Tópicos Especiales en Ingeniería de Sistemas

CASO DE ESTUDIO

Caso 1: Pedidos en la Florería “Todo Flores S.A.”

1. Organización en estudio

Se trata de la empresa “Todo Flores S.A.”.

Su negocio es vender arreglos florales en sus puntos de ventas y por delivery.

Los arreglos pueden ser simples o con accesorios.

2. Proceso de Negocios

El Proceso de Negocios escogido es: Gestión de Pedidos. Se inicia cuando un

cliente realiza un pedido de un Arreglo Floral; y culmina cuando se registra en
el sistema la fecha y hora de la entrega del arreglo al cliente.

3. Modelo de Datos Transaccional

-1-
 Ms Ing Arturo Diaz Pulido.

Tabla Descripción
Acá se registran todos los Pedidos de la Florería
Fecha_hora_recepcion: fecha y hora en que se toma el
pedido
Fecha _recepcion: fecha en que se toma el pedido. La hora
se establece igual para todos con la finalidad de escoger
sólo dias diferentes, y no días-horas diferentes
Fecha_hora_confirmacion: fecha y hora en que el
PEDIDOS distribuidor nos toma el pedido
Fecha_hora_despacho: fecha y hora en que el distribuidor
envia el pedido al cliente
Fecha_hora_entrega: fecha y hora en que el distribuidor
entrega el pedido al cliente
Fecha_hora_satisfaccion: fecha y hora en que el distribuidor
registra la entrega en el sistema
Des_estado: estado del Pedido
Acá se registran los datos personales de Clientes, entre ellos
Tipo_persona N: Natural J: Jurídica
CLIENTES
Cod_cliente_vip N: no S: si
Sexo_Cliente H: Hombre M: Mujer E: Empresa
Registra la satisfacción del cliente al recibir el ramo de flores
SATISFACCIÓN
Tipo_satisfaccion S: Satisfecho I: Insatisfecho
Registra el historial del cambio de estado de Pedidos
Des_estado_orig C: Confirmado E: Entregado N:
Anulado R: Recepcionado
GESTION
Des_estado_cambio C: Confirmado E: Entregado N:
Anulado R: Recepcionado S: Satisfaccion
Fecha_hora_cambio fecha y hora del cambio

-2-
 Tópicos Especiales en Ingeniería de Sistemas

Registra detalles de los Arreglos de Flores, entre ellos

Cod_tipo_arreglo 1: sin extras 2: con accesorios
Cod_clase_arreglo va de la mano con Cod_tipo_arreglo
ARREGLOS Cod_arreglo va de la mano con Cod_tipo_arreglo y con
Cod_clase_arreglo
Imp_costo precio de costo del arreglo
Imp_arreglo precio de venta del arreglo
Registra las Clases (tipos) de Arreglos
CLASE_DE_AR
Cod_tipo_arreglo 1: sin extras 2: con accesorios
REGLO
Cod_clase_arreglo va de la mano con Cod_tipo_arreglo
TIPO_DE_ARR Registra los Tipos de Arreglos
EGLO Cod_tipo_arreglo 1: sin extras 2: con accesorios

-3-
 Ms Ing Arturo Diaz Pulido.

4. Creación del Modelo de la BD Transaccional con SQL Server 2014

1. Cargar SQL Server Management Studio .

2. Elegir Motor de Base de Datos y Conectar.
3. Clic derecho en Databases y crear una nueva BD.
4. Exportar desde ERWIN o
5. Clic derecho en la BD creada y New Query (Nueva Consulta).
6. Crear Tablas Transaccionales: Copiar o Abrir el archivo Query de SQL

(Transaccional.sql ) y luego Execute.

7. Crear Database Diagrams:
8. Clic derecho en Database Diagrams/ New Database Diagrams
9. Marcar las tablas indicadas y luego Add.
10. Al cerrar la Query correspondiente poner nombre al diagrama.
Cómo determinar la Versión de SQL
Método 1: Conectar con la instancia de SQL Server y ejecutar: Select
@@version

Esta consulta producirá un resultado similar al siguiente:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)

Oct 19 2012 13:38:57

Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on

Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Método 2: Conectar con la instancia de SQL Server y ejecutar:

SELECT SERVERPROPERTY('productversion'),

SERVERPROPERTY ('productlevel'), SERVERPROPERTY

('edition')

Archivo : Transaccional.sql

-4-
 Tópicos Especiales en Ingeniería de Sistemas

/* Table: ARREGLOS */
/*========================================================*/
create table ARREGLOS (
COD_TIPO_ARREGLO numeric(7) not null,
COD_CLASE_ARREGLO numeric(7) not null,
COD_ARREGLO numeric(7) not null,
DES_ARREGLO char(100) null,
IMP_ARREGLO numeric(9,2) null,
IMP_COSTO numeric(9,2) null,
constraint PK_ARREGLOS primary key (COD_TIPO_ARREGLO,
COD_CLASE_ARREGLO, COD_ARREGLO)
)
go

/*========================================================*/
/* Table: CLASE_DE_ARREGLO */
/*========================================================*/
create table CLASE_DE_ARREGLO (
COD_TIPO_ARREGLO numeric(7) not null,
COD_CLASE_ARREGLO numeric(7) not null,
DES_CLASE_ARREGLO char(100) null,
constraint PK_CLASE_DE_ARREGLO primary key
(COD_TIPO_ARREGLO, COD_CLASE_ARREGLO)
)
go

-5-
/*========================================================*/

/* Table: CLIENTES */
/*========================================================*/
create table CLIENTES (
COD_CLIENTE numeric(7) not null,
NOM_CLIENTE char(100) null,
TIPO_PERSONA char(1) null,
COD_CLIENTE_VIP char(1) null, SEXO_CLIENTE
char(1) null,
constraint PK_CLIENTES primary key (COD_CLIENTE)
)
go

/*========================================================*/
/* Table: GESTION */
/*========================================================*/
create table GESTION (
COD_PEDIDO numeric(7) not null,
DES_ESTADO_ORIG char(1) not null,
DES_ESTADO_CAMBIO char(1) null,
FECHA_HORA_CAMBIO datetime null,
constraint PK_GESTION primary key (COD_PEDIDO,
DES_ESTADO_ORIG)
)
go
/* Table: PEDIDOS */
/*========================================================*/
create table PEDIDOS (
COD_PEDIDO numeric(7) not null,
COD_CLIENTE numeric(7) null,
TIPO_SATISFACCION char(1) null,
COD_SATISFACCION numeric(7) null,
COD_TIPO_ARREGLO numeric(7) null,
COD_CLASE_ARREGLO numeric(7) null,
COD_ARREGLO numeric(7) null,
DES_DIRIGIDO_A char(100) null,
DES_NOTA char(100) null,
FECHA_HORA_RECEPCION datetime null,
FECHA _RECEPCION date null,
FECHA_HORA_CONFIRMACION datetime null,
FECHA_HORA_DESPACHO datetime null,

-6-
/*========================================================*/

FECHA_HORA_ENTREGA datetime null,

FECHA_HORA_SATISFACCION datetime null,
DES_ESTADO char(1) null,
DES_DIRECCION char(100) null,
UNID_VENDIDAS numeric(7) null, constraint
PK_PEDIDOS primary key (COD_PEDIDO)
)
go

/*========================================================*/
/* Table: SATISFACCION */
/*========================================================*/
create table SATISFACCION (
TIPO_SATISFACCION char(1) not null,
COD_SATISFACCION numeric(7) not null,
DES_SATISFACCION char(100) null, constraint
PK_SATISFACCION primary key (TIPO_SATISFACCION,
COD_SATISFACCION)
)
go
/* Table: TIPO_DE_ARREGLO */
/*========================================================*/
create table TIPO_DE_ARREGLO (
COD_TIPO_ARREGLO numeric(7) not null,
DES_TIPO_ARREGLO char(100) null, constraint
PK_TIPO_DE_ARREGLO primary key (COD_TIPO_ARREGLO)
)
go

alter table ARREGLOS

add constraint FK_ARREGLOS_REFERENCE_CLASE_DE foreign key
(COD_TIPO_ARREGLO, COD_CLASE_ARREGLO) references
CLASE_DE_ARREGLO (COD_TIPO_ARREGLO,
COD_CLASE_ARREGLO)
go

alter table CLASE_DE_ARREGLO

add constraint FK_CLASE_DE_REFERENCE_TIPO_DE_ foreign key

-7-
/*========================================================*/

(COD_TIPO_ARREGLO) references TIPO_DE_ARREGLO

(COD_TIPO_ARREGLO)
go

alter table GESTION

add constraint FK_GESTION_REFERENCE_PEDIDOS foreign key
(COD_PEDIDO) references PEDIDOS
(COD_PEDIDO)
go

alter table PEDIDOS

add constraint FK_PEDIDOS_REFERENCE_CLIENTES foreign key
(COD_CLIENTE) references CLIENTES
(COD_CLIENTE)
go

alter table PEDIDOS

add constraint FK_PEDIDOS_REFERENCE_SATISFAC foreign key
(TIPO_SATISFACCION, COD_SATISFACCION) references
SATISFACCION (TIPO_SATISFACCION,
COD_SATISFACCION)
go

-8-
alter table PEDIDOS
add constraint FK_PEDIDOS_REFERENCE_ARREGLOS foreign key
(COD_TIPO_ARREGLO, COD_CLASE_ARREGLO, COD_ARREGLO)
references ARREGLOS (COD_TIPO_ARREGLO,
COD_CLASE_ARREGLO, COD_ARREGLO) go

El Diagrama resultante en es SQL Server es:

-9-
5. Data Transaccional

Están en Archivos Excel y Planos (txt).

TIPO_DE_ARREGLO 2 registros
COD_TIPO DES_TIPO
1 Sin extras
2 Con accesorios

CLASE_DE_ARREGLO 7 registros
TIPO COD_CLASE DES_Clase
1 1 Sencillo
1 2 Doble
1 3 Triple
1 4 Otros
2 1 Globos
2 2 Peluches
2 3 Regalos

ARREGLO 118 registros

TIPO CLASE COD DES IMP_ARRE COSTO
1 1 1 Rosas estilo campestre 25 20
1 1 2 Claveles estilo campestre 18 14.4
1 1 3 Girasoles estilo campestre 14 11.2
1 1 16 Otros estilo italiano 11 8.8
1 2 1 Rosas estilo campestre 45 36
1 2 2 Claveles estilo campestre 32 25.6
1 2 3 Girasoles estilo campestre 25 20
1 3 15 Girasoles estilo italiano 39 31.2
1 3 16 Otros estilo italiano 29 23.2
1 4 1 Rosas estilo campestre 25 20
1 4 2 Claveles estilo campestre 18 14.4
1 4 15 Girasoles estilo italiano 15 12

-10-
 1 4 16 Otros estilo italiano 11 8.8
2 1 18 Girasoles Jardin c/ globo chico 15 12
2 2 1 Rosas campestre c/ peluche grande 32 25.6
Rosas campestre c/ peluche
2 2 2 mediano 30 24
… … … … … …

CLIENTES 250 (150+100) registros

COD NOM TIPO VIP SEXO
4004119 KRAFT MYRTLE N N M
2379106 GOWEN AGATHA N N M
2765577 WASHINGTON TAVISH N N H
4654823 LIFE REBECCA N N M
1785412 MALONE JESSIE N N M
2623490 HESKETT TITUS N N H
1937503 FIGGENS LAWRENCE N N H
4115526 LOVETT ZENIA N N M
2269204 HILL REYBURN N N H
1336725 MANUEL WILL N S H
6497113 LANDAIR SERVICES INC J S E
… … … … …

SATISFACCIÓN 8 registros
TIPO COD DES
S 1 Satisfaccion
I 1 Entrega retrasada
I 2 Flores marchitas, secas
I 3 Flores inadecuadas para la ocasión
I 4 Presentacion inadecuada
I 5 Disconformidad con lo solicitado
I 6 Accesorios incompletos
I 7 Otros

-11-
GESTION 19562 registros

PED ESTADO_ORIG ESTADO_CAMBIO FECHA

100220 R N 07/09/2002
100220 N C 08/09/2002
100220 C E 09/09/2002
101060 R N 29/09/2002
101060 N C 30/09/2002
101060 C E 01/10/2002
101060 E S 02/10/2002
101100 R N 29/09/2002
101100 N C 01/10/2002
101100 C E 02/10/2002
101100 E S 03/10/2002
101110 R N 30/09/2002
101110 N C 01/10/2002
101120 R N 30/09/2002
… … … …

-12-
6. Cargar Data a las BD Transaccionales desde OLTP (EXCEL, Acces) con SQL Server
2014

1. Cargar SQL Server 2014 Management Studio .

2. Acceder a Data Bases.

3. Clic derecho en la BD <Pedidos> / Task / Import Data….

4. Escoger el Tipo y el Nombre del Archivo (XLS). 1º las Tablas padre y

luego las Tablas hijas.

5. Cargar todas las Tablas.

6. Elegir destino de la data: SQL Native Client o Microsoft OLE Provider.

Notas: Los pasos 4 y 6 se pueder realizar utilizando Tareas de Integration

Services.
Los archivos planos deben estar en formato Unicode, sus columnas
separadas por tabulaciones y sin nombre de cabecera. Deshabilitar
Nombres de columna de la primera fila de datos.

Crear Database Diagrams

1. Clic derecho en Database Diagrams/ New Database Diagrams.

2. Marcar las tablas indicadas y luego Add.

3. Al cerrar la Query correspondiente poner nombre al diagrama.

Revisar DATA WAREHUSE y DATA MART

-14-
Toda la data estratégica se ha de poder integrar gracias a procesos ETL:

extracción (Extract) de fuentes heterogéneas, transformación (Transform) en un

modelo único de representación del negocio y carga (Load) en el Data

Warehouse.

El primer paso para implantar soluciones de análisis de negocio es

garantizar la calidad de la información. Sólo con información consolidada,

normalizada, no duplicada y consistente podremos medir, controlar y gestionar

adecuadamente el negocio. Por esta razón, el proceso de depuración de los

datos pasa por la utilización de una herramienta de Extracción, Transformación

y Carga de datos (ETL), que nos permitirá estructurar los datos de forma

sencilla, pensando en el rendimiento, rapidez y facilidad de uso.

-15-
DEFINICIÓN

ETL son las siglas en inglés de Extraer, Transformar y Cargar (Extract,

Transform and Load). Es el proceso que permite a las organizaciones mover

datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en

otra base de datos, data mart, o data warehouse para analizar, o en otro

sistema operacional para apoyar un proceso de negocios.

El ETL es un lenguaje para el entendimiento y sincronización de datos entre

diferentes plataformas tecnológicas, el cual respeta los esquemas de

seguridad de la fuente e interpreta las reglas de acceso necesarias.

Proceso para transferir, formatear, limpiar y cargar datos desde

aplicaciones de producción (ERP, CRM, BDR, archivos) a los sistemas de

BI (Data Marts, BDD, OLAP).

EXTRAER

La primera parte del proceso ETL, basándose en las necesidades y requisitos

del usuario, consiste en extraer los datos desde los sistemas de origen. La

-16-
mayoría de los proyectos de

almacenamiento de datos fusionan

datos provenientes de diferentes

sistemas de origen. Los formatos de las

fuentes normalmente se encuentran en

bases de datos relacionales o ficheros planos, pero pueden incluir bases de

datos no relacionales u otras estructuras diferentes. La extracción convierte los

datos a un formato preparado para iniciar el proceso de transformación.

Una parte intrínseca de este proceso es la de analizar los datos extraídos,

de lo que resulta un chequeo que verifica si los datos cumplen la estructura que

se esperaba. De no ser así los datos son rechazados.

Un requerimiento importante que se debe exigir a la tarea de extracción es

que ésta cause un impacto mínimo en el sistema origen. Si los datos a extraer

son muchos, el sistema de origen se podría ralentizar e incluso colapsar,

provocando que éste no pueda utilizarse con normalidad para su uso cotidiano.

Por esta razón, en sistemas grandes las operaciones de extracción suelen

programarse en horarios o días donde este impacto sea nulo o mínimo.

Si los datos operacionales residen en un SGBD Relacional, el proceso de

extracción se puede reducir a, por ejemplo, consultas en SQL o rutinas

programadas. En cambio, si se encuentran en un sistema no convencional o

fuentes externas, ya sean textuales, hipertextuales, hojas de cálculo, etc., la

obtención de los mismos puede ser un tanto más dificultoso, debido a que, por

-17-
ejemplo, se tendrán que realizar cambios de formato y/o volcado de

información a partir de alguna herramienta específica.

Una vez que los datos son seleccionados y extraídos, se guardan en un

almacenamiento intermedio, lo tiene las siguientes ventajas:

Manipular los datos sin interrumpir ni paralizar los OLTP, ni tampoco el DW.

Almacenar y gestionar los metadatos que se generarán en los procesos

ETL.

Facilitar la integración de las diversas fuentes, internas y externas.

El almacenamiento intermedio constituye en la mayoría de los casos una

base de datos en donde la información puede ser almacenada por ejemplo en

tablas auxiliares, tablas temporales, etc. Los datos de estas tablas serán los

que finalmente (luego de su correspondiente transformación) poblarán el DW.

TRANSFORMAR

Convierte datos inconsistentes en datos compatibles y congruentes, para ser

cargados en el DW. Estas acciones se llevan a cabo, debido a que pueden

existir diferentes fuentes de datos, y es vital conciliar un formato único,

definiendo estándares, para que todos los datos que ingresarán al DW estén

integrados.

Los casos más comunes en los que se deberá realizar integración son:

Codificación.

-18-
 Medida de atributos.

Convenciones de nombramiento.

Fuentes múltiples.

La fase de transformación aplica una serie de reglas de negocio o

funciones sobre los datos extraídos para convertirlos en datos que serán

cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación

de los datos. No obstante en otros casos pueden ser necesarias aplicar algunas

de las siguientes transformaciones:

Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las

columnas con valores nulos no se carguen).

-19-
Traducir códigos (por ejemplo, si la fuente almacena una "H" para Hombre

y "M" para Mujer pero el destino tiene que guardar "1" para Hombre y "2"

para Mujer).

Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en

"1").

Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad *

precio).

Unir datos de múltiples fuentes (por ejemplo, búsquedas, combinaciones,

etc.).
Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de

cada región).

Generación de campos clave en el destino.

Transponer o pivotar (girando múltiples columnas en filas o viceversa).

Dividir una columna en varias (por ejemplo, columna "Nombre: García,

Miguel"; pasar a dos columnas "Nombre: Miguel" y "Apellido: García"). La

aplicación de cualquier forma, simple o compleja, de validación de datos, y

la consiguiente aplicación de la acción que en cada caso se requiera:

Datos OK: Entregar datos a la siguiente etapa (Carga).

Datos erróneos: Ejecutar políticas de tratamiento de excepciones (por

ejemplo, rechazar el registro completo, dar al campo erróneo un valor

nulo o un valor centinela).

-20-
Limpieza de Datos (Data Cleaning)

Su objetivo principal es el de realizar distintos tipos de acciones contra el mayor

número de datos erróneos, inconsistentes e irrelevantes.

Las acciones más típicas que se pueden llevar a cabo al encontrarse con

Datos Anómalos (Outliers) son: o

Ignorarlos.

o Eliminar la columna. o Filtrar la columna.

o Filtrar la fila errónea, ya que a veces su origen, se debe a casos

especiales.

o Reemplazar el valor.

-21-
 o Discretizar los valores de las columnas. Por ejemplo de 1 a 2, poner

“bajo”; de 3 a 7, “óptimo”; de 8 a 10, “alto”. Para que los outliers caigan

en “bajo” o en “alto” sin mayores problemas.

Las acciones que suelen efectuarse contra Datos Faltantes (Missing

Values) son:

o Ignorarlos. o Eliminar la columna. o Filtrar la columna.

o Filtrar la fila errónea, ya que a veces su origen, se debe a casos

especiales.

o Reemplazar el valor. o Esperar hasta que los datos faltantes estén

disponibles.

Un punto muy importante que se debe tener en cuenta al elegir alguna

acción, es el de identificar el por qué de la anomalía, para luego actuar en

consecuencia, con el fin de evitar que se repitan, agregándole de esta manera

más valor a los datos de la organización. Se puede dar que en algunos casos,

los valores faltantes sean inexistentes, ya que por ejemplo, un nuevo asociado

o cliente, no poseerá consumo medio del último año.

CARGAR

La fase de carga es el momento en el cual los datos de la fase anterior

(transformación) son cargados en el DW destino con:

Aquellos datos que han sido transformados y que residen en el

almacenamiento intermedio.

-22-
 Aquellos datos de los OLTP que tienen correspondencia directa con el

depósito de datos.

Dependiendo de los requerimientos de la organización, este proceso

puede abarcar una amplia variedad de acciones diferentes. Los data

warehouse mantienen un historial de los registros de manera que se pueda

hacer una auditoría de los mismos y disponer de un rastro de toda la historia

de un valor a lo largo del tiempo.

Existen dos formas básicas de desarrollar el proceso de carga:

Acumulación simple: Es la más sencilla y común, y consiste en realizar un

resumen de todas las transacciones comprendidas en el período de tiempo

seleccionado y transportar el resultado como una única transacción hacia el

data warehouse, almacenando un valor calculado que consistirá típicamente

en un sumatorio o un promedio de la magnitud considerada.

-23-
 Rolling: Se aplica en los casos en que se opta por mantener varios niveles

de granularidad. Para ello se almacena información resumida a distintos

niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o

diferentes niveles jerárquicos en alguna o varias de las dimensiones de la

magnitud almacenada (por ejemplo, totales diarios, totales semanales,

totales mensuales, etc.).

La fase de carga interactúa directamente con la base de datos de destino

(DW). Al realizar esta operación se aplicarán todas las restricciones y triggers

(disparadores) que se hayan definido en ésta (por ejemplo, valores únicos,

integridad referencial, campos obligatorios, rangos de valores). Estas

restricciones y triggers (si están bien definidos) contribuyen a que se garantice

la calidad de los datos en el proceso ETL, y deben ser tenidos en cuenta.

EL PROCESO ETL

A continuación, se explicará en síntesis el accionar del proceso ETL. En la

siguiente figura se puede apreciar mejor lo antes descrito:

-24-
Figura 15. Proceso ETL.

Los pasos que se siguen son:

1. Conectarse a la base origen de los datos.

2. Se extraen los datos relevantes desde los OLTP y se depositan en un

almacenamiento intermedio.

3. Se integran y transforman los datos, para evitar inconsistencias.

4. Se cargan los datos desde el almacenamiento intermedio hasta el DW. Si

existiesen correspondencias directas entre datos de los OLTP y el DW, se

procede también a su respectiva carga.

La forma más común de realizar la extracción de los datos es a través de

Queries definidas en SQL; el trabajo se facilita cuando se puede automatizar el

proceso de construcción de las queries correspondientes.

El trabajo de transformación se realiza haciendo uso de numerosas

funciones de conversión de datos. Las funciones más comunes que se realizan

en esta etapa son: integración, depuración, validación referencial, valores

derivados, de-normalización y re-normalización, agregación, auditoria de

seguimiento y conversiones de nulidad.

En la etapa de carga se procede a “mover” los datos transformados al Data

Warehouse e incluye los parámetros de actualización automáticas que se dejan

programados con el timer incorporado.

-25-
Ver demo en http://www.sixtina.com.ar/0videos/sixtinaetl/etl/sixtina_etl.html

PROCESAMIENTO PARALELO

Un desarrollo reciente en el software ETL es la aplicación de procesamiento

paralelo. Esto ha permitido desarrollar una serie de métodos para mejorar el

rendimiento general de los procesos ETL cuando se trata de grandes

volúmenes de datos. Hay 3 tipos principales de paralelismos que se pueden

implementar en las aplicaciones ETL:

De datos: Consiste en dividir un único archivo secuencial en pequeños

archivos de datos para proporcionar acceso paralelo.

De segmentación (pipeline): Permite el funcionamiento simultáneo de varios

componentes en el mismo flujo de datos. Un ejemplo de ello sería buscar un

valor en el registro número 1 a la vez que se suman dos campos en el

registro número 2.

De componente: Consiste en el funcionamiento simultáneo de múltiples

procesos en diferentes flujos de datos en el mismo puesto de trabajo.

Estos tres tipos de paralelismo no son excluyentes, sino que pueden ser

combinados para realizar una misma operación ETL.

Una dificultad frecuente es asegurar que los datos que se cargan sean

relativamente consistentes. Las múltiples bases de datos de origen tienen

diferentes ciclos de actualización (algunas pueden ser actualizadas cada pocos

minutos, mientras que otras pueden tardar días o semanas). En un sistema de

-26-
ETL será necesario que se puedan detener ciertos datos hasta que todas las

fuentes estén sincronizadas. Del mismo modo, cuando un almacén de datos

tiene que ser actualizado con los contenidos en un sistema de origen, es

necesario establecer puntos de sincronización y de actualización.

DEFINICIÓN

Un almacén de datos (del inglés datawarehouse) es una colección de datos

orientada a un determinado ámbito (empresa, organización, etc.), integrado,

no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la

-27-
entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo

de una organización, más allá de la información transaccional y operacional,

almacenado en una base de datos diseñada para favorecer el análisis y la

divulgación eficiente de datos (especialmente OLAP, procesamiento

analítico en línea). Los almacenes de datos contienen a menudo grandes

cantidades de información que se subdividen a veces en unidades lógicas

más pequeñas dependiendo del subsistema de la organización del que

procedan o para el que sean necesario.

Un Datawarehouse es una base de datos corporativa que se caracteriza por

integrar y depurar información de una o más fuentes distintas, para luego

procesarla permitiendo su análisis desde infinidad de perspectivas y con

grandes velocidades de respuesta. La creación de un datawarehouse

representa en la mayoría de las ocasiones el primer paso, desde el punto

de vista técnico, para implantar una solución completa y fiable de Business

Intelligence.
Definición de Bill Inmon Bill Inmon fue uno de los primeros autores en

escribir sobre el tema de los almacenes de datos, define un data warehouse

(almacén de datos) en términos de las

características del repositorio de datos:

Orientado a temas.- Los datos en la base de datos

están organizados de manera que todos los

elementos de datos relativos al mismo evento u

objeto del mundo real queden unidos entre sí.

-28-
Variante en el tiempo.- Los cambios producidos en los datos a lo largo del

tiempo quedan registrados para que los informes que se puedan generar

reflejen esas variaciones.

No volátil.- La información no se modifica ni se elimina, una vez almacenado

un dato, éste se convierte en información de sólo lectura, y se mantiene

para futuras consultas.

Integrado.- La base de datos contiene los datos de todos los sistemas

operacionales de la organización, y dichos datos deben ser consistentes.

Inmon defiende una metodología descendente (top-down) a la hora

de diseñar un almacén de datos, ya que de esta forma se considerarán

mejor todos los datos corporativos. En esta metodología los Data marts se

crearán después de haber terminado el data warehouse completo de la

organización.

http://www.inmoncif.com/home/
Definición de Ralph Kimball Una copia de las transacciones de datos

específicamente estructurada para la consulta y el análisis.

También fue Kimball quien determinó que un data

warehouse no era más que: "la unión de todos los Data

Marts de una organización". Defiende por lo tanto una

metodología ascendente (bottom-up) a la hora de diseñar

un almacén de datos.

-29-
 La ventaja principal de este tipo de bases de datos radica en las

estructuras en las que se almacena la información (modelos de tablas en

estrella, en copo de nieve, cubos relacionales... etc). Este tipo de persistencia

de la información es homogénea y fiable, y permite la consulta y el tratamiento

jerarquizado de la misma (siempre en un entorno diferente a los sistemas

operacionales).

http://www.kimballgroup.com/

APORTACIONES DE UN DATAWAREHOUSE

-30-
 Gestiona el depósito de datos a través de tablas de hechos y tablas de

dimensiones, y lo organiza en torno a una BD multidimensional. Esto

permite que se puedan crear cubos multidimensionales.

Proporciona una herramienta para la toma de decisiones en cualquier área

funcional, basándose en información integrada y global del negocio.

Facilita la aplicación de técnicas estadísticas de análisis y modelación para

encontrar relaciones ocultas entre los datos del almacén; obteniendo un

valor añadido para el negocio de dicha información.

Proporciona la capacidad de aprender de los datos del pasado y de predecir

situaciones futuras en diversos escenarios.

Simplifica dentro de la empresa la implantación de sistemas de gestión

integral de relación con el cliente.

CARACTERÍSTICAS DE UN DATAWAREHOUSE

Según definió el propio Bill Inmon, un datawarehouse se caracteriza por ser:

Integrado: los datos almacenados en el datawarehouse deben integrarse

en una estructura consistente, por lo que las inconsistencias existentes

entre los diversos sistemas operacionales deben ser eliminadas. La

información suele estructurarse también en distintos niveles de detalle para

adecuarse a las distintas necesidades de los usuarios.

Histórico: el tiempo es parte implícita de la información contenida en un

datawarehouse. En los sistemas operacionales, los datos siempre reflejan

-31-
el estado de la actividad del negocio en el momento presente. Por el

contrario, la información almacenada en el datawarehouse sirve, entre otras

cosas, para realizar análisis de tendencias. Por lo tanto, el datawarehouse

se carga con los distintos valores que toma una variable en el tiempo para

permitir comparaciones.

Temático: sólo los datos necesarios para el proceso de generación del

conocimiento del negocio se integran desde el entorno operacional. Los

datos se organizan por temas para facilitar su acceso y entendimiento por

parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes

pueden ser consolidados en una única tabla del datawarehouse. De esta

forma, las peticiones de información sobre clientes serán más fáciles de

responder dado que toda la información reside en el mismo lugar.

-32-
No volátil: el almacén de información de un datawarehouse existe para ser

leído, pero no modificado. La información es por tanto permanente,

significando la actualización del datawarehouse la incorporación de los

últimos valores que tomaron las distintas variables contenidas en él sin

ningún tipo de acción sobre lo que ya existía.

-33-
 Separación de los datos usados en operaciones diarias de los datos usados

en el almacén de datos para los propósitos de divulgación, de ayuda en la

toma de decisiones, para el análisis y para operaciones de control. Ambos

tipos de datos no deben coincidir en la misma base de datos, ya que

obedecen a objetivos muy distintos y podrían entorpecerse entre sí.

Otra característica del datawarehouse es que contiene metadatos, es decir,

datos sobre los datos. Los metadatos permiten saber la procedencia de la

información, su periodicidad de refresco, su fiabilidad, forma de cálculo... etc.

Los metadatos serán los que permiten simplificar y automatizar la obtención

de la información desde los sistemas operacionales a los sistemas

informacionales.

-34-
 Los objetivos que deben cumplir los metadatos, según el colectivo al que

va dirigido, son:

Dar soporte al usuario final, ayudándole a acceder al datawarehouse con

su propio lenguaje de negocio, indicando qué información hay y qué

significado tiene. Ayudar a construir consultas, informes y análisis, mediante

herramientas de Business Intelligence como DSS, ESS o BSC.

Dar soporte a los responsables técnicos del datawarehouse en

aspectos de auditoría, gestión de la información histórica, administración

del datawarehouse, elaboración de programas de extracción de la

información, especificación de las interfaces para la realimentación a los

sistemas operacionales de los resultados obtenidos, ... etc.

-35-
VENTAJAS E INCONVENIENTES DE LOS DW

Ventajas: Hay muchas ventajas por las que es recomendable usar un almacén

de datos. Algunas de ellas son:

Los almacenes de datos hacen más fácil el acceso a una gran variedad de

datos a los usuarios finales.

Facilitan el funcionamiento de las aplicaciones de los sistemas de apoyo a

la decisión tales como informes de tendencia, por ejemplo: obtener los ítems

con la mayoría de las ventas en un área en particular dentro de los últimos

dos años; informes de excepción, informes que muestran los resultados

reales frente a los objetivos planteados a priori.

-36-
 Los almacenes de datos pueden trabajar en conjunto y, por lo tanto,

aumentar el valor operacional de las aplicaciones empresariales, en

especial la gestión de relaciones con clientes.

Inconvenientes: Utilizar almacenes de datos también plantea algunos

inconvenientes, algunos son:

A lo largo de su vida los almacenes de datos pueden suponer altos costos.

El almacén de datos no suele ser estático. Los costos de mantenimiento

son elevados.

Los almacenes de datos se pueden quedar obsoletos relativamente pronto.

A veces, ante una petición de información éstos devuelven una información

subóptima, que también supone una pérdida para la organización.

A menudo existe una delgada línea entre los almacenes de datos y sistemas

operativos. Hay que determinar qué funcionalidades de éstos se pueden

aprovechar y cuáles se deben implementar en el data warehouse, resultaría

-37-
 costoso implementar operaciones no necesarias o dejar de implementar

alguna que sí vaya a necesitarse.

DATA LAKES Y DATA WAREHOUSES

Los data lakes han surgido en el paisaje de Data Management en los últimos

años, sin embargo, data lake no es necesariamente un reemplazo del data

warehouse. En cambio, complementan los esfuerzos existentes y dan soporte

al descubrimiento de nuevas preguntas. Una vez que se descubren esas

preguntas se optimizan las respuestas. Y optimizar puede significar moverse

fuera del datalake para ir a un datamart o al datawarehouse.

Estas son algunas diferencias clave entre datalake y data warehouse:

Datos: Un data warehouse sólo almacena datos que han sido modelados o

estructurados, mientras que un Data Lake no hace acepción de datos. Lo

almacena todo, estructurado, semiestructurado y no estructurado.

Procesamiento: Antes de que una empresa pueda cargar datos en un data

warehouse, primero debe darles forma y estructura, es decir, los datos

deben ser modelados. Eso se llama schema-on-write. Con un data lake,

sólo se cargan los datos sin procesar, tal y como están, y cuando esté listo

para usar los datos, es cuando se le da forma y estructura. Eso se llama

schema-on-read. Dos enfoques muy diferentes.

Almacenamiento: Una de las principales características de las tecnologías

de big data, como Hadoop, es que el coste de almacenamiento de datos es

relativamente bajo en comparación con el de un data warehouse. Hay dos

-38-
razones principales para esto: en primer lugar, Hadoop es software de

código abierto, por lo que la concesión de licencias y el soporte de la

comunidad es gratuito. Y segundo, Hadoop está diseñado para ser

instalado en hardware de bajo coste.

Agilidad: Un almacén de datos es un repositorio altamente estructurado, por

definición. No es técnicamente difícil cambiar la estructura, pero puede

tomar mucho tiempo dado todos los procesos de negocio que están

vinculados a ella. Un data lake, por otro lado, carece de la estructura de un

data warehouse, lo que da a los desarrolladores y a los científicos de datos

la capacidad de configurar y reconfigurar fácilmente y en tiempo real sus

modelos, consultas y aplicaciones.

Seguridad: La tecnología del data warehouse existe desde hace décadas,

mientras que la tecnología de big data (la base de un Data Lake) es

relativamente nueva. Por lo tanto, la capacidad de asegurar datos en un

data warehouse es mucho más madura que asegurar datos en un data lake.

Cabe señalar, sin embargo, que se está realizando un importante esfuerzo

en materia de seguridad en la actualidad en la industria de Big

Data.

-39-