Introducción
Hoy en día, la discusión más común entre los gestores de almacenes de datos es determinar qué esquema está más orientado al rendimiento. Sin embargo, es fundamental saber que no se puede descartar ninguno de los enfoques de normalización o desnormalización, ya que ambos tienen pros y contras.
Por lo tanto, antes de detallar sus diferencias a través de casos de uso, vamos a ver la normalización y la desnormalización.
Normalización
La normalización es el acto de reorganización de los datos en un almacén de datos para cumplir con dos requisitos fundamentales:
- Eliminar la redundancia de datos almacenando todos los datos estrictamente en un solo lugar
- Asegurar la dependencia de los datos i.es decir, que todos los elementos de datos correspondientes se almacenen juntos
- DynamoDB de Amazon no tiene esquema, y cuando se crea una tabla en esta base de datos, se requiere especificar solo los atributos de la clave primaria, como la clave de ordenación y la clave de partición, o solo la clave de partición. Además, no tiene que definir ningún otro atributo de antemano.
- DynamoDB no respalda las operaciones de unión a través de las tablas.
La normalización es fundamental por varias razones, pero principalmente porque permite que los almacenes de datos ocupen el mínimo espacio en disco posible. Esto se traduce en una mejora del rendimiento.
Desnormalización
Esta estrategia de data warehousing se utiliza para mejorar la funcionalidad de una infraestructura de base de datos. La desnormalización llama a los datos redundantes a un almacén de datos normalizado para minimizar el tiempo de ejecución de las consultas específicas de la base de datos que unen los datos de muchas tablas en una sola.
De hecho, la interpretación de la desnormalización depende de la normalización, que se caracteriza como el acto de organizar una base de datos en tablas eliminando las repeticiones para implementar un caso de uso determinado. Recuerde, una base de datos desnormalizada nunca debe confundirse con una base de datos que nunca fue normalizada.
Normalización y desnormalización – Casos de uso
Amazon DynamoDB
La opción de un esquema normalizado o desnormalizado en una base de datos NoSQL, como DynamoDB, depende de su caso de uso. Sin embargo, los profesionales recomiendan diseñar sus tablas de DynamoDB con un esquema desnormalizado debido a las dos razones siguientes:
Sin embargo, hay ciertas situaciones en las que puede utilizar un esquema normalizado.
El esquema normalizado puede considerarse cuando:
- Se requiere almacenar elementos con tamaños superiores a 400 KB. Sin embargo, el tamaño máximo de elemento permitido en DynamoDB es de 400 KB. Por lo tanto, los atributos más grandes pueden almacenarse en Amazon S3 o en una tabla individual de DynamoDB.
- Espera varios patrones de acceso. Por ejemplo, tome una tabla de pedidos de productos, a la que se accede cada vez que un cliente pide un producto. Ahora tome una tabla de disponibilidad de productos, a la que solo se accede ocasionalmente. Ambas tablas tienen diferentes requisitos previos de capacidad de lectura & de escritura.
- Sus aplicaciones realizan varias actualizaciones. En Amazon DynamoDB, una WCU (unidad de capacidad de escritura) se perfila como una escritura/segundo, para un elemento de 1 KB de tamaño. Además, las numerosas escrituras de elementos de datos de más de 1 KB influirán en el número de WCUs agotadas por escritura. Además, aunque se actualice un solo atributo, el cálculo de las WCU depende del tamaño del elemento completo.
El esquema desnormalizado puede considerarse cuando:
- Se requiere almacenar ítems pequeños con pocos atributos. Además, el tamaño del ítem no debe exceder los 4 KB para las lecturas. Recuerde que una RCU (unidad de capacidad de lectura) se especifica como una lectura/segundo para un elemento de menos de 4 KB de tamaño. Alternativamente, para las escrituras, el tamaño del ítem no debería exceder de 1 KB.
Sus aplicaciones deben leer así como escribir datos en un entorno de tráfico intenso, sin considerar la sincronización y consistencia de los datos en varias tablas.
Caso de uso de la normalización en el almacenamiento de datos sanitarios
Hoy en día, la normalización de datos tiene un papel más amplio en una serie de entornos sanitarios, ya que ofrece un marco para interpretar los datos para facilitar varios casos de uso.
Para simplificar las cosas, lo siguiente es un área común que emplea la normalización de datos:
Hacer que los datos sean útiles dentro del almacén de datos
Un almacén de datos típico obtiene los datos de los pacientes de una serie de sistemas clínicos y de TI. Esto se debe a que las organizaciones quieren centralizar sus proyectos de informes, programas de calidad, utilizar los datos para diseñar modelos predictivos y utilizar los datos clínicos y de reclamaciones para supervisar el proceso de atención sanitaria.
Entonces, ¿cuáles son las aplicaciones de los datos normalizados en la atención sanitaria?
Digamos que un hospital pretende establecer una tendencia de los niveles de hemoglobina A1C para un grupo de pacientes diabéticos. Sin embargo, es habitual que los sistemas de laboratorio pongan sus códigos de laboratorio propios y personales que no están estandarizados en LOINC. El almacén de datos del hospital bien puede poseer los resultados del laboratorio A codificados como 4321/Hgb A1c en sangre. En el mismo repositorio, el hospital puede tener los resultados del laboratorio B estandarizados ya como código 17855-8 en LOINC.
Ambos representan resultados de laboratorio de A1C, pero los datos deben ser normalizados a un estándar como LOINC para que el sistema de salud pueda interpretar y analizar correctamente ambos resultados de laboratorio.
Caso de uso de la normalización
Considere una plataforma de blogs en la que se almacenan las publicaciones y los usuarios. Los posts hacen referencia a sus autores a través de un campo Author_ID. Usted almacenaría estas dos entidades en colecciones separadas. Esto se debe a que los posts contendrán vistas, gustos, comentarios y otras estadísticas, y por lo tanto, necesitarán más rendimiento de escritura en comparación con los usuarios.
Ahora, tal vez se emplace un feed de los posts más recientes y el feed agregará directamente los autores en cada post. En el almacenamiento de datos, esto se logra estableciendo el Author_ID de las publicaciones como una clave externa, seguido de la consulta de las tablas de usuarios y publicaciones con una transformación de unión para construir el feed en tiempo real.
Sin embargo, esa opción no está disponible aquí; en su lugar, tendrá que desnormalizar sus datos conservando el feed en un contenedor individual que está a la espera de ser consultado. Este contenedor llevará una copia de los datos almacenados en los contenedores de usuarios y posts, con los autores consolidados en los posts.
Conclusión
El esquema que elija para su almacén de datos depende principalmente de los patrones de acceso de las aplicaciones y del tamaño de sus elementos de datos. Puede consultar a nuestros arquitectos de soluciones para garantizar el uso de técnicas de automatización avanzadas al normalizar o desnormalizar su almacén de datos.
