Escolar Documentos
Profissional Documentos
Cultura Documentos
MODALIDAD DE GRADUACIN
Proyecto de Grado
FACULTAD DE INGENIERA
Carrera Ingeniera de Sistemas
MODALIDAD DE GRADUACIN
Proyecto de Grado
ABSTRACT
TITULO
AUTOR
PROBLEMATICA
OBJETIVO
CONTENIDO
CARRERA
PROFESOR GUIA
DESCRIPTORES O TEMAS
: Ingeniera de Sistemas
: Ing. Germn Suarez
: Data Warehouse, Data Mart, Analisis,
Diseo, Modelo Dimensional.
: oscar.amelunge@gmail.com
: Julio de 2010.
FECHA
AGRADECIMIENTO
En esta seccin se realizara el agradecimiento correspondiente
RESUMEN
INTRODUCCION
(almacn de datos)
El objetivo primordial de un D.W.es almacenar los datos de tal manera que se facilita la
extraccin y consulta de los mismos sin importar el amplio volumen de informacin que
pueda existir. Normalmente el alcance que tiene un D.W. llega a ser, toda la informacin
generada empresa, la construccin de un D.W. requiere una inversin en tiempo y
esfuerzo considerable. Una estrategia o concepto alternativo al D.W. que tiene el mismo
fin pero con un alcance ms limitado a un rea o departamento de empresa es el Data
mart. Un Data mart es una versin especial de almacn de datos (Data Warehouse). Son
subconjuntos de datos con el propsito de ayudar a que un rea especfica dentro del
negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden
ser agrupados, explorados y propagados de mltiples formas para que diversos grupos de
usuarios realicen la explotacin de los mismos de la forma ms conveniente segn sus
necesidades. (WIKIPEDIA, 2010).
En los tiempos actuales las empresas necesitan depositar toda su confianza en la toma de
decisiones, para lo cual se requieren fuentes de informacin fiables y oportunas, la cuales
brinden a los empleados, jefes de seccin, administrativos, ejecutivos y tambin entes
externos
TABLA DE CONTENIDO
PARTE I PLANIFICACIN Y
El sistema utiliza como repositorio de informacin una base de datos cuyo diseo
relacional est orientado mas al almacenamiento que a la consulta y explotacin de los
mismo, con el paso del tiempo los usuarios de dicho sistema han ido requiriendo cada
vez mayor cantidad de reportes y necesidad de poder analizar la informacin de los
funcionarios, con lo cual el modelo transaccional sobre la cual est construida la base de
datos dificulta el estudio de la informacin almacenada en la misma.
Con los sistemas tradicionales se preparan reportes ad-hoc para encontrar las respuestas a
algunas de las preguntas del negocio, pero se necesita dedicar mucho del tiempo al
anlisis de localizacin, formateo, presentacin y procesamiento de los datos, como
tambin asignacin de recursos humanos del departamento de sistemas para poder
responderlas, sin tener en cuenta la degradacin de los sistemas transaccionales. Esta
problemtica se debe a que dichos sistemas transaccionales no fueron construidos con el
fin de brindar sntesis, anlisis, consolidacin, bsquedas y proyecciones.
Existe una gran cantidad de reportes ad-hoc asociados a los datos que se registran en el
sistema de recursos humanos y la variacin de los mismos en el tiempo es poco
significativa, la herramienta en la cual estn construidos y publicados estos reportes exige
que cada vez que se requiera un cambio menor en el mismo, tenga que contactarse a los
desarrolladores para que el reporte ad-hoc sea modificado, lo cual implica un retraso para
la persona o rea de empresa que necesita el reporte.
1.5. JUSTIFICACIN
La ventaja de utilizar un Data Mart como herramienta al soporte de decisiones son
muchas por ejemplo: que el departamento de RR. HH. pueda consultar la informacin
reduciendo la dependencia de personal tcnico (programadores o analistas de sistemas)
que genere los reportes o consultas ad hoc a travs de un lenguaje y/o herramienta de
programacin, lo cual adems conlleva en disminuir el proceso de elaborar un
requerimiento, explicar este requerimiento al programador, esperar a que el programador
comprenda y programe el requerimiento, validar u observar el trabajo realizado por el
programador, etc.
1.6. OBJETIVOS
1.6.1. OBJETIVO GENERAL
Construir un Data Mart para la gestin de reportes y apoyo a la toma de decisiones del
departamento de RR.HH. de la empresa de agua S.A.
1.7. ALCANCE
La metodologa a utilizar ser El Proceso de Ingeniera para el Data Warehouse (DWEP
por sus siglas en ingles) planteado en la tesis doctoral de Lujn-Mora (Lujn Mora,
2005) utilizando como herramientas de modelado al Lenguaje Unificado de Modelado
(UML) y las extensiones multidimensional profile, data mapping profile, ETL profile,
UML profile database desing y database deployment profile planteadas en la citada tesis
doctoral.
Fases
Inicio
Requerimientos
o Requerimientos funcionales y no funcionales.
o Identificacin de las medidas y dimensiones ms importantes.
o Anlisis de los reportes peridicos que se utilizan actualmente.
o Elaboracin del modelo del dominio
o Elaboracin de los casos de uso ms importantes
Anlisis
o Determinacin de las posibles fuentes de datos
o Elaboracin de los diagramas lgico de la fuente de datos SLS, diagrama
fsico de las fuentes de datos SPS.
Diseo
o Diseo definicin de la estructura del Data Mart.
o Elaboracin del diagrama conceptual del Data Mart DMCS.
Elaboracin
Requerimientos
o Recoleccin y refinamiento de requerimientos.
o Identificacin de nuevas medidas agregaciones y dimensiones.
3
Anlisis
o Eleccin de fuentes de datos que alimenta el Data Mart.
o Actualizacin del diagrama lgico de las fuentes de datos SLS y el
diagrama fsico de las fuentes de datos SPS.
o Elaboracin del diagrama conceptual de las fuentes de datos SCS.
Diseo
o Definicin procesos a nivel conceptual de los ETL mas importantes
(mapeo de datos) desde la fuente de datos hacia el Data Mart.
o Actualizacin del diagrama conceptual del Data Mart DMCS.
o Elaboracin del diagrama mapeo de datos de integracin del Data Mart.
Implementacin
o Elaboracin de las estructuras fsicas del Data Mart.
o Elaboracin de los diagramas, Diagrama lgico del Data Mart, Diagrama
fsico del Data Mart, Diagramas de procesos ETL de integracin.
Pruebas
o Planeacin de pruebas.
o Diseo de los casos de prueba.
o Realizacin de las pruebas en base a los casos de pruebas.
o Resultados y correcciones.
Construccin
Anlisis
o Actualizacin de los diagramas: diagrama lgico de la fuente de datos,
diagrama fsico de la fuente de datos diagrama conceptual de la fuente de
datos.
Diseo
o Actualizacin y definicin de los nuevos procesos ETL a nivel conceptual
(mapeo de datos) desde las fuentes de datos hacia el Data Mart.
o Actualizacin de los diagramas conceptual del Data Mart (DMCS) mapeo
de datos de integracin.
Implementacin
4
Pruebas
o Diseo de los casos de prueba.
o Realizacin de las pruebas
o Resultados y correcciones.
CAPITULO II
DATA WAREHOUSE Y DATA MART
De acuerdo a Immon (1999) existen dos tipos de ata Mart: dependientes e independientes.
Un Data Mart dependiente es aquel cuya fuente de datos es un Data Warehouse, Un Data
Mart independiente es aquel cuya fuente de datos son los sistemas transaccionales, el
Data Mart a construir en el presente trabajo de grado.
Data Warehouse
Data Mart
Alcance
Corporativo
rea de Negocios
Temas
Multiples
Simples
Fuentes de Datos
Muchas
Pocas
Tamaos
100 GB-TB+
< 100 GB
Tiempo de implementacin
Fuente
De meses a aos
Meses
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
2.4. LOS PROCESOS ETL
Las bases de datos operacionales trabajan con un tipo de procesamiento OLPT mientras
que un Data Warehouse trabaja bajo un procesamiento de tipo OLAP.
2.6. OLPT
De acuerdo a Wikipedia (2010) Online transaction processing por sus siglas es un tipo de
sistemas que facilitan y administran aplicaciones transaccionales, usualmente para
entrada de datos y recuperacin y procesamiento de transacciones (gestor transaccional).
Los paquetes de software para OLTP se basan en la arquitectura cliente-servidor ya que
suelen ser utilizados por empresas con una red informtica distribuida. La tecnologa
OLTP se utiliza en innumerables aplicaciones, como en banca electrnica, procesamiento
de pedidos, comercio electrnico, supermercados o industria.
2.7. OLAP
De acuerdo a Wikipedia(2010) OLAP es el acrnimo en ingles de procesamiento
analtico en lnea. Es una solucin que consiste en consultas a estructuras
ROLAP
Implementacin OLAP que almacena los datos en un motor relacional. Tpicamente, los
datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas.
Los esquemas ms comunes sobre los que se trabaja son estrella copo de nieve, aunque
es posible trabajar sobre cualquier base de datos relacional. La arquitectura est
compuesta por un servidor de banco de datos relacional y el motor OLAP se encuentra en
un servidor dedicado. La principal ventaja de esta arquitectura es que permite el anlisis
de una enorme cantidad de datos.
MOLAP
Esta implementacin OLAP almacena los datos en una base de datos multidimensional.
Para optimizar los tiempos de respuesta, el resumen de la informacin es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base de las
ganancias de desempeo de este sistema. Algunos sistemas utilizan tcnicas de
compresin de datos para disminuir el espacio de almacenamiento en disco debido a los
valores precalculados.
10
2.8.1. MEDIDAS
El blog oficial para Olap Oracle Corp. En el articulo Olap Workshop 1: Basic OLAP
concepts (2007) nos dice que las medidas representan los datos objetivos, muchas veces
llamadas hechos. Un ejemplo tpico de medidas son las ventas, los costos, ganancias
mrgenes, etc. Las medidas se organizan en una o ms dimensiones. Las medidas estn
por lo general representadas por la forma de un cubo en donde los bordes o aristas del
cubo son las dimensiones y el contenido del cubo son los valores de medida.
http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olap-concepts.html
Hechos
11
Granularidad
La granularidad es el nivel de detalle de los hechos en un Data Warehouse (Peterson,
1995) . Por ejemplo se determina que el mayor nivel de detalle de un cubo de ventas, es
la cantidad de ventas realizadas por mes, o sea, no llega al detalle de ventas diarias.
2.8.2. DIMENSIONES
Las dimensiones identifican y categoriza los datos del negocio. Ejemplos de dimensiones
pueden ser product, geografia, tiempo, canal de distribucion, etc. Las dimensiones son
almacenadas en tablas satlites que estn unidas a las tablas de hechos(Poe, 2007)
12
Jerarquas
Las jerarquas son estructuras lgicas que agrupan datos pertenecientes a una dimensin
con el propsito de analizarlos por ejemplo: si se considera una escala (o dimensin)
temporal "Mayo de 2005" se puede incluir en "Segundo Trimestre de 2005", que a su vez
se incluye en "Ao 2005".
Niveles
Los niveles representan una posision en una jerarquia. El nivel superiror contiene una
agregacin de valores para el nivel inferior. Cada nivel tienen una relacin uno a muchos
o maestro detalle con su nivel inferior. Por ejemplo una medida de ventas puede
encontrarse en la jerarqua de productos y en un nivel superior en categora de productos
o sub categoras, etc.
13
Origen : http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olapconcepts.html
Atributos
Los atributos proveen informacin descriptiva hacerca de los datos y son de utilidad
cundo se seleccionan datos para el anlisis por ejemplo:
Seleccin de productos cuyo color (atributo) es Azul.
Seleccin de clientes que tienen dos hijos.
Seleccin de promociones que son de tipo Multipack.
14
2.8.3.1. Estrella
Segun Oracle Corporation el esquema tipo estrella es llamado asi debido a que el diagram
entidad relacion que este forma se asemeja a una estrella con puntas que se originan
desde el centro. El centro de la estrella consiste en una tabla de hechos y las puntas de la
estrella son las tablas de dimensiones como se muestra en la figura siguiente.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/schemas.htm
15
Origen: http://es.wikipedia.org/wiki/Archivo:Esquema_en_estrella.png
La caracterstica del esquema copo de nieve es que normaliza las dimensiones para
eliminar redundancia. Esto quiere decir que la tabla de dimensiones es distribuida en
distintas tablas pequeas en vez de una tabla grande como se lo hara en una estrella
como se muestra en la figura.
16
17
CAPITULO III
PROCESO DE INGENIERIA DEL DATA WAREHOUSE
19
El proceso de ingeniera para el data warehouse, al ser una instancia del UP(Proceso
Unificado), hereda las siguientes caractersticas del mismo:
Dirigido por casos de Uso, es decir que los casos de uso son utilizados para especificar
los requerimientos de un sistema, pero adems, estos dirigen el diseo, implementacin y
pruebas del mismo.
Centrado en la arquitectura, la arquitectura del software engloba los aspectos estticos y
dinmicos mas significativos del sistema, y es descrita como diferentes vistas del sistema
que se est construyendo.
Iterativo e incremental, el desarrollo de los productos de software es difidido en partes
mas pequeas llamadas iteraciones que resultan en un incremento en el crecimiento del
producto, por otra parte los diagramas no permanecern intactos, deben evolucionar a
medida que pasa el tiempo, y vayan apareciendo nuevos requerimientos.
De acuerdo con el Proceso Unificado el proyecto esta dividido en cuatro fases (Inicio,
Elaboracin, construccin y Transicin) y cinco flujos de trabajo fundamentales
(Requerimientos, Anlisis, Diseo, Implementacin y Pruebas), los flujos de trabajo de
Mantenimiento y Revisin Pot-Desarrollo son aadidos por el Proceso de Ingeniera del
Data Warehouse.
En la figura siguiente se muestra como los 7 flujos de trabajo toman lugar en las cuatro
fases, para cada flujo de trabajo la curva presenta aproximadamente el grado en el cual el
flujo de trabajo es realizado en cada fase.
(Insertar figura del proceso unificado).
Por cada uno de los flujos de trabajo se utiliza diferentes diagramas UML para modelar y
documentar el proceso de desarrollo, pero un modelo puede ser modificado en diferentes
fases porque los modelos evolucionan a travs del tiempo. A continuacin se muestras los
20
3.3.1. REQUERIMIENTOS
Durante este flujo de trabajo se captura lo que los usuarios finales esperan poder hacer
con el Data Warehouse, los usuarios finales deberan especificar las medidas y
agregaciones ms interesantes, las dimensiones de anlisis, los reportes que utiliza
peridicamente para tomar decisiones, la frecuencia de actualizacin de los datos, etc.
Los requerimientos son modelados utilizando casos de uso como se propone en el libro
Developing requeriments for Data Warehouse System with Use Cases (Brukner, 2001).
3.3.2. ANALISIS
En este flujo de trabajo se refinan y estructuran los requerimientos que se capturaron en
el anterior flujo de trabajo, adems de identificar y documentar las posibles fuentes de
datos que alimentaran el Data Warehouse.
3.3.3. DISENIO
Al finalizar este flujo de trabajo la estructura del Data Warehouse es definida. El
resultado principal de este flujo de trabajo es el modelo conceptual del Data Warehouse,
adems del mapeo de datos desde las fuentes de datos ya definidas hacia el Data
Warehouse y del Data Warehouse hacia las estructuras del cliente.
En este flujo de trabajo se construyen los siguientes diagramas: Diagrama conceptual del
Data Warehouse, Mapeo de Datos de la etapa de Integracin, Diagrama Conceptual del
cliente y Mapeo de Datos de la etapa de personalizacin, (DWCS, DM, CCS y DM). Los
dos ltimos diagramas son aplicados en el caso de que existan Data Marts coo clientes en
21
3.3.4. IMPLEMENTACION
En este flujo de trabajo se construye el Data Warehouse, se construyen las estructuras
fsicas del Data Warehouse, el Data Warehouse es llenado y ajustado para un rendimiento
ptimo. Para esto se pueden utilizar diferentes diagramas, a continuacin se mencionan
los principales: diagrama lgico del Data Warehouse (DWLS), diagrama Fsico del Data
Warehouse (DWPS), Diagrama Lgico del cliente (CLS), Diagrama Fsico del cliente
(CPS), Diagrama de Procesos ETL, Procesos de Exportacin y diagramas de transporte.
Los diagramas: Diagrama Lgico del Cliente (CLS), Proceso de Exportacion y Diagrama
Fsico del Cliente (CPS) son utilizados en el caso de que existan Data Marts como
clientes en una estrategia top-down y en el caso de que exista un data Warehouse como
cliente en una estrategia bottom-up punto 3.3.8.
3.3.5. PRUEBAS
El objetivo de este flujo de trabajo es verificar que la implementacin funcione de
acuerdo a lo deseado. Mas espeficicamente el propsito de las pruebas es:
Planear las pruebas requeridas.
Diseara y realizar la pruebas a travs de los casos de prueba requeridos.
Ejecutar las pruebas y analizar los resultados de las mismas.
Ningn diagrama nuevo es creado, pero los diagramas existentes son modificados de
acuerdo a las acciones correlativas tomadas y cambios realizados por motivo de las
pruebas.
3.3.6. MANTENIMIENTO
A diferencia de muchos sistemas, el Data Warehouse nunca est terminado. El objetivo
principal de este flujo de trabajo es el de mantener los proceso de carga y actualizacin
22
Durante este flujo de trabajo puede ocurrir que los usuarios generen nuevos
requerimientos como nuevas consultas, lo cual genera una nueva iteracin.
23
24
PARTE II
ANALISIS Y DISEO DEL DATA MART
CAPITULO 6
REQUERIMIENTOS
6. INTRODUCCION
En este captulo se describen los requerimientos funcionales y no funcionales del Data
Mart.
6.1. REQUERIMIENTOS
Los requerimientos determinan que datos van a estar disponibles en el Data warehouse,
como
estos
datos
estarn
organizado
con
que
frecuencia
estos
sern
actualizados.(Kimbal,1998).
Los datos generales de los empleados incluyen: Cdigo de Empleado, Nombre, Apellido
Paterno, Apellido Materno, nmero de cuenta bancaria, direccin del domicilio, estado
civil, fecha de nacimiento, grupo sanguneo, libreta de servicio militar, nacionalidad,
sexo, nivel salarial , el supervisor del empleado.
La actualizacin de los datos de empleado deber tener frecuencia diaria, cada vez que se
actualice alguno de los datos que se incluyen para el Data Mart, deber registrarse un
histrico del cambio de los datos afectados.
Adicional a los datos de empleados el Data Mart debe permitir el almacenado y consulta
de los datos demogrficos del empleado, como ser seccin, departamento y gerencia
donde este trabaja y el histrico de donde trabajo durante sus aos de servicio en la
empresa, los datos demogrficos tienen una frecuencia de actualizacin por periodos
mensuales.
Planilla de sueldos
Mostrar reporte de sueldos por mes.
Mostrar reporte de sueldos por mes por empleado.
Mostrar reporte de sueldos trimestral.
Mostrar reporte de sueldo trimestral por mes por empleado.
Mostrar anticipos de sueldo.
Mostrar descuentos por empleados.
Mostrar sobregiros de los empleados.
Mostrar reporte de formularios RC-IVA presentados por los empleados.
Mostrar descuentos por RC-IVA de los empleados.
Mostrar detalles de planilla de transporte.
Mostrar detalles de planilla de subsidios.
Mostrar reporte de aguinaldos.
Mostrar reporte de aportes AFP.
6.1.2.2. RENDIMIENTO
El rendimiento del Data Mart debe ser superior a las herramientas utilizadas para la
consulta en los sistemas transaccionales.
6.1.2.3. HERRAMIENTAS
EL Data Mart se construir sobre una Base de Datos Oracle 10g R2, utilizando la
herramienta Oracle Warehouse Builder para el desarrollo y construccin del modelo
dimensional.
En la figura siguiente se muestra el modelo del dominio el cual contiene los principales
objetos y sus atributos identificados a partir de los requerimientos funcionales. En el
contexto del modelo del Data Warehouse las clases del dominio representan los hechos y
dimensiones.
Id.
H1
Clase
EntradaSalida
Descripcin
Representa los hechos generados a consecuencia
de las asistencia diaria de los empleados al
trabajo: Fecha, Horas de Ingreso y horas de
salida
H2
Faltas
Atraso
H4
Permisos
H5
Suspensin
H7
BajaMedica
ID
D8
Clase
Empleado
Descripcin
Representa los empleados de la empresa, as
como los superiores de cada empelado
D10
NivelSalarial
D11
Cargo
D12
rea
D13
TipoEntradaSalida
D14
TipoFalta
D15
TipoPermiso
D16
TipoAtraso
D17
TipoSuspencin
Los actores que se identificaron para del Data Mart son los siguientes:
uc Actors
Tcnico de Sistemas
Auxiliar Control de
Personal
Numero
CASO DE USO
CU001
CU002
CU003
CU004
CU007
CU008
Mostrar Asistencia
Mostrar asistencia diaria
CU009
CU010
CU011
Mostrar Atrasos
Mostrar atrasos diarios
CU012
CU013
CU014
Mostrar Faltas
Mostrar faltas diarias
CU015
CU016
CU017
Mostrar Permisos
Mostrar permisos por hora
CU018
CU019
CU020
CU021
CU022
Mostrar Suspenciones
CU023
CU024
CU025
CU026
CU027
Autenticar Solicitante
<<extend>>
(from Seguridad)
<<include>>
<<extend>>
Mostrar historico de empleados
por departamento
Caso de Uso
Id
CU001
Actores
Precondicin
datos de empleados.
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
*
+Tiene
+Presente
Periodo
-
Ao
Mes
Caso de Uso
Id
CU003
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
CodificacionGerencia
NombreGerencia
+Tiene
+Tiene
+Presente
Gerencia
<<extend>>
Caso de Uso
Id
CU003
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
CodificacionDepartamento
NombreDepartamento
+Tiene
+Tiene
+Presente
Departamento
Caso de Uso
Id
CU004
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
CodificacionSeccion
NombreSeccion
+Tiene
+Tiene
+Presente
Seccion
Mostrar asistencia
diaria
extend
Mostrar Asistencia
extend
Mostrar asistencia
diaria por gerencia
Caso de Uso
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Id
CU007
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar asistencia
diaria
extend
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU008
Actores
Precondicin
Flujo Bsico
Ninguna
Puntos de
Extensin
Ninguno
Mostrar asistencia
diaria por gerencia
extend
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU009
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
uc Atrasos
Mostrar atrasos
diarios
extend
Mostrar Atrasos
Mostrar atrasos
diarios por gerencia
Auxiliar Control de
Personal
(from Actors)
extend
Caso de Uso
Mostrar Atrasos
Id
CU010
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar atrasos
diarios
extend
Mostrar Atrasos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU011
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
Mostrar atrasos
diarios por gerencia
extend
Mostrar Atrasos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU012
Actores
Precondicin
Flujo Bsico
Ninguna
Puntos de
Extensin
Ninguno
extend
Mostrar Faltas
Mostrar faltas diarias
por gerencia
extend
Caso de Uso
Mostrar Atrasos
Id
CU013
Actores
Auxiliar Control de
Personal
(from Actors)
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
uc Faltas
Mostrar Faltas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU014
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
extend
Mostrar Faltas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU015
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
extend
Mostrar Permisos
extend
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar Premisos
Id
CU016
Actores
Precondicin
Flujo Bsico
Ninguna
Puntos de
Extensin
extend
Mostrar Permisos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU017
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
uc Permisos
Mostrar Permisos
extend
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU018
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
uc Baj a Medica
Mostrar Baj as
medicas por dia
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
extend
Mostrar Baj as
medicas por mes
Caso de Uso
Id
CU019
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar Baj as
medicas por dia
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU020
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
Mostrar Baj as
medicas por mes
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU021
Actores
Precondicin
Flujo Bsico
Ninguna.
Puntos de
Extensin
Ninguno.
Mostrar suspenciones
por dia
extend
Mostrar
Suspenciones
extend
Auxiliar Control de
Personal
(from Actors)
Mostrar
suspenciones por
mes
Caso de Uso
Mostrar Suspensiones
Id
CU022
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar suspenciones
por dia
extend
Mostrar
Suspenciones
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU023
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
Mostrar
suspenciones por
mes
extend
Mostrar
Suspenciones
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU024
Actores
Precondicin
Flujo Bsico
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
Programar tareas de
carga del Data Mart
Tcnico de Sistemas
(from Actors)
Ej ecutar tareas de
carga del Data Mart
Tcnico de Sistemas
(from Actors)
uc Seguridad
Autenticar Solicitante
7. ANALISIS
En este captulo se realiza el anlisis de la arquitectura del del Data Mart y se define las
fuentes de datos a un nivel conceptual, lgico y fsico.
Cargar Datos
Seguridad
Autenticar Solicitante
(from Seguridad)
Empleado
<<extend>>
Mostrar historico de empleados
por departamento
(from Empl eado)
<<extend>>
Mostrar historico de empleados
(from Empl eado)
<<extend>>
Mostrar historico de empleados
por seccion
(from Empl eado)
siglas en ingles, el cual es un simple diagrama de clases que representa solamente las
clases persistentes de los sistemas operacionales de donde se obtienen los datos.
RHX_PRM_ORG
RHX_TRN_AST
COD_EMP : SMALLINT
PRD_AST : VARCHAR(7)
TUR_AST : SMALLINT
HRA_REF_AST : VARCHAR(5)
FCH_AST : DATE
PER_AST : VARCHAR(5)
HRA_INI_PER_AST : VARCHAR(5)
HRA_FIN_PER_AST : VARCHAR(5)
ATR_AST : VARCHAR(5)
HRA_INI_ATR_AST : VARCHAR(5)
FCL_AST : DECIMAL(4, 2)
FSL_AST : DECIMAL(4, 2)
BJA_MED_AST : DECIMAL(4, 2)
SPS_AST : DECIMAL(4, 2)
OPC_AST : VARCHAR(15)
PERID_AST : INTEGER
ASTID : INTEGER
0..*
RHX_DIC_CARGO
COD_CAR : SMALLINT
DSC_CAR : VARCHAR(30)
EST_CAR : VARCHAR(10)
CARGOID : INTEGER
RHX_TRN_VAC
GST_ORG : SMALLINT
COD_ORG : VARCHAR(10)
DSC_ORG : VARCHAR(40)
EST_ORG : VARCHAR(10)
ORGID : INTEGER
COD_EMP_TRN_VAC : SMALLINT
NRO_TRN_VAC : SMALLINT
GST_TRN_VAC : VARCHAR(10)
0..*
FCH_VNC_TRN_VAC : DATE
FCH_TRN_TRN_VAC : DATE
FCH_INI_TRN_VAC : DATE
GLS_INI_TRN_VAC : VARCHAR(20)
FCH_FIN_TRN_VAC : DATE
GLS_FIN_TRN_VAC : VARCHAR(25)
DIA_MAD_TRN_VAC : SMALLINT
DIA_REAL_TRN_VAC : DECIMAL(4, 2)
DIA_CTA_TRN_VAC : DECIMAL(4, 2)
DIA_SLD_TRN_VAC : DECIMAL(4, 2)
DIA_VAC_TRN_VAC : DECIMAL(4, 2)
COD_REM_TRN_VAC : SMALLINT
OBS_TRN_VAC : VARCHAR(150)
TRNVACID : INTEGER
SLD_ANT_TRN_VAC : DECIMAL(4, 2)
1..*
0..1
0..1
RHX_MAE_EMP
COD_EMP : SMALLINT
PATERNO : VARCHAR(20)
MATERNO : VARCHAR(20)
NOMBRE : VARCHAR(20)
0..* SEX_EMP : VARCHAR(2)
FCH_NAC_EMP : DATE
EST_CIV_EMP : VARCHAR(15)
NRO_DOC_EMP : VARCHAR(15)
EXP_DOC_EMP : VARCHAR(2)
DIR_EMP : VARCHAR(40)
TEL_EMP : VARCHAR(50)
NAC_EMP : VARCHAR(15)
COD_PRF : SMALLINT
FRM_EMP : VARCHAR(35)
LIB_MIL_EMP : VARCHAR(10)
LIC_CND_EMP : VARCHAR(15)
GRP_SNG_EMP : VARCHAR(15)
FCH_ING_EMP : DATE
COD_ORG_EMP : VARCHAR(10)
COR_EMP : SMALLINT
COD_CAR_EMP : SMALLINT
CAR_EMP : VARCHAR(45)
NIV_SAL_EMP : SMALLINT
NRO_CRD_EMP : INTEGER
CLAVE : VARCHAR(20)
0..*
RHX_TRD_RELOJ
RELOJID : INTEGER
COD_EMP : SMALLINT
FCH_TRN : DATE
HRA_TRN : DATE
CRL_TRN : INTEGER
TIP_TRN : VARCHAR(50)
Cdigo
Nombre
Descripcin
SCS001
RHX_MAE_EMP
SCS002
RHX_DIC_CARGO
RHX_PRM_ORG
SCS004
RHX_TRN_AST
SCS005
RHX_TRD_RELOJ
SCS006
RHX_TRN_VAC
deployment Nodes
Oracle 10g
Arreglo de Discos
Serv idor de Almacenamiento
{RAID 5}
table space
RHX_DATOS
deployment Artifacts
table
RHX_TRN_VAC
table
RHX_MAE_EMP
table
RHX_DIC_CARGO
table space
RHX_DATOS
table
RHX_TRN_AST
table
RHX_PRM_ORG
table
RHX_TRD_RELOJ
8. DISEO
En este captulo se realiza el diseo conceptual del Data Mart y la etapa de integracin
con las fuentes de datos. En el diseo conceptual del Data Mart se utiliza el modelo
multidimensional en el diseo conceptual de Integracin se utilizan los mapeos de datos.
En la fase de anlisis se empaquetaron los casos de uso de acurdo a los temas del
negocio que se analizan con el Data Mart, adems de otros aaspectos como la gestin de
ingreso y la carga de datos.
Control de Asistencia
Area
Empleado
Nivel Salarial
HechosEmpleado
DIMENSIN EMPLEADO
class DimensionEmpleado
Empleado
Descripcion
Empleado
8.1.1.1.1.2.
Niv el Salarial
8.1.1.1.1.3.
DIMENSION AREA
class Area
Area
Descripcion del
Area
Gerencia
Departamento
Seccion
8.1.1.1.1.4.
DIMENSION PERIODO
class Periodo
Periodo
Descripcion del
Periodo
Asistencia
Descripcion
Asistencia
Tipo de Asistencia
Atraso
Descripcion Atraso
Tipo Atraso
Baj a Medica
Descripcion Baj a
Medica
class Falta
Falta
Descripcion de Falta
Tipo de Falta
Permiso
Descripcion
Permiso
Tipo de Permiso
class Suspencion
Suspencion
Descripcion
Suspencion
Tipo de
Suspencion
Tiempo
Hora
Dia
Anio
Mes
REFERENCIAS BIBLIOGRAFICAS
(Kimbal,1998) Kimball, Ralph. The Data Warehouse Lifecycle Toolkit. Impreso en
Estados Unidos:Wiley, 1998.
ORACLE.
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
Consultado 19 de agosto del 2010