BASES DE DATOS

RELACIONALES

Clase N° 07

09 – NOVIEMBRE - 2022
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Para poder comprender de mejor forma cuáles son los pasos para generar un diagrama de clases, es
que se verá un ejercicio resuelto paso a paso con explicación de cada etapa:

Ejercicio 6: Reserva de vuelos

El sistema de reserva de vuelos es un sistema que permite al usuario hacer consultas y reservas de
vuelos, además de poder comprar los billetes aéreos de forma remota, sin la necesidad de recurrir a un
agente de viajes humano. Se desea que el sistema de reservas sea accesible a través de internet.

El sistema actualmente tiene un Terminal de Servicio de Reserva en donde se presenta un mensaje de

bienvenida describiendo los servicios ofrecidos junto con la opción para registrarse por primera vez, o si
ya se está registrado, poder utilizar el sistema de reserva de vuelos. Este acceso se da por medio de la
inserción de un login previamente especificado (dirección de correo electrónico del usuario) y una
contraseña previamente escogida y que debe validarse.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Una vez registrado el usuario, y después de haberse validado el registro y contraseña del usuario, se
pueden seleccionar las siguientes actividades:
Consulta de vuelos.
Reserva de vuelos.
Compra de billetes.

La consulta de vuelos se puede hacer de tres maneras diferentes:

1. Horarios de Vuelos.
2. Tarifas de Vuelos.
3. Información de Vuelo
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
La consulta según horario muestra los horarios de las diferentes aerolíneas que dan servicio entre dos
ciudades. La consulta según tarifas muestra los diferentes vuelos entre dos ciudades ordenados por su
costo. La información de vuelos se utiliza principalmente para consultar el estado de algún vuelo,
incluyendo información de si existen asientos disponibles y, en el caso de un vuelo para el mismo día, si
este está en hora. Se pueden incluir preferencias en las búsquedas, como fecha y horario deseado,
categoría de asiento, aerolínea deseada y si se desean solo vuelos directos. La reserva de vuelo permite
al cliente hacer una reserva para un vuelo particular, especificando la fecha y horario, bajo una tarifa
establecida. Es posible reservar un itinerario compuesto de múltiples vuelos, para uno o más pasajeros,
además de poder reservar asientos.

La compra permite al cliente, dada una reserva de vuelo previa y una tarjeta de crédito válida, adquirir
los billetes aéreos. Los billetes serán posteriormente enviados al cliente, o estarán listos para ser
recogidos en el mostrador del aeropuerto antes de la salida del primer vuelo. Es necesario estar
previamente registrado con un número de tarjeta de crédito válida para poder hacer compras de
billetes, o bien proveerla en el momento de la compra. Además de los servicios de vuelo, el usuario
podrá en cualquier momento leer, modificar o cancelar su propio registro, todo esto después de haber
sido el usuario validado en el sistema.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Solución

Se presentan los diagramas de clases obtenidos mediante aproximaciones sucesivas. El proceso de

construcción del diagrama de clases implica la realimentación de las soluciones conseguidas tantas
veces como sea necesario, sin implicar por ello mayor o menor capacidad de los analistas.

El primer paso a realizar va a ser la Identificación de Clase. Para ello se subrayan todos los sustantivos en
la descripción del problema, identificándose los siguientes sustantivos, correspondientes a las clases
candidatas (excluyendo repeticiones y manteniendo todo en singular):
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS

El segundo paso que se va a realizar será la Selección de Clases. En este proceso de selección se
eliminan las clases innecesarias, para ello se explicará el desarrollo completo de algunas clases y sus
consideraciones de elección, siendo el resto deducibles de forma inmediata.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
A. Clases redundantes:

Cliente y Usuario “Usuario” puede ser más descriptivo para una aplicación informática. En el caso del
Sistema de Reserva, “Cliente” es más descriptivo y se mantiene. Los sustantivos eliminados se listan a
continuación con los sustantivos preferidos entre paréntesis:

• Consulta de vuelo (consulta).

• Reserva de vuelo (reserva).
• Compra de billete (compra).
• Sistema de reservas de vuelo (sistema de reservas).
• Billete (billete aéreo).
• Costo (tarifa).
• Tarifa de vuelo (tarifa).
• Vuelo directo (vuelo).
• Login (email).
• Horario (hora).
• Fecha (día).
• Dirección de correo electrónico (email)
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
B. Clases irrelevantes: Mostrador del Aeropuerto, Agente de Viajes Humano y Billete Aéreo.

C. Clases imprecisas: Sistema, Servicios, Actividad, Preferencia, Búsqueda, Información, Estado, Opción,
Acceso, Itinerario, son clases imprecisas. Durante la introducción de herencia puede que sea necesario
una clase para compartir aspectos comunes a ambas clases.

D. Nombres de clases: Aeropuerto en lugar de ciudad.

E. Clases que son atributos: Número de Tarjeta de Crédito es un atributo de Tarjeta de Crédito,
Categoría de Asiento (asiento), información de vuelo (vuelo) y horario de vuelo (vuelo).

F. Clases que son operaciones: Consulta, Compra, Reserva.

G. Clases de interfaces de usuario: Mensaje de bienvenida, hoja principal.

H. Clases del sistema completo: Sistema de reserva.

I. Clases actores: Cliente, Operador (opcional, ya que es una ampliación del sistema).
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
A continuación, se lista cuáles son las clases candidatas del sistema a analizar:

Después de haber identificado y seleccionado las clases, se construye un primer diagrama de clases para
el dominio del problema. Como se puede observar, se han eliminado aquellas clases candidatas que son
atributos.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
El siguiente paso que se realiza corresponde a la Identificación de las Relaciones.
Inicialmente se muestran las relaciones básicas existentes entre las diferentes clases del sistema.
Para ello se identifican las siguientes frases:
• Reserva de vuelos.
• Asientos en un vuelo.
• Fecha y horario de vuelo.
• Aerolínea deseada.
• Tarifa de vuelo.
• Itinerario de vuelos.

Se reescriben las frases para así obtener las candidatas:

• El vuelo contiene reservas.
• El vuelo contiene asientos.
• El vuelo tiene día y hora.
• El vuelo pertenece a una aerolínea.
• El vuelo tiene tarifas.
• El vuelo se compone de un itinerario.
• El pasajero tiene reservas.
• El pasajero posee una tarjeta de crédito.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Tras haber identificado y seleccionado las asociaciones, se construye un diagrama de clases con las
asociaciones, los roles y la multiplicidad quedando el diagrama de clases que se muestra en la Figura
Primera aproximación al diagrama de clases.

El Vuelo se denomina por medio de un número, tiene como origen un aeropuerto en una ciudad y tiene
como destino un aeropuerto de otra ciudad. Un vuelo puede tener múltiples escalas y múltiples vuelos,
se relacionan por medio de conexiones. El vuelo pertenece a una aerolínea y puede operar varios días a
la semana teniendo un horario de salida y otro de llegada.

El Aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una
ciudad de un país determinado. Se identifica una clase adicional, como Avión, y las relaciones básicas
existentes entre las clases Aerolínea, Avión, Tarifa, Asiento y Vuelo.

La Aerolínea provee servicio de múltiples vuelos entre diferentes ciudades bajo diferentes horarios. La
aerolínea se identifica por un nombre.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Un vuelo en una fecha determinada se hace en un tipo de avión particular. El tipo de avión define la
cantidad máxima de pasajeros que pueden viajar en ese vuelo para esa fecha.

Los diferentes vuelos tienen múltiples tarifas para compra de billete, variando según la clase de billete,
si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes.

En las reservas de vuelos se puede incluir una solicitud de asignación de asiento, especificando
preferencias como pasillo o ventana. El número de asientos disponibles en un vuelo particular depende
del tipo de avión que opere ese día. En el diagrama de la Figura Segunda aproximación al diagrama de
clases, se muestran las relaciones entre las clases descritas anteriormente.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Otras de las relaciones que se encuentran son las siguientes:

• El horario de un vuelo se define según los días en que opera.

• Para poder tomar un vuelo es necesario contar con una reserva previa, la cual debe pagarse antes de
una fecha límite, que puede ser el propio día del vuelo. Una reserva puede hacerse para múltiples
vuelos y múltiples pasajeros. La reserva cuenta con una clave que identifica un registro de reserva
particular.

• El horario de un vuelo se determina por su hora de salida y hora de llegada durante los días que
opera. Así pues, el diagrama resultante de esta asociación entre la clase Día y Hora se muestra en la
figura a continuación:
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Se identifica una clase adicional llamada Pago, que consta de información sobre la cantidad, fecha y tipo
de transacción. Por razones de seguridad, los pagos de billete se hacen mediante tarjeta de crédito. El
diagrama que muestra las relaciones anteriores es el de la figura a continuación:

Finalmente se identifican los atributos según la descripción del problema. Los atributos de las clases se
han podido obtener antes de proceder a la determinación de las asociaciones, pero en este caso parece
más fácil su representación al final, aunque es obvio que mientras se estaban obteniendo las relaciones
se extraían los atributos.
MODELOS CONCEPTUALES PROPUESTOS PARA
LA MEJORA DE UN MODELO DE DATOS
Así pues, se tienen los siguientes atributos asociados a cada clase:
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 0

Para que un sistema se denomine sistema de gestión de bases de datos relacionales, este sistema debe
utilizar (exclusivamente) sus capacidades relacionales para gestionar la base de datos.

Por ejemplo, esta regla se aplica cuando por medio de la capacidad relacional de la base de datos es
posible realizar búsquedas rápidas y precisas sin redundancia de datos. Agregar un usuario al sistema se
debe efectuar con las mismas herramientas (lenguaje) que son usadas para agregar un registro en la
tabla clientes.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 1: La regla de la información

Toda la información en la base de datos es representada unidireccionalmente, por valores en posiciones

de las columnas dentro de filas de tablas. Toda la información en una base de datos relacional se
representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas.

Ejemplo: Toda la información necesaria para que la base de datos funcione de manera correcta debe ir
en tablas ya que de lo contrario se puede obtener información incompleta carente de significado dentro
de la base de datos.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 2: La regla del acceso garantizado

Todos los datos deben ser accesibles sin ambigüedad. Esta regla es esencialmente una nueva exposición
del requisito fundamental para las llaves primarias. Dice que cada valor escalar individual en la base de
datos debe ser lógicamente direccionable especificando el nombre de la tabla, la columna que lo
contiene y la llave primaria.

Ejemplo: Cualquier dato almacenado debe tener la posibilidad de ser direccionado unívocamente. Para
esto hay que especificar en qué tabla se ubica, cual es la columna y la fila, esto por medio de la clave
primaria.

Un ejemplo de esta regla es al hacer una búsqueda

al interior de la base de datos y obtener como
resultado información repetida junto con
información que no ha sido requerida, esto como
consecuencia de que las claves primarias no se
encuentran apuntando de forma correcta hacia su
tabla o bien hacia los datos que de ella dependen.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 3: Tratamiento sistemático de valores nulos

El sistema de gestión de base de datos debe permitir que haya campos nulos. Debe tener una
representación de la “información que falta y de la información inaplicable” que es sistemática, distinto
de todos los valores regulares.

Ejemplo: Cuando la base de datos no puede manejar la entrada de datos nulos, lo cual podría generar
un error, debido a esto es importante considerar los dominios de todos los campos de cada tabla, así
como verificar la inexistencia del dato requerido. En las operaciones relacionales, hay inconvenientes
para soportar valores nulos, sobre todo en las operaciones lógicas.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 4: Catálogo dinámico en línea basado en el modelo relacional

El sistema debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a los usuarios
autorizados. Es decir, los usuarios autorizados deben tener acceso a la estructura de la base de datos
(catálogo).

Ejemplo:

Utilizar clave para controlar lo que cada usuario puede acceder o realizar dentro de la base de datos y
debe tener acceso en el momento en que lo requiera.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 5: La regla comprensiva del sublenguaje de los datos

Un sistema relacional debe soportar distintos lenguajes y modos de uso de terminal. No obstante, debe
existir al menos un lenguaje cuyas sentencias sean expresables, por medio de una sintaxis bien definida,
como cadenas de caracteres, soportando:

• Definición de datos y vistas

• Manipulación de datos
• Limitantes de integridad y transacción
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 6: Regla de actualización

Todas las vistas que son teóricamente actualizables deben ser actualizables por el sistema.

Ejemplo: Se debe realizar la actualización automáticamente sin intervención manual del usuario, al
momento de querer ingresar un nuevo registro en una vista.

Regla 7: Alto nivel de inserción, actualización y borrado

El sistema debe permitir suministrar datos al mismo tiempo en que se inserten, actualicen o eliminen
por medio de sus capacidades relacionales.

Ejemplo: Si se desean eliminar los registros de una tabla no se debe ir de a uno, el sistema debe proveer
opciones para poder eliminarlos todo de una vez.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 8: Independencia física de los datos

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico, cuando
quiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.

Ejemplo: El modelo relacional es un modelo lógico de datos y no muestra las características de su

representación física.

Si se desean almacenar los datos en varios discos duros, ya no en uno solamente, no se deberían
modificar ni la estructura de la base de datos ni los programas que acceden a ella, esto es tarea del
sistema gestor de base de datos.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 9: independencia lógica de los datos

Los cambios al nivel lógico (tablas, columnas, filas, etc.) no deben requerir un cambio a una solicitud
basada en la estructura. La independencia de datos lógica es más difícil de lograr que la independencia
física de datos.

Ejemplo:

Cambios que preservan la información:

• Añadir un atributo a una tabla base

• Reemplazar dos tablas base por la unión de ellas. Utilizando vistas de la unión se puede recrear las
tablas anteriores.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 10: Independencia de la integridad

Las limitaciones de la integridad se deben especificar por separado de los programas de la aplicación y
se almacenan en la base de datos. Debe ser posible cambiar esas limitaciones sin afectar
innecesariamente las aplicaciones existentes.

Ejemplo:

El objetivo de las bases de datos no se refiere solamente a almacenar datos, sino a establecer las
relaciones e impedir que estas (limitantes) se codifiquen en los programas. Se deben poder definir
limitantes de integridad:
• Una base de datos tiene integridad de entidad: Todas las tablas deben contar con una clave primaria
• Una base de datos tiene integridad referencial: Toda clave externa no nula debe existir en la relación
donde es primaria.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 11: Independencia de la distribución

La distribución de las porciones de la base de datos a las varias localizaciones debe ser invisible a los
usuarios de la base de datos. Los usos existentes deben continuar funcionando con éxito:
• Cuando una versión distribuida del SGBD se introdujo por primera vez
• Cuando se distribuyen los datos existentes se redistribuyen en todo el sistema.

Ejemplo:

En una base de datos centralizada y en una base de datos distribuida, las instrucciones y programas se
ejecutan de la misma forma. Para el cliente debe ser transparente dónde se están almacenando y
accediendo los datos para el proceso que se está ejecutando, el encargado de esto es el sistema gestor
de base de datos.
CONSTRUCCIÓN DEL DISEÑO LÓGICO DE MODELOS DE BASES DE
DATOS RELACIONALES BAJO REQUERIMIENTOS DE UN CLIENTE
Regla 12: La regla de la no subversión

Si el sistema proporciona una interfaz de bajo nivel de registro, a parte de una interfaz relacional, esa
interfaz de bajo nivel no se puede utilizar para subvertir el sistema.

Ejemplo:

No es posible acceder sin pasar por seguridad relacional o limitación de integridad. Esto es debido a que
existen sistemas anteriores no relacionales que agregaron una interfaz relacional, pero con la interfaz
anterior está la posibilidad de trabajar no relacionalmente.
LOS ELEMENTOS DE LOS SISTEMAS DE BASE DE DATOS
Datos: Son hechos conocidos que pueden registrarse y que tienen un significado implícito.

Ejemplo: Datos pueden ser nombres, números de teléfono y direcciones de personas, etc.

Entidades: Es todo aquello de lo cual interesa guardar datos.

LOS ELEMENTOS DE LOS SISTEMAS DE BASE DE DATOS
Claves primarias y claves foráneas.

Relaciones: Para cada entidad se define una clave primaria que establece específicamente un conjunto
de datos. Cuando una entidad contiene la clave primaria de otra entidad, esta se denomina clave
foránea o también llamada Foreign Key (FK). La forma de relacionarse entre distintas entidades es por
medio de las claves foráneas.
MUCHAS GRACIAS