Está en la página 1de 16

GUÍA DE MODELAJE bóveda de datos

Guía de introducción a Data Vault Modelado

GENESEE ACADEMIA, LLC

2012 Escrito por:


Hans Hultgren
GUÍA DE MODELAJE bóveda de datos

Guía de introducción a Data Vault Modelado

Adelante

El modelado de datos Vault es más convincente cuando se aplica a un programa de almacenamiento de datos empresariales (EDW).

Varias decisiones clave sobre el tipo de programa, proyectos relacionados, y el alcance de la iniciativa más amplia son luego

respondidas por esta designación. En resumen, la organización que contemple esta iniciativa se compromete a un programa de

almacenamiento de datos variable en el tiempo y la clave del negocio impulsada integrado, no volátil.

Los principios de la bóveda datos son específicamente bien adecuados para tal programa y - cuando se aplica consistentemente - puede

proporcionar la organización con algunos beneficios muy convincentes. Estos incluyen auditabilidad, la agilidad, la adaptabilidad, la

alineación con el negocio, y el apoyo a las iniciativas de almacenamiento de datos operacionales.

Para obtener estos beneficios, sin embargo, la organización deberá comprometerse a ambos factores a nivel de programa EDW así como

el modelado de datos bóveda de patrones, reglas y métodos específicos. Esta guía presenta el modelado bóveda de datos en el contexto

de la EDW.
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

1
Índice

F Orward ................................................. .................................................. ............................. 1 I NDICE ..................................................


.................................................. ................................. 2 T ÉL EDW P ROGRAMA ..................................................
.................................................. ............. 3 T ÉL re ATA V AULT F Nociones básicas .................................................
............................................... 4 M ODELING CON LA re ATA V AULT .................................................. ............................................. 6 T hink
re IFFERENTLY ................................................. .................................................. ................ 7 T ÉL si EGOCIOS K EY ..................................................
.................................................. ................. 9 B EGOCIOS K EY UNA LIGNMENT ..................................................
.................................................. ..... 10 A RCHITECTURE .................................................. .................................................. ................... 12
S AMPLIO re ATA V AULT METRO ODELO ................................................. .................................................. .. 13 H YBRID T ABLES ..................................................
.................................................. ................... 14 A PLICACIÓN LA re ATA V AULT ..................................................
.................................................. .. 14 F INAL norte beneficios según objetivos ..................................................
.................................................. ....................... 15

Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

2
El Programa EDW

El Programa (EDW) Enterprise Data Warehousing representa las actividades de almacenamiento de datos en curso de la
organización. Estas actividades incluirán las funciones de mantenimiento del almacén de datos, además del flujo continuo de
proyectos incrementales relacionados con el almacenamiento de datos empresariales. Estos proyectos incrementales se
componen de

una) La adaptación a las nuevas fuentes de datos de los nuevos sistemas internos, externos integraciones,

y de las adquisiciones, y
si) La absorción de los cambios en las fuentes existentes, incluyendo nuevos cuadros, nuevos atributos, nueva

valores de dominio, nuevos formatos y nuevas reglas, y

C) Adaptarse a las nuevas reglas de negocio sobre la aproximación, el grano, y cardinalidad


valores del dominio de claves de negocio, así como los cambios en las relaciones entre ellos, y

re) nuevos requisitos de entrega corriente abajo Accommodating incluyendo nuevo sujeto
áreas, nuevas reglas de negocio, informes de cumplimiento de la normativa y otra adicional y los cambios en los
requisitos de latencia de operación.

Por esta razón, el propio EDW no se designa un “proyecto” (no hay principio y al final discernible, y ningún
conjunto predeterminado de objetivos específicos).

En un sentido más amplio, este programa se puede definir como la función de BI o el Programa de BI dentro de una organización.
Para que quede claro, sin embargo, esto no es más que el grupo que posee las herramientas OLAP. Esta es la opinión nivel más alto
de todo el almacenamiento de datos e inteligencia empresarial (DWBI) dentro de la organización, que incluye el centro de inteligencia
de negocio competencia o BICC, el EDW o equipo de CDW, los componentes relacionados con la gobernabilidad y el medio ambiente,
tanto técnica y organizativa. El éxito de un programa DWBI depende de un compromiso con la organización y una cultura corporativa
de BI.
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

Es precisamente en este contexto donde el enfoque bóveda de datos es el más valioso. Por lo que el Data Vault EDW
se define ante todo por la empresa de ancho, DWBI programa a largo plazo - desde una perspectiva técnica y la
arquitectura desde una perspectiva cultural, la alineación de la organización también.

3
Las camisetas Fundamentos de datos Vaul

La bóveda de datos consta de tres componentes básicos, la Hub, Link y Satélite. Por encima de todas las demás reglas y

factores Programa de DV, el compromiso con la coherencia y la integridad de estas construcciones es de suma importancia para

un programa DV éxito.

los Cubo representa un concepto de negocio básicas, tales como clientes, proveedores, venta o producto. La tabla Hub se forma

alrededor de la clave de negocio de este concepto y se estableció la primera vez que una nueva instancia de esa clave del negocio se

introduce en el EDW. Puede requerir una clave de múltiples partes para asegurar una clave única para toda la empresa, sin embargo la

cardinalidad del concentrador debe ser de 1: 1 con una única instancia del concepto de negocio. El concentrador no contiene información

descriptiva y no contiene FKs. El Hub consiste en la clave de negocio única, con una secuencia de la máquina almacén de identificación,

un sello de fecha de carga / tiempo y un origen de registros.

Figura 1 Cubo

UNA Enlazar representa un relaciones comerciales naturales entre claves de negocio y se establece la primera vez que esta nueva

asociación única se presenta al EDW. Puede representar una asociación entre varios concentradores y en ocasiones otros enlaces. Lo

hace mantener una relación 1: 1 con la asociación definido de negocio único y específico entre ese conjunto de teclas. Al igual que el

Hub, que no contiene información descriptiva. El enlace consiste en la secuencia de identificadores de los concentradores y los enlaces

que se está relacionando solamente, con una secuencia de la máquina almacén de identificación, un sello de fecha de carga / tiempo y

un origen de registros.

Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

Figura 2 Enlazar

Nótese la similitud entre el cubo y el enlace. Ambos representan la primera vez que un concepto de negocio central
(hub) o la relación natural de negocios (Enlace) se introduce en el DW.

4
los Satélite contiene la información descriptiva (contexto) para una clave de negocio. Puede haber varios satélites utilizados para
describir una única clave de negocio (o asociación de teclas) sin embargo, un satélite sólo puede describir una sola tecla (Hub o un
enlace). Hay una buena cantidad de flexibilidad que ofrece los modeladores en cómo diseñar y construir satélites. Enfoques comunes
incluyen el uso de la materia, tasa de cambio, sistema de origen, o el tipo de datos para dividir a cabo contexto y el diseño de los
satélites. El satélite está enchavetado por el ID de secuencia desde el concentrador o un enlace a la que está unido más el sello de
fecha / hora para formar una clave de dos partes.

Tenga en cuenta que el satélite es, pues, la única construcción que gestiona (seguimiento histórico almacén de datos de valores en

el tiempo) de datos de la porción temporal.

Fig. 3 Satélite

Un satélite no tiene un ID de Secuencia de sí mismo y, de hecho, no puede tener una clave diferente que el concentrador o
secuencia de enlace a la que está unido. Además, un satélite no tiene ninguna restricción de clave externa (sin nieve, escamas,
ramificadas o puente).

Estas tres construcciones son los bloques de construcción para la DV EDW. Juntos se pueden utilizar para representar todos los
datos integrados de la organización. Los bujes son las claves de negocio, los enlaces representan todas las relaciones y los
satélites proporcionan todo el contexto y cambia con el tiempo.
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

Fig. 4 Datos Vau lt Modelo

5
Cuando nos fijamos en el Hub y Link juntos, forman la columna vertebral o “estructura esquelética” del modelo. Este modelo
de columna vertebral representa una relación 1: 1 con conceptos básicos de negocios y sus relaciones comerciales naturales.

Fig. 5 Espina dorsal o esquelético St ructure

Tenga en cuenta que l contexto al ( información descriptiva) y l historia al se encuentran en los satélites.

Modelo wi º ing la Bóveda de Datos

El proceso de modelado con el Data Vault está estrechamente alineado con el análisis de negocio. El primer paso es identificar los

concentradores para el área de tema dado. Una vez definidos los concentradores próximo modelo que las relaciones comerciales

naturales entre estos centros. Luego diseñamos y añadir los satélites para proporcionar un contexto para estas construcciones.

PASO TAREA

1.1 Identificar los conceptos de negocio

1.2 Establecer EWBK de concentradores

1.3 concentradores modelo

2.1 Identificar las relaciones de negocios natural

2.2 Analizar las relaciones unidad de trabajo

2.3 Enlaces modelo

3.1 Reunir Atributos de contexto para definir claves Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

3.2 Establecer criterios de diseño y Satélites

3.3 modelo Satélites

Fig. 6 Pasos para modelar ing wi º datos Vau lt

Este proceso no se ocupa de la separación de los hechos a partir de dimensiones, o de la separación de las entidades maestros de

eventos o transacciones. La atención se centra de lleno en el negocio principal

6
- conceptos y sus claves únicas de negocio. En ese sentido, todo lo anterior son candidatos para concentradores. Por ejemplo, los

eventos, incluyendo transacciones se modelan como concentradores.

Piensa diferente

Modelado con Data Vault nos obliga a piensa diferente. La mayoría de nosotros aprendió por primera vez modelado 3NF para
bases de datos operativas. Para gestionar la tercera forma normal, todos los atributos de una entidad debe depender directamente
de la llave de esa entidad. Así el contexto atributos que describen un cliente (apellido, nombre, dirección, ciudad, estado, código
postal, home_phone, mobile_phone, etc.) debe ser colocado en la entidad de cliente, donde la clave identifica de forma exclusiva
una instancia de un cliente. Si incluimos atributos que no dependan de la clave de esa entidad, entonces no estaríamos en 3 rd forma
normal. Del mismo modo, si colocamos algunos de los atributos que dependen de esa llave en otra entidad, de nuevo, ya no
estaríamos en 3 rd forma normal.

En algún momento es posible que también hemos aprendido cómo modelar usando modelado tridimensional técnicas.

Aunque diferentes construcciones de modelado y otras reglas para el modelado, incluyendo el concepto de

contexto atributos dentro de una tabla con una clave de esos atributos sigue siendo el mismo. Un

Conformados Dimensión requiere que los atributos de contexto dependen de la clave de esa dimensión. De

nuevo, si nos movemos a cabo atributos en función de una tecla dimensión a algún otro constructo entonces

ya no tenemos una dimensión conformado.

Aquí se muestra un Customer_Entity en 3NF donde podemos ver la clave de negocio (Customer_Code), la
relación (Customer_Class_SID) y todo el marco en forma de todos los demás atributos de la tabla. Tenga
Fig.en
7 Tomer Cus 3NF

cuenta que esta es una tabla que incluye todo esto estos componentes.

Con el modelado Data Vault separamos las claves de


negocio de las relaciones a partir del contexto. Todas las
claves de negocio se modelan como concentradores,
todas las relaciones y asociaciones se modelan como
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

enlaces, y se proporciona todo el contexto y la historia


mediante los satélites. Se muestra aquí podemos ver que
la clave de negocio (Customer_Code) se encuentra en un
cubo (H_Customer), la relación (Customer_Class_ID) se
encuentra en un enlace (L_Customer_Cust_Class), y el
contexto se modela en varios satélites.

Fig. 8 Data Vault Cliente

7
Mirar hacia atrás para el modelo 3NF y ahora consideran que todos la misma información (los mismos componentes de datos) sobre el

“Cliente” están representados plenamente en ambos modelos. Curiosamente ambos modelos representan una dependencia de una

única clave de negocio. En realidad, si nos basamos en círculos alrededor de cada uno de estos modelos podemos ver que lo que está

dentro de cada círculo es una representación de la misma clave de negocio que es el mismo conjunto de atributos y la misma relación.

Nótese aquí que el llegar desde el “Cliente” a la clase de cliente


se modela a través de una relación con un FK dentro del círculo
3NF.

Lo mismo es cierto para el círculo de DV


en que llegar a “Cliente” a la clase de
cliente se modela a través de una
relación (Enlace) con un FK en ese
enlace y en el perímetro del círculo.

Fig. 9 Modelo 3NF

Es importante pensar en el círculo de DV en la


misma forma que el círculo 3NF.

Esto significa que a) todas las cosas, ya sea en círculo

dependen de una única clave de negocio, b) relaciones

pasan a través del círculo directamente de mesa con la

BK, c) el único cambio de grano en cualquiera de los

círculos se basa en Sello fecha / hora para la propósito


Los datos del almacén GUÍA DE MODELAJE | 5/15/2012
de la historia de seguimiento.
La Fig. 10 Datos Vau lt Modelo

INSINUACIÓN: A medida que avance con Data Vault Modelado, esta visión de pensar diferente será cada vez más
importante. Tenemos la tendencia a ver las tablas de la misma manera que siempre hemos verlos. Por esta razón, se
tiende a volver a combinar las claves con las relaciones con el contexto. Pero tan pronto como lo hace, en realidad se deja
de bóveda y volver a otras formas de modelado. Así que antes de cambiar el grano de un satélite, incluya una relación de
FK en un satélite o concentradores, por favor considere el análisis círculos arriba y reconsiderar.

8
La clave iness autobús

En el centro de la bóveda de datos es el Cubo la cual nos referimos como la clave de negocio. Tal vez el paso inicial más
importante en el modelado de una DV EDW es identificar y diseñar cuidadosamente estas claves de negocio. Para empezar,
una clave de negocio es representante de la entidad negocio principal como “cliente” o “producto”, por ejemplo. Además, el BK
también representa claves basadas en eventos tales como “venta” o “transferencia”. De esta manera, el proceso de diseño de la
Bóveda de datos no se ocupa de las diferencias entre la persona a cabo entidades de tipo / / cosa y las entidades de tipo
evento. Para decirlo de otra manera, no estamos interesados ​en diferenciar Dimensiones de Datos sino que se centra en la
identificación de llaves comerciales que pueden representar bien.

Este enfoque es entonces diferente de los enfoques tradicionales para el modelado de sistemas operativos o mercados de datos. La comparación

más cercana sería la de considerar nuestros esfuerzos en la definición de los elementos de datos maestros para una iniciativa de MDM. En este

caso también, la atención se centra en los términos básicos utilizados en la gestión del negocio.

Desde el Programa DV es la organización en su alcance, las llaves de negocio también debe esforzarse por ser significativa en toda la

empresa. Así que nuestra búsqueda de estas teclas debe dar lugar a la empresa Claves Wide Business (EWBKs). Tenga en cuenta

también que las claves que llegan desde los sistemas de origen específicas no suelen estar totalmente alineados con estos EWBKs. Por

esta razón, no ponemos demasiado énfasis en las claves representadas en cualquier sistema de fuente en particular.

NOTA: Ya que estamos por lo general trata de cientos de fuentes, cada uno comúnmente sujeta a actualizaciones y cambios, no hay que
planificar para modelar nuestro EDW utilizando las teclas accionadas por un subconjunto de estos sistemas de origen.

El proceso de identificar y modelar estas EWBKs es entonces más cerca de un proceso de recogida de los requisitos de negocio
que un análisis del sistema de origen. El equilibrio entre los diversos factores de entrada, con un énfasis en el negocio frente a la
técnica, resume de manera efectiva las mejores prácticas para este proceso.
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

La Fig. 11 Factores de entrada para el diseño de las llaves de negocio DV EDW

9
Las entradas primarias para este procedimiento incluyen:

primero los diseños de procesos de negocios, entrevistas de negocios, mercados de datos, metadatos negocio,

metadatos proceso existente, existe un glosario de negocios si es, modelos semánticos, modelos lógicos, modelos de

información y los artefactos de gestión de datos maestros (si existe) y el modelo de referencia de la industria (a los

componentes medida determinado están alineados) y luego

Segundo los diseños técnicos, bases de datos, metadatos de código fuente, sistema de aplicación (guías,
manuales, diseños) y los datos reales del sistema de origen.

Tenga en cuenta que la EWBK debe ser una clave que trasciende el tiempo y resiste la sustitución de cualquier sistema de fuente

específica. Las teclas del sistema fuente entonces requerir algún tipo de alineación para que coincida con sus EWBKs objetivo

vinculados. Esta alineación será a menudo en desacuerdo con las características completamente primas y auditables de cargas del

sistema fuente persistido. En el


pasado hemos resuelto bien esta alineación en el camino a los marts, o más comúnmente, crea un registro limpia “oro” entre
las cuatro paredes del propio almacén de datos. La primera solución conduce a los silos y anomalías, mientras que el último
puede comprometer la capacidad de auditoría y la aceptación de los usuarios.

Bus iness Clave Al ignment

Debido a que el DV EDW absorbe todos los datos todo el tiempo y mantiene una trazabilidad completa a alimenta sistema de origen,

el almacén de datos no debe perder de resolución sobre estos sistemas auditables de registro. Al mismo tiempo la integración en torno

a la clave de negocio - la EWBK - es una función básica de la DV EDW. Por lo que el EDW hoy en día tiene un reto integrado en

relación con la integración de datos - la alineación de los Cayos de negocios (en toda la empresa) con el crudo y componentes

auditables de la Bóveda de datos.

Por un lado, sabemos que no podemos confiar en que los pormenores primas sólo en el área de ensayo o en nuestros archivos. Nosotros

necesitamos tener todos los datos cargados en el EDW para ser un verdadero “espejo” auditable de las fuentes. Ver la parte inferior izquierda

“llaves en bruto” en la figura 5 a continuación.

Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

La Fig. 12 DV EDW Chaveta de alineación

10
Por otro lado, sabemos que el almacenamiento de datos empresariales (EDW) debe estar alineado con el punto de vista de la organización de

las claves de negocio / términos (EWBKs). Ver la parte superior derecha “Claves de Negocios” en la figura 5.

La integración de estas teclas primas con las EWBKs representa una función básica de la EDW hoy. En efecto, hemos
estado encajonado entre los requisitos de aguas arriba (construir un DW, que incluye todos los datos a nivel atómico y con
una trazabilidad completa) y los requisitos de aguas abajo (alinear los Cayos de negocios con la organización a nivel de
empresa utilizando la terminología de negocios).

NOTA: No podemos confiar en tener estas transformaciones ocurren en la puesta en escena Mart o capas de datos Mart como: a) la
puesta en escena Mart no está destinado a ser persistido y b) los Data Marts son de alcance departamental (no para toda la
empresa). No compartir esta alineación clave del negocio a través de la EDW dará lugar a una falta de integración en torno a las
verdaderas claves de negocio y dará lugar a las inconsistencias aguas abajo comunes a los silos de datos.

La medida en que las fuentes ya están alineados con los EWBKs determinará el alcance de la integración y la
alineación que debe ocurrir en el DV EDW. Ver figura 6 a continuación.

La Fig. 13 DV EDW Ámbito de Key Al ignment

La alineación de estas teclas se facilita a través Enlaces. Como puede verse en la figura 5 en la página anterior, la llave en bruto,
de “Persona” se alinea con la clave de negocio de “cliente” por medio de una estructura de enlaces.

Tenga en cuenta que las convenciones de nombres no son suficientes por sí mismas para justificar la separación de los
centros clave primas y de negocios. Si, de hecho, la persona y el Cliente significaban exactamente lo mismo a la empresa y,
de hecho, eran verdaderos sinónimos plazo negocio, entonces la carga del sistema de registros prima persona podría poblar
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

el Hub Cliente directamente. Sin embargo, en este caso la clave Raw persona no significa, de hecho, algo diferente a la tecla
de clientes comerciales. En este caso se supone que existen reglas de negocio en juego - por ejemplo, un registro de la
persona se determina que es un cliente si estaban involucrados en una transacción de venta, había un no-cero precio de
compra, la transacción se completó con éxito, y el venta no fue cancelado. Como se puede ver aquí, la carga es auditable
prima a la persona y la carga de negocios alineados es al Cliente.

Esas tablas que se cargan mediante este tipo de procesos de negocio deben ser identificados como “ Sysgen ”registros de origen de registros

(generados por nosotros a través de un proceso de reglas de negocio impulsado).

11
Estos componentes de la DV EDW se refieren a menudo como almacén de datos de negocios (BDW) o componentes bóveda de
datos de negocios (BDV).

NOTA: La lógica de negocio en el BDW o BDV puede tomar muchas formas y puede relacionarse con muchos tipos de
transformaciones. La lógica dirigido específicamente a la alineación de llaves en bruto y de negocios es un subconjunto de esta área y, a
menudo referido como el componente de la barra (clave de negocio Reglas de alineación). ¿Porque es esto importante? Debido a que el
objetivo principal de la DV EDW es integrar y historizar datos de diversas fuentes. Las reglas de barras son el corazón de esta actividad.

Tanto la BDW y las capas de barras son parte del almacén de datos de negocios alineados.

tecture Archi

El alto nivel de arquitectura DV EDW incluye un EDW que alinea el RAW con los niveles bar. La arquitectura de
alto nivel se puede representar como se ve aquí.

La Fig. 14 DV EDW arco i tecture

Tenga en cuenta que las reglas de negocio representados en la capa BDW se pueden aplicar ya sea en la misma zona que el EDW o como

una capa separada. Data Marts puede entonces la fuente de la BDW y las capas EDW según sea apropiado. Las áreas de la etapa y del

mercado de datos no se conservan.

En un escenario típico, el área del escenario no se conserva (datos no se mantiene sino que sobrescribe). Los componentes
EDW se conservan, la capa BDW es comúnmente persistió sin embargo, no es necesario, y los Marts de datos no se
conservan. Este último punto representa una importante distinción entre almacenes (federados) de datos dimensionales y el
almacén de datos DV. almacenes de datos dimensionales se basan en el concepto de la persistencia de las dimensiones y
hechos asociados.
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

Las capas RAW y BAR representan una designación lógica. Si bien esta separación es a menudo también física, no se
requiere este factor. De hecho un enfoque común incluye una separación lógica con enlaces de la gestión de la alineación
dentro de la capa física.

12
Muestra Data Vault Modelo
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

13
La Fig. 15 Fu ll lt modelo de datos Vau
Tablas id hybr

El enfoque de depósito de datos ha definido un conjunto de tablas de híbridos que se pueden utilizar para hacer el despliegue global

más eficiente. Estos se aplican sobre una base caso por caso según sea apropiado para las circunstancias concretas.

los En la tabla punto de tiempo (PIT) es una tabla satélite modificada que rastrea los segmentos de tiempo válidas de los
satélites que rodean un Hub particular. Esta se rellena para que el proceso de asociar contexto de datos relativa /
descriptiva juntos para los informes.

los mesa de bridge es un establo Enlace modificado que aplana la relación entre concentradores incluyendo importantes datos

descriptivos de contexto / relacionados (potencialmente también las claves de negocio) en una sola tabla para facilitar el acceso y el

rendimiento.

En todos los casos, estas y otras construcciones pueden coexistir en el DV EDW no obstante, de que siempre se observan como
tablas “Sysgen” y utilizados sólo por razones de rendimiento. Los datos históricos y auditables relacionados que se utiliza para
cargar estas construcciones deben seguir siendo la única fuente de los datos EDW con el tiempo.

Aplicar el ing datos Vaul t

El modelado de datos Vault es excepcionalmente útil cuando el modelado de un almacén de datos. Un proyecto de Enterprise Data

Warehouse (EDW) está específicamente bien alineado con las características de modelado de depósito de datos. Un beneficio principal es la

capacidad de adaptarse fácilmente a los cambios en las dos fuentes originales y los requisitos de data mart aguas abajo. Esto nos proporciona

la capacidad de construir de forma incremental y ejecutar un programa de almacenamiento de datos verdaderamente ágil. El almacén de

datos bóveda de datos también se integra fácilmente datos e inherentemente logra proporcionando la historia de un verdadero almacén de

datos de la empresa.

El modelado de datos Vault también ha demostrado ser el patrón de modelado preferido para situaciones especiales de almacenamiento de

datos que incluye almacenamiento verdaderamente operativo de datos, integración de datos grandes, los modelos DW basadas modelo de

información, los meta-datos impulsadas implementaciones de almacenamiento de datos y modelos de almacenamiento de datos genéricos

incluso basadas en datos.

Los datos del almacén GUÍA DE MODELAJE | 5/15/2012


La comprensión de los beneficios del enfoque de modelado bóveda de datos comienza con la obtención de su certificación. Este
proceso se ve facilitado por Genesee Academia e incluye materiales, conferencias en línea, ejercicios, dos días en un aula con
conferencias, laboratorios y ejercicios de modelado grupo. En el último día hay un examen que da lugar a la designación
certificada modelador de datos bóveda de datos (CDVDM).

Por favor visita GeneseeAcademy.com para obtener más información sobre los horarios del curso y registro.

14
F inal Nota

El enfoque Data Vault está creciendo y la adaptación de año en año. cambios incrementales en el enfoque de modelado, las normas y las

mejores prácticas se pueden esperar con cierta frecuencia. Tenga en cuenta que esta guía se debe aplicar de manera concertada con las

actualizaciones actuales que se encuentran en línea en los foros de la bóveda de datos, LinkedIn y de los profesionales certificados.

La formación en línea que incluye actualizaciones y temas actuales también se encuentra disponible en línea en

DataVaultAcademy.com
Los datos del almacén GUÍA DE MODELAJE | 5/15/2012

15

También podría gustarte