Apostila Completa

BD I
BANCO DE DADOS I
Versão 2007/2
Bancos de Dados I
Índice
1. Introdução ______________________________________________________________ 4
1.1. Dado_______________________________________________________________ 4
1.2. Informação __________________________________________________________ 4
1.3. A Informação como Recurso da Empresa __________________________________ 5
2. Organização de Arquivos __________________________________________________ 6
2.1. Conceitos ___________________________________________________________ 6
2.2. Estruturas de Arquivos _________________________________________________ 8
2.2.1. Arquivo seqüencial ________________________________________________ 8
2.2.2. Arquivo seqüencial-indexado _______________________________________ 10
2.2.3. Arquivo indexado_________________________________________________ 11
2.2.4. Arquivo direto ___________________________________________________ 12
3. Bancos de Dados _______________________________________________________ 13
3.1. Banco de Dados (BD)_________________________________________________ 13
3.2. Sistema de Gerência de Banco de Dados (SGBD) __________________________ 14
3.2.1. Processamento de Dados sem Banco de Dados ________________________ 14
3.2.2. Processamento de dados com uso de SGBD ___________________________ 15
3.2.3. Principais Componentes de um Sgbd _________________________________ 15
3.2.4. Características de um SGBD _______________________________________ 16
3.3. Abstração de Dados __________________________________________________ 18
3.4. Modelos de Bancos de Dados __________________________________________ 18
3.5. Independência de Dados ______________________________________________ 19
3.6. Funções relacionadas ao SGBD ________________________________________ 19
3.6.1. Administrador de Dados ___________________________________________ 19
3.6.2. Administrador de Banco de Dados ___________________________________ 20
3.6.3. Projetista da Base de Dados ________________________________________ 22
3.6.4. Analista de Sistemas______________________________________________ 22
3.7. Arquiteturas para uso do SGBD _________________________________________ 23
A ANSI divide a arquitetura de banco de dados em 3 níveis distintos: _______________ 23
3.7.1. Nível Externo____________________________________________________ 23
3.7.2. Nível Conceitual _________________________________________________ 24
3.7.3. Nível Interno ____________________________________________________ 25
3.7.4. Mapeamento ____________________________________________________ 26
3.7.5. Arquitetura Cliente/Servidor ________________________________________ 26
3.7.6. Mono-usuário ___________________________________________________ 29
3.7.7. Multiusuário com Processamento Central ______________________________ 29
3.7.8. Arquitetura em Rede com Servidor de Arquivos _________________________ 29
3.7.9. Arquitetura Cliente/Servidor ________________________________________ 29
3.8. Fases do Projeto de Banco de Dados ____________________________________ 29
3.8.1. Construir o Modelo Conceitual ______________________________________ 29
3.8.2. Construir o Modelo Lógico__________________________________________ 29
3.8.3. Construir o Modelo Físico __________________________________________ 30
3.8.4. Avaliar o Modelo Físico ____________________________________________ 30
3.8.5. Implementar o BD ________________________________________________ 30
4. Modelagem de Dados ____________________________________________________ 30
4.1. Conceitos __________________________________________________________ 30
4.2. Tipos de Abstração___________________________________________________ 31
4.2.1. Classificação ____________________________________________________ 31
4.2.2. Agregação ______________________________________________________ 31
4.2.3. Generalização ___________________________________________________ 31
4.3. Requisitos para Modelagem de Dados____________________________________ 31
4.4. Modelos Conceituais _________________________________________________ 31
4.5. Modelos Lógicos_____________________________________________________ 31
4.5.1. Modelo Hierárquico _______________________________________________ 32
4.5.2. Modelo de Rede _________________________________________________ 33
4.5.3. Modelo Relacional________________________________________________ 34
4.6. Modelo de Dados Físico_______________________________________________ 35
5. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.) ____________________________ 36
5.1. Introdução _________________________________________________________ 36
5.2. Entidade ___________________________________________________________ 36
5.2.1. Regras para Atribuição de Nomes a Entidades__________________________ 37
5.3. Relacionamento _____________________________________________________ 37
5.3.1. Auto-relacionamento ______________________________________________ 38
5.3.2. Cardinalidade de Relacionamentos___________________________________ 39
5.3.3. Cardinalidade Máxima_____________________________________________ 39
5.3.4. Classificação de Relacionamentos Binários ____________________________ 40
5.3.5. Relacionamento ternário ___________________________________________ 41
5.3.6. Cardinalidade mínima _____________________________________________ 42
5.4. Notações Alternativas_________________________________________________ 42
5.5. Atributo ____________________________________________________________ 43
5.5.1. Domínio ________________________________________________________ 43
5.5.2. Tipos de Atributos ________________________________________________ 44
5.5.3. Atributo de Relacionamento ________________________________________ 44
5.5.4. Identificador de Entidades __________________________________________ 44
5.5.5. Relacionamento Identificador (Entidade Fraca) _________________________ 45
5.5.6. Identificador de Relacionamentos ____________________________________ 45
5.6. Generalização/Especialização __________________________________________ 45
5.7. Entidade Associativa (Agregação) _______________________________________ 47
5.8. Relacionamento Mutuamente Exclusivo___________________________________ 49
5.9. Restrição de Persistência no Relacionamento ______________________________ 49
5.9.1. Normalização ___________________________________________________ 50
5.9.2. Anomalias de Atualização __________________________________________ 51
5.9.3. Terminologia ____________________________________________________ 52
5.9.4. Notação para as Estruturas de Dados ________________________________ 53
5.9.5. Esquema da Normalização _________________________________________ 55
5.9.6. Relações Não-Normalizadas________________________________________ 56
5.9.7. Primeira Forma Normal (1FN) _______________________________________ 57
5.9.8. Escolha da Chave Primária _________________________________________ 58
5.9.9. Segunda Forma Normal (2FN) ______________________________________ 60
5.9.10. Terceira Forma Normal (3FN) _____________________________________ 61
Bancos de Dados I
1. INTRODUÇÃO
Temos observado ao longo dos nossos anos de experiência no desenvolvimento de sistemas
de informação, que existe uma grande dificuldade dos analistas e programadores em
entenderem a diferença entre INFORMAÇÃO e DADO.
1.1. DADO
O DADO é uma representação, um registro de uma informação. Este DADO pode ser
registrado fisicamente através de um papel (receita médica), um disco de computador ou um
impulso elétrico, etc. Este registro pode ser o originador de uma série de processos que
influenciam na realidade observada (salvar a vida de um paciente, tocar um alarme, etc.). Um
DADO tem as seguintes características:
Representação de um evento do mundo físico, de um fato ou de uma idéia;
Representação de uma propriedade ou característica de um objeto real;
Não tem significado por si só;
Ex.: quantidade de Kwh consumidos em uma residência.
1.2. INFORMAÇÃO
A INFORMAÇÃO acrescenta algo ao conhecimento da realidade a ser analisada. Por

exemplo, a dosagem que um paciente precisa receber de um determinado remédio, é uma
INFORMAÇÃO. Este conhecimento pode ser (ou não) modelado (registrado). A
INFORMAÇÃO também pode apresentar as seguintes características:
Organização e agregação dos dados, permitindo uma interpretação;
Informação é a interpretação dos dados;
Ex: Consumo de energia comparado com a capacidade geradora da usina.
Identificados
Dados Organizados geram Informação
Agrupados
Armazenados
Recuperados
Bancos de Dados I - 4
1.3. A INFORMAÇÃO COMO RECURSO DA EMPRESA
2. ORGANIZAÇÃO DE ARQUIVOS
2.1. CONCEITOS
• Estruturas de Dados: define a forma como os dados estão organizados, como se
relacionam e como serão manipulados pelos programas. Ex: vetores e matrizes, registros,
filas, pilhas, árvores, grafos, etc.
• Arquivo: coleção de registros lógicos, cada um deles representando um objeto ou entidade.

Na prática os arquivos geralmente estão armazenados na memória secundária (fitas e
discos) e são usados para armazenar os resultados intermediários de processamento ou
armazenar os dados de forma permanente.
• Registro lógico (registro): Um registro é constituído por conjunto de campos valorados

(contendo dados). Consiste na unidade de armazenamento e recuperação da informação
em um arquivo. Geralmente, os registros de um arquivo possuem um formato padrão
(layout), definido pela seqüência, tipo e tamanho dos campos que o compõem. Porém,
algumas linguagens de programação permitem a criação de registros com layouts diferentes
em um mesmo arquivo, recurso este que raramente é utilizado.
• Campo: É a unidade básica formadora de um registro. Constitui a célula da informação. É a

menor porção de um arquivo que pode ser referenciada por um programa. Cada campo
possui NOME, TIPO DE DADO e TAMANHO;
• Bloco: unidade de armazenamento do arquivo em disco, também denominado registro

físico. Um registro físico normalmente é composto por vários registros lógicos. Cada bloco
armazena um número inteiro de registros;
• Chave: é uma seqüência de um ou mais campos em um arquivo;
• Chave primária ou Primary Key: A Chave Primária (ou simplesmente CHAVE) é o

identificador único de um registro em um arquivo. Pode ser constituída de um campo
(CHAVE SIMPLES) ou pela combinação de dois ou mais campos (CHAVE COMPOSTA),
de tal maneira, que não existam dois registros no arquivo com o mesmo valor de chave
primária. Em regra, todo arquivo deve possuir uma chave primária, que permita a
identificação inequívoca do registro, especialmente, para dar maior consistência aos
processos de inclusão, alteração e exclusão de dados. Para que não ocorram duplicatas
nos valores da chave, os campos que a compõem são de PREENCHIMENTO
OBRIGATÓRIO (NOT NULL). Na escolha da chave primária de um arquivo deve-se buscar
campos que possuam ESTABILIDADE no valor armazenado. A escolha do NÚMERO DO
TELEFONE como chave de um cadastro de clientes, por exemplo, seria inadequada, por
que esse valor pode mudar com freqüência. Sem considerar que o cliente pode ter mais de
um telefone. Deve-se também evitar a escolha de campos que possam causar
AMBIGÜIDADE em relação aos valores nele contidos. Nesse sentido, seria inadequada a
escolha do campo NOME para chave de um cadastro de clientes, haja vista, que um
mesmo nome pode ser escrito de várias formas. Por exemplo: LUÍS, LUIZ, LOUIS, LOYS,
LUYS. Se desejássemos cobrar uma fatura de um cliente com um nome como esse, a
probabilidade de erramos o cliente seria grande. Além disso, a extensão do campo (30 ou
mais caracteres) é um outro aspecto que aumenta a possibilidade de erros.
• Chave secundária: A chave secundária pode ser formada por um campo ou pela
combinação de campos (SIMPLES / COMPOSTA). Ë utilizada como parâmetro (filtro) para
seleção de registros no arquivo em consultas, emissão de relatórios ou processos de
atualização simultânea de um grupo de registros. Por exemplo, para aumentarmos o valor
do salário dos analistas em 10%, poderíamos utilizar o campo FUNÇÃO do arquivo
CADASTRO DE FUNCIONÁRIOS como parâmetro (chave secundária) no processo de
seleção dos registros a serem alterados. Em síntese, a chave secundária é o campo ou
combinação de campos do arquivo que permite a recuperação de mais de um registro no
arquivo. Portanto, não possui a característica de unicidade proposta para a chave primária.
• Chave de acesso: é uma chave usada para identificar o(s) registro(s) desejado(s) em uma
operação de acesso ao arquivo.
• Chave Estrangeira ou Foreign Key: É um atributo ou conjunto de atributos cujos valores

aparecem necessariamente na chave primária de uma tabela. Este mecanismo permite a
implementação de relacionamentos no modelo relacional.
Exemplo:
Departamento (CodDep, NomeDepto)
Empregado(CodEmp, NomeEmp, CodDepto, CatFunc)
2.2. ESTRUTURAS DE ARQUIVOS
2.2.1. ARQUIVO SEQÜENCIAL

Nos arquivos seqüenciais a ordem lógica e física dos registros armazenados é a mesma. Os
registros podem estar dispostos seguindo a seqüência determinada por uma chave primária
(chamada chave de ordenação), ou podem estar dispostos aleatoriamente.
# Numero Nome Idade Salário

0 1000 ADEMAR 25 600
1 1050 AFONSO 27 700
2 1075 CARLOS 28 500
3 1100 CESAR 30 1000
4 1150 DARCI 23 1500
5 1180 EBER 22 2000
6 1250 ENIO 27 750
7 1270 FLAVIO 28 600
8 1300 IVAN 30 700
9 1325 MIGUEL 34 1000
10 1340 MARIA 35 1500
11 1360 RAMON 32 2000
12 1400 SANDRA 29 700
13 1450 TATIANA 30 500
a) Acesso a um registro
Podemos considerar dois tipos de acesso: seqüencial ou aleatório.

• O acesso seqüencial consiste em acessar os registros na ordem em que estão
armazenados, ou seja, o registro obtido é sempre o posterior ao último acessado. Como os
registros são armazenados em sucessão contínua, acessar o registro “n” de um arquivo
requer a leitura dos “n-1” registros anteriores.
• O acesso aleatório se caracteriza pela utilização de um “argumento de pesquisa” (chave

de acesso), que indica qual o registro desejado. Neste caso, a ordem em que os registros
são acessados pode ser diferente da ordem em que eles estão armazenados fisicamente.
Se o arquivo está ordenado e a chave de acesso coincide com a chave de ordenação,
podemos utilizar a pesquisa binária. Caso contrário, deve ser realizada uma pesquisa
seqüencial no arquivo.
b) Inserção de um registro
Se o arquivo não está ordenado, o registro pode ser simplesmente inserido após o último
registro armazenado. Se o arquivo está ordenado, normalmente é adotado o seguinte
procedimento: Dado um arquivo base B, é construído um arquivo de transações T, que contem
os registros a serem inseridos, ordenados pela mesma chave que o arquivo B. Os arquivos B
e T são então intercalados, gerando o arquivo A, que é a versão atualizada de B.
Arquivo B Arquivo T Arquivo A

# Num Nome Idade # Num Nome Idade # Num Nome Idade
0 1000 ADEMAR 25 0 1070 ANGELA 25 0 1000 ADEMAR 25
1 1050 AFONSO 27 1 1120 CLAUDIA 27 1 1050 AFONSO 27
2 1075 CARLOS 28 2 1280 IARA 28 2 1070 ANGELA 25
3 1100 CESAR 30 3 1310 LUIS 30 3 1075 CARLOS 28
4 1150 DARCI 23 4 1420 SONIA 23 4 1100 CESAR 30
5 1180 EBER 22 5 1120 CLAUDIA 27
6 1250 ENIO 27 6 1150 DARCI 23
7 1270 FLAVIO 28 7 1180 EBER 22
8 1300 IVAN 30 8 1250 ENIO 27
9 1325 MIGUEL 34 9 1270 FLAVIO 28
10 1340 MARIA 35 10 1280 IARA 28
11 1360 RAMON 32 11 1300 IVAN 30
12 1400 SANDRA 29 12 1310 LUIS 30
13 1450 TATIANA 30 13 1325 MIGUEL 34
14 1340 MARIA 35
15 1360 RAMON 32
16 1400 SANDRA 29
17 1420 SONIA 23
18 1450 TATIANA 30
c) Exclusão de um registro
Normalmente é implementada como a inserção, com a criação de um arquivo de transações

que contém os registros a serem excluídos, que é processado posteriormente. Pode ainda ser
implementada através de um campo adicional no arquivo que indique o estado (status) de
cada registro. Na exclusão, o valor deste campo seria alterado para “excluído”.
Posteriormente, é feita a leitura seqüencial de todos os registros, sendo que os registros que
não estiverem marcados como “excluídos” são copiados para um novo arquivo.
d) Alteração de um registro
Consiste na modificação do valor de um ou mais atributos de um registro. O registro deve ser

localizado, lido e os campos alterados, sendo gravado novamente, na mesma posição. A
alteração é feita sem problemas, desde que ela não altere o tamanho do registro nem
modifique o valor de um campo usado como chave de ordenação.
2.2.2. ARQUIVO SEQÜENCIAL-INDEXADO
Quando o volume de acessos aleatórios em um arquivo seqüencial torna-se muito grande, é

necessário utilizar uma estrutura de acesso que ofereça maior eficiência na localização de um
registro com base em uma chave de acesso. O arquivo seqüencial-indexado é um arquivo
seqüencial acrescido de uma estrutura de acesso (índice). Um índice é formado por uma
coleção de pares, associando um valor da chave de acesso a um endereço de registro. Deve
existir um índice específico para cada chave de acesso.
Índice Primário Índice Secundário Arquivo

# Num End. # Num End. # Num Nome Idade
0 1300 0 0 1070 0 0 1000 ADEMAR 25
1 1605 3 1 1200 3 1 1050 AFONSO 27
2 ** 6 2 1300 6 2 1070 ANGELA 25
** Maior valor que a chave 3 1430 9 3 1075 CARLOS 28
pode assumir 4 1520 12 4 1100 CESAR 30
5 1605 15 5 1200 CLAUDIA 25
6 1710 18 6 1250 CRISTIE 26
7 1745 21 7 1275 DARCI 29
8 ** 24 8 1300 DIOGO 25
** Maior valor que a chave 9 1310 ELBER 27
pode assumir 10 1400 EDISON 25
11 1430 EDMUNDO 28
12 1470 ENIO 30
13 1510 FLAVIO 25
14 1520 GENARO 26
15 1530 GERSON 29
16 1590 HELENA 25
17 1605 IARA 27
18 1650 IVAN 25
19 1700 LUIS 28
20 1710 MARIA 30
21 1730 MIGUEL 25
22 1740 RAMON 26
23 1745 SANDRA 29
24 1800 SONIA 32
25 1905 TATIANA 34
26 2010 WILSON 20
2.2.3. ARQUIVO INDEXADO
O arquivo indexado é aquele em que os registros são acessados através de um ou mais
índices, não havendo qualquer compromisso com a ordem em que os registros estão
armazenados. Podem existir tantos índices quantas forem às chaves de acesso aos registros.
As entradas no índice são ordenadas pelo valor das chaves de acesso, sendo cada uma delas
constituída por um par (chave do registro, endereço do registro).
Índice Arquivo
Num End. # Num Nome Idade Salário
1000 1 0 2010 WILSON 26 1000
1050 13 1 1000 ADEMAR 32 250
1070 2 2 1070 ANGELA 28 300
1075 16 3 1200 CLAUDIA 25 750
1100 22 4 1300 DIOGO 24 400
1200 3 5 1400 EDISON 22 1500
1250 10 6 1510 FLAVIO 30 250
1275 19 7 1590 HELENA 26 300
1300 4 8 1650 IVAN 32 750
1310 14 9 1730 MIGUEL 28 400
1400 5 10 1250 CRISTIE 25 1500
1430 17 11 1520 GENARO 24 750
1470 23 12 1740 RAMON 22 400
1510 6 13 1050 AFONSO 30 1500
1520 11 14 1310 ELBER 26 250
1530 20 15 1605 IARA 32 300
1590 7 16 1075 CARLOS 28 750
1605 15 17 1430 EDMUNDO 26 400
1650 8 18 1700 LUIS 32 1500
1700 18 19 1275 DARCI 26 750
1710 24 20 1530 GERSON 26 400
1730 9 21 1745 SANDRA 32 400
1740 12 22 1100 CESAR 28 1500
1745 21 23 1470 ENIO 25 750
1800 25 24 1710 MARIA 24 400
1905 26 25 1800 SONIA 22 750
2010 0 26 1905 TATIANA 30 400
2.2.4. ARQUIVO DIRETO
A idéia básica de um arquivo direto é o armazenamento dos registros em endereços
determinados com base no valor de uma chave primária, de modo que se tenha acesso rápido
aos registros especificados por argumentos de pesquisa, sem que haja necessidade de
percorrer uma estrutura de índice. Em um arquivo direto ao invés de um índice é usada uma
função que calcula um endereço de registro a partir do argumento de pesquisa.
Arquivo
# Num Nome Idade Salário
0 2010 WILSON 26 1000
1
2 1070 ANGELA 28 300
C=’CLAUDIA’ E=F(C) E=3 3 1200 CLAUDIA 25 750
4 1300 DIOGO 24 400

5
6
7
8 1650 IVAN 32 750
9 1730 MIGUEL 28 400
10 1250 CRISTIE 25 1500
11
12
13 1050 AFONSO 30 1500
14
15 1800 SONIA 22 750
...
O principal problema associado com os arquivos diretos é o da determinação de uma função F,

que transforme o valor C da chave de um registro no endereço E, que lhe corresponde no
arquivo. Geralmente são usadas “funções probabilísticas” que geram, para cada valor da
chave, um endereço “tão único quanto possível”, podendo gerar, para valores distintos da
chave, o mesmo endereço. Este fato é denominado “colisão”, e devem ser estabelecidos
procedimentos para tratá-lo.
Exercício
1. Defina com suas palavras a diferença entre Bancos de dados e Sistemas
Gerenciadores de Bancos de dados.
2. Dê exemplos de arquivos, registros e campos.
3. Simule a criação de um banco de dados. Este banco deverá conter 3 tabelas. Defina o
conceito de chave primária, secundária e estrangeira para as tabelas criadas.
3. BANCOS DE DADOS
Introdução
No início da década de 60, foram lançados os primeiros sistemas gerenciadores de banco de dados (SGBD),
tendo como principal proposta o aumento na produtividade nas atividades de desenvolvimento e manutenção de
sistemas, até então realizadas de forma artesanal em linguagens de programação convencionais de primeira e
segunda geração. Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares e amigáveis com
o advento da microinformática. Cada vez mais as fronteiras entre esses dois mundos estreitam-se e a
concorrência pelo domínio do mercado de SGBD, tem levado seus diversos fabricantes a sofisticarem seus
produtos. Cada nova versão lançada incorpora novidades como interfaces gráficas, ferramentas de apoio ao
desenvolvimento, utilitários para gerenciamento de BD e facilidades para extração de dados. Essa evolução vem
tornando o trabalho de programadores, analistas e usuários menos artesanal, com reflexos na qualidade e
produtividade.
3.1. BANCO DE DADOS (BD)
Um Banco de Dados (BD) pode ser definido como uma coleção de dados inter-relacionados,
armazenados de forma centralizada ou distribuída, com redundância controlada, para servir a
uma ou mais aplicações. Coleção de dados inter-relacionados, que representam informações
sobre um domínio específico; Ex.: Agenda telefônica, Base de dados de uma empresa, Acervo
de uma biblioteca.
3.2. SISTEMA DE GERÊNCIA DE BANCO DE DADOS (SGBD)
Conjunto de software para gerenciar (definir, criar, modificar, usar) um BD e garantir a
integridade e segurança dos dados. O SGBD é a interface entre os programas de aplicação e
o BD. Em inglês é denominado DataBase Managementm System (DBMS).
3.2.1. PROCESSAMENTO DE DADOS SEM BANCO DE DADOS

Dados de diferentes aplicações não estão integrados, pois são projetados para atender a uma
aplicação específica.
Problemas da falta de integração de dados:

• O mesmo objeto da realidade são múltiplas vezes representado na base de dados.
Exemplo: dados de um produto em uma indústria.
• Redundância não controlada de dados: Não há gerência automática da redundância, o que
leva a inconsistência dos dados devido a redigitação de informações.
• Dificuldade de extração de informações: os dados são projetados para atender aplicações
especificas gerando dificuldades para o cruzamento de informações.
• Dados pouco confiáveis e de baixa disponibilidade.
3.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD

Os dados usados por uma comunidade de usuários são integrados no Banco de Dados. Cada
informação é armazenada uma única vez, sendo que as eventuais redundâncias são
controladas pelo sistema em computador, ficando transparentes para os usuários.
3.2.3. PRINCIPAIS COMPONENTES DE UM SGBD
• Dicionário de dados (Data Dictionary): Descreve os dados e suas relações em forma

conceitual e independente de seu envolvimento nas diversas aplicações. Fornece
referências cruzadas entre os dados e as aplicações.
• Linguagem de definição de dados (DDL - Data Definition Language): Descreve os

dados que estão armazenados no BD. As descrições dos dados são guardadas em um
“meta banco de dados”.
• Linguagem de acesso (DML - Data Manipulation Language): Usada para escrever as

instruções que trabalham sobre a base de dados, permitindo o acesso e atualização dos
dados pelos programas de aplicação. Geralmente integrada com a DDL.
• Linguagem de consulta (QUERY): Permite que o usuário final, com poucos

conhecimentos técnicos, possa obter de forma simples, informações do BD.
• Utilitários administrativos: Programas auxiliares para carregar, reorganizar, adicionar,
modificar a descrição do BD, obter cópias de reserva e recuperar a integridade física em
caso de acidentes.
3.2.4. CARACTERÍSTICAS DE UM SGBD

Um princípio básico em BD determina que cada item de dado deveria ser capturado apenas
uma vez e então armazenado, de modo que possa tornar disponível para atender a qualquer
necessidade de acesso a qualquer momento. Alguns pontos importantes são:
• Independência dos dados: O SGBD deve oferecer isolamento das aplicações em

relação aos dados. Esta característica permite modificar o modelo de dados do BD sem
necessidade de reescrever ou recompilar todos os programas que estão prontos. As
definições dos dados e os relacionamentos entre os dados são separados dos códigos
os programas. Mais de 80% do tempo dos analistas e programadores é gasto na
manutenção de programas. A principal causa deste elevado tempo reside na falta de
independência entre dados e programas.
• Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturas de dados

complexas, os arquivos devem ser projetados para atender a diferentes necessidades,
permitindo desenvolver aplicações melhores, mais seguras e mais rapidamente. Deve
possui comandos poderosos em sua linguagem de acesso.
• Integridade dos dados: O SGBD deve garantir a integridade dos dados, através da
implementação de restrições adequadas. Isto significa que os dados devem ser precisos
e válidos.
• Redundância dos dados: O SGBD deve manter a redundância de dados sob controle,
ou seja, ainda que existam diversas representações do mesmo dado, do ponto de vista
do usuário é como se existisse uma única representação. No processamento tradicional
de arquivos, cada grupo de usuários deve manter seu próprio conjunto de arquivos e
dados. Desta forma, acaba ocorrendo redundâncias que prejudicam o sistema com
problemas como:
• Toda vez que for necessário atualizar um arquivo de um grupo, então todos os
grupos devem ser atualizados para manter a integridade dos dados no ambiente
como um todo;
• A redundância desnecessária de dados leva ao armazenamento excessivo de

informações, ocupando espaço que poderia estar sendo utilizado com outras
informações.
• Segurança e privacidade dos dados: O SGBD deve assegurar que estes só poderão
ser acessados ou modificados por usuários autorizados.
• Rápida recuperação após falha: Os dados são de importância vital e não podem ser
perdidos. Assim, o SGBD deve implementar sistemas de tolerância a falhas, tais como
estrutura automática de recover e uso do conceito de transação.
• Uso compartilhado: Um SGBD multiusuário deve permitir que múltiplos usuários

acessem o banco de dados ao mesmo tempo. Este fator é essencial para que múltiplas
aplicações integradas possam acessar o banco. O SGBD multiusuário deve manter o
controle de concorrência para assegurar que os resultados de atualizações sejam
corretos. Um banco de dados multiusuário deve fornecer recursos para a construção de
múltiplas visões.
• Controle do espaço de armazenamento: O SGBD deve manter controle das áreas de

disco ocupadas, evitando a ocorrência de falhas por falta de espaço de armazenamento.
• Restrição a Acesso não Autorizado: Um SGBD deve fornece um subsistema de

autorização e segurança, 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.
• Representação de Relacionamentos Complexos entre Dados: Um banco de dados

pode incluir uma variedade de dados que estão inter-relacionados de várias formas. Um
SGBD deve fornecer recursos para se representar uma grande variedade de
relacionamentos entre os dados, bem como, recuperar e atualizar os dados de maneira
prática e eficiente.
• Tolerância a Falhas: Um SGBD deve fornecer recursos para recuperação de falhas
tanto de software quanto de hardware.
3.3. ABSTRAÇÃO DE DADOS

Um propósito central de um SGBD é proporcionar aos usuários uma visão abstrata dos
dados, isto é, o sistema esconde certos detalhes de como os dados são armazenados ou
mantidos. No entanto, os dados precisam ser recuperados eficientemente. A preocupação
com a eficiência leva a concepção de estruturas de dados complexas para representação dos
dados no BD. Porém, uma vez que SGBD são freqüentemente usados por pessoas sem
treinamento na área de computação, esta complexidade precisa ser escondida dos usuários.
Isto é conseguido definindo-se diversos níveis de abstração pelos quais o BD pode ser visto:
• NÍVEL FÍSICO: É o nível mais baixo de abstração, no qual se descreve como os dados são
armazenados. Estruturas complexas, de baixo nível, são descritas em detalhe.
• NÍVEL CONCEITUAL: É o nível onde se descreve quais os dados são realmente

armazenados no BD e quais os relacionamentos existentes entre eles. Este nível descreve
o BD como um pequeno número de estruturas relativamente simples. Muito embora a
implementação de estruturas simples no nível conceitual possa envolver estruturas
complexas no nível físico, o usuário do nível conceitual não precisa saber disto.
• NÍVEL VISÃO: Este é o nível mais alto de abstração, no qual se expõe apenas parte do
BD. Na maioria das vezes os usuários não estão preocupados com todas as informações do
BD e sim com apenas parte delas (Visões dos Usuários).
3.4. MODELOS DE BANCOS DE DADOS

Um modelo de (banco de) dados é uma descrição dos tipos de informações que estão
armazenadas em um banco de dados, ou seja, é a descrição formal da estrutura de BD. Estes
modelos podem ser escritos em linguagens textuais ou linguagens gráficas. Cada
apresentação do modelo é denominada de “esquema de banco de dados”. Se tomarmos
como exemplo uma indústria, o modelo de dados deve mostrar que são armazenadas
informações sobre produtos, tais como código, descrição e preço. Porém o modelo de dados
não vai informar quais produtos estão armazenados no Banco de Dados.
No projeto de um banco de dados, geralmente são considerados 3 modelos: conceitual, lógico
e físico.
• Modelo conceitual: É uma descrição mais abstrata da base de dados. Não contém
detalhes de implementação e é independente do tipo de SGBD usado. É o ponto de
partida para o projeto da base de dados.
• Modelo Lógico: É a descrição da base de dados conforme é vista pelos usuários do

SGBD (programadores e aplicações). É dependente do tipo de SGBD escolhido, mas
não contém detalhes da implementação (uma vez que o SGBD oferece abstração e
independência de dados).
• Modelo físico (interno): Descrição de como a base de dados é armazenada

internamente. Geralmente só é alterada para ajuste de desempenho. A tendência dos
produtos modernos é ocultar cada vez mais os detalhes físicos de implementação.
3.5. INDEPENDÊNCIA DE DADOS
• Independência de dados a nível físico: a capacidade de se modificar o modelo físico, sem

precisar reescrever os programas de aplicação.
• Independência dados a nível lógico: a capacidade de se modificar o esquema lógico, sem

a necessidade de reescrever os programas de aplicação. Modificações no nível lógico são
necessárias sempre que a estrutura lógica do BD for alterada. Em alguns casos a
recompilação pode ser requerida.
3.6. FUNÇÕES RELACIONADAS AO SGBD
3.6.1. ADMINISTRADOR DE DADOS
• Gerenciar o dado como um recurso da empresa.

• Planejar, desenvolver e divulgar as bases de dados da empresa.
• Permitir a descentralização dos processos, mas manter centralizado os dados.
• Permitir fácil e rápido acesso as informações a partir dos dados armazenados.
• O grande objetivo de administrador de dados é permitir que vários usuários compartilhem os
mesmos dados. Deste modo, os dados não pertencem a nenhum sistema ou usuário de
forma específica, e sim, à organização como um todo. Assim, o administrador de dados se
preocupa basicamente com a organização dos dados e não com o seu armazenamento.
3.6.2. ADMINISTRADOR DE BANCO DE DADOS
O administrador do banco de dados (DBA), já mencionado é a pessoa (ou grupo de pessoas)

responsável pelo controle do sistema. As responsabilidades do DBA incluem o seguinte:
• Decidir o conteúdo de informações do banco de dados
Faz parte do trabalho do DBA decidir exatamente que informação manter no banco de dados -
em outras palavras, deve identificar as entidades do interesse da empresa e a informação a
registrar em relação a estas entidades. Uma vez feito isto, o DBA deve então definir o conteúdo
do banco de dados, descrevendo o esquema conceitual (usando 0 DDL conceitual). A forma
objeto (compilado) daquele esquema é utilizada pelo DBMS para responder às solicitações de
acesso. A forma (não compilada) atua como documento de referência para os usuários do
sistema.
• Decidir a estrutura de armazenamento e a estratégia de acesso
O DBA também deve decidir como os dados serão representados no banco de dados, e definir
esta representação escrevendo a definição da estrutura de armazenamento (usando a DDL
interna). Além disso, deve definir o mapeamento associado entre os níveis interno e conceitual.
Na prática, tanto a DDL conceitual quanto a DDL interna - mais provavelmente a primeira -
provavelmente incluirão os meios de definição desse mapeamento, mas as duas funções (a
definição do esquema, a definição do mapeamento) devem ser claramente separadas. Tal
como o esquema conceitual, o esquema interno e o mapeamento correspondente existirão não
só na forma-fonte como na forma objeto.
• Servir de elo de ligação com usuários
É função do DBA servir de elo de ligação com os usuários, a fim de garantir a disponibilidade
dos dados de que estes necessitam, e prepará-los ou auxiliá-los na preparação dos
necessários esquemas externos, utilizando a DDL externa apropriada (como já mencionamos,
um determinado sistema pode suportar diversas DDLs externas e distintas). E, ainda, também
deve ser definido o mapeamento entre qualquer esquema externo e o esquema conceitual. Na
prática, a DDL externa provavelmente incluirá os meios de especificação do mapeamento, mas
o esquema e o mapeamento devem ser claramente separados. Cada esquema externo e o
mapeamento correspondente existirão tanto na forma fonte como na forma objeto.
• Definir os controles de segurança e integridade
Os controles de segurança e de integridade, como já mencionado, podem ser considerados

parte do esquema conceitual. A DDL conceitual incluirá os recursos para a especificação de
tais controles.
• Definir a estratégia de reserva e recuperação
A partir do momento em que a empresa começa efetivamente a basear-se em banco de dados,

torna-se dependente do bom funcionamento deste sistema. Na eventualidade de danos à parte
do banco de dados - causados, digamos, por erro humano, ou por falha no hardware, ou nó
sistema operacional de suporte -, é de suma importância fazer retornar os dados envolvidos
com um mínimo de demora e com as menores conseqüências ao restante do sistema. Por
exemplo, os dados que não sofreram danos não deverão ser afetados.' O DBA deve definir e
implementar uma estratégia de recuperação apropriada envolvendo, por exemplo, o
descarregamento periódico do banco de dados na memória auxiliar de armazenamento e
procedimentos para recarregá-lo, quando necessário.
• Monitorar o desempenho e atender as necessidades de modificações.
O DBA deve organizar o sistema de tal maneira que obtenha "o melhor desempenho para a
empresa"; e efetuar os ajustes adequados quanto às necessidades de modificações. Como já
mencionamos, quaisquer mudanças nos detalhes de armazenamento e acesso devem ser
acompanhadas de mudanças correspondentes na definição do mapeamento, a partir do nível
conceitual, de forma que o esquema conceitual possa permanecer constante.O DBA,
evidentemente, irá precisar de diversos programas utilitários como auxílio às tarefas
precedentes. Estes são uma parte essencial de um sistema de banco de dados prático, embora
não sejam mostrados na Figura 5 da arquitetura. Listamos abaixo alguns exemplos dos
programas utilitários necessários.
• Rotinas de carga (para criar uma versão inicial do banco de dados a partir de um ou
mais arquivos).
• Rotinas de despejo na memória e recuperação (despejar o banco de dados, auxiliar de
armazenamento de dados, e recarregar o banco de dados a partir dessa cópia de
segurança). Observação: As rotinas de carga mencionadas acima consistirão, na
prática, no aspecto de "recuperação" das rotinas de despejo/recuperação na memória.
Rotinas de reorganização (para rearrumar os dados no banco de dados, em vista de
diversas razões de desempenho - por exemplo, agrupar os dados de certa maneira ou
regenerar espaço ocupado por dados que se tornaram obsoletos).
• Rotinas estatísticas (para computar diversos desempenhos estatísticos, tamanhos de

arquivos e distribuição de valores de dados). Rotinas analíticas (para analisar as
estatísticas mencionadas). Uma das ferramentas mais importantes do DBA - de muitas
maneiras e, de fato, o coração de todo o sistema, embora não mostrado na Figura 5 - é
o dicionário de dados (conhecido também como catálogo do sistema). O dicionário de
dados pode ser considerado um banco de dados (mas um banco de dados de sistema, e
não propriamente um banco de dados de usuário). O conteúdo do dicionário pode ser
considerado "dados sobre dados" (às vezes denominado "metadados") - ou seja,
descrições de outros objetos no sistema, ao invés de simples "dados em bruto". Os
diversos esquemas e mapeamentos (externo, conceitual etc.), especialmente, serão
fisicamente armazenados, ambos na forma-fonte e na forma objeto, no dicionário. Um
dicionário abrangente também incluirá referências cruzadas das informações, mos-
trando, por exemplo, que programas utilizam tal parte do banco de dados, que
departamentos necessitam de tais relatórios, que terminais estão conectados ao
sistema, e assim por diante. O dicionário também pode (e deveria) estar integrado ao
banco de dados que descreve, incluindo, portanto, a sua própria descrição. Deveria ser
possível consultar-se o dicionário, tal como qualquer outro banco de dados, de maneira
que fosse possível indicar os programas e/ou usuários que seriam afetados por eventual
mudança no sistema.
3.6.3. PROJETISTA DA BASE DE DADOS

Constrói o modelo conceitual de uma parte da base de dados, com a participação do usuário.
Junto com o DBA integra as novas partes ao banco de dados global.
3.6.4. ANALISTA DE SISTEMAS

Define e projeta aplicação que irão usar a base de dados existente. Utiliza o modelo conceitual
e o modelo lógico existentes, mas não define os dados da base de dados.
3.7. ARQUITETURAS PARA USO DO SGBD
A ANSI DIVIDE A ARQUITETURA DE BANCO DE DADOS EM 3 NÍVEIS DISTINTOS:
1. Nível Externo – Nível do usuário

2. Nível Interno – Nível físico
3. Nível Conceitual – Nível de conjunto de visões de usuários. Faz a ligação entre os
outros
dois.
3.7.1. NÍVEL EXTERNO
O nível externo é o nível do usuário individual. Um determinado usuário tanto pode ser
um programador de aplicações como um usuário de terminal on-line - i.e., um usuário final - de
qualquer grau de sofisticação. O DBA é um caso especial importante. Ao contrário do usuário
comum, o DBA terá de se interessar pelos níveis conceitual e interno também. Cada usuário
tem uma linguagem à sua disposição:
• Esta linguagem, para o programador de aplicação, pode ser uma linguagem
convencional de programação, como COBOL ou PL/I, ou uma linguagem de
programação apropriada, específica do sistema em questão (sistemas NOMAD,
Rdv/VMS ou dBase II).
• Para o usuário final, pode ser uma linguagem de consulta ou uma linguagem de
propósitos especiais, talvez baseadas em formulários ou menu, modelada às
necessidades do usuário e suportada por um programa de aplicação on-line.
Para nossos propósitos, o que importa é sabermos que todas essas linguagens incluirão
uma sublinguagem de dados - ou seja, um subconjunto de toda a linguagem, voltado para os
objetivos e operações do banco de dados. A sublinguagem de dados (DSL) é embutida na
linguagem hospedeira correspondente, a qual proporciona os diversos recursos não-
específicos de banco de dados, tais como variáveis locais (temporárias), operações
computacionais, lógica if-then-else e assim por diante. Determinados sistemas podem suportar
múltiplas linguagens hospedeiras e múltiplas sublinguagens de dados.
3.7.2. NÍVEL CONCEITUAL
A visão conceitual é uma representação de todo o conteúdo de informações do banco de

dados, mais uma vez (como no caso de uma visão externa) em uma forma um tanto abstrata
em comparação com o modo como os dados são armazenados fisicamente. Em geral, ela
também será bastante diferente do modo como os dados são visualizados por qualquer usuário
em particular. A visão conceitual consiste em muitas ocorrências de cada um dos vários tipos
de registros conceituais. Por exemplo, ela pode consistir em uma coleção de ocorrências de
registros de departamentos, somada a uma coleção de ocorrências de registros de
empregados, mais uma coleção de ocorrências de registros de fornecedores, somada a uma
coleção de ocorrências de registros de peças (etc. etc.). Um registro conceitual não é
necessariamente o mesmo que um registro externo, nem o mesmo que um registro
armazenado. Na visão conceitual não haverá nenhuma informação física, como ponteiros ou
índices de acesso. Neste nível, deverão existir todas as restrições de segurança e integridade
de dados.Na maior parte dos sistemas existentes, o "esquema conceitual" é na verdade pouco
mais que uma simples reunião de todos os esquemas externos individuais, somados a certas
restrições de segurança e integridade. Porém, sem dúvida, é possível que sistemas futuros
eventualmente sejam muito mais sofisticados em seu suporte do nível conceitual.
3.7.3. NÍVEL INTERNO
O terceiro nível da arquitetura é o nível interno. A visão interna é uma representarão de baixo
nível do banco de dados por inteiro; ela consiste em muitas ocorrências de cada um dos vários
tipos de registros internos. "Registro interno" é o termo ANSI/SPARC que representa a
construção que temos chamado de registro armazenado (e continuaremos a usar essa última
forma). A visão interna é descrita por meio do esquema interno, que não somente define os
diversos tipos de registros armazenados, mas também especifica quais índices existem, como
os campos armazenados estão representados, em que seqüência física está o registro
armazenado, e assim por diante. Para encerrar lembramos que, em certas situações
excepcionais, os programas aplicativos - em particular as aplicações de natureza utilitária -
podem ter permissão para operar diretamente no nível interno, e não no nível externo. Não é
preciso dizer que essa prática não é recomendável; ela representa um risco de segurança (pois
as restrições de segurança são ignoradas) e um risco de integridade (pois também as
restrições de integridade são ignoradas), e o programa terá uma inicialização dependente dos
dados; porém, às vezes essa poderá ser a única maneira de obter a funcionalidade ou o
desempenho exigido - do mesmo modo o usuário em uma linguagem de programação de alto
nível poderia ter a necessidade ocasional de descer até a linguagem assembler para satisfazer
certos objetivos de funcionalidade ou desempenho.
3.7.4. MAPEAMENTO
Além dos três níveis básicos, esta arquitetura envolve certos mapeamentos: um mapeamento
conceitual/interno e vários mapeamentos externos/conceitual:
• O mapeamento conceitual/interno define a correspondência entre a visão conceitual e o
banco de dados armazenado;
• Um mapeamento externo/conceitual define a correspondência entre uma visão externa
específica e a visão conceitual.
A propósito, a maioria dos sistemas permite que a definição de certas visões externas seja
expressa em termos de outras (efetivamente, através de mapeamentos externos/externos), em
vez de sempre exigir uma definição explícita do mapeamento no nível conceitual - um recurso
útil se diversas visões externas forem bastante semelhante. Em particular, os sistemas
relacionais oferecem essa capacidade.
3.7.5. ARQUITETURA CLIENTE/SERVIDOR
Descrevemos até agora neste capítulo os sistemas de bancos de dados sob o ponto de vista
da chamada arquitetura ANSI/SPARC. Nesta seção, examinaremos os sistemas de bancos de
dados sob uma perspectiva um pouco diferente. Naturalmente, o objetivo geral desses
sistemas é fornecer suporte ao desenvolvimento e à execução de aplicações de bancos de
dados. Portanto, sob um ponto de vista de mais alto nível, um sistema de banco de dados pode
ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um
servidor (também chamado hack end) e um conjunto de clientes (também chamados front
ends).
• O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBDs. Tais como:
definição de dados, manipulação de dados, segurança e integridade e dados, e assim por
diante. Em particular, ele oferece todo o suporte de nível externo, conceitual e interno que
examinamos anteriormente. Assim, o termo "servidor" neste contexto é tão somente um outro
nome para o SGBD.
• Os clientes são as diversas aplicações executadas sobre o SGBD. Tanto aplicações escritas
por usuários quanto aplicações internas, ou seja, aplicações fornecidas pelo fabricante do
SGBD ou por produtores independentes. No que se refere ao servidor, é claro que não existe
nenhuma diferença entre aplicações escritas pelo usuário e aplicações internas todas elas
empregam a mesma interface para o servidor.
Usuário Final
iMac
Aplicações Cliente
SGBD Servidor
BD Banco de Dados
Vamos aprofundar o exame da questão de aplicações escritas pelo usuário versus aplicações
fornecidas pelo fabricante:
• Aplicações escritas pelo usuário são basicamente programas aplicativos comuns, escritos
(em geral) em uma linguagem de programação convencional de terceira geração (L3G),
como C ou COBOL, ou então em alguma linguagem proprietária de quarta geração (L4G) -
embora em ambos os casos a linguagem precise ser de algum modo acoplada a uma
sublinguagem de dados apropriada.
• Aplicações fornecidas por fabricante (chamadas freqüentemente de ferramentas - tools) são
aplicações cuja finalidade básica é auxiliar na criação e execução de outras aplicações! As
aplicações criadas são aplicações adaptadas a alguma tarefa específica (elas podem não
ser muito semelhante às aplicações no sentido convencional; de fato, a finalidade das
ferramentas é permitir aos usuários, em especial aos usuários finais, criar aplicações sem
ter de escrever programas em uma linguagem de programação convencional). Por exemplo,
uma das ferramentas fornecidas pelo fabricante será um gerador de relatórios, cuja
finalidade é permitir que os usuários finais obtenham relatórios formatados a partir do
sistema sob solicitação. Qualquer solicitação de relatório pode ser considerada um pequeno
programa aplicativo, escrito em uma linguagem de geração de relatórios de nível muito alto
(e finalidade especial).
As ferramentas fornecidas pelo fabricante podem ser divididas em diversas classes mais ou
menos distintas:
a. Processadores de linguagem de consulta.
b. Geradores de relatórios.
c. Subsistemas gráficos de negócios.
d. Planilhas eletrônicas.
e. Processadores de linguagem natural.
f. Pacotes estatísticos.
g. Ferramentas para gerenciamento de cópias ou "extração de dados".
h. Geradores de aplicações (inclusive processadores L4G).
i. Outras ferramentas para desenvolvimento de aplicações, inclusive produtos de
engenharia de software auxiliada pelo computador (CASE - computer-aided software
engineering).
Observamos que, tendo em vista que toda a importância de um sistema de banco de dados
está em dar suporte à criação e à execução de aplicações, a qualidade das ferramentas
disponíveis é, ou deve ser, um fator preponderante na "decisão sobre o banco de dados" (isto
é, o processo de escolha do produto de banco de dados apropriado). Em outras palavras, o
SGBD em si não é o único fator que precisa ser levado em consideração, nem mesmo é
necessariamente o fator mais significativo. Encerramos esta seção com uma referência para o
que se segue. Como o sistema por completo pode estar tão claramente dividido em duas
partes, servidores e clientes, surge a possibilidade de executar os dois em máquinas
diferentes. Em outras palavras, existe o potencial para o processamento distribuído. O
processamento distribuído significa que máquinas diferentes podem estar conectadas entre si
para formar algum tipo de rede de comunicações, de tal modo que uma única tarefa de
processamento de dados possa ser dividida entre várias máquinas na rede. Na verdade, essa
possibilidade é tão atraente - por uma variedade de razões, principalmente de ordem
econômica - que o termo "cliente/servidor" passou a se aplicar a quase exclusivamente ao caso
em que o cliente e o servidor estão de fato localizados em máquinas diferentes.
Exercícios
1. Explique os três níveis da arquitetura definida pela Ansi/Parc.
2. Qual é a função do mapeamento.
3. Explique a arquitetura Cliente/Servidor.
3.7.6. MONO-USUÁRIO
• BD está no mesmo computador que as aplicações;
• Não há múltiplos usuários;
• Recuperação geralmente através de backup;
• Típico de computadores pessoais;
3.7.7. MULTIUSUÁRIO COM PROCESSAMENTO CENTRAL

• BD está no mesmo computador que as aplicações;
• Múltiplos usuários acessando através de terminais;
• Típico de ambientes com mainframe;
3.7.8. ARQUITETURA EM REDE COM SERVIDOR DE ARQUIVOS

• Multiusuário;
• Servidor de arquivos contém todos os arquivos do banco de dados;
• As estações clientes executam as aplicações e o software de BD;
• Gera alto tráfego na rede;
• Típico de redes pequenas (peer-to-peer);
3.7.9. ARQUITETURA CLIENTE/SERVIDOR

• Multiusuário;
• Servidor dedicado ao Banco de Dados, executando o SGBD;
• As estações clientes executam apenas as aplicações;
• Tráfego na rede é menor;
• Arquitetura atualmente em uso;
3.8. FASES DO PROJETO DE BANCO DE DADOS
3.8.1. CONSTRUIR O MODELO CONCEITUAL
• Modelo de alto nível, independente da implementação;

• Etapa de levantamento de dados;
• Uso de uma técnica de modelagem de dados;
• Abstração do ambiente de hardware/software ;
3.8.2. CONSTRUIR O MODELO LÓGICO

• Modelo implementável, dependente do tipo de SGBD a ser usado;
• Considera as necessidades de processamento;
• Considera as características e restrições do SGBD;
• Etapa de normalização dos dados;
3.8.3. CONSTRUIR O MODELO FÍSICO

• Modelo implementável, com métodos de acesso e estrutura física;
• Considera necessidades de desempenho;
• Considera as características e restrições do SGBD;
• Dependente das características de hardware/software;
3.8.4. AVALIAR O MODELO FÍSICO

• Avaliar o desempenho das aplicações;
• Avaliar os caminhos de acesso aos dados e estruturas utilizadas;
3.8.5. IMPLEMENTAR O BD
• Etapa de carga (load) dos dados;
• Gerar as interfaces com outras aplicações;
4. MODELAGEM DE DADOS
4.1. CONCEITOS
• Abstração: processo mental através do qual selecionamos determinadas propriedades ou
características dos objetos e excluímos outras, consideradas menos relevantes para o
problema sendo analisado.
• Modelo: É uma abstração, uma representação simplificada, de uma parcela do mundo real,
composta por objetos reais.
• Modelagem: Atividade através da qual se cria um modelo.
• Modelo de dados: Um modelo de dados é uma descrição das informações que devem ser
armazenadas em um banco de dados, ou seja, é a descrição formal da estrutura de BD
(descrição dos dados, dos relacionamentos entre os dados, da semântica e das restrições
impostas aos dados).
4.2. TIPOS DE ABSTRAÇÃO
4.2.1. CLASSIFICAÇÃO
Os objetos do mundo real são organizados segundo suas propriedades ou características
comuns, formando classes de objetos. Um objeto pode pertencer simultaneamente a várias
classes.
4.2.2. AGREGAÇÃO
Uma classe é definida a partir de um conjunto de outras classes, que representam suas partes
componentes.
4.2.3. GENERALIZAÇÃO
Define uma nova classe a partir de características comuns de outras classes. A classe genérica
que reúne as características comuns é denominada superclasse e as classes que herdam
estas características são denominadas subclasses.
4.3. REQUISITOS PARA MODELAGEM DE DADOS

• Entender a realidade em questão, identificando os objetos que compõe a parte da realidade
que vai ser modelada;
• Representar formalmente a realidade analisada, construindo um modelo de dados;
• Estruturar o modelo obtido e adequá-lo ao SGBD a ser usado, transformando o modelo
conceitual em modelo lógico.
4.4. MODELOS CONCEITUAIS

São usados para descrição de dados no nível conceitual. Proporcionam grande capacidade de
estruturação e permitem a especificação de restrições de dados de forma explícita. Exemplos:
• Modelo Entidade-Relacionamento (M.E.R.);
• Modelo de Semântica de dados;
• Modelo Infológico;
• Modelos Orientados para Objetos (OO);
4.5. MODELOS LÓGICOS

São usados na descrição dos dados no nível lógico. Em contraste com modelos conceituais,
esses modelos são usados para especificar tanto a estrutura lógica global do BD como uma
descrição em alto nível da implementação.
4.5.1. MODELO HIERÁRQUICO
Um BD hierárquico é uma coleção de árvores de registros. Os registros são usados para
representar os dados e ponteiros são usados para representar o relacionamento entre os
dados, numa ligação do tipo pai-filho. A restrição é que um determinado registro somente pode
possuir um registro pai.
4.5.2. MODELO DE REDE
O BD em rede é um grafo, onde os nós representam os registros e os arcos representam os
relacionamentos entre os registros, através de ligações pai-filho. Diferente do modelo
hierárquico, um registro pode possuir diversos registros pai.
4.5.3. MODELO RELACIONAL
Um BD relacional possui apenas um tipo de construção, a tabela. Uma tabela é composta por
linhas (túplas) e colunas (atributos). Os relacionamentos entre os dados também são
representados ou por tabelas, ou através da reprodução dos valores de atributos.
4.6. MODELO DE DADOS FÍSICO
Usados para descrever os dados em seu nível mais baixo. Capturam os aspectos de
implementação do SGBD.
5. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)
5.1. INTRODUÇÃO
O MODELO DE ENTIDADE E RELACIONAMENTOS (MER), foi proposto originalmente por

PETER CHEN em 1976. Seu objetivo, ao publicar esse trabalho, era consagrar um método
eficiente para representar os dados e ressaltar a diferença entre as estruturas suportadas pelos
SGBD HIERÁRQUICOS, REDE e RELACIONAL. Atualmente o MER tem sido utilizado para
representar a visão dos dados no projeto de banco de dados. A principal vantagem do MER é
a simplicidade. O Modelo de Entidade e Relacionamento possui apenas três componentes
básicos: ENTIDADE, ATRIBUTO e RELACIONAMENTO (e seus respectivos símbolos para
diagramação). A proposta original de CHEN foi enriquecida por trabalhos de diversos autores,
que procuraram atribuir maior capacidade semântica ao MER, o que gerou as camadas
EXTENSÕES. As extensões ao MER possibilitam representar o mundo real com maior riqueza
de detalhes. Por outro lado, elas provocaram a diversificação dos padrões de notação e
terminologia, contrastando com a proposta original de simplicidade e acarretando problemas
para a disseminação da cultura. Seu objetivo é definir um modelo de alto nível independente
de implementação. O modelo é representado graficamente por um Diagrama de Entidade-
Relacionamento (DER), que é simples e fácil de ser entendido por usuários não técnicos.
5.2. ENTIDADE
Uma Entidade ou Tabela é uma coleção de REGISTROS do mesmo tipo, ou seja, referentes a
um mesmo assunto e com o mesmo formato padrão (layout). Constitui o componente do
sistema no qual são armazenados os dados, que combinados através dos programas servem
de base para a geração da informação desejada pelo usuário, através de relatórios e consultas
on-line. Um sistema de controle de notas, por exemplo, pode armazenar seus dados em
diversas tabelas, cada uma contendo informações sobre um determinado item do sistema:
ALUNO, PROFESSOR, MATÉRIA, NOTA, etc. Essas informações podem ser combinadas
através de programas para gerar, por exemplo, o BOLETIM ESCOLAR, a PAUTA ou uma tela
de CONSULTA DE NOTAS.
Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no

Banco de Dados. Uma entidade pode representar objetos concretos da realidade (pessoas,
automóveis, material, nota fiscal) quanto objetos abstratos (departamentos, disciplinas,
cidades). A entidade se refere a um conjunto de objetos; para se referir a um objeto em
particular é usado o termo instância (ou ocorrência). No DER, uma entidade é representada
através de um retângulo que contém o nome da entidade;
PESSOA DEPARTAMENTO
5.2.1. REGRAS PARA ATRIBUIÇÃO DE NOMES A ENTIDADES
A literatura não consagra um padrão para a atribuição de nomes a entidades, mas, para
alcançarmos um mínimo de padronização, indicamos observar as seguintes regras:
Nomes breves e objetivos, grafados em maiúsculas e, que identifiquem facilmente o

conteúdo da entidade;
No singular, já que a pluralidade decorre, naturalmente, do número de ocorrências

(linhas / túplas), característica própria de toda entidade;
Nomes compostos separados por hífen, eliminando-se o uso de preposições ou outros

termos de ligação;
Evitar abreviação de nomes. Se necessário, ampliar o tamanho da figura representativa

da entidade.
5.3. RELACIONAMENTO
O relacionamento representa a relação existente entre entidades integrantes de um MER. É

notado por uma LINHA ligando as ENTIDADES envolvidas e possuem NOME e
CARDINALIDADE. Veja as seguintes características:
É toda associação entre entidades, sobre a qual deseja-se manter informações no Banco
de Dados;
Os relacionamentos representam fatos ou situações da realidade, onde as entidades
interagem de alguma forma;
Um dado por si só não faz uma informação, pois não tem sentido próprio, é necessário que
haja uma associação de dados para que a informação seja obtida.
Exemplos:
Fornecimento: entre as entidades FORNECEDOR e MATERIAL;
Matrícula: entre as entidades ALUNO e DISCIPLINA;
Financiamento: entre as entidades PROJETO e AGENTE FINANCEIRO;
No DER, os relacionamentos são representados por losangos, ligados às entidades que

participam do relacionamento;
DEPARTAMENTO LOTAÇÃO PESSOA
Diagrama de ocorrências de relacionamentos:
5.3.1. AUTO-RELACIONAMENTO
Relacionamento entre ocorrências da mesma entidade.
PESSOA
marido esposa
CASAMENTO
Diagrama de ocorrências no auto-relacionamento:
O papel da entidade no relacionamento indica a função que uma ocorrência de uma

entidade cumpre em uma ocorrência de um relacionamento.
5.3.2. CARDINALIDADE DE RELACIONAMENTOS
A cardinalidade de uma entidade em um relacionamento expressa o número de
instâncias da entidade que podem ser associadas a uma determinada instância da entidade
relacionada.
Devem ser consideradas duas cardinalidades:
Cardinalidade mínima de uma entidade é o número mínimo de instâncias da

entidade associada que devem se relacionar com uma instância da entidade em
questão.
Cardinalidade máxima de uma entidade é o número máximo de instâncias da

entidade associada que devem se relacionar com uma instância da entidade em
questão.
5.3.3. CARDINALIDADE MÁXIMA

No projeto para BD relacional não é necessário distinguir as cardinalidades que sejam
maiores que 1. Assim, são usados apenas as cardinalidades máximas 1 e n (muitos).
5.3.4. CLASSIFICAÇÃO DE RELACIONAMENTOS BINÁRIOS
A cardinalidade máxima é usada para classificar os relacionamentos binários (aqueles
que envolvem duas entidades).
a) Relacionamentos 1:1 (um-para-um)
b) Relacionamentos 1:N (um-para-muitos)
c) Relacionamentos N:N (muitos-para-muitos)
5.3.5. RELACIONAMENTO TERNÁRIO

É o relacionamento formado pela associação de três entidades
Cardinalidade em relacionamentos ternários:
5.3.6. CARDINALIDADE MÍNIMA
A cardinalidade mínima é usada para indicar o tipo de participação da entidade em um
relacionamento. Esta participação pode ser:
Parcial ou Opcional: quando uma ocorrência da entidade pode ou não participar de

determinado relacionamento; é indicado pela cardinalidade mínima = 0 (zero).
Total ou Obrigatória: quando todas as ocorrências de uma entidade devem

participar de determinado relacionamento; é indicado pela cardinalidade mínima > 0
(zero).
Exemplos:
1 REALIZA N
CLIENTE PEDIDO
Um cliente pode fazer pedidos ou não, mas todos os pedidos devem estar associados
a um cliente.
1 ALOCA N
DEPTO EMPREGADO
Todos os departamentos devem possuir pelo menos um empregado alocado, e todos

os empregados devem estar alocados em um departamento.
1 ALOCA N
DEPTO EMPREGADO
10
Parcialidade mínima: para um departamento para ser criado, devem existem pelo
menos 10 empregados alocados.
5.4. NOTAÇÕES ALTERNATIVAS
Notação Heuser: semântica associativa
(1,1) (0,N)
DEPTO ALOCA EMPREGADO
Notação Santucci/MERISE: semântica participativa
(0,N) (1,1)
Notação Setzer: semântica associativa
1 N
5.5. ATRIBUTO
Os atributos são os dados que devemos armazenar a respeito da entidade, para atender às
necessidades de informações demandadas pelo usuário. Constituem tudo o que se pode
relacionar como próprio (propriedade) da entidade e que, de alguma forma, estejam contidos
no escopo do problema em análise. Os atributos qualificam e distinguem as entidades no MER.
Em relação ao banco de dados, os atributos representam as colunas, que formam a estrutura
de dados das tabelas. As colunas armazenam um valor para cada linha. Esse valor
armazenado é designado por VALOR DE ATRIBUTO. O conjunto de valores de atributos,
distintos por um identificador único (chave primária) denomina-se OCORRÊNCIA. Esse
conceito é análogo ao de linha (túpla) em tabela relacional e de registro em arquivo
convencional. É um dado que é associado a cada ocorrência de uma entidade ou
relacionamento. Os atributos não possuem existência própria ou independente - estão sempre
associados a uma entidade ou relacionamento Podemos exprimir os atributos no MER,
conforme mostrado na figura abaixo:
Exemplo:
Funcionário: Matrícula, Nome, Endereço;
Material: Código, Descrição;
Financiamento: Valor total, Meses;
Fornecedor: Nome, Endereço;
5.5.1. DOMÍNIO
É o conjunto de valores válidos que um atributo pode assumir.
Ex: Estado civil: solteiro, casado, divorciado, viúvo.
5.5.2. TIPOS DE ATRIBUTOS
a) Opcional/Mandatório
Opcional: o atributo pode possuir um valor nulo (vazio). Ex: número de telefone
Mandatório: o atributo deve possuir um valor válido, não nulo. Ex: nome do cliente
b) Monovalorado/Multivalorado
Monovalorado: o atributo assume um único valor dentro do domínio. Ex: data de
nascimento
Multivalorado: o atributo pode assumir um número qualquer de valores dentro do
domínio. Ex: Telefone para contato
c) Atômico/Composto
Atômico: o atributo não pode ser decomposto em outros atributos. Ex: Idade
Composto: o atributo é composto por mais de um atributo. Ex: Endereço
5.5.3. ATRIBUTO DE RELACIONAMENTO

Assim como as entidades, os relacionamentos também podem possuir atributos.
5.5.4. IDENTIFICADOR DE ENTIDADES

Conjunto de atributos que tem a propriedade de identificar univocamente cada ocorrência
de uma entidade;
Toda entidade deve possuir um identificador;
O identificador deve ser mínimo, único, monovalorado e mandatório;
5.5.5. RELACIONAMENTO IDENTIFICADOR (ENTIDADE FRACA)
Existem casos em que uma entidade não pode ser identificada apenas com seus
próprios atributos, mas necessita de atributos de outras entidades com as quais se relaciona.
Este relacionamento é denominado Relacionamento Identificador. Alguns autores denominam
uma entidade nesta situação de Entidade Fraca.
5.5.6. IDENTIFICADOR DE RELACIONAMENTOS

Uma ocorrência de relacionamento diferencia-se das demais pelas ocorrências das
entidades que participam do relacionamento. No exemplo
No exemplo, uma ocorrência de ALOCAÇÃO é identificada pela ocorrência de

Engenheiro e pela ocorrência de Projeto. Ou seja, para cada par (engenheiro, projeto) há no
máximo um relacionamento de alocação.
Em certos casos, será necessário o uso de atributos identificadores de
relacionamentos. Por exemplo:
Como o mesmo médico pode consultar o mesmo paciente em diversas ocasiões, é

necessário o uso de um atributo que diferencie uma consulta da outra.
5.6. GENERALIZAÇÃO/ESPECIALIZAÇÃO
A generalização é um processo de abstração em que vários tipos de entidade são
agrupados em uma única entidade genérica, que mantém as propriedades comuns;
A especialização é o processo inverso, ou seja, novas entidades especializadas são

criadas, com atributos que acrescentam detalhes à entidade genérica existente;
A entidade genérica é denominada superclasse e as entidades especializadas são as

subclasses. A superclasse armazena os dados gerais de uma entidade, as subclasses
armazenam os dados particulares;
Este conceito está associado à idéia de herança de propriedades. Isto significa que as
subclasses possuem, além de seus próprios atributos, os atributos da superclasse
correspondente.
Usada quando é necessário caracterizar entidades com atributos próprios ou participação
em relacionamentos específicos
Uma generalização / especialização pode ser total ou parcial:
É total quando, para cada ocorrência da entidade genérica, existe sempre uma
ocorrência em uma das entidades especializadas.
É parcial quando nem toda ocorrência da entidade genérica possui uma ocorrência
correspondente em uma entidade especializada.
5.7. ENTIDADE ASSOCIATIVA (AGREGAÇÃO)
Na abordagem “top-down” (do geral para o específico) é comum representar-se no Modelo

Conceitual apenas as entidades mais importantes para a elucidação do problema. Assim, uma
única entidade do Conceitual, ao ser normalizada, pode dar origem a um conjunto de entidades
e seus relacionamentos no Modelo Operacional. Portanto, a AGREGAÇÃO é um recurso do
Modelo Conceitual, que representa através de uma única entidade “não-normalizada”, um
conjunto de entidades e relacionamentos do nível Operacional. A Agregação permite visualizar
um modelo complexo, com muitas entidades, de uma maneira mais genérica. Com isso, obtém-
se uma melhor visão do contexto, com destaque para as entidades e relacionamentos mais
importantes e omissão dos detalhes irrelevantes. Uma agregação possue as seguintes
características:
• O uso desta abstração é necessário quando um relacionamento deve ser representado

como uma entidade no modelo conceitual. Isto ocorre quando é necessário estabelecer um
relacionamento entre uma entidade e um relacionamento.
• Para atender a esta situação foi criado o conceito de Entidade Associativa ou Agregação. A
agregação é simplesmente um relacionamento que passa a ser tratado como entidade.
• Considerando o exemplo:
Se for necessário adicionar a informação que, a cada consulta um ou mais medicamentos
podem ser prescritos ao paciente, será necessário criar uma nova entidade (MEDICAMENTO).
Esta entidade deve se relacionar com as consultas, mas CONSULTA é um relacionamento.
Deve ser criada então uma entidade associativa.
Outra forma alternativa de se representar à entidade associativa é:
5.8. RELACIONAMENTO MUTUAMENTE EXCLUSIVO
Neste tipo de relacionamento uma ocorrência de uma entidade pode estar associada com
ocorrências de outras entidades, mas não simultaneamente.
AVIÃO TRANSPORTE CARGA
TRANSPORTE
PASSAGEIRO
5.9. RESTRIÇÃO DE PERSISTÊNCIA NO RELACIONAMENTO

Um relacionamento é persistente quando, depois de criado, ele não puder ser removido
indiretamente pela remoção de uma ocorrência de uma das entidades associadas.
1 N
EMPRÉS-
ALUNO LIVRO
TIMO
5.9.1. NORMALIZAÇÃO
A NORMALIZAÇÃO é uma técnica de modelagem de dados, criada por E. F. CODD, nos

laboratórios de pesquisa da IBM, lançada junto com as bases do modelo Relacional de SGBD.
Essa técnica de modelagem nos proporciona critérios objetivos, para determinarmos quando
uma relação (tabela / estrutura de dados) apresenta problemas no tocante à observância de
princípios do enfoque relacional, tais como:
• Tabela bidimensional (valores atômicos);
• Regras de integridade;
• Mínima redundância;
• Nenhuma inconsistência;
• Inexistência de anomalias de atualização (inclusão, alteração e exclusão).
O processo de NORMALIZAÇÃO proposto por CODD, deu origem a três FORMAS NORMAIS:
• PRIMEIRA FORMA NORMAL - 1FN;
• SEGUNDA FORMA NORMAL - 2FN e;
• TERCEIRA FORMA NORMAL - 3FN.
Outras formas normais foram propostas, por diversos autores, configurando situações que
ocorrem mais raramente, sendo a 4FN a mais significativa. Conforme veremos mais adiante,
a 1FN visa tão somente colocar as estruturas de dados oriundas dos modelos conceituais no
formato tabular adequado, que permita que elas possam ser criadas nos SGBD-R. Nesse
sentido, considera-se que relações em 1FN já estão NORMALIZADAS.
As demais formas normais estão dirigidas para evitar REDUNDÂNCIA DE DADOS,
INCONSISTÊNCIAS e ANOMALIAS DE ATUALIZAÇÃO. Redundância de dados é um fato
gerador de inconsistências, já as anomalias de atualização criam dificuldades operacionais
para a manutenção do BD. Esses aspectos reforçam a importância de aplicação da 2FN e 3FN.
5.9.2. ANOMALIAS DE ATUALIZAÇÃO
São problemas presentes em estruturas de dados modeladas de forma inadequada.
TABELA FUNCIONÁRIO
Matricula Nome Endereço Código Sigla Órgão Quantidade

Órgão Funcionário
03 JOÃO SQS 01 GETAE 2
05 JOSÉ SQS 01 GETAE 2
01 VILMA GAMA 05 GEPAC 1
02 ANA GUARA 02 GEPRO 3
08 JUCA SQN 02 GEPRO 3
06 ANA SQN 02 GEPRO 3
Exemplos de anomalias de atualização na tabela FUNCIONÁRIOS:
• A INCLUSÃO de um novo ORGÃO na tabela fica condicionada a que algum funcionário

seja alocado nele;
• A ALTERAÇÃO de nome do órgão “GERAE” para “GETAE” provoca atualização em várias

túplas, haja vista, que o mesmo pode repetir-se numerosas vezes na relação;
• A INCLUSÃO de um novo funcionário para o “GEORG’ causa ALTERAÇÃO no atributo

“QT-FUNC” em diversas túplas;
• A EXCLUSÃO da funcionária “VILMA” da tabela ocasiona perda de informações sobre o

‘GEPAC”;
5.9.3. TERMINOLOGIA
O vocabulário de NORMALIZAÇÃO se confunde com o empregado nos SGBD do modelo

RELACIONAL. Isso ocorre por que a técnica de normalização é uma das bases desse modelo.
Os termos abaixo são relevantes para o entendimento das três formas normais:
• Célula
Interseção (LINHA X COLUNA) de uma relação.
• Item Repetitivo (Valor Não-Atômico ou Atributo Não-Simples).

Ocorre quando uma célula possui mais do que um valor de atributo é representado por
estruturas de dados dos tipos VETOR, MATRIZ ou ITENS DE GRUPO, que impedem a
adequada aplicação das operações relacionais, com SQL (Structured Query Language).
• Valor Atômico (Atributo Simples)

Caracterizado quando uma célula possui apenas um valor de atributo. Esta é a situação
adequada no modelo Relacional.
• Chave Primária
CHAVE PRIMÁRIA, PRIMARY KEY (PK) ou simplesmente CHAVE é o atributo ou combinação
de atributos que permite a IDENTIFICAÇÃO ÚNICA de cada túpla na relação. A PK não admite
duplicata e nem valor nulo.
Ex: Se pesquisarmos uma relação de FUNCIONÁRIOS, de PK = MATRICULA, utilizando a

matricula como chave de acesso, deveremos obter uma única túpla como resultado da
pesquisa.
A chave primária pode ser simples ou composta:
• SIMPLES: Constituída de apenas um atributo

Exemplo:
COD-PRODUTO ==> NOME-PROD

NUM-CONTA ==> NOME-CLI, DT-NASC, SALDO
• COMPOSTA: formada pela concatenação de dois ou mais atributos.

Exemplo:
COD-PROD + COD-FORNECEDOR ==> PREÇO-PROD

MATR-ALUNO + MATR-PROF + DATA-PROVA ==> NOTA-PROVA
NUM-CONTA + TIPO-APLICAÇÃO + DATA ==> SALDO-APLIC
• Dependência Funcional
É a correspondência (identificação unívoca) existente entre dois atributos de uma mesma

relação. Podendo ser de três tipos: COMPLETA, PARCIAL e TRANSITIVA
• Dependência Funcional Completa (DFC)
Relação de identificação unívoca entre o ATRIBUTO-CHAVE e os demais atributos da relação.
Ex: COD-CLIENTE ==> NOME-CLIENTE, ENDEREÇO;
COD-CLIENTE + NUM-PRESTAÇÃO ==> DT-VENCIMENTO, VALOR;
• Dependência Funcional Parcial (DFP)
Relação de identificação unívoca entre parte da CHAVE PRIMÁRIA (PK composta por dois ou
mais atributos) e algum dos demais atributos da relação.
Ex: COD-PRODUTO + COD-FORNECEDOR ==> NOME-PROD, PREÇO
COD-PRODUTO identifica univocamente o NOME-PROD e é um componente da chave

primária.
Obs.: Para que ocorra dependência parcial é necessário chave primária composta. Por outro
lado, nem sempre que ocorre PK composta haverá dependência parcial.
• Dependência Funcional Transitiva (DFT)
Relação de identificação unívoca entre atributos que não fazem parte da chave primária da
relação.
Ex: PK-MATR ==> NOME, DT-NASC, COD-SETOR, NOME-SETOR
COD-SETOR identifica univocamente o NOME-SETOR e não faz parte da chave.
5.9.4. NOTAÇÃO PARA AS ESTRUTURAS DE DADOS
Existem diversas notações, segundo as quais, podemos representar genericamente uma

relação. Neste trabalho iremos adotar, principalmente, a notação empregada por CHRIS GANE
para a descrição de depósitos de dados e, opcionalmente, a notação de YORDON/DE
MARCO.
TABELA VENDA:
ITENS-DE-VENDA
NUM-NF NOME-CLI END-CLI DT-VENDA CD-PRD QDT P-UNIT
01 10 20,00
001 Antônio SQS 22/08 02 20 10,00
05 8 5,00
02 Juliana SQN 10/09 01 6 20,00
03 Cláudia SQS 20/07 05 10 5,00
. . . . . . .
. . . . . . .
. . . . . . .
A representação genérica da relação VENDA, conforme a notação de GANE, corresponde à

seguinte:
VENDA ==> nome da relação

# NUM-NF
NOME-CLI
END-CLI
DT-VENDA
ITENS-DE-VENDA*===========================> grupo repetitivo
# COD-PROD
QUANT
P-UNIT
Observações:
• ITENS DE GRUPO são IDENTADOS, com deslocamento para a direita dando idéia de
hierarquia;
• GRUPOS REPETITIVOS são sinalizados com “*” e/ou grafados no PLURAL.
• Os atributos componentes da CHAVE devem receber uma das seguintes notações:
o sublinhados, ou;
o Um “#” ou um “C” colocados à esquerda dos atributos.
A representação genérica da tabela “VENDA” segundo a notação de YORDON/DE MARCO é:
VENDA = NUM-NF, NOME-CLI, END-CLI, DATA-VENDA, ITENS-DE-VENDA {COD-PROD,

QUANT, P-UNIT}
Observações:
• GRUPOS REPETITIVOS são representados entre chaves;

• O ATRIBUTO-CHAVE deve ser sublinhado.
• Para relações com grande número de atributos a notação de GANE é mais eficiente;
5.9.5. ESQUEMA DA NORMALIZAÇÃO
RELAÇÃO
NÃO Tabela com itens de grupo
NORMALIZADA
Eliminar ITENS DE GRUPO
1FN Escolher a chave primária
Eliminar DEPÊNDÊNCIA PARCIAL
2FN
Eliminar DEPENDÊNCIA TRANSITIVA
3FN
5.9.6. RELAÇÕES NÃO-NORMALIZADAS
Uma relação NÃO NORMALIZADA é aquela que possui atributos do tipo NÃO-SIMPLES
(NÃO-ATÔMICOS). Para a devida utilização dos OPERADORES RELACIONAIS é necessário
que a relação não-normalizada seja transformada numa forma onde os atributos só contenham
VALORES ATÔMICOS, em outras palavras, é preciso tornar a estrutura de dados plana. Esse
processo de planificação da relação é concretizado após a sua transposição para a 1FN.
Considere a relação abaixo:
Relação: CONTA CORRENTE
CCONTA-CORRENTE
CONTA
AGENCIA
NUMERO
NOME-CLIENTE
ENDEREÇO-CLIENTE
DEPENDENCIA
TIPO-AGENCIA
DESCRIÇÃO-TIPO-AGENCIA
ENDEREÇO-DEPENDENCIA
LANÇAMENTOS*
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO Observações:
• Os atributos “CONTA” , “DEPENDÊNCIA” e “LANÇAMENTOS” são itens de grupo;
• O atributo “LANÇAMENTOS” é um grupo repetitivo;
• Esses atributos são do tipo não-atômicos, pois suas células não contêm valores únicos;
• A relação “CONTA-CORRENTE” está na forma NÃO-NORMALIZADA.
5.9.7. PRIMEIRA FORMA NORMAL (1FN)
Uma relação está em 1FN se todos seus ATRIBUTOS são SIMPLES (ATÔMICOS). Para
colocarmos uma relação em 1FN devemos PLANIFICÁ-LA, eliminando de sua estrutura os
atributos NÃO-ATÔMICOS (VETOR, MATRIZ e ITEM DE GRUPO), de modo que, cada célula
da tabela possua apenas um valor de atributo. Isto porque os atributos NÃO-ATÔMICOS não
podem ser implementados nos SGBD RELACIONAIS. A especificação abaixo corresponde à
relação CONTA-CORRENTE após o processo de normalização (1FN):
CONTA-CORRENTE
AGENCIA
NUMERO-CONTA
NOME-CLIENTE
ENDEREÇO-CLIENTE
TIPO-AGENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO
Observações:
• O esquema genérico passou a contar somente com ATRIBUTOS SIMPLES. Todos os

ITENS DE GRUPO foram eliminados;
• Assim como toda a relação em 1FN, a estrutura de dados acima apresenta redundâncias
e anomalias de atualização;
• CODD estabelece um outro procedimento para normalização (1FN), que é o de decompor

a relação não-normalizada em tantas relações quantos forem os grupos repetitivos além
de incluir uma relação para o conjunto de colunas atômicas. No processo que
descrevemos essas relações surgem naturalmente na derivação das formas normais
seguintes (2FN e 3FN).
5.9.8. ESCOLHA DA CHAVE PRIMÁRIA
Estando a relação em 1FN, o próximo passo no esquema de normalização é a escolha da

CHAVE PRIMÁRIA. CHAVE PRIMÁRIA é Atributo (chave simples) ou combinação de
atributos (chave composta) que identifica univocamente as túplas de uma relação. Na
escolha do ATRIBUTO-CHAVE os seguintes aspectos são relevantes:
• Não pode conter valor nulo para evitar duplicatas;

• Não pode conter duplicatas para garantir a identificação unívoca;
• Deve ser um atributo estável (não sujeito a constantes mudanças);
o Estável: MATRICULA, CPF, NUM-CONTA-CORRENTE;
o Não estável: MOEDA-NACIONAL, SALDO, INDICE-ECONÔMICO.
• Não deve dar margem a ambigüidades para garantir a eficiência de acesso (dar
preferência a código numérico e o mais curto possível);
o Obs1: atributos alfabéticos podem gerar dúvidas quanto à grafia.
Ex: Nome de pessoa - Luís ou Luiz; Melo ou Mello
Nome de órgão - GERAD; GEDAD; GEPAD;
o Obs2: Códigos alfanuméricos ou atributos muito extensos são mais propensos a

erros de digitação.
• Os grupos repetitivos, constantes da relação não-normalizada, devem ceder pelo menos um
atributo para formar a chave composta da relação em 1FN;
• CHAVES CANDIDATAS ocorrem quando numa relação existem vários atributos (ou
combinações) com potencial de CHAVE PRIMÁRIA. Nesse caso, para escolher-se a
CHAVE da relação, deve-se considerar os critérios anteriormente definidos. Somente uma
CHAVE PRIMÁRIA será escolhida, as demais serão chamadas CHAVES ALTERNATIVAS.
• O processo de escolha de CHAVE PRIMÁRIA em um BD relacional constitui uns fatores
críticos, que afeta a estabilidade do Banco de dados, pois, os relacionamentos são
implementados através da redundância das CHAVES. Portanto, qualquer alteração na
chave repercute em todos os relacionamentos nos quais a entidade detentora da mesma
esteja envolvida (direta ou indiretamente).
Exemplo: Consideremos a relação CONTA-CORRENTE em 1FN (ITEM 5.5):
CONTA-CORRENTE
AGENCIA
NUMERO-CONTA
NOME-CLIENTE
ENDEREÇO-CLIENTE
TIPO-AGENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO
Qual o atributo ou combinação de atributos que identificam singularmente cada túpla da

relação CONTA-CORRENTE?
R1: O atributo “AGÊNCIA-CONTA” isoladamente deve ser descartado, pois, o código de uma
agência relaciona-se com diversos números de conta;
R2: O “NUMERO-CONTA” isoladamente não é adequado, haja vista, que podem existir duas
contas com o mesmo número em agências diferentes;
R3: A combinação AGÊNCIA + NUMERO-CONTA” ainda não é satisfatória, porque podem

existir diversos lançamentos (NUM-DOC, DATA, VALOR) para cada conta vinculada a
uma agência;
R4: Como “LANÇAMENTOS” é um grupo repetitivo na forma NÃO-NORMALIZADA da

relação CONTA-CORRENTE, naturalmente, ele deve ceder um atributo para compor a
chave primária. Assim, a CHAVE dessa relação é COMPOSTA pela concatenação dos
atributos:
- AGÊNCIA + NUMERO-CONTA + NUM-DOC
R5: Se considerássemos possível dois documentos, com o mesmo número, em sua mesma
conta, deveríamos buscar um outro arranjo para a chave-primária.
5.9.9. SEGUNDA FORMA NORMAL (2FN)
Uma relação está em 2FN se:
• Está em 1FN;
• Não contém atributos que dependam funcionalmente de subconjuntos da CHAVE

PRIMÁRIA COMPOSTA, em outras palavras, não contém DEPENDÊNCIA FUNCIONAL
PARCIAL (DFP).
Para passarmos uma relação da 1FN para a 2FN devemos ELIMINAR as DEPENDÊNCIAS
PARCIAIS. Para tanto, utilizamos o conceito de PROJEÇÃO, gerando novas tabelas contendo
as colunas que se encontram em DFP com a chave primária. A aplicação da 2FN sobre a
relação “CONTA-CORRENTE” resulta na criação das seguintes tabelas:
CONTA
# NUMERO-CONTA
NOME-CLIENTE
ENDEREÇO-CLIENTE
AGENCIA
# NUM-AGENCIA
TIPO-AGENCIA
LANÇAMENTOS
# AGENCIA
# NUMERO-CONTA
# NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO
5.9.10. TERCEIRA FORMA NORMAL (3FN)
Uma relação está em 3FN se:
• Está em 1FN;
• Está em 2FN;
• Não possui DEPENDÊNCIA FUNCIONAL TRANSITIVA (DFT).
Para passarmos uma relação da 2FN para a 3FN devemos ELIMINAR as DEPENDÊNCIAS
TRANSITIVAS utilizando a operação de PROJEÇÃO. Assim, são geradas novas tabelas
correspondentes as DFT identificadas. Ao decompormos a tabela “CONTA-CORRENTE”,
gerando as relações em 2FN, restou apenas uma DFT, que se encontra na relação
“DEPENDÊNCIA”. Fazendo a PROJEÇÃO dessa relação para eliminar a DFT obtemos as
relações abaixo:
AGENCIA
# NUM-AGENCIA
TIPO-AGENCIA
TIPO-AGENCIA
# TIPO-AGENCIA
CONTA
# NUMERO-CONTA
NOME-CLIENTE
ENDEREÇO-CLIENTE
LANÇAMENTOS
# AGENCIA
# NUMERO-CONTA
# NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO
Observações:
• A chave da relação “TIPO-AGÊNCIA” permaneceu na relação principal como CHAVE

ESTRANGEIRA, possibilitando o relacionamento entre as duas tabelas.
• As relações “CONTA” e “LANÇAMENTO” já se encontram em 3FN, porque não contém
DFT.
• Com a aplicação da 3FN, TODAS as DEPENDÊNCIAS FUNCIONAIS restantes nas
relações são do tipo COMPLETAS.

Apostila Completa

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila Completa

Caricato da

Copyright:

Formati disponibili

BD I

Representação de uma propriedade ou característica de um objeto real;

Não tem significado por si só;

Ex.: quantidade de Kwh consumidos em uma residência.

A INFORMAÇÃO acrescenta algo ao conhecimento da realidade a ser analisada. Por

Informação é a interpretação dos dados;

Ex: Consumo de energia comparado com a capacidade geradora da usina.

• Arquivo: coleção de registros lógicos, cada um deles representando um objeto ou entidade.

• Registro lógico (registro): Um registro é constituído por conjunto de campos valorados

• Campo: É a unidade básica formadora de um registro. Constitui a célula da informação. É a

• Bloco: unidade de armazenamento do arquivo em disco, também denominado registro

• Chave: é uma seqüência de um ou mais campos em um arquivo;

• Chave primária ou Primary Key: A Chave Primária (ou simplesmente CHAVE) é o

• Chave Estrangeira ou Foreign Key: É um atributo ou conjunto de atributos cujos valores

2.2.1. ARQUIVO SEQÜENCIAL

# Numero Nome Idade Salário

Podemos considerar dois tipos de acesso: seqüencial ou aleatório.

• O acesso aleatório se caracteriza pela utilização de um “argumento de pesquisa” (chave

Arquivo B Arquivo T Arquivo A

Normalmente é implementada como a inserção, com a criação de um arquivo de transações

Consiste na modificação do valor de um ou mais atributos de um registro. O registro deve ser

Quando o volume de acessos aleatórios em um arquivo seqüencial torna-se muito grande, é

Índice Primário Índice Secundário Arquivo

4 1300 DIOGO 24 400

O principal problema associado com os arquivos diretos é o da determinação de uma função F,

2. Dê exemplos de arquivos, registros e campos.

3.1. BANCO DE DADOS (BD)

3.2.1. PROCESSAMENTO DE DADOS SEM BANCO DE DADOS

Problemas da falta de integração de dados:

3.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD

3.2.3. PRINCIPAIS COMPONENTES DE UM SGBD

• Dicionário de dados (Data Dictionary): Descreve os dados e suas relações em forma

• Linguagem de definição de dados (DDL - Data Definition Language): Descreve os

• Linguagem de acesso (DML - Data Manipulation Language): Usada para escrever as

• Linguagem de consulta (QUERY): Permite que o usuário final, com poucos

3.2.4. CARACTERÍSTICAS DE UM SGBD

• Independência dos dados: O SGBD deve oferecer isolamento das aplicações em

• Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturas de dados

• A redundância desnecessária de dados leva ao armazenamento excessivo de

• Uso compartilhado: Um SGBD multiusuário deve permitir que múltiplos usuários

• Controle do espaço de armazenamento: O SGBD deve manter controle das áreas de

• Restrição a Acesso não Autorizado: Um SGBD deve fornece um subsistema de

• Representação de Relacionamentos Complexos entre Dados: Um banco de dados

3.3. ABSTRAÇÃO DE DADOS

• NÍVEL CONCEITUAL: É o nível onde se descreve quais os dados são realmente

3.4. MODELOS DE BANCOS DE DADOS

• Modelo Lógico: É a descrição da base de dados conforme é vista pelos usuários do

• Modelo físico (interno): Descrição de como a base de dados é armazenada

3.5. INDEPENDÊNCIA DE DADOS

• Independência de dados a nível físico: a capacidade de se modificar o modelo físico, sem

• Independência dados a nível lógico: a capacidade de se modificar o esquema lógico, sem

3.6. FUNÇÕES RELACIONADAS AO SGBD

3.6.1. ADMINISTRADOR DE DADOS

• Gerenciar o dado como um recurso da empresa.

3.6.2. ADMINISTRADOR DE BANCO DE DADOS

O administrador do banco de dados (DBA), já mencionado é a pessoa (ou grupo de pessoas)

• Decidir o conteúdo de informações do banco de dados

• Decidir a estrutura de armazenamento e a estratégia de acesso

• Servir de elo de ligação com usuários

• Definir os controles de segurança e integridade

Os controles de segurança e de integridade, como já mencionado, podem ser considerados

• Definir a estratégia de reserva e recuperação

A partir do momento em que a empresa começa efetivamente a basear-se em banco de dados,