Curso Bacharelado em Sistemas de Informao Granbery / J.

FORA

BD I
Banco de Dados I
Prof. Carlos Alberto Ribeiro Granbery/ JFORA Verso 2011/2.0

BANCOS DE DADOS .................................................................................................................................................................4 1.1. BANCO DE DADOS (BD) .....................................................................................................................................................4 1.2. SISTEMA GERNCIADOR DE BANCO DE DADOS (SGBD) ....................................................................................................4 1.2.1. Processamento de Dados sem Banco de Dados......................................................................................................5 1.2.2. Processamento de dados com uso de SGBD ...........................................................................................................5 1.2.3. Principais Componentes de um SGBD....................................................................................................................6 1.2.4. Funes de um SGBD .............................................................................................................................................6 1.3. FLUXO OPERACIONAL DE DADOS E CONTROLE ..................................................................................................................8 1.4. ABSTRAO DE DADOS ....................................................................................................................................................10 1.5. MODELOS DE BANCOS DE DADOS ....................................................................................................................................11 1.6. INDEPENDNCIA DE DADOS ...........................................................................................................................................11 1.7. FUNES RELACIONADAS AO SGBD................................................................................................................................12 1.7.1. Administrador de Dados .......................................................................................................................................12 1.7.2. Administrador de Banco de Dados .......................................................................................................................12 1.8. ARQUITETURAS PARA USO DO SGBD ...............................................................................................................................13 1.8.1. Mono-usurio........................................................................................................................................................13 1.8.2. Multi-Usurio com Processamento Central..........................................................................................................13 1.8.3. Arquitetura Cliente/Servidor.................................................................................................................................13 1.9. FASES DO PROJETO DE BD ...............................................................................................................................................14 1.9.1. Construir o Modelo Conceitual ...........................................................................................................................14 1.9.2. Construir o Modelo Lgico ...................................................................................................................................14 1.9.3. Construir o Modelo Fsico ....................................................................................................................................14 1.9.4. Avaliar o Modelo Fsico .......................................................................................................................................14 1.9.5. Implementar o BD.................................................................................................................................................14 2. MODELAGEM DE DADOS .................................................................................................................................................15 2.1. CONCEITOS .......................................................................................................................................................................15 2.2. REQUISITOS PARA MODELAGEM DE DADOS .....................................................................................................................15 2.3. MODELOS CONCEITUAIS ..................................................................................................................................................15 2.4. MODELOS LGICOS ..........................................................................................................................................................16 2.4.1. Modelo Relacional ................................................................................................................................................16 2.4.2. Modelo de Rede.....................................................................................................................................................17 2.4.3. Modelo Hierrquico..............................................................................................................................................18 2.5. MODELO DE DADOS FSICO ..............................................................................................................................................19 3. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)..................................................................................................19 3.1. INTRODUO ....................................................................................................................................................................19 3.2. ENTIDADE ........................................................................................................................................................................19 3.3. RELACIONAMENTO ...........................................................................................................................................................20 3.3.1. Auto-relacionamento.............................................................................................................................................21 3.3.2. Cardinalidade de Relacionamentos ......................................................................................................................21 3.3.3. Cardinalidade Mxima .........................................................................................................................................22 3.3.4. Classificao de Relacionamentos Binrios .........................................................................................................23 3.3.5. Relacionamento ternrio.......................................................................................................................................26 3.3.6. Cardinalidade mnima ..........................................................................................................................................26 3.4. NOTAES ALTERNATIVAS ..............................................................................................................................................27 3.5. ATRIBUTO ........................................................................................................................................................................28 3.5.1. Domnio.................................................................................................................................................................28 3.5.2. Tipos de Atributos .................................................................................................................................................28 3.5.3. Atributo de Relacionamento .................................................................................................................................29 3.5.4. Identificador de Entidades ....................................................................................................................................29 3.5.5. Relacionamento Identificador (Entidade Fraca) ..................................................................................................30 3.5.6. Identificador de Relacionamentos.........................................................................................................................30 3.6. GENERALIZAO/ESPECIALIZAO .................................................................................................................................31 3.7. ENTIDADE ASSOCIATIVA (AGREGAO) ..........................................................................................................................33 4. O MODELO RELACIONAL ................................................................................................................................................35 4.1. CARACTERSTICAS DAS TABELAS - MODELO RELACIONAL .............................................................................................36 4.2. CONCEITOS BSICOS ........................................................................................................................................................38 4.2.1. Chave primria : (primary key) ............................................................................................................................38 4.2.2. Chave estrangeira : (foreign key) .........................................................................................................................38

4.2.3. Chave candidata ou alternativa ............................................................................................................................38 4.3. NORMALIZAO ...............................................................................................................................................................39 4.3.1. Ilustrao de um Sistema a ser Normalizado.......................................................................................................40 4.3.2. Anlise de Dependncia Funcional.......................................................................................................................43 4.3.3. Formas Normais: ..................................................................................................................................................47 4.3.4. Roteiro Prtico para Normalizao: ....................................................................................................................47 4.3.5. Exemplo de Normalizao: ...................................................................................................................................49 4.4. TRANSPOSIO D.E.R PARA D.T.R (DIAGRAMA DE TABELAS RELACIONAIS) ................................................................53 4.4.1. Simbologia adotada no modelo relacional ...........................................................................................................53 4.4.2. Anlise da Entidade no D.E.R...............................................................................................................................54 4.4.3. Anlise de Relacionamento ...................................................................................................................................54 4.5. RESTRIES DE INTEGRIDADE NO MODELO RELACIONAL .................................................................................................61 4.5.1. Integridade Lgica ................................................................................................................................................61 4.5.2. Integridade Fsica .................................................................................................................................................61 4.6. LINGUAGENS RELACIONAIS ....................................................................................................................................64 4.6.1. lgebra Relacional ...............................................................................................................................................65 4.6.2. Exemplos de lgebra Relacional ..........................................................................................................................72 5. EXERCCIOS:.......................................................................................................................................................................75 5.1. EXERCCIOS DE MODELAGEM DE DADOS .........................................................................................................................75 5.2. EXERCCIOS DE NORMALIZAO: ....................................................................................................................................78 5.3. EXERCCIOS DE LGEBRA RELACIONAL ..........................................................................................................................81 6. BIBLIOGRAFIA ..................................................................................................................................................................82

BANCOS DE DADOS
1.1. BANCO DE DADOS (BD) Um Banco de Dados (BD) pode ser definido como uma coleo de dados interrelacionados, armazenados de forma centralizada ou distribuda, com redundncia controlada, para servir a uma ou mais aplicaes. 1.2. SISTEMA GERNCIADOR DE BANCO DE DADOS (SGBD) Conjunto de software para gerenciar (definir, criar, modificar, usar) um BD e garantir a integridade e segurana dos dados. O SGBD a interface entre os programas de aplicao e o BD. Em ingls denominado DataBase Management System (DBMS). Sistema de BD

1.2.1.

PROCESSAMENTO DE DADOS SEM BANCO DE DADOS

Dados de diferentes aplicaes no esto integrados, pois so projetados para atender a uma aplicao especfica.

Problemas da falta de integrao de dados: O mesmo objeto da realidade mltiplas vezes representado na base de dados. Exemplo: dados de um produto em uma indstria. Redundncia no controlada de dados: No h gerncia automtica da redundncia, o que leva a inconsistncia dos dados devido a redigitao de informaes Dificuldade de extrao de informaes: os dados so projetados para atender aplicaes especificas gerando dificuldades para o cruzamento de informaes Dados pouco confiveis e de baixa disponibilidade 1.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD Os dados usados por uma comunidade de usurios so integrados no Banco de Dados. Cada informao armazenada uma nica vez, sendo que as eventuais redundncias so controladas pelo sistema em computador, ficando transparentes para os usurios.

1.2.3.

PRINCIPAIS COMPONENTES DE UM SGBD

Dicionrio de dados (Data Dictionary): Descreve os dados e suas relaes em forma conceitual e independente de seu envolvimento nas diversas aplicaes. Fornece referncias cruzadas entre os dados e as aplicaes. Linguagem de definio de dados (DDL - Data Definition Language): Descreve os dados que esto armazenados no BD. As descries dos dados so guardadas em um meta banco de dados. Linguagem de acesso (DML - Data Manipulation Language): Usada para escrever as instrues que trabalham sobre a base de dados, permitindo o acesso e atualizao dos dados pelos programas de aplicao. Linguagem de consulta (QUERY): Permite que o usurio final, com poucos conhecimentos tcnicos, possa obter de forma simples, informaes do BD. Utilitrios administrativos: Programas auxiliares para carregar, reorganizar, adicionar, modificar a descrio do BD, obter cpias de reserva e recuperar a integridade fsica em caso de acidentes. 1.2.4. FUNES DE UM SGBD Um princpio bsico em BD determina que cada item de dado deveria ser capturado apenas uma vez e ento armazenado, de modo que possa tornar disponvel para atender a qualquer necessidade de acesso qualquer momento.

Alguns pontos importantes so: Independncia dos dados: O SGBD deve oferecer isolamento das aplicaes em relao aos dados. Esta caracterstica permite modificar o modelo de dados do BD sem necessidade de reescrever ou recompilar todos os programas que esto prontos. As definies dos dados e os relacionamentos entre os dados so separados dos cdigos dos programas. Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturas de dados complexas, os arquivos devem ser projetados para atender a diferentes necessidades, permitindo desenvolver aplicaes melhores, mais seguras e mais rapidamente. Deve possui comandos poderosos em sua linguagem de acesso. Integridade dos dados: O SGBD deve garantir a integridade dos dados, atravs da implementao de restries adequadas. Isto significa que os dados devem ser precisos e vlidos. Redundncia dos dados: O SGBD deve manter a redundncia de dados sob controle, ou seja, ainda que existam diversas representaes do mesmo dado, do ponto de vista do usurio como se existisse uma nica representao. Segurana e privacidade dos dados: O SGBD deve assegurar que estes s podero ser acessados ou modificados por usurios autorizados. Rpida recuperao aps falha: Os dados so de importncia vital e no podem ser perdidos. Assim, o SGBD deve implementar sistemas de tolerncia a falhas, tais como estrutura automtica de recover e uso do conceito de transao. Uso compartilhado: O BD pode ser acessado concorrentemente por mltiplos usurios. Controle do espao de armazenamento: O SGBD deve manter controle das reas de disco ocupadas, evitando a ocorrncia de falhas por falta de espao de armazenamento. 7

1.3. FLUXO OPERACIONAL DE DADOS E CONTROLE

PROGRAMA DE APLICACAO AREA LOCAL DO PROGRAMA

10 S.G.B.D 5
AREA DE ENTRADA/SAIDA

2 4

SISTEMA OPERACIONAL

ESQUEMAS, DICIONARIO DE DADOS, DIRETORIOS

BASE DADOS

FLUXO DE DADOS FLUXO DE CONTROLE

1 - O programa do usurio comunica-se com o SGBD utilizando DML pedindo a leitura de um registro lgico. 2 - O SGBD emite um comando para o S.O. para leitura dos esquemas (META DADOS). 3 - O S.O. acessa os esquemas. 4 - Os Meta-dados so transferidos para rea de E/S do SGBD. 5 - O SGBD consulta os Meta-dados para saber como traduzir o comando do usurio. 6 - O SGBD emite os comandos para que o S.O. leia os registros fsicos necessrios. 7 - O S.O. acessa a base de dados. 8 - Os registros fsicos so transferidos para rea de E/S do SGBD. 9 - O SGBD seleciona os dados necessrios para formar o(s) registro(s) lgico(s) pedidos pelo usurio, se necessrio faz a transformao, e coloca o registro lgico na rea do usurio/aplicao. 10 - O SGBD envia ao programa de aplicao um cdigo indicando fim de comando.

1.4. ABSTRAO DE DADOS Um propsito central de um SGBD proporcionar aos usurios uma viso abstrata dos dados, isto , o sistema esconde certos detalhes de como os dados so armazenados ou mantidos. No entanto, os dados precisam ser recuperados eficientemente. A preocupao com a eficincia leva a concepo de estruturas de dados complexas para representao dos dados no BD. Porm, uma vez que SGBD so freqentemente usados por pessoas sem treinamento na rea de computao, esta complexidade precisa ser escondida dos usurios. Isto conseguido definindo-se diversos nveis de abstrao pelos quais o BD pode ser visto: NVEL FSICO: o nvel mais baixo de abstrao, no qual se descreve como os dados so armazenados. Estruturas complexas, de baixo nvel, so descritas em detalhe. NVEL CONCEITUAL: o nvel que descreve quais os dados so realmente armazenados no BD e quais os relacionamentos existentes entre eles. Este nvel descreve o BD como um pequeno nmero de estruturas relativamente simples. Muito embora a implementao de estruturas simples no nvel conceitual possa envolver estruturas complexas no nvel fsico, o usurio do nvel conceitual no precisa saber disto. NVEL VISO: Este o nvel mais alto de abstrao, no qual se expe apenas parte do BD. Na maioria das vezes os usurios no esto preocupados com todas as informaes do BD e sim com apenas parte delas (Vises dos Usurios)

10

1.5. MODELOS DE BANCOS DE DADOS Um modelo de (banco de) dados uma descrio dos tipos de informaes que esto armazenadas em um banco de dados, ou seja, a descrio formal da estrutura de BD. Estes modelos podem ser escritos em linguagens textuais ou linguagens grficas. Cada apresentao do modelo denominado esquema de banco de dados. Se tomarmos como exemplo uma indstria, o modelo de dados deve mostrar que so armazenadas informaes sobre produtos, tais como cdigo, descrio e preo. Porm o modelo de dados no vai informar quais produtos esto armazenados no Banco de Dados. No projeto de um banco de dados, geralmente so considerados 3 modelos: conceitual, lgico e fsico. Modelo conceitual: uma descrio mais abstrata da base de dados. No contm detalhes de implementao e independente do tipo de SGBD usado. o ponto de partida para o projeto da base de dados. Modelo Lgico: a descrio da base de dados conforme vista pelos usurio do SGBD (programadores e aplicaes). dependente do tipo de SGBD escolhido, mas no contm detalhes da implementao (uma vez que o SGBD oferece abstrao e independncia de dados). Modelo fsico (interno): Descrio de como a base de dados armazenada internamente. Geralmente s alterada para ajuste de desempenho. A tendncia dos produtos modernos ocultar cada vez mais os detalhes fsicos de implementao. 1.6. INDEPENDNCIA DE DADOS Independncia de dados a nvel fsico: a capacidade de se modificar o modelo fsico, sem precisar reescrever os programas de aplicao. Ex: reorganizao fsica de arquivos, criao de ndices adicionais Independncia dados a nvel lgico: a capacidade de se modificar o esquema lgico, sem a necessidade de reescrever os programas de aplicao. Modificaes no nvel lgico so necessrias sempre que a estrutura lgica do BD for alterada. Em alguns casos a recompilao pode ser requerida. Ex: Acrescentar um campo a um registro, mudar o tipo de dados de um registro 11

1.7. FUNES RELACIONADAS AO SGBD 1.7.1. ADMINISTRADOR DE DADOS

Gerenciar o dado como um recurso da empresa. Planejar, desenvolver e divulgar as bases de dados da empresa. Permitir a descentralizao dos processos, mas manter centralizado os dados. Permitir fcil e rpido acesso as informaes a partir dos dados armazenados O grande objetivo de administrador de dados permitir que vrios usurios compartilhem os mesmos dados. Deste modo, os dados no pertencem a nenhum sistema ou usurio de forma especfica, e sim, organizao como um todo. Assim, o administrador de dados se preocupa basicamente com a organizao dos dados e no com o seu armazenamento.

1.7.2.

ADMINISTRADOR DE BANCO DE DADOS

O DBA (DataBase Administrator) pessoa ou grupo de pessoas responsvel pelo controle do SGBD. So tarefas do DBA: Responsabilidade pelos modelos lgico e fsico (definindo a estrutura de armazenamento) do BD Coordenar o acesso ao SGBD (usurios e senhas) Definir a estratgia de backup Melhorar o desempenho do SGBD Manter o dicionrio de dados

12

1.8. ARQUITETURAS PARA USO DO SGBD 1.8.1. MONO-USURIO

BD est no mesmo computador que as aplicaes No h mltiplos usurios Recuperao geralmente atravs de backup Tpico de computadores pessoais 1.8.2. MULTI-USURIO COM PROCESSAMENTO CENTRAL

BD est no mesmo computador que as aplicaes Mltiplos usurios acessando atravs de terminais Tpico de ambientes com mainframe 1.8.3. ARQUITETURA CLIENTE/SERVIDOR

Multi-usurio Servidor dedicado ao Banco de Dados, executando o SGBD As estaes clientes executam apenas as aplicaes Trfego na rede menor Arquitetura atualmente em uso

13

1.9. FASES DO PROJETO DE BD 1.9.1. CONSTRUIR O MODELO CONCEITUAL

Modelo de alto nvel, independente da implementao Etapa de levantamento de dados Uso de uma tcnica de modelagem de dados Abstrao do ambiente de hardware/software 1.9.2. CONSTRUIR O MODELO LGICO

Modelo implementvel, dependente do tipo de SGBD a ser usado Considera as necessidades de processamento Considera as caractersticas e restries do tipo de SGBD Etapa de normalizao dos dados 1.9.3. CONSTRUIR O MODELO FSICO

Modelo implementvel, com mtodos de acesso e estrutura fsica Considera necessidades de desempenho Considera as caractersticas e restries do SGBD Dependente das caractersticas de hardware/software 1.9.4. AVALIAR O MODELO FSICO

Avaliar o desempenho das aplicaes Avaliar os caminhos de acesso aos dados e estruturas utilizadas 1.9.5. IMPLEMENTAR O BD

Etapa de carga (load) dos dados Gerar as interfaces com outras aplicaes

14

2.

MODELAGEM DE DADOS
2.1. CONCEITOS

Abstrao: processo mental atravs do qual selecionamos determinadas propriedades ou caractersticas dos objetos e exclumos outras, consideradas menos relevantes para o problema que esta sendo analisado. Modelo: uma abstrao, uma representao simplificada, de uma parcela do mundo real, composta por objetos reais. Modelagem: atividade atravs da qual se cria um modelo. Modelo de dados: Um modelo de dados uma descrio das informaes que devem ser armazenadas em um banco de dados, ou seja, a descrio formal da estrutura de BD (descrio dos dados, dos relacionamentos entre os dados, da semntica e das restries impostas aos dados). 2.2. REQUISITOS PARA MODELAGEM DE DADOS Entender a realidade em questo, identificando os objetos que compe a parte da realidade que vai ser modelada.. Representar formalmente a realidade analisada, construindo um modelo de dados. Estruturar o modelo obtido e adequ-lo ao SGBD a ser usado, transformando o modelo conceitual em modelo lgico. 2.3. MODELOS CONCEITUAIS So usados para descrio de dados no nvel conceitual. Proporcionam grande capacidade de estruturao e permitem a especificao de restries de dados de forma explcita. Exemplos: Modelo Entidade-Relacionamento (M.E.R.) Modelo de Semntica de dados Modelo Orientado a objeto

15

2.4. MODELOS LGICOS So usados na descrio dos dados no nvel lgico. Em contraste com modelos conceituais, esses modelos so usados para especificar tanto a estrutura lgica global do BD como uma descrio em alto nvel da implementao. 2.4.1. MODELO RELACIONAL

Um BD relacional possui apenas um tipo de construo, a tabela. Uma tabela composta por linhas (tuplas) e colunas (atributos). Os relacionamentos entre os dados tambm so representados ou por tabelas, ou atravs da reproduo dos valores de atributos. Idias bsicas Edgar Frank Codd , laboratrio pesquisas da IBM em 1970 Exemplo : Considere o BD composto de clientes e contas. NOME Jos Juca Juca Carlos Carlos RUA Rua A Rua B Rua B Rua C Rua C CIDADE JF RJ RJ SP SP N CONTA 40 30 38 * 45 38 *

N CONTA 40 30 38 45

SALDO 1.000,00 2.000,00 2.500,00 3500,00

* compartilham a mesma conta, devem ser scios 16

2.4.2.

MODELO DE REDE

O BD em rede um grafo, onde os ns representam os registros e os arcos representam os relacionamentos entre os registros, atravs de ligaes pai-filho. Diferente do modelo hierrquico, um registro pode possuir diversos registros pai. Origem na linguagem de programao Cobol, Primeiro SGBD comercial IDS (Integrated Data Store) projetado para a General Eletric em 1967.. Extenso : DBTG-CODASYL(Data Base Task Group Conference on Data Systems and Languages) , 1 especificao padro de BD em 1971. Exemplos : TOTAL, IDMS, ADABAS

JOSE

RUA A

JF

40

1.000,00

JUCA

RUA B

RJ

30

2.000,00

CARLOS

RUA C

SP

38

2.500,00

45

3.500,00

17

2.4.3.

MODELO HIERRQUICO

Um BD hierrquico uma coleo de rvores de registros. Os registros so usados para representar os dados e ponteiros so usados para representar o relacionamento entre os dados, numa ligao do tipo pai-filho. A restrio que um determinado registro somente pode possuir um registro pai, relao 1/N. O acesso s pode ocorrer a partir da raiz. Exemplo : 1 SGBD bem sucedido da IBM IMS (Information Management System) em 1966 , DMS2 SGBD da Unisys.

JOS RUA A JF

JUCA RUA B RJ

CARLOS RUA C SP

40 1.000,00

30 2.000,00

38 2.500,00

38 2.500,00

45 3.500,00

18

2.5. MODELO DE DADOS FSICO Usados para descrever os dados em seu nvel mais baixo. Capturam os aspectos de implementao do SGBD.

3.

MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)

3.1. INTRODUO

Apresentado por Peter Chen, em 1976 a tcnica mais difundida para construir modelos conceituais de bases de dados o padro para modelagem conceitual, tendo sofrido diversas extenses Est baseado na percepo de uma realidade constituda por um grupo bsico de objetos chamados ENTIDADES e por RELACIONAMENTOS entre estas entidades Seu objetivo definir um modelo de alto nvel independente de implementao O modelo representado graficamente por um Diagrama de EntidadeRelacionamento (DER), que simples e fcil de ser entendido por usurios no tcnicos Conceitos centrais do MER: entidade, relacionamento, atributo, generalizao/especializao, agregao (entidade associativa) 3.2. ENTIDADE Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informaes no Banco de Dados Uma entidade pode representar objetos concretos da realidade (pessoas, automveis, material, nota fiscal) quanto objetos abstratos (departamentos, disciplinas, cidades) A entidade se refere a um conjunto de objetos; para se referir a um objeto em particular usado o termo instncia (ou ocorrncia) No DER, uma entidade representada atravs de um retngulo que contm o nome da entidade PESSOA
DEPARTAMENTO

19

3.3. RELACIONAMENTO toda associao entre entidades, sobre a qual deseja-se manter informaes no Banco de Dados. Os relacionamentos representam fatos ou situaes da realidade, onde as entidades interagem de alguma forma Um dado por si s no faz uma informao, pois no tem sentido prprio; necessrio que haja uma associao de dados para que a informao seja obtida. Exemplos: Fornecimento: entre as entidades FORNECEDOR e MATERIAL Matrcula: entre as entidades ALUNO e DISCIPLINA Financiamento: entre as entidades PROJETO e AGENTE FINANCEIRO No DER, os relacionamentos so representados por losangos, ligados s entidades que participam do relacionamento

DEPARTAMENTO

LOTAO

EMPREGADO

Diagrama de ocorrncias de relacionamentos:

20

3.3.1.

AUTO-RELACIONAMENTO

Relacionamento entre ocorrncias da mesma entidade.

PESSOA marido CASAMENTO esposa

Diagrama de ocorrncias no auto-relacionamento:

O papel da entidade no relacionamento indica a funo que uma ocorrncia de uma entidade cumpre em uma ocorrncia de um relacionamento. 3.3.2. CARDINALIDADE DE RELACIONAMENTOS A cardinalidade de uma entidade em um relacionamento expressa o nmero de instncias da entidade que podem ser associadas a uma determinada instncia da entidade relacionada. Devem ser consideradas duas cardinalidades: Cardinalidade mnima de uma entidade o nmero mnimo de instncias da entidade associada que devem se relacionar com uma instncia da entidade em questo. Cardinalidade mxima de uma entidade o nmero mximo de instncias da entidade associada que devem se relacionar com uma instncia da entidade em questo. 21

3.3.3.

CARDINALIDADE MXIMA

No projeto para BD relacional (como neste curso) no necessrio distinguir as cardinalidades que sejam maiores que 1. Assim, so usados apenas as cardinalidades mximas 1 e n (muitos).

22

3.3.4.

CLASSIFICAO DE RELACIONAMENTOS BINRIOS

A cardinalidade mxima usada para classificar os relacionamentos binrios (aqueles que envolvem duas entidades). a) Relacionamentos 1:1 (um-para-um) Uma instncia da entidade A est associada com no mximo uma instncia da entidade B. Uma instncia da entidade B est associada com no mximo uma instncia da entidade A.
A B

A1

B1

A2

B2

A3

B3

23

b)

Relacionamentos 1:N (um-para-muitos)

. Uma instncia da entidade "A" esta associada a qualquer nmero de instncias da entidade "B". . Uma instncia da entidade "B", todavia, pose estar associada a no mximo uma instncia da entidade "A"
A
A1

B
B1

A2

B2

B3

B4

24

c) Relacionamentos N:N (muitos-para-muitos) Uma instncia da entidade "A" esta associada a qualquer nmero instncias da entidades "B". Uma instncia da entidade "B" esta associada a qualquer nmero de instncia da entidades "A"
A B

A1

B1

A2

B2

A3

B3

A4

B4

25

3.3.5.

RELACIONAMENTO TERNRIO

o relacionamento formado pela associao de trs entidades

Cardinalidade em relacionamentos ternrios:

3.3.6.

CARDINALIDADE MNIMA

A cardinalidade mnima usada para indicar o tipo de participao da entidade em um relacionamento. Esta participao pode ser: Parcial ou Opcional: quando uma ocorrncia da entidade pode ou no participar de determinado relacionamento; indicado pela cardinalidade mnima = 0 (zero). Total ou Obrigatria: quando todas as ocorrncias de uma entidade devem participar de determinado relacionamento; indicado pela cardinalidade mnima > 0 (zero). 26

Exemplos:
CLIENTE

REALIZA

PEDIDO

Um cliente pode fazer pedidos ou no, mas todos os pedidos devem estar associados a um cliente.
DEPTO

ALOCA

EMPREGADO

Todos os departamentos devem possuir pelo menos um empregado alocado, e todos os empregados devem estar alocados em um departamento.
DEPTO

1
10

ALOCA

EMPREGADO

Parcialidade mnima: para um departamento ser criado, devem existem pelo menos 10 empregados alocados. 3.4. NOTAES ALTERNATIVAS Notao Santucci/MERISE: semntica participativa
DEPTO 0,N) ALOCA 1,1) EMPREGADO

Notao Setzer: semntica associativa

DEPTO 1 ALOCA N EMPREGADO

Notao Heuser: semntica associativa

1,1) DEPTO ALOCA 0,N EMPREGADO

27

3.5. ATRIBUTO um dado que associado a cada ocorrncia de uma entidade ou relacionamento. Os atributos no possuem existncia prpria ou independente - esto sempre associados a uma entidade ou relacionamento Exemplos: Funcionrio: Matrcula, Nome, Endereo Material: Cdigo, Descrio Financiamento: Valor total, Meses Fornecedor: Nome, Endereo

3.5.1.

DOMNIO

o conjunto de valores vlidos que um atributo pode assumir. Ex: Estado civil: solteiro, casado, divorciado, vivo 3.5.2. TIPOS DE ATRIBUTOS

a) Opcional/Mandatrio Opcional: o atributo pode possuir um valor nulo (vazio). Ex: nmero de telefone Mandatrio: o atributo deve possuir um valor vlido, no nulo. Ex: nome do cliente b) Monovalorado/Multivalorado Monovalorado: o atributo assume um nico valor dentro do domnio. Ex: data de nascimento Multivalorado: o atributo pode assumir um nmero qualquer de valores dentro do domnio. Ex: Telefone para contato

28

c) Atmico/Composto Atmico: o atributo no pode ser decomposto em outros atributos. Ex: Idade Composto: o atributo composto por mais de um atributo. Ex: Endereo

3.5.3.

ATRIBUTO DE RELACIONAMENTO

Assim como as entidades, os relacionamentos tambm podem possuir atributos.

3.5.4.

IDENTIFICADOR DE ENTIDADES

Conjunto de atributos que tem a propriedade de identificar univocamente cada ocorrncia de uma entidade Toda entidade deve possuir um identificador O identificador deve ser mnimo, nico, monovalorado e mandatrio

29

3.5.5. RELACIONAMENTO FRACA)

IDENTIFICADOR

(ENTIDADE

Existem casos em que uma entidade no pode ser identificada apenas com seus prprios atributos, mas necessita de atributos de outras entidades com as quais se relaciona. Este relacionamento denominado Relacionamento Identificador. Alguns autores denominam uma entidade nesta situao de Entidade Fraca.

3.5.6.

IDENTIFICADOR DE RELACIONAMENTOS

Uma ocorrncia de relacionamento diferencia-se das demais pelas ocorrncias das entidades que participam do relacionamento. No exemplo

No exemplo, uma ocorrncia de ALOCAO identificada pela ocorrncia de Engenheiro e pela ocorrncia de Projeto. Ou seja, para cada par (engenheiro, projeto) h no mximo um relacionamento de alocao. Em certos casos, ser necessrio o uso de atributos identificadores de relacionamentos. Por exemplo:

Como o mesmo mdico pode consultar o mesmo paciente em diversas ocasies, necessrio o uso de um atributo que diferencie uma consulta da outra.

30

31

3.6. GENERALIZAO/ESPECIALIZAO A generalizao um processo de abstrao em que vrios tipos de entidade so agrupados em uma nica entidade genrica, que mantm as propriedades comuns A especializao o processo inverso, ou seja, novas entidades especializadas so criadas, com atributos que acrescentam detalhes entidade genrica existente A entidade genrica denominada superclasse e as entidades especializadas so as subclasses. A superclasse armazena os dados gerais de uma entidade, as subclasses armazenam os dados particulares Este conceito est associado idia de herana de propriedades. Isto significa que as subclasses possuem, alm de seus prprios atributos, os atributos da superclasse correspondente. Usada quando necessrio caracterizar entidades com atributos prprios ou participao em relacionamentos especficos

32

Uma generalizao/especializao pode ser total ou parcial: total quando, para cada ocorrncia da entidade genrica, existe sempre uma ocorrncia em uma das entidades especializadas. parcial quando nem toda ocorrncia da entidade genrica possui uma ocorrncia correspondente em uma entidade especializada.

33

3.7. ENTIDADE ASSOCIATIVA (AGREGAO) O uso desta abstrao necessrio quando um relacionamento deve ser representado como uma entidade no modelo conceitual. Isto ocorre quando necessrio estabelecer um relacionamento entre uma entidade e um relacionamento. Para atender a esta situao foi criado o conceito de Entidade Associativa ou Agregao. A agregao simplesmente um relacionamento que passa a ser tratado como entidade. Considerando o exemplo

Se for necessrio adicionar a informao que, a cada consulta um ou mais medicamentos podem ser prescritos ao paciente, ser necessrio criar uma nova entidade (MEDICAMENTO). Esta entidade deve se relacionar com as consultas, mas CONSULTA um relacionamento. Deve ser criada ento uma entidade associativa.

34

Outra forma alternativa de se representar a entidade associativa

35

4.

O MODELO RELACIONAL

Foi introduzido pelo pesquisador da IBM Edgar Frank Codd, 1970. Duas caractersticas marcantes, razes de sucesso : . estrutura de dados simples e uniforme . fundamentao terica slida O modelo de dados Relacional representa o banco de dados com uma coleo de tabelas Representao tabular : Toda relao pode ser vista como uma tabela, onde cada linha uma tupla e em cada coluna esto valores de um mesmo domnio. Exemplo : FORNECIMENTO
FORNECEDOR 1 2 4 PEA 2 3 1 PROJETO 5 7 1 QUANTIDADE 18 25 4

Relao = tabela Tupla = linha Atributo = coluna

36

4.1. CARACTERSTICAS DAS TABELAS - MODELO RELACIONAL Cada Tabela tem um nome nico atravs do qual ela referenciada. Cada Tabela contm um nmero fixo de colunas(grau tabela). No existem linhas iguais. d) A ordem das linhas irrelevante(identificao no feita pela localizao, mas sim pelo valor da chave primria). e) Cada coluna tem um nome nico(diferente das demais colunas). f) A ordem das colunas irrelevante(a coluna identificada pelo seu nome). g) Cada coluna contm valores atmicos(no so permitidos grupos de valores). h) Cada valor de coluna extraido de um determinado DOMNIO(conjunto de valores possveis). i) Duas ou mais colunas podem ser definidas sobre um mesmo Domnio. j) Operaes sobre colunas diferentes exigem que as colunas pertenam ao mesmo Domnio, k) Conexes entre Tabelas somente sero expressas atravs de valores das colunas(Chave Estrangeira).
a) b) c)

37

38

4.2. CONCEITOS BSICOS 4.2.1. CHAVE PRIMRIA : (PRIMARY KEY)

um atributo(coluna) ou uma combinao de atributos cujos valores distinguem uma linha das demais dentro de uma tabela. NUMFUNC Chave primria NOMEFUNC CPFFUNC DEPTO

4.2.2.

CHAVE ESTRANGEIRA : (FOREIGN KEY)

um atributo ou uma combinao de atributos, cujos valores aparecem necessariamente na chave primria de uma tabela. A chave estrangeira o mecanismo que permite a implementao de relacionamentos(navegabilidade) em um banco de dados relacional. NUMFUNC Chave primria DEPTO Chave primria NOMEFUNC CPFFUNC DEPTO Chave estrangeira

NOMEDPTO

4.2.3.

CHAVE CANDIDATA OU ALTERNATIVA

Em alguns casos, mais de um atributo ou combinaes de atributos podem servir para distinguir uma linha das demais. Um dos atributos (ou combinao de atributos) escolhido como chave primria, os demais atributos (ou combinaes) so denominados chaves CANDIDATAS NUMFUNC Chave primria NOMEFUNC CPFFUNC Chave candidata DEPTO Chave estrangeira

39

4.3. NORMALIZAO O que ? o processo formal de exame e agrupamento de dados numa forma capaz de suportar melhor as mudanas futuras, minimizando o impacto destas mudanas sobre a base de dados. Segundo Edgar F. Codd , normalizao um processo sistemtico e reversvel, que consiste em substituir um determinado conjunto de relaes por sucessivos conjuntos nos quais as relaes tenham uma estrutura mais simples e regular. Principais objetivos : Reduzir as redundncias Reduzir a necessidade de reestruturar as relaes quando novos tipos de dados so introduzidos Escopo : A partir deste processo pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta purificado em relao as anomalias de (incluso, alterao, excluso) Concluso : Durante a Modelagem Conceitual poderemos estar trabalhando sobre estruturas no normalizadas, pois o objetivo deste modelo com a representao semntica da realidade da empresa em primeiro lugar. Nossa proposta que seja feita uma reviso a nvel de transposio do DER para o DTR, verificando as regras de normalizao antes da transposio entre os modelos Conceitual e Lgico da realidade modelada.

40

4.3.1.

ILUSTRAO DE UM SISTEMA A SER NORMALIZADO

PEDIDO(# Num-Ped, Data-Ped, Num-Cli, Nome-Cli, End-Cli ((Cod-Prod, Nome-Prod, Qtde-Ped,Preo-Prod, Total-Prod)), Total-Ped) ( Pedido ) Dentro dos parenteses esto os tens de dados que constituem o

(( )) Os parenteses duplos envolvem os atributos do item da tupla do Pedido. Esses (( )) so utilizados para indicar que mais do que um Pedido de linha pode compor um Pedido: O tem de linha do Pedido chamado de GRUPO DE REPETIO
Num Data-Ped Ped 100 Num Nome End-Cli -Cli -Cli Joo Rua A, 19 Produtos Cod- NomeProd Prod 10 Banana 20 Maa 30 Laranja 20 40 10 50 10 Total Qtde- Preo- Total- -Ped Ped Prod prod 10 0,10 1,00 15 1,00 15,00 20 0,20 4,00 20,00 Maa 20 1,00 20,00 Mamo 10 0,50 5,00 25,00 0,10 2,00 Banana 20 Pra 10 0,50 5,00 7,00 Banana 10 0,10 1,00 1,00

1/3/99 100

200 300 400

2/4/99 100 3/5/99 200 4/7/99 300

Joo Jlio

Rua A, 19 Rua B, 19

Carlos Rua C, 20

41

Nesta Estrutura O que acontece se: - O Cliente mudar o endereo Estes problemas ocorrem na vida real Devemos analisar tambm a redundncia, um mesmo Cliente cada vez que fizer um pedido vamos guardar (nome-cli, end-cli). Anomalias de armazenamento. 1 Incluso : S possvel incluir um novo Cliente a partir de um pedido. Se nosso sistema fosse, nica e exclusivamente baseado na tabela apresentada at o momento, no poderamos cadastrar um novo Cliente em nossa tabela, a menos que surgisse um pedido para ele. 2 Excluso : Se houver a excluso do Pedido nmero 400, toda a informao do Cliente Carlos ser perdida. Neste caso, podemos perceber que o fato de um pedido conter, em sua estrutura, os dados do Cliente, vinculados diretamente a sua existncia, pode nos levar simplesmente, perder esses dados quando um pedido for excludo. 3 Alterao : Se algum dado do Cliente 100 mudar, teremos que efetuar esta operao em vrias linhas da tabela. Neste caso ser necessrio processar a alterao em cada uma das linhas de cada um dos pedidos pertencentes a esse cliente

42

Um analista experiente, intuitivamente separaria os vrios atributos do Pedido em arquivos(TABELAS) distintos. CLIENTE PEDIDO ITEM-PEDIDO PRODUTO A Normalizao realiza formalmente esta separao dos atributos em registros normalizados(CLIENTE, PEDIDO, ITEM-PEDIDO, PRODUTO) baseado na Dependncia existente entre cada atributo e sua chave primria. Ela consegue essa separao de ENTIDADES baseada no na intuio(como acontece com um analista de sistemas experiente), mas atravs de uma metodologia formal, que no requer experincia anterior com computadores.

43

4.3.2.

ANLISE DE DEPENDNCIA FUNCIONAL

Tcnica de normalizao adotada em nosso curso. Dependncia Funcional : O atributo B funcionalmente dependente do atributo A se, em qualquer instante, um valor em A determina, de modo nico, o valor correspondente em B, na mesma relao. Exemplo: EMPREGADO #Num-Emp Nome-Emp Vlr-Sal-Emp O Nome-Emp funcionalmente dependente do Num-Emp, pelo fato de cada Num-Emp est associado sempre ao mesmo Nome-Emp. Para denotar esta dependncia funcional, usa-se uma expresso na forma Num-Emp Nome-Emp. A expresso denota que a coluna Nome-Emp depende funcionalmente da coluna Num-Emp. Diz-se que a coluna Num-Emp o determinante da dependncia Funcional. De forma geral, o determinante de uma dependncia funcional pode ser um conjunto de colunas e no somente uma coluna como na definio acima.

44

Prope trs tipos de dependncias entre os atributos de uma tabela. a) Dependncia Funcional Total: Os atributos de uma tabela tem que depender da chave primria e somente da chave primria. Um atributo C totalmente funcionalmente dependente da chave primria composta pelo atributos A e B , quando for funcionalmente dependente de A e B e no dependente funcionalmente de qualquer parte da chave primria. Exemplo : ALOCAO # Num-Emp # Cod-Proj Qtde-horas-trab - A quantidade de horas trabalhadas num projeto no funcionalmente dependente do cod-proj, porque no significa o total de horas do projeto e no funcionalmente dependente da matrcula do funcionrio, porque no significa o total de horas trabalhadas pelo empregado. - A quantidade de horas trabalhadas determinada, de modo nico, pela composio da matrcula do empregado e do cdigo do projeto, porque significa a quantidade de horas trabalhadas por empregado em um determinado projeto. b) Dependncia Funcional Parcial : O atributo C parcialmente funcionalmente dependente da chave primria composta pelos atributos A e B quando for funcionalmente dependente de A ou B e no de ambos A e B
# Cod-mat # Cod-forn Nom-forn Prc-mat

O atributo nom-forn funcionalmente dependente somente do atributo cod-forn. O nome do fornecedor determinado, de modo nico pelo cdigo do fornecedor, independente dos materiais que so fornecidos. 45

A dependncia funcional parcial ocorre quando a chave primria da relao composta e se constitui numa anomalia que se deve ser evitada. A soluo para o problema da dependncia parcial consiste na criao de uma nova relao, que ser composta pelo atributo ou atributos que dependem de parte da chave e a chave que determine, de modo nico estes atributos
# Cod-mat # Cod-forn Prc-mat # Cod-forn Nom-forn

c) Dependncia Funcional Transitiva - O atributo C dependente funcional transitivo de A se C funcionalmente dependente de B e B funcionalmente dependente de A, na mesma relao.
# Num-emp
DFT D F T

Nom-emp Data-adm-emp Cod-proj Data-term-proj

DF

D F

DF

DF

O atributo data-term-proj funcionalmente dependente do atributo cod-proj, que por sua vez funcionalmente dependente do atributo Numemp. Ento data-term-proj dependente transitivo de Num-emp. A dependncia funcional transitiva constitui numa anomalia que deve ser evitada. A soluo para o problema da D.F.T. consiste na criao de uma nova relao que ser composta pelo atributo ou atributos que so dependentes funcionais transitivos tendo como chave primria o atributo que determina a transitividade.
# Num-emp Nom-emp Data-adm-emp Cod-proj # Cod-proj Data-term-proj

46

Resultado da anlise da dependncia Funcional: Uma relao estar normalizada segundo a anlise da dependncia funcional, quando possuir uma nica chave primria, todos os atributos no chaves forem totalmente funcionalmente dependentes da chave primria e independentes entre si, ou seja, aps a eliminao da dependncia funcional parcial e transitiva, caso exista.

47

4.3.3. 1a Forma Normal :

FORMAS NORMAIS:

Uma relao estar na 1a FN se no houver atributo representando agrupamento e nem atributo repetitivo(multivalorado). 2a Forma Normal : Uma relao estar na 2a FN, se e somente se, estiver na 1a FN e os seus atributos no chaves forem dependentes funcionais completos da chave primria. 3a Forma Normal : Uma relao estar na 3a FN, se e somente se, estiver na 2 FN e todos os seus atributos no chaves forem dependentes no transitivos da chave primria.

4.3.4.

ROTEIRO PRTICO PARA NORMALIZAO:

A)TRANSFORMAO DE RELAES NO NORMALIZADAS EM RELAOES NA 1 FN. - Escolher uma chave primria para a relao - Separar da relao os atributos(ou grupos) repetitivos, transformando a relao em outras duas relaes. . Uma delas contendo o grupo repetitivo e que ter como chave a combinao da chave primria da relao no normalizada e uma chave (ou +) escolhida(s) entre os atributos repetitivos. (Regra Geral) . Outra que permanece com a chave original e os atributos restantes. - Transformar atributos COMPOSTOS em atributos ATMICOS

48

B)TRANSFORMAO DAS RELAES EM 1 FN PARA RELAES NA 2 FN. - Examinar as relaes com chave primria composta e verificar se todos os atributos dependem funcionalmente de toda a chave ou apenas de parte dela. - Os atributos que dependem de parte da chave, formam uma nova relao, cuja chave primria a parte da chave da relao em 1 FN da qual dependem. - Apenas os atributos que dependem totalmente da chave composta permanecem na relao original. C) TRANSFORMAO DAS RELAES EM 2 FN PARA RELAES EM 3 FN. - Examinar as dependncias funcionais entre todos os atributos das relaes em 2 FN. - Aqueles atributos que dependem de outro atributo da relao, que no a sua chave, vo constituir uma nova relao cuja chave o atributo do qual dependem. ATENO : Esta chave continua como atributo na tabela Base pois o elo de ligao entre ambas.

49

4.3.5.

EXEMPLO DE NORMALIZAO:

ENTIDADE ATRIBUTO Num-Ped Data-Ped Num-Cli Nome-Cli End-Cli Cod-Prod Nome-Prod Qtde-Ped Preo-Prod Total-Prod Total-Ped

PEDIDO X \ \ \ \ (\) (\) (\) (\) (\) \

50

1 FN liminar atributos multivalorados e atributos representam agrupamento

ENTIDADE ATRIBUTO Num-ped Data-Ped Num-Cli Nome-Cli Nome-log Numero-log Cidade-log Estado-log Cep-log Cod-Prod Nome-Prod Qtde-Ped Preo-Prod Total-Prod Total-Ped PEDIDO ITEM PED X \ \ \ \ \ \ \ \ X

X \ \ \ \ \

51

2 FN Eliminar D.F.P
ENTIDADE ATRIBUTO Num-Ped Data-Ped Num-Cli Nome-Cli Nome-Log Numero-Log Cidade-Log Estado-Log Cep-Log Cod-Prod Nome-Prod Qtde-Ped Preo-Prod Total-Prod Total-Ped PEDIDO X \ \ \ \ \ \ \ \ ITEM PED PRODUTO X

X \ \ \ \

X \

52

3 FN Eliminar D.F.T - Redundncia deve ser evitada. No devo guardar o que posso calcular(Cuidado - carroa)
ENTIDADE ATRIBUTO Num-Ped Data-Ped Num-Cli Nome-Cli Nome-Log Numero-Log Cidade-Log Estado-Log Cep-Log Cod-Prod Nome-Prod Qtde-Ped Preo-Prod Total-Prod Total-Ped PEDIDO X \ \ ITEM PED X X \ \ \ \ \ \ X \ \ X \ PRODUTO CLIENTE

53

4.4. TRANSPOSIO D.E.R PARA D.T.R (DIAGRAMA DE TABELAS RELACIONAIS) 4.4.1. . James Martin SIMBOLOGIA ADOTADA NO MODELO RELACIONAL

um opcional

um obrigatrio vrios

.
1: 1 1:N N:N

Bachman

Notao de setas

54

4.4.2. 4.4.3.

ANLISE DA ENTIDADE NO D.E.R ANLISE DE RELACIONAMENTO

Toda Entidade vai virar uma Tabela no D.T.R As ligaes entre as tabelas assumem um papel importante, pois atravs delas que so representados os relacionamentos do modelo relacional. Representao do Relacionamento no D.T.R . Relacionamento vira Tabela . Relacionamento vai ser representado por uma Chave Estrangeira 4.4.3.1 Mapeamento Relacionamento 1 p/ 1 A) Pelo menos uma das entidades possui participao total no relacionamento. A entidade que tem participao obrigatria no relacionamento recebe a chave estrangeira.
DEPTO 1 CHEFIA 1 EMPREGADO

DEPTO #COD-DEPTO NOME-DEPTO NUM-EMP

EMPREGADO #NUM-EMP NOME-EMP

B) Ambas entidades possuem participao parcial no relacionamento Uma das entidades, dependendo do modelo, recebe a chave estrangeira.
HOMEM 1 CASAMENTO 1 MULHER

HOMEM #CPF-H NOME-H

MULHER #CPF-M NOME-M CPF-H

55

4.4.3.2 Mapeamento Relacionamento 1 p/ N A entidade do lado N recebe a chave estrangeira, independente se sua participao no relacionamento total ou parcial Ex.1)
CLIENTE 1 FAZ N PEDIDO

CLIENTE #COD-CLI NOME-CLI CGC-CLI

PEDIDO #NRO-PED DATA-PED COD-CLI

Ex.2)

HOMEM

CASAMENTO

MULHER

HOMEM #CPF-H NOME-H

MULHER #CPF-M NOME-M CPF-H

56

4.4.3.3 Mapeamento Relacionamento N p/ N - Um relacionamento N:N sempre pode ser resolvido em dois relacionamentos 1:N. Uma relao de interseo dever ser implementada.
N N

FORNECEDOR

FORNECIMENT O

MATERIAL

FORNECEDOR #COD-FORN NOME-FORN

FORNECIMENTO #COD-FORN #COD-MAT QTDE

MATERIAL #COD-MAT DESC-MAT

4.4.3.4 Mapeamento Relacionamento Mltiplo

FORNECEDOR N FORNECIMENTO N MATERIAL

PROJETO

FORNECEDOR #COD-FORN NOME-FORN

FORNECIMENTO #COD-FORN #COD-MAT #COD-PROJ QTDE

MATERIAL #COD-MAT DESC-MAT

PROJETO #COD-PROJ NOME-PROJ

57

4.4.3.5 Mapeamento Agregao

MEDICO

ATENDE

PACIENTE

SOLICITA

N EXAME

MEDICO #COD-MED NOME-MED

ATENDE #COD-MED #COD-PAC DATA-CONS

PACIENTE #COD-PAC NOME-PAC

SOLICTA #COD-MED #COD-PAC #COD-EXAME RESULTADO-EX

EXAME #COD-EXAME DESC-EXAME

58

4.4.3.6 Mapeamento Auto Relacionamento

DISCIPLINA

PRE-REQUISITO

DISCIPLINA #COD-DISC NOME-DISC

PRE-REQUISITO #COD-DISC-P #COD-DISC-S DATA-PRE

59

4.4.3.7 Mapeamento Hierarquia de Classe

COD- CLI

CLIENTE

NOME- CLI

TIPO FISCAL

CPF

CGC

PESSOA FSICA

PESSOA JURDICA

60

a) Mapear em uma nica Relao

CLIENTE
# COD-CLI NOME-CLI CPF-CLI /CGC-CLI

b) Mapear nas Subclasses as relaes

PESSOA FSICA # COD-CLI NOME-CLI CPF-CLI PESSOA JURDICA # COD-CLI NOME-CLI CGC-CLI

c) Mapear como Relaes distintas

CLIENTE # COD-CLI NOME-CLI PESSOA FSICA # COD-CLI CPF-CLI PESSOA JURDICA # COD-CLI CGC-CLI

61

4.5. RESTRIES DE INTEGRIDADE NO MODELO RELACIONAL 4.5.1. INTEGRIDADE LGICA

. Conjunto de regras que existem para o modelo de dados, assim como um conjunto de regras de negcio, que regem a manipulao do BD, de forma a no ferir nenhuma destas regras estabelecidas 4.5.2. INTEGRIDADE FSICA . Conjunto de procedimentos operacionais que garantem a integridade do BD, mesmo em situaes de falha de algum componente do ambiente onde o BD manipulado 4.5.1- INTEGRIDADE LGICA a) Restrio de Chave Uma relao deve ter pelo menos uma chave b) Restrio de Integridade de Entidade Nenhum valor da chave primria de uma relao pode ser nula c) Restrio de Integridade de Referncia A chave estrangeira deve ter correspondncia com a chave primria em outra tabela ou ser nula d) Restrio de Integridade Semntica ou Regras do Negcio So regras ditadas pelo negcio e no so mapeadas pelo M.E.R por se tratar de condies especiais EX: . Valor mnimo de depsito para abertura de uma conta R$10.000,00 . Conta corrente sem movimento a 180 dias ser encerrada. Podem ser cumpridas e implementadas pelos SGBDs Relacionais, atravs do mecanismo de Regras ou gatilhos (Triggers), hoje existentes no SQL

62

4.5.1.1 - INTEGRIDADE REFERENCIAL DE INSERO 1 - Respeitar as cardinalidades mnimas 2 - Antes de INSERIR uma nova linha em uma tabela que contem um valor de chave estrangeira, necessrio que j exista uma linha em uma tabela com este valor de chave primria. Caso contrrio, a operao de INSERO deve ser rejeitada ou uma linha com a chave primria dever ser inserida na respectiva tabela. DEPARTAMENTO DESCRIO NUMDEPTO 100 R.H 200 COBRANA 300 INFORMTICA FUNCIONRIO NOME NUMFUNC 9999 LUIZ 8888 VERA 9898 ALBERTO

NUMDEPTO 100 300 200

4.5.1.2 - INTEGRIDADE REFERENCIAL DELEO . Quando uma linha de uma tabela deletada ento: a) Todas as ocorrncias de chave estrangeira desta chave primria tambm devem ser deletadas (CASCATA) b) Os valores de chave estrangeira devem ser atualizados para nulo(SET NULL) c) A operao de deleo pode ser rejeitada, se existir uma ocorrncia de chave estrangeira da chave primria a ser deletada. (RESTRITA)

63

4.5.1.3 - INTEGRIDADE REFERENCIAL ATUALIZAO: . Se uma chave primria atualizada, ento a) Mudar para nulas todas as ocorrncias existentes de chave estrangeira como antigo valor b)Mudar todas as ocorrncias de chave estrangeira do antigo valor para o novo valor c)Rejeitar a atualizao

64

4.6. LINGUAGENS RELACIONAIS - FORMAIS . LGEBRA RELACIONAL . CLCULO RELACIONAL - COMERCIAIS . SQL : Sctructured Query Language . QUEL : linguagem de Consulta INGRES 1976 . QBE : Query By Example IBM - 1975

65

4.6.1.

LGEBRA RELACIONAL

Matemticamente falando, uma tabela (relao) um conjunto , um conjunto de linhas. No modelo relacional temos o B.D. representado como uma coleo de tabelas, quando queremos manipular ( recuperar ) dados em geral o resultado nos apresentado como uma tabela, derivada de alguma forma de outras tabelas. A lgebra relacional um conjunto de operaes e relaes. 4.6.1.1 - Operaes tradicionais - Union (Unio) - Intersection (Interseo) - Diference (Diferena) - Cartesian Product (Produto Cartesiano) 4.6.1.2- Operaes especiais - Project (Projeo) - Select (Seleo) - Join (Juno) - Divide (Diviso)

66

4.6.1.1 - Operaes Tradicionais . UNION R S: Retorna uma tabela que inclui todas as tuplas que esto ou em R ou em S, ou em ambas. Tuplas duplicadas so eliminadas.
Exemplo

R3 = R1 R2 R1 union R2 giving R3
R1 COD S1 S2 NOME CIDADE JOAO JOSE RJ RJ R2 COD S1 S3 NOME CIDADE JOAO BETO RJ SP R3 COD S1 S2 S3 NOME CIDADE JOAO JOSE BETO RJ RJ SP

. INTERSECTION R S: Retorna uma tabela que inclui as tuplas que esto em R e em S.

Exemplo

R4 = R1 R2 R1 intersection R2 giving R4
R4 COD S1 NOME CIDADE JOAO RJ

. DIFERENCE R S: Retorna uma tabela que inclui todas as tuplas que esto em R mas no esto em S.
Exemplo

R5 = R1 - R2 R1 diference R2 giving R5
R5 COD S2 NOME CIDADE JOSE RJ

67

4.6.1.1 - Operaes Tradicionais . CARTESIAN PRODUCT R X S: Retorna uma tabela que combina todos os atributos de duas tabelas.
Exemplo

R8 = R6 X R7 R6 cartesian R7 giving R8

R6

A A1 A2

B B1 B2

R7

C C1 C2

D D1 D2

R8

A A1 A1 A2 A2

B B1 B1 B2 B2

C C1 C2 C1 C2

D D1 D2 D1 D2

4.6.1.2 - Operaes Especiais . PROJECT <colunas> (tabela): Seleciona certas colunas de uma tabela e descarta outras. Elimina repeties dentro da coluna.
Exemplo

R9 = Cod (R1) Project R1 over Cod giving R9

R1

COD F1 F2 F3 F4

NOME JOSE JOAO MARIA PEDRO

R9

COD F1 F2 F3 F4

68

. SELECT (tabela): Seleciona um subconjunto de tuplas de uma tabela que satisfaam a uma condio de seleo. O resultado da seleo tem colunas com os mesmos nomes e domnios da tabela de entrada.
<condio>
Exemplo

R11 = salrio > 5.000 (R10) Select R10 where salario > 5.000 giving R11

R10 COD DEPTO SALARIO F1 F2 F3 D1 D2 D1 1.000 4.000 6.000

R11 COD F3

DEPTO SALARIO D1 6.000

69

4.6.1.2- Operaes Especiais . DIVIDE R1 R2: A operao de diviso tem duas tabelas como operandos. Os nomes das colunas (e os respectivos domnios) da tabela R2 (C2) devem estar contidos dentro dos nomes das colunas (e respectivos domnios) da tabela R1 (C1). A tabela resultante tem como nomes de colunas e domnios aqueles que aparecem em R1 mas no aparecem em R2 (C1 - C2). Exemplo: R14 = R12 R13 Divide R12 by R13 over B giving R14

R12 COD B A1 A2 A3 A7 A2 A3 A7 B1 B1 B2 B2 B3 B3 B3

R13 B B2 B3

R14 COD A3 A7

70

Exemplo: Todos os fornecedores das peas 'P2' e 'P4' R3 = Fornecimento Temp Divide Fornecimento by Temp over CodPea giving R
Fornecimento CdPea CodFornec P1 F1 P2 F1 P3 F1 P4 F1 P5 F1 P2 F2 P4 F2 P1 F3 P2 F3 P3 F3 P4 F3 P1 F4 P2 F4 P2 F5 Temp Cdpea P2 P4 R CdFornec F1 F2 F3

71

. JOIN A combinao de uma operao de seleo, aplicada sobre uma operao de produto cartesiano usual em aplicaes de BD. atravs dela que dados de tabelas relacionadas so associados. Por isso, foi criada a operao join (juno), que corresponde exatamente a esta seqncia de operaes (produto cartesiano e seleo). RX<condio>S: A operao join usada para combinar tuplas relacionadas de duas tabelas em uma nica tupla.
Exemplo

R17 = R15 X R15.A = R16.A R16 Join R15 and R16 over A giving R17 JOIN NATURAL O JOIN na verdade duplica a coluna que passada como argumento. ( Ns adotamos que no )
R15 A S1 S2 B ZE JO C 20 10 D RJ SP R16 A S1 S2 S3 E 5 10 15 F 6 7 8 R17 A S1 S2 B ZE JO C 20 10 D RJ SP ! ! A S1 S2 E 5 10 F 6 7

Estamos trabalhando com JUNO baseada em igualdade de valores (EQUI-JOIN). Mas poderamos ter JUNO com qualquer expresso booleana ("maior que", menor que, "no igual", etc). Um EQUI-JOIN em que os nomes das colunas sejam iguais chamado JOIN NATURAL. Neste caso, o nome das colunas, no precisam ser especificadas. R17 = R15 XR16

72

4.6.2.

EXEMPLOS DE LGEBRA RELACIONAL

4.6.2.1 - Considere as seguintes relaes

FORN #FN Fnome 1313 Pavan 1320 ABC 1330 DEF 1350 Gil 1360 Visart #FN 1313 1313 1320 1320 1360 1313 Fcidade J. Fora T.Rios J. Fora J. Fora R.Janeiro #PN P1 P2 P2 P3 P3 P4 PEA #PN P1 P2 P3 P4 Pnome Pcor pia branca vaso bege sifo branca fio preto

FORNECIMENTO

QTDE 25 20 25 20 25 20

A) Quais os nomes dos fornecedores que fornecem pelo menos 1 pea. A - Comandos a.1) PROJECT FORNECIMENTO OVER FN GIVING R1 a.2) JOIN FORN AND R1 OVER FN GIVING R2 a.3) PROJECT R2 OVER Fnome GIVING R3 A Smbolos a.1) R1 = FN FORNECIMENTO

a.2) R2 = R1 |X| R1.FN = FORN.FN FORN a.3) R3 = Fnome R2

FN 1313 1320 1360 Fnome Pavan ABC Visart a.2) R2 FN 1313 1320 1360 Fnome Pavan ABC Visart Fcidade J. Fora T. Rios R. Janeiro

a.1)R1

a.3)R3

73

B) Quais os nomes de todos os fornecedores PROJECT FORN OVER Fnome GIVING ARQ ARQ = Fnome FORN C) Encontre o nome da cidade do fornecedor 1360 C - Comando SELECT FORN WHERE FN = 1360 GIVING R1 PROJECT R1 OVER Fcidade GIVING R2 C Smbolo R1 = FN = 1360 FORN

R2 = Fcidade R1

D)

Encontre o nome dos fornecedores de J. Fora D - Comando SELECT FORN WHERE Fcidade=J. Fora giving R1 PROJECT R1 OVER Fnome GIVING R2 D Smbolo R1 = Fcidade =J. Fora FORN

R2 = Fnome R1

E)

Encontre o nome das Peas fornecidas pelo fornecedor 1313 E Comando SELECT FORNECIMENTO WHERE FN = 1313 GIVING R1 PROJECT R1 OVER PN GIVING R2 JOIN R2 AND PECA OVER PN GIVING R3 PROJECT R3 OVER PNOME GIVING R4 E Smbolo R1 = FN = 1313 FORNECIMENTO

R2 = PN R1 R3 = R2 |X| R2.PN = PECA.PN PECA R4 = pnome R3

F)

Obtenha o nome dos fornecedores que fornecem a pea P2

74

4.6.2.2 - Considere as seguintes relaes

ALUNO #Matr 9516001 9516002 9516003 9616001 9616002 Nome Jose Juca Joao Pedro Carlos DISC #Codigo ADMP LTPIV TAPII Nome Administ. B.D Projeto

APROVADO

#Matr 9516001 9516001 9516002 9516002 9516002 9516003

#Codigo LTPIV TAPII ADMP LTPIV TAPII ADMP

Nota 55,0 60,0 80,0 90,0 90,0 70,0

Falta 2 4 0 1 2 2

A) Obter o nome dos alunos que j cursaram todas as disciplinas.

75

5.

EXERCCIOS:
5.1. EXERCCIOS DE MODELAGEM DE DADOS

5.1.1.Projetos
Este texto descreve uma Empresa de Projetos de grande porte, envolvendo diversos projetos como Engenharia, Urbanismo, Transporte. A Empresa organizada em Deptos. Cada Depto coordena ( responsvel) por vrios projetos e um projeto coordenado obrigatoriamente por um nico Depto. Cada Depto tem um Empregado que o gerencia. Um empregado deve pertencer obrigatoriamente a um Depto, mas pode estar alocado vrios Projetos.

5.1.2.Loja
Uma loja especializada em computadores resolveu automatizar seus procedimentos de venda e aluguel de computadores. Atravs de entrevistas com seu diretor, gerente e funcionrios, observou o seguinte: Os clientes da loja podem alugar ou comprar computadores. Se o cliente faz opo por alugar ento obrigatoriamente tem que fazer um contrato de manuteno para dar cobertura ao computador que est sendo alugado. Sabe-se ainda que : Dado um cliente e um Contrato este par pode estar associado a vrias mquinas. Dado uma mquina de um determinado contrato este par pertence a um nico cliente. Dado um Cliente e uma mquina este par pertence a um nico contrato.

5.1.3.A Universidade Milenium

Os diversos institutos da Universidade Milenium esto organizados em Departamentos. Cada departamento possui um corpo docente e um dos professores o Chefe do Departamento. Um Departamento responsvel pelo ensino de diversas disciplinas. Cada disciplina pode ser lecionada por vrios professores. Um professor pode lecionar mais de uma disciplina. Os alunos cursam as disciplinas de acordo com os pr-requisitos j alcanados. Os alunos podem optar com qual professor ele cursar determinada disciplina. A Universidade mantm, para cada aluno, um Histrico Escolar, que relaciona as disciplinas que ele j cursou, com as respectivas notas e a freqncia.

5.1.4.Controle de Projetos
Uma Empresa manufatureira funciona num esquema de Projeto, nos quais so alocados seus empregados com um certo percentual de dedicao. Administrativamente, os empregados esto lotados em departamentos e podem gerenciar um ou mais projetos que so gerenciados por um nico empregado. As Peas utilizadas nos projetos so armazenadas nos vrios armazns. A Empresa mantm um controle do fornecimento Efetivo de Peas feito aos projetos pelos fornecedores, e um controle de fornecimento Potencial de Peas de cada um dos seus fornecedores. Deve-se controlar a composio das peas, onde uma pea pode ser simples ou composta. As peas compostas so montagens de peas simples. Cada pea simples pode ser utilizada para compor vrias peas compostas.

76

5.1.5. Empresa do ramo de alimentao

Deseja-se controlar as principais atividades de uma empresa do ramo de alimentao, que possui vrias lojas de varejo e vrios armazns para guardar seus produtos. Estes armazns so especializados (por exemplo, frigorfico) de maneira que um produto s pode ser armazenado em um nico armazm e um armazm pode armazenar vrios produtos. As lojas podem emitir vrios pedidos, sendo que um pedido deve pertencer obrigatoriamente a uma loja. Um Pedido composto de vrios produtos e um produto pode fazer parte de vrios pedidos. Para entregar os pedidos a empresa conta com uma frota de caminhes dos mais variados tipos. Um caminho pode atender a vrios pedidos, e um pedido pode ser atendido por mais de caminho (por exemplo, no caso em que pedido no caiba em um nico caminho). Observe que o sistema deve ser capaz de informar quais os produtos de determinado pedido esto em determinado caminho. O sistema deve permitir ainda que existam pedidos que no sejam atendidos por nenhum caminho. Cada caminho tem um obrigatoriamente um funcionrio que o responsvel pelo mesmo, e um Funcionrio pode ser responsvel por mais de um caminho.

5.1.6.Restaurante
Deseja-se desenvolver um Sistema de Controle das principais atividades de um restaurante, atendendo s seguintes consideraes: Os Clientes novos devero ser cadastrados pelo sistema para efeito de correspondncias futuras, sendo necessrio armazenar os dados pessoais. Sabe-se que cada cliente pode fazer vrios pedidos, ou nenhum, e um pedido sempre estar associado a um nico cliente. Um pedido est associado obrigatoriamente a vrios itens de cardpio. Cada item do cardpio pode estar associado a vrios pedidos ou nenhum, sendo necessrio armazenar quais itens foram pedidos, a quantidade de cada um e a data do pedido, a fim de que a conta, com o valor total, possa ser gerada no final do atendimento. Cada item do cardpio possui um cdigo, um nome, um tipo (indicando se bebida ou comida), uma descrio detalhada e um preo unitrio. Cada pedido est associado a uma mesa, sendo possvel associar vrios pedidos a uma mesma mesa. Cada mesa atendida por um nico garon, que pode atender a vrias mesas. O nmero de identificao do garon tambm deve constar na conta a ser gerada.

5.1.7.A cadeia de Hotis Imperador

A cadeia de Hotis Imperador possui diversos hotis situados nas principais capitais. Cada hotel possui vrios tipos de apartamento (simples, luxo, suite, etc.) e um apartamento, naturalmente, pertence a um nico hotel. Toda vez que um cliente se hospeda, necessrio que ele informe o nmero da Carteira de Identidade ou Passaporte, endereo, data de nascimento e o sexo. Para controle interno, o hotel tambm registra o nmero do quarto alocado e a data da hospedagem. Qualquer hotel da cadeia deve ser capaz de responder imediatamente a um pedido de reserva (efetivando-a ou negando-a). A data em que foi feita a reserva deve ser registrada. O hspede pode utilizar os diversos servios do hotel (lavanderia, sauna, etc.), pagando a conta apenas no check-out. Os servios oferecidos por toda a cadeia de hotis so padronizados.

77

5.1.8.Modelo para uma biblioteca

Uma Empresa possui uma Biblioteca para uso exclusivo dos seus empregados que podem levar emprestado um nmero qualquer de exemplares, e fazer solicitaes de emprstimo (RESERVA) quando no houver exemplar disponvel. Os Livros so classificados em Categorias e em Subcategorias. Eles devem pertencer a uma nica categoria Principal e podem pertencer a vrias Categorias Secundrias. Quando um Livro possui vrios Autores um deles e referido como Autor Principal e os outros como Co-Autores.

5.1.9.Modelo para uma Locadora de veculos

Uma locadora de automveis possui cerca de 100 carros, cujo emprstimo deve ser controlado. Os CARROS so identificados pelo nmero da placa e so de MODELOS especficos. Cada modelo fabricado por um FABRICANTE. Para alugar um carro o CLIENTE deve ser cadastrado. Para cada cliente necessrio saber seu nome, numero-identidade, telefone, endereo. Cada cliente identificado por um cdigo. Quando um cliente aluga um carro ento obrigatoriamente tem que fazer um SEGURO, identificado pelo numero da aplice do seguro. Sabe-se ainda que: Dado um Cliente e um Carro este par refere-se a um nico Seguro. Dado um Cliente e um Seguro este par refere-se a um nico Carro. Dado um Carro e um Seguro este par refere-se um nico Cliente

5.1.9.Modelo para clube de Jogos em CD-ROM

Um clube que aluga CD-ROM de jogos, resolveu controlar seus emprstimos atravs de um sistema computacional. necessrio manter um controle dos SCIO do clube e dos EXEMPLARES dos JOGOS(ttulos) que eles tomam emprestado. Cada Scio pode pegar emprestado vrios exemplares e pode indicar algumas PESSOAS autorizadas a fazer emprstimo em seu nome, sabe-se que uma Pessoa pode ser autorizada por no mximo um Scio. Existem vrios Exemplares de CD-ROM para cada Jogo(ttulo) e cada exemplar possui obrigatoriamente um Jogo. Os Jogos podem ser SHAREWARE ou OFICIAL. Somente os jogos oficiais so comprados atravs de fornecedores cadastrados. Sabe-se que um fornecedor pode fornecer vrios jogos oficiais e um Jogo oficial fornecido somente por um fornecedor.

78

5.2. EXERCCIOS DE NORMALIZAO: 5.2.1 - PEDIDOS(#Num-pedido, data-Pedido, Num-Cliente, Nome-Cliente, End-Cliente, ((Cod-Produto, nome-Produto, Preo-Unitrio, QtdePedida,Valor-Total-Item)),Valor-Total-Pedido) 5.2.2 - CONTRATO(#Num-contrato, Cod-Cliente, Nome-Cliente, CPFCliente, Dt-inic-contrato, Dt-term-contrato, ((Num-prestao, Valor-Prestao, Dt-Venc-prest)), Valor-Total-Contrato) 5.2.3 - EMPREGADO(#Cod-Empregado, Nome-Empregado, TtuloEmpregado, ((Cod-Curso,Nome-Curso, data-incio-Curso, Resultado-Curso))) 5.2.4 - PEA-ESTOCADA(#Cod-Pea, #Cod-Armazem, Qtde-Estocada, Tel-armazem) 5.2.5 - QUADRO-PESSOAL #Cod-Orgo Nome-Orgo HIST-CARGO N vezes Cod-Cargo Nome-Cargo Nmero-Vagas HIST-FUNCIONRIO N vezes Matricula-Emp Nome-Emp Data-Posse

79

5.2.6 - DADOS-EMPREGADO #Matricula Nome Endereo Cdigo-Cargo-Atual Nome-Cargo-Atual HIST-CURSOS N vezes Cod-Curso Nome-Curso Data-Concluso Nota-Final HIST-HABILIDADES N vezes Cod-Habilidade Nome-Habilidade Grau-Habilitao Data-Admisso Codigo-Orgo-Lotao Nome-Orgo-Lotao 5.2.7 PROJETO #Cod-Proj Tipo-Proj Desc-Proj HIST-EMPREGADO N VEZES Cod-Empregado Nome-Emp Cat-Emp Sal-Emp Data-ini-Proj 5.2.8 ARQ_CANDIDATO #Cod-Curso Nome-Curso Num-Vagas-Curso HIST-CANDIDATO N VEZES Cod-Cand Nome-Cand Escore-Cand 80

5.2.9 ARQ_ALUNO #Cod-Aluno Nome-Aluno HIST-CURSO N VEZES Cod-Curso Nome-Curso Ano-Sem-Ingresso HIST-DISCIPLINA N VEZES Cod-Disciplina Nome-Disciplina HIST-SEMESTRE-CURSADO N VEZES Ano-Sem-Disc-Cursada Nota-Disc

81

5.3. EXERCCIOS DE LGEBRA RELACIONAL 5.3.1 Exerccio Locadora de Fitas

CLIENTE #ID Nome 101 Josemar 102 Juca 103 Lucas 104 Petrus 105 Cludio EMPRESTIMO #ID #IDFita 102 1203 103 1205 104 1401 FITA #IDFita 1201 1203 1205 1401 __ DataAquis IDFilme 12/12/2001 0003 15/04/2000 0003 07/05/2001 0002 27/10/2000 0001 FILME _________ #IDFilme Titulo__________ 0001 E o vento levou 0002 ET 0003 SpiderMan 0004 MadMax

DataEmp 12/5/2002 14/5/2002 13/5/2002

Valor 3,50 3,00 3,50

a) Nome de todos os clientes. b) IDFita e DataAquis do filme 0003. c) Nome do cliente que est com a fita 1203. d) Nome do filme cuja fita est com Petrus. e) Nome dos clientes que esto com fita em emprstimo. f) Data em que foi emprestada a fita do filme ET. 5.3.2 Exerccio de consultoria
CONSULTOR #ID Nome Formao 0001 Edison Engenharia 0002 Raquel Economia 0003 Allan Administracao AREA CONSULTORIA #IDA Descrio #ID #IDA Horas A1 Planejamento 0001 A1 A2 Obras Civis 0002 A1 A3 Marketing 0001 A2 30 0003 A3 45

20 25

a) Nomes dos consultores engenheiros. b) Nomes e Formao de todos os consultores. c) Formao do consultor 0002. d) Nomes dos consultores que j prestaram consultoria. e) Descrio da reas em que Raquel j prestou consultoria. f) Nome dos consultores que trabalharam com Marketing.

82

6.

BIBLIOGRAFIA
1 ELMASRI, Ramez e NAVATHE, Shamkant B. Sistemas de Banco de Dados Fundamentos e aplicaes. 3 Edio. Ed. LTC, 2002. 2 KORTH, H. F. e SILBERSCHATZ, A. Sistemas de Banco de Dados. So Paulo, 5 edio Ed. Campus, 2006. 3 HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre. Ed. Sagra Luzzato, 1998. 4 -DATE, C. J. Introduo a Sistemas de Banco de Dados, Rio de Janeiro, 8o edio Americana, Ed. Campus, 2004. 5 - SETZER, Valdemar W.. Banco de Dados, So Paulo, Ed. Edgar Blucher, 1986. 6 - COUGO, Paulo. Modelagem Conceitual, Rio de Janeiro, Ed. Campus,1997. 7 - BARBIERI, Carlos. Modelagem de Dados, Rio de Janeiro, Ed. IBPI Press,1994. 8 - MACHADO, Felipe Nery R. Projeto de Banco de Dados uma viso prtica, So Paulo, Ed. rica, 1995. 9 - CEROLA, Vicente Osvaldo. Banco de dados relacional e distribudo, So Paulo, LTC, 1995. 10 - CHEN, Peter. Gerenciando Banco de Dados. A abordagem entidade e Relacionamento, So Paulo, Ed. McGraw Hill, 1990

83