database design - non - Bases de datos relacionales vs. dimensionales, ¿cuál es la diferencia?
nosql databases (4)
En palabras simples, la base de datos normalizada OLTP está diseñada con el punto de vista "transaccional" más óptimo. Las bases de datos están normalizadas para funcionar de manera óptima en un sistema transaccional. Cuando digo optimización del sistema transaccional quiero decir ... obtener un estado de diseño de la estructura de la base de datos donde todas las operaciones transaccionales como eliminar, insertar, actualizar y seleccionar se equilibran para dar la misma o óptima importancia a todas ellas en cualquier momento. .al igual que en un sistema transaccional.
Y eso es lo que ofrece un sistema normalizado ... actualizaciones mínimas posibles para una actualización de datos, inserción mínima posible para nueva entrada, eliminación de un lugar para eliminación de categoría, etc. (por ejemplo, nueva categoría de producto) ... todo esto es posible una rama un crear maestro tablas ... pero esto tiene el costo de "seleccionar" la demora de operación ... pero como dije, su modelo (normalización) no es el más eficiente para todas las operaciones ... es "Óptimo" ... una vez dicho esto obtenemos otros métodos para mejorar la velocidad de obtención de datos ... como la indexación, etc.
Por otro lado, el modelo dimensional (principalmente utilizado para el diseño de data warehouses) ... destinado a dar importancia a un solo tipo de operaciones que es Selección de datos ... como en data warehouses ... la actualización / inserción de datos ocurre periódicamente. .y es un costo de una vez.
Entonces, si uno intenta modificar la estructura de datos normalizada de modo que solo la selección sea la operación más importante en cualquier punto del tiempo ... terminaremos obteniendo una estructura de estrella dimensional desnormalizada (diría parcialmente desnormalizada).
- todas las claves foráneas son de un solo hecho: ninguna dimensión para unir dimensión (es decir, maestro para unir mesa maestra) ... el copo de nieve representa la misma dimensión
- hechos idealmente diseñados solo portan números ..medidas o claves extranjeras
- dimensión se utilizan para llevar la descripción y la información no agregable
- la redundancia de datos se ignora ... pero en casos excepcionales, si las Dimensiones crecen demasiado, el diseño del copo de nieve se ve como una opción ... pero eso aún se puede evitar
Para más detalles, revise libros detallados sobre este tema.
Estoy tratando de aprender sobre OLAP y el almacenamiento de datos, y estoy confundido acerca de la diferencia entre el modelado relacional y dimensional. ¿El modelado dimensional es básicamente un modelado relacional, pero permite datos redundantes / no normalizados?
Por ejemplo, digamos que tengo datos históricos de ventas en (producto, ciudad, # ventas). Entiendo que lo siguiente sería un punto de vista relacional:
Product | City | # Sales Apples, San Francisco, 400 Apples, Boston, 700 Apples, Seattle, 600 Oranges, San Francisco, 550 Oranges, Boston, 500 Oranges, Seattle, 600
Si bien el siguiente es un punto de vista más dimensional:
Product | San Francisco | Boston | Seattle Apples, 400, 700, 600 Oranges, 550, 500, 600
Pero parece que ambos puntos de vista se implementarían en un esquema de estrella idéntico:
Fact table: Product ID, Region ID, # Sales Product dimension: Product ID, Product Name City dimension: City ID, City Name
Y no es hasta que comienza a agregar algunos detalles adicionales a cada dimensión que las diferencias comienzan a aparecer. Por ejemplo, si también desea rastrear regiones, una base de datos relacional tenderá a tener una tabla de regiones separada, a fin de mantener todo normalizado:
City dimension: City ID, City Name, Region ID Region dimension: Region ID, Region Name, Region Manager, # Regional Stores
Si bien una base de datos dimensional permitiría la desnormalización para mantener los datos de la región dentro de la dimensión de la ciudad, a fin de que sea más fácil cortar los datos:
City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores
¿Es esto correcto?
Encontré la descripción que encontré en http://www.orafaq.com/node/2286 ser muy útil cuando vengo a los esquemas de estrellas desde una perspectiva relacional.
Considere un modelo de datos completamente normalizado. Ahora piense exactamente en lo contrario, donde desnormaliza completamente su modelo de datos relacionales para que tenga solo un registro plano como una hoja de cálculo big''ol con una fila muy amplia. Ahora haga una copia de seguridad de esta grabación plana solo un poco para que tenga un modelo de datos que tenga solo dos niveles de profundidad; una gran mesa y varias mesas pequeñas a las que apunta la gran mesa. Este es un esquema STAR. Por lo tanto, un modelo de datos en estrella verdadero tiene dos atributos, siempre tiene dos niveles de profundidad, y un modelo de estrella verdadero siempre contiene solo una tabla grande que es el foco del modelo.
Recientemente, he leído sobre la diferencia entre el modelado de datos dimensional y relacional, ya que utilizamos principalmente modelos relacionales en mi negocio donde almacenamos un Enterprise Data Warehouse (EDW).
Según Steve Hoberman en su libro "Data Modelling Made Simple", la distinción entre los 2 tipos de modelos es la siguiente:
- Los modelos relacionales de datos capturan la solución de negocio de cómo funciona una parte del negocio, también conocido como proceso comercial
- Los modelos de datos dimensionales capturan los detalles que la empresa necesita para responder preguntas sobre lo bien que lo está haciendo
Se puede argumentar que un modelo relacional también se puede usar como una base sobre la cual responder preguntas comerciales, pero a nivel táctico. "¿Cuántas órdenes hay en un estado incumplido para el cliente x debido a retención de crédito?" Pero la distinción es aquella en que la pregunta de informe necesita el "grano nativo" de la tabla y cuando la pregunta de informe se puede responder con datos resumidos.
En los 2 ejemplos anteriores, en realidad ambos son ejemplos de modelado de datos dimensionales, ya que ninguna de las 2 tablas almacena la Orden de venta en su "grano original" y, por lo tanto, no captura el proceso comercial de crear un pedido de cliente. La única diferencia entre las 2 tablas es que en la 2da tabla la dimensión de la ciudad ha sido transpuesta a la tabla de hechos.
Un esquema en estrella realmente se encuentra en la intersección del modelo relacional de datos y el modelo dimensional de datos. Es realmente una forma de comenzar con un modelo dimensional y mapearlo en tablas SQL que se parecen un tanto a las tablas SQL que obtienes si comienzas desde un modelo relacional.
Digo algo parecido porque muchas metodologías de diseño relacional dan como resultado un diseño normalizado, o al menos un diseño casi normalizado. Un esquema en estrella tendrá desviaciones significativas de la normalización total.
Cada desviación de la normalización completa conlleva una anomalía de actualización de datos consecuente. (Estoy incluyendo anomlaies en operaciones de inserción, actualización y eliminación bajo un paraguas). Esas anomalías no tienen nada que ver con el modelo de datos con el que comenzó.
El comentario sobre OLTP versus OLAP es relevante aquí. Las anomalías de actualización tendrán diferentes impactos en el rendimiento y / o la dificultad de programación en esas dos situaciones.
Además de un esquema en estrella en una base de datos SQL, existen productos de bases de datos dimensionales que almacenan datos en una forma física que es única para ese producto. Con esos productos, no se ve un esquema en estrella tanto como se ve una implementación directa del modelo dimensional, y una interfaz que puede ser peculiar del producto. Algunas de esas interfaces permiten que las operaciones OLAP sean completamente apuntar y hacer clic.
Al igual que una digresión de su pregunta, una vez construí un esquema en estrella como un paso intermedio entre una base de datos OLTP que soportaba una aplicación basada en transacciones y un cubo de datos dentro de Cognos PowerPlay. Usando técnicas ETL estándar, la transferencia combinada de la base de datos OLTP al esquema en estrella y luego del esquema en estrella al cubo de datos en realidad superó la transferencia directa de la base de datos OLTP al cubo de datos. Este fue un resultado inesperado.
Espero que esto ayude.