2. Distribuindo a Informação por várias Tabelas

    Nos capítulos anteriores a informação foi armazenada numa tabela apenas. Guardar a informação associada a aplicações mais complexas numa tabela só, acarreta problemas de espaço e consistência.

    Exemplo: Se um banco guardasse toda a informação sobre uma conta (número, data de abertura, nome do 1º titular, morada do 1º titular, etc) junto com a informação de cada movimento feito, o tamanho de cada registo seria enorme e a tabela atingiria uma dimensão incomportável. Para além disso, se, por exemplo, o 1º titular mudasse de residência, seria necessário corrigir todos os registos de movimentos na conta respectiva. Se se considerar o facto de que cada conta pode ter vários titulares, então o problema agravar-se-ia, dado que seria preciso acrescentar à estrutura da tabela campos para o nome e morada, etc dos outros titulares. Isto provocaria, entre outros problemas, desperdício de espaço, dado que nas contas com menos titulares do que o máximo previsto teriam vários campos vazios, e também dificuldade na definição da estrutura da tabela, para decidir qual o número máximo de titulares que uma conta pode ter.¨

    Exemplo: Para além de guardar informação sobre os alunos, a faculdade pretende registar as suas notas. Para tal a tabela Alunos criada anteriormente é extendida, como mostrado na figura abaixo, passando a chamar-se Notas.

    Pode-se verificar aqui também muita redundância, com dados como a morada, localidade e data de nascimento a serem registados para cada nota do aluno. O mesmo sucede com o regente da disciplina que é guardado com cada nota da disciplina respectiva. Para além das dificuldades referidas no exemplo anterior relacionadas com a alteração de informação, a introdução repetida dos mesmos dados vai multiplicar os erros. Note-se, por exemplo, que na 4ª linha, o utilizador esqueceu-se do acento na palavra Informática. Este erro reflectir-se-ia, por exemplo, quando se calculasse a média das notas lançadas a 10 de Julho de 97 a essa disciplina. Uma solução seria preencher estes campos apenas uma vez, o que implicaria um desperdício de espaço considerável. Implicaria também que se esse registo fosse apagado seria necessário reintroduzir esses dados noutro registo.

    Repare-se também que, como foi utilizado o tipo AutoNumber para o campo número, cada vez que é introduzida uma nota é atribuido um número diferente ao aluno.

    Finalmente, como esta tabela tem informação de notas, seria impossível obter informação sobre um aluno que ainda não tivesse nenhuma nota lançada.¨

    1. Relacionamentos

A melhor solução para estes problemas é dividir a informação por várias tabelas, relacionando-as para poder ter acesso à informação como um todo. A forma como essa divisão é feita, isto é o Desenho da Base de Dados, está desenvolvida noutra sebenta. O desenho da BD é a fase mais importante da criação de uma BD e resulta num modelo de dados.

Exemplo: A análise da informação a armazenar na BD da faculdade resulta no seguinte modelo de dados:

 

que se pode interpretar da seguinte forma:

Assim, para além da tabela Alunos original são criadas tabelas para as outras entidades representadas, Disciplinas e Notas:

com os dados distribuidos pelas 3 tabelas da seguinte forma:

Note-se que a tabela Notas tem um campo Aluno que guarda o número do aluno a que a nota diz respeito. É acrescentado um campo chamado Código à tabela Disciplinas para substituir o campo Disciplina no papel de chave. A disciplina é, assim, identificada na tabela Notas pelo campo Disciplina que guarda um valor correspondente ao código.

Apesar da divisão da informação em várias tabelas, nada foi perdido: para saber o nome do aluno a que corresponde a nota na 3ª linha da tabela Notas, obtém-se o valor do campo Aluno desse registo, 2, e procura-se na tabela Alunos o aluno cujo Número é 2, que é a Maria Oliveira.

Se algum aluno mudar de morada, basta alterar o registo respectivo na tabela Alunos.¨

Os relacionamentos representados no modelo de dados são implementados directamente em Access. Um relacionamento envolve 2 tabelas que têm um campo comum, isto é, um campo que representa o mesmo elemento de informação. A criação de um relacionamento é uma indicação ao SGBD desse facto. O Access suporta dois tipos de relacionamentos:

 

Os relacionamentos mais comuns são do tipo 1:N.

Para criar relacionamentos executar o comando Tools, Relationships. É apresentada uma caixa de diálogo para selecionar as tabelas a relacionar:

 

Selecionadas as tabelas, o relacionamento é definido arrastando o campo comum na tabela primária para cima do campo comum na tabela relacionada. Um relacionamento pode envolver vários campos comuns, 2 a 2, bastando para isso preencher o resto das linhas disponíveis. O tipo de relacionamento é automaticamente detectado e indicado em baixo. O valor Indeterminate indica que o Access não conseguiu detectar o tipo de relacionamento.

O campo comum tem que ser do mesmo tipo em ambas as tabelas e ter também o mesmo tamanho (Field Size). A excepção à regra permite relacionar campos do tipo AutoNumber e Number, desde que o Field Size seja o mesmo.

O campo comum é, normalmente, o campo chave da tabela primária. Na tabela relacionada o campo comum é chamado chave externa (foreign key). No caso raro de haver um relacionamento entre tabelas em que o campo comum não é chave em nenhuma, então ele terá que ser indexado numa delas.

Exemplo: Para definir os relacionamentos da BD da faculdade, executar o comando Tools, Relationships e seleccionar todas as tabelas. Depois arrastar o campo Número da tabela Alunos para o campo Aluno da tabela Notas e o campo Código da tabela Disciplinas para Disciplina de Notas. O Access detecta que são relacionamentos 1:N.¨

Para apagar um relacionamento é preciso seleccioná-lo e executar Edit, Delete. Atenção que a execução desse comando depois de seleccionada uma tabela só provoca o desaparecimento da tabela da janela de relacionamentos. Este mecanismo permite facilitar a análise dos relacionamentos em BD complexas. Para visualizar todos os relacionamentos executar Relationships, Show All e para ver todos os relacionamentos em que a tabela seleccionada participa, executar Relationships, Show Direct.

Numa BD bem desenhada e bem construida cada tabela está relacionada com pelo menos outra tabela.

    1. Integridade Referencial

Dividir a informação por várias tabelas resolveu os problemas de redundância e inconsistência referidos acima, mas criou outros. Por exemplo, se um registo numa tabela primária fôr apagado e existirem registos relacionados noutra tabela, a BD fica inconsistente. De forma semelhante, se fôr alterado o valor do campo comum de um registo da tabela primária, a informação na BD deixará de ser consistente.

Exemplo: Se eliminar o registo da tabela Disciplinas referente a Informática, a BD passa a estar inconsistente porque vários registos na tabela Notas fazem referência à disciplina 1 que já não existe. Isto é, não é possível, por exemplo, saber a qual disciplina é que a aluna Carolina Santos teve 15, como é indicado pelo 1º registo de Notas.

Se, por exemplo, os número dos alunos Maria Oliveira e Paulo Silva forem alterados na tabela Alunos (o que é impossível de fazer neste caso porque é um campo do tipo AutoNumber) então estes alunos passarão a ter as notas trocadas entre eles.¨

Activando a opção Enforce Referential Integrity, o Access passa a validar os valores dos campos relacionados, de forma a garantir a integridade referencial, e, portanto, a consistência da informação distribuida pelas tabelas. Assim, todos os valores existentes no campo comum da tabela relacionada terão que existir no campo comum da tabela primária. Na janela de relacionamentos, um relacionamento com esta opção activada passa a ter indicação do lado 1 e do lado N, este último representado por um símbolo de infinito (¥ ).

Exemplo: Activando a opção Enforce Referential Integrity para os relacionamentos da BD da faculdade, a janela de relacionamentos será semelhante à seguinte:

Se tentar apagar o 1º registo de Alunos o Access dá a seguinte mensagem de erro:

¨

Note-se que a partir deste momento não é possível introduzir a informação na BD por qualquer ordem. Os dados das tabelas primárias têm que ser introduzidos antes dos dados das tabelas relacionadas.

Assim, para alterar o valor de um campo comum ou apagar um registo numa tabela primária, é necessário antes alterar/apagar os registos relacionados. Para simplificar estas tarefas que são frequentes, o Access permite que as alterações efectuadas na tabela primária sejam automaticamente reflectidas nas tabelas relacionadas após confirmação pelo utilizador.

Quando a opção Enforce Referential Integrity é activada são disponibilizadas mais 2 opções:

 

Exemplo: Depois de activar ambas as opções de propagação em ambos os relacionamentos da BD da faculdade, se se apagar o registo da aluna Carolina Santos em Alunos, aparece a seguinte caixa de diálogo:

¨

    1. Consultas sobre várias Tabelas

Como já foi referido, os relacionamentos permitem ver e pesquisar a informação da BD como um todo, apesar de estar dividida em várias tabelas. Para isso usa-se consultas que tenham como fonte de registos as tabelas onde se encontram os dados que se deseja obter. Os relacionamentos determinam a forma como a junção (join) das tabelas será feita. A construção de consultas com uma ou várias tabelas é idêntica: selecciona-se as tabelas, escolhe-se os campos a mostrar e define-se o critério. Qualquer das consultas apresentadas pode ter várias tabelas (ou outras consultas) como fontes de registos.

Cada linha da tabela gerada pela execução da consulta é uma das combinações possíveis de registos com os mesmos valores do campo comum.

Exemplo: Para obter uma lista com os nomes dos alunos e as notas obtidas, sem indicar os nomes das disciplinas, construir uma consulta com a seguinte estrutura e resultado:

Note-se que cada registo de Alunos foi combinado tantas vezes quantos os registos de Notas com que se relaciona, enquanto cada registo de Notas foi combinado apenas 1 vez. Isto deve-se ao facto de a relação ser 1:N, isto é, cada aluno tem várias notas e cada nota diz respeito a apenas 1 aluno.¨

 

Exemplo: Supondo agora que também se pretende obter uma pauta, isto é, o nome da disciplina juntamente com o nome do aluno e da nota:

Repare-se que apesar de se combinar registos de mais uma tabela, o número de registos da tabela resultante mantem-se o mesmo. Isto é devido a cada nota dizer respeito a 1 só disciplina para além de 1 só aluno.¨

Uma consulta que envolva tabelas com relacionamentos 1:1 são editáveis, isto é, é possível inserir novos registos, e alterar e eliminar registos existentes. No caso de haver relacionamentos 1:N também é possível editar a tabela resultante excepto:

Note-se que eliminar um registo da tabela virtual é equivalente a eliminar um registo da tabela relacionada, isto é, do lado N do relacionamento.

Ao criar uma consulta que usa tabelas relacionadas, ela não "herda" os respectivos relacionamentos. Assim, ao criar consultas que usem como fonte de registos uma consulta em conjunto com outras consultas ou tabelas, a falta desses relacionamentos pode provocar resultados errados. Para resolver este problema é possível criar relacionamentos envolvendo consultas tal como se criam com tabelas apenas. Outra possibilidade é a criação de relacionamentos próprios da consulta, na vista de estrutura. Tal é feito arrastando os campos como na janela de relacionamentos, sendo as únicas diferenças:

 

    1. Mais sobre Junções…

      Até agora foram consideradas apenas consultas envolvendo tabelas relacionadas. No entanto, é possível fazer consultas sobre tabelas não relacionadas. Nesse caso, a junção feita é o produto cartesiano das tabelas, isto é, cada registo de uma tabela é combinado com todos os registos da outra. No entanto, raras vezes esta acção é realmente útil.

       

      Exemplo: Executando a consulta que se segue nos dados das tabelas Table1 e Table2 mostradas:

      obtem-se:

      ¨

      1. Propriedades das Junções

As operações de junção (join) em tabelas relacionadas apresentadas até agora só incluiram os registos para os quais os valores dos campos relacionados são iguais em ambos os lados da relação. Se houver algum registo na tabela primária sem correspondência na tabela relacionada, esse registo não é apresentado. De igual forma não é mostrado um registo da tabela relacionada que não tenha correspondência na primária, o que só pode acontecer se a integridade referencial não estiver activa. Este tipo de junção é conhecido como equi-join. Por vezes pretende-se obter registos que não tenham correspondência. Nestes casos pode-se alterar o tipo de junção associada ao relacionamento. Para tal basta editar o relacionamento, seleccionando-o e executando o comando Relationships, Edit Relationships e clicar no botão Join Type. É apresentada a caixa de diálogo seguinte:

A opção 2 permite mostrar todos os registos do lado 1 e apenas os registos do lado N que estejam relacionados, enquanto a opção 3 permite o inverso. Visualmente a alteração é representada como uma seta no lado em que só são seleccionados os registos com correspondência.

Exemplo: Para que qualquer consulta que inclua as tabelas Alunos e Notas inclua sempre os nomes dos alunos que ainda não tiveram qualquer nota, altera-se o relacionamento entre essas tabelas para um left outer join:

 

Criando uma consulta igual a Notas + Alunos obtem-se:

¨

Também é possível limitar a aplicação do tipo de junção a uma consulta. Para isso é preciso seleccionar o relacionamento na vista de estrutura da consulta respectiva e executar o comando View, Join Properties.

As junções do tipo left outer join e right outer join são frequentemente utilizadas para detectar situações de excepção.
Hosted by www.Geocities.ws

1