Vous êtes sur la page 1sur 29
Bacharelado em Sistemas de Informação Banco de Dados Prof. Dory Gonzaga Rodrigues

Bacharelado em Sistemas de Informação

Banco de Dados

Bacharelado em Sistemas de Informação Banco de Dados Prof. Dory Gonzaga Rodrigues

Prof. Dory Gonzaga Rodrigues

Apostila Adaptada

Autora Sandra de Albuquerque Siebra Doutora em Ciência da Computação, pelo Centro de Informática da UFPE Professora da Universidade Federal Rural de Pernambuco (UFRPE).

Sumário

Capítulo 1 – Banco de Dados...............................................................................................................4 Alguns Conceitos Básicos...............................................................................................................4 Como era antes de surgirem os bancos de dados?...........................................................................6 Resumo da Origem dos Bancos de Dados..................................................................................7 O Sistema Gerenciador de Banco de Dados (SGBD)......................................................................9 Estrutura Geral de um SGBD........................................................................................................11 Classes de Usuários de um Sistema de Banco de Dados...............................................................12 Alguns Exemplos de SGBDs.........................................................................................................12 Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados...............................................................14 Evolução do armazenamento de dados..........................................................................................14 Primeira Geração dos Bancos de Dados........................................................................................14 Modelo de Dados Hierárquico..................................................................................................14 Modelo de Dados em Redes......................................................................................................16 Segunda Geração dos Bancos de Dados........................................................................................17 Modelo de Dados Relacional....................................................................................................17 Terceira Geração dos Bancos de Dados.........................................................................................18 Modelo de Dados Orientado a Objetos.....................................................................................18 Modelo de Dados Objeto-Relacional........................................................................................19 Arquiteturas de Sistemas de Banco de Dados...............................................................................19 Arquiteturas Centralizadas........................................................................................................20 Arquitetura Cliente-Servidor.....................................................................................................20 Arquitetura Distribuída.............................................................................................................22 Arquitetura Paralela..................................................................................................................23 Arquitetura Mono-Usuário........................................................................................................24 Abstração de Dados.......................................................................................................................24

Capítulo 1 – Banco de Dados

Neste capítulo, vamos comentar sobre os conceitos básicos da área de Banco de Dados. Essa é uma área muito presente no nosso dia-a-dia e que ganha ainda mais importância quando paramos para pensar que estamos vivendo na chamada “Era da Informação”, onde o conhecimento adquirido a partir da avaliação das informações é o maior bem de qualquer empresa ou instituição. E informações são obtidas a partir de dados que precisam estar armazenados em algum lugar.

Você poderia me perguntar, mas dados e informações não seriam a mesma coisa? Não, não são. Vamos diferenciar.

Dado: é um elemento que mantém a sua forma bruta (texto, imagens, sons, vídeos, etc.) e ele sozinho não levará a compreender determinada situação. Ou seja, o termo “Dado” envolve fatos, imagens, sons que podem ou não serem úteis para determinado fim, eles apenas representam coisas do mundo real.

Informação: Já a “Informação” é o conjunto de dados coletados de forma a se tornarem aplicáveis a determinada situação, ou seja, sua forma e conteúdo são apropriados para um uso específico. A informação não existe por si só, ela é obtida através de uma interpretação realizada sobre um grupo de dados. Além disso, ela necessita de uma situação ou objetivo que justifique a sua existência. Vamos dar alguns exemplos. O nome de um cliente, o número de peças em um estoque, o número de horas trabalhadas por um empregado e o valor total de um pedido são dados. Já o valor total das vendas por mês de uma loja é uma informação que para ser obtida, vai precisar considerar uma série de dados (tais como, o mês de cada pedido e o valor total do pedido) armazenados em algum lugar.

O Banco de Dados, geralmente, será esse lugar onde os dados estarão armazenados e a partir do qual você irá extrair informações para finalidades diversas. Mas, finalmente, qual a definição de Banco de Dados?

Alguns Conceitos Básicos

Um Banco de Dados (também chamado de Base de Dados) é uma coleção de dados relacionados, organizados e armazenados visando facilitar a manipulação dos dados armazenados, permitindo realizar alterações, inserções, remoções e consultas. Os tipos de “coleções de dados” são ilimitados (ex: dados de um produto, de um estudante, mapas, dados sobre genes humanos, etc), ou seja, quaisquer aplicações do mundo real que possam ser representadas através de dados computáveis poderão ser armazenadas em um banco de dados. Vamos ver agora, algumas definições mais formais:

“Um Banco de Dados é uma coleção de dados operacionais armazenados, sendo usados pelos sistemas de aplicação de uma determinada organização” (DATE, 2000).

“Um Banco de dados é um conjunto de dados armazenados, cujo conteúdo informativo representa a cada instante, o estado atual de uma determinada aplicação” (LAENDER, 1993).

“Um banco de dados é uma coleção de dados relacionados que representa alguns aspectos do mundo real, sendo chamado, às vezes, de mini mundo.” (ELMASRI e NAVATHE, 2005)

Realmente, como definiram ELMASRI e NAVATHE, um banco de dados (BD) é um modelo de uma determinada parte da realidade, geralmente denominada de Universo de Discurso ou mini mundo. Isso porque só devemos colocar no banco de dados as informações do domínio que sejam relevantes para a resolução de um problema ou para obter determinadas informações. Vamos dar um exemplo. Suponha que precisamos criar um banco de dados para uma Livraria. O mini mundo da Livraria englobaria diversas características que a definem como, por exemplo, o seu nome, a sua localização, os dados dos seus proprietários, os dados dos funcionários que trabalham lá, os dados dos livros disponíveis e de qualquer outro produto que esteja sendo comercializado. Essas informações são interessantes para serem armazenadas e, posteriormente recuperadas. Porém, por exemplo, as cores das paredes da livraria, o material de que é feito o chão, não são características relevantes para serem consultadas em um sistema, logo, não fariam parte dos dados a serem armazenados no banco de dados. Logo, o mini mundo será justamente a especificação da

parte do mundo real que é relevante para a implementação da livraria (vide Figura 1) e deverá conter informações que caracterizem o domínio do negócio.

parte do mundo real que é relevante para a implementação da livraria (vide Figura 1) e

Figura 1 - O Mundo Real x Mini Mundo

Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas especialmente para esta tarefa (por exemplo, no caso da livraria, poderia existir um Sistema Controle de Livraria para gerenciar o acesso ao Banco de Dados) ou por um Sistema Gerenciador de Bancos de Dados (SGBDs ou DBMS – Database Management System). Um SGBD é um pacote de software designado para guardar e gerenciar um banco de dados. É ele que realiza a manipulação dos dados armazenados em um BD. O SGBD tem uma gama de funções pré-implementadas que gerenciam as operações de inserção, remoção, atualização e consulta dos dados armazenados.

O conjunto formado por um banco de dados mais as aplicações que o manipulam (o SGBD) é chamado de Sistema de Banco de Dados (SBD). Pode-se definir esse sistema como um ambiente cujo objetivo global é registrar e manter informação. A Figura 2 representa o ambiente de um sistema de banco de dados, que interage com os programadores (as pessoas que o desenvolveram) e com os usuários finais (as pessoas que o utilizarão). Num primeiro nível as pessoas interagem com os programas de aplicação (programas desenvolvidos em uma linguagem de aplicação), que foram criados para os usuários finais utilizando-se uma linguagem de consulta (linguagem própria para acesso ao banco de dados). Esta aplicação interage com o SGBD, que possui programas responsáveis por processar as consultas e acessar os dados armazenados, dentre outras funções. Por fim, num nível mais interno, encontra-se a base de dados, separada em dois arquivos distintos, um contendo a definição dos dados e outro contendo os dados propriamente ditos, ou seja, os dados armazenados.

parte do mundo real que é relevante para a implementação da livraria (vide Figura 1) e

Figura 2 - Sistema de Banco de Dados

A separação da base de dados em dois arquivos distintos deve-se ao fato de que para um conjunto de dados é definida apenas uma estrutura, que por suas características próprias altera-se pouco. Por exemplo, define-se que o endereço do estudante deve ser um campo alfanumérico com capacidade para armazenar 80 caracteres. Já os dados armazenados mudam muito uma vez que a cada nova inserção, alteração ou remoção de dados, os dados são modificados. Por exemplo, o endereço da estudante Ana Maria é Rua das Flores, 320. Mas a qualquer instante esse dado pode ser modificado. Por exemplo, ela pode passar a morar na Av. Abdias de Carvalho, 52. Sendo assim, é uma vantagem manter separados estes dois arquivos com características distintas. O arquivo contendo a definição dos

dados é o que podemos chamar de metadados, ou dados sobre os dados. Ou seja, são dados cujo significado reflete características dos próprios dados, como por exemplo: de que tipo são estes dados? Qual será o tamanho deles? Ele pode ficar em branco ou não? Etc.

Como era antes de surgirem os bancos de dados?

Antes de existirem os bancos de dados, qualquer sistema, programa ou aplicação que precisasse armazenar e manipular dados fazia uso de um sistema de arquivos. Ou seja, cada sistema, programa ou aplicação desenvolvido tinha seus próprios arquivos de armazenamento dos dados. Geralmente, naquela época, os programas eram escritos em respostas às necessidades, ou seja, iam sendo desenvolvidos na medida em que as necessidades apareciam e muitas vezes, eram desenvolvidos por programadores diferentes.

Qual a implicação disso? Diferentes Programadores pensam e programam de forma diferente. Desse modo, os arquivos de cada programa desenvolvido poderiam estar em formatos diferentes e poderiam ter sido usadas linguagem de programação diferentes. Qual o problema com isso? O problema com isso é que entre os diversos sistemas desenvolvidos gradualmente para uma determinada empresa ou instituição poderiam haver dados em comum. Vamos dar um exemplo: suponha uma fábrica que possui um Sistema de Vendas, um Sistema de Produção e um Sistema de Engenharia (vide Figura 3). Cada um deles teria seus próprios arquivos e nesses arquivos poderia existir em comum, por exemplo, os dados de um produto, que por causa dessa organização precisaria ser replicado em cada sistema de arquivos. E qual a consequência dessa replicação de dados dentro de uma mesma fábrica?

dados é o que podemos chamar de metadados, ou dados sobre os dados. Ou seja, são

Figura 3 - Exemplo de sistemas que fazem uso de um Sistema de Arquivos

A consequência é que essa redundância poderia acarretar inconsistência dos dados, uma vez que a mesma informação poderia estar duplicada em diversos arquivos (no exemplo, os dados do produto). Vamos dar um exemplo. Vamos supor que nos arquivos de Vendas, eu atualizei o nome do produto 01 de Mesa para Cadeira. Se eu desejasse manter a consistência, eu teria de entrar nos arquivos de Produção e de Engenharia e fazer a mesma atualização. Se não fizesse, os dados do produto na fábrica ficariam inconsistentes, pois dependendo do sistema acessado o produto 01 poderia ser Mesa ou Cadeira. Ficou claro?

Além disso, a duplicação de dados em diversos sistemas de arquivos leva a um maior custo de armazenamento (lembre, você está armazenando diversas vezes os mesmos dados) e a necessidade de redigitação de dados (e esse trabalho repetitivo pode levar a erros, que também geram inconsistências entre os dados). Adicionalmente, o uso de sistemas de arquivos possui outros problemas tais como:

» Dificuldade do acesso a dados – a geração de informação pode surgir, durante o tempo em que o sistema está em produção, sob diferentes aspectos. Cada requisição de informação diferente, no sistema de arquivos, vai gerar a necessidade da criação de um programa aplicativo, de uma nova consulta ou de um novo relatório. Dessa forma, a recuperação de informação não é atendida de modo eficiente. Haveria dificuldade em apagar informações dos sistemas. Poderia novamente ocorrer casos de inconsistência, onde um produto poderia ser deletado dos arquivos de Vendas, mas não dos outros dois arquivos (Engenharia e Produção).

» Isolamento dos dados – os dados estão armazenados em arquivos distintos, que não possuem qualquer tipo de relacionamento direto, e ainda, podem conter diferentes formatos para o mesmo dado. Por exemplo, o código

do produto nos arquivos de venda poderia ser representado só por números e nos arquivos de Produção por letras e números.

» Problemas de integridade – fica difícil manter restrições de integridade automaticamente. E o que são essas restrições de integridade? Seriam checagens de determinadas condições a serem feitas pelo sistema sobre os dados armazenados (por exemplo, a quantidade de produtos em estoque não pode ser inferior a um valor X). Essas restrições teriam de ser mantidas pelo sistema, implicando em implementação do código apropriado para fazer esse tipo de checagem em CADA UM dos sistemas afetados. O problema seria que a cada inclusão de uma nova restrição de integridade, um novo código deveria ser escrito EM CADA SISTEMA para poder mantê-la, já que cada sistema trabalha com um diferente sistema de arquivos.

» Problemas de segurança – Nem todos os usuários do sistema devem estar autorizados a ver/acessar todos os dados armazenados. Porém, uma vez que os programas de aplicação são inseridos no sistema como um todo, de forma aleatória (à medida que a necessidade surge, lembra?) é difícil implementar e garantir a efetividade de regras de segurança.

» Anomalias no acesso concorrente – a melhora de desempenho em um sistema pode ocorrer pela execução simultânea de diversas operações. Geralmente, nos sistemas de arquivos, esta melhoria seria difícil de implementar sem levar a danos na consistência dos dados. Ou seja, seria difícil permitir que múltiplos usuários possam ter acesso aos dados ao MESMO TEMPO. Vamos dar um exemplo. Considere um sistema bancário (com a existência de contas correntes, agências, transações bancárias, etc) e a seguinte situação: suponha que o saldo de uma conta bancária C1 seja 500 reais. Se dois clientes retiram fundos desta conta C1 AO MESMO TEMPO (acesso concorrente à conta C1), um estado inconsistente pode ocorrer se na execução das duas instâncias do programa de débito, ambos os clientes lerem o saldo inicial original e retirarem, cada um, seu valor correspondente, e seja então armazenado o valor restante. Instanciando o problema:

  • 1. Ambos leem o valor do saldo 500;

  • 2. Um retira 50 reais (resultando 450 reais) e o outro 100 reais (resultado 400 reais) – lembre que ambos

estão realizando a operação em cima dos 500 reais iniciais que foi lido;

  • 3. Dependendo de qual execução do programa de débito registre o saldo restante primeiro, o valor do saldo

da conta será 450 ou 400 reais, quando, na verdade, deveria ser 350 reais.

Outros problemas existentes são:

» A definição das estruturas dos arquivos está inserida no próprio código dos programas, sistemas ou aplicativos, dificultando a manutenção;

» Compartilhamento de um arquivo por vários programas fica comprometido. Há a necessidade de duplicar a definição das estruturas dos arquivos nos programas;

» Podem existir arquivos e programas de um mesmo sistema desenvolvidos, de forma isolada, por diferentes programadores de forma diferentes e, até mesmo, em linguagens de programação diferentes.

Justamente a necessidade de resolver diversos desses problemas motivou a criação dos bancos de dados e dos sistemas gerenciadores de banco de dados. Com eles, os dados só necessitam ser armazenados uma única vez e passam a ser acessados por todos os sistemas (vide Figura 4)

do produto nos arquivos de venda poderia ser representado só por números e nos arquivos de

Figura 4 - Exemplo de Sistemas fazendo uso de um Banco de Dados

Resumo da Origem dos Bancos de Dados

No início da computação, os programas tinham o único objetivo de armazenar e manipular dados. Esses programas gravavam seus dados em arquivos em disco, segundo estruturas de dados próprias (vide Figura 5). Programas que não conhecessem a estrutura dos dados não podiam utilizar os dados.

Resumo da Origem dos Bancos de Dados No início da computação, os programas tinham o único

Figura 5 - Programa acessando seu arquivo

Se vários programas precisassem compartilhar os dados de um mesmo arquivo, eles todos teriam que conhecer e manipular as mesmas estruturas de dados (vide Figura 6). Ou seja, toda a definição dos dados deveria estar dentro dos programas que os manipulariam.

Resumo da Origem dos Bancos de Dados No início da computação, os programas tinham o único

Figura 6 - Vários programas acessando os dados tinham de conhecer sua estrutura

Se um programa precisasse realizar alguma mudança na estrutura de dados, todos os programas que acessam os dados tinham que ser alterados, mesmo que a alteração ocorresse em dados não manipulados pelos outros programas. Isso gerava um grande problema: Como garantir a unicidade das estruturas de dados entre os diversos programas devido à existência de redundâncias? Para evitar esse problema, colocou-se um sistema intermediário que deveria conhecer a estrutura de dados do arquivo manipulado; que deveria fornecer apenas os dados que cada programa necessitasse e deveria armazenar adequadamente os dados de cada programa (vide Figura 7).

Resumo da Origem dos Bancos de Dados No início da computação, os programas tinham o único

Figura 7 - Acesso ao arquivo através de um sistema intermediário

Agora, através do uso desse sistema intermediário:

» Os programas passariam a enxergar apenas os dados que lhes interessam. » Os programas não precisariam conhecer os detalhes de como seus dados estão gravados fisicamente. » Os programas não precisariam ser modificados se a estrutura de dados que utilizam não for modificada. » As alterações ficariam concentradas nesse sistema intermediário.

Com o tempo, esse sistema intermediário passou a gerenciar vários arquivos (vide Figura 8) e a essa coleção de arquivos foi dado o nome de Banco de Dados e ao sistema intermediário deu-se o nome de Sistema Gerenciador de Banco de Dados (SGBD).

Figura 8 - SGBD gerenciando o acesso aos arquivos usados pelos programas 9

Figura 8 - SGBD gerenciando o acesso aos arquivos usados pelos programas

O Sistema Gerenciador de Banco de Dados (SGBD)

Vimos anteriormente neste capítulo que um Sistema de Banco de Dados (SBD) é o conjunto formado por um banco de dados (BD) mais as aplicações que o manipulam (o SGBD). Assim, um SGBD é uma coleção de programas que habilitam usuários a criar e manter um banco de dados. Ele é um software de propósito geral, que facilita o processo de definição, construção e manipulação de um banco de dados.

Definição do banco de dados envolve especificar estruturas e tipos de dados para serem gravados no banco de dados, com uma descrição detalhada de cada tipo de dado.

Construção do banco de dados é o processo de consistir e gravar inicialmente dados no banco de dados.

Manipulação de um banco de dados inclui funções como consulta por dados específicos e atualização para refletir as alterações no mundo real.

Quais características esse software deve ter? Vamos apresentá-las a seguir:

» Independência de Dados – consiste na capacidade de tornar as características físicas dos dados (como localização, estrutura e tamanho) transparentes para a aplicação. Ou seja, os SGBD devem ser dotados de recursos que possibilitem a descrição das estruturas de dados (layout de arquivos e/ou tabelas) de forma independente dos procedimentos de manipulação (leitura e gravação) de dados no BD. Isto possibilita tornar transparente para os programas que acessam o BD as alterações que, por ventura, venham a ocorrer nas estruturas de dados, como, por exemplo, o acréscimo de um novo campo de informação ao banco. Da mesma forma, alterações em lógicas de programas que acessam o BD não devem afetar as estruturas de dados definidas no BD. Os SGBDs conseguem isso por fazer uso de SQL (Structured Query Language), que possui grupos de comandos específicos e independentes para as tarefas de criação e alteração de tabelas (DDL – Data Definition Language) e leitura e atualização do BD (DML – Data Manipulation Language).

» Redução ou Eliminação de Redundâncias – Em um sistema tradicional de controle de arquivos cada usuário normalmente apresenta seus próprios arquivos armazenando o conjunto de dados que é de seu interesse e, nestes casos, é comum ocorrer redundância de dados. Esta redundância consiste no armazenamento de uma mesma informação em locais diferentes. Por exemplo, o nome do funcionário poderia estar nos arquivos dos Sistemas de Cadastro, de Folha de Pagamento e de Avaliação em uma empresa, se esses não tivessem uma única base de dados compartilhada. A redundância é danosa para o ambiente computacional, pois ela leva a um aumento de esforço computacional para realizar a atualização dos dados redundantes e aumento do espaço necessário para o armazenamento destes dados. Porém, o problema mais sério é que a representação dos dados desta forma pode tornar-se inconsistente, pois duas informações podem aparecer em locais distintos, mas apresentando valores diferentes. Dessa forma, um SGBD deve prover meios para que seja possível o controle da redundância de dados nos diversos arquivos administrados por ele. Para isso, os dados que eventualmente são comuns a mais de um sistema devem ser compartilhados por eles, fazendo-os acessar um mesmo banco de dados. Além disso, deve haver uma centralização da definição dos dados num Dicionário de Dados ou Catálogo, que vai servir como base para a operação do SGBD.

» Eliminação de Inconsistências – Geralmente causada pela redundância de dados, a inconsistência ocorre quando um mesmo campo tem valores diferentes em sistemas diferentes. Por exemplo, o estado civil de um funcionário pode estar como solteiro no Sistema de Cadastro e como casado no Sistema de Folha de Pagamento. Isto pode ocorrer quando esta pessoa atualizou o campo em um sistema e não o atualizou em outro. Quando o dado é armazenado em um único local (no caso, o banco de dados) e compartilhado pelos sistemas, este problema não ocorre.

» Compartilhamento dos Dados – Permite a utilização simultânea e segura de um dado, por mais de uma aplicação ou usuário (através do tratamento de concorrência), independente da operação que esteja sendo realizada. O compartilhamento de dados visa diminuir a redundância de dados. Para implementar o compartilhamento de dados

é necessário que o SGBD possua um competente sistema de segurança, para que se estabeleça a privacidade de dados, através de mecanismos de restrição de acesso.

» Tratamento de Concorrência – para que seja possível um compartilhamento simultâneo dos dados armazenados no banco de dados, o SGBD implementa o tratamento de concorrência. Ou seja, o SGBD deve possuir mecanismos para a identificação e tratamento dos acessos concorrentes, para garantir a consistência das informações do BD no sentido de sua veracidade. Os sistemas de bloqueio (LOCK) e desbloqueio (UNLOCK) são os mecanismos utilizados para evitar que uma informação que está sendo manipulada por um determinado usuário U1, seja alterada por outro usuário U2. Enquanto o primeiro usuário U1 estiver acessando um dado no BD, o segundo usuário U2 não terá acesso ao mesmo ou o terá apenas para leitura e receberá um aviso do SGBD de que a informação está sendo acessada por outro usuário e pode estar sendo modificada.

» Privacidade dos Dados – um SGBD deve fornecer um subsistema de autorização e segurança (por exemplo, através de senhas e sistemas de LOG e AUDIT, o qual é utilizado pelo DBA para criar “contas” e especificar as restrições destas contas; o controle de restrições se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao SGBD. Dessa forma, torna-se possível definir, para cada usuário, o nível de acesso a ele concedido (leitura, leitura e gravação ou sem acesso) a tabela e/ou campo. Este recurso impede que pessoas não autorizadas utilizem ou atualizem uma determinada tabela ou campo, bem como que utilizem softwares inadequados ao seu perfil.

» Segurança dos Dados – o SGBD deve oferecer meios que resguardem a base de dados nos casos de falha de programa, equipamento ou acidentes. Também deve ser possível que alterações indevidas feitas pelos usuários durante a operação dos aplicativos sejam desfeitas sem prejuízo da coerência dos dados. A segurança física dos dados poderá ser obtida a partir de utilitários e aplicativos que os fabricantes colocam em seus produtos, visando facilitar o trabalho de proteção aos dados contra danos físicos, que podem ser causados por falhas de hardware ou queda da rede. Nessa linha destacam-se as rotinas de backup (cópias de segurança dos dados armazenados) e a gravação com espelhamento (você ter duas máquinas diferentes com o banco de dados instalado e periodicamente ele ser replicado de uma máquina para outra, para se uma sair do ar, a outra já assumir).

» Padronização dos Dados – Permite que os campos armazenados na base de dados sejam padronizados segundo um determinado formato. Por exemplo, para o campo sexo poderia ser definido e apenas permitido usar os caracteres “M” ou “F”. Padronizar os dados pode facilitar a comunicação e a cooperação entre vários departamentos, projetos e usuários. Padrões podem ser definidos para formatos de nomes, elementos de dados, telas, relatórios, terminologias, etc. O DBA pode obrigar a padronização em um ambiente de base de dados centralizado, muito mais facilmente que em um ambiente onde cada usuário ou grupo tem o controle de seus próprios arquivos e software;

» Controle de Transações – Uma Transação é um conjunto de operações sobre o BD que devem ser executadas integralmente e sem falhas ou interrupções. Caso contrário, devem ser desfeitas. Todo SGBD deve realizar o controle das Transações.

» Integridade dos Dados – A integridade de dados refere-se a mecanismos que estão disponíveis nos SGBD, que garantem a consistência dos dados armazenados no SGBD, segundo parâmetros de validação, especificados no momento de criação do BD, em conjunto com as estruturas de dados. Ou seja, esses mecanismos garantem que o conteúdo dos dados armazenados no Banco de Dados possua valores coerentes ao objetivo do campo, não permitindo que valores absurdos sejam cadastrados. Por exemplo: Não permite que uma data final seja menor do que uma data inicial.

» Representação de Relacionamento Complexo entre Dados – uma base de dados pode possuir uma variedade de dados que estão inter-relacionados de muitas maneiras. Um SGBD deve ter a capacidade de representar uma variedade de relacionamentos complexos entre dados, bem como recuperar e modificar dados relacionados de maneira fácil e eficiente

» Possibilidade de Múltiplas Interfaces – Vários usuários representam também necessidades diversas no que se refere aos tipos de interfaces fornecidas pelo SGBD. Interfaces para consultas de dados, programação, e interfaces baseadas em menus ou em linguagem natural são exemplos de alguns tipos que podem estar disponíveis.

Estrutura Geral de um SGBD

A estrutura geral de um SGBD envolve, em síntese, os componentes apresentados na Figura 9 e descritos a seguir.

Estrutura Geral de um SGBD A estrutura geral de um SGBD envolve, em síntese, os componentes

Figura 9 - Estrutura Geral do SGBD

» Pré-compilador da DML – converte comandos da DML embutidos em um aplicativo para chamadas de procedimentos normais na linguagem hospedeira do BD. O pré-compilador precisa interagir com o processador de consultas pra gerar o código apropriado.

» Compilador DDL – converte comandos da DDL em um conjunto de tabelas contendo metadados (“dados sobre dados”), que são armazenados no Dicionário de Dados.

» Processador de consultas – traduz os comandos em uma linguagem de consulta para instruções de baixo nível que o gerenciador do banco de dados pode interpretar. Além disso, o processador de consultas tenta transformar uma requisição do usuário em uma forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa estratégia para executar a consulta.

» Gerenciador do banco de dados – fornece a interface entre os dados de baixo nível armazenados no disco e os programas aplicativos e de consulta submetidos ao sistema.

» Gerenciador de arquivos – gerencia a alocação do espaço na armazenagem do disco e as estruturas de dados usadas para representar a informação armazenada no disco. É o gerenciador de memória quem traduz os diversos comandos DML em comandos de baixo nível para atuar sobre os dados armazenados na base de dados.

Adicionalmente, diversas estruturas de dados são requeridas como parte da implementação do sistema físico, incluindo:

» Arquivos de dados – armazenam o banco de dados propriamente dito.

» Dicionário de dados – armazena informações sobre a estrutura do banco de dados. Também chamado de catálogo de dados, contém os metadados, isto é, as informações a respeito dos componentes do banco de dados:

tabelas, índices, procedimentos, restrições e outros.

» Índices – proporcionam acesso rápido aos itens de dados com valores específicos. São estruturas que permitem um acesso mais eficiente aos dados.

Classes de Usuários de um Sistema de Banco de Dados

Um Banco de Dados pode apresentar diversos usuários cada qual com uma necessidade em particular, e com um envolvimento diferente com os dados do BD. Você sabe quais são eles? Não? Que tal conhecer um pouco mais? Os usuários podem ser classificados nas seguintes categorias:

» Administrador de Bancos de Dados (DBA – DataBase Administrator) – em qualquer organização onde muitas pessoas compartilham diversos recursos, existe a necessidade de um administrador chefe (sempre existe o que vai ficar à frente, não é?) para supervisionar e gerenciar estes recursos (em um ambiente de base de dados, o recurso primário é a própria base de dados e os recursos secundários são o próprio SGBD e software relacionados). A administração desses recursos é de responsabilidade do DBA. Ele é responsável, entre outras coisas, por autorizar acesso à base de dados e coordenar e monitorar seu uso. Adicionalmente, ele é responsável por problemas, tais como, quebra de segurança ou baixo desempenho do BD.

» Projetista de Bancos de Dados – também chamado de analista de banco de dados, possui a responsabilidade de identificar os dados a serem armazenados no BD e pela escolha da estrutura apropriada a ser utilizada para armazená-los. Ou seja, é a pessoa responsável pelo projeto de construção e utilização do BD, envolvendo as tarefas de definição de quais dados deverão ser construídos e como eles serão construídos. Pode existir um único projetista ou um grupo deles e ele(s) irá(ao) interagir com outras classes de usuários, tanto os analistas e programadores, como os chamados usuários finais do sistema, a fim de obter a visão dos dados que cada um possui, integrando-as de forma a se obter uma representação adequada de todos os dados.

» Usuários Finais – existem profissionais que precisam ter acesso à base de dados para consultar, modificar e gerar relatórios. A base de dados existe para estes usuários.

Existem algumas categorias de usuários finais:

Usuários ocasionais: ocasionalmente fazem acesso à base de dados, mas eles podem necessitar de diferentes informações a cada vez que fazem acesso. Eles podem usar uma linguagem de consulta sofisticada para especificar suas requisições e são, tipicamente, gerentes de médio ou alto nível;

Usuários comuns ou paramétricos: estes usuários realizam operações padrões de consultas e atualizações, chamadas transações permitidas, que foram cuidadosamente programadas e testadas. Estes usuários constantemente realizam recuperações e modificações na base de dados;

Usuários sofisticados: incluem engenheiros, analistas de negócios e outros que procuraram familiarizar-se com as facilidades de um SGBD para atender aos seus complexos requisitos;

Analistas de Sistemas e Programadores de Aplicações: são os Engenheiros de Software, aquelas pessoas que determinam as necessidades dos usuários finais e desenvolvem as especificações para as transações que irão atender a estas necessidades. Os programadores das aplicações são as pessoas que irão realmente implementar estas especificações, criando os programas que irão constituir o sistema e fazer acesso ao BD. Adicionalmente, os programadores também são os responsáveis por testar os programas criados. Muitos de nós nos enquadramos nessa última categoria de usuários (usuários finais).

Podem existir ainda alguns profissionais de apoio ou suporte para realizar tarefas específicas como tirar backup (cópia de segurança) dos dados armazenados no Banco de Dados.

Alguns Exemplos de SGBDs

Alguns dos principais SGBDs disponíveis no mercado nos últimos anos são:

» Oracle – é um sistema comercial, mas possui versões gratuitas para uso acadêmico e/ou doméstico (em casa). Ele foi o primeiro Banco de Dados Corporativo (cliente/servidor) possuindo grande variedade de distribuições

(para Macintosh, Windows, Linux, FreeBSD, Unix) e para computadores de grande porte. Foi um dos primeiros a fazer parte do mercado Web. Nele a linguagem padrão é a SQL, mas possui também uma linguagem própria para desenvolvimento de aplicações, a PL/SQL4. A participação do Oracle no mercado de Banco de Dados é bastante acentuada, principalmente em grandes empresas e em conjunto com sistemas de médio e grande porte. É um SGBD robusto e seguro, quando bem administrado. Além da base de dados, a Oracle desenvolve uma suíte de desenvolvimento chamada de Oracle Developer Suite, utilizada na construção de programas de computador que interagem com a sua base de dados. Site Oficial em http://www.oracle.com/us/products/database/index.htm

» Microsoft SQL Server – é o banco de dados comercial da Microsoft. Ele é um dos principais concorrentes do Oracle. Tem como uma das vantagens o fato de, por ser um produto Microsoft, se integrar nativamente com produtos e linguagens da Microsoft (talvez seja esse o fator que o popularizou!). As versões atuais são independentes e operam exclusivamente sobre Windows. É um software proprietário e pago, como a maioria dos produtos Microsoft. Algumas empresas que usam o MS SQL Server. Site Oficial em http://www.microsoft.com/sqlserver/2008/en/us/

» IBM DB2 – é o Sistema Gerenciador de Banco de Dados Relacionais (SGDBR) produzido pela IBM. Existem diferentes versões do DB2 que rodam desde num simples PDA (computador de mão), até em potentes mainframes e funcionam em servidores baseados em sistemas Unix, Windows ou Linux. DB2 é vendido em diversos tipos de edições ou licenças. Pela escolha de uma versão com menos recursos, a IBM evita que os consumidores paguem por coisas que não iriam usar. Informações em http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp

» Interbase – é um sistema gerenciador de banco de dados relacionais da Borland. Foi incluído, pela Borland, nas suas ferramentas de desenvolvimento (Delphi, C++ Builder e JBuider). Ele pode ser instalado em sistemas operacionais Microsoft Windows, Linux, Mac OS X e Sun Solaris. Além de não ser pesado é relativamente rápido e suporta bancos de dados de grande tamanho (maiores que 2 Gigabytes).Em 2000 a Borland liberou o código da versão 6.0, mas as posteriores voltaram a ter licença proprietária. Desta versão 6.0 foi criado o Banco de Dados Open source Firebird. Site Oficial: http://www.embarcadero.com/products/interbase-smp

» Firebird – Nascido de uma iniciativa da Borland em abrir o código do InterBase 6.0, este sistema é open source e esbanja versatilidade e robustez. O Firebird (algumas vezes chamado de FirebirdSQL) roda em Linux, Windows, Mac OS e uma variedade de plataformas Unix. A Fundação FirebirdSQL coordena a manutenção e desenvolvimento do Firebird, sendo que os códigos fonte são disponibilizados sob o CVS da SourceForge. O produto é bastante seguro e confiável, suportando sistemas com centenas de usuários simultâneos e bases de dados com dezenas/centenas de gigabytes. Há suporte gratuito na Internet através de vários sites. O Firebird é amplamente utilizado em todo o mundo, com a maior base de usuários no Brasil, Rússia e Europa. Site Oficial em http://www.firebirdsql.org/

» MySQL – é, atualmente, um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo. Ele possui versões para Windows, Solaris, Unix, FreeBSD, Linux e é gratuito para uso não-comercial. Algumas das empresas mais famosas que fazem uso deste banco estão: NASA, Banco Bradesco, Dataprev, HP, Nokia, Sony e Lufthansa. O MySQL é usado principalmente para desenvolvimento WEB como servidor de dados para comércio eletrônico. Passou a ser considerado um SGBD de verdade (com conceito de transação) a partir da versão 5. Site Oficial em http://www.mysql.com/

» PostgreSQL – é um sistema gerenciador de banco de dados objeto relacional (SGBDOR), desenvolvido como projeto de código aberto. Ele é um dos SGBDs (Sistema Gerenciador de Bancos de Dados) de código aberto mais avançados, é grautito e tem uma boa aceitação no mercado. Originalmente concebido para rodar em Linux, ele possui versões para Windows. É usando, principalmente, para comércio eletrônico juntamente com linguagem PHP. O PostgreSQL é um projeto open source coordenado pelo PostgreSQL Global Development Group. Site Oficial em http://www.postgresql.org/

Dos SGBDs listados acima vale ressaltar que o SQL Server e o Oracle tem versões gratuitas, porém limitadas. O Firebird e o PostgreSQL são open source, o DB2 é pago e o MySQL é gratuito para desenvolvimento, mas pago para produção.

A escolha de qual SGBD usar depende muito do projeto sendo desenvolvido e do quanto a empresa está disposta a investir para armazenamento dos seus dados. Um SGBD gratuito e muito popular nos dias de hoje é o PostgreSQL e vários sistemas de instituições públicas vêm adotando o mesmo. Já no mundo corporativo o Oracle tem sido um dos

mais adotados, por ser um dos mais robustos.

Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados

Neste capítulo, vamos estudar a evolução dos SGBDs no tempo, que deram origem a gerações diferentes de banco de dados, além de estudar a forma como os bancos de dados estão organizados internamente, ou seja, a sua arquitetura.

Evolução do armazenamento de dados

Como visto no capítulo anterior, no começo, não existiam bancos de dados, mas apenas os sistemas de arquivos. Ou seja, cada aplicação ou programa desenvolvido para uma organização tinha seu próprio conjunto de dados e a descrição desses dados ficava dentro das próprias aplicações. Dessa forma, não havia compartilhamento de dados entre as mesmas. Devido a isso, diversos problemas surgiam, tais como redundância de dados, inconsistências, falta de padronização, falta de segurança no acesso aos dados, limitações no compartilhamento dos dados, entre outros. Os bancos de dados surgiram como forma de tentar resolver esses problemas. Os bancos de dados não foram sempre os mesmos, inclusive são subdivididos em três gerações bem definidas (vide Figura 10), cada uma com características próprias. Na primeira geração, que surgiu no final dos anos 60, estão os bancos de dados hierárquicos e em rede. Na segunda geração que nasceu no final dos anos 70 está o banco de dados relacional. E, por fim, a geração mais atual que data desde o final dos anos 80 estão os bancos de dados orientado a objetos e objeto-relacional. A seguir, detalharemos cada uma dessas gerações.

Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados Neste capítulo, vamos estudar a evolução

Figura 10 - Evolução dos Bancos de Dados

Primeira Geração dos Bancos de Dados

Os primeiros bancos de dados surgiram nos anos 60, com o surgimento dos bancos de dados hierárquicos e em rede, com acesso sequencial aos dados e processamento em batch (em lote, várias instruções de uma vez), essa foi a chamada primeira geração. Os dois modelos da época eram o Hierárquico e o em Rede, ambos orientados a registros, isto é, qualquer acesso à base de dados – inserção, consulta, alteração ou remoção – era feita em um registro de cada vez. Vamos detalhar agora, cada um desses modelos.

Modelo de Dados Hierárquico

O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados. Nesse modelo de dados, os dados são estruturados em hierarquias ou árvores (lembra das árvores que você estudou na disciplina de estrutura de dados?). Os nós das hierarquias contêm ocorrências de registros, onde cada registro é uma coleção de campos

(atributos), cada qual contendo somente um valor.

Os registros são conectados uns aos outros por meio de uma ligação, também chamada de link (associação essa entre exatamente dois registros). O registro da hierarquia que precede a outros é o registro-pai, os outros são chamados de registros-filhos. O relacionamento entre um registro-pai e vários registros-filhos possui cardinalidade 1:N, ou seja, cada registro-pai pode possuir 1 ou mais registros-filhos, mas os registros filhos possuem apenas um único registro pai (vide representação da Figura 11).

(atributos), cada qual contendo somente um valor. Os registros são conectados uns aos outros por meio

Figura 11 - Relação 1-N entre registro-pai e registros-filhos

Os dados organizados, segundo este modelo, podem ser acessados segundo uma sequência hierárquica com uma navegação do topo (raiz) para as folhas (nós sem filhos) e da esquerda para a direita dentro de cada nó ou registro. Um mesmo registro pode estar associado a vários registros diferentes, desde que seja replicado. Porém, a replicação possui duas grandes desvantagens: pode causar inconsistência de dados quando houver atualização e causar desperdício de espaço.

Vamos dar um exemplo. Suponha que o conjunto de todos os registros de clientes e de contas de um banco está organizado na forma de uma árvore com raiz (vide Figura 12), em que a raiz da árvore é um registro falso (sem conteúdo, serve apenas para iniciar a árvore). Teríamos nós que representariam os clientes (com valores para o nome do cliente, a rua onde ele mora e a cidade) como, por exemplo, o nó com valor “Rui, Rua XV e S. Carlos” e nós que representariam as contas (com valores para o número da conta e o saldo) como, por exemplo, o nó com valor “7556, 3.000” (vide Figura 13). Neste modelo, a necessidade de representar contas conjuntas levaria à duplicação de registros, devido à representação em árvore. Por exemplo, suponhamos que Silvia e Rui possuem a conta conjunta de número 7556 (vide Figura 12, os nós com o número da conta em negrito), para representar esse fato, o nó da conta corrente teve de ser duplicado para obedecer a regra que “cada filho só pode ter um único pai”.

(atributos), cada qual contendo somente um valor. Os registros são conectados uns aos outros por meio

Figura 12 - Exemplo de Modelo Hierárquico

(atributos), cada qual contendo somente um valor. Os registros são conectados uns aos outros por meio

Figura 13 - Representação dos nós usada no exemplo

Além de poder causar inconsistência de dados quando houver atualização e causar desperdício de espaço, outros problemas encontrados no modelo hierárquico são:

» Nem tudo pode ser representado como uma hierarquia; » Complexidade dos diagramas de estrutura de árvore; » Não pode haver ciclos no gráfico básico de um diagrama de estrutura de árvore; » Restrições à cardinalidade dos links (não pode haver ligações de muitos para muitos (N:M) e de muitos para um

(N:1));

» Ausência de facilidades de consultas declarativas (não há linguagem ou recurso específico para isso), logo a realização de consultas é uma atividade complexa; » Necessidade de navegação por ponteiros para acesso à informações;

O sistema comercial mais divulgado no modelo hierárquico foi o Information Management System (IMS) da IBM Corporation. O IMS é um dos mais antigos e mais amplamente utilizados sistema de bancos de dados. Os desenvolvedores deste sistema estão entre os primeiros a tratarem características como concorrência, recuperação, integridade e processamento eficiente de consultas. Além dele, outros bancos que usavam o modelo hierárquico foram: UNIVAC 1100, CDC 6000, CYBER 70 e 170.

Modelo de Dados em Redes

O modelo em redes surgiu como uma extensão ao modelo hierárquico, eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em várias associações. E que benefícios trás isso? Bem, isso faz com que seja possível construir relações menos restritivas entre os registros. No modelo em rede, os registros são organizados em grafos onde aparece um único tipo de associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os registros C e D é possível construir um relacionamento M:N (muitos para muitos) entre A e D, o que não era possível no modelo hierárquico. Adicionalmente, ao contrário do Modelo Hierárquico, em que qualquer acesso aos dados passa pela raiz (lembra do tal registro falso?), o modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz.

Dessa forma, no modelo em redes os registros são organizados no banco de dados por um conjunto arbitrário de grafos. Na Figura 14, podemos ver o mesmo exemplo de registros de clientes e contas apresentado antes como exemplo do modelo hierárquico, agora sendo representados pelo modelo em redes. Note que não há mais duplicação do registro que representa a conta 7556 em negrito na Figura 14), por ser permitida mais de uma ligação (o que não era possível no modelo hierárquico). Note também a ausência do registro falso (raiz).

» Nem tudo pode ser representado como uma hierarquia; » Complexidade dos diagramas de estrutura de

Figura 14 - Exemplo de Modelo em Rede

As restrições impostas pelo Modelo de Redes podem ser descritas como de ordem de Entrada e de Existência. Em relação às restrições de entrada citamos a obrigatoriedade de cada novo registro estar conectado ao conjunto indicado. Em relação a restrições de Existência podemos dizer que um componente de um tipo de registro pode existir de forma independente de outros desde que esteja conectado a algum outro registro fazendo parte de algum conjunto, ou sendo base de um novo conjunto. A identificação de um conjunto pode ser verificada através do esquema de ligação entre o registro pai e o registro filho, assim sendo, cada instância de conjunto apresenta um elemento de distinção, o tal registro pai, e os registros filhos devidamente ordenados e, portanto, passíveis de serem acessados pelos seus elementos.

Alguns problemas do modelo em redes são:

» O modelo de rede é fortemente dependente da implementação.

» As consultas são complicadas: o programador é forçado a pensar em termos de links e, em como percorrê-los para obter as informações de que necessita. Essa manipulação de dados é chamada navegacional.

No Modelo em Rede o sistema comercial mais divulgado é o CAIDMS da Computer Associates. Além dele, há o DBMS10, o IDS II, o DMS II e o IMAGE

Segunda Geração dos Bancos de Dados

Nos anos 70 e 80, com os dispositivos de acesso direto aos dados, surgem os sistemas indexados e de processamento transacional (cada operação deve ser realizada, se não o for, deve ser desfeita, esse é o conceito de transação).

Nos anos 80, foram lançadas as bases do modelo relacional (dando origem à segunda geração) que impulsionou o uso e abriu caminho para todos os SGBDs atuais.

Modelo de Dados Relacional

O modelo relacional apareceu devido às seguintes necessidades:

» aumentar a independência de dados nos sistemas gerenciadores de banco de dados; » prover um conjunto de funções apoiadas em álgebra relacional para armazenamento e recuperação de dados; » permitir processamento ad-hoc

O Modelo Relacional (MR) é considerado o primeiro modelo de dados efetivamente usado em aplicações comerciais. Foi introduzido por Codd em 1970. É o modelo que possui a base mais formal entre os modelos de dados, entretanto é o mais simples e com estrutura de dados mais uniforme. O modelo relacional tem como base a teoria dos conjuntos e a álgebra relacional.

A estrutura fundamental do modelo relacional é a relação (tabela). Na verdade, o modelo é composto por uma coleção de tabelas de nomes únicos. Cada relação ou tabela é constituída por uma ou mais colunas chamadas de atributos (campos) que são os tipos dos dados contidos na relação. O conjunto de valores passíveis de serem assumidos por um atributo será intitulado de domínio. Cada linha da relação é chamada de tupla (registro). O esquema de uma relação nada mais é do que os campos (colunas) existentes em uma relação ou tabela. Já a instância da relação consiste no conjunto de valores que cada atributo assume em um determinado instante. As relações não podem ser duplicadas (por exemplo, não podem existir dois estados de Pernambuco, no conjunto de estados brasileiros) e a ordem de entrada de dados no Banco de Dados não deverá ter qualquer importância para as relações, no que concerne ao seu tratamento.

Diferentemente dos modelos que o precederam o modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados. Os relacionamentos entre as tabelas são feitos através do uso de valores de atributos. Por exemplo, na Figura 15, a Tabela de Empregados precisa usar valores que estão, originalmente, na tabela de Departamentos (o atributo ou campo chamado Cod_Depto). Isso causa a necessidade de um relacionamento entre as tabelas.

» As consultas são complicadas: o programador é forçado a pensar em termos de links e,

Figura 15 - Exemplo de Relacionamento no Modelo Relacional

Para trabalhar com tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como:

Repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações. Veremos em detalhes isso tudo no volume II da disciplina. O modelo relacional faz uso da linguagem SQL para definição e manipulação de dados (discutiremos sobre a linguagem SQL, em detalhes, no volume III da disciplina).

Alguns exemplos de banco de dados que fazem uso desse modelo são: PostGreSQL, Oracle, SQLServer, MySql, entre outros.

Terceira Geração dos Bancos de Dados

Devido às necessidades do mundo moderno de manipular dados complexos, surgiu a terceira geração dos bancos de dados, com os modelos de dados orientados a objetos e os modelos de dados objeto-relacionais. E o que eles trouxeram de novo? Vamos ver a seguir.

Modelo de Dados Orientado a Objetos

Os bancos de dados orientados a objeto começaram a se tornar comercialmente viáveis em meados de 1980. A motivação para seu surgimento está em função dos limites de armazenamento e representação semântica impostas no modelo relacional. Um exemplo de modelo orientado a objetos são os sistemas de informações geográficas (SIG) que são mais facilmente construídos usando tipos complexos de dados. A habilidade para criar os tipos de dados necessários é uma característica das linguagens de programação orientadas a objetos.

Contudo, estes sistemas necessitam guardar representações das estruturas de dados que utilizam no armazenamento permanente. A estrutura padrão para os bancos de dados orientados a objetos foi feita pelo Object Database Management Group (ODMG).

Esse grupo é formado por representantes dos principais fabricantes de banco de dados orientados a objeto disponíveis comercialmente. Membros do grupo têm o compromisso de incorporar o padrão em seus produtos. O termo Modelo de Dados Orientado a Objetos é usado para documentar o padrão que contém a descrição geral das facilidades de um conjunto de linguagens de programação orientadas a objetos e a biblioteca de classes que pode formar a base para o Sistema de Banco de Dados.

Quando os bancos de dados orientados a objetos foram introduzidos, algumas das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado.

Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serão usados em aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes.

Alguns exemplos de banco de dados que fazem uso desse modelo são: O2, OBJECTSTORE, Caché e IRIS.

O diagrama de classes UML, usado na análise orientada a objetos, serve geralmente como o esquema para o modelo de dados orientado a objetos (vide exemplo para o problema dos registros de clientes e contas, que já foi utilizado para ilustrar os modelos hierárquico e em rede, na Figura 16).

Repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são:

Figura 16 - Exemplo de Modelo de Dados Orientado a Objetos

Alguns problemas do modelo orientado a objetos são: ele não tem base teórica (formalismo) como os modelos anteriores e não existe linguagem padronizada para acesso e manipulação dos dados (tal qual o SQL). Isso fez com que esse paradigma não fosse aceito no mercado. Como solução surgiu o paradigma objeto-relacional.

Modelo de Dados Objeto-Relacional

A área de atuação dos sistemas Objeto-Relacional tenta suprir a dificuldade dos sistemas relacionais convencionais, que é o de representar e manipular dados complexos, visando ser mais representativos em semântica e construções de modelagens. Neste modelo de dados, toda a informação persistente está ainda nas tabelas, mas algumas das entradas da tabela podem ter uma estrutura de dados mais rica, denominada tipos abstratos de dados (TAD). Um TAD é um tipo de dado que é construído combinando tipos de dados alfanuméricos básicos. Um suporte para tipos de dados abstratos é atrativo porque as operações e funções associadas com o novo tipo podem ser usadas para indexar, armazenar, e recuperar registros baseados no índice do novo tipo de dado (por exemplo, multimídia).

Diferente do modelo orientado a objetos, o modelo objeto-relacional foi desenvolvido com base no modelo relacional. Dessa forma, foi possível unir conceitos de OO (tais como: supertabelas, supertipos, herança, reutilização de códigos de criação, encapsulamento, controle de identidade de objetos e referência a objetos) com conceitos do modelo relacional (tais como: capacidade de consulta avançada e a alta proteção a dados). Assim, os modelos Objeto- Relacional combinam os benefícios do modelo Relacional com a capacidade de modelagem do modelo OO.

A linguagem de consulta objeto relacional é uma extensão da linguagem SQL para suportar o modelo de objetos. As extensões incluem consultas envolvendo objetos, atributos multivalorados, TADs, métodos e funções como predicados de busca em uma consulta.

Alguns motivos que levam a utilização desse tipo de modelo são:

» A incapacidade do modelo relacional básico de resolver os desafios e atender as necessidades das novas aplicações; » A capacidade de armazenar novos tipos de dados; » Fornecem suporte para consultas complexas sobre dados complexos » Atendem aos requisitos das novas aplicações e da nova geração de aplicações de negócios

Algumas aplicações para as quais é necessário o uso desse tipo de modelo são:

» Armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital); » Dados complexos não-convencionais em projeto de engenharia; » Grandes informações sobre o genoma biológico; » Projetos de arquitetura; » Dados de séries temporais em transações; » Dados sobre o espaço (regiões geográficas, criação de mapas); » Sistemas móveis e distribuídos, dentre outros.

Alguns bancos de dados que fazem uso do modelo objeto-relacional são Oracle 9i, DB2/6000, ILUSTRA e CA-Ingres.

Arquiteturas de Sistemas de Banco de Dados

A arquitetura dos sistemas de banco de dados é influenciada pela arquitetura dos sistemas computacionais, levando em consideração aspectos como:

» Redes de computadores – cujo surgimento colaborou para a divisão de tarefas entre máquinas remotas, em que uma assume papel de cliente e outra de servidor, levando a uma arquitetura cliente-servidor;

» Paralelismo – que consiste na possibilidade de executar atividades simultaneamente, obtendo melhores tempos de resposta e executando uma maior quantidade de transações por segundo;

» Distribuição – em que os dados residem na localidade em que são gerados ou em que serão mais úteis, por meio de diversas cópias do banco de dados. Uma arquitetura distribuída possibilita uma maior disponibilidade dos dados, que podem ser acessados ainda que uma determinada localidade enfrente problemas e se torne indisponível.

Como consequência do emprego desses aspectos, temos as arquiteturas centralizadas, cliente-servidor, distribuída e paralela que será descrito a seguir.

Arquiteturas Centralizadas

As primeiras arquiteturas usavam mainframes6 para executar o processamento principal e de todas as funções do sistema, incluindo os programas aplicativos, programas de interface com o usuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de processamento, apenas a capacidade de visualização (esses terminais eram muitas vezes chamados de terminais- burros, justamente por não terem poder de processamento). Ou seja, todos os processamentos eram feitos remotamente, apenas as informações a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualização (também chamados de nós), conectados a ele por uma rede de comunicação (vide Figura

17).

Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por computadores pessoais (PCs) e estações de trabalho (tais como as estações unix). No começo os SGBDs usavam esses computadores da mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de programas aplicativos e processamento da interface do usuário eram executados em apenas uma máquina (a que centralizava tudo). A arquitetura centralizada tem como principais vantagens: permitir que muitos usuários manipulem grande volume de dados e que, com os dados totalmente isolados, se ganha consideravelmente em segurança, visto que o acesso aos dados é feito somente em um único local. E a sua principal desvantagem é a total dependência de um único sistema, podendo ocasionar uma elevada indisponibilidade em caso de falhas deste.

Como consequência do emprego desses aspectos, temos as arquiteturas centralizadas, cliente-servidor, distribuída e paralela que será

Figura 17 - Esquema de um BD Centralizado

Com o desenvolvimento de computadores pessoais com maior capacidade de processamento, parte do controle da aplicação e interface junto ao usuário, que antes era de total responsabilidade do sistema centralizado, passou a ser realizado pelos computadores pessoais, cabendo ao sistema centralizado apenas satisfazer às solicitações geradas pelos sistemas clientes. Assim, gradualmente, os SGBDs começaram a explorar a disponibilidade do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor, que veremos a seguir.

Arquitetura Cliente-Servidor

A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um grande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos são conectados juntos por uma rede.

A ideia é definir servidores especializados, tais como servidor de arquivos (que mantém os arquivos de máquinas clientes) ou servidores de impressão (que podem estar conectados a várias impressoras), assim, quando se desejar imprimir algo, todas as requisições de impressão são enviadas a este servidor. As máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento para executar aplicações locais. Esta arquitetura se tornou muito popular por algumas razões.

» Primeiro, a facilidade de implementação dada à clara separação das funcionalidades e dos servidores;

» Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples são delegadas às máquinas clientes, que são mais baratas; » Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés de usar a interface do servidor.

Diferentes técnicas foram propostas para implementar essa arquitetura, sendo que a mais adotada pelos SGBDs relacionais comerciais é a inclusão da funcionalidade de um SGBD centralizado no lado do servidor. A realização de consultas e a funcionalidade transacional (você lembra do que é uma transação?) permanecem no servidor, sendo que este é chamado de servidor de consulta ou servidor de transação. É assim que um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas (usando a linguagem SQL), prover a interface para o usuário e as funções da interface usando uma linguagem de programação. Comumente, o servidor SQL também é chamado de back-end machine e a máquina cliente de front-end machine.

Resumindo com outras palavras, na arquitetura Cliente-Servidor, o cliente (front_ end machine) executa as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela e processamento de entrada e saída), ferramentas de relatório, geração de formulários, análise e mineração de dados. Já o servidor (back_end machine) executa as consultas no SGBD e retorna os resultados ao cliente, ficando responsável por tarefas como o controle de acesso, otimização de consultas, controle de concorrência, recuperação, etc. Como SQL provê uma linguagem padrão para os SGBDs Relacionais, esta criou o ponto de divisão lógica entre o cliente e o servidor. Dessa forma, a comunicação entre a front-end machine e o back-end machine é realizada por meio da linguagem SQL e por meio de uma API7 que possibilita a conexão e a comunicação entre as máquinas cliente e servidora. Exemplos de APIs são os padrões ODBC8, JDBC9 que vão justamente servir para a comunicação de programas escritos em uma linguagem de programação com os SGBDs. Quando um programa escrito em uma linguagem de programação faz uso de uma API (tudo isso no lado do cliente) para acesso a um banco de dados que está em uma máquina servidora (vide Figura 18), dizemos que se está usando uma arquitetura clienteservidor de 2 camadas. Ou seja, a comunicação é direta do cliente para o servidor. Já a arquitetura cliente-servidor em três camadas, conta com a máquina cliente na qual um navegador web, atua como front-end junto ao usuário para acessar um servidor de aplicação (também conhecido como servidor Web). Esse servidor de aplicação atua em uma camada intermediária (a segunda camada), processando as solicitações dos usuários e fornecendo respostas obtidas através do acesso ao servidor de banco de dados (que é a terceira camada), que continua sendo o responsável pela realização de consultas e transações no SGBD. Sistemas que lidam com grande quantidade de usuários adotam essa arquitetura em três camadas.

» Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples são delegadas às máquinas

Figura 18 - Esquema de uma arquitetura em 2 camadas

» Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples são delegadas às máquinas

Figura 19 - Esquema de uma arquitetura em 3 camadas

24

A principal vantagem da arquitetura cliente-servidor é a divisão do processamento entre dois ou mais sistemas, o que reduz o tráfego de dados na rede.

Arquitetura Distribuída

A tecnologia de Banco de Dados Distribuídos (BDDs) surgiu como uma intercalação de duas tecnologias: tecnologia de banco de dados e tecnologia de comunicação de dados e de rede. Com as novas tecnologias de comunicação de dados, atendendo à necessidade da descentralização, é possível se trabalhar com bancos de dados não mais centralizados em um servidor, mas sim distribuídos em vários servidores. Podendo esses servidores estar na mesma rede, assim como podem estar em países diferentes, compartilhando informações de uma maneira transparente para os usuários. Assim, em um sistema de banco de dados distribuídos, o banco de dados é armazenado em diversos computadores, que se comunicam uns com os outros através de vários meios de comunicação, tais como redes de alta velocidade ou linhas de telefone, em que cada qual pode participar na execução de transações que acessam dados em um ou diversos nós (vide Figura 20).

A principal vantagem da arquitetura cliente-servidor é a divisão do processamento entre dois ou mais sistemas,

Figura 20 - Esquema de um banco de dados distribuído

Nesta arquitetura, cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos aplicativos são feitas para qualquer servidor indistintamente. Caso a informação solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informação necessária, de maneira transparente para o aplicativo, que passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos típicos são as bases de dados corporativas, em que o volume de informação é muito grande e, por isso, deve ser distribuído em diversos servidores.

De forma simplificada, pode-se dizer que a principal diferença entre sistemas de bancos de dados centralizados e distribuídos é que no primeiro os dados estão localizados em um único lugar, enquanto no último os dados residem em diversos locais. Um dos motivos para distribuir um banco de dados é que um banco de dados distribuído além de ser mais confiável, tem a capacidade de resolver da melhor maneira os problemas grandes e complexos com os quais nos defrontamos hoje, usando uma variação da regra de dividir e conquistar. Ou seja, problemas complicados podem ser resolvidos simplesmente dividindo-os em fragmentos menores e atribuindo-os a grupos de software distintos, que funcionem em computadores diferentes, produzindo um sistema que atue sobre vários elementos de processamento. Esses grupos de software devem colaborar de forma eficaz para a execução de uma tarefa em comum. Outros motivos para distribuir são:

» Disponibilidade – pois se um site “sai do ar”, os demais sites podem continuar em operação. Isso é devido ao fato que, como os dados são replicados em vários nós, uma transação que necessita de um particular item de dado pode encontrá-lo em qualquer outro nó. Com isso, a falha de um nó não necessariamente implica na parada de funcionamento de um sistema, aumentando a confiabilidade e disponibilidade do sistema.

» Desempenho otimizado – o desempenho otimizado dos SGBDs distribuídos se baseia em dois pontos: Um SGBD distribuído fragmenta o banco de dados, permitindo que os dados fiquem armazenados próximos a seus pontos de utilização, reduzindo o atraso de acesso remoto, além disso, cada site manipula apenas uma parte do banco de dados,

tornando a administração deste mais simples. O paralelismo inerente de sistemas distribuídos pode ser explorado para se obter paralelismo entre consultas e intraconsulta, assim é possível executar várias consultas ao mesmo tempo e o paralelismo intraconsulta é alcançado desmembrando uma única consulta em várias subconsultas que serão executadas em locais diferentes.

» Facilidade de Expansão – um sistema distribuído pode crescer mais facilmente que um sistema centralizado. Se for necessário expandir o sistema porque o volume de dados cresceu ou o volume de processamento aumentou, é mais fácil acrescentar um novo nó à rede de computadores, desde que os nós sejam autônomos, do que substituir um sistema centralizado já existente por outro maior.

Porém, tudo na vida tem pontos positivos e negativos. Dessa forma, nos sistemas distribuídos há um acréscimo de complexidade para assegurar a coordenação entre os sites e há um custo para desenvolver os softwares de aplicação e gerenciamento do sistema como um todo.

Arquitetura Paralela

Sistemas gerenciadores de bancos de dados paralelos são compostos por diversos processadores, memórias e discos, utilizados em aplicações críticas, que necessitam lidar com quantidades muito grandes de dados e oferecer baixos tempos de resposta. A arquitetura paralela é adequada aos seguintes casos:

» Quando é necessário consultar bancos de dados extremamente grandes (na ordem de terabytes); » Quando é necessário processar um número muito grande de transações por segundo (na ordem de milhares de transações por segundo).

Existem vários modelos de arquitetura paralela. São eles:

» Memória compartilhada – Em um modelo de memória compartilhada, diversos processadores acessam uma única memória, por meio de barramento ou rede de interconexão (vide Figura 21). Esse modelo tem como vantagem o fato de que os processadores podem trocar rapidamente mensagens entre si através da memória comum. E possui como desvantagem o fato que o modelo não pode ser expandido a um número superior a 32 ou 64 processadores, visto que o barramento ou a rede de interconexão entre processadores e memória se tornaria um gargalo e os processadores passariam mais tempo aguardando pela sua vez para acessar memória do que realizando o processamento.

tornando a administração deste mais simples. O paralelismo inerente de sistemas distribuídos pode ser explorado para

Figura 21 - Esquema do modelo paralelo de memória compartilhada

» Disco compartilhado – No modelo de disco compartilhado (vide Figura 22), todos os processadores acessam todos os discos diretamente por meio de uma rede de interconexão, contudo, cada processador possui sua própria memória privada e exclusiva. Esse modelo tem como vantagens o fato de que, como cada processador possui sua própria memória, não há problemas de gargalo de acesso à memória e pode-se maximizar o número de processadores utilizados. Além disso, há uma boa tolerância a falhas, visto que caso um processador falhe, todos os demais continuarão trabalhando normalmente e acessando os dados nos discos compartilhados de forma natural. Como desvantagem, temos que, em relação ao modelo de memória compartilhada, a troca de mensagens entre os processadores é muito mais lenta, uma vez que é necessário que as mensagens trafeguem pela rede de interconexão (tanto para acessar o disco, como para haver a comunicação entre os processadores).

Figura 22 – Esquema do modelo paralelo de disco compartilhado » Nenhum compartilhamento – Neste modelo

Figura 22 – Esquema do modelo paralelo de disco compartilhado

» Nenhum compartilhamento – Neste modelo (vide Figura 23), cada nó possui seus próprios discos, processador e memória, comunicando-se com os demais nós por meio de uma rede de interconexão de alta velocidade. Aqui, cada nó assume o papel de servidor em relação aos demais nós, oferecendo como serviço o acesso aos dados que estão em seus discos. A vantagem é que esse modelo é altamente escalável, podendo admitir facilmente uma grande quantidade de processadores. A desvantagem é que o custo para comunicação e acesso aos dados em discos não locais é muito maior que nos modelos de memória e discos compartilhados, visto que, além de ser necessária a transmissão por rede, também há a interação entre os softwares, em ambas as extremidades.

Figura 22 – Esquema do modelo paralelo de disco compartilhado » Nenhum compartilhamento – Neste modelo

Figura 23 - Esquema do modelo paralelo sem compartilhamento

» Hierárquico – este modelo combina características do modelo de memória compartilhada, disco compartilhado e com nenhum compartilhamento. Em um nível superior, pode-se ter nós que não compartilham memória ou discos entre si, trabalhando em um modelo “sem nenhum compartilhamento”, porém, cada nó poderia ser um sistema de memória compartilhada entre dois ou mais processadores. Ou seja, no nível mais alto os nós são conectados por uma rede, sem compartilhar recursos. E, no nível mais baixo, cada nó é constituído de sistemas de compartilhamento (vide Figura 24).

Figura 22 – Esquema do modelo paralelo de disco compartilhado » Nenhum compartilhamento – Neste modelo

Figura 24 - Esquema de modelo paralelo hierárquico

Arquitetura Mono-Usuário

Aqui, o banco de dados encontra-se no mesmo computador em que são executadas as aplicações e não há múltiplos usuários. Geralmente utilizada com computadores pessoais, no começo esse processamento era bastante limitado,

porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o padrão Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, possuem um único aplicativo a ser executado na máquina. A principal vantagem desta arquitetura é a simplicidade.

Abstração de Dados

Abstrair dados significa omitir a complexidade do sistema de modo a facilitar a interação dos usuários com ele. Como um dos principais objetivos de um SGBD é simplificar a interação do usuário com o sistema, ele deve prover uma visão abstrata dos dados, ou seja, omitir detalhes de como os dados são armazenados e mantidos. Na verdade, uma das características fundamentais da abordagem de banco de dados é que ela fornece algum nível de abstração de dados, pela omissão de detalhes de armazenamento de dados que não são necessários para a maioria dos usuários. O modelo de dados é a principal ferramenta que fornece esta abstração.

Um Modelo de Dados é um conjunto de conceitos que podem ser usados para descrever a estrutura do banco de dados. Por estrutura do banco de dados entendem-se os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.

Em qualquer modelo de dados é importante distinguir entre a descrição do banco de dados e o banco de dados propriamente dito. A descrição de um banco de dados é chamada Esquema do Banco de Dados. Um esquema de banco de dados é especificado durante o projeto deste banco, sendo que a expectativa de mudanças não é grande. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo.

Os dados existentes em um banco de dados podem mudar com relativa frequência. Os dados contidos em um banco de dados em um momento específico do tempo são chamados Instâncias do Banco de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de Base-Intencional e uma instância é chamada de Base- Extensional do esquema.

Para prover abstração um SGBD provê a definição de esquemas em três níveis (vide Figura 25): o nível de visão, o nível conceitual e o nível físico. Estes níveis facilitam a manutenção do sistema e a interação dos usuários com os sistemas. Vamos detalhar mais cada um deles a seguir.

porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam

Figura 25 - Níveis de Abstração providos por um SGBD

» O nível físico – também chamado nível interno, possui um esquema interno que descreve como os dados estão de fato armazenados no(s) disco(s) rígido(s) (ex: formato dos registros, ordem em que aparecem, etc). Ou seja, descreve a estrutura de armazenamento físico dos dados do BD, fornecendo um modelo físico dos dados que inclui detalhes sobre os caminhos de acesso aos dados internamente. Os desenvolvedores de Banco de Dados devem ter noção desse

nível.

» O nível conceitual – também chamado nível lógico, é um nível médio de abstração e possui um esquema conceitual que descreve quais dados estão armazenados no banco de dados e quais são os interrelacionamentos entre eles. Ou seja, descreve a estrutura de todo o BD para uma determinada comunidade de usuários, ocultando detalhes sobre a organização física dos dados e apresentando a descrição lógica dos dados e das ligações existentes entre eles. Esse esquema se concentra na descrição de entidades, tipos de dados, relacionamentos e restrições. É a visão dos administradores de banco de dados e dos programadores.

» O nível de visão – também chamado nível externo, possui esquemas externos ou visões dos usuários. Ele é o mais alto nível de abstração. Cada esquema externo descreve a visão do banco de dados de um grupo de usuários deste banco. Cada visão descreve, tipicamente, a parte do banco de dados que um grupo particular de usuários está interessado e esconde deste o restante do banco de dados. Ou seja, vai existir uma visão diferente para cada grupo de usuários finais. Ele descreve apenas parte do BD, pois os usuários normalmente não precisam conhecer todo o banco, eles acabam utilizando apenas parte dele.

Essa divisão em níveis é conhecida como arquitetura “Three-Schema” (também conhecida como arquitetura ANSI/SPARC) e foi proposta por Tsichritzis & Klug em 1978. A meta desta arquitetura é separar as aplicações de usuários do banco de dados físico (meio que deixar “cada macaco no seu galho”)

Como os três níveis apresentam descrições diferentes para os mesmos dados, torna-se necessário converter uma representação em outra, ou seja, definir mapeamentos de dados entre os níveis.

Esses mapeamentos são mantidos pelo DBA.

Muitos SGBDs não separam os três níveis completamente. Pode acontecer que alguns SGBDs incluam detalhes do nível interno no esquema conceitual. Em muitos SGBDs que permitem visões, os esquemas externos são especificados com o mesmo modelo de dados usado no nível conceitual.

Estes três níveis podem ser utilizados para explicar conceitos de independência de dados. Mas o que é independência de dados? Independência de dados se refere à imunidade de aplicativos dos usuários a mudanças na definição e na organização de dados, e vice-versa. Em outras palavras, ela pode ser definida como a capacidade de alterar o esquema de um nível de abstração sem ter que alterar o esquema do próximo nível superior. Você só vai ter ideia da importância disso quando começar realmente a manipular um banco de dados!

Pode-se dividir a independência de dados em dois tipos: a independência de dados lógica e a independência de dados física.

A independência de dados lógica é a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas externos (nível de visão) ou programas de aplicação que fazem uso do banco de dados. Pode-se mudar o esquema conceitual para expandir o banco de dados, com a adição de novos tipos de registros (ou itens de dados), ou reduzir o banco de dados removendo um tipo de registro. Neste último caso, esquemas externos que se referem apenas aos dados remanescentes (que não foram alterados) não devem ser afetados. Assim é possível modificar a organização conceitual com impacto mínimo nas aplicações (construídas sobre os esquemas externos ou visões).

A independência de dados física é a capacidade de alterar o esquema interno (nível físico) sem ter que alterar o esquema conceitual (nível lógico). Mudanças no esquema interno podem ser necessárias devido a alguma reorganização de arquivos físicos para melhorar o desempenho nas recuperações e/ou modificações. Após a reorganização, se nenhum dado foi adicionado ou perdido, não haverá necessidade de modificar o esquema conceitual. Em outras palavras, a independência de dados física lida com a ocultação dos detalhes da estrutura de armazenamento em relação aos aplicativos do usuário, ou seja, quando um aplicativo é escrito, ele não deve se preocupar com os detalhes da organização física dos dados. Assim, é possível modificar as estruturas de armazenamento sem impactar nas aplicações que fazem uso do BD.