APRENDICES

ALEIXO EDER PINEDA RAMIREZ

CLARA JULIETA MARTINEZ USCATEGUI
OSCAR PEREZ SABOGAL
LIZETH VIVIAN JIMENEZ NARANJO

SERVICIO NACIONAL DE APRENDIZAJE

ESPECIALIZACIÓN EN GESTIÓN Y GERENCIA DE SEGURIDAD DE BASES DE DATOS
MEDELLÍN
SEPTIEMBRE/2019
 DISEÑO LOGICO DE LA BASE DE DATOS CONOCIMIENTO (KD)

CARACTERÍSTICAS DEL MODELO

Teniendo en cuenta el modelo lógico propuesto se pueden identificar las siguientes

características

• La Base de datos de conocimiento se encarga de registrar los incidentes y las

posibles soluciones correspondientes a hardware y software al interior de las
dependencias de la alcaldía “San Antonio del SENA”

• Este modelo se desarrolló de acuerdo al formato de reportes de incidentes

• Esta compuesta por cinco tablas o entidades definidas a saber

Usuarios: en donde se registran todas las personas que interactúan con la base de
datos y los procesos tecnológicos de la alcaldía

Equipos: en donde se almacenan todo el inventario tecnológico exixtente en cada

una de las dependencias, las cuales se usan para especificar mas específicamente el
incidente presentado
Dependencias: registra las diferentes dependencias, áreas o departamentos de la
alcaldía con el fin de localizar correctamente el incidente presentado

Incidencias: en ella se almacena la información detallada sobre las situaciones

presentadas dependiendo del área donde se suscitó el inconveniente. Dicha
información es de vital importancia para que los encargados del área de sistemas
puedan brindar soluciones acertadas al incidente

Soluciones: aquí se registran cada una de las alternativas de solución que se

proponen para determinado incidente. Es de vial importancia para la solución de
incidentes futuros.

SCRIPT DE LA BASE DE DATOS

TABLA DEPENDENCIAS

create table DEPENDENCIAS

(
IDDEPENDENCIA INTEGER not null,
NOMBREDEP VARCHAR(50),
constraint PK_DEPENDENCIAS primary key (IDDEPENDENDIA)
)

TABLA EQUIPOS

create table EQUIPOS

(
IDEQUIPO INTEGER not null,
NOMBREEQUIPO VARCHAR(50),
DESCRIPCIONEQUIPO VARCHAR(255),
constraint PK_EQUIPOS primary key (IDEQUIPO)
)
TABLA INCIDENTES

create table INCIDENTES(

IDINCIDENTE INTEGER not null,
IDDEPENDENCIA INTEGER,
DOCUMENTOUSER INTEGER,
IDEQUIPO INTEGER,
FECHAINCIDENTE DATE,
FECHAREGISTRO DATE,
ERRORPANTALLA VARCHAR(2),
MENSAJEERROR VARCHAR(100),
USUARIOSAFECTADOS VARCHAR(2),
MODULOERROR VARCHAR(255),
DEMASMODULOSFUN VARCHAR(2),
FALLOSISTEMA VARCHAR(2),
OBSERVACIONES VARCHAR(255),
ESTADO VARCHAR(20),
constraint PK_INCIDENTES primary key (IDINCIDENTE)
)
create index R1_FK on INCIDENTES
(
DOCUMENTOUSER ASC
);
create index R2_FK on INCIDENTES
(
IDDEPENDENCIA ASC
);
create index R3_FK on INCIDENTES
(
IDEQUIPO ASC
);

TABLA SOLUCIONES

create table SOLUCIONES

(
IDSOLUCION INTEGER not null,
IDINCIDENTE INTEGER,
DESCRIPCIONSOL VARCHAR(255),
constraint PK_SOLUCIONES primary key (IDSOLUCION)
)
create index R4_FK on SOLUCIONES
(
IDINCIDENTE ASC
);
TABLA USUARIOS

create table USUARIOS

(
DOCUMENTOUSER INTEGER not null,
NOMBREUSER VARCHAR(50),
APELLIDOUSER VARCHAR(50),
CARGOUSER VARCHAR(50),
constraint PK_USUARIOS primary key (DOCUMENTOUSER)
)

Llaves foráneas

Alter table INCIDENTES add constraint FK_INCIDENT_R1_USUARIOS foreign

key (DOCUMENTOUSER) references USUARIOS (DOCUMENTOUSER);
Alter table INCIDENTES add constraint FK_INCIDENT_R2_DEPENDEN foreign
key (IDDEPENDENCIA) references DEPENDENCIAS (IDDEPENDENCIA);
Alter table INCIDENTES add constraint FK_INCIDENT_R3_EQUIPOS foreign
key (IDEQUIPO) references EQUIPOS (IDEQUIPO);

Alter table SOLUCIONES add constraint FK_INCIDENT_R4_INCIDENT foreign

key (IDINCIDENTE) references INCIDENTES (IDINCIDENTE);

IMPLEMENTACION EN POSTGRESQL
INSERCION DE LOS DATOS EN LAS TABLA DEPENDENCIAS
INSERCION EN LA TABLA EQUIPOS
INSERCION EN LA TABLA USUARIOS
 CREACION DE INCIDENTES

Una vez ingresados los datos anteriores podemos crear los incidentes, los cuales tienen
un código único cada uno.

INSERT INTO `incidentes` (`IDINCIDENTE`, `IDDEPENDENDIA`, `DOCUMENTOUSER`, `IDEQUIPO`,

`FECHAINCIDENTE`, `FECHAREGISTRO`, `ERRORPANTALLA`, `MENSAJEERROR`,
`USUARIOSAFECTADOS`, `MODULOERROR`, `DEMASMODULOSFUN`, `FALLOSISTEMA`,
`OBSERVACIONES`, `ESTADO`) VALUES ('1', '1', '6589025', '3', '2018-05-01', '2018-05-02', 'no', '-',
'no', 'Informes de Afiliacion', 'si', 'no', 'Alcalde solicita Informe de afiliados a EPS, estaba
intentando extraer la informacion pero el rendimiento de la consulta es demasiado bajo y veo que
pasan 10 minutos y no se visualiza el resultado', 'PENDIENTE');

INSERT INTO `incidentes` (`IDINCIDENTE`, `IDDEPENDENDIA`, `DOCUMENTOUSER`, `IDEQUIPO`,

`FECHAINCIDENTE`, `FECHAREGISTRO`, `ERRORPANTALLA`, `MENSAJEERROR`,
`USUARIOSAFECTADOS`, `MODULOERROR`, `DEMASMODULOSFUN`, `FALLOSISTEMA`,
`OBSERVACIONES`, `ESTADO`) VALUES ('2', '1', '6589025', '4', '2018-05-02', '2018-05-04', 'SI',
'ERROR 1420- es posible que el usuario no tenga privilegios suficientes para esta operacion', 'SI',
'Afiliacion a EPS', 'NO', 'NO', 'no se pudo realizar la afiliación a un nuevo usuario de la EPS
Mutualser', 'PENDIENTE');
CREACIÓN DE SOLUCIONES
Después de haber creado lo incidentes, se puede proceder con el ingreso de su respectiva
solución, ya que si no existen anteriormente en el sistema no se podrán ingresar
La sentencia SQL es la siguiente
INSERT INTO soluciones (IDSOLUCION, IDINCIDENTE, DESCRIPCIONSOL) VALUES ('1', '3', 'se
verifico el error encontrando que el espacio asignado para el almacenamiento se encuentra lleno.
Es necesario asignar más espacio en disco de inmediato');

Una vez creada la solución debemos cambiar el estado al incidente a través de la siguiente
consulta SQL
UPDATE INCIDENTES SET ESTADO='SOLUCIONADO' WHERE IDINCIDENTE=3;

UPDATE INCIDENTES SET ESTADO='SOLUCIONADO' WHERE IDINCIDENTE=3;

Como podemos ver ha cambiado el estado del incidente 3 de PENDIENTE a SOLUCIONADO