Projeto lgico de bancos de dados

Apostila elaborada pelo Professor Antonio Cesar de Barros Munari FEV/1998 Revisada: MAR/2002

ndice

Introduo Conceitos bsicos dos bancos de dados relacionais Regras de integridade fundamentais no modelo relacional Outras regras de integridade Mapeamento E/R para bancos de dados relacionais Atribuio de nomes Tipos de dados Regras bsicas de mapeamento Anlise de Relacionamentos Normalizao de tabelas Primeira forma normal Segunda forma normal Terceira forma normal Roteiro para normalizao de dados Referncias bibliogrficas

1 2 7 8 10 10 11 12 14 18 18 19 20 21 22

Projeto lgico de bancos de dados

Introduo
O projeto lgico constitui a fase imediatamente posterior modelagem conceitual do banco de dados, e procura detalhar a forma como as entidades, atributos e relacionamentos sero representados no banco de dados. , por esse motivo, dependente da tecnologia que ser utilizada, ao contrrio do que ocorre com a modelagem conceitual. Assim, importante saber se o banco de dados ser criado, por exemplo, usando a abordagem relacional, objetorelacional ou orientada a objetos e, num segundo momento, tambm qual seria exatamente o produto SGBD a ser adotado, j que uma grande parte do detalhamento depende de caractersticas que costumam variar entre um e outro SGBD. Existe ainda uma terceira fase, teoricamente subseqente ao projeto lgico, denominada projeto fsico, onde h o detalhamento dos dispositivos e recursos fsicos a serem alocados para suportar o contedo proposto para o banco de dados, tais como ndices, clusters, discos, etc. Esse projeto fsico, entretanto, muitas vezes sobrepe-se parcialmente ao projeto lgico (principalmente devido s caractersticas e recursos oferecidos por algumas ferramentas CASE utilizadas para o projeto lgico, que freqentemente misturam elementos das duas fases), e em parte com a fase de programao e de ajuste de desempenho, devido prpria natureza iterativa do processo de desenvolvimento. Em geral, considera-se que um bom projeto lgico, no nvel das definies que sero feitas a seguir, suficiente para a gerao e documentao de bons esquemas de bancos de dados. Apesar de a tecnologia orientada a objeto ser alvo de intensa pesquisa e divulgao nos ltimos tempos, fato que a esmagadora maioria das implementaes de bancos de dados ainda utiliza a abordagem relacional, que por esse motivo ser a adotada neste material. Isso significa que o projeto lgico passar a ser ento, para toda a discusso subseqente, o mapeamento de entidades e relacionamentos para tabelas e chaves estrangeiras e de atributos para colunas.

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

Conceitos bsicos dos bancos de dados relacionais

Em um ambiente de banco de dados relacional utilizamos alguns conceitos muito importantes, imprescindveis para a correta implantao e operao de qualquer sistema de banco de dados. Alguns desses novos termos originaram-se diretamente da teoria de Conjuntos, outros so decorrentes da utilizao de elos lgicos para implementar os relacionamentos entre os dados armazenados no banco de dados. A seguir ser apresentada uma rpida viso desses conceitos fundamentais. Tabela: A estrutura que armazena os dados referentes a cada uma das ocorrncias de uma entidade ou relacionamento com atributos uma tabela ou seja, a tabela a materializao para o SGBD desses objetos conceituais. Assim, ao projetarmos um banco de dados relacional a partir de um modelo Entidade / Relacionamento criamos uma tabela para cada entidade ou relacionamento com atributos. As tabelas so tambm chamadas de relaes (no sentido proposto pela Teoria dos Conjuntos). Uma tabela composta por colunas e linhas (ou tuplas, segundo a Teoria dos Conjuntos), conforme ilustra o exemplo a seguir. Nome da tabela: FUNCIONARIO Linha NrMatric 1001 1004 1034 1021 1029 1095 1023 1042 1048 1015 NmFunc JOAO SAMPAIO LUCIO TORRES ROBERTO PEREIRA JOSE NOGUEIRA RUTH DE SOUZA MARIA DA SILVA LUIZ DE ALMEIDA PEDRO PINHEIRO ANA SILVEIRA PAULO RODRIGUES DtAdm 10/08/93 02/03/94 23/05/92 10/11/94 05/01/92 03/09/92 12/01/93 29/07/94 01/06/93 17/08/92 VrSalario CdCargo CdDepto 750 C2 750 C2 450 C3 450 C3 350 C1 600 C4 750 C2 600 C4 2300 C5 750 C2 D2 D2 D1 D1 D3 D1 D2 D1 D1 D2

Coluna
Figura 1: Conceitos de tabela, linha e coluna.

Esses conceitos bsicos so freqentemente indicados por mais de uma termo, devido tanto a razes conceituais como culturais e histricas, e muitas vezes acaba havendo alguma confuso com relao a terminologia adotada. A tabela a seguir, extraida de [MELO et al.,
Antonio Cesar de Barros Munari 2

Projeto lgico de bancos de dados 1997], procura resumir a equivalncia dos principais termos utilizados para retratar esses conceitos em diversas situaes. Contexto Modelo (formal) Terminologia Relacional Relao Tupla Linha Elemento estruturado (lista) Registro Registro Atributo Coluna Componente de lista Campo Campo

Modelo Relacional Tabela (informal) e SQL Teoria de conjuntos Conjunto e Estrutura de dados Anlise estruturada Depsito de Dados moderna Processamento dados de Arquivo

Tabela 1: Terminologia de conceitos bsicos do Modelo Relacional em diversos contextos

Linha: Uma ocorrncia em particular de dados em uma tabela ocupa uma linha dessa tabela. No exemplo anterior, os dados de um empregado ocupam uma linha na tabela Funcionario. Como existem 10 empregados nessa tabela, ela possui 10 linhas (ou tuplas, ou registros). Coluna : Cada tipo de informao armazenada em uma tabela uma coluna. Toda coluna de uma tabela deve possuir um nome pelo qual ser referenciada sempre que necessrio. Ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome e tambm o seu tipo (numrico, alfabtico, data, etc). Por exemplo, NmFunc e DtAdm so colunas (ou campos) da tabela Funcionario. Essa tabela possui um total de 6 colunas em sua estrutura. Domnio: Sempre que identificamos um atributo de uma entidade, temos tambm uma idia de qual o tipo de informao que ele poder vir a conter. Por exemplo, se reconhecemos Sexo como sendo um atributo de uma entidade qualquer, sabemos de antemo que a informao ali contida ser, sempre, "Masculino" ou "Feminino". De forma semelhante, se um atributo for Estado, com certeza seu contedo ser a sigla ou o nome de um dos Estados do Brasil. Chamamos a essa faixa de valores que um atributo pode conter de domnio desse atributo. Assim, para o atributo Dia do Ms, o domnio ser o conjunto de nmeros entre 1 e 31; o domnio de um atributo Salrio ser o conjunto de nmeros entre 0 e o teto salarial estipulado pela empresa, e assim por diante.

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

M F

1 5 9 (...) 27 31

2 6 10 28

3 7 11 29

4 8 12 30

CdInquilino 0001 0002 0004 (...) 0133

NmInquilino CLAUDIO SANTOS ANA FIGUEIREDO SILVIO CORREIA (...) JANETE MOREIRA

Sexo M F M (...) F

UF SP RJ SP (...) RS

(...) Dia DurContr (...) 12 6 (...) 5 3 (...) 23 12 (...) (...) (...) (...) 30 4

SP

RJ MG RS PR

1 4 7 10

2 5 8 11

3 6 9 12

SC

ES

Figura 2: Exemplos de domnios simples (discretos).

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

C5 C1 C4 C3 C2

D1 D2 D3

NrMatric 1001 1004 1034 (...) 1015

NmFunc JOAO SAMPAIO LUCIO TORRES ROBERTO PEREIRA (...) PAULO RODRIGUES

DtAdm 10/08/93 02/03/94 23/05/92 (...) 17/08/92

VrSalario 750 750 450 (...) 750

CdCargo C2 C2 C3 (...) C2

CdDepto D2 D2 D1 (...) D2

750 2300 (...) 200 50

350 450 600 (...) 1200

Figura 3: Outros exemplos de domnios (contnuos e discretos).

Chave primria : Um dos princpios do modelo relacional diz que uma linha de uma tabela deve sempre poder ser referenciada de forma nica. O atributo diferenciador (que no se repete) entre as linhas de uma tabela chamado de chave primria, que no caso da tabela Funcionario, por exemplo, poderia ser a coluna NrMatric, j que essa informao no se repete para dois funcionrios distintos. Muitas vezes, porm, uma entidade no possui, entre seus atributos, um que por si s seja suficiente para identificar univocamente uma ocorrncia. Nesses casos deve sempre ser possvel que a combinao de dois ou mais atributos tenha a capacidade de se constituir numa chave primria. Chamamos a essas chaves primrias formadas pela combinao de vrios atributos de chaves primrias compostas.
Antonio Cesar de Barros Munari 5

Projeto lgico de bancos de dados Chave estrangeira: Os relacionamentos entre tabelas so implementados no modelo relacional atravs de atributos de relacionamento. Essa tcnica consiste na distribuio de alguns atributos-chave pelas tabelas que representam as entidades envolvidas no relacionamento, de forma que seja possvel a associao lgica entre as linhas das tabelas com base na comparao de suas chaves. Na prtica uma chave estrangeira uma coluna (ou combinao de colunas) que indica um valor que deve existir como chave primria numa outra tabela (chamada de Tabela Pai). No caso da tabela Funcionrio existem duas chaves estrangeiras: as colunas CdCargo e CdDepto que referenciam, respectivamente, as tabelas de Cargos e de Departamentos. NrMatric NmFunc 1001 1004 1034 1021 1029 1095 1023 1042 1048 1015 JOAO SAMPAIO LUCIO TORRES ROBERTO PEREIRA JOSE NOGUEIRA RUTH DE SOUZA MARIA DA SILVA LUIZ DE ALMEIDA PEDRO PINHEIRO ANA SILVEIRA PAULO RODRIGUES DtAdm 10/08/1993 02/03/1994 23/05/1992 10/11/1994 05/01/1992 03/09/1992 12/01/1993 29/01/1994 01/06/1993 17/08/1992 VrSalario 750 750 450 450 350 600 750 600 2300 750 CdCargo C2 C2 C3 C3 C1 C4 C2 C4 C5 C2 CdDepto D2 D2 D1 D1 D3 D1 D2 D1 D1 D2

CdCargo C1 C3 C7 C2 C5 C4

NmCargo COZINHEIRA AUX. ESCRITORIO VIGIA MECANICO GERENTE ESCRITURARIO CdDepto D1 D2 D3 D4 NmDepto ADMINISTRACAO OFICINA SERVICOS GERAIS VENDAS

Figura 4: Exemplo de chaves estrangeiras para a tabela de funcionrios.

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

Nulo: Representa um valor desconhecido para um dado. No devemos confundir o conceito de nulo com espaos em branco ou o nmero zero, por exemplo, que so valores conhecidos. Nulo a ausncia de informao. Uma coluna de preenchimento obrigatrio numa tabela deve possuir todos os seus valores no-nulos. Se, por exemplo, uma linha da tabela Funcionrio contiver um nulo na coluna DtAdm, significa que a data de admisso do funcionrio correspondente quela linha desconhecida. NrMatric NmAluno 22941010 22941012 (...) 22941088 CLAUDIO SILVA ANA RIBEIRO (...) JOSE SANTOS (...) (...) (...) (...) (...) Sexo M F (...) M RG 21212121 14141414 (...) 34343434 Reservista 91929 ?! ?! ?! ?! (...) 828122

Figura 5: Exemplo de atributo com valor nulo permitido (Reservista).

Regras de integridade fundamentais no modelo relacional O modelo relacional, ao definir conceitos como Tabela, Coluna, Nulo, Domnio, Chave Primria e Chave Estrangeira, deixa implcitas algumas regras fundamentais para a manuteno da consistncia da base de dados. Elas so chamadas de Regras de Integridade e tratam dos cuidados que analistas, projetistas e programadores devem observar ao implementar as rotinas de Incluso, Alterao e Excluso de dados nos objetos. Consideramos que existem dois principais tipos de integridade a serem mantidas numa base de dados relacional adequadamente projetada: a Integridade de Entidade e a Integridade Referencial. Integridade de Entidade (ou de Identidade ou Existencial) : Refere-se s chaves primrias e procura garantir que toda e qualquer linha de uma tabela deve poder ser acessada com base apenas no contedo de sua chave primria. Regra bsica: "Nenhum atributo que faa parte de uma chave primria pode ter valor nulo." Isso significa que os contedos de todos os atributos que constituem uma chave primria devem ser conhecidos. Um contedo nulo representa uma informao desconhecida ou, em outras palavras, a ausncia da informao, o que no pode ser permitido em qualquer elemento de uma chave primria. Adicionalmente lembramos que, por definio, no se deve permitir que numa mesma tabela existam duas ocorrncias com chaves primrias iguais. Integridade Referencial: Diz respeito s chaves estrangeiras e visa manter a integridade dos relacionamentos previstos na base de dados. Na definio dos cuidados referentes a esse tipo de integridade, utilizaremos dois conceitos novos: Tabela-Pai (Parent Table): aquela onde o atributo de relacionamento desempenha o papel de chave primria.

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento desempenha o papel de chave estrangeira. Regra bsica: "O contedo de uma chave estrangeira deve, necessariamente, ser igual ao de uma ocorrncia da Tabela-Pai ou ento ser nulo." O primeiro caso mencionado pela regra significa que a ocorrncia da Tabela-Filho possui uma correspondente na Tabela-Pai. J o segundo caso representa a ausncia da correspondncia: para aquela ocorrncia em particular, no existe o relacionamento. As conseqncias da Integridade Referencial refletem-se nas consistncias necessrias ao se proceder s operaes de Incluso, Alterao e Excluso de dados nas Tabelas Pai e Filho. isso o que mostra o quadro a seguir. Operao Tabela-Pai Incluso No afeta. Tabela-Filho No pode incluir se no tiver na Tabela-Pai

Alterao Se envolver a chave primria, utilizar Se envolver a chave estrangeira, um dos seguintes critrios: s aceitar valores que existam na Tabela-Pai no alterar se tiver dependentes; alterar e colocar nulos nas chaves estrangeiras de todos os dependentes da Tabela-Filho; alterar e colocar o novo valor nas chaves estrangeiras de todos os dependentes na Tabela-Filho. Excluso Utilizar um destes 3 critrios: no deletar se tiver dependentes; deletar e colocar nulos nas chaves estrangeiras da Tabela-Filho; deletar e tambm eliminar todos os dependentes.
Tabela 2: Implicaes da integridade referencial nas operaes de gravao em tabelas.

No afeta.

Outras regras de integridade Alm das regras de integridade de entidade e referencial, um banco de dados relacional pode suportar um conjunto adicional de regras (ou restries) cuja finalidade especificar aspectos prprios de cada coluna e respectivo domnio, complementando com isso a definio de suas caractersticas lgicas. As principais restries de integridade complementares tratam sobre a obrigatoriedade e unicidade de valores e sobre conjuntos de valores permitido.
Antonio Cesar de Barros Munari 8

Projeto lgico de bancos de dados Obrigatoriedade: indica se deve ou no ser permitida a existncia de nulos numa coluna. Colunas que no aceitam nulos so ento de preenchimento obrigatrio como, por exemplo, o nome de um funcionrio na tabela de funcionrios da figura 4, enquanto que a coluna Reservista no obrigatria na tabela de alunos da figura 5. Unicidade: indica se deve ser permitido ou no que uma coluna possua valores idnticos em duas ou mais linhas. Uma coluna que no pode possuir valores repetidos uma coluna de valores nicos. Um exemplo de coluna de valores nicos a coluna RG na tabela de alunos da figura 5 enquanto que, nessa mesma tabela, a coluna Sexo no de valores nicos, pois deve aceitar valores repetidos. Verificao de valores especficos: indica explicitamente qual o conjunto de valores permitidos para uma coluna. Por exemplo, para a coluna Sexo da tabela de alunos da figura 5, os valores permitidos so { M, F}.

Antonio Cesar de Barros Munari

Projeto lgico de bancos de dados

Mapeamento E/R para bancos de dados relacionais

O conjunto de objetos de banco de dados que implementam um modelo de dados especfico chamado de esquema do banco de dados. Em princpio ele composto pelas tabelas que devero armazenar as informaes necessrias, mas ao final do projeto, objetos de outros tipos acabam tambm sendo necessrios, como ndices, regras e subrotinas, por exemplo. As recomendaes apresentadas a seguir procuram organizar a abordagem que o projetista de um banco de dados precisa adotar ao desenvolver um projeto lgico. Atribuio de nomes As tabelas e colunas que constituiro o banco de dados devem receber nomes prprios, que precisam seguir as regras de formao de nomes especficas de cada produto, e que algumas vezes so bastante restritivas, conforme indica o quadro apresentado a seguir. Isso significa que nem sempre ser possvel adotar no esquema das tabelas os mesmos nomes utilizados no modelo E/R. Alm disso, h tambm pelo menos dois outros motivos para no se repetir cegamente no esquema do banco de dados os mesmos nomes do modelo conceitual: com a mudana do nvel de abstrao empregado, h uma correspondente (mesmo que ligeira) modificao dos significados de alguns elementos, que acabam inevitavelmente requerendo adaptaes ou, muitas vezes, levam ao desmembramento de um atributo em mais de uma coluna e, em segundo lugar, inegvel que nomes curtos so sempre mais prticos que nomes longos, principalmente quando se trata de programao. Um clssico exemplo de variao na nomenclatura entre o modelo conceitual e o modelo lgico o dos nomes das tabelas que, em geral, so substantivos no plural ao contrrio do que ocorre com as entidades, costumeiramente batizadas por meio de substantivos no singular.A preocupao com o emprego de bons critrios para a atribuio de nomes deve ser permanente, levando documentao das convenes adotadas, principalmente no que se refere a padres de abreviatura, grafia e regras para a gerao de nomes compostos. Num outro plano, todo o esquema lgico deve ser documentado num dicionrio de dados, indicando o nome de cada objeto do banco de dados, sua finalidade e estrutura, pelo menos.
Padro SQL Ansi Aspecto Tam. nome tabela Tam. nome coluna Caracteres permitidos
92 128 128

DBF
III+ *** 10

Paradox
7 *** 25

MSAccess
2000 64 64

Oracle
8 30 30

MS-SQL Server
7 128 128 Letras, nmeros, underscore, cifro e number (#).

Interbase
4.2 31 31

MySQL
3.23 64 64

P/ colunas, Tudo Letras, tudo exceto: exceto: nmeros, vrgula; ponto dec; underscore, pipe; exclamao; cifro e exclamao. acento number (#). grave; P/ tabelas: P/ tabelas: colchetes. *** *** Primeiro Espaos em Primeiro Primeiro Primeiro Obs. caracter branco e caracter no caracter no caracter deve ser pontuaes pode ser um pode ser um deve ser uma letra. no so espao espao uma letra. permitidos *** Varia conforme o sistema de arquivos do sistema operacional

Letras, Letras, nmeros e nmeros e underscore. alguns caracteres especiais.

Letras, Tudo, nmeros, exceto: underscore ponto dec. e cifro. P/ tabelas tb no permite usar contrabarras. Primeiro Primeiro Nomes no caracter caracter podem ser deve ser deve ser compostos letra ou uma letra. apenas por underscore. nmeros.

Tabela 3: Regras de nomes em alguns SGBDs relacionais. Antonio Cesar de Barros Munari 10

Projeto lgico de bancos de dados Tipos de dados O detalhamento de uma tabela deve apresentar todas as colunas, juntamente com seu tipo de dados e, quando necessrio, o tamanho correspondente. Novamente, as diferenas entre cada SGBD so marcantes, conforme mostra o quadro a seguir, que rene os tipos de dados de uso mais comum em uma variedade de produtos de banco de dados.
Padro SQL Ansi
92

DBF
III+

Paradox
7

MS-Access
2000 Text Memo

Oracle
8 Char Varchar2 Long Date Date Number BLOB

MS-SQL Server Interbase MySQL

7 Char Varchar Datetime Datetime Numeric Int Real Money Bit Varbinary 4.2 Char Varchar Date Date Numeric Integer Float BLOB 3.23 Char Varchar Datetime Datetime Numeric Integer Double BLOB

Tipo Texto Data Hora Nmero

Char Varchar

Character Alpha

Date Time Numeric Integer Float Moeda Lgico Contador Binrios

Date Numeric Logic -

Date Time

Datetime Datetime Long Integer Long Number Double Money Currency Logical Bit Autoincrement Counter Bynary LongBinary

Tabela 4: Principais tipos de dados suportados por alguns SGBDs relacionais.

Exemplo: Entidade
PRODUTO @ Cd. Prod. Nome Preo Unit. Qtde Estoque Data ltima compra

Tabela de produto no formato DBF Coluna CdProd NmProd VrUnit QtEstoque DtUltCompr Tabela de produto no formato Paradox Coluna CdProd NmProd VrUnit QtEstoque DtUltCompra

Tipo Numeric Character Numeric Numeric Date

Tamanho 5, 0 30 10, 2 8, 4 -

Tipo Tamanho Long Integer Alpha 30 Money Number Date -

Antonio Cesar de Barros Munari

11

Projeto lgico de bancos de dados

Tabela de produto no Access Coluna CdProd NmProd VrUnit QtEstoque DtUltCompra Tabela de produto no Oracle Coluna CdProd NmProd VrUnit QtEstoque DtUltCompra Tabela de produto no MS-SQL Server Coluna CdProd NmProd VrUnit QtEstoque DtUltCompra Regras bsicas de mapeamento

Tipo Long Text Currency Double Datetime Tipo Number Varchar2 Number Number Date Tipo Numeric Varchar Money Numeric Datetime

Tamanho 30 Tamanho 5, 0 30 10, 2 8, 4 Tamanho 5, 0 30 8, 4 -

Qualquer componente do modelo conceitual que possua dados deve ser representado no banco de dados atravs de uma tabela. Isso significa que, em princpio, a cada entidade ou relacionamento com atributos prprios deve corresponder uma tabela do banco de dados. Geralmente representamos esse mapeamento atravs de algum tipo de diagrama onde aparecem todas as tabelas, seus relacionamentos e suas chaves primrias, pelo menos. Os relacionamentos entre as tabelas so implementados por meio de colunas especiais, chamadas chaves estrangeiras, que permitem vincular uma linha de uma tabela com a sua correspondente em outra tabela. Exemplo: Vamos supor o seguinte diagrama E/R
N Pertence 1

FUNCIONRIO

DEPARTAMENTO

@ Nmero de Matrcula Nome completo Nmero da Carteira Prof. Data de Admisso Sexo Data de Nascimento
Antonio Cesar de Barros Munari

@ Cdigo do Depto Nome completo Ramal telefnico

12

Projeto lgico de bancos de dados

Uma representao das tabelas para esse modelo poderia ser dada por:
NrMatr NmFunc NrCProf DtAdm Sexo DtNasc FUNCIONARIOS CHAR VARCHAR VARCHAR DATE CHAR DATE 6 30 15 1 DEPARTAMENTOS CdDepto CHAR NmDepto VARCHAR NrRamal CHAR

2 30 5

A questo agora determinar como vincular a linha de um funcionrio com a linha correspondente ao seu respectivo departamento, e vice-versa. A soluo colocar na tabela Funcionarios uma nova coluna, do tipo CHAR com tamanho 2, destinada a conter o cdigo do departamento ao qual o funcionrio pertence. Com isso, para um funcionrio qualquer, basta obter o valor contido nessa nova coluna e procur-lo na coluna CdDepto da tabela Departamentos para saber o nome completo do departamento ou o seu ramal. Essa coluna nova criada para implementar essa amarrao entre as tabelas uma chave estrangeira. O desenho a seguir mostra como ficaria o esquema lgico das tabelas implementando a chave estrangeira para o relacionamento "Pertence":
NrMatr NmFunc NrCProf DtAdm Sexo DtNasc Depto FUNCIONARIOS CHAR VARCHAR VARCHAR DATE CHAR DATE CHAR 6 30 15 1 2 N 1 DEPARTAMENTOS CdDepto CHAR NmDepto VARCHAR NrRamal CHAR

2 30 5

As descrio completa da estrutura de cada tabela, indicando o nome, o tipo de dado e o tamanho para cada coluna deve ser documentada em um dicionrio de dados parte, se nenhuma ferramenta CASE estiver sendo utilizada no projeto. Esse dicionrio pode conter informaes adicionais sobre o significado de cada tabela, a indicao do(s) objeto(s) correspondente(s) no modelo conceitual e a descrio de caractersticas complementares importantes das colunas (como, por exemplo, se algum tipo de chave ou possui alguma regra de validao que deve ser considerada para o dado). Tambm conveniente que esse dicionrio esteja adequadamente organizado de maneira a facilitar as consultas que se fizerem necessrias, e geralmente isso obtido colocando-se a descrio das tabelas por ordem alfabtica de nome.

Antonio Cesar de Barros Munari

13

Projeto lgico de bancos de dados

Anlise de Relacionamentos Um mesmo modelo conceitual (como o MER) pode dar origem a diversos modelos lgicos (relacionais e no-relacionais) distintos. Algumas entidades podem ser fundidas em uma nica tabela; outras podem ser desmembradas em duas ou mais tabelas distintas, o mesmo ocorrendo com os atributos. Tambm os relacionamentos merecem alguma ateno quanto s vrias possibilidades de implementao. A seguir, discute-se os principais aspectos dos relacionamentos que devem ser considerados ao se projetar as tabelas de um banco de dados relacional. Relacionamentos 1 para 1 Sempre que detectado um relacionamento de 1 para 1, a questo saber se as duas entidades so realmente distintas ou se elas podem ser unidas em uma nica tabela. Se possuem o mesmo atributo identificador, h uma forte razo para representar essas entidades em uma tabela s, a menos que o relacionamento seja opcional com cardinalidade mnima zero de um lado e um de outro lado. Exemplos:
PRODUTO @ CdProd DescProd PrecoProd 1 Possui 1 ESTOQUE @ CdProd QtProd

Neste diagrama, observamos que as entidades PRODUTO e ESTOQUE possuem seguramente o mesmo identificador, logo podemos representar as informaes todas em uma s tabela (PRODUTOS, no caso). Se tivermos, como no diagrama a seguir, uma entidade MAQUINA e outra MISTURA DE COMBUSTVEL, onde cada mquina tem sua prpria mistura de combustvel e cada mistura relaciona-se com uma e somente uma mquina, devemos considerar que a mistura de combustvel utilizada pode ser representada como uma coluna da tabela MQUINAS
MAQUINA 1 Usa 1 MISTURA DE COMBUSTIVEL

Dicas prticas: Se as duas entidades forem realmente distintas, o relacionamento se dar atravs de um elo explcito, ou seja, uma chave estrangeira. Ao projetar, devemos analisar a possibilidade de o relacionamento 1 para 1 futuramente tornar-e um relacionamento 1 para muitos. Vamos supor um modelo retratando um relacionamento entre um funcionrio e a diviso a que pertence conforme o diagrama a seguir.
Antonio Cesar de Barros Munari 14

Exemplo:

Projeto lgico de bancos de dados

EMPREGADO @ Ident. Empregado Nome Endereo Telefone

Gerencia

DIVISO @ Cdigo da Unidade Nome da diviso Oramento anual

As solues possveis de distribuio da chave estrangeira so as seguintes (indicadas em negrito itlico):

IdEmp NmEmp EndEmp TelEmp EMPREGADOS CHAR VARCHAR VARCHAR VARCHAR 6 30 50 20 1 1 DIVISOES CdUnidade CHAR NmDivisao VARCHAR VrOrcamento MONEY IdEmpGerente CHAR

2 30 6

EMPREGADOS IdEmp CHAR NmEmp VARCHAR EndEmp VARCHAR TelEmp VARCHAR CdUnidGer CHAR

6 30 50 20 2

CdUnidade NmDivisao VrOrcamento

DIVISOES CHAR VARCHAR MONEY

2 30

A estrutura de colunas proposta tabela DIVISOES, na primeira soluo, permite que no futuro um EMPREGADO possa vir a gerenciar mais de uma diviso. Uma discusso mais detalhada sobre mapeamento de relacionamentos um para um pode ser encontrada em [SHOVAL, 1991]. Relacionamentos 1 para muitos Este um tipo de relacionamento mais fcil para anlise. A chave estrangeira deve ser colocada na tabela do lado MUITOS do relacionamento e pode fazer parte da chave primria dessa tabela ou no.

Antonio Cesar de Barros Munari

15

Projeto lgico de bancos de dados

Exemplo:
CLIENTE @ Cd. Cliente Nome Cliente Endereo CLIENTES NUMERIC VARCHAR VARCHAR 1 Tem N VENDA @ Num. Venda Data Venda

CdCliente NmCliente EndCliente

6,0 30 50

NrVenda DtVenda CdCliente

VENDAS NUMERIC DATE NUMERIC

6,0 6,0

VENDA @ Num. Venda Data Venda VENDAS NUMERIC DATE NUMERIC

Possui

ITEM DE VENDA @ Num. Item Cd. Produto Qtde Item

NrVenda DtVenda CdCliente

6,0 6,0

NrItem CdProd QtItem NrVenda

ITENSVENDA NUMERIC CHAR NUMERIC NUMERIC

6,0 8 8,2 6,0

Se considerarmos que um CLIENTE pode ter muitas vendas sendo feitas a ele, o cdigo do cliente dever fazer parte da tabela VENDAS, mas no necessariamente da chave, pois o nmero da venda identifica claramente a venda. Nesse exemplo um cliente est associado a N vendas e cada venda, a N tens de venda. Deve ento o cdigo do cliente ser includo tambm na tabela ITEM DE VENDA? Obrigatoriamente no, pois se quisermos saber quais clientes pediram ou compraram um determinado produto, podemos pesquisar todas as ocorrncias de itens de venda para o produto em pauta, obtendo o nmero de suas vendas para, posteriormente, pesquisar em VENDAS quais os clientes que as efetuaram. Entretanto, igualmente verdade que simplificaria bastante a programao e a pesquisa se colocssemos o cdigo do cliente tambm em ITEM DE VENDA.

Antonio Cesar de Barros Munari

16

Projeto lgico de bancos de dados

Relacionamentos muitos para muitos Em todo relacionamento muitos para muitos a pergunta que se faz : QUEM REFERENCIA QUEM? Este caso sempre pode ser resolvido com o desdobramento em 2 relacionamentos 1 para muitos e a criao de uma tabela intermediria que faa a associao entre as duas tabelas principais. A chave primria dessa nova tabela , em princpio, a concatenao ou combinao das chaves primrias das duas tabelas principais.
FORNECEDOR @ Cd. Forn. Nome Forn. Endereo N Fornece N PRODUTO @ CdProd DescProd

Em nosso exemplo temos a situao em que FORNECEDOR fornece muitos PRODUTOS e qualquer PRODUTO poder ser fornecido por vrios fornecedores. Pergunta-se ento: Qual tabela possuir esta concatenao de chaves? Que colunas constituem essa tabela? Que elementos podem ser determinados se soubermos que estamos lidando com determinado PRODUTO de um FORNECEDOR especfico? (Qual a razo desta ligao?)

Podemos dar ento o nome de ORIGEM_PRODUTOS a essa tabela. Um produto poder estar disponvel em diferentes fornecedores, com preos e prazos diferenciados, e um fornecedor poder ofertar vrios produtos. Observe a chave primria composta nessa tabela, formada pela combinao das suas 2 chaves estrangeiras (as colunas CdFornec e CdProd).
FORNECEDORES CdFornec NUMERIC NmFornec VARCHAR EndFornec VARCHAR 6,0 30 50 1 N ORIGEM_PRODUTOS CdFornec NUMERIC CdProd CHAR VrPreco MONEY Prazo NUMERIC N 6,0 8 4,0

1 CdProd DescProd PRODUTOS CHAR VARCHAR 8 30

Antonio Cesar de Barros Munari

17

Projeto lgico de bancos de dados

Normalizao de tabelas
A normalizao de tabelas tem por objetivo principal resolver problemas de atualizao de bases de dados, minimizando redundncias. As principais caractersticas de uma base de dados normalizada so : gerao de aplicaes mais estveis (e por isso tambm mais alterveis) ; aumento do nmero de tabelas utilizadas ; diminuio dos tamanhos mdios das tabelas.

O processo de normalizao ocorre em etapas sucessivas. A cada etapa corresponde uma determinada forma normal, que representa um progressivo refinamento na estrutura das tabelas. Assim, uma tabela que se encontra na Terceira Forma Normal considerada mais normalizada (mais "enxuta", pode-se dizer) que uma tabela que se encontra apenas na Segunda Forma Normal. Atualmente os tericos da modelagem de dados consideram a existncia de inmeras formas normais, mas geralmente basta que uma tabela atenda s 3 primeiras para que possa ser considerada como normalizada. Primeira Forma Normal Requer que a tabela no apresente dados repetitivos em sua estrutura. Exemplo: Livros a) Estrutura original Tabela "Livros" IdLivro 21237 33455 12312 Ttulo Os Sertes Eletricidade bsica Atlas do Brasil Assunto Fico Fsica Geografia Autor1 E. Cunha A. Silva IBGE B. Santos Autor2 Autor3

b) Estrutura normalizada (1FN) Tabela "Livros" IdLivro 21237 33455 12312 Ttulo Os Sertes Eletricidade bsica Atlas do Brasil Assunto Fico Fsica Geografia

Antonio Cesar de Barros Munari

18

Projeto lgico de bancos de dados

Tabela "Autorias" IdLivro 21237 33455 33455 12312 Segunda Forma Normal Exige que a tabela no tenha atributos no-chave se referindo a apenas uma parte da chave primria (dependncia funcional parcial). Exemplo: Disciplinas a) Estrutura original Tabela "Disciplinas" Discipl BD1 TGA TGA Curso PD ADM ECON Fac PD ADM ADM Prof 005 004 004 Cargo Assistente Associado Associado CredSem 4 4 3 TotCred 72 72 54 Autor E. Cunha A. Silva B. Santos IBGE

b) Estrutura normalizada (2FN) Tabela "Disciplinas" Discipl BD1 TGA TGA Curso PD ADM ECON Prof 005 004 004 Cargo Assistente Associado Associado CredSem 4 4 3 TotCred 72 72 54

Tabela "Cursos" Curso PD ADM ECON Nome Processamento de Dados Administrao de Empresas Economia Fac PD ADM ADM Parecer (...) (...) (...)

Antonio Cesar de Barros Munari

19

Projeto lgico de bancos de dados Terceira Forma Normal Para estar na terceira forma normal a tabela no pode ter atributos no-chave se referindo a outros atributos no-chave. Exemplo: Disciplinas a) Estrutura original Tabela "Disciplinas" Discipl BD1 TGA TGA Curso PD ADM ECON Prof 005 004 004 Cargo Assistente Associado Associado CredSem 4 4 3 TotCred 72 72 54

b) Estrutura normalizada (3FN) Tabela "Disciplinas" Discipl BD1 TGA TGA Curso PD ADM ECON Prof 005 004 004 CredSem 4 4 3

Tabela "Professores" Prof 005 004 008 Nome Joo Pedro Maria Cargo Assistente Associado Pleno

Antonio Cesar de Barros Munari

20

Projeto lgico de bancos de dados

Roteiro para normalizao de dados

Tabela no normalizada

Desmembrar a tabela em uma ou mais tabelas sem grupos repetitivos de itens. Designar um ou mais atributos como Chave Primria das novas tabelas.

Tabela na 1 Forma Normal

Verificar a existncia de atributos parcialmente dependentes da Chave Primria. Criar novas entidades, que absorvero os atributos com dependncia funcional parcial, herdando a chave parcial.

Tabela na 2 Forma Normal

Verificar se no existem atributos dependentes de outros atributos no-chave. Destacar atributos dependentes de uma Chave Estrangeira e incorporar na tabela da chave estrangeira ou cri-las, se no existir. Eliminar os atributos obtidos por clculos a partir de outros atributos da mesma tabela.

Tabela na 3 Forma Normal

Antonio Cesar de Barros Munari 21

Projeto lgico de bancos de dados

Referncias bibliogrficas
BARBIERI, Carlos. Modelagem de Dados. Rio de Janeiro: Infobook, 1994. CHEN, Peter. Modelagem de Dados: A abordagem Entidade - Relacionamento para projeto lgico. So Paulo: Makron Books, 1990. ELMASRI, Ramez & NAVATHE, Shamkant B. Fundamentals of Database Systems . 3th Ed. Reading: Addison Wesley, 2000. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 1998. KORTH, Henry F. & SILBERSCHATZ Abraham. Sistema de Banco de Dados. 2a Ed. Rev. So Paulo: Makron Books, 1995. MELO, Rubens N. et al. Banco de Dados em Aplicaes Cliente-Servidor. Rio de Janeiro: Livraria e Editora InfoBook, 1997. SHOVAL, Peretz. One-to-One Dependencies in Database Design. In: IEEE Transactions on Knowledge and Data Engineering, vol. 3, no. 3, September 1991, pp. 371-379.

Antonio Cesar de Barros Munari

22