Capítulo 10: Diseño de la Base de Datos

10 DISEÑO DE LA BASE DE DATOS

En el presente capítulo se hará un recorrido por los pasos a seguir para diseñar una
base de datos, haciendo una descripción del modelo Entidad-Relación (modelo
conceptual) y el modelo Relacional (esquema lógico) de la base de datos utilizada en la
aplicación Web.

10.1 METODOLOGÍA DE DISEÑO DE BASES DE DATOS

El diseño de una base de datos es un proceso complejo que abarca decisiones a

muy distintos niveles. La complejidad se controla mejor si se descompone el problema
en subproblemas y se resuelve cada uno de estos subproblemas independientemente,
utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en
diseño conceptual, diseño lógico y diseño físico.
 Capítulo 10: Diseño de la Base de Datos

Diseño conceptual
No depende del modelo de
datos ni de ningún SGBD
específico
Esquema conceptual

Diseño lógico
Depende del modelo de
datos, pero no de ningún
SGBD específico
Esquema lógico

Diseño físico
No depende del modelo de
datos y de un SGBD
específico
Esquema físico

El diseño conceptual parte de las especificaciones de requisitos de usuario y su

resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una
descripción de alto nivel de la estructura de la base de datos, independientemente del
SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje
que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual
es describir el contenido de información de la base de datos y no las estructuras de
almacenamiento que se necesitarán para manejar esta información.

El diseño lógico parte del esquema conceptual y da como resultado un esquema

lógico. Un esquema lógico es una descripción de la estructura de la base de datos en
términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo
lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional,
modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar,
no depende del producto concreto.

El diseño físico parte del esquema lógico y da como resultado un esquema

físico. Un esquema físico es una descripción de la implementación de una base de datos
en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para
tener un acceso eficiente a los datos. Por ello, el diseño físico depende del SGBD
concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.

130
 Capítulo 10: Diseño de la Base de Datos

10.2 MODELOS DE DATOS

Un modelo de datos es una serie de conceptos que puede utilizarse para describir
un conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de
datos: los modelos conceptuales y los modelos lógicos. Los modelos conceptuales se
utilizan para representar la realidad a un alto nivel de abstracción. Mediante los modelos
conceptuales se puede construir una descripción de la realidad fácil de entender. En los
modelos lógicos, las descripciones de los datos tienen una correspondencia sencilla con
la estructura física de la base de datos.

En el diseño de bases de datos se usan primero los modelos conceptuales para

lograr una descripción de alto nivel de la realidad, y luego se transforma el esquema
conceptual en un esquema lógico. El motivo de realizar estas dos etapas es la dificultad
de abstraer la estructura de una base de datos que presente cierta complejidad. Un
esquema es un conjunto de representaciones lingüísticas o gráficas que describen la
estructura de los datos de interés.

Los modelos conceptuales deben ser buenas herramientas para representar la

realidad, por lo que deben poseer las siguientes cualidades:

• Expresividad: deben tener suficientes conceptos para expresar perfectamente la

realidad.
• Simplicidad: deben ser simples para que los esquemas sean fáciles de entender.
• Minimalidad: cada concepto debe tener un significado distinto.
• Formalidad: todos los conceptos deben tener una interpretación única, precisa y
bien definida.

En general, un modelo no es capaz de expresar todas las propiedades de una

realidad determinada, por lo que hay que añadir aserciones que complementen el
esquema.

10.3 EL MODELO ENTIDAD-RELACIÓN

El modelo entidad-relación es el modelo conceptual más utilizado para el diseño

conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo
entidad-relación está formado por un conjunto de conceptos que permiten describir la
realidad mediante un conjunto de representaciones gráficas y lingüísticas.

Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad,

relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos
compuestos y las jerarquías de generalización, en lo que se ha denominado modelo
entidad-relación extendido.

131
 Capítulo 10: Diseño de la Base de Datos

10.3.1 Elementos básicos del modelo E/R

[Link] Entidad

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa,

persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes,
empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se
representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un
nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad
cuya existencia depende de la existencia de otra entidad. Una entidad fuerte es una
entidad que no es débil.

[Link] Relación (interrelación)

Es una correspondencia o asociación entre dos o más entidades. Cada relación

tiene un nombre que describe su función. Las relaciones se representan gráficamente
mediante rombos y su nombre aparece en el interior.

Las entidades que están involucradas en una determinada relación se denominan

entidades participantes. El número de participantes en una relación es lo que se
denomina grado de la relación. Por lo tanto, una relación en la que participan dos
entidades es una relación binaria; si son tres las entidades participantes, la relación es
ternaria; etc.

Una relación recursiva es una relación donde la misma entidad participa más de
una vez en la relación con distintos papeles. El nombre de estos papeles es importante
para determinar la función de cada participación.

La cardinalidad con la que una entidad participa en una relación especifica el

número mínimo y el número máximo de correspondencias en las que puede tomar parte
cada ocurrencia de dicha entidad. La participación de una entidad en una relación es
obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia
de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es
opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las
reglas de negocio.

A veces, surgen problemas cuando se está diseñado un esquema conceptual.

Estos problemas, denominados trampas, suelen producirse a causa de una mala
interpretación en el significado de alguna relación, por lo que es importante comprobar

132
 Capítulo 10: Diseño de la Base de Datos

que el esquema conceptual carece de dichas trampas. En general, para encontrar las
trampas, hay que asegurarse de que se entiende completamente el significado de cada
relación. Si no se entienden las relaciones, se puede crear un esquema que no represente
fielmente la realidad.

Una de las trampas que pueden encontrarse ocurre cuando el esquema representa
una relación entre entidades, pero el camino entre algunas de sus ocurrencias es
ambiguo. El modo de resolverla es reestructurando el esquema para representar la
asociación entre las entidades correctamente.

Otra de las trampas sucede cuando un esquema sugiere la existencia de una

relación entre entidades, pero el camino entre una y otra no existe para algunas de sus
ocurrencias. En este caso, se produce una pérdida de información que se puede subsanar
introduciendo la relación que sugería el esquema y que no estaba representada.

[Link] Atributo

Es una característica de interés o un hecho sobre una entidad o sobre una

relación. Los atributos representan las propiedades básicas de las entidades y de las
relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se
representan mediante bolitas que cuelgan de las entidades o relaciones a las que
pertenecen.

Cada atributo tiene un conjunto de valores asociados denominado dominio. El

dominio define todos los valores posibles que puede tomar un atributo. Puede haber
varios atributos definidos sobre un mismo dominio.

Los atributos pueden ser simples o compuestos. Un atributo simple es un

atributo que tiene un solo componente, que no se puede dividir en partes más pequeñas
que tengan un significado propio. Un atributo compuesto es un atributo con varios
componentes, cada uno con un significado por sí mismo. Un grupo de atributos se
representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su
significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente
mediante un óvalo.

Los atributos también pueden clasificarse en monovalentes o polivalentes. Un

atributo monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad
o relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores
para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos
también se les denomina multivaluados, y pueden tener un número máximo y un
número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y
el número máximo de valores que puede tomar para cada ocurrencia de la entidad o
relación a la que pertenece. El valor por omisión es (1,1).

133
 Capítulo 10: Diseño de la Base de Datos

Por último, los atributos pueden ser derivados. Un atributo derivado es aquel
que representa un valor que se puede obtener a partir del valor de uno o varios atributos,
que no necesariamente deben pertenecer a la misma entidad o relación.

[Link] Identificador o clave

Un identificador de una entidad es un atributo o conjunto de atributos que

determina de modo único cada ocurrencia de esa entidad. Un identificador de una
entidad debe cumplir dos condiciones:

1. No pueden existir dos ocurrencias de la entidad con el mismo valor del

identificador.
2. Si se omite cualquier atributo del identificador, la condición anterior deja de
cumplirse.

Toda entidad tiene al menos un identificador y puede tener varios identificadores

alternativos. Las relaciones no tienen identificadores.

10.3.2 Modelo E/R de la Aplicación Web

A continuación se representa la realidad del proceso que se está llevando a cabo

mediante un modelo E/R.

134
 Capítulo 10: Diseño de la Base de Datos

(1,n) (1,1) (1,1)

Contacto Trabaja Empresa Tiene

(1,1) (1,n)

Realiza Reservas Participa Camiones

(0,n) (0,n) (1,1)

ID
Nombre_Contacto
Zona
Contacto Telefono
Fecha
E_mail Reservas
Hora
Empresa
Fecha_Peticion

Hora_Peticion

Nombre_Empresa Empresa

Empresa Telefono Matricula_Camion

Loguin

Password
Matricula
Nivel_Acceso Camiones
Empresa

10.4 DISEÑO LÓGICO DE BASES DE DATOS

El objetivo del diseño lógico es convertir los esquemas conceptuales locales en

un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a
implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es
la compleción y expresividad de los esquemas conceptuales locales, el objetivo del
diseño lógico es obtener una representación que use, del modo más eficiente posible, los
recursos que el modelo de SGBD posee para estructurar los datos y para modelar las
restricciones.

135
 Capítulo 10: Diseño de la Base de Datos

Los modelos de bases de datos más extendidos son el modelo relacional, el

modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy
popular, pero no existe un modelo estándar orientado a objetos.

El modelo relacional (y los modelos previos) carecen de ciertos rasgos de

abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la
fase del diseño lógico consistirá en la conversión de esos mecanismos de representación
de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo
relacional.

10.5 EL MODELO RELACIONAL

En 1970, el modo en que se veían las bases de datos cambió por completo
cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque
existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones
de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería
relacionar un registro A con un registro B, se debía añadir al registro A un campo
conteniendo la dirección en disco del registro B. Este campo añadido, un puntero físico,
siempre señalaría desde el registro A al registro B. Codd demostró que estas bases de
datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar
sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el
entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos
se movían de una localización física a otra, se requería una conversión de los ficheros de
datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos
modelos lógicos que constituyeron la primera generación de los SGBD.

El modelo relacional representa la segunda generación de los SGBD. En él,

todos los datos están estructurados a nivel lógico como tablas formadas por filas y
columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un
punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de
esa simple estructura hay un fundamento teórico importante del que carecen los SGBD
de la primera generación, lo que constituye otro punto a su favor.

Dada la popularidad del modelo relacional, muchos sistemas de la primera

generación se han modificado para proporcionar una interfaz de usuario relacional, con
independencia del modelo lógico que soportan (de red o jerárquico). Por ejemplo, el
sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión
relacional de los datos.

En los últimos años, se han propuesto algunas extensiones al modelo relacional

para capturar mejor el significado de los datos, para disponer de los conceptos de la
orientación a objetos y para disponer de capacidad deductiva.

136
 Capítulo 10: Diseño de la Base de Datos

El modelo relacional, como todo modelo de datos, tiene que ver con tres
aspectos de los datos:

• Estructura de datos.
• Integridad de datos.
• Manejo de datos.

10.5.1 El Modelo Relacional de la Aplicación Web

A continuación se pasa a realizar el diseño lógico. Para ello se parte del esquema
conceptual E/R y se transforma en el esquema lógico relacional. Con dicho esquema
lógico ya se tendrá la estructura de nuestra base de datos.

Por lo tanto, se obtienen las siguientes tablas:

137
 Capítulo 10: Diseño de la Base de Datos

CONTACTO EMPRESA CAMIONES

Nombre_Contacto Nombre_Empresa Matricula

Teléfono Teléfono Empresa

E_mail Loguin

Empresa Password

Nivel_Acceso

RESERVA

ID

Zona

Fecha

Hora

Fecha_Petición

Hora_Petición

Empresa

Matricula_Camión

10.6 NORMALIZACIÓN

La normalización es una técnica para diseñar la estructura lógica de los datos de

un sistema de información en el modelo relacional, desarrollada por E. F. Codd en
1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se
van agrupando en relaciones (tablas) según su afinidad. Aquí no se utilizará la
normalización como una técnica de diseño de bases de datos, sino como una etapa
posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que
elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización
son las siguientes:

138
 Capítulo 10: Diseño de la Base de Datos

• Evita anomalías en inserciones, modificaciones y borrados.

• Mejora la independencia de datos.
• No establece restricciones artificiales en la estructura de los datos.

Uno de los conceptos fundamentales en la normalización es el de dependencia

funcional. Una dependencia funcional es una relación entre atributos de una misma
relación (tabla). Si X e Y son atributos de la relación R, se dice que Y es funcionalmente
dependiente de X (se denota por XÆY) si cada valor de X tiene asociado un solo valor
de Y (X e Y pueden constar de uno o varios atributos). A X se le denomina
determinante, ya que X determina el valor de Y. Se dice que el atributo Y es
completamente dependiente de X si depende funcionalmente de X y no depende de
ningún subconjunto de X.

La dependencia funcional es una noción semántica. Si hay o no dependencias

funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien,
los modelos mentales del usuario y las reglas de negocio de la organización o empresa
para la que se desarrolla el sistema de información. Cada dependencia funcional es una
clase especial de regla de integridad y representa una relación de uno a muchos.

En el proceso de normalización se debe ir comprobando que cada relación

(tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias
funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla
no se cumple, la relación se debe descomponer en varias relaciones que sí la cumplan.

La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a

una forma normal que tiene unas propiedades. Conforme se va avanzando en la
normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto,
son menos vulnerables a las anomalías de actualización. El modelo relacional sólo
requiere un conjunto de relaciones en primera forma normal. Las restantes formas
normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es
recomendable llegar al menos a la tercera forma normal.

Primera forma normal (1FN)

Una relación está en primera forma normal si, y sólo si, todos los dominios de la
misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la
relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la
intersección de cada fila con cada columna.

Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos.
Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para
cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la
primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo.
De este modo, se introducen redundancias ya que se duplican valores, pero estas
redundancias se eliminarán después mediante las restantes formas normales. La segunda

139
 Capítulo 10: Diseño de la Base de Datos

forma de eliminar los grupos repetitivos consiste en poner cada uno de ellos en una
relación aparte, heredando la clave primaria de la relación en la que se encontraban.

Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos

repetitivos.

Segunda forma normal (2FN)

Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además,
cada atributo que no está en la clave primaria es completamente dependiente de la clave
primaria.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos
o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo
atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden
sufrir anomalías cuando se realizan actualizaciones.

Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias
parciales de la clave primaria. Para ello, se eliminan los atributos que son
funcionalmente dependientes y se ponen en una nueva relación con una copia de su
determinante (los atributos de la clave primaria de los que dependen).

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además,
cada atributo que no está en la clave primaria no depende transitivamente de la clave
primaria. La dependencia XÆZ es transitiva si existen las dependencias XÆY, YÆZ,
siendo X e Y atributos o conjuntos de atributos de una misma relación.

Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en
1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una
relación de 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se
eliminan los atributos que dependen transitivamente y se ponen en una nueva relación
con una copia de su determinante (el atributo o atributos no clave de los que dependen).

140