Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
61
Access ______________________________________________________________
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
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