Bases de datos avanzadas

María José Aramburu Cabo

Ismael Sanz Blasco

Bases de datos orientadas a

objetos
INTRODUCCION
Las BD mas utilizadas son las relacionales para muchas
aplicaciones habituales.
Qué pasa si se requiere:
 Datos muy complejos o no convencionales (imágenes,
documentos...).
 Bases de datos multimedia.
 Las bases de datos científicos y
 Los sistemas de apoyo al diseño industrial (cad/cam).
Objeto
 En las bases de datos orientadas a objetos todos los elementos que se
manejan son objetos. Cada objeto se corresponde con una entidad de la
realidad, y define sus propiedades y comportamiento.
 Un objeto es una representación abstracta de una entidad del mundo real
que tiene:
 Identidad única dentro de la base de datos. Propiedades incorporadas en sí
mismo.
 Comportamiento que le proporciona la capacidad de interaccionar con
otros objetos y consigo mismo.

Los objetos, tienen identidad,

de tal forma que poseen un
comportamiento y pueden
interaccionar entre sí.
Propiedades
 La estructura de datos se construye a partir de
unos tipos de datos básicos por medio de unos
constructores de tipos de datos y de tipos de
objetos, que se pueden combinar
arbitrariamente.
Entre los tipos de datos Los SGBDOO más avanzados
básicos el SGBDOO también permiten al usuario definir sus
pueden aparecer tipos de propios tipos de datos básicos con
datos multimedia y texto. sus propias operaciones
Constructores de Objetos
elementos de los dominios básicos: enteros,
Átomos reales, cadenas, etc
Constructores
Colecciones tuplas ([…]), conjuntos ({…}) y listas (//…//)

Las tuplas tienen varios componentes llamados atributos con un nombre y un tipo.
Los conjuntos son un número de 0 o más elementos del mismo tipo y que no se
repiten. Las listas son como los conjuntos pero conservando el orden de inserción.
Los BDOO, como los lenguajes de programación OO, pueden proporcionar otros
tipos de colecciones.

Los valores de los objetos se construyen a partir de los átomos (valores reales,
enteros, cadenas, etc.) y también a partir del conjunto de OID de todos los objetos
existentes en la base de datos. A la hora de construir los valores, los constructores
pueden ser anidados dando lugar a valores con estructuras complejas.
Constructores
define data type Fecha
Lenguaje de definición de datos
tuple [ año: integer,
simplificado, basado en el
mes: integer,
lenguaje O2C del SGBDOO O2
dia: integer]
o1 = (OID = oid_e1,
valor = [‘José García’, define object type Empleado
‘99.999.999-X’, tuple [ nombre: string,
[1980, 12, 10], dni: string,
V, fecha_nac: Fecha,
oid_d1 sexo: char,
]) depto: Departamento]
o2 = (OID= oid_d1,
valor= [‘Informática’, define object type Departamento
17, tuple [ nombred: string,
[oid_e1, [1999, 10, 17] ], numerod: integer,
{‘Castellón’, ‘Valencia’, ‘Alicante’}, dirigido: tuple [ gerente: Empleado,
{oid_e1, oid_e13, oid_e11, oid_e17, fecha_inic: Fecha],
oid_e5, oid_e3, oid_e2} sedes: set(string),
]) empleados: set(Empleado)]
Constructores
 Las palabras reservadas tuple, set y list permiten definir los tipos tupla,
conjunto y lista respectivamente, y para los tipos atómicos asumiremos
que están disponibles los tipos de datos básicos más habituales (integer,
string, real...).
 Definido un tipo de datos (data type) Fecha para simplificar la definición
los tipos de objetos (object type) Empleado y Departamento.
 Los tipos de datos se utilizan para simplificar la definición de tipos de
objetos, y representan estructuras de datos que se reutilizan en la
definición de las propiedades de distintos tipos de objetos (como fechas
o direcciones), y no van a tener existencia independiente: En ningún caso
va haber objetos «Fecha» con identidad propia. Es muy importante
hacer notar esta distinción entre «object type» para definir objetos, y
«data type» que se utiliza exclusivamente para facilitar la definición de
las propiedades de los tipos de objetos.
Persistencia

 Los objetos transitorios desaparecen una vez

que el programa que los creó termina de
ejecutarse.
 Los objetos persistentes permanecen
almacenados en la base de datos.
Alternativas para hacer al objeto
persistente
 La primera es marcarlo explícitamente como persistente.
 En el siguiente ejemplo en Java se utiliza la BDOO db4o
(db4objects) para crear un objeto de tipo Empleado, que
a continuación se marca como persistente usando el
método STORE para tal efecto. El objeto CONTENEDOR
encapsula el almacenamiento de objetos.

Empleado empleado = new Empleado("Joan", "Cardona", "Vives");

contenedor.store(empleado);
Alternativas para hacer al objeto
persistente
 La segunda alternativa para hacer un objeto persistente es hacerlo alcanzable a partir de otro objeto
ya marcado como persistente.
 Se dice que un objeto A es alcanzable desde otro B, si hay alguna cadena de referencias que llevan
desde el objeto B hasta el objeto A.
Por ejemplo:
class Empleado {
⁞
private Direccion direccion;
⁞
public void setDireccion(Direccion nueva_dir) {
dirección = nueva_dir;
}
⁞
}

Podemos crear un objeto de tipo Empleado y asignarle una dirección de esta manera:

Direccion direccion = new Direccion("C/Mayor, 5", "Castellón")

Empleado empleado = new Empleado("Joan", "Cardona", "Vives");
empleado.setDireccion(direccion);
contenedor.store(empleado);
Alternativas para hacer al objeto
persistente
La última manera de hacer objetos persistentes es añadiéndolos a
una colección persistente de su clase. Sobre una clase se pueden
definir varias colecciones de objetos persistentes, y para aquellas
clases que vayan a tener instancias almacenadas en la base de datos
esEnimprescindible
nuestro lenguaje tener definida
de definición al menos
de datos una.
se define por medio de la cláusula
extent una colección persistente para cada clase.
Siguiendo con el ejemplo, en db4o se encuentran versiones persistentes de las
colecciones estándar; por ejemplo com.db4o.collections.ActivatableLinkedList
es la versión persistente de la colección estándar java.util.LinkedList, y tiene la
misma interfaz:
ActivatableLinkedList<Empleado> listaDeEmpleados;
listaDeEmpleados = new ActivatableLinkedList<Empleado>();
Empleado empleado = new Empleado("Joan", "Cardona", "Vives");
listaDeEmpleados.add(empleado)
Características de los SGBDOO

El conjunto de reglas equivalente para los sistemas orientados

a objetos se conoce como el Manifiesto de las BDOO, y fue
definido en 1992. Consta de las 13 reglas y cinco opciones de
implementación.

Opciones de implementación:

1. Herencia múltiple
2. Verificación e inferencia de tipos
3. Distribución de los datos
4. Transacciones
5. Versionado de objetos
Características de los SGBDOO

 Es importante hacer notar que las reglas 1 a 8

son características generales de los sistemas
orientados a objetos, incluyendo los
lenguajes de programación, y que por otro
lado, las reglas 9 a 13 son características
generales de las bases de datos, incluyendo
las no orientadas a objetos, como las
relacionales.
Reglas para un SGBDOO
REGLA EXPLICACIÓN
1. Objetos complejos. Un SGBDOO podrá gestionar objetos
con estructuras de datos arbitrarias

2. Identidad de objetos En una BDOO los objetos tendrán una

identidad, que será diferente de su
valor
3 Encapsulación Un SGBDOO permitirá ocultar los
detalles de implementación de los
objetos, haciendo que un objeto solo
sea accesible mediante su interfaz
público.
4. Tipos y clases Un SGBDOO permitirá definir tipos de
datos y tipos de objetos.
Reglas para un SGBDOO
REGLA
5. Jerarquías de clases
6. Sobrecarga y polimorfismo
7. Lenguaje computacionalmente completo
8. Extensibilidad
EXPLICACIÓN
Un SGBDOO permitirá organizar los objetos en
clases, y permitirá definir nuevas clases
especializando o generalizando otras ya existentes
Distintas clases podrán proporcionar distintos
métodos para una misma operación; el sistema
determinará dinámicamente qué método se debe
ejecutar
Un SGBDOO proporcionará un lenguaje de
programación computacionalmente completo, que
es aquel que puede expresar cualquier algoritmo.
SQL, por ejemplo, no es completo.
Cada SGBDOO tiene un conjunto de tipos
predefinidos por el sistema. Este conjunto puede
ser extendido. Los tipos definidos por el sistema y
los tipos definidos por el usuario deben ser tratados
del mismo modo.
Reglas para un SGBDOO
REGLA EXPLICACIÓN
9. Persistencia En una SGBDOO, los objetos serán persistentes de la
manera más transparente posible.

10. Gestión de memoria secundaria Todo SGBDOO ha de ofrecer funciones de gestión de

almacenamiento eficiente. Esto ha de incluir el uso de
índices, agrupación de datos, el almacenamiento en
memoria intermedia de datos, selección de la ruta de
acceso y optimización de consultas. Todas estas
características deben ser invisibles para el
programador de la aplicación.
11. Concurrencia Un SGBDOO debe ofrecer mecanismos para
sincronizar el acceso de más de un usuario al mismo
tiempo.
12. Recuperación Un SGBDOO debe mantener el nivel de servicios en
caso de fallos de software o hardware.
13. Consultas ad hoc con un lenguaje declarativo Un SGBDOO proporcionará un lenguaje de consulta
específico para objetos
Diseño lógico de base de datos
Orientadas a Objetos
Para diseñar bases de datos orientadas a
objetos hay que identificar:
Las clases de objetos que se necesitan,
Tipo y las operaciones de cada clase

Para definir el tipo de los objetos de una clase,

primero hay que identificar qué relaciones se
dan entre las clases.
Vamos a analizar los distintos tipos de
relaciones que se pueden dar entre las clases de
una bdoo.
Agregación

 Los objetos agregados son aquellos que se

componen de otros objetos.
 La agregación es un tipo de relación que
permite relacionar objetos agregados con sus
objetos componentes (relación todo/parte).
 La relación entre un objeto y sus componentes
siempre la vamos a denotar con se_compone_de
y dibujaremos flechas que vayan desde el objeto
agregado hacia los componentes.
Agregación
Asociación
 La asociación sirve para relacionar objetos de varias clases
independientes. En el esquema conceptual de la base de
datos a este tipo de relaciones se las denomina con un
nombre y una cardinalidad que reflejen su significado.
Generalización, especialización y
herencia.
Todas las instancias de una subclase son también instancias de
la superclase, pero no a la inversa. Este tipo de relación se
denomina generalización, o especialización a la inversa, y en el
esquema conceptual se representa con una relación
denominada es_un y unas flechas que van desde las subclases
hacia las superclase. La generalización tiene dos propiedades de
las bases de datos orientadas a objetos:
 Sustituibilidad dice que toda instancia de una clase puede ser
utilizada cuando se espera una instancia de alguna de sus
superclases.
 Extensión dice que las instancias de una clase incluyen las
instancias de sus subclases. En otras palabras, la extensión de
una clase incluye a las extensiones de sus subclases.
Generalización o especialización
inversa

public class Generalizacion {

public static void main(String[] args) {
Secretario sec = new Secretario("Francesc", "Tárrega");
Gerente ger = new Gerente("Maximilià", "Alloza");
System.out.println(sec instanceof Empleado);
System.out.println(ger instanceof Empleado);
}
}
Herencia

Una importante característica de las jerarquías de

especialización es el de la herencia de tipos y operaciones
desde las superclases hacia las subclases. Es decir, todas
las subclases de una clase heredan automáticamente su
tipo y operaciones, siendo esta una propiedad que se
propaga a lo largo de toda la jerarquía. Por esta razón, a la
hora de hacer el diseño lógico, la definición del tipo y de
las operaciones de una subclase incluye de manera
implícita a todas las definiciones hechas para la superclase
más aquellas nuevas definiciones (nuevos atributos y
nuevas operaciones) explícitas que quieran hacerse.
Herencia
 La herencia simple: ocurre cuando cada clase en una
jerarquía tiene una sola superclase inmediata.
 La herencia múltiple: ocurre cuando una subclase tiene
varias superclases inmediatas.
Polimorfismo de métodos
Permite asignar a una misma operación dos o más
implementaciones diferentes, con el propósito de que en
cada caso se ejecute una de ellas, dependiendo de la clase
de los objetos a los que se aplique.
define object type Objeto_Geometrico define object type Triangulo inherit
type Objeto_Geometrico
forma: string type
operations tuple [ lado_1: real,
area(): real; lado_2: real,
angulo: real]
define object type Rectangulo inherit operations
Objeto_Geometrico //inherit -hereda de… es_equilatero?(): bool;
type
tuple [ ancho: real, define object type Circulo inherit
alto: real] Objeto_Geometrico
operations type
es_cuadrado?(): bool; radio: real;
Polimorfismo de métodos

 La operación area() se declara para todos los

objetos de la clase Objeto_Geometrico,
aunque su implementación varía
dependiendo de la subclase del objeto.
 Una posibilidad es tener una implementación
general para calcular el área de cualquier
objeto geométrico, y luego implementar
otros métodos específicos para calcular las
áreas de ciertos objetos geométricos.
Polimorfismo de métodos
public class Polimorfismo {
public static void main(String[] args) {
// Creamos una colección de Objeto_Geometrico
List<Objeto_Geometrico> objetos = new List<Objeto_Geometrico>();
// Añadimos instancias de objetos geométricos
objetos.add(new Rectangulo(2, 2));
objetos.add(new Triangulo(3, 2, Math.PI/4));
objetos.add(new Circulo(1.5));
// Calculamos el área de todos los objetos
// Se llamará en cada caso al método correspondiente a la subclase
for (Objeto_Geometrico o : objetos) {
System.out.println(o.area());
}
}
}
En este ejemplo se aprovechan las propiedades de sustituibilidad y polimorfismo. La
sustituibilidad permite crear una colección de objetos de la superclase Objeto_Geometrico, y
añadir objetos de las subclases. Además, se puede llamar al método polimórfico area() sin
preocuparnos de cuál es la subclase a que pertenece cada objeto, lo que simplifica muchísimo la
programación.
Diseño lógico de una base de datos

 Para implementar una BDOO a partir de un esquema conceptual

lo primero que hay que hacer es definir los tipos de datos, los
tipos de objetos y las operaciones de las clases en el lenguaje
de definición de datos de nuestro SGBD.

 Posteriormente, se añaden los métodos que se implementan en el

lenguaje de programación disponible.

 Vamos a partir de un esquema conceptual que represente tanto

las relaciones de asociación, como las de agregación y
especialización, sin embargo los métodos tendrán que ser
especificados por separado. A grandes rasgos la transformación
puede hacerse como sigue:
Diseño lógico de una base de datos

 Paso 1.- Crear una clase de objetos para cada entidad

del esquema. El tipo de objetos de la clase deberá
agrupar todos los atributos de la entidad por medio de
un constructor de tupla. Los atributos multivaluados se
declaran a través de un constructor de tipo conjunto, o
lista si están ordenados. Los atributos complejos se
declaran por medio de un constructor de tupla. Todos
los tipos y, sobre todo, aquellos tipos de datos que se
utilicen en varias clases se pueden definir como tipos de
datos aparte. Todas las clases deben tener una
extensión (cláusula extent) definida.
Diseño lógico de una base de datos

 Paso 2.- Aquellas clases que son subclases de

otras deberán tener una cláusula inherit para
indicarlo. Cada subclase hereda de forma
automática el tipo y las operaciones de su
superclase inmediata. Solo hay que
especificar los atributos y operaciones
específicos de la subclase.
Diseño lógico de una base de datos

Paso 3.- Para cada relación de asociación y agregación en las que participe
una clase, añadir atributos para referenciar las clases que participen en la
relación. Las referencias pueden definirse en una dirección o en ambas,
aunque suele ser más eficiente definirlas en ambas. Nosotros añadiremos
atributos con referencias a las dos clases relacionadas, excepto en las
relaciones de cardinalidad (0,1) que dependerá de cada caso a analizar. Los
atributos serán monovaluados para las relaciones de cardinalidad (1,1), y
multivaluados (atributos de tipo conjunto o lista) para los de cardinalidad
(1,n). Si una relación se representa con referencias en ambas direcciones se
debe declarar que cada referencia es la inversa de la otra (cláusula
inverse). Si hay alguna relación con atributos, hay que usar un constructor
de tupla para representarlo de la siguiente manera tuple[referencia con
cláusula inverse, atributos de la relación]. Esta tupla se incluye en el
atributo de referencia.
Diseño lógico de una base de datos

Paso 4.- Incluir métodos apropiados para cada

clase. Estos no estarán disponibles en el
esquema conceptual y se deberán agregar al
diseño de la base de datos según se necesiten.
Al final, toda clase debe incluir un método
constructor y otro destructor para sus
instancias.
Ejemplo de una base de datos

 Primero se definen dos tipos de datos.

 define data type Telefonos: set(integer);

 define data type Fecha:tuple[año:integer,
mes:integer, dia:integer];
Ejemplo de una base de datos

 Se definen los tipos de objetos que se

corresponden con las entidades del diagrama
conceptual.
define object type Persona extent Personas define object type Profesor inherit Persona extent Profesores
type type
tuple[ dni: string, tuple [ salario: real,
nombre: tuple [ nombrepila:string, rango: string,
apellido_p:string, telefono: Telefonos,
apellido_s:string], pertenece_a: Departamento inverse
direccion:tuple [ numero:integer, Departamento:miembros,
calle:string, tutoriza: set(Estudiante_Investigacion) inverse
ciudad:string],
fechanac:Fecha Estudiante_investigacion:tutor,
sexo:char] imparte: set(Asignatura) inverse Asignatura:prof]
operations operations
edad():integer; promover_profesor:boolean,
dar_aumento(porcentaje:real):boolean;
Ejemplo de una base de datos
Ejemplo de una base de datos
define object type Estudiante inherit Persona extent Estudiantes
type
tuple [ grupo: string,
estudia: Departamento inverse Departamento:alumnos,
examinado_de: set(tuple [ nota:real,
fecha:Fecha,
asignatura: Asignatura inverse Asignatura:examinados.estudiante])

]
operations
nota_media():real,
cambiar_grupo:boolean,
cambiar_carrera(nueva_carrera:Departamento):boolean;

define object type Estudiante_investigacion inherit Estudiante extent Estudiantes_inv

type
tuple [ telefono:Telefonos,
graduación: list(tuple [ colegio:string,
grado:string,
año:integer]),
tutor: Profesor inverse Profesor:tutoriza];
Ejemplo de una base de datos
define object type Departamento extent Departamentos
type
tuple [ nombre: string,
oficinas: set(string),
telefonos: Telefonos,
miembros: set(Profesor) inverse Profesor:pertenece_a,
alumnos: set(Estudiante) inverse Estudiante:estudia,
director: Profesor,
cursos: set(Curso) inverse Curso:ofrecido_por]
operations
añadir_profesor(p:Profesor),
añadir_a_carrera(e:Estudiante),
quitar_de_carrera(e:Estudiante):boolean;

define object type Curso extent Cursos

type
tuple [ nombre: string,
codigo: string,
descripcion: string,
asignaturas: set(Asignatura) inverse Asignatura:curso,
ofrecido_por: Departamento inverse Departamento:cursos]
operations
añadir_asignatura(a:Asignatura);
Ejemplo de una base de datos
define object type Asignatura extent Asignaturas
type
tuple [ cod_asig: integer,
año: integer,
examinados:set(tuple [ nota:real,
fecha:Fecha,
estudiante:Estudiante inverse
Estudiante:examinado_de.asignatura])
curso: Curso inverse Curso:asignaturas,
profesores: set(Profesor) inverse Profesor:imparte ]
operations
cambiar_notas(e:Estudiante, n:integer);
Implementación para el método edad()

method body edad:integer in class Persona

{
int a; Date d;
d=today();
a=d->año - self->fechanac->año;
if (d->mes < self->fechanac->mes) ||
(( d->mes == self->fechanac->mes) && (d->dia < self->fechanac->dia)) --a
}
 GRACIAS
Bases de datos avanzadas
María José Aramburu Cabo
Ismael Sanz Blasco
Data Warehouse (Almacen de Datos)

Información de las diferentes fuentes.

Es donde se concentran todos los datos con un
diseño especial para explotar la información.
Se compone por fragmentos derivados los
cuales se conocen como Data Marts.

Modelo de estrella
Data Marts
Modelo de snowflake
Data Warehouse (Almacen de Datos)

Generación de Reportes

Análisis de información
Explotar la información
Tableros de control

Minería de datos

Enfocado a toda la empresa Preparado para carga masiva de datos

Su diseño debe ajustarse a los cambios como sea posible
Data Warehouse (Almacen de Datos)

- Para tener un mayor conocimiento del negocio

- Para tomar mejores decisiones y en un tiempo menor.

- Para mejorar y ser más efectivos.

- Para no perder distancia con la competencia.

- En definitiva para aumentar los ingresos.

Data Warehouse
Data Warehouse
Arquitectura y diseño para un
Datawarehouse

Puede tener diferentes estructuras en

diferentes implementaciones.
ODS ( Operational Data Múltiples Data Marts
Store )
Pequeño numero de fuentes Docenas de fuentes de datos
de datos

Es mas razonable presentar las capas en lugar

de discutir sobre un tema específico.
Capas de un Data warehouse

Capa de fuentes de datos:

Esta representa las diferentes fuentes de datos que alimentan
los datos del datawarehouse. La fuente de datos puede estar
en cualquier formato: archivo de texto plano, base de datos
relacional, otros tipos de base de datos, archivo Excel, etc.
Todos estos pueden actuar como fuente de datos. Además,
los tipos de datos pueden ser muy variados:
 Datos de operaciones, como datos de ventas, datos de recursos
humanos, datos de productos, datos de inventario, datos de
marketing y datos de sistemas.
 Logs de un servidor web, con datos de navegación de los
usuarios.
 Datos internos de investigación de mercado.
 Datos de terceros, como datos del censo, datos demográficos o
datos de encuestas.
Capas de un Data warehouse

Capa de extracción de datos:

Los datos se extraen de las fuentes de datos y se llevan al
sistema datawarehouse. Es probable que en esta capa se
limpien algunos datos mínimos, pero no es previsible que
haya una transformación de datos importante.

Área de pruebas:
Aquí es donde los datos son depurados y transformados en
un datamart y datawarehouse. Tener un área común
facilita el proceso y la integración posterior de los datos.
Capas de un Data warehouse

Capa ETL:
Aquí es donde los datos obtienen su inteligencia
ya que se aplica la lógica para transformar los
datos de una naturaleza transaccional a una
naturaleza analítica. En esta capa es también
donde se limpian los datos. La fase de diseño ETL
es frecuentemente la fase que más se demora en
un proyecto de datawarehouse y habitualmente se
utiliza una herramienta ETL en esta capa.
Capas de un Data warehouse

Capa de almacenamiento de datos:

Aquí es dónde se colocan los datos
transformados y limpios. Basándose en el
alcance y la funcionalidad se pueden encontrar
tres tipos de entidades: datawarehouse, data
mart y almacén de datos operacional (ODS). En
cualquier sistema puedes encontrar sólo uno de
los 3, 2 de los 3, o los tres tipos juntos.
Capas de un Data warehouse

Capa lógica de datos:

Aquí es donde se almacenan las reglas de
negocio. Estas reglas de negocio no afectan a
las reglas de transformación de datos, pero
afectan a lo que luego puedes ver en los
informes.
Capas de un Data warehouse

Capa de presentación de datos:

Se refiere a la información que llega a los usuarios.
Esto puede ser en forma de un informe tabular o
gráfico a través de un navegador, un informe
enviado por email que se genera automáticamente
y se envia a diario, una alerta que advierte a los
usuarios acerca de excepciones, etc. Usualmente
en esta capa se utiliza una herramienta OLAP y una
herramienta de generación de informes.
Capas de un Data warehouse

Capa de metadatos:
Aquí es donde la información sobre los datos
almacenados en el datawarehouse es almacenada.
Un modelo de datos lógico sería un ejemplo de
algo que está en esta capa de metadatos.
Frecuentemente se utiliza una herramienta de
metadatos para administrar los metadatos.
Capas de un Data warehouse

Capa de operaciones del sistema:

Esta capa incluye información sobre cómo está
funcionando el sistema de datawarehouse,
cuál es el estado de trabajo ETL, cuál es el
rendimiento del sistema y el historial de acceso
de los usuarios.
Diseño de un data warehouse

En el diseño de un data warehouse hay que

partir de una serie de características:

 Administra grandes cantidades de

información
 Guarda histórico de datos
 Condensa y agrega información
 Integra y asocia información de varias fuentes
Diseño de un data warehouse

Para ello, hay que cambiar de los modelos E/R usuales en los
operacionales, ya que de tipo de modelo de dato es complejo
obtener datos acumulados e históricos. Usualmente se realizan una
serie de procesos ETL, para obtener un modelo multidimensional y
así poder realizar consultas analíticas de manera más optima.
Normalmente las consultas de análisis, se realizan sobre un hecho
esencial a partir de una serie de parámetros. Un ejemplo sería:
 Las ventas con una serie de variables como tiempo, localización y
producto.
 Número de ventas en un periodo determinado
 Evolución de las ventas
 Productos más vendidos en una zona determinada
Data Marts

 Subconjunto de datos dentro de un data

warehouse que contienen información sobre
un áreas especifica de la empresa o negocio
por ejemplo por departamentos por funciones
se pueden definir también como pequeños
data warehouse enfocados en un tema.
 Son consultados mediante herramientas
OLAP para ser analizados con el resto de los
data marts
Diseño de un data warehouse

 Este tipo de modelo de datos consta

principalmente de dos tipos de elementos:
 DIMENSIONES: Representan factores por lo que
se analiza un determinado área del negocio. Son
pequeñas y usualmente están desnormalizadas.
 HECHOS: Son el objeto de los análisis y están
relacionados con las dimensiones. Son tablas muy
grandes y suelen estar desnormalizadas. A
menudo incluyen diferentes agregaciones como
máximo, mínimo, media, …
Metodología Button Up
 Ralph Kimball propone una metodología Button up que
es de lo particular a lo general que es la que vamos a ver
a continuación.
 Esta es una visión de abajo hacia arriba debido a que los
data marts se crean primero.
 Es un diseño modular donde se crean los Data Marts
por cada departamento o unidad de negocio con sus
análisis y operaciones independientes, se construye un
modelo dimensional de los datos y el data warehouse
se completa por medio de un bus que integra los
distintos data Marts como si fueran uno solo.
Diseño de un data warehouse (Tabla de
hechos)
 Los Hechos son el centro del modelo dimensional, estas
contienen mediciones cuantitativas del negocio es decir
valores numéricos o aditivos a los que se puede aplicar
sumatorias y promedios que son el resultado de análisis
que hagamos a los procesos de negocios.
 Además estas tablas no tienen una llave primaria sino
que se encuentran formadas por las llaves foráneas a
sus dimensiones, completando así una relación n,n es
decir de muchos a muchos dependiendo de sus
dimensiones.
Diseño de un data warehouse (Tabla de
Dimensiones)
 Las Dimensiones son las tablas que acompañan a
los hechos, de donde se obtienen los datos, estas
son las que tienen información extraída de los
sistemas transaccionales, sus llaves primarias
definen la integridad referencial del data
warehouse es decir cada una de estas dimensiones
tiene una llave primaria única que se utiliza para
relacionarse entre los diferentes hechos, además
contienen campos que funcionan como filtros y
agrupadores para aplicar funciones de agregación.
Ejemplo
Obtener los valores cuantificables de
cada subdiagrama
 Los valores cuantificables consisten en datos que
podemos extraer de cada una de las relaciones por
ejemplo:
 En el proceso de ENVÍO de productos a clientes
(Tiempo de Envío, Costo de Envío, Pesos de Productos)
 En el proceso de PROVEE (Ganancias por productos,
Cantidades de almacenaje, tiempos de manufactura)
 En el proceso de VENDE (Ganancias Netas, Porcentajes
de descuentos, Ventas por Localidad)
 Los valores cuantificables de cada proceso son los
HECHOS para formar los esquemas en estrella.
 Modelado de datos
Estas tablas forman un modelo
en estrella y es un diagrama por
cada proceso de negocio
(un conjunto de actividades
definidas dentro de un empresa
en un tema específico).
Carga de datos en el Data Warehouse

 En esta etapa se debe llevar a cabo el proceso

ETL (Extracción, transformación y carga) que
permita leer las tablas de los sistemas
transaccionales para que puedan ser
cargadas en las tablas de dimensiones. En
este proceso se deben considerar todas las
restricciones y lógica exclusiva y necesaria
para almacenar los datos.
Programa de carga de las tablas de
dimensiones y de hechos:
Herramientas
Desarrollo de cubo OLAP

OLAP = On-Line Analytical Processing

= Procesamiento analítico en línea. Es el método más
utilizado para analizar y evaluar los datos de la data
warehouse en línea. Permite a los gerentes y analistas
obtener una idea de la información . Para analizar los
datos se utilizan un conjunto de operaciones. Estas
operaciones se realizan mucho más fácilmente con
software o programas OLAP, que suelen incluir los
programas data warehouse. Para los programas OLAP
un tiempo de respuesta es una medida de su eficacia.
Desarrollo de cubo OLAP

Los cubos OLAP son las herramientas que se

basan en la capacidad de analizar y explorar los
datos, nos proporcionan un análisis interactivo
por las diferentes dimensiones de los datos (por
ejemplo, tiempo, producto, cliente, criterios
geográficos, etc.) y por los diferentes niveles de
detalle. Esto se puede cargar incluso en Excel
2010.
Ejemplo
Herramienta KPI
 Si estás dentro del entorno del marketing y las ventas
no es la primera vez que escuchas hablar del término
KPI. Pero por si acaso, vamos a hacer un repaso del
significado de estas tres siglas en inglés que se refieren a
Key Performance Indicator, lo que en español podríamos
entender como el indicador clave de rendimiento. Este
concepto es tan amplio como las formas de aplicación
que puede tener esta métrica, por eso es importante
hacer una clasificación básica para ver que puedas
entenderlo mejor y para que encuentres cuál es la mejor
opción para tus mediciones.
Bussines Intelligence

 Es el proceso de transformación de datos en

información y la transformación a través del
descubrimiento de la información en
conocimiento
 Una vez que una empresa gana un margen
competitivo basado en conocimiento, se
vuelve más fácil mantener su ventaja y por
ende para la competencia es más difícil
alcanzarla.
Elementos.
 Datawarehouse
Su funcionalidad consiste en almacenar información de
distintas fuentes internas o externas para realizar
operaciones sobre las mismas y así obtener conocimiento
valioso sobre el negocio en un proceso llamado bussines
inteligence.

 Datamarts
 OLAP
 Datamining
 KPI's
Ejercicio.

 Establecer 2 áreas de aplicación, justificando la

razón para un Data Warehouse.

 Comprender el concepto de Business Intelligence

y sus componentes

 Identificar y explicar la importancia de la

aplicación de Business Intelligence en las
organizaciones y areas de aplicación antes
mencionadas.