Un modelo de datos es un lenguaje enfocado en describir una base de datos. Permite describir elementos de la realidad que intervienen en un problema dado (requisitos) y la forma en la que se relacionan entre sí.

La fase de diseño es un paso esencial tanto en el desarrollo de software como en el desarrollo de bases de datos. EL lenguaje de modelado más extendido es el lenguaje UML (Unified Modeling Language).

Los pasos del diseño de una Base de Datos se pueden resumir en:

• Recolección y análisis de requisitos: En este paso recogemos información del sistema para el que debemos diseñar la Base de Datos.

• Diseño conceptual: Una vez recogidos todos los requisitos y conocido el problema, realizamos un primer esquema conceptual en algún lenguaje de alto nivel como es el Modelo Entidad-Relación

• Diseño lógico: El diseño conceptual debe ser ahora transformado en un diseño lógico, que es la transformación de un modelo conceptual a un modelo de datos concreto con el fin de poder representar el problema, más adelante, en algún software concreto. En nuestro caso usaremos el Modelo Relacional.

• Diseño físico: En este punto debemos aplicar el modelo lógico de datos del punto anterior sobre un SGBD concreto. Dependiendo del diseño físico escogido, tendremos un abanico de posibilidades en cuanto al software disponible. En nuestro caso hemos optado por un modelo relacional por lo que tendremos que escoger entre los SGBD relacionales disponibles. En este curso será Access y MySQL.

Es un modelo de datos que representa la realidad a través de entidades , que son objetos que existen y se distinguen de otros por sus características, que llamamos atributos. Además, estas entidades podrán o no estar relacionadas unas con otras a través de lo que se conoce como relación. Hay que tener en cuenta que se trata solamente de un modelo de representación, por lo que no tiene correspondencia real con ningún sistema de almacenamiento.

Se utiliza en la etapa de Análisis y Diseño de una Base de Datos a partir de la toma de requisitos, por lo que habrá que convertirla a otro modelo antes de poder empezar a trabajar con ella.

Consta principalmente de dos pasos:

1. Se elabora el diagrama con las entidades y las relaciones entre ellas.
2. Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.

Las herramientas de modelado son un tipo de software enfocado en la creación de modelos y diagramas. En nuestro caso utilizaremos la herramienta yED Graph Editor por el hecho de ser de libre uso. Permite la creación de multitus de tipos de diagramas.

Una entidad es un objeto que existe en una realidad que queremos representar, por ejemplo, un alumno, que se distingue de otro por sus características como pueden ser: el nombre, los apellidos, el número de expediente, . . .

Las entidades se representan por el siguiente símbolo: Esas características que hacen que unas entidades se distingan de otras, son los atributos. El nombre, los apellidos y el número de expediente serían atributos de la entidad alumno. Los atributos se representan por el siguiente símbolo: A su vez, podemos relacionar unas entidades con otras a través de lo que se conoce como relación. Por ejemplo, dos entidades alumno y asignatura podrían estar relacionadas entre sí puesto que un alumno cursa una asignatura (o varias). Conviene resaltar que una relación entre dos entidades no expresa obligatoriedad de relación sino posibilidad de relacionarse.

En este caso, no será necesario que todos los alumnos cursen una asignatura o que una asignatura sea cursada por todos los alumnos para que la relación se establezca. Por tanto, en este caso se establece que entre esas dos entidades existe una relación a la que podríamos llamar cursa. Las relaciones se representan por el siguiente símbolo:

Si consideramos que dos entidades A y B están relacionadas a través de una relación R, deberemos determinar lo que se conoce como cardinalidades de la relación, que determina cuantas entidades de tipo A se relacionan, como máximo, con cuantas entidades de tipo B. Además, resulta conveniente, en cada caso, calcular cuántas entidades de tipo A se relacionan, cómo mínimo, con cuantas entidades de tipo B (que normalmente será 0 ó 1). De esa manera podremos indicar la obligatoriedad o no de relación entre elementos de las entidades A y B.

Para evitar las dificultades que supone el la transformación a tablas (Modelo Relacional) de algunos aspecto del Modelo Entidad/Relación Extendido como las agregaciones, trataremos de plantear siempre relaciones en las que participen como máximo dos entidades (Relaciones binarias). Es decir, trataremos en la medida de lo posible evitar relaciones ternarias:

Relación binaria y ternaria

En esta relación una entidad de tipo A sólo se puede relacionar con una entidad de tipo B, y viceversa. Por ejemplo, si suponemos dos entidades Curso y Aula, relacionadas a través de una relación Se Imparte, podremos suponer que un Curso se imparte en una Aula y en una Aula sólo se puede impartir un Curso. Se representaría como sigue:

Indica que una entidad de tipo A se puede relacionar con un número indeterminado de entidades de tipo B, pero a su vez una entidad de tipo B sólo puede relacionarse con una entidad de tipo A. Si suponemos una entidad Propietario y otra entidad Vehículo relacionadas a través de una relación Posee, podremos suponer que un Propietario puede poseer varios Vehículos, mientras que cada Vehículo sólo puede pertenecer a un Propietario.

Quedaría representado de la siguiente manera:

Significa que una entidad de tipo A sólo puede relacionarse con una entidad de tipo B, pero una entidad de tipo B puede relacionarse con un número indeterminado de entidades de tipo A. En realidad se trata como una relación uno a muchos pero el sentido de la relación es el inverso.

En este caso, tanto las entidades de tipo A y B, pueden relacionarse con un número indeterminado de entidades del otro tipo. Por ejemplo, si suponemos las entidades Alumno y Asignatura y una relación Cursa, podremos suponer que un Alumno cursa varias asignaturas mientras que una Asignatura la cursan varios Alumnos. Quedaría representado de la siguiente manera:

Son las cardinalidades que nos indican con cuantos elementos de una entidad participan los elementos de la otra entidad, cómo mínimo y como máximo. Cada entidad tiene su cardinalidad parcial, y a partir de ambas se obtiene la cardinalidad completa de la relación. Se separan mediante , y se encierran entre parentesis.

Es una cardinalidad que nos hace ver rápidamente la participación de dos entidades en una relación. La cardinalidad de la relación se indica dentro del símbolo de la relación o debajo de la relación. Se obtiene a partir de los máximos de las cardinalidades parciales de la relación:

Se indica en mayúsculas y separada por :

Existen situaciones en las que a la hora de modelar ciertos requisitos, nos encontramos con que hay ciertos datos que debe almacenar la base de datos que no son características realmente propias de ninguna de las entidades que conforman una relación. En esos caso es probable que dichas propiedades pertenezcan a la relación en sí.

Ejemplo: Un alumno puede cursar varias veces la misma asignatura por lo que debemos almacenar el año en que la cursa.

También es posible representar otro tipo de relaciones entre objetos de nuestro sistema. La relación de herencia, representada como un triángulo (ver figura), expresa que un objeto es un subtipo de otro objeto. También se suele considerar al subtipo como una especialización del primero o al primero como una generalización del segundo.

En el caso del ejemplo, existen dos tipos de empleados que se relacionan de forma diferente con otros objetos del sistema, pero que a su vez pueden tener gran parte en común. Por ejemplo, trabajan de forma diferente pero muchos de los datos personales que almacenaremos de ambos son comunes. Es por eso que el objeto Empleado se puede considerar una generalización de los dos tipos de trabajadores que hay en el sistema. Todos aquellos atributos y relaciones que tengan en común serán atributos y funcionalidades del objeto Empleado y los atributos y relaciones que tengan como trabajadores especializados(Encargados o repartidores) serán representados en la correspondiente entidad.

Es posible que la misma entidad ocupe ambos lados de una relación. En ese caso estamos frente a lo que se conoce como relaciones reflexivas. La cardinalidad de la relación indicará si todos los elementos de la relación están relacionados reflexivamente o bien sólo algunos están relacionados entre sí. En el caso de la figura podríamos suponer una empresa en la que algunos empleados hacen de supervisor de otros empleados.

Los atributos multivaluados son aquellos atributos que pueden contener una cantidad indeterminada de valores.

Los atributos estructurados o compuestos son aquellos atributos que pueden estar compuestos por otros atributos. Normalmente son atributos que pueden descomponerse aunque dependiendo del contexto de la aplicación puede no interesar hacer esa descomposición y tratarlo como un atributo simple.

Los atributos derivados (o calculados) son aquellos atributos cuyo valor puede ser deducido realizando algunas operaciones con otros atributos de la misma entidad o de otras entidades. En algunas situaciones se podría considerar redundante (puesto que su valor se puede deducir) pero en otras puede resultar cómodo almacenarlo ya calculado puesto que se puede ahorrar mucho tiempo de cómputo si se trata de un valor de díficil y/o recurrente cálculo.

Se conoce como Diagrama Entidad/Relación (E/R) al diagrama resultante de modelar un mundo real siguiendo el modelo Entidad/Relación. Como resultado, se modelan todas las entidades con sus atributos, así como todas las relaciones existentes entre ellas, junto con sus cardinalidades.

1. Resulta cómodo que las entidades estén escritas en minúscula para hacer todas estas comprobaciones
2. Comprobar que nuestro diagrama no se ha convertido en un diagrama de flujo y no describe procesos, sino almacenes de datos
3. Comprobar que las Entidades son nombres de cosas y las relaciones son verbos
4. Comprobar que ninguna Entidad tiene como atributo algo que existe como Entidad (si ocurre, se deberían relacionar ambas Entidades)
5. Comprobar que varias entidades no comparten un mismo atributo estructurado que pueda ser considerado realmente como una Entidad
6. Evitar los ciclos (si aparece alguno, que puede ocurrir, comprobar que es necesario)
7. Si una relación tiene varios atributos, valorar si es posible que realmente deba ser una nueva Entidad (Comprar → Pedido, Alquilar → Alquiler, Reservar → Reserva, Enviar → Envío, . . .)
8. Comprobar que no hay colocada ninguna cardinalidad al revés: Se tiene que poder leer: un Usuario Realiza de 0 a N Pedidos. Usuario y Pedido son entidades y Realizar la relación entre ambas. En este caso, (0, N) debería estar escrito en el lado Pedido para que pudiera leerse correctamente

Aunque hasta ahora nos hemos referido a este tipo de modelo como Entidad/Relación, en sus inicios este lenguaje de modelado planteaba algunas limitaciones por lo que se añadieron una serie de características nuevas al modelo. Es lo que se conoce el modelo E/R Extendido o Ampliado.

Algunas de estas características ya se han tratado en los puntos anteriores:

• Cardinalidades en las relaciones
• Atributos en las relaciones
• Herencias

Pero hay otro elementos que no se han nombrado ya que no son obligatorios para realizar un modelo conceptual completo, y en mi experiencia, generan más dificultades a la hora de estudiar los requisitos de un problema real y desarrollar el modelado. Por ejemplo:

• Entidades fuertes y débiles
• Dependencias por existencia e identidad
• Agregaciones

Como se ha indicado, omitir estos elementos del lenguaje de modelado a la hora de realizar el diseño, no afecta al buén diseño conceptual, lógico ni físico de una base de datos.

• Diseñar un modelo Entidad/Relacion (entidades, atributos y relaciones)

• Diseñar un modelo Entidad/Relación (ciclos y redundancia]

• Diseñar un modelo Entidad/Relación (atributos multivaluados, compuestos y derivados)

El modelo relacional es otro modelo de representación en el que los datos y sus relaciones se representan a través de tablas, y en el que los atributos se traducen en campos de esas tablas. Es el modelo de representación que siguen la gran mayoría de los SGBD relacionales (MySQL, SQL Server, Oracle, Ms Access, entre otros) en la actualidad, puesto que es el modelo de datos más extendido.

Así, es necesario transformar nuestro modelo Entidad/Relación a un modelo relacional si queremos crear nuestra Base de Datos en algún SGBD relacional.

Representa la información mediante tablas organizadas en filas llamadas registros y en columnas llamadas campos los cuales albergan un dato concreto.

En la práctica no es necesario dibujar una tabla completa, sino que se suele indicar el nombre de los campos, y los campos claves que conforman las relaciones:

Trabajo (#codigo, nombre, posicion, salario)

Asignatura (#id, nombre, n_horas, -id_profesor) 
Profesor (#id, dni, nombre, apellidos, departamento)

Cuando tenemos un diseño lógico organizado en tablas y campos, establecemos las relaciones estableciendo referencias entre columnas de dos tablas. Los sistemas SGBD Relacionales hacen hincapie en el concepto de Integridad Referencial de los datos almacenados.

La Integridad Referencial consiste en mantener las relaciones entre los registros de diferentes tablas de forma consistente e inequívoca, de forma que siempre podamos conocer qué datos de una tabla están relacionados con otro dato de otra tabla.

Para mantener esta integridad de los datos es necesario es uso de dos tipos de campos clave dentro de las tablas: Claves primarias y Claves ajenas o foráneas.

Toda tabla que contenga registros que queramos relacionar con registros de otras tablas, debe contener al menos un campo cuyos valores son únicos para cada registro de dicha tabla. Por ejemplo, el valor de un dni o un identificador autonumérico, son campos que no se repiten para una tabla de Personas.

Denominamos Clave Primaria, en inglés Primary Key (PK), al campo identificador principal de una tabla. La elección del campo que hará de clave primaria corre nuestra, pero es habitual crear un campo id autonumérico para tal fin por motivos de simplicidad.

Toda tabla cuyos registros tengan relación con los registros de otra tabla, debe tener un campo cuyos valores identifiquen a los registros de otra tabla. A este campo se le conoce como Clave Ajena o Foránea, en inglés Foreign Key (FK). Contiene los valores de la clave primaria de los registros de la tabla con la que se relaciona.

Aparte, es habitual que esta tabla también tengo un campo Clave Primaria.

La tabla Propietario tiene un campo (id) que actúa como clave primaria(PK) de la tabla. No puede haber dos registros con el mismo valor (id). La tabla Vehiculo tiene un campo(id) que actúa como clave primaria de la tabla. Además la tabla Vehículo tiene un campo (id_propietario) que actúa como clave ajena(FK), y referencia cada uno de sus registros con un registro concreto de la tabla Propietario.

De este modo podemos saber quién es el propietario de cada vehículo. Como se trata de una relación 1:N un propietario puede tener varios Vehículos, pero cada vehículo solo puede tener un propietario.

Se suele llamar de este modo a todos los campos que identifican a cada registro de forma inequívoca, es decir, campos que almacenan valores que no se pueden repetir en más de un resgistro de una misma tabla.

En las imágenes del ejemplo anterior, el campo (matricula) de la tabla Vehículo, es un campo único por lo que se considera una clave secundaria. También podríamos tener un campo (dni) para la tabla Propietario que actuaría como clave secundaria.

El paso de un modelo E/R a un modelo relacional se puede llevar a cabo, en gran parte, siguiendo una serie de reglas o pautas, que se enumeran a continuación:

Entidades y atributos:

• Toda entidad se transforma en una tabla.
• Todo atributo simple o derivado se transforma en columna de una tabla.
• Los atributos estructurados transforman los campos en los que se componen en nuevas columnas de la tabla.
• El identificador único de la entidad se convierte en clave primaria. Siempre que pueda, añadiré un campo id como clave primaria.
• Los atributos multivaluados generan una nueva tabla con tres columnas: un id, el id de la tabla de la que surgen propagado como clave ajena y el valor del campo multivaluado.

  (#id, -id_tabla_origen, atributo_multivaluado)

Relaciones:

• Toda relación N:M se transforma en una tabla que tendrá como clave primaria la concatenación de los atributos clave de las entidades que relaciona. Cada uno de los dos campos será clave ajena.

Ejemplo: Un producto puede estar en varios pedidos, y un pedido puede tener varios productos.

Tablas pedidos, productos y pedido_producto

pedidos(#id, descripcion, fecha)
productos(#id, nombre, descripcion, precio_sin_iva, tipo, codigo_producto)
pedido_producto(#(-id_pedido, -id_producto), precio)

* Para casos particulares de relación N:M en el que una cardinalidad parcial mínima y máxima coincida (2,2), (3,3), valoraré transformarlo siguiendo el planteamiento de relación 1:N.

• En las relaciones 1:N se propaga la clave primaria (habitualmente el campo id) de la entidad que tiene de cardinalidad máxima 1 a la que tiene cardinalidad máxima N, convirtiéndose en clave ajena y haciendo desaparecer a la relación.

Ejemplo: Un pedido es realizado por un solo cliente, y un cliente puede realizar multiples pedidos.

Tablas pedidos y clientes

pedidos(#id, precio, fecha, -id_cliente)
clientes(#id, nombre, apellidos, direccion, telefono, num_pedidos)

• En la transformación de relaciones 1:1 se tienen en cuenta las cardinalidades de las entidades que participan en ellas. Existen también diferentes soluciones:
  1. La transfomación tradicional consiste en que una de las tablas tenga una clave primaria que al mismo tiempo es clave ajena de la otra tabla. Solo se puede plantear si alguna de las cardinalidades parciales es (1,1). En ese caso se propaga la clave primaria de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1), en la que será clave primaria y ajena al mismo tiempo. Si ambas cardinalidades parciales son (1,1), no importa hacia qué lado se propaga. (Ejemplo 1)
  2. Otra solución más sencilla es transformarla como si fuera una relación 1:N. Si existe una entidad con cardinalidad parcial (0,1), su tabla tendrá una columna nueva que sería la clave primaria de la otra entidad propagada como clave ajena. Si las cardinalidades parciales son iguales da igual hacia qué tabla se propague la clave primaria. Si usamos esta opción, al crear las tablas en el SGBD, la clave ajena debe ser una columna indexada sin repeticiones (UNIQUE). (Ejemplo 2)
  3. Transformarlo en una tabla. Es un caso muy específico y solo se aplica cuando ambas entidades poseen cardinalidades parciales (0,1) y si solo unos pocos registros de ambas tablas están relacionados. La relación se convierte en una tabla de la misma forma que una relación N:M.

Ejemplo: Un empleado solo puede tener un despacho, y un despacho pertenece a un solo empleado.

Tablas empleados y despachos (Ejemplo 1)

-- Ejemplo 1: Clave primaria y ajena al mismo tiempo
 
empleados(#id, nombre, apellidos, direccion, dni, telefono)
despachos(#(-id_despacho), cod_despacho, direccion, superficie)
 
-- Ejemplo 2: Clave primaria y ajena diferente (como 1:N)
 
empleados(#id, nombre, apellidos, direccion, dni, telefono)
despachos(#id, cod_despacho, direccion, superficie, -id_empleado)

• Las relaciones de herencia se transforman como relaciones 1:1 entre tablas padres e hijas. Aplicando las reglas anteriores, se ha de crear una tabla por cada entidad hija con sus propias columnas.
  1. Para relacionarlas, la forma más directa es propagar la clave primaria de la tabla padre como claves ajenas en las tablas hijas; Las tablas hijas tienen como clave primaria el campo clave de la tabla padre (Ejemplo 1).
  2. La otra forma, menos común, es transfomarla como si fueran dos relaciones 1:N: las tablas hijas tienen su propia clave primaria (id), y añadirán una columna nueva que es la clave primaria de la entidad padre, propagada como clave ajena. En este caso, al crear las tablas hijas en el SGBD, las claves ajenas deben tener ser columnas indexadas sin repeticiones/duplicados (UNIQUE) y sin valores nulos (NOT NULL, o la propiedad requerido en Access). (Ejemplo 2).

Ejemplo: Una pista puede ser una pista_abierta o una pista_cerrada.

Tablas pistas, pistas_abiertas y pistas_cerradas

-- Ejemplo 1: Claves primarias y ajenas al mismo tiempo
 
pistas(#id, nombre, tipo, superficie)
pistas_abiertas(#(-id_pista), fecha_inscripcion, fecha_alta)
pistas_cerradas(#(-id_pista), razon_cierre, fecha_apertura)
 
-- Ejemplo 2: Claves primarias y ajenas diferentes (-id_pista es UNIQUE y NOT NULL)
 
pistas(#id, nombre, tipo, superficie)
pistas_abiertas(#id, fecha_inscripcion, fecha_alta, -id_pista)
pistas_cerradas(#id, razon_cierre, fecha_apertura, -id_pista)

• Las relaciones reflexivas, se transforman antendiendo a su cardinalidad del mismo modo que hemos planteado en los casos anteriores:
  • Si la cardinalidad es N:M, se crea una tabla nueva como el caso general de relación N:M. La clave primaria se compone de dos columnas que referencian al mismo id de la propia tabla.
  • Si la cardinalidad es 1:N, se transforma como si se tratara de una relación 1:N, se propaga la clave primaria a la misma tabla como clave ajena.
  • Si la cardinalidad es 1:1, al tratarse de la misma tabla, se transforma como si se tratara de una relación 1:N. En este caso, al crear la tabla en el SGBD la columna clave ajena no permitirá valores repetidos (indexada sin repeticiones, ó UNIQUE).

Un empleado puede supervisar a varios empleados

-- Relacion 1:N y 1:1
empleados(#id, nombre, apellidos, dni, -id_empleado_supervisor)
 
-- Relación N:M
empleados(#id, nombre, apellidos, dni)
empleados_supervisores(#(-id_empleado_supervisor, -id_empleado_supervisado))

• Para los atributos de las relaciones existen dos casos:
  • Si la relación es 1:N, sus atributos se propagan a la tabla de lado N, junto con la clave del lado 1
  • Si la relación es N:M, sus atributos se transforman en columnas de la tabla generada por dicha relación
  • Las relaciones 1:1 no deberían de tener atributos, ya que en principio deben pertenecer a alguna de las dos entidades.

• Transformar relaciones 1 a 1 al modelo relacional

• Transformar relaciones N a M al modelo relacional

• Transformar relaciones 1 a N al modelo relacional

• Tranformar una herencia al modelo relacional

• Transformar relaciones reflexivas al modelo relacional

• Transformar atributos al modelo relacional

• Ejemplo completo de diseño y transformación de modelo Entidad/Relación a modelo relacional

• Transformar un modelo Entidad/Relación a modelo relacional

Uno de los retos en el diseño de toda Base de Datos es el obtener una estructura estable tal que:

• El sistema no sufra de anomalías de almacenamiento
• El modelo lógico pueda modificarse si aparecen nuevos requisitos

Una Base de Datos bien diseñada tiene mayor esperanza de vida, incluso en un ambiente dinámico donde puedan aparecer nuevos requisitos, que una Base de Datos con un diseño pobre. Como media, una Base de Datos puede sufrir una reorganización cada seis años, dependiendo de lo dinámico que sean sus requisitos. Si la Base de Datos se diseño bien seguirán teniendo un buen rendimiento aunque aumente el tamaño, y será lo suficientemente flexible para soportar los nuevos requisitos y/o características adicionales.

Actualmente existen diversos riegos en el diseño de Bases de Datos relacionales. Los más habituales son la redundancia de información, la inconsistencia de datos y el no aprovechamiento de espacio en disco.

La normalización es el proceso de simplificar la relación entre los campos de un registro de forma que éste se reemplaza por varios registros más simples y predecibles y, por tanto, más manejables. En definitiva, la normalización busca simplificar el diseño para que éste sea más fácil incorporar nuevas funcionalidades con el paso del tiempo y no baje su rendimiento cuando la cantidad de datos almacenados en ella aumenten considerablemente.

La teoría de la normalización se basa en lo que se conoce como Formas Normales. Cada una de estas Formas Normales establece una serie de restricciones que el diseño deberá cumplir para satisfacer dicha Forma. Se considera que una base de datos que cumple las tres primeras FN (Formas Normales) tiene un nivel suficiente de normalización.

Se dice que una tabla está en primera forma normal si una tabla posee las siguientes propiedades:

• Cada columna tiene un solo valor y un solo tipo de datos
• El orden de las filas y las columnas no importa
• Dos filas no contienen valores idénticos
• Las columnas no pueden contener valores repetidos o que representan lo mismo

Supongamos el caso más común, que un campo pueda tener más de un valor:

Es similar al caso de tablas que poseen columnas con valores repetidos (una tabla de clientes con los campos teléfono 1, teléfono 2, teléfono 3, . . .):

En el caso anterior, hay columnas con valores nulos (vacias) y si hay una gran cantidad de registros la definición de la tabla ocupará mucho espacio en desuso. Del mismo modo tendremos problemas a la hora de realizar consultas del tipo: ¿Cual es el teléfono2 de los clientes?, ¿Cuantos números de teléfono tiene el usuario 123?, ó ¿Que usuarios tienen el mismo número de teléfono?.

De cualquier modo estás tablas no cumplen la 1FN. Para normalizar debemos crear una tabla nueva para los teléfonos:

• Se localizan los atributos correspondientes a la clave principal.
• Cada una de las columnas o valores repetidos se separan en una nueva tabla, de manera que se hace la proyección de la clave primaria de la tabla de la que proceden sobre cada uno de los valores del atributo que no es atómico.

Esta formal normal sólo debe ser considerada para aquellas tablas en las que la clave principal sea compuesta. Si no fuera así, la tabla estaría, de forma directa, en segunda forma normal.

Decimos que una tabla está en segunda forma normal si se cumplen las siguientes condiciones:

• Está en 1FN
• Todo atributo secundario (que no pertenezca a la clave principal) tiene una dependencia funcional total de la clave principal, y no de una parte de ella

Se dice un atributo B depende funcionalmente de A (A→B) si cada valor de A se corresponde con un único valor de B. Visto de otra manera, si dado A puedo obtener B. Un caso típico podría ser DNI → Nombre, puesto que dado un DNI puedo obtener, de forma unívoca, el nombre de la persona

Para convertir una tabla que no está en 2FN se creará una tabla con la clave y todas sus dependencias funcionales totales y otra tabla con la parte de la clave que tiene dependencias con los atributos secundarios.

En el ejemplo podemos ver como el campo TelefonoProveedor no depende totalmente de la clave (NombreProducto, NombreProveedor), sino únicamente del campo NombreProveedor.

Clave primaria (NombreProducto, NombreProveedor). Existen dependencias funcionales

Elimino los atributos que depende de una parte de la clave primaria

Los junto en una tabla propia

Se dice que una tabla está en tercera forma normal si:

• Está en 2FN
• No existen atributos no primarios (que no pertenezcan a la clave) que son transitivamente dependientes de cada posible clave de la tabla. Es decir, un atributo secundario sólo puede ser conocido a través de la clave principal y no por medio de un atributo no primario.

Para convertir una tabla que no está en 3FN se realizará una proyección de la clave a los elementos que no tengan dependencia funcional transitiva y otra tabla con una nueva clave a los elementos que anteriormente tenían esta dependencia.

En el ejemplo, es posible conocer la edad del inscrito a través del número de licencia, y dada la edad podemos conocer su categoría, tenemos una dependencia funcional transitiva entre categoría y número de licencia. Lo importante es reconocer que la categoría depende de un atributo que no forma parte de la clave. Para normalizar, debemos descomponer esa tabla en las tablas Atletas y Categorías

Tabla con dependencias transitivas (categoría → edad)

Tabla Atletas

Tabla categorías

La desnormalización es el proceso de procurar optimizar el funcionamiento de una base de datos por medio de agregar datos redundantes. Este proceso surge de la necesidad de mejorar el rendimiento de una base de datos a la hora de realizar consultas demasiado costosas, por ejemplo consultas de unión de varias tablas para obtener datos relacionados.

Un método es mantener normalizado el diseño lógico, pero indicar al SGBD que almacene en el disco información redundante para optimizar la respuesta a la consulta, o añadir datos redundantes en una tabla, y mantenerlos actualizados mediante el uso de disparadores. De este modo podrían acceder a datos relacionados desde la misma tabla sin necesidad de hacer consultas de unión de tablas.

Un modelo de datos desnormalizado no es lo mismo que un modelo de datos que no ha sido normalizado, y la desnormalización debe tomar lugar solamente después de que haya ocurrido un nivel satisfactorio de normalización.

1. Se quiere diseñar una Base de Datos para almacenar todos los datos de un campeonato de fútbol sala que se organiza este año en la ciudad. Aquellos que quieran participar deberán formar un equipo (nombre, patrocinador, color de la 1ª camiseta, color de la 2ª camiseta, categoría, . . .) e inscribirse en el campeonato. A medida que transcurran los partidos se irán almacenando los resultados de éstos, así como qué equipos lo jugaron, en qué campo se jugó, quién lo arbitró y alguna incidencia que pudiera haber ocurrido (en caso de que no ocurran incidencias no se anotará nada. Además, los participantes deberán rellenar una ficha de suscripción con algunos datos personales (nombre, apellidos, edad, dirección, teléfono, . . .)
   
   
2. Se quiere diseñar una Base de Datos para controlar el acceso a las pistas deportivas de León. Se tendrán en cuenta los siguientes supuestos:
   • Todo aquel que quiera hacer uso de las instalaciones tendrá que registrarse y proporcionar su nombre, apellidos, email, teléfono, dni y fecha de nacimiento
   • Hay varios polideportivos en la ciudad, identificados por nombre, dirección, extensión (en m²)
   • En cada polideportivo hay varias pistas de diferentes deportes. De cada pista guardaremos un código que la identifica, el tipo de pista (tenis, fútbol, pádel, . . .), si está operativa o en mantenimiento, el precio y la última vez que se reservó.
   • Cada vez que un usuario registrado quiera utilizar una pista tendrá que realizar una reserva previa a través de la web que el ayuntamiento ha creado. De cada reserva queremos registrar la fecha en la que se reserva la pista, la fecha en la que se usará y el precio. Hay que tener en cuenta que todos los jugadores que vayan a hacer uso de la pista deberán estar registrados en el sistema y serán vinculados con la reserva, pero la reserva solo la realizará un usuario.
     
     
3. Se desea diseñar una Base de Datos para una sucursal bancaria que contenga información sobre los clientes (nombre, apellidos, dni, fecha de nacimiento), las cuentas (tipo de cuenta, numero, interés, balance), las sucursales (código, dirección [calle, número, piso], localidad, provincia) y las transacciones producidas entre sus cuentas (transferencias de dinero de una cuenta a otra). Construir el modelo E/R teniendo en cuenta las siguientes restricciones:
   • Una transacción viene determinada por su número de transacción, la fecha y la cantidad, e intervienen siempre dos cuentas.
   • Un cliente puede tener muchas cuentas.
   • Una cuenta puede tener muchos clientes.
   • Una cuenta sólo puede estar en una sucursal.
   • Dado que una cuenta puede pertenecer a varios usuarios, necesitamos saber también el usuario ordenante de la transacción.
     
     
4. Diseña el modelo E/R para una biblioteca con las siguientes restricciones:
   • Se quiere almacenar información sobre los libros de los que se dispone: titulo, editorial, número de páginas y un resumen breve)
   • Se almacenará información sobre los autores: nombre, apellidos, fecha de nacimiento, fecha de fallecimiento, nacionalidad y un breve resumen de su vida
   • De todos aquellos que se hagan socios de esta biblioteca se les hará una ficha con los siguientes datos: nombre, apellidos, fecha de nacimiento, dirección, teléfono y e-mail
   • Por último, se quiere almacenar todos los libros que cogen prestados los socios para saber quién tiene un determinado libro en cada momento y para conocer que lectores han leído (tenido) alguna vez un libro determinado. Será interesante saber si un libro está actualmente en prestamo, desde cuándo se ha prestado, cuándo se devuelve, y el tiempo permitido de prestamo.
     
     
5. Diseña el modelo E/R para la Base de Datos de una aplicación para la gestión de la secretaría de un colegio:
   • Cuando un alumno venga a matricularse se le hará rellenar una ficha con sus datos que luego se introducirá a la aplicación: DNI, número de expediente, nombre, apellidos, domicilio, teléfono y e-mail
   • Se tendrá ya almacenada información sobre todos los cursos que se imparten en el centro: un código, el nombre, aula donde se imparte y el horario
   • Se almacenarán todas las asignaturas de todos los cursos con el fin de conocer en que asignaturas se matricula cada alumno. De cada una guardaremos el nombre, el profesor que la imparte y el número de horas a la semana. Hay que tener en cuenta que todos los alumnos se matricularán al menos de una asignatura en algún curso
   • Los profesores también están dentro de la Base de Datos, con la siguiente información: nombre, apellidos, domicilio y e-mail. Un profesor podrá impartir como máximo 6 asignaturas y deberá impartir al menos una. También habrá que almacenar el curso del que un profesor es tutor, teniendo en cuenta que puede que no sea tutor de ningún curso
   • Hay que tener en cuenta que es importante almacenar las notas que cada alumno tiene en cada asignatura a lo largo del curso en las distintas evaluaciones (3), así como las observaciones que los profesores podrán anotar. Además, al principio de curso los alumnos escogerán con que compañero quieren realizar las prácticas o trabajos (será siempre con el mismo), información que almacenaremos también en la Base de Datos
     
     
6. La Base de Datos COMPAÑÍA se ocupa de los empleados, departamentos y proyectos de una empresa de desarrollo de software, de acuerdo con los siguientes requisitos:
   • La compañía está organizada en departamentos. Cada departamento tiene un nombre único, un número único, una localización y un empleado que lo dirige. Se debe almacenar la fecha en que dicho empleado comenzó a dirigir ese departamento.
   • Cada departamento controla un cierto número de proyectos, cada uno de los cuales tiene un nombre y un número únicos.
   • Se almacena el nombre, número de la Seguridad Social, dirección, salario, sexo y fecha de nacimiento de cada empleado. Todo empleado está asignado a un departamento, pero puede trabajar en varios proyectos que no tienen por que ser del mismo departamento. Nos interesa saber el número de horas que un empleado dedica a cada uno de los proyectos asignados.
   • También se quiere guardar la relación de las cargas familiares de cada empleado para administrar el seguro médico. Almacenaremos el nombre, sexo y fecha de nacimiento de cada una de las cargas familiares y su parentesco con el empleado
     
     
7. Se quiere diseñar una Base de Datos para uno de los hoteles del complejo Gran Scala:
   • En este hotel, los clientes se registran por Internet al solicitar su reserva, que podrá incluir una o varias habitaciones. En cualquier caso la fecha de entrada y salida de todas las habitaciones de una misma reserva será la misma. Además, debido a la exclusividad del hotel, cada habitación dispone de personal propio (uno o varios empleados, dependiendo del tipo de habitación). De los clientes almacenaremos nombre, apellidos, teléfono, email y fecha de nacimiento. Hay que tener en cuenta que nos interesa poder consultar un histórico de todas las reservas que un cliente vaya realizando a lo largo del tiempo, pero en un momento dado un cliente sólo puede tener una reserva vigente.
   • Es importante almacenar tanto la fecha de entrada y salida de cada una de las reservas, asi como las habitaciones que la componen. De cada habitación almacenamos el tipo, precio, extensión y el número de clientes que hasta el momento la han utilizado. Cada habitación tiene asignado un número determinado de empleados, de los que guardamos nombre, apellidos, horario y cargo que desempeñan. Hay que tener en cuenta que cada empleado sólo puede tener asignada una habitación donde trabajar.
   • A la hora de realizar el cobro de los servicios utilizados, será importante almacenar cuando se solicita un uso de los empleados de alguna de sus habitaciones, puesto que tiene un coste por tarea desempeñada. Habrá que anotar una descripción del servicio la fecha y hora en la que se hace uso de sus servicios y el precio del mismo. Asi, todos esos cargos se añadirán al precio de la factura de la propia reserva.
   • Por último, hay que tener en cuenta que las habitaciones tienen un precio pero éstas pueden ser reservadas a precios más bajos dependiendo de la oferta en vigor. Estas ofertas deberán quedar almacenadas y se aplican al precio total del coste de todas las habitaciones de la reserva completa. Por lo tanto el precio total de la reserva dependerá también de la oferta.
     
     
8. Una empresa desea crear un sitio Web de comercio electrónico al que se podrán conectar clientes para realizar sus compras. Se tiene que realizar el diseño de la Base de Datos que soporte la operativa de este sitio Web.
   • Cuando un usuario intenta entrar en este sitio, se le pedirá un login y una contraseña. El sistema comprobará si el usuario tiene cuenta y en caso negativo se le pedirán los siguientes datos de alta: NIF, correo, nombre, dirección, teléfono, login y password. Se comprobará si el usuario ya existía con distinto login para darle un mensaje de error.
   • Una vez el usuario se ha dado de alta o ha entrado con su login y password correctos, puede visitar las distintas secciones de la tienda virtual. Nuestra empresa quiere que quede constancia de las secciones visitadas por los usuario y la fecha en la que la visitaron. Hay que tener en cuenta que un usuario podrá visitar varias secciones. De cada sección se almacenará un código, nombre, descripción y fecha de creación.
   • Los usuarios pueden realizar sus compras utilizando un carrito virtual. Cuando un usuario decide utilizar el carrito, el sistema creará uno almacenando la fecha de creación. El usuario entonces puede poner productos, detallando cuantas unidades desea o bien eliminarlos. Un carrito puede contener varios productos y un producto puede aparecer en carritos de diferentes usuarios. Solo existe un carrito actual.
   • De los productos se almacenará el código de producto, el nombre, la descripción y el precio por unidad. Cuando un usuario decide finalizar su compra, el sistema le pedirá entonces los datos bancarios (si es la primera vez que paga) y dará el carrito por finalizado. El usuario puede dejar un carrito lleno y no completar la compra en esa sesión, para completarla otro día. El usuario debe poder comprobar cuál es el coste total de un carrito antes de pagarlo. Además podrá comprobar el precio total de todos sus carritos anteriores ya pagados y su contenido.
   • En este sitio Web los productos están organizados en las diferentes secciones teniendo en cuenta que un producto puede aparecer en varias secciones y una sección puede tener varios productos
     
     
9. Se quiere crear una Base de Datos para una inmobiliaria que funciona de la siguiente manera:
   • La inmobiliaria se dedica a la venta o alquiler de inmuebles: pisos, chalets, locales, plazas de garage, . . .
   • Los bienes inmuebles se identifican por un código numérico y su información es la dirección, población, tipo de inmueble, código postal, precio de venta, precio de alquiler, fecha del último movimiento y observaciones. Habrá que tener en cuenta que un mismo inmueble puede estar sólo en alquiler, en venta, o ambas. Además, hay que saber que los precios son aproximados, puesto que el precio por el que realmente se alquile o venta puede ser diferente.
   • Hay varios agentes, que se identifican por su DNI, de los que guardaremos su nombre, dirección, población, teléfono, horario (mañana/tarde), salario base y observaciones.
   • Se almacena información de cada uno de los clientes cuando éstos realizan alguna operación con la oficina, dni, dirección, población, teléfono y email.
   • Todos los movimientos, sean de venta o alquiler, se registran con toda la información necesaria, que habrá de determinarse.
   • Por último, habrá que tener en cuenta que a final de cada mes, los agentes recibirán una comisión, en función de las ventas que hayan realizado dependiendo del tipo de inmueble. Habrá que hacer las modificaciones necesarias en la Base de Datos para poder calcular y almacenar dicha información
     
     
10. Un sitio de juegos online por Internet desea contar con una base de datos para gestionar los usuarios, juegos y partidas que se desarrollan en su plataforma. El funcionamiento del sitio es el siguiente:
    • Cuando un usuario entra en este sitio, se le pide el nombre de usuario y una contraseña. El sistema comprobará si el usuario tiene cuenta y en caso negativo se le pedirán los siguientes datos de alta antes de darle acceso: nombre, email, nick, login y contraseña. Se comprobará si ya existía algún usuario con el mismo nick y login para darle un mensaje de error en ese caso.
    • Una vez el usuario ha iniciado una sesión, puede visitar los distintos salones donde se están disputando las partidas. No se desea que quede constancia de dichos salones en la base de datos. Si un usuario quiere entrar en una partida o crear una nueva tiene que crear un avatar, que será su representación en el mundo virtual. Cada usuario podrá tener diferentes avatares pero cada avatar sólo puede pertenecer a un usuario. De los avatares queremos almacenar el aspecto y el nivel. Éstos se identificarán por el nick del propietario.
    • Hay que tener en cuenta que un avatar solo sirve para un tipo de juego, mientras que en un juego puede haber registrado varios avatares de diferentes usuarios. De los tipos de juego se almacenarán un código, el nombre, una descripción y un texto con las reglas del mismo.
    • Los usuarios podrán crear partidas de ese juego para que otros se unan a la partida, o bien podrán unirse a partidas existentes, siempre utilizando el avatar correspondiente. De cada partida queremos almacenar el código, nombre, una contraseña (opcional), fecha y hora de creación, el estado (en curso o finalizada) y también es necesario conocer el avatar del usuario que la creó. Además, hay que tener en cuenta que una partida sólo puede ser para un tipo de juego, aunque un juego puede tener varias partidas.
    • Las partidas se podrán dejar a medias para continuarlas otro día. Cuando un usuario la crea, puede dar una contraseña de entrada para limitar el acceso. Aquellos usuarios que se unan a las partidas con contraseña quedarán registrados de manera que si quieren abandonarla y unirse más tarde no tengan que volver a introducir dicha contraseña. Nunca se permitirá a los usuarios volver a conectarse a partidas que han finalizado
    • Por último, para obtener las puntuaciones finales, se desean registrar los enfrentamientos que se producen en cada partida entre los diferentes avatares de los usuarios, y el resultado de los mismos
      
      
11. La empresa de comida rápida Burger King, con servicio a domicilio, desea crear una base de datos para gestionar todo su negocio. Actualmente sólo vende hamburguesas, ensaladas y bebidas, aunque también quiere registrar todas las ventas realizadas, así como la actividad de sus empleados.
    • Burger King tiene varios centros de comida rápida distribuidos por toda la comunidad de Aragón y atenderá peticiones en todas las poblaciones. De cada centro se quiere almacenar un código, nombre, dirección, población y un teléfono.
    • Aunque todos los centros pertenecen a Burger King, la empresa da libertad a cada uno para que oferten sus propias hamburguesas y ensaladas. De dichas ofertas se almacena el número, nombre, descripción y precio. Hay que tener en cuenta que una hamburguesa puede ser ofertada por más de un centro.
    • De los clientes a domicilio guardaremos su número, nombre, dirección y teléfono. Además, en cada pedido almacenaremos los productos que se han adquirido así como la fecha del mismo. También es importante, para hacer descuentos, saber la cantidad de pedidos totales por cliente.
    • Respecto a los empleados, hay que almacenar su DNI, nombre, dirección, teléfono y población. La empresa asignará empleados a los diferentes centros según las necesidades de cada uno. Un empleado sólo estará asignado un centro en un momento dado pero puede ser reasignado a otro distinto. Por ello, interesa conocer los centros en los que un empleado determinado ha trabajado y en qué fechas empezó y terminó en cada caso.
    • Además, para analizar sus ventas, se almacena información de todas las poblaciones en las que se ha abierto algún centro: nombre, provincia y número de habitantes. Hay que tener en cuenta que en una misma población podrá haber más de un centro
      
      
12. El Gobierno de Castilla y León quiere mantener una base de datos de las fiestas celebradas en todos los pueblos de la comunidad para el verano de 2020.
    • En particular se quiere almacenar la información referente a los grupos musicales que actúan en cada pueblo, los encierros que se celebran y las peñas de cada municipio. Toda esta información se utilizará para proporcionar ayudas económicas a los municipios que la soliciten.
    • De cada municipio se almacenará el nombre, el número de habitantes, la superficie de su término municipal, el presupuesto de las últimas fiestas y el número de peñas que tiene. De cada grupo musical se mantener el nombre, el año de formación, el precio por actuación y el número de componentes. Hay que tener en cuenta que un grupo puede actuar en varios pueblos en diferentes fiestas y un municipio puede tener la actuación de varios grupos. Por supuesto, un grupo puede repetir actuación en un mismo pueblo. Además, será importante mantener información sobre las fechas en las que ha actuado cada grupo en cada uno de los pueblos.
    • En cuanto a los encierros, se almacenará el pueblo en el que se realizan, la fecha, la ganadería y el número de heridos producidos.
    • Las peñas se definen por el nombre, el número de socios y el año en que se crearon. Hay que tener en cuenta que una peña solo puede pertenecer a un pueblo y un pueblo puede tener varias peñas. También interesa conocer qué peñas colaboran con la celebración de los encierros. Además, es importante conocer el número de heridos de cada peña que se producen en un encierro determinado.
    • Por último, habrá que tener en cuenta que para cada actuación de un grupo musical, es una peña de dicho municipio quién elige dicho grupo
      
      
13. El Ayuntamiento de León quiere implantar un sistema de control para las estaciones de bicicletas públicas que ha instalado recientemente. El objetivo es conocer donde están las bicicletas en cada momento y saber qué usuarios las han usado y cuando lo han hecho. Además, cada bicicleta tiene instalado un módulo de autodiagnóstico que detecta las averías para que éstas quede registradas y puedan ser reparadas por los técnicos del Ayuntamiento.
    • De cada bicicleta se almacenará su matrícula, cuantas marchas tiene, el color, si tiene o no cesta, la velocidad máxima y si está o no averiada.
    • Por otra parte, a los usuarios se les obliga a darse de alta a través de una web, aportando su DNI, nombre, apellidos, email, teléfono móvil y un número de cuenta.
    • Hay que tener en cuenta que habrá muchas estaciones repartidas por la ciudad y que los usuarios deben poder consultar información relativa a éstas desde una página web: el número asignado a la estación, dirección donde se encuentra, si está o no operativa, su capacidad máxima y el horario de apertura de dicha estación.
    • Cuando el módulo de diagnóstico detecta una avería, la envía al servidor central aportando un número de avería, una descripción breve de la misma y la fecha en la que tuvo lugar. Por supuesto, habrá que saber qué bicicleta está averiada. De esa manera los mecánicos del servicio podrán consultar el fichero de averías y repararlas. También es importante que quede guardado qué mecánico arregló una avería determinada (de ellos se guarda su código de empleado, nombre, apellidos y teléfono móvil) teniendo en cuenta que cada uno tiene asignadas dos estaciones de las que hacerse cargo, aunque las bicicletas pueden estar en cualquier estación.
    • Además, es necesario conocer en cada momento qué usuario tiene una bicicleta determinada asi como las bicicletas que han sido utilizadas por los usuarios y durante cuánto tiempo las usaron. En el caso de las averías también tienen que quedar registradas cuál fue el último usuario que usó la bicicleta averiada por si hubiera que multarlo
      
      
14. Como desarrollador de la empresa EventoBook, debes diseñar la Base de Datos de la aplicación estrella de la empresa. Se trata de una red social para que la gente se relacione con sus amigos y con eventos que tienen lugar en su ciudad de forma que puedan consultarlos, apuntarse y ver si sus amigos también van a acudir. Además, podrán opinar sobre ellos y compartir esas opiniones con el resto de los usuarios de esta red.
    • Cada nuevo usuario debe registrarse proporcionando su nombre, apellidos, email, una contraseña y su fecha de nacimiento. Por otro lado, cualquiera puede registrar eventos que podrán ser de dos tipos: deportivos y culturales, indicando en ambos casos nombre, descripción del evento, una URL, la dirección (compuesta de calle, código postal, población y provincia), la fecha de inicio, la fecha de finalización y el precio, si tienen. Además, dependiendo del tipo de evento se almacenarán algunos otros datos. De los eventos deportivos se almacena el deporte y los equipos que se enfrentan (cantidad variable) además de todos los datos anteriores. Si el evento es cultural se añaden el motivo (que tomará los valores música, pintura ó cine) y el nombre del artista que ha motivado dicho evento. En cualquier caso debe quedar constancia del usuario que creó el evento.
    • Los usuarios podrán indicar qué usuarios son conocidos suyos y el motivo (que tomará los valores trabajo, familia o amistad) y asi quedará almacenado. Además, los usuarios se podrán apuntar a los eventos de forma que será necesario conocer qué usuarios van a cada uno de ellos. Tras la celebración del evento el usuario que haya ido podrá dejar (o no) una opinión sobre el mismo donde podrá escribir una opinión libre sobre ese evento, una puntuación (de 1 a 10) y si lo recomendaría o no a sus amigos. Hay que tener en cuenta que las opiniones deben ser anónimas, de forma que no sea posible saber que usuario la ha escrito
      
      
15. Han abierto un centro comercial en Ponferrada y para su gestión se debe diseñar una Base de Datos para almacenar toda la información sobre el mismo. Es el centro comercial más grande del mundo por lo que tendrá varios tipos de establecimientos: tiendas de ropa, restaurantes y museos. De todos ellos se almacenará el nombre, número de local, capacidad máxima y su horario. Además, de las tiendas de ropa se almacenará el tipo de ropa que venden y si están de rebajas o no. Para los restaurantes se almacenará el nombre del chef y el estilo de comida que preparan; y para los museos se almacenará una lista con los pintores que exponen sus obras en cada momento.
    • Además, se almacenará la información de los clientes que asisten a estos establecimientos (si éstos lo autorizan) almacenando el nombre, apellidos, dirección, teléfono y email. También se almacenará en qué establecimientos han hecho alguna compra y la cantidad a la que ésta asciende. Se ofrecerán descuentos a aquellos clientes que vengan recomendados por otros, por lo que es interesante almacenar esta relación.
    • Puesto que también se celebran eventos de todo tipo en el centro comercial (almacenando el nombre del evento, fecha y tipo de evento, que podrá ser deportivo, festivo o cultural), se venderán entradas que los clientes podrán adquirir para asistir a los mismos. De las entradas se guardará la numeración, la fecha de compra, la butaca asignada y el tipo de entrada que podrá ser VIP, PREMIUM o NORMAL. Es importante que quede registrado a qué cliente pertenece cada entrada, ya que son personales
      
      
16. La organización de la vuelta ciclista a España 2021 ha decidido crear una web para seguir el transcurso del evento en directo. Para ello debe diseñar una Base de Datos. Se desea almacenar información de todos los ciclistas (dorsal, nombre, apellidos, fecha de nacimiento, nacionalidad y el equipo al que pertenecen). De cada equipo de la vuelta almacenaremos el nombre, la marca a la que representa, la nacionalidad y el presupuesto. Además, cada equipo tendrá un líder, que será un corredor del equipo.
    • También se quiere almacenar todas las etapas de esta edición, almacenando el número de la etapa, el origen, el destino, la distancia en kms y el tipo de etapa (montaña o contrarreloj). Si la etapa es de montaña además se almacenarán los nombres de los puertos de montaña que atraviesa y la pendiente media de toda la etapa. Si fuera una contrarreloj se añade en que kilómetros intermedios se tomarán tiempos. Una vez terminada cada etapa se almacenará qué corredores han quedado en los tres primeros puestos y el tiempo que les ha costado.
    • Por último, en esta edición de la vuelta se quiere tener registrada cada bicicleta que use cualquier corredor, teniendo en cuenta que un corredor puede usar más de una bicicleta pero que una bicicleta determinada sólo puede haberla usado un corredor. De cada bicicleta almacenaremos la marca, el modelo y el estado (en uso, rota o en reparación) y también es necesario que queden registradas las fechas entre las que el corredor la utilizó en carrera.
      
      
17. Se desea diseñar una base de datos para un centro comercial organizado por departamentos que contenga información sobre los clientes que han comprado algo, los trabajadores, el género que se oferta y las ventas realizadas. Construir el modelo ER y Relacional si:
    • De los clientes queremos almacenar un perfil en el que se incluyen sus datos principales y diferentes intereses.
    • Existen 3 tipos de trabajadores de los que almacenamos nombre y apellidos, dni y fecha de nacimiento. De los gerentes almacenamos también fecha de alta, de los jefes almacenamos sus titulaciones, que pueden ser varias y de los vendedores su bonificación.
    • Cada departamento se identifica por nombre y descripción y está gestionado por un gerente.
    • De cada producto queremos conocer su nombre, codigo de barras y su precio, y solo se localiza en un departamento concreto.
    • Los jefes y vendedores pertenecen a un departamento concreto, el cual queremos conocer.
    • Cada gerente tiene a su cargo varios jefes. Éstos, a su vez, controlan a varios vendedores.
    • Una venta la realiza un vendedor a un cliente. Debe quedar constancia del artículo vendido, la cantidad y la fecha. Cada apunte de venta lo es de un único artículo.
      
      
18. Se pretende llevar a cabo un control sobre la energía eléctrica que se produce y consume en un determinado país. Se parte de la siguiente situación:
    • Existen productores básicos de electricidad que se identifican por un nombre, de los cuales interesa su producción media, producción máxima y fecha de entrada en funcionamiento. Estos productores básicos producen una de las siguientes energías: Hidroeléctrica, Solar, Nuclear o Térmica.
    • De una central hidroeléctrica, interesa saber la ocupación de su presa, capacidad máxima y número de turbinas. De una central solar interesa saber la superficie total de paneles solares, la media anual de horas de sol y el tipo de instalación (Fotovoltaica o termodinámica). De una central nuclear interesa saber el número de reactores que posee, el volumen de plutonio consumido y el de residuos nucleares que produce. De una central térmica interesa saber el número de hornos que posee, el volumen de carbón consumido y el volumen de emisión de gases.
    • Por motivos de seguridad nacional, interesa conocer el plutonio que se provee a una central nuclear. Este control se refiere a la cantidad de plutonio que compra a cada uno de sus posibles suministradores (nombre y país) y que transporta un determinado transportista (nombre y matrícula). Ha de tenerse en cuenta que el mismo suministrador puede vender plutonio a distintas centrales nucleares y que cada pedido, (un único pedido por compra), puede realizarlo un transportista diferente.
    • Cada día, los productores entregan la totalidad energía producida a una o varias estaciones electricas primarias, las cuales pueden recibir diariamente una cantidad distinta de energía de cada uno de esos productores. Las estaciones primarias se identifican por su nombre, y tienen un número de transformadores de baja a alta tensión, una capacidad energética y disponen de una o varias redes cableadas de distribución para suministrar su energía.
    • Una red de distribución se identifica por un número de red, tiene una fecha de inauguración y abarca una superficie, y sólo puede tener una estación primaria como cabecera. La propiedad de una red puede ser compartida por varias compañías eléctricas. A cada compañía eléctrica se la identifica por su nombre, su CIF y también deseamos conocer su sede, capital, y su presidente.
    • La energía sobrante en una de las redes puede enviarse a otra red. Se registra el volumen total de energía intercambiada entre dos redes. Una red está compuesta por una seria de líneas, cada línea se identifica por un número secuencial dentro del número de red y tiene una determinada longitud, y fecha de mantenimiento. La menor de las líneas posibles abastecerá al menos a dos subestaciones.
    • Una subestación es abastecida sólo por una línea y distribuye a una o varias zonas de servicio. A estos efectos, las provincias (código, nombre y población), se encuentran divididas en tales zonas de servicio, aunque no puede haber zonas de servicio que pertenezcan a más de una provincia. Cada zona de servicio puede ser atendida por más de una subestación. En cada zona de servicio se desea registrar el consumo medio y el número de consumidores finales de cada una de las siguientes categorías: particulares, empresas e instituciones.
      
      
19. Se quiere modelar una bbdd de una clínica odontológica. La clínica está compuesta por varios locales de atención, identificados por su nombre, de los cuales se conoce además su dirección, dada por la ciudad donde se ubica, la calle y el número. En cada local existen varias salas de consulta que se identifican por un código dentro del local, una superficie y contiene cierto equipamiento. El equipamiento se identifica globalmente mediante un número de serie, se conoce el tipo(torno, laser, etc.) e interesa mantener registro de la última fecha en que se le realizó mantenimiento.
    • La clínica posee dos planes diferentes de afiliación: individual y grupal. De los afiliados se conoce el dni, el nombre y uno ó más teléfonos. Para los afiliados grupales interesa saber el nombre del convenio de afiliación y el porcentaje de rebaja que se debe aplicar a la cuota mensual. De los afiliados individuales, la fecha de afiliación, la cantidad de consultas realizadas y si viene recomendado por otro afiliado, conocer también el afiliado (del tipo que sea) que lo recomendó.
    • En la clínica se realizan tratamientos, los cuales se identifican por su nombre, duración y tienen un coste asociado. Los odontólogos que trabajan en la clínica se identifican por su nombre, apellidos y dni. De ellos se conoce su especialidad principal dentro de la odontología, las diferentes titulaciones y los diferentes tratamientos que pueden realizar. Los odontólogos trabajan en diferentes locales y cada odontólogo puede tener distintos horarios de atención en cada local. De cada horario de atención se conoce el día de la semana, la hora de comienzo y la hora de finalización. (ej. lunes de 16:00 a 18:30).
    • Los clientes afiliados se someten a intervenciones para algún tratamiento. Debo registrar el Doctor que le trata, la sala en la que se realiza, la fecha de comienzo del tratamiento. Los tratamientos de un paciente pueden llevar varias sesiones o intervenciones, por lo que es interesante conocer cuando se realizan, y cuando acaban. Aunque se realice en diferentes sesiones siempre será el mismo Doctor el que complete el tratamiento. Queremos poder consultar el historial médico de todos los tratamiento o intervenciones del paciente en nuestra clínica.
      
      
20. El club de ajedrez de la universidad ha sido encargado por la federación internacional para la organización de los proximos campeonatos internacionales. Debido a esto, se debe diseñar la base de datos para realizar la gestión del campeonato, participantes, alojamienros, partidas, etc.
    • En el campeonato participan jugadores y árbitros. De ambos se desea conocer el número de asociado, nombre, dirección y telefono. De los jugadores se desea conocer su nivel de juego (1-10) y una descripción del palmarés. De los árbitros la fecha de nacimiento y campeonatos previos en los que han participado. Los árbitros no pueden participar como jugadores, ni viceversa.
    • Los países envían al campeonato un conjunto de participantes (tanto jugadores como árbitros), aunque no todos los paises envían participantes. Además algunos países pueden estar representados por otro pais. Al inscribir un país indicamos su nombre, el número de clubes existentes en el país, y una imagen de la bandera, para incluirla en la web de las clasificaciones.
    • Cada partida se identifica por un código, fecha y hora, y participan siempre 2 jugadores y un árbitro. Es necesario registrar las partidas que juega cada jugador y el color con el que juega. Un árbitro no podrá arbitrar a jugadores proveninetes de su mismo país. Todo jugador participa al menos en una partida. Cada partida se realiza en una jornada, aunque no haya partidas todas las jornadas.
    • Tanto los jugadores como los árbitros, se alojan en alguno de los hoteles en los que se desarrollan las partidas. Es necesario conocer en qué hotel y en que fechas se ha alojado cada participante, pudiendo alojarse en diferentes hoteles, ya que no es necesario que permanezcan en la ciudad los días que no tienen partidas. De los hoteles almacenaremos la dirección, el nombre, el teléfono y el número de salones para jugar partidas.
    • Cada partida se celebra en alguna de las salas de las que disponen los hoteles. Se desea conocer el número de entradas vendidas de la sala para esa partida. De cada sala queremos conocer la capacidad de asistentes, el piso en el que se encuentra, y la cantidad de medios de que dispone (radio, tv, video, streaming, etc) para facilitar la retransmisión.
    • Por último, en la página web del campeonato se podrá hacer un seguimiento del transcurso de cada partida, por lo que necesitamos registrar todos los movimientos realizados en cada una de ellas. Cada movimiento se identificará por un número ascendente dentro de cada partida (movimiento 1, movimiento 2, etc), la jugada en sí (p.e. alfil negro A2) y un comentario realizado por un experto.

© 2024 Santi Faci y Fernando Valdeón