Análisis dE DATA WAREHOUSe

parte 1

Ing. Gabriela Betzabé Lizárraga Ramírez

1
 RECOPILACIÓN e INTEGRACIÓN
Para realizar el Diseño Lógico (Análisis) requiere
decidir:
 Cuales serán las Fuentes de datos
◦ Internas y
◦ externas
 ¿Cómo se van a mantener con el tiempo?

2
Si una compañía europea quiere analizar aquellos
países y gamas de productos en los que las ventas
vayan excepcionalmente bien para premiar a las
mejores oficinas comerciales.

De cada venta se registra

 la fecha,
 cantidad,
 comprador y
 país.
Sí deseamos hacer un análisis profundo, revisaremos:
 la renta per cápita de cada país o
 la distribución por edad de cada país o
 información externa como horas de sol anuales de cada país
para una compañía de cosméticos.
3
La BD transaccional sirve de fuente de datos para
un DWH

4
Diagrama OLTP que alimenta al DWH anterior para la parte de ventas (solo se usa una
parte de las tablas) de facturación de productos, actividades de empleados e información
de publicidad

5
 Diferencias OLTP- OLAP

Ejemplos de transacciones en OLAP que requieren

muchos recursos:

 resúmenes de ventas mensuales,

 la espera media de los pacientes en cirugía
digestiva de un hospital,
 el producto cuyas ventas han crecido más en
Ejemplos de transacciones en OLTP: el último trimestre, etc.

• la inserción de un nuevo cliente,

• el cambio del sueldo de un empleado,
• la tramitación de un pedido, etc.

El almacén como integrador de

diferentes fuentes de datos

- Diseñar el DWH
- Cargar el DWH
- Mantener el DWH

6
Los datos en un DWH se organizan en torno
a los hechos, con sus atributos y medidas que
pueden verse en mayor o menor detalle según
sus dimensiones.
Por ejemplo una cadena de supermercados
puede tener como hechos básicos las ventas.

7
Las ventas en DWH tienen
medidas: importe, cantidad, número de clientes
y se puede detallar o agregar en varias, responden
generalmente a la pregunta “cuánto”
dimensiones: fecha (día, mes, año, bimestre…) de
la venta, producto de la venta, lugar de la venta, etc.
responden al “cuándo”,“qué”,“dónde”, etc.

8
 Resultado del análisis de
datos es el Modelo ROLAP
elaborado de preferencia
para su fácil mantenimiento
en herramienta CASE
El modelo ha de permitir, de una manera sencilla,
obtener información sobre hechos a diferentes
niveles de agregación. Por ejemplo, el hecho

“El Día 20 de mayo del 2013 la empresa

vendió en España 12327 unidades de productos
de la categoría insecticidas”
El hecho representa
•una medida (cantidad 12327 unidades) de una venta
•con granularidad día para la dimensión tiempo (20 de mayo del 2003),
•con granularidad país para la dimensión lugar (España) y
•con granularidad categoría (insecticidas) para la dimensión de productos.

10
En el modelo ROLAP Ventas Las flechas se pueden leer
como “se agrega en”.

11
La forma que tienen estos conjuntos de hechos y sus
dimensiones hace que se llamen:

• “estrella simple”
cuando no hay caminos alternativos
en las dimensiones, con una tabla estrella
cada una.

ó
• “estrella jerárquica” o “copo de nieve” cuando hay varias tablas
copo de nieve en cada dimensión, o incluso caminos alternativos
en las dimensiones.

12
Cuando el número de dimensiones no excede
de tres, podemos representar cada combinación
de niveles de agregación como un cubo. El cubo
está formado por casillas, cada casilla representa
un hecho.

13
 Si hay más de 3 dimensiones, se habla de un
hipercubo.
Esta estructura permite:
 agregación (varias casillas se fusionan en
casillas más grandes) nivel máximo de
agregación en dimensión tiempo en el
ejemplo es un año

 disgregación (las casillas se separan en casillas

con mayor detalle) nivel mínimo es
hora.

14
 Por tanto el almacén de datos (data warehouse) estará formado
por muchas estrellas formando una “constelación”.
 Se pueden compartir dimensiones, noten que la dimensión
tiempo por ser información histórica siempre aparece

15
Los sistemas de almacenes de bases de datos
pueden implementarse utilizando 4 tipos de
esquemas físicos:
 ROLAP (Relational OLAP): se construye sobre
una base de datos relacional, es menos costoso
 MOLAP (Multidimensional OLAP): se construye
sobre estructuras basadas en matrices
multidimensionales, es más eficiente

16
Ejemplos de sistemas ROLAP
 Microstrategy (Con interfaz completamente
multidimensional mientras que por debajo existe
un sistema relacional),
 Informix Metacube u
 oracle Discoverer
 Pentaho Data Integration, Pentaho workbench
 ODI, OBI
 Business Intelligence Sqlserver
Ejemplos de sistemas MOLAP
 Oracle Express o
 Hyperion Enterprise.

17
18
2 Tabla de hechos (fact tables): se crea una única tabla de
hechos por datamart. En esta tabla se incluye un atributo para
cada dimensión, que será FK a cada una de las tablas copo de
nieve de mayor detalle, además, todos estos atributos forman
la clave primaria. Adicionalmente, pueden existir atributos que
representen información de cada hecho,
denominados medidas.

19
3 Tablas estrella (star tables): para cada dimensión se crea una
tabla que tiene un atributo para cada nivel de agregación
diferente en la dimensión. Cada uno de estos atributos es una
FK que hace referencia a tablas copo de nieve. Todos los
atributos PK de las tablas estrella forman la PK de la tabla de
hechos.

20
Esquema Estrella SIMPLE

Esquema Snowflake (Copo de Nieve)

21
22
Estas tablas Estrella, representan “pre-
concatenaciones”, o “pre-joins” entre las tablas
copo de nieve.
Evitan concatenaciones costosas cuando se
realizan operaciones roll-up.

Las tablas copo de nieve. Son muy útiles para

los operadores drill, slice&dice y pivot.

23
Además de la estructura anterior, los sistemas
ROLAP se pueden acompañar de:

índices de mapa de bits (bitmap),

optimizadores de consultas,
extensiones de SQL (por ejemplo “CUBE”), etc.
OPERADOR CUBE
https://sites.google.com/site/josepando/home/funcio
nes-sql/funciones-de-totalizacin-mejoras-de-la-
clausula-group-by/operador-cube

24
Existe también sistemas
DOLAP (Desktop, por su lugar en donde se
almacena)
y
HOLAP (Híbrido = ROLAP para diseñar + MOLAP
para almacenar)

Los sistemas MOLAP almacenan físicamente los

datos en estructuras multidimensionales de forma
que la representación externa e interna coincidan.
Lo que permite rendimientos mayores que los
ROLAP.

25
Inconvenientes en MOLAP
 Se necesitan sistemas específicos. Esto ocasiona un
costo mayor de software

 Compromete la portabilidad al no existir estándares

como en el modelo relacional.
 Los cambios en el diseño del almacén de datos obligan a
una reestructuración profunda del esquema físico y
viceversa
 Existe más desnormalización que en las ROLAP.
 En muchos casos un almacén de datos MOLAP ocupa
más espacio que su correspondiente ROLAP.
26
Las ventajas de esta normalización son
• Reducción del tamaño y
• Aumento de flexibilidad en la definición de
dimensiones.
Desventajas
• El incremento en la cantidad de tablas hace que
se necesiten más operaciones de JOINs para
responder a las consultas, lo que empeora el
performance.
• Mantenimiento adicional que requieren las tablas
adicionales.

27
 Extensiones del modelo entidad relación (1999)
o de modelos orientados a objetos (2001).

 Si se utiliza una metodología orientada a objetos

o UML, existe un estándar “Common Warehouse
Metadata (CWM)”. Se trata de una extensión del
UML para modelar almacenes de datos.

https://www.service-architecture.com/articles/web-
services/common_warehouse_meta-
model_cwm.html
http://www.omg.org/spec/CWM/

28
 4 pasos principales para ANALIZAR
un almacén de datos (para cada
datamart)
1. Elegir “dominio” de la organización sobre el que
se deseen realizar informes complejos.
Ejemplos, datamart sobre
pedidos,
ventas,
facturación, etc.

29
2 Decidir el hecho central y el “gránulo” (nivel de
detalle) máximo que se va a necesitar sobre él.

En general, siempre hay que considerar gránulos

finos por si más adelante se fueran a necesitar, a
no ser que haya restricciones de espacio.

30
3. Identificar las dimensiones que caracterizan el
“dominio” y su jerarquía de agregación, así como los
atributos básicos de cada nivel. Incluir atributos
descriptivos imprescindibleS para ayudar en la
visualización.

31
4. Determinar y refinar las medidas y atributos
necesarios para los hechos y las dimensiones.
Generalmente las medidas de los hechos son
valores numéricos agregables
(totales,
cuentas,
medias…).

En general las tablas de hechos tienen muchas filas y

relativamente pocas columnas.
Las tablas de dimensión
suelen tener muchas columnas pero pocas filas.
Depende el ámbito (dominio) existen otras dimensiones
comunes son las de clientes, productos, representantes de
ventas, regiones, sucursales.
32
DISEÑO dE DATA WAREHOUSe
parte 2

Ing. Gabriela Betzabé Lizárraga Ramírez

33
DISEÑO FÍSICO DE DATA WAREHOUSE
(PARTE 2)

Etapa para incluir nuevos objetos de

BD: como cluster, tablas de indice
organizado, particionamiento, hacer
calculos e incluir clausula storage 
Para mejorar el script DDL

34
Los DataWarehouses se acercan o exceden el
terabyte son llamadas VLDBs (Very Large Databases).

Diseñar una base de datos de este tipo es un gran

desafío.

A continuación se detallan algunos temas que

impactan sobre el diseño físico del DataWarehouse.

35
1 Particionamiento
Las tablas deben particionarse y ubicarse en varios
discos, donde las tablas de hechos pueden llegar a
ocupar varios cientos de gigabytes.
El particionamiento permite que los datos de una
tabla lógica se repartan en múltiples conjuntos de
datos físicos.

36
Este particionamiento se aplica generalmente
en una columna de la tabla de hechos, que
comúnmente es la columna que indica la fecha,
no puede ser una columna derivada ni
contener valores nulos.

37
Desde el punto de vista lógico, aparecerán
como si estuvieran juntos aunque se
encuentren separados físicamente.
Si dividimos una tabla grande en múltiples
particiones más pequeñas, mejoraremos:
• el rendimiento de las operaciones de
mantenimiento,
• copias de seguridad,
• recuperaciones,
• transacciones y
• consultas.
38
 Una tabla puede ser particionada en hasta 64.000 particiones
separadas.
Se recomiendan cuando:
•La tabla tiene un tamaño superior a 2 GB.
•Tablas que mantienen históricos.

Cuando se particiona una tabla, las particiones deberían

almacenarse en tablespaces diferentes.
Si la tabla tiene un tamaño de 1 terabyte y utiliza 100
particiones distribuídas uniformemente, de 10GB cada una.
Aunque las tablas de 10 GB no sean siempre fáciles de
administrar, está claro que siempre lo serán más que las de 1
terabyte.

Nota: No se pueden realizar particiones de objetos que

utilicen tipos de datos LOB (como LONG o LONG RAW).

39
1) particionamiento por rangos.
Create table EMPLEADO (
Empno Number(10) primary key,
Name varchar2(40),
Deptno number(2),
Salary number(7,2),
Birth_date date,
Soc_sec_num varchar2(9),
State_code char(2),
Constraint fk_deptno foreign key (deptno) references dept(deptno)
)
partition by range (deptno)
(partition PART1 values less than (11)
tablespace PART1_TS,
partition PART2 values less than (21)
tablespace PART2_TS,
partition PART3 values less than (31)
tablespace PART3_TS,
partition PART4 values less than (MAXVALUE)
tablespace PART4_TS)
40
Consultas directas a las particiones.
Ejemplo:
Select *
From EMPLEADO partition (PART2)
Where Deptno between 11 and 20;

41
Indexación de particiones.
Create index EMPLEADO_DEPTNO
On EMPLEADO(deptno)
Local
(partition PART1
tablespace PART1_NDX_TS,
partition PART2
tablespace PART2_NDX_TS,
partition PART3
tablespace PART3_NDX_TS,
partition PART4
tablespace PART4_NDX_TS)
local le indica a Oracle que cree un índice
diferente para cada partición de la tabla
EMPLEADO
42
También se pueden crear índices “globales”.

Create index EMPLEADO_DEPTNO

On EMPLEADO(deptno)
Global partition by range (name)
(partition PART1 values less than (‘J’) tablespace PART1_NDX_TS,
partition PART2 values less than (‘N’) tablespace PART2_NDX_TS,
partition PART3 values less than (‘R’) tablespace PART3_NDX_TS,
partition PART4 values less than (MAXVALUE) tablespace )
PART4_NDX_TS

La cláusula global de este comando create index

permite especificar rangos para los valores de índice

43
Gestión de particiones
Alter table EMPLEADO
Modify partition PART1
Storage (next 1M pctincrease 0);

Alter table EMPLEADO

Truncate partition PART1
Drop storage;

Alter index EMPLEADO_DEPTNO

Rebuild partition PART4
Storage (inicial 2M next 2M pctincrease 0);

44
3) Partición Hash.
Esta opción es útil cuando:
• Se desconoce la correspondencia en función de los rangos y
Es difícil balancearla manualmente, por tanto el RDBMS lo realiza
automático.
• No elegir una columna con un alto grado de valores duplicados
ya que esto puede generar particiones no balanceadas

CREATE TABLE sales_hash

(salesman_id NUMBER(5),
sales_name VARCHAR2(30),
sales_amount NUMBER(10),
week_no NUMBER(2))
PARTITION BY HASH(salesman_id)
PARTITIONS 4
STORE IN (data1, data2, data3, data4);

45
4) Partición compuesta o Particionamiento por Composición.
Cada partición se particiona a su vez es sub-particiones. Las particiones más
generales se hacen con el método de rango. Cada partición se sub-particiona con el
método de hash o por lista.
CREATE TABLE sales_composite
(salesman_id NUMBER(5),
sales_name VARCHAR2(30),
sales_amount NUMBER(10),
sales_date DATE)
PARTITION BY RANGE(sales_date)
SUBPARTITION BY HASH(salesman_id)
SUBPARTITION TEMPLATE(
SUBPARTITION sp1 TABLESPACE data1,
SUBPARTITION sp2 TABLESPACE data2,
SUBPARTITION sp3 TABLESPACE data3,
SUBPARTITION sp4 TABLESPACE data4)
(PARTITION sales_jan2000 VALUES THAN
(TO_DATE(’01/02/2000’,’DD/MM/YYYY’)
PARTITION sales_feb2000 VALUES THAN
(TO_DATE(’01/03/2000’,’DD/MM/YYYY’
PARTITION sales_mar2000 VALUES THAN
(TO_DATE(’01/04/2000’,’DD/MM/YYYY’
PARTITION sales_apr2000 VALUES THAN 46
2 Clustering
Esta técnica es importante permite en el mismo segmento incluir
varias tablas que frecuentemente se utilizan juntas
Ejemplo de Cluster Índice
1) Cree un cluster.
CREATE CLUSTER scott.ord_clu
(ord_no NUMBER (3))
SIZE 200 TABLESPACE DATA01
STORAGE (INITIAL 5M NEXT 5M
PCTINCREASE 0);
2) Cree un índice cluster.
CREATE INDEX scott.ord_clu_idx
ON CLUSTER scott.ord_clu
TABLESPACE INDX01
STORAGE (INITIAL 1M NEXT 1M
PCTINCREASE 0);
47
3) Cree tablas en el cluster.
CREATE TABLE scott.ord
(ord_no NUMBER (3) CONSTRAINT ord_pk PRIMARY KEY,
Ord_dt DATE,
cust_cd VARCHAR2 (3))
CLUSTER scott.ord_clu (ord_no);

CREATE TABLE scott.item

(ord_no NUMBER (3) CONSTRAINT item_ord_fk REFERENCES scott.ord,
Prod VARCHAR2 (5),
qty NUMBER (3),
CONSTRAINT item_pk PRIMARY KEY (ord_no, prod))
CLUSTER scott.ord_clu (ord_no);

48
Ejemplo de Cluster HASH
1) Cree un Cluster
CREATE CLUSTER scott.off_clu
(country VARCHAR2 (2),
postcode VARCHAR2 (8))
SIZE 500 HASHKEYS 1000
TABLESPACE DATA01
STORAGE (INITIAL 5M NEXT 5M
PCTINCREASE 0);

2) Cree tablas en un cluster

CREATE TABLE scott.office (
office_cd NUMBER (3),
cost_ctr NUMBER (3),
country varchar2 (2),
postcode VARCHAR2 (8))
CLUSTER scott.off_clu (country,postcode);
49
Parámetro SIZE
El parámetro SIZE para un cluster define el espacio usado por
todos los renglones de un valor de llave cluster dado. Para el
cluster indexado, por ejemplo, cada orden tiene 10 artículos y el
tamaño de un renglón en la tabla ORD es de 20 bytes y un
renglón en la tabla ITEM es de 18 bytes, el SIZE es definido por la
siguiente fórmula:

1 fila ORD X 20 bytes/fila + 10 filas ITEM X 18 bytes/fila = 200 bytes

Mientras se decide el valor de SIZE para los clusters hash, es

importante especificar un valor ligeramente mayor para reducir la
posibilidad de colisiones

50
 3 Indexado
La mayoría de los DBMSs proveen varios algoritmos,
entre ellos B-tree, Hash, llave Invertida y Binario.

Creación de Indice bitmap

Considerados para columnas con pocos valores distintos

(como genero en persona)

CREATE BITMAP INDEX scott.ord_region_id_idx

ON scott.ord(region_id)
PCTFREE 30
STORAGE (INITIAL 200K NEXT 200K
PCTINCREASE 0 MAXEXTENTS 50)
TABLESPACE indx01;

51
4 TABLAS DE INDICE ORGANIZADO
Permite almacenar una tabla e índice en el mismo
segmento, no se almacena el rowid, se ejercita
mayor control sobre el ordenamiento de los
datos.

Recomendable para aplicaciones OLAP, es útil

para una tabla que es accesada frecuentemente
usando la llave primaria y tiene solo unas pocas y
cortas columnas no llave.

52
La tabla de índice organizado puede ser utilizada
como cualquier otra tabla.

No pueden ser creados índices secundarios en

este tipo de tablas.

Soporta todos los constraints excepto constraints

unique.

No puede ser particionada.

53
Ejemplo de tablas de índice organizado
CREATE TABLE scott.sales
( office_code NUMBER(3),
qtr_end DATE,
revenue NUMBER (10,2),
review VARCHAR2 (1000),
CONSTRAINT sales_pk PRIMARY KEY (office_code, qtr_end))
ORGANIZATION INDEX TABLESPACE data01
PCTTHRESHOLD 20  Almacena los datos además de PK, default
50
INCLUDING (REVIEW)  se trasladan a data02 después de
revenue, si excede umbral disponible en el bloque por pctused
OVERFLOW TABLESPACE data02;  mejora la capacidad de E/S

54
 ETL-ELT
(PARTE 3,
este tema tiene otras
diapositivas en una ppt
independiente)

55
Carga y mantenimiento del almacén de datos
 Los procesos de carga de un almacén de
datos son procesos de “migración”.

 La carga y mantenimiento es uno de los

aspectos más delicados y requiere más
esfuerzo, alrededor del 50% de la
implantación de un almacén de datos.
Sistema ETL

 Extraction,
 Transformation,
 Load

56
 Dicho sistema no se compra, ni se descarga de
internet, sino que: la construcción del ETL es
responsabilidad del equipo de desarrollo.

 Se pueden utilizar triggers, vistas materializadas,

herramientas de migración como Pentaho, Talend,
sqlldr.

57
El sistema ETL se encarga de:

a) Lectura de datos transaccionales: mediante

consultas SQL en horarios de poca carga
transaccional (noches o fines de semana).
Para la primera carga los datos pueden
encontrarse en históricos y en distintos
formatos.
a) b) Incorporación de datos externos: utilizando
herramientas para incorporar .txt, .xls, .csv,
.xml.

58
c) Creación de PK’s nuevas en tabla de hechos

d) Integración de datos: Conectar la información con

integridad referencial.

e) Realizar agregaciones: std_dev, corr, max, min, count, sum,

avg

f) Limpieza y transformación de datos para evitar: datos

redundantes, inconsistentes, estandarizar medidas, formatos
fechas, tratar valores nulos, etc.

g) Identificación de cambios: detectar los cambios y actualizar,

en ocasiones un delete en OLTP, no se realiza en OLAP por
ser histórico, a menos que sea por un error, etc.

59
h) Planificación de la carga y mantenimiento: Define el
orden de la carga, para evitar
 violar restricciones de integridad,
 saturar la BD transaccional,
 paralizar el almacén de datos.
i) Indización: Crear índices sobre las claves y atributos
que se consideren relevantes, en ocasiones se
eliminan, para que las cargas de datos sean más
rápidas y después se crean nuevamente.
j) Pruebas de calidad:
 Definir métricas de calidad de datos (conciliación de
cifras origen-destino),
 tener un responsable de calidad (conteos para
comprobar migraciones)

60
En ocasiones los sistemas ETL se basan en un almacenamiento
intermedio (ODS), esto puede parecer abusar de recursos, pero es
extremadamente útil para realizar la limpieza y transformación, sin
que afecte la obtención de reportes, ni interrumpa los OLTP.

ODS Es especialmente útil para integrar información

externa.
61
 E-LT lo definiremos en el orden de las iniciales que consiste
en Extracción, carga y transformación de datos.

Consiste en lo siguiente.
1)extraer y cargar los datos de manera “BULK” directamente a una Base
de Datos o tablas especialmente creadas para los datos de paso
(conocido también como staging).

Este medio servirá solo temporalmente, y puede ser limpiado en cada

proceso de carga.

62
2) teniendo la información en staging proseguimos a elaborar el proceso de
transformación de los datos que posteriormente pasaran a nuestra base de
datos del datawarehouse.

La transformación se hará con el lenguaje propio de la base de datos por

ejemplo T-SQL, PL/SQL.

63
3) con los datos transformados en nuestros procesos propios de la base de
datos, seguimos al proceso de inserción a nuestro datawarehouse, limpiando
nuestros datos de paso si es conveniente.

64
Ventajas de E-LT sobre ETL
Velocidad de proceso y transformación, la principal ventaja de E-LT es la forma en
que trabaja cada herramienta implicada, en el caso de ETL las herramientas de
transformación evalúan registro por registro y en E-LT la transformación se
hace en la base de datos que evalúa los registros en lotes.

65
•Otra ventaja de E-LT es que una base de datos está preparada para la
optimización de recursos ya sea de disco, memoria y proceso, lo cual
hace que el rendimiento del proceso sea administrado por la
configuración de la base de datos,
•En los casos de las herramientas de ETL, no toman ventaja de la
configuración del disco (RAID) ni de la distribución de la memoria y
procesador, esto debido a que hacen transformaciones temporales y
en muchos casos redundantes.

66
Comentarios de uso de Almacenes
de Datos
Parte 4

67
USO DE INFORMACIÓN
EN UN DATA MART O
DATA WAREHOUSE
 Explotación (Uso) de un almacén de datos (operadores
de consulta OLAP)

Los 4 operadores más importantes son:

 Drill: Se trata de disgregar los datos (mayor nivel de
detalle o desglose, menos sumarización) siguiendo los
caminos de una o más dimensiones.
 Roll: se trata de agregar los datos (menor nivel de
detalle o desglose, más sumarización) siguiendo los
caminos de una o más dimensiones.
 Slice & Dice: se seleccionan (where) y se proyectan
datos.
 Pivot: se reorientan las dimensiones.

69
Por ejemplo
 “obtener el total de ventas”.
 En un entorno geográfico,
 dicha consulta se podría realizar eligiendo 2 categorías
“refrescos y congelados” y
 eligiendo el nivel trimestre para la dimensión tiempo.
 Además, se elegiría la medida que se desea (importe).

70
71
Supongamos que queremos las ventas de refrescos en las ciudades
(Valencia y León)
Los operadores, permiten modificar la consulta, son navegadores de
informes. Para este ejemplo podemos utilizar el operador drill,
que permite más detalle.

En el resultado se puede observar que la distribución de ventas en Valencia

(claramente estacional) difiere de la de León (prácticamente no
estacional). 72
Drill (mayor detalle)
 El operador roll es la inversa del drill y el objetivo es
obtener información más agregada.

pivot

74
El operador pivot permite cambiar algunas filas por
columnas. Esta operación, aparentemente sencilla, no
está generalizada en muchos sistemas de bases de
datos. Este cambio permite que valores de columnas
pasen a ser nombre de nuevas columnas y viceversa.

76
El operador Slice & dice permite escoger parte de la información
mostrada, no por agregación sino por selección (Where).

77
 Ejemplo Oracle --PIVOT
--Crea la tabla emp select to_char(fecha,'yyyy') anio, job, count(*)
from emp
create table emp (
group by to_char(fecha,'yyyy'),job
emp_id number(10) constraint emp_pk primary key,
order by anio,job;
job varchar2(20) not null, --
fecha date select anio,ANALYST,CLERK,MANAGER,SALESMAN
); from (select to_char(fecha,'yyyy') anio, job from emp)
---Llena la tabla pivot (count(*) for job in ('ANALYST' as
ANALYST,'CLERK' as CLERK,'MANAGER' as
insert into emp values MANAGER,'SALESMAN' as SALESMAN))
(1,'CLERK',to_date('01/01/1980','DD/MM/YYYY'));
order by anio;
insert into emp
values(2,'ANALYST',to_date('01/01/1981','DD/MM/YYY
URLs PARA MAS INFORMACIÒN
Y'));
http://www.oracle.com/technetwork/es/articles/sql/ca
insert into emp racteristicas-database11g-2108415-esa.html
values(3,'MANAGER',to_date('01/01/1981','DD/MM/YY
YY'));
https://technet.microsoft.com/es-
insert into emp es/library/ms177410(v=sql.105).aspx
values(4,'CLERK',to_date('01/01/1981','DD/MM/YYYY'))
;
insert into emp
values(5,'SALESMAN',to_date('01/01/1981','DD/MM/YY
YY'));
insert into emp
values(6,'ANALYST',to_date('01/01/1987','DD/MM/YYY
Y'));
Los almácenes de datos pueden agilizar muchos procesos diferentes de
análisis.

Observe la variedad de usos y también por supuesto hay

diferentes grupos de usuarios: analistas, ejecutivos, investigadores,
etc.

79
Según el carácter de estos usuarios se les puede
catalogar en 2 grandes grupos:

“Picapedreros” o “granjeros” Se dedican a:

 realizar informes periódicos,
 ver la evolución de indicadores,
 controlar valores anómalos, etc.
“exploradores” encargados de:
 encontrar nuevos patrones significativos utilizando
técnicas OLAP o de minería de datos.

La estructura del almacén de datos y sus operadores

facilita la obtención de diferentes vistas de análisis o
“vistas minables”.
80
El nivel de agregación para los requerimientos de análisis
OLAP puede ser mucho más amplio que el necesario
para minería de datos.

Por ejemplo para OLAP puede ser mínimo el

supermercado, mientras que en minería puede ser por
caja o cajero.(para analisis de desempeño)

Se puede hacer minería de datos sobre un simple archivo

de datos. Sin embargo, las ventajas de organizar un
almacén de datos son a mediano y largo plazo.

81
 Tampoco es cierto que un almacén de datos
sólo tenga sentido si tenemos una base de
datos transaccional inicial.

 Incluso si todos los datos originalmente no

provienen de bases de datos puede ser
conveniente la realización de un almacén de
datos.

82
En gran medida, un almacén de datos también
facilita:
 la limpieza y
 la transformación de datos
(en especial para generar “vistas minables” en
tiempo real).

83