Modelo de Dados
PADRÕES DE CONSTRUÇÃO DE MODELOS DE DADOS
Introdução
A modelagem de dados é um processo crucial no design de sistemas de informação. Ela envolve a definição e análise dos requisitos de dados necessários para dar suporte aos processos de negócios de uma organização. Os padrões de modelagem de dados ajudam a garantir consistência, clareza e eficiência no design de bancos de dados.
Objetivo
Estabelecer diretrizes, padrões e nomenclaturas para a construção de modelos de dados.
Aplicação
Aplica-se a toda a SEDUC.
Gestão de Dados
É a função na organização que cuida do planejamento, controle e entrega de ativos de dados e de informação. Esta função inclui as disciplinas do desenvolvimento, execução e supervisão de planos, políticas, programas, projetos, processos, práticas e procedimentos que controlam, protegem, distribuem e aperfeiçoam o valor dos ativos de dados e informações. (DAMADMBOK ®)
Administração de Dados
É a função responsável por desenvolver e administrar de modo centralizado as estratégias, procedimentos e práticas para o processo de gerência dos recursos de dados e aplicativos, incluindo planos para a sua definição, padronização, organização, proteção e utilização. (BARBIERI, Carlos)
Administrador de Dados - AD
Responsável por estabelecer e disseminar padrões de administração de dados, políticas, boas práticas e procedimentos para a construção e validação dos modelos de dados da empresa. Também é responsável por modelar ou apoiar a construção e/ou alteração dos modelos de dados conceituais, lógicos e físicos, assim como pela implementação e atualização das estruturas de dados nos bancos de dados em ambiente de desenvolvimento.
Modelos Conceituais
Diagrama Entidade-Relacionamento (ER)
O Diagrama Entidade-Relacionamento é um padrão amplamente utilizado para representar dados de forma conceitual. Ele mostra entidades (objetos do mundo real) e os relacionamentos entre elas. Por exemplo, uma entidade 'Cliente' pode estar relacionada a uma entidade 'Pedido'.
Modelagem Orientada a Objetos
A modelagem orientada a objetos usa conceitos de objetos e classes para modelar dados. Cada objeto representa uma instância de uma classe, que define atributos e comportamentos.
Modelos Lógicos
Modelo Relacional
O modelo relacional organiza dados em tabelas (ou relações) que são compostas por linhas e colunas. Cada tabela possui uma chave primária que identifica unicamente cada registro e pode ter chaves estrangeiras para representar relacionamentos.
Modelo de Dados Hierárquico
O modelo hierárquico organiza dados em uma estrutura de árvore, onde cada entidade tem um único pai, exceto a raiz. Esse modelo é menos flexível que o modelo relacional, mas pode ser eficiente para certos tipos de dados.
Modelo de Dados em Rede
O modelo de dados em rede é uma extensão do modelo hierárquico que permite que uma entidade tenha vários pais. Ele usa um grafo para representar as relações complexas entre entidades.
Modelos Físicos
Normalização
A normalização é um processo para organizar os dados em tabelas para reduzir a redundância e melhorar a integridade dos dados. As formas normais (1NF, 2NF, 3NF, BCNF) são regras que guiam esse processo.
Desnormalização
A denormalização é o processo inverso da normalização, onde tabelas são combinadas para melhorar a performance de consultas em situações onde a performance é mais crítica que a integridade dos dados.
Melhores Práticas para Nomear Tabelas, Colunas e Descrição das Colunas
Nomeação/Especificação de Entidades e Tabelas
- Use nomes descritivos: O nome da tabela deve indicar claramente o que a tabela contém um substantivo, função ou evento. Por exemplo, PI_ACD_Alunos, PI_ACD_Aulas, PI_LOT_Cursos, PI_LOT_Diciplinas.
- Pluralize nomes de entidades: Use nomes no plural e sem acentuação para indicar que a tabela contém múltiplos registros de uma entidade. Por exemplo, Alunos em vez de Aluno.
- Evite abreviações: Nomes abreviados podem ser difíceis de entender, mas se for necessário usar 5 caracteres. Prefira nomes completos, como Endereco em vez de descEndereco.
Nomeação de Colunas
- Use nomes significativos: O nome da coluna deve indicar claramente o que o dado representa. Por exemplo, DataMatricula, NomeAluno, PercentualFaltas.
- Seja consistente com o estilo de nomeação: Use um estilo de nomeação consistente, como CamelCase (NomeAluno) ou snake_case (nome_aluno), e mantenha o mesmo padrão em todo o banco de dados.
- Inclua a unidade de medida, se aplicável: Se a coluna representa uma medida, inclua a unidade no nome. Por exemplo, Peso_kg, Altura_cm.
Descrição das Colunas
- Forneça descrições detalhadas: Use o campo de comentário ou documentação da coluna para descrever detalhadamente o que a coluna representa e como deve ser usada.
- Inclua restrições e regras de validação: Documente quaisquer restrições, como valores permitidos ou regras de validação.
- Explique a origem dos dados: Se os dados são derivados de outra fonte ou calculados, explique a origem ou o cálculo.
Exemplos de Boas Práticas
Tabelas
| Nome da Tabela | Descrição |
|---|---|
| censo_00 | IDENTIFICAÇÃO DA UNIDADE ESCOLAR - Sequência de campos que identificam a Unidade Escolar. |
| censo_10 | REG. ESTRUTURA FISICA DA UNIDADE ESCOLA - Sequência estrutura física da unidade escolar. |
| censo_20 | REG. DA TURMA - Sequência de campos que identificam a estrutura da escola. |
| censo_30 | REG. PESSOA FISICA - Sequência de campos que identificam a pessoa física. |
| censo_40 | REG. DO DIRETOR - Sequência de campos que identificam os dados do diretor |
| censo_50 | REG. DE PROFES./TURMA/DISCIPLINA - Sequência de campos que identificam os dados do professor/turma/disciplina |
| censo_60 | REG. ALUNO/TURMA - Sequência de campos que identificam os dados do Aluno vinculado a turma |
Prefixo de identificação de tabelas com tipo específico
| Prefixo | Descrição |
|---|---|
| LG | Tabelas de Log |
| HT | Tabelas de historicos |
| TP | Tabelas temporarias |
| FT | Tabelas de fato |
| DI | Tabelas de dimensão |
| SA | Tabelas de Staging area |
| AT | Tabelas de área de trabalho |
| OD | Tabelas de ODS (Operational Data Store) |
Colunas
Colunas
| Tabela | Nome da Coluna | Descrição |
|---|---|---|
| Censo_20 | id_20 | Identificador autoincremento. |
| Censo_20 | data_inclusao | Data/Hora de inclusão. |
| Censo_20 | item_20_001 | Tipo de registro. |
| Censo_20 | item_20_002 | Código de escola - Inep. |
| Censo_20 | item_20_003 | Código da Turma na Entidade/Escola. |
| Censo_20 | item_20_004 | Código da Turma - Inep. |
| Censo_20 | item_20_005 | Nome da Turma. |
Restriçõe de Integridade
Chave Primária
Utilizar o prefixo pk seguido do nome da entidade:
| Exemplo |
|---|
| pk_servidor |
Chave Alternativa
Utilizar o prefixo ak seguido do nome da entidade e do nome do(s) campo(s) que a compõem:
| Exemplo |
|---|
| ak_servidor_nome |
Chave Estrangeira
Utilizar o prefixo fk seguido do nome da entidade que possui a chave estrangeira e do nome da entidade à qual a chave faz referência:
| Exemplo |
|---|
| fk_servidor |
Sequência
Utilizar o prefixo seq seguido do nome do objeto ao qual a seqüência atende:
| Exemplo |
|---|
| seq_dependente |
| seq_registro |
Aviso
Observação: O uso deste recurso, bem como de campos do tipo auto-incremento, não é recomendado pois afeta negativamente a portabilidade do sistema. Aconselha-se a criação de uma tabela auxiliar para geração de seqüências, com estrutura
Stored Procedures
Utilizar o prefixo sp seguido por uma descrição do que a stored procedure faz
| Exemplo |
|---|
| sp_NovaMatricula |
| sp_nova_matricula |
Aviso
Observação: O uso deste recurso não é recomendado pois afeta negativamente a portabilidade do sistema.
Triggers
Utilizar os prefixos ti (insert), tu (update) ou td (delete) seguido do nome da tabela:
| Exemplo | Modelo |
|---|---|
| tr_PI_ACD_OfertaEscola_Insert | ti_PI_ACD_OfertaEscola |
| tr_PI_ACD_OfertaEscola_Update | tu_PI_ACD_OfertaEscola |
| tr_PI_ACD_OfertaEscola_Delete | td_PI_ACD_OfertaEscola |
Info
Para cada trigger deve existir uma stored procedure associada que recebe como parâmetro
os campos da tabela que necessitam validação ou atualização:
| Exemplo |
|---|
| sp_ti_PI_ACD_OfertaEscola |
| sp_tu_PI_ACD_OfertaEscola |
| sp_td_PI_ACD_OfertaEscola |
Aviso
Observação: O uso deste recurso não é recomendado pois afeta negativamente a portabilidade do sistema.
Rules
Utilizar os prefixos rs (select), ri (insert), ru (update) ou rd (delete) seguido do nome da tabela:
| Exemplo |
|---|
| rs_processo |
Considerações Finais
A escolha do modelo de dados e dos padrões a serem utilizados depende dos requisitos específicos do projeto e das características do sistema a ser desenvolvido. Uma boa modelagem de dados é fundamental para garantir que o sistema seja escalável, eficiente e fácil de manter.