Introdução a Banco de Dados

PARTE I

INTRODUÇÃO...................................................................................................................1

CAPÍTULO I - CONCEITOS BÁSICOS

1. Arquivo...........................................................................................................................2
2. Registro..........................................................................................................................2
3. Campo............................................................................................................................3
4. Chave Primária...............................................................................................................4
5. Chave Secundária..........................................................................................................5
6. Chave Candidata............................................................................................................6

CAPÍTULO II - ORGANIZAÇÃO DE ARQUIVOS

1. Método De Acesso.........................................................................................................7
2. Organização Seqüencial................................................................................................9
3. Organização Serial.......................................................................................................10
4. Organização Indexada.................................................................................................11

CAPÍTULO III - SGBD

1. Sistema Gerenciador de Banco de Dados – SGBD.....................................................13
2. Banco de Dados...........................................................................................................13
3. Sistema em Banco de Dados.......................................................................................13

CAPÍTULO IV - OBJETIVOS DE BANCO DE DADOS

1. Independência de dados..............................................................................................15
2. Compartilhamento de dados........................................................................................16
3. Menor redundância.......................................................................................................16
4. Privacidade de dados...................................................................................................17
5. Segurança de dados....................................................................................................17
6. Tratamento de concorrência.........................................................................................18
7. Integridade de dados....................................................................................................18

CAPÍTULO V - LINGUAGENS DE BD
1. SQL..............................................................................................................................19
2. Autocontidas.................................................................................................................22
3. Hospedeiras.................................................................................................................22
4. Visuais..........................................................................................................................23

CAPÍTULO VI - MODELO HIERÁRQUICO

1. limitações dos modelos hierárquicos............................................................................24

CAPÍTULO VII - MODELO REDE

1. Características dos modelos Rede CODASYL.............................................................27

CAPÍTULO VIII - MODELO RELACIONAL

1. Terminologia do Modelo Relacional.............................................................................31
2. Regras de integridade..................................................................................................32
3. Operadores Relacionais...............................................................................................36
4. Propriedades Relacionais.............................................................................................36
5. Vantagens do Modelo Relacional.................................................................................38

CAPÍTULO IX - ÁLGEBRA RELACIONAL

1. Estudo de caso.............................................................................................................40
2. Generalidades..............................................................................................................42
3. Operadores de Conjunto..............................................................................................43
4. Operadores Relacionais...............................................................................................47

1
 PARTE II

CAPÍTULO I - NORMALIZAÇÃO
1. Definição......................................................................................................................51
2. Anomalias de Atualização............................................................................................52
3. Terminologia.................................................................................................................53
4. Notações para descrição das Estruturas de Dados......................................................56
5. Esquema da Normalização..........................................................................................58
6. Relações não Normalizadas.........................................................................................59
7. Primeira Forma Normal (1FN)......................................................................................60
8. Escolha da Chave Primária..........................................................................................61
9. Segunda Forma Normal (2FN).....................................................................................64
10. Terceira Forma Normal (3FN)....................................................................................65

BIBLIOGRAFIA................................................................................................................75

Brasília-DF
Março/2009

2
 INTRODUÇÃO A DE BANCO DE DADOS

PARTE I

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.

A literatura classifica os SGBD como HIERÁRQUICO, REDE e RELACIONAL. Essa classificação

representa a evolução desses produtos no curso da história. Atualmente, o mercado é dominado pelos
SGBD RELACIONAIS e caminha para a colocação em escala comercial dos SGBD ORIENTADOS A
OBJETOS.

Este texto introduz a teoria de BANCO DE DADOS, a partir de conceitos básicos da teoria de arquivos que
perpetuaram-se na terminologia de banco de dados. Na sequencia aborda superficialmente os modelos
HIERÁRQUICO e REDE (por razões de mercado) e de forma mais aprofundada o MODELO RELACIONAL,
o qual designaremos neste texto pela sigla SGBD-R.

3
 CAPÍTULO I

CONCEITOS BÁSICOS

Para compreender com maior facilidade os conceitos relativos a BANCO DE DADOS é de suma importância
revisar-mos alguns conceitos básicos referentes à teoria e terminologia de arquivos convencionais, haja
vista, que os primeiros SGBD foram criados a partir do aperfeiçoamento de sistemas gerenciadores de
arquivo, e ainda utilizam muito da base conceitual e da terminologia de arquivos.

1. ARQUIVO

Um arquivo é 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 diversos arquivos,
cada um 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.

2. 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
deferentes em um mesmo arquivo, recurso este que raramente é utilizado.

3. 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 e TAMANHO. Os tipos de campo mais comuns são:

Armazena somente números

NUMBER Pode conter casas decimais
Pode ser utilizado em operações matemáticas
CHAR ou Pode armazenar letras, números e caracteres especiais
ALFANUMÉRICO
DATE Armazena datas, fazendo consistência automática
MEMO ou LONG Armazena textos em formato livre

A figura a seguir sintetiza os conceitos de ARQUIVO, REGISTRO e CAMPO:

ARQUIVO ALUNO
LAYOUT
CAMPOS MATRICULA NOME ENDEREÇO DT_NASC
TIPO e TAM. NUMBER (03) CHAR (30) CHAR (50) DATE
001 José SQS 308 ... 23/08/78
REGISTROS 002 Maria QND 14 .... 25/09/70
003 Ana SQN 410 ... 10/08/85
. . . .
. . . .
4
4. CHAVE PRIMÁRIA (PRIMARY KEY - PK)

A CHAVE PRIMÁRIA (ou simplesmente CHAVE) é o identificador único de um registo 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 inadequado 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.

DICAS PARA ESCOLHA DA CHAVE PRIMÁRIA:

 Todo arquivo deve possuir uma chave primária.

 VALOR ÚNICO para cada registro.
 SIMPLES ou COMPOSTA.
 Campos de PREENCHIMENTO OBRIGATÓRIO.
 Valor ESTÁVEL.
 Não AMBÍGUO.
 PEQUENA EXTENSÃO (menor possível).
 De preferência CAMPOS NUMÉRICOS

5. 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.

A figura a seguir ilustra os conceitos de CHAVE PRIMÁRIA e SECUNDÁRIA

ARQUIVO ALUNO
MATRICULA NOME ENDEREÇO DT_NASC
001 José SQS 308 ... 23/08/78
003 Maria QND 14 .... 25/09/70
002 Ana SQN 410 ... 10/08/85

5
005 José GAMA 05/04/76
A Chave Primária (PK) é a Matrícula.
Acesso via CHAVE SECUNDÁRIA (NOME) no arquivo ALUNO:

PROGRAMA X
INÍCIO....

.
SE NOME = “José”
ENTÃO IMPRIMIR
.....
.
.
FIM

6. CHAVE CANDIDATA

Pode ocorrer uma situação em que mais de um campo satisfaça a condição de chave primária,
constituindo duas ou mais CHAVES CANDIDATAS. Neste caso, o analista deverá eleger somente
uma delas como CHAVE PRIMÁRIA, as demais permanecerão na condição de CANDIDATAS,
indicando que se trata de campos de preenchimento obrigatório e com valores únicos para cada
registro, o que será garantido através de mecanismos de integridade de coluna, que veremos no
capítulo relativo a banco de dados.

A figura a seguir mostra um exemplo de arquivo com CHAVE CANDIDATA

ARQUIVO ALUNO
CHAVE CANDIDATA
CHAVE PRIMÁRIA

MATRICULA NOME ENDEREÇO CPF

001 José SQS 308 ... 72993246500
003 Maria QND 14 .... 12354789065
002 Ana SQN 410 ... 09876587659
005 José GAMA 28746503645
. . . .
. . . .

6
 CAPÍTULO II

ORGANIZAÇÃO DE ARQUIVOS

O tema organização de arquivos refere-se à forma como os registros são armazenados em um arquivo
baseado em computador. Confunde-se com MÉTODO DE ACESSO, que consiste na forma como
esses podem ser recuperados. A organização do arquivo determina os métodos de acesso que podem
ser utilizados na recuperação dos registros, mas se trata de coisas distintas.

Apesar de este ser um assunto muito abrangente e com muitas variantes em termos de abordagem,
trataremos de apenas três tipos de organização (SEQÜENCIAL, SERIAL E INDEXADA) e seus
respectivos métodos de acesso. Essa escolha baseia-se na necessidade de discutirmos alguns
conceitos essenciais para o estudo do modelo Relacional de banco de dados, que constitui o objeto
principal desse texto.

1. MÉTODOS DE ACESSO

Para recuperarmos um registro em um arquivo, podemos utilizar acesso SEQÜENCIAL ou DIRETO.

O método SEQÜENCIAL de acesso é o mais tradicional e consiste em efetuar a leitura dos registros,
um após o outro, comparando o ARGUMENTO DE PESQUISA, com o valor do campo CHAVE
(primária ou secundária) no registro corrente, até encontrar os registros desejados ou o final do
arquivo.

exemplo:
PROGRAMA Y
INÍCIO....
.
Repita até fim
ler registro chave secundária (campo chave)

SE NOME = “José” argumento de pesquisa

ENTÃO IMPRIMIR
Fim repita (volte a ler)
.
FIM DO PROGRAMA

O método DIRETO consiste em recuperar o(s) registro(s) desejado(s), sem a necessidade de efetuar a
leitura dos registros que o(s) antecede(m), o que pode ser feito através de um ÍNDICE (que
abordaremos no item organização indexada) ou com o auxílio de um algoritmo de RANDOMIZAÇÃO
que localiza o registro, calculando a posição ocupada pelo registro no disco, com base no valor do
argumento de pesquisa, que deve ser um campo numérico.

Em ambos os casos, a localização do registro ocorre a cargo do gerenciador de arquivos, de maneira

transparente para o programador, que só precisa escolher a organização adequada para o arquivo e
fornecer no programa o argumento de pesquisa.

exemplo:

PROGRAMA Z
INÍCIO....
.
.
ABRIR ARQUIVO ALUNO INDEXADO POR NOME
.
NOME=“JOSÉ” argumento de pesquisa
LOCALIZAR REGISTRO acesso direto (indexado)
SE ENCONTROU REGISTRO
ENTÃO IMPRIMIR
.

7
 FIM DO PROGRAMA

2. ORGANIZAÇÃO SEQÜENCIAL

A ORGANIZAÇÃO SEQÜENCIAL caracteriza-se pela existência de uma CHAVE DE ORDENAÇÃO.

Essa chave determina a ordem em que os registros são armazenados e pode ser SIMPLES ou
COMPOSTA por dois ou mais campos. Geralmente, coincide com a chave primária, mas não
obrigatoriamente.

A organização seqüencial somente permite o ACESSO SEQÜENCIAL.

A figura a seguir apresenta um arquivo com ORGANIZAÇÃO SEQÜENCIAL e CHAVE PRIMÁRIA

(MATRICULA) distinta da CHAVE DE ORDENAÇÃO (NOME - ordem alfabética).

ARQUIVO ALUNO

chave primária chave de ordenação

MATRICULA NOME ENDEREÇO DT_NASC

001 Ana SQS 308 ... 23/08/78
003 José QND 14 .... 25/09/70
002 José SQN 410 ... 10/08/85
005 Maria GAMA 05/04/76
. . . .
. . . .

3. ORGANIZAÇÃO SERIAL

Nesta forma de organização os registros são armazenados de acordo com a ordem de inclusão. o
arquivo não possui chave de ordenação, portanto não existe preocupação com a ordem de
armazenamento dos registros. No entanto, é sempre recomendável o arquivo possua uma chave
primária.
A organização serial somente permite o ACESSO SEQÜENCIAL. Não deve ser utilizada em processos
de exclusão e alteração de registros na modalidade bacth (atualização em lote), pois degrada a
performance.
É muito utilizada em processos de inclusão de registros onde não haja preocupação em manter a
seqüência dos mesmos (“pools” de digitação). É também empregada no arquivo de dados que serve de
base para a organização indexada, que estudaremos no próximo item.
A figura a seguir apresenta um arquivo com ORGANIZAÇÃO SERIAL. Note que ele não possui CHAVE
DE ORDENAÇÃO.

ARQUIVO ALUNO

chave primária

MATRICULA NOME ENDEREÇO DT_NASC

005 Maria SQS 308 ... 23/08/78
003 José QND 14 .... 25/09/70
002 Ana SQN 410 ... 10/08/85
001 José GAMA 05/04/76
. . . .

4. ORGANIZAÇÃO INDEXADA

8
 Nesta forma de organização, os registros são armazenados em um arquivo de dados com organização
serial e para cada campo (ou combinação deles) através do qual se deseja obter acesso direto
(indexado) deve-se criar um arquivo de índice (processo de indexação).
Um mesmo arquivo de dados pode possuir diversos arquivos de índice a ele associados. Porém,
apesar da flexibilidade para a criação de índices, esse recurso deve ser utilizado com critério, pois a
manutenção de muitos índices pode degradar a performance no processo de atualização do arquivo.
Ou seja, se ganha na consulta on-line, mas pode-se perder na atualização de dados.
O arquivo de índice é composto basicamente por duas colunas. A primeira corresponde ao campo
utilizado no processo de indexação (endereço lógico) e a segunda armazena um valor (endereço físico)
que serve como referência, para que o gerenciador de arquivos localize o registro no disco magnético.
Os registros dos arquivos índice são ordenados pelo endereço lógico. Portanto, se utilizarmos um
algoritmo de leitura seqüencial em um arquivo indexado por nome, por exemplo, obteremos os
registros em ordem alfabética, mesmo sendo o arquivo de dados um arquivo serial. Ou seja, prevalece
a ordem do índice. Porém nesse exemplo, a performance a performance do arquivo indexado seria
menor, se comparada a de um arquivo seqüencial por nome.

Sempre que um arquivo índice for referenciado por um programa, ele será carregado para memória
principal, o que torna desprezível o tempo de busca dos registros nesse arquivo. Além disso, o
algoritmo utilizado na busca é o de pesquisa binária, o que reduz ainda mais o tempo.

Os índices constituídos com base no valor da chave primária ou candidata são conhecidos como
ÍNDICES PRIMÁRIOS e os demais como ÍNDICES SECUNDÁRIOS.

Em resumo, a organização indexada é formada pela combinação de pelo menos um arquivo de dados
e um ou mais arquivos de índice.

A figura a seguir apresenta o cenário da ORGANIZAÇÃO INDEXADA:

ARQUIVO ALUNO

ÍNDICE
PRIMÁRIO
TRILHA, SETOR E LADO DO DISCO (endereço físico)
MATR TSL chave primária (endereço lógico)
001 220
002 321
003 231
005 110 TSL MATR NOME ENDEREÇO DT_NASC
. 110 005 Maria SQS 308 ... 23/08/78
231 003 José QND 14 .... 25/09/70
ÍNDICE 321 002 Ana SQN 410 ... 10/08/85
SECUNDÁRIO 220 001 José GAMA 05/04/76
331 . . . .
NOME TSL
Ana 321
José 220
José 231
Maria 110
. 331

9
 CAPÍTULO III

SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD

A expressão BANCO DE DADOS, é coloquialmente empregada com os mais diversos significados, de tal
sorte que, ao indagarmos de alguém sobre o BANCO DE DADOS com o qual trabalha em sua empresa,
poderemos obter as seguintes respostas:

1. Trabalho com ORACLE, ACCESS, SQL SERVER, SYBASE, etc..

2. Trabalho com o banco de dados de PESSOAL, MATERIAL ou FINANÇAS;

3. Trabalho com o CADASTRO DE PESSOAL, SISTEMA DE VENDAS, etc.

Para evitar conflitos terminológicos, definimos a seguir três expressões, consagradas na a literatura
clássica, que seriam melhor aplicadas a cada uma das situações anteriores.

1. SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD

Essa expressão estará corretamente empregada, quando utilizada para designar o SOFTWARE
utilizado para criar um BANCO DE DADOS. Portanto, tratando-se de SGBD estaremos nos referindo a
produtos como ACCESS, ORACLE, SYBASE, SQL SERVER, ADABAS, etc.

2. BANCO DE DADOS - BD

Esse enunciado refere-se a um conjunto de informações relacionadas, que são armazenadas no

computador e recuperadas com a utilização dos recursos de um SGBD. Essas informações devem ser
estruturadas, de tal maneira, que independam de aplicações específicas. Ou seja, um BD de
PESSOAL, adequadamente estruturado, pode fornecer dados, tanto para um sistema de Folha de
Pagamento, quanto para um sistema de Treinamento de Recursos Humanos.

3. SISTEMA EM BANCO DE DADOS - SBD

Essa expressão refere-se às APLICAÇÕES desenvolvidas para atender às necessidades específicas

da empresa, que acessam um ou mais BD para leitura ou atualização de informações. Tome como
exemplo de aplicações específicas os sistemas de folha de pagamento e Treinamento de Recursos
Humanos, citados no item anterior.

A figura abaixo ilustra um ambiente onde o BANCO DE DADOS de alunos foi estruturado para atender a
quatro SISTEMAS distintos: CADASTRO DE ALUNOS, CONTROLE DE MENSALIDADES, EMPRÉSTIMO
DE LIVROS e CONTROLE DE NOTAS. O BD foi montado utilizando os recursos do SGBD SQL SERVER.

10
 Banco de Dados ALUNOS
CONTROLE DE
CADASTRO MENSALIDADES
DE ALUNOS

SECRETARIA
TESOURARIA

SGBD SQL SERVER

EMPRÉSTIMOS
DE LIVROS
CONTROLE DE NOTAS
DE NOTAS

BIBLIOTECA
PEDAGOGA

11
 CAPÍTULO IV

OBJETIVOS DE BANCO DE DADOS

O desenvolvimento da tecnologia de banco de dados tem se pautado por buscar alcançar, como objetivo
permanente o aumento de produtividade nas atividades de desenvolvimento e manutenção de sistemas.
Nesse sentido os fabricantes de SGBD vem dotando seus produtos com mecanismos que facilitam a
adaptação dos BD às novas necessidades que surgem no dia a dia e que reduzem o trabalho de
programação. Aliado a esses dois fatores existe toda uma filosofia que orienta os técnicos na escolha do
melhor produto para a sua empresa e no trabalho de projeto de banco de dados.

Dessa filosofia destacamos, a seguir, alguns objetivos de BD, os quais um profissional deve ter em mente
ao lidar com essa tecnologia.

1. INDEPENDÊNCIA DE DADOS

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. Esse objetivo visa 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.

Quanto maior o grau de independência de dados, menor será o tempo em que o BD ficará fora de
operação para atividades de manutenção como, por exemplo, recompilação.

Até hoje, a maneira mais eficiente adotada pelos fornecedores de SGBD para implementação desse
objetivo foi a utilização do SQL (structured query language) nos produtos que seguem o Modelo
Relacional. O SQL 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).

2. COMPARTILHAMENTO DE DADOS

Consiste na reutilização dos dados do BD pelo maior número possível de aplicações dentro da
empresa. Nesse sentido, os dados do BD devem ser muito bem planejados e estruturados. Portanto,
este objetivo de banco de dados está mais ligado a atividade de análise e projeto de BD.

O compartilhamento de dados visa diminuir a redundância de dados, considerando-o como um recurso

da empresa e não propriedade de setores isolados da organização.
Para implementar o compartilhamento de dados é necessário que a empresa disponha de recursos de
rede, que permitam colocar o BD ao alcance dos diversos usuários. Além disso, é 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.

3. MENOR REDUNDÂNCIA DE DADOS

Redundância de dados consiste na repetição de um mesmo dado em diversos arquivos (tabelas) de

um sistema, banco de dados, ambiente computacional ou empresa. Como exemplo, pode-se tomar a
ocorrência do dado “NOME DO FUNCIONÁRIO”, em bases de dados não compartilhadas dos sistemas
de CADASTRO, FOLHA DE PAGAMENTO e TREINAMENTO de uma empresa.

A redundância é danosa para o ambiente computacional, pois aumenta os custos com o

armazenamento de dados, com o pessoal para manutenção de sistema.

12
 Além disso, a redundância gera inconsistência de dados, ou seja, o dado redundante extraído a partir
de arquivos diferentes apresenta valores divergentes. Tal fato, pode afetar a credibilidade do usuário
no sistema e no pessoal de informática.

4. PRIVACIDADE DE DADOS

O COMPARTILHAMENTO DE DADOS leva um grande número de usuários, com funções

diversificadas na empresa, a acessar um mesmo banco de dados. Nesse contexto, o objetivo de
privacidade de dados ressalta a preocupação que o projetista de BD deve ter em vedar o acesso de
usuários não autorizados a informações sigilosas ou de acesso restrito.

Nesse sentido, o sistema de segurança dos SGBD, deve possuir meios para que o projetista possa
definir perfis diferenciados de acesso ao BD, com a criação de grupos de usuários e atribuição de
direitos de acesso a esses grupos, a partir da utilização de senhas.

5. SEGURANÇA DE DADOS

A segurança das informações armazenadas no BD pode ser encarada sob dois prismas: SEGURANÇA
LÓGICA e SEGURANÇA FÍSICA.

A SEGURANÇA LÓGICA é alcançada com a utilização dos mecanismos de restrição de acesso

disponíveis nos SGBD para implementação do objetivo de privacidade de dados, tais como senhas e
sistemas de LOG e AUDIT que registram dados sobre as operações que são efetuadas no BD (data,
hora, usuário, comando, etc.).

A SEGURANÇA FÍSICA dos dados é 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, GRAVAÇÃO COM ESPELHAMENTO e SISTEMAS DE MONITORAÇÃO DE
TRANSAÇÕES DISTRIBUÍDAS (TWO-PHASE-COMMIT).

6. TRATAMENTO DE CONCORRÊNCIA

Este objetivo de BD aborda o aspecto do acesso simultâneo de dois usuários a um mesmo conjunto de
informações. O SGBD deve possuir mecanismos para a identificação e tratamento desses 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 usuário (“USU1”) seja alterada por outro
(“usu2”). Enquanto o “USU1” dela se utiliza o ‘USU2”, não terá acesso a mesma 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 ser modificada.

Existem vários níveis de LOCK. As opções variam conforme o produto (SGBD) analisado, sendo que
os mais comuns ocorrem a nível de tabela, página (conjunto de registros) e linha (nível mais baixo).

Cabe lembrar que o nível de bloqueio influi na performance do SGBD em ambientes de missão crítica
(altos índices de acesso concorrente), sendo que quanto menor o nível de LOCK, a performance tende
a ser melhor. Ressalta-se que além desse, existem outros fatores que influenciam na performance do
SGBD.

7. INTEGRIDADE DE 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.

Esse objetivo só se tornou disponível, como recurso do SGBD, com o advento dos modelos
Relacionais e consta como pré-requisito para enquadramento de produtos nessa categoria de SGBD.

No capítulo dedicado aos SGBD relacionais trataremos esse assunto com maior riqueza de detalhes.

13
 CAPÍTULO V

LINGUAGENS DE BANCO DE DADOS

As linguagens de banco de dados consistem na interface do usuário para interagir com o SGBD. Neste
texto destacamos quatro modalidades de linguagens que são mais comumente utilizadas nessa interação:
SQL, autocontida, hospedeira e visuais. Esta é uma classificação meramente didática que objetiva apenas
demostrar formas diferenciadas de interação com o BD. Outros autores possuem diferentes classificações.

1. SQL (STRUCTURED QUERY LANGUAGE)

A linguagem SQL (anteriormente escrita SEQUEL) foi criada junto com o Sistema R, primeiro protótipo
de SGBD-R, desenvolvido de 1974 a 1979 no IBM San Jose Research Laboratory. A vesão original do
SQL foi baseada em uma linguagem anterior chamada SQUARE. As duas linguagens são
essencialmente a mesma, mas a SQUARE usa uma sintaxe bem mais matemática, enquanto a SQL é
mais parecida com o inglês.

A linguagem SQL é mais do que somente uma linguagem de consulta, sem que isto se oponha ao
“query” no seu nome. Ela fornece funções de recuperação e atualização de dados, além de criação,
manutenção da estrutura de dados e controle do ambiente do BD.

É uma linguagem essencialmente interativa, porém pode ser embutida em outras linguagens procedurais
(que neste texto chamamos linguagem hospedeira) para ser utilizada em programas batch ou on-line,
que acessam o BD. Suas principais características são:

_ Padrão ANSI (American National Standard Institute). O ANSI estabeleceu-se como um “padrão de fato”
de SQL para os fornecedores de produtos relacionais, que atualmente lideram o mercado. Este aspecto
facilita a interoperabilidade entre BDs de diferentes fornecedores.

_ Padrão de acesso. Todo o acesso ao BD Relacional é feito em SQL, mesmo que embutida em outra
linguagem.

_ Interpretada (não compilada), característica que provê maior grau de independência de dados aos BD
relacionais, ou seja, faz com que a aplicação reconheça alterações nas estruturas de dados, sem
necessidade de ser recompilada.

_ DDL, DML e DCL. O SQL possui esses três grupos de comandos, montados conforme a função do
comando no banco de dados. Esta característica também relaciona-se à independência de dados, uma
vez que pode-se descrever os dados (DCL) de forma independente das aplicações (DML).

_ DDL (Data Definition Languge). Linguagem para definição de dados, que compreende os seguintes
comandos SQL:
_ CREATE - Utilizado para criar objetos (tabela, índice, view, sequence, etc.) no BD.

Exemplo: Criação da tabela funcionário com os atributos matricula e nome.

CREATE TABLE funcionário

(matricula number(05)
nome char (30);
_ ALTER - Utilizado para alterar objetos do BD (adicionar colunas, modificar tipo de dados, adcionar
integridade, etc.).

Exemplo: Adição da integridade de chave primária à tabela funcionário.

ALTER TABLE funcionário

ADD CONSTRAINT PRIMARY KEY (matricula);

_ DROP - Exclui objetos do BD.

14
Exemplo: Exclusão da tabela funcionário do BD.
DROP TABLE funcionário

15
 _ DML (Data Manipulation Languge). Linguagem para manipulação de de dados, que compreende os
comandos para que o usário interaja com os dados armazenados no BD.
SELECT - Comando de leitura, utilizado para que o usuário possa efetuar consultas (query) nas
tabelas do banco de dados. É o comando mais poderoso do SQL, efetua as sete operações da
algebra relacional conforme veremos no capítulo VIII. Seu formato básico é SELECT-FROM-
WHERE (leia-de-onde). Pode ser combinado com os demais comandos SQL constituindo “sub-
queries”. O resultado de todo comando SELECT é uma tabela, que pode conter uma, nenhuma ou
N linhas.
Exemplo: Ler da tabela funcionário “matricula” e “nome”, onde o salário seja maior do que 500,00.

SELECT matricula, nome

FROM funcionário
WHERE salário > 500,00;

INSERT - Utilizado para incluir registros nas tabelas do banco de dados.

Exemplo: Inclusão de um registro na tabela funcionário.

INSERT INTO funcionário (matricula, nome)

VALUES ( 20,’Maria do Carmo’);

UPDATE - Utilizado para alterar dados nas tabelas do banco de dados.

Exemplo: Alteração no salário do funcionário de matrícula igual a 20.

UPDATE funcionário
SET salário=1200
WHERE matricula=20;

DELETE - Utilizado para excluir registros das tabelas do banco de dados.

Exemplo: Exclusão do funcionário de matrícula igual a 20.

DELETE funcionário
WHERE matricula=20;

2. LINGUAGEM AUTOCONTIDA

Esta modalidade de linguagem é a extensão procedural do SQL, que nos SGBD-R é utilizada para
desenvolvimento de programas que ficam residentes no banco de dados (TRIGGERS, STORED
PROCEDURES, FUNCÕES). Acrescenta ao SQL interativo estruturas de decisão (IF-THEN-ELSE) e
repetição (LOOP, FOR e/ou DO WHILE). É uma linguagem proprietária (Cada SGBD possui a sua). Os
programas escritos nessa linguagem geralmente assemelham-se a programas PASCAL.

3. LINGUAGEM HOSPEDEIRA

São linguagens procedurais de 3ª geração (notadamente o COBOL) utilizadas como hospedeiras (host)
de comandos próprios de banco de dados. Linguagens hospedeiras foram muito utilizadas nos SGBD
dos modelos Hierárquicos e Rede, dado que nestas gerações de SGBD ainda não existia o SQL com
toda a sua simplicidade e potencialidade. Por outro lado, imperava uma forte cultura nas linguagens
COBOL, PL/1, FORTRAN, etc.... que foi aproveitada pelos fabricantes de SGBD, facilitando a
introdução dessa nova cultura.

Os SGBD que utilizam linguagens hospedeiras. possuem um software PRÉ-COMPILADOR, que é

inserido na rotina de compilação do fonte do programa hospedeiro, para converter os comandos de BD
(estranhos à linguagem HOST) em linguagem objeto ou chamadas (CALL) de rotinas inteligíveis pelo
compilador a linguagem.

16
 Esquema de compilação com linguagem hospedeira:

PROGRAMA
FONTE
HOSPEDEIRO

PRÉ_
COMPILADOR

PROGRAMA
PRÉ_
COMPILADO

PROCESSO
NORMAL DE
COMPILAÇÃO

4. LINGUAGEM VISUAL

As linguagens visuais atualmente dominam o ambiente de desenvolvimento para a arquitetura

Cliente/Servidor. Nessa arquitetura, são utilizadas para desenvolver a interface Cliente da aplicação.
Recebem a denominação de FRONT-END. Geram aplicações para ambiente gráfico, padrão
WINDOWS. São orientadas a eventos e em sua maioria, baseiam-se na tecnologia de Orientação a
Objetos, apresentando recursos como classe, objeto, herança, polimorfismo, etc.. Utilizam o SQL
como linguagem para acesso aos bancos de dados relacionais, através de APIs (Aplication Program
Interface) nativas ou genéricas (ex: ODBC e ODAPI).

Nossa maior preocupação neste texto é chamar a atenção do leitor para o fato de que essas
linguagens são FRONT_ENDs de SGBD relacionais. Apesar de serem orientadas a objeto, não devem
ser confundidas com os BD Orientados a Objeto, que ainda são uma tecnologia emergente.

Esquema de acesso a BD relacional com linguagem visual:

SQL SQL PARÃO

PRGRAMA EM
LIGUAGEM API BD-R
VISUAL
DADOS DADOS

17
 CAPÍTULO VI

MODELO HIERÁRQUICO

Os primeiros SGBD lançados no mercado foram os do tipo HIERÁRQUICO. Nessa categoria, o

SOFTWARE de maior aceitação, no mercado brasileiro, foi o IMS da IBM.

1. Limitações dos modelos HIERÁRQUICOS

a. Relacionamentos, no máximo, de grau “1: N”. O processo de implementação dos relacionamentos do

tipo M:N, ocasiona alto grau de redundância e / ou torna-se ineficaz.

FORNECEDOR FORNECEDOR

1 N

b. O

N
N
FATURA PRODUTO

Banco de dados só pode ter um SEGMENTO RAIZ

e cada SEGMENTO FILHO pode ligar-se a um
único SEGMENTO PAI.

SEGMENTO PROFESSOR PROFESSOR ALUNO

RAIZ

1 1 1 1

N N N N

ALUNO MATÉRIA MATÉRIA

c. Não implementam AUTO- RELACIONAMENTOS.

18
 É COMPOSTA

PEÇA

COMPÔE

d. Não permitem dupla ligação entre duas entidades:

FORNECEDOR

1 1
FORNECE FABRICA

N N

PEÇA

e. Estruturas percorridas somente no sentido de cima para baixo. No exemplo abaixo, poder-se-ia
facilmente listar “FATURA” a partir da entidade “CLIENTE”, porém, o caminho inverso não seria
possível.

CLIENTE CLIENTE

1 1

N N

FATURA FATURA

19
 CAPÍTULO VII

MODELO REDE

Os SGBD do modelo REDE corrigiram as limitações dos HIERÁRQUICOS e mereceram a formação de um

grupo da CODASYL. (Conferencie on Data Systems Langues) designado pela sigla DBTG (Data Base Task
Group). Assim, esse modelo ficou também conhecido como CODASYL ou DBTG. O relatório final do
DBTG data de abril de 1971.

Como exemplos de SGBD/REDE, que seguiram o padrão CODASYL, citamos: DMS-1100 da UNIVAC, IDS
da Honeywell, DBMS da DEC e o IDMS da Cullinet, que mais tarde foi estendido incorporando uma vis ão
relacional dos dados e algumas operações relacionais (IDMS-R).

1. CARACTERÍSTICAS DOS MODELOS REDE CODASYL

a. Os RELACIONAMENTOS são do tipo BINÁRIOS (duas entidades), possuem nome e são

IMPLEMENTADOS através da criação de SETs. Cada SET possui uma entidade pai (OWNER) e
outra filho (MEMBER).

FORNECEDOR OWNER

SET NAME IS paga

1 criação do SET PAGA
SET PAGA OWNER IS fornecedor
na ddl do SGBD
MEMBER IS fatura
N

FATURA MEMBER

b. Os SETs possuem internamente ponteiros físicos (FIRST, LAST NEXT, PRIOR, OWNER) que
relacionam os registros e permitem a navegação no banco de dados com alta flexibilidade.

OWNER
REGISTRO OWNER
OWNER
PRIOR

FIRST REGISTRO MEMBER

PRIOR

NEXT
REGISTRO MEMBER
LAST

20
c. As estruturas podem ser percorridas nos dois sentidos - de pai para filho (através dos ponteiros NEXT,
FIRST e LAST) e no sentido inverso (através dos ponteiros PRIOR e OWNER).

CLIENTE

1
FIRST PRIOR
NEXT
LAST OWNER
N

FATURA

d. Um registro filho (MEMBER) pode relacionar-se com mais de um registro pai (OWNER),
caracterizando REDE, que serve como designação para o modelo de banco de dados em questão.
A estrutura REDE é usada na implementação dos relacionamentos do tipo “M:N”, que são
transformados em dois relacionamentos do tipo “1:N”, através da criação de uma ENTIDADE
ASSOCIATIVA.

OWNER1 OWNER2
PROFESSOR
PROFESSOR ALUNO
N e.
1 1

SET1 PROF-MAT SET2 ALUNO-MAT

N

ALUNO N MEMBER N
Permitem dupla ligação entre duas entidades.
Pelo exemplo abaixo poderíamos saber todas as MATÉRIA
peças que o FORNECEDOR fornece e quais são
as que ele fabrica.
ENTIDADE ASSOCIATIVA

FORNECEDOR

SET1 1 1 SET2
FORNECE FABRICA

N N

PEÇA

21
 f. O AUTO-RELACIONAMENTO é transformado em relacionamento BINÁRIO simulando-se uma
entidade OWNER ou MEMBER, conforme o caso. A entidade simulada deve conter o ATRIBUTO
CHAVE e os PONTEIROS a ela inerentes .

É GERENCIADO GERENTE

N
1
FUNCIONÁRIO
GERENCIA

1 N

GERENCIA FUNCIONÁRIO

Apesar das características técnicas positivas já evidenciadas, os modelos Rede são pouco flexíveis no que
se refere a alterações nas estruturas de dados, sua cultura é de difícil assimilação pelo usuário final e até
mesmo por técnicos. Além disso, esses SGBD apresentam alguns problemas de desempenho e na
manutenção de ponteiros.

Em função dessas dificuldades e do salto tecnológico que experimentamos a partir da popularização dos
microcomputadores, os SGBD Rede cederam espaço para o modelos Relacionais, que hoje constituem-se
no padrão de mercado.

22
 CAPITULO VIII

BANCO DE DADOS RELACIONAL

O Modelo Relacional de Banco de Dados utiliza a teoria de conjuntos como base conceitual para a
formulação de seus conceitos. Esse pressuposto facilita o entendimento por parte do usuário e possibilita a
representação do mundo real de forma mais natural.

O Modelo Relacional começou a ser divulgado a partir de 1970, por E. F. Codd, um cientista da IBM, que
utilizou o SISTEMA-R como produto experimental para a comprovação da teoria Relacional, publicada em
uma série de artigos, que apresentaram os requisitos desse modelo em doze regras atualmente seguidas
pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBD-R).

As doze regras de Codd foram reeditadas por diversos autores que escreveram sobre o modelo Relacional.
Em nossa pesquisa bibliográfica para elaboração desse material, notamos que, existem interpretações
ambíguas e até contraditórias em relação a essas regras. Portanto, para nortear o estudo do modelo
Relacional, adotamos a abordagem de C. J. DATE, que apresenta o Modelo Relacional como possuindo as
seguintes características fundamentais, que o distingue dos demais modelos:

_ Estrutura de dados tabular

_ Regras de integridade
_ Operadores relacionais
_ Utilização do SQL (Structured Query Language)

O modelo Relacional, assim como seus antecessores, nasceu no ambiente dos computadores de grande
porte (mainframe). Sofreu restrições ao uso, por demandar muita memória principal para alcançar uma
performance (tempos de resposta) que o tornasse comercialmente viável. Ganhou força a partir do início a
década de 80, com a revolução tecnológica provocada pela produção em larga escala dos
microcomputadores PC, o que propiciou o barateamento do hardware.

Atualmente o modelo relacional é um padrão seguido, praticamente por todos os formecedores de SGBD do
mercado, Dentre os quais destacam-se: ORACLE, SYBASE, MYCROSOFT (SQL SERVER e ACCESS),
INFORMIX e IBM DB/2.

1. TERMINOLIGIA DO MODELO RELACIONAL

a. Os SGBD RELACIONAIS representam os dados sob a forma de TABELAS bidimensionais (linhas X

colunas), denominadas RELAÇÕES.

b. As linhas das tabelas são conhecidas como TUPLAS e as colunas como ATRIBUTOS.

c. O número de atributos (colunas) de uma relação (tabela) determina o GRAU DA RELAÇÃO. Portanto
uma relação com quatro colunas possui grau quatro.

d. A interseção linha X coluna de uma tabela denomina-se CÉLULA.

e. O conteúdo de uma célula denomina-se valor de atributo.

f. Cada célula de uma tabela relacional comporta apenas um valor de atributo, característica a qual
designa-se por ATOMICIDADE (valor atômico).

g. O conjunto de valores possíveis para um atributo de tabela denomina-se DOMÍNIO. Por exemplo, o
domínio para o atributo cargo pode ser definido como: Valor numérico entre 1 e 10.

23
 ATRIBUTO

RELAÇÃO: FUNCIONÁRIO
MATR NOME CARGO DT_NASC
01 MIRIAM 01 25/09/62
TUPLA
02 JUVENAL 03 18/04/70
ATRIBUTO
03 GABRIELA 02 10/02/68

VALOR DE
CÉLULA ATRIBUTO

2. REGRAS DE INTEGRIDADE

Integridade de dados é o conjunto de parâmetros (regras do negócio) previamente estabelecidos e

criados no banco de dados, aos quais os dados são submetidos, para garantir que de um processo de
atualização não resultem dados inconsistentes.

Uma das características mais fortes dos SGBD-R, está em oferecer mecanismos para a criação de
regras de integridade diretamente no banco de dados. Nesse ponto a grande vantagem em relação
aos demais modelos (Hierárquico e Rede), consiste n o gerenciamento automático e centralizado de
rotinas de integridade pelo SGBD, do que decorrem fatores como a eliminação de códigos redundantes
e maior segurança no que se refere à consistência das informações.

Por outro lado, a possibilidade de definir integridade no BD, não descarta a hipótese de mante-la na
fonte da aplicação que acessa o BD. Na arquitetura Cliente/Servidor, essa prática é muito corriqueira e
pode trazer significativos ganhos de performance.

As regras de integridade de dados podem ser implementadas nos SGBD-R de forma DECLARATIVA
ou PROCEDURAL:

a. INTEGRIDADE DECLARATIVA

A integridade declarativa é implementada no BD, através de parâmetros opcionais da linguagem de

definição de dados (DDL). Os tipos mais comuns de integridade declarativa são: CHAVE PRIMÁRIA,
DOMÍNIO e INTEGRIDADE REFERENCIAL.

A integridade de CHAVE PRIMÁRIA garante que a chave primária da tabela não contenha valores em
duplicata e nem valor NULO.

A integridade de DOMÍNIO permite restringir o universo de valores válidos para uma coluna.

A integridade REFERENCIAL garante o sincronismo de valores entre a chave estrangeira (foreign key)
e a respectiva chave primária. Esse tipo de integridade será tratado com maiores detalhes no item “c”
deste capitulo.

Na DDL do ORACLE, por exemplo, o comando CREATE apresenta as seguintes opções de integridade
declarativa:

_ PRIMARY KEY - Garante a integridade de chave primária.

_ NOT NULL - Torna o campo de preenchimento obrigatório.
_ CHECK - Permite a integridade de domínio.
_ UNIQUE - Evita a ocorrência de valores em duplicata.
_ FOREIGN KEY - Implementa a integridade referencial.

24
 Exemplo:

CREATE TABLE funcionário

(matricula number(05) PRIMARY KEY
nome char (30) NOT NULL
sexo char (01) CHECK sexo = ‘F’ or ‘M’;

No exemplo, o ORACLE encarrega-se da integridade de chave primária (PRIMARY KEY), da condição

de campo obrigatório (NOT NULL) e da integridade de domínio (CHECK), todas especificadas de forma
declarativa. Nenhuma linha de código é necessária nos programas que acessam BD para garantir
essas integridades.

b. INTEGRIDADE PROCEDURAL

A Integridade Procedural apresenta-se sob a forma de um programa, cuja lógica é escrita pelo
programador, na linguagem procedural nativa do SGBD. Esse tipo de integridade supre as
necessidades não cobertas pelos parâmetros de integridade declarativa.

No ORACLE a integridade procedural pode ser criada através de TRIGGERS, STORED

PROCEDURES ou FUNÇÕES DO USUÁRIO. Estes elementos são escritos em PL/SQL que é a
extensão procedural do SQL desse SGBD.

Um TRIGGER (gatilho) é criado para disparar, automaticamente, sempre que o SGBD detectar a
ocorrência de um ou mais comandos de acesso a tabela.

Exemplo:

CREATE TRIGGER atualiza_saldo

AFTER INSERT ON TABLE lançamentos
BEGIN
UPDATE Tab_saldo
SET saldo_atual=saldo_atual + valor_lançamento;
END;

No exemplo, sempre que um registro for incluído na tabela “lançamentos” o trigger dispara e atualiza o
“saldo_atual” na tabela “tab_saldo”.

Nem todos os SGBD possuem integridade procedural. Esse recurso é mais freqüente nos SGBD de
maior porte como ORACLE, DB/2, INFORMIX, SQL SERVER, etc..

c. INTEGRIDADE REFERENCIAL

A Integridade Referencial é o mecanismo dos SGBD-R que, no processo de atualização do BD,

mantém o sincronismo entre duas tabelas relacionadas, em relação aos valores da chave
estrangeira e da respectiva chave primária.

TABELA PAI FUNCIONÁRIO

MATRICULA -
PK
1

N
TABELA FILHO DEPENDENTE
MATRICULA- FK

A integridade referencial evita a ocorrência de registros órfãos no banco de dados, ou seja, registros
“filhos” sem a correspondente linha de referencia na tabela “pai”.

25
 Os SGBD_R que seguem o padrão SQL ANSI/92, suportam a integridade referencial de forma
declarativa. Possuem ainda ações referenciais, que propagam atualizações e exclusões efetuadas
na tabela pai para a tabela filho.

As ações referenciais propiciam, por exemplo, que a exclusão de um registro pai provoque a
exclusão automática de seus respectivos filhos (exclusão em cascata), ou que a alteração no valor
de uma chave primária reflitam automaticamente para os registros que a referenciam (atualização
em cascata).

Exemplo:

CREATE TABLE funcionário

(matricula number(05) PRIMARY KEY
nome char (30)
sexo char (01));

CREATE TABLE dependente

(id_dependente number(05) PRIMARY KEY
nome_dependente char (30)
data nascimento date
matricula_funcionário number(05) FOREIGN KEY

REFERENCES funcionário.matricula
ON DELETE CASCADE);

O exemplo apresenta a integridade referencial, declarada na tabela “dependente”, indicando que o

campo “matricula_funcionário” dessa tabela, refere-se ao campo “matricula” da tabela “funcionário”.
Com essa declaração o SGBD garante que a inclusão de um “DEPENDENTE”, somente será valida
caso exista o “FUNCIONÁRIO” correspondente.

Por outro lado, a cláusula “ON DELETE CASCADE” indica que sempre que for excluído um registro
da tabela “funcionário”, o SGBD deve excluir automaticamente os registros da tabela dependente a
ele relacionados.

3. OPERADORES RELACIONAIS

Os Operadores Relacionais constituem mecanismos do SGBD-R para recuperação de informações no

Banco de Dados. Inserem-se no contexto da Álgebra Relacional que possui sete operadores, sendo
três relacionais (PROJEÇÃO, SELEÇÃO e JUNÇÃO) e quatro operadores tradicionais de conjunto
(UNIÃO, INTERSEÇÃO, DIFERENÇA e PRODUTO CARTEZIANO).

Para que um SGBD seja considerado relacional basta que possua apenas os operadores relacionais.
Os operadores de conjunto podem ser simulados a partir dos primeiros.

No SQL/ANSI, os sete operadores são implementados por variações nas cláusulas do comando
SELECT.

No capítulo VIII trataremos dos operadores relacionais com exemplos da aplicação de cada um deles.

4. PROPRIEDADES RELACIONAIS

As Propriedades relacionais são considerações óbvias, porém elucidativas a respeito do funcionamento

e da filosofia que norteia o desenvolvimento dos SGBD-R. Essas propriedades derivam da teoria de
conjuntos e algumas se sobrepõem ou confirmam as regras de integridade.

a. Uma tabela não deve possuir duas linhas iguais. Isto se explica pelo fato de que as linhas são
componentes de um conjunto (a tabela) e se faz necessário poder distinguir os elementos de um
conjunto. Assim sendo, pelo menos um atributo componente da linha deve possuir um valor que a

26
diferencie das demais. Nos modelos relacionais o diferencial mínimo entre duas linhas de uma tabela é
a chave primária.

b. Toda a tabela de um BD relacional deve possuir chave primária. Essa propriedade decorre da
anterior. Atualmente, todos os SGBD-R disponíveis no mercado mantém automaticamente a unicidade
da chave primária. Por outro lado, alguns produtos relacionais permitem a criação de tabelas sem PK,
deixando a critério do analista a sua declaração ou não, o que contraria esta propriedade mas atribui
maior flexibilidade ao produto.

c. Cada tabela deve possuir um nome próprio, distinto das demais tabelas do mesmo banco de dados.
Essa propriedade também deriva da teoria de conjuntos, já que as tabelas são componentes do
conjunto BD. Ressalta-se que em banco de dados distintos duas tabelas podem ter o mesmo nome.

d. Cada atributo de uma mesma tabela deve possuir um nome diferente. Por outro lado, o mesmo
atributo pode aparecer em outra tabela com o mesmo nome ou com nome diferente (sinônimo).

e. Os SGBD-R somente operam com estruturas de dados de formato tabular, normalizadas pelo menos
em !FN (1ª forma normal), onde a principal característica é a atômicidade, ou seja, ocorrência de
apenas um valor de atributo para cada célula da tabela. Esse nível de normalização é exigido para
tornar possível a aplicação da Álgebra Relacional para recuperar informações contidas nas tabelas do
BD. Níveis mais altos de normalização (2FN a $FN) são úteis para diminuir a redundância, melhorar a
consistência e integridade dos dados.

f. A ordem das linhas e colunas na tabela é irrelevante, pois pode ser facilmente modificada nas
consultas, através dos recursos da linguagem SQL (Structured Query Language).

g. Os SGBD-R devem ser capazes de tratar, de maneira diferenciada o valor NULO (NULL), que indica
ausência de valor para um atributo em determinada linha. Nulo corresponde na teoria de conjuntos a
conjunto vazio e é diferente de zero ou branco.

5. VANTAGENS DO MODELO RELACIONAL

As vantagens em relação aos sistemas de arquivos convencionais e SGBD Hierárquicos e Rede são:

a. Linguagem SQL interativa e muito próxima da linguagem natural escrita (inglês);

b. Facilidade no entendimento da estrutura de dados tabular;
c. Maior possibilidade de utilização direta pelo usuário final;
d. Centralização da integridade no BD.
e. Redução no tamanho dos códigos de programa;
f. Maior integridade e consistência de dados;
g. Maior segurança;
h. Maior flexibilidade para acréscimo de novas informações no BD;
i. Possibilidade de criar gatilhos (TRIGGERS) e procedimentos armazenados (STORED
PROCEDURE);
j. Maior Produtividade.
k. Padronização dos produtos facilitando a difusão e preservação da cultura relacional.

27
 CAPITULO IX

ÁLGEBRA RELACIONAL

A Álgebra Relacional é uma teoria matemática baseada nas relações entre conjuntos. Da sua aplicação ao
Modelo Relacional de Banco de Dados, resultou a possibilidade de armazenar estruturas de dados
complexas (como uma ficha cadastro de clientes), de maneira fragmentada, no formato tabular dos SGBR-
R e recompor a informação original, a partir da formulação de relações entre as tabelas do banco de dados.
Essas relações são providas pelos operadores da álgebra relacional, que se encontram disponíveis nos
recursos da linguagem SQL (Structured Query Language).
Os operadores da álgebra relacional classificam-se em dois grupos:

_ OPERADORES TRADICIONAIS DE CONJUNTO

. UNIÃO
. INTERSEÇÃO
. DIFERENÇA
. PRODUTO CARTESIANO

_ OPERADORES RELACIONAIS

. PROJEÇÃO
. SELEÇÃO
. JUNÇÃO

Para classificar-se um SGBD como Relacional, é fundamental que ele possua, entre outras características,
no mínimo os três operadores relacionais, haja vista que, nem todos os SGBD-R possuem os sete
operadores. Os Operadores Tradicionais são mais encontrados em SGBD mais robustos, como ORACLE,
SYBASE e DB/2.

1. ESTUDO DE CASO

O gráfico abaixo corresponde ao Modelo de Entidades e Relacionamentos (MER) de um banco de

dados, que será utilizado como referência para o estudo dos operadores relacionais.

CLIENTE

CONTA

Segue uma amostragem das tabelas do banco de dados representado no MER:

28
CLIENTE

ID-CLI NOME ENDEREÇO TIPO C = COMUM

001 RITA SQN V E= ESPECIAL
002 MARCELO GUARÁ C V= VIP
003 CARLA GAMA E
004 VÍTOR SQS C
005 RAQUEL SQS E
006 BRUNA GUARÁ V
007 SÔNIA CRUZEIRO C
008 GETÚLIO SQN C

CONTA_CORRENTE
NUM-
AGENCIA CONTA ID-CLI SIT SALDO
106 001 004 0 20.000,00
106 002 003 2 250,00
106 040 003 0 500,00
167 001 005 0 50,00
167 005 007 0 10,00
167 006 008 2 20,00
202 001 001 0 150,00
202 002 003 1 0
202 003 002 0 30,00
202 004 004 2 50.000,00

0 = ATIVA
1 = INATIVA
2 = BLOQUEADA
2. GENERALIDADES

a. Nos SGBD que utilizam o SQL padrão ANSI (Americam National Standard Institute), os
operadores da Álgebra Relacional são implementados por variações de parâmetros na sintaxe do
comando SELECT, que é um comando de leitura da base de dados.

b. A sintaxe utilizada para os comandos SELECT, que aparecerão nos exemplos, foi extraída dos
manuais do SGBD ORACLE, que segue o padrão SQL ANSI. A estrutura básica do comando SELECT
é:

SELECT colunas.... ou * (que significa todas as colunas)

FROM tabelas .....
WHERE condição........

c. As operações da álgebra relacional geram sempre uma tabela resultado residente em memória
principal (tabela virtual), que em analogia com a teoria de conjuntos, pode ser vazia, unitária ou conter
“N” linhas.

d. As operações podem ser efetuadas entre duas tabelas virtuais através da combinação de dois
comandos SELECT em uma única sentença.

e. É comum a combinação de diversos operadores da Ágebra Relacional em um único comando

“SELECT”. A análise individual de cada um deles é um exercício meramente didático.

f. As situações criadas, são apenas ensaios, que não esgotam as possibilidades de utilização dos
operadores. Além disso, uma mesma necessidade pode ter mais de uma solução. Portanto a utilidade
dos operadores depende do problema tratado e da criatividade do técnico.

29
3. OPERADORES DE CONJUNTO

a. UNIÃO

A união de duas tabelas “A” e “B”, resulta numa tabela virtual “C”, contendo o total de linhas das
tabelas envolvidas na operação.

No sistema exemplo, imagine que cada agência mantenha os dados cadastrais de CLIENTE em
servidores locais de sua rede, e que esses servidores estão ligados em um servidor corporativo. Para
se obter no servidor corporativo uma visão única, que contenha os dados de todos os clientes do
Banco, pode-se utilizar o operador UNION da seguinte maneira:

SELECT * FROM cliente@agencia1;

UNION
SELECT * FROM cliente@agencia2;
.
.
UNION
SELECT * FROM cliente@agenciaN;

O resultado seria idêntico ao que temos na amostragem da tabela CLIENTE do sistema exemplo:

ID-CLI NOME ENDEREÇO TIPO

001 RITA SQN V
002 MARCELO GUARÁ C
003 CARLA GAMA E
004 VÍTOR SQS C
005 RAQUEL SQS E
006 BRUNA GUARÁ V
007 SÔNIA CRUZEIRO C
008 GETÚLIO SQN C

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqüência.

b. INTERSEÇÃO

A Interseção entre duas tabelas “A” e “B”, resulta numa tabela virtual “C”, contendo as linhas comus
às duas tabelas envolvidas na operação.

No sistema exemplo, considere a necessidade de se listar o “ID-CLI" de clientes que possuam,

simultaneamente, CONTAS_CORRENTES ativas e bloqueadas. Para atender a esse requerimento,
pode-se utilizar o operador INTERSECT da seguinte maneira:

SELECT id_cli
FROM conta_corrente
WHERE sit = 0
INTERSECT
SELECT id_cli
FROM conta_corrente
WHERE sit = 2;

Considerando a amostragem da tabela CONTA_CORRENTE do sistema exemplo, o resultado do

SQL anterior seria:

ID-CLI
004
003

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqüência.

30
c. DIFERENÇA

A Diferença entre duas tabelas “A” e “B” (na ordem A - B), resulta numa tabela virtual “C”, contendo
as linhas pertencentes exclusivamente à tabela “A” e não a “B”.

No sistema exemplo, considere a necessidade de se listar o “ID-CLI" de clientes que não possuam
contas_correntes INATIVAS ou BLOQUEADAS, somente ATIVAS. Para atender a esse requerimento,
pode-se utilizar o operador MINUS da seguinte maneira:

SELECT id_cli
FROM conta_corrente
WHERE sit = 0
MINUS
SELECT id_cli
FROM conta_corrente
WHERE sit = 2 OR sit = 1;

Considerando a amostragem da tabela CONTA_CORRENTE do sistema exemplo, o resultado do

SQL anterior seria:

ID-CLI
005
007
001
002

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqüência.

d. PRODUTO CARTESIANO

A Produto Cartesiano entre duas tabelas “A” x “B” resulta numa tabela virtual “C”, contendo todas as
linhas da tabela “A” combinadas com todas as linhas da tabela “B”, através da concatenação de
suas linhas.
Essa operação tem uma certa semelhança com a JUNÇÃO, pois combina dados de mais de uma
tabela, exceto que não estabelece nenhum critério (join condition) para isso.
Geralmente o Produto é utilizado para construção de massas de teste ou quando o técnico esquece
de colocar o “join condition” em um SELECT que envolva duas ou mais tabelas. Nesse caso, pode
resultar numa tabela enorme. Por exemplo, o produto entre uma tabela “A” com 50 linhas e uma
tabela “B’ com 100 linhas resulta numa tabela “C” com 5.000 linhas.
O SELECT a seguir efetua um produto entre as tabelas CLIENTE e CONTA_CORRENTE:

SELECT nome, saldo

FROM cliente, conta_corrente;

Considerando as amostragens das tabelas do sistema exemplo referenciadas no comando anterior, a

tabela resultado teria 80 linhas, com o seguinte aspecto:

NOME SALDO
RITA 20.000,00
RITA 250,00
RITA 500,00
. .
. .
MARCELO 20.000,00
. .
MARCELO 50,000,00
. .
31
 . .
SÔNIA 30,00
. .
. .
. .
GETÚLIO 50,000,00

3. OPERADORES RELACIONAIS

e. PROJEÇÃO

A Projeção consiste em obter um subconjunto de colunas de uma ou mais tabelas_base,

como resultado de uma consulta parcial aos dados disponíveis no banco de dados.

Geralmente é utilizada em conjunto com as demais operações para produzir resultados de

consultas, ou ainda, para criar visões (VIEWs), que restringem o acesso do usuário a
determinados atributos da base de dados.

No sistema exemplo, uma consulta contendo nome e endereço dos clientes, corresponde a uma
PROJEÇÃO elaborada a partir da tabela-base CLIENTE, através da seguinte sentença SQL:

SELECT nome, endereço

FROM cliente;

Considerando a amostragem da tabela CLIENTE do sistema exemplo, o resultado do SQL anterior

seria:

NOME ENDEREÇO

RITA SQN
MARCELO GUARÁ
CARLA GAMA
VITOR SQS
RAQUEL SQS
BRUNA GUARÁ
SÔNIA CRUZEIRO
GETÚLIO SQN

f. SELEÇÃO

Também conhecida como Restrição, essa operação tem por finalidade selecionar um subconjunto
de linhas de uma ou mais tabelas_base, de acordo com critérios (where criteria), que envolvem
atributos e valores para filtrar os dados desejados, gerando uma consulta parcial aos dados
disponíveis no banco de dados.

Geralmente é utilizada em conjunto com as demais operações para produzir resultados de

consultas, ou ainda, para criar visões (VIEWs), que restringem o acesso do usuário a
determinadas linhas de tabelas na base de dados.

Os Critérios de Seleção são traduzidos na sintaxe do comando SELECT, pela combinação de

operadores lógicos (AND, OR, NOT), aritiméticos (=, <>, >, <, >= e <=) e operadores SQL
(BETWEEM, LIKE, IN, NULL), representados na cláusula WHERE.

No sistema exemplo, uma consulta contendo somente os clientes VIP, corresponde a uma SELEÇÃO
elaborada a partir da tabela-base CLIENTE, através da seguinte sentença SQL.

Considerando a amostragem da tabela CLIENTE do sistema exemplo, SELECT *

o resultado do SQL anterior seria: FROM cliente
WHERE tipo = ‘V’;
ID-CLI NOME ENDEREÇO TIPO
001 RITA SQN V

32
 006 BRUNA GUARÁ V

g. JUNÇÃO

Essa operação relacional é utilizada para compor informações complexas a partir de tabelas
relacionadas. A junção de duas tabelas “A” e “B” concatena as linhas das tabelas envolvidas,
resultando numa tabela virtual “C”.

Para efetuar a JUNÇÃO de duas tabelas é essencial que elas estejam logicamente relacionadas,
conforme prevê o modelo relacional, ou seja, o grau do relacionamento deve ser no máximo “1 :
N”, sendo que a chave primária da entidade “1” deve figurar como chave estrangeira da entidade
“N”. Além disso, os valores dessas chaves devem ser coincidentes, para as linhas que se deseja
concatenar.

A junção é notada na sintaxe do SQL, pela comparação de atributos chave primária / chave
estrangeira, através da cláusula WHERE do comando SELECT, o que denominamos condição de
junção (join condition). Quando o técnico esquece de colocar o “join condition” em um SELECT que
envolva duas ou mais tabelas o SGBD geralmente efetua o PRODUTO.

O SELECT a seguir efetua uma junção entre as tabelas CLIENTE e CONTA_CORRENTE:

SELECT nome, saldo

FROM cliente, conta_corrente
WHERE cliente.id-cli = conta_corrente.id-cli;

Considerando as amostragens das tabelas do sistema exemplo referenciadas no comando anterior, a

tabela resultado seria:

NOME SALDO
RITA 150,00
MARCELO 30,00
CARLA 500,00
CARLA 0,00
VITOR 20.000,00
VITOR 50.000,00
RAQUEL 50,00
SÔNIA 10,00
GETÚLIO 20,00

Note que a cliente de nome BRUNA não figura na tabela resultado porque não possui registro na
tabela CONTA_CORRENTE.

33
 PROJETO DE BANCO DE DADOS

PARTE II

NORMALIZAÇÃO

CAPÍTULO I

1.DEFINIÇÃ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.

2. ANOMALIAS DE ATUALIZAÇÃO

São problemas presentes em estruturas de dados modeladas de forma inadequada.

TABELA FUNCIONÁRIO
MATR NOME ENDEREÇO COD-ORGÃO SIGLA-ORG QTD-FUNC
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 tuplas, haja
vista, que o mesmo pode repetir-se numerosas vezes na relação;

34
- A INCLUSÃO de um novo funcionário para o “GEORG’ causa ALTERAÇÃO no atributo “QT-FUNC” em
diversas tuplas;
- A EXCLUSÃO da funcionária “VILMA” da tabela ocasiona perda de informações sobre o “GEPAC”;

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.

a. CÉLULA

Interseção (LINHA X COLUNA) de uma relação.

b. 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).

c. VALOR ATÔMICO (ATRIBUTO SIMPLES)

Caracterizado quando uma célula possui apenas um valor de atributo. Esta é a situação adequada
no modelo Relacional.

d. 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 tupla 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 tupla 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

e. DEPENDÊNCIA FUNCIONAL

É a correspondência (identificação unívoca) existente entre dois atributos de uma mesma relação.
pode ser de três tipos: COMPLETA, PARCIAL e TRANSITIVA

f. DEPENDÊNCIA FUNCIONAL COMPLETA (DFC)

35
 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;

g. 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ária chave primária composta. Por outro lado,
nem sempre que ocorre PK composta haverá dependência parcial.

h. 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.

4. NOTAÇÃO PARA DESCRIÇÃO DAS 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 COD-PROD QTD 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.

36
 - Os atributos componentes da CHAVE devem receber uma das seguintes notações:

. sublinhados, ou;

. 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. 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

37
 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

CONTA-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ômico, pois suas células não contêm valores únicos.

- A relação “CONTA-CORRENTE” está na forma NÃO-NORMALIZADA.

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
DESCRIÇÃO-TIPO-AGENCIA
ENDEREÇO-DEPENDENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO

38
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).

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 tuplas de uma relação.

Na escolha do ATRIBUTO-CHAVE os seguintes aspectos são relevantes:

a. Não pode conter valor nulo para evitar duplicatas;

b. Não pode conter duplicatas para garantir a identificação unívoca;

c. Deve ser um atributo estável (não sujeito à constantes mudanças);

Estável: MATRICULA, CPF, NUM-CONTA-CORRENTE

Não estável: MOEDA-NACIONAL, SALDO, INDICE-ECONÔMICO

d. Não deve dar margem à ambigüidades para garantir a eficiência de acesso (dar preferência a
códigos numéricos e o mais curtos possíveis);

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;

Obs2: Códigos alfanuméricos ou atributos muito extensos são mais propensos a erros de digitação.

e. 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;

f. 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.

g. O processo de escolha de CHAVES PRIMÁRIAS em um BD relacional constitui um fator crítico, 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

39
TIPO-AGENCIA
DESCRIÇÃO-TIPO-AGENCIA
ENDEREÇO-DEPENDENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO

Qual o atributo ou combinação de atributos que identificam singularmente cada tupla 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.

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
DESCRIÇÃO-TIPO-AGENCIA
ENDEREÇO-DEPENDENCIA

LANÇAMENTOS
# AGENCIA
# NUMERO-CONTA
# NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANÇAMENTO

40
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 às DFT identificadas. Ao decompor-mos a tabela “CONTA-CORRENTE”, gerando as
relações em 2FN, restou apenas uma DFT, que encontra-se 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
ENDEREÇO-DEPENDENCIA

TIPO-AGENCIA
# TIPO-AGENCIA
DESCRIÇÃO-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.

41
 EXERCÍCIOS I

I. MARQUE V - verdadeiro ou F - falso.

1. CHAVES:

a. (f) As tabelas de um SGBD-R podem possuir diversas chaves primárias.

b. (v) Nos SGBD-R qualquer coluna de uma tabela pode ser utilizada como chave de acesso.
c. (f) Chave secundária é o campo utilizado como segunda alternativa para o relacionamento entre
tabelas.
d. (f) Uma chave primária composta é formada por várias chaves candidatas.
e. (f) Chave de ordenação é o mecanismo que ordena tabelas nos SGBD-R.
f. (f) As chaves estrangeiras denotam relacionamento e, portanto, obrigatoriamente devem compor a
PRIMARY-KEY.
g. (v) Qualquer tipo de chave pode ser simples ou composta.
h. (v) Toda FOREING KEY é chave primária em alguma outra tabela.
i. (v) Com exceção das chaves candidata e primária, todas as demais colunas da tabela são potencias
chaves secundárias.

2. ÍNDICES:

a. (v) Uma tabela pode possuir vários índices primários.

b. (v) Nos SGBD-R ao definir-se a PK, automaticamente é criado um índice secundário.
c. (f) A indexação ordena a tabela.
d. (f) É ideal que todas as colunas de uma tabela sejam indexadas.
e. (v) Os índices primários e os secundários podem ser simples ou compostos
f. (v) O índice é um mecanismo de acesso direto aos dados
g. (f) É adequada a criação de índices para campos com domínio discreto.
h. (f) Em uma tabela indexada, todos os acessos serão do tipo direto indexado.

3. SQL:

a. (f) O SQL é uma linguagem procedural e “não-proprietárias”.

b. (v) Os SGBD-R possuem linguagens procedurais proprietárias que complementam o SQL.
c. (v) Os SGBD-R somente permitem a criação de estruturas de dados do tipo tabular
d. (f) O SQL/ANSI é um padrão rigorosamente seguido pelos SGBD-R.
e. (f) O comando DELETE é usado para excluir estruturas de dados do BD.
f. (f) O resultado de todos os comandos SQL é uma tabela Virtual denominada VIEW.
g. (v) O SQL é um padrão de fato, para definição de estruturas e manipulação de dados nos SGBD-R.

4. ADMINISTRAÇÃO DE BANCO DE DADOS

a. (v) O DBA é o profissional que cuida do administração do banco de dados da empresa

b. (f) Desde que um usuário possua uma senha no BD-R, ele pode executar qualquer comando SQL.
c. (v) O requisito de privacidade pode ser implementado através da criação de VIEWs.
d. (f) O CHECK-POINT é o mecanismo que permite realizar auditoria no banco de dados.
e. (f) Atribuir a execução de comandos DML apenas ao DBA é uma forma correta de centralizar a
administração do BD.
f. (v) Nos SGBD-R, pode-se limitar os privilégios de um usuário, para que execute apenas o comando
SELECT em uma tabela.
g. (v) Em um sistema de administração descentralizada, o administrador de dados (AD) valida modelos
lógicos e o administrador de banco de dados (DBA) valida modelos físicos.

5. BANCO DE DADOS

a. (v) O IMS foi o SGBD hierárquico mais vendido no mundo todo.

b. (v) Um banco de dados relacional pode conter dados e procedimentos armazenados.
c. (f) Os SGBD Rede receberam essa designação porque rodavam em grandes redes de mainframes.
d. (f) O CLIPPER é um exemplo de SGBD relacional, porque opera com estruturas de dados do tipo
tabular..
e. (v) PASCAL, COBOL e PL/1 são exemplos de linguagens hospedeiras de SGBDs de grande porte
42
 f. (f) O ACCESS é um SGBD orientado a objetos por que opera em ambiente gräfico (Windows) .
g. (f) Atualmente, o modelo de SGBD mais usado na arquitetura Cliente/Servidor é o Rede.
h. (v) Os SGBD hierárquicos apresentam restrições em relação ao sentido de acesso aos dados.
i. (v) O CODASYL é um organismo de padronização americano, intimamente relacionado aos SGBD
baseados modelo rede.
j. (f) A riqueza de ponteiros e a dependência de caminhos de acesso são características dos modelos
relacionais de BD.

II. RELACIONE OS OBJETIVOS DOS BD COM A MELHOR DAS ALTERNATIVAS A SEGUIR.

1. INDEPENDÊNCIA DE DADOS 5. PRIVACIDADE

2. INTEGRIDADE 6. SEGURANÇA
3. COMPARTILHAMENTO DE DADOS 7. TRATAMENTO DE CONCORRÊNCIA
4. REDUNDÂNCIA 8. NDA

(1) Minimiza o impacto das alterações nas estruturas de dados do BD, sobre as aplicações.
(3) Controla o acesso simultâneo aos dados
(2) Possibilita que os parâmetros de validação dos dados sejam definidos no BD
(4) Em BD deve ocorrer no menor grau possível
(6) Rotina de auditoria

III. CONSIDERE AS TABELAS ABAIXO PARA RESPONDER AS QUESTÕES SEGUINTES.

CLIENTE CONTRATO
CÓD-CLI NOME ENDEREÇO SEXO NUM-CONTRATO COD-CLI VALOR

Obs: Um cliente pode ter muitos contratos, mas não existe dois contratos com o mesmo número.

1. RELACIONAR AS COLUNAS:

1. CHAVE DE ORDENAÇÃO (1) NOME em uma VIEW em ordem alfabética

2. CHAVE SECUNDÁRIA (3) NUM-CONTRATO na tabela CONTRATO
3. CHAVE PRIMÁRIA (2) NOME na tabela cliente
4. ESTRANGEIRA (4) CÓD-CLI na tabela CONTRATO
5. NDA (3) COD-CLI na tabela cliente

2. Marque “V” para itens verdadeiros e “F” para os falsos, considerando os seguintes parâmetros.
Integridade referencial (ligada) , Atualização em cascata (ligada), Exclusão em cascata (desligada). -
(2ptos)

a. (v) Alterando-se o código de um cliente na tabela cliente, seus correspondentes em contrato não
serão alterados.
b. (f) Excluindo-se um cliente, todos os contratos a ele relacionados serão automaticamente excluídos.
c. (f) Não será possível incluir clientes que não possuam contratos.
d. (v) Não será possível excluir contratos que possuam clientes a ele relacionados.
e. (f) Ao incluir-se um cliente, automaticamente será criado um contrato.

3. Para obtermos o NOME, NUM-CONTRATO e VALOR de todos os contratos de um cliente utilizamos:

a. ( ) UNIÃO, INTERSEÇÃO e PROJEÇÃO

b. (x ) PROJEÇÃO, SELEÇÃO e JUNÇÃO
c. ( ) PRODUTO, SELEÇÃO e JUNÇÃO
d. ( ) UNIÃO, DIFERENÇA e JUNÇÃO
e. ( ) NDA

43
 EXERCÍCIOS II

I. RELACIONE AS SENTENÇAS COM A MELHOR DAS ALTERNATIVAS ABAIXO:

1. Cardinalidade 2. Relacionamento
3. Entidade 4. Auto-relacionamento
5. Atributo 6. Nda

a. ( ) Objeto do mundo real sobre o qual se deseja armazenar informações.

b. ( ) Relaciona ocorrências de uma mesma entidade.
c. ( ) Propriedade que qualifica uma entidade.
d. ( ) Quando “1:N”, implica que a chave estrangeira reside na mesma tabela da chave primária.
e. ( ) Representa no MER pelo menos uma tabela do banco de dados.
f. ( ) Sinal que apresenta grande variação entre os diversos autores de literatura sobre MER.
g. ( ) Deve gerar uma tabela do BD com no mínimo duas linhas e duas colunas
h. ( ) Representa a relação entre dois conjuntos de informação no MER;
i. ( ) Indica a quantidade genérica de ocorrências envolvidas no relacionamento
j. ( ) Seu tipo pode ser numérico, caracter ou data;

II. MARQUE 'V' PARA AS SENTENÇAS VERDADEIRAS E 'F' PARA FALSAS.

a. ( ) Dependência transitiva é o nome da relação de identificação, entre componentes da chave
primária.
b. ( ) Cada entidade do MER lógico gera no máximo uma tabela normalizada no BD.
c. ( ) Em tabelas 3FN, todos os atributos “não chave” estão em dependência funcional completa com
a chave.
d. ( ) Entidades Associativas herdam as chaves primárias das entidades associadas.
e. ( ) O chave estrangeira obrigatoriamente deve compor a chave primária
f. ( ) A normalização é uma seqüência de projeções, efetuadas a partir de uma estrutura de dados
não atomizada.
g. ( ) Os SGBD-R não permitem a criação de tabelas que contenham itens de grupo.
h. ( ) Uma tabela normalizada só pode conter valores atômicos.
i. ( ) Quando a chave primária é simples, pode-se afirmar que a tabela não contém dependência
funcional.
j. ( ) Quando a chave primária é simples e os valores atômicos, pode-se afirmar que a tabela está
em 2FN.

IV. RESCREVA A ESTRUTURA DE DADOS EM 3FN E ELABORE O MER CORRESPONDENTE .

CONTROLE DE BENEFÍCIOS
MATRÍCULA_DO_FUNCIONÁRIO
NOME_DO_FUNCIONÁRIO
ENDEREÇO_DO_FUNCIONÁRIO
BENEFÍCIOS*
DATA_DE_CONCESSÃO_DO_BENEFÍCIO
CODIGO_DO_BENEFÍCIO
NOME_DO_BENEFÍCIO (TICKETS, VALE TRANSPORTE, ASSIST. MÉDICA, BOLSA, ETC...)
VALOR_DO_BENEFÍCIO

OBS: Um funcionário pode receber vários benefícios, mas este deve ser cadastrado uma única vez.
O valor de um benefício será igual para todos os beneficiários.

44
 EXERCÍCIOS III

I. RELACIONE AS SENTENÇAS COM A MELHOR DAS ALTERNATIVAS ABAIXO:

1. ENTIDADE
2. CARDINALIDADE
3. RELACIONAMENTO
4. ATRIBUTO
5. AUTO-RELACIONAMENTO
6. NDA

( ) Objeto do mundo real sobre o qual se deseja armazenar informações.

( ) Seu tipo pode ser numérico, caracter ou data;

( ) Possui correspondência com os depósitos de dados do DFD.

( ) Indica a quantidade genérica de ocorrências envolvidas no relacionamento

( ) Relaciona ocorrências de uma mesma entidade.

( ) Gera pelo menos uma tabela no banco de dados.

( ) Identificador único que pode ser simples ou composto.

( ) A bibliografia registra grande variação na sua notação (números, barras, setas, "pés de galinha", etc.)

( ) Representa no MER as entidades externas do DFD.

( ) Representa a relação entre dois conjuntos de informação no MER;

II. MARQUE 'V' PARA AS SENTENÇAS VERDADEIRAS E 'F' PARA FALSAS.

( ) Uma entidade do MER pode gerar "N" tabelas no BD.

( ) Em tabelas 3FN, todos os atributos "não chave" estão em dependência funcional completa com a
chave.

( ) Entidades Associativas herdam as chaves primárias das entidades associadas.

( ) A normalização é uma seqüência de projeções, efetuadas a partir de uma estrutura de dados não
atomizada.

( ) A chave estrangeira obrigatoriamente deve compor a chave primária.

( ) Os SGBD-R não permitem a criação de tabelas que contenham itens de grupo.

( ) Uma tabela normalizada só pode conter valor atômico.

( ) Quando a chave primária é simples, pode-se afirmar que a tabela não contém dependência
funcional.

( ) Toda chave estrangeira é chave primária em outra tabela do banco de dados.

( ) Dependência transitiva é o nome da relação de identificação, entre componentes da chave primária.

45
III. RESCREVA A ESTRUTURA DE DADOS EM 3FN E ELABORE O MER CORRESPONDENTE .

CONTROLE DE MANUTENÇÃO DE MICROCOMPUTADORES

NUM_OS

DATA_OS

TÉCNICO_ATENDEU

MATRICULA

NOME

DESCRIÇÃO_DEFEITO

NR_SÉRIE_MICRO

PEÇAS(*)

CÓDIGO

DESCRIÇÃO

OBS: "OS" significa ORDEM DE SERVIÇO. Não existem duas OS com o mesmo número. O usuário
deseja montar um catalogo de peças e gerar estatísticas sobre consumo de peças e número de
atendimentos.

46
 BIBLIOGRAFIA

1. CHU, SHAO YONG

BANCO DE DADOS - ATLAS

2. KORTH, HENRY F.
SISTEMAS DE BANCO DE DADOS - MAC GRAW

3. DATE , C. J.
BANCO DE DADOS - TÓPICOS AVANÇADOS - CAMPUS

4. SETZER, VALDEMAR W.
BANCO DE DADOS

5. ACÁCIO FELICIANO NETO

ENGENHARIA DA INFORMAÇÃO - MAC GRAW

6. GANE, CHRIS
ANÁLISE ESTRUTURADA DE SISTEMAS - LTC

7. GANE, CHRIS
DESENVOLVIMENTO RÁPIDO DE SISTEMAS - LTC

8. YORDON, EDWARD
ANÁLISE ESTRUTURADA MODERNA - CAMPUS

9. CHEN, PETER
MODELO ENTIDADE x RELACIONAMENTOS

VALOR DE
ATRIBUTO

47