AAI-1 DATAMART

INTEGRANTES:

BLANCA YASMIN CRUZ ARAQUE

SAID MORALES ABAUNZA

GABRIEL ANTONIO VEGA PIRAGAUTA

INSTRUCTOR:

Ing. FREDY ANTONIO ALARCON FONSECA

ESPECIALIZACIÓN TECNOLÓGICA

GESTION Y SEGURIDAD DE BASES DE DATOS (1501669)

Modalidad Presencial
Servicio Nacional de Aprendizaje SENA
2017
 DATA MART
(Mercado de Datos)

DEFINICIÓN

Un Data Mart es una base de datos departamental, especializada en el

almacenamiento de los datos de un área de negocio específica. Se caracteriza por
disponer la estructura óptima de datos para analizar la información al detalle desde
todas las perspectivas que afecten a los procesos de dicho departamento.

Los Data Marts son subconjuntos de datos con el propósito de ayudar a que un
área específica dentro del negocio pueda tomar mejores decisiones. Los datos
existentes en este contexto pueden ser agrupados, explorados y propagados de
múltiples formas para que diversos grupos de usuarios realicen la explotación de
los mismos de la forma más conveniente según sus necesidades.

Históricamente, los datos de una empresa suelen residir en bases que se diseñaron
principalmente para introducir y almacenar datos, mediante el llamado Proceso de
Transacciones Online (OLTP). Este método es idóneo para insertar, modificar o
borrar registros, pero no lo es tanto para responder a complejas consultas.

La relación entre los datos responde, cuando existe, a unas técnicas llamadas de
Entidad-Relación (modelo-Relacional).

Un Data Mart puede ser alimentado desde los datos de un datawarehouse, o

integrar por sí mismo un compendio de distintas fuentes de información.
Por tanto, para crear el Data Mart de un área funcional de la empresa es preciso
encontrar la estructura óptima para el análisis de su información, estructura que
puede estar montada sobre una base de datos OLTP, como el propio
datawarehouse, o sobre una base de datos OLAP. La designación de una u otra
dependerá de los datos, los requisitos y las características específicas de cada
departamento.

Tipos de Data Marts

Data mart OLAP

Se basan en los populares cubos OLAP, que se construyen agregando, según los
requisitos de cada área o departamento, las dimensiones y los indicadores
necesarios de cada cubo relacional.

Data mart OLTP

Pueden basarse en un simple extracto del data warehouse, no obstante, lo común

es introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser
las operaciones más usuales) aprovechando las características particulares de cada
área de la empresa.

Los Data Marts que están dotados con estas estructuras óptimas de análisis
presentan las siguientes ventajas:

 Fácil acceso a los datos que se necesitan frecuentemente.

 Poco Volumen de datos
 Crea vista colectiva para grupo de usuarios.
 Mejora el tiempo de respuesta del usuario final.
 Facilidad de creación.
 Costo inferior al de la aplicación de un completo almacén de datos.
 Los usuarios potenciales son más claramente identificables que en un almacén
de datos completo...
 Dar a los usuarios acceso a los datos que ellos necesitan para analizarlos más
a menudo.
 Pueden fácilmente extenderse a la toma de decisiones estratégicas, que pueden
brindar beneficios grandes y tangibles
 Permite entender y administrar simultáneamente macro y micro perspectivas del
área de comercio exterior, lo que puede ahorrar incontables horas de trabajo y
ayudar a evitar errores que pueden ser el resultado de suposiciones que se
hicieron con base en datos incompletos o incorrectos.
CLASIFICACION

Data mart dependiente

Los data mart dependientes son aquellos que reciben los datos desde una data
warehouse. En este tipo de Data mart la fuente de los datos es única.

Data mart independiente

Son aquellos que toman sus datos directamente desde los sistemas transaccionales
y no dependen de otros data warehouse. Este tipo de Datamart se alimenta
generalmente de las organizaciones.

Data mart híbrido

Los data mart híbridos permiten combinar las fuentes de datos de un data
warehouse corporativo con otras fuentes de datos tales como sistemas
transaccionales y/o operacionales.

Data warehouse y data mart

Los data warehouse surgen precisamente en respuesta a los problemas asociados

a realizar análisis de datos sobre bases de datos del tipo OLTP. La solución
propuesta por el data warehouse es extraer los datos de una (o más) bases
operacionales y moverlos a una base de datos independiente y orientada a las
consultas.
Pero el problema surge cuando los data warehouse crecen y se tornan más
complejos. Debido a esto el rendimiento de las consultas decae y el modelo
centralizado deja de ser óptimo. En estos casos, la solución es crear unos
almacenes de datos especializados por áreas como Ventas o Compras, que reciben
los datos desde el almacén centralizado (DW) y que pueden residir en diferentes
máquinas, bases de datos, redes, etc. Cada uno de estos almacenes se conoce
como Data mart.

Dado que un data mart soporta menos usuarios que un data warehouse se puede
optimizar para recuperar más rápidamente los datos que necesitan los usuarios.

Tomado: http://www.evaluandosoftware.com/abc-del-data-mart/

RAZONES PARA CREAR UN DATA MART

El siguiente listado de razones proporciona algunos argumentos para la creación de

Data Marts en un negocio.

 Dar a los usuarios acceso a los datos que ellos necesitan para analizarlos
más a menudo
 Proveer los datos en una forma que concuerda la vista colectiva de los datos
por un grupo de usuarios en un departamento o función de negocio
 Mejorar el tiempo de respuesta al usuario final debido a la reducción en el
volumen de información a ser accedido.
 Proveer datos apropiadamente estructurados para satisfacer los
requerimientos de las herramientas de acceso de usuario final.
 Un número de herramientas de acceso de usuario, particularmente
especialistas en minería de datos o herramientas de análisis
multidimensional pueden requerir sus propias estructuras internas de bases
de datos.
 En la práctica, estas herramientas a menudo crean su propio data mart
diseñado para soportar su funcionalidad específica.
 Los Data Marts normalmente usan menos datos de tal manera que la tarea
de carga de datos es más fácil, y de esta manera la implementación de un
data mart es más simple comparado con un datawarehouse corporativo.
 El costo de implementación de un data mart normalmente es menor que el
requerido para establecer un datawarehouse.
 Los potenciales usuarios de un data mart son más claramente definidos y
puede ser más fácilmente involucrados para obtener soporte para un
proyecto de Data Mart.
Aspectos del Data Mart

Algunos de aspectos de consideración dentro de la implementación de un Data

Mart:

 Funcionalidad del Data Mart

 Tamaño del Data Mart
 Rendimiento de Carga del Data Mart
 Acceso a usuarios en múltiples Data Mart
 Acceso al Data Mart desde Intranet / Internet
 Administración del Data Mart
 Instalación del Data Mart

Funcionalidad del Data Mart

 Las capacidades del data mart se ha incrementado con el crecimiento de su

popularidad. Más que ser simplemente base de datos pequeñas, fáciles a
acceder, algunos data marts deben ser ahora escalables a cientos de
gigabytes (GB).
 Proveen análisis sofisticado usando herramientas de minería de datos.
 Además cientos de usuarios deben ser capaces de acceder remotamente al
data mart.
 La complejidad y tamaño de algunos data marts son concordantes con las
características de data warehouses corporativos de pequeña escala.

Tamaño del Data Mart

 Los usuarios esperan tiempos de respuesta más rápidos desde data marts
que desde data warehouses, sin embargo, el deterioro del rendimiento de un
data mart crece con el tamaño.
 Varios vendedores de data marts están investigando maneras para reducir el
tamaño de data marts para ganar mejoras en el rendimiento; por ejemplo
soportar dimensiones y jerarquías dinámicas para reducir el tamaño de la
base de datos y tiempo de consolidación.
 Dimensiones dinámicas permiten agregaciones a ser calculadas sobre
demanda antes que pre calculados y almacenados en los cubos de bases de
datos multidimensionales (MDDB).
Rendimiento de carga del Data Mart

 Un data mart tiene que balancear dos componentes críticos: tiempo de

respuesta al usuario final y rendimiento de carga de datos.
 Un data mart designado para respuesta rápida a usuarios tendrá un gran
número de tablas resúmenes y valores agregados. Desgraciadamente, la
creación de tales tablas y valores incrementan grandemente el tiempo del
procedimiento de carga. MDDBs, soportan actualización incremental de la
base de datos de tal manera que la estructura completa del MDDB no tiene
que ser cambiada por cada actualización, lo cual es tradicionalmente
requerido; únicamente las celdas afectadas por el cambio son actualizadas.

Acceso de usuarios a datos en múltiples data marts

 Un enfoque es replicar los datos entre diferentes data marts o,

alternativamente, construir data marts virtuales.
 Data marts virtuales son vistas de varios data marts físicos o el data
warehouse corporativo ajustado para satisfacer los requerimientos de grupos
específicos de usuarios. Los vendedores están desarrollando productos para
gestionar data marts virtuales.

Acceso al Data Mart a través del Internet/Intranet

 Tecnología Internet/Intranet ofrece a los usuarios acceso de bajo costo a data

marts y data warehouses usando Web browsers tales como Mozilla e
Internet Explorer.
 Productos Data Mart para Internet/Intranet normalmente se sitúan entre un
Web server y el producto de análisis de datos.

Administración del Data Mart

 A medida que el número de data marts en una organización se incrementa,

se tiene la necesidad de gestionar y coordinar centralmente las actividades
del data mart. Una vez que los datos son copiados al data mart, los datos
pueden llegar a ser inconsistentes a medida que los usuarios alteran sus
propios data marts para permitirles analizar los datos en diferentes maneras.
 Las organizaciones no pueden ejecutar fácilmente la administración de
múltiples data marts, dando surgimiento a aspectos tales como nuevas
versiones de data marts, consistencia e integridad de datos y meta datos,
seguridad de empresas amplias, y afinamiento de rendimiento.
 Existen herramientas administrativas de data marts en el mercado.
Instalación del Data Mart

 Data marts están llegando a ser incrementalmente complejos de construir.

 Actualmente los vendedores están ofreciendo productos referidos como
“data marts en una caja” que proveen una fuente de herramientas data mart
de bajo costo.

Arquitectura de una aplicación de Data Mart

Desde el punto de vista de arquitectura tecnológica, la arquitectura de una

aplicación de Data Mart es la misma que si se desarrollara todo un Dawarehouse.

Es conveniente que una aplicación de data warehouse o data mart sea desarrollada
considerando que va a ser explotada en una arquitectura de tres capas
(aplicaciones distribuidas); las cuales son:

 Capa de presentación (los componentes de interface de usuario y de

despliegue)
 Capa lógica analítica (las consultas, procesos, y funciones de formateo)
 Capa de datos (data warehouse)

Construcción en Incrementos, Data Marts.

Construcción Incremental:

La implementación en incrementos warehouse desarrolla y genera un subconjunto

del DW total. La implementación incremental es una aproximación pragmática para
construir un warehouse a un nivel empresarial en forma evolutiva.

Resultados de Implementación:

Los resultados más significativos de la implementación de un incremento DW,

incluyen:

 Las bases de datos warehouse.

 Programas y procedimientos para extraer, transformar y cargar datos.
 Instalar herramientas de acceso a los datos.
 Poblar el DW con los datos necesarios.
 Poblar el catálogo de metadatos con los datos necesarios.
 Técnicas de uso y soporte el almacén
Consideraciones de Implementación mediante Data Marts.

Debe tomar en cuenta lo siguiente;

 La arquitectura Datawarehouse se debe desarrollar al principio del proyecto.

 El primer incremento se desarrolla basándose en la arquitectura.
 La construcción del primer incremento puede causar cambios en la
arquitectura.
 La operación del DW puede implicar la realización de cambios en la
arquitectura.
 Cada incremento adicional puede extender el datawarehouse.
 Cada nuevo incremento puede causar ajustes en la arquitectura.
 La operación continua puede causar ajustes en la arquitectura.

Tomado:https://www.adictosaltrabajo.com/tutoriales/datawarehouse4/#2.10.2.Razones%20para%20crear%20
un%20Data%20Mart%7Coutline

EJEMPLO

Ilustraremos los conceptos que aprendimos en esta unidad con nuestro ejemplo de La
Distribuidora Latinoamericana de Alimentos (DLA).
Construiremos el modelo del data mart de ventas en tres etapas:

Etapa 1 Construcción de las Dimensiones

Etapa 2 Armado de la Tabla de Hechos
Etapa 3 Definición de las Medidas
Construcción de las Dimensiones
Como primer paso definiremos las dimensiones porque estas nos darán las aperturas del cubo.
En base a definiciones surgidas de los reuniones de trabajo con los representantes de DLA, vimos
que necesitan analizar sus datos según el siguiente cuadro:

Hecho a medir: Venta de Productos

Dimensiones

Medidas Tiempo Sucursal Vendedor Cliente Producto

Ventas_Importe X X X X X

Ventas_Costo X X X X X
 Ventas_Unidades X X X X X

Ventas_ImporteTotal X X X X X

Ventas_Ganancia X X X X X

Ventas_Promedio X X X X X

Si trabajamos en forma correcta, debería haber una exacta coincidencia entre la definición de las
dimensiones y los datos que estamos extrayendo de las fuentes transaccionales. Si esa
coincidencia no ocurre, en alguna de las dos etapas tenemos un error, o bien los datos de origen
no están correctos o bien definimos mal las dimensiones.
Comenzaremos por la Dimensión Tiempo ya que, como aprendimos en esta unidad, es la más
importante dentro de cualquier data mart.
Nuestro cliente necesita analizar sus datos diariamente, entonces definiremos los niveles:
 Año
 Semestre
 Trimestre
 Mes
 Día

La tabla de dimensión quedara formada:

Dimensión Tiempo

* Año

** Semestre

*** Trimestre

**** Mes
Dimensión Sucursal, usaremos un esquema estrella y su estructura jerárquica será:

Dimensión Sucursal

* Sucursal

** Tipo Sucursal

*** País

**** Provincia
Dimensión Vendedor, al igual que sucursal, tendrá un esquema estrella y quedará definida por los
niveles:
 Dimensión Vendedor

* Sucursal

** Sección

*** Vendedor

Dimensión Cliente tendrá todos los atributos de un cliente.

Dimensión Cliente

* País

** Provincia

*** Ciudad

Dimensión Producto, esta dimensión la construiremos según un esquema copo de nieve. En estos
casos se mantiene la normalización propia de los sistemas OLTP. Cada tabla contiene los datos
iniciales y su relación con el resto.
La dimensión nos quedará normalizada por lo que usaremos más tablas para construirla.
Nuestro cliente puede clasificar sus productos según la categoría, el departamento y la familia de
producto a la que pertenece.

Armado de la Tabla de Hechos

Ahora que tenemos definidas las dimensiones y sus niveles, conformaremos la tabla de Hechos.
La tabla de hechos debe tener las columnas claves de las tablas de las dimensiones y las
columnas de las medidas.
Primero colocaremos las columnas claves de la tabla cada una de las tablas de dimensiones.

Fact_Ventas

ID_Fecha

ID_Producto

ID_Cliente

ID_Vendedor

Definición de las Medidas

Recordemos que las medidas son los valores numéricos que el usuario desea analizar.
Vimos que nuestro cliente necesita medir:
 El coste inducido en cada unidad vendida
 El valor de venta de cada producto.
 La ganancia obtenida en la venta de cada producto.

Agregaremos a nuestra tabla de hechos ventas estas medidas:

Fact_Ventas

ID_Fecha

ID_Producto

ID_Cliente

ID_Vendedor

Ventas_Importe

La medida “ganancia obtenida en la venta de cada producto” no la agregamos a la tabla porque

esta medida puede ser calculada a partir de las medidas naturales ventas importe y ventas costo.
Nuestro modelo contará también con las medidas calculadas:
 Ventas_Ganacia que tendrá la formula Ventas_Importe menos Ventas_Costo
 Ventas_Promedio que será el resultado de la suma de Ventas_Unidades dividido
cantidad de días, comprobando la condición del numerador diferente de cero.

Realizadas estas tres etapas, podemos ver el diseño completo de nuestro data mart.
Lecciones Aprendidas
 Un Data Mart adopta un esquema estrella para maximizar la
performance de las consultas.
 Las dimensiones son categorías descriptivas por las cuales
las medidas se pueden separar para el análisis.
 La dimensión Tiempo está implícita en todo Data Mart
 Las medidas son los datos numéricos de interés primario
para el cliente
 Con las medidas calculadas se pueden construir alertas

Tomado de: https://bigroup.wikispaces.com/file/view/Academia+BI+Unidad+3.doc

 GLOSARIO

o Data Mart: Almacén de datos limitados compuesta por una área de la

organización.
o Data mining de pronóstico. Es un data mining que produce un modelo para
ser usado con nuevos datos para pronosticar un valor o predecir un probable
resultado basado en patrones en la data histórica.
o Data WareHouse: Repositorio central de datos que almacena toda
información de interés de las áreas la organización.
o DSS: Sistema de Soporte de Decisiones. Sistema de aplicaciones
automatizadas que asiste a la organización en la toma de decisiones
mediante un análisis estratégico de la información histórica.
o Sistemas transaccionales OLTP: Es un sistema o proceso que facilita la
administración de información para aplicaciones de tipo transaccionales en
donde las necesidades del usuario son resueltas inmediatamente
convirtiendo en un apoyo importante para la toma de decisiones.
o OLAP (OnLine Anlytical Processing): Es una solución o método utilizado
para el procesamiento de grandes volúmenes de información actualmente
manejada en el campo de la llamada inteligencia de negocios. OLAP tiene
como objetivo principal agilizar el procesamiento de información mediante
cubos que contienen resúmenes de información o sistemas transaccionales
OLTP.
o Dashboard: Interface gratica de comunicación basado en una o varias vistas
de información necesarias para alcanzar las estrategias de negocio.
o Esquema estrella: Es la arquitectura de almacén de datos más simple. En
este diseño del almacén de datos la tabla de Variables (Hechos) está
rodeada por Dimensiones y juntos forman una estructura que permite
implementar mecanismos básicos para poder utilizarla con una herramienta
de consultas OLAP.
o Esquema 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.