Capitulo 4

4 TEMA 4. DISEÑO DE BASES DE DATOS

4 TEMA 4. DISEÑO DE BASES DE DATOS........................................................... 1
4.1 Metodologías de diseño .................................................................................... 2
4.1.1 Introducción.............................................................................................. 2
4.1.2 Metodologías de diseño de bases de datos ............................................... 3
4.2 Diseño Conceptual. El Modelo Entidad-Relación (E/R).................................. 6
4.2.1 Conceptos fundamentales ......................................................................... 6
4.2.2 Control de redundancia de los diagramas E/R.......................................... 8
4.2.3 Modelo E/R extendido.............................................................................. 9
4.3 Diseño Lógico. Normalización....................................................................... 13
4.3.1 Transformación de diagramas E/R en relaciones ................................... 13
4.3.2 Normalización. Formas Normales.......................................................... 15
4.3.3 Dependencias funcionales ...................................................................... 16
4.3.4 Primera, segunda y tercera formas normales.......................................... 17
4.3.5 Forma normal de Boyce/Codd................................................................ 19
4.3.6 Cuarta forma normal............................................................................... 20
4.3.7 Quinta forma normal .............................................................................. 21
4.4 Diseño Físico .................................................................................................. 23
4.4.1 Introducción al diseño físico................................................................... 23
4.4.2 Criterios para la selección de índices ..................................................... 24

Tema 4: Diseño de bases de datos 1

4.1 Metodologías de diseño
4.1.1 Introducción
Un sistema de información (SI) es un conjunto de elementos que funcionan
conjuntamente con el objetivo de recoger, tratar, manipular y aportar la informaciones
necesarias para el desarrollo de las actividades de una empresa u organización. Un SI
puede incluir procesos manuales o automáticos.

Uno de los elementos principales de un SI es la base de datos (BD). Las BD son
ejemplos típicos de grandes sistemas de software con tres características importantes:

• Hay una gran cantidad de datos que deben ser almacenados en memoria
externa y que deben ser organizados de forma que los datos elementales
puedan ser recuperados y actualizados fácil y eficientemente.

• Los datos guardan entre sí complejas interrelaciones. La información incluye
restricciones estáticas y dinámicas, como los valores permitidos o las
posibles evoluciones.

• Los datos deben ser compartidos entre diferentes usuarios y el sistema debe
mantener la integridad de la información.

Un modelo es una representación de un sistema que pretende simplificar su
comprensión poniendo en evidencia ciertos aspectos del sistema mientras otros son
ocultados. Los modelos se utilizan para facilitar la tarea de diseño de los SI complejos,
ya que facilitan ‘pensar en lo que se está haciendo’ y permiten comprobar la corrección
y adecuación al problema de los resultados.

Los modelos pueden tener distintos niveles de abstracción. En los SI se utilizan tres
tipos de modelos con diferentes niveles de abstracción:

• El modelo físico, que describe completamente el sistema: circulación y
tratamiento de la información, elementos informáticos y elementos
manuales. Para la BD el modelo físico representa la organización de la
información sobre los soportes de almacenamiento.

• El modelo lógico, que describe las informaciones y las manipulaciones a que
son sometidas. Este modelo hace abstracción de los soportes materiales de
almacenamiento. El modelo lógico sobre una BD representa la definición de
la información sobre el SGBD elegido para el desarrollo del SI.

• El modelo conceptual, que describe el contenido subyacente al modelo
lógico, esto es, el significado de las informaciones y las relaciones que las
unen. Este modelo hace abstracción de las manipulaciones de la información.

En los siguientes capítulos se establecen los conceptos y técnicas necesarios para
diseñar bases de datos. Los criterios que definen un buen diseño de la BD, según
Gardarín, son:


• Independencia física
• Independencia lógica
• Manipulación de datos por no informáticos
• Eficacia del acceso a los datos
• Administración centralizada de los datos
• No redundancia de los datos
• Coherencia de los datos
• Compatibilidad de los datos
• Seguridad de los datos

4.1.2 Metodologías de diseño de bases de datos
Existen distintas metodologías para el diseño de SI y de BD, que identifican las etapas
del diseño, los subproductos que se obtienen en cada una de ellas, así como las utilerías
necesarias para desarrollar esta actividad. Algunas de las metodologías más utilizadas
son MERISE y SSADM. En este capítulo describiremos una de las metodología para el
desarrollo de BD relacionales, que sigue las recomendaciones más comunes encontradas
en la literatura.

4.1.2.1 Análisis de requisitos de usuario

El objetivo de esta etapa es describir con precisión el contenido de información de la
base de datos y determinar las demandas de transacción que sufrirá el sistema.

Las especificaciones del sistema pueden describirse informalmente utilizando
descripciones narrativas, o formalmente utilizando un modelo de datos. El modelo de
datos a utilizar debe ser suficientemente ‘expresivo’ como para poder representar toda la
información de la BD.

Al integrar la BD las necesidades de información de distintos grupos de usuarios y de
distintas aplicaciones dentro de la empresa u organización, será un previo identificar
todos los grupos de usuarios que interactúan con la BD. Posteriormente se obtendrá para
cada uno de estos grupos la descripción detallada de sus requisitos. Cada grupo de estas
especificaciones constituye una vista particular de la BD.

En esta etapa se identificarán los objetos o eventos del mundo real que almacenará la
BD, sus propiedades y las relaciones que mantienen entre ellos. Se identificarán las
condiciones de integridad de la información que darán lugar a restricciones de
manipulación. Se identificarán las autorizaciones de acceso a la información por parte
de los distintos grupos de usuarios. También puede ser interesante en esta etapa tener
una estimación del volumen de datos a almacenar.

Por último, se identificarán las operaciones a realizar sobre la información. Esta
información es relevante en el modelo relacional únicamente para el diseño del modelo
físico de la BD. Por esta razón, en algunos casos no se requiere. Se describirán la
naturaleza de las transacciones, la frecuencia con que se realizan, la información que
utilizan y producen, así como el flujo de información entre ellas.


4.1.2.2 Diseño del esquema conceptual

En esta etapa se combinan los requisitos de los distintos grupos de usuarios del sistema
para contribuir a una descripción única y coherente de toda la información a almacenar
en la BD. El esquema conceptual se desarrolla en un modelo semántico y define las
entidades en la BD, las relaciones entre ellas, las restricciones de integridad de la
información, los grupos de usuarios y las autorizaciones de acceso de cada uno de ellos.

Este proceso se conoce a veces como integración de vistas, y en el se produce una
descripción global de la BD eliminando la redundancia e inconsistencia entre las
especificaciones de distintos grupos de usuarios. El modelador debe reconocer entre las
diferentes vistas los sinónimos y homónimos y aquellos tipos de datos que pertenecen a
las mismas categorías.

En esta etapa se construye un modelo de datos que describe cada uno de los objetos y
sus relaciones. Se identifican los atributos que forman las claves de acceso a los objetos,
se decide la representación de las interrelaciones y se identifican las propiedades
opcionales y fijas, para lo cual se utiliza un modelo semántico de datos, comúnmente el
modelo Entidad/Relación, que será el que utilicemos nosotros en esta presentación.

4.1.2.3 Diseño Lógico

Durante esta etapa, el modelo conceptual se transforma en el modelo empleado por el
SGBD donde se implementará el sistema. El modelo que más se utiliza hoy por hoy es
el modelo relacional, aunque se utilizan todavía el modelo en red y el jerárquico.

Para BD relacionales, en esta etapa se construyen las tablas a partir de los elementos del
esquema conceptual, incluyendo las relaciones entre entidades y las reglas de
integridad. En esta etapa se crean los usuarios y se administran las autorizaciones para
acceder a la información.

El modelo E/R desarrollado en el paso anterior puede transformarse directamente en
tablas, siguiendo una serie de reglas de transformación. La mayoría de modelos ofrece
estas reglas para una transformación semiautomática del esquema conceptual de
relaciones de la BD.

4.1.2.4 Normalización de los esquemas relacionales

En muchos casos, las tablas resultantes del proceso anterior se someten a un proceso
posterior de normalización que elimina redundancias de la información no eliminadas y
que repercuten en dificultades en el procesamiento de la información.

4.1.2.5 Diseño físico

En función de las operaciones a realizar sobre la BD, se definen los mecanismos de
almacenamiento y organización de la información, incluyendo la creación de índices o
la agrupación en ‘clusters’ de los datos. En algunos casos puede ser necesario
desnormalizar la información (añadiendo redundancia) para conseguir el rendimiento
deseado de la aplicación.


4.1.2.6 Implementación

Es la transformación del modelo de datos y los diseños realizados en una base de datos
en funcionamiento, que opere en un determinado equipo y bajo el control de un SGBD.

4.1.2.7 Test

La etapa de test tiene el propósito de descubrir errores aparecidos en las etapas
anteriores y que provocan un comportamiento del sistema diferente al previsto. Es
también objetivo de la etapa de test el comprobar junto a los usuarios que el sistema
satisface los objetivos establecidos durante la etapa de especificación.

4.1.2.8 Mantenimiento

La fase de mantenimiento incluye la corrección de errores que pudieran aparecer
durante la etapa de operación del sistema. La implementación también comprende las
modificaciones que el usuario pudiera solicitar a partir de la experiencia de operación
del sistema o de nuevas necesidades, la mejora de la eficacia del sistema y la mejora de
los interfaces de usuario.


4.2 Diseño Conceptual. El Modelo Entidad-Relación (E/R)
En este apartado estudiaremos el modelo E/R, uno de los modelos de datos conceptuales
más extendidos en las metodologías de diseño de bases de datos y en las herramientas
CASE.

El modelo E/R fue propuesto por Peter P. Chen en 1976. Según Chen, ‘el modelo E/R
puede ser usado como una base para una vista unificada de los datos’, adoptando ‘el
enfoque más natural del mundo real que consiste en entidades y relaciones’.

Posteriormente, otros autores han investigado y escrito sobre el modelo, proponiendo
importantes aportaciones, por lo que realmente no se puede considerar que exista un
único modelo E/R, sino más bien lo que podríamos llamar una familia de modelos.

El modelo E/R está centrado en dos conceptos fundamentales: el de entidad y el de
relación que explicaremos más adelante en está sección de forma detallada. Desde que
fue propuesto, este modelo ha tenido una gran difusión y ha despertado un enorme
interés en la comunidad informática dedicada a las bases de datos.

4.2.1 Conceptos fundamentales
En el modelo E/R se pueden distinguir como elementos fundamentales las entidades, los
atributos, y las relaciones, además del conjunto de valores (análogo al concepto de
dominio).

4.2.1.1 Entidad

Se puede definir entidad como aquel objeto (real o abstracto) acerca del cual queremos
almacenar información en la base de datos. Denominaremos a la estructura genérica en
su sentido abstracto tipo de entidad, mientras que entidad será cada una de las
ocurrencias o instancias de este tipo de entidad.

La representación gráfica de un tipo de entidad es un rectángulo etiquetado con el
nombre del tipo de entidad:

LIBRO AUTOR

Tres reglas generales que debe cumplir cualquier entidad son (Tardieu):

• Tiene que tener existencia propia
• Cada ocurrencia de un tipo debe poder distinguirse de las demás
• Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de
características (atributos).

Existen dos clases de entidades: regulares, que tienen existencia por ellas mismas, y
débiles, cuya existencia depende de otro tipo de entidad (p. ej., FAMILIAR depende de
que exista EMPLEADO, y la eliminación de EMPLEADO obliga a la eliminación de
FAMILIAR).


Los tipos de entidad débil se representan con dos rectángulos concéntricos con su
nombre en el interior:

LIBRO

4.2.1.2 Relación

Se entiende por relación a aquella asociación o correspondencia existente entre
entidades. Llamaremos tipo de relación a la estructura genérica del conjunto de
relaciones existentes entre dos o más tipos de entidad.

El tipo de relación se representa mediante un rombo etiquetado con el nombre de la
relación, unido mediante arcos a los tipos de entidad que asocia. P. ej.:

LIBRO escribe AUTOR

Entre dos tipos de entidades puede existir más de un tipo de relación.

Una relación se define por su nombre y por su grado. El nombre es el identificador que
se le da a la propia relación, y el grado equivale al número de tipos de entidad a los que
asocia o relaciona. Así por ejemplo, en el caso anterior, ‘escribe’ es una relación de
grado 2. También pueden existir relaciones de grado 1 (o reflexivas), de grado 3, 4, …

En general, las relaciones de grado superior a 2 se suelen reducir a relaciones de grado
2, si la semántica de la relación lo permite, puesto que se facilita tanto la comprensión
del diagrama como la posterior conversión a otros modelos.

Otro elemento que caracteriza a las relaciones es el tipo de correspondencia, que es el
número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una
ocurrencia del tipo de relación que se está tratando. Gráficamente, esto se representa
con alguna de estas etiquetas textuales: 1:1, 1:N, N:M. El papel o rol es la función que
cada tipo de entidad realiza en el tipo de relación. Se representa con su nombre sobre el
arco que une el tipo de entidad con el tipo de relación. P. ej.:
N:M

es_escrito_por escribe
LIBRO escribe AUTOR

4.2.1.3 Atributo

Cada una de las propiedades o características que tiene un tipo de entidad o un tipo de
relación se denomina ATRIBUTO. La representación gráfica de un atributo consiste en
una elipse con el nombre del atributo en su interior.


Entre todos los atributos de un tipo de entidad debemos elegir uno o varios que actúen
como claves primarias. Estos atributos se representarán de la misma forma, pero con el
nombre del atributo subrayado. Veamos un ejemplo:

N:M
es_escrito_por escribe
LIBRO escribe AUTOR

ISBN Título Fecha Nombre F_nac

4.2.2 Control de redundancia de los diagramas E/R
Una vez construido un esquema E/R, hay que analizar si se presentan redundancias, ya
que pueden acarrear problemas a la hora de instrumentar la base de datos. Además de la
existencia de atributos redundantes, como los que se derivan de otros mediante algún
cálculo, hay que estudiar detenidamente los ciclos en el diagrama E/R, ya que pueden
indicar la existencia de relaciones redundantes.

Un ciclo en un diagrama E/R es un grupo de tipos de entidad unidos en forma circular o
cíclica a través de ciertas relaciones. P. ej.:
N:M N:M

escribe AUTOR publica

N:1

LIBRO edita EDITORIAL

Es evidente que en este ejemplo podríamos eliminar la relación publica, puesto que si
conocemos los libros que un autor ha escrito, y sabemos las editoriales que editan
dichos libros, somos capaces de extrapolar las editoriales en las que un determinado
autor publica sus libros. Por consiguiente, podemos eliminar la relación publica de
nuestro diagrama por ser redundante.

Este caso no es general, es decir, es posible que existan ciclos en los que no aparezcan
redundancias. Los casos más típicos son los que resultan de dividir relaciones ternarias
en sus correspondientes binarias.


4.2.3 Modelo E/R extendido
Una vez visto el modelo básico de Chen, hay que profundizar un poco más en otros
aspectos que aportan aún más significado y relevancia a esta herramienta, tan
fundamental en la fase de diseño conceptual.

Ya hemos señalado que varios autores han considerado diversas extensiones al modelo
E/R definido por Chen, dando lugar a lo que algunos han llamado modelo E/R
extendido (EE/R). Trataremos de mostrar las extensiones al modelo más interesantes
por su funcionalidad y uso.

4.2.3.1 Cardinalidad de un tipo de entidad

Se define como el número máximo y mínimo de ocurrencias de un tipo de entidad que
pueden estar relacionadas con una ocurrencia del otro u otros tipos de entidad que
participan en la relación. Su representación gráfica es una etiqueta del tipo (0,1), (1,1),
(0,n), o (1,n), según corresponda. El significado de cada una es:

• (0,1). Para una ocurrencia determinada de los otros tipos de entidades que
participan en la relación, el valor mínimo de ocurrencias de la entidad que se
trata es 0, y el número máximo es 1.

• (1,1). Para una ocurrencia determinada de los otros tipos de entidades que
participan en la relación, debe existir una y sólo una ocurrencia de la entidad
que se trata.

• (0,n). Para una ocurrencia determinada de los otros tipos de entidades que
participan en la relación, el valor mínimo de ocurrencias de la entidad que se
trata es 0, y el número máximo es n.

• (1,n). Para una ocurrencia determinada de los otros tipos de entidades que
participan en la relación, debe existir como mínimo una ocurrencia de la
entidad que se trata, si bien no hay límite en el número de veces que dicha
ocurrencia puede aparecer en la relación.

Ejemplo:
1:N
(1,1) (1,n)
DEPTO. pertenece EMPLDO.

4.2.3.2 Relaciones exclusivas

Decimos que dos o más tipos de relación son exclusivos cuando cada ocurrencia de un
tipo de entidad sólo puede pertenecer a un tipo de relación. Un ejemplo, con su
correspondiente forma de representación, es el siguiente:


publica REVISTA

ARTICULO

aparece RECOPILACION

4.2.3.3 Generalización y Herencia

La descomposición de tipos de entidad en varios subtipos es una necesidad muy
habitual en el modelado de bases de datos. En el mundo real se pueden identificar varias
jerarquías de entidades. La relación que se establece entre un supertipo y sus subtipos
corresponde a la noción de ‘es_un’ o ‘es_un_tipo_de’.

Este tipo de relación especial se representa a través de un triángulo invertido con la base
paralela al rectángulo que representa al supertipo, y conectado a los subtipos. Esta
relación tiene la característica de que toda ocurrencia de un subtipo es una ocurrencia
del supertipo, aunque no sucede lo contrario, con lo que las cardinalidades serán
siempre (1,1) en el supertipo, y (0,1) o (1,1) en el subtipo. El atributo del supertipo que
actúa como discriminante se liga al triángulo a través de una elipse. Por ejemplo:

EMPLEADO

(1,1)

tipo es-un

(0,1) (0,1)

DOCENTE NO DOCENTE

Una característica importante en estas relaciones es la herencia, puesto que cualquier
atributo del supertipo pasa a ser un atributo de los subtipos.

Adicionalmente, existen dos tipos de elementos para la representación que se utilizan
para indicar:

• Arco. Indica la exclusividad de los subtipos, es decir, que una entidad del
supertipo sólo puede ser de uno sólo de los subtipos.
• Elipse vacía. Indica la obligatoriedad del supertipo de pertenecer a alguno de
los subtipos.


Un ejemplo completo de estos diagramas es:

EMPLEADO

(1,1)

tipo es-un

(0,1) (0,1)

DOCENTE NO DOCENTE

En este caso, se indica que un empleado debe ser de tipo docente o no docente, y
además no puede pertenecer a los dos subtipos a la vez.

4.2.3.4 Relaciones Ternarias (de grado 3)

Como ya se ha mencionado con anterioridad, lo habitual es encontrar relaciones binarias
en los diagramas E/R. Sin embargo, esto no significa que no puedan existir relaciones
de orden superior, aunque siempre es conveniente tratar de reducirlas (en la medida en
que la semántica de la relación lo permita) a relaciones binarias. Vamos a analizar cómo
se representan las relaciones ternarias, y cómo se deben interpretar las cardinalidades de
estos tipos de relaciones.

Supongamos la relación ternaria mostrada en la figura inferior. En esta relación de
ejemplo aparecen las entidades Profesor, Asignatura y Alumno. La relación se llama
curso, y representa las ternas que se pueden dar durante un curso académico,
relacionando los profesores que imparten ciertas asignaturas, con los alumnos
matriculados en dichas asignaturas, y por ende, los profesores que tienen asignados
ciertos alumnos.

PROFESOR (0,1) ASIGNATURA

(0,n)
curso

(0,n)

ALUMNO


Es evidente que esta relación se podría descomponer en tres relaciones binarias, de
modo que los profesores estuviesen relacionados con los alumnos a los que les imparten
clase, los alumnos estuviesen relacionados con las asignaturas en las que están
matriculados, y las asignaturas estuviesen relacionadas con los profesores que las
imparten.

La información que se podría extraer de ambos diagramas E/R sería la misma, sólo que
quizás se encontraría de forma más compacta en la representación tabular
correspondiente al diagrama con la relación ternaria. No obstante, es mucho más fácil
de interpretar el diagrama E/R con relaciones binarias.

Volviendo al diagrama con la relación ternaria, hay que indicar que todos los elementos
que pueden aparecer en torno a la relación tienen el mismo significado que en las
relaciones binarias, excepto la cardinalidad de las relaciones.

Como podrá observarse fácilmente, la cardinalidad de una relación binaria hace
referencia al número de apariciones que puedo tener (máximo y mínimo) de una entidad
respecto a la aparición de un elemento de la otra entidad que participa en la relación. Si
se pretende extender este significado al caso de relaciones de orden n, habrá que
especificar la cardinalidad máxima y mínima de elementos de una entidad respecto a los
n-1 elementos de las n-1 entidades restantes. Es decir, hay que fijar la aparición de
elementos de n-1 entidades para encontrar la cardinalidad máxima y mínima de los
elementos de la entidad restante.

Por tanto, en nuestro ejemplo, la cardinalidad (0,n) correspondiente a la entidad alumno
indica que para una pareja fija de profesor/asignatura puedo tener en la relación un
mínimo de 0 alumnos y un máximo sin determinar.


4.3 Diseño Lógico. Normalización.
En el diseño lógico se debe coordinar exigencias casi siempre encontradas, como son
eliminar redundancias, conseguir la máxima simplicidad, y evitar cargas suplementarias
de programación, obteniendo una estructura lógica adecuada que venga a establecer el
debido equilibrio entre las exigencias de los usuarios y la eficiencia.

Pero básicamente, el proceso de diseño lógico debe utilizar como entrada un modelo de
datos conceptual, el cual se deberá convertir al modelo de la base de datos para el que se
está diseñando, esto es, el diseño lógico consiste en una transformación de modelos.
Adicionalmente, será necesario comprobar que el modelo lógico resultante garantiza las
propiedades de eliminación de redundancias, fácil accesibilidad a los datos, etc. Para
ello, en el caso de bases de datos relacionales, recurriremos a la teoría de la
normalización, que nos permitirá obtener las mejores relaciones posibles para un
esquema lógico.

4.3.1 Transformación de diagramas E/R en relaciones
El paso de un esquema en el modelo E/R al relacional está basado en los tres principios
siguientes:

• Todo tipo de entidad se convierte en una relación.

• Todo tipo de relación N:M se transforma en una relación.

• Todo tipo de relación 1:N se traduce en el fenómeno de propagación de clave
o se crea una nueva relación.

En el proceso de transformación de esquemas se pierde semántica, pero esto no va a
afectar para nada la integridad de la base de datos, ya que se definirán, por ejemplo,
restricciones de integridad referencial para asegurar la conservación de la misma.

4.3.1.1 Transformación de entidades

Cada tipo de entidad se debe convertir a una relación, es decir, será necesario crear una
tabla para cada entidad que aparezca en el diagrama E/R. Esto, sin embargo, tiene
alguna restricción para el caso particular en que las relaciones entre entidades sea del
tipo 1:1.

4.3.1.2 Transformación de atributos de entidades

Cada atributo de una entidad se debe transformar en una columna en la relación a la que
ha dado lugar la entidad. Puesto que hay diferentes tipos de atributos, hay que indicar
cómo se deben definir cada uno de ellos:

• El o los atributos principales de una entidad (es decir, los que actúan como
identificador único para los elementos de la relación, subrayados en el
esquema) pasan a ser la clave primaria de la relación. Se debe especificar
que no son nulos.


• El resto de atributos pasan a ser columnas de la tabla, pudiendo tomar
valores nulos, a no ser que se indique lo contrario.

4.3.1.3 Transformación de relaciones

Dependiendo del tipo de relación (cardinalidad) de que se trate, existen diversas formas
de transformarlas:

• Relaciones N:M. Se transforman en una relación que tendrá como clave
primaria la concatenación de los atributos principales de cada una de las
entidades que relacionan. Estos atributos deben ser clave ajena respecto a
cada una de las tablas donde ese atributo es clave primaria. Habrá que
considerar lo que ocurre en los casos en los que se borre o modifique la clave
primaria referenciada. Será necesario crear las restricciones de cardinalidad
adecuadas a través de la sentencia CHECK de SQL.

• Relaciones 1:N. Existen dos soluciones para transformarlas. Habrá que
considerar en ambos casos las referencias ajenas, y las actuaciones en caso
de borrado y modificación.

a) Propagar el atributo principal de la entidad que tiene cardinalidad
máxima 1 a la que tiene N, y hacer desaparecer la relación como tal.

b) Transformarla en una relación como si fuese una de tipo N:M. Esta
acción sólo es recomendable en los casos en que: 1) cuando es
posible que aparezcan muchos nulos porque existen pocos elementos
relacionados, 2) cuando se prevé que dicha relación pasará en un
futuro a ser de tipo N:M, y 3) cuando la relación tiene atributos
propios.

• Relaciones 1:1. Puesto que se trata de una particularización de cualquiera de
los dos casos anteriores, se puede del mismo modo aplicar cualquiera de las
dos reglas definidas. No obstante, es recomendable seguir las siguientes
reglas: 1) si la relacione es (0,1)(0,1), es mejor crear una relación para evitar
el tener muchos nulos como propagación de alguna de las claves a la otra
relación (si se prevé que puede haber muchos nulos); 2) si la relación es
(0,1)(1,1), es mejor propagar la clave de la entidad (1,1) a la (0,1); 3) si la
relación es (1,1)(1,1) la propagación es indiferente, y se hará atendiendo a
los criterios de frecuencia de acceso (consulta, modificación, inserción, etc.)
a cada una de las tablas en cuestión.

4.3.1.4 Transformación de atributos de relaciones

Si la relación se transforma en una tabla, todos sus atributos pasan a ser columnas de la
tabla. En el caso en que alguno de los atributos de la relación sea principal, deberá ser
incluido como parte de la clave primaria en dicha tabla.

4.3.1.5 Transformación de relaciones exclusivas

Para soportar relaciones exclusivas debemos definir las restricciones pertinentes en cada
caso. Por ejemplo, en el caso en que exista una exclusividad en la edición de un libro


por parte de una editorial o de una universidad, estas dos relaciones se resuelven
mediante el mecanismo de propagación de la clave, llevando las claves primarias de
editorial y universidad a libro. Se utilizará entonces la cláusula CHECK de SQL para
introducir las restricciones pertinentes. Ejemplo:

CRATE TABLE LIBRO
( Cod_libro char(10),
Titulo, char(100),
…
Cod_editorial char(20),
Cod_univers char(20),
PRIMARY KEY(Cod_libro),
FOREIGN KEY (Cod_editorial) REFERENCES Editorial ON UPDATE CASCADE,
FOREIGN KEY (Cod_univers) REFERENCES Univers ON UPDATE CASCADE,
CHECK ( (Cod_editorial IS NULL AND Cod_univers IS NOT NULL) OR
(Cod_univers IS NULL AND Cod_editorial IS NOT NULL) );

4.3.1.6 Transformación de tipos y subtipos

Los tipos y subtipos no son objetos que se puedan representar en el modelo relacional
estándar. Existen, pues, varias posibilidades para su transformación:

• Englobar todos los atributos de una entidad y sus subtipos en una sola
relación, añadiendo el atributo que permite distinguir los subtipos. También
habrá que especificar las restricciones semánticas adecuadas.

• Crear una relación para el supertipo, y tantas relaciones como subtipos
existan. Esta es la mejor opción desde el punto de vista semántico, pero es
menos eficiente que la opción anterior.

• Crear sólo relaciones para los subtipos, añadiendo en cada una de ellas los
atributos pertenecientes al supertipo.

4.3.2 Normalización. Formas Normales
Lo que nos ocupa aquí es el esquema conceptual. El diseño de bases de datos es en
realidad el diseño de esquemas.

Las relaciones base de una BD relacional siempre están normalizadas, en el sentido de
que los dominios simples subyacentes contienen sólo valores atómicos. Este tema lleva
la idea de normalización mucho más lejos. El punto fundamental es que una relación
dada, aun cuando pudiera estar normalizada, podría poseer ciertas propiedades
indeseables. La teoría de la normalización nos permite reconocer esos casos y nos
muestran cómo podemos convertir esas relaciones a una forma más deseable.

La teoría de la normalización tiene como fundamento el concepto de formas normales.
Se dice que una relación está en una determinada forma normal si satisface un cierto
conjunto de restricciones.

Se ha definido un gran número de formas normales (FN). En principio, Codd definió la
1FN, 2FN y 3FN, con la idea de que era más deseable que una relación estuviese en


2FN que en 1FN, y a su vez, era mejor que estuviese en 3FN que en 2FN. Se introdujo
también la idea de un procedimiento, el procedimiento de normalización, con el cual
una cierta relación en una determinada FN puede convertirse en un conjunto de
relaciones más deseables (o sea, en una FN superior). Además, este procedimiento es
reversible, lo que garantiza que no se pierde información en cada paso del proceso.

Con posterioridad, se definieron la forma normal de BOYCE/CODD (FNBC) y las 4FN
y 5FN. El siguiente gráfico muestra como las relaciones se agrupan en función de su
estado de normalización:

Universo de las relaciones
Relaciones 1FN
Relaciones 2FN
Relaciones 3FN
Relaciones FNBC
Relaciones 4FN
Relaciones PJ/NF (5FN)

4.3.3 Dependencias funcionales
El concepto de dependencia funcional se define del siguiente modo:

Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R
(R.X R.Y) si y sólo si un valor de Y en R está asociado a cada valor X en R (en
cualquier momento dado).

Obviamente, si X es una clave candidata de la relación (o la clave primaria), todos los
atributos deben depender funcionalmente de ella. Otra manera más clara de expresar el
significado de una dependencia funcional es:

Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R si
y sólo si siempre que dos tuplas de R concuerden en su valor de X, deben por fuerza
concordar en su valor de Y.

Definimos también el concepto de dependencia funcional completa:

Se dice que el atributo Y de la relación R es por completo dependiente funcionalmente
del atributo X de R si depende funcionalmente de X y no depende funcionalmente de
ningún subconjunto propio de X.


Para representar las dependencias funcionales utilizaremos los diagramas de
dependencias funcionales. Un ejemplo de este tipo de diagramas es:

DNI
X#
DNI DNI CANTIDAD
Y#
DNI

La dependencia funcional es un concepto semántico. Como consecuencia, se puede
decir que estas dependencias son un tipo especial de reglas de integridad. Estas
dependencias representan a su vez interrelaciones de muchos a uno.

4.3.4 Primera, segunda y tercera formas normales
Por simplicidad, se definen estas tres formas normales para el caso en el que las
relaciones sólo tienen una clave candidata (y por tanto, solo tienen clave primaria). Para
el caso en que no se cumpla esto, se recurre directamente a la FNBC, que se explica con
posterioridad.

Definiciones:

1. Una relación está en 1FN si y sólo si todos los dominios simples subyacentes
contienen sólo valores atómicos.

2. Una relación está en 2FN si y sólo si está en 1FN y todos los atributos no
clave dependen por completo de la clave primaria.

3. Una relación está en 3FN si y sólo si está en 2FN y todos los atributos no
clave dependen de manera no transitiva de la clave primaria. O dicho de otro
modo, una relación está en 3FN si y sólo si los atributos no clave son:

• mutuamente independientes, y
• dependientes por completo de la clave primaria

donde no clave significa que no participa en la clave primaria, y mutuamente
independientes significa que cualquiera de los atributos no depende
funcionalmente de cualquier combinación de los otros.

Veamos ahora un ejemplo de cómo convertir relaciones entre distintas formas normales.

X# SITUACION
CANTIDAD
Y#
CIUDAD


En esta relación, X# e Y# son la clave primaria de la relación, y cantidad, ciudad y
situación son los atributos de la relación que dependen funcionalmente de la clave
primaria (o de sus componentes) tal y como se indica en la figura.

Esta relación está en 1FN por definición, es decir, todos los atributos de la relación
tienen valores atómicos (no hay tablas dentro de tablas). El problema de esta relación es
que no tiene buen comportamiento respecto a las acciones de actualización (INSERT,
DELETE y UPDATE), puesto que las redundancias existentes hacen que las variaciones
que se deseen para un cierto numero de tuplas dejen la relación con un contenido
incongruente. Por ejemplo, para modificar la situación en una tupla, habrá que
modificarla en todas las tuplas donde aparezca dicha situación, puesto que de otro modo
la dependencia ciudad situación dejará de cumplirse. En general, el borrado puede
eliminar información sobre ciertas dependencias, la inserción puede generar
discordancias, y la modificación puede provocar el mismo efecto que una inserción
incorrecta.

Es obvio que esta relación no está en 2FN puesto que no todos los atributos no clave
dependen por completo de la clave primaria. De hecho, Situación y Ciudad dependen de
un componente de la clave primaria. Por tanto, para pasar a 2FN habrá que
descomponer la relación en otras relaciones más simples (y este será el procedimiento
genérico que seguiremos para pasar de unas FN a otras superiores: descomponer las
tablas, o lo que es lo mismo, realizar operaciones de proyección). En este caso, la
siguiente descomposición nos permite obtener relaciones en 2FN:

X# X# SITUACION
CANTIDAD
Y#
CIUDAD

La segunda de las relaciones separadas contiene relaciones transitivas, y por tanto,
tampoco está en 3FN. Para obtener relaciones en 3FN hay que de nuevo dividir la
relación en las siguientes relaciones:

X# CIUDAD CIUDAD SITUACION

y con esta separación ya se obtienen, definitivamente, las relaciones en 3FN.

Como detalle, hay que destacar que la última descomposición se podría haber realizado
de dos formas distintas:

• X# CIUDAD, CIUDAD SITUACION, o

• X# CIUDAD, X# SITUACION

Es evidente que en la segunda descomposición se pierde información sobre la
dependencia CIUDAD SITUACION. Por tanto, ésta sería una ‘mala’


descomposición. Habrá que obrar, por tanto, con cautela antes de decidir que tipo de
descomposición se realiza en las relaciones con transitividad.

4.3.5 Forma normal de Boyce/Codd
El problema de la 3FN es que no maneja relaciones que:

• Tiene varias claves candidatas,
• Esas claves candidatas son compuestas, y
• Las claves candidatas se traslapan (o sea, tienen por lo menos un atributo en
común).

Por ello, se define la FNBC para el caso en el que existan más de una clave candidata, y
que se cumplan dichas condiciones. Hay que introducir, por comodidad, el concepto de
determinante, que se define como el atributo del cual depende funcionalmente algún
otro atributo. Así pues, se define la FNBC como:

Una relación está en FNBC si y sólo si todo determinante es una clave candidata.

Se debe advertir que en el caso en el que no se den las condiciones anteriores, o no
exista más de una clave candidata (sólo la clave primaria) la FNBC es completamente
equivalente a la 3FN.

Dicho de otro modo, la definición implica que los únicos determinantes son las claves
candidatas, o sea, las flechas del diagrama de dependencias funcionales sólo salen de
claves candidatas.

Por ejemplo, la siguiente X# J#
relación está en FNCB,
donde se puede ver que la
existencia de varias claves Y# K#
candidatas no es necesaria-
mente mala.

Un problema serio, que no contempla la 3FN sería el siguiente diagrama DF:

X#
Z#
Y#

En este caso, la relación no está en FNBC, y sería necesario descomponerla en dos
relaciones ((X#, Z#), (Z#, Y#)), aunque las relaciones resultantes no podrían ser
independientes entre sí.

Sin embargo, en el caso en que se diese simultáneamente cualquiera de estas dos
posibles dependencias funcionales en una relación:


X# Y#
Z# X#
Y# Z#

estaríamos ante una relación en FNBC.

4.3.6 Cuarta forma normal
Existen relaciones en las que no existen dependencias entre los atributos, sin embargo la
actualización de sus campos no es tarea trivial, puesto que la representación semántica
de la relación así lo requiere. Por ejemplo, en una tabla en la que se haga constar los
profesores que imparten ciertas asignaturas y que utilizan una serie de textos como
ayuda a la enseñanza, es evidente que no habrá dependencia entre cada uno de los
atributos; sin embargo, en el caso en que se desee introducir un profesor nuevo en la
tabla, habrá que crear una fila nueva por cada asignatura que vaya a impartir, y a su vez
una fila por cada texto que se utiliza de forma común por todos los profesores de esa
asignatura.

Estamos por tanto ante una situación de patrones repetitivos en los que no existen
dependencias funcionales individuales, pero que obligan a un tratamiento poco óptimos
en las operaciones de actualización de la relación.

Para analizar este tipo de casos no podemos utilizar las dependencias funcionales que
hemos estado manejando hasta ahora. Introducimos un nuevo concepto: dependencia
multivaluada, que son una generalización de las dependencias funcionales. Por ejemplo,
en la relación de nuestro ejemplo tenemos dos dependencias multivaluadas
(ASIGNATURA ⇒ PROFESOR, y ASIGNATURA ⇒ TEXTOS), puesto que una
asignatura puede estar impartida por varios profesores, y una asignatura puede utilizar
varios textos como apoyo a la enseñanza.

Podemos dar una definición un poco más formal de dependencia multivaluada (DMV):

Dada una relación R con los atributos A, B y C, la DMV R.A ⇒ R.B se cumple en R si y
sólo si el conjunto de valores de B correspondiente a un par dado (valor de A, valor de
C) en R depende sólo del valor de A y es independiente del valor de C. Como siempre,
A, B y C pueden ser compuestos.

Es evidente que una DMV sólo puede existir en una relación que tenga por lo menos
tres atributos.

Se puede demostrar que en una relacion R(A,B,C), la DMV R.A⇒R.B se cumple si y
sólo si se cumple también la DMV R.A⇒R.C. Por tanto, se suele emplear la notación
R.A ⇒ R.B | R.C que indica esta situación.

Es ahora fácil ver que el problema mencionado con anterioridad tiene que ver con la
presencia de DMV en la relación que no son a la vez DF.


Para resolver el problema planteado es necesario descomponer las relaciones que
presentan DMV en otras relaciones más pequeñas, aplicando el teorema siguiente:

• La relación R, cuyos atributos son A, B y C, se puede descomponer sin
pérdidas en sus dos proyecciones R1(A, B) y R2(A, C) si y sólo si se
cumplen en R las dependencias multivaluadas A ⇒ B | C.

Y ahora ya podemos definir la 4FN:

Una relación R está en 4FN si y sólo si, siempre que existe una DMV en R, digamos A
⇒ B, todos los atributos de R dependen tambien funcionalmente de A

En otras palabras, las únicas dependencias funcionales o multivaluadas en R son de la
forma X K (o sea, una dependencia funcional con respecto a una clave candidata K de
algún otro atributo X). O lo que es equivalente, R está en 4FN si está en FNBC y todas
las dependencias multivaluadas de R son de hecho dependencias funcionales.

4.3.7 Quinta forma normal
Hasta ahora hemos supuesto que la única manera de normalizar consistía en la
sustitución (sin pérdidas) de una relación por dos de sus proyecciones, lo que nos ha
llevado con éxito hasta 4FN. Sin embargo, existen relaciones imposibles de
descomponer sin pérdidas en dos proyecciones, pero que sí pueden descomponerse un
tres o más proyecciones sin pérdidas. Para tratar este tipo de relaciones usaremos el
término ‘n-descomponibles’ (para n>2), lo que significa que la relación puede
descomponerse sin pérdidas en n relaciones, pero no en m (m<n).

Vamos a introducir el concepto de dependencia de reunión (DR) para indicar un cierto
tipo de restricción sobre las relaciones:

La relación R satisface la dependencia de reunión (DR) *(X, Y, …, Z) si y sólo si R es
igual a la reunión de sus proyecciones según X, Y, …, Z, donde X, Y, …, Z son
subconjuntos del conjunto de atributos de R.

Esto no es siempre cierto. Veámoslo con un ejemplo:

Sea la relación, XYZ(X#, Y#, Z#), y sus proyecciones XY(X#, Y#), YZ(Y#, Z#),
ZX(Z#, X#). La relación XYZ contiene las tuplas siguientes:

X1, Y1, Z2
X1, Y2, Z1
X2, Y1, Z1
X1, Y1, Z1

Por tanto, las proyecciones tendrán las tuplas

XY YZ ZX
X1,Y1 Y1,Z2 Z2,X1
X1,Y2 Y2,Z1 Z1,X1
X2,Y1 Y1,Z1 Z1,X2


Ahora realizamos la reunión de XY e YZ según Y#, con lo que obtenemos:

X1, Y1, Z2
X1, Y1, Z1
X1, Y2, Z1
X2, Y1, Z2
X2, Y1, Z1

y esta relación la reunimos con ZX según (X#, Y#), con lo que obtenemos la relación
original.

De alguna manera, el hecho de que la reunión de las relaciones en que hemos
descompuesto la relación original nos devuelva de nuevo esta relación, significa que la
existencia de las tuplas (a1,b1,c2), (a1,b2,c1) y (a2,b1,c1) obliga a la existencia de
(a1,b1,c1), tal y como hemos podido comprobar, puesto que la reunión hará que
aparezca indefectiblemente esta última tupla. Se puede decir que esta obligación es lo
que hemos llamado dependencia de reunión. Sin embargo, si eliminamos la última tupla
de la relación XYZ, es decir, no obligamos a que aparezca (a1,b1,c1) por el hecho de
que aparezcan las otras tres, dicha dependencia de reunión desaparece, puesto que la
reunión sí que hará aparecer esta última tupla al final, sin que aparezca en la relación
original. En este ejemplo, la relación XYZ satisface la DR *(XY, YZ, ZX).

El teorema de Fagin dice que:

R(A, B, C) satisface la DR *(AB, AC) si y sólo si satisface la pareja de dependencias
multivaluadas A ⇒ B | C.

En vista de que una DR es una generalización de una DMV, y que no todas las
relaciones que satisfacen una DR también satisfacen una DMV, además del hecho de
que las DR pueden presentar problemas de actualización en las relaciones, hemos de
definir una nueva forma normal para evitar estos problemas:

Una relación está en 5FN, también llamada forma normal de proyección/reunión
(PJ/NF), si y sólo si toda dependencia de reunión en R es una consecuencia de las
claves candidatas de R.


4.4 Diseño Físico
El rendimiento de un SGBD es la última medida en el diseño de una base de datos. Un
DBA puede mejorar el rendimiento ajustando algunos parámetros del SGBD, e
identificando cuellos de botella y problemas de hardware. Sin embargo, el primer paso
que hay que dar para obtener un buen rendimiento de la base de datos es hacer una
buena toma de decisiones en cuanto al diseño físico de la misma.

4.4.1 Introducción al diseño físico
Como cualquier otro aspecto de diseño de una base de datos, el diseño físico debe ser
definido por la naturaleza de los datos y su intención de uso. En particular, es necesario
conocer la carga que el sistema debe soportar; esta carga consiste en una serie de
consultas y actualizaciones de datos de nuestra base de datos. Además, los usuarios
suelen tener ciertos requisitos sobre la rapidez que deben tener los procesos de consulta
y actualización. La descripción de la carga y los requisitos de los usuarios sobre el
rendimiento de las consultas son la base para la toma de decisiones de un buen diseño
físico.

La descripción de la carga del sistema incluye los siguientes elementos:

• Una lista de consultas y sus frecuencias, como una fracción de todas las
consultas y actualizaciones.

• Una lista de actualizaciones y sus frecuencias.

• Objetivos de rendimiento para cada tipo de consulta y actualización.

Para cada consulta, debemos identificar:

• Las relaciones a las que accede.

• Los atributos de la cláusula SELECT.

• Los atributos en las condiciones (WHERE), y el grado de selectividad que
pueden aportar (mucha restricción, poca, etc.).

De igual forma, para cada actualización debemos tomar la siguiente información:

• Los atributos en las condiciones (WHERE) y el grado de selectividad que
pueden aportar.

• El tipo de actualización (insert, delete, update).

• En caso de UPDATE, los campos que se modifican.

Conviene tener en cuenta que las actualizaciones utilizan un parámetro para seleccionar
las tuplas que se deben actualizar. El uso de índices para estos campos puede resultar
interesante. Sin embargo, las actualizaciones conllevan una sobrecarga de actualización


de índices, con lo que actualizar campos sobre los que hay definidos índices puede
hacer más lento el proceso de actualización.

Las decisiones que hay que tomar durante el diseño físico de una base de datos son las
siguientes:

• Qué índices crear

o Qué relaciones y campos de las relaciones se indexarán
o Tipo de índice a utilizar

• Cuándo realizar cambios en el esquema conceptual para mejorar el
rendimiento:

o Normalización alternativa de esquemas, cuando se pueda llegar, por
ejemplo, a una descomposición FNBC o 3FN por caminos distintos.
o Desnormalización
o Particionado
o Vistas

4.4.2 Criterios para la selección de índices
A continuación se proporcionan una serie de criterios que ayudarán a decidir que
índices se deben crear y cómo se deben crear.

4.4.2.1 Cuando indexar

No hay que construir un índice a menos que alguna consulta se vaya a beneficiar de
dicho índice. Cuando sea posible, seleccionar un índice que pueda mejorar la velocidad
de más de una consulta.

4.4.2.2 Elección de la clave de búsqueda

Los atributos que aparecen en la cláusula WHERE son los candidatos a recibir índices

• Los atributos que se usan con criterio de búsqueda exacta pueden ser
indexados con índices de tipo hash.

• Los atributos que se usan con criterio de búsqueda en un rango pueden ser
indexados utilizando Arboles B.

4.4.2.3 Clave de búsqueda de múltiples atributos

Se deben considerar índices compuestos (de más de un atributo) cuando la cláusula
WHERE incluye condiciones sobre más de un atributo de una relación. Cuando se creen
índices de este tipo, si existen condiciones de búsqueda en rangos, hay que tener
cuidado con el orden de los atributos definido en el índice.

4.4.2.4 Contemplar el coste del mantenimiento de índices

Después de obtener un listado de los índices que sería conveniente crear, hay que
considerar el impacto que provocarán en las sentencias de actualización:


• Si el mantenimiento del índice ralentiza operaciones de actualización muy
frecuentes, habrá que considerar la eliminación del índice.

• Considerar que un índice puede acelerar el proceso de actualización, cuando
el índice se define sobre los campos que se utilizan como criterio de
selección de aquellas tuplas que se van a actualizar.

En resumen, el diseño físico de la base de datos contempla, básicamente, la creación
adecuada de índices sobre las estructuras que definen la base de datos. Hemos
proporcionado unos criterios de decisión sobre la creación de índices, y una
metodología a seguir para obtener un conjunto de índices deseable para el sistema. Pero
al mismo tiempo, hay que tener en cuenta que la creación de índices no siempre va a ser
beneficiosa para mejorar el rendimiento de nuestro sistema, y es por ello que seguir las
directrices de criterios de selección de índices de la forma más ajustada posible nos
aportará mayores beneficios y nos evitará errores en la parte del diseño físico.


Capitulo 4

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Destacado

Destacado (7)

Similar a Capitulo 4

Similar a Capitulo 4 (20)

Más de Luis Gonzales

Más de Luis Gonzales (20)

Último

Último (20)

Capitulo 4