UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

(Universidad del Perú, DECANA DE AMÉRICA)

ESCUELA PROFESIONAL ACADÉMICA DE INGENIERÍA DE
SOFTWARE

CURSO: BASE DE DATOS II

DOCENTE: JORGE LUIS DEL MAR ARZOLA
TEMA: PROYECTO FINAL DEL CURSO - PARTE A
GRUPO: 8
INTEGRANTES:
- BALCEDA DELGADO, ADRIANA ISABEL 19200281
- DOMINGUEZ MATOS, JUAN MARTIN 19200275
- FANOLA TARAZONA, JONATHAN HERNAN 19200077
- HUARCAYA TACAS, EDWARD JOEL 19200113
- RAMOS RIVAS, KEVIN KEYLER 19200096

Lima, Perú
2022
Índice
Introducción 1
Vista Funcional de la Base de datos 1
Propósito 1
Objetivos 1
Objetivo principal 1
Objetivos específicos 1
Alcances y limitaciones 2
Alcances 2
Limitaciones 2
Reglas del negocio 2
Reglas del modelo de datos 2
Reglas de relación 2
Regla de flujo 3
Modelo conceptual 5
Modelo lógico 7
Modelo Físico 8
Creación de las tablas en SQL 9
Carga de datos a las tablas 9
Restricciones, consultas y optimización 10
Restricciones 10
Tabla Celda 10
Tabla Condena 10
Tabla Empleado 11
Tabla Nacionalidad 12
Tabla Pabellón 12
Tabla Personal 13
Tabla Rasgos 13
Tabla ReoVisita 14
 Tabla Tatuajes 15
Tabla TatuajesReo 15
Consultas 16
Consultas sin optimizar 16
Consultas con optimización 28
Comandos de administración de base de datos 34
Creación de Logins 34
Creación de usuarios 35
Asignar rol a un usuario 36
Asignar o revocar privilegios a un usuario 37
Creación de un plan de mantenimiento para la BD 38
Creación de CTE - COMMON TABLE EXPRESSION 42
Creación de Triggers y Stored Procedure 44
Conclusiones 47
Recomendaciones 48
Referencias 49
1. Introducción

El siguiente documento tiene como objetivo la creación de una base de datos para
un centro penitenciario, esta base de datos estará documentada desde su
concepción como modelo conceptual, luego pasando por el modelo conceptual,
luego un modelo lógico y finalmente siendo implementada en SQL Server haciendo
uso de Microsoft SQL Server Management Studio. Por último se incluirán todos los
temas vistos durante el semestre del curso de Base de datos II que corresponden a
la administración de base de datos.

2. Vista Funcional de la Base de datos

2.1. Propósito

Nuestro país no se encuentra libre de que se cometan distintos crímenes, cuyas

incidencias van incrementando año tras año. Debido a esto, existen centros
penitenciarios que albergan más presos excediendo el aforo o capacidad total.

Entonces, al existir una sobrepoblación carcelaria, debe haber una correcta gestión
y administración de la información correspondiente a cada uno de las personas
encarceladas, asegurándose que su información sea correcta para evitar errores
administrativos. De igual forma, se busca registrar la información del personal que
labora en la penitenciaría.

Se destaca entonces que, para una adecuada gestión penitenciaria se debe contar
con los datos e información suficientes de cada una de las entidades.

2.2. Objetivos

A continuación, se detalla el objetivo principal de este trabajo, además de objetivos

específicos que guiarán el rumbo de todo este trabajo.

2.2.1. Objetivo principal

● Crear una base de datos que permita administrar de forma adecuada los
distintos datos que tiene un centro penitenciario.

2.2.2. Objetivos específicos

● Tener un registro óptimo de los distintos tipos de reos que ingresan a la

penitenciaría, teniendo en cuenta información relevante como el tipo de
delito, características físicas y su ubicación dentro del centro penitenciario.
● Dar la facilidad de búsqueda por parte de las autoridades ante cualquier
requerimiento de información.

1
 ● Evitar la pérdida de información con el pasar del tiempo que puede ser
perjudicial si es que no se almacena correctamente.
● Distribución correcta de los reos al centro penitenciario ya que en los centros
penitenciarios de nuestro país tienen hacinamiento.

2.3. Alcances y limitaciones

A continuación se detallan los diversos alcances y limitaciones de nuestro proyecto.

2.3.1. Alcances

● El proyecto abarca un sistema de gestión penitenciaria basado en el modelo

de gestión del Perú y aplicable en este, más no de otros países que puedan
gestionar y administrar sus cárceles de una forma distinta.
● Se llegará a abarcar la información de los servicios básicos de los reos en un
campo general.

2.3.2. Limitaciones

● El sistema de gestión penitenciaria se limitará a almacenar la información de

los encarcelados durante el cumplimiento de su condena. Concluido dicho
periodo de tiempo, no se tendrá un seguimiento del liberado pues
corresponde a una gestión postpenitenciaria que se encontrará a cargo de
otro organismo o entidad estatal.
● El sistema de gestión estará ligado con el Poder Judicial para una mejora
interacción de los datos de los presos y a un mejor uso de estos.

2.4. Reglas del negocio

a.Reglas del modelo de datos

● Los datos numéricos deben ser positivos.
● Todas las fechas deben ser válidas.
● El sexo de los reos del centro penitenciario solo puede ser masculino.
● Los datos sobre altura y peso deben contener a lo más dos decimales.
● El código de la nacionalidad será almacenado según la ISO 3166-1 alfa-3.
● Para los puestos de trabajo en el centro penitenciario, tendrán un idArea
conformada por las 2 primeras letras del nombre del área + números.
● Las fotos serán colocadas de tipo varbinary(50).

b. Reglas de relación
● Un reo que haya ingresado al centro penitenciario, se deberá garantizar que
no es posible retirarlo, salvo que se cumpla la sentencia completa.
● Uno de los campos de visitante deberá ser el reo al cual visitan

2
● Un empleado del centro penitenciario deberá estar siempre asociado a un
área dentro de este centro penitenciario.

c. Reglas de restricciones

● Todos los datos no pueden ser nulos.

● El ingreso de datos de nombres y apellidos no debe superar los 50 caracteres
y no pueden ser nulos.
● El total de aforo dentro de un pabellón no debe de exceder de 120
presidiarios.
● El número de celdas en los pabellones no debe de exceder de los 35.
● El número máximo de reos en una carceleta o celda es 4.
● Solo existirán 5 tipos de color de piel en el registro (blanco, negro,
mestizo,asiático,amerindio).
● El peso y la altura deben de ser números positivos y se medirán en kg y en
metros, respectivamente.
● El dato “tiempoCarcel” deberá estar expresado en meses y días, y deberá ser
mayor a 0. Para cadena perpetua, no podrá ser expresado como tal.
● Las fechas deben estar expresadas en año, mes y día siguiendo el formato
(aaaa-mm-dd).
● Los campos fechaIngreso y fechaSalida (condena de un reo) deberán estar
expresados en horas, minutos y segundos.
● Los campos horaIngreso y horaSalida (visitantes) deberán estar expresados
en horas, minutos y segundos.
● El sexo del personal y visitante solo debe de ser femenino o masculino.

d. Regla de flujo

● Antes de las visitas del prisionero se deben registrar los datos de las
personas que ingresan
● Después de las visitas del prisionero se registrará la hora de salida
● El número máximo de horas de visita son 3 horas.

3
A continuación, se muestran las principales entidades que serán tomadas en cuenta
para el desarrollo de esta base de datos con algunos campos que creemos serán
necesarios.

4
3. Modelo conceptual

El siguiente modelo fue realizado teniendo en cuenta las entidades definidas

previamente, este gráfico fue realizado haciendo uso del software Star UML que
nos ayuda a hacer estos gráficos de forma sencilla.

5
El siguiente diagrama de entidad relación (ER) fue realizado teniendo en cuenta
las entidades definidas previamente, este gráfico fue realizado haciendo uso del
software web LucidChart, en este se define de mejor manera los atributos de
cada entidad.

6
4. Ventajas y desventajas

VENTAJAS DESVENTAJAS

Correcta definición de las entidades y Posible falta de optimización con el fin de

relaciones entre ellas. hacerlo más eficiente.

Tiene concordancia el modelo con la Posible falta de algunas entidades que

estructura del proyecto. precisen más en el proyecto.

El modelo conceptual cuenta con las correctas No se contempló el traslado de un preso de un

cardinalidades. lugar a otro

El modelo contempla que todas aquellas No se contempló que a un preso pueda tener
personas que visitan a un preso sean una reducción de la condena ya que según las
registradas en la base de datos, esto aumenta reglas de negocio esta no puede ser variada.
la seguridad del establecimiento penitenciario.

5. Modelo lógico

El siguiente diagrama lógico fue realizado teniendo en cuenta el gráfico del

diagrama conceptual, este gráfico fue realizado haciendo uso del software web
LucidChart, en este se define de mejor manera los atributos de cada entidad.
Hay que tener en cuenta que este gráfico varió mucho con respecto al original
debido a que después de hacer el modelo conceptual se aplicó de
normalización, resultando en el diagrama actual.

7
 Para una mejor visualización del modelo, ingresar al siguiente link
https://drive.google.com/file/d/1gH7zqfPReJh-o8P1lTdYmXDmrJ7-L2pS/view?us
p=sharing

6. Modelo Físico

8
7. Creación de las tablas en SQL

A continuación se comparte un enlace al documento donde se detalla el código SQL

para llevar a cabo la creación del esquema de la base de datos, según el modelo
lógico.

SCRIPT ESQUEMA BASE DE DATOS PRISIÓN

ARCHIVO SQL DEL ESQUEMA DE LA BASE DE DATOS

8. Carga de datos a las tablas

A continuación se comparte un enlace al documento donde se detalla el código SQL

para llevar a cabo la carga de datos a la base de datos creada previamente en el
punto 6.

CARGA DE DATOS EN LA BASE DE DATOS

ARCHIVO SQL DE CARGA DE DATOS EN LA BASE DE DATOS

9
9. Restricciones, consultas y optimización

9.1. Restricciones

a) Tabla Celda

idCelda
Para este primer check constraint se requiere que los datos introducidos en la
columna idCelda siempre puedan empezar con la letra C seguidos de caracteres
numéricos.

ALTER TABLE Celda

ADD CONSTRAINT valid_idCelda
CHECK(idCelda LIKE 'C%')

camas
Crearemos un check constraint que nos asegure que al introducir datos en el campo
camas, estos siempre sean un número positivo. De esta manera nuestros datos en
esta tabla tendrán siempre sentido de acuerdo al objetivo de la BD.

ALTER TABLE Celda

ADD CONSTRAINT valid_numCamas
CHECK(camas > 0)

Nótese que ambos constraint fueron creados con éxito en el explorador de objetos
de SSMS.

b) Tabla Condena

fecha_inicio, fecha_fin
Se creará un check constraint que comparta que ambas fechas no son iguales y que
sino la data no tendría sentido ya que un preso no puede tener como fecha de inicio
de condena el mismo día en el que acaba.

USE centropenitenciario

10
ALTER TABLE Condena
ADD CONSTRAINT valid_date
CHECK([fecha_inicio]<>[fecha_fin])
Ahora crearemos otra nueva restricción para esta tabla ya que también debemos
cerciorarnos que la fecha de fin de condena siempre sea mayor que la fecha de
inicio de la condena del preso.

USE centropenitenciario
ALTER TABLE Condena
ADD CONSTRAINT valid_startDate_endDate
CHECK(fecha_inicio < fecha_fin);

idReo
Por último crearemos un check constraint para el campo de idReo , sabemos por
nuestras reglas de negocio que este tipo de dato está identificado con una R al inicio
seguido de un código numérico, para impedir que datos que nos correctos puedan
ingresarse creamos este nuevo constrain.

ALTER TABLE Condena

ADD CONSTRAINT valid_idReo
CHECK(idReo LIKE 'R%')

Vemos que los tres check constraint fueron creados exitosamente en el explorador
de objetos de SSMS.

c) Tabla Empleado

Nacionalidad_Empleado
Una forma de crear el Check Constraint es en el mismo momento de crear la tabla.
En nuestro caso la columna de [nacionalidad_empleado] sólo contiene 3 caracteres
debido a una norma ISO.

11
Ahora vemos que se creó correctamente.

d) Tabla Nacionalidad

IdNacionalidad
Ahora creamos un checkConstraint para la columna [idNacionalidad] de la tabla
Nacionalidad. El caso es el mismo que el anterior donde cada id debe de estar
formado por 3 caracteres según norma ISO.

ALTER TABLE Nacionalidad ADD CONSTRAINT

CH_nacionalidad CHECK (len(idNacionalidad)=3)

Vemos que se creó correctamente:

e) Tabla Pabellón

IdPabellon
Creamos un check Constraint para la columna [idPabellon] de la tabla Pabellon. El
caso es que la id se debe identificar con una ‘P’ seguido de un código numérico.

ALTER TABLE Pabellon

ADD CONSTRAINT CHK_Pabellon_idPabellon

12
CHECK (idPabellon LIKE 'P%')

Planta
Creamos un check Constraint para la columna [planta] de la tabla Pabellon, de modo
que este solo acepta datos cuyo número sea positivo.

ALTER TABLE Pabellon

ADD CONSTRAINT CHK_Pabellon_planta

CHECK (planta > 0)

f) Tabla Personal

IdEmpleados
Creamos un check Constraint para la columna [idEmpleado] de la tabla
PersonalEmpleo, de modo que solo acepte datos ingresados que sean números
positivos.

ALTER TABLE PersonalEmpleo

ADD CONSTRAINT CHK_Pabellon_PersonalEmpleo

CHECK (idEmpleado > 0)

g) Tabla Rasgos

Tez
Se creará un Check Constraint para establecer el ingreso de valores para el campo
tez.

ALTER TABLE [dbo].[Rasgos]

ADD CONSTRAINT valid_tez

CHECK(tez IN ('Blanco', 'Negro', 'Mestizo', 'Amerindio', 'Asiático'))

Peso
Se creará un Check Constraint para que el peso sea un número natural.

ALTER TABLE [dbo].[Rasgos]

13
ADD CONSTRAINT valid_peso

CHECK(peso>0)

Altura
Se creará un Check Constraint para la altura para que este sea un número natural.

ALTER TABLE [dbo].[Rasgos]

ADD CONSTRAINT valid_altura

CHECK(altura>0)

idReo
Por último crearemos un check constraint para el campo de idReo , sabemos por
nuestras reglas de negocio que este tipo de dato está identificado con una R al inicio
seguido de un código numérico, para impedir que datos que nos correctos puedan
ingresarse creamos este nuevo constraint.

ALTER TABLE [dbo].[Rasgos]

ADD CONSTRAINT valid_idReo

CHECK(idReo LIKE 'R%')

h) Tabla ReoVisita

idVisitante
Crearemos un check constraint para el campo de idVisitante, sabemos por nuestras
reglas de negocio que este tipo de dato está identificado con una V al inicio seguido
de un código numérico, para impedir que datos que nos correctos puedan
ingresarse creamos este nuevo constraint.

14
ALTER TABLE [dbo].[ReoVisita]

ADD CONSTRAINT valid_idVisit

CHECK(idVisitante LIKE 'V%')

hora_ingreso, hora_salida
Se creará un Check Constraint para establecer que la de hora_ingreso debe ser
diferente a hora_salida.

ALTER TABLE [dbo].[ReoVisita]

ADD CONSTRAINT validHora
CHECK([hora_ingreso]<>[hora_salida])

Luego se creará un Check Constraint para establecer que hora_ingreso debe ser
menor que hora_salida.

ALTER TABLE [dbo].[ReoVisita]

ADD CONSTRAINT validHorario
CHECK(hora_ingreso < hora_salida)

i) Tabla Tatuajes

IdTatuaje
Se creará un Check Constraint para el id de los tatuajes para que este sea un
número natural.

ALTER TABLE [dbo].[Tatuajes] ADD CONSTRAINT CK_idTatuaje CHECK (idTatuaje>0)

j) Tabla TatuajesReo

IdTatuaje
Se creará un Check Constraint para el id de los tatuajes para que este sea un
número natural.

15
 ALTER TABLE [dbo].[TatuajesReo] ADD CONSTRAINT CK_TatuajesReo CHECK
(idTatuaje>0)

9.2. Consultas

a) Consultas sin optimizar

i) Consultando a los reos que sean peruanos o venezolanos y que se
encuentren por debajo de la edad promedio.
Como sabemos en nuestro país el número de delitos se ha incrementado
notablemente y estos son perpetrados en su mayoría por ciudadanos de
nacionalidad peruana, colombiana o venezolana. Los delitos que estos
cometen van desde leves a muy graves y sería muy importante hacer un
estudio de qué crímenes son los que en su mayoría se cometen y que edad
tienen aquellos que fueron condenados.
La siguiente consulta tiene como propósito el poder encontrar a reos
peruanos y venezolanos que tengan su edad debajo de la edad promedio,
esto podría servirnos como ya se mencionó anteriormente para poder hacer
un estudio que podría servir para que el estado pueda enfocar sus políticas
públicas de reinserción social o encontrar algunas pistas de por qué cada vez
son más los delitos cometidos por ciudadanos de estas nacionalidades.

Autores

Dominguez Matos, Juan Martin

Huarcaya Tacas, Edward Joel

Ramos Rivas, Kevin Keyler

select concat(r.nombre_reo,' ',r.apellido_paterno_reo,' ',r.apellido_materno_reo) as

Reo,datediff(year,r.fecha_nacimiento_reo,getdate()) as Edad,

16
 n.nombre_nac,d.nombre_del from reo as r
inner join Nacionalidad as n on n.idNacionalidad = r.nacionalidad_reo
inner join ReoDelito as rd on rd.idReo = r.idReo
inner join Delito as d on d.idDelito = rd.idDelito
where datediff(year,r.fecha_nacimiento_reo,getdate()) < (select
avg(datediff(year,r.fecha_nacimiento_reo,getdate())) as Edad from Reo as r)
and n.nombre_nac in('Perú','Venezuela')
order by concat(r.nombre_reo,' ',r.apellido_paterno_reo,' ',r.apellido_materno_reo);

Salida de la consulta 1

17
Gráfico del Plan de ejecución de consulta no optimizada número 1

Análisis del Plan de ejecución de consulta no optimizada #1:

a. Operadores e íconos del plan de ejecución
Los íconos representan a distintos operadores, los cuales, para el presente plan de ejecución, son:

Ícono Operador Ícono Operador

Clustered index scan (Clustered) Nested Loops

Escaneo de índice agrupado (Agrupado)
Bucles Anidados

18
 Compute Scalar Sort

Cómputo Escalar Orden

Stream Aggregate (Aggregate) Clustered index seek (Clustered)

Agregado de Flujo (Agregado) Búsqueda de índice agrupado (Agrupado)

b. Interpretación del Plan de ejecución

● En la gráfica del Plan de ejecución, lo primero en
mostrarse es el operador Clustered index scan
(Clustered), el cual hace referencia a la tabla Reo y
su primary key ‘idReo’. Cuando se definió ‘idReo’ como llave primaria de la tabla Reo, se creó de manera automática
un índice agrupado para dicha tabla. Ello puede verificarse usando el comando ‘EXECUTE sp_helpindex Reo’,
mostrando el resultado de la imagen.
Este operador es usado para leer todos los datos de un índice agrupado de una tabla (índice ‘PK_Reo’ de la tabla
Reo). Por dicha razón, se leyeron los 101 de 101 registros que se contaban al momento de ejecutar la consulta. Por
ello, el costo fue del 100%. De este operador, se tiene un object [centropenitenciario].[dbo].[Reo].[PK_Reo][r] y un
output [centropenitenciario].[dbo].[Reo].fecha_nacimiento_reo, puesto que es el dato requerido en la segunda línea
de la consulta, en datediff(year,r.fecha_nacimiento_reo,getdate()). Cabe mencionar que los datos que buscamos
obtener de la tabla Reo son el nombre del Reo, su apellido paterno y apellido materno, únicamente.

● Luego, aparece el operador Compute Scalar. Este operador es usado para calcular nuevos valores basados en
valores de otras columnas. Estos nuevos valores son calculados mediante una operación de nombre “cálculo

19
 escalar”. Tal como se ve en la gráfica del plan de ejecución, tiene como input al output del operador anterior. Esto se
debe a que se calcularán nuevos valores para la fecha de nacimiento del reo a partir de la columna
‘fecha_nacimiento_reo’ de la tabla ‘Reo’. En SQL Server, se señala que el tipo de dato a obtener en este Compute
Scalar es datetimeoffset.

● Seguidamente, encontramos al operador Stream Aggregate (Aggregate). Tiene una sola entrada y una sola salida
y, normalmente, el número de filas como output es mucho menor que el input porque devuelve solo una fila para
cada grupo de filas recibidas como input. Recordar que usa datos que han sido ordenados previamente para realizar
la agregación de una forma rápida. Los tipos de agregación más habituales son SUM y AVG y, justamente, SUM es
la agregación que aparece al ejecutar mostrar el Plan de ejecución, exactamente en
datediff(year,r.fecha_nacimiento_reo,getdate()), al querer sumar los valores de diferencia entre ‘year’ y
‘fecha_nacimiento_reo’.

● Nuevamente, aparece un Compute Scalar. Esto se debe a que calculará nuevos valores basados en valores de
otras columnas, en este caso, convierte los valores output del operador anterior (Stream Aggregate (Aggregate)).

● En la línea inferior, se aprecia otro Clustered index scan (Clustered), que también hace referencia a la tabla Reo y
su primary key ‘idReo’. Sin embargo, este es de tipo ORDERED FORWARD SCAN, el cual devuelve los datos en el
orden que se especificó cuando se creó el índice. Seguidamente, aparece un operador Compute Scalar, del cual ya
comprendemos su rol en el Plan de ejecución.

● Ambos operadores Compute Scalar de las 2 líneas analizadas son nodos hijos del nodo Nested Loops (Inner
Join), este último viene a ser el nodo padre. Este operador realiza las operaciones de JOIN y se realizan búsquedas
en la tabla interna por cada fila de otra tabla externa. Se devolverán las filas que cumplen con un predicado:
(datediff(year,[Expr1013],CONVERT_IMPLICIT(datetimeoffset(3),getdate(),0))<[Expr1006])), siendo Expr1006 el
output tras ejecutar el Compute Scalar de la línea superior y Expr1013, el de la línea inferior.

20
 Se aprecia que se obtiene un porcentaje de 101% (55 de 54). Tal como señala Ariely (2020), “este error en el cálculo
del costo de la operación ocurre raramente y se debe a un error de la herramienta de cálculo de porcentajes de costo
por el lado del cliente”.

● En un tercer nivel, aparece un operador Clustered index seek (Clustered), el cual se usa cuando el requisito es
obtener datos filtrados. Si una tabla tiene una clave principal (índice agrupado) y se escribe una consulta para filtrar
algunos registros con la ayuda del índice agrupado, se realizará la operación de búsqueda del índice agrupado
[Clustered index seek]. En este caso, se está buscando la nacionalidad de un reo, accediendo por lo tanto, a la tabla
Nacionalidad y haciendo uso de su primary key ‘PK_Nacionalidad’.
● Después, se muestra que Clustered index seek (Clustered) (analizado en el punto anterior) y un primer Nested
Loops son inputs al siguiente Nested Loops. Ello ocurre por lo especificado en la consulta, exactamente en la 4ta
línea, en inner join Nacionalidad as n on n.idNacionalidad = r.nacionalidad_reo, donde se consultan los datos de la
tabla Reo y la tabla Nacionalidad. Estas se comparan primero debido al orden en el que fue escrita la consulta. Al
realizarse este Inner Join, se obtiene como output un conjunto de datos filtrado en primera instancia (Reos que sean
de Perú o Venezuela).

● Luego, se muestra el operador Sort. Este se encargará de ordenar los datos recopilados siguiendo el orden
establecido en la consulta, que viene a ser order by concat(r.nombre_reo,' ',r.apellido_paterno_reo,'
',r.apellido_materno_reo). ¡Nótese que se obtiene un costo de 1% y se obtiene un 462% (37 de 8)!. Ello puede ser
resultado de un error de cálculo del porcentaje del costo (explicado en puntos anteriores, citando a Ariely).

● Bajo el operador Sort, aparece

el operador Table Scan, el cual
se usa para leer todos o la
mayoría de los datos de una

21
 tabla que no tiene un índice agrupado. Ello puede comprobarse al usar el comando ‘EXECUTE sp_helpindex
ReoDelito’, obteniendo este resultado. Esta operación tiene un costo de 11% y se han leído 3700 filas para un
estimado de 771 filas, representando un porcentaje de 479%.
Esto fue para un object [centropenitenciario].[dbo].[ReoDelito].[rd], del cual se obtuvo un output
[centropenitenciario].[dbo].[ReoDelito].idReo, [centropenitenciario].[dbo].[ReoDelito].idReo. Aquí se relacionan tanto
la tabla ReoDelito y Delito para obtener los resultados esperados de la consulta.

● Tanto el Sort como el Table Scan son nodos hijos del nodo padre Nested Loops a continuación. Mediante la
operación Inner Join, se obtendrá un filtro de los datos que cumplan el predicado
‘[centropenitenciario].[dbo].[ReoDelito].[idReo] as [rd].[idReo] = [centropenitenciario].[dbo].[Reo].[idReo] as
[rd].[idReo]’.

● Aparece un último Nested Loops en el Plan de ejecución.

Este guarda relación con el output del Nested Loops
anterior con el Clustered index seek (Clustered) para la
tabla Delito, con índice ‘PK_Delito’. Del Inner Join entre
ambos, se obtuvieron 35 resultados de 101 registros de la tabla Reo. Finalmente, el Compute Scalar quiere decir
que se computan nuevos valores basados en otras columnas.

c. ShowPlan Text
Mediante este comando ‘SET SHOWPLAN_TEXT ON’, se muestra en formato de texto el Plan de ejecución que se mostró
gráficamente en SSMS. Para esta consulta, el texto obtenido es el mostrado en la página siguiente. Este muestra con
mayor detalle el proceso llevado a cabo en el Plan de ejecución de la consulta.

22
23
ii) Consultando la persona que visita y a quien visita, junto con las horas
visitadas, ubicación de la celda y pabellón. Adicionalmente se le agregó
un indicador que dice si el horario está por encima de las 3 horas
permitidas.
Creemos que la seguridad es muy importante en un centro penitenciario, sin
embargo muchas veces, aprovechando el horario de visita los familiares o
conocidos de un reo. ingresan objetos ilícitos que los reos usan para
actividades ilícitas como extorsiones desde la cárcel, órdenes a sicarios, etc.
Además del ingreso de objetos a veces se suele aprovechar este tiempo de
visita para coordinar de forma directa o indirecta actividades ilícitas.
Esta consulta tiene como propósito el poder consultar de una forma sencilla
información que nos puede ser de utilidad para investigar posibles actos
ilícitos ya que la consulta nos brinda información relevante como la cantidad
de horas que visita una persona a un preso, la ubicación del preso además
de indicarnos si la cantidad de horas de visita excede el número máximo de
horas permitidas.

Autores

Balceda Delgado Adriana

Fanola Tarazona Jonathan

Nota 1 : Se guardo la consulta en una tabla temporal(into #Temporal) para poder

usarlo en consultas futuras.

select concat(v.nombre_vis,' ',v.apellido_paterno_vis,' ',v.apellido_materno_vis)

as Visitante,
concat(r.nombre_reo,'',r.apellido_paterno_reo,'',r.apellido_materno_reo) as
Reo,
rv.fecha_visita,DATEDIFF(HOUR,rv.hora_ingreso,rv.hora_salida) as
HorasVisitadas,
case when (DATEDIFF(HOUR,rv.hora_ingreso,rv.hora_salida) > 3)
then 'Exceso'
else 'Normal'
end as Condicion,
ru.idCelda,pc.idPabellon
into #Temporal
from visitante as v
inner join ReoVisita as rv on rv.idVisitante = v.idVisitante
inner join Reo as r on r.idReo = rv.idReo
inner join ReoUbicacion as ru on ru.idReo = r.idReo
inner join Celda as c on c.idCelda = ru.idCelda
inner join PabellonCelda as pc on pc.idCelda = c.idCelda

24
Gráfico del Plan de ejecución de consulta no optimizada número 2

25
 Análisis del Plan de ejecución de consulta no optimizada #2:
a. Operadores e íconos del plan de ejecución
Los íconos representan a distintos operadores, los cuales, para el presente
plan de ejecución, son:

Ícono Operador Ícono Operador

Clustered index scan (Clustered)

Nested Loops
Escaneo de índice agrupado
(Agrupado) Bucles Anidados

Compute Scalar Sort

Cómputo Escalar Orden

Clustered index seek (Clustered)

Stream Aggregate (Aggregate)
Búsqueda de índice agrupado
Agregado de Flujo (Agregado)
(Agrupado)

b. Interpretación del plan de ejecución

● En el plan de ejecución se muestra el “Table Scan” o el escaneo de tablas,

específicamente de las tablas “PabellonCelda”, “ReoUbicacion” y “ReoVisita”.

● En la parte inferior aparece un “Compute Scalar” que se encarga de calcular

nuevos valores a partir de los valores de otras columnas a través de la
operación “Compute Scalar” dando como output “idVisitante”, “fecha_visita”.

● En la parte superior aparece un “Hash Match” y teniendo como output

“idReo”, “idCelda”, “idPabellon”, también como hash key probe “idCelda”.

● Aparece el “Clustered index seek” que tiene como función leer valores para
encontrar entradas que coinciden, dando como lista de output “nombre_vis”,
“apellido_paterno_vis” y “apellido_materno_vis”.

● Del hash match y el clustered index seek, ocurre un “nested loops” o bucles
anidados, en donde se busca el resultado desde una tabla y después
seleccionar otra tabla por cada fila de la primera, siendo el idVisitante la

26
 referencia y seleccionando las tablas “Visitante”, “ReoVisita”, “ReoUbicacion”,
“PabellonCelda”.

● Después aparece otro Compute Scalar que se encarga de calcular los

nuevos valores desde valores existentes de otras columnas dando como una
lista de outputs “fecha_visita”, “idReo”, “idCelda”, “idPabellon”.

● En la parte inferior se puede visualizar otro clustered index seek o búsqueda

de índice agrupado dando como lista de output “nombre_reo”,
“apellido_paterno_reo”, “apellido_materno_reo”.

● Vemos otro nested loops, que toma como referencia “idReo” y pasando por
las tablas “Reo”, “ReoUbicacion”, “PabellonCelda”.

● Después aparece otro compute scalar dando como lista de output

“fecha_visita”, “idCelda”, “idPabellon”.

● Después está el “table insert” o la inserción de tabla, que en este caso es la

tabla “#Temporal”.

c. ShowPlan Text
Mediante este comando ‘SET SHOWPLAN_TEXT ON’, se muestra en
formato de texto el Plan de ejecución que se mostró gráficamente en SSMS.

27
b) Consultas con optimización
i) Consultando a los reos que sean peruanos o venezolanos y que se
encuentren por debajo de la edad promedio.

28
Creación de una columna adicional en la tabla Reo
Empecemos optimizando la consulta dandonos cuenta que las palabras resaltadas
en amarillo suelen repetirse mucho, estas lienas nos ayudan a poder calcular la
edad de los presos. Para optimizar esto sería más lógico que en vez de estar
calculando esto tantas veces, esa columna con la información de la edad del preso
debería crearse en la tabla Reo.

USE centropenitenciario;
ALTER TABLE Reo
ADD Edad as datediff(year,Reo.fecha_nacimiento_reo,getdate());

La consulta anterior crea justamente la nueva columna en la tabla Reo, a

continuación vamos a modificar la primera consulta para analizar posteriormente
qué tanto ayuda esto.

La consulta con los cambios quedaría de la siguiente manera, hemos sustituido la

parte que calculaba la edad gracias a la columna Edad de la tabla Reo.

Adición de una función que ya tenga el valor del promedio de edades

Otra optimización que podemos hacerle a la consulta sería crear una función que
tenga calculado el valor del promedio de edad de los reos, ya que de la forma en la
que se encuentra ahora se está calculando cada vez que se hace la consulta.
Donde se encuentran las letras de amarillo se puede apreciar esto.

29
A continuación, crearemos una función con la siguiente instrucción:

GO
CREATE FUNCTION promedio_edad ()
RETURNS FLOAT
AS
BEGIN
DECLARE @promedioEdad FLOAT;
SET @promedioEdad = (select avg(Reo.edad) from Reo);
return @promedioEdad
END;

La nueva consulta quedaría así después de hacer uso de esta variable:

Adición de un índice clustered a la tabla ReoDelito

Haciendo uso del plan de consulta analizado previamente, podemos darnos cuenta
de un detalle, en la tabla ReoDelito para hacer la consulta se está recorriendo cada
fila de la tabla, esto como se vio en clase es muy ineficiente. Esto puede ser
solucionado de una forma sencilla y es creando un índice, para esto en el buscador
de objetos buscamos si es que en esta tabla existe o no un índice.

30
Como vemos no existe ningún índice, entonces para poder agilizar aún más la
consulta podemos hacer uso de un índice clustered, ya que como se explicó en
clase una tabla sólo puede tener un índice de este tipo. Para ello usamos esta
consulta SQL para crear el índice mencionado anteriormente.

31
ii) Consultando la persona que visita y a quien visita, junto con las horas
visitadas, ubicación de la celda y pabellón. Adicionalmente se le agregó
un indicador que dice si el horario está por encima de las 3 horas
permitidas.

Iniciamos la optimización de la consulta observando que la diferencia entre la

hora de entrada de un visitante con la hora de salida del mismo al penal
representado por DATEDIFF(HOUR,rv.hora_ingreso,rv.hora_salida) es un
dato que se repite a lo largo de la consulta es por ello que para optimizarla
crearemos un campo destinado a este dato en la tabla ReoVisita al cual
daremos por nombre duración.

También, nos percatamos de que a la tabla ReoVisita le faltaba un índice

clustered para poder agilizar la consulta.

32
Esta consulta crea el campo ‘duracion’ en la tabla ReoVisita, una vez
realizada procedemos a hacer uso de este nuevo campo en la consulta que
deseamos optimizar.

33
10. Comandos de administración de base de datos

10.1. Creación de Logins

10.1.1. Usuario Adriana

-- Usuario Adriana

USE [master]

GO

CREATE LOGIN [Adriana] WITH PASSWORD= '2536contraseña1*' ,

DEFAULT_DATABASE=[centropenitenciario]

10.1.2. Usuario Edward

-- Usuario Edward

USE [master]

GO

CREATE LOGIN [Edward] WITH PASSWORD= '2536contraseña2*' ,

DEFAULT_DATABASE=[centropenitenciario]

10.1.3. Usuario Juan

-- Usuario Juan

USE [master]

GO

CREATE LOGIN [Juan] WITH PASSWORD= '2536contraseña3*' ,

DEFAULT_DATABASE=[centropenitenciario]

10.1.4. Usuario Jonathan

-- Usuario Jonathan

USE [master]

GO

CREATE LOGIN [Jonathan] WITH PASSWORD= '2536contraseña4*' ,

34
 DEFAULT_DATABASE=[centropenitenciario]

10.1.5. Usuario Kevin

-- Usuario Kevin

USE [master]

GO

CREATE LOGIN [Kevin] WITH PASSWORD= '2536contra#*' ,

DEFAULT_DATABASE=[centropenitenciario]

10.2. Creación de usuarios

10.2.1. Creación de usuario s_Adriana

-- Creación de usuario s_Adriana

USE [centropenitenciario]

GO

CREATE USER s_Adriana FOR LOGIN Adriana

10.2.2. Creación de usuario s_Edward

-- Creación de usuario s_Edward

USE [centropenitenciario]

GO

CREATE USER s_Edward FOR LOGIN Edward

10.2.3. Creación de usuario s_Juan

-- Creación de usuario s_Juan

USE [centropenitenciario]

GO

CREATE USER s_Juan FOR LOGIN Juan

10.2.4. Creación de usuario s_Jonathan

-- Creación de usuario s_Jonathan

35
 USE [centropenitenciario]

GO

CREATE USER s_Jonathan FOR LOGIN Jonathan

10.2.5. Creación de usuario s_Kevin

-- Creación de usuario s_Kevin

USE [centropenitenciario]

GO

CREATE USER s_Kevin FOR LOGIN Kevin

10.3. Asignar rol a un usuario

Para esta parte se considero los roles brindados por la documentación oficial de
SQL Server de Microsoft, a continuación el enlace de donde nos basamos:

Roles de base de datos predeterminadas

10.3.1. Asignación de un rol al usuario s_Adriana

-- Asignación de un rol al usuario s_Adriana

USE [centropenitenciario]

ALTER ROLE db_datareader add member s_Adriana

10.3.2. Asignación de un rol al usuario s_Edward

-- Asignación de un rol al usuario s_Edward

USE [centropenitenciario]

ALTER ROLE db_datawriter add member s_Edward

10.3.3. Asignación de un rol al usuario s_Juan

-- Asignación de un rol al usuario s_Juan

USE [centropenitenciario]

ALTER ROLE db_owner add member s_Juan

10.3.4. Asignación de un rol al usuario s_Jonathan

36
 -- Asignación de un rol al usuario s_Jonathan

USE [centropenitenciario]

ALTER ROLE db_datareader add member s_Jonathan

10.3.5. Asignación de un rol al usuario s_Kevin

-- Asignación de un rol al usuario s_Kevin

USE [centropenitenciario]

ALTER ROLE db_owner add member s_Kevin

10.4. Asignar o revocar privilegios a un usuario

10.4.1. Asignación de privilegios al usuario s_Adriana

-- Asignación de privilegios al usuario s_Adriana

USE [centropenitenciario]

GRANT SELECT,INSERT ON dbo.Visitante TO s_Adriana

GRANT SELECT,INSERT ON dbo.ReoVisita TO s_Adriana

10.4.2. Asignación de privilegios al usuario s_Edward

-- Asignación de privilegios al usuario s_Edward

USE [centropenitenciario]

REVOKE INSERT,UPDATE ON dbo.Reo FROM s_Edward

REVOKE INSERT,UPDATE ON dbo.Condena FROM s_Edward

10.4.3. Asignación de privilegios al usuario s_Jonathan

-- Asignación de privilegios al usuario s_Jonathan

USE [centropenitenciario]

GRANT SELECT,INSERT,UPDATE ON dbo.Visitante TO s_Adriana

GRANT SELECT,INSERT,UPDATE ON dbo.ReoVisita TO s_Adriana

37
10.5. Creación de un plan de mantenimiento para la BD

- Vamos a la carpeta planes de mantenimiento.

- Seleccionamos “Asistente para planes de mantenimiento”.

- Realizamos la configuración sobre la programación de trabajo.

38
- Ahora marcamos las tareas de mantenimiento que se realizarán en nuestra
base de datos.

- Seleccionamos la base de datos a la que se le realizarán los planes de

mantenimiento.

39
40
- Nos informará en donde se guardará el informe acerca del plan de
mantenimiento, si no estamos de acuerdo con la ubicación se puede cambiar.

- Por último, le damos click a “Finalizar”.

- Finalmente, nos tiene que salir que se realizó exitosamente el proceso.

41
 - Ahora, podemos ver que se creó en la carpeta de “Planes de mantenimiento”.

10.6. Creación de CTE - COMMON TABLE EXPRESSION

10.6.1. CTE - Datos del reo

Esta CTE ‘reo_datos’ selecciona el id y la fecha de nacimiento del Reo para

que, con la fecha del día de ejecución de esta CTE y la fecha del nacimiento
del Reo, se obtenga la edad del Reo.

42
10.6.2. CTE - Datos de un reo asociado a su delito

En esta tabla de expresión común (CTE), de nombre DatosReo_Delito, se

seleccionan los datos personales del Reo y se asocia a ellos el código del
delito que cometieron. En la consulta, se hizo un llamado a dicha CTE,
estableciendo una condición adicional de que las nacionalidades de los reos
sean ‘PER’ y ordenando los datos alfabéticamente por el apellido paterno del
Reo.

10.6.3. CTE - Reo Por Planta

El siguiente script es una tabla de expresión secuencial donde la primera

capturamos el nombre, los apellidos, el id de la celda y la planta (piso) en la
que se encuentra, en esta ocasión seleccionamos solo la primera planta. Para
la siguiente tabla de expresión se hizo lo mismo que el anterior pero
seleccionando solo los de la segunda planta obteniendo como resultado solo
los reos de la primera y segunda planta.

43
10.6.4. CTE - Duración Visita

Esta tabla CTE nos permitirá obtener el tiempo durante el cual una visita
permaneció en el centro penitenciario, esto podrá ser muy relevante en un futuro por
si es que sucedieron problemas o para revelar posibles actos ilícitos.

10.7. Creación de Triggers y Stored Procedure

10.7.1. Triggers

a) Trigger

Este trigger nos ayuda a poder eliminar la información de un Reo de toda la

base de datos, este procedimiento estará reservado sólo para algunas
personas debido a que podría conllevar a la pérdida de datos importantes

44
 b) Trigger

Este trigger resulta útil para ubicar a un reo en una celda dentro del centro
penitenciario. Este disparador se activará después de la operación de
inserción de datos. Se verifica que la celda que será asignada al reo no
supere el límite de 4 reos. Si se cumple ello, el reo es ingresado en otra celda
que no supere los 4 reos, con sus datos idReo e idCelda.

10.7.2. Stored Procedures

a) Stored Procedures

Este procedimiento nos ayudará a poder calcular los meses de condena que
aún le quedan a un preso, para ello haremos uso de el código como dato de
entrada y como dato de salida tendremos los meses que le faltan de condena
al preso.

45
b) Stored Procedures

En este procedimiento se hará el cálculo de las personas que fueron

liberadas en un determinado año, como dato de entrada hará uso una fecha
que el usuario ingrese.

46
11. Conclusiones

● La creación del plan de mantenimiento conforman las tareas que van a velar
por asegurar que los activos de una organización mantengan los niveles de
funcionamiento y uso para los que fueron adquiridos. Esto es realmente
importante debido a que su implementación en un ambiente real puede
ayudarnos a que los tiempos de carga mejoren mucho, prevenir pérdidas de
datos, etc. Esta herramienta brindada por SQL Sever fue usada por primera
vez en el grupo ya que la BD originalmente fue realizada en MySQL.
Creemos como grupo que esta herramienta es de mucha utilidad y aún más
el poder hacer uso de esta de forma gráfica.

● El uso del análisis del plan de ejecución nos ayudó a poder optimizar las
consultas, sin embargo esto no fue lo único, ya que también se utilizaron
recomendaciones que se dieron durante las clases del curso. Como equipo
consideramos que esta herramienta sumada a las recomendaciones
brindadas durante clases son muy importantes y aplicables en un ámbito
profesional, ya que en estos tiempos se hace la búsqueda de cada vez mayor
rapidez con el costo mínimo.

● Tener un correcto modelo lógico de la base de datos es una ayuda al

momento de implementar una base de datos en el DBMS, debido a que
tenemos una referencia con respecto a las entidades y relaciones entre ellas.
Asimismo nos da la opción de a lo largo del proyecto realizar actualizaciones
con el fin de encontrar algunos fallos o cosas que se pueden mejorar, para
poder aplicar esas mejoras del modelo a la base de datos creada.

● Los temas vistos a lo largo del curso serán fundamentales de cara al futuro,
para poder implementar estos conocimientos ya sea en la base de datos
creada para el proyecto o para futuros proyectos con el objetivo de poder
tener mejoras y facilidades cuando hagamos la creación de dichas Bases de
Datos.

47
12. Recomendaciones

● Para usar los planes de mantenimiento debemos de usar herramientas que

sean compatibles con estas, como lo es SQL Server, si los lectores se
encuentran usando herramientas como MySQL se les recomienda migrar a
SQL Server para acceder al uso de los planes de mantenimiento.

● Para diseñar una base de datos organizada y optimizada, se recomienda

hacer uso de programas o softwares para el modelamiento de datos. Esto
ayudará a un negocio u organización a desarrollar e implementar una
estrategia de datos, cumplir los requisitos y el objetivo de la base de datos y
garantizar la inserción de datos correctos.

● Si Ud. (por su cuenta o con un equipo de trabajo) desea realizar una base de
datos y son consideradas un gran número de entidades, recomendamos que
organice sus datos y tablas aplicando la Normalización. Ello le facilitará la
creación de consultas que involucren distintas tablas, así como las
optimizaciones de consultas que lo requieran. Esto fue aplicado en el
presente trabajo y ayudó considerablemente al equipo para consultar datos
de las diferentes tablas e interpretar los datos de estas de una manera
sencilla.

● Se recomienda encarecidamente si es que se desea crear una base de datos

haciendo uso del DBMS SQL Server o busca saber que diferencia a este del
actual DBMS con el que trabaja, buscar información primero en la
documentación oficial de SQL Server brindada por Microsoft, luego puede
consultar en canales de youTube como el de hdeleon.net. Estos dos recursos
y otros más fueron de mucha ayuda para el desarrollo de este trabajo, ya que
originalmente esta base de datos fue realizada en MySQL y la tuvimos que
migrar a SQL Server de forma manual.

48
13. Referencias

● Microsoft Docs. (2022, 28 enero). Database-Level Roles - SQL Server.

Recuperado 11 de agosto de 2022, de
https://docs.microsoft.com/en-us/sql/relational-databases/security/authenticati
on-access/database-level-roles?view=sql-server-ver16#fixed-database-roles.

● Microsoft Docs. (2022, junio 11). Usar el Asistente para planes de

mantenimiento - SQL Server. Recuperado 11 de agosto de 2022, de
https://docs.microsoft.com/es-es/sql/relational-databases/maintenance-plans/
use-the-maintenance-plan-wizard?view=sql-server-ver16

● W. (2022, 27 julio). Subqueries (SQL Server) - SQL Server. Microsoft Docs.

https://docs.microsoft.com/en-us/sql/relational-databases/performance/subqu
eries?view=sql-server-ver16

● M. (2022a, mayo 28). Aggregate Functions (Transact-SQL) - SQL Server.

Microsoft Docs.
https://docs.microsoft.com/en-us/sql/t-sql/functions/aggregate-functions-trans
act-sql?view=sql-server-ver16

● R. (2022b, mayo 28). Variables (Transact-SQL) - SQL Server. Microsoft Docs.

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/variables-transa
ct-sql?view=sql-server-ver16

● Ariely, R. (2020, 18 agosto). SQL Server Execution Plan shows cost of more
than 100 percentage. Recuperado el 11 de agosto del 2022 de
https://ariely.info/Blog/tabid/83/EntryId/272/SQL-Server-Execution-Plan-shows
-cost-of-more-than-100-percentage.aspx

49