Teoría BBDD

12
Mar
2024

Modelo estrella en profundidad

Los modelos de datos son una forma de representar la información que se almacena en una base de datos. Existen diferentes tipos de modelos de datos, cada uno con sus ventajas e inconvenientes, según el tipo de datos que se quiera gestionar y el objetivo que se persigue. En este artículo vamos a hablar de los modelos de datos en estrella, un tipo de modelo muy utilizado en el ámbito del Business Intelligence y el análisis de datos. Veremos qué son, cómo se construyen y qué beneficios aportan frente a un modelo relacional, que es el más común en las bases de datos relacionales.

¿Qué es un modelo de datos en estrella?

Un modelo de datos en estrella es una forma de organizar los datos en una base de datos que se basa en dos tipos de tablas: una tabla central o tabla de hechos, y varias tablas periféricas o tablas de dimensiones.

Tabla de hechos

La tabla de hechos contiene los datos numéricos o medidas que se quieren analizar, como por ejemplo las ventas, los ingresos, los costes, etc. Cada fila de esta tabla representa un hecho o evento que ha ocurrido en el negocio.

Tablas de dimensiones

Las tablas de dimensiones contienen los atributos o características que describen los hechos, como por ejemplo el cliente, el producto, la fecha, la ubicación, etc. Cada tabla de dimensiones tiene una clave primaria que se relaciona con una clave foránea en la tabla de hechos.

La estructura resultante tiene forma de estrella, donde la tabla de hechos está en el centro y las tablas de dimensiones la rodean. Por ejemplo, si queremos analizar las ventas por cliente, producto y fecha, tendríamos una tabla de hechos con las columnas venta_id, cliente_id, producto_id, fecha_id y cantidad_vendida, y tres tablas de dimensiones con las columnas cliente_id, nombre_cliente, producto_id, nombre_producto y fecha_id, año, mes y día.

Ventajas de un modelo de datos en estrella

Un modelo de datos en estrella tiene varias ventajas frente a un modelo relacional, especialmente para el análisis de datos. Algunas de estas ventajas son:

  • Simplifica las consultas: al tener menos tablas y menos relaciones entre ellas, las consultas son más sencillas y rápidas de escribir y ejecutar. Además, al tener los atributos en las tablas de dimensiones, se evita tener que hacer muchos joins para obtener la información deseada.
  • Facilita el análisis multidimensional: al tener los datos organizados por dimensiones, se puede realizar fácilmente el análisis desde diferentes perspectivas o ángulos. Por ejemplo, se puede analizar las ventas por cliente, por producto o por fecha, o combinar varias dimensiones para obtener resultados más detallados.
  • Mejora el rendimiento: al tener menos tablas y menos columnas, se reduce el espacio ocupado por los datos y se optimiza el acceso a los mismos. Además, al tener los datos numéricos en la tabla de hechos, se pueden aplicar técnicas como la agregación o el precálculo para mejorar la velocidad de las consultas.
  • Favorece la comprensión: al tener los datos más estructurados y organizados por temas o conceptos, se facilita la comprensión y el uso de los mismos por parte de los usuarios finales o analistas.

Modelo de Estrella vs Modelo Relacional

Un modelo relacional es el tipo de modelo más habitual en las bases de datos relacionales. Se basa en normalizar los datos para evitar la redundancia y la inconsistencia. Para ello, se dividen los datos en varias tablas relacionadas entre sí mediante claves primarias y foráneas.

Un modelo relacional tiene como objetivo principal garantizar la integridad y la calidad de los datos. Sin embargo, también tiene algunos inconvenientes para el análisis de datos. Algunos de estos inconvenientes son:

  • Complejidad en las consultas: La estructura relacional, ideal para entornos OLTP tienen muchas tablas y muchas relaciones entre ellas. Esto hace las consultas de análisis de datos más complejas y lentas de escribir y ejecutar. Además, al tener los atributos repartidos por varias tablas, se requieren muchos joins para obtener la información deseada.
  • Dificulta el análisis multidimensional: al tener los datos dispersos por varias tablas, se dificulta el análisis desde diferentes perspectivas o ángulos. Tenemos que pensar que este modelo está pensado para procesos específicos eficientes y no para un análisis global. Por ejemplo, para analizar las ventas por cliente, producto y fecha, se tendría que acceder a varias tablas y combinarlas mediante joins.
  • Rendimiento: al tener muchas tablas y muchas columnas, se incrementa el espacio ocupado por los datos y se ralentiza el acceso a los mismos cuando se quieren analizar todos juntos. Además, al tener los datos numéricos repartidos por varias tablas, se dificulta la aplicación de técnicas como la agregación o el precálculo para mejorar la velocidad de las consultas.
  • Comprensión: al tener los datos estructurados y organizados por temas o conceptos, se complica la visualización y el uso de los mismos de manera centralizada por parte de los usuarios finales o analistas.

Conclusión

Los modelos de datos en estrella son una forma de organizar los datos en una base de datos que se adapta muy bien al ámbito del Business Intelligence y el análisis de datos. Al tener una estructura simple y clara, con una tabla de hechos y varias tablas de dimensiones, se facilita la realización de consultas, el análisis multidimensional, el rendimiento y la comprensión de los datos.
Los modelos de datos en estrella son diferentes de los modelos relacionales, que son los más comunes en las bases de datos relacionales. Estos últimos, se basan en normalizar los datos para evitar la redundancia y la inconsistencia, pero también presentan algunos inconvenientes para el análisis de datos, como la complejidad de las consultas, la dificultad del análisis multidimensional, la reducción del rendimiento y la complicación de la comprensión de los datos.

Esperamos que te haya gustado este artículo y que te haya servido para aprender algo nuevo. Si tienes alguna duda o comentario, no dudes en dejarnos un mensaje en Twitter, por mail o dejarnos en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir. 

Publicado por Roberto Carrancio en Power BI, 1 comentario
11
Mar
2024

Consejos para un buen modelo de datos

¿Te gustaría mejorar el rendimiento, la seguridad y la calidad de tus bases de datos en SQL Server? ¿Quieres conocer las mejores prácticas para un buen modelo de datos? Entonces este artículo es para ti. Vamos a explicar, cómo diseñar y optimizar tus modelos de datos, siguiendo las recomendaciones de los expertos. ¡Sigue leyendo!

¿Qué es el modelado de datos?

El modelado de datos es el proceso de definir la estructura, las relaciones y las restricciones de los datos que se almacenan en una base de datos. El modelado de datos tiene como objetivo crear un diseño lógico y físico que sea coherente, eficiente y fácil de mantener.

¿Por qué es importante?

El modelado de datos influye directamente en el rendimiento, la seguridad y la calidad de los datos por lo que es muy importante para nosotros. Un buen modelo de datos nos va a permitir, por ejemplo, reducir el espacio ocupado por los datos y mejorar el tiempo de respuesta de las consultas. No solo eso, a menor espacio mayor velocidad en las copias de seguridad y en los planes de mantenimiento, aspecto de vital importancia en entornos grandes y con pocas ventanas de mantenimiento. Además nos evitará la redundancia, la inconsistencia y la corrupción de los datos y facilitará el acceso, la manipulación y el análisis. ¿Necesitas más motivos? Porque esto no es todo, cumplir estas buenas prácticas no solo garantiza integridad, confidencialidad y disponibilidad de los datos, también va a simplificar el desarrollo, la documentación y la evolución de la base de datos.

Tipos de definición de modelos de datos

Antes de entrar en los modelos de datos más comunes, tenemos que ver la forma en la que los definimos. Atendiendo a esto, existen diferentes tipos según el nivel de abstracción y el grado de detalle que presentan. Los más comunes son:

  • Conceptual: representa los conceptos y las entidades del dominio del problema, así como sus atributos y relaciones. Este modelo es independiente de nuestro sistema gestor de base de datos (SGBD) y se suele expresar mediante diagramas entidad-relación (ER).
  • Lógico: especifica las tablas, las columnas, las claves y las restricciones que se van a implementar en la base de datos. Es un modelo dependiente del SGBD y se suele expresar mediante diagramas relacionales o notación SQL.
  • Físico: describe los detalles técnicos de cómo se almacenan y organizan los datos en el disco. Incluye aspectos como el tamaño, el tipo de dato, el índice, la partición o el formato de almacenamiento. Es un modelo específico del SGBD y se suele expresar mediante scripts SQL o herramientas gráficas.

Tipos de modelos de datos

Como hemos comentado antes, existen varios tipos de modelos de datos según las necesidades de cada sistema y no todos están pensados para bases de datos relacionales de las que nos gustan a nosotros.

Modelo relacional

El modelo relacional es el más usado y se basa en el concepto de tabla con filas y columnas que todos conocemos. Cada fila representa un registro o una entidad, y cada columna representa un atributo o una propiedad. Las tablas se relacionan entre sí mediante claves primarias y foráneas, que son valores únicos que identifican a cada registro. El modelo relacional permite realizar consultas complejas y garantiza la integridad y la consistencia de los datos. Este modelo es el usado por las bases de datos relacionales y se aconseja mantener las tablas por lo menos en la tercera forma normal.

Modelo dimensional

Es un modelo alternativo al relacional, que se usa principalmente para fines analíticos y de inteligencia de negocios. El modelo dimensional se basa en el concepto de cubo, que es una estructura multidimensional que contiene medidas y dimensiones. Las medidas son los valores numéricos que se quieren analizar, como ventas, ingresos o costes. Las dimensiones son los atributos que describen las medidas, como tiempo, producto o cliente. El modelo dimensional permite realizar análisis rápidos y flexibles sobre grandes volúmenes de datos sin embargo no es lo ideal para transacciones que buscan el detalle de un registro. Igual que para el modelo relacional la recomendación es llegar, al menos, a 3FN en estos casos es común quedarse en la segunda forma normal. Este tipo de modelo está quedando en desuso en favor de los siguientes que vamos a ver.

Modelo estrella 

Es una evolución del modelo dimensional, que se caracteriza por tener una tabla central llamada tabla de hechos, que contiene las medidas, y varias tablas periféricas llamadas dimensiones, que contienen los atributos. El modelo estrella tiene una estructura simple y eficiente, que facilita el acceso y la navegación por los datos de manera rápida cuando se desea hacer agregaciones y operaciones de consulta masiva. Por lo general encontraremos este modelo en Datamarts y DataWarehouses donde los datos provenientes de otros orígenes ya han sido clasificados y tratados mediante ETLs y esperan a ser usados en reportes de BI.

Modelo copo de nieve 

Pueden existir ocasiones en las que un modelo estrella se nos quede corto. En estas ocasiones, necesitaremos juntar varios modelos de estrellas mediante relaciones más o menos normalizadas, es decir, dividimos el modelo de estrella en subtablas para evitar la redundancia de datos. Esto se llama modelo copo de nieve y tiene una estructura más compleja y detallada, que reduce el espacio ocupado por los datos pero aumenta el número de tablas y las consultas necesarias.

Pasos para realizar un buen modelado de datos en SQL Server?

Ahora que ya sabemos que tipos de modelo existen y cómo definirlos vamos a ver los pasos necesarios para diseñar un buen modelo de datos:

  1. Analizar los requisitos del negocio y del usuario, identificando las entidades, los atributos y las relaciones que se necesitan representar en la base de datos.
  2. Diseñar el modelo conceptual, utilizando diagramas ER o herramientas CASE (Computer-Aided Software Engineering).
  3. Normalizar el modelo conceptual, aplicando las reglas de normalización para eliminar las anomalías y las dependencias funcionales.
  4. Diseñar el modelo lógico, traduciendo las entidades y relaciones del modelo conceptual en tablas y columnas del modelo de datos. Definir las claves primarias, las claves foráneas y las restricciones de integridad referencial si las hubiera.
  5. Diseñar el modelo físico, ajustando el modelo lógico a las características de nuestro SGBD. Elegir los tipos de datos adecuados, crear los índices necesarios, definir las políticas de seguridad y establecer las estrategias de particionamiento, copia de seguridad y recuperación.
  6. Implementar el modelo físico, generando los scripts SQL o utilizando herramientas gráficas como SQL Server Management Studio (SSMS) o SQL Server Data Tools (SSDT).
  7. Validar y verificar el modelo físico, comprobando que cumple con los requisitos del negocio y del usuario, que no contiene errores ni inconsistencias y que ofrece un buen rendimiento.

Conclusión

El modelado de datos es una tarea fundamental para crear bases de datos eficientes, seguras y de calidad en SQL Server. Siguiendo las buenas prácticas que te hemos mostrado en este artículo, podrás diseñar e implementar modelos de datos que satisfagan las necesidades de tu negocio y tus usuarios. 

Esperamos que te haya gustado este artículo y que lo pongas en práctica.  Si tienes alguna duda o comentario, no dudes en dejarnos un mensaje en Twitter, por mail o dejarnos en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir. 

Publicado por Roberto Carrancio en Power BI, Rendimiento, SQL Server, 1 comentario
08
Ene
2024

Formas Normales o Normalización de Bases de Datos

En el pasado post, recreamos con IA una entrevista de trabajo para DBA SQL Server. Una de las preguntas de esta entrevista era sobre la normalización de bases de datos y os comenté que esto era muy importante. Es teoría básica de base de datos, pero tan básica que son las normas sobre las que se construyen las bases de datos. Como aún no hemos hablado de ello y todo el que trabaje con base de datos (DBA o usuario) debe conocerlo vamos a dedicarle el artículo de hoy. 

Desde ya os aviso que es un tema puramente teórico, voy a intentar poner ejemplos prácticos para que sea lo más claro posible pero puede que se nos haga a todos un poco de bola. Es normal. Que esto no os pare, como decimos es la base de todo buen profesional de las bases de datos relacionales y debemos conocerlo al detalle, como los mandamientos de la biblia.

¿Qué es la normalización y por qué es tan importante? 

La normalización es el proceso de organizar los datos en una base de datos de forma que se eviten las redundancias, las inconsistencias y las anomalías. Se basa en aplicar una serie de reglas, llamadas formas normales, que definen cómo deben estructurarse las tablas y las relaciones entre ellas. 

La normalización tiene muchos beneficios, como mejorar el rendimiento, facilitar el mantenimiento, garantizar la integridad y optimizar el espacio de almacenamiento.

¿Cómo se aplica la normalización?

Como hemos comentado existen varias formas normales, desde la primera forma normal (1FN) hasta la sexta forma normal (6FN). Cada una de ellas con sus propios requisitos y objetivos. Sin embargo, no siempre vamos a necesitar aplicar todas las formas normales, depende del tipo de datos y del diseño de la base de datos.

A continuación vamos a explicar brevemente cada forma normal con algunos ejemplos.Para el ejemplo vamos a partir de este conjunto de datos que tenemos y vamos a tratar de normalizarlo:

Normalización Origen

Primera forma normal (1FN)

Esta primera forma normal trata de eliminar registros duplicados y que cada campo de la tabla contenga un único tipo de información Así cada campo de una tabla debe contener un valor único y atómico, es decir, que no se pueda descomponer en partes más pequeñas. Además, cada tabla debe tener una clave primaria que identifique de forma única a cada registro. 

En nuestro ejemplo no teníamos filas duplicadas, pero sí que debemos descomponer la dirección en varios campos atómicos y unificar el tipo de datos de la columna precio. Quedaría de la siguiente manera:

Normalización 1FN

Segunda forma normal (2FN)

Para poder considerar una tabla en 2FN tiene que cumplir con todos los requisitos de la 1FN y, además, que todos los campos que no formen parte de la clave primaria dependan completamente de la clave primaria. Esto significa que si la clave primaria está compuesta por más de un campo, cada campo no clave debe depender de todos los campos clave y no solo de algunos. Deberemos separar nuestra tabla en varias de manera que todos los campos cumplan con este requisito. ¿Os ha explotado la cabeza ahora mismo? No os preocupéis que con el ejemplo lo vamos a ver más claro.

Como hemos dicho el primer requisito es estar en 1FN así que vamos a empezar a trabajar sobre esa tabla ya en 1FN. Tendremos que saber cuál es su clave primaria, podría ser Num Factura + Cliente + Linea Factura. Sin embargo no es un buen candidato a clave primaria porque no con menos campos también logramos identificar inequívocamente todos los registros. La clave será Num Factura + Linea factura. Con esta nueva clave, tanto la fecha como los datos del cliente dependen del número de factura pero no de la línea de la factura así que vamos a hacer 2 tablas separadas.

Normalización 2FN

Tercera forma normal (3FN)

Para cumplir esta 3FN, además de tener que cumplir con la 2FN, cada campo de una tabla debe depender funcionalmente solo de la clave primaria sin que haya dependencias transitivas. Esto significa que si un campo no clave depende de otro campo no clave, debemos eliminar esa dependencia y crear una tabla separada.

Parecido a la 2FN pero un poco más restrictiva, en este caso tenemos que ver las dependencias de los campos con la clave y ver si puede crearse la relación con una clave intermedia. En nuestro caso separaremos los clientes de las facturas y los datos del artículo de las líneas de facturas.

Normalización 3FN

Otras Formas Normales, para un extra de normalización

Lo más normal es normalizar las bases de datos hasta la tercera forma normal, a partir de aquí, aunque sigue siendo recomendable, no siempre se cumple con todo y va a depender más de casos concretos. Vamos a conocerlo aunque ya sin nuestra tabla de ejemplo, pues lo que resta no aplica en nuestro caso.

Cuarta forma normal (4FN)

Esta 4FN dicta que las tablas no deben contener columnas multivalores, es decir, que no haya campos que contengan más de un valor para un mismo registro. Esto significa que si un campo puede tener varios valores posibles para un mismo registro, debemos crear una tabla aparte para almacenar esos valores y relacionarla con la tabla original mediante una clave foránea.

Por ejemplo, si tenemos una tabla de cursos con los campos código de curso, nombre y requisitos previos, debemos eliminar el campo requisitos previos, ya que puede contener más de un valor para un mismo curso. Este campo debe ir en una tabla aparte de requisitos previos y relacionarse con la tabla de cursos mediante una clave foránea.

Quinta forma normal (5FN)

Esta forma normal establece que cada tabla debe estar libre de anomalías de unión o inserción, es decir, que no haya redundancias o inconsistencias al combinar o insertar datos en varias tablas. Esto significa que si tenemos varias tablas relacionadas entre sí mediante claves foráneas compuestas, debemos asegurarnos de que esas relaciones sean necesarias y suficientes para representar los datos correctamente. 

Por ejemplo, si tenemos tres tablas: profesores, asignaturas y horarios, que se relacionan entre sí mediante las claves foráneas código de profesor, código de asignatura y día de la semana, debemos verificar que no haya combinaciones de valores que no tengan sentido o que falten datos. Si un profesor imparte una asignatura en varios días de la semana, debemos tener un registro por cada día en la tabla de horarios. Igualmente, si una asignatura se imparte por varios profesores en diferentes días, debemos tener un registro por cada profesor y día en la tabla de horarios. Si un profesor no imparte ninguna asignatura o una asignatura no se imparte por ningún profesor, debemos tener registros vacíos en la tabla de horarios.

Sexta forma normal (6FN)

Esta forma normal es la más nueva de todas y en algunos sitios no encontraréis referencias a ella justo por esto. Mientras que el resto de FN datan de los años 70, esta última no se dictó hasta los 90.

Establece que cada tabla debe contener sólo un hecho atómico, es decir, que no haya campos derivados o calculados a partir de otros campos. Esto significa que si tenemos una tabla que contiene información que se puede obtener mediante una operación matemática o lógica sobre otros campos, debemos eliminar esa información y crear una tabla aparte para almacenarla. 

Por ejemplo, si tenemos una tabla de facturas con los campos número de factura, fecha, código de cliente, subtotal, impuesto y total, debemos eliminar los campos impuesto y total, ya que se pueden calcular a partir del subtotal y del porcentaje de impuesto aplicable. Estos campos deben ir en una tabla aparte de impuestos y totales y relacionarse con la tabla de facturas mediante una clave foránea.

Conclusión

Enhorabuena si habéis llegado hasta aquí, os adelantaba que iba a ser un artículo denso de teoría pero a medida que lo escribía hasta a mi se me ha hecho cuesta arriba. Es lo que hay, en todos los campos hay que tratar estos artículos teóricos para tener una buena base. En este caso, la normalización es un proceso fundamental para diseñar bases de datos eficientes, consistentes y fáciles de manejar. Espero que este esfuerzo os haya servido para entender mejor la normalización de bases de datos. Practicad con vuestros propios ejemplos y, si os surgen dudas, podéis dejarlo en los comentarios, Twitter o mail y trataré de ayudaros lo mejor que sepa. 

Publicado por Roberto Carrancio en Otros, 4 comentarios