Upload
joseroxa
View
144
Download
0
Embed Size (px)
Citation preview
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 1/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 53
Base de dados Relacional
Quando se inicia a utilização de base de dados existe tendência para
considerar apenas uma tabela. No exemplo da base de dados do clube de
vídeo, poderíamos considerar apenas uma tabela com todos os sócios, todosos filmes e todos os alugueres de filmes. Na verdade isso obrigaria à repetição
desnecessária de informação (redundância): a informação sobre um filme que
é alugado várias vezes repetir-se-ia em cada aluguer. É importante criar
tabelas que mantenham o mínimo de informação, ao mesmo tempo que
mantemos uma base de dados fácil de usar. Para o conseguir é necessário
utilizar várias tabelas, o que torna a base de dados mais eficiente, evitando
armazenar informação repetida.
Para obtenção das várias tabelas do modelo relacional, podemos
começar por identificar tudo aquilo sobre o que queremos guardar informação
na nossa base de dados – as entidades. No exemplo do clube de vídeo
identificamos: Sócios, Filmes, Aluguer. Seguidamente identificamos as várias
características de cada uma das entidades: Nome, morada, telefone etc. Em
alternativa pode-se partir de uma tabela inicial, dividindo-a em várias tabelas
através de um processo que se chama Normalização (processo mais
utilizado).
Não é suficiente termos identificadas as tabelas necessárias. As tabelas
do modelo relacional relacionam-se através da existência de atributos
comuns. É necessária a identificação de todas as relações existentes. Estas
relações indicam-se através das linhas que ligam os campos das tabelas que
se relacionam.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 2/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 54
Modelo E-R
Existem 3 tipos de relacionamentos:
Relacionamentos um para um - 1 para 1 (1:1);
Relacionamentos um para muitos - 1 para M (1:M);
Relacionamentos muitos para muitos - M para M (M:M).
Os relacionamentos de 1:1 são raros e não existe nenhum exemplo no
caso da base de dados do clube de vídeo. Este tipo de relacionamento
acontece quando cada registo de uma tabela está relacionado com um registoda outra tabela e vice-versa.
Exemplo:
Um país é governado no máximo por um ministro
Um ministro governa no máximo um país
Os relacionamentos 1:M (O Access utiliza o símbolo ∞ em lugar do M)
são os mais comuns. Este tipo de relacionamento acontece quando um registo
de uma tabela1 se relaciona com muitos registos de uma outra tabela2, mas
cada registo da tabela2 se relaciona apenas com um registo da tabela1. No
exemplo do clube de vídeo existem vários relacionamentos deste tipo. Por
exemplo, cada sócio pode alugar muitos filmes, mas cada filme (DVD) só pode
ser alugado por um sócio.
Os relacionamentos M:M, existem em praticamente todas as bases de
dados. Isto acontece quando um registo de uma tabela1 se relaciona com
muitos registos de uma outra tabela2, e cada registo da tabela2 se relaciona
com muitos registos da tabela1. Nesta situação temos de criar uma nova
tabela a que chamamos tabela de ligação, transformando este relacionamento
em relacionamentos de 1:M, pois o Access apenas permite a existência de
relacionamentos de tipos 1:1 e 1:M. No exemplo do clube de vídeo cada sócio
pode alugar vários filmes, e cada filme pode ser alugado por vários sócios.
Criou-se assim a tabela de ligação Aluguer.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 3/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 55
Existem alguns conceitos fundamentais associados às bases de dados
Relacionais. A saber:
Campo Chave:
O campo chave de uma tabela é constituído por um ou mais campos que
possam ser utilizados como identificadores de cada registo:
• Os campos-chave devem permitir identificar um registo de forma unívoca
(Que só admite uma forma de interpretação).
• O campo ou o conjunto de campos seleccionados para chave de uma
tabela não pode conter informação repetida.
• Nenhum dos campos que formam a chave poderá conter valor nulo.
Existe:
Chave simples – constituída apenas por um campo
Chave composta - constituída por mais do que um campo
Ainda relativamente à Chave, temos:
Chaves candidatas – Todas as chaves possíveis de uma tabela. Por
exemplo na tabela sócio existem duas chaves candidatas, o Nº_socio e o BI.
Chave primária – entre as chaves candidatas, uma delas será a mais
indicada ou a escolhida para desempenhar o papel de chave. No caso
da tabela sócio resolvemos escolher como chave primária o Nº_socio.
Por fim temos ainda:
Chave estrangeira ou chave externa – As tabelas do modelo relacionalrelacionam-se através da existência de campos comuns. Nesta situação,um campo de uma tabela, que se relaciona com um campo que é chaveprimária de outra tabela, diz-se uma chave estrangeira ou chaveexterna. Na base de dados do clube de vídeo, por exemplo, o campoNº_sócio da tabela Aluguer é uma chave estrangeira, pois relaciona-se
com o campo Nº_Sócio da tabela Sócio onde é Chave primária.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 4/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 56
ABORDAGEM BOTTOM-UP (processo de normalização)
Para uma boa estruturação das bases de dados relacionais (por forma a
evitar as típicas anomalias de redundância ou perda de integridade da
informação), foi desenvolvido um conjunto de normas, ou processo denormalização, composto pelas chamadas formas normais (1.ª Forma Normal,
2.ª Forma Normal, 3.ª Forma Normal…). Um modelo de base de dados que
respeite os princípios estipulados até à 3.ª Forma Normal pode considerar-se,
na maioria dos casos, como adequadamente elaborado para funcionar num
SGBD relacional.
1.ª Forma Normal (1 FN); 2.ª Forma Normal (2 FN); 3.ª Forma Normal (3FN)
Dados não normalizadosAnalisar a informação e estruturá-la com vista à elaboraçãode tabelas; procurar atribuir todos os atributosconsiderados importantes.
1ª Forma Normal (1 FN)Todos os atributos estão definidos emdomínios que contêm apenas valoresatómicos. Não há conjuntos de atributosrepetidos para um determinado género decaracterísticas.
Converter os atributos não-atómicos em atributos atómicos,por forma a que não possa incluir-se mais que um valor emcada campo de uma tabela.Eliminar atributos repetidos, passando a considerá-loscomo elementos de uma nova tabela.
2ª Forma Normal (2 FN)A tabela já se encontra na 1 FN. Todos osatributos não-chave são funcionalmentedependentes da chave na sua totalidade enão apenas de parte da chave.
Identificar a chave de uma entidade;- Se a chave só tem um atributo, e a tabela já está na 1 FN,então também está na 2 FN;- Se a chave é composta analisam-se as dependências dosoutros atributos; se algum ou alguns dos atributosdependem de uma parte da chave, a tabela deverá serdecomposta, por forma a que cada atributo dependaapenas da totalidade da chave.
3ª Forma Normal (3 FN)A tabela já se encontra na 2 FN.Nenhum atributo não-chave dependefuncionalmente de nenhum outro atributonão-chave.
Analisar todos os atributos não-chave e procurardependências funcionais; se existir algum conjunto deatributos que tenham uma dependência funcional emrelação a um outro atributo, então decompõe-se a tabelaaté que não haja qualquer dependência funcional entre osatributos não-chave; só podem existir dependênciasfuncionais entre atributos não-chave e a chave.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 5/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 57
Termos usados no processo de normalização e que convém saber:
Entidades: são unidades fundamentais do modelo relacional de base de
dados. São representadas ou traduzidas em tabelas. É definida por um
conjunto de atributos.
Atributos: os atributos são representados ou traduzidos nos campos das
tabelas.
A palavra atómico, significa indecomponível; que deve ser o mais
elementar possível.
Atributos atómicos: são atributos que não podem ser decompostos em
unidades mais elementares.
Atributos não-atómicos: são atributos que podem ser decompostos em
unidades mais elementares.
Uma entidade é definida por um conjunto de atributos. Neste caso a entidade Socio
é definida pelos atributos, Nº_Socio,Nome
, Morada, Telefone, BI .
O atributo Nº_Socio não pode ser decomposto em itens mais elementares, ou seja, é
indecomponível, logo estamos perante um atributo atómico.
O atributo Nome pode ser decomposto em itens mais elementares como por
exemplo, PrimeiroNome e UltimoNome, logo é um atributo não-atómico. O
mesmo acontece com o atributo morada. Este atributo pode ser decomposto
por exemplo em Rua e Nº_da_porta, logo também é um atributo não-atómico.
Entidade
Atributos
Atributo atómico
Atributos não-atómicos
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 6/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 58
Um princípio basilar do modelo relacional diz que cada atributo (de uma entidade) ou
cada campo (de uma tabela) deve ser o mais elementar possível, “atómico” ou
indecomponível – Principio da atomicidade.
A realidade é que nem sempre isso acontece. Por vezes deparamo-nos comsituações de dilema em relação à questão de definir um atributo de forma o
mais elementar possível. Dito de outra forma, por vezes surge o dilema de
saber se um atributo deve, ou não, ser decomposto nos seus itens mais
elementares.
Por exemplo, a decomposição de um nome em PromeiroNome e ÚltimoNome
pode trazer vantagens mas também pode trazer desvantagens.
O mesmo se pode dizer em ralação à morada; mas será que tem interesse
decompor uma morada em Rua, NúmeroPorta, Andar etc.? Há a considerar
moradas que não se apresentam nesse formato; por isso, talvez seja preferível
deixar alguns itens juntos.
As datas são outro exemplo de atributos não-atómicos mas que convém manter os
seus itens juntos.
Mas as formas normais não terminam aqui…
Posteriormente, surgiram outras formas normais para além das descritas
anteriormente:
• Forma Normal de Boyce-Codd (FNBC);
• 4ª Forma Normal (4 FN);
• 5ª Forma Normal (5 FN).
Como já foi referido anteriormente, um modelo de base de dados que
respeite os princípios estipulados até à 3.ª Forma Normal pode considerar-se,
na maioria dos casos, como adequadamente elaborado para funcionar num
SGBD relacional. Por isso não vamos dar importância à Forma Normal de
Boyce-Codd (FNBC), à 4 FN nem à 5 FN.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 7/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 59
Resumindo
O processo de normalização consiste no seguinte:
1º. Definem-se as entidades com todos os atributos considerados
relevantes;
2º. Analisam-se as relações e dependências entre os atributos de cada
entidade (tabela) e compara-se a estrutura analisada com as referidas
formas normais;
3º. Sempre que uma entidade ou tabela apresentar alguma característica
não conforme a uma forma normal, reestruturam-se os atributos ou
separam-se da entidade original para formar com eles uma nova
entidade ou tabela;
4º. Repete-se o processo até que todas as entidades (tabelas) estejam na
forma normal pretendida.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 8/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 60
Exemplo de modelação de informação utilizando as Formas Normais e o
modelo E-R.
Base de dados de alunos de uma escola e as disciplinas que eles frequentam.
1º. Definem-se as entidades com todos os atributos considerados
relevantes;
Exemplo: Tabela Alunos
Nº_Aluno Nome Morada Disciplinas
1 Abel Lisboa Mat.; Port.;
2 Ana Porto Port.; Ing.;
3 Daniel Porto Mat.
4 Daniela Faro Ing.
2º. Analisam-se as relações e dependências entre os atributos de cada
entidade (tabela) e compara-se a estrutura analisada com as referidas
formas normais;
Neste caso, cada aluno só possui uma morada, mas a mesma morada
pode pertencer a mais quem um aluno. Logo estamos perante uma
relação de 1:M. O Access permite este tipo de relacionamento por isso
vamos continuar.
Um aluno pode inscrever-se em várias disciplinas e em cada disciplina
podem inscrever-se vários alunos. Logo estamos perante uma relaçãode M:M. O Access não permite este tipo de relacionamento por isso
vamos ter de colocar o campo disciplinas noutra tabela e criar uma
terceira tabela (por exemplo Alunos_disciplinas) para que o
relacionamento passe a ser 1:M.
Se a terceira tabela não se criar, a tabela Alunos e a Tabela Disciplinas
não tinham como se relacionar, uma vez que a relação continuava a ser
M:M.
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 9/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 61
A solução para estabelecer o relacionamento 1:M, passa por uma
terceira tabela, que deverá incluir (como chaves estrangeiras ou
externas) os campos que são chaves primárias nas outras duas tabelas.
Então uma solução seria:
Tabela Alunos Tabela Disciplinas Tabela Alunos_disciplinas
Nº_Aluno Nome Morada Disciplinas Data_Inscriç
1 Abel Lisboa Português 04-02-2008
2 Ana Porto Inglês 06-02-2008
3 Daniel Porto Informática 06-02-2008
4 Daniela Faro Matemática 05-02-2008
Em cada tabela é obrigatório haver uma chave primária. Neste caso elas
seriam definidas da seguinte forma:
Nº_Aluno: é a chave primária da tabela Alunos;
Cod_Discip: Passa a ser a chave primária para a tabela Disciplinas;
Nº_Aluno e Cod_Discip: para além de serem chaves primárias, passam
a ser também chaves estrangeiras ou chaves externas na tabela
Alunos_disciplinas.
Assim sendo ficaria:
Tabela Alunos Tabela Alunos_disciplinas Tabela Disciplinas
Nº_Aluno Nome Morada Nº_Aluno Cod_Discip Data_Inscriç Cod_Discip Disciplinas
1 Abel Lisboa 04-02-2008 1 Português
2 Ana Porto 06-02-2008 2 Inglês
3 Daniel Porto 06-02-2008 3 Informática
4 Daniela Faro 05-02-2008 4 Matemática
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 10/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 62
Agora vamos comparar as tabelas com as Formas normais: 1 FN; 2 FN e
3 FN.
1ª Forma Normal (1 FN)
Todos os atributos estão definidos em domíniosque contêm apenas valores atómicos. Não há
conjuntos de atributos repetidos para um
determinado género de características.
Converter os atributos não-atómicos em atributos atómicos, por
forma a que não possa incluir-se mais que um valor em cadacampo de uma tabela.
Eliminar atributos repetidos, passando a considerá-los como
elementos de uma nova tabela.
As tabelas obedecem à 1 FN?
Nas tabelas há valores não-atómicos, como porexemplo o nome e a morada. Então nãoestamos a obedecer à 1 FN. Mas já vimos queneste caso (Nome e morada) é preferível deixaros itens juntos.Podemos também verificar que não há
conjuntos de atributos repetidos.Conclusão: as tabelas estão na 1 FN
É preciso converter e eliminar atributos?
Poderíamos converter os atributos não atómicos, relativos aonome e morada, em atributos atómicos, mas já vimos que nestecaso é preferível deixar os itens juntos.Não há conjuntos de atributos repetidos.
Conclusão: as tabelas estão na 1 FN
2ª Forma Normal (2 FN)
A tabela já se encontra na 1 FN. Todos os
atributos não-chave são funcionalmente
dependentes da chave na sua totalidade e não
apenas de parte da chave.
Identificar a chave de uma entidade;
- Se a chave só tem um atributo, e a tabela já está na 1 FN, então
também está na 2 FN;
- Se a chave é composta analisam-se as dependências dos
outros atributos; se algum ou alguns dos atributos dependem de
uma parte da chave, a tabela deverá ser decomposta, por forma a
que cada atributo dependa apenas da totalidade da chave.
Análise:
Temos a certeza que a tabela está na 1 FN.Nome e morada são dependentes da chaveNº_Aluno na sua totalidade.Disciplinas é dependente da chave Cod_discipna sua totalidade.
Conclusão: as tabelas estão na 2 FN
Análise:
Temos uma tabela com chave composta mas os atributos docampo Data_incriç dependem da chave na sua totalidade.
Conclusão: as tabelas estão na 2 FN
3ª Forma Normal (3 FN)
A tabela já se encontra na 2 FN.
Nenhum atributo não-chave depende
funcionalmente de nenhum outro atributo não-
chave.
Analisar todos os atributos não-chave e procurar dependências
funcionais; se existir algum conjunto de atributos que tenham umadependência funcional em relação a um outro atributo, então
decompõe-se a tabela até que não haja qualquer dependência
funcional entre os atributos não-chave; só podem existir
dependências funcionais entre atributos não-chave e a chave.
Análise:Temos a certeza que a tabela está na 2 FN.Só existem dependências funcionais entre
atributos não-chave e a chave.
Conclusão: as tabelas estão na 3 FN
Análise:Temos a certeza que a tabela está na 2 FN.Só existem dependências funcionais entre atributos não-chave e
a chave.
Conclusão: as tabelas estão na 3 FN
5/10/2018 Base de Dados1 - slidepdf.com
http://slidepdf.com/reader/full/base-de-dados1 11/11
AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Professor: José Rocha 63
3º. Sempre que uma entidade ou tabela apresentar alguma característica
não conforme a uma forma normal, reestruturam-se os atributos ou
separam-se da entidade original para formar com eles uma nova
entidade ou tabela;
Neste caso as tabelas obedeceram sempre às formas normais. Não
temos de reestruturar nada.
4º. Repete-se o processo até que todas as entidades (tabelas) estejam na
forma normal pretendida.
Aqui também não necessitamos fazer nada.
Conclusão:
As tabelas estão normalizadas. Podemos começar a criar a nossa base de
dados no Access.
Ao trabalho!
FIM