CAPITULO 1

SISTEMAS DE ARCHIVOS TRADICIONALES VS BASES DE DATOS

1.1. Sistemas de ficheros

Un sistema de ficheros es un conjunto de programas que prestan servicio a los usuarios finales.
Cada programa define y maneja sus propios datos.
Los sistemas de ficheros surgieron al tratar de informatizar el manejo de los archivadores
manuales con objeto de proporcionar un acceso más eficiente a los datos.
En lugar de establecer un sistema centralizado en donde almacenar todos los datos de la
organización o empresa, se escogió un modelo descentralizado en el que cada sección o
departamento almacena y gestiona sus propios datos. Para comprender esto vamos a utilizar
como ejemplo una empresa inmobiliaria cuya descripción completa se encuentra en el último
apartado de este capítulo.
En esta inmobiliaria, el departamento de ventas se encarga de alquilar inmuebles. Por ejemplo,
cuando un propietario pasa por el departamento de ventas para ofrecer en alquiler su piso, se
rellena un formulario en donde se recogen los dat os del piso, como la dirección y el número de
habitaciones, y los datos del propietario. El departamento de ventas también se encarga de
atender a los clientes que desean alquilar un inmueble. Cuando un cliente (posible inquilino)
pasa por este departamento se rellena un formulario con sus datos y sus preferencias: si quiere un
piso o una casa, el importe mensual que está dispuesto a pagar por el alquiler, etc. Para gestionar
toda esta información, el departamento de ventas posee un sistema de información. El sistema
tiene tres ficheros: fichero de inmuebles, fichero de propietarios y fichero de inquilinos.

Se puede ver claramente que hay una gran cantidad de datos repetidos en los ficheros de estos
departamentos, algo que siempre ocurre en los sistemas de ficheros. A raíz de esto, los sistemas
de ficheros presentan una serie de inconvenientes:
 Separación y aislamiento de los datos. Cuando los datos se separan en distintos ficheros,
es más complicado acceder a ellos, ya que el programador de aplicaciones de be
sincronizar el procesamiento de los distintos ficheros implicados para asegurar que se
extraen los datos correctos.
 Duplicación de datos. La redundancia de datos existente en los sistemas de ficheros hace
que se desperdicie espacio de almacenamiento y lo que es más importante: puede llevar a
que se pierda la consistencia de los datos. Se produce una inconsistencia cuando copias
de los mismos datos no coinciden.
 Dependencia de datos. Ya que la estructura física de los datos (la definición de los
ficheros y de los registros) se encuentra codificada en los programas de aplicación,
cualquier cambio en dicha estructura es difícil de realizar. El programador debe
identificar todos los programas afectados por este cambio, modificarlos y volverlos a
probar, lo que cuesta mucho tiempo y está sujeto a que se produzcan errores. A este
problema, tan característico de los sistemas de ficheros, se le denomina también falta de
independencia de datos lógica -física.
 Formatos de ficheros incompatibles. Ya que la estructura de los ficheros se define en los
programas de aplicación, es completamente dependiente del lenguaje de programación.
 La incompatibilidad entre ficheros generados por distintos lenguajes hace que los
ficheros sean difíciles de procesar de modo conjunto.
 Consultas fijas y proliferación de programas de aplicación. Desde el punto de vista de
los usuarios finales, los sistemas de ficheros fueron un gran avance comparados a los
sistemas manuales. A consecuencia de esto, creció la necesidad de realizar distint os tipos
de consultas de datos. Sin embargo, los sistemas de ficheros son muy dependientes del
programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser
programado por él. En algunas organizaciones se conformaron con fijar e l tipo de
consultas e informes, siendo imposible realizar otro tipo de consultas que no se hubieran
tenido en cuenta a la hora de escribir los programas de aplicación.
En otras organizaciones hubo una proliferación de programas de aplicación para resolver
todo tipo de consultas, hasta el punto de desbordar al departamento de proceso de datos,
que no daba abasto para validar, mantener y documentar dichos programas.

1.2. Sistemas de bases de datos

Los inconvenientes de los sistemas de ficheros se pueden a tribuir a dos factores:
 La definición de los datos se encuentra codificada dentro de los programas de aplicación,
en lugar de estar almacenada aparte y de forma independiente.
 No hay control sobre el acceso y la manipulación de los datos más allá de lo i mpuesto por
los programas de aplicación.
Para trabajar de un modo más efectivo, surgieron las bases de datos y los sistemas de gestión de
bases de datos (SGBD).
Una base de datos es un conjunto de datos almacenados entre los que existen relaciones lógica s y
ha sido diseñada para satisfacer los requerimientos de información de una empresa u
organización. En una base de datos, además de los datos, también se almacena su descripción.
La base de datos es un gran almacén de datos que se define una sola vez y que se utiliza al
mismo tiempo por muchos departamentos y usuarios. En lugar de trabajar con ficheros
desconectados e información redundante, todos los datos se integran con una mínima cantidad de
duplicidad. La base de datos no pertenece a un departamento , se comparte por toda la
organización. Además, la base de datos no sólo contiene los datos de la organización, también
almacena una descripción de dichos datos. Esta descripción es lo que se denomina metadatos, se
almacena en el diccionario de datos o catálogo y es lo que permite que exista independencia de
datos lógica-física.
El modelo seguido con los sistemas de bases de datos, en donde se separa la definición de los
datos de los programas de aplicación, es muy similar al modelo que se sigue en la actu alidad para
el desarrollo de programas, en donde se da una definición interna de un objeto y una definición
externa separada. Los usuarios del objeto sólo ven la definición externa y no se deben preocupar
de cómo se define internamente el objeto y cómo fun ciona. Una ventaja de este modelo,
conocido como abstracción de datos, es que se puede cambiar la definición interna de un objeto
sin afectar a sus usuarios ya que la definición externa no se ve alterada. Del mismo modo, los
sistemas de bases de datos sepa ran la definición de la estructura de los datos, de los programas de
aplicación y almacenan esta definición en la base de datos. Si se añaden nuevas estructuras de
datos o se modifican las ya existentes, los programas de aplicación no se ven afectados ya q ue no
dependen directamente de aquello que se ha modificado.
El sistema de gestión de la base de datos (SGBD) es una aplicación que permite a los usuarios
definir, crear y mantener la base de datos, y proporciona acceso controlado a la misma.
El SGBD es la aplicación que interacciona con los usuarios de los programas de aplicación y la
base de datos. En general, un SGBD proporciona los siguientes servicios:
 Permite la definición de la base de datos mediante el lenguaje de definición de datos . Este
lenguaje permite especificar la estructura y el tipo de los datos, así como las restricciones
sobre los datos. Todo esto se almacenará en la base de datos.
 Permite la inserción, actualización, eliminación y consulta de datos mediante el lenguaje
de manejo de datos. El hecho de disponer de un lenguaje para realizar consultas reduce el
problema de los sistemas de ficheros, en los que el usuario tiene que trabajar con un
conjunto fijo de consultas, o bien, dispone de un gran número de programas de aplicación
costosos de gestionar.
Hay dos tipos de lenguajes de manejo de datos: los procedurales y los no procedurales.
Estos dos tipos se distinguen por el modo en que acceden a los datos. Los lenguajes
procedurales manipulan la base de datos registro a registro, mientr as que los no
procedurales operan sobre conjuntos de registros. En los lenguajes procedurales se
especifica qué operaciones se deben realizar para obtener los datos resultado, mientras
que en los lenguajes no procedurales se especifica qué datos deben obte nerse sin decir
cómo hacerlo. El lenguaje no procedural más utilizado es el SQL (Structured Query
Language) que, de hecho, es un estándar y es el lenguaje de los SGBD relacionales.
 Proporciona un acceso controlado a la base de datos mediante:
 un sistema de seguridad, de modo que los usuarios no autorizados no puedan
acceder a la base de datos;
 un sistema de integridad que mantiene la integridad y la consistencia de los datos;
 un sistema de control de concurrencia que permite el acceso compartido a la ba se
de datos;
 un sistema de control de recuperación que restablece la base de datos después de
que se produzca un fallo del hardware o del software;
 un diccionario de datos o catálogo accesible por el usuario que contiene la
descripción de los datos de la base de datos.
A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura física de los datos y su
almacenamiento. Con esta funcionalidad, el SGBD se convierte en una herramienta de gran
utilidad. Sin embargo, desde el punto de vista del us uario, se podría discutir que los SGBD han
hecho las cosas más complicadas, ya que ahora los usuarios ven más datos de los que realmente
quieren o necesitan, puesto que ven la base de datos completa. Conscientes de este problema, los
SGBD proporcionan un mecanismo de vistas que permite que cada usuario tenga su propia vista
o visión de la base de datos. El lenguaje de definición de datos permite definir vistas como
subconjuntos de la base de datos.
Las vistas, además de reducir la complejidad permitiendo q ue cada usuario vea sólo la parte de la
base de datos que necesita, tienen otras ventajas:
 Las vistas proporcionan un nivel de seguridad, ya que permiten excluir datos para que
ciertos usuarios no los vean.
 Las vistas proporcionan un mecanismo para que l os usuarios vean los datos en el formato
que deseen.
 Una vista representa una imagen consistente y permanente de la base de datos, incluso si
la base de datos cambia su estructura.
Todos los SGBD no presentan la misma funcionalidad, depende de cada produ cto. En general,
los grandes SGBD multiusuario ofrecen todas las funciones que se acaban de citar y muchas
más. Los sistemas modernos son conjuntos de programas extremadamente complejos y
sofisticados, con millones de líneas de código y con una documentaci ón consistente en varios
volúmenes. Lo que se pretende es proporcionar un sistema que permita gestionar cualquier tipo
de requisitos y que tenga un 100% de fiabilidad ante cualquier fallo hardware o software. Los
SGBD están en continua evolución, tratando de satisfacer los requerimientos de todo tipo de
usuarios. Por ejemplo, muchas aplicaciones de hoy en día necesitan almacenar imágenes, vídeo,
sonido, etc. Para satisfacer a este mercado, los SGBD deben cambiar. Conforme vaya pasando el
tiempo irán surgiendo nuevos requisitos, por lo que los SGBD nunca permanecerán estáticos.

1.3. Historia de los sistemas de bases de datos

Como se ha visto en este capítulo, los predecesores de los sistemas de bases de datos fueron los
sistemas de ficheros. No hay un mome nto concreto en que los sistemas de ficheros hayan cesado
y hayan dado comienzo los sistemas de bases de datos. De hecho, todavía existen sistemas de
ficheros en uso.
Se dice que los sistemas de bases de datos tienen sus raíces en el proyecto estadouniden se Apolo
de mandar al hombre a la luna, en los años sesenta. En aquella época, no había ningún sistema
que permitiera gestionar la inmensa cantidad de información que requería el proyecto. La
primera empresa encargada del proyecto, NAA (North American Avia tion), desarrolló un
software denominado GUAM (General Update Access Method) que estaba basado en el
concepto de que varias piezas pequeñas se unen para formar una pieza más grande, y así
sucesivamente hasta que el producto final está ensamblado. Esta estr uctura, que tiene la forma de
un árbol, es lo que se denomina una estructura jerárquica. A mediados de los sesenta, IBM se
unió a NAA para desarrollar GUAM en lo que ahora se conoce como IMS (Information
Management System). El motivo por el cual IBM restri ngió IMS al manejo de jerarquías de
registros fue el de permitir el uso de dispositivos de almacenamiento serie, más exactamente las
cintas magnéticas, ya que era un requisito del mercado por aquella época.
A mitad de los sesenta, se desarrolló IDS (Integ rated Data Store), de General Electric. Este
trabajo fue dirigido por uno de los pioneros en los sistemas de bases de datos, Charles
Bachmann. IDS era un nuevo tipo de sistema de bases de datos conocido como sistema de red,
que produjo un gran efecto sobre los sistemas de información de aquella generación. El sistema
de red se desarrolló, en parte, para satisfacer la necesidad de representar relaciones entre datos
más complejas que las que se podían modelar con los sistemas jerárquicos, y, en parte, para
imponer un estándar de bases de datos. Para ayudar a establecer dicho estándar, CODASYL
(Conference on Data Systems Languages), formado por representantes del gobierno de EEUU y
representantes del mundo empresarial, formaron un grupo denominado DBTG (Data Ba se Task
Group), cuyo objetivo era definir unas especificaciones estándar que permitieran la creación de
bases de datos y el manejo de los datos. El DBTG presentó su informe final en 1971 y aunque
éste no fue formalmente aceptado por ANSI (American National Standards Institute), muchos
sistemas se desarrollaron siguiendo la propuesta del DBTG. Estos sistemas son los que se
conocen como sistemas de red, o sistemas CODASYL o DBTG.
Los sistemas jerárquico y de red constituyen la primera generación de los SGBD. Pero estos
sistemas presentan algunos inconvenientes:
 Es necesario escribir complejos programas de aplicación para responder a cualquier tipo
de consulta de datos, por simple que ésta sea.
 La independencia de datos es mínima.
 No tienen un fundamento teórico.
En 1970 Codd, de los laboratorios de investigación de IBM, escribió un artículo presentando el
modelo relacional. En este artículo, presentaba también los inconvenientes de los sistemas
previos, el jerárquico y el de red. Entonces, se comenzaron a desarrollar muchos sistemas
relacionales, apareciendo los primeros a finales de los setenta y principios de los ochenta. Uno de
los primeros es System R, de IBM, que se desarrolló para probar la funcionalidad del modelo
relacional, proporcionando una imple mentación de sus estructuras de datos y sus operaciones.
Esto condujo a dos grandes desarrollos:
 El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha
convertido en el lenguaje estándar de los sistemas relacionales.
 La producción de varios SGBD relacionales durante los años ochenta, como DB2 y
SLQ/DS de IBM, y ORACLE de ORACLE Corporation.
Hoy en día, existen cientos de SGBD relacionales, tanto para microordenadores como para
sistemas multiusuario, aunque muchos no son completa mente fieles al modelo relacional.
Otros sistemas relacionales multiusuario son INGRES de Computer Associates, Informix de
Informix Software Inc. y Sybase de Sybase Inc. Ejemplos de sistemas relacionales de
microordenadores son Paradox y dBase IV de Borla nd, Access de Microsoft, FoxPro y R:base de
Microrim.
Los SGBD relacionales constituyen la segunda generación de los SGBD. Sin embargo, el
modelo relacional también tiene sus fallos, siendo uno de ellos su limitada capacidad al modelar
los datos. Se ha hecho mucha investigación desde entonces tratando de resolver este problema.
En 1976, Chen presentó el modelo entidad -relación, que es la técnica más utilizada en el diseño
de bases de datos. En 1979, Codd intentó subsanar algunas de las deficiencias de su m odelo
relacional con una versión extendida denominada RM/T (1979) y más recientemente RM/V2
(1990). Los intentos de proporcionar un modelo de datos que represente al mundo real de un
modo más fiel han dado lugar a los modelos de datos semánticos.
Como respuesta a la creciente complejidad de las aplicaciones que requieren bases de datos, han
surgido dos nuevos modelos: el modelo de datos orientado a objetos y el modelo relacional
extendido. Sin embargo, a diferencia de los modelos que los preceden, la compo sición de estos
modelos no está clara. Esta evolución representa la tercera generación de los SGBD.

1.4. Ventajas e inconvenientes de los sistemas de bases de datos

Los sistemas de bases de datos presentan numerosas ventajas que se pueden dividir en dos
grupos: las que se deben a la integración de datos y las que se deben a la interface común que
proporciona el SGBD.
Ventajas por la integración de datos
 Control sobre la redundancia de datos. Los sistemas de ficheros almacenan varias copias
de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de
almacenamiento, además de provocar la falta de consistencia de datos. En los sistemas de
bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias
copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la
redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones
entre los datos, o bien es necesaria para mejorar las prestaciones.
 Consistencia de datos. Eliminando o controlando las redundancias de datos se reduce en
gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola
vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los
 usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia,
el propio sistema puede encargarse de garantizar que todas las copias se mantienen
consistentes. Desgraciadamente, no todos los SGBD de hoy en día se encargan de
mantener automáticamente la consistencia.
 Más información sobre la misma cantidad de datos. Al estar todos los datos integrados,
se puede extraer información adicional sobre los mismos.
 Compartición de datos. En los sistemas de ficheros, los ficheros pertenecen a las
personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la
base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que
estén autorizados. Además, las nuevas aplicaciones que se vayan creando pueden utilizar
los datos de la base de datos existente.
 Mantenimiento de estándares. Gracias a la integración es más fácil respetar los
estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e
internacionales. Estos estándares p ueden establecerse sobre el formato de los datos para
facilitar su intercambio, pueden ser estándares de documentación, procedimientos de
actualización y también reglas de acceso.
Ventajas por la existencia del SGBD
 Mejora en la integridad de datos. La integridad de la base de datos se refiere a la validez
y la consistencia de los datos almacenados. Normalmente, la integridad se expresa
mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden
aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de
mantenerlas.
 Mejora en la seguridad. La seguridad de la base de datos es la protección de la base de
datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la
integración de datos en los sistemas de bases de datos hace que éstos sean más
vulnerables que en los sistemas de ficheros. Sin embargo, los SGBD permiten mantener
la seguridad mediante el establecimiento de claves para identificar al personal autorizado
a utilizar la base de datos. Las autorizaciones se pueden realizar a nivel de operaciones,
de modo que un usuario puede estar autorizado a consultar ciertos datos pero no a
actualizarlos, por ejemplo.
 Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan lenguaj es de
consultas o generadores de informes que permiten al usuario hacer cualquier tipo de
consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación
que realice tal tarea.
 Mejora en la productividad. El SGBD proporciona much as de las funciones estándar que
el programador necesita escribir en un sistema de ficheros. A nivel básico, el SGBD
proporciona todas las rutinas de manejo de ficheros típicas de los programas de
aplicación. El hecho de disponer de estas funciones permite al programador centrarse
mejor en la función específica requerida por los usuarios, sin tener que preocuparse de los
detalles de implementación de bajo nivel. Muchos SGBD también proporcionan un
entorno de cuarta generación consistente en un conjunto de h erramientas que simplifican,
en gran medida, el desarrollo de las aplicaciones que acceden a la base de datos. Gracias
a estas herramientas, el programador puede ofrecer una mayor productividad en un
tiempo menor.
 Mejora en el mantenimiento gracias a la i ndependencia de datos. En los sistemas de
ficheros, las descripciones de los datos se encuentran inmersas en los programas de
 aplicación que los manejan. Esto hace que los programas sean dependientes de los datos,
de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en
disco, requiere cambios importantes en los programas cuyos datos se ven afectados. Sin
embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo
que se conoce como independencia de d atos, gracias a la cual se simplifica el
mantenimiento de las aplicaciones que acceden a la base de datos.
 Aumento de la concurrencia. En algunos sistemas de ficheros, si hay varios usuarios que
pueden acceder simultáneamente a un mismo fichero, es posibl e que el acceso interfiera
entre ellos de modo que se pierda información o, incluso, que se pierda la integridad. La
mayoría de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que
no ocurran problemas de este tipo.
 Mejora en los servicios de copias de seguridad y de recuperación ante fallos. Muchos
sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias
para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen
que hacer copias de seguridad cada día, y si se produce algún fallo, utilizar estas copias
para restaurarlos. En este caso, todo el trabajo realizado sobre los datos desde que se hizo
la última copia de seguridad se pierde y se tiene que volver a realizar. Sin e mbargo, los
SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido
cuando se produce un fallo.
Inconvenientes de los sistemas de bases de datos
 Complejidad. Los SGBD son conjuntos de programas muy complejos con una gran
funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder sacar un
buen partido de ellos.
 Tamaño. Los SGBD son programas complejos y muy extensos que requieren una gran
cantidad de espacio en disco y de memoria para trabajar de forma eficiente.
 Coste económico del SGBD. El coste de un SGBD varía dependiendo del entorno y de la
funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador personal puede
costar 500 euros, mientras que un SGBD para un sistema multiusuario que dé servicio a
cientos de usuarios puede costar entre 10.000 y 100.000 euros. Además, hay que pagar
una cuota anual de mantenimiento que suele ser un porcentaje del precio del SGBD.
 Coste del equipamiento adicional. Tanto el SGBD, como la propia base de datos, pueden
hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar
las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande
o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación
de un sistema de bases de datos sea más cara.
 Coste de la conversión. En algunas ocasiones, el coste del SGBD y el coste del equipo
informático que sea necesario adquirir para su buen funcionamiento, es insignificante
comparado al coste de convertir la aplicación actual en un sistema de bases de datos. Este
coste incluye el coste de enseñar a la plantilla a utilizar estos sistemas y, probablemente,
el coste del personal especializado para ayudar a realizar la conversión y poner en marcha
el sistema. Este coste es una de las razones principales por las que algunas empresas y
organizaciones se resisten a cambiar su sistema actual de ficheros por un sistema de bases
de datos.
 Prestaciones. Un sistema de ficheros está escrito para una aplicación específica, por lo
que sus prestaciones suelen ser muy buenas. Sin embargo, los SGBD están escritos para
 ser más generales y ser útiles en muchas aplicaciones, lo que puede hacer que algunas de
ellas no sean tan rápidas como antes.
 Vulnerable a los fallos. El hecho de que todo esté centralizado en el SGBD hace que el
sistema sea más vulnerable ante los fallos que puedan producirse.

CAPITULO 2

ORGANIZACIÓN DE FICHEROS

2.1. Conceptos fundamentales de organizaciones de ficheros

En los dispositivos de almacenamiento secundario , la base de datos se organiza en uno o varios
ficheros. Cada fichero está formado por una serie de registros, y cada registro se divide en varios
campos. Normalmente, los registros corresponden a entidades: personas, objetos, eventos, etc.,
siendo los campos aquellos atributos o propiedades que se desea conocer sobre las entidades: el
nombre de cada persona, el color del objeto, la fecha del evento, etc.
El orden en que se colocan los registros en un fichero depende de su estructura. Los principales
tipos de estructuras de ficheros son los siguientes:
 Ficheros desordenados. En estos ficheros los registros no siguen un orden específico.
 Ficheros ordenados. En estos ficheros los registros están ordenados por el valor de un
determinado campo.
 Ficheros dispersos. En estos ficheros los registros se almacenan en la posición del fichero
que indica una función matemática al ser aplicada sobre un determinado campo.
 Agrupamiento. Varios ficheros intercalan sus registros de modo que éstos queden
agrupados por el valor de algún campo que tienen en común.
Los pasos que se deben llevar a cabo para almacenar y acceder a un registro de un fichero es lo
que se denomina un método de acceso. Hay distintos métodos de acceso, algunos de los cuales
sólo se pueden utilizar con determinadas estructuras de ficheros.

2.2. Ficheros desordenados

En un fichero desordenado, también denominado fichero heap, los registros se colocan en el
fichero en el orden en que se van insertando. Cuando llega un nuevo registro, se inserta en el
último bloque del fichero; si el fichero está lleno, se le añade más espacio. Esta organización
hace que la inserción sea muy eficiente. Sin embargo, cuando se trata de acceder a un registro del
fichero, es necesario realizar una búsqueda lineal recorriendo todos los bloques del fichero uno
tras otro, hasta encontrar el registro deseado. Esto hace que las búsquedas de registros en los
ficheros desordenados sean muy lentas.
Si lo que se desea es obtener todos los registros del fichero presentándolos en un det erminado
orden (según el valor de alguno de sus campos), es necesario realizar una ordenación externa si
el fichero completo no cabe en memoria principal: se van leyendo los registros, se escriben de
forma ordenada en un fichero temporal en disco y, finalm ente, se accede a este último fichero
para leer los registros una vez ordenados.
Para eliminar un registro es necesario traer a memoria principal el bloque en el que se encuentra,
después se marca el registro como borrado y, por último, se vuelve a escrib ir el bloque en el
mismo lugar en que se encontraba. El espacio que ocupaba el registro borrado no se reutiliza, lo
que hace que empeoren las prestaciones, por lo que, cada cierto tiempo, habrá que realizar una
reorganización del fichero para recuperar est e espacio.
Para modificar un registro también es necesario traerlo a memoria principal y actualizarlo. Si el
registro modificado cabe en el bloque en el que se encontraba, se reescribe el bloque en su sitio.
Si el registro modificado ha aumentado su tamañ o de modo que no cabe en el bloque, hay que
borrar el registro original y añadir el registro modificado al final del fichero.
Los ficheros desordenados son los más adecuados cuando se trata de cargar grandes cantidades
de datos, ya que la inserción es muy eficiente al no tener que realizarse ningún cálculo para
determinar la posición que debe ocupar el registro en el fichero.

2.3. Ficheros dispersos

En los ficheros dispersos, la dirección de cada registro se calcula aplicando cierta función sobre
uno o varios de sus campos, denominados campos de dispersión. A la función se le denomina
función de dispersión. Los registros de este tipo de ficheros parece que han sido distribuidos de
forma aleatoria por el mismo, por lo que a estos ficheros también se les de nomina ficheros
aleatorios o ficheros directos. El acceso a los datos es muy rápido sólo si se busca con la
condición de igualdad sobre el campo de dispersión.
La función de dispersión se debe escoger de modo que los registros queden distribuidos
uniformemente en todo el fichero. La técnica más popular consiste en utilizar el resto de la
división entera: se toma el valor de un campo, se divide entre un valor determinado y se utiliza el
resto de la división entera para obtener la dirección en disco. Otra té cnica es el plegado. Consiste
en tomar distintas partes del campo de dispersión y aplicarles alguna función aritmética. Por
ejemplo, si el campo de dispersión es el DNI, se pueden tomar sus dígitos por parejas y sumarlos.
Si el campo tiene caracteres, se p uede tomar su valor ASCII para aplicar la operación aritmética.
En realidad, la función de dispersión produce un número de bloque relativo. En una tabla que se
encuentra en la cabecera del fichero se convierte este número en la dirección del bloque en el
disco.
El problema que presentan la mayoría de las funciones de dispersión es que no garantizan
direcciones únicas, de modo que varios registros se asocian a una misma dirección de bloque. Si
a un bloque se asocian más registros de los que realmente caben, se producen colisiones que hay
que resolver. Los registros que se destinan a un mismo bloque se denominan sinónimos.
Hay varias técnicas para gestionar las colisiones:
 Direccionamiento abierto. Cuando se produce una colisión, el sistema hace una búsqued a
lineal a partir del bloque al que iba destinado el registro para encontrar un hueco donde
insertarlo. Si se llega al final del fichero sin encontrar hueco, se continúa la búsqueda
desde el principio.
 Encadenamiento. En lugar de buscar un hueco libre, lo que se hace es disponer de una
serie de bloques como área de desborde. Cuando se produce una colisión, el registro se
sitúa en el área de desborde y mediante un puntero en el bloque colisionado, se apunta a
la dirección del bloque de desborde y la posició n relativa del registro dentro del bloque.
Además, todos los registros que han colisionado en un mismo bloque se van encadenando
mediante punteros.
 Dispersión múltiple. Esta técnica de resolución de colisiones consiste en utilizar una
segunda función de dispersión cuando la primera ha producido una colisión. El objetivo
es producir una nueva dirección que no provoque colisión. Normalmente, la segunda
función da una dirección de bloque situada en un área de desborde.
Aunque la dispersión es el método de ac ceso directo más rápido a través del campo de
dispersión, no es muy útil cuando también se quiere acceder al fichero a través de otro campo.
Ya que la mayoría de las funciones de dispersión que se utilizan no mantienen el orden entre los
registros, tampoco es útil cuando se quiere leer los registros ordenadamente.
Buscar un registro a través de un campo que no es el de dispersión es tan caro como buscar un
registro en un fichero desordenado: es preciso realizar una búsqueda lineal. Para borrar un
registro hay que eliminarlo del bloque en el que se encuentra. Si el bloque tiene una lista de
desborde, se puede mover un registro de la lista al bloque. Si el registro a borrar está en la lista
de desborde, sólo hay que eliminarlo de ella. En este caso, será nece sario mantener una lista
enlazada de posiciones de desborde no utilizadas. Si al actualizar un registro se modifica el
campo de dispersión, es muy probable que el registro tenga que cambiar de posición, por lo que
habrá que borrarlo e insertarlo de nuevo.

Otra desventaja de la dispersión es que el espacio de almacenamiento es fijo, por lo que es difícil
que el fichero se expanda o se comprima dinámicamente. Si el fichero tiene bloques y en cada
uno caben registros, como máximo se podrán almacenar registros. Si hay menos de registros,
quedará espacio sin utilizar. Si hay más de registros, habrá muchas colisiones y esto hará que el
acceso sea más lento, ya que habrá largas listas de desborde. En este caso, puede ser preferible
ampliar el espacio de almacenamiento y cambiar a otra función de dispersión, lo que implica q ue
habrá que redistribuir todos los registros (reorganizar el fichero). Ya que el espacio de
almacenamiento es fijo, a este tipo de dispersión se la denomina dispersión estática.
Hay varios esquemas que tratan de remediar esta situación: la dispersión dinámica y la
dispersión extensible, que almacenan una estructura de acceso además del fichero, y la
dispersión lineal, que no necesita dicha estructura.
Estas técnicas aprovechan el que las funciones de dispersión dan como resultado un valor entero
no negativo que, por tanto, se puede representar como un número binario. Los registros se
distribuyen entre los bloques teniendo en cuenta los primeros bits de este número, que se
denomina valor de dispersión.

2.4. Ficheros ordenados

En los ficheros ordenados, l os registros se encuentran ordenados físicamente según el valor de
uno o varios campos. A este campo o campos se les denomina campos de ordenación.
Cuando se trata de buscar un registro en un fichero ordenado, se puede utilizar una búsqueda
binaria sólo cuando se busca por el campo de ordenación. Si la búsqueda se realiza a través de
cualquier otro campo, se debe hacer una búsqueda lineal. Si se quiere leer el fichero
ordenadamente, la operación será muy eficiente si el orden escogido es el del campo de
ordenación. Si el orden de lectura es sobre cualquier otro campo, es preciso realizar una
ordenación externa.
Para insertar un registro hay que encontrar su posición en el fichero según el orden establecido,
hacer hueco y escribir. Si hay espacio suficiente en el bloque correspondiente, se reordena el
bloque y se escribe en el fichero. Si no hay espacio en el bloque, habrá que mover algún registro
al siguiente bloque. Si este último bloque no tiene espacio suficiente para estos registros, habrá
que mover algunos registros al bloque siguiente, y así sucesivamente. Esto hace que la inserción
de un registro pueda ser muy costosa. Una solución consiste en tener un fichero desordenado de
desborde, en donde se van realizando todas las inserciones. Cada cierto tiemp o, el fichero de
desborde se mezcla con el fichero ordenado, de modo que así las inserciones son muy eficientes.
Esto perjudica a las búsquedas, ya que si el registro no se encuentra mediante búsqueda binaria
en el fichero ordenado, hay que realizar una bú squeda lineal en el fichero de desborde.
Cuando se trata de eliminar un registro, hay que encontrarlo y marcarlo como borrado. Como en
los ficheros desordenados, cada cierto tiempo se debe realizar una reorganización del fichero.
Para modificar un registro hay que encontrarlo y actualizarlo en caso de que quepa en el bloque
en el que se encontraba. Si el registro actualizado ya no cabe en su ubicación, hay que borrarlo,
hacer hueco e insertarlo. Si en la actualización se modifica el campo de ordenación, en tonces es
muy probable que haya que cambiar el registro de lugar para mantener el orden: habrá que
borrarlo, hacer hueco e insertarlo de nuevo.
Los ficheros ordenados no se suelen utilizar como ficheros de datos en los SGBD.

CAPITULO 3

SISTEMAS DE BASES DE DATOS

3.1. Modelos de datos

Una de las características fundamentales de los sistemas de bases de datos es que proporcionan
cierto nivel de abstracción de datos, al ocultar las características sobre el almacenamiento físico
que la mayoría de usuarios no necesita conocer. Los modelos de datos son el instrumento
principal para ofrecer dicha abstracción. Un modelo de datos es un conjunto de conceptos que
sirven para describir la estructura de una base de datos: los datos, las relaciones entre los da tos y
las restricciones que deben cumplirse sobre los datos. Los modelos de datos contienen también
un conjunto de operaciones básicas para la realización de consultas (lecturas) y actualizaciones
de datos. Además, los modelos de datos más modernos incluye n conceptos para especificar
comportamiento, permitiendo especificar un conjunto de operaciones definidas por el usuario.
Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que ofrecen
para describir la estructura de la base d e datos. Los modelos de datos de alto nivel, o modelos
conceptuales, disponen de conceptos muy cercanos al modo en que la mayoría de los usuarios
percibe los datos, mientras que los modelos de datos de bajo nivel, o modelos físicos,
proporcionan conceptos que describen los detalles de cómo se almacenan los datos en el
ordenador. Los conceptos de los modelos físicos están dirigidos al personal informático, no a los
usuarios finales. Entre estos dos extremos se encuentran los modelos lógicos, cuyos conceptos
pueden ser entendidos por los usuarios finales, aunque no están demasiado alejados de la forma
en que los datos se organizan físicamente. Los modelos lógicos ocultan algunos detalles de cómo
se almacenan los datos, pero pueden implementarse de manera direc ta en un ordenador.
Los modelos conceptuales utilizan conceptos como entidades, atributos y relaciones. Una
entidad representa un objeto o concepto del mundo real como, por ejemplo, un empleado de la
empresa inmobiliaria o una oficina. Un atributo representa alguna propiedad de interés de una
entidad como, por ejemplo, el nombre o el salario del empleado. Una relación describe una
interacción entre dos o más entidades, por ejemplo, la relación de trabajo entre un empleado y su
oficina.
Cada SGBD soporta un modelo lógico, siendo los más comunes el relacional, el de red y el
jerárquico. Estos modelos representan los datos valiéndose de estructuras de registros, por lo que
también se denominan modelos orientados a registros . Hay una nueva familia de modelos
lógicos, son los modelos orientados a objetos , que están más próximos a los modelos
conceptuales.
Los modelos físicos describen cómo se almacenan los datos en el ordenador: el formato de los
registros, la estructura de los ficheros (desordenados, ordenados , etc.) y los métodos de acceso
utilizados (índices, etc.).
A la descripción de una base de datos mediante un modelo de datos se le denomina esquema de
la base de datos. Este esquema se especifica durante el diseño, y no es de esperar que se
modifique a menudo. Sin embargo, los datos que se almacenan en la base de datos pueden
cambiar con mucha frecuencia: se insertan datos, se actualizan, etc. Los datos que la base de
datos contiene en un determinado momento se denominan estado de la base de datos u
ocurrencia de la base de datos.
La distinción entre el esquema y el estado de la base de datos es muy importante. Cuando
definimos una nueva base de datos, sólo especificamos su esquema al SGBD. En ese momento,
el estado de la base de datos es el ``estado vací o", sin datos. Cuando se cargan datos por primera
vez, la base datos pasa al ``estado inicial". De ahí en adelante, siempre que se realice una
operación de actualización de la base de datos, se tendrá un nuevo estado. El SGBD se encarga,
en parte, de garantizar que todos los estados de la base de datos sean estados válidos que
satisfagan la estructura y las restricciones especificadas en el esquema. Por lo tanto, es muy
importante que el esquema que se especifique al SGBD sea correcto y se debe tener muchís imo
cuidado al diseñarlo. El SGBD almacena el esquema en su catálogo o diccionario de datos, de
modo que se pueda consultar siempre que sea necesario.

3.2. Arquitectura de los sistemas de bases de datos

Hay tres características importantes inherentes a los sistemas de bases de datos: la separación
entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los
usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. En 1975, el
comité ANSI-SPARC (American National Standard Institute - Standards Planning and
Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de
datos, que resulta muy útil a la hora de conseguir estas tres características.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la
base de datos física. En esta arquitectura, el esquema de una base de datos se define en tres
niveles de abstracción distintos:
1. En el nivel interno se describe la estructura física de la base de datos mediante un
esquema interno. Este esquema se especifica mediante un modelo físico y describe todos
los detalles para el almacenamiento de la base de datos, así como los métodos de acceso.
2. En el nivel conceptual se describe la estructura de toda la base de datos para una
comunidad de usuarios (todos los de una empresa u organización), mediante un esquema
conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se
concentra en describir entidades, atributos, re laciones, operaciones de los usuarios y
restricciones. En este nivel se puede utilizar un modelo conceptual o un modelo lógico
para especificar el esquema.
 3. En el nivel externo se describen varios esquemas externos o vistas de usuario. Cada
esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios
determinado y oculta a ese grupo el resto de la base de datos. En este nivel se puede
utilizar un modelo conceptual o un modelo lógico para especificar los esquemas.
La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del
nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario,
los esquemas externos se especifican con el mismo modelo de datos que describe l a información
a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los
niveles conceptual y externo.
Hay que destacar que los tres esquemas no son más que descripciones de los mismos datos pero
con distintos niveles de abstracción. Los únicos datos que existen realmente están a nivel físico,
almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura
de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema
externo. Por lo tanto, el SGBD debe transformar cualquier petición expresada en términos de un
esquema externo a una petición expresada en términos del esquema conceptual, y luego, a una
petición en el esquema interno, que se procesará sobre la base de dat os almacenada. Si la
petición es de una obtención (consulta) de datos, será preciso modificar el formato de la
información extraída de la base de datos almacenada, para que coincida con la vista externa del
usuario. El proceso de transformar peticiones y r esultados de un nivel a otro se denomina
correspondencia o transformación. Estas correspondencias pueden requerir bastante tiempo, por
lo que algunos SGBD no cuentan con vistas externas.
La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos que
podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener
que modificar el esquema del nivel inmediato superior. Se pueden definir dos tipos de
independencia de datos:
 La independencia lógica es la capacidad de modificar el esquema conceptual sin tener
que alterar los esquemas externos ni los programas de aplicación. Se puede modificar el
esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se
reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran
a ella no deberán verse afectados.
 La independencia física es la capacidad de modificar el esquema interno sin tener que
alterar el esquema conceptual (o los externos). Por ejemplo, pue de ser necesario
reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las
operaciones de consulta o de actualización de datos. Dado que la independencia física se
refiere sólo a la separación entre las aplicaciones y las estructuras físicas de
almacenamiento, es más fácil de conseguir que la independencia lógica.
En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catálogo o
diccionario, de modo que incluya información sobre cómo establecer la correspond encia entre
las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de
procedimientos adicionales para realizar estas correspondencias haciendo referencia a la
información de correspondencia que se encuentra en el catálogo. La independencia de datos se
consigue porque al modificarse el esquema en algún nivel, el esquema del nivel inmediato
superior permanece sin cambios, sólo se modifica la correspondencia entre los dos niveles. No es
preciso modificar los programas de aplicación que hacen referencia al esquema del nivel
superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtención de la verdadera
independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de
correspondencia implican un gasto extra durante la ejecución de una consulta o de un programa,
lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta
arquitectura completa.

3.3. Lenguaje de definición de datos

Una vez finalizado el diseño de una base de datos y escogido un SGBD para su implementación,
el primer paso consiste en especificar el esquema conceptual y el esquema interno de la base de
datos, y la correspondencia entre ambos. En muchos SGBD no se mantiene una separación
estricta de niveles, por lo que el administrador de la base de datos y los diseñadores utilizan el
mismo lenguaje para definir ambos esquemas, es el lenguaje de definición de datos (LDD). El
SGBD posee un compilador de LDD cuya función consiste en procesar l as sentencias del
lenguaje para identificar las descripciones de los distintos elementos de los esquemas y
almacenar la descripción del esquema en el catálogo o diccionario de datos. Se dice que el
diccionario contiene metadatos: describe los objetos de la base de datos.
Cuando en un SGBD hay una clara separación entre los niveles conceptual e interno, el LDD
sólo sirve para especificar el esquema conceptual. Para especificar el esquema interno se utiliza
un lenguaje de definición de almacenamiento (LDA). Las correspondencias entre ambos
esquemas se pueden especificar en cualquiera de los dos lenguajes. Para tener una verdadera
arquitectura de tres niveles sería necesario disponer de un tercer lenguaje, el lenguaje de
definición de vistas (LDV), que se utilizaría para especificar las vistas de los usuarios y su
correspondencia con el esquema conceptual.

3.4. Lenguaje de manejo de datos

Una vez creados los esquemas de la base de datos, los usuarios necesitan un lenguaje que les
permita manipular los datos de la base de datos: realizar consultas, inserciones, eliminaciones y
modificaciones. Este lenguaje es el que se denomina lenguaje de manejo de datos (LMD).
Hay dos tipos de LMD: los procedurales y los no procedurales. Con un LMD procedural el
usuario (normalmente será un programador) especifica qué datos se necesitan y cómo hay que
obtenerlos. Esto quiere decir que el usuario debe especificar todas las operaciones de acceso a
datos llamando a los procedimientos necesarios para obtener la información requ erida. Estos
lenguajes acceden a un registro, lo procesan y basándose en los resultados obtenidos, acceden a
otro registro, que también deben procesar. Así se va accediendo a registros y se van procesando
hasta que se obtienen los datos deseados. Las sente ncias de un LMD procedural deben estar
embebidas en un lenguaje de alto nivel, ya que se necesitan sus estructuras (bucles,
condicionales, etc.) para obtener y procesar cada registro individual. A este lenguaje se le
denomina lenguaje anfitrión. Las bases de datos jerárquicas y de red utilizan LMD procedurales.
Un LMD no procedural se puede utilizar de manera independiente para especificar operaciones
complejas sobre la base de datos de forma concisa. En muchos SGBD se pueden introducir
interactivamente instrucciones del LMD desde un terminal o bien embeberlas en un lenguaje de
programación de alto nivel. Los LMD no procedurales permiten especificar los datos a obtener
en una consulta o los datos que se deben actualizar, mediante una sola y sencilla sentenc ia. El
usuario o programador especifica qué datos quiere obtener sin decir cómo se debe acceder a
ellos. El SGBD traduce las sentencias del LMD en uno o varios procedimientos que manipulan
los conjuntos de registros necesarios. Esto libera al usuario de te ner que conocer cuál es la
estructura física de los datos y qué algoritmos se deben utilizar para acceder a ellos. A los LMD
no procedurales también se les denomina declarativos. Las bases de datos relacionales utilizan
LMD no procedurales, como SQL (Struc tured Query Language) o QBE (Query -By-Example).
Los lenguajes no procedurales son más fáciles de aprender y de usar que los procedurales, y el
usuario debe realizar menos trabajo, siendo el SGBD quien hace la mayor parte.
La parte de los LMD no procedural es que realiza la obtención de datos es lo que se denomina un
lenguaje de consultas. En general, las órdenes tanto de obtención como de actualización de datos
de un LMD no procedural se pueden utilizar interactivamente, por lo que al conjunto completo
de sentencias del LMD se le denomina lenguaje de consultas, aunque es técnicamente incorrecto.

3.5. Lenguajes de cuarta generación

No existe consenso sobre lo que es un lenguaje de cuarta generación (4GL). Lo que en un
lenguaje de tercera generación (3GL) c omo COBOL requiere cientos de líneas de código, tan
solo necesita diez o veinte líneas en un 4GL. Comparado con un 3GL, que es procedural, un 4GL
es un lenguaje no procedural: el usuario define qué se debe hacer, no cómo debe hacerse. Los
4GL se apoyan en unas herramientas de mucho más alto nivel denominadas herramientas de
cuarta generación. El usuario no debe definir los pasos a seguir en un programa para realizar una
determinada tarea, tan sólo debe definir una serie de parámetros que estas herramientas utilizarán
para generar un programa de aplicación. Se dice que los 4GL pueden mejorar la productividad de
los programadores en un factor de 10, aunque se limita el tipo de problemas que pueden resolver.
Los 4GL abarcan:
 Lenguajes de presentación, como len guajes de consultas y generadores de informes.
 Lenguajes especializados, como hojas de cálculo y lenguajes de bases de datos.
 Generadores de aplicaciones que definen, insertan, actualizan y obtienen datos de la base
de datos.
 Lenguajes de muy alto nivel que se utilizan para generar el código de la aplicación.
Los lenguajes SQL y QBE son ejemplos de 4GL. Hay otros tipos de 4GL:
 Un generador de formularios es una herramienta interactiva que permite crear
rápidamente formularios de pantalla para introduci r o visualizar datos. Los generadores
de formularios permiten que el usuario defina el aspecto de la pantalla, qué información
se debe visualizar y en qué lugar de la pantalla debe visualizarse. Algunos generadores de
formularios permiten la creación de at ributos derivados utilizando operadores aritméticos
y también permiten especificar controles para la validación de los datos de entrada.
 Un generador de informes es una herramienta para crear informes a partir de los datos
almacenados en la base de datos. Se parece a un lenguaje de consultas en que permite al
usuario hacer preguntas sobre la base de datos y obtener información de ella para un
informe. Sin embargo, en el generador de informes se tiene un mayor control sobre el
aspecto de la salida. Se puede dejar que el generador determine automáticamente el
aspecto de la salida o se puede diseñar ésta para que tenga el aspecto que desee el usuario
final.
  Un generador de gráficos es una herramienta para obtener datos de la base de datos y
visualizarlos en un gráfico mostrando tendencias y relaciones entre datos. Normalmente
se pueden diseñar distintos tipos de gráficos: barras, líneas, etc.
 Un generador de aplicaciones es una herramienta para crear programas que hagan de
interface entre el usuario y la base de datos. El uso de un generador de aplicaciones puede
reducir el tiempo que se necesita para diseñar un programa de aplicación. Los
generadores de aplicaciones constan de procedimientos que realizan las funciones
fundamentales que se utilizan en la mayor ía de los programas. Estos procedimientos
están escritos en un lenguaje de programación de alto nivel y forman una librería de
funciones entre las que escoger. El usuario especifica qué debe hacer el programa y el
generador de aplicaciones es quien determi na cómo realizar la tarea.

CAPITULO 4

MODELO RELACIONAL

4.1. El modelo relacional

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd
introdujo el modelo relacional. En aquellos momentos, el enfoque existente pa ra la estructura de
las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de
distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía
añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido,
un puntero físico, siempre señalaría desde el registro al registro . Codd demostró que estas bases
de datos limitaban en gran medida los tipos de operaciones qu e los usuarios podían realizar sobre
los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si
se añadían los controladores de un nuevo disco al sistema y los datos se movían de una
localización física a otra, se reque ría una conversión de los ficheros de datos. Estos sistemas se
basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron
la primera generación de los SGBD.
El modelo relacional representa la segunda generación de los SG BD. En él, todos los datos están
estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico
pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la
sencillez de su estructura lógica . Pero detrás de esa simple estructura hay un fundamento teórico
importante del que carecen los SGBD de la primera generación, lo que constituye otro punto a su
favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han
modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo
lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red IDMS ha evolucionado
a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los da tos.
En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar
mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y
para disponer de capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:
 Estructura de datos.
 Integridad de datos.
 Manejo de datos.

4.2. Relaciones
Definiciones informales
El modelo relacional se basa en el concepto matemático de relación, que gráficamente se
representa mediante una tabla. Codd, que era un experto matemático, utilizó una terminología
perteneciente a las matemáticas, en concreto de la teoría de conjuntos y de la lógica de
predicados.
Una relación es una tabla con columnas y filas. Un SGBD sólo necesita que el usuario pueda
percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la
estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres
niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede
implementar con distintas estructuras de almacenamiento.
Un atributo es el nombre de una columna de una relación. En el modelo relacional, las
relaciones se utilizan para almacenar informac ión sobre los objetos que se representan en la base
de datos. Una relación se representa gráficamente como una tabla bidimensional en la que las
filas corresponden a registros individuales y las columnas corresponden a los campos o atributos
de esos registros. Los atributos pueden aparecer en la relación en cualquier orden.

El concepto de dominio es importante porque permite que el usuario defina, en un lugar común,
el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que ha ya más
información disponible para el sistema cuando éste va a ejecutar una operación relacional, de
modo que las operaciones que son semánticamente incorrectas, se pueden evitar. Por ejemplo, no
tiene sentido comparar el nombre de una calle con un número de teléfono, aunque los dos
atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un
inmueble no estará definido sobre el mismo dominio que el número de meses que dura el
alquiler, pero sí tiene sentido multiplicar los valor es de ambos dominios para averiguar el
importe total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo
de los dominios ya que su implementación es extremadamente compleja.
Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la
tabla. En la relación OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas
de una relación no siguen ningún orden.
El grado de una relación es el número de atributos que contiene. La relación OFICINA es de
grado seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con
seis valores. El grado de una relación no cambia con frecuencia.
La cardinalidad de una relación es el número de tuplas que contiene. Ya que en las relaciones se
van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente.

Una base de datos relacional es un conjunto de relaciones normalizadas.

Definiciones formales Una relación definida sobre un conjunto de dominios consta de:
  Cabecera: conjunto fijo de pares atributo:dominio

donde cada atributo corresponde a un único dominio y todos los son distintos, es decir, no
hay dos atributos que se llamen igual. El grado de la relación es .

 Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de pares atributo:valor:

con , donde es la cardinalidad de la relación . En cada par se tiene que .

La relación OFICINA tiene la siguiente cabecera:
{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Población:NOM_POBLACION), (Teléfono:NUM_TEL_FAX),
(Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:
{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Población:Castellón), (Teléfono:964 201 240), (Fax:964 201
340)}.
Este conjunto de pares no está ordenado, por lo que esta tupla y la siguiente, son la misma:
{ (Calle:Enmedio,8), (Fax:964 201 340), (Población:Castellón),
(Onum:O5), (Teléfono:964 201 240), (Area:Centro) }
Gráficamente se suelen representar las relaciones mediante tablas. Los nombres de las columnas
corresponden a los nombres de los atribu tos y las filas son cada una de las tuplas de la relación.
Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del
dominio sobre el que está definido el atributo correspondiente.

4.3. Propiedades de las relaciones

Las relaciones tienen las siguientes características:
 Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.
 Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo valor.
Se dice que las relaciones están normalizadas.
 No hay dos atributos que se llamen igual.
 El orden de los atributos no importa: los atributos no están ordenados.
 Cada tupla es distinta de las demás: no hay tuplas duplicadas.
 El orden de las tuplas no importa: las tuplas no están orden adas.
4.4. Tipos de relaciones
En un SGBD relacional pueden existir varios tipos de relaciones, aunque no todos manejan todos
los tipos.
 Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la
base de datos almacenada (son autónomas).
 Vistas. También denominadas relaciones virtuales, son relaciones con nombre y
derivadas: se representan mediante su definición en términos de otras relaciones con
nombre, no poseen datos almacenados propios.
 Instantáneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son
reales, no virtuales: están representadas no sólo por su definición en términos de otras
relaciones con nombre, sino también por sus propios datos almacenados. Son relaciones
de sólo de lectura y se refrescan periódicamente.
 Resultados de consultas. Son las relaciones resultantes de alguna consulta especificada.
Pueden o no tener nombre y no persisten en la base de datos.
 Resultados intermedios. Son las relaciones que contienen los resultados de las
subconsultas. Normalmente no tienen nombre y tampoco persisten en la base de datos.
 Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las
instantáneas, pero la diferencia es que se destruyen automáticamente en algún mo mento
apropiado.
4.5. Claves
Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir,
se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus
atributos.
Una superclave es un atributo o un conjunto de atributos que identifican de modo único las
tuplas de una relación.

Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave
de la relación. El atributo o conjunto de atributos de la relación es una clave candidata para si y
sólo si satisface las siguientes propiedades:

 Unicidad: nunca hay dos tuplas en la relación con el mismo valor de .

 Irreducibilidad (minimalidad): ningún subconjunto de tiene la propiedad de unicidad, es
decir, no se pueden eliminar componentes de sin destruir la unicidad.
Cuando una clave candidata está formada por más de un atributo, se dice que es una clave
compuesta. Una relación puede tener varias claves candidatas. Por ejemplo, e n la relación
OFICINA, el atributo Población no es una clave candidata ya que puede haber varias oficinas
en una misma población. Sin embargo, ya que la empresa asigna un código único a cada oficina,
el atributo Onum sí es una clave candidata de la relació n OFICINA. También son claves
candidatas de esta relación los atributos Teléfono y Fax.
En la base de datos de la inmobiliaria hay una relación denominada VISITA que contiene
información sobre las visitas que los clientes han realizado a los inmuebles. Es ta relación
contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha
y un comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar
varias visitas a varios inmuebles. Del mismo modo, dado un n úmero de inmueble Inum, puede
que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave
candidata para la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la
combinación de los dos atributos sí identif ica a una sola tupla, por lo que los dos juntos son una
clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda
visitar un mismo inmueble en varias ocasiones, habría que incluir el atributo Fecha para
identificar las tuplas de modo único (aunque éste no es el caso de la empresa que nos ocupa).
Para identificar las claves candidatas de una relación no hay que fijarse en un estado o instancia
de la base de datos. El hecho de que en un momento dado no haya duplicados par a un atributo o
conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la
presencia de duplicados en un estado de la base de datos sí es útil para demostrar que cierta
combinación de atributos no es una clave candidata. El ún ico modo de identificar las claves
candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es
posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con
certeza si un conjunto de atributo s forman una clave candidata. Por ejemplo, viendo la instancia
anterior de la relación PLANTILLA se podría pensar que el atributo Apellido es una clave
candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos
empleados con el mismo apellido, el atributo no es una clave candidata.
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus
tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave
candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave
primaria estará formada por todos los atributos de la relación, pero normalmente habrá un
pequeño subconjunto de los atributos que haga esta función.
Las claves candidatas que no son escogidas como clave primaria son denominadas claves
alternativas. Por ejemplo, la clave primaria de la relación OFICINA es el atributo Onum, siendo
Teléfono y Fax dos claves alternativas. En la relación VISITA sólo hay una clave candidata
formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.
Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores
coinciden con los valores de la clave primaria de alguna otra relación (pu ede ser la misma). Las
claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a
cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores
hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave
ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria (
tupla referenciada).

4.6. Esquema de una base de datos relacional

Una base de datos relacional es un conjunto d e relaciones normalizadas. Para representar el
esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de
éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves
ajenas.
El esquema de la base de datos de la empresa inmobiliaria es el siguiente:
OFICINA (Onum, Calle, Area, Población, Teléfono, Fax)
 (Enum, Nombre, Apellido, Dirección, Teléfono, Puesto,
PLANTILLA
Fecha_nac,
Salario, DNI, Onum)
(Inum, Calle, Area, Población, Tipo, Hab, Alquiler,
INMUEBLE
Pnum, Enum,
Onum)
(Qnum, Nombre, Apellido, Dirección, Teléfono,
INQUILINO
Tipo_pref,
Alquiler_max)
PROPIETAR
(Pnum, Nombre, Apellido, Dirección, Teléfono)
IO
VISITA (Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos
encerrados entre paréntesis. Las claves primarias son los atributos subrayados. Las claves ajenas
se representan mediante los siguientes diagramas referenciales.

PLANTIL
OFICINA : Oficina a la que pertenece el empleado.
LA

INMUEBL PROPIETAR
: Propietario del inmueble.
E IO

INMUEBL
PLANTILLA : Empleado encargado del inmueble.
E

INMUEBL
OFICINA : Oficina a la que pertenece el inmueble.
E

VISITA INQUILINO : Inquilino que ha visitado el inmueble.

VISITA INMUEBLE : Inmueble que ha sido visitado.

CAPITULO 5

DISEÑO DE BASES DE DATOS

5.1. Metodología de diseño conceptual

El primer paso en el diseño de una base de datos es la producción del esquema conceptual.
Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las
distintas visiones que los usuarios tienen de la información. Cada una de estas visiones suelen
corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción,
ventas, recursos humanos, etc.
Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.
Una opción consiste en examinar los diagramas de flujo de datos, que se pueden haber producido
previamente, para identificar cada una de las áreas funcionales. La otra opción consiste en
entrevistar a los usuarios, exam inar los procedimientos, los informes y los formularios, y también
observar el funcionamiento de la empresa.
A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas
conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones,
atributos, dominios de atributos e identificadores. El esquema conceptual también tendrá una
documentación, que se irá produciendo durante su desarrollo. Las tareas a realizar en el diseño
conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama entidad -relación.
8. Revisar el esquema conceptual local con el usuario.
1. Identificar las entidades
En primer lugar hay que definir los principales objetos que interesan al usuario. Estos objetos
serán las entidades. Una forma de ide ntificar las entidades es examinar las especificaciones de
requisitos de usuario. En estas especificaciones se buscan los nombres o los sintagmas nominales
que se mencionan (por ejemplo: número de empleado, nombre de empleado, número de
inmueble, dirección del inmueble, alquiler, número de habitaciones). También se buscan objetos
importantes como personas, lugares o conceptos de interés, excluyendo aquellos nombres que
sólo son propiedades de otros objetos. Por ejemplo, se pueden agrupar el número de emplea do y
el nombre de empleado en una entidad denominada empleado, y agrupar número de inmueble,
dirección del inmueble, alquiler y número de habitaciones en otra entidad denominada inmueble.
Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por
ejemplo, empleado es una entidad porque los empleados existen, sepamos o no sus nombres,
direcciones y teléfonos. Siempre que sea posible, el usuario debe colaborar en la identificación
de las entidades.
A veces, es difícil identificar las entidades por la forma en que aparecen en las especificaciones
de requisitos. Los usuarios, a veces, hablan utilizando ejemplos o analogías. En lugar de hablar
de empleados en general, hablan de personas concretas, o bien, hablan de los pue stos que ocupan
esas personas.
Para liarlo aún más, los usuarios usan, muchas veces, sinónimos y homónimos. Dos palabras son
sinónimos cuando tienen el mismo significado. Los homónimos ocurren cuando la misma
palabra puede tener distintos significados dep endiendo del contexto.
No siempre es obvio saber si un objeto es una entidad, una relación o un atributo. Por ejemplo
¿cómo se podría clasificar matrimonio? Pues de cualquiera de las tres formas. El análisis es
subjetivo, por lo que distintos diseñadores pueden hacer distintas interpretaciones, aunque todas
igualmente válidas. Todo depende de la opinión y la experiencia de cada uno. Los diseñadores de
bases de datos deben tener una visión selectiva y clasificar las cosas que observan dentro del
contexto de la empresa u organización. A partir de unas especificaciones de usuario es posible
que no se pueda deducir un conjunto único de entidades, pero después de varias iteraciones del
proceso de análisis, se llegará a obtener un conjunto de entidades que sean a decuadas para el
sistema que se ha de construir.
Conforme se van identificando las entidades, se les dan nombres que tengan un significado y que
sean obvias para el usuario. Los nombres de las entidades y sus descripciones se anotan en el
diccionario de datos. Cuando sea posible, se debe anotar también el número aproximado de
ocurrencias de cada entidad. Si una entidad se conoce por varios nombres, éstos se deben anotar
en el diccionario de datos como alias o sinónimos.
2. Identificar las relaciones
Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas. Del mismo
modo que para identificar las entidades se buscaban nombres en las especificaciones de
requisitos, para identificar las relaciones se suelen buscar las expresion es verbales (por ejemplo:
oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Si las
especificaciones de requisitos reflejan estas relaciones es porque son importantes para la empresa
y, por lo tanto, se deben reflejar en el esqu ema conceptual.
Pero sólo interesan las relaciones que son necesarias. En el ejemplo anterior, se han identificado
las relaciones empleado gestiona inmueble y cliente visita inmueble. Se podría pensar en incluir
una relación entre empleado y cliente: empleado atiende a cliente, pero observando las
especificaciones de requisitos no parece que haya interés en modelar tal relación.
La mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que
también puede haber relaciones en l as que participen más de dos entidades, así como relaciones
recursivas.
Es muy importante repasar las especificaciones para comprobar que todas las relaciones,
explícitas o implícitas, se han encontrado. Si se tienen pocas entidades, se puede comprobar po r
parejas si hay alguna relación entre ellas. De todos modos, las relaciones que no se identifican
ahora se suelen encontrar cuando se valida el esquema con las transacciones que debe soportar.
Una vez identificadas todas las relaciones, hay que determina r la cardinalidad mínima y máxima
con la que participa cada entidad en cada una de ellas. De este modo, el esquema representa de
un modo más explícito la semántica de las relaciones. La cardinalidad es un tipo de restricción
que se utiliza para comprobar y mantener la calidad de los datos. Estas restricciones son
aserciones sobre las entidades que se pueden aplicar cuando se actualiza la base de datos para
determinar si las actualizaciones violan o no las reglas establecidas sobre la semántica de los
datos.
Conforme se van identificando las relaciones, se les van asignando nombres que tengan
significado para el usuario. En el diccionario de datos se anotan los nombres de las relaciones, su
descripción y las cardinalidades con las que participan las entidade s en ellas.
3. Identificar los atributos y asociarlos a entidades y relaciones
Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son
atributos los nombres que identifican propiedades, cualidades, identificadores o c aracterísticas de
entidades o relaciones.
Lo más sencillo es preguntarse, para cada entidad y cada relación, ¿qué información se quiere
saber de ...? La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos.
Pero, en ocasiones, será necesario preguntar a los usuarios para que aclaren los requisitos.
Desgraciadamente, los usuarios pueden dar respuestas a esta pregunta que también contengan
otros conceptos, por lo que hay que considerar sus respuestas con mucho cuidado.
Al identificar los atributos, hay que tener en cuenta si son simples o compuestos. Por ejemplo, el
atributo dirección puede ser simple, teniendo la dirección completa como un solo valor: `San
Rafael 45, Almazora'; o puede ser un atributo compuesto, formado por la calle (`San Rafael'), el
número (`45') y la población (`Almazora'). El escoger entre atributo simple o compuesto depende
de los requisitos del usuario. Si el usuario no necesita acceder a cada uno de los componentes de
la dirección por separado, se puede re presentar como un atributo simple. Pero si el usuario quiere
acceder a los componentes de forma individual, entonces se debe representar como un atributo
compuesto.
También se deben identificar los atributos derivados o calculados, que son aquellos cuyo v alor se
puede calcular a partir de los valores de otros atributos. Por ejemplo, el número de empleados de
cada oficina, la edad de los empleados o el número de inmuebles que gestiona cada empleado.
Algunos diseñadores no representan los atributos derivados en los esquemas conceptuales. Si se
hace, se debe indicar claramente que el atributo es derivado y a partir de qué atributos se obtiene
su valor. Donde hay que considerar los atributos derivados es en el diseño físico.
Cuando se están identificando los a tributos, se puede descubrir alguna entidad que no se ha
identificado previamente, por lo que hay que volver al principio introduciendo esta entidad y
viendo si se relaciona con otras entidades.
Es muy útil elaborar una lista de atributos e ir eliminándol os de la lista conforme se vayan
asociando a una entidad o relación. De este modo, uno se puede asegurar de que cada atributo se
asocia a una sola entidad o relación, y que cuando la lista se ha acabado, se han asociado todos
los atributos.
Hay que tener mucho cuidado cuando parece que un mismo atributo se debe asociar a varias
entidades. Esto puede ser por una de las siguientes causas:
 Se han identificado varias entidades, como director, supervisor y administrativo, cuando,
de hecho, pueden representarse como una sola entidad denominada empleado. En este
caso, se puede escoger entre introducir una jerarquía de generalización, o dejar las
entidades que representan cada uno de los puestos de empleado.
 Se ha identificado una relación entre entidades. En est e caso, se debe asociar el atributo a
una sola de las entidades y hay que asegurarse de que la relación ya se había identificado
previamente. Si no es así, se debe actualizar la documentación para recoger la nueva
relación.
Conforme se van identificando l os atributos, se les asignan nombres que tengan significado para
el usuario. De cada atributo se debe anotar la siguiente información:
 Nombre y descripción del atributo.
 Alias o sinónimos por los que se conoce al atributo.
 Tipo de dato y longitud.
 Valores por defecto del atributo (si se especifican).
 Si el atributo siempre va a tener un valor (si admite o no nulos).
 Si el atributo es compuesto y, en su caso, qué atributos simples lo forman.
 Si el atributo es derivado y, en su caso, cómo se calcula su valor.
 Si el atributo es multievaluado.
4. Determinar los dominios de los atributos
El dominio de un atributo es el conjunto de valores que puede tomar el atributo. Por ejemplo el
dominio de los números de oficina son las tiras de hasta tres caracteres en donde el primero es
una letra y el siguiente o los dos siguientes son dígitos en el rango de 1 a 99; el dominio de los
números de teléfono y los números de fax son las tiras de 9 dígitos.
Un esquema conceptual está completo si incluye los dominios de cada atributo: los valores
permitidos para cada atributo, su tamaño y su formato. También se puede incluir información
adicional sobre los dominios como, por ejemplo, las operaciones que se pueden realizar sobre
cada atributo, qué atributos pueden comparar se entre sí o qué atributos pueden combinarse con
otros. Aunque sería muy interesante que el sistema final respetara todas estas indicaciones sobre
los dominios, esto es todavía una línea abierta de investigación.
Toda la información sobre los dominios se debe anotar también en el diccionario de datos.
5. Determinar los identificadores
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los
identificadores de cada una de las entidades. Los identificadores pueden ser si mples o
compuestos. De cada entidad se escogerá uno de los identificadores como clave primaria en la
fase del diseño lógico.
Cuando se determinan los identificadores es fácil darse cuenta de si una entidad es fuerte o débil.
Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son padre,
propietaria o dominante). Si una entidad no tiene atributos que le sirvan de identificador, es
débil (otras denominaciones son hijo, dependiente o subordinada).
Todos los identificadores de las entidades se deben anotar en el diccionario de datos.
6. Determinar las jerarquías de generalización
En este paso hay que observar las entidades que se han identificado hasta el momento. Hay que
ver si es necesario reflejar las diferencias entre distinta s ocurrencias de una entidad, con lo que
surgirán nuevas subentidades de esta entidad genérica; o bien, si hay entidades que tienen
características en común y que realmente son subentidades de una nueva entidad genérica.
En cada jerarquía hay que determin ar si es total o parcial y exclusiva o superpuesta.
7. Dibujar el diagrama entidad -relación
Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad -relación
correspondiente a una de las vistas de los usuarios. Se obtiene así un es quema conceptual local.
8. Revisar el esquema conceptual local con el usuario
Antes de dar por finalizada la fase del diseño conceptual, se debe revisar el esquema conceptual
local con el usuario. Este esquema está formado por el diagrama entidad -relación y toda la
documentación que describe el esquema. Si se encuentra alguna anomalía, hay que corregirla
haciendo los cambios oportunos, por lo que posiblemente haya que repetir alguno de los pasos
anteriores. Este proceso debe repetirse hasta que se esté se guro de que el esquema conceptual es
una fiel representación de la parte de la empresa que se está tratando de modelar.

5.2. Metodología de diseño físico para bases de datos relacionales

El objetivo de esta etapa es producir una descripción de la implem entación de la base de datos en
memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos
de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
El diseño físico se divide de cuatro fases, cada una d e ellas compuesta por una serie de pasos:
 Traducir el esquema lógico global para el SGBD específico.
1. Diseñar las relaciones base para el SGBD específico.
2. Diseñar las reglas de negocio para el SGBD específico.
 Diseñar la representación física.
1. Analizar las transacciones.
2. Escoger las organizaciones de ficheros.
 3. Escoger los índices secundarios.
4. Considerar la introducción de redundancias controladas.
5. Estimar la necesidad de espacio en disco.
 Diseñar los mecanismos de seguridad.
1. Diseñar las vistas de los usuarios.
2. Diseñar las reglas de acceso.
 Monitorizar y afinar el sistema.

5.3. Metodología de diseño lógico en el modelo relacional

La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos
fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.
 Construir y validar los esquemas lógicos locales para cada vista de usuario.
1. Convertir los esquemas conceptuales locales en esquemas lógicos locales.
2. Derivar un conjunto de relaciones (tabla s) para cada esquema lógico local.
3. Validar cada esquema mediante la normalización.
4. Validar cada esquema frente a las transacciones del usuario.
5. Dibujar el diagrama entidad -relación.
6. Definir las restricciones de integridad.
7. Revisar cada esquema lógico local con el usuario correspondiente.
 Construir y validar el esquema lógico global.
1. Mezclar los esquemas lógicos locales en un esquema lógico global.
2. Validar el esquema lógico global.
3. Estudiar el crecimiento futuro.
4. Dibujar el diagrama entidad -relación final.
5. Revisar el esquema lógico global con los usuarios.
En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario y se
validan. En esta fase se refinan los esquemas conceptuales creados durante el diseño conceptual,
eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el
modelo que soporta el SGBD, en el caso que nos ocupa, el modelo relacional. Una vez hecho
esto, se obtiene un primer esquema lógico que se valida mediante la normaliz ación y frente a las
transacciones que el sistema debe llevar a cabo, tal y como se refleja en las especificaciones de
requisitos de usuario. El esquema lógico ya validado se puede utilizar como base para el
desarrollo de prototipos. Una vez finalizada est a fase, se dispone de un esquema lógico para cada
vista de usuario que es correcto, comprensible y sin ambigüedad.
1. Convertir los esquemas conceptuales locales en esquemas lógicos locales
En este paso, se eliminan de cada esquema conceptual las estruct uras de datos que los sistemas
relacionales no modelan directamente:
(a)
Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una nueva
entidad intermedia y dos relaciones de uno a muchos de esta nueva entidad con las entidades
originales. La nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de
ocurrencias en las entidades originales.

(b)
 Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de ellas por una
nueva entidad (débil) intermedia que se relaciona con cada una de las entidades originales.
La cardinalidad de estas nuevas relaciones binarias dependerá de su significado.

(c)
Eliminar las relaciones recursivas, sustituyendo cada una de ellas por una nueva entidad
(débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La
cardinalidad de estas relaciones dependerá de su significado.

(d)
Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva entidad
(débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades
originales. La cardinalidad de estas relaciones dependerá del tipo de la relación original y de
su significado.

(e)
Eliminar los atributos multievaluados, sustituyendo cada uno de ellos po r una nueva entidad
(débil) y una relación binaria de uno a muchos con la entidad original.

(f)
Revisar las relaciones de uno a uno , ya que es posible que se hayan identificado dos
entidades que representen el mismo objeto (sinónimos). Si así fuera, amba s entidades deben
integrarse en una sola.

(g)
Eliminar las relaciones redundantes . Una relación es redundante cuando se puede obtener la
misma información que ella aporta mediante otras relaciones. El hecho de que haya dos
caminos diferentes entre dos en tidades no implica que uno de los caminos corresponda a una
relación redundante, eso dependerá del significado de cada relación.
Una vez finalizado este paso, es más correcto referirse a los esquemas conceptuales locales
refinados como esquemas lógicos lo cales, ya que se adaptan al modelo de base de datos que
soporta el SGBD escogido.
2. Derivar un conjunto de relaciones (tablas) para cada esquema lógico local
En este paso, se obtiene un conjunto de relaciones (tablas) para cada uno de los esquemas lógic os
locales en donde se representen las entidades y relaciones entre entidades, que se describen en
cada una de las vistas que los usuarios tienen de la empresa. Cada relación de la base de datos
tendrá un nombre, y el nombre de sus atributos aparecerá, a c ontinuación, entre paréntesis. El
atributo o atributos que forman la clave primaria se subrayan. Las claves ajenas, mecanismo que
se utiliza para representar las relaciones entre entidades en el modelo relacional, se especifican
aparte indicando la relación (tabla) a la que hacen referencia.
A continuación, se describe cómo las relaciones (tablas) del modelo relacional representan las
entidades y relaciones que pueden aparecer en los esquemas lógicos.
(a)
 Entidades fuertes. Crear una relación para cada e ntidad fuerte que incluya todos sus atributos
simples. De los atributos compuestos incluir sólo sus componentes.
Cada uno de los identificadores de la entidad será una clave candidata. De entre las claves
candidatas hay que escoger la clave primaria; el r esto serán claves alternativas. Para escoger
la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:

 Escoger la clave candidata que tenga menos atributos.

 Escoger la clave candidata cuyos valores no tengan probabilidad de cambi ar en el

futuro.

 Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad

en el futuro.

 Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto).

 Escoger la clave candidata más fácil de utilizar de sde el punto de vista de los
usuarios.

(b)
Entidades débiles. Crear una relación para cada entidad débil incluyendo todos sus atributos
simples. De los atributos compuestos incluir sólo sus componentes. Añadir una clave ajena a
la entidad de la que depen de. Para ello, se incluye la clave primaria de la relación que
representa a la entidad padre en la nueva relación creada para la entidad débil. A
continuación, determinar la clave primaria de la nueva relación.

(c)
Relaciones binarias de uno a uno. Para cada relación binaria se incluyen los atributos de la
clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para
actuar como una clave ajena. La entidad hijo es la que participa de forma total (obligatoria)
en la relación, mientras que la entidad padre es la que participa de forma parcial (opcional).
Si las dos entidades participan de forma total o parcial en la relación, la elección de padre e
hijo es arbitraria. Además, en caso de que ambas entidades participen de for ma total en la
relación, se tiene la opción de integrar las dos entidades en una sola relación (tabla). Esto se
suele hacer si una de las entidades no participa en ninguna otra relación.

(d)
Relaciones binarias de uno a muchos. Como en las relaciones de uno a uno, se incluyen los
atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la
entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre es la de ``la parte
del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es la de ``la parte
del uno'' (cada hijo tiene un solo padre).

(e)
 Jerarquías de generalización. En las jerarquías, se denomina entidad padre a la entidad
genérica y entidades hijo a las subentidades. Hay tres opcione s distintas para representar las
jerarquías. La elección de la más adecuada se hará en función de su tipo (total/parcial,
exclusiva/superpuesta).
1. Crear una relación por cada entidad. Las relaciones de las entidades hijo heredan
como clave primaria la de l a entidad padre. Por lo tanto, la clave primaria de las
entidades hijo es también una clave ajena al padre. Esta opción sirve para cualquier
tipo de jerarquía, total o parcial y exclusiva o superpuesta.
2. Crear una relación por cada entidad hijo, heredando los atributos de la entidad padre.
Esta opción sólo sirve para jerarquías totales y exclusivas.
3. Integrar todas las entidades en una relación, incluyendo en ella los atributos de la
entidad padre, los atributos de todos los hijos y un atributo discriminati vo para indicar
el caso al cual pertenece la entidad en consideración. Esta opción sirve para cualquier
tipo de jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo será
multievaluado.
Una vez obtenidas las relaciones con sus atributos, c laves primarias y claves ajenas, sólo queda
actualizar el diccionario de datos con los nuevos atributos que se hayan identificado en este paso.
3. Validar cada esquema mediante la normalización
La normalización se utiliza para mejorar el esquema lógico, de modo que satisfaga ciertas
restricciones que eviten la duplicidad de datos. La normalización garantiza que el esquema
resultante se encuentra más próximo al modelo de la empresa, que es consistente y que tiene la
mínima redundancia y la máxima estabilid ad.
La normalización es un proceso que permite decidir a qué entidad pertenece cada atributo. Uno
de los conceptos básicos del modelo relacional es que los atributos se agrupan en relaciones
(tablas) porque están relacionados a nivel lógico. En la mayoría de las ocasiones, una base de
datos normalizada no proporciona la máxima eficiencia, sin embargo, el objetivo ahora es
conseguir una base de datos normalizada por las siguientes razones:
 Un esquema normalizado organiza los datos de acuerdo a sus dependen cias funcionales,
es decir, de acuerdo a sus relaciones lógicas.
 El esquema lógico no tiene porqué ser el esquema final. Debe representar lo que el
diseñador entiende sobre la naturaleza y el significado de los datos de la empresa. Si se
establecen unos objetivos en cuanto a prestaciones, el diseño físico cambiará el esquema
lógico de modo adecuado. Una posibilidad es que algunas relaciones normalizadas se
desnormalicen. Pero la desnormalización no implica que se haya malgastado tiempo
normalizando, ya que mediante este proceso el diseñador aprende más sobre el
significado de los datos. De hecho, la normalización obliga a entender completamente
cada uno de los atributos que se han de representar en la base de datos.
 Un esquema normalizado es robusto y care ce de redundancias, por lo que está libre de
ciertas anomalías que éstas pueden provocar cuando se actualiza la base de datos.
 Los equipos informáticos de hoy en día son mucho más potentes, por lo que en ocasiones
es más razonable implementar bases de dat os fáciles de manejar (las normalizadas), a
costa de un tiempo adicional de proceso.
 La normalización produce bases de datos con esquemas flexibles que pueden extenderse
con facilidad.
El objetivo de este paso es obtener un conjunto de relaciones que se encuentren en la forma
normal de Boyce-Codd. Para ello, hay que pasar por la primera, segunda y tercera formas
normales. El proceso de normalización se describe en el apartado 7.3.
4. Validar cada esquema frente a las transacciones del usuario
El objetivo de este paso es validar cada esquema lógico local para garantizar que puede soportar
las transacciones requeridas por los correspondientes usuarios. Estas transacc iones se
encontrarán en las especificaciones de requisitos de usuario. Lo que se debe hacer es tratar de
realizar las transacciones de forma manual utilizando el diagrama entidad -relación, el diccionario
de datos y las conexiones que establecen las claves ajenas de las relaciones (tablas). Si todas las
transacciones se pueden realizar, el esquema queda validado. Pero si alguna transacción no se
puede realizar, seguramente será porque alguna entidad, relación o atributo no se ha incluido en
el esquema.
5. Dibujar el diagrama entidad -relación
En este momento, se puede dibujar el diagrama entidad -relación final para cada vista de usuario
que recoja la representación lógica de los datos desde su punto de vista. Este diagrama habrá sido
validado mediante la normalización y frente a las transacciones de los usuarios.
6. Definir las restricciones de integridad
Las restricciones de integridad son reglas que se quieren imponer para proteger la base de datos,
de modo que no pueda llegar a un estado inconsistente. H ay cinco tipos de restricciones de
integridad.
(a)
Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir, no
admiten nulos.

(b)
Restricciones de dominios. Todos los atributos tienen un dominio asociado, que es el
conjunto los valores que cada atributo puede tomar.

(c)
Integridad de entidades. El identificador de una entidad no puede ser nulo, por lo tanto, las
claves primarias de las relaciones (tablas) no admiten nulos.

(d)
Integridad referencial. Una clave ajena enlaza cada tupla de la relación hijo con la tupla de la
relación padre que tiene el mismo valor en su clave primaria. La integridad referencial dice
que si una clave ajena tiene un valor (si es no nula), ese valor debe ser uno de los valores de
la clave primaria a la que referencia. Hay varios aspectos a tener en cuenta sobre las claves
ajenas para lograr que se cumpla la integridad referencial.
1. ¿Admite nulos la clave ajena? Cada clave ajena expresa una relación. Si la
participación de la entidad hijo en la r elación es total, entonces la clave ajena no
admite nulos; si es parcial, la clave ajena debe aceptar nulos.
2. ¿Qué hacer cuando se quiere borrar una ocurrencia de la entidad padre que tiene
algún hijo? O lo que es lo mismo, ¿qué hacer cuando se quiere borr ar una tupla que
 está siendo referenciada por otra tupla a través de una clave ajena? Hay varias
respuestas posibles:

 Restringir: no se pueden borrar tuplas que están siendo referenciadas por otras
tuplas.

 Propagar: se borra la tupla deseada y se propaga el borrado a todas las tuplas

que le hacen referencia.

 Anular: se borra la tupla deseada y todas las referencias que tenía se ponen,
automáticamente, a nulo (esta respuesta sólo es válida si la clave ajena acepta
nulos).

 Valor por defecto: se borra la tupla deseada y todas las referencias toman,
automáticamente, el valor por defecto (esta respuesta sólo es válida si se ha
especificado un valor por defecto para la clave ajena).

 No comprobar: se borra la tupla deseada y no se hace nada para garantizar que

se sigue cumpliendo la integridad referencial.
3. ¿Qué hacer cuando se quiere modificar la clave primaria de una tupla que está siendo
referenciada por otra tupla a través de una clave ajena? Las respuestas posibles son
las mismas que en el caso anterior. C uando se escoge propagar, se actualiza la clave
primaria en la tupla deseada y se propaga el cambio a los valores de clave ajena que
le hacían referencia.

(e)
Reglas de negocio. Cualquier operación que se realice sobre los datos debe cumplir las
restricciones que impone el funcionamiento de la empresa.
Todas las restricciones de integridad establecidas en este paso se deben reflejar en el diccionario
de datos para que puedan ser tenidas en cuenta durante la fase del diseño físico.
7. Revisar cada esquema lógico local con el usuario correspondiente
Para garantizar que cada esquema lógico local es una fiel representación de la vista del usuario lo
que se debe hacer es comprobar con él que lo reflejado en el esquema y en la documentación es
correcto y está completo.
Relación entre el esquema lógico y los diagramas de flujo de datos
El esquema lógico refleja la estructura de los datos a almacenar que maneja la empresa. Un
diagrama de flujo de datos muestra cómo se mueven los datos en la empresa y los almac enes en
donde se guardan. Si se han utilizado diagramas de flujo de datos para modelar las
especificaciones de requisitos de usuario, se pueden utilizar para comprobar la consistencia y
completitud del esquema lógico desarrollado. Para ello:
 Cada almacén de datos debe corresponder con una o varias entidades completas.
 Los atributos en los flujos de datos deben corresponder a alguna entidad.
Los esquemas lógicos locales obtenidos hasta este momento se integrarán en un solo esquema
lógico global en la siguiente fase para modelar los datos de toda la empresa.
8. Mezclar los esquemas lógicos locales en un esquema lógico global
 En este paso, se deben integrar todos los esquemas locales en un solo esquema global. En un
sistema pequeño, con dos o tres vistas d e usuario y unas pocas entidades y relaciones, es
relativamente sencillo comparar los esquemas locales, mezclarlos y resolver cualquier tipo de
diferencia que pueda existir. Pero en los sistemas grandes, se debe seguir un proceso más
sistemático para llevar a cabo este paso con éxito:
1. Revisar los nombres de las entidades y sus claves primarias.
2. Revisar los nombres de las relaciones.
3. Mezclar las entidades de las vistas locales.
4. Incluir (sin mezclar) las entidades que pertenecen a una sola vista de usuari o.
5. Mezclar las relaciones de las vistas locales.
6. Incluir (sin mezclar) las relaciones que pertenecen a una sola vista de usuario.
7. Comprobar que no se ha omitido ninguna entidad ni relación.
8. Comprobar las claves ajenas.
9. Comprobar las restricciones de i ntegridad.
10. Dibujar el esquema lógico global.
11. Actualizar la documentación.
9. Validar el esquema lógico global
Este proceso de validación se realiza, de nuevo, mediante la normalización y mediante la prueba
frente a las transacciones de los usuarios. Pe ro ahora sólo hay que normalizar las relaciones que
hayan cambiado al mezclar los esquemas lógicos locales y sólo hay que probar las transacciones
que requieran acceso a áreas que hayan sufrido algún cambio.
10. Estudiar el crecimiento futuro
En este paso, se trata de comprobar que el esquema obtenido puede acomodar los futuros
cambios en los requisitos con un impacto mínimo. Si el esquema lógico se puede extender
fácilmente, cualquiera de los cambios previstos se podrá incorporar al mismo con un efecto
mínimo sobre los usuarios existentes.
11. Dibujar el diagrama entidad -relación final
Una vez validado el esquema lógico global, ya se puede dibujar el diagrama entidad -relación que
representa el modelo de los datos de la empresa que son de interés. La doc umentación que
describe este modelo (incluyendo el esquema relacional y el diccionario de datos) se debe
actualizar y completar.
12. Revisar el esquema lógico global con los usuarios
Una vez más, se debe revisar con los usuarios el esquema global y la do cumentación obtenida
para asegurarse de que son una fiel representación de la empresa.

5.4. El modelo entidad-relación

El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de
bases de datos. Fue introducido por Pet er Chen en 1976. El modelo entidad -relación está
formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto
de representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad -relación sólo incluía los conceptos de entidad, relación y
atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías
de generalización, en lo que se ha denominado modelo entidad-relación extendido.
Entidad
Cualquier tipo de objeto o concepto sob re el que se recoge información: cosa, persona, concepto
abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de
productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante
rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una
vez en el esquema conceptual.
Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia
depende de la existencia de otra entidad. Un a entidad fuerte es una entidad que no es débil.
Relación (interrelación)
Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre
que describe su función. Las relaciones se representan gráficamente mediante rombos y s u
nombre aparece en el interior.
Las entidades que están involucradas en una determinada relación se denominan entidades
participantes. El número de participantes en una relación es lo que se denomina grado de la
relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si
son tres las entidades participantes, la relación es ternaria; etc.
Una relación recursiva es una relación donde la misma entidad participa más de una vez en la
relación con distintos papeles. El n ombre de estos papeles es importante para determinar la
función de cada participación.
La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y
el número máximo de correspondencias en las que puede tomar parte cada oc urrencia de dicha
entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de
cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad
participante. Si no, la participación e s opcional (parcial). Las reglas que definen la cardinalidad
de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas,
denominados trampas, suelen producirse a causa de una mala interpretación en el significado de
alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas
trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende
completamente el significado de cada r elación. Si no se entienden las relaciones, se puede crear
un esquema que no represente fielmente la realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación
entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de
resolverla es reestructurando el esquema para representar la asociación entre las entidades
correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre
entidades, pero el camin o entre una y otra no existe para algunas de sus ocurrencias. En este
caso, se produce una pérdida de información que se puede subsanar introduciendo la relación que
sugería el esquema y que no estaba representada.
Atributo
Es una característica de inter és o un hecho sobre una entidad o sobre una relación. Los atributos
representan las propiedades básicas de las entidades y de las relaciones. Toda la información
extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuel gan
de las entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define
todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos
sobre un mismo dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que tiene un
solo componente, que no se puede dividir en partes más pequeñas que tengan un significado
propio. Un atributo compuesto es un atributo con varios comp onentes, cada uno con un
significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto
cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto

se representa gráficamente mediante un óval o.

Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo
monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la
que pertenece. Un atributo polivalente es aquel que tiene varios valor es para cada ocurrencia de
la entidad o relación a la que pertenece. A estos atributos también se les denomina
multivaluados, y pueden tener un número máximo y un número mínimo de valores. La
cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede
tomar para cada ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es .
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un
valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente
deben pertenecer a la misma entidad o relación.
Identificador
Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo
único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos
condiciones:
 1. No pueden existir dos ocurrencias de la entidad con el mismo valor del identifi cador.
2. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos.
Las relaciones no tienen identificadores.
Jerarquía de generalización

Una entidad E es una generalización de un grupo de entidades E, E, ... E, si cada ocurrencia de

cada una de esas entidades es también una ocurrencia de E. Todas las propiedades de la entidad
genérica E son heredadas por las subentidades.
Cada jerarquía es total o parcial, y exclusiva o superpuesta. Una jerarquía es total si cada
ocurrencia de la entidad genérica corresponde al menos con una ocurrencia de alguna subentidad.
Es parcial si existe alguna ocurrencia de la entidad genérica que no corresponde con ninguna
ocurrencia de ninguna subentidad. Una jerarquía es exclusiva si cada ocurrencia de la entidad
genérica corresponde, como mucho, con una ocurrencia de una sola de l as subentidades. Es
superpuesta si existe alguna ocurrencia de la entidad genérica que corresponde a ocurrencias de
dos o más subentidades diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad como subentidad.
Un subconjunto siempre es una jerarquía parcial y exclusiva.

5.5. Normalización
La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de
información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrat egia de
diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas)
según su afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de
datos, sino como una etapa posterior a la correspond encia entre el esquema conceptual y el
esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la
normalización son las siguientes:
 Evita anomalías en inserciones, modificaciones y borrados.
 Mejora la independencia de da tos.

 No establece restricciones artificiales en la estructura de los datos.

Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una
dependencia funcional es una relación entre atributos de una misma relación (tabla). Si e son
atributos de la relación , se dice que es funcionalmente dependiente de (se denota por ) si cada
valor de tiene asociado un solo valor de ( e pueden constar de uno o varios atributos). A se le
denomina determinante, ya que determina el valor de . Se dice que el atributo es completamente
dependiente de si depende funcionalmente de y no depende de ningún subconjunto de .
La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre
atributos no lo determina una serie abstract a de reglas, sino, más bien, los modelos mentales del
usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema
de información. Cada dependencia funcional es una clase especial de regla de integridad y
representa una relación de uno a muchos.
En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una
serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que
se cumple aumenta el grado de normalizac ión. Si una regla no se cumple, la relación se debe
descomponer en varias relaciones que sí la cumplan.
La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal
que tiene unas propiedades. Conforme se va avanzando en l a normalización, las relaciones tienen
un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de
actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma
normal. Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de
actualización, es recomendable llegar al menos a la tercera forma normal.
Primera forma normal (1FN)
Una relación está en primera forma normal si, y sólo si, todos los dominios de la mism a
contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente
como una tabla, estará en 1FN si tiene un solo valor en la intersección de cada fila con cada
columna.
Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo
repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la
relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los
atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen
redundancias ya que se duplican valores, pero estas redundancias se eliminarán después
mediante las restantes formas normales. La segunda forma de eliminar los grupos repetitivos
consiste en poner cada uno de ellos en una relación aparte, heredando la clave primaria de la
relación en la que se encontraban.
Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos.
Segunda forma normal (2FN)
Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo
que no está en la clave primaria es completamente dependiente de la clave primaria.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más
atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces también está en 2FN. Las relaciones que no están en 2FN pueden sufrir anomalías
cuando se realizan actualizaciones.
Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave
primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en
una nueva relación con una copia de su determinante (los atributos de la clave primaria de los
que dependen).

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada atributo que
no está en la clave primaria no depende transitivamente de la clave primaria. La dependencia es
transitiva si existen las dependencias , , siendo , , atributos o conjuntos de atributos de una misma
relación.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía
pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de 2 FN a 3FN hay
que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen
transitivamente y se ponen en una nueva relación con una copia de su determinante (el atributo o
atributos no clave de los que dependen).
Forma normal de Boyce-Codd (BCFN)
Una relación está en la forma normal de Boyce -Codd si, y sólo si, todo determinante es una clave
candidata.
La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave
primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si
éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en
3FN.
La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que rar amente
se presentan. Se debe comprobar si una relación viola la BCFN si tiene dos o más claves
candidatas compuestas que tienen al menos un atributo en común.