COPIA DE SEGURIDAD DE LA SECRETARIA DE GOBIERNO Y HACIENDA DE LA

ALCALDIA DE SAN ANTONIO DEL SENA

PRESENTADO POR:

CESAR AUGUSTO TAMAYO HERNANDEZ

PRESENTADO A:
DEIVID ENRIQUE TRIVIÑO LOZADA
WILLIAM FRANCISCO CASTILLO PENAGOS
JUAN JOSE BOTELLO CASTELLANOS

SERVICIO NACIONAL DE APRENDIZAJE SENA

ESPECIALIZACIÓN EN GESTION Y SEGURIDAD EN BASES DE DATOS
MODALIDAD VIRTUAL
2020
 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.
 Está 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 existente en cada una de las
dependencias, las cuales se usan para especificar más 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