Paso 1: identificar los casos de uso y el modelo de datos lógico

Una empresa automotriz desea crear un sistema de gestión de componentes transaccional para almacenar y buscar todas las piezas de automóviles disponibles y establecer relaciones entre los diferentes componentes y piezas. Por ejemplo, un automóvil contiene varias baterías, cada batería contiene varios módulos de alto nivel, cada módulo contiene varias celdas y cada celda contiene varios componentes de bajo nivel.

Por lo general, para crear un modelo de relación jerárquica, utilizar una base de datos de gráficos como Amazon Neptune es una mejor opción. Sin embargo, en algunos casos, Amazon DynamoDB es una mejor alternativa para el modelado jerárquico de datos debido a su flexibilidad, seguridad, rendimiento y escalabilidad.

Por ejemplo, puede crear un sistema en el que entre el 80 y el 90 por ciento de las consultas sean transaccionales, en el que DynamoDB se adapta bien. En este ejemplo, entre el 10 y el 20 por ciento restante de las consultas son relacionales, por lo que una base de datos de gráficos como Neptune encaja mejor. En este caso, incluir una base de datos adicional en la arquitectura para atender solo entre el 10 y el 20 por ciento de las consultas podría aumentar el costo. También añade la carga operativa que supone el mantenimiento de varios sistemas y la sincronización de los datos. En su lugar, puede modelar ese 10 o 20 por ciento de consultas relacionales en DynamoDB.

Crear un diagrama de un árbol de ejemplo para los componentes de un automóvil puede ayudarlo a trazar la relación entre ellos. En el siguiente diagrama, se muestra un gráfico de dependencia con cuatro niveles. El CM1 es el componente de nivel superior del propio automóvil de ejemplo. Tiene dos subcomponentes para dos baterías de ejemplo, el CM2 y CM3. Cada batería tiene dos subcomponentes, que son los módulos. El CM2 tiene los módulos CM4 y CM5, y el CM3 tiene los módulos CM6 y CM7. Cada módulo tiene varios subcomponentes, que son las celdas. El módulo CM4 tiene dos celdas, CM8 y CM9. El CM5 tiene una celda, CM10. Los CM6 y CM7 aún no tienen celdas asociadas.

En esta guía, se utilizará este árbol y los identificadores de sus componentes como referencia. Un componente superior se denominará principal y un subcomponente se denominará secundario. Por ejemplo, el componente CM1 superior es el principal de CM2 y CM3. El CM2 es el principal de CM4 y CM5. Esto representa de forma gráfica las relaciones entre principales y secundarios.

En el árbol, puede ver el gráfico de dependencia completo de un componente. Por ejemplo, el CM8 depende del CM4, que depende del CM2, que depende del CM1. El árbol define el gráfico de dependencia completo como la ruta. Una ruta describe dos cosas:

Rellenar las plantillas para los requisitos empresariales:

Facilite información sobre sus usuarios:

Facilite información sobre las fuentes de datos y sobre cómo se van a ingerir los datos:

Facilite información sobre cómo se consumirán los datos: