base de dados1

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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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.



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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



AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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


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.


Análise:

Temos uma tabela com chave composta mas os atributos docampo Data_incriç dependem da chave na sua totalidade.



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.


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.




AAcccceessss _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


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

base de dados1

Documents