BD Banco20de20dados

Fundao Educacional de Fernandpolis
Apostila de Banco de Dados

Prof. Evandro A. Jardini 1 de fevereiro de 2006
Sumrio
1 Introduo 1.1 Sistema de Processamento de Arquivos . . . . . 1.2 Independncia de Dados . . . . . . . . . . . . . 1.3 Sistema Gerenciador de Banco de Dados (SGBD) 1.3.1 Caracterticas de um SGBD . . . . . . . 1.4 Motivao para SGBDs . . . . . . . . . . . . . . 1.4.1 Linguagens de acesso a um SGBD . . . . 1.4.2 Arquitetura de um SGBD . . . . . . . . . 1.5 Exerccios . . . . . . . . . . . . . . . . . . . . . 1.6 Bibliograa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 6 6 7 8 8 9 9 10 10 11 12 12 13 13 14 14 15 16 16 16 16 18 18 18 20 20 20 22 23 23 23 23 23 27
O Modelo Entidade-Relacionamento 2.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Chave Primria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Atributos Multivalorados . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Atributos Compostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Atributo Derivado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Entidades Fracas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Atributos de Relacionamento . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Cardinalidade dos Relacionamentos . . . . . . . . . . . . . . . . . . . . . 2.4.3 Grau dos Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3.1 Relacionamentos Binrios . . . . . . . . . . . . . . . . . . . . . 2.4.4 Relacionamentos Ternrios . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Auto-Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 MER Estendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Generalizao e Especilizao . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1.1 Relacionamentos entre Entidades Especializadas . . . . . . . . . 2.5.1.2 Multiplas Especializaes . . . . . . . . . . . . . . . . . . . . . 2.5.1.3 Restries da Abstrao de Generalizao . . . . . . . . . . . . 2.5.2 Agregao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2.1 1 Caso do uso de Agregao (Opcionalidade) . . . . . . . . . . . 2.5.2.2 2 Caso do uso de Agregao (Identicador em Relacionamento) . 2.5.2.3 3 Caso do uso de Agregao (indica tempo) . . . . . . . . . . . 2.6 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Primeira Lista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Bibliograa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SUMRIO
3 O Modelo Relacional 3.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Domnios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Relaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Chave no Modelo Relacional . . . . . . . . . . . . . . . . . . 3.4.1 Superchave . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Chave . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Chave Candidata . . . . . . . . . . . . . . . . . . . . 3.4.4 Restries de Integridade . . . . . . . . . . . . . . . . 3.4.4.1 Chave Estrangeira (Integridade Referencial) 3.4.4.2 Exemplos de Restries de Integridade . . . 3.5 Outros tipos de Restries . . . . . . . . . . . . . . . . . . . 3.6 Bibliograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapeamento do Modelo ER para Modelo Relacional 4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . 4.2 Mapeando Entidades . . . . . . . . . . . . . . . . 4.3 Entidades Fracas . . . . . . . . . . . . . . . . . . 4.4 Relacionamento Binrio com Cardinalidade 1:1 . . 4.5 Relacionamento Binrio com Cardinalidade 1:N . . 4.6 Relacionamento Binrio com Cardinalidade M:N . 4.7 Relacionamentos Ternrios . . . . . . . . . . . . . 4.8 Exemplo 1 . . . . . . . . . . . . . . . . . . . . . . 4.9 Atributos Compostos e Multivalorados . . . . . . . 4.10 Generalizao . . . . . . . . . . . . . . . . . . . . 4.11 Agregao . . . . . . . . . . . . . . . . . . . . . . 4.12 Exemplo 2 . . . . . . . . . . . . . . . . . . . . 4.13 Resumo dos 6 passos . . . . . . . . . . . . . . . . 4.14 Bibliograa . . . . . . . . . . . . . . . . . . . . . Normalizao de Relaes 5.1 Introduo . . . . . . . . . . . 5.2 Normalizao de Relaes . . 5.3 Anomalias de Modicaes . . 5.4 Primeira Forma Normal . . . . 5.5 Dependncia Funcional . . . . 5.6 Segunda Forma Normal (2FN) 5.7 Terceira Forma Normal (3FN) 5.8 Exemplo Prtico . . . . . . . . 5.9 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 28 28 29 29 30 30 30 31 31 31 32 33 33 34 34 34 35 35 35 36 36 37 38 39 39 40 40 41 42 42 42 42 43 44 44 45 46 48 49 49 50 51 52 52 53 53 54
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lgebra Relacional 6.1 Introduo . . . . . . . . . . . . . . . . . 6.2 Operao Selecionar ( ) . . . . . . . . . 6.3 A Operao Projetar ( ) . . . . . . . . . 6.4 A Operao Unio ( ) . . . . . . . . . . 6.5 A Operao Interseco de Conjuntos ( ) 6.6 A Operao Diferena de Conjuntos (-) . 6.7 A Operao Produto Cartesiano (X) . . . 6.8 A Operao Juno Natural (|X|) . . . . .

SUMRIO
6.9 A Operao Diviso ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Captulo 1 Introduo
Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado de banco de dados, contm informaes sobre uma empresa em particular. O principal objetivo de um SGBD proporcinar um ambiente tanto conveniente quanto eciente para a recuperao e armazenamento das informaes do banco de dados. SGBDs so projetados para gerir grandes volumes de informaes. Devem possuir mecanismos para denio e manipulao de dados, alm de prover compartilhamento e segurana dos mesmos.
1.1 Sistema de Processamento de Arquivos

Como exemplo, considere a rea de um banco responsvel por todas as informaes de seus clientes e de suas contas-poupana. Um modo de guardar as informaes no computador armazen-las em sistemas de arquivos permanentes. Para o acesso aos dados foram desenvolvidos os seguintes mdulos de programas: Programa para dbito e crdito na contabilidade.

Programa para incluir novos registros na contabilidade. Programa parabalano da contabilidade.
A medida que surge na necessidade, outros mdulos so desenvolvidos. Considere que os programas foram desenvolvidos em Pascal (poderiam ter sido desenvolvidos em Clipper, Cobol, Basic, etc) e que a estrutura do registro de cliente : type Cliente = record nome:string; rua:string; cidade:string; cep; end; Neste Sistema de Processamento deArquivos que acabamos de descrever, os registros so armazenados em vrios arquivos e diversos programas so escritos para extrair e gravar estes registros. Obter informaes organizacionais em sistemas de processamento de arquivos apresenta numerosas desvantagens: 4
CAPTULO 1. INTRODUO
Redundncia e inconsistncia de dados: Redundncia a caracterstica onde um elemento de informao aparece duplicado em diversos lugares. Por exemplo, um clientede uma empresa pode esta cadastrado tanto na base de dados do departamento de crdito assim como no departamento de contabilidade. Esta redundncia pode causa a inconsistencia, visto que as informaes podem ser diferentes para o mesmo cliente. Diculdade no acesso aos dados: Suponha que um diretor necessite encontrar os clientes que residem em uma rea da cidade onde o CEP seja 12133-433. Se este modulo do sistema de informao no estiver implementado, o diretor ter duas opes: ele pega a lista de clientes e extrai a informao necessria, ou pede para o departamento de informtica implementar a rotina necessria para obteno do relatrio.

Isolamento de dados: Uma vez que os dados esto espalhados em diversos arquivos e podem ter formatos diferentes, difcil escrever novos programasaplicativos para recuperar os dados adequados. Anomalia de acesso concorrente: Evitar problemas relacionados a acesso concorrentes em um dado. Por exemplo, se duas pessoas sacarem dinheiro de uma conta ao mesmo tempo, o resultado das operaes concorrentes podemdeixar um saldo inconsistente. Considere uma conta com a quantia de $400 e dois saques simultneo de $100 e $50. Se houver problema de concorrncia, a conta pode car com valores de $300 ou de $350 ao invs de $250 Segurana: Cada usurio do sistema poder ter acesso aos dados relativos a sua funo. Por exemplo, um caixa no pode ver dados pertencentes as diretoria. Problemas de Integridade: Os valores armazenados BD devem satisfazer certos tipos de restries de consistncias. Por exemplo, um lho de um funcionrio no pode ser cadastrado sem que o pai trabalhe na empresa.
1.2 Independncia de Dados

O desenho a seguir representa um sistema de processamento de arquivo tpico:
Arquivo de Cliente
Figura 1.1: Sistema de Processamento de Arquivo De acordo com a gura 1.1, nota-se que os programas gravam seus dados em disco, seguindo estruturas prprias. Para acess-los necessrio conhecer sua estrutura. Se vrios programas compartilham seus dados, todos devem conhecer e manipular as mesmas estruturas. Se algum programa precisar de alguma mudana de dados, todos os programas tero que ser alterados, mesmo que a alterao ocorra em dados que ele no utiliza.
CAPTULO 1. INTRODUO
Se entre os programas e os dados for colocado um sistema que converte o formato em que os dados esto gravados para o formato especco que cada programa precisa dos dados, ento cada programa: V apenas os dados que lhe interessa;

No precisa entrar em detalhes de como seus dados esto sicamente gravados; No precisa ser modicado se a estrrutura de dados que ele no utiliza for mudada.
feita uma converso especca dos dados gravados para a forma usada em cada programa. Alterar os dados obriga a alterar a forma de converso para cada programa, mas no cada programa em si. As alteraes cam concentradas nesse sistema intermedirio. Esse sistema intermedirio chamado de Sistema Gerenciador de Banco de Dados (Figura 1.2).
SGBD
Banco de Dados
Figura 1.2: Independencia de Dados provida pelo SGBD
1.3 Sistema Gerenciador de Banco de Dados (SGBD)

Como j foi dito, um SGBD e um conjunto de programas com a nalidade de manipular um conjunto de dados. Com a introduo de um SGBD em uma organizao demanda o surgimento de um novo prossional, o Administrador de Banco de Dados (DBA). O DBA responsvel pela manuteno do SGBD e da Base de Dados em si, centralizando todo o gerenciamento sobre a estrutura dos dados da empresa.
1.3.1 Caracterticas de um SGBD

Segue as caracterticas que um SGBD tem de ter: CONTROLE DE REDUNDNCIA:A redundncia, ou seja, a repetio de dados, deve ser evitada para se minimizar possibilidade de inconsistncias. COMPARTILHAMENTO DE DADOS:Em um ambiente multi-usurios deve-se possibilitar a manipulao simultnea de dados distintos ou dos mesmos dados conforme regras abaixo.
CAPTULO 1. INTRODUO
CONTROLE DE ACESSO: Vericao automtica do tipo de acesso pedido por cada usurio. Os nveis de segurana so estabelecidos para cada usurio independentemente, de acordo com suas necessidades.A identicao de cada usurio, por parte do SGBD, feita pelo nome e senha cadastrados. CONTROLE DE TRANSAO: Transao o conjunto de operaes que devem ser executadas completamente. So normalmente usadas em situaes crticas (atualizaes ou incluses) de longa durao que podem afetar a consistncia do BD. Exemplo: bug milnio, corte dos 3 zeros, aumento geral dos produtos, etc. O SGBD deve utilizar mecanismos internos para que nenhuma falha ocorra durante a execuo da transao.

ACESSO EM MLTIPLAS INTERFACES: Possibilidade de usar diversas interfaces mesmo se o SGBD estiver sendo utilizado. Por exemplo: Se existe uma aplicao emDelphi com o SGBD Interbase, se trocar alinguagem para Visual Basic, no necessrio fazeralteraes no SGBD. RESTRIES DE INTEGRIDADE: Estabelecimento de um formato para os dados inseridos de modo a garantir uma certa integridade e facilitar oarmazenamento. Ex. Tamanho do nomes empreigual a 30 e em maisculo, armazenamento dos salrios em dlar, etc. Algumas regras de integridade so estabelecidas pelo prprio SGBD para manter o BD consistente e outras so denidas pelo DBA por meio de sentenas condicionais queso vericadas toda vez que um dado armazenado no BD. BACKUP E RECUPERAO:Estabelecer o backup automtico do BD total ou parcial em momentosestabelecidos pelo DBA.Proporcionar proteo contra a perda de informaes devido afalhas nodispositivo de armazenamento (discos). INDENPENDNCIA DE DADOS: A descrio fsica dos arquivos mantida internamente pelo SGBD e de suainteira responsabilidade e exclusividade.Programas aplicativos no dispem da descrio fsica esim de uma descrioexterna.Alteraes nos arquivos podem no afetar os programas aplicativos. INDEXAO AUTOMTICA: Com a indicao explcita dos atributos quesero mais utilizados em consultas,o SGBD cria os arquivos de indexao que tornaro mais rpidas as pesquisas. A estrutura de indexao e de organizao dos arquivos de dados prprio decada SGBD e normalmente no de domnio dos usurios comuns.
1.4 Motivao para SGBDs

A utilizao dos SGBDs traz os seguintes problemas: um produto caro; um sistema a mais a ser aprendido e gerenciado; Ocupa espao de armazenagem no computador.
Porm traz vantagens muito maiores:
CONSISTNCIA DE DADOS E INDEPENDNCIA DE DADOS

Alm disso, O SGBD a ferramenta por excelncia para promover a integrao dos diversos componentes de um sistema de software;
CAPTULO 1. INTRODUO
Concentram o maior potencial para promover aceso compartilhado de informao, sem bloquear desnecessariamente o acesso compartilhado; retiram dos programas aplicativos muita da complexidade de gerenciamento de estruturas de acesso aos dados;

Facilitam a proteo contra a perda de dados, atrave de recursos de backup; s Promovem a adoo de padres para toda a empresa, facilitando seu emprego.
1.4.1 Linguagens de acesso a um SGBD

Existe uma linguagem especca para denir o esquema conceitual e fsico de um SGBD. A linguagem utilizada a Structured Query Language (SQL), que apesar de exitir um padro denido, varia de SGBD pra SGBD. A SQL pode ser dividida em 3 grupos: Linguagem de Denio de Dados (DDL): Reponsvel por criar e manipular os objetos de armazenamento de dados no SGBD. Linguagem de Manipulao de Dados (DML): Responsvel por manipular os dados do SGBD. Linguagem de Controle dos Dados (DCL): Responsvel por permitir o acesso de usurios ao SGBD.
Os aplicativos so escritos em uma linguagem de programao, que pode ser: DELPHI, VISUAL BASIC, COBOL, C, PASCAL, ETC. A SQL utilizada de forma embutida nestas linguagens. A linguagem SQL engloba numa nica linguagem todos os recursos necessrios para a manipulao da Base de Dados.
1.4.2 Arquitetura de um SGBD

A arquitetura de um SGBD se divide em trs nveis (Figura 1.3): Nvel Interno ou Fsico: o mais prximo do meio de armazenamento fsico, ou seja, aquele que se ocupa do modo como os dados so sicamente armazenados. Nvel Conceitual ou Lgico: Descreve quais dados esto armazenados no banco de dados e quais os interrelacionamentos entre eles. Este nvel utilizado pelos administradores. Nvel externo: o mais prximo dos usurios, ou seja, aquele que se ocupa do modo como os dados so vistos por usurios individuais.
Exemplos para compreenso dos nveis: No nvel conceitual: O banco de dados contm informaes relativas a um tipo de entidade chamada EMPREGADO. Cada empregado contm um NMERO_EMPREGADO, um NMERO_DEPARTAMENTO e um SALRIO. No nvel interno: Os empregados so representados por um tipo de registro armazenado, denominado EMP_ARMAZENADO, com 20 bytes de comprimento. Contm 4 campos: um prexo de 6 bytes mais 3 campos de informao de empregado. Alm disso os registros so indexados sobre o campo EMP. No nvel externo: O usurio SECRETRIA tem uma viso na qual cada empregado tem 2 campos: Nome e Salrio. J o usurio CONTADOR tem uma viso que cada empregado tem os campos Nome e Salrio.
CAPTULO 1. INTRODUO
VISAO 1
VISAO 2
S G B D
Esquema Conceitual
Esquena Fisico
Figura 1.3: Arquitetura de SGBD
1.5 Exerccios
1. Resolver em grupo as questes 1.2, 1.4, 1.7, 1.8, 1.9, 1.10, 1.17 e 1.23 do captulo 1 da bibliograa 2. Ateno: Este captulo encontra-se no Xerox. 14 pginas. 2. Resolver em grupo as questes 2.3, 2.5, 2.7, 2.8 do captulo 2 da bibliograa 3.
1.6 Bibliograa
[1] Traina Jr, Caetano, Modelagem de Dados, Apostila, ICMC-USP. [2] Kroenke, David M., Banco de Dados:Fundamentos, Projeto e Implementao, Editora LTC, 6 ed, Captulo 1, Rio de Janeiro, 1999 [3] Date, C. J., Introduo a Sistemas de Banco de Dados, Editora Campus, Ed. 7, Captulo 2, Rio de Janeiro, 2000.
Captulo 2 O Modelo Entidade-Relacionamento

Este captulo descreve e ilustra o uso do Modelo Entidade-Relacionamento (MER), que foi apresentado por Peter Cher em 1976. Hoje no existe um padro nico de modelo E-R aceito universamente; em vez disto, h um conjunto de conceitos dos quais se origina a maioria das variantes do E-R. No MER, os elementos que o compe so representados gracamente atravs da ferramenta denominada Diagrama Entidade - Relacionamento (DER). A seguir so descritos os principais elementos que compe o MER.
2.1 Entidades
Dene-se entidade como aquele objeto que existe no mundo real com uma identicao distinta e com um signicado prprio. So as coisas que existem no negcio, ou ainda, descrevem o negcio. Se alguma coisa , existente no negcio nos proporciona algum interesse em mantermos dados (informaes armazenadas sobre ele), ista a caracteriza como uma Entidade do Negcio. Alguns exemplos de entidades: O FUNCIONRIO Joo;

O VEICULO Corsa; A ALUNA Maria; O CLIENTE Pedro; O PRODUTO A323....
Entidades de um mesmo tipo so agrupadas em Classes de Entidade. Assim, a classe de entidades FUNCIONRIOS o conjunto de todas as instncias de funcionrios. Neste texto, classes de entidades esto impressas em letra maiscula. Cada ocorrncia de um funcionrio dentro da classe FUNCIONRIO denominado Instncia de Entidade. A representao grca de uma entidade no MER se realiza atravs de um retngulo, com o nome desta entidade em seu interior, como mostra a gura 2.1. 10
CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

CLIENTE PRODUTO FUNCIONARIO
11
NOTA FISCAL
ORDEM DE PRODUCAO
Figura 2.1: Exemplos de Entidades
Importante: As instncias de uma entidade no so representadas no DER.
2.2 Atributos
Toda entidade possui propriedade que so descritas por Atributos. No MER supe que todas as instncias de uma dada classe de entidade possuem os mesmos atributos. Considere a entidade FUNCIONRIO uma empresa. O que descreve Funcionrio? Funcionrio descrito por: nmero de mtricula

nome data da admisso
Como representado na tabela 2.1. Tabela 2.1: Entidade Funcionrio Matrcula 4455 4456 4457 4458 Nome Data Admisso Joo 24/04/1991 Pedro 30/02/1992 Jos 14/04/1992 Manoel 01/01/1995
No DER os atributos PODEM ser representados por um circulo em torno de seu nome, como mostra a gura 2.2.
FUNCIONARIO
Matricula
Nome
Atributo
Data Admissao
Figura 2.2: Represetnao de Atributos
12
2.2.1 Chave Primria

No existe DUAS INSTNCIAS DE ENTIDADES IGUAIS. Sempre haver atributo (ou atributos) que nunca se repete. Este atributo tem a funo de atuar como identicador nico das instncias da entidade e denominado de CHAVE PRIMRIA. Na tabela 2.1, a chave primria o atributo MATRICULA. Ento, como a chave primria identica uma instncia da entidade, ela tem duas restries importantes: No se repete;

No contm valor NULO.
Um VALOR NULO um valor que no tem signicado algum para o mundo real, somente para o conceitual. No DER, um atributo chave primria representa por um trao abaixo de seu nome, como mostra a gura 2.3.
ALUNO RA Nome Chave Primaria
Data_Nasc
Figura 2.3: Atributo Chave Primria Alm da chave primria tambm temos: Superchave: o conjunto de um ou mais atributos que, tomado coletivamente, permite-nos identicar unicamente uma entidade no conjunto de entidade. Chaves candidatas: chaves com unicidade em uma relao: Ex: CIC, RG, ttulo eleitoral. Todos os atributos que conseguem identicar uma Relao. Chave secundria: chave sem unicidade em uma relao. Ex: idade, sexo,endereo.
2.2.2 Atributos Multivalorados

So atributos que para cada instncia de um entidade, ele pode ocorre vrias vezes. No DER, representado por duas elipses em torno do nome do atributo. Ex.: Telefones para clientes ou alunos, Nomes de cidades beira de uma rodovia, Nomes dos autores de um livro, etc. A gura 2.4 representa o atributo telefone dos cliente de uma empresa. A representao em um SGBD para atributos multivalorados mostrado na tabela 2.2:
13
Clientes RG Nome
Figura 2.4: Atributos Multivalorados Tabela 2.2: Representao em um SGBD de atributos multivalorados da entidade cliente RG 11 16 Nome Pedro Afonso Telefone 442 3244 1231
Telefone
RG_Cliente 16 16 11
2.2.3 Atributos Compostos

So atributos formados por outros atributos. Ex: Telefones, Enderecos, Nome, area de uma sala, etc A gura 2.5, representa atributos compostos de uma entidade: Em um SGBD, os atributos so representados da maneira como mostra a tabela 2.3 Tabela 2.3: Atributo Composto em um SGBD numero comprimento largura s1 5 3 s2 5 2 s3 7 3 altura 3 3 3
2.2.4 Atributo Derivado

So atributos derivados de outros atributos ou originados de algum calculo. Por exemplo, na gura 2.6, tm-se os campos idade e qtidade_de_funcion. O primeiro calculado a partir da data de nascimento e o segundo obtido atravs da contagem dos funcionrios. Por esta razo, este atributo no precisa ser armazenado.
14
Atributo Composto Sala Numero
Dimensao
Comprimento
Largura
Altura
Figura 2.5: Atributos Compostos
codigo data_nasc idade
FUNCIONARIO
qtde_de_funcion
Figura 2.6: Atributo derivado (representado pela linha pontilhada).
2.3 Entidades Fracas

Pode ocorrer que alguma instncia de entidade possua uma dependncia existencial com outra instncia de entidade e neste caso cada instncia daquela Entidade existe somente porque est associada a outra instncia de entidade diferente. Dizer que uma Entidade fraca, signica dizer:QUE NO INTERESSA MANTER NA BASE OS DADOS DE UMA ENTIDADE SE ELA NO ESTIVER RELACIONADA COM OUTRA ENTIDADE. Este tipo de Entidade denominada Entidade Fraca. Exemplo: Dependente um tipo de Entidade Fraca pois existe somente se existir o funcionrio. A gura 2.7 representa o DER da entidade fraca: Considerando a entidade Funcionario e seus Dependentes, a tabela 2.4 representa as instncias de cada entidade:
2.4 Relacionamentos
Nenhuma informao armazenada no Banco de Dados existe isoladamente. Todos os elementos pertencentes ao mundo real modelado de alguma forma est associado a outros elementos. Normalmente essas associaes representam aes fsicas ou alguma forma de dependncia entre os elementos envolvidos. Relacionamento: a associao entre Entidades. No DER, os relacionamentos so representados conforme mostra a gura2.8.
15
FUNCIONARIO
PRODUTOS
DEPENDENTE
LOTES
Entidades Fracas
Figura 2.7: Entidade Fraca Tabela 2.4: Representao das entidades Funcionrios e Dependentes Matrcula 4455 4456 4457 4458 Nome Data Admisso Joo 24/04/1991 Pedro 30/02/1992 Jos 14/04/1992 Manoel 01/01/1995 Nome Pedro Junior Marcelo Henrique
Matricula_Funcionario Codigo_Depend 4456 01 4458 01 4456 02
Agora que j temos as denies de Entidades e de Relacionamento, vamos aprender como encontr-los em um problema: Cliente faz emprestimos Desta frase, o que Entidade e o que relacionamento? Pode-se dizer que os SUBSTANTIVOS so as Entidades e os VERBOS so os Relacioanamentos. Sendo assim tem-se: Entidades:Cliente e Emprestimo.

Relacionamento: Faz
A gura 2.9 representa gracamente a modelagem deste enunciado.
2.4.1 Atributos de Relacionamento

Considere a gura 2.10. Atributos de Relacionamentos so igualmente representados como elipses, ligadas aos conjuntos de Relacionamento
16
Relacionamento
Figura 2.8: Representao grca de um relacionamento
CLIENTE
faz
EMPRESTIMO
Figura 2.9: Identicao de Entidade e Relacionamento Perceba que Nota um atributo tipicamente do relacionamento Cursa. Se fosse um atributo de Pessoa, cada pessoa teria apenas uma nota, no importa em qual disciplina. Se fosse um atributo de Disciplina, todas as Pessoas matriculadas numa disciplina teriam a mesma nota. Outro exemplo: A quantidade de Material fornecidos por um Fornecedor.
2.4.2 Cardinalidade dos Relacionamentos

A quantidade de Entidades envolvidas em um Relacionamento determinado pela Cardinalidade do Tipo de Relacionamento, ou seja, pode-se estabelecer a quantidade mnima e mxima de Entidades envolvidas com cada Entidade relacionada. A Cardinalidade Mnima que determina a quantidade mnima de Entidades relacionadas determinada pelo nmero representativo, ou seja, 0 (zero), 1, 2,... N(muitos). A Cardinalidade Mxima que determina a quantidade mxima de Entidades relacionadas determinada pelo nmero representativo, ou seja, 0 (zero), 1, 2,... N (muitos). A gura 2.11 demonstra os tipos de Cardinalidades Mximas que se tem para os relacionamentos Binrios.
2.4.3 Grau dos Relacionamentos

Um Relacionamento pode envolver duas ou mais Entidades. O Grau do Relacionamento o nmero de Entidades envolvidas. Desta forma pode-se categorizar os tipos de relacionamento em: 2.4.3.1 Relacionamentos Binrios Relacionamento que envolve duas Entidades. Figura 2.12.
2.4.4 Relacionamentos Ternrios

Relacionamento que envolve duas Entidades. Figura 2.13. Colocar quando usar o relacionamento ternario. Exemplo : fornacedor, peca, e projeto (tudo M:N).
17
ALUNO RA Nome
Cursa
DISCIPLINAS
Nota
Codigo Nome
Figura 2.10: Atributo de Relacionamento

Cardinalidade EMENTA 1 1:1 (Um para 1 UM)
Possui
DISCIPLINA
Cardinalidade TURMA N
1:N
(Um
para
Muitos) 1 CURSO Muitos)
Pertence M:N (Muitos N Cursa
Cardinalidade M ALUNO
para
DISCIPLINAS
Figura 2.11: Tipos de Cardinalidade
Como Determinar as Cardinalidades de um Relacionamento Ternrio

Para determinar as Cardinalidades, por exemplo de ALUNO-PROFESSOR-DISCIPLINA, faa o seguinte: 1. Escolha uma Entidade, por exemplo ALUNO, e pergunte:Para cada Aluno, quantos pares Professor-Disciplina eu tenho. 2. Coloque a resposta na Entidade ALUNO. Neste caso N. Isto , um Professor lecionando uma Disciplina pode ter vrios Alunos. 3. Escolhendo a Entidade PROFESSOR. Pergunta-se: Para cada Professor, quantos pares Aluno-Disciplina eu tenho. 4. Coloque a resposta na Entidade PROFESSOR. Neste caso 1. Isto , um Aluno no pode ter em uma certa Disciplina mais do que um Professor. 5. Escolhendo a Entidade DISCIPLINA. Pergunta-se: Para cada Disciplina, quantos pares Aluno-Professor eu tenho. 6. Coloque a resposta na Entidade Disciplina. Neste caso N. Isto , um Professor pode dar a um certo Aluno mais do que uma Disciplina.
18
CLIENTE
Compra
PRODUTO
CURSO
Inscreve
CANDIDATO
Figura 2.12: Exemplo de Relacionamento Binrio

PROFESSOR P-A-D ALUNO
DISCIPLINA CORRENTISTA C-C-CM CONTA
CARTAO_MAGNETICO
Figura 2.13: Exemplo de Relacionamento Ternrio
2.4.5 Auto-Relacionamentos
Uma instncia ou conjunto de instncia de uma mesma Entidade, pode se relacionar com outra(s) instncia(s) da mesma Entidade. Na gura 2.14 temos os seguintes exemplo: Disciplina pr-requisito de Disciplina

Funcionrio gerencia Funcionrio
2.5 MER Estendido

Com o passar do tempo, percebeu-se que o MER original, criado por Peter Chen, no modelava alguns tipos de progblemas. Surgiu ento, uma extenso do MER denominada MER Estendido ou MER-RX.
2.5.1 Generalizao e Especilizao

Algumas Entidades contm conjunto de atributos especcos. Quando ocorre a situao em que uma entidade possuir atributos que no fazem parte de todas as instncias da entidade ou quando estas instncias se relacionarem de maneira diferente com outras entidades, temos ai o conceito de GENERALIZAO/ ESPECIALIZAO.

N DISCIPLINA M N FUNCIONARIO 1
Figura 2.14: Exemplo de Auto-Relacionamentos Considere a entidade CLIENTE com os atributos nmeroCliente, NomeCliente e QuantiaDevida.
19
Pre-Requisito
Gerencia
Suponha que um CLIENTE pode ser uma nica pessoa individual, uma associao ou uma coporao e que sero armazenados dados adicionais dependendo do tipo. Suponha ainda que estes dados adicionais so: CLIENTE-INDIVIDUAL: Endereco, NumeroPrevidenciaSocial

CLIENTE-ASSOCIACAO: NomeAssociado, Endereco, Taxa CLIENTE-CORPORACAO: PessoaContato, Fone, NumeroIdenticacao
Para modelar esta situao demos 2 alternativas: 1. Alocar todos estes atributos na entidade CLIENTE. Neste caso, alguns dos atributos no so aplicveis a todas as entidades. 2. Denir 3 entidades para cada um dos tipos. As quais seriam: CLIENTE-INDIVIDUAL, CLIENTEASSOCIACAO e CLIENTE-CORPORACAO. Outros exemplos: FUNCIONARIO:CODIGO, NOME, ENDERECO SECRETARIA:cursos, linguas ENGENHEIRO:crea, especialidade VEICULO:chassis, marca UTILITARIO:capacidade_lugares TRANSPORTE:Tara A gura 2.15 demonstra esta situao do cliente. Uma vez que a entidade CLIENTE uma entidade genrica, ela denominada de GENERALIZAO (ou entidade de nvel superior) e as entidades INDIVIDUAL, ASSOCIADO e CORPORAO so denominadas ESPECIALIZAO (ou entidade de nvel inferior).

NumeroCliente NomeCliente QuantiaDevida
20
CLIENTE
INDIVIDUAL Endereco NumPrevSocial
ASSOCIADO
CORPORACAO
Endereco Taxa
PessoaContato Telefone
Figura 2.15: Generalizao e Especializao 2.5.1.1 Relacionamentos entre Entidades Especializadas Entre as especializaes pode haver relacionamento. Considere a gura 2.16, ela demonstra o relacionamento que existe entras as especializaes PROFESSOR e ALUNO.
idade Pessoa
cpf nome
nrprof
titulo
ra curso
Aluno
Professor
Funcionario nrfunc funcao
Leciona
Figura 2.16: Relacionamento entre Especializaes 2.5.1.2 Multiplas Especializaes As especializaes podem se especializar em outras especializaes, isto ocorre na gura 2.17.
2.5.1.3 Restries da Abstrao de Generalizao Existem duas restries que devem ser denidas para cada Ocorrncia de Abstraes de Generalizao: Excluso Mtua/Sobrepostos: Onde EXCLUSO MTUA exige que uma entidade de nvel superior pode pertencer a apenas um conjunto de nvel entidades de nvel inferior. No exemplo da gura 2.15 uma cliente s pode ser ou INDIVIDUAL ou ASSOCIADO ou CORPORATIVO. J SOBREPOSTOS, uma entidade superior pode pertencer a mais de um conjunto de entidades de nvel inferior. O que o caso da gura 2.17, onde um ALUNO pode ser um FUNCIONARIO da escola.

idade Pessoa cpf nome
21
nrprof ra curso Aluno

Leciona
titulo
Professor
Graduac semestre
Pos_Grad
Orienta
area
Figura 2.17: Multiplas Especializacoes Total/Parcial: Onde TOTAL, signica que cada entidade superior deve pertencer a um conjunto de entidades de nvel inferiores. J PARCIAL, signica que uma entidade superior pode pertencer a a um conjunto de entidades de nvel inferior.

As possveis combinaes so: Parcial Exclusiva: Por exemplo, Um departamento ministra disciplinas para cursos de graduao e psgraduao (deve haver estas entidades). Alm disso pode ministrar disciplinas para treinamento sob solicitao de empresas (no precisa haver a entidade empresa).
Uma discip. ou de graduac. ou de ps, mas no pode disciplina ser as duas coisas. Existem discip. que no so nem de grad. nem de ps. Graduac pos-grad
Figura 2.18: Parcial exclusiva Parcial Sobreponvel: Um departamento contrata pessoal para desempenhar suas funes, tais como vigias, secretrios, bliblitecrios, etc.
pessoa Um funcionrio pode acumular mais de uma funo Alm de Vigia, secret. e bibliot. existem outras funes
vigia
secretario bibliotecrio
Figura 2.19: Parcial Sobreponvel Total Exclusiva: Um departamento ministra disciplinas para cursos de grad.e pos-grad. Alm disso pode ministrar disciplinas de especializao para treinamento sob solicitao de empresas.

Uma discip. ou de graduac. ou de ps ou de especializ, disciplina mas s pode ser uma dessas coisas. S existem discip. de grad., de ps ou de especializ.
22
Graduac pos-grad especializ
Figura 2.20: Total exclusiva Total Sobreponvel: Os alunos de um departamento so de Graduao ou de Especializao, conforme os cursos que frequentam.
Aluno Um aluno pode cursar mais de um curso ao mesmo tempo S existem alunos de grad., ps ou de especializao.
grad
pos-grad especiliz
Figura 2.21: Total Sobreponvel
2.5.2 Agregao
Uma limitao do modelo E-R que no possivel expressar relacionamentos entre relacionamentos. Alm Para ilustrar esta necessidade, considere um banco de dados descrevendo informaes sobre Funcionrios que trabalham em um determinado Projeto e utilizam uma srie de diferentes Mquinas em seus trabalhos. Usando o modelo bsico de construo E-R, obtemos o diagrama E-R da gura 2.22.
Horas FUNCIONARIO M Trabalho N N Usa PROJETO Numero Descricao
Id Nome
MAQUINA
Id Descricao
Figura 2.22: Diagrama E-R com relacionamentos redundantes No exemplo da gura 2.22, o relacionamento Usa deve empregar informaes j existentes previamente no conjunto de relacionamento Trabalho. Alm disso, h pares Funcionrio-Trabalho que no usam nenhuma mquina, isto , no esto em Usa.
23
A soluo usar a Agregao. A agregao uma abstrao por meio da qual relacionamentos so tratados como entidades de nvel superior. Assim, para nosso exemplo, o relacionamento Trabalho e as entidades FUNCIONRIO e PROJETO, torna-se-o uma nica entidade. Isto permite que relacionar o conjunto FUNCIONARIO, TRABALHO e PROJETO com a entidade MQUINA. A gura 2.23, mostra a soluo de nosso problema em forma de agragao.
Nome Id FUNCIONARIO Horas M Trabalho N Descricao Numero PROJETO
N Usa M MAQUINA Id Descricao
Figura 2.23: Diagrama E-R com Agregao Agora com a gregao, signica dizer que o conjunto Funcionrio-Projeto nem sempre utilizam mquinas. Outros exemplos:Assassino-Vitima-Arma, Cliente-Conta-CartoCrdito, Rua-Bairro-Linha. Agora que j temos a noo do uso da Agregao vamos analisar os casos em que se deve us-la: Quando necessrio identicar-se cada relacionamento.

Quando necessrio mais de um relacionamento envolvendo as mesmas entidade (ACABAR)
2.5.2.1 1 Caso do uso de Agregao (Opcionalidade) 2.5.2.2 2 Caso do uso de Agregao (Identicador em Relacionamento) 2.5.2.3 3 Caso do uso de Agregao (indica tempo)
2.6 Exerccios
2.6.1 Primeira Lista
1 - Obtenha o modelo Entidade-Relacionamento dos seguinte enunciados. Coloque os atributos necessrios das entidades. Coloque pelo menos 3 atributos em cada entidade. 1. Uma Empresa possui funcionrios. Um funcionrio trabalha em uma Empresa 2. Os Atletas participam de competies. Em uma compatio participam vrios atletas. 3. Deseja-se fazer um banco de dados para uma rede de hotelaria. Um hotel possui quartos. Cada quarto pertence a apenas um hotel.
24
4. Um soldado, que possui as caractersticas nome, Registro Militar (RM), data de nascimento, possui armas. Uma arma, que possui as caractersticas de srie, registro e calibre, de um soldado. Uma arma limpa por vrios soldados. Um soldado limpa vrias armas. 5. Um funcionrio supervisionado por um gerente (o gerente tambm um funcionrio). Um gerente (que tambm funcionrio) supervisiona vrios funcionrios. Do funcionrio deseja-se saber nome, cpf e endereo. 6. Um mdico trata de pacientes. Do mdico deseja-se saber CRM, nome e suas especialies. Um paciente, no qual h a necessidade de sabermos seu nome, endereo e idade, tratado por vrios mdico. Um paciente realiza vrios tipos de exames. Um tipo de exame, destes h a necessidade de guardar seu nmero, data e descrio, feito por vrios paciente. 7. O aluno cursa disciplinas lecionadas por um professor cada uma. Para cada aluno deve-se manter as informaes de ra, nome e seus telefones. Uma disciplina cursada por vrios alunos e lecionada por um professor. Das disciplinas deseja-se saber codigo, nmero de crditos e descrio. Os professores lecionam diversas disciplinas cada um e em cada disciplina possui diversos alunos. Dos professores deseja-se saber seu cdigo, nome e telefone. 8. Um mdico trata de pacientes. Do mdico deseja-se saber CRM, nome e suas especialies. O mdico pede exames para vrios pacientes. Um paciente, no qual h a necessidade de sabermos seu nome, endereo e idade, tratado por vrios mdico. Um paciente realiza vrios tipos de exames pedidos pelos mdicos. Um tipo de exame, destes h a necessidade de guardar seu nmero, data e descrio, feito por vrios paciente a pedido dos mdicos. 9. Uma empresa possui funcionrios. Os funcionrios podem ser engenheiros, secretrias ou tcnicos. 10. Uma empresa fabrica automveis. Os automveis podem ser carros de passeio, caminhes ou nibus. Identique as cardinalidade dos exerccios anteriores. 2 - Obtenha o modelo Entidade-Relacionamento dos seguinte enunciados. Coloque os atributos necessrios das entidades. Coloque pelo menos 3 atributos em cada entidade. 1. Uma empresa deseja elaborar um cadastro completo de seus empregados e suas atividades. Para cada empregado desejado armazenar seu nome, nmero funcional, telefone (ddd + nmero) e seus diversos dependentes (nem todo empregado possui dependente), o departamento no qual o empregado trabalha (todo empregado trabalha em um departamento), o departamento o qual o empregado gerencia (nem todo empregado gerencia departamento) e os diversos projetos no qual o empregado trabalha (nem todo empregado trabalha em projeto). Para cada departamento necessrio armazenar seu nome, nmero, os diversos empregados que o departamento possui (todo departamento possui empregado), o empregado que gerencia o departamento (todo departamento gerenciado por um empregado) e os diversos projetos que o departamento controla (nem todo departamento controla projetos). Para cada projeto necessrio armazenar seu nome, seu nmero, as diversas cidades nas quais o projeto desenvolvido, os diversos funcionrios que trabalham no projeto (todo projeto possui funcionrios) e o departamento que controla o projeto (todo projeto controlado por um departamento). Para cada dependente necessrio armazenar seu nome, sexo, o relacionamento com o empregado e o empregado do qual o dependente depende (todo dependente depende de um empregado). 2. Um Hotel deseja montar um banco de dados de Hospedagem. Do cliente que hospeda-se no hotel, e desejado saber seu nome, RG, Endereo, telefone e o quarto que esta hospedado. Dos quartos, deseja-se saber seu numero, andar, a quantidade de leitos e os clientes que dormiram no quarto(um quarto pode abrigar mais de um cliente). Deseja-se saber tambm a data de hospedagem e o que o cliente consumiu.
25
3. Uma Transportadora quer automatizar seu controle de transporte. Ela deseja ter as seguintes informaes de seus caminhes: Marca, modelo, ano, capacidade de transporte e a data em que um motorista viajou com o caminho(mais de um motorista pode dirigir um caminho). Do motorista deseja-se saber Nome, RG, Idade, Endereo e o caminho com o qual j viajou. Um caminho pode transportar diversos produtos, destes deseja-se saber nome, marca, fabricante e data de transporte( um tipo de produto pode viajar em mais de um caminho). 4. A Federao Paulista de Futebol deseja elaborar um cadastro geral para o Campeonato Paulista de 1999. Para cada time desejado armazenar seu nome, sua cidade, seu nmero de cadastro na FPF, a situao do time no campeonato, o estdio que o time possui (todo time possui um estdio), os jogos que o time participa (todos os times participam de jogos) bem como, o nmero de gols que o time marcou na partida, as diversas torcidas organizadas que o time possui (um time no obrigado a possuir torcida organizada), os diversos jogadores que compem o elenco do time (todo time possui jogadores no elenco) e os diversos jogadores cujos passes pertencem ao time (um time no obrigado a possuir passes de jogadores). Para cada jogo desejado armazenar seu nmero, a data, horrio, os diversos membro da comisso de arbitragem, o estdio no qual o jogo realizado (todo jogo realizado em estdio), os times que participam do jogo (todo jogo realizado por times), as diversas torcidas organizadas que frequentaram o jogo (nem todo jogo deve frequentado por torcidas organizadas) e os diversos jogadores que participaram ativamente do jogo, sendo desejado armazenar o nmero de gols, o nmero de cartes amarelos e o nmero de cartes vermelhos que o jogador recebeu no jogo (todo jogo disputado por jogadores). Para cada estdio desejado armazenar seu nome, localizao, o nmero de torcedores, os diversos jogos que o estdio abriga (um estdio no obrigado a abrigar jogos) e o time proprietrio do estdio (um estdio pode ser pblico). Para cada torcida organizada desejado armazenar seu nmero de cadastro na FPF, seu nome, o nome de seu presidente, sua sede, o nmero de associados, os diversos jogos que a torcida frequenta (uma torcida no obrigada a frequentar jogos) e o time para o qual a torcida torce (toda torcida torce para um time). Para cada jogador desejado armazenar o nmero de cadastro do jogador na FPF, seu nome, apelido, idade, o time ao qual o passe do jogador pertence (o jogador pode ter passe livre), o time para o qual o jogador atua (o jogador pode estar cadastrado na FPF e no atuar em um time) e os jogos dos quais o jogador participa ativamente (um jogador no obrigado a participar de jogos ativamente). 5. Uma universidade deseja elaborar um cadastro acadmico, envolvendo seus alunos, cursos e disciplinas. Para cada faculdade desejado armazenar seu nome, seu nmero, os diversos departamentos que a faculdade possui (toda faculdade dividida em departamentos) e os diversos professores que a faculdade possui (toda faculdade possui professores). Para cada departamento necessrio armazenar seu nmero, sendo que para cada faculdade, a numerao de seus departamentos vai de 1 at N, seu nome, o professor que chea este departamento (todo departamento cheado por um professor), a faculdade qual o departamento pertence (todo departamento pertence a uma faculdade), as diversas disciplinas que o departamento oferece (nem todo departamento oferece. Para cada curso desejado armazenar seu cdigo, seu nome, os diversos perodos nos quais o curso oferecido, o departamento ao qual o curso pertence (todo curso pertence a um departamento), os diversos alunos que frequentam o curso (se no hover alunos frequentando o curso o mesmo no ser cancelado) e as diversas disciplinas que so oferecidas pelo curso (todo curso oferece disciplinas). Para cada disciplina desejado armazenar seu nome, cdigo, carga horria, o departamento pelo qual a mesma oferecida (toda disciplinas oferecida por um departamento), os diversos cursos para os quais a disciplina oferecida (mesmo que uma disciplina no seja oferecida por um curso ela no ser cancelada), os diversos professores que lecionam a disciplina (toda disciplina lecionada por professores) e os diversos alunos que frequentam a disciplina, sendo necessrio armazenar para cada aluno a nota 1 N1, nota 2 N2, as faltas F, a mdia nal do aluno ((N1 + N2)/2) e a situao do aluno (mdia nal > 7) e F <= 25% aluno aprovado (se no houver alunos frequentando a disciplina, a mesma no ser cancelada). Para cada aluno desejado armazenar seu nome, ra, seus endereos completos (o da cidade onde reside e o da cidade da universidade) com rua, nmero, bairro, cep, cidade, seus telefones (o da cidade onde reside e o da cidade da universidade) com DDD + nmero, o curso que o aluno frequenta (todo aluno frequenta
26
um curso, no podendo frequentar mais que um), as diversas disciplinas que o aluno frequenta (todo aluno frequenta disciplina) e o professor que orienta o aluno (nem todo aluno orientado por professor). Para cada professor desejado armazenar seu nmero funcional, seu nome, a faculdade qual ele pertence (todo professor pertence a uma faculdade), o departamento o qual o professor chea (um professor no obrigado a chear um departamento) e as diversas disciplinas que o professor leciona (um professor no obrigado a lecionar disciplinas). 6. Um hospital deseja elaborar um cadastro para controlar as atividades de suas clnicas. Para cada clnica desejado armazenar seu nome, seu cdigo, sua especialidade e os diversos mdicos que a clnica possui (toda clnica possui mdicos). Para cada mdico desejado armazenar seu nome, nmero do CRM, sua especialidade, as diversas consultas que o mdico faz (o mdico no obrigado a realizar consultas), as diversas cirurgias que o mdico faz (um mdico no obrigado a realizar cirurgias) e a clnica ao qual o mdico pertence. Para cada consulta desejado armazenar seu nmero, sua data, horrio, o mdico que realizou a consulta (toda consulta realizada por um mdico) e o paciente que foi consultado (toda consulta feita em um paciente). Para cada cirurgia necessrio armazenar seu nmero, a data , o horrio, os diversos mdicos que realizaram a cirurgia (toda cirurgia realizada por mdicos), as diversas enfermeiras que auxiliaram na cirurgia (toda cirurgia auxiliada por enfermeiras) e o paciente no qual realizada a cirurgia (toda cirurgia realizada em um paciente). Para cada paciente desejado armazenar seu cod, nome, rg, dt de nascimento, endereo completo (rua, nmero, bairro, cep, cidade), as diversas consultas que o paciente realizou (um paciente no obrigado a realizar consultas), as cirurgias que o paciente realizou (um paciente no obrigado a realizar cirurgias) e as diversas enfermeiras que atenderam o paciente assim como a data e o horrio do atendimento (nem todo paciente atendido por enfermeira). Caso o paciente seja menor de idade e no possua RG, ento ser necessrio armazenar o RG do responsvel pelo mesmo. Para cada enfermeira desejado armazenar seu nmero, seu nome, sua especialidade, as diversas cirurgias que a enfermeira auxiliou (nem toda enfermeira auxlia em cirurgia) e os diversos pacientes que a enfermeira atendeu (toda enfermeira atende paciente). 7. Uma empresa deseja elaborar um sistema para controlar suas vendas. Para cada vendedor necessrio armazenar seu nome, seu nmero, endereo, os diversos clientes que o vendedor atende (todo vendedor atende clientes) e as diversas notas scais que o vendedor emite (todo vendedor emite notas scais). Para cada cliente necessrio armazenar seu cdigo, nome fantasia, nome da empresa, cgc, os diversos vendedores que atenderam este cliente (todo cliente atendido por vendedor) e todos os pedidos de compra que os clientes emitiram (nem todo cliente cadastrado emite pedido de compra). Para cada pedido de compra desejado armazenar o seu nmero, a data de emisso, o valor total do pedido de compra, o cliente que emitiu o pedido de compra (todo pedido de compra emitido por um cliente), as notas scais geradas para este pedido de compra (todo pedido de compra gera notas scais) e os diversos itens de pedido de compra (todo pedido de compra possui itens de pedido de compra). Cada item de pedido de compra identicado por seu nmero que vai de 1..20 para cada pedido de compra, a quantidade, o valor do item, o pedido de compra ao qual o item pertence (todo item pertence a um pedido de compra) e o produto que o item descreve (todo item de pedido descreve um produto). Para cada nota scal necessrio armazenar seu nmero, sua srie (a numerao varia pela srie), a data de emisso, o valor total da nota, o vendedor que emitiu a nota (toda nota emitida por um vendedor), o pedido de compra que gerou a nota (toda nota gerada por um pedido de compra) e os diversos itens de nota que a mesma contm (toda nota contm itens de nota). Para cada item de nota necessrio armazenar seu nmero que vai de 1..20 para cada nota scal, a quantidade de produto, o valor total do item, a nota scal ao qual o item pertence (todo item pertence a uma nota scal e o produto que o item descreve (todo item de nota scal descreve um produto). Cada produto descrito por seu cdigo, descrio, valor unitrio, os diversos itens de pedido de compra nos quais o mesmo citado (um produto no obrigado a estar citado em um item de pedido de compra) e todos os itens de nota scal nos quais o produto descrito (nem todo produto deve ser descrito em item de nota scal).

3 - Resolver os seguintes exerccios da Bibliograa 2: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.8, 2.14, 2.15, 2.16 e 2.18
27
2.7 Bibliograa
[1] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora. rica, 5 ed., Captulo 4. [2] - Korth, H.; Silberschatz, A. Sistema de Banco de Dados. Editora Makron Books, 3 ed., 1999
Captulo 3 O Modelo Relacional

3.1 Introduo
Criado por Edgar Codd, nos anos 70, comeou a ser realmente utilizado nas empresas a partir de 1987, atravs do SGBDs. A abordagem relacional est baseada no princpio de que as informaes em uma base de dados podem ser consideradas como relaes matemticas e que esto representadas de maneira uniforme, atravs do uso de tabelas, ou falando de uma forma mais direta, um arquivo. Porm, um arquivo mais restrito que uma tabela. Toda tabela pode ser considerada um arquivo, porm, nem todo arquivo pode ser considerado uma tabela. Este princpio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que so as tabelas. O conceito principal vem da teoria dos conjuntos (lgebra relacional) atrelado idia de que no relevante ao usurio saber onde os dados esto nem como os dados esto (transparncia). Os usurios manipulam objetos dispostos em linhas e colunas das tabelas, como mostra a gura a seguir. O usurio pode lidar com estes objetos, conta com um conjunto de operadores e funes de alto nvel, constantes na lgebra relacional. Terminologia do modelo relacional: Tabela chamada de RELAO;

Linha de uma tabela chamada de TUPLA; Coluna chamado de ATRIBUTO; O tipo de dado que descreve cada coluna chamado de DOMNIO.
28
CAPTULO 3. O MODELO RELACIONAL

A gura 3.1 repesenta uma tabela de alunos:
29
RA Nome Ender Telef Idade Tupla Relacao
Atributo
Figura 3.1: Representao de uma tabela no Modelo Relacional Uma relao representada da seguinte maneira: Aluno={Ra, Nome, Ender, Telef, Idade}
3.2 Domnios
O Domnio de um atributo , em geral, um tipo de dado que especica o que o atributo pode receber. Exemplo: Nmero de salas de aula

Conjunto dos nmeros de 1 a 150, inteiros no formato 999. Nomes de alunos Conjunto de todos os nomes possveis para pessoas no formato String[60]. Cdigos de Disciplinas Conjunto de trs letras seguidas de um trao e de trs dgitos:AAA-999. um conjunto de valores atmicos. Valor Atmico signica um valor indivisvel e monovalorado.
3.3 Relaes
Dado o seguinte esquema de uma Relao de Alunos: Aluno = {Nome, RG, Idade} uma possvel instanciao para esse esquema a Relao: R(Aluno)={<Jos, 12345, 21>, <Pedro, 54321, 18>, <Paulo, 32123,22>}
30
Como um esquema de uma Relao R denido como um cojunto, no existe a idia de ordem. Assim, desde que se indique que cada valor Vi corresponde a um atributo Ai, a ordem dos atributos em esquemas de relaes apenas uma questo de disposio fsica. Importante: A instncia de uma relao em um determinado momento, toda a relao no momento, ou seja, uma instncia de Alunos so todos os alunos cadastrados no momento. Se amanh acrescentar mais alunos, a instncia ser todos os alunos antigos mais os novos
3.4 Chave no Modelo Relacional

3.4.1 Superchave
Um cojunto de atributos de uma relao R que identica univocamente cada tupla na relao R chamada uma SUPERCHAVE. Considere a seguinte relao Aluno: Aluno = {Nome, Endereco, Telefone, RA, Idade} Superchave(Aluno)={Nome, Endereco, Telefone, RA, Idade} Superchave(Aluno)={Nome, Endereco} (Considerendo que no existem duas pessoas com o nome em uma residncia) Superchave(Aluno)={Nome, Telefone} Superchave(Aluno)={RA, Nome} Superchave(Aluno)={RA}
mesm
3.4.2 Chave
CHAVE uma Superchave da qual no se pode retirar nenhum atributo e ainda preservar-se a propriedade de identicao unvoca. Exemplo: Aluno = {Nome, Endereco, Telefone, RA, Idade} Superchave(Aluno)={Nome, Endereco, Telefone, RA, Idade}: No chave, pois se retirarmos idade, ainda consiguiremos identicar um nico aluno. Superchave(Aluno)={Nome, Endereco}: chave, pois se retirarmos um atributo no consiguiremos identicar um aluno. Superchave(Aluno)={Nome, Telefone}: chave. Superchave(Aluno)={RA, Nome}: No chave. Superchave(Aluno)={RA}: chave. Em geral, adota-se a conveno de que os atributos chaves so grifados. Se mais de um atributo participa de uma mesma chave, grifam-se esses atributos todos com o mesmo nmero de traos. Exemplo: Aluno = {Nome, Endereco, Telefone, RA, Idade}
31
3.4.3 Chave Candidata

comum que exista mais de uma chave para uma mesma relao. Neste caso, cada uma das chaves chamada de Chave Candidata. Quando existe mais de uma, grifa-se cada chave candidata com um nmero diferente de traos. Exemplo

Aluno = {Nome, Endereco, Telefone,
, Idade}
3.4.4 Restries de Integridade

So regras a respeito dos valores que podem ser armazenados nas relaes que devem ser sempre satisfeitas. Existem 3 que so consideradas necessrias a uma base de dados relacional: Restrio de Integridade da Chave: Uma chave candidata qualquer no pode ter o mesmo valor em duas tuplas distintas da mesma relao.

Restrio de Integridade da Entidade:A chave primria de qualquer relao no pode ser nula em nenhuma tupla dessa relao. Restrio de Integridade Referencial: Informalmente, a restrio de integridade referencial declara que uma tupla em uma relao, que faz referncia a outra relao, deve se referir a uma tupla existente nessa relao. O conceito de Integridade Referencial depende do conceito de Chave Estrangeira.
3.4.4.1 Chave Estrangeira (Integridade Referencial) Uma Chave Estrangeira ocorre quando um conjunto de atributos C R1 que no chave em R1, compatvel com outro conjunto de domnio de atributos D R2 que a Chave Primria da relao R2. Exemplo: Curso={Cod_Cur, Nome, Qtidade_Max_Aluno} Aluno={RA, Nome, Endereco, Idade, Num_Curso} Dom(Cod_Cur) = Dom(Num_Curso) Se (Cod_Cur) Chave Primria de Curso, ento (Num_Curso) Chave Estrangeira em Aluno. Importante: A chave estrangeira pode ter o valor NULO. Nao existe uma representao formal para chave estrangeira. Normalmente, identica-se com um arco direto de cada chave estrangeira relao que ela faz referncia. Para maior clareza, a seta deve apontar para a chave primria da relao referida (gura 3.2). Uma outra maneira colocar a sigla FK (Foreign Key) na frente de cada campo. Neste caso se os nomes dos atributos no forem os mesmos (chave primria com chave estrangeira) ca difcil de identicar de qual relao o atributo chave estrangeira.

32
funcionario = {codFunc, nome, numD
departamento={numDep, descricao, c
Figura 3.2: Representao de Chave Estrangeira 3.4.4.2 Exemplos de Restries de Integridade Aluno={ Nome, RA, Idade} { <Mario, 1234, 20> <Paulo, 4312 18> <Jose, 1212 21> <Marta 3322 19>} Disciplina={ Sigla RA_Monitor} { D-104 1234 D-123 1212 D-149 1234 D-189 NULL} Dom(aluno.RA)=Dom(disciplina.RA_Monitor) Relaes Vlidas: Apesar de RA_Monitor ser chave estrangeira, ela no Chave Candidata. ==================================================================== Aluno={ Nome, RA, Idade} { <Mario, 1234, 20> <Paulo, 4312 18> <Jose, 1212 21> <Marta 3322 19>} Disciplina={ Sigla RA_Monitor} { D-104 1234 D-123 2222 (Errado) D-149 1234 D-189 } Dom(aluno.RA)=Dom(disciplina.RA_Monitor) Relaes Invlidas: Valor 222 para RA_Monitor inexistente na tabela Aluno Integridade Referencial Violada ====================================================================

Aluno={ Nome, RA, { <Mario, 1234, <Paulo, NULL(Errado) <Jose, 1212 <Marta 1212 (Errado) Idade} 20> 18> 21> 19>}
33
Disciplina={ Sigla RA_Monitor} { D-104 1234 D-123 1212 D-149 1234 D-189 NULL} Dom(aluno.RA)=Dom(disciplina.RA_Monitor) Relaes Invlidas: Valor NULL para o atributo RA na relao Aluno e existem duas chaves primrias com o mesmo valor. Integridades de Entidade e de Chave Violadas Respectivamentes
3.5 Outros tipos de Restries

As restries apresentadas so restries do prprio modelo relacioanal. Existem outros tipos, como por exemplo, as restries de integridade semnticas. Os exemplos destas restries so O salrio de um empregado no deve exceder o do supervisor em um banco de dados relacioanal e o nmero mximo de horas que um empregado pode trabalhar por semana em todos os projetos 56. Essas restries podem ser especicadas e impostas dentro dos programas de aplicao que atualizam o banco de dados ou pelo prprio SGBD atravs de Stored Procedure e Triggers. (Estes recursos sero vistos posteriomente no curso). Outro tipo de restrio a dependncia funcional, que estabelece um relacionamento funcional entre dois conjuntos de atributos X e Y. Essa restrio especica que o valor de X determina o valor de Y em todos os estados de uma relao.
3.6 Bibliograa
[1] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora. rica, 5 ed., Captulo 13. [2] - Traina Jr, Caetano Apostila de Modelagem de Dados, USP-So Carlos.
Captulo 4 Mapeamento do Modelo ER para Modelo Relacional

4.1 Introduo
O MER um Modelo Conceitual: Pode ser usado para especicar conceitualmente a estrutura de dados de uma aplicao. O Modelo Relacional um Modelo Lgico (porm bem prximo ao Fsico): uma descrio de um banco de dados no nvel de abstrao visto pelo usurio do SGBD. Assim, o modelo lgico dependente do tipo particular de SGBD que est sendo usado. O Mapeamento permite que se traduzam os esquemas concebidos com um modelo de contedo semntico mais alto para uma implementao utilizando um modelo lgico (ou fsico). O Mapeamento do MER para o Mod. Relacional (MRel) um procedimento executado em 6 passos consecutivos apresentados a seguir.
4.2 Mapeando Entidades

Cada Conjunto de Entidades mapeada como uma relao que envolve todos os atributos do conjunto de entidades. Os atributos CHAVES comporo a chave da relao (gura 4.1).
34
CAPTULO 4. MAPEAMENTO DO MODELO ER PARA MODELO RELACIONAL
35
Nome Aluno RA
Aluno={Nome,RA} Figura 4.1: Mapeamento Entidades
4.3 Entidades Fracas

Conjunto de Entidades Fracas(CEF) so mapeadas numa relao formada por todos os atributos do CEF mais os atributos que so chave das relao ao qual o CEF depende (gura 4.2).
Dependente rg nome idade N possui 1 Funcionario codigo nome telefone
funcionario={codigo, nome, telefone} dependente={rg, nome, idade, codigo_func} Figura 4.2: Mapeamento de Entidades Fracas
4.4 Relacionamento Binrio com Cardinalidade 1:1

Conjunto de Relacionamentos Binrios (CRB) de Cardinalidade 1:1 no so representados como novas relaes. Seus atributos so acrescentados numa das relaes que mapeiam os Conjuntos de Entidades (CE) envolvidos (qualquer uma). Nessa mesma relao inclui-se tambm tambem os atributos chave da relao que mapeia o outro CE (Figura 4.3).
4.5 Relacionamento Binrio com Cardinalidade 1:N

CRB de cardinalidade 1:N tambm no so representados como novas relaes. Seus atributos so acrescentados na relao que mapeia o CE que ocupa o papel de cardinalidade N. Os atributos chave da relao que mapeia o CE que participa com cardinalidade 1 so tabm acrescentados na CE com papel de cardinalidade N (Figura 4.4).

Ementa nome 1 possui 1 Disciplina Sigla nome Num. de Creditos
36
Data Aprov
disciplina = {sigla, nome, num_creditos} ementa = {nome, data_aprov, sigla_discip} Figura 4.3: Mapeamento de Relacionamentos 1:1
Professor codigo nome Horario Num. 1 possui N Disciplina Sigla nome de Creditos
professor={codigo, nome} disciplina={sigla, nome, num_creditos, horario, codigo_prof} Figura 4.4: Relacionamento Binrio com Cardinalidade 1:N
4.6 Relacionamento Binrio com Cardinalidade M:N

Cada CR Binrio de Cardinalidade M:N representado como uma nova relao. Os atributos da relao so os do CR mais os atributos chave das relaes que mapeiam os CEs envolvidos. A Chave da Relao a concatenao dos atributos chaves das relaoes que mapeiam os CEs envolvidos (Figura 4.5).
M N
Aluno ra nome
matriculado
Disciplina Sigla
Nota
nome Num. de Creditos
aluno={ra, nome} | disciplina={sigla, nome, num_creditos} matriculado={ra, sigla, nota} Figura 4.5: Relacionamento Binrio com Cardinalidade M:N
4.7 Relacionamentos Ternrios

Conjuntos de Relacionamentos de ordem maior do que dois com cardinalidade diferente de M:N:P tm um mapeamento complexo. Assim, usualmente se mapeiam os cjs. de Relac. ternrios, quartenrios, etc. como se todos fossem de cardinalidade vrios para vrios para vrios... etc (Figura 4.6).

M N
37
Aluno ra nome
monitora P
Disciplina
Sigla nome
professor
Num. de Creditos
codigo nome
aluno={ra, nome} | disciplina={sigla, nome, num_creditos} | professor={codigo, nome} monitora={ra, sigla, codigo} Figura 4.6: Relacionamento Ternrio com Cardinalidade M:N:P
4.8 Exemplo 1
A gura 4.7 demonstra um exemplo de mapeamento de um DER completo para o modelo Relacional.

Professor cod_prof nome N Monitora M composto 1 N 1 ministra N Turma
38
cod_turma numero_alunos por
Aluno ra nome
matricula
N 1 Disciplina sigla num_credito nome
professor = {cod_prof, nome} | disciplina = {sigla, nome, n_credito} | aluno = {ra, nome} turma = {cod_turma, sigla, n_aluno, cod_prof} | monitora = {cod_prof, ra, cod_turma, sigla} matricula = {sigla, ra} Figura 4.7: Exemplo de DER completo mapeado para o Relacional
4.9 Atributos Compostos e Multivalorados

Os atributos compostos sero decompostos nas relaes e os multivalorados torna-se-o relaes cuja chave primria ser composta pela chave da entidade posuidora do atributo mais o atributo multivalorado (Figura 4.8).

num_funcional Secretaria rua endereco numero
39
telefone
secretaria={num_funcional, rua, numero} | secretaria_endereco={num_funcional, telefone} Figura 4.8: Mapeamento de atributos composto e multivalorado
4.10 Generalizao
A gura 4.9 mostra o mapeamento DER-Relacional de uma Generalizao/Especializao.
num_func Funcionario nome
Secretaria idioma curso
Engenheiro crea
funcionario={num_func, nome, tipo_funcionario} | secretaria = {num_func, idioma, curso} engenheiro={num_func, crea} Figura 4.9: Mapeamento Generalizao/Especializao
4.11 Agregao
A gura 4.10 mostra o mapeamento DER-Relacional de uma Agregao.

valor num_proj Projeto M participa N num_func nome Funcionario
40
M usa N fabricante cod_maq Maquina
projeto={num_proj, valor} | funcionario={num_func, nome} | maquina={cod_maq, fabricante} participa={num_proj, num_func} | usa={num_proj, num_func, cod_maq}
Figura 4.10: Mapeamento Agregao
4.12 Exemplo 2
valor num_proj Projeto M participa N num_func nome Funcionario
M usa N fabricante cod_maq Maquina Tecnico formacao Engenheiro crea
coordena N Atividade
cod_atividade
duracao
projeto={num_proj, valor} | funcionario={num_func, nome} | maquina={cod_maq, fabric}

participa={num_proj, num_func} | usa={num_proj, num_func, cod_maq} tecnico={num_func, formacao} | engenheiro={num_func, crea} atividade={cod_atividade, duracao, num_func}
Figura 4.11: Exemplo 2 de DER completo mapeado para o Relacional
4.13 Resumo dos 6 passos

1. Mapear todos os Cj. de Entidades Regulares do Diagrama ER. 2. Mapear todos os Cj. de Entidades Fracas do Diagrama ER. 3. Mapear todos os Cj. de Relacionamentos 1:1 do Diagrama ER. 4. Mapear todos os Cj. de Relacionamentos 1:N do Diagrama ER. 5. Mapear todos os Cj. de Relacionamentos M:N do Diagrama ER. 6. Mapear todos os Cj. de Relacionamentos Ordem > 2 do Diagrama ER.
41
4.14 Bibliograa
[1] - Traina Jr, Caetano Apostila de Modelagem de Dados, USP-So Carlos. [2] - Setzer, Valdemar Banco de Dados:Conceitos, Modelos, Gerenciadores, Projeto Lgico e Fsico, Editora Edgard Blucher Ltda, 3 ed. [3] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora rica, 5 ed., Captulo 13.
Captulo 5 Normalizao de Relaes

5.1 Introduo
O controle de Consistncia pode ser feito: Pelo SGBD

Pelo Aplicativo Pela prpria construo do sistema
O controle obtido pela prpria construo do sistema , em geral, a melhor, pois no incorre em perda de ecincia durante a execuo. O controle atravs da prpria construo do sistema obtido no Modelo Relacional construindo-se as relaes segundo regras que garantem a manuteno de certas propriedades. As relaes que atendem a um determinado conjunto de regras diz-se estarem em uma determinada Forma Normal.
5.2 Normalizao de Relaes

O processo de Normalizao permite ao programador controlar quanto da consistncia garantida pela maneira de construo do sistema, e quanto deve ser responsabilidade dos aplicativos e/ou SGBD. Normalizar demais diminui a ecincia dos aplicativos e de menos abre acos para inconsistncia. Antes de entrarmos em detalhes sobre as formas normais, vamos olhar alguns problamas de relaes mal normalizadas
5.3 Anomalias de Modicaes

Considere a gura 5.1, ela demonstra uma tabela contndo nome de alunos de uma academia e suas respectivas atividades fsicas com seus respectivos valores. Esta tabela representada pela seguinte relao: cliente = {nome, atividade, taxa} 42
CAPTULO 5. NORMALIZAO DE RELAES

Tabela 5.1: Relao Aluno Nome Atividade Taxa Jos Musculacao 30,00 Pedro Jud 35,00 Manoel Judo 35,00
43
Suponha a tupla do aluno Jos, bem neste caso, perdemos, alm do nome do aluno, as informaes referentes a atividade Musculao, bem como seu valor. Este problema denominado Anomalia de Eliminao. Outro problema ocorre quando a academia implanta um novo curso e no podemos inseri-lo at que um aluno tenha a disposio de faze-lo. Isto denominado Anomalia de Insero. Agora, note que Jud, est grafado de forma errada na tupla do aluno Manoel. Se uma busca for feita por Jud, s ir aparecer 1 aluno e no 2 alunos Denominamos estes problema como Anomalia de Modicao.
5.4 Primeira Forma Normal

As Formas Normais tm nomes pelas quais so conhecidas. Para o modelo relacional, a Forma Normal (FN) mais importnte a chamada 1 forma normal (1FN). Denio da 1FN Uma relao est na 1FN quando todos os seus atributos so Atmicos e Monovalorados. Um atributo atmico aquele que no tratado em partes separadas. Um atributo monovalorado aquele que possui somente um valor (no uma lista). Considere a seguinte relao: cliente={CPF, nome, endereo, (telefone)} A relao Cliente no est na 1FN, porque Nome e Endereco so atributos compostos e telefone um atributo multivalorado. A normalizao desta relao resulta nas seguintes relaes: cliente={CPF, nome, sobrenome, rua, numero_casa, bairro} cliente_telefone = {CPF, DDD, numero_tel} Note que Telefone foi para uma nova relao composta pela chave primria de cliente mais o telefone (decomposto). Todos os atributos da relao Cliente_Telefone fazem parte da chave primria. Outros exemplos

curso = {cod_curso, descricao, (ra_aluno, nome_aluno) obra = {cod_obra, preco, (cidades))
44
De forma geral, para determinar a chave primria de uma tabela originada pela regra da 1FN deve-se proceder como segue: 1. Tomar como parte da chave primria da tabela na 1FN a chave primria da tabela Original. 2. Vericar se esta chave primria suciente para identicar as linhas da tabela na 1FN. (a) Caso seja suciente, a chave primria da tabela na 1FN a mesma que a da tabela Original. (b) Caso contrrio, deve-se determinar quais as demais colunas que so necessrias para identicar as linhas da tabela na 1FN, compondo assim a chave primria na 1FN.
5.5 Dependncia Funcional

Para entender as duas formas normais que sero apresentadas a seguir necessrio compreender o conceito Dependncia Funcional. Dependncia Funcional um relacionamento entre pelo menos dois atributos. Se o valor de um conjunto de atributos A permite descobrir o valor de um outro conjunto B, dizemos que A determina funcionalmente B ou que B depende de A. Denotamos esta rela da seguinte forma: A -> B Exemplo: RA -> Nome, Idade, Curso (Sigla, Sala, Hora) -> Codigo_Turma Importante: As dependncias Funcionais devem ser identicadas pelo projetista do sistema sendo desenvolvido, NO EXISTE MANEIRA DE INFERIR AS DEPENDNCIAS A PARTIR DA DESCRIO DA BASE.
5.6 Segunda Forma Normal (2FN)

A 2 FN est relacionada com as Dependncias Funcionais. Denio da 2FN Uma tabela encontra-se na segunda forma normal, quando, alm de estar na 1FN, no contm Dependncias Funcionais Parciais, ou seja, todos atributos no chave devem depender funcionamente da chave primria composta. Importante: Deve-se vericar a violao da 2FN somente se a relao contiver chaves compostas. Considere o seguinte exemplo:

aluno_disciplina = {ra_aluno, cod_discip, nome_aluno, carga_horar_discip, nota} As dependncias funcionais so: ra_aluno -> nome_aluno cod_discip -> carga_horar_discip (ra_aluno,cod_aluno) -> nota
45
Pela demonstrao das dependncias percebemos que existem atributos que contm dependncia parcial da chave, neste caso, nome_aluno depende ra_aluno e carga_horar_discip depende cod_discip. Isto caracteriza a violao da 2FN, visto que nesta regra no deve-se existir dependncia parcial da chave. A normalizao desta relao caria da seguinte forma. aluno_discipla = {ra_aluno, cod_discip, nota} disciplina = {cod_discip, carga_horar_discip} aluno = {ra_aluno, nome_aluno} A normalizao foi feita da seguinte forma: 1. Mantm-se na tabela original as chaves e os atributos que dependem totalmente dela. 2. Para cada chave que possua atributos dependentes, cria-se uma nova relao, neste caso Aluno e Disciplina. Outros exemplos: projeto_funcionario = {cod_proj, cod_func, nome, categoria, salario, data_ini, temp_proj} onde: (cod_proj,cod_func) -> data_ini, temp_proj cod_func -> nome, categoria, salario cliente_produto = {cpf_cli, cod_prod, nome_cli, end_cli, (telef_cli), valor_unit, qtdade) onde: (cfp_cli, cod_prod) -> qtdade cpf_cli -> nome_cli, end_cli, telef_cli cod_prod -> valor_init
5.7 Terceira Forma Normal (3FN)

A 3FN resolve problemas relacionados com Dependcias Transitivas. Diz-se que um atributo tem dependncia transitiva quando depender de outro atributo que no a chave primria da relao. Observe o exemplo: compra = {cod_compra, cod_cliente, nome_cliente, valor_compra, tel_cliente} cod_compra -> cod_cliente, valor_compra cod_cliente -> nome_cliente, tel_cliente Perceba que o atributo chave primria cod_compra identica os atributos cod_cliente e valor_compra e que o atributo cod_cliente, que no chave primria, identica os atributos nome_cliente e tel_cliente. Ento, tanto nome_cliente como tel_cliente depende transitivamente de um atributo (neste caso cod_cliente) que no chave primria.

Denio da 3FN: Uma Relao est na 3 Forma Normal quando estiver na 1 FN e no existir dependncia transitiva dos atributos. A normalizao de uma relao para a 3FN dar-se pela seguinte maneira: Verica-se um grupo de atributo que depende no diretamente da chave.
46
Retira-se da relao esse grupo de atributos.

Cria-se uma nova relao que contm esse grupo de atributos e inclui-se nela como chave os atributos dos quais esse grupo depende diretamente. Repetem-se esses passos at que todos os atributos restantes na relao original dependam diretamente de toda sua chave.
Exemplos * compra = {cod_compra, cod_cliente, nome_cliente, valor_compra, tel_cliente} compra = {cod_compra, cod_cliente, valor_compra} cliente = {cod_cliente, nome_cliente, tel_cliente}
* chamada_funcionario = {rg_funcion, num_chamado, duracao_chamada, nome_funcion, cod_cidade_chamad nome_cidade_chamada} chamada_funcionario = {rg_funcion, num_chamado, duracao_chamada, cod_cidade} funcionario = {rg_funcion, nome_funcion} cidade = {cod_cidade, nome_cidade}
5.8 Exemplo Prtico

Vamos agora considerar um exemplo prtico, baseado em uma nota sca de compra representada pela gura 5.1.

Numero Nota Fiscal: Codigo do Cliente: Nome do Cliente: Logradouro Cliente (rua, bairro,etc): Cod.Prod Desc.Prod Data da Nota: Telefone Cliente:
47
Qtdade Val.Prod Val.Total
Figura 5.1: Nota Fiscal Considere que um analista mapeou a nota para o seguinte esquema relacional: nota_scal = {num_nota, cod_cliente, nome_cliente, logradouro_cliente, telefone_cliente, data_nota_scal, (cod_produto, desc_produto, qtdade, valor_produto, valor_total)} Ao analisarmos esta relao, notamos que mesma causar problemas de inconsistncia de dados. Bem, para evitarmos futuros problemas, vamos aplicar as formas normais e corrigir erros na relao. 1. Primeira forma normal: A relao no est na 1FN pois existem atributos mutivalorados e compostos. Vamos ento passar para a 1FN: nota_scal = {num_nota, cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente, data_nota_scal} nota_produto = {num_nota, cod_produto, desc_produto, qtdade, valor_produto, valor_total} 2. Segunda forma normal: A relao no est na 2FN pois existem atributos com dependncia parcial da chave primria: nota_scal = {num_nota, cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente, data_nota_scal} nota_produto = {num_nota, cod_produto, qtdade, valor_total} produto = {cod_produto, desc_produto, valor_produto} 3. Terceira forma normal: A relao no est na 3FN pois existem atributos com dependncia transitiva: nota_scal = {num_nota, cod_cliente, data_nota_scal} cliente = {cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente} nota_produto = {num_nota, cod_produto, qtdade, valor_total} produto = {cod_produto, desc_produto, valor_produto} Temos: Dom(cliente.cod_cliente) = Dom(nota_scal.cod_cliente) Dom(nota_scal.num_nota) =Dom(nota_produto.num_nota) Dom(produto.cod_produto) = Dom(nota_produto.cod_produto)
48
5.9 Exerccios
1. Identique, nas relaes abaixo, as dependncias funcionais e se h violao de alguma forma normal (1, 2 e 3), se houver, normalize-as. Obs: Os campos que esto entre (parnteses) , indicam campos multivalorados. (a) Funcionario={RG, nome, endereco, dada_nasc.} (b) Projeto={Codigo, descricao, (cidade),ano} (c) Atleta={ID_Atleta, Nome, numero_entidade_patricinadora, ender_entidade_patrocinadora, sexo, (numero_documento, orgao_expedidor_documento, data_expedicao_documento)} (d) Pedido= {Numero, data, item, descricao_item, quatidade, valor_do_pedido}
(e) Aluno={ RA, nome_aluno, Endereco, cod_professor, nome_professor, cod_disciplina, descricao_disciplina} (g) Salario={RG_Func, nome_funcion, (data_salario, valor)} (h) Gerencia={Cod_Depart, RG_Gerente, descricao_depart} 2. D o conjunto de dependncias funcionais para o esquema relacional R(A,B,C,D) com chave primria nos atributos AB. Sabe-se que a relao est na 1FN mas no est na 2FN. 3. Dena a terceira forma normal. D um exemplo de uma relao em 2FN mas no em 3FN. Transforme a relao em relao em 3FN.
(f) Emprestimo={ Cod_agencia, cidade_agencia, cic_cliente, nome_cliente, (endereco_cliente), valor_emprsti
Captulo 6 lgebra Relacional

6.1 Introduo
A lgebra relacional uma linguagem de consulta procedural. Consiste em um conjunto de operaes que usam uma ou mais relaes como entrada e produz uma nova relao. Importante Toda as operaes da lgebra sobre uma relao produz uma outra relao. Mesmo que a relao resultante seja vazia. As principais operaes so: Seleo

Projeo Unio Diferena Inteseco Produto Cartesiano Juno Diviso
Antes de estudarmos cada uma destas operaes, considere as instncias das relaes que compe o banco de dados:
cod_cli c1 c3 c2 c4
nome_cli rua Joao Rua TT Pedro Rua A4 Marcos Rua XY Maria Rua A
cidade Rio Preto Sao Paulo Sao Paulo Belo Horizonte
cod_agenc ag1 ag4 ag3 ag2
nome_agenc Sao Jose Botafogo Praiana Bom Retiro
gerente cidade Pedro Sao Paulo Manoel Rio de Janeiro Dario So Paulo Pedro Belo Horizonte
49
CAPTULO 6. LGEBRA RELACIONAL

Relao Cliente cod_agenc cod_cli num_conta saldo ag1 c3 101 500 ag2 c2 215 780 ag1 c1 102 400 ag3 c4 305 350 ag3 c3 105 230 Relao Conta Relao Agncia cod_agenc cod_cli num_emprest valor ag3 c4 e100 1500 ag2 c2 e500 800 ag2 c2 e550 100 ag1 c1 e230 1200 ag3 c1 e150 150 Relao Emprstimo
50
6.2 Operao Selecionar ( )

A operao Selecionar seleciona tuplas que satisfazem um dado predicado. representada pela letre grega Sigma ( ). Considere a consulta: Encontre os emprestimos feito na agncia ag2. A resposta em lgebra relacional seria: cod_agenc=ag2 (emprestimo);

O resultado desta consulta traria as seguintes tuplas: cod_agenc ag2 ag2 cod_cli c2 c2 num_emprest e500 e550 valor 800 100
Podemos querer saber todas as contas que possuem saldo maior do que 400 escrevendo: saldo>400(conta);

cod_agenc ag1 ag2
cod_cli num_conta saldo c3 101 500 c2 215 780

Alm disso, diversos predicados podem ser combinados em um predicado maior usando os conectivos AND ( ) e OR ( ). Por exemplo, para encontrar os emprestim os maiores do que 500 e realizados na agncia ag2.

cod_agenc=ag2 cod_agenc ag2
valor > 500 (emprestimo);
cod_cli num_emprest valor c2 e500 800
Geralmente, permitimos as comparaes =,
, <,
, >,
51
6.3 A Operao Projetar ( )

Representada pela letra grega pi ( ), a operao projetar seleciona (projeta)atributos especcos de uma relao. O resultado da projeo uma nova relao com os atributos selecionados. Suponha que desejemos saber o nome de todos os clientes de um banco: nome_cli(cliente);

Teriamos como resposta: nome_cli Joao Pedro Marcos Maria Agora queremos saber o nome dos gerentes e suas respectivas agncias: gerente, nome_agenc(agencia);

gerente nome_agenc Pedro Sao Jose Manoel Botafogo Dario Praiana Pedro Bom Retiro Suponha que desejemos saber o nome de todos os gerentes, sem saber suas agncias: gerente(agencia); gerente Pedro Manoel Dario Note que apareceu apenas um gerente de nome Pedro. Isto se d ao fato que que para a lgebra, uma relao um conjunto de elementos, e eu um conjunto no existem valores repedidos. Podemos combinar as operaes de projeo com seleo. Considere a consulta no qual desejemos os nomes dos clientes que residem em So Paulo: nome_cli ( cidade=Sao Paulo(cliente)); nome_cli Pedro Marcos Ou seno o codigo da agncia e o codigo do cliente cujo saldo da conta seja inferior ou igual a 400:

cod_agenc, cod_cli ( saldo 400(saldo)); cod_agenc ag1 ag3 ag3 cod_cli c1 c4 c3

52
IMPORTANTE As operaes de Projetar e Selecionar so consideradas unrias. Pois operam sobre apenas uma nica relao. As operaes estudadas a seguir devem operar sobre relaes compatveis em domnio, ou seja, devem possuir o mesmo nmero de atributos e os atributos nas colunas correspondentes devem vir do mesmo domnio.
6.4 A Operao Unio ( )

A unio de duas relaes formada pela adio das tuplas de uma relao s tuplas de uma segunda relao, para produzir uma terceira. representada, como na teoria dos conjuntos, pelo smbolo . Como exemplo, queremos saber todos os clientes (cod_cli) que possuem contas ou qaue zeram emprstimos na agncia ag3. Existe duas maneiras de realizar esta consulta: Maneira 1: R1 = cod_cli( cod_agenc=ag3(conta)); R2 = cod_cli( cod_agenc=ag3(emprestimo)); R3 = R1 R2; Maneira 2: cod_cli( cod_agenc=ag3(conta)) Resultado cod_cli c4 c1 c3

cod_cli( cod_agenc=ag3(emprestimo));

6.5 A Operao Interseco de Conjuntos ( )

Esta operao produz atua sobre duas relao compatveis em domnio e produz uma terceira contendo as tuplas que aparecem simultaneamente nas duas relaes. representada pelo smbolo . Consulta: Encontre os codigos dos cliente que possuem contas e que zeram emprestimos.


R1 = cod_cli (conta); R2 = cod_cli (emprestimo); R3 = R1 R2; cod_cli c4 c2 c1

53
6.6 A Operao Diferena de Conjuntos (-)

A diferena de duas relaes uma terceira relao contendo as tuplas que ocorrem na primeira relao mas no ocorrem na segunda. representado pela smbolo -. Considere que desejemos encontrar todos os clientes (cod_cli) que possuem contas mas no zeram emprestimos: R1= cod_cli(conta); R2= cod_cli(emprestimo); R3=R1-R2; cod_cli c3 As operaes a seguir no necessitam ser compatveis em domnio.

6.7 A Operao Produto Cartesiano (X)

O produto de duas relaes a concatenao de todas as tuplas de uma relao com todas as tuplas de uma segunda relao. O produto da relao A (tendo m tuplas) com a relao B (tendo n tuplas) um relao contendo m vezes n tuplas. A representao do produto cartesiano feito pelo smbolo X. Consulta: Encontre o nome dos clientes e o nmero de suas respectivas contas bancrias que possuem saldo maior do que 450: R1= saldo>450(conta); R2=cliente X R1;

cliente. cliente. cliente. cod_cli nome_cli rua c1 Joao Rua TT c1 Joao Rua TT c3 Pedro Rua A4 c3 Pedro Rua A4 c2 Marcos Rua XY c2 Marcos Rua XY c4 Maria Rua A c4 Maria Rua A

54
cliente. conta. conta. conta. conta. cidade cod_agenc cod_cli num_conta saldo Rio Preto ag1 c3 101 500 Rio Preto ag2 c2 215 780 Sao Paulo ag1 c3 101 500 Sao Paulo ag2 c2 215 780 Sao Paulo ag1 c3 101 500 Sao Paulo ag2 c2 215 780 Belo Horizonte ag1 c3 101 500 Belo Horizonte ag2 c2 215 780
R3= nome_cli, num_conta( cliente.cod_cli = conta.cod_cli(R2)); nome_cli num_conta c3 101 c2 215
6.8 A Operao Juno Natural (|X|)

Percebemos na operao de produto cartesiano que foi necessrio realizar uma seleo dos dados (R3= nome_cli, num_conta( cliente.cod_cli = conta.cod_cli(R2));) em cima do produto entre as relaes conta e R1. Alm do mais, um problema que ocorre no produto cartesiano o consumo excessivo de memria. Imagine duas relao onde uma contm 3000 tuplas de 100 bytes cada e outra com 5000 tuplas de 200 bytes cada. Seria necessrio 4.5 mb de memria para armazenar a relao resultante. A operao juno natural as operaes de seleo e produto cartesiano em uma nica operao. representada pelo smbolo |x|. A operao de juno natural forma um produto cartesiano de seus dois argumentos, faz uma seleo forando uma igualdade sobre os atributos que aparecem em ambas relaes e nalmente remove colunas duplicadas. Vamos considerar novamente a consulta no qual desejemos saber o nome dos clientes e suas respectivas contas bancrias que possuem saldo maior que 450. Pode ser realizado de duas maneiras: Maneira 1: R1= saldo>450(conta); R2= nome_cli, num_conta(cliente|x|num_cli=num_cli(R1)); Maneira 2: R1= saldo>450(conta); R2= nome_cli, num_conta(cliente|x|R1) // importante frisar que desta maneira, os atributos de juno esto implcitos no smbolo de juno; nome_cli num_conta c3 101 c2 215

55
6.9 A Operao Diviso ( )

A operao diviso, representada por , retorna as tuplas da relao A que se relaciona com todas as tuplas da relao B ao mesmo tempo. No uma operao importante como as anteriores. Considere a consulta de que querer encontrar todos os clientes (cod_cli) que tem pelo menos uma conta em todas as agncias de So Paulo: R1= cod_agenc( cidade=Sao Paulo(agencia)); cod_agenc ag1 ag3 R2= cod_cli, cod_agenc(conta); cod_cli cod_agenc c3 ag1 c2 ag2 c1 ag1 c4 ag3 c3 ag3

R3 = cod_cli, cod_agenc(R2) cod_cli cod_agenc c3 ag1 c3 ag3
cod_agenc(R1);
56
6.10 Exerccios
Considere as seguintes relaes para resoluo dos exerccios: Relao Empregado
Nome Joo Luiz Fernando Ricardo Jorge RG 101010 202020 303030 404040 CIC 111111 222222 33333 444444 Depto 1 2 3 2 RG_Gerent NULO 101010 101010 202020
Relao Departamento
Salrio 3.000,00 2.500,00 2.300,00 4.200,00 DNome Contabil Eng. Civil Eng. Mecn. DNum 1 2 3 RG_Gerent 101010 303030 202020
Relao Projeto PNum 5 10 20 PValor PLocal 5.000,00 Sao Paulo 7.800,00 Rio Preto 9.500,00 Campinas
Relao Dependente RGResp DepenNome 101010 Jorge 101010 Luiz 202020 Fernanda 202020 Angelo 303030 Andreia
Data_Nasc Parent. 27/12/94 Filho 18/11/93 Filho 14/02/99 Filha 10/02/95 Filho 01/05/00 Filho
Sexo M M F M M
Relao Depart_Projeto Dept_Num Num_Proj 2 5 3 10 2 20
Relao Emp_Proj RG_Emp Num_Proj Horas 202020 5 10 202020 10 25 303030 5 35 404040 20 30
1. Obtenha as seguintes consultas. (a) consulta = dnum>=1(departamento); (b) consulta = rg_gerent=101010(empregado); (c) consulta = nome, rg ( salario <= 2500(empregado)); (d) consulta = dept_num(depart_proj); (e) consulta = rg_emp,num_proj( horas=35 (emp_proj); (f) consulta = depennome( rgresp=202020( sexo="m"(dependentes))); (g) consulta1= nome (empregado); consulta2= depennome (dependentes); consulta3= consulta1 consulta2; (h) consulta = emp_proj X projeto; (i) consulta = empregado|X| rg=rgresp(dependentes) 2. Forme as expresses em lgebra relacional dos seguintes enunciados: (a) Liste o nome de todos funcionrios (b) Liste o valor e a localizao de todos os projetos (c) Liste o nome de todos os departamentos (d) Encontre o nome, rg do responsvel e a data de nascimento de todos os dependentes (e) Encontre o nome de todos os empregados que possuem dependentes


(f) Encontre o nome e salrio dos funcionrios que recebem acima de 2000
57
(g) Consulte os nomes dos empregados que trabalham em todos os projetos controlados pelo departamento 2. (h) Encontre os nomes dos funcionrios que no possuem dependentes (i) Para cada nome de empregado, obtenha o departamento que este gerencia. (j) Com o nome do empregado Ricardo, monte uma pesquisa utilizando a lgebra relacional que mostre os projetos que o funcionrio participa. (k) Monte uma pesquisa em lgebra relacional utilizando o mesmo enunciado acima (enunciado L), porm no utilizando a relao empregado_projeto. (l) Liste o nome dos gerentes que possuem dependentes. (m) Selecione todos os empregados que trabalham no departamento nmero 2 ou que supervisionam empregados que trabalham no departamento nmero 2. 3. Elabore a lgebra relacional para as consultas baseadas nas seguintes relaes. O Aluno pode instanciar as relaes e inserir alguns dados. Reside ={nome_pessoa, rua, cidade} Trabalha ={nome_pessoa, nome_companhia, salrio} Localizado ={nome_companhia, cidade} Gerencia ={nome_pessoa, nome_gerente} (a) D todos os funcionrios que moram na mesma cidade da companhia em que trabalham. (b) D todos os funcionrios que vivem na mesma cidade que seu gerente. (c) D todos os empregados que no trabalham para a empresa "Kangle Corporation"

BD Banco20de20dados

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BD Banco20de20dados

Transféré par

Droits d'auteur :

Formats disponibles

Fundao Educacional de Fernandpolis

Apostila de Banco de Dados

6.9 A Operao Diviso ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

1.1 Sistema de Processamento de Arquivos

Programa para incluir novos registros na contabilidade. Programa parabalano da contabilidade.

1.2 Independncia de Dados

Figura 1.2: Independencia de Dados provida pelo SGBD

1.3 Sistema Gerenciador de Banco de Dados (SGBD)

1.3.1 Caracterticas de um SGBD

1.4 Motivao para SGBDs

Porm traz vantagens muito maiores:

CONSISTNCIA DE DADOS E INDEPENDNCIA DE DADOS

1.4.1 Linguagens de acesso a um SGBD

1.4.2 Arquitetura de um SGBD

Figura 1.3: Arquitetura de SGBD

Captulo 2 O Modelo Entidade-Relacionamento

O VEICULO Corsa; A ALUNA Maria; O CLIENTE Pedro; O PRODUTO A323....

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.1: Exemplos de Entidades

Importante: As instncias de uma entidade no so representadas no DER.

nome data da admisso

Figura 2.2: Represetnao de Atributos

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

2.2.1 Chave Primria

No contm valor NULO.

ALUNO RA Nome Chave Primaria

2.2.2 Atributos Multivalorados

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

2.2.3 Atributos Compostos

2.2.4 Atributo Derivado

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Atributo Composto Sala Numero

codigo data_nasc idade

Figura 2.6: Atributo derivado (representado pela linha pontilhada).

2.3 Entidades Fracas

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Matricula_Funcionario Codigo_Depend 4456 01 4458 01 4456 02

A gura 2.9 representa gracamente a modelagem deste enunciado.

2.4.1 Atributos de Relacionamento

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.8: Representao grca de um relacionamento

2.4.2 Cardinalidade dos Relacionamentos

2.4.3 Grau dos Relacionamentos

2.4.4 Relacionamentos Ternrios

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.10: Atributo de Relacionamento

Muitos) 1 CURSO Muitos)

Pertence M:N (Muitos N Cursa

Figura 2.11: Tipos de Cardinalidade

Como Determinar as Cardinalidades de um Relacionamento Ternrio

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.12: Exemplo de Relacionamento Binrio

DISCIPLINA CORRENTISTA C-C-CM CONTA

Figura 2.13: Exemplo de Relacionamento Ternrio

Funcionrio gerencia Funcionrio

2.5 MER Estendido

2.5.1 Generalizao e Especilizao

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

CLIENTE-ASSOCIACAO: NomeAssociado, Endereco, Taxa CLIENTE-CORPORACAO: PessoaContato, Fone, NumeroIdenticacao

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

INDIVIDUAL Endereco NumPrevSocial

Funcionario nrfunc funcao

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO