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, telef�no, salario, antig�edad, etc.
Las categor�as en las que se dividen los empleados son:
- Enterradores
- Jardineros
- 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.
Las Tumbas pueden ser de uno de los siguientes tipos:
- Nicho
- Pante�n
- Fosa Com�n
Es necesario, adem�s, almacenar informaci�n sobre el fallecido, as� como de la persona (familiar) que se har� cargo de los costes del servicio (todo ello, obviamente identificado mediante los datos personales y de inter�s para la empresa).
- Cada fallecido es enterrado por un �nico enterrador,l�gicamente el enterrador puede enterrar a mas de un fallecido durante su jornada laboral.
- Los nichos tienen capacidad para una sola persona.
- Sin embargo un pante�n tiene capacidad para varias personas siendo lo normal 4, siendo por eso de tipo smallint.
- 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.
Adem�s, los administrativos emiten facturas para los familiares, de tal forma que un administrativo puede emitir facturas a varios familiares, y un familiar puede recibir varias facturas.
El �nico tipo de tumba que puede ser propiedad de un familiar es el pante�n, siendo propiedad de una �nica persona, y dicha persona puede poseer varios panteones.
�Construyendo el diagrama E-R
Para realizar el diagrama de entidad-relaci�n hemos de decidir los conjuntos tanto de entidades como de relaciones, atendiendo al enunciado del problema, la estructura del diagrama ha quedado como sigue:
- Entidades:
- Empleado (que constar� a su vez de tres tipos: Jardinero, Enterrador y Administrativo).
- Sector (en los que est� dividido el cementerio).
- Tumba (puede ser de tres tipos: Nicho, Pante�n y Fosa Com�n).
- Fallecido (Representa a la persona muerta mediante los atributos detallados mas tarde).
- Familiar (Es necesario enviar la factura a los familiares del fallecido).
- Relaciones:
- JarSec ( Indica la relaci�n de los jardineros con los sectores del cementerio)
- TumSec (Relaci�n que se da entre las tumbas y los sectores en que est�n ubicadas)
- EnFa (Es la relaci�n que se establece entre los enterradores y los fallecidos).
- Factura (Representa la venta de una tumba a la familia del fallecido).
- NiFa (Indica si el fallecido tiene asignado un Nicho).
- FoFa (Indica si el fallecido se encuentra en una Fosa Com�n).
- PanFa (Indica si el fallecido se encuentra en un Pante�n).
- FamFa (Es la relaci�n establecida entre el fallecido y su familia).
- PaFam (Relaci�n que indica la posesi�n de un pante�n por parte de una familia).
A continuaci�n hablaremos de los pormenores tanto de las entidades como de las relaciones, especificando atributos, tipos de relaciones, cardinalidades y todo aquello que sea interesante destacar.
Comenzamos pues por los atributos propios de cada entidad:
La entidad Familiar tiene 5 atributos:
- Nombre: Nombre del familiar al que se env�a la factura.
- Apellidos: Contiene los apellidos del familiar.
- Telefono: Tel�fono de contacto del familiar.
- Direccion: Almacena la direcci�n (calle, numero, piso, etc).
- ID_Familia: C�digo identificador de un familiar, es la clave primaria de esta tabla.
La entidad Enterrador tiene 8 atributos:
- Nombre: Representar� el nombre del empleado.
- Apellidos: Contienen los apellidos del empleado.
- Direcci�n: Almacena la direcci�n (calle, numero, piso, etc).
- Tel�fono: N�mero de tel�fono de contacto.
- Telef_Movil: N�mero de tel�fono m�vil.
- Antig�edad: A�os de servicio en la empresa.
- Salario: Sueldo en Euros .
- DNI: Contiene el n�mero del DNI, es la clave primaria de esta entidad.
La entidad Administrativo tiene 8 atributos:
- Nombre: Representar� el nombre del empleado.
- Apellidos: Contienen los apellidos del empleado.
- Direcci�n: Almacena la direcci�n (calle, numero, piso, etc).
- Tel�fono: N�mero de tel�fono de contacto.
- Telef_Movil: N�mero de tel�fono m�vil.
- Antig�edad: A�os de servicio en la empresa.
- Salario: Sueldo en Euros .
- DNI: Contiene el n�mero del DNI, es la clave primaria de esta entidad.
La entidad Sector tiene 4 atributos:
- Nombre: Nombre de cada sector o zona del cementerio.
- ID_Sector: C�digo identificador de zona
- Superficie: Extensi�n en m2
- Capacidad: N�mero de fallecidos que puede alojar.
La entidad Jardinero tiene 9 atributos:
- Nombre: Representar� el nombre del empleado.
- Apellidos: Contienen los apellidos del empleado.
- Direcci�n: Almacena la direcci�n (calle, numero, piso, etc).
- Tel�fono: N�mero de tel�fono de contacto.
- Antig�edad: A�os de servicio en la empresa.
- Salario: Sueldo en Euros
- Sector: El sector del cementerio donde trabaja. Clave ajena tomada de Sector.
- DNI: Contiene el n�mero del DNI, es la clave primaria de esta entidad.
La entidad Tumba tiene 4 atributos:
- ID_Tumba: C�digo identificadore de tumba.
- Tipo: Puede ser de tres tipos: Nicho, Pante�n o Fosa Com�n.
- Sector: Sector en que se encuentra la tumba. Clave ajena tomada de Sector.
La entidad Nicho tiene 3 atributos:
- Altura: Altura del nicho
- ID_Nicho: C�digo identificador de nicho. Clave primaria y Clave Ajena tomada de Tumba (ID_Tumba).
- Inscripcion: Texto que figura en el.
La entidad FosaComun tiene 3 atributos:
- ID_Fosa: C�digo identificador de Fosa Com�n. Clave primaria y Clave Ajena tomada de Tumba (ID_Tumba).
- Capacidad: N�mero de fallecidos que puede contener.
La entidad Panteon tiene 4 atributos:
- ID_Panteon: C�digo identificador de panteon. Clave primaria y Clave Ajena tomada de Tumba (ID_Tumba).
- ID_Familia: C�digo identificador de familia Clave ajena tomada de Familiar (ID_Familia).
- Inscripcion: Texto que figura en el.
- Capacidad: N�mero de fallecidos que puede contener.
La entidad Factura tiene 5 atributos:
- Cantidad: Total a pagar por la familia.
- Fecha: Fecha en que se emite la factura.
- Clave_Factura: Clave primaria (Fecha,ID_Familia,ID_Admin).
- ID_Familia: C�digo identificador de familia. Clave ajena tomada de Familiar.
- ID_Admin: C�digo identificador de Administrativo. Clave ajena tomada de Administrativo (DNI).
La entidad Fallecido tiene 7 atributos:
- Nombre: Representar� el nombre del fallecido.
- Apellidos: Contienen los apellidos del fallecido.
- FechaNacimiento: Almacena la fecha de nacimiento del fallecido.
- FechaMuerte: Almacena la fecha de la muerte del fallecido.
- Enterrador: C�digo q identifica al enterrador encargado del entierro. Clave Ajena tomada de Enterrador (DNI).
- ID_Familia: C�digo q identifica a la familia del fallecido. Clave Ajena tomada de Familiar (ID_Familia).
- Tumba: C�digo q identifica la tumba del fallecido. Clave Ajena tomada de Tumba (ID_Tumba).
Para la realizaci�n del esquema Entidad-Relaci�n, hemos utilizado una herramienta para el dise�o de diagramas muy conocida por los usuarios de Linux como es Dia , se puede descargar en su versi�n para Windows 95/98/NT/ME/XP... de 
este web. El �nico inconveniente que hemos observado, es la notaci�n que utiliza para la representaci�n de los atributos, enmarc�ndolos en una elipse.Debido a esto, decidimos representar en el diagrama s�lo los atributos que son clave primaria (para consultar detalles sobre atributos, ver lista anterior)
Por lo que se refiere a la especializaci�n de la entidad Empleado, podemos decir que consta de tres tipos: Jardinero, Enterrador y Administrativo. En cuanto a la ligadura, diremos que se trata de conjuntos de entidades disjuntos cuya ligadura de completitud es de tipo total, posee adem�s un atributo llamado Tipo que identifica cada una de las tres categor�as.
La entidad Tumba tambi�n posee una especializaci�n en la que se diferencian tres tipos de subclases, a saber: Nicho, Pante�n y Fosa Com�n, se trata de entidades disjuntas cuya participaci�n es total, al pasarlo a tablas aparecer� un atributo en la tabla Tumba q identificar� el tipo de Tumba de q se trata.
�Construyendo las tablas
Una vez obtenido el esquema relacional es sencillo pasarlo a tablas. Nos ayudaresmo de PgAccess, una aplicaci�n gr�fica que permite gestionar Postgres de un modo sencillo. M�s adelante comentaremos un poco PgAccess.
En la figura no indicamos campos no nulos ni las claves primarias. De cualquier modo, el resultado es lo bastante claro como para hacernos una idea de la estructura que tendr� la bbdd.
Una vez conseguido este esquema pasamos a plasmarlo a comandos SQL. El resultado se puede observar en este fichero.
�Consultando nuestra Base de Datos
En esta secci�n mostraremos la manera de realizar consultas en la base de datos cementerio mediante unos ejemplos, tomados bien como capturas de Putty para ilustrar la posibilidad de administraci�n remota, bien como salida de pantalla .
Como primer ejemplo pondremos una captura directamente de Putty de una consulta que muestra todos los campos de la tabla Familiar.
A continuaci�n mostramos otra captura tomada tambi�n de Putty en la que se relacionan nombres y apellidos de Familiares y Fallecidos, como puede observarse, es una consulta que afecta a dos tablas relacionadas por el campo ID_Familia.
Un ejemplo de lo laborioso que puede resultar hacer una consulta para conocer el Dni del enterrador que se ocup� de un fallecido llamado Restituto
cementerio=# select Fallecido.Nombre, Fallecido.Apellidos, Enterrador.Dni cementerio-# From Fallecido INNER JOIN Enterrador cementerio-# ON Fallecido.Enterrador = Enterrador.Dni cementerio-# WHERE Fallecido.Nombre = 'Restituto'; nombre | apellidos | dni -----------+----------------+---------- Restituto | Gracia de Dios | 10657493 (1 row)
Ejemplo que muestra la salida de una consulta para listar el nombre de aquellos enterradores cuyo sueldo sea superior a 1600 Euros
cementerio=# select Nombre, Apellidos, Salario cementerio-# FROM Enterrador cementerio-# WHERE Salario > 1600; nombre | apellidos | salario ---------+-------------------+--------- Marc | P�rez | 1800.00 Gonzalo | Gonz�lez Gonz�lez | 1900.00 Luis | Ant� Bajo | 1750.00 Frutos | Rojo del Bosque | 1869.25 (4 rows)
Veamos ahora el uso de Alias para las columnas, mientras que en SQL es sufiente con ponerlo a continuacion del campo o con comilla doble, en PostgreSQL es necesario utilizar as de la siguiente manera:
cementerio=# SELECT Nombre as "Nombre de Pila", Apellidos, cementerio-# Dni as "C�digo Indentificador" FROM Enterrador; Nombre de Pila | apellidos | C�digo Indentificador ----------------+-------------------+----------------------- Ju�n Felipe | Garc�a Sierra | 71659874 Marc | P�rez | 71545545 Jacinto | Rodr�guez L�pez | 10657493 Gonzalo | Gonz�lez Gonz�lez | 71234321 Luis | Ant� Bajo | 9632236 Frutos | Rojo del Bosque | 10653298 (6 rows)
�Consideraciones finales
En este apartado, trataremos temas como la sem�ntica no reflejada en el dise�o, los controles que se realizan mediante la aplicaci�n de acceso a la base de datos as� como todos aquellos aspectos y consideraciones que no tienen cabida en otros apartados.
�Observaciones
Como puede apreciarse en el esquema, los fallecidos est�n relacionados tanto con Nicho como con Pante�n y Fosa Com�n, esto nos oblig� a crear la tabla Tumba con un campo llamado Tipo que indicar� si la tumba en cuesti�n es Nicho, Pante�n o Fosa Com�n. Este campo resulta muy �til para realizar consultas que necesiten saber el tipo de enterramiento.
No hemos considerado la posibilidad de que una familia pueda ser la propietaria del nicho de su familiar fallecido, dejando esta relaci�n s�lo para los panteones. Obviamente no ha sido por comodidad, pues el trabajo a�adido ser�a �nfimo, sino que lo que nos interesaba era conseguir la mayor variedad posible dentro de unos l�mites razonables.
Adem�s de lo anterior, decidimos que el entierro en fosa com�n no generase una factura, siendo este un servicio gratuito.
Aunque quiz� fuera m�s propio decir esto en el apartado de conclusiones finales y a pesar de que se ha mencionado en varias ocasiones,hemos de hacer hincapi� en la forma de trabajo conjunta entre las dos m�quinas, una con Linux RedHat 8.0 (donde est� alojada la base de datos y el resto del material del trabajo) y otra con Windows 98 desde donde se pueden realizar las tareas necesarias para administrar la base de datos y trabajar en la documentaci�n (haciendo alg�n que otro malabarismo).
�Sem�ntica no reflejada
Como puede apreciarse viendo tanto el modelo de Entidad-Relaci�n como el diagrama de tablas, pueden darse casos un tanto extra�os como que a dos fallecidos se les asigne el mismo nicho. Tambi�n se puede exceder la capacidad tanto de Panteones como de Fosas Comunes, no obstante estos problemas son controlados mediante software por la aplicaci�n en Python pycemen, as� nos aseguramos de que un nicho s�lo pueda estar ocupado por un fallecido, que un pante�n pueda contener como m�ximo a 6 (pueden ser menos) personas as� como que una fosa com�n albergue un m�ximo de 200 personas (pueden ser menos).
As�mismo se observa que los fallecidos pueden pasar indistintamente a un Nicho, Fosa Com�n o Pante�n, sin que aparentemente haya una raz�n para decidir mas all� de las econ�micas o de cualquier otro tipo.