INSTITUTO TECNOLÓGICO DE MORELIA

José María Morelos y Pavón

Administración de Base de Datos

Proyecto Final

Gerardo Mendoza Chávez

Isaí Gutiérrez Rubio

Abraham Quintana Villicaña

 Análisis del SGBD

PostgreSQL es una de las opciones más interesantes en bases de datos relacionales open-
source. Michael Stonebraker inició el proyecto bajo el nombre Post Ingres a mediados de los
80’s con la idea de solucionar problemas existentes en las bases de datos en esa época.
MySQL fue por mucho tiempo el motor más popular; pero hoy es propiedad de Oracle y esto
limita su evolución. Es gratuito y libre, además de que hoy nos ofrece una gran cantidad de
opciones avanzadas. De hecho, es considerado el motor de base de datos más avanzado en la
actualidad.

Razones por las cuales se eligió este gestor:

• OPEN SOURCE: Una de las principales razones para usar PostgreSQL es que está
desarrollado bajo código abierto (Open Source), lo podemos encontrar disponible en
su página oficial y descargarlo sin ningún tipo de costo. Gracias a su libertad en el
desarrollo permite tener a profesionales colaboradores por todo el mundo que
constantemente están incluyendo nuevos desarrollos.
• MULTIPLATAFORMA: Se encuentra disponible prácticamente en todas las
versiones de los sistemas operativos Unix y también para Windows, dándonos la
oportunidad de tenerla instalada localmente, realizar una conexión remota a través de
su administrador PgAdmin o también desde la aplicación que se esté desarrollando.
• FACILIDAD DE MANEJO: PgAdmin es el principal administrador de base de datos
de Postgre, es muy sencillo de manejar, esta herramienta prácticamente hace todo con
unos simples clics, siendo óptima para las personas que no tienen mucha experiencia.
• SEGURIDAD DE LA INFORMACIÓN.
 El Proyecto
“Salvando Vidas” es un proyecto de monitoreo de accidentes automovilísticos. La
finalidad de este proyecto es poder facilitar la correcta atención paramédica a los
involucrados en un accidente automovilístico. Esto se logra mediante el registro de los
ciudadanos en una base de datos donde se almacenarán los datos básicos de su expediente
clínico, incluyendo enfermedades crónicas, antecedentes personales y familiares, alergias y
datos generales del paciente. Esta base de datos podrá ser accedida por los paramédicos.

Requerimientos Funcionales

RF1 Administrador/Médico El médico será el único encargado de dar de alta, dar de baja
(Eliminar), Buscar y Editar los datos de todos los pacientes
registrados por él.
RF2 Administrador/Médico Al iniciar se abrirá una pestaña en el navegador donde pedirá
dos campos a llenar, que será usuario y password, además de
un botón que diga aceptar el cual al presionarlo revisará que
estén correctos tanto el usuario, como la contraseña y dar
acceso al Administrador/Médico.
RF3 N/A El logo será un corazón atravesado por una onda del
electrocardiograma, el cual será de color negro con fondo azul
y estará ubicado en la parte superior derecha de la página.
RF4 N/A Se tendrá un menú que contará con las secciones: Dar de alta,
Dar de baja, Editar, Buscar paciente y Salir, el cual al dar clic
nos direccionará a lo indicado en cada sección.
RF5 N/A En la parte superior izquierda se mostrará el nombre del
médico el cual se encuentra en sesión.
RF6 N/A Sección Dar de alta: Se abrirá una nueva pestaña con las
opciones de nuevo registro con los siguientes campos:
Nombre(s), Apellido Materno, Apellido Paterno, RFC, Peso,
Talla, Alergias, Sexo, Edad, Ocupación, Motivo de la Consulta,
Antecedentes personales Patológicos y no Patológicos,
Antecedentes Familiares, Antecedentes Gineco-obstétricos y
Exploración física donde el RFC es el ID.
RF7 N/A Sección dar de baja: se contará con una barra de búsqueda en
la cual se debe escribir el apellido paterno del paciente.
RF8 N/A Al dar clic en el botón de buscar se redireccionará a una
pestaña donde mostraremos en una
tabla los campos: nombre, apellido paterno, apellido
materno, edad, y sexo con un botón al final el cual al hacer
clic eliminara según sea el botón seleccionado.

RF9 N/A Sección Editar: Se contará con una barra de búsqueda en la

cual se debe escribir el apellido paterno del paciente
RF10 N/A Al dar clic en el botón de buscar se redireccionará a una
pestaña donde mostraremos en una tabla los campos:
 nombre, apellido paterno, apellido materno, edad, y sexo con
un botón al final de los campos por cada registro mostrado
que re direccionará a una pestaña donde se podrán modificar
los datos del paciente seleccionado.
RF11 N/A Sección Buscar: se contará con una barra de búsqueda en la
cual se debe escribir el apellido paterno del paciente.

RF12 N/A Al dar click en el botón buscar e re direccionara a una pestaña

donde mostraremos en una tabla con los campos: Nombre,
Apellido paterno, Apellido Materno, Edad y Sexo con un botón
al final de los campos por cada registro mostrado que re
direccionara a una pestaña donde se mostraran todos los
datos del paciente seleccionado.
RF13 N/A Sección Historial: Contará con una tabla la cual muestre el
registro de los últimos 10 pacientes registrados atendidos por
el paramédico con los campos: Fecha, Nombre del paciente
diagnóstico y estatus final.
RF14 N/A Se encriptarán las contraseñas de los paramédicos y médicos
de los pacientes se encriptará los campos alergias,
antecedentes personales no patológicos, antecedentes
personales patológicos, antecedentes familiares,
antecedentes Gineco-obstétricos y exploración física.
RF15 N/A Habrá un campo donde se especificará la última fecha en la
que el paciente requirió atención médica.
RF16 ADMINISTRADOR El administrador en este caso el médico contará con una
contraseña y un nombre de usuario
RF17 N/A Habrá una cuenta de un superadministrador, el cual podrá ser
el único que pueda dar de alta y de baja a médicos.
RF18 SUPERADMINISTRADOR El super administrador tendrá las opciones exclusivas en el
menú de dar de alta y dar de baja a médicos.
 Requerimientos no funcionales

RNF1 Se recomienda que la página se abra en el navegador Chrome

RNF2 La página web será constituida con HTML

RNF3 El aspecto de la página será en CSS

RNF4 Se le proporcionará un Usuario y contraseña al administrador

RNF5 Las búsquedas de la información se efectuarán mediante un código QR o escribiendo el

nombre completo de la persona a atender

RNF6 El sistema de gestor de base de datos a utilizar será PostgreSQL 10

RNF7 La página web se complementará con lenguajes como PHP

RNF8 La página web se complementará con lenguajes como JavaScript

RNF9 Se utilizará el Framework Bootstrap 4

RNF10 El identificador para cada paciente será asignado siguiendo un patrón similar al del RFC

RNF11 Se realizarán las validaciones correspondientes para el correcto registro de información

RNF12 La contraseña de acceso para el administrador no será menor a 8 Caracteres

RNF13 La restricción entre Administradores se validará mediante sesiones

RNF14 La restricción del súper administrador se validará mediante un inicio de sesión único

RNF15 Se proporcionará un usuario y Contraseña únicos para el superadministrador

RNF16 El súper Administrador será el único que podrá dar de alta otros médicos

RNF17 El nombre de usuario para el administrador no será mayor a 12 caracteres

RNF18 Se realizarán validaciones correspondientes para el inicio de sesión

RNF19 Las búsquedas serán realizadas mediante el apellido del paciente.

RNF20 Se tendrán tablas en la base de datos para facilitar la auditoria de la misma

RNF21 Se habilitarán las herramientas necesarias para realizar el monitoreo de la base de

datos

RNF22 La base de datos contará con mecanismos de replicación necesarios para garantizar la
disponibilidad de los datos
 Diagramas

Diagrama Entidad-Relación 1

Diagrama Relacional 1
 Diccionario de Datos

1.- Tabla Rol

Guardar información de los roles usados en la base de datos y los usuarios a los que están
ligados asi como las contraseñas de los usuarios del rol

Llave Campo Tipo Longitud Descripción

P Idrol Int Predeterminada Id de rol
Rol Varchar 20 Nombre del rol
Bduser Bytea Predeterminada Usuario de la
base de datos
Bdpass Bytea Predeterminada Password del
usuario

2.- Empleado

Guardar información de los empleados con el fin de tener un control del personal

Llave Campo Tipo Longitud Descripción

P Cedprof Int Predeterminada Cedula del
empleado
Pass Bytea Predeterminada Contraseña de
empleado
Nombre Varchar 20 Nombre del
empleado
Apaterno Varchar 20 Apellido
paterno del
empleado
Amaterno Varchar 20 Apellido
materno del
empleado
F rol Int Predeterminada Rol del
empleado
Activo Small int Predeterminada Estado del
empleado
Relación: Campos llave:
Rol-Empleado cedprof
1:1 rol
 3.- Paciente

Guarda información de los pacientes y sus antecedentes médicos asi como sus estudios
recientes

Llave Campo Tipo Tamaño Descripción

Nombre Varchar 20 Nombre del
paciente
Apaterno Varchar 20 Apellido
paterno del
paciente
Amaterno Varchar 20 Apellido
materno del
paciente
RFC Varchar 10 RFC del
paciente
Peso Float Predeterminada Peso del
paciente
Talla Float Predeterminada Talla del
paciente
Sexo Varchar 1 Sexo del
paciente
Edad Int Predeterminada Edad del
paciente
Ocupación Varchar 30 Ocupación del
paciente
AntPerNpat Bytea Predeterminada Detalle de
antecedentes
personales no
patológicos del
paciente
antPerPat Bytea Predeterminada Detalle de
antecedentes
personales
patológicos del
paciente
antFam Bytea Predeterminada Detalle de
antecedentes
familiares
patológicos del
paciente
antGinObs Bytea Predeterminada Detalle de
antecedentes
gineco obstétricos
del paciente
 expFis Bytea Predeterminada Detalle de la
exploración física
al paciente
alergias Bytea Predeterminada Alergias del
paciente
P Idpaciente
Activo Small int Predeterminada

4.- Percance

Guarda información cerca de los padecimientos del paciente asi como del diagnostico, el
motivo de la consulta y el paramédico que lo atiende

Llave Campo Tipo Tamaño Descripción

P Idpercance Identificador
del percance
Motconsulta Varchar 120 Motivo de
consulta
Diagnostico Varchar 256 Diagnóstico de
la consulta
F Paramedico Int Predeterminada Identificador
del paramédico
F Paciente Int Predeterminada Identificador
del paciente
Fecha Date Predeterminada Fecha de la
consulta
Statfin Varchar 256 Consulta final

5.- Empleado historial

Guardar información de los cambios que se realicen en la tabla de empleados en referencia

a las contraseñas del empleado

Llave Campo Tipo Longitud Descripción

Cedprof Int Predeterminada Cedula del
empleado
old_pass Bytea Predeterminada Password
anterior
new_pass Bytea Predeterminada Password
nueva
Fecha Timestamp Predeterminada Fecha del
cambio
Usuario Varchar Predeterminada Usuario que
hizo el cambio
 Accion Varchar Predeterminada Accion del
cambio (insert,
delete, update)

6.- Paciente historial

Guardar información de los cambios que se realicen en la tala de pacientes en referencia

al peso y la talla del paciente

Llave Campo Tipo Longitud Descripción

RFC Varchar 10 RFC del
paciente
old_peso Float Predeterminada Peso anterior
new_peso Float Predeterminada Peso nuevo
old_talla Float Predeterminada Talla anterior
new_talla Float Predeterminada Talla nueva
Fecha Timestamp Predeterminada Fecha del
cambio
Usuario Varchar Predeterminada Usuario que
hizo el cambio
Accion Varchar Predeterminada Accion del
cambio (insert,
delete, update)
 Triggers
En este Proyecto se contemplaron 6 diferentes triggers, 3 para la tabla pacientes y tres para
la tabla empleados. En la tabla “paciente” se llevará registro de los datos RFC, además de los
datos antiguo y nuevo de los campos “talla” y “peso”. En la tabla “empleados” se registrará
el ID del empleado, asi como los nuevo y antiguo de “password”. En ambos casos se
registrará el dia que se realizó la acción, el usuario que lo hizo y la acción realizada. A
continuación, se enlistan los comandos utilizados.

------EMPLEADO------

CREATE OR REPLACE FUNCTION nuevo_empleado() RETURNS TRIGGER

AS $insertar$
DECLARE BEGIN
INSERT INTO empleado_historial VALUES (NEW.cedProf,
NEW.pass, NEW.pass, current_timestamp, current_user,
'insert');
RETURN NULL;
END;
$insertar$ LANGUAGE plpgsql;

CREATE TRIGGER insertar_empleado AFTER INSERT

ON empleado FOR EACH ROW
EXECUTE PROCEDURE nuevo_empleado();

CREATE OR REPLACE FUNCTION quitar_empleado() RETURNS TRIGGER

AS $eliminar$
DECLARE BEGIN
INSERT INTO empleado_historial VALUES (OLD.cedProf,
OLD.pass, OLD.pass, current_timestamp, current_user,
'delete');
RETURN NULL;
END;
$eliminar$ LANGUAGE plpgsql;

CREATE TRIGGER eliminar_empleado AFTER DELETE

 ON empleado FOR EACH ROW
EXECUTE PROCEDURE quitar_empleado();

CREATE OR REPLACE FUNCTION modificar_empleado() RETURNS

TRIGGER AS $modi$
DECLARE BEGIN
INSERT INTO empleado_historial VALUES (OLD.cedProf,
OLD.pass, NEW.pass, current_timestamp, current_user,
'update');
RETURN NULL;
END;
$modi$ LANGUAGE plpgsql;

CREATE TRIGGER actualizar_empleado BEFORE UPDATE

ON empleado FOR EACH ROW
EXECUTE PROCEDURE modificar_empleado();

-------PACIENTE-------

CREATE OR REPLACE FUNCTION nuevo_paciente() RETURNS TRIGGER

AS $insertar$
DECLARE BEGIN
INSERT INTO paciente_historial VALUES (NEW.rfc, null,
NEW.peso, null, NEW.talla, current_timestamp, current_user,
'insert');
RETURN NULL;
END;
$insertar$ LANGUAGE plpgsql;

CREATE TRIGGER insertar_paciente AFTER INSERT

ON paciente FOR EACH ROW
EXECUTE PROCEDURE nuevo_paciente();

CREATE OR REPLACE FUNCTION adios_paciente() RETURNS TRIGGER

AS $adios$
DECLARE BEGIN
INSERT INTO paciente_historial VALUES (OLD.rfc, OLD.peso,
null, OLD.talla, null, current_timestamp, current_user,
'insert');
RETURN NULL;
END;
$adios$ LANGUAGE plpgsql;

CREATE TRIGGER eliminar_paciente AFTER DELETE

ON paciente FOR EACH ROW
EXECUTE PROCEDURE adios_paciente();
 CREATE OR REPLACE FUNCTION modi_paciente() RETURNS TRIGGER
AS $mod$
DECLARE BEGIN
INSERT INTO paciente_historial VALUES (OLD.rfc, OLD.peso,
NEW.peso, OLD.talla, NEW.peso, current_timestamp,
current_user, 'insert');
RETURN NULL;
END;
$mod$ LANGUAGE plpgsql;

CREATE TRIGGER actualizar_paciente BEFORE UPDATE

ON paciente FOR EACH ROW
EXECUTE PROCEDURE modi_paciente();

Indices
Como índice secundario con campo clave, se empleará el campo “RFC” de la tabla
paciente, debido a que éste es una llave secundaria y se emplea en las consultas.

CREATE UNIQUE INDEX IF NOT EXISTS index_rfc ON paciente

(rfc);

Otro índice de importancia es el del campo “estado” en “paciente” y “empleado” para

ordenar clustered index,

CREATE INDEX IF NOT EXISTS index_estado_empleado ON

empleado(estado);
CLUSTER empleado USING index_estado_empleado;
CREATE INDEX IF NOT EXISTS index_estado_paciente ON
paciente(estado);
CLUSTER paciente USING index_estado_paciente;

Estos índices son creados basados en el tipo de consultas empleadas dentro de la

aplicación.

Migración
Los comandos a ejecutar para la creación de los archivos .csv de la base de datos
“salvandovidas” en PostgreSQL 10 son los siguientes:

-Rol

COPY rol ("idrol", "rol", "bduser", "bdpass")

TO 'C:\salvando\rol.csv' DELIMITERS ',' WITH CSV HEADER;

-Empleado
 COPY empleado ("cedprof", "pass", "Nombre", "Apaterno",
"Amaterno", "rol", "Activo")
TO 'C:\salvando\empleado.csv' DELIMITERS ',' WITH CSV
HEADER;

-Paciente

COPY paciente ("nombre", "apaterno", "amaterno", "rfc",

"peso", "talla", "sexo", "edad", "ocupacion", "antpernpat",
"antperpat", "antfam", "antginobs", "expfis", "alergias",
"idpaciente", "activo")
TO 'C:\salvando\paciente.csv' DELIMITERS ',' WITH CSV
HEADER;

-Percance

COPY percance ("idpercance", "motconsulta", "diagnostico",

"paramedico", "paciente", "fecha", "statfin")
TO 'C:\salvando\percance.csv' DELIMITERS ',' WITH CSV
HEADER;

-Empleado historial

COPY empleado_historial("cedprof", "old_pass", "new_pass",

"fecha", "usuario", "accion")
TO 'C:\salvando\empleado_historial.csv' DELIMIRERS ',' WITH
CSV HEADER;

-Paciente historial

COPY paciente_historial ("rfc", "old_peso", "new_peso",

"old_talla", "new_talla", "fecha", "usuario", "accion")
TO 'C:\salvando\paciente_historial.csv' DELLIMITERS ',' WITH
CSV HEADER;

Consideraciones
• Las sintaxis de los triggers varían entre gestores. Investigar la sintaxis del gestor a
usar.
 • Investigar asignación de roles en el gestor a usar. Puede variar la manera de
asignación.
• Investigar la sintaxis de índices en el gestor receptor.
• Aplicar replicación y respaldo correspondientes.
• Aplicar herramientas de monitoreo correspondientes

Tipos de datos
A continuación, se muestra una tabla con equivalencias de los tipos de datos utilizados en
esta base de datos con otros gestores.

Tipo de dato Oracle MySQL SQL Server Sybase

INT NUMBER INT INT INT
VARCHAR VARCHAR2 VARCHAR VARCHAR VARCHAR
BYTEA BLOB VARBINARY VARBINARY IMAGE
SMALL INT NUMBER SMALLINT SMALLINT SMALLINT
FLOAT FLOAT FLOAT FLOAT FLOAT
DATE DATE DATE DATE DATE
TIMESTAMP TIMESTAMP DATETIME DATETIME DATETIME

Auditoria
Para realizar auditorías en esta base de datos se hará uso únicamente de los triggers antes
mencionados, además de realizar la activación de los archivos log en el sistema gestos.
Para activar los logs de PostgreSQL y poder visualizar los query que estamos ejecutando
en tiempo real debemos editar el archivo de configuración de PostgreSQL de la siguiente
manera:

nano /etc/postgresql/8.4/main/postgresql.conf

Luego descomentamos la línea log_statement y debe quedar de la asi:

log_statement = ‘all’

Guardamos los cambios y procedemos a reiniciamos el servicio

/etc/init.d/postgresql restart
 Luego para visualizar los logs en tiempo real aplicamos la siguiente instrucción:

tail -f /var/log/postgresql/postgresql-8.4-main.log

tail -f se utiliza para mostra las ultimas lineas del log en

tiempo real

Para Windows son los mismos pasos solo que cambiará la ruta en vez de ser etc será la
ruta donde este postgresql por default es

c:\Program Files\PostgreSQL\10 (caso de la versión 10 de otra forma esta

última parte cambiara)

Para verificar los logs en tiempo real en la línea de comandos o cmd se usa el comando:

Eventvwr

Monitoreo
Para realizar el monitoreo de la base de datos, se decidió utilizar la herramienta Zabbix.
Zabbix es un sistema para monitorear la capacidad, el rendimiento y la disponibilidad de los
servidores, equipos, aplicaciones y bases de datos. Además, ofrece características avanzadas
de monitoreo, alertas y visualización, que incluso, algunas de las mejores aplicaciones
comerciales de este tipo no ofrecen.
• Agregar y monitorear servidores, equipos, servicios, aplicaciones específicas,
dispositivos físicos como impresoras, routers, entre otros
• Reporte en tiempo real a través de gráficas, datos y alertas visuales que muestran
el estado y rendimiento de los servicios y equipos monitoreados
• Inventario de equipos para mantener al día la infraestructura tecnológica
• Mapas de la red de la empresa
• Configuración de notificaciones vía correo electrónico
• Perfiles de usuarios para el uso del administrador Web
• Permite monitorear las métricas en tiempo real recopiladas de máquinas virtuales,
servidores del sistema o cualquier tipo de dispositivo de red conectado.
• Las métricas ayudan a identificar el estado de su infraestructura de TI y los
problemas relacionados con los componentes de hardware y software.
• Las métricas o la información se pueden almacenar en una variedad de formatos
de base de datos que se pueden analizar más adelante para comprender y mejorar
la condición del servidor.
 • Esta aplicación utiliza una arquitectura cifrada cliente-servidor y un método de
comunicación entre los agentes del servidor y los clientes para recopilar los datos
y enviarlos al servidor.
• Los datos o la información están bien protegidos mientras se transfieren a través
de redes inseguras debido a su cifrado.
• Los datos o las métricas se pueden ver o analizar y la configuración del sistema se
puede configurar a través de una interfaz web intuitiva.
• Zabbix es maduro, una plataforma de nivel empresarial para monitorear entornos
de TI a gran escala.
• Ofrece agentes para monitorear host remoto.
• Zabbix también admite la supervisión del sistema a través de SNMP, TCP e ICMP.

Bases de datos soportadas:

• MySQL (5.03 en adelante)
• PostgreSQL (8.1 en adelante)
• Oracle (10g en adelante)
• SQLite (3.3.5 en adelante)

Replicacion
Para la creación de una réplica de base de datos usando PostgreSQL 10 en Ubuntu 18.04,
se emplearán dos maquina virtuales cada una con su instancia de PostgreSQL corriendo.
Lo primero que se deberá hacer es crea un usuario con permisos de replicación sobre la
base, el cual será usado para darle acceso de replicación en la bd-esclavo.

CREATE USER rep_master WITH LOGIN REPLICATION ENCRYPTED

PASSWORD ‘repli23’;

Como siguiente paso se procede a modificar el archivo postgresql.conf

$ sudo nano /etc/postgresql/10/main/postgresql.conf

Se ubica la línea

#listen_addresses = 'localhost' # what IP address(es)

to listen on;

Se procede a borrar el # de listen… y se agrega la dirección IP que se usará para la replica

listen_addresses = 'localhost,192.168.50.3' # what

IP address(es) to listen on;
 Continuando, se localiza la siguiente línea dentro del mismo archivo

#wal_level = replica # minimal, replica,

or logical

La cual se descomenta quitando el # de wal_le…. Y cambienado “replica” por “logical”

wal_level = logical

Una vez hecho esto, se guarda el archivo y se cierra nano.

Lo siguiente es abrir el archivo pg_hba.conf

$ sudo nano /etc/postgresql/10/main/pg_hba.conf

Y se localiza la siguiente línea

# TYPE DATABASE USER ADDRESS

METHOD
...
host all all 192.168.0.3/32
md5

Se cierra el archivo guardando los cambios.

Como siguiente paso se agregará una regla de acceso por medio del firewall de Ubuntu

$ sudo ufw allow from db_replica_private_ip_address to any

port 5432

Y se reinicia postgresql

$ sudo systemctl restart postgresql

Lo siguiente es montar la base de datos en ambas instancias, y una vez compleatado esto,
se usan las siguientes sentencias SQL en la instancia maestra

CREATE PUBLICATION my_publication;

ALTER PUBLICATION my_publication ADD TABLE my_table;

El ultimo comando se repite hasta la cantidad de tablas a replicar, con esto terminaríamos
en la instancia maestra.
Pasando a la instancia esclavo se introducen las siguientes sentencias SQL

CREATE SUBSCRIPTION my_subscription CONNECTION

'host=db_master_private_ip_address port=5432
password=my_password user=sammy dbname=example' PUBLICATION
my_publication;
Y si todo salió bien ya se tendrán las tablas indicadas replicadas en la instancia eslcavo.
Para probar esto, se insertan datos de prueba y estos deben aparecer en ambas instancias.