Sesión 3 de DataWarehouse

DATAWAREHOUSE
Fases del Diseño

SESION 3
Contenido
• Identificar Medidas y Dimensiones en un Modelo
Dimensional.
• Generar jerarquías de análisis, jerarquías múltiples de tablas
dimensionales, llaves artificiales y granuralidad en el modelo
dimensional.
• Entender la importancia de las tablas sumarias y su
modelamiento.
• Diseño e implementación del esquema físico del DW en el
servidor, administración de la metadata.
• Métodos para analizar e identificar las Fuentes de Datos
requeridas
Metadatos
• Metadatos (Meta+datos) es un término que se
refiere a datos sobre los propios datos.
• Un ejemplo es una ficha que nos informa sobre el
lugar y el tipo de un libro. Nos está dando datos
sobre otros datos: el libro al que se refiere la ficha.
• El contenido combinado de los datos y metadatos
se conoce generalmente como paquete
contenedor.
• (SAP BusinessObjects Metadata Management)
Fase 1
• Realizar Análisis Estratégico
• Crear el modelo de negocio
• Documentar los metadatos
Identificar los requisitos del proceso de negocio
• En el modelado dimensional, la mejor unidad de análisis es el
proceso de negocio en el que la organización tiene el mayor
interés
• Cuando cree una lista de candidatos de procesos de negocio de
alto potencial, debe priorizar los requisitos
• Los procesos de negocio no siempre son departamentos de
negocio.
• Las consultas relacionadas a toma de decisiones son de
naturaleza más estratégica y plantean preguntas relacionadas
con un ámbito más amplio.
– Un ejemplo de consulta es "¿Qué productos se venden bien?" o
"¿Dónde están mis oficinas de ventas más débiles?".
Cuando seleccione un solo proceso de negocio (entre todos los procesos posibles que
existen en una empresa), debe priorizar los procesos de negocio según determinados
criterios. Los criterios pueden incluir:
– El significado del proceso de negocio,
– La calidad de los datos en los sistemas de origen y
– La viabilidad y complejidad de los procesos de negocio.
Cuando identifique los procesos de negocio de un modelo dimensional, reúna los siguientes
metadatos:
– Procesos de negocio
– Propietarios
– Sistemas de origen que se utilizarán
– Problemas de calidad de los datos
– Términos comunes utilizados en los procesos de negocio
– Otros metadatos relacionados con el negocio
Cree y estudie la lista de procesos de negocio de empresa

Cree una lista completa de procesos de negocio para toda la empresa.
Considere los siguientes factores de asesoramiento al crear la lista:
• Complejidad de los sistemas de origen de cada proceso de negocio
• Disponibilidad de datos de estos sistemas
• Calidad de datos de estos sistemas
• Significado de negocio estratégico de cada proceso de negocio
• Otros factores importantes para los procesos de negocio
Consejo: Puede ser útil asignar valores a cada factor de asesoramiento

y proceso de negocio. Cuando asigne valores, puede determinar la
prioridad de cada proceso de negocio.
Identificar los requisitos del proceso de
negocio
Identifique el proceso de negocio que desea
modelar
Priorice los procesos de negocio. Debe identificar
el mayor y el menor proceso de viabilidad al crear
un modelo dimensional.
Este paso resume los factores de asesoramiento
determinado anteriormente.
Los procesos más significativos para el negocio
deben modelarse primero.
Identifique las entidades y medidas de alto nivel que son comunes en

diversos procesos
Determine las entidades empresariales de alto nivel implicadas en cada
proceso.
Determine qué entidades son comunes en varios procesos de negocio.
Una vez identificadas las entidades comunes, puede unir los procesos
de negocio a través de estas dimensiones comunes (compartidas).
Para crear dimensiones compartidas que se puedan utilizar en toda la
empresa, debe asegurarse de que las distintas partes del negocio están
de acuerdo con las definiciones de estas entidades comunes.
.
Seleccione el método de recopilación de requisitos
Los requisitos suelen ser difíciles de definir.
Generalmente, sólo después de ver un resultado se
puede decidir que el resultado cumple (o no) un
requisito. Los requisitos de una organización también
cambian a lo largo del tiempo. Lo que es válido un día
puede no serlo al día siguiente. A pesar de ello, los
requisitos identificados en este punto se utilizan en el
ciclo de desarrollo para crear el modelo dimensional.
Preguntas
• Cómo puede crear algo que no se puede definir de forma
precisa?
• ¿Cómo sabe cuándo ha identificado correctamente los
requisitos?
• Aunque no hay ninguna prueba definitiva, generalmente
puede empezar el proceso de modelado si sus requisitos
incluyen las siguientes preguntas:
• Para reunir el conjunto completo de requisitos, debe
considerar las siguientes preguntas:¿Quiénes son las
personas, los grupos y las organizaciones de interés?
• ¿Qué funciones deben analizarse?
• ¿Por qué son necesarios los datos?
Preguntas
• ¿Cuándo deben registrarse los datos?
• ¿Dónde, a nivel geográfico y organizativo, se producen los
procesos relevantes?
• ¿Cómo se mide el rendimiento de las funciones?
• ¿Cómo se mide el rendimiento del proceso de negocio? ¿Qué
factores determinan el éxito o el fracaso?
• ¿Cuál es el método de distribución de la información? ¿Es un
informe de datos por escrito o por correo electrónico, o se
trata de otro método?
• ¿Qué tipos de información faltan para realizar el análisis y la
toma de decisiones?
• ¿Qué pasos se han llevado a cabo actualmente para satisfacer
la falta de información?
• ¿Qué nivel de detalle habilitaría el análisis de datos?
Modelo Dimensional
Esquemas de estrella
• Un esquema de estrella es un tipo de esquema de

base de datos relacional que consta de una sola tabla
de hechos central rodeada de tablas de dimensiones.
• En la siguiente figura se muestra un esquema de
estrella con una sola tabla de hechos y cuatro tablas
de dimensiones. Un esquema de estrella puede tener
cualquier número de tablas de dimensiones. Las
ramas situadas al final de los enlaces que conectan las
tablas indican una relación de muchos a uno entre la
tabla de hechos y cada tabla de dimensiones.
Esquemas de estrella
Esquemas de copo de nieve
• El esquema de copo de nieve consta de una tabla de hechos que
está conectada a muchas tablas de dimensiones, que pueden
estar conectadas a otras tablas de dimensiones a través de una
relación de muchos a uno.
• Las tablas de un esquema de copo de nieve generalmente se
normalizan en el tercer formulario de normalización. Cada tabla
de dimensiones representa exactamente un nivel en una
jerarquía.
• En la siguiente figura se muestra un esquema de copo de nieve
con dos dimensiones, cada una con tres niveles. Un esquema de
copo de nieve puede tener varias dimensiones y cada dimensión
puede tener varios niveles.
Esquemas de copo de nieve
Esquemas de constelación
• Un esquema de constelación es una combinación de un esquema
de estrella y un esquema de copo de nieve. Los esquemas de
constelación son esquemas de copo de nieve en los que sólo
algunas de las tablas de dimensiones se han desnormalizado.
• El objetivo de los esquemas de constelación es aprovechar las
ventajas de los esquemas de estrella y de copo de nieve. Las
jerarquías de los esquemas de estrella están desnormalizadas,
mientras que las jerarquías de los esquemas de copo de nieve
están normalizadas.
• Los esquemas de constelación están normalizados para eliminar
las redundancias de las dimensiones. Para normalizar el esquema,
las jerarquías dimensionales compartidas se colocan en outriggers.
Esquemas de constelación
• Outriggers
• Un outrigger es una entidad o una tabla de dimensiones unida a otras
tablas de dimensiones en un esquema de estrella. Los outriggers se
utilizan cuando una tabla de dimensiones tiene un esquema de copo
de nieve.
• Los outriggers son entidades o tablas compartidas por más de una
dimensión.
• Una entidad o tabla que esté incluida en una jerarquía pero no esté
relacionada directamente con la tabla de hechos se conoce como
outrigger. Los outriggers se utilizan con frecuencia cuando otra
dimensión hace referencia a una entidad o tabla de dimensiones. La
clave foránea de una entidad o tabla de dimensiones hace referencia a
la clave primaria de un outrigger.
Jerarquías
Existen dos maneras principales de modelizar las
jerarquías:
Modelo en estrella: Donde una única tabla contiene toda
la información de la jerarquía.
Modelo copo de nieve: Donde se crea una tabla para
cada nivel de la jerarquía
En la base de datos de presentación (también llamado
modelo dimensional) del DWH debe preferirse siempre el
modelo en estrella. Es decir, debe crearse una única tabla
para cada jerarquía. La misma tabla de PRODUCTOS debe
tener toda la información relativa a los productos
(presentación, producto, familia, marca).
Jerarquías
Las consultas generadas deben ser sencillas (con pocas
tablas y pocas relaciones). El modelo en estrella es
perfecto para conseguir este objetivo. Además,
desaparece el problema que generan las diferentes
jerarquías en que se pueden agrupar los productos
La herramienta de explotación puede requerir normalizar
parte de una jerarquía en una tabla independiente. Esta
limitación aparece cuando diferentes "hechos" están
definidos con diferente granularidad. Por ejemplo, las
ventas están a nivel de "producto", pero los objetivos de
venta se marcan a nivel de "familia". En este caso, muchas
herramientas BI exigirán la existencia de una tabla
de FAMILIAS.
Requerimiento de tecnología
• Hardware
• Software
• Otros Recursos
Jerarquías
Las dimensiones se agrupan en jerarquías mediante relaciones uno-
a-muchos.
• Una población agrupa a muchos clientes.
• Una provincia agrupa a muchas poblaciones.
• Una región está formada por varias provincias. Etcétera.
Las jerarquías típicas, que aparecen en cualquier sistema Business

Intelligence, son:
• Jerarquía geográfica o de clientes (país del cliente/ región/ ciudad/
cliente)
• Jerarquía de producto (marca/familia/producto/presentación)
• Jerarquía comercial (país/zona/punto de venta)
• Jerarquía temporal (año/trimestre/mes/día)
• Modelado Dimensional
• Ciclo De Vida De Modelado Dimensional
• Conceptos De Modelado Dimensional
• Diseño De Esquema Dimensional
• Esquemas Dimensionales
• Esquemas De Estrella
• Esquemas De Copo De Nieve
• Esquemas De Constelación
• Relaciones De Muchos A Uno
• Modelos De Datos Dimensionales Lógicos
• Modelos De Datos Dimensionales Físicos
• Modelos Dimensionales
• Tablas Y Entidades De Hechos
• Tablas Y Entidades De Dimensiones
• Jerarquías
• Outriggers
• Medidas
Modelado dimensional
• Los modelos dimensionales correlacionan los
aspectos de cada proceso de su negocio. Los
esquemas de bases de datos que se modelan
según los principios de modelado dimensional
funcionan bien con las aplicaciones que deben
leer grandes cantidades de datos rápidamente.
Este acceso rápido y fácil a los datos ayuda a
desarrollar aplicaciones y consultas que
permiten a la empresa analizar los datos.
• Ciclo de vida de modelado dimensional
El ciclo de vida de un modelo dimensional incluye las fases de diseño, prueba,
transformación y producción.
• Conceptos de modelado dimensional
Para trabajar con modelos dimensionales, debe comprender los conceptos del diseño
de esquema dimensional, términos como esquema de estrella y esquema de copo de
nieve, y la relación entre la estructura de base de datos y las jerarquías de modelado
dimensional.
• Creación de modelos dimensionales lógicos y físicos
Para crear un modelo dimensional en un proyecto, puede crear un nuevo modelo de
datos lógicos o físicos con notación dimensional o habilitar la notación dimensional en
un modelo de datos lógicos o físicos existente.
• Descubrimiento de los hechos y dimensiones de un modelo dimensional
Utilice el entorno de trabajo para descubrir los hechos y dimensiones de un modelo de
datos físico-dimensional o lógico-dimensional. También puede generar
automáticamente una jerarquía para cada dimensión descubierta.
Fase de diseño
• Durante la fase de diseño identificará los procesos de negocio que desea modelar,
después identificará el grano y las dimensiones y medidas del proceso de negocio.
• Paso 1: Identificar los requisitos del proceso de negocio
Seleccione el proceso de negocio para el que se asignará el modelo dimensional.
Según la selección, se reúnen los requisitos del proceso de negocio. Un proceso de
negocio requiere más de un modelo dimensional.
• Paso 2: Identificar el grano
Identifique la granularidad de cada tabla de hechos y proceso de negocio. Durante
este proceso deberá identificar los tipos de tablas de hechos y los candidatos
preliminares para las dimensiones y medidas.
• Paso 3: Identificar las dimensiones
Una vez que haya determinado el grano del modelo, identifique las dimensiones
verdaderas para ese grano. Debe crear columnas, jerarquías y casos para el
esquema de copo de nieve.
• Paso 4: Identificar las medidas
Durante este paso del ciclo de diseño de modelo dimensional, identificará las
medidas y el tipo de medidas incluidas en el modelo dimensional.
Paso 2: Identificar el grano
• Identifique la granularidad de cada tabla de hechos y proceso de negocio. Durante este proceso deberá identificar los
tipos de tablas de hechos y los candidatos preliminares para las dimensiones y medidas.
• La lista siguiente contiene varias características de identificación del grano:Especificar qué contienen los registrosAl
identificar el grano, se especifica exactamente qué contiene un registro de tabla de hechos. El grano muestra el nivel de
detalle asociado a las medidas de la tabla de hechos. Cuando identifique el grano, decida también el nivel de detalle que
desea que esté disponible en el modelo dimensional. Si se incluyen más detalles, el nivel de granularidad será más bajo. Si
se incluyen menos detalles, el nivel de granularidad será más alto.Identificar el nivel de detalleEl nivel de detalle
disponible en un esquema de estrella se conoce como grano. Cada tabla de hechos y dimensiones tiene su propio grano o
granularidad. Cada tabla (de hechos o dimensiones) contiene un nivel de detalle con el que se asocia. El grano del modelo
dimensional es el nivel de detalle más fino que está implícito al unir las tablas de hechos y dimensiones. Por ejemplo, la
granularidad de un modelo dimensional que consta de las dimensiones de fecha, almacén y producto es producto vendido
en el almacén por día.Identificar los datosCada fila contiene el mismo tipo de datos. Por ejemplo, cada fila puede contener
ventas diarias por almacén, por producto, o elementos de línea diarios por almacén.Por ejemplo, las definiciones de grano
pueden incluir los siguientes elementos:Un elemento de línea en un recibo de tienda de comestibles
• Una instantánea mensual de un extracto de cuenta bancaria
• Un solo billete de avión adquirido un día
• Las tablas de hechos y dimensiones tienen una granularidad asociada a ellas. El modelado dimensional,
la granularidad hace referencia al nivel de detalle almacenado en una tabla. Por ejemplo, una dimensión como la fecha
(con las jerarquías de año y trimestre) tiene granularidad en el nivel trimestral pero no tiene información para los días o
meses individuales. Alternativamente, una tabla de dimensiones de fecha (con las jerarquías de año, trimestre y mes)
tiene granularidad en el nivel mensual, pero no contiene información en el nivel diario.
• Puede gestionar distintas granularidades de datos utilizando varias tablas de hechos (tablas diarias, mensuales y anuales).
También puede utilizar una sola tabla con un distintivo de granularidad, o una columna que indique el grano de la tabla.
No obstante, no almacene datos con distintas granularidades en la misma tabla de hechos.
Paso 2: Identificar el grano
• Cuando identifique los granos de los objetos de datos,
realice los pasos siguientes:
• Determine la granularidad de la tabla de hechos.
• Determine cómo gestionar varios granos independientes.
• Determine el tipo de tabla de hechos que desea utilizar.
• Compruebe la atomicidad de los granos.
• Determine las dimensiones y medidas de alto nivel según
sus definiciones de grano
.
• Cree un informe de sus definiciones de grano.
Identificación de los metadatos del grano
Durante esta fase recopilará los siguientes metadatos:
• Una o más definiciones de grano para el proceso de negocio que va a modelar
• Tipo de tabla de hechos utilizada
• Dimensiones y medidas preliminares de alto nivel
Determinación de la granularidad de la tabla de hechos
• El detalle de grano se basa en las conclusiones de los requisitos analizados y
documentados en el
• Paso 1: Identificar los requisitos del proceso de negocio. Reúna documentos, como
facturas, recibos y memorándums de pedido. Estos documentos con frecuencia
incluyen información que se puede utilizar para definir el grano. Estos documentos
también tienen información que ayuda a identificar las dimensiones y medidas de
los modelos dimensionales.
• El grano que elija determinará el nivel de detalle de la información que puede
haber disponible en el modelo dimensional.
• La definición de grano es la base de cada modelo dimensional. La definición de
grano determina el nivel de información que hay disponible. Las directrices para
• Gestión de varios granos independientes
• Determine si hay varios granos asociados al proceso de negocio para el que va a diseñar el modelo dimensional. Puede haber más de una
definición de grano asociada a un solo proceso de negocio. En estos casos, diseñe tablas de hechos independiente con granos independientes. No
fuerce todas las medidas en una sola tabla de hechos.Se pueden gestionar distintas granularidades de datos utilizando varias tablas de hechos
(por ejemplo, tablas diarias, mensuales y anuales). Además, considere la cantidad de datos, espacio y requisitos de rendimiento cuando decida
cómo gestionar varias granularidades.
• Criterios para una o más tablas de hechosPara determinar si desea utilizar una o más tablas de hechos, considere los siguientes criterios:Considere
las medidas. Decida si desea agrupar las medidas en una tabla de hechos o en distintas tablas de hechos con granos diferentes.
• ¿Hay varios sistemas de origen OLTP implicados? Cada sistema de origen está diseñado con un objetivo específico. Si dos sistemas de origen no
cumplen objetivos diferentes, consolide los sistemas en un solo origen. Si desea mantener los sistemas separados, cada sistema de origen deberá
satisfacer un requisito concreto del negocio. Si los procesos de negocio incluyen la gestión de pedidos o el inventario de almacén, probablemente
serán necesarios sistemas de origen diferentes. En este caso, utilice distintas tablas de hechos.
• Determine si hay implicados varios procesos de negocio no relacionados. Cree tablas de hechos independientes para los procesos de negocio no
relacionados. Si un solo proceso de negocio requiere distintos niveles de granularidad, cree distintas tablas de hechos para gestionar esos niveles.
• Si una dimensión no es verdadera en la definición de grano, diseñe una nueva tabla de hechos con su propia definición de grano.
• Considere la temporización y la secuencia de los sucesos. Quizá necesite procesos diferentes para gestionar un solo suceso. Por ejemplo, una
empresa comercializa su producto. Los clientes solicitan los productos. El departamento encargado de las cuentas genera una factura. El cliente
paga la factura. Después de la compra, el cliente puede devolver algunos de los productos o enviarlos a reparar. Si alguno de los productos está
fuera de garantía, este proceso requiere nuevos cargos. Varios procesos forman parte de la secuencia de una sola compra. Cada uno de estos
procesos se realiza en momentos temporales diferentes. Cada uno de estos procesos se gestiona utilizando tablas de hechos diferentes.
• Varias granularidades en una sola tabla de hechosSi utiliza varios granos en una tabla de hechos, añada una columna llamada distintivo de
granularidad. Esta columna indica el grano de la tabla. La columna define si la información se almacena a nivel diario, semanal, mensual o
anual.Nota: Puede almacenar varios granos en una sola tabla de hechos, pero este método no se recomienda. Diseñe distintas tablas de hechos y
esquemas de estrella para cada definición de grano.
• Identificación de los tipos de tablas de hechos que se pueden utilizar
• Identifique el tipo de tabla de hechos implicada en el diseño del modelo dimensional. Para obtener más información sobre los
tipos de tablas de hechos, consulte Tablas y entidades de hechos.
• Comprobación de la atomicidad del grano
• Revise la atomicidad (nivel de detalle) del grano para asegurarse de que está en el nivel de mayor detalle. Esta decisión incluye
la consideración por anticipado de las necesidades futuras con el fin de minimizar la necesidad de crear un nuevo diseño
cuando cambien los requisitos empresariales.
• El grano del modelo dimensional es importante al diseñar el modelo dimensional. Aunque los requisitos empresariales
necesiten información a nivel mensual o trimestral, haga disponible esta información a nivel diario. Si las dimensiones son más
detalladas (atómicas), el negocio puede recupera información más detallada.
• Por ejemplo, considere una dimensión de fecha que sólo tenga un atributo Year. Como sólo hay un atributo, no puede
consultar la información a nivel trimestral, mensual o diario. Para maximizar la información disponible, elija un grano atómico
detallado. En este ejemplo, puede definir el grano a nivel diario.
• Por ejemplo, pongamos por caso un grano de un producto vendido en un almacén. No podrá asociar un cliente con un
producto determinado que se haya adquirido porque sólo hay una fila para un producto. Si mil clientes diferentes compran el
producto, no podrá descubrir esa información.
• Siempre puede declarar granos de mayor nivel para un proceso de negocio utilizando agregaciones de los datos más atómicos
y detallados. Sin embargo, cuando se selecciona un grano de mayor nivel, el número de dimensiones se limita y puede ser
menos granular. No puede detallar más estas dimensiones menos granulares para obtener un nivel menor de detalle.
• La granularidad proporciona la oportunidad de alcanzar el equilibrio entre las cuestiones importantes relacionadas con un
depósito de datos:El rendimiento frente al volumen de los datos (y el coste derivado de almacenar esos datos)
• La capacidad de acceder a los datos a un nivel detallado frente al rendimiento (y el coste de almacenar y acceder a grandes volúmenes de datos)
• Seleccionar el nivel apropiado de granularidad afecta considerablemente el volumen de datos del depósito de datos. Seleccionar el nivel apropiado de
granularidad también puede determinar la capacidad del depósito de datos para satisfacer los requisitos de consulta.
• Si consideramos el espacio de disco y el volumen de datos, una mayor granularidad proporciona una forma más eficaz de almacenar datos que una baja
granularidad. También debe considerar el espacio de disco para el índice de los datos. Mediante el uso del índice, ahorrará espacio de disco. Tenga también en
cuenta la manipulación de grandes volúmenes de datos. La manipulación de datos puede afectar al rendimiento a costa de más potencia de proceso.
• Siempre existen ventajas y desventajas al procesar los datos. Por ejemplo, al aumentar la granularidad, disminuye la capacidad para responder a distintos tipos
de consultas (que requieren datos a nivel más detallado). Si la tabla utiliza un nivel bajo de granularidad, puede soportar las consultas que utilizan esos datos a
costa del aumento del espacio de almacenamiento y la disminución del rendimiento.
• Aunque la granularidad no afecta a la capacidad de responder a una consulta, el sistema puede necesitar más recursos para ejecutar la misma consulta.
Supongamos que tiene dos tablas con distintos niveles de granularidad: una tabla con detalles de transacción y una tabla que resume las cuentas mensualmente.
Para crear un informe de cuentas mensual, puede utilizar cualquiera de las tablas sin ninguna dependencia de la granularidad. Sin embargo, la consulta de la
tabla de transacciones detalladas es una búsqueda que abarca más datos, lo que requiere un proceso para calcular los resultados. La tabla de resumen de
cuentas mensual requiere menos recursos.
• Cuando decida el nivel de granularidad, determine si el coste del volumen de datos compensa la capacidad de responder a las consultas.
• Identificación de dimensiones y medidas de alto nivel
• Identifique las dimensiones y medidas preliminares de alto nivel a partir de las cuales comprenderá la definición de grano. Para identificar estas dimensiones y
medidas preliminares, no se lleva a cabo ningún análisis detallado. Cuando defina el grano correctamente, podrá encontrar fácilmente las dimensiones y medidas
preliminares.
• Las medidas preliminares son aquellas que se pueden identificar fácilmente consultando la definición de grano. Por ejemplo, las medidas como el precio unitario,
la cantidad y el descuento se identifican fácilmente viendo el grano. Sin embargo, las medidas detalladas como el coste, el precio de fabricación y el coste de
transporte no son medidas preliminares identificadas por el grano. Estos tipos de medidas están ocultas y generalmente no son visibles en un informe. Las
medidas preliminares no son el conjunto final de medidas. La identificación formal de medidas detalladas se produce alidentificar las medidas.
• Estas dimensiones y medidas preliminares de alto nivel son útiles al identificar formalmente las dimensiones.
• Creación de un informe de la fase de identificación del grano
• El informe de definición del grano se crea para esta fase. El informe contiene una o más definiciones para el grano del proceso de negocio y define el tipo de
tabla de hechos. El informe también incluye las dimensiones y medidas preliminares de alto nivel.
Paso 3: Identificar las dimensiones
Una vez que haya determinado el grano del modelo, identifique las dimensiones verdaderas
para ese grano. Debe crear columnas, jerarquías y casos para el esquema de copo de nieve.
Al identificar tablas de dimensiones, se recopilan los siguientes metadatos:
• Nombres de dimensión
• Definiciones de negocio
• Jerarquías
• Gestión de cambios de dimensión
• Frecuencia y estadísticas de carga
• Estadísticas de uso
• Reglas y estadísticas de archivado
• Reglas y estadísticas de depuración
• Calidad y precisión de los datos
• Claves primarias y foráneas y manera de generar las claves
• Información de origen de datos
• Hechos
Identificar las dimensiones
Para definir totalmente las dimensiones del modelo
dimensional, realice los pasos siguientes:
• Identifique las dimensiones verdaderas para el grano del modelo.
• Identifique las columnas y jerarquías dimensionales de las
dimensiones.
• Si crea dimensiones de tiempo y fecha, defina la granularidad de
esas dimensiones.
• Determine qué dimensiones cambian lentamente a lo largo del
tiempo y cómo abordar esos cambios.
• Determine qué dimensiones (si hay alguna) deben tener
estructura de copo de nieve.
Identificar las medidas
Durante este paso del ciclo de diseño de modelo dimensional, identificará las medidas y el tipo de medidas
incluidas en el modelo dimensional.
Al definir las medidas, se recopilan los siguientes metadatos:
• Nombre de tabla de hechos
• Alias
• Grano
• Definición de negocio
• Frecuencia y estadísticas de carga
• Estadísticas de uso
• Cómo gestionar los datos archivados
• Cómo y cuándo depurar los datos
• Calidad y precisión de los datos
• Grano de dimensiones de fecha y hora
• Claves y cómo se generan las claves
• Información de origen de datos
• Medidas
• Dimensiones
• Información de contacto del propietario de la tabla
Identificar las medidas
Cuando identifique las medidas del modelo dimensional, realice
los pasos siguientes:
• Identifique las medidas verdaderas para el grano de la tabla.

• Identifique los tipos de medidas del modelo.
• Si no es una tabla de hechos que agregue totales anuales,
asegúrese de que no se incluyan medidas de año a fecha en la
tabla.
• Si es una tabla de hechos basada en sucesos, determine cómo
gestionar los sucesos.
• Pronostique el crecimiento de la tabla de hechos.
Verificación del modelo
• Durante esta fase se prueba el modelo dimensional para ver si cumple los requisitos
empresariales.
• Durante esta fase el modelo dimensional no contiene datos. Debe comprobar si el
modelo dimensional responde a todas las preguntas planteadas durante la fase de
recopilación de requisitos.
• Para verificar el modelo, debe trabajar con los analistas de negocio que escriben los
informes. Si los analistas pueden crear informes a partir del modelo dimensional, el
modelo será válido. Si faltan atributos, añádalos al modelo y vuelva a revalidar el
modelo.
• Confirme los requisitos de la gestión de cambios de datos históricos. Si necesita
conservar datos históricos, verifique que los datos se conserven de la forma requerida
por el proceso de negocio.
• Utilice el entorno de trabajo para verificar el modelo de datos. Ejecute el
asistente Analizar modelo para verificar el modelo dimensional. El entorno de trabajo
verifica la aplicación de las reglas de modelado dimensional estándar para que el
modelo de datos sea válido y funcione bien.
Consideraciones físicas de diseño
• Una vez que haya verificado el modelo dimensional, diseñe la base de datos física.
Desarrolle estrategias para gestionar la agregación, agregue la navegación, el indexado y
el particionamiento de los datos al modelo dimensional.
• Cuando diseñe la base de datos física, recopile los siguientes metadatos: Información de
agregación, incluida la siguiente información:
– Número de tablas de agregación
– Frecuencia y estadísticas de carga
– Estadísticas de uso
– Reglas y estadísticas de archivado
– Reglas y estadísticas de depuración
– Calidad y precisión de los datos
• Estrategias de indexado para tablas de dimensiones y hechos
• Cuando cree el diseño físico de un modelo dimensional, realice los pasos siguientes:
– Diseñe las agregaciones de cada una de las tablas de hechos.
– Cree índices para mejorar el rendimiento.
– Particione las tablas en el modelo.
Conceptos de modelado dimensional
• Para trabajar con modelos dimensionales, debe comprender los conceptos del
diseño de esquema dimensional, términos como esquema de estrella y esquema
de copo de nieve, y la relación entre la estructura de base de datos y las
jerarquías de modelado dimensional.
• Diseño de esquema dimensional
Comprenda los conceptos en que se basa el diseño de esquema dimensional,
como los esquemas de estrella, de copo de nieve y de constelación. Obtenga más
información sobre la relación entre la estructura de base de datos y las jerarquías
del modelo dimensional.
• Modelos dimensionales
Antes de crear un modelo dimensional, debe comprender los objetos básicos que
se utilizan para crear modelos dimensionales: tablas y entidades de hechos,
tablas y entidades de dimensiones, jerarquías, outriggers y medidas.
Diseño de esquema dimensional
• Comprenda los conceptos en que se basa el diseño de esquema dimensional, como los
esquemas de estrella, de copo de nieve y de constelación. Obtenga más información sobre la
relación entre la estructura de base de datos y las jerarquías del modelo dimensional.
• Esquemas dimensionales
Una base de datos consta de una o más tablas, y las relaciones entre todas las tablas de la base
de datos se denomina colectivamente elesquema de base de datos. Aunque hay muchos
diseños de esquema diferentes, las bases de datos en las que se realizan consultas de datos
históricos generalmente utilizan un diseño de esquema dimensional.
• Modelos de datos dimensionales lógicos
Un modelo lógico de datos es un modelo que no es específico de una base de datos que
describe aspectos relacionados con las necesidades de una organización para recopilar datos y
las relaciones entre estos aspectos.
• Modelos de datos dimensionales físicos
Al crear un modelo de datos físicos, se debe correlacionar el modelo de datos lógicos con las
estructuras físicas de una base de datos que aloja el depósito de datos.
• Esquemas dimensionales
• Una base de datos consta de una o más tablas, y las relaciones entre todas las tablas de la base de datos se
denomina colectivamente el esquema de base de datos. Aunque hay muchos diseños de esquema diferentes, las
bases de datos en las que se realizan consultas de datos históricos generalmente utilizan un diseño de esquema
dimensional.
• El modelado dimensional en el entorno de trabajo se realiza a nivel lógico y físico. Los conceptos del modelado
dimensional se aplican a los modelos de datos lógicos y físicos. El modelado dimensional añade otra capa a los
modelos de datos, que funcionan con muchos proveedores de gestión de base de datos.
• Utilice el modelado dimensional para conseguir los siguientes beneficios:Puede crear consultas que respondan a
cuestiones de negocio. Generalmente, una consulta calcula alguna medida de rendimiento entre varias
dimensiones de negocio.
• Puede crear consultas SQL. La mayoría de proveedores RDBMS utilizan el lenguaje SQL.
• Un esquema dimensional separa físicamente las medidas que cuantifican el negocio de los elementos descriptivos
(también llamados dimensiones) que describen y categorizan el negocio. El esquema dimensional puede ser físico
o lógico. Un esquema dimensional físico generalmente se representa en forma de esquema de estrella o de copo
de nieve, en el que los objetos que contiene son en realidad tablas de base de datos. El esquema dimensional
puede incluso adoptar la forma de una sola tabla o vista, en la que todos los hechos y dimensiones están en
columnas distintas de dicha tabla o vista. En un esquema dimensional lógico, los hechos, las medidas y las
dimensiones se representan como entidades y atributos independientes a un proveedor de base de datos y, por lo
tanto, se pueden transformar en un esquema dimensional físico para cualquier proveedor de base de datos.
• Esquemas de estrella
Un esquema de estrella es un tipo de esquema de base de datos relacional que consta de una sola tabla
de hechos central rodeada de tablas de dimensiones.
• Esquemas de copo de nieve
El esquema de copo de nieve consta de una tabla de hechos que está conectada a muchas tablas de
dimensiones, que pueden estar conectadas a otras tablas de dimensiones a través de una relación de
muchos a uno.
• Esquemas de constelación
Un esquema de constelación es una combinación de un esquema de estrella y un esquema de copo de
nieve. Los esquemas de constelación son esquemas de copo de nieve en los que sólo algunas de las
tablas de dimensiones se han desnormalizado.
• Relaciones de muchos a uno
Una relación de muchos a uno hace referencia a una tabla o entidad que contiene valores y hace
referencia a otra tabla o entidad que tiene valores exclusivos. Las relaciones de muchos a uno con
frecuencia son impuestas por las relaciones de clave foránea y clave primaria, y generalmente las
relaciones se establecen entre las tablas de hechos y las entidades o tablas de dimensiones y entre los
niveles de una jerarquía.
Relaciones de muchos a uno
• Una relación de muchos a uno hace referencia a una tabla o entidad que contiene valores y hace referencia
a otra tabla o entidad que tiene valores exclusivos. Las relaciones de muchos a uno con frecuencia son
impuestas por las relaciones de clave foránea y clave primaria, y generalmente las relaciones se establecen
entre las tablas de hechos y las entidades o tablas de dimensiones y entre los niveles de una jerarquía.
• La relación se utiliza con frecuencia para describir clasificaciones o agrupaciones. Por ejemplo, en un
esquema geográfico que tenga las tablas Región, Estado y Ciudad muchos estados pertenecen a una región
determinada, pero los mismos estados no pueden pertenecer a dos regiones diferentes. Lo mismo ocurre
con las ciudades, una ciudad sólo está en un estado (las ciudades que tienen el mismo nombre pero están
en más de un estado se deben tratar de forma algo distinta). Cada ciudad existe en un solo estado, pero un
estado puede tener muchas ciudades, de ahí el término muchos a uno.
Relaciones de muchos a uno
• Los distintos elementos, o niveles, de una jerarquía deben tener
relaciones de muchos a uno entre los niveles hijo y padre,
independientemente de si la jerarquía se representa físicamente en
un esquema de estrella, de copo de nieve o de constelación. Los
datos deben cumplir con estas relaciones. Los datos limpios que son
necesarios para aplicar las relaciones de muchos a uno son una
característica importante de un esquema dimensional. Además, estas
relaciones posibilitan la creación de cubos a partir de los datos
relacionales.
• Al definir un modelo dimensional, las relaciones de muchos a uno
que definen la jerarquía se convierten en niveles de una dimensión.
Modelos de datos dimensionales lógicos
• Un modelo lógico de datos es un modelo que no es específico de una base de datos que describe aspectos
relacionados con las necesidades de una organización para recopilar datos y las relaciones entre estos
aspectos.
• Un modelo lógico contiene representaciones de entidades y atributos, relaciones, identificadores
exclusivos, subtipos y supertipos y restricciones entre relaciones. Un modelo lógico también puede
contener objetos de modelo o hacer referencia a uno o más modelos. Una vez definidas las relaciones y
los objetos lógicos en un modelo de datos lógicos, puede utilizar el entorno de trabajo para transformar el
modelo lógico en una representación física específica de base de datos en forma de modelo de datos
físicos.
• Los objetos del modelo lógico siempre están contenidos en un objeto de paquete raíz. Siempre hay un
paquete raíz, pero puede añadir paquetes adicionales bajo el paquete raíz para agrupar objetos similares.
• Los modelos de datos lógicos abordan las siguientes áreas de interés:Validación de modelos de aplicación
con requisitos empresariales
• Creación de requisitos para modelos de datos físicos y diseño de base de datos
• Identificación de entidades empresariales y las relaciones entre las entidades
• Los modelos de datos lógicos crean una sola vista de todos los datos. Puede crear un modelo de datos
lógicos para abordar el rendimiento, la coherencia y las redundancias de los datos. El modelo de datos
lógicos se utiliza para crear un modelo de datos físicos que permita acceder a los datos.
• Al crear un modelo de datos lógicos, utilice los pasos siguientes:Identifique entidades, atributos y relaciones:
– Revise la documentación del proyecto. Debe definir el ámbito del proyecto y la información sobre el sistema de origen del
que va a obtener los datos. Defina requisitos empresariales, modelos de procesos, perfiles, diseños arquitectónicos y
modelos de datos.
– Cree categorías generales que representen la información que almacenará en el depósito de datos. Asegúrese de que se
impliquen los analistas de negocio y los expertos en la materia interesados. Estas categorías deben representar conceptos
de empresa, no sólo atributos o subconjuntos de datos.
– Identifique las entidades. Las entidades generalizan los conceptos, las partes implicadas, los productos, los planes, las
ubicaciones o los sucesos que se almacenarán en la base de datos. Las entidades pueden ser objetos de la base de datos o
categorías que haya creado más arriba.
– Determine las relaciones entre las entidades. Una entidad pueden tener relaciones con otras entidades, pero entre dos
entidades sólo puede haber una relación. Cuando cree relaciones, hágalo desde el punto de vista del negocio. Cree
nombres para cada parte de la relación.
– Identifique la cardinalidad de cada relación.
– Identifique los atributos y las características de cada entidad. Durante este paso, debe definir claves primarias. Una clave
primaria es un subconjunto de atributos que identifican de forma exclusiva una entidad.
– Cree descripciones de texto para entidades y atributos. La descripción debe representar los objetos desde el punto de
vista del negocio.
• Fusione el modelo funcional con el modelo de datos lógicos.
– Cree, lea, actualice y suprima atributos de las entidades.
– Mantenga las relaciones y cardinalidades del modelo datos lógicos y los valores de los atributos.
• Valide el modelo de datos lógicos con los requisitos del negocio. Asegúrese
de que la siguiente información se encuentre en el modelo de datos lógicos:
– Todos los procesos de negocio necesarios se documentan a través de entidades
– Todos los datos necesarios se incluyen en el modelo de datos lógicos
– Todas las entidades tienen nombre, así como claves primarias, atributos y relaciones
con otras entidades del modelo de datos lógicos
– Las cardinalidades entre objetos reflejan sus relaciones apropiadas
– Las entidades y atributos se encuentran en el depósito de datos, y están
relacionados con funciones o procesos que tienen lugar en el depósito de datos
• Revise el modelo de datos a lo largo del proceso. Tenga en cuenta que debe
mantenerse en el ámbito de las necesidades del negocio, y debe modificar el
modelo cuando conozca mejor dichas necesidades. Una vez completado el
modelo de datos, siga revisando y mejorando el modelo para sacar el
máximo partido de los datos disponibles para el negocio.
Modelos de datos dimensionales físicos
• Al crear un modelo de datos físicos, se debe correlacionar el modelo de datos lógicos con las estructuras
físicas de una base de datos que aloja el depósito de datos.
• Al crear un modelo de datos físicos, debe definir estructuras físicas, como las tablas y tipos de datos que
utilizará cuando se almacenen los datos. También debe definir nuevas estructuras de datos que pueden
mejorar el rendimiento de las consultas. Sin embargo, debe definir nuevas estructuras sin cambiar el
significado del esquema del modelo de datos lógicos.
• Tenga en cuenta las siguientes consideraciones cuando cree un modelo de datos físicos:¿Qué nivel de
escalabilidad tiene el diseño? ¿Qué nivel de escalabilidad tiene el sistema de gestión de bases de datos
físicos (DBMS)?
• ¿Qué consultas, procesos ETL y otras aplicaciones requiere el depósito de datos?
• ¿Hay algún modelo de datos abstracto que pueda utilizar para mejorar el rendimiento?
• ¿Cómo utilizará o realizará el mantenimiento del depósito de datos?
• Nota: El modelado de datos físicos en el proceso de transacción en línea (OLTP) no difiere mucho del
modelado físico del depósito de datos. En el nivel de modelo conceptual, el modelado de datos físicos de
OLTP difiere principalmente en el diseño de rendimiento. En OLTP, el diseño se centra en los volúmenes de
datos y de transacciones, mientras que en el modelo de datos físicos de depósito de datos se centra en el
rendimiento de la carga, el rellenado de las áreas de análisis y las tablas de resumen por parte de
aplicaciones por lotes o en tiempo real, y en el rendimiento de las consultas analíticas.
• Para crear un modelo de datos dimensionales físicos, realice los
pasos siguientes:Modele las entidades y los atributos del modelo de
datos físicos:
– Defina una tabla para cada entidad del modelo de datos lógicos. Asigne un
nombre a cada tabla.
– Cree columnas para cada uno de los atributos de las entidades del modelo
de datos lógicos. Asigne un nombre y un tipo de datos a cada columna.
– Defina las claves primarias y foráneas de cada tabla.
• Cree el DDL del modelo de datos físicos:
– Cree la base de datos de destino.
– Conecte con la base de datos de destino.
– Genere el DDL.
– Implemente el DDL.
• Diseñe y ajuste el rendimiento del modelo de datos físicos. Ajuste las entidades y relaciones que se obtienen
del modelo de datos lógicos y céntrese en cómo se rellenan esos objetos. El rendimiento del rellenado se
ajusta utilizando uno de estos dos métodos:Rellenado por lotesUtilice las aplicaciones personalizadas, las
herramientas ETL o los programas de utilidad de base de datos que proporcionen un buen
rendimiento.Rellenado en tiempo realUtilice procesos y técnicas que permitan que los datos estén disponibles
más rápidamente. Por ejemplo, en vez de utilizar el proceso ETL típico, utilice un proceso ELT (extraer,
transformar y cargar). En el proceso ELT, los datos se extraen y cargan antes de que se realice la transformación,
lo que puede mejorar el rendimiento.Nota: El rendimiento depende de las estructuras de datos físicos. La
modificación o adición de estructuras físicas más apropiadas puede mejorar el rendimiento de las consultas, de
las extracciones de datos o de las réplicas. Sin embargo, la adición de más estructuras físicas también puede
aumentar el tiempo de carga del depósito de datos. El ajuste de rendimiento permite minimizar los costes. Por
ejemplo, el rendimiento siempre se puede mejorar añadiendo más CPU y recursos de E/S, pero debe buscar un
compromiso entre un rendimiento aceptable y el coste total del sistema.
• Verifique el diseño físico asegurándose de haber abordado las áreas siguientes:
– El script DLL del modelo físico debe definir correctamente las estructuras físicas, incluidas las mejoras del rendimiento.
– El diseño físico debe estar totalmente documentado.
– Cada entidad del modelo de datos lógicos debe representar una tabla física, incluidos los atributos y relaciones adecuados.
– Cada relación debe describir cardinalidades correctas (uno a uno, uno a muchos, muchos a muchos).
– Describa correctamente cada entidad y atributo en el diccionario de datos.
– Valide todas las estimaciones de capacidad.
Modelos dimensionales
Antes de crear un modelo dimensional, debe comprender los objetos básicos que se
utilizan para crear modelos dimensionales: tablas y entidades de hechos, tablas y
entidades de dimensiones, jerarquías, outriggers y medidas.
Tablas y entidades de hechos
Una tabla de hechos o una entidad de hecho es una tabla o entidad de un esquema
de estrella o copo de nieve que almacena medidas para medir el negocio, como las
ventas, el coste de las mercancías o las ganancias.
Tablas y entidades de dimensiones
Una tabla de dimensiones o entidad de dimensiones es una tabla o entidad de un
esquema de estrella, copo de nieve o constelación que almacena detalles acerca de
hechos. Por ejemplo, una tabla de dimensión de hora almacena los distintos
aspectos del tiempo, como el año, trimestre, mes y día.
Jerarquías
Una jerarquía es una relación de muchos a uno entre los miembros de una tabla o
entre tablas. Una jerarquía consta básicamente de distintos niveles, y cada uno
corresponde a un atributo de dimensión.
Outriggers
Un outrigger es una entidad o una tabla de dimensiones unida a otras tablas de
Tablas y entidades de hechos
• Una tabla de hechos o una entidad de hecho es una tabla o entidad de un esquema de estrella o copo de nieve que
almacena medidas para medir el negocio, como las ventas, el coste de las mercancías o las ganancias.
• Las tablas y entidades de hechos agregan medidas o los datos numéricos de un negocio. Para medir los datos de una tabla o
entidad de hechos, todas lasmedidas de una tabla o entidad de hechos debe corresponder al mismo grano.
• Para obtener los datos más útiles de una tabla o entidad de hechos, debe utilizar medidas que sean numéricas y aditivas. La
utilización de estas medidas garantiza que los datos se puedan recuperar y agregar de manera que el negocio pueda hacer
uso de la riqueza de datos de negocio de la base de datos.
• Las tablas y entidades de hechos también contienen claves foráneas a las tablas de dimensiones. Estas claves foráneas
relacionan cada fila de datos de la tabla de hechos con sus correspondientes dimensiones y niveles.
• Las tablas y entidades de hechos utilizan claves primarias que son claves compuestas. Una clave compuesta consta de un
subconjunto de otras claves. Si una tabla o entidad de un modelo dimensional utiliza una clave compuesta, esa tabla será
una tabla o entidad de hechos. El uso de claves compuestas hace que la tabla o entidad tenga una relación de muchos a uno
con otras tablas y entidades del modelo dimensional.
• Tipos de tablas y entidades de hechos
• Hay tres tipos de tablas y entidades de hechos:TransacciónUna tabla de hechos de transacciones o entidad de hechos de
transacciones registra una fila por transacción.PeriódicoUna tabla de hechos periódicos o entidad de hechos
periódicos almacena una fila para un grupo de transacciones que se realizan a lo largo de un período de
tiempo.AcumulativoUna tabla de hechos acumulativos o entidad de hechos acumulativos almacena una fila para el tiempo
de vida total de un suceso. Un ejemplo de una tabla o entidad de hechos acumulativos registra el tiempo de vida de una
aplicación de tarjetas de crédito desde el momento en que se envía al momento en que se acepta.Nota: No puede
especificar explícitamente el tipo de tabla o entidad de hechos utilizando el entorno de trabajo. Para documentar los tipos
de tablas de hechos que está utilizando, puede añadir la información a la documentación.
• En la tabla siguiente se comparan los distintos tipos de tablas y entidades de hechos. En la tabla se enfatiza que cada una
tiene un tipo distinto de grano y que hay diferencias en cómo se realizan en cada una las operaciones de inserción y
actualización. Por ejemplo, en las tablas y entidades de hechos periódicos, sólo se realizan operaciones de inserción. Sin
embargo, en una tabla o entidad de hechos acumulativos, la fila se inserta primero, y cuando se consigue un objetivo y se
hacen disponibles medidas adicionales, se actualiza posteriormente la tabla o entidad.
Tablas y entidades de dimensiones
• Una tabla de dimensiones o entidad de dimensiones es una tabla o entidad de un esquema de estrella, copo de nieve o constelación que almacena
detalles acerca de hechos. Por ejemplo, una tabla de dimensión de hora almacena los distintos aspectos del tiempo, como el año, trimestre, mes y día.
• Una tabla de dimensiones almacena información descriptiva sobre los valores numéricos de una tabla de hechos. Por ejemplo, las tablas de dimensiones
para una aplicación de análisis de mercado pueden incluir el tipo de período de tiempo, región comercial y producto.
• Las tablas de dimensiones describen los distintos aspectos de un proceso de negocio. Por ejemplo, si desea determinar los objetivos de ventas, puede
almacenar los atributos de dichos objetivos en una tabla de dimensiones. Las tablas de dimensiones agrupan los datos en la base de datos cuando el
negocio crea informes. Por ejemplo, puede agrupar objetivos de ventas por país, producto o minorista, y dichas agrupaciones se almacenarán en tablas de
dimensiones.
• Cada tabla de dimensiones contiene varias columnas y atributos que se utilizan para describir los procesos de negocio.
• Dado que los datos de una tabla de dimensiones se suelen desnormalizar, las tablas de dimensiones tienen un gran número de columnas. Las tablas de
dimensiones contienen menos filas de datos que la tabla de hechos. Las columnas de una tabla de dimensiones se utilizan para crear informes o para
mostrar resultados de consultas. Por ejemplo, las descripciones textuales de un informe se crean desde las etiquetas de las columnas de una tabla de
dimensiones.
• Considere los puntos siguientes cuando cree las tablas de dimensiones:GranoCada tabla de dimensiones tiene sólo un elemento en el nivel más bajo de
detalle, y este elemento se conoce como grano de la dimensión.Elementos no de claveCada elemento no de clave debe aparecer en una única tabla de
dimensiones.Dimensiones de tiempo y fechaGeneralmente tendrá varias dimensiones de tiempo y fecha en el modelo dimensional.Número de
dimensionesLos modelos dimensionales generalmente sólo contienen entre 10 y 15 tablas de dimensiones. Si necesita más dimensiones, fusiones esas
tabla de dimensiones en una sola tabla.Creación de relaciones de uno a muchosLas filas de una tabla de dimensiones establecen una relación de uno a
muchos con la tabla de hechos o los outriggers.Dimensiones compartidasGeneralmente, las tablas de dimensiones compartidas por varias tablas de
hechos (o varios modelos dimensionales) se denominan dimensiones compartidas. Si ya existen dimensiones compartidas para cualquiera de las
dimensiones del depósito de datos o del modelo dimensional, debe utilizar las dimensiones compartidas. Si va a desarrollar nuevas dimensiones que
puedan utilizarse en todo el almacén de empresa, debe desarrollar un diseño que anticipe las necesidades del almacén de empresa.
• Dimensiones compartidas
Generalmente, las tablas de dimensiones compartidas por varias tablas de hechos (o varios modelos dimensionales) se denominan dimensiones
compartidas.
• Claves primarias y foráneas
Las tablas se relacionan con otras tablas mediante una relación de clave primaria o de clave foránea. Las relaciones de claves primarias y foráneas se
utilizan en las bases de datos relacionales para definir relaciones de muchos a uno entre tablas.
• Dimensiones compartidas
• Generalmente, las tablas de dimensiones compartidas por varias tablas de
hechos (o varios modelos dimensionales) se denominan dimensiones
compartidas.
• Si ya existen dimensiones compartidas para cualquiera de las dimensiones
del depósito de datos o del modelo dimensional, debe utilizar las
dimensiones compartidas. Si va a desarrollar nuevas dimensiones que
puedan utilizarse en todo el almacén de empresa, debe desarrollar un
diseño que anticipe las necesidades del almacén de empresa. Con el fin de
averiguar por anticipado las necesidades del almacén, es posible que deba
interactuar con varios procesos de negocio para saber cómo definirían las
dimensiones.
• En el entorno de trabajo, las dimensiones compartidas utilizan el siguiente
icono:
• Claves primarias y foráneas
• Las tablas se relacionan con otras tablas mediante unarelación de clave primaria o de clave foránea. Las
relaciones de claves primarias y foráneas se utilizan en las bases de datos relacionales para definir relaciones
de muchos a uno entre tablas.
• Las relaciones de claves primarias y foráneas entre tablas en un esquema de estrella o copo de nieve, a veces
llamadas relaciones de muchos a uno, representan las vías de acceso a través de las cuales las tablas
relacionadas se unen en la base de datos. Estas vías de acceso de unión son la base para formar consultas de
datos históricos. Para obtener más información sobre las relaciones de muchos a uno, consulte
Relaciones de muchos a uno.
• Claves primariasUna clave primaria es una columna o un conjunto de columnas en una tabla cuyos valores
identifican de forma exclusiva una fila de la tabla. Una base de datos relacional está diseñada para imponer la
exclusividad de las claves primarias permitiendo que haya sólo una fila con un valor de clave primaria específico
en una tabla.Claves foráneasUna clave foránea es una columna o un conjunto de columnas en una tabla cuyos
valores corresponden a los valores de la clave primaria de otra tabla. Para poder añadir una fila con un valor de
clave foránea específico, debe existir una fila en la tabla relacionada con el mismo valor de clave primaria.
• Claves sucedáneas
Las claves sucedáneas unen las tablas de dimensiones a la tabla de hechos. Las claves sucedáneas son un
medio importante para identificar cada instancia o entidad en una tabla de dimensiones.
• Las claves sucedáneas unen las tablas de dimensiones a la tabla de hechos. Las claves sucedáneas son un medio importante para identificar cada instancia o entidad en una
tabla de dimensiones.
• Razones para utilizar las claves sucedáneas
• Las tablas de datos de varios sistemas de origen OLTP pueden utilizar distintas claves para la misma entidad.También es posible que una sola clave sea utilizada por distintas
instancias de la misma entidad. Esto significa que distintos clientes se pueden representar utilizando la misma clave en distintos sistemas OLTP.Esto puede constituir un
grave problema al intentar consolidar la información de diversos sistemas de origen. O para las empresas que intentan crear/modificar depósitos de datos después de
fusiones y adquisiciones. Los sistemas existentes que proporcionan datos históricos pueden haber utilizado un sistema de numeración diferente al sistema OLTP actual.
Además, es posible que los sistemas desarrollados independientemente no utilicen las mismas claves, o que utilicen claves que estén en conflicto con los datos de los
sistemas de otras divisiones. Esta situación puede no causar problemas si cada departamento notifica independientemente datos de resumen, pero sí lo puede causar si se
intenta conseguir una vista a nivel de empresa de los datos.
• Esto significa que no podemos confiar en utilizar las claves primarias naturales del sistema de origen como claves primarias dimensionales, ya que no existe garantía de que
las claves primarias naturales sean exclusivas para cada instancia. Una clave sucedánea identifica de forma exclusiva cada entidad de la tabla de dimensiones,
independientemente de su clave de origen natural. Esto se debe fundamentalmente a que una clave sucedánea genera un valor entero simple para cada nueva entidad.
• Las claves sucedáneas proporcionan el medio para mantener la información de depósito de datos cuando cambian las dimensiones.Las claves sucedáneas son necesarias
para gestionar los cambios en los atributos de las tablas de dimensiones.Las claves del sistema OLTP naturales pueden cambiar o ser reutilizadas en los sistemas de datos de
origen.Algunos sistemas tienen claves de reutilización pertenecientes a datos obsoletos o para datos que se han purgado. No obstante, una clave puede seguir utilizándose
en los datos históricos del depósito de datos, y la misma clave no se puede utilizar para identificar distintas entidades.El diseño, implementación y administración de las
claves sucedáneas es responsabilidad del equipo de depósito de datos. Las claves sucedáneas se mantienen en el área de preparación de datos durante el proceso de
transformación de datos.
• Mejorar el rendimiento de las consultasLas claves sucedáneas en enteros cortos conllevan una tabla de hechos más estrecha. Cuando más estrecha sea la tabla de hechos,
mejor será el rendimiento.Gestionar casos de excepciónSi se deben determinar requisitos o no son necesarios, utilice una clave sucedánea.Los cambios o la realineación de
medidas debe llevarse a cabo en una columna independiente de la tabla.Si se deben revisar o resumir los datos, independientemente del número de veces que aparezcan
en la tabla, debe utilizar esa columna como parte de la clave sucedánea.
• Evite los identificadores exclusivos globalmente como claves sucedáneas
• Los identificadores exclusivos globalmente funcionan bien en los sistemas OLTP de origen, pero son difíciles de utilizar cuando se trata de depósitos de datos. Esto de debe
fundamentalmente a dos razones:Los identificadores exclusivos globalmente utilizan una importante cantidad de espacio en comparación con los correspondientes enteros.
Los identificadores exclusivos globalmente ocupan aproximadamente 16 pulgadas cada uno, mientras que un entero ocupa alrededor de 4 bytes.
• Los índices de las columnas de identificadores exclusivos globalmente son relativamente más lentos que los índices de las claves de enteros, ya que los identificadores
exclusivos globalmente son cuatro veces más grandes.
• Las claves sucedáneas unen las tablas de dimensiones a la tabla de hechos. Las claves sucedáneas son un medio importante para identificar cada instancia o entidad en una
tabla de dimensiones.
• Razones para utilizar las claves sucedáneas
• Las tablas de datos de varios sistemas de origen OLTP pueden utilizar distintas claves para la misma entidad.También es posible que una sola clave sea utilizada por distintas
instancias de la misma entidad. Esto significa que distintos clientes se pueden representar utilizando la misma clave en distintos sistemas OLTP.Esto puede constituir un
grave problema al intentar consolidar la información de diversos sistemas de origen. O para las empresas que intentan crear/modificar depósitos de datos después de
fusiones y adquisiciones. Los sistemas existentes que proporcionan datos históricos pueden haber utilizado un sistema de numeración diferente al sistema OLTP actual.
Además, es posible que los sistemas desarrollados independientemente no utilicen las mismas claves, o que utilicen claves que estén en conflicto con los datos de los
sistemas de otras divisiones. Esta situación puede no causar problemas si cada departamento notifica independientemente datos de resumen, pero sí lo puede causar si se
intenta conseguir una vista a nivel de empresa de los datos.
• Esto significa que no podemos confiar en utilizar las claves primarias naturales del sistema de origen como claves primarias dimensionales, ya que no existe garantía de que
las claves primarias naturales sean exclusivas para cada instancia. Una clave sucedánea identifica de forma exclusiva cada entidad de la tabla de dimensiones,
independientemente de su clave de origen natural. Esto se debe fundamentalmente a que una clave sucedánea genera un valor entero simple para cada nueva entidad.
• Las claves sucedáneas proporcionan el medio para mantener la información de depósito de datos cuando cambian las dimensiones.Las claves sucedáneas son necesarias
para gestionar los cambios en los atributos de las tablas de dimensiones.Las claves del sistema OLTP naturales pueden cambiar o ser reutilizadas en los sistemas de datos de
origen.Algunos sistemas tienen claves de reutilización pertenecientes a datos obsoletos o para datos que se han purgado. No obstante, una clave puede seguir utilizándose
en los datos históricos del depósito de datos, y la misma clave no se puede utilizar para identificar distintas entidades.El diseño, implementación y administración de las
claves sucedáneas es responsabilidad del equipo de depósito de datos. Las claves sucedáneas se mantienen en el área de preparación de datos durante el proceso de
transformación de datos.
• Mejorar el rendimiento de las consultasLas claves sucedáneas en enteros cortos conllevan una tabla de hechos más estrecha. Cuando más estrecha sea la tabla de hechos,
mejor será el rendimiento.Gestionar casos de excepciónSi se deben determinar requisitos o no son necesarios, utilice una clave sucedánea.Los cambios o la realineación de
medidas debe llevarse a cabo en una columna independiente de la tabla.Si se deben revisar o resumir los datos, independientemente del número de veces que aparezcan
en la tabla, debe utilizar esa columna como parte de la clave sucedánea.
• Evite los identificadores exclusivos globalmente como claves sucedáneas
• Los identificadores exclusivos globalmente funcionan bien en los sistemas OLTP de origen, pero son difíciles de utilizar cuando se trata de depósitos de datos. Esto de debe
fundamentalmente a dos razones:Los identificadores exclusivos globalmente utilizan una importante cantidad de espacio en comparación con los correspondientes enteros.
Los identificadores exclusivos globalmente ocupan aproximadamente 16 pulgadas cada uno, mientras que un entero ocupa alrededor de 4 bytes.
• Los índices de las columnas de identificadores exclusivos globalmente son relativamente más lentos que los índices de las claves de enteros, ya que los identificadores
exclusivos globalmente son cuatro veces más grandes.
Jerarquías equilibradas
• En las jerarquías equilibradas, las ramas de la jerarquía
descienden al mismo nivel, y el padre de cada miembro
está en el nivel inmediatamente superior al miembro.
• Una jerarquía equilibrada puede representar una fecha
en la que el significado y la profundidad de cada nivel,
como el nivel anual, trimestral y mensual, sean
coherentes. Son coherentes porque cada nivel
representa el mismo tipo de información, y cada nivel es
equivalente lógicamente. La Figura 1 muestra un
ejemplo de una jerarquía de tiempo equilibrada.
• Jerarquías desequilibradas
• Las jerarquías desequilibradas incluyen niveles que tienen una
relación padre-hijo coherente, pero tienen niveles lógicos
incoherentes. Las ramas de la jerarquía también pueden tener
profundidades incoherentes.
• Un ejemplo de jerarquía desequilibrada es una gráfica de
organización, que muestra relaciones de información entre los
empleados de una organización. Los niveles de la estructura
organizativa están desequilibrados, y algunas ramas de la
jerarquía tienen más niveles que otras.
• Jerarquías desiguales
• En las jerarquías desiguales, el miembro padre de al menos un miembro de una
dimensión no está en el nivel inmediatamente superior al miembro. Al igual que las
jerarquías desequilibradas, las ramas de las jerarquías pueden descender a niveles
diferentes.
• Una jerarquía desigual puede representar una jerarquía geográfica en la que el significado
de cada nivel, como por ejemplo la ciudad o el país, se utilice coherentemente, pero la
profundidad de la jerarquía varía. En la Figura 1 se muestra una jerarquía geográfica que
tiene definidos los niveles continente, país, provincia/estado y ciudad. Una rama tiene
América del Norte como continente, Estados Unidos como país, California como provincia
o estado y San Francisco como ciudad. Sin embargo, la jerarquía se hace desigual cuando
un miembro no tiene una entrada en todos los niveles. Por ejemplo, otra rama tiene
Europa como continente, Grecia como país, y Atenas como ciudad, pero no tiene una
entrada para el nivel de provincia o estado porque este nivel no es aplicable a Grecia para
el modelo de negocio de este ejemplo. En este ejemplo, las ramas Grecia y Estados Unidos
descienden a distintas profundidades creando una jerarquía desigual.
• Jerarquías padre-hijo
• Una jerarquía padre-hijo contiene varios niveles que realizan un seguimiento de las
relaciones internas de la jerarquía.
• Para crear una jerarquía padre-hijo, debe crear una sola tabla o vista que represente la
jerarquía padre-hijo. Si necesita varias tablas para crear la jerarquía, puede crear una vista
que aplane la estructura. El nivel superior de la jerarquía utiliza la clave padre como clave
de nivel. El nivel inferior contiene la clave hijo. Por ejemplo, en una jerarquía que
represente una estructura organizativa, puede tener dos niveles: gestor y empleado. El
nivel de gestor es el nivel padre, y el nivel de empleado es el nivel hijo.
• Una jerarquía padre-hijo puede representar una gráfica de organización. Por ejemplo, la
Figura 1 muestra un director general (CEO) en el nivel superior de la jerarquía y al menos
dos personas subordinadas, incluido el director de operaciones y el secretario de dirección.
El director ejecutivo tiene además más subordinados, pero este no es el caso del secretario
de dirección. Las relaciones padre-hijo en ambas ramas de la jerarquía son coherentes. Sin
embargo, los niveles de ambas ramas no son equivalentes lógicos. Por ejemplo, un
secretario de dirección no es el equivalente lógico de un director de operaciones.
• Creación de una jerarquía en un modelo dimensional
• Utilice el entorno de trabajo para crear una jerarquía en el
modelo dimensional. Por ejemplo, cree una sola jerarquía de
tiempo en una dimensión de hora para realizar un seguimiento
de las ventas a nivel diario, trimestral y anual.
• Antes de empezar
• Debe tener un modelo de datos lógicos o un modelo de datos
físicos. La notación dimensional debe estar habilitada.
• Acerca de esta tarea
• Procedimiento
• Para crear una jerarquía, siga estos pasos:
• En el Explorador de proyectos de datos,
seleccione una entidad o una tabla de
dimensiones en el modelo dimensional.
• Genere una jerarquía o cree una nueva
jerarquía:
Descripció
Opción n
Generar Pulse con
una el botón
jerarquía y derecho
niveles del ratón
basados en en la
la notación entidad o
dimension la tabla de
al dimensione
sy
pulse Gene
rar
jerarquía.
Crear una Pulse con
jerarquía el botón
en blanco derecho
del ratón
en el
objeto y
pulseAñadi
r objeto de
datos > Jer
arquía.
• La jerarquía se crea y se muestra debajo de la entidad o la
tabla de dimensiones. Si ha creado una jerarquía en
blanco, puede añadir niveles a la dimensión desde la vista
de propiedades.
• Creación de un nivel en una jerarquía
Utilice el entorno de trabajo para añadir un nivel a una
jerarquía. Por ejemplo, puede añadir un nivel anual a una
jerarquía de tiempo para realizar un seguimiento anual de
los cambios en las ventas.
• Creación de un nivel en una jerarquía
• Utilice el entorno de trabajo para añadir un nivel a una jerarquía. Por ejemplo, puede añadir un nivel
anual a una jerarquía de tiempo para realizar un seguimiento anual de los cambios en las ventas.
• Después de crear una jerarquía, puede añadirle un nivel.
• Procedimiento
• Para crear un nivel, siga estos pasos:
• En el Explorador de proyectos de datos, seleccione la jerarquía en el modelo de datos.
• Abra y complete los pasos de la ventana Crear nivel.
– Pulse con el botón derecho del ratón en la jerarquía y pulse Añadir objeto de datos > Nivel. Se abre la
ventana Crear nivel.
– Seleccione los atributos o columnas que desea utilizar como atributos de nivel, asigne los roles y pulse Aceptar.
• El nivel se crea y se muestra bajo el objeto de jerarquía en el Explorador de proyectos de datos.
• Outriggers
• Un outrigger es una entidad o una tabla de dimensiones unida a otras
tablas de dimensiones en un esquema de estrella. Los outriggers se
utilizan cuando una tabla de dimensiones tiene un esquema de copo
de nieve.
• Los outriggers son entidades o tablas compartidas por más de una
dimensión.
• Una entidad o tabla que esté incluida en una jerarquía pero no esté
relacionada directamente con la tabla de hechos se conoce como
outrigger. Los outriggers se utilizan con frecuencia cuando otra
dimensión hace referencia a una entidad o tabla de dimensiones. La
clave foránea de una entidad o tabla de dimensiones hace referencia a
la clave primaria de un outrigger.
• Medidas
• Las medidas definen un atributo de medida y se utilizan en las tablas de hechos. Puede calcular medidas correlacionándolas directamente con un valor numérico en una columna o
atributo. Una función de agregación resume el valor de las medidas para el análisis dimensional.
• Las medidas tienen sentido en el contexto de un conjunto de dimensiones. Por ejemplo, unos ingresos de 300 no tienen sentido en sí mismos. Cuando se pone una medida de ingresos en
el contexto de las dimensiones, como por ejemplo región y tiempo, la medida tiene sentido: los ingresos de Nueva York en enero son de 300. Ejemplos comunes de medidas son los
ingresos, el coste y las ganancias.
• Una medida se define mediante una lista de agregación. Si una medida tiene más de una agregación, las funciones de agregación se realizarán en el orden en que aparecen listadas, y cada
agregación posterior tomará como entrada el resultado de la agregación anterior.
• Cada agregación especifica una función que se aplica a la lista de dimensiones correspondiente. La función de agregación puede ser cualquier función de agregación soportada por la base
de datos subyacente. El entorno de trabajo soporta las siguientes funciones de agregación:AVG
• CORRELATION
• COUNT
• COUNT_BIG
• COVARIANCE
• MAX
• MIN
• STTDEV
• SUM
• VARIANCE
• El objeto de medida sólo puede agregar cada dimensión una vez. Una medida debe tener una agregación con una lista vacía de dimensiones, y otras agregaciones deben tener una lista
explícita de dimensiones. La agregación para una lista vacía de dimensiones se aplica a todas las dimensiones del modelo de cubo que no son utilizadas específicamente por otra
agregación.
• Si la medida tiene una función de agregación, como por ejemplo CORRELATION, que requiere dos o más parámetros, la medida tendrá dos o más expresiones SQL.
• Las medidas también tienen un tipo de datos basado en tipos de datos SQL. El entorno de trabajo determina automáticamente el tipo de datos de una medida.
• Las medidas de una tabla de hechos pueden ser de uno de estos tipos:AditivaLas medidas aditivas son aquellas que se pueden agregar a todas las dimensiones de la tabla de hechos, y son
el tipo más común de medida. Las medidas aditivas se utilizan en varias dimensiones con el fin de realizar sumas.Dado que el modelado dimensional implica jerarquías en dimensiones, la
agregación de información en distintos miembros de la jerarquía es un elemento clave en la utilidad del modelo. Puesto que la agregación es un proceso aditivo, utilice medidas aditivas el
mayor número de veces posible.
• SemiaditivaLas medidas semiaditivas se pueden agregar a algunas dimensiones, pero no a todas. Por ejemplo, medidas como el recuento de personas y el inventario se consideran
semiaditivas.No aditivaLas medidas no aditivas son aquellas que no se pueden agregar a ninguna de las dimensiones. Estas medidas no se pueden agregar lógicamente entre registros o
filas de hechos. Las medidas no aditivas generalmente son el resultado de proporciones u otros cálculos matemáticos. El único cálculo que se puede realizar para dicha medida es obtener
un recuento del número de filas de tales medidas.
• Creación de modelos dimensionales lógicos y físicos
• Para crear un modelo dimensional en un proyecto, puede crear un nuevo modelo
de datos lógicos o físicos con notación dimensional o habilitar la notación
dimensional en un modelo de datos lógicos o físicos existente.
• Antes de empezar
• Debe crear un proyecto de diseño de datos en elExplorador de proyectos de datos.
• Si crea un nuevo modelo de datos lógicos o físicos con notación dimensional, ésta
se habilitará automáticamente. Si habilita la notación dimensional en un modelo de
datos existente, el entorno de trabajo mostrará la notación dimensional de un
modelo de datos.
• Nota: Si importa un modelo de datos del sistema de archivos al espacio de trabajo,
debe habilitar la notación dimensional en el modelo, incluso si el modelo contiene
elementos dimensionales.
• Jerarquías
• Una jerarquía es una relación de muchos a uno entre los miembros de una tabla o entre tablas. Una jerarquía consta básicamente
de distintos niveles, y cada uno corresponde a un atributo de dimensión.
• En otras palabras, una jerarquía es una especificación de niveles que representa relaciones entre distintos atributos de una
jerarquía. Por ejemplo, una posible jerarquía en la dimensión de fecha es Año > Trimestre> Mes > Día.
• El entorno de trabajo soporta cuatro tipos importantes de jerarquías:
• Jerarquías equilibradas
En las jerarquías equilibradas, las ramas de la jerarquía descienden al mismo nivel, y el padre de cada miembro está en el nivel
inmediatamente superior al miembro.
• Jerarquías desequilibradas
Las jerarquías desequilibradas incluyen niveles que tienen una relación padre-hijo coherente, pero tienen niveles lógicos
incoherentes. Las ramas de la jerarquía también pueden tener profundidades incoherentes.
• Jerarquías desiguales
En las jerarquías desiguales, el miembro padre de al menos un miembro de una dimensión no está en el nivel inmediatamente
superior al miembro. Al igual que las jerarquías desequilibradas, las ramas de las jerarquías pueden descender a niveles
diferentes.
• Jerarquías padre-hijo
Una jerarquía padre-hijo contiene varios niveles que realizan un seguimiento de las relaciones internas de la jerarquía.
• Creación de una jerarquía en un modelo dimensional
Utilice el entorno de trabajo para crear una jerarquía en el modelo dimensional. Por ejemplo, cree una sola jerarquía de tiempo
en una dimensión de hora para realizar un seguimiento de las ventas a nivel diario, trimestral y anual.
• Inicio de Information Center de Integrated Data Management
• Notas del release
• Visiones generales de productos
• Instalación, actualización y configuración
• Guías de aprendizaje
• Ejemplos
• Diseñar y modelar bases de datos
• Desarrollar y optimizar rutinas y aplicaciones de datos
• Desplegar cambios de bases de datos
• Gestionar objetos de datos y servidores de datos
• Enmascaramiento de información
• Supervisar consultas, bases de datos y servidores de datos
• Resolución de problemas
• Consulta
• ibm.com: About IBM - Privacy - Contact
El modelo dimensional distingue tres elementos básicos:
• Hechos: es la representación en el data warehouse de los
procesos de negocio de la organización. Por ejemplo: una
venta puede identificarse como un proceso de negocio.
Los hechos se podrán reconocer además porque siempre
tienen asociada una fecha, y una vez registrados no se
modifican ni se eliminan (para no perder la historia).
• Métrica: son los indicadores de negocio de un proceso
de negocio. Aquellos conceptos cuantificables que
permiten medir nuestro proceso de negocio. Por
ejemplo, en una venta tenemos el importe de la misma y
la cantidad vendida. Existen métricas derivadas, como el
precio unitario, que se obtiene al dividir el importe total
por las unidades vendidas.
• Dimensión: es la representación en el data warehouse
de un punto de vista para los hechos de cierto proceso
de negocio. Si regresamos al ejemplo de una venta, para
la misma tenemos el cliente que ha comprado, la fecha
en la que se ha realizado, el producto vendido,… Estos
conceptos pueden ser considerados como vistas para
este proceso de negocio. Puede ser interesante
recuperar todas las compras realizadas por un cliente, o
para un producto o familia de productos, o para un lapso
determinado.
• Los conceptos básicos – hechos, métricas y
dimensiones (facts, measures y dimensions) –
se representan en el modelo como relaciones
(tablas) dentro de un esquema dimensional.
Según las técnicas de modelado utilizadas, ese
esquema dimensional puede adoptar forma
de estrella o de copo de nieve.
• Vemos que existe una tabla de hechos en el centro (h_ventas_diarias), y una tabla de
dimensión para cada dimensión de análisis que participa de la descripción de ese hecho
(dim_xxx).
Las columnas de la tabla de hechos incluyen las dimensiones que identifican el hecho, y los
hechos o medidas del negocio. Las columnas en las tablas de dimensión incluyen atributos
asociados a cada posible valor de la dimensión.
• Los atributos de una dimensión permitirán agrupar los hechos
jerárquicamente, para poder consolidar y desagregar las mediciones según se
desee. Como ejemplos tenemos:
Para la dimensión fecha: año, mes, día, nombre del mes, día de la semana,
trimestre, …
• Para la dimensión producto: tipo de producto, familia, unidad de medida, …
•
Cuando a una dimensión no se le pueden asociar múltiples atributos, se dice
que tenemos una dimensión degenerada, y solo aparecerá como una columna
en la tabla de hechos. Por ejemplo, si tuviéramos en nuestro ejemplo una
dimensión “Estado de la Venta”, con los posibles valores: “Confirmada”,
“Pendiente”, “Cancelada”; en este caso la dimensión serviría solo para separar
las ventas según su estado, y no se requieren atributos adicionales.
• Eventualmente, pudiera surgir un esquema en estrella integrado solo por una tabla
de hechos con dimensiones degeneradas.
Por otro lado, cuando se decide normalizar las tablas de dimensiones para eliminar
campos redundantes, tenemos lo que se conoce como esquema en copo de nieve.
• La decisión de normalizar, o no, una tabla de
dimensión corresponde a los diseñadores, quienes
deberán tener presente que el objetivo es dar
respuesta rápida a las consultas de los usuarios, no
ahorrar espacio. Generalmente, el espacio que se
logra ahorrar al normalizar la dimensión, es
insignificante comparado con el volumen de la
tabla de hechos, mientras el impacto en los
tiempos de respuesta es apreciable.
Las bases de datos multidimensionales contienen las ventajas siguientes.
• Presentación y navegación realzadas de los datos Intuitivo hoja de balance - las vistas semejantes de los datos son la salida de
bases de datos multidimensionales. Tales visiones son difíciles de generar en sistemas emparentados sin el uso de las preguntas
complejas del SQL, mientras que otras no se pueden realizar por el SQL estándar en todos, eg. Resultados del examen de la tapa
diez. Facilidad del mantenimiento Las bases de datos multidimensionales son muy fáciles de mantener, porque se almacenan los
datos de la misma forma que se ven, que están según sus cualidades fundamentales, así que no se requiere ningunos gastos
indirectos de cómputo adicionales para las preguntas de la base de datos. Compare esto al sistema emparentado, donde
indexación de direcciones compleja y ensambla puede ser utilizado que requiere mantenimiento y gastos indirectos significativos.
Funcionamiento creciente La base de datos multidimensional alcanza los niveles de funcionamiento que están bien superior al de
los sistemas emparentados que realizan requisitos de almacenaje similares de datos. Estos niveles del alto rendimiento animan y
permiten OLAP usos. El funcionamiento se puede mejorar en sistemas emparentados a través de la base de datos que templa,
pero la base de datos no se puede templar para cada en marcha posible pregunta. En sistemas emparentados, el templar es
flexibilidad absolutamente específica, por lo tanto que disminuye, y también requiere a especialistas costosos de la base de datos.
Resumiendo, los sistemas multidimensionales de la base de datos son una tecnología complementaria a los sistemas
emparentados de la entidad, y en algunas circunstancias hace más sentido de utilizar órdenes multidimensionales más bien que
las tablas emparentadas.
Donde los sistemas multidimensionales sobresalen sobre sus contrapartes emparentadas del sistema está en el área de la
presentación de los datos y análisis, donde los datos en la pregunta se conducen a ser convenientes para los sistemas
multidimensionales, tales como donde existen las correlaciones complejas.
Las vistas de datos a nivel superior sobre muchas combinaciones de dimensiones hacen sistemas multidimensionales
particularmente útiles para el análisis de tendencia en un cierto plazo cerca gerencia personal de organizaciones, debido a la
facilidad del te de ver los datos de una manera más naturalmente intuitiva.
• Aparte de las ventajas inherentes de usar una estructura multidimensional del arsenal, las bases de datos multidimensionales
también contienen las ventajas siguientes.
Presentación y navegación realzadas de los datos Intuitivo hoja de balance - las vistas semejantes de los datos son la salida de bases
de datos multidimensionales. Tales visiones son difíciles de generar en sistemas emparentados sin el uso de las preguntas complejas
del SQL, mientras que otras no se pueden realizar por el SQL estándar en todos, eg. Resultados del examen de la tapa diez. Facilidad
del mantenimiento Las bases de datos multidimensionales son muy fáciles de mantener, porque se almacenan los datos de la misma
forma que se ven, que están según sus cualidades fundamentales, así que no se requiere ningunos gastos indirectos de cómputo
adicionales para las preguntas de la base de datos. Compare esto al sistema emparentado, donde indexación de direcciones compleja
y ensambla puede ser utilizado que requiere mantenimiento y gastos indirectos significativos. Funcionamiento creciente La base de
datos multidimensional alcanza los niveles de funcionamiento que están bien superior al de los sistemas emparentados que realizan
requisitos de almacenaje similares de datos. Estos niveles del alto rendimiento animan y permiten OLAP usos. El funcionamiento se
puede mejorar en sistemas emparentados a través de la base de datos que templa, pero la base de datos no se puede templar para
cada en marcha posible pregunta. En sistemas emparentados, el templar es flexibilidad absolutamente específica, por lo tanto que
disminuye, y también requiere a especialistas costosos de la base de datos. Resumiendo, los sistemas multidimensionales de la base
de datos son una tecnología complementaria a los sistemas emparentados de la entidad, y en algunas circunstancias hace más
sentido de utilizar órdenes multidimensionales más bien que las tablas emparentadas.
Donde los sistemas multidimensionales sobresalen sobre sus contrapartes emparentadas del sistema está en el área de la
presentación de los datos y análisis, donde los datos en la pregunta se conducen a ser convenientes para los sistemas
multidimensionales, tales como donde existen las correlaciones complejas.
Las vistas de datos a nivel superior sobre muchas combinaciones de dimensiones hacen sistemas multidimensionales
particularmente útiles para el análisis de tendencia en un cierto plazo cerca gerencia personal de organizaciones, debido a la facilidad
del te de ver los datos de una manera más naturalmente intuitiva.
• Entidad Relación (ER) el modelar y la estructuración de datos en las tablas normalizadas popular y se han estandardizado
extensamente entre los administradores y los diseñadores entrenados de la base de datos, que utilizan rutinariamente el DBMS
emparentado para almacenar los volúmenes enormes de datos de organización con tarifas muy altas de la transacción.
Aunque engañoso es simple diseñar y funcionar, ER modelando prueba problemático para el usuario final no técnico que diseña y
que se ejecuta preguntas. Los datos que tienen acceso pueden requerir el complejo ensamblan de muchas tablas y el usuario final
inexperimentado puede ser forzado emplearlo los profesionales para diseñar las preguntas complejas de los datos usando a lenguaje
de interrogación por ejemplo SQL. Cuando las preguntas que modifican datos o las estructuras de la tabla se ejecutan, la probabilidad
de producir errores o las consecuencias indeseables se aumenta dramáticamente.
En un sistema de la base de datos de la multi-dimensión, los datos se presentan al usuario como a hypercube o arsenal
multidimensional, donde cada valor individual de los datos es contenido dentro de una célula accesible por índices múltiples. La
estructura multidimensional del arsenal representa un de alto nivel de la organización que la tabla emparentada. La estructura sí
mismo representa una vista más inteligente de los datos que contiene, porque las perspectivas de los datos se encajan directamente
en la estructura como dimensiones, más bien que siendo colocado en campos.
Una variedad de estas formas ha sido aspirada almacenando objetos en una base de datos. Algunos productos se han acercado al
problema del uso que programa el final, por haciendo los objetos manipulados según el programa persistente. Esto también
típicamente requiere la adición de una especie de lengua de pregunta, ya que lenguajes de programación convencionales no tienen la
capacidad de encontrar objetos basados en su contenido de la información. Los otros han atacado el problema a partir del final de
base de datos, por definiendo un modelo de datos mediante objetos para la base de datos, y definiendo un lenguaje de
programación de base de datos que permite a capacidades de programa llenas así como instalaciones de pregunta tradicionales.
Identificar Medidas y Dimensiones en un
Modelo Dimensional
Generar jerarquías de análisis, jerarquías
múltiples de tablas dimensionales, llaves
artificiales y granularidad en el modelo
dimensional.
tablas sumarias y su modelamiento
Diseño e implementación del esquema físico
del DW en el servidor
administración de la metadata
Métodos para analizar e identificar las
Fuentes de Datos requeridas
Cubos OLAP
• Un cubo OLAP, por sus siglas en inglés Online
Analytical Processing, es una de las primeras
base de datos multidimensional. Edgar Frank
Codd fue el precursor de estas, las cuales
nacen para suplir la necesidad de búsquedas
de sentencias mas rápidas,
• Un cubo OLAP, Online Analytical Processing, es una base de
datos pero multidimensional, que guarda los datos físicos a través
de un vector multidimensional.
• Una de las principales características de la potencia de los cubos
OLAP es la rápida ejecución de las sentencias SQL de tipo SELECT.
• Edgar Frank Codd fue el pionero en este tipo de bases de datos y
precursor del diseño del cubo, su idea era tener los datos en
vectores con el fin de un análisis mucho más rápido.
• Los vectores serían los cubos y con esto se resolvía el problema
de las bases de datos relacionales las cuales no podían analizar
instantáneamente altas cantidades de datos.
Tipos de sistemas OLAP
ROLAP
Los sistemas OLAP son los que almacenan los datos de forma relacional, se caracterizan por ser
detallados, y por lo general se encuentran en tablas normalizadas.
El cubo ROLAP es el más utilizado en la actualidad para la creación de formularios, donde cada
campo es definido según un ID y posteriormente relacionado en las tablas de SQL
MOLAP
El sistema MOLAP guarda los datos en una base de datos multidimensional, con esto se optimizan
los tiempo de búsqueda y respuesta.
Una de las características de los cubos MOLAP es que para cada dimensión hay un campo, y otro
campo por cada hecho.
HOLAP (Hybrid OLAP)
El cubo HOLAP, es la unión de los dos anteriores, básicamente puede almacenar los datos en un
motor relacional, pero también puede almacenar otros en bases de datos multidimensional.
En conclusión los cubos OLAP son bases de datos multidimensionales, para crear un cubo el
usuario puede utilizar la web Pentaho.com una herramienta open source para la creación de
cubos OLAP.
Laboratorio
Dimensiones, cubos y sus
características
Lenguajes de Consultas OLAP
• DMX «Data Mining Extensions» es un
lenguaje para modelos de minería de datos;
• MDX «Multidimensional Expressions» es un
lenguaje de consulta para bases de datos
OLAP;

Sesión 3 de DataWarehouse

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesión 3 de DataWarehouse

Cargado por

Copyright:

Formatos disponibles

DATAWAREHOUSE

Fases del Diseño

Cree y estudie la lista de procesos de negocio de empresa

Consejo: Puede ser útil asignar valores a cada factor de asesoramiento

Identifique las entidades y medidas de alto nivel que son comunes en

• Un esquema de estrella es un tipo de esquema de

Las jerarquías típicas, que aparecen en cualquier sistema Business

• Identifique las medidas verdaderas para el grano de la tabla.

También podría gustarte