Rafael CompanhoniO processo de modelagem segue as orientações dos livros 'Data Modeling for MongoDB' de Steve Hoberman e 'Projeto de Banco de Dados' de Carlos Heuser.
Modelo Conceitual
Tem como objetivo dar uma visão geral dos requisitos do negócio e consiste nas seguintes tarefas:
- Responder as perguntas estratégicas do negócio.
- Identificar e definir conceitos (entidades).
- Definir o relacionamentos entre as entidades.
- Definição do 'modelo conceitual'.
- Revisar com o cliente que o modelo está correto.
Modelo Lógico
Nesta etapa já temos as entidades e relacionamentos então o objetivo é normalizar o modelo (observar que até este ponto o processo serve tanto para bancos relacionais como para não-relacionais). Consiste nas seguintes etapas:
- Criação do 'Dicionário de Dados': documentação que define claramente os tipos de cada propriedade (de cada entidade) e uma descrição do significado das propriedades que possuírem regras específicas.
- Normalização.
Primeira Forma Normal (atomicidade dos atributos)
Todo atributo deve possuir um único valor e deve prover uma informação que é pertinente apenas à chave primária da entidade. Na prática, observe os seguintes pontos:
- Atributos multivalorados: quando um único atributo possui mais de um valor.
- Atributos repetidos: atributos que possuem o mesmo significado e se repetem para uma mesma entrada.
No exemplo, o atributo multivalorado Nome foi quebrado em Nome e Sobrenome e os atributos repetidos Telefone1 e Telefone2 foram reduzidos para Telefone apenas.
Segunda Forma Normal (entidades aninhadas)
A entidade estará na 2FN se já estiver na 1FN e se cada atributo não-primário for dependente exclusivamente da chave-primária. No exemplo a entidade original possui propriedades referentes ao fabricante e ao modelo de uma escova de dentes. Após a separação em duas entidades todos os atributos não-chave são pertinentes apenas à chave primária.
Terceira Forma Normal (transitividade funcional)
Ocorre quando uma propriedade é 'computada' a partir de uma ou mais outras propriedades (não-chave) da entidade.
No exemplo abaixo, a entidade Funcionario possui as propriedades DataAdminissao e DataDemissao. Adicionalmente possui uma propriedade Ativo, que indica se o funcionário ainda encontra-se contratado pela empresa. A propriedade Ativo na realidade é uma propriedade que se pode inferir a partir de DataDemissao, ou seja, é redundante e pode ser eliminada.
Modelo Físico
Esta é a etapa que realmente considera de que forma implementaremos o modelo no MongoDB. Consiste nas seguintes etapas:
Aninhamento ou Referência
Basicamente é decidir se uma coleção será aninhada em outra ou se serão distintas e relacionadas por chave primária. Os 5 motivos principais para aninhamento de acordo com Hoberman:
- Requirements state that data from two or more entities are frequently queried together.
- The child is a dependent entity -- evaluate if an entity can be identified uniquely by its primary key. If it's dependant on other entity's primary key then evaluate if the dependent entity should be embedded or referenced (depends on how often the business requirements require that). An identifying relationship is a much stronger relationship than non-identifying, giving us more weight towards embedding the weak entity within the strong entity so that we have just one document.
- There is a one-to-one relationship between two entities.
- Similar volatility. If the entity you are considering embedding within another entity experiences updates, inserts, and deletes at a similar rate to the entity it will be embedded into, there is a stronger reason to combine them.
- If an entity is referenced by many others than it is more efficient and less error prone to reference the entity that is needed by many other entities. Another example are many-to-many relationships where the associative entity (the entity that resolves the many-to-many), is referenced by at least two other entities. In these situations it may be better to reference rather than embed.
Registro 'histórico' das entidades
Avaliar quais entidades precisam ter sua 'história' mantida. Acredito que no contexto da Mentha isso não é importante mas como exemplo, poderíamos armazenar todo o histórico de preços que um dado produtor configurou ao longo de várias semanas para desta forma ter uma ideia de como os preços têm variado por comunidade.
Índices e Sharding
Mapear quais as consultas mais comuns e incluir indices apropriados para otimização. Sharding refere-se a métodos para distribuir o banco em múltiplas máquinas.
Implementação
Desenvolver o script para criação do banco de dados propriamente.