ANÁLISIS Y DISEÑO DE BASES DE DATOS

Ordenanza municipal
reguladora de la
gestión y
funcionamiento de
los mercados de
abastos
GRADO EN ESTADÍSTICA

María Aragón Ruiz

Gonzalo Díaz Amor
Carlos González Duque
Javier Martínez García
Curso 2018/2019
INTRODUCCIÓN
En este informe se expone detalladamente el diseño de una base de datos para la ordenanza
municipal reguladora de la gestión y funcionamiento de los mercados de abastos en el
municipio de Aljaraque y al de Corrales.

Nos ocuparemos también tanto del arrendamiento como de la explotación de los distintos
puestos fijos y almacenes destinados al servicio de mercado de abastos.

Nuestra base de datos se encargará de gestionar la concesión de los puestos pertenecientes a

cada mercado, además de tratar el registro de sanciones y deudas.

Trabajaremos con tres tipos de personas: El personal auxiliar del mercado, el titular de la
concesión y sus empleados. Contamos con dos tipos de locales: el puesto de venta (clasificado
según su denominación) y el almacén correspondiente a cada puesto (en caso de que sea
necesario).

En cuanto al proceso de adjudicación de puestos, la base de datos no es responsable, es decir,

los datos se añadirán a la base de datos una vez hecha la concesión.

No nos encargaremos de los albaranes justificativos de las compras.

Además, hemos tomado la decisión de que los traspasos sean gestionados por un organismo
externo a nuestra base de datos.

Como en los tres puntos anteriores y teniendo en cuenta que no toda la información está bien
especificada, nuestra interpretación de ciertos aspectos ha sido simplificada y supondremos
que estos aspectos serán tratados por organismos externos a nuestra base de datos.
DIAGRAMA ENTIDAD-RELACIÓN

A continuación explicaremos la función de cada una de las entidades que forman el diagrama
entidad-relación.

Persona: Esta entidad representa los distintos tipos de personas que existen en nuestro
planteamiento. Va a tener los siguientes atributos:

-dni: Atributo de tipo String, representa el DNI o NIF de la persona y es el identificador

de esta entidad.

-nombre: Atributo de tipo String, representa el nombre y los apellidos de la persona.

Personal Auxiliar: Esta entidad representa uno de los tipos de persona, se encargan de las
funciones de vigilancia y conservación del buen orden y limpieza del mercado.

-ocupacion: Atributo de tipo enum, representa las distintas ocupaciones que puede
tener el personal auxiliar (especificadas en la ordenanza).

Empleado: Esta entidad representa otro tipo de persona que trabaja para el titular en cada
concesión.

Titular: Entidad que representa el último tipo de persona, es el que realizará la concesión.

-puestosFamiliar: Atributo de tipo entero, que nos indica el número puestos que
tienen los familiares del titular con la misma denominación.

Mercado: Esta entidad representa el mercado formado por un conjunto de locales.

 -idM: Atributo de tipo entero, es identificador de la entidad mercado.

-encargado: Atributo de tipo String, representa la persona responsable de dirigir el

mercado.

Local: Entidad que representa los locales que forman cada mercado.

-idL: Atributo de tipo entero, identificador del local.

-vacío: Atributo de tipo booleano que indica si el local está vacío o no.

Almacén: Entidad que representa un tipo de local utilizado para almacenar y/o conservar.

-frigorífico: Atributo de tipo booleano que indica si el almacén es frigorífico o no.

PuestoVenta: Entidad que representa el lugar físico de los puestos.

Concesión: Entidad que representa un contrato entre un titular y un local.

-idC: Atributo de tipo entero que representa el identificador de la concesión.

-fechaInic: Atributo de tipo Fecha, representa la fecha inicial del contrato.

-fechaFin: Atributo de tipo Fecha, representa la fecha final de la concesión.

-dia: Atributo de tipo bit, representa los días de apertura del puesto.

-denominacion: Atributo de tipo enum, indica cuál de los tipos de denominaciones

vende la concesión (especificados en la ordenanza).

Sanción: Entidad que representa las sanciones que se imponen a una concesión.

-idS: Atributo de tipo entero, identificador de la sanción.

-fechaSancion: Atributo de tipo Fecha, representa la fecha en la que se impone la

sanción.

-gravedad: Atributo de tipo enum que indica la gravedad de la sanción (especificado en

la ordenanza).

-causa: Atributo de tipo enum, que indica el motivo de la sanción. En este enum
tendremos 34 causas, cada una de ellas pertenecientes a un nivel de gravedad
(especificado en la ordenanza).

Deuda: Entidad que representa la deuda que debe la concesión.

-idD: Atributo de tipo entero, identificador de la deuda.

-tipoDeuda: Atributo de tipo String que indica el tipo de deuda que debe la concesión.
(especificado en la ordenanza: agua, luz, gas…)

-cantidadDeuda: Atributo de tipo double que indica la cantidad que debe la concesión.
Tras exponer todas las entidades que forman el diagrama entidad-relación y sus atributos,
vamos a explicar las relaciones que existen entre ellas:

En el esquema superior, se encuentra la herencia que representa los distintos tipos de

persona: personal auxiliar, empleado y titular.

En este caso la relación de herencia es de tipo {mandatory, disjoint}: mandatory indica que
cada persona tiene que ser obligatoriamente de uno de los 3 tipos, es decir, que no puede
existir una persona que no pertenezca a uno de estos grupos. Por otro lado, disjoint indica que
una persona no puede pertenecer a dos tipos a la vez, es decir, que si esta en uno de los tres
grupos no puede estar en otro.

En cuanto a la relación entre empleado y titular, vemos que es de tipo muchos a muchos
(*1..*), es decir, un empleado puede trabajar para 1 o muchos titulares y un titular puede
tener ninguno o muchos empleados bajo su mando.
En el fragmento de diagrama superior está representada la relación entre el personal auxiliar y
el mercado, podemos ver que se trata de una relación muchos a muchos (**), esto quiere
decir que en un mercado pueden estar trabajando muchas o ninguna personas pertenecientes
al grupo de personal auxiliar y viceversa.

En la representación superior, observamos que la relación entre las entidades mercado y local
es 1 a muchos (1*), lo que quiere decir que cada local solo pertenece a un mercado, pero un
mercado está formado por 0, 1 o varios locales.
En la representación anterior observamos la herencia que representa los distintos tipos de
locales: almacén y puesto de venta.

La relación de herencia es de tipo {mandatory, disjoint}: mandatory indica que cada local tiene
que ser obligatoriamente de uno de los 2 tipos, es decir, que no puede existir un local que no
pertenezca a uno de estos grupos. Por otro lado, disjoint indica que un local no puede
pertenecer a dos tipos a la vez, es decir, que si está en un grupo no puede estar en el otro. Por
lo tanto, un local será o almacén o puesto de venta, pero nunca ambos.

La relación entre local y concesión es de 1 o 2 a muchos (1..2*), esto quiere decir, que una
concesión puede ser de 1 o 2 locales, ya que puede ser un almacén y un puesto de venta, y un
local puede ser asignado a ninguna o varias concesiones.
Hemos añadido la restricción de que si una concesión tiene asignados 2 locales, tiene que ser
uno de cada tipo, ya que cada concesión puede tener asignado un puesto de venta, y no
vemos sentido a tener dos almacenes si luego no tienes un puesto de venta.

En cuanto a la relación titular con concesión, vemos que es una relación 1 a muchos (11..*),
un titular puede tener 1 o varias concesiones, mientras que una concesión tiene que
pertenecer a un único titular.

La entidad concesión tiene 3 restricciones: Un supuesto titular solo puede tener dos puestos
con la misma denominación, un puesto sólo puede vender una denominación, y por último, la
concesión y consiguiente ocupación de los puestos tendrá duración máxima permitida de 10
años a contar desde la fecha de su adjudicación. Estas tres restricciones están especificadas en
la ordenanza.
En la representación superior podemos ver la relación entre concesión con sanción y entre
concesión con deuda.

La entidad sanción tiene asociada una restricción que es la siguiente: 3 faltas leves en un año
se corresponden con una falta grave. Reiteración de faltas graves en un periodo menor a un
año se corresponde con una falta muy grave. (Especificado en la ordenanza).

La relación entre concesión y sanción es 1 a muchos (1*), lo que quiere decir que una
concesión puede tener ninguna, 1 o muchas sanciones, mientras que una sanción solo puede
estar a asociada a una única concesión.

La relación entre concesión y deuda es 1 a muchos (1*), lo que indica que una concesión
puede tener ninguna, 1 o muchas deudas, mientras que una deuda solo puede pertenecer a
una concesión.
ESQUEMA RELACIONAL

Titular (dni, puestosFamiliar)

TitularEmpleado(dniT,dniE)

Empleado (dni)

Persona (dni, nombre)

Concesión(idC, fechaInic, fechaFin, día, denominación, dniTitular, idLocal)

PersonalAuxiliar (dni, ocupación)

TrabajoMercado(idMercado, idPersonalAuxiliar)

Mercado (idM, encargado)

Local(idL,vacio, idMercado)

Almacén(idL,frigorifico)

PuestoVenta(idL)

Sanción (idS, fechaSancion, gravedad, causa,idConcesion)

Deuda (idD, tipoDeuda, cantidadDeuda,idConcesion)

Hemos creado las siguientes tablas:

Titular, TitularEmpleado, Empleado, Persona, Concesión, PersonalAuxiliar, TrabajoMercado,

Mercado, Local, Almacén, PuestoVenta, Sanción, Deuda.

Concesión: Esta tabla consta de 7 columnas. La primera de ellas es idC, que representa la clave
primaria y es identificador de esta entidad, por lo tanto no puede ser nulo. El siguiente es
fechaInic que tampoco debe ser nulo, y hace referencia a la fecha en la que empieza nuestra
concesión. La tercera columna es fechaFin que tampoco debe ser nulo, y hace referencia a la
fecha en la que expira nuestra concesión. La cuarta columna de la tabla corresponde al
atributo día, no puede ser nulo, ya que una concesión exige unos días mínimos de apertura.
Continuamos con denominación, que tampoco puede ser nulo puesto que la concesión debe
tener asignado un tipo de venta. Las dos últimas columnas de la tabla son dniTitular que es
clave foránea y hace referencia al titular que tiene la concesión e idLocal que también es clave
foránea y hace referencia al local o locales que el titular tiene en concesión. Las dos últimas
columnas tampoco pueden ser nulas, puesto que son claves foráneas y hacen referencia a
otras entidades.

Deuda: En esta tabla disponemos de 4 columnas. idD se refiere a la identificación (clave

primaria) de la entidad deuda, no puede ser nulo. Después contamos con 3 campos:
idConcesion, tipoDeuda y cantidadDeuda ; los cuales no pueden ser nulos, ya que cuando
tenemos una deuda, necesitamos saber con qué concesión está relacionada; además de la
necesidad de indicar el tipo de deuda que es y la cantidad total a deber.

Sanción: En esta tabla contamos con 5 columnas. La primera de ellas es idS, que representa el
identificador (clave primaria) de la entidad y por tanto no puede ser nulo, las tres siguientes
son fechaSancion, gravedad y causa; que tampoco pueden ser nulas, ya que cuando se
produce una sanción necesitamos saber la fecha en la que se produjo, la causa de ella misma y
su gravedad. Y por último idConcesion, que es clave foránea y representa la relación entre
sanción y concesión, ya que cuando se produce una sanción de cualquier tipo, debemos
relacionarla con una concesión determinada.

Persona: Constará de dos columnas. El campo nombre no va a poder ser nulo, ya que nos
permite saber quién es una persona sea del tipo que sea. En este caso nuestra clave primaria
será el dni, que será el identificador de cada persona.

PersonalAuxiliar: La cual constará de dos columnas. Una de ellas es la ocupación, la cual no va

a poder ser nula, ya que vamos a necesitar saber a qué se dedica: limpieza, seguridad… El otro
campo hará referencia al dni de dicha persona, y el cuál será clave primaria de dicha tabla y
clave foránea que lo va a relacionar con Persona. Por lo tanto, al ser clave primaria y foránea a
la vez, se va a producir una debilidad en identificación de la entidad. Debido a esto, se realizará
un borrado en cascada; es decir, si eliminamos una tupla perteneciente a Persona y que está
también en PersonalAuxiliar, se eliminarán ambas.

Empleado: Esta tabla constará de 1 columna que hará referencia al dni del empleado, y el cual
va a ser clave primaria de esta tabla y foránea que lo va relacionar con Persona. Como ocurría
en el caso anterior, va a ser débil en identificación por lo que también realizaremos un borrado
en cascada.

Titular: Constará de dos campos. El primero será puestosFamiliar, que podrá ser cero, ya que
cuando tenemos un titular puede darse el caso de que este mismo no tenga familiares que
tengan algún puesto de la misma denominación. Por último tenemos el dni, que al igual que
pasaba en los dos casos anteriores, va a ser clave primaria de esta tabla y foránea con Persona,
y por lo tanto también va a ser débil en identificación e implementaremos el borrado en
cascada.

TitularEmpleado: (Chasm trap) En esta tabla contaremos con dos campos, y ambos serán
claves primarias. El primero será dniT, que a su vez será clave foránea de Titular y el segundo
es dniE, que será también clave foránea de Empleado. Esta tabla la creamos para solucionar el
problema que encontramos con la relación *  1..* que hay entre Empleado y Titular. Para
ello tendremos unas relaciones *  1 entre Empleado y TitularEmpleado, así como una
relación *  1 entre TitularEmpleado y Titular. Al ser ambas claves primarias y foráneas,
tendremos un caso de debilidad en identificación, por lo que se implementará el borrado en
cascada.

Mercado: Tendrá dos columnas. La primera será encargado, y no podrá ser nula, ya que
cuando tenemos un Mercado nuevo necesitamos representar a la persona que se encarga de
dirigirlo. La segunda será idM, y que no podrá ser nula, ya que se trata de la clave primaria de
esta clase y por lo tanto es el identificador de esta.

TrabajoMercado: (Fan trap) Esta tabla constará de dos campos. Ambas columnas de esta tabla
además se corresponderán con la clave primaria. Primero tenemos idMercado, que a su vez
será clave foránea de Mercado y después idPersonalAuxiliar, que también será clave foránea
de PersonalAuxiliar. Esta tabla la creamos porque queremos solucionar el problema que
tenemos con la relación *  * que tenemos entre PersonalAuxiliar y Mercado. Para ello,
consideraremos una relación *  1 entre PersonalAuxiliar y TrabajoMercado, ya que el
personal auxiliar sólo puede trabajar en una sección del mercado (que hace referencia a los
distintos tipos de trabajo de un mercado, ya sea limpieza, seguridad…) y cada sección puede
tener trabajando desde 0 a infinito personal auxiliar. Y después otra relación que será *  1
entre TrabajoMercado y Mercado, ya que un mercado podrá tener distintos tipos de trabajo.
Tendremos para ambos casos una debilidad en identificación, por lo que, como hacíamos en
casos anteriores, implementaremos el borrado en cascada.

Local: Tendrá tres columnas. La primera será vacio, y cuando tenemos un local necesitaremos
saber si este se encuentra o no vacío, por lo tanto no podrá ser nula. La segunda hace
referencia al idMercado, que no será nula, y será clave foránea de Mercado, ya que cuando
creamos un Local necesitamos saber el id del Mercado al que pertenece. Por último tenemos
la clave primaria, que será idL y que nos permitirá identificar al Local.

Almacén: Constará de dos columnas. La primera será frigorífico, y no será nula, ya que cuando
tenemos un Almacén necesitamos saber si este contará de cámara frigorífica o no. La segunda
será el idL, que tampoco será nulo y será clave primaria de esta tabla y clave foránea
referenciando a Local. Por lo tanto será débil en identificación de la identidad y vamos a
implementar el borrado en cascada; es decir, cuando una tupla pertenezca a Local y se
encuentre también en Almacén, eliminaremos las dos.

PuestoVenta: En esta tabla únicamente contaremos con un campo. Este será idL, y que como
ocurría en el caso anterior será clave primaria de esta tabla y foránea respecto a Local, y
tendremos el mismo caso de debilidad en identificación y también implementaremos el
borrado en cascada similarmente al caso anterior.
CONSULTAS
-Averiguar el dni de los empleados que trabajan en carnicería.

- Averiguar el nombre de los titulares que tienen una concesión de panadería.

- Averiguar la cantidad de deuda de las concesiones que tiene ‘García’.

- Averiguar el total de deuda de las concesiones que acaben antes de 2021.

- Averiguar el nombre del titular de la concesión con máxima deuda.

ANEXO
REQUISITOS :

Un único fichero (max. 50MB) en formato zip ó 7z, y cuyo nombre sea el grupo al que se
pertenece, por ejemplo G08.7z Este archivo contendrá: (1) la memoria de la práctica en
formato pdf; (2) un script SQL (estándar) que permita construir la base de datos. Más en
detalle, los contenidos de cada uno de ellos serán los siguientes:

(1) Memoria
• Diagrama ER. Esquema final, incluyendo restricciones si las hubiere, y acompañado
de aquellas aclaraciones que se consideren más importantes para poder entender
mejor el esquema presentado
• Esquema relacional. Esquema final, con aquellas aclaraciones que se consideren más
importantes para poder entender mejor el paso ER -> Relacional
• (no evaluable) Enumeración de las consultas implementadas y la relevancia y sentido
que pueden tener a nivel de la aplicación. SQL de cada una de ellas. En el caso de que
alguna consulta tenga un planteamiento complejo o particular, se acompañará una
explicación de dicho planteamiento.
(2) Script
• drop de las tablas
• create de las tablas
• insert de las tuplas (una a una individualmente)
• (no evaluable) select de las consultas que se hayan implementado