Documentos de Académico
Documentos de Profesional
Documentos de Cultura
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA
DE SISTEMAS E INFORMATICA
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA Y DE
SISTEMAS
PROYECTO:
ALUMNOS:
CURSO:
DEDICATORIA
A nuestros queridos padres que con su esfuerzo
de nuestros conocimientos.
AGRADECIMIENTO
Agradecemos a Dios por darnos la oportunidad
presente en la vida.
INDICE
Carátula…………………………………………………………………………………………….1
Contra carátula………………………………………………………………………………….2
Dedicatoria………………………………………………………………………………………..3
Agradecimiento……………………………………………….………………………………..4
Índice General………………………………………………….……………………………….5
Índice De Tablas……………………………………………….……………………………….9
Índice De Figuras……………………………………………….………………………………9
Resumen……………………………………………………………………………………………10
Abstract………………………………………………………………………. …………………..12
Introducción………………………………………………………………………………………14
CAPITULO I:
GENERALIDADES……………………………………………………….…………15
Descripción……………………………………………………………………………..…………17
INTEGRANTES……………………………………..……………………………………………..18
LOGOTIPO DE LA ORGANIZACIÓN……………………………………..……………….18
Reseña Histórica……………………………………………………………………..………….19
Visión………………………………………………………………………………………………….20
Misión…………………………………………………………………………………….………….20
Organigrama……………………………………..………………………………………………..21
Pictograma……………………………………..……………………………………………………22
CAPITULO II:
MARCO TEORICO……………………………………………………..……………23
2.1 Antecedentes…………………………………………………………………………….24
CAPITULO III:
DESCRIPCION DE LA METODOLOGIA…………………………………..41
3.2.3 Pasaje……….……….……….……….……….……….…………………..44
3.3.1 Contenido……….……….……….……….……….……….……………..45
3.3.2 Objetivo……….……….……….……….……….……….………………..45
3.7 Modelado……….……….……….……….……….……….……………………….55
3.8 Evaluación……….……….……….……….……….……….………………………..57
3.9 Desarrollo……….……….……….……….……….………………59
CAPITULO IV:
APLICACIÓN DE LA METODOLOGIA……………………………61
4.1.1 Contexto……………………………………………………………………………….62
4.2.4 Terminología………………………………………………………….……………70
INDICE TABLAS
Tabla 3.1.……………………………………………………………………………………………..41
INDICE FIGURAS
Figura 1.1 Logotipo EGB.……………………………………………………………………..18
Figura 1.2 Organigrama EGB………………………………………………………………. 21
Figura 1.3 Pictograma EGB………………………………………………………………… 22
Figura 2.1. Esquema Estrella. …………………………………………………………….. 27
Figura 2.2. Esquema Copo de Nieve…………………………………………………… 28
Figura 2.3. Cubo Multidimensional……………………………………………………. 33
Figura 2.4. Dimensiones y Jerarquías. ……………………………………………..... 34
Figura 2.5. Ejemplos de Transformación…………………………………………….. 38
Figura 3.1. Niveles de interrupción ..………………………………………………….. 43
Figura 3.2 Fases del Modelo……….. ..………………………………………………….. 46
Figura 3.3 Fases Genéricas………… ..………….………………………………………… 48
Figura 3.4.Comprensión del negocio….……………………………………….. …… .48
Figura 3.5. Comprensión de datos ..………………………………………………….. .51
Figura 3.6 Preparación de datos ..………………………………………………………53
Figura 3.7. Modelado…………………....………………………………………………….. .55
Figura 3.8 .Evaluación……………….. ..……………………………………………………. 57
Figura 3.9. Desarrollo……………….. ..………………………………………………….. …59
Figura 4.1 Plan Del Proyecto………………………………………………………………..72
RESUMEN
El presente informe consta de a elaboración de sistema para evitar el desabastecimiento de la
farmacia del Hospital Eleazar Guzmán Barron utilizando minería de datos.
En dicho sistema intervienen: Jefa De Farmacia, Jefa de ventas, Encargado del kárdex ,
Secretaria De Farmacia pero en este caso solo la jefa de farmacia y la jefa de ventas serán
quienes interactúen con el sistema
Basados en nuestras investigaciones a fondo y entrevistas con los diferentes actores que
intervienen en este Sistema establecemos las relaciones de dicha manera:
Las compras son solicitadas por la jefatura de ventas quien envía un documento hacia
la jefatura de ventas para su aprobación.
o Nacional: Se realiza una vez al año en el mes de junio, los pedidos son
enviados al MINSA (ministerio de salud) quien junta los pedidos que llegan de
todo el país y las compras totales se dan en licitación.
Este es el ciclo de compras, la idea es crear un software para simular agentes extraños como el clima,
virus estacionarios, ya que estos pedidos se hacen en relación a ventas realizados en el mes anterior.
Con este software seria posible evitar el desabastecimiento ya que estaríamos preparados para
mayores ventas.
Habiendo detallado todo nuestro Sistema procedemos a elaborar nuestros procesos a seguir para así
obtener un buen Sistema Informático que brindar al Hospital Regional Eleazar Guzmán Barron
ABSTRACT
The formless present consists of to system elaboration to avoid the desabastecimiento
of the pharmacy of the Hospital Eleazar Guzmán Barron using mining of data.
In this system they intervene: Boss Of Pharmacy, Boss of sales, Taken charge of the
kardex, Secretary Of Pharmacy but in this alone case the pharmacy boss and the boss
of sales will be who interactúen with the system
Thoroughly based on our investigations and you interview with the different actors that
intervene in this System we establish the relationships in a this way:
The document is sent the pharmacy boss who revises the order for its approval.
o National: He/she is carried out once a year in the month of June, the
orders are correspondents to the MINSA (ministry of health) who it joins
the orders that they arrive of the whole country and the total purchases
are given in bid.
o Regional: Carried out when for some reason they need medications for
reservation, they send their order to Huaraz who joins the order. The sale
is also carried out for bid,
This is the cycle of purchases, the idea it is to create a software to simulate strange
agents as the climate, stationary virus, since these orders are made in relation to sales
carried out in the previous month. With this serious software possible to avoid the
desabastecimiento since we would be prepared for further sales.
Having detailed all our System we proceed to elaborate our processes to continue
he/she stops this way to obtain a good Computer System that to offer to the Regional
Hospital Eleazar Guzmán Barron
INTRODUCCION
Hoy en día, y está claro que se trata de una tendencia válida para los próximos años,
el almacenamiento de la información es algo sencillo y barato. Nuestros sistemas
informáticos cada vez tienen una capacidad mayor, y lo que ahora es normal encontrar
(una hoja de cálculo en el caso más simple) para localizar correlaciones entre
variables, establecer medias y varianzas e intentar modelar de esta forma nuestra
información.
Sin embargo, en esa montaña de datos existe información que no puede ser
encontrada con los procedimientos habituales de trabajo. La minería de datos nos
ayuda a dar un paso más en ese análisis sacando a la luz relaciones ocultas entre los
datos: información desconocida que pueda ayudarnos a gestionar mejor nuestro
negocio o proceso.
El propósito de este proyecto es lograr establecer los puntos más importantes y los
actores principales que participan, proponemos construir un sistema dinámico y de
acceso restringido en donde se pueda elaborar los principales registros estableciendo
así una base de datos que constantemente se va actualizar ante la entrada o salida de
datos
CAPITULO I
GENERALIDADES
EL
DESABASTECIMIENTO
APLICANDO MINERIA DE
DATOS
DESCRIPCION:
EL SIGUIENTE PROYECTO PRESENTADO FUE ELABORADO CON LA INTENCION DE EVITAR QUE LA
FARMACIA DEL HOSPITAL SE VEA DESABASTECIDA.
LA TAREA DEL SISTEMA ES CAPTAR LOS DATOS QUE CONTIENE ALMACENADOS EN SU BASE DE DATOS
PARA GENERAR ALTERNATIVAS DE SOLUCION EN ESTE CASO ANTE EL DESABASTECIMIENTO.
ADEMAS PERMITIRA QUE LOS PACIENTES SE SIENTAN MAS SATISFECHOS CADA VEZ QUE SE ATIENDAN
EN EL HOSPITAL Y QUE TENGAN QUE COMPRAR MEDICAMENTOS EN LA FARMACIA DE ESTE.
1.1 INTEGRANTES
DIRECCION EJECUTIVA
1.4 VISION
Al año 2011 ser un hospital modelo, competente y docente de categoría III-1, líder en la región,
con personal calificado, especializado y comprometido que brinda respuestas efectivas, eficiente
y de calidad de atención integral de la salud con equidad, calidez, facilitando el acceso y la
participación ciudadana para el autocuidado de la salud y el desarrollo de estilos de vida
saludable que favorezcan el desarrollo integral y sostenible de la Ciudadanía mediante la
planificación estratégica y tecnología de punta para la satisfacción del usuario.
1.5 MISION
Somos una institución que brindamos atención de salud integral, para mejorar la calidad de vida
de la persona, familia y comunidad, articulando esfuerzos con la sociedad organizada para
promover la salud, prevenir los riesgos, recuperar del daño y rehabilitar las capacidades, con
trabajadores capaces y mística de servicio para las personas desde la preconcepción hasta su
muerte, con el enfoque de salud como derecho, respeto a la diversidad cultural y equidad de
genero.
1.6 ORGANIGRAMA
1.7 PICTOGRAMA
CAPÍTULO II
MARCO TEÓRICO
2.1 ANTECEDENTES.
Sin embargo, cabe indicar que hasta el presente no se han desarrollado trabajos sobre Data Mart,
Datamining y Toma de Decisiones en el ámbito del Consumo de Medicamentos y,
específicamente, en el Hospital Regional Eleazar Guzmán Barron.
Asimismo, con relación a las variables del tema, no se han encontrado investigaciones que
hayan abordado estos temas aplicados a la problemática planteada, con lo cual consideramos
que la presente investigación reúne las condiciones metodológicas suficientes para ser
considerada inédita.
Para cumplir estos objetivos se necesitan efectuar consultas que sumarizan los datos, y
que si se hacen sobre los sistemas operacionales reducen mucho la performance de las
transacciones que se están haciendo al mismo tiempo. Fue entonces que se decidió
separar los datos usados para reportes y toma de decisiones de los sistemas operacionales
y así, diseñar y construir los llamados DataWarehouses para almacenar estos datos.
• Diseño Lógico.
- Preparar el Data Warehouse para soportar la recuperación de una gran cantidad de filas de
datos en forma rápida.
- La mayoría de los analistas de negocios van a querer ver datos totalizados. Estos datos en lo
posible deben precalcularse y almacenarse de antemano para que esta recuperación sea rápida y
eficiente. Es importante además discutir el nivel de granularidad y de detalle esperado por los
analistas cuando hacen operaciones de DRILLDOWN.
- El diseño debe estar conducido por el acceso y por el uso, es decir, teniendo en cuenta qué tipo
de reportes o resúmenes son los más frecuentes, y cuáles los más urgentes.
- Todos los datos que se incluyan ya deben existir en las fuentes de datos operacionales, o ser
derivables a partir de ellos. [PATRICIA ZVENGER]
Las dos técnicas de diseño más populares de almacenamiento lógico de un DataWarehouses son
las siguientes:
Esquema Estrella.
Este esquema está formado por un elemento central que consiste en una tabla llamada la Tabla
de Hechos, que está conectada a varias Tablas de Dimensiones.
Las tablas de hechos contienen los valores precalculados que surgen de totalizar valores
operacionales atómicos según las distintas dimensiones, tales como clientes, productos o
períodos de tiempo.
Las tablas de hechos representan un evento crítico y cuantificable en el negocio, como ventas o
costos.
Su clave está compuesta por las claves primarias de las tablas de dimensión relacionadas (las
FOREIGN KEYS). Pueden existir varias tablas de hechos con información redundante, porque
podrían contener distintos niveles de agregación de los mismos datos.
Por ejemplo podría existir una tabla de hechos para las Ventas por Sucursal, Región y Fecha,
otra para Ventas por Productos, Sucursal y Fecha, y otra para Ventas por Cliente, Región y
Fecha.
En general las tablas de hechos tienen muchas filas y relativamente pocas columnas.
Las tablas de dimensión representan las diferentes perspectivas desde donde se ven y analizan
los hechos de la tabla de hechos. A diferencia de las anteriores, su clave primaria está formada
por un solo atributo, y su característica principal es que están denormalizadas. Esto significa que
si la dimensión incluye una jerarquía, las columnas que la definen se almacenan en la misma
tabla dando lugar a valores redundantes, lo cual es aceptable en este esquema.
En general suelen tener muchas columnas pero pocas filas. Siempre que sea posible, es
conveniente compartir las tablas de dimensión entre distintas tablas de hechos.
Una de las dimensiones mas comunes es la que representa el tiempo, con atributos que
describen periodos para años, cuatrimestres, periodos fiscales, y periodos contables.
Otras dimensiones comunes son las de clientes, productos, representantes de ventas, regiones,
sucursales.
El esquema estrella es el más usado porque maneja bien la performance de consultas y reportes
que incluyen años de datos históricos, y por su simplicidad en comparación con una base de
datos normalizada.
Es una variante del esquema estrella en el cual las tablas de dimensión están normalizadas, es
decir, pueden incluir claves que apuntan a otras tablas de dimensión.
Las ventajas de esta normalización son la reducción del tamaño y redundancia en las tablas de
dimensión, y un aumento de flexibilidad en la definición de dimensiones.
Sin embargo, el incremento en la cantidad de tablas hace que se necesiten más operaciones de
unión para responder a las consultas, lo que empeora la performance, además del mantenimiento
que requieren las tablas adicionales.
• Diseño Físico.
Entre las decisiones de implementación que se deben tomar se incluyen el tamaño del espacio
libre, el tamaño del buffer, el tamaño del bloque, y si se usa o no una técnica de compactación
de la base de datos.
Todas estas cuestiones afectarán la performance del DataWarehouse. Algunos temas que
impactan sobre el rendimiento del Datawarehouse son:
- Particionamiento. Generalmente cuando se hablan de base de datos enormes, donde las tablas
de hechos ocupan varios cientos de gigabytes. El particionamiento permite que los datos de una
tabla lógica, esté en varios datos físicos.
El particionamiento es importante, pues permite realizar respaldos de porciones de una tabla, sin
impactar en su accesibilidad. Por otro lado, permite guardar información mas frecuentemente
accedidos, en dispositivos más rápidos. [PATRICIA ZVENGER]
- Clustering. Es una técnica útil, para el acceso secuencial de grandes cantidades de datos. Se
obtiene definiendo un índice de clustering para una tabla, el cual determina el orden secuencial
físico en el que se almacenan las filas en los conjuntos de datos.
Esta técnica mejora drásticamente el acceso secuencial, y es la técnica mas usada para
procesamiento OLAP. Cuando las filas de la tabla no permanezcan almacenadas en el orden
correspondiente a su índice clustering, situación conocida como fragmentación, la performance
bajará y habrá que reorganizar la tabla. [PATRICIA ZVENGER]
- Indexado. Existen dos estrategias extremas de indexado: una es indexar todo, y la otra es no
indexar nada, pero ninguna de las dos es conveniente. Las columnas que se elijan para indexar
deben ser las que se usan más frecuentemente para recuperar las filas, y las que tienen una alta
distribución de valores, no una baja como por ejemplo Código Postal.
Una vez que se determinan las columnas a indexar, hay que determinar la estrategia de índice.
La mayoría de las DBMSs proveen varios algoritmos, entre ellos B-tree, Hash, archivo
Invertido, Sparse y Binario. Se debería optar por el más óptimo para el producto DBMSs que se
está usando. [PATRICIA ZVENGER]
- Reorganizaciones. Las cargas incrementales de las bases de datos irán fragmentando las tablas,
y esta fragmentación puede resultar en un decaimiento de la performance. La mayoría de las
DBMSs proveen rutinas de reorganización para reclamar el espacio fragmentado y mover
registros.
Las actividades básicas involucradas en la reorganización de una base de datos implican copiar
la base de datos vieja en otro dispositivo, rebloquear las filas y recargarlas. Estas tareas no son
triviales en un Data Warehouse, pero todos los DBMSs permiten reorganizar particiones, lo cual
es otra buena razón para particionar las tablas.[PATRICIA ZVENGER]
- Backup y Recupero. Los DBMSs proveen utilidades para hacer backups completos y también
incrementales. Muchas organizaciones tienen la errónea impresión de que los DataWarehouses
siempre se pueden recrear a partir de las fuentes de datos originales. Sin embargo, además de
que esta tarea puede llevar mucho tiempo porque hay que reejecutar los programas de
extracción, transformación y carga, es posible que estos programas y los datos mismos ya
- Ejecución de las consultas en paralelo. Para mejorar la performance de una consulta es mejor
dividirla en componentes que ejecuten concurrentemente. Algunos DBMSs ofrecen ejecución
paralela en forma transparente, es decir, dividen la consulta por si solos. [PATRICIA
ZVENGER]
2.2.2 DATAMART.
Las corporaciones de hoy se esfuerzan por conducir sus negocios hacia una base internacional.
Vemos compañías que surgieron en Estados Unidos y se expandieron a Europa, Asia y África.
La expansión del negocio crea la necesidad de acceder a datos corporativos que están ubicados
en diferentes puntos geográficos. Por ejemplo, un ejecutivo de ventas de una compañía con
origen en Brasil que está situado en Chile puede necesitar acceso a la base de datos de la
empresa para identificar los clientes potenciales que residen solo en Chile.
Este problema se soluciona creando versiones más pequeñas del Data Warehouse, los datamarts.
Estas versiones se crean usando algún criterio particular, como por ejemplo el lugar geográfico.
En el ejemplo anterior los datos de los clientes que residen en Chile se deben almacenar en el
datamart de la sucursal en ese país.
La existencia de los datamarts crea nuevas formas de pensar cuando se diseñan los repositorios
corporativos de datos.
Otras compañías usan datamarts para complementar sus DataWarehouses. Mueven datos desde
el DataWarehouses hacia varios datamarts con el fin de permitir un análisis más eficiente. La
separación de los datos se determina según criterios como departamentos, áreas geográficas,
periodos de tiempo, etc.
Finalmente, algunas organizaciones usan sus datamarts como el primer paso de almacenamiento
de datos operacionales.
Luego los datos de todos los datamarts se replican en un DataWarehouse corporativo central.
[PATRICIA ZVENGER].
Los usuarios de herramientas OLAP se mueven desde una perspectiva de negocio a otra, por
ejemplo, pueden estar observando las ventas anuales por sucursal y pasar a ver las sucursales
con más ganancias en los últimos tres meses, y además con la posibilidad de elegir entre
diferentes niveles de detalle, como ventas por día, por semana o por cuatrimestre. Es esta
exploración interactiva lo que distingue a OLAP de las herramientas simples de consulta y
reportes. [PATRICIA ZVENGER]
El análisis multidimensional, permite a los analistas de negocios examinar sus indicadores clave
o medidas, como ventas, costos, y ganancias, desde distintas perspectivas, como periodos de
tiempo, productos, regiones. Estas perspectivas constituyen las dimensiones desde las que se
explora la información.
La escala empresarial, se refiere a que OLAP trabaja con fuentes de datos corporativos, que
contienen datos de toda la empresa.
Para proveer estas características, toda herramienta OLAP tiene tres principales características:
• Un motor OLAP que procesa las consultas multidimensionales sobre los datos.
que se van a analizar. Este componente puede ser externo a la herramienta, como un RDBMS o
un Data Warehouse.
CUBOS MULTIDIMENSIONALES
En una base de datos multidimensional, el modelo de datos esta constituido por lo que se
denomina un Cubo multidimensional o simplemente Cubo. En un cubo la información se
representa por medio de matrices multidimensionales o cuadros de múltiples entradas, que nos
permite realizar distintas combinaciones de sus elementos para visualizar los resultados desde
distintas perspectivas y variando los niveles de detalle. Esta estructura es independiente del
sistema transaccional de la organización, facilita y agiliza la consulta de información histórica
ofreciendo la posibilidad de navegar y analizar los datos.
Aquí vemos como ejemplo un cubo multidimensional que contiene información de ventas
discriminadas por periodos de tiempo, productos y zonas geográficas de la empresa.
Los ejes del cubo son las Dimensiones, y los valores que se presentan en la matriz, son las
Medidas. [PATRICIA ZVENGER]
DIMENSIONES
Son objetos del negocio con los cuales se puede analizar la tendencia y el comportamiento del
mismo. Las definiciones de las dimensiones se basan en políticas de la compañía o del mercado,
e indican la manera en que la organización interpreta o clasifica su información para segmentar
el análisis en sectores, facilitando la observación de los datos.
Para determinar las dimensiones requeridas para analizar los datos podemos hacer preguntas
como: Cuándo, Dónde, Qué, Quién, Cuál, etc. [PATRICIA ZVENGER]
MEDIDAS O METRICAS
Son características cualitativas o cuantitativas de los objetos que se desean analizar en las
empresas. Las medidas cuantitativas están dadas por valores o cifras porcentuales.
Por ejemplo, las ventas en dólares, cantidad de unidades en stock, cantidad de unidades de
producto vendidas, horas trabajadas, el promedio de piezas producidas, el porcentaje de
aceptación de un producto, el consumo de combustible de un vehículo, etc. [PATRICIA
ZVENGER]
En el grafico anterior, los niveles de Zonas y Gerencia no están relacionados entre si, a pesar de
que ambos están relacionados con las Áreas. [PATRICIA ZVENGER]
Las bases de datos relacionales están optimizadas para obtener una performance óptima en
consultas simples y frecuentes, pero no funcionan de manera ideal para las consultas
multidimensionales y complejas de estas aplicaciones, ya que existen muchas de ellas que no se
pueden expresar en una única consulta SQL, y seguramente se requerirán muchas operaciones
de JOIN, lo cual reduce drásticamente el tiempo de respuesta de la consulta.
Las herramientas OLAP que usan almacenamiento multidimensional son llamadas MOLAP,
mientras que a las que almacenan los datos en bases relacionales se les llama herramientas
ROLAP.
Las herramientas que combinan los dos enfoques se conocen como OLAP Híbrido u HOLAP.
Cada alternativa tiene sus ventajas y desventajas. En lugar de discutir cual de las dos es mejor
hay que definir un criterio para optar por una u otra, y evaluar el alcance de HOLAP, que en la
práctica intenta combinar lo mejor de ambos mundos.
MOLAP
• Buena performance en las consultas, ya que el almacenamiento esta optimizado para el análisis
multidimensional.
• La escalabilidad está limitada por la capacidad del Motor de Base de Datos y por el tiempo de
carga de los datos.
• Puede requerir aprendizaje por ser una tecnología nueva en la organización. [PATRICIA
ZVENGER]
ROLAP
• Además del análisis de información sumarizada, se pueden analizar datos detallados hasta el
nivel de las transacciones.
• La herramienta ROLAP requiere un DataWarehouse de donde extraer los datos para analizar.
• Las cuestiones técnicas del manejo de los datos está a cargo del Motor de Base de Datos.
La mayoría de los datos de origen son los datos operacionales actuales, aunque parte de ellos
pueden ser datos históricos archivados.
Si los requerimientos de datos incluyen algunos años de historia es necesario desarrollar tres
conjuntos de programas ETL: una Carga Inicial, una Carga Histórica, y una Carga Incremental.
Carga Inicial
Carga Histórica
Este proceso debe verse como una extensión de la carga inicial, pero la conversión aquí
es un poco diferente porque los datos históricos son datos estáticos.
Carga Incremental
Una vez que el DataWarehouse está cargado con datos iniciales e históricos, hay que
desarrollar otro proceso para la carga incremental, que se ejecutará mensual, semanal o
diariamente. Existen dos formas de diseñar la carga incremental:
En general esta opción no es viable debido al volumen de los datos, por eso la
mayoría opta por la siguiente opción.
Diseñar programas ETL para extracciones delta es más fácil cuando las fuentes
consisten en bases de datos relacionales y contamos con una columna
“timestamp” para determinar los deltas. [PATRICIA ZVENGER]
B. Transformar Datos. Este proceso es el más crítico, debido a que debe controlar
Los algoritmos de Data Mining utilizan técnicas que han existido por lo menos desde
hace 10 años, pero que sólo han sido implementadas recientemente como herramientas
maduras y confiables.
- Predicción: Esta función de la minería predice los valores posibles de datos faltantes o
la distribución de valores de ciertos atributos en un conjunto de objetos.
- Clustering: Identifica clusters en los datos, donde un cluster es una colección de datos
Analiza un gran conjunto de datos obtenidos con el correr del tiempo para encontrar en
él regularidades y características interesantes, incluyendo la búsqueda de patrones
secuenciales, periódicos, modas y desviaciones.
CAPITULO III:
Descripción de la
metodología
3. La metodología CRISP-DM
3.1 Interrupción jerárquica
La metodología de CRISP-DM está descrita en términos de un modelo de proceso
jerárquico, consistente en un conjunto de tareas descritas en cuatro niveles de abstracción
(de lo general a lo específico): fase, tarea genérica, tarea especializada, e instancia de
procesos. (Ver la figura 1.)
En el nivel superior, el proceso de minería de datos es organizado en un número de fases;
cada fase consiste de varias tareas genéricas de segundo nivel. Este segundo nivel lo llaman
genérico porque esta destinado a ser bastante general para cubrir todas las situaciones
posibles de minería de datos. Las tareas genéricas están destinadas a ser tan completas y
estables como sea posible. Completo significa que cubre tanto al proceso entero de
minería de datos y todas las aplicaciones de minería de datos posibles. Estable significa que
el modelo debería ser válido para acontecimientos normales y aún para desarrollos
imprevistos como técnicas de modelado nuevo.
El tercer nivel, el nivel de tarea especializado, es el lugar para describir como las acciones
en las tareas genéricas deberían ser realizadas en ciertas situaciones específicas. Por
ejemplo, en el segundo nivel podría haber una tarea genérica llamada limpieza de datos. El
tercer nivel describe como esta tarea se diferencia en situaciones diferentes, como la
limpieza de valores numéricos contra la limpieza de valores categóricos, o si el tipo de
problema es agrupamiento o el modelado predictivo.
La descripción de fases y tareas como pasos discretos realizados en un orden específico
representa una secuencia idealizada de eventos.
En la práctica, muchas de las tareas pueden ser realizadas en una orden diferente, y esto a
menudo será necesario volver a hacer tareas anteriores repetidamente y repetir ciertas
acciones. Nuestro modelo de proceso no intenta capturar todas estas posibles rutas del
proceso de la minería de datos porque esto requeriría un modelo de proceso demasiado
complejo.
El cuarto nivel, la instancia de proceso, es un registro de las acciones, decisiones, y de los
resultados de una minería de datos real contratada.
Una instancia de proceso esta organizado según las tareas definidas en los niveles más
altos, pero representa lo que en realidad pasó en un contrato particular más bien que lo
que pasa en general.
La figura 3.3 presenta un contexto de fases acompañadas por tareas genéricas y las
salidas. En las secciones siguientes, describimos cada tarea genérica y sus salidas más
detalladamente. Enfocamos nuestra atención en descripciones de tarea y los
resúmenes de salidas.
Figura 3.3 : Tareas genéricas (negritas) y salidas (cursivas) del modelo de referencia
CRISP-DM
3.4 Comprensión del negocio
Listar las presunciones hechas por el proyecto. Estas pueden ser presunciones sobre los datos
que pueden ser verificados durante la minería de datos, pero también puede incluir
presunciones no-comprobables sobre el negocio relacionado con el proyecto. Es en particular
importante listar si esto afectará la validez de los resultados.
Listar las restricciones sobre el proyecto. Estas pueden ser restricciones sobre la disponibilidad
de recursos, pero puede también incluir coacciones tecnológicas como el tamaño de conjunto
de datos lo que es práctico para usar el modelado.
Riesgos y contingencias
Listar los riesgos o los acontecimientos que podrían retrasar el proyecto o hacer que ello falle.
Listar los planes de contingencia correspondientes, que acción será tomada si estos riesgos o
acontecimientos ocurren.
Terminología
Compile un glosario de terminología relevante al proyecto. Esto puede incluir dos
componentes:
(1) Un glosario de terminología relevante del negocio, que forma la parte de la comprensión
del negocio disponible al proyecto. La construcción de este glosario es una útil “evocación al
conocimiento” y un ejercicio de educación.
(2) Un glosario de terminología de minería de datos, ilustrada con ejemplos relevantes al
problema del negocio en cuestión.
Costos y beneficios
Construya un análisis de costo-beneficio para el proyecto, que compare los gastos del proyecto
con los beneficios potenciales al negocio si esto es exitoso. La comparación debería ser tan
específica como posible. Por ejemplo, use medidas monetarias en una situación comercial.
3.4.3 Determinación de los objetivos de la minería de datos
Tarea Determinar los objetivos de la minería de datos
Un objetivo de negocio declara objetivos en la terminología de negocio. Un objetivo de minería
de datos declara objetivos de proyecto en términos técnicos. Por ejemplo, el objetivo de
negocio podría ser “Aumentar catálogos de ventas a clientes existentes.” Un objetivo de
minería de datos podrían ser “Predecir cuantas baratijas un cliente comprará, obteniendo
datos de sus compras de tres años pasados, información demográfica (edad, sueldo, ciudad,
etc.), y el precio del artículo.”
Salida Objetivos de la minería de datos
Describir las salidas intencionadas del proyecto que permiten el logro de los objetivos de
negocio.
Criterios de éxito de la minería de datos
Definir los criterios de un resultado exitoso para el proyecto en términos técnicos -por
ejemplo, un cierto nivel de predicción precisa o un perfil de inclinación-a-comprar con un
determinado grado de "elevación". Como con un criterio de éxito de negocio, puede ser
necesario describir estos en términos subjetivos, en este caso la persona o las personas que
hacen el juicio subjetivo deberían ser identificadas.
sobre los datos demográficos del área circundante. Cada una de estas tablas contiene un
registro para cada tienda. Estas tablas pueden ser combinadas simultáneamente en una nueva
tabla con un registro para cada tienda, combinando campos de las tablas fuentes.
Los datos combinados también cubren agregaciones. La agregación se refiere a operaciones en
la que nuevos valores son calculados de información resumida de múltiples registros y/o
tablas. Por ejemplo, convirtiendo una tabla de compra de clientes donde hay un registro para
cada compra en una tabla nueva donde hay un registro para cada cliente, con campos tales
como el número de compras, el promedio de la cantidad de compra, el porcentaje de ordenes
cobrados a tarjeta de crédito, el porcentaje de artículos bajo promoción, etc.
3.6.5 Formatear datos
Tarea Formatear datos
Formateando transformaciones se refiere a modificaciones principalmente sintácticas hechas a
los datos que no cambian su significado, pero podría ser requerido por la herramienta de
modelado.
Salida Datos reformateados
Algunas herramientas tienen requerimientos sobre el orden de los atributos, tales como el
primer campo que es un único identificador para cada registro o el último campo es el campo
resultado que el modelo debe predecir.
Podría ser importante cambiar el orden de los registros en el conjunto de datos. Quizás la
herramienta de modelado requiere que los registros sean clasificados según el valor del
atributo de resultado. Comúnmente, los registros del conjunto de datos son ordenados al
principio de algún modo, pero el algoritmo que modela necesita que ellos estén en un orden
moderadamente arbitrario. Por ejemplo, cuando se usa redes neuronales, esto es
generalmente mejor para los registros para ser presentados en un orden aleatorio, aunque
algunas herramientas manejen esto automáticamente sin la intervención explicita del usuario.
Además, hay cambios puramente sintácticos hechos para satisfacer las exigencias de la
herramienta de modelado específica. Ejemplos: el quitar de comas de adentro de campos de
texto en ficheros de datos delimitados por coma, corta todos los valores a un máximo de 32
caracteres
3.7 Modelado
Figura 3. 7: Modelado
Figura 3. 8: Evaluación
3.9 Desarrollo
CAPITULO IV
Aplicando
Metodología
Crisp-dm
Ing. Ricardo Mendoza Rivera Practicas Pre-I 61
UNIVERSIDAD SAN PEDRO
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA
DE SISTEMAS E INFORMATICA
4.1.1.1 Contexto
El Hospital Eleazar Guzmán Barron consta de 15 módulos:
MODULO DE PSICOLOGIA
MODULO DE CIRUGIA
MODULO DE PEDIATRIA
MODULO DE GINECO-OBSTETRICIA
MODULO DE ODONTOESTOMATOLOGIA
MODULO DE ENFERMERIA
MODULO DE FARMACIA
Los ingresos que genera el hospital en mención básicamente están dados de dos
maneras:
En este caso nuestro proyecto esta basado en que existen ocasiones en las que nos
encontramos con clientes quejándose por la falta de medicamentos en farmacia los
cuales son importantes para ellos, esto en el caso del paciente y en el caso del
hospital de la misma forma es importante porque genera mayores ingresos para el
mismo.
LOGO
ORGANIGRAMA
El hospital esta dirigido por el doctor Carlos Enrique Fernández Neyra a su vez el área
encargada de las compras para la jefatura de ventas es el departamento de
Farmacia..
Compra Nacional: Se realiza una vez al año en el mes de junio, los pedidos son
enviados al MINSA (ministerio de salud) quien junta los pedidos que llegan de todo el
país y las compras totales se dan en licitación.
Compra Regional: Realizada cuando por alguna razón necesitan medicamentos para
reserva, envían su pedido a Huaraz quien junta el pedido. La venta también se realiza
por licitación,
Compra Local: En caso de emergencia se realiza a algún agente vendedor que tenga el
Hospital.
Para lo cual esperamos entregar un sistema operacional para ser entendido por
cualquier usuario.
En entrevistas con los responsables del área de farmacia, se supo que la información
con la que cuentan es a modo de reportes estadísticos, donde se visualizan números
que informan el estado del stock de los medicamentos. Adicionalmente a los reportes
ya existentes, constantemente surgen necesidades para obtener información
basándose en nuevos y diversos criterios, para lo que se recurre al área de sistemas y se
solicita los cambios en la emisión del reporte. Vemos aquí la dependencia que tiene con
el área de sistemas y la inflexibilidad con la que se puede obtener información.
Los Lineamientos de Política del Hospital "Eleazar Guzmán Barrón", los siguientes:
¿De igual manera como afecta al paciente el tener que buscar otros lugares donde
encontrar el medicamento existiendo y debiendo encontrarse en el mismo hospital?
¿De Que manera el modelar, construir y cargar una Base De Datos Relacional hacia
Data Mining ayuda a establecer estrategias para la Toma De Decisiones?
Los datos a tratar se encuentran en la base de datos del mencionado hospital, los
cuales se encuentran en SQL SERVER 2000; los datos son ingresados por medio del
sistema hospitalario LOLIMSA.
Todos los datos están almacenados en el servidor del hospital, exactamente en el área
de sistemas.
Nuestras fuentes en este caso son documentos que nos proporciono las doctora
Federinda Doris Álvarez De Osorio, ordenes de compra, kárdex de inventario, PECOSAS,
etc.
También hicimos pequeñas encuestas a los pacientes para saber si estaban satisfechos
con la disponibilidad de los medicamentos en farmacia.
REQUERIMIENTOS
Por seguridad el uso de la base de datos es restringido así que necesitamos de la
compañía de la jefa del área de estadística y informática la Ing. PEREZ LOPEZ EULOGIA
MARIA.
PRESUNCIONES
Necesitamos que los datos con los que vamos a trabajar sean de buena calidad para
que los datos que explotemos también hereden la buena calidad y permitir tomar
decisiones correctas.
RESTRICCIONES
El tiempo es una de nuestras restricciones ya que el proyecto a de ser terminado antes
de la terminación de nuestro ciclo, es decir antes del 31 de julio del 2009.
El acceso a la base de datos es a través el servidor el cual tiene una validación por
intermedio de un usuario y una contraseña.
El sistema operativo de este es Windows Xp, la base de datos en SQL SERVER 2000.
Los datos de compras y ventas están accesibles al ingresar al Server, o por medio des
sistema LOLIMSA al generar los reportes.
4.2.4 Terminología
Kárdex de productos: reporte generado para ver el inventario físico del almacén
de ventas.
unidad de logística.
Conocer como el modelar, construir y cargar una base de Datos relacional a un Data
Mining coadyuva a establecer estrategias para la toma de decisiones.
Microsoft SQL Server Analysis Services proporciona herramientas que puede utilizar
para crear soluciones de minería de datos que le permitan resolver problemas
empresariales concretos.
SQL Server Management Studio proporciona herramientas que puede utilizar para
administrar y explorar los modelos de minería de datos una vez creados. SQL Server
Integration Services contiene herramientas útiles para limpiar datos, para automatizar
tareas como la creación de predicciones o la actualización de modelos y para crear
soluciones de minería de datos de texto.
necesarias para seleccionar un algoritmo y un origen de datos y para definir una tabla
de escenarios.
crear nuevos modelos de minería de datos, así como implementar, examinar, comparar
y crear predicciones de los modelos de minería de datos existentes.
SQL Server Integration Services proporciona herramientas que puede utilizar para
automatizar tareas comunes de minería de datos, como procesar un modelo de minería
de datos y crear consultas de predicción. Por ejemplo, si dispone de un modelo de
minería de datos generado a partir de un conjunto de datos de posibles clientes, puede
crear un paquete de Integration Services que actualice automáticamente el modelo
cada vez que el conjunto de datos se actualice con nuevos clientes. A continuación
podría utilizar el paquete para crear una predicción, separando los clientes potenciales
en dos tablas. Una tabla contendría los clientes probables y la otra los clientes que
posiblemente no adquirirán ningún producto.