Apuntes bd1

apuntes
Bases de Datos 1
Eva Gómez Ballester
Patricio Martínez Barco
Paloma Moreda Pozo
Armando Suárez Cueto
Andrés Montoyo Guijarro
Estela Saquete Boro
Dpto. de Lenguajes y
Sistemas Informáticos
Escuela Politécnica Superior
Universidad de Alicante
http://www.dlsi.ua.es/asignaturas/bd

BIBLIOGRAFÍA BÁSICA
A continuación se presentan los libros de textos que se consideran manuales
básicos para la asignatura. De cada uno de ellos, presentamos un breve
resumen con la intención de facilitar al alumno una primera aproximación
sobre la idoneidad de cada uno de ellos para cada una de las partes del
temario de la asignatura.
CELMA03
Celma, M.; Casamayor, J.C.; Mota, L.
Bases de Datos Relacionales
Pearson-Prentice Hall, 2003.
DATE01
Date, C.J.
Introducción a los sistemas de bases de datos.
Addison-Wesley Publishing Company, Ed. 7, 2001.
ELMASRI02
Elmasri & Navathe
Fundamentos de Sistemas de Bases de Datos.
Addison-Wesley Publishing Company, Ed. 3, 2002
SILBERSCHATZ02
Silberschatz, S., Korth, H.
Fundamentos de Bases de Datos.
Mc Graw-Hill, Ed. 3, 2002
CONNOLLY05
Sistemas de Bases de Datos.
Connolly, Thomas M.; Begg, Carolyn E.
Addison Wesley, 2005
DRAE
Real Academia Española de la Lengua
Diccionario de la Lengua Española
Espasa, 2001
http://buscon.rae.es/diccionario/drae.htm
Comentarios a la bibliografía
básica
CELMA03
Este libro está pensado para introducirse en la temática de las bases de datos
relacionales mediante una presentación formal y rigurosa. En los capítulos 1 y
2 se introducen los conceptos de base de datos, sistemas de gestión de
bases de datos y los principales modelos de datos. El capítulo 3 presenta los
fundamentos del modelo relacional de datos desde la doble perspectiva
algebraica y lógica, lo que permite introducir formalmente las estructuras de
datos del modelo y sus operadores asociados mediante el Álgebra Relacional.

Además proporciona la base formal lógica para introducir los lenguajes
lógicos de interrogación, el Cálculo Relacional de Tuplas y el Cálculo
Relacional de Dominios. En el capítulo 4 se introduce el lenguaje SQL, y en el
capítulo 5 se profundiza en el concepto de sistema de gestión de bases de
datos. El libro contiene numerosos ejemplos y ejercicios resueltos.
El libro ha sido realizado por un grupo de profesores de Bases de Datos de la
Universidad Politécnica de Valencia y recoge su experiencia en la enseñanza
de esta materia. Es por este motivo que se ajusta globalmente al enfoque
docente propuesto en la asignatura, y tiene especial aplicación en las
unidades 1, 2, 3, 4, y 7 del temario, aunque no incluye información sobre
aspectos de normalización (unidad 5), ni sobre la organización física de una
base de datos (unidad 6), y puesto que se basa en el modelo de datos
relacional, no incluye información para el seguimiento de la unidad 8 del
temario de la asignatura relativa al modelo entidad-relación.
DATE01
Este libro es la traducción en castellano de la séptima edición del texto Date,
ed. 2000 que revisa actualiza y mejora ciertos aspectos contemplados en la
versión previa Date, ed. 1993. El libro se organiza en seis partes principales.
La parte I proporciona una amplia introducción a los conceptos básicos de las
bases de datos, adaptándose al temario propuesto en la unidad 1 de la
asignatura, e incluyendo información acerca de los sistemas de gestión de las
bases de datos, adaptándose al propuesto en la unidad 7; la parte II aborda el
modelo relacional de datos incluyendo información actualizada y revisada
respecto a la 5ª edición, lo que lo hace más recomendable en este sentido
para el alumno (unidades 3, 4 y 5 del temario); la parte III trata la teoría
general del diseño de bases de datos incluyendo información acerca de la
teoría de la normalización (unidad 5 del temario) y del modelo entidad-relación
(unidad 8 del temario); la parte IV profundiza en los aspectos de recuperación
y concurrencia y la V en otros aspectos entre los que se incluye el de la
seguridad, lo que las hace recomendable a ambas para la extensión de los
conocimientos que los alumnos han manejado en la unidad 7 del temario.
Finalmente, la parte VI se dedica a la descripción del impacto de la tecnología
orientada a objetos en los sistemas de bases de datos, lo que puede servir
para iniciar al alumno hacia la enseñanza que se mostrará en la asignatura de
Bases de Datos Avanzadas (optativa).
ELMASRI02
Tercera edición de otro de los libros clásicos en bases de datos. El texto
contiene seis partes principales en las que abarca la gran parte de los
aspectos necesarios para la enseñanza de las bases de datos. En concreto,
la parte I se centra en los conceptos básicos de los sistemas de bases de
datos, y la parte II en el modelo relacional de datos, siendo ambas
especialmente recomendables para abarcar la enseñanza de la asignatura de
Bases de Datos I. De este texto se destaca además el rigor y la extensión con
los que trata cualquiera de los temas, y además las frecuentes referencias a
ejemplos sobre sistemas de gestión de bases comerciales como Oracle y
Microsoft Access. También se destaca la profundidad con la que se trata el
modelo entidad-relación con un frecuente uso de ejemplos, así como la
cobertura de otros aspectos relativos a tecnologías emergentes (novedad de
esta tercera edición) sobre las bases de datos como los relativos a los
almacenes de datos, tecnologías Web, multimedia y bases de datos
distribuidas. Estos aspectos son brevemente introducidos durante la unidad 1
del temario y serán analizados con mayor profundidad en la asignatura Bases
de Datos Avanzadas (optativa).

SILBERSCHATZ02
Este libro es una versión revisada, ampliada y corregida de un texto anterior
que con el mismo título fue escrito por los mismos autores korth93. En esta
revisión se ofrece un marco completo de los fundamentos y diseño de las
bases de datos, sus lenguajes de acceso y las diversas técnicas de
implementación de bases de datos. Además incluye numerosos ejercicios
después de cada tema que ayudan a la asimilación de los contenidos, así
como frecuentes ejemplos para apoyar las diferentes explicaciones. Este libro
se puede considerar como básico para el seguimiento de la asignatura ya que
contiene un tratamiento elemental sobre todos y cada uno de los aspectos
propios de las bases de datos, y además proporciona algunos aspectos más
avanzados que pueden ser usados por el alumno como complemento a su
enseñanza teórica o como introducción a otras asignaturas más avanzadas
sobre las bases de datos.
Se destacan de este libro los capítulos 1 al 5 que contienen la introducción a
las bases de datos, el modelo entidad-relación y posteriormente el desarrollo
del modelo relacional encajando perfectamente en las unidades 1, 3, 4 y 8 del
temario de la asignatura, aunque lo hace de una forma bastante elemental.
Más interesantes resultan los capítulos 10 al 21 en los que se tratan los
aspectos más avanzados de los sistemas de gestión de las bases de datos,
desde el acceso físico a los datos pasando por aspectos como el
procesamiento de las consultas, transacciones, concurrencia, seguridad,
arquitectura, acceso cliente/servidor y bases de datos distribuidas, que
permitirán al alumno profundizar en los temas mostrados en las unidades 6 y
7 del temario de la asignatura. Especialmente se destaca el capítulo 4 que
realiza un estudio tanto teórico como práctico del lenguaje SQL lo que servirá
al alumno para aclarar conceptos y problemas que se le presentan en las
sesiones prácticas de la asignatura.
Sin embargo, el libro adolece de una falta de profundidad en el tratamiento del
concepto de modelo de datos del que únicamente se presentan brevemente
las diferencias entre los modelos de datos más tratados. Aún así puede ser
considerado como una obra básica para la asignatura.

I introducción a las bases de datos 1
I1. introducción intuitiva 3
I2. evolución de las técnicas de procesamiento electrónico de la
información 8
II modelos de datos 15
II1. Sistemas de información 16
II2. Conceptos y definiciones 19
II3. Representación de un sistema de información 22
II4. Cualidades de los modelos de datos 23
II5. Clasificación de modelos de datos 23
III el modelo relacional 27
III1. introducción intuitiva 29
III2. concepto de relación 30
III3. representación de objetos 32
III4. restricciones semánticas 43
III5. operadores 55
III6. otras características 56
III7. conclusiones 58
IV álgebra relacional 61
IV1. Conceptos previos. 62
IV2. definición informal de los operadores 65
IV3. Resumen de los operadores del Álgebra Relacional 76
IV4. ejemplos 77
IV5. Referencia 83
V introducción al diseño de bases de datos relacionales 87
V1. Introducción 88
V2. dependencia funcional 91
V3. formas normales 93
V4. forma normal de boyce-codd 97
V5. Un ejemplo ¡Error! Marcador no definido.
VI la perspectiva lógica del modelo relacional 99
VI1. introducción 100
VI2. cálculo de predicados de primer orden 100
VI3. una base de datos relacional como una interpretación de un lenguaje
de primer orden. 109
VI4. fórmulas seguras 113
VI5. cálculo relacional 117

VII organización física de las bases de datos 123
VII1.introducción 125
VII2.conceptos básicos 126
VII3.ficheros 129
VII4.implementación de bases de datos relacionales 138
VIII sistemas de gestión de bases de datos 141
VIII1. técnicas de base de datos 142
VIII2. arquitectura de un sistema de gestión de bases de datos 143
VIII3. el administrador de la bd 148
VIII4. componentes y funciones de un SGBD 149
VIII5. independencia, integridad y seguridad 151
VIII6. arquitectura cliente-servidor 154
IX introducción al modelo entidad-relación extendido 157
IX1. modelo entidad-relación 159
IX2. ejemplo 1 165
IX3. otros mecanismos de abstracción 169
IX4. ejemplo 2 170
IX5. deficiencias del modelo 172

1
I INTRODUCCIÓN A LAS BASES
DE DATOS
Como primera introducción a la asignatura Bases de Datos I, se pretende
efectuar un somero recorrido por los conceptos e ideas a tratar en ella, dando
una visión superficial de las técnicas de bases de datos. Se expone, de una
manera informal y no estructurada, el contexto y los contenidos de la
asignatura.

Introducción a las bases de datos
3
I1. introducción intuitiva
La necesidad de manejar información
Pongamos como ejemplo un caso sencillo: queremos mantener de forma
electrónica una lista con los discos que hemos comprado a lo largo de estos
años. Tenemos un ordenador y un programa que nos permite almacenar la
lista como se presenta a continuación.
autor Título format año tipo
COCTEAU TWINS Victorialand CS 86 Ambient
BJÖRK Post CD 95 Pop
BLACK CROWES Amorica CD 94 Rock
BLUE NILE,THE High CD 04 Pop
BOB MOULD CD 96 Independientes
BLUR Leisure CD 90 Pop
BUD POWELL Jazz Time CD Jazz
CANDY DULFER Saxuality CS 93 Fusión
CHURCH,THE The Blurred Crusade LP 82 Pop
COCTEAU TWINS Blue Bell Knoll CD 88 Ambient
CURVE Pubic Fruit CG Independientes
COCTEAU TWINS Milk And Kisses CD 95 Ambient
CODE BLUE Code Blue LP 80 Pop
COP SHOT COP Ask Questions Later CD 93 Independientes
COMITE CISNE Dulces Horas(Maxi) LP 85 Pop
COMPLICES La Danza De La Ciudad CD 90 Pop
CONSTANCE DEMBY Novus Magnificat CD 86 Nuevas Músicas
CULT, THE Sonic Temple CD 89 Hard Rock
CURVE Doppelgänger CS Nueva Psicodelia
La lista es muy sencilla, y está detallada por autor del volumen, título, año de
publicación, formato en que lo tenemos disponible en nuestra discoteca (CD
es disco compacto, CS es cassette, y LP es disco en vinilo), y una
clasificación propia del estilo de música que contiene.
¿Para qué necesitamos almacenar los datos de esta manera? A lo largo del
tiempo hemos ido adquiriendo más y más discos, y nos gusta intercambiar
música con nuestros amigos (como se hacía antes, de forma inocente y legal,
según lo que se entiende por legal hoy en día). Es más práctico dar una lista
en papel, o enviarla por correo electrónico para que éste elija lo que más le
guste, en vez de invitarle a casa y que él se lleve los discos viéndolos
directamente en el estante; nuestro amigo también nos proporcionaría su
propia lista para hacer nosotros lo propio.
Precisamente en este punto, cuando la cantidad de discos es grande, hacer
dicha lista no es tan fácil. Podemos pensar que lo normal es comenzar a
confeccionarla un día y anotar en ella las nuevas adquisiciones a medida que
van llegando. Más tarde, si alguien nos la pide, podemos fotocopiarla y
proporcionársela.
Sin embargo, es evidente que la lista no está ordenada bajo ningún criterio,
salvo si nos hemos tomado la molestia de, cuando creamos la lista, anotar la
información ordenada por autor, por ejemplo. No obstante, las nuevas
entradas de la lista estarán desordenadas puesto que las anotamos al final de
esa lista. Además, con la cantidad de discos que manejamos, es fácil que
tengamos descripciones de discos repetidas, o mal catalogadas, o con el año
equivocado; ¿qué hacemos?: ¿un borrón, escribir encima, escribirla a lápiz
para poder borrar y rectificar?
Un día, un amigo nos pide una lista de los discos que tenemos, pero sabemos
que lo que le gusta es el guitarreo y el ruido, lo que nosotros catalogamos

BD1 2006-2007
4
como rock, duro, o independiente. La única posibilidad es darle la lista y que
él mismo se busque lo que le interesa.
Cansados de estas limitaciones decidimos utilizar el ordenador. Lo hacemos
porque nos permite obtener listados ordenados por cualquier criterio,
mantener la información actualizada, y corregir los errores fácilmente.
Figura 1.1. Ejemplo de bases de datos de discos
Además, esta información la podemos suministrar de cualquier forma: en
papel mediante la salida por impresora, por correo electrónico, en un fichero
de texto en un dispositivo de almacenamiento portátil o, en definitiva, en
cualquier formato de intercambio. Podemos tener copias de seguridad por si
se nos pierde la lista principal. Además, si queremos dar más datos
descriptivos de nuestros discos, el ordenador nos da facilidades para hacerlo
sin alterar la información anterior: sólo la definición de los listados se alterará
para poder imprimir, a partir de entonces, los nuevos datos.
Herramientas para manejar la información
Ya hemos dicho que vamos a utilizar un ordenador y un programa para
almacenar los datos y manejarlos. La primera opción en la que podemos
pensar es un procesador de textos o una hoja de cálculo, donde la
información es fácilmente accesible y modificable. Simplemente se trata de
escribir la lista y guardarla en el disco duro. No obstante, el programa
diseñado desde un principio para hacer lo que nosotros pretendemos es un
programa de creación y manejo de bases de datos, un sistema de gestión
de bases de datos (SGBD). Una base de datos (BD)1
es un conjunto de
datos estructurados apropiadamente y relacionados entre sí (como, por
ejemplo, nuestra lista de discos). Podemos tener tantas bases de datos
almacenadas en nuestro disco duro como permita la capacidad del disco
duro: la lista de discos, la agenda de teléfonos y direcciones de nuestros
amigos, etc., son todas bases de datos diferentes; o podríamos tener
relacionada los discos con la agenda de tal forma que sepamos en todo
1 Para el profano en la materia es normal denominar al programa de gestión simplemente base
de datos. Entiéndase que un sistema de gestión de bases de datos, el programa, puede manejar
una o muchas bases de datos, uno o muchos conjuntos de información sobre un determinado
tema.

5
momento a quien le prestamos los discos, con lo que todo sería una única
base de datos.
El SGBD nos facilita un interfaz para introducir nuestra información desde
teclado o cualquier otro periférico que lo permita, y procesar después esa
información para obtener informes de cualquier tipo. Por ejemplo nos puede
interesar tener un listado ordenado por autor y otro por tipo de música. Otro
informe puede que sólo tenga la información del autor, título y año de
publicación del disco.
La ventaja estriba en que la información sólo la hemos introducido una vez, y
es el propio sistema de gestión de base de datos el que, según nuestras
necesidades, se encarga de clasificar esa información cada vez que le
pedimos un listado. Además, si nos hemos equivocado en el año de
publicación de un disco, simplemente lo modificamos y en los siguientes
listados ya saldrá corregido. Si quisiéramos borrar un disco, porque se nos
haya perdido o roto, tampoco es un problema: simplemente, cuando el SGBD
vaya a realizar un nuevo listado no se encontrará con ese disco entre los
datps que maneja.
Figura 1.2. Ejemplo de consulta a la base de datos mediante una sentencia
SQL.
Diseño del almacenamiento de la información
El fundamento de toda BD se encuentra en el análisis y el diseño. Al SGBD se
le han de proporcionar dos cosas: los datos y la forma en que los vamos a
almacenar. Es decir, un disco musical, para nosotros, es un objeto que tiene
como características que lo diferencian de otro disco conceptos tales como la
información del autor, el título, el año de publicación, el formato del disco y el
tipo de música que contiene. Debemos, antes de nada, darle al SGBD estos
conceptos con su correspondiente tipo de datos: si es un número, si es una
cadena de caracteres, si es una fecha, etc. Una vez hecho esto, ya podemos
introducir los datos de nuestros discos. De la misma forma, una vez que se
han introducido los mismos, podemos realizar consultas sobre los datos
almacenados basándonos en los objetos definidos.

BD1 2006-2007
6
I1.1. Sistema de Gestión de Base de Datos
Un SGBD es un programa de ordenador que facilita una serie de
herramientas para manejar bases de datos y obtener resultados (información)
de ellas. Además de almacenar la información, se le pueden hacer preguntas
sobre esos datos, obtener listados impresos, generar pequeños programas de
mantenimiento de la BD, o ser utilizado como servidor de datos para
programas más complejos realizados en cualquier lenguaje de programación.
Además, ofrece otras herramientas más propias de la gestión de BD como
sistemas de permisos para autorización de accesos, volcados de seguridad,
transferencia de ficheros, recuperación de información dañada, indización,
etc.
En general, un SGBD es un software de BD que
• centraliza2
los datos en un único “lugar” lógico al que acceden
todos los usuarios y aplicaciones.
• es utilizable por múltiples usuarios y aplicaciones
concurrentemente.
• ofrece visiones parciales del conjunto total de información, según
las necesidades de un usuario en particular.
• posee herramientas para asegurar:
la independencia de datos: a varios niveles, permitiendo
la modificación de las definiciones de datos sin afectar a
las aplicaciones o esquemas que no utilizan esos datos.
la integridad de los datos: que los datos sean correctos
en todo momento, de acuerdo con las especificaciones o
reglas impuestas al sistema
la seguridad de los datos: que sólo las personas
autorizadas puedan acceder a determinados datos y que
sólo puedan efectuar las operaciones para las que han
sido autorizados.
Hay muchos tipos de SGBD, pero la mayor parte de los utilizados
comercialmente en la actualidad son relacionales, es decir, se basan en una
cierta teoría o forma de representar los datos para implementar sus
herramientas e interfaces, en este caso el modelo relacional. Entendemos
por representación de los datos como la forma en que se presentan al usuario
y que permiten ciertas operaciones para poder manejarlos.
De hecho, en estos SGBD, la información se presenta en forma de tablas
(“relación” es el término formal), con columnas para las características de los
objetos o conceptos que pretende representar la tabla, y filas para cada caso
concreto o instancia de objeto. Existe un lenguaje considerado como estándar
para manejar esas tablas, el SQL, que permite crear y modificar tablas, y
consultarlas, introducir nuevos datos, modificar los ya almacenados, o
borrarlos.
Al decir que un SGBD es relacional, estamos hablando de que, como mínimo,
sigue todas las reglas y conceptos propuestos por el modelo relacional. El
modelo relacional se basa en la teoría de conjuntos y es, por tanto, un modelo
con un fundamento matemático. Este modelo maneja una estructura de datos,
la relación (concepto matemático que se representa “físicamente” como una
tabla), y unos operadores definidos sobre ella.
2 Nos referimos a las bases de datos centralizadas. En otras asignaturas se profundiza en el
concepto de bases de datos distribuidas.

7
Estos operadores se agrupan en lenguajes de especificación y manipulación,
que nos proporcionan una sintaxis para poder dar ordenes al SGBD. A nivel
teórico se proponen tres lenguajes equivalentes en cuanto a las cosas que
pueden hacer: el Álgebra Relacional, el Cálculo Relacional orientado a
Tuplas y el Cálculo Relacional orientado a Dominios. El álgebra está
basado en el álgebra de conjuntos, mientras que los dos cálculos se basan en
el cálculo de predicados de primer orden.
El SQL, que podemos decir que es el lenguaje “real” utilizado, tiene su origen
formal en los anteriores. Además, aporta más operadores, necesarios para
manejar eficazmente una BD relacional.
Como procedimiento de comprobación de la calidad de nuestros esquemas
de base de datos relacionales veremos la teoría de la normalización. Ésta
nos dice cuando una tabla es correcta: no contiene redundancia innecesaria,
teniendo en cuenta las dependencias que existen entre las columnas de la
tabla, y proporciona los métodos para corregir las deficiencias detectadas
No debemos olvidar que para almacenar datos en una BD primero debemos
diseñarla, decir cuáles y cómo son las tablas (si hablamos exclusivamente de
los sistemas relacionales). Para tal diseño se suelen utilizar otros modelos de
datos más intuitivos y expresivos. Uno muy cercano al modelo relacional, el
Entidad-Relación Extendido3
(EER) se utiliza para definir la BD sobre papel.
Una vez que ya sabemos cómo representar la información nos queda,
simplemente, crear las tablas e introducir la información.
Hemos hablado de dos de los muchos modelos de datos que existen.
Brevemente, un modelo de datos es un conjunto de reglas y conceptos que
sirve para describir un conjunto de información. Estos modelos de datos
pueden ser de tipo gráfico (p.ej. el Entidad-Relación) o no, e incluir más o
menos formas de representar hechos y objetos de la vida real. Al modelar un
conjunto de datos, un sistema de información, lo que estamos haciendo es
desechar la información no útil quedándonos únicamente con la que nos
interesa, y representando lo más fielmente posible las interrelaciones entre
los datos de ese sistema.
Pero, ¿qué había antes de las BD y los SGBD, y por qué nacen éstos? Los
comienzos gestión administrativa ayudada por ordenador fueron fruto del
desarrollo de los lenguajes de programación normales de aquella época,
como COBOL, FORTRAN, BASIC, etc., y la información se manejaba
mediante ficheros convencionales de registros. Los avances en hardware
y software generaron un incrementó exponencial del volumen de dato
manejado, y el rendimiento de estos programas bajó al tiempo que los costes
de mantenimiento crecieron de forma alarmante. Los datos se duplicaban
innecesariamente, no había suficientes controles de seguridad frente a
accesos no autorizados a la información, ni controles de calidad de los datos.
Alterar las estructuras de datos, los ficheros, llevaba aparejado una ingente
cantidad de trabajo para modificar todos los programas afectados. Como
solución a estos y otros problemas se desarrollaron las técnicas de Bases
de Datos.
3 También conocido como Entidad-Interrelación, por diferenciar el concepto relación en este
modelo y en el relacional: en el primero es una dependencia o asociación entre objetos,
mientras que en el segundo es la estructura de datos que almacena los datos.

BD1 2006-2007
8
I2. evolución de las técnicas de
procesamiento electrónico de la
información
I2.1. sistemas de información mecanizados
tradicionales.
Veamos ahora, de una forma muy sucinta, cuales fueron los inicios de los
sistemas de información mecanizados. Éstos han ido evolucionando hasta el
presente al ritmo de las innovaciones tecnológicas tanto en hardware como
en software. El hecho de disponer de una determinada tecnología siempre
conlleva ciertas ventajas sobre los sistemas anteriores, y una serie de
limitaciones impuestas por las posibilidades de la técnica de ese momento.
Todo se traduce en una carrera en la que se solucionan problemas y
carencias para mejorar la calidad, prestaciones, flexibilidad y seguridad de
nuestro sistema de información, a la vez que la mayor exigencia y las nuevas
necesidades de los usuarios plantea nuevos problemas no previstos o no
abordables en un momento dado.
Los sistemas de información basados en archivo convencional se apoyan
en las distintas organizaciones de fichero: secuenciales, directos
(direccionamiento directo, calculado), indexados, invertidos... Estas
organizaciones llevan aparejados unos métodos de acceso a los registros
particulares: el acceso secuencial recorre todos los registros hasta encontrar
el buscado; el indexado puede acceder en un solo paso al registro si estamos
buscando por un campo clave. Para el manejo de estos ficheros los sistemas
operativos llevan integradas rutinas que facilitan las operaciones básicas:
inserción, borrado, modificación y recuperación.
Para entender mejor el origen y necesidad de las bases de datos es
interesante analizar las características del sistema tradicional. La
característica básica de estos sistemas es que los ficheros se diseñaban para
un programa concreto. Esto los hace muy eficientes en principio, pero los
problemas aparecen cuando hay que ampliar o modificar el sistema inicial.
Puesto que la definición de los datos está dentro de cada programa de
aplicación, cualquier alteración de la estructura de los ficheros que manejan
nos obliga a recompilar todos los programas que utilicen esos ficheros, o bien
construir nuevos programas que utilicen nuevos ficheros con información
replicada o calculada en base a los antiguos.
La solución más rápida y fácil suele ser construir nuevos programas y ficheros
con información redundante, más si se piensa en sistemas grandes donde
cada departamento representa un conjunto de usuarios con una visión parcial
de la Organización (la que es necesaria para su propio cometido), y por lo
tanto, con un conocimiento parcial del sistema global.
Por ejemplo, en una Universidad, la sección de Personal, la secretaría del
Centro y el Departamento tienen una visión distinta de los datos almacenados
sobre un empleado docente, algunos comunes a todos (nombre, dirección,
categoría, ...), pero otros únicamente útiles para una de ellos. La información
sobre cuenta bancaria, estado civil o número de hijos es necesaria para
Personal, pero no las asignaturas impartidas por el profesor o su horario. Esta
distinta perspectiva de la organización es la que conduce en muchos casos a
desarrollar aplicaciones separadas con ficheros propios.

9
En definitiva, todos ellos manejan información que pertenece a la
organización, pero el desarrollo de los tratamientos de esos datos se realiza
independientemente de los otros usuarios, de tal forma que cada aplicación
es un objeto autónomo.
Puestas así las cosas, es fácil que nos encontremos, en un sistema de
información mecanizado basado en archivo convencional, con los siguientes
problemas:
• Redundancia de datos.
• Dependencia de los programas respecto de los datos.
• Insuficientes medidas de seguridad en tres aspectos:
control de accesos simultáneos
recuperación de ficheros
control de autorizaciones
Pasamos ahora a describir cada uno de estos puntos.
I2.2. deficiencias de los sistemas basados en
archivo convencional
Redundancia de datos.
El desarrollo de las aplicaciones no termina nunca. Las necesidades de la
organización son cambiantes y evolucionan con el tiempo. Esto quiere decir
que siempre se están creando nuevas aplicaciones y modificando las
existentes. En un sistema de ficheros tradicional, cada programa lleva su
propia definición de datos y maneja sus propios ficheros. Además, suelen ser
varios los programadores que las realizan, bien en el mismo período de
tiempo, o porque se van sustituyendo unos a otros.
El resultado fue, habitualmente, que muchos ficheros utilizados por diversos
programas almacenaban la misma información. Y no solo eso, sino que la
mayoría de las veces no recibían el mismo nombre ni coincidían los tipos de
datos. Por ejemplo, un campo ciudad (cadena de 20 caracteres de longitud)
en un fichero, se llamaba localidad en otro y podía tener una longitud mayor
que la primera.
Evidentemente, es la falta de control sobre los datos que generaba la
empresa lo que llevaba a estas situaciones. Una persona o equipo que se
dedicara a supervisar todas las aplicaciones podría intentar mejorar este
problema. En realidad, estos sistemas no son los adecuados para la tarea por
lo costoso que resultaría tal control (y así aparecerán las técnicas bases de
datos).
Aunque cada aplicación gestiona información propia, siempre hay datos
comunes a varias aplicaciones. Al estar estos datos almacenados en ficheros
independientes se produce redundancia dentro del sistema de información, lo
que genera situaciones indeseables:
• inconsistencia: al tener almacenada la misma información en
varios sitios, es difícil mantenerlos en el mismo estado de
actualización (que en todo lugar tenga el mismo valor), pudiendo
producir información incorrecta.
• laboriosos programas de actualización: no es lo mismo modificar
el valor de un dato una sóla vez que tantas veces como se halle
duplicado.

BD1 2006-2007
10
• mayor ocupación de memoria.
Dependencia de los programas respecto de los datos.
En los sistemas clásicos la descripción de los ficheros usados por un
programa, con información sobre formato de los registros, organización y
modo de acceso, localización del fichero, etc., forma parte del código del
programa.
Esto significa que cualquier cambio realizado en alguno de estos tres
aspectos obliga a reescribir y recompilar todos los programas que utilicen el
fichero modificado. Piénsese, por ejemplo, si se cambiara la organización de
un fichero de secuencial a indexado, o que se añadiera un campo a un
registro para una aplicación nueva, hecho éste que, en teoría, no tendría que
afectar a las antiguas.
Podemos decir que los programas son completamente dependientes de los
datos, lo que provoca:
• poca flexibilidad del sistema de información frente a futuras
variaciones en los requerimientos de información.
• alto coste de mantenimiento del software.
Insuficientes medidas de seguridad:
• control de accesos simultáneos
El acceso simultáneo de dos o más programas a unos mismos datos
puede conducir a errores en la información almacenada.
Supongamos dos procesos que deben acceder al mismo dato, que en
ese instante vale 100, y lo hacen concurrentemente, de tal forma que el
primero suma al valor leído 200 y el segundo 500, por lo que finalmente
deberíamos obtener un valor de 800 y almacenarlo.
Supongamos que el primer proceso llega antes que el segundo. Las
respectivas transacciones comprenden una operación de lectura del
dato almacenado y la posterior escritura del dato incrementado (la
transacción está formada por dos operaciones atómicas).
Cuando el primero ha terminado de leer (y obtiene el valor 100) y antes
de actualizar el dato (sumándole 100), el segundo proceso también
efectúa una operación de lectura recuperando el mismo valor. Debido a
la secuencia de operaciones en el tiempo, la actualización del proceso
1 se pierde puesto que, inmediatamente después, el proceso 2 modifica
el mismo dato pero con una suma errónea. Es como si el proceso 1
nunca se hubiera ejecutado.
proceso 1
proceso 2
t
leer
(100)
escribir
(100+200)
leer
(100)
escribir
(100+500)
• recuperación de ficheros
En el caso de procesos de actualización incompletos o erróneos hace
falta devolver los ficheros a un estado anterior correcto a partir del cual
se puedan repetir, ahora correctamente, los procesos de actualización

11
rechazados. Tradicionalmente se recurre a copias de seguridad de los
ficheros afectados.
• Control de autorizaciones
No todos los usuarios deben poder acceder a los mismos datos, por
motivos de privacidad de la información, ni pueden acceder de la
misma forma, por permisos a la hora de realizar recuperaciones,
actualizaciones, etc. En los sistemas clásicos, al tener aplicaciones
independientes, el volumen de información y el número de usuarios de
cada una era reducido, pudiendo aplicarse estas medidas de seguridad
a nivel humano.
A medida que fueron creciendo los sistemas se vio la necesidad de que
el software dispusiese de mecanismos de seguridad adecuados a estos
niveles.
En resumen, las características de los sistemas basados en archivo
convencional adolecen de los siguientes problemas al incrementarse las
exigencias y el volumen de datos:
• Pobre control de los datos: los datos pueden estar replicados
innecesariamente, llamarse de distinta forma y tener distintas
definiciones en diferentes ficheros.
• Capacidades de manipulación de los datos inadecuadas: las
organizaciones de ficheros no son adecuadas para cierto tipo de
operaciones que impliquen acceder a los datos para obtener
información elaborada (o simplemente, en el mejor de los casos,
que el criterio de búsqueda no está indexado).
• Excesivo esfuerzo de programación: en entornos de este tipo, la
programación de nuevas aplicaciones obligaba a construir de
nuevo las definiciones de fichero y rutinas de acceso en la
mayoría de los casos.
Podemos decir que esta situación es la que “obliga” a replantear la forma de
gestionar grandes volúmenes de datos, buscando principalmente la
independencia de las aplicaciones respecto de la representación física de los
datos almacenados. Nacen entonces las técnicas de bases de datos, que
se abordan en el siguiente tema.

BD1 2006-2007
12
1ª generación
(Desde mediados de los 40 a mediados
de los 50)
2ª generación
(Desde mediados de los 50 a mediados
de los 60)
3ª generación
(Desde mediados de los 60 a mediados de
los 70)
4ª generación
(Desde mediados de los 70 a
mediados de los 80)
5ª generación
(Desde mediados de los 80
a mediados de los 90)
Modelos de datos
o Modelo jerárquico
o Modelo red
o Modelo relacional o Modelos semánticos
o M. Orientados a
Objetos
o ...
Dispositivos de
almacenamiento
o programas + datos
o tarjetas perforadas
o Cintas magnéticas (1945)
o Discos magnéticos o Tambores
o SGI
o Discos
o o
Productos
o IDS de General Electric (1965)
o BOMP, DBOMP, CFMS de IBM
o TOTAL de Cincon (1971)
o IMAGEN de HP
o ADABAS de Software AG
o SYSTEM 2000 de MRI
o SGBD IMS/1 de IMB (1969) (Modelo
jerárquico)
o Sistemas de red CODASYL (1969-71)
o IDS/2 de Honeywell
o DMS-1100 de Univac
o IDMS de BF Goodrich
o DBMS de Digital
o INGRES de la U.Berkeley
(1973-77)
o System R de IBM (1974-78)
o INGRES de RTI (1980)
o SQL/DS de IBM (1981)
o ORACLE de RSI (1981)
o DB2 de IBM (1983)
o RDB de Digital (1983)
o ORION de MCC
o OpenOODB de TI
o IRIS de HP
o Gemstone de
ServioLogic
o ONTOS de Ontologic
o O2 de O2 Tech.
o ObjectStone de Object
Design
o CORAL de U.
Wisconsin
o LDL de MCC
Acceso de datos
o Ficheros secuenciales o Ficheros de a. directo
o Ficheros indexados
o Ficheros hash
o Ficheros integrados
o Ficheros invertidos
o Ficheros secuencial-indexado
Avances destacados de
la generación
o Gestión de datos apoyado en
aplicaciones
o Integración de información
o Independencia de datos
o SGBD prerelacionales
o Sistemas de gestión de bases de datos
relacionales
o Sistemas de gestión de bases
de datos postrelacionales
Visión diacrónica de la evolución de la tecnología de las bases de datos

introducción a las bases de datos
13
CONCLUSIONES
Toda organización, sea pequeña o grande, tiene unas necesidades de
información, bien en la forma tradicional de datos administrativos, bien en
sistemas avanzados de tratamiento de información de todo tipo. De todos los
datos que entran y salen de esa organización, en el formato que sea, unos
son importantes y otros no tanto.
El objetivo de un analista es identificar la información importante y
estructurarla de forma que sea útil para todos los miembros de la
organización. Ese sistema de información puede ser mecanizado mediante
herramientas informáticas y servir así a la productividad de la entidad.
En un principio, los sistemas de información a mecanizar eran sencillos y
reflejaban más o menos exactamente el flujo administrativo de papel del
exterior hacia la empresa, dentro de la misma empresa, y de la empresa hacia
el exterior nuevamente. Para ello se utilizaban los lenguajes de programación
disponibles, más o menos adecuados para la tarea, que manejaban ficheros
organizados según lo permitía la tecnología del momento.
Pero pronto nuevas necesidades y expectativas hicieron que el
mantenimiento y creación de aplicaciones informáticas, junto con el
incremento masivo de la cantidad de datos a almacenar y tratar, se convirtiera
en un cuello de botella debido a problemas de redundancia (e inconsistencia)
de datos, deficientes medidas de seguridad, baja calidad de la información
almacenada, y pérdidas de información por diversas causas. La tecnología
del momento no era adecuada para sistemas de información en constante
evolución y con unos requerimientos de rendimiento y fiabilidad cada vez más
exigentes.
La aparición de las técnicas de bases de datos vino a solucionar gran parte
de estos problemas.
BIBLIOGRAFÍA
[CELMA97]
[DATE2000]
[KORT87]
Prieto, A.; Lloris, A.; Torres, J. C.;
Introducción a la Informática
McGraw-Hill, 2ª edición.

15
II MODELOS DE DATOS
Antes de entrar a la descripción del modelo relacional, objetivo central de la
asignatura, debemos definir lo que es un modelo de dato en general.
La calidad del análisis y diseño de un sistema de información que
pretendemos mecanizar dependerá de los modelos de datos que utilicemos
para cada una de las fases de desarrollo. Además, disponer de herramientas
software basadas en modelos de datos adecuados a nuestra tarea nos hará
más fácil y rentable el diseño y el mantenimiento.
Podemos decir que, en líneas generales, el diseño de un sistema de
información, en lo que atañe a las bases de datos, tiene tres fases:
• Diseño conceptual: en la que se formalizan las estructuras que
se observan en el mundo real produciendo lo que se denomina
Esquema Conceptual.
• Diseño Lógico: en la que se estructura el conjunto de
información de la fase anterior teniendo en cuenta el SGBD que
se vaya a utilizar. En esta fase obtendremos el Esquema Lógico.
• Diseño Físico: en la que se estructuran los datos en términos de
almacenamiento en los dispositivos del ordenador. Es lo que se
conoce como Esquema Interno.
Para definir esas representaciones, es decir, los distintos esquemas,
utilizaremos uno o varios modelo de datos, un formalismo o un lenguaje que
nos permite representar una realidad con una mayor o menor riqueza de
detalle.
Podemos considerar que los Modelos de Datos se utilizan, entre otras
aplicaciones, para:
• Como herramienta de especificación, para definir tipos de datos y
la organización de los datos de una BD específica.
• Como soporte para el desarrollo de una metodología de diseño
de BD.
• Como formalismo para el desarrollo de familias de lenguaje de
muy alto nivel, para la resolución de requerimientos y
manipulación de datos.
• Como modelo soporte de la arquitectura de los SGBD.
• Como vehículo para investigar el comportamiento de diversas
alternativas en la organización de los datos.

BD1 2006-2007
16
En una primera aproximación, un modelo de datos es un conjunto de
conceptos y unas reglas de composición de esos conceptos que, combinados
de alguna forma, son capaces de representar un sistema de información,
tanto en su parte estática como dinámica.
Pero, hablando de bases de datos, ¿qué es antes: el modelo de datos o el
SGBD? En realidad, el concepto de modelo de datos es totalmente
independiente de las técnicas de BD. Es una herramienta que permite
describir un determinado concepto o sistema. Los SGBD se apoyan en un
determinado modelo de datos para poder estructurar la información a
almacenar y gestionarla rentablemente. Esto implica unas ciertas reglas que
el diseñador de la BD debe seguir para “informar” al SGBD de cómo se van a
introducir los datos y que límites, restricciones o evolución pueden o deben
tener esos datos.
No olvidemos, pues, que el modelo de datos es una “forma de hablar”, un
lenguaje de representación que podemos utilizar independientemente de que
se vaya a utilizar un ordenador o no, y que nos sirve para definir las
propiedades esenciales de un sistema de información y, al mismo tiempo,
poder comunicarnos con otras personas para explicarles esas propiedades.
El siguiente punto pretende ser el marco de partida para introducir los
modelos de datos, herramientas que se utilizan para describir, mejor o peor,
una realidad concreta. El concepto a desarrollar es el Sistema de información,
la realidad que queremos modelar y convertir (seguramente) en un sistema de
información mecanizado por ordenador.
II1. Sistemas de información
Uno de los pilares de cualquier organización es la información que necesita
para su funcionamiento. Asimismo, el tratamiento de dicha información es una
de sus ocupaciones básicas. Podemos decir que la Organización dispone en
un primer momento de una cantidad de datos desordenados e inconexos
sobre el entorno en el que se desarrolla y la actividad o actividades a las que
se dedica. Es primordial, pues, ordenar e interrelacionar esos datos y obtener
conclusiones de ellos, es decir, obtener información elaborada que permita
tomar decisiones o conocer el estado de la Organización.
El tratamiento de la información (sea manual o electrónico) tiene como
objetivo proporcionar esa información elaborada, de tal forma que sea
correcta, se obtenga en el momento y lugar adecuado, para la persona
autorizada y con el mínimo coste.
Si un sistema es un conjunto de “cosas” que, ordenadamente relacionadas
entre sí, contribuyen a cumplir unos determinados objetivos, un sistema de
información es un conjunto de elementos (en este caso datos),
ordenadamente relacionados entre sí siguiendo unas ciertas reglas, que
aporta al sistema objeto (la organización a la que sirve y que le marca las
directrices de funcionamiento) la información necesaria para el cumplimiento
de sus fines, para lo cual tendrá que recoger, procesar y almacenar los datos,
facilitando la recuperación, elaboración y presentación de los mismos.
Dicho de otra forma, un sistema (y un sistema de información en particular) es
un conjunto de componentes conectados de forma organizada. Dependiendo
de cómo estén conectados el sistema se comporta o contribuye a sus fines de
una manera concreta; si cambiamos esas interrelaciones, su comportamiento
cambiará, al igual que si eliminamos o agregamos componentes.
Esos componentes del sistema de información, datos en nuestro caso, se
representarán mediante papeles que se archivan o cualquier otro tipo de

modelos de datos
17
almacén de información (¿una base de datos?). Así, si deseamos controlar el
inventario de un almacén, el sistema físico que queremos representar es el
local donde se almacenan y se retiran ciertas mercancías.
En realidad, el encargado podría pasarse todos los días por el lugar y
comprobar si se ve el suelo del almacén, y decidir entonces que es necesario
reponer existencias. Otra forma de organizar el almacén es construir un
sistema de información en el que las entradas y salidas no sean bienes
materiales sino notas de pedido, albaranes, etc., es decir, papeles que van de
un archivador a otro. Sería la representación mediante la circulación de
información del sistema físico almacén. En la Figura 2.1 podemos ver este
ejemplo del almacén visto desde el punto de vista físico y desde el punto de
vista del sistema de información.
Figura 2.1. Diferencias entre un sistema físico y un sistema de información.
Una decisión a posteriori sería la de mecanizar este sistema de información o
no. Es perfectamente posible que se dé el caso en el que la incorporación de
un ordenador no reporte ningún beneficio en cuanto a eficiencia y
rendimiento, e incluso que fuera perjudicial para una buena gestión.
Un sistema de información mecanizado (SIM) será aquel soportado por un
ordenador. Si nos circunscribimos a este supuesto, podemos particularizar los
componentes básicos de un sistema de información:
- contenido: los datos y su descripción.
- equipo físico: el ordenador soporte de la información.
- equipo lógico: sistema de gestión de bases de datos, sistema de
comunicaciones, etc.
- administrador: la persona o equipo de personas responsables de
asegurar la calidad y disponibilidad de los datos.
- usuarios.
Resumiendo, los SIM están compuestos de máquinas, programas que se
ejecutan en esas máquinas, un responsable o responsables de su buen
funcionamiento experto en temas de análisis, diseño e implementación de
sistemas informáticos y, por supuesto, los usuarios finales que son los que
indican cuales son las necesidades de la organización.
Los sistemas de información soportados por un ordenador han sufrido una
rápida evolución. Desde el punto de vista de su funcionalidad podemos hacer
una somera distinción de estos:
- SIM de procesos de transacción.
- SIM de ayuda a la toma de decisiones.
ALMACÉN
INVENTARIO
sistema físico
bienes bienes
Pedido
Albarán
Nota de Envío
Orden de Venta
sistema de información

BD1 2006-2007
18
Los primeros tienen como objetivo el tratamiento de los datos necesarios para
llevar a cabo las tareas rutinarias de la organización: nóminas, contabilidad,
etc.; eran sistemas de información para la gestión.
Pero el desarrollo técnico en el campo de los ordenadores ha permitido exigir
cada vez más prestaciones a los sistemas de información, que pasan a
proporcionar una información más elaborada de ayuda a la toma de
decisiones: son los sistemas de información para la ayuda a la toma de
decisiones. Pensemos en una sistema de información de diseño asistido por
ordenador (CAD); la máquina será la encargada de simular el comportamiento
de un determinado objeto (el diseño de un avión, por ejemplo) en distintas
condiciones ambientales, información ésta que nos dará una base para
decidir si es factible su fabricación o si, por el contrario, no debemos seguir
adelante con el proyecto. Los almacenes de datos (más conocidos como Data
Warehouses y las aplicaciones OLAP constituyen hoy en día el núcleo de
estos sistemas de apoyo a la toma de decisiones). Estos sistemas son la
parte central de la asignatura optativa Bases de Datos Multidimensionales.
II1.1. Desarrollo de un sistema de información
mecanizado.
Para construir un sistema de información se parte de una definición de los
posibles usuarios, sus necesidades y las fuentes de información, pasando a
dar respuesta a un conjunto de temas entre los que destacan los relativos a la
organización de los datos, que determinan en gran medida el rendimiento,
flexibilidad y fiabilidad de todo el sistema. Así, cualquier sistema de
información pretende, por medio de una abstracción del mundo real,
representar con un conjunto de datos estructurado toda la información
necesaria para el cumplimiento de los objetivos de una organización, para lo
que se deben seguir distintas fases apoyadas en métodos y reglas.
En primer lugar, habrá que aislar la parcela del mundo real objeto de estudio,
identificando objetos con sus propiedades, las relaciones entre ellos, así
como su semántica asociada.
A continuación y por medio de un proceso de abstracción, intentaremos
obtener una imagen (representación) de esta parcela del mundo real. Es lo
que se llama modelado, proponer un esquema bajo un determinado sistema
de representación que simule el comportamiento de la parte de la realidad en
estudio. Obtendremos así las estructuras que alberguen nuestros datos y los
procesos (operaciones) que las han de afectar para obtener la información
elaborada final.
Por último, habrá que organizar el conjunto de información definido en la
etapa anterior para almacenarla en un soporte informático, lo que exige el
conocimiento de técnicas cada vez más sofisticadas entre las que se
encuentran las técnicas de bases de datos.
En definitiva, siguiendo el ciclo de vida clásico del software podemos
diferenciar tres fases a la hora de desarrollar un sistema de información, en
nuestro caso mecanizado, a saber:
- Análisis: investigación y modelado
- Diseño: lógico y físico
- Implementación: programas, carga de datos, pruebas.

modelos de datos
19
En la fase de análisis se realizan labores de recogida de requerimientos, y se
obtiene un modelo no influido por un sistema mecanizado concreto (modelo
conceptual), que representa, lo más fielmente posible, el conjunto de datos en
estudio y las interrelaciones que hubiere entre ellos, así como los procesos
que los afectan. En definitiva vamos a describir, mediante un formalismo
adecuado, nuestro sistema físico.
En la etapa de diseño trasladamos las ideas obtenidas en la fase anterior a un
modelo comprensible por el ordenador, el diseño lógico y el físico, que
representan sucesivos acercamientos al nivel más bajo de detalles de
almacenamiento.
Con la implementación introducimos en la máquina el resultado del diseño y
los datos necesarios para la inmediata explotación de los mismos, tras las
correspondientes pruebas de fiabilidad y rendimiento. En la Figura 2.2.
podemos ver un resumen del proceso de diseño de una base de datos desde
el punto de vista del ciclo de vida de evolución del software.
Figura 2.2. Diseño de una base de datos desde el punto de vista del ciclo de
vida de evolución del software
II2. Conceptos y definiciones
Propiedades de un sistema de información
En un sistema de información encontraremos propiedades estáticas,
dinámicas y restricciones de integridad.
Las propiedades estáticas se refieren a los datos en si, qué información
es la que se maneja en el sistema, qué valores puede contener el
sistema, y cómo dependen unos de otros. Son propiedades que no
varían en el tiempo.
Las dinámicas hacen referencia a la evolución de esos datos en el
tiempo, a las operaciones que se les aplican, más concretamente
transacciones (secuencias indivisibles de operaciones simples).
Las restricciones de integridad son reglas utilizadas para definir las
propiedades estáticas y dinámicas. Dicho de otro modo, es el
mecanismo por el que establecemos cuales son los valores válidos de
los objetos de nuestro sistema en cada instante.
MUNDO
REAL modelado organización
objetos
interrelaciones
procesos
restricciones
semánticas
requerimientos
de información
requerimientos
de procesos
MUNDO DE
LAS IDEAS
MUNDO
DE LOS
DATOS
esquemas de
datos
esquemas de
transacciones
análisis diseño implementación

BD1 2006-2007
20
La mayoría de ellas se podrán expresar adecuadamente con los conceptos
que maneja el modelo de datos. Al estructurar la información de una cierta
manera y al especificar las transacciones ejecutables estamos estableciendo
ya unas reglas que cumplirá el sistema. No obstante, hay propiedades
imposibles de expresar con los mecanismos anteriores que necesitan una
definición adicional mediante un formalismo de especificación de aserciones.
De una forma hasta cierto punto coloquial, habitualmente se habla de
restricciones de integridad refiriéndose únicamente a las segundas, ya que las
primeras no necesitan de esa especificación aparte.
Resumiendo, en el proceso de análisis y diseño de un sistema de información
obtendremos finalmente un conjunto estructurado de datos, un conjunto de
operaciones a realizar sobre ellos, y una serie de afirmaciones adicionales
sobre las combinaciones de valores que son posibles dentro de nuestro
sistema. Para reflejar todo ello necesitamos un formalismo, un “lenguaje” que
nos permita estructurar esa información y definir esas operaciones para
satisfacer las demandas de los usuarios finales. Este formalismo es el modelo
de datos.
Figura 2.3. Ejemplo del proceso de diseño de una base de datos
Modelo de datos
Definimos un modelo de datos como la herramienta intelectual que nos
permite estructurar los datos de forma que se capte la semántica de los
mismos. Éste nos ofrecerá un conjunto de conceptos y reglas que nos
permitirán representar, con mayor o menor fidelidad, un conjunto de datos
interrelacionados y operaciones sobre los mismos, a los que afectan unas
restricciones que han de cumplir en todo momento. Cuanta más información
sobre los datos podamos representar dentro del mismo, más expresivo será
el modelo de datos (y por la tanto más deseable).
Esquema
La aplicación de un cierto modelo de datos a una realidad nos dará como
resultado un esquema, una representación de esa realidad que podrá ser de
tipo gráfico o lingüístico y que describirá un conjunto de objetos e
interrelaciones entre ellos, un conjunto de operaciones (combinaciones de
S.I
.
• propiedades estáticas
• propiedades dinámicas
• restricciones de integridad
MD
conceptos + reglas de
composición
LDD
• clases de objetos
• operadores
• mecanismos de
representación de
R.I.
ESQUEMA
SGBD
BD
• descripción
• estado actual del S.I.
• ocurrencia del esquema
• estado de la base de datos
abstracción
datos
transacciones
• soporte del modelo

modelos de datos
21
insertar, borrar, modificar y consultar) a aplicar sobre los primeros, y todas las
restricciones semánticas que afecten al sistema.
Lenguajes de definición y manipulación de datos
Para aplicar un modelo de datos deberíamos disponer de un lenguaje de
definición de datos (LDD) y de un lenguaje de manipulación de datos (LMD).
Con el LDD describiríamos las estructuras en las que se almacenarían los
datos, y con el LMD las transacciones a efectuar para obtener información
elaborada a partir de esos datos. Podemos decir, pues, que un modelo de
datos se compone de dos partes estrechamente relacionadas: las
estructuras de datos4
, que representan las propiedades estáticas del
modelo, y la especificación de transacciones, que hace lo propio con las
dinámicas.
No todos los modelos tienen en cuenta los dos tipos de propiedades,
centrándose bien en uno o en otro. De hecho, los más implantados de forma
comercial se basan casi exclusivamente en la parte estática, seguramente por
ser la menos costosa de solucionar.
¿Quién es el encargado de proporcionar los lenguajes antes mencionados y
de gestionar los datos estructurados en función de un determinado modelo de
datos? El sistema de gestión de bases de datos es la herramienta software
que soporte a un modelo de datos o, dicho de otro modo, todo SGBD debe
tener un modelo de datos subyacente que permita describir los datos de una
forma concreta.
Disponemos, pues, de un conjunto de reglas, aplicables mediante el LDD,
para la generación de esquemas. El esquema de una base de datos,
resultado de la utilización del LDD, es la definición de las estructuras de
acuerdo a cada modelo. Se usa para representar las propiedades estáticas
según el modelo que se utilice. En algunos modelos se distinguen dos
subconjuntos de este conjunto de reglas: uno para la definición de estructuras
en sí, y otro para la definición de restricciones de integridad estáticas.
Los LMD pueden ser navegacionales o de especificación. Los primeros se
basan en la utilización interna de punteros, por lo que los operadores
seleccionan un único objeto por la posición lógica que ocupa, es decir, se
recupera la información partiendo del valor actual del puntero (del objeto al
que está apuntando). En otras palabras, debemos recorrer la estructura
desde el lugar en el que nos encontremos hasta llegar a la información que
precisamos.
Los LMD de especificación, sin embargo, recuperan los datos en función de
qué es lo que estamos buscando, indicando explícitamente qué datos
precisamos y qué condiciones han de cumplir, pero dejando al SGBD la tarea
de cómo obtiene esa información.
Sistema de Gestión de Bases de Datos
Un Sistema de Gestión de Bases de Datos (SGBD) es el software que
implementa las herramientas asociadas a un modelo de datos.
Estados de la BD
Diremos que para un esquema de BD existen muchas ocurrencias de base
de datos, cada una de las cuales tiene las mismas estructuras y obedece a
las mismas restricciones de integridad. La estructura de la base de datos es
siempre la misma o sufre alteraciones cada bastante tiempo pero las
operaciones de manipulación de datos son constantes y, por tanto, los datos
4 En un sentido amplio; piénsese que en el análisis y diseño orientados a objeto no se habla de
estructuras sino de objetos.

BD1 2006-2007
22
contenidos en la base de datos cambian continuamente. Tradicionalmente,
los términos ocurrencia del esquema y base de datos se suelen utilizar
indistintamente.
Un estado de la base de datos está definido en un instante de tiempo por la
descripción de la misma y la información almacenada; generalmente se
entiende que el resultado de una transacción o una simple operación atómica
(insertar, borrar, ...) generan un nuevo estado de la BD (se ha modificado, de
alguna forma, la BD con respecto al estado inmediatamente anterior).
Evidentemente, las operaciones que provocan la transición de un estado de
BD a otro nunca varían la estructura de la BD (el esquema).
II3. Representación de un sistema de
información
Resumiendo de forma intuitiva todo lo expuesto en las secciones anteriores,
todo modelo de datos utiliza los siguientes mecanismos de abstracción para
la construcción de las clases de objetos apropiadas:
− Clasificación: definir un concepto como una clase de objetos
− Agregación: definir una nueva clase de objetos a partir de otras clases
− Generalización: definir subtipos de una clase
Igualmente, para expresar las restricciones aplicables a las clases de objetos
en particular, y al sistema en general, sean de tipo estático o dinámico se
utilizan las:
− restricciones de dominio: definen el conjunto de valores (escalares o
complejos) agrupados en una clase de objetos.
− restricciones de identificación: no hay dos objetos dentro de una clase de
objetos iguales.
− restricciones de correspondencia entre clases: restricciones de
cardinalidad, de dependencia de identificador, de existencia y de cobertura
de las generalizaciones.
Características dinámicas del sistema del información: restricciones
dinámicas.
La parte dinámica de un sistema hace referencia a la variación del contenido
del sistema de información (o incluso su evolución como esquema) a través
del tiempo. Visto de una forma simplista, su comportamiento frente a
inserciones, borrados, modificaciones y consultas de los datos en él
almacenados.
Tal y como estudiaremos en el tema 3 dedicado al modelo relacional, éste es
en concreto, un modelo que como todos los denominados clásicos y algunos
de los semánticos, únicamente es capaz de representar la parte estática de
un sistema de información. Posteriores extensiones o nuevos modelos de
datos más potentes han incorporado herramientas para representar el

modelos de datos
23
comportamiento en el tiempo de los datos, esto es, las restricciones
dinámicas del sistema.
Es evidente que siendo un tema importante este último, tradicionalmente se
ha dejado de lado por su dificultad de definición e implementación, y no va a
ser tratado en más profundidad en esta asignatura.
II4. Cualidades de los modelos de
datos
A la hora de evaluar un modelo de datos debemos fijarnos en los siguientes
puntos:
• Expresividad: cuantos más mecanismos o conceptos de
representación tenga un modelo mayor será la cantidad de propiedades
del sistema de información que pueda captar, y menor el uso de
aserciones en forma de restricciones de integridad que no se pueden
reflejar directamente sobre el esquema.
• Simplicidad: también es deseable que el modelo sea simple para que
los esquemas sean fáciles de entender por terceras personas. Debe
llegarse, pues, a un equilibrio entre la potencia del modelo mencionada
en el punto anterior y esa simplicidad deseable.
• Minimalidad: cada concepto tiene un significado distinto de los demás
conceptos utilizados en el modelo de datos; no se puede expresar un
concepto en función de otros.
• Formalidad: todos los conceptos del modelo tienen una interpretación
única, precisa y bien definida. Puesto que el esquema pretende ser una
especificación formal del sistema de información a representar, esta
cualidad permitiría el tratamiento matemático de sus conceptos.
Si el modelo utiliza un lenguaje de definición gráfico, también tendremos en
cuenta:
• Compleción gráfica: un modelo es gráficamente completo si todos sus
conceptos poseen representación gráfica.
• Facilidad de lectura: que los símbolos gráficos sean fácilmente
distinguibles unos de otros.
II5. Clasificación de modelos de datos
A medida que han ido evolucionando el software y el hardware, las
posibilidades y las demandas de los usuarios han ido creciendo;
paralelamente, los modelos de datos fueron enriqueciéndose y salvando
carencias de sus predecesores. Cronológicamente, podemos clasificarlos de
la siguiente forma:
- Primitivos: basados en sistemas de ficheros convencionales
- Clásicos

BD1 2006-2007
24
- Jerárquico (el más conocido, IMS: IBM)
- Red (CODASYL)
- Relacional (desarrollado por E. Codd)
- Semánticos5
- EER (Entidad-Relación Extendido: Chen)
- RM/T (Relational Model/Tasmania: Codd)
- Semántico General
- Orientado a Objetos
- Modelo Funcional
Se dice que tanto primitivos como clásicos están basados en registros,
mientras que los semánticos se apoyan en la filosofía Orientada a Objetos.
Los modelos de datos primitivos se usaron durante la década de los 70,
cuando aun no se utilizaban las técnicas de bases de datos. Los objetos se
representaban como registros organizados en ficheros, y las relaciones
mediante referencias explícitas a otros registros en algún campo del mismo.
Los lenguajes de manipulación dependen por entero de la organización física
de los datos, y las operaciones básicas son la lectura y la escritura.
Para garantizar, o al menos mejorar, la independencia de los aplicaciones
frente a los datos aparecen los primeros SGBD, basados en lo que ahora
llamamos modelos de datos clásicos. Los primeros en aparecer fueron el
jerárquico y el red de CODASYL, cuyos nombres muestran cual es la
estructura de datos subyacente en los modelos. Los objetos siguen siendo
representados por registros pero las relaciones entre objetos se expresan,
con ciertas limitaciones implícitas del modelo, mediante la estructura en que
se basan. Los lenguajes de manipulación de datos son navegacionales.
Sin embargo, y dentro todavía de esta generación, la aparición del Modelo
Relacional provocó la representación de los objetos como relaciones (tablas
en su denominación informal), cuyas tuplas (filas en su denominación
informal) identifican a ocurrencias del objeto patrón, y la vuelta a las
referencias explícitas (unos atributos que relacionan un objeto con un
segundo por comparación de valores iguales en uno y otro) para expresar las
interrelaciones. La estructura de datos más simple y la aparición de lenguajes
de especificación totalmente declarativos ha hecho de este modelo el más
ampliamente utilizado en los SGBD comerciales actuales.
Uno de los grandes problemas que plantean los SGBD comerciales actuales,
en general, es que no soportan modelos con la suficiente expresividad como
para dejar libre al diseñador de sistemas de información de molestas tareas
de administración de datos a bajo nivel. Es práctica habitual utilizar en la
confección del EC modelos de datos con un fuerte potencial semántico para
traducirlo después a modelos que si tienen un software comercial disponible,
pero muy probablemente más pobres semánticamente.
Por eso, la aparición de los modelos de datos semánticos está justificada por
la pretensión de aumentar la capacidad expresiva de los modelos clásicos
incorporando conceptos y mecanismos de abstracción no contemplados en
los anteriores. Se utilizan preferentemente para la confección del Esquema
Conceptual, y como modelo subyacente de algunos SGBD aun en
experimentación. Son los más potentes pero no tienen un reflejo comercial en
algún producto de amplia difusión; la representación del EC ha de traducirse a
5 El modelo EER será estudiado en profundidad en la asignatura Bases de Datos II, mientras
que el resto de los modelos semánticos son objeto de estudio en la asignatura Bases de Datos
Avanzadas.

modelos de datos
25
un Esquema Lógico, en general a un modelo clásico, para poder ser
explotado eficientemente en algún SGBD.
Así y todo, parece que el EER está teniendo alguna penetración sobre todo
en herramientas de análisis y diseño de Sistemas de Información, en forma de
módulo de ciertas herramientas CASE que se puede traducir de forma
automática al Modelo Relacional.
Otros modelos de datos, que denominaremos de propósito particular, se
desarrollaron sobre aplicaciones concretas: cartografía, CAD/CAM, hipertexto,
etc.
BIBLIOGRAFÍA
[DATE01]. Capítulos 1 y 2.
[ELMASRI02]. Capítulo 1.
[SILBERSCHATZ02]. Capítulo 1 y apéndices A (Modelo de Red) y B
(Modelo Jerárquico).
[MOTA02]. Capítulo 2.

27
III EL MODELO RELACIONAL
La teoría del Modelo Relacional se desarrolló hacia el 1970
de la mano de E. Codd, que propuso también tres lenguajes
de definición y manipulación de datos basados en el
Álgebra de conjuntos y el Cálculo de Predicados de Primer
Orden. Desde entonces, el Modelo Relacional se ha
impuesto claramente sobre sus inmediatos predecesores, el
Jerárquico y el Red, por su sencillez y por la aparición de un
lenguaje de especificación, el SQL (Standard Query
Language), de fuerte aceptación como lenguaje de
explotación.
Veremos a continuación las estructuras que definen el
modelo, los operadores asociados y los mecanismos para
representar restricciones de integridad.

29
III1. introducción intuitiva
Se puede decir que empezamos a hablar de tecnologías de bases de
datos propiamente dichas con la aparición del modelo relacional. De
hecho, el modelo jerárquico y el modelo en red, los otros clasificados
dentro del grupo de los modelos clásicos, no eran considerados como
tales sino que la aparición del relacional forzó la formalización de esos
dos sistemas de gestión de ficheros.
Sin duda es el modelo de datos de más éxito entre los SGBD
comerciales. Su difusión se basa en la sencillez en la representación de
los datos y en la aparición de un lenguaje de manipulación de datos
que es considerado como estándar y cada vez más utilizado.
Los modelos clásicos, el relacional entre ellos, se considera que están
orientados a registro (mientras que los semánticos se dice que están
orientados al objeto). No obstante, de cara al usuario, el modelo
relacional no presenta la información en registros sino como tablas. La
tabla presenta la información referente a un concepto en forma de filas,
y las columnas representan una cierta característica o propiedad del
concepto; los nombres descriptivos de dichas propiedades están en la
cabecera de la tabla.
tabla ALUMNO
exp dni nombre titulación curso grupo
1 21 PEPE ITIG 2 A
3 52 LUISA ITIS 2 C
2 23 ANA ITIG 2 A
No existe otra forma de representar la información: la única estructura
que ofrece el modelo para captar cualquier realidad es la tabla. La
información siempre se almacena en forma de valores explícitos, es
decir, no existen punteros o mecanismos similares que relacionen la
información sino que valores iguales en dos columnas de diferentes
tablas indican una posible relación.
Además, los lenguajes de manipulación de datos no son
navegacionales, no implican procesos de recuperación secuencial de
registros, sino que, simplemente, el usuario le dice al sistema que
condiciones ha de cumplir la información resultante. Ese resultado
también se presenta en forma de tabla, o lo que es lo mismo, el
lenguaje es cerrado ya que operandos y resultado son del mismo tipo
conjunto.
El estándar actual, el SQL, sufre pocas variaciones de una marca a otra
de SGBD y ha contribuido también a la alta aceptación del modelo.

BD1 2006-2007
30
III2. concepto de relación
La teoría del Modelo Relacional se basa en el concepto matemático de
relación, formalismo en el que se apoya la tabla6
. Definiremos los
conceptos necesarios hasta llegar al de Relación Matemática: dominio
y producto cartesiano. La relación nos permitirá representar objetos y
restricciones semánticas, y los operadores utilizarán relaciones como
operandos y darán como resultado nuevas relaciones.
dominio
Un dominio es un conjunto de valores escalares, en el sentido de que
son las unidades semánticas de datos más pequeñas, son valores
simples que no tienen una estructura interna.
En realidad, hablar de dominios es hablar de tipos de datos sobre los
que toman valores los objetos del sistema de información, y es un
concepto clave a la hora de poder establecer criterios de ordenación o,
simplemente, comparar dos objetos.
Por otro lado, es evidente que si definimos un dominio y una cierta
clase de objetos sobre él, estamos describiendo directamente algunas
de las restricciones semánticas del sistema de información, en concreto
las que limitan los valores que puede tomar un objeto.
producto cartesiano
Dada una colección de conjuntos D1, D2, ..., Dn , no necesariamente
disjuntos, el producto cartesiano de los n conjuntos D1 × D2 × ...× Dn es
el conjunto de todas las posibles n-tuplas < d1, d2, ..., dn > tales que la
componente i-ésima de la misma pertenece al i-ésimo conjunto.
D1 × D2 × ...× Dn = { < d1, d2, ..., dn > /
d1 ∈ D1, d2 ∈ D2, ..., dn ∈ Dn }
relación matemática
R es una Relación Matemática definida sobre los dominios
D1, D2, ..., Dn si es un subconjunto del producto cartesiano
D1 × D2 × ...× Dn .
R ⊆ D1 × D2 × ...× Dn
6
Desde un punto de vista formal, el termino correcto sería relación, sin embargo se
utilizan indistintamente los términos tabla y relación.

modelo relacional
31
grado de una relación matemática
A los conjuntos Di se les denomina dominios. El número de dominios
sobre el que está definida una Relación Matemática recibe el nombre
de grado de la relación.
Grado(R) = n.
cardinalidad de una relación matemática
Asimismo, se denomina cardinalidad de la relación al número de n-
tuplas que contiene R. Resulta evidente que mientras el grado es
constante, la cardinalidad de una relación varía en el tiempo (a medida
que se incluyen o eliminan tuplas de la relación).
De la definición de Relación Matemática podemos deducir las
siguientes conclusiones:
1. En una Relación Matemática, por ser un conjunto, no hay tuplas
duplicadas. Es evidente que el producto cartesiano de los
dominios no produce la misma tupla dos veces, y la relación es
un subconjunto de ese producto cartesiano.
2. Las tuplas, por la misma razón, no están ordenadas entre sí.
3. La tupla es un conjunto ordenado de valores (lista de valores) de
forma que el i-ésimo valor siempre pertenece al i-ésimo dominio.
Supongamos una relación que agrupe a los ALUMNOS DE
INFORMÁTICA, de los que se conoce información tal como el número
de expediente, nombre, titulación, curso y grupo, que toman valores,
respectivamente, en los siguientes dominios:
número de expediente ∈ domExp = { 1.. 3000 }
dni ∈ domDni = { c / c es cadena(8) }
nombre ∈ domNom = { c / c es una cadena(30) }
titulación ∈ domTit = { ‘II’, ‘ITIG’, ‘ITIS’ }
curso ∈ domCur = { 1, 2, 3, 4, 5 }
grupo ∈ domGrp = { ‘A’ .. ‘Z’ }
La relación matemática ALUMNO sería un conjunto de tuplas cuya
primera componente pertenecería al primer dominio, domExp, la
segunda al segundo dominio, etc.:
ALUMNO ⊆ domExp × domDni × domNom × domTit × domCur ×
domGrp
El grado de la relación es 6, y un posible subconjunto de tuplas del
producto cartesiano antes definido podría ser el mostrado a
continuación, de cardinalidad 3.

BD1 2006-2007
32
III3. representación de objetos
Una base de datos representa objetos y conceptos de la vida real. Hay
procesos previos a la introducción de datos en el ordenador que
implican la identificación de tales objetos y su diseño para aplicarlos a
un sistema informático concreto.
Podemos decir que, tras una fase de investigación en la que se
detectan las necesidades de información de una determinada
organización o sistema, la información se estructura en clases de
objetos que pretenden representar esa realidad particular.
En este punto veremos en primer lugar, de forma general, cuáles son
los mecanismos a través de los cuales se llega a esa estructuración
concreta de los datos. Posteriormente, ya dentro del modelo relacional,
se detallarán las herramientas y conceptos del mismo que ayudan a
esa representación.
Es importante destacar que los conceptos que se desarrollan en este
punto no son exclusivos del modelo relacional sino que, por necesidad
de justificación del porqué se definen las tablas como se definen, se
exponen ahora.
Como recordaremos en el tema de modelos de datos, estos conceptos
son generales y aplicables a cualquier modelo de datos, sean cuales
sean sus herramientas de representación.
III3.1.mecanismos de abstracción
La realidad, el sistema de información a representar, tiene demasiados
detalles como para poder tenerlos todos en cuenta. De hecho, muchos
de ellos son irrelevantes para nuestro objetivo final, que es administrar
un conjunto de datos que refleje la problemática de nuestro sistema de
datos. Se hace necesario obtener una representación que únicamente
abarque los detalles importantes para nuestros objetivos.
Los esquemas de base de datos hacen precisamente eso, resumir las
características más importantes de nuestro sistema de información y
1 PEPE ITIG 2 A
2 ANA ITIG 2 A
3 LUISA ITIS 2 C
ALUMNO
21
52
23

modelo relacional
33
hacerlas comprensibles a nuestro SGBD. Esos esquemas se apoyan
en un determinado modelo de datos.
Un modelo de datos es un conjunto de conceptos y unas reglas de
composición de esos conceptos que, combinados de alguna forma, son
capaces de representar un sistema de información, tanto en su parte
estática como dinámica.
Dicho de otra manera, un lenguaje de descripción de datos, apoyado
en un modelo de datos, nos permite definir las estructuras de datos que
van a almacenar nuestra información, las operaciones que se realizan
sobre esas estructuras y la definición de las restricciones de integridad
que determinan cuales son los valores válidos en todo momento.
Pensemos, por ejemplo, en un modelo de datos cuyas herramientas de
representación sean registros, campos de registro y algunos tipos de
datos, y que queremos representar el hecho de la matriculación de los
alumnos en ciertas asignaturas.
MODELO DE DATOS ⇒ ESQUEMA
Conceptos:
registros
campos
tipo entero
tipo carácter
operador Insertar( )
operador Borrar( )
operador Consultar( )
Reglas:
Los registros se componen
de campos.
Los campos son de un
determinado tipo.
Los operadores se aplican
a registros y devuelven
registros.
abstracción REG ALUMNO
( nombre: char(30)
dni:char(9)
dir:char(30) )
REG ASIGNATURA
( cod:char(5)
nombre:char(30)
créditosT:entero
créditosP:entero )
REG ASISTE
( asig:char(5)
alum:char(9) )
asiste.Insertar(r) = si
(alumno.Consultar(x) y
asignatura.Consultar(y))
OCURRENCIA DEL ESQUEMA
dni nombre dir
21 Pepe c/Toro, 10
22 Juan c/Moisés, 30 3 D
cod nombre créditosT créditosP
BD1 Bases de Datos 1 6 3
BD2 Bases de Datos 2 3 3
asig alum
BD1 21
BD2 21
BD1 22
Así, la primera tarea a realizar es seleccionar el conjunto de
características representativas del sistema y excluir lo irrelevante. En
este proceso de abstracción identificaremos los objetos importantes,
las relaciones que se dan entre ellos, las operaciones a realizar, y los

BD1 2006-2007
34
límites de comportamiento que afectan a todos, tanto datos como
operaciones (restricciones semánticas o de integridad).
Al modelar una determinada situación estamos aplicando los siguientes
mecanismos de abstracción:
- Clasificación: definir un concepto como una clase de objetos
- Agregación: definir una nueva clase de objetos a partir de otras
clases
- Generalización: definir subtipos de una clase
clasificación.
Entendemos por clasificación como la definición de un concepto como
una clase de objetos.
Si observamos los objetos enero, febrero, marzo, ..., y diciembre,
podemos establecer una clase de objetos que represente al concepto
MES, que será, por decirlo de otra manera, un conjunto de objetos (los
meses en sí) agrupados bajo un mismo epígrafe.
Los nombres de persona se pueden clasificar como una clase de
objetos que los defina:
NOMBRE = { Alfredo, Antonio, Antonia, Armando, … }
o, de forma más general:
NOMBRE = { s / s es una cadena de caracteres de longitud variable
}
También, para el D.N.I.:
DNI = { s / s es una cadena de 8 dígitos }
Resumiendo, la clasificación tipifica en una clase de objetos un
conjunto de objetos reales o, desde otro punto de vista, dichos objetos
son miembros_de una clase de objetos
agregación
La definición de una clase de objetos a partir de otras ya definidas se
conoce como agregación. Por ejemplo, la clase PROFESOR se define
a partir de la agregación de los objetos dni, nombre, y dirección.

modelo relacional
35
Definimos la clase de objetos como una agregación de sus partes
componentes, (dni es_parte_de profesor). Un ejemplo un poco más
complejo de agregación sería el siguiente, que define una clase
IMPARTE, en función de las clases profesor y asignatura.
Por otro lado, una misma clase de objetos puede participar en más de
una agregación.
generalización
Este mecanismo nos sirve para definir subtipos de una clase de
objetos. Pensemos en COCHES y MOTOS: todos ellos son
VEHÍCULOS, pero aunque la agregación de matrícula es común a
todos ellos, sólo podemos hablar de número de puertas en los coches,
mientras que el tipo de refrigeración del motor es una propiedad
relevante únicamente en las motocicletas.
Un objeto generalizado es un objeto definido a partir de dos o más
objetos especializados con propiedades comunes. Las propiedades del
objeto generalizado serán las comunes a todos los especializados,
profesor
dni nombre dirección
profesor
asignatura
código descripción créditos
imparte
profesor
asignatura
imparte
coordinador
alumno

BD1 2006-2007
36
mientras que estos últimos, además, aportan las suyas que no se
pueden aplicar al resto de objetos dentro de la generalización.
Decimos que un objeto especializado es_un objeto generalizado (un
coche es un vehículo).
III3.2.restricciones semánticas
Las restricciones de integridad hacen referencia a todas aquellas
reglas o normas que delimitan los valores que pueden tomar las
ocurrencias del esquema, y que modifican, en un sentido amplio, el
significado de los conceptos en él recogidos. Estas restricciones
pueden reflejarse simplemente mediante la utilización de los
mecanismos de abstracción antes mencionados, o como añadidos no
soportados por tales representaciones (los nacidos en Alicante tienen
un descuento del 10% en su declaración de renta). Afectan tanto a las
propiedades estáticas del sistema de información como a las dinámicas
(las operaciones).
Veremos qué tipo de restricciones semánticas se aplican a cada uno de
los conceptos que aparecen en un modelo de datos:
- restricciones de dominio
- restricciones de identificación
- restricciones de correspondencia entre clases
restricciones de dominio.
Al definir una clase como una asociación de objetos estamos
determinando cuales son los valores válidos para la instanciación de
esa clase, es decir, estamos estableciendo, por definición, el dominio
sobre el que tomará valores.
restricciones de identificación.
No existen duplicados entre los posibles valores de una instanciación
de la clase de objetos (aún dos hermanos clónicos, siendo
exactamente iguales, ocupan espacios diferentes y son, a efectos de
identificación, dos personas diferentes).
VEHÍCULO
MOTOCOCHE
matrícula
puertas refrigeración

modelo relacional
37
restricciones de correspondencia entre clases.
Tanto la agregación como la generalización establecen
correspondencias entre las clases de objetos involucradas.
En la agregación IMPARTE, un profesor puede impartir varias
asignaturas y una asignatura ser impartida por varios profesores, y
podemos obligar a que todo profesor imparta al menos una asignatura.
Estamos estableciendo restricciones de cardinalidad.
Entendemos como cardinalidad mínima CardMin(o, a) como el número
de correspondencias mínimo que se establece entre el objeto o y la
agregación a. De igual forma, la cardinalidad máxima, CardMax(o, a),
es el máximo de correspondencias entre la clase de objetos o y la
agregación a.
Por abreviar, utilizaremos la notación Card(o, a) = (m, M) donde m es la
cardinalidad mínima y M la máxima.
Siguiendo el mismo ejemplo las cardinalidades serían:
Card(profesor, imparte) = (1, n)
Card(asignatura, imparte) = (0, n)
Aunque los valores típicos para la mínima son 0 y 1 y para la máxima 1
y n (n indicaría que no existe límite) se admiten otros valores si así lo
requiere el sistema de información a representar. Serían del tipo que un
profesor ha de impartir al menos 3 asignaturas y/o que el máximo de
asignaturas que puede impartir son 5.
En las cardinalidades indicadas arriba estamos representando la
obligatoriedad para todo profesor de impartir al menos una asignatura,
mientras que una asignatura pudiera no tener profesor que la
impartiera. Si nos fijamos en los límites máximos, ninguno de los
objetos de la agregación tiene restricción alguna.
En esta agregación, la definición de la clase de objetos agregada se
apoya en otras dos clases ya definidas. Sería el caso de una
agregación binaria; en general, hablamos de agregación n-aria cuando
el número de clases participantes es n.
Sea la agregación siguiente, que representa que la correspondencia
entre profesor, asignaturas que imparte y aula donde las imparte, así
como las restricciones de cardinalidad que se especifican para tal
agregación.
Card(profesor, imparte) = (1, n)
Card(asignatura, imparte) = (0, n)
Card(aula, imparte) = (0, n)
En este caso, la semántica asociada a la agregación indica que un
profesor imparte una asignatura en un aula determinada, con la única
profesor asignaturaaula
imparte

BD1 2006-2007
38
restricción de que todo profesor ha de estar asignado a un aula y una
asignatura al menos.
Las restricciones de integridad que se refieren a las correspondencias
entre clases que se producen por la generalización se conocen como
propiedades de cobertura de la generalización.
Si dividimos a las personas entre varones y hembras todas ellas serán
o varón o hembra pero no las dos cosas a la vez.
Por contra, de todas las asignaturas obligatorias de Informática, unas
son compartidas por dos o más titulaciones (ITIG, ITIS, o II), y toda
asignatura obligatoria pertenece a alguna titulación.
Si generalizamos a los pintores y escultores como ARTISTA (un pintor
o un escultor es un artista), no todos los artistas son de las dos artes
mencionadas, pero un pintor puede ser al mismo tiempo escultor.
Resumiendo, la generalización puede ser total o parcial, y disjunta o
solapada:
total: si toda ocurrencia del objeto generalizado se corresponde con
una de al menos uno de los objetos especializados.
parcial: si alguna ocurrencia del objeto generalizado no tiene su
correspondiente ocurrencia en uno de los objetos especializados.
disjunta: si una ocurrencia del objeto generalizado se corresponde,
como máximo, con una y sólo una ocurrencia de uno de los
objetos especializados.
solapada: si una ocurrencia del objeto generalizado se corresponde
con ocurrencias de objetos especializados distintos.
Las generalizaciones mencionadas tienen las siguientes propiedades
de cobertura:
- PERSONA: total y disjunta.
- ASIGNATURA OBLIGATORIA DE INFORMÁTICA: total y
solapada.
- ARTISTA: parcial y solapada.
armando
eva
rafa
fbd
dgbd
pc
p15
c01
e02
p25

modelo relacional
39
III3.3.adaptación del concepto de relación
matemática al modelo relacional.
La relación es la estructura básica que proporciona el modelo relacional
para representar una determinada realidad. Es el medio por el que
podemos hacer referencia en una BD relacional a personas, cosas o
interrelaciones entre esos objetos o individuos.
No obstante, necesitamos adaptar el concepto matemático antes
expuesto para la “tarea” que va a realizar como estructura del modelo
relacional. Veamos cuáles son esas adaptaciones y como representar
con él los objetos y relaciones entre objetos de nuestro sistema de
información.
En primer lugar, recalcar el hecho de que la única referencia a una
componente de una tupla, en una relación matemática, es su posición
relativa dentro de ella. En otras palabras, la única información sobre la
“forma” que tiene la relación son los dominios de los que se extraen los
valores y el orden que ocupan en el producto cartesiano.
En el contexto del Modelo Relacional, pretendemos evitar tratar así las
tuplas de la relación, como listas de valores donde cada componente
se referencia por la posición que ocupa. Modificaremos, pues, la
definición que se ha dado de Relación Matemática.
Una relación sobre los dominios D1, D2, ..., Dn (no
necesariamente disjuntos) consta de una intensión y una
extensión.
• Intensión: un conjunto de nombres de atributos distintos
A1, A2, ..., An, cada uno de ellos asociado a su dominio
correspondiente. También recibe el nombre de esquema o
cabecera de la relación. Consta del nombre de la relación y de
los nombres de los atributos y los dominios asociados, en forma
de pares < nombreDeAtributo : Dominio >. Por ejemplo:
ALUMNO = { <exp : domExp>, <nombre : domNom>, <titulación : domTit>,
<curso : domCur>, <grupo : domGrp> }7
• Extensión: un conjunto de n-tuplas donde cada tupla es un
conjunto de pares (nombreDeAtributon: Valor), siendo n el
grado de la relación, uno por cada atributo del conjunto anterior,
donde Valor siempre es un valor del dominio asociado a
nombreDeAtributo. Se le conoce también como cuerpo de la
relación.
T = {
{<exp: 3>,<nombre: LUISA>,<titulación: ITIS>,<curso: 2>,
<grupo: C>}
{<nombre: PEPE>, <grupo: A>, <titulación: ITIG>, <exp: 1>,
<curso: 2>}
{<exp: 2>, <titulación: ITIG>, <curso: 2>, <grupo: A>, <nombre:
ANA>}
7
Aunque ésta es la notación formal, para abreviar, en adelante utilizaremos la forma
ALUMNO( exp: domExp, nombre : domNom, titulación : domTit, curso : domCur,
grupo : domGrp )

BD1 2006-2007
40
}
( T es la extensión de ALUMNO )
En la definición del punto anterior, la relación matemática era
simplemente un conjunto de tuplas, donde cada valor se movía en el
dominio que le correspondía por la posición que ocupaba en la tupla.
Ahora una relación matemática consta de dos conjuntos, el de nombres
de atributo y el de tuplas de valores.
Fijémonos que ahora no existe un orden entre los componentes de una
tupla, puesto que siempre sabemos qué dominio, por ser el asociado al
nombre de atributo, es el conjunto al que pertenece ese valor.
Disponemos, pues, de dos formas de describir una Relación
Matemática (según la nueva definición del concepto): por intensión o
por extensión.
- - por intensión: R { (A1 : D1), (A2 : D2), ..., (An : Dn) }.
- - por extensión: {{(A1 : vi1), (A2 : vi2), ..., (An : vin)}} i=1, 2, ..., m.
- ( Grado(R) = n; Cardinalidad(R) = m )
Así definida la relación, los componentes de una tupla se referencian
por el nombre del atributo, no por su posición relativa dentro de ella; no
existe, pues, un orden dentro de cada tupla para sus componentes.
III3.4.percepción de la relación: la tabla
Una vez familiarizados con el concepto matemático necesitamos
trasladar el concepto a un medio “físico” con el que podamos trabajar,
ya sea en papel o en el ordenador, debemos representar la relación de
alguna manera. La representación de la idea abstracta de relación
sobre un SGBD relacional es la tabla.
La tabla se asemeja a una matriz donde la fila representa una tupla de
la relación matemática, y la columna los valores de las componente de
cada tupla asociados al dominio correspondiente.
exp nombre titulación curso grupo
1 PEPE ITIG 2 A
3 LUISA ITIS 2 C
2 ANA ITIG 2 A
Decimos que la tabla es la representación física de la relación
matemática. Sin embargo, una tabla sugiere unas características que
no tiene la relación:
- En una tabla vemos que existe un orden entre sus filas. Por tanto,
si podemos diferenciar cada tupla por el orden que ocupa dentro
de la tabla, es perfectamente posible tener dos tuplas con los
mismos valores para todos sus atributos.

modelo relacional
41
- También sugiere un orden entre las columnas: podemos referirnos
a una componente de una fila por su nombre o por la posición
dentro de ella.
No obstante, son detalles de representación que no influyen a la hora
de su tratamiento: nosotros entenderemos una tabla como una
Relación Matemática, con todas las características de la definición
antes expuesta.
Así pues, al trasladar el concepto de Relación Matemática al Modelo
Relacional, nos encontramos con que los conceptos matemáticos
tienen un equivalente informal.
Concepto formal Equivalente informal
relación tabla
atributo columna
tupla fila
grado número de columnas
cardinalidad número de filas
Por último, mencionar que si bien la percepción del usuario de la
"forma" de sus datos es la tabla, nada tiene que ver con su almacenaje
físico. La representación de los datos en los dispositivos físicos del
ordenador no es en forma de tablas sino registros estructurados de una
manera más o menos eficiente (o, en general, cualquier otro método).
La tabla es, por tanto, una abstracción de su representación física la
cual es desconocida por el usuario final.
III3.5.abstracciones.
Las clases de objetos se representan por medio de relaciones (tablas).
Veamos cuál es la mecánica de definición de esas relaciones.
El proceso de abstracción de clases de objetos utiliza tres mecanismos
concretos, tal como mencionamos anteriormente:
• clasificación: La descripción de dominios y la definición de
atributos que toman valores en esos dominios.
• agregación: La definición de relaciones.
• generalización: La definición de relaciones como subtipos de
otra relación.
Veremos, con ejemplos sencillos, como trata el modelo relacional estos
mecanismos de abstracción. Como ya hemos dicho, la clasificación
consiste en la identificación de objetos y los dominios sobre los que
trabajan.
dni ∈ domDni = { c / c es cadena(8) }
nombre ∈ domNom = { c / c es cadena(30) }
dirección ∈ domDir = { c / c es cadena(50) }

BD1 2006-2007
42
código ∈ domCod = { c / c es cadena(6) }
descripción ∈ domNom
créditos ∈ domCdt = { n / n es real y n > 0.0 }
La agregación puede verse como la composición de objetos de mayor
nivel a partir de los identificados en la clasificación.
El esquema de la base de datos (el conjunto de todos los esquemas de
relación), según las agregaciones anteriores, sería el siguiente8
:
PROFESOR ( dni:domDni, nombre:domNombre, dirección:domDir )
ASIGNATURA ( código: domCod, descripción: domNom, créditos:
domCdt )
IMPARTE ( profesor:domDni, asignatura:domCod )
La simple comparación de valores entre las relaciones nos permite
saber qué profesores imparten qué asignaturas, como se puede ver en
las extensiones de las relaciones que se muestran seguidamente.
PROFESOR
211 LUCÍA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333
ASIGNATURA
BD1 Bases de datos 1 9
BD2 Bases de datos 2 6
FP2 Fundamentos de programación 2 3
IMPARTE
profesor asignatura
211 BD1
321 BD1
211 BD2
8
Más adelante, por las restricciones de cardinalidad de correspondencia entre clases, se
justificará esta representación.
profesor
asignatura
imparte

modelo relacional
43
Sea la generalización de vehículos que se propone a continuación:
El esquema resultante sería el siguiente:
VEHÍCULO (matrícula : domMat, marca : domMarca, modelo :
domMod)
COCHE (mat : domMat, puertas : domPp)
MOTO (mat : domMat, refrigeración : domRfr)
VEHÍCULO
matrícula marca modelo
A-0000-AA Xeat Kordoba
A-1111-BB Susuki Fantom
0-0000-0 Ferrari Testarrossa
COCHE MOTO
mat puertas mat refrigeración
0-0000-0 3 A-1111-BB agua
A-0000-AA 5
Por la estructuración de las relaciones, sabemos que el vehículo con
matrícula A-0000-AA es un coche de marca Xeat y modelo Kordoba y
que tiene 5 puertas. El vehículo A-1111-BB es una moto Susuki Fantom
refrigerada por agua.
Los atributos comunes a todos los tipos se mantienen en la relación
vehículo, mientras que el número de puertas únicamente es aplicable a
los coches, como el tipo de refrigeración sólo lo es para las motos.
Más adelante veremos como se completan los esquemas de relación
para dotarles de una semántica adecuada y preservar la integridad de
los datos.
III4. restricciones semánticas
Con lo visto hasta ahora no somos capaces de representar fielmente
todas las características del sistema de información a mecanizar, ni
VEHÍCULO
MOTOCOCHE
matrícula
puertas refrigeración
marca
modelo

BD1 2006-2007
44
hemos conseguido que la tabla se comporte como una relación: ¿cómo
evitamos la duplicación de tuplas en las relaciones?
Otro ejemplo: podemos introducir información en las tablas definidas
como se proponía en el punto 3, pero no controlamos la integridad de
los datos. Podríamos decir, insertando una nueva tupla en la relación
IMPARTE, que Lucía se responsabiliza de la docencia de XYZ, pero tal
código de asignatura no se encuentra en la relación ASIGNATURA:
¿cuál es esa asignatura, cuántos créditos tiene?
Vamos a ver, a continuación, qué mecanismos utiliza el modelo
relacional para reflejar todas las restricciones semánticas que afectan a
un sistema de información representado mediante una base de datos
relacional.
Los conceptos del modelo relacional a desarrollar son los siguientes:
• dominio
• valor nulo
• clave primarias y alternativa
• clave ajena e integridad referencial
III4.1.Restricciones de dominio
Todo atributo tiene un dominio asociado (un tipo de datos), un conjunto
de valores sobre los que toma valor. Los atributos pueden contener
nulos o tener prohibida esta posibilidad.
Un valor nulo es ausencia de información, un dato que se desconoce.
No tiene nada que ver con valores 0 o cadenas de longitud 0, puesto
que estos son valores conocidos. Es un concepto fundamental de la
teoría del modelo relacional pero que está lejos de haberse solucionado
satisfactoriamente.
Por ejemplo, de una persona podemos no conocer su teléfono. Sin
embargo, esto no implica que esa persona no posea ese servicio sino,
simplemente, que no disponemos de esa información. Por otro lado, el
valor NULO no se puede comparar con otros valores; únicamente
podemos saber si un atributo es NULO o no lo es. Así, si el sueldo de
un empleado es desconocido, obviamente, no podemos interrogar a la
base de datos sobre si esa persona es la que más cobra de toda la
plantilla.
III4.2.restricciones de identificación
Como ya hemos dicho, no existen dos tuplas iguales en una relación.
Es obvio, pues, que podemos encontrar un conjunto de atributos que

modelo relacional
45
por su combinación de valores nos identifique unívocamente una
determinada tupla de la relación (o fila de una tabla)9
.
Pensemos en una relación que contenga información sobre
PERSONAS. Parece obvio que nunca nos encontraremos el caso de
dos personas con el mismo D.N.I.: si éste es un atributo de la relación,
podremos diferenciar cada tupla (cada persona) de las demás.
Estamos buscando, pues, un atributo (o subconjunto de atributos) que
nos permita especificar una única tupla.
Clave candidata
Una clave candidata es un subconjunto de atributos que cumple que
cualquier combinación de sus valores es única; no existirán dos filas
con valores iguales en las mismas columnas que constituyen tal
subconjunto. Además, no debe contener atributos que no sean
relevantes para esa identificación.
Sea R una relación con atributos A1, A2, ..., An. Se dice que un
subconjunto de esos atributos K = { Ai, Aj, ..., Ak } es una clave
candidata si satisface las dos propiedades siguientes: identificación
única e irreducibilidad.
Identificación única
No hay dos tuplas en R, Tm y Tn tales que:
Aim = Ain
Ajm = Ajn
.... Akm = Akn
Para cada tupla, la combinación de valores de los atributos que forman
la clave candidata es única, no se repite para ninguna otra tupla.
K es irreducible
Ninguno de los atributos de K puede eliminarse sin que se deje de
cumplir la propiedad anterior, o lo que es lo mismo, ningún subconjunto
de K puede diferenciar cada tupla del resto de tuplas de la relación.
Supongamos una relación R con atributos a, b, c, y d. Si (a,d) es clave
candidata entonces10
:
(a) no lo es, ni (d)
(a, b, d) no lo es, ni (a, c, d), ni (a, b, c, d)
(b) sí puede serlo, y (c)
(c, d) sí puede serlo, y (a, b), (a, c), (b, c)
9
En general, no vamos a diferenciar términos tales como tupla de relación y fila, o atributo
y columna: véase la discusión del punto anterior.
10
Téngase en cuenta que el orden de las columnas no importa: (a, d) es lo mismo que (d,
a).

Apuntes bd1

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to Apuntes bd1

Similar to Apuntes bd1 (20)

Recently uploaded

Recently uploaded (20)

Apuntes bd1