Resumo

Neste módulo, aprendemos que:

1. Enquanto os modelos conceituais têm livre arbítrio para a descrição das entidades e atributos, quando transformamo-los em modelos lógicos, precisamos adaptar a nomenclatura. Para tal, devemos evitar símbolos, números, caracteres especiais, letras acentuadas e espaços em branco.
2. As entidades e atributos devem possuir nomes fáceis de serem compreendidos. Devemos evitar acrônimos e reduções em nomes que prejudicam o entendimento. De outra forma, todo modelo deve contar com seu dicionário de dados que explique, em detalhes, cada entidade e atributo.
3. Outro fator importante na conversão de um modelo conceitual para lógico é a preparação correta para os tipos de dados. Isso será fundamental para uma perfeita compatibilidade, no momento em que criarmos o modelo físico dentro do SGBD.
4. Há vários padrões para nomear entidades e atributos, não há um padrão melhor que o outro, apesar de alguns serem mais compreensíveis e menos complexos para se analisar. É uma decisão de projeto a escolha do padrão mais adequado.
5. Há vários tipos de índices que podem ser criados em um modelo. Os índices servem para ordenar campos (aumentando a performance das operações de consultas) e/ou para criar regras de unicidade (para impedir dados duplicados). Os índices devem ser aplicados em campos que são rotineiramente consultados pelas aplicações. Criar muitos índices pode diminuir a performance do banco de dados.
6. A normalização de dados provê uma adequação ao modelo de dados para o aumento da qualidade da forma de organização das informações.
7. As diretrizes de modelagem são regras básicas que existem para que o projetista crie modelos de alta qualidade, fáceis de analisar, programar e manter. Essas regras são fundamentais para um bom projeto de software.
8. A diretriz 1 define que dados redundantes devem ser eliminados, criando tabelas auxiliares que receberão os dados. Também devemos evitar nomes de entidades e atributos difíceis de se interpretar.
9. A diretriz 2 define que devemos evitar anomalias de SQL, como instruções de UPDATE que realizam inserções de dados. Para tanto, devemos adequar nosso modelo de dados. Quando não for possível ou desejável, devemos documentar essas anomalias a fim de subsidiar as equipes de desenvolvimento de sistemas.
10. A diretriz 3 dita que entidades com muitos atributos nulos devem, preferencialmente, ter esses atributos definidos em entidades associadas.
11. A diretriz 4 afirma que as relações entre as tabelas devem ser feitas sempre por chaves que as identifiquem. Não deve haver chaves nulas ou que permitam valores duplicados.