BLOG DE GRUPOS DE TRABAJO PARA EL DISEÑO DE UNA BODEGA DE

DATOS Y CONSTRUCCIÓN DE UN CUBO.

DIEGO FERNNEY QUINTERO HERNANDEZ

SERVICIO NACIONAL DE APRENDIZAJE SENA

ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AÑO 2019
 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;