PARTE I - INTRODUO A BANCO DE DADOS

CAPTULO I - CONCEITOS BSICOS

Introduo ...........................................................................01
1. Arquivo ............................................................................02
2. Registro ...........................................................................02
3. Campo ............................................................................ 03
4. Chave Primria ................................................................04
5. Chave Secundria............................................................05
6. Chave Candidata..............................................................06

CAPTULO II - ORGANIZAO DE ARQUIVOS

1. Mtodo De Acesso ...........................................................07
2. Organizao Seqencial ..................................................09
3. Organizao Serial...........................................................10
4. Organizao Indexada .....................................................11

CAPTULO III - SGBD

1. Sistema Geranciador de Banco de Dados - SGBD.........13
2. Banco de Dados..............................................................13
3. Sistema em Banco de Dados.......................................... 14

CAPTULO IV - OBJETIVOS DE BANCO DE DADOS

1. Independncia de dados.................................................15
2. Compartilhamento de dados...........................................16
3. Menor redundncia.........................................................16
4. Privacidade de dados ....................................................16
5. Segurana de dados .....................................................17
6. Tratamento de concorrncia .........................................17
7. Integridade de dados ....................................................18

CAPTULO V - LINGUAGENS DE BD
1. SQL...............................................................................19
2. Autocontidas..................................................................22
3. Hospedeiras...................................................................22
4. Visuais...........................................................................23
5. Linguagens para INTERNET..........................................23
Concluso..........................................................................24

CAPTULO VI - BANCO DE DADOS RELACIONAL

1. Terminologia do Modelo Relacional..... .........................25
2. Regras de integridade...................................................26
a. Integridade Declarativa..................................................27
b. Integridade Procedural..................................................29
c. Integridade Referencial.................................................30
3. Operadores Relacionais...............................................32
4. Propriedades Relacionais.............................................33
5. Vantagens do Modelo Relacional.................................34

CAPTULO VII - LGEBRA RELACIONAL

1. Estudo de caso ...........................................................36
2. Generalidades ...........................................................38
3. Operadores de Conjunto ..........................................39
a. Unio...........................................................................40
b. Interseo....................................................................41
c. Diferena.....................................................................42
d. Produto carteziano......................................................43
4. Operadores Relacionais ............................................44
e. Projeo......................................................................44
f. Seleo........................................................................45
g. Juno........................................................................46

PARTE II - PROJETO DE BANCO DE DADOS

Introduo ......................................................................48
CAPTULO VIII - NVEIS DE ABSTRAO
1. Mundo Real ...............................................................50
2. Modelo Descritivo ......................................................50
3. Modelo Conceitual .....................................................51
4. Modelo Operacional ...................................................51
5. Modelo Interno ...........................................................52

CAPTULO IX - MODELO DE ENTIDADES E RELACIONAMENTOS (MER)

Generalidades ................................................................53
1. MER - Notao e terminologia.....................................54
2. Regras para atribuio de nomes entidades.............55
3. Atributo .......................................................................56
4. Dicionrio de Dados.....................................................57
5. Relacionamento...........................................................59
6. Cardinalidade.............................. ................................60
7. Nome do relacionamento.. ......... ................................62
8. Papel ...........................................................................63
9. Sentenas ...................................................................64
10. Integridade Referencial .............................................65
11. Regras gerais para o MER ........................................66
12. Vantagens e desvantagens do MER .........................67
CAPTULO X - TIPOS ESPECIAIS DE RELACIONAMENTO
1. Auto-relacionamento ...................................................68
2. Mais de um relacionamento ........................................69
3. Relacionamento Mltiplo .............................................70
CAPTULO XI - EXTENSES AO MER
1. Generalizao .............................................................72
2. Especializao ............................................................73
3. Agregao ..................................................................74
4. Variao do conceito de Agregao ............................75
CAPTULO XII - NORMALIZAO
1. Anomalias de Atualizao ...........................................76
2. Terminologia ...............................................................77
Dependncia Funcional Completa (DFC) ...................78
Dependncia Funcional Parcial (DFP) .......................79
Dependncia Funcional Transitiva (DFT) ...................80
3. Notao para as estruturas de dados .........................81
4. Esquema de normalizao ..........................................83
5. Relaes no Normalizadas ........................................84
6. Primeira forma normal (1FN) ........................................85
7. Escolha da chave primria ...........................................86
8. Segunda forma normal (2FN) ......................................88
9. Terceira forma normal (3FN) ........................................89
Bibliografia........................................................................91

INTRODUO

No incio da dcada de 60, foram lanados os primeiros sistemas

gerenciadores de banco de dados (SGBD), tendo como principal proposta o
aumento na produtividade nas atividades de desenvolvimento e manuteno
de sistemas, at ento realizadas de forma artezanal em linguagens de
programao convencionais de primeira e segunda gerao.
Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares
e amigveis com o advento da microinformtica. Cada vez mais as fronteiras
entre esses dois mundos estreitam-se e a concorrncia pelo domnio do
mercado de SGBD, tem levado seus diversos fabricantes a sofisticarem seus
produtos. Cada nova verso lanada, incorpora novidades como interfaces
grficas, ferramentas de apoio ao desenvolvimento, utilitrios para
gerenciamento de BD e facilidades para extrao de dados. Essa evoluo
vem tornando o trabalho de programadores, analistas e usurios menos
artezanal, com reflexos na qualidade e produtividade.
A literatura classifica os SGBD como HIERRQUICO, REDE
e
RELACIONAL. Essa classificao representa a evoluo desses produtos no
curso da histria. Atualmente, o mercado dominado pelos SGBD
RELACIONAIS e caminha para a colocao em escala comercial dos SGBD
ORIENTADOS A OBJETOS.
Este texto introduz a teoria de BANCO DE DADOS, a partir de conceitos
bsicos da teoria de arquivos que perpetuaram-se na terminologia de banco
de dados. Na sequencia aborda superficialmente os modelos
HIERRQUICO e REDE (por razes de mercado) e de forma mais
aprofundada o MODELO RELACIONAL, o qual designaremos neste texto
pela sigla SGBD-R.

CAPTULO I
CONCEITOS BSICOS
Para compreender com maior facilidade os conceitos relativos a BANCO DE
DADOS de suma importncia revisar-mos alguns conceitos bsicos
referentes teoria e terminologia de arquivos convencionais, haja vista, que
os primeiros SGBD foram criados a partir do aperfeioamento de sistemas
gerenciadores de arquivo, e ainda utilizam muito da base conceitual e da
terminologia de arquivos.

1. ARQUIVO
Um arquivo uma coleo de REGISTROS do mesmo tipo, ou seja,
referentes a um mesmo assunto e com o mesmo formato padro (layout).
Constitui o componente do sistema no qual so armazenados os dados,
que combinados atravs dos programas servem de base para a gerao
da informao desejada pelo usurio, atravs de relatrios e consultas
on-line.
Um sistema de controle de notas, por exemplo, pode armazenar seus
dados em diversos arquivos, cada um contendo informaes sobre um
determinado item do sistema: ALUNO, PROFESSOR, MATRIA, NOTA,
etc.
Essas informaes podem ser combinadas atravs de programas para
gerar, por exemplo, o BOLETIM ESCOLAR, a PAUTA ou uma tela de
CONSULTA DE NOTAS.

2. REGISTRO
Um registro constitudo por conjunto de campos valorados (contendo
dados. Consiste na unidade de armazenamento e recuperao da
informao em um arquivo. Geralmente, os registros de um arquivo
possuem um formato padro (layout), definido pela seqncia, tipo e
tamanho dos campos que o compem. Porm, algumas linguagens de
programao permitem a criao de registros com layouts deferentes em
um mesmo arquivo, recurso este que raramente utilizado.

3. CAMPO
a unidade bsica formadora de um registro. Constitui a clula da
informao. a menor poro de um arquivo que pode ser referenciada
por um programa.
Cada campo possui NOME, TIPO e TAMANHO. Os tipos de campo mais
comuns so:
_ Armazena somente nmeros
_ Pode conter casas decimais

NUMBER

_ Pode ser utilizado em operaes matemticas

_ Pode armazenar letras, nmeros e caracteres

CHAR ou
ALFANUMRICO
DATE

especiais
_ Armazena datas fazendo consistncia automtica

MEMO ou LONG _ Armazena textos em formato livre

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

ARQUIVO ALUNO
LAYOUT
CAMPOS
TIPO e TAM.
REGISTROS

MATRICULA NOME
ENDEREO DT_NASC
NUMBER (03) CHAR (30) CHAR (50)
DATE
001
002
003
.
.

Jos
Maria
Ana
.
.

SQS 308 ... 23/08/78

QND 14 .... 25/09/70
SQN 410 ... 10/08/85
.
.
.
.

4. CHAVE PRIMRIA (PRIMARY KEY - PK)

3

A CHAVE PRIMRIA (ou simplesmente CHAVE) o identificador nico

de um registo em um arquivo. Pode ser constituda de um campo
(CHAVE SIMPLES) ou pela combinao de dois ou mais campos
(CHAVE COMPOSTA), de tal maneira, que no existam dois registros no
arquivo com o mesmo valor de chave primria.
Em regra, todo arquivo deve possuir uma chave primria, que permita a
identificao inequvoca do registro, especialmente, para dar maior
consistncia aos processos de incluso, alterao e excluso de dados.
Para que no ocorram duplicatas nos valores da chave, os campos que a
compem so de PREENCHIMENTO OBRIGATRIO (NOT NULL).
Na escolha da chave primria de um arquivo deve-se buscar campos que
possuam ESTABILIDADE no valor armazenado. A escolha do NMERO
DO TELEFONE como chave de um cadastro de clientes, por exemplo,
seria inadequada, por que esse valor pode mudar com freqncia. Sem
considerar que o cliente pode ter mais de um telefone...
Deve-se tambm evitar a escolha de campos que possam causar
AMBIGIDADE em relao 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 vrias
formas. Por exemplo: LUS, LUIZ, LOUIS, LOYS, LUYS.
Se desejssemos cobrar uma fatura de um cliente com um nome como
esse, a probabilidade de erramos o cliente seria grande. Alm disso, a
extenso do campo (30 ou mais caracteres) um outro aspecto que
aumenta a possibilidade de erros.
DICAS PARA ESCOLHA DA CHAVE PRIMRIA:
_ Todo arquivo deve possuir uma chave primria.
_ VALOR NICO para cada registro.
_ SIMPLES ou COMPOSTA.
_ Campos de PREENCHIMENTO OBRIGATRIO.
_ Valor ESTVEL.
_ No AMBGUO.
_ PEQUENA EXTENSO (menor possvel).
_ De preferncia CAMPOS NUMRICOS

5. CHAVE SECUNDRIA

A chave secundria pode ser formada por um campo ou pela combinao

de campos (SIMPLES / COMPOSTA). utilizada como parmetro (filtro)
para seleo de registros no arquivo em consultas, emisso de relatrios
ou processos de atualizao simultnea de um grupo de registros.
Por exemplo, para aumentarmos o valor do salrio dos analistas em 10%,
poderamos utilizar o campo FUNO do arquivo CADASTRO DE
FUNCIONRIOS como parmetro (chave secundria) no processo de
seleo dos registros a serem alterados.
Em sntese, a chave secundria o campo ou combinao de campos do
arquivo que permite a recuperao de mais de um registro no arquivo.
Portanto, no possui a caracterstica de unicidade proposta para a chave
primria.
A figura a seguir ilustra os conceitos de CHAVE PRIMRIA e SECUNDRIA

ARQUIVO ALUNO

PK
MATRICULA
001
003
002
005
.

NOME
Jos
Maria
Ana
Jos
.

ENDEREO
SQS 308 ...
QND 14 ....
SQN 410 ...
GAMA
.

DT_NASC
23/08/78
25/09/70
10/08/85
05/04/76
.

Acesso via CHAVE SECUNDRIA (NOME) no arquivo ALUNO:

PROGRAMA X
INCIO....
.
.
SE NOME = JOS
ENTO IMPRIMIR
.....
.
.
FIM

6. CHAVE CANDIDATA
Pode ocorrer uma situao em que mais de um campo satisfaa a
condio de chave primria, constituindo duas ou mais CHAVES
CANDIDATAS. Neste caso, o analista dever eleger somente uma delas
como CHAVE PRIMRIA, as demais permanecero na condio de
CANDIDATAS, indicando que tratam-se de campos de preenchimento
obrigatrio e com valores nicos para cada registro, o que ser garantido
atravs de mecanismos de integridade de coluna, que veremos no
captulo relativo a banco de dados.
A figura a seguir mostra um exemplo de arquivo com CHAVE CANDIDATA

ARQUIVO ALUNO

CHAVE CANDIDATA
CHAVE PRIMRIA
MATRICULA
001
003
002
005
.
.

NOME
Jos
Maria
Ana
Jos
.
.

ENDEREO
SQS 308 ...
QND 14 ....
SQN 410 ...
GAMA
.
.

CPF
72993246500
12354789065
09876587659
28746503645
.
.

CAPTULO II
ORGANIZAO DE ARQUIVOS
O tema organizao de arquivos refere-se a forma como os registros so
armazenados em um arquivo baseado em computador. Confunde-se com
MTODO DE ACESSO, que consiste na forma como esses podem ser
recuperados. A organizao do arquivo determina os mtodos de acesso
que podem ser utilizados na recuperao dos registros, mas tratam-se de
coisas distintas.
Apesar de este ser um assunto muito abrangente e com muitas variantes
em termos de abordagem, trataremos de apenas trs tipos de
organizao (SEQENCIAL, SERIAL E INDEXADA) e seus respectivos
mtodos 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. MTODOS DE ACESSO
Para recuperarmos um registro em um arquivo, podemos utilizar acesso
SEQENCIAL ou DIRETO.
O mtodo SEQENCIAL de acesso o mais tradicional e consiste em
efetuar a leitura dos registros, um aps o outro, comparando o
ARGUMENTO DE PESQUISA, com o valor do campo CHAVE (primria
ou secundria) no registro corrente, at encontrar os registros desejados
ou o final do arquivo.
exemplo:
PROGRAMA Y
INCIO....
.
Repita at fim
ler registro

chave secundria (campo chave)

SE NOME = JOS
ENTO IMPRIMIR
Fim repita (volte a ler)
.
FIM DO PROGRAMA

argumento de pesquisa

O mtodo 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 atravs de um NDICE (que
abordaremos no item organizao indexada) ou com o auxlio de um
algoritmo de RANDOMIZAO que localiza o registro, calculando a
posio ocupada pelo registro no disco, com base no valor do argumento
de pesquisa, que deve ser um campo numrico.
Em ambos os casos, a localizao do registro ocorre a cargo do
gerenciador de arquivos, de maneira transparente para o programador,
que s precisa escolher a organizao adequada para o arquivo e
fornecer no programa o argumento de pesquisa.
exemplo:
PROGRAMA Z
INCIO....
.
.
ABRIR ARQUIVO ALUNO INDEXADO POR NOME
.
NOME=JOS
argumento de pesquisa
LOCALIZAR REGISTRO
acesso direto (indexado)
SE ENCONTROU REGISTRO
ENTO IMPRIMIR
.
.
FIM DO PROGRAMA

2. ORGANIZAO SEQENCIAL
A ORGANIZAO SEQENCIAL caracteriza-se pela existncia de uma
CHAVE DE ORDENAO. Essa chave determina a ordem em que os
registros so armazenados e pode ser SIMPLES ou COMPOSTA por
dois ou mais campos. Geralmente, coincide com a chave primria, mas
no obrigatoriamente.
A organizao seqencial somente permite o ACESSO SEQENCIAL.
A figura a seguir apresenta um arquivo com ORGANIZAO SEQENCIAL e CHAVE
PRIMRIA(MATRICULA) distinta da CHAVE DE ORDENAO (NOME - ordem alfabtica).

ARQUIVO ALUNO

chave primria
MATRICULA
001
003
002
005
.
.

NOME
Ana
Jos
Jos
Maria
.
.

chave de ordenao
ENDEREO
SQS 308 ...
QND 14 ....
SQN 410 ...
GAMA
.
.

DT_NASC
23/08/78
25/09/70
10/08/85
05/04/76
.
.

3. ORGANIZAO SERIAL
Nesta forma de organizao os registros so armazenados de acordo
com a ordem de incluso. o arquivo no possui chave de ordenao,
portanto no existe preocupao com a ordem de armazenamento dos
registros. No entanto, sempre recomendvel o arquivo possua uma
chave primria.
A organizao serial somente permite o ACESSO SEQENCIAL. No
deve ser utilizada em processos de excluso e alterao de registros na
modalidade bacth (atualizao em lote), pois degrada a performance.
muito utilizada em processos de incluso de registros onde no haja
preocupao em manter a seqncia dos mesmos (pools de digitao).
tambm empregada no arquivo de dados que serve de base para a
organizao indexada, que estudaremos no prximo item.
A figura a seguir apresenta um arquivo com ORGANIZAO SERIAL. Note que ele
no possui CHAVE DE ORDENAO.

ARQUIVO ALUNO

chave primria
MATRICULA
005
003
002
001
.

NOME
Maria
Jos
Ana
Jos
.

ENDEREO
SQS 308 ...
QND 14 ....
SQN 410 ...
GAMA
.

DT_NASC
23/08/78
25/09/70
10/08/85
05/04/76
.

10

4. ORGANIZAO INDEXADA
Nesta forma de organizao, os registros so armazenados em um
arquivo de dados com organizao serial e para cada campo (ou
combinao deles) atravs do qual se deseja obter acesso direto
(indexado) deve-se criar um arquivo de ndice (processo de indexao).
Um mesmo arquivo de dados pode possuir diversos arquivos de ndice a
ele associados. Porm, apesar da flexibilidade para a criao de ndices,
esse recurso deve ser utilizado com critrio, pois a manuteno de
muitos ndices pode degradar a performance no processo de atualizao
do arquivo. Ou seja, ganha-se na consulta on-line, mas pode-se perder
na atualizao de dados.
O arquivo de ndice composto basicamente por duas colunas. A
primeira corresponde ao campo utilizado no processo de indexao
(endereo lgico) e a segunda armazena um valor (endereo fsico) que
serve como referncia, para que o gerenciador de arquivos localize o
registro no disco magntico.
Os registros dos arquivos ndice so ordenados pelo endereo lgico.
Portanto, se utilizarmos um algoritmo de leitura seqencial em um arquivo
indexado por nome, por exemplo, obteremos os registros em ordem
alfabtica, mesmo sendo o arquivo de dados um arquivo serial. Ou seja
prevalece a ordem do ndice. Porm nesse exemplo, a performance a
performance do arquivo indexado seria menor, se comparada a de um
arquivo seqencial por nome.
Sempre que um arquivo ndice for referenciado por um programa, ele
ser carregado para memria principal, o que torna desprezvel o tempo
de busca dos registros nesse arquivo. Alm disso, o algoritmo utilizado
na busca o de pesquisa binria, o que reduz ainda mais o tempo.
Os ndices constitudos com base no valor da chave primria ou
candidata so conhecidos como NDICES PRIMRIOS e os demais
como NDICES SECUNDRIOS.

11

Em resumo, a organizao indexada formada pela combinao de pelo

menos um arquivo de dados e um ou mais arquivos de ndice.
A figura a seguir apresenta o cenrio da ORGANIZAO INDEXADA.

ARQUIVO ALUNO
NDICE
PRIMRIO

TRILHA, SETOR E LADO DO DISCO

MATR
001
002
003
005
.

TSL
220
321
231
110

NDICE
SECUNDRIO
NOME TSL
Ana
321
Jos
220
Jos
231
Maria 110
.
331

(endereo fsico)

chave primria (endereo lgico)

TSL MATR NOME

110 005 Maria
231 003 Jos
321 002 Ana
220 001 Jos
331
.
.

ENDEREO
SQS 308 ...
QND 14 ....
SQN 410 ...
GAMA
.

DT_NASC
23/08/78
25/09/70
10/08/85
05/04/76
.

12

CAPTULO III
SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD
A expresso BANCO DE DADOS, coloquialmente empregada com os mais
diversos significados, de tal sorte que, ao indagarmos de algum 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 FINANAS;
3. Trabalho com o CADASTRO DE PESSOAL, SISTEMA DE VENDAS, etc.
Para evitar conflitos terminolgicos, definimos a seguir trs expresses, consagradas
na a literatura clssica, que seriam melhor aplicadas a cada uma das situaes
anteriores.
1. SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD
Essa expresso 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 informaes relacionadas,
que so armazenadas no computador e recuperadas com a utilizao
dos recursos de um SGBD. Essas informaes devem ser estruturadas,
de tal maneira, que independam de aplicaes especficas. 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.

13

3. SISTEMA EM BANCO DE DADOS - SBD

Essa expresso refere-se s APLICAES desenvolvidas para atender
a necessidades especficas da empresa, que acessam um ou mais BD,
para leitura ou atualizao de informaes. Tome como exemplo de
aplicaes especficas 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, EMPRSTIMO DE LIVROS e CONTROLE
DE NOTAS. O BD foi montado utilizando os recursos do SGBD SQL SERVER.
TESOURARIA
SECRETARIA
CADASTRO
DE ALUNOS

BD DE ALUNOS

CONTROLE DE
MENSALIDADE

SGBD SQL SERVER

CONTROLE
DE NOTAS

PEDAGOGA

EMPRSTIMOS
DE LIVROS

BIBLIOTECA

14

CAPTULO IV
OBJETIVOS DE BANCO DE DADOS
O desenvolvimento da tecnologia de banco de dados tem se pautado por buscar
alcanar, como objetivo permanente o aumento de produtividade nas atividades de
desenvolvimento e manuteno de sistemas. Nesse sentido os fabricantes de SGBD
vem dotando seus produtos com mecanismos que facilitam a adaptao dos BD s
novas necessidades que surgem no dia a dia e que reduzem o trabalho de
programao. Aliado a esses dois fatores existe toda uma filosofia que orienta os
tcnicos 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. INDEPENDNCIA DE DADOS
Os SGBD devem ser dotados de recursos que possibilitem a descrio
das estruturas de dados (layout de arquivos e/ou tabelas) de forma
independente dos procedimentos de manipulao (leitura e gravao) de
dados no BD. Esse objetivo visa tornar transparente para os programas
que acessam o BD as alteraes que, por ventura, venham a ocorrer nas
estruturas de dados, como por exemplo o acrscimo de um novo campo
de informao ao banco. Da mesma forma, alteraes em lgicas de
programas que acessam o BD no devem afetar as estruturas de dados.
Quanto maior o grau de independncia de dados, menor ser o tempo
em que o BD ficar fora de operao para atividades de manuteno
como, por exemplo, recompilao.
At hoje, a maneira mais eficiente adotada pelos fornecedores de SGBD
para implementao desse objetivo foi a utilizao do SQL (structured
query language) nos produtos que seguem o Modelo Relacional. O SQL
possui grupos de comandos especficos e independentes para as tarefas
de criao e alterao de tabelas (DDL - data definition language) e
leitura e atualizao do BD (DML - data manipulation language).

15

2. COMPARTILHAMENTO DE DADOS
Consiste na reutilizao dos dados do BD pelo maior nmero possvel de
aplicaes dentro da empresa. Nesse sentido, os dados do BD devem
ser muito bem planejados e estruturados. Portanto, este objetivo de
banco de dados esta mais ligado a atividade de anlise e projeto de BD.
O compartilhamento de dados visa diminuir a redundncia de dados,
considerando-o como um recurso da empresa e no propriedade de
setores isolados da organizao.
Para implementar o compartilhamento de dados necessrio que a
empresa disponha de recursos de rede, que permitam colocar o BD ao
alcance dos diversos usurios. Alm disso, necessrio que o SGBD
possua um competente sistema de segurana, para que se estabelea a
privacidade de dados, atravs de mecanismos de restrio de acesso.
3. MENOR REDUNDNCIA DE DADOS
Redundncia de dados consiste na repetio de um mesmo dado em
diversos arquivos (tabelas) de um sistema, banco de dados, ambiente
computacional ou empresa. Como exemplo, pode-se tomar a ocorrncia
do dado NOME DO FUNCIONRIO, em bases de dados no
compartilhadas dos sistemas de CADASTRO, FOLHA DE PAGAMENTO
e TREINAMENTO de uma empresa.
A redundncia danosa para o ambiente computacional, pois aumenta
os custos com o armazenamento de dados, com o pessoal para
manuteno de sistema.
Alm disso, a redundncia gera inconsistncia de dados, ou seja, o dado
redundante extrado a partir de arquivos diferentes apresenta valores
divergentes. Tal fato, pode afetar a credibilidade do usurio no sistema e
no pessoal de informtica.
4. PRIVACIDADE DE DADOS
O COMPARTILHAMENTO DE DADOS leva um grande nmero de
usurios, com funes diversificadas na empresa, a acessar um mesmo
banco de dados. Nesse contexto, o objetivo de privacidade de dados
ressalta a preocupao que o projetista de BD deve ter em vedar o
acesso de usurios no autorizados a informaes sigilosas ou de
acesso restrito.
16

Nesse sentido, o sistema de segurana dos SGBD, devem possuir

meios para que o projetista possa definir perfis diferenciados de acesso
ao BD, com a criao de grupos de usurios e atribuio de direitos de
acesso a esses grupos, a partir da utilizao de senhas.
5. SEGURANA DE DADOS
A segurana das informaes armazenadas no BD pode ser encarada
sob dois prismas: SEGURANA LGICA e SEGURANA FSICA.
A SEGURANA LGICA alcanada com a utilizao dos mecanismos
de restrio de acesso disponveis nos SGBD para implementao do
objetivo de privacidade de dados, tais como senhas e sistemas de LOG
e AUDIT que registram dados sobre as operaes que so efetuadas no
BD (data, hora, usurio, comando, etc.).
A SEGURANA FSICA dos dados obtida a partir de utilitrios e
aplicativos que os fabricantes colocam em seus produtos, visando facilitar
o trabalho de proteo aos dados contra danos fsicos, que podem ser
causados por falhas de hardware ou queda da rede. Nessa linha
destacam-se as ROTINAS DE BACKUP, GRAVAO COM
ESPELHAMENTO e SISTEMAS DE MONITORAO DE TRANSAES
DISTRIBUDAS (TWO-PHASE-COMMIT).
6. TRATAMENTO DE CONCORRNCIA
Este objetivo de BD aborda o aspecto do acesso simultneo de dois
usurios a um mesmo conjunto de informaes. O SGBD deve possuir
mecanismos para a identificao e tratamento desses acessos
concorrentes, para garantir a consistncia das informaes do BD no
sentido de sua veracidade.
Os sistemas de bloqueio (LOCK) e desbloqueio (UNLOCK) so os
mecanismos utilizados para evitar que uma informao que est sendo
manipulada por um usurio (USU1) seja alterada por outro (usu2).
Enquanto o USU1 dela se utiliza o USU2, no ter acesso a mesma ou
o ter apenas para leitura e receber um aviso do SGBD de que a
informao est sendo acessada por outro usurio e pode ser
modificada.
Existem vrios nveis de LOCK. As opes variam conforme o produto
(SGBD) analisado, sendo que os mais comuns ocorrem a nvel de tabela,
pgina (conjunto de registros) e linha (nvel mais baixo).
17

Cabe lembrar que o nvel de bloqueio influi na performance do SGBD em

ambientes de misso crtica (altos ndices de acesso concorrente), sendo
que quanto menor o nvel de LOCK, a performance tende a ser melhor.
Ressalta-se que alm desse, existem outros fatores que influenciam na
performance do SGBD.

7. INTEGRIDADE DE DADOS
A integridade de dados refere-se a mecanismos que esto disponveis
nos SGBD, que garantem a consistncia dos dados armazenados no
SGBD, segundo parmetros de validao, especificados no momento de
criao do BD, em conjunto com as estruturas de dados.
Esse objetivo s se tornou disponvel, como recurso do SGBD, com o
advento dos modelos Relacionais e consta como pr-requisito para
enquadramento de produtos nessa categoria de SGBD.
No captulo dedicado aos SGBD relacionais trataremos esse assunto
com maior riqueza de detalhes.

18

CAPTULO V
LINGUAGENS DE BANCO DE DADOS
As linguagens de banco de dados consistem na interface do usurio para interagir
com o SGBD. Neste texto destacamos cinco modalidades de linguagens que so mais
comunmente utilizadas nessa interao: SQL, autocontida, hospedeira, visuais e
aquelas voltadas para INTERNET. Esta uma classificao meramente didtica que
objetiva apenas demostrar formas diferenciadas de interao com o BD. Outros
autores possuem diferentes classificaes.
1. SQL (STRUCTURED QUERY LANGUAGE)
A liguagem SQL (anteriormente escrita SEQUEL) foi criada junto com o Sistema
R, primeiro prottipo de SGBD-R, desenvolvido de 1974 a 1979 no IBM San Jose
Research Laboratory. A veso original do SQL foi baseada em uma linguagem
anterior chamada SQUARE. As duas linguagens so essencialmente a mesma, mas
a SQUARE usa uma sintaxe bem mais matemtica, enquanto a SQL mais
parecida com o ingls.
A linguagem SQL mais do que somente uma linguagem de consulta, sem que isto
se oponha ao query no seu nome. Ela fornece funes de recuperao e
atualizao de dados, alm de criao, manuteno da estrutura de dados e controle
do ambiente do BD.
uma linguagem essencialmente interativa, porm 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
caractersticas so:
_ Padro ANSI (American National Standard Institute). O ANSI estabeleceu-se
como um padro 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.
_ Padro de acesso. Todo o acesso ao BD Relacional feito em SQL, mesmo que
embutida em outra linguagem.
_ Interpretada (no compilada), caracteristica que prov maior grau de
independncia de dados aos BD relacionais, ou seja, faz com que a aplicao
reconhea alteraes nas estruturas de dados, sem necessidade de ser recompilada.

19

_ DDL, DML e DCL. O SQL possui esses trs grupos de comandos, montados
conforme a funo do comando no banco de dados. Esta caracterstica tambm
relaciona-se independncia de dados, uma vez que pode-se descrever os dados
(DCL) de forma independente das aplicaes (DML).
_ DDL (Data Definition Languge). Linguagem para definio de dados, que
compreende os seguintes comandos SQL:
_ CREATE - Utilizado para criar objetos (tabela, ndice, view, sequence, etc.)
no BD.
Exemplo: Criao da tabela funcionrio com os atributos matricula e nome.
CREATE TABLE funcionrio
(matricula number(05)
nome
char (30);
_ ALTER - Utilizado para alterar objetos do BD (adicionar colunas, modificar
tipo de dados, adcionar integridade, etc.).
Exemplo: Adio da integridade de chave primria tabela funcionrio.
ALTER TABLE funcionrio
ADD CONSTRAINT PRIMARY KEY (matricula);
_ DROP - Exclui objetos do BD.
Exemplo: Excluso da tabela funcionrio do BD.
DROP TABLE funcionrio

20

_ DML (Data Manipulation Languge). Linguagem para manipulao de

de dados, que compreende os comandos para que o usrio interaja com
os dados armazenados no BD.
SELECT - Comando de leitura, utilizado para que o usurio possa
efetuar consultas (query) nas tabelas do banco de dados. o comando
mais poderoso do SQL, efetua as sete operaes da algebra relacional
conforme veremos no captulo sobre banco de dados Relacional. Seu
formato bsico 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 funcionrio matricula e nome, onde o salrio
seja maior do que 500,00.
SELECT matricula, nome
FROM funcionrio
WHERE salrio > 500,00;

INSERT - Utilizado para incluir registros nas tabelas do banco de

dados.
Exemplo: Incluso de um registro na tabela funcionrio.
INSERT INTO funcionrio (matricula, nome)
VALUES ( 20,Maria do Carmo);
UPDATE - Utilizado para alterar dados nas tabelas do banco de dados.
Exemplo: Alterao no salrio do funcionrio de matrcula igual a 20.
UPDATE funcionrio
SET salrio=1200
WHERE matricula=20;
DELETE - Utilizado para excluir registros das tabelas do banco de
dados.
Exemplo: Excluso do funcionrio de matrcula igual a 20.
DELETE funcionrio
WHERE matricula=20;

21

2. LINGUAGEM AUTOCONTIDA
Esta modalidade de linguagem a extenso procedural do SQL, que nos
SGBD-R utilizada para desenvolvimento de programas que ficam
residentes no banco de dados (TRIGGERS, STORED PROCEDURES,
FUNCES). Acrescenta ao SQL interativo estruturas de deciso (IFTHEN-ELSE) e repetio (LOOP, FOR e/ou DO WHILE). uma
linguagem proprietria (Cada SGBD possui a sua). Os programas
escritos nessa linguagem geralmente assemelham-se a programas
PASCAL.
3. LINGUAGEM HOSPEDEIRA
So linguagens procedurais de 3 gerao (notadamente o COBOL)
utilizadas como hospedeiras (host) de comandos prprios de banco de
dados. Linguagens hospedeiras foram muito utilizadas nos SGBD dos
modelos Hierrquicos e Rede, dado que nestas geraes de SGBD ainda
no 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 introduo dessa nova cultura.
Os SGBD que utilizam linguagens hospedeiras. possuem um software
PR-COMPILADOR, que inserido na rotina de compilao do fonte do
programa hospedeiro, para converter os comandos de BD (estranhos
linguagem HOST) em linguagem objeto ou chamadas (CALL) de rotinas
intelegveis pelo compilador a linguagem.
Esquema de compliao com linguagem hospedeira:
PROGRAMA
FONTE
HOSPEDEIRO

PR_
COMPILADOR

PROGRAMA
PR_
COMPILADO

PROCESSO
NORMAL DE
COMPILAO

22

4. LINGUAGEM VISUAL
As linguagens visuais atualmente dominam o ambiente de
desenvolvimento para a arquitetura Cliente/Servidor. Nessa arquitetura,
so utilizadas para desenvolver a interface Cliente da aplicao.
Recebem a denominao de FRONT-END. Geram aplicaes para
ambiente grfico, padro WINDOWS. So orientadas a eventos e em sua
maioria, baseiam-se na tecnologia de Orientao a Objetos,
apresentando recursos como classe, objeto, herana, polimorfismo, etc..
Utilizam o SQL como linguagem para acesso aos bancos de dados
relacionais, atravs de APIs (Aplication Program Interface) nativas ou
genricas (ex: ODBC e ODAPI). Como exemplos de linguagem dessa
categoria podemos citar: DELPHI, VISUAL BASIC, POWER BUILDER,
CENTURA, etc..
Nossa maior preocupao neste texto chamar a ateno do leitor para
o fato de que essas linguagens so FRONT_ENDs de SGBD relacionais.
Apesar de serem orientadas a objeto, no devem ser confundidas com os
BD relacionais ou Orientados a Objeto, este ltimo, ainda uma
tecnologia que ocupa um espao restrito no mercado.
Esquema de acesso a BD relacional com linguagem visual:

SQL
PRGRAMA EM
LIGUAGEM
VISUAL

SQL PARO

API
DADOS

BD-R
DADOS

5. LINGUAGENS PARA INTERNET

Nesse grupo de linguagens, incluem-se aquelas utilizadas para
manipular, formatar, manipular e apresentar as informaes que so
acessadas na INTERNET atravs dos Browsers, das quais, destacam-se:
HTML, JAVA SCRIPT, ASP e JAVA.

23

CONCLUSO
O banco de dados constitui a parte esttica da aplicao. A dinmica de
um sistema dada pelas linguagens que armazenam, recuperam e
manipulam as informaes contidas no BD e existem diversas maneiras
para se executar essas tarefas.
A evoluo das linguagens aponta para utilizao de produtos no
proprietrios e que privilegiem a reutilizao do cdigo, alm dos dados
que j so amplamente reutilizados atravs da tecnologia relacional. Isso
porque, o cdigo contm a inteligncia das aplicaes (regras do
negcio) que, em ltima anlise, refletem o conhecimento da empresa a
respeito do seu negcio. A reutilizao do cdigo pode trazer, como
benefcios imediatos, a reduo no tempo e custo de desenvolvimento e
manuteno de novas aplicaes, a padronizao de processos e a
melhoria constante na qualidades dos sistemas gerados.
A medida que surgem novas tecnologias para acesso s informaes do
BD, muitos sistemas antigos permanecem como legados, porque so
sistemas crticos, de difcil substituio, ou porque so satisfatrios e, em
anlise de custo / benefcio, tem o seu redesenvolvimento
desaconselhado. Alm disso, as necessidades de acesso s informaes
esto se diversificando, as empresas esto abrindo suas fronteiras e
oferecendo acesso direto do cliente a suas bases de dados. Como
resultado, comum observarmos ambientes de sistemas heterogneos,
desenvolvidos com tecnologias diferentes, em termos de linguagens e
banco de dados, onde observamos COBOL convivendo com DELPHI,
VB, HTM, JAVA, etc..
Nesse contexto, tambm surge como uma tendncia o desenvolvimento
de aplicaes em trs ou N camadas. O foco principal dessa tecnologia
maximizar a reutilizao de cdigo, atravs do desenvolvimento das
regras do negcio em componentes reutilizveis, que obedeam a
padres de mercado (CORBA, COM/DCOM, EJB) e que funcionem como
linguagens universais, podendo ser acionados a partir de interfaces
clientes desenvolvidas em diferentes linguagens.
Em sntese, o bancos de dados relacionais tornaram-se grandes
repositrios de dados, constituindo uma tecnologia madura que tem
atendido satisfatoriamente o mercado. Do lado das aplicaes, observase uma tendncia a diversificao de tecnologias, sem descuidar dos
benefcios que podem trazer a reutilizao das regras de negcio.

24

CAPTULO VI

BANCO DE DADOS RELACIONAL

O Modelo Relacional de Banco de Dados, utiliza a teoria de conjuntos como base
conceitual para a formulao de seus conceitos. Esse pressuposto facilita o
entendimento por parte do usurio e possibilita a representao do mundo real de
forma mais natural.
O Modelo Relacional, comeou 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
comprovao da teoria Relacional, publicada em uma srie 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 bibliogrfica para elaborao desse material,
notamos que, existem interpretaes ambiguas e at contraditrias em relao a essas
regras. Portanto, para notear o estudo do modelo Relacional, adotamos a abordagem
de C. J. DATE, que apresenta o Modelo Relacional como possuindo as seguintes
caractersticas fundamentais, que o distingue dos demais modelos:
_ Estrutura de dados tabular
_ Regras de integridade
_ Operadores relacionais
_ Utilizao do SQL (Structured Query Language)
O modelo Relacional, assim como seus antecessores, nasceu no ambiente dos
computadores de grande porte (mainframe). Sofreu resties ao uso, por demandar
muita memria principal para alcanar uma performance (tempos de resposta) que o
tornasse comercialmente vivel. Ganhou fora a partir do incio a dcada de 80, com
a revoluo tecnolgica provocada pela produo em larga escala dos
microcomputadores PC, o que propiciou o barateamento do harware.
Atualmente o modelo relacional um padro 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

25

a. Os SGBD RELACIONAIS representam os dados sob a forma de

TABELAS bidimensionais (linhas X colunas), denominadas RELAES.
b. As linhas das tabelas so conhecidas como TUPLAS e as colunas
como ATRIBUTOS.
c. O nmero de atributos (colunas) de uma relao (tabela) determina o
GRAU DA RELAO. Portanto uma relao com quatro colunas possui
grau quatro.
d.

A interseo
CLULA.

linha

coluna

de

uma

tabela

demomina-se

e. O contedo de uma clula denomina-se valor de atributo .

f. Cada clula de uma tabela relacional comporta apenas um valor de
atributo, caracterstica a qual designa-se por ATOMICIDADE (valor
atmico).
g. O conjunto de valores possveis para um atributo de tabela denominase DOMNIO. Por exemplo, o domnio para o atributo cargo pode ser
definido como: Valor numrico entre 1 e 10.

ATRIBUTO

RELAO: FUNCIONRIO
MATR
NOME
CARGO DT_NASC
01
MIRIAM
01
25/09/62
02
JUVENAL
03
18/04/70
02
10/02/68
03
GABRIELA

CLULA

TUPLA

VALOR DE
ATRIBUTO

2. REGRAS DE INTEGRIDADE
26

Integridade de dados o conjunto de parmetros (regras do negcio)

previamente estabelecidos e criados no banco de dados, aos quais os
dados so submetidos, para garantir que de um processo de atualizao
no resultem dados inconsistentes.
Uma das caractersticas mais fortes dos SGBD-R, est em oferecer
mecanismos para a criao de regras de integridade diretamente no
banco de dados. Nesse ponto a grande vantagem em relao aos
demais modelos (Hierrquico e Rede), consiste n o gerenciamento
automtico e centralizado de rotinas de integridade pelo SGBD, do que
decorrem fatores como a eliminao de cdigos redundntes e maior
segurana no que se refere consistncia das informaes.
Por outro lado, a possibilidade de de definir integridade no BD, no
descarta a hiptese de mante-la no fonte da aplicao que acessa o BD.
Na arquitetura Cliente/Servidor, essa prtica muito corriqueira e pode
trazer significativos ganhos de performance.
As regras de integridade de dados podem ser implementadas nos SGBDR de forma DECLARATIVA ou PROCEDURAL:
a. INTEGRIDADE DECLARATIVA
A integridade declarativa implementada no BD, atravs de parmetros
opcionais da linguagem de definio de dados (DDL). Os tipos mais
comus de integridade declarativa so: CHAVE PRIMRIA, DOMNIO e
INTEGRIDADE REFERENCIAL.
A integridade de CHAVE PRIMRIA garante que a chave primria da
tabela no contenha valores em duplicata e nem valor NULO.
A integridade de DOMNIO permite restringir o universo de valores
vlidos para uma coluna.
A integridade REFERENCIAL garante o sincronismo de valores entre a
chave estrangeira (foreign key) e a respectiva chave primria. Esse tipo
de integridade ser tratado com maiores detalhes no item c deste
capitulo.

27

Na DDL do ORACLE, por exemplo, o comando CREATE apresenta as

seguintes opes de integridade declarativa:
_ PRIMARY KEY - Garante a integridade de chave primria.
_ NOT NULL - Torna o campo de preenchimento obrigatrio.
_ CHECK - Permite a integridade de domnio.
_ UNIQUE - Evita a ocorrncia de valores em duplicata.
_ FOREIGN KEY - Implementa a integridade referencial.
Exemplo:
CREATE TABLE funcionrio
(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 primria
(PRIMARY KEY), da condio de campo obrigatrio (NOT NULL) e da
integridade de domnio (CHECK), todas especificadas de forma
declarativa. Nenhuma linha de cdigo necessria nos programas que
acessam BD para garantir essas integridades.

28

b. INTEGRIDADE PROCEDURAL
A Integridade Procedural apresenta-se sob a forma de um programa, cuja
lgica escrita pelo programador, na linguagem procedural nativa do
SGBD. Esse tipo de integridade supre as necessidades no cobertas
pelos parmetros de integridade declarativa.
No ORACLE a integridade procedural pode ser criada atravs de
TRIGGERS, STORED PROCEDURES ou FUNES DO USURIO.
Estes elementos so escritos em PL/SQL que a extenso procedural do
SQL desse SGBD.
Um TRIGGER (gatilho) criado para disparar, automaticamente, sempre
que o SGBD detectar a ocorrncia de um ou mais comandos de acesso a
tabela.
Exemplo:
CREATE TRIGGER atualiza_saldo
AFTER INSERT ON TABLE lanamentos
BEGIN
UPDATE Tab_saldo
SET saldo_atual=saldo_atual + valor_lanamento;
END;
No exemplo, sempre que um registro for includo na tabela lanamentos
o trigger dispara e atualiza o saldo_atual na tabela tab_saldo.
Nem todos os SGBD possuem integridade procedural. Esse recurso
mais frequente nos SGBD de maior porte como ORACLE, DB/2,
INFORMIX, SQL SERVER, etc..

29

c. INTEGRIDADE REFERENCIAL
A Integridade Referencial o mecanismo dos SGBD-R que, no processo de
atualizao do BD, mantm o sincronismo entre duas tabelas relacionadas, em
relao aos valores da chave estrangeira e da respectiva chave primria.

TABELA PAI

FUNCIONRIO
MATRICULA- PK
1

TABELA FILHO

DEPENDENTE
MATRICULA- FK

A integridade referencial evita a ocorrncia de registros orfos no banco de

dados, ou seja, registros filhos sem a correspondente linha de referencia na
tabela pai.
Os SGBD_R que seguem o padro SQL ANSI/92, suportam a integridade
referencial de forma declarativa. Possuem ainda aes referenciais, que
propagam atualizaes e excluses efetuadas na tabela pai para a tabela filho.
As aes referenciais propiciam, por exemplo, que a excluso de um registro
pai provoque a excluso automtica de seus respectivos filhos (excluso em
cascata), ou que a alterao no valor de uma chave primria reflitam
automticamente para os registros que a referenciam (atualizao em cascata).

30

Exemplo:
CREATE TABLE funcionrio
(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_funcionrio number(05) FOREIGN KEY
REFERENCES funcionrio.matricula
ON DELETE CASCADE);
O exemplo apresenta a integridade referencial, declarada na tabela
dependente, indicando que o campo matricula_funcionrio dessa tabela,
refere-se ao campo matricula da tabela funcionrio. Com essa declarao o
SGBD garante que a incluso de um DEPENDENTE, somente ser valida
caso exista o FUNCIONRIO correspondente.
Por outro lado, a clusula ON DELETE CASCADE indica que sempre que
for excludo um registro da tabela funcionrio, o SGBD deve excluir
automticamente os registros da tabela dependente a ele relacionados.

31

3. OPERADORES RELACIONAIS
Os Operadores Relacionais constituem mecanismos do SGBD-R para
recuperao de informaes no Banco de Dados. Inserem-se no contexto
da Algebra Relacional que possui sete operadores, sendo trs relacionais
(PROJEO, SELEO e JUNO) e quatro operadores tradicionais de
conjunto (UNIO, INTERSEO, DIFERENA 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 so implementados por variaes nas
clusulas do comando SELECT.
No prximo captulo trataremos dos operadores relacionais com
exemplos da aplicao de cada um deles.

32

4. PROPRIEDADES RELACIONAIS
As Propriedades relacionais so consideraes bvias, porm
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 sobrepem ou confirmam as regras de
integridade.
a. Uma tabela no deve possuir duas linhas iguais. Isto se explica
pelo fato de que as linhas so componentes de um conjunto (a tabela) e
se faz necessrio poder distinguir os elementos de um conjunto. Assim
sendo, pelo menos um atributo componente da linha deve possuir um
valor que a diferencie das demais. Nos modelos relacionais o diferencial
mnimo entre duas linhas de uma tabela a chave primria.
b. Toda a tabela de um BD relacional deve possuir chave primria.
Essa propriedade decorre da anterior. Atualmente, todos os SGBD-R
disponveis no mercado mantm automaticamente a unicidade da chave
primria. Por outro lado, alguns produtos relacionais permitem a criao
de tabelas sem PK, deixando a critrio do analista a sua declarao ou
no, o que contraria esta propriedade mas atribui maior flexibilidade ao
produto.
c. Cada tabela deve possuir um nome prprio, distinto das demais
tabelas do mesmo banco de dados. Essa propriedade tambm deriva
da teoria de conjuntos, j que as tabelas so 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 (sinnimo).
e. Os SGBD-R somente operam com estruturas de dados de formato
tabular, normalizadas pelo menos em !FN (1 forma normal), onde a
principal caracterstica a atmicidade, ou seja, ocorrncia de apenas
um valor de atributo para cada clula da tabela. Esse nvel de
normalizao exigido para tornar possvel a aplicao da lgebra
Relacional para recuperar informaes contidas nas tabelas do BD.
Nveis mais altos de normalizao (2FN a $FN) so teis para diminuir a
redundncia, melhorar a consistncia e integridade dos dados.

33

f. A ordem das linhas e colunas na tabela irrelevante, pois pode ser

facilmente modificada nas consultas, atravs dos recursos da lingugem
SQL (Structured Query Language).
g. Os SGBD-R devem ser capazes de tratar, de maneira diferenciada
o valor NULO (NULL), que indica ausncia 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 relao aos sistemas de arquivos convencionais e
SGBD Hierrquicos e Rede so:
a. Linguagem SQL interativa e muito prxima da linguagem natural
escrita (ingls);
b. Facilidade no entendimento da estrutura de dados tabular;
c. Maior possibilidade de utilizao direta pelo usurio final;
d. Centralizao da integridade no BD.
e. Reduo no tamanho dos cdigos de programa;
f. Maior integridade e consitncia de dados;
g. Maior segurana;
h. Maior flexibilidade para acrscimo de novas informaes no BD;
i. Possibilidade de criar gatilhos (TRIGGERS)
armazenados (STORED PROCEDURE);

procedimentos

j. Maior Produtividade.
l. Padronizao dos produtos facilitando a difuso e preservao da
cultura relacional.

34

CAPTULO VII

LGEBRA RELACIONAL
A lgebra Relacional uma teoria matemtica baseada nas relaes entre conjuntos.
Da sua aplicao 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 informao
original, a partir da formulao de relaes entre as tabelas do banco de dados. Essas
relaes so providas pelos operadores da lgebra relacional, que se encontram
disponveis nos recursos da linguagem SQL (Structured Query Language).
Os operadores da lgebra relacional classificam-se em dois grupos:
_ OPERADORES TRADICIONAIS DE CONJUNTO
. UNIO
. INTERSEO
. DIFERENA
. PRODUTO CARTESIANO
_ OPERADORES RELACIONAIS
. PROJEO
. SELEO
. JUNO
Para classificar-se um SGBD como Relacional, fundamental que ele possua, entre
outras caractersticas, no mnimo os trs operadores relacionais, haja vista que, nem
todos os SGBD-R possuem os sete operadores. Os Operadores Tradicionais so mais
encontrados em SGBD mais robustos, como ORACLE, SYBASE e DB/2.

35

1. ESTUDO DE CASO

O grfico abaixo corresponde ao Modelo de Entidades e Relacionamentos

(MER) de um banco de dados, que ser utilizado como referncia para o
estudo dos operadores relacionais.

CLIENTE
1

N
CONTA

36

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

CLIENTE
ID-CLI
001
002
003
004
005
006
007
008

NOME
RITA
MARCELO
CARLA
VTOR
RAQUEL
BRUNA
SNIA
GETLIO

ENDEREO TIPO
SQN
V
GUAR
C
GAMA
E
SQS
C
SQS
E
GUAR
V
CRUZEIRO
C
SQN
C

CONTA_CORRENTE
NUMAGENCIA CONT ID-CLI
A
106
001
004
106
002
003
106
040
003
167
001
005
167
005
007
167
006
008
202
001
001
202
002
003
202
003
002
202
004
004

SIT
0
2
0
0
0
2
0
1
0
2

C = COMUM
E= ESPECIAL
V= VIP

SALDO
20.000,00
250,00
500,00
50,00
10,00
20,00
150,00
0
30,00
50.000,00
0 = ATIVA
1 = INATIVA
2 = BLOQUEADA

37

2. GENERALIDADES
a. Nos SGBD que utilizam o SQL padro ANSI (Americam National
Standard Institute),
os operadores da lgebra Relacional so
implementados por variaes de parmetros na sintaxe do comando
SELECT, que um comando de leitura da base de dados.
b. A sintaxe utilizada para os comandos SELECT, que aparecero nos
exemplos, foi extrada dos manuais do SGBD ORACLE, que segue o
padro SQL ANSI. A estrutura bsica do comando SELECT :
SELECT colunas.... ou * (que significa todas as colunas)
FROM tabelas .....
WHERE condio........

c. As operaes da lgebra relacional geram sempre uma tabela

resultado residente em memria principal (tabela virtual), que em
analogia com a teoria de conjuntos, pode ser vazia, unitria ou conter N
linhas.
d. As operaes podem ser efetuadas entre duas tabelas virtuais
atravs da combinao de dois comandos SELECT em uma nica
sentena.
e. comum a combinao de diversos operadores da gebra
Relacional em um nico comando SELECT. A anlise individual de cada
um deles um exerccio meramente didtico.
f. As situaes criadas, so apenas ensaios, que no esgotam as
possibilidades de utilizao dos operadores. Alm disso, uma mesma
necessidade pode ter mais de uma soluo. Portanto a utilidade dos
operadores depende do problema tratado e da criatividade do tcnico.

38

3. OPERADORES DE CONJUNTO
a. UNIO
A unio de duas tabelas A e B, resulta numa tabela virtual C,
contendo o total de linhas das tabelas envolvidas na operao.
No sistema exemplo, imagine que cada agncia mantenha os dados
cadastrais de CLIENTE em servidores locais de sua rede, e que esses
servidores esto ligados em um servidor corporativo. Para se obter no
servidor corporativo uma viso 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 idntico ao que temos na amostragem da tabela
CLIENTE do sistema exemplo:
ID-CLI
001
002
003
004
005
006
007
008

NOME
RITA
MARCELO
CARLA
VTOR
RAQUEL
BRUNA
SNIA
GETLIO

ENDEREO
SQN
GUAR
GAMA
SQS
SQS
GUAR
CRUZEIRO
SQN

TIPO
V
C
E
C
E
V
C
C

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma

seqncia.

39

b. INTERSEO
A Interseo entre duas tabelas A e B, resulta numa tabela virtual
C, contendo as linhas comus s duas tabelas envolvidas na
operao.
No sistema exemplo, considere a necessidade de se listar o
IDCLI"
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 seqncia.

40

c. DIFERENA
A Diferena entre duas tabelas A e B (na ordem A - B), resulta
numa tabela virtual C, contendo as linhas pertencentes
exclusivamente tabela A e no a B.
No sistema exemplo, considere a necessidade de se listar o ID-CLI"
de clientes que no 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 seqncia.

41

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, atravs da concatenao de suas linhas.
Essa operao tem uma certa semelhana com a JUNO, pois
combina dados de mais de uma tabela, exceto que no estabelece
nenhum critrio (join condition) para isso.
Geralmente o Produto utilizado para construo de massas de teste
ou quando o tcnico 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;

42

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
.
.
.
.
SNIA
30,00
.
.
.
.
.
.
GETLIO
50,000,00

43

3. OPERADORES RELACIONAIS
e. PROJEO
A Projeo consiste em obter um subconjunto de colunas de
uma ou mais tabelas_base, como resultado de uma consulta
parcial aos dados disponveis no banco de dados.
Geralmente utilizada em conjunto com as demais operaes
para produzir resultados de consultas, ou ainda, para criar
vises (VIEWs), que restringem o acesso do usurio a determinados
atributos da base de dados.
No sistema exemplo, uma consulta contendo nome e endereo dos
clientes, corresponde a uma PROJEO elaborada a partir da tabelabase CLIENTE, atravs da seguinte sentena SQL:
SELECT nome, endereo
FROM cliente;
Considerando a amostragem da tabela CLIENTE do sistema exemplo, o
resultado do SQL anterior seria:
NOME
RITA
MARCELO
CARLA
VITOR
RAQUEL
BRUNO
SNIA
GETLIO

ENDEREO
SQN
GUAR
GAMA
SQS
SQS
GUAR
CRUZEIRO
SQN

44

f. SELEO
Tambm conhecida como Restrio, essa operao tem por finalidade
selecionar um subconjunto de linhas de uma ou mais tabelas_base,
de acordo com critrios (where criteria), que envolvem atributos e
valores para filtrar os dados desejados, gerando uma consulta parcial
aos dados disponveis no banco de dados.
Geralmente utilizada em conjunto com as demais operaes
para produzir resultados de consultas, ou ainda, para criar
vises (VIEWs), que restringem o acesso do usurio a determinadas
linhas de tabelas na base de dados.
Os Critrios de Seleo so traduzidos na sintaxe do comando
SELECT, pela combinao de operadores lgicos (AND, OR, NOT),
aritimticos (=, <>, >, <, >= e <=) e operadores SQL (BETWEEM, LIKE,
IN, NULL), representados na clusula WHERE.
No sistema exemplo, uma consulta contendo somente os clientes VIP,
corresponde a uma SELEO elaborada a partir da tabela-base
CLIENTE, atravs da seguinte sentena SQL.
SELECT *
FROM cliente
WHERE tipo = V;
Considerando a amostragem da tabela CLIENTE do sistema exemplo, o
resultado do SQL anterior seria:
ID-CLI NOME
ENDEREO
001 RITA
SQN
006 BRUNA GUAR

TIPO
V
V

45

g. JUNO
Essa operao relacional utilizada para compor informaes
complexas a partir de tabelas relacionadas. A juno de duas tabelas
A e B concatena as linhas das tabelas envolvidas, resultando numa
tabela virtual C.
Para efetuar a JUNO de duas tabelas essencial que elas estejam
logicamente relacionadas, conforme prev o modelo relacional, ou
seja, o grau do relacionamento deve ser no mximo 1 : N, sendo que
a chave primria da entidade 1 deve figurar como chave estrangeira
da entidade N. Alm disso, os valores dessas chaves devem ser
coincidentes, para as linhas que se deseja concatenar.
A juno notada na sintaxe do SQL, pela comparao de atributos
chave primria / chave estrangeira, atravs da clusula WHERE do
comando SELECT, o que denominamos condio de juno (join
condition). Quando o tcnico 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 juno entre as tabelas CLIENTE e

CONTA_CORRENTE:
SELECT nome, saldo
FROM cliente, conta_corrente
WHERE cliente.id-cli = conta_corrente.id-cli;

46

Considerando as amostragens das tabelas

do sistema exemplo
referenciadas no comando anterior, a tabela resultado seria:
NOME
RITA
MARCELO
CARLA
CARLA
VITOR
VITOR
RAQUEL
SNIA
GETLIO

SALDO
150,00
30,00
500,00
0,00
20.000,00
50.000,00
50,00
10,00
20,00

Note que a cliente de nome BRUNA no figura na tabela resultado

porque no possui registro na tabela CONTA_CORRENTE.

47

PARTE II - PROJETO DE BANCO DE DADOS

INTRODUO
A modelagem de um sistema de processamento de dados pode ser feita a partir de dois
enfoques:
1) Enfoque dos DADOS que so processados;
2) Enfoque das FUNES que tratam esses dados.
Esses dois enfoques so complementares e, usados conjuntamente, fornecem ao analista os
dois principais ngulos do problema em anlise: DADOS E FUNES. O Diagrama de
fluxo de dados (DFD) e o Diagrama Hierrquico Funcional (DHF) so exemplos de
ferramentas com enfoque FUNCIONAL e o Modelo de Entidade e Relacionamentos (MER)
o diagrama utilizado para prover a viso dos DADOS.
Os modelos Funcional e de Dados, ao integrarem um projeto de sistemas, constituem-se em
importantes instrumentos para, entre outras coisas:
_ Apresentar, atravs de diagramas, uma sntese do problema, destacando seus aspectos
mais relevantes;
_ Oferecer uma viso contextual do sistema em anlise.
_ Facilitar a comunicao entre os integrantes da equipe de desenvolvimento (gerentes,
analistas, usurios, etc);
_ Motivar a participao do usurio no projeto;
_ Documentar o processo de anlise, para que o trabalho no sofra soluo de continuidade;
Apesar dos dois enfoques (Funcional e de Dados) do processo de anlise de sistemas, este
texto trata, especificamente, da MODELAGEM DE DADOS, com o emprego do MODELO
DE ENTIDADES E RELACIONAMENTOS e da tcnica de NORMALIZAO, adotando
a METODOLOGIA DE PROJETO DESCENDENTE (Setzer, Valdemar) como referencial
metodolgico para o proceso de modelagem.

48

CAPTULO VIII
NVEIS DE ABSTRAO
Ao projetar um sistema de informaes para ser implantado no computador, o projetista
elabora um modelo da realidade, visando adequa-la s limitaes do ambiente do
computador. Devido complexidade do mundo real e seguindo a linha de abordagem TOP
DOWN, o processo de modelagem atravessa diversas fases, s quais Setzer1 denominou
NVEIS DE ABSTRAO, em sua Metodologia de Projeto Descendente, que usaremos
como referncia neste texto e que encontra esquematizada na figura a seguir:
MUNDO REAL

MODELO
DESCRITIVO

Texto, documentos, entrevistas, relatrios,

etc..

MODELO
CONCEITUAL

MER ou DFD

NORMALIZAO
MODELO
OPERACIONAL

MODELO
INTERNO

MER Normalizado

DDL do banco de dados

Waldemar W. setzer - livro:Projeto de Banco de Dados

49

Os NVEIS DE ABSTRAO, propostos por Setzer, representam as diferentes vises que

um analista obtm de uma realidade (MUNDO REAL), a medida que avana no processo de
modelagem, at chegar ao sistema implantado. A partir do MUNDO REAL, Setzer prope
quatro nveis de abstrao, que so os modelos DESCRITIVO, CONCEITUAL,
OPERACIONAL E INTERNO.

1. MUNDO REAL
O MUNDO REAL envolve todos os objetos (normas, pessoas, eventos,
fatos, organismos sociais, etc..), que compem o CENRIO, do qual, o
analista dever extrair a parte a ser representada no computador, que
pode ser uma empresa, um departamento, setor, processo de negcio,
etc..

2. MODELO DESCRITIVO
Este modelo representado por um texto contendo a descrio do
mundo real (ambiente alvo do estudo), explicitando as caractersticas do
problema a ser tratado atravs de regras do negcio, elenco de
necessidades, a anlise de requisitos, questionrios, formulrios,
relatrios, informaes sobre volume, etc.. Constitui o primeiro nvel da
modelagem, onde o analista estabelece as fronteiras do sistema.
Neste nvel de abstrao, o modelador identifica a rea alvo da
modelagem, descreve o problema a ser solucionado e identifica os
componentes sobre os quais se deseja armazenar e recuperar
informaes. Deve-se relatar o maior o nvel de detalhes possvel a
respeito do problema, cuidando-se para no perder a objetividade.
O maior problema do modelo descritivo a falta de padro. Existem
vrias maneiras de se descrever o mesmo problema, as palavras
possuem significados variados e podem causar dupla interpretao, ou
seja, ambigidade. Para amenizar esse problema, deve-se evitar
perodos longos, procurar trabalhar com tpicos, frases curtas e utilizar
palavras precisas e adequadas ao vocabulrio profissional do usurio.

50

3. MODELO CONCEITUAL
um modelo baseado em smbolos PADRONIZADOS, que expressa,
graficamente, os CONCEITOS do MUNDO REAL delineados no Modelo
Descritivo. A utilizao de uma simbologia padronizada torna a linguagem
mais precisa, o que facilita a comunicao entre os integrantes da equipe
de desenvolvimento, especialmente, entre analistas e usurios. Portanto,
esse modelo o mais adequado para o registro e validao dos
conceitos do mundo real, nas fases do projeto que envolvem o usurio.
O produto dessa fase da anlise deve ser um MODELO DE ENTIDADES
E RELACIONAMENTOS (MER) enfocando a viso dos DADOS com alto
nvel de abstrao, ou seja, voltado para o MUNDO REAL e sem
preocupar-se com detalhes do ambiente operacional, como, por exemplo,
o software e hardware no qual o sistema ser implantado.
Neste nvel da modelagem, deve-se ressaltar os aspectos mais
relevantes do problema, ou seja, representa-se principais entidades,
relacionamentos, estruturas de dados e integrao com outros sistemas.
Os detalhes do banco de dados (chaves primrias, estrangeiras,
integridades, etc.) devem ser deixados para a fase seguinte, de
construo do modelo operacional.

4. MODELO OPERACIONAL
O modelo Operacional decorre da anlise do modelo Conceitual, visando
torna-lo adequado ao ambiente operacional, no qual o sistema ser
implantado. No caso especfico deste texto, essa anlise visa adaptar o
modelo Conceitual s limitaes de um Sistema Gerenciador de Banco
de Dados Relacional (SGBD-R).
Obter o projeto das tabelas do banco de dados o principal objetivo
dessa fase e para alcana-lo, o analista deve investigar cada entidade do
Modelo Conceitual, decompor estruturas em elementos de dados, utilizar
a NORMALIZAO e o conhecimento sobre o MODELO RELACIONAL
como balizadores de suas aes.
Nesta fase, o dicionrio de dados do Modelo Conceitual enriquecido
com a escolha das chaves primrias, definio de chaves estrangeiras,
ndices, integridades, e outros detalhes essenciais para a criao do
banco de dados.

51

5. MODELO INTERNO
Corresponde ao sistema implementado no computador, ou seja,
representado pelo conjunto de linhas de cdigo geradas na linguagem do
SGBD, que no caso dos modelos Relacionais o SQL (structured query
language).
Do ponto de vista terico, o modelo Operacional seria o ideal para ser
implantado. Porm, a prtica revela que esse modelo ainda pode sofrer
modificaes antes que o BD seja criado. Os principais fatores que
determinam essas modificaes so a MELHORIA DE PERFORMANCE
e a DISTRIBUIO DE DADOS.
Visando aumentar a performance, podem ser criadas redundncias, com
a desnormalizao e criao de tabelas totalizadoras para gerao de
informaes gerenciais. Nesses casos, deve-se ter especial cuidado com
a consistncia do BD no processo de atualizao dos dados. Alm disso,
deve-se considerar que a redundncia de dados aumenta os custos com
processamento e armazenamento de dados, que devem ser
compensados pelo benefcio esperado.
Com relao distribuio de dados comum a criao de cpias de
tabelas (distribuio por replicao) ou a fragmentao de uma entidade
do modelo operacional em vrias tabelas no redundantes (distribuio
por particionamento). Em ambos os casos, as partes resultantes so
distribudas em diversos ns da rede e a manuteno dessas partes ser
facilitada caso o SGBD possua algum mecanismo de gerenciamento
automtico de distribuio de dados.

52

CAPITULO IX
MODELO DE ENTIDADES E RELACIONAMENTOS
O MODELO DE ENTIDADE E RELACIONAMENTOS (MER), foi proposto
originalmente por PETER CHEN em 1976. Seu objetivo, ao publicar esse trabalho,
era consagrar um mtodo eficiente para representar os dados e ressaltar a diferena
entre as estruturas suportadas pelos SGBD HIERRQUICOS, REDE e
RELACIONAL. Atualmente o MER tem sido utilizado para representar a viso dos
dados no projeto de banco de dados.
A principal vantagem do MER a simplicidade. O Modelo de Entidades e
Relacionamentos possui apenas trs componentes bsicos: ENTIDADE, ATRIBUTO
e RELACIONAMENTO (e seus respectivos smbolos para diagramao).
A proposta original de CHEN foi enriquecida por trabalhos de diversos autores, que
procuraram atribuir maior capacidade semntica ao MER, o que gerou as camadas
EXTENSES. As extenses ao MER possibilitam representar o mundo real com
maior riqueza de detalhes. Por outro lado, elas provocaram a diversificao dos
padres de notao e terminologia, contrastando com a proposta original de
simplicidade e acarretando problemas para a disseminao da cultura.
Este captulo procura exprimir uma viso objetiva do Modelo de Entidades, para
instrumentalizar o analista frente necessidade de representar a viso dos dados de
um projeto de sistema.

53

1. NOTAO E TERMINOLOGIA
ENTIDADE a representao genrica de um COMPONENTE DO
MUNDO REAL, SOBRE O QUAL DESEJAMOS ARMAZENAR
INFORMAES (ATRIBUTOS).
As ENTIDADES podem representar coisas tangveis (pessoal, material,
patrimnio, etc.) ou intangveis (eventos, conceitos, planos, etc.).
Para NOTAR graficamente uma entidade emprega-se um RETNGULO
identificado por um substantivo (simples ou composto).
Exemplo:

CLIENTE

CONTA_CORRENTE

54

2. REGRAS PARA ATRIBUIO DE NOMES ENTIDADES

A literatura no consagra um padro para a atribuio de nomes a
entidades, mas, para alcanarmos um mnimo de padronizao,
indicamos observar as seguintes regras:
- Nomes breves e objetivos, grafados em maisculas e, que identifiquem
facilmente o contedo da entidade;
- No singular, j que a pluralidade decorre, naturalmente, do nmero de
ocorrncias (linhas / tuplas), caracterstica prpria de toda entidade.
- Nomes compostos separados por hfen, eliminando-se o uso de
preposies ou outros termos de ligao.
- Evitar abreviao de nomes. Se necessrio, ampliar o tamanho da
figura representativa da entidade.

55

3. ATRIBUTO
Os atributos so os dados que devemos armazenar a respeito da
entidade, para atender s necessidades de informaes demandadas
pelo usurio. Constituem tudo o que se pode relacionar como prprio
(propriedade) da entidade e que, de alguma forma, estejam contidos no
escopo do problema em anlise. Os atributos qualificam e distinguem as
entidades no MER.
Em relao 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 primria) denomina-se OCORRNCIA. Esse conceito anlogo
ao de linha (tupla) em tabela relacional e de registro em arquivo
convencional.
Pode-se exprimir os atributos no MER, conforme mostrado na figura
abaixo:

CONTA_CORRENTE

CLIENTE

0 endereo
0 nome
0 identificador

0 tipo (1-poupana, 2- C/C)

0 cod-agncia
0 num-conta

Cabe observar, que a representao de atributos no MER pode poluir o

grfico, comprometendo sua objetividade e viso contextual. Esse
recurso deve ser reservado para situaes especiais, em que voc queira
destacar um atributo, por considera-lo elucidativo para o contexto.

56

4. DICIONRIO DE DADOS
Os ATRIBUTOS so usualmente descritos sob a forma de estruturas e
elementos no Dicionrio de Dados, onde deve constar uma relao de
atributos para cada entidade do MER. As notaes mais utilizadas para
criao de dicionrios de dados so as definidas por GANE2 e
YOURDON3.
Exemplo da notao de Gane para descrio de estruturas de dados:
CLIENTE
IDENTIFICADOR
NOME
ENDEREO
CONTA_CORRENTE
NUMERO_CONTA
TIPO-CONTA (1-poupana, 2-c/c)
AGNCIA
CDIGO_AGNCIA
ENDEREO_AGNCIA
LANAMENTOS*
NUMERO_LANAMENTO
DATA
TIPO (deb, cre)
VALOR

2
3

GANE, CHRIS - LIVRO: ANLISE ESTRUTURADA DE SISTEMAS

YOURDON, EDWARD - LIVRO: ANLISE ESTRUTURADA MODERNA

57

A figura a seguir ilustra conceitos vistos nesse captulo, representando a entidade

FUNCIONRIO sob a forma de uma tabela do banco de dados.

ENTIDADE
DO MER

FUNCIONRIO

TABELA
DO BD

ENTIDADE FUNCIONRIO
MATRIC
01
02
03

NOME
MIRIAM
JUCA
JOO

CARGO
01
03
02

DT-NASC
25/09/62
18/04/70
10/02/68

ATRIBUTOS
OCORRNCIA

VALOR DE
ATRIBUTO
CLULA

58

5. RELACIONAMENTO
O relacionamento representa a relao existente entre entidades integrantes de um
MER. notado por uma LINHA ligando as ENTIDADES envolvidas e possuem
NOME e CARDINALIDADE. Veja a figura a seguir.
RELACIONAMENTO

CLIENTE

1 MOVIMENTA

CONTA_CORRENTE

NOME DO RELACIONAMENTO

CARDINALIDADE DO
RELACIONAMENTO

utiliza
um
LOSANGO
para
representar
o
Peter
Chen4
RELACIONAMENTO entre entidades, porm, a experincia demostra que
o uso dessa notao contribui para poluir o grfico e no produz
resultado prtico, exceto em casos de relacionamentos que envolvam
mais de duas entidades (relacionamento mltiplo - modelo conceitual).

CLIENTE

N
movimenta

CONTA_CORRENTE

Notao de CHEN

CHEN, PETER - LIVRO: MODELO DE ENTIDADES E RELACIONAMENTOS

59

6. CARDINALIDADE (GRAU DO RELACIONAMENTO)

A cardinalidade constitui um indicativo genrico da quantidade de
ocorrncias (mxima e mnima) de cada ENTIDADE envolvida no
relacionamento. expressa por sinais (flechas, ps-de-galinha, nmeros,
letras, etc..), que so grafados sobre a linha do relacionamento, nas duas
extremidades do mesmo.
A notao para a cardinalidade o item que apresenta maior variao
entre os autores que escrevem sobre o MER. Neste texto usaremos uma
barra para notar a cardinalidade 1 e o p-de-galinha para a
cardinalidade N.
Exemplo:
CARDINALIDADE N

CARDINALIDAD

CLIENTE

MOVIMENT

CONTA_CORRENTE

Considerando a cardinalidade, o relacionamento pode ser de trs tipos:

1) 1:1 - L-se UM para UM
Exemplo:
CLIENTE

MOVIMENTA

CONTA_CORRENTE

Indica que UMA ocorrncia da entidade CLIENTE relaciona-se com UMA

ocorrncia da entidade CONTA-CORRENTE e vice-versa,

60

2) 1:N - L-se UM para MUITOS

Exemplo:

CLIENTE

MOVIMENT

CONTA_CORRENTE

Indica que UMA ocorrncia da entidade CLIENTE relaciona-se com

muitas ocorrncias da entidade CONTA-CORRENTE e vice-versa,
3) M:N - L-se MUITOS para MUITOS
exemplo:

CLIENTE

MOVIMENTA

CONTA_CORRENTE

Indica que:

- UMA ocorrncia da entidade CLIENTE relaciona-se com MUITAS ocorrncias da

entidade CONTA- CORRENTE e;
- UMA ocorrncia da entidade CONTA-CORRENTE relaciona-se com MUITAS
ocorrncias da entidade CLIENTE. (cada das contas conjuntas)

61

7. NOME DO RELACIONAMENTO
o componente do modelo E-R que identifica o relacionamento,
justificando e esclarecendo a importncia de sua existncia para o
contexto estudado.
Exemplo:
NOME DO RELACIONAMENTO

CLIENTE

MOVIMENTA

CONTA_CORRENTE

Nos casos onde o relacionamento bvio torna-se dispensvel a

atribuio de nome ao mesmo.
O nome do relacionamento recomendvel nas seguintes situaes:
- Quando existirem diversas possibilidades bvias de relacionamentos
entre o par de entidades, sendo que, deseja-se representar apenas em;
- Por questo documentacional, para dar maior clareza ao modelo;
- Caso ocorra mais do que um relacionamento entre o par de entidades
(relacionamento duplo, triplo, etc.);
- No caso de AUTO-RELACIONAMENTOS (entidade relacionando-se
com ela mesma- recursividade)
- Quando da utilizao do MER para representar modelos a serem
implementados em SGBD REDE
- Quando da utilizao de CASE para desenho do MER ( caso a
ferramenta obrigue)

62

8. PAPEL
O papel das entidades no relacionamento fica implcito no nome e na
cardinalidade do mesmo e pode ser inferido a partir desses
componentes. Porm, especificar o PAPEL que cada entidade
desempenha uma alternativa, que pode substituir, com maior preciso,
a colocao do nome no relacionamento, atribuindo ao MER maior
capacidade semntica.
EXEMPLO:

GERENTE

LIDER

LIDERADO

PROJETO

OBS: A maioria das ferramentas CASE no utilizam o PAPEL como

alternativa para a construo de MER.

63

9. SENTENAS (REGRAS DO NEGCIO)

Duas sentenas so derivadas da leitura do relacionamento. Elas
refletem as regras do negcio e ajudam na validao do modelo junto ao
usurio.
Exemplo:

CLIENTE

TITULAR

CONTA_CORRENTE

_ Sentena-1:
UM CLIENTE titular de VRIAS CONTAS-CORRENTES.
CARDINALIDADE

_ Sentena-2:
UMA CONTA-CORRENTE tem como titular UM CLIENTE.
CARDINALIDADE 1

OBS: As sentenas sempre comeam com UM / UMA e a cardinalidade

considerada a do lado oposto ao da primeira entidade citada na
sentena.

64

10. INTEGRIDADE REFERENCIAL (IR)

A Integridade Referencial notada no MER atravs de sinalizao
colocada no relacionamento junto marca de carnalidade, que indica se
o relacionamento OBRIGATRIO ou OPCIONAL (TOTAL / PARCIAL).
Os sinais utilizados para notar a IR, variam muito, conforme os autores ou
ferramenta CASE adotados e se confundem com a marca de
cardinalidade.
Veja no quadro a seguir as notaes mais utilizadas para IR:
OPCIONAL

OBRIGATRIO

(bolinha aberta)
sem marcao
| (uma barra vertical)
linha do relacionamento tracejada

(bolinha fechada)
| ( uma barra vertical)
|| (duas barras verticais)
linha cheia no relacionamento

AUTOR
JAMES MARTIN
DIVERSOS
DIVERSOS
BACHMAN / GANE

Exemplo:

CLIENTE

MOVIMENT

CONTA_CORRENTE

65

11. REGRAS GERAIS

- No podem existir duas entidades iguais no mesmo modelo, ou seja,
que representem o mesmo objeto do mundo real e possuam os mesmos
atributos; mesmo que elas possuam nomes diferentes.
- Cada entidade deve possuir pelo menos dois atributos (colunas) e duas
ocorrncias (linhas).
_ No Modelo Operacional os relacionamentos devem envolver, no
mximo, duas entidades.
- Os relacionamentos Mltiplos do Modelo Conceitual devem ser
transformados em entidades em sua passagem para o modelo
operacional.
- Pode existir mais do que um relacionamento entre o mesmo par de
entidades (relacionamento duplo, triplo, etc..)
- Para cada relacionamento com cardinalidade N:N do Modelo
Conceitual, deve ser criada, no Modelo Operacional, uma ENTIDADE
ASSOCIATIVA. Essa entidade ser ligada s demais por dois
relacionamentos 1:N, sendo que as cardinalidades N de cada
relacionamento, sero marcadas ao seu lado.
- Deve-se avaliar os relacionamentos com cardinalidade 1:1, verificando
se o par de entidades envolvidas pode ser representado por uma
entidade nica.
- Cada entidade do MER deve participar de pelo menos um
relacionamento. Caso isso no ocorra provvel que a entidade isolada
no faa parte do contexto modelado.

66

12. VANTAGENS E DESVANTAGENS DO MER

Vantagens:
- Simplicidade da notao e terminologia
- Rpida absoro dos conceitos por parte dos tcnicos
- Facilidade de compreenso por parte dos usurios
- Grande possibilidade de validao do modelo por parte do usurio
- Capacidade de representar diversos nveis de abstrao
- Compreenso mais objetiva, mais formal e portanto menos ambgua da
do problema.

Desvantagens do MER:
- Diversidade da notao e terminologia
- Nenhuma nfase aos processos que manipulam as informaes.

67

CAPITULO X
TIPOS ESPECIAIS DE RELACIONAMENTO
Os casos apresentados a seguir representam situaes especiais que ocorrem
esporadicamente. Geralmente os relacionamentos do MER so do tipo 1:N entre um
par de entidades.
1. AUTO-RELACIONAMENTO
O auto-relacionamento representa a relao entre linhas de uma mesma
tabela. tambm conhecido como RECURSIVIDADE.
Exemplos:

FUNCIONRIO

GERENCIA

UM funcionrio gerencia N funcionrios

UM funcionrio gerenciado por 1 funcionrio

PEA

COMPE

UMA pea compe N peas

UMA pea componente de N peas

68

2. MAIS DE UM RELACIONAMENTO (duplo, triplo, etc.)

Ocasionalmente pode ser necessrio representar mais de um
relacionamento entre o mesmo par de entidades. Esses relacionamentos
sero vlidos desde que denotem situaes distintas e independentes.
Neste caso, existiro no Modelo Operacional, tantas chaves estrangeiras
quantos forem os relacionamentos.
LOTA

SETOR

FUNCIONRIO
CHEFIA

69

3. RELACIONAMENTO MLTIPLO
O Relacionamento Mltiplo, previsto por PETER CHEN, aquele que
relaciona mais do que duas entidades. Este tipo de relacionamento
somente ocorre em Modelos Conceituais e geralmente denota eventos.
Para implementa-lo nos SGBD-R necessrio criar uma entidade, em
procedimento anlogo ao que adotado nos casos de relacionamento
N:N.
Exemplo:

VENDEDOR

VENDE

PRODUTO

CLIENTE

70

CAPITULO XI
EXTENSES AO MER
EXTENSES AO MER so conceitos e simbologias criados por diversos
autores que escrevem sobre o Modelo de Entidades, para representar
situaes especficas, no cobertas pela proposta original de PETER
CHEN. As extenses possibilitam ao modelador tornar o modelo mais
genrico (conceitual) ou mais especfico (operacional), conforme a
necessidade. Neste captulo destacamos algumas extenses as quais
julgamos importantes para a abordagem metodolgica que adotamos
neste texto.
As extenses que abordaremos so as seguintes:
_ Generalizao (Setzer e outros) ou Supertipo (Gane)
_ Especializao (Setzer e Outros), Subtipo (Gane), particionamento ou
classificao (outros).
_ Agregao (Setzer)

71

1. GENERALIZAO
o resultado da unio de dois ou mais conjuntos de entidades afins, de
mais baixo nvel de abstrao, produzindo uma entidade mais genrica.
Portanto, a generalizao parte de entidades ESPECFICAS para criar
uma GENRICA.
O exemplo a seguir apresenta dois tipos de conta (corrente e poupana).
No Modelo Conceitual elas apresentam-se como entidades
independentes. Verificado que elas possuem atributos em comum, criouse no Modelo Operacional a entidade genrica CONTA, que contm os
atributos comuns aos dois tipos de conta, alm de um atributo TIPO
para diferenci-las. Essa soluo pode simplificar o processo de
atualizao e facilitar determinadas consultas que manipulem
informaes gerais sobre os dois tipos de conta.
Exemplo:
MODELO CONCEITUAL

MODELO OPERACIONAL

CLIENTE

CONTA_CORRENTE

CLIENTE

POUPANA

GENERALIZAO

CONTA

TIPO

ENTIDADES ESPECFICAS
CONTA_CORRENTE

POUPANA

72

2. ESPECIALIZAO
o resultado da diviso de uma entidade genrica, em subconjuntos de
entidades, que contenham atributos especficos de determinadas
categorias de entidades. Portanto, a Especializao parte de uma
entidade GENRICA para criar ESPECFICAS.
Exemplo:
MODELO OPERACIONAL

MODELO CONCEITUAL
CLIENTE

CLIENTE

CONTA

CONTA

ENTIDADE GENRICA
TIPO

ESPECIALIZAO

CONTA_CORRENTE

POUPANA

73

3. AGREGAO
Na abordagem top-down (do geral para o especfico) comum
representar-se no Modelo Conceitual apenas as entidades mais
importantes para a elucidao 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 AGREGAO um recurso do Modelo Conceitual, que
representa atravs de uma nica entidade no-normalizada, um
conjunto de entidades e relacionamentos do nvel Operacional.
A Agregao permite visualizar um modelo complexo, com muitas
entidades, de uma maneira mais genrica. Com isso, obtm-se uma
melhor viso do contexto, com destaque para as entidades e
relacionamentos mais importantes e omisso dos detalhes irrelevantes.

MODELO CONCEITUAL

MODELO OPERACIONAL

CLIENTE

CLIENTE

NOTA-FISCAL

NOTA-FISCAL

ENTIDADES
AGREGADAS
NORMALIZAO
AGREGAO

ITENS-NOTA

PRODUTO

74

4. VARIAO DO CONCEITO DE AGREGAO

Alguns autores no admitem o relacionamento mltiplo e utilizam a
Agregao para representar o relacionamento de uma entidade com um
par de entidades, conforme mostrado no grfico a seguir. Neste texto
no adotaremos essa linha de pensamento.
Exemplo:
CLIENTE

COMPRA

VENDEDOR

PRODUTO

75

CAPTULO XII
NORMALIZAO
A NORMALIZAO uma tcnica de modelagem de dados, criada por E. F.
CODD, nos laboratrios de pesquisa da IBM, lanada junto com as bases do
modelo Relacional de SGBD. Essa tcnica de modelagem nos proporciona
critrios objetivos, para determinarmos quando uma relao (tabela / estrutura de
dados) apresenta problemas no tocante observncia de princpios do enfoque
relacional, tais como:
- Tabela bidimensional (valores atmicos)
- Regras de integridade
- Mnima redundncia
- Nenhuma inconsistncia
- Inexistncia de anomalias de atualizao (incluso, alterao e excluso)
O processo de NORMALIZAO proposto por CODD, deu origem a trs
FORMAS NORMAIS:
_ PRIMEIRA FORMA NORMAL - 1FN;
_ SEGUNDA FORMA NORMAL 2FN e;
_ TERCEIRA 3FN.
Outras formas normais foram propostas, por diversos autores, configurando
situaes que ocorrem mais raramente, sendo a 4FN a mais significativa.
Conforme veremos mais adiante, a 1FN visa to 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 relaes em 1FN j esto NORMALIZADAS.
As demais formas normais esto dirigidas para evitar REDUNDNCIA DE
DADOS, INCONSISTNCIAS e ANOMALIAS DE ATUALIZAO.
Redundncia de dados um fato gerador de inconsistncias, j as anomalias de
atualizao criam dificuldades operacionais para a manuteno do BD. Esses
aspectos reforam a importncia de aplicao da 2FN e 3FN.

76

1. ANOMALIAS DE ATUALIZAO
So problemas presentes em estruturas de dados modeladas de forma inadequada.
TABELA FUNCIONRIO

MATR NOME ENDEREO COD-ORGO SIGLA-ORG QTD-FUNC

03
05
01
02
08
06
.
.
.

JOO
JOS
VILMA
ANA
JUCA
ANA
.
.
.

SQS
SQS
GAMA
GUARA
SQN
SQN
.
.
.

01
01
05
02
02
02
.
.
.

GETAE
GETAE
GEPAC
GEPRO
GEPRO
GEPRO
.
.
.

2
2
1
3
3
3
.
.
.

Exenplos de anomalias de atualizao na tabela FUNCIONRIOS:

- A INCLUSO de um novo ORGO na tabela fica condicionada a que algum
funcionrio seja alocado nele;
- A ALTERAO de nome do rgo GERAE para GETAE provoca atualizao
em vrias tuplas, haja vista, que o mesmo pode repetir-se numerosas vezes na relao;
- A INCLUSO de um novo funcionrio para o GEORG causa ALTERAO no
atributo QT-FUNC em diversas tuplas;
- A EXCLUSO da funcionria VILMA da tabela ocasiona perda de informaes
sobre o GEPAC;

77

2. TERMINOLOGIA
O vocabulrio de NORMALIZAO se confunde com o empregado nos
SGBD do modelo RELACIONAL. Isso ocorre por que a tcnica de
normalizao uma das bases desse modelo. Os termos abaixo so relevantes
para o entendimento das trs formas normais.
a. CLULA
Interseo (LINHA X COLUNA) de uma relao.
b. ITEM REPETITIVO (VALOR NO-ATMICO ou ATRIBUTO NOSIMPLES).
Ocorre quando uma clula 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 aplicao das operaes relacionais,
com SQL (Structured Query Language).
c. VALOR ATMICO (ATRIBUTO SIMPLES)
Caracterizado quando uma clula possui apenas um valor de atributo. Esta a
situao adequada no modelo Relacional.
d. CHAVE PRIMRIA
CHAVE PRIMRIA, PRIMARY KEY (PK) ou simplesmente CHAVE o
atributo ou combinao de atributos que permite a IDENTIFICAO NICA
de cada tupla na relao. A PK no admite duplicata e nem valor nulo.
Ex: Se pesquisarmos uma relao de FUNCIONRIOS, de PK =
MATRICULA, utilizando a matricula como chave de acesso, deveremos obter
uma nica tupla como resultado da pesquisa.

78

A chave primria pode ser simples ou composta:

- SIMPLES: Constituda de apenas um atributo
Exemplo:
COD-PRODUTO ==> NOME-PROD
NUM-CONTA ==> NOME-CLI, DT-NASC, SALDO
- COMPOSTA: formada pela concatenao de dois ou mais atributos.
Exemplo:
COD-PROD + COD-FORNECEDOR ==> PREO-PROD
MATR-ALUNO + MATR-PROF + DATA-PROVA ==> NOTA-PROVA
NUM-CONTA + TIPO-APLICAO + DATA ==> SALDO-APLIC

e. DEPENDNCIA FUNCIONAL
a correspondncia (identificao unvoca) existente entre dois atributos de
uma mesma relao. pode ser de trs tipos: COMPLETA, PARCIAL e
TRANSITIVA
f. DEPENDNCIA FUNCIONAL COMPLETA (DFC)
Relao de identificao unvoca entre o ATRIBUTO-CHAVE e os demais
atributos da relao.
Ex: COD-CLIENTE ==> NOME-CLIENTE, ENDEREO;
COD-CLIENTE + NUM-PRESTAO ==> DT-VENCIMENTO, VALOR;

79

g. DEPENDNCIA FUNCIONAL PARCIAL (DFP)

Relao de identificao unvoca entre parte da CHAVE PRIMRIA (PK
composta por dois ou mais atributos) e algum dos demais atributos da relao.
Ex: COD-PRODUTO + COD-FORNECEDOR ==> NOME-PROD, PREO
COD-PRODUTO identifica univocamente o NOME-PROD e um
componente da chave primria.
Obs.: Para que ocorra dependncia parcial necessrio chave primria
composta. Por outro lado, nem sempre que ocorre PK composta haver
dependncia parcial.
h. DEPENDNCIA FUNCIONAL TRANSITIVA (DFT)
Relao de identificao unvoca entre atributos que no fazem parte da chave
primria da relao.
Ex: PK-MATR ==> NOME, DT-NASC, COD-SETOR, NOME-SETOR
COD-SETOR identifica univocamente o NOME-SETOR e no faz parte da
chave.

80

3. NOTAO PARA AS ESTRUTURAS DE DADOS

Existem diversas notaes, segundo as quais, podemos representar genericamente
uma relao. Neste trabalho iremos adotar, principalmente, a notao empregada
por CHRIS GANE para a descrio de depsitos de dados e, opcionalmente, a
notao de YORDON/DE MARCO.
TABELA VENDA:
NUM-NF

NOME-CLI

END-CLI

DT-VENDA

001

Antnio

SQS

22/08

02
03
.
.
.

Juliana
Cludia
.
.
.

SQN
SQS
.
.
.

10/09
20/07
.
.
.

ITENS-DE-VENDA
COD-PROD QUANT P-U
01
10
20
02
20
10
05
8
5
01
6
20
05
10
5
.
.
.
.
.
.

A representao genrica da relao VENDA, conforme a notao de GANE,

corresponde seguinte:
VENDA ==> nome da relao
# NUM-NF
NOME-CLI
END-CLI
DT-VENDA
ITENS-DE-VENDA*===========================> grupo repetitivo
# COD-PROD
QUANT
P-UNIT

81

Observaes:
- ITENS DE GRUPO so IDENTADOS, com deslocamento para a direita dando
idia de hierarquia;
- GRUPOS REPETITIVOS so sinalizados com * e/ou grafados no PLURAL.
- Os atributos componentes da CHAVE devem receber uma das seguintes
notaes:
. sublinhados, ou;
. Um # ou um C colocados esquerda dos atributos.
A representao genrica da tabela VENDA segundo a notao de YORDON/DE
MARCO :
VENDA = NUM-NF, NOME-CLI, END-CLI, DATA-VENDA, ITENS-DE-VENDA
{COD-PROD, QUANT, P-UNIT}

Observaes:
- GRUPOS REPETITIVOS so representados entre chaves;
- O ATRIBUTO-CHAVE deve ser sublinhado.
- Para relaes com grande nmero de atributos a notao de GANE mais
eficiente;

82

4. ESQUEMA DA NORMALIZAO

RELAO
NO
NORMALIZADA

Tabela com itens de grupo

Eliminar ITENS DE GRUPO

1FN

Escolher a chave primria

Eliminar DEPNDNCIA PARCIAL

2FN

Eliminar DEPENDNCIA TRANSITIVA

3FN

83

5. RELAES NO-NORMALIZADAS
Uma relao NO NORMALIZADA aquela que possui atributos do tipo NOSIMPLES (NO-ATMICOS).
Para a devida utilizao dos OPERADORES RELACIONAIS necessrio que a
relao no-normalizada seja transformada numa forma onde os atributos s
contenham VALORES ATMICOS, em outras palavras, preciso tornar a
estrutura de dados plana. Esse processo de planificao da relao concretizado
aps a sua transposio para a 1FN.
Considere a relao abaixo:
Relao: CONTA CORRENTE
CONTA-CORRENTE
CONTA
AGENCIA
NUMERO
NOME-CLIENTE
ENDEREO-CLIENTE
DEPENDENCIA
TIPO-AGENCIA
DESCRIO-TIPO-AGENCIA
ENDEREO-DEPENDENCIA
LANAMENTOS*
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANAMENTO Observaes:

- Os atributos CONTA , DEPENDNCIA e LANAMENTOS so itens de

grupo;
- O atributo LANAMENTOS um grupo repetitivo;
- Esses atributos so do tipo no-atmicos, pois suas clulas no contm valores
nicos.
- A relao CONTA-CORRENTE est na forma NO-NORMALIZADA.

84

6. PRIMEIRA FORMA NORMAL (1FN)

Uma relao est em 1FN se todos seus ATRIBUTOS so SIMPLES
(ATMICOS).
Para colocarmos uma relao em 1FN devemos PLANIFICA-LA, eliminando de
sua estrutura os atributos NO-ATMICOS (VETOR, MATRIZ e ITEM DE
GRUPO), de modo que, cada clula da tabela possua apenas um valor de atributo.
Isto porque os atributos NO-ATMICOS no podem ser implementados nos
SGBD RELACIONAIS.
A especificao abaixo, corresponde relao CONTA-CORRENTE aps o
processo de normalizao (1FN):
CONTA-CORRENTE
AGENCIA
NUMERO-CONTA
NOME-CLIENTE
ENDEREO-CLIENTE
TIPO-AGENCIA
DESCRIO-TIPO-AGENCIA
ENDEREO-DEPENDENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANAMENTO

Observaes:
- O esquema genrico passou a contar somente com ATRIBUTOS SIMPLES.
Todos os ITENS DE GRUPO foram eliminados.
- Assim como toda a relao em 1FN, a estrutura de dados acima apresenta
redundncias e anomalias de atualizao.
- CODD estabelece um outro procedimento para normalizao (1FN), que o de
decompor a relao no-normalizada em tantas relaes quantos forem os grupos
repetitivos alm de incluir uma relao para o conjunto de colunas atmicas. No
processo que descrevemos essas relaes surgem naturalmente na derivao das
formas normais seguintes (2FN e 3FN).

85

7. ESCOLHA DA CHAVE PRIMRIA

Estando a relao em 1FN, o prximo passo no esquema de normalizao a
escolha da CHAVE PRIMRIA.
CHAVE PRIMRIA Atributo (chave simples) ou combinao de atributos
(chave composta) que identifica univocamente as tuplas de uma relao.
Na escolha do ATRIBUTO-CHAVE os seguintes aspectos so relevantes:
a. No pode conter valor nulo para evitar duplicatas;
b. No pode conter duplicatas para garantir a identificao unvoca;
c. Deve ser um atributo estvel (no sujeito constantes mudanas);
Estvel: MATRICULA, CPF, NUM-CONTA-CORRENTE
No estvel: MOEDA-NACIONAL, SALDO, INDICE-ECONMICO
d. No deve dar margem ambiguidades para garantir a eficincia de acesso (dar
preferncia a cdigos numricos e o mais curtos possveis);
Obs1: atributos alfabticos podem gerar dvidas quanto grafia.
Ex: Nome de pessoa - Lus ou Luiz; Melo ou Mello
Nome de rgo - GERAD; GEDAD; GEPAD;
Obs2: Cdigos alfanumricos ou atributos muito extensos so mais propensos a
erros de digitao.
e. Os grupos repetitivos, constantes da relao no-normalizada, devem ceder
pelo menos um atributo para formar a chave composta da relao em 1FN;
f. CHAVES CANDIDATAS ocorrem quando numa relao existem vrios
atributos (ou combinaes) com potencial de CHAVE PRIMRIA. Nesse
caso, para escolher-se a CHAVE da relao, deve-se considerar os critrios
anteriormente definidos. Somente uma CHAVE PRIMRIA ser escolhida, as
demais sero chamadas CHAVES ALTERNATIVAS.

86

g. O processo de escolha de CHAVES PRIMRIAS em um BD relacional

constitui um fator crtico, que afeta a estabilidade do Banco de dados, pois, os
relacionamentos so implementados atravs da redundncia das CHAVES.
Portanto, qualquer alterao na chave repercute em todos os relacionamentos
nos quais a entidade detentora da mesma esteja envolvida (direta ou
indiretamente).
Exemplo: Consideremos a relao CONTA-CORRENTE em 1FN (ITEM 5.5):
CONTA-CORRENTE
AGENCIA
NUMERO-CONTA
NOME-CLIENTE
ENDEREO-CLIENTE
TIPO-AGENCIA
DESCRIO-TIPO-AGENCIA
ENDEREO-DEPENDENCIA
NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANAMENTO

Qual o atributo ou combinao de atributos que identificam singularmente cada

tupla da relao CONTA-CORRENTE?
R1: O atributo AGNCIA-CONTA isoladamente deve ser descartado, pois, o
cdigo de uma agncia relaciona-se com diversos nmeros de conta;
R2: O NUMERO-CONTA isoladamente no adequado, haja vista, que podem
existir duas contas com o mesmo nmero em agncias diferentes;
R3: A combinao AGNCIA + NUMERO-CONTA ainda no satisfatria,
porque podem existir diversos lanamentos (NUM-DOC, DATA, VALOR)
para cada conta vinculada a uma agncia;
R4: Como LANAMENTOS um grupo repetitivo na forma NONORMALIZADA da relao CONTA-CORRENTE, naturalmente, ele deve
ceder um atributo para compor a chave primria. Assim, a CHAVE dessa
relao COMPOSTA pela concatenao dos atributos:
- AGNCIA + NUMERO-CONTA + NUM-DOC
R5: Se considerssemos possvel dois documentos, com o mesmo nmero, em sua
mesma conta, deveramos buscar um outro arranjo para a chave-primria.

87

8. SEGUNDA FORMA NORMAL (2FN)

Uma relao est em 2FN se:
- est em 1FN;
- no contm atributos que dependam funcionalmente de subconjuntos da CHAVE
PRIMRIA COMPOSTA, em outras palavras, no contm DEPENDNCIA
FUNCIONAL PARCIAL (DFP).
Para passarmos uma relao da 1FN para a 2FN devemos ELIMINAR as
DEPENDNCIAS PARCIAIS. Para tanto, utilizamos o conceito de PROJEO,
gerando novas tabelas contendo as colunas que se encontram em DFP com a chave
primria. A aplicao da 2FN sobre a relao CONTA-CORRENTE resulta na
criao das seguintes tabelas:
CONTA
# NUMERO-CONTA
NOME-CLIENTE
ENDEREO-CLIENTE
AGENCIA
# NUM-AGENCIA
TIPO-AGENCIA
DESCRIO-TIPO-AGENCIA
ENDEREO-DEPENDENCIA
LANAMENTOS
# AGENCIA
# NUMERO-CONTA
# NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANAMENTO

88

9. TERCEIRA FORMA NORMAL (3FN)

Uma relao est em 3FN se:
- Est em 1FN;
- Est em 2FN;
- No possui DEPENDNCIA FUNCIONAL TRANSITIVA (DFT).
Para passarmos uma relao da 2FN para a 3FN devemos ELIMINAR as
DEPENDNCIAS TRANSITIVAS utilizando a operao de PROJEO. Assim,
so geradas novas tabelas correspondentes s DFT identificadas. Ao decompormos a tabela CONTA-CORRENTE, gerando as relaes em 2FN, restou apenas
uma DFT, que encontra-se na relao DEPENDNCIA. Fazendo a
PROJEO dessa relao para eliminar a DFT obtemos as relaes abaixo:
AGENCIA
# NUM-AGENCIA
TIPO-AGENCIA
ENDEREO-DEPENDENCIA
TIPO-AGENCIA
# TIPO-AGENCIA
DESCRIO-TIPO-AGENCIA
CONTA
# NUMERO-CONTA
NOME-CLIENTE
ENDEREO-CLIENTE
LANAMENTOS
# AGENCIA
# NUMERO-CONTA
# NUM-DOCUMENTO
DATA-DOCUMENTO
VALOR-LANAMENTO

89

Observaes:
- A chave da relao TIPO-AGNCIA permaneceu na relao principal como
CHAVE ESTRANGEIRA, possibilitando o relacionamento entre as duas tabelas.
- As relaes CONTA e LANAMENTO j se encontram em 3FN, porque
no contm DFT.
- Com a aplicao da 3FN, TODAS as DEPENDNCIAS FUNCIONAIS restantes
nas relaes so do tipo COMPLETAS.

90

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 DAODS - TPICOS AVANADOS - CAMPUS
4. SETZER, VALDEMAR W.
BANCO DE DADOS
5. ACCIO FELICIANO NETO
ENGENHARIA DA INFORMAO - MAC GRAW
6. GANE, CHRIS
ANLISE ESTRUTURADA DE SISTEMAS - LTC
7. GANE, CHRIS
DESENVOLVIMENTO RPIDO DE SISTEMAS - LTC
8. YORDON, EDWARD
ANLISE ESTRUTURADA MODERNA - CAMPUS
9. CHEN, PETER
MODELO ENTIDADE x RELACIONAMENTOS

91