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;

Valores booleanos em bases de dados

Em bases de dados não é nada aconselhável a utilização de booleanos. “Dados” como ‘Sim’ ou ‘Não’ não tem grande significado e geram múltiplas interpretações pelo que é sempre melhor atribuir valores explícitos, ou seja, que sejam clara e univocamente compreensíveis pelos utilizadores.
Na presença de valores deste tipo é frequente que os utilizadores tentem interpretá-los à sua maneira ou, pior ainda, fazendo suposições que estão longe do que o pretendido pelo sistema de informação.
Quando, por exemplo, uma tabela contém um campo denominado “Persistente” onde se pretende armazenar o facto de esse produto ter um carácter persistente após ter sido aplicado é bem mais explícito, e livre de falsas interpretações, se os valores forem do género ‘Muito persistente , ‘Não persistente” em vez de ‘Sim’, ‘Não’ ou ‘S’, ‘N’.

Big Data: o tamanho importa! (Parte I)

Tal como outras tecnlogias/técnicas que o antecederam (por exemplo o armazenamento Cloud, a virtualização ou mesmo o Data Warehousing) o Big Data, por enquanto, parece não ser mais do que um termo da moda. Será que passará a ser verdadeiramente útil? Quando, como e porquê?
Para começar pode dizer-se que o Big Data é um conceito que se refere à colecta e análise de toda e qualquer peça de informação proveniente de todos os tipos de fontes.
Se observarmos uma breve cronologia que comece nos centros de informática dos anos 70 e 80, passe pelos sistemas de informação executivos dos anos 90 e, mais recentemente, pelo data warehousing e business intelligence, pode considerar-se que o Big Data como a etapa em curso.
À medida que a sociedade actual vai gerando mais e mais montanhas de dados é necessário encontrar uma forma de ir escavando essas encostas à procura de dados preciosos.
Actualmente, as três maiores áreas de aplicação do Big Data são a análise financeira, o serviço e apoio ao cliente e estudos de marketing. A dimensão das empresas não é aqui relevante dado que o Big Data destina-se a todas as organizações nas quais os dados estão no seu centro de actividade. É minha convicção de que as PMEs poderão retirar vantagens acrescidas da utilização do Big Data nas suas actividades do dia-a-dia.