BASE DE DATOS DE :

CRUZ JIMIENEZ JONATHANDORANTES GUZMÁN GRECIA

MONSERRATOROZCO RAMIREZ NADIA ELENASALAZAR ARGUELLES AARÓN

ING.SISTEMAS COMPUTACIONALES.

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.

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.

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.

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á.

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.

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.

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.

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.

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.

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.

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).

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.

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

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

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.

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.

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.

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.

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. Enterradores2. Jardineros3. 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.

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.

CREATE DATABASE panteonmunicipal;USE panteonmunicipal;CREATE TABLE Familiar (nombre varchar(20) not null,apellidos varchar (40) not null,teléfono DECIMAL (10),dirección varchar (40) not null,id_familia DECIMAL (3),CONSTRAINT pk_fPRIMARY KEY (id_familia)); CREATE TABLE Enterrador (nombre varchar (20)not null,apellidos varchar (30) not null,dirección varchar(40) not null,teléfono DECIMAL (10),telefono_movil DECIMAL (10),antigüedad varchar(15)not null,salario DECIMAL(10),dni_enterrador DECIMAL (3),CONSTRAINT pk_ePRIMARY KEY (dni_enterrador));

CREATE TABLE Administrativo ( nombre varchar(20) not null,apellidos varchar (30)not null,direccion varchar(40) not null,telefono DECIMAL (10),telefono_movil DECIMAL (10),antiguedad varchar(15)not null,salario DECIMAL(10),id_administrativo DECIMAL(3),dni_enterrador DECIMAL (3),CONSTRAINT pk_aPRIMARY KEY (id_administrativo),CONSTRAINT fk_entFOREIGN KEY (dni_enterrador)REFERENCES Enterrador (dni_enterrador));  CREATE TABLE Sector (nombre varchar(20)not null,id_sector DECIMAL(3),Superficie DECIMAL(10),capacidad DECIMAL (10),CONSTRAINT pk_sPRIMARY KEY(id_sector),CONSTRAINT ck_capCHECK (capacidad >=0)); 

CREATE TABLE Jardinero ( nombre varchar(20) not null,apellidos varchar (30)not null,direccion varchar(40) not null,telefono DECIMAL (10),telefono_movil DECIMAL(10),antiguedad varchar(15)not null,salario DECIMAL(10),id_sector DECIMAL (3),dni_jardinero DECIMAL(3),CONSTRAINT fk_secFOREIGN KEY (id_sector)REFERENCES Sector (id_sector),CONSTRAINT ck_salCHECK (salario>=0)); CREATE TABLE Tumba (id_tumba DECIMAL(3),tipo varchar (10) not null,id_sector DECIMAL (3),CONSTRAINT pk_tPRIMARY KEY(id_tumba),CONSTRAINT fk_sectFOREIGN KEY (id_sector)REFERENCES Sector (id_sector));

CREATE TABLE Nicho (altura DECIMAL (10),id_nicho DECIMAL (3),od_nicho long,CONSTRAINT ck_altCHECK (altura>=0)); CREATE TABLE FosaComun (id_fosa DECIMAL (3),capacidad DECIMAL (10),CONSTRAINT pk_fPRIMARY KEY(id_fosa),CONSTRAINT ck_capdCHECK (capacidad>=0)); CREATE TABLE panteon (id_panteon DECIMAL (3),id_familia DECIMAL (3),capacidad DECIMAL (10),od_panteon long,CONSTRAINT pk_pPRIMARY KEY (id_panteon),CONSTRAINT fk_fmFOREIGN KEY(id_familia)REFERENCES Familia (id_familia),CONSTRAINT ck_capddCHECK (capacidad>=0)); 

CREATE TABLE Factura ( cantidad DECIMAL(10),fecha_factura DATE not null,id_factura DECIMAL (3),id_familia DECIMAL (3),id_administrativo DECIMAL (3),CONSTRAINT fk_fmlFOREIGN KEY(id_familia)REFERENCES Familia(id_familia),CONSTRAINT fk_admiFOREIGN KEY(id_administrativo)REFERENCESAdministrativo(id_administrativo),CONSTRAINT ck_canCHECK (cantidad>0));

CREATE TABLE Fallecido (nombre varchar (20) not null,apellidos varchar (30) not null,fecha_nacimiento DATE not null,fecha_muerte DATE not null,dni_enterrador DECIMAL (3),id_familia DECIMAL(3),id_tumba DECIMAL (3),id_fosa DECIMAL(3),id_panteon DECIMAL(3),CONSTRAINT fk_entrFOREIGN KEY (dni_enterrador)REFERENCES Enterrador(dni_enterrador),CONSTRAINT fk_fmaFOREIGN KEY (id_familia)REFERENCES Familia(id_familia),CONSTRAINT fk_tmFOREIGN KEY(id_tumba)REFERENCES Tumba(id_tumba),CONSTRAINT fk_fsFOREIGN KEY (id_fosa)REFERENCES FosaComun(id_fosa),CONSTRAINT fk_pantFOREIGN KEY(id_panteon)REFERENCES Panteon(id_panteon));

/inicamos con la base de datos master

use mastergo /creamos la base de datos create database panteonmunicipal /creamos un archivo de respaldo en docuemnto por si se borra on primary(name=panteon_dat,filename='C:\Aaron Arguelles\

panteon.mdf',size= 30mb,maxsize=60mb,filegrowth= 4mb/tope maximo)golong on( name=panteon_dat,filename='C:\Aaron Arguelles\

panteon.mdf',size= 30mb,maxsize=60mb,filegrowth= 4mb)go

create table Familia (id_familia INT IDENTITY(1,1)PRIMARY KEY,nombre varchar(20) not null,apellidos varchar (40) not null,telefono INT (10),direccion varchar (40) not null)create table Enterrador(nombre varchar (20)not null,apellidos varchar (30) not null,direccion varchar(40) not null,telefono INT (10),telefono_movil INT (10),antiguedad varchar(15)not null,salario INT(10),dni_enterrador INT IDENTITY(3)PRIMATY KEY)create table Administrativo(nombre varchar(20) not null,apellidos varchar (30)not null,direccion varchar(40) not null,telefono INT (10),telefono_movil INT (10),antiguedad varchar(15)not null,salario INT(10),id_administrativo INT IDENTITY(3)PRIMARY KEY,dni_enterrador INT (3)not null)

---RESTRICCIONES---ALTER TABLE AdministrativoADD CONSTRAINT fk_entFOREIGN KEY (dni_enterrador)REFERENCES Enterrador (dni_enterrador) create table Sector(nombre varchar(20)not null,id_sector INT IDENTITY(3)PRIMARY KEY,Superficie INT(10)not null,capacidad INT (10)not null) create table Jardinero (nombre varchar(20) not null,apellidos varchar (30)not null,direccion varchar(40) not null,telefono INT(10),telefono_movil INT(10),antiguedad varchar(15)not null,salario INT(10),id_sector INT (3)not null,dni_jardinero INT IDENTITY(3)PRIMARY

KEY) 

---RESTRICCIONES---ALTER TABLE JardineroADD CONSTRAINT fk_secFOREIGN KEY (id_sector)REFERENCES Sector (id_sector) create table Tumba(id_tumba INT IDENTITY(3)PRIMARY KEY,tipo varchar (10) not null,id_sector INT (3)) ---RESTRICCIONES---ALTER TABLE TumbaADD CONSTRAINT fk_scFOREIGN KEY (id_sector)REFERENCES Sector (id_sector) create table Panteon(id_panteon INT INDENTITY (3)PRIMARY

KEY,id_familia INT (1,1),capacidad INT (10),od_panteon long)

---RESTRICCIONES---ALTER TABLE PanteonADD CONSTRAINT fk_famFOREIGN KEY (id_familia)REFERENCES Familia (id_familia) create table Factura(cantidad INT(10),fecha_factura DATE not null,id_factura INT IDENTITY(3)PRIMARY KEY,id_familia INT (1,1),id_administrativo INT (3)) ---RESTRICCIONES---ALTER TABLE FacturaADD CONSTRAINT fk_fmFOREIGN KEY (id_familia)REFERENCES Familia (id_familia),ALTER TABLE FacturaADD CONSTRAINT fk_admiFOREIGN KEY (id_amdiministrativoREFERENCES Administrativo

(id_administrativo) 

create table Fallecido (nombre varchar (20) not null,apellidos varchar (30) not null,fecha_nacimiento DATE not null,fecha_muerte DATE not null,dni_enterrador INT(3),id_familia INT(1,1),id_tumba INT (3),id_panteon INT(3),id_administrativo(3))---RESTRICCIONES---ALTER TABLE FallecidoADD CONSTRAINT fk_fmFOREIGN KEY (id_familia)REFERENCES Familia (id_familia),ALTER TABLE FallecidoADD CONSTRAINT fk_admiFOREIGN KEY (id_administrativoREFERENCES Administrativo (id_administrativo),ALTER TABLE FallecidoADD CONSTRAINT fk_entFOREIGN KEY(dni_enterrador)REFERENCES Enterrador(dni_enterrador),ALTER TABLE FallecidoADD CONSTRAINT fk_tumbFOREIGN KEY(id_tumba)REFERENCES Tumba (id_tumba),ALTER TABLE FallecidoADD CONSTRAINT fk_panFOREIGN KEY(id_panteon)REFERENCES Panteon (id_panteon)

Silva, R. O. (2002). Teorías de la AdministraciónMéxico: Thompson. Francisco Montero, F. J. (2004). El panteón: imagen,tiempo y espacio : proyecto y patrimonio. Sevilla:

PedroCid. Avances en Informática y Sistemas

computacionales(Tomo 1) CONAIS 2006Héctor García MolinaPrimera Edición 2006 por: Universidad Juárez Autónoma de Tabasco.Av. Universidad S/N, Zona de la Cultura,Villahermosa, Tabasco. México