Fundamentos de Desenho e Modelação de Bases de Dados

O desenho de bases de dados e a criação de modelos de dados é uma parte importante do ciclo de vida do desenvolvimento de aplicações. No entanto, nem sempre lhe é dada a devida importância. Um modelo de dados fidedigno e actualizado pode servir como uma ferramenta importante de referência para analistas de bases de dados, programadores e outros membros das equipas de desenvolvimento.

O processo de criação de um modelo de dados ajuda as equipas a identificar questões adicionais a colocar aos utilizadores. Um bom desenho de bases de dados também permite desenvolver aplicações que funcionem bem desde o seu início. A preocupação com a qualidade de um projecto permite que as equipas reduzam o tempo necessário para a conclusão do mesmo, o que acabará por reduzir os custos de desenvolvimento. O aspecto central subjacente ao desenho de bases de dados consiste em "medir duas vezes e cortar uma vez".

Os bons especialistas em desenho de bases de dados têm sempre em conta os princípios de normalização. A normalização é uma abordagem de desenho de bases de dados que procura responder a quatro objectivos:

• Minimização da redundância de dados;
• Minimização da reestruturação de dados;
• Minimização do I/O através da redução da dimensão das transacções;
• Implementação da integridade referencial.

Apresentamos a seguir vários conceitos e técnicas que se devem ter em conta no desenho de bases de dados.

1. Uma entidade é um conjunto lógico de coisas que são relevantes para a base de dados. O correspondente físico de uma entidade é uma tabela de base de dados. Devemos atribuir nomes às entidades no singular e em maiúsculas. Por exemplo, uma entidade que contenha dados sobre os empregados de uma empresa deverá ser designada por EMPREGADO.

2. Um atributo é uma característica descritiva ou quantitativa de uma entidade. O correspondente físico de um atributo é uma coluna (ou campo) de base de dados. Devemos atribuir nomes aos atributos no singular e com a letra inicial maiúscula, ou tudo em minúsculas. Por exemplo, alguns nomes de atributos para a nossa entidade EMPREGADO podem ser EmpregadoId (ou empregado_id) e DataNascimento (ou datanascimento).

3. Uma chave primária é um atributo (ou combinação de atributos) que identificam de forma única cada instância de uma entidade. Uma chave primária não pode ser nula e o valor que lhe é atribuído não deverá mudar ao longo do tempo. Uma chave primária também precisa de ser eficiente. Ou seja, os seus valores devem ser atribuídos de forma arbitrária, sem qualquer significado subjacente. Por vezes, nenhum dos atributos de uma entidade é suficiente para satisfazer o critério de uma chave primária eficaz. Nestes casos, os especialistas em desenho de bases de dados deverão criar uma chave primária "artificial".

4. Uma relação é uma ligação lógica entre duas entidades. Uma relação representa uma regra de negócio e pode ser expressa sob a forma de uma frase verbal. A maior parte das relações entre entidades são do tipo "um para muitos". Neste caso, uma instância de uma entidade principal relaciona-se com muitas instâncias de uma entidade secundária. Por exemplo, a relação entre EMPREGADO e LOCALIZACAO_LOJA seria representada da seguinte forma: uma LOCALIZACAO_LOJA (entidade principal) emprega vários EMPREGADOs (entidade secundária).

5. O segundo tipo de relação é a do tipo "muitos para muitos". Neste tipo de relação, muitas instâncias de uma entidade relacionam-se com muitas instâncias de outra entidade. As relações "muitos para muitos" precisam de ser resolvidas para evitar a redundância de dados. Estas relações podem ser resolvidas através da criação de uma entidade intermédia designada por entidade de referência cruzada. Esta entidade é constituída pelas chaves primárias das duas entidades originais. Desta forma, a relação "muitos para muitos" fica resolvida, dando lugar a duas relações "um para muitos". Por exemplo, a relação "muitos para muitos" de (vários) EMPREGADOs a serem alocados a (várias) TAREFAs pode ser resolvida com a criação de uma nova entidade chamada EMPREGADO_TAREFA. Desta forma, resolve-se a relação "muitos para muitos" com a criação de duas relações "um para muitos". Estas duas relações "um para muitos" consistem no seguinte: EMPREGADO (entidade principal) é alocado a EMPREGADO_TAREFA (entidade secundária) e TAREFA (entidade principal) é alocada a EMPREGADO_TAREFA (entidade secundária).

6. Existe uma "chave estrangeira" quando a chave primária de uma entidade principal consta de uma entidade secundária. Uma chave estrangeira exige que estejam presentes valores na entidade principal antes de valores similares serem inseridos na entidade secundária. O conceito de manter chaves estrangeiras é conhecido pela designação "integridade referencial".

7. As relações entre duas entidades podem ser classificadas como sendo "identificadoras" ou "não identificadoras". As relações identificadoras existem quando a chave primária da entidade principal está incluída na chave primária da entidade secundária. Por outro lado, existe uma relação não identificadora quando a chave primária da entidade principal está incluída na entidade secundária, mas não como parte da chave primária da entidade secundária. Por outro lado, as relações não identificadoras ainda podem ser classificadas como "obrigatórias" ou "não obrigatórias". Existe uma relação não identificadora obrigatória quando o valor na tabela secundária não pode ser nulo. Pelo contrário, existe uma relação não identificadora e não obrigatória quando o valor na tabela secundária pode ser nulo.

8. A cardinalidade ajuda-nos a compreender melhor a natureza da relação entre a entidade secundária e a entidade principal. A cardinalidade de uma relação pode ser determinada se colocarmos a seguinte questão: "quantas instâncias da entidade secundária se relacionam com cada instância da entidade principal"? Existem quatro tipos de cardinalidade: (1) um para zero ou mais (cardinalidade comum); (2) um para um ou mais (cardinalidade P); (3) um para zero ou um (cardinalidade Z); e (4) um para exactamente N (cardinalidade N).

Badeado num artigo de Brent Huscher com o título "Database Design and Modeling Fundamentals", publicado no site http://4guysfromrolla.com/webtech/datamodeling.shtml.