Modelagem

UNIVATES – Centro Universitário

Manual Básico de Modelagem de Dados

Análise e Modelagem de Dados Mouriac Halen Diemer

Setembro de 2001

Sumário 1. Introdução...........................................................................................................................3 1.1 Evolução no tratamento dos dados .................................................................................3 1.1.1 Primeira Fase.........................................................................................................3 1.1.2 Segunda Fase.........................................................................................................3 1.1.3 Terceira Fase.........................................................................................................3 1.1.4 Quarta Fase ...........................................................................................................4 1.2 Razão para a evolução ..................................................................................................4 1.3 Conseqüências do uso de SBD.......................................................................................5 2. Abstração de dados.............................................................................................................6 2.1 Projeto descendente - Top down.....................................................................................7 2.2 Projeto ascendente - Bottom up......................................................................................7 3. Projetos descendentes .........................................................................................................8 3.1 Modelo Conceitual ........................................................................................................8 3.1.1 Conceito ................................................................................................................8 3.1.2 O que deve ser descrito pelo modelo conceitual? .....................................................8 3.1.3 Semântica do modelo de dados conceitual...............................................................8 3.1.4 Requisitos para modelos conceituais.......................................................................8 3.2 Modelo conceitual de entidades e relacionamentos..........................................................9 3.2.1 Elementos e conceitos estabelecidos pelo modelo E-R .............................................9 3.2.2 Restrições de relacionamento................................................................................10 3.2.3 Características de implementação do modelo E-R .................................................11 3.3 Modelo Operacional ....................................................................................................12 3.3.1 Conversão do modelo conceitual para o operacional..............................................12 3.3.2 Dicionário de dados .............................................................................................15 4. Projetos Ascendentes ........................................................................................................16 4.1 Introdução...................................................................................................................16 4.2 Normalização..............................................................................................................16 4.2.1 Primeira forma normal .........................................................................................16 4.2.2 Segunda forma normal .........................................................................................16 4.2.3 Terceira forma normal .........................................................................................17 4.2.4 Quarta forma normal ...........................................................................................17

1. Introdução

1.1 Evolução no tratamento dos dados 1.1.1 Primeira Fase Nesta fase os dados são tratados por aplicação. Somente a aplicação possui acesso aos dados, pois a estrutura dos registros encontra-se definida no código fonte da aplicação. Por causa disso os problemas de tratamento (acesso) dos dados, comuns a qualquer aplicação, precisam ser resolvidos (administrados) pela própria aplicação. Características: Usuário

A

• Arquivos por aplicação isolada • Estrutura dos arquivos definida na própria aplicação • Não há integração

1.1.2 Segunda Fase Sendo uma evolução da primeira fase e forçada pela necessidade dos usuários, nesta segunda fase os dados continuam sendo armazenados em arquivos e tratados por aplicação. No entanto já há uma preocupação dos desenvolvedores em integrar as aplicações possibilitando a troca de dados entre elas.

Características: Usuário

A

Usuário

B

• Integração de aplicações que antes eram isoladas • Racionalização na entrada de dados • Os arquivos continuam sendo por aplicação • Troca de dados entre aplicações através de fitas ou disquetes

1.1.3 Terceira Fase Visando isolar os dados das aplicações facilitando o acesso aos mesmos e por conseqüência a integração dos sistemas, na terceira fase começam a surgir os primeiros SGBDs. Os sistemas gerenciadores passam a assumir algumas funções que antes eram de

responsabilidade da aplicação, como por exemplo, a definição das estruturas dos arquivos (tabelas).

A

Usuário

Características:

S G B D

Usuário

• Banco de dados por aplicação • Possibilidade de acesso interativo diretamente sobre o banco de dados • Começam a surgir as primeiras linguagens de consulta

1.1.4 Quarta Fase A quarta fase constitui a última geração dos SGBDs. A proposta destes sistemas é promover uma completa abstração dos dados. Os SGBDs assumem todo o controle e tratamento, restando para a aplicação apenas a necessidade de se comunicar com o gerenciador requisitando consultas. Os problemas de acesso concorrente, segurança, consistências e integridade passam a ser de responsabilidade do banco de dados, abrindo caminhos para a construção de sistemas melhores e tempos cada vez menores.

Usuário

A

Usuário

Usuário

Características:

S G B D

• Banco de dados integrado • Compartilhamento dos dados por diversos usuários, de forma concorrente ou não • Independência de dados

B

1.2 Razão para a evolução Em poucas palavras podemos justificar a necessidade de evolução na forma como os dados são tratados afirmando que os dados são recursos estratégicos para um empresa. Um sistema de banco de dados proporciona à empresa um controle centralizado de seus dados operacionais. Os dados são um dos ativos mais valiosos que uma empresa pode ter. Em caso de sinistro é preferível que se perca todo o patrimônio da empresa, mas se preservem os dados. Sendo tão importantes assim, os dados merecem tratamento especial.

4

1.3 Conseqüências do uso de SBD A integração e compartilhamento dos dados gerou grandes benefícios, mas criou novas necessidades. O próprio conceito de independência de dados (imunidade das aplicações com relação aos dados) reforçou a necessidade de níveis de abstração de dados.

Benefícios:

Necessidades:

• Economia de espaço de armazenamento

• Maior uniformidade

• Economia do esforço de desenvolvimento

• Ampliar dispositivos de segurança (restrições de acesso e responsabilidades sobre a manutenção de dados).

• Redução da redundância de dados • Redução da inconsistência de dados

• Reforçar padrões • Manter a integridade

5

2. Abstração de dados Um SBD deve dar ao usuário uma visão abstrata dos dados, escondendo detalhes de armazenamento e manutenção, pois a complexidade interna das estruturas de armazenamento não interessam ao usuário. Abstração de dados, portanto, é a capacidade de enxergar a realidade desprezando certos detalhes que, no momento, são irrelevantes. Setzer (1987) estabeleceu cinco níveis para efeito de estudos sobre este assunto. O primeiro nível, considerado por Setzer, é a própria realidade, seguida por quatro níveis de abstração.

Mundo Real

Modelo Descritivo

Modelo Conceitual

Modelo Operacional

Modelo Interno

Nível Operacional: Mais próximo da máquina Nível Conceitual: Mais próximo do mundo real

Mundo Real: • Os objetos são seres, fatos, coisas e organismos sociais • Nebuloso do ponto de vista formal • Não é um nível de abstração Nível Descritivo: • Informações informais (relatórios em linguagem natural) • Descreve estruturas e transações • Já é um nível de abstração • Modelo descritivo da realidade • Não há regras formais para esse modelo Nível Conceitual: • Informações formais • Deve ser estritamente formal (formalismo matemático) • Facilitar a obtenção do modelo operacional • Trabalha com estruturas de informações. • Estruturas: Cliente (código, nome, endereço...) ou Cliente possui Pedido • As estruturas descrevem a informação • Exemplos de modelos conceituais: DER, DFD, fluxogramas, diagramas de blocos, etc. (português estruturado é intermediário entre conceitual e operacional) Nível Operacional: • É o nível de dados • Símbolos a serem introduzidos no computador (meta-dados e dados) • Modelos deste nível são operacionais • Linguagens: DDL e DML • Modelos hierárquicos, redes e relacionais Nível Interno ou de Máquina: • Cadeias de bits e bytes • Estruturas internas de arquivos e tabelas • Programas em linguagem de máquina (EXE) • Usuário não vê detalhes desse nível • Nível de máquina por dentro

2.1 Projeto descendente - Top down É um método para derivar os modelos de cima para baixo. Inicialmente elabora-se um projeto lógico para só então derivar o projeto físico. Os passos enumerados abaixo orientam a elaboração de um projeto descendente. O primeiro e o segundo passo correspondem ao projeto lógico, enquanto que o terceiro passo corresponde ao projeto físico. Primeiro Passo: Elaborar um modelo descritivo a partir de observações e vivências do mundo real. Segundo Passo: Derivar um modelo conceitual a partir do modelo descritivo. Terceiro Passo: Derivar um modelo operacional a partir do modelo conceitual, que será introduzido no computador.

2.2 Projeto ascendente - Bottom up É um método para gerar o modelo operacional partindo dos próprios dados que serão introduzidos no computador. No projeto ascendente aplicam-se técnicas que visam ajudar a definir quais dados são relevantes para a organização, bem como suas formas de armazenamento. Estas técnicas, quando bem empregadas, geram modelos operacionais idênticos (ou iguais) aos gerados pelo método descendente, ou seja, sem redundâncias. Os seguintes passos orientam a construção de um projeto ascendente. Primeiro Passo: Fazer um levantamento completo de todos os dados operacionais da empresa a partir de documentos utilizados no mundo real. Segundo Passo: Aplicar as técnicas de normalização sobre as relações de dados extraídas dos documentos. Terceiro Passo: Construir o modelo conceitual a partir do modelo operacional. Este passo, por razões de conveniência, pode não ser de interesse da empresa.

7

3. Projetos descendentes

3.1 Modelo Conceitual 3.1.1 Conceito O modelo conceitual é um nível de abstração utilizado para representar os elementos que compõe a realidade do usuário, bem como os relacionamentos entre estes componentes. Abaixo estão relacionados dois conceitos propostos respectivamente por Silberschatz e Bubenko. “Modelo de dados é uma coleção de ferramentas conceituais para descrição dos dados, relacionamentos entre dados, semântica e restrições dos dados” (Korth & Silberchatz). “Modelo conceitual tem como objetivo fornecer conceitos e linguagens para representação de um modelo de parte relevante da realidade, em alto nível e independente da representação para computador” (Bubenko).

3.1.2 O que deve ser descrito pelo modelo conceitual? O modelo conceitual deve descrever o conhecimento útil e relevante da realidade, como fatos, fenômenos individuais, entidades ou relacionamentos, de forma concreta e concisa. Ex.: “Fornecedor F fornece peças do tipo P para o projeto J” O exemplo acima revela um fato concreto e fenômenos classificados como conjuntos de entidades. Um conhecimento abstrato é uma informação que amplia nossa interpretação da informação concreta e nos permite fazer inferências e conclusões sobre outros fatos. Este tipo de conhecimento é indesejável para o modelo conceitual. Ex.: “Num dado dia, um funcionário pode atuar em somente um projeto” “Qualquer fornecedor fornece ao menos duas peças para cada projeto”.

3.1.3 Semântica do modelo de dados conceitual A semântica inerente aos dados deve ser uma preocupação atendida pelo modelo conceitual. Sempre que possível o modelo conceitual deve capturar o máximo de semântica da realidade, pois a semântica diz respeito ao significado dos dados.

3.1.4 Requisitos para modelos conceituais Deve ser elaborado com a participação do usuário: • Evitar a tendência de usar representações e conceitos computacionais.

• O usuário conhece melhor a realidade. • Modelos conceituais devem ser naturais, de alto nível e orientados para a solução dos problemas do usuário, de maneira que incentive sua participação. Deve servir de base para discussão e negociação: • O modelo conceitual mostrará uma forma de enxergar a realidade. • O usuário deve opinar e discutir com o analista a cerca do grau de abstração desejado. • As regras e restrições devem ser negociadas com o usuário. Deve servir de base para o projeto de um banco de dados eficiente em computador.

3.2 Modelo conceitual de entidades e relacionamentos • Proposto por Peter Chen em 1976 • Mundo real consiste de entidades e relacionamentos • Incorpora importantes informações semânticas sobre o mundo real • Baseado na teoria dos conjuntos • Possui alto grau de independência de dados • Modelos operacionais são facilmente derivados

O modelo E-R foi proposto por Peter Chen em 1976. Peter Chen acredita que o mundo real e composto de entidades e relacionamentos. Baseado na teoria dos conjuntos criou o modelo E-R visando incorporar informações semânticas sobre o mundo real em uma forma de representação que garanta a independência de dados e que facilmente derive modelos operacionais.

3.2.1 Elementos e conceitos estabelecidos pelo modelo E-R Entidade:

É uma representação abstrata de um “objeto” do mundo real.

Conjunto de Entidades: Grupo de entidades com características semelhantes, como por exemplo, o conjunto de funcionários. Os conjuntos de entidades são representados por retângulos no modelo E-R. Cada objeto do mundo real é representado por uma só entidade de um único conjunto de entidades, para evitar redundâncias. Funcionários

Atributos:

Informações a cerca de uma entidade. São representados no modelo ao redor do conjunto de entidades. Funcionários

Nome

Relacionamentos:

Produtos

Endereço Sexo

Produtos

Descrição

Preço

São associações entre duas ou mais entidades, que representam um fato ou uma solução do mundo real. Ex.: João está lotado no departamento vendas.

9

Domínio:

O domínio de um atributo é o conjunto de valores admissíveis para este atributo. O atributo sexo, por exemplo, pode ter como domínio o conjunto { M, F }. Já o atributo código pode ter como domínio um intervalo de valores [1 ; 999 ]. Formalmente, atributo é a função que mapeia um conjunto de entidades em um conjunto de valores (domínio). Matrícula

Conjunto de Entidades Funcionários

o o o o o o o

Conjunto de Matrículas

oM

Conjunto de Sexos

o o o o o o o Sexo oF

3.2.2 Restrições de relacionamento 3.2.2.1 Cardinalidade Expressa o número de instâncias de uma entidade que podem ser associadas a uma instância (ocorrência, tupla, registro) de outra entidade através do relacionamento. Uma para muitos: Uma entidade em A está associada a qualquer número de entidades em B. Uma entidade em B pode estar associada a, no máximo, uma entidade em A.

A

1

N

B

Um para um: Uma entidade em A está associada a, no máximo, uma entidade em B. E uma entidade em B está associada com no máximo uma entidade em A.

A

1

1

B

Muitos para muitos: Uma entidade em A está associada a qualquer número de entidades em B. Uma entidade em B está associada a qualquer número de entidades em A.

A

N

N

B

3.2.2.2 Parcialidade/totalidade ou Obrigatoriedade/opcionalidade Seja E um conjunto de entidades e R um conjunto de relacionamentos em que E participa. Se todo elemento de E deve estar obrigatoriamente em R, então R é total em E, caso contrário, R é parcial em E. Esta restrição (restrição de participação) especifica se a participação de uma entidade em um relacionamento será total ou parcial. • Total: Todas as instâncias participam do relacionamento. • Parcial: Algumas instâncias participam do relacionamento.

A

1

R R é total em B

10

N

B

3.2.2.3 Persistência Bloqueia a remoção de instâncias das entidades envolvidas em um determinado relacionamento, que estejam participando de alguma instância desse relacionamento. N

Aluno

N

Aula

Assiste

3.2.3 Características de implementação do modelo E-R 3.2.3.1 Auto-relacionamento É aquele que associa elementos de um conjunto de entidades a elementos deste mesmo conjunto de entidades.

3.2.3.2 Sinônimos para conjuntos de entidades (papéis ou roles) Uma entidade pode, conforme o caso, assumir diferentes papéis num modelo de dados. GERENTE FUNCIONÁRIO

3.2.3.3 Relacionamentos múltiplos N

Fornecedor

Possui

N

Produtos

N

Projeto 3.2.3.4 Agregações A agregação é uma abstração onde um relacionamento de muitos para muitos é tratado como uma entidade de um nível mais alto. Implementa a representação de um relacionamento entre uma entidade e um relacionamento de muitos para muitos.

11

Cliente

N Possui

N

Conta

1

Emite

1

Cartão Magnético

3.2.3.5 Particionamento ou Generalização ou Especialização Conjunto de entidades que representam elementos do mundo real que se subdividem em categorias com atributos parcialmente distintos. Generalização: Mecanismo onde atributos comuns a entidades de mais baixo nível são representadas um única vez em uma entidade de mais alto nível. Especialização: Atributos adicionais, presentes em apenas alguns objetos da entidade (especializações) são representados em entidades de mais baixo nível. PESSOA

PESSOA

PESSOA

PESSOA

3.3 Modelo Operacional O modelo operacional é responsável por detalhar todos os aspectos necessários para implementação do projeto. Devem ser descritas todas as tabelas ou relações necessárias, seus atributos e regras ou restrições de acesso aos dados. O nível de detalhe ao qual se deve chegar depende do ambiente de desenvolvimento adotado pela empresa. Normalmente descreve-se tudo que é necessário (ou requisitado) para operacionalizar o modelo no banco de dados usado pela organização.

3.3.1 Conversão do modelo conceitual para o operacional Para gerar o modelo conceitual podemos utilizar diversas técnicas e diagramas, contudo, se este fora modelado sob a proposta de Peter Chen, utilizando o diagrama de entidades e relacionamentos, a conversão para o modelo operacional torna-se natural. No modelo conceitual de entidades e relacionamentos utilizamos conjuntos de entidades, relacionamentos, atributos e alguns símbolos para representar a semântica pertinente a um ou

12

mais objetos e fatos do mundo real. Estes elementos facilmente são convertidos para relações ou tabelas, tuplas e regras operacionais. Veja como esta conversão se dá:

Modelo E-R

Modelo Operacional

• • • • •

• • • • •

Conjunto de Entidades Atributo Domínio Entidade Relacionamentos

Tabela ou relação Coluna da tabela Domínio, regras de validação Tuplas Regras de integridade relacional, chaves estrangeiras (externas)

A próxima figura explicita melhor estes elementos do modelo operacional.

Domínios

001 002 003...

Nomes próprios

Lajeado Londres Paris...

Código

Nome

Cidade

Relação

001

José

Lajeado

002

Carlos

Estrela

003

Júlio

Canoas

Atributos Tuplas

Chave primária

3.3.1.1 Chave Primária Para cada tabela (relação) devemos eleger um chave primária. A chave primária é composta por um ou mais atributos que permitem uma identificação única de cada tupla da tabela. Para tal seleciona-se os atributos ou conjunto de atributos que reúnem esta característica, os quais são chamados de chaves candidatas. Entre as chaves candidatas escolhe-se o atributo que melhor desempenha o papel de chave primária para assumir esta função, assim sendo as demais chaves passam a ser consideradas chaves alternativas. Na ausência de um atributo (ou conjunto de atributos) que se qualifique para assumir o papel de chave primária, cria-se um novo atributo com esta característica. Normalmente este atributo recebe nomes como: código, matrícula, número, sigla, etc. As tabelas (relações) inicialmente são enumeradas juntamente com a lista de seus atributos, como mostra o exemplo abaixo. Para destacar a chame primária costuma-se sublinhar os atributos que a compõe. Exemplo de representação no modelo operacional: Produto ( CódProduto, Descrição, PreçoUnitário, Estoque )

13

3.3.1.2 Chave estrangeira No modelo operacional relacional as tabelas se relacionam através de atributos comuns. Duas tuplas estão relacionadas quando a chave primária (um ou mais atributos) da primeira tupla estiver presente na segunda tupla. Veja o exemplo abaixo. NotaFiscal ( NúmeroNF, DataEmissão, ValorTotal, CódigoCliente ) Cliente ( CódigoCliente, Nome, Endereço, Fone ) Cada tupla da relação NotaFiscal se relaciona com uma tupla da relação Cliente, pois na realidade do usuário uma nota fiscal sempre é emitida para um cliente. Para explicitar este relacionamento a relação NotaFiscal contém dentre a lista de seus atributos o atributo CódigoCliente, que é a chave primária da relação cliente. Assim sendo o atributo CódigoCliente pertencente a tabela NotaFiscal (necessário para estabelecer o relacionamento) é considerado chave estrangeira na relação NotaFiscal. Normalmente estes atributos recebem um sinal # para melhor identificá-los. NotaFiscal ( NúmeroNF, DataEmissão, ValorTotal, CódigoCliente# )

3.3.1.3 Relacionamentos de um para um Este tipo de relacionamento é o mais fácil de ser convertido para o modelo operacional. Após definidas as duas tabelas com suas chaves primárias, basta acrescentar a chave primária de uma delas como chave estrangeira na outra tabela.

3.3.1.4 Relacionamentos de um para muitos Os relacionamentos de um para muitos também são facilmente convertidos para o modelo operacional. Neste caso a chave primária da tabela onde os relacionamentos são unívocos deve ser acrescentada na tabela onde os relacionamentos são múltiplos. Veja o mesmo exemplo já utilizado anteriormente. NotaFiscal ( NúmeroNF, DataEmissão, ValorTotal, CódigoCliente# ) Cliente ( CódigoCliente, Nome, Endereço, Fone ) Neste caso as tuplas da relação Cliente podem se relacionar com várias tuplas da relação NotaFiscal, mas cada tupla da relação NotaFiscal só se relaciona com uma tupla da relação Cliente, ou seja, é um relacionamento de um para muitos. Portanto a chave primária da relação Cliente deve figurar na relação NotaFiscal como chave estrangeira.

3.3.1.5 Relacionamentos de muitos para muitos Alguns bancos de dados não implementam relacionamentos de muitos para muitos. Por causa disto devemos converter os relacionamentos deste tipo para dois relacionamentos de um para muitos. Modelo E-R Nota Fiscal

N

Possui

Modelo Operacioanal N

Produtos

1 Nota Fiscal

N Contém

N Itens da NF

1 Descrevem

Produtos

Após realizada esta conversão aplicam-se os mesmos procedimentos já descritos nos tópicos anteriores.

14

3.3.2 Dicionário de dados O dicionário de dados nada mais é do que uma descrição detalhada de todos os dados que envolvem uma aplicação. A construção de um dicionário de dados pode ser um trabalho exaustivo e ocasionalmente complicado se optarmos por descrever absolutamente todos os dados frutos de uma análise de um sistema, pois muitas metodologias geram um grandiosíssimo volume de dados. No entanto o dicionário de dados é provavelmente um dos resultados mais importantes que deve sair de um projeto de banco de dados, pois nele serão definidas importantíssimas informações para o gerenciamento da base de dados e conseqüentemente para a construção dos futuros sistemas de informação. Para cada atributo de cada relação devemos definir nome interno, tipo, tamanho, domínio, entidade relacionada, valor default, se pode ou não receber valor nulo, etc. A construção do dicionário de dados deve ser baseada nas características do software de banco de dados existente na organização, mas nada impede que se inclua outras informações. Veja um exemplo simples: Entidade

Atributo

Descrição

Tipo

Tamanh o

Produto

CodProd Descr

Código do produto Descrição do produto

Char Char

10 40

15

Decimai Domínio s ---

(0;9999999999] Caracteres

Admite Nulo Não Não

4. Projetos Ascendentes

4.1 Introdução De maneira inversa aos projetos descendentes, os projetos ascendentes partem da realidade operacional do usuário aplicando sobre os dados existentes na empresa uma técnica de projeto de banco de dados conhecida como normalização. A normalização é efetuada a partir das informações (dados) extraídos dos documentos comumentemente utilizados pelo usuário, caracterizando-se como um processo altamente formal.

4.2 Normalização Normalização é uma técnica de projeto de banco de dados que visa, a partir dos dados existentes na organização, construir relações (tabelas) livres de redundância e passíveis de serem implementadas em um banco de dados relacional. Para normalizar um conjunto de dados devemos aplicar sobre os mesmos as regras que os tornam normalizados. O processo de normalização passa por diversas etapas conhecidas como formas normais. Veja um exemplo. Seja a seguinte relação não normalizada: Funcionários ( Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento, ( Código Curso, Curso, Data, Grau )) Obs.: Os atributos Código Curso, Curso, Data e Grau estão entre parênteses porque se repetem muitas vezes na ficha do funcionário.

4.2.1 Primeira forma normal Uma relação estará na primeira forma normal se e somente se todos os seus atributos possuírem valores atômicos (únicos). Funcionários ( Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento ) CursosFuncionário ( Código Funcionário#, Código Curso, Curso, Data, Grau ) Obs.: Os atributos que se repetem (valores não únicos) formam uma nova relação. A chave primária da primeira relação (relação origem) deve ser levada para a nova relação. Para a nova relação devemos definir uma chave primária.

4.2.2 Segunda forma normal Uma relação estará na segunda forma normal se e somente se estiver na primeira forma normal e todos os seus atributos forem dependentes funcionais de toda a chave primária, ou seja, nenhum atributo pode ser dependente parcial da chave primária. Funcionários ( Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento ) CursosFuncionário ( Código Funcionário#, Código Curso#, Data, Grau )

Cursos( Código Curso, Curso ) Obs.: O atributo Curso é dependente apenas de Código Curso, por isso foi retirado e passou a integrar uma nova tabela de Cursos onde o atributo que gera a dependência funcional, Código Curso, é trazido como chave primária.

4.2.3 Terceira forma normal Uma relação estará na terceira forma normal se e somente se estiver na segunda forma normal e nenhum de seus atributos for dependente transitivo da chave primária, ou seja, nenhum atributo pode depender de outro atributo que não é chave. Funcionários ( Código Funcionário, Nome, Endereço, CEP#, Departamento ) Cidades ( CEP, Cidade, UF ) CursosFuncionário ( Código Funcionário#, Código Curso#, Data, Grau ) Cursos( Código Curso, Curso ) Obs.: Os atributos Cidade e UF além de dependerem da chave primária Código Funcionário são dependentes do atributo CEP, portanto passam a constituir uma nova tabela tendo como chave primária o CEP.

4.2.4 Quarta forma normal Uma relação estará na quarta forma normal se e somente se estiver na terceira forma normal e nenhum de seus atributos for dependente multivalorado da chave primária, ou seja, possuir um conteúdo comum a muitas tuplas da relação. Funcionários ( Código Funcionário, Nome, Endereço, CEP#, Código Depto# ) Cidades ( CEP, Cidade, UF ) CursosFuncionário ( Código Funcionário#, Código Curso#, Data, Grau ) Cursos( Código Curso, Curso ) Deptos ( Código Depto, Departamento ) Obs.: O atributo Departamento é dependente multivalorado do Código Funcionário, pois ele ocorre repetidamente em várias tuplas da relação Funcionário. Para solucionar esta dependência cria-se uma nova tabela com o atributo Departamento, gerando um novo atributo para constituir a chave primária desta nova tabela, Código Depto.

17