Diploma de Especializacin en Computacin

Sistemas de Data Warehousing

Trabajo de evaluacin 2009

Docentes: Dra. Ing. Adriana Marotta Ing. Santiago Dalchiele Integrantes del grupo: Lic. Adrin Arredondo Papiol (C.I. 3.877.113-6) Ing. Leonardo Cabral Trebino (C.I. 1.887.214-2)

CSI - Instituto de Computacin Facultad de Ingeniera Universidad de la Repblica

Cuadro de Requerimientos vs. Dimensiones.................................................................4 Dimensiones, Niveles y Medidas..................................................................................7 Relaciones Dimensionales.............................................................................................8 Estudio de Aditividad....................................................................................................9 Esquema Lgico.-............................................................................................................10 Materializacin de Relaciones Dimensionales............................................................10 Fragmentacin vertical de dimensiones......................................................................12 Tablas del Data Warehouse.........................................................................................17 Requerimiento 1.a-..............................................................................................17 Requerimiento 1.b-..............................................................................................18 Requerimiento 2-.................................................................................................19 Requerimiento 3-.................................................................................................20 Esquema Lgico completo del DW.............................................................................21 Seg-Cli.....................................................................................................................24 Eval-Franja..............................................................................................................24

Introduccin.Para la resolucin de este caso de estudio, adoptamos la estrategia recomendada en el curso, diseando un esquema conceptual orientado por los requerimientos, utilizando el modelo CMDM [Car00], aunque no llegamos a aplicar el Lenguaje de Restricciones, por un tema de tiempo disponible. Por tratarse de un caso de estudio donde no tenemos stakeholders a quien consultar, en diversos momentos del diseo se realizaron interpretaciones personales del significado de algunas frases, las cuales se detallan en cada caso. Consideramos que es el encare ms adecuado como norma general, a pesar del argumento que expresa que partir de los requerimientos puede comprometer la realizabilidad, mientras que la estrategia de partir de los datos fuente la asegurara. Nos basamos en que normalmente los requerimientos de los usuarios a quienes se destina el Sistema de Data Warehousing (SDW), son basados en la realidad tangible de sus empresas, sobre todo cuando se enmarca en algn sector especfico (data mart), y hay una muy baja probabilidad que se refieran a datos que no son manejados por alguna fuente de datos. Sin embargo, en virtud de contar con una descripcin detallada y completa de los datos fuente, y aplicada a una porcin pequea del negocio, consideramos que tambin pudo ser adecuada la aplicacin del modelo DF de [Gol98], por lo cual, y como complemento del proceso principal, realizamos el ejercicio de aplicar en forma parcial dicho modelo. Luego diseamos el esquema lgico a partir del esquema conceptual y lo refinamos utilizando lineamientos de diseo presentados en [Per01]. Al igual que para el esquema conceptual, la presencia de un E/R completo y detallado, habilita el concepto de que partir del esquema E/R asegurara que la estructura del DW refleje la semntica de los datos subyacentes. Por este motivo, tambin como complemento del proceso principal, realizamos el ejercicio de aplicar el mtodo presentado en [Moo00] en forma parcial. Creemos que tambin pudo haber sido interesante aplicar el modelo de transformaciones de [Mar00] pero el tiempo disponible no nos permiti hacerlo. Por otro lado, aclaramos que la forma de obtener la base fuente integrada est ms all del alcance del presente trabajo, ya que este problema aparece resuelto en la letra del obligatorio, y asumimos que se obtuvo toda la informacin posible que pudo ser extrada de las bases de datos operacionales.

Esquema Conceptual.Como especificacin del esquema conceptual se utiliza el modelo conceptual multidimensional CMDM definido en [Car00]. Durante la etapa del diseo conceptual se realiza una abstraccin de la realidad basados en los objetos del negocio y los requerimientos de informacin planteados, de modo de no contener ningn aspecto de la implementacin, organizacin fsica de los datos, mecanismos de acceso, etc.

Cuadro de Requerimientos vs. Dimensiones

La primer tarea ser identificar los dos elementos clave para el cliente del Data Warehouse, es decir el usuario que deber evaluar o analizar algunos aspectos de la organizacin o negocio: lo que est siendo analizado, y los criterios de evaluacin por lo que se est analizando. Nos referimos a los criterios de evaluacin como las medidas y lo que est siendo analizado como dimensiones. Basndonos en los requerimientos planteados en la letra del problema, definimos las siguientes dimensiones y medidas necesarias para resolverlos, siguiendo [Bal98].

Requerimientos Dimensiones Usuarios Fechas Estrellas Franjas_Eval Rangos_Sop Estrategias Caractersticas

R 1.1 x

R 1.2

R2 x

R3 x x

x x x x x x

Medidas Cnt_Eval Cnt_Usu_Frj Cnt_Pref Cnt_Estr Cnt_Pel_Prf

x x x x x

Requerimiento Captura de evaluaciones (R 1-) Separamos este requerimiento en dos (R 1.a- y R 1.b-), en virtud de ser claramente disjuntos y reflejar distintas necesidades. En el R 1.a- se plantea la necesidad de obtener la medida: cantidad de evaluaciones realizadas por los usuarios, considerando entonces la dimensin Usuarios y la medida cantidad de evaluaciones (Cnt_eval). A su vez se pide desagregar por cantidad de estrellas asignadas, lo cual define la dimensin Estrellas. A las evaluaciones de los usuarios se las pretende clasificarla por: sexo, edad, profesin y geografa; definiendo as los niveles de jerarquas para la dimensin

Usuarios. La dimensin tiempo est explcitamente identificada con dos niveles Dias y Horarios, y surge cuando se plantea la necesidad de estudiar las evaluaciones por da de la semana cruzado con los horarios en los que se registran las evaluaciones. En el R 1.b- se plantea la necesidad de obtener cantidad de usuarios por ao y por franjas de evaluaciones; es decir, cantidad de usuarios cuyas cantidades de evaluaciones anuales quedan contenidas en franjas preestablecidas. Esto ltimo establece la necesidad de considerar por un lado una dimensin para las franjas de evaluaciones (Franjas_eval) y por el otro la dimensin Tiempo a nivel de aos.. La medida a analizar es la cantidad de usuarios por franja de evaluacin (Cnt_Usu_Frj) Requerimiento Generacin de preferencias (R 2-) En este requerimiento se pide obtener la cantidad de preferencias de cada caracterstica generada por cada estrategia, promediando por tipo de estrategia. En este sentido se defini como medida la cantidad de preferencias (Cnt_pref), considerando una preferencia por evaluacin de cada caracterstica dentro de cada estrategia. Las dimensiones hasta ahora entonces son: Usuarios, Caractersticas y Estrategias. Se plantea un roll-up por tipo de estrategia considerando el promedio de valores para su clculo. A continuacin, dentro del mismo anlisis, se plantea la necesidad de estudiar estos valores discriminados por rango de soporte, es decir, segn la preferencia relativa de la caracterstica considerada por usuario. En tal sentido se define una dimensin de Rangos, que contendr los rangos a considerar para el anlisis. Dado que las preferencias se generan una vez por ao, en un proceso batch a partir de las estrategias, consideramos que es imprescindible agregar la dimensin tiempo para determinar el ao en que fueron generadas las preferencias. Asumimos que las estrategias no cambian sus parmetros en diferentes aos, y que a lo sumo se crearn estrategias nuevas con nuevos parmetros, y algunas se dejarn de considerar. Dado que se pide promediar por tipo de estrategia, decidimos agregar la medida Cnt_Estr = cantidad de estrategias, de modo de asegurar que los resultados de los distintos roll-ups den valores correctos, cuando se utilice el promedio de preferencias por tipo de estrategia. Al nivel de mxima granularidad, este valor ser siempre 1. Requerimiento Evolucin de preferencias (R 3-) Referido al tercer requerimiento, se pide estudiar que caractersticas de las pelculas son las preferidas por los usuarios. Donde dice () se quiere estudiar que caractersticas de las pelculas son preferidas (), entendimos que debe decir valores de caractersticas En este sentido encontramos que este requerimiento puede tener varias interpretaciones y es necesario tomar ciertos recaudos en funcin de cmo se considere. El principal factor de ambigedad surge de la palabra preferidas Las opciones que se consideraron fueron: a) Preferidas, en el sentido de que fue vista (y evaluada), sin considerar si la evaluacin fue positiva o negativa, en funcin de algn criterio, b) o preferida, en funcin de que existe un parmetro para determinar si el puntaje otorgado al criterio considerado es positivo o negativo (es decir preferida = le gust).

Para el resto del informe, y en funcin de nuestro criterio, asumimos que una pelcula es preferida por los usuarios cuando esta es evaluada por los usuarios, independientemente del puntaje que se le otorgue. Esto es porque asociamos el trmino pelculas preferidas a taquilla, o sea aquellas pelculas que el cliente vi, dado que el inters de Marketing no es saber la calidad que los usuarios perciben de cada pelcula (reflejada en la cantidad de estrellas que asignen), sino la pelculas que eligen ver, de acuerdo a los atributos (valores de caractersticas) que saben, a priori, que dichas pelculas tienen (quin acta, de qu genero es, cul es el director). Adems creemos errneo asumir que los valores de las 12 caractersticas que se identifican para cada pelcula, heredan por igual el puntaje que el usuario asign a la misma. Por ejemplo, si se desea saber que gnero es preferido por los clientes, creemos ms adecuado analizar de qu gnero son las pelculas que los usuarios eligen ver, y no la opinin sobre la calidad (rating) de las pelculas de cada gnero que vio el cliente.

Dimensiones, Niveles y Medidas

Se describe a continuacin el esquema conceptual multidimensional obtenido a partir de los requerimientos planteados, junto con un estudio de aditividad de las medidas identificadas. La siguiente imagen grafica las dimensiones y sus estructuras de jerarquas de niveles de agregacin relevadas. El nivel Atributos agrupa todos los valores de los dominios de las

caractersticas.

Relaciones Dimensionales
Las relaciones dimensionales simbolizan cruzamientos entre las dimensiones, y cada relacin dimensional representa el conjunto de cubos que se pueden construir tomando al menos un nivel de las dimensiones participantes. De acuerdo a la realidad planteada, las relaciones dimensionales detectadas son las que se muestran en la figura siguiente.

Estudio de Aditividad
Dimensiones Usuarios Tiempo Estrellas Franjas_eval Atributos Estrategias Rango_sop Todos los niveles Todos los niveles Todos los niveles -Atributos Caractersticas Caractersticas ALL Estrategia Tipo Estrategia Estrategia ALL -R 1.a R 1.b R2 R2 R3 Cnt_Eval Cnt_Usu_Frj Cnt_Pref Cnt_Estr Cnt_Pel_Prf + + + + + + + +

+ +

+ PROM PROM +

+ + + +

+ NO PERM.

Para solucionar el problema detectado para Cnt_Pref en el roll-up por Estrategia, se decidi mantener la medida Cant_Estr, para realizar los clculos de roll-up de las dems dimensiones, de modo de poder realizar la suma de los promedios. En el Requerimiento 3- se utiliza el nivel Atributos, que agrupa todos los valores de los dominios de las caractersticas. No tiene sentido sumar cantidades de pelculas de atributos de caractersticas distintas, por eso no se permite la operacin. Por ejemplo sumara cantidad de pelculas preferidas de Actores con Lugares de Rodaje.

Esquema Lgico.El esquema lgico es una descripcin de la estructura de una base de datos que almacena informacin en un modelo de datos orientado a satisfacer requerimientos de toma de decisiones. Nos decidimos por un diseo lgico-relacional a partir del Esquema Conceptual, siguiendo lineamientos de diseo de [Per01]. Dado que no tenamos informacin sobre cmo cambian los datos, se utiliz la solucin del Galaxy Schema, es decir, varios Star Schemas con tablas de hechos independientes, por considerarse la ms balanceada entre performance y facilidad del mantenimiento de datos. Por otra parte, se hizo un ejercicio de obtencin del modelo lgico a partir del esquema relacional de los datos fuente siguiendo la metodologa de Kortink y Moody, que nos hizo inferir que con ese enfoque se hubiese llegado a un Data Warehouse sobredimensionado si no se hubiese considerado los requerimientos. En el anexo X, se muestra la realizacin de este ejemplo

Materializacin de Relaciones Dimensionales

Para el Requerimiento 1.a- elegimos materializar 3 cubos. Llamamos Seg-Cli al de mxima granularidad, requerido para realizar todas las operaciones posibles de la Relacin Dimensional. Adems definimos Eval-Cli y Ms-Activos, para optimizar la performance de aquellas consultas que consideramos ms relevantes y frecuentes.

Para el Requerimiento 2- elegimos materializar 3 cubos. Llamamos Gen-Pref al de mxima granularidad, adems definimos Tipo-Estr y Pref-Usu, guindonos por la forma en que estn estructurados los prrafos que explican el requerimiento. Para el cubo del Requerimiento 3-, decidimos materializar un nico cubo, y realizar una fragmentacin horizontal con 12 franjas, una por cada Caractersticas: Gnero, Pas de rodaje, Continente de rodaje, Ao de rodaje, Dcada de rodaje, Palabra clave, Idioma, Compaa productora, Pas de produccin, Continente de produccin, Actor, Director. Los valores de estas Caractersticas se agrupan en la tabla Atributos. Nos planteamos la idea de realizar una mini-dimensin que agrupe Ao+Sexo+Edad, la cual quedara de menos de 150 registros, de modo de mejorar la performance, al tratarse de tablas muy grandes, tanto la dimensin Atributos (aproximadamente 80.000 registros) como la Fact Table (ms de 11 millones de registros). Sin embargo nos quedan dudas del beneficio real que esta accin generara, as como de la posibilidad y funcionamiento real de ejecutarlo con las herramientas conocidas

Fragmentacin vertical de dimensiones

Decidimos seguir las siguientes fragmentaciones para las dimensiones, en funcin de los requerimientos planteados, y los cubos materializados, para indicar para cada dimensin qu niveles se almacenarn juntos, es decir, el nivel de normalizacin deseada. Para la dimensin Tiempo, se omite el fragmento Fechas ya que no se utiliza en ninguna parte del Esquema Lgico.

Las dimensiones no reflejadas en la figura: Estrellas, Rangos_Sop y Franjas_Eval, tienen un solo nivel, por lo que no es necesario determinar ninguna fragmentacin.

Mapeo de fragmentos de dimensiones con datos fuente

A continuacin se presentan los mapeos definidos para los fragmentos de la dimensin Usuarios, y se definen condiciones de mapeos. Para el fragmento Geografa (Cdigos postales), se debi buscar una fuente externa, y se obtuvo una planilla de clculo ZipCod_Uy.xls de www.correo.com.uy

Los mapeos de Estrategias y Caractersticas son bastante lineales, pero se produce un caso interesante en el nivel Atributos, que agrupa todos los valores de los dominios de las 12 caractersticas. Se debe generar a partir de las referencias a las tablas relacionadas con cada dominio de Characteristics, y generar una clave autonumrica para el identificador del atributo.

Finalmente las dimensiones para Estrellas, Franjas_Eval, Rangos_Sop y Tiempo son bastante triviales, pero igualmente especificamos los mapeos, por completitud.

Mapeo de Cubos
Las distintas materializaciones de cubos provenientes de una misma Relacin Dimensional se generan para agilitar las funciones de roll-ups ms frecuentes, y normalmente implican sumatorias de las medidas aditivas. En el caso del Requerimiento 2-, el roll-up por Estrategia implica un promedio, para lo cual adems de la medida Cnt_Pref, se utiliza la medida Cnt_Estr. En cada roll-up se tomar la precaucin de realizar la suma de los promedios y no los promedios de las sumas.

Tablas del Data Warehouse

A continuacin se presenta la representacin del diseo lgico en dentro de un esquema ROLAP. Dado que no se especifica la volatilidad (es decir, la frecuencia de cambio) que presentan los datos de las dimensiones (y por ende la optimizacin que se requiere en su mantenimiento) as como tampoco sobre la performance de las consultas, utilizaremos una representacin relacional directa del modelo multidimensional, usando el Star Schema para cada relacin dimensional. Con este esquema se logran estructuras ms fciles de entender y consultar, dado que se disminuye en nmero de tablas respecto al de la otras opciones (por ejemplo Snowflake Schema), logrndose as una mejor performance. A su vez, cada Star Schema consistir en una tabla central (Fact Table) y para cada dimensin, una nica tabla por cada fragmento vertical definido, con las jerarquas embebidas (representadas implcitamente) y por lo tanto, desnormalizada. La Fact Table tiene por clave la concatenacin de las claves primarias de todas las tablas dimensin y las medidas. A continuacin mostraremos la representacin resumida del esquema para cada requerimiento en particular, a los efectos de verlo ms claramente.

Requerimiento 1.a-

Usuarios Id_Usu Usu_Nom Usu_Dir Usu_Tel Id_CodPos Id_Sexo Id_Edad Id_Prof Prof_Desc

Seg-Cli Id_Usu Id_DiaSem Id_Hora Id_Estrella Cnt_Eval Estrellas Id_Estrella

Horarios Dia_Sem Id_DiaSem DiaSem_Nom Id_Hora Hora_Ini Hora_Fin

Usuarios Id_Usu Usu_Nom Usu_Dir Usu_Tel Id_CodPos Id_Sexo Id_Edad Id_Prof Prof_Desc Eval-Cli Id_Usu Id_Estrella Cnt_Eval Estrellas Id_Estrella

Geografa Id_CodPos CP_Nom Id_Local Loc_Nom Id_Depto Dpt_Nom

Mas_Activos Id_CodPos Id_DiaSem Id_Hora Cnt_Eval

Horarios Id_Hora Hora_Ini Hora_Fin

Dia_Sem Id_DiaSem DiaSem_Nom

Requerimiento 1.b-

Franjas_Eval Id_Frj Eval_Min Eval_Max

Eval_Franja Id_Frj Id_Ao Cnt_Usu_Frj

Aos Id_Ao

Requerimiento 2-

Usuarios Id_Usu Usu_Nom Usu_Dir Usu_Tel Id_CodPos Id_Sexo Id_Edad Id_Prof Prof_Desc

Gen-Pref Id_Usu Id_Ao Id_Estrat Id_Caract Id_Sopor Cnt_Pref Cnt_Estr

Estrategias Id_Estrat Estr_Nom Id_TpoEst

Aos Id_Ao

Caractersticas Id_Caract Car_Nom

Rangos_Sop Id_Sopor Sop_Min Sop_Max

Aos Id_Ao

Tipo-Estr Id_Ao Id_Caract Id_TpoEst Id_Sopor Cnt_Pref Cnt_Estr

Tipos_Estrat Id_TpoEst TpoEst_Nom

Caractersticas Id_Caract Car_Nom

Rangos_Sop Id_Sopor Sop_Min Sop_Max

Aos Id_Ao

Pref-Usu Id_Ao Id_Caract Id_Usu Cnt_Pref Cnt_Estr

Caractersticas Id_Caract Car_Nom

Usuarios Id_Usu Usu_Nom Usu_Dir Usu_Tel Id_CodPos Id_Sexo Id_Edad Id_Prof Prof_Desc

Requerimiento 3-

Aos Id_Ao

Pref-Evol Id_Ao Id_Atrib Id_Edad Id_Sexo Cnt_Pel_Prf

Sexo Id_Sexo Sex_Nom

Atributos Id_Atrib Atr_Val Id_Caract Car_Nom

Frj_Etaria Id_Edad Edad_Min Edad_Max

Esquema Lgico completo del DW

Carga y Actualizacin.El diseo del DW debe tener en cuenta que la informacin proviene de sistemas operacionales ya existentes debe ser mantenida a medida que estos sistemas cambian. Para los siguientes procesos, y para acotar el problema, no se considerarn los versionados de los datos, ni procesos de limpieza, correccin de errores, o resolucin de inconsistencias. Con las salvedades especificadas, las actividades de carga son fundamentalmente: Identificacin (obtencin de los datos), Extraccin, Filtrado (verificacin de existencia de datos previamente cargados en el DW), Integracin (de varias estructuras fuentes en una destino), Transformacin (clculos, conversiones, formateos, generacin de cdigos) e Insercin (cargar los datos en las tablas destino del DW).

Carga Inicial
Se identificaron relaciones dimensionales que, por a razones de performance, conviene definirlas con un nivel de granularidad menor. En este sentido, y al momento de enfrentar la carga inicial del sistema, se deben cargar las fragmentaciones de los cubos originales con datos agrupados bajo ciertos criterios.

Bsicamente, para cada Star Schema se cargan primero sus dimensiones y luego la Fact Table asociada. Por lo tanto, los rdenes seran: Requerimiento 1.aCargar Usuarios Cargar Estrellas, Dia_Sem, Horarios, Geografa Cargar Seg-Cli Cargar Eval-Cli Cargar Mas-Activos Requerimiento 1.bCargar Franjas-Eval Cargar Aos Cargr Eval-Franja Requerimiento 2Cargar Estrategias y Tipos de Estrategia Cargar Caractersticas Cargar Rango_Sop Cargar Gen-Pref Cargar Tipo-Estr Cargar Pref-Usu Requerimiento 3Cargar Sexo Cargar Frj-Etaria Cargar Atributos Cargar Pref-Evol

Dimensiones
Para ayudar en el diseo del proceso de carga realizamos un diagrama resumido del Esquema Lgico del DW, identificando el tipo de proceso que requiere la carga de cada tabla de dimensin.

Tipo de operaciones - Creacin de tablas nuevas, identificada con color verde: Dia_Sem, Franjas_Eval, Horarios, Estrellas, Rangos_Sop, Sexo. - Carga desde datos externos, identificada con color rojo: Geografa. - Datos inferidos de tablas fuente, identificados con color naranja: Aos, Tipos_Estrat. - Tablas copiadas, eventualmente con renombrado de atributos, identificadas con color celeste: Frj_Etaria, Estrategias, Caractersticas. - Tablas que llevan proceso de transformacin o agrupacin, identificadas con color rosado: Usuarios y Atributos. Con estas consideraciones y el mapeo de fragmentos de dimensiones con datos fuente queda prcticamente definida la carga inicial de las tablas de dimensiones.

Sentencias SQL para la carga inicial de Fact Tables

A modo de ejemplo, se detallan de las sentencias SQL ms interesantes, que deben considerarse para cargar la estructura relacional del DW.

Seg-Cli
SELECT UserId, DOW(Timestamp), CALC_HORA(TimeStamp), Rating, COUNT(*) FROM UserRatings INTO DW_Seg-Cli GROUP BY UserId, DOW(Timestamp), CALC_HORA(TimeStamp), Rating

Eval-Franja

Actualizacin
Los datos operacionales que alimentan el presente SDW, se pueden dividir, por su variabilidad en 4 categoras: Tablas casi inmutables, como por ejemplo UserAges, UserOcupations, Characteristics, Strategies, I_Genres, Language, I_Countries, etc. Tablas de cambio lento, como Users, I_Director, Keyword Tablas de crecimiento rpido, como UserRatings, I_Movies y sus relacionadas Tablas de generacin anual, especficamente Preferences En base a esto, al mapeo de fragmentos de dimensiones con datos fuentes y al diagrama resumido del Esquema Lgico, llegamos a las siguientes estrategias de actualizacin del DW: a) Dimensiones que se cargan slo la primera vez Horarios, Dia_Sem, Franjas_Eval, Estrellas, Rangos_Sop, Sexo, Geografa, Frj_Etaria, Caractersticas b) Dimensiones que se actualizan agregando registros cuando corresponde Usuarios, Estrategias, Tipos_Estrat, Atributos c) Dimensin que se actualiza anualmente Aos Fact Tables del Requerimiento 1.aEs el que requiere actualizacin peridica, en virtud de la variacin de los datos fuentes que lo alimentan. Se debe realizar la carga completa cada vez que se actualiza, borrando los datos anteriores y actualizando las Dimension Tables del tem b) Fact Tables del Requerimiento 1.bActualizacin en mismos perodos que Req. 1.a-, pero en lugar de borrar y cargar nuevamente toda la tabla, slo se debe realizar esto con el ao en curso, sin alterar los registros de aos anteriores. Fact Tables del Requerimiento 2Generacin anual, tras el proceso batch de Generacin de Preferencias, agregando datos del ao procesado, sin alterar los datos de aos anterires, y actualizando la tabla de Aos. Fact Tables del Requerimiento 3Idem Req. 1.b-

Implementacin.

ANEXO 1

Mtodo de Moody y Kortink Clasificacin de Entidades

Identificar Jerarquias
Determinar las Maximas Jerarquias: UserAges Users UserRatings UserAges Users - Preferences UserOccupations Users Preferentes UserOccupations Users UserRatings Strategies Preferences Characteristics Preferences I_Movies UsersRatings I_Movies I_MovieActors I_Movies I_MovieGenerers I_Movies I_MovieProdCompanies I_Movies I_MovieCountries I_Movies I_MovieLanguages I_Movies I_MovieKeyword I_Movies I_MovieYear I_Movies I_MovieDirector I_Actors - I_MovieActors I_Generes I_MovieGenerers I_Country I_CountryCode - I_MovieProdCompanies

I_Countrie I_MovieCountries Language I_MovieLanguages I_Keywrds I_MovieKeyword I_Director I_MovieDirector Entidades minimas: UserRatings Preferences I_MovieActors I_MovieGenerers I_MovieProdCompanies I_MovieCountries I_MovieLanguages I_MovieKeyword I_MovieYear I_MovieDirector I_MovieActors I_MovieGenerers I_MovieProdCompanies I_MovieCountries I_MovieLanguages I_MovieKeyword I_MovieDirector

Entidades maximas: UserAges UserOccupations Strategies Characteristics I_Movies I_Actors I_Generes I_Countrie Language I_Keywrds I_Director

Modelos Dimensionales
El modelo planteado por Moody establece: a) Fusionar Jerarquas Fusin 1 UserAges Users UserRatings UserAges Users - Preferences UserOccupations Users Preferentes UserOccupations Users UserRatings (UserAges+Users) (UserOccupations+Users) -------------------------------------------------------------Users UserRatings Users - Preferences

Users UserId Name Address Phone ZipCode Gender OccupationId AgeId MinAge MaxAge

UserAges AgeId MinAge MaxAge

Users UserId Name Address Phone ZipCode Gender AgeId MinAge MaxAge OccupationId Occupation

UserOccupations OccupationId Occupation

Fusin 2 I_CountryCode - I_MovieProdCompanies (I_Countrie+ I_MovieProdCompanies) -------------------------------------------------------------I_MovieProdCompaines

I_MovieProdCompanies MovieID CompanyName CountryCode Description Country

I_CountryCodes CountryCode Country Description

Fusion 3 I_Actors I_MovieActors (I_Actors+ I_MovieActors) -------------------------------------------------------------I_MovieActors Fusion 4 I_Generes I_MovieGenerers (I_Generes + I_MovieGenerers) -------------------------------------------------------------I_MovieGenerers

b) Agregar Datos El siguiente paso en la metodologa planteada por Moody es utilizar la agregacin a las transformaciones de las entidades para crear una nueva entidad que contenga datos sumarizados. Esto es seleccionar un subconjunto de atributos de una entidad origen y otro subconjunto de atributos a agrupar por los primeros. La clave de esta nueva entidad es la combinacin de los atributos utilizados para agrupar. Es importante destacar que esta transformacin pierde informacin; no pudiendo reconstruir el detalle de los elementos agrupados. Se considero la posibilidad de agrupar cantidad de evaluaciones por usuario, obtener evaluaciones por Usuario y por franja, etc. No se llevaron a la prctica principalmente por restricciones de tiempo en la realizacin del informe. Sin embargo y Segn Moody [Moo01], en este punto del proceso se debe considerar que todava resta realizar una anlisis de requerimientos para identificar cuales de las entidades son relevantes y su posterior clasificacin. Entendemos que segn la realidad que se este analizando estos criterios de agregacin pueden surgir ms fcilmente en forma temprana o quizs convenga postergarlos hasta comprender los requerimientos especficos mas cabalmente. A su vez, utilizar el diagrama de ER de los datos permite un buen punto de comienzo para el desarrollo de modelos dimensionales [Moo01], postergando para etapas posteriores de refinamiento y optimizacin del modelo. Modelo dimensional Final

Evaluar y Refinar el modelo

Moody plantea tres pasos para el refinamiento y evaluacin del modelo dimensiona. 1. Combinar tablas de Hecho Las tablas con las mismas claves primarias son candidatas a ser fusionadas, esto reduce la cantidad de esquemas tipo estrella y facilita la comparacin entre tablas de Hecho relacionadas. En nuestro caso de estudio no encontramos tablas de Hecho con la misma o similares claves, por tanto, no fue aplicado. 2. Combinar tablas de Dimensiones Crear tablas de dimensiones para cada tabla de componente resulta en un importante nmero de tablas de dimensiones. Para simplificar la estructura del data Mart, Dimensiones relacionadas pueden ser consolidadas en una sola dimensin. No se encontr aplicacin. 3. Analizar relaciones N a N. Una de las complejidades frecuentes en la transformacin de modelos de Entidad Relacin en un modelo Dimensional surge al tratar de representar las relaciones N a N o interseccin de entidades. Estas relaciones causan un problema por cortar un canal de Jerarqua, y por tanto, la posibilidad de fusionarla. No se encontraron en el caso de estudio relaciones N a N, por tanto, no aplica. Sin embargo, observamos que modelo relacional planteado como obligatorio aplica una de las tcnicas para la solucin de los inconvenientes asociados a relaciones N a N mediante la utilizacin de una BridgeTable. A modo de ejemplo podemos observar como se creo la tabla puente I_MoviesActors para relacionar las I_Movies y los I_Actors, transformando una relacin N a N en dos relaciones ( N a 1 y otra 1 a N)