Clase_6_Conceptos_B_sicos_BI_DWH_DM

Vista previa del material en texto

1 
ANTECEDENTES Y MARCO TEORICO: 
Antecedentes de las carreras informáticas en Argentina y en la UNJu 
Para llegar a comprender la situación actual de la carrera Licenciatura en Sistemas de la 
Facultad de Ingeniería, ámbito en el cual se desarrollan los temas vistos en el actual 
Proyecto de Trabajo Final de Memoria Docente, se plantea una línea de tiempo con los 
principales antecedentes de computación, de las carreras informáticas en el país y en la 
UNJu (Universidad Nacional de Jujuy): 
 1.955: El Doctor Manuel Sadosky se incorpora a la Facultad de Ciencias Exactas y 
Naturales como profesor del Departamento de Matemática de la UBA (Universidad 
de Buenos Aires) y comienza a plantearse el desarrollo de la matemática aplicada 
en el país (Jacovskis, 2.004). 
 1.956: el Ingeniero Jorge Santos en Bahía Blanca de la Universidad Nacional del 
Sur constituye el Seminario de Computadores con alumnos avanzados de la 
carrera de Ingeniero Electricista 
 1957: la UBA (Universidad de Buenos Aires) comienza la construcción de su nuevo 
edificio, el Pabellón I, en la Ciudad Universitaria, en donde el doctor Manuel 
Sadosky plantea obtener una computadora para la Facultad, que sirviera tanto para 
tareas científicas como servicio para diversos usuarios, y crear un Instituto de 
Matemática Aplicada, que sirva de base institucional al uso de la computadora, 
aprobándose un año después el presupuesto de dicho Pabellón gracias al Doctor 
Rolando García Vicepresidente del CONICET 
 1.960: comienza a funcionar el primer Instituto de Cálculo de la UBA siendo 
aprobado por el Consejo Superior en 1962 y su director es el Dr. Manuel Sadosky 
 1.961: se incorpora la primer computadora al Pabellón I, la misma es utilizada 
hasta 1.966 (Czemerinski y Jacovkis: 2.012) 
 1.961: comienza el proyecto CEUNS (Computadora Electrónica de la Universidad 
Nacional del Sur) dirigido por el Ing. Jorge Santos (Carnota y Rodriguez: 2.010) 
cuyo desafío es diseñar y construir la primer computadora en Argentina 
 1.962: se crea la primera Carrera de “Computador Científico”, la cual es aprobada 
por el Consejo Directivo de la Facultad de Ingeniería de la UBA en dicho año, y por 
el Consejo Superior en 1963. Tiene menor duración que las tradicionales 
licenciaturas, y su objetivo es formar "auxiliares de científicos": programadores, 
analistas, etc. 
2 
 1.966: se crea la primera Carrera de “Computador Científico”, 
 En el año 1966 la Universidad Nacional de La Plata (UNLP) creo la carrera de 
Calculista Científico, en el Departamento de Matemáticas de la Facultad de 
Ciencias Exactas. Es una carrera con fuerte contenido matemático, orientada a 
incorporar la programación de aplicaciones sobre computadoras, especialmente 
dentro del ámbito científico.1 
 1.982: Creación de la licenciatura en computación en Buenos Aires. 
 A partir de estas fechas se crean innumerables carreras de grado y postgrados en 
informática a lo largo del país. 
 1.992: la Facultad de Ingeniería de la Universidad Nacional de Jujuy crea la primer 
carrera universitaria informática en Jujuy, de pregrado “Técnico Universitario en 
Informática”, posteriormente convalidada por el Ministerio de Cultura y Educación 
por Resolución Nº724/97 y del Consejo Superior Resolución de la UNJu Nº150/952 
 1.995: en la Universidad Nacional de Jujuy el Consejo Académico de la Facultad de 
Ingeniería aprueba la primer carrera universitaria informática en Jujuy de grado 
“Ingeniería en Informática” mediante Resolución CAFI Nº 151/95 y posteriormente 
convalidada por el Ministerio de Cultura y Educación por Resolución Nº722/97 y del 
Consejo Superior de la UNJu Resolución Nº204/963. En dicha Resolución del 
Ministerio de Cultura y Educación también se le otorga reconocimiento oficial a la 
carrera de pregrado Analista Programador Universitario solicitado por el Consejo 
Superior de la UNJu Resolución Nº150/95 
 2.002: por Resolución Nº5784 del Ministerio de Educación, Ciencia y Tecnología 
otorga el reconocimiento oficial y validez nacional a la carrera Licenciatura en 
Sistemas, aprobada previamente por resolución del Consejo Superior de la UNJu 
Nº 049/01. Es importante mencionar que uno de los alcances que el mismo plantea 
es “Investigar fenómenos desarrollados con los procesos de diseños conceptuales 
de sistemas, así como para valorar estrategias de búsqueda de fuentes de 
 
1
 Página de la Universidad Nacional de la Plata. Disponible en http://www.info.unlp.edu.ar/resena_historica. Accedido 
en Julio del 2.013 
2
 Resolución 724 del ministerio de cultura y educación. Disponible en 
http://repositorio.educacion.gov.ar/dspace/bitstream/handle/123456789/83297/5645.pdf?sequence=1. Accedido en Julio 
del 2.013. 
3
Resolución 722 del ministerio de cultura y educación. Disponible en 
http://repositorio.educacion.gov.ar/dspace/bitstream/handle/123456789/83294/5643.pdf?sequence=1. Accedido en Julio 
del 2.013. 
4
 Resolución Nº578 del Ministerio de Educación, Ciencia y Tecnología. Disponible en 
http://repositorio.educacion.gov.ar:8080/dspace/bitstream/handle/123456789/86065/8884.pdf?sequence=1. Accedido en 
Julio del 2.013. 
3 
información de manera de lograr comunicar en forma efectiva los resultados de la 
investigación”, ya que este plantea las bases de conceptos que luego dieron lugar 
al “Data Warehouse”. 
 2.012: la Facultad de Ingeniería de la de la UNJu acredita la carrera de Licenciatura 
en Sistemas mediante Resolución de la CONEAU Nº 1230/12, por un período de 
tres (3) años con los compromisos de desarrollar proyectos de investigación, 
incrementar la cantidad de docentes con postgrados e incrementar las 
dedicaciones de los docentes5 
 
Data Warehouse y Cubos de Información OLAP como exigencia de la CONEAU 
En el punto 3 del actual Proyecto de Trabajo Final de Memoria Docente se mencionó que 
el tema de “Data Warehouse” y Cubos de Información OLAP, son considerados como un 
punto clave que se requiere a las Facultades con Carreras Informáticas para su 
Acreditación. Esto se afirma cuando en la memoria anual del año 2.0056 solicita en los 
proyectos de acreditación que sean “tenidos en cuenta otros aspectos concernientes a 
su integración con futuros proyectos. Se detallan a continuación dos posibles vías de 
desarrollo” en donde uno de ellos menciona “la utilización de los datos enviados por las 
instituciones para discernir relaciones entre los datos y extraer conclusiones de los 
mismos a través del uso de herramientas de datawarehousing (tales como Análisis 
estadístico, consultas OLAP, etc.)”. Esto muestra a las claras las necesidades de 
incorporar dicho tema a la competencia del profesional informático. 
En el año 2.009 CONEAU7 exige como contenido mínimo específico para la acreditación 
de la carrera Licenciatura en Sistemas en el área Ingeniería de Software, Base de Datos y 
Sistemas de Información (cantidad de horas para el área 650 en total), se incorpore los 
temas de “Data Warehouse” y “Data Mining”. El autor del actual Proyecto de Trabajo Final 
es integrante de la subcomisión de autoevaluación en la acreditación de la carrera 
Ingeniería en Informática, y participe en múltiples reuniones para la acreditación de la 
Licenciatura en Sistemas de la Facultad de Ingeniería en el año 2.009 (Resolución de la 
Facultad de Ingeniería Nº159/10). En dichas reuniones los referentes nombrados por el 
señor decano con la guía de la CONEAU informan a todos los participantes los contenidos 
 
5
Resolución CONEAU Nº1230/12. Disponible en http://www.coneau.gov.ar/archivos/resoluciones/Res1230-
12E804086610.pdf. Accedido en Julio del 2.013. 
6
 Resolución CONEAU Nº657/05. Disponible en http://www.coneau.gob.ar/archivos/657.pdf. Accedido en Julio del 
2.013. 
7
 Resolución CONEAU Nº789/09. Disponible en http://www.coneau.gov.ar/archivos/Res786_09.pdf. Accedidoen Julio 
del 2.013. 
4 
mínimos específicos y las horas que debían cumplir las cátedras que incluyan “Data 
Warehouse” y “Data Mining”. 
En el año 2.010 la Facultad de Ingeniería de la Universidad Nacional de Jujuy mediante 
resolución CAFI 005/10 agrega el nuevo plan de estudios 2.010 para la carrera 
Licenciatura en Sistemas8, en el cual incorpora un 5to.año y en el mismo, la materia 
“Aplicación de Base de Datos 1” en el primer cuatrimestre, con una carga horaria semanal 
de 5 hs. y una carga horaria total de 75 hs. Dicha materia actualmente es dictada por la 
persona que escribe el actual Proyecto de Trabajo Final de Memoria Docente; tiene como 
contenido mínimo fundamental el tema de “Data Warehouse”, con todos los conceptos 
que el mismo involucra, en donde unos de los ítems principales que posee son los Cubos 
de Información OLAP y “Business Intelligence”. 
Como se mencionó antes, en el año 2.012 se acredita la carrera Licenciatura en Sistemas 
de la Facultad de Ingeniería, Universidad de Jujuy, donde uno de los puntos más 
importantes de dicha resolución de la CONEAU es que ante la falta de dichos temas en 
los planes de estudios anteriores, solicita que “con el objeto de subsanar los déficits 
detectados se agreguen al plan de transición anterior Módulos Complementarios a los 
aprobados por Resolución CAFI N° 086/11”, con lo cual, requiere, entre otras cosas la 
creación de un “Taller de Aplicación de Base de Datos” que tenga como contenido mínimo 
principal “Data Warehouse” para los planes de estudios anterior de la licenciatura 2.001 y 
2.007. 
 
Relación en Business Intelligence de Base de Datos Relacionales, Data Marts, Data 
Warehouse, Cubos de Información OLAP y ETL 
Para comprender en profundidad los diferentes conceptos que rodean a Business 
Intelligence, los cuales se detallan a continuación se muestra el Gráfico Nº1 en el cual se 
observa una primera aproximación en la relación entre Base de Datos Relaciones, Data 
marts, Data Warehouse, Cubos de Información OLAP y ETL. 
 
8
 Plan de Estudios de la carrera Licenciatura en Sistemas, aprobado por resolución CAFI 005 del 2.010. Disponible en 
http://www.fi.unju.edu.ar/component/option,com_docman/task,doc_download/gid,183/. Accedido en Julio del 2.013. 
5 
 
Gráfico Nº1: Relación en Business Intelligence de 
Base de Datos Relacionales, Data marts, 
Data Warehouse, Cubos de Información OLAP y ETL 
 
 
Base de Datos (BD) 
Diversas son las definiciones que mencionan distintos autores sobre Base de Datos: 
 Date (2.001: 10) sostiene que una BD es un conjunto de datos persistentes, que se 
emplean en los sistemas informáticos de alguna organización. 
 Elmasri y Navathe (2.007: 4) y Silberschatz, Korth y Sudarshan (2.002: 1) 
mencionan definiciones similares al afirma que las BD están formadas por una 
colección de datos, que se encuentran con una relación lógica, y que al mismo 
tiempo necesitan de Sistemas de Información para acceder a ellos. 
 
Para todos estos autores este conjunto o colección de datos es tan ampliamente usado 
por todas las organizaciones de la sociedad que se pierde noción de la importancia 
significativa que tienen dentro de cada una de ellas; se pueden ver en todos aquellos 
lugares en donde se necesite almacenar información, desde las principales instituciones 
modernas que conforman la sociedad tales como hospitales, bancos, universidades, etc 
hasta las más pequeñas como un kiosco o un almacén. Todas requieren almacenar 
registros de la información que se procesan dentro de ella. Es impensado creer que una 
institución como un Hospital puede existir en la actualidad sin llevar registros de sus 
pacientes, tratamientos o remedios. O que un banco puede realizar cualquier operación 
6 
crediticia sin conocer fehacientemente la situación financiera de sus clientes. A pesar de 
lo expresado en general no se es consciente de la gran importancia que tienen las BD en 
la vida diaria. Por ejemplo, sin ellas las empresas telefónicas no podrían registrar las 
llamadas que se realizan a diario y por lo tanto no habría comunicaciones, o las compras 
que se realizan tan naturalmente en un supermercado no existirían como tales. El mismo 
internet que se usa a diario no podría almacenar información alguna y dejaría de existir 
como tal. 
Conjuntamente con la BD debe existir un software de aplicación para el usuario (tal como 
se mencionó anteriormente), del tipo Cliente-Servidor que permita acceder a ellas 
desarrollado tanto en ambientes de escritorios como en ambientes web. 
 
Base de Datos Relacionales 
Las Bases de Datos Relacionales son BD que cumplen con un modelo bien formado de 
datos, lo que implica cumplir con aspectos estructurales, de integridad y de manipulación 
que forman un tipo de relación especial, con cierto vínculo entre las diferentes tablas de 
información que forman las BD (Date, 2.001: 59-82), tal como se puede ver en el Gráfico 
Nº2. 
 
Gráfico Nº2: Caso de una Base de Datos Relacional de Ventas 
En dicho gráfico se observan los componentes principales en los que se basa el modelo 
relacional: tabla, fila, columna y relaciones. Estos componentes se encuentran 
especialmente desarrollados en el libro de Elmasri y Navathe (2.007: 123-144)) donde se 
hace fuerte hincapié en las restricciones que se le imponen a la Base de Datos Relacional 
para ser considerada como tal, distinguiendo claramente los conceptos de Dominio, 
Atributos, Tuplas o Registros y Relaciones. 
7 
 
Este modelo relacional se basa en una lógica de predicados y teoría de conjunto cuyos 
principios se postularon en 1970 por Edgar Frank Codd y que a partir de esa fecha se ha 
convertido en el estándar usado en BD (Silberschatz et al., 2002: 1-3). Si bien existen 
antes otros modelos para el manejo de datos como el Modelo Jerárquico y el de Red, los 
mismos tienen innumerables inconvenientes que se superaron con el Modelo Relacional. 
Actualmente el modelo que está empezando a tener auge es el Modelo Orientado a 
Objetos, el cual puede ser llegado a considerar como una extensión del Modelo 
Relacional, ya que además de las características definidas por este incorpora los 
conceptos de Objetos, Clases y Herencia, permitiendo que unos objetos se construyan a 
partir de otros objetos con un comportamiento específico. En la actualidad el Modelo 
imperante en gran parte de las BD del mundo sigue siendo el Relacional. 
 
Business Intelligence (BI) 
Laudon y Laudon (2.008: 12-19) afirman que “muchos gerentes operan en un banco de 
niebla en relación con la información, ya que nunca tienen la información correcta en el 
momento adecuado para tomar una decisión informada. Por el contrario, se apoyan en 
pronósticos, buenos deseos y la suerte”, esto lo dicen para remarcar la necesidad que 
existe en una toma de decisiones gerencial mejorada, en obtener una ventaja competitiva 
en relación con sus competidores y sobrevivir en el competitivo mundo actual. Remarcan 
las características que deben satisfacer los sistemas de información gerenciales. 
Edison Medina la Plata (2009:2-3) define BI o Inteligencia de Negocios como “el conjunto 
de estrategias y herramientas enfocadas a la administración y creación de conocimiento 
mediante el análisis de datos existentes en una organización” es decir que la misma 
organización se gestiona en base a los registros que ella misma genera a diario. Se debe 
tener en cuenta que la información de una organización puede clasificarse en 
Operacional, Táctica y Estratégica según el usuario que la utilice tal cual lo muestra el 
Gráfico Nº3: 
8 
 
Gráfico Nº3: Tipos de Información y Usuarios que la emplean 
Los sistemas de BI toman los datos diarios registrados por los Sistemas Operacionales y 
los convierte en información valiosa usada en los niveles tácticos y estratégicos. Es muy 
difícil que esta transformación que sea realizada por los Sistemasde Información (SI) 
tradicionales por las siguientes razones (Sinnexus, 2007): 
 Gran rigidez a la hora de extraer datos: porque el usuario utiliza los informes ya 
definidos 
 Necesidad de conocimientos técnicos: ya que la generación de nuevos informes 
necesita de personal técnico 
 Largos tiempos de respuesta: porque consultas complejas requieren la unión de 
grandes tablas complejas 
 Deterioro en el rendimiento del SI: debido a que las consultas antes mencionadas 
pueden causar grandes degradaciones del sistema 
 Falta de integración que implica islas de datos: porque por lo general las 
instituciones trabajan sus base de datos sin estar integradas 
 Datos erróneos, obsoletos o incompletos: por la calidad de los datos de la 
organización 
 Problemas para adecuar la información al cargo del usuario: porque la información 
se debe adecuar al usuario según la posición que el mismo ocupe en la 
organización 
 Ausencia de información histórica: en los sistemas operacionales se trabaja con la 
información diaria, no permitiéndose comparar con la de años anteriores 
9 
Es por ello que las BI se basan en la integración y universalización de la información, no 
solo de la información que se genera en cada sector o departamento del mismo sino en 
toda la organización en su conjunto. 
Existen una serie de factores que se deben cumplir para garantizar el éxito de las BI 
(Medina la Plata, 2009:6-7): 
 Apoyo de la Gerencia: sin el soporte del personal directivo o de la/s persona/s que 
toman las decisiones en la organización el BI está destinado a fracasar 
 Compromiso de los usuarios: hay usuarios que son claves para el proyecto, sin 
ellos no se puede recopilar la información necesaria 
 Metodología de la Implementación: los primeros proyectos de BI fracasaron por no 
contar con una metodología que defina claramente los pasos que a seguir, porque 
se intenta en muchos casos realizar la implementación de forma similar a la de los 
sistemas de información tradicionales 
 Selección de la Herramienta analítica: existen en la actualidad diferentes 
herramientas que facilitan el análisis gerencial y directivo, cada una con sus 
características propias, es por ello que se debe seleccionar el más adecuado para 
el proyecto de estudio. 
 Rapidez de Implementación: el realizar un proyecto de BI, si su implementación 
demora una excesiva cantidad de tiempo hará fracasar al mismo. Los cambios que 
se producen en la organización obligan a que el sistema que se desarrolle para la 
toma de decisión se realice con la mayor celeridad posible 
 Experiencia: realizar un proyecto de este tipo necesita de profesionales con 
experiencia en BI que garanticen el mejor aprovechamiento de los recursos 
disponibles 
También existen una serie de errores comunes que se realizan en la implementación de 
las BI y que se deben evitar (Medina la Plata, 2012:2-6): 
 Enfoque netamente técnico: implementar una solución de BI no es solamente 
generar un nuevo repositorio de datos (Data Warehouse o Data Smart), con 
información más limpia y preparada; implica además sumar un valor agregado que 
se obtiene de un estudio de las necesidades de la gestión de la organización 
 Mala selección del equipo de trabajo o de la tecnología que se emplee: ya sea que 
el proyecto de BI se desarrolle en forma interna o por una empresa externa, el 
mismo debe contar con expertos en el tema, no basta con que sean expertos en 
10 
soluciones transaccionales sino que deben serlo en soluciones de BI. La elección 
de la tecnología que se utilice también es clave ya que han aparecido varias y la 
tecnología elegida debe cubrir las necesidades globales de la organización y no 
solamente la de un departamento o sector en particular 
 Mala calidad de datos: si el origen del cual se obtienen los datos no tienen la 
calidad suficiente el proyecto de BI se verá comprometido, por lo cual al inicio del 
mismo se debe analizar este problema y trabajar en atenuarlos 
 Falta de Planificación de la iniciativa de BI: antes de empezar con el proyecto de BI 
se debe analizar y planificar cuales son las áreas de la empresa que demandan 
este tipo de iniciativa, cual es la tecnología a usar, cuales son las necesidades de 
información, las funcionalidades que se solicitan y la calidad de los datos existentes 
 Presupuesto inadecuado: una iniciativa de BI demanda un adecuado cálculo de los 
costos que el mismo involucra: licencias, infraestructura tecnológica, consultoría, 
ampliación de requerimientos, etc 
 Mala selección de herramientas: existen muchas herramientas a utilizar para BI, es 
por ello que se debe elegir cuidadosamente la que mejor se adapta al proyecto en 
cuestión 
 No propiciar el cambio: las variaciones que implica BI debe atender a las 
necesidades de gestión, propiciando e impulsando cambios en la organización 
centralizando la información en BI, alineando las expectativas en una estrategia de 
negocios, fortaleciendo los equipos técnicos, mostrando además a los usuarios del 
negocio las ventajas del BI y generando proyectos que sean dinámicos, con un 
área dedicada al soporte de estas soluciones 
 
Data Warehouse 
El mismo Edgar Codd afirma que las Base de Datos Relacionales no son suficientes para 
trabajar en BI, es por ello que se comienza a hablar de Data Warehouse (DWH) con dos 
importantes autores que escriben libros sobre este tema (considerados como los pilares 
del DWH) Ralph Kimball y William Inmon, con muchos puntos en común pero con 
filosofías muy distintas a la hora de diseñar la estrategia de datos. 
William H. Inmon (al cual también se lo conoce en mucha bibliografía como Bill Inmon y el 
padre del DWH), acuñó el término de Data WareHouse en 1.992 en su libro “Building the 
11 
Data Warehouse” como aplicaciones para la toma de decisiones, afirmando que el mismo 
es un almacén de datos con ciertas características (Inmon, 2.005: 29-33): 
 Orientado al sujeto: Los datos de la BD están organizados de manera que todos los 
elementos de datos relativos al mismo evento u objeto del mundo real quedan 
unidos entre sí 
 Integración: esta característica refiere al hecho de que la misma se obtiene a partir 
de diferentes Base de Datos Operacionales, las cuales pueden no tener siempre la 
misma estructura y encontrarse sobre distintos motores de BD (SQL Server, 
Oracle, MySql, PostgreSQL, etc) 
 De Tiempo Variante: en el ambiente operacional la información solicitada es 
obtenida en el momento en el que se realizó el requerimiento, mientras que en una 
Base de Datos DWH el almacenamiento es usado como un depósito en el que el 
horizonte de tiempo de la información obtenida, ronda de 5 a 10 años, lo cual 
implica además que la información almacenada no puede sufrir modificaciones, 
como en cambio si lo hacen continuamente las Base de Datos Operacionales 
 No volátil: en una Base de Datos Operacional la información cambia o se actualiza 
continuamente en tiempo real, a diferencia de una Base de Datos DWH en la cual 
la información una vez cargada no sufre modificaciones 
Inmon utiliza un enfoque Top-down o ir de arriba hacia abajo, en donde la información 
debe estar en los máximos niveles de detalle, los Data marts (concepto que se explicará 
en los siguientes párrafos), son tratados como subconjuntos del DWH. Es decir que lo 
primero a la hora de desarrollar el DWH es establecer una estructura de datos en 3FN 
(tercera forma normal), perfectamente normalizada y limpia. Los datos se insertan en esta 
estructura, siendo depurados antes de pasar a la estructura normalizada del DWH. 
A partir de esa estructura, se pueden establecer una serie de Data marts que agrupen de 
una forma más lógica (y si se quiere multidimensional) la información del DWH principal. 
A continuación se muestra el gráfico Nº4 con el diseño Top-down planteado por Inmon 
 
Gráfico Nº4 Diseño Top-down aplicando Inmon 
12El otro gran autor de DWH es Ralph Kimball (1.996: 310) quien afirma que el DWH es “a 
copy of transaction data specifically structured for query and analysis” o “una copia de las 
transacciones de datos específicamente estructurada para la consulta y el análisis”, 
también menciona que un DWH no es más que “la unión de todos los Data marts de una 
entidad”. Por lo tanto lo que este autor plantea a la hora de diseñar un DWH es que la 
metodología que se emplee sea la ascendente o bottom-up o ir de abajo a arriba, es decir 
que las partes individuales se diseñan con detalle y luego se enlazan para formar 
componentes más grandes, que a su vez se enlazan hasta que se forma el sistema 
completo. A continuación se muestra el gráfico Nº5 con el diseño Bottom-up de Kimball 
 
Gráfico Nº5 Diseño Bottom-up aplicando Kimball 
 
Kimball parte de los datos y procesos existentes y modela el DWH para que se adapte a 
ellos, tomando como premisas la eficiencia en tiempo y la representación natural de datos 
a costa de la normalización. El cálculo de los datos sirve para que la toma de decisiones 
sea rápida, por lo que estructura los datos del DWH sigue patrones dimensionales. Esto 
mejora el rendimiento a la hora de realizar consultas y organiza los datos de una forma 
más intuitiva y natural para los usuarios. 
 
Roberto Espinosa el cual es un escritor muy reconocido sobre BI afirma en su artículo 
“Kimball vs Inmon. Ampliación de conceptos del Modelado Dimensional” (2.010) que “el 
enfoque Inmon es más apropiado para sistemas complejos, donde además queremos 
asegurar su perdurabilidad y consistencia aunque cambien los procesos de negocio en la 
organización. Pero para pequeños proyectos, donde además queremos asegurar la 
usabilidad de los usuarios con un sistema fácil de entender y el rápido desarrollo de la 
solución, el enfoque Kimball es más apropiado”, es decir que según sean las 
características del proyecto de BI que se encare conviene seguir con el enfoque de Inmon 
o el de Kimball. 
13 
 
Data marts (DM) 
Inmon, Imhoff y Sousa definen DM como as “a subset of a data warehouse that has been 
customized to fit the needs of a department" (1.998, 70) o sea un subconjunto de un DW 
que se ha hecho a la medida de un departamento. Lo que afirma es que un DM es un 
subconjunto de los datos del DWH con el objetivo de responder a un determinado análisis, 
función o necesidad y con una población de usuarios específica. 
Kimball también trabaja con DM, pero para el se define por procesos y no por 
departamentos. También insiste en que las dimensiones deben ser 
conformadas/compartidas entre los distintos DM, a lo que llama “bus architecture”. 
Un DM puede ser dependiente o independiente de un DWH, tal cual puede observarse en 
el Gráfico Nº6 que se muestra a continuación, lo cual depende si el DM se encuentra en el 
mismo equipo del DWH (imagen de la derecha) o si el DM está en otro equipo 
independiente del DWH (imagen de la izquierda) (Inmon, 2.005: 384-385): 
 
Gráfico Nº6 DM independiente de un DWH DM dependiente de un DWH 
Dependiendo el tipo de proyecto esta independencia puede ser o no conveniente para 
algunos casos y para otros no. 
Entonces la principal diferencia entre un DM y un DWH es el alcance. El DM está pensado 
para cubrir las necesidades de un grupo de trabajo o de un determinado departamento 
dentro de la organización, mientras que el ámbito del DWH es la organización en su 
conjunto o sea que trabajan con los datos corporativos comunes. 
 
 
14 
ETL 
ETL son las siglas en ingles de Extract, Transform y Load o sea extracción, 
transformación y carga. Kimball y Ross (2.002, 401) define ETL como el “conjunto de 
procesos mediante los cuales los datos origen son preparados para el DWH … Consiste 
en extraer los datos operacionales de una aplicación de origen , transformarlo, cargarlo e 
indexarlo, asegurando su alta calidad y publicación”. 
Inmon (2.005, 18) por su parte menciona la grandes ventajas que tiene el uso del ETL el 
cual “puede automatizar gran parte del tedioso proceso de la integración de datos 
complejos. Además, este proceso de integración se debe realizar sólo una vez”. 
Adzic, Fiore y Sisto (2.006, 89-90) señalan claramente el ambiente donde trabaja ETL al 
afirmar que se lleva a cabo en “una amplia zona entre el origen de datos y una base de 
datos de destino en el sistema de gestión (DWH); en el medio, están todos las 
condiciones necesarias para llevar y mantener los datos históricos en una forma 
adecuada para el análisis”. A continuación en el Gráfico Nº7 puede observarse el 
escenario con el que se trabaja en ETL: 
Gráfico Nº7 Escenario de ETL 
 
Espinosa Roberto cuando escribe en DATAPRIX (2.010) afirma que ETL es el proceso 
que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y 
limpiarlos, cargándolos en otra BD, DM, o DWH para analizar, o en otro sistema 
operacional para apoyar el BI. Este proceso ETL se caracteriza por: 
 Extracción: realizar un proceso de extracción con un software ETL consiste en 
EXTRAER los datos de los sistemas de origen, los cuales generalmente provienen 
de diferentes sistemas de origen que pueden tener formatos distintos (Base de 
Datos Relacionales, ficheros planos, Base de Datos no Relacionales, etc). Esta 
fase de extracción convierte los datos a un formato diseñado para el proceso de 
transformación, analizando los mismos y rechazándolos si correspondiera. Este 
proceso debe ser diseñado cuidadosamente ya que debido al volumen de datos 
15 
puede ocasionar que el sistema operacional tenga una sobrecarga y los usuarios 
del personal operativo no puedan trabajar, es por ello que generalmente se 
programa en horarios de poca o ninguna actividad 
 Transformación: transformar los datos usando herramientas ETL significa aplicar 
funciones a los datos extraídos con el fin de convertirlos a un formato útil para su 
carga, estas funciones también se les llama reglas de negocio, ya que describe las 
definiciones de la información en la organización. Esta transformación puede incluir 
manipulaciones sobre las mismas que pueden ser de tipos variados tales como 
juntar columnas o desagregarlas, aplicar funciones de agrupamiento (realizar 
conteos, sumarizaciones, promedios, etc), generación de claves, unificación de 
múltiples fuentes, transformar valores de los campos, etc. 
 Carga: en este proceso los datos ya transformados de la etapa anterior se cargan 
en la nueva Base de Datos del DWH. Dependiendo de cómo se diseñe esta fase se 
puede sobreescribir la información antigua o agregar solamente los nuevos 
registros. Existen incluso reglamentaciones legales de esta fase, ya que la 
modificación de registros ya existentes no es permitida porque las decisiones 
gerenciales se basan en las mismas y una modificación en ella puede provocar 
cambios en el rumbo de la organización. Hay dos formas de desarrollar este 
proceso, por “acumulación simple” que consiste en realizar funciones de 
agrupamiento y guardar esos resultados en la Base de Datos del DWH o realizar 
un “rolling” en donde se opta por mantener un cierto nivel de granularidad, 
manteniendo información resumida por niveles jerárquicos en una o más 
dimensiones del DWH. 
Los procesos ETL son generalmente complejos y deben ser planificados cuidadosamente 
para evitar inconvenientes. Se debe estudiar la calidad de datos existente en las Base de 
Datos Operacionales y las diferentes herramientas existentes en el mercado, tanto 
Software Propietario como Software Libre (u Open Source). Las herramientas más 
populares en el momento en el que se escribe el actual Proyecto Final de Memoria 
Docente son: 
 IBM Webspher 
 Pentaho Data Integration (Kettle ETL) (Herramienta Open Source BI) 
 SAS ETL Studio 
 Oracle Warehouse Builder 
16 
 Informatica PowerCenter 
 Cognos Decisionstream Ab Initio 
 BusinessObjects Data Integrator (BODI) 
 Microsoft SQL Server Integration Services (SSIS) 
 
Cubos de Información OLAP 
Una de las herramientas más importantes a la hora de trabajar con “Data Warehouse” es 
el llamado Cubo de Información OLAP, el término original OLAP (Date, 2.001:715) 
("Procesamiento Analítico en Línea") fue acuñado en el artículo “Providing OLAP (Online 
Analytic Processing) to User-Analysts: An IT Mandate” escrito por el mismo Edgar Codd 
para Arbor Software Corp. en 1993 y puede ser definido como "el proceso interactivo de 
crear, mantener, analizar y elaborar informes sobre datos". Es usual asumir que los datos 
en cuestión son percibidos y manejados como si estuvieran almacenados en un "arreglo 
multidimensional", a diferencia del modelo relacional que plantea las tablas con filas y 
columnas. 
Hurtado y Gutierrez (2.006, 37) define que “un cubo de datos es el conjunto de todas las 
posibles vistas del cubo definidas sobre una lista de dimensiones, una tabla base y 
medidas agregación”, aquí también se observa que aparecen conceptos nuevos como 
dimensiones y medidas de agregación, que se verán en detalle a continuación. 
Bernabeu (2.010: 33) simplifica este concepto afirmando que un Cubo de Datos 
“representa o convierte los datos planos que se encuentran en filas y columnas, en una 
matriz de N dimensiones”. Es decir, que la información deja de considerarse en dos 
dimensiones, tal cual sería el caso de una planilla Excel, y pasa a tener N dimensiones de 
análisis, en donde la cantidad de dimensiones depende del estudio del problema en 
cuestión. 
La definición clásica que menciona Roberto Espinosa en “El Rincón del BI” (2.009) es que 
“son las herramientas que se basan en la capacidad de analizar y explorar por los datos”, 
y que tiene un enfoque, el cual a través de las herramientas OLAP de reportes, permite 
analizar el “¿por qué está pasando?” a través de navegar y profundizar en los datos y ya 
no solamente observar el “¿qué está pasando?” tradicional. 
Estas herramientas OLAP permite hacer un análisis interactivo de las dimensiones e 
indicadores (estos conceptos también se explicarán a continuación), permitiendo 
17 
“moverse” en ellas, es decir se seleccionan las dimensiones e indicadores que se tengan 
disponibles y en base a eso obtendrá diferentes reportes de los datos, resultando esto 
totalmente transparente al usuario. Inclusive no es necesario que el usuario directivo o 
gerencial tenga conocimientos avanzados de informática (aunque es recomendable que 
tenga cierto manejo del mismo) ya que con un conocimiento de las reglas del negocio 
podrá “navegar” entre las diferentes dimensiones que tenga disponible, obteniendo 
distintas visiones del negocio. 
Como se mencionó arriba para trabajar con cubos OLAP es necesario operar con los 
siguientes conceptos: 
 Indicadores o Coeficientes de Gestión: son variables que se obtienen por medio de 
operaciones matemáticas que se realizan sobre algún hecho o expresiones 
basadas en estas, pertenecientes a una tabla de hechos. 
 Atributos: hacen referencia a los campos o criterios de análisis, pertenecientes a 
tablas de dimensiones. 
 Nivel de Agregación o Jerarquía de la Dimensión: las cuales representan una 
relación lógica entre dos o más atributos. 
Existen una serie de acciones que se pueden realizar con los conceptos arriba 
mencionados: 
 Swap: rota filas por columnas o sea permuta dos dimensiones de análisis 
 Down: bajar el nivel de visualización en las filas a una jerarquía inferior 
 Drilldown: genera un detalle de una fila en concreto, de datos a un nivel inferior 
 Expand: similar al anterior sin perder la información a nivel superior para éste y el 
resto de los valores. 
 Collapse: operación inversa de la anterior 
 
A continuación en el Gráfico Nº8 se muestra la forma de representar un indicador a través 
de los atributos en un cubo de información multidimensional. 
 
18 
 
Gráfico Nº8: Cubos de Información Multidimensional 
 
En el Gráfico Nº9 se muestra un caso con el uso de fecha en la aplicación de jerarquías 
en un Data Warehouse 
 
Gráfico 9: Jerarquía de fecha en un Cubo de Información 
 
Es importante mencionar que tal como afirman Elmasri y Navathe (2.007: 854) “el 
rendimiento de la consulta en las matrices multidimensionales puede ser mucho mejor 
que en el modelo de datos relacional” y este es el objetivo principal que se persigue al 
utilizar cubos multidimensionales de información en Base de Datos DWH sobre el empleo 
de las BD Operativas. Es cierto que se pueden obtener los mismos resultados, pero no es 
lo mismo para un gerente tomar una decisión crítica en el que esté en juego el futuro en la 
organización en un par de segundos con cubos multidimensionales a tener una espera de 
minutos o hasta horas de consulta en las tradicionales Base de Datos Operativas. En este 
nivel los sistemas de información deben dar respuestas acordes a las circunstancias, que 
permitan obtener estadísticas, proyecciones y consultas en forma rápida y eficiente. 
 
 
19 
11.- BIBLIOGRAFIA CITADA Y DE CONSULTA 
 
 Adzic Jovanka, Fiore Valter y Sisto Luisella, 2.006. “Capítulo 4: Extraction, 
Transformation, and Loading Processes” de “Data Warehouses and OLAP: 
Concepts, Architectures and Solutions” de Wrembel Robert y Koncilia Christian. 
Hershey. Idea Group Inc 
 
 Bernabeu Ricardo Dario. 2.010. “HEFESTO – Data Warehousing: Investigación y 
Sistematización de Conceptos - Hefesto: Metodología para la Construcción de un 
Data Warehouse. Disponible en 
http://sourceforge.net/projects/bihefesto/files/Hefesto/HEFESTO.gz/download. 
Versión Digital 2.0. Accedido en Julio 2.103. 
 
 Carnota Raúl y Rodriguez Ricardo. 2.010. “Fulgor y Ocaso de CEUNS. Una 
apuesta a la tecnología nacional en el Sur de Argentina”. “Proyecto SAMCA 
(Salvando la Memoria de la Computación Argentina)”.Disponible en 
http://www.cos.ufrj.br/shialc/content/docs/2.1_30SHIALCCarnota_Paper.v2.pdf. 
Accedido en Julio del 2.013 
 
 Czemerinski Hernan y Jacovkis Pablo. 2.012. “La llegada de la computación a la 
Universidad de Buenos Aires”. “Revista iberoamericana de ciencia tecnología y 
sociedad”. Disponible en http://www.scielo.org.ar/scielo.php?pid=S1850-
00132012000100006&script=sci_arttext. Accedido en Julio del 2.013 
 
 Date Christopher. 2.001. “Introducción a los Sistemas de Bases de Datos”. México. 
Pearson Educación. 7ma Edición. 
 
 Elmasri Ramez y Navathe Shamkant. 2.007. “Fundamentos de Sistemas de Bases 
de Datos”. Madrid. 5ta. Edición. Pearson Educación. 
 
 Espinosa Roberto. 2.009. “El Rincón del BI: Descubriendo el Business Intelligence”. 
Artículo “Cubos OLAP (On-Line Analytic Processing)”. Disponible en 
http://churriwifi.wordpress.com/2009/11/24/2-2-cubos-olap-on-line-analytic-
processing/. Ultimo acceso Julio 2.013 
20 
 
 Espinosa Roberto. 2.010. “El Rincón del BI: Descubriendo el Business Intelligence”. 
Artículo “Kimball vs Inmon. Ampliación de conceptos del Modelado Dimensional”. 
Disponible en http://churriwifi.wordpress.com/2010/04/19/15-2-ampliacion-
conceptos-del-modelado-dimensional/. Ultimo acceso Julio 2.013. 
 
 Espinosa Roberto. 2.010. “DATAPRIX Knowledge Is the Goal” Artículo 
“Herramientas ETL. ¿Que son, para que valen?. Productos más conocidos. ETL´s 
Open Source.”. Disponible en 
http://www.dataprix.com/blogs/respinosamilla/herramientas-etl-que-son-para-que-
valen-productos-mas-conocidos-etl-s-open-sour. Ultimo acceso Julio 2.013 
 
 Jacovskis Pablo M. 2.004. “Breve resumen de la historia de la computación en 
Argentina”. Disponible en 
http://www.sadio.org.ar/modules.php?op=modload&name=News&file=article&sid=5
0. Accedido en Julio del 2.013. 
 
 Garcia Sevilla Julia. 2.008. “El aprendizaje basado en problemas en la enseñanza 
universitaria”. Murcia. EDITUM. 
 
 Goleman Daniel. 1.998. “La práctica de la Inteligencia Emocional”. Disponibleen 
http://webs.uvigo.es/pmayobre/master/textos/evangelina_garcia/practica_inte_emo
cional.pdf. Accedido en Julio 2.103. Barcelona. Kairós S.A. 
 
 Hurtado Carlos y Gutierrez Claudio. 2.006. “Capítulo 2: Handling Structural 
Heterogeneity in OLAP” de “Data Warehouses and OLAP: Concepts, Architectures 
and Solutions” de Wrembel Robert y Koncilia Christian. Hershey. Idea Group Inc 
 
 Inmon William, Imhoff Claudia y Sousa Ryan. 1.998. “Corporate Information 
Factory”.NY, John Wiley & Sons, Ltd. 
 
 Inmon. 2.005. “Building the Data Warehouse”. Indianápolis. Wiley Publishing, inc. 
4ta. Edición. 
 
 Laudon Kenneth C. y Laudon Jane P. 2.008. “Sistemas de Información Gerencial: 
administración de la empresa digital”. México. Pearson Educación. 10ma Edición. 
21 
 
 Medina la Plata, Edison. 2.009. “Business Intelligence: la información como arma 
competitiva”. Portal de revistas UPC (Universidad Peruana de Ciencias Aplicadas): 
Sinergia e Innovación. Revista Nº5. Disponible en 
http://revistas.upc.edu.pe/index.php/sinergia/article/view/112/77. Ultimo acceso 
Julio 2.013 
 
 Medina la Plata, Edison. 2.012. “Business Intelligence: Errores comunes en su 
implementación”. Portal de revistas UPC (Universidad Peruana de Ciencias 
Aplicadas): Sinergia e Innovación. Revista Nº17. Disponible en 
http://revistas.upc.edu.pe/index.php/sinergia/article/view/30/20. Ultimo acceso Julio 
2.013 
 
 Kimball Ralph. 1.996. “The Data Warehouse Toolkit: Practical Techniques for 
Building Dimensional Data Warehouses”. NY. John Wiley & Sons, Ltd. 
 
 Kimball Ralph y Ross Margy. 2.002. “The Data Warehouse Toolkit”, “The Complete 
Guide to Dimensional Modeling”. NY. John Wiley & Sons, Inc. 
 
 Pérez López Cesar y González Daniel Santín. 2.008. “Minería de Datos: técnicas y 
herramientas”. Madrid. Thompson. 2da. Edición 
 
 Silberschatz Abraham, Korth Henry F., Henry y Sudarshan S. 2.002. “Fundamentos 
de Base de Datos”. Madrid. Mc Graw-Hill. 4ta. Edición. 
 
 Sinnexus. “Manual de Business Intelligence”. “Sinergia e Inteligencia de Negocio 
S.L.”. Disponible en http://www.sinnexus.com/business_intelligence/index.aspx. 
Accedido en Julio 2.013. 
 
 Vizcarro Carmen y Juárez Elvira. 2008. “¿Qué es y cómo funciona el aprendizaje 
basado en problemas?” En García Sevilla, J. (coord.). “El aprendizaje basado en 
problemas en la enseñanza universitaria”. Murcia. EDITUM. 
 
 SIE - Servicio de Innovación Educativa. 2.008. “Aprendizaje Basado en Problemas: 
Guías rápidas sobre nuevas tecnologías”. Madrid. Disponible en 
http://innovacioneducativa.upm.es/guias/Aprendizaje_basado_en_problemas.pdf. 
Accedido en Julio 2.103.