AA8 - EVIDENCIA 4: BASE DE DATOS DE CONOCIMIENTO
Ing. YULY PATRICIA PATRICIA COAVAS COAVAS MARTINEZ MARTINEZ Presentado a: Ing. Mas. GREGORIO ARTURO BAREÑO MARIN
SERVICIO NACIONAL DE APRENDIZAJE SENA ESPECIALIZACIÓN EN GESTION Y SEGURIDAD EN BASES DE DATOS MODALIDAD VIRTUAL MOMIL-CORDOBA 2018
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 te nga 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 e l 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 e stado 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
