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:

• Arquivos por aplicação isolada

Usuário A • 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
• 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
Usuário B 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).

Características:
S
Usuário A G • Banco de dados por aplicação
• Possibilidade de acesso
B interativo diretamente sobre o
Usuário banco de dados
D
• 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.

Características:
Usuário A
S
• Banco de dados integrado
Usuário G • Compartilhamento dos dados
B por diversos usuários, de forma
D concorrente ou não
Usuário B • Independência de dados

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
• Redução da redundância de dados
sobre a manutenção 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:
• Os objetos são seres, fatos, coisas e organismos
sociais
• Nebuloso do ponto de vista formal
Mundo Real • Não é um nível de abstração
Nível Descritivo:
• Informações informais (relatórios em
linguagem natural)
• Descreve estruturas e transações
Modelo Descritivo • 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
Modelo Conceitual 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
Modelo Operacional
• Exemplos de modelos conceituais: DER, DFD,
fluxogramas, diagramas de blocos, etc.
(português estruturado é intermediário entre
conceitual e operacional)
Nível Operacional:
Modelo Interno • É o nível de dados
• Símbolos a serem introduzidos no computador
(meta-dados e dados)
• Modelos deste nível são operacionais
Nível Operacional: • Linguagens: DDL e DML
• Modelos hierárquicos, redes e relacionais
Mais próximo da máquina
Nível Interno ou de Máquina:
• Cadeias de bits e bytes
Nível Conceitual: • Estruturas internas de arquivos e tabelas
• Programas em linguagem de máquina (EXE)
Mais próximo do mundo real • 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

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.
• 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

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 Produtos

Atributos: Informações a cerca de uma entidade. São representados no

modelo ao redor do conjunto de entidades.
Funcionários Produtos

Nome Endereço Sexo Descrição Preço

Relacionamentos: 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).
o o Conjunto
Matrícula o o o de
o o Matrículas

Conjunto o o
de Entidades o o o
Funcionários o o
oM Conjunto
Sexo de
oF Sexos

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.
1 N
A 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.
1 1
A 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.
N N
A 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.
1 N
A R B
R é total em B

10
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 N
Aluno Assiste Aula

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 N
Fornecedor Possui Produtos

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
 N N
Cliente Possui Conta

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 • Tabela ou relação
• Atributo • Coluna da tabela
• Domínio • Domínio, regras de validação
• Entidade • Tuplas
• Relacionamentos • Regras de integridade relacional, chaves
estrangeiras (externas)

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

001 Lajeado
Nomes
002 Londres
próprios
Domínios 003... Paris...

Código Nome Cidade Atributos

001 José Lajeado
Relação
002 Carlos Estrela Tuplas
003 Júlio Canoas

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 Modelo Operacioanal
N N 1 N N 1
Nota Fiscal Possui Produtos Nota Fiscal Contém Itens da NF 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 Decimai Domínio Admite

o s Nulo
Produto CodProd Código do produto Char 10 -- (0;9999999999] Não
Descr Descrição do produto Char 40 -- Caracteres Não

15
 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