Access ______________________________________________________________

Base de dados Relacional Quando se inicia a utilizao de base de dados existe tendncia para considerar apenas uma tabela. No exemplo da base de dados do clube de vdeo, poderamos considerar apenas uma tabela com todos os scios, todos os filmes e todos os alugueres de filmes. Na verdade isso obrigaria repetio desnecessria de informao (redundncia): a informao sobre um filme que alugado vrias vezes repetir-se-ia em cada aluguer. importante criar tabelas que mantenham o mnimo de informao, ao mesmo tempo que mantemos uma base de dados fcil de usar. Para o conseguir necessrio utilizar vrias tabelas, o que torna a base de dados mais eficiente, evitando armazenar informao repetida. Para obteno das vrias tabelas do modelo relacional, podemos comear por identificar tudo aquilo sobre o que queremos guardar informao na nossa base de dados as entidades. No exemplo do clube de vdeo identificamos: Scios, Filmes, Aluguer. Seguidamente identificamos as vrias caractersticas de cada uma das entidades: Nome, morada, telefone etc. Em alternativa pode-se partir de uma tabela inicial, dividindo-a em vrias tabelas atravs de um processo que se chama Normalizao (processo mais utilizado). No suficiente termos identificadas as tabelas necessrias. As tabelas do modelo relacional relacionam-se atravs da existncia de atributos comuns. necessria a identificao de todas as relaes existentes. Estas relaes indicam-se atravs das linhas que ligam os campos das tabelas que se relacionam.

Professor: Jos Rocha

53

Access ______________________________________________________________

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 so raros e no existe nenhum exemplo no caso da base de dados do clube de vdeo. Este tipo de relacionamento acontece quando cada registo de uma tabela est relacionado com um registo da outra tabela e vice-versa. Exemplo: Um pas governado no mximo por um ministro Um ministro governa no mximo um pas Os relacionamentos 1:M (O Access utiliza o smbolo

em lugar do M)

so 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 vdeo existem vrios relacionamentos deste tipo. Por exemplo, cada scio pode alugar muitos filmes, mas cada filme (DVD) s pode ser alugado por um scio. 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 situao temos de criar uma nova tabela a que chamamos tabela de ligao, transformando este relacionamento em relacionamentos de 1:M, pois o Access apenas permite a existncia de relacionamentos de tipos 1:1 e 1:M. No exemplo do clube de vdeo cada scio pode alugar vrios filmes, e cada filme pode ser alugado por vrios scios. Criou-se assim a tabela de ligao Aluguer.

Professor: Jos Rocha

54

Access ______________________________________________________________

Existem alguns conceitos fundamentais associados s bases de dados Relacionais. A saber: Campo Chave: O campo chave de uma tabela constitudo por um ou mais campos que possam ser utilizados como identificadores de cada registo: Os campos-chave devem permitir identificar um registo de forma unvoca (Que s admite uma forma de interpretao). O campo ou o conjunto de campos seleccionados para chave de uma tabela no pode conter informao repetida. Nenhum dos campos que formam a chave poder conter valor nulo. Existe: Chave simples constituda apenas por um campo Chave composta - constituda por mais do que um campo Ainda relativamente Chave, temos: Chaves candidatas Todas as chaves possveis de uma tabela. Por exemplo na tabela scio existem duas chaves candidatas, o N_socio e o BI. Chave primria entre as chaves candidatas, uma delas ser a mais indicada ou a escolhida para desempenhar o papel de chave. No caso da tabela scio resolvemos escolher como chave primria o N_socio. Por fim temos ainda: Chave estrangeira ou chave externa As tabelas do modelo relacional relacionam-se atravs da existncia de campos comuns. Nesta situao, um campo de uma tabela, que se relaciona com um campo que chave primria de outra tabela, diz-se uma chave estrangeira ou chave externa. Na base de dados do clube de vdeo, por exemplo, o campo N_scio da tabela Aluguer uma chave estrangeira, pois relaciona-se com o campo N_Scio da tabela Scio onde Chave primria.
Professor: Jos Rocha

55

Access ______________________________________________________________

ABORDAGEM BOTTOM-UP (processo de normalizao) Para uma boa estruturao das bases de dados relacionais (por forma a evitar as tpicas anomalias de redundncia ou perda de integridade da informao), foi desenvolvido um conjunto de normas, ou processo de normalizao, composto pelas chamadas formas normais (1. Forma Normal, 2. Forma Normal, 3. Forma Normal). Um modelo de base de dados que respeite os princpios 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 no normalizados Analisar a informao e estrutur-la com vista elaborao de tabelas; procurar atribuir todos os atributos considerados importantes.

1 Forma Normal (1 FN)

Todos os atributos esto definidos em domnios que contm apenas valores atmicos. No h conjuntos de atributos repetidos para um determinado gnero de caractersticas.

Converter os atributos no-atmicos em atributos atmicos, por forma a que no possa incluir-se mais que um valor em cada campo de uma tabela. Eliminar atributos repetidos, passando a consider-los como elementos de uma nova tabela.

2 Forma Normal (2 FN)

A tabela j se encontra na 1 FN. Todos os atributos no-chave so funcionalmente dependentes da chave na sua totalidade e no 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, ento tambm est na 2 FN; - Se a chave composta analisam-se as dependncias 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.

3 Forma Normal (3 FN)

A tabela j se encontra na 2 FN. Nenhum atributo no-chave depende funcionalmente de nenhum outro atributo no-chave.

Analisar todos os atributos no-chave e procurar dependncias funcionais; se existir algum conjunto de atributos que tenham uma dependncia funcional em relao a um outro atributo, ento decompe-se a tabela at que no haja qualquer dependncia funcional entre os atributos no-chave; s podem existir dependncias funcionais entre atributos no-chave e a chave.

Professor: Jos Rocha

56

Access ______________________________________________________________

Termos usados no processo de normalizao e que convm saber: Entidades: so unidades fundamentais do modelo relacional de base de dados. So representadas ou traduzidas em tabelas. definida por um conjunto de atributos. Atributos: os atributos so representados ou traduzidos nos campos das tabelas. A palavra atmico, significa indecomponvel; que deve ser o mais elementar possvel. Atributos atmicos: so atributos que no podem ser decompostos em unidades mais elementares. Atributos no-atmicos: so atributos que podem ser decompostos em unidades mais elementares.

Entidade

Atributo atmico Atributos

Atributos no-atmicos

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 no pode ser decomposto em itens mais elementares, ou seja, indecomponvel, logo estamos perante um atributo atmico. O atributo Nome pode ser decomposto em itens mais elementares como por exemplo, PrimeiroNome e UltimoNome, logo um atributo no-atmico. O mesmo acontece com o atributo morada. Este atributo pode ser decomposto por exemplo em Rua e N_da_porta, logo tambm um atributo no-atmico.
Professor: Jos Rocha

57

Access ______________________________________________________________

Um princpio basilar do modelo relacional diz que cada atributo (de uma entidade) ou cada campo (de uma tabela) deve ser o mais elementar possvel, atmico ou indecomponvel Principio da atomicidade. A realidade que nem sempre isso acontece. Por vezes deparamo-nos com situaes de dilema em relao questo de definir um atributo de forma o mais elementar possvel. Dito de outra forma, por vezes surge o dilema de saber se um atributo deve, ou no, ser decomposto nos seus itens mais elementares. Por exemplo, a decomposio de um nome em PromeiroNome e ltimoNome pode trazer vantagens mas tambm pode trazer desvantagens. O mesmo se pode dizer em ralao morada; mas ser que tem interesse decompor uma morada em Rua, NmeroPorta, Andar etc.? H a considerar moradas que no se apresentam nesse formato; por isso, talvez seja prefervel deixar alguns itens juntos. As datas so outro exemplo de atributos no-atmicos mas que convm manter os seus itens juntos.

Mas as formas normais no terminam aqui Posteriormente, surgiram outras formas normais para alm 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 princpios estipulados at 3. Forma Normal pode considerar-se, na maioria dos casos, como adequadamente elaborado para funcionar num SGBD relacional. Por isso no vamos dar importncia Forma Normal de Boyce-Codd (FNBC), 4 FN nem 5 FN.
Professor: Jos Rocha

58

Access ______________________________________________________________

Resumindo

O processo de normalizao consiste no seguinte: 1. Definem-se as entidades com todos os atributos considerados relevantes; 2. Analisam-se as relaes e dependncias 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 caracterstica no 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.

Professor: Jos Rocha

59

Access ______________________________________________________________

Exemplo de modelao de informao 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 1 2 3 4 Nome Abel Ana Daniel Daniela Morada Lisboa Porto Porto Faro Disciplinas Mat.; Port.; Port.; Ing.; Mat. Ing.

2. Analisam-se as relaes e dependncias 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 relao de 1:M. O Access permite este tipo de relacionamento por isso vamos continuar. Um aluno pode inscrever-se em vrias disciplinas e em cada disciplina podem inscrever-se vrios alunos. Logo estamos perante uma relao de M:M. O Access no 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 no se criar, a tabela Alunos e a Tabela Disciplinas no tinham como se relacionar, uma vez que a relao continuava a ser M:M.
Professor: Jos Rocha

60

Access ______________________________________________________________

A soluo para estabelecer o relacionamento 1:M, passa por uma terceira tabela, que dever incluir (como chaves estrangeiras ou externas) os campos que so chaves primrias nas outras duas tabelas. Ento uma soluo seria:
Tabela Alunos N_Aluno 1 2 3 4 Nome Abel Ana Daniel Daniela Morada Lisboa Porto Porto Faro Tabela Disciplinas Disciplinas Portugus Ingls Informtica Matemtica Tabela Alunos_disciplinas Data_Inscri 04-02-2008 06-02-2008 06-02-2008 05-02-2008

Em cada tabela obrigatrio haver uma chave primria. Neste caso elas seriam definidas da seguinte forma: N_Aluno: a chave primria da tabela Alunos; Cod_Discip: Passa a ser a chave primria para a tabela Disciplinas; N_Aluno e Cod_Discip: para alm de serem chaves primrias, passam a ser tambm chaves estrangeiras ou chaves externas na tabela Alunos_disciplinas.

Assim sendo ficaria:

Tabela Alunos N_Aluno 1 2 3 4 Nome Abel Ana Daniel Daniela Morada Lisboa Porto Porto Faro Tabela Alunos_disciplinas N_Aluno Cod_Discip Data_Inscri 04-02-2008 06-02-2008 06-02-2008 05-02-2008 Tabela Disciplinas Cod_Discip 1 2 3 4 Disciplinas Portugus Ingls Informtica Matemtica

Professor: Jos Rocha

61

Access ______________________________________________________________

Agora vamos comparar as tabelas com as Formas normais: 1 FN; 2 FN e 3 FN.

1 Forma Normal (1 FN) Todos os atributos esto definidos em domnios que contm apenas valores atmicos. No h conjuntos de atributos repetidos para um determinado gnero de caractersticas. As tabelas obedecem 1 FN? Nas tabelas h valores no-atmicos, como por exemplo o nome e a morada. Ento no estamos a obedecer 1 FN. Mas j vimos que neste caso (Nome e morada) prefervel deixar os itens juntos. Podemos tambm verificar que no h conjuntos de atributos repetidos. Concluso: as tabelas esto na 1 FN Converter os atributos no-atmicos em atributos atmicos, por forma a que no possa incluir-se mais que um valor em cada campo de uma tabela. Eliminar atributos repetidos, passando a consider-los como elementos de uma nova tabela. preciso converter e eliminar atributos? Poderamos converter os atributos no atmicos, relativos ao nome e morada, em atributos atmicos, mas j vimos que neste caso prefervel deixar os itens juntos. No h conjuntos de atributos repetidos.

Concluso: as tabelas esto na 1 FN

2 Forma Normal (2 FN) A tabela j se encontra na 1 FN. Todos os atributos no-chave so funcionalmente dependentes da chave na sua totalidade e no 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, ento tambm est na 2 FN; - Se a chave composta analisam-se as dependncias 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.

Anlise: Temos a certeza que a tabela est na 1 FN. Nome e morada so dependentes da chave N_Aluno na sua totalidade. Disciplinas dependente da chave Cod_discip na sua totalidade. Concluso: as tabelas esto na 2 FN

Anlise: Temos uma tabela com chave composta mas os atributos do campo Data_incri dependem da chave na sua totalidade. Concluso: as tabelas esto na 2 FN

3 Forma Normal (3 FN) A tabela j se encontra na 2 FN. Nenhum chave. Anlise: Temos a certeza que a tabela est na 2 FN. S existem dependncias funcionais entre atributos no-chave e a chave. Concluso: as tabelas esto na 3 FN atributo no-chave depende funcionalmente de nenhum outro atributo no-

Analisar todos os atributos no-chave e procurar dependncias funcionais; se existir algum conjunto de atributos que tenham uma dependncia funcional em relao a um outro atributo, ento decompe-se a tabela at que no haja qualquer dependncia funcional entre os atributos no-chave; s podem existir dependncias funcionais entre atributos no-chave e a chave. Anlise: Temos a certeza que a tabela est na 2 FN. S existem dependncias funcionais entre atributos no-chave e a chave. Concluso: as tabelas esto na 3 FN

Professor: Jos Rocha

62

Access ______________________________________________________________

3. Sempre que uma entidade ou tabela apresentar alguma caracterstica no 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. No temos de reestruturar nada.

4. Repete-se o processo at que todas as entidades (tabelas) estejam na forma normal pretendida. Aqui tambm no necessitamos fazer nada.

Concluso: As tabelas esto normalizadas. Podemos comear a criar a nossa base de dados no Access.

Ao trabalho!

FIM
Professor: Jos Rocha

63