Diseño de depósito de base de datos: tablas de hechos y tablas de dimensiones

Question

Estoy construyendo un depósito de datos de un hombre pobre utilizando un RDBMS. He identificado la tecla 'atributos' para ser registrado como:

• sexo (verdadero/falso)
• clasificación demográfica (A, B, C, etc.)
• lugar de nacimiento
• fecha de nacimiento
• peso (registrada al día): El hecho de que se está grabando

Mis requisitos son ser capaz de ejecutar consultas 'OLAP' que me permiten:

• 'picadillo'
• 'perforar arriba/abajo de los datos y
• general, poder visualizar los datos desde diferentes perspectivas

Después de leer en esta área temática , el consenso general parece ser que esto se implementa mejor utilizando tablas de dimensiones en lugar de tablas normalizadas.

Suponiendo que esta afirmación es verdadera (es decir, la mejor manera de implementar la solución es utilizando tablas de hechos y de dimensiones), me gustaría buscar ayuda en el diseño de estas tablas.

'natural' (o obvias) dimensiones son:

• Fecha dimensión
• ubicación geográfica

que tienen atributos jerárquicos. Sin embargo, estoy luchando con la forma de modelar los siguientes campos:

• sexo (verdadero/falso)
• clasificación demográfica (A, B, C, etc.)

La razón por la que estoy luchando con estos campos es que:

1. no tienen atributos evidentes jerárquicas que ayudarán a la agregación (AFAIA) - que sugieren que deberían estar en una tabla de hechos
2. Son en su mayoría estáticos o muy raramente cambian, lo que sugiere que deberían estar en una tabla de dimensiones.

¿Quizás la heurística que estoy usando anteriormente es demasiado cruda?

Daré algunos ejemplos sobre el tipo de análisis que me gustaría llevar a cabo en el almacén de datos, espero que aclare las cosas.

Me gustaría agregar y analizar los datos por sexo y clasificación demográfica - por ej.responder preguntas como:

• ¿Cómo se comparan los pesos de los hombres y las mujeres en las diferentes clasificaciones demográficas?
• Qué clasificación demográfica (masculina Y femenina) muestra el mayor aumento en el peso este trimestre.

etc.

¿Alguien puede aclarar si el sexo y la clasificación demográfica son parte de la tabla de hechos, o si son (como sospecho) tablas de dimensiones.?

Suponiendo también que son tablas de dimensiones, ¿podría alguien elaborar las estructuras de la tabla (es decir, los campos)?

El 'obvio' esquema:

CREATE TABLE sex_type (is_male int); 
CREATE TABLE demographic_category (id int, name varchar(4)); 

puede no ser la correcta.

Answer 1

No estoy seguro de por qué siente que el uso de RDBMS es una solución pobre, pero espero que esto pueda ayudar.

Tablas DimGeography y dimDemographic son los llamados mini-dimensiones; permiten cortar en función de la demografía y la geografía sin tener que unirse a dimUser, y también para capturar la demografía y la geografía actual del usuario en el momento de la medición.

Y, por cierto, cuando en DW mundo, verbosa - Gender = 'female', AgeGroup = '30-35', EducationLevel = 'university', etc.

Answer 2

Las búsquedas de esquema en estrella son el equivalente SQL de los puntos de intersección de Diagramas de Venn. Como las consultas de muestra muestran claramente, SEX_TYPE y DEMOGRAPHIC_CATEGORY son conjuntos por los que desea buscar y, por lo tanto, deben ser dimensiones.

En cuanto a las estructuras de la tabla, creo que su diseño para SEX_TYPE está equivocado. Para empezar, es más fácil, más intuitiva, para diseñar consultas sobre la base de

where sex_type.name = 'FEMALE' 

que

where sex_type.is_male = 1 

Además, en el mundo real el sexo no es un valor lógico. La mayoría de las aplicaciones también deberían reunir DESCONOCIDO y TRANSGÉNERO, y eso es cierto para aplicaciones de salud/médicas, que es lo que parece que está haciendo. Además, evitará algunos argumentos desagradables de la oficina si tiene compañeros de trabajo femeninos.

Editar

"Pienso en cómo hacer frente a casos de nuevas sex_types y demográficos categorías no está ya en la base de datos "

Hubo una moda de no tener claves foráneas en Data Warehouses. Pero proporcionan metadatos útiles que un optimizador de consultas puede usar para derivar la ruta de búsqueda más eficiente. Esto es particularmente importante cuando hay una gran cantidad de datos y consultas ad hoc para procesar. Tratar con valores de nueva dimensión siempre será difícil, a menos que los sistemas de origen le proporcionen una notificación. Esto realmente depende de tu configuración.

Answer 3

¿Qué herramienta OLAP/nivel de presentación pretenden utilizar? Estos suelen tener características propias para admitir la construcción de cubos, jerarquías, agregaciones, etc.

Normal La forma es generalmente la base más sólida para un Almacén de Datos flexible y eficiente, aunque los Mart a veces se desnormalizan para admitir un conjunto específico de los requisitos de información. A falta de otra información, sugiero que intente asegurarse de que su base de datos esté en al menos Boyce-Codd/5th Normal Form.

Answer 4

En general, todas las cantidades y medidas numéricas son las columnas de la tabla (s) de hecho. Entonces todo lo demás es un atributo dimensional. A qué dimensión pertenecen es bastante pragmática y depende de los datos.

Además de las sugerencias que ya ha recibido, no vi mencionar las dimensiones degeneradas. En estos casos, cosas como el número de factura o la marca de tiempo del número de secuencia, que es diferente para cada hecho, deben almacenarse en el hecho, de lo contrario, la tabla de dimensiones se convertirá en 1-1 con la tabla de hechos.

Una decisión clave de diseño en su caso es probablemente el análisis de los datos relacionados con la edad si el estudio está en curso. Debido a que las edades de las personas cambian con el tiempo, se moverán a otro grupo de edad en algún momento. Dependiendo de si los grupos están fijos al comienzo de un estudio o no, esto puede determinar cómo desea agregar. No necesariamente digo que debe tener una dimensión de grupo y envejecer a través de eso, pero es posible que deba determinar la edad/dimensión demográfica correcta durante el ETL. Pero esto depende del uso final (o de ambos) con dos roles de dimensión vinculados desde la tabla de hechos: datos demográficos iniciales, que nunca cambian, y datos demográficos actuales que cambiarán con el tiempo).

Algo similar podría aplicarse con la geografía. Aunque obviamente puede rastrear la geografía de una persona analizando los cambios actuales de geografía a lo largo del tiempo, el punto de una DW dimensional es tener todas las dimensiones relevantes ligadas al hecho (cosas que normalmente podría derivar en un modelo normalizado a través de la red Modelo de relación de entidad: estos se bloquean en el momento de ETL). Esta redundancia hace que el análisis sea más rápido en el modelo dimensional en los RDBMS tradicionales.

Tenga en cuenta que mucho de esto no se aplica en DW masivamente paralelo como Teradata, que no funcionan bien con los esquemas de estrella: les gustan todos los datos normalizados y vinculados al mismo índice primario porque son el índice principal de distribuir los datos sobre las unidades de procesamiento.