1. Estruturação da Informação

A criação de uma Base de Dados no ACCESS exige um trabalho prévio de estruturação da informação obtida no levantamento de especificações. A lógica do ACCESS tem subjacente conceitos do Modelo Relacional. Falar do Modelo Relacional significa estruturar a informação de acordo com a seguinte forma:

 

a) organizar em tabelas as informações necessárias para as decisões correntes e estratégicas.

 

 Exemplo:   Numa Biblioteca, a informação relativa à Requisição de Título e a Ficha de Título, de consulta do mesmo, poderá estar expressa da seguinte forma:

 

Tabela Requisição de Título:

 

Tabela Ficha de Requisição

 

Aos campos IDrequis e IDtitulo corresponde uma característica do tipo de informação que se quer tratar e que pode estar relacionada com outra informação

 

A Tabela Requisição de Título contêm, como campos, os códigos internos das tabelas Título e Sócio IDtitulo e IDautor. A presença destes códigos naquela tabela significa que os três tipo de informação estão relacionados: cada requisição está relacionada quer com um título quer com um sócio.

 

 

b) identificar o tipo de relações existentes entre tabelas:

 

1 para 1: a um registo de uma tabela corresponde um registo de outra tabela relacionada.

n para 1: a n registos corresponde 1 registo (em esquema apenas esta relação é expressa graficamente).

 

 Exemplo:   Pretende-se que na tabela FACTU apareçam as características do cliente e as características do programa (provenientes dos campos das tabelas respectivas). Assim, são inseridos os códigos internos das tabelas Cliente e Programa (CODCLIEN e o CODPROG, respectivamente) que permitirão relacionar as três tabelas em qualquer um dos seus campos.

 

Relação n para p a 1 registo de uma tabela A correspondem n registos de uma tabela B; e
  a 1 registo na tabela B correspondem p registos na tabela A.

 

 

A construção gráfica do Modelo Relacional deve obedecer aos seguintes requisitos:

 

•  desenho em árvore das ramificações
•  setas orientadas de baixo para cima, das tabelas dependentes para as outras. As setas significam relações 1 para n
•  sem cruzamento de setas

 

 

Exemplos de construção do Modelo Relacional

 

 Exemplo 1: Controle de Gestão  Uma empresa de software pretende criar uma metodologia de actuação dentro de forma a registar todos os fluxos de informação dentro da empresa e desta com o exterior, incrementando a respectiva rapidez de decisões. Questões a responder: que programas estão instalados nos clientes; quem é o técnico responsável por cada programa; que acções foram executadas por cada técnico (telefonema, assistência técnica, etc); e a que programa ou cliente as acção dizem respeito?

 


TECP

PROG

CLIEN

PROCL

TECNA

técnico responsável por um programa

Programa

Cliente

Programa-Cliente

Técnico responsável por uma acção

 

   

As relações criadas neste modelo são:

ACCAOTECNA  de n para 1, pois várias acções poderão dizer respeito a um técnico;

ACCAOPROGR

de n para p, pois várias acções podem dizer respeito a vários programas e vários programas poderão corresponder a várias acções;
ACCAOCLIEN

de n para r,

pois várias acções poderão dizer respeito a vários clientes e vários clientes podem originar várias acções;

PROGRCLIEN de p para r

pois vários programas estão afectos a vários clientes e vários clientes podem ter vários programas;

 

Para resolver as relações de n para r tais como PROGRCLIEN foi criada uma nova tabela PROCL. A sua criação remete para uma particularidade do Modelo Relacional.

 

Na construção dos esquemas do Modelo Relacional quando existem relações:

de 1 para 1 a informação relacionada fica contida apenas num campo de uma tabela

de n para r:

cria-se terceira tabela que deverá integrar as duas fontes de informação

 

Sempre que vários clientes possam estar associados a vários programas, cria-se uma terceira tabela que associa cada individualmente cada uma das outras: PROCL = CLIEN+PROG. Assim:

 

Em vez de se estabelecer a relação directa:   Utiliza-se a seguinte relação indirecta:

 

 

 

 Exemplo 2: Facturação 

Neste caso, a tabela LINFA (linha da factura) resolve simultaneamente
as relações para p entre:

• PROGFACT:

pois uma factura pode registar vários programas e vários programas podem figurar em várias facturas.

• PROGCLIEN:

porque um cliente pode ter vários programas e um programa pode estar associado a vários clientes.

 

 

 

 Exemplo 3: Gestão de Arquivos Mortos  Um cliente entrega a uma empresa um conjunto de documentos para serem classificados a arrumados. Durante o processo de classificação, a arrumação dos documentos do arquivo morto poderá variar ao longo do tempo. Posteriormente o cliente vem buscar os seus documentos e a empresa tem de saber onde os arrumou.

 

A tabela MDLOC reflecte a relação de n para p entre LOTE e LOCAL.

 

 

 

 Exemplo 4 - Gestão de Correspondência 

A diferenciação entre entrada e saída de correspondência será realizada num campo dentro da tabela CORRESP.

 

 

 

 

 Exemplo 5 - Gestão de Biblioteca  Uma Biblioteca pretende ter um sistema de informação que permita aos seus funcionários gerir as requisições de livros, as respectivas entregas e atrasos. Questões a resolver: por quem foi requisitado determinado livro? Que (e quantos) livros requisitou um determinado leitor em determinado período de tempo? Qual é o montante de multa a pagar pelo sócio pelo facto de este ter entregue o livro atrasado face ao período estipulado para a entrega?

 

Descrição de alguns campos possíveis de figurar nas tabelas:

 

 

 

 

A tabela TITASS reflecte a relação entre ASSUN e TITULO

 


2. Hierarquia da Informação

Na concepção da base de dados é também necessário atender à hierarquia existente entre os vários tipos de informação. Assim, é necessário ter em consideração os seguintes conceitos:


2.1. Noção de Área

O conceito de área está associado à existência de tabelas dominantes e subordinadas. A tabela domínio (ou tabela-mãe) reúne os campos e referências que existirão igualmente nas tabelas subordinadas (dependentes). A inserção de registos deve efectuar–se através das tabelas subordinadas, segundo determinados critérios.

 

A criação de relacionamentos entre as tabelas da base de dados é realizada recorrendo unicamente às tabelas subordinadas.

 


TEC
TECPRO
TECASS

Tabela dos Técnicos (Domínio)
Tabela de Técnicos de Programas (Área)
Tabela de Técnicos de Assistência (Área)

 

 


2.2. Tipos de Integridade

As informações e relações atribuídas na tabela-mãe podem ser tratadas de diferentes formas nas tabelas dependentes. Existem três tipos de integridade:

 

a) Integridade Referencial

Por forma a manter a origem de determinada informação — quando existem dependências — sempre que se elimina um registo na tabela-mãe surge uma janela de aviso.

 

 

b) Apagar tudo

A eliminação de um registo implica a anulação de registos dependentes.

 

 

 Exemplo Facturação   A tabela LINFA integra um campo de código interna da tabela FACTU. Logo, as colunas "Relac" e "Campo" estão respectivamente preenchidas com FACTU e IDFACTU. Se for criada a condição de integridade "Apagar tudo" quando se elimina um registo de uma factura, todas as linha de factura relacionadas com a mesma serão apagadas.

 

 

c) Apagar registo desmarcando dependentes

A eliminação de um registo poderá não implicar a eliminação de registos que lhe sejam dependentes.

 

 Exemplo Facturação   A tabela CHEQUE possui o código interno da tabela FACTURA com as colunas "Relac" e "Campo" preenchidas com FACTU  CODFACTU. Se se quiser condicionar a eliminação da informação é possível apagar registos de cheques sem apagar facturas a que diz respeito.


3. Outras Relações entre tabelas de dados

Por fim, o modelo relacional considera diversas relações que se podem estabelecer entre as tabelas: transitiva, consulta à tabela, último valor. Existem funções específicas utilizadas para a criação dos dois últimos tipos de relação.


3.1 Relações Transitivas

 

Sendo A, B e C tabelas de dados:

se A possui uma relação de n para 1 com B
e se B possui uma relação de n para 1 com C
então A possui uma relação de n para 1 com C.

 


Ou seja, é possivel relacionar campos da tabela A com campos da tabela C através dos campos da tabela B.

 

 

 

 Exemplo Controlo de Gestão 

 

A relação transitiva é considerada para garantir a permanente actualização de dados interligados.

 

 

 Exemplo Facturação  A tabela CHEQUE possui um código interno da tabela FACTU com as colunas "Relac" e "Campo" preenchidas com FACTU e IDFACTU. Se for pretendido condicionar a eliminação de informação é possível eliminar todos os registos de Cheques sem eliminar as Facturas a que dizem respeito.

 


3.2. Relações de Consulta à Tabela

Permitem ir buscar dados de outras tabelas para preencher determinado campo e relacioná-lo com outros.


3.3. Relação de Último Valor

Indica somente o último registo efectuado relativamente à informação que se pretende.


4. Informações diversas sobre o relacionamento de dados

a) Quando se pretende realizar previsões/simulações com base em registos da base de dados, poderão surgir duas situações:

• 

a previsão/simulação é realizada de uma só forma tendo por base um determinado objecto; e

• 

a previsão/simulação de um determinado objecto pode ser requerida de formas distintas

 

No primeiro caso, dever-se-á criar tabelas cujos campos auxiliam a criação de rotinas manuais (processos que visam automatizar cálculos matemáticos ou relações entre campos e respectivos registos). No segundo caso, existe uma maior aleatoriedade na elaboração das previsões logo não se poderão criar tabelas fixas para as mesmas, gerindo os dados através das rotinas manuais.

 

b) Para um número fixo de designações caracterizadoras de determinado registo existem duas hipóteses:

• 

criar um campo dentro da tabela principal que caracteriza um registo com uma array com o número fixo de designações; e

• 

criar uma tabela específica destinada exclusivamente para incluir a array com as designações

 

A primeira é mais simples na elaboração da base de dados mas não permite realizar determinado tipo de consultas por designação. No segundo caso as designações são autonómas permitindo a agregação dos registos por designação.

 

 Exemplo:   No processo de avaliação de projectos de investimento, uma entidade poderá classificá-los em quatro categorias: pontuais, integrados, microempresas e urbanismo. A sub-tabela a criar (array) terá como campos as categorias acima indicadas.

 

c) Não é pertinente criar tabelas apenas com o campo código interno ou um segundo campo que não seja objecto de consulta e que possa ser facilmente introduzido pelo utilizador: é preferível colocar esse campo numa tabela para que a informação esteja relacionada.