Diseno_de_base_de_datos-Informatica_3

Guía de Informática III
Presentación del Autor:
Carta al Alumno
Estimado alumno:
Me es grato acercarme a usted a través de estas líneas y ofrecerle compartir esta materia
esperando que tenga el deseo de disfrutarla y la constancia suficiente para aprovechar su tiempo y
esfuerzo.
Con los contenidos de la asignatura quiero proveerle la predisposición natural a desarrollar
bases de datos eficientes, desde el modelado de la misma, adaptando una situación de la vida real
hasta la creación de sus estructuras de almacenamiento, empleando mecanismos de particulares
de almacenamiento y recuperación de datos. Es nuestro deseo acompañarlo en su estudio y
convertirlo en un administrador de bases de datos que integre todos los conocimientos aprendidos,
su experiencia y habilidad para lograr una buena gestión de las bases de datos.
Estoy segura que la interacción de este trabajo con el suyo en la practica y seguimiento de
cada una de las etapas, logrará impulsar su aprendizaje rápidamente.
¡Comencemos!
Índice
Unidad I: Panorama general de los sistemas de bases de datos
1. Sistemas de bases de datos

1.1 Ejemplo de sistema de base de datos
1.2 Componentes de un sistema de base de datos
1.3 Fundamentos para el uso de sistemas de base de datos
1.4 Sistema de archivo tradicional y sistemas de bases de datos
1.5 Diccionario de datos
2. Resumen de los modelos de bases de datos
2.1 Modelo relacional de base de datos
2.2 Modelo de base de datos orientado a objetos
2.3 Modelo deductivo de base de datos
2.4 Modelo de base de datos en red
3. Una arquitectura de sistemas de bases de datos: arquitectura de tres esquemas
3.1 Componentes de la arquitectura de un sistema de base de datos
3.2 Arquitectura de tres esquemas
3.3 Sublenguajes de datos
3.4 Administrador de bases de datos
3.5 Sistema de administración de bases de datos
Unidad II: Estructuras de almacenamiento en disco
1. Definición de estructuras de almacenamiento

2. Organización física de un disco de almacenamiento
3. Indización
4. Dispersión
5. Cadena de apuntadores
6. Técnicas de compresión
Unidad III: Bases de Datos Relacionales
1. Ilustración informal de una base de datos relacional

2. Elementos del modelo relacional
1
3. Relaciones binarias
3.1 Relaciones de una a muchas
3.2 Relaciones de muchas a muchas
3.3 Factorización de relaciones muchas a muchas
3.4 Relaciones una a una
4. Relaciones de grado superior
4.1 Relaciones recursivas
5. Restricciones de integridad
Unidad IV: Modelado de datos utilizando el enfoque Entidad – Relación
1. La importancia del modelo Entidad – Relación

2. Convenciones y definiciones básicas
3. Un ejemplo simple
4. Identificar entidades, atributos y relaciones
5. Comprobación de calidad y de finalización
6. Relaciones validas
Unidad V: Lenguaje de Consulta Estructurada
1. Álgebra relacional
2. Lenguaje de consulta estructurado
2.1 Definición de Datos
2.2 Manipulación de Datos
3. SQL Avanzado
3.1 Vistas
3.2 Independencia de Datos
3.3 Valores nulos
3.4 Disparadores
Unidad VI: Diseño de bases de datos
1. La importancia de un buen diseño de bases de datos

2. La teoría de Normalización
2.1 Dependencias funcionales
2.2 Formas Normales
2.3 Forma Normal de Boyce/Codd
3. Diseño simple de base de datos
Unidad VII: El ambiente de las bases de datos (DATE)
1. Recuperación
2. Concurrencia
3. Seguridad
4. Integridad
Introducción General Orientadora: (Resumen de la Materia)
Nuestra asignatura es una de las más importantes de la línea Informática, fundamentalmente por la
importancia que las Bases de Datos, especialmente las relacionales, tienen en las empresas.
Comprender y manejar los conceptos de la misma asegurará al alumno una muy buena inserción
2
en el ámbito profesional. Además, es el punto de partida para las asignaturas siguientes, entender
los conceptos e ideas de la materia es una base fundamental para el Analista de Sistemas.
Hoy en día no existe una organización que no necesite un sistema de base de datos donde pueda
apoyar su estructura de información. Las bases de datos y la tecnología a ellas asociadas están
teniendo un impacto crucial en casi todas las áreas de aplicación de tecnologías informática, como
son las industrias, el comercio, la educación, la medicina, etc. El termino "base de datos" es de
amplia difusión y por tanto utilizado habitualmente cuando se habla de estructuras de datos. Ahora
bien cuando hablamos de bases de datos, ¿a qué nos referimos?
Una concepción general de este concepto nos dice que es:
 una colección de datos relacionados entre sí

 construida para lograr un cierto objetivo
 que representa algún aspecto del mundo real
 y que posee un cierto significado.
Un sistema de base de datos cuenta con un sistema de administración de base de datos (DBMS)
que es un conjunto de programas necesarios para crear y mantener una base de datos. El DBMS
debe emplear varios métodos para llevar a cabo su función, cada método constituye un modelo de
base de datos. Un modelo de base de datos proporciona un mecanismo particular para guardar y
recuperar datos.
En las primeras unidades realizamos una presentación general de cinco modelos de bases de
datos: relacional, orientado a objetos, deductivo, de red y jerárquico. El modelo relacional es el
preferido en la actualidad mientras que el orientado a objetos y deductivo marcan la tendencia
hacia el futuro ya que se adaptan a las nuevas estructuras de los lenguajes.
El modelo relacional establece el modo de representar los datos, para ello, utiliza un esquema
como el de tablas bidimensionales. Estudiaremos que estas tablas deben cumplir ciertas reglas
para poder denominarlas bases de datos. La arquitectura del Modelo Relacional es propia de este
modelo y consta de un nivel externo, el que ve el usuario final; un nivel conceptual, la estructura
base de la relación y por último el nivel interno que es la representación de bajo nivel.
Una vez que los datos son almacenados en bases de datos podemos realizar consultas complejas
mediante pasos simples con la utilización de un lenguaje de manipulación de datos denominado
SQL (Structured Query Language). El SQL funciona eficientemente cuando las bases de datos
están normalizadas, es decir, correctamente estructuradas.
Los contenidos de esta materia serán utilizados seguramente en forma cotidiana durante su
ejercicio profesional de los próximos años, por esa razón compartimos un objetivo: ayudarlo a
desarrollar una predisposición natural al diseño de bases de datos relacionales eficientes y
convertirlo en un ferviente defensor de esa eficiencia.
La materia consta de cinco unidades. Lo que se estudia en cada una de ellas es lo siguiente:
 En la unidad I presentamos un panorama general de las bases de datos y se sus diferentes

modelos. Nos introducimos en la arquitectura de sistemas de bases de datos, qué son, cómo se
administran, quiénes las administran, quiénes las utilizan y qué ventajas proporcionan frente a
los archivos tradicionales.
 En la unidad II vemos las estructuras de almacenamiento, su importancia, y como

desarrollarlas de forma tal de optimizar los tiempos de espera de consultas y actualizaciones, y
ocupar menos espacio en disco.
 En la unidad III comenzamos con el estudio de uno de los modelos presentados en la unidad I:
El Modelo Relacional, describimos la estructura de las bases de datos y sus reglas de
integridad. Además aprendemos a representarlo mediante el diagrama Entidad-Relación. Por
último nos centramos en la normalización; este método permite reducir las bases de datos a
estructuras simples, sin redundancia de datos, evitando así problemas en la actualización de
datos.
3
 En la unidad IV estudiamos el diagrama entidad-relación, aprendiendo como identificar y
representar los componentes del diagrama, destacando la importancia de su utilización en la
construcción de buenos sistemas y/o manuales de sistemas.
 En la unidad V analizamos el álgebra relacional necesario para la creación de consultas;

estudiamos un lenguaje de manipulación de datos (SQL) que permite de manera sencilla
actualizar y obtener los datos de las bases de datos. Aprendemos también funciones,
procedimientos y otros objetos de las bases de datos.
 En la unidad VI estudiamos como diseñar correctamente una base de datos utilizando las
técnicas de normalización y ampliando algunos conceptos adicionales que ayudan al diseño.
Destacamos la importancia de un buen diseño y como facilita el momento de la construcción del
modelo físico.
 En la unidad VII desarrollamos aspectos importantes del ambiente de las bases de datos
planteando algunos problemas de concurrencia y de seguridad de datos. Para solucionar esto
estudiamos técnicas que ayudan a compartir los datos de una forma segura y proveemos
información de cómo manejar la seguridad de accesos a los datos.
¿Qué bibliografía obligatoria utilizaremos?

 DATE C.J. Introducción a los Sistemas de bases de datos. Volumen 1. Quinta Edición. Editorial
Addison-Wessley Iberoamericana. 1993.
 JAMES L: JHONSON Bases de datos. Modelos, lenguajes, diseños. Editorial OXFORD

University Press
 RICHARD BARKER. El modelo entidad-relación CASE*METHOD. Editorial Addison-Wessley
Al finalizar la materia esperamos que haya logrado los siguientes objetivos:
 Conocer y distinguir los distintos modelos de bases de datos, identificando sus ventajas y
desventajas.
 Comprender los fundamentos teóricos del modelo relacional y su aplicación práctica.
 Identificar las ventajas de la utilización de bases datos frente a los archivos tradicionales.
 Modelar una base de datos utilizando el diagrama entidad-relación
 Reconocer el valor de las restricciones de integridad y de la normalización de las bases de
datos e incorporarlas como alternativas únicas en el diseño de bases de datos.
 Visualizar la importancia de la normalización en las bases de datos.
 Comprender la ventaja de utilizar SQL para la confección de consultas y adquirir práctica en su
utilización.
 Aplicar los conceptos de seguridad y integridad en bases de datos.
 Identificar claramente los tres niveles de la arquitectura de bases de datos.
Le recomendamos que al finalizar el estudio de cada unidad revise si ha cumplido con los objetivos
específicos de esa unidad y que efectúe el mismo tipo de control al finalizar la materia respecto de
los objetivos generales.
Ante cualquier duda o dificultad no deje de consultar al tutor.
4
Cómo está organizada la guía de estudio de la asignatura
Conforme avanzamos con el desarrollo de los temas teóricos encontrara usted pequeños
recuadros con actividades o preguntas simples que le permitirán reafirmar conceptos claves,
necesarios para seguir adelante. Al finalizar cada unidad deberá resolver además las Actividades
de autoevaluación que le ayudarán a estimar lo cerca que está de cumplir los objetivos de la
unidad.
Revisión de Terminología:
Para facilitar su estudio se le proporciona la definición de ciertos términos utilizados en el desarrollo

de la unidad. Esa revisión terminológica le será útil a modo de repaso, para la mejor comprensión
de unidades posteriores.
Actividades de autoevaluación:
En esta sección se elaboran preguntas para que usted revise los temas estudiados, destacando los
ítems mas importantes de la unidad. Además se plantean problemas y ejercicios que le permitirán
relacionar los contenidos estudiados integrando sus conocimientos. De esta manera usted podrá
fijar mejor los conceptos de la materia, logrando así los objetivos planteados.
Esquema Conceptual de la materia:
Cómo estudiamos:
La materia se divide es dos partes principales:
 Bases de datos
A su vez esta primera parte se subdivide en una parte fundamentalmente teórica que lo
inserta al alumno en el concepto general de las bases de datos y su importancia y otra con
base práctica en las bases de datos relacionales específicamente, las cuales se estudiaran
en detalle incorporando un enfoque de modelado - modelo de entidad-relación -, la
normalización de bases de datos y un lenguaje para poder manipularlas llamado SQL.
La bibliografía obligatoria para esta parte es el libro “Sistemas de Bases de Datos” de
Date.
 DB2
Para que el alumno pueda aplicar los aspectos aprendidos en la teoría se estudiara un
motor de base de datos de IBM llamado DB2.
Sugerencias para estudiar la materia:
 Comenzar leyendo la guía de estudio por unidad.

 Realizar todas las actividades de proceso que están propuestas al final del desarrollo de
cada tema, ya que esto ayudara a fijar los conceptos estudiados.
 No pasar a la siguiente unidad de la guía sin haber comprendido los conceptos.
 Consultar la pagina de la materia, allí Ud. tendrá disponible mas información de cada que
pueden aclararle algunos conceptos, ejemplos de la vida real, sitios de interés que puedan
ayudarle en el estudio de la materia, foros, preguntas frecuentes, ejercicios, etc..
 En las ultimas unidades con toda la base teórica recorrida, tome ejemplos de la vida real y
llévelos a la practica en pequeños sistemas de bases de datos tomando como ejemplos los
ejercicios propuestos. Piense que ejercitar es la mejor forma de asimilar los conceptos
teóricos de la asignatura.
Bibliografía:
5
 DATE C.J. Introducción a los Sistemas de bases de datos. Volumen 1. Quinta Edición. Editorial
Addison-Wessley Iberoamericana. 1993.
 JAMES L: JHONSON Bases de datos. Modelos, lenguajes, diseños. Editorial OXFORD

University Press
 RICHARD BARKER. El modelo entidad-relación CASE*METHOD. Editorial Addison-Wessley
Como es la evaluación:
Criterios de evaluación para el examen final.
 Claridad y rigurosidad en los conceptos que fundamentan la teoría de los Sistemas de

Bases de Datos.
 Precisión en la justificación de las respuestas a los temas propuestos.
 Claridad en los ejemplos elaborados.
 Precisión en la sintaxis y el resultado de los ejercicios prácticos.
Sugerencias para el examen final
 Analice e integre los conceptos teóricos de Sistemas de Bases de datos con la practica.
 Reflexione sobre cada caso practico planteado tanto en la guía como en la pagina web de
la asignatura.
 Resuelva todas las actividades y ejercicios propuestos en la guía y en la bibliografía
obligatoria.
 Clarifique todas sus dudas.
 Realice todos los ejercicios de SQL y álgebra relacional.
 Elabore ejemplos propios y consulte su dudas acerca de los mismos.
Cuanto tiempo lleva estudiar la asignatura:
Cronograma:
Unidades Distribución de tiempo Tiempo

estimada
1 10%
2 10%
3 10%
4 20%
5 20%
6 20%
7 10%
6
Unidad I: Panorama general de los sistemas de bases de datos
Orientación del Aprendizaje:
Toda organización necesita mantener su información sobre un sistema que le permita archivar,
actualizar y obtener de manera segura y confiable los datos importantes de su compañía. Esto es
en esencia un sistema de base de datos. En esta unidad presentamos el concepto global de
sistemas de bases de datos y hacemos énfasis en la comparación con los sistemas de archivo
tradicional que solamente permitían almacenar información. Destacamos las ventajas de emplear
un sistema de base de datos aprovechando sus funciones y reglas.
Un sistema de base de datos puede emplear varios métodos para llevar a cabo sus
responsabilidades; cada método constituye un modelo de base de datos. Un modelo de base de
datos es un principio de organización que especifica mecanismos particulares para guardar y
recuperar datos. Realizamos una explicación sistemática de cinco modelos de base de datos.
El desarrollo de cada modelo comprende varios niveles, desde las estructuras físicas sobre el
dispositivo de almacenamiento en disco hasta las abstracciones - tablas, objetos- que describen
una aplicación. Describimos una arquitectura típica para el modelo relacional de base de datos.
Desde esta perspectiva los contenidos que trabajaremos en la unidad son:
Contenido de la Unidad:
1. Sistemas de bases de datos

1.5 Diccionario de datos
2.2 Modelo de base de datos orientado a objetos
3. Una arquitectura de sistemas de bases de datos: arquitectura de tres esquemas
3.4 Administrador de bases de datos
3.5 Sistema de administración de bases de datos
7
Esquema Conceptual:
Usuarios Programadores de Usuarios Administrador de

ingenuos aplicaciones sofisticados base de datos
Interfaces de Lenguajes de Interfaces de Planificación de

aplicación desarrollo consulta base de datos
Precompilador de Compilador de
lenguaje de Procesadores de lenguaje de
manipulación de consulta definición de datos
datos
Código objeto de
programa de Gestor de
aplicación Archivos
Sistema de
gestión de base
de datos
Gestor de
Archivos
Archivos de
datos
Diccionario de
Almacenamiento datos
en disco
Estructura del sistema
Fuente: Korth H, Silbertschatz A. Fundamentos de base de datos. Segunda Edición Editorial Mc

Graw Hill. España 1995
Los objetivos que alcanzara con el estudio de esta unidad son los siguientes:
 Identificar a las bases de datos relacionales como una alternativa de almacenamiento

de datos.
 Aprender a identificar la información que debe ser almacenada en una base de datos.
8
 Diferenciar los distintos tipos de modelos de datos reconociendo las ventajas y
desventajas de cada uno.
 Analizar los diferentes niveles de una arquitectura de base de datos.
1. Sistemas de base de datos:
Un sistema de base de datos se apoya en un administrador de sistemas de base de datos y presta

soporte al almacenamiento confiable de la base de datos, pone en marcha las estructuras para
mantener relaciones y restricciones, y ofrece servicios de almacenamiento y recuperación a
usuarios; otras funciones se ocupan de tareas como son el acceso simultaneo, seguridad, respaldo
y recuperación de datos.
Una base de datos es un conjunto de elementos de datos que se describe a si mismo,

establece relaciones entre esos elementos y presenta una interfaz uniforme de servicio.
Suponga usted que se le ha encomendado el desarrollo de un sistema automatizado cuyo objetivo

sea la administración de alumnos de la universidad. El sistema de información automatizado
deberá contemplar las materias cursadas y rendidas por cada alumno, los parciales aprobados y
reprobados entre otros datos, las correlatividades de las materias y los docentes de cada materia.
Es natural suponer que, para responder a las necesidades expuestas anteriormente, será
necesario almacenar datos relativos a cada uno de los aspectos indicados a continuación:
ALUMNOS: nombre_alumno, documento, dirección, localidad, teléfono.

MATERIAS: nombre_materia.
CARRERAS: nombre_carrera, nombre_materia.
DOCENTES: nombre_profesor.
DICTADO_MATERIAS: nombre_materia, nombre_profesor, día, hora, aula.
Habrá notado que cada objeto de la aplicación que desarrollamos esto es, alumnos, materias, etc.,
tiene un conjunto de valores de datos: nombre, documento, dirección, localidad, teléfono, etc.
La definición anterior requiere que los elementos de datos se encuentren en una estructura que se
describa a sí misma, y les confiera significado. La estructura más obvia es la que representamos
en el siguiente esquema.
9
ALUMNOS ALUMNO_MATERIAS MATERIAS CARRERAS
nombre_alumno nombre_alumno nombre_materia nombre_carrera

documento nombre_materia nombre_materia
dirección fecha_inscripcion
localidad
teléfono
DOCENTES DOCENTE_MATERIAS
nombre_profesor nombre_profesor
dirección nombre_materia
teléfono día
documento hora
aula
La definición también expresa que una base de datos debe almacenar relaciones entre los
elementos de datos. En general decimos que una relación indica la existencia de un sentido de
unidad entre ciertos elementos de datos.
Supongamos que Pedro Campos es alumno del Instituto Universitario Aeronáutico y que esta
inscripto en la materia Física I de la carrera Ingeniería en Sistemas. Note que el atributo
nombre_alumno en la relación alumno_materia, especifica el nombre del estudiante "Pedro
Campos" que está inscripto en alguna materia "FISICA I" del atributo nombre_materia. Esta
conexión declara una cierta "cercanía" entre el conjunto de valores de datos que representa al
estudiante "Pedro Campos" y el conjunto que representa a la materia "FISICA I". En este caso la
base de datos almacena esta asociación en una nueva relación donde se inserta una parte de la
identificación de una entidad: ALUMNOS con otra parte de otra entidad: MATERIAS.
Ahora encuentre usted otras relaciones entre los atributos de las entidades descriptas en el ejemplo
anterior.
Las base de cada relación es un principio abstracto que agrupa elementos de datos de una manera
significativa para la aplicación.
Un sistema de base de datos es un sistema para archivar en computador cuyo propósito general
es mantener información y hacer que este disponible cuando se la solicite1.
El propósito del esquema es ilustrar como se integran los cuatro componentes principales de un
sistema de bases de datos : la información, el equipo, los programas y los usuarios.
1
DATE C.J Introducción a los sistemas de base de datos. Volumen I. Quinta Edicion. Editorial Addison Wessley
Iberoamericana
10
Sistema de administracion de bases de
datos (DBMS)
Base de datos
Programas Usuarios
de aplicación finales
Esquema simplificado de un sistema de bases de datos:
Fuente: Date C. J. Introducción a los sistemas de base de datos. Volumen I. Quinta Edicion.
Editorial Addison Wessley Iberoamericana
Información
Puede ser cualquier concepto que se considere importante para el individuo o la organización a la
cual debe servir el sistema. La información en la base de datos estará integrada y además será
compartida. Definiremos estos conceptos a continuación:
Integrada: significa que la base de datos puede considerarse como una unificación de varios
archivos de datos, por lo demás distintos, y que elimina del todo o en parte cualquier redundancia
entre ellos.
Compartida: significa que los elementos individuales de información en la base de datos pueden
compartirse entre varios usuarios distintos, y diferentes usuarios están habilitados para acceder al
mismo elemento de información y utilizarlos para propósitos diferentes.
Busque informacion en bibliografias o sitios de interes que hagan referencia a estos dos conceptos y
elabore un ejemplo del concepto informacion integrada y otro de informacion compartida.
Confronte con solucion nº 1
11
Equipo
Los componentes de equipo del sistema son:
 Los volúmenes de almacenamiento secundario donde se conservan los datos almacenados,

junto con los dispositivos de E/S asociados (unidades de disco, etc.), controladores de
dispositivos, canales de E/S, etc.
 El procesador, o procesadores, y la memoria principal asociada que hacen posible la ejecución
de los programas del sistema de bases de datos.
No nos ocupamos mucho más de los componentes del equipo ya que los problemas que presentan
en este área no son exclusivos de los sistemas de bases de datos; sólo lo analizaremos como
componente de un sistema de base de datos. Si desea usted profundizar este tema existe gran
cantidad de material que podrá consultar.
Programas
Entre la base de datos física misma, o sea los datos tal como están almacenados en realidad, y los
usuarios, existe un nivel de programas: el sistema de administración de base de datos (DBMS). El
DBMS maneja todas las solicitudes de acceso a la base de datos formuladas por los usuarios.
Analizaremos las funciones del DBMS en unidades posteriores.
Usuarios
 Programador de aplicaciones: escriben programas de aplicación que utiliza la base de datos.

 Usuario final: interactúan con el sistema desde una terminal en línea.
 Administrador de dase de datos: se encarga del diseño de la base de datos misma; mas
adelante profundizaremos este tipo especial de usuario.
De acuerdo con lo estudiado hasta este momento, responda con sus palabras las siguientes
preguntas:
¿Que es un sistema de base de datos? ¿En que casos cree necesario implementarlo? Ejemplifique.
¿Cuáles son sus principales componentes? ¿Qué rol cumple cada uno de ellos?
Los sistemas de bases de datos separan el almacenamiento de datos y los detalles de

recuperación -lectura- de las complejidades especificas de una aplicación. Se puede apreciar mejor
la necesidad de esta separación si se conocen algunos problemas de sistemas anteriores a las
bases de datos.
Suponga que una aplicación consiste en un conjunto de programas, cada uno de los cuales
requiere ciertos archivos de entrada y produce archivos de salida empleados por otros programas
del conjunto; y considere las siguientes situaciones:
 Sin bases de datos, tanto dichos como los programas dependen en gran medida unos de otros.
Los elementos de datos dependen de que un programa les dé significado. Desde luego que un
programa requiere sus archivos de entrada para ejecutarse, pero también existe dependencia
en la dirección inversa. Al examinar un archivo de entrada aislado, podría resultar casi
imposible leerlo ya que está formado por unos y ceros. Sólo dentro de un programa los datos
se acomodan en estructuras que develan su significado. Si el archivo es una secuencia de
códigos ASCII, entonces éstos se pueden volcar o descargar para mostrar la estructura del
registro.
12
Veamos este ejemplo. Un registro puede aparecer como 0 08 11 2 14 JUAN 45601 AT7Y 000
45. La palabra JUAN lleva a sospechar que éste es un registro de personal, pero el resto del
registro no proporciona mucha más información. Obviamente, los datos no son descriptivos por
sí solos. Quizá haya documentación que describa los campos del archivo y tal vez el
programador recuerde el diseño. Cuando el programa lee el archivo, los caracteres llenan
ciertas variables y estructuras de registro y quizá el programa contenga comentarios acerca del
significado de estas variables. El punto es que los datos tienen sentido sólo en el contexto del
programa. Debido a que el usuario necesita el programa apropiado para comprender el
significado de los datos, no es probable que utilice ese archivo de datos para un programa
nuevo, incluso si el archivo contiene exactamente la información que requiere el nuevo
programa.
Los datos no deben depender de un programa para hacerlo entendible y útil, es decir, los datos
deben describirse por sí solos.
 Fuera de un entorno de bases de datos, el mismo elemento de datos aparece en muchos

archivos. Cada programador establece una estructura de archivo para igualar las necesidades
de entrada de un programa en particular. Debido a que el programador no desea buscar e
interpretar archivos asociados con otros programas, crea una nueva estructura de archivo que
pueda duplicar elementos de datos existentes.
Por ejemplo, muchos programas procesan registros de persona, todos de diferentes archivos,
todos con elementos de datos como nombre, dirección, ciudad y teléfono. Si bien el espacio de
almacenamiento desperdiciado constituye un problema, mas importante resulta el problema de
la integridad de datos. Si un empleado cambia de domicilio ¿llegará la actualización a todos los
archivos que contengan los datos de la dirección? Con la dirección dispersa en muchos
archivos, algunos de ellos podrían contener la nueva dirección, pero otros conservarían la
anterior. Desde el punto de vista de la aplicación, esta condición es inconsistente porque un
empleado debe tener una dirección bien definida.
 Sin un depósito central de base de datos, frecuentemente los programas deben tener acceso a
datos que se hallan en archivos separados.
Considere el siguiente ejemplo: Un usuario necesita un informe de ciertos detalles acerca de

los empleados que trabajan en varios proyectos. El archivo de personal y el archivo de
proyectos en proceso suministran, cada uno de ellos, parte de la información requerida. El
usuario puede escribir un procedimiento preliminar para extraer los campos deseados de cada
archivo produciendo por tanto un archivo especial para este programa, pero esto sólo se
sumaría al problema de la repetición de datos. En teoría, debe ser posible recobrar las
relaciones entre los elementos de datos a partir de datos en bruto, sin dicho procesamiento
previo. Como los trabajadores y los proyectos están naturalmente relacionados en la
aplicación, el usuario debe estar en aptitud de ensamblar los campos requeridos por el nuevo
programa según sea necesario. En otras palabras, un mecanismo de almacenamiento y
recuperación flexible debe mantener relaciones en igual condición con los elementos
individuales de datos.
 Sin una base de datos centralizada, la política de seguridad debe tratar con un conjunto
disperso de archivos de formatos que varían. Ciertos aspectos de seguridad destacan en
cualquier conjunto de datos: ¿a quién se le permite tener acceso a los datos? ¿quién los
cambia? Una base de datos maneja la seguridad en una forma más eficiente al concentrar el
esfuerzo sobre la base de datos misma. Los sistemas de bases de datos ofrecen una amplia
variedad de medidas de seguridad, que permiten varias clases de privilegios de acceso como
leer, escribir, borrar a diferentes resoluciones estructurales como elemento de datos, registro,
tabla, archivo. Se reconoce que el método centralizado tiene una incómoda desventaja de
seguridad: todos los datos quedan expuestos.
13
 Los borrados o actualizaciones de datos pueden producir inconsistencias, difíciles de controlar
en un sistema sin base de datos.
Suponga el siguiente ejemplo. Un usuario desea demoler la casa de un empleado. El campo

de dirección de muchos archivos se puede referir ahora a una casa que no existe. ¿Deben los
programas de aplicación tratar de conservar actualizados estos alineamientos de datos? Si es
así, ¿qué programa de aplicación tiene cuáles responsabilidades? Una base de datos puede
coordinar las actividades de borrado, lo cual asegura que no queden referencias colgantes
después de un borrado.
 Sin base de datos es mas difícil compartir datos. Aun cuando los sistemas operativos
proporcionan acceso simultáneo de sólo lectura a archivo, normalmente limitan el acceso de
lectura-escritura a un proceso. Un archivo de datos en particular puede entonces servir sólo a
un usuario común en un momento determinado. Este nivel burdo de bloque es ineficiente
porque el programa podría estar usando sólo una pequeña parte del archivo, y otro programa
podría desear tener acceso a una porción no relacionada. Una base de datos puede coordinar
acceso simultáneo a los elementos de datos. Permite compartir datos a una resolución más
fina, bloqueando sólo elementos individuales de datos durante operaciones de escritura.
 Sin vigilancia de bases de datos, pueden aparecer inconsistencias de datos cuando un largo
proceso termine en error. Un proceso puede modificar parte de los datos pero abortar antes de
instalar todos los cambios deseados.
Supongamos que a través de un movimiento bancario debemos transferir dinero de la cuenta X

a la cuenta Y. El movimiento resta la cantidad del saldo de la cuenta X y luego, una falla en la
energía eléctrica interrumpe el proceso antes de que pueda sumar la cantidad a la cuenta Y. El
usuario puede recobrar los archivos afectados usando las copias de respaldo, pero éste es un
método específico para el problema general de recuperación por fallas. Por el contrario, un
sistema de base de datos fácilmente maneja dicha recuperación. El DBMS (Sistema de
administración de base de datos) rechaza un tramite que no se completa, permaneciendo el
estado de la base de datos como si el movimiento nunca se hubiera iniciado. Debido a que el
DBMS maneja recuperaciones, las aplicaciones individuales no tienen que tratar con
operaciones fallidas.
 Finalmente, sin bases de datos, las variaciones en la representación física de los datos pueden
causar muchos problemas.
Por ejemplo: si el medio de almacenamiento de información cambia de disco magnético a disco

óptico, ciertas aplicaciones pueden quedar invalidadas porque tienen referencias de
codificación inalterable para el primer dispositivo, con número de cilindro y pistas. Otro
problema aparece cuando los registros de archivo adquieren un nuevo campo. Los programas
viejos podrán pasar por alto el campo nuevo, pero, ¿lo harán? Todo depende de que tan cerca
el programador haya acoplado la actividad de lectura-escritura a los detalles de las estructuras
de almacenamiento. Por último, supongamos que se dispone de memoria extra para
procesamiento. ¿Aprovecharán ésta memoria, los programas al enviar los registros de datos a
la memoria caché, reduciendo así los lentos ciclos de acceso al disco? Es probable y seguro
que no. Los programas deben ocuparse de manipular los objetos de la aplicación sin detalles
de almacenamiento.
Teniendo en cuenta los ejemplos presentados elabore una lista de ventajas y desventajas que, a su
criterio, presenta un sistema de base de datos.
14
En los sistemas de archivo tradicional cada aplicación define los archivos que utilizará. En el
ejemplo citado anteriormente, el sector "Inscripción de alumnos", mantendrá un archivo con los
datos de los alumnos, las materias cursadas y las materias en las que se inscriben. Por otro lado,
el sector "Seguimiento de alumnos" deberá tener un archivo con los datos de los alumnos, las
materias en las que están inscriptos, las notas de los parciales y finales de cada materia.
En un sistema como este, la redundancia de datos es muy significativa. A consecuencia de esta

característica se desperdicia espacio de almacenamiento, se tornan más complicados y lentos los
procesos de respaldo, resulta muy difícil mantener todos los archivos duplicados actualizados, en
síntesis, se sobreutilizan los recursos innecesariamente.
Un sistema de bases de datos cuenta con un único almacén de datos desde donde los usuarios de
cada aplicación consultan y/o actualizan.
Lo importante es que en el sistema exista tanto la definición de la base de datos - almacenada en
el catalogo del sistema - como la base de datos misma.
El catálogo del sistema contiene información sobre la estructura de cada relación de la base de
datos y acerca de las restricciones relativas a los datos. Esta información se denomina metadatos.
En la siguiente sección ampliamos el concepto de Diccionario de datos.
Al mantenerse la estructura de la base de datos en el catálogo del sistema, la misma puede ser
accedida por el DBMS o los usuarios y es independiente de la aplicación que manipula estos
datos.
En los sistemas de archivo tradicionales cada vez que se cambia la estructura de un archivo es
necesario cambiar todas las aplicaciones que utilizan este archivo, como hemos mencionado en
los ejemplos del tema anterior. En cambio, trabajando con bases de datos, las aplicaciones y
los datos son independientes. Pueden incorporarse columnas nuevas a una relación sin
necesidad de modificar todas las aplicaciones que acceden a dicha operación.
Los sistemas de base de datos permiten trabajar con vistas sobre los mismos. Una vista es una
combinación de datos extraídos de la base, que el usuario puede ver y actualizar sin conocer
necesariamente en qué relación están almacenados o si son datos calculados. Por ejemplo, se
puede armar una vista de la relación alumnos, citada anteriormente, que muestre el nombre y el
apellido de todos los alumnos. En este caso el usuario solo ve estas dos columnas sin saber que
existen las otras. Estas vistas pueden realizarse uniendo datos de varias relaciones.
La gran flexibilidad ofrecida por las bases de datos permite que varios usuarios accedan al mismo
tiempo a los mismos datos, por tanto, es necesario que el DBMS controle la concurrencia para
asegurar que los accesos simultáneos a los datos se haga de manera controlada.
Otra gran ventaja que ofrece el DBMS es el manejo de transacciones. Una transacción es un
conjunto de operaciones que deben ejecutarse todas o no ejecutarse ninguna. Veamos un proceso
de actualización de permisos de exámenes para los alumnos que registra las materias que un
alumno puede rendir. Este proceso no debe ser interrumpido porque a causa de una falla puede
quedar una parte de la relación actualizada y la otra sin actualizar. Para que no suceda esto, el
DBMS trabaja bajo el concepto de "transacción" lo que permite que en el caso de que una
operación de transacción no se complete con éxito, se anule la transacción en forma completa.
En unidades posteriores desarrollamos y profundizamos algunos aspectos presentados aquí:

vistas, acceso simultáneo y manejo de transacciones.
1.5 Diccionario de Datos
Introducimos una breve descripción de un Diccionario de Datos o Catálogo del Sistema tal como
aparece en DB2, con el objetivo de proporcionar un conocimiento básico de la estructura y
contenido de un catálogo representativo y ofrecer al alumno una idea de la utilidad de esa
15
información para el usuario y para el sistema. Esa forma simplificada contiene, entre otras, las
siguientes tablas del catalogo.
 SYSTABLES
Esta tabla del catálogo contiene una fila por cada tabla con nombre que forma parte del
sistema de base de datos. Por cada una de esas tablas, proporciona nombre (NAME), el
nombre del usuario creador de esa tabla (CREATOR), el número de columnas en la tabla
(COLCOUNT), y muchos otros datos más.
 SYSCOLUMNS
Esta tabla de catalogo contiene, entre otros datos, una fila por cada columna de cada tabla
mencionada en SYSTABLES. Para cada una de esas columnas, proporciona su nombre
(NAME), el nombre de la tabla de la cual forma parte (TBNAME), el tipo de datos de la
columna (COLTYPE)..
 SYSINDEXES
Esta tabla del catalogo contiene una fila por cada índice del sistema. Para cada uno de
estos índices, proporciona su nombre (NAME) , el nombre de la tabla indizada (TBNAME),
el nombre del usuario dueño del índice (CREATOR), etc.
La estructura del catálogo para la base de datos que definimos en el ejemplo anterior podría ser
como se muestra a continuación:
----------- ---------------- ------------------

SYSTABLE NAME CREATOR COLCOUNT
----------- ---------------- ------------------
alumnos Lucas 5
materias Lucas 1
carreras Lucas 2
docentes Lucas 4
----------- ---------------- ------------------

SYSTCOLUMNS NAME TBNAME COLTYPE
----------- ---------------- ------------------
nombre_alumno alumnos CHAR
documento alumnos CHAR
dirección alumnos CHAR
localidad alumnos CHAR
teléfono alumnos CHAR
nombre_materia materias CHAR
nombre_carrera carreras CHAR
nombre_materia carreras CHAR
nombre_profesor docentes CHAR
dirección docentes CHAR
teléfono docentes CHAR
documento docentes CHAR
En lo referido al ejemplo, suponemos que el dueño de todas las tablas e índices en esa base de
datos es un usuario cuyo identificador es "Lucas".
Como el catálogo se compone de tablas iguales a las tablas ordinarias de los usuarios, se admite
consultarlo mediante proposiciones SELECT de SQL de la misma manera que en el caso de tablas
ordinarias. Un usuario no familiarizado con la estructura de la base de datos puede valerse de este
tipo de consultas para descubrirla.
16
Sobre la base de los temas desarrollados hasta ahora, defina un sistema de base de datos que
reúna todas las características que a su juicio son mas importantes y justifique.
Un modelo de base de datos es un principio de organización que especifica mecanismos

particulares para guardar y recuperar datos. El modelo explica la forma de tener acceso a un
elemento de datos cuando se conocen otros elementos de datos relativos. También especifica el
significado preciso del término "datos relativos", y proporciona proyecciones -mapeos- de
relaciones particulares en una aplicación a los tipos mas genéricos conservados por el DBMS.
A continuación destacamos semejanzas y distinciones básicas entre cinco modelos de base de

datos:
El modelo relacional emplea tablas o "relaciones" para organizar los elementos de datos. Cada
tabla corresponde a una entidad de aplicación o "relación", y cada fila representa una instancia de
esa entidad o "tupla de la relación". Por ejemplo la entidad "alumno" en la aplicación corresponde a
la tabla ALUMNOS de la base de datos. Cada fila de la tabla representa un alumno diferente. Las
relaciones enlazan filas de dos tablas al insertar identificadores de fila de una tabla como valores
de atributo en la otra tabla. Por ejemplo, el identificador de una fila de alumnos (nombre_alumno)
aparece en una fila de ALUMNO_MATERIA determinando por tanto al alumno inscripto en esa
materia. A pesar de las complicaciones que resulta n de relaciones en donde aparecen muchas
filas de muchas tablas, este sencillo mecanismo soporta relaciones sin recurrir a estructuras
auxiliares, como listas o índices enlazados. El lenguaje de consulta estructurado (SQL) sirve como
interfase uniforme para los usuarios, proporcionando un conjunto de expresiones estándar para
almacenar y recuperar datos.
2.2 Modelo de base de datos orientado a objeto
Aun cuando en la actualidad el modelo relacional domina el campo, dos competidores agresivos
afirman dar una representación de datos más flexible, por lo menos para aplicaciones
especializadas. Nos referimos a los modelos posrelacionales. Cada uno ofrece una alternativa de
inserciones en tablas para mantener relaciones.
El primer modelo posrelacional, o modelo orientado a objetos, representa una entidad de aplicación
como una clase. Una clase captura los atributos y el comportamiento de la entidad. Por ejemplo, la
clase "alumno" posee no sólo atributos como el nombre, la dirección y el teléfono, sino también
procedimientos que imitan acciones esperadas de un alumno, tales como
inscribeEnMateria("matemáticas"); rindeExamen("química"). Las instancias de la clase, llamadas
objetos, corresponden a alumnos individuales. Dentro de un objeto, los atributos de clase toman
valores específicos, que distinguen, por ejemplo, un alumno de otro. Sin embargo, las pautas de
comportamiento son compartidas por todos los objetos alumnos.
El modelo orientado a objetos no restringe los valores de los atributos al pequeño conjunto de tipos
de datos nativos que por lo general se asocian con bases de datos y lenguajes de programación,
como entero, de punto flotante, real, decimal y de cadena. En lugar de esto, los valores pueden ser
otros objetos. Uno de los atributos de un alumno puede ser "carrera", y el valor de ese atributo
puede ser un "objeto carrera", correspondiente a la carrera que esta cursando el alumno en la
aplicación.
El modelo orientado a objetos mantiene relaciones por medio de una contención lógica. Considere
el ejemplo alumno-carrera. Encontramos a la carrera de un alumno en particular dentro del
alumno, como el valor de uno de los atributos del alumno. Puesto que "carrera" es un objeto en si,
se pueden examinar de modo recursivo sus atributos. En particular, la carrera puede tener un
atributo "ayudante de cátedra" cuyo valor es un objeto "alumno". Desde luego que el objeto
17
"alumno" es el mismo alumno en el que originalmente se encuentra la carrera. Dicho de otro
modo, el alumno X contiene a la carrera Y que contiene al alumno X. Debido a que la contención
física está obviamente fuera de toda duda, el término contención lógica es mas apropiado.
EL segundo modelo posrelacional de base de datos es el modelo deductivo, también conocido

como modelo de inferencia. Este modelo almacena tan pocos datos como sea posible, pero lo
compensa al mantener reglas que permiten crear nuevas combinaciones de datos cuando resulte
necesario. Supongamos que la base de datos almacena hechos de la forma alumCursaCarrera
(X,Y), lo que significa que el alumno X cursa la carrera Y. Por ejemplo, la realidad
alumCursaCarrera (Pedro, Ingeniería Electrónica) puede aparecer en la base de datos.
Supongamos que un alumno pueda cursar muchas carreras y que una carrera va a ser cursada por
varios alumnos. Entonces se puede imaginar otra relación en la que dos alumnos estén
relacionados si están cursando la misma carrera. Esta relación aparecería en el formato
carreraCompañeros (X, Z) lo que significa que los alumnos X y Z comparten una carrera. Aun
cuando la base de datos explícitamente almacena los hechos alumCursaCarrera (X, Y), no
almacena los hechos carreraCompañeros (X, Z). En lugar de ello, almacena una regla que expresa
que algunos hechos en particular, por ejemplo carreraCompañeros (Pedro, Pablo), se pueden
deducir de hechos existentes, por ejemplo, alumCursaCarrera (Pedro, Ingeniería Electrónica) y
alumCursaCarrera (Pablo, Ingeniería Electrónica). Estas reglas de inferencia indirectamente
capturan agrupaciones de relaciones. La base de datos entonces almacena ciertos hechos
elementales, llamados "axiomas", de los cuales se pueden deducir otros hechos cuando resulte
necesario.
2.4 Modelo jerárquico de base de datos
Al contrario de los modelos orientados a objetos y deductivos, el modelo jerárquico es

relativamente viejo, ya que se remonta a finales de la década de 1950. EL modelo jerárquico
supone una estructura de árbol, como el organigrama de una empresa. Así lo mostramos en el
siguiente diagrama:
Presidente
Vicepresidente Vicepresidente Vicepresidente
Dept Dept Dept Dept Dept Dept Dept
Emp Emp Emp Emp Emp Emp Emp Emp Emp
Emp Emp Emp Emp Emp Emp Emp Emp
Fuente: James L. Johnson Bases de datos: modelos, lenguajes, diseño Oxford University Press
Actualmente Esta suposición esta reconocida actualmente como confusa. De hecho, muchas de
las deficiencias del modelo jerárquico resultan de esta visión de relaciones sobrerestringida; por el
momento, supongamos que solo son importantes las relaciones jerárquicas.
Consideremos, por ejemplo, una jerarquía corporativa. El presidente se encuentra en la parte más
alta, sobre una estructura subordinada que se ramifica en vicepresidentes, departamentos y
18
empleados. En el organigrama se muestra sólo el tipo de entidad, por ejemplo: presidente,
vicepresidente, etc. y se suprimen los atributos, por ejemplo: nombre, dirección, número de seguro
social, etc. Varios vicepresidentes están bajo las órdenes del presidente, y varios departamentos
están bajo las órdenes de cada vicepresidente. En el nivel más bajo, cada departamento contiene
muchos empleados. Una característica clave de esta organización es que se puede traducir en una
lista lineal, como se ilustra a continuación:
Presidente (nombre= García, teléfono = 111-222-3333, etc.)

Vicepresidente (nombre= Allende, ...)
Departamento (nombre= Eléctrico, ...)
Empleado (nombre = Pérez, ...)
Empleado (nombre = Sánchez, ...)
Empleado (nombre = Gutiérrez, ...)
Departamento (nombre= Mecánico, ...)
Empleado (nombre = Casas, ...)
Empleado (nombre = Cena, ...)
Vicepresidente (nombre= Altamira, ...)
Departamento (nombre= Finanzas, ...)
Empleado (nombre = Pedernera, ...)
Empleado (nombre = Scarello, ...)
Departamento (nombre= Contabilidad, ...)
Empleado (nombre = Belveder, ...)
El modelo jerárquico organiza elementos de datos en filas tabulares, una por cada instancia de una
entidad de aplicación. En este ejemplo, una fila (renglón) separada representa al presidente, a
cada vicepresidente, a cada departamento y a cada empleado. La posición de la fila implica una
relación con las otras filas; esto es, un empleado determinado pertenece al departamento que está
más cerca arriba de él en la lista; un departamento determinado está bajo las órdenes del
vicepresidente inmediatamente encima del mismo en la lista. El modelo jerárquico representa
relaciones con la noción de adyacencia lógica, o mas precisamente, de proximidad lógica en el
árbol linealizado. Se puede aislar el conjunto de empleados que trabajan para el departamento
bajo las órdenes del vicepresidente X ubicando primero al vicepresidente X y luego incluyendo a
cada uno de los empleados en la lista después de X y antes de que se vuelva a presentar otro
vicepresidente (o el final de la lista). Debido a que el árbol linealizado es una abstracción, el
término proximidad lógica es mas apropiado. Un producto real puede dispersar los elementos de
datos en varias estructuras y materializar el árbol linealizado según sea necesario con esquemas
de segmentación o con listas enlazadas. La proximidad lógica describe la organización, pero no
implica proximidad física.
El modelo en red sustituye al árbol jerárquico con una gráfica, lo que permite conexiones más
generales entre los nodos. Sobre la base del ejemplo anterior, supongamos que un empleado
trabaja para dos departamentos; entonces se descompone el estricto arreglo jerárquico, y el árbol
del diagrama se convierte en una gráfica general, o red. La proximidad lógica falla porque no se
puede colocar un elemento de datos simultáneamente en dos posiciones de la lista. El modelo
jerárquico contiene métodos más complicados para manejar estas situaciones y la sintaxis resulta
más difícil de seguir. El modelo de base de datos en red evoluciono específicamente para manejar
relaciones no jerárquicas; mantiene relaciones con un sistema de cadenas que se intersecan como
se muestra en la siguiente ilustración. La cadena de línea continua que se extiende desde el
empleado "Carlos", contiene un círculo por cada departamento en el que "Carlos" trabaja. Del
mismo modo, la cadena de línea interrumpida que se extiende desde el "departamento eléctrico",
contiene un círculo por cada empleado de ese departamento. Cuando un círculo está en las dos
cadenas, entonces el empleado que origina la cadena de línea continua trabaja para el
departamento que posee la cadena de línea interrumpida. Las cadenas interrumpidas incompletas
que pasan por otros círculos de la cadena de "Carlos" pertenecen a otros departamentos.
Igualmente, las cadenas continuas incompletas que pasan por otros círculos en la cadena del
"departamento eléctrico" pertenecen a otros empleados.
19
Las cadenas que se intersecan mantienen relaciones en la red.
Departamento. Electrico...
Empleado: Carlos...
En el siguiente cuadro se resumen las características de los cinco modelos de bases de datos
estudiados antes.
Modelo Organización de Organización de relación Identidad Lenguaje de

elementos de datos acceso
Relacional Tablas Los identificadores para filas de una Con base en No
tabla se insertan como valores de valor procedimental
atributo en otra tabla
Orientado a Objetos: encapsulan Los objetos relacionados, de Con base en Procedimental
objetos lógicamente atributos y contención lógica, se encuentran registro
conducta. dentro de un objeto determinado por
examen recursivo de atributos de un
objeto que son los objetos mismos.
Deductivo Hechos base que pueden Reglas de inferencia que permiten Con base en No
arreglarse en tablas generar, a petición , hechos valor procedimental
relacionados
Jerárquico Archivos, registros Proximidad lógica en un árbol Con base en Procedimental
linealizado registro
Red Archivos, registros Cadenas que se intersecan Con base en Procedimental
registro
Explicamos ahora algunos conceptos no conocidos nombrados en el cuadro:
20
Lenguaje procedimental: prescribe una secuencia de operaciones para calcular los resultados
deseados.
Lenguaje no procedimental: expresa sólo los resultados deseados y deja el cálculo específico al
sistema de base de datos.
Otro concepto que se incluye en el cuadro de distinción es la identidad de los elementos. Dentro de
una base de datos, un objeto o relación de aplicación aparece como elemento de datos o
agrupación de elementos de datos.
Los modelos orientados a objetos, de red y jerárquicos suponen que el objeto sobrevive a cambios
de todos sus atributos. Estos sistemas están basados en registros. Un registro del elemento del
mundo real aparece en la base de datos, y aun cuando el contenido del registro puede cambiar por
completo, el registro en sí representa al elemento de aplicación. Mientras el registro permanezca
en la base de datos la identidad del objeto no cambia.
Por el contrario, los modelos relacional y deductivo están basados en valores. Suponen que un
elemento del mundo real no tiene identidad independiente de sus valores de atributo.
Represente la base de datos de la administración de alumnos de la universidad,

desarrollada en la sección anterior, en cada uno de los modelos de base de datos
estudiados.
3. Una arquitectura de sistemas de bases de datos: Arquitectura de tres esquemas
El objetivo de presentar esta arquitectura es establecer un marco de referencia útil para describir
los conceptos generales de bases de datos y explicar la estructura de sistemas específicos. Por
supuesto no aseguramos que todo sistema pueda encajar perfectamente en este marco de
referencia específico; ni tampoco sugerimos que esta arquitectura en particular constituye el único
marco de referencia posible. No obstante, la arquitectura en cuestión sí se ajusta en forma
razonable a la mayor parte de los sistemas.
Comenzamos con los elementos que componen la arquitectura de un sistema de bases de datos y
luego definimos los tres esquemas.
Componentes de la arquitectura central de un sistema de administración de bases de datos
Diseñador/
administrador de Usuario de base
base de datos de datos
Servicios de
Compilador almacenamiento/ Interface
de esquema recuperacion de usuario
21
DBMS
Sistema operativo
Diccionario Datos
de datos
El gráfico anterior ilustra una distribución arquitectónica simplificada de un sistema de

administración de base de datos (DBMS). En el nivel más bajo los elementos de datos aparecen en
almacenamiento en disco. Para satisfacer el requisito de descripción por sí solo, el DBMS también
debe almacenar metadatos, esto es, datos acerca de los datos, lo que comúnmente se llama
diccionario de datos o catálogo del sistema.
Debido a que un Sistema de administración de base de datos es software genérico, destinado a
dar soporte a una amplia variedad de aplicaciones de bases de datos, personaliza copias de la
estructura general de almacenamiento para reflejar las necesidades de aplicación. El diseñador de
aplicación proporciona los nombres de las entidades y sus atributos y también relaciones en un
guión que la máquina puede leer. Ese guión se denomina esquema conceptual. Por ejemplo el
esquema conceptual para la aplicación de alumno-carrera describe la tabla ALUMNOS y la tabla
CARRERAS, y observa la forma en que las filas de alumnos se relacionan con las filas de carreras.
EL DBMS compila el esquema conceptual en una forma compacta, apropiada para que otras
partes del sistema se remitan a ella, y lo archiva en almacenamiento permanente. Este diccionario
de datos está disponible para resolver referencias a nombres de tablas y atributos que resulten
cuando los usuarios de la base de datos soliciten servicios.
Los usuarios de bases de datos pueden ser individuos que traten con una interface interactiva, o
bien con otros programas de computadora que soliciten servicios con llamadas a
subprocedimientos proporcionados por el DBMS. Aun cuando existan algunas diferencias entre
estos dos modos de servicios, el DBMS debe proporcionar tanta uniformidad como sea posible a
sus usuarios. El módulo de interface del usuario del DBMS responde a las peticiones de servicio,
usando el diccionario de datos para confirmar la existencia y compatibilidad de elementos de datos
mencionados en las solicitudes. Un segundo módulo procesa peticiones de almacenamiento y
recuperación, ejecuta optimizaciones necesarias para reducir el tiempo de ejecución, y realiza las
operaciones de datos para responder. El DBMS pasa los elementos de datos solicitados y
devuelve cualquier mensaje de error hacia el modulo de interfase para retransmitirlo al usuario.
Un sistema de bases de datos intenta especialmente esconder el detalle de cómo se almacenan y

manipulan los datos internamente, de separar los programas de aplicación de los datos, posibilitar
22
el uso de vistas específicas para cada tipo de usuario entre otras. Para lograrlo se definen tres
niveles de abstracción: externo, conceptual e interno.
El nivel externo: también denominado nivel de vistas, muestra a cada tipo de usuario una vista
particular de los datos ocultando el resto de la base de datos.
El nivel conceptual: describe la estructura de la base de datos considerando las entidades

intervinientes, su tipo, las relaciones entre ellas y las restricciones.
El nivel interno: describe la estructura física de los datos detallando su estructura de

almacenamiento y métodos de acceso.
La arquitectura de tres esquemas permite explicar la mayor ventaja que propicia este sistema de
archivo: la independencia respecto de los datos, lo que implica que se puede modificar el esquema
en cualquiera de los tres niveles sin afectar el/los nivel/es superior/es.
Se puede incluso modificar la estructura de una relación agregando un nuevo elemento o registro
sin necesidad de modificar ningún programa de aplicación. Si fuese necesario modificar un
elemento para ampliar o reducir su capacidad o bien para cambiar su tipo, rara vez deberá
modificarse el programa de aplicación que trabaja sobre ese elemento en particular. A este tipo de
independencia se la denomina independencia lógica respecto de los datos. El trabajar con
bases de datos, vuelve sencillo cambiar la fecha de un formato dd/mm/aa a otro del tipo
dd/mm/aaaa permitiendo a las organizaciones ahorrar el costo de conversión, que en el caso de
los archivos tradicionales es bastante significativo.
Por otro lado, frecuentemente se presenta la necesidad de cambiar las condiciones de acceso a
una relación o de añadir nuevas formas de acceso. este ordenamiento de la relación puede
realizarse sin cambiar los niveles conceptuales ni externos. A este tipo de independencia se la
denomina independencia física de los datos.
Es más fácil lograr la independencia física de los datos que la lógica debido a que los programas
de aplicación dependen más fuertemente de la estructura lógica de los datos sobre la que trabajan.
Figura 1.1: Independencia de datos física y lógica
Usuario Usuario Usuario Usuario Usuario
Vista externa Vista externa Vista externa

personalizada personalizada personalizada
Barrera lógica
Vista conceptual
(tablas, etc.)
23
Barrera física
Vista fisica
Nivel interno:
Como hemos descrito anteriormente hay tres niveles de servicios de bases de datos. En el más
bajo, más alejado de las entidades de aplicación, ciertos componentes físicos organizan y
almacenan los datos que no han sido procesados. Además del hardware, estos componentes
incluyen estructuras de control que rastrean cuáles elementos de datos se encuentran en qué
discos y en qué formato. Otras estructuras aparecen aquí también para acelerar la operación,
como los búferes para retener datos de uso frecuente e información para conducir búsquedas
rápidas. La capa física por lo general tiene parámetros que pueden ser afinados para un
funcionamiento óptimo bajo las pautas de acceso de una aplicación en particular. Por tanto, el
diseñador de bases de datos puede especificar parámetros, pero los modelos más antiguos es
decir, relacionales, orientados a objetos y deductivos, comúnmente dejan la tarea de afinación al
DBMS. Si el diseñador de una base de datos tiene acceso a estas estructuras, especifica valores
apropiados en un esquema físico. Este es un segundo guión que la máquina puede leer, que indica
temas como: cuáles elementos de datos almacenar con una proximidad física por ejemplo, en la
misma pista o cilindro del disco; cómo distribuir los datos en múltiples archivos y dispositivos de
almacenamiento, y cuáles archivos distribuir al índice.
Nivel conceptual:
El aislamiento de estos detalles de almacenamiento en el nivel más bajo del DBMS proporciona un
cómodo separador para la siguiente capa de abstracción, el nivel conceptual. Los objetos de
aplicación existen a este nivel. Si el sistema operativo o el equipo básico cambia, las
consecuencias se confinan a la interfase entre la capa física y la capa conceptual inmediatamente
encima de ella. Si el diseñador de base de datos está controlando el esquema físico, puede ser
que necesite modificarlo y volver a compilarlo. En ningún caso debe volver a afinar el DBMS para
que funcione eficazmente en el nuevo entorno. En el peor de los casos, esto puede requerir la
adquisición de una nueva versión del DBMS. Por ejemplo, si cambia la plataforma de VAX VMS a
UNIX - dos sistemas operativos -, es probable que sea necesaria una nueva versión del DBMS.
Lo importante es que todas las aplicaciones construidas sobre los objetos de la capa conceptual
permanecen válidas; no resulta afectada una inversión potencialmente grande en programas de
aplicación que utilicen la base de datos.
En la capa central de la figura 1.1 se describe el entorno de aplicación completo en términos de las
abstracciones soportadas por el DBMS, tales como: tablas, objetos o reglas de inferencia. Aquí se
encuentran las entidades de interés en la aplicación, junto con sus relaciones, restricciones y
medidas de seguridad. Así como esta capa puede permanecer estable frente a cambios en la capa
de soporte físico debajo de ella, las modificaciones a esta imagen conceptual pueden ocultarse con
frecuencia del siguiente nivel mas alto.
Nivel externo:
El nivel superior del gráfico representa vistas externas personalizadas que varían de acuerdo con
la aplicación para diferentes usuarios. Por ejemplo, un programa considera que los atributos de
alumno son simplemente "nombre" y "carrera", mientras que otro espera una definición más
completa, que incluya "dirección", "teléfono" y "documento". Diferentes vistas externas pueden
usar la misma descripción conceptual para satisfacer expectativas distintas. Pero, cuando un
24
programa espera que una entidad contenga ciertos atributos, no debe resultar afectado si el
esquema conceptual cambia para agregar más atributos al objeto correspondiente de la base de
datos.
Desde luego que ciertos parámetros del sistema de administración de bases de datos (DBMS)
pueden requerir ajustes para materializar la vista externa anterior a partir de un esquema
conceptual modificado, pero el programa que utiliza la vista anterior permanece aislado del cambio.
Desafortunadamente, no es posible limitar las consecuencias de todos los cambios de esta forma.
Por ejemplo, si un atributo de una entidad se borra de una vista conceptual, entonces, a menos
que se trate de una propiedad redundante en primer lugar, es difícil que el DBMS lo materialice
para beneficio de un programa existente. En este caso, es necesario volver a escribir el programa.
A pesar de sus limitaciones, las vistas externas compensan en gran medida los cambios en el
esquema conceptual.
De acuerdo a lo leido hasta ahora responda las siguientes preguntas:
¿Qué término describe el desacoplamiento descripto en el ultimo parrafo del nivel externo ?
¿Qué concepto describe la desarticulacion de los programas de aplicación del equipo basico y
las estructuras de datos? Explique ambos
Confronte con Solucion nº 1
Los usuarios individuales que interactúan con la base de datos a través del nivel externo pueden
ser, como hemos mencionado anteriormente, programadores de aplicaciones o usuarios de
terminales en línea, es decir usuarios finales, con cantidades variables de conocimientos de
informática. El administrador de base de datos (DBA) es un caso especial importante, pero a
diferencia de los usuarios ordinarios, el Administrador de Base de Datos debe interesarse también
en los niveles conceptual e interno. Discutimos esto en la sección siguiente.
Cada usuario dispone de un lenguaje:

 En el caso de los programadores de aplicaciones, dicho lenguaje serán los lenguajes de
programación conocidos, como COBOL o PL/I, o bien un lenguaje propio más específico para
el sistema en cuestión.
 En el caso de usuarios finales serán suficientes, lenguajes de consulta, o algún lenguaje de
aplicación especial, quizá manejado mediante formas o menús, adaptado a los requerimientos
de ese usuario y apoyado por algún programa de aplicación en línea.
Pero el aspecto importante de todos esos lenguajes es que deben incluir un sublenguaje de datos,
es decir, un subconjunto del lenguaje total que se ocupe de manera específica de los objetos y
operaciones de la base de datos. Se dice que el sublenguaje de datos está inmerso dentro del
lenguaje anfitrión correspondiente. Un sublenguaje de datos cuyo uso es posible en casi todos los
sistemas relacionales actuales es el lenguaje SQL denominado Lenguaje de Consulta Estructurado
lo exploramos en unidades posteriores.
En principio, cualquier sublenguaje de datos es en realidad una combinación de, por lo menos, dos
lenguajes subordinados: un Lenguaje de definición de datos (DDL) y un Lenguaje de
manipulación de datos (DML). Veamos cada uno de ellos.
Lenguaje de definición de datos

El esquema de una base de datos se especifica mediante un lenguaje de definición de datos
(DDL). Este esquema se almacena en el diccionario de datos o catálogo del sistema.
El cual es consultado antes de actualizar una base de datos.
Lenguaje de manipulación de datos

Este lenguaje permite agregar, borrar, consultar o modificar los datos contenidos en las bases de
datos lo siguiente.
25
Existen dos tipos de lenguajes de manipulación de datos (DML).
 los procedimentales: en los que el usuario debe especificar qué datos requiere y cómo
obtenerlos.
 los no procedimentales: donde el usuario especifica sólo los datos que necesita.
Las operaciones de manipulación de datos (consulta, actualización, borrado e inserción)

generalmente se realizan a través de SQL en los DML no procedimentales. Trataremos este tema
en unidades posteriores.
Estos lenguajes de manipulación y de definición de datos fueron creados para ser utilizados por el
administrador de bases de datos, los usuarios y el sistema de administración de bases de datos
contenidos en los sublenguajes de cada aplicación que dichos usuarios utilizan. Analicemos a
continuación las tareas que desarrollan cada uno de ellos.
3.4 Administrador de bases de datos (DBA)
Además de los componentes de hardware y software ya descritos, un DBMS en funciones también

implica ciertas intervenciones humanas. Debido a que el DBMS proporciona una vista general de
los datos de aplicación cualquier cambio en la estructura debe ser cuidadosamente coordinado,
tomando en cuenta a usuarios bastante dispersos que se verán afectados por un cambio.
El administrador de bases de datos es quien controla los datos y los programas que lo acceden.
Funciones del administrador de base de datos
 definir/modificar el esquema de la base de datos;

 definir/modificar la estructura de almacenamiento y métodos de acceso;
 especificar las restricciones de integridad;
 definir las autorizaciones de acceso de los usuarios a los datos;
 supervisar operaciones de respaldo y recuperación;
 arbitrar sugerencias en conflictos de usuarios por cambios en la estructura de base de datos o
privilegios de acceso.
3.5 Sistema de administración de bases de datos (DBMS)
El DBMS es el conjunto de programas que maneja todo acceso a la base de datos. Interactúa con
el sistema operativo para almacenar y recuperar los datos almacenados; es responsable de la
integridad de los datos y de la seguridad de los mismos, del control de concurrencia, del back up y
recuperación de los datos.
A nivel conceptual, sucede lo siguiente:
1- Un usuario solicita acceso, empleando algún sublenguaje de datos determinado (por
ejemplo SQL).
2- EL DBMS interpreta esa solicitud y la analiza.
3- EL DBMS inspecciona, en orden, el esquema externo de ese usuario, el esquema
conceptual y la definición de la estructura de almacenamiento.
4- El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.
El usuario no forma parte de la arquitectura del sistema de bases de datos, sin embargo, mediante
la comunicación de datos, se conecta con esta arquitectura. La comunicación de datos necesita de
un administrador, quien se considera externo a la arquitectura.
El DBMS se comunica con el sistema operativo para grabar y recuperar datos almacenados. El
sistema operativo no forma parte de la arquitectura.
Veamos las funciones del DBMS.
26
 Definición de datos: el DBMS debe incluir componentes que interpreten los diversos lenguajes
de definición de datos y convertirlos en la versión apropiada para almacenarlos en el disco.
 Manipulación de datos: el DBMS debe atender las solicitudes de los usuarios para extraer y
actualizar datos que ya existen en la base de datos, o agregar datos nuevos.
 Seguridad e integridad de los datos: el DBMS debe controlar las solicitudes de los usuarios y
rechazar los intentos de violación de las medidas de seguridad e integridad definidas por el
DBA.
 Recuperación y concurrencia de los datos: el DBMS debe preservar el cumplimiento de ciertos

controles de recuperación y concurrencia. Analizaremos estos mismos temas mas adelante.
 Diccionario de datos: el DBMS debe incluir un diccionario de datos o catalogo del sistema para
almacenar físicamente toda la información que contiene la base de datos.
Como conclusión podemos decir que: el DBMS constituye la interface entre el usuario y el sistema
de base de datos. La interfase del usuario se define como una frontera del sistema, mas allá de la
cual todo resulta invisible para el usuario.
27
Actividades de Autoevaluación
1- Plantee un problema sobre el cual se desea implementar un sistema de base de datos.

Enumere sus aspectos importantes y elabore la estructura que debería tener esa base de
datos - tablas y atributos -.
2- ¿Que información de la base de datos desarrollada anteriormente se almacenaría en el
Diccionario de Datos?
3- ¿Cree Ud. que el nuevo sistema de base de datos implementado aportará ventajas a la
organización? ¿Cuales?
4- Enumere las ventajas y desventajas que considere comparando los diferentes modelos de
base de datos.
5- Examine cualquier sistema de base de datos asequible. Y establezca las correspondencias
entre cada uno de esos sistemas y la arquitectura descripta de tres esquemas. ¿Incluye el
sistema los tres niveles de esa arquitectura? ¿Que aspecto tienen los diversos lenguajes de
definición de datos, (externo, conceptual, interno)? ¿Cuales sublenguajes de datos permite
utilizar el sistema? ¿Quien realiza la función de administración de la base de datos? ¿Existen
medidas de seguridad? ¿Existe un diccionario?
28
Unidad II: Estructuras de almacenamiento en disco
Orientación del aprendizaje.
Un objetivo prioritario de desempeño en sistemas de bases de datos es reducir al minimo el

numeroi de accesos a disco. En esta unidad nos ocuparemos de técnicas para lograr ese objetivo,
es decir técnicas para organizar los datos almacenados en el disco de manera tal que eun elemnto
de informacion requerido se pueda realizar con un minimo de E/S. Ademas incorporamos algunos
aspectos basicos de la arquitectura de los discos para mejorar la comprension de los conceptos.
Contenidos de la unidad:
1. Definición de las estructuras de almacenamiento

3. Indización
4. Dispersión
5. Cadena de apuntadores
6. Técnicas de compresión
 Conocer las diferentes estructuras de almacenamiento y saber en que casos es

conveniente aplicar cada una.
 Entender la importancia de las estructuras de almacenamiento en una base de datos.
Esquema conceptual:
Panorama General del acceso a las bases de datos
DBMS
Manejador
de archivos
Indización
Dispersión
Manejador
de disco
Cadena de apuntadores
Técnicas de compresión
Técnicas que reducen el
numero de accesos a
Base de disco
datos
almacenada
29
1. Definición de las estructuras de almacenamiento
En el capitulo anterior destacamos las estructuras que los modelos de base de datos utilizan para
almacenar elementos de datos y mantener relaciones entre ellos. Debido a que el contenido de
una base de datos puede ser grande y a que debe continuar operando después de fallas o
interrupciones de la maquina (se vera en unidades posteriores), el sistema de administración de
bases de datos (DBMS) retiene las estructuras de las base de datos en almacenamiento
secundario, por lo general en paquetes de discos magnéticos. EL DBMS transfiere pequeñas
secciones de la base de datos a la memoria de la computadora para su procesamiento, y escribe
cualquier cambio en el disco. Desafortunadamente, un intercambio entre el paquete de datos en
disco y memoria es de tres a cinco ordenes de magnitud mas lento que la misma operación entre
dos estructuras de memoria.
La organización de disco que responde a comandos de base de datos debe reducir al mínimo los
accesos de disco requeridos. Mas adelante veremos las técnicas para organizar el
almacenamiento de datos en discos y para hallar rápidamente elementos particulares de datos en
ese almacenamiento.
EL DBMS tiene que manejar numerosos tipos de datos diferentes y por razones de eficiencia, debe
empaquetar diferentes tipos de registros en registros de archivos adyacentes. El DBMS, por tanto,
percibe un almacenamiento de disco como paginas manejables en forma individual y toma la
administración de estas paginas desde el sistema operativo. Por supuesto, las paginas almacenan
datos de aplicación pero también contienen eslabones para registros relacionados y apuntadores
para lecturas rápidas.
En esta sección examinaremos los parámetros físicos de los discos de almacenamiento, los cuales
determinan su capacidad de almacenamiento y su tasa de transferencia de datos hacia la memoria
principal y desde esta. El disco contiene una columna de platos (discos) en un husillo común. Una
delgada película uniforme de material magnético cubre la superficie de cada uno de los discos.
Cuando el diseñador almacena datos en la superficie del disco, el almacenamiento es persistente;
incluso si se corta la corriente de la unidad de disco, los datos permanecen allí, hasta que la
cabeza de grabación los estimule a cambiar. El almacenamiento persistente es fundamentalmente
diferente de la memoria de una computadora, donde los datos almacenados desaparecen cuando
se corta la corriente. El almacenamiento volátil describe un dispositivo de memoria que pierde sus
datos almacenados cuando se corta la corriente.
La superficie de cada disco contiene subdivisiones, llamadas regiones, donde el diseñador puede
almacenar de modo confiable los bytes de datos y leerlos.
Los platos están unidos rígidamente al husillo central, que los hace girar a una velocidad uniforme,
por lo general 3600 revoluciones por minuto. En la periferia de los platos que giran, esta la cabeza
de grabación, que contienen un solo sensor de lectura y escritura para la superficie de cada plato.
Un motor preciso de velocidad gradual controla el movimiento hacia adentro y hacia afuera, lo que
permite que la cabeza se detenga solo en ciertas posiciones radiales llamadas pistas. La posición
radial mas cercana al borde del plato es la pista exterior, o pista 0; la posición correspondiente a la
máxima extensión de los brazos de lectura y escritura es la pista mas interna, o pista N-1. El
numero de pistas, N, es un parámetro que determina la capacidad de almacenamiento del disco. N
es alrededor de 100 para pequeños discos flexibles y unos 1000 para unidades selladas mas
grandes.
Cada pista contiene mas subdivisiones, llamados sectores. Un sector es una extensión angular a
lo largo de una pista. El diseñador puede almacenar el mismo numero de bytes en cualquier sector,
cualquiera que sea su pista. Como la pista mas externa esta mas alejada del husillo, la magnitud
lineal de un sector es mayor que para la pista mas interna. Esta disparidad significa que las
pequeñas áreas magnetizadas que definen los bytes deben estar empaquetadas en forma mas
estrecha en la pista mas interna que en la mas externa.
Como el plato gira a una velocidad angular uniforme, el tiempo requerido para que un sector pase
bajo la cabeza de lectura y escritura es el mismo, cualquiera que sea su pista. El proceso de
30
formateo establece una posición angular fija como el principio del sector 0 (en todas la pistas) y los
demás sectores toman entonces numero s consecutivamente mas altos hasta algún limite M-1
M determina la capacidad de almacenamiento del disco, por lo general M oscila ente 20 y 50. El
numero de bytes, B, que se pueden almacenar en cada sector también varia con la unidad de
disco, pero suele ser una potencia de 2 entre el intervalos de 512 y 4096.
El ultimo parámetro necesario para determinar la capacidad de almacenamiento de disco es el
numero de superficie del plato, P. P puede variar de 1 para discos flexibles de un solo lado hasta
50 para unidades mas grandes.
La capacidad total en bytes es entonces el producto PNMB Si se toma el extremo superior de las
variaciones de parámetro, es posible calcular una capacidad de almacenamiento de 50 * 1000 * 50
* 4096 = 1010, o sea 10 gigabytes.
Un cilindro es el conjunto de pistas con el mismo numero de las diversas superficies de plato. EL
cilindro 0 contiene todas las pistas mas externas de las superficies; el cilindro N-1 contiene todas
las pistas mas internas. El concepto de cilindro es importante porque es posible tener acceso a
datos desde las pistas de un cilindro sin cambiar la posición radial de la cabeza de lectura y
escritura. Cada una de los sectores del disco tienen una dirección única en disco formada por el
numero de cilindro, el numero de superficies del disco y el numero de sector angular. Un sector
también se conoce como pagina.
Una unidad de disco contiene una pila de platos (o discos), cada una con dos superficies
para almacenamiento. Cada superficie tiene una secuencia de pistas concentricas, cada pista
tiene un numero fijo de sectores (o paginas), y cada sector tiene un numero fijo de bytes. Es
posible dirigir de manera individual cada sector (pagina) del disco.
31
Figura 2.1 Capas de administración entre el disco y un programa de usuario
Fuente: Date C. J. Introducción a los sistemas de base de datos. Volumen I. Quinta Edición. Editorial
Addison Wessley Iberoamericana
El hardware lleva a cabo todas las transferencias de datos entre la unidad de disco y la memoria
de la computadora en sectores completos. Además, las transferencias se presentan si la atención
continua del procesador central de la computadora. El procesador central da un comando al
controlador de disco, que especifica la dirección de sector, la ubicación de una memoria intermedia
y la dirección de la transferencia deseada (al disco o desde el disco). El procesador central
continua entonces con su programa mientras el controlador de disco efectúa la transferencia y
proporciona una interrupción cuando esta completa. Esta operación independiente es el acceso
directo a memoria (DMA).
El tiempo necesario para terminar una transferencia es la suma de tres retardos. Primero, las
cabezas de lectura y escritura deben moverse al cilindro apropiado, lo que generalmente toma 10
milisegundos. Este es el tiempo de localización.
La cabeza debe esperar entonces que el sector buscado gire bajo sus sensores, que en general
toma alrededor de 8 milisegundos. Este es el estado latente rotacional.
Por ultimo, la cabeza debe leer o escribir la información a medida que pasa por el sector. Este es le
tiempo de transmisión, quizá 0.5 milisegundos. Los valores dados son promedios. Las cabezas de
lectura y escritura pueden estar ya en pistas requerida, y el sector apropiado puede estar listo para
girar junto al sensor; en este caso el tiempo seria de 0.5 milisegundos para la transferencia.
Los discos mas recientes están reduciendo este valor, pero siempre estará en la escala de
milisegundos porque intervienen piezas que se mueven físicamente. Esto es casi un millón de
veces mas lento que la escala de nanosegundos para operaciones de memoria de computadora.
Un usuario incluyendo uno tan refinado como un DBMS, considera el disco como un conjunto de
archivos donde cada uno de estos contiene registros de un formato en particular. El sistema
operativo suele interponer dos niveles de abstracción entre el usuario y el medio real de
almacenamiento; el administrador (o manejador) de archivos y el administrador (o manejador) de
disco.
Administrador de Disco
Es un componente del sistema operativo que se encarga de todas las operaciones físicas de
entrada y salida E/S, por lo tanto necesita conocer direcciones físicas del disco. Por ejemplo: el
administrador de archivos solicita la lectura de una pagina especifica p, el manejador de disco
necesita saber con exactitud donde esta situada esa pagina en el disco físico. Por otro lado el
administrador de archivos no necesita conocer esta información; para el administrador de archivos,
el disco es tan solo una colección lógica de conjuntos de paginas, cada uno de los cuales se
compone de un grupo de paginas de tamaño fijo. Cada conjunto de paginas se identifica con un
identificador de conjunto de paginas único. Cada pagina, a su vez, se identifica mediante un
numero de pagina que es único dentro del disco; los diferentes conjuntos de paginas no tienen
paginas en común.
El administrador de disco entiende y mantiene la correspondencia entre números de pagina y
direcciones físicas en el disco.
Existe un conjunto de paginas llamado el conjunto de paginas de espacio libre que sirve como
reserva de paginas disponibles (no utilizadas hasta el momento); y los demás conjuntos contienen
datos. Es el administrador de disco quien se encarga de la asignación de paginas a los conjuntos y
la liberación de paginas de los mismos cuando se lo solicita el administrador de archivos.
La ventaja que posee este arreglo es que todas las instrucciones codificadas especificas para un
dispositivo pueden aislarse dentro de un solo componente del sistema, el administrados de disco; y
todos los componentes a nivel mas alto pueden ser independientes del dispositivo.
32
Administrador de Archivo:
Es un componente del sistema operativo (a veces empacado en el DBMS) que utiliza los recursos
del manejar de disco de manera tal que su usuario (el DBMS) puede percibir el disco como un
conjunto de archivos almacenados. Cada conjunto de paginas contendrá uno o mas archivos
almacenados. EL DBMS necesita saber que existen conjuntos de paginas aunque no los maneje
en detalle, en particular, necesita saber cuando dos archivos almacenados comparten el mismo
conjuntos de paginas o cuando dos registros almacenados comparten la misma pagina. Veremos
en secciones siguientes porque es útil esta información para el DBMS.
Cada archivo almacenado se identifica mediante un identificador de archivo, único dentro del
conjunto de paginas que lo contiene y cada registro almacenado se identifica mediante un
identificador de registro único al menos dentro del archivo almacenado que lo contiene.
El sistema operativo de las computadoreas suelen controlar el acceso a disco por medio de un
administrador de disco que lee y escribe paginas a peticion del administrador de archivos. Este ultimo
esta informado de cuales paginas pertenecen a que archivos y permite que un programa de aplicación
vea un archivo como un conjunto de registros con nombre. Debido a que necesita almacenar diferentes
clases de registros en el mismo archivo, el DBMS suele interactuar de manera directa con el
administrador de discos.
Agrupamiento:
La idea de agrupamiento es procurar almacenar juntos físicamente los registros que tienen una
relación lógica entre si, y que por eso se utilizan con frecuencia al mismo tiempo. Es fácil darse
cuenta por todo lo visto hasta ahora que el agrupamiento físico de los datos es un factor de
importación extrema para el desempeño.
Vamos a suponer que el registro almacenado de acceso mas reciente es r1, y que a continuación
se requiere el registro almacenado r2 Supongamos también que r1 esta en la pagina p1 y r2 esta
en la pagina p2. Entonces:
 Si p1 y p2 son una misma, el acceso a r2 no requerirá E/S física alguna, porque la pagina
deseada ya esta en la memoria principal.
 Si p1 y p2 son distintas pero cercanas físicamente, mejor si son adyacentes; el acceso a r2
requerirá una E/S física, pero el tiempo de búsqueda implicado en esa E/S será pequeño,
porque las cabezas de lectura y escritura ya estarán cerca de la posición deseada.(En
particular el tiempo de búsqueda será cero si p1 y p2 están en el mismo cilindro).
El DBMS puede hacer posible el agrupamiento, tanto dentro de un archivo como entre varios
archivos, si almacena los registros que tienen una relación lógica entre si en la misma pagina
cuando sea posible y en paginas adyacentes cuando no lo sea. (Por esta razón el DBMS debe
saber acerca de las paginas y no solo de los archivos almacenados)
Cuando el DBMS crea un nuevo registro almacenado, el administrador de archivos debe permitirle
especificar el almacenamiento del registro nuevo "cerca" de algún registro ya existente (en la
misma pagina, o en una adyacente). El DBMS solo puede saber cual agrupamiento se requiere si
el administrador de la base de datos es capaz de indicárselo.
Si desea leer mas acerca de conjuntos de paginas y archivos lea la bibliografía obligatoria
Introducción a las Bases de Datos C.J. DATE (Quinta Edición) Capitulo 3 El Nivel Interno.
Describiremos algunas técnicas mas importantes pare lograr una ruta de acceso mejor que la
secuencia física. Las técnicas que analizaremos son Indización, dispersión, cadena de
apuntadores y técnicas de compresión.
33
3. Indización:
Recuerde la base de datos del acuario, y suponga que la consulta "encontrar todos los peces que
son de color C" (donde C es un parámetro), se ejecuta con frecuencia y por ende debe tener buen
desempeño.
Con ese requisito el DBA podría elegir la representación almacenada de la figura.
En esta representación hay dos archivos almacenados; uno de peces y otro de colores. Si necesita
encontrar todos los peces anaranjados el DBMS puede optar por dos posibles estrategias:
1- Examinar el archivo peces completo, buscando todos los registros en los cuales el
valor del campo de color sea anaranjado.
2- Buscar en el archivo de colores todas las entradas de Anaranjado, y para cada una de
ellas seguir el apuntador al registro correspondiente en el archivo de peces.
Archivo de Colores (índice)
Anaranjado 
Anaranjado 
Azul 
Blanco 
Blanco 
Blanco 
Morado 
Negro 
Rojo 
Archivo de Peces (Datos)
Pnro Pnombre Pcolor ppeso Tnro snro

164 Charlie Anaranjado 12 42 74
347 Flipper Negro 25 35 17
228 Killer Blanco 32 42 22
281 Charlie Anaranjado 27 85 22
438 Albert Rojo 45 55 17
119 Bonnie Azul 51 42 22
388 Cory Morado 12 35 93
654 Darron Blanco 84 42 93
765 Elsie Blanco 73 42 22
Si la proporción de peces anaranjados es pequeña con respecto a los demás, la segunda

estrategia deberá ser mas eficiente que la primera porque a) el DBMS esta consiente del orden
fisco del archivo de colores (puede interrumpir su búsqueda tan pronto como encuentre un color
posterior a anaranjado en orden alfabético).
En este ejemplo se dice que el archivo de colores es un índice del archivo de peces, lo que
equivale a decir que el archivo de peces esta indizado por archivo de colores.
Un índice es un tipo especial de archivo almacenado. En términos específicos es un archivo en el
cual cada entrada (registro) se compone de solo dos calores, un datos y un apuntador (RID); el
datos es un valor de algún campo del archivo indizado, y el apuntador identifica un registro de ese
archivo que tiene ese valor en ese campo. El campo del archivo indizado se llama campo indizado
34
Como se utilizan los índices:
La ventaja primordial de los índices es la agilización de la obtención de datos . Sin embargo hacen
mas lenta la actualización de los archivos. Por ejemplo si añadimos un registro en el archivo de
peces es preciso agregar también una entrada al índice. Entonces ante una posible indización
según un campo dado, siempre debemos preguntarnos si es mas importante una eficiente
recuperación de datos con base en los valores del campo en cuestión, o el trabajo adicional de
actualización requerido para lograr esa eficiencia.
Los índices pueden ser utilizados de dos maneras.
 Acceso secuencial al archivo indizado: Secuencial significa en el orden definido por los valores
del campo indizado. Este acceso es útil para consultas de intervalos, por ejemplo "hallar todos
los peces cuyo color quede dentro de un cierto intervalo alfabético"; o "hallar todos los peces
cuyo color sea menor o mayor que algún valor especificado" - menor o mayor en campos
alfanuméricos se refiere al orden alfabético de los caracteres -.
 Acceso directo al archivo indizado: Este acceso es útil para consultas por listas, por ejemplo
"hallar todos los peces que son de color anaranjado, rojo y azul".
Algunas consultas solo necesitan emplear solo el índice para ser respondidas, como por ejemplo
considere la consulta "¿existen peces violetas?" La respuesta a esta consulta será afirmativa si
desde luego existe una entrada para violeta en el índice color.
Un archivo almacenado puede tener cualquier cantidad de índices, por ejemplo el archivo
almacenado de peces podría tener un índice color y un índice tanque. Estos índices podrían
utilizarse para lograr un acceso eficiente a los registros de peces con base en cualquiera de los
campos color o tanque, o ambos.
Indización según combinaciones de campos.
Supongamos la base de datos de proveedores donde los atributos son numero de proveedor,
nombre, ciudad y situación.
Es posible construir un índice con base en los valores combinados de dos o mas campos. La figura
siguiente muestra un índice del archivo de proveedores según combinación de los campos ciudad
y situación - en ese orden -. Con un índice como este el DBMS podría responder a la consulta
"hallar los proveedores cuya situación sea 30" revisando una sola vez el índice. Si se reemplaza el
índice combinado por dos índices separados, la consulta implicaría dos revisiones de índice
distintas.
Indice
CIUDAD/SITUACION
Atenas/30
Londres/20
Londres/20
Paris/10
Paris/30
Archivo de proveedores
S1 Salazar 20 Londres
S2 Jaimes 10 Paris
S3 Bernal 30 Paris
S4 Corona 20 Londres
S5 Aldana 30 Atenas
Figura 2.2 Indización del archivo proveedores según la combinación de campos

CIUDAD/SITUACION
35
Fuente: Date C. J. Introducción a los sistemas de base de datos. Volumen I. Quinta Edicion. Editorial
Indización densa y no densa.
El objetivo fundamental de un índice es reducir el número de operaciones de E/S de disco

necesarias para obtener un cierto registro almacenado. Hasta ahora hemos visto que en lo básico,
este objetivo se logra mediante apuntadores que apuntan a registros - es decir, identificadores de
registros, o RID- Pero en realidad podría alcanzarse el objetivo postulado si esos apuntadores no
fueran mas que apuntadores de paginas - es decir, números de página -. También es cierto que el
sistema tendría que realizar un trabajo adicional revisando la pagina en memoria principal para
localizar el registro deseado dentro de la pagina, pero el numero de operaciones de E/S seguirá
siendo el mismo.
Recuerde que un archivo almacenado tiene una sola secuencia "física", representada por la
combinación de a) la secuencia de registros almacenados dentro de cada pagina y b) la secuencia
de paginas dentro del conjunto de paginas al cual pertenecen. Supongamos ahora que el archivo
de proveedores esta agrupado según el campo "nro. de proveedor", vamos a suponer también que
se requiere un índice por ese campo; en este caso el índice no deberá por fuerza incluir una
entrada para cada registro almacenado en el archivo indicado solo se necesita una entrada por
cada pagina, con el numero de proveedor mas alto de la pagina y el numero de pagina
correspondiente. En la siguiente figura se muestra el ejemplo planteado.
Indice
S2
S4
S5
Archivo de proveedores
página p-1
S2 Jaimes 10 Paris
S3 Bernal 30 Paris
página p
S5 Aldana 30 Atenas
página p+1
Figura 2.3 Ejemplo de indice no denso

A esta clase de índices se los llama índices no denso o esparcido porque no contienen una entrada
para cada registro almacenado del archivo indizado.
Las ventajas que posee son 1) ocupa un reducido espacio de almacenamiento comparado con un
índice denso correspondiente; 2) por la misma razón su revisión será con toda probabilidad mas
36
rápida. La desventaja es que ya no se podrán realizar pruebas de existencia con base únicamente
en el índice.
Arboles B:
No existe una estructura de almacenamiento optima para todas las aplicaciones, pero si ha de
elegirse una sola estructura, el árbol B de uno u otro tipo es el mas conveniente ya que ofrecen un
mejor desempeño general y la mayoría de los sistemas relacionales lo incluyen como forma
principal de estructura de almacenamiento.
Comenzaremos presentando una idea del concepto de estructura de árbol o índice multinivel.
Supongamos que tenemos un archivo indizado de gran tamaño, el índice será también muy grande
y por tanto una revisión secuencial puede llegar a requerir bastante tiempo. La solución a este
problema es realizar un índice del índice, o sea tratar al índice como un archivo normal y crear un
índice para el. Esta idea puede llevarse a tantos niveles como se desee, cada nivel del índice actúa
como índice no denso del nivel inferior.
Arboles B: Un árbol B es un tipo especial de índice con estructura de árbol. Los arboles B como
tales fueron descritos por vez primera en un articulo de Bayer y McCreight en 1972. Desde
entonces, Bayer y muchos otros investigadores han propuesto gran cantidad de variaciones de
1
noción basica .
En esta materia describiremos la variación propuesta por Knuth.

En la variación de Knuth el índice tiene dos partes que describimos a continuación:
 Conjunto secuencia:
Esta formado por un índice de un solo nivel de los datos reales; este índice podría ser
denso o no denso si el archivo esta agrupado según el campo indizado. Las entradas del
índice están agrupadas en paginas y las paginas están encadenadas entre si; de esta
forma el orden lógico representado por el índice se obtiene siguiendo las entradas en orden
físico de todas las paginas de la cadena. De esta manera, el conjunto secuencial permite
un acceso secuencial rápido a los datos indizados.
 Conjunto índice:
El conjunto índice hace posible un acceso directo rápido al conjunto secuencia y por
consiguiente también a los datos. El conjunto índice es el árbol b propiamente dicho: un
índice con estructura de árbol del conjunto secuencia. La combinación del conjunto índice y
el conjunto secuencia se denomina arboles B + .
El nivel superior del conjunto índice se compone de un solo nodo (una sola pagina) y recibe
el nombre de raíz.
1
Iberoamericana
37
Figura 2.4. Parte de un árbol B sencillo
Ahora veremos un ejemplo sencillo extraído del libro de C. J. DATE Introducción a los sistemas de
Bases de Datos.
En primer lugar los valores 6, 8, 12, ..., 97,98 son valores del campo indizado, digamos C.
Examinemos el nodo superior, el cual contiene dos valores de C (50 y 82) y tres apuntadores
(numero de pagina). Los registros de datos con valores de C de 50 o menos pueden hallarse
siguiendo el apuntador izquierdo a partir de este nodo; de manera similar, los registros donde C es
mayor que 50 pero menor o igual que 82 pueden localizarse siguiendo el apuntador de en medio; y
los registros con valores de C mayores que 82 se hallaran siguiendo el apuntador derecho. Los
demás nodos del índice se interpretan de manera análoga; adviértase que si, por ejemplo,
seguimos el apuntador derecho desde el primer nodo del segundo nivel encontraremos todos los
registros con C mayor que 32 también menor o igual que 50.
Sin embargo este ejemplo ilustrado en la figura no se ajusta mucho a una situación real, por las
siguientes razones:
 No todos los nodos de un árbol B contienen el mismo numero de valores de datos.
 Y contienen por lo general una cierta cantidad de espacio libre.
Un árbol B de orden n tiene por lo menos n pero no mas de 2n valores de datos en un nodo dado -
y si tiene k valores de datos, tendrá por ende k+1 apuntadores-
El problema que presenta las estructuras de árbol en general es que las inserciones y las
eliminaciones pueden desequilibrar el árbol; esto significa que los nodos hoja no están todos en el
mismo nivel, es decir, los nodos hojas están a diferentes distancias del nodo raíz. Esto afecta
directamente a los tiempos de búsqueda, ya que por cada nodo visitado se requiere un acceso a
disco.
La ventaja notable de los arboles B es que el algoritmo de inserción/eliminación garantiza en todo
momento el equilibrio del árbol; por esta razón se asegura a veces que la B del nombre significa
balanceado.
No describiremos el algoritmo de búsqueda de los arboles B pero presentaremos un ejemplo de

cómo el proceso de inserción utiliza el algoritmo.
Supongamos que deseamos insertar un valor V en un árbol B de orden n.
38
En primer lugar, se ejecuta el algoritmo de búsqueda para localizar el nodo al cual llamaremos N
que este en el nivel mas bajo del conjunto índice al cual pertenece V por lógica. Si N contiene
espacio libre V se inserta en el y el proceso termina.
En caso contrario el nodo N, el cual contiene 2n valores se divide en dos nodos N1 y N2. Sea S el
conjunto ordenado formado por los 2n valores originales mas el nuevo valor V, en su secuencia
lógica. Los n valores mas bajos del conjunto S se colocan en el nodo izquierdoN1, los n valores
mas altos de ese conjunto se colocan en el nodo derecho N2, y el valor medio, al cual llamaremos
W, se promueve al nodo padre de N, que llamaremos P, para servir como valor separador de los
nodos N1 y N2.
En seguida se intenta insertar W en P, y el proceso se repite.
En el peor de los casos, habrá una división continua hasta el nivel mas alto del árbol; se creara un
nuevo nodo raíz, padre de la raíz anterior, la cual se habrá dividido ahora en dos, y la altura del
árbol aumentara en un nivel pero seguirá estando equilibrado.
Desde luego el algoritmo de eliminación es lo inverso del algoritmo de inserción que se acaba de
describir y la modificación de un valor se realiza eliminando el valor antiguo e insertando el nuevo.
4. Dispersión
El direccionamiento por dispersión es una técnica para obtener acceso directo rápido a un registro
almacenado especifico con base en un valor dado para un cierto campo. El campo en cuestión es
con frecuencia la clave primaria.
Describiremos como funciona la técnica:

Los registros almacenados se colocan en la base de datos en un sitio cuya dirección RID se
calcula como una función de algún campo de ese registro. La función se llama función de
dispersión, y el campo de ese registro se llama campo de dispersión o clave de dispersión. La
dirección calculada se llama dirección de dispersión.
El DBMS entonces, calcula la dirección de dispersión del nuevo registro que se desea almacenar y
ordena al administrador de archivos que lo grabe en esa posición.
Para localizar después el registro el DBMS, a partir del valor del campo de dispersión, realiza el
mismo calculo y ordena al manejador de archivos que lea el registro en la posición calculada.
Veamos un ejemplo extraído del libro de DATE
0 1 2 3 4 5
S300 Bernal 30 Paris S200 Jaimes 10 Paris
6 7 8 9 10 11
S300 Aldana 30 Atenas S100 Salazar 20 Londres S400 Corona 20 Londres
12
Figura 2.5 Ejemplo de estructura de dispersión

39
Supongamos la base de datos de proveedores donde los atributos son numero de proveedor,
nombre y ciudad.
a) los valores de los números de proveedor son S100, S200, S300, S400, S500 (en vez de S1,
S2, S3, S4, S5) y
b) cada registro de proveedor almacenado requiere toda una pagina, y examinemos la siguiente
función de dispersión:
dirección de dispersión (o sea, número de pagina) = residuo de dividir la parte numérica del
valor de S# entre 13
Este es un ejemplo de una función de dispersión de uso frecuente llamado división/residuo.
Siempre se opta por un numero primo como divisor en una dispersión de división/residuo.
Los números de pagina de los cinco proveedores serán entonces 9, 5, 1, 10 y 6, respectivamente,
dando pie a la representación mostrada en la figura 2.5.
Como habrán notado con el ejemplo la dispersión es diferente de la indización ya que un

determinado archivo almacenado puede tener cualquier cantidad de índices pero no mas de una
estructura de dispersión.
Un archivo puede tener cualquier cantidad de campos indizados pero solo uina campo de
dispersion
El ejemplo muestra que seria posible utilizar una función de dispersión de identidad, es decir,
emplear de manera directa el valor numérico de la clave primaria para cualquier registro
almacenado como dirección de dispersión; pero en la practica una técnica de este tipo casi nunca
es apropiada por que los posibles valores que puede tomar una clave primaria excede la gama de
direcciones disponibles.
El ejemplo también muestra una desventaja de la dispersión: la secuencia física de registros dentro
del archivo almacenado no será la secuencia de clave primaria, ni ninguna otra secuencia con una
interpretación lógica razonable, además puede haber espacios vacíos de tamaño arbitrario entre
registros consecutivos.
Otra desventaja de la dispersión en general es la posibilidad de colisiones, es decir, que dos o mas
registros produzcan la misma dirección de dispersión. Imagine que sucedería si aumentara el
tamaño del archivo disperso, crece la cantidad de registros por consiguiente crece también el
numero de colisiones y el tiempo promedio de acceso aumenta ya que se invierte cada vez mas
tiempo examinando conjunto de colisiones. A veces se llega a situaciones donde es mas
conveniente descargar el archivo existente y volverlo a cargar utilizando una nueva función de
dispersión.
Para el ejemplo planteado piense en una función de dispersión que genere colisión con algunos
valores determinados.
Dispersión Extensible:
La dispersión extensible es una ingeniosa variación de la idea básica de la dispersión que presenta
soluciones a las desventajas planteadas; de hecho garantiza que el numero de accesos a disco
necesarios para localizar un registro especifico nunca sea mayor que 2 y por lo general resulta en
uno.
Ejemplo tomado del libro de DATE

Sea h la función básica de dispersión, y sea k el valor de clave primaria de un registro especifico r.
La dispersión de k -–es decir la evaluación de h(k)- produce un valor s llamado seudoclave de r.
Las seudoclaves no se interpretan directamente como direcciones sino que mas bien conducen a
los sitios de almacenamiento en forma indirecta, como se describe a continuación.
Existe un directorio asociado al archivo almacenado, grabado también en el disco. El directorio
testa formado por una cabecera, donde se encuentra el valor j llamado profundidad del directorio,
junto con 2f apuntadores . Estos apuntan a paginas de datos las cuales contienen los registros
almacenados reales (varios en cada pagina). Así, un directorio de profundidad f puede manejar un
archivo con un tamaño máximo de 2f paginas distintas de datos.
40
Figura 2.6. Ejemplo de dispersión extensible
Si consideramos a los primeros f bits de una seudoclave como un entero binario sin signo, b,
entonces el iesimo apuntador en el directorio (1<=i=2f) apunta a una pagina donde están todos los
registros para los cuales b adopta el valor i-1. Dicho de otro modo el primer apuntador apunta a la
página donde están todos los registros para los cuales b se compone solo de ceros, el segundo
apunta a la pagina en la cual b es 0...01, etcétera. Así si deseamos localizar el registro cuyo valor
de clave primaria es k, se dispersará k a fin de encontrar la seudoclave s y tomaremos los primeros
f bits de esa seudoclave; si esos bits tienen el valor numérico i-1 pasaremos al iesimo apuntador en
el directorio (primer acceso a disco) y lo seguiremos a la pagina donde esta grabado el registro
requerido (segundo acceso a disco).
Si desea profundizar mas sobre este tema dirigirse a la bibliografía.
5. Cadena de Apuntadores:
Supongamos que la consulta “hallar todos los proveedores de la ciudad C” es importante. En la

sección anterior resolvimos con un índice un tipo de consulta similar sobre la base de datos del
acuario la consulta era “hallar los peces que son de color anaranjado”. Empleando cadenas de
apuntadores la consulta se podrá manejar, inclusive mejor, que con indización.
41
Archivo
Atenas  Londres  Paris  CIUDAD
S1 Salazar 20  S2 Jaime 10  S3 Bernal 30  S4 Corona 20  S5 Aldana 30 
Archivo
PROVE-
EDORES
Figura 2.7. Ejemplo de estructura padre/hijo

La figura muestra dos archivos almacenados uno de proveedores y otro de ciudades; pero el
archivo de ciudades no es un índice, sino lo que en ocasiones se denomina archivo padre, en
consecuencia el archivo de proveedor se denomina archivo hijo, y la estructura general es un
ejemplo de organización padre/hijo.
La estructura padre e hijo tiene su base en los valores de ciudad de los proveedores. El archivo
padre de ciudades contiene un registro almacenado para cada ciudad distinta donde hay
proveedores, el cual incluye el valor de la ciudad y funciona como inicio de una cadena o anillo de
apuntadores que liga todos los registros hijos de los proveedores residentes en esa ciudad. Si
desea localizar todos los proveedores de Londres, por ejemplo , el DBMS puede buscar la entrada
de Londres en el archivo de ciudades y desde ahí seguir la cadena de apuntadores
correspondiente.
La ventaja principal de esta estructura reside en una mayor sencillez de los algoritmos de inserción
y eliminación con respecto a los algoritmos correspondientes de un índice. Otra ventaja es que la
estructura ocupara con toda probabilidad menor espacio de almacenamiento que la estructura de
índice correspondiente, porque cada valor de ciudad aparece una sola vez no varias.
Una desventaja es si por ejemplo los registros de proveedores no estas agrupados de manera
adecuada, y cada acceso implica una operación de búsqueda por parte de la cabeza de lectura, el
tiempo requerido para obtener el enésimo proveedor puede ser considerable.
Otra desventaja es que la estructura es adecuada para consultas especificas, por ejemplo si bien
es adecuada para “hallar los proveedores de una ciudad dada”, resulta definitivamente un
obstáculo si la consulta es opuesta: “hallar la ciudad de un proveedor dado”. Lo mas apropiado en
este ultimo caso seria una dispersión o bien un índice sobre el archivo de proveedores.
Existen muchas variaciones posibles de la estructura padre/hijo. Por ejemplo:

 Los apuntadores podrían ser bidireccionales
 Se podría incluir un apuntador al padre directo de cada registro hijo al registro padre
correspondiente.
 Otra variación sería no eliminar el campo de ciudad del archivo de proveedores sino repetir ese
campo en los registros de proveedor.
6. Técnicas de Compresión:
42
Las técnicas de compresión son métodos para reducir el espacio de almacenamiento requerido por
un conjunto dado de datos almacenados. Esto significa no solo que ahorraremos espacio de
almacenamiento, sino también se reducirá el numero de operaciones de E/S; pues si los datos
ocupan menos espacio, se requerirá menos operaciones de E/S para tener acceso a ellos. No
abordaremos esta técnica tan especifica por lo que si desea profundizar por su cuenta consulte a
su tutor o visite sitios de interés específicos de bases de datos tales como: www.oracle.com;
www.ibm.com/db2; etc.
Aclaración: Estos sitios propuestos son empresas que han desarrollado aplicaciones para el
manejo de sistemas de bases de datos relacionales específicamente. A lo largo de esta guía
veremos algunas características generales, que dependiendo de la base de datos que utilice podrá
tener algunas sutiles diferencias. Citamos Oracle y DB2 de Ibm porque son las mas fuertes en el
mercado.
¿En qué casos utilizaría cada una de las estructuras de almacenamiento arriba descriptas? Plantee
un caso practico y justifique.
43
Actividades de autoevaluación
1. A su entender, ¿que debe tener en cuenta a la hora de elegir una estructura de datos
determinada para su base de datos? Enumere las situaciones que considera importantes y con
que estructura de datos las resolvería.
44
Unidad III: Bases de Datos Relacionales
Orientación del aprendizaje:
El modelo relacional establece como representar los datos. Se basa en estructuras simples, las
relaciones, en las que los datos son representados en estructuras uniformes y guardan cierta
relación entre si de manera de describir algún evento o alguna entidad. Introducimos estos
conceptos presentando un ejemplo simple, mostrando además que cualquier situación de la vida
real puede ser modelada para luego ser almacenada en una base de datos.
El modelo relacional se ocupa de la estructura, la integridad y la manipulación de los datos, en esta
unidad nos concentraremos en la estructura y la integridad.
Presentamos los componentes del modelo relacional y estudiamos la naturaleza de las relaciones
entre elementos de datos.
Utilizamos un diagrama de entidad-relacion que representa los componentes del modelo
- entidades, atributos, relaciones, etc. - de una forma sencilla y clara.
Contenidos de la materia:

2. Elementos del modelo relacional
3. Relaciones binarias
3.1 Relaciones de una a muchas
3.4 Relaciones una a una
4. Relaciones de grado superior
5. Relaciones recursivas
6. Restricciones de integridad
45
Esquema conceptual:
usuarios
arrays cursores
SQL
VISTA VISTA
Real
tabla tabla tabla tabla

base base base base Representacion
de un caso real
tabla tabla tabla tabla

base base base base
Almacenado
base de datos
almacenada
46
 Conocer que es el Modelo Relacional y cual es su alcance.

 Incorporar el Modelo Relacional como herramienta para la representación de los datos.
 Identificar las diferentes relaciones entre las entidades dentro del modelo relacional
 Aprender a modelar los datos y relaciones simplificando el modelo.
 Reconocer el valor de las restricciones de integridad.
Un modelo de base de datos describe una estructura para almacenar y manipular información en
una base de datos. En el modelo relacional, una base de datos es un conjunto de tablas, cada una
de ellas estructuralmente semejantes a un archivo de longitud fija. Debido a este conocido formato,
el modelo relacional es accesible a una amplia variedad de usuarios no técnicos.
El modelo relacional además estudia la naturaleza de las relaciones entre elementos de datos e
introduce el diagrama entidad-relación como herramienta estándar para describir relaciones
Ejemplo: Base de datos de Acuario de acuerdo con el Modelo Relacional:
Especies
Snro snombre salimento

17 Delfin Arenque
22 Tiburon Cualquier cosa
74 Olomina Gusano
93 Tiburon Mantequilla de cacaguate
TANQUE
tnro tnombre Tcolor tvolumen
55 Charco Verde 200
42 Letrina Azul 100
35 Laguna Rojo 400
85 Letrina Azul 100
38 Playa Azul 200
44 Laguna Verde 200
PEZ
Pnro Pnombre pcolor ppeso tnro snro
164 Charlie anaranjado 12 42 74
347 Flipper negro 25 35 17
228 Killer blanco 32 42 22
438 Albert rojo 45 55 17
119 Bonnie azul 51 42 22
388 Cory morado 12 35 93
654 Darron blanco 84 42 93
765 Elsie blanco 73 42 22
438 Fran negro 61 55 74
277 George rojo 33 42 93
911 Helen azul 48 44 74
104 Indira negro 19 42 17
302 Jill rojo 28 38 17
419 Kilroy rojo 49 55 74
47
EVENTO
enro Pnro efecha edescripcion

3456 164 26/01 Incubado
6653 347 14/05 Nacido
5644 347 15/05 Nadando
5645 347 30/05 Tomar pez de entrenador
6789 228 30/05 Incubado
5211 281 30/04 Incubado
6719 483 23/05 Nacido
6720 483 25/06 Doble Longitud
9874 119 30/06 Incubado
9875 119 22/07 Alimento monopolizado
2176 388 05/08 Incubado
2285 654 04/02 Incubado
2874 765 08/02 Incubado
3116 438 19/04 Incubado
3651 277 25/09 Incubado
3884 911 02/10 Incubado
3992 104 12/11 Nacido
4004 302 25/12 Nacido
5118 419 04/16 Incubado
Las entidades de interés en este ejemplo son tanques, peces, especies, junto con los eventos que
marcan la vida de determinado pez, como el nacimiento, alimentos y enfermedades. Cada
instancia de una entidad exhibe un cierto conjunto de características. Cada tanque tiene un numero
particular, nombre, volumen y color.
La aplicación requiere tres relaciones:
La primera asocia cada pez precisamente con un tanque, aquel en el que vive.
La segunda relación agrupa cada pez exactamente con una especie, aquella que
representa.
Y la tercera asocia cada evento precisamente con un pez.
Mediante el uso de abreviaturas adecuadas para las características, las cuatro tablas del ejemplo
modelan el acuario como una base de datos relacional.
Observe los valores de las columnas de las tablas.

No hay dos filas de la tabla del tanque que tengan el mismo valor en la columna tnro. Lo mismo
se cumple de snro en la tabla Especie, pnro en la tabla Pez, y enro en la tabla Evento. Estos
nombres de características son abreviaturas de numero de pez, numero de tanque, etc. La
característica única del valor de tnro le permite servir como breve identificador de su fila y, por
extensión del particular tanque perteneciente a la fila. Del mismo modo, un valor snro identifica
solo a una especie, y un valor pnro determina un pez en particular.
Entonces el tanque cuyas características son tnro =42, tnombre=letrina, tcolor=azul,
tvolumen=100 es precisamente el mismo tanque identificado simplemente por tnro = 42.
Ninguna otra característica de la tabla del tanque tiene este poder de identificación. Hay varios
tanques con tnombre= letrina, varios con tcolor= azul, y varios con volumen tvolumen=100.
De hecho, ninguna combinación de características sin incluir a tnro, tiene el poder de identificar
un tanque único porque varias letrinas azules tienen un volumen de 100.
Cuando el valor de una característica determina una fila única en una tabla, la característica es una
llave o clave para la tabla. A veces es necesario especificar los valores de un grupo de
características para determinar una fila única de la tabla, en ese caso el grupo de características es
la llave.
La tablas capturan toda la información pertinente acerca de la aplicación del acuario. Para
demostrar este punto debemos poder responder ciertas preguntas acerca del acuario utilizando las
tablas: Por ejemplo: ¿cuáles son los colores de los tanques llamados laguna? ¿Cuántos tanques
azules tienen un volumen de 200? Para preguntas mas complicadas debemos relacionar la
información de varias tablas.
48
Las tablas contienen información que relaciona peces y sus tanques. Aun cuando cada pez nada
en un solo tanque, un determinado tanque contiene muchas peces. Para expresar esta relación de
una para muchas, el tnro del tanque base aparece como característica en cada fila de pez.
Recuerde que tnro especifica de manera única un tanque en particular .
Cuando la llave de una tabla remota participa como característica de otra tabla, es una llave
externa de la tabla huésped. Nótese que tnro no es una llave de la tabla de peces porque no
posee poderes de identificación; varias filas tienen el mismo valor de tnro en la tabla de peces.
En lugar de esto tnro es una llave externa en la tabla de peces que se refiere a la llave tnro de la
tabla de tanques. Del mismo modo la llave externa snro de la tabla de peces se refiere a la llave
snro de la tabla especies, manteniendo así la relación entre cada pez y su especie. Y por ultimo
una fila de la tabla de eventos conecta precisamente con una fila de peces por medio de la llave
externa pnro de la tabla de eventos.
El ejemplo del acuario deja ver la estructura verdaderamente sencilla de una base de datos
relacional. Además de ofrecer un esquema intuitivamente obvio para almacenar relaciones, las
tablas se asemejan a conocidos archivos de registros de longitud fija. Esto es cada fila
corresponde a un registro del archivo, y cada característica corresponde a un campo dentro del
registro.
Piense en una situacion de la vida cotidiana y representela de acuerdo con el modelo

relacional.
2. Elementos del Modelo Relacional
El Modelo Relacional tiene tres partes principales, que tiene que ver con la estructura de datos, la
integridad de los datos y la manipulación de los datos. Cada parte tiene su propia terminología
especial. Los términos estructurales mas importantes los ilustramos en el siguiente ejemplo:
Figura 3.1: La relación Tanque
tnro tnombre tcolor tvolumen
-------- ------ Rojo --------

--------
------ Verde, -------- Dominios
Clave
Primaria C
a
tnro tnombre Tcolor tvolumen r
d
Relación 55 Charco Verde 200 I
42 Letrina Azul 100 Tuplas n
35 Laguna Rojo 400 a
85 Letrina Azul 100 l
i
d
a
d
Atributos
Grado
Fuente: C.J.Date Introducción a los Sistemas de Bases de Datos
49
 Una relación corresponde a lo que hasta ahora hemos llamado en general tabla
 Una tupla corresponde a una fila de esa tabla y un atributo de una columna. El numero de
tuplas se denomina cardinalidad y el numero de atributos se llama grado.
 Un atributo es un par ordenado (N, D), donde N es el nombre del atributo y D es el dominio
asociado.
 La clave primaria es un identificador único para la tabla; es decir una columna o combinación
de columnas con la siguiente propiedad: nunca existen dos filas de la tabla con el mismo valor
en esa columna o combinación de columnas
 Un dominio es una colección de valores de los cuales uno o mas atributos (columnas) obtienen
sus valores reales. Por ejemplo, el dominio marcado con tnro en el gráfico es el conjunto de
todos los numero de tanque legales, y el conjunto de valores que aparecen en el atributo tnro
de la relación Tanque en cualquier momento es algún subconjunto de ese conjunto.
Dominios:
Los dominios proporcionan los elementos de datos para poblar las celdas de una tabla. Definimos
un dominio como un conjunto de valores escalares, todos del mismo tipo. Los valores escalares
representan "la menor unidad semántica de información" en el sentido de que son atómicos; no
poseen estructura interna; no se pueden descomponer desde el punto de vista del modelo.
Por ejemplo: el dominio de números de tanques es el conjunto de todos los enteros mayores que
cero y menores que 10.000 (por fijar un numero máximo). Los dominios son fondos de valores, de
los cuales se extraen los valores reales que aparecen en los atributos. Cada atributo debe estar
definido sobre uno y solo un domino; lo que significa que los valores de ese atributo deben
proceder de ese dominio.
Por ejemplo tanto el atributo de numero de tanque de la relación Tanque (Tanque. tnro) como el
atributo de numero de tanque de la relación Pez (Pez. tnro) se definirán sobre el dominio de
numero de tanque porque ambos atributos representan desde luego números de partes
La importancia fundamental de definir dominios es que restringen las comparaciones. Veremos
mas adelante en la parte manipulativa del modelo como son necesarios los dominios para poder
obtener datos de la base de datos realizando comparaciones entre atributos de las relaciones.
Los dominios pueden estar o no almacenados de manera explícita en la base de datos como
conjuntos reales de valores; pero en la mayor parte de los casos no será así. Sin embargo deberán
al menos especificarse como parte de la definición de la base de datos; y cada definición de
atributo debería incluir una referencia al dominio correspondiente, con el objetivo de que el sistema
pueda saber cuales atributos son comparables entre si y cuales no.
Dominios compuestos:
Un dominio compuesto no es mas que la concatenación de dominios simples.
Defina una relacion que posea al menos un dominio compuesto.
Tabla de referencia de Dominios
atributos dominios descripción

(Tnro,Z) Z Números enteros
(tnombre, S) S Cadena de caracteres
(tcolor, TC) TC (rojo, azul, verde, amarillo)
(tvolumne, TV) TV (100,200,300,400)
Relación:
50
Una relación R sobre un conjunto de dominios D 1 , D 2 , D 3 , ....D n se compone de dos partes: una
cabecera y un cuerpo
La cabecera esta formada por un conjunto fijo de pares atributo-dominio.

{(A 1 :D 1 ), (A 2 :D 2 ), .... (A n :D n )}
tales que cada atributo Aj corresponde a uno y solo uno de los dominos subyacentes
Dj (j=1, 2, ...n)
El cuerpo esta formado por un conjunto de tuplas, el cual varia con el tiempo. Cada tupla a su vez
esta formada por un conjunto de pares atributo-valor
{(A 1 :vi 1 ), (A 2 :vi 2 ), .... (A n :vi n )}
(i=1,2,....m, donde m es el numero de tuplas del conjunto). En cada una de estas tuplas hay uno de
estos pares atributo-valor (A j :v ij ) para cada atributo A j de la cabecera. Para cada par atributo-valor
(A j :v ij ), v ij es un valor del dominio único D j asociado al atributo A j . 1
Los valores de m y n se llaman cardinalidad y grado, respectivamente, de la relación R. La

cardinalidad varia con el tiempo pero el grado no .
Propiedades de las Relaciones: DATE
Las propiedades de las relaciones vienen dadas por la definición del termino "relación"
presentamos brevemente cada una de ellas:
 No existen tuplas repetidas:
El cuerpo de una relación es un conjunto matemático (conjunto de tuplas) y todo conjunto

matemático por definición no incluye elemento repetidos.
En el libro de C.J. Date se marca una continua diferencia entre tabla y relación; esta primera
propiedad marca esa diferencia ya que una tabla (en general) puede contener filas repetidas ya
que no posee una disciplina que evite tal situación, pero una relación no puede por definición
contener tuplas repetidas, ya que en una relación siempre existe una clave primaria.
Si las tuplas son únicas es evidente que si combinamos todos los atributos de la relación
mantendremos la propiedad de unicidad por lo que la combinación de todos los atributos puede
servir (si fuese necesario) de clave primaria. Profundizaremos mas adelante el concepto de clave
primaria
 Las tuplas no están ordenadas (de arriba hacia abajo)
Seguimos citando las bases de los conjuntos matemáticos: El cuerpo de una relación es un
conjunto matemático, y los conjuntos en matemática no son ordenados. Por o tanto no podemos
señalar "la quinta tupla", o "la tupla nro. 30" de una relación ni tampoco "la primera o la siguiente
tupla"; no podemos darle una posición a una tupla determinada.
Continuamos marcando las diferencias con una tabla, ya que las filas de una tabla poseen un
orden obvio de arriba hacia abajo.
 Los atributos no están ordenados (de izquierda a derecha)
La cabecera de una relación también se define como un conjunto : Conjunto de pares atributo-
dominio. Supongamos la relación PEZ , sus atributos también podrían presentarse en el siguiente
orden pnombre, pcolor, pnro, snro, enro, ppeso y seguiría siendo la misma relación.
Así que no podemos hablar del primer atributo o del ultimo; y no existe o no debería existir forma
de "saltar" de un atributo a otro.
Las columnas de una tablas tienen un orden de izquierda a derecha pero los atributos de una
relación no.
1
Iberoamericana
51
 Todos los valores de los atributos son atómicos
Todos los valores de los atributos simples son atómicos, si existieran atributos compuestos, estos
son una concatenación entre atributos simples.
Esto significa que en cada posición de fila y columna dentro de la tabla, siempre existe un solo
valor, nunca una lista de valores.
Tipos de Relaciones:
Relaciones Base: Son aquellas entidades de la aplicación que tienen realmente importancia y el
diseñador de la base de datos ha decidido darles un nombre y hacerlas parte directa de la base de
datos en si. Una relación base corresponde al concepto de tabla base den SQL.
Vistas: Son relaciones virtuales, con nombre, que se definen en termino de otras relaciones con
nombre. A diferencia de las relaciones base, no poseen datos almacenados propios
Instantáneas: Una instantánea (snapshot) es también una relación derivada, con nombre, como
una vista. Pero las instantáneas son reales no solo están representadas por su definición en
términos de otras relaciones con nombre, sino que posee datos almacenados propios. La creación
de una instantánea es muy similar a la ejecución de una consulta excepto que:
El resultado de esa consulta se almacena en la base de datos con el nombre especificado.
En forma periódica la instantánea se actualiza, se desecha su valor actual, se ejecuta de nuevo la
consulta y se toma como valor actual de la instantánea el nuevo resultado.
Resultados de Consulta: Es la relación final resultante de alguna consulta especificada. Los

resultados de consulta no tienen existencia persistente dentro de la base de datos propiamente
dicha.
Resultados Intermedios: Un resultado intermedio es una relación resultante de alguna expresión

relacional anidada dentro de alguna otra expresión relacional mas grande. Profundizaremos estas
relaciones en capítulos posteriores.
Relaciones Temporales: Es una relación con nombre, similar a una relación base, vista o
instantáneas, pero se destruye en forma automática en algún momento apropiado por ejemplo
cuando termina una sesión. Las relaciones base, vistas e instantáneas son mas permanentes, en
cuanto a que solo se destruyen como resultado de alguna acción explícita del usuario.
Tome las relaciones del punto 1 e identifique cada una de sus elementos. Y además defina dos
dominios posibles para cada atributo de cada relación.
3. Relaciones Binarias:
El esquema de una relación representa una entidad genérica de la aplicación mientras que el
cuerpo de la relación contiene instancias especificas de esa entidad. El cuerpo de una relación
cambia a medida que cambia la situación del mundo real del acuario. Debido a que una relación es
una representación dentro del modelo de una entidad externa de la aplicación, utilizaremos los
términos con el mismo significado. Por ejemplos no referiremos a la entidad tanque o a la relación
tanque, esta convención será particularmente útil en el análisis de las relaciones “Relaciones entre
relaciones” suena bastante complejo por lo que “Relaciones entre entidades” es mas atractivo.
52
Una relación (entidad) capta dos aspectos de una entidad de aplicación: una descripción genérica
mediante el esquema, e instancias especificas en el cuerpo. Del mismo modo, una relación tiene
una forma general, e instancias especificas.
La forma de relación entre las entidades de peces y tanque es aquella donde cada pez tiene un
tanque sede.
Una instancia de esta relación es una agrupación de un tanque con todos los peces que ocupan el
tanque. A medida que en el acuario se agregue o retire peces en particular, cambia la instancia de
relación, pero la forma general permanece fija como el concepto de ocupación. El termino relación
se refiere a la forma y el termino instancia de relación se refiere a una agrupación en particular que
se ajusta a la forma.
Dentro de la base de datos estas agrupaciones están formadas de tuplas, para la relación tanque-
peces. Cada agrupación contiene una tupla de tanque, más cero, una o más tuplas de peces.
Dentro de una agrupación el atributo tnro de cada tupla de peces contiene el mismo valor que el
atributo tnro del tanque. Los valores iguales en este atributo común marcan los miembros del
grupo.
El grupo no necesita mas estructura para almacenar el hecho de que estos peces en particular
están relacionados con este tanque particular en el sentido de “peces viven en tanque”.
Se pueden describir todas las relaciones de esta manera. Una relación es una conexión definida
por aplicaciones entre varias entidades. Una instancia de relación es una agrupación “significativa”
en términos de la aplicación.
En el gráfico también se ilustra un ejemplo de la relación especie-pez, en la que la forma general
es “pez representa especie”. Todas las tuplas de peces dentro de una agrupación de instancia
representan a la misma especie, esto es, a la única tupla de especie del grupo. El valor snro
común entre todas las tuplas mantiene unido al grupo. Note que las agrupaciones de instancia de
diferentes relaciones se pueden traslapar. En el gráfico este traslape simplemente significa que
algunos de los peces que nadan en uno de los tanques letrina son de una variedad de tiburón, pero
dos agrupaciones de instancia de la misma relación no se pueden intersecar.
Una relación es una conexión especifica de la aplicación entre varias entidades. Una instancia de
relación es una agrupación significativa de tuplas de las entidades participantes que ejemplifica la
conexión.
Una relación es binaria cuando conecta precisamente dos entidades.
3.1 Relaciones de una a muchas:
Los ejemplos de relación considerados antes son relaciones binarias, de una a muchas. Una
relación es binaria cuando conecta precisamente dos entidades. Una relación binara es de una a
muchas cuando cada agrupación de instancia contiene una sola tupla proveniente de una de las
entidades, junto con una multitud de tuplas de la otra.
Ejemplo:
Cada tanque se relaciona con muchos peces, en el sentido que "pez habita en tanque", y cada pez
se relaciona con muchos eventos, en el sentido de "pez experimenta evento
En la figura 3.2 se ilustra la forma en que un tanque actúa como el "padre" de muchos peces, cada
uno de los cuales sirve como padre de muchos eventos.
53
Figura 3.2 : Cascada de relaciones de una a muchas
Una relación implicada conecta tanques y eventos. Un evento particular se asocia precisamente
con un tanque, aquel que contiene los peces que experimentaron el evento. Esta relación no tiene
una representación explícita con atributos comunes porque tnro no aparece en las tuplas de
evento; pero las agrupaciones de relaciones se pueden recuperar, en cualquier dirección, si se
procesan los peces intermedios. Por ejemplo: se pueden obtener las fechas de todos los eventos
que ocurran en tnro = 42 mediante el uso de la relación peces-tanque para visitar cada pez del
tanque. Y luego nos detenemos en cada pez para hacer una excursión a los largo de las
agrupaciones de pez-evento de ese pez, acumulando valores de efecha de los eventos
Una relacion binaria es aquella en la que intervienen dos entidades. Una relacion de muchos a uno es
una relaicon binaria, en la que hay una entidad dominante distinguida y una entidad no dominante o
dependiente.
Una tupla de la entidad dominante recibe el nombre de tupla dominante y la tupla de la entidad no
dominante recibe el nombre de tupla no dominante.
Cada instancia de relación agrupa exactamente una tupla dominante con cero, una o mas tuplas
no dominantes. Dentro de cada instancia la tupla dominante posee las tuplas no dominantes en
algún sentido definido por la aplicación. Existe solo una instancia de relación por cada tupla de la
entidad dominante.
Cada tupla no dominante aparece cuando mucho en una instancia y por tanto se asocia con una
tupla dominante a lo sumo.
Una tupla no dominante podría no participar en ninguna agrupación de relación, sin embargo si
participa, debe aparecer solo en una agrupación.
54
Por contraste una tupla dominante se asocia con una multitud de tuplas no dominantes, todas las
tuplas no dominantes de su grupo.
Supongamos que tenemos una relación binaria pero no podemos identificar ninguna relación como
dominante. Esta relación se cumple entre especies y tanques por medio de la forma de aplicación
"especie esta representada en tanque". Un tanque en particular puede alojar muchas especies, y
una especie en particular aparece en muchos tanques por medio de una multitud de peces.
Ninguna entidad desempeña el papel dominante como se define en el caso de una a muchas.
Debido a que una especie se asocia con muchos tanques y un tanque se asocia con muchas
especies, esta relación recibe el nombre de muchas a muchas.
Note que la relacione especie-tanque ya esta representada de manera indirecta en la base de
datos del acuario por medio de las relaciones existentes de una a muchas peces-especie y peces-
tanque.
Consideremos otro ejemplo, donde no este presente una representación indirecta. Supongamos
que en un club de yates participan solo botes y marineros. La relación entre botes y marineros es
"marinero ha navegado en bote" . Cada bote se asocia con muchos marineros y cada marinero se
asocia con muchos botes; es una relación intrínseca de muchos a muchos.
Una instancia de esta relación bote-marinero es una agrupación significativa de tuplas de bote y
tuplas de marinero, que claramente indica cuales marineros han navegado en que botes y
viceversa.
Ahora intentemos construir esta agrupación.
Al imitar las formas de agrupación de una relación de una a muchas, se comienza con una tupla de
bote y luego se agregan todos los marineros que hayan navegado en ese bote. Ahora, escogiendo
una de estas tuplas de marinero, se observa que este marinero ha navegado en otros botes de
modo tal que se extiende la agrupación para incluir todos los botes en los que este marinero haya
navegado; pero la construcción falla en este punto porque un bote recién agregado no esta
necesariamente relacionado con los otros marineros que se agregaron en el primer paso. Esta
posibilidad permite que un bote en la misma agrupación de instancias con un marinero que no
navego en el.
En la figura 3.3 se ilustra el proceso y su potencial falla. El bote sea sprit (duende del mar) inicia la
agrupación, que se extiende para incluir a los marineros alfred y bernice. Entonces se agrega el
bote calypso porque alfred lo navego; pero bernice no. Por lo tanto calypso debe excluirse del
grupo. Esto resulta en la situación contradictoria de que calypso debe esta en el grupo por una
razón pero debe excluirse por otra.
55
Alfredo navega en el Calypso y en el Sea Sprite
Bernice navega en el Sea Sprite y en el Tempest
Figura 3.3: Algunas dificultades al construir una instancia de una relación de muchas a muchas
Note que las agrupaciones de instancias de una relación de muchas a muchas son pares, donde
cada par contiene una tupla de cada entidad. Como se ve en la figura 3.4, se comparte una gran
cantidad de tuplas entre los pares. Ciertas tuplas no participan de los pares, situación esta que es
permisible porque ciertos botes puede ser que nunca hayan navegado con tripulación, y ciertos
marineros pude ser que nunca hayan navegado en un bote.
56
Figura 3.4: Representación de una relación muchas a muchas
Una relación muchas a muchas es una relación binaria para la cual los ejemplos son pares de
tuplas. Cada par contiene dos tuplas, una de cada entidad participante.
Pero ahora ¿cómo se expresan los pares de relación en la base de datos? En el ejemplo de bote-
marinero podría considerarse incrustar una referencia dentro de una tupla determinada de
marinero a los botes relacionados. Este método no funciona porque el marinero puede estar
relacionado con mas de un bote. Supongamos que la referencia incrustada es bnro. Ahora
recordemos que el contenido de una tupla de marinero es un conjunto de asociaciones, una
asociación por cada atributo. Cada asociación toma en cuenta el nombre del atributo y
exactamente un valor del dominio de atributos. No se toman en cuenta valores múltiples, de
manera que el atributo bnro incrustado en la relación del marinero puede contener solo un bote
por tupla de marinero. En consecuencia este método no puede expresar la situación donde el
marinero esta relacionado con muchos botes.
La atomicidad es la restricción que requiere que cada asociación dentro de una tupla contenga
exactamente un valor del dominio. En términos de tablas, la atomicidad expresa que la entrada de
cada celda debe ser un solo valor del dominio del atributo situado a la cabeza de la columna.
¿Cómo es que el modelo relacional representa las relaciones de muchas a muchas?
Desafortunadamente, el modelo relacional no puede representar directamente relaciones de
muchas a muchas. Aun cuando esta restricción parece ser una deficiencia seria, de hecho no lo es.
57
Una técnica estándar puede descomponer una relación muchas a muchas en una situación
equivalente que contenga dos relaciones de una a muchas.
Figura 3.5: Fatorización de la relación bote-marinero en relaciones una a muchas

En la figura 3.5 se aprecia una imagen mas sugerente de la relación bote-marinero. Debido a que
las agrupaciones de relaciones son pares que contienen un bote y un marinero, se puede expresar
la relación al tabular esos pares e incluyendo la tabla resultante en la base de datos. Este método
es perfectamente legal dentro de la definición de una base de datos relacional porque no introduce
nuevos tipos estructurales, solo una nueva tabla. Resulta un termino técnico porque las tuplas de la
nueva tabla contienen pares bote-marinero. En otras palabras, hay dos atributos, el primero
destinado a contener un bote, y el segundo un marinero. Pero los valores de atributo deben ser
tomados de ciertos dominios especificados, y por tanto no pueden ser botes y marineros que son
tuplas completas por si solas; pero se puede usar un nuevo valor clave para representar cada
tupla. Recordemos que una clave es un atributo cuyo valor identifica de manera única a una tupla.
Si se supone que bnro y snro son llaves de las relaciones base bote y marinero respectivamente,
se pueden expresar instancias de la relación bote-marinero al tabular pares (bnro, snro).
La nueva tabla es la relación de intersección. Es el resultado de factorizar la relación bote-marinero

de muchas a muchas en dos relaciones una a muchas. En la figura 3.5 aparecen instancias de las
relaciones una a muchas en forma descompuesta. Una tupla de la relación de bote se asocia con
58
las tuplas de intersección que lleven el mismo valor bnro, lo que constituye por consiguiente una
instancia de la relación deducida una a muchas entre bote e intersección. Del mismo modo sucede
con la relación marinero.
Los atributos comunes de bnro y son mantienen las relaciones. El proceso no pierde información.
Una base de datos relacional represente una relación muchas a muchas con una tercera tabla. La
relación de intersección, y con dos nuevas relaciones una a muchas entre las entidades originales
y la nueva tabla.
La relación de intersección creada durante esta descomposición lleva con frecuencia al

"descubrimiento" de una nueva entidad de aplicación. Por lo general esta nueva entidad debe
hacer estado en la base de datos desde el principio. En el ejemplo de bote-marinero, la relación de
intersección se pude llamar "carrera" porque un marinero y un bote están conectados por medio de
un evento de navegación. El par que conecta un marinero y un bote sirve también para representar
la carrera en la que el marinero y el bote participaron. La relación muchas a muchas entre botes y
marineros no esta comprometida porque no hay limite en el numero de veces en que un bote en
particular pueda aparecer en la tabla, ni hay limite en cuanto al numero de apariciones de un
marinero en particular. En consecuencia, la entidad de intersección a la que se ja cambiado el
nombre por "carrera", participa en las relaciones bote-carrera y marinero-carrera.
Ahora que la relación de intersección corresponde a una entidad en una aplicación del mundo real,
se pueden agregar otros atributos para describir una carrera en forma mas completa; en la tabla
2.1 se muestran nuevos atributos: fechaCarrera, distanciaCarrera y condicionesMar.
El valor de cualquiera de estos atributos es una propiedad de una combinación particular bote-
marinero.
Tabla 2.1: Descubrimiento de la entidad carrera de la base de datos de bote-marinero.
Marinero
snro snombre sedad
21 Alfred 19
17 Bernice 22
36 Candice 25
41 Dennis 20
12 Elsie 24
59 Frank 22
Bote
bnro bnombre bcolor blongitud
101 Calypso Azul 28
102 Sea sprite Verde 32
103 Tempest Rojo 28
104 Up scow Azul 24
105 Nigth stalker Rojo 28
106 Wind debt Azul 28
fechaCarrera distanciaCarrera condicionesMar snro bnro

Junio 22 25 Calma 21 101
Junio 28 32 Brisa ligera 21 102
Junio 29 50 Tormenta 21 103
Junio 23 25 Calma brisa fuerte 17 101
Julio 2 32 Brisa fuerte 17 103
Julio 2 32 Brisa fuerte 41 102
59
Julio 8 25 Tormenta 12 105
Julio 9 32 Calma 59 104
Julio 10 50 Brisa ligera 59 105
3.4 Relaciones una a una:
Si se impone la restricción adicional de que una tupla pueda aparecer en no mas de un par se
obtiene una relación una a una. Un par en la agrupación de relación se asocia exactamente a una
tupla de cada una de las entidades participantes, y estas tuplas quedan excluidas entonces de
cualquier otros pares.
Debido al acoplamiento uno a uno entre instancias de las entidades participantes, las dos
entidades a veces representan un solo concepto del dominio de aplicación. Supongamos que la
relación bote-marinero es una a una. Entonces cada marinero esta conectado a los sumo a un
bote, y cada bote esta conectado a lo sumo a un marinero. En este caso, podrían considerarse los
atributos del bote (por ejemplo, bnro, blongitud) como atributos del marinero, ya que estas
cualidades caracterizan al bote que pertenece a un marinero en particular y a ningún otro marinero.
Debido a que el bote no se puede asociar a ningún otro marinero, hay pocas razones para
mantenerlo en la base de datos como tupla separada. El bote se convierte en una de las
características que distinguen al marinero, en la misma forma que su dirección o numero telefónico.
Sin embargo este punto de vista tiene ciertas desventajas. Por ejemplo, si un marinero no tiene
bote, entonces todas las características del bote son nulas dentro de la tupla que representa a ese
marinero. SI los marineros están comúnmente sin botes, entonces esta representación contiene
muchos campos no utilizados. Además, un bote sin marinero no puede entrar en la base de datos
porque puede existir solo como atributos dentro de algún marinero.
La decisión final para unir las entidades se apoya con la aplicación especificas. Combinar
entidades conectadas por una relación una a una puede se mejor, o conservarlas separadas
también. Si se mantienen separadas, todavía se puede evitar crear una entidad de intersección.
Aun cuando la relación una a una es un caso especial de la relación muchas a muchas, también es
un caso especial de una relación una a muchas. En este ultimo contexto, se puede simplemente
incrustar la llave de una entidad en la otra para mantener la relación entre las dos tablas. Por
ejemplo se puede incluir bnro como atributo en marinero para identificar el bote correspondiente.
No es necesario incrustar snro en bote porque se pueden recuperar las agrupaciones apropiadas
desde la otra dirección.
Defina una base de datos donde existan relaciones binarias (de una a muchas, de muchas a
muchas y de una a una).
4. Relaciones de Grado Superior
El grado de una relación es el numero de entidades participantes. La mayor parte de las relaciones
encontradas en aplicaciones de bases de datos son binarias, es decir de grado dos, pero
ocasionalmente se puede encontrar una relación de grado superior; en teoría no hay limites para el
grado de una relación pero, en la practica, la mayor parte de las relaciones son de grado dos, y las
relaciones de grado superior que se encuentran no son mayor que tres.
La aplicación de una compañía de embarques de la figura 3.6 es un ejemplo de relaciones ternaria
(es decir, de grado tres). Una relación ternaria se apoya en triples mas que en pares, de manera
que, en la aplicación de embarques, una agrupación de relación es un triple, con una tupla de cada
una de las entidades participante, esto es, barco, carga y puerto, aportando un valor clave.
60
Figura 3.6. Relación ternaria entre las entidades de una compañía de embarques
Una agrupación del barco X con carga Y y puerto Z significa que el barco X llevo una carga Y al
puerto Z. Una tupla determinada puede entrar en estos triples un numero ilimitado de veces. La
asociación mutua entre los tres triples es la conexión importante.
Esta conexión de tres modos no es equivalente a conexiones por pares entre las entidades.
Debido a que barco, carga y puerto tienen una llave única, por ejemplo snro, cnro y pnro,
respectivamente, se pueden tabular los triples en una entidad de intersección. Recordemos que el
grado de una relación (entidad) es el numero de atributos, mientras que el grado de una relación
(interrelación entre relaciones) es el numero de entidades participantes. El grado de una relación
influye en el grado de la relación de intersección que tabula las conexiones. Si en una relación
ternaria aparecen tres entidades, cada una con una llave de un solo atributo, entonces la entidad
de intersección debe contener tres atributos. Sin embargo, una vez que el diseñador de la base de
datos cree la intersección, normalmente la reconoce como alguna entidad del mundo real en la
aplicación. Entonces agrega mas atributos para engrosar la descripción de esa entidad. Por tanto,
el grado de la relación (interrelación) da el grado mínimo de la correspondiente relación de
intersección.
En el ejemplo de embarques, la entidad de intersección es "misión". Una misión en particular es

despachar el barco X que transporta la carga Y al puerto Z. Se puede entonces descomponer la
61
relación ternaria entre barco, carga y puerto en tres relaciones una a muchas: barco-mision, carga-
mision y puerto-mision. En la tabla 2.2 se muestra esta descomposición.
Tabla 2.2: Descomposición de una relación ternaria en varias relaciones binarias de una a muchas.
Barco Puerto Carga

snro snombre pnro pnombre cnro cnombre
13 Galaxy 91 Boston 55 petroleo

25 Enterprise 17 Tampa 82 frijoles
83 Vega 64 Seattle
Mision
snro pnro cnro
13 91 82
25 91 55
25 64 82
83 17 82
Una instancia de la relación barco-mision es una tupla particular de barco agrupadas con todas las
tuplas de misión que comparten el mismo valor snro. Interpretaciones semejantes se aplican a las
relaciones carga-mision y puerto-mision. Note que la transformación preserva el significado exacto
de la relación original. Se puede recobrar todos los triples de barco-carga-puerto y no crear ningún
triple extra por error. Esta equivalencia se cumple porque la entidad de intersección preserva la
relación original como un conjunto de triples.
¿Transportó el barco Enterprise frijoles a Boston? Usando las tres entidades originales, se
determina que snro =25, cnro=82 y pnro=91 identifican Enterprise, frijoles y Boston,
respectivamente. La respuesta a la pregunta es si y solo si alguna tupla de la relación de misión
contiene snro =25, cnro =82 y pnro =91.
62
Figura 3.7 Descomposición errónea por pares de una relación ternaria
Que sucedería ahora si se descompone la relación ternaria identificando tres entidades de

intersección. Un par barco-carga es un embarque, un par carga-puerto es una llegada y un par
puerto-barco es un amarre en muelle. La entidad embarque sirve como intersección entre barco y
carga, y contiene todos los pares (snro, cnro ) tales que los valores snro y cnro aparecen en
algún triple de relación ternaria original, cualquiera que sea el pnro correspondiente. Una entrada
(snro =X, cnro =Y) de la tabla de embarque significa que el barco con snro =X transporto la
carga con cnro =Y a algún puerto no especificado. Del mismo modo, una entrada (cnro =Y,
pnro=Z) de la tabla de llegada significa que la carga Y llego al puerto Z en algún barco no
especificado. Finalmente una entrada (pnro =Z, snro =X) de la tabla de amarre en muelles
significa que el barco X llego a muelles en el puerto Z llevando alguna carga no especificada.
Ahora supongamos que el barco Enterprise nunca transporto frijoles a Boston. El triple
correspondiente a (Enterprise, frijoles, Boston) no aparece como agrupación de relación; sin
embargo, el Enterprise ha transportado frijoles a algún lugar, pero no a Boston. Por
tanto(Enterprise, frijoles) aparece en la tabla de embarque. Además algún barco ha transportado
frijoles a Boston, pero no el barco Enterprise. Por consiguiente (frijoles, Boston), aparece en la
tabla llegadas. Finalmente el Enterprise ha entregado carga en Boston, pero no frijoles, en
consecuencia (Boston, Enterprise) aparece en la tabla de entrada a muelles. Los datos de la tabla
2.3 ilustran estas circunstancias.
Tabla 2.3 : Intersecciones de descomposiciones por pares de la relacion barco-puerta-carga.
Amarrar en muelles Embarque

snro pnro snro cnro
13(Galaxy) 91 (Boston) 13(Galaxy) 82(frijoles)

25(Enterprise) 91 (Boston) 25(Enterprise) 55(petroleo)
25(Enterprise) 64 (Seattle) 25(Enterprise) 82(frijoles)
83(Vega) 17 (Tampa) 83(Vega) 82(frijoles)
63
Llegada
pnro cnro
91 (Boston) 82(frijoles)
91 (Boston) 55(petroleo)
64 (Seattle) 82(frijoles)
17 (Tampa) 82(frijoles)
Pero esta descomposición no esta mostrando la relación entre las tres entidades, no nos dice que
un barco transporta una determinada carga a un determinado puerto, porque justamente son
descomposiciones binarias, no ternarias.
Esta situación recibe el nombre de trampa de conexión debido a que un conjunto de asociaciones
por pares sugiere una conexión de tres vías, aun cuando la conexión de tres vías no existe.
El ejemplo ilustra que una verdadera relación ternaria no es equivalente a relaciones binarias por
pares entre las tres entidades. En una relación ternaria, cada agrupación significativa implica tres
tuplas, una de cada una de las entidades participantes. Tres tuplas, una de barco, una de carga y
una de puerto, deben venir juntas para hacer que una misión sea significativa. Este mismo principio
se aplica para todas las relacione de grado mas alto. Las agrupaciones de una relación de grado n
contienen cada una n tuplas, una de cada una de las n entidades participantes.
Defina una base de datos donde existan al menos dos relaciones de grado superior.
5. Relaciones Recursivas
En una relación recursiva binaria coinciden las dos entidades participantes. Son posibles las
situación de una a muchas y de muchas a muchas.
Una relacion recursiva es aquella en que una entidad participa mas de una vez asumiendo
un papel diferente en cada entrada en la relacion.
Relaciones recursivas una a muchas
Considere la relación muchas a una entre la entidad empleado y si misma, como se muestra en la
figura 3.8. Una instancia de relación agrupa un supervisor con cero, uno o mas trabajadores. La
relación es muchas a una porque un supervisor, que también es empleado, puede tener muchos
empleados trabajando para el, pero cada empleado se reporta a lo sumo a un supervisor. En el
papel del supervisor , la entidad empleado sirve como entidad dominante en la relación. EN el
papel de trabajador también sirve como entidad no dominante.
64
Figura 3.8. Relación binaria recursiva una a muchas
Al igual que el caso no recursivo, se mantiene una relación una a muchas al incrustar el atributo
llave de la entidad dominante en el compañero no dominante. En este caso, enro es una llave
para la relación de empleado porque cada tupla de empleado contiene un valor distintivo de enro.
La llave externa snro (numero de supervisor) se refiere al enro del eindividuo para quien
trabaja el empleado. Como ambos atributos se presentan en la misma tabla, se debe partir de la
convención de asignar el mismo nombre a los atributos de enlace entre dos tablas, pero el
significado de la llave externo no cambia. El valor snro de una tupla determinada se refiere al
supervisor de ese empleado.
Supongamos para este ejemplo que no hay ciclos en la cadena de mando. Comenzando con un
empleado X determinado, se pueden determinar todos sus trabajadores (los de ese trabajador) y
luego todos sus trabajadores (los de esos trabajadores), y así sucesivamente, pero no es de
esperarse encontrar un empleado X una segunda vez en el árbol en expansión.
5.1 Relaciones recursivas muchas a muchas
Como segundo ejemplo, considere la base de datos de la lista de materiales que se muestra en la
figura 3.9
Papel de ensamble
Parte
Papel de componente
65
Parte
Ensamble Componente
Uso
Figura 3.9. Base de datos de lista de materiales donde se ilustra una relacion recursiva
La entidad principal aquí es una "pieza", típicamente un componente de algún conjunto mecánico.
La relación recursiva aparece porque una pieza determinada contiene partes componentes. Por
ejemplo un motor esta formado de pistones, válvulas, levas, etc. Cada uno de estos componentes,
a su vez, contiene mas partes elementales. En ultima instancia, el proceso llega a partes
indivisibles, como son tuercas y tornillos.
A diferencia del ejemplo anterior esta relación es de muchas a muchas. Además de contener
subpartes una pieza en particular puede aparecer en muchas superpartes. Por ejemplo, una rueda
esta formada por un aro, una llanta y seis tuercas de orejas. Una rueda también aparece como un
componente del conjunto del eje delantero, el conjunto del eje trasero y el paquete del baúl de
equipaje (llanta de repuesto). Como las ruedas aparecen como componentes de tres partes, una
agrupación una a muchas esta fuera de duda porque la rueda estaría en la intersección de las tres
agrupaciones.
La técnica estándar de descomposición produce una entidad de intersección entre una pieza y ella
misma. Al igual que en la relación de empleado, la entidad pieza ahora desempeña dos papeles,
uno de los cales es "conjunto" y el otro es "componente". Como conjunto, una rueda contiene los
constituyentes antes mencionados: como componente, contribuye a la formación de otras partes,
por ejemplo el conjunto del eje delantero. Si se supone que pnro es una llave de la relación de la
pieza, se puede tabular la entidad de intersección como todos los pares de valores pnro, (pnro
1 =x, pnro 2 =y), donde la pieza x contiene a la pieza y. Para los componentes de un vagón, esta
descomposición aparece en la tabla 2.4. Para recuperar los componentes de la pieza x, se busca
en la tabla de intersección todos los pares con pnro 1 =x. Los valores correspondientes pnro 2
identifican los componentes. Para determinar los conjuntos que contienen la pieza y, se buscan en
la tabla de intersección todos los pares con pnro 2 =y. Los valores correspondientes pnro 1
identifican los conjuntos contenedores.
Tabla 2.4: Descomposición de la relación recursiva de lista de materiales
66
pnro pnombre
35 Vagon
51 Llanta
52 Maza
44 Eje
92 Chaveta
72 Cojinete de bolas
61 Pista de cojinete
90 Soporte de eje
98 Lengüeta de direccion
24 Perno
10 Suspensión delantera
11 Suspensión trasera
15 Rueda
16 carro
pnro 1 pnro 2 cantidad

35 16 1
35 10 1
35 11 1
35 98 1
35 24 1
10 90 1
10 15 2
10 24 1
10 44 1
10 92 2
11 90 1
11 15 2
11 24 2
11 44 1
11 92 2
15 51 1
15 52 1
15 61 1
15 72 8
En la tabla 2.4 se muestra una rueda (pieza 15) compuesta de una llanta (pieza 51), una maza
(pieza 52), una pista de cojinete (pieza 61) y cojinetes de bolas (pieza 72). Además una rueda
(pieza 15) aparece en la suspensión delantera (pieza 10) y en la suspensión trasera (pieza 11).
Como de costumbre se puede identificar la entidad de intersección con una similar del mundo real,
a saber, el uso de la pieza.
Debido a que la intersección ahora corresponde a un concepto de aplicación (uso), la tabla de uso
proporciona una ubicación conveniente para el numero de veces que una subparte en particular
aparece dentro de un conjunto determinado. El atributo cantidad agrega esta información .
Continuando con el ejemplo de la tabla 2.4 una rueda (pieza 15) contiene una llanta (pieza 51), una
maza (pieza 52), una pista de cojinete (pieza 61) y ocho cojinetes de bolas (pieza 72). Si leemos a
la inversa, una rueda (pieza 15) aparece dos veces en la suspensión delantera (pieza 10) y dos
veces en la suspensión trasera (pieza 11).
Defina una base de datos donde existan al menos dos relaciones recursivas.
67
6. Restricciones:
Una restricción de base de datos restringe los datos que parecen en los cuerpos de relaciones. El
cuerpo de una relación contiene tuplas y el valor de atributo de una tupla debe venir de algún
dominio especificado. Por consiguiente, la definición de este punto ya impone alguna disciplina
acerca del contenido de las tablas.
Sin embargo, una aplicación a veces demanda restricciones mas allá de restricciones de dominio.
Quizá los apellidos de una base de datos de personal están restringidos a caracteres alfabéticos o
a un máximo de veinte caracteres. Quizá nunca debe haber mas de cien peces en cualquier
tanque de la base de datos del acuario. Aparecen restricciones desde la aplicación dada. El
diseñador de la base de datos pude instruir al Sistema de administración de base de datos (DBMS)
para obligar restricciones de aplicación y en, consecuencia, hacer que el modelo de la base de
datos sea una reflexión mas precisa de la realidad.
Una violación ocurre si cualquier cuerpo relacional contiene datos que no satisfagan una
restricción. Debido a que los datos de los cuerpos cambian a medida que evoluciona la
correspondiente situación del mundo real, el contenido de la base de datos puede pasar de un
estado consistente (sin violaciones) a un estado inconsistente (una o varias violaciones).
El estado de la base de datos en un momento especificado es el contenido de los cuerpos
relacionales en ese momento. Un estado consistente, con respecto a alguno conjunto de
restricciones, es un estado sin violaciones de restricción. El diseñador de una base de datos debe
identificar las restricciones de aplicación y luego asegurarse que el estado de la base de datos
permanezca consistente con respecto a estas restricciones.
¿Cómo es precisamente que las bases de datos mantienen un estado consistente?

Cuando se definen las diversas relaciones se arma la estructura de la base de datos; luego los
usuarios manipulan el contenido de estas relaciones (tablas) al añadir, modificar y borrar tuplas. Se
puede vigilar continuamente el estado de la base de datos con rutinas de interfaz, que pueden ser
programas de software o usuarios interactivos. Estas rutinas podrían rechazar cualquier
transacción que lleve a un estado inconsistente. Debido a que puede haber numerosos usuarios en
interacción, este requisito impone una pesada carga para el desarrollo del software
correspondiente. Un método mas eficiente incluye las restricciones en la definición de la base de
datos: El sistema de administración de bases de datos (DBMS) soporta operaciones de uso
general de bases de datos, por ejemplo la de insertar, modificar y borrar tuplas.
Ahora introduciremos algunos términos importantes para entender como el DBMS aplica las
restricciones.
Claves Primarias:
La clave primaria de una relación es solo un identificador único para esa relación. Por ejemplo las
claves primarias de las relaciones Marinero, Bote y Carrera son Marinero.snro, Bote.bnro y
Carrera.(snro,bnro) respectivamente.
Note que el ultimo ejemplo nos dice que la clave primaria puede ser compuesta; aunque poco
usual también se puede tener una relación en la cual el único identificador único (la clave primaria)
sea el atributo compuesto formado por la combinación de todos los atributos de la relación; es decir
la relación es "toda clave". Ejemplo: la relación Carrera sin los atributos fechaCarrera,
distanciaCarrera, condicionMar.
También es posible, aunque otra vez poco usual, tener una relación con mas de un identificador
único. Ejemplo: Si le agregamos a la tabla Marinero el numero de documento de cada marinero. En
un caso así, diríamos que la relación tiene varias claves candidatas; nosotros escogeríamos una
de esas claves candidatas como clave primaria, y las demás las llamaríamos entonces claves
alternativas.
Definiremos el termino claves candidatas de la siguiente manera.
El atributo K posiblemente compuesto de la relación R es una clave candidata de R si y solo si

satisface las siguientes dos propiedades, independientes del tiempo:
1- Unicidad:
68
En cualquier momento dado, no existen dos tuplas en R con el mismo valor de K.
2- Minimalidad:
Si K es compuesto, no será posible eliminar ningún componente de K sin destruir la propiedad de
unicidad. 2
Entonces del conjunto de claves candidatas de una relación, se elige una y solo una como clave
primaria de esa relación; las demás si existieran se llamarían claves alternativas. Una clave
alternativa es una clave candidata que no es clave primaria.
¿Por qué son importantes las claves primarias?

Una de las respuestas fundamentales es que el manejo de claves primarias es fundamental para el
manejo de claves ajenas como veremos mas adelante. Otra respuesta es que la única forma
garantizada por el sistema, para localizar alguna tupla especifica es por el valor de su clave
primaria.
Las claves primarias con tan indispensables para el funcionamiento exitoso de un sistema
relacional como las direcciones de memoria principal lo son para el funcionamiento exitoso de la
3
maquina subyacente.
El DBMS interpreta la definición de un atributo como clave primaria y aplica fácilmente de manera
general la "restricción de llave" haciendo cumplir las propiedades de la clave primaria en todas las
operaciones de manipulación (insertar, modificar o borrar)
El modelo relacional tiene dos reglas generales de integridad:
La Regla de Integridad de las Entidades:
Ningun componente de la clave primaria de una relacion base puede aceptar nulos.
Nulos significa información faltante por algún motivo, por ejemplo si el valor se desconoce o si no
es aplicable. Es decir, no representa valor real alguno del atributo aplicable.
Justifiquemos esta regla:

 Una relación base representa una entidad del mundo real. Por ejemplo: la relación Marinero
representa a una conjunto de marineros del mundo real.
 Por definición las entidades del mundo real se pueden identificar de alguna manera
 Por lo tanto las tuplas que representan las entidades dentro de la base de datos deben ser
identificables también.
 Las claves primarias realizan esta función.
 Supongamos que en la relación Marinero existiera una tupla en la cual el valor de snro fuera
nulo. Eso equivaldría a decir que en el mundo real existe un marinero sin identidad conocida.
 En conclusión si una entidad del mundo real es realmente importante para estar representada
en la base de datos, deberá tener una identificación definida y sin ambigüedad, pues de lo
contrario seria imposible hablar de ella de cualquier forma sensata.
Además:
 Las claves primarias compuestas deben ser no nulas en su totalidad. En el caso de la relación
Carreras cuya clave primaria es Carrera.(snro,bnro), deben tener ambos las restricción de "no
se permiten nulos"; ni snro, ni bnro podrán aceptar nulos.
 La regla de integridad de las entidades se aplica a las relaciones base.
 La regla de integridad de las entidades se aplica a las claves primarias. En claves alternativas
se podrán permitir nulos.
2y3
Iberoamericana
69
Claves Ajenas:
Recordemos la base de datos de Pez y Tanque; y consideremos el atributo tnro de la relación Pez
es evidente que solo deberá permitirse a un valor dado de ese atributo aparecer en la base de
datos si ese mismo valor aparece también como un valor de la clave primaria de la relación
Tanque. De lo contrario la base de datos no estaría consistente o en un estado de integridad. Seria
absurdo que la relación Pez incluyera en alguna de sus tuplas un tanque que no existiese en la
relación Tanque. La base de datos esta almacenando información errónea y lo que es peor no
sabríamos cual es el verdadero tanque en el que habita dicho pez.
¿Que pasaría entonces si en la relación Carreras existiera un valor para los atributos bnro y snro
que no existiera en las relaciones respectivas Botes y Marineros?
Tanto el atributo tnro de la relación Pez, como los atributos bnro y snro de la tabla Carreras con
ejemplos de lo que se conoce como claves ajenas.
Una clave ajena es un atributo (quizá compuesto) de una relación R2 cuyos valores deben
concordar con los de la clave primaria de alguna relación R14.
Un valor de clave ajena representa una referencia a la tupla donde se encuentra el valor
correspondiente de la clave primaria. La restricción según la cual los valores de una clave ajena
determinada deben concordar con los valores de la clave primaria correspondiente se conoce
como restricción referencial. La relación que contiene la clave ajena se la conoce como relación
referencial y la relación que contiene la clave primaria correspondiente se denomina relación
referida o relación objetivo.
Podemos representar la base de datos de Marineros y Botes de la siguiente manera:
Marinero Carrera Botes
Cada flecha significa que existe una clave ajena en la relación de la cual sale la flecha, la cual hace
referencia a la clave primaria de la relación a la cual apunta la flecha.
Una definición mas formal expresa lo siguiente:

Sea el atributo LF (quizá compuesto) de la relación base R2 es una clave ajena si y solo si
satisface estas dos propiedades independientes del tiempo:
1- Cada valor de LF es nulo del todo o bien no nulo del todo.

2- Existe una relación base R1 con clave primaria LP tal que cada valor no nulo de LF es idéntico
al valor de LP en alguna tupla de R15.
De las definiciones anteriores surge los siguiente:
 La clave ajena y la clave primaria correspondiente deben definirse sobre el mismo dominio
subyacente.
 La clave ajena no necesita ser un componente de la clave primaria de la relación que la
contiene. Podemos ver en el caso de la relación Pez, tnro y snro no son partes de la clave
primaria.
 Una relación dada puede ser tanto una relación referida como una relación referencial
R3 R2 R1
 Las claves ajenas a diferencia de las claves primarias, en ocasiones deben aceptar valores
nulos.
4y5
Iberoamericana
70
La regla de integridad referencial
La base de datos no debe contener valores de claves ajenas sin concordancia.
La definición se refiere a que para un valor no nulo de clave ajena siempre debe tener su
correspondiente clave primaria en la relación objetivo.
Note lo siguiente:
 La integridad referencial exige concordancia de las claves ajenas con claves primarias, no con
las claves alternativas.
 No es posible explicar que es una clave ajena sin mencionar la noción de integridad referencial
y de la misma manera no es posible explicar la regla de integridad referencial sin hacer
mención del concepto de clave ajena.
Reglas para claves ajenas:
Así como el DBMS restringe las violaciones a una clave primaria también lo hace con las dos
reglas que acabamos de definir, manteniendo a la base de datos en un estado de integridad o
consistente. Pero en muchos casos una alternativa preferible seria que el sistema aceptara la
operación pero realizará en caso necesario, ciertas operaciones de compensación con objeto de
garantizar un estado legal como resultado.
Por ejemplo si el usuario solicita eliminar el marinero snro1 de la relación Marinero debería ser
posible hacer que el sistema elimine también de la relación Carreras todas las carreras que ha
corrido este marinero (que están almacenadas en la relación Carreras), sin necesidad de acciones
adicionales por parte del usuario (suponiendo que la "eliminación en cascada" era lo deseado).
El diseñador de base de datos deberá poder especificar que operaciones han de rechazarse y
cuales han de aceptarse y en el ultimo caso cuales operaciones de compensación deberá realizar
el sistema:
Si se quiere eliminar el objetivo de una referencia de clave ajena: Por ejemplo queremos eliminar
un marinero de la relación Marinero.
Existen por lo general tres posibilidades:
 RESTRINGIDA - La operación de eliminación esta restringida en el caso que el marinero

(RESTRICTED) hubiera participado en alguna carrera.
 SE PROPAGA - La operación de eliminación se propaga eliminando también las carreras
(CASCADES) correspondientes.
 ANULA - Se asignan nulos a la clave ajena en todos las carreras correspondientes
(NULLIFIES) a ese marinero y se elimina el marinero.
Si se quiere modificar la clave primaria del objetivo de referencia de clave ajena. Por ejemplo
cambiar el numero de un Marinero:
 RESTRINGIDA - La operación de modificación esta restringida en el caso que el marinero

(RESTRICTED) hubiera participado en alguna carrera.
 SE PROPAGA - La operación de modificación se propaga modificando también las
(CASCADES) carreras correspondientes.
 ANULA - Se asignan nulos a la clave ajena en todos las carreras correspondientes
(NULLIFIES) a ese marinero y se modifica el marinero.
Tomando la base de datos de la seccion 1 de esta unidad represente dos situaciones que violen
la regla de integridad de las entidades y la regla de integridad referencial.
71
Actividades de autoevaluación:
1- Sin intentar un método sistemático de recuperación de información, conteste las siguientes

preguntas explorando la base de datos del acuario.
1. Encuentre los nombres de pez azul.
2. Encuentre los nombres de pez azul que vive en un tanque llamado letrina.
3. Encuentre los nombres de especie representados en algún tanque denominado letrina.
4. Encuentre los nombres de especie representados en todos los tanques de la base de
datos.
5. Encuentre los nombres de especie representada en todos los tanques rojos de la base
de datos
2- Analice las siguientes situaciones y encuentre las relaciones binarias, factorice todas las
relaciones muchas a muchas.
1. La ciudad de Megopolis sostiene un sistema de biblioteca que comprende varios
edificios de bibliotecas, cada uno de los cuales contiene un gran numero de libros.
Desde luego que los libres mas populares se pueden hallar en varias de las bibliotecas.
2. La ciudad de Megopolis sostiene un sistema de biblioteca formado por varios edificios,
muchos libros y un conjunto de usuarios que periódicamente piden libros prestados. Al
igual que en el párrafo anterior, puede haber un libro en ejemplares duplicados en
varios edificios de la biblioteca y además los usuarios pueden pedir libros de cualquiera
de las bibliotecas del sistema.
3. Una universidad esta formada por varias facultades, cada una de las cuales consta de
varios departamentos. Por ejemplo la Facultad de Ingeniería contienen los
departamentos de Ingeniería Eléctrica, Civil, Mecánica y Química. La facultad de
humanidades tiene los departamentos de Historia, Antropología, Lenguas extranjeras,
etc. Cada departamento cuenta con un grupo de profesores. No hay nombramientos
conjuntos un profesor enseña dentro de un solo departamento. Los estudiantes se
especializan en diversos departamentos, pero, a diferencia de un profesor, un
estudiante puede especializarse de manera simultanea en mas de un departamento.
3- Analice las siguientes situaciones y encuentre las relaciones de grado mas alto. En cada caso
demuestre que las relaciones de grado mas alto no es equivalente al conjunto de relaciones
binarias por pares.
1. La sucursal de un fabricante cuenta con muchos artículos para venta . Un cliente y un

vendedor trabajan juntos para completar una transacción facilitando la compra de un
articulo para el cliente. Un cliente puede comprar un articulo determinado en cualquier
cantidad, y esta información también debe registrarse.
2. Existen campos para arar, tractores para hacer el trabajo del arado y agricultores para
manejar los tractores. Cuando los tres factores se unen, se realiza un trabajo.
4- Analice las siguientes situaciones y encuentre las relaciones recursivas.
1. Un programa de computadora esta formado por un conjunto de subprocedimientos,

que se llaman unos a otros para diferentes servicios. En general, un subprocedimiento
determinado llama otras rutinas para descomponer el trabajo en componentes mas
pequeños, pero un procedimiento especifico también puede invocarse por muchos
procedimientos anfitriones diferentes.
2. Una colección literaria contiene varios libros, cada uno con una sección de bibliografía
que remite a otros libros.
72
Unidad IV: Modelado de datos utilizando el enfoque Entidad – Relación
El objetivo que persigue el modelo entidad-relación es proporcionar un modelo preciso de las

necesidades de información de la organización; independiente de cualquier almacenamiento de
datos y método de acceso, que permita timar decisiones objetivas de las técnicas de
implementación y la coexistencia con sistemas mas antiguos.
El modelo entidad-relación, junto con las herramientas sofisticadas CASE, puede ofrecer un medio
efectivo y preciso de especificar y controlar la definición de las necesidades de información. Pero
estas técnicas y herramientas CASE de apoyo se deben utilizar de forma correcta, al igual que
cualquier otra herramienta poderosa.
En esta sección le enseñaremos a crear, validar y explotar el modelo entidad-relación para ayudar
a construir buenos sistemas y/o manuales de sistemas.

7. Diseño de base de datos relacional
 Aprender a diseñar un modelo entidad-relación identificando correctamente sus componentes

 Comprender la importancia de incorporar el modelo como una herramienta de ayuda para la
construcción de buenos sistemas.
 Valorar las entrevistas con los usuarios para poder representar en el modelo lo que quiere
mostrar el sistema.
 Entender la importancia de trabajar con calidad y con normas de diseño.
73
Esquema Conceptual:
usuarios
SQL
VISTA VISTA
Modelo Entidad-Relación Técnicas de

Modelado de
Bases de Datos
Lógico
Físico
Almacenado
base de datos
almacenada
74
El modelo entidad-relación es una técnica para definir las necesidades de información de su

organización. En su forma mas simple implica identificar asuntos de importancia dentro de una
organización: "entidades", las propiedades de sus asuntos: "atributos" y como se relacionan entre
si: "relación". Pero esto tiene valor solamente dentro del contexto de lo que se realiza en la
empresa y en la forma de actuar de estas funciones de gestión sobre el modelo de información.
Se espera que los sistemas que se están demandando hoy en día y en un futuro proporcionen un
apoyo simultaneo para las diferentes necesidades de cualquier organización, operaciones diarias,
información de gestión y otros requisitos a niveles locales, centrales y descentralizados. Estos
sistemas deben acompañar los muchos métodos alternativos de implementación disponibles,
desde archivos manuales simples y sistemas de oficina pasando por la sofisticación de
heterogéneas bases de datos distribuidas.
Temas claves:
Existen diez temas claves que se necesitan tener en cuenta cuando se utilice el modelo entidad-
relación como ayuda para definir las necesidades de información de gestión:
 Dato, recurso clave: un dato como recurso es importante para la evolución satisfactoria de la
organización como lo son los recursos financieros, humanos y físicos. Las compañías que
evolucionan y ganan ventaja competitiva gracias al control de este recurso de información vital.
 Compromiso de la dirección: la dirección debe confirmar los requisitos de información.

Recuerde que tendrá un éxito limitado sin el compromiso de la dirección
 Convenciones: aplicar en todo momento convenciones rigurosas, estándares y directrices,

incluyendo obviamente los conceptos de normalización de datos.
 Definición mínima: Se debería definir o modelizar cualquier información o concepto de datos

solo de una forma y a continuación configurar asociaciones para todos los objetos
relacionados. Ejemplo: Definimos de una vez un <<Pedido de compra>> y a continuación lo
relacionamos con el departamento, los productos, funciones de autorización, etc.
 Independencia de datos: Definir los requisitos de información de forma que sean

independientes de cualquier almacenamiento final o método de acceso.
 Patrones genéricos: Buscar patrones genéricos de datos permite a los usuarios utilizarlos en
su gestión y perfeccionar la forma de procesar sus datos.
 Actitud y calidad: Los modelizadores pueden comenzar a aplicar las convenciones automática
y velozmente, pero sin sacrificar el rigor. Se debe comprender el 100 por 100 de las
necesidades de información de la organización y reforzar diseños mas flexibles y genéricos,
para minimizar así los problemas y disminuir los costos de mantenimiento.
 Comunicación: Debe haber comunicación con los usuarios finales, en términos que ellos
puedan entender. Utilizar un lenguaje claro, sin abreviaturas ni jergas para lograr su
comprensión. Hablar siempre en concreto "cosas con significado" acerca de las necesidades
de información que se van a conocer y a mantener. Utilizar ejemplos que tengan relevancia
directa para el usuario.
 Relevancia: Los requisitos de información solo pueden tener valor si soportan las necesidades
funcionales de la organización, dentro del marco de trabajo de los objetivos y propósitos de la
empresa.
75
 Un medio, no un fin: Aunque el modelo entidad-relación es muy potente, ofrecer una idea de la
compañía y actuar como un marco de trabajo para el diseño de los datos, solo es una técnica
intermedia.
Definiremos ahora las convenciones y definiciones de entidades, relaciones, atributos y diseño.
Entidad: Una entidad es una cosa o un objeto con significado, real o imaginado acerca de las
necesidades de información que se van a conocer o a mantener.
NOMBRE DE ENTIDAD
Una entidad se representa, en forma de diagrama con un recuadro, por ejemplo: un rectángulo con
esquinas redondeadas, con un nombre. El nombre se muestra en singular y con letras mayúsculas.
El recuadro puede tener cualquier tamaño o forma, suficiente para contener un nombre sin
ambigüedad y sin abreviaturas, y para hacer que el dibujo de un diagrama entidad-relación sea
mas conveniente. Por ejemplo, a menudo es sensato agrandar un recuadro para permitir que se
conecten a el mas líneas de relación sin líneas cruzándose innecesariamente o que el diagrama se
asemeje a una telaraña.
Nombre de la entidad
El nombre de la entidad debe ser el que represente un tipo o clase de elemento, no una instancia.
En este estudio, "Heathrow" o "John F. Kennedy" no podrían ser nombres de entidades: la entidad
es AEROPUERTO, y aquellas son dos instancias de esta entidad.
AEROPUERTO/AERODROMO
Por ejmplo:Heathrow
John F. Kennedy
Fairoaks
Fairoaks, por tanto, as un aeródromo pequeño al sur

de Inglaterra, el cual, sin embargo, tiene una torre de control,
aduana, inmigración, etc.
Los ejemplos son muy útiles para comprender el concepto de la entidad y se pueden mostrar en
letras minúsculas o mayúsculas.
Reglas para definir una entidad:
Cualquier objeto solo puede ser representado por una entidad. Es decir, las entidades son
mutuamente exclusivas en todos los casos.
Cada entidad debe ser identificada de forma única. Es decir, cada instancia (aparición) de una
entidad debe encontrarse separada e identificable claramente de todas las demás instancias de
ese tipo de entidad.
76
Relación: Una relación es una asociación entre dos entidades referida a un nombre.
Una relación es binaria, en el sentido de que es siempre una asociación entre exactamente dos
entidades, o entre una entidad y ella misma. Cada relación tiene dos extremos, para cada uno de
los cuales tiene un:
 nombre,
 grado/cardinalidad (cuantos),
 opcionalidad (opcional u obligatorio).
Estas propiedades se utilizan para describir la asociación de extremo; se deben definir ambos
extremos.
Una relación se representa mediante una línea que une dos recuadros de entidades, o
recursivamente (recurrentemente) une un recuadro de entidad consigo mismo. La relación más
común es la que tiene un grado de muchos a uno: en el extremo "muchos" es obligatoria y en
opcional en el extremo 'uno' como se muestra a continuación.
Muchos uno
(ramificación)
obligatorio opcional
Para un grado de muchos, la línea de relación une un recuadro de tres puntos, conocido como
"ramificación". Para un grado de uno la línea se une solamente en un punto.
En donde la terminación de la relación es obligatoria, se dibuja una línea continua para esa mitad
de la relación. En donde la terminación de la relación es opcional, se dibuja una línea discontinua o
guiones.
A menudo es útil pensar acerca de una relación de uno a muchos como una relación padre a hijo,
con la existencia del hijo encontrándose en una forma dependiente de su padre.
Relación recursiva
A continuación se muestra una relación recursiva con propiedades idénticas.
muchos
obligatorio
uno
opcional
Esta relación recursiva en particular muestra una jerarquía infinita.

77
El nombre de cada extremo de una relación se sitúa cerca del extremo apropiado en minúsculas
como se muestra a continuación.
nombre-extremo-1
ENTIDACD-A ENTIDACD-B
nombre-extremo-2
Cuando la terminación de la relación es obligatoria, la frase "debe ser" se utiliza para preceder al
nombre final de la relación: para los nombres finales opcionales de la relación se utiliza la frase
"puede ser". Por tanto, el diagrama anterior se leería de la siguiente forma:
Cada ENTIDAD-A debe ser el nombre-extremo-I una y sólo una ENTIDAD-B,
Y de derecha a izquierda:
Cada ENTIDAD-B puede ser el nombre-extremo-2 y una o más ENTIDADes-A.
Esto Puede Parecer incomprensible hasta que se lee un ejemplo real.
para
BILLETE PASAJERO
mostrado en
Cada BILLETE debe ser para uno y sólo un PASAJERO
Y:
Cada PASAJERO se puede mostrar en uno o en más BILLETES.
El plural del nombre de la entidad se utiliza cuando el grado es muchos. Un grado de muchos se
lee como uno o más, Y un grado de uno como uno y solamente uno.
Cuando se dibujan diagramas de entidad-relación, se puede encontrar un grado mayor de
precisión si la ramificación (los finales muchos) se puede situar en la terminación izquierda y
superior de la línea de la relación. Además, se ha mostrado una técnica de dar nombres ha
empleado el verbo 'ser' para asignar nombres más útiles y mas definitivos.
Dar nombres a relaciones, en ambos extremos, ayuda a eliminar las relaciones innecesarias
(redundantes) lo antes posible, facilita la comprensión y evidencia frecuentemente el hecho de que
se necesita relaciones y entidades posteriores.
Una definición de relación es la que representa un tipo de asociación entre dos entidades con las
que deben ajustarse todas las instancias (apariciones). Todos los conceptos en el modelo entidad-
relación se relacionan con tipos no con las instancias de esos tipos.
Para leer cualquier relación de forma simple, pero definitiva, se utiliza la siguiente sintaxis.
78
Sintaxis normal:
debe ser
Cada una y todas las ENTIDADES-A
puede ser nombre-extremo 1
Una y solo una ENTIDAD-B (siempre)
Una o mas ENTIDADES-B plural ¿es eso verdad?
y a la inversa:
debe ser
Cada una y todas las ENTIDADES-B
puede ser nombre-extremo 2
Una y solo una ENTIDAD-A (siempre)
Una o mas ENTIDADES-A plural ¿es eso verdad?
Hay que tener en cuenta que las palabras "y todas" y "siempre" se pueden insertar en la sentencia
para aportar más rigor. La expresión "y todas" implica. que ninguna instancia se puede apartar de
la limitación aplicada por la definición de relación. La expresión "siempre" implica que se está
normalmente interesado en las relaciones que existen hoy en ida, en el futuro y en el pasado.
Para comprobar la afirmación se puede añadir la expresión "es eso verdad".
Si se lee la relación BILLETE/PASAJERO de nuevo se Ilegará a aclarar.
Cada uno y todos los BILLETES deben ser para uno y sólo un PASAJERO siempre, ¿es
eso verdad?
Esta es una buena pregunta, ya que la sentencia implica. que la compañía no puede tener nunca
billetes para familias, grupos o billetes cuando no conocemos la identidad del pasajero.
Esta facilidad de leer las relaciones en español y el grado de rigor es muy importante ya que
permite que un analista desenrede excepciones, requisitos relacionados con el tiempo y casos
especiales con los usuarios lo antes posible. Habiéndolo hecho así, el modelo puede reflejar esos
temas v se pueden elegir los diseños consecuentes de los sistemas para ofrecer el mecanismo
óptimo para manipularlos - lo cual incluye manipulación manual -. En muchas ocasiones se ha visto
que la mayoría de los problemas en el mantenimiento aparecen en su mayor parte debido a que
los diseñadores no conocían estas excepciones; y que el coste de volver a desarrollar es por
consiguiente muy alto.
Sintaxis invertida:
La sintaxis anterior es muy buena para muchos propósitos, pero para comprobar de verdad los
detalles, la siguiente sintaxis puede ser muy útil.
79
para
CUPON VUELO
causa de
Como sintaxis normal esto se lee:
Cada CUPON debe ser para uno y sólo un VUELO siempre
Mientras que en la sintaxis invertida, esto se lee así:
Eso significa que nunca se puede tener un CUPON que no sea para un VUELO únicamente
identificable ¿es eso verdad?
Aquí, "cada" se puede reemplazar por una expresión mucho mas cuestionable, y la expresión ya
delimitadora "uno y sólo uno ... siempre" se puede reemplazar por "típicamente identificable".
Una vez más, esta es una buena cuestión, ya que el modelo actual no permite tener un CUPON
que no identifique únicamente un vuelo en un ida en particular. Pero en el mundo real, los billetes
abiertos existen cuando el cupón no muestra una fecha especifica de salida, y la definición de
relación tendría que cambiarse y ser opcional de poderla proporcionar.
Relaciones validas:
No todas las relaciones que se pueden dibujar son válidas y aparecen muy a menudo. Los
siguientes dibujos son construcciones de relaciones comunes.
Relaciones válidas comunes.
Muchos a uno
Muchos a muchos
Recursivo,
muchos a uno por
jerarquias
Relaciones no validas
Los dibujos siguientes no son válidos, ya que representan condiciones imposibles.
80
Muchos a muchos
obligatorio
Jerarquia
infinita
Atributo: Un atributo es cualquier detalle que sirve para calificar, identificar, clasificar, cuantificar o
expresar el estado de una entidad; o cualquier descripción de una característica de importancia.
Un atributo podría ser un texto, números, un dibujo, un sentimiento, un olor, etcétera, según se
requiera. Para propósitos de proceso de datos, se tiende a concentrarse en un texto y en números,
pero otros atributos podrían ser importantes en el éxito del funcionamiento de su empresa, por
ejemplo, la profesionalidad de los miembros del departamento de sistemas de información.
Para representar un atributo hay que escribir su nombre en singular y en minúsculas, y de forma
opcional con un ejemplo de su valor.
ENTIDAD-A
atributo-1
atributo-2
En un diagrama entidad-relación no es necesario mostrar atributos, aunque el añadir uno o dos a

cada entidad durante el período de formación es altamente beneficioso. En particular, esto es muy
útil cuando se distinguen entre entidad "tipo" e "instancia".
En el ejemplo siguiente, los atributos candidatos son esenciales para ayudar a distinguir entre dos
entidades.
AVION TIPO DE AVION

de
numero de registro clasificación de Codigo: por ejemplo 747
fecha hecha descripcion
nombre
81
En este informe, la línea aérea puede que haya adquirido solo cuatro o cinco tipos de aviones
diferentes, pero puede tener cien o mas aviones reales. El número de registro de atributo tendría
un único valor para cada instancia de la entidad AVION.
Las siguientes normas simples ayudan a crear un modelo preciso, completo y flexible.
El atributo debe describir la entidad en contra de lo que se muestra. Esto puede ser obvio, pero es
el error más común que se encuentra en los atributos.
Por ejemplo: ¿el "numero do asiento" es un atributo de un cupón, billete, tarjeta de embarque,
avión o asiento de un avión?
Obviamente es un atributo de ASIENTO, pero en la vida real el numero a menudo se ve duplicado
muchas veces: por ejemplo, en una tarjeta de embarque, véase la Figura 4.1.
¿Por que? En el mundo real, un número do asiento es una forma muy conveniente de representar
una relación. Por el contrario, cuando se encuentran estas situaciones hay que dibujar la línea de
relación, si es necesario, crear la entidad a la que se refiere, corno se muestra a continuación.
Figura 4.1
Asignar un atributo a la entidad correcta:
TARJETA DE emitido para ASIENTO

EMBARQUE
utilizado numero
fecha mediante
en
compuesto de
AVION
numero de registro
fecha hecha
nombre
Para que sirva de guía, la mayoría de las entidades sólo se describen manejando entre dos y ocho
atributos. Si se tienen más, probablemente existirán muchas relaciones y/o entidades perdidas.
Nombres de atributos: No hay que utilizar el nombre de la entidad como parte del nombre del
atributo. Sería redundante, ya que el atributo sólo describe la entidad. En el ejemplo anterior, el
"número de asiento" realmente ayudó a identificar una entidad perdida llamada ASIENTO que se
podría describir con el atributo "número" y quizás con otros atributos como "tipo".
Para leer atributos que se nombren de esta manera, se pueden utilizar de una de las dos formas:
entity name attribute name (nombre entidad nombre atributo)
attribute name of entity name (nombre atributo de nombre entidad).
Por ejemplo, asiento número o número de asiento.

En el ejemplo clásico de empleados y de sus departamentos, el "número de departamento" no es
un atributo de la entidad EMPLEADO. Es un atributo de DEPARTAMENTO, y se debería definir
como número de departamento.
Eliminar atributos repetidos:
82
Una entidad puede que sólo tenga un valor para un atributo en cualquier momento. Si son
esenciales muchos valores, se debe crear una entidad nueva para mantenerlos en la relación
muchos a uno, unidos con la entidad original. Al utilizar el ejemplo, asiento de nuevo, un primer
modelo debería haber sido:
AVION
numero de registro
fecha hecha
nombre
asiento1
asiento2
....
asiento96
Un atributo repetido indica una entidad perdida. Se debe añadir la entidad perdida:
ASIENTO AVION
numero número de registro

nombre
El nombre de un atributo debe ir en singular. Los nombres generalmente reflejan el problema de

los atributos repetidos mostrado anteriormente. Así, pues, los atributos no válidos de la entidad
AVION incluirían asientos, tripulación, puertas y motores. Una vez más, implica a entidades
perdidas con sus propios atributos.
Un atributo se convierte en una entidad cuando tiene importancia por si misma, con sus propias
relaciones y atributos.
En el ejemplo anterior se ha utilizado el "número de registro" como un atributo de avión. Esto casi
siempre será juicioso, hasta que se considere el subsistema de registros de una línea aérea, en
cuyo caso solo se necesita la "fecha de registro", "¿cuando fue registrado?", "¿para que fue
registrado?", "¿avión vuelto a registrar?", etc. El diagrama evolucionara como se muestra a
continuación:
Figura 4.2
Un atributo puede llegar a ser una entidad.
REGISTRO
emitido por AUTORIDAD DE
numero origen de REGISTROS
fecha
tipo
de
identificado en
AVION
83
Atención! Es fácil dejarse llevar por detalles irrelevantes. En este caso, no interesa este subsistema
y se volverá al modelo anterior, quizás mejorando la comprensión añadiendo al "número de
registro" el adjetivo "actual".
AVION
número de registro actual
Cada entidad debe ser identificable únicamente por una combinación de atributo y/o relación. De
esta forma se podría buscar siempre cualquier atributo candidato que ayude a identificar una
entidad.
En los autos - o los aviones que hemos tenido en cuenta -, la utilización de los números de chasis,
números de motores, etc., obviamente tiene mucho valor.
El valor del atributo debe ser dependiente de todo el identificador único.

Hay que quitar los atributos por los que los valores son dependientes sólo de parte del identificador
único.
Hay que quitar los atributos quo no sean dependientes directamente del identificador único de la
entidad. Por ejemplo, se podría tener una tarjeta de embarque en la que esta grabado el nombre
del pasajero.
¿Es el nombre del pasajero de alguna forma dependiente del identificador único de la
tarjeta de embarque?'*
Obviamente, no. (¡Bien, no cambio mi nombre cuando voy con una tarjeta de embarque!) Si el
atributo no es dependiente directamente del identificador único, probablemente existe una entidad
y/o relación perdida.
Atributos opcionales
Un atributo puede tener un valor sólo algunas veces, o puede no estar disponible, en cuyo caso
esto se puede mostrar con una "o" pequeña delante del nombre del atributo para indicar que es
opcional.
Atributos obligatorios
El valor de un atributo que se debe conocer siempre se muestra "*" pequeño delante del nombre.
Pero hay que tenor cuidado porque si se aplica rigurosamente esto significa que en ninguna
ocasión se conocerá la existencia de la aparición de una entidad sin conocer el valor de cada uno
de sus atributos obligatorios. Con la práctica, este grado de rigor normalmente relaja ligeramente.
Veamos la opcionalidad de los atributos en un diagrama:
VUELO
*fecha de salida
o
hora de salida
84
identificador único: Cada entidad debe ser únicamente identificable de forma que cada instancia
de la entidad esté separada y sea claramente identificable de todas las otras instancias de ese tipo
de entidad. El identificador único puede ser un atributo, una combinación de atributos, una
combinación de relaciones o una combinación de atributos y relaciones.
Una entidad puede tener más de un medio alternativo de identificación única. El método primario
se puede mostrar en el diagrama entidad-relación antecediendo a un atributo que forme el
identificador, una marca '#', y colocando una barra cruzada en el caso de una(s) línea(s) de
relación.
Figura 4.3
Muestra de identificadores únicos:
TARJETA DE emitida para

EMBARQUE ASIENTO
# *fecha emitida
usado mediante # *numero
# *hora emitida
emitida para en
utilizado
mediante compuesto de
VUELO
AVION
# *fecha de salida
# *hora de salida
de
planificado como
RUTA DE LINEA
AEREA
# *numero de vuelo
Así, pues, para identificar únicamente una tarjeta de embarque se necesita:
 la relación con el asiento, y por tanto el número de asiento.

 la relación con el vuelo, y por tanto la fecha y hora de salida
 la fecha y hora emitidas en el caso raro en que las tarjetas de embarque se hayan re emitido:
por ejemplo, para volver a sentar a una familia junta después de que alguien no haya
aparecido en el vuelo,
 como el identificador único del vuelo también incluye la relación con la ruta de la línea aérea,
se necesita el número de vuelo.
Tipo e Instancia: Es importante comprender que las definiciones que se acaban de ver de
entidad. relación, atributo e identificador único son definiciones que representan un tipo o clase de
concepto, no una instancia. A continuación se va a ver más detenidamente lo que se quiere decir
con esta afirmación.
85
Figura 4.4
Representación de instancias.
Tarjeta de embarque
CUPON emitida para
ASIENTO en AVION
*clase # *numero # *numero de

utilizado compuesto de
*estado *indicador de fumador registro
mediante
*indicador de *posicion *nombre
confirmado *tipo
o *descripcion
comentario
El diagrama anterior de tipos y clases se puede visualizar en tres dimensiones, como pilas de
tarjetas en un sistema de archivos para mostrar las instancias reales.
Cupones: Cada uno tiene su propia clase, estado, indicador de confirmación y comentarios.
Algunos todavía no están asociados con una instancia de asiento en un avión en particular, ya que
la relación es opcional.
Asientos: Cada uno tiene su propio número, el cual es único dentro del contexto del avión en el que
es fijo.
Aviones: Cada uno tiene su propio número de registro, nombre, tipo y descripción.
Por ejemplo en un momento dado, todos los asientos están asociados con un avión, pero sólo
algunos tienen cupones. Este momento representa solamente una instantánea del mundo real en
la que los asientos vacíos del avión son válidos.
Cuando se observan todos los cupones: antiguos, actuales y los que se acaban de preasignar para
vuelos próximos, se ve la situación siguiente:
Futuro, presente e historial de instancia.
El asiento del dibujo del avión no ha cambiado, pero ahora hay cientos de miles de cupones de los
que se han seleccionado todos los asignados (antiguos, actuales o preasignados) al asiento A1 del
avión con el número de registro G-ORCE.
Igualmente, las definiciones se deben aplicar de forma precisa a cada una y todas las instancias
del objeto - no simplemente al caso normal -. En este estudio, la flota de aviones puede que incluya
una pareja de los más antiguos, para los cuales es; vital conocer cuándo se comprobó por última
vez la disponibilidad de las piezas de repuesto. En este caso tan excepcional, si es muy
importante, las definiciones deben proporcionar la información que se requiera como una opción
que no se aplicará en el caso normal.
Todos los otros conceptos y definiciones en el modelo e relación también se aplican al tipo o clase
de objeto.
Normas de diseño
Las normas simples del diseño que siguen a continuación se han definido para que el diagrama
sea fácil de leer, aplicable para personas que necesiten trabajar con ellas y así maximizar la
calidad y la precisión.
 Diagrama de subconjunto:
86
Cuando se trata un área funcional en particular con un usuario o un diseño con los diseñadores, es
bueno crear un diagrama de subconjunto y expresar las ideas de nuevo más eficazmente como un
vehículo de comunicación con ese propósito.
 Esmerado y pulcro:
Hay que organizar el diagrama de forma que los recuadros de las entidades estén alineados y que
las líneas de las relaciones sean rectas en sentido horizontal o vertical. Hay que dibujar el menor
número de líneas cruzadas posible. Hay que evitar construir un diagrama que tenga demasiadas
líneas paralelas que están muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda
para evitar el sentimiento de congestión y utilice de vez en cuando la línea en diagonal para ayudar
a la estética diagrama.
 Etiquetado:
Hay que añadir un titulo y una fecha e identificar el autor/es de cada diagrama.
 Reconocimiento de patrones
La mayoría de las personas tienen la capacidad incorporada de reconocer formas y patrones en un
instante y por tanto pueden recordar fácilmente el tema. Los modelizadores pueden beneficiarse de
esto haciendo que cada diagrama sea claramente diferente en forma - el tamaño no parece afectar
el tema -. Posteriormente, se puede tratar con más productividad un modelo previamente
acordado.
La consecuencia será que si se producen varios diagramas con la misma forma o modelo la
capacidad de recordar el detalle se pierde rápidamente.
 Texto
Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las abreviaturas y las jergas.
Hay que utilizar las convenciones de lectura descritas anteriormente y leer todo el diagrama para
asegurarse de que es completo y preciso. Un buen diagrama entidad-relación debería ser
semánticamente completo. Para mejorar la comprensión y la precisión al leerlo, hay que añadir
adjetivos y ejemplos cuando sea necesario.
La mayor parte del texto debería estar alineado horizontalmente para facilitar la lectura. Se puede
utilizar más de una línea para un nombre de forma que se faciliten los problemas del diseño. Si
fuera necesario se deberían escribir los nombres de las relaciones a lo largo de las líneas, pero
normalmente se deberían poner al final de la línea y en los lados opuesto de la línea.
Figura 4.5
PRODUCTO clasificado por GRUPO DE

clasificación PRODUCTOS
para
Hay que centrar, alinear a la izquierda o a la derecha el texto consecuentemente, de forma que se
extraigan resultados de buena calidad.
 Grado de relación
Hay que situar la terminación de muchas - ramificación - de las relaciones a la izquierda o en la
parte superior de la línea de relación. Se ha probado, que esta técnica ha incrementado la
precisión del modelo forzando la consideración de las relaciones, desde las entidades que
aparecen con más frecuencia a las menos frecuentes.
La mayoría de las personas leen los diagramas de izquierda a derecha y de arriba abajo; por tanto,
esto sigue la ruta natural. A esto le ayuda el hecho de que los elementos, que aparecerán en la
parte inferior derecha del diagrama son entidades altamente significativas que se utilizan para
definir otras circunstancias; por ejemplo, compañía, producto, aeropuerto. Así, pues, leer hacia
ellas nos ayuda a definir las otras entidades en parte por su relación con estas entidades de
referencia.
87
 Tamaño y forma
El tamaño y la forma de las entidades no tienen una trascendencia especial. Así, pues. los
recuadros se pueden estirar, agrandar o reducir para ayudar al diseño del diagrama.
 Calidad
Cuando se utilizan estas convenciones tienden a aparecer similares en posiciones adyacentes del
diagrama. Esto es muy útil en la practica, ya que a menudo son las mismas cosas, aunque con
nombres distintos: hay que examinar los atributos, relaciones y las funciones comerciales que las
utilizan.
Para facilitar la comprensión de los conceptos hemos desarrollado una serie de ejemplos que
el alumno podrá consultar en la pagina de la asignatura. Archivos / BD.Archivos
Complementarios.
En general, el uso riguroso de las definiciones es todo lo que se necesita para identificar entidades,
atributos y relaciones, pero en la practica existen algunas formas mecánicas que ayudan durante el
aprendizaje .
Identificar entidades
Por definición, las entidades son cosas sobre las cuales las personas hablan, escriben, registran
información, y también sobre las que trabajan.
Una entidad es una cosa u objeto con significado, real o imaginado, acerca de la cual se necesita
información para conocerla.
Esta definición es útil y facilita el trabajo un poco mas. Pero, ¿por qué a veces es difícil
identificarlas?
 Ejemplos, sinónimos, homónimos y funciones:

Las personas a menudo hablan con ejemplos, analogías y dibujos. En lugar de hablar acerca de un
avión, hablan por ejemplo del Jumbo, del 747 y el Concorde. Para mayor confusión frecuentemente
se utilizan sinónimos: un sinónimo de avión podría ser aeroplano.
Los homónimos se encuentran donde la misma palabra puede tener mas de un significado
dependiendo del contexto. Por ejemplo la palabra programa, tiene muchos significados
alternativos: - un juego de instrucciones para un computador,
- una serie de sucesos,
- un curso de estudios,
- un plan de intenciones,
- una descripción de los actos de un concierto de música,
- lo que se podría ver en la televisión.
Las personas generalmente hablan de las funciones de las cosas particularmente de las personas
y de las organizaciones; estas funciones a veces son títulos de trabajos, otras veces
responsabilidades informales y otras los nombres que relacionamos con las personas.
Los plurales y otros términos gramaticales añaden una capa mas de confusión que hay que
atravesar.
Nuestro trabajo consiste en identificar la cosa esencial y subyacente, seleccionar una palabra
genérica con la que todo el mundo se encuentre feliz, y a continuación definir esa entidad.
 Documentos fuente
88
También se podrían analizar de forma similar documentos escritos. Los informes anuales de las
compañías que a menudo demuestran que las entidades de referencia realmente significativas son
una fuente fructífera, resultan ser de un valor especial.
Los formularios en papel pueden ser útiles, aunque tienden a ser una fuente mejor para los
atributos, ya que las secciones que se rellenan van casi siempre precedidas del nombre del
atributo.
 Sentido común
Finalmente hay que observar el contexto de la organización que se esta analizando. La mayoría de
las cosas que se ven resultan ser instancias de entidades.
Imagínese que se encuentra en una agencia de viajes. ¿Qué se ve? Obviamente se ven mesas de
despacho, sillas, un contador, teléfonos, puertas, ventanas, etc.
Estos elementos pueden que no sean significativos a no ser que se tengan en cuenta como
requisitos desde una perspectiva de recursos físicos, de inventario o de posesiones.
Por otro lado los elementos siguientes se pueden considerar muy importantes:
- folletos,
- horarios,
- mapas,
- impresos de reservas,
- condiciones para crédito,
- la oficina de cambio,
- etc.
Si se tienen que modelizar o no, debe ser determinado con los usuarios o mediante la
extrapolación de los sistemas existentes o los procedimientos que se deben suministrar.
El uso de su capacidad de observación, sentido común y de poderes lógicos de deducción añadirá
valores positivos a la calidad de los modelos.
Hay que recordar que cada entidad debe ser identificable de forma única y que debe tener al
menos dos atributos - y que ninguno de ellos sean relaciones - antes de que se haya terminado su
análisis. Por lo tanto la siguiente pregunta es muy directa y muy útil:
¿Cómo se identifica de forma única un .....<<nombre de la entidad>>.......?
Identificar atributos
Los atributos son la información que se necesita para saber acerca de las cosas.
A menudo, estas aparecerán como datos en un sistema informático o manual; por tanto, esta es
una buena fuente. Utilícela para la comprobación "de abajo arriba" bottom-up para asegurarse de
que no se ha perdido ningún atributo de otras fuentes tales como entrevistas.
Hay que recordar que un atributo es cualquier detalle que sirva para calificar, identificar, clasificar,
cuantificar o expresar el estado de una entidad o cualquier descripción de una cosa.
 Pregunte!
Cuando se ha identificado una entidad, hasta ahora lo mas fácil es preguntar a un usuario:
¿Qué información necesita conocer o mantener acerca de .......<<nombre de entidad>>?
Desafortunadamente también se van a obtener respuestas con otros conceptos, de forma que se
tendrá que analizar la respuesta con detalle.
 Formulario de papel
Examinando formularios de papel se encuentran fácilmente atributos en potencia. Hay que
observar los encabezamientos y las preguntas de los formularios en blanco. El mismo atributo
puede aparecer a menudo con nombre diferentes en formularios distintos.
 Archivos de computador
Los archivos de computador, definiciones de COBOL, esquemas de bases de datos, diseños de
pantallas, etc. suministran buena provisión de datos que pueden ser analizados.
89
Existe el peligro de que analizando impresos de papel y los archivos existentes del computador se
puedan reiterar sistemas obsoletos. Para evitar esto, hay que modelizar siempre primero la
necesidad, basada en entrevistas, y a continuación hay que comprobar los sistemas existentes por
omisión, una vez que se ha realizado la comprobación "de abajo arriba" bottom-up hay que volver
al usuario con pregunta como esta: <<¿Se necesita realmente esto todavía?>>
 Atributos citados
En una entrevista se puede ver que muchos atributos se citan directamente, pero hay que lograr
unirlos a sus entidades. Simplemente hay que preguntarse: <<¿Qué es lo que describe?>>
¿Qué describe tarifa aérea?
Es el billete o posiblemente la tarifa aérea estándar para un viaje.
¿Qué describe fecha?

Vuelo o reserva
¿A que se podría aplicar descuento?

De nuevo, el billete o posiblemente alguna forma de acuerdo estándar para reservas de volumen:
quizás una entidad perdida?
Pero tenga en cuenta que no debe deducir el significado de los atributos pensando que es una
obviedad. Pregunte al usuario indicado. Consultar todo tipo de obviedades previene futuros
problemas.
Identificar relaciones
Principalmente los sistemas de computadores dan a entender o explícitamente soportan las

relaciones en conversaciones y en impresos manuales.
Una relación es una asociación significativa nombrada entre dos cosas.
 De nuevo, pregunte
Se puede utilizar la misma técnica simple de hacer a personas la pregunta:
¿Me podría decir todas las formas diferentes en que se podría asociar a una persona con un
billete?
La respuesta probablemente será muy larga, aunque útil, y de muchas mas formas de las que se
intentaban, y probablemente se obtendrán palabras como estas:
- pasajero del billete,
- reservado por,
- cambiado por,
- inspeccionado por,
- emitido por.
Ahora probablemente estas palabras serán potencialmente útiles y abrirán el área de investigación
otra vez.
 Analizar entrevistas
Esta vez, al analizar el extracto de la entrevista anterior, de nuevo hay que buscar frases de enlace
entre nombres, ya que a menudo pueden sugerir relaciones.
Cada una de las líneas reales o destacadas en un impreso como este pueden ayudar a identificar
una relación. En primer lugar hay que identificarlo y seguidamente nombrarlo.
 Técnica de retícula
Hay que colocar todos los nombres de entidades, y a continuación hay que poner los nombres en
los recuadros que tengan relación significativa. Hay que tener en cuenta que pueden existir
diferentes asociaciones entre dos entidades.
90
Figura 4.6
PERSONA
PERSONA cientos AVION

posibles
AVION pilotado por alternativa a BILLETE

mantenido por
BILLETE reservado por ? reemplazo por RESERVA

pasajero de
RESERVA hecho por para emitido por subordinado a ORDEN DE

hecho para
COMPRA
¿bajo?
ORDEN DE aprobado por ? --- ---
COMPRA
Etcétera
Esta retícula puede sugerir muchas preguntas útiles de las relaciones posibles, pero también
puede hacer que se definan relaciones que sean importantes, que a continuación se tendrán que
eliminar.
 Archivos en soporte magnético para tratamiento informatizado

Finalmente, analizar la estructura de los archivos en soporte magnético en sistemas que necesitan
ser reemplazados provoca muchas ideas. Hay que trabajar con un diseñador de bases de datos
que comprenda el sistema actual y, a continuación, hay que buscar:
- punteros,
- claves externas,
- grupos de repetición,
- códigos estructurados,
todos los cuales implican relaciones posibles.
Para alcanzar el máximo potencial es importante que cualquier analista aprenda el significado de
las palabras, que tenga un vocabulario rico, que defina cualquier cosa importante que se encuentre
y que escuche cuidadosamente lo que realmente se dice.

Estos temas serán abordados en detalle en la pagina de la asignatura
Veamos ahora algunos ejemplos del uso normal del grado de una relación y su opcionalidad.
Obligatorio a opcional:
A B
91
Muchos a uno: Esta es con mucho la forma mas común de relación. Implica que cada una de las
instancias de A solo puede existir dentro del contexto - nombrado - de una - y solo una - B. Por otro
lado, las B pueden existir con asociaciones o sin ellas a las A.
Opcional a opcional
A B
Se utilizan ocasionalmente. Pueden existir tanto la A como la B sin relación entre ellos.
Obligatorio a obligatorio
A B
Esta es una construcción muy poderosa, que implica que una instancia de B no se puede crear sin
crear a su vez al menos una A asociada. En el ejemplo, un BILLETE no es significativo a no ser
que se componga al menos de un CUPON; hasta entonces solo es una hoja de papel.
Opcional a obligatorio
A B
Es una extraña construcción. Ocurre cuando B es un concepto inventado que se compone siempre
de un grupo preciso de A. Las A pueden existir por si solas. En un examen mas detallado, estas
relaciones se convierten a menudo en muchos a muchos.
Uno a uno:
Obligatorio a opcional
A B
Es un caso raro.
Opcional a opcional
A B
Es un caso raro.
92
A B
Es un caso muy extraño. Casi siempre es falso.

Con casi todas las relaciones de uno a uno, un examen mas detallado muestra que A y B son
realmente vistas o conjuntos diferentes de los mismos, quizás con nombres diferentes y con
relaciones y atributos diferentes.
Muchos a muchos:
Opcional a opcional
A B
Esta construcción es muy común al principio de un análisis e implica una relación que no se
comprende del todo y necesita mas resolución, o bien es solo una asociación simple colectiva, una
lista con dos formas.
A B
Es un caso extraño. Estas relaciones deberían resolverse siempre con mas detalle.
A B
Es imposible. Esta relación implica que no puede existir una instancia de una A sin una B y
viceversa. En la practica, se ha visto siempre que construcciones de este tipo no son muy precisas.
Relaciones recursivas
Muchos a uno
93
Es un bucle infinito. No hay parte superior.
Obligatorio a obligatorio A
Es imposible.
Opcional a obligatorio
Es imposible
Opcional a opcional
Es muy común y a menudo se llama una "oreja de cerdo opcional". Este muestra una jerarquía
simple a cualquier nivel y se utiliza generalmente para cosas tales como jerarquías de
organizaciones, clasificaciones de productos, marketing, etc.
Uno a uno
Es imposible
94
Es imposible.
Opcional a opcional A
Es extraño pero muy útil. Se podría utilizar para relaciones que muestran una alternativa.
Muchos a muchos
Opcional a opcional
Es muy frecuente al principio. A menudo implica una estructura de "catalogo de materiales", que
muestra la composición y descomposición de los componentes.
Por ejemplo:
Cada COMPONENTE se puede componer de uno o mas (otro) COMPONENTEs y cada

COMPONENTE se puede utilizar en uno o mas COMPONENTEs
Es imposible
Es imposible
95
7. Diseño de base de datos relacional
Paso 1: Cada entidad simple se traduce a una tabla. Una entidad simple es la que no es un
subtipo y tiene subtipos por si misma. Una norma útil es utilizar la forma plural de la entidad para el
nombre de la tabla.
Paso 2: Cada atributo se traduce a una columna candidata del mismo nombre, y es el momento en
que se puede elegir un FORMATO mas preciso.
 Los atributos opcionales se convierten en columnas nulas.
 Los atributos obligatorios se convierten en columnas no nulas.
Paso 3: Los componentes del identificador único de la entidad se convierten en la clave primaria
de la tabla. Hay que recordar que puede haber mas de un identificador único para una entidad, y
se elige el mas usado.
También hay que recordar que una entidad solo se puede identificar por una combinación de
atributos y/o relaciones. Cuando se usan las relaciones, hay que seguir la relación y hay que
recoger como columnas una copia de los componentes de identificación únicos de la entidad en el
último extremo de la relación como parte de la clave primaria. (Esto puede resultar recursivo hasta
que se encuentren eventualmente los atributos.)
Durante este proceso, los nombres de terminaciones de relaciones y/o nombres de entidades se
utilizan con los nombres de los atributos, para sugerir los nombre de columnas únicos y poderse
usar como parte de claves externas.
Paso 4: Las relaciones de muchos a uno (y de uno a uno) se convierten en claves externas. Es
decir, hay que recoger una copia del identificador único de cada entidad referenciada de la
terminación uno y utilizarlo como columna candidatas.
 Relaciones opcionales crean columnas nulas
 Relaciones obligatoria crean columnas no nulas
Figura 4.7
RUTAS DE
LINEAS AEREAS
desde origen de AEROPUERTO
# *numero de vuelo
hora de salida # *codigo
programada *nombre
hacia destino a
operado
por
encargada
de
LINEAS AEREAS
# *codigo
*nombre dentro de
la organización
padre de
96
AEROPUERTOS
Codigo car 4 not null clave primaria
Nombre car 40 not null
LINEAS AEREAS
Codigo car 4 not null clave primaria
Nombre car 40 not null
Codigo de linea car 4 null clave externa desde
aérea asociada relacion recursiva
calificada tanto por
nombres de entidad
como de relacion
RUTA DE LINEAS AEREAS

Numero de vuelo entero 4 not null claves primaria
Codigo de lineas aereas *car 4 not null
Codigo de aeropuerto origen car 4 not null claves externas
hasta linea area
Codigo de aeropuerto destino car 4 not null y aeropuerto
Hora de salida programada fecha null
Los pasos 1 y 4 representan la mayoría de las situaciones normales de diseño lógico. Antes de
examinar los casos mas complejos, en donde se utilizan la exclusividad y los subtipos, hay que
observar los índices.
Paso 5: Diseño de índices
Hay que crear índices candidatos para cada:

 Clave primaria (índice único)
 Claves externas, y
 Las sugeridas por cualquier función: matriz de atributo
Hay que recordar que la clave primaria y las claves externas se pueden componer cada una de
mas de una columna.
Cuando una columna es la primera columna citada en un índice multicolumna, normalmente no
tiene que ser indexada para otros propósitos.
Un análisis detallado y a conciencia puede elaborar definiciones de función que citen el uso de
atributos para condiciones de selección. En estos casos se puede haber creado una matriz de
función hacia atributos, en donde los atributos mas usados, cuando se estructuran en columnas de
tabla, se utilizan como índices candidatos.
Ejemplo:
Los índices de las tres tablas anteriores serian de la forma siguiente:
Codigo AEROPUERTO (Índice único)

Codigo AEROLÍNEAS (Índice único)
Codigo de linea aérea asociada AEROLÍNEA (Índice no único)
Codigo de linea aérea y numero de vuelo
RUTA LINEAS AEREAS (Índice multicolumna único)
Codigo aeropuerto origen RUTAS LINEAS AEREAS (Índice no único)
Codigo aeropuerto destino RUTAS LINEAS AEREAS (Índice no único)
97
Paso 6: Diseño para subtipos
Un subtipo de entidad es simplemente una entidad con sus propios atributos o relaciones, pero
también hereda cualquier atributo y relación de su entidad padre (supertipo) y así en adelante
hasta la jerarquía de supertipos.
Para quienes ya hayan utilizado estructuras de datos orientadas a objetos con propiedades de
herencia, este concepto les resultara familiar
Existen dos alternativas básicas, cada una con sus ventajas e inconvenientes:
 Todo en una tabla
 Tabla para subtipos
Todo en una tabla:
Se ha creado una tabla para la entidad de supertipo externa y en cada uno de los subtipos se han
podido crear vistas relacionales opcionales. Como antes, los atributos u las relaciones de muchos
a uno hacen que se creen las columnas de datos u las claves externas.
Una vista es un medio de acceder a un subconjunto de una tabla como si fuera una segunda tabla.
La vista se puede limitar a un subconjunto de columnas o a filas especificas, y puede cambiar los
nombres de las columnas. Estas vistas simples se pueden utilizar para la actualización, así como
para las recuperación de datos. también se pueden crear vistas mas complejas incluyendo datos
de muchas tablas y datos derivados, pero normalmente solo para acceso de lectura.
El mismo proceso ocurre para cada subtipo y para cada uno de sus subtipos y así sucesivamente.
La diferencia es que todos los candidatos creados para subtipos son no nulos (opcional). Un
atributo obligatorio (o relación) de un subtipo no sería aplicable en otro; por tanto, todos deben ser
opcionales, y su integridad debe ser reforzada por el software de aplicación o por una vista con
opción de comprobación reforzada.
Se debe añadir al menos una columna extra no nula a la tabla para indicar TIPO, y así se convierte
en parte de la clave primaria.
Por ejemplo:
TIPO char 4 not null con un valor predefinido para cada subtipo.
Se puede crear una vista relacional para cada uno de los subtipos, y de esta forma permitir que el
procesamiento acceda solo a los datos que necesita , como se especifica en el nivel de gestión
para las funciones de gestión definiendo acciones en entidades que son subtipos. Deben incluir
columnas derivadas para el subtipo, todos los subtipos y supertipos. ES posible añadir la cláusula
WHERE a la vista que comprueba la validez de claves externas y la opcionalidad de columnas en
el contexto de la columna Tipo. En algunas implementaciones relacionales, cuando se inserta o se
actualiza dicha vista, se puede utilizar WHIT CHECK OPTION (CON OPCION DE
COMPROBACION) para reforzar estas condiciones dentro del sistema de gestión de bases de
datos.
Nota: Sin embargo, se recomienda que dicho reforzamiento se integridad se añada al código de
aplicación, para asegurar que los usuarios puedan recibir mensajes del contexto cuando se infrinja
la restricción o limitación de integridad.
98
Figura 4.8
LINEA DE PEDIDOS
LINEAS DE
PEDIDO DE para
AEROPUERTO
PRODUCTO
mostrado en # *codigo
*cantidad
*nombre
OTRA LINEA DE
PEDIDO
ºcomentario sobre
impuestos
#*numero
ºdescripcion
parte de
compuesto de
PEDIDO
# *numero
Hay que tener en cuenta que existen dos columnas llamadas numero calificadas por adjetivos para
mantener claro su significado. Además, tanto cantidad como código de producto se han hecho
opcionales a la vez que ninguna se aplica a OTRA LIENA DE PEDIDO.
Se ha añadido una columna tipo para poder distinguir entre subtipos de LINEA DE PEDIDOS. Una
convención simple seria utilizar un código <<POL>>, que significa LINEA DE PEDIDO DE
PRODUCTO, y <<OOL>> que significa OTRA LINEA DE PEDIDO: de aquí una columna de tres
caracteres.
Las vistas relaciónales posibles, como se define en SQL son las siguientes:
CREATE VIEW OTRAS_LINEAS_PEDIDOS AS

SELECT LINEA_NUMERO,
PEDIDO_NUMERO,
DESCRIPCIÓN,
COMENTARIO_IMPUESTOS,
TIPO
FROM LINEA_DE_PEDIDOS
WHERE TIPO= ‘OOL’
WITH CHECK OPTION
CREATE VIEW LINEA_PEDIDO_PRODUCTO AS

SELECT LINEA_NUMERO,
PEDIDO_NUMERO,
DESCRIPCIÓN,
CANTIDAD,
CODIGO_PRODUCTO
TIPO
99
FROM LINEA_DE_PEDIDOS
WHERE TIPO= ‘POL’
AND CANTIDAD NOT NULL
AND EXISTS (SELECT NULL
FROM PRODUCTOS
WHERE PRODUCTOS.CODIGO =
LINEA_DE_PEDIDOS.CODIGO_PRODUCTO)
WITH CHECK OPTION
Observe que ambas vistas comprueban la columna tipo y la segunda vista también refuerza no
nulo en cantidad y asegura que existe un código de producto que se corresponde con un código ya
existente en la tabla PRODUCTOS
Tabla para subtipo
Las tablas se han creado para subtipos de forma que abarquen todas las instancias posibles.
Donde existen muchos niveles de subtipos es normal utilizar el primer nivel hacia abajo y crear
tablas para todos los subtipos de ese nivel. Se podrían crear para mas subtipos. Para el subtipo se
rea una tabla con columnas candidatas, creándose para cada atributo y para cada relación de
muchos a uno. Sobre una base similar, se crean columnas para el supertipo (y así sucesivamente
subiendo hasta la jerarquía de subtipos); cada una de estas columnas heredadas mantiene su
opcionalidad.
Donde subtipo es por si mismo un supertipo, las columnas opcionales candidatas se han creado
también para cada uno de sus subtipos (y así sucesivamente bajando hasta la jerarquía de
subtipos)
también se puede crear una vista UNION para permitir procesar el supertipo.
Figura 4.9
B
*b1
*b2
F
#*f
D
ºd
un hijo de
E
ºe
el padre de
C
#*c1
ºc2
#*a1 G
ºa2 #*g
En el ejemplo anterior se ha supuesto que se ha creado una tabla para el subtipo B.
100
Este es un ejemplo complejo y merece la pena hacer un estudio cuidadoso, ya que se abarcan la
mayoría de las circunstancia con las que se encuentra.
B
b1 not null desde el subtipo B
b2 null
a1 not null clave primaria desde el supertipo A
G_g not null
tipo not null
a2 null desde el subtipo D y hecho opcional
d null
F_f null
e null desde el subtipo E
padre_a1 null desde relación entre E y B,
padre_G_g null duplicando la clave primaria de
padre_tipo null nuevo para el padre, y haciéndolas
opcionales
A continuación se va a observar la vista del subtipo E
CREATE VIEW E AS
SELECT e,
b1,
b2,
a1,
G_g,
tipo,
a2,
padre_a1,
padre_G_g,
padre_tipo
FROM B
WHERE TIPO= ‘E’
AND e not null
AND EXISTS (SELECT Null
FROM B
WHERE B.a1 = E.Padre_a1
AND B.G-G = E.Padre_G_g
AND B.tipo = E.Padre_Tipo)
WITH CHECK OPTION
Y para observarlo completo hay que observar la vista UNION para A:
CREATE VIEW A AS
SELECT *
FROM B
UNION
SELECT *
FROM C
101
Observe que el * anterior es una nota taquigráfica, que se puede utilizar con el SGBDR ORACLE
para seleccionar todas las columnas.
Ventajas e Inconvenientes
Todo en una tabla Tabla para subtipo

Ventajas Ventajas
Todo en un lugar Las normas se alinean mas claramente en los
subtipos
Fácil de acceder a supertipo y subtipos Los programas funcionan solo en tablas que se
relacionan con los subtipos necesitados
Se necesitan menos tablas

Inconvenientes Inconvenientes
Altamente genérico Muchas tablas extras
La lógica necesita ofrecer diferentes conjuntos Columnas confusas en la visión UNION

de columnas e integridad
Embotellamiento potencial, particularmente con Problemas potenciales de configuración en la

algunos mecanismos de bloqueo vista UNION
Las columnas de subtipos deben ser todas Las actualizaciones no son posibles en el
opcionales supertipo; de esta forma se inhiben las funciones
a las que se refieren
En algunas realizaciones, SGBDR se puede
extender fuera de las columnas o abusar del
espacio para valores nulos
Paso 7: relación exclusiva
Existen dos métodos básicos de manejar diseños de bases de datos para utilizarse con relaciones
exclusivas. Estos son:
 Dominio común
 Claves externas explicitas
Dominio común:
Si las claves externas que quedan se encontraran en el mimo dominio (formato idéntico), entonces
habría que crear dos columnas candidatas:
 identificador de relación
 identificador de entidad
La columna de identificador de relación se utilizaría para diferenciar entre las distintas relaciones
abarcadas por el arco exclusivo.
La columna del identificador de entidad se utilizaría para mantener valores para el valor del
identificador único de la entidad al final de la relación apropiada.
102
Figura 4.10
para
ENTRADA DE UNIDAD DE
HOJAS PROYECTO
HORARIAS # *codigo (car 7)
*numero de horas mostrado en *descripción
*fecha de comienzo
º fecha final
acerca de
para
vigilado por
PERSONA ACTIVIDAD FUERA

mostrado en DE PROYECTO
#*codigo (car 7)
*descripción
ej.enfermedad
Para la tabla ENTRADA DE HOJAS HORARIAS, las columnas candidatas para ejecutar las
relaciones para UNIDAD DE PROYECTO o para ACTIVIDAD FUERA DE PROYECTO seria:
Hoja_horaria_para char 3 not null (valor ‘PU’ y ‘NPA’)

Codigo_actividad char 7 not null
Hay que tener en cuenta que los nombres significativos se han elegido para ambas columnas,
CODIGO_ACTIVIDAD tomaría los valores de los códigos UNIDAD_DE_PROYECTO o
ACTIVIDAD_FUERA_DE PROYECTO cuando sea apropiado. Para estas relaciones obligatorias
ambas columnas son no nulas.
Claves Externas Explicitas
Si las claves externas resultantes no estuvieran en el mismo dominio, habría que crear las
columnas explicitas de clave externa para cada relación abarcada por el arco exclusivo, y hacer
nulas (opcionales) las columnas resultantes. El código de aplicación debe reforzar la norma que
solo puede introducir uno y que debe hacerlo si las relaciones son obligatorias.
Véase de nuevo el ejemplo de la hora de horas, pero esta vez con el código de unidad de proyecto
como un entero.
103
Figura 4.11
para
UNIDAD DE
ENTRADA DE PROYECTO
HOJAS HORARIAS # *codigo (car 7)
mostrado en
para
ACTIVIDAD FUERA
mostrado en DE PROYECTO
#*codigo (car 7)
Las columnas candidatas resultantes son:
codigo_unidad_proyecto integer 5 null

codigo_atividad_fuera_de_proyecto char 7 null
Ventajas e Inconvenientes
Dominio común Claves externas explicitas

Ventajas Ventajas
Solo se necesitan dos columnas Condiciones de unión son explicitas
Opcionalmente reforzado por SGBDR

Inconvenientes Inconvenientes
Todas las uniones deben usar ambas columnas Excesivas columnas
Opcionalidad y usos deben reforzarse por la
aplicación
Modelos alternativos de entidad y su impacto en el diseño
Las convenciones de modelización mostradas permiten modelizar los mismos conceptos de

diferentes formas. A continuación se van a observar tres alternativas y como se puede ver afectado
el diseño.
Figura 4.12
B
A
Un arco simple exclusivo, como se vio al principio de este apéndice

104
Figura 4.13
A
B
A1
A2
C
Este es el modelo preferido, siempre y cuando los subtipos A1 y A2 existan funcionalmente. Ahora
la implementación de claves externas no tiene que preocuparse de la entidad <<padre>>, a la que
va señalando la relación.
Figura 4.14
D
A
B
Una vez mas se prefiere a la alternativa 1, ya que el identificador único de D se puede utilizar para
B y para C. Este modelo, desde luego, solo es bueno si existe un supertipo funcional D.
Las alternativas 2 y 3 ofrecen la oportunidad de preguntar si estos conceptos de A1 y A2 (quizás
con sus propios atributos/relaciones o funciones) y de D (con sus propios atributos, etc.) existen
realmente.
Pasos siguientes:
Una gran parte del diseño anterior de bases de datos por defecto se lleva a cano automáticamente,
a petición del usuario, guiándose con el software CASE.
Pero esto es solo el punto de partida, ya que el diseño de la base de datos ahora necesita un
escrutinio cuidadoso para asegurar que proporciona un apoyo completo de una forma de
realización/espacio eficiente para los programas, peticiones especificas, archivos, etc. Esto puede
requerir una desnormalización cuidadosa, una replica controlada en la red y un diseño físico
detallado de índices y utilización de discos.
105
Unidad V: Lenguaje de Consulta Estructurada
En esta unidad abordamos la parte del modelo relacional que se ocupa de los datos, mas
específicamente de la manipulación de datos. Desglosando el termino "manipulación" nos
referimos a la obtención de consultas y la actualización de datos utilizando un lenguaje
denominado Structured Query Language (SQL). Previamente a conocer la sintaxis del lenguaje;
estudiamos las operaciones el álgebra relacional que nos ayudan a formular expresiones que luego
convertiremos en cláusulas propias del lenguaje SQL utilizado para las bases de datos.
Además profundizaremos características avanzadas del lenguaje y algunos objetos útiles para
mantener la integridad de una base de datos que esta siendo manipulada.
1. Algebra relacional
2.1 Definición de Datos
2.2 Manipulación de Datos
3. SQL Avanzado
1.1 Vistas
1.2 Independencia de Datos
1.3 Valores nulos
1.4 Disparadores
 Incorporar la sintaxis del álgebra como una forma simple de resolver consultas de
manipulación de datos de una base de datos.
 Aprender a resolver consultas de manipulación de datos con el lenguaje de consulta
estructurado (SQL).
 Valorar la importancia del lenguaje de definición de datos. Aprender a definir una base
de datos.
 Comprender el concepto de disparadores y su importancia.
 Comprender el concepto de vistas y su importancia.
 Valorar la importancia de trabajar en un entorno que permita mantener la
independencia de los datos.
1. Algebra relacional
Hasta ahora hemos desarrollado temas relacionados con la estructura de una base de datos, sus
propiedades y como optimizar las estructuras de almacenamiento para mejorar la carga y la
recuperación de los datos, pero, ¿qué pasa con los datos que queremos almacenar en una base
de datos? Necesitamos cargarlos, modificarlos, consultarlos. Para esto en esta sección nos
introducimos en el álgebra relacional que nos brinda un conjunto de operaciones que nos permite
elaborar una sintaxis para poder ilustrar funciones de manipulación que deseamos realizar con los
datos de una base de datos.
Estas operaciones constituyen un lenguaje de manipulación de datos (DML).
La parte manipulativa es la tercera y la ultima parte del modelo relacional, y se divide a su vez en
dos partes. Un conjunto de operadores que forman el "álgebra relacional", y una operación de
asignación que asigna el valor de alguna expresión arbitraria del álgebra a una relación nombrada.
Este conjunto de operadores de alto nivel operan sobre relaciones. Cada uno de estos operadores
toma una o dos relaciones como entrada y produce una nueva relación como salida. Por ejemplo,
supongamos que se desean los nombres de todos los peces rojos del la base de datos del acuario.
La siguiente operación extrae es información al aislar primero las tuplas de fcolor = rojo, y
luego retener solo la columna fnombre. Visualizamos la transformación como sigue:
106
PEZ
Pnro Pnombre pcolor Ppeso tnro snro
438 Fran negro 61 55 74
911 Helen azul 48 44 74
302 Jill rojo 28 38 17
<........>
Fnombre
Albert
George
Jill
Kilroy
Los operadores del álgebra relacional son los que enumeramos a continuación y a grandes rasgos
funcionan como sigue:
 Restricción: Extrae las tuplas especificadas de una relación dada, o sea restringe la relación
solo a las tuplas que satisfagan una condición dada.
 Proyección: Extrae los atributos especificados de una relación dada
 Producto: Tomando dos relaciones especificadas, construye una relación que continúen todas
las combinaciones posibles de tuplas, una de cada una de las relaciones.
 Unión: Construye una relación formada por todas las tuplas que aparecen en las dos
relaciones especificadas.
 Intersección: Construye una relación formada por aquellas tuplas que aparezcan en las dos
relaciones especificadas.
 Diferencia: Construye una relación formada por todas las tuplas de la primera relación que no
aparezcan en la segunda de las dos relaciones especificadas.
 Reunión: A partir de dos relaciones especificadas, construye una relación que contiene todas
las posibles combinaciones de tuplas, una de cada una de las dos relaciones, tales que las dos
tuplas participantes en una combinación dad satisfagan alguna condición especificada.
107
 División: Toma dos relaciones, una binaria y una unaria, y construye una relación formada por
todos los valores de un atributo de la relación binaria que concuerdan - en el otro atributo - con
todos los valores en la relación unaria 1.
Figura 5.1. Los ocho operadores originales (panorama general)

Observe que el resultado de cada una de las operaciones es por supuesto otra relación. Entonces
como el resultado de cualquier operación es un objeto del mismo tipo que los operandos - todos
son relaciones- el resultado de una operación puede convertirse en operando de la otra. Así pues,
es posible obtener la proyección de la unión, o una reunión de dos restricciones, etc. Dicho de otro
modo es posible escribir expresiones relacionales anidadas, es decir , expresiones en las cuales
los operandos mismos están representados mediante expresiones y nos solo mediante nombres.
Por cierto, cuando decimos que el resultado de toda operación es otra relación, estamos hablando
108
desde un punto de vista conceptual. No queremos sugerir que el sistema deba siempre materializar
el resultado de cada operación individual. Por ejemplo, supongamos que estamos tratando de
calcular una restricción de una reunión; al construirse cada tupla de la reunión, el sistema puede
aplicar de inmediato la restricción a la tupla para ver si debe incluirse en el resultado final, y
desecarla en ese momento si no. En otras palabras , el resultado intermedio producido por la
reunión podría no existir nunca en si mismo como una relación materializada por completo. Como
regla general el sistema trata hasta donde puede de no materializar resultados intermedios en su
totalidad, por razones de desempeño.
Vamos a incluir la base de datos simple que utilizaremos para realizar los ejemplos de las
operaciones del álgebra relacional.
Los proveedores los representaremos con la relación S
--- ---- --------- ----------- ---------

S S# SNOMBRE SITUACION CIUDAD
--- ---- --------- ----------- ---------
S2 Jaime 10 París
S3 Bernal 30 París
S5 Aldana 30 Atenas
Las partes las representaremos con la relación P

--- ---- --------- ------- ------- --------
P P# PNOMBRE COLOR PESO CIUDAD
--- ---- --------- ------- ------- --------
P1 Tuerca Rojo 12 Londres
P2 Perno Verde 17 París
P3 Birlo Azul 17 Roma
P4 Birlo Rojo 14 Londres
P5 Leva Azul 12 París
P6 Engrane Rojo 19 Londres
Los envios los representamos con la relación SP
--- ---- ----- -----

SP S# P# CANT
--- ---- ----- -----
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P3 200
S4 P2 200
S4 P4 300
S4 P5 400
Una sintaxis para el álgebra:
Como se explico anteriormente, una relación tiene dos partes, una cabecera y un cuerpo; la
cabecera es el conjunto de nombres de atributos y el cuerpo el conjunto de tuplas o sea los datos.
Ahora bien, toda relación nombrada - relación base almacenada en la base de datos- tendrá una
cabecera, pero ¿que pasa con las no nombradas o resultantes?. Es importante que una relación
109
resultante tenga un conjunto apropiado de nombres de atributos ya que esa relación puede ser el
resultado de una expresión anidada dentro de otra mas grande, y obviamente necesitamos alguna
forma de referirnos a los atributos del resultado de la expresión. Introduciremos un nuevo operador
RENAME (renombrar) como paso previo para lograr este objetivo. Veamos un ejemplo:
S RENAME CIUDAD AS SCIUDAD
El operador RENAME toma una relación especificada S y crea una copia nueva de esa relación
con un nombre diferente en uno de sus atributos SCIUDAD en vez de CIUDAD como posee la
relación original; los demás nombres de atributos se heredan sin modificaciones.
La sintaxis que sugerimos no se sugiere para lenguaje destinado a usuarios finales pero si se
sugiere como base sólida para los análisis del resto del unidad:
expresión
: := expresión-de-una-relación I expresión-de-dos-relaciones
expresión-de-una-relación
: := renombrado I restricción I proyección
renombrado
: := término RENAME atributo AS atributo
término
::= relación | ( expresión )
restricción
: := término WHERE comparación
proyección
: := término | término [ listaconcomas-de-atributos ]
listaconcomas-de-atributos
::= atributo | atributo, listaconcomas-de-atributos
expresión-expresion-de-dos-relaciones
: := proyección operación-binaria expresión
operación-binaria
: := UNION | INTERSECT | MINUS | TIMES | JOIN | DIVIDEBY
Figura 5.2: Una gramática BNF para el álgebra relacional

 Las dos categorías "relación" y "atributo" representan respectivamente un nombre de relación y

un nombre de atributo.
 La categoría "comparación" representa una operación escalar sencilla de comparación entre
dos valores escalares: =, <>, >, etc. Un valor escalar, a su vez, puede ser un valor de atributo,
representado por su nombre, o bien un literal escalar.
 Advierta que la gramática implica un empleo abundante de paréntesis en expresiones
complejas con objeto de forzar un orden deseado de evaluaciones de subexpresiones.
Operaciones tradicionales de conjuntos:
En matemáticas, la unión de dos conjuntos es el conjunto de todos los elementos pertenecientes a

uno de los conjuntos originales, o a ambos. Como una relación es, en términos informales, un
conjunto (de tuplas), es posible construir la unión de dos relaciones: el resultado será una conjunto
formado por todas las tuplas que aparecen en ambas relaciones. Aunque el resultado no es una
relación - es un conjunto - las relaciones no pueden contener una mezcla de diferentes tipos de
tupla, deben ser "homogéneas en sus tuplas", y desde luego queremos que el resultado sea una
relación. Por tanto, la unión incluida en el álgebra relacional es la unión matemática completamente
general ; mas bien es una forma limitada de unión, en la cual se obliga a las dos relaciones de
2
entrada a tener lo que podríamos llamar "la misma forma" .
110
Diremos que dos relaciones son compatibles respecto a la unión si y solo si sus cabeceras son
idénticas; lo cual significa que:
a) tienen el mismo conjunto de nombres de atributos - o sea que deben tener el mismo grado-
b) los atributos correspondientes se definen sobre el mismo dominio.
La union las interseccion y la diferencia requieresn todas operandos compatibles respecto a la

union.
 Unión
Sean dos relaciones A y B compatibles respecto a la unión, A UNION B, resulta una relación cuya
cabecera es idéntica a la de A o B y cuyo cuerpo esta formado por todas las tuplas que pertenecen
a A y todas las tuplas que pertenecen a B.
 Intersección
Sean dos relaciones A y B compatibles respecto a la unión, A INTERSECT B, resulta una relación
cuya cabecera es idéntica a la de A o B y cuyo cuerpo esta formado por todas las tuplas que
pertenecen tanto a A como a B. La misma tupla es idéntica en las dos relaciones A y B.
 Diferencia
Sean dos relaciones A y B compatibles respecto a la unión, A MINUS B, resulta una relación cuya
cabecera es idéntica a la de A o B y cuyo cuerpo esta formado por todas las tuplas que pertenecen
a A pero no pertenecen a B.
111
---- -------------- ---------------- ----------- ---- ------------ ---------------- ----------
A S# SNOMBRE SITUACIóN CIUDAD B S# SNOMBRE SITUACIóN CIUDAD
---- -------------- ---------------- ----------- ---- ------------ ---------------- ----------
Sl Salazar 20 Londres Sl Salazar 20 Londres
S4 Corona 20 Londres S2 Jaimes 10 París
(a) Unión (A UNION B)
---- ------------ ---------------- ----------

S# SNOMBRE SITUACIóN CIUDAD
---- ------------ ---------------- ----------
Sl Salazar 20 Londres
S2 Jaimes 10 París
(b) Intersección (A INTERSECT B)

---- ------------ ---------------- ----------
---- ------------ ---------------- ----------
Sl Salazar 20 Londres
(c) Diferencia (A MINUS B)

---- ------------ ---------------- ----------
---- ------------ ---------------- ----------
(d) Diferencia (B MINUS A)

---- ------------ ---------------- ----------
---- ------------ ---------------- ----------
S2 Jaimes 10 París
Figura 5.3 Ejemplos de unión, intersección y diferencia

 Producto cartesiano ampliado
En matemáticas, el producto cartesiano de dos conjuntos es el conjunto de todos los pares

ordenados de elementos tales que el primer elemento de cada par pertenece al primer conjunto y
el segundo elemento de cada par pertenece al segundo conjunto. Así el producto cartesiano de
dos relaciones seria un conjunto de pares ordenados de tuplas no de pares ordenados. Por tanto la
versión del producto cartesiano en el álgebra relacional es una forma ampliada de la operación en
la cual cada par ordenado de tuplas es reemplazado por la tupla resultante de la combinación de
3
las dos tuplas en cuestion ; donde combinación significa en esencia unión. Veamos un ejemplo.
Dadas dos tuplas: - mostramos los nombres de atributos para hacerlas mas explícitas-
(A1:a1, A2:a2, ..., Am:am ) y (B1:b1, B2:b2,...,Bn:bn)
la combinación de las dos es la tupla única
(A1:a1, A2:a2, ..., Am:am ,B1:b1, B2:b2,...,Bn:bn)
112
Ahora bien, la cabecera resultante no es mas que la combinación de las cabeceras de las
relaciones de entrada, por lo tanto se presentara un problema si esas dos cabeceras tienen algún
atributo en común, si sucediera esto debemos emplear antes el operador RENAME (renombrar)
para modificar de manera apropiada los nombres de atributos. Diremos entonces que dos
relaciones son compatibles respecto al producto si y solo si sus cabeceras son disjuntas - no tienen
nombres de atributos en común -.
Ahora si definimos el producto cartesiano.
Sean dos relaciones A y B compatibles respecto al producto, A TIMES B, resulta una relación cuya
cabecera es la combinación de las cabeceras de A y B y cuyo cuerpo esta formado por el conjunto
de todas las tuplas t tales que t es la combinación de una tupla a perteneciente a A y una tupla b
perteneciente a B.
Queremos aclarar que el producto cartesiano se incluye en el álgebra relacional por razones
conceptuales, ya que es necesario como paso intermedio para otras operaciones como la "reunión
theta". Pero el producto cartesiano en si no tiene mucha importancia practica.
--- ---
A S# B P#
--- ---
Sl Pl
s2 P2
S3 P2
S4 P4
S5 P5
P6
Producto cartesiano (A TIMES B)

--- ---
S# P# ... ... ... ...
--- ---
Sl Pl S2 Pl S3 Pl S4 Pl S5 Pl
Sl P2 S2 P2 S3 P2 S4 P2 S5 P2
Sl P3 S2 P3 S3 P3 S4 P3 S5 P3
Sl P4 S2 P4 S3 P4 S4 P4 S5 P4
Sl P5 S2 P5 S3 P5 S4 P5 S5 P5
Sl P6 S2 P6 S3 P6 S4 P6 S5 P6
.... ... ... ... ...
Figura 5.4 Ejemplo de producto cartesiano

Operaciones relacionales especiales
Nos ocuparemos ahora de las operaciones relacionales especiales, estas operaciones estas
extraídas del libro de C. J. Date, de donde hemos seleccionado las más útiles. Ellas son
restricción, proyección, reunión natural y división.
 Restricción
Si decimos que theta es la representación de cualquier operador de comparación escalar simple -

=, <>, <=, etc.-, y X, Y son atributos de la relación A, definidos bajo un mismo dominio. La
restricción theta de la relación A según los atributos X y Y:
A WHERE X theta Y
113
resulta una relación con la misma cabecera que A y con un cuerpo formado por el conjunto de
todas la tuplas de A que satisfacen la comparación "X theta Y", dicho de otro modo la comparación
"X theta Y" resulta "verdadera".
También se puede especificar un valor literal en vez del atributo X o Y, como se muestra en el
ejemplo:
A WHERE X theta literal
Note que el operador restricción theta produce en realidad un subconjunto "horizontal" de las tuplas
de la relación para las cuales se satisface una comparación especificada.
La comparación de restricción permite solo una comparación simple en la cláusula WHERE

(donde) pero se puede ampliar la definición a una forma en la cual la expresión condicional de la
cláusula WHERE este formada por una combinación booleana de tales comparaciones simples,
según se indica con las siguientes equivalencias:
1- A WHERE c1 AND c2
se define como equivalente a:
(A WHERE c1 ) INTERSECT (A WHERE c2 )
2- A WHERE c1 OR c2
(A WHERE c1 ) UNION (A WHERE c2 )
3- A WHERE NOT c
A MINUS (A WHERE c )
Veamos algunos ejemplos:
--------------
S [ CIUDAD ] CIUDAD
--------------
Londres
París
Atenas
-------------- --------------
P [ CQLOR, CIUDAD ] COLOR CIUDAD
------------- --------------
Rojo Londres
Verde París
Azul Roma
Azul París
----
( S WHERE CIUDAD = 'París' ) [ S# ] S#
----
52
53
Figura 5.5 Ejemplos de Restricción

114
 Proyección
La proyección de la relación A según los atributos, X, Y, ...,Z
A [X, Y, ..., Z]
es una relación con (X, Y, ..., Z) como cabecera y cuyo cuerpo esta formado por el conjunto de
todas la tuplas (X:x, Y:y, ... Z:z) tales que una tupla t aparece en A con el valor x en X, el valor y en
Y, .... y el valor z en Z. Así el operador de proyección produce un subconjunto "vertical " de una
relación dada, o sea un subconjunto obtenido mediante la selección de los atributos especificados,
y la eliminación de las tuplas repetidas dentro de los atributos seleccionados.
Omitir por completo la lista de atributos equivale a especificar una lista con todos los atributos de la
relación original. Esto representa la "proyección identidad".
Veamos algunos ejemplos:
Figura 5.6 Ejemplos de proyección

 Reunión natural
La operación de reunión tiene varias formas distintas. La mas importante es la "reunión natural"
que definimos como sigue:
Sean la cabeceras de las relaciones A y B
(X1, X2, ..., Xm, Y1, Y2, ...,Yn)

y
(Y1, Y2, ...., Yn, Z1, Z2, ..., Zp)
respectivamente. Note que los atributos Y1, Y2, ..., Yn son los únicos comunes a las dos
relaciones y suponga que los atributos correspondientes con el mismo nombre están definidos
sobre el mismo dominio. Ahora considere (X1, X2, ..., Xm),(Y1, Y2, ...,Yn), (Z1, Z2, ..., Zp) como
tres atributos compuestos X, Y, Z respectivamente. La reunión natural de A y B:
A JOIN B
es una relación con la cabecera (X, Y, Z) y con un cuerpo formado por el conjunto de todas las
tuplas (X:x, Y:y,Z:z) tales que una tupla a aparezca en A con el valor x en X y el valor y en Y, y una
tupla b aparezca en B con el valor y en Y y el valor z en Z.
La reunión natural es tanto asociativa como conmutativa:
(A JOIN B) JOIN C
115
y
A JOIN (B JOIN C)
Y se pueden simplificar sin problemas de la siguiente forma
A JOIN B JOIN C
Además, las dos expresiones siguientes son equivalentes:
A JOIN B
y
B JOIN A
Veamos un ejemplo:
S# SNOMBRE SITUACIÓN CIUDAD P# PNOMBRE COLOR PESO
Sl Salazar 20 Londres Pl Tuerca Rojo 12

Sl Salazar 20 Londres P4 Birlo Rojo 14
Sl Salazar 20 Londres P6 Engrane Rojo 19
S2 Jaimes 10 París P2 Perno Verde 17
S2 Jaimes 10 París P5 Leva Azul 12
S3 Berna1 30 París P2 Perno Verde 17
S3 Bernal 30 París P5 Leva Azul 12
S4 Corona 20 Londres Pl Tuerca Rojo 12
S4 Corona 20 Londres P4 Birlo Rojo 14
S4 Corona 20 Londres P6 Engrane Rojo 19
Figura 5.7. La reunión natural S JOIN P

 División
Sean las cabeceras de las relaciones A y B
(X1, X2, ..., Xm, Y1, Y2, ...,Yn)

y
(Y1, Y2, ...,Yn)
respectivamente; es decir los atributos Y1, Y2, ...,Yn son comunes a las dos relaciones. Las
relaciones A y B representan el dividendo y el divisor, respectivamente. Suponemos que los
atributos correspondientes están definidos sobre el mismo dominio y que son atributos
compuestos. La división de A entre B
A DIVIDEBY B
resulta una relación con la cabecera (X) y un cuerpo formado por el conjunto de todas las tuplas
(X:x) tales que aparece una tupla X:x, Y:y en A para todas las tuplas (Y:y) presentes en B. O sea
que el resultado contiene todos los valores de X en A cuyos valores de Y correspondientes en A
incluyen a todos los valores de Y en B, en términos informales.
Veamos un ejemplo:
116
DIVIDENDO
S# P#
S1 Pl S2 Pl
Sl P2 S2 P2
Sl P3 S3 P2
Sl P4 S4 P2
Sl P5 S4 P4
Sl P6 S4 P5
..... .....
DIVISOR P# DIVISOR P# DIVISOR P#

Pl P2 Pl
P4 P2
P3
P4
P5
P6
DIVIDENDO DIVIDEBY DIVISOR
S# S# S#
S1 S1 S1
S2 S4
Figura 5.8 Ejemplos de división

Ejemplos
Veremos algunos ejemplos extraídos del libro C.J DATE Introducción a los sistemas de bases de
datos:
1- Obtener los nombres de los proveedores que suministran la parte P2.
((S JOIN SP) WHERE P# = 'P2') [SNOMBRE]
Explicación: Primero se construye la reunión natural de las relaciones S y SP según los

números de proveedor, cuyo efecto conceptuales ampliar cada tupla SP con la información del
proveedor correspondiente (es decir los valores apropiados de SNOMBRE, SITUACION y
CIUDAD). EN seguida se restringe esa reunión solo a las tuplas en las cuales el valor P# es
P2. Por ultimo, la restricción se proyecta según el atributo SNOMBRE. El resultado final tiene
un solo atributo, llamado SNOMBRE.
2- Obtener los nombres de los proveedores que suministran por lo menos una parte roja.
(((P WHERE COLOR = 'ROJO') [P#]

JOIN SP) [S#]
JOIN S) [SNOMBRE]
El único atributo del resultado es SNOMBRE.
3- Obtener los nombres de los proveedores que suministran todas las partes.
(( SP [S#, P#] DIVIDEBY P [P#] ) JOIN S ) [SNOMBRE]
117
El único atributo del resultado es SNOMBRE.
4- Obtener los números de los proveedores que suministran al menos todas las partes
suministradas por le proveedor S2
SP [S#, P#] DIVIDEBY (SP WHERE S# = 'S2') [P#]
El resultado tiene un único atributo, llamado S#
5- Obtener los nombres de los proveedores que no suministran la parte P2.
((S [S#] MINUS (SP WHERE P# = 'P2') [S#])

JOIN S ) [SNOMBRE]
El resultado tiene un único atributo, llamado SNOMBRE
Operadores adicionales:
Comenzamos ampliando la sintaxis introducida al comienzo de la sección. Añadimos los nuevos

tipos de expresión que desarrollaremos en esta sección:
Ampliación:
EXTEND termino ADD calculo-escalar AS atributo
Resumen:
SUMARIZE termino GROUPBY (listaconcomas-de-atributos)

ADD calculo-de-agregados AS atributo
 Ampliación
Como seguramente ha advertido, el álgebra tal como la hemos desarrollado hasta ahora no
presenta la capacidad de calculo, y es obvio que en la practica tal capacidad es mas que
necesaria. Veamos un ejemplo. Si deseamos poder obtener de la base de datos el valor de una
expresión aritmética como PESO *454, o hacer referencia a un valor de este tipo en una cláusula
WHERE, la cláusula EXTEND nos brindara esa capacidad. EXTEND toma una relación
especificada y crea una nueva relación semejante a la anterior pero con un atributo mas, cuyos
valores se obtienen evaluando alguna expresión de calculo escalar especificada. Podríamos
escribir:
EXTEND P ADD ( PESO * 454 ) AS PESOGRS
La evaluación de esta expresión produce una relación cuya cabecera es idéntica a la de P, excepto
que incluye además un atributo llamado PESOGRS, y las tuplas de la nueva relación son iguales a
las correspondientes en P solo que incluye además un valor de PESOGRS calculado de la manera
especificada.
Ahora podemos emplear el nuevo atributo PESOGRS en proyecciones, restricciones, etc. Por
ejemplo:
(EXTEND P ADD ( PESO * 454 ) AS PESOGRS ) WHERE PESOGRS > 10000
También podemos abreviar "ampliaciones múltiples" como sugerimos en el siguiente ejemplo:
(EXTEND P ADD 'Peso en Gramos' AS EXPLICACION,( PESO * 454 ) AS

PESOGRS ) WHERE PESOGRS > 10000
118
 Resumen
La operación SUMMARIZE (resumir) hace algo similar que la operación EXTEND (ampliar) pero
con operaciones de agregados - cuenta, suma, promedio, máximo, mínimo-
Por ejemplo la expresión:
SUMMARIZE SP GROUPBY (P#) ADD SUM (CANT) AS CANTTOTAL
produce una relación con la cabecera (P#, CANTTOTAL) en la cual hay una tupla por cada valor
distinto de P# en SP y la cantidad total correspondiente. Si se omite la lista de atributos en la
cláusula GROUPBY, se agrupa la relación especificada mediante ningún atributo y por tanto realiza
el calculo de agregado para toda la relación. Por ejemplo:
SUMMARIZE SP GROUPBY () ADD SUM (CANT) AS GRANTOTAL
esta expresión produce una relación con un atributo y una tupla; el atributo se llama GRANTOTAL
y el único valor escalar en la relación es el total de todos los valores CANT en la relación SP
original.
Tanto la cuenta como la suma -COUNT y SUM- de un conjunto vacío deberían ser cero; en
cambio el promedio -AVG-, el máximo -MAX- y el mínimo -MIN- deberán ser todos indefinidos.
También se puede abreviar los "resúmenes múltiples" como se sugiere con el siguiente ejemplo:
SUMMARIZE SP GROUPBY (P#) ADD SUM (CANT) AS CANTTOTAL,

AVG (CANT) AS CANTPROMEDIO )
Ahora consideremos la siguiente consulta. Obtener las ciudades donde se almacenan mas de
cinco partes rojas. Una posible formulación es:
(( SUMMARIZE (P WHERE COLOR = 'Rojo') G

GROUPBY ( CIUDAD ) ADD COUNT AS N ) WHERE N > 5 ) [ CIUDAD ]
Suponemos ahora que cambiamos la consulta de la siguiente forma. Obtener las ciudades donde
se almacenan menos de cinco partes rojas. Si nos limitamos a sustituir ">" por "<" en la expresión
algebraica anterior:
(( SUMMARIZE (P WHERE COLOR = 'Rojo') G

GROUPBY ( CIUDAD ) ADD COUNT AS N ) WHERE N < 5 ) [ CIUDAD ]
No obtendremos la respuesta correcta, porque no se incluirán las ciudades donde no se

almacenan partes rojas. Para incluir tales ciudades, necesitamos ampliar la expresión anterior
añadiendo el siguiente termino:
UNION
(P [CIUDAD] MINUS (P WHERE COLOR = 'Rojo') [CIUDAD])
Hasta ahora hemos visto un conjunto de ejemplos que nos han sugerido que el objetivo principal
del álgebra es solo la obtención de datos.
La intensión general del álgebra es ayudar a escribir expresiones coayudando a diversos
propósitos entre los que esta incluida desde luego la obtención de datos, pero no esta limitado a
esa única función. A continuación enumeramos algunas de las posibles aplicaciones de tales
expresiones:
 Definir los datos que se van a extraer como resultado de una recuperación.
119
 Definir los datos por insertar, modificar o eliminar como resultado de una operación de
actualización.
 Definir los datos que se podrán ver en forma de relación virtual o vista.
 Definir los datos que se han de mantener en forma de una relación tipo "instantánea"
 Definir los derechos de acceso.
 Definir los datos que abarcara alguna operación de control de concurrencia.
 Definir reglas especificas que debe satisfacer la base de datos
Precisamente por su naturaleza fundamental, el álgebra se utiliza a menudo como patrón de

referencia para medir la capacidad expresiva de un determinado lenguaje relacional. En esta
materia evaluaremos como el SQL soporta estas expresiones.
Del conjunto original de ocho operaciones algebraicas, las cinco operaciones: unión, diferencia,
producto, restricción y proyección se pueden considerar como primitivas. Defina la reunión, la
intersección y la división en términos de esas primitivas.
Tanto el álgebra relacional como el calculo relacional - no desarrollado en esta guía- pueden
expresar consulta complejas, pero debido a su notación matemática, ninguno es apropiado para un
usuario no técnico e interesado en un lenguaje de acceso a bases de datos para uso general. Un
lenguaje mejora parea este tipo de usuarios es el lenguaje de consulta estructurado o SQL. SQL es
la interfaz de mas uso para bases de datos relacionales, y todo sistema de administración de
bases de datos relacionales de éxito comercial aceptan instrucciones de SQL, incluso si este no es
el lenguaje básico de acceso.
Dividiremos la sección en dos partes. En la primera parte de la analizaremos las proposiciones
incluidas en el lenguaje de definición de datos (DDL). Esta porción del lenguaje como ya lo hemos
descrito anteriormente se encarga de definir la estructura de una base de datos: "crear "o "alterar",
tablas, índices, vistas, etc.
Por ultimo abordaremos los aspectos de manipulación de datos de SQL (DML) que se encargan de
insertar, modificar y consultar los datos almacenados en la estructura de una base de datos.
2.1 Definición de Datos:
Desarrollaremos ahora proposiciones de SQL incluidas en el lenguaje de definición de datos

(DDL), limitaremos nuestra atención a las porciones "relacionales" del DDL; es decir veremos los
aspectos que le interesan de manera directa al usuario, y no los que se relacionan con el nivel
interno del sistema. Las principales proposiciones del DDL son:
CREATE TABLE CREATE VIEW CREATE INDEX

ALTER TABLE
DROP TABLE DROP VIEW DROP INDEX
Tablas Base:
Repasemos la definición de tabla base: Una tabla en un sistema relacional se compone de:
 una fila de cabeceras de columna: la cual nos da un nombre de una columna y un tipo de dato
para cada una;
 y cero o mas filas de valores de datos: cada fila de datos contienen un solo valor escalar para
cada una de las columnas especificadas en la fila de cabeceras de columna. Todos los valores
de una columna dada tienen el mismo tipo de datos especificado en la fila de cabeceras de
columna para esa columna.
120
Advierta que de acuerdo a esta definición no existe ningún ordenamiento de filas, se considera
que las filas de una tabla relacional están desordenadas ya que se las considera como un
conjunto matemático y en matemáticas los conjuntos no están ordenados de ninguna manera.
Note en cambio, que las columnas de una tabla sí se consideran ordenadas de izquierda a
derecha. Por ejemplo en la tabla de proveedores S la columna S# es la primera columna, la
columna SNOMBRE es la segunda, etc.
La definición dice también que una tabla base es una tabla autónoma con nombre. Al decir
"autónoma" queremos decir que la tabla existe por derecho propio no como la vista la cual no
existe por si misma sino que se deriva de una o mas tablas base. Al decir "con nombre" queremos
decir que a la tabla se le asigna de manera especifica un nombre haciendo uso de la proposición
CREATE (crear) apropiada, a diferencia de una tabla construida como resultado de una consulta
carece de un nombre explícito propio.
Create table
CREATE TABLE table-base

( definicion-de-columna [,definicion-de-columna] ...
[,definicion-de-clave-primaria]
[,definicion-de-clave-ajena] [,definicion-de-clave-ajena] ....] );
donde "definicion-de-columna" a su vez tiene la forma:
columna tipo-de-datos [NOT NULL]
Los corchetes [] indican que lo que esta encerrado en ellos es opcional; los puntos suspensivos
significa que la unidad sintáctica inmediata anterior puede repetirse de manera opcional una o mas
veces.
Explicaremos la definición de NOT NULL (no nulo) mas adelante; pero queremos señalar que
aunque la definición de clave primaria es en realidad opcional siempre es preferible crearla con la
tabla ya que como hemos analizado anteriormente es una parte importante dentro del modelo
relacional.
Veamos un ejemplo concreto:
CREATE TABLE S
( S# CHAR(5) NOT NULL,
SNOMBRE CHAR(20) NOT NULL,
SITUACION SMALLINT NOT NULL,
CIUDAD) CHAR(15) NOT NULL,
PRIMARY KEY ( S# ) );
La tabla S tiene cuatro columnas llamadas S#, SNOMBRE, SITUACION, CIUDAD cuyos tipos de
datos son los indicados; la columna S# es la clave primaria y debe declararse en forma explícita
como no nula. Ya esta creada la estructura de la tabla a partir de este momento es posible
cargarle los datos mediante una proposición que veremos en el lenguaje de manipulación de datos
llamada INSERT.
Tipos de Datos:
Veremos algunos tipos de datos escalares

 Datos numéricos:
INTEGER : entero binario de palabra completa.

SMALLINT: entero binario de media palabra.
DECIMAL (p,q): numero decimal empacado, p dígitos y signo, con q dígitos a la derecha del
punto decimal
121
FLOAT (p): numero de punto flotante, con precisión de p dígitos binarios
 Datos de cadena
CHARACTER (n): cadena de longitud fija con exactamente n caracteres de 8 bits.

VARCHAR (n): cadena de longitud variable con hasta n caracteres de 8 bits.
GRAPHIC (n): cadena de longitud fija con exactamente n caracteres de 16 bits.
VARGRAPHIC (n): cadena de longitud variable con hasta n caracteres de 16 bits.
 Datos de fecha/hora
DATE: fecha (aaaammdd)

TIME: hora (hhmmss)
TIEMSTAMP: marca de tiempo (combinación de fecha y hora con una precisión de
microsegundos)
Estos tipos de datos dependen del motor de base de datos con el cual se trabaje, los descriptos
anteriormente son extraídos de DB2, pero podrán encontrar varias abreviaturas y ortografías
distintas (por ejemplo, CHAR en vez de CHARACTER, DEC en vez de DECIMAL, INT en vez de
INTEGER), incluso hasta otros tipos de datos si trabajan con Oracle, SQL Server, etc.
Valores Nulos:
En cualquier situación del mundo real surge el problema de la información faltante; por ejemplo, los
registros históricos contienen a veces entradas tales como "fecha de nacimiento desconocida";
expedientes policiacos pueden incluir la entrada "paradero actual desconocido". Incluso en
situaciones mas simple puede que no sepamos algún dato con precisión para poder almacenarlo
en la base de datos. La forma normal de representar esta "información faltante es sistemas SQL es
mediante indicadores especiales llamados nulos (nulls). Si un registro posee un nulo en una cierta
posición de campo, significara que se desconoce el valor de este campo. Suponga que estamos
cargando un registro de un envío y no sabemos la cantidad enviada, entonces en la tabla envíos
insertamos todos los datos y el campo CANT lo dejamos sin información ya que la desconocemos,
por lo que DB2 automáticamente insertara un nulo en ese campo para ese registro.
Es importante aclarar que un "nulo" no es un "espacio en blanco" o un "cero", entendamos que
nulo no es un valor.
Cualquier campo puede contener nulos a menos que la definición de ese campo especifique NOT
NULL (no nulo) de manera explícita. Vea los ejemplos de la proposición CREATE TABLE de la
sección anterior. Si un campo dado puede contener nulos e insertamos algún registro en esa tabla
sin dar un valor para ese campo, la base de datos insertara en forma automática un nulo en esa
posición; y si un campo dado no puede contener nulos la base de datos rechazara cualquier intento
de introducir un nulo en ese campo. En las próximas secciones profundizaremos mas este tema
por ahora es suficiente con que advierta lo siguiente:
a) las expresiones escalares de calculo en las cuales uno de los operando es nulo dan un nulo
como resultado.
b) las operaciones escalares de comparación en las cuales uno de los comparandos es nulo dan
nulo como resultado.
Alter table
Así como podemos crear una tabla base nueva con CREATE TABLE también podemos alterar una
tabla base ya existente con ALTER TABLE
a) agregando una columna nueva a la derecha
b) modificando el tipo de datos y el tamaño de una columna
c) agregando una regla de integridad
d) modificar características de almacenamiento y otros parámetros
e) habilitar, deshabilitar o borrar una regla de integridad
122
En esta guía veremos solo las dos primeras si desea profundizar mas sobre este tema le
proponemos consultar los sitios : www.oracle.com; www.ibm.com/db2; o cualquier manual de
referencia del lenguaje SQL:
ALTER TABLE tabla-base ADD columna tipo-de-datos;
ALTER TABLE tabla-base MODIFY columna tipo-de-datos;
La primera sentencia es para agregar columnas, la segunda es para modificar algún dato
especifico de una columna.
Por ejemplo:
ALTER TABLE S ADD DESCUENTO SMALLINT;
Esta sentencia añade una columna llamada DESCUENTO a la tabla S. Todos los registros S
existentes crecen, en lo conceptual de cuatro valores de campo a cinco; el valor del nuevo campo
es nulo en todos los casos.
ALTER TABLE S MODIFY DESCUENTO INTEGER(8,2);
Esta sentencia modifica el tipo de dato de la columna DESCUENTO de la tabla S.
ALTER TABLE S MODIFY DESCUENTO INTEGER(10,2);
Esta sentencia modifica el tamaño del tipo de dato de la columna DESCUENTO de la tabla S. Note
que las modificación de tipo de dato o de tamaño del tipo de dato, puede hacerse para aumentar
su tamaño no para reducirlo, ya que de otra manera truncaríamos los valores por lo que no es una
modificación permitida.
Estas modificaciones de columnas, modifican todos los valores existentes, en el primer caso se
amplia la parte entera y se le añaden la parte decimal, que para los valores existentes será: .00; en
el segundo caso se amplia mas el tamaño de la parte entera. Todas las conversiones de tipo
dependen de la compatibilidad entre los tipos, la base de datos no permitirá modificar un campo de
tipo character a un tipo numérico, y en lo conceptual tampoco seria lógico. Estas conversiones
también dependen del sistema de base de datos con el que se este trabajando. Por lo que le
recomendamos que siempre que tenga que realizar cualquier clase de modificación de las
estructuras de una base de datos consulte a los manuales específicos de la base de datos con la
que esta trabajando.
Drop table
También es posible eliminar en cualquier momento una tabla base existente
DROP TABLE table-base;
La tabla base especificada se elimina del catalogo del sistema con su descripción completa y
también se desechan en forma automática todos los índices y vistas definidos en términos de esa
tabla base.
Indices
Los índices se crean y desechan con las mismas proposiciones que las tablas bases. CREATE
INDEX y DROP INDEX son las únicas proposiciones que hacen referencia a los índices; las de
manipulación de datos como SELECT no pueden referirse al índice. La decisión de utilizar o no un
índice determinado para responder a una cierta consulta en SQL no la toma el usuario, sino el
sistema de base de datos DB2.
123
CREATE [UNIQUE] INDEX índice
ON tabla-base (columna [orden] [, columna [orden]] ...)
[CLUSTER] ;
Cada especificación de "orden" es ascendente ASC o descendente DESC, si no se especifica una

de las dos, se toma ASC por omisión. La secuencia de izquierda a derecha en la mención de las
columnas en la proposición CREATE INDEX corresponde al ordenamiento mas o menos
importante en la forma acostumbrada. La especificación opcional CLUSTER indica que se trata de
un índice de agrupamiento; una tabla base puede tener como máximo un índice de agrupamiento.
CREATE INDEX X
ON T (P, Q, R [DESC]) CLUSTER ;
Esta proposición crea un índice de agrupamiento llamado X para la tabla base T en el cual las
entradas se ordenan en forma ascendente según el valor de R dentro de un orden descendente
según el valor de Q dentro de un orden ascendente según el valor de P. No es preciso que las
columnas P, Q y R de la tabla T sean contiguas, ni necesitan tener el mismo tipo de datos, ni
deben ser por fuerza todas de longitud fija o todas de longitud variable.
Si se especifica la opción UNIQUE (único) en CREATE INDEX, no se permitirá que dos registros
de la tabla base indizada tengan el mismo tiempo el mismo valor en el campo o combinación de
campos de indización. Para las claves primarias por ejemplo esto es inminente para que se cumpla
la propiedad unicidad, por lo que en DB2 se debe realizar lo siguiente:
CREATE UNIQUE INDEX XS ON S (S#) ;

CREATE UNIQUE INDEX XP ON P (P#) ;
CREATE UNIQUE INDEX XSP ON SP (S#, P#) ;
Ahora si DB2 rechazara cualquier intento de introducir mediante una operación INSERT (insertar) o
UPDATE (actualizar) un valor que ya existe en el campo S.S# o en el P.P# o el campo compuesto
SP.(S#,P#).
Note que algunos sistemas de base de datos interpretan la creación de un índice único cuando
advierten en la cláusula CREATE TABLE que algún campo es clave primaria, por lo que si se
especifica explícitamente la clave primaria cuando se esta creando la tabla no es necesario crear
un índice único para esta clave.
Se puede crear cualquier cantidad de índices para una misma tabla base.
La proposición para desechar un índice es
DROP INDEX índice;
El índice se destruye, su descripción se elimina del catalogo.
2.2 Manipulación de Datos:
Este lenguaje ofrece cuatro proposiciones de DML:

 SELECT: seleccionar
 UPDATE: actualizar
 DELETE: eliminar
 INSERT: insertar
Las tablas manipuladas con estas proposiciones de DML pueden ser, en términos generales, tanto
tablas base como vistas, pero en esta sección nos ocuparemos de las tablas base.
Consultas Simples
124
Mostraremos la forma general de la proposición SELECT, y luego ilustraremos las características
principales de esta proposición mediante una serie de ejemplos.
SELECT [DISTINCT] elemento(s)

FROM tabla
[WHERE condición]
[GROUP BY campo(s)]
[HAVING condición]
[ORDER BY campo(s)] ;
Supongamos las siguientes dos tablas relacionadas. Plantearemos una consulta simple sobre cada
una de las tablas.
PROVINCIA ALUMNO
---------- --------
CODPROV NUM
NOMPROV NOMBRE
APELLIDOS
EDAD
CODPROV
NOTA
1. Listar todo el contenido de una tabla
 "Obtener datos completos de todas las provincias"
SELECT * FROM provincia;

Resultado:
CODPROV NOMPROV
---------- --------------------
41 SEVILLA
21 HUELVA
28 MADRID
8 BARCELONA
23 JAEN
 "Obtener datos completos de todos los alumnos"
SELECT * FROM alumno;
Resultado:
NUM NOMBRE APELLIDOS EDAD CODPROV NOTA

------ ---------- -------------------- ------ -------- ------
4 ANTONIO PEREZ LOPEZ 22 41 6.5
3 PABLO SUAREZ GUERRA 25 21 7.8
82 RAFAELA PEREZ LOPEZ 19 8 4.3
9 MARIO BEATO SOLIS 22 28 5.1
2 ANGELA RODRIGUEZ JODAR 27 41 6.9
1 JULIAN BARCO SANDOVAL 26 41 6.5
8 FRANCISCA RAMIREZ MARTIN 25 41 3.5
12 BENITO GOTERA OTILIO 28 21 9.3
2. Selección de atributos concretos.
125
 "Obtener los apellidos, el nombre y la edad de todos los alumnos"
SELECT apellidos, nombre, edad FROM alumno;
Resultado:
APELLIDOS NOMBRE EDAD

-------------------- ---------- ----------
PEREZ LOPEZ ANTONIO 22
SUAREZ GUERRA PABLO 25
PEREZ LOPEZ RAFAELA 19
BEATO SOLIS MARIO 22
RODRIGUEZ JODAR ANGELA 27
BARCO SANDOVAL JULIAN 26
RAMIREZ MARTIN FRANCISCA 25
GOTERA OTILIO BENITO 28
Estos ejemplos muestran la forma mas común de la proposición SELECT de SQL. El SELECT
selecciona los campos especificados. El asterisco ("*") representa una lista de todos los nombres
de campo de la tabla o tablas nombradas en la cláusula FROM. FROM (de) indica de que tabla
hay que tomar los datos.
Note que el resultado de las consultas es otra tabla, derivada en alguna forma de las tablas
existentes en la base de datos.
También podríamos haber formulado las consultas empleando nombres de campos calificados en
todos los casos.
SELECT alumno.apellidos, alumno.nombre, alumno.edad FROM alumno;
Un nombre calificado se compone de un nombre de tabla y un nombre de campo, en ese orden

separado por un punto. Las dos formas son correctas pero en algunos casos que veremos mas
adelante el uso de nombre calificado resulta indispensable.
Los alias también son muy útiles para poder calificar los campos o las tablas. Consiste en
reemplazar el nombre por un "alias" que puede ser un nombre mas corto o una letra. De esta forma
podemos hacer uso del alias y del nombre de la tabla.
SELECT a.apellidos, a.nombre, a.edad FROM alumno AS a;
SELECT a.apellidos, a.nombre, a.edad FROM alumno a;
La sintaxis para poner un alias a un nombre es anteponiendo la cláusula AS o simplemente, como

se ve en el segundo ejemplo con un espacio en blanco que separe el nombre del alias. Los alias
nos permiten calificar los campos "con un nombre corto", evitándonos tener que escribir el nombre
completo de la tabla o "con un nombre significativo", en el caso de que alguna tabla tenga un
nombre difícil de recordar o su nombre no tenga que ver con el contenido especifico de los datos
que almacena, podemos definir un alias que sea mas entendible.
3. Ordenación de la salida
 "Obtener datos completos de todas las provincias ordenado por nombre de provincia"
SELECT * FROM provincia ORDER BY nomprov;
CODPROV NOMPROV
---------- --------------------
8 BARCELONA
126
21 HUELVA
23 JAEN
28 MADRID
41 SEVILLA
 "Obtener los apellidos, nombre y edad de todas los alumnos ordenado por edad"
SELECT apellidos, nombre, edad FROM alumno ORDER BY edad;

-------------------- ---------- ----------
Puede ordenarse tanto por valores alfabéticos como numéricos. Puede ordenarse de menor a
mayor (orden ascendente, o ASC) o de mayor a menor (orden descendente, o DESC). Por defecto
el orden considerado es de menor a mayor. La ordenación tiene asociado un cierto coste
computacional por lo que solo debe realizarse cuando sea necesario
4. Ordenación múltiple
 "Obtener los apellidos y nombre de todos los alumnos ordenado por edad por apellido
ascendente y por nombre ascendente"
SELECT apellidos, nombre FROM alumno ORDER BY edad DESC,

apellidos ASC, nombre ASC;
APELLIDOS NOMBRE
-------------------- ----------
GOTERA OTILIO BENITO
RODRIGUEZ JODAR ANGELA
BARCO SANDOVAL JULIAN
RAMIREZ MARTIN FRANCISCA
SUAREZ GUERRA PABLO
BEATO SOLIS MARIO
PEREZ LOPEZ ANTONIO
PEREZ LOPEZ RAFAELA
5. Condición simple
 "Obtener los apellidos de los alumnos que tienen 23 años"
SELECT apellidos FROM alumno WHERE edad = 23;
Resultado:
APELLIDOS
--------------------
SUAREZ GUERRA
127
RAMIREZ MARTIN
BARCO SANDOVAL
RODRIGUEZ JODAR
GOTERA OTILIO
 "Obtener los apellidos de los alumnos que no tienen 23 años"
SELECT apellidos FROM alumno WHERE edad != 23;
Resultado:

-------------------- ---------- ----------
 "Obtener los datos completos de los alumnos que tienen entre 19 y 25 años"
Resultado: SELECT * FROM alumno WHERE edad BETWEEN 19 AND 25;
NUM NOMBRE APELLIDOS EDAD CODPROV NOTA

------ ---------- -------------------- ------ -------- ------
4 ANTONIO PEREZ LOPEZ 22 41 6.5
3 PABLO SUAREZ GUERRA 25 21 7.8
82 RAFAELA PEREZ LOPEZ 19 8 4.3
9 MARIO BEATO SOLIS 22 28 5.1
8 FRANCISCA RAMIREZ MARTIN 25 41 3.5
 "Obtener los números de los alumnos que tienen cargada alguna nota"
SELECT num FROM alumno WHERE nota IS NOT null;
Resultado:
NUM
------
4
3
82
9
2
1
8
12
Profundizaremos el uso del null en la sección: Características avanzadas.
 "Obtener los números de los alumnos que viven en Sevilla y Huelva"
SELECT num FROM alumno WHERE codprov IN (21, 41);
128
Resultado:
NUM
------
4
3
2
1
8
12
6. Condición compuesta
 "Obtener la nota de los alumnos que tienen mas de 20 años y que viven en Sevilla"
SELECT nota FROM alumno WHERE edad > 20 AND codprov = 41;
Resultado:
NOTA
------
6.5
6.9
6.5
3.5
 "Obtener el numero de los alumnos que tienen menos de 20 años o mas de 30 años"
SELECT num FROM alumno WHERE edad < 20 OR edad > 30;
Resultado:
NUM
------
82
 "Obtener la edad de los alumnos que tienen menos de 20 años o que no viven en Sevilla ni
tampoco en Huelva"
SELECT edad FROM alumno WHERE edad < 20 OR codprov NOT IN (41,21);
Resultado:
EDAD
------
19
22
Profundizaremos el uso del NOT IN en la sección: Características avanzadas.
7. Combinación de condición y orden
 "Obtener la nota de los alumnos aprobados (nota>=5) y que son mayores de 20 años. Ordenar
según la nota de forma ascendente"
SELECT nota FROM alumno WHERE nota>=5 AND edad>20 ORDER BY nota;
129
Resultado:
NOTA
----------
5.1
6.5
6.5
6.9
7.8
9.3
Obsérvese que en la salida puede aparecer un mismo valor repetidas veces.
8. Evitar repetición de la salida
 "Obtener las distintas nota de los alumnos aprobados (nota>=5) y que son mayores de 20
años. Ordenar según la nota de forma ascendente"
SELECT DISTINCT nota FROM alumno WHERE nota >= 5;
Resultado:
NOTA
----------
5.1
6.5
6.9
7.8
9.3
Consultas de Reunión:
La posibilidad de reunir dos o mas tablas en una sola es una de las características mas poderosas
de los sistemas relacionales; de hecho es, mas que cualquier otra cosa, lo que distingue a los
sistemas relacionales de los no relacionales. Así pues podemos definir la reunión en términos
informales como una consulta en la cual se obtiene información de mas de una tabla.
1. Equirreunión simple
 "Obtener todos los datos de los alumnos con todos los datos de la provincia en la que viven"
SELECT alumno.*, provincia.* FROM alumno, provincia WHERE

alumno.codprov = provincia.codprov;
Note que aquí las referencias a campos en la cláusula WHERE deben calificarse con los
nombres de las tablas correspondientes, pues de lo contrario serian ambiguas.
Resultado:
NUM NOMBRE APELLIDOS EDAD CODPROV NOTA CODPROV NOMPROV

------ ---------- -------------------- ------ -------- ------ ------- -------
4 ANTONIO PEREZ LOPEZ 22 41 6.5 41 SEVILLA
3 PABLO SUAREZ GUERRA 25 21 7.8 21 HUELVA
82 RAFAELA PEREZ LOPEZ 19 8 4.3 8 BARCELONA
9 MARIO BEATO SOLIS 22 28 5.1 28 MADRID
2 ANGELA RODRIGUEZ JODAR 27 41 6.9 41 SEVILLA
130
1 JULIAN BARCO SANDOVAL 26 41 6.5 41 SEVILLA
8 FRANCISCA RAMIREZ MARTIN 25 41 3.5 41 SEVILLA
12 BENITO GOTERA OTILIO 28 21 9.3 21 HUELVA
Por el enunciado es evidente que los datos requeridos provienen de dos tablas, "alumno" y
"provincia". Por tanto en la formulación SQL de la consulta, nombramos primero esas dos tablas en
la cláusula FROM (de) y en seguida expresamos la conexión entre ellas - o sea el hecho de que
los valores de código de provincia deben ser iguales- en la cláusula WHERE (donde).
Se dice que el resultado de esta consulta es una reunión de las tablas "alumno" y "provincia" con
base en valores de CODPROV iguales. También se usa el termino "reunión" para designar la
operación de construir un resultado de este tipo. Se dice que la condición alumno.codprov =
provincia.codprov es una condición de reunión.
La reunión natural es el tipo de reunión mas útil, el termino "reunión" sin calificativo casi siempre se
utiliza para referirse a la reunión natural.
Explicaremos un poco mas el concepto de reunión.
Primero se forma el "producto cartesiano" de las tablas incluidas en la cláusula FROM (de).
El producto cartesiano de un conjunto de n tablas es la tabla formada por todas las filas f posibles,
donde f es la concatenación de una fila de la primera tabla, una fila de la segunda tabla, ..., y una
1
fila de la nesima tabla .
Veamos el producto cartesiano de la tabla alumno y provincia:

------ ---------- -------------------- ------ -------- ------ ------- -------
4 ANTONIO PEREZ LOPEZ 22 41 6.5 41 SEVILLA
4 ANTONIO PEREZ LOPEZ 22 41 6.5 21 HUELVA
4 ANTONIO PEREZ LOPEZ 22 41 6.5 8 BARCELONA
4 ANTONIO PEREZ LOPEZ 22 41 6.5 23 JAEN
4 ANTONIO PEREZ LOPEZ 22 41 6.5 28 MADRID
3 PABLO SUAREZ GUERRA 25 21 7.8 41 SEVILLA
3 PABLO SUAREZ GUERRA 25 21 7.8 8 BARCELONA
3 PABLO SUAREZ GUERRA 25 21 7.8 23 JAEN
3 PABLO SUAREZ GUERRA 25 21 7.8 28 MADRID
. . . . . . . .
. . . . . . . .
. . . . . . . .
12 BENITO GOTERA OTILIO 28 21 9.3 28 MADRID
La tabla completa contiene 8 * 5 = 40 filas

De esta tabla se eliminan todas las filas que no satisfagan la condición de reunión. Lo restante es
la reunión requerida. O sea eliminamos todas las filas en las cuales alumno.codprov no es igual a
provincia.codprov, y lo que queda es exactamente la equirreunión antes mostrada.
2. Consulta de reunión con una condición adicional
 " Obtener todos los datos de los alumnos con todos los datos de la provincia en la que viven,
pero omitiendo a los alumnos que son mayores a 22 años "
Resultado:
SELECT alumno.*, provincia.* FROM alumno, provincia WHERE

alumno.codprov = provincia.codprov AND
alumno.edad > 22;

131
------ ---------- -------------------- ------ -------- ------ ------- -------
2 ANGELA RODRIGUEZ JODAR 27 41 6.9 41 SEVILLA
1 JULIAN BARCO SANDOVAL 26 41 6.5 41 SEVILLA
8 FRANCISCA RAMIREZ MARTIN 25 41 3.5 41 SEVILLA
12 BENITO GOTERA OTILIO 28 21 9.3 21 HUELVA
3. Reunión de tres tablas
Suponga que tenemos una nueva tabla con la siguiente descripción:
INSCRIPCION
------------
FECHA
COD_CARRERA
NUM
Con los siguientes datos:
FECHA COD_CARRERA NUM

----- ----------- -----
12/03/03 05 1
12/03/03 05 2
12/03/03 05 3
12/03/03 05 4
12/03/03 01 8
12/03/03 05 9
12/03/03 01 12
12/03/03 01 82
 "Obtener todos los números y nombres de alumnos con el nombre de la provincia en la que
viven y el numero de carrera en la que están inscriptos"
SELECT alumno.num, provincia.nomprov, inscripcion.cod_carrera

FROM alumno, provincia, inscripcion
WHERE alumno.codprov = provincia.codprov AND
alumno.num = inscripcion.num;
Resultado:
NUM NOMBRE NOMPROV COD_CARRERA

------ --------- -------- -----------
4 ANTONIO SEVILLA 05
3 PABLO HUELVA 05
82 RAFAELA BARCELONA 05
9 MARIO MADRID 05
2 ANGELA SEVILLA 05
1 JULIAN SEVILLA 05
8 FRANCISCA SEVILLA 05
12 BENITO HUELVA 05
Funciones de agregados:
Aunque es bastante poderosa en muchos aspectos, la proposición SELECT tal como se ha
descrito hasta ahora resulta inadecuada para muchos problemas prácticos. Por ejemplo una
consulta sencilla como ¿cuántos proveedores hay? No puede expresarse empleando las
construcciones introducidas hasta ahora. Por tanto SQL ofrece una serie de funciones de
agregados especiales para ampliar su capacidad básica de recuperación de información:
132
Las funciones son:
COUNT - número de valores en la columna-

SUM - suma los claores de la columna-
AVG - promedio de los calores de la columna-
MAX - valor mas grande en la columna-
MIN - valor mas pequeño en la columna-
Las funciones de agregación toman como entrada una colección de valores o tuplas de salida
producidas por una consulta y producen un único valor como salida.
En caso de SUM y AVG la columna debe contener valores numéricos. En general el argumento de
la función puede ir precedido de manera opcional por la palabra clave DISTINCT para indicar que
los valores repetidos deben eliminarse antes de que se aplique la función. En el caso de MAX y
MIN, empero, DISTINCT no tiene efecto alguno. En el caso de COUNT, es necesario especificar
DISTINCT excepto que se incluya la función especial COUNT(*) donde no se permite DISTINCT y
los valores nulos se manejan igual que los no nulos. Si el argumento es un conjunto vacío, COUNT
devuelve el valor cero; las demás funciones devuelven el valor nulo.
1. Función media aritmética
 "Obtener el promedio de edad de todos los alumnos"
SELECT AVG(edad) FROM alumno;
Resultado:
AVG(edad)
----------
23
 "Obtener el promedio de nota de todos los alumnos aprobados"
SELECT AVG(nota) FROM alumno WHERE nota>=5;
Resultado:
AVG(nota)
----------
7.01
2. Función de cuenta:
 "Obtener la cantidad de alumnos aprobados"
SELECT COUNT(*) FROM alumno WHERE nota>=5;
Resultado:
COUNT(*)
----------
6
3. Cardinalidad de una tabla (número de filas o tuplas)
 "Obtener la cantidad de filas que tiene la tabla alumnos"
SELECT COUNT(*) FROM alumno;
Resultado:
133
COUNT(*)
----------
8
4. Función de suma
 "Obtener la suma de las edades de los alumnos "
SELECT SUM(edad) FROM alumno;
Resultado:
SUM(edad)
----------
194
5. Función de máximo
 "Obtener la nota mas alta de todos los alumnos "
SELECT MAX(nota) FROM alumno;
Resultado:
MAX(nota)
----------
9.3
6. Función de mínimo
 "Obtener la nota mas baja y la edad mas pequeña de todos los alumnos "
SELECT MIN(nota), MIN(edad) FROM alumno;
Resultado:
MIN(nota) MIN(edad)
---------- ------------
3.5 19
 "Obtener la nota mas baja de los alumnos que obtuvieron mas de 7"
SELECT MIN(nota) FROM alumno WHERE nota>7;
Resultado:
MIN(nota)
----------
7.8
7. Empleo de GROUP BY
 Suponga que desea saber la cantidad total de alumnos por provincia, es decir para cada
provincia obtener el numero de provincia y la cantidad total de alumnos.
SELECT CODPROV, COUNT(NUM) FROM alumno GROUP BY CODPROV;
Resultado:
134
CODPROV COUNT(NUM)
---------- ------------
8 1
21 2
28 1
41 4
El operador GROUP BY (agrupar por) reorganiza en el sentido lógico la tabla representada por la
cláusula FROM (de) formando particiones o grupos, de manera que dentro de un grupo dado todas
las filas tengan el mismo valor en el campo del GROUP BY. En seguida se aplica la cláusula
SELECT a cada grupo de la tabla dividida y no a cada fila de la tabla individual. Cada expresión en
la cláusula SELECT debe producir un solo valor por grupo. Adviértase que GROUP BY no implica
ORDER BY.
Una tabla puede ser agrupada según cualquier combinación de sus campos.
8. Empleo del HAVING
Supongamos el ejemplo anterior pero con una pequeña modificación:

 "Obtener los códigos de provincia en las que vive mas de un alumno"
SELECT CODPROV
FROM alumno
GROUP BY CODPROV
HAVING COUNT(*)>1;
Resultado:
CODPROV
----------
21
41
HAVING (con) es a los grupos lo que WHERE es a las filas. Si se especifica HAVING deberá
haberse especificado también GROUP BY. Entonces HAVING sirve para eliminar grupos de la
misma manera que WHERE(donde) sirve para eliminar filas. Las expresiones en una cláusula
HAVING deben producir un solo valor por grupo.
Características avanzadas:
1. Recuperación de datos con LIKE (como)
 " Nombres de alumnos que empiezan por 'A' "
SELECT nombre FROM alumno WHERE nombre LIKE 'A%';
Esta comparación es sensible a minúsculas y mayúsculas. El carácter '%' representa cualquier

secuencia de n caracteres donde n puede ser cero. El carácter '_' representa cualquier carácter
individual. Para testear la no presencia de patrones en cadenas se puede utilizar NOT LIKE.
 "Nombres de provincias cuya segunda y tercera letras son 'EV' "
SELECT nomprov FROM provincia WHERE nomprov LIKE '_EV%';
Existen muchas más funciones definidas sobre cadenas de caracteres: concatenación de cadenas,
extracción de subcadenas, cálculo de la longitud de una cadena, etc.
2. Recuperación de datos que incluye null.
135
Vamos a supones para este ejemplo que el alumno 1 y 2 tienen un valor de edad nulo en vez de 26
y 27 respectivamente.
 "Obtener los números de los alumnos que tienen mas de 25 años"
SELECT num FROM alumnos WHERE edad > 25;
Resultado:
NUM
----
12
Los alumnos 1 y 2 no cumplen la condición. Como mencionamos antes al evaluar una condición se
compara un nulo con cualquier otro valor, sea cual sea el operador de comparación empleado, el
resultado de la comparación nunca se considera verdadero. Por eso si edad tiene un valor nulo
ninguna de las siguientes comparaciones resulta verdadera:
edad > 25
edad <= 25
edad = 25
edad >= 25
edad <> 25
edad = NULL /* Esta sintaxis no es legal */
edad <> NULL /* Esta sintaxis no es legal */
Se incluye una condición especial con la forma
nombre-columna IS [NOT] NULL

para detectar la presencia de nulos:
SELECT num FROM alumnos WHERE edad IS NULL;
Resultado:
NUM
----
1
2
La sintaxis "edad = NULL" no esta permitida, porque nada - ni siquiera un nulo- se considera igual
a un nulo.
3. Recuperación de datos con subconsultas
 "Cantidad de alumnos que han obtenido la máxima nota"
SELECT COUNT(*) FROM alumno WHERE nota=(SELECT MAX(nota) FROM alumno);
 "Alumnos cuya nota sea menor que todas las notas obtenidas por los alumnos de 20 años"
SELECT apellidos, nombre FROM alumno WHERE nota IN

(SELECT nota FROM alumno WHERE edad=22);
Una subconsulta es una expresión SELECT ...FROM ...GROUP BY... HAVING anidada dentro de
otra expresión del mismo tipo. Para evaluar la consulta compleja el sistema evalúa primero la
subconsulta anidada. En este ultimo ejemplo esa subconsulta produce como resultado el conjunto
de notas de los alumnos de 22 años, o sea el conjunto (6.5, 5.1). La consulta se transforma en una
mas simple:
136
SELECT apellidos, nombre FROM alumno WHERE nota IN
(6.5, 5.1);
La cláusula WHERE en esta forma se cumple si y solo si nota tiene uno de los valores 6.5 o 5.1.
 "Nombres de provincias para las cuales existen alumnos"
SELECT nomprov FROM provincia WHERE codprov IN

(SELECT codprov FROM alumno);
SELECT nomprov FROM provincia WHERE EXISTS

(SELECT * FROM alumno WHERE alumno.codprov = provincia.codprov);
Estas dos sentencias producen el mismo resultado aunque dependiendo de la implementación

quizás no en el mismo orden.
EXISTS (existe) representa aquí el cuantificador existencial. La expresión "EXISTS (SELECT ..
FROM)" da como resultado un valor verdadero si y solo si el resultado de evaluar la subconsulta
"SELECT ....FROM" no es el conjunto vacío. Adviértase como la condición WHERE dentro de la
expresión EXISTS hace referencia a la tabla FROM del nivel externo de la consulta: lo hace a
través de un nombre de columna calificado de manera explícita provincia.codprov
 Nombre de los alumnos cuya nota sea igual a alguna de las obtenidas por algún alumno de
más de 20 años
SELECT nombre FROM alumno WHERE nota IN

(SELECT nota FROM alumno WHERE edad>20);
 Nombres de provincias para las que existen alumnos con más de 25 años de edad
SELECT nomprov FROM provincia WHERE codprov IN

(SELECT codprov FROM alumno WHERE edad>25);
SELECT nomprov FROM provincia WHERE EXISTS

(SELECT * FROM alumno WHERE alumno.codprov=provincia.codprov AND
edad>25);
Nuevamente puede darse el caso de que la salida producida, aún contenido las mismas tuplas,
estén dispuestas en diferente orden.
4. Operaciones sobre conjuntos
UNION Unión de conjuntos (usualmente resultados de salida).

MINUS Diferencia de conjuntos.
Los conjuntos que participen en este tipo de operaciones han de ser compatibles, esto es, deben
tener el mismo conjunto de atributos o resultados de salida. Estas tres operaciones eliminan
automáticamente los duplicados (se supone que un elemento solo puede estar una vez en un
conjunto). Si se quiere conservar los duplicados debe usarse el operador ALL. Ejemplos:
SELECT codprov FROM provincia UNION SELECT codprov FROM alumno;

SELECT codprov FROM provincia UNION ALL SELECT CODPROV FROM alumno;
SELECT codprov FROM provincia MINUS SELECT codprov FROM alumno;
Operaciones de actualización:
1. Inserción de tuplas:
137
INSERT
INTO tabla [(campo [, campo] ... )]
VALUES (literal [, literal] ....);
O bien
INSERT
INTO tabla [(campo [, campo] ... )]
subconsulta;
 Insertar un solo registro:
INSERT
INTO provincia (codprov, nomprov)
VALUES (21,'HUELVA');
 Inserta un solo registro omitiendo nombres de campos
INSERT
INTO provincia
VALUES (28,'MADRID');
Para que la inserción de una tupla sea válida deben satisfacerse las restricciones de clave,
integridad y de otro tipo que pudieran existir. Obsérvese que en el ejemplo los valores del atributo
añadido a los de la definición original de la tabla ocupan el último lugar en la lista de valores y que
los valores de los atributos se especifican en el mismo orden en que fueron declarados los
atributos. Si no se recuerda el orden de los atributos entonces se puede especificar en cualquier
orden el nombre de cada atributo dentro de la sentencia INSERT como se muestra en el primer
ejemplo en la tabla provincia o de la siguiente manera en la tabla alumno:
INSERT
INTO alumno (num,codprov,apellidos,nombre,nota,edad)
VALUES (12,21,'GOTERA OTILIO','BENITO',9.3,28);
No es necesario insertar tuplas individualmente de una en una sino que también pueden insertarse
varias tuplas resultantes de una consulta.
1. Modificación de información (valores de atributos)
UPDATE tabla
SET campo = expresion-escalar
[, campo = expresion-escalar] ....
[WHERE condición];
 Modificación de un solo registro
UPDATE alumno
SET nombre='BENITA'
WHERE nombre='BENITO';
 Modificación de varios registros: Todos los alumnos de Sevilla se mudaron a Barcelona.
UPDATE alumno
SET codprov= 8
WHERE codprov= 41;
138
Como por definición las operación UPDATE, INSERT y DELETE modifican la base de datos, hay
que tener en cuenta que siempre existe la posibilidad de alterarla en alguna forma incorrecta y
violar con ello la integridad de los datos
2. Borrado de tuplas
DELETE
FROM tabla
[WHERE condición];
 Eliminación de todos los registro de una tabla
DELETE
FROM alumno;
 Eliminación de un solo registro.
DELETE
FROM alumno
WHERE num = 1;
 Eliminación de varios registros
DELETE
FROM alumno
WHERE nota < 5.0;
Una sentencia DELETE solo puede operar sobre una tabla. Si se borran todas las tuplas de una
tabla como resultado de un borrado, ya sea absoluto o condicional, la tabla sigue definida y
existiendo aunque sin contenido.
Un repaso de consultas agrupadas
 Nota media de los alumnos de cada provincia
SELECT codprov, AVG(nota) FROM alumno GROUP BY codprov;
 Nota media de las provincias cuya nota media sea mayor de 5
SELECT codprov, AVG(nota) FROM alumno

GROUP BY codprov HAVING (AVG(nota) > 5);
 Nota media de las provincias para las que haya más de 1 alumno
SELECT codprov, AVG(nota) FROM alumno

GROUP BY codprov HAVING (COUNT(*) > 1);
 Nota media, agrupada por edades, de los alumnos de Sevilla
SELECT edad, AVG(nota) FROM alumno WHERE codprov IN

(SELECT codprov FROM provincia WHERE nomprov='SEVILLA')
GROUP BY edad;
 Número de alumnos por cada nota.
SELECT nota, COUNT(*) FROM alumno GROUP BY nota;
139
 Notas medias por provincia con ordenación según la nota.
SELECT codprov, AVG(nota) FROM alumno GROUP BY codprov ORDER BY 2;

Donde el '2' referencia al segundo elemento de la lista de selección (en este caso, la media de las
notas).
 Edad máxima de los alumnos de cada provincia
SELECT codprov, MAX(edad) FROM alumno GROUP BY codprov;
SELECT edad, AVG(nota) FROM alumno WHERE codprov IN

(SELECT codprov FROM provincia WHERE nomprov='SEVILLA')
GROUP BY edad;
Observe la sintaxis de las sentencia SQL y encuentre la operación equivalente del algebra
relacional. Luego resuelva la consulta aplicando la sintaxis del algebra relacional.
3. SQL Avanzado
SQL cuenta con muchas mas características de las que hemos desarrollado hasta ahora, para
ayudar al usuario a modelar mas cercanamente una aplicación. Las características avanzadas que
desarrollaremos en esta sección comprenden tablas virtuales o vistas, un tratado sistemático de
valores nulos y un método mas completo para imponer restricciones.
3.1 Vistas
Los ejemplos hasta este punto han utilizado solo tablas de bases de datos de la cláusula FROM,
pero el formato permite una lista de relaciones de comas, por la cual la primera extensión es
generalizar expresiones de tablas de la cláusula FROM. Con el formato extendido, el usuario
puede acumular tablas intermedias en una sola instrucción de SQL al anidar cláusulas SELECT.
Por ejemplo, ubicados en la base de datos del acuario, considere la consulta existencial: encuentre
los nombres de especies que nadan con un tiburón. Es posible incrustar una expresión en la
cláusula FROM para aislar los tanques con tiburones, como se ilustra a continuación.
SELECT S.nombre
FROM especie as s, pez as f,
(SELECT t.tno as tiburontno
FROM tanque t, pez g, especie h
WHERE t.tno=g.tno AND g.son=h.son AND h.snombre = 'tiburon') as ST
WHERE s.son= f.son and f.tno=ST.tiburontno
La tercera componente del producto cartesiano es la relación intermedia, ST, que contiene el
atributo único tiburontno. ST contiene los números de tanque de los tanques con un tiburon.
Una consecuencia de este formato extendido es que la cláusula HAVING es ahora superflua.
140
Es posible sustituir una condición de la cláusula HAVING con una cláusula WHERE en el campo de
alcance exterior. Por ejemplo considere la consulta: encuentre el promedio de volumen de tanque
relacionado con las especies representadas en dos o mas tanques. El primer fragmento de abajo
proporciona una solución con la cláusula HAVING. EL nuevo formato de mas abajo efectúa los
cálculos agregados dentro de una selección anidada en la cláusula FROM.
SELECT S.sno especie, avg(t.volumen) promVol

FROM especie s, tanque t,
WHERE exists
(SELECT *
FROM pez f
WHERE s.son = f.son AND
f.tno= t.tno)
GROUP BY s.son
HAVING count(*) > 2;
SELECT S.son, promVol

FROM (SELECT S.sno as sno, avg(t.volumen) promVol, count(*) as
tanqueCuenta
FROM especie s, tanque t,
WHERE exists
(SELECT *
FROM pez f
WHERE s.son = f.son AND
f.tno= t.tno)
GROUP BY s.son)
WHERE tanqueCuenta > 2;
La flexibilidad de la cláusula extendida from también resuelve el problema de componer funciones

de agregados.
SQL permite instrucciones SELECT anidadas en la clausula FROM de una instrucción SELECT
canfitriona. Esta caracteristica eleimna la necesidad de clausulas having
La sintaxis extendida de la cláusula FROM es útil para explicar vistas del lenguaje de consulta
estructurado (SQL). Una vista es una relación virtual, especificada con una instrucción SELECT de
SQL, que el usuario puede tratar como si en realidad existiera en la base de datos. Por ejemplo,
supongamos que ciertos usuarios - personas o programas- del entorno del acuario han estado
acostumbrados durante mucho tiempo a un modelo de datos de una sola fila. O sea cada registro
de archivo contiene información acerca de un pez, que incluye información de la especie y tanque.
Además estos usuarios no tienen que ver con la entidad del evento y no saben que el pez y los
tanques tienen colores. Del mismo modo, algunos atributos tienen nombres diferentes, tales como
peznombre en lugar de pnombre, y el volumen del tanque esta especificado en cuartos de galón en
lugar de galones. La vista que tienen las personas o programas del acuario es como sigue:
Las entradas entre paréntesis se refieren a los nombres reales de la base de datos.
Pezno Peznombre Especieno Especienombre Especiealimento Tanqeno Tanquenombre Tanquevolumen

(pnro) (pnombre) (sno) (snombre) (salimento) (tno) (tnombre) (tvolumen)
También es posible usar una instrucción SQL para crear esta vista y hacerla disponible como si
fuera una tabla real de base de datos.
CREATE VIEW acuarioviejo AS

141
(SELECT f.pno as pezno, f.pnombre as peznombre, s.son as especieno,
s.snombre as especienombre, s.salimento as especiealimento, t.tno
as tanqueno, t.tnombre as tanquenombre, 4* t.tvolumen as
tanquevolumen
FROM especie s, pez f, tanque t
WHERE s.son=f.son AND
f.tno=t.tno );
Las tablas reales son tablas base, y las vistas son tablas virtuales. Una tabla base posee una
representación concreta en las estructuras del disco duro del sistema, peor una tabla virtual es solo
una abreviatura para una instrucción SELECT de SQL. Cuando otra instrucción de SQL se refiera a
la tabla virtual, el DBMS sustituye la forma expandida.
La sintaxis general de la operación CREATE VIEW (crear vista) en SQL se detalla a continuación:
CREATE VIEW vista [ (columna [ , columna ] ... ) ]

AS subconsulta
[ WITH CHECK OPTION ];
Por ejemplo supongamos que el usuario esta operando con la vista acuarioviejo y desea los
nombres de especies que nadan en tanques llamados "letrina". SQL de abajo utiliza la tabla virtual,
acuarioviejo.
SELECT especienombre
FROM acuarioviejo
WHERE tanquenombre= 'LETRINA';
El DBMS sustituye la definición de la vista acuarioviejo de la cláusula FROM, y se obtiene la

forma equivalente.
SELECT especienombre
FROM
tanquevolumen
f.tno=t.tno )
WHERE tanquenombre= 'LETRINA';
Es posible también juntar tablas base con vistas. Los siguientes formatos equivalentes encuentran
los colores de pez que nadan en tanques llamados letrina.
SELECT f.color
FROM pez f, acuarioviejo q
WHERE f.pno=q.pezno AND
q.tanquenombre= 'LETRINA';
El DBMS sustituye la definición de acuarioviejo y procesa la siguiente consulta:

SELECT f.color
FROM pez f,
tanquevolumen
142
f.tno=t.tno ) as q
WHERE f.pno=q.pezno AND
q.tanquenombre= 'LETRINA';
El usuario puede contestar muchas consultas existenciales con una selección simple de una sola
tabla de acuarioviejo, porque la vista presenta una combinación unificada de especies, peces y
tanques; ya no se visualiza un producto cartesiano de una cláusula FROM de las tablas de
especie, pez y tanque. El producto cartesiano vuelva a aparecer, por supuesto, cuando el DBMS
sustituye la definición de la vista, pero los usuarios no tiene que conocer esa complicación. Para
ellos la consulta aborda una sola tabla.
Una vista es una tabla virtual especificada como instrucción SELECT de SQL. El DBMS
fusiona la definicion de vista con el resto de cualqueira instrucción de SQL en donde aparece,
lo cual resulta en una nueva expresion que comprende solo las tablas base.
La base de datos almacena la definición de la vista, lo cual la hace disponible en diferentes

sesiones. Además el DBMS vuelve a materializar la relación virtual cada vez que se cite. Como el
DBMS vuelva a calcular la vista por cada instrucción de SQL que la utilice, cualquier cambio de las
tablas básicas se reflejan de inmediato en la vista.
Actualización de tuplas por medio de una vista:
La recuperación de información por medio de una vista implica una sencilla sustitución de la
definición de la vista en la consulta de exploración, aunque son mas complejas las inserciones,
borrados y actualizaciones por medio de vistas. Por ejemplo, supongamos que el usuario tiene la
siguiente vista que materializa una sola columna de colores de peces. Como se indica abajo, la
vista da una mirada estrecha a la relación de peces al dejar ver solo los colores de peces
PEZ
Pnro Pnombre pcolor ppeso tnro snro
438 Fran negro 61 55 74
911 Helen azul 48 44 74
302 Jill rojo 28 38 17
CREATE VIEW pezColor as

(SELECT f.pcolor as pcolor from pez f);
La vista resultante es:
PEZCOLOR
143
pcolor
anaranjado
negro
blanco
anaranjado
rojo
azul
morado
blanco
blanco
negro
rojo
azul
negro
rojo
rojo
Ahora cuales son los efectos de las siguientes operaciones de SQL?
DELETE from pezColor INSERT INTO pezColor (pcolor)

WHERE pclor = 'ROJO'; VALUES ('ROJO');
Como una vista no tiene contraparte explícita en almacenamiento físico, el DBMS debe aplicar
cualquier cambio a las tablas base subyacentes. En este caso, ¿cuál de los cuatro peces rojos
debe borrar el DBMS de la tabla peces? Y para la inserción ¿qué valores debe poner el DBMS en
otros atributos cuando crea una nueva tupla con pcolor rojo? En particular ¿qué valor debe poner
en el atributo clave pno? Debido a que estas preguntas no tiene respuestas satisfactorias, el
usuario no puede actualizar esta vista.
En general una vista se puede actualizar si tiene una sola tabla base e incluye una clave para esa
tabla. Si una actualización o inserción produce una fila de tabla base con valores nulos en
posiciones no claves, las consecuencias no son tan graves como cuando la clave adquiere valores
nulos. La restricción de integridad de entidad no se viola. Del mismo modo, borrar una fila de la
vista afecta exactamente a una fila en la tabla básica porque el valor clave aparece en la vista. Por
tanto, los borrados también están bien definidos.
Algunos productos de base de datos toman la ruta segura y no permiten modificaciones a la

información por medio de vistas. En estos sistemas, las vistas existen solo para recuperación
personalizada de datos , y las operaciones de modificación de datos deben referirse a las tablas
base. Otros productos permiten modificaciones de datos por medio de ciertas vistas, siempre que
la definición de vista y SQL de modificaciones puedan juntos determinar el efecto preciso sobre las
tablas base fundamentales. Un criterio es que la vista se encuentre basada en una sola tabla y que
incluya los atributos clave.
El DBMS restringe la modificacion de datos por medio de vistas, peor las reglas varian de un
sistema de bases de datos a otro. No obstante, todos requiren que un cambio a la vista debe
traducirse en un cambio inequivoco de las tablas base fundamentales
Una vista puede eliminarse del catalogo del sistema mediante la sentencia DROP VIEW (eliminar
vista).
DROP VIEW vista;
Note que si se borra una tabla base, se desechara también en forma automática todas las vistas
definidas en términos de esa tabla.
No existe una proposición ALTER VIEW (alterar vista). La alteración de una tabla base mediante
ALTER TABLE no afecta a las vistas ya existentes.
144
La opción de verificación para una vista
Suponga que definimos la vista GrandesTanques. Como esta vista esta basada en una sola tabla e
incluye el atributo de clave tnro, considere que puede realizar inserciones, actualizaciones y
borrados por medio de la vista.
CREATE VIEW GrandesTanques AS

(SELECT *
FROM tanque
WHERE tvolumne > 200);
Y ahora considere las sentencias de SQL siguientes:
INSERT INTO GrandesTanques (tno, tnombre, tcolor, tvolumen)

VALUES (71, 'BigMuddy', "cafe", 150);
SELECT *
FROM GrandesTanques;
El tanque recién insertado no aparecerá en la consulta subsecuente. La instrucción INSERT

agrega una fila a la relación de tanque fundamental, especificando un nuevo tanque con un
volumen de 150. En virtud de que la definición de GrandesTanques admite solo tanques cuyos
volúmenes excedan de 200, el DBMS excluye la nueva tupla de la relación de GrandesTanques
aun cuando acaba de insertarlo de manera exitosa. Un usuario podría confundirse si no pudiera
recuperar una tupla que el haya acabado de insertar. Para evitar esto, puede agregar la frase
"whith check option" que significa con opción de verificación, a la definición de la vista. Esta
cláusula hace que falle una instrucción INSERT si la tupla que se inserte no cumple con los
requisitos de admisión de la vista. La definición (check) también bloquea cualquier actualización
por medio de la vista si la tupla actualizada desapareciera. Veamos vistas que se comportan de
modo consistente.
CREATE VIEW GrandesTanques AS

(SELECT *
FROM tanque
WHERE tvolumne > 200)
WITH CHECK OPTION;
CREATE VIEW PequeñosTanques AS

(SELECT *
FROM GrandesTanques
WHERE tvolumne < 300)
WITH CHECK OPTION;
El usuario puede construir una vista sobre una vista existente. Si utiliza la vista GrandesTanques
del ejemplo anterior como base, puede crear una segunda vista como se muestra arriba a la
derecha. ¿Es posible insertar una tupla con tvolumen = 100 en PequeñosTanques? La nueva tupla
para la opción de verificación de la definición de PequeñosTanques pero no la opción de
verificación de GrandesTanques. ¿Rechazara el DBMS la inserción?
Sí, la inserción fallara porque, por omisión, las condiciones de vista pasan en cascada a vistas
subsecuentes.
La opcion CHECK en una definicion de una vista bloquea la insercion o actualizacion de tuplas
que serian subsecuentemente excluidas de la vista
145
3.2 Independencia de datos
Los sistemas de bases de datos entregan servicios en tres niveles: físico, conceptual y externo.
Las vistas apoyan al nivel mas alto, la descripción de la base de datos externa, que puede variar
de un usuario a otro. Una vista protege a la aplicación con la que mantiene una relación de los
cambios ocurridos en los niveles mas bajos.
En el nivel mas bajo, la descripción física sirve como fundamento que soporta al nivel intermedio, o
sea el esquema conceptual. No es necesario que los cambios en el hardware o en las estructuras
de datos del disco alteren el esquema conceptual, que modela la aplicación como un conjunto de
relaciones, dominios, atributos y relaciones. Desde luego que ciertas rutinas del sistema de
administración de base de datos (DBMS) pueden requerir modificación para adaptarse al nuevo
entorno físico, peor ese trabajo le corresponde al fabricante de la base de datos. Cualquier
software de aplicación construido en el esquema conceptual permanece valido. Aislar el esquema
conceptual del hardware básico, sistema operativo y estructuras de datos, recibe el nombre de
independencia física de los datos.
La independencia física de los datos tiene una contraparte en el siguiente nivel. No es necesario
que cambios en el esquema, por ejemplo agregar nuevas tablas o nuevos atributos a tablas
existentes afecten una aplicación con una vista protectora. La definición de vista puede requerir
modificación pero la aplicación continúa funcionando como antes, siempre que la nueva vista
materialice las relaciones esperadas. Esta característica de vistas se denomina independencia
lógica de los datos; pero el aislamiento no es total. Por ejemplo, si el diseñador de una base de
datos cancela un atributo del esquema conceptual y la vista del usuario utiliza ese atributo, es
probable que el usuario no pueda restablecerlo en la vista. En lugar de esto, el usuario tendrá que
volver a escribir la aplicación y usar una nueva vista.
Una vista proporciona independencia lógica de los datos y aisla software de aplicación contra
cambios del esquema
3.3 Valores nulos
Hablemos un poco mas de este tema. En cualquier aplicación de base de datos grande,
inevitablemente se encuentran datos faltantes. Todos los sistemas de bases de datos cuentan con
alguna código interno para un valor nulo (null) que el usuario puede sustituir por un valor faltante
de atributo. Desafortunadamente, el valor nulo toma distintos significados en diferentes ocasiones.
Por ejemplo puede significar que el valor existe, peor no se sabe cual es. Supóngase que el
usuario introduce un trabajador en la tabla de empleados pera una base de datos de personal;
podría especificar el atributo de estatura como nulo porque no sabe cual es la estatura de la
persona. En otras ocasiones, el valor nulo podría significar "no aplicable". Por ejemplo supongamos
por ejemplo que el atributo cruceroAltitud se presenta en una tabla de vehículos. Los aviones
tienen altitudes de crucero, pero no los automóviles. Por lo que en las tuplas de vehículos este
atributo podrá almacenar un valor nulo que significaría en este caso "no aplica".
Operaciones con valores nulos
En presencia de valores nulos, cada operación aritmética exhibe comportamiento ligeramente

modificado, devolviendo null si cualquiera de sus operandos es null.
Ejemplos:
 nulo + nulo produce nulo
 nulo + 3 = nulo
Las operaciones booleanas se extienden a una lógica de tres valores: verdadero, falso y
desconocido. Cada operación de comparación devuelve el valor de verdad desconocido si
cualquiera de sus operandos es nulo.
146
Ejemplos:
 6 < nulo produce desconocido
 incluso nulo = nulo produce desconocido
Las operaciones lógicas es decir y, o, no; - and, or, not respectivamente- aceptan argumentos en el
intervalo de tres valores - verdadero, falso y desconocido- y devuelven valores en este mismo
intervalo. En algunos casos, la operación lógica puede devolver un valor definitivo verdadero o
falso, incluso si uno de sus operados es desconocido. Por ejemplo, verdadero "o" desconocido
devuelve verdadero; falso "y" desconocido devuelve falso. La siguiente tabla muestra las tablas de
verdad extendidas para los operadores lógicos.
Tabla 5.1 Definición de operadores lógicos en presencia de calores desconocidos de verdad
A B No A AyB AoB
verdadero verdadero falso verdadero verdadero
verdadero falso falso falso verdadero
verdadero desconocido falso desconocido verdadero
falso verdadero verdadero falso verdadero
falso falso verdadero falso falso
falso desconocido verdadero falso desconocido
desconocido verdadero desconocido desconocido verdadero
desconocido falso desconocido falso desconocido
desconocido desconocido desconocido desconocido desconocido
Una operación aritmetica devuelve nulo si cualquier de sus operandos es nulo.

Comparaciones en presencia de nulos devuelven valores en el sistema logico de tres estados:
verdadero, falso, desconocido. Los valores de tres estados se pueden combinar con los conectivos
El predicado EXISTS, cuando se aplica a una tabla construida con una subconsulta, siempre
devuelve verdadero (true) o falso (false - desconocido). Incluso si la tabla contiene solo tuplas
nulas, todavía no esta vacía y el predicado exists devuelve verdadero.
Como el operador not (no) devuelve falso o verdadero cuando se aplica a operandos verdaderos o
falsos, el predicado not exists también devuelve un valor consistente verdadero o falso, nunca un
desconocido.
Supongamos que se buscan los nombres de peces que tengan un color nulo (null).
SELECT pnombre
FROM pez
WHERE color = null
SELECT pnombre
FROM pez
WHERE color is null
La primer sentencia no es legal. SQL no admite la palabra null en comparaciones. En lugar de

esto, contiene una sintaxis especial para explorar un atributo para un valor nulo. El predicado
correcto toma la forma:
nombre-de-atributo is null o
nombre-de-atributo is not null
147
Este predicado siempre devuelve verdadero o falso, nunca un desconocido. La segunda sentencia
del ejemplo anterior de hecho recupera los nombres de peces que tengan color nulo.
3.4 Disparadores
El sistema de administración de base de datos (DBMS) generalmente responde de dos formas a la

modificación de datos que produce una violación de una restricción. Puede rechazar la
modificación y restablecer el estado de la base de datos que existía antes de la transacción, o
puede intentar posteriores ajustes para hacer que la base de datos satisfaga las restricciones.
Hasta aquí, hemos supuesto la primera solución. La segunda posibilidad permite al DBMS ejecutar
un procedimiento compensatorio para volver a ganar un estado consistente. Estos procedimientos
compensatorios se denominan rutinas disparadas. En el caso mas general comprenden, un código
de aplicación arbitrario que esta asociado a una tabla de la base de datos.
Sintaxis general de un disparador
CREATE [OR REPLACE] TRIGGER nombre

[temporalidad del evento]
[granularidad del evento]
[WHEN condición]
BEGIN cuerpo del trigger
END nombre;
/
CREATE [OR REPLACE] TRIGGER nombre

Crea o reemplaza un disparador con el nombre especificado.
[temporalidad del evento]

Puede tomar dos valores: BEFORE ó AFTER que indicará si el cuerpo del disparador
debe ejecutarse antes o después del evento que causa la activación del disparador.
Ambos valores pueden aplicarse tanto para disparadores a nivel de fila como a nivel de
orden. Un disparador se define a nivel de fila cuando el cuerpo del disparador se debe aplicar fila a
fila de la tabla afectada y se define a nivel de orden cuando se debe aplicar a toda la tabla a la
vez.
La opción BEFORE/AFTER debe acompañarse de la operación que causa la activación
del disparador. Estas pueden ser operaciones de inserción (INSERT) y/o borrado
(DELETE) y/o modificación (UPDATE) respecto a una tabla o respecto a una columna
de una tabla. Cuando se quiere especificar más operación, estas se pueden unir
utilizando los operadores OR y AND.
La forma general de la temporalidad del evento será, por tanto:

BEFORE/AFTER INSERT/UPDATE/DELETE [OF nombre_columna] ON
nombre_tabla
Por ejemplo:
BEFORE INSERT ON empleado
BEFORE INSERT OR DELETE ON empleado
BEFORE UPDATE OF salario ON empleado
Esta última se activará para una operación como:
UPDATE empleado SET salario=salario+1;

Y también para:
UPDATE empleado SET salario=salario;
Pero no para:
UPDATE empleado SET emp_cod=101;
148
La cláusula OF nombre_columna puede utilizarse tanto a nivel de fila como a nivel de
orden.
[granularidad del evento]

[WHEN condición]
Permite distinguir si el disparador es a nivel de fila o a nivel de columna.
Si queremos definir el disparador a nivel de fila, la granularidad deberá especificarse
con la cláusula FOR EACH ROW a la que habrá que acompañar de la condición que
debe cumplir la fila para aplicar el cuerpo del disparador. Esta condición se indica en la
orden SQL mediante la cláusula WHEN condición.
Cuando no exista definición del granularidad del evento, significará que el disparador
está definido a nivel de orden.
Ejemplos:
CREATE TRIGGER nivel_fila_sin_condición

AFTER DELETE OF salario ON empleado
FOR EACH ROW
BEGIN
...
CREATE TRIGGER nivel_fila_con_condición
FOR EACH ROW
WHEN empleado.salario >60000
BEGIN
...
CREATE TRIGGER nivel_columna
BEGIN
...
Si se quiere hacer mención en la condición WHEN al valor de la fila a borrar, se debe

hacer referencia mediante las variables NEW y OLD. Así, para el ejemplo anterior, el
disparador estaría correctamente definido de la siguiente manera:
CREATE TRIGGER nivel_fila_con_condición

FOR EACH ROW
WHEN OLD.salario >60000
BEGIN
...
Con OLD.nombre_columna referenciamos:

 al valor que tenía la columna antes del cambio debido a una modificación
(UPDATE)
 al valor de una columna antes de una operación de borrado sobre la misma
(DELETE)
 al valor NULL para operaciones de inserción (INSERT)
Con NEW.nombre_columna referenciamos:

 al valor de una nueva columna después de una operación de inserción (INSERT)
 al valor de una columna después de modificarla mediante una sentencia de
modificación (UPDATE)
 al valor NULL para una operación de borrado (DELETE)
BEGIN cuerpo del trigger

END nombre;
Dentro del cuerpo de un disparador podemos incluir sentencias de borrado (DELETE),
149
inserción (INSERT) o modificación (UPDATE) pero también se puede poner cualquier
otra sentencia SQL (SELECT..).
Dentro de este cuerpo también se puede hacer referencia a las variables OLD y NEW
sólo que en este caso habrá que utilizarlas con " : "delante.
Ejemplo:
BEGIN
DELETE FROM tabla2 WHERE tabla2.cod=:OLD.cod;
END Ejemplo;
Orden de Activación
El orden en que se activan varios disparadores con el mismo evento es:
1. Ejecutar, si existe, el disparador de tipo before con nivel de orden

2. Para cada fila a la que afecte la orden:
A. ejecutar, si existe, el disparador de tipo before con nivel de fila

B. ejecutar la propia orden
C. ejecutar, si existe, el disparador de tipo after con nivel de fila
3. Ejecutar, si existe, el disparador de tipo after con nivel de orden
Otras funciones de disparadores
Habilitar o deshabilitar todos los disparadores asociados a una tabla:
ALTER TABLE nombre_tabla ENABLE ALL TRIGGERS

ALTER TABLE nombre_tabla DISABLE ALL TRIGGERS
Habilitar o desabilitar un disparador específico:
ALTER TRIGGER nombre_disparador ENABLE

ALTER TRIGGER nombre_disparador DISABLE
Eliminar un disparador
DROP TRIGGER nombre_disparador*
Ver todos los disparadores y su estado. USER_TRIGGERS es una tabla del catalogo del sistema
donde se almacena información acerca de los triggers de las tablas de la base de datos.
SELECT TRIGGER_NAME , STATUS FROM USER_TRIGGERS;
Ver el cuerpo de un disparador
SELECT TRIGGER_BODY FROM USER_TRIGGERS WHERE

TRIGGER_NAME=`nombre_disparador';
Ver la descripción de un disparador
SELECT DESCRIPTION FROM USER_TRIGGERS WHERE TRIGGER_NAME=

`nombre_disparador';
150
1. Supongamos que tenemos las siguientes tablas cuenta y transacción con los siguientes
atributos: cuenta: nro_cuenta (10 caracteres) y balance (numérico). El campo numero_cuenta es la
clave primaria.
transaccion: nro_cuenta(10 caracteres), hora_modificacion (tipo fecha), id_cliente (10 caracteres),
ant_balance (numérico), act_balance (numérico). Los campos nro_cuenta y hora_modificación
forman la clave primaria.
Crear un disparador que consiga mantener actualizada la tabla transacción cada vez
que se modifique la tabla cuenta (se cambie el atributo balance).
2. Supongamos que tenemos una tabla de distancias de diferentes rutas y que queremos
guardar estas distancias en kilómetros y en millas.
distancias: ruta (10 caracteres), distancia_k (numérico), distancia_m (numérico). Siendo ruta la
clave principal.
Crear disparadores para conseguir que cuando se introduzca (o se modifique) una distancia en
kilómetros, automáticamente se introduzca también en millas y viceversa. (1 Km=0.621371 millas y
1 Milla=1.609344 Km).
151
1. Sean A y B dos relaciones.
Supongamos que las dos son compatibles respecto a la union, compatibles respecto al
producto, etc., en caso necesario. Indicar la clave primaria de cada una de las siguientes
relaciones:
a. Una restricción arbitraria de A;

b. Una proyección arbitraria de A;
c. El producto A TIMES B;
d. La union A UNION B;
e. La intersección A INTERSEC B;
f. La diferencia A MINUS B;
g. La reunión natural A JOIN B;
h. El cociente A DIVIDEBY B.
2. Sean las siguientes relaciones:
DEPTO (nro_depto, nom_depto)

EMP (nro_emp, nom_emp, fec_ing, cargo, salario, nro_depto)
Resuelva los ejercicios que se describen a continuación en álgebra relacional y en SQL.
a. Nombre de empleado y número de departamento de todos los empleados.

b. Todos los datos de los empleados con salario entre 300 y 400.
c. Número, nombre y salario de los empleados cuyo cargo es ‘DIRECTOR’ o ‘PRESIDENTE’.
d. Nombre de los departamentos que tengan empleados.
e. Nombre de los empleados del departamento ‘CONTABILIDAD’.
f. Nombre de los departamentos que tengan empleados con cargo ‘ANALISTA’.
g. Nombre de los departamentos que no tengan empleados con cargo ‘ANALISTA’.
h. Número de los empleados que trabajan en el mismo departamento que ‘REY’.
i. Número de los empleados más antiguos que el ‘PRESIDENTE’.
j. Nombre de los departamentos que tienen empleados en todos los cargos.
k. Número, nombre y salario anual (salario * 12) de los empleados con cargo ‘VENDEDOR’
l. Cantidad de empleados por departamento ( Nombre de departamento, cantidad de
empleados ).
m. Máximo, mínimo, y promedio de salarios por departamento ( Nombre de departamento,
máximo, mínimo, promedio )
n. Máximo, mínimo y promedio de salarios.
o. Nombre de los departamentos que tengan más de 3 empleados.
p. Número de los empleados con menor salario en cada departamento ( Número de
empleado, Número de departamento ).
q. Número de los empleados con salario mayor al promedio del departamento.
r. Número de los empleados con menor salario que el mayor salario del departamento 30.
3. Cree dos vistas basadas en la base de datos del punto anterior, que incluyan alguno de los
siguientes operadores: Like, In, (Not) Exists, Between. ( Para cada vista debe realizar una
explicación del resultado que se va a obtener)
4. Considerando las siguientes dos tablas:
EMPLEADO: nss(numérico), nombre (10 caracteres), salario (numérico), num_dep (10

caracteres)
DEPARTAMENTO: num_dep (10 caracteres), nombre (10 caracteres), presupuesto
(numérico)
152
a. Diseñar un disparador que al insertar un nuevo empleado, automáticamente quede
actualizado el presupuesto total del departamento al que el empleado pertenece,
añadiéndole el salario asignado al nuevo empleado.
b. Diseñar un disparador que al modificar el salario de un empleado, automáticamente
quede actualizado el presupuesto total del departamento al que el empleado
pertenece, en función del nuevo salario asignado al empleado.
153
Unidad VI: Diseño de Bases de Datos
Orientación del Aprendizaje
Nombramos a esta unidad como Diseño de bases de datos para destacar la importancia del diseño
en general y las técnicas de normalización. La experiencia nos muestra que un buen diseño debe
siempre estar acompañado con un buen relevamiento del negocio y un buen entendimiento de que
se quiere almacenar en una base de datos, junto con esto debemos conocer perfectamente las
técnicas de normalización y otros aspectos igualmente importantes de diseño que desarrollaremos
a continuación. La normalización de datos es un procedimiento que asegura que un modelo de
datos se ajusta a algunos estándares útiles. Para los datos y los modelos entidad-relación, estos
estándares se han definido para minimizar la duplicación de datos, proporcionar la flexibilidad
necesaria para soportar requisitos funcionales y para permitir que el modelo se estructure sobre
una amplia variedad de diseños alternativos de bases de datos.
Contenido de la Unidad

2. Teoría de normalización
2.1 Dependencia funcional
2.2 Formas Normales
2.3 Forma Normal de Boyce/Codd
 Aprender a identificar en que forma normal se encuentran las entidades de una base de datos.
 Identificar cuando una base de datos esta desnormalizada y llevarla a la forma normal
adecuada.
 Entender las formas normales como una formalización del sentido común.
 Valorar la importancia de un buen diseño lógico de una base de datos y como favorece para el
traspaso al diseño físico.
 Comprobar como los conceptos del modelo relacional y la técnica de normalización ayudan a
un buen diseño de una base de datos.
154
Esquema conceptual
Información del Negocio Formas Normales
Universo de las relaciones (normalizadas y no normalizadas)

Relaciones en 1FN
Relaciones en 2FN
Relaciones en 3FN
Relaciones en FNBC
Relaciones en 4FN
Relaciones en 5FN
Bases de Datos
bien diseñadas
El problema de diseñar una base de datos se puede expresar de manera muy sencilla. Si
pensamos en un conjunto de datos que se debe representar en una base de datos. ¿Cómo
155
decidimos cual es la estructura lógica adecuada para esos datos? En otras palabras ¿Cómo
decidimos cuales relaciones base deberán existir y que atributos deberán tener?
En primer lugar debemos tener en cuenta que en esta instancia solo nos preocupa el problema de
diseño lógico, no el diseño físico, no es que el diseño físico carezca de importancia pero puede
manejarse como una actividad separada.
La forma correcta de diseñar una base de datos en un sistema relacional es hacer primero
un diseño lógico limpio, es decir relacional, y después como paso aparte establecer la
correspondencia entre ese diseño lógico y cualquier estructura física que pueda manejar el
DBMS objetivo.
El diseño físico tiende a ser un tanto especifico con respecto al DBMS, el diseño lógico en cambio
es - o deberá ser - mas independiente del DBMS y existen varios principios teóricos sólidos que se
pueden aplicar al problema.
En general nos ocuparemos del diseño independiente de las aplicaciones. Nos centraremos
sobre todo en la naturaleza de los datos no la forma en como se utilizaran. En este sentido es
deseable la independencia con respecto a las aplicaciones por una razón muy buena: por lo
regular en el momento de hacer el diseño, no se conocen todas las formas como se utilizaran los
datos, por lo cual desearemos un diseño robusto, en el sentido de que no perderá validez si se
presentan requerimientos de aplicación nuevos no contemplados en el momento de hacerse el
diseño original. Lo que estamos tratando de hacer es diseñar el esquema conceptual: producir un
diseño lógico abstracto independiente del equipo, independiente del sistema operativo,
1
independiente del DBMS, independiente del lenguaje, independiente del usuario, etc. etc .
2. Teoría de normalización
Consideremos una vez mas la base de datos de proveedores y partes:
Los proveedores los representaremos con la relación S

--- ---- --------- ----------- ---------
S S# SNOMBRE SITUACION CIUDAD
--- ---- --------- ----------- ---------
S2 Jaime 10 París
S3 Bernal 30 París
S5 Aldana 30 Atenas
Las partes las representaremos con la relación P

--- ---- --------- ------- ------- --------
P P# PNOMBRE COLOR PESO CIUDAD
--- ---- --------- ------- ------- --------
P1 Tuerca Rojo 12 Londres
P2 Perno Verde 17 París
P3 Birlo Azul 17 Roma
P4 Birlo Rojo 14 Londres
P5 Leva Azul 12 París
P6 Engrane Rojo 19 Londres
Los envíos los representamos con la relación SP
--- ---- ----- -----

SP S# P# CANT
--- ---- ----- -----
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
156
S1 P6 100
S2 P1 300
S2 P2 400
S3 P3 200
S4 P2 200
S4 P4 300
S4 P5 400
La estructura lógica si parece ser la correcta necesita tres relaciones (S, P y SP) donde por
ejemplo, el atributo COLOR de parte debe estar en la relación P, el atributo de CIUDAD del
proveedor pertenece a la relación S, el atributo CANT pertenece a la relación SP, etc. Pero ¿qué
nos indica que esto es verdad? Tal vez podamos entenderlo un poco mas si vemos que sucede si
la estructura se modifica de alguna manera. Supongamos que el atributo CIUDAD de proveedor se
saca de la relación S y se pasa a la relación SP, el cual intuitivamente podemos afirma que es el
lugar equivocado, puesto que "ciudad de proveedor" obviamente tiene que ver con los
proveedores, no con los envíos. Veamos la tabulación de la relación SP modificada.
--- ---- -------- ----- -----

SP S# CIUDAD P# CANT
--- ---- -------- ----- -----
S1 Londres P1 300
S1 Londres P2 200
S1 Londres P3 400
S1 Londres P4 200
S1 Londres P5 100
S1 Londres P6 100
S2 París P1 300
S2 París P2 400
S3 París P3 200
S4 Londres P2 200
S4 Londres P4 300
S4 Londres P5 400
Es evidente que la base de datos contiene ahora un alto grado de redundancia; cada una de las
tuplas en SP' del proveedor S1 nos dice que S1 esta situado en Londres y lo mismo sucede con los
proveedores S2 situado en París y S4 también situado en Londres. O sea que la ciudad se repite
por cada envío que posea el proveedor. Esa redundancia provoca varios problemas. Por ejemplo si
actualizamos la relación de Proveedor, S modificando la ciudad del proveedor S1 por Amsterdam,
en la relación de Envíos, SP el proveedor S1 nos quedara situado en Londres. Así pues un
principio de diseño podría ser "cada dato en un lugar".
Los temas que desarrollaremos a lo largo de la sección, la teoría de normalización, tienen

que ver con la expresión formal de ideas sencillas como esta.
Algo que debe quedar absolutamente claro es que el diseño de bases de datos es en realidad es
diseño de esquemas. Cuando diseñamos una base de datos nos interesan las propiedades de los
datos que siempre se cumplen, no propiedades que por casualidad son ciertas en algún instante
especifico. Por ejemplo: la propiedad "toda parte tiene un peso" siempre es cierta; en cambio la
propiedad "todas las partes rojas están almacenadas en Londres" es solo una coincidencia que se
muestra en la tabulación de la relación Partes.
La teoría de la normalización tiene como fundamento el concepto de formas normales que

desarrollaremos mas adelante. Se han definido un gran numero de formas normales.
Originalmente Codd definió la primera, segunda y tercera formas normales -1NF, 2 NF, 3 NF-
157
También introdujo la idea de un procedimiento de normalización con el cual una relación en cierta
forma normal digamos 2NF se puede convertir en un conjunto de relaciones en una forma mas
deseable. Cabe aclarar que el procedimiento es reversible; es decir, siempre es posible tomar la
salida del procedimiento, por ejemplo el conjunto de relaciones en 3NF, y convertirlas otra vez en
la entrada, en este caso en la relación 2 NF original. Esa reversibilidad es importante, porque
significa que no se pierde información durante el proceso de normalización adicional.
La idea general de la normalización es que el objetivo del diseñador de bases de datos debe ser
llevar las relaciones a la forma normal "final" (5NF) , si embargo esta recomendación no deberá
tomarse como una ley; en ocasiones hay buenas razones para descartar los principios de
normalización. El único requerimiento rígido es que las relaciones estén por lo menos en primera
forma normal. La teoría de normalización es útil para el proceso del diseño de una base de datos,
pero no es una panacea; sin duda es recomendable que toda persona encargada de diseñar una
base de datos este familiarizada con las técnicas básicas de normalización tal como describimos
en esta sección, pero no por fuerza el Ximeno debe basarse solo en los principios de
normalización.
2.1 Dependencia Funcional:
Comenzaremos el desarrollo de la teoría de la normalización con la definición del concepto

fundamental de "dependencia funcional".
Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R:
R.X R.Y Esto se lee: R.X determina funcionalmente a R.Y
Si y solo si, en cualquier momento dado, un solo valor Y en R esta asociado a cada valor X en R.
Los atributos pueden ser compuestos.
Veamos un ejemplo: En la base de datos de proveedores y partes, los atributos SNOMBRE,

SITUACION y CIUDAD de la relación S son todos funcionalmente dependientes del atributo S# de
la relación S, porque dado un valor especifico de S.S#, existe solo un valor correspondiente de
S.SNOMBRE, S.SITUACION y S.CIUDAD.
S.S# S.SNOMBRE
S.S# S.SITUACION
S.S# S.CIUDAD
S.S# S.(SNOMBRE, SITAUCION, CIUDAD)
Veamos también un ejemplo opuesto:
P.COLOR P.PESO
En la relación P no sucede que para cada color haya un solo peso; por ejemplo, P1 es roja y tiene
un peso de 12, P6 también es roja pero tiene un peso de 19.
Si el atributo X es una clave candidata de la relación R, en particular si es clave primaria, entonces

todos los atributos Y de la relación R deben por fuerza depender funcionalmente de X - esto se
desprende de la definición de clave candidata -. Advierta que la definición de dependencia
funcional no requiere que X sea una clave candidata de R.
Presentamos una definición de dependencia funcional tomada del libro de C. J Date.
158
Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R si y solo si,
siempre que dos tuplas de R concuerden en su valor de X deben por fuerza concordar en su valor
de Y.2
También definimos el concepto de dependencia funcional completa:
Se dice que el atributo Y de la relación R es por completo dependiente funcionalmente del atributo
X de la relación R si depende funcionalmente de X y no depende funcionalmente de ningún
subconjunto propio de X.
Veamos un ejemplo: En la relación SP, el atributo CIUDAD depende funcionalmente del atributo
compuesto (S#,P#):
SP.(S#,P#) SP.CIUDAD
Pero no es una dependencia funcional completa porque tenemos la dependencia funcional:
SP.S# SP.CIUDAD
CIUDAD depende funcionalmente de S# solamente
Debe entenderse que la dependencia funcional es un concepto semantico, reconocer las

dependencias funcionales es parte del proceso de entender que significan los datos. El hecho de
que CIUDAD dependa funcionalmente de S# significa que cada proveedor esta situado en una sola
ciudad. Lo que significa que existe una restricción en el mundo real representado por la base de
datos que cada proveedor esta situado en una sola ciudad.
Debe entenderse también, a raíz de lo anterior que la dependencia funcional es un tipo especial de
restricción de integridad, deberá ser posible expresarla en la sintaxis del lenguaje de integridad
presentado anteriormente o en cualquier otra sintaxis similar.
Debe tener en cuenta que las dependencias funcionales representan interrelaciones de muchos a
uno. La dependencia funcional anterior puede leerse como "muchos proveedores están situados en
la misma ciudad", pero un proveedor esta situado en una sola ciudad.
Encuentre las dependencias funcionales que se encuentran en la base de datos del acuario
desarrollada en la unidad II. Identifique las dependencias funcionales y las dependencias
funcionalmente completas.
2.2 Formas Normales
 Una relación esta en primera forma normal (1NF) si y solo si todos los dominios simples
subyacentes contiene solo valores atómicos.
Veamos un ejemplo para entender el concepto de valores atómicos:

Si en una relación existen tuplas con mas de un valor para un solo dominio en un momento dado.
Ejemplos:
S S# SNOMBRE CIUDAD
S1 Juan, Perez Paris
S2 Lucas, Jimenez Londres
S3 Sebastian, Fox Paris
El dominio del atributo SNOMBRE no contiene valores atómicos, por lo tanto la relación S no esta
en primera forma normal, deberíamos descomponerla como sigue:
S S# SNOMBRE SAPELLIDO CIUDAD

159
S1 Juan Perez Paris
S2 Lucas Jimenez Londres
S3 Sebastian Fox Paris
De esta forma todos los dominios simples son atómicos y la relación esta en 1NF.
Una relación que esta en 1NF pero no esta en 2NF y por lo tanto tampoco en 3NF, tiene una
estructura indeseable por varias razones. Supongamos que la información acerca de proveedores
y envíos, no esta dividida en dos relaciones sino que esta amontonada en una sola relación como
sigue:
PRIMERA(S#, SITUACION, CIUDAD, P#, CANT)
Veamos la tabulación de dicha relación como para fundamentar algunos problemas
PRIMERA S# SITUACION CIUDAD P# CANT

---- --------- --------- ---- ------
S1 20 Londres P1 300
S2 10 Paris P2 400
S2 10 Paris P2 200
S3 10 Paris P2 200
Veamos también las dependencias funcionales:
S# SITUACION
CANT
P# CIUDAD
Las redundancias de la relación PRIMERA provocan diversos casos de lo que suele llamarse
"anomalías de actualización" es decir, problemas con las operaciones INSERT, DELETE y
UPDATE . Nos concentraremos primero en la redundancia de la ciudad del proveedor provocada
por la dependencia funcional PRIMERA.S# PRIMERA.CIUDAD.
INSERT: Si tenemos en cuenta que la clave primera de la relación PRIMERA es numero de

proveedor y numero de parte, no podremos insertar un nuevo proveedor en tanto ese proveedor no
suministre por lo menos una parte. Recuerde la definición de la regla de integridad de las
entidades.
160
DELETE: Si eliminamos una única tupla de un proveedor en la relación PRIMERA , destruiremos
no solo el envió que relaciona a ese proveedor con alguna parte sino también la información de
que el proveedor esta situado en cierta ciudad.
UPDATE: Note que el valor de ciudad de un proveedor dado aparece varias veces en PRIMERA.
Esta redundancia provoca problemas de modificación. Por ejemplo si el proveedor S1 cambia de
Londres a Amsterdam, nos enfrentamos al problema de revisar PRIMERA para localizar todas las
tuplas que conectan a S1 y a Londres y modificarlas o bien a producir un resultado inconsistente ya
que podría aparecer que la ciudad de S1 es Amsterdam y en otra que es Londres.
La solución a estos problemas es dividir la relación PRIMERA en dos relaciones:
SEGUNDA (S#, SITUACION, CIUDAD)
SP (S#, P#, CANT)
Veamos la tabulación de las dos relaciones:
---- ----------- -------

SEGUNDA S# SITUACION CIUDAD
---- ----------- -------
S1 20 Londres
S2 10 Paris
S3 10 Paris
S4 20 Londres
S5 30 Atenas
--- --- -----

SP S# P# CANT
--- --- -----
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400
Veamos la dependencia funcional:
SITUACION
S#
CANT
S#
P#
CIUDAD
161
Observe que se ha incluido información del proveedor S5 en la relación SEGUNDA pero no es SP.
deberá ser evidente que esta estructura modificada resuelve todos los problemas relacionados con
las operaciones de actualización antes bosquejados. Además comparando las figuras de las
dependencias funcionales podemos decir que la modificación estructural que realizamos ha sido
el8iminar las dependencias no completas. Intuitivamente podemos decir que en la relación
PRIMERA el atributo CIUDAD no describía la entidad identificada por la clave primaria, o sea un
envió, sino que describía al proveedor implicado en ese envió. El origen real de los problemas fue
la mezcla de los dos tipos de información en la misma relación.
Presentaremos ahora la definición de segunda forma normal
 Una relación esta en segunda forma normal (2NF) si y solo si esta en 1NF y todos los
atributos no claves dependen por completo de la clave primaria.
Las relaciones SEGUNDA y SP están en 2NF. La relación PRIMERA no esta en 2NF. Cuando una
relación esta en 1NF y no en 2NF siempre podrá reducirse a un conjunto equivalente de relaciones
en 2NF. Este proceso de reducción es, precisamente, un proceso de sacar proyecciones; es decir,
el operador de descomposición es la proyección, de manera similar el operador de recomposición
es la reunión natural.
La sustitución de PRIMERA por SEGUNDA y SP en el ejemplo muestran lo que se conoce como
descomposición sin perdidas Como no se pierde información en esa descomposición, cualquier
información derivable de la estructura original podrá derivarse también de la nueva estructura, pero
advierta que lo contrario no se cumple: la nueva estructura puede contener información -tal es el
caso en el ejemplo del proveedor S5 esta situado en Atenas- que no podría representarse en la
original.
Pero la estructura SEGUNDA/SP todavía causa problemas. La relación SP ya esta en 3NF no nos
detendremos en ella por ahora, pero la relación SEGUNDA en cambio todavía sufre de una falta de
independencia mutua entre sus atributos no clave.
Analicemos la figura de la dependencia funcional. La dependencia de SITUACION con respecto a
S#, aunque es funcional y completa, es transitiva a traces de CIUDAD; esto es, cada valor de S#
determina un valor de CIUDAD, y ese valor de CIUDAD determina a su vez el valor de
SITUACION.
Veamos las anomalías que presentan las dependencias transitivas:
INSERT: No podemos insertar el hecho de que una cierta ciudad tiene una situación determinada,
por ejemplo no podemos especificar que cualquier proveedor de Roma debe tener una situación de
50, en tanto no tengamos algún proveedor situado en esa ciudad.
DELETE: Si eliminamos una única tupla en SEGUNDA de una ciudad determinada, destruimos no
solo la información del proveedor en cuestión, sino también la información de que esa ciudad tiene
una situación determinada.
UPDATE: En general la situación de una ciudad dada aparece en SEGUNDA muchas veces,
todavía estamos en presencia de redundancia, si necesitáramos cambiar la situación de Londres
de 20 a 30, nos enfrentamos al problema de revisar SEGUNDA hasta encontrar todas las tuplas de
Londres y modificarlas, o bien a la posibilidad de producir un resultado inconsistente.
Una vez mas, la soluciona los problemas es sustituir la relación original por dos proyecciones:
SC (S#, CIUDAD)
CS (CIUDAD, SITUACION)
Veamos los diagramas de dependencia funcional:
S# CIUDAD CIUDAD SITUACION

162
deberá ser evidente que esta estructura modificada resuelve los problemas antes planteados.
Veamos dos definiciones de la tercera forma normal:
 Una relación esta en tercera forma normal (3NF) si y solo si esta en 2NF y todos los
atributos no clave dependen de manera no transitiva de la clave primaria.
 Una relación esta en 3NF si y solo si los atributos no clave son:

(a) Mutuamente independientes, y
(b) Dependientes por completo de la clave primaria
Un atributo no clave es cualquier atributo que no participa en la clave primaria de la

relación en cuestión.
Dos o mas atributos son mutuamente independientes si ninguno de ellos depende
funcionalmente de cualquier combinación de los otros.
Las relaciones SC y CS están en 3NF. La relación SEGUNDA no esta en 3NF. Cuando una
relación esta en 2NF y no en 3NF siempre podrá reducirse a un conjunto equivalente de relaciones
3NF.Como hemos indicado anteriormente el proceso es reversible, no se pierde información en la
reducción.
Debemos tener en claro que el nivel de normalización de una relación dada es cuestión de
semántica, no solo cuestión de los valores de los datos que aparecen en una relación en un
momento especifico. No es posible observar la tabulación de una relación dada en un instante
dado y decir, sin mas información, si esa relación esta en 3NF, por ejemplo; es necesario además
conocer el significado de los datos, dependencias, claves, y reglas de negocios.
Note que el proceso de normalización, no es mas que la formalización de la intuición y el sentido

común del diseñador junto con un buen conocimiento de los datos y las reglas que se quieren
representar en esa base de datos.
Tomando relaciones de las bases de datos presentadas a lo largo del desarrollo de la guía.
Represente dos ejemplos por cada una de las formas normales aprendidas. Realice las
descomposiciones o recomposiciones necesarias.
2.3 Forma Normal de Boyce y Codd
La definición original de Codd de 3 NF tenia ciertas deficiencias; no manejaba de manera

satisfactoria el caso de una relación en la cual:
(a) hay varias claves candidatas,

(b) las claves candidatas son compuestas,
(c) las claves candidatas se traslapan; es decir, tienen por lo menos un atributo en común.
Así pues la definición original de 3NF se sustituyo por la definición mas sólida de Boyce y Codd, la
cual atendía también este caso y el nuevo nombre fue forma normal Boyce/Codd (BCNF). Y en el
caso de una relación en la cual no son aplicables (a), (b) y (c), la BCNF se reduce a la antigua 3NF.
163
Para definir BCNF es conveniente introducir primero el termino "determinante".
Determinante: es un atributo del cual depende funcionalmente por completo algún otro atributo.
Ahora si:
 Una relación esta en forma normal de Boyce/Codd si y solo si todo determinante es una
clave candidata.
Adviértase que ahora estamos hablando en términos de claves candidatas, no solo de la clave
primaria. Además sigue siendo cierto que cualquier relación puede descomponerse sin perdidas en
un conjunto equivalente de relación BCNF.
Antes de examinar algunos ejemplos con múltiples claves candidatas demuestre porque las
relaciones PRIMERA y SEGUNDA no están en BCNF y porque SP, SC y CS si están en BCNF.
Ejemplo 1: en este ejemplo consideremos dos claves candidatas sin atributos comunes.
Supongamos la relación de Proveedores
S(S#, SNOMBRE, SITUACION, CIUDAD)
S# y SNOMBRE son claves candidatas; es decir, en todo momento se cumple que todos los
proveedores tiene números de proveedores únicos y nombres únicos. Supongamos que los
atributos situación y ciudad son independientes entre si. Veamos el diagrama de dependencia
funcional:
S# SITUACION
SNOMBRE CIUDAD
La relación presentada esta en BCNF. El diagrama de dependencia es mas complejo que el de

3NF pero sí se cumple la condición de que los únicos determinantes son las claves candidatas. Por
lo tanto podemos decir que la existencia de varias claves candidatas no es necesariamente mala.
Ejemplo 2: En este ejemplo las claves candidatas se traslapan:
SSP (S#, SNOMBRE, P#, CANT)
Las claves candidatas son (S#, P#) y (SNOMBRE, P#). Esta relación no esta en BCNF porque
contiene dos determinantes S# y SNOMBRE que no son claves candidatas de la relación - S# y
SNOMBRE son determinantes porque cada uno determina al otro -
Veamos la tabulación de esta tabla.
--- --- ------- --- -----

SSP S# SNOMBRE P# CANT
--- --- ------- --- -----
S1 Salazar P1 300
S1 Salazar P2 200
S1 Salazar P3 400
S1 Salazar P4 200
... .... ... ...
... .... ... ...
Como puede verse en la figura, la relación SSP incluye el mismo tipo de redundancias que
mostraba las relaciones PRIMERA y SEGUNDA y SP por lo tanto esta sujeta al mismo tipo de
anomalías de actualización.
164
La solución a los problemas de SSP es, desde luego, decomponer la relación en dos proyecciones,
en este caso las proyecciones:
SS (S#, SNOMBRE) y SP (S#, P#, CANT),
O bien las proyecciones
SS (S#, SNOMBRE) y SP (SNOMBRE, P#, CANT)
Todas estas proyecciones están en BCNF. EL diseño original es deficiente, sus problemas son
obvios en forma intuitiva, es poco probable que algún diseñador lo propusiera seriamente. El
sentido común le diría que el diseño SS/SP es mejor. Tengan en cuenta que el único objetivo de la
teoría fundamental de toda esta área es tratar de identificar esos principios del sentido común y
formalizarlos.
Encuentre Ud. mismo dos ejemplos mas por la forma normal de Boyce/Codd. Realice las
descomposiciones o recomposiciones necesarias.
Paso 1: Cada entidad simple se traduce a una tabla. Una norma útil es utilizar la forma plural de la
entidad para el nombre de la tabla.
Paso 2: Cada atributo se traduce a una columna candidata del mismo nombre, y es el momento en
que se puede elegir un formato mas preciso.
Los atributos opcionales se convierten en columnas nulas.
Los atributos obligatorios se convierten en columnas no nulas.
Paso 3: Los componentes del identificador único de la entidad se convierten en la clave primaria de
la tabla. Hay que recordar que puede haber mas de un identificador único para una entidad, y se
elige el mas usado.
También hay que recordar que una entidad solo se puede identificar por una combinación de
atributos y/o relaciones. Cuando se usan las relaciones, hay que seguir la relación y hay que
recoger como columnas una copia de los componentes de identificación unidos de la entidad en el
ultimo extremo de la relación como parte de la clave primaria. Esto puede resultar recursivo hasta
que se encuentren eventualmente los atributos.
Durante este proceso, los nombres de terminaciones de relaciones y/o nombres de entidades se
utilizan con los nombres de los atributos, para sugerir los nombres de columnas únicos y poderse
usar como parte de claves externas.
Paso 4: Las relaciones de muchos a uno y de uno a uno se convierten en claves externas. Es
decir, hay que recoger una copia de un identificador único de cada entidad referenciada de la
terminación uno y utilizarlo como columnas candidatas.
Relaciones opcionales crean columnas nulas.
Relaciones obligatorias crean columnas no nulas.
165
Unidad VII: El ambiente de las bases de datos
Orientación del aprendizaje
Hasta ahora nos hemos concentrado en el diseño de una base de datos, su estructura y la forma
de manipular los datos que dicha base almacena; pero nos estamos olvidando de su entorno, de
los recursos adicionales que tenemos que definir para poder trabajar en un ambiente confiable y
seguro. En esta unidad desarrollaremos técnicas que nos permitirán poder compartir datos en un
sistema multiusuario pudiendo modificarlos sin que se presenten mayores inconvenientes para los
demás usuarios que consultan dicho dato; y por otra parte aprenderemos a manejar la seguridad
en una base de datos para cuidar que los datos no sean accedidos por usuarios no autorizados, y
para mantener la integridad de la información almacenada.
Contenidos de la unidad
1. El ambiente de bases de datos

2. Recuperación y concurrencia
2.1 Puntos de sincronización
2.2 Compromiso en dos fases
2.3 Tres problemas de concurrencia
3. Seguridad
3.1 Seguridad en SQL
4. Integridad
4.1 Un lenguaje de integridad hipotético
 Identificar los problemas que provoca la concurrencia en una base de datos.

 Valorar la importancia que tiene trabajar en un sistema de transacciones.
 Saber otorgar y restringir privilegios sobre los datos, entendiendo la importancia del cuidado de
la información.
 Conocer los riesgos que genera trabajar en un sistema donde no se controle la seguridad.
1. El ambiente de bases de datos
Un sistema completo debe ofrecer por fuerza varios recursos adicionales aparte de las funciones
básicas de acceso a datos analizadas hasta ahora. La información en una base de datos esta
sujeta a varios peligros tanto deliberados como accidentales. Por ejemplo un disco podría sufrir
daño físico o destruirse, o ciertos datos confidenciales podrían quedar expuestos a un usuario no
autorizado, por lo tanto el DBMS deberá ofrecer un conjunto apropiado de controles para proteger
la base de datos contra este tipo de riesgos. Entre los controles necesarios están los de
recuperación, concurrencia, seguridad e integridad.
Supondremos en la mayor parte de esta unidad que estamos en un ambiente "grande" o de

macrocomputador. Los DBMS "pequeños" no suelen ofrecer apoyo para la recuperación y
concurrencia; la cuestión de concurrencia no es pertinente y la recuperación se considera como
problema del usuario.
2. Recuperación y concurrencia
Los problemas de recuperación y concurrencia en un sistema de bases de datos están muy

vinculados a la noción de procesamiento de transacciones. Explicaremos primero que es una
transacción, que significa el termino procesamiento de transacciones y que significan las funciones
COMMIT y ROLLBACK.
166
Recuperación de transacciones
Una transacción es una unidad lógica de trabajo. Consideremos el siguiente ejemplo. Supongamos
que la tabla P de partes definida en la unidad 3 posee un campo adicional CANTTOTAL que
representa la cantidad total enviada; lo que significa que para una parte dada el valor de
CANTTOTAL es igual a la suma de todos los valores SP.CANT - de la tabla SP de envíos también
definida en la unidad 3- de todos los registros SP correspondientes a esa parte. Consideremos
ahora que se quiere añadir un nuevo envío (S5, P1, 1000) a la base de datos.
EXEC SQL WHENEVER SQLERROR GO TO ANULAR;

EXEC SQL INSERT
INTO SP (S#, P#, CANT)
VALUES ('S5', 'P1', 1000);
EXEC SQL UPDATE P
SET CANTTOTAL=CANTTOTAL + 1000
WHERE P#='P1';
EXEC SQL COMMIT;
GO TO TERMINAR;
ANULAR:
EXEC SQL ROLLBACK;
TERMINAR:
RETURN;
La proposición INSERT agrega el nuevo envío a la tabla SP, la proposición UPDATE pone al día
en forma apropiada el campo CANTTOTAL de la parte P1.
El objetivo de este ejemplo es mostrar que una operación supuestamente individual y atómica -
"añadir un nuevo envío"- implica en realidad dos modificaciones de la base de datos. Note que la
base de datos deja de ser consistente entre esas dos modificaciones; viola en forma temporal el
requerimiento en la cual el valor de CANTTOTAL para la parte P1 debe ser la suma de todos los
valores SP.CANT correspondientes a esa parte. Entonces podemos decir que una unidad lógica de
trabajo o una transacción no es por fuerza una sola operación en la base de datos; es una
secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de
datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos lo
1
puntos intermedios
Lo que no debemos permitir en el ejemplo es la ejecución de una de las dos modificaciones. Se
deben ejecutar las dos o ninguna para mantener la consistencia de la base de datos. Pero es
imposible tener garantía absoluta de que se realizaran las dos operaciones, siempre existe la
posibilidad de una falla, por ejemplo el sistema podría caerse justo después de la primera
modificación, o podría haber un desborde aritmético en la segunda, etc. No obstante, si el sistema
maneja el procesamiento de transacciones podrá ofrecer lo mas cercano a esa garantía, lo que
significa que si la transacción ejecuta algunas modificaciones y después se presenta una falla
antes de que llegue el termino norma de la transacción, se anularan esas modificaciones. Así bien
la transacción se lleva a cano en su totalidad o se cancela en su totalidad. De esta manera puede
lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo
desde un punto de vista externo.
El componente del sistema encargado de lograr esa atomicidad se conoce como manejador de
transacciones y la clave de su funcionamiento son las operaciones COMMIT (comprometer) y
ROLLBACK (retroceder).
1
Iberoamericana
167
COMMIT: esta operación señala el termino exitoso de la transacción ; le dice al manejador de
transacciones que se ha finalizado correctamente una unidad lógica de trabajo, la base de datos
esta de nuevo en un estado consistente y que las modificaciones realizadas por esa unidad de
trabajo se pueden "comprometer" o hacer permanentes.
ROLLBACK: esta operación en cambio indica el termino no exitoso de la transacción; le dice al

manejador de transacciones que algo salió mal, que la base de datos podría no estar en un estado
consistente, y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de
trabajo deben "retroceder" o anularse.
Analizando la codificación del ejemplo; "EXEC SQL WHENEVER SQLERROR GO TO ANULAR" nos
indica que si cualquiera de las dos proposiciones de modificación produce una condición
SQLERROR la ejecución del programa siga por la cláusula ANULAR donde allí emitiremos un
ROLLBACK, a fin de anular todas las modificaciones efectuadas hasta ese momento.
¿Como es posible anular una modificación? El sistema mantiene una bitácora o diario en disco, en
los cuales se registran los detalles de todas las operaciones de actualización, en particular, los
valores inicial y final del objeto modificado. Entonces si resulta necesario anular alguna
modificación especifica, el sistema puede utilizar la entrada correspondiente de la bitácora para
restaurar el valor original del objeto modificado.
Un punto a tener en cuenta en un sistema relacional las proposiciones de manipulación de datos
se encuentran en el nivel de conjuntos y por lo regular trabajan con varios registros a la vez. ¿Qué
sucedería si hay alguna falla durante la ejecución de una proposición de estas? Por ejemplo ¿es
posible que una actualización (UPDATE) de múltiples registros ponga al día varios de sus registros
objetivo y después falle antes de poner al día el resto?. La respuesta es que no es posible, las
proposiciones individuales de SQL deben ser por fuerza atómicas en lo concerniente a su efecto
sobre la base de datos. Si se llega a presentar un error durante la ejecución de esas proposiciones,
la base de datos no sufrirá alteración alguna.
¿Una transacción puede ser anidada dentro de otra? ¿Por qué?
2.1 Puntos de sincronización
Un punto de sincronización establece el limite entre dos transacciones consecutivas, de modo que
corresponde al final de una unidad lógica de trabajo y por lo tanto al punto en el cual la base de
datos debería estar en un estado de consistencia. Las únicas operaciones que establecen un punto
de sincronización son COMMIT, ROLLBACK y el inicio de un programa.
Entonces cuando se establece un punto de sincronización:
 Se comprometen (COMMIT) o anulan (ROLLBACK) todas la modificaciones realizadas por el

programa desde el punto de sincronización anterior.
 Se cierran todos los cursores abiertos y se pierde todo posicionamiento en la base de datos.
 Se liberan todos los registros bloqueados.
En conclusión podemos percatarnos ya que las transacciones no solo son la unidad de trabajo sino
también la unidad de recuperación. Pues si una transacción se compromete con éxito, el sistema
deberá garantizar el establecimiento permanente de sus modificaciones en la base de datos , aun
si el sistema se cayera en el instante siguiente. Es muy posible que el sistema se caiga después de
haberse realizado la instrucción COMMIT pero antes de grabarse físicamente las modificaciones
en la base de datos. Incluso si esto sucediera el procedimiento de reinicio del sistema instalara de
todas maneras esas modificaciones en la base de datos; podrá descubrir los valores que se deben
grabar examinando las entradas pertinentes de la bitácora. Así el procedimiento de reinicio
recuperara todas las transacciones que se completaron con éxito pero cuyas modificaciones no
lograron grabarse físicamente antes de la caída.
168
Recuperación del sistema y de los medios de almacenamiento
El sistema debe ser capaz de recuperarse también de las fallas "globales" como podría ser la
interrupción del suministro eléctrico en la CPU. Una falla local afecta solo la transacción en la cual
se presento la falla, en cambio una falla global afecta varias de las transacciones que se estaban
efectuando en el momento de la falla, por lo cual tendrá implicaciones importantes para todo el
sistema. Tales fallas se dividen en dos categorías amplias:
 Fallas del sistema: se interrumpe el suministro eléctrico el cual afecta a todas las transacciones
que se están realizando pero no dañan físicamente la base de datos.
 Fallas de los medios de almacenamiento: un daño en el disco, las cuales si causan daños a la
base de datos, o a una porción de ella, y afectan al menos a las transacciones que están
utilizando esa porción.
Analizaremos las fallas del sistema con mas detalle.
En una falla del sistema el punto critico es que se pierde el contenido de la memoria principal. Por
tanto ya no se conocerá el estado preciso de la transacción que se estuviera realizando en el
momento de la falla; esa transacción jamás se podrá completar con éxito, por lo cual será preciso
anularla (retroceder) cuando se reinicie el sistema. Además podría ser necesario en el momento de
reiniciar, volver a realizar ciertas transacciones cuya ejecución sí terminó con éxito antes de la
caída pero cuyas modificaciones no lograron ser transferidas desde el buffer de la base de datos a
la base de datos física.
Veamos ahora como sabe el sistema cuales transacciones debe anular y cuales rehacer. Cada
cierto intervalo el sistema establece un "punto de revisión" de manera automática, esto implica:
 Grabar el contenido de los búferes de datos a la base de datos física.
 Grabar físicamente un registro de punto de revisión especial en la bitácora física; este registro
incluye todas las transacciones que se estaban realizando en el momento de establecerse el
punto de revisión
Veamos un ejemplo tomado del libro de C.J. Date Introducción a las Bases de Datos
tv tf
Tiempo tv
T
R T1
A
N
S T2
A
C T3
C
I
O T4
N
E
S T5
Punto de verificación Falla del sistema

(tiempo tv) (tiempo tf)
 Se presento una falla del sistema en el momento tf.

 EL punto de verificación mas reciente antes de tf se tomo en el momento tv.
 Las transacciones del tipo T1 se completaron antes del tiempo tv.
 Las transacciones del tipo T2 se iniciaron antes del tiempo tv y se completaron después del
tiempo tv y antes del tiempo tf.
169
 Las transacciones del tipo T3 también se iniciaron antes del tiempo tv pero no se completaron
antes del tiempo tf.
 Las transacciones del tipo T4 se iniciaron después del tiempo tv y se completaron antes del
tiempo tf.
 Por ultimo, las transacciones del tipo T5 también se iniciaron después del tiempo tv pero no se
completaron antes del tiempo tf.
Al reiniciarse el sistema se deberán anular las transacciones de los tipos T3 y T5 y se deberán

realizar de nuevo las transacciones de los tipos T2 y T4. Las transacciones del tipo T1 no entran en
absoluto en el proceso de reinicio, porque sus modificaciones se grabaron físicamente en la base
de datos en el momento tv como parte del proceso del punto de revisión.
2.2 Compromiso en dos fases
El compromiso en dos fases es en el contexto de los sistemas de bases de datos distribuidas es

decir, cuando una transacción dada puede interactuar con varios administradores de recursos
independientes, cada uno de los cuales administra su propio conjunto de recursos recuperables.
Supongamos una transacción perfectamente legal que actualiza tanto una base de datos IMS
como una base de datos DB2; si la transacción se completa con éxito, todas sus modificaciones en
IMS como en DB2 deberán comprometerse y si de lo contrario, la transacción fracasa, todas sus
modificaciones se deberán anular. No tiene ningún sentido que la transacción emita una instrucción
COMMIT a IMS y una instrucción ROLLBACK a DB2, además existe la posibilidad de una caída del
sistema entre las dos. Así pues, y respetando su definición de "atómica", la transacción emite una
sola instrucción COMMIT o ROLLBACK para todo el sistema. Esa instrucción es manejada por un
componente del sistema llamado coordinador, cuya tarea es garantizar que - de acuerdo a nuestro
ejemplo - los dos administradores de recursos de IMS y DB2 comprometan o anulen al unísono las
modificaciones de las cuales son responsables haciendo valer esa garantía aun si se produjera
una falla en el sistema durante el proceso. Y es el protocolo de compromiso en dos fases el que le
permite ofrecer esa garantía.
Supongamos por sencillez que la transacción termina con éxito, de modo que la operación para
todo el sistema es COMMIT. El coordinador recibe la solicitud de comprometer y realiza el
siguiente proceso en dos fases:
Fase 1: Ordena a todos los administradores de recursos que se preparen para la finalización de la
transacción de la siguiente forma: cada uno de los administradores de recursos debe forzar la
grabación en la bitácora física, de todas las entradas de la bitácora correspondientes a los recursos
locales empleados por la transacción, de esta forma suceda lo que suceda el manejador de
recursos tendrá un registro permanente de lo que hizo con respecto a la transacción y podrá
comprometer o anular las modificaciones según sea necesario. Si la grabación forzada tiene éxito
el administrador de recursos contestara al coordinador "todo bien" o en caso contrario "no esta
bien".
Fase 2: Cuando el coordinador halla recibido la respuesta de todos los manejadores de recursos,
forzara la grabación de una entrada en su propia bitácora física, para registrar su decisión en
cuanto a la transacción. Si todas las respuestas fueron "todo bien", la decisión será comprometer, y
si cualquiera de las respuestas fue "no esta bien", la decisión será retroceder. En cualquiera de los
casos el coordinador informara de su decisión a todos los administradores de recursos y cada
administrador de recursos deberá comprometer o anular la transacción localmente, según se haya
ordenado. Adviértase que cada administrador de recursos debe hacer lo que ordena el coordinador
en la fase 2; ese es el protocolo.
Si el sistema falla en algún punto durante el proceso general, el procedimiento de reinicio buscara
el registro de decisión en la bitácora del coordinador. Si lo encuentra, el proceso de compromiso en
dos fases podrá continuar donde fue interrumpido, sino supondrá que la decisión fue "retroceder",
con lo cual el proceso se podrá completar en forma apropiada.
170
2.3 Tres problemas de concurrencia:
La mayor parte de los DBMS son sistemas para múltiples usuarios; es decir son sistemas en los
cuales se permite a cualquier cantidad de transacciones tener acceso a la misma base de datos al
mismo tiempo. En sistemas como estos, se necesita algún tipo de mecanismo de control de
concurrencia a fin de asegurar que ninguna transacción concurrente interfiera con las operaciones
de los demás. Sin un mecanismo semejante pueden surgir muchos problemas.
En esencia son tres los errores que pueden presentarse y son los siguientes:
1. El problema de la modificación perdida

2. El problema de la dependencia no comprometida
3. El problema del análisis inconsistente
El problema de la modificación perdida
Transacción A Tiempo Transacción B
TRAER R t1
---- t2 TRAER R
ACTUALIZAR R t3
---- t4 ACTUALIZAR R
La transacción A lee algún registro R en el tiempo t1; la transacción B lee ese mismo registro en el
momento t2; la transacción A actualiza el registro (con base en los valores observados en el tiempo
t1) en el momento t3; y la transacción B actualiza el registro (con base en los valores observados
en el tiempo t2, los cuales son también los observados en el tiempo t1) en el momento t4. La
modificación de la transacción A se pierde en el momento t4, porque la transacción B graba su
registro modificado encima del registro modificado para A sin verlo siquiera.
El problema de la dependencia no comprometida
El problema de la dependencia no comprometida se presenta cuando se permite a una transacción

leer o modificar un registro que ha sido puesto al día por otra transacción y esta ultima todavía no
lo ha comprometido; pues si todavía no esta comprometido, existe la posibilidad de que nunca se
comprometa y en cambio se anule.
En el ejemplo que vemos a continuación la transacción A observa un valor que no esta

comprometido, al momento t3 la actualización de la transacción B se retrocede por lo que la
información que observo la transacción A fue errónea.
TRAER R t2 ----
---- t3 RETROCEDER
171
Este ejemplo es aun peor, la transacción A no solo se vuelve dependiente de una modificación no
comprometida en el momento t2 sino que pierde la actualización en el momento t3, ya que el
retroceso en ese instante hace que el registro vuelva a los valores que tenia en el tiempo t1.
ACTUALIZAR R t2 ----
---- t3 RETROCEDER
El problema del análisis inconsistente
Las transacción A y B operan sobre registros de cuentas (CTA): la transacción A esta sumando los
saldos de las cuentas y la transacción B esta transfiriendo una cantidad de 10 de la cuenta 3 a la
cuenta 1. EL resultado producido por A (110) es obviamente incorrecto. Este caso difiere al anterior
en que A no depende de una modificación no comprometida, ya que B compromete todas sus
modificaciones antes que A vea la CTA 3.
CTA 1: 40 CTA 2: 50 CTA 3: 30
TRAER CTA 1 (40) t1 ----

Suma=40
TRAER CTA 2 (50) t2 ----

Suma=90
---- t3 TRAER CTA 3 (30)
---- t4 ACTUALIZAR CTA 3:

30 20
t5 TRAER CTA 1 (40)
t6 ACTUALIZAR CTA 1:
40 50
t7 COMPROMETER
172
TRAER CTA 3 (20) t8
Suma= 110, no 120
La transacción A realiza un análisis inconsistente.
Como mencionamos al principio de esta sección estos problemas pueden resolverse mediante un
mecanismo de control de concurrencia. El mecanismo que veremos a continuación se llama
bloqueo.
El bloque produce el efecto de "bloquear el acceso de otras transacciones" al objeto, y en particular

evitar que lo modifiquen. De esta forma la primera transacción puede realizar su procesamiento
con toda confianza, pues el objeto en cuestión permanecerá en un estado estable mientras esa
transacción lo desee.
Suponemos primero la existencia de dos tipos de bloqueo: bloqueos exclusivos (bloqueo X) y
bloqueos compartidos (bloqueo S). Veamos la definición:
Si la transacción A tiene un bloqueo exclusivo (X) sobre un registro R, una solicitud por parte de
la transacción B de cualquier tipo de bloqueo sobre R hará que B entre en un estado de espera. B
esperara hasta que se libere el bloqueo de A.
Si una transacción A tiene un bloqueo compartido (S) sobre el registro R:
(a) una solicitud por parte de la transacción B de bloqueo X sobre R hará que B entre en
un estado de espera, B esperara hasta que se libere el bloqueo de A.
(b) Una solicitud por parte de la transacción B de un bloque S sobre R será concedida, es
decir, B tendrá también ahora un bloqueo S sobre R.
Las solicitudes de bloqueo sobre registros por parte de las transacciones son implícitas, en
condiciones normales cuando una transacción lee con éxito un registro, adquiere en forma
automática un bloqueo S sobre el. Cuando una transacción pone al día con éxito un registro,
adquiere en forma automática un bloque X sobre el.
Veremos ahora como el bloque resuelve los tres problemas descritos anteriormente.
El problema de modificación perdida:
TRAER R t1
(adquirir bloque S sobre R)
---- t2 TRAER R
(adquirir bloque S sobre R)
ACTUALIZAR R t3
(solicitar bloque X sobre R)
esperar t4 ACTUALIZAR R
esperar (solicitar bloque X sobre R)
esperar esperar
esperar esperar
esperar esperar
No se pierde ninguna modificación, pero hay un bloque mutuo en el tiempo t4.
El problema de la dependencia no comprometida

173
(adquirir bloque X sobre R)
TRAER R t2 ----
(solicitar bloqueo S sobre R)
esperar t3 punto de sincronización
esperar (liberar el bloqueo X sobre R)
continuar: TRAER R t4
(adquirir bloqueo S sobre R)
----
----
Se evita que la transacción A vea una modificación no comprometida en el tiempo t2
(adquirir bloque X sobre R)
ACTUALIZAR R t2 ----
(solicitar bloqueo X sobre R)
esperar t3 punto de sincronización
esperar (liberar el bloqueo X sobre R)
continuar: ACTUALIZAR R t4
(adquirir bloqueo X sobre R)
----
----
Se evita que la transacción A actualice una modificación no comprometida en el tiempo t2.
El problema del análisis inconsistente
CTA 1: 40 CTA 2: 50 CTA 3: 30
TRAER CTA 1 (40) t1 ----

(adquirir bloqueo S sobre CTA 1)
Suma=40
TRAER CTA 2 (50) t2 ----

Suma=90
---- t3 TRAER CTA 3 (30)

---- t4 ACTUALIZAR CTA 3:

(adquirir bloqueo X sobre CTA 3)
30 20
t5 TRAER CTA 1 (40)

174
t6 ACTUALIZAR CTA 1:
(solicita bloqueo X sobre CTA 1)
esperar
esperar
esperar
esperar
TRAER CTA 3 (20) t7
(solicita bloque S sobre CTA 3)
esperar
esperar
Se evita el análisis inconsistente pero se presenta un bloqueo mutuo en el tiempo t7.
Bloqueo Mutuo:
Hemos visto como el bloqueo puede servir para resolver los tres problemas básicos de
concurrencia. Pero henos visto también que por desgracia el bloqueo puede causar sus propios
problemas como el bloqueo mutuo.
EL bloqueo mutuo es una situación en la cual dos o mas transacciones están en un estado de
espera simultaneo, y cada una espera la liberación de un bloqueo por parte de la otra para poder
continuar, ya hemos visto solucionando los problemas anteriores un bloqueo mutuo entre dos
transacciones, pero también son posibles bloqueos mutuos en los cuales estén implicadas tres o
cuatro transacciones.
Si se presenta un bloqueo mutuo, desearemos que el sistema lo detecte y lo rompa. La detección
del bloqueo mutuo implica la detección de un ciclo en la "gráfica de espera" la gráfica donde se
indica quien esta esperando a quien. Para romper el bloqueo es necesario elegir una de las
transacciones que se encuentran paralizadas y cancelarla, con lo cual se liberan sus bloqueos y se
permite la continuación de alguna otra transacción.
Elabore un ejemplo para cada problema de concurrencia y describa como solucionarlo

utilizando el mecanismo de bloqueo.
3. Seguridad
Seguridad se refiere a la protección de los datos contra una revelación, alteración o destrucción no
autorizada. La seguridad implica asegurar que los usuarios están autorizados para llevar a cabo lo
que tratan de hacer. Pero la seguridad merece las consideraciones generales que detallaremos a
continuación:
El problema de seguridad tiene muchos aspectos, entre ellos los siguientes:
 Aspectos legales, sociales y éticos: por ejemplo, ¿tiene la persona que solicita el crédito de un
cliente, digamos, derecho legal a obtener la información solicitada?
 Controles físicos: por ejemplo, ¿deberá estar cerrado o resguardado de alguna otra manera el
cuarto de computadores o terminales?
 Cuestiones de política interna: por ejemplo, ¿cómo decide la empresa propietaria del sistema
quienes pueden tener acceso a qué?
 Problemas de operación: por ejemplo, si se utiliza un sistema de contraseñas ¿cómo se
mantienen en secreto las contraseñas? ¿Con qué frecuencia se cambian?
 Controles del equipo: por ejemplo, ¿posee la CPU características de seguridad tales como
claves para la protección de las áreas de almacenamiento o un modo de operación
privilegiado?
 Seguridad del sistema operativo: por ejemplo, ¿borra el sistema operativo subyacente el
contenido de las áreas de almacenamiento y los archivos de datos cuando ya no se necesitan?
175
 Materias de relevancia especifica para el sistema mismo de base de datos: por ejemplo, ¿tiene
el sistema de base de datos un concepto de propiedad sobre los datos?
Por razones obvias, nos limitaremos en general a considerar los aspectos incluidos solo en esta
ultima categoría.
En vista que una aplicación de base de datos ofrece un servicio centralizado a un grupo
potencialmente grande de usuarios, el DBMS debe proporcionar un mecanismo para proteger la
información contra abusos. Ciertos datos son confidenciales y deben ser vistos solo por personas o
programas privilegiados. Otra información puede existir de modo mas general con un fundamento
de solo lectura pero debe ser protegida contra actualizaciones.
La unidad de información para propósitos de seguridad puede ser desde una base de datos o
conjunto de tablas completos hasta un valor especifico en una posición especifica y columna
dentro de una tabla especifica. Un usuario determinado tendrá por lo regular diferentes derechos
de acceso o autorizaciones sobre diferentes objetos de información; por ejemplo, veamos la
siguiente tabla:
SELECT El objeto debe ser una tabla. El usuario puede seleccionar todas las
columnas de la tabla, incluyendo cualquier columna que se agregue mas
tarde.
INSERT El objeto debe ser una tabla. El usuario puede insertar tuplas en la tabla
y especificar un valor para cualquier columna, incluyendo cualquier
columna que pudiera agregarse mas tarde.
INSERT (c1, c2, ...) El objeto debe ser una tabla. El usuario puede insertar tuplas en la tabla,
especificando valores solo para las columnas escogidas c1, c2,... Otras
columnas toman sus valores por omisión como se especifica en el
esquema.
DELETE El objeto debe ser una tabla. El usuario puede borrar tuplas de la tabla
UPDATE El objeto debe ser una tabla. El usuario puede actualizar tuplas en la
tabla y especificar un valor nuevo para cualquier columna, incluyendo
cualquier columna que pudiera agregarse mas tarde.
UPDATE(c1, c2,...) El objeto debe ser una tabla. El usuario puede actualizar tuplas en la
tabla, especificando valores nuevos solo para las columnas escogidas
c1, c2...
Desde luego , diferentes usuarios pueden tener diferentes derechos sobre el mismo objeto. El
usuario A podría tener autorización para usar solo SELECT con alguna tabla dada, mientras que
otro usuario B podría tener al mismo tiempo autorización para usar tanto SELECT como UPDATE
sobre esa misma tabla.
En el caso de SQL, el sistema cuenta con dos características mas o menos independientes
implicadas en el mantenimiento de la seguridad:
1- El mecanismo de vistas, el cual como se menciono anteriormente puede servir para ocultar
datos confidenciales a usuarios no autorizados.
2- El subsistema de autorización, mediante el cual usuarios con derechos específicos pueden
conceder de manera selectiva y dinámica esos derechos a otros usuarios, y después revocar
esos derechos si lo desean.
Cabe aclarar que las decisiones sobre cuales derechos deben concederse a cuales usuarios son
decisiones de política, no técnicas. El DBMS obliga el cumplimiento de esas decisiones una vez
tomadas. Para que el DBMS pueda llevar a cabo esas funciones en forma apropiada se deben
cumplir los siguientes pasos.
1- Una vez que las decisiones están tomadas se deben dar a conocer al sistema con las
proposiciones que proporciona SQL, GRANT -conceder- y REVOKE -revocar -, y el sistema
debe ser capaz de recordarlas grabándolas en el catalogo del sistema como restricciones de
autorización.
176
2- Debe existir alguna forma de verificar una solicitud de acceso dada contra las restricciones de
autorización aplicables. En el caso especifico de DB2 esa verificación es realizada por el
componente ligador en el momento de compilar la solicitud.
3- Para poder decidir cuales restricciones son aplicables a una solicitud dada, el sistema debe ser
capaz de reconocer el origen de dicha solicitud, o sea el usuario especifico del cual proviene
esa solicitud. Por esta razón cuando los usuarios acceden al sistema se les pide proporcionar
su identificador y su contraseña para tener la certeza que son quienes dicen ser.
Piense cuales serian los riesgos en que incurriría un sistema de base de datos de no definir
correctamente los esquemas de seguridad.
3.1 Seguridad en SQL
Vistas y seguridad
Veamos algunos ejemplos de empleo de vistas con propósitos de seguridad:
1- Para un usuario al cual se permite tener acceso a registros completos de proveedores pero
solo de los proveedores situados en París:
2- Para un usuario al cual se permite tener acceso a todos los registros de proveedores pero no a
las calificaciones de los proveedores, o sea a los valores de situación.
Elabore usted mismo mas ejemplos de vistas sobre alguna de las bases de datos presentadas a lo
largo del desarrollo de la guía de estudio.
GRANT (conceder) y REVOKE (revocar)
El mecanismo de vistas hace posible ocultar información confidencial a usuarios no autorizados

dividiendo conceptualmente la base de datos en fragmentos de distintas maneras. Sin embargo, no
permite especificar las operaciones que los usuarios autorizados pueden ejecutar con esos
fragmentos. Para están las proposiciones GRANT (conceder) y REVOKE (revocar) de SQL.
En primer lugar, para poseer realizar cualquier operación en SQL, el usuario debe tener una
autorización apropiada para esa operación; en caso contrario, la operación se rechazara con un
mensaje de error o código de excepción adecuado. Veamos un ejemplo:
SELECT *
FROM S;
El usuario debe tener autorización de selección sobre la tabla S.
Los diferentes sistemas reconocen una amplia gama de autorizaciones diferentes aunque algunas
son especificas de cada sistema. En esta sección limitaremos nuestra atención solo a las
autorizaciones que podrían considerarse como representativas manejadas por los sistemas de
bases de datos en general. La mayor parte de esas autorizaciones tienen que ver con el acceso a
los datos - tablas base y vistas, en el caso de un sistema relacional-
177
Explicaremos ahora como se inicia el subsistema de autorización, empleando el procedimiento de
DB2 como ejemplo de dicho proceso de iniciación; luego describiremos las autorizaciones de
acceso a los datos.
Cuando se instala DB2 por primera vez, parte del procedimiento de instalación implica la
designación de un usuario con privilegios especiales como administrador del sistema para ese
sistema instalado. Ese usuario privilegiado recibe de manera automática una autorización especial
llamada SYSADM. La autorización SYSADM confiere a quien la posee, el derecho de realizar
todas y cada una de las operaciones manejadas por el sistema. Por lo tanto en principio, existe un
usuario que puede hacerlo todo - en particular, puede conceder derechos a otros usuarios- y nadie
mas puede hacer nada.
Supongamos ahora que el administrador del sistema concede a algún otro usuario U el derecho de
crear algún objeto - una vista o una tabla base - y supongamos que U lo crea. En ese momento el
usuario U obtiene de manera automática todo tipo de derechos sobre ese objeto, incluyendo en
particular el derecho de conceder esos derechos a otro usuario. Por supuesto "todo tipo de
derechos" no incluye aquí derechos absurdos; por ejemplo si el usuario U tiene solo autorización
de selección sobre la tabla base T, y si U crea alguna vista V con base en T, ciertamente U no
recibirá autorización de actualización sobre V.
Veamos algunos ejemplos de concesión de derechos, como hemos enunciado antes esto se
realiza utilizando la proposición GRANT (conceder).
GRANT SELECT ON TABLE S TO CARLOS;

GRANT SELECT, UPDATE (SITUACION, CIUDAD) ON TABLE S
TO JULIA, JUAN, JAIME;
GRANT ALL ON TABLE S, P, SP TO FERNANDO, MARIA;
GRANT SELECT ON TABLA P TO PUBLIC;
GRANT INDEX ON TABLE S TO FELIPE;
PUBLIC es una palabra clave especial que representa a "todos los usuarios del sistema".
Si el usuario U1 concede cierta autorización a otro usuario U2, el usuario U1 puede revocar
después esa autorización. Esto se hace con la proposición REVOKE (revocar).
REVOKE SELECT ON TABLE S FROM CARLOS;

REVOKE UPDATE ON TABLE S FROM JAIME;
REVOKE INSERT, DELETE ON TABLE SP FROM ELENA, JUAN;
REVOKE ALL ON TABLE S, P, SP FROM SAMUEL;
En DB2, la revocación de una autorización dada a un usuario hace que todos los planes de
aplicación ligados por ese usuario y dependientes de esa autorización se marquen como "no
validos", lo cual provocara un religamiento automático en la siguiente invocación de uno de esos
planes.
Las autorizaciones también se almacenan en el catalogo del sistema por lo que pueden
consultarse ante alguna intención de manipular alguna tabla.
Mencionaremos un tema mas en esta sección con respecto a la opción GRANT . Si el usuario U1
tiene el derecho de conceder cierta autorización A a otro usuario U2, tendrá también - por
definición- el derecho de conceder esa autorización A al usuario U2 "con la opción GRANT"
especificando WITH GRANT OPTION en la proposición GRANT.
Transferir la opción GRANT de U1 a U2 de esta manera implica que ahora U2 tiene a su vez
derecho de conceder esa autorización A a un tercer usuario U3; y desde luego U2 tiene también el
derecho de pasarle a U3 la opción de GRANT, etc., etc.
Usuario U1:
GRANT SELECT ON TABLE S TO U2 WITH GRANT OPTION;
Usuario U2:
178
Usuario U3:
Y así sucesivamente. Si el usuario U1 emite ahora:
REVOKE SELECT ON TABLE S FROM U2;
La revocación se propagara; se revocaran de manera automática la concesión de U2 a U3 y la de

U3 a U4.
4. Integridad
El término "integridad" se refiere a la corrección de la información contenida en la base de datos.

En este sentido muchos de los sistemas actuales son por lo regular mas bien deficientes en cuanto
a la integridad; casi toda la verificación de la integridad se realiza hoy día mediante código de
procedimientos escrito por los usuarios. Indudablemente, seria preferible poder especificar
restricciones de integridad en una forma mas declarativa y hacer así que el sistema se encargara
de la verificación; así pues un sistema que manejara tales especificaciones podría liberar a los
programadores de aplicaciones de una carga considerable, y al mismo tiempo les permitiría
volverse bastante mas productivos.
Una restricción de integridad puede considerarse como una condición, que debe ser todos os
estados correctos de la base de datos. Veamos un ejemplo sencillo:
FORALL SX (SX.SITUACION > 0)
Esto significa, para todos los proveedores SX, la situación de SX debe ser positiva. Si el usuario
intenta ejecutar una operación cuyo resultado seria una violación de la restricción, el sistema
deberá o bien rechazar la operación, o quizá efectuar alguna acción de compensación en alguna
otra parte de la base de datos para garantizar que el resultado siga siendo un estado correcto. Un
ejemplo de este ultimo caso lo ofrece la regla de eliminación de claves ajenas CASCADES - se
propaga -.
Así pues, cualquier lenguaje para especificar restricciones de integridad deberá incluir no solo la
capacidad de especificar condiciones arbitrarias, sino también recursos para especificar este tipo
de acciones de compensación cuando resulte apropiado.
4.1 Un lenguaje de integridad hipotético
El lenguaje hipotético que desarrollaremos aquí esta tomado de C.J. Date "A contribution to the
study of database integrity". En C. J. Date, Relational Database Writings 1985-1989.
Este articulo intenta imponer cierta estructura sobre el problema de integridad de las bases de
datos proponiendo un esquema de clasificación para las restricciones de integridad, empleando
ese esquema para aclarar los principales conceptos básicos de la integridad de los datos.
Se compone de dos proposiciones, CREATE UNTEGRITY RULE - crear regla de integridad - y

DROP INTEGRITY RULE - desechar regla de integridad -.
Como siempre utilizaremos SX, ..., PX, ..., SPX, ..., para representar variables de tuplas cuyos
recorridos son S, P, SP respectivamente y utilizaremos S, P, SP con variables de tuplas por
omisión cuando esto no provoque ambigüedad.
Ejemplo 1: Los valores de situación deben ser positivos:
CREATE INTEGRITY RULE R1

ON INSERT S.SITUACION,
UPDATE S.SITUACION:
CHECK FORALL S (S.SITUACION > 0)
ELSE REJECT;
179
La proposición CREATE INTEGRITY RULE debe especificar:
 El nombre de la regla "R1 en el ejemplo".
 Una o mas ocasiones de verificación "ON INSERT S.SITUACION, UPDATE S.SITUACION" en
el ejemplo, que significa: al insertar S.SITUACION, modificar S.SITUACION; para indicar al
sistema cuando debe realizar la verificación especificada en la cláusula CHECK que significa:
verificar.
 Una restricción que debe ser satisfecha por todos los estados legales de la base de datos
"FORALL S (S.SITUACION > 0)" que significa: para toda S (S.SITUACION > 0) en el ejemplo.
 Una respuesta de violación, para indicar qué debe hacerse si la verificación falla "REJECT"
que significa rechazar en el ejemplo, quiere decir que la proposición INSERT o UPDATE
culpable debe rechazarse con un código de retorno apropiado.
En el ejemplo que acabamos de presentar analizamos a propósito en forma detallada para ilustrar
el punto de que, al menos en lo abstracto, las reglas de integridad deben incluir los cuatro
componentes: nombre, ocasión de verificación, restricción, respuesta de violación. No obstante,
existen algunas simplificaciones que podemos y vamos aplicar en la mayor parte de los ejemplos
subsecuentes:
 Las ocasiones de verificación casi siempre serán obvias, por lo tanto supondremos que el
DBMS es capaz de determinar por si mismo la ocasión u ocasiones de verificación sino se
especifica de manera explícita.
 La restricción de la cláusula CHECK casi siempre comenzara con un cuantificador universal,
por lo tanto omitiremos ese cuantificador en nuestra sintaxis concreta y nos limitaremos a
suponer que cualquier variable no cuantificada se cuantificara en forma automática con un
FORALL (para toda) apropiado.
 También supondremos que si se omite la cláusula ELSE (si no), quedara implícita la respuesta
de violación "rechazar la operación de actualización, con un código de retorno adecuado".
Si aplicamos todas estas ejemplificaciones, podemos reducir el ejemplo anterior a:

CHECK S.SITUACION > 0;
Cuando se ejecuta una proposición CREATE INTEGRITY RULE, el sistema comprueba primero si
el estado actual de la base de datos satisface la restricción especificada. Si no lo hace, se rechaza
la nueva regla; en caso contrario se acepta, o sea se guarda en el catalogo del sistema y se
considera en adelante. El cumplimiento en el presente ejemplo requiere la supervisión, por parte
del DBMS, de todas las operaciones que insertarían un valor en la columna S.SITUACION, o que
modificarían un valor de esa columna.
Veamos como se desecha una regla de integridad:
DROP INTEGRITY RULE R1;
Ejemplo 2: En este ejemplo mostraremos como la complejidad de las restricciones pude ser
arbitraria: Supongamos que la relación SP incluye un conjunto adicional de atributos DIA, MES,
AÑO cada uno CHAR(2), para representar la fecha de envío en cuestión, supondremos también
que el sistema no maneja en forma directa un tipo de datos de fecha.

CHECK IS_INTEGER(SP.AÑO)
AND IS_INTEGER(SP.MES)
AND IS_INTEGER(SP.DIA)
AND NUM (SP.AÑO) BETWEEN 0 AND 99
AND NUM (SP.MES) BETWEEN 1 AND 12
AND NUM (SP.DIA) > 0
AND IF NUM (SP.MES) IN (1,3,5,7,8,10,12)
THEN NUM (SP.DIA) < 32
180
AND IF NUM (SP.MES) IN (4,6,9,11)
AND IF NUM (SP.MES)= 2
AND IF NUM (SP.MES) = 2 AND NUM (SP.AÑO) <> 0
AND MOD (NUM (SP.AÑO), 4)=0
THEN NUM (SP.DIA) < 29;
Hemos supuesto además la existencia de dos funciones integradas: IS_INTEGER que significa es
entero, la cual prueba una cadena de caracteres para ver si representa un valor entero decimal
legal y NUM, la cual convierte una cadena de caracteres que represente un valor decimal, en una
forma numérica interna.
Ejemplo 3: Los valores de situación nunca deben disminuir:

BEFORE UPDATE OF SITUATION FROM NUEVA_SITUACION:
CHECK NUEVA_SITUACION > S.SITUACION;
La regla R3 no se aplica a estados de la base de datos, sino mas bien a la transición entre los dos
estados. Adviértase que por este motivo la regla requiere que se especifique una ocasión de
verificación explícita, la cláusula BEFORE que significa antes a fin de indicar al DBMS cuando
debe efectuarse la verificación. En este ejemplo NUEVA_SITUACION es un parámetro formal.
Ejemplo 4: El valor promedio de situación de los proveedores debe ser mayor que 25:

CHECK IF EXISTS S () THEN AVG (S.SITUACION) > 25;
La regla R4 implica el conjunto total de registros de la tabla S. Se requiere la condición "IF EXISTS
S ()" que significa si existe S, porque si la tabla S esta vacía el promedio no esta bien definido: la
operación resulta nulo y como hemos visto anteriormente no es un valor valido para comparar con
25.
Ejemplo 5: Todos los proveedores de Londres deben suministrar la parte P2:

AT COMMIT :
CHECK IF S.CIUDAD = 'Londres' THEN
EXISTS SP (SP.S# = S.S# AND SP.P# = 'P2')
ELSE ROLLBACK;
En este ejemplo es necesario especificar de manera explícita tanto la ocasión de verificación "AT
COMMIT" que significa al comprometer, como la respuesta de violación "ROLLBACK" que significa
retroceder. La restricción debe verificarse en el momento del compromiso porque sino fuera así
nunca seria posible insertar un registro S nuevo de un proveedor de Londres, pues en el momento
de la inserción jamás podría existir un registro SP según el cual el nuevo proveedor ya suministrara
la parte P2, suponiendo desde luego que se acata la restricción referencial entre las tablas SP y S.
Sin embargo, la restricción implica que cualquier transacción para insertar un nuevo proveedor de
Londres debe proceder enseguida a crear al menos un envío que relacione a ese proveedor con la
parte P2, pues de lo contrario la base de datos no satisfacerá la restricción en el momento del
compromiso y la transacción se cancelara en virtud de la respuesta de violación - cláusula ELSE -.
De este ejemplo puede concluirse que, aunque una transacción transforme un estado correcto de
la base de datos en otro estado correcto, puede generar de manera temporal un estado incorrecto
181
mientras lo hace. Por supuesto que ninguna otra transacción percibirá en realidad ese estado
incorrecto si se acatan los protocolos de bloqueo descriptos anteriormente. Note que una
transacción puede considerarse no solo como una unidad de trabajo, y de recuperación, y
de concurrencia, sino también como una unidad de integridad.
182
1- La tabla PERSONAL se define de la siguiente forma:
CREATE TABLE PERSONAL

( IDENTUSUARIO CHAR(8),
SEXO CHAR(1),
DEPENDIENTES NUMBER(2),
OCUPACION CHAR(20),
SALARIO NUMBER (8,2),
IMPUESTO NUMBER (8,2),
AUDITORIAS NUMBER(2),
PRIMARY KEY ( IDENTUSUARIO ));
Escribir proposiciones SQL para conceder lo siguiente:
(a) Al usuario Fraga, autorización de selección sobre la tabla.

(b) Al usuario Suárez, autorización de inserción y eliminación sobre toda la tabla.
(c) A cada usuario, autorización de selección sobre su propio registro.
(d) Al usuario Nava, autorización de selección sobre toda la tabla y autoridad de actualización
sobre los campos SALARIO e IMPUESTO (solamente).
(e) Al usuario Torres, autorización de selección sobre los campos IDENTUSUARIO, SALARIO
e IMPUESTO (únicamente).
(f) Al usuario Vargas, autorización de selección igual a la de Torres y autorización de
actualización sobre los campos SALARIO e IMPUESTO (solamente).
(g) Al usuario Jimenez, autorización de selección igual a la de Torres y autoridad de
actualización sobre los campos IMPUESTO y AUDITORIA.
(h) Al usuario Reyes, autorización de selección sobre los salarios máximos y mínimos por
clase de ocupación, pero ninguna otra autorización.
2- Con el lenguaje de integridad hipotético definido en la sección de Integridad, escribir

proposiciones CREATE INTEGRITY RULE para las siguientes restricciones sobre la base de
datos de proveedores, partes y proyectos.
(a) Los únicos colores validos para las partes son rojo, azul y verde.
(b) Todas las partes rojas pesan menos de 50 libras.
(c) No puede haber dos proyectos en la misma ciudad.
(d) No puede haber mas de un proveedor situado en Atenas en un momento dado.
(e) Todo proyecto debe estar situado en una ciudad en la cual exista por lo menos un
proveedor.
183

Diseno_de_base_de_datos-Informatica_3

Cargado por

Copyright:

Formatos disponibles

Diseno_de_base_de_datos-Informatica_3

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diseno_de_base_de_datos-Informatica_3

Cargado por

Copyright:

Formatos disponibles

Guía de Informática III

Presentación del Autor:

Unidad I: Panorama general de los sistemas de bases de datos

1. Sistemas de bases de datos

Unidad II: Estructuras de almacenamiento en disco

1. Definición de estructuras de almacenamiento

Unidad III: Bases de Datos Relacionales

1. Ilustración informal de una base de datos relacional

Unidad IV: Modelado de datos utilizando el enfoque Entidad – Relación

1. La importancia del modelo Entidad – Relación

Unidad V: Lenguaje de Consulta Estructurada

Unidad VI: Diseño de bases de datos

1. La importancia de un buen diseño de bases de datos

Unidad VII: El ambiente de las bases de datos (DATE)

Introducción General Orientadora: (Resumen de la Materia)

 una colección de datos relacionados entre sí

 En la unidad I presentamos un panorama general de las bases de datos y se sus diferentes

 En la unidad II vemos las estructuras de almacenamiento, su importancia, y como

 En la unidad V analizamos el álgebra relacional necesario para la creación de consultas;

¿Qué bibliografía obligatoria utilizaremos?

 JAMES L: JHONSON Bases de datos. Modelos, lenguajes, diseños. Editorial OXFORD

 RICHARD BARKER. El modelo entidad-relación CASE*METHOD. Editorial Addison-Wessley

Al finalizar la materia esperamos que haya logrado los siguientes objetivos:

Ante cualquier duda o dificultad no deje de consultar al tutor.

Para facilitar su estudio se le proporciona la definición de ciertos términos utilizados en el desarrollo

Esquema Conceptual de la materia:

La materia se divide es dos partes principales:

Sugerencias para estudiar la materia:

 Comenzar leyendo la guía de estudio por unidad.

 JAMES L: JHONSON Bases de datos. Modelos, lenguajes, diseños. Editorial OXFORD

 RICHARD BARKER. El modelo entidad-relación CASE*METHOD. Editorial Addison-Wessley

Criterios de evaluación para el examen final.

 Claridad y rigurosidad en los conceptos que fundamentan la teoría de los Sistemas de

Sugerencias para el examen final

Cuanto tiempo lleva estudiar la asignatura:

Unidades Distribución de tiempo Tiempo

Orientación del Aprendizaje:

Desde esta perspectiva los contenidos que trabajaremos en la unidad son:

1. Sistemas de bases de datos

Usuarios Programadores de Usuarios Administrador de

Interfaces de Lenguajes de Interfaces de Planificación de

Estructura del sistema

Fuente: Korth H, Silbertschatz A. Fundamentos de base de datos. Segunda Edición Editorial Mc

 Identificar a las bases de datos relacionales como una alternativa de almacenamiento

1. Sistemas de base de datos:

Un sistema de base de datos se apoya en un administrador de sistemas de base de datos y presta

1.1 Ejemplo de sistema de base de datos

Una base de datos es un conjunto de elementos de datos que se describe a si mismo,

Suponga usted que se le ha encomendado el desarrollo de un sistema automatizado cuyo objetivo

ALUMNOS: nombre_alumno, documento, dirección, localidad, teléfono.

nombre_alumno nombre_alumno nombre_materia nombre_carrera

1.2 Componentes de un sistema de base de datos

Esquema simplificado de un sistema de bases de datos:

Los componentes de equipo del sistema son:

 Los volúmenes de almacenamiento secundario donde se conservan los datos almacenados,

 Programador de aplicaciones: escriben programas de aplicación que utiliza la base de datos.

1.3 Fundamentos para el uso de sistemas de base de datos

Los sistemas de bases de datos separan el almacenamiento de datos y los detalles de

 Fuera de un entorno de bases de datos, el mismo elemento de datos aparece en muchos

Considere el siguiente ejemplo: Un usuario necesita un informe de ciertos detalles acerca de