|
|
|
O 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:
|
|
|
|
|
|
|
|
1. **Responder as perguntas estratégicas do negócio**.
|
|
|
|
2. **Identificar e definir conceitos (entidades)**.
|
|
|
|
3. **Definir o relacionamentos entre as entidades**.
|
|
|
|
4. **Definição do 'modelo conceitual'.**
|
|
|
|
5. **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):
|
|
|
|
* 1FN (atomicidade)
|
|
|
|
* 2FN (tabelas aninhadas)
|
|
|
|
* 3FN (atributos independentes)
|
|
|
|
|
|
|
|
Ao final, teremos um modelo lógico normalizado, indicando as propriedades e relacionamentos corrigidos.
|
|
|
|
|
|
|
|
## 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. |
