Diseño de una Bodega de Datos y Construcción de un Cubo


INTRODUCCIÓN

La presente actividad tiene el propósito diseñar una Bodega de Datos y construcción de un Cubo para la información objeto de los requerimientos propuestos en el caso de estudio “INTELIGENCIA DE NEGOCIOS APLICADA A LAS SECRETARÍAS DE LA ALCALDÍA SAN ANTONIO DEL SENA”. Para lo anterior se implementara un cubo que resuelva por lo menos dos de las situaciones presentadas, mediante la identificación de  las necesidades del modelo de negocio de acuerdo con los requerimientos planteados en el caso de estudio. También se realizara la descripción cuantitativa y cualitativa de los datos de los sistemas de fuentes planteados en el caso de estudio y se establecerá las dimensiones, métricas y tablas de hechos necesarios para la construcción del cubo, seleccionando el modelo de datos adecuado para la construcción del cubo de datos requeridos y construir el cubo de datos de acuerdo con los requerimientos establecidos.
Aún con la inclusión de nuevas tecnologías en el área de sistemas de la alcaldía de San Antonio del SENA, se presentan problemas relacionados con la gestión de la información y convergencia de datos (labor realizada por cada una de las secretarías) que dificultan los procesos de análisis y toma de decisiones derivados de éstos.
La base de datos son sistemas que guardan la información de una o más empresas para que estas puedan ser utilizadas cuando el usuario así lo deseen de gran relevancia porque automatizan previenen de errores y son eficaces en el tiempo y pueden ser adquiridas cuando el administrador del sistema lo desee.
Los SMBD (sistemas manejadores de base de datos) se han incrementado en los últimos años de forma drástica, pues claro está que cada vez más empresas requieren de software para registrar sus datos.
Los SMBD presentan además una interfaz razonable y comprensible para cualquier usuario, debemos mencionar que hay distintos gestores de base de datos, entre ellos se encuentran los de código libre, es decir, pueden ser usados de forma gratuita, los que requieren una licencia comercial, así como los que se pueden usar en forma de software de instalación, u otros que su utilizan desde un navegador predeterminado.

1.            OBJETIVOS DE LA ACTIVIDAD

  

1.1.       OBJETIVOS GENERALES.

  •  Organizar, gestionar  la información y relación puntual de los datos que dificultan los procesos de análisis y toma de decisiones derivados de éstos.
  • Ofrecer una escala de confianza admisible que permita la implementación de dicha solución con el fin de lograr Información precisa y confiable que permita trabajar los nuevos proyectos.
  • Representar de forma puntual y concisa la relación entre los acontecimientos registrados por las diferentes secretarías.

1.2.       OBJETIVOS ESPECIFICOS.

Secretaría de Salud
  • Supervisar y controlar  los recursos del sector salud para un buen recaudo y aplicación.
  • Registrar los prestadores de servicios de salud para  la gestión de la prestación de los mismos.
  • Implementar y actualizar la operación del Sistema Integral de Información en Salud para reportar la información a las instancias correspondientes.

Secretaría de Recreación
  • Elaborar estudios para identificar los problemas y necesidades del Municipio en el campo deportivo, recreativo y cultural con el fin de formular planes y proyectos que respondan a esas demandas.
  • Vigilar y supervisar la correcta administración y funcionamiento de los escenarios deportivos, recreativos y culturales.

Secretaría de Hacienda
  •         Gestionar y recaudar todos los dineros que por diversos conceptos debe percibir el municipio.
  •           Registrar, recibir y procesar toda la información económica en la administración municipal.
  •           Custodiar, guardar y controlar los títulos, valores y garantías constituidas a favor del municipio.
  •      Expedir los certificados de Paz y Salvo que por concepto de pago de impuestos le sean solicitados y que se encuentren al día.

Secretaria de Gobierno
  •    Estudiar, revisar y preparar los proyectos de acuerdos, resoluciones, decretos y contratos relacionados con asuntos de competencia de la Alcaldía.
  •          Velar por el cumplimiento de las normas legales que regulan el funcionamiento de la Alcaldía.
  •          Vigilar el oportuno cumplimiento de las decisiones del mismo.

Secretaría de Ambiente
  •       Gestionar las políticas para la conservación del medio ambiente y protección de los recursos naturales.
  •         Ejercer el control y vigilancia del cumplimiento de estas normas, adelantando investigaciones e imponiendo las sanciones que correspondan.

2.            CONTENIDO DEL TRABAJO

AA4-Ev6-Blog de Grupos de trabajo para el diseño de una bodega de datos y construcción de un cubo.
El diseño y construcción de Bodegas de Datos puede ser abordado desde diferentes enfoques. Una alternativa es construir la Bodega de Datos a partir de la agrupación de los cubos de datos que se generan por cada dependencia de la empresa y utilizar algún modelo o metodología para estructurarlos de manera ordenada. Un segundo enfoque es utilizar una metodología para realizar Minería de Datos y contemplar la construcción de la Bodega de Datos como un proceso que permite la extracción de conocimiento de los datos.

2.1.       TIPO DE ARQUITECTURA.

Con base a las exigencias requeridas por la Alcaldía San Antonio del SENA se manejará la arquitectura en dos capaz ya que la base de datos estará relacionada en base a la información que da solución al problema de la alcaldía.

2.2.       MODELADO LÓGICO DE LA BODEGA DE DATOS.

El modelo lógico que da solución a los requerimientos conforme a la problemática que tiene la Alcaldía es un esquema en copo de nieve ya que las tablas no estarán relacionadas con una única tabla sino que estará relacionada con demás para obtener una mayor información y coherencia en los datos. La finalidad es normalizar las tablas y así reducir el espacio de almacenamiento al eliminar la redundancia de datos.

2.3.       CREACIÓN DE UNA BASE DE DATOS A PARTIR DE UN ASISTENTE DE CONFIGURACIÓN.

Figura 1. Creación y configuración del LISTENER.




Figura 2. Creación y configuración de la Base de Datos.




Figura 3. Dirección URL de la Database Control.




Figura 4. Inicio de Enterprise Maanager 11g.

2.4.       IMPLEMENTACIÓN DEL CUBO DE DATOS.

2.4.1.   Comprensión del modelo de negocio.

La Alcaldía es una institución del estado Colombiano, y según el artículo 314 de la constitución de 1991 establece que un alcalde es el jefe de la administración local y el representante legal de un municipio que realiza las funciones de administración  local en una población de este país.
La Alcaldía San Antonio del SENA está presidida por el Alcalde elegido por votación popular, quien enfrenta una situación de caos administrativo a causa de los malos manejos de la información y la inadecuada utilización de tecnología para el apoyo a los procesos.
El Alcalde de “San Antonio del SENA”, convencido de poder mejorar la situación, presentó un proyecto de inclusión de tecnología que le fue aprobado por el concejo y propende en realizar todas las mejoras en las condiciones actuales de manejo de información de las diferentes dependencias y secretarias de su actual administración.
Una mejora sensible,  se da a través de una reingeniería de procesos  enfocados en la utilización de la información generada por  las dependencias de la alcaldía,  pensando en optimizar los tiempos de respuesta y flujo de información para la toma de decisiones.

2.4.2.   Levantamiento de requerimientos.

La Alcaldía del Sena desea mejorar los procesos de la información que se manejan en cada una de las secretarias para la toma de decisiones, para lograr esto se comenzó por realizar un análisis de los datos suministrado por cada una de las dependencias, arrojando los siguientes requerimientos:
  • Analizar mes a mes la relación directa entre las personas que han participado en los eventos deportivos y las atenciones que especialistas realizaron a esas mismas personas a través de consultas en las EPS’s.
  • Determinar si hay relación entre quienes asisten a un evento de la secretaría de recreación y deportes y quienes son atendidos en unidades de urgencias. Se debe tener en cuenta: el mes, el rango de edad y el tipo de evento realizado.
  • Verificar si existe una correlación entre las personas atendidas por tipo de servicio psiquiatría y personas que se hayan visto involucradas en una contravención.
  • Identificar si hay alguna relación entre los datos registrados mes a mes por la Secretaría de Ambiente, con los datos de consultas médicas generadas en cada uno de los meses.
  • Desde la consulta a los datos de inspecciones de la secretaría de Hacienda y los datos de la secretaría de Gobierno, establecer si existen registros de personas morosas que hayan sido detenidas por hechos que alteran el orden público.
  • Identificar el número de propietarios de predios que han sido demandados por temas relacionados con la propiedad horizontal.
  • Precisar las personas que presentaron mora en el pago de impuestos y posterior a dicha mora fueron atendidos por unidad de urgencias, por cuidados intensivos, especialista o psiquiatría.
  • Determinar si la variación del número de eventos realizados por la secretaría de recreación y deporte está correlacionado con la variación del número de contravenciones por: alicoramiento en vía pública, riña callejera, desorden en la vía pública o pelea familiar. (teniendo en cuenta el tipo de evento).

MODELADO LOGICO DE LA BODEGA DE DATOS


TABLA
DESCRIPCION
EVENTOS_DEPTVOS
EVENTOS DEPORTIVOS
CAxEERED
CONSOLIDADO ATENCION x ESPECIALISTA EPS RELACIONADO CON EVENTOS DEPORTIVOS
CAxEE
CONSOLIDADO ATENCION x ESPECIALISTA EPS
CAxUI
CONSOLIDADO ATENCION x URGENCIAS IPS
CAUIRED
CONSOLIDADO ATENCION x URGENCIAS IPS RELCIONADOS CON EVENTOS DEPORTIVOS
RDxAOP
RELACION DE DETENIDOS x ATERACIONES AL ORDEN PUBLICO
RMSH
RELACION DE MOROS DE LA SECRETARIA DE HACIENDA
RMAxUI
RELACION DE MOROS ATENDIDOS x URGENCIAS IPS
RMDxAOP
RELACION DE MOROSOS DETENIDOS x ATERACIONES AL ORDEN PUBLICO




SCRIPT PARA LA CREACIÓN DE LAS TABLAS EN EL CUBO
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
USE `mydb` ;
-- -----------------------------------------------------
-- Table `mydb`.`usuarios`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`usuarios` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `tipo_doc` VARCHAR(5) NULL,
  `num_documento` INT NULL,
  `nombres` VARCHAR(100) NULL,
  `apellidos` VARCHAR(100) NULL,
  `celular` INT NULL,
  `correo` VARCHAR(100) NULL,
  `direccion` VARCHAR(100) NULL,
  `id_afiliacion` INT NULL,
  `fecha_nacimiento` DATE NULL,
  `edad` INT NULL,
  `cat_edad` VARCHAR(5) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`ips`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`ips` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(45) NULL,
  `regimen` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`CAxUI`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`CAxUI` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `tipo_atencion` VARCHAR(45) NULL COMMENT 'Por urgencias o por atencion por EPS',
  `fecha` DATE NULL,
  `hora` TIME NULL,
  `diagnostico` TEXT NULL,
  `codigo_diag` VARCHAR(45) NULL,
  `observaciones` VARCHAR(45) NULL,
  `usuarios_id` INT NOT NULL,
  `ips_id` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_CAxUI_usuarios1_idx` (`usuarios_id` ASC),
  INDEX `fk_CAxUI_ips1_idx` (`ips_id` ASC),
  CONSTRAINT `fk_CAxUI_usuarios1`
    FOREIGN KEY (`usuarios_id`)
    REFERENCES `mydb`.`usuarios` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_CAxUI_ips1`
    FOREIGN KEY (`ips_id`)
    REFERENCES `mydb`.`ips` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`EVENTOS_DEPTVOS`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`EVENTOS_DEPTVOS` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `fecha_inicio` DATE NULL,
  `hora_inicio` TIME NULL,
  `fecha_fin` DATE NULL,
  `hora_fin` TIME NULL,
  `responsable` VARCHAR(45) NULL,
  `organizador` VARCHAR(45) NULL,
  `poblacion_dirigida` VARCHAR(45) NULL,
  `lugar` VARCHAR(45) NULL,
  `num_asistentes` INT NULL,
  `medidas_seguridad` TEXT NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`CAUIRED`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`CAUIRED` (
  `id_evento` INT NOT NULL,
  `id_atencion` INT NOT NULL,
  PRIMARY KEY (`id_evento`, `id_atencion`),
  INDEX `fk_EVENTOS_DEPTVOS_has_CAxUI_CAxUI1_idx` (`id_atencion` ASC),
  INDEX `fk_EVENTOS_DEPTVOS_has_CAxUI_EVENTOS_DEPTVOS_idx` (`id_evento` ASC),
  CONSTRAINT `fk_EVENTOS_DEPTVOS_has_CAxUI_EVENTOS_DEPTVOS`
    FOREIGN KEY (`id_evento`)
    REFERENCES `mydb`.`EVENTOS_DEPTVOS` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_EVENTOS_DEPTVOS_has_CAxUI_CAxUI1`
    FOREIGN KEY (`id_atencion`)
    REFERENCES `mydb`.`CAxUI` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`eps`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`eps` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(45) NULL,
  `regimen` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`CAxEE`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`CAxEE` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `tipo_atencion` VARCHAR(45) NULL COMMENT 'Por urgencias o por atencion por EPS',
  `fecha` DATE NULL,
  `hora` TIME NULL,
  `diagnostico` TEXT NULL,
  `codigo_diag` VARCHAR(45) NULL,
  `observaciones` VARCHAR(45) NULL,
  `usuarios_id` INT NOT NULL,
  `eps_id` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_CAxUI_usuarios1_idx` (`usuarios_id` ASC),
  INDEX `fk_CAxEE_eps1_idx` (`eps_id` ASC),
  CONSTRAINT `fk_CAxUI_usuarios10`
    FOREIGN KEY (`usuarios_id`)
    REFERENCES `mydb`.`usuarios` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_CAxEE_eps1`
    FOREIGN KEY (`eps_id`)
    REFERENCES `mydb`.`eps` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`CAxEERED`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`CAxEERED` (
  `id_evento` INT NOT NULL,
  `id_atencion_x_eps` INT NOT NULL,
  PRIMARY KEY (`id_evento`, `id_atencion_x_eps`),
  INDEX `fk_EVENTOS_DEPTVOS_has_CAxEE_CAxEE1_idx` (`id_atencion_x_eps` ASC),
  INDEX `fk_EVENTOS_DEPTVOS_has_CAxEE_EVENTOS_DEPTVOS1_idx` (`id_evento` ASC),
  CONSTRAINT `fk_EVENTOS_DEPTVOS_has_CAxEE_EVENTOS_DEPTVOS1`
    FOREIGN KEY (`id_evento`)
    REFERENCES `mydb`.`EVENTOS_DEPTVOS` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_EVENTOS_DEPTVOS_has_CAxEE_CAxEE1`
    FOREIGN KEY (`id_atencion_x_eps`)
    REFERENCES `mydb`.`CAxEE` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`propietarios`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`propietarios` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `identificacion_propietario` INT NULL,
  `nombres` VARCHAR(45) NULL,
  `apellidos` VARCHAR(45) NULL,
  `direccion` VARCHAR(45) NULL,
  `identificacion_predio` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`RMSH`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`RMSH` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `contribuyente` VARCHAR(100) NULL,
  `identificacion` VARCHAR(45) NULL,
  `celular` INT NULL,
  `direccion` VARCHAR(100) NULL,
  `correo` VARCHAR(100) NULL,
  `id_propietario` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_RMSH_propietarios1_idx` (`id_propietario` ASC),
  CONSTRAINT `fk_RMSH_propietarios1`
    FOREIGN KEY (`id_propietario`)
    REFERENCES `mydb`.`propietarios` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`RDxAOP`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`RDxAOP` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `identificacion` VARCHAR(45) NULL,
  `nombre_detenido` VARCHAR(100) NULL,
  `celular` INT NULL,
  `direccion` VARCHAR(100) NULL,
  `correo` VARCHAR(100) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`RMSH_has_RDxAOP`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`RMSH_has_RDxAOP` (
  `id_moroso` INT NOT NULL,
  `id_detenido` INT NOT NULL,
  PRIMARY KEY (`id_moroso`, `id_detenido`),
  INDEX `fk_RMSH_has_RDxAOP_RDxAOP1_idx` (`id_detenido` ASC),
  INDEX `fk_RMSH_has_RDxAOP_RMSH1_idx` (`id_moroso` ASC),
  CONSTRAINT `fk_RMSH_has_RDxAOP_RMSH1`
    FOREIGN KEY (`id_moroso`)
    REFERENCES `mydb`.`RMSH` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_RMSH_has_RDxAOP_RDxAOP1`
    FOREIGN KEY (`id_detenido`)
    REFERENCES `mydb`.`RDxAOP` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`DEMANDAS`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`DEMANDAS` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `identificacion` INT NULL,
  `nombre_demandado` VARCHAR(45) NULL,
  `apellidos_demandado` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`listado_propietarios_demandados`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`listado_propietarios_demandados` (
  `id_propietarios` INT NOT NULL,
  `id_demandado` INT NOT NULL,
  PRIMARY KEY (`id_propietarios`, `id_demandado`),
  INDEX `fk_propietarios_has_DEMANDAS_DEMANDAS1_idx` (`id_demandado` ASC),
  INDEX `fk_propietarios_has_DEMANDAS_propietarios1_idx` (`id_propietarios` ASC),
  CONSTRAINT `fk_propietarios_has_DEMANDAS_propietarios1`
    FOREIGN KEY (`id_propietarios`)
    REFERENCES `mydb`.`propietarios` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_propietarios_has_DEMANDAS_DEMANDAS1`
    FOREIGN KEY (`id_demandado`)
    REFERENCES `mydb`.`DEMANDAS` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`RMAxUI`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`RMAxUI` (
  `id_atencion` INT NOT NULL,
  `id_persona_morosa` INT NOT NULL,
  PRIMARY KEY (`id_atencion`, `id_persona_morosa`),
  INDEX `fk_RMSH_has_CAxUI_CAxUI1_idx` (`id_persona_morosa` ASC),
  INDEX `fk_RMSH_has_CAxUI_RMSH1_idx` (`id_atencion` ASC),
  CONSTRAINT `fk_RMSH_has_CAxUI_RMSH1`
    FOREIGN KEY (`id_atencion`)
    REFERENCES `mydb`.`RMSH` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_RMSH_has_CAxUI_CAxUI1`
    FOREIGN KEY (`id_persona_morosa`)
    REFERENCES `mydb`.`CAxUI` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;




3.            CONCLUSIONES

·      El diseño y construcción de cubos de datos permite a las organizaciones escalar progresivamente hacia una arquitectura de almacenamiento con Bodegas de Datos
·      Se puede utilizar la minería de datos con el fin de extraer conocimiento que permita satisfacer las expectativas de los clientes y alcanzar los objetivos estratégicos de la organización.
·      La aplicación de técnicas de minería de datos para identificar y extraer conocimiento de las bases de datos, permite mejorar la estrategia de negocio mediante el diseño de tácticas que generen ventajas competitivas en el mercado.

4.            REFERENCIAS BIBLIOGRÁFICAS

Hernández J., Ramírez J.y Ferri R. (2008). Introducción a la minería de datos, Madrid, España: Editorial: Pearson Prentice Hall.
Kroenke, D, (2003). Procesamiento de Bases de Datos, Editorial: Prentice Hall.
Pérez, César y González D, (2007.) Mineria de datos Técnicas y herramientas, Madrid, España: Editorial:Thomson.
Heurtel, O. (2009). Oracle 11g: administración. Ediciones ENI.
Chaparro, A. M. (2012). Oracle 11g PL/SQL: curso práctico de formación. RC Libros.
Aranda, Y. R., & Sotolongo, A. R. (2013). Integración de los algoritmos de minería de datos 1R, PRISM e ID3 a PostgreSQL. JISTEM-Journal of Information Systems and Technology Management, 10(2), 389-406.
Rios, S. (2015). JSF 2+ Hibernate 4+ Spring 4: PrimeFaces 5 with JAX-WS y EJB’S. Sergio Rios.
Rodríguez, M. (2010). Los documentos vitales en los archivos: su identificación y conserva-ción. Comma, 2010(2), 199-207.

 

Comentarios

Entradas populares de este blog

PREPARACIÓN DE DATOS

LEVANTAMIENTO DE REQUERIMIENTOS

CONSTRUCCIÓN DEL VISUALIZADOR