Introducción al diseño de bases de

datos
 Jordi Casas Roma

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a

una licencia Creative Commons de tipo Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND)

v.3.0. Se puede copiar, distribuir y transmitir la obra públicamente siempre que se cite el autor y la

fuente (Fundació per a la Universitat Oberta de Catalunya), no se haga un uso comercial y ni obra

derivada de la misma. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice
 Introducción

 Objetivos

 1.Proceso de diseño de una base de datos

 2.Fases del diseño de una base de datos

o 2.1.Fase 1. Recogida y análisis de requisitos

 2.1.1.Recogida de requisitos

 2.1.2.Estructuración y refinamiento de los requisitos

 2.1.3.Formalización de los requisitos

o 2.2.Fase 2. Diseño conceptual

 2.2.1.El modelo ER

 2.2.2.El lenguaje unificado de modelización

o 2.3.Fase 3. Diseño lógico

 2.3.1.Reconsideraciones del modelo conceptual

 2.3.2.Transformación del modelo conceptual en el modelo

lógico
 2.3.3.Normalización
o 2.4.Fase 4. Diseño físico

 2.4.1.El nivel físico y el nivel virtual

 2.4.2.Transformación del modelo lógico en el modelo físico

o 2.5.Fase 5. Implementación y optimización

 2.5.1.Procesamiento y optimización de consultas

 2.5.2.Procesamiento de vistas
  2.5.3.Administración de la seguridad
 Resumen

 Glosario

 Bibliografía

Introducción
El diseño de bases de datos es un proceso complejo que permite obtener una implementación de
una base de datos a partir de los requisitos iniciales de los usuarios del sistema de información.
Este proceso guía al diseñador de bases de datos por varias etapas con el objetivo de segmentar
un problema de una complejidad considerable en diferentes subproblemas de menor
complejidad.

Cada uno de los subproblemas identificados corresponde a una de las etapas del proceso de
diseño de bases de datos. En estos materiales didácticos se describe el proceso global de diseño
de bases de datos y las diferentes etapas que lo forman. Este módulo es solo un texto
introductorio al diseño de bases de datos y será necesario profundizar en el estudio de cada una
de sus etapas mediante los distintos módulos de la asignatura que corresponden a las diferentes
etapas del proceso. Así pues, en este módulo se presenta una visión general de todo el proceso
de diseño de bases de datos.

Objetivos
En estos materiales encontraréis las herramientas indispensables para lograr los objetivos
siguientes:

1. Entender en qué consiste el diseño de bases de datos y cuáles son sus objetivos.

2. Conocer las distintas etapas que integran el proceso de diseño de una base de datos.

1.Proceso de diseño de una base de datos

El proceso de diseño de bases de datos consiste en definir la estructura lógica y física de una o
más bases de datos para responder a las necesidades de los usuarios con respecto a la
información y para un conjunto concreto de aplicaciones.

Mediante un proceso de diseño de bases de datos, se pueden decidir las tablas y relaciones que
debe tener una base de datos determinada, los atributos de las diferentes tablas, las claves
primarias y las claves foráneas que se deben declarar en cada tabla, etc. Todas estas tareas
forman parte del proceso de diseño de bases de datos. Para poder tomar estas decisiones de la
manera más correcta posible, hay que tener en cuenta las necesidades de información de los
usuarios en relación con un conjunto concreto de aplicaciones.

Por lo tanto, el diseño de una base de datos es el proceso en el que se define la estructura de los
datos que debe tener la base de datos de un sistema de información determinado.

Los requisitos que debe cumplir un sistema de información y la complejidad de la información

que se presenta en él provocan que el diseño de una base de datos sea un proceso complicado.
Para simplificar este proceso, es muy recomendable utilizar la estrategia de “divide y vencerás”
(divide and conquer).

Si aplicamos este concepto, obtenemos las diferentes etapas del diseño de bases de datos. Estas
etapas son secuenciales y el resultado de cada una sirve de punto de partida de la etapa
siguiente. El resultado de la última etapa será el diseño final de nuestra base de datos. De este
modo, un proceso de una cierta complejidad se descompone en diferentes procesos de menor
complejidad. La figura 1 muestra las distintas etapas del diseño de bases de datos.
En primer lugar, tenemos la recogida y análisis de requisitos. Esta etapa debe permitir
obtener los requisitos y las restricciones de los datos del problema. Para obtener esta
información será necesario mantener conversaciones con los diferentes usuarios de la futura
base de datos y de las aplicaciones que estén relacionadas con ésta. Sólo si se cruzan los
requisitos de los diferentes perfiles de usuarios será posible establecer un marco completo de
requisitos y las restricciones de los datos relacionados con la futura base de datos.

Dividir para vencer

La estrategia de “divide y vencerás” propone resolver un problema complejo mediante la subdivisión

en un conjunto de problemas más sencillos donde la resolución de los diferentes subproblemas implica

solucionar el problema inicial.

Figura 1. Etapas del diseño de bases de datos

A continuación, se inicia el diseño conceptual. En esta etapa se crea un esquema conceptual

de alto nivel a partir de las especificaciones y los requisitos obtenidos en la etapa anterior. En
este proceso hay que extraer las necesidades y los requisitos de la problemática y sintetizarlos
en un modelo visual de manera que permita representar los datos y las restricciones de los
conceptos que se quieren modelizar en el sistema de información. Este modelo se
denomina esquema conceptual.

Sistema gestor de bases de datos

Un sistema gestor de bases de datos (SGBD; en inglés database management system, DBMS) es un

tipo de software específico que sirve de interfaz entre la base de datos, el usuario y las aplicaciones

que la utilizan.

Hasta esta etapa del diseño de bases de datos todavía no ha sido necesario elegir el tipo de
bases de datos que se utilizará (relacional, orientada a objetos, documental, etc.) ni el sistema
gestor de bases de datos (SGBD (1) ) que se utilizará o el lenguaje concreto con el que se
implementará la base de datos.
En el momento en el que se inicia la tercera etapa del proceso de diseño, el diseño lógico, hay
que determinar el tipo de bases de datos que se utilizará. Es decir, no es necesario todavía
escoger un SGBD concreto, pero sí el tipo de bases de datos que se quiere utilizar. En esta etapa
el esquema conceptual se convierte en un esquema lógico adecuado al tipo de bases de datos
que se pretende usar.

Por tipos de bases de datos entendemos los diferentes grupos de bases de datos según el

modelo de datos que aplican. Actualmente hay varios tipos de SGBD, entre los cuales los más
utilizados son las bases de datos relacionales, orientadas a objetos, documentales, geográficas o
multidimensionales. Por ejemplo, las bases de datos relacionales son el conjunto de todos los
SGBD que aplican modelos de datos relacionales.

En este punto, y antes de iniciar la etapa de diseño físico, hay que elegir un SGBD concreto
sobre el que se pretende implementar la base de datos. La etapa de diseño físico adapta el
esquema lógico a las necesidades específicas de un SGBD concreto y, posteriormente, ajusta
algunos parámetros para el funcionamiento correcto de la base de datos. Por base de datos
concreta o SGDB concreto entendemos una aplicación concreta de bases de datos. En el caso de
bases de datos relacionales, ejemplos de SGBD concretos son Oracle Database, Mysql, SQL
Server o IBM Informix, entre otros.

Finalmente, la última etapa es la implementación y optimización de la base de datos. Esta

etapa permite cargar los datos y posteriormente permite ajustar algunos parámetros del modelo
físico y para optimizar el rendimiento de la base de datos.

Estas etapas del diseño no hay que seguirlas estrictamente de manera secuencial, y en muchos
casos es habitual rehacer el diseño de la etapa anterior a partir de necesidades detectadas en
fases posteriores. Estos bucles de retroalimentación son habituales y permiten afinar los
diseños de las distintas etapas de una manera iterativa.

El proceso que muestra la figura 1 se basa en el modelo de diseño orientado a datos. Este
modelo se centra en el diseño de los contenedores de la información y en la estructura de la
base de datos. Paralelamente a este modelo existe el modelo de diseño orientado a procesos,
que se centra en las aplicaciones de bases de datos para determinar los datos y el uso que de
estas hacen las aplicaciones. Tradicionalmente, el diseño de aplicaciones se ha basado en este
segundo modelo, pero cada vez resulta más claro que ambas actividades son paralelas y que
están estrechamente interrelacionadas. Las herramientas de diseño de bases de datos y de
aplicaciones se combinan cada vez con mayor frecuencia.

SGBD es la sigla de sistema gestor de bases de datos.

(1) 

2.Fases del diseño de una base de datos

A continuación veremos con algo más de detalle las fases que forman el proceso de diseño de
una base de datos.

2.1.Fase 1. Recogida y análisis de requisitos

La primera fase en el diseño de una base de datos consiste en conocer y analizar con detalle las
expectativas, las necesidades y los objetivos de los futuros usuarios de la base de datos. Este
proceso se denomina recogida y análisis de requisitos.

La fase de recogida y análisis de requisitos se puede dividir en tres subfases secuenciales: la

recogida de requisitos; la estructuración y el refinamiento de los requisitos, y la formalización de
los requisitos.

2.1.1.Recogida de requisitos
Para determinar los requisitos, en primer lugar hay que establecer los actores del sistema de
información que interaccionarán con la base de datos. Esto incluye a los usuarios y las
aplicaciones, tanto si son nuevos como si no lo son. Normalmente, un grupo de analistas se
encarga de hacer el análisis de requisitos y, muy probablemente, este análisis suele ser
informal, incompleto e incluso incoherente en algún punto. Por lo tanto, hay que dedicar muchos
esfuerzos a trabajar esta información y convertirla en una especificación que los diseñadores de
bases de datos puedan utilizar para modelizar e implementar el sistema de información.

En esta fase, no solo hay que recoger y analizar los requisitos referentes a la estructura o la
forma de la información (tipos de datos y relaciones entre ítems de datos), sino que hay que
capturar y analizar cualquier tipo de requisito, independientemente de qué tipo sea. Hay que
recoger, analizar y documentar cualquier requisito que los usuarios esperen de la base de datos.
Esto incluye los procesos que se deben ejecutar sobre la base de datos, las restricciones sobre
los datos, las restricciones sobre el rendimiento del sistema de información, las restricciones
relativas a la implementación (tanto en lo que respecta al hardware como en lo que se refiere al
software), requisitos de seguridad o requisitos de rendimiento (por ejemplo, tiempo de
respuesta), entre otros. Algunas de las actividades más habituales de esta fase son las
siguientes:

 Identificar los grupos de usuarios y las principales áreas de aplicación que utilizarán la
base de datos y que se verán directa o indirectamente afectados por ésta. Dentro de
cada grupo hay que elegir usuarios clave y formar comités para llevar a cabo la
recopilación y la especificación de requisitos.

 Estudiar y analizar la documentación existente relativa a las aplicaciones en uso.

 Estudiar el entorno actual y el uso que se quiere dar a la información. Esto incluye el
estudio de las entradas, el flujo y las salidas de información, además de las
frecuencias y los usos de las diferentes tareas dentro del sistema de información.

 Hacer entrevistas y encuestas a los futuros usuarios para que puedan manifestar su
opinión y sus prioridades acerca del nuevo sistema de información.

2.1.2.Estructuración y refinamiento de los requisitos

Se debe tener en cuenta que algunos de estos requisitos, muy probablemente, cambiarán
durante el proceso de diseño y que hay que estar atentos y en contacto permanente con los
usuarios de la base de datos para detectar posibles problemas. Es una buena práctica incorporar
los usuarios de la base de datos durante el proceso de desarrollo, puesto que así se incrementa
su grado de implicación y satisfacción. Hay algunas propuestas de metodologías para la recogida
y el análisis de requisitos basadas en el trabajo conjunto de los desarrolladores con los usuarios
de la base de datos, como, por ejemplo, el diseño conjunto de aplicaciones (JAD  (2) ).

JAD es la sigla de la expresión inglesa joint application design.

(2) 

2.1.3.Formalización de los requisitos

El paso siguiente es convertir los requisitos a un formato estructurado mediante técnicas de
especificación de requisitos como, por ejemplo, el análisis orientado a objetos (OOA  (3) ),
diagramas de flujo de datos (DFD (4) ) o la notación Z. Estas técnicas utilizan diferentes tipos de
recursos (diagramas, texto, tablas, gráficos, diagramas de decisión, etc.) para organizar y
representar los requisitos de manera clara.

Esta fase puede representar un coste importante dentro del proceso de diseño de una base de
datos, pero es muy importante y puede ser determinante para el éxito o el fracaso del sistema
de información. Detectar y corregir los errores o problemas en las fases iniciales del proyecto es
mucho menos costoso que arrastrar los errores hasta las fases finales, cuando corregirlos tendrá
unos costes mucho más importantes. La satisfacción del usuario final vendrá determinada por la
capacidad de recoger y captar sus necesidades e implementarlas de manera correcta en la
solución final.
 OOA es la sigla de la expresión inglesa object oriented analysis.
(3) 

DFD es la sigla de la expresión inglesa data flow diagrams.

(4) 

La notación Z

La notación Z es un lenguaje formal utilizado en ingeniería del software.

2.2.Fase 2. Diseño conceptual

La fase de diseño conceptual tiene como objetivo crear un esquema conceptual de alto nivel e
independiente de la tecnología a partir de los requisitos, las especificaciones y las restricciones
que se han recogido en la fase anterior.

En esta fase se parte de la recogida y el análisis de requisitos obtenidos en la fase anterior y

tiene como objetivo diseñar un esquema conceptual de la base de datos que sea consistente con
los requisitos, las especificaciones y las restricciones impuestas por la problemática que hay que
resolver.

Un esquema conceptual es una descripción concisa de los requisitos de datos que se expresa
mediante conceptos proporcionados por un modelo de datos de alto nivel, fácil de entender y sin
detalles de implementación. El esquema, además, debe servir de referencia para verificar que se
han agrupado todos los requisitos y que no hay ningún conflicto entre ellos.

En esta fase del diseño todavía no se considera el tipo de base de datos que se utilizará. Y, por
lo tanto, tampoco el SGBD ni el lenguaje concreto de implementación de la base de datos. En
esta etapa nos concentraremos en la estructura de la información, sin resolver de momento
cuestiones relacionadas con la tecnología.

2.2.1.El modelo ER
Hay varios modelos de datos de alto nivel que permiten modelizar los requisitos, las
especificaciones y las restricciones que se han obtenido en la primera fase del diseño de una
base de datos. Uno de los más conocidos y utilizados es el modelo entidad-interrelación, que
abreviaremos como modelo ER. Este modelo es uno de los más utilizados en el diseño
conceptual de las aplicaciones de bases de datos, principalmente, debido a su simplicidad y
facilidad de uso.

Los principales elementos que incluye el modelo son los tipos de entidad, los atributos y los tipos
de relaciones entre entidades. El objetivo principal del modelo ER es permitir a los diseñadores
reflejar en un modelo conceptual los requisitos del mundo real que sean de interés para el
problema. El modelo ER facilita el diseño conceptual de una base de datos y, como ya hemos
comentado, es aplicable al diseño de cualquier tipo de bases de datos.

Modelo ER

En inglés se denomina entity-relationship model. Dada la ambigüedad de la traducción, en español

encontramos autores que lo traducen como modelo entidad-relación y otros que lo traducen

como modelo entidad-interrelación. Ambos conceptos se refieren al mismo modelo.

2.2.2.El lenguaje unificado de modelización

El lenguaje unificado de modelización (UML) es un lenguaje gráfico diseñado para especificar,
visualizar, modificar, construir y documentar un sistema. El lenguaje UML incorpora una gran
cantidad de diagramas que permiten representar el modelo de un sistema desde perspectivas
diferentes. En relación con el diseño conceptual de bases de datos, nos interesa especialmente el
diagrama de clases, que permite representar información del dominio de discurso. Los
diagramas de clases son diagramas estáticos que describen la estructura de un sistema a partir
de las clases o tipos de entidad del sistema, sus atributos y las asociaciones o tipos de relaciones
que se establecen entre ellos. Estos diagramas han mostrado una capacidad excelente para la
modelización de datos. Por este motivo, son cada vez más importantes en el diseño conceptual
de bases de datos.

Lenguaje UML

El lenguaje unificado de modelización (en inglés, unified modeling language) es un lenguaje de

propósito general para modelizar sistemas de software. Este estándar fue creado, y actualmente es

mantenido, por el Object Management Group (OMG).

2.3.Fase 3. Diseño lógico

Previamente a la fase de diseño lógico, se debe elegir un tipo de base de datos. Es decir, no hay
que escoger todavía un SGBD concreto, sino que simplemente hay que seleccionar el tipo de
base de datos que se quiere implementar. Es importante que quede claro que el tipo de base de
datos determina el esquema de diseño lógico. Una vez elegido el tipo de SGBD donde se quiere
implementar la base de datos, ya se puede iniciar la fase del diseño lógico.

En la fase de diseño lógico se transforma el modelo conceptual, independiente del tipo de

tecnología, en un modelo lógico dependiente del tipo de SGBD en el que se quiere implementar
la base de datos.

En esta etapa se parte del diseño conceptual desarrollado en el paso anterior y se obtiene un
diseño lógico de la futura base de datos. En esta transformación se ajusta el modelo
considerando el tipo de SGBD en el que se quiere implementar la base de datos. Por ejemplo, si
se quiere crear la base de datos en un sistema relacional, esta etapa obtendrá un conjunto de
relaciones con sus atributos, sus claves primarias y sus claves foráneas correspondientes.

En esta etapa nos concentramos en las cuestiones tecnológicas relacionadas con el modelo de la
base de datos, asumiendo que en la etapa anterior ya hemos resuelto la problemática de
estructuración de la información desde el punto de vista conceptual.

Por lo tanto, el resultado de esta etapa será un modelo lógico de la estructura de la información.
Generalmente, cuando este modelo lógico hace referencia a un SGBD relacional, se
denomina modelo relacional. En este material nos centraremos en la transformación del modelo
conceptual a un modelo relacional, es decir, a un modelo lógico para una base de datos
relacional.

En el diseño lógico se pueden ver tres subfases o partes independientes, que se aplican de
manera secuencial para transformar el modelo conceptual obtenido en la fase anterior en un
modelo lógico que será el resultado de esta fase. En primer lugar, en la subfase
llamada reconsideraciones del modelo conceptual revisamos el modelo conceptual para
asegurarnos de que está libre de algunos errores tipificados e identificables. A continuación, se
produce la transformación del modelo conceptual en el modelo lógico y, finalmente, aplicamos la
teoría de la normalización al modelo lógico.

2.3.1.Reconsideraciones del modelo conceptual

En esta primera parte se realiza un análisis en profundidad del modelo conceptual obtenido en la
fase anterior, con la intención de detectar y corregir algunos errores que se suelen producir en
los modelos conceptuales y que conviene detectar y reparar lo antes posible para evitar que se
propaguen en fases posteriores. Dichos errores se denominan trampas de diseño. Es
conveniente conocer cada uno de estos errores y asegurarse de que el modelo conceptual que se
quiere transformar está libre de ellos antes de continuar con el diseño lógico.

2.3.2.Transformación del modelo conceptual en el modelo lógico

En estos materiales nos centraremos en el diseño lógico de bases de datos relacionales. Por lo
tanto, el modelo lógico generado será aplicable a cualquier base de datos relacional. Partiremos
del resultado de la etapa del diseño conceptual expresado mediante un diagrama de clases UML
y veremos cómo se puede transformar utilizando una estructura de datos del modelo relacional.
Este proceso muestra la manera de llevar a cabo la transformación de los diferentes elementos
que forman el modelo conceptual en elementos que constituyen el modelo lógico o, más
concretamente, el modelo relacional.

El modelo relacional

El modelo relacional es el modelo lógico específico para bases de datos relacionales.

2.3.3.Normalización
La teoría de la normalización aplica la teoría de conjuntos, la lógica y el álgebra relacional para
formalizar un conjunto de ideas simples, que guían un buen diseño de bases de datos
relacionales.

La teoría de la normalización utiliza las formas normales (FN) para reconocer los casos en los
que no se aplican buenos criterios de diseño. Una relación está en una forma normal
determinada si satisface un conjunto de restricciones específicas que son propias de esta forma
normal. La infracción de estas restricciones origina que la relación tenga un conjunto de
anomalías y redundancias de actualización no deseables. Las formas normales son declarativas,
es decir, cada forma normal indica las restricciones que se deben cumplir, pero no describe
ningún procedimiento para conseguirlo.

2.4.Fase 4. Diseño físico

Previamente a la fase de diseño físico hay que elegir un SGBD concreto. Hay que estudiar los
diferentes sistemas comerciales o libres que hay en el mercado y seleccionar un SGBD donde se
pueda implementar el sistema de información que se ha ido gestando en las fases anteriores del
proceso de diseño.

Los componentes físicos que forman cada SGBD son específicos. Los fabricantes utilizan
estrategias y tecnologías diferentes para maximizar el rendimiento de sus sistemas gestores de
bases de datos. En este nivel no existe ningún estándar y, por lo tanto, habrá que adaptar el
esquema lógico obtenido en el paso anterior, teniendo presentes las características de cada
sistema gestor. El diseñador debe considerar los aspectos de implementación física y de
eficiencia que dependen específicamente del SGBD elegido.

El diseño físico es una fase del proceso de diseño de bases de datos que adapta el esquema
lógico obtenido en la fase anterior al SGBD concreto, que utilizará el sistema de información.

2.4.1.El nivel físico y el nivel virtual

El estudio de los niveles físico y virtual de las bases de datos permite ver aspectos como las
estructuras de almacenamiento y las rutas de acceso por los ficheros de la base de datos. Cada
SGBD ofrece diferentes opciones para organizar ficheros y rutas de acceso, y es necesario que el
diseñador conozca la implementación concreta, con el fin de implementar de una manera más
eficiente el diseño físico del sistema de información.

También es importante conocer las características de los procesos que consultan y actualizan la
base de datos, como por ejemplo las frecuencias de ejecución y los volúmenes que se espera
tener de los diferentes datos que se quieren almacenar con el fin de conseguir un buen
rendimiento de la base de datos.

Algunos criterios importantes que pueden ser útiles para elegir las opciones de diseño físicas de
la base de datos son los siguientes:
  Tiempo de respuesta. Es el tiempo que transcurre desde que se envía una petición al
SGBD hasta que éste devuelve los datos de la respuesta. Una parte importante de
este tiempo está bajo el control del SGBD y hace referencia al tiempo de acceso por
parte del SGBD a los datos requeridos para generar la respuesta. Otros aspectos no
son controlados por el SGBD, como por ejemplo la planificación del sistema operativo
o los tiempos de acceso a los medios físicos de almacenamiento de los datos.

 Uso del espacio. Es la cantidad de espacio de disco utilizado por los ficheros de la base
de datos y las estructuras de rutas de acceso al disco, incluyendo índices y otras rutas
de acceso.

 Rendimiento. Es la cantidad media de transacciones que se pueden procesar en un

minuto de tiempo. Este factor puede ser crítico para sistemas transaccionales, como
por ejemplo líneas aeronáuticas o entidades bancarias.

2.4.2.Transformación del modelo lógico en el modelo físico

En este paso se transforma el modelo lógico de una base de datos en un modelo físico, según el
SGBD elegido para implementar el sistema de información, las características concretas del
hardware utilizado y el sistema operativo y el software básico. Cada SGBD ha desarrollado un
lenguaje propio, hecho a medida por el constructor mismo, para implementar el diseño físico de
la base de datos, de acuerdo con las características del entorno, y para obtener el máximo
rendimiento del hardware, del sistema operativo y del propio gestor. En realidad, se podría
considerar una ampliación del lenguaje SQL estándar con las cláusulas propias que cada gestor
necesita para definir los componentes del diseño físico. Sin embargo, existe un gran parecido o
equivalencia entre una parte importante de los diferentes gestores.

El estándar SQL incorpora la definición de todos los componentes del diseño lógico de la base de
datos. En cambio, no contiene ningún elemento del diseño físico.

Para transformar el diseño lógico de la base de datos en un SGBD concreto, partimos de las
definiciones de tablas (con toda la información relacionada; es decir, atributos, claves primarias,
claves foráneas y claves alternativas). A continuación se relaciona cada elemento con un espacio
adecuado en el nivel virtual y finalmente se relaciona cada espacio virtual con un fichero físico,
que constituye el nivel físico del sistema de información.

2.5.Fase 5. Implementación y optimización

La última etapa es la implementación y la optimización de la base de datos.

La etapa de implementación y optimización consiste en realizar la carga de los datos y

posteriormente ajustar algunos parámetros relacionados con el modelo físico de la base de datos
para optimizar el rendimiento.

El objetivo principal de esta etapa es optimizar el rendimiento de la base de datos. En primer

lugar, hay que realizar la carga de los datos, puesto que no es posible optimizar el acceso a los
datos sin poder determinar el tamaño de las tablas, los tipos de accesos y consultas, la
frecuencia de éstos, etc.

Finalmente, también habrá que concretar los diferentes roles de usuarios y aplicaciones para
poder determinar los permisos de los diferentes grupos. El componente de gestión de la
seguridad y las vistas permiten limitar los accesos y de este modo reducir el riesgo de problemas
derivados de accesos no autorizados.

2.5.1.Procesamiento y optimización de consultas

El lenguaje SQL empleado por las bases de datos relacionales es un lenguaje declarativo. Esto
implica que se especifica el resultado que se quiere obtener a partir de una consulta realizada,
en lugar de determinar el algoritmo o el método que hay que usar para obtener el resultado. Por
lo tanto, es necesario entender el conjunto de tareas que realizan los SGBD relacionales para
obtener la respuesta deseada.

Los SGBD relacionales evalúan sistemáticamente las posibles estrategias alternativas que se
pueden presentar, con el objetivo de elegir la que se considera óptima. El procesamiento de
consultas recoge todo el conjunto de actividades realizadas por el SGBD, que tienen como
objetivo la extracción de información de la base de datos para lograr la estrategia más eficiente
y proporcionar un mejor rendimiento del sistema de información.

El procesamiento de consultas se puede dividir en las cuatro etapas principales siguientes:

1) Descomposición de la consulta. Traducción de la consulta expresada en lenguaje SQL a

una representación interna basada en el álgebra relacional.

2) Optimización de la consulta. Proceso de selección del plan de ejecución de la consulta más

eficiente entre las muchas estrategias generalmente disponibles en el procesamiento de una
consulta. La optimización de consultas se puede realizar sobre tres vertientes:

a) Optimización semántica basada en las restricciones especificadas en el esquema de la base

de datos.

b) Optimización sintáctica, que consiste en transformar heurísticamente la expresión relacional

original en otra equivalente pero que sea mucho más eficiente.

c) Optimización física, con el objetivo de elegir entre los distintos planes de evaluación –que
pueden tener costes diferentes– el que sea más eficiente. Para determinar el coste más eficiente
hay que conocer el coste de cada operación, que a menudo depende de diferentes parámetros.

3) Generación de código.

4) Ejecución de la consulta.

Es el proceso de optimización de consultas, es decir, el tratamiento que da un SGBD a las

consultas hechas por los usuarios mediante SQL. Este punto es uno de los más importantes que
se deben tener en cuenta cuando se diseña un SGBD relacional, puesto que la opción elegida
afecta directamente al rendimiento global del sistema.

La optimización de consultas es un aspecto muy importante que hay que considerar cuando se
diseña y se construye un SGBD relacional. Las técnicas que se utilizan para optimizar consultas
condicionan el rendimiento global del sistema, puesto que determinan el tiempo que necesita el
sistema gestor para resolver las consultas que han hecho los usuarios.

2.5.2.Procesamiento de vistas
Una vista es una tabla lógica que permite acceder a la información de una o varias tablas
mediante una consulta predefinida. No contiene información por sí misma, sino que se basa en
información de otras tablas. Las vistas proporcionan mecanismos de seguridad y permiten al
diseñador de la base de datos personalizar la vista que tienen los diferentes usuarios de la base
de datos.

Hacer un uso adecuado de las vistas es un aspecto clave para lograr un buen diseño de una base
de datos, puesto que nos permite ocultar los detalles de las tablas y mantener la visión del
usuario independientemente de la evolución que tenga la estructura de tablas.

Las vistas habían sido durante mucho tiempo un simple mecanismo de simplificación de
consultas, pero actualmente tienen una importancia capital en varias áreas, como el diseño
externo, los almacenes de datos (5) o la informática distribuida.

En inglés, data warehouse.
(5) 
2.5.3.Administración de la seguridad
Por último, hay que tener en cuenta las técnicas que se emplean para proteger la base de datos
contra accesos no autorizados y los mecanismos para asignar y revocar privilegios a los
diferentes usuarios. De estas y otras acciones se encarga el componente de seguridad del SGBD.
Este componente viene siendo cada día más importante, dado que en la actualidad una gran
cantidad de ordenadores y otros tipos de dispositivos están interconectados y, por lo tanto,
cualquier persona podría convertirse en usuario, y posible atacante, de una base de datos.

En muchas organizaciones, la información es un activo intangible y de naturaleza sensible, que

tiene un valor muy importante. Para preservar esta información hay que proteger el sistema de
información y conocer las obligaciones legales que hay que cumplir.

Resumen
En este módulo hemos visto, de una manera muy general, el proceso de diseño de una base de
datos.

Hemos introducido, aunque muy brevemente, las distintas etapas que forman el proceso de
diseño de una base de datos. Abordaremos este tema en detalle en el resto de los módulos de la
asignatura.

El proceso de diseño de una base de datos se inicia con la fase de recogida y análisis de
requisitos, lo cual permite recoger y centralizar las necesidades de los diferentes grupos de
usuarios y aplicaciones. A partir de este análisis, en la segunda fase, se modeliza un esquema
conceptual que permite describir el modelo de datos de una manera independiente de la
tecnología.

La etapa siguiente en este proceso es el diseño lógico, que requiere haber elegido previamente
el tipo de base de datos que se quiere utilizar en la implementación del sistema de información.
El tipo de base de datos determina el modelo lógico que va a desarrollarse. Por ejemplo, en el
caso de utilizar un tipo de base de datos relacional, se transforma el modelo conceptual en un
modelo lógico específico para bases de datos relacionales denominado modelo relacional.

El diseño físico permitirá adaptar el modelo lógico a un sistema gestor de bases de datos (SGBD)
concreto. Por lo tanto, previamente a este paso se deberá escoger el SGBD específico que se
quiere utilizar para implementar el sistema de información. En esta etapa se crea la estructura
física que almacenará los datos de la base de datos.

Para terminar, la última etapa permite la optimización de la base de datos y la gestión de la

seguridad relacionada con los usuarios y las aplicaciones de la base de datos. Lógicamente,
habrá que realizar la carga de los datos previamente, puesto que el tamaño de las tablas, los
tipos de consultas y las frecuencias de estas son elementos importantes para optimizar el acceso
a los datos por parte del sistema gestor.

Glosario
database management system f
Véase sistema gestor de bases de datos.
sigla DBMS

divide and conquer loc

Véase divide y vencerás.

divide y vencerás loc
 Estrategia que propone resolver un problema complejo mediante la subdivisión en un
conjunto de problemas más sencillos cuya resolución implica resolver el problema inicial.
en divide and conquer

entity relationship model m

Véase modelo ER.

lenguaje unificado de modelización m

Lenguaje de propósito general para modelizar sistemas de software. El estándar fue
creado, y actualmente es mantenido, por el Grupo de Gestión de Objetos.
en unified modeling language
sigla UML

modelo ER m
Modelo entidad-interrelación de datos de alto nivel que permite modelizar los requisitos,
las especificaciones y las restricciones.
en entity-relationship model

SGBD m
Véase sistema gestor de bases de datos.

sistema gestor de bases de datos m

Tipo de software específico que sirve de interfaz entre la base de datos, el usuario y las
aplicaciones que la utilizan.
en database management system
sigla SGBD

UML m
Véase lenguaje unificado de modelización.

Bibliografía
Elmasri, Ramez; Navathe, Shamkant, B. (2007). Fundamentos de sistemas de bases de
datos (5.ª ed.). Madrid: Pearson Educación.

Ramakrishnan, Raghu; Gehrke, Johannes (2003). Database management systems (3.ª ed.).

Boston: McGraw-Hill Higher Education.
Diseño conceptual de bases de
datos
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a

una licencia Creative Commons de tipo Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND)

v.3.0. Se puede copiar, distribuir y transmitir la obra públicamente siempre que se cite el autor y la

fuente (Fundació per a la Universitat Oberta de Catalunya), no se haga un uso comercial y ni obra

derivada de la misma. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice
 Introducción

 Objetivos

 1.Introducción al diseño conceptual

o 1.1.El diseño conceptual

 1.1.1.Metodologías de diseño

 1.1.2.Estrategias de diseño
o 1.2.El modelo ER

o 1.3.El lenguaje UML

 2.Elementos básicos de modelización

o 2.1.Tipos de entidades

o 2.2.Atributos

 2.2.1.Representación de los atributos

 2.2.2.Dominio de los atributos

 2.2.3.Atributos compuestos y atributos atómicos

 2.2.4.Atributos monovalor y atributos multivalor

 2.2.5.Atributos derivados

 2.2.6.El valor NULL

o 2.3.Claves

o 2.4.Tipos de relaciones

 2.4.1.Tipos de relaciones binarias

 2.4.2.Tipo de relaciones ternarias

 2.4.3.Tipos de relaciones n-arias

 2.4.4.Tipos de relaciones reflexivas o recursivas

o 2.5.Tipos de entidades asociativas
 o 2.6.Tipos de entidades débiles

o 2.7.Opciones de diseño

o 2.8.Criterios de asignación de nombres

o 2.9.Ejemplo completo

 3.Elementos avanzados de modelización

o 3.1.Generalización/especialización

 3.1.1.Restricciones en la generalización/especialización

 3.1.2.Herencia simple y múltiple

 3.1.3.Clasificación múltiple
o 3.2.Agregación y composición

o 3.3.Restricciones de integridad

 3.3.1.Restricciones en los tipos de entidad

 3.3.2.Restricciones en los atributos

 3.3.3.Restricciones en los tipos de relaciones

 3.3.4.Otras restricciones
o 3.4.Modelización de datos históricos

o 3.5.Ejemplo completo

 Resumen

 Glosario

 Bibliografía

Introducción
El diseño conceptual de bases de datos es la segunda etapa después del análisis de requisitos en
el proceso de diseño de una base de datos. El diseño conceptual permite crear un esquema
conceptual de alto nivel e independiente de la tecnología de implementación a partir de las
especificaciones y los requisitos de un problema del mundo real. Durante este proceso hay que
extraer las necesidades y los requisitos de los problemas planteados con el fin de sintetizar en
un modelo visual la representación de los datos y las restricciones de los conceptos que se
desean representar en el sistema de información.

En esta etapa se obtiene una estructura de la información independiente de la tecnología.

Todavía no se tiene en cuenta qué tipo de base de datos se utilizará (relacional, orientada a
objetos, etc.), ni el sistema gestor de bases de datos que se utilizará o el lenguaje concreto que
se implementará en la base de datos. Sin embargo, en esta etapa el foco de atención se centra
en la estructura de la información, y se dejan por resolver las cuestiones ligadas a la tecnología.

El objetivo de esta etapa es elaborar un modelo conceptual del problema. Este modelo se
representa mediante algún modelo de datos de alto nivel. Uno de los modelos más conocidos es
el modelo entidad-interrelación (modelo ER). Dicho modelo ha tenido una gran relevancia hasta
nuestros días, aunque actualmente el uso del lenguaje unificado de modelización (UML) ha
tomado una gran fuerza en todos los ámbitos de la computación. Inicialmente, este último se
desarrolló para modelizar sistemas de software, pero la potencia y la flexibilidad que tiene lo han
convertido en un lenguaje ideal para otros ámbitos de la computación.

Concretamente, en este módulo explicaremos los principios del diseño conceptual y la aplicación
de este diseño mediante diagramas en lenguaje UML.
Objetivos
En los materiales didácticos de este módulo encontraréis las herramientas indispensables para
lograr los objetivos siguientes:

1. Conocer los fundamentos del diseño conceptual de bases de datos.

2. Entender los elementos básicos de modelización como mecanismo de representación

conceptual de datos.

3. Estudiar los diagramas de clases UML como herramienta para representar modelos de
datos.

4. Ser capaces de leer y entender diagramas de modelos conceptuales de bases de

datos.

5. Aprender a modelizar, mediante diagramas UML, las necesidades de un sistema de

información a partir de una descripción de los requisitos iniciales.

1.Introducción al diseño conceptual

El diseño conceptual es la segunda etapa en el proceso de diseño e implementación de una base
de datos, y sigue a la etapa inicial de recopilación y análisis de requisitos. El objetivo del diseño
conceptual es crear un esquema conceptual para la base de datos mediante un modelo de datos
conceptual de alto nivel e independiente de la tecnología a partir del análisis de requisitos.

Un esquema conceptual es una descripción concisa de los requisitos de datos por parte de los
usuarios e incluye descripciones detalladas de las entidades que están involucradas, las
relaciones entre estas entidades y las restricciones de integridad que tienen. Se expresa
mediante conceptos proporcionados por un modelo de datos de alto nivel, que debe ser fácil de
entender y no debe contener detalles de implementación.

1.1.El diseño conceptual

La etapa de diseño conceptual parte de la recopilación y el análisis de requisitos obtenido en la
etapa previa con la ayuda de los futuros usuarios de la base de datos, y tiene como objetivo
conseguir un esquema conceptual de la base de datos que sea consistente con los requisitos y
las restricciones impuestas por los problemas que hay que resolver.

El esquema conceptual, además, debe servir como referencia para verificar que se han
considerado todos los requisitos y que no hay conflicto entre ellos. Si algunos de los requisitos
iniciales no se pueden representar gráficamente en el modelo conceptual, deben añadirse de
manera textual, para asegurarnos de que quedan recogidos en el modelo conceptual y de que se
tendrán en cuenta en las fases siguientes del diseño de la base de datos. Hay diferentes
lenguajes para representar modelos conceptuales de datos. Algunas características importantes
para representar modelos conceptuales de datos son estas:

 Expresividad: el modelo debe ser suficientemente expresivo para permitir representar

los diferentes conceptos del mundo real y las asociaciones entre estos conceptos.

 Simplicidad: el modelo debe ser simple. Ha de permitir a los usuarios de la base de

datos entender los conceptos que se expresan.

 Representación diagramática: el modelo debe utilizar una notación diagramática fácil

de entender y útil para visualizar el esquema conceptual.
  Formalidad: la representación del modelo debe ser precisa, formal y no puede
presentar ambigüedades.

Satisfacer estas características no es fácil y a menudo algunas características entran en conflicto

con las demás.

Además de las características comentadas, hemos dicho que un esquema conceptual es una
descripción de alto nivel e independiente de la tecnología. Estas dos características son
importantes para un lenguaje que permita definir un modelo conceptual. Hay muchas razones
que destacan estas dos características como importantes en el modelo conceptual, entre las
cuales se pueden señalar las siguientes:

 El uso del modelo conceptual permite a los diseñadores de bases de datos concentrarse
en expresar las propiedades, las asociaciones y las restricciones de los datos sin
preocuparse de los detalles de implementación y con independencia de las
particularidades de los diferentes sistemas gestores de bases de datos (SGBD  (1) ).

 El esquema conceptual se convierte en un elemento de descripción estable del contenido

de la base de datos.

 Un modelo de alto nivel independiente de las tecnologías específicas de cada SGBD

permite más expresividad y un carácter más general.

 El modelo se puede utilizar como vehículo de comunicación entre los usuarios, los
diseñadores y los analistas de la base de datos.

SGBD es la sigla de sistema gestor de bases de datos.

(1) 

1.1.1.Metodologías de diseño
A partir de los requisitos recopilados y trabajados en la primera fase del proceso de diseño de
una base de datos se pueden establecer dos metodologías básicas para el diseño conceptual de
bases de datos:

1) Metodología centralizada (one shot): en esta primera metodología se fusionan todos los

requisitos de los distintos grupos de usuarios y aplicaciones recopilados en la primera fase en un
solo conjunto antes de empezar la fase de diseño. A partir de este único conjunto de requisitos
se desarrolla un único esquema conceptual para toda la base de datos.

2) Metodología de integración de vistas: en esta metodología se construye un esquema

(denominado vista) para cada conjunto de requisitos de cada grupo de usuarios y se validan de
manera independiente. Posteriormente, en una subfase llamada integración de vistas hay que
fusionar los diferentes esquemas o vistas en un único esquema conceptual global para toda la
base de datos.

La metodología de integración de vistas permite crear esquemas conceptuales más pequeños

que son validados por los diferentes grupos de usuarios de la base de datos, pero añade la
subfase de integración de vistas para unificar los diferentes esquemas. Además, esta subfase
añade una complejidad notable y requiere una metodología y unas herramientas específicas para
poder llevarse a cabo de manera correcta. Generalmente, esta metodología se suele aplicar al
diseño de grandes bases de datos.

En este material nos centraremos en la metodología centralizada.

1.1.2.Estrategias de diseño
A partir de un conjunto de requisitos, recopilados para un único usuario o para un conjunto de
ellos, hay que diseñar un esquema conceptual que los satisfaga. Para llevar a cabo esta tarea, se
pueden utilizar diferentes estrategias. La mayoría utilizan un método incremental, es decir,
empiezan por modelizar algunas estructuras principales derivadas de los requisitos y las van
modificando y refinando en diferentes iteraciones del mismo proceso.

Algunas de las estrategias más utilizadas para el diseño conceptual de bases de datos son las
siguientes:

a) Estrategia descendente: se empieza el proceso con un esquema que contiene

abstracciones de alto nivel y se van aplicando sucesivamente refinamientos sobre estas
abstracciones.

b) Estrategia ascendente: se empieza el proceso con un esquema que contiene los detalles de
las abstracciones y se van combinando de manera sucesiva formando conjuntos de más entidad
o conceptos complejos.

c) Estrategia de dentro hacia fuera: es un caso concreto de la estrategia ascendente. Esta

estrategia centra la atención en un conjunto central de conceptos que son muy evidentes y,
poco a poco, incluye en el esquema nuevos conceptos relacionados directamente con los
conceptos existentes.

d) Estrategia mixta: esta estrategia divide los requisitos según una estrategia descendente y
entonces construye cada una de las divisiones siguiendo una estrategia ascendente. Finalmente
se combinan las partes para generar el esquema completo.

1.2.El modelo ER
El modelo entidad-interrelación, o modelo ER, es un modelo conceptual de datos de alto
nivel e independiente de la tecnología. Este modelo y las variaciones que tiene constituyen los
modelos más utilizados por el diseño conceptual de las aplicaciones de bases de datos. Esto se
debe, principalmente, a la simplicidad y la facilidad de uso. Los principales elementos que
incluye el modelo son las entidades, los atributos y las relaciones entre entidades.

El objetivo principal del modelo ER es permitir a los diseñadores reflejar en un modelo

conceptual los requisitos del mundo real que sean de interés para el problema.

Este modelo facilita el diseño conceptual de una base de datos y es aplicable al diseño de
cualquier tipo de bases de datos (relacionales, orientadas a objetos, etc.), ya que en la etapa del
diseño conceptual no se tiene en cuenta todavía la tecnología concreta que se empleará para
implementar la base de datos.

Modelo ER

El nombre original proviene de la lengua inglesa, en la que las siglas ER significan entity-relationship.

En español encontramos autores que lo traducen como modelo entidad-relación y otros que lo

traducen como modelo entidad-interrelación. Ambos se refieren al mismo modelo.

El modelo ER tiene el origen en los trabajos hechos por Peter Chen en 1976. Posteriormente,
otros muchos autores han propuesto variantes y ampliaciones para este modelo. Por lo tanto, en
la literatura se pueden encontrar variaciones en el modelo ER que pueden diferir simplemente en
la notación diagramática o en algunos conceptos en los que se basan para modelizar los datos.

El modelo ER permite reflejar aspectos relacionados con la estructura de los datos y de la

integridad de estos datos.

Para representar el modelo ER se ha empleado tradicionalmente el diagrama entidad-

interrelación, o diagrama ER. Este diagrama define una nomenclatura específica para
representar los diferentes conceptos de entidades y relaciones que requiere el modelo. A pesar
del amplio uso de este diagrama, últimamente se tiende a emplear el lenguaje UML para
representar el modelo ER. En este texto utilizaremos el lenguaje UML. No obstante, hay que
tener en cuenta que los conceptos son los mismos y solo cambia la manera de representar los
conceptos relacionados con las entidades, los atributos o las relaciones.

Peter Pin-Shan Chen

Es científico y profesor de informática en la Universidad Estatal de Luisiana. Obtuvo el grado de doctor

en la Universidad de Harvard en 1973. Posteriormente, en 1976, desarrolló el modelo ER, hecho por el

que es conocido.

1.3.El lenguaje UML

El lenguaje unificado de modelización (2) (UML) es un lenguaje de propósito general para
modelizar sistemas de software. El estándar fue creado y es mantenido por, el Object
Management Group. Se añadió por primera vez a la lista de tecnologías empleadas por el OMG
en 1997 y desde entonces se ha convertido en el estándar de la industria para modelizar
sistemas de software.

UML es un lenguaje gráfico diseñado para especificar, visualizar, modificar, construir y

documentar un sistema. Permite una visualización estándar de diferentes artefactos, entre otros,
actividades, actores, lógicas de negocio y esquemas de bases de datos.

El lenguaje UML lo desarrolló la compañía Rational Software Corporation durante los años
noventa. Después de un periodo en el que coexistieron diferentes tendencias en la modelización
orientada a objetos, la compañía unificó los esfuerzos de tres pioneros en esta área: James
Rumbaugh, Grady Booch e Ivar Jacobson. En 1996 se creó el consorcio UML Partners con el
objetivo de completar la especificación de UML. En enero de 1997 se publicó la versión 1.0 de
UML. Durante el mismo año se publicó la versión 1.1, que aceptó y adoptó el consorcio OMG.
Finalmente, la versión 2.0 se publicó en el 2005. En el momento de escribir este material, la
última versión es la 2.3, publicada en mayo del 2010.

El lenguaje UML incorpora una gran cantidad de diagramas que permiten representar el modelo
de un sistema desde diferentes perspectivas. Podemos encontrar diagramas que hacen
referencia a la estructura (por ejemplo, diagramas de clase, diagramas de componentes o
diagramas de paquetes), diagramas referentes al comportamiento (por ejemplo, diagramas de
actividad o diagramas de casos de uso) o diagramas referentes a la interacción (por ejemplo,
diagramas de comunicación o diagramas de secuencia).

UML define nueve tipos de diagramas divididos en dos categorías:

 Diagramas estructurales: describen las relaciones estructurales o estáticas entre los

diferentes componentes del sistema.

 Diagramas de comportamiento: describen las relaciones de comportamiento o

dinámicas entre los diferentes componentes del sistema.

En inglés, unified modeling language (UML).

(2) 

Object Management Group

El Object Management Group (OMG) es un consorcio dedicado a establecer y promover varias

especificaciones de tecnologías orientadas a objetos, como UML, XMI o CORBA. Es una organización

sin ánimo de lucro que promueve el uso de la tecnología orientada a objetos mediante guías y

especificaciones para estas guías.

Para el diseño conceptual de bases de datos nos interesa especialmente el diagrama de clases,
que permite representar información del dominio de discurso. Aun así, a continuación veremos
una breve descripción de cada uno de estos diagramas, a pesar de que el alcance de los
diferentes diagramas UML cae fuera de los objetivos de este texto.

Diagramas estructurales:

a) Los diagramas de clases son diagramas estáticos que describen la estructura de un sistema

a partir de las clases del sistema, los atributos de este sistema y las relaciones que se
establecen entre éstas (también conocidas como asociaciones en terminología UML). Estos
diagramas son uno de los principales bloques en el desarrollo orientado a objetos, pero también
han demostrado una capacidad excelente para modelizar datos. Por este motivo, han sido cada
vez más importantes en el diseño conceptual de bases de datos.

b) Los diagramas de objetos muestran las instancias (u objetos del mundo real) y las

relaciones entre estas en un momento concreto. Las instancias de un sistema se modifican a lo
largo de tiempo, es decir, se crean instancias nuevas, se destruyen instancias y se modifican
ciertos valores de determinadas instancias. Por lo tanto, los diagramas de objetos son como una
fotografía que muestra una vista estática de las diferentes instancias de un sistema y de las
relaciones entre estas instancias en un instante de tiempo determinado.

Dominio del discurso

El dominio del discurso, universo del discurso, o simplemente dominio, es el conjunto de cosas de las

que se habla en un determinado contexto.

c) Los diagramas de componentes ilustran las organizaciones y las dependencias entre los

componentes del sistema. En entornos de bases de datos se utilizan para modelizar los espacios
de tabla o las particiones.

d) Los diagramas de implantación representan la distribución de componentes del sistema y

su relación con los componentes del hardware disponible.

Diagramas de comportamiento:

a) Los diagramas de casos de uso se utilizan para modelizar las interacciones funcionales

entre los usuarios y el sistema.

b) Los diagramas de secuencia describen las interacciones entre distintos objetos en el

transcurso del tiempo. Muestran el flujo temporal de mensajes entre varios objetos.

c) Los diagramas de colaboración representan las interacciones entre objetos como una serie

de mensajes en secuencia. Estos diagramas centran la atención en la organización estructural de
los objetos que envían y reciben mensajes.

d) Los diagramas de estado describen cómo cambia el estado de un objeto en respuesta a

diferentes acontecimientos externos.

e) Los diagramas de actividad presentan una vista dinámica del sistema y modelizan el flujo

de control de actividad a actividad.

Los espacios de tabla (tablespaces) se ven en el subapartado 5.2 del módulo “Diseño físico de bases

de datos” de esta asignatura.

2.Elementos básicos de modelización

Un modelo conceptual permite definir información de dominio a partir de tipos de entidades,
tipos de relaciones, atributos y restricciones de integridad.

2.1.Tipos de entidades
Entendemos por entidad un objeto del mundo real, que tiene identidad propia y que es
distinguible del resto de los objetos.

Las entidades pueden ser objetos con existencia física (por ejemplo, un coche o una persona) u
objetos con existencia conceptual (por ejemplo, un trabajo o una asignatura de un curso
universitario).

Ejemplos de entidades

Algunos ejemplos de entidad son una manzana, un coche o una persona. Otros ejemplos, que no
son tangibles pero que tienen identidad y son distinguibles del resto, son un pedido a un
proveedor, una petición de préstamo en una biblioteca o una incidencia municipal.

Entendemos por tipo de entidad la abstracción que permite definir el conjunto de objetos con
las mismas propiedades, comportamiento común, semántica común e idéntica relación con los
demás objetos.

El proceso para pasar de un conjunto de entidades a un tipo de entidad se

denomina abstracción. Este proceso consiste en eliminar las diferencias o distinciones entre las
entidades para poder observar aspectos comunes a todas estas entidades.

Ejemplos de entidades

El tipo de entidad coche se define como el concepto de vehículo que describe las partes comunes
de diferentes coches con independencia de la marca, el color, el modelo y otras características
concretas. Un coche concreto, por ejemplo mi coche, es una instancia u ocurrencia del tipo de
entidad coche.

Utilizaremos la nomenclatura siguiente para diferenciar estos dos conceptos:

 El concepto que hemos definido como entidad también puede ser referenciado por los
términos objeto, instancia u ocurrencia.

 El concepto que hemos definido como tipo de entidad también puede ser referenciado

por los términos clase, entidad tipo o tipo.

En la literatura se pueden encontrar autores que utilizan las diferentes terminologías y, por lo
tanto, hay que tenerlas todas presentes para identificar de manera rápida y unívoca a qué
concepto se hace referencia cuando se utiliza cualquiera de estos términos.

Terminología UML

En la representación mediante diagramas UML, los tipos de entidad se denominan clases y las

entidades, objetos.

2.2.Atributos
Un atributo es una propiedad que tienen todas las entidades de un mismo tipo de entidad y que
permite representar sus características.

Para representar gráficamente los tipos de entidad y sus atributos, utilizaremos los diagramas de
clases del modelo UML.

Diagrama de clases

El tipo de entidad ‘coche’ tiene un conjunto de atributos; por ejemplo: marca, modelo, matrícula,
color y año de fabricación. Una entidad de coche tiene valores específicos para cada uno de
estos atributos. Por ejemplo, un coche puede ser de la marca Fiat, modelo Punto, matrícula
3621-GHV, color negro y fabricado en el 2010.

De manera similar, el tipo de entidad ‘persona’ tiene un conjunto de atributos; por ejemplo:
identificación (en el caso de España es el documento nacional de identidad o DNI), nombre y
apellidos, fecha de nacimiento, número de teléfono y correo electrónico. Una entidad de
‘persona’ puede ser, por ejemplo, una persona con DNI 33551058D, nombre Fred y apellido
Smith, nacido el 1 de marzo de 1968, con número de teléfono 85542154 y correo electrónico
fredsmith@mydom.com.

La figura 1 muestra un ejemplo de representación de los tipos de entidad ‘coche’ (Car) y

‘persona’ (Person).

Figura 1. Ejemplos de los tipos de entidad ‘coche’ (Car) y ‘persona’ (Person)

En los diagramas de clases del modelo UML representaremos los tipos de entidad
(denominados clases en los diagramas UML) mediante un rectángulo con tres secciones. En la
primera sección indicaremos el nombre del tipo de entidad. Los atributos se representan como
una lista en la segunda sección, y la tercera sección permite representar ciertas restricciones
sobre los datos u operaciones, que no utilizaremos en el diseño conceptual de bases de datos.

La tabla 1 muestra un posible ejemplo de un conjunto de entidades de persona.

Tabla 1. Ejemplo de representación de entidades del tipo de entidad ‘persona’ (Person)

ID name surname birthDate phoneNumber email

33941857B John Smith 12/10/1987 936542798 johnsmith@ejemplo.com

77854623Q Mary Jane 17/02/1972 696275345 maryjane@ejemplo.com

96725466Z Fred Sanchez 07/09/2001 649785467 fredsanchez@ejemplo.com

Atributos y relaciones binarias

En teoría, un atributo no es más que un tipo de relación binaria en la que uno de los participantes es

un tipo de dato (podéis ver el subapartado siguiente). No obstante, para simplificar el modelo y

facilitar su creación y legibilidad se tratan de manera diferente y más compacta.

2.2.1.Representación de los atributos

Los diagramas UML presentan una nomenclatura concreta para especificar las propiedades de
cada uno de los atributos:

1. visibilidad nombre [etiquetas] [: tipo] [multiplicidad] [= valor inicial]

Donde:

 Visibilidad: visibilidad del atributo (public, protected, package o private). Normalmente

este concepto no se aplica al diseño conceptual de bases de datos.

 Nombre: denominación del atributo.

 Etiquetas: etiquetas opcionales para indicar ciertos conceptos relacionados con el

atributo.

 Tipo: tipo o dominio de los datos.

 Multiplicidad: número de ocurrencias del atributo.

 Valor inicial: valor por defecto.

Como ya se ha visto en algunos ejemplos, se pueden utilizar notas asociadas a los tipos de
entidades o atributos para indicar restricciones especiales o cualquier casuística que el diseñador
considere oportuno remarcar.

Tipos de entidad

La figura 2 muestra un tipo de entidad en el que podemos ver un atributo opcional (surname),
un atributo derivado (age), un atributo de tipo enumeración (sex), un atributo con valor inicial
especificado (isWearingGlasses) y un atributo multivalor (phoneNumber). Una nota asociada al
atributo age indica la fórmula de cálculo de este atributo derivado.

Figura 2. Ejemplo del tipo de entidad ‘persona’ (Person)

Atributo de tipo enumeración

Un atributo de tipo enumeración presenta un conjunto cerrado de valores que el atributo puede tomar.

Por ejemplo, se pueden definir los días de la semana como un atributo de tipo enumeración, donde el

conjunto de posibles valores es lunes, martes, miércoles, jueves, viernes, sábado y domingo.

2.2.2.Dominio de los atributos

El conjunto de posibles valores legales que puede tomar un atributo se denomina dominio del
atributo. Este conjunto restringe los posibles valores que puede tomar el atributo en cualquiera
de las entidades. Generalmente se especifican a partir de los tipos de datos básicos disponibles
en la mayoría de los lenguajes de programación, como entero, real, cadena de texto, booleano o
tipo enumerado.

Dominio de los atributos

La figura 3 muestra el tipo de entidad ‘coche’ (Car), en el que se especifica el dominio para cada
uno de sus atributos.
En este ejemplo hemos definido un nuevo atributo para indicar el número de plazas de un coche
(seats), que corresponde al dominio de los enteros y que está limitado por un valor mínimo de 1
plaza y un valor máximo de 10 plazas (para este ejemplo se considera que no hay coches que
tengan un número de plazas superior a 10). Para indicar esta restricción sobre el dominio en
UML se pueden utilizar notas textuales o recurrir a uno de los lenguajes que permiten definir
restricciones sobre los modelos UML, como por ejemplo OCL.

Figura 3. Ejemplo de los tipos de entidad ‘coche’ (Car) con el dominio de los atributos

Object Constraint Language (OCL)

OCL es un lenguaje declarativo que permite definir reglas que se aplican a modelos UML. Entre otras,

permite describir restricciones sobre el dominio de los atributos. En este módulo no utilizaremos este

lenguaje, puesto que supone una dificultad añadida, y utilizaremos las notas textuales para indicar

restricciones en el dominio y consideraciones similares.

Reflexión

El uso de lenguajes como OCL, por su complejidad, cae fuera del alcance de este texto y, por lo tanto,

aquí utilizaremos una nota que indique de manera textual la restricción asociada al atributo en

cuestión.

2.2.3.Atributos compuestos y atributos atómicos

Un atributo compuesto es aquel que se puede dividir en atributos más básicos con significado
independiente. Un atributo atómico o simple es aquel que no es divisible sin perder el
significado.

Atributo compuesto

Un ejemplo de atributo compuesto es el concepto de ‘dirección postal’: el atributo de dirección

postal con valor “Avenida Santa Cristina, 75, 08280 Barcelona” se puede descomponer en los
atributos calle, número, código postal  y ciudad. De este modo, cada nuevo atributo mantiene
significado independiente y el conjunto de todos juntos identifica una dirección postal. Un
ejemplo de atributo simple es el nombre de una población. Aunque este atributo sea compuesto,
por ejemplo “Arenys de Mar”, no se puede dividir sin perder el significado original.

En lenguaje UML, los atributos compuestos se representan mediante un nuevo tipo de entidad.

2.2.4.Atributos monovalor y atributos multivalor

Un atributo monovalor es aquel que tiene un solo valor para cada entidad. En contraposición a
este concepto, un atributo multivalor es aquel que puede tomar más de un valor para la misma
entidad.

Atributos monovalor y multivalor

Un ejemplo de atributo monovalor es el atributo ‘fecha de nacimiento’ de una persona, puesto
que una persona sólo puede haber nacido en una única fecha.

Un ejemplo de atributo multivalor es el atributo ‘teléfono’ de una persona, puesto que se puede
dar el caso de que una persona tenga ninguno, uno o más de un teléfono (por ejemplo, un
teléfono fijo y un teléfono móvil).

La figura 4 muestra el tipo de entidad ‘persona’ (Person) con el atributo ‘teléfono’ convertido en
atributo multivalor.

Figura 4. Ejemplo del tipo de entidad ‘persona’ (Person) con un atributo multivalor

Para indicar la cardinalidad de un atributo multivalor utilizaremos:

 Un número para indicar el número exacto de valores que debe tener el atributo.

 El intervalo min..max para indicar el número mínimo y máximo de valores que puede

tener el atributo.

 El símbolo * para indicar que el atributo puede tener indefinidos valores (cero o más).

Significado del símbolo *

Para indicar que el atributo ‘teléfono’ (phoneNumber) del tipo de entidad ‘persona’ (Person) de la

figura 4 puede tener entre 0 y 5 valores hay que indicar “phoneNumber: String[0..5]” en la definición

del tipo de entidad.

2.2.5.Atributos derivados
Un atributo derivado es aquel que se calcula a partir de otros atributos. Por lo tanto, un
atributo derivado lleva asociado un procedimiento de cálculo para obtener el valor a partir de
otros atributos, que pueden ser derivados o no. Un atributo no derivado es aquel al que hay que
asignar un valor.

Atributos derivados

Supongamos la clase ‘factura’ (Bill) con los atributos ‘número de factura’ (number), ‘cliente’
(customer), ‘fecha de la factura’ (date) e ‘importe total de la factura’ (total). Para obtener la
información del importe total de la factura, tenemos que crear el atributo ‘importe total’ (total)
como atributo derivado, calculado a partir de la suma de cada una de las líneas de los detalles
de la factura, tal como se muestra en la figura 5.

Figura 5. Ejemplo de atributo derivado

2.2.6.El valor NULL
El valor NULL es un valor especial diseñado para indicar que un atributo es desconocido o no se
aplica en una entidad concreta. Para cada atributo, se puede indicar si acepta un valor NULL o
no. En caso de que se especifique que el atributo no acepta un valor NULL, todas las entidades
deben tener informado dicho atributo con un valor.

Atributo con valor NULL

La figura 6 muestra el tipo de entidad ‘dirección’ (Address), que permite definir la dirección física
de una casa, un piso o un local. Hay que señalar que en las casas unifamiliares no tiene sentido
el atributo de ‘número de piso y puerta’. Los atributos que indican el ‘número de piso’ (floor) y
‘puerta de escalera’ (doorNumber) especifican una multiplicidad de 0 o 1, es decir, que para
cada entidad pueden tener un valor asociado o tener valor no definido (NULL).

Figura 6. Ejemplo de atributo con valor NULL

2.3.Claves
Una clave candidata es un conjunto de atributos mínimo que permite identificar de manera
única todas las entidades de un tipo de entidad.

Un tipo de entidad puede tener una o más claves candidatas. Pero es necesario que tenga al
menos una clave candidata que permita identificar de manera unívoca todas las entidades.

Una clave candidata puede estar formada por uno o más atributos. En el caso de estar formada
por varios atributos, recibe el nombre de clave candidata compuesta. En este caso, la
combinación de los diferentes valores de los atributos debe ser única para identificar de manera
unívoca a todas las entidades de un mismo tipo de entidad. Una clave candidata compuesta
debe ser mínima, es decir, debe incluir el número mínimo de atributos que permitan identificar
de manera unívoca las entidades. La definición de clave candidata se puede ver como una
restricción sobre los datos, puesto que prohíbe que dos entidades tengan el mismo valor en los
atributos que forman la clave candidata.

El diseñador de la base de datos elige una de las claves candidatas para que sea la clave
primaria. Esta es la clave elegida para identificar las entidades de manera unívoca. Como clave
candidata, no puede contener valores duplicados pero además, de manera implícita, no puede
contener valores NULL en ninguna entidad.

En UML no hay ninguna notación para indicar las claves candidatas ni la clave primaria. En este
texto tomamos un convenio para indicar las claves candidatas y las claves primarias. Las claves
candidatas se marcan con la etiqueta <Un>, donde n (n > 0) agrupa cada uno de los conjuntos
de claves candidatas. Por lo tanto, si dos o más atributos tienen la misma etiqueta, por
ejemplo <U1>, entendemos que se trata de una clave candidata compuesta por todos los
atributos con esta etiqueta. La clave primaria se marca con la etiqueta <P>  para distinguirla del
resto de claves.

Otros autores prefieren indicar las claves con la etiqueta {Un} y {P} o utilizar restricciones
textuales como método de notación. Aunque el significado es el mismo para las diferentes
notaciones, en este texto utilizaremos la notación mencionada inicialmente.

Tipos de entidad con clave primaria y claves candidatas

La figura 7 muestra ejemplos de los tipos de entidad ‘coche’ y ‘ persona’ con las marcas de la
clave primaria y de las claves candidatas, en caso de que existan.

El tipo de entidad ‘persona’ (Person) tiene dos claves candidatas: por un lado tenemos la clave
formada por el atributo ‘ID’ y por el otro tenemos la clave formada por los atributos ‘nombre’
(name) y ‘apellidos’ (surname). Para este ejemplo, suponemos que no pueden existir dos
personas con los mismos nombre y apellidos. Aun así, elegimos como clave primaria el atributo
‘ID’. El tipo de entidad ‘coche’ (Car) sólo tiene una clave candidata, formada por el atributo
‘matrícula’ (plateNumber), que por lo tanto es elegida para ser clave primaria.

Figura 7. Ejemplos de los tipos de entidad ‘coche’ (Car) y ‘persona’ (Person) con la clave primaria y las

claves candidatas marcadas

2.4.Tipos de relaciones
Denominamos tipos de relaciones a las asociaciones entre tipos de entidades, y relaciones, a
las asociaciones entre las entidades.

Los tipos de relaciones indican generalmente las relaciones en las que pueden participar las
entidades de un tipo de entidad, y en qué condiciones.

Utilizaremos la nomenclatura siguiente para diferenciar estos dos conceptos:

 El concepto que acabamos de definir como tipo de relación también puede ser
referenciado por los términos interrelación, relación o asociación.

 El concepto que acabamos de definir como relación también puede ser referenciado por

los términos instancia u ocurrencia de la relación, interrelación o asociación.

Ejemplo de tipo de relación

Entre los tipos de entidades ‘coche’ (Car) y ‘persona’ (Person) podemos establecer un tipo de
relación de propiedad que indique que una persona posee un coche. Para representar esta
información debemos crear en el diagrama conceptual de la figura 8 un nuevo tipo de relación
denominado Has, para indicar que una persona tiene un coche.

Figura 8. Ejemplo de tipo de relación Has entre los tipos de entidad ‘persona’ (Person) y ‘coche’ (Car)
Tal como se puede ver en la figura 8, en un tipo de relación pueden aparecer diferentes
etiquetas, todas con el fin de facilitar la comprensión de la relación entre las entidades:

 Los tipos de relación casi siempre tienen una etiqueta de tipo de relación que indica
el significado de la asociación entre los dos tipos de entidades. Esta etiqueta indica la
acción entre los dos tipos de entidades, y suele ser un verbo. Para especificar mejor
su significado, de manera opcional se puede indicar la dirección del tipo de relación.
Esto facilita la lectura de la acción o de la relación que existe entre los dos tipos de
entidad. En la figura 8 podemos leer que “una persona tiene un coche”. Aunque no es
muy habitual, cuando esta relación es lo bastante evidente se puede considerar que
no es necesario indicarlo explícitamente y se puede obviar la etiqueta o la dirección.

 También se puede dar la situación en que sea necesario definir mejor el papel que tiene
cada una de las entidades en la relación. En estos casos se puede definir una etiqueta
en cada extremo del tipo de relación, que indica el papel que juega cada una de las
entidades en la relación y que ayuda a explicar el significado de la relación. Estas
etiquetas se denominan etiquetas de rol o nombres de rol. En términos generales
no suelen ser necesarias y no siempre se utilizan, pero en algunos casos pueden ser
útiles para definir el papel de las entidades en la relación. La figura 8 muestra los
nombres de roles para los dos tipos de entidades que aparecen. Utilizando las
etiquetas de rol, podemos leer que “una persona posee (owns) un coche” y, de
manera inversa, que “un coche es propiedad (belongs to) de una persona”. Es
necesario que todo tipo de relación tenga definidos los roles de los participantes o el
nombre del tipo de relación.

En algunos casos los tipos de relaciones, en primera instancia, se modelizan como atributos. Un
análisis posterior con más detalle ayuda a ver que lo que se había modelizado en un primer
momento como un atributo es un tipo de relación hacia un tipo de entidad nuevo o existente.

Diseño de un nuevo tipo de relación

Supongamos que queremos modelizar el tipo de entidad empleado (Employee) para almacenar
datos de los empleados de una empresa. Entre otros atributos, nos interesa indicar a qué
departamento de la empresa pertenece cada empleado. Una primera aproximación sugiere un
diseño en el que se incluye el atributo ‘departamento’ en el tipo de entidad ‘empleado’, tal como
muestra la figura 9. Pero refinando este modelo, es posible que nos interese tener categorizados
los diferentes departamentos, e incluso nos podría interesar almacenar cierta información
relativa al departamento. En este nuevo diseño se crea un nuevo tipo de entidad para los
departamentos y se establece un tipo de relación entre los empleados y los departamentos
(tipos de entidad Department) que indica a qué departamento pertenece cada empleado. La
figura 10 muestra el nuevo diseño.

Figura 9. Ejemplo de diseño del departamento como un atributo del tipo de entidad ‘empleado’ (Employee)
Figura 10. Ejemplo de diseño del departamento como un nuevo tipo de entidad ‘departamento’ (Department)

relacionado con el tipo de entidad ‘empleado’ (Employee)

Se define el grado de un tipo de relación como el número de tipos de entidades que

participan en la asociación.

Los tipos de relaciones se clasifican, según su grado, en:

 Tipos de relaciones binarias: asociaciones en las que intervienen dos tipos de

entidades.

 Tipos de relaciones ternarias: asociaciones en las que intervienen tres tipos de

entidades.

 Tipos de relaciones n-arias: asociaciones en las que intervienen n  tipos de entidades.

A pesar de que los tipos de relaciones binarias y ternarias son un caso concreto de los
tipos de relaciones n-arias, estos tipos se usan para denotar relaciones con un grado
superior a tres.

Terminología UML

En la representación en diagramas UML, los tipos de relaciones se denominan asociaciones y las

relaciones, instancias de las asociaciones.

2.4.1.Tipos de relaciones binarias

Se define un tipo de relación binaria como la asociación entre dos tipos de entidades.

Tipos de relación binaria

Figura 11. Ejemplo del tipo de relación binaria ‘matrícula’ (Enrollment) entre los tipos de entidad ‘estudiante’

(Student) y ‘asignatura’ (Subject)

La figura 11 muestra el tipo de relación ‘matrícula’ (Enrollment) entre los tipos de entidad
‘estudiante’ (Student) y ‘asignatura’ (Subject). Esta relación indica en qué asignaturas se ha
matriculado cada uno de los estudiantes.

Figura 12. Ejemplo en el nivel de entidades de la relación ‘matrícula’ (Enrollment)

Siguiendo con el ejemplo de la figura 11, la figura 12 muestra la misma relación, pero a escala
de entidades. Es decir, este ejemplo muestra una posible asociación entre los datos de las dos
entidades mediante la relación Enrollment. Se puede ver, por ejemplo, que el
estudiante John está matriculado en las asignaturas Mathematics  y Databases.

Conectividad

La conectividad de un tipo de relación expresa el tipo de correspondencia que hay entre los

tipos de entidades que participan en un tipo de relación. En el caso de los tipos de relación
binarios, expresa el número de ocurrencias de un tipo de entidad con el que se puede asociar
una ocurrencia del otro tipo de entidad según el tipo de relación.

Un tipo de relación binaria puede tener tres tipos de conectividad:

1) Conectividad uno a uno (1:1): indica que cada entidad de un tipo se relaciona solo con una
de las entidades del otro tipo. En la figura 13a se puede ver un ejemplo de conectividad 1:1,
donde, según el modelo, cada empleado tiene un despacho y en cada despacho hay un solo
empleado. La conectividad 1:1 se denota poniendo un 1 en cada parte del tipo de relación.

2) Conectividad uno a muchos (1:N o 1..*): indica que cada entidad de un tipo se relaciona con
varias entidades del otro tipo, pero las entidades de este segundo tipo solo se relacionan con
una única entidad del primer tipo. En la figura 13b se puede ver un ejemplo de conectividad 1:N,
donde la N está en la parte del tipo de entidad ‘despacho’. Según el modelo, cada empleado
tiene varios despachos, pero en cada despacho hay un solo empleado. En la figura 13c se puede
ver la relación inversa. En este caso la N está en la parte del tipo de entidad ‘empleado’. Según
el modelo, cada empleado tiene un único despacho, pero un mismo despacho lo pueden
compartir varios empleados. La conectividad 1:N se denota poniendo un 1 en una parte del tipo
de relación y una N o * en la otra parte.

3) Conectividad muchos a muchos (M:N o *..*): indica que cada entidad de un tipo de entidad
se relaciona con varias entidades del otro tipo. En la figura 13d se puede ver un ejemplo de
conectividad M:N, donde, según el modelo, cada empleado tiene varios despachos y en cada
despacho hay varios empleados. La conectividad M:N se denota poniendo una M o * en una
parte del tipo de relación y una N o * en la otra parte.

Figura 13. Ejemplos de conectividad en los tipos de relaciones binarias entre los tipos de entidad ‘empleado’

(Employee) y ‘despacho’ (Office)

Estas restricciones las determinan los requisitos de cada problema y son los usuarios de la base
de datos quienes han de conocer las restricciones implícitas en los problemas.

Cuando se habla de “conectividad a muchos” se puede indicar de diferentes maneras. Según el

matiz del problema, usaremos:

 Un número para indicar el número exacto de entidades que pueden intervenir en la

relación.

 El intervalo min..max para indicar el número mínimo y máximo de entidades que pueden

intervenir en la relación.

 Lo etiqueta N o * para indicar que un número indefinido (cero o más) de entidades

pueden participar en la relación.

Conectividad “a muchos”

La figura 14 muestra el tipo de relación ‘matrícula’ (Enrollment) entre el tipo de entidad

‘estudiante’ (Student) y ‘asignatura’ (Subject), donde se indica que un estudiante tiene que
estar matriculado en un mínimo de dos asignaturas y un máximo de cinco.

Figura 14. Ejemplo del tipo de relación ‘matrícula’ (Enrollment) donde se indica el número mínimo y máximo

de instancias que pueden intervenir en la relación

Dependencia de existencia o restricciones de participación

Observación

En algunos diagramas de ejemplo de los tipos de relaciones obviaremos los atributos y las

características que no sean necesarias para explicar el concepto que nos interese, con objeto de

simplificar los diagramas y centrarnos en los tipos de relaciones.

En algunos casos, las entidades de un tipo de entidad no pueden existir si no están relacionadas
con las entidades de otro tipo de entidad mediante una relación binaria determinada. En estos
casos, se dice que el segundo tipo de entidad es un tipo de entidad obligatorio en la relación. En
otro caso, se dice que es un tipo de entidad opcional en la relación.

Dependencia de existencia en los tipos de relaciones binarias

La figura 15 muestra un modelo en el que aparece un tipo de relación binaria que expresa la
relación de ‘dirección de departamento’ (Heads) entre los tipos de entidad ‘profesor’ (Professor)
y ‘departamento’ (Department). El tipo de entidad ‘profesor’ es obligatorio en la relación
‘dirección de departamento’. Esto indica que no puede haber un departamento que no tenga un
profesor que haga de director de departamento. El tipo de entidad ‘departamento’, en cambio,
es opcional en la relación ‘dirección de departamento’. Puede ser que haya uno o más profesores
que no tengan la responsabilidad de dirigir un departamento.

Figura 15. Ejemplo de dependencia de existencia en los tipos de relaciones binarias

Esta dependencia de existencia sólo es aplicable en los tipos de relaciones binarias. No se da en

los tipos de relaciones n-arias.

En los diagramas UML se utiliza la cardinalidad del tipo de relación para expresar la
obligatoriedad o no de cada uno de los tipos de entidades que participan en la asociación.
Considerando los tipos de conectividad que hemos visto, hay que aplicar:

 Tipo de entidad con cardinalidad 1: un tipo de entidad conectada con cardinalidad 1

a una asociación expresa la obligatoriedad indicando una cardinalidad exactamente
igual a 1..1, mientras que si es opcional en la asociación, se indica con la cardinalidad
0..1.

 Tipo de entidad con cardinalidad N: un tipo de entidad conectada con

cardinalidad N a una asociación expresa la obligatoriedad indicando una cardinalidad
1..*, mientras que si es opcional en la asociación, se indica con la cardinalidad 0..*.

Métodos abreviados de cardinalidades:

 La cardinalidad 1 es una manera abreviada de referirse a la cardinalidad 1..1.

 La cardinalidad * es una manera abreviada de referirse a la cardinalidad 0..*.

Obligatoriedad en la dependencia de existencia

La figura 16 muestra las cuatro posibilidades de expresar la obligatoriedad de las clases A y B en

un tipo de relación binaria 1:N. En la figura 16 vemos en 16a el caso en el que los dos tipos de
entidades son opcionales, en 16b el caso en el que el tipo de entidad A es obligatorio, en 16c el
caso en el que el tipo de entidad B es obligatorio y en 16d el caso en el que los dos tipos de
entidad son obligatorios.

Figura 16. Ejemplos de obligatoriedad en la dependencia de existencia

Igual que las restricciones de conectividad, estas restricciones son inherentes a los problemas
que se quieren resolver y a partir de la compilación de requisitos de los usuarios de la base de
datos se podrá determinar cómo se debe proceder en cada caso.

Tipos de entidad obligatoria y opcional

Tipo de entidad obligatoria: para designar este concepto también se puede decir que el tipo de

entidad tiene una participación total en la asociación o que presenta una dependencia de existencia

respecto a la asociación.

Tipo de entidad opcional: para designar este concepto también se puede decir que el tipo de

entidad tiene una participación parcial en la asociación.

2.4.2.Tipo de relaciones ternarias

Se define un tipo de relación ternaria como la asociación entre tres tipos de entidades.

Hay situaciones en las que no basta modelizar una asociación entre dos tipos de entidades para
representar un concepto y es necesario modelizar la asociación entre tres tipos de entidades
para representar el concepto deseado.

Tipos de relación ternaria

Siguiendo un ejemplo visto antes, no es suficiente modelizar el tipo de relación ‘matrícula’

(Enrollment) entre los tipos de entidades ‘estudiante’ (Student) y ‘asignatura’ (Subject) para
representar la realidad de los estudiantes que suspenden una asignatura y tienen que volver a
cursarla en un semestre posterior. En estos casos, una entidad ‘estudiante’ puede tener cero,
una o más de una matrícula para una misma entidad ‘asignatura’. El requisito es que sólo es
posible efectuar una matrícula por semestre. Por lo tanto, hay que introducir el tipo de entidad
‘semestre’ (Semester) en el ejemplo anterior y modificar el modelo para que la relación
‘matrícula’ asocie los tres tipos de entidad. La figura 17 muestra el nuevo modelo.

Figura 17. Ejemplo de tipo de relación ternaria entre los tipos de entidad ‘estudiante’ (Student), ‘asignatura’

(Subject) y ‘semestre’ (Semester)

Conectividad

En la conectividad de un tipo de relación ternaria hay implicados tres tipos de entidades y cada
uno puede tomar la conectividad “a uno” o “a muchos”.

Un tipo de relación ternaria puede tener cuatro tipos de conectividad:

 Conectividad M:N:P o *..*..*.

 Conectividad M:N:1 o *..*..1.

 Conectividad M:1:1 o *..1..1.

 Conectividad 1:1:1 o 1..1..1.

Para decidir cómo se debe conectar cada uno de los tipos de entidad a la asociación, hay que
fijar “a una” las otras entidades y entonces preguntarse si es posible conectar con la relación “a
una” o “a muchas” entidades del primer tipo de entidad.

Conectividad en un tipo de relación ternaria

Veamos cómo definimos la conectividad en un tipo de relación ternaria mediante el ejemplo que
ilustra la figura 18.

En la figura podemos ver los tres tipos de entidad, ‘estudiante’ (Student), ‘asignatura’ (Subject)
y ‘semestre’ (Semester), y el tipo de relación ‘matrícula’ (Enrollment).

Figura 18. Ejemplo de conectividad en un tipo de relación ternaria

Para determinar el grado de conectividad de cada tipo de entidad en la asociación, debemos fijar
“a una” las instancias del resto de los tipos de entidades y nos tenemos que preguntar si es
posible conectar con la relación “a una” o “a muchas” instancias del primer tipo de entidad.
En primer lugar, por ejemplo, nos preguntamos si con referencia a la relación ‘matrícula’ y dados
una asignatura y un semestre concretos se pueden tener “uno” o “muchos” estudiantes. La
respuesta es que puede haber “muchos” estudiantes matriculados, puesto que varios
estudiantes pueden matricularse de una misma asignatura en el mismo semestre. Por lo tanto,
el tipo de entidad ‘estudiante’ participa con grado N en la relación ‘matrícula’.

En segundo lugar, nos preguntamos, por ejemplo, si fijados un estudiante y una asignatura
concretos puede existir matrícula en “uno” o “muchos” semestres. La respuesta es que pueden
tener “muchos” semestres, puesto que un estudiante se puede matricular más de una vez en
diferentes semestres hasta superarlos. Por lo tanto, el tipo de entidad ‘semestre’ participa con
grado N en la relación ‘matrícula’.

Finalmente, nos preguntamos si fijados un estudiante y un semestre concretos pueden tener

matrícula de “una” o “muchas” asignaturas. La respuesta es que se pueden tener “muchas”
asignaturas matriculadas, puesto que un estudiante se puede matricular de varias asignaturas
en un mismo semestre. Por lo tanto, el tipo de entidad ‘asignatura’ también participa con
grado N en la relación matrícula.

Así pues, vemos que el tipo de relación ‘matrícula’ tiene cardinalidad M:N:P o *..*..*.

2.4.3.Tipos de relaciones n-arias
Se define un tipo de relación n-aria como la asociación entre tres o más tipos de entidades.

El tipo de relación ternaria es un caso concreto de tipo de relación n-aria. Lo que hemos visto en
el subapartado anterior se puede generalizar para los tipos de relaciones n-arias. Por lo tanto, en
una relación n-aria puede haber n  + 1 tipos de conectividad, puesto que cada una de
las n entidades puede estar conectada “a uno” o “a muchos” tipos en la asociación.

Conectividad en un tipo de relación cuaternaria

La figura 19 presenta una ampliación del ejemplo anterior, en el que se presentaban los tipos de
entidad ‘estudiante’ (Student), ‘asignatura’ (Subject) y ‘semestre’ (Semester) asociados
mediante el tipo de relación ‘matrícula’ (Enrollment).

En este caso queremos añadir el concepto de turno o franja horaria en el esquema para indicar
que una misma asignatura puede ser de turno de mañana o de tarde. Para modelizar este
concepto, hemos creado el tipo de entidad ‘franja horaria’ (TimeSlot).

Para determinar el grado de conectividad del nuevo tipo de entidad seguiremos el mismo
proceso visto para el caso del tipo de relaciones ternarias. En este caso, nos preguntamos si con
referencia al tipo de relación ‘matrícula’ y fijados un estudiante, un semestre y una asignatura
concretos puede haber “una” o “muchas” franjas horarias. La respuesta es que solo puede haber
“una” franja horaria. Por lo tanto, el tipo de entidad de ‘franja horaria’ o ‘turno’ (TimeSlot)
participa con grado 1 en este tipo de relación.

Figura 19. Ejemplo de conectividad en un tipo de relación cuaternaria

2.4.4.Tipos de relaciones reflexivas o recursivas
Un tipo de relación reflexiva o recursiva es un tipo de relación binaria en la que un tipo de
entidad se relaciona consigo misma.

Se presenta una relación entre dos entidades del mismo tipo de entidad. Igual que en el resto de
los tipos de relaciones binarias, pueden tener conectividad 1:1, 1:N o M:N y pueden expresar
dependencia de existencia.

Tipos de relación recursiva binaria

Un claro ejemplo de un tipo de relación recursiva binaria es el concepto de amistad entre dos

personas. En este caso, tenemos el tipo de entidad ‘persona’ (Person) y el tipo de relación
‘amistad’ (Friendship), que une dos entidades de ‘persona’. La figura 20 muestra su modelo
conceptual. La conectividad de la asociación es M:N, puesto que una persona puede tener varios
amigos y, a la vez, puede haber varias personas que la tengan de amiga.

Figura 20. Ejemplo de tipo de relación recursiva

Generalmente no se hace referencia explícita al rol de cada entidad en una relación, puesto que
normalmente cada entidad participa una única vez en una relación y su rol se sobreentiende.
Pero en las relaciones recursivas puede ser que el rol de cada entidad no sea tan claro. Por lo
tanto, si se considera oportuno, se puede indicar el rol de cada asociación entre la entidad y la
relación.

Otro ejemplo de tipo de relación recursiva

La figura 21 muestra un tipo de relación recursiva que describe la relación de maternidad entre
las personas. Podemos ver que una persona puede tener cero o más hijos, y que una persona
solo puede tener una madre. Las etiquetas o nombres de rol, en este caso, pueden ayudar a
comprender el rol de cada entidad en esta relación recursiva.

Figura 21. Ejemplo de tipo de relación recursiva con nombres de rol

2.5.Tipos de entidades asociativas

Las relaciones también pueden tener atributos que permitan describir propiedades interesantes.
Estos atributos se definen y siguen las mismas reglas que en el caso de los atributos de las
entidades.

Un tipo de entidad asociativa es el resultado de considerar una relación entre entidades como
si fuera una entidad. Su nombre se corresponde con el nombre de la relación sobre la que se
define.

Los tipos de entidades asociativas añaden nuevas funcionalidades a las relaciones. Algunas de
las principales son las siguientes:

1) Permiten definir atributos que hacen referencia a la relación. Es decir, son específicos de la
asociación que hay entre las dos instancias de los dos tipos de entidad que forman la relación.

2) Permiten que el tipo de entidad asociativa, y por lo tanto la relación entre los tipos de
entidades, participe en otras relaciones con otros tipos de entidades o con otros tipos de
entidades asociativas.

Tipos de entidad asociativa

La figura 22 muestra el tipo de relación ‘matrícula’ (Enrollment) entre los tipos de entidad
‘estudiante’ (Student) y ‘asignatura’ (Subject). Esta relación indica en qué asignaturas están
matriculados cada uno de los estudiantes. La entidad asociativa contiene el atributo ‘nota’
(Grade), que indica la nota que ha obtenido un estudiante en una asignatura. Para cada relación
entre un estudiante y una asignatura hay una relación ‘matrícula’ con un atributo ‘nota’.

En el caso de situar el atributo ‘nota’ (Grade) en la entidad ‘estudiante’ (Student), decimos que
un estudiante siempre tendrá la misma nota de todas las asignaturas de las que se matricule. En
el caso de situar el atributo en la entidad ‘asignatura’ (Subject), en cambio, decimos que todos
los estudiantes tienen la misma nota en una misma asignatura. Por lo tanto, la única manera de
modelizar la realidad de manera correcta es considerar el atributo ‘nota’ como un atributo de la
relación entre estos dos tipos de entidad.

Figura 22. Ejemplo del tipo de entidad asociativa ‘matrícula’ (Enrollment)

Los tipos de entidades asociativas permiten establecer relaciones con otras entidades y también
con otras entidades asociativas, es decir, permiten crear relaciones entre relaciones.

Tipos de relación entre una entidad y una entidad asociativa

Supongamos que queremos añadir en el ejemplo anterior el concepto de justificación o retorno

personalizado de la nota. Es decir, queremos expresar que en algunos casos, por ejemplo
cuando lo solicite, el estudiante recibirá una descripción en la que se justifica la puntuación que
ha obtenido y los errores que ha cometido en una asignatura determinada. La figura 23 muestra
el modelo conceptual con el nuevo requisito. Podemos ver cómo el nuevo tipo de entidad
‘justificación’ (Justification) indica la fecha y la descripción de la justificación y se relaciona con
algunas matriculaciones. Este punto es relevante, puesto que, dada la cardinalidad del tipo de
relación ‘revisión’ (Review), se puede deducir que pueden existir parejas estudiante-asignatura
sin una justificación.
 Figura 23. Ejemplo de tipo de relación entre una entidad y una entidad asociativa

Cabe señalar que esta misma situación no se puede modelizar mediante un tipo de relación
ternaria.

Error de expresión

La figura 24 muestra el modelo conceptual y emplea un tipo de relación ternaria. En este caso el
significado del modelo es diferente del que planteábamos en el ejemplo anterior. Este modelo
nos dice que para cada estudiante (Student) y asignatura (Subject) puede haber ninguna o una
justificación (Justification). Pero también indica que fijadas una justificación y una asignatura
puede haber muchos estudiantes, afirmación que es falsa según los requisitos iniciales.
Igualmente, el modelo indica que fijados un estudiante y una justificación puede haber muchas
asignaturas, afirmación que también es falsa. Si modificamos las cardinalidades de los tipos de
entidad ‘estudiante’ y ‘asignatura’ y las establecemos a 1, entonces no podremos representar de
manera correcta que un estudiante puede estar matriculado en varias asignaturas.

El problema reside en el hecho de que intentamos representar con un tipo de relación ternaria
un modelo que es binario. Hay que señalar que el concepto de justificación hace referencia a la
relación que existe entre las entidades ‘estudiante’ y ‘asignatura’, y para ello es necesario que
sea modelizado como un tipo de entidad que se relaciona con el tipo de entidad asociativa que
surge del tipo de relación entre los dos tipos de entidades.

Figura 24. Ejemplo de error de expresión sobre el ejemplo de la figura 23

Es importante que quede claro que no se representa el mismo concepto con un tipo de relación
ternaria y un tipo de relación binaria con una entidad asociativa.

2.6.Tipos de entidades débiles

Se define un tipo de entidad fuerte como un tipo de entidad que posee un conjunto de
atributos suficientes para formar claves candidatas e identificar de manera inequívoca todas sus
instancias.

La existencia de las instancias de un tipo de entidad fuerte no depende de ningún otro tipo de
entidad o tipo de relación. Es decir, el significado de las entidades fuertes no necesita ninguna
relación con otras entidades que complemente su significado. Por lo tanto, se pueden ver estas
entidades como aquellas que tienen existencia propia y muy definida.

Tipos de entidades fuertes

También se pueden denominar tipos de entidades propietarias, dominantes o padres.

Se define un tipo de entidad débil como un tipo de entidad cuyos atributos no la identifican

completamente, sino que sólo la identifican de manera parcial. Estas entidades deben participar
en una relación con otras entidades que ayuden a identificarlas de manera unívoca.

Un tipo de entidad débil, por lo tanto, necesita una asociación con un tipo de entidad que le
permite identificar de manera única sus instancias. Este tipo de relación recibe el nombre de tipo
de relación identificativa del tipo de entidad débil. El tipo de entidad débil debe tener una
restricción de participación total (dependencia de existencia) respecto al tipo de relación
identificativa, puesto que si no es así, hay instancias que no se podrán identificar de manera
única.

Toda entidad débil debe formar parte de una relación binaria con conectividad 1:N, donde la
entidad débil debe estar en el lado N. Esta relación le permitirá identificarse completamente.

Las entidades débiles no pueden sobrevivir si se elimina la entidad fuerte con la que están
relacionadas mediante la relación identificativa. Por lo tanto, hay que tener en cuenta que, si se
elimina una entidad fuerte, hay que eliminar las entidades débiles que están relacionadas con
ella.

En los diagramas UML un tipo de entidad débil se indica mediante la dependencia de su

existencia hacia el tipo de entidad fuerte. El tipo de entidad débil, debido a la dependencia de
existencia o restricción de participación, necesita mantener una relación 1:N con el tipo de
entidad fuerte. Por lo tanto, siempre mantendrá una relación con una cardinalidad igual a 1
hacia la parte del tipo de entidad fuerte. La figura 25 muestra la notación para indicar un tipo de
entidad débil en los diagramas UML.
 Figura 25. Notación UML para indicar un tipo de entidad débil (B)

Hay que destacar que un tipo de relación identificativa no suele tener atributos, puesto que en
las relaciones 1:N siempre es posible poner los atributos en el tipo de entidad débil, es decir, en
la parte con cardinalidad N.

Un tipo de entidad puede ser fuerte en una determinada asociación y, al mismo tiempo, ser débil
en otra asociación.

Relatividad del tipo de relación

La figura 26 muestra el tipo de entidad ‘mes del año’ (Month), que es débil respecto a la relación
con el tipo de entidad ‘año’ (Year) y fuerte respecto a la relación con el tipo de entidad ‘día del
mes’ (DayOfTheMonth).

Figura 26. Ejemplo de tipo de entidad fuerte respecto a una relación y, al mismo tiempo, débil respecto a

otra relación

Una clave parcial en un tipo de entidad débil es el conjunto de atributos que permite identificar
de manera única todas las instancias del tipo de entidad débil que están relacionadas con la
misma instancia del tipo de entidad fuerte.

En el peor de los casos, la clave parcial es el conjunto de todos los atributos del tipo de entidad
débil.

Se considera que la clave primaria del tipo de entidad débil está formada por la clave primaria
del tipo de entidad fuerte y la clave parcial del tipo de entidad débil. De este modo se puede
referenciar cada una de las instancias del tipo de entidad débil de manera única.

Notación única de dos tipos de entidades débiles

Si consideramos el concepto cuenta corriente en una entidad bancaria, podemos afirmar que es

un tipo de entidad fuerte, puesto que posee el conjunto de atributos necesarios para identificar
de manera única cada una de sus instancias. En cambio, si consideramos el concepto
de movimiento o transacción, nos damos cuenta de que sólo tiene sentido y puede existir si está
asociado a una cuenta bancaria. Por lo tanto, para modelizar esta situación se puede crear un
tipo de entidad fuerte, BankAccount, y un tipo de entidad débil, Transaction, como se muestra
en la figura 27. La clave primaria del tipo de entidad BankAccount  es el atributo accountNumber.
En el tipo de entidad Transaction la clave parcial es el atributo transactionNumber, que indica el
número de transacción. Por lo tanto, la clave primaria del tipo de entidad débil es compuesta y
está formada por los atributos {accountNumber, transactionNumber}.
 Figura 27. Ejemplo de tipo de entidad débil (Transaction) y la relación identificativa con el tipo de entidad

fuerte (BankAccount)

Tipos de entidades débiles

También se pueden denominar tipos de entidades subordinadas o hijas.

2.7.Opciones de diseño
En algunas situaciones no es trivial determinar si un concepto debe ser modelizado como un tipo
de entidad, un atributo o un tipo de relación. Hay que tener en cuenta que normalmente no
existe un único diagrama conceptual para un problema concreto, y que puede haber diferentes
conceptualizaciones que den lugar a diferentes diagramas, todos correctos.

A continuación, mencionamos algunos consejos que pueden ser útiles durante el diseño
conceptual de una base de datos:

 El proceso de diseño conceptual de una base de datos se puede enfocar como un

proceso iterativo de refinamiento, donde se crea un primer diseño inicial y se va
refinando de manera iterativa hasta conseguir el nivel de diseño deseado.

 Es frecuente modelizar un concepto como un atributo en un primer momento, y en

refinamientos posteriores convertirlo en un tipo de relación. Modelizar el atributo
como una relación a un tipo de entidad nuevo o existente permite categorizar los
valores de este concepto y, además, permite que se puedan añadir nuevos atributos
relacionados con el tipo de entidad nuevo o existente, ahora o en el futuro.

 También es habitual que un atributo existente en varios tipos de entidades sea

convertido en un nuevo tipo de entidad. A continuación hay que establecer relaciones
desde los tipos de entidades que contenían este atributo hacia el nuevo tipo de
entidad.

 También puede existir el refinamiento inverso. En este caso, se puede eliminar un tipo
de entidad y representar el concepto como un atributo si solo afecta a un tipo de
entidad (o a muy pocos).

De atributo a tipo de entidad

Si los tipos de entidades Estudiante, Profesor y Curso tienen el atributo Departamento es interesante

crear el nuevo tipo de entidad Departamento, con un único atributo que indica el nombre del
departamento, y crear tres tipos de relaciones binarias entre Estudiante, Profesor y Curso, y el nuevo

tipo de entidad Departamento.

2.8.Criterios de asignación de nombres

En el diseño del esquema conceptual de una base de datos es importante elegir adecuadamente
los nombres de los tipos de entidades, atributos y tipos de relaciones que aparecen en él, puesto
que no siempre es fácil determinar el papel de cada uno de ellos en un modelo conceptual. Hay
que escoger nombres que transmitan de la mejor manera posible el significado de las diferentes
estructuras del esquema.

Los criterios empleados en este texto son una opción, aunque no hay normativa y pueden variar
respecto a otros autores.

En los puntos siguientes establecemos la base de la nomenclatura en los diagramas UML:

 Etiquetar los tipos de relaciones utilizando nombres simples en singular, siempre que sea
posible. Si es necesario, se pueden utilizar hasta dos o tres nombres. Hay que
emplear la grafía Pascal para escribir el nombre de los tipos de entidades.

 Etiquetar los atributos utilizando nombres simples en singular y evitando que aparezca el
nombre del tipo de entidad. Si es necesario, se pueden utilizar hasta dos o tres
nombres o la combinación de un nombre y uno o dos adjetivos. Hay que emplear la
grafía Camel para escribir el nombre de los atributos.

 En el caso de atributos booleanos se suele utilizar el nombre o nombres deseados

precedidos de es (de la forma verbal es, o is en la versión inglesa) para dar el énfasis
de valor booleano que responde que sí o que no ante una pregunta. Por
ejemplo: esNegrita o isBold.

 Etiquetar los tipos de relaciones utilizando verbos en tercera persona del singular. En
caso de requerir etiquetas compuestas, se suele utilizar un verbo seguido de una
preposición y otro verbo. Las etiquetas de los tipos de relaciones siguen la grafía
Pascal.

Las etiquetas para identificar los roles de las entidades en las relaciones siguen la grafía Camel.

Como práctica general, a partir de una descripción funcional de los requisitos de la base de
datos, los nombres que aparecen tienden a ser candidatos de nombres para los tipos de
entidades que se vayan a definir, mientras que los verbos tienden a ser utilizados para los tipos
de relaciones del esquema conceptual. Los nombres de los tipos de relaciones se eligen para que
se puedan leer de izquierda a derecha y de arriba abajo, como criterio general. De este modo se
facilita la lectura de las relaciones. Puede haber excepciones a estas normas, y en estos casos
nos podemos ayudar de los nombres de roles o podemos indicar la dirección del tipo de relación
para facilitar la comprensión de las relaciones y el papel de las entidades en cada una de estas
relaciones. Los atributos suelen ser nombres extraídos de las descripciones de los objetos
definidos como tipos de entidades.

Ejemplos de grafías posibles

Grafía Pascal: la primera letra del identificador y la primera letra de las siguientes palabras se

escriben en mayúscula. El resto, en minúscula. Por ejemplo: BackColor.

Grafía Camel: la primera letra del identificador se escribe en minúscula y la primera letra de las

siguientes palabras concatenadas, en mayúscula. El resto, en minúscula. Por ejemplo: backColor.

2.9.Ejemplo completo
En este apartado hemos visto los elementos básicos del diseño conceptual según el modelo ER.
Antes de continuar con los elementos avanzados en el apartado 3, puede resultar muy ilustrativo
ver una aplicación práctica de los conceptos vistos hasta ahora. Para facilitar el análisis de un
ejemplo más o menos real, plantearemos a continuación una descripción y un conjunto de
requisitos y restricciones que deben permitir implementar un modelo conceptual de una base de
datos destinada a la gestión universitaria. Este modelo es una reducción de un modelo real y no
se quiere adaptar a la gestión real de una universidad. Sólo pretende servir como modelo de
ejemplo para los conceptos vistos hasta ahora.

A continuación enumeramos los diferentes aspectos de los requisitos de los usuarios que hay
que tener en cuenta al realizar el diseño conceptual de la futura base de datos:

1) La universidad está formada por diferentes departamentos. Cada departamento está formado
por un conjunto de profesores y está dirigido por un único profesor. Nos interesa conocer el
nombre de los departamentos y el número de profesores adscrito a cada departamento.

2) De cada profesor nos interesa poder almacenar los datos personales, como, por ejemplo,
nombre, DNI, edad y si es un hombre o una mujer. De los profesores que son directores de
departamento, nos interesa poder identificar la fecha en la que empezaron a ejercer este cargo.

3) En la universidad se imparten un conjunto de asignaturas. Nos interesa conocer el código de

cada una de estas asignaturas, el nombre, el número de créditos, la descripción y los
prerrequisitos, es decir, otras asignaturas que sea necesario haber cursado anteriormente.
Además, hay que tener en cuenta que una asignatura pertenece a un único departamento y es
impartida por un único profesor.

4) Los estudiantes son una parte muy importante de la base de datos, ya que se desea
información sobre sus datos personales (nombre, DNI, edad, sexo) y número de identificación
universitario (conocido como NIU).

5) Cada estudiante puede estar matriculado de más de una asignatura en cada semestre. Y para
cada una de las asignaturas en las que está matriculado cada semestre debemos poder
almacenar su nota final de aquel estudiante.

6) También se quiere dejar constancia de las fechas de inicio y final de cada semestre.

A partir de los requisitos expresados, la figura 28 muestra un diagrama del modelo conceptual.
Como hemos comentado, este modelo no es único, y pueden existir diferentes aproximaciones y
conceptualizaciones válidas para una misma representación del mundo real.

Figura 28. Diagrama del modelo conceptual para la base de datos de gestión universitaria
A continuación comentamos los aspectos más relevantes de este modelo conceptual:

 En el tipo de entidad ‘departamento’ (Department), el atributo ‘número de profesores’

(numberOfProfessors) es un atributo derivado, puesto que se calcula a partir del
número de profesores que están vinculados a cada departamento.

 Los tipos de entidad ‘departamento’ y ‘profesor’ (Professor) tienen dos tipos de

relaciones, para indicar por un lado en qué departamento trabaja cada profesor, y por
otro lado, para determinar qué profesor es el director de cada departamento. La
conectividad de la primera asociación indica que un profesor debe pertenecer a un
departamento y que los departamentos deben tener como mínimo un profesor. La
segunda relación es un tipo de entidad asociativa y contiene el atributo ‘fecha de
inicio’ (startDate) para indicar la fecha en la que el profesor empieza la tarea como
jefe de departamento. Un profesor puede impartir cero, una o más de una asignatura,
como indica la conectividad del tipo de relación con el tipo de entidad ‘asignatura’
(Subject).

 El concepto prerrequisito de una asignatura se ha modelizado como un tipo de relación

recursiva que asocia diferentes entidades de asignaturas. Tal como se desprende de la
conectividad, una asignatura puede tener ninguno o múltiples prerrequisitos y ser a la
vez prerrequisito de ninguna o de múltiples asignaturas.

 El semestre se ha modelizado como un tipo de entidad (Semester).

  El tipo de relación ternaria entre los tipos de entidad ‘asignatura’, ‘semestre’ y
‘estudiante’ (Student) determina la nota obtenida por cada estudiante como
calificación de cada asignatura en la que está matriculado cada semestre. Tal como se
expresaba en los requisitos, un estudiante puede estar matriculado de múltiples
asignaturas en un semestre, y se puede matricular de la misma asignatura en varios
semestres.

Pero este modelo conceptual también presenta algunas deficiencias, que comentamos a
continuación:

 Según el modelo, un profesor imparte un conjunto de asignaturas, pero no se mantiene

relación con cada uno de los semestres. Es decir, el tipo de relación ‘imparte’
(Teaches) indica el profesor que imparte una asignatura, pero no permite saber qué
profesor la había impartido en semestres anteriores.

 En los tipos de entidad ‘profesor’ y ‘estudiante’ se almacena la edad mediante un

atributo numérico que contiene el valor para cada profesor o estudiante en un
momento determinado. Esto implica que cada año debería de actualizarse la base de
datos y sumar 1 a los valores de este atributo. Lógicamente, este modelo no es el
adecuado y habría que almacenar la fecha de nacimiento de los profesores y los
estudiantes y crear un atributo derivado que indique la edad (age) de los profesores o
los estudiantes de manera automática.

Figura 29. Diagrama del modelo conceptual con las correcciones aplicadas
La figura 29 muestra el modelo conceptual modificado para corregir las deficiencias detectadas.
El tipo de relación ‘imparte’ (Teaches) se ha convertido en un tipo de relación ternaria. De este
modo, podemos indicar qué profesor es responsable de cada asignatura en cada semestre.

3.Elementos avanzados de modelización

Los conceptos vistos hasta ahora permiten representar una gran cantidad de los esquemas de
bases de datos en aplicaciones tradicionales. Pero para poder aproximar de manera más precisa
algunas características del mundo real y fomentar la reusabilidad, se han desarrollado múltiples
ampliaciones y complementos a los elementos vistos hasta ahora. En este apartado veremos
algunas de estas ampliaciones y de estos complementos que permiten representar realidades
difícilmente expresables utilizando los elementos de modelización vistos hasta ahora.

3.1.Generalización/especialización
En algunos casos, se pueden encontrar entidades que tengan algunas características propias y
diferenciadas de otras entidades del mismo tipo de entidad, y que interese poder representar
estas diferencias en el modelo conceptual.

Ejemplos de generalización/especialización de tipos de entidades

Dentro de un entorno universitario podemos modelizar el tipo de entidad ‘persona’, que contiene
atributos como por ejemplo el nombre, los apellidos, el DNI, la fecha de nacimiento, el sexo, el
teléfono o el correo electrónico. Pero dentro de este tipo de entidad podemos encontrar algunas
entidades con características propias que nos interesa modelizar. Las entidades que
corresponden a estudiantes tienen algunas características propias relevantes (número de
identificación universitario, año de primera matrícula, etc.) que hay que incluir en el modelo. Por
otro lado, podemos definir otras entidades que pertenezcan al colectivo de profesores y sobre los
cuales queremos representar otros tipos de atributos (departamento al que pertenecen,
especialidad, etc.) o al colectivo de personal administrativo de la universidad, que tiene otros
requisitos (cargo, sección, etc.). Es decir, todas las entidades tienen un conjunto de
características comunes importante, pero también tienen algunas diferencias entre sí que hay
que poder representar en el modelo de base de datos.

La generalización/especialización es una relación entre un tipo de entidad general,

denominado superclase  o tipo de entidad padre, y un tipo de entidad más específico,
denominado subclase  o tipo de entidad hijo.

Esta relación permite definir los tipos de entidades en dos niveles: en el primer nivel
encontramos el tipo de entidad general (superclase), que contiene las características comunes a
todas las entidades, y en el segundo nivel encontramos los tipos de entidades que contienen las
características propias de las diferentes especializaciones (subclases).

Cualquier entidad de una subclase debe ser también entidad de la superclase. En sentido
contrario no es imprescindible, es decir, puede haber entidades de la superclase que no
pertenezcan a ninguna subclase.

Los atributos o relaciones de la superclase se propagan hacia las subclases. Es lo que se

denomina herencia de propiedades.

Los atributos de las subclases reciben el nombre de atributos específicos o atributos locales.

Solo las entidades que pertenecen a una subclase determinada tienen valor para estos atributos.
Por el contrario, cualquier entidad que pertenezca a cualquiera de las subclases debe tener valor
para los atributos que se definen en la superclase. En notación UML esta relación se representa
mediante una flecha vacía que sale de las subclases y que se dirige hacia la superclase.

Modelo de generalización/especialización

Siguiendo el ejemplo anterior, la figura 30 muestra un modelo de generalización/especialización

para representar los diferentes tipos de personas que podemos encontrar en el entorno
universitario que hemos descrito. La superclase de la relación es el tipo de entidad ‘persona’
(Person), que incluye los datos básicos que nos interesa almacenar para cualquier persona del
modelo. A continuación encontramos las tres subclases descritas antes, que contienen la
información relevante de los estudiantes (Student), profesores (Professor) y personal de
administración (Administrative).

Por lo tanto, cualquier entidad de la subclase ‘estudiante’ tiene todos los atributos de la
superclase ‘persona’ y además los atributos específicos o locales.

Figura 30. Ejemplo de generalización/especialización

Las subclases se denominan especializaciones de la superclase y la superclase se

denomina generalización de las subclases.
En el momento de realizar el diseño del modelo, se puede optar por una estrategia descendente
(top-down) y empezar diseñando la superclase como tipo de entidad principal, y posteriormente
refinar el diseño añadiendo las características específicas de las subclases. Esta metodología de
diseño recibe el nombre de proceso de especialización.

La estrategia contraria, basada en una metodología ascendente (bottom-up), consiste en diseñar

las subclases y posteriormente, en el momento de darse cuenta de las características comunes
entre estas subclases, definir la superclase que las une. Esta metodología recibe el nombre
de proceso de generalización.

Relación entre las entidades en una generalización/especialización

La figura 31 muestra una posible relación entre las entidades del ejemplo anterior. Podemos ver
que hay cinco entidades de la superclase ‘persona’ (Person), con los
nombres John, Mary, Paul, Fred y Sally, dos de las cuales son estudiantes y pertenecen a la
subclase ‘estudiante’ (Student), una es un profesor (Professor) y otra es administrativo
(Administrative). La entidad Mary no pertenece a ninguna de las subclases y solo pertenece a la
superclase.

Figura 31. Ejemplo de la relación entre las entidades en una generalización/especialización

Tanto las superclases como las subclases pueden intervenir en relaciones sin ningún tipo de
restricción.

Generalización/especialización con tipos de relaciones

En la figura 32 se puede ver cómo la superclase ‘persona’ (person) participa en la relación ‘vive’
(Lives) con la entidad ‘población’ (City) y la subclase ‘profesor’ (Professor) participa en la
relación ‘dirige’ (Heads) con la entidad ‘departamento’ (Department). Evidentemente no tiene
sentido considerar que cualquier entidad de la superclase ‘persona’ puede dirigir un
departamento y hay que indicar en el modelo conceptual que solo aquellas personas que son
entidades de la subclase ‘profesor’ pueden dirigir un departamento.

Figura 32. Ejemplo de generalización/especialización con tipos de relaciones

Hay dos motivos principales que inducen al uso de las relaciones de
generalización/especialización entre tipos de entidades:

1) El primer motivo se debe al hecho de que en determinadas situaciones hay que modelizar
casos en los que algunos atributos sólo son aplicables a algunas de las entidades, pero no a toda
la superclase. Por lo tanto, se define una relación de generalización/especialización que permite
agrupar estas entidades en una subclase y añadirles los atributos necesarios, mientras continúan
formando parte de la superclase y compartiendo el resto de los atributos con todas las entidades
de la superclase. La figura 32 muestra un ejemplo de este caso.

2) La segunda situación se produce cuando hay que modelizar tipos de relaciones que solo se
pueden establecer con algunas entidades de la superclase. Por ejemplo, supongamos que hemos
creado un tipo de entidad ‘trabajador’ (Worker) para modelizar a los trabajadores de una fábrica
y queremos establecer un tipo de relación que indique de qué empresa de trabajo temporal
provienen. Lógicamente, esta relación sólo es aplicable a los trabajadores que sean temporales y
no a los trabajadores fijos de la empresa. Para modelizar esta situación podemos crear una
subclase para identificar a los ‘trabajadores temporales’ (TemporaryWorker) y relacionarlos con
el tipo de entidad de las empresas temporales (EmploymentAgency). De este modo, solo los
trabajadores que pertenezcan a la subclase podrán estar relacionados con la empresa de trabajo
temporal. La figura 33 muestra un esquema que ejemplifica este caso.

Figura 33. Ejemplo de generalización/especialización que incorpora relaciones con la subclase

Por lo tanto, un proceso de generalización/especialización permite:

Relación ‘es-un’ o ‘es-una’

Una relación de generalización/especialización a veces también se denomina relación ‘es-un’ o ‘es-una’

por la manera de hacer referencia al concepto. Por ejemplo, un estudiante ‘es una’ persona, un

profesor ‘es una’ persona.

 Crear una taxonomía de tipos de entidades, definiendo un conjunto de entidades tipo

específicas (subclases) a partir del tipo de entidad genérica (superclase).

 Establecer atributos específicos adicionales a cada tipo de entidad específico (subclase).

 Establecer tipos de relaciones adicionales entre los tipos de entidades específicos

(subclases) y otros tipos de entidad.

Generalización de tipo de entidad

Supongamos que queremos modelizar una base de datos para mantener información sobre los
vehículos que tiene una empresa. En un momento del diseño aparece el tipo de entidad ‘coche’
(Car), del que queremos almacenar el número de bastidor, la matrícula, la marca, el modelo, la
fecha de matriculación, el número de plazas disponibles y si es un vehículo todoterreno o no.
Más adelante, en la misma fase de diseño, nos aparece el tipo de entidad ‘camión’ (Truck), del
que queremos almacenar el número de bastidor, la matrícula, la marca, el modelo, la fecha de
matriculación, el peso máximo autorizado de carga y el número de ejes del camión. La figura 34
muestra el diseño conceptual de los dos tipos de entidades.

Figura 34. Ejemplo de los tipos de entidad ‘coche’ (Car) y ‘camión’ (Truck)
Pero en este punto el diseñador se da cuenta de que los dos tipos de entidad comparten una
buena parte de los atributos y de que sería interesante generalizar esta parte común para
obtener una nueva superclase que permita identificar un vehículo, sea camión o coche. Por lo
tanto, se crea la superclase ‘vehículo’ (Vehicle), que contiene todos los atributos comunes (el
número de bastidor, la matrícula, la marca, el modelo y la fecha de matriculación), y entonces
se crean dos subclases con los atributos propios de cada una. La figura 35 muestra el diseño
conceptual después del proceso de generalización.

Figura 35. Ejemplo de generalización de los tipos de entidad ‘coche’ (Car) y ‘camión’ (Truck)

Observación

A partir de este punto, denominamos superclase a los tipos de entidad genéricos, y subclase, a los

tipos de entidad específicos.

3.1.1.Restricciones en la generalización/especialización
Hay tres tipos de restricciones básicas en los procesos de generalización/especialización.

1) Pertenencia definida por atributo o usuario

En algunos casos la superclase contiene un conjunto de atributos que indican, para cada entidad,
qué subclase pertenece. En estos casos se denominan subclases de predicado
definido o subclases de condición definida.

Ejemplo de pertenencia definida por atributo o usuario

Continuando con el ejemplo anterior de los vehículos, podemos especificar a qué subclase
pertenece cada entidad a partir de un atributo que define el tipo de vehículo (vehicleType) de la
superclase, que tome valor igual a  car en caso de que la entidad tenga que pertenecer a la
subclase Car o que tome valor igual a truck  en caso de que tenga que pertenecer a la
subclase Truck.

En caso de que todas las subclases tengan una condición de pertenencia en el mismo atributo de
la superclase, el atributo recibe el nombre de atributo definitorio o discriminador y se dice
que la relación de generalización/especialización es de atributo definido. En caso de que no
exista ningún atributo que permita identificar la pertenencia de las entidades a las diferentes
subclases, se dice que es una generalización/especialización definida por el usuario.
En UML, el atributo discriminador, si lo hay, se indica en la flecha de la relación de
generalización/especialización. La figura 37 muestra un ejemplo de
generalización/especialización de atributo definido.

2) Restricción de exclusividad

Otra restricción que se puede aplicar a las generalizaciones/especializaciones es la restricción

de exclusividad, que indica si las subclases han ser disjuntas entre sí. Dicho de otro modo,
expresa si una misma entidad puede pertenecer a más de una subclase. En este sentido, la
generalización/especialización puede ser:

 Disjunta (3) : una entidad solo puede pertenecer a una única subclase.

En inglés, disjoint.
(3) 

 Solapada (4) : una entidad puede pertenecer a más de una subclase al mismo tiempo.
Generalización/especialización solapada

La figura 36 muestra un ejemplo de generalización/especialización solapada. En este modelo

podemos ver la superclase ‘punto de interés’ (PointOfInterest), que permite almacenar
información sobre diferentes puntos de interés turístico de una zona. Este concepto se puede
especializar en diferentes subclases. Por ejemplo, podemos decir que los hoteles (Hotel), los
restaurantes (Restaurant) y los conventos (Convent) son especializaciones de ‘punto de interés’.
Debe tenerse en cuenta que puede haber hoteles que también son restaurantes, o conventos
que hacen funciones de hotel. Esto implica que una misma entidad puede pertenecer a más de
una subclase al mismo tiempo. Por lo tanto, podemos decir que esta
generalización/especialización es de tipo solapada.

Figura 36. Ejemplo de generalización/especialización solapada

3) Restricción de participación

Finalmente, la última de las restricciones referentes a la generalización/especialización se

denomina restricción de participación e indica la obligatoriedad de las entidades de
pertenecer a alguna de las subclases o no. Siguiendo este enfoque se puede establecer la
clasificación siguiente:

En inglés, overlapping.
(4) 

 Total (5) : toda entidad de la superclase debe pertenecer a alguna de las subclases.

En inglés, complete.
(5) 
  Parcial (6) : puede haber entidades de la superclase que no pertenezcan a ninguna de las
subclases.

En una generalización/especialización con restricción de participación total, todas las entidades

deben pertenecer a una o más subclases. Por lo tanto, todas las entidades pertenecen a alguna
de las subclases y no puede haber entidades que pertenezcan exclusivamente a la superclase.
En estos casos se dice que la superclase es un tipo de entidad abstracta, puesto que no
contiene ninguna entidad. Los tipos de entidades abstractas en UML se indican con el nombre del
tipo de entidad en letra cursiva.

Si en una generalización/especialización no se indican las restricciones, por defecto se asume

que se trata de una relación definida por el usuario, solapada y parcial.

La figura 37 muestra la nomenclatura para identificar los dos casos en UML. En la misma
relación se indica entre llaves {} los conceptos de total o parcial (complete/incomplete) y
disjunta o solapada (disjoint/overlapping).

Generalización/especialización disjunta parcial y completa

Las figuras 37 y 38 muestran un esquema similar, con una diferencia importante en el diseño.

En la figura 37 podemos ver la superclase ‘vehículo’ (Vehicle) y las subclases ‘coche’ (Car) y
‘camión’ (Truck) con una herencia disjunta e incompleta. Esto nos indica, en primer lugar, que
una entidad no puede pertenecer a las dos subclases al mismo tiempo, es decir, que no puede
haber un vehículo que sea coche y camión a la vez, y, en segundo lugar, que algunas entidades
puede ser que no pertenezcan a ninguna de las subclases, es decir, que puede haber instancias
de vehículos que no son coches ni camiones.

En la figura 38, en cambio, se presenta una herencia similar, pero en este caso es completa. El
hecho de que sea completa implica que la superclase no podrá contener entidades; por lo tanto,
será un tipo de entidad abstracta. Es decir, que cualquier entidad de ‘vehículo’ deberá ser un
coche o un camión.

Figura 37. Ejemplo de generalización/especialización disjunta (disjoint) y parcial (incomplete)

Figura 38. Ejemplo de generalización/especialización disjunta (disjoint) y completa (complete)

Los conceptos de restricciones de exclusividad y de participación son independientes entre sí, y,
por lo tanto, se pueden combinar para dar lugar a cuatro posibles restricciones de
generalización/especialización:

 Disjunta y total

 Disjunta y parcial

 Solapada y total

 Solapada y parcial

En inglés, incomplete.
(6) 

3.1.2.Herencia simple y múltiple

Una subclase puede tener a la vez subclases que permitan refinar más los conceptos.

La herencia simple en un proceso de generalización/especialización se da cuando todos los

tipos de entidades involucradas en la relación sólo tienen una superclase, es decir, hay un único
tipo de entidad padre o clase raíz. Como resultado de esta condición se genera una estructura en
forma de árbol.

Herencia simple

La figura 39 muestra una relación de herencia simple, en la que a partir de la superclase raíz
‘vehículo’ (Vehicle) y del atributo discriminador ‘tipo de vehículo’ (vehicleType) se refinan dos
subclases según si el vehículo es un coche (Car) o un camión (Truck). Al mismo tiempo, el tipo
de entidad ‘coche’ se especializa en dos subclases, según si es un turismo (Tourism) o un
vehículo todoterreno (SUV). El tipo de entidad ‘coche’ es superclase en esta nueva relación y a la
vez subclase en la relación con el tipo de entidad ‘vehículo’. Hay que señalar, además, que el
tipo de entidad ‘coche’ se convierte en abstracta, puesto que la especialización es completa.

Figura 39. Ejemplo de herencia simple

El tipo de entidad origen de la jerarquía, en este caso el tipo de entidad ‘vehículo’, es
la superclase raíz o tipo de entidad base. Las subclases que no tienen otras subclases, en
este caso las clases ‘turismo’, ‘todoterreno’ y ‘camión’ son clases hija.

La herencia múltiple en un proceso de generalización/especialización se da cuando alguno de

los tipos de entidad involucrados en la relación tiene dos o más superclases. En estos casos se
obtiene una estructura de tipo grafo dirigido.

Herencia múltiple

La figura 40 muestra una relación de herencia múltiple. A partir del tipo de entidad base, en este
ejemplo el tipo de entidad ‘vehículo’ (Vehicle), creamos una especialización en la que indicamos
si se trata de un vehículo terrestre (LandVehicle) o acuático (WaterVehicle). Los vehículos
terrestres se pueden especializar en coches (Car), camiones (Truck) o anfibios (Amphibious).
Los vehículos anfibios se pueden desplazar por tierra y por medios acuáticos, y, por lo tanto,
este tipo de entidad también es una especialización del tipo de entidad ‘vehículo acuático’, junto
con los tipos de entidades ‘barco’ (Boat) y ‘submarino’ (Submarine).

Figura 40. Ejemplo de herencia múltiple

Ampliación

El tipo de entidad ‘anfibio’ se denomina subclase compartida, puesto que tiene más de una
superclase o tipo de entidad padre. Hay que señalar que si un atributo o relación que se origina
en una misma superclase es heredado más de una vez por caminos diferentes del entramado,
sólo se puede incluir una sola vez en la subclase compartida. Es decir, los atributos y las
relaciones de la clase ‘vehículo’ sólo pueden aparecer una única vez en la subclase compartida.

Es importante darse cuenta de que la existencia de una única subclase compartida provoca que
la relación sea de herencia múltiple en lugar de simple.

Observación

Una relación de herencia múltiple no puede contener ciclos.

3.1.3.Clasificación múltiple
Un modelo de clasificación múltiple es aquel que permite que una entidad sea instancia de
dos tipos de entidades, E1 y E2, de modo que E1 no es subclase de E2, E2 no es subclase de E1 y no
hay ningún tipo de entidad E3 que sea subclase de E1 y E2.

Las relaciones de generalización/especialización solapadas permiten clasificación múltiple, puesto

que una entidad puede pertenecer a diferentes subclases a la vez. La figura 36 muestra un
ejemplo de generalización/especialización solapada que permite clasificación múltiple.

Otro tipo de clasificación múltiple se da cuando la superclase tiene dos o más jerarquías de
especialización según diferentes discriminantes. Cada entidad puede pertenecer a diferentes
subclases a la vez.

Generalización/especialización con clasificación múltiple

Partiendo del tipo de entidad ‘persona’ (Person) podemos establecer un proceso de

especialización para definir su estado civil, que indique si la persona está soltera (Single),
casada (Married), divorciada (Divorced) o viuda (Widowed). Por otro lado, una persona también
se puede especializar, según el sexo, en ‘hombre’ (Man) o ‘mujer’ (Woman). La figura 41
muestra el modelo conceptual descrito.

Figura 41. Ejemplo de generalización/especialización con clasificación múltiple

3.2.Agregación y composición
La agregación es un tipo de relación entre entidades que indica una relación de “parte-todo”
entre las instancias.

En esta asociación se distingue la parte que representa el “todo”, y que recibe el nombre
de compuesto, y las diferentes “partes” que lo componen, y que reciben el nombre
de componentes.

Agregación

La figura 42 muestra un ejemplo de agregación entre un plato (Dish) y los ingredientes con los
que se ha preparado (Ingredient). Como se puede ver en el modelo conceptual, un plato debe
estar compuesto por uno o más ingredientes, mientras que un mismo ingrediente puede estar
incluido en cualquier número de platos.
 Figura 42. Ejemplo de agregación

La distinción entre tipos de relación y agregación es sutil, y a menudo subjetiva. En general, se

considera que es necesario que haya una cierta relación de ensamblaje, sea física o lógica, entre
las entidades para hablar de agregación en lugar de tipo de relación. La única restricción que
añade la agregación respecto al tipo de relación es que las cadenas de agregaciones entre
entidades no pueden formar ciclos.

La composición es un tipo concreto de agregación en el que la multiplicidad del tipo de entidad

compuesta debe ser como máximo 1 y los componentes presentan dependencia de existencia
hacia el compuesto que tienen.

Es decir, la composición impone dos restricciones respecto a la agregación:

 Cada componente puede estar presente en un único compuesto (la multiplicidad del tipo
de entidad compuesta debe ser como máximo 1).

 Si se elimina el elemento compuesto, hay que eliminar todos los componentes

vinculados a este elemento (los componentes presentan dependencia de existencia
hacia el elemento compuesto).

Composición

Podemos pensar en el conjunto de dedos que forman una mano. La figura 43 muestra el modelo
conceptual en el que se representa la composición de una mano (tipo de entidad Hand) como
conjunto de dedos (tipos de entidad Finger) y donde cada dedo solo puede pertenecer a una sola
mano.

Figura 43. Ejemplo de composición

A diferencia de la agregación, en la composición hay una fuerte dependencia entre la parte

compuesta y la parte componente, de modo que los componentes no pueden vivir sin el
compuesto.

Observación

La agregación se marca con un rombo hueco, mientras que la composición se marca con un rombo

negro.

3.3.Restricciones de integridad
3.3.1.Restricciones en los tipos de entidad
La multiplicidad de tipo de entidad establece un rango de posibles cardinalidades para las
entidades de un determinado tipo de entidad. Es decir, indica cuántas instancias de un
determinado tipo de entidad pueden aparecer en la base de datos.

Generalmente, y por defecto, esta restricción toma el valor indefinido, pero algunas veces puede
ser interesante poder determinar un intervalo en el número de ocurrencias de un tipo de
entidad, especialmente en los casos en los que sólo puede haber una entidad.
Tipos de entidad con multiplicidad 1

Supongamos que queremos modelizar una base de datos para gestionar pequeñas o medianas
empresas. Además de toda la información de clientes, proveedores, productos y otras cosas, hay
que almacenar los datos de la empresa (CIF, nombre, dirección, etc.) para poder mostrar esta
información en facturas, listas y otros datos. Una manera de modelizar este requisito es crear un
tipo de entidad que permita almacenar esta información. En este caso, hay que especificar una
multiplicidad de tipo de entidad igual a 1, puesto que sólo debe haber una entidad con los datos
de la empresa. La figura 44 muestra el diagrama UML de este tipo de entidad.

Figura 44. Tipos de entidad con multiplicidad 1

3.3.2.Restricciones en los atributos

En la definición de los atributos hemos visto algunas restricciones básicas asociadas a los
atributos. Estas restricciones son las siguientes:

 Restricciones de dominio: son las restricciones asociadas al conjunto de posibles

valores legales que puede tomar un atributo. En este sentido, se puede especificar el
tipo de datos que utilizará el atributo (cadena de texto, entero, real, booleano, etc.) y
las restricciones adicionales específicas para cada tipo de datos (por ejemplo, la
longitud en el caso de cadenas de texto o un intervalo válido en el caso de valores
enteros).

 Atributos derivados: son atributos que calculan el valor a partir de otros atributos y
que, por lo tanto, implícitamente son atributos de sólo lectura desde el punto de vista
del usuario o de la aplicación. No obstante, su valor puede cambiar si cambia el valor
de los atributos de los que dependen.

Restricciones de cambiabilidad

Esta restricción indica si los valores de un atributo pueden cambiar o no.

Hay cuatro valores permitidos:

 ‘Cambiable’ (changeable  o unrestricted): es el valor por defecto. Indica que se permite

cualquier cambio sobre el atributo.

 ‘Congelado’ (frozen o readOnly): indica que una vez que se ha asignado valor al atributo
no se podrá modificar ni eliminar.

 ‘Solo-añadir’ (addOnly): indica que una vez que se ha asignado valor al atributo no se
podrá modificar ni eliminar. Pero, en caso de ser un atributo multivalor, sí que se
podrán asignar nuevos valores para este atributo.

 ‘Solo-eliminar’ (removeOnly): indica que la única operación permitida es eliminar el valor

del atributo.
Restricciones de cambiabilidad en los atributos

La figura 45 muestra el tipo de entidad Person, donde podemos ver un atributo no restringido o

cambiable (Name) y dos atributos congelados o de sólo lectura (ID y birthDate).

Figura 45. Ejemplo de restricciones de cambiabilidad en los atributos

3.3.3.Restricciones en los tipos de relaciones

Aparte de las restricciones en la multiplicidad en los tipos de relaciones, es posible expresar
otras restricciones sobre las relaciones en los diagramas UML. A pesar de que la mayoría de los
casos quedan cubiertos con las restricciones que hemos visto hasta ahora, estas nuevas
restricciones permitirán una mayor expresividad del modelo conceptual. A continuación
mencionamos algunas de las más relevantes.

a) Restricciones de cardinalidad min..max

Además de todas las restricciones referentes a la cardinalidad de las relaciones que hemos visto,
es posible indicar un valor o rango concreto en la cardinalidad de una relación. Para indicar un
rango en UML, se expresa el valor mínimo seguido de dos puntos y el valor máximo (min..max).

Ejemplo

La figura 46 modeliza una situación en la que un empleado (Employee) sólo puede pertenecer a
un único departamento (Department) y cada departamento debe tener entre 10 y 50
empleados.

Figura 46. Ejemplo de restricción de cardinalidad min..max

b) Restricción xor

Esta restricción se puede aplicar cuando hay varias relaciones ligadas a un mismo tipo de
entidad. La restricción indica que una entidad sólo puede participar en uno de los tipos de
relación unidos por esta restricción.

Ejemplo

Un coche puede pertenecer a una persona o a una empresa. Para modelizar esta situación, la
figura 47 muestra cómo los tipos de relaciones que unen los tipos de entidad ‘coche’ (Car) con
los tipos de entidad ‘persona’ (Person) y ‘empresa’ (Enterprise) están relacionados con la
restricción xor, que indica que un coche ha de ser de una persona o de una empresa, pero no de
ambos a la vez.

Figura 47. Ejemplo de restricción xor

c) Restricción subset

Esta restricción indica que un tipo de relación es un subconjunto de otro tipo de relación.

Ejemplo de restricción subset

El jefe de un departamento debe pertenecer a este departamento. Para indicar esta restricción,
podemos utilizar el concepto subset  tal como se muestra en la figura 48.

Figura 48. Ejemplo de restricción subset

d) Restricción ordered

Esta restricción indica que hay una relación de orden en la asociación entre los tipos de
entidades.

Ejemplo de restricción subset

Una receta de cocina está formada por un conjunto de dos o más pasos que deben seguir un
orden determinado. Para indicar esta restricción, podemos utilizar el concepto ordered  tal como
se muestra en la figura 49.

Figura 49. Ejemplo de restricción ordered

e) Restricciones de cambiabilidad

Esta restricción indica si los valores del extremo de una relación pueden cambiar o no.

Hay cuatro valores permitidos:

 ‘Cambiable’ (changeable  o unrestricted): es el valor por defecto. Indica que se permite

cualquier cambio sobre la asociación.

 ‘Congelado’ (frozen o readOnly): indica que una vez que la relación ha sido creada no se
podrá modificar ni eliminar. Tampoco se podrán crear nuevas relaciones.
  ‘Solo-añadir’ (addOnly): indica que una vez que la relación ha sido creada no se podrá
modificar ni eliminar. Pero sí que se podrán crear nuevas relaciones.

 ‘Solo-eliminar’ (removeOnly): indica que la única operación permitida es eliminar el valor

de la relación.

Restricciones de cambiabilidad en los tipos de relaciones

Para poder comparar diferentes ejemplos relacionados con la cambiabilidad, la figura 50 nos
muestra tres situaciones diferentes en las que intervienen los mismos tipos de entidades. En la
primera, representamos la ciudad donde vive una persona, que evidentemente puede cambiar.
Por lo tanto, el extremo de la asociación que conecta con el tipo de entidad ‘ciudad’ (City) es
cambiable o no restringida (opción por defecto). En la segunda situación, representamos el lugar
de nacimiento de una persona, y en este caso etiquetamos como congelado el extremo de esta
asociación. Finalmente, si consideramos las ciudades donde ha vivido una persona, etiquetamos
con el atributo ‘Solo-añadir’, puesto que la lista de ciudades donde ha vivido una persona puede
aumentar, pero no modificar o eliminar valores existentes.

Figura 50. Ejemplos de restricciones de cambiabilidad en los tipos de relaciones

3.3.4.Otras restricciones
En el análisis de requisitos muchas veces se pueden encontrar requisitos o restricciones de
carácter semántico. Estas restricciones dependen completamente del problema, y hay que dejar
constancia de ellas. Generalmente, se utilizan notas ligadas a los tipos de entidades, atributos o
tipos de relaciones a los que hacen referencia para dejar constancia de ellas.

Uso de notas para indicar otras restricciones

La figura 51 muestra tres notas que permiten notaciones de cualquier tipo para clarificar
conceptos del modelo, asociadas a un tipo de entidad, un atributo o un tipo de relación.

Figura 51. Ejemplo de uso de notas para indicar requisitos o restricciones del modelo
3.4.Modelización de datos históricos
Las bases de datos modelizan el estado de algunos aspectos del mundo exterior. Generalmente,
sólo modelizan un estado del mundo real –el estado actual– y no almacenan información sobre
los estados anteriores. Cuando se produce un cambio de estado en el mundo real, la base de
datos se actualiza y se pierde la información sobre los estados anteriores. No obstante, en
algunas aplicaciones es importante poder almacenar y recuperar información sobre los estados
anteriores del sistema.

Básicamente hay dos tipos de requisitos a la hora de modelizar el tiempo asociado a un estado
del mundo real:

1) Instante de tiempo: en algunas acciones sólo hay que señalar en qué instante de tiempo han
ocurrido. Para modelizar este tipo de actividad, se puede añadir una marca de tiempo que
permita identificar en cada instancia el momento de tiempo con el que está asociado. Este
comportamiento se puede modelizar de dos maneras:

 Añadiendo un atributo de tipo ‘fecha y hora’. Cada instancia indica el valor de tiempo en
este atributo.

 Añadiendo una relación con el tipo de entidad ‘fecha’ (Date), que contiene un atributo de
tipo ‘fecha y hora’.

2) Intervalo de tiempo: otras acciones tienen un tiempo de vida. Es decir, están activas durante
un intervalo de tiempo específico. En estos casos hay que indicar el intervalo de tiempo en el
que es válida cada una de las entidades. Este comportamiento se puede modelizar de dos
maneras:

 Si se quiere aplicar este criterio sobre un concepto que está modelizado como un tipo de
entidad, se pueden añadir dos atributos de tipo fecha y hora en la entidad para indicar
el inicio y el final del intervalo.

 Si se quiere aplicar este criterio sobre un concepto que está modelizado como una
relación, hay que añadir en la relación un tipo de entidad ‘fecha’ (Date) que
determinará los tiempos inicial y final del intervalo.

Modelización de datos históricos

La lectura de un sistema de monitorización de una fábrica irá tomando diferentes lecturas en

diferentes estados de tiempo. Nos interesa guardar el valor de la lectura y el momento de
tiempo en el que se ha producido esta lectura.

En otras situaciones nos interesa definir no un instante de tiempo, sino un intervalo de tiempo.
Por ejemplo, supongamos que una empresa tiene un conjunto de vehículos con diferentes
características y un conjunto de comerciales y personal técnico que los utiliza. Según las tareas
y las visitas de cada día, cada uno de los comerciales y técnicos puede necesitar un vehículo
diferente. Por lo tanto, a esta empresa le interesará saber qué coche ha estado utilizando cada
uno de los comerciales y técnicos en cada momento (por ejemplo, en caso de recibir una sanción
de tráfico). Para modelizar esta situación hay que definir un tipo de relación cuaternaria en la
que intervienen un comercial, un vehículo y dos entidades de tiempo (una que indica el inicio de
la asociación y otra que indica cuándo la asociación deja de ser válida). La figura 52 muestra un
modelo que implementa la situación descrita.

Figura 52. Ejemplos de situación con modelización de datos históricos

La tabla 2 muestra, a modo de ejemplo, una posible configuración de entidades del ejemplo
anterior en un instante de tiempo concreto.

Tabla 2. Ejemplo de representación de entidades del modelo de la figura 52

ID name numberPlate starts ends

33941857B John 8754-GFD 2001-05-12 09:25 2001-05-12 17:36

33941857B John 1258-CGC 2001-05-17 11:13 --

15488574Q Mary 8754-GFD 2001-05-10 15:11 2001-05-10 19:47

15488574Q Mary 1258-CGC 2001-05-13 07:02 2001-05-14 14:41

15488574Q Mary 1126-BMR 2001-05-16 20:14 --

 ID name numberPlate starts ends

25486257F Fred 1126-BMR 2001-05-11 09:13 2001-05-11 18:56

3.5.Ejemplo completo
A continuación planteamos un ejemplo completo para poder ver un esquema conceptual en el
que aparezcan algunos de los elementos vistos en este apartado. Continuaremos con el ejemplo
del apartado anterior, que se basa en el diseño de una base de datos para la gestión
universitaria.

A continuación enumeramos los diferentes aspectos de los requisitos de los usuarios que hay
que tener en cuenta al realizar el diseño conceptual de la base de datos:

1) La universidad está formada por diferentes departamentos. Cada departamento está formado
por un conjunto de profesores y está dirigido por un único profesor. Nos interesa conocer el
nombre de los departamentos y el número de profesores que trabajan en cada uno, así como su
localización física, la dirección, teniendo en cuenta que una misma dirección puede existir en
más de una ciudad.

2) Para cada profesor nos interesa poder almacenar sus datos personales como, por ejemplo,
nombre, DNI, fecha de nacimiento, sexo, dirección y números de teléfono. Para los profesores
que son directores de departamento, nos interesa poder identificar la fecha en la que empezaron
a ejercer este cargo.

3) En la universidad se imparten un conjunto de asignaturas. Interesa saber, para cada una de
estas asignaturas, el código, el nombre, el número de créditos, la descripción, si tiene
laboratorio asociado y los prerrequisitos, es decir, otras asignaturas que hay que haber cursado
anteriormente. Además, hay que tener en cuenta que una asignatura pertenece a un único
departamento.

4) Los departamentos están agrupados en escuelas o facultades. Por ejemplo, el departamento

de matemáticas pertenece a la facultad de ciencias. Un departamento pertenece a una única
escuela o facultad.

5) Los estudiantes son una parte muy importante de la base de datos. Se quiere almacenar
información sobre los datos personales de estos estudiantes (nombre, DNI, fecha de nacimiento,
sexo, dirección y números de teléfono) y su número de identificación universitaria (conocido
como NIU).

6) Cada estudiante puede estar matriculado de varias asignaturas en cada semestre. Y para
cada una de las asignaturas en las que está matriculado cada semestre, tenemos que poder
almacenar una nota final.

7) También se quiere dejar constancia de las fechas de inicio y final de cada semestre.

8) Las asignaturas se agrupan en los diferentes cursos que forman cada uno de los grados que
ofrece la universidad. Por ejemplo, la asignatura de Álgebra pertenece al primer curso del grado
de Matemáticas. Sobre cada uno de los cursos sólo nos interesa almacenar el conjunto de
asignaturas que lo forman. Sobre cada uno de los grados, nos interesa almacenar información
referente a su número de créditos (obligatorios, opcionales y totales) y una descripción.

9) Los estudiantes estudian uno o más grados.

10) Cuando un estudiante se gradúa, elabora un proyecto de final de carrera sobre el que nos
interesa almacenar información acerca de la fecha en la que se ha presentado, la nota que ha
obtenido y el profesor que lo ha dirigido.
A partir de los requisitos expresados, la figura 53 muestra un diagrama del modelo conceptual.
Como hemos comentado, este modelo no es único, sino que puede haber diversas
aproximaciones e interpretaciones válidas para una misma representación del mundo real.

Figura 53. Diagrama del modelo conceptual para la segunda aproximación de la base de datos de gestión

universitaria

Ampliación

Resumen
En este módulo hemos visto el proceso de diseño conceptual. Este proceso es una de las etapas
del diseño de bases de datos, concretamente, es la segunda etapa, y se realiza después del
análisis de requisitos.

El diseño conceptual permite crear un esquema conceptual de alto nivel e independiente de la

tecnología de implementación a partir de las especificaciones y los requisitos de un problema del
mundo real.

El enfoque de este material nos ha permitido ver las bases del diseño conceptual empleando los
diagramas UML como sistema de notación.

En la primera parte de este material hemos visto una breve introducción en la que hemos
detallado las bases, los objetivos y los requisitos del diseño conceptual y de los diagramas en
lenguaje UML.

En la segunda parte hemos visto los elementos básicos de modelización en el diseño conceptual.
Entre los elementos principales hay que destacar los tipos de entidades, los atributos y los tipos
de relaciones. A pesar de que estos tres elementos forman la base principal del modelo
conceptual, también hemos visto los tipos de entidades asociativas y los tipos de entidades
débiles, que permiten una mayor riqueza en la representación del modelo conceptual.

Finalmente, en la tercera parte de este material hemos visto algunos de los elementos
avanzados en el diseño conceptual. Los elementos vistos en la parte anterior no permiten
representar situaciones que encontramos en el mundo real y que queremos poder representar
en nuestro modelo. Fruto de esta necesidad se amplía el modelo para incluir conceptos como la
generalización/especialización, la agregación o la composición, que permiten una mayor riqueza
en la representación del modelo conceptual. Para finalizar este texto, nos hemos referido
brevemente a las restricciones de integridad básicas y a la modelización de datos históricos.

Glosario
atributo m
 Propiedad que interesa representar de un tipo de entidad.

clase f
Nombre que reciben los tipos de entidades en el modelo UML.

conectividad f
Expresión del tipo de correspondencia entre las entidades de una relación.

diseño conceptual m
Etapa del diseño de una base de datos que obtiene una estructura de la información de
la futura base de datos independiente de la tecnología que se quiere emplear.

diseño lógico m
Etapa del diseño de una base de datos que parte del resultado del diseño conceptual y lo
transforma de manera que se adapte al modelo de sistema gestor de bases de datos con
el cual se desea implementar la base de datos.

generalización/especialización f
Construcción que permite reflejar que existe un tipo de entidad general, llamada
superclase, que se puede especializar en diferentes tipos de entidades más específicas,
llamadas subclases.

grado de una relación m

Número de entidades que asocia la relación.

entidad f
Objeto del mundo real que podemos distinguir del resto de objetos y del cual nos
interesan algunas propiedades.

lenguaje unificado de modelización m

Lenguaje gráfico para modelizar, visualizar, especificar, construir y documentar sistemas
de software o de bases de datos.
sigla UML
en  unified modeling language

modelo entidad-interrelación m
Modelo de datos de alto nivel ampliamente utilizado para el diseño conceptual de las
aplicaciones de bases de datos. El objetivo principal del modelo ER es permitir a los
diseñadores reflejar en un modelo conceptual los requisitos del mundo real.

sistema gestor de bases de datos m

Tipo de software específico dedicado a servir de interfaz entre la base de datos, el
usuario y las aplicaciones que la utilizan.
sigla SGBD
en  database management system (DBMS)

tipo de relación m
 Asociación entre entidades.

tipo de entidad asociativa m

Tipo de entidad resultante de considerar una relación entre entidades como una nueva
entidad.

tipo de entidad débil m

Tipo de entidad cuyos atributos no la identifican completamente, sino que solo la
identifican de manera parcial.

tipo de relación recursiva m

Asociación a la cual alguna entidad está asociada más de una vez.

Bibliografía
Elmasri, Ramez; Navathe, Shamkant, B. (2007). Fundamentos de sistemas de bases de
datos (5.ª ed.). Madrid: Pearson Educación.

Teorey, T. J. (2008). Database design: Know it all. Burlington: Morgan Kaufmann.

Camps, R.; Cassany M. J.; Conesa, J.; Costal, D.; Figuls, D.; Martín, C.; Rius, A.;
Rodríguez, M. E.; Urpí, T. (2011). Uso de bases de datos. FUOC.

Date, C. J. (2001). Introducción a los sistemas de bases de datos. Madrid: Pearson Educación.

Rumbaugh, James; Jacobson, Ivar; Booch, Grady (2007). El lenguaje unificado de

modelado. Manual de referencia (2.ª ed.). Madrid: Pearson Educación.

Diseño lógico de bases de datos

 Xavier Burgués Illa

Los textos e imágees publicados en esta obra están sujetos –excepto que se indique lo contrario– a

una licencia Creative Commons de tipo Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND)

v.3.0. Se puede copiar, distribuir y transmitir la obra públicamente siempre que se cite el autor y la

fuente (Fundació per a la Universitat Oberta de Catalunya), no se haga un uso comercial y ni obra

derivada de la misma. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice
 Introducción

 Objetivos

 1.Introducción al diseño lógico

 2.Reconsideración del modelo conceptual: trampas de diseño

o 2.1.Abanico

o 2.2.Corte
 o 2.3.Pérdida de afiliación

o 2.4.Aridad de los tipos de relación

o 2.5.Semántica de los tipos de entidad

 3.Diseño lógico: transformación del modelo conceptual en el modelo relacional

o 3.1.Conceptos previos del modelo relacional

o 3.2.Impacto del uso de los valores nulos

o 3.3.Tipo de entidad

 3.3.1.Atributos multivaluados
o 3.4.Tipo de relación

 3.4.1.Tipos de relaciones binarias con una multiplicidad 1

 3.4.2.Tipos de relaciones binarias reflexivas

 3.4.3.Tipos de relaciones binarias de composición

 3.4.4.Tipos de relaciones n-arias
o 3.5.Tipos de entidades asociativas

o 3.6.Generalizaciones

o 3.7.Restricciones

 3.7.1.Multiplicidades

 3.7.2.Generalizaciones

 3.7.3.Abrazos mortales
o 3.8.Reconsideraciones

 4.Normalización
o 4.1.Anomalías

o 4.2.Conceptos previos

o 4.3.Teoría de la normalización

 4.3.1.Primera forma normal

 4.3.2.Segunda forma normal

 4.3.3.Tercera forma normal

 4.3.4.Forma normal de Boyce-Codd

 4.3.5.Reglas de Armstrong

 4.3.6.Algoritmo de análisis

 4.3.7.Algoritmo de síntesis

 4.3.8.Cuarta forma normal

 4.3.9.Quinta forma normal

o 4.4.Práctica de la normalización

 Resumen

 Glosario
  Bibliografía

Introducción
El proceso de desarrollo de una base de datos para un sistema de información es un proceso
secuencial formado por un conjunto de diferentes fases que nos acercan al resultado final de
manera progresiva. Después de la etapa de diseño conceptual, que permite obtener una
especificación basada en el esquema conceptual generado a partir de los requisitos y el análisis
del dominio de la aplicación, tenemos que llevar a cabo el diseño lógico.

Empezaremos el estudio de este módulo con algunas reflexiones sobre posibles errores que se
pueden haber cometido en la etapa de diseño conceptual y que conviene repasar antes de
tomarlo como punto de partida del diseño lógico.

A continuación, nos centraremos en la etapa de diseño lógico y estudiaremos las pautas para
llevarla a cabo. El diseño lógico tiene por objetivo conseguir un esquema lógico de la base de
datos a partir del esquema conceptual que hemos obtenido en la fase anterior. Se puede
considerar, pues, como la etapa que permite transformar un modelo conceptual en un modelo
lógico de la futura base de datos.

En este material utilizaremos modelos conceptuales basados en el lenguaje UML y los

transformaremos en modelos lógicos relacionales, denominados simplemente modelos
relacionales.

En este módulo también veremos la teoría de la normalización, que permite asegurar que el
esquema relacional satisface una serie de condiciones que garantizan una mejor calidad de la
base de datos.

Objetivos
El contenido de estos materiales didácticos os permitirá alcanzar los objetivos siguientes:

1. Entender el diseño lógico como actividad de transformación.

2. Conocer las trampas de diseño e identificar las situaciones en las que se pueden
producir.

3. Conocer los efectos negativos que puede suponer la existencia de valores nulos.

4. Conocer las alternativas de transformación de los elementos del modelo conceptual

en los diferentes elementos del modelo relacional.

5. Conocer y aplicar los diferentes mecanismos de definición de restricciones en el

modelo relacional.

6. Conocer las anomalías que se pueden producir en un esquema no normalizado.

7. Conocer las formas normales hasta la quinta, y ser capaces de aplicarlas a un

esquema dado.

1.Introducción al diseño lógico

El diseño lógico es una etapa intermedia de las que componen el proceso de desarrollo de una
base de datos. Por lo tanto, se parte de los resultados de una etapa previa (la etapa del diseño
conceptual) y se producen otros nuevos, que a su vez servirán como punto de entrada de una
etapa posterior (el diseño físico).

Si hablamos de desarrollo de software en general, la etapa de diseño lógico parte de las

especificaciones del sistema para diseñar una solución independiente de la tecnología, que
después se refinará y se implementará en etapas posteriores del desarrollo. Si nos centramos en
la parte de datos del diseño lógico, partiremos de la parte de la especificación que corresponde a
la modelización conceptual del dominio de la aplicación, para obtener un esquema de la base de
datos expresado en un lenguaje correspondiente a algún modelo lógico de base de datos, pero
sin adoptar una versión concreta de ningún sistema de gestión de base de datos (SGBD) ni
entrar en detalles de optimización o refinamiento de la base de datos, que se dejarán para
etapas posteriores de desarrollo.

Existen varias opciones para el lenguaje de modelización conceptual, en el que estará expresada
la información de entrada al diseño lógico, y para el modelo lógico que utilizaremos para
expresar la solución resultante de este diseño. En este material, utilizaremos modelos
conceptuales basados en el lenguaje UML y los transformaremos en modelos lógicos
relacionales.

Empezaremos el estudio de este módulo con el tratamiento de las denominadas trampas de

diseño, que son errores que se pueden haber cometido al hacer el diseño conceptual. Es
necesario asegurarse de que el modelo conceptual está libre de estos antes de tomarlo como
punto de partida para iniciar el diseño lógico.

A continuación, nos centraremos en la etapa de diseño lógico propiamente dicha. Analizaremos

un diagrama de clases de UML y veremos cuáles son las diferentes alternativas de
transformación de cada uno de los elementos de dichos diagramas en elementos del modelo
relacional. También estudiaremos las ventajas y los inconvenientes de cada alternativa para
poder elegir de manera correcta, en caso de disponer de más de una alternativa.

En este módulo también veremos la teoría de la normalización. Entre otras aplicaciones, esta
teoría permite poner un sello de calidad al diseño obtenido desde el punto de vista de la
ausencia de redundancia, facilidad de mantenimiento de la consistencia y eficiencia en las
operaciones de actualización de la base de datos derivada del diseño lógico. Además, en el
supuesto de que el diseño no satisfaga las propiedades requeridas, la teoría de la normalización
incluye procedimientos de corrección del diseño.

2.Reconsideración del modelo conceptual: trampas de

diseño
En este apartado veremos algunos errores que se pueden cometer durante la elaboración del
diseño conceptual de la base de datos. Estos errores están relacionados con conceptualizaciones
erróneas de la realidad que se han incorporado en el modelo conceptual.

Precisamente por la naturaleza del diseño conceptual, que implica interpretar y modelizar
conceptos del mundo real, surge la posibilidad de cometer errores dependiendo de si la
interpretación que hacemos es del todo correcta o no. Es importante evitar estos errores, puesto
que pueden provocar graves problemas en fases posteriores del desarrollo de la base de datos.

Algunos de estos errores son recurrentes y siguen unos patrones que nos permiten
identificarlos; son lo que denominamos trampas de diseño. A continuación presentaremos
cinco de estas trampas, puesto que si las conocemos nos será más sencillo detectarlas y evitar
caer en ellas.

Reflexión

Hay diferentes tipos de diagramas para representar los modelos conceptuales, pero en este texto

emplearemos los diagramas de clases del lenguaje UML.

2.1.Abanico
El abanico es la primera trampa que se nos puede presentar cuando tenemos tres tipos de
entidades relacionadas mediante tres tipos de relaciones binarias (1..*).

Decimos que hemos caído en la trampa del abanico cuando uno de los tipos de relación es
derivado de los otros dos y, al no querer incorporar el derivado en el esquema conceptual, nos
equivocamos y eliminamos uno de los que no lo es.

Ilustrémoslo con un ejemplo. Imaginemos que intentamos modelizar las grabaciones que hace
una discográfica de música clásica. En la producción de esta compañía, cada obra (work) es
interpretada (play) por una orquesta (orchestra) una sola vez, y cada orquesta está dirigida
siempre por un director (conductor). La situación se puede modelizar como se indica en la figura
1.

Figura 1. Tres tipos de relaciones binarias, uno de los cuales es derivado

Este modelo, a pesar de que contiene los elementos (tipos de entidad y tipos de relaciones)
necesarios, no es del todo correcto, porque falta una restricción: si una orquesta interpreta
alguna obra y un director dirige dicha orquesta, el director dirige la obra. Es decir, el tipo de
relación conductsWork es un tipo derivado a partir de los otros dos.

Si decidimos representar el dominio con el esquema de la figura 2, habremos caído en la

trampa, puesto que habremos sacado el tipo de relación plays en lugar de
eliminar conductsWork.

También puede suceder que caigamos en la trampa directamente, sin ser conscientes de que
incluimos un tipo de relación derivado y, en cambio, no incluyamos en el modelo el tipo de
relación a partir del cual se puede derivar la nueva información.

Al caer en la trampa, dejamos de representar información relevante. En el ejemplo, no sabemos

qué orquesta ha interpretado cada obra. El nombre abanico tiene su origen en la forma que
resulta de representar las instancias y los vínculos entre ellas, como se muestra en la figura 2.

Figura 2. La trampa del abanico

El modelo conceptual correcto, sin representar el tipo de relación derivado, se puede ver en la
figura 3.

Figura 3. Esquema correcto de la figura 1

Reflexión

Cuando hay elementos derivados, podemos decidir eliminarlos del diagrama de clases si pensamos

que de este modo queda más claro y el elemento derivado no es de interés para la base de datos que

diseñamos.

2.2.Corte
Esta otra trampa se presenta en la misma situación que la del abanico: cuando tres tipos de
entidad están relacionados por tres tipos de relaciones binarias (1..*), uno de los cuales es un
tipo derivado de los otros dos.

Decimos que hemos caído en la trampa del corte cuando, al no querer incorporar el tipo de
relación derivado en el esquema conceptual, nos equivocamos y eliminamos uno de los que no lo
es. En este caso, la consecuencia es que la información sobre la relación entre objetos de las
entidades que no han quedado directamente relacionadas queda supeditada a la existencia de
algún objeto de la tercera entidad para hacer de puente.

Continuando con el ejemplo anterior, podemos entender mejor la problemática de la trampa de

corte y por qué esta trampa nos habría llevado al modelo conceptual de la figura 4.

Figura 4. La trampa del corte

El modelo de la figura 4 vuelve a ser incorrecto porque incluye un tipo de relación derivado
(conductsWork) y se olvida de uno que no lo es (conductsOrc).

Si observamos las instancias que acompañan al modelo conceptual de la figura 4, no se ven las
consecuencias que tiene caer en esta trampa. A pesar de esto, resulta muy fácil ver que este
modelo no es correcto, si pensamos:

1) cómo podemos indicar quién es el director de una orquesta que todavía no ha interpretado
ninguna obra, o

2) que si eliminamos una obra, perdemos datos del director de la orquesta que la interpretó.
De aquí proviene el nombre de esta trampa: eliminar una obra puede "cortar" la conexión entre
una orquesta y su director.

2.3.Pérdida de afiliación
La tercera trampa que podemos detectar es lo que se conoce como pérdida de afiliación. Se
puede presentar cuando hay un tipo de relación ternaria y tres tipos de relaciones binarias entre
los tipos de entidad que lo constituyen.

Decimos que hemos caído en la trampa de pérdida de afiliación cuando en vez de

representar un tipo de relación ternaria, representamos los tipos de relaciones binarias que se
derivan de ella.

Retomemos el ejemplo de los casos anteriores, pero ahora supongamos que una misma
orquesta puede ser dirigida por varios directores y una misma obra puede ser interpretada por
varias orquestas. Esta situación nos puede llevar a un modelo como el de la figura 5.

Figura 5. La trampa de la pérdida de afiliación

Si suponemos que en el mundo real modelizamos el hecho de que C. Abbado ha dirigido la

orquesta de St. Martin in the Fields interpretando la Sinfonía del Reloj de Haydn, que H. von
Karajan ha dirigido la OCB interpretando la Sinfonía del Reloj y que C. Abbado ha dirigido la OCB
interpretando la 5.ª sinfonía de Mahler, las instancias serán las que se ven en la figura 5. Sin
embargo, a la vista de las instancias, podríamos pensar que Claudio Abbado ha dirigido la OCB
interpretando la Sinfonía del Reloj, lo cual no es cierto. Es decir, el uso de múltiples tipos de
relaciones binarias en lugar de una ternaria puede provocar confusiones. Hemos perdido parte
de la información que teníamos, puesto que sabemos qué directores han dirigido una orquesta,
pero no cuáles de las obras interpretadas por la orquesta han sido dirigidas por cada director.

El modelo conceptual correcto que se ajusta a la situación planteada corresponde a un modelo

con un tipo de relación ternaria, tal y como se describe en la figura 6.

Figura 6. Esquema conceptual correcto

Reflexión

Aplicamos la misma denominación al caso en el que pretendemos representar esta situación con dos

de los tipos de relaciones binarias. Por ejemplo, si solo modelizamos los tipos de

relación conductsWork y plays.

2.4.Aridad de los tipos de relación

En el caso anterior hemos visto que una equivocación en el número de tipos de entidad que
participan en un tipo de relación puede ser una fuente de errores en los esquemas conceptuales.

En este punto, veremos que incorporar un tipo de entidad a un tipo de relación que no le
corresponde también puede ser fuente de errores en el diseño conceptual.

La trampa de aridad de los tipos de relación se puede presentar cuando hay un tipo de
relación de grado mayor que 2 que tiene alguna multiplicidad de valor 1. En este caso, es
posible que la entidad que se encuentra en el lado con multiplicidad igual a 1 en realidad no
deba formar parte del tipo de relación. Decimos que hemos caído en esta trampa cuando hemos
incluido la entidad de manera errónea.

Así pues, cuando nos aparece una multiplicidad igual a 1 en un tipo de relación ternaria (o de
grado más alto), debemos tener mucho cuidado y verificar si el grado del tipo de relación es tal
como lo planteamos o si en realidad se trata de dos o más tipos de relación de grado más bajo.

Pensemos ahora en un contexto en el que se quiere modelizar el hecho de que las obras son
interpretadas por orquestas y que cada obra tiene un compositor, con la restricción de que cada
obra tiene un único compositor. Un posible modelo conceptual para esta descripción se muestra
en la figura 7.

Figura 7. La trampa de la aridad de los tipos de relación

Este modelo es erróneo porque el compositor de una obra no depende de las orquestas que la
interpretan. Es decir, hay una relación directa entre la obra y el compositor y otra entre la
orquesta y la obra. El modelo correcto sería el que se muestra en la figura 8.

Figura 8. El esquema correcto

Esto no significa que no pueda haber algún tipo de relación de grado mayor que 2 y con alguna
multiplicidad igual a 1. Como ejemplo correcto de tipo de relación ternaria en el que uno de los
tipos de entidad participa con multiplicidad igual a 1, consideremos el de la figura 9, donde
asumimos que en un momento dado una orquesta solo tiene un director, a pesar de que
permitimos que un director se haga cargo de más de una orquesta de manera simultánea.

Figura 9. Un tipo de relación ternaria correcto con una multiplicidad igual a 1

2.5.Semántica de los tipos de entidad

La trampa conocida como trampa de semántica del tipo de entidad es la última trampa que
presentamos y que deberemos evitar. Tal como indica su nombre, está relacionada con la
interpretación que hagamos de la semántica de un tipo de entidad.

Decimos que caemos en la trampa de semántica de tipo de entidad cuando se asignan a un

tipo de entidad atributos que no le corresponden debido a una interpretación incorrecta del
significado del tipo de entidad.

Una manera de confirmar o descartar que un atributo se encuentra en un tipo de entidad que le
corresponde es no perder de vista la semántica del tipo de entidad y comprobar si el atributo es
coherente con esta semántica.

Supongamos el modelo conceptual que se presenta en la figura 10, en la cual definimos el

atributo minutes en el tipo de entidad Work.

Figura 10. La trampa de la semántica de los tipos de entidad

Si reflexionamos un poco, no obstante, podremos concluir que los minutos de duración no

corresponden tanto a la obra, sino a cada una de las interpretaciones que se hacen de ella. Por
lo tanto, el atributo minutes tendría que ser un atributo del tipo de relación plays y no del tipo
de entidad Work. Desde el punto de vista semántico, fijémonos en que una obra es un concepto
abstracto que hemos confundido con un concepto más físico, como es la interpretación de la
obra.

El esquema conceptual correcto sería el que se presenta en la figura 11.

Figura 11. El esquema correcto

3.Diseño lógico: transformación del modelo conceptual

en el modelo relacional
La etapa de diseño lógico consiste en obtener un esquema lógico a partir del esquema
conceptual generado en la etapa anterior. El esquema lógico depende del tipo de base de datos
elegido, aunque es independiente de la implementación concreta del sistema de gestión de
bases de datos (SGBD (1) ).

SGBD es la sigla de sistema de gestión de bases de datos.

(1) 

Como hemos mencionado, en este módulo nos centraremos en la conversión del esquema
conceptual expresado en lenguaje UML en un esquema lógico para un tipo de base de datos
relacional. En estos casos, el modelo lógico recibe el nombre de modelo lógico relacional o,
simplemente, modelo relacional.

Utilizaremos la palabra relación para referirnos al elemento básico del modelo relacional. Es

preciso no confundirse con las relaciones a las que nos hemos referido al tratar el diseño
conceptual, que eran instancias de tipos de relación. Hay que decir que el contexto nos tendría
que ayudar a distinguir ambos conceptos de manera unívoca.

Reflexión

Dado que en este módulo trataremos únicamente el caso de modelos lógicos para bases de datos

relacionales, cuando hablemos de modelo lógico interpretaremos que se trata de un modelo relacional.

Actualmente, existen herramientas CASE (2) que son capaces de hacer este proceso de traducción
de manera automática. Ahora bien, dado que hay situaciones en las cuales parte de un modelo
se puede traducir de varias maneras, los usuarios de estas herramientas deben tener los
conocimientos necesarios para realizar la traducción de forma manual porque, como usuarios de
una herramienta CASE, deben ser capaces de modificar el resultado de la traducción automática
si la herramienta no ha elegido la alternativa que se ajusta mejor a las condiciones de cada caso
concreto. También es necesario tener estos conocimientos para decidir correctamente si la
herramienta, al encontrarse ante alternativas que no puede resolver, pide la intervención del
usuario.

Las herramientas CASE

Una herramienta CASE es la implementación de un conjunto de herramientas y de métodos para el

desarrollo de software a partir de especificaciones y definiciones de alto nivel. Uno de los objetivos
principales es liberar a los diseñadores de la base de datos de los procesos rutinarios, con posibilidad

de automatización, no sólo para conseguir una producción más eficiente, sino también para evitar

algunos de los errores que se pueden cometer en estos procesos de desarrollo. En el área de la

modelización conceptual y las bases de datos, algunas de las herramientas más conocidas

actualmente son VisualParadigm, ArgoUML, Poseidon o MagicDraw. Algunas

herramientas CASE pueden efectuar ingeniería inversa, es decir, pueden ayudar a encontrar el

esquema conceptual que corresponde a una base de datos ya diseñada e implementada.

A continuación, aunque se presupone que conocéis el modelo relacional y tenéis conocimientos

básicos de SQL, mencionamos los conceptos más básicos de este modelo y su representación en
lenguaje SQL para aquellos elementos que se deban considerar al transformar el modelo
conceptual en el modelo lógico.

CASE es la sigla de la expresión inglesa computer-aided software engineering, 'ingeniería de

(2) 

software asistida por ordenador'.

3.1.Conceptos previos del modelo relacional

El modelo relacional representa la información sobre la base de un conjunto de relaciones.
Una relación se define como un conjunto de atributos, cada uno con un dominio concreto (el
dominio es el conjunto de valores que se pueden asignar al atributo), y uno de estos es la clave
primaria. Esta descripción se denomina esquema de una relación.

El conjunto de todos los esquemas de relación que describe la base de datos se

denomina esquema de la base de datos.

Dado el esquema de la relación, podemos crear tuplas que conforman la extensión de la

relación; cada tupla está informada con valores del dominio correspondientes a uno de sus
atributos. Por ejemplo, podemos definir una relación Obra cuyo esquema consta de dos
atributos: un atributo nombre, cuyo dominio son las cadenas de caracteres, y un
atributo añoComp, cuyo dominio es numérico. Por ejemplo, la extensión de la
relación Obra puede contener las tuplas <“Concierto para piano núm 3 de Mozart”, 1779> y
<“Parsifal”, 1857>.

El modelo también permite expresar restricciones que limitan los valores o las combinaciones de
valores que pueden tomar los atributos. Las más importantes son:

 Clave candidata. Un atributo o grupo de atributos constituye una clave candidata de la

relación cuando no puede haber dos tuplas con el mismo valor en aquel atributo o
grupo de atributos. Además, no es posible asignar valor nulo a estos atributos.

Ejemplo

En una relación de orquestas en la que cada tupla contiene los datos de una orquesta, el atributo
que corresponde al número de identificación fiscal se puede declarar como clave candidata.

 Clave primaria. De entre las claves candidatas, el diseñador elige una que será la que
utilizaremos habitualmente para identificar de manera unívoca una tupla de la
relación. En lenguaje SQL, la restricción PRIMARY KEY sirve para especificar la clave
primaria de una relación.
 Clave alternativa. Cada una de las claves candidatas que no ha sido elegida clave
primaria recibe el nombre de clave alternativa. En lenguaje SQL, se usa la
cláusula UNIQUE se utiliza para especificar una clave alternativa en una relación.

Ejemplo

Siguiendo con el ejemplo anterior sobre la relación de orquestas, si añadimos un

atributo con el nombre de orquesta, y éste es diferente para cada una, dicho nombre
también puede ser clave candidata y, puesto que la otra es la primaria, esta sería una
clave alternativa.

 Clave foránea. Se puede especificar que un atributo o conjunto de atributos de una

relación R1 forman una clave foránea, que referencia una relación R2 del esquema,
mediante una clave candidata de R2. Esta clave candidata de R2 deberá estar
formada por un conjunto de atributos que se corresponden uno a uno con los de la
clave foránea de R1. La declaración de clave foránea implica que para cada
tupla t de R1 debe existir una tupla de R2 que tenga como valor de los atributos de la
clave candidata referenciada los mismos valores que tiene la tupla t en los atributos
de la clave foránea. De manera alternativa, t puede tener valores nulos en los
atributos de la clave foránea. En lenguaje SQL, la restricción FOREIGN KEY permite
especificar la clave foránea de una relación.

Ejemplo

Si tenemos definidas las relaciones Obra (con un atributo nombreObra y un

atributo comp) y Compositor (con un atributo nombreComp –que es clave primaria– y
un atributo anoNac) y decimos que el atributo comp de Obra es clave foránea que
referencia Compositor por medio de nombreComp, entonces para cada obra que no
tenga el valor nulo en comp debe existir un compositor con este valor en el
atributo nombreComp.

 Valores nulos. Decimos que no admiten valores nulos todos aquellos atributos que
siempre deben estar informados. En lenguaje SQL, un atributo de este tipo se
especifica mediante la restricción NOT NULL aplicada a la columna en cuestión.

 Comprobación de una condición. Es una restricción que verifica que el valor de uno o
más atributos satisface una expresión booleana que se especifica en la declaración de
la restricción. En lenguaje SQL, usamos la restricción CHECK seguida de la expresión
que debe satisfacerse.

Ejemplo

Si la relación de orquestas utilizada anteriormente tiene un atributo numérico

denominado numeroMusicos y queremos que todas las orquestas presentes en la
 relación tengan 30 músicos o más, estableceremos la
restricción Check(numeroMusicos >= 30).

Por claridad y concisión, expresaremos un esquema del modelo relacional mediante una notación
simplificada del lenguaje SQL estándar.

El estándar SQL

El estándar SQL es un lenguaje que permite trabajar con bases de datos relacionales. Es muy utilizado

y casi todas las aplicaciones desarrolladas sobre bases de datos relacionales lo utilizan. Los SGBD

relacionales que se eligen de manera habitual para almacenar la información lo implementan, a veces

con pequeñas diferencias. Contiene sentencias tanto para definir bases de datos como para hacer

actualizaciones y consultas. Ha tenido tres versiones principales que han aparecido, respectivamente,

en los años 1989, 1992 y 1999. El lenguaje continúa evolucionando y se le incorporan nuevos

elementos en sucesivas revisiones, la última publicada en el año 2011.

A continuación, se define brevemente la notación utilizada en estos materiales:

 Denotaremos las relaciones a partir del nombre, seguido de la lista de atributos entre
paréntesis y separados por comas.

 Denotaremos las claves primarias subrayando con una línea continua los atributos que
las forman.

 Denotaremos las claves alternativas subrayando con una línea discontinua los atributos
que las forman.

 Denotaremos las claves foráneas como flechas que tienen su origen en el conjunto de
atributos que las forman y su destino en el conjunto de atributos que forman la clave
referenciada. Esta notación es diferente de la notación utilizada en otros textos sobre
diseño de bases de datos, pero resulta interesante, puesto que muestra de manera
gráfica y más comprensible la transformación del esquema conceptual en el modelo
relacional. En caso de tener un gran número de relaciones, puede ser confusa porque
puede implicar un gran número de flechas que se cruzan entre sí. En estas ocasiones
será mejor usar una notación textual que indique en cada relación qué claves foráneas
contiene y qué relación referencia cada clave foránea.

 Utilizaremos el tipo de letra negrita en los nombres de atributo que queremos

declarar NOT NULL.

Expresión de un modelo con dos relaciones

A continuación mostramos cómo expresar un modelo con dos relaciones, una de obras y una de
compositores, en el que las obras se identifican mediante un código de catalogación y contienen
un nombre popular que se puede repetir en compositores diferentes, pero no en obras de un
mismo compositor. Los compositores se identifican por su nombre y es obligatorio asignar valor
al atributo de fecha de nacimiento (fechaN).
Reflexión

Una clave candidata sirve para identificar cada una de las tuplas de manera unívoca dentro de una

relación.

3.2.Impacto del uso de los valores nulos

Para empezar, presentaremos una breve reflexión sobre los valores nulos que inicialmente se
incorporaron al modelo relacional para poder expresar el hecho de que un dato tiene un valor
desconocido o es inaplicable.

Es importante conocer el impacto que puede tener la existencia de valores nulos, porque al

llevar a cabo la traducción del esquema conceptual al esquema relacional, pueden surgir
atributos que no aparecían en los tipos de entidad del esquema conceptual y que pueden admitir
valores nulos.

Un mal uso de los valores nulos puede causar problemas, básicamente de dos tipos: de
eficiencia y de construcción de consultas que manipulan atributos que contienen valores nulos.

El problema de eficiencia se deriva del acceso a filas que contienen columnas con valores nulos,
las cuales podrían haberse evitado con un diseño alternativo de la base de datos. El ejemplo
siguiente lo ilustra:

Reflexión

Recordemos que los valores nulos constituyen un mecanismo que soluciona el problema de

representación de datos desconocidos o que no se pueden aplicar. En general, no podemos evitar la

existencia de valores nulos.

1. SELECT * FROM Obra WHERE nTenores >= 1

La relación Obra nos dice cuántos tenores, bajos, contraltos, sopranos y barítonos se requieren

para interpretar cada obra (las columnas con un nombre que empieza por n tienen esta
información). Si consideramos que existirán obras sin intervención de voz, estas obras tendrán
valores nulos en las columnas que empiezan por n, puesto que esta información no es aplicable
a obras instrumentales. La consulta del ejemplo, que pretende localizar las obras en las que hay
uno o más tenores, deberá acceder a todas las obras instrumentales, y lógicamente, no
devolverá ninguna de estas tuplas como resultado de la consulta. Podemos diseñar un modelo
relacional que evite el uso de valores nulos y también el acceso innecesario a tuplas. Por
ejemplo, se puede hacer separando las obras en dos relaciones: una de obras con intervención
de voces y otra de obras sin intervención de voces. Con esta idea, obtenemos el modelo
relacional siguiente:
Con este modelo relacional, ahora haremos la consulta de este modo:

1. SELECT * FROM ObraCoral WHERE nTenores >= 1

La diferencia de accesos entre una alternativa y otra dependerá de la proporción de obras

corales respecto al número total de obras. Cuantas menos obras corales (y, por lo tanto, más
tuplas con valores nulos en la primera alternativa), más diferencia habrá.

Así pues, cuando hay columnas para las cuales una proporción grande de las filas puede tener
valor nulo, hay que analizar si las consultas pueden ser penalizadas y, si procede, cambiar el
diseño para eliminar la presencia de valores nulos.

En cuanto a la corrección de las consultas que involucran atributos que pueden tomar valor nulo,
debemos estar atentos para asegurarnos de que la consulta devuelve el resultado correcto, tanto
en el caso de existir tuplas con valor nulo como en el caso contrario. Consideremos el caso
siguiente, en el que tanto la relación de directores como la de compositores tienen una columna
que indica de qué país es el director o compositor. Si queremos obtener la de los directores que
son de un país donde no ha nacido ningún compositor, podríamos pensar en las dos consultas
que se muestran a continuación:

1. SELECT * FROM Director

2. WHERE pais NOT IN (SELECT pais FROM Compositor)
3.  
4. SELECT * FROM Director d
5. WHERE NOT EXISTS
6. (SELECT * FROM Compositor c WHERE d.pais = c.pais)

Las dos consultas devuelven el mismo resultado siempre que la columna pais no tenga valores
nulos. Observad que si un director tiene el valor nulo en la columna pais, la primera consulta no
lo incorpora en el resultado y, en cambio, la segunda sí.

Este es solo un ejemplo para ilustrar el impacto que puede tener la existencia de valores nulos
en las consultas. Será necesario, pues, tenerlo presente en todas las consultas que involucran
los valores nulos en la condición de selección, atributos de agrupación (GROUP BY), funciones de
agregación (MAX, SUM, ...), etc.

Después de los preliminares, pasemos a ver cómo podemos transformar cada uno de los
elementos del modelo conceptual expresados en lenguaje UML en el modelo lógico relacional.

3.3.Tipo de entidad
El primer elemento del modelo conceptual que transformaremos será el concepto de tipo de
entidad.

El tipo de entidad del esquema conceptual se transforma en general en una relación del

modelo relacional. Cada atributo del tipo de entidad se convertirá en una columna de la
relación.

Supongamos el tipo de entidad de la figura 12:

Figura 12. Un tipo de entidad

Vemos que este tipo de entidad tiene los atributos nombre (name), que es clave primaria,
ciudad de residencia (residCity), que es una cadena de caracteres, año de nacimiento (bYear) y
año de defunción (dYear), que son enteros. Este tipo de entidad se representa en el modelo
lógico como la relación que se muestra a continuación:

3.3.1.Atributos multivaluados
La transformación de los atributos multivaluados requiere un análisis más detallado. El modelo
relacional no soporta directamente esta posibilidad, pero hay dos maneras de representar
atributos multivaluados:

1) Por columnas. La representación por columnas consiste en definir en el esquema relacional

tantas columnas como el número máximo de valores que pueda tomar el atributo multivaluado
del esquema conceptual. Esta representación requiere conocer el número máximo de valores,
información que no siempre está definida.

2) Por filas. Esta segunda representación consiste en representar cada valor de un atributo
multivaluado como una fila o tupla de una nueva relación en el esquema relacional.

Ejemplo de atributo multivaluado

Supongamos, por ejemplo, que el tipo de entidad Composer ahora tiene, en vez del

atributo residCity, un atributo residCities multivaluado, tal y como se muestra en la figura 13.

Figura 13. Un tipo de entidad con un atributo multivaluado

Suponiendo que cada compositor puede tener como máximo cinco ciudades de residencia,
podemos representar este atributo multivaluado mediante dos modelos lógicos posibles:

1) Por columnas:

2) Por filas:

Fijémonos en que, como hemos explicado, para hacer la representación por columnas debemos
conocer el número máximo de ciudades en las que puede haber vivido un compositor, y que
para cada compositor dejaremos con valor nulo los atributos de ciudad que no sean necesarios.
Si conocemos este número máximo y la mayoría de los compositores dejan pocos o ningún valor
nulo, esta puede ser una buena representación. Si este no es el caso, probablemente será mejor
la representación por filas. También hay que tener presente que en esta segunda representación
será preciso efectuar operaciones de combinación (join) para recuperar las ciudades de un
compositor, cosa que no habrá que hacer si se utiliza la primera representación.

3.4.Tipo de relación
Para realizar la transformación de los tipos de relaciones al modelo relacional deberemos fijarnos
en la aridad, o grado, y en las multiplicidades, o conectividad. En lo que respecta al grado,
distinguiremos entre grado 2 o más, y en cuanto a la conectividad, distinguiremos si el mínimo
es 0 o más y si el máximo es 1 o más. También estudiaremos los casos particulares de tipos de
relaciones reflexivas y de composiciones.

Todo tipo de relación se puede representar con una nueva relación, que tiene como clave
primaria la concatenación de claves primarias de las relaciones que representan los tipos de
entidad que participan en el tipo de relación. Además, esta nueva relación tendrá una clave
foránea por cada tipo de entidad relacionado.

Figura 14. Un esquema con tipos de relaciones binarias

Ejemplo de tipos de relación

La relación "interpreta" (plays) de la figura 14 se puede transformar en el modelo relacional de

la manera siguiente:

3.4.1.Tipos de relaciones binarias con una multiplicidad 1

Los tipos de relaciones binarias 1..1 o 1..* se pueden representar mediante una clave
foránea en el extremo opuesto al que tiene la multiplicidad máxima igual a 1.

De este modo, el tipo de relación composes de la figura 14 se representa:

Si además tenemos en cuenta que, tal y como especifica el esquema conceptual, toda obra tiene
un compositor, entonces habrá que añadir la restricción NOT NULL sobre la columna composer.
Por lo tanto, el modelo conceptual de la figura 14 se transforma en el siguiente modelo lógico:
Detengámonos y reflexionemos un poco sobre esta representación en el supuesto de que la
multiplicidad mínima del tipo de relación composes fuera igual a 0 en lugar de igual a 1. Si
suponemos que una obra puede no tener asociado ningún compositor –por ejemplo, porque se
desconoce o consta como anónima–, entonces la clave foránea podría tomar valores nulos.

Si queremos evitar la existencia de valores nulos, podemos optar por utilizar la representación
de los tipos de relación mediante una relación.

En nuestro ejemplo, si representamos composes por medio de una relación, obtendremos:

En el caso particular de un tipo de relación binaria 1..1 entre dos tipos de entidad E1 y E2 que se
transforman en las relaciones R1 y R2 del modelo lógico, podremos representar el tipo de
relación como relación, como clave foránea de R1 que referencia R2 o como clave foránea
de R2 que referencia R1.

En caso de que las multiplicidades mínimas sean igual a 0, la representación por clave foránea
tendrá que admitir valores nulos, tal y como hemos explicado. Si optamos por la representación
por relación, hay que tener presente que ahora la relación no tiene una clave compuesta, sino
dos claves candidatas.

Por ejemplo, si queremos representar el hecho de que un compositor puede tener una obra
preferida (favourite) y que una obra puede ser la preferida de un compositor, entonces tenemos
el esquema conceptual de la figura 15.

Figura 15. Un tipo de relación con multiplicidades mínimas igual a 0

Si optamos por una transformación por relación, obtenemos el modelo lógico siguiente:
3.4.2.Tipos de relaciones binarias reflexivas
Otro caso particular que tenemos que estudiar es el de los tipos de relaciones binarias reflexivas.
Se pueden representar igual que en el caso general: mediante claves foráneas o mediante
relaciones.

Como ejemplo de transformación de tipo de relación reflexiva, consideremos el esquema de la

figura 16, que modeliza los convenios que pueden existir entre orquestas.

Figura 16. Un tipo de relación reflexiva

El modelo relacional correspondiente es:

En el supuesto de que el tipo de relación tenga la multiplicidad máxima mayor que 1, en ambos
extremos se tiene que representar por relación, y en este caso hay que analizar si es simétrica.

En caso afirmativo, podemos optar por ahorrar espacio guardando la mitad de la información y
dejando implícita la otra mitad, que se puede deducir por simetría. También hay que garantizar
que para cada par (o1, o2) de la extensión exista el par (o2, o1):

Tipos de relaciones binarias

Un tipo de relación binaria es simétrico si para toda relación del tipo (a ,b) también existe la relación

(b, a). Por ejemplo, el tipo de relación hermanos entre dos entidades de tipo Persona es simétrico.

 bien físicamente, con aserciones que lo garanticen,

 bien virtualmente, guardando solo la mitad de los pares y con aserciones que eviten la
existencia de pares simétricos y una vista definida sobre la tabla. Esta vista debe
reconstruir la extensión entera a partir de la mitad que tenemos almacenada.

Recordad

Una vista se declara dándole un nombre y definiéndola como una consulta sobre una o más tablas.

Una vez se ha declarado, se le pueden hacer consultas como si fuera una tabla.

Ved también

El mecanismo de aserciones se presenta en el subapartado 3.7 de este módulo.

3.4.3.Tipos de relaciones binarias de composición

Las composiciones son, en el fondo, un caso especial de tipo de relación binaria y, además, se
transforman en el modelo relacional del mismo modo. Por este motivo, las tratamos en este
subapartado como otro caso de tipo de relación binaria.

Las composiciones establecen una relación de dependencia de existencia entre dos tipos de
entidad. Normalmente, esta dependencia hace que la identificación del componente sea solo
válida en el conjunto de componentes de un mismo compuesto.

Este tipo de relación de composición se representa como clave foránea en la relación que

representa el tipo de entidad dependiente. Además, la clave primaria de este tipo de entidad
está formada por el identificador del tipo de entidad concatenado con la clave foránea.

Imaginemos que queremos representar el conjunto de obras de cada compositor. Cada obra se
identifica por el atributo opus (un número que ordena cronológicamente las obras de un
compositor), pero diferentes obras de distintos compositores pueden tener un mismo opus. En la
figura 17 se representa el esquema conceptual correspondiente.

Figura 17. Ejemplo de relación binaria de composición

De acuerdo con la regla de transformación de los tipos de relación de composición vista

anteriormente, obtenemos el modelo lógico siguiente:

3.4.4.Tipos de relaciones n-arias
Los tipos de relación de aridad mayor que 2 se representan por relaciones. Lo que es preciso
tener en cuenta son las multiplicidades, puesto que si hay alguna conectividad máxima igual a 1,
aparecen claves alternativas.

Supongamos que queremos registrar los datos históricos referentes a las direcciones de
orquesta con el correspondiente director, tal y como se muestra en la figura 18.

Figura 18. Un tipo de relación ternaria

La figura 18 representa el caso sencillo, sin ninguna multiplicidad limitada a 1. El modelo

relacional correspondiente es el siguiente:
El hecho de que el extremo de un tipo de entidad participante tenga conectividad máxima igual a
1 indica que, una vez fijadas las otras entidades, queda ya determinada la primera. Por lo tanto,
el atributo correspondiente a esta entidad no forma parte de la clave de la relación en la que se
transforma el tipo de relación n-aria. Si hay más de un participante con multiplicidad máxima
igual a 1, podemos formar varias claves según qué atributo sea descartado para formar la clave.

En la figura 19 podemos ver diferentes casos en el mismo contexto, en los que vamos limitando
la multiplicidad máxima de los extremos del tipo de relación conduction.

Observemos el impacto que tiene en la relación conduction y cómo afecta la definición de las

claves candidatas.

Figura 19. Tipos de relaciones ternarias con multiplicidades mínimas igual a 1

Considerando los esquemas de la figura 19, obtenemos:

a) una clave candidata, pero formada solo por dos atributos. El otro se tiene que declarar NOT
NULL:

b) dos claves candidatas:

c) tres claves candidatas:

De manera similar, se representan los tipos de relación de aridad mayor que 3, a pesar de que
son poco frecuentes.

3.5.Tipos de entidades asociativas

Las entidades asociativas del modelo relacional también deben transformarse en el modelo
lógico, y por este motivo debe tenerse en cuenta dónde se ubican los atributos de este tipo de
entidad, puesto que conceptualmente pertenecen al tipo de relación.

En un tipo de entidad asociativa, los atributos se pueden representar de dos maneras,
dependiendo de cómo se ha representado el tipo de relación, si como una relación o como una
clave foránea. En el primer caso, los atributos del tipo de relación se convertirán en columnas de
la relación y, en el segundo caso, en columnas de la clave foránea de la relación.

Veámoslo con un ejemplo. Supongamos el modelo conceptual de la figura 20.

Figura 20. Tipos de entidades asociativas

Dado que plays tiene una multiplicidad *..*, se transforma mediante una relación. En cambio,
puesto que composes tiene una multiplicidad 0..1, se puede transformar mediante una clave
foránea. Teniendo en cuenta esto, la traducción al modelo relacional del esquema conceptual es
la siguiente:

Tenemos que prestar atención una vez más a los valores nulos. El atributo comp puede ser nulo
porque el tipo de relación tiene multiplicidad 0..1 y, por lo tanto, el atributo age también lo
puede ser.

Es preciso tener en cuenta que si las claves foráneas que representan un tipo de relación pueden
ser nulas, todos los atributos que tenga el tipo de relación también lo pueden ser.

Un tipo de entidad asociativa puede participar en tipos de relación. Al igual que el resto de los
tipos de entidades participantes de un tipo de relación, también los tipos de entidad asociativa
tendrán que ser referenciados por alguna clave foránea si participan en tipos de relaciones.

Si el tipo de entidad asociativa se ha representado con una relación, la clave primaria será
compuesta y las claves foráneas que la referencien también lo deberán ser. En cambio, si se ha
representado como clave foránea en una relación R, las claves foráneas que tengan que
referenciar el tipo de entidad asociativa deberán referenciar la relación R.
Para ilustrar esta casuística, fijémonos en el modelo conceptual de la figura 21. Este modelo
relaciona cada obra con su compositor y las orquestas que la han interpretado. Además, se
incluye en qué ciudades residía el compositor durante la composición de la obra y qué directores
dirigían la orquesta en las interpretaciones de la obra.

Figura 21. Ejemplo de tipos de entidades asociativas que participan en otros tipos de relaciones

De acuerdo con la regla de transformación de los tipos de entidad asociativa comentada

anteriormente, obtenemos el modelo relacional siguiente:

Observemos que el tipo de entidad asociativa Plays se ha transformado en la relación Plays. Por

este motivo, en el esquema relacional, Conducts referencia Plays. En cambio, el tipo de entidad
asociativa Composes se ha transformado en la clave foránea comp de la relación Work. Por este
motivo, residence referencia Work, que es donde ha quedado la clave foránea comp, la
transformación de Composes.

3.6.Generalizaciones
La última estructura del modelo conceptual de la cual veremos su tranformación en el modelo
relacional es la generalización/especialización o, simplemente, generalización.

Hay tres maneras de transformar una generalización en el modelo relacional:

1) Una única relación, cuyas columnas son la unión de los atributos de todos los tipos de entidad
(superclase y subclases).

2) Una relación para cada subclase, pero ninguna relación para la superclase. Cada relación
tendrá las columnas que corresponden a los atributos de su subclase y, además, los de la
superclase.

3) Una relación para cada tipo de entidad. Cada relación contendrá las columnas de los atributos
correspondientes a su tipo de entidad. En el caso de las relaciones que representan las
subclases, además, tendremos el identificador con una restricción de clave foránea que
referenciará la relación padre o superclase.
Consideremos el esquema conceptual de la figura 22, que representa diferentes tipos de obra.
Están las obras de música antigua (early) de las cuales queremos información sobre la partitura
original (original sheet), las de música clásica (classical) y las de música moderna (modern).

Figura 22. Un caso de generalización/especialización

A continuación, veamos cómo se transforma según las diferentes opciones:

Para elegir entre las tres representaciones posibles de una generalización, tenemos que
considerar una serie de circunstancias:

1. Una primera cuestión que hay que tener en cuenta es cuáles de las posibles estructuras
pueden almacenar toda la información de todas las posibles instancias.

2. Otro criterio importante es el número de valores nulos generados en cada estructura.

3. También hay que decir que algunas de las opciones pueden implicar redundancia cuando la
generalización es solapada. Por ejemplo, en la segunda opción, una instancia que pertenezca a
dos subclases repetirá dos veces los valores de los atributos provenientes de la superclase.

d) Finalmente, también en función de la consulta que queramos realizar, debemos considerar

cuestiones de rendimiento. En el ejemplo anterior, cuando se intenta combinar las relaciones
más específicas con la relación genérica o padre, la opción 3 genera operaciones de combinación
(join) entre las relaciones para obtener todos los resultados, mientras que la opción 2 genera
operaciones de unión (union) entre las diferentes relaciones para acceder a todos los resultados.

Comentemos algunos ejemplos para ilustrar estos criterios:

a) Si elegimos la opción 2 y se trata de una generalización parcial, no dispondremos de lugar

donde almacenar las instancias que no pertenecen a ninguna subclase.
b) Si elegimos la opción 1, cada tupla tendrá valores nulos en las columnas que no
corresponden a la subclase de la instancia que se considere. Si la generalización es total y
solapada, toda instancia será de una o más subclases y la proporción de nulos quizás será
admisible. En el otro extremo, una generalización parcial y disjunta dará lugar a una gran
proporción de nulos.

c) Si elegimos la opción 3, en el caso de una generalización solapada, los atributos comunes de
la superclase se repetirán para cada instancia de la relación tantas veces como el número de
subclases a las que pertenece la instancia.

Hay que elegir la alternativa que permita almacenar todas las instancias y que no genere valores
nulos (o que genere un número mínimo de estos) ni redundancia, excepto cuando haya razones
de rendimiento que exijan una opción diferente.

A continuación, podemos ver otro ejemplo en el que la superclase forma parte de un tipo de
relación. La figura 23 muestra un modelo en el cual se define que cada compositor tiene una
obra representativa y que las obras pueden ser de diferentes tipos.

Figura 23. Un caso de generalización/especialización en el que la superclase participa en un tipo de relación

La regla de transformación de generalizaciones se debe considerar como una guía general, pero
además hay que tener en cuenta el resto del esquema conceptual en el que participa la
generalización. Por ejemplo, si hay referencias de otras relaciones (surgidas de la traducción de
otra parte del esquema), algunas de las opciones dejan de ser válidas: en el esquema de la
figura 23, si decidimos convertir el tipo de relación representative en una clave foránea que
referencia Work, la opción 2 no es válida porque necesitamos una relación para la clase
genérica.

Recordad

Toda generalización/especialización presenta una superclase (o tipo de entidad genérica) y un

conjunto de subclases (o tipos de entidades específicas). Además, es posible que estas subclases sean

disjuntas o solapadas, por un lado, y que la especialización sea total o parcial, por el otro.

3.7.Restricciones
Finalmente, nos falta analizar la manera en que las restricciones que forman parte del modelo
conceptual se transforman en el modelo lógico relacional.

Es importante que las restricciones del modelo conceptual se conserven en el modelo lógico.

Algunas de estas restricciones son estructurales del diagrama de clases, y otras son restricciones
textuales que el diseñador ha indicado en el modelo conceptual.

En este subapartado, nos centraremos en las restricciones estructurales del diagrama de clases.
Algunas restricciones quedan incorporadas en el modelo relacional si se han aplicado de manera
correcta las transformaciones que hemos visto hasta ahora. Hay, no obstante, otras restricciones
que habrá que añadir al modelo lógico relacional de manera más explícita.

Las restricciones estructurales son de tres tipos:

1) Restricciones de identidad. Corresponden a identificadores de los tipos de entidad. Ya

hemos comentado que se incorporan como claves primarias o alternativas en el diseño lógico.

2) Multiplicidad de los tipos de relación. Hay que garantizar la conectividad entre las
instancias de relaciones, respetando los máximos y mínimos de estas multiplicidades. Ya hemos
tenido en cuenta algunas de estas restricciones, pero quedan otras que aún no hemos tratado.

3) Tipología de las generalizaciones. Se tiene que procurar que queden reflejadas las
restricciones de pertenencia a superclases y a las subclases teniendo en cuenta su tipología
(declaración de disjunto/solapado y total/parcial).

Los mecanismos de los que disponemos para mantener y controlar las restricciones son los
siguientes:

 Restricciones admitidas en la creación de tablas: PRIMARY KEY, FOREIGN

KEY, UNIQUE, NOT NULL, CHECK. Son mecanismos automáticos y de baja
complejidad que resultan fáciles de definir y de mantener.

 Aserciones. El estándar SQL incorpora este mecanismo de definición de restricciones

basado en condiciones que se especifican usando una construcción que puede
involucrar instrucciones SELECT. Por este motivo, son muy potentes y permiten
expresar condiciones que no pueden incluir las restricciones del subapartado anterior,
las cuales sólo pueden acceder a información de una tupla de una relación. Se trata
de un mecanismo con las características positivas de los anteriores (son automáticas,
de baja complejidad, fáciles de definir y de mantener) pero que desgraciadamente
ningún SGBD implementa hoy día.

 Procedimientos almacenados. Son procedimientos que pueden contener sentencias SQL

(consulta, actualización y definición) combinadas con estructuras de control clásicas
de programación (iteraciones, alternativas, etc.). Se pueden definir unos
procedimientos de acceso a las tablas que efectuarán los controles necesarios para
asegurar el mantenimiento de restricciones.

 Disparadores (3) . Son similares a procedimientos almacenados que se asocian a

operaciones sobre tablas y que se ejecutan de manera automática a partir de
determinadas acciones sobre los datos (inserción, modificación o eliminación de
datos). Se trata de un mecanismo automático, pero requiere un esfuerzo considerable
definirlos y mantenerlos. Podemos, pues, diseñar disparadores que se ejecuten
cuando se realicen actualizaciones en los datos de tablas en las cuales haya que
comprobar que no se violan las restricciones.

 Precondiciones. Se puede considerar la posibilidad de delegar el control de algunas

restricciones a las aplicaciones y liberar la base de datos, la cual actuará bajo el
supuesto de que las operaciones que se le piden satisfacen las condiciones de
corrección necesarias.
  Control externo. Incluso se puede llevar la idea anterior más allá y confiar en que
determinadas restricciones se controlen de manera externa a la aplicación,
habitualmente por parte de algún mecanismo o proceso automático que valida los
datos.

En este módulo ya hemos tratado las restricciones de identidad. A continuación, veremos cómo
podemos tratar los otros dos tipos de restricciones estructurales y los problemas con los que nos
podemos encontrar.

En inglés, triggers.
(3) 

3.7.1.Multiplicidades
En lo que respecta a las multiplicidades, será necesario analizar los diferentes tipos de relación.
Empecemos por los tipos de relaciones binarias que se representan mediante alguna clave
foránea, es decir, tipos de relaciones entre dos relaciones A y B de manera que una de estas
tiene una o más columnas que referencian las tuplas de la otra relación.

En la figura 24 se muestran las posibles multiplicidades de un tipo de relación binaria.

Figura 24. Conjunto de posibles multiplicidades de un tipo de relación binaria que se puede transformar en

clave foránea

Según la multiplicidad de la izquierda (lado de la entidad A), la clave foránea admitirá valores

nulos o no, como ya hemos discutido. La multiplicidad de la derecha (lado de la entidad B), sin
embargo, nos puede obligar a añadir alguna restricción que antes no hayamos tenido en cuenta.
Según el valor de esta multiplicidad, hay que considerar:

 Si es *, no hay que añadir nada más.

 Si es 0..1, tenemos que declarar que fk es UNIQUE, asegurando así que no puede haber
más de un elemento de B asociado con el mismo elemento de A.

 Si es 1, tenemos que asegurar que toda tupla de A es referenciada por una tupla de B.
Podemos expresar de varias maneras que toda fila de A es referenciada por una fila
de B. Por ejemplo, como una aserción o una clave foránea de A hacia B. Esta clave
foránea sería el atributo pk de A que haría referencia a fk de B, que habremos
definido como UNIQUE. Además, será necesario controlar que si la tupla b de B hace
referencia a la tupla a de A, la tupla a hace referencia a la tupla b. Esta comprobación
se podría hacer, por ejemplo, empleando un disparador.

 Si es 1..*, tenemos que asegurar mediante una aserción que toda fila de A es
referenciada por una o más filas de B.
A continuación, analizamos otro tipo de relación binaria.

Las multiplicidades posibles de este tipo de relación son las que se muestran en la figura 25.

Figura 25. Posibles multiplicidades de un tipo de relación binaria que se puede transformar en relación

En función del número máximo de las multiplicidades de los tipos de entidades A y B en el tipo
de relación C (si es igual a 1 o mayor que 1), fk1 y fk2 serán claves por sí mismas o no:

 si ambos máximos son iguales a 1, tendremos dos claves alternativas.

 si un máximo es igual a 1 pero el otro es mayor que 1, habrá una sola clave formada por
una sola columna.

 si ambos máximos son mayores que 1, habrá una clave formada por las dos columnas.

Ved también

Podéis ver las multiplicidades y los diferentes tipos de relación en el subapartado 3.4 de este módulo

didáctico.

Pensemos ahora en las multiplicidades mínimas, que se tratarán cada una de manera
independiente: si el mínimo es igual a 0, no hay que añadir más controles. Si la multiplicidad a
la izquierda de la figura 25 es igual a 1, tenemos que asegurar que todas las tuplas de la
relación B aparezcan una y solo una vez en la relación C. Y si la multiplicidad es 1..* tendremos
que asegurar que aparezcan una o más veces. Será preciso establecer los controles simétricos si
el mínimo de la derecha de la figura 25 es igual a 1.

Reflexión

Encontramos situaciones análogas a las que hemos tratado en el caso de representación por clave

foránea y que también solucionamos de manera análoga.

Para acabar el estudio de restricciones provenientes de tipos de relación, veremos ahora los
tipos de relación de aridad superior a 2. Como ya hemos explicitado, en función del máximo de
las multiplicidades (si es igual a 1 o mayor que 1), la clave de la relación del tipo de relación
estará formada por todas las claves foráneas o solo por una parte de las mismas. También
puede pasar, como ya hemos visto, que aparezcan claves alternativas.

En cuanto a las multiplicidades mínimas, en el caso de aridad mayor que 2 es habitual que

sean 0. Si se da el caso de multiplicidad mayor que 0, será necesaria una aserción que
compruebe que se dan efectivamente las relaciones indicadas por la multiplicidad.
Por ejemplo, en la transformación del esquema conceptual de la figura 19a, la aserción tendrá
que comprobar que para todo par de orquesta y fecha hay un director relacionado.

Ved también

Podéis ver los tipos de relaciones n-arias en el subapartado 3.4.4 de este módulo didáctico.

3.7.2.Generalizaciones
En este subapartado nos ocuparemos de las restricciones correspondientes a las características
de las generalizaciones. Según cuál sea la opción elegida de las tres presentadas, la que se
utilice para transformar la generalización del modelo conceptual al modelo lógico, deberemos
incorporar un tipo de restricciones u otro:

a) Una única relación para todos los tipos de entidad de la jerarquía. Es útil en casos muy
particulares de generalizaciones solapadas y parciales, como ya se ha comentado. En función de
cómo se indique a qué clases o subclases puede pertenecer una instancia en el modelo
conceptual, será necesario diseñar alguna aserción para comprobar que cada instancia pertenece
a alguna subclase.

b) Una relación para cada tipo de entidad específica. Se ajusta bien a los casos en que la
jerarquía es disjunta y total. En este caso, será necesario controlar que una misma instancia no
pertenezca a más de una subclase. Esta comprobación se puede realizar mediante el uso de
disparadores incorporados en la inserción y la modificación.

c) Una relación para la entidad genérica. Es la opción más flexible y permite representar
cualquier combinación disjunta/solapada y total/parcial. En este caso será necesario añadir los
controles de disjunta (como acabamos de explicar) y/o total (que podemos implementar con una
aserción) según proceda.

Ved también

Podéis ver las generalizaciones en el subapartado 3.6 de este módulo didáctico.

3.7.3.Abrazos mortales
Finalizaremos este subapartado de restricciones comentando un problema que puede aparecer
en el proceso de incorporación de las restricciones en el modelo relacional, o también durante el
paso del esquema conceptual al modelo relacional en determinadas situaciones. Nos referimos a
los abrazos mortales, referencias cíclicas entre relaciones del modelo.

Cuando en un esquema relacional se genera un ciclo de claves foráneas, decimos que se ha

producido un abrazo mortal de definición. Esto significa que no podemos definir directamente
las tablas correspondientes porque cada una necesita que se haya definido previamente alguna
otra. La solución de este problema pasa por definir primero una tabla sin clave foránea mediante
una sentencia CREATE TABLE. A continuación, se definen otras tablas que requerían la primera,
y finalmente se incorpora la clave foránea en la primera tabla con una sentencia ALTER TABLE.

Supongamos que queremos modelizar una situación en la cual una obra sea representativa de
un compositor y que un compositor tenga o no una obra de referencia. El modelo conceptual
para esta situación sería el que se describe en la figura 26.

Figura 26. Un tipo de relación binaria que se puede transformar en dos claves foráneas cíclicas

Este modelo conceptual se puede transformar en el modelo relacional siguiente:

La clave foránea de Work en Composer representa el tipo de relación representative. Le
añadimos la clave foránea de Composer a Work junto con la restricción UNIQUE para garantizar
la multiplicidad igual a 1. En un primer momento, nos encontramos con que no podemos definir
estas relaciones porque ambas necesitan que la otra ya esté definida previamente. Para
solucionarlo, crearemos primero una de las tablas sin clave foránea, después la otra tabla, y
finalmente incorporaremos la clave foránea a la primera tabla.

Una vez superada la dificultad de la creación de tablas con referencias cíclicas, nos podemos
encontrar con una situación similar a la hora de insertar filas en las tablas vacías: no podemos
insertar una obra si no está antes el compositor, pero tampoco podemos insertar el compositor
hasta que no tengamos su obra representativa.

Cuando en un esquema relacional no podemos insertar las tuplas que darían lugar a un
contenido que no viola ninguna restricción porque hay un ciclo de claves foráneas que impide
insertar las tuplas de una en una sin violar la integridad referencial, decimos que se ha
producido un abrazo mortal de carga.

Una primera solución del abrazo mortal de carga consiste en eliminar las restricciones que la
provocan o delegarlas a algún otro nivel. Podemos, sin embargo, mantener el control de estas
restricciones en el ámbito del SGBD difiriendo su comprobación.

Los SGBD, por medio del mecanismo de transacciones, nos ofrecen la posibilidad de diferir la
comprobación de restricciones en lugar de hacer la comprobación inmediatamente después de
cada operación elemental. De este modo, después del primer INSERT se estará violando la
restricción, pero el segundo INSERT nos llevará a un nuevo estado en el cual se satisface la
restricción. En medio de las dos sentencias de inserción de filas, la SGBD impedirá los accesos a
estas tablas que son, provisionalmente, inconsistentes. Una vez completadas las dos sentencias
de inserción, el SGBD comprobará las restricciones y volverá a permitir el acceso a las tablas.

3.8.Reconsideraciones
Una vez finalizada la transformación de un esquema conceptual en un modelo relacional, quedan
detalles que debemos refinar en el esquema relacional obtenido.

En este subapartado, presentamos dos situaciones que pueden ayudar a ajustar el esquema
lógico.

La primera de estas situaciones se presenta cuando existe la posibilidad de eliminar alguna

relación que puede parecer innecesaria. Cuando nos encontramos con relaciones que consisten
exclusivamente en la clave primaria y que además son referenciadas desde otra relación, nos
podemos preguntar si es mejor eliminar estas relaciones y quedarnos sólo con la relación que las
referencia, de manera que se evite repetir los mismos valores tanto en la clave foránea
referenciadora como en la clave primaria referenciada. La respuesta suele ser negativa porque la
existencia de estas relaciones nos permite comprobar la integridad referencial.

Consideremos el caso de la figura 27, que representa obras, orquestas y qué obras ha
interpretado cada orquesta.

Figura 27. Un tipo de relación binaria

A partir del modelo conceptual de la figura 27, obtenemos el esquema lógico siguiente:
Si Work y Orchestra no tienen más atributos que el identificador, nos podemos preguntar si es
mejor eliminar estas relaciones y quedarnos sólo con la relación Plays, en la que ya aparecen
estos identificadores. Debemos valorar, no obstante, que Orchestra y Work nos permiten estar
seguros de que siempre que aparece una obra o una orquesta se trata de una obra u orquesta
que existe y que siempre lo hace con el mismo nombre o denominación.

Si nos encontramos en una situación (que es poco frecuente) en la cual la integridad referencial
nos viene garantizada por algún otro sistema (por ejemplo, no es necesaria una tabla de fechas
porque la SGBD ya no permite la existencia de valores de fecha incorrectos), podremos eliminar
la tabla.

Otra opción de simplificación consiste en fusionar dos tipos de entidad conectados por un tipo de
relación 1..1 en un único tipo de entidad. Tomaremos la decisión sobre si es mejor fusionar o no
en función del espacio ocupado y del tiempo requerido para las operaciones más frecuentes (si
es más frecuente consultar atributos de un solo tipo de entidad o, por el contrario, consultar
información que incluye atributos de los dos tipos de entidades). La fusión consiste en
representar el esquema conceptual, no con dos relaciones vinculadas con claves foráneas, sino
con una única relación que incluya los atributos de los dos tipos de entidad.

Si nos decidimos a llevar a cabo la fusión, la relación resultante tendrá dos claves alternativas y
deberemos elegir cuál debe ser la primaria. El criterio de elección más adecuado suele ser el de
mínima frecuencia de cambio.

Fijémonos en el caso de la figura 28, en el que se representan orquestas, directores y el director

que dirige cada orquesta.

Figura 28. Dos tipos de entidad susceptibles de ser transformados en una única relación

Si fusionamos ambos tipos de entidad, la relación resultante tendrá dos claves alternativas (la
de Conductor y la de Orchestra). En este caso, seguramente es mejor que la clave primaria sea
el identificador de orquesta, que prácticamente no cambia nunca; en cambio, el director de una
orquesta puede cambiar con mayor frecuencia.

4.Normalización
Durante el proceso de diseño se han tomado diferentes decisiones que determinan un diseño
concreto, entre las distintas alternativas posibles, para resolver una misma necesidad. Por
ejemplo, un mismo concepto del mundo real puede dar lugar a esquemas conceptuales
ligeramente diferentes, o la transformación del modelo conceptual en el modelo lógico se puede
llevar a cabo con diferentes alternativas o matices.

En los apartados anteriores, hemos visto algunos criterios para elegir o descartar determinadas
opciones (por ejemplo, favorecer determinadas operaciones por encima de otras o evitar la
existencia de valores nulos). En este apartado veremos las condiciones de normalización, que
son las condiciones que garantizan que la base de datos está diseñada de manera que no se
mezclen conceptos diferentes en una misma relación. Esta característica es positiva porque
facilita la comprensión del diseño y evita redundancias innecesarias.

En primer lugar, veremos las anomalías que se pueden producir cuando una base de datos no
está normalizada. Estas anomalías implican ineficiencia y complejidad en el mantenimiento de la
coherencia de los datos. En segundo lugar, después de un repaso previo de conceptos del
modelo relacional y del álgebra de conjuntos, presentaremos la teoría de normalización y
veremos cómo la podemos aplicar a los esquemas lógicos. Veremos que esta aplicación elimina
las anomalías de la base de datos.

4.1.Anomalías
Un diseño lógico no normalizado tiene como consecuencias negativas la falta de separación de
conceptos y la existencia de redundancias que provocan la aparición de las
denominadas anomalías de actualización. Decimos que hay anomalías cuando es preciso
actualizar muchas tuplas para reflejar un cambio elemental que con un diseño normalizado
implicaría un volumen de tuplas mucho menor.

Estas anomalías pueden aparecer en la inserción, la supresión o la modificación de tuplas.

Anomalías de inserción

Cuando resulta imposible insertar informaciones elementales de manera independiente en una

base de datos, decimos que se produce una anomalía de inserción.

Ejemplo

Imaginemos que queremos almacenar información de las obras que tenemos disponibles en
nuestra discoteca y de los compositores que son sus autores. Con este objetivo, creamos la
relación siguiente:

Se registra el año de composición de las obras (en el atributo yearComp), el siglo en que

nacieron los compositores (bCentury) y el porcentaje de digitalización que han alcanzado sus
obras (digitDegree). En un momento determinado, la relación podría tener la extensión que
representa la figura 29.

Figura 29. Extensión de una relación con redundancias y anomalías

Si queremos añadir un nuevo compositor denominado Montsalvatge cuyo nombre y siglo de

nacimiento conocemos pero de quien aún no disponemos de información de ninguna de sus
obras, no podemos añadirlo. Tendríamos que insertar la tupla:

Sin embargo, no podemos porque el atributo work es la clave primaria y ésta no puede tener
valor nulo. Nos encontramos, pues, con que no podemos insertar información de un compositor
independientemente de sus obras.

Anomalías de supresión

Cuando se produce una pérdida de información involuntaria de un hecho elemental debido a la

supresión de otro hecho elemental, decimos que se produce una anomalía de supresión.

Ejemplo
Supongamos ahora que queremos suprimir el Tercer concierto para piano de Mozart. Después de
la supresión, nuestra relación tendrá la extensión que muestra la figura 30.

Figura 30. Extensión de la relación después de una supresión

Observad que, de manera involuntaria, hemos perdido la información que teníamos del
compositor Mozart.

Anomalías de modificación

Cuando se presenta la necesidad de modificar varias (potencialmente muchas) tuplas para

reflejar el cambio de un solo hecho elemental, se dice que se produce una anomalía de
modificación.

Ejemplo

Si ahora queremos anotar que el grado de digitalización de las obras de Mahler ha pasado a ser
del 73%, tendremos que actualizar la relación tal y como se muestra en la figura 31.

Figura 31. Extensión de la relación después de una modificación

Observad que tendremos que modificar tantas tuplas como obras de Mahler tengamos en la
relación.

El origen de las anomalías de inserción, eliminación y actualización que acabamos de ver es la

mezcla de dos conceptos en una misma relación, lo cual implica además redundancia. La
solución no es otra que la separación de conceptos, lo que se consigue dividiendo la relación
original en dos nuevas relaciones.

La solución del caso utilizado como ejemplo vendría dada por la separación de los datos de obras
y de compositores, lo que daría lugar al modelo normalizado siguiente:

La extensión de estas nuevas relaciones es la que se presenta en la figura 32.

Figura 32. Extensión de dos relaciones normalizadas

Ahora podemos efectuar las operaciones de inserción, supresión y modificación que hemos
utilizado en el ejemplo sin que se produzca ninguna anomalía.

La teoría de la normalización nos permitirá detectar si un diseño puede provocar anomalías

como las que hemos descrito y, además, nos permitirá obtener un nuevo diseño con estas
problemáticas resueltas.

4.2.Conceptos previos
La teoría de la normalización se basa en el concepto de dependencia funcional, el cual a su vez
se define en términos del álgebra relacional y de conceptos de la teoría de conjuntos. En este
subapartado, se presentan estos elementos que permitirán abordar la teoría de la normalización.

Para empezar, repasaremos algunos conceptos de álgebra de conjuntos. Estos conceptos nos
servirán después para razonar sobre los valores que toman los atributos de las relaciones.
Concretamente, queremos definir el producto cartesiano, la correspondencia y la función:

 Dados dos conjuntos O e I, el producto cartesiano  O × I es el conjunto de todos los

pares ordenados (o, i) tales que o ∈ O e i ∈ I. Lo podemos representar gráficamente
como se ve en la figura 33. El conjunto O recibe el nombre de conjunto origen y el
conjunto I se denomina conjunto imagen.

Figura 33. El producto cartesiano

 Un subconjunto cualquiera del producto cartesiano es una correspondencia. La figura

34 muestra una correspondencia entre los mismos conjuntos del ejemplo anterior.

Figura 34. Una correspondencia

  Algunas correspondencias son, además, funciones: aquellas en las que cada elemento
del conjunto origen está relacionado con un elemento (y solo uno) del conjunto
imagen. La figura 35 es un ejemplo de función entre los conjuntos O e I de las figuras
anteriores.

Figura 35. Una función

 Decimos que una función es inyectiva cuando cada elemento del conjunto imagen está
relacionado, como mucho, con un elemento del conjunto origen. En la figura 36,
podemos ver un ejemplo de función inyectiva.

Figura 36. Una función inyectiva

Como ya hemos visto, las relaciones se ajustan a un esquema que define sus atributos y tienen
una extensión formada por tuplas que dan valores a los atributos.
Cada tupla de la extensión de una relación tiene la información de una entidad del mundo real.
Podemos usar el concepto de función para representar los valores que toma un atributo en cada
tupla y, por lo tanto, para cada entidad.

Por ejemplo, la relación Composer de la figura 32 tiene tres

atributos: cName, Century y digitDegree. El dominio del primero son las cadenas de caracteres y
el de los otros dos, los números.

Los valores que toma un atributo en la extensión de una relación se pueden considerar una
función que tiene como origen el conjunto de las entidades del mundo real y como imagen, el
dominio del atributo.

La figura 37 es la visualización en términos de conjuntos y funciones de los atributos de la

relación de la figura 32.

Figura 37. La visión como funciones de los atributos de una relación

Podemos observar que la función correspondiente a cName es inyectiva; fijémonos en que esta
es una propiedad que cumplirán por definición todas las funciones que correspondan a atributos
identificadores (observad que ya habíamos indicado que este atributo es una clave de la
relación).

Las dependencias funcionales se establecen entre conjuntos de atributos de una relación, y

las podemos considerar un tipo más de restricciones que deben satisfacer la extensión de la
relación.

Dependencias funcionales

Dada una relación R(A1, A2, ..., An), podemos declarar X → Y como dependencia funcional

si X, Y ⊂ {A1, A2, ..., An}. Para satisfacer esta restricción, la extensión de la relación debe ser tal
que X determine de manera única el valor de Y; es decir, que si dos tuplas tienen los mismos
valores en los atributos de X, también tengan los mismos valores en los atributos de Y. En este
caso, decimos que Y depende funcionalmente de X o, de modo alternativo, que X determina
funcionalmente Y (y, por esto, X se denomina determinante de la dependencia). Es decir, si
generalizamos el concepto de función, podemos decir que hay una función con origen X e
imagen Y.

Observemos que un caso particular de dependencias funcionales son las claves de una relación:
en este caso, los atributos que forman la clave determinan todos los demás. Esto es
consecuencia de la no repetición de valores de la clave: puesto que sólo puede haber una tupla
con un valor concreto de la clave, todas las tuplas con aquel valor (es decir, como máximo una)
tienen el mismo valor para todos los demás atributos de la relación.

Ejemplo de dependencia funcional

Para acabar de presentar este concepto, lo ilustraremos con un ejemplo. Analicemos la relación
siguiente para identificar dependencias funcionales:

Encontramos las dependencias funcionales siguientes:

 {work} → {composer, yearComp, bCentury, digitDegree}. Esta dependencia

corresponde a la clave primaria.

 {composer} → {bCentury, digitDegree}. Sabemos que el compositor determina el siglo

en que nació y también el grado de digitalización conseguido en sus obras. Podemos
comprobar que la extensión utilizada de ejemplo es correcta respecto a esta
dependencia: Mahler, el compositor que se repite, aparece dos veces con los mismos
valores para los atributos bCentury y digitDegree.

En cambio, {composer} → {yearComp} es falso, porque el compositor no determina el año de

composición de las obras; un mismo compositor puede haber compuesto varias obras en años
diferentes. Por este motivo, la extensión de la relación puede contener una tupla con Mahler y
1923 y otra con Mahler y 1918.

Para denotar las dependencias que hay en una relación, utilizaremos una notación basada en
flechas, tal y como muestra el ejemplo siguiente:

Para finalizar, notemos que puede haber dependencias en las que podemos prescindir de
algunos de los atributos del determinante.

Decimos que una dependencia funcional X → Y es completa cuando no hay ninguna otra
dependencia X' → Y, siendo X' un subconjunto propio de X.

Ved también

Podéis ver los conceptos previos del modelo relacional en el subapartado 3.1 de este módulo

didáctico.

Por ejemplo, podemos afirmar que {work, composer} → {yearComp}, pero en esta dependencia
podemos prescindir de composer porque {work} → {yearComp} también es verdad. La primera
de las dependencias anteriores no es completa, porque está la segunda y se verifica que {work}
es un subconjunto propio de {work, composer}.

Reflexión
Observad que si en una dependencia funcional X → Y el conjunto X solo tiene un atributo, la

dependencia funcional seguro que es completa.

4.3.Teoría de la normalización
El objetivo de la teoría de la normalización es fijar unas condiciones que nos garanticen la
separación de conceptos y la ausencia de redundancia para evitar las anomalías de actualización.
Estas condiciones se basan en gran medida en el concepto de dependencia funcional plena que
acabamos de presentar en el subapartado anterior.

Las anomalías presentes en una relación tienen el origen en dependencias existentes entre los
atributos de la relación. La teoría de la normalización define una serie de niveles
denominados formas normales que eliminan progresivamente determinadas dependencias que
son causantes de diferentes anomalías. Estas formas normales son inclusivas; es decir, si una
relación cumple las condiciones de un determinado nivel, también cumple las condiciones de
todos los niveles anteriores. Cuanto más alto es el grado de normalización, más redundancias se
eliminan y, por lo tanto, menos anomalías se pueden producir.

La teoría de la normalización establece las bases para modificar una relación que no está en una
determinada forma normal con el objetivo de que lo esté. Este proceso de modificación se
denomina normalización. Tal como iremos viendo, una misma relación no normalizada se puede
modificar de varias maneras hasta convertirse en una relación normalizada; es decir, el proceso
de normalización puede tener diversos resultados.

Estudiaremos seis formas normales:

 la primera (1FN) se define en términos de la atomicidad de los atributos,

 las tres siguientes (2FN, 3FN y BCNF), en términos de dependencias funcionales,

 la penúltima (4FN) se basa en dependencias multivaluadas, y

 la última, (5FN), en la dependencia de proyección-combinación.

Estos dos últimos tipos de dependencias se presentarán en el momento de definir las formas
normales correspondientes.

En un primer bloque trataremos las cuatro primeras formas normales, y después presentaremos
un par de algoritmos capaces de normalizar hasta este nivel. Finalmente, veremos las dos
últimas formas normales.

4.3.1.Primera forma normal

Una relación está en primera forma normal (1FN) si, y solo si, ningún atributo de la relación
es en sí mismo una relación, ni descomponible ni con multiplicidad de valores. Los atributos,
pues, deben ser atómicos.

Para ilustrar este concepto, fijémonos en la figura 38, en la que tenemos una relación que
permite incluir información de los compositores.

Figura 38. Una relación con atributos no atómicos

Esta relación no está en 1FN porque hay dos atributos, works y yearComp, que no son atómicos.
Para normalizar una relación en la primera forma normal, debemos aplanar los atributos que no
son atómicos.

A partir de la relación de la figura 38, obtenemos la relación de la figura 39.

Figura 39. La relación después de aplanar los atributos

Debe observarse que la clave primaria de la relación normalizada cambia: tenemos que buscar
la nueva clave a partir de la superclave formada por la composición de la que teníamos antes
(en nuestro caso, composer) con la clave de la subrelación que formaban los atributos no
atómicos (en nuestro caso, work y yearComp que tiene como clave work).

En nuestro ejemplo, la superclave es {composer, work} pero dado que {work} → {composer},

la clave primaria está formada exclusivamente por el atributo work.

Hay que tener presente que el modelo relacional y los SGBD relacionales ya garantizan esta
primera forma normal en cualquier relación que podamos definir.

Aplanar un atributo no atómico

Aplanar un atributo no atómico de una relación consiste en sustituir cada tupla por tantas como

repeticiones haya del atributo no atómico.

4.3.2.Segunda forma normal

Una relación está en segunda forma normal (2FN) si, y solo si, está en primera forma normal
y todo atributo que no forma parte de una clave candidata depende completamente de todas las
claves candidatas de la relación.

Observad que toda relación en primera forma normal que tenga las claves candidatas formadas
por un solo atributo está de manera automática en segunda forma normal: por definición de
clave, todo atributo depende de las claves candidatas y, en el caso de ser de un solo atributo,
seguro que la dependencia es completa.

Como ejemplo de esta problemática, consideremos la relación siguiente, que almacena las obras
que contiene en cada una de las grabaciones (discos, cintas, archivos Mp3, etc.) que tenemos.
Una misma obra (work) puede estar repetida en varias grabaciones (recordings) y una grabación
puede contener varias obras. También se desea guardar el compositor de cada obra (composer)
y los minutos que dura cada obra (durWorkRecord) en una grabación determinada.
Esta relación, que tiene como clave primaria {work, record}, no está en segunda forma normal
porque composer no depende completamente de la clave, puesto que existe la dependencia
{work} → {composer}. El ejemplo nos permite ver con claridad cuál es el objetivo de la segunda
forma normal: impedir que se mezclen dos hechos elementales que comparten parte de la clave
(las grabaciones de las obras que tenemos, por un lado, y los compositores de las obras, por
otro) en una misma relación. De este modo, evitaremos redundancias como la de tener replicado
el compositor de una obra tantas veces como el número de grabaciones que contienen la obra.
Para normalizar una relación a 2FN debemos separar los hechos mezclados que violan la
condición de 2FN en dos relaciones. En el ejemplo que estamos viendo, hay que transformar la
relación Recordings en dos nuevas relaciones:

Como se puede observar, las dos relaciones resultantes se deben relacionar mediante una clave
foránea por medio de la parte de la clave compartida por ambos hechos. Es preciso no confundir
las flechas que representan dependencias con la que representa esta clave foránea.

4.3.3.Tercera forma normal

Una relación está en tercera forma normal (3FN) si, y solo si, está en segunda forma normal
y ningún atributo que no forma parte de una clave candidata depende de un conjunto de
atributos que contiene alguno que no forma parte de una clave candidata.

Podemos tomar la relación Works del ejemplo anterior y añadirle el siglo de nacimiento de los

compositores (bCentury); obtenemos:

Esta relación, cuya clave es work, está en 2FN, pero no está en 3FN porque, dada la
dependencia {composer} → {bCentury}, ninguno de estos atributos forma parte de alguna clave
candidata. Con la tercera forma normal evitamos, pues, que se mezclen hechos (quién es el
compositor de una obra y cuándo nació un compositor, en el ejemplo) aunque compartan
atributos que son clave en un hecho (composer, en el ejemplo) y otros que no lo son. De este
modo, evitaremos redundancias, como la repetición del siglo de nacimiento de un compositor
tantas veces como obras del compositor aparezcan en la relación. Para normalizar a 3FN, como
antes, debemos separar el hecho que corresponde a la dependencia que viola la condición de
3FN. Aplicado al ejemplo anterior, obtendremos:

4.3.4.Forma normal de Boyce-Codd

Una relación está en la forma normal de Boyce-Codd (FNBC) si, y solo si, está en 3FN y los
determinantes de todas las dependencias que presenta la relación son claves candidatas de esta.
Para ver un ejemplo, podemos fijarnos en la siguiente relación, que está en 3FN:

Se trata de una relación similar a la del ejemplo anterior, a la que hemos añadido una nueva
manera de identificar las obras. Ahora lo podemos hacer con un nombre y un código. La relación
presenta redundancia porque repetimos tanto el nombre como el código de cada obra tantas
veces como grabaciones tenga la obra. Cuando se definió la 3FN no se previó una situación
como esta, en la que hay dos claves candidatas compuestas, solapadas y con dependencias
entre partes de estas claves.

Tal y como hemos constatado gráficamente, existen cuatro dependencias en esta relación:

 {workCode} → {workName}

 {workName} → {workCode}

 {workCode, record} → {durWorkRecord}

 {workName, record} → {durWorkRecord}
Los determinantes de las dos últimas son claves candidatas de la relación, pero los
determinantes de las dos primeras, no. Por lo tanto, la relación no está en FNBC. La figura 40
muestra una posible extensión de la relación.

Figura 40. Ejemplo de relación que cumple la 3FN pero no la FNBC

Observad que, efectivamente, se pueden producir anomalías. Por ejemplo, si queremos cambiar
el nombre de la Sinfonía 5, tendremos que modificar tres tuplas.

Para normalizar en la FNBC tenemos que eliminar las dependencias cuyo determinante no
constituye una clave candidata. Puesto que hay dos, podemos hacerlo de dos maneras:

1) Eliminando {workCode} → {workName}

2) Eliminando {workName} → {workCode}

Nos decidiremos por una opción u otra en función de si preferimos acceder a través del código o
del nombre de la obra. Independientemente de la opción seleccionada, será preciso elegir cuál
es la clave primaria de la relación Works, que tiene dos claves candidatas. Lo más coherente
será elegir como clave primaria el atributo que es referenciado desde la
relación Recordings (workCode si hemos elegido la opción 1 y workName si hemos elegido la
opción 2).

La forma normal de Boyce-Codd

Esta forma normal se tuvo que definir (lo hicieron Boyce y Codd en 1974) para corregir algunas

carencias de la 3FN que, cuando Codd la enunció en 1970, pensaba que bastaba para evitar las

anomalías de actualización.

4.3.5.Reglas de Armstrong
Tal y como hemos comentado, vistas las cuatro primeras formas normales, presentaremos dos
algoritmos capaces de normalizar un esquema relacional hasta FNBC. Estos algoritmos se basan
en una serie de propiedades que tienen las dependencias funcionales, que nos permiten deducir
propiedades nuevas a partir de las que ya conocemos. Pongamos por ejemplo la relación que
hemos utilizado para presentar las dependencias funcionales:
Compositions(work, composer, yearComp, bCentury, digitDegree)

Antes hemos mencionado que work es su clave, pero también podríamos haberlo deducido así:

 {work} → {composer, yearComp}, podemos afirmarlo por el conocimiento que tenemos

del dominio sobre el que hacemos el diseño.

 Asimismo, como conocedores del dominio, sabemos que {composer} →

{bCentury, digitDegree}.

 Y ahora podemos razonar que si work determina composer, work también determina los

atributos determinados por composer, y deducimos que work determina todos los
demás atributos.

Las reglas de deducción de Armstrong que permiten hacer este y otros razonamientos son

las que se enumeran a continuación:

 Reflexividad: X → X

 Aumentatividad: si X → Y, entonces X ∪ Z → Y

 Distributividad: si X → Y ∪ Z, entonces X → Y y X → Z

 Aditividad: si X → Y y X → Z, entonces X → Y ∪ Z

 Transitividad: si X → Y y Y → Z, entonces X → Z

 Seudotransitividad: si X → Y y Y ∪ Z → W, entonces X ∪ Z → W

La clausura transitiva de un conjunto de dependencias D es el conjunto que se obtiene si se
aplican repetidamente y de manera exhaustiva (hasta que ya no se pueden deducir nuevas
dependencias) las reglas de Armstrong. La clausura transitiva de D, que denotamos con D+,
contiene todas las dependencias que son consecuencia de D y solo estas.

Por este motivo, la clausura de un conjunto de dependencias nos sirve para:

Reflexión

Hay que aclarar que este no es un conjunto mínimo de reglas, puesto que algunas se pueden deducir

a partir de las otras. En todo caso, tampoco hay un conjunto mínimo único, sino que podemos elegir

varios conjuntos como axiomas y demostrar las otras reglas a partir de estos axiomas.

 Confirmar o descartar una dependencia que sospechamos que se verifica.

 Encontrar todas las claves candidatas de las relaciones. Si queremos normalizar hasta
FNBC, esta información es imprescindible.

 Confirmar o descartar que dos esquemas lógicos son equivalentes. A partir de las
dependencias conocidas de D1 y D2, se puede decir que D1 y D2 son equivalentes si se
verifica que D 1 + = D 2 + .

Tomando como base algunas o todas estas reglas, se han definido algoritmos de normalización.

A continuación, presentamos dos algoritmos que se pueden ver como una aproximación a la
generación automática de un esquema lógico a partir de los atributos y las dependencias de un
dominio que surgen de una actividad previa equivalente al diseño conceptual de la BD. El primer
algoritmo sigue un enfoque descendente, de descomposición de una relación potencialmente
muy grande que representa toda la información del dominio, mientras que el segundo está
planteado desde un punto de vista ascendente, de agrupación de pequeñas informaciones
elementales.

Reflexión

La normalización hasta FNBC es el grado de normalización mínimo que se requiere si no queremos que

nuestra base de datos resulte afectada por anomalías.

4.3.6.Algoritmo de análisis
La idea del algoritmo de análisis parte de una única relación, denominada relación universal, que
contiene todos los atributos identificados. Utilizando las dependencias que también se deben
haber identificado previamente, el algoritmo secciona repetidamente la relación universal hasta
obtener un conjunto de relaciones normalizado. En cada paso de la partición, se comprueba si
hay alguna relación que no está en la FNBC. Si no se encuentra ninguna, es que hemos
conseguido un esquema normalizado; de lo contrario, se elige una de las relaciones que no
están en la FNBC y se divide en dos usando la dependencia (o una cualquiera, si hay varias) que
viola la FNBC en aquella relación. Este proceso se repite hasta que llegamos a la normalización.
De hecho, el proceso es el que seguimos intuitivamente cuando normalizamos un esquema, con
la diferencia de que habitualmente no partimos de una relación universal sino de un conjunto de
relaciones resultantes de un diseño previo.

4.3.7.Algoritmo de síntesis
En este otro algoritmo, se sigue un enfoque ascendente. Partiendo de múltiples relaciones
pequeñas, el algoritmo las fusiona para encontrar un conjunto de relaciones normalizado y tan
compacto como sea posible. Estas relaciones iniciales provienen de lo que se
denomina recubrimiento mínimo de las dependencias funcionales, que se define como un
conjunto de dependencias más simple a partir del cual se pueden deducir las dependencias
iniciales. El recubrimiento mínimo se genera en tres fases:

1) Desdoblar las dependencias de manera que sólo haya un atributo en la parte derecha.

2) Simplificar los determinantes eliminando atributos superfluos. Podremos eliminar los atributos
que vienen determinados por otros atributos del mismo determinante en virtud de las
dependencias.

3) Eliminar dependencias redundantes (dependencias que se pueden deducir a partir de otras

dependencias).

Cada una de las dependencias del recubrimiento mínimo da lugar a una de las múltiples
relaciones iniciales; y estas relaciones se van fusionando, agrupando las que comparten una
clave candidata.

Ejemplo de obtención de un algoritmo de síntesis

Tomemos, por ejemplo, las dependencias siguientes:

 {codigoObra} → {nombreObra}, {nombreObra} → {codigoObra}

 {codigoObra, nombreObra} → {compositor, sigloNac}

 {compositor} → {sigloNac}

 {codigoObra, grab} → {duracionObraGrab}
obtenemos un recubrimiento mínimo siguiendo los pasos que hemos descrito:

1) Tenemos que desdoblar {codigoObra, nombreObra} → {compositor, sigloNac} en

{codigoObra, nombreObra} → {compositor} y {codigoObra, nombreObra} → {sigloNac}.

2) Los determinantes de las dos relaciones obtenidas se pueden simplificar. El resultado, entre
otros posibles, es {codigoObra} → {compositor} y {codigoObra} → {sigloNac}

3) Ahora podemos detectar que tenemos una dependencia redundante: {codigoObra} →

{sigloNac}, que se puede deducir a partir de {codigoObra} → {compositor} y {compositor} →
{sigloNac}. El recubrimiento mínimo que obtenemos al finalizar este tercer paso está formado
por estas dependencias: {codigoObra} → {nombreObra}, {nombreObra} → {codigoObra},
{codigoObra} → {compositor}, {compositor} → {sigloNac} y {codigoObra, grab} →
{duracionObraGrab}.

Las dependencias del recubrimiento han originado estas relaciones iniciales:

(codigoObra, nombreObra), (nombreObra, codigoObra), (codigoObra, compositor),
(compositor, sigloNac) y (codigoObra, grab, duracionObraGrab). Las tres primeras relaciones
comparten una clave candidata: codigoObra. Se fusionarán y el esquema final obtenido por el
algoritmo es:

4.3.8.Cuarta forma normal

La condición que define esta forma normal no se basa en dependencias funcionales sobre hechos
monovaluados, sino que se basa en dependencias sobre hechos multivaluados que, si no se
trasladan correctamente al esquema lógico, originan anomalías en relaciones que están en la
FNBC.

Si intentamos transformar un atributo multivaluado del esquema conceptual en un atributo no

atómico en un esquema relacional pensando que ya lo normalizaremos posteriormente, podemos
obtener una relación en la FNBC que, sin embargo, presenta anomalías puesto que no está en
4FN.

Veamos todo esto con un ejemplo: queremos saber qué orquestas y qué obras ha dirigido cada
director. Se trata de dos hechos multivaluados (un director puede haber dirigido muchas
orquestas y puede haber dirigido muchas obras). Si nos imaginamos una relación que admite
atributos no atómicos, podemos pensar en una situación como la que describe la figura 41.

Figura 41. Una relación con atributos no atómicos

Puesto que sabemos que esto lo podemos imaginar pero no lo podemos definir en un SGBD
relacional, aplanamos la relación para obtener la relación que describe la figura 42. Esta relación
no tiene ninguna dependencia, aparte de la dependencia trivial reflexiva
{conductor, works, orchestras} → {conductor, works, orchestras} y similares.

Figura 42. La relación después de aplanar los atributos

La relación está, pues, en la FNBC. Está claro, sin embargo, que esconde redundancias que
provocan anomalías. Por ejemplo, si queremos registrar que Claudio Abbado ha dirigido la
Filarmónica de Berlín, tendremos que añadir dos tuplas:

El problema, como en los casos presentados en las formas normales anteriores, es que en una
única relación estamos mezclando dos hechos: las orquestas dirigidas y las obras dirigidas. La
condición que revela esta mezcla de hechos es lo que denominamos dependencia multivaluada
independiente, que definimos formalmente a continuación.

Sean X e Y subconjuntos de los atributos de una relación con el conjunto de atributos R. La

dependencia multivaluada independiente de Y respecto de X, que denotamos por X →→ Y, se
verifica si para todo par de tuplas de la relación que tienen el mismo valor en X y diferente en Y,
hay dos tuplas como estas que intercambian los valores de R – X – Y. Es decir, si existen
<x, y1, z1> y <x, y2, z2>, también deben existir <x, y1, z2> y <x, y2, z1> (siendo x valores
posibles para X, y 1 e y 2 valores posibles para Y y z1 y z2 valores posibles para R – X – Y). Cuando
se verifica X →→ Y también se verifica X →→ R – Y.

Reflexión

Los hechos multivaluados aparecen con naturalidad en un esquema conceptual como tipo de relación

con multiplicidad *, pero no se pueden representar como atributos multivaluados en el esquema lógico

puesto el modelo relacional no admite atributos no atómicos.

Efectivamente, pues, tenemos las dependencias {director} →→ {obras} y {director} →→

{orquestas} en la relación Direcciones. Por ejemplo, para las tuplas <C. Abbado, Sinfonía
9, London SO> y <C. Abbado, Sinfonía 5, OCB> existen las tuplas <C. Abbado, Sinfonía
9, OCB> y <C. Abbado, Sinfonía 5, London SO>.

Ahora ya estamos en condiciones de definir la cuarta forma normal.

Reflexión

Observemos que las dependencias funcionales son un caso particular de las multivaluadas en el que

un mismo valor de X solo puede aparecer con un solo valor de Y. Es decir, si {X} → {Y} entonces {X}

→→ {Y}.

Una relación está en cuarta forma normal (4FN) si, y solo si, está en la FNBC y no presenta
dependencias multivaluadas independientes.

La relación Conductions no está en 4FN porque, como hemos visto, presenta dependencias

multivaluadas independientes debidas a la mezcla de hechos en una misma relación. Por este
motivo, la solución vuelve a consistir en la separación de los dos hechos en dos relaciones. La
relación de la figura 42, una vez normalizada, se convierte en las que se presentan en la figura
43.

Figura 43. Dos relaciones normalizadas

Si recapitulamos el proceso que nos ha llevado hasta aquí, recordaremos que todo ha empezado
con unos atributos multivaluados que hemos representado en una sola relación.

Si hubiéramos hecho una traducción sistemática del esquema conceptual, habríamos obtenido
directamente el esquema lógico correcto.

El esquema conceptual de partida se muestra en la figura 44.

Figura 44. Los tipos de relaciones binarias de donde provienen las relaciones
La traducción de los tipos de relación conductsWork y conductsOrc lleva directamente a las
relaciones normalizadas de la figura 43. La relación no normalizada de la figura 42 podría ser el
resultado de traducir un esquema conceptual diferente, que presentamos en la figura 45.

Figura 45. El tipo de relación ternaria de donde proviene la relación

Sin embargo, entonces no existirían las dependencias multivaluadas porque ahora lo que
queremos es registrar un único hecho ternario: qué obras ha dirigido cada director y con qué
orquesta ha dirigido cada obra. En este caso, la relación Conductions, al no presentar las
dependencias multivaluadas, estaría en 4FN. Y ahora podría tener una extensión como la que se
muestra en la figura 46, que antes no era válida de acuerdo con las dependencias.

Figura 46. La extensión de la relación correspondiente al tipo de relación ternaria

Esta relación no presenta anomalías, porque ahora no tiene sentido decir que queremos añadir,
por ejemplo, que Claudio Abbado ha dirigido la Filarmónica de Berlín. Ahora el hecho básico es
que Claudio Abbado ha dirigido la Filarmónica de Berlín interpretando una obra concreta.

Reflexión

Observad que por la definición de dependencia multivaluada independiente, una relación con solo uno

o dos atributos no puede violar la condición de 4FN.

4.3.9.Quinta forma normal

Hay todavía un último caso en el que las tablas mezclan hechos y que la 4FN no detecta.
Tomemos el caso de la figura 46 y supongamos que hay una ley de simetría en el dominio que
afirma que si un director ha dirigido una obra y esta obra la ha interpretado una orquesta y el
director ha dirigido esta orquesta, entonces el director ha dirigido la obra con esta orquesta. En
este caso, la extensión de la figura 46 no cumpliría esta ley; faltaría la tupla

Esto es así porque H. von Karajan ha dirigido la Sinfonía 9 (según la tercera tupla), la OCB ha
interpretado la Sinfonía 9 (según la primera tupla) y H. von Karajan ha dirigido la OCB (según la
cuarta tupla). Por otro lado, añadir esta nueva tupla no implica que la relación deje de estar en
4FN.

En casos así, la relación vuelve a presentar anomalías. Por ejemplo, si un director pasa a dirigir
una nueva obra, por la ley de simetría tenemos que añadir tantas tuplas como orquestas que
han interpretado la obra dirigida por el director. Si intentamos eliminar las anomalías
descomponiendo la relación en dos, tenemos tres opciones de descomposición. Observemos que
ninguna de las opciones es válida:

a) La descomposición siguiente no es válida porque no permite saber qué orquestas han dirigido
los directores (podríamos pensar que Claudio Abbado ha dirigido la Filarmónica de Berlín).

b) La descomposición siguiente no es válida porque no permite saber qué obras ha interpretado
cada orquesta (podríamos pensar que la Sinfónica de Londres ha interpretado la sinfonía 9).

c) La descomposición siguiente no es válida porque no permite saber qué obras han dirigido los
directores (podríamos pensar que Claudio Abbado ha dirigido el concierto para piano 1).

Observemos, pues, que no podemos representar tres hechos con dos relaciones. Sin embargo,
¿qué sucede si tomamos las tres relaciones CondWork, WorkOrc y CondOrc?

Si descomponemos la relación original en estas otras tres relaciones, tenemos la misma

información, porque podemos obtener la relación original haciendo la combinación natural de las
otras tres. Se puede demostrar que esto es así para cualquier extensión que cumpla la ley de
simetría. Esta propiedad se conoce con el nombre de dependencia de proyección-
combinación y es en lo que se basa la definición de quinta forma normal:

Una relación está en quinta forma normal (5FN) si, y solo si, está en 4FN y no presenta
dependencias de proyección-combinación.

De este modo, para saber si una relación que está en 4FN también está en 5FN tenemos que
proyectar y combinar las proyecciones, y a continuación comprobar si obtenemos la misma
relación original. En caso contrario, podemos asegurar que no hay dependencia de proyección-
combinación y que la relación está en 5FN. De lo contrario, tenemos que estudiar si existe una
ley de simetría que suponga que para toda extensión de la relación original, el proceso de
proyección y combinación nos volverá a dar la relación original o si esto solo sucede en algunos
casos.

La relación Conductions en el momento de incorporar la ley de simetría no está en 5FN. Por esto,

si partimos de la extensión de la figura 46 y le añadimos la tupla <H. von Karajan, Sinfonia
9, OCB> que ya hemos comentado que faltaba para cumplir esta ley, y luego proyectamos y
combinamos, volvemos a la extensión de partida. En cambio, si ahora suponemos que no hay
ley de simetría y que la extensión de Conductions es la de la figura 46, haciendo el proceso de
proyección y combinación no obtendríamos la extensión de partida, sino la tupla adicional <H.
von Karajan, Sinfonía 9, OCB>, y podríamos decir inmediatamente que la relación está en 5FN.

Si retomamos el caso desde el comienzo, veremos que, si partimos del esquema conceptual
correcto y lo traducimos de manera correcta al modelo relacional, obtendremos directamente el
esquema lógico normalizado.

Cuando no se da la ley de dependencia, estamos ante un tipo de relación ternaria (la que se
muestra en la figura 45), que por tanto, se convierte en una única relación normalizada. Cuando
añadimos la ley de simetría, estamos introduciendo tres tipos de relaciones binarias y una
ternaria que se deriva de las tres binarias, como se muestra en la figura 47.

A partir de este esquema conceptual, debemos traducir, no el tipo de relación derivado (que
daría lugar a la relación que no está en 5FN), sino las tres binarias (que producen las tres
relaciones que sí están en 5FN).

Figura 47. Los tipos de relaciones binarias de donde provienen las relaciones normalizadas y el tipo de

relación ternaria derivada

Reflexión

A la vista de la definición, podemos afirmar que una relación con solo uno o dos atributos no puede

violar la condición de 5FN.

4.4.Práctica de la normalización
El proceso de normalización tiene en general efectos beneficiosos para la base de datos y
preserva la semántica del esquema de partida. El proceso siempre es factible y existen
algoritmos que normalizan hasta la FNBC. Un mismo esquema de partida se puede normalizar en
general de más de una manera (tanto si lo hacemos manualmente como si usamos algún
algoritmo), y es trabajo del diseñador elegir la alternativa que más interesa en cada caso.

Los efectos beneficiosos de aplicar las formas normales son la eliminación de redundancias y
anomalías y la clarificación del esquema, al separar los hechos diferentes que quizá se
encuentran mezclados en el esquema inicial.

El momento y la oportunidad de la aplicación de la normalización pueden ser varios en función

del contexto en el que se lleva a cabo el diseño de la base de datos. Si nos encontramos en una
situación de desarrollo a partir de un sistema preexistente (o de una parte), puede ser
interesante aplicar la normalización antes de empezar, si no la tenemos garantizada. Si nos
encontramos modificando un esquema lógico cuya documentación correspondiente no tenemos
en el esquema conceptual, la normalización a posteriori es la única manera de tener la certeza
de que el resultado está normalizado. En cambio, si partimos de cero y disponemos de un
esquema conceptual correcto, una traducción correcta al modelo relacional nos asegura un
esquema lógico normalizado. Aun así, puesto que el esquema conceptual de partida puede ser
incorrecto y en el proceso de traducción podemos cometer errores, es muy recomendable
comprobar si el resultado final está normalizado. Por ejemplo, si hemos introducido en el
esquema un tipo de relación ternaria en vez de dos o tres binarias, es posible que esto haya
provocado la aparición de alguna relación que no está en 4FN o 5FN.

La normalización tiene como consecuencia no deseada la penalización de la recuperación de la

base de datos. Puesto que descompone las relaciones, separa atributos que en un esquema no
normalizado estarían en la misma relación. Esto implica la necesidad de ejecutar más
operaciones de combinación para obtener información que en el esquema no normalizado
lograríamos consultando una única relación.

En general, sin embargo, podemos asumir esta desventaja a cambio de eliminar las anomalías y
facilitar la integridad de la base de datos. Hay, sin embargo, casos o partes de las bases de
datos en los que las actualizaciones son poco frecuentes. En estos casos, el equilibrio entre
ventajas e inconvenientes puede llevarnos a decantarnos por la opción de no normalizar.

La desnormalización es el proceso de deshacer la normalización agrupando datos lógicamente

independientes o añadiendo redundancia a la base de datos con el objetivo de hacer más
eficientes las consultas.

Hay que tener presente que este proceso penaliza las actualizaciones de la base de datos y
requiere un diseño muy cuidadoso de las restricciones para garantizar que la base de datos se
mantiene consistente. Se requiere, por lo tanto, un análisis cuidadoso de ventajas e
inconvenientes de la desnormalización en cada caso. Un caso en el que la desnormalización sale
más a cuenta es el de las bases de datos dedicadas solo a consultar datos históricos agregados
por diferentes conceptos.

Una opción a medio camino de la desnormalización es la definición de vistas materializadas

adicionales al diseño normalizado que ayuden a acelerar las consultas más frecuentes o
costosas.

Resumen
En este módulo hemos estudiado el proceso de diseño lógico como una de las etapas del
desarrollo de una base de datos para un sistema de información. Este proceso parte del
esquema conceptual que hemos obtenido en la fase de especificación y genera como resultado el
esquema lógico de la base de datos.

Hemos empezado el estudio identificando las trampas de diseño, posibles errores que pueden
haberse cometido durante el diseño conceptual y que conviene repasar antes de tomarlo como
punto de partida del diseño lógico.

Hemos tratado la etapa de diseño lógico en el caso particular de transformación de modelos

conceptuales basados en el lenguaje UML en modelos lógicos relacionales. Hemos analizado cada
uno de los elementos del esquema conceptual (tipos de entidades, tipos de relaciones,
generalizaciones y tipos de entidades asociativas) y hemos ofrecido pautas de transformación
para cada uno. Hemos separado cada elemento en los distintos casos en los que se puede dividir
y hemos dado la solución para cada uno, sin dejar de lado las restricciones. En algunos casos,
hemos presentado varias alternativas de transformación y hemos puesto énfasis en el hecho de
que muchas veces la mejor alternativa será la que evite la presencia de valores nulos.

Finalmente, hemos estudiado la teoría de la normalización, que permite asegurar que el

esquema relacional satisface una serie de condiciones que garantizan una mejor calidad de la
base de datos. Hemos identificado las anomalías que se pueden producir en una base de datos
no normalizada y hemos definido una serie de formas normales mediante condiciones que, si son
satisfechas por la base de datos, nos garantizan la ausencia de anomalías. Hemos terminado con
una reflexión sobre las ventajas y los inconvenientes de la normalización y una breve
introducción al concepto de desnormalización.

Glosario
abrazo mortal de carga f
Imposibilidad de insertar tuplas en ninguna tabla de un conjunto de tablas porque las
claves foráneas que contienen forman un ciclo.

abrazo mortal de definición f

Imposibilidad de definir un conjunto de tablas porque las claves foráneas que contienen
forman un ciclo.

anomalía de actualización f
Necesidad de actualizar muchas tuplas para reflejar un cambio elemental.

clausura transitiva de un conjunto de dependencias f

Conjunto de todas las dependencias que se pueden deducir aplicando de manera
reiterada las reglas de Armstrong a partir del conjunto inicial.

dependencia funcional f
En una relación, decimos que un conjunto de atributos Y depende de un conjunto de
atributos X (X → Y) si siempre que dos tuplas tienen los mismos valores en los atributos
de X, también tienen los mismos valores en los atributos de Y.

dependencia funcional completa f

X → Y es completa si no existe ningún X' subconjunto propio de X tal que X' → Y.

dependencia multivaluada independiente f

Decimos que hay una dependencia multivaluada independiente de Y respecto a X, que
denotamos por X →→ Y, si se verifica que para todo par de tuplas de la relación que
tienen el mismo valor en X y diferente en Y, hay dos tuplas como estas que intercambian
los valores de R – X – Y.

dependencia proyección-combinación f
Decimos que una relación con tres atributos presenta una dependencia de proyección-
combinación si para cualquier extensión correcta de la relación se verifica que, como
resultado de descomponerla en otras tres relaciones de dos atributos (haciendo las
correspondientes proyecciones) y combinar estas tres relaciones a continuación,
obtenemos nuevamente la relación original.

desnormalización f
Proceso consistente en deshacer la normalización agrupando datos lógicamente
independientes o añadiendo redundancia a la base de datos, con el objetivo de hacer
más eficientes las consultas.

determinante m
Conjunto de atributos X de una dependencia funcional X → Y.
diseño lógico m
Proceso de transformación de un esquema conceptual en un esquema lógico de base de
datos.

forma normal f
Decimos que una relación está en una determinada forma normal si satisface las
condiciones fijadas por aquella forma normal. Las formas normales son inclusivas: la
condición de una forma normal de nivel superior implica la condición de cada uno de los
niveles inferiores y, por lo tanto, si una relación está en una forma normal también está
en todas las formas normales de nivel inferior.

normalización f
Proceso por el cual, a partir de un conjunto de relaciones, se obtiene un conjunto de
relaciones equivalente que satisface la condición de la forma normal deseada.

trampa de diseño m
Patrón del esquema conceptual que puede inducir a cometer errores en la interpretación
del mundo real.

recubrimiento mínimo m
Conjunto más simple de otro conjunto a partir del cual se pueden deducir las
dependencias del conjunto original.

reglas de Armstrong f pl
Conjunto de reglas de deducción que permiten demostrar si una dependencia es
consecuencia de otras.

restricción f
Condición que limita las extensiones válidas de una relación.

Bibliografía
Camps, R.; Cassany M. J.; Conesa, J.; Costal, D.; Figuls, D.; Martín, C.; Rius, A.;
Rodríguez, M. E.; Urpí, T. (2011). Uso de bases de datos. FUOC.

Elmasri, Ramez; Navathe, Shamkant, B. (2007). Fundamentos de sistemas de bases de

datos (5.ª ed.). Madrid: Pearson Educación.

Gulutzan, P.; Pelzer, T. (1999). SQL-99 Complete, really. R&D Books.

Ramakrishnan, Raghu; Gehrke, Johannes (2003). Database management systems (3.ª ed.).

Boston: McGraw-Hill Higher Education.

Sciore, E. (2008). Database Design and Implementation. Wiley.

Unified Modeling Language: Superstructure (versión 2.0, OMG doc. formal/05-07-04). Accesible

en línea desde la web www.omg.org.

Diseño físico de bases de datos

 Blai Cabré i Segarra
  Jordi Casas Roma

 Dolors Costal Costa

 Pere Juanola Juanola

 Àngels Rius Gavidia

 Ramon Segret i Sala

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a

una licencia Creative Commons de tipo Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND)

v.3.0. Se puede copiar, distribuir y transmitir la obra públicamente siempre que se cite el autor y la

fuente (Fundació per a la Universitat Oberta de Catalunya), no se haga un uso comercial y ni obra

derivada de la misma. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice
 Introducción

 Objetivos

 1.Conceptos previos

 2.El nivel lógico

o 2.1.Componentes lógicos

 3.El nivel físico

o 3.1.La página

 3.1.1.Estructura de una página

 3.1.2.Estructura de una fila

 3.1.3.Estructura de un campo

 3.1.4.Gestión de la página

 3.1.5.Otros tipos de páginas

o 3.2.La extensión

o 3.3.El fichero

o 3.4.Visión general de las E/S en un SGBD

 4.El nivel virtual

o 4.1.Justificación de la existencia del nivel virtual

o 4.2.El espacio virtual y sus asociaciones

o 4.3.Estructura del espacio virtual

 4.3.1.Direccionamiento en un SGBD
  5.Transformación del modelo lógico en el modelo físico
o 5.1.Tabla

 5.1.1.Clave primaria y clave alternativa

 5.1.2.Índice

 5.1.3.Restricciones
o 5.2.Espacio para tablas

o 5.3.Base de datos

 6.Implementación de métodos de acceso

o 6.1.Los métodos de acceso a una BD

 6.1.1.Los datos

 6.1.2.Los accesos por posición

 6.1.3.Los accesos por valor

 6.1.4.Los accesos por varios valores

o 6.2.Implementación de los accesos por posición

o 6.3.Implementación de los accesos por valor

 6.3.1.Necesidad de los índices

 6.3.2.Características generales de los índices

 6.3.3.Árboles B+

 6.3.4.Dispersión

 6.3.5.Índices agrupados
o 6.4.Implementación de los accesos por varios valores

 6.4.1.Implementación de los accesos directos

 6.4.2.Implementación de los accesos secuenciales y mixtos

o 6.5.Índices del sistema Oracle

 6.5.1.Accesos por valor

 6.5.2.Accesos por varios valores

 Resumen

 Glosario

 Bibliografía

Introducción
El diseño físico de bases de datos constituye la cuarta etapa en el proceso de diseño de una base
de datos. En las etapas anteriores se ha llevado a cabo el análisis de requisitos, el diseño
conceptual y, finalmente, el diseño lógico de la base de datos. En este módulo veremos el
proceso de transformación del modelo lógico, obtenido en la etapa anterior, hacia un modelo
físico que nos permita obtener una implementación sobre un sistema de gestión de bases de
datos (SGBD).

Antes de iniciar esta etapa, hay que seleccionar el SGBD concreto sobre el cual se quiere
implementar la base de datos. En este módulo nos centraremos en las bases de datos
relacionales; por lo tanto, el objetivo es ver el proceso de transformación de un modelo lógico
relacional hacia un modelo físico y concretar un SGBD relacional.

Este módulo se estructura en tres partes:

1) En la primera parte veremos cómo hay que estructurar y almacenar la información de la base
de datos en un soporte físico no volátil para que pueda ser recuperada. Presentaremos los
niveles lógico, físico y virtual de las bases de datos (apartados 1, 2, 3 y 4).

2) En la segunda parte de este módulo veremos el proceso de transformación del modelo lógico
relacional hacia el modelo físico, que nos permitirá una implementación sobre un SGBD concreto
de la base de datos (apartado 5).

3) Finalmente, en la tercera parte, veremos el funcionamiento de los métodos principales de

acceso a los datos (apartado 6).

Objetivos
En los materiales didácticos de este módulo, encontraremos las herramientas indispensables
para alcanzar los objetivos siguientes:

1. Conocer la estructura física que utiliza la base de datos para almacenar los datos de
manera no volátil.

2. Conocer la funcionalidad y la estructura del nivel virtual y del nivel físico.

3. Aprender a realizar el diseño físico de la base de datos a partir de su diseño lógico

adaptado a las características de un SGBD concreto.

4. Definir los índices necesarios y convenientes en cada tabla para que las aplicaciones
tengan un buen rendimiento cuando accedan a la base de datos.

5. Conocer los diferentes métodos de acceso necesarios para efectuar consultas y

actualizaciones en los datos almacenados en las bases de datos.

6. Comprender la utilidad de los índices para la implementación de los accesos por

valor.

7. Conocer la estructura de los índices de árboles B +.

1.Conceptos previos
La manera más sencilla de explicar una base de datos (BD) es decir que se trata de un conjunto
de datos persistentes relacionados entre sí. La característica de persistencia implica que los
datos no han de desaparecer entre ejecuciones sucesivas de programas, aunque entre estas
ejecuciones transcurra un intervalo de tiempo largo. Este requisito obliga a su vez a tener los
datos entre ejecución y ejecución almacenados en un medio no volátil, normalmente en un disco
magnético.

Para comprender qué relación hay entre los datos tal como los ve el programador o el usuario
final y tal y como están almacenados en el soporte no volátil, utilizaremos una arquitectura de
tres niveles, que denominaremos arquitectura de los componentes de almacenamiento,
representada en la figura 1.

Figura 1. Arquitectura de los componentes de almacenamiento

Lo primero que vemos es que la arquitectura de los componentes de almacenamiento es de tres
niveles:

1) El nivel lógico corresponde a todos los componentes que, de una manera más o menos
directa, son conocidos y manipulados por el programador o por el usuario final. Estos
componentes forman la interfaz externa o de usuario del sistema de gestión de la base de datos
(SGBD). De manera muy simplificada, podemos considerar que en el nivel lógico hay un
conjunto de datos estructurados en tablas. De hecho, todos los demás componentes lógicos
giran en torno a las tablas.

2) Las tablas deben ser persistentes; por este motivo se almacenan en un soporte no volátil y
utilizan unas estructuras determinadas, que son los componentes que constituyen el nivel
físico.

¿Qué es una arquitectura?

Una arquitectura, como cualquier otra manera de esquematizar la realidad, es una herramienta

sencilla y potente ideada para abstraer y entender los rasgos fundamentales de los sistemas más

complejos.

3) Entre los niveles físico y lógico existe un tercero que denominaremos nivel virtual. Este nivel
proporciona al SGBD (1) una visión simplificada del nivel físico, como ya veremos.

Ya conocéis los componentes del nivel lógico. En este módulo presentamos los componentes de
los otros dos niveles, el virtual y el físico, que denominamos conjuntamente componentes de
almacenamiento porque controlan la disposición física de los datos en el soporte no volátil.
 Abreviamos sistema gestor de bases de datos con la sigla SGBD.
(1) 

Terminología

En este módulo denominamos programador a la persona que confecciona programas que

interaccionan con la base de datos, normalmente mediante sentencias de SQL, y usuario final, a la

persona que interacciona con los datos directamente por medio de una interfaz gráfica.

2.El nivel lógico

Aunque los componentes del nivel lógico ya se estudian en otro módulo didáctico, recordaremos
brevemente los conceptos más importantes para poder relacionar los componentes lógicos con
los de los niveles físico y virtual.

Ved también

Podéis ver los componentes del nivel lógico en el módulo “Diseño lógico de bases de datos” de esta

asignatura.

2.1.Componentes lógicos
En la figura 1 podemos ver que el componente lógico más importante es la tabla y, para
reflejarlo, la hemos representado con un tramado. El conjunto de tablas es el núcleo
fundamental de la base de datos por dos motivos: es el conjunto de datos disponibles para el
usuario, y es también el conjunto más importante y voluminoso de datos almacenados en los
soportes físicos.

El usuario puede acceder directamente a las tablas o bien puede acceder a estas de manera
indirecta por medio de las vistas; por este motivo, tablas y vistas están agrupadas como el
conjunto de componentes de datos.

Una base de datos tiene, aun así, otros componentes que no son las tablas y las vistas, pero que
están estrechamente relacionados con éstas. Se trata, entre otros, de las restricciones  (2) , que
definen ciertas reglas que tienen que cumplir los datos, o los disparadores  (3) , los cuales indican
acciones que se tienen que ejecutar si se cumplen ciertas condiciones. Denominamos todos
estos otros componentes conjunto de componentes de control, puesto que en cierto modo
permiten controlar los datos dinámicamente.

También se puede considerar que los índices pertenecen al conjunto de componentes de control,
aunque con un matiz ligeramente diferente, dado que su función fundamental es de
rendimiento: facilitan el acceso a los datos en un tiempo razonable.

En inglés, constraints.
(2) 

En inglés, triggers.
(3) 

3.El nivel físico

Como ya hemos dicho, los datos se almacenan en soportes no volátiles, normalmente en discos
magnéticos en la mayoría de los sistemas informáticos (desde los grandes sistemas hasta los
ordenadores personales). Estos soportes son controlados por el sistema operativo de la
máquina, que es el que realmente efectúa la lectura y la escritura física de los datos. Los SGBD
no reimplementan estas funciones, sino que utilizan las rutinas especializadas del sistema
operativo (SO) para leer y escribir los datos y también para la gestión física de los dispositivos.
Los sistemas operativos gestionan los datos en los discos magnéticos a partir de unas unidades
globales denominadas ficheros (4) . Normalmente, el sistema operativo no reserva una gran
cantidad de espacio de disco para cada fichero, sino que lo va adquiriendo a medida que lo
necesita. La unidad de adquisición es la denominada extensión (5) , otro de los componentes de
este nivel. Finalmente, la extensión es un múltiplo entero del componente físico más pequeño,
que es la página. La página (6) es el elemento que contiene y almacena los datos del nivel lógico, y
por este motivo también la hemos tramado en la figura 1. A continuación veremos estos tres
componentes, del menor al mayor.

En inglés, files.
(4) 

En inglés, extent.
(5) 

En inglés, page.
(6) 

3.1.La página
Para entender qué es una página de una BD (7) o de un SGBD, no partiremos de una definición,
sino de una descripción de lo que es una página en una BD desde dos puntos de vista diferentes,
aunque complementarios:

Abreviamos base de datos con la sigla BD.

(7) 

 Los datos se almacenan en dispositivos externos pero, por otro lado, sabemos que para
efectuar cualquier operación tienen que estar presentes en la memoria principal del
ordenador. Debe haber, pues, un transporte de datos entre la memoria externa (que
normalmente es un disco) y la memoria interna (o memoria principal). Este transporte
se hace empleando una unidad discreta de transporte de datos que en los SO  (8) se
denomina bloque y en los SGBD recibe el nombre de página.

 Paralelamente al hecho de ser la unidad de entrada/salida, la página también es la

unidad de organización de los datos almacenados. El espacio del disco siempre se
asigna a un número múltiple de páginas, y cada página puede estar direccionada de
manera individual.

Concretando, diremos que la página es la unidad mínima de acceso y transporte del sistema de
entrada/salida (E/S) de un SGBD, lo cual la hace ideal para ser a su vez la unidad de
organización más importante de los datos almacenados.

Observad que en la definición anterior hemos definido la página como “unidad mínima de acceso
y transporte”. La razón es que, del mismo modo que nunca se accede a menos de una página, sí
que se puede acceder al mismo tiempo a un número entero de páginas consecutivas. Esta
cuestión, que veremos más adelante, no invalida la explicación que hemos dado hasta ahora de
la página ni su importancia dentro de la arquitectura de componentes. Se trata sólo de una
opción de rendimiento del sistema.

Abreviamos sistema operativo con la sigla SO.

(8) 

Que la página sea la unidad de organización del nivel físico no significa que no tenga su propia
estructura interna. De hecho, en una página hay diferentes componentes. A estos componentes
que hay en el interior de la página sólo pueden acceder las rutinas del SGBD, una vez la página
ya está en la memoria principal del ordenador. En cambio, a la página como unidad accede (para
leer y escribir) el subsistema de E/S (9) del SO de la máquina.
 Abreviamos la expresión entrada/salida con la sigla E/S.
(9) 

Un símil artístico

Imaginad que la página es un cuadro. El SGBD sería entonces el pintor; es quien ve el interior del

cuadro y lo llena (lo pinta). Una vez listo, lo envuelve y llama a su mozo (el sistema operativo), que

toma el cuadro y, sin verlo, lo transporta al almacén.

3.1.1.Estructura de una página

Para facilitar la explicación, ahora nos centraremos en las páginas que almacenan tablas. Estas
páginas se suelen denominar páginas de datos. Más adelante, ampliaremos algunos detalles
para generalizar la estructura de la página.

La página es de longitud fija. Hay SGBD que permiten elegir el tamaño de la página entre un
pequeño repertorio. Otros solo tienen un tamaño único. La estructura de la página, que se
muestra en la figura 2, es muy similar en todos los SGBD.

Figura 2. Estructura de una página

Una página consta de los elementos siguientes, enumerados desde la dirección más baja de la
página hasta la más alta:

a) Una cabecera, con información de control de la página.

b) Un cierto número de registros, que aquí denominaremos filas porque corresponden a las filas
de las tablas del nivel lógico. Este número puede variar con el tiempo, y en un momento
concreto puede ser igual a cero.

c) Un espacio libre.

El tamaño de una página

Los valores más corrientes del tamaño de una página actualmente son 2 kB, 4 kB y 8 kB.

Posiblemente, 4 kB es el tamaño más habitual.

d) Un vector de direcciones de fila (VDF), que tiene tantos elementos como filas hay en la
página. Cada elemento del VDF (10) contiene la dirección de una fila dentro de la página (apunta a
la fila). El elemento que ocupa la posición de dirección más alta en el VDF apunta a la fila que
ocupa la dirección más baja en la página, tal y como podéis ver en la figura 2. La fila siguiente
(a continuación de la primera) está apuntada por el elemento del VDF a la izquierda del primer
elemento.

Así pues, las filas se van colocando de izquierda a derecha en el orden creciente de las
direcciones dentro de la página, mientras que los elementos del VDF se van colocando de
derecha a izquierda desde la posición más alta y siguiendo en el orden decreciente de las
direcciones. De este modo, el espacio libre siempre queda hacia la mitad de la página.

Abreviamos la expresión vector de direcciones de fila con la sigla VDF.

(10) 

3.1.2.Estructura de una fila

El elemento que hemos denominado fila cuando hemos hablado de la estructura de la página
(nivel físico) generalmente registra toda la información correspondiente a una fila de una tabla
(nivel lógico). Por esta razón, su estructura es sencilla. Se trata de una secuencia de campos
(nivel físico), cada uno de los cuales registra la información del campo de la fila correspondiente
(nivel lógico).

Así pues, en cuanto a filas y campos, la correspondencia entre el nivel lógico y el físico es muy
directa.

Es posible que el SGBD necesite guardar alguna información de control en lo que respecta a la
fila y, por este motivo, antes de la secuencia de campos encontramos una cabecera de fila.
Podéis ver la estructura de la fila en la figura 3.

Figura 3. Estructura de una fila

Normalmente, las filas de una tabla son de longitud inferior al tamaño de las páginas y por este
motivo caben en las mismas perfectamente. De todos modos, si la longitud de la fila es superior
a la de la página, los SGBD parten la fila en trozos. Cada trozo se almacena en una página
diferente y apunta al trozo siguiente, como podéis observar en la figura 4.

Figura 4. Almacenamiento de una fila más larga que una página

No os preocupéis ahora si en la figura no acabáis de entender la manera concreta como un trozo

de fila apunta al siguiente. Lo veréis más adelante.

3.1.3.Estructura de un campo
Hemos visto que una página está formada por filas y que una fila está formada por campos. Un
campo de una fila de una tabla (nivel lógico) se almacena como uno de los campos de la fila
dentro de la página (nivel físico).

Un campo normalmente está formado por una cabecera y un contenido, tal como indicamos en
la figura 5.
 Figura 5. Estructura de un campo

La cabecera del campo permite guardar ciertas características del campo, como por ejemplo:

a) La indicación de si el contenido en cada momento es nulo o no lo es. Esta indicación es

necesaria si el campo está definido de manera que admite el valor nulo.

b) La longitud del campo, también en un momento concreto. Esta información es necesaria
cuando el campo se ha definido con un tipo de dato de longitud variable, como por ejemplo el
tipo CHARACTER VARYING.

El contenido del campo es el resultado de almacenar el valor del campo según las normas de
codificación de cada SGBD en cada arquitectura de máquina concreta. A continuación,
encontraréis el formato de almacenamiento de los tipos de datos más comunes en los diferentes
SGBD:

 Tipo SMALLINT: número binario entero de 16 bits.

 Tipo INTEGER: número binario entero de 32 bits.

 Tipo FLOAT: número en coma flotante de 64 bits.

CHARACTER VARYING

CHARACTER VARYING es el nombre del estándar SQL:1999 para el tipo de dato “cadena de caracteres

de longitud variable”, que en varios SGBD comerciales se denomina VARCHAR.

 Tipo CHARACTER(n) o, de manera abreviada, CHAR(n): cadena de nbytes (11) , donde n es

la longitud definida en el tipo de dato.

 Tipo CHARACTER VARYING: como el caso anterior, con la excepción de que aquí n es la

longitud real del valor concreto que el campo tenga en cada momento.

Bytes codificados en código ASCII o bien en el código que utilice la máquina donde funciona el
(11) 

SGBD.

 Tipo DATE: aunque externamente es una cadena de 8 dígitos (4 para el año, 2 para el

mes y 2 para el día), internamente se puede almacenar de manera que ocupe mucho
menos espacio, por ejemplo 4 bytes, siguiendo un patrón de codificación propio de
cada SGBD.

Ahorrar espacio en disco

Los SGBD intentan ahorrar espacio en el disco y tiempo de proceso siempre que sea posible. Por esto,

si el campo no admite nulos y es de longitud fija (por ejemplo, CHAR(3)), entonces esta información

no es necesaria y podemos prescindir de la cabecera. En este caso, el campo ocupa solo el espacio

necesario para almacenar su valor.

3.1.4.Gestión de la página
Después de ver cómo se organiza el espacio de una página y cuáles son sus contenidos,
describiremos brevemente las principales operaciones que un SGBD hace de este espacio y estos
contenidos. Son las siguientes:

1) Formateo de una página. Cuando el SGBD necesita más espacio dentro de un fichero para
almacenar datos, adquiere una nueva extensión. Las páginas de esta extensión se formatean, es
decir, se inicializan de una manera adecuada para que posteriormente las utilice el SGBD.
La inicialización consiste fundamentalmente en escribir la cabecera y dejar el resto de la
página como espacio libre.

2) Carga inicial de filas. Si la extensión inicializada se utiliza para una carga inicial o masiva
de filas de tablas, el SGBD empieza a usar el espacio libre de la página de la manera siguiente:

 La primera fila se coloca detrás de la cabecera, se crea un elemento del VDF que apunta
a esta fila y se coloca al final de todo de la página.

 La segunda fila ocupa el lugar inmediatamente detrás de la primera, y su elemento del

VDF ocupa el lugar justo delante del elemento de la fila anterior.

El proceso se repite sucesivamente, como ya habéis visto en la explicación de la estructura de

una página.

De este modo el espacio libre va disminuyendo, pero siempre ocupa un lugar en torno al centro
de la página. El administrador de la base de datos (DBA  (12) ) normalmente habrá fijado un tanto
por ciento de espacio libre mínimo que el SGBD tiene que respetar en una carga masiva de filas.
Esto significa que, cuando el proceso de carga detecta que el espacio que queda libre en una
página es precisamente este espacio libre mínimo, ya no coloca más filas y empieza a hacerlo en
la página siguiente.

La finalidad de esta limitación es dejar un cierto espacio libre en todas las páginas para que sea
aprovechado para las operaciones que veremos a continuación.

Abreviamos administrador de la base de datos con la sigla DBA, de la expresión inglesa database

(12) 

administrator.

Administrador de la BD

El administrador de la BD (database administrator, DBA) es la persona -o equipo de personas-

encargada, entre otras cosas, de la gestión de los componentes de almacenamiento.

3) Alta posterior de una nueva fila. Para añadir una fila a una tabla de la BD, el SGBD en el
nivel físico localiza primero la página donde tiene que añadir la fila. Esta página se
denomina página candidata. Una vez el SGBD sabe cuál es la página candidata, utiliza el espacio
libre disponible en la página para colocar la fila y dejarla apuntada por un nuevo elemento del
VDF. La fila y el elemento del VDF se colocan según el criterio explicado anteriormente.

Añadir una fila

Las filas se añaden con la sentencia INSERT.

Puede llegar un momento en el que ya no quede espacio libre suficiente en la página candidata
para colocar la fila. Entonces, la fila se coloca en otra página según algoritmos propios de cada
SGBD.

4) Baja de una fila. La baja de una fila consiste en liberar el espacio ocupado por la fila y el
elemento del VDF. En este momento, o más adelante, el SGBD reorganiza la página para que el
espacio liberado por la baja se una al resto del espacio libre de la página. Habrá un
desplazamiento de filas y de elementos del VDF para que la estructura de la página continúe
siendo tal y como hemos descrito anteriormente.

5) Cambio de longitud de una fila. Un cambio de longitud de una fila puede afectar de tres
maneras a la reorganización del espacio de la página:

a) Si el cambio tiene como resultado una disminución de la longitud de la fila, el espacio liberado
se unirá al espacio libre según el mecanismo que acabamos de explicar.

b) Si, por el contrario, da lugar a un aumento de la longitud y el espacio extra requerido está
disponible en forma de espacio libre dentro de la página, la fila quedará en su lugar ocupando
más espacio y las filas que la siguen se desplazarán hacia la derecha (hacia direcciones más
altas).

c) En caso de que la necesidad de espacio no se pueda servir a partir del espacio libre de la
página, esta fila se traslada hacia otra página que disponga de espacio suficiente. En la página
original y en la posición original se crea una dirección que apunta hacia la nueva posición de la
fila, como se indica en la figura 6.

Figura 6. Fila situada fuera de la página original

Como en el caso de las filas que ocupan más de una página, no os preocupéis tampoco si no
acabáis de entender, a partir de la figura, la manera como se apunta a la fila que se ha
trasladado de la página original a la nueva. Lo veréis más adelante.

Reflexión

Las diferentes formas de localizar una página quedan fuera del alcance de este módulo.

3.1.5.Otros tipos de páginas

Hasta ahora nos hemos centrado en las páginas que contienen filas de tablas, las páginas de
datos. Cómo sabéis muy bien, en el nivel lógico hay otros componentes. De todos modos, la
estructura de página que acabáis de ver sirve de base para entender los otros tipos de páginas.

En efecto, dejando los índices aparte, todos los demás componentes (vistas, restricciones,
disparadores, etc.) son definiciones que alguien ha proporcionado al SGBD mediante el lenguaje
SQL. Estas definiciones, como explicamos más adelante, se guardan en unas tablas diseñadas
especialmente para contenerlas, pero que a todos los efectos que aquí nos interesan son tablas
como las que contienen los otros datos. Así pues, una vez en el nivel físico, todo lo que hemos
visto hasta ahora es válido para las tablas que contienen estos componentes.

Los índices son un caso ligeramente distinto, y también lo son las tablas con datos del tipo
objeto grande. La estructura del bloque que utilizan es similar, pero varía su contenido.

Reflexión
Queda fuera del alcance de este módulo el estudio en profundidad de los diferentes tipos de páginas.

3.2.La extensión
Una extensión es un número entero de páginas, en principio consecutivas, que el sistema
operativo adquiere a petición del SGBD cuando éste detecta que necesita más espacio para
almacenar datos. Esta adquisición es automática (sin intervención humana explícita).

Es importante notar que cuando a petición del SGBD, el SO gestiona los datos en el soporte no
volátil de los periféricos, lo hace siempre dentro del marco de un fichero. Así, la adquisición de
una extensión también tiene lugar dentro de este marco. Esto significa que cuando se detecta
que falta espacio en un fichero, se adquiere una extensión para este fichero. La extensión está,
pues, asociada a un fichero, es parte de él. Y el fichero es, entre otras cosas, un conjunto de
extensiones.

Las páginas de una extensión deben ser físicamente consecutivas. Si el SO no las puede asignar
porque físicamente no están en el dispositivo, seguirá estrategias diferentes.

La razón de la contigüidad de las páginas de una extensión

La razón principal por la cual las páginas en una extensión deben ser contiguas es que, de este
modo, los componentes que son lógicamente consecutivos (por ejemplo, las filas de una tabla)
se pueden almacenar de manera consecutiva y se pueden recuperar del mismo modo, y así se
favorecen los tratamientos que impliquen la recuperación consecutiva de todos los componentes
(tratamientos que son frecuentes en las BD relacionales).

Por otro lado, los mecanismos más avanzados de mejora de rendimiento que encontraréis
esbozados en el subapartado que nos da una visión general de la E/S en un SGBD, tienen
sentido sólo si las páginas sobre las que actúan son consecutivas.

Algunas estrategias del SO

Algunas de las estrategias que utiliza el SO cuando no puede asignar páginas físicamente consecutivas

son, por ejemplo, partir la extensión en trozos o devolver un aviso que indique que no hay suficiente

espacio.

3.3.El fichero
El fichero es la unidad que usan los SO para gestionar el espacio en los dispositivos periféricos.
También es un conjunto de extensiones.

Los SGBD aprovechan la funcionalidad que proporcionan los SO y no interaccionan directamente

con los ficheros. Este es el motivo de que muchas veces cueste encontrar el término fichero de
manera explícita en libros o manuales de SGBD. Incluso hay SGBD relativamente pequeños en
los que todos los datos que controlan están almacenados en un único fichero, lo cual desvirtúa la
importancia de este componente.

De todos modos, los ficheros están siempre presentes en el almacenamiento: los distintos datos
de las BD están en las páginas; éstas se agrupan en extensiones, y estas últimas, en ficheros.
En resumen, podemos decir que el fichero es para el SGBD un conjunto de páginas que se han
ido creando de extensión en extensión.

Extensiones de un fichero

Normalmente, los SGBD permiten definir dos tipos de extensiones. Una se denomina extensión
primaria y la otra, extensión secundaria. Estas dos extensiones pueden ser –y normalmente
lo son– de longitud diferente, pero ambas son un múltiplo de la página.

Cuando un fichero necesita espacio por primera vez, se adquiere el número de páginas
correspondientes a la extensión primaria. A partir de este momento, las extensiones sucesivas
que se vayan necesitando en este fichero adquirirán el número de páginas de la extensión
secundaria. Para un fichero solo hay una extensión primaria (la primera), pero hay varias
secundarias (las siguientes). El número máximo de extensiones secundarias lo fija el sistema
operativo o el SGBD, y suele ser una potencia de dos (16, 128, 256, etc.).

3.4.Visión general de las E/S en un SGBD

Recordad que hemos definido la página como una unidad de almacenamiento y de transporte.
Dado que hasta ahora sólo hemos hablado de almacenamiento, para finalizar la exposición del
nivel físico trataremos el transporte.

El procesamiento de datos persistentes, que se efectúa en la memoria principal del ordenador,

como ya habéis visto, requiere un transporte de datos entre unidad central y periféricos. A
continuación, explicamos brevemente este transporte y el comportamiento de la entrada/salida
en el caso de los ficheros clásicos y en los SGBD.

1) Entrada/salida de ficheros clásicos

En el caso de la gestión de los denominados ficheros clásicos o ficheros tradicionales –puesto

que no pertenecen a una base de datos– este transporte es muy sencillo conceptualmente, tal y
como podéis ver en la figura 7.

Figura 7. E/S en los ficheros clásicos

Para leer datos, por ejemplo, el SO desencadena una operación de E/S para llevar hacia la
memoria principal el bloque que contiene los datos que se necesitan. Este bloque es una unidad
físicamente delimitada y direccionable en el conjunto de los datos grabados en el soporte no
volátil (el disco magnético). Después, el bloque viaja por el canal que une el periférico con la
unidad central del ordenador y, finalmente, el bloque se coloca en la memoria principal y puede
ser tratado por los programas.

2) Entrada/salida en las bases de datos

En el caso de los SGBD, este mecanismo, aunque básicamente es el mismo, es algo más
elaborado. Tiene unas características propias que muestra la figura 8 y que describimos a
continuación:

Figura 8. E/S en las bases de datos

a) La longitud de la página es fija. Normalmente, la página tiene la misma longitud en todos los
ficheros que constituyen las BD. Esto se contrapone al caso de los ficheros clásicos, en los que la
longitud del bloque suele ser diferente para cada uno, puesto que se elige la longitud que parece
más adecuada para los datos almacenados.

Entonces, y respecto a los SGBD, podemos plantearnos la pregunta siguiente: si los

componentes que encontramos en las páginas (como por ejemplo, las filas o las entradas de
índice) son, en principio, de longitud variable, ¿por qué los encapsulamos en un marco de
longitud fija (la página)? La respuesta es fácil: al basar el almacenamiento en una unidad fija
para todo el SGBD, la gestión que este tiene que hacer de la E/S puede ser mucho más sencilla,
lo que finalmente da lugar a un rendimiento mejor.

b) La optimización del tiempo de E/S, que permite ofrecer tiempos razonables de procesamiento
cuando se tratan cantidades importantes de datos, es otra característica de los SGBD. Los
diferentes SGBD han elaborado distintos mecanismos, algunos bastante sofisticados.
Mencionamos brevemente algunos:

 Aprovechar la operación física de E/S para leer y llevar a la memoria más de una página
consecutiva a la vez, lo cual ahorra tiempo de transporte por unidad leída (página).

 Avanzar en el tiempo la lectura de una página cuando se prevé que se necesitará

próximamente. Así, en el momento en que un proceso la necesite, no tendrá que
esperar el tiempo de lectura, puesto que la página ya estará en la memoria.

 Retener en la memoria principal páginas modificadas, incluso después de ser escritas en

el soporte no volátil, con el fin de ahorrarse una nueva lectura si algún otro proceso
las necesita.

Recordad

Cuando hemos definido la página habéis visto que, a pesar de que normalmente es la unidad de E/S,

muchas veces, por razones de rendimiento, el SGBD puede leer o escribir un número entero de

páginas de una vez.

c) Las técnicas de transmisión simultánea de varias páginas en una sola operación de E/S
implican la necesidad de dedicar una parte de la memoria principal del ordenador a recibir,
gestionar y almacenar páginas de las BD. Esta memoria, gestionada por las rutinas adecuadas
del SGBD, se denomina memoria intermedia (13) y está estructurada como un conjunto
de unidades de memoria intermedia (14) .

Cada unidad de memoria intermedia es un trozo de memoria que actúa como marco para
contener una página. El conjunto de todas estas unidades puede ser bastante grande, y
dimensionarlas correctamente es uno de los principales factores de refinamiento del rendimiento
de una instalación con SGBD.
Finalmente, para ilustrar las funciones propias de el SGBD y las del sistema operativo a la
entrada/salida, pasamos a comentar la figura 9.

Figura 9. Funcionamiento del SO y del SGBD a la entrada/salida de una página

Observamos que el SGBD se sirve del SO para ciertas funciones. Cuando el SGBD detecta la
necesidad de tratar una página que no tiene en la memoria intermedia, hace una petición a las
rutinas de gestión de E/S del sistema operativo para obtenerla. Estas rutinas son las que
gestionan la lectura física de la página y la sitúan en una unidad libre del conjunto de las
unidades de memoria intermedia. A continuación, el SGBD trata la página, puesto que es quien
conoce su organización y sus contenidos.

En inglés, buffer pool.
(13) 

En inglés, buffers.
(14) 

4.El nivel virtual

Para empezar, justificaremos la existencia del nivel virtual y después veremos la estructura del
espacio virtual, que es el componente que materializa las funciones del nivel virtual.

4.1.Justificación de la existencia del nivel virtual

En una primera aproximación podríamos pensar que cada tabla se almacena en un fichero, es
decir, que hay una relación biunívoca entre tabla y fichero, con lo cual desaparecería la
necesidad de un nivel intermedio que haga corresponder componentes lógicos con componentes
físicos, puesto que la correspondencia sería fija.

La realidad, sin embargo, es más compleja que la suposición anterior. A continuación,

presentamos algunos casos:

a) Hay tablas muy grandes que nos interesará fragmentar y almacenar cada fragmento en un
dispositivo diferente con el fin de mejorar el acceso a los mismos.

b) Por el contrario, podemos encontrar un conjunto de tablas muy pequeñas y que convenga
guardarlas todas en un mismo fichero para no consumir tantos recursos del sistema.

c) Cada vez más se usan tablas que, además de campos con datos de tipo tradicional
(cantidades numéricas, cadenas de caracteres que representan nombres y direcciones, fechas,
etc.), tienen otros que almacenan tipos de datos diferentes, como por ejemplo gráficos,
imágenes o algunos minutos de audio o de vídeo. Estos datos, que necesitan muchos más bytes
para ser almacenados, son los objetos grandes y que interesa almacenar en ficheros diferentes
de los que se emplean para los datos tradicionales, para mejorar los tiempos de acceso.

d) A pesar de que hasta ahora sólo hemos mencionado las tablas, todos sabéis que hay otros
componentes, como por ejemplo índices, definiciones de disparadores, etc. Al igual que en el
punto anterior, seguramente interesará almacenar cada componente en ficheros estructurados
de manera distinta, para obtener el máximo rendimiento de ellos.
Todos estos ejemplos tienen que advertirnos de que resulta bastante útil disponer de un nivel
intermedio. Nos proporciona un grado elevado de flexibilidad (o independencia) para asignar
componentes lógicos a los componentes físicos, puesto que no hay que hacerlo de una manera
estrictamente biunívoca (una tabla, un fichero). Concretamente, nos permite decidir dónde se
almacenará cada tabla o fragmento. De este modo, elegimos en qué máquina, disco o trozo de
disco tendremos los diferentes datos de la base de datos.

Recursos limitados

El interés por no querer consumir más recursos de los imprescindibles reside en el hecho de que hay

algunos SGBD que soportan sólo un número determinado de ficheros.

4.2.El espacio virtual y sus asociaciones

Hemos visto que la función del nivel virtual es proporcionar un grado elevado de independencia
entre los niveles lógico y físico. Denominamos espacio virtual(EV (15) ) al componente que
implementa esta funcionalidad.

Los diferentes SGBD comerciales otorgan distintos nombres a este componente, entre los cuales
los más empleados son dbspace y tablespace. También cabe decir que la funcionalidad que
veremos implementada para el espacio virtual es una simplificación de la realidad de muchos
SGBD comerciales, los cuales utilizan una estructura algo más compleja en este nivel virtual.
Aun así, la idea del nivel virtual es simple y se puede explicar correctamente a partir de un único
componente, el espacio virtual, que describimos a continuación.

Normalmente, en todos los SGBD una tabla se asocia a un único EV. Por el contrario, un EV
puede estar asociado a una o más tablas. Por otro lado, la asociación entre EV y fichero suele
ser de muchos a muchos: un EV se asocia a uno o más ficheros y un fichero se corresponde uno
o más EV.

La asociación entre tabla y EV se hace en tiempo de definición de la tabla. Junto con otros
atributos, se indica con qué EV la asociamos. El espacio virtual también se debe definir y, al
definirlo, se mencionan el fichero o los ficheros con los cuales lo asociamos.

Figura 10. Ejemplo del nivel virtual

Ejemplo del nivel virtual

La figura 10 muestra una base de datos de ciudadanos (Citizens). En este ejemplo podemos ver
la asociación entre el nivel lógico (con dos tablas: Persons y Cities) y el nivel físico (con tres
ficheros: Persons1, Persons2 y Cities1) por medio de dos espacios virtuales
(EV_Persons y EV_Cities).

A continuación, se muestran las sentencias necesarias para la creación de estas asociaciones en

el SGBD Oracle:
 1. CREATE TABLE Person (idPerson integer, name varchar2(30), ...)
2. TABLESPACE EV_Persons;
3.  
4. CREATE TABLESPACE EV_Persons DATAFILE '/db/filas/Persons1.dbf' SIZE
5. 100M;

La sentencia CREATE TABLE permite crear una tabla en un EV determinado, haciendo uso de la

cláusula TABLESPACE. La segunda sentencia, CREATE TABLESPACE, permite crear un EV y
asignarle un fichero.

Espacio virtual de agrupación

El espacio virtual de agrupación es un tipo de espacio virtual al que se asocian dos o más tablas y que

se corresponde con un único fichero. Este tipo de espacio virtual permite tener los datos de tablas

relacionadas en un mismo fichero, así como tener la combinación (operación de JOIN) preconstruida

en el disco. Este tipo de espacio virtual tiene sentido si el acceso a las tablas se hace siempre

conjunto, puesto que penaliza las consultas a las tablas individuales.

4.3.Estructura del espacio virtual

El EV es una visión diferente de las páginas del nivel físico. Al igual que una vista en el modelo
relacional es otra manera de ver los datos de una tabla sin que esto represente duplicar
físicamente los datos de la tabla, el espacio virtual es una manera distinta de organizar las
páginas que hemos visto en el nivel físico, pero sin duplicarlas materialmente.

Las únicas páginas que realmente existen son las del nivel físico, agrupadas en extensiones y
almacenadas en ficheros. Ahora bien, estas páginas no deben estar necesariamente ordenadas
en el soporte físico. Incluso páginas que contienen elementos que en el nivel lógico son
consecutivos (por ejemplo, las filas de una tabla) pueden estar separadas unas de otras en el
nivel físico (por ejemplo, ocupando extensiones diferentes); en algunos casos, el resultado de la
combinación de varias tablas se puede almacenar en un espacio virtual, si conviene tenerlo
precalculado.

Estructura de un espacio virtual

La estructura de un espacio virtual es similar a la de otros mecanismos que ya conocéis, como por

ejemplo:

a) La correspondencia que hay en un ordenador entre memoria virtual y memoria real.

b) Las vistas del modelo relacional. Los datos de una vista son los que realmente existen en una o

más tablas, pero dispuestos de otro modo, sin que esto represente una duplicación de estos datos.

Como veremos enseguida, es conveniente que las páginas estén ordenadas ocupando posiciones
consecutivas. Dado que esto físicamente no siempre es posible, los SGBD implementan una
ficción, que es lo que denominan espacio virtual.

El espacio virtual está constituido por las imágenes de las páginas reales (imágenes que
denominaremos páginas virtuales) ordenadas secuencialmente y situadas de manera contingua
(sin saltos en medio).
Así pues, podemos definir el espacio virtual como una secuencia de páginas virtuales que se
corresponden una por una con páginas reales del nivel físico.

Podemos ilustrar la estructura del espacio virtual mediante la figura 11.

Figura 11. Correspondencia entre páginas reales y páginas virtuales

Observad que las distintas páginas que contienen, por ejemplo, las filas de una tabla, están
distribuidas entre extensiones diferentes de ficheros distintos. El EV es una ficción para ver y
tratar todas estas páginas como si estuvieran ordenadas de manera consecutiva.

En la figura 12 representamos con más detalle y mediante un ejemplo la relación que hay entre
los tres niveles de la arquitectura que hemos visto hasta ahora.

En el nivel lógico, tenemos la tabla Student con sus filas. Esta tabla se almacena en páginas de
datos en el nivel físico. Por la manera como se ha ido creando la tabla y por la disponibilidad de
espacio libre en el disco, puede haber sucedido que no todas las filas de la tabla hayan quedado
en páginas consecutivas. Observamos que las páginas que contienen estas filas pertenecen a
dos extensiones diferentes, separadas por otra extensión que puede ser de otro fichero y,
evidentemente, puede contener otros datos.

Figura 12. Un ejemplo de los tres niveles

No podemos asegurar la contigüidad de las filas del nivel lógico en las páginas del nivel físico.
Entonces, el EV nos permite ver todas las páginas que contienen las filas de esta tabla de
manera consecutiva y sin saltos.

4.3.1.Direccionamiento en un SGBD
Ahora estamos en condiciones de analizar cómo es el direccionamiento en un SGBD.

En el nivel lógico, el usuario manipula tablas, filas y campos. Estos componentes están
almacenados en ficheros. ¿Cómo encuentra el SGBD uno de estos componentes en el nivel
físico? ¿Cómo lo direcciona? Responderemos a esta pregunta en dos pasos, puesto que en
realidad hay un direccionamiento doble, que se corresponde con la arquitectura que hemos
estado viendo y que se ilustra en la figura 13.

Figura 13. Un direccionamiento doble

1) Primer paso: del nivel lógico al virtual

Puesto que la unidad más pequeña que dirige de manera explícita un SGBD es la fila, lo que
hace realmente el SGBD es encontrar las filas dentro del espacio virtual. El direccionamiento del
SGBD es, pues, del nivel lógico al nivel virtual.

Tratamiento de los campos

Una vez la fila está en la memoria, el SGBD, dado que conoce su estructura, puede localizar todos sus

campos y tratarlos individualmente.

Para localizar las filas en el EV, los SGBD utilizan una dirección que
denominaremos identificador de fila (RID). El RID, como podemos ver en la figura 14, tiene
dos partes diferenciadas:

 el número de la página que contiene la fila dentro del espacio virtual asociado a la tabla
a la cual pertenece la fila,

 el número de elemento del VDF de esta página que apunta a la fila.

Tal como indicamos en la figura 14, el RID normalmente es una dirección de 4 bytes, 3 para el
número de página y 1 para el número de elemento del VDF.

Figura 14. Estructura del RID

Este sistema de direccionamiento merece algunos comentarios:

a) Una fila, una vez dada de alta en una página, no puede cambiar de página mientras esté
viva, puesto que su dirección también cambiaría. Dado que esta dirección puede estar guardada
en más de un lugar de la base de datos, interesa no hacer este cambio para evitar el
mantenimiento inútil y costoso de otras estructuras de datos (por ejemplo, en los índices que se
hayan construido sobre esta tabla).

b) En cambio, una fila se puede desplazar dentro de su página original. Cambiando solo el
contenido del elemento de VDF correspondiente (que indica el desplazamiento dentro de la
página donde empieza la fila), tendremos siempre la fila correctamente direccionada, y esto sin
ningún cambio en su RID. Por esto, es posible una gestión del espacio libre de una página sin
cambios en los RID de las filas de esta página. La gestión de espacio libre, como ya habéis visto,
tiende a agrupar todo el espacio libre de una página y, para ello debe desplazar filas dentro de la
página.

c) Por el mismo motivo que mencionábamos en el punto a, si una fila aumenta su longitud de
manera que no cabe en su página original y se tiene que colocar en otra página, ya hemos visto
que en la página original se mantiene una dirección, que es un RID, el cual desde la página
original apunta a la nueva página. Así pues, los RID almacenados en otras estructuras, como los
índices que apuntaban a la fila, la continúan encontrando sin que se hayan tenido que modificar.

Ahora ya habréis podido comprender que las direcciones o apuntadores que hemos mencionado
en puntos anteriores de este módulo son en realidad RID. Es el caso de las filas demasiado
largas que no cabían en una página (que se han partido en trozos y cada trozo apunta al
siguiente) o bien el de las filas que crecen de longitud (que se tienen que trasladar a otra página
y se les apunta desde la página original).

2) Segundo paso: del nivel virtual al físico

En este paso, normalmente intervienen los SO y no lo veremos en detalle. Destacaremos

solamente que la unidad de localización en el nivel físico es la página.

De este modo, el SGBD pide al SO que le lea/guarde una página concreta y este lo hace
empleando una dirección muy diferente del RID. Por lo tanto, en este paso hay una
transformación de direcciones: del RID a una dirección física que depende de la arquitectura del
dispositivo.

Antes de acabar el tema del direccionamiento, podemos reflexionar sobre la utilidad del
direccionamiento propio de los SGBD, el RID.

Al prescindir de muchos de los detalles del nivel físico, un direccionamiento como el RID permite
que el SGBD pueda emplear más de un tipo diferente de dispositivos de almacenamiento, puesto
que las diferencias son gestionadas en otro nivel y por otro componente (normalmente, el
sistema operativo). Este mecanismo simplifica los SGBD y aumenta su potencia, puesto que les
proporciona la independencia de los dispositivos físicos concretos.

Y finalmente, no debemos olvidar que el nivel virtual es el que posibilita, por medio del EV, el
direccionamiento de tipo RID.

El identificador de fila (RID)

RID es un acrónimo del término inglés row identifier. Este identificador recibe diferentes nombres

según las implementaciones de cada SGBD. Por ejemplo, en el caso de Oracle recibe el nombre

de ROWID.

5.Transformación del modelo lógico en el modelo físico

A partir del diseño lógico de una base de datos debemos llegar a su diseño físico, pasando por el
nivel virtual. La forma de implementar un diseño lógico en un SGBD concreto depende de las
características propias de cada uno de los SGBD. Y las características propias de cada SGBD son
un reflejo del entorno:

 Características del hardware.

 Sistema operativo y software básico.

 Diseño del SGBD.

Cada SGBD ha desarrollado un lenguaje propio, hecho a medida por el propio constructor, para
implementar el diseño físico de la base de datos, de acuerdo con las características del entorno y
para obtener el máximo rendimiento del hardware, del sistema operativo y del propio gestor. De
hecho, se podría considerar como una ampliación del lenguaje SQL estándar, con las cláusulas
propias que cada gestor necesita para definir los componentes del diseño físico. Sin embargo,
hay una gran similitud o equivalencia entre buena parte de los componentes de los diferentes
gestores.

El estándar SQL incorpora la definición de todos los componentes del diseño lógico de la base de
datos. En cambio, no incorpora ningún elemento del diseño físico.

En la transformación del modelo lógico en el modelo físico, seguiremos los pasos siguientes:

1) Transformar las tablas con las correspondientes claves primarias, claves foráneas y claves
alternativas, a partir del diseño lógico de la base de datos que hemos obtenido en el paso
anterior.

2) A continuación relacionamos cada tabla con un espacio para tablas, y cada índice con un
espacio para índice. Es el nivel virtual.

3) Para terminar, relacionamos cada espacio virtual con un fichero físico y definimos sus
características. Esto constituye el diseño físico de la base de datos.

De manera adicional es preciso completar esta definición con los índices necesarios para
garantizar un acceso correcto a los datos, además de las restricciones necesarias sobre los datos
(valores nulos, valores únicos de los campos, etc.).

A continuación, veremos el proceso de transformación. Como ejemplo de SGBD para la parte

que no queda incluida en el estándar SQL, se utiliza el sistema gestor Oracle. Aun así, gran parte
de la sintaxis es similar a la que se utiliza en otros SGBD y basta consultar un manual de
referencia para ver cómo se aplican las diferentes instrucciones en cada SGBD.

5.1.Tabla
La tabla es un componente del diseño lógico de la base de datos y, como tal, está definida en el
estándar SQL. Ahora bien, es importante remarcar que la parte que afecta al nivel virtual y físico
no está incluida en el estándar y, por lo tanto, cada SGBD implementa estas funciones de
manera diferente.

La sentencia CREATE TABLE de todos los SGBD incorpora las cláusulas del estándar SQL y,
además, el enlace con los elementos físicos propios de cada uno.
 1. CREATE TABLE table_name
2. ( column_definition )
3. <unique_constraint>
4. <referential_constraint>
5. <check_constraint>
6. <extent_specs>
7. TABLESPACE table_space_name

Las cláusulas siguientes de la sentencia CREATE TABLE pertenecen al SQL

estándar: column_definition, unique_constraint, referential_constraint, check_constraint. Estas
cláusulas son definiciones del diseño lógico. Todos los SGBD las incorporan con una sintaxis casi
idéntica.

Por otro lado, las cláusulas <extent_specs> y TABLESPACE son específicas de Oracle. Sirven

para relacionar la definición de la tabla (nivel lógico) con el espacio para tablas (nivel virtual),
que se denomina Tablespace en Oracle. Además, la cláusula <extent_specs> puede incorporar
otros parámetros que permiten controlar el porcentaje de ocupación de las páginas del espacio
para tablas.

Ejemplo de creación de una tabla en Oracle

A continuación, veremos un ejemplo de creación de una tabla en el SGBD Oracle:

1. CREATE TABLE Employees (

2. employeeId NUMBER(6) PRIMARY KEY
3. , firstName VARCHAR2(20)
4. , lastName VARCHAR2(25)
5. , email VARCHAR2(25) NOT NULL
6. , phoneNumber VARCHAR2(20)
7. , salary NUMBER(8,2) NOT NULL
8. , commissionPct NUMBER(2,2)
9. , departmentId NUMBER(4)
10. , CONSTRAINT empSalaryMinDemo CHECK (salary > 0)
11. , CONSTRAINT empEmailUKDemo UNIQUE (email)
12. ) TABLESPACE users_fecha;

En el ejemplo, se crea la tabla Employees con diferentes atributos y algunas restricciones.

Algunas consideraciones sobre el ejemplo:
 La clave primaria de la tabla es el atributo employeeId.

 Dos de los atributos no admiten el valor nulo (email y salary).

 Las restricciones que encontramos son:

o CHECK: diferentes validaciones, como por ejemplo que el campo sea

superior a cero o que cumpla determinadas condiciones.
 o UNIQUE: unicidad del campo indicado, es decir, que no puede haber dos
registros en esta tabla con el mismo valor en este campo.

A continuación, veremos con más detalle las definiciones relativas a clave primaria y clave
alternativa, índice y algunas de las restricciones más relevantes.

5.1.1.Clave primaria y clave alternativa

Las definiciones de claves primarias, foráneas y alternativas actualmente forman parte del
estándar SQL. No obstante, no siempre ha sido así; en el año 1986 todavía no se habían definido
y el estándar SQL86 no las incluyó cuando se publicó. En el estándar SQL89 se mencionan las
claves primarias por primera vez, y no fue hasta 1992 cuando de hecho se definieron y se
incorporaron al estándar SQL92.

Como ya sabemos, la clave primaria tiene que ser obligatoriamente una clave única y que no
admita valores nulos. La teoría del modelo de bases de datos relacionales sugiere que cada tabla
debería tener una clave primaria que identificara de manera unívoca la entidad que describe. A
pesar de esto, el estándar SQL no obliga a la existencia de una clave primaria en cada tabla,
sino que es opcional. Lógicamente, sin embargo, cada tabla puede tener como máximo una
clave primaria.

El resto de las claves únicas y que no admiten valores nulos son claves alternativas a la clave
primaria. Esto tampoco está legislado en el estándar SQL.

Tal como muestra el ejemplo anterior, se indica la clave primaria mediante la

instrucción PRIMARY KEY.

5.1.2.Índice
Los índices son unos elementos del diseño físico de la base de datos que tienen como finalidad
mejorar el rendimiento de las aplicaciones cuando acceden a las tablas. Los índices no forman
parte del diseño lógico de la base de datos y, por lo tanto, no están incluidos en el estándar SQL.

Aun así, la sentencia CREATE INDEX está presente en todos los SGBD con opciones muy
similares. A continuación, veremos el detalle de esta sentencia sobre el SGBD Oracle. Además,
incorpora cláusulas para definir el espacio para índices y cláusulas de enlace con los elementos
físicos propios (los ficheros de índices).

1. CREATE [UNIQUE] INDEX index_name

2. ON table_name ( column [ ASC | DESC ] [ ,..n ])
3. [ CLUSTER cluster_name ]
4. [ < extent_specs > ]
5. [ TABLESPACE table_space_name ]
6. [ ...... ]
7.  
8. < extent_specs > ::=
9. [ PCTFREE nn ]
10. [ PCTUSED nn ]
11. [ INITRANSnn ]
12. [ MAXTRANSnn ]
13. [ STORAGE < storage_clause > ]
14.
15. < storage_clause > ::=
 16. INITIAL nn
17. [ NEXT nn ]
18. [ MAXEXTENTS nn ]
19. [ PCTINCREASE nn ]
20. [ OPTIMAL nn ]
21. [ ..... ]

Donde:

 index_name es el nombre lógico del índice definido sobre la tabla especificada en la

cláusula ON.

 UNIQUE y CLUSTER son características del índice.

 table_space_name es el nombre del espacio para índice y se define con la

sentencia CREATE TABLESPACE, que hemos visto anteriormente.

 Cuando se crea el espacio para índice (CREATE TABLESPACE), se asocia a un fichero

físico con características propias de nombre, tamaño, ubicación física en disco, etc.

 La cláusula <extent_specs> especifica condiciones de porcentaje de ocupación de las

páginas del espacio para índice.

 La cláusula <storage_clause> define características de almacenamiento, tamaño inicial,

tamaño incremental, extensiones mínimas y máximas, etc.

Ejemplo de creación de un índice

El ejemplo siguiente muestra cómo se crea un índice mediante la instrucción CREATE INDEX de

Oracle:

1. CREATE INDEX indexDepName

2. ON Employees (departmentId) TABLESPACE users_ind;

5.1.3.Restricciones
A continuación, veremos algunas de las principales restricciones que podemos definir sobre los
atributos de las tablas y cómo se implementan en el SGBD de Oracle.

Estas restricciones nos permiten definir una lógica que nos ayude a validar los datos de nuestro
modelo, de manera que cumplan determinadas condiciones.

Algunos ejemplos típicos que podemos resolver mediante estas restricciones son:

 Verificar que un número sea superior a cero.

 Verificar que un atributo contenga una cadena de texto de un tamaño determinado.

 Verificar que no haya valores duplicados para un cierto atributo.

a) Check
Esta restricción permite indicar ciertas condiciones que el valor del registro debe cumplir para
ser admitido en la tabla.

Por ejemplo, podemos definir una tabla con información sobre trabajadores, que contenga como
atributos el nombre y el sueldo. Evidentemente, el sueldo debe ser positivo. Para indicarlo, en la
creación de la tabla utilizamos la restricción CHECK.

1. CREATE TABLE Employees

2. ( name varchar2(30),
3. salary number CHECK (salary > 0)
4. ) TABLESPACE data_employees;

b) Not null

Esta restricción permite definir atributos que deben contener información obligatoriamente, es
decir, que deben contener datos. Indicamos esta restricción en el SGBD por medio del
parámetro NOT NULL.

1. CREATE TABLE Employees

2. ( name varchar2(30) NOT NULL,
3. salary number
4. ) TABLESPACE data_employees;

c) Unique

Esta restricción posibilita validar que no existen valores duplicados en un determinado atributo.
Permite definir las claves candidatas.

Continuando con el ejemplo anterior, esta restricción nos permite definir que cada trabajador
debe tener un identificador único (por ejemplo, el DNI en el caso de España), el cual debe ser
único para cada persona.

1. CREATE TABLE Employees

2. ( id varchar2(9) UNIQUE,
3. name varchar2(30) NOT NULL,
4. salary number
5. ) TABLESPACE data_employees;

d) Foreign key / References

Esta restricción permite crear claves foráneas que referencian atributos de otras tablas.

Por ejemplo, si queremos crear una tabla que contenga los departamentos de la empresa
(Department) e indicar a qué departamento pertenece cada trabajador (Employees), será
preciso crear la nueva tabla y añadir un atributo que referencie la nueva tabla para cada registro
de la tabla Employees.

1. CREATE TABLE Department

 2. ( id number(6) PRIMARY KEY
3. name varchar2(50)
4. ) TABLESPACE data_departments;
5.  
6. CREATE TABLE Employees
7. ( id varchar2(9) UNIQUE,
8. name varchar2(30) NOT NULL,
9. salary number,
10. departId number(6),
11. CONSTRAINT fkDep FOREIGN KEY (departId) REFERENCES Department (id)
12. ) TABLESPACE data_employees;

5.2.Espacio para tablas

El espacio para tablas es un componente del nivel virtual. No pertenece al diseño lógico de la
base de datos y, por lo tanto, no está incluido en el estándar SQL. La sentencia de creación de
un espacio para tablas es diferente en cada SGBD e incorpora las cláusulas de enlace con los
elementos físicos propios de cada uno de estos SGBD (los ficheros).

El nivel virtual recibe en Oracle el nombre de tablespace. La sentencia CREATE

TABLESPACE permite crear espacios virtuales en este SGBD.

1. CREATE TABLESPACE table_space_name

2. DATAFILE < filespec > [ ,...n ]
3. DEFAULT STORAGE < storage_clause >
4.
5. < filespec > ::=
6. 'file_name'
7. [ SIZE nn ]
8. < storage_clause > ::=
9. INITIAL nn
10. [ NEXT nn ]
11. [ MINEXTENTS nn ]
12. [ MAXEXTENTS nn ]
13. [ PCTINCREASE nn ]
14. [ OPTIMAL nn ]
15. [ ..... ]

Donde:

 table_space_name es el nombre del espacio para tablas, que se define con esta
sentencia y que está relacionada con la cláusula TABLESPACE de la sentencia CREATE
TABLE.

 Cada espacio para tablas se asocia a uno o más ficheros físicos <filespec>.
  La definición del fichero físico viene dada por su nombre externo file_name, su ubicación
en disco y su tamaño, size.

 La cláusula <storage_clause> define sus características de almacenamiento, tamaño

inicial, tamaño incremental, extensiones mínimas y máximas, etc.

Ejemplo de creación de un espacio para tablas

En el ejemplo siguiente crearemos un espacio para tablas con el nombre users_data formado por

el fichero ‘/db/users/users_data1.dbf’ y con un tamaño total de 100 MB.

1. CREATE TABLESPACE users_data

2. DATAFILE '/db/users/users_data1.dbf' SIZE 100M;

Algunos parámetros son opcionales y no es necesario que sean informados en la sentencia de

creación. En estos casos, se asigna el valor por defecto del parámetro. En el ejemplo anterior el
tamaño de la página no se especifica y, por lo tanto, se utilizará el valor por defecto.

5.3.Base de datos
Como en el caso del espacio para tablas, la base de datos no pertenece al diseño lógico de la
base de datos y, por lo tanto, tampoco está incluida en el estándar SQL.

La sentencia CREATE DATABASE es diferente en cada SGBD e incorpora cláusulas de definición

de elementos físicos propios de cada uno (diario, catálogo, ficheros, etc.).

En Oracle, la sintaxis de esta sentencia es como se indica a continuación:

1. CREATE DATABASE database_name

2. [ CONTROLFILE REUSE ]
3. [ LOGFILE < filespec > [ ,...n ] ]
4. [ MAXLOGFILES nn ]
5. [ MAXLOGMEMBERS nn ]
6. [ MAXLOGHISTORY nn ]
7. [ DATAFILE < filespec > [ ,...n ] ]
8. [ MAXDATAFILES nn ]
9. [ MAXINSTANCES nn ]
10. [ CHARACTER SET charset ]
11. [ ...... ]

Donde:

 database_name es el nombre de la base de datos que se asocia a un conjunto de

ficheros físicos que contienen los espacios para tablas explicados en el subapartado
anterior.

 Los ficheros físicos que contienen los espacios para tablas se relacionan en la
cláusula DATAFILE < filespec >.
  La cláusula LOGFILE <filespec> especifica el nombre de los diarios que se definen para
que el gestor registre todas las actualizaciones de las tablas de esta base de datos y
posibilitar, así, su recuperación en caso necesario.

 El detalle de la definición de los ficheros físicos <filespec> se ha explicado en el

subapartado de los espacios para tablas.

 Otros parámetros limitan el número máximo de ficheros de cada

tipo: MAXLOGFILES, MAXLOGMEMBERS, MAXDATAFILES, etc.

Ejemplo de creación de bases de datos

En el siguiente ejemplo crearemos una base de datos para una universidad, con unos diarios
(logfiles) de 10 MB cada uno y con unos límites de 5 logfiles y 100 datafiles.

1. CREATE DATABASE university

2. USER SYS IDENTIFIED BY pass1
3. USER SYSTEM IDENTIFIED BY pass2
4. LOGFILE GROUP 1 ('/db/oracle/oradata/university/redo01.log')
5. SIZE 10M,
6. GROUP 2 ('/db/oracle/oradata/university/redo02.log') SIZE 10M,
7. GROUP 3 ('/db/oracle/oradata/university/redo03.log') SIZE 10M
8. MAXLOGFILES 5
9. MAXDATAFILES 100;

6.Implementación de métodos de acceso

En una base de datos hay datos almacenados a los que se debe acceder para hacer consultas y
actualizaciones. Por este motivo, una de las funciones de los SGBD es la de proporcionar el
acceso a los datos que gestionan. La problemática de cómo ofrecer este acceso es el objeto de
estudio de este apartado.

Inicialmente, veremos de manera breve los diferentes métodos de acceso a los datos. A
continuación, profundizaremos en el estudio de los métodos de acceso por posición, por valor y
por varios valores. Finalmente, veremos cómo implementa estas funciones el SGBD Oracle.

6.1.Los métodos de acceso a una BD

Una de las funciones de los SGBD es proporcionar el acceso a los datos que gestionan. El acceso
a los datos debe permitir consultar y actualizar los datos almacenados. Siempre que se lee o se
graba algún dato en una BD se hace mediante alguno de los métodos de acceso de los que
dispone el SGBD.

Reflexión

Debemos entender “actualizaciones de datos” en sentido amplio; es decir, su inserción, eliminación y

modificación.

6.1.1.Los datos
En este subapartado, para presentar los métodos de acceso a los datos de manera
comprensible, supondremos siempre que los datos a los que hay que acceder se perciben según
la visión que proporciona el nivel virtual, y no según la del nivel físico. Así pues, casi siempre
que en este módulo se emplea la palabra página tenemos que interpretar que nos referimos a
páginas virtuales; si nos referimos a páginas reales, lo mencionaremos de manera explícita.

Con objeto de simplificar, también supondremos que todos los accesos se hacen a datos
almacenados en una sola tabla, situada en un único EV. Así pues, no consideramos los casos en
que es necesario combinar datos de tablas (y espacios) diferentes para obtener los datos a los
que queremos acceder.

6.1.2.Los accesos por posición

En este subapartado, veremos los tipos de acceso más simples que utilizan los SGBD.

El acceso directo por posición consiste en obtener una página que dispone de un número de

página determinado dentro de un espacio.

El acceso secuencial por posición consiste en obtener las páginas de un espacio siguiendo el

orden establecido por sus números de página.

La figura 15 muestra estos dos tipos de acceso por posición.

Figura 15. Los accesos por posición

Estos tipos de acceso simples son suficientes para casos en los que solo haya que efectuar
consultas y actualizaciones muy sencillas en la BD.

Ejemplo de acceso directo por posición

Supongamos que disponemos de una BD que contiene la tabla Employees(emplId, emplName,
officeNum, salary). Supongamos también que esta tabla se almacena en un espacio determinado
y que las filas de los empleados se sitúan en el espacio mencionado por orden de inserción.
Consideremos ahora la actualización siguiente, descrita en SQL:

1. INSERT INTO Employees

2. VALUES (25, 'Juan Tarrago', 150, 2000);

Esta actualización se puede efectuar fácilmente. El SGBD tiene grabado el número de la primera
página del espacio con capacidad de absorber nuevas filas. Entonces, se usa el acceso directo
por posición para insertar el empleado en la página mencionada (añadiendo la fila
correspondiente al empleado nuevo).

Ejemplo de acceso secuencial por posición

En la base de datos anterior podríamos realizar una consulta para recuperar los datos de todos
los empleados, como por ejemplo la siguiente:

1. SELECT * FROM Employees;

Para resolver esta consulta, el SGBD puede utilizar el acceso secuencial por posición, mediante
el cual el SGBD va obteniendo todas las páginas que contienen las filas de los empleados. De
este modo, puede proporcionar los empleados en el mismo orden en que los obtiene. Observad
que la consulta no requiere ninguna ordenación particular de los empleados y, entonces, el
SGBD los puede proporcionar en el mismo orden en el que están almacenados.

Accesos por posición

Los accesos por posición son viejos conocidos. El acceso secuencial y el acceso directo por posición se

utilizan también en la tecnología de los ficheros. En concreto, el fichero secuencial ofrece el acceso

secuencial por posición y el fichero relativo ofrece tanto el acceso directo por posición como el acceso

secuencial por posición.

6.1.3.Los accesos por valor

En este subapartado, explicamos algunos tipos de acceso más complejos que los accesos por
posición que acabamos de ver.

El acceso directo por valor consiste en obtener todas las filas que contienen un valor
determinado por un atributo.

El acceso secuencial por valor consiste en obtener varias filas por el orden de los valores de
un atributo.

Ejemplos de acceso directo por valor

Consideremos las sentencias de manipulación siguientes:

 Sentencia 1:

1. SELECT * FROM Employees WHERE officeNum = 150;

  Sentencia 2:

1. UPDATE Employees SET salary = 2500 WHERE officeNum = 200;

 Sentencia 3:

1. DELETE FROM Employees WHERE officeNum = 150;

Observad que en los tres ejemplos hay que buscar las filas de los empleados que tienen un
número de despacho (officeNum) determinado, para mostrarlos, modificarlos o borrarlos,
respectivamente. Es decir, en los tres casos hay que hacer búsquedas de un valor por un
atributo determinado.

De estos ejemplos, se deduce que el acceso directo por valor es necesario para ejecutar
consultas y actualizaciones sobre filas que contienen un determinado valor de un atributo.

Ejemplos de acceso secuencial por valor

Consideremos las sentencias de manipulación siguientes:

 Sentencia 1:

1. SELECT * FROM Employees ORDER BY officeNum;

 Sentencia 2:

1. SELECT * FROM Employees

2. WHERE officeNum >= 100 AND officeNum <= 300;

 Sentencia 3:

1. UPDATE Employees SET salary = 2500

2. WHERE officeNum >= 100 AND officeNum <= 300;

 Sentencia 4:

1. DELETE FROM Employees

2. WHERE officeNum >= 100 AND officeNum <= 300;

En todos estos ejemplos, es necesario conseguir algunas filas de la tabla de empleados en una
secuencia ordenada por el atributo officeNum.

En la primera de las sentencias hay que obtener los empleados ordenados por el número de
despacho, debido a la cláusula ORDER BY officeNum. Para ejecutar las tres sentencias restantes
también debe disponer del acceso secuencial por valor, aunque la causa es quizá menos
evidente. La cláusula WHERE officeNum >= 100 AND officeNum <= 300 implica que sea
necesario localizar todos los empleados que tienen un número de despacho entre el 100 y el 300
para consultar los datos, modificarlos o borrarlos, respectivamente. Una manera de localizar
todos los empleados es disponer de algún mecanismo de acceso a cada uno de ellos por orden
de número de despacho a partir del valor 100 y hasta el 300. Este mecanismo es el acceso
secuencial por valor.

De los ejemplos anteriores, se desprende que el acceso secuencial por valor se utiliza para
ejecutar consultas en las que el resultado debe estar ordenado por un atributo y para consultas
o actualizaciones que afecten a un conjunto de filas que contienen el valor de un atributo que se
encuentra dentro de un rango determinado de valores.

6.1.4.Los accesos por varios valores

Hemos considerado accesos por valor de un solo atributo. Nos falta considerar los casos en los
que se quiere acceder según los valores de varios atributos: los accesos por varios valores. Los
accesos por varios valores pueden ser, como los accesos por un solo valor, directos o
secuenciales.

Ejemplos de acceso por varios valores

Consideremos los ejemplos siguientes de acceso por varios valores:

 Sentencia 1:

1. SELECT *
2. FROM Employees
3. WHERE officeNum = 150 AND salary = 2000;

 Sentencia 2:

1. SELECT *
2. FROM Employees
3. ORDER BY officeNum, salary;

 Sentencia 3:

1. DELETE *
2. FROM Employees
3. WHERE officeNum >= 100 AND salary >= 1800;

En estos ejemplos, se accede a los datos según los valores de dos atributos: el
atributo officeNum y el atributo salary. La primera sentencia corresponde a un acceso directo por
varios valores y las dos siguientes, a un acceso secuencial por varios valores.

También puede ocurrir, sin embargo, que los accesos por varios valores sean mixtos.

Los accesos mixtos por varios valores son accesos en los que se combina el acceso directo por
valores de algunos atributos y el acceso secuencial por valores de otros atributos.
Ejemplos de accesos mixtos por varios valores

Consideremos las sentencias siguientes:

 Sentencia 1:

1. SELECT *
2. FROM Employees
3. WHERE officeNum = 150 AND salary >= 2000;

 Sentencia 2:

1. SELECT *
2. FROM Employees
3. WHERE salary = 2000
4. ORDER BY officeNum;

 Sentencia 3:

1. DELETE *
2. FROM Employees
3. WHERE officeNum >= 100 AND officeNum <= 300 AND salary = 2000;

La primera de las sentencias combina un acceso directo por valor del atributo officeNum con un
acceso secuencial por valor del atributo salary. Las dos siguientes combinan un acceso
secuencial por valor del atributo officeNum con un acceso directo por valor del atributo salary.

Los accesos por varios valores

Los accesos por varios valores no tienen su correspondiente en tecnología de los ficheros, a diferencia

de lo que sucedía con los otros accesos que hemos explicado.

6.2.Implementación de los accesos por posición

Para la implementación de los accesos por posición, los SGBD se basan casi completamente en
el SO. Las rutinas de gestión de E/S del SO permiten obtener una página real si tenemos su
dirección y también permiten grabar en el disco una página real concreta. Podríamos decir que el
SO implementa el acceso por posición en páginas reales.

De acuerdo con el punto de partida que acabamos de presentar, la implementación de los

accesos por posición es muy simple.

En el caso del acceso directo por posición, sólo es preciso que el SGBD transforme los
números de posición de las páginas virtuales en direcciones de páginas reales almacenadas al
disco.

Si el SGBD necesita realizar un acceso secuencial por posición, el mismo procedimiento que
hemos explicado para el acceso directo por posición sirve para ir accediendo a todas las páginas,
de la primera a la última.
6.3.Implementación de los accesos por valor
La implementación de los accesos por valor es más compleja que la de los accesos por posición.
La dificultad proviene del hecho de que si el SGBD se basara únicamente en el SO para
implementarlos, no siempre obtendría un buen rendimiento. Será necesario, por lo tanto, que el
SGBD disponga de mecanismos propios especializados que los implementen de manera eficiente.

En este apartado veremos que para implementar de una manera eficiente el acceso directo y el
acceso secuencial por valor, los SGBD usan unas estructuras de datos auxiliares que se
denominan índices. Para la implementación de los accesos por valor con índices, partiremos del
hecho de que ya disponemos de los accesos por posición que hemos explicado. Los SGBD
utilizan los accesos por posición para implementar los accesos por valor.

6.3.1.Necesidad de los índices

Empezaremos explicando por qué los índices son necesarios si se desea obtener un buen
rendimiento al realizar accesos por valor. Para ello, presentaremos algunas implementaciones
que no los utilizan y veremos los problemas que comportan.

Consideremos la sentencia siguiente, que requiere un acceso directo por valor del
atributo officeNum:

1. SELECT * FROM Employees WHERE officeNum = 150;

Hay que tener en cuenta que las filas de la tabla EMPLEADOS se encuentran en un espacio
virtual. Por lo tanto, ya que disponemos del acceso secuencial por posición a las páginas del
espacio virtual, el SGBD puede emplear este acceso para obtener todas las páginas una a una,
comprobando para cada una, qué filas contienen el valor buscado.

El inconveniente de la solución anterior es que requerirá un gran número de E/S, sobre todo si
hay muchos empleados en la BD. Habrá que consultar todas las páginas de la BD que tienen filas
de empleados para conseguir únicamente los empleados del despacho 150, que pueden ser muy
pocos.

Ahora analizamos otro ejemplo que requiere un acceso secuencial por valor; podéis observar la
sentencia siguiente:

1. SELECT * FROM Employees ORDER BY officeNum;

Para obtener los empleados por orden de número de despacho, convendría que estuvieran
almacenados según este mismo criterio. Entonces, utilizando el acceso secuencial por posición
que nos facilita el SO, se conseguirían los empleados en el orden deseado.

El problema de esta solución es que la ordenación de los empleados por número de despacho iría
muy bien para la consulta anterior, pero muy mal si también se quisiera ejecutar, por ejemplo,
la sentencia siguiente:

1. SELECT * FROM Employees ORDER BY emplId;

Puesto que en una BD tienen que convivir habitualmente consultas y actualizaciones que
requieren ordenaciones diferentes de unos mismos datos, la solución que hemos presentado no
es satisfactoria para todas las sentencias que será necesario ejecutar de manera eficiente.
Las soluciones que hemos analizado para implementar los accesos por valor no nos permiten
conseguir un rendimiento lo suficientemente aceptable en muchos casos. A continuación,
analizaremos la manera como los índices nos permitirán mejorar esta situación.

6.3.2.Características generales de los índices

Existen índices de muchos tipos diferentes, pero todos tienen algunas características generales
comunes como implementaciones adecuadas de los accesos por valor. Los índices de los SGBD
tienen una utilidad parecida a la de los índices que contienen los libros para localizar
rápidamente un apartado determinado.

El índice de un libro

Este módulo tiene un índice al principio. Si queremos localizar con rapidez el subapartado
dedicado a los árboles B+, lo que debemos hacer es consultar el índice. Allí encontraremos
fácilmente el número de página donde está situado el subapartado de los árboles B +, porque el
índice no es muy largo y no tardaremos en leerlo. Una vez conocido el número de página, solo
debemos localizar la página que lleva aquel número.

Los índices que emplean los SGBD son unas estructuras de datos auxiliares que, como los
índices de los libros, facilitan las búsquedas sobre unos determinados datos.

Uno de los motivos por los cuales las búsquedas pueden ser más rápidas si se realizan mediante
un índice en lugar de acceder directamente a los datos, es que los índices suelen ocupar menos
espacio que los datos.

Las filas que contienen los datos generalmente son voluminosas porque almacenan muchos
atributos. Los índices, en cambio, normalmente contienen sólo una colección de parejas,
denominadas entradas, formadas por un valor y un RID.

Espacio ocupado por los índices y por los datos

Las filas de una tabla de empleados podrían registrar el número de empleado, su nombre, DNI,
dirección, teléfono, sueldo, número de despacho, departamento donde está asignado, etc. En
cambio, si queremos tener un índice para acceder a los empleados según su número de
empleado, las entradas del índice tendrán que estar formadas sólo por un número de empleado
y un RID.

Una búsqueda mediante un índice consiste en localizar primero los valores en el índice para
conocer el RID. Una vez se dispone del RID, se emplea un acceso directo por posición para
conseguir la página que contiene la fila de los datos que buscábamos.

La figura 16 ilustra la consulta del empleado número 25 con un índice.

Figura 16. Consulta mediante un índice

De los párrafos anteriores, podemos deducir que los SGBD utilizan el acceso por posición para
implementar los accesos por valor.

Un índice tiene que estar organizado de alguna manera que facilite las búsquedas de los valores
que contiene. Hay varias maneras de organizar los índices: los árboles B +, las funciones de
dispersión, etc. Algunos de estos tipos de índice sólo facilitan el acceso directo por valor (por
ejemplo, las funciones de dispersión); otros sirven tanto para el acceso directo como para el
acceso secuencial por valor (por ejemplo, los árboles B+).

Una característica muy útil de la mayoría de los tipos de índice es que permiten la posibilidad de
tener varios índices sobre unos mismos datos.

Las peculiaridades de los índices sugieren que es mejor gestionarlos de manera separada de los
datos de las tablas. Por este motivo, hay un tipo de espacio virtual para contenerlos,
denominado espacio de índices.

Ejemplo

Sobre una tabla que contiene datos de empleados podemos tener un índice que facilite el acceso por

número de empleado, otro que facilite el acceso por nombre, otro que facilite el acceso por número de

despacho, etc.

Más adelante, estudiamos los tipos de índices que utilizan más a menudo los SGBD para
implementar los accesos por valor: los estructurados como árboles B + y los estructurados según
funciones de dispersión. Cada SGBD tiene sus particularidades propias en la implementación de
un tipo de índice determinado. Dado que sería impracticable intentar explicar exhaustivamente y
con todos los detalles las implementaciones que hay, solo estudiamos los principios comunes a
la mayoría de las implementaciones de índices estructurados como árboles B + y los de los índices
estructurados mediante funciones de dispersión. Estos principios nos facilitan la comprensión de
las implementaciones particulares que proporcionan los SGBD del mercado.

El cálculo del coste de ejecución de los accesos a los datos mediante la utilización de índices es
un aspecto que deberemos considerar de ahora en adelante para evaluar la bondad de los
diferentes tipos de índice. Para este cálculo, tomamos las convenciones siguientes:

Observación

Observad que los índices también se pueden usar para implementar los accesos que requieren los

ficheros por valor.

1) Consideramos sólo el coste de las E/S y no otros componentes del coste, como por ejemplo el
que corresponde a los cálculos de la UCP (16) . El motivo es que el coste de las E/S es
normalmente el componente dominante en el coste de las operaciones que se llevan a cabo en
las BD y nos proporciona una buena aproximación a los costes reales.

2) Para contabilizar el coste de las E/S adoptamos la simplificación de contar el número de

páginas que se leen o que se graban en el disco. Esta simplificación nos sirve porque suponemos
que todas las E/S transportan únicamente una página (es el caso más habitual) y que para
acceder a una página siempre hay que hacer una E/S, a pesar de que en algunos casos
concretos podría no ser necesario (por ejemplo, si ya se ha accedido a la página con anterioridad
y todavía se tiene una copia de la misma en la memoria interna).

UCP es la sigla del término unidad central de procesamiento.

(16) 

6.3.3.Árboles B+
En los subapartados siguientes, presentamos un tipo de índice que sirve para facilitar el acceso
directo y el secuencial por valor de un atributo: los árboles B +.
Los árboles B+ son un tipo particular de árbol de búsqueda. El objetivo primordial de la
estructura de los árboles B+ es el de conseguir que las búsquedas se efectúen con un número
pequeño de E/S.

Es importante tener en cuenta que, a diferencia otros tipos de árboles, los árboles B + que
estudiamos aquí están orientados a realizar búsquedas en el disco.

El estudio de los árboles B+ es muy interesante porque la mayoría de los sistemas comerciales
(como por ejemplo Oracle, PostgreSQL, Informix, DB2, etc.) los implementan.

Terminología de las estructuras de datos de árbol

Empezamos presentando brevemente la terminología que se emplea al hablar de las estructuras
de datos en forma de árbol.

Un árbol se compone de nodos. Cada nodo del árbol, excepto un nodo especial

denominado raíz, tiene un nodo padre y varios (cero o más) nodos hijos. El nodo raíz no tiene
padre. Los nodos que no tienen hijos se denominan nodos hoja y los nodos que no son hojas se
denominan nodos internos. El nivel de un nodo es siempre el nivel de su padre más uno, y el
nivel del nodo raíz es uno. Un subárbol de un nodo consiste en el nodo y todos sus nodos
descendentes: sus nodos hijos, los nodos hijos de sus hijos, etc.

La figura 17 ilustra la estructura de datos de árbol que acabamos de presentar.

Figura 17. Estructura de un árbol

Ejemplo

En la figura 17 podemos ver los siguientes elementos del árbol:

 El nodo raíz de la figura es A.

 Los nodos hijos de A son B, C, D y E.

 Los nodos hoja son F, G, C, H, Y, J y E.

 El subárbol del nodo B es el marcado en la figura.

Estructura de los nodos

En primer lugar, hay que considerar que todo árbol B+ tiene un número de orden d que indica la
capacidad de sus nodos. Más concretamente, si un árbol B + tiene orden d, entonces sus nodos
contienen como máximo 2d valores.

En un árbol B+, los nodos internos y los nodos hoja tienen una estructura diferente. Las causas
de esta diferencia estructural son tres:

1) Los nodos hoja son los que contienen todas las entradas del índice (es decir, las parejas de
valor y RID).
2) Los nodos internos tienen como objetivo dirigir la búsqueda de la hoja que tiene la entrada
correspondiente a un valor determinado. El acceso directo por valor consistirá, pues, en hacer un
recorrido del árbol que empezará en la raíz e irá bajando por los nodos del árbol hasta llegar a la
hoja adecuada (la que contiene, si existe, la entrada correspondiente al valor buscado).

3) Los nodos hoja están conectados por apuntadores, que sirven para facilitar el acceso
secuencial por valor (el recorrido de las hojas siguiendo los apuntadores proporciona las
entradas ordenadas por valor).

La figura 18 ilustra lo que acabamos de explicar.

Figura 18. Índice del árbol B+

Ejemplo de estructura de un árbol B+

La figura 18 muestra un índice de árbol B+ de orden d = 1 que sirve para acceder a datos de
empleados según el valor del atributo “número de empleado”. Observad que los RID que
apuntan a los datos están sólo en los nodos hoja, que los nodos internos sirven para buscar los
valores de las hojas y que el hecho de que las hojas estén conectadas entre sí facilita el acceso
secuencial por valor.

A continuación, describiremos la estructura de los nodos internos y después la estructura de los

nodos hoja de los árboles B+.

1) Estructura de un nodo interno

Un nodo interno contiene valores y apuntadores hacia sus nodos hijos (una manera de
implementar un árbol es tener en cada nodo apuntadores hacia todos sus nodos hijos).

La estructura de un nodo interno que contiene n valores (donde n es menor o igual que 2d) es la
que muestra la figura 19.
Figura 19. Estructura de un nodo interno

Cada vi indica un valor y cada fi indica un apuntador a un nodo hijo del árbol. Si un nodo

contiene n valores, entonces tiene n + 1 apuntadores a otros nodos del índice.

Tal como indica la figura 19, se cumple que el subárbol del nodo apuntado por fi contiene
valores v tales que:

 vi ≤ v < vi+1, si i > 0 e i < n.

 v < v1, si i = 0.

 v ≥ vn, si i = n.
Ejemplo de estructura de un nodo interno

La figura 20 muestra varios nodos de un índice de árbol B + de orden 2 por el atributo número de
empleado.

Figura 20. Ejemplo de árbol B+ de orden 2

Considerad el nodo raíz: tiene tres apuntadores que apuntan a sus nodos hijos. Observad que el
subárbol apuntado por el primero de estos apuntadores contiene valores menores que 10. El
subárbol apuntado por el segundo contiene valores mayores o iguales que 10 y menores que 45.
Finalmente, el subárbol apuntado por el tercero contiene valores mayores o iguales que 45.

2) Estructura de un nodo hoja

Los nodos hoja de los árboles B+ contienen entradas formadas por los valores a los cuales se
tiene que acceder y el RID que apunta a los datos, un apuntador al nodo hoja anterior y un
apuntador al nodo hoja siguiente.

La estructura de un nodo hoja que contiene n valores (donde n es menor o igual que 2d) es la
que muestra la figura 21. En la figura, cada vi corresponde a la entrada del valor vi (por
tanto, vi y su RID), aa indica el apuntador al nodo hoja anterior y as indica el apuntador al
siguiente.

Figura 21. Estructura de un nodo hoja

De manera adicional, es preciso que los nodos hoja cumplan las condiciones siguientes:

 Todos los valores de un nodo hoja son menores que los valores del nodo hoja siguiente.

 Todos los valores de algún nodo interno del árbol están repetidos en alguna hoja del
árbol (así, las hojas contienen todos los valores del árbol).

Ejemplo de estructura de un nodo hoja

La figura 22 muestra varios nodos de un índice de árbol B + de orden 2 por el atributo número de
empleado.

Figura 22. Ejemplo de estructura de un nodo hoja

Considerad, por ejemplo, el nodo hoja que está situado más a la izquierda. Contiene las
entradas del empleado número 2 y del empleado número 3. También tiene los apuntadores en la
hoja anterior y en la siguiente del árbol (en este caso concreto, no existe hoja anterior).
Observad que todos los valores del nodo considerado (los valores 2 y 3) son menores que los
valores de la hoja siguiente (6 y 8). Finalmente, observad que el valor 6 de la segunda hoja está
repetido en un nodo interno. El motivo es que en un árbol B + las hojas deben contener todos los
valores del árbol.

Acceso directo por valor

Para realizar un acceso directo por valor con un índice del tipo árbol B+ se requiere primero
localizar la hoja que tiene la entrada del valor buscado, y después usar el RID de la entrada para
localizar los datos a los que se quiere acceder.

Ejemplo de localización de la hoja que tiene la entrada del valor buscado

Mostraremos cómo se puede implementar la localización de un valor v en el árbol con un

ejemplo de la figura 22. Supongamos que queremos encontrar el valor 8 en el árbol del ejemplo
anterior.

Accedemos primero al nodo raíz. Después, seguimos el primer apuntador porque 8 < 20. A
continuación, seguimos el segundo apuntador, dado que 6 ≤ 8 < 12, y localizamos el nodo hoja
que contiene la entrada del valor deseado.

Supongamos ahora que buscamos el valor 26 en el mismo árbol. Accederemos igualmente al

nodo raíz. Seguiremos el apuntador al hijo de la derecha, porque 26 ≥ 20. Después seguiremos
el primer apuntador porque 26 < 27. El nodo hoja que obtenemos esta vez no contiene la
entrada del valor 26, lo cual indica que el 26 no está en nuestros datos.

Acceso secuencial por valor

Para realizar un acceso secuencial por valor con un índice del tipo árbol B + es necesario primero
localizar ordenadamente todas las entradas de los valores a los cuales se quiere acceder y, para
cada una, usar el RID que apunta a los datos para encontrar el valor.

La localización ordenada de las entradas del árbol es sencilla. Conviene recordar que las hojas
contienen todos los valores del árbol, que cada hoja tiene un apuntador a la hoja siguiente y que
los valores de un nodo hoja son menores que los valores del nodo hoja siguiente. Entonces, solo
hay que acceder primero a la hoja situada más a la izquierda y, después, ir accediendo cada vez
a la hoja siguiente hasta que se acabe la cadena de hojas.

Observación

Si seguimos el procedimiento de acceso secuencial por valor explicado en este subapartado con el

árbol de la figura 21, iremos obteniendo todas las entradas del árbol de manera ordenada.

Propiedades destinadas a mejorar el rendimiento

Consideremos un acceso directo por valor que se implementa con un árbol B +. Para localizar la
hoja que contiene la entrada del valor, el número de nodos que hay que recorrer es igual al del
nivel de la hoja mencionada. En consecuencia, si reducimos el nivel de las hojas de un árbol B +,
conseguiremos reducir el número de nodos que hay que recorrer cuando se hace un acceso
directo por valor.

Una propiedad de los árboles B+ destinada a reducir el nivel de las hojas es que todos los nodos
del árbol (excepto la raíz) tienen que estar llenos, como mínimo, hasta un 50% de su capacidad.
Esta norma equivale a exigir que en un árbol de orden d todos los nodos excepto la raíz
contengan, al menos, d valores.

Esta norma evita tener árboles B+ donde muchos de los nodos estén prácticamente vacíos. Si
conseguimos que los nodos de un árbol no estén demasiado vacíos, el árbol tendrá menos nodos
y también menos niveles.

Con el objetivo de mejorar el rendimiento de un índice, suele ser deseable que el número de
nodos que haya que recorrer sea siempre más o menos el mismo, independientemente de cuál
sea el valor al que se quiere acceder.

Por el motivo anterior, los árboles B+ cumplen una segunda propiedad: ser equilibrados. Un árbol
es equilibrado si todas sus hojas están en el mismo nivel.

En un árbol equilibrado, el nivel de las hojas es lo que se denomina altura del árbol. La

localización de cualquier hoja siempre requerirá recorrer un número de nodos que coincidirá con
la altura del árbol.

Observación

Observad que el árbol de la figura 22 es un árbol equilibrado y su altura es 3.

Almacenamiento del árbol y coste de localización de una entrada

Tal y como ya hemos visto, por las peculiaridades de los índices es aconsejable gestionarlos de
manera separada de los datos de las tablas. Por este motivo, existe un tipo de espacio virtual
para contener los índices denominado espacio de índices.

Una cuestión importante sobre el almacenamiento de un árbol es la elección de un tamaño

adecuado para sus nodos (que depende, por lo menos, del orden del árbol). Ya hemos explicado
que interesa que un árbol B+ tenga una altura pequeña; para ello, es preciso que los nodos del
árbol sean grandes aunque sin sobrepasar el tamaño de una página, porque de lo contrario no
se podrían consultar con una única E/S.
En consecuencia, el tamaño habitual de los nodos de un árbol B + coincide con el tamaño de las
páginas y cada nodo del árbol se almacena en una página virtual diferente. Observad que, según
esta forma de almacenamiento, en un árbol B+ de altura h son necesarias h E/S para localizar
una entrada del árbol (por ejemplo, si h = 3, harán falta tres E/S).

El hecho de que los nodos sean del tamaño de una página (que almacena normalmente 4 kB)
permite tener típicamente árboles de órdenes entre 50 y 100.

Orden habitual de un árbol y volumen de datos indexados

a) Supongamos que disponemos de páginas de 4 kB y los valores por indexar ocupan 20 bytes.
Consideremos también que el tamaño del RID es de 4 bytes y los apuntadores a páginas del
árbol ocupan 3 bytes. Según estos datos, en los nodos internos caben 177 valores y 178
apuntadores a otros nodos del árbol; en los nodos hoja caben 170 entradas (parejas de valor y
RID) y los 2 apuntadores a las hojas anterior y siguiente. Puesto que la capacidad en valores
debe ser la misma en todos los nodos, la restringiremos a 170 (el peor caso). El orden del árbol
será, pues, la mitad de 170, es decir, d = 85. Observad que hemos obtenido un orden que se
encuentra entre 50 y 100.

b) Consideremos ahora un árbol de orden d = 50, de altura h = 3 y donde todos los nodos
tienen una ocupación del 69%. Si d = 50, la capacidad máxima de los nodos es de 100 y una
ocupación del 69% supone tener 69 valores en cada nodo. En este árbol, tendremos el número
de valores siguiente en cada nivel:

 Nivel 1: 1 nodo con 69 valores y 70 apuntadores.

 Nivel 2: 70 nodos con 69 valores cada uno y 70 apuntadores cada uno.

 Nivel 3: 4.900 nodos con 69 entradas cada uno.

Es decir, 338.100 entradas en total. Según esto, el árbol B+ anterior, que tiene una altura de
solo 3 niveles, nos permite indexar un volumen de datos de 338.100 filas.

De este ejemplo se desprende que con órdenes d = 50 y una altura de h = 3 se puede indexar
una cantidad de datos considerable.

Reflexión

Si pensamos que el árbol B+ se construye sobre el número de empleado, y suponiendo que este

número es la clave primaria de la relación de empleados, nuestra relación podrá contener hasta

338.100 empleados diferentes.

Inserciones y supresiones
Las inserciones y supresiones se tienen que hacer de manera que el árbol resultante satisfaga
todas las propiedades de los árboles B+. Esto implica en algunos casos realizar una
reestructuración del árbol.

A) Inserciones

Describimos un algoritmo que, dada una entrada, localiza el nodo hoja que le corresponde y, si
este nodo tiene espacio libre, se la inserta. En el supuesto de que este nodo hoja no tenga
espacio libre para la nueva entrada, reestructura el árbol para encontrarle un lugar.

Comentaremos algunos ejemplos que nos ayudarán a entender con más exactitud qué debe
hacer este algoritmo de inserción, cuya descripción detallada queda fuera del alcance de este
módulo.

Consideremos el árbol B+ de orden 2 de la figura 23.

Figura 23. Árbol de partida I

A partir de este árbol, consideraremos los casos de inserción que exponemos a continuación:

a) Supongamos que se quiere insertar en este árbol la entrada 45*. El 45 tiene que pertenecer a
la hoja situada más a la derecha. Dado que esta hoja tiene espacio libre, la entrada 45* se
puede colocar en la hoja que le corresponde y no hay que hacer ninguna reestructuración del
árbol. Se obtiene el árbol que muestra la figura 24.

Figura 24. Inserción sin necesidad de reestructuración

b) Ahora consideramos que se quiere insertar la entrada 52* en el árbol que acabamos de
obtener. Le corresponde la hoja situada más a la derecha, pero no tiene espacio libre. Para
insertar la nueva entrada, hay que dividir la hoja en dos. Las dos hojas resultantes de la división
se muestran en la figura 25.

Figura 25. División de un nodo hoja

Cuando se divide un nodo, hay que insertar en su nodo padre un valor y un apuntador al nuevo
hijo. En nuestro ejemplo, este valor es el 40, porque es el valor más pequeño del segundo nodo
hoja que ha resultado de la división. Es necesario, pues, insertar el 40 y el apuntador en el nodo
padre. El nodo padre no tiene espacio y habrá que dividirlo.

Cuando se divide un nodo no-hoja, sus primeros d valores se dejan en el nodo (el 6 y el 12),
los d valores más grandes se colocan en un nuevo nodo (el 34 y el 40) y el valor del medio se
inserta en el nodo padre (el 27), junto con un apuntador hacia el nuevo nodo. La figura 26 nos
muestra esta división de un nodo no-hoja.
Figura 26. División de un nodo no-hoja

Observad las diferencias que hay entre esta división y la división de un nodo hoja.

Puesto que acabamos de dividir el nodo raíz del árbol, hay que crear un nuevo nodo raíz en el
que se colocan el valor 27, el apuntador al nuevo nodo y también un apuntador a la raíz antigua.
El árbol que se obtiene finalmente es el que podéis ver en la figura 27.

Figura 27. Inserción con reestructuración

B) Supresiones

Describiremos un algoritmo que, partiendo de una entrada, localiza el nodo hoja que le
corresponde, lo borra y, si hace falta, reestructura el árbol para que todos los nodos del árbol
(excepto la raíz) tengan, por lo menos, d valores.

Comentaremos algunos ejemplos para entender de manera más precisa cómo funciona el
algoritmo, cuya descripción detallada queda fuera del alcance de este módulo.

Consideremos el árbol de la figura 27 y supongamos los casos de supresión siguientes:

a) Supongamos que queremos borrar el valor 45 del árbol. La hoja que contiene la entrada del
valor 45 es la que está situada más a la derecha. Después de borrar 45*, la hoja todavía
contiene dos valores y, por lo tanto, no hay que hacer ninguna reestructuración. El árbol
obtenido es el que muestra la figura 28.

Figura 28. Supresión sin necesidad de reestructuración

b) Ahora supondremos que queremos borrar el valor 8 del árbol que acabamos de obtener. Su
entrada está situada en la segunda hoja del árbol. Después de borrarla, la hoja se queda con
menos de dos entradas, por lo que hay que corregirlo. Para garantizar que la ocupación de un
nodo sea correcta, es decir, que la estructura resultante después de la supresión siga siendo un
árbol B+, siempre utilizamos su nodo hermano de la derecha; solo si no tiene hermano a la
derecha usaremos el de la izquierda.

En nuestro ejemplo, puesto que el nodo hermano de la derecha tiene tres entradas, se hace una
redistribución de entradas entre los dos nodos hoja. La figura 29 ilustra esta redistribución.

Figura 29. Redistribución con nodos hoja

Observad que la redistribución afecta al contenido del nodo padre de los dos nodos
participantes. El valor 12 del nodo padre se cambia por el 15. El árbol que se obtiene finalmente
es el que se muestra en la figura 30.

Figura 30. Supresión con reestructuración

c) Consideremos ahora el caso del borrado del 35 del árbol que acabamos de obtener. La
entrada del 35 está situada en la penúltima hoja. Después de borrarla, la hoja se queda con
menos de dos entradas, de modo que hay que llevar a cabo una reestructuración. En este caso,
su nodo hermano de la derecha tiene solo dos entradas y, por lo tanto, no se hará una
redistribución como en el caso anterior (el nodo hermano no tiene entradas sobrantes para
redistribuir), sino que se hará una fusión de los dos nodos hoja en un único nodo.

La figura 31 nos muestra esta fusión de los nodos hoja.

Figura 31. Fusión de nodos hoja

Observad que cuando se fusionan dos nodos, su nodo padre pierde un valor. Debido a esta
pérdida, el nodo padre de nuestro ejemplo nos ha quedado con menos de dos valores. En este
caso, será preciso hacer todavía otra reestructuración del árbol para corregirlo. El nodo padre no
tiene ningún hermano a la derecha; por lo tanto, usaremos el de la izquierda para reestructurar
el árbol.

El hermano de la izquierda tiene solo dos valores, por lo que se hará una fusión de ambos
nodos. La figura 32 nos ilustra esta fusión de dos nodos no-hoja.

Figura 32. Fusión de nodos no-hoja

Conviene observar las diferencias respecto de la fusión anterior de dos hojas.

Después de esta última fusión, nos ha quedado un árbol con la raíz vacía. En estos casos hay
que descartar la raíz antigua y construir la raíz nueva con el nodo resultante de la fusión.
Finalmente, se obtiene el árbol que muestra la figura 33.

Figura 33. Supresión con reestructuración y pérdida de un nivel

d) Para el último ejemplo de supresión, elegimos el árbol B + de partida que muestra la figura 34.

Figura 34. Árbol de partida II

Ampliación

Consideremos el borrado del valor 25 del árbol. La entrada del 25 está en la tercera hoja.
Después de borrarlo, la hoja se queda con menos de dos entradas. Esta hoja no tiene ninguna
hoja hermana a la derecha y hay que fusionarla con la de la izquierda, como muestra la figura
35.

Figura 35. Fusión de nodos hoja

Después de la fusión, el nodo padre se ha quedado con menos de dos valores. Será necesario
hacer una redistribución con su nodo hermano derecho (que tiene más de dos valores). La figura
36 muestra esta redistribución de valores entre nodos no-hoja.

Figura 36. Redistribución con nodos no-hoja

Entonces, el árbol B+ que se obtiene finalmente es el que muestra la figura 37.

Figura 37. Supresión con redistribución de nodos

C) Supresiones de valores que tienen una copia en nodos internos

Hemos analizado un procedimiento de borrado de los valores de un árbol B + que sólo aparecen
en un nodo hoja del árbol. Como ya sabemos, un árbol B + puede tener valores que figuran en
dos lugares: en un nodo hoja y en un nodo no-hoja (nodo interno). Para borrar los valores que
tienen una copia en nodos internos, podemos utilizar el mismo procedimiento si hacemos
previamente una sustitución del valor copiado en el nodo interno por el valor del árbol que le
sigue según el orden de los valores. Una vez hecho esto, podremos emplear el procedimiento de
supresión anterior para eliminar el valor de la hoja.

Borramos el valor 53 de la figura 34, que tiene la entrada en la penúltima hoja del árbol y una
copia en el nodo padre de la hoja mencionada. Sustituimos la copia del 53 por el valor que le
sigue, que es el 56. Una vez hecho esto, borramos el 53 de la hoja. El árbol que nos queda se
muestra en la figura 38.

Figura 38. Supresión de valores que tienen una copia en nodos internos

Ampliación

Nodos hermanos

Dos nodos son hermanos si comparten el mismo nodo padre.

Valores repetidos
En las búsquedas, inserciones y supresiones de los árboles B + que acabamos de explicar no
hemos considerado la posibilidad de que pudiera haber valores repetidos en los datos; hemos
considerado que indexábamos los valores de atributos identificadores.

Existen varias soluciones para el tratamiento de los valores repetidos en los árboles B +;
comentaremos dos brevemente:

1) Una posibilidad es permitir la existencia de entradas diferentes con el mismo valor en el

árbol. En este caso, hojas diferentes pueden tener entradas correspondientes a un mismo valor.
El algoritmo de acceso directo por valor tendrá que localizar primero la entrada situada más a la
izquierda del valor, y después todas las posibles entradas adicionales del mismo valor. Estas
entradas adicionales se pueden encontrar en otras hojas y se localizan siguiendo los apuntadores
entre hojas del árbol. Las inserciones y supresiones también deben adaptarse.

2) Otra posibilidad es tener una sola entrada que contenga varios RID (uno para cada aparición
del valor). Esta posibilidad provoca que el tamaño de las entradas sea variable y que su gestión
resulte más compleja. Por el contrario, se ahorra espacio porque el valor en entradas diferentes
no se repite, y, en consecuencia, se ahorran operaciones de E/S.

6.3.4.Dispersión
Otros tipos de índices sirven para facilitar el acceso directo por valor, pero no el acceso
secuencial por valor: son los índices basados en la dispersión  (17) .

A continuación, analizaremos la utilización de la dispersión para implementar búsquedas en el

disco, donde es fundamental la minimización del número de E/S.

En inglés, hashing.
(17) 

Los índices basados en la dispersión consiguen normalmente un rendimiento algo mejor que

los índices de árbol B+ cuando se trata de implementar los accesos directos por valor. Por el
contrario, no permiten implementar los accesos secuenciales por valor, mientras que los árboles
B+ sí lo permiten. En consecuencia, algunos sistemas comerciales proporcionan solo
implementaciones basadas en los árboles B+.

Los sistemas comerciales

Algunos sistemas comerciales, como por ejemplo Oracle, proporcionan solo implementaciones basadas

en los árboles B+. Otros, como por ejemplo el sistema PostgreSQL, proporcionan ambos tipos de

índices.

Introducción a la dispersión
La característica fundamental de los índices basados en la dispersión es que las entradas se
colocan en las páginas según una función de dispersión h.

La función de dispersión h es una función que a partir de un valor v devuelve un número de

página p, es decir, p = h(v). El número de página p será un entero del intervalo [1, ..., N].
Entonces, la entrada correspondiente al valor v, que representamos por v*, se situará en la
página número p del intervalo.

Cuando se quiera acceder al valor v, podremos acceder a su entrada, v*, de la manera

siguiente:

 Se calcula el número de página p, tal que p = h(v).

 Se accede a la página p para localizar la entrada del valor v.

Podemos utilizar diferentes funciones h de dispersión que transforman un valor numérico o
alfanumérico en un número entero del intervalo [0, ..., N – 1]. Podremos usar cualquiera de
estas funciones siempre que sumemos 1 al resultado que nos den, porque nos interesa obtener
números de página que estén en el intervalo [1, ..., N].

Localización de una entrada con un índice basado en la dispersión

Queremos indexar unos datos por el valor de un atributo que representa nombres de pila.
Supongamos que h(Juan) = 3, h(Marta) = 1 y h(Rosa) = 4. Entonces, las entradas de estos
valores quedarán colocadas en las páginas del índice tal y como se muestra en la figura 39.

Figura 39. Ejemplo de página de índice

Para localizar la entrada del valor Rosa en el índice anterior, calcularemos h(Rosa). Este cálculo
nos dará el número de página 4. Luego, accederemos a la página 4, donde encontraremos la
entrada correspondiente a Rosa.

Observad que el número de valores posibles puede ser muy grande, mientras que el número de
páginas que puede ocupar el índice en el disco suele ser mucho más limitado. Esto hace que el
número de valores v posibles sea mucho mayor que el número N de páginas posibles. La función
de dispersión h transforma valores de un intervalo muy grande en posiciones de un intervalo
menor (el intervalo [1, ..., N]).

Por este motivo, es posible que para dos valores diferentes, vi y vj, suceda que h(vi) = h(vj), es
decir, que la función devuelva la misma página para los dos valores, como se aprecia en la
figura 40.

Figura 40. Valores sinónimos

En este caso, los valores vi y vj se denominan sinónimos. Las entradas correspondientes a los

valores sinónimos deben estar en la misma página. Las páginas, por lo tanto, deben poder
almacenar varias entradas. Denominamos L al número de entradas que caben en una página.

Ejemplo de valores sinónimos

Si al índice por el atributo “nombre de pila” anterior añadimos el valor Jorge y h(Jorge) = 4,

entonces tendremos la situación que se muestra en la figura 41.

Figura 41. Ejemplo de página de índice

A veces, una página puede ser insuficiente para contener todos los sinónimos que deberían
colocarse. Esto sucederá cuando a una página le correspondan más de L sinónimos.

Cuando un sinónimo no tiene espacio en la página que le corresponde, se denomina excedente y

se coloca en alguna otra página, que se elige según una determinada política de gestión de
excedentes. Existen diversas maneras alternativas de gestionar los excedentes; a continuación,
explicaremos una.

Ejemplo

Pensad en valores de un atributo que representa un DNI. Los valores posibles del atributo se

encuentran entre 0 y 99.999.999. En cambio, el número de páginas que puede ocupar el índice en el

disco difícilmente llegará a los cien millones.

Gestión de excedentes
La política de gestión de excedentes que estudiamos se basa en que el índice lo forman dos tipos
disjuntos de páginas:
 Páginas primarias: páginas donde colocaremos todas las entradas que no son
excedentes (habrá N).

 Páginas de excedentes: páginas destinadas a guardar las entradas excedentes.

Cuando una página primaria p se llena y se le inserta un nuevo valor que según la función de
dispersión debería ir en la misma página p, la entrada del valor se coloca en una página de
excedentes e y se añade a la página primaria p un apuntador hacia la página e.

Esta página de excedentes e se utilizará solo para contener los posibles excedentes de la página
primaria p que se inserten posteriormente. Si la página e también se llena, se le encadenará una
nueva página de excedentes e’ donde se podrán colocar más excedentes de la página primaria p,
y así sucesivamente.
De este modo, para cada página primaria con excedentes, se construye una cadena de páginas
de excedentes. El primer apuntador de la cadena está situado en la página primaria que lo ha
originado.

Puesto que hay una cadena separada de páginas de excedentes para cada página primaria, esta
política de gestión de excedentes a veces se denomina encadenamiento separado (18) .

Las supresiones de los valores del índice pueden hacerse de varias maneras. Una posibilidad es
marcar el valor con una señal especial que indique que está borrado, sin reorganizar nada. Otra
posibilidad es aprovechar estas supresiones de valores para reducir la longitud de las cadenas de
excedentes.

Ejemplo de gestión de excedentes con encadenamiento separado

Supongamos que tenemos un índice con cinco páginas primarias (N = 5), que todas las páginas
tienen una capacidad de tres entradas (L = 3) y que la función de dispersión es h(x) =
(x mod 5) + 1. Si insertamos los valores: 22, 23, 12, 57, 33, 38, 32, 67, 62, 43, 2, 3, el índice
quedará como muestra la figura 42.

Figura 42. Ejemplo de página de excedentes

En inglés, separate chaining.
(18) 

Almacenamiento y coste de localización de una entrada del índice

Los índices basados en la dispersión se almacenan en un tipo de espacio virtual
denominado espacio de índices (al igual que los índices de árbol B+).

Es fácil darse cuenta de que el coste de localizar una entrada en el índice almacenado en las
páginas de un espacio de índices varía bastante según si esa entrada es excedente o no:

 Si una entrada no es excedente y, por lo tanto, se encuentra en su página primaria, solo

habrá que hacer una E/S para obtenerla.

 Para las entradas excedentes, en cambio, siempre será necesario hacer más de una E/S.
En consecuencia, para conseguir un buen rendimiento del índice interesa que el índice tenga
pocas entradas de excedentes. Una manera de reducir el número de entradas de excedentes es
disponer de más espacio del que se requiere para las páginas primarias; es decir, conseguir que
las páginas primarias estén poco cargadas de entradas.

Se denomina factor de carga al número de entradas que se espera tener dividido por el

número de entradas que caben en las páginas primarias:

C = M / (N × L)

donde M representa el número de entradas que esperamos tener y N × L es el número de

entradas que caben en las páginas primarias.

Cuanto más bajo sea el factor de carga, menos excedentes habrá y menos E/S serán necesarias.
En contrapartida, si el factor de carga es muy bajo, se utiliza más espacio.

Ejemplo de cálculo de L

Si disponemos de páginas de 4 kB, los valores indexados ocupan 40 bytes, los RID, 4 y los
apuntadores a páginas, 3. Entonces, el número L de entradas será 93, dado que se tiene que
cumplir que 4 kB = (40 + 4)L + 3 (la página debe contener hasta L entradas formadas por el
valor y un RID cada una, así como el apuntador a la primera página de excedentes).

Introducción a la dispersión dinámica

La dispersión que acabamos de explicar es una dispersión estática, en el sentido de que el
número de páginas primarias N es fijo. Un problema que tiene este tipo de dispersión es que, si
el número de datos indexados crece más de lo previsto, puede ocurrir que el factor de
carga C aumente excesivamente y el rendimiento del índice empeore.

Una solución es crear un nuevo índice con un número N’ de páginas primarias mayor que N,
cambiar de función de dispersión para que devuelva valores de [0, ..., N’ – 1] en lugar de
valores de [0, ..., N – 1], y reinsertar todas las entradas en el nuevo índice empleando la nueva
función de dispersión. Sin embargo, esta solución es muy costosa.

La dispersión dinámica tiene el objetivo de admitir el incremento dinámico del número de

páginas primarias sin que sea necesaria la reinserción de todas las entradas.

Algunas técnicas de dispersión dinámica permiten modificar la función de dispersión de manera

dinámica para acomodarse al aumento o la disminución de los datos indexados. En este módulo,
sin embargo, no describimos las técnicas de dispersión dinámica, dos de las cuales, la dispersión
extensible y la dispersión lineal, las podéis encontrar explicadas con todos los detalles en la obra
de Ramakrishnan (2002).

Lectura complementaria

Encontraréis la explicación detallada de la dispersión extensible y la lineal en la obra siguiente:

R. Ramakrishnan; J. Gehrke (2002). Database management systems. Boston: McGraw-Hill.

6.3.5.Índices agrupados
Los índices que permiten implementar los accesos secuenciales por valor (como por ejemplo los
árboles B+) pueden ser índices agrupados (19) o índices no agrupados (20) .

Un índice agrupado es aquel en el que los datos que indexa están ordenados físicamente
según el acceso secuencial por valor que proporciona el índice. En cambio, un índice no
agrupado es un índice en el que los datos indexados están colocados de manera aleatoria.

La figura 43 ilustra las diferencias entre los índices agrupados y los no agrupados.
 En inglés, clustered.
(19) 

En inglés, unclustered.
(20) 

Figura 43. Diferencias entre índices agrupados y no agrupados

El coste de un acceso secuencial por valor varía mucho según si el índice que nos
proporciona el acceso es agrupado o no:

 Si el índice es agrupado, los RID que se obtengan consecutivamente apuntarán a filas

contiguas. Entonces, será necesario hacer muchos accesos seguidos a filas de la
misma página (y se podrán portar conjuntamente con una sola E/S).

 En índices no agrupados puede pasar que la mayoría de los RID consecutivos apunten a
filas de páginas diferentes. Esta situación puede llegar a suponer tantas E/S como
filas a las cuales haya que acceder.
Un aspecto que hay que tener en cuenta en los índices agrupados es que la ordenación física de
sus datos es difícil de mantener cuando se producen inserciones y supresiones. En la práctica,
esta dificultad se resuelve de la manera siguiente:

1) Inicialmente, se deja espacio libre en las páginas que contienen los datos para absorber
inserciones futuras.

2) Si el espacio libre de una página se agota, las inserciones futuras a la página se realizan en
páginas de excedentes que se le encadenan.

3) Si hay muchas páginas de excedentes, los datos se reorganizan para mejorar el rendimiento.

Reflexión

Aunque podemos tener varios índices sobre unos datos, solo uno puede ser agrupado, porque los

datos pueden tener una única ordenación física.

6.4.Implementación de los accesos por varios valores

La implementación de los accesos por varios valores es en algunos casos muy similar a la
implementación de los accesos por un solo valor, que ya hemos estudiado en el subapartado
anterior. En otros casos, no obstante, presentan algunas dificultades adicionales. Explicaremos
en primer lugar la implementación de los accesos directos por varios valores y a continuación
analizaremos los accesos secuenciales y mixtos por varios valores.

6.4.1.Implementación de los accesos directos

Considerad la relación Employees(emplId, emplName, officeNum, salary), que tiene un índice de
árbol B+ definido para facilitar los accesos por valor del atributo officeNum y otro índice de árbol
B+ para facilitar los accesos por valor del atributo salary.

Supongamos que se quiere ejecutar la sentencia siguiente, que requiere un acceso directo por
varios valores, concretamente por los valores de salary y de officeNum:

1. SELECT *
2. FROM Employees
3. WHERE officeNum = 150 AND salary = 1200;

Una buena estrategia para procesar la consulta anterior es la que presentamos a continuación:

1) Usar el índice del atributo officeNum para obtener todos los RID de las filas de empleados que
tiene el despacho 150.

2) Usar el índice del atributo salary para encontrar todos los RID de filas de empleados que
tienen el sueldo 1.200.

3) Realizar la intersección entre los dos conjuntos de RID. Los RID de la intersección
corresponden a los empleados que tienen al mismo tiempo el despacho 150 y un sueldo de
1.200.

Esta es una buena estrategia porque aprovecha el hecho de tener dos índices para los datos de
los empleados. Aun así, en algunos casos concretos puede tener un mal rendimiento.

Por ejemplo, si hay muchos empleados en el despacho 150, muchos empleados con un sueldo de
1.200 y muy pocos empleados que cumplan las dos condiciones a la vez, habrá que examinar
muchos RID para localizar pocos empleados. Una solución más eficiente para este caso es definir
un único índice –en lugar de dos, como en el caso anterior– que utilice valores compuestos de
los atributos officeNum y salary.
Un índice de valores compuestos por los atributos [A1, ..., Ai, ..., An] tiene la misma
estructura que los otros índices. La única diferencia es que los valores del índice serán, de
hecho, listas de elementos [v1, ..., vi, ..., vn] donde vi es un valor del atributo Ai.

La gestión del índice implica necesariamente establecer una relación de orden entre los valores
compuestos del índice. Se ordenan según el primer elemento de la lista y, si el primer elemento
coincide, se ordenan de acuerdo con el segundo; si este también coincide, se ordenan según el
tercero, etc.

Ejemplo de índice de valores compuestos

El índice de valores compuestos por los atributos [officeNum, salary] tiene valores como por
ejemplo [150, 1.200], [150, 1.500], etc.

Para establecer una relación de orden entre los valores compuestos del índice hay que deducir
para los dos valores anteriores [150, 1.200], [150, 1.500] cuál es el más grande. Aquí, puesto
que el primer elemento de la lista coincide, se utiliza el segundo para ordenar. Se obtiene que
[150, 1.200] < [150, 1.500].

En general, el orden entre dos valores compuestos v = [v1, ..., vi, ..., vn] y w =
[w1, ..., wi, ..., wn] se establece de la manera siguiente:

 Si v1  > w1, entonces v > w; y si v1  < w1, entonces v < w.

 Si v1  = w1 y v2> w2, entonces v > w; y si v1= w1 y v2< w2, entonces v < w.

 Si v1  = w1, ..., vi–1 = wi–1 y vi  > wi, entonces v > w; y si v1 = w1, ..., vi–1 = wi–1 y vi < wi,
entonces v < w.

 Si v1 = w1, ..., vi = wi, ..., vn = wn, entonces v = w.

6.4.2.Implementación de los accesos secuenciales y mixtos

Hemos visto que los índices de valores compuestos por los atributos [A1, ..., Ai, ..., An]
constituyen una buena implementación de los accesos directos por varios valores. En este
subapartado comentaremos su aplicación para implementar accesos secuenciales y mixtos por
varios valores y veremos que presenta algunas deficiencias.

Considerad otra vez la relación Employees(emplId, emplName, officeNum, salary) y recordad

que tiene un índice de árbol B+ de valores compuestos por los atributos [officeNum, salary].

Supongamos que se quieren ejecutar las sentencias siguientes:

 Sentencia 1:

1. SELECT *
2. FROM Employees
3. ORDER BY officeNum, salary;

Esta sentencia corresponde a un acceso secuencial por varios valores. El orden de presentación
de los empleados que requiere esta sentencia coincide con el orden de los valores compuestos
del índice por [officeNum, salary]. Así pues, el índice nos permitirá procesar la sentencia de
manera eficiente.

 Sentencia 2:
 1. SELECT *
2. FROM Employees
3. WHERE officeNum = 100 AND salary > 960;

Esta sentencia corresponde a un acceso mixto por varios valores. Observad que el orden de los
valores compuestos del índice por [officeNum, salary] concuerda con el orden en el que nos
interesa obtener los empleados para procesar la consulta. De este modo, el índice nos permite
también procesar la consulta de manera eficiente.

Desgraciadamente, no sucederá lo mismo con otros ejemplos de accesos secuenciales o mixtos

por varios valores, porque no habrá concordancia entre el orden del índice por
[officeNum, salary] y el orden que requiera la consulta. Este es el caso de las sentencias
siguientes:

 Sentencia 3:

1. SELECT *
2. FROM Employees
3. ORDER BY salary, officeNum;

 Sentencia 4:

1. SELECT *
2. FROM Employees
3. WHERE salary = 1200 AND officeNum > 100;

Para las sentencias 3 y 4 necesitaríamos un índice [salary, officeNum], en lugar del índice

[officeNum, salary].

Existen tipos de índices, denominados índices multidimensionales por varios atributos

[A1, ..., Ai, ..., An], que no imponen un orden lineal en el conjunto de valores indexados. Éstos
organizan los datos según un cierto vínculo espacial: cada valor se considera un punto de un
espacio de dimensión n, donde n es el número de atributos del índice.

Utilidad de un índice multidimensional

Con un solo índice multidimensional por los atributos salary y officeNum podríamos procesar todas las

sentencias de consulta 1, 2, 3 y 4 presentadas en este subapartado.

Se han propuesto varios tipos de índices multidimensionales: los árboles R, los archivos en
retícula, etc. Se utilizan sobre todo en SGBD destinados a almacenar información geográfica,
pero pocos sistemas relacionales los incorporan.

Lectura complementaria

Podéis encontrar la descripción de los árboles R y de los archivos en retícula en la obra siguiente:
A. Silberschatz; H. F. Korth; S. Sudarshan (2010). Fundamentos de bases de datos (3.ª ed.).

Madrid: McGraw-Hill.

6.5.Índices del sistema Oracle

El sistema Oracle pone al alcance del diseñador algunos de los índices que hemos estudiado en
este módulo.

Documentación Oracle

Para obtener los detalles de la implementación, así como una guía de la sintaxis y ejemplos de uso, se

puede consultar la documentación en línea del SGBD Oracle.

6.5.1.Accesos por valor

Para implementar accesos por valor directos o secuenciales el sistema Oracle proporciona índices
de árbol B+ por un atributo, que pueden ser agrupados o no.

Por ejemplo, si tenemos una relación Employees(emplId, emplName, officeNum, salary),

podemos declarar un índice para acceder por el valor del atributo denominado officeNum así:

1. CREATE INDEX indexOfficeNum ON Employees (officeNum);

Si se desea que el acceso secuencial sea por orden descendente, debe declararse de manera
explícita (porque, por defecto, el orden se considera ascendente):

1. CREATE INDEX indexOfficeNum ON Employees (officeNum DESC);

Podemos conseguir que el índice sea agrupado si declaramos:

1. CREATE INDEX CLUSTER indexOfficeNum ON Employees (officeNum);

Finalmente, si queremos que el índice no admita valores repetidos, la sentencia será:

1. CREATE UNIQUE INDEX indexOfficeNum ON Employees (officeNum);

6.5.2.Accesos por varios valores

Para implementar accesos por varios valores, el sistema Oracle proporciona índices de árbol
B+ de valores compuestos, que también pueden ser agrupados o no.

Por ejemplo, si en la relación Employees(emplId, emplName, officeNum, salary) queremos

declarar un índice de valores compuestos por los atributos [officeNum, salary], haremos:

1. CREATE INDEX indexOfficeSalary ON Employees (officeNum, salary);

Si queremos que el acceso secuencial por alguno de los atributos sea descendente, hay que
declararlo de manera explícita. Por ejemplo, si deseamos que la ordenación de los sueldos sea
descendente:

1. CREATE INDEX indexOfficeSalary ON Employees (officeNum, salary DESC);

También podemos conseguir que el índice sea agrupado:

1. CREATE INDEX CLUSTER indexOfficeSalary ON Employees (officeNum, salary);

Finalmente, si se desea que el índice no admita valores repetidos, habrá que declarar:

1. CREATE UNIQUE INDEX indexOfficeSalary ON Employees (officeNum, salary);

Resumen
En la primera parte de este módulo didáctico, hemos presentado los componentes que usan los
SGBD en el almacenamiento de los datos que gestionan. Hemos visto el nivel físico de la
arquitectura de una base de datos, en el que los SGBD utilizan los ficheros que ya conocíais de
otras asignaturas para almacenar los datos en dispositivos no volátiles, normalmente discos
magnéticos, y el nivel virtual, que es un nivel propio de los SGBD que permite simplificar la
visión que tienen de los datos almacenados.

En la segunda parte de este módulo, hemos tratado la manera de implementar el diseño físico
de la base de datos.

Finalmente, en la tercera y última parte de este módulo didáctico hemos identificado métodos de
acceso que son necesarios para llevar a cabo diferentes tipos de consultas y actualizaciones en
las BD. Estos métodos de acceso son los accesos directos y secuenciales por posición, los
accesos directos y secuenciales por valor y, finalmente, los accesos por varios valores, que
pueden ser directos, secuenciales o mixtos.

Hemos explicado que la implementación de los accesos por posición se fundamenta casi
completamente en los servicios proporcionados por el SO y que, en cambio, la implementación
eficiente de los accesos por uno o varios valores es más compleja y requiere que el SGBD
disponga de estructuras propias especializadas.

Hemos descrito algunas de las estructuras que los SGBD utilizan para implementar los accesos
por uno o varios valores: índices del tipo árbol B +, índices estructurados según funciones de
dispersión, índices agrupados e índices de valores compuestos. Hemos mostrado el impacto que
pueden tener estas estructuras en el número de E/S necesario para implementar los accesos a
los datos.

Glosario
acceso directo por posición m
Método de acceso que consiste en obtener una página que tiene un número de página
determinado dentro de un espacio.

acceso directo por valor m

 Método de acceso que consiste en obtener todas las filas que contienen un determinado
valor por un atributo.

acceso por varios valores m

Método de acceso que consiste en obtener varias filas según los valores de varios
atributos. Puede ser directo, secuencial o mixto.

acceso secuencial por posición m

Método de acceso que consiste en ir obteniendo las páginas de un espacio siguiendo el
orden definido por sus números de página.

acceso secuencial por valor m

Método de acceso que consiste en obtener varias filas por orden de los valores de un
atributo.

árbol B+ m
Estructura de datos que se emplea para organizar índices que permiten implementar el
acceso directo y el acceso secuencial por valor.

arquitectura de componentes de almacenamiento f

Esquema de tres niveles (lógico, físico y virtual) con el cual clasificamos y describimos
cada componente de los SGBD, especialmente aquellos que están relacionados con el
almacenamiento de los datos.

bloque m
Unidad de transferencia de datos entre la memoria del ordenador y los dispositivos o
ficheros externos. El sistema operativo de la máquina, concretamente la parte
especializada en la E/S, es quien lleva a cabo esta transferencia.

catálogo m
Conjunto de tablas que contienen los metadatos de la base de datos.

dispersión f
Manera de organizar valores que se puede utilizar en índices que implementan el acceso
directo por valor.

entrada f
Elemento de un índice que consiste en una pareja formada por un valor y un RID.

espacio virtual m
Secuencia de páginas virtuales. Proporciona una visión ordenada y contigua de las
páginas físicas. Según su funcionalidad específica tiene características ligeramente
diferentes, en función de las cuales puede ser un espacio para tablas, fragmentado, de
agrupación, de objetos grandes, de índices, temporal, etc.
sigla EV

EV m
 Podéis ver espacio virtual

extensión f
Unidad de asignación de espacio en un dispositivo periférico. Cada extensión es un
número entero de páginas consecutivas y está contenida dentro de un fichero.
Normalmente existe una extensión primaria, que se adquiere la primera vez que el
fichero se extiende, y una extensión secundaria, que corresponde a las extensiones
siguientes.

fichero m
Unidad de gestión del espacio en los dispositivos periféricos. Normalmente, el sistema
operativo gestiona los ficheros en lugar del SGBD.

identificador de fila m
Dirección uniforme que utilizan los SGBD para grabar las referencias internas de sus
estructuras de datos. Otros nombres equivalentes son ROWID y, últimamente, OID (en
la medida en que los SGBD relacionales se convierten en los denominados object-
relational).
sigla RID

índice m
Estructura de datos auxiliar que los SGBD usan para facilitar las búsquedas necesarias
para implementar los accesos por uno o varios valores.

índice agrupado m
Índice que proporciona el acceso secuencial por valor (y también el acceso directo por
valor) y que indexa datos que están ordenados físicamente según el orden del acceso
secuencial por valor proporcionado.

índice de valores compuestos m

Índice de valores compuestos por los atributos [A1, ..., Ai, ..., An]. Tiene la misma
estructura que los otros índices, pero con la diferencia de que los valores del índice son,
de hecho, listas de valores [v1, ..., vi, ..., vn] en las que cada vi es un valor del atributo Ai.

memoria intermedia f
Espacio de la memoria principal del ordenador, normalmente bastante grande, dedicado
a contener todas las unidades de memoria intermedia que gestiona el SGBD.

método de acceso m
Tipo de acceso a los datos almacenados por un SGBD.

nivel físico m
Nivel que engloba los componentes físicos (fichero, extensión y página) dentro de la
arquitectura de componentes de almacenamiento.

nivel lógico m
 Nivel que engloba los componentes lógicos (base de datos, tablas, vistas, restricciones,
etc.) dentro de la arquitectura de componentes de almacenamiento.

nivel virtual m
Nivel que engloba el componente virtual (el espacio virtual) dentro de la arquitectura de
componentes de almacenamiento.

página f
Unidad de transferencia de datos entre la memoria del ordenador y los ficheros de una
BD. El SO de la máquina es lo que lleva a cabo esta transferencia y pasa la página al
SGBD para que este le gestione la información que contiene, puesto que el SGBD es lo
que entiende la estructura interior de la página. La página también es la unidad principal
de grabación de los datos de una base de datos en los dispositivos periféricos. En este
módulo, a veces la denominamos página física o página real para distinguirla de la
página virtual.

página virtual f
Imagen de la página real o visión que desde el nivel virtual se tiene de la página real sin
materializarla físicamente. Hay una relación biunívoca entre página real y página virtual.

RID m
Podéis ver identificador de fila

SGBD m
Sigla de sistema de gestión de bases de datos

SO m
Sigla de sistema operativo

vector de direcciones de fila m

Estructura que ocupa las posiciones más altas dentro de una página. Es un vector con
tantos elementos como filas hay en la página. Cada elemento apunta a una de estas
filas. El último elemento apunta a la primera fila, el penúltimo a la segunda, y así
sucesivamente.
sigla VDF

VDF m
Podéis ver vector de direcciones de fila

Bibliografía
Elmasri, Ramez; Navathe, Shamkant, B. (2007). Fundamentos de sistemas de bases de
datos (5.ª ed.). Madrid: Pearson Educación.

Hansen, G. W.; Hansen, J. V. (1997). Diseño y administración de bases de datos (2.ª ed.).

Prentice Hall.

Ramakrishnan, Raghu; Gehrke, Johannes (2003). Database management systems (3.ª ed.).

Boston: McGraw-Hill Higher Education.
Silberschatz, A.; Korth, H. F.; Sudarshan, S. (2006). Fundamentos de bases de datos (5.ª
ed.). Madrid: McGraw-Hill. Edición de 2011 en eBook.

Teorey, T. J. (2011). Database Modeling & Design (5.ª ed.). San Francisco: Morgan Kaufmann
Publishers, Inc.

Procesamiento de consultas y
vistas
Seguridad en bases de datos
 Joan Anton Pérez Braña

 Santiago Ortego Carazo (†2007)

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a

una licencia Creative Commons de tipo Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND)

v.3.0. Se puede copiar, distribuir y transmitir la obra públicamente siempre que se cite el autor y la

fuente (Fundació per a la Universitat Oberta de Catalunya), no se haga un uso comercial y ni obra

derivada de la misma. La licencia completa se puede consultar en:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Índice
 Introducción

 Objetivos

 1.Procesamiento de consultas
o 1.1.Descomposición de consultas

 1.1.1.Validación léxica y sintáctica

 1.1.2.Normalización de la consulta

 1.1.3.Análisis semántico

 1.1.4.Simplificación
o 1.2.Optimización semántica

o 1.3.Optimización sintáctica

 1.3.1.Reglas de equivalencia

 1.3.2.Estrategias de procesamiento heurístico

o 1.4.Estimación de costes para las operaciones de álgebra relacional

 1.4.1.Estadísticas de la base de datos

 1.4.2.Operación de selección

 1.4.3.Operación de ordenación
  1.4.4.Operación de proyección

 1.4.5.Operación de combinación

 1.4.6.Operaciones de conjuntos de álgebra relacional

 1.4.7.Agregación
o 1.5.Optimización física

 1.5.1.Optimización heurística

 1.5.2.Optimización basada en costes

 2.Procesamiento de vistas
o 2.1.Mecanismos de implementación de vistas

o 2.2.Actualización de vistas

 2.2.1.Actualización con disparadores de sustitución

o 2.3.La vista como elemento de diseño externo

o 2.4.Las tablas derivadas

o 2.5.Tablas temporales

o 2.6.Ventajas e inconvenientes en la utilización de vistas

 3.La seguridad
o 3.1.Identificación y autenticación

o 3.2.Control de acceso

 3.2.1.Control de acceso discrecional

 3.2.2.Control de acceso obligatorio

 3.2.3.Clasificación de los sistemas de seguridad

o 3.3.Implementación del control de acceso discrecional a SQL:2011

o 3.4.Auditoría

o 3.5.La Ley de protección de datos de carácter personal

 3.5.1.Principios generales de protección de datos

 3.5.2.Los niveles de seguridad

 3.5.3.La Agencia de Protección de Datos

 4.Anexos
o 4.1.Reglas de equivalencia de operaciones de álgebra relacional

o 4.2.Consideraciones sobre vistas en el SGBD Oracle 11g

 4.2.1.Vistas del diccionario de datos

 4.2.2.Operaciones de actualización sobre vistas

o 4.3.Aspectos referentes a la seguridad en el SGBD Oracle 11g

 4.3.1.Gestión de usuarios

 4.3.2.Definición de perfiles

 4.3.3.Identificación de usuarios
  4.3.4.Gestión de los privilegios

 4.3.5.Roles
 Resumen

 Glosario

 Bibliografía

Introducción
El lenguaje SQL es un lenguaje declarativo. Como tal, las consultas realizadas con este lenguaje
especifican qué se quiere obtener en lugar de indicar cómo se quiere conseguir. En el presente
módulo se explica la forma en que los sistemas gestores de bases de datos (SGBD) relacionales
evalúan sistemáticamente las posibles estrategias alternativas que se pueden presentar, de
acuerdo con las necesidades de los usuarios y las aplicaciones, con el objetivo de escoger la
estrategia que se considera óptima.

También veremos que las vistas proporcionan mecanismos de seguridad y permiten al diseñador
de la base de datos personalizar el modelo lógico al modelo de los usuarios. Se estudiará en qué
casos una vista es actualizable y qué mecanismos incorporan los SGBD para permitir que las
vistas sean actualizables.

Por último, estudiaremos las técnicas empleadas para proteger la base de datos contra accesos
no autorizados y los mecanismos para otorgar/revocar privilegios a los diferentes usuarios según
el modelo de negocio implícito en el sistema de información. También trataremos las
obligaciones legales derivadas del hecho de estar en posesión de determinados datos
especialmente protegidos.

Objetivos
Los materiales didácticos asociados a este módulo os permitirán lograr los siguientes objetivos:

1. Saber cuáles son los mecanismos de procesamiento y optimización de consultas, y

así poderlas plantear de la forma más eficiente posible.

2. Conocer las diferentes estrategias de implementación de las operaciones de álgebra

relacional con el fin de evaluar el coste de las consultas.

3. Interpretar y optimizar el plan de ejecución de una consulta de forma adecuada.

4. Presentar las vistas como elementos de diseño externo que permiten la actualización
de datos.

5. Conocer nuevas aplicaciones de las vistas para mejorar el diseño de la base de datos.

6. Conocer el alcance de los mecanismos de seguridad de una base de datos.

7. Tomar conciencia de las obligaciones legales derivadas del cumplimiento de la Ley

orgánica de protección de datos de carácter personal.

1.Procesamiento de consultas
Una de las principales críticas a los primeros sistemas gestores de bases de datos (SGBD  (1) )
relacionales fue el bajo rendimiento en el procesamiento de consultas. En los lenguajes no
procedimentales, como es el caso del SQL, el usuario especifica los datos que quiere obtener en
lugar de indicar cómo quiere conseguirlos.
El procesamiento de consultas hace referencia al conjunto de actividades que el SGBD lleva a
cabo para extraer información de una base datos con el objetivo de lograr la estrategia más
eficiente y que le permita tener un mayor control sobre las prestaciones del sistema.

Figura 1. Etapas del procesamiento de consultas.

En la figura 1 podéis observar gráficamente las cuatro etapas que componen el procesamiento
de consultas:

1) descomposición de la consulta,

2) optimización de la consulta,

3) generación de código, y

4) ejecución de la consulta.

La descomposición de consultas implica la traducción de consultas expresadas en lenguaje

SQL a una representación interna basada en el álgebra relacional que suele ser más útil.

En primer lugar, se comprueba la corrección sintáctica y semántica de la consulta en SQL y

después se crea un árbol sobre el cual se realiza el análisis de la consulta, que se transformará
en una expresión de álgebra relacional.
Por lo que respecta a las expresiones de álgebra relacional, utilizaremos el siguiente convenio de
símbolos:

Concepto Representación Observaciones

Relaciones R, S La lista de atributos de cada relación se define según el esquema siguiente: R =

(A1, A2, ..., An).

Predicados p, q Estos predicados se evaluarán lógicamente en las operaciones de selección y

combinación.

Selección σp(R) Operación que devuelve las tuplas de la relación R  que satisfacen la evaluación del

predicado p.

Proyección ∏L(R) Donde L corresponde a una lista de atributos que se mostrarán de la relación R.

Unión (R) ∪ (S) Se obtiene una relación nueva que incluye las tuplas de la relación R y S menos las

repeticiones.

Intersección (R) ∩ (S) Se obtiene una relación nueva que incluye las tuplas que pertenecen a las dos

relaciones, R y S .

Diferencia (R) – (S) Se obtiene una relación nueva que incluye las tuplas que pertenecen a la relación R pero

que no están incluidas en la relación S.

Producto cartesiano (R) × (S) Se obtiene una relación nueva formada por todas las tuplas que resultan de concatenar

tuplas de la relación R con tuplas de la relación S.

Combinación Theta (R) ⋈ p (S) Se obtiene una relación nueva que incluye los atributos de los pares de tuplas

correspondientes a R y S que satisfacen el predicado p.

A partir del primer árbol de consulta lógico, que representa la expresión relacional, empieza el
proceso de optimización de la consulta.

La optimización de consultas consiste en encontrar el plan de ejecución más eficiente de

entre varias estrategias disponibles para procesar una consulta dada.

La optimización de consultas se lleva a cabo desde tres vertientes:

1) Optimización semántica, que consiste en reescribir la consulta basándose en las
restricciones especificadas en el esquema de la base de datos.

2) Optimización sintáctica, que consiste en transformar heurísticamente la expresión

relacional original en otra equivalente, pero que sea mucho más eficiente. Del mismo modo que
una consulta se puede expresar de diferentes formas en SQL, una consulta SQL también se
puede traducir a diferentes expresiones de álgebra relacional.

Supongamos el esquema de la base de datos COMPANY definido a continuación:

SGBD es la sigla de sistema gestor de bases de datos.

(1) 

Jobs(jobId,jobName)
Locs(locId,streetAddress,postalCode,stateProvince,city,countryId)
Emp(empId,firstName,lastName,jobId,deptId,hireDate,
salary,manager)
{jobId} REFERENCES Jobs(jobId),
{manager} REFERENCES Emp(empId),
{deptId} REFERENCES Dept(deptId)
Dept(deptId, deptName, managerId, locId),
{locId} REFERENCES Locs(locId),
{managerId} REFERENCES Emp(empId)

Imaginemos que queremos consultar los empleados de la base de datos COMPANY que

pertenecen al departamento “IT” y que son alta en la empresa a partir del 1 de septiembre del
2007.

1. SELECT *
2. FROM Emp e, Dept d
3. WHERE e.dept Id = d.dept Id
4. AND (e.hireDate > ';01-SEP-07';
5. AND d.deptName LIKE ';IT';) ;

A partir de esta consulta, podemos obtener tres expresiones de álgebra relacional equivalentes
distintas:

a) Se realiza el producto cartesiano entre las relaciones Emp  y Dept para posteriormente

realizar las operaciones de selección correspondientes:

σ(deptName=′IT’)∧(hireDate>′01-SEP-07’)∧(Emp:deptId=Dept:deptId)(Emp × Dept)

b) Se combinan las tablas y después se realizan las operaciones de selección:

σ(deptName=’IT’)∧ (hireDate>′01-SEP-07’)(Emp ⋈ (Emp:deptId=Dept:deptId) Dept)

c) Primero se realizan las operaciones de selección correspondientes a cada tabla y después se

combinan los resultados:

(σ(deptName=′IT’) Dept) ⋈ (Emp:deptId=Dept:deptId) (σ(hireDate>′01-SEP-07’)(Emp))

Reflexión
Prestad atención al hecho de que la serie de operaciones de álgebra relacional es diferente en cada

caso.

3) Optimización física, que permite escoger, de entre los distintos planes de evaluación, cada
uno con costes diferentes, el que resulte más eficiente. Para determinar el coste más eficiente
de cada consulta, es preciso conocer el coste de la secuencia de operaciones del álgebra que la
forman y, por lo tanto, de cada operación, lo cual a menudo depende de diferentes parámetros.
Así pues, para especificar completamente cómo se evaluará la consulta, hay que determinar qué
algoritmos se utilizarán para cada operación y cuáles serán los índices empleados. Estas
especificaciones se denominan primitivas de evaluación, y la secuencia de estas primitivas se
denomina plan de ejecución de una consulta.

El plan de ejecución es la secuencia de pasos que realizará el SGBD para ejecutar una
sentencia SQL.

El SGBD construye un plan de ejecución que minimiza el uso de recursos. Así, trata de reducir
en la medida de lo posible el tiempo de ejecución de la consulta, ya sea minimizando el tiempo
de cada operación o maximizando el número de operaciones paralelas. Por último, el motor de
ejecución será el que ejecutará el plan trazado y obtendrá el resultado de la consulta a partir
de los datos almacenados.

Reflexión

Antes del estudio de la optimización física, se ofrecerá una visión de la estimación de costes para las

diferentes operaciones del álgebra relacional.

1.1.Descomposición de consultas
Esta es la primera fase del procesamiento de una consulta. Se comprueba que la consulta sea
sintáctica y semánticamente correcta y, si es el caso, se transforma la consulta expresada en
lenguaje SQL en un conjunto de operaciones de álgebra relacional.

Las etapas típicas de la descomposición de consultas son:

1) validación léxica y sintáctica,

2) normalización de la consulta,

3) análisis semántico, y

4) simplificación.

1.1.1.Validación léxica y sintáctica

La consulta se analiza léxica y sintácticamente empleando las técnicas de compiladores de los
lenguajes de programación.

Se accede al diccionario de datos y se comprueba que todas las tablas y atributos que se
mencionan en la consulta realmente existen. También se comprueba que el usuario tiene los
derechos de acceso correspondientes y que las operaciones realizadas son adecuadas para aquel
tipo de objeto.

Ejemplo de validación léxica y sintáctica

Supongamos el esquema de la base de datos COMPANY y la siguiente consulta:

1. SELECT emplId
2. FROM Emp
 3. WHERE deptId LIKE ';10';;

Esta consulta sería rechazada por dos motivos:

1) El atributo emplId no está definido por la relación Emp: habría que denominarlo empId.

2) La comparación LIKE ‘10’ es incompatible con el tipo de datos deptId, que es numérico en

lugar de ser una cadena de caracteres.

Finalizado este análisis, la consulta se ha transformado en un árbol de consulta construido de la

siguiente manera:

1) Por cada relación base de la consulta se crea un nodo hoja.

2) Por cada operación intermedia producida por una operación de álgebra relacional se crea un
nodo no hoja.

3) El resultado de la consulta se representa como la raíz del árbol.

4) La secuencia de operaciones se dirige de los nodos hoja al nodo raíz.

Ejemplo de transformación de una consulta en un árbol de operaciones relacionales

Consideremos la siguiente consulta:

1. SELECT e.firstName, e.lastName, e.hireDate, d.deptName

2. FROM Emp e, Dept d
3. WHERE e.dept Id = d.dept Id
4. AND (e.hireDate > ';01-SEP-07'; AND d.deptName LIKE ';IT';);

Esta consulta genera el plan de evaluación siguiente:

Que corresponde a la siguiente expresión relacional:

∏firstName;lastName((σ(hireDate>′01-SEP-07’)(Emp)) ⋈ (Emp:deptId=Dept:deptId) (σ(deptName=′IT’)(Dept)))

Ved también
Los derechos de acceso se estudian en el apartado 3 de este módulo didáctico.

1.1.2.Normalización de la consulta
Se evalúa el predicado de la cláusula WHERE, que a menudo suele ser lo bastante complejo
como para convertir la consulta en una de estas formas normalizadas:

 Forma normal conjuntiva: genera una secuencia de conjunciones conectadas con el

operador ∧ (AND). Cada conjunción puede contener uno o más predicados conectados
con el operador ∨ (OR).

Ejemplo

(jobId  =′STClerk′ ∨ salary > 2000) ∧ manager = 121

 Forma normal disyuntiva: genera una secuencia de disyunciones conectadas con el

operador ∨ (OR). Cada disyunción puede contener uno o más predicados conectados
con el operador ∧ (AND).

Ejemplo

(jobId  =′STClerk′ ∧ salary > 2000) ∨ (jobId =′STClerk′ ∧ manager = 121)

1.1.3.Análisis semántico
En esta etapa se lleva a cabo un análisis semántico con el objetivo de rechazar las consultas
normalizadas que sean contradictorias o que no estén bien formuladas.

Una consulta incorrecta es aquella cuyos componentes, una vez formulada, no permiten la
generación de resultado, lo que puede suceder si falta alguna especificación de combinación.

Ejemplo de consulta incorrecta

1. SELECT e.firstName, e.lastName

2. FROM Emp e, Dept d, Locs l
3. WHERE e.deptId=d.deptId
4. AND l.city LIKE ';Paris';
5. AND e.salary > 2000;

Esta consulta se considera incorrecta porque las conexiones entre relaciones no están
completas, ya que se ha omitido la condición de combinación d.locId=l.locId.

Una consulta contradictoria es aquella que contiene en su formulación algún predicado que

ninguna tupla puede satisfacer.

Ejemplo de consulta contradictoria

1. SELECT firstName, lastName, salary

2. FROM Emp
3. WHERE salary < 1200 AND salary > 2000;

Esta consulta es contradictoria porque las dos condiciones de la cláusula WHERE son

incompatibles.
1.1.4.Simplificación
El objetivo de esta etapa es detectar predicados redundantes, eliminar expresiones comunes y
transformar una consulta en otra semánticamente equivalente pero que se pueda calcular de
una forma más eficiente. Para realizar este proceso, se aplican las reglas de la lógica.

Ejemplo de simplificación

Consideremos la siguiente consulta:

1. SELECT firstName, lastName, salary

2. FROM Emp
3. WHERE salary > 1200 AND salary > 2000;

Esta consulta se puede simplificar, ya que la segunda condición incluye la primera:

1. SELECT firstName, lastName, salary

2. FROM Emp
3. WHERE salary > 2000;

Ejemplo de simplificación de predicados redundantes

Consideremos también esta otra consulta:

1. SELECT firstName, lastName, salary, managerId, jobId

2. FROM Emp
3. WHERE (jobId LIKE 'STClerk' AND manager = 121)
4. AND manager = 121;

Se puede transformar en otra consulta con una condición WHERE equivalente:

1. SELECT firstName, lastName, salary, managerId, jobId

2. FROM Emp
3. WHERE jobId LIKE 'STClerk' AND manager = 121;

1.2.Optimización semántica
La optimización semántica utiliza una técnica que emplea las restricciones especificadas en el
catálogo de la base de datos para reducir el espacio de búsqueda.

Ejemplo de optimización semántica

Suponiendo una restricción que indica que el salario debe ser superior a 500 euros, la consulta
que presentamos a continuación:

1. SELECT firstName, lastName, salary

 2. FROM Emp
3. WHERE salary > 500 AND deptId = 3 ;

podría simplificarse así:

1. SELECT firstName, lastName, salary

2. FROM Emp
3. WHERE deptId = 3 ;

Ejemplo de optimización semántica

Del mismo modo, consideremos esta otra consulta:

1. SELECT e.deptId
2. FROM Emp e, Dept d
3. WHERE e.deptId = d.deptId;

Dado que todos los valores de e.deptId deben ser valores de d.deptId, la consulta que
presentamos a continuación es equivalente a la anterior:

1. SELECT e.deptId
2. FROM Emp e;

La implementación de este tipo de optimizadores en el SGBD permite incrementar el

rendimiento, sobre todo en aquellos sistemas que tengan una semántica muy rica y
completamente implementada, ya que evita buscar según aquellas condiciones que no se
cumplen para ninguna fila de la tabla.

1.3.Optimización sintáctica
Mediante la aplicación de diferentes reglas de transformación, el optimizador puede convertir
una expresión de álgebra relacional en otra expresión equivalente pero más eficiente. Para llevar
a cabo este proceso, se aplican las reglas de equivalencia entre las operaciones de álgebra
relacional, con el objetivo de encontrar una expresión equivalente.

1.3.1.Reglas de equivalencia
Las reglas de equivalencia y las estrategias de procesamiento heurístico que se utilizan para
reestructurar el árbol de operaciones de álgebra relacional son las siguientes:

1) Capacidad de transformación de las operaciones conjuntivas de selección en una cascada de

operaciones individuales de selección.

2) Conmutatividad en las operaciones de selección.

3) En una secuencia de operaciones de proyección, solo hace falta la última proyección de la
secuencia.

4) Conmutatividad de la selección y la proyección.

Ved también

Podéis consultar varios ejemplos de reglas de equivalencia en los anexos del apartado 4.

5) Conmutatividad de la combinación Theta (y del producto cartesiano).

6) Conmutatividad de la selección y de la combinación Tetha (y del producto cartesiano).

7) Conmutatividad de la proyección y de la combinación Tetha (y del producto cartesiano)

8) Conmutatividad de la unión y de la intersección, pero no de la diferencia.

9) Conmutatividad de la selección y de las operaciones de conjuntos (unión, intersección y

diferencia).

10) Conmutatividad de la proyección y de la unión.

11) Asociatividad de la combinación Tetha (y del producto cartesiano).

12) Asociatividad de la unión y de la intersección (pero no de la diferencia de conjuntos).

Combinaciones Theta

Combinaciones que utilizan los operadores de comparación como condición de combinación.

1.3.2.Estrategias de procesamiento heurístico

Una serie de reglas heurísticas permiten encontrar una buena expresión equivalente, muchas
veces la mejor, a partir de la aplicación de las propiedades mencionadas anteriormente.

Los heurísticos normalmente aceptados son los que se presentan a continuación:

1) Realizar las operaciones de selección lo antes posible. Debido a que estas operaciones
reducen la cardinalidad de la relación resultante, utilizaremos la regla 1 para “conectar en
cascada” todas las operaciones de selección. Después aplicaremos las reglas 2, 4, 6 y 9,
definidas anteriormente, referentes a la conmutatividad de la selección con operaciones unarias
y binarias. Las operaciones de selección aparecerán cerca de los nodos hoja del árbol indicando
que son las primeras en realizarse. Se mantendrán juntos los predicados referentes a la misma
relación.

2) Transformar el producto cartesiano de dos relaciones seguido de una operación de selección

en una operación de combinación.

3) Emplear la asociatividad de las operaciones binarias para reordenar los nodos hoja. El
objetivo es que las operaciones de selección más restrictivas se ejecuten primero.

4) Realizar las operaciones de proyección lo antes posible.

5) El cálculo de las expresiones comunes sólo se realizará una vez.

Ved también

Observad cómo se han aplicado las estrategias de procesamiento en el árbol representado en el

subapartado 1.1.1 de este módulo didáctico.

1.4.Estimación de costes para las operaciones de álgebra relacional

Las implementaciones de operaciones del álgebra relacional son diferentes para cada SGBD, y
cada una de ellas tiene un coste asociado. Cuando evaluamos el coste de una consulta, es decir,
el tiempo de respuesta para el plan de evaluación de una consulta, hay que tener en cuenta
diferentes factores, como el coste de CPU, los accesos a memoria, los accesos a disco e incluso
el tiempo empleado por las comunicaciones con sistemas remotos (en el caso de los SGBD
distribuidos).

En los grandes SGBD, el coste más importante corresponde al acceso a disco, puesto que es el
dispositivo más lento. Así pues, para comparar las diferentes estrategias de manera relativa solo
se utilizará el número de páginas de disco a las que se accede (por operaciones de
lectura/escritura) en el peor de los casos.

Consideraciones sobre el coste de los accesos a disco

Consideremos que el subsistema de disco tarda tT segundos en realizar una operación de

transferencia de un bloque de datos con un tiempo de acceso a bloque tB, que corresponde al
tiempo de búsqueda en disco más la latencia rotacional. Entonces, una operación que
transfiera nBlocks y ejecute N buscas tendría un coste temporal de nBlocks · tT+ N · tB.

En las siguientes consideraciones, no se tendrán en cuenta las operaciones de escritura a disco

que tardan el doble de tiempo ni tampoco si hay alguna información en memoria intermedia.
Este valor de estimación de coste se expresará como CE.

Parámetros de acceso a disco

Para tener una idea de los parámetros asociados a los accesos a disco, podemos suponer que tT = 0,1

ms y tB = 4 ms en caso de que la medida de un bloque sea de 4 kilobytes y se disponga de una

velocidad de transferencia de 40 megabytes por segundo.

1.4.1.Estadísticas de la base de datos

El éxito de la estimación de la medida y del coste de las operaciones intermedias depende de la
calidad y del grado de actualización de la información estadística almacenada en un SGBD. Para
poder estimar el coste de cada uno de los algoritmos, es preciso disponer de valores estadísticos
de las tablas que intervienen en la consulta, la mayoría de los cuales son valores medios que se
mantienen calculados (o se recalculan de vez en cuando) en el diccionario de datos. Los
estadísticos más importantes son los que se relatan a continuación.

Para cada relación (o tabla) R:

1) nTuples(R): número de tuplas de la relación R; es decir, su cardinalidad.

2) blockFactor(R): factor de bloqueo de R; el número de filas de R que caben en una página.

3) nBlocks(R): número de bloques requeridos para guardar todas las tuplas de R, donde:

nBlocks(R) = nTuples(R)/blockFactor(R)

4) t(R): tamaño en bytes de una fila de R.

Para cada atributo A de la tabla R:

1) nDistinctA(R): número de valores diferentes del atributo A que aparecen en R.

2) minA(R): menor valor del atributo A  en la tabla R.

3) maxA(R): mayor valor del atributo A  en la tabla R.

4) CSA(R): cardinalidad de la selección del atributo. Es el número medio de filas que cumplen
una condición sobre el atributo A.

Para una condición de igualdad sobre el atributo A, el cálculo es:

a) Si A  es una clave candidata:

CSA(R) = 1
b) Si los valores están distribuidos de forma uniforme:

CSA(R) = nTuples(R)/nDistinctA(R)

También es posible, suponiendo una distribución uniforme, calcular la cardinalidad de selección

para otros casos diferentes de la igualdad:

a) Para predicados de comparación del tipo A  > a:

CSA>a(R) = nTuples(R) · (maxA(R) –  a)/(maxA(R) –  minA(R))

b) Para predicados de comparación del tipo A  < a:

CSA<a(R) = nTuples(R) · (a –  maxA(R))/(maxA(R) –  minA(R))

c) Para A ⊂ (a1, ... , an), donde n es el número de elementos del conjunto (a1, ... , an):

CSA⊂(a1, ..., an)(R) = n · (nTuples(R)/nDistinctA(R))

d) Para la disyunción de dos predicados, A ∨ B:

CSA∨B (R) = CSA(R) · CSB(R)/nTuples(R).

e) Para la conjunción, A ∧ B:

CSA∧B (R) = CSA(R) + CSB(R) – (CSA(R) · CSB(R)) / nTuples(R)

Para cada índice multinivel I de un atributo A:

1) nLevelsA(I): el número de niveles en I.

2) nLfBlocksA(I): el número de páginas de hojas en I.

Otro dato importante es el número de páginas de memoria, M, que se pueden utilizar como
memoria intermedia.

1.4.2.Operación de selección
Hay muchos algoritmos para la selección de valores en una tabla. A continuación, hacemos un
repaso de los más importantes e indicamos su coste:

1) Búsqueda lineal sobre ficheros no ordenados: con este algoritmo se exploran todas las
páginas que forman la tabla y se comprueba cada una de las filas para ver si contiene el valor
adecuado del atributo:

Si se trata de un atributo que no es una clave candidata, el coste será:

CE  = nBlocks(R)

Si el atributo sobre el cual se hace la búsqueda es una clave candidata, de media lo

encontraremos hacia la mitad de la tabla, a veces antes y a veces después. En este caso el coste
será:

CE  = nBlocks(R)/2

2) Búsqueda binaria sobre ficheros ordenados: consiste en examinar primero la posición

central de la tabla de forma que se elimina la mitad que no corresponde y se repite el
procedimiento hasta que se encuentra el valor buscado:

 Para encontrar una tupla con un atributo clave, el coste será:

CE = log2(nBlocks(R))

 Si se trata de un atributo no clave y se supone una distribución uniforme de los valores,

tendremos:
 CE = [log2(nBlocks(R)] + [CSA(R)/blockFactor(R)] – 1

3) Igualdad con una clave hash: si el atributo es una clave hash, se aplica el

algoritmo hash para calcular la dirección correspondiente a una tupla determinada. Si no hay
desbordamiento, el coste será 1.

4) Igualdad de clave primaria con un índice B+ tree: si la búsqueda se hace con respecto a
la igualdad de una clave primaria sobre la cual se ha definido un índice con estructura de árbol
B+, el número de páginas leídas será igual al número de niveles del árbol más la página de los
datos, es decir:

CE  = nLevelsA(I) + 1

5) Desigualdad con la clave primaria: si la condición de búsqueda es la de desigualdad con

la clave principal, se puede emplear el índice para localizar la tupla que satisface el
predicado A = x y así, posteriormente, leer las tuplas que se encuentran situadas antes o
después de la localizada.

6) Igualdad con un índice secundario: si se trata de un índice que no representa una clave
candidata y, por lo tanto, pueden existir diferentes valores que cumplen la igualdad, se deberán
leer todas las páginas que los contengan y el coste será:

CE = nLevelsA(I) + CSA(R)/blockFactor(R))

Ejemplo de estimación de coste para una operación de selección

Para lograr el propósito de este ejemplo, se dan los siguientes supuestos referentes a la
relación Emp descrita anteriormente en el esquema de la base de datos COMPANY.

 Hay un índice hash  sobre el atributo de clave principal empId.

 Hay un índice de agrupamiento sobre el atributo de clave externa deptId.

 Hay un índice árbol B+ sobre el atributo salary.

 La relación Emp  tiene las siguientes estadísticas almacenadas en el catálogo del

sistema:
nTuples(Emp) = 3000

blockFactor(Emp) = 30) ⇒ nBlocks(Emp) = 100

nDistinctjobId(Emp) = 50) ⇒ CSjobId(Emp) = 60

nDistinctfirstName(Emp) = 3000) ⇒ CSfirstName(Emp) = 1

nDistinctsalary(Emp) = 500) ⇒ CSsalary(Emp) = 6
minsalary(Emp) = 10.000
maxsalary(Emp) = 50.000
nLevelsjobId(I) = 2
nLevelssalary(I) = 2
nLfBlockssalary(I) = 50

El coste estimado de una búsqueda lineal sobre el atributo deptId  es de 50 bloques y el coste de

una búsqueda lineal sobre un atributo no clave es de 100 bloques.

Se calcula el coste estimado para las siguientes operaciones:

1) σ(empId=′T450′)(Emp): la operación de selección contiene una condición de igualdad sobre la clave
principal. El atributo empId está almacenado mediante un método hash, por lo tanto el coste
estimado será de un bloque (CE = 1) y la cardinalidad estimada de la relación resultante será:

CSempId(Emp) = 1

2) σ(firstName=′Smith′)(Emp): el atributo es no clave y no indexado, por lo que no se puede mejorar el

método de búsqueda lineal. El coste estimado obtenido será de CE = 100. La cardinalidad
estimada se ha calculado previamente:

CSfirstName(Emp) = nTuples(Emp) / nDistinctfirstName(Emp) = 3.000 / 3.000 = 1.

3) σ(jobId=′prog′)(Emp): el atributo del predicado es una clave externa con un índice de clustering, por
lo tanto el coste será CE = 2 + [60/30] = 4 bloques. La cardinalidad estimada será:

CSdeptIp(Emp) = 60

4) σ(salary>20.000)(Emp). El predicado implica una búsqueda dentro del rango del atributo salary que
tiene un índice árbol B+, por lo que para calcular el coste estimado se realizará el cálculo CE = 2
+ [50/2] + [3.000/2] = 1.527. La cardinalidad estimada será:

CSsalary>20.000(Emp) = [3.000 · (50.000 – 20.000)/(50.000 – 10.000)] = 2.250

7) Condición de igualdad en un índice secundario sin agrupamiento: si en el predicado

aparece una condición de igualdad para el atributo A, que no es clave principal, pero es un índice
secundario de tipo B+– tree sin agrupamiento, entonces las tuplas se ubican en diferentes
bloques. En este caso, el coste estimado sería:

CE=nLevelsA(I) + SCA(R)

8) Condición de desigualdad en un índice secundario de tipo B+–tree: si el predicado

implica una condición de desigualdad para el atributo A y este fuera un índice secundario de tipo
B+–tree, entonces, a partir de los nodos hoja del árbol, se puede realizar la exploración del nodo
más pequeño hasta el valor x, en el caso de que las condiciones de desigualdad
fuesen A<x o A<=x, o de otro modo, desde x hasta el valor máximo, en los casos A>x o A>=x.

Considerando una distribución uniforme, se puede estimar un acceso a la mitad de los bloques y
a la mitad de las tuplas, el coste estimado sería:

CE = nLevelsA(I) + nLfBlocksA(I)/2 + nTuples(R)/2

Con lo que queda explicado el cálculo del punto 4; σ( salary>2000)(Emp); CE=2+50/2+3000/2.

B+ tree

Un árbol B+ es un tipo de estructura de datos en forma de árbol donde toda la información se guarda

en las hojas, ya que los nodos internos solo contienen claves y punteros. De este modo, se pueden

crear índices multinivel y dinámicos, con un límite máximo y mínimo en el número de claves por nodo.

1.4.3.Operación de ordenación
Muchas veces resulta necesario ordenar los datos de una tabla, ya sea porque se desea el
resultado ordenado o porque se utiliza para implementar una operación de combinación de
forma más eficiente.

La ordenación se puede conseguir creando un índice sobre el atributo objeto de la ordenación y

utilizándolo para realizar una lectura ordenada. No obstante, hay que tener en cuenta que esta
ordenación se efectúa en el nivel lógico, pues físicamente se puede traducir en un acceso a disco
para cada tupla más la transferencia del bloque correspondiente. Esto puede ser muy costoso,
ya que el número de registros suele ser superior al número de bloques, dado que las tuplas no
tienen por qué estar almacenadas físicamente de manera consecutiva.
Quicksort

El ordenamiento rápido, quicksort en inglés, es un algoritmo basado en la técnica del “divide y

vencerás” que permite, de media, ordenar n elementos en un tiempo proporcional a n·log(n).

En el caso de que toda la relación se pueda almacenar en la memoria principal, se pueden

emplear técnicas de ordenación rápida, como el algoritmo quicksort.

Cuando la relación no cabe en la memoria, se suele utilizar el algoritmo de ordenación-fusión

externa. Consideremos que se dispone de M marcos de página en la memoria intermedia de la
memoria principal. Esta operación consta de dos fases:

En la primera fase, el algoritmo divide la relación en N = [nBlocks(R)/M] partes, las carga
sucesivamente en la memoria para ordenar cada una de ellas y crear un archivo de
secuencias Si.

En la segunda etapa, y en caso de que el número de secuencias N sea inferior a M:

1) En el primer bloque de cada archivo de secuencia, se lee la primera tupla de cada bloque,
para proceder a la fusión ordenada de los primeros bloques de cada secuencia.

2) En caso de que el contenido del bloque se haya agotado, se lee el siguiente bloque del mismo
archivo de secuencias hasta agotar todos los bloques de cada secuencia, lo cual implicará que se
ha obtenido la ordenación.

3) En el caso de que el número de secuencias N todavía sea superior a M, se fusionan las M – 1
primeras secuencias para formar otra secuencia ordenada. En este punto, se ha reducido el
número de secuencias en M – 1.

4) En caso de que el número de secuencias sea menor que M, entonces se puede proceder a la
fusión definitiva. En caso contrario, se repite el procedimiento con otras M – 1 secuencias hasta
obtener un número de secuencias menor que M.

El coste total de este algoritmo es tal como se indica a continuación.

El número inicial de secuencias es N = [nBlocks(R)/M]. Debido a que este decrece en un

factor M – 1 en cada ciclo de fusión, el número total de ciclos requeridos será de log M–1 ·
[nBlocks(R)/M]. En cada ciclo se leen y se escriben los bloques de la relación una sola vez, por lo
que el número de transferencias de bloque será nBlocks(R)[logM–1[(nBlocks(R)/M] + 1]. También
es necesario añadir los costes de búsqueda en disco. Durante la fase de fusión, si se leen
simultáneamente nBlocks[S] de cada secuencia, entonces cada paso implica como
mínimo nBlocks(R) = nBlocks(S) búsquedas para la lectura de datos. También hay que tener en
cuenta que, aunque la salida se escriba secuencialmente, el cabezal puede haberse desplazado,
por lo que habrá que añadir 2[nBlocks(R)/nBlocks(S)] búsquedas por cada paso, excepto en el
paso final.

Así pues, el coste estimado será:

CE = 2[nBlocks(R)/nBlocks(S)] +
+ [nBlocks(R)/nBlocks(S)](2[logM–1[(nBlocks(R)/M] – 1])

Marcos de página

Consideramos que el número de marcos de página, M, es el número de bloques de disco que se

pueden almacenar en la memoria intermedia de la memoria principal.

1.4.4.Operación de proyección
Una proyección implica dos operaciones: eliminar los atributos no deseados y eliminar, si es
preciso, las tuplas repetidas que se han generado con la cláusula DISTINCT.
Se puede implementar fácilmente la eliminación de duplicados empleando la ordenación de las
tuplas y utilizando como clave de ordenación los atributos resultantes de la proyección. Las
tuplas idénticas aparecen contiguas durante la operación de ordenación y, por lo tanto, se
pueden eliminar todas menos una. El coste estimado en el peor de los casos es el mismo que el
coste estimado en el peor de los casos en la operación de ordenación.

Observación

Si dentro de la lista de atributos de la proyección se incluyen todos los que forman la clave primaria,

no se producirán duplicados.

1.4.5.Operación de combinación
Las operaciones de combinación, aparte de las del producto cartesiano, suelen ser las que
consumen más tiempo durante el procesamiento de consultas, por lo que marcarán de manera
importante la eficiencia global del SGBD.

Los algoritmos más importantes son: la combinación de ciclo anidado, la combinación de ciclo
anidado indexado, la combinación por ordenación por fusión, la combinación por función
resumen y la combinación por agrupación (clúster).

Combinación de ciclo anidado

La combinación de ciclo anidado (2) consiste en dos ciclos anidados: el bucle externo recorre todas
las tuplas de la primera relación R y el bucle interno recorre todas las tuplas de la relación S. El
coste estimado para esta solución es:

CE  = nBlocks(R) + nBlocks(R) · nBlocks(S)

Podemos apreciar claramente que, para reducir el coste, es preciso que la primera relación que
se utiliza en el bucle externo ocupe el menor número posible de bloques.

En inglés, nested loop join.

(2) 

Una mejora consiste en leer tantos bloques como sea posible de la relación más pequeña, y
reservar un bloque para la relación interna y otro para la relación resultante. Si la memoria
intermedia (3) permite almacenar un número de bloques, nBuffer, entonces se leen (nBuffer  – 2)
bloques de R y un bloque de S cada vez. Con esta técnica, la estimación del coste sería:

CE = nBlocks(R) + nBlocks(S) · nBlocks(R)/(nBuffer – 2)

También deberíamos considerar si la memoria es suficiente para que se puedan leer de la

memoria intermedia de la base de datos después de la primera lectura todos los bloques de R.
En este caso, la estimación del coste sería:

CE = nBlocks(R) + nBlocks(S)

En inglés, buffer.
(3) 

Combinación de ciclo anidado indexado

El coste de la combinación de ciclo anidado indexado  (4) varía según el método de indexación que
se utilice. Si existe un índice o función resumen  (5) sobre los atributos de combinación de la
relación interna, entonces en el bucle interior no se efectúa un recorrido por todas las páginas de
la tabla, sino que se va directamente, mediante el índice o la función resumen, a la página
adecuada.

Si se tiene un índice árbol B+ sobre el atributo A, para encontrar el coste de la consulta, será
necesario conocer: nLevelsA(I), el número de niveles del árbol B+ del índice I sobre el atributo A;
y CSA(R), la cardinalidad de selección del atributo A de la tabla R y del número de filas que caben
en una página blockFactor(R). Si se trata de un índice sobre una clave candidata de R, el coste
será:

CE  = nBlocks(R) + nTuples(R) · (nLevelsA(I) + 1)

Si el atributo es un índice de agrupación, entonces la estimación del coste será:

CE  = nBlocks(R) + nTuples(R) · (nLevelsA(I) + [CSA(R)/blockFactor(R)])

En inglés, index nested loop join.

(4) 

En inglés, hash function.
(5) 

Combinación por ordenación por fusión

En una combinación por ordenación por fusión  (6) , la combinación más eficiente se logra cuando
las relaciones están ordenadas según los atributos de combinación. De no ser así, se requerirá
un paso previo para ordenarlas. Una vez ordenadas, solo hay que leer secuencialmente cada una
de las tablas y añadir a los resultados aquellos valores que coinciden. Si asumimos que la
combinación es de tipo muchos a muchos, es decir, que hay diferentes tuplas de R y de S con el
mismo valor de combinación, y también asumimos que cada conjunto de tuplas con el mismo
valor puede caber en la memoria intermedia, entonces solo habrá que leer cada bloque de la
relación una única vez. Así, la estimación del coste sería:

CE = nBlocks(R) + nBlocks(S)

Si es necesario ordenar una de las relaciones, entonces hay que añadir el coste de ordenación:

CE = nBlocks(R) + nBlocks(S) · log2(nBlocks(S))

teniendo en cuenta que se redondea por exceso el cálculo de cada logaritmo.

En inglés, sort-merge join.
(6) 

Combinación por función resumen

El algoritmo de combinación por función resumen  (7) se basa en emplear una función resumen
(hash) que presente características de uniformidad y aleatoriedad para dividir las filas de las dos
tablas en conjuntos que tengan el mismo valor de la función resumen. Después se realiza la
combinación de las filas de cada partición.

El coste de la combinación por función resumen es:

 CE = 3 · (nBlocks(R) + nBlocks(S)), si el índice hash se almacena en memoria y no se

tienen en cuenta los desbordamientos.

 CE = 2 · (nBlocks(R) + nBlocks(S)) · [lognBuffer–1(nBlocks(S)) – 1] + nBlocks(R)

+ nBlocks(S), en otro caso.

Ejemplo de estimación de coste para una operación de combinación

Para lograr el propósito de este ejemplo, se dan los siguientes supuestos referentes a las
relaciones Emp y Jobs.

 Existe hash sin desbordamiento sobre el atributo de clave principal depId.

 Existen unos cien bloques de memoria intermedia de la base de datos.

  Tenemos las siguientes estadísticas almacenadas en el catálogo del sistema:

nTuples(Emp) = 3.000
blockFactor(Emp) = 30) ⇒ nBlocks(Emp) = 100
nTuples(Jobs) = 50
blockFactor(Jobs) = 10) ⇒ nBlocks(Jobs) = 5

Se quiere evaluar el coste de las diferentes estrategias para la combinación siguiente:

(Emp ⋈ Emp.jobId=Jobs.jobIdJobs)

1) La combinación de ciclo anidado:

 La memoria intermedia sólo contiene un bloque de Emp y Jobs:

CE  = nBlocks(Emp) + nBlocks(Emp) · nBlocks(Jobs) = 100 + 100 · 5 = 600

 El número de bloques que se tratarán por Emp es (nBuffer – 2):

CE = nBlocks(Emp) + nBlocks(Jobs) · nBlocks(Emp)/(nBuffer – 2) =

= 100 + 100 · 5/98 = 106

 Todos los bloques de la relación Emp  caben en la memoria intermedia:

CE = nBlocks(Emp) + nBlocks(Jobs) = 100 + 5 = 105

2) La combinación de ciclo anidado indexado:

nTuples(Emp) + nBlocks(Emp) = 3.000 + 100 = 3.100

3) La combinación de ordenación por fusión:

 Tuplas desordenadas:

CE  = nBlocks(Emp) + nBlocks(Jobs) + nBlocks(Emp) · log2(nBlocks(Emp) +

+ nBlocks(Jobs) · log2(nBlocks(Jobs)) = 100 + 5 + 100 · 7 + 5 · 3 = 820

 Tuplas ordenadas:

CE = nBlocks(Emp) + nBlocks(Jobs) = 100 + 5 = 105

4) La combinación por función resumen. Si el índice hash cabe en la memoria:

CE  = 3 · (nBlocks(Emp) + nBlocks(Jobs)) = 3 · (100 + 5) = 315

En inglés, hash join.
(7) 

Funciones resumen

Una función resumen es un algoritmo u operación que permite obtener un sumario o resumen a partir

de un conjunto de datos. Este sumario o resumen está asociado a los datos originales, y cualquier

cambio en los datos originales tiene que repercutir en el sumario o resumen.

1.4.6.Operaciones de conjuntos de álgebra relacional

Las operaciones de unión R ∪ S, intersección R ∩ S y diferencia R – S se pueden implementar
ordenando primero las dos relaciones según un mismo criterio y después produciendo el
resultado.

Los resultados para cada operación se calculan de la siguiente manera:

 Cuando se realiza la unión de R y S (R  ∪  S), se realiza una lectura concurrente de las
tuplas de las dos relaciones, y si se detecta la misma tupla en ambas, se elimina el
duplicado.

 Cuando se realiza la intersección de R y S (R ∩ S), sólo se almacenan las tuplas que

aparezcan como duplicados en ambas relaciones.

 Cuando se realiza la diferencia R  –  S, se almacenan las tuplas de R que no aparezcan

en S.

Todo esto tendría un coste CE = nBlocks(R) + nBlocks(S), más el coste de la ordenación

de R y S.

1.4.7.Agregación
Cualquier operación de agrupación se puede implementar de una manera parecida a la
eliminación de duplicados, pero en lugar de eliminar las tuplas que tienen el mismo valor, se
reúnen por grupos y se aplica la operación correspondiente para obtener el resultado.

Operaciones de agrupación

Son operaciones de agrupación las funciones min, max, sum, count y avg.

1.5.Optimización física
El optimizador físico de consultas es el componente del SGBD que prepara los planes de
ejecución de las consultas para que se lleven a cabo en el mínimo tiempo. Hay varias
posibilidades para conseguirlo:

 que el coste de CPU sea mínimo;

 que la necesidad de memoria sea mínima;

 que se minimicen los accesos a disco, y

 otras posibilidades.
Los algoritmos de optimización física se pueden clasificar en dos grandes familias:

1) Optimización heurística: También conocida como optimización basada en reglas,

consiste en escoger un plan físico de ejecución con aquellos algoritmos que normalmente son
más eficientes.

2) Optimización basada en costes: Consiste en encontrar todas las implementaciones físicas

una vez se dispone de todo el espacio de posibles realizaciones de la consulta. Para cada plan se
calcula el coste (tiempo, número de accesos a disco, etc.) y, finalmente, se escoge el de coste
más bajo.

Los SGBD comerciales acostumbran a permitir escoger un tipo de implementación u otro,

aunque la tendencia es ofrecer solo optimización basada en costes, puesto que aunque la
heurística es muy rápida de calcular, puede escoger planes de ejecución muy poco eficientes.
Soluciones comerciales optimizadas

Si aumentamos la memoria de nuestro servidor, conseguiremos que muchos de los procesos de

combinación se puedan hacer completamente en la memoria. Habrán cambiado todos los tiempos de

ejecución, mientras que los planes de ejecución se mantendrán.

1.5.1.Optimización heurística
Para poder realizar una optimización heurística, es preciso que el SGBD tenga definido un orden
de eficiencia para las diferentes operaciones lógicas y pueda escoger aquel que suele tener un
coste más bajo.

Como la mayoría de las opciones de diseño, la optimización heurística tiene virtudes y defectos:
su principal virtud es que no hay que efectuar ningún tipo de cálculo, la obtención de un buen
plan de ejecución se realiza de manera inmediata; y el principal defecto es que a veces los
planes propuestos pueden diferir mucho de los óptimos.

En una base de datos compleja, una consulta puede involucrar varias tablas, cada una con
varios índices y condiciones de selección complejas. Esta complejidad significa que podría haber
una gran cantidad de opciones resultantes, y el sencillo conjunto de reglas utilizadas por el
optimizador basado en reglas no podría diferenciar lo suficientemente bien las elecciones como
para asegurar la mejor elección.

Otra de las debilidades del optimizador basado en reglas es la resolución de las opciones de
optimización en caso de obtener dos o más planes de ejecución con el mismo coste. En este
caso, el optimizador considera la sintaxis de la sentencia SQL para resolver el empate. La ruta
de ejecución ganadora se basa en el orden en que las tablas se presentan en la sentencia SQL.

1.5.2.Optimización basada en costes

Este método selecciona la ruta de ejecución que requiere el menor número de operaciones
lógicas de E/S. Con esta finalidad se utilizan estadísticas que se consideran relevantes, recogidas
sobre la composición de las estructuras de datos proporcionados. De este modo, el optimizador
basado en costes puede conocer qué tabla es la más grande y puede seleccionarla como la tabla
de la derecha para iniciar la consulta, independientemente de la sintaxis de la sentencia SQL. Así
reduce el número de iteraciones y, si se tercia, el número de accesos a disco.

Ejemplo de reducción del número de iteraciones

Se puede entender el impacto potencial sobre la elección del orden en las tablas observando una
situación sencilla en la que se hace una combinación de una tabla pequeña con diez
registros, SmallTable, con una tabla con diez mil, LargeTable.

1. SELECT *
2. FROM SmallTable s, LargeTable l
3. WHERE s.id = l.id;

La sentencia anterior obtendría un resultado equivalente a esta otra:

1. SELECT *
2. FROM LargeTable l, SmallTable s
3. WHERE l.id = s.id;
El tamaño de las tablas y el orden en que éstas se leen tiene repercusión en el tiempo de
ejecución de la consulta:

 Si el optimizador elige para leer SmallTable  en primer lugar, el SGBD lee las diez filas y
después LargeTable diez veces para encontrar las filas coincidentes de cada una de
las diez filas.

 Si el optimizador elige LargeTable en primer lugar, el SGBD tiene que leer las diez mil
filas de LargeTable y después las de SmallTable diez mil veces para encontrar los
registros coincidentes.

Además, en el primer caso, las filas de SmallTable probablemente se podrían almacenar en

memoria caché, lo que reduciría el impacto de lecturas de disco.

Independientemente del orden en que aparecen las tablas en la sentencia SQL, gracias a la
información obtenida a partir de las estadísticas, el optimizador escogerá la tabla más grande
como si esta apareciera la última en la sentencia, es decir, más a la derecha.

A partir de las estadísticas, se seleccionan los operadores físicos y se determina la estrategia de

ejecución.

Las estadísticas y los histogramas

Las estadísticas registran la distribución de los datos y las características de almacenamiento
de las tablas, columnas, índices y particiones a partir de los cuales el optimizador estima la
cantidad de accesos a disco y memoria necesaria para ejecutar un plano físico particular.

Los parámetros estadísticos que los SGBD almacenan más a menudo son los siguientes:

1) Tabla: número de filas, número de páginas, número de páginas vacías, longitud media de
una fila.

2) Columna: número de valores diferentes en la columna, número de valores NULL en la

columna, histograma de frecuencia de aparición de cada uno de los valores.

3) Índice: número de páginas, niveles, factor de agrupamiento.

En el SGBD comercial Oracle, se puede emplear el paquete PL/SQL DBMS_STATS para generar y
gestionar las estadísticas de las tablas, columnas, índices, particiones y otros objetos de la base
de datos.

Generar y gestionar estadísticas

Por ejemplo, podemos recopilar estadísticas para el esquema ‘COMPANY’  utilizando la siguiente
instrucción SQL, donde también se especifica en el segundo parámetro que calcule
automáticamente el alcance del tamaño de la muestra.

1. EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('COMPANY',
2. DBMS_STATS.AUTO_SAMPLE_SIZE);

Ved también

Algunos de los parámetros que almacenan los estadísticos se ven en el subapartado 1.4.1. de este

módulo didáctico.

Disponemos de diferentes opciones a la hora de recopilar estadísticas que permiten especificar

el tipo de muestreo:
  muestreo basado en filas, de forma que se ignora la ubicación física en disco; y

 muestreo basado en bloques, de modo que se escoge una muestra aleatoria de

bloques y las estadísticas se generan a partir de los datos almacenados en ellos.

Generalmente, un muestreo utiliza menos recursos que si se calcula el valor exacto de la

estructura completa.

Las estadísticas se almacenan en el diccionario de datos.

Un histograma es una estructura de datos que se puede utilizar para mejorar las estimaciones
de las que puede disponer el optimizador.

Reflexión

También se puede hacer que Oracle recopile las estadísticas al crear o reconstruir índices

especificando la opción COMPUTE STATISTICS en las sentencias CREATE INDEX o ALTER INDEX.

Un histograma recoge un conjunto de valores junto con sus frecuencias relativas, y proporciona
al optimizador las mejores estimaciones en presencia de una distribución uniforme. Existen
dos tipos de histogramas:

 Histograma equilibrado de ancho, que divide los datos en un número fijo de rangos
con el mismo ancho y para cada uno de ellos se realiza el cálculo del número de
valores que les pertenece.

 Histograma equilibrado de altura, donde se determinan los rangos una vez

distribuidos equinuméricamente los valores y se generan rangos de diferente ancho
pero con un mismo valor de frecuencia relativa.

Reflexión

En Oracle, es el usuario quien crea y mantiene los histogramas para las columnas apropiadas

empleando el paquete PL/SQL DBMS_STATS.

Operadores físicos y estrategias de ejecución

El término operador físico se utiliza para referenciar a un algoritmo específico que implementa la
operación lógica de la base de datos. Por ejemplo, se puede escoger el operador físico de
combinación mediante un bucle anidado indexado con encarrilamiento  (8) .

Sustituir las operaciones lógicas en un árbol de álgebra relacional por operadores físicos produce
una estrategia de ejecución, plan de evaluación de la consulta o plan de acceso para la
consulta.

Consideremos la consulta de ejemplo del subapartado 1.1.1.:

Aunque los diferentes SGBD tienen distintas implementaciones para los diferentes operadores
físicos, podemos considerar varios operadores abstractos para implementar las funciones
especificadas en cada nodo del árbol:

1) tableScan(R): exploración de la tabla. Los diferentes bloques de R se leen en un orden

arbitrario.

2) sortScan(R, L): exploración ordenada. Las tuplas de R se leen por orden de acuerdo con los
criterios de ordenación especificados en la lista de atributos L.

3) indexScan(R, P): exploración indexada. El predicado P especifica una comparación entre el

valor del atributo A y un valor c. Se accede a las tablas mediante un índice sobre el atributo A.

4) indexScan(R, A): exploración indexada. A es un atributo de R. Se extrae la

relación R completa empleando un índice sobre el atributo A.

Además, la estrategia de ejecución soporta una interfaz iteradora uniforme que permite ocultar
los detalles de implementación de cada operador:

1) open: inicia el estado del iterador antes de extraer la primera tupla y asigna un espacio de
memoria intermedia para las entradas y salidas. Se pueden indicar varios parámetros que
permitan definir condiciones de selección de forma que modifiquen el comportamiento del
operador.

2) getNext: devuelve la siguiente tupla del resultado y la coloca en la memoria intermedia de

salida. El estado del iterador se actualiza para reflejar las acciones que ya se han realizado.

3) close: una vez finalizado el proceso de iteración, es decir, una vez generadas todas las
salidas solicitadas, el operador realiza las operaciones de limpieza y desasigna espacio de
memoria.

Al definir este tipo de operadores, el sistema puede implementar de manera natural el concepto
de encarrilamiento o de materializar los valores intermedios.

1) Materialización: con este enfoque se inicia la evaluación para las operaciones de nivel más
bajo a partir del árbol de operadores. Se ejecutan las operaciones con los algoritmos estudiados
y después se almacenan los resultados en relaciones temporales. Así pues, el coste de toda la
expresión es la suma de los costes de cada una de las operaciones más el coste de los
resultados intermedios en disco.
 En inglés, pipelining.
(8) 

Encarrilamiento

El encarrilamiento, o pipelining, como se ve más adelante, es una técnica que consiste en aprovechar

la salida de una operación como entrada de la siguiente con el objetivo de incrementar la eficiencia de

las operaciones, ya que ahorra el coste de lectura/escritura de las relaciones intermedias.

2) Encarrilamiento: consiste en aprovechar la salida de una operación como entrada de la

siguiente; de este modo nos ahorramos el coste de lectura/escritura de las relaciones
intermedias. Para cada operación del encarrilamiento se modeliza un proceso aislado  (9) que toma
un flujo de tuplas de sus entradas y produce otro para su salida. Para esto es necesario definir
en cada operación una memoria intermedia para la entrada y otra para la salida. Con el
encarrilamiento también se puede conseguir que varias operaciones se ejecuten en paralelo, de
forma que se gana velocidad a cambio de una mayor necesidad de memoria para llevar a cabo
los diferentes procesos.

En inglés, thread.
(9) 

Visualización del plan de ejecución

Oracle permite visualizar el plan de ejecución que escogerá el optimizador mediante la

sentencia EXPLAIN PLAN.

Esta sentencia resulta bastante útil cuando se desea analizar por qué la eficiencia de una
consulta no es la esperada. La salida de esta sentencia se escribe de manera predeterminada en
la tabla PLAN_TABLE.

Ved también

Podéis consultar la sintaxis y funcionalidad de la sentencia EXPLAIN PLAN en la documentación de

Oracle.

2.Procesamiento de vistas
Desde un punto de vista teórico, una vista se puede definir como el resultado dinámico de una o
más operaciones relacionales sobre tablas para producir una relación nueva.

Las vistas son relaciones virtuales que sólo están representadas por su nombre y su definición;
no existen físicamente en la base de datos. Sólo sirven a partir del momento en que el usuario
las utiliza.

La sintaxis de creación de vistas según el estándar SQL:2011 es la siguiente:

1. CREATE VIEW ViewName [(column_name), ... ]

2. AS query
3. [WITH [CASCADED|LOCAL]CHECK OPTION ]

El estándar SQL
Desde que el lenguaje SQL fue aceptado como un estándar, en primer lugar por el ANSI en 1986 y

después por la ISO en 1987, se han ido añadiendo nuevas funcionalidades y características, que se

han recogido en las diferentes versiones, documentadas en la referencia ISO/IEC 9075.

La cláusula WITH CHECK OPTION asegura que nunca podremos actuar sobre partes de una tabla
que no están a la vista. Si se incluye la cláusula LOCAL, se valida la integridad de la vista para
aquellas operaciones de inserción o actualización que se efectúen, mientras que si se utiliza la
cláusula CASCADED, también se valida la integridad de todas las otras vistas que dependen de
ella.

Ejemplos de creación de vistas

Si se tiene en cuenta la base de datos COMPANY definida anteriormente, algunas definiciones de

vistas son las siguientes:

1. CREATE VIEW View01 AS

2. SELECT firstName, lastName, hireDate, salary
3. FROM Emp e
4. WHERE salary < 30000;
5.  
6. CREATE VIEW View02 AS
7. SELECT firstName, lastName, deptName
8. FROM Emp e, Dept d
9. WHERE e.deptId = d.deptId;
10.  
11. CREATE VIEW View03 AS
12. SELECT *
13. FROM View02
14. WHERE (firstName, lastName) IN
15. (SELECT firstName, lastName
16. FROM View01);

De manera opcional, se puede asignar un nombre a las diferentes columnas de la vista. En caso
contrario, las columnas tomarán el mismo nombre que tienen en la subconsulta. Si la
subconsulta incluye columnas calculadas o funciones, será imprescindible definirles un nombre.

Fijaos en que, tal como se puede ver en el tercer ejemplo, en la subconsulta de una vista puede
aparecer otra vista.

Por otro lado, ¿que pasaría si se realizara la siguiente actualización?:

1. UPDATE View01
2. SET salary = 45000
3. WHERE salary = 29000;

Se daría el caso inverosímil de que se ocultaría una fila a la vista. Una situación parecida se
daría si se realizara la siguiente inserción:
 1. INSERT INTO View01
2. VALUES (';John';, ';Smith';, ';12/3/2012';, 50000);

Si la vista se hubiera creado con la cláusula WITH CHECK OPTION, las operaciones se habrían
comprobado antes para asegurar que las nuevas filas insertadas o actualizadas cumpliesen la
condición de la vista.

Aunque una vista no ocupa mucho lugar en la base de datos, recordad que sólo se trata de una
definición y que también se puede destruir.

Según el estándar SQL:2011, la sintaxis de eliminación de vistas es la siguiente:

1. DROP VIEW View_Name [CASCADE|RESTRICT]

La cláusula opcional CASCADE destruirá todos los objetos creados a partir de esta vista. En

cambio, si se usa la cláusula RESTRICT, se impedirá la eliminación de la vista si existen otros
objetos que dependen de ella.

Ejemplo de destrucción de una vista

Con la sentencia siguiente destruiremos la primera de las vistas creada en el ejemplo anterior:

1. DROP VIEW View01 CASCADE;

Al ejecutar esta sentencia, además de eliminar la vista View01, también se elimina la

vista View03, ya que en su definición se utiliza View01. En caso de haber empleado la
cláusula RESTRICT, no se habría eliminado ninguna de las dos vistas por esta dependencia.

2.1.Mecanismos de implementación de vistas

Existen dos estrategias fundamentales para implementar las vistas: reescribir la consulta o
materializar la vista.

La estrategia de reescritura es la más utilizada por el SGBD. Según esta estrategia, la

consulta se reescribe de forma que referencie las tablas de la base de datos.

Ejemplo de implementación de vistas por reescritura

Considerad la base de datos definida por el diagrama relacional de la base de datos COMPANY y

las vistas siguientes:

1. CREATE VIEW DeptSummaryView(department, salary, employees) AS

2. SELECT d.deptName, AVG(e.salary), COUNT(*)
3. FROM Emp e, Dept d, Jobs j
4. WHERE e.deptId = d.deptId
5. AND e.jobId = j.jobId
6. AND j.jobName NOT IN (';President';, ';Manager';)
7. GROUP BY d.deptName;

Una consulta como la que presentamos a continuación:

 1. SELECT department, salary
2. FROM DeptSummaryView
3. WHERE employees > 4;

se convertiría en lo siguiente:

1. SELECT d.deptName, AVG(e.salary)

2. FROM Emp e, Dept d, Jobs j
3. WHERE e.deptId = d.deptId
4. AND e.jobId = j.jobId
5. AND j.jobName NOT IN (';President';, ';Manager';)
6. GROUP BY d.deptName
7. HAVING COUNT(*) > 4;

La consulta que realmente se ejecuta con esta estrategia es mucho más compleja que la que se
plantea inicialmente, y esta complejidad hará que las consultas requieran mucho tiempo de
ejecución. El colmo de la ineficiencia se da cuando hay que hacer varias consultas seguidas
sobre una misma vista. También puede ser difícil la conversión en caso de consultas muy
complejas.

Reescritura o cálculo inline

La estrategia de implementación de vistas por reescritura también se conoce con el nombre de cálculo

bajo mandato  o, en inglés, inline.

Con la segunda estrategia, llamada materialización de la vista, cuando se hace la consulta se

crea una tabla temporal con el contenido físico de la vista.

Ejemplo de implementación de vistas por materialización

Si se aplicara la estrategia de materialización de vistas en el ejemplo anterior, se crearía la tabla

temporal DeptSummaryView  con los datos del resultado de la vista y las consultas se harían
físicamente sobre esta tabla.

Según esta estrategia, el caso de mínima eficiencia que presentaba la primera estrategia se
transformaría en máxima eficiencia, dado que sólo tendría que calcular la tabla una única vez.

En contraste con esta ventaja, la estrategia de materialización de la vista presenta un

inconveniente: si las tablas básicas a partir de las cuales se construye la vista varían de
contenido, habrá que modificar la tabla temporal (actualización incremental). Esto puede
resultar bastante costoso, sobre todo para algunos casos de funciones agregadas o en las que
aparezcan cláusulas GROUP BY.

Cabría esperar de un buen SGBD que utilizara la primera estrategia para las consultas sobres
vistas simples y la segunda para las complejas.

Duración de las vistas

Si durante un periodo de tiempo la vista no se consulta, el propio sistema la destruye y la vuelve a

construir de nuevo, si hace falta, en otro momento.

2.2.Actualización de vistas
Las vistas siempre se pueden consultar, pero no siempre se pueden actualizar. Consideremos,
por ejemplo, una tabla con los datos de los empleados y una vista con el nombre del
departamento al que están asignados y el salario medio del departamento. ¿Qué significado
tendría aumentar un 10% la media de los salarios de un departamento? Este aumento se puede
conseguir de muchas formas, subiendo y bajando los salarios de los diferentes miembros del
departamento. Por lo tanto, estamos ante una ambigüedad.

De una manera más formal, sea D una base de datos y V, una vista que se construye con la
función V = F(D). Si se hace una operación de actualización A sobre la vista A(V) = A(F(D)),
habrá que encontrar una operación de actualización A’ tal que A(V) = F(A’(V)). En muchos casos
habrá muchas operaciones A’  que cumplirán la igualdad anterior, aunque dejarán la base de
datos en un estado diferente.

Solo es posible asegurar que una vista será actualizable si está construida sobre una única tabla
y sus atributos contienen una clave candidata de la tabla original. Las vistas definidas sobre más
de una tabla acostumbran a no ser actualizables. Las vistas que incluyen cláusulas GROUP BY o
funciones agregadas nunca son actualizables.

Reflexión

Cualquier operación de actualización sobre una vista deberá respetar las restricciones de integridad

definidas en la tabla original.

El concepto actualizable  tiene una base semántica, no sintáctica; se pueden encontrar

definiciones de vistas que a priori parecen no actualizables, pero que sí lo son.

Expresiones actualizables equivalentes

La vista que presentamos a continuación parece no actualizable:

1. CREATE VIEW View04 AS

2. SELECT empId
3. FROM Emp
4. WHERE salary > 30000
5. UNION
6. SELECT empId
7. FROM Emp
8. WHERE deptId = 20

Pero sí que lo es, dado que es equivalente a esta otra:

1. SELECT empId
2. FROM Emp
3. WHERE salary > 30000 OR deptId = 20

Y esta expresión sí que es actualizable.

Ved también

Podéis consultar las consideraciones referentes a las vistas actualizables en el SGBD Oracle 11g en el

anexo.
2.2.1.Actualización con disparadores de sustitución
Existen varios mecanismos para romper las posibles ambigüedades en las acciones de
actualización sobre vistas, y se basan en el hecho de que se almacena el criterio de actualización
adecuado junto con la definición de la vista. El estándar SQL:2008 incorpora el uso de los
disparadores de sustitución (10) .

En inglés, triggers instead of.

(10) 

Los disparadores de sustitución son disparadores (11) que no se ejecutan ni antes ni después,

sino “en lugar de” la orden de modificación que se quiere realizar con la vista. Este tipo de
disparadores permiten efectuar acciones de inserción, eliminación y actualización sobre vistas
que no son actualizables. Solo se pueden definir sobre vistas.

Ejemplo de actualización de vistas con disparadores de sustitución

Consideremos el ejemplo clásico de implementación de vistas. Supongamos que se define la

vista siguiente:

1. CREATE VIEW DeptAvgSalaryView(department, salary) AS

2. SELECT d.deptName, AVG(e.salary)
3. FROM Emp e, Dept d
4. WHERE e.deptId = d.deptId
5. GROUP BY d.deptName

Como ya hemos planteado, esta vista es claramente no actualizable. Ahora bien, si

consideramos que la política de la organización es la de realizar incrementos de sueldo
proporcionales, un disparador que hiciera actualizable esta vista podría ser el siguiente (la
sintaxis utilizada es Oracle 11g):

1. CREATE TRIGGER updatingDeptAvgSalary

2. INSTEAD OF UPDATE ON DeptAvgSalaryView
3. DECLARE
4. v_increase NUMBER;
5. v_old_deptId Dept.deptId%TYPE;
6. BEGIN
7. IF :NEW.salary != 0 and :OLD.salary != 0 THEN
8. v_increase := :NEW.salary / :OLD.salary;
9. SELECT deptId INTO v_old_deptId
10. FROM Dept d
11. WHERE d.deptName = :OLD.department ;
12. UPDATE Emp SET salary = v_increase * salary
13. WHERE deptId = v_old_deptId
14. AND salary IS NOT NULL;
15. END IF ;
16. IF :NEW.department != :OLD.department THEN
17. UPDATE Dept SET deptName = :NEW.department
 18. WHERE Dept.deptName = :OLD.department;
19. END IF;
20. END updatingDeptAvgSalary;

En este ejemplo se puede observar que, para actualizar el salario a un valor nuevo, el salario de
cada empleado se incrementa de forma proporcional al incremento que tendría la media de
salarios de todos los trabajadores. Si la política de actualización de salarios de nuestra
organización es proporcional, la actualización funcionará. Del mismo modo, si se cambia el
nombre de un departamento, se cambiará en la tabla correspondiente.

Si la política de la organización es que cuando desaparece un departamento todos sus

empleados quedan a la espera de destino, dicho de otro modo, con el campo departamento en
nulo, el correspondiente disparador sería el siguiente:

1. CREATE TRIGGER deletingDeptAvgSalary

2. INSTEAD OF UPDATE ON DeptAvgSalaryView
3. DECLARE
4. v_deptId Emp.deptId%TYPE;
5. BEGIN
6. SELECT deptId INTO v_deptId
7. FROM Dept d
8. WHERE d.deptName = :OLD.department;
9.  
10. UPDATE Emp SET deptId = NULL
11. WHERE deptId = v_deptId;
12.  
13. DELETE FROM Dept
14. WHERE deptName = :OLD.department;
15.  
16. END deletingDeptAvgSalary;

El uso de este tipo de disparadores facilita el diseño interno y la encapsulación de la información.

En inglés, triggers.
(11) 

2.3.La vista como elemento de diseño externo

Siempre habría que diseñar las bases de datos teniendo en cuenta cómo son la organización o el
sistema, nunca la utilización que se hará de los datos, a menos que sea necesario por razones
de eficiencia. Una base de datos corporativa será utilizada por múltiples aplicativos, y a todos les
gustaría que la base de datos fuera diseñada según sus necesidades (por lo menos, a sus
diseñadores). La manera de conseguir este doble objetivo recibe el nombre de diseño externo.

El diseño externo consiste en crear una interfaz entre la base de datos y la aplicación.

En el siguiente esquema se puede ver una representación gráfica de esta situación:

Figura 2. Función del diseño externo en una base de datos corporativa

Una manera bastante sencilla y muy segura de implementar el diseño externo es usar una
colección de vistas con los respectivos disparadores de sustitución para cada una de las
aplicaciones cliente; de este modo, la complejidad del esquema conceptual de la base de datos
es transparente a las diferentes aplicaciones y estas se “hacen la ilusión” de que tienen una base
de datos diseñada a medida, en la cual toda la información se encuentra tal como les conviene.

Ejemplo de implementación de diseño externo con vistas

Podemos considerar una aplicación que podría tener asignada la vista DeptSummaryView en su

esquema, vista que hemos tratado en ejemplos anteriores, sin ningún tipo de disparador de
sustitución porque solo tendrá que hacer consultas.

También podemos tener otra aplicación que “verá” la base de datos como si solo hubiera la
tabla DeptAvgSalaryView, sobre la cual puede borrar y actualizar gracias a los disparadores de
sustitución implementados, pero no podrá realizar ninguna acción de inserción.

Así, se logra la independencia lógica de los datos, puesto que en caso de que el esquema
conceptual sea modificado, la visión que tienen de él las diferentes aplicaciones no debe verse
afectada.

En este apartado se utilizan la notación y las facilidades del SGBD comercial Oracle 11g.

Implementación del diseño externo

Para implementar el diseño externo, se podrán usar (según las posibilidades del SGBD) vistas,

consultas, vistas objeto, procedimientos, funciones, disparadores de sustitución, métodos, etc.

2.4.Las tablas derivadas

La mayor parte de los SGBD incorporan unas estructuras muy parecidas a las vistas, las tablas
derivadas, también conocidas como instantáneas (12) , agregados  o vistas materializadas.

Ejemplo de tabla derivada

En un supermercado, se podría tener una tabla de ventas, con la suma de las ventas de cada
sección. No haría falta insertar ninguna fila, sino que la tabla se actualizaría automáticamente a
medida que se fueran insertando filas.

En inglés, snapshots.
(12) 

Las vistas materializadas son tablas que, además de almacenar la definición de la vista, también
almacenan los datos calculados (o derivados) de la ejecución de la sentencia SELECT definida en
la vista. Esta tabla se puede definir con los mismos parámetros de almacenamiento que una
tabla normal, como por ejemplo el espacio de tablas o la utilización de índices.
Cuando una sentencia SQL o PL/SQL accede a una vista materializada, el SGBD se dirige
directamente a los datos de la vista que están almacenados en lugar de utilizar los datos de las
diferentes tablas empleados en la definición de la vista.

Es conveniente utilizar vistas materializadas cuando la definición de la vista hace referencia a

muchas tablas enlazadas de manera compleja, así como en las vistas que se utilizan con mucha
frecuencia, puesto que permiten mejorar el rendimiento al ejecutarse la sentencia SQL solo una
vez.

Por otro lado, hay que considerar si la vista materializada se reutilizará en el futuro. Esto
implicará actualizar su contenido, puesto que probablemente el contenido de las tablas base será
modificado.

A la hora de determinar si hay que definir una vista como materializada o no, es preciso valorar
los costes de ejecutar la sentencia SQL que define la vista frente a los costes de almacenamiento
y actualización de la vista materializada.

Para definir una vista materializada, el patrón de sentencia SQL es el siguiente:

Comparación entre vistas y tablas derivadas

Las vistas son simples definiciones que se utilizan cuando hace falta (para materializar o reescribir una

vista). En cambio, las tablas derivadas existen físicamente.

1. CREATE MATERIALIZED VIEW MaterializedViewName

2. [TABLESPACE tablespace_name]
3. [PARALELL (DEGREE n)]
4. [BUILD {IMMEDIATE|DEFERRED}]
5. [REFRESH {FAST|COMPLETE|FORCE|NEVER|ON COMMIT|ON DEMAND}]
6. [{ENABLE|DISABLE} QUERY REWRITE]
7. AS SELECT ... FROM ... WHERE ...

La cláusula BUILD permite elegir si en el momento de crear la vista, aparte de la creación de la

tabla que almacenará los resultados, ésta se informa o no. En la primera opción, hay que
usar INMEDIATE; en la segunda, DEFERRED, en cuyo caso los datos no informarán la tabla hasta
que se realice la primera actualización de la vista materializada.

La cláusula REFRESH permite indicar el mecanismo que utilizará el SGBD para actualizar la vista

materializada. El método de actualización que se escoja dependerá de la frecuencia de
actualización de las tablas base. Este puede ser:

 COMPLETE (’completo’): se recalcula toda la tabla derivada según la consulta que la

define.

 FAST (’rápido’): este método de actualización especifica un método de refresco

incremental; los cambios se efectuarán agregando los nuevos datos que se han
añadido a las tablas base.

 FORCE (’forzado’): aplica, si es posible, el refresco rápido, y si no es posible, el refresco

completo.

 NEVER (’nunca’): indica que la vista materializada nunca será refrescada.

La actualización se puede producir en dos momentos diferentes:
Reflexión

Hay que tener en cuenta que las vistas que usan funciones de

agregación SUM, AVG, MAX, MIN o COUNT no admiten la actualización FAST.

1) Actualización manual. Hay que definir la vista con la restricción ON DEMAND. El refresco se
produce cuando el usuario ejecuta manualmente algún proceso de actualización sobre la vista
materializada. Las actualizaciones manuales de las vistas materializadas se realizan utilizando el
paquete PL/SQL estándar DBMS_MVIEW.

El paquete PL/SQL DBMS_MVIEW

Este paquete incluye un conjunto de funciones y procedimientos que permiten gestionar las vistas

materializadas. Entre ellos podemos destacar:

 DBMS_MVIEW.REFRESH(‘MaterializedViewName’): actualiza una vista materializada a
partir de su nombre.

 DBMS_MVIEW.REFRESH_DEPENDENT(‘Table1, Table2, ...’): actualiza todas las vistas

materializadas que utilicen como tabla base alguna de las tablas o vistas indicadas en la
lista.

 DBMS_MVIEW.REFRESH_ALL_MVIEWS(n): actualiza todas las vistas materializadas

devolviendo un número (n) que indica la cantidad de registros que se han actualizado.

2) Actualización automática. Esta forma de actualización puede ser:

 ON COMMIT: el refresco se produce cuando la transacción que modifica alguna de las

tablas base se confirma. Esto significa que la ejecución del COMMIT tendrá un mayor
coste temporal, lo que puede afectar al rendimiento.

 Actualización programada: la actualización se programa para que suceda en un

determinado instante.

Ejemplo de actualización programada

Una vista se podría programar para que se actualice todos los días a una hora determinada
mediante el uso de las cláusulas START WITH y NEXT. La cláusula START WITH permite indicar
el momento de la primera actualización automática y NEXT indica el intervalo entre
actualizaciones automáticas.

1. CREATE MATERIALIZED VIEW NAME_VIEW

2. ...
3. REFRESH START WITH ROUND(SYSDATE + 1) + 5/24
4. NEXT NEXT_DAY(TRUNC(SYSDATE), ';SUNDAY';) + 15/24
5. AS SELECT ...;

Actualización con tablas derivadas

Consideremos el siguiente modelo relacional de la base de datos operativa de un supermercado:

ProductLine(idLine, description)
Products(productCode, productLine, description, priceEach),
{productLine} REFERENCES ProductLine(idLine)
Order(orderNumber, orderDate)
OrderDetail(orderNumber, orderLineNumber, productCode,
quantityOrdered), {orderNumber} REFERENCES Order(orderNumber)

La tabla derivada correspondiente a los ingresos realizados en los pedidos por línea de producto
se podría crear con la sentencia siguiente:

1. CREATE MATERIALIZED VIEW ProductLineIncomeMView

2. BUILD IMMEDIATE
3. REFRESH FAST ON DEMAND
4. ENABLE QUERY REWRITE
5. AS SELECT pl.description as description,
6. SUM(od.quantityOrdered * p.priceEach) as amount
7. FROM ProductLine pl, Products p, Order o, OrderDetail od
8. WHERE pl.idLine = p.productLine
9. AND p.productCode = od.productCode
10. GROUP BY pl.description;

La cláusula ENABLE/DISABLE QUERY REWRITE sirve para determinar si el optimizador de

consultas puede reescribir o no las sentencias SQL, de forma que, a ser posible, se utilice la
vista materializada en lugar de las tablas base empleando el mecanismo de reescritura. Esta
opción sólo está disponible cuando se utiliza el optimizador basado en costes, puesto que el
SGBD utiliza las estadísticas para determinar si la ejecución de la sentencia SQL o su reescritura
utilizando la vista materializada es la que tiene menor coste.

Mecanismos de reescritura de consultas

Siguiendo con la base de datos del supermercado del ejemplo anterior, imaginemos la consulta
siguiente:

1. SELECT pl.description, SUM(od.quantityOrdered * p.priceEach)

2. FROM ProductLine pl, Product sp, Order o, OrderDetail od
3. WHERE pl.idLine = p.productLine
4. AND p.productCode = od.productCode
5. AND pl.description IN (';vegetables';, ';meat';, ';drinks';)
6. GROUP BY pl.description;
7. HAVING SUM(od.quantityOrdered<i> * </i>p.priceEach) > 2500000.00;

El sistema podría aprovechar la vista materializada y reescribiría la consulta como:

1. SELECT description, amount

2. FROM ProductLineIncomeMView
3. WHERE description IN (';vegetables';, ';meat';, ';drinks';)
4. AND amount > 2500000.00;
Reflexión

Todos estos procedimientos y funciones admiten parámetros adicionales que se pueden consultar en

la documentación de Oracle 11g.

Las vistas materializadas siempre se calculan a partir de las tablas básicas y la única operación
que se puede hacer con ellas es la consulta; no tiene sentido hablar de actualización, borrado o
inserción. Dado que se acostumbran a usar para almacenar y precalcular datos agregados, a
menudo se denominan resúmenes.

Tablas derivadas en entornos distribuidos

En entornos distribuidos, las tablas derivadas se pueden utilizar para replicar datos en las diferentes

sedes, lo que permitiría sincronizar las actualizaciones sin crear ningún tipo de conflicto.

2.5.Tablas temporales
Otro tipo de tablas especiales son las tablas temporales, que deberían llamarse, de forma más
exacta, tablas de contenido temporal.

En las tablas temporales, el contenido tiene vigencia en el transcurso de una sesión (o una
transacción) y desaparece en el momento en que ésta finaliza.

La sentencia SQL para la creación de una tabla temporal es la siguiente:

1. CREATE {GLOBAL|LOCAL} TEMPORARY TABLE TableName

2. table_definition
3. ON COMMIT {PRESERVE ROWS|DELETE ROWS}

Estas tablas son muy útiles para almacenar resultados intermedios de una transacción.

Ejemplo de utilización de una tabla temporal

Consideremos la creación de la tabla siguiente, referente a las calificaciones obtenidas por los
alumnos en una asignatura:

1. CREATE LOCAL TEMPORARY TABLE SubjectMarks (

2. student VARCHAR2(50),
3. mark NUMBER(3,1))
4. ON COMMIT DELETE ROWS;

Cuando se realice la primera inserción, la tabla se materializará y será posible trabajar con ella
hasta el momento en que se ejecute la cláusula COMMIT; en ese momento la tabla se destruirá
y solo permanecerá su definición en el diccionario de datos.

2.6.Ventajas e inconvenientes en la utilización de vistas

Como en cualquier decisión de diseño, la utilización de vistas presenta una serie de ventajas e
inconvenientes. Las ventajas más importantes son las siguientes:

a) Independencia de los datos y las aplicaciones: Si se usan vistas como interfaz, se puede
llegar a una independencia completa entre la estructura real de los datos y la que ven las
aplicaciones. En cualquier momento se puede cambiar el nombre de una tabla, añadir nuevas
columnas o variar completamente su estructura. Todos estos cambios resultan invisibles para las
aplicaciones clientes. Solo habría que redefinir la interfaz, es decir, las vistas.

b) Simplificación del uso para el usuario: La utilización de las vistas permite tener
almacenadas consultas bastante complejas con múltiples combinaciones de tablas, condiciones y
funciones agregadas, y utilizarlas por medio de una consulta muy simple.

c) Mejora de la seguridad: El usuario no conoce las tablas y las columnas que forman
realmente la base de datos, de modo que ni siquiera puede intentar acceder a ellas; sólo tiene
noticia de aquellas información y estructura que se le dan a partir de las vistas.

d) Integridad de los datos: Con la cláusula WITH CHECK OPTION el usuario no puede llevar
datos fuera de los límites que tiene marcados; todos los cambios que haga sobre la vista (si es
actualizable) tendrán que dejar la fila consistente con las condiciones de la vista.

e) Rendimiento: Si es posible determinar el tipo de consultas que se llevarán a cabo a partir de

la vista, también es posible determinar caminos de acceso que mejoren la eficiencia de la
consulta.

Pero no todo son ventajas; los inconvenientes más importantes son los siguientes:

a) Restricciones de actualización: No todas las vistas son actualizables (en realidad, la

mayoría no lo son); no es posible hacer un diseño externo sólo con vistas (salvo que se usen
disparadores de sustitución).

b) Restricciones de estructura: Algunos SGBD, siguiendo una norma ISO, no permiten

construir una vista a partir de cualquier consulta: una vista creada a partir de una
sentencia SELECT no tendrá en cuenta las columnas nuevas que se hayan podido añadir a la
tabla original.

3.La seguridad
En un sistema de información, generalmente, las diferentes aplicaciones y usuarios de la
organización utilizan un único conjunto de datos (base de datos corporativa) con el SGBD. Por
un lado, esto resuelve problemas de redundancia, inconsistencia e independencia entre los datos
y los programas, y por otro, hace que la seguridad se convierta en uno de los problemas más
importantes en estos entornos.

La palabra seguridad engloba diferentes conceptos. Los más importantes son:

a) Confidencialidad: hay que proteger el uso de la información por parte de personas no

autorizadas. Esto implica que un usuario sólo tiene que poder leer la información para la cual
tiene autorización y que no podrá inferir información secreta a partir de la información a la que
tiene acceso.

b) Integridad: la información se tiene que proteger de modificaciones no autorizadas; esto

incluye tanto insertar datos falsos como destruirlos.

c) Disponibilidad: la información debe estar disponible en el momento en que le haga falta al

usuario.

Las violaciones de la base de datos consisten en lecturas o modificaciones incorrectas de los

datos. Por modificación entendemos las altas y las bajas de información y las modificaciones de
información existente. Las consecuencias de estas violaciones se pueden agrupar en tres
categorías:

a) Liberación incorrecta de la información. Está causada por la lectura de datos por parte
de usuarios impropios mediante un acceso intencionado o accidental. En esta categoría se
incluyen las violaciones del secreto derivadas de deducir información confidencial a partir de
lecturas de información autorizada.

b) Modificación impropia de los datos. Corresponde a todas las violaciones de la integridad

de los datos por tratamientos o modificaciones fraudulentas de éstos. Las modificaciones
impropias no se deben necesariamente a lecturas no autorizadas, puesto que los datos pueden
ser falsificados sin ser leídos.

c) Denegación de servicios. Corresponde a acciones que puedan impedir que los usuarios
accedan a los datos o utilicen determinados recursos.

Las amenazas a la seguridad se clasifican según la forma en que pueden producirse:

1) Amenazas no fraudulentas. Son accidentes casuales, entre los cuales se pueden distinguir
los siguientes:

a) Desastres accidentales o naturales: terremotos, inundaciones o incendios, que originan

accidentes que dañan el hardware del sistema.

b) Errores en el hardware o en el software: pueden conducir a accesos no autorizados.

c) Errores humanos: causados de forma no intencionada al introducir datos o utilizar

aplicaciones.

2) Violaciones intencionadas o violaciones fraudulentas. Son causadas por dos tipos de

usuarios diferentes:

a) Usuarios autorizados que abusan de sus privilegios.

b) Agentes hostiles, usuarios impropios (internos o externos) que ejecutan acciones de

vandalismo sobre el software y/o el hardware del sistema, o lecturas o escrituras de datos; en
ambos casos, los usos legales de los datos y las aplicaciones pueden enmascarar el propósito
fraudulento real.

A continuación se detallan los principales mecanismos de seguridad:

1) Identificación y autenticación. Se trata de mecanismos que identifican al usuario y se

aseguran de que es quien dice ser.

Problemas de disponibilidad

Los problemas de disponibilidad incluyen la seguridad física (por problemas de hardware), la no

saturación del sistema, la denegación de servicio (DoS) por parte de la red, etc.

2) Control de acceso. Son mecanismos que se cercioran de que los usuarios accedan sólo a los
lugares a los que están autorizados para ejecutar las acciones para las cuales han sido
autorizados.

3) Integridad y consistencia. Son mecanismos para que la base de datos permanezca

siempre en un estado que cumpla todas las reglas del negocio del modelo de datos, aunque se
produzcan cambios.

4) Auditoría. Consiste en mecanismos para saber quién ha realizado qué, es decir, para llevar
un registro de quién lleva a cabo todos los cambios y consultas en la base de datos. Más que un
mecanismo para proporcionar seguridad, se trata de un mecanismo que permite monitorizar a
los usuarios del sistema.

Ved también

El control de acceso al SGBD Oracle 11g se puede consultar en el subapartado 4.3. de este módulo

didáctico.

3.1.Identificación y autenticación
Los sistemas de información y los datos que almacenan y procesan son recursos muy valiosos
que hay que proteger. Uno de los primeros pasos hacia la seguridad en un sistema de
información es la capacidad de verificar la identidad del usuarios. Este proceso está formado por
dos partes: identificación (ver quién es) y autenticación (comprobar que es quien dice ser).

La identificación implica la forma en que un usuario proporciona su identidad al sistema.

La identidad tiene que ser única para que el sistema pueda diferenciarla entre los distintos
usuarios. Según los requisitos operacionales, una identidad puede describir a un individuo, a
más de un individuo o a uno o más individuos sólo una parte del tiempo.

La autenticación es el proceso de asociar a un individuo con su identidad única, es decir, es el

proceso que verifica que un usuario es quien dice que es.

Hay tres recursos de identificación básicos para poder demostrar quién es realmente un

individuo:

1) Algo que conoce una persona: una contraseña, un número de identificación personal, etc.

2) Algo que posee una persona: una tarjeta, una clave, etc.

3) Algo que caracteriza a una persona: la huella dactilar, la voz, etc.

Estos métodos básicos se pueden emplear individualmente o se pueden combinar para obtener
un nivel de seguridad más alto.

Las contraseñas son el mecanismo clásico de autenticación. Las contraseñas son palabras (o

mejor dicho, combinaciones de caracteres) que solo conoce un usuario. La seguridad de un
esquema de contraseñas depende de la capacidad de mantenerlas en secreto. Una contraseña se
tiene que elegir de forma que sea fácil de recordar y difícil de adivinar.

Criterios para elegir contraseñas

A continuación presentamos algunos criterios que conviene tener en cuenta a la hora de elegir
una contraseña:

1) Seleccionar contraseñas largas: ocho caracteres es una medida adecuada.

2) Combinar diferentes tipos de caracteres: mayúsculas, minúsculas, números, espacios en

blanco y signos de puntuación.

3) No usar palabras con significado.

4) Utilizar contraseñas diferentes para acceder a sistemas diferentes.

5) Cambiar la contraseña de manera periódica.

6) No escribir la contraseña en lugares a los que otra persona pueda acceder.

7) Que no sea la misma que el identificador de usuario.

8) Al cambiarla, que difiera de la anterior en al menos tres caracteres.

9) Cambiar la contraseña la primera vez que se inicie una sesión.

Las tarjetas dan mayor seguridad. Pueden ser simples trozos de plástico con una banda
magnética o incluso pueden incorporar chips, como hacen las tarjetas inteligentes. En ambos
casos, la contraseña personal tiene que coincidir con la que hay escrita en la tarjeta, o bien la
contraseña y cierta información de la tarjeta deben coincidir con la que hay en el ordenador.

La tendencia actual es ir hacia sistemas biométricos, que son métodos automatizados de

reconocimiento de una persona que se basan en una característica fisiológica o de
comportamiento. Los sistemas biométricos se pueden utilizar como método de identificación, en
el que se identifica a una persona dentro de una población buscando la coincidencia de una
característica suya registrada en una base de datos. También se pueden utilizar en modo de
verificación: el sistema autentica la identidad reclamada de una persona con su patrón
previamente grabado.
Ámbito de la identidad

Una diferencia importante entre la identificación y la autenticación es que las identidades son públicas,

mientras que la información de autenticación se mantiene en secreto. Esto proporciona el recurso

gracias al cual una persona prueba que es realmente quien dice ser.

Para la validación de un usuario de un sistema de gestión de bases de datos, se pueden usar

cuatro métodos:

1) Autenticación por el mismo SGBD. Es la más utilizada, puesto que las cuentas son más
fáciles de controlar y gestionar y el mismo SGBD tiene recursos que permiten la administración
de pequeñas comunidades de usuarios.

2) Autenticación por el sistema operativo Es una forma de validación externa. Sólo es

posible en aquellos sistemas que permitan la validación de usuarios (UNIX, Windows NT, etc.).

3) Autenticación por el servicio de red. Utiliza productos especializados de red, como

Kerberos, CyberSafe, Identix, Radius u otros.

Sistema de autenticación de la red Kerberos

En sistemas en los que se requiere un cierto nivel de seguridad, es habitual la utilización de sistemas

externos (máquinas diferentes de aquella a la que queremos conectarnos) como servicios de

autenticación. El más conocido es Kerberos, el cual, utilizando diferentes técnicas de cifrado y emisión

de tiques (tickets), proporciona un buen nivel de seguridad para la mayoría de los sistemas.

4) Autenticación por una capa intermedia. En un sistema cliente/servidor de tres niveles, la

capa intermedia podría ser el software intermediario  (13) o la aplicación misma.

En todos los casos, la comunicación puede ser cifrada.

Figura 3. El sistema de autenticación de la red Kerberos

La figura muestra el sistema de autenticación de la red Kerberos, que usa una máquina específica para llevar a cabo la

autenticación y, de este modo, libera al SGBD de esta tarea.

En inglés, middleware.
(13) 

3.2.Control de acceso
Se denomina control de acceso aquella parte del SGBD que tiene la función de asegurar que
los accesos al sistema se llevan a cabo de acuerdo con los modelos y reglas fijadas por la política
de protección.

El control de acceso controla la interacción (lectura, escritura...) entre los sujetos (usuarios,
aplicativos, procesos...) y los objetos a los que acceden.

El control de acceso está formado por dos componentes:

1) Políticas de acceso: definen los principios según los cuales se autoriza a un usuario, se
deniega o se filtra un acceso específico a un objeto.

2) Mecanismos de seguridad: procedimientos que se aplican a las consultas de los usuarios

para que cumplan las normas anteriores.

Las diferentes implementaciones de las políticas de acceso se pueden clasificar en control de

acceso discrecional y control de acceso obligatorio.

Filtrado

El filtrado devuelve sólo una parte de la información requerida.

3.2.1.Control de acceso discrecional

El control de acceso discrecional (DAC (14) ) se basa en la identidad de los usuarios o grupos de
usuarios para restringir el acceso a objetos. El control discrecional es el mecanismo de control
más común que se implementa en los sistemas de información actuales.

DAC es la sigla de discretionary access controls.

(14) 

Uso del DAC

El control de acceso discrecional (DAC) es el más utilizado en los SGBD comerciales.

Las políticas discrecionales se fundamentan en el conocimiento de los derechos que cada

usuario tiene sobre cada objeto. Estas políticas podrán ser definidas por el administrador de la
base de datos o por el propietario del objeto.

La mejor manera de representar la estructura del control de acceso discrecional es la matricial:

  Objeto 1 Objeto 2 ...

Usuario 1     ...  

Usuario 2     ... Derechos del u

... ... ... ...  

Usuario n     ...  

La intersección entre filas y columnas indica los derechos de cada usuario sobre cada objeto.

Una ampliación habitual de la tabla anterior consiste en incorporar los grupos de usuarios como
si se trataran de otro usuario y los privilegios sobre el sistema como si se trataran de un objeto.
La descentralización de las autorizaciones provoca que surjan problemas de propagación tanto
de autorizaciones como de revocaciones. Si un usuario M ha recibido una autorización de un
usuario N que tenía el derecho de administrar la seguridad sobre un objeto P, ¿qué derechos
tendrá el usuario M si a N se le revocan todos los permisos? El sistema deberá prever políticas
de autorización y revocación en cadena.

Los derechos del usuario

Los derechos del usuario pueden incluir el de administrar la seguridad del objeto.

3.2.2.Control de acceso obligatorio

El control de acceso obligatorio (MAC (15) ) se suele usar en aquellas bases de datos en las que los
datos tienen una estructura de clasificación muy rígida y estática, como por ejemplo las bases de
datos militares y gubernamentales.

Las políticas de control de acceso obligatorio se basan en la idea de que cada dato tiene un
nivel de clasificación (por ejemplo, muy secreto, secreto, confidencial...) y cada usuario tiene un
nivel de acreditación (con las mismas posibilidades que el nivel de clasificación). Los diferentes
niveles están ordenados de forma estricta e incremental: muy secreto > secreto > confidencial...
Las normas de funcionamiento del control de acceso obligatorio son las siguientes:

 Un usuario puede ver un objeto sólo si su nivel de acreditación es mayor o igual que el
nivel de clasificación del objeto.

 Un usuario puede modificar un objeto sólo si su nivel de acreditación es igual al nivel de

clasificación del objeto.

Los usuarios deberán tener, primero, el acceso discrecional autorizado y los privilegios
adecuados sobre el objeto de la base de datos antes de que se compruebe el sistema de acceso
obligatorio. El sistema de seguridad MAC se basa en el concepto de etiqueta.

Una etiqueta indica el nivel del usuario (acreditación) o del objeto (clasificación). Los valores
bajos denotan información no clasificada o menos sensible; los valores altos denotan
información más restrictiva o accesible a menos usuarios. Las etiquetas se pueden refinar
añadiendo otros subniveles.

Ejemplo de utilización de etiquetas

En el ejército se podría tener una clasificación como la que se presenta en la tabla siguiente,
donde a cada etiqueta le corresponde un valor:

El sistema de gestión de bases de datos comprueba primero todas las autorizaciones de acceso
discrecional; en caso de que el usuario cumpla todos los niveles de seguridad, el sistema de
acceso obligatorio compara las etiquetas del usuario y del objeto para decidir quien tiene acceso.

Nombre Valor Descripción

General 80 Alto secreto, personal.

Oficial 60 Alta seguridad, no distribuir.

Suboficial 40 Moderadamente seguro.

Militar 20 Nivel básico, no demasiado sensible.

Civil 1 Público conocimiento, libre distribución.

MAC es la sigla de mandatory access controls.

(15) 

Uso del MAC

El control de acceso obligatorio se suele utilizar en los SGBD que trabajan con información sensible

(de alta seguridad).

3.2.3.Clasificación de los sistemas de seguridad

Los sistemas de seguridad se clasifican en cuatro niveles de seguridad, que son, de menos a
más protección:
1) Protección mínima: la clase D no incorpora ningún mecanismo de seguridad.

2) Protección discrecional: la clase C soporta el control de acceso discrecional y tiene las

subclases C1 y C2. La clase C1 requiere separación entre los datos y los usuarios. La clase C2
requiere además procesos de registro, auditoría y aislamiento de recursos.

Los sistemas de seguridad habituales

Aunque algunos productos comerciales proporcionan un nivel de seguridad B1, lo más normal es que

solo lleguen al nivel C2.

3) Protección estructurada: la clase B soporta el control de acceso obligatorio y tiene las

subclases B1, B2 y B3. La clase B1 requiere protección de seguridad etiquetada: todos los
objetos están etiquetados con un nivel de seguridad. La clase B2 requiere además una sentencia
formal para cada cosa, así como que los canales de cobertura sean identificados y eliminados. La
clase B3 requiere también apoyos de recuperación y auditoría.

4) Protección verificada: la clase A, la más segura, requiere una demostración matemática de

que los mecanismos de seguridad son consistentes y adecuados para soportar la política de
seguridad especificada.

Ejemplo de cobertura

Un ejemplo de cobertura podría ser inferir la respuesta de una consulta ilegal a partir de una consulta

legal.

La clasificación de los sistemas de seguridad que se ha presentado aquí fue creada por el

Pentágono como sistema de clasificación estándar, y se encuentra definida en el Orange Book,
en el que se definen los requisitos de seguridad para cualquier TCB  (16) , y en el Lavender Book, en
el que se define la interpretación de los requisitos para un sistema gestor de bases de datos
específico.

TCB es la sigla de la expresión inglesa trusted computing base.

(16) 

3.3.Implementación del control de acceso discrecional a SQL:2011

El estándar actual define la siguiente sintaxis de autorizaciones:

1. <sentencia de autorización> ::=

2. <sentencia autorización privilegios>
3. | <sentencia autorización roles>
4. <sentencia autorización privilegios> ::=
5.  
6. GRANT <privilegios> TO <autorizado> [{ , <autorizado>}]
7. [WITH HIERARCHY OPTION]
8. [WITH GRANT OPTION]
9. [GRANTED BY <autorizador>]
10. <privilegios> ::=
11. <privilegios de objeto> ON <nombre objeto>
12.  
13. <privilegios de objeto> ::=
 14. ALL PRIVILEGES|<acción>[{ , <acción>}]
15. <acción> ::=
16. DELETE |
17. SELECT [(<nombre columna> [ , <nombre columna>] ... ])]|
18. SELECT [(<nombre rutina> [ , <nombre rutina>] ... ])]|
19. INSERT [(<nombre columna> [ , <nombre columna>] ... ])]|
20. UPDATE [(<nombre columna> [ , <nombre columna>] ... ])]|
21. REFERENCES [(<nombre columna> [ , <nombre columna> ... ])]|
22. USAGE |
23. UNDER |
24. TRIGGER |
25. EXECUTE
26.  
27. <nombre objeto> ::=
28. [ TABLE ] <nombre tabla>
29. |DOMAIN <nombre dominio>
30. | COLLATION <nombre compaginador de caracteres>
31. | CHARACTER SET <nombre juego de caracteres>
32. | TRANSLATION <nombre transcripción>
33. | TYPE <nombre tipo>
34. | SEQUENCE <nombre generador de secuencias>
35. | <designador específico de rutina>
36. | MODULE <nombre módulo>
37.  
38. <autorizado> ::=
39. PUBLIC | <nombre autorizado>
40.  
41. <autorizador> ::=
42. CURRENT_USER | CURRENT_ROLE

El significado de los privilegios que se pueden dar a un usuario sobre un objeto son los
siguientes:

Ejemplos de autorizaciones

A continuación presentamos un ejemplo de cómo se implementan las autorizaciones tratadas en

este subapartado:

1. GRANT SELECT ON TABLE Empleado TO Auditor2;

2. GRANT USAGE ON DOMAIN d_Telefono TO PUBLIC;
 Privilegios Definición

INSERT [(lista-nombres-columnas)] Insertar valores en las columnas relacionadas de una fila.

UPDATE [(lista-nombres-columnas)] Actualizar valores en las columnas relacionadas de una fila.

DELETE Borrar filas.

SELECT [(lista-nombres-columnas)] Consultar valores en las columnas relacionadas.

REFERENCES [(lista-nombres-columnas)] Referenciar a valores de las columnas relacionadas.

TRIGGER Crear un disparador sobre una tabla.

EXECUTE Ejecutar un procedimiento incorporado.

1. GRANT ALL PRIVILEGES ON VIEW Vista1 TO Joan, Pere, Maria

Es relativamente frecuente asociar los mismos privilegios a diferentes usuarios, por ejemplo a
todo el departamento de contabilidad. Para facilitar este tipo de autorización, se usa el rol.

Un rol se puede definir como un conjunto de uno o más privilegios. Si se autoriza un rol a un
usuario, automáticamente se le autorizan todos los privilegios incorporados en el rol.

La sintaxis del rol es la siguiente:

Cláusulas de autorización de privilegios

La opción WITH GRANT OPTION permite transmitir los privilegios que se tienen a otro. La

cláusula WITH HIERARCHY OPTION permite trasladar los permisos a todas las subtablas.

1. <definición rol> ::=

2. CREATE ROLE <nombre rol>
3. [WITH ADMIN <autorizador>]
4.  
5. <sentencia autorización rol> ::=
6. GRANT <nombre rol> [ { , <nombre rol>}]
7. TO <autorizado> [ { , <autorizado>}]
8. [WITH GRANT OPTION]
 9. [GRANTED BY <autorizador>]

La cláusula WITH ADMIN permite indicar quién administrará el rol.

Ejemplos de creación y utilización de roles

Considerad los ejemplos siguientes de creación y utilización de roles:

1. CREATE ROLE Auditores WITH ADMIN CURRENT_USER;

2. GRANT SELECT, UPDATE (Salario, Comision) TO Auditores;
3. GRANT Auditores TO Pere, Joan, Maria;

Del mismo modo que se dan autorizaciones, se pueden revocar.

La sintaxis para revocar roles es la siguiente:

1. <sentencia revocar privilegios> ::=

2. REVOKE [{GRANT OPTION FOR|HIERARCHY OPTION FOR}]
3. <privilegios> FROM <autorizado> [{ , <autorizado>} ... ]
4. [ FROM {CURRENT_USER|CURRENT_ROLE}]
5. [ GRANTED BY <autorizador>]
6. { RESTRICT|CASCADE}
7.  
8. <sentencia revocar rol> ::=
9. REVOKE [ADMIN OPTION FOR] <nombre rol> [{ , <nombre rol> } ... ]
10. FROM <autorizado> [ { , <autorizado >} ... ]
11. [FROM {CURRENT_USER|CURRENT_ROLE}]
12. [GRANTED BY <autorizador>]
13. {RESTRICT|CASCADE}

Problemas de propagación de privilegios

Las opciones RESTRICT y CASCADE tienen una importancia especial para resolver los problemas de

propagación. Cuando A autoriza un privilegio a B (con la opción de administrarlo) y B lo autoriza a C,

si a A se le quitan los privilegios que tenía, B y C se quedarán con los privilegios “abandonados”. Si la

opción elegida cuando se revocan los privilegios a A es CASCADE, los permisos de B y C también

serán revocados. Si la opción es RESTRICT, sólo se podrá revocar los permisos de A si previamente se

han eliminado los permisos candidatos a ser abandonados. Si no se utiliza ninguna de las opciones, B

y C se quedarán con los permisos, y se correrá el riesgo de que B vuelva a dar privilegios a A.

3.4.Auditoría
La auditoría es el registro y monitorización de algunas acciones específicas de usuarios sobre la
base de datos.

La auditoría se utiliza normalmente para los casos siguientes:

1) La investigación de una actividad sospechosa.

Ejemplo de investigación de una actividad sospechosa

Si un usuario no autorizado intenta borrar datos de las tablas, el administrador de seguridad

podrá decidir si audita todas las conexiones de la base de datos y todos los intentos (con éxito o
no) de borrar datos.

2) La monitorización y la recogida de actividades específicas de la base de datos.

Ejemplo de monitorización de la base de datos

El administrador de la base de datos puede recoger datos sobre qué tablas se actualizan o
cuántos usuarios están conectados en momentos punta.

El sistema de auditoría debe permitir diferentes formas de utilización:

La carga del trabajo de auditoría

El trabajo de auditoría puede representar una sobrecarga superior al nivel del trabajo normal.

 Auditar sentencias. La auditoría (17) indicará cuándo y quién ha utilizado un tipo de

sentencia concreta; por ejemplo, auditar todas las inserciones o los borrados.

 Auditar objetos. El sistema registrará cada vez que se realice alguna operación sobre un
objeto determinado.

 Auditar sentencias sobre objetos, una versión combinada de las dos anteriores.

 Auditar a usuarios o grupos.

Auditar significa averiguar quién es el autor de cualquier cambio en la base de datos.

(17) 

También se puede decidir si se desea un único registro por sesión, por sentencia o por acceso; y
si sólo se quiere registrar cuándo tiene éxito, cuándo fracasa o en ambos casos. La información
que suele registrar la auditoría es el nombre del usuario, el identificador de sesión, el
identificador de terminal, el nombre del objeto al que se ha accedido, la operación ejecutada o
que se ha intentado, el código completo de la operación, la fecha y la hora.

La creación de auditorías

Algunos SGBD incorporan sentencias SQL que permiten generar una auditoría de manera declarativa;

en otros casos habrá que crear disparadores que vayan rellenando las tablas de auditoría conforme se

producen acontecimientos.

3.5.La Ley de protección de datos de carácter personal

La legislación española recoge una serie de derechos y deberes relativos a la utilización de los
datos personales en el ámbito de los sistemas de información. Las principales fuentes de
derechos son las siguientes: la Ley Orgánica 5/1992, de 29 de octubre, de Regulación del
Tratamiento Automatizado de los Datos de Carácter Personal (LORTAD) y el Real Decreto
1332/1994, de 30 de junio, que desarrolla la ley anterior. Esta ley ha sido derogada por la Ley
Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPDCP).
Las leyes LORTAD y LOPDCP han sido creadas en cumplimiento del mandato constitucional
contenido en el artículo 18.4, que dice: “la ley limitará el uso de la informática para garantizar el
honor y la intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos”.

Las normativas actuales también siguen la Directiva del Parlamento europeo 95/46 de 24 de
octubre, relativa a la protección de las personas físicas por lo que respecta al tratamiento de
datos personales y a la libre distribución de esos datos.

3.5.1.Principios generales de protección de datos

1) Calidad de datos. Los datos de carácter personal sólo podrán ser recopilados para su
tratamiento y sometidos a dicho tratamiento cuando resulte adecuado, pertinente y no excesivo
en relación con el ámbito y las finalidades para las que se han obtenido.

2) Derecho de información en la recogida de datos. Se deberá informar con antelación a

los interesados a quienes se soliciten los datos personales de los puntos siguientes:

 de la existencia de un fichero o tratamiento de datos de carácter personal;

 del carácter obligatorio o facultativo de la respuesta dada a las preguntas que se

planteen;

 de las consecuencias de la obtención de los datos o la negativa a suministrarlos;

 de la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación y

oposición, y

 de la identidad y dirección del responsable del tratamiento o, según el caso, de su

representante.

3) Consentimiento del afectado. Salvo que la ley disponga otra cosa, se requerirá el
consentimiento inequívoco de los afectados para el tratamiento de los datos de carácter
personal.

4) Datos especialmente protegidos. Los datos de carácter personal que revelen ideología,
afiliación sindical, religión y creencias sólo podrán ser objeto de tratamiento con el
consentimiento, expreso y por escrito, del afectado.

5) Datos relativos a la salud. Las instituciones y los centros sanitarios públicos y privados y
los profesionales correspondientes podrán proceder al tratamiento de los datos de carácter
personal relativos a la salud de las personas siempre que sean facilitados por el titular por
motivo de asistencia sanitaria.

Finalidad del tratamiento de los datos

Los datos de carácter personal objeto del tratamiento no se podrán utilizar para finalidades

incompatibles con aquellas para las que se habrían recogido.

6) Seguridad de los datos y deber de secreto. Tanto el responsable del fichero como el
encargado del tratamiento deberán adoptar las medidas técnicas y organizativas necesarias que
garanticen la seguridad de los datos de carácter personal y eviten la alteración, la pérdida o el
tratamiento o acceso no autorizados.

7) Comunicación de datos. Los datos de carácter personal objeto de tratamiento sólo se

podrán comunicar a un tercero para el cumplimiento de finalidades directamente relacionadas
con las funciones legítimas del cedente y del cesionario, si hay consentimiento por parte del
interesado.
8) Acceso a los datos por parte de terceras personas. Los tratamientos que realicen
terceras personas deberán estar regulados en un contrato por escrito o de cualquier otra forma
que permita acreditar su suscripción y contenido. El acceso de un tercero a estos datos no se
considerará comunicación de datos cuando sea necesario para la prestación de un servicio al
responsable del tratamiento.

Las personas tienen los derechos siguientes:

1) Impugnación de valoraciones: los ciudadanos tienen derecho a no verse sometidos a una

decisión con efectos jurídicos que se fundamente únicamente en un tratamiento de datos
destinados a evaluar aspectos de su personalidad.

Impugnación de valoraciones

El afectado podrá impugnar los actos administrativos o las decisiones privadas que impliquen una

valoración de su comportamiento.

2) Derecho de acceso: el interesado tendrá derecho a solicitar y obtener gratuitamente

información de sus datos de carácter personal sometidos a tratamiento, del origen y de las
comunicaciones efectuadas o que se prevea hacer.

Derecho de acceso

El Registro General será de consulta pública y gratuita.

3) Derecho de rectificación y cancelación: cuando los datos de carácter personal resulten

inexactos o incompletos, serán rectificados o cancelados. El responsable del tratamiento tiene la
obligación de hacer efectivo este derecho de rectificación o cancelación del interesado.

4) Derecho a una indemnización: si el responsable o el encargado del tratamiento incumplen

la ley, y si como consecuencia de este incumplimiento los interesados tienen algún perjuicio o
lesión en sus bienes o derechos, estos tendrán derecho a ser indemnizados.

Tutela de los derechos

Las actuaciones contrarias a la presente Ley pueden ser objeto de reclamación por pare de los

interesados ante la Agencia de Protección de Datos.

Secreto profesional de los datos personales

Los datos de carácter personal que hagan referencia a su origen racial, a la salud y a la vida sexual se

podrán tratar o ceder sólo cuando así lo disponga la ley.

3.5.2.Los niveles de seguridad

Según el Real Decreto 994/1999, se establecen tres niveles de seguridad: básico, medio y alto.
La aplicación de uno u otro dependerá de la naturaleza de la información.

Para aplicar las medidas de seguridad correspondientes en los ficheros con datos de carácter
personal, deben observar los aspectos que se consideran a continuación.

Nivel básico

Todos los ficheros que contengan datos de carácter personal deben seguir las medidas de
seguridad del nivel básico.
Las medidas del nivel básico de seguridad se definirán en el documento de seguridad que
habrá elaborado e implementado el responsable del fichero. Este documento tendrá que incluir
los puntos siguientes:

a) El ámbito de aplicación del documento con especificación detallada de los recursos
protegidos.

b) Las medidas, normas, procedimientos, reglas y estándares dirigidos a garantizar el nivel de

seguridad exigido por el Real Decreto 994/1999.

c) Las funciones y obligaciones del personal.

d) La estructura de los ficheros que contengan datos de carácter personal y descripción de los
sistemas de información que los tratan.

e) El procedimiento de notificación, gestión y respuesta de las incidencias (tanto tecnológicas

como funcionales y de acceso). El procedimiento de notificación y gestión de incidencias debe
incluir un registro donde conste como mínimo el tipo de incidencia, el momento en el que se ha
producido, la persona que realiza la notificación, la persona a quien se notifica la incidencia y los
efectos derivados de ésta.

f) Los procedimientos de realización de copias de seguridad y de recuperación de datos.

g) La periodicidad con la que hay que sustituir las contraseñas de los usuarios.

h) El personal autorizado para conceder, modificar y/o alterar los accesos autorizados a los
datos y/o recursos, así como los criterios para realizar estas acciones.

i) El personal autorizado para acceder al lugar donde se almacenan datos de carácter personal.

Nivel medio

Los ficheros que contengan datos relativos a la comisión de infracciones penales y/o
administrativas, la Hacienda Pública y servicios financieros (solvencia patrimonial y crédito,
cumplimiento o incumplimiento de las obligaciones monetarias) tendrán que seguir las medidas
del nivel medio.

Las medidas de seguridad de nivel medio incluyen todas las del nivel básico y, además,
exigen el cumplimiento de los puntos siguientes:

a) Identificación del responsable o responsables de seguridad.

El responsable de seguridad

Muy a menudo, el administrador de la base de datos (ABD) suele ser la persona responsable de la

seguridad y de mantener el documento de seguridad.

b) Controles periódicos (auditoría) para verificar el cumplimiento de lo establecido en el propio

documento de seguridad.

Auditorías

Los informes de auditoría deberán depositarse en la Agencia de Protección de Datos.

c) Medidas que adoptar cuando un soporte que contenga datos de carácter personal esté a
punto de ser destruido o reutilizado.

d) Personal autorizado para acceder a los locales donde se encuentren físicamente ubicados los
sistemas de información con datos de carácter personal.

Nivel alto
Ficheros con datos cuyo contenido esté relacionado con la ideología, religión, creencias, origen
racial, salud o vida sexual seguirán las medidas del nivel alto.

Las medidas de seguridad de nivel alto incluyen todas las del nivel medio y, además, exigen
el cumplimiento de los puntos siguientes:

a) Los datos de carácter personal que se tengan que distribuir en cualquier tipo de soporte se
cifrarán.

b) Para cada acceso se guardará como mínimo la identificación del usuario, la fecha y la hora en
que se hizo el acceso, el nombre del fichero al que se ha accedido y el tipo de acceso.

c) Se deberá guardar un copia de seguridad y de los procedimientos de recuperación de los

datos en un lugar diferente de donde se encuentren físicamente los sistemas de información.

d) Se cifrarán los datos de carácter personal que se transmitan por la red de
telecomunicaciones.

El documento de seguridad

El documento de seguridad deberá mantenerse siempre actualizado y deberá revisarse cada vez que

se produzcan cambios relevantes en el sistema de información o en su organización. El documento se

tendrá que adecuar siempre a la normativa vigente en materia de protección de datos de carácter

personal.

3.5.3.La Agencia de Protección de Datos

La Agencia es un ente de derecho público, con personalidad jurídica propia y plena capacidad
pública y privada. Actúa con total independencia de las administraciones públicas en el ejercicio
de sus funciones. Su finalidad principal consiste en velar por el cumplimiento de la legislación
sobre protección de datos personales y controlar su aplicación, en especial en todo lo
relacionado con los derechos de información, acceso, oposición, rectificación y cancelación de
datos.

La Agencia de Protección de Datos en Internet

En la página de Internet de la Agencia de Protección de Datos, podéis encontrar las últimas

actualizaciones de todas las normativas y realizar notificaciones y registros de inscripción de los

ficheros de datos personales.

La página también dispone de una sección de FAQ (preguntas más frecuentes), que tiene el objetivo

de que el ciudadano pueda ejercer sus derechos y aclarar a las organizaciones cómo tienen que

cumplir con sus deberes.

4.Anexos
4.1.Reglas de equivalencia de operaciones de álgebra relacional
Las reglas de equivalencia se utilizan para reestructurar el árbol de operaciones de álgebra
relacional que se ha obtenido en el proceso de descomposición de la consulta.

A continuación, vamos a definir algebraicamente cada una de ellas y a mostrar algunos ejemplos
aclaratorios:
1) Las operaciones conjuntivas de selección pueden transformarse en una cascada de
operaciones individuales de selección.

σ(p)∧(q)∧(r)(R) = σp(σq(σr(R))), donde p ∈ {A1, ... , An}

Ejemplo

σ(salary>2.500)∧(hireDate>‘01-SEP-97’)(Emp) = σ(salary>2.500)(σ(hireDate>‘01-SEP-97’)(Emp))

2) Las operaciones de selección son conmutativas.

σq(σp(R)) = σp(σq(R)), donde p, q ∈ {A1, ... , An}

Ejemplo

σ(salary>2.500)(σ(hireDate>‘01-SEP-97’)(Emp)) = σ(hireDate>‘01-SEP-97’)(σ(salary>2.500)(Emp))

3) En una secuencia de operaciones de proyección, sólo es necesaria la última proyección de la

secuencia.

∏L∏M∏N(R) = ∏L(R)

Ejemplo

∏empId∏empId;firstName;lastName(Emp) = ∏empId(Emp)

4) Conmutatividad de la selección y la proyección.

∏L(σp(R)) = σp(∏L(R)), donde p  ∈ {A1, ... , An}

Ejemplo

∏empId;firstName;lastName(σ(salary>2.500)(Emp)) =
= σ(salary>2.500)(∏empId;firstName;lastName(Emp))

5) Conmutatividad de la combinación Theta (y del producto cartesiano).

R ⋈ p S = S ⋈ p R
R × S = S × R

Ejemplo

Emp ⋈ (Emp:deptId=Dept:deptId)Dept = Dept ⋈ (Dept:deptId=Emp:deptId)Emp

6) Conmutatividad de la selección y de la combinación Tetha (y del producto cartesiano).

σp(R ⋈ t S) = (σp(R)) ⋈ t  S, donde p ∈ {A1, ... , An}

σp(R × S) = σp(R) × S

En caso de que el predicado sea de la forma (p ∧ q), donde p corresponde a los atributos

de R y q a los de S, entonces las operaciones son conmutativas de la forma siguiente:

σ(p∧q)(R ⋈ t S) = (σp(R)) ⋈ t (sq(S))
σ(p∧q)(R × S) = (σp(R)) × (σq(S))

Ejemplo

σ(deptName=‘IT’)∧(hireDate>‘01-SEP-97’)(Emp ⋈ (Emp:deptId=Dept:deptId)Dept) =
= σ(deptName=‘IT’)(Emp ⋈ (Emp:deptId=Dept:deptId) (σ(hireDate>‘01-SEP-97’)Dept)

7) Conmutatividad de la proyección y de la combinación Tetha (y del producto cartesiano).

∏ L1∪L2(R ⋈ t S) = (∏L1(R)) ⋈ t (∏L2(S))

Ejemplo

∏firstName;lastName;deptId;deptName((Emp) ⋈ Emp:deptId=Dept:deptId (Dept)) =
= (∏firstName;lastName;deptId(Emp)) ⋈ Emp:deptId=Dept:deptId (∏deptId;deptName(Dept))
8) Conmutatividad de la unión y de la intersección, pero no de la diferencia.

R ∪ S = S ∪ R

R ∩ S = S ∩ R

9) Conmutatividad de la selección y de las operaciones de conjuntos (unión, intersección y

diferencia).

σp(R ∪ S) = σp(R) ∪ σp(S)

σp(R ∩ S) = σp(R) ∩ σp(S)

σp(R – S) = σp(R) – σp(S)

10) Conmutatividad de la proyección y de la unión.

∏L(R ∪ S) = ∏L(R) ∪ ∏L(S)

11) Asociatividad de la combinación Tetha (y del producto cartesiano).

((R ⋈ S) ⋈ T) = (R ⋈ (S ⋈ T))
((R × S) × T) = (R × (S × T))

Ejemplo

((Emp  ⋈ Emp:deptId=Dept:deptIdDept) ⋈ Dept:locid=Locs:locid Locs) =
= (Emp  ⋈ Emp:deptId=Dept:deptId (Dept ⋈ Dept:locid=Locs:locid  Locs))

12) Asociatividad de la unión y de la intersección (pero no de la diferencia de conjuntos).

(R ∪ S) ∪ T = S ∪ (R ∪ T)

(R ∩ S) ∩ T = S ∩ (R ∩ T)

Combinaciones Theta

Combinaciones que utilizan los operadores de comparación como condición de combinación.

4.2.Consideraciones sobre vistas en el SGBD Oracle 11g

En este apartado del anexo nos detendremos a considerar diferentes aspectos referentes al uso
de las vistas en el SGBD Oracle 11g:

1) las vistas del diccionario de datos, y

2) las operaciones de actualización sobre vistas.

4.2.1.Vistas del diccionario de datos

El diccionario de datos está formado por un conjunto de tablas y vistas que proporcionan
información sobre el contenido de una base de datos:

 estructuras de almacenamiento;

 usuarios y sus derechos, y

 los objetos: tablas, vistas, índices, procedimientos y funciones.

El diccionario de datos se carga en la memoria y se utiliza internamente para el tratamiento de
las consultas. Existen dos grupos de tablas/vistas en el diccionario de datos:

1) Vistas estáticas. Se basan en tablas almacenadas en el espacio de tablas  (18) SYSTEM. Hay

tres grandes grupos de vistas estáticas:
a) USER_%. Contienen información sobre los objetos que pertenecen al usuario.

b) ALL_%. Contienen información sobre los objetos a los que el usuario tiene acceso.

c) DBA_%. Contienen información sobre todos los objetos de la base de datos.

Después del prefijo, el nombre describe la información a la que se accede cuando se hace una
consulta sobre la vista.

2) Vistas dinámicas de rendimiento. Aunque contienen información que no se basa en tablas

ni en otras vistas, sino que se captura de la memoria o de partes del fichero de control, estas
vistas permiten efectuar consultas sobre el rendimiento de la base de datos o del SGBD. Se
caracterizan porque tienen el prefijo V$ y a continuación su nombre describe la información que
representan. Estas vistas son accesibles sólo si el usuario tiene el privilegio DBA.

En inglés, tablespace.
(18) 

4.2.2.Operaciones de actualización sobre vistas

Las operaciones de actualización (INSERT, DELETE y UPDATE) son un tema conflictivo para los
varios SGBD, ya que las vistas se basan en sentencias SELECT, en las que pueden intervenir
muchas o pocas tablas e incluso otras vistas, y por lo tanto hay que decidir a cuál de estas
tablas y/o vistas corresponde la operación de actualización solicitada.

En el SGBD Oracle 11g, el concepto de tabla key-preserved es fundamental para entender las
restricciones en las actualizaciones sobre vistas basadas en operaciones de combinación (JOIN).

Una tabla es key-preserved en una operación de combinación (JOIN) si cada valor clave de la
tabla también puede ser valor clave en el resultado del JOIN.

La propiedad key-preserved de una tabla en un JOIN no depende de los datos de las tablas, sino
que es una propiedad deducida a partir de su definición.

Ejemplo

En la vista EmpDeptView, a la que nos hemos referido ya en este módulo, la tabla Emp es key-

preserved en un join con la tabla Dept, dado que la columna empId (clave primaria de la
tabla Emp) continúa siendo única en el resultado de la combinación. En cambio, la tabla Dept  no
es key-preserved, puesto que la columna deptId  (clave primaria de la tabla Dept) no es única en
el resultado de la combinación.

El SGBD Oracle 11g proporciona la vista USER_UPDATABLE_COLUMNS, que permite conocer

todas las columnas que podemos actualizar en las tablas y vistas a las que tenemos acceso.

Reflexión

Habrá que conocer muy bien las operaciones de actualización sobre las vistas que permite cada SGBD.

Analizando el descriptor de la vista USER_UPDATABLE_COLUMNS, podemos observar que ésta

nos muestra todas las columnas de todas las tablas y vistas a las que el usuario tiene acceso
junto con las operaciones que puede ejecutar.

 La columna owner muestra el esquema que contiene la tabla o vista.

 La columna table_name  contiene los nombres de las tablas y de las vistas a las que el
usuario tiene acceso.

 La columna column_name nos indica las diversas columnas.

Ejemplos de columnas actualizables en una vista
Recordemos las dos vistas creadas sobre el esquema COMPANY. En caso de que queramos saber
qué operaciones podemos realizar sobre las columnas de estas dos vistas, podemos consultar la
vista USER_UPDATABLE_COLUMNS:

1. SELECT table_name, column_name, updatable, insertable, deletable

2. FROM user_updatable_columns
3. WHERE owner = ';COMPANY';
4. AND (table_name in (';EmpDeptView';, ';EvenDeptView';));

Fijaos en que la columna deptName  de la vista EmpDeptView  no es actualizable, y que tampoco

se pueden efectuar inserciones ni eliminaciones, es decir:
 Si ejecutamos una sentencia DELETE sobre la vista EmpDeptView, eliminaremos filas de
la tabla Emp (a la que pertenecen las columnas que tienen YES como deletable), pero
no eliminaremos ninguna fila de la tabla Dept  (a la que pertenece la
columna deptName).

 Podemos ejecutar INSERT sobre la vista EmpDeptView  para rellenar filas de la

tabla Emp, pero no para rellenar ninguna fila en la tabla Dept.

 Podemos ejecutar UPDATE sobre la vista EmpDeptView  para modificar el contenido de

las columnas provenientes de la tabla Emp, pero no podremos hacerlo para la
columna deptName proveniente de la tabla Dept.

Condiciones para que una vista sea actualizable

La vista USER_UPDATABLE_COLUMNS sólo muestra las vistas que el sistema considera que

pueden ser actualizables. Para que una vista tenga este reconocimiento, deben darse las
condiciones siguientes:

a) Cada columna de la vista tiene que corresponder con una columna de una tabla simple.

b) La vista no puede contener ninguno de los componentes siguientes:

 operador DISTINCT;

 funciones de agrupamiento;

 cláusulas GROUP BY, ORDER BY, CONNECT BY o START WITH;

 subconsultas en la cláusula SELECT;

 vista creada con la opción WITH READ ONLY, y

 operaciones de combinación, con algunas excepciones, que están recogidas en la

documentación de Oracle.

c) Además, si una vista actualizable contiene pseudocolumnas o expresiones, la operación de

actualización no puede hacer referencia a ninguna de ellas.

d) Para que una vista basada en un  JOIN sea actualizable, deben cumplirse todas las
condiciones siguientes:

 La sentencia de actualización sólo puede afectar a una única tabla de las que forman
parte de la operación de combinación.
  Para una sentencia INSERT, la vista no puede haber sido creada con WITH CHECK
OPTION, y todas las columnas para las que se insertarán valores deben de pertenecer
a una tabla key-preserved.

 Para una sentencia UPDATE, la vista no puede haber sido creada con WITH CHECK
OPTION, y todas las columnas modificadas deben de pertenecer a una tabla key-
preserved.

 Para las sentencias DELETE sobre vistas basadas en JOIN, si el JOIN está formado por

más de una tabla key-preserved, se efectúa la eliminación sobre la primera tabla
indicada en la cláusula FROM.

Ejemplo de operaciones de actualización sobre vistas

Supongamos que efectuamos algunas actualizaciones de departamentos pares por medio de la

vista EvenDeptView.

1. INSERT INTO EvenDeptView VALUES (50,';R & D, ';Barcelona';);

Esta instrucción provoca la inserción sin ningún problema de una fila en la tabla Dept.

Ahora bien, si la vista EvenDeptView  hubiera sido creada con la opción WITH CHECK OPTION, al
ejecutar cualquiera de las sentencias siguientes:

1. INSERT INTO EvenDeptView VALUES (55, ';Design';, ';Girona';);

2. UPDATE EvenDeptView SET deptId = deptId + 1 WHERE deptId = 50;

no se podrían realizar las acciones solicitadas, ya que no verifican la cláusula WHERE de la

definición de la vista.

Descriptor de una tabla o vista

Para visualizar la descripción de una tabla o vista, se utiliza la sentencia SQL:

DESC [table_name|table_view]

4.3.Aspectos referentes a la seguridad en el SGBD Oracle 11g

4.3.1.Gestión de usuarios
a) Creación de usuarios

La sentencia SQL CREATE USER permite crear un nuevo usuario.

La sintaxis es:

Rol DBA

El rol DBA es aquel papel, rol, que permite a un usuario realizar tareas que corresponden al

administrador de la base de datos.

 1. CREATE USER user_name
2. IDENTIFIED {BY password|EXTERNALLY}
3. [DEFAULT TABLESPACE tablespace_name]
4. [TEMPORARY TABLESPACE tablespace_name]
5. [QUOTA {value [K|M]|UNLIMITED} ON tablespace_name [ , ... ]]
6. [PROFILE profile_name]
7. [PASSWORD EXPIRE]
8. [ACCOUNT {LOCK|UNLOCK}];

Espacios de tablas SYSTEM y SYSAUX

Cuando se instala el SGBD Oracle, automáticamente se crean los espacios de tablas  SYSTEM, en los

que se almacenan los objetos del sistema, y SYSAUX, que se utiliza para hacer operaciones auxiliares

del sistema.

Para que un usuario pueda conectarse, hay que darle los derechos sobre lo que puede hacer, en
este caso atribuyéndole los privilegios de sistema CREATE SESSION.

Descripción de los parámetros:

 IDENTIFIED: esta cláusula indica si el usuario es identificado por el sistema operativo

(EXTERNALLY) o mediante contraseña (BY contraseña). Desde la versión 11, las
contraseñas son por defecto sensibles a mayúsculas/minúsculas
(parámetro SEC_CASE_SENSITIVE_LOGON = TRUE por defecto). Esto significa que
podemos tener creadas cuentas de usuario sin permiso de conexión. Aunque puede
ser útil en la preparación de las cuentas de usuario sin activarlas de inmediato y
deshabilitar así el acceso a un usuario de forma temporal, hoy en día se bloquea o
desbloquea explícitamente una cuenta mediante ACCOUNT LOCK|UNLOCK.

 DEFAULT NAMESPACE: esta cláusula indica en qué espacio de tablas se crearán por
defecto los segmentos del usuario en caso de que no se explicite ninguna
cláusula TABLESPACE en el momento de la creación del segmento. Si esta cláusula se
omite, permanece el espacio de tablas definido por defecto en la base de datos.

 TEMPORARY NAMESPACE: esta cláusula indica en qué espacio de tablas se crearán por
defecto los segmentos de temporales del usuario, por ejemplo, creados en el
momento de ejecución de una operación de ordenación. Si esta cláusula se omite,
permanece el espacio de tablas temporal por defecto que haya definido en la base de
datos.

 QUOTA: este concepto permite limitar el espacio que un usuario puede emplear en un
espacio de tablas. Esta funcionalidad sólo afecta a los usuarios que pueden crear
segmentos, y en ningún caso a los usuarios finales de una aplicación, dado que éstos
se limitan a manipular datos. Por defecto, los usuarios no tienen ninguna cuota en
ningún espacio de tablas, y en cambio los DBA tienen una cuota ilimitada en todos los
 espacio de tablas. En todo caso, hay que evitar dar cuotas a los usuarios en
el  TABLESPACE SYSTEM y en el SYSAUX.

 PROFILE: esta cláusula indica el perfil asignado al usuario.

 PASSWORD EXPIRE: esta cláusula permite forzar la modificación de la contraseña en el

momento de la primera conexión. Carece de sentido si el usuario se identifica
mediante el sistema operativo.

 ACCOUNT: esta cláusula admite uno de los dos parámetros siguientes: LOCK, si la

cuenta existe pero evitamos que el usuario pueda conectarse a ella, o UNLOCK, donde
la conexión está autorizada.

Ejemplo

1. CREATE USER joan IDENTIFIED BY passtemp

2. DEFAULT TABLESPACE tablespace1
3. QUOTA UNLIMITED ON tablespace1
4. PASSWORD EXPIRE;

b) Modificación de un usuario

La sentencia SQL ALTER USER permite modificar un usuario. Las cláusulas son las mismas que
para la creación.

Ejemplo

1. ALTER USER joan

2. IDENTIFIED BY otherpasstemp
3. PASSWORD EXPIRE;
4.  
5. ALTER USER joan
6. DEFAULT TABLESPACE tablespace2
7. QUOTA UNLIMITED ON tablespace2;
8.  
9. ALTER USER joan ACCOUNT LOCK;

El primer ejemplo cambia la contraseña de un usuario y le obliga a volver a cambiarla en la

primera conexión. El segundo ejemplo modifica el espacio de tablas y asigna una cuota sin
límite. El tercer ejemplo prohíbe temporalmente la conexión al usuario especificado.

C) Eliminación de un usuario

La sentencia SQL DROP USER permite eliminar a un usuario.

1. DROP USER user_name [CASCADE];

Si un usuario es propietario de un conjunto de objetos, la opción CASCADE es necesaria para
eliminar tales objetos. En caso contrario, nos devolverá el código de error ORA-01922.

Reflexión

No se puede eliminar a un usuario que está conectado. En este caso nos devuelve el error ORA-01940.

También hay que recordar que con DROP USER no hay posibilidad de ROLLBACK porque es una

sentencia DDL.

4.3.2.Definición de perfiles
Un perfil es un conjunto de limitaciones de recursos identificadas por un nombre que pueden
asignarse a un usuario.

a) Creación de un perfil

La sentencia SQL CREATE PROFILE permite crear un nuevo perfil.

1. CREATE PROFILE profile_name LIMIT constraint_resources

Las limitaciones pueden ser de restricciones de recursos o para la gestión de contraseñas:

Parámetros para definir restricciones:

1) Resticciones de recursos:

 SESSION_PER_USER: número de sesiones simultáneas.

 CPU_PER_SESSION: asignación de CPU total por sesión.

 CPU_PER_CALL: asignación de CPU total por llamada.

 CONNECT_TIME: duración total de la conexión, en minutos.

 IDLE_TIME: tiempo de inactividad.

 LOGICAL_READS_PER_SESSION: número de lecturas lógicas por sesión.

 LOGICAL_READS_PER_CALL: número de lecturas lógicas por llamada.

 COMPOSITE_LIMIT: suma ponderada

de CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION y PRIVATE_
SGA. La vista RESOURCE_COST permite consultar las ponderaciones empleadas y la
sentencia ALTER RESOURCE COST permite modificar las ponderaciones.

2) Restricciones sobre contraseñas:

 FAILED_LOGIN_ATTEMPTS: número de intentos de conexión fallidos como paso previo al

bloqueo de cuenta.

 PASSWORD_LOCK_TIME: duración del bloqueo.

 PASSWORD_LIFE_TIME: duración de vida de la contraseña.

  PASSWORD_GRACE_TIME: periodo de gracia después de la caducidad de la contraseña.

 PASSWORD_REUSE_TIME: número de cambios de contraseña antes de que una

contraseña pueda reutilizarse.

 PASSWORD_VERIFY_FUCTION: función de verificación de la complejidad de la

contraseña. El script utlpwdmg:sql  del repositorio $ORACLE_HOME/rdms/admin
contiene un ejemplo de función de verificación.

En la mayoría de las restricciones mencionadas, se pueden emplear también las palabras

clave UNLIMITED y DEFAULT.

b) Modificación de un perfil

La sentencia ALTER PROFILE permite modificar un perfil. Por ejemplo:

1. ALTER PROFILE default LIMIT

2. SESSION_PER_USER 2
3. IDLE_TIME 15
4. FAILED_LOGIN_ATTEMPTS 3;

Los valores de los otros parámetros conservan su valor por defecto (UNLIMITED).

c) Asignación de un perfil a un usuario

Puede asignarse un perfil a un usuario en las situaciones siguientes:

1) En el momento de la creación de un usuario. Por ejemplo:

1. CREATE USER jordi IDENTIFIED BY password

2. PROFILE default
3. PASSWORD EXPIRE;

2) Cuando se modifica un usuario. Por ejemplo:

1. ALTER USER joan PROFILE default;

d) Información referente a usuarios y sus perfiles

Para obtener información sobre usuarios y perfiles, se pueden consultar las siguientes vistas del
diccionario de datos:

 DBA_USERS: información sobre los usuarios.

 DBA_TS_QUOTAS: información sobre cuotas de usuarios.

 DBA_PROFILES: información sobre los perfiles.

4.3.3.Identificación de usuarios
Un usuario puede identificarse desde el SGBD Oracle o bien desde el propio sistema operativo.
1) Identificación por Oracle: el usuario se conecta a la base de datos utilizando un nombre y
una contraseña. Por ejemplo:
SQL > CONNECT joan/GNB9175$
Conectado.

2) Identificación por el sistema operativo: Oracle no verifica la contraseña. Debe

configurarse el parámetro OS_AUTHEN_PREFIX  = OPS  si se quiere tener esta funcionalidad
habilitada.

4.3.4.Gestión de los privilegios

En una base de datos Oracle, los derechos de los usuarios se gestionan a partir del concepto
de privilegio. Un privilegio es:

 el derecho a ejecutar una sentencia SQL general, por ejemplo de crear una tabla (este
concepto se denomina privilegio de sistema);

 el derecho a acceder a un objeto de otro usuario (este concepto se denomina privilegio

de objeto).

1) Privilegios de sistema

Un privilegio de sistema es el derecho a ejecutar una sentencia SQL en general. Cada sentencia
SQL presenta como mínimo un privilegio de sistema asociado que tiene el mismo nombre que la
sentencia SQL. Así pues, la sentencia SQL CREATE TABLE tiene un privilegio de sistema asociado
llamado CREATE TABLE, que otorga el derecho de crear una tabla en su propio esquema.
También hay que tener en cuenta que el privilegio CREATE ANY TABLE proporciona el derecho de
crear tablas en cualquier esquema de la base de datos.

Los privilegios de sistema son una fuente de riesgo, sobre todo aquellos relacionados con la
gestión de usuarios y sus derechos (CREATE USER, ALTERUSER, DROP USER, GRANT ANY
PRIVILEGE, GRANT ANY ROLE) y todos aquellos que permiten eliminar objetos (DROP ANY
TABLE, DROP TABLESPACE, etc.).

Los privilegios de sistema se utilizan principalmente para controlar el uso de las sentencias DDL;
por lo general, están destinados a administradores y/o desarrolladores y a la cuenta propietaria
de la aplicación, rara vez a usuarios finales.

La sentencia para otorgar privilegios es:

Algunos privilegios
 CREATE SESSION: otorga a un usuario el derecho a conectarse. Si un usuario carece
de este privilegio, se devuelve el error ORA-01045.

 SELECT ANY DICTIONARY: permite consultar cualquier objeto que pertenezca al

diccionario de datos del esquema SYS.

1. GRANT privilege_name [ , ... ] TO (authorized|PUBLIC ) [ , ... ]

2. [WITH ADMIN OPTION];

Un privilegio puede asignarse a un usuario, a un grupo de usuarios o a todo el mundo (PUBLIC).

El privilegio asignado está activo inmediatamente. La cláusula WITH ADMIN OPTION proporciona
al beneficiario el derecho a transmitir este privilegio de sistema.

Es necesario que un usuario que quiera asignar o revocar un privilegio de sistema haya recibido
previamente:
  el mismo privilegio con la cláusula WITH ADMIN OPTION, y

 el privilegio de sistema GRANT ANY PRIVILEGE.

Para revocar un privilegio a un usuario, se utiliza la sentencia REVOKE.

La sentencia de revocación de privilegios es la siguiente:

1. REVOKE privilege_name [ , ... ] FROM (authorized|PUBLIC) [ ,... ]

No hay cascada en la revocación de un privilegio de sistema que haya sido transmitido gracias a
la cláusula WITH ADMIN OPTION.

Ejemplo

Si se asigna a Juan un privilegio con la opción WITH ADMIN OPTION y este lo ha transmitido a

Jorge, revocar este privilegio a Juan no tiene ningún efecto sobre el privilegio transmitido por él
a Jorge.

Si se ha asignado un privilegio a un usuario con la opción WITH ADMIN OPTION y se desea

eliminar esta opción, hay que revocar el privilegio y asignarlo de nuevo sin la opción WITH
ADMIN OPTION.

También hay que tener en cuenta que la sentencia REVOKE permite revocar privilegios que un
usuario haya recibido directamente, no los que el usuario recibe vía PUBLIC. Se pueden revocar
todos los privilegios de sistema mediante la sentencia:

1. REVOKE ALL PRIVILEGES FROM autorizado;

2) Privilegios de objeto

Un privilegio sobre un objeto es el derecho a acceder a un objeto de otro usuario. Por defecto, el
propietario es el único que tiene derecho a acceder al objeto.

Los privilegios de objeto se utilizan fundamentalmente para permitir a los usuarios finales de una
aplicación acceder a los objetos de la aplicación creados en una cuenta propietaria de la
aplicación. Para que otro usuario pueda acceder al objeto, es preciso que el propietario le asigne
un privilegio objeto:

Tabla 6. Ejemplos de privilegios.

Privilegio Definición Tabla Vista Secuencia Programa

SELECT [(columnas)] Derecho de lectura de datos. √ √ √ √

INSERT [(columnas)] Derecho de creación de √ √    

datos.

UPDATE [(columnas)] Derecho de actualización de √ √    

 Privilegio Definición Tabla Vista Secuencia Programa

datos*.

DELETE Derecho de eliminación de √ √    

datos*.

EXECUTE Derecho de ejecución de un       √

programa.

* Para lograr los privilegios UPDATE y DELETE, hay que conceder también el privilegio SELECT.

La sentencia SQL GRANT permite asignar un privilegio objeto.

La sentencia de otorgamiento de privilegios es la siguiente:

1. GRANT {privilege_name [(column_list)][ , ... ]|ALL [PRIVILEGES]}

2. ON [schema_name.] object_name
3. TO {authorized|PUBLIC} [ , ... ]
4. [WITH GRANT OPTION];

Para los privilegios INSERT y UPDATE, se pueden especificar las columnas para indicar a cuáles
de ellas se limita el privilegio.

Un privilegio puede asignarse a un usuario, a un grupo de usuarios o a todo el mundo (PUBLIC).

La cláusula WITH GRANT OPTION otorga al beneficiario el derecho a transmitir este privilegio

objeto.

Para asignar o revocar un privilegio objeto, es necesario:

 ser el propietario del objeto;

 haber recibido el mismo privilegio con la cláusula WITH ADMIN OPTION, y

 haber recibido el privilegio de sistema ANY OBJECT PRIVILEGE.

Cuando queremos acceder a un objeto del que se han recibido privilegios con la opción WITH
GRANT OPTION, es preciso calificarlo con el nombre del propietario, porque el SGBD asume por
defecto que este objeto se encuentra en el propio esquema.

Para facilitar la escritura de sentencias y que el esquema propietario de los objetos sea
transparente, es necesario emplear los sinónimos. La existencia de un sinónimo, y aunque éste
sea público, no da ningún derecho sobre el objeto subyacente.

La sentencia SQL REVOKE permite revocar un privilegio objeto.

La sentencia de revocación de privilegios es la siguiente:

1. REVOKE {privilege_name [ , ... ]|ALL [PRIVILEGES]}

 2. ON [schema_name.] object_name
3. FROM {authorized|PUBLIC}[ , ... ];

También hay que tener en cuenta que la sentencia REVOKE permite revocar privilegios que un
usuario haya recibido directamente, no los que el usuario recibe vía PUBLIC.

Se pueden revocar todos los privilegios de sistema mediante la sentencia:

1. REVOKE ALL PRIVILEGES ON...FROM... autorizado;

Se produce cascada en la revocación de un privilegio de objeto que haya sido transmitido gracias
a la cláusula WITH GRANT OPTION.

Ejemplo

Si se asigna a Juan un privilegio con la opción WITH GRANT OPTION y éste lo ha transmitido a

Jorge, el hecho de revocar después este mismo privilegio a Juan comporta también la revocación
inmediata sobre Jorge.

Si se ha asignado un privilegio a un usuario con la opción WITH GRANT OPTION y se desea

eliminar esta opción, es necesario revocar el privilegio y asignarlo de nuevo sin la opción WITH
GRANT OPTION.

Algunas consideraciones sobre privilegios en vistas y programas almacenados

El hecho de que un usuario disponga de un derecho sobre una vista no implica que tenga ningún
derecho sobre los objetos subyacentes a la vista. En cambio, por defecto, un programa
almacenado se ejecuta con los derechos del propietario. El comportamiento deseado se define
en el momento de la creación del programa almacenado gracias a la cláusula AUTHID.

La sintaxis de la cláusula AUTHID es:

1. AUTHID {CURRENT_USER|DEFINER}

Consulta de información al catálogo sobre privilegios

Existen diferentes vistas en el catálogo sobre los privilegios de sistema:

 DBA_SYS_PRIVS: muestra los privilegios de sistema asignados a los usuarios o a los

roles.

 SESION_PRIVS: muestra los privilegios de sistema actualmente activos en la sesión, ya

sean obtenidos directamente o mediante un rol.

 SYSTEM_PRIVILEGE_MAP: lista todos los privilegios de sistema.

 DBA_TAB_PRIVS: muestra los privilegios objeto asignados a los usuarios o a los roles
sobre la totalidad del objeto.

 DBA_COL_PRIVS: muestra los privilegios objeto asignados únicamente sobre ciertas

columnas del objeto.
  TABLE_PRIVILEGE_MAP: muestra la lista de todos los privilegios de objeto.

También podemos obtener del diccionario de datos información sobre los privilegios objeto a través de

las vistas siguientes:

4.3.5.Roles
Dentro de una organización, los roles se crean para modelizar funciones de trabajo diferentes.
Los permisos para realizar determinadas operaciones están asignados a roles específicos. A los
usuarios del sistema se les asigna determinados roles, a través de los cuales adquieren los
diferentes permisos que les permiten ejercer funciones específicas en el sistema informático.
Dado que los usuarios no tienen permisos de forma directa, sino que los adquieren a través de
su rol, la gestión de los derechos de cada usuario se convierte simplemente en una cuestión de
asignar los roles apropiados a la cuenta del usuario, cosa que simplifica las operaciones más
comunes, como por ejemplo añadir un usuario o cambiar las funciones de un usuario.

El modelo basado en roles RBAC define las siguientes tres normas primarias:

1) Asignación de roles: un sujeto puede ejercer un permiso sólo si el sujeto ha sido

seleccionado o se le ha asignado un rol.

2) Autorización de rol: es necesario que el rol activo de un sujeto esté autorizado por el
sujeto. Junto con el artículo 1, esta norma garantiza que los usuarios puedan asumir roles sólo
para los cuales están autorizados.

3) Autorización de permiso: un usuario puede ejercer un permiso sólo si el permiso es

autorizado por el rol activo del usuario. Junto con las normas 1 y 2, esta norma garantiza que
los usuarios ejerzan sólo los permisos para los cuales están autorizados.

Como restricciones adicionales, los roles se pueden combinar en una jerarquía de niveles, donde
los roles de nivel superior asumen los permisos de propiedad de sus subroles.

Figura 4. Modelo RBAC

Figura 4

En la figura podemos observar las reglas siguientes:

 Un sujeto puede tener varios roles.
  Un rol puede tener varios sujetos.

 Un rol puede tener muchos permisos.

 Un permiso puede ser asignado a múltiples roles.

 Una operación puede tener asignados muchos permisos.

 Un permiso puede estar asignado a muchas operaciones.

Los privilegios se pueden asignar directamente a los usuarios o mediante roles. El uso de RBAC
para administrar los privilegios de usuario está ampliamente aceptado como una buena práctica.
Oracle permite modelizar RBAC.

Un rol es un agrupamiento de privilegios definido por un nombre que puede atribuirse a un

usuario, de modo que el usuario recibe automáticamente los privilegios contenidos en el rol. Los
roles se utilizan para la gestión de los derechos.

La sentencia SQL CREATE ROLE permite crear un rol.

La sentencia de creación de un rol presenta la sintaxis siguiente:

Reflexión

Para crear un rol un usuario debe tener el privilegio de sistema CREATE ROLE.

1. CREATE ROLE role_name

2. [IDENTIFIED {BY password|EXTERNALLY|USING package}
3. |NOT IDENTIFIED];

En el momento de creación del rol es posible precisar con qué mecanismo se podrá activar, ya
sea mediante una contraseña, con autenticación externa (por ejemplo, mediante el sistema
operativo) o mediante un paquete.

Los requisitos y la sintaxis referente a la asignación y/o revocación de privilegios de sistema y de

objeto por roles son los mismos que para los usuarios. Los privilegios son inmediatamente
asignados o revocados según cuál sea la instrucción, y su efecto es inmediato sobre los usuarios
conectados que tienen el rol activo.

La sentencia de asignación de roles a usuarios presenta la sintaxis siguiente:

Reflexión

Un usuario puede tener varios roles, en cuyo caso los privilegios se acumulan (no hay efecto

“negativo”).

1. GRANT role_name [ , ... ]

2. TO {user_name|role_name|PUBLIC} [ , ... ]
3. [WITH ADMIN OPTION];

Los requisitos y la sintaxis referentes a la revocación de un rol a un usuario o a otro rol y sobre
la eliminación de un rol son parecidos a los explicados anteriormente.
Un rol asignado a un usuario se activa por defecto de forma automática en el momento de la
conexión del usuario. Si el usuario ya estaba conectado en el momento de la asignación, la
activación inmediata del rol no es automática, sino que hay que activar el rol con la
sentencia SET ROLE.

Disponer de la posibilidad de emplear diferentes roles sin que estén activos al mismo tiempo es
interesante porque:

 el parámetro MAX_ENABLED_ROLES (por defecto, treinta) limita el número de roles

activos simultáneos para un usuario;

 los roles protegidos con contraseña se pueden asignar a los usuarios aunque
permanezcan inactivos y, sin dar la contraseña al usuario, encargar a las aplicaciones
la activación de los roles, proporcionando las contraseñas cuando sea necesario.

La sentencia ALTER USER permite definir los roles por defecto de un usuario.

La sintaxis de la sentencia ALTER USER es la siguiente:

1. ALTER USER user_name

2. DEFAULT ROLE {role_name [ , ... ]|ALL {EXCEPT role_name [ , ... ]|NONE};

La sentencia SET ROLE permite activar o desactivar un rol.

La sintaxis de la sentencia SET ROLE es la siguiente:

1. SET ROLE {role_name [IDENTIFIED BY password][ ,... ]|ALL {EXCEPT role_name[ , ...
]|NONE};

Consulta al catálogo para obtener información sobre roles

Además de las ya consideradas (DBA_SYS_PRIVS, DBA_TAB_PRIVS y DBA_COL_PRIVS), existen

varias vistas del diccionario de datos que permiten obtener información sobre los roles:
 DBA_ROLES: listado de los roles existentes en la base de datos.

 DBA_APLICATION_ROLES: descripción de los roles que tienen los sistema de activación

por medio de un paquete.

 DBA_ROLE_PRIVS: roles asignados a usuarios o a otros roles.

 ROLE_SYS_PRIVS: privilegios de sistema asignados a roles.

 ROLE_TAB_PRIVS: privilegios de objeto asignados a roles.

 ROLE_ROLE_PRIVS: roles asignados a otros roles.

 SESION_ROLES: roles actualmente activos en la sesión.

Resumen
En este módulo hemos estudiado el procesamiento de consultas y vistas, así como la seguridad
en las bases de datos.

Hemos visto que es responsabilidad del SGBD transformar la consulta efectuada por un usuario
en otra equivalente pero que se pueda calcular de una forma más eficiente. Este proceso de
búsqueda de una buena estrategia para realizar el procesamiento de una consulta recibe el
nombre de optimización de consultas. En primer lugar se comprueba la correctitud semántica y
léxica de la consulta SQL, y después se transforma en un árbol que permite su análisis y
optimización. Después se decide cuál es la mejor estrategia de implementación física.

Una vista es una relación virtual que no existe físicamente en la base de datos, sino que se
genera cada vez que un usuario efectúa una solicitud. El mecanismo de las vistas contribuye a la
seguridad al permitir ocultar los detalles de la base de datos a ciertos usuarios. Con el uso de
disparadores de sustitución se puede conseguir que las vistas sean actualizables.

Hemos expuesto el concepto de seguridad de una base de datos como el conjunto de

mecanismos que protegen a la base de datos frente a amenazas intencionadas o accidentales.
La mayoría de SGBD proporcionan un mecanismo denominado control de acceso
discrecional (DAC) que gestiona los privilegios empleando el lenguaje SQL. Aunque algunos
SGBD proporcionan técnicas de control de acceso obligatorio (MAC) basadas en políticas de nivel
de sistema que no pueden ser alteradas por los usuarios, el estándar SQL no incluye soporte
para MAC. Finalmente, hemos introducido brevemente la legislación vigente de protección de
datos, así como la necesidad de velar por cualquier tipo de datos de carácter personal que deben
estar protegidos por ley.

Glosario
amenaza f
Cualquier situación o suceso intencionado o accidental que pueda afectar de manera
adversa al sistema y, en consecuencia, a la organización.

autenticación f
Mecanismo por el cual se determina si un usuario es quien dice ser.

autorización f
Concesión de un derecho o privilegio que permite a un sujeto acceder legítimamente al
sistema o a un objeto del sistema.

cifrado m
Codificación de datos mediante un algoritmo especial que provoca que estos datos no
sean legibles para ningún programa que no disponga de la clave de descifrado.

heurístico -a adj.
Cualidad de los métodos que utilizan el razonamiento y las experiencias pasadas para
encontrar la mejor solución a un problema.

mecanismo de copia de seguridad m

Proceso de realizar de forma periódica una copia de la base de datos, del archivo de
registro y, posiblemente, de algún programa, y almacenarla en un dispositivo de
almacenamiento fuera de línea.

optimización f
 Proceso por el cual se transforma una consulta en otra equivalente pero más eficiente.
La optimización se puede realizar en el ámbito semántico, sintáctico y físico.

plan de ejecución m
Conjunto de operaciones (lógicas o físicas) necesarias para obtener el resultado de una
consulta.

registro m
Proceso de mantener un diario donde se almacenen los cambios efectuados en la base
de datos con el objetivo de realizar la recuperación de manera efectiva en caso de
quiebra del sistema.

vista f
Resultado dinámico de una o más operaciones relacionales sobre una base de datos con
el objetivo de producir otra relación.

Bibliografía
Connolly, T.; Begg, C. (2005). Sistemas de bases de datos (4.ª ed.). Madrid: Pearson.

Huey, P. (2011). Oracle database security guide 11g release 1. Oracle.

Lorentz, D.; Roeser, M. B. (2011). Oracle database SQL language reference, 11g Release 2.
Oracle.

Silberschatz, A.; Korth, H.; Sudarshan, S. (2006). Fundamentos de bases de datos (5.ª ed.).

Madrid: McGraw-Hill. Edición de 2011 en eBook.

Weinberg, P.; Groff, J.; Oppel, A. (2009). SQL. The complete reference (3.ª ed.). McGraw-
Hill.