Bases de datos relacionales vs. dimensionales, ¿cuál es la diferencia?

Question

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). Yo entiendo que la siguiente sería una vista de punto de relacional:

 
Product | City | # Sales 
Apples, San Francisco, 400 
Apples, Boston, 700 
Apples, Seattle, 600 
Oranges, San Francisco, 550 
Oranges, Boston, 500 
Oranges, Seattle, 600 

Mientras que la siguiente es una vista de punto de más dimensiones:

 
Product | San Francisco | Boston | Seattle 
Apples, 400, 700, 600 
Oranges, 550, 500, 600 

pero parece que ambos puntos de vista no obstante, sería implementado en un esquema en estrella idéntica:

 
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 añadir algunos detalles adicionales para cada dimensión que las diferencias empiezan a aparecer. Por ejemplo, si desea realizar un seguimiento de las regiones, así, una base de datos relacional tendería a tener una tabla de regiones por separado, con el fin de mantener todo normalizado:

 
City dimension: City ID, City Name, Region ID 
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores 

Mientras que una base de datos tridimensional permitiría desnormalización a mantener la región datos dentro de la dimensión de la ciudad, con el fin de que sea más fácil para rebanar los datos:

 
City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores 

es esto correcto?

Answer 1

Un esquema de 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 en 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 de estrella en una base de datos SQL, existen productos de bases de datos dimensionales que almacenan datos en una forma física que es exclusiva de 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 admitía 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.

Answer 2

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 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 ramificar una crear tablas maestras ... pero esto tiene el costo de "seleccionar" la demora de operación ... pero como dije su (normalización) no es el modelo más eficiente para todas las operaciones ... su "Óptimo" ... habiendo dicho obtenemos otros métodos para mejorar la velocidad de obtención de datos ... como indexación, etc.

Por otro lado Modelo dimensional (principalmente utilizado para el diseño de la casa de datos) ... destinado a dar importancia a un solo tipo de operaciones. Selección de datos ... como en los almacenes de datos ... la actualización/inserción de datos ocurre periódicamente ... y es un costo único.

Así que si intentamos ajustar la estructura de datos normalizada de modo que la selección sea la operación más importante en cualquier momento ... terminaremos obteniendo una estructura de estrella dimensional desnormalizada (diría parcialmente desnormalizada).

• todas las claves externas de un solo lugar informativas dimensión -no se unen a la dimensión (es decir maestro para dominar unión de tablas) .. copo de representar misma dimensión
  • hechos idealmente diseñados llevan sólo números o ..measures Las claves externas
  • dimensión se utilizan para transportar 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 de copos de nieve se ve como opción ... pero eso aún se puede evitar

Para obtener más información, consulte los libros detallados sobre este tema.

Answer 3

Acabo de leer sobre la diferencia entre el modelado de datos dimensional y relacional ya que principalmente utilizamos modelos relacionales en mi negocio donde almacenamos un Enterprise Data Warehouse (EDW).

De acuerdo con Steve Hoberman en su libro "Modelado de datos Made Simple" la distinción entre los 2 tipos de modelos es la siguiente:

• modelos de datos relacionales capta la solución de negocio para saber cómo parte de las obras de negocio, también conocido como procesos de negocio
• modelos de datos dimensionales capturar los detalles de la empresa necesita para responder a preguntas acerca de lo bien que está haciendo

se puede argumentar que un modelo relacional también se puede utilizar como una base sobre la cual responde 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 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 dos ejemplos anteriores, en realidad son ejemplos de modelado de datos dimensionales ya que ninguna de las 2 tablas almacena la Orden de venta en su "grano nativo" y, por lo tanto, no captura el proceso comercial de crear una orden de venta. La única diferencia entre las 2 tablas es que en la segunda tabla se ha transposición a la tabla de hechos.

Answer 4

me encontré con la descripción que encontré en http://www.orafaq.com/node/2286 a ser muy útil cuando viene a la estrella del esquema 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.