Duas relações com a mesma chave primária?


Por vezes surgem propostas de modelos de dados em que co-existem duas, por vezes mais, relações com a mesma chave primária (CP). Ora, isso teoricamente é um erro dado que duas relações com uma CP idêntica são uma única relação.

Regra:

Os objectos que tenham uma relação de 1:1 entre si devem manter-se juntos: um aluno tem um número de aluno (não tem dois); um automóvel tem uma matrícula (não tem duas), e por ai fora.

Exemplo:

 

Figura 1: Excerto de modelo de dados

No caso da Figura 1 ninguém poderá afirmar que o desenho esteja correcto. Porquê subdividir algumas características dos alunos por relacções diferentes quando na verdade os atributos têm uma relação de 1:1 com cada aluno.
  • Por acaso um aluno têm dois nomes? Não, não tem.
  • Será que um aluno têm dois números de bilhete de identidade? Também parece que não...
Então isso significa que entre a relação Aluno e os atributos nome e número de bilhete de identidade há uma associação de 1:1, i.e., um aluno tem um só nome e um único número de bilhete de identidade. Pelo que esses atributos têm que pertencer à mesma relação, têm que estar todos no mesmo conjunto.

A intersecção do conjunto (a relação) Aluno com o conjunto Aluno Identificação não é o conjunto vazio pelo que não são disjuntos, pelo contrário são uma e a mesma coisa. A intersecção dos dois conjuntos é a soma de todos os atributos sem que isso implique qualquer perca de integridade dos factos. Aliás, a integridade e o valor da informação aumentam quando os atributos 1:1 ficam todos no mesmo conjunto.

Conclusão: duas relações com uma CP idêntica são uma única relação.




Associação 1:1 entre objectos

A associação, ou relação, entre peças de informação é fundamental para no desenho do modelo de dados relacional. Tudo o que tenha o grau 1:1 deve manter-se na mesma relação.

A não observação desta regra leva a que no mesmo modelo de dados possam existir várias relações com a mesma chave primária. O que em si mesmo é uma impossibilidade lógica, pois duas relações com a mesma chave primária são uma e a mesma coisa.

Media library - Itens

Por vezes surgem em modelos de dados construções particulares que são confusas pois fogem aos estereótipos. No caso do modelo proposta por Williams (2011) há uma secção sobre a tipificação de atributos de suportes de informação como se pode ver na Figura 1.

Figura 1: Tipificação de atributos.

Como se trata de um centro de documentação onde são possíveis tipos muito distintos de elementos como, por exemplo, livros, revistas, DVD, VHS, CD, então é quase impossível ter uma tabela na base de dados onde existam em simultâneo TODOS as colunas necessárias à caracterização de casa item. Uma tabela construída dessa forma além de ter numerosas colunas teria sempre muitas que não seriam preenchidas por não se encaixarem no item a registar.

Assim, Williams (2011) propõe uma construção invulgar que começa pela definição do tipo de dados (Ref_Data_Types), que se liga a Data_Items onde se definem TODAS as características que interessem aos diferentes tipos de media. Esta última por sua vez converge em Library_Data_Items onde se atribuem as caraterísticas a cada um dos Library_Items.

A tabela Data_Item_Values proposta não faz qualquer sentido pois há uma relação de 1:1 entre a característica e o respectivo valor. Ou seja a coluna "Data_Item_Value" deve transitar para a tabela Library_data_Items, e a tabela Data_Item_Values deve ser descartada.

Oracle | Data aleatória

Pretende-se gerar uma data aleatória entre 2006-12-01 e 2006-12-20 (um intervalo de 20 dias). Para fazer o cálculo transforma-se a data para o dia juliano em número: TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J'):
SELECT TO_DATE(TRUNC(DBMS_RANDOM.VALUE(
       TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J'),
       TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J')+20)), 'J')
FROM DUAL;

DBA | Afinação da Aplicação

Estatísticas | Oracle

Custo de Execução de Queries | Oracle