El documento presenta la base de datos propuesta para el sistema de administración de un panteón municipal. La base de datos contendrá tablas para registrar información sobre empleados, sectores, tumbas, nichos, fosas comunes y panteones. Se especifican los campos y relaciones entre las tablas para almacenar datos sobre la gestión de entierros, personal y recursos del cementerio.

1. BASE DE DATOS DE :

2.  CRUZ JIMIENEZ JONATHAN
 DORANTES GUZMÁN GRECIA MONSERRAT
 OROZCO RAMIREZ NADIA ELENA
 SALAZAR ARGUELLES AARÓN
ING.SISTEMAS COMPUTACIONALES.

3.  El presente proyecto se origina en la
necesidad actual de la gestión del panteón
municipal, de contar con un sistema de
información computacional integral que
permita lograr una gestión eficiente, eficaz
para brindar información clara y oportuna.

4.  En este sentido el proyecto considera el diseño y
desarrollo de un prototipo de un sistema de
administración electrónica que permita registrar,
clasificar, buscar y recuperar eficientemente la
información crítica y relevante en torno a la gestión de
los cementerios. En este aspecto, el sistema, contará
con una base de datos segura y confiable que permita
reducir los tiempos de almacenamiento, reemplazar el
trabajo físico de administración de archivos e
innecesario de documentos, automatizar los procesos
de trabajo y la generación de documentos entre otras.

5.  El objetivo general de este proyecto es contar
con un sistema de información
computacional integral que permita llevar a
cabo el control de gestión que sustente la
toma de decisiones en forma eficiente, eficaz
y efectiva de las autoridades municipales en
la prestación y gestión de este tipo de
servicio.

6. Para llevar a cabo el objetivo general se desprenden los
siguientes objetivos específicos:
 • Definir el estado, etapa en la cual se reunirá la información
documental necesaria para entregar una base teórica sobre
la cual se basará el siguiente proyecto.
 • Identificar requerimientos de información, de esta manera
se pretende tener un mejor enfoque del problema
contextualizando las necesidades planteadas por el
solicitante del sistema.
 • Diseñar y analizar el sistema, de esta manera se pretende
dar una solución al problema planteado y el cómo se debe
desarrollar.
 • Desarrollar un prototipo del sistema para entregar una
visión preliminar al sistema futuro que se implantará.

7.  QUE ES UN PANTEON
 Panteón es una palabra que tiene su origen en el
vocablo latino Pantheon, tal como se
denominaba al templo que, en la Antigua Roma,
estaba dedicado a todos los dioses. De ahí que,
hoy en día, el concepto se aproveche para
nombrar a un monumento de carácter funerario
donde se entierra a varias personas, aunque
también puede usarse como sinónimo de
cementerio en algunas naciones.

8.  HISTORIA:
Los pueblos antiguos tenían por principio
enterrar los difuntos fuera de las ciudades. Así lo
hicieron también los primeros cristianos que,
perseguidos por mucho tiempo, no pudieron
tener un lugar especial para depositar sus
muertos. Lo que hacían era observar bien el sitio
donde se enterraban los mártires, procurando no
confundir sus reliquias con los huesos de otros.
Las catacumbas no fueron suficientes para
contener los mártires y hubo que buscar otros
lugares para dar sepultura a los cristianos.

9.  El término cementerio (del griego: lugar para
dormir) implica que el terreno está designado
específicamente como terreno para enterrar. Los
cementerios en el mundo occidental son el lugar
en donde las ceremonias finales de la muerte se
observan. Estas ceremonias o ritos varían según la
práctica cultural y creencia religiosa. Alrededor del
siglo VII, el entierro europeo estaba bajo control
de la iglesia y podía ocurrir solamente en el
terreno consagrado de la iglesia.

10. Una organización generalmente posee más
de un tipo de sistemas de información, cada
uno de ellos tiene sus propias características y
cada uno juega un rol fundamental en el logro
de la satisfacción de necesidades de
información de dicha organización.

11.  En general, varios autores están de acuerdo en la existencia de dos
tipos de sistemas de información en cualquier organización, que
son:
 1) Sistema de Información Formal: Basados en un conjunto de
normas, estándares y procesamientos que permiten que la
información se genere y llegue a quien la necesita en el momento
deseado. La información formal puede ser producida por el
computador.
 2) Sistema de Información Informal: Están basados en la
comunicación no formalizada ni predefinida entre las personas de
la organización. Este tipo de sistema no tiene estructuras y no
sigue normas o procesamientos establecidos porque su
información puede ser bastante imprecisa, irregular e incierta,
imposibilitándose así el procesamiento automático.

12.  Un sistema de información tiene un origen (nacimiento),
generalmente ocasionado por necesidades, a partir del
cual se emprende su desarrollo que va desde la definición,
del proyecto hasta la puesta en operación (Crecimiento)
seguidamente se inicia su operación y mantenimiento por
un período mayor a los demás durante el cual alcanza el
máximo rendimiento posible (maduración). Luego,
factores tales como la dinámica de la organización, los
avances tecnológicos y las presiones externas o internas
vuelven obsoleto e ineficaz al sistema (decaimiento), lo
cual origina su paralización (muerte). En este último
período se toma la decisión de renovar el sistema. Lo que
origina un nuevo ciclo de vida, o desecharlo por completo,
lo cual marca su fin definitivo.

13.  Los períodos relevantes del ciclo de vida de
un sistema de información se pueden agrupar
en las siguientes etapas:
 • Surgimiento de necesidades.
 • Desarrollo.
 • Operación y Mantenimiento.
 • Disposición (Renovación o Extinción).

14.  MySQL es un sistema de gestión de bases de datos (SGBD)
multiusuario, multiplataforma y de código abierto. MySQL
pertenece a la compañía sueca MySQL AB, a la que le pertenece
casi todos los derechos del código fuente. La compañía desarrolla
y mantiene el sistema, vendiendo soporte y servicios, como
también las licencias para usar MySQL.
 VERSIONES DE MYSQL
 * 1995 (23 de mayo): MySQL fue lanzado internamente.
 * 1998 (8 de enero): lanzan la primera versión de MySQL para
Windows 95 y NT.
 * 2000 (agosto): lanzan la versión 3.23 beta.
 * 2001 (enero): lanzan la versión 3.23.
 * 2002 (agosto): lanzan la versión 4.0 beta.
 * 2003 (marzo): lanzan la versión 4.0.

15.  Es un sistema de gestión o administración de bases de datos
relacionales, que puede ejecutar muchas tareas simultáneamente
con otras tareas y es accesible a muchos usuarios a la hora de
obtener información que se encuentra almacenada en este gestor
de base de datos.
ENTRE SUS CARACTERÍSTICAS DESTACAN:
 Soporte de transacciones
 Escalabilidad, estabilidad y seguridad
 Soporta procedimientos almacenados
 Entorno gráfico de administración
 Permite trabajar en modo cliente-servidor
 Permite administrar información de otros servidores de datos.
 Licencia privada (Microsoft) e

16.  Firebird es un sistema de administración de base de
datos relacional (o RDBMS) (Lenguaje consultas: SQL)
de código abierto, basado en la versión 6
de Interbase, cuyo código fue liberado
por Borland en 2000. Su código fue reescrito de C a C+
+.
Los objetivos de la Fundación FirebirdSQL son:
 Apoyar y lograr el avance del manejador de base de
datos relacional Firebird
 Proveer los mecanismos e infraestructura no
comerciales para aceptar y administrar los fondos
recaudados, e invertir tales fondos para promover el
esfuerzo del desarrollo de esta base de datos

17.  Oracle es un sistema de gestión de base de
datos objeto-relacional (o ORDBMS por el
acrónimo en inglés de Object-Relational Data
Base Management System), desarrollado
por Oracle Corporation.
Se considera a Oracle como uno de los sistemas de
bases de datos más completos, destacando:
 soporte de transacciones,
 estabilidad,
 escalabilidad y
 Soporte multiplataforma.

18.  Nuestro proyecto del “PANTEON MUNICIPAL” como
es un proyecto transaccional está diseñado para
recolectar, almacenar, modificar y recuperar todo tipo
del información que maneje el panteón. Como
sabemos una transacción es un evento o proceso que
genera o modifica la información que se encuentra
eventualmente almacenado.
 El proyecto al ser transaccional mantendrá la
seguridad y consistencia d ellos datos involucrados.
 Además de que es capaz de controlar y enmendar los
errores que surjan, pudiendo deshacer las operaciones
realizadas, mantenimiento de datos tal cual estaban
antes del error.

19.  El proyecto es capaz de responder rápidamente, la
respuesta no debe ser mayor a un par de segundos.
 Debe ser altamente fiable de lo contrario afectara al
panteón municipal. En caso de fallas debe tener
mecanismos de recuperación y de respaldo de datos.
 * Automatizan tareas operativas en una organización,
permitiendo ahorrar en personal.
 * Suelen dirigirse especialmente al área de ventas,
finanzas, administración y recursos humanos.
 * Suelen ser los primeros sistemas de información que
se implementan en una organización.

22.  Se desea implementar una base de datos para
facilitar la gestión y administración de un
cementerio, en dicha base de datos se
contemplan diferentes categorías laborales,
distintos tipos de enterramiento, facturas por los
servicios prestados, incluso se permite que una
familia posea su propio panteón para un
determinado número de personas.
 El cementerio está dividido en sectores,
teniendo estos una capacidad y extensión
variable que ha de quedar reflejada.

23.  Asimismo se ha quiere tener información sobre los
empleados mediante datos personales como nombre y
apellidos, dirección, teléfono, salario, antigüedad, etc.
 Las categorías en las que se dividen los empleados son:
1. Enterradores
2. Jardineros
3. Administrativos
 Los jardineros se ocuparán del cuidado de los sectores, de
tal forma que un jardinero está al cuidado de un sector,
aunque del cuidado de un sector pueden encargarse varios
jardineros.
 Asimismo, cada sector contendrá un determinado número
de tumbas. Una tumba pertenece a un sector.

27.  SUPUESTO 1: El panteón jardín, entierra un número amplio de difuntos
 SUPUESTO 2: Las tumbas se renuevan cada cierta cantidad de tiempo
para dar paso a otros entierros.
 SUPUESTO 3: Los nichos tienen capacidad para una sola persona.
 SUPUESTO 4: Sin embargo un panteón tiene capacidad para varias
personas siendo lo normal 4, siendo por eso de tipo smallint.
 SUPUESTO 5: Un empleado puede enterrar a uno o más Difuntos.
 SUPUESTO 6: El panteón asigna un código a cada ataúd que maneja lo
que les permite diferenciar cada ataúd.
 SUPUESTO 7: Es importante conocer la fecha de entierro de los ataúdes.
 SUPUESTO 8: Un ataúd almacena un difunto, y una tumba puede
almacenar varios ataúdes.
 SUPUESTO 9: La capacidad de una Fosa Común es superior a la de un
panteón, y es de tipo integer. En este caso y en los dos anteriores
asumimos la indivisibilidad del fallecido.
 SUPUESTO 10: Cada fallecido es enterrado por un único enterrador,
lógicamente el enterrador puede enterrar a más de un fallecido durante
su jornada laboral.

28. CREATE DATABASE panteonmunicipal; CREATE TABLE Administrativo (
USE panteonmunicipal; nombre varchar(20) not null,
CREATE TABLE Familiar ( apellidos varchar (30)not null,
nombre varchar(20) not null, direccion varchar(40) not null,
apellidos varchar (40) not null, telefono DECIMAL (10),
teléfono DECIMAL (10), telefono_movil DECIMAL (10),
dirección varchar (40) not null, antiguedad varchar(15)not null,
id_familia DECIMAL (3), salario DECIMAL(10),
CONSTRAINT pk_f id_administrativo DECIMAL(3),
PRIMARY KEY (id_familia)); dni_enterrador DECIMAL (3),
CONSTRAINT pk_a
CREATE TABLE Enterrador ( PRIMARY KEY (id_administrativo),
nombre varchar (20)not null, CONSTRAINT fk_ent
apellidos varchar (30) not null, FOREIGN KEY (dni_enterrador)
dirección varchar(40) not null, REFERENCES Enterrador (dni_enterrador));
teléfono DECIMAL (10),
telefono_movil DECIMAL (10), CREATE TABLE Sector (
antigüedad varchar(15)not null, nombre varchar(20)not null,
salario DECIMAL(10), id_sector DECIMAL(3),
dni_enterrador DECIMAL (3), Superficie DECIMAL(10),
CONSTRAINT pk_e capacidad DECIMAL (10),
PRIMARY KEY (dni_enterrador)); CONSTRAINT pk_s
PRIMARY KEY(id_sector),
CONSTRAINT ck_cap
CHECK (capacidad >=0));

29. CREATE TABLE Jardinero ( CREATE TABLE Nicho (
nombre varchar(20) not null, altura DECIMAL (10),
apellidos varchar (30)not null, id_nicho DECIMAL (3),
direccion varchar(40) not null, od_nicho long,
telefono DECIMAL (10), CONSTRAINT ck_alt
telefono_movil DECIMAL(10), CHECK (altura>=0));
antiguedad varchar(15)not null,
salario DECIMAL(10), CREATE TABLE FosaComun (
id_sector DECIMAL (3), id_fosa DECIMAL (3),
dni_jardinero DECIMAL(3), capacidad DECIMAL (10),
CONSTRAINT fk_sec CONSTRAINT pk_f
FOREIGN KEY (id_sector) PRIMARY KEY(id_fosa),
REFERENCES Sector (id_sector), CONSTRAINT ck_capd
CONSTRAINT ck_sal CHECK (capacidad>=0));
CHECK (salario>=0));
CREATE TABLE panteon (
CREATE TABLE Tumba ( id_panteon DECIMAL (3),
id_tumba DECIMAL(3), id_familia DECIMAL (3),
tipo varchar (10) not null, capacidad DECIMAL (10),
id_sector DECIMAL (3), od_panteon long,
CONSTRAINT pk_t CONSTRAINT pk_p
PRIMARY KEY(id_tumba), PRIMARY KEY (id_panteon),
CONSTRAINT fk_sect CONSTRAINT fk_fm
FOREIGN KEY (id_sector) FOREIGN KEY(id_familia)
REFERENCES Sector (id_sector)); REFERENCES Familia (id_familia),
CONSTRAINT ck_capdd
CHECK (capacidad>=0));

30. CREATE TABLE Factura ( CREATE TABLE Fallecido (
cantidad DECIMAL(10), nombre varchar (20) not null,
fecha_factura DATE not null, apellidos varchar (30) not null,
fecha_nacimiento DATE not null,
id_factura DECIMAL (3), fecha_muerte DATE not null,
id_familia DECIMAL (3), dni_enterrador DECIMAL (3),
id_administrativo DECIMAL (3), id_familia DECIMAL(3),
CONSTRAINT fk_fml id_tumba DECIMAL (3),
FOREIGN KEY(id_familia) id_fosa DECIMAL(3),
REFERENCES Familia(id_familia), id_panteon DECIMAL(3),
CONSTRAINT fk_admi CONSTRAINT fk_entr
FOREIGN KEY (dni_enterrador)
FOREIGN KEY(id_administrativo) REFERENCES Enterrador(dni_enterrador),
REFERENCES CONSTRAINT fk_fma
Administrativo(id_administrativo), FOREIGN KEY (id_familia)
CONSTRAINT ck_can REFERENCES Familia(id_familia),
CHECK (cantidad>0)); CONSTRAINT fk_tm
FOREIGN KEY(id_tumba)
REFERENCES Tumba(id_tumba),
CONSTRAINT fk_fs
FOREIGN KEY (id_fosa)
REFERENCES FosaComun(id_fosa),
CONSTRAINT fk_pant
FOREIGN KEY(id_panteon)
REFERENCES Panteon(id_panteon));

33. /inicamos con la base de datos master create table Familia (
use master id_familia INT IDENTITY(1,1)PRIMARY KEY,
go nombre varchar(20) not null,
apellidos varchar (40) not null,
/creamos la base de datos telefono INT (10),
create database panteonmunicipal direccion varchar (40) not null
)
/creamos un archivo de respaldo en create table Enterrador(
docuemnto por si se borra nombre varchar (20)not null,
apellidos varchar (30) not null,
on primary( direccion varchar(40) not null,
name=panteon_dat, telefono INT (10),
filename='C:Aaron Arguellespanteon.mdf', telefono_movil INT (10),
size= 30mb, antiguedad varchar(15)not null,
maxsize=60mb, salario INT(10),
filegrowth= 4mb/tope maximo dni_enterrador INT IDENTITY(3)PRIMATY KEY
) )
go create table Administrativo(
long on( nombre varchar(20) not null,
name=panteon_dat, apellidos varchar (30)not null,
filename='C:Aaron Arguellespanteon.mdf', direccion varchar(40) not null,
telefono INT (10),
size= 30mb,
telefono_movil INT (10),
maxsize=60mb,
antiguedad varchar(15)not null,
filegrowth= 4mb salario INT(10),
) id_administrativo INT IDENTITY(3)PRIMARY KEY,
go dni_enterrador INT (3)not null
)

34. ---RESTRICCIONES--- ---RESTRICCIONES---
ALTER TABLE Administrativo ALTER TABLE Jardinero
ADD CONSTRAINT fk_ent ADD CONSTRAINT fk_sec
FOREIGN KEY (dni_enterrador) FOREIGN KEY (id_sector)
REFERENCES Enterrador (dni_enterrador) REFERENCES Sector (id_sector)
create table Sector( create table Tumba(
nombre varchar(20)not null, id_tumba INT IDENTITY(3)PRIMARY KEY,
id_sector INT IDENTITY(3)PRIMARY KEY, tipo varchar (10) not null,
Superficie INT(10)not null, id_sector INT (3)
capacidad INT (10)not null )
)
---RESTRICCIONES---
create table Jardinero ( ALTER TABLE Tumba
nombre varchar(20) not null, ADD CONSTRAINT fk_sc
apellidos varchar (30)not null, FOREIGN KEY (id_sector)
direccion varchar(40) not null, REFERENCES Sector (id_sector)
telefono INT(10),
telefono_movil INT(10), create table Panteon(
antiguedad varchar(15)not null, id_panteon INT INDENTITY (3)PRIMARY KEY,
salario INT(10), id_familia INT (1,1),
id_sector INT (3)not null, capacidad INT (10),
dni_jardinero INT IDENTITY(3)PRIMARY KEY od_panteon long
) )

35. create table Fallecido (
---RESTRICCIONES--- nombre varchar (20) not null,
apellidos varchar (30) not null,
ALTER TABLE Panteon fecha_nacimiento DATE not null,
ADD CONSTRAINT fk_fam fecha_muerte DATE not null,
FOREIGN KEY (id_familia) dni_enterrador INT(3),
REFERENCES Familia (id_familia) id_familia INT(1,1),
id_tumba INT (3),
id_panteon INT(3),
create table Factura( id_administrativo(3)
cantidad INT(10), )
fecha_factura DATE not null, ---RESTRICCIONES---
ALTER TABLE Fallecido
id_factura INT IDENTITY(3)PRIMARY KEY, ADD CONSTRAINT fk_fm
id_familia INT (1,1), FOREIGN KEY (id_familia)
id_administrativo INT (3) REFERENCES Familia (id_familia),
ALTER TABLE Fallecido
) ADD CONSTRAINT fk_admi
FOREIGN KEY (id_administrativo
---RESTRICCIONES--- REFERENCES Administrativo (id_administrativo),
ALTER TABLE Factura ALTER TABLE Fallecido
ADD CONSTRAINT fk_ent
ADD CONSTRAINT fk_fm FOREIGN KEY(dni_enterrador)
FOREIGN KEY (id_familia) REFERENCES Enterrador(dni_enterrador),
REFERENCES Familia (id_familia), ALTER TABLE Fallecido
ALTER TABLE Factura ADD CONSTRAINT fk_tumb
FOREIGN KEY(id_tumba)
ADD CONSTRAINT fk_admi REFERENCES Tumba (id_tumba),
FOREIGN KEY (id_amdiministrativo ALTER TABLE Fallecido
REFERENCES Administrativo (id_administrativo) ADD CONSTRAINT fk_pan
FOREIGN KEY(id_panteon)
REFERENCES Panteon (id_panteon)

36.  Silva, R. O. (2002). Teorías de la Administración
México: Thompson.
 Francisco Montero, F. J. (2004). El panteón: imagen,
tiempo y espacio : proyecto y patrimonio. Sevilla: Pedro
Cid.
 Avances en Informática y Sistemas computacionales
(Tomo 1) CONAIS 2006
Héctor García Molina
Primera Edición 2006 por:
Universidad Juárez Autónoma de Tabasco.
Av. Universidad S/N, Zona de la Cultura,
Villahermosa, Tabasco. México