M ODELAGEM C ONCEITUAL

1. Introduo ao Modelo Entidade-Relacionamento (MER)

Conforme comentado no captulo anterior, o sistema de banco de dados deve prover uma viso abstrata de dados aos usurios, isolando-os de certos detalhes do BD. A arquitetura desta abstrao se d em trs nveis. O mais externo, o nvel de vises do usurio, descreve partes do banco que sero visualizadas pelos usurios. No nvel intermedirio, tem-se o nvel conceitual (ou lgico), que descreve quais os dados esto armazenados e seus relacionamentos. Finalmente, no nvel mais baixo, est o nvel fsico, descrevendo a forma como os dados esto realmente armazenados. O foco deste captulo um aprofundamento das tarefas do nvel conceitual, atravs da modelagem conceitual dos dados referentes ao negcio. O termo negcio referese ao problema em questo que se deseja realizar uma modelagem. A inteno de armazenar informaes de alunos numa escola, por exemplo, sugere que o negcio seja Registro acadmico. Num outro exemplo, o negcio Instituio financeira poder ser modelado tendo dados de correntistas e saldos. Razes para a criao do modelo conceitual: Descreve exatamente as informaes necessrias ao negcio. Para a modelagem, todas as regras do negcio devero ser conhecidas e, cabe ao projetista, traduzi-las em informaes relevantes ao banco; Facilita a discusso, seja entre o projetista e o usurio ou entre o projetista e sua equipe de trabalho; Ajuda a prevenir erros do futuro sistema; Uma forma de documentar o sistema ideal. Um sistema ideal quando todas suas informaes esto modeladas de acordo com certas condies; a base para o projeto fsico do banco de dados. A abordagem utilizada aqui ser a representao de dados no modelo relacional, utilizando-se, para tal, o Modelo de Entidade-Relacionamento (MER). O MER um modelo baseado na percepo do mundo real, que consiste em um conjunto de objetos bsicos chamados de entidades e nos relacionamentos entre esses objetos. Foi proposto por Peter Chen, em 1976, como uma ferramenta de projeto de banco de dados. O MER apresenta como contribuies um maior grau de independncia de dados que os modelos convencionais (de redes e hierrquico) e uma unificao de representao destes modelos, atravs do formalismo grfico do Diagrama de Entidade-Relacionamento (DER).

PGINA 1 / 16

BANCO DE DADOS I

So caractersticas do MER: Modela regras de negcio e no a implementao. A modelagem dos dados requeridos para o negcio, baseado nas funcionalidades do sistema atual ou a ser desenvolvido. Para modelar um negcio, necessrio conhecer em detalhes sobre do que se trata. Possui uma sintaxe robusta, bem definida; Tcnica amplamente difundida e utilizada. Atualmente, a maioria dos bancos de dados disponveis no mercado utiliza a abordagem relacional como modelo de dados; Diagramas fceis de entender e alterar. Os objetivos de uma modelagem entidade-relacionamento so: Obter todas as informaes requeridas sobre o negcio antes de sua implementao, tornando claras suas dependncias; Dentro do possvel, uma informao aparecer apenas uma vez no banco de dados. Uma modelagem que prev o armazenamento de uma mesma informao em dois locais diferentes, deixa o sistema vulnervel quanto a possibilidade destas informaes no serem as mesmas. No caso de uma inconsistncia dos dados, qual delas dever ser descartada? Facilitar o projeto do banco de dados, possibilitando a especificao de sua estrutura lgica.

2. Entidade e Instncia
Num MER, uma entidade um objeto, real ou abstrato, de relevncia para o negcio. uma categoria de idias que so importantes ao negcio, as quais devem ser traduzidas em informao. Dois importantes aspectos de uma entidade que possui instncias e estas instncias tambm so de interesse ao negcio. Pode-se considerar que uma instncia identifica individualmente uma entidade. O quadro abaixo mostra alguns exemplos de entidades e instncias: Entidade Pessoa Produto Tipo de produto Tarefa Verso do documento Instncia Joo, Jos, Antnio Prego 12x12, File de Peixe Merluza Plstico, papel, madeira Professor, pianista, gerente 1.2, 10.5

QUADRO 2.1 EXEMPLOS DE ENTIDADES E INSTNCIAS Observa-se que uma entidade possui vrias instncias e que cada instncia est relacionada a uma entidade. Uma entidade representa um conjunto de instncias que interessam ao negcio. Segue o exemplo abaixo: Tarefa Gerente Porteiro Pianista Em termos fsicos, uma entidade ser uma tabela do BD e cada instncia ser uma linha (ou registro ou tupla). Exemplo: Tabela Tarefa Cdigo Descrio 405 Gerente 564 Porteiro 321 Pianista Entidade Instncias

PGINA 2 / 16

BANCO DE DADOS I

3. Atributo e Domnio
Um atributo tambm representa algo significativo ao negcio. Um atributo uma propriedade de uma entidade. uma poro de informao que descreve, quantifica, qualifica, classifica e especifica uma entidade. Normalmente, uma entidade possui vrios atributos. Interessa, em termos de modelagem conceitual, que estes atributos representem informaes relevantes ao negcio. Atributos possuem valores (um nmero, um caracter, uma data, uma imagem, um som, etc), chamados de tipos de dados ou formato. Para um atributo particular, todas suas instncias possuem os mesmos formatos. O quadro abaixo apresenta exemplos de entidades, instncias e atributos. Entidade Instncia Atributo Empregado Joo, Antnio Nome, idade, tamanho p, dependentes, cidade Carro Escort, Gol Cor, preo, modelo Tarefa Gerente Cdigo, Depto, Valor/hora, descrio QUADRO 2.2 EXEMPLOS DE ENTIDADES, INSTNCIAS E ATRIBUTOS Algumas questes: O atributo Idade, da entidade Empregado, no parece ser uma boa escolha. O ideal seria Data Nascimento, ficando o clculo da idade quando necessrio. O armazenamento da informao idade de difcil, seno impossvel, atualizao; O atributo Tamanho P, de Empregado, depender das regras de negcio. Imaginando que a finalidade de entidade Empregado seja a de armazenar dados sobre funcionrios numa empresa que fornea uniforme de trabalho, o atributo coerente. Se a empresa no possui esta poltica, ele desnecessrio; Uma importante deciso precisa ser tomada em relao a armazenar uma informao como um atributo ou uma entidade. O atributo Cidade, de Empregado, ter a cidade na qual o empregado reside. Se Cidade fosse uma entidade, alguns possveis atributos seriam Populao, rea e Data Fundao. Aqui, novamente a escolha passa pelas regras de negcio. Normalmente, uma informao ser um atributo se for de natureza atmica e ser uma entidade quando possuir informaes que possam (ou necessitem) ser relacionadas a outras entidades. Em termos fsicos, os atributos sero as colunas de uma tabela do BD. Exemplo: Tabela Empregado Nome Joo Antnio Colunas Idade 32 25

Atributo monovalorado ou atmico: assume um nico valor, num certo instante de tempo, para cada instncia. Exemplo: Nome, de Empregado Atributo composto: formado por um ou mais sub-atributos. Exemplo: Cidade, de Empregado. Cidade pode ser composto pelo nome da cidade e o estado. Atributo multivalorado: assume diversos valores. Seu nome, normalmente, no plural. Exemplo: Dependentes, de Empregado.

PGINA 3 / 16

BANCO DE DADOS I

Atributo determinante: identifica cada entidade como nica. Exemplo: Cdigo, em Tarefa. Domnio de um atributo: conjunto de valores possveis para um atributo. Exemplo: Idade deve estar ente 18 e 60, Estado deve ser RS, RJ, SP, etc.

4. Relacionamentos
uma estrutura que indica uma associao entre duas ou mais entidades. Alguns exemplos: Entidade Empregado Tarefa Produto Tipo Produto Pessoa Reserva Relacionamento Exerce exercida por classificado por um uma classificao de Faz feita por Entidade Tarefa Empregado Tipo Produto Produto Reserva Pessoa

QUADRO 2.3 EXEMPLOS DE RELACIONAMENTOS

Empregado

Tarefa Servente Maria Cozinha Portaria Faxina Pianista

Joo

Pedro Sandra

Todos os empregados exercem tarefas; Nenhum empregado tem mais de uma tarefa; Nem todas as tarefas so exercidas por empregados; Algumas tarefas so exercidas por mais de um empregado.

FIGURA 2.1 EXEMPLO DE RELACIONAMENTO ENTRE EMPREGADO-TAREFA

O exemplo anterior serviu para que sejam apresentadas algumas questes referentes aos relacionamentos entre duas entidades. So elas: 1. Todo empregado DEVE (ou PODE) ter uma tarefa? 2. Toda tarefa DEVE (ou PODE) ser exercida por um empregado? 3. Um empregado pode exercer UMA ou MAIS tarefas? Ou ento: Uma tarefa pode ser exercida por UM ou MAIS empregados? Para as duas primeiras, a anlise do relacionamento de existncia (obrigatrio DEVE ou opcional PODE), enquanto que a terceira trata da cardinalidade do relacionamento (um-para-um, um-para-vrios, vrios-para-um ou vrios-paravrios). Um relacionamento entre duas entidades E1 e E2 deve ser lido da seguinte forma: PGINA 4 / 16

BANCO DE DADOS I

Cada E1 {deve / pode} nome_do_relacionamento {um / vrios} E2

Existncia Cardinalidade

Existncia (Obrigatrio x Opcional) Um relacionamento pode ser obrigatrio ou no. Se ele existe, diz-se que obrigatrio. Se no existe, opcional. A existncia ou no de um relacionamento identificada pelas palavras DEVE e PODE, por exemplo. Sem levar em conta a cardinalidade, as possveis combinaes da relao de existncia entre as entidades Empregado e Tarefa so (observar que a coluna Pode/Deve determinante da existncia do relacionamento):
E1 Cada Cada Cada Cada Empregado Tarefa Empregado Tarefa Pode Deve Deve Deve Pode Pode Nome do relacionamento Exercer Ser exercida por Exercer Ser exercida por E2 Uma/vrias Tarefas Um/vrios Empregados Uma/vrias Tarefas Um/vrios Empregados Obrigatrio Opcional Obrigatrio Obrigatrio Opcional Opcional

QUADRO 2.4 EXISTNCIA DE RELACIONAMENTOS Cardinalidade o nmero de entidades que podem estar associadas. Os relacionamentos binrios podem ser: um-para-um (1:1), um-para-vrios (1:N) ou vrios-para-vrios (N:N). Sem levar em conta a existncia, as possveis combinaes para a cardinalidade do relacionamento entre as entidades Empregado e Tarefa so (observar que a coluna de E2 determinante para a cardinalidade):
Pode Deve Cada Empregado Deve/pode Cada Tarefa Deve/pode E1 Cada Empregado Deve/pode Cada Tarefa Deve/pode Cada Empregado Deve/pode Cada Tarefa Deve/pode Nome do relacionamento Exercer Ser exercida por Exercer Ser exercida por Exercer Ser exercida por E2 Uma Tarefa Um Empregado Uma Tarefa Vrios Empregados Vrias Tarefas Vrios Empregados Cardinalidade Um-para-um 1:1 Um-para-vrios 1:N Vrios-para-vrios N:N

QUADRO 2.5 CARDINALIDADE DE RELACIONAMENTOS

A cardinalidade um-para-um (1:1) ocorre quando uma instncia de E1 est associada no mximo a uma instncia de E2 e uma instncia de E2 est associada no mximo a uma instncia de E1. E1 A1 A2 E2 B1 B2

FIGURA 2.2 CARDINALIDADE UM-PARA-UM PGINA 5 / 16

BANCO DE DADOS I

A cardinalidade um-para-vrios (1:N) ocorre quando uma instncia de E1 est associada a qualquer nmero de instncias de E2, enquanto que uma instncia de E2 est associada no mximo a uma instncia de E1. E1 A1 B2 B3 A2 B4 E2 B1

FIGURA 2.3 CARDINALIDADE UM-PARA-VRIOS A cardinalidade vrios-para-vrios (N:N) ocorre quando uma instncia de E1 est associada a qualquer nmero de instncias de E2 e uma instncia de E2 est associada a qualquer nmero de instncias de E1. E1 A1 A2 A3 E2 B1 B2 B3

FIGURA 2.4 CARDINALIDADE VRIOS-PARA-VRIOS

5. O Diagrama Entidade-Relacionamento (DER)

A estrutura lgica geral de um banco de dados pode ser expressa graficamente por um Diagrama de Entidade-Relacionamento. uma representao grfica do modelo ou parte do modelo. De acordo com o grau de complexidade do negcio ou o nvel de detalhamento impresso pelo projetista do banco, um modelo pode ser representado por vrios diagramas. Um DER utiliza-se de um nmero de elementos grficos. Infelizmente, no existe uma padronizao na representao do diagrama. Sero apresentados dois padres: um deles segundo Peter Chen e o outro uma pequena variao de um desenvolvido pela Oracle. Os componentes do Diagrama de Entidade-Relacionamento, de acordo com Peter Chen so: Retngulos: representam as entidades Elipses: representam os atributos Losangos: representam os relacionamentos Linhas: ligam atributos a entidades e entidades a relacionamentos.

Exemplo de um DER envolvendo Empregados e Tarefas PGINA 6 / 16

BANCO DE DADOS I

Empregado

Exerce

Tarefa

Cod_Emp Nome

Dependentes

Cod_Tar Descrio

Endereo

Rua

Cidade

UF

FIGURA 2.5 EXEMPLO DE DER SEGUNDO PETER CHEN Observa-se o seguinte: So duas as entidades: Empregado e Tarefa Atributos da entidade Empregado: Cod_Emp (determinante - est sublinhado) Nome (monovalorado) Dependentes (multivalorado) Endereo (composto) Rua (monovalorado) Cidade (monovalorado) UF (monovalorado) Atributos da entidade Tarefa: Cod_Tar (determinante - est sublinhado) Descrio (monovalorado) O relacionamento entre Empregado e Tarefa possui cardinalidade 1:n

Uma variao do diagrama anterior apresentada a seguir. Nota-se que os atributos determinantes no mais so sublinhados, pois possuem smbolos diferentes dos demais.

Empregado

Exerce

Tarefa

Cod_Emp Nome Dependentes Endereo

Cod_Tar

Descrio

Rua UF Cidade FIGURA 2.6 UMA VARIAO DE DER

PGINA 7 / 16

BANCO DE DADOS I

A representao adotada neste texto, adaptada de uma desenvolvida pela Oracle, ser apresentada por intermdio de um exemplo.

EMPREGADO Cod_Emp Nome Endereo Rua Cidade UF Dependentes Cod_Tar

possui exercida por

TAREFA Cod_Tar Descrio

FIGURA 2.7 DER ADAPTADO DO PADRO ORACLE Sobre as entidades So duas, Empregado e Tarefa, identificadas por letras maisculas. Abrigam os atributos correspondentes. Sobre os atributos Aqueles determinantes (atributos chave) so sublinhados. Possuem a idia de obrigatrios ou opcionais, identificados, respectivamente, pelos smbolos * (asterisco) e o (crculo). Um atributo obrigatrio quando todas suas instncias de sua entidade possuem a informao conhecida e disponvel, enquanto que opcional quando pode ser desconhecida ou no disponvel ou, ainda, quando conhecida, mas no muito importante para o negcio. Sobre os relacionamentos No possui um smbolo especfico para sua representao. A prpria linha de ligao entre as entidades o relacionamento. O nome do relacionamento colocado prximo ao ponto de partida da entidade.

Sentido Empregado Tarefa Tarefa Empregado

L-se Empregado possui Tarefa Tarefa exercida por Empregado

QUADRO 2.6 NOMES DE RELACIONAMENTOS A cardinalidade do relacionamento identificada pelas extremidades da linha. Do lado do Empregado, o smbolo semelhante a um p de galinha na ponta representa VRIOS, e, do lado da Tarefa, uma ponta simples representa UM. Do DER apresentado, o relacionamento de 1:n. Cada Empregado pode (ou deve) possuir UMA Tarefa Cada Tarefa pode (ou deve) ser exercida por VRIOS Empregados Em relao existncia do relacionamento, ele pode se obrigatrio ou opcional. Os smbolos utilizados para esta identificao so, respectivamente, um trao cortando PGINA 8 / 16

BANCO DE DADOS I

a linha do relacionamento (lado do Empregado) e um crculo sobre a linha (lado do Depto). Cada Empregado DEVE possuir uma Tarefa Cada Tarefa PODE ser exercida por vrios Empregados

Os quadros seguintes mostram as possveis combinaes para relacionamentos envolvendo a questo da existncia, com seus respectivos smbolos.

Relacionamento 1:n

L-se Cada E1 deve existir em vrios E2 Cada E2 deve existir em um E1 Cada E1 pode existir em vrios E2 Cada E2 deve existir em um E1 Cada E1 deve existir em vrios E2 Cada E2 pode existir em um E1 Cada E1 pode existir em vrios E2 Cada E2 pode existir em um E1

Relacionamento n:n

L-se Cada E1 deve existir em vrios E2 Cada E2 deve existir em vrios E1 Cada E1 deve existir em vrios E2 Cada E2 pode existir em vrios E1 Cada E1 pode existir em vrios E2 Cada E2 deve existir em vrios E1

Relacionamento 1:1

L-se Cada E1 deve existir em um E2 Cada E2 deve existir em um E1 Cada E1 deve existir em um E2 Cada E2 pode existir em um E1 Cada E1 pode existir em um E2 Cada E2 deve existir em um E1

QUADRO 2.7 POSSVEIS RELACIONAMENTOS

PGINA 9 / 16

BANCO DE DADOS I

6. Projeto de chaves e Regras de Integridade

A questo fundamental do projeto de chaves numa modelagem eliminar ao mximo os efeitos da redundncia. Uma chave um conjunto de um ou mais atributos que, tomados coletivamente, permite identificar unicamente uma entidade. Numa entidade que contenha mais de uma chave, cada uma chamada de chave candidata. Outros conceitos de chaves so relevantes neste contexto: chave primria (primary key - pk), chave alternativa (alternate key -ak) e chave estrangeira (foreign key - fk). Chave primria: o conjunto de atributos que identificam unicamente uma entidade. o mesmo conceito de atributo determinante, j explicado. Exemplo: a figura 2.7 apresenta os atributos Cod_Emp e Cod_Tar como chaves primrias de suas entidades. Pode-se imaginar, como outro exemplo, uma entidade ALUNO contendo um atributo Nro de Matrcula. Este atributo uma chave primria (primary key - pk), pelo fato de no existir dois alunos dentre os cadastrados com o mesmo Nro de Matricula. Num BD, permitida apenas uma chave primria a cada entidade. Chave alternativa: tambm conhecida como chave secundria, aquela chave candidata que no primria. De acordo com as regras do negcio, s vezes pode ser conveniente identificar entidades por atributos que no so nicos dentre todas as instncias. No exemplo da entidade ALUNO, um atributo Nome srio candidato a ser uma chave alternativa (alternate key - ak). Desta forma, apesar de Nome no garantir que todas as instncias sejam nicas por este atributo (uma mesma pessoa pode estar matriculada em dois cursos. Assim, a chave primria Nro de Matrcula nica dentre todos os alunos, mas Nome ter, pelo menos, em duas instncias), as instncias de ALUNO podem ser recuperadas pela chave alternativa. Pode-se ter tantas chaves alternativas quantas forem necessrias, numa mesma entidade. Chave estrangeira: so atributos de uma entidade cujos valores aparecem como chave primria em outra entidade. A presena de uma chave estrangeira (foreign key - fk) numa entidade ocorre por fora das regras de integridade referencial. As regras de integridade num BD relacional so: 1 regra - Integridade de entidade: nenhum valor de uma chave primria pode ser nulo. Em termos de DER, o atributo pk deve ser sempre obrigatrio, nunca opcional. 2 regra - Integridade referencial: numa entidade que possui uma chave estrangeira, cada valor desta chave s pode ser nulo ou igual a algum valor da pk correspondente no relacionamento. As alteraes dos valores constituintes da pk ou a remoo de uma instncia que contenha uma pk com uma fk associada em outra entidade pode causar problemas de integridade referencial. A figura 2.8 abaixo apresenta um DER e algumas instncias das entidades envolvidas. Este exemplo servir para maiores explicaes sobre o projeto de chaves e as regras de integridade da modelagem.

PGINA 10 / 16

BANCO DE DADOS I

EMPREGADO Cod_Emp Nome Endereo Rua Cidade UF Dependentes Cod_Tar

possui exercida por

TAREFA Cod_Tar Descrio

EMPREGADO Cod_Emp Nome 120 Jalson 343 Cleber 459 Lus 530 Marcela

Cod_Tar 77 42 77 77

TAREFA Cod_Tar 42 12 77

Descrio Secretrio Office-boy Contador

FIGURA 2.8 DER ENTRE EMPREGADO-TAREFA Questes sobre o exemplo: Cod_Emp, de EMPREGADO e Cod_Tar, de TAREFA, so chaves primrias (pk) Cod_Tar de EMPREGADO uma chave estrangeira (fk) As pks so atributos obrigatrios. Pela primeira regra de integridade, portanto, todas as instncias de EMPREGADO e de TAREFA devem estar com esta coluna preenchida. Neste caso, a fk um atributo obrigatrio porque a regra de existncia do relacionamento diz que Cada empregado deve possuir uma tarefa. Poderia ser opcional, caso o relacionamento fosse Cada empregado pode possuir uma tarefa. A remoo da instncia Secretrio, de TAREFA, ou a troca do contedo de Cod_Tar, de TAREFA, de 42 para 39, por exemplo, causa problemas de integridade referencial (segunda regra). A remoo da instncia Office-Boy, de TAREFA, no fere a nenhuma regra de integridade, porque no existe nenhuma instncia em EMPREGADO com fk=12. Em relao a existncia do relacionamento do lado de TAREFA, o fato de ser opcional (Cada Tarefa PODE ser exercida por vrios Empregados), faz que se tenha instncias (Office-Boy) sem necessariamente estar associado a algum empregado.

Uma anlise entre as chaves de entidades e cardinalidade dos relacionamentos (1:1, 1:n ou n:n), leva-nos s seguintes observaes: Num relacionamento 1:1, a fk deve estar em umas das entidades relacionadas. Exemplo: EMPREGADO Cod_Emp Nome Cod_Tar

possui exercida por

TAREFA Cod_Tar Descrio

PGINA 11 / 16

BANCO DE DADOS I

ou EMPREGADO Cod_Emp Nome TAREFA Cod_Tar Descrio Cod_Emp

possui exercida por

Num relacionamento 1:n, a fk deve estar na entidade da direo VRIOS. Exemplo: EMPREGADO Cod_Emp Nome Cod_Tar

possui exercida por

TAREFA Cod_Tar Descrio

Num relacionamento n:n, deve ser criada uma nova entidade contendo como pk as pks das entidades relacionadas. Exemplo:

EMPREGADO Cod_Emp Nome

possui exercida por

TAREFA Cod_Tar Descrio

EMPREGADO Cod_Emp Nome

possui

exercida por

TAREFA Cod_Tar Descrio

EMPREGADO-TAREFA Cod_Emp Cod_Tar

PGINA 12 / 16

BANCO DE DADOS I

7. Normalizao e Regras para a confeco de DER

Conforme j comentado, o esquema de um banco de dados a estrutura geral do BD e, este esquema, pode ser representado de uma forma textual ou grfica. Normalmente, utiliza-se o DER para a representao grfica, ficando a textual como uma opo mais simples e rpida no processo de normalizao dos dados. Para uma modelagem conceitual de dados, necessrio um completo domnio das regras de negcio, de modo que o modelo resultante reflita numa estrutura que melhor represente os objetos envolvidos. Tm-se duas alternativas para a criao de modelos conceituais: uma delas atravs da normalizao de dados e, a outra, por umas regras bsicas de identificao dos elementos do DER na idia geral do negcio. Normalizao de Dados Consiste em definir o formato lgico adequado s entidades identificadas no negcio, com o objetivo de minimizar o espao utilizado pelos dados e garantir as regras de integridade e a confiabilidade das informaes. A normalizao feita atravs da anlise dos dados que compem as entidades, utilizando um conceito chamado Formas Normais (FN). As FN so conjuntos de restries nos quais os dados devem satisfaz-las. Pode-se dizer que a estrutura est na primeira forma normal (1FN), se os dados que a compem satisfizerem as restries definidas para esta etapa. A normalizao completa dos dados feita seguindo as restries das trs formas normais existentes, sendo que a passagem de uma FN para outra feita tendo como base o resultado obtido na etapa anterior, ou seja, na FN anterior. Para realizar a normalizao dos dados, so imprescindveis as definies dos atributos chave a cada entidade e ser adotada a representao textual. Como exemplo, criar um modelo conceitual para armazenar os dados de um boletim escolar, conforme a figura 2.9 abaixo: ESCOLA ESTADUAL BARO DE MACABAS www.eebm.com.br

Aluno: FRANCISCO JOS GUSMES LIMA Matrcula: 6969 Ano letivo: 2004 Endereo: RUA DAS ACCIAS, 465, CARREIROS, SO FIDLIS - RJ Filiao: GERALDO TENRIO LIMA Curso: 45 INFORMTICA FELICIA MARIA GUSMES LIMA Turno: DIURNO Disciplina 13 - LGICA 08 - BDADOS Turma I A C II NOTAS III IV Ex I 0 3 FALTAS II 4 3 III IV 6 0 0 0 7,0 6,9 23 35 10 9 Aprov Aprov MF TA TF Cond.

7,0 8,0 6,0 7,0 5,0 4,0 9,0 8,0 8,0

As notas I, II, III e IV referem-se aos quatro bimestres. A nota Ex a nota do exame As faltas I, II, III e IV referem-se aos quatro bimestres. MF a Mdia Final, TA o Total de Aulas dadas, TF o Total Faltas e Cond condio de aprovao FIGURA 2.9 EXEMPLO DE UM BOLETIM ESCOLAR EMPREGADO-TAREFA

PGINA 13 / 16

BANCO DE DADOS I

Primeira Forma Normal (1FN) Consiste em retirar da entidade os elementos repetitivos, ou seja, aqueles dados que podem compor uma estrutura de vetor. Pode-se afirmar que uma entidade est normalizada na 1FN, se no possuir atributos repetitivos. Do exemplo, pode-se iniciar pensando numa nica entidade chamada BOLETIM, com o seguinte esquema: BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno, Relao de Disciplinas (Cod Disc, Nome Disc, Turma, Relao de Notas (I, II, III, IV, Ex), Relao de Faltas (I, II, III, IV), MF, TA, TF, Cond)).

necessria a definio de uma pk para BOLETIM. Como o assunto trata de boletins escolares e cada aluno possui um, o atributo Nro Matricula apresenta-se como um forte candidato a chave primria. Da entidade, observa-se que existem vrias disciplinas para cada aluno, sendo, portanto, elementos repetitivos que devero ser retirados. Ento, a primeira forma normal ser:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno) MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma, Relao de Notas (I, II, III, IV, Ex), Relao de Faltas (I, II, III, IV), MF, TA, TF, Cond))

Como resultado desta etapa, ocorre um desdobramento dos atributos da entidade, a saber: Em BOLETIM, foram extrados os atributos repetidos; Em MATRICULA, os atributos foram os extrados de BOLETIM, tendo como chave primria Nro Matrcula e Cod Disc. Esta pk, em MATRICULA, nica. Em MATRICULA, nota-se ainda uma repetio de notas e de faltas, que podero dar origem a novas entidades. Por uma deciso de projeto, as entidades ficam:

BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno) MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma, MF, TA, TF, Cond) NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre, Nota, Falta) PGINA 14 / 16

BANCO DE DADOS I

Aqui, mais uma vez, a nova entidade NOTA e FALTA tem sua pk composta da pk de MATRICULA acrescentada de Id Bimestre, uma identificao do bimestre. Segunda Forma Normal (2FN) Consiste em retirar, das entidades que possuem chaves compostas (atributo chave formado por mais de um atributo), os atributos que so funcionalmente dependentes de parte da chave. Pode-se afirmar que, uma entidade est na 2FN, se estiver na 1FN e no possuir atributos funcionalmente dependentes de parte da chave. (1FN) BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno) MATRICULA (Nro Matrcula, Cod Disc, Nome Disc, Turma, MF, TA, TF, Cond) NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre, Nota, Falta)

A ltima configurao das entidades as apresenta na 1FN. Pode-se notar MATRCULA como a nica entidade que possui uma pk composta com atributos dependentes (Nome Disc depende de Cod Disc). A segunda forma normal, ento, define: BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno) MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF, Cond) DISCIPLINA (Cod Disc, Nome Disc) NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre, Nota, Falta)

Da ao da 2FN, tem-se: Surgiu a nova entidade DISCIPLINA, tendo como pk parte da pk do atributo originrio constante na dependncia. O atributo Nome Disc foi excludo de MATRICULA por ser dependente de Cod Disc.

PGINA 15 / 16

BANCO DE DADOS I

Terceira Forma Normal (3FN) Consiste em retirar os atributos que so funcionalmente dependentes de outros atributos que no so chaves. Pode-se afirmar que, uma entidade est na 3FN, se estiver na 2FN e no possuir atributos dependentes de outros atributos no chaves. (2FN) BOLETIM (Nome Escola, Http Escola, Nome Aluno, Nro Matrcula, Ano Letivo, Endereo, Pai, Me, Cod Curso, Nome Curso, Turno) MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF, Cond) DISCIPLINA (Cod Disc, Nome Disc) NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre, Nota, Falta) (3FN)

BOLETIM (Nro Matrcula, Nome Aluno, Endereo, Pai, Me, Cod Curso, Turno) CURSO (Cod Curso, Nome Curso) MATRICULA (Nro Matrcula, Cod Disc, Turma, MF, TA, TF, Cond) DISCIPLINA (Cod Disc, Nome Disc) NOTA e FALTA (Nro Matrcula, Cod Disc, Id Bimestre, Nota, Falta)

A ao da 3FN provocou poucas alteraes; surgiu uma nova entidade CURSO e o atributo Nome Curso, de BOLETIM, foi eliminado. Os demais ajustes foram em decorrncia de uma melhoria da modelagem. So eles: Atributo Ano Letivo foi eliminado do modelo por no se relacionar com nenhuma entidade existente. Em termos prticos, pode-se imaginar que todos os dados referentes ao ano letivo fiquem armazenados em BD diferentes, mas com a mesma estrutura (um BD para o ano 2001, outro para 2002, ...). Os dados da escola no so relevantes nesta modelagem porque so constantes, ou seja, so iguais a todos os boletins.

PGINA 16 / 16