CBD1 Ebook

Lía F.
Torres Auad
Conceptos
de bases de
datos
Una aproximación a los

fundamentos
Conceptos de bases de datos
Una aproximación a los fundamentos
Índice
Tabla de contenido
CAPITULO I ............................................................................................................................ 4
Introducción a las Bases de Datos ..................................................................................... 4
Bases de Datos. Concepto................................................................................................... 5
Características del enfoque de Bases de Datos ................................................................. 7
Modelos de Bases de Datos .................................................................................................. 9
Modelos Lógicos basados en Registros ............................................................................. 11
Modelos Lógicos basados en Objetos ............................................................................... 11
Sistemas de Gestión de Bases de Datos  DBMS .................................................... 15
Funciones del DBMS ............................................................................................................ 21
Arquitectura de los Sistemas de Bases de Datos .......................................................... 25
Clasificación de los DBMS ................................................................................................... 29
Historia de los sistemas de bases de datos ..................................................................... 31
CAPITULO II ......................................................................................................................... 32
El nivel interno ...................................................................................................................... 32
Proceso general de localizar y leer un registro ............................................................ 33
Administración de Páginas ................................................................................................. 35
Administración de Registros almacenados ....................................................................... 37
Agrupamiento ....................................................................................................................... 39
Indexación ............................................................................................................................. 39
B.- Índices multinivel ....................................................................................................... 41
Dispersión .............................................................................................................................. 45
Dispersión dinámica ......................................................................................................... 47
Dispersión extensible ....................................................................................................... 47
Dispersión lineal ............................................................................................................... 48
CAPITULO III ........................................................................................................................ 49
Modelado Conceptual: El modelo Entidad-Relación...................................................... 49
ENTIDAD-RELACION ......................................................................................................... 51
Construir un modelo E-R ................................................................................................. 58
A tener en cuenta… ..................................................................................................... 62
Claves candidatas ......................................................................................................... 62
Clave principal ............................................................................................................... 62
Entidades fuertes y débiles ......................................................................................... 64
Modelo ER-Extendido: Entidades Compuestas ............................................................... 65
Generalización y Herencia ................................................................................................... 67
Pág. 2 de 141
© Ing. Lía F. Torres Auad
Dpto. Ciencias de la Computación
Diseño de un esquema de bases de datos ER ................................................................. 74
Metodología de diseño conceptual .................................................................................... 75
CAPITULO IV ....................................................................................................................... 77
Modelado Lógico: El modelo Relacional .......................................................................... 77
A. - Estructura de datos relacional .................................................................................... 80
B. Reglas de integridad ....................................................................................................... 88
Reglas de negocio ............................................................................................................ 91
Manipulación de los datos .................................................................................................. 99
Algebra relacional .............................................................................................................. 101
Tabla - Operadores del Algebra relacional ..................................................................... 101
Álgebra Relacional vs. Cálculo Relacional ................................................................... 110
Cálculo relacional............................................................................................................... 110
Vistas .................................................................................................................................... 112
Resumen .............................................................................................................................. 114
Bases de datos normalizadas .......................................................................................... 115
Medidas informales de la calidad para el diseño de esquemas de relaciones ...... 115
Proceso de normalización ................................................................................................ 118
Definición de la clave ................................................................................................. 119
Primera forma normal (1NF) .................................................................................... 120
Segunda forma normal (2NF) ................................................................................ 121
Tercera forma normal (3NF) .................................................................................. 122
Cuarta forma normal (4NF) o Forma Normal de Boyce-Codd (FNBC) ............ 123
Otras formas normales ........................................................................................... 123
SQL como lenguaje de consultas relacionales ............................................................. 124
Características generales .............................................................................................. 125
Funcionalidad .............................................................................................................. 125
Recuperación de Datos.............................................................................................. 127
Select................................................................................................................................ 127
Joins (Reunión) ........................................................................................................... 129
Operadores Agregados .............................................................................................. 129
Agregación por Grupos .............................................................................................. 130
Having .......................................................................................................................... 130
Subconsultas ............................................................................................................... 131
Definición de Datos .................................................................................................... 131
Create Table ................................................................................................................ 131
Tipos de Datos en SQL .............................................................................................. 132
Drop Table, Drop Index, Drop View ........................................................................ 135
Actualización de Datos .............................................................................................. 135
Insert Into ................................................................................................................... 135
Update.......................................................................................................................... 135
Delete ........................................................................................................................... 135
Consultas: Forma Básica ................................................................................................... 136
System Catalogs ............................................................................................................. 141
SQL Embebido ................................................................................................................ 141
Pág. 3 de 141
CAPITULO I
Introducción a las Bases de Datos
n estas hojas he intentado compendiar las conceptualizaciones básicas referidas a las
E Bases de Datos y a los Sistemas de Bases de Datos, como así también abordar de la
manera más clara y abarcativa posible toda la temática referida a las mismas,
involucradas en el programa de la asignatura. De hecho, las fuentes a las que recurrí son muy
variadas y de diversos enfoques; la tarea fue ardua, pero creo lograr el objetivo principal, el cual
supone además futuras ampliaciones y optimizaciones.
Sin embargo siempre es necesario que el alumno no tenga en cuenta sólo estos apuntes,
sino que “construya” su propio universo conceptual acerca del tema, por lo que presento a
continuación los títulos, autores y empresas editoras consultadas.
Bibliografía sugerida:
 Sistemas de bases de datos. Conceptos fundamentales. Ramez Elmasri/S.Navathe –

PEARSON EDUCACIÓN (texto principal)
 Fundamentos y Modelos de Bases de Datos. A. De Miguel, M. Piattini – RA-MA
 Bases de datos, modelos, lenguajes y diseño. James L. Johnson – OXFORD
 Introducción a los sistemas de bases de datos. Vol.1. C.J. Date – ADDISON WESLEY
Las bases de datos y su tecnología tuvieron un impacto decisivo sobre el uso creciente de las
computadoras. Desempeñan un papel muy importante en casi todas las áreas de aplicación:
negocios, ingeniería, medicina, derecho, educación, etc. El término Base de Datos es tan común
actualmente que debemos comenzar definiéndolo formalmente.
Pág. 4 de 141
Bases de Datos. Concepto
na primera aproximación al concepto, según Elmasri/Navathe, requiere

U necesariamente acercar en primer término la definición de:
Datos: hechos conocidos que pueden registrarse y que tienen un significado implícito.
Tomando esta idea, definimos ahora...
Base de datos: conjunto de datos interrelacionados entre sí, que tienen un significado
implícito...
Pero una definición muy general como ésta puede permitir hasta un periódico como ejemplo;
en verdad, la acepción es más restringida. Para comprender un poco mejor el alcance, mencionamos
a continuación algunas propiedades implícitas de una base de datos:
 Una BD representa algún aspecto del mundo real, “minimundo” o “universo de discurso”. Las
modificaciones del mini mundo se reflejan en la base de datos.
 Una BD es un conjunto de datos lógicamente coherente, con cierto significado inherente. No

es una colección aleatoria de datos.
 Toda BD se diseña, construye y puebla con datos para un propósito específico. Está dirigida
a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a dichos
usuarios.
En otras palabras una BD tiene una fuente de la cual se derivan los datos,
cierto grado de interacción con el mundo real y un público que está activamente
interesado en el contenido de la base de datos.
Según C. J. Date una base de datos es un conjunto de datos “persistentes” (tal como los
denomina el autor) utilizado por los sistemas de aplicaciones de una empresa determinada
entendiendo por empresa un término genérico aplicable a cualquier organización comercial,
científica, técnica, o de otro tipo, (ya sea unipersonal o corporativa): una compañía manufacturera,
un banco, un hospital, una universidad, una dependencia del gobierno, etc.
Pág. 5 de 141
Cada una de ellas debe por fuerza mantener una gran cantidad de datos referentes a su
operación. Estos son los “datos persistentes”. Para los ejemplos anteriores, y en el mismo orden,
datos de productos, de cuentas, de pacientes, de estudiantes, de planificación.
Para C. J. Date, una base de datos está constituida por cierto conjunto de datos,
donde datos significa hechos registrados, y representa, por lo general, algún aspecto del
mundo real, y sirve para fines específicos de uno o más grupos de usuarios.
Si bien Date es anterior a Elmasri, remarca igualmente el modelado del mundo real y
objetivos específicos, Date utiliza el término “entidad” para referirse a cualquiera de estos “objetos”
distinguibles que han de representarse en la base de datos, incluyendo y remarcando, además, que
existen también interrelaciones que vinculan dichas entidades.
A continuación, analicemos la concepción de base de datos de otro autor:
Para Johnson, como una aproximación más concreta, una base de datos es un
conjunto de elementos de datos que se describe a sí mismo, con relaciones entre ésos
elementos, que presenta una interfaz uniforme de servicios.
Esta definición menciona especialmente una de las características principales de toda base de
datos: se “autodescribe”. Es una de las definiciones más técnicas, y seguiremos precisándola a
medida que se revisen los métodos específicos.
Finalmente, se incluye la de De Miguel y Piattini, que además de más reciente, es la más

abarcativa y completa.
En esta última, todos los conceptos de los autores anteriores están contenidos, y se
incorporan formalmente los conceptos de “redundancia controlada”, “independencia”, “modelo de
datos”, “interrelaciones”, “restricciones” y “seguridad”. Todos ellos van a ser tratados como
características del enfoque de bds.
Para concluir la conceptualización, las bases de datos pueden ser de cualquier tamaño y
tener diversos grados de complejidad. La generación y mantenimiento de las bases de datos pueden
ser manuales o mecánicos. Las bases de datos computarizadas se pueden crear y mantener con un
grupo de programas de aplicación escritos específicamente para esa tarea, o bien, mediante un
sistema de gestión de bases de datos.
Pág. 6 de 141
Características del enfoque de Bases de Datos
Hay varias características que distinguen este nuevo enfoque del enfoque tradicional de
programación con archivos. Sintéticamente, en el procesamiento de archivos tradicional, cada
usuario define e implementa los archivos requeridos para una aplicación específica.
Según el enfoque de bases de datos se mantiene un único almacén de datos que se
define una sola vez y al cual tiene acceso muchos usuarios, esta es una de las diferencias con aquel
procesamiento de archivos.
Analizamos detenidamente las características:
Naturaleza autodescriptiva de los sistemas de bases de datos
“Los datos no deben depender de un programa para hacerlo

entendible y útil, es decir, los datos deben describirse por sí solos” (Johnson)
Característica fundamental, por la que el sistema no sólo contiene la base de datos misma,
sino también una definición o descripción completa de la base de datos.
En el procesamiento de archivos tradicional, la definición de los datos suele ser parte de los
programas de aplicación mismos, por lo que dichos programas sólo pueden trabajar con la
estructura de datos específica, declarada en los programas de aplicación.
Esta descripción mencionada en las bases de datos (MetaDatos) se almacena en el Catálogo

del sistema, que contiene información como la estructura de cada archivo, el tipo y el
formato de almacenamiento de cada elemento de información y diversas restricciones que se
aplican a los datos. (E/N)
Abstracción de los datos
“No es aconsejable que cada programador cree una estructura para cada
aplicación que repite elementos de datos existentes, que sólo ése programa conoce.”
“No es aconsejable que cada programador posea los archivos de datos

asociados con su programa, haciéndolos menos accesibles a los otros usuarios.”
Esta característica es la que hace posible la independencia con respecto a los programas y
datos y la independencia con respecto a los programas y operaciones. Un sistema de BD’s
ofrece a los usuarios una representación conceptual de los datos que no incluye muchos
de los detalles de cómo se almacenan.
En el procesamiento de archivos tradicional, la estructura de los archivos de datos viene

integrada en los programas de acceso, así que cualquier modificación de la estructura de un
archivo puede requerir la modificación de todos los programas que tienen acceso a dicho
archivo. En el enfoque de BD’s como la información de estructura y demás especificaciones
de archivos están concentradas en el Catálogo (Metadatos), los programas de acceso se
escriben de modo que sean independientes de los archivos específicos. Los usuarios de la
base de datos hacen referencia a la representación conceptuadle los archivos, y el sistema de
gestión de bases de datos extrae del catálogo los detalles de almacenamiento de éstos
cuando los necesita.
Pág. 7 de 141
Datos compartidos y procesamiento de transacciones multiusuario
“Sin bases de datos es más difícil compartir los datos; las

actualizaciones pueden producir inconsistencias que son incontrolables sin BD’s”
“Sin bases de datos los programas pueden interferir unos con otros; los
efectos de las transacciones en un programa no están aislados de los de otros.”
En este enfoque es totalmente viable el acceso simultáneo de varios usuarios a la base de

datos y es indispensable para que los datos de múltiples aplicaciones se integran y
mantengan una sola base de datos. El sistema de gestión de bases de datos incluye software
para el control de concurrencia que asegura que cuando varios usuarios intenten
actualizar los mismos datos lo hagan de manera controlada para que el resultado sea
correcto y sin interferencias.
Manejo de Múltiples vistas de los datos
Una base de datos suele tener muchos usuarios, cada uno de los cuales puede requerir una
perspectiva o vista diferente de la misma. Una vista, efectivamente, puede ser un
subconjunto de la base de datos o contener datos virtuales que se deriven de los archivos de
bases de datos. El enfoque de BD’s proporcionan los mecanismos para definir diversas vistas.
Es posible que algunos usuarios no necesiten saber si los datos a los que hacen referencia
están almacenados o son derivados.
___________________________________________________________________________
Las características hasta aquí mencionadas suponen implícitamente una comparación de

bondades y falencias con el procesamiento de archivos tradicional, que pueden resumirse así:
Las deficiencias de procesamiento de información antes de las bases de datos

comprenden:
 datos codificados (por cada programa/programador)

 interdependencia entre programas y archivos de datos
 repetición de datos e inconsistencias relativas
 representación específica de relaciones entre elementos de datos
 falta de coordinación entre programas que usan datos comunes
 acceso simultáneo restringido a datos
 métodos de recuperación de errores no uniformes
(inconsistencias no controladas)
Sin embargo, este renovado enfoque involucra otras características deseables para un
sistema de gestión de bases de datos, de ahora DBMS, cuyo análisis iniciaremos más adelante.
Pág. 8 de 141
Modelos de Bases de Datos

na característica fundamental del enfoque de Bases de Datos es que proporciona
U cierto nivel de abstracción de los datos al ocultar detalles de almacenamiento que la

mayoría de los usuarios no necesita conocer.
Para ofrecer dicha abstracción, los modelos de datos son el principal instrumento.
Pero… ¿qué es un modelo?
Desde el punto de vista de los datos…
Un modelo de datos es un conjunto de conceptos que pueden

servir para describir la estructura de una base de datos. En otras
palabras...
Es una colección de herramientas conceptuales para describir los
Con estructura definimos los
tipos de datos, los vínculos y datos, relaciones entre ellos, semántica asociada a los datos y
las restricciones que deben restricciones de consistencia.
cumplirse para ésos datos.
Pág. 9 de 141
Por lo regular los modelos de datos contienen además, un conjunto de operaciones básicas para
especificar lecturas y actualizaciones de la base de datos, y casi siempre cuenta con operaciones
genéricas para insertar eliminar, modificar o recuperar un objeto.
Dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la
bases de datos, podemos clasificar los modelos en tres categorías:
o de alto nivel o Conceptuales,

o de representación o Implementación y
o los modelos de datos de bajo nivel o Físicos.
o Modelos de datos Conceptuales: disponen de conceptos muy cercanos al modo como la

generalidad de los usuarios percibe los datos. Uno de los más populares el de Entidad-Vínculo
utilizan conceptos como entidades, atributos y vínculos, que describiremos brevemente y
estudiaremos en otras unidades.
Una Entidad representa un objeto o concepto del mundo real, almacenado en la base de datos.
Un Atributo representa alguna propiedad de interés que dá una descripción más amplia de la E.
Un vínculo describe una interacción entre dos o más entidades.
o Modelos de datos de Implementación: entre estos dos extremos hay una clase de modelos de
datos cuyos conceptos pueden ser entendidos por los usuarios finales aunque no están
demasiado alejados de la forma en que los datos se organizan dentro del computador. Estos
ocultan algunos detalles de cómo se almacenan los datos, pero pueden implementarse de
manera directa. Son los más utilizados en los DBMS actuales, y entre ellos se cuentan los tres
modelos más comunes: el Relacional, el de Red y el Jerárquico. Representan sus datos
valiéndose de estructuras de registros, por lo que a veces se les denomina modelos de datos
basados en registros.
o Modelos de datos Físicos: proporcionan conceptos que describen los detalles de cómo se
almacenan los datos en el computador, al representar información como los formatos y
ordenamientos de los registros y los caminos de acceso. Un camino de acceso es una estructura
que hace eficiente la búsqueda de registros específicos de la base de datos. Casi siempre están
dirigidos a especialistas en computación, no a los usuarios finales corrientes.
Pág. 10 de 141
Modelos Lógicos basados en Registros
Se usan para describir datos en los Niveles Conceptual y Físico. A diferencia de los basados
en objetos, son utilizados para especificar la estructura lógica global de la base de datos y para
proporcionar una descripción a un nivel más alto de la Implementación.
Estos modelos se llaman así porque la base de datos está estructurada en registros de formato fijo
de varios tipos. Cada tipo de registro define un número fijo de campos de longitud fija.
 Modelo Relacional de Bases de Datos

Emplea tablas para organizar los elementos de datos. Cada tabla corresponde a una entidad de
aplicación, y cada fila representa una instancia de ésa entidad. A pesar de las complicaciones que
resultan de relaciones en donde aparecen muchas filas de muchas tablas, este sencillo
mecanismo soporta relaciones sin recurrir a estructuras auxiliares, como son listas o índices
enlazados. El lenguaje de consulta estructurado (SQL) sirve como interfaz uniforme para los
usuarios, proporcionando un conjunto de expresiones standard para almacenar y recuperar
datos.
 Modelo Jerárquico de Bases de Datos

Es relativamente viejo, ya que remonta a finales de la década de 1950. Supone que una
estructura de árbol, como el organigrama de una empresa. Es la relación que se presenta con
más frecuencia. Esta suposición está reconocida actualmente como confusa. De hecho, muchas
deficiencias del modelo resultan de esta visión de relaciones sobrerrestringida; pero, para
simplificar, supongamos que sólo son importantes las relaciones jerárquicas.
Este modelo organiza elementos de datos en filas tabulares, una por cada instancia de una
entidad de aplicación; representa relaciones con la noción de adyacencia lógica, o más
precisamente, de proximidad lógica, en el árbol linealizado.
La proximidad lógica describe la organización pero no implica proximidad física.
 Modelo de Bases de Datos en Red

Sustituye al árbol jerárquico con una gráfica, lo que permite conexiones más generales entre los
nodos (enlaces). Los registros en la base de datos se organizan como colecciones de grafos
arbitrarios.
Como el método Jerárquico contiene métodos más complicados para manejar situaciones donde
la proximidad lógica falla al no poder colocar un elemento de datos simultáneamente en dos
posiciones de la lista, la sintaxis resulta más difícil de seguir.
Este modelo de Red evolucionó específicamente para manejar relaciones no jerárquicas, pues
mantiene relaciones con un sistema de cadenas que se intersectan.
Modelos Lógicos basados en Objetos

Podemos concebir a los modelos de datos orientados a objetos como una nueva familia de
modelos de implementación de alto nivel más próxima a los niveles conceptuales.
 Modelo Entidad-Relación
Se basa en la percepción de un mundo real que consiste en una colección de objetos básicos
llamados Entidades y las relaciones o Vínculos entre estos objetos. Este modelo será analizado
en profundidad en el capítulo 3.
 Modelo de Bases de Datos Orientados a Objetos

Es el primer modelo pos_relacional y ofrece una alternativa para las inserciones en tablas para
mantener relaciones. Al igual que el anterior, se basa en una colección de objetos.
Representa una entidad de aplicación como una clase; una clase captura los atributos y el
comportamiento de la entidad. Las instancias individuales de cada clase son llamadas Objetos.
Pág. 11 de 141
Dentro de un objeto, los atributos de clase toman valores específicos, sin embargo las pautas de
comportamiento son compartidas por todos los objetos. Estas pautas forman parte del objeto,
denominándose métodos (parte de códigos que operan sobre el objeto).
Este modelo no restringe los valores de los atributos al pequeño conjunto de los 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 o texto. En lugar de esto los valores pueden
ser otros objetos. Es decir, los objetos contienen objetos a un nivel de anidamiento de
profundidad arbitraria.
El modelo mantiene relaciones por medio de una “contención lógica”. La única forma en que un
objeto puede acceder a los datos de otro objeto es invocando a un método de ése objeto.
Como conclusión…
Pág. 12 de 141
Otras conceptualizaciones:
En cualquier modelo de base de datos es importante distinguir entre la descripción de la base de
datos y la base de datos misma.
Entonces, el Esquema de la base de datos (Metadatos) es la descripción de la misma.

Se especifica durante el diseño y no se modifica asiduamente. Cada uno de los objetos del esquema
de denomina elemento del esquema.
Pág. 13 de 141
En la mayoría de los modelos de datos se utilizan ciertas convenciones para representar los
esquemas en forma de diagramas.
El diagrama del esquema es la representación del mismo. Muestra un

diagrama esquemático de la base de datos y sólo ilustran algunos
aspectos del esquema como los nombres de los tipos de registros y de los
elementos de información y alguna clase de restricciones
Importante!: Al definir una nueva base de datos, sólo especificamos el esquema al DBMS. Los
datos reales de la base de datos van siendo ingresados luego y pueden cambiar con mucha
frecuencia (para el ejemplo: agregar nuevos estudiantes, modificar notas, etc.).
El Estado de la base de datos es el conjunto de datos, llamados ocurrencias

o ejemplares que la misma posee en un determinado momento.
En un estado dado de la base de datos, cada elemento del esquema tiene su propio
conjunto actual de ocurrencias, por ejemplo, el elemento Estudiante contendrá como ejemplares del
conjunto de entidades estudiantes individuales (registros).
Es posible crear muchos estados de la base de datos que correspondan a un esquema en

particular. Cada vez que insertamos o eliminamos un registro, o que modificamos el valor de un
elemento de información, transformamos un estado de la base de datos a otro.
La distinción entre Esquema y Estado de la base de datos es muy importante. Al esquema se le
llama intención, y a un estado de la base de datos, extensión del esquema.
Cuando se define una nueva base de datos, el estado correspondiente es

vacío, sin datos. Cuando cargamos éstos por primera vez, pasa al estado
inicial. De ahí en adelante, siempre que se aplique una instrucción de
actualización a la base de datos tendremos otro estado. El DBMS se encarga
en parte de asegurar que todos los estados de la base de datos sean estados
válidos; esto es, que satisfagan la estructura y las restricciones especificadas
en el esquema. Por eso es tan importante especificar un esquema correcto.
Pág. 14 de 141
Sistemas de Gestión de Bases de Datos  DBMS

Analicemos brevemente las definiciones formales dadas por los autores de nuestro interés:
Elmasri/Navathe:
Un DBMS (DataBase Management System) es un conjunto de programas que
permite a los usuarios crear y mantener una BD. Es un sistema de software de
propósito general que facilita el proceso de definir, construir y manipular bases de
datos para diversas aplicaciones.
Johnson:
Un DBMS proporciona el método de organización necesario para el
almacenamiento y recuperación flexibles de grandes cantidades de datos. Es un
producto de software que presta soporte al almacenamiento confiable de los datos,
pone en marcha las estructuras para mantener relaciones y restricciones, y ofrece
servicios de almacenamiento y recuperación a usuarios; más funciones que se
ocupan de otras tareas, como son el acceso simultáneo, seguridad y respaldo de
datos.
C. J. Date:
Un DBMS es un sistema computarizado cuyo propósito general es mantener
información y hacer que esté disponible cuando se solicite, entendiéndose por
información todo lo que se considere importante para apoyar el proceso general de
atender los asuntos del individuo o la organización a la cual debe servir el sistema.
Veamos este entorno simplificado de un SGBD.
A. De Miguel
y M. Piattini:
Conjunto de programas que permiten la implementación, acceso y mantenimiento de
la base de datos.
Como se puede apreciar, la definición de BD de este autor contiene los demás
conceptos que aquí no hace falta mencionar. A este punto podemos decir que:
Pág. 15 de 141
El DBMS actúa como interfaz entre la BD y los distintos niveles de gestión de la organización.
Integra los distintos subsistemas, atendiendo a las necesidades de los usuarios en los tres niveles.
Usuarios / Programadores
SISTEMA DE
BASES DE DATOS
Programas de Aplicación / Consultas
SOFTWARE
DEL DBMS Software para procesar
consultas / programas
Software para tener acceso

a los datos almacenados
Definición de la base Base de Datos

de datos almacenada almacenada
(MetaDatos)
Pág. 16 de 141
Tipos de usuario de un Sistema de Bases de Datos
Una base de datos pequeña puede ser diseñada, construida y manipulada por una sola persona. Sin
embargo a medida que crece la complejidad de la misma, por ejemplo, a cientos de usuarios, el
diseño, uso y mantenimiento suele depender de un grupo de gente. Analicemos estos casos de los
que Elmasri llama “actores en el escenario”:
 Administrador de bases de datos (DBA): tiene el control central sobre el sistema (datos y
programas que los acceden). Administra los recursos compartidos, controlando su uso. El recurso
primario es la propia base de datos y el secundario el DBMS y el software con él relacionado.
Suele contar con personal a su cargo para desempeñar estas funciones.
Resumiendo las tareas del DBA decimos:
a. Coordina el trabajo de los diseñadores respecto a la Definición del Esquema, de la

estructura de almacenamiento y los métodos de acceso.
b. Supervisa la modificación del esquema y la organización física.
c. Autoriza el acceso a la base de datos, de coordinar y vigilar su empleo.
d. Adquiere recursos necesarios de software y hardware.
e. Respecto a la Concesión de la autorización para el acceso a los datos, es responsable de

violaciones de seguridad. También de respuestas lentas del sistema.
f. Especifica las restricciones de Integridad.
 Diseñadores: se encargan de identificar los datos que se almacenarán y de elegir las

estructuras apropiadas para representar y almacenar dichos datos. Casi siempre interactúan con
cada uno de los grupos de usuarios potenciales y desarrollan una vista que satisfaga los
requerimientos de datos y de procesamiento para ése grupo.
 Usuarios finales: son las personas que necesitan tener acceso a la base de datos para
consultarla, actualizarla y generar informes. Existen varias categorías:
a. Simples o paramétricos: constituyen la mayor porción de los usuarios finales y su

principal función gira en torno a las consultas y actualizaciones constantes de la base de
datos, utilizando tipos standard de estas operaciones que se han programado y probado
con mucho cuidado. NO necesitan saber mucho de los recursos que proporciona el
DBMS. (por ej.; encargados de reservaciones de líneas aéreas, hoteles)
b. Los esporádicos: tienen acceso de vez en cuando y posiblemente requieran informa-ción

diferente en cada ocasión. Aprenden a emplear sólo unos cuantos recursos. Suelen ser
gerentes de nivel medio o alto.
c. Avanzados: son los que conocen en forma cabal los recursos del DBMS y lo utilizan para
satisfacer requerimientos complejos.
Sin embargo, existen además personas a las que no les interesa la base de datos misma.
Tiene que ver, en cambio con el diseño, creación y operación del software y entorno del sistema del
DBMS, y Elmasri los llama “trabajadores tras bambalinas”. Podemos distinguir las siguientes
categorías:
Pág. 17 de 141
 Diseñadores e implementadores del DBMS: éstos se encargan de diseñar e implementar los
módulos e interfaces del DBMS en forma de “paquetes de software”. UN DBMS es un sistema
complejo de software que consta de diversos componentes o módulos, como los módulos para
implementar el Catálogo, los lenguajes de consulta, los procesadores de interfaz, el acceso a los
datos y la seguridad.
 Creadores de Herramientas: se ocupan de diseñar e implementar paquetes especiales

llamados herramientas. Las herramientas son paquetes de software que facilitan el diseño y el
empleo de los sistemas de bases de datos, y que ayudan a elevar el rendimiento. Estos paquetes
son opcionales y a menudo se adquieren por separado. Incluyen paquetes para diseñar bases de
datos, vigilar el rendimiento, proporcionar interfaces de lenguaje natural o de gráficos, elaborar
prototipos, realizar simulaciones y generar datos de prueba.
 Operadores y personal de mantenimiento: tiene a su cargo el funcionamiento y

mantenimiento reales del entorno de hardware y software del sistema de base de datos.
Características de un DBMS
Ahora analizaremos cuidadosamente cuáles son las características esperables en un

DBMS y las ventajas específicas que emanan del concepto.
A.- Control de la Redundancia

Es posible disminuir la redundancia
En los sistemas sin bases de datos, cada aplicación tiene sus propios archivos privados para manejar
sus aplicaciones de procesamiento de datos, lo que provoca considerable redundancia en los datos
almacenados, con el consecuente desperdicio de espacio de almacenamiento .
A veces, y no pocas, esta redundancia provoca varios problemas, no sólo el del almacenamiento (peor
aún si las bd’s son grandes), sino también una duplicación del trabajo porque es necesario realizar
varias actualizaciones lógicas (como introducir los datos de un nuevo registro) tantas veces como
archivos contengan una estructura igual (igual entidad).
No debe entenderse que es posible o deseable eliminar toda la redundancia, es recomendable notar
la conveniencia de controlarla con mucho cuidado, por ejemplo, mediante el uso de métodos de
propagación de actualizaciones que eliminen las inconsistencias de datos. Veamos el siguiente ítem.
B.- Cumplimiento de las restricciones de Integridad

Es posible mantener la integridad
Es posible que los archivos que representen los mismos datos de tornen inconsistentes porque la
actualización se haya aplicado a algunos archivos y a otros no. Incluso si la actualización se aplica a
todos los archivos apropiados, persiste la posibilidad de que los datos relacionados también resulten
con problemas de consistencia porque cada grupo de usuarios aplica las actualizaciones de manera
independiente. Por ejemplo, introducir una fecha errónea en una sólo aplicación; el dato era 28/04/65
y en uno de los tres archivos donde se realizó la entrada se tipeó 23/04/65.
La inconsistencia entre varias entradas que supuestamente representan el mismo “hecho” es un

ejemplo de falta de integridad.
Con el enfoque de bases de datos, las vistas de los diferentes grupos de usuarios se integran durante
el diseño de la misma, siendo almacenados en un mismo lugar, evitando inconsistencias y ahorrando
espacio de almacenamiento.
Pág. 18 de 141
Por otro lado, si la redundancia no se elimina, pero sí se controla (haciendo que la perciba el DBMS),
se puede garantizar la consistencia de la base de datos desde el punto de vista del usuario,
asegurándose de aplicar en forma automática a las otras entradas la modificación hecha a una de
ellas. Este proceso se conoce como método de propagación de actualizaciones entendiéndose como
actualización altas (inserciones), bajas (eliminaciones) y modificaciones de datos.
Finalmente, la mayor parte de las aplicaciones de bases de datos tienen ciertas restricciones de
integridad que deben cumplir los datos en sí mismos (normalmente conocidas como validaciones).
La forma más simple de restringir la integridad consiste en especificar un tipo de datos para cada
elemento de información.
C.- Sharing de datos y archivos

Es posible compartir datos entre aplicaciones
Es posible equilibrar requerimientos opuestos
El compartir archivos, hecho que se presupone en los puntos anteriores, implica no sólo que las
aplicaciones ya existentes pueden acceder a la misma información de la base de datos, sino también
que se pueden desarrollar aplicaciones nuevas para trabajar con los mismos datos almacenados.
Dicho de otro modo, es posible satisfacer las necesidades de información de las aplicaciones nuevas
sin tener que almacenar datos adicionales.
Al tener un control centralizado de la base de datos, se puede garantizar la observancia de todas las
normas aplicables para la representación de datos. Es conveniente, entonces, escoger una forma de
representación de datos con la cual las aplicaciones más importantes puedan tener acceso rápido,
aunque el funcionamiento de algunas otras aplicaciones sufra menoscabo.
La normalización de formatos de los datos almacenados es deseable además, y sobre todo, como
apoyo para el intercambio de información, o migración de datos entre sistemas. Asimismo, las normas
para nombrar y documentar los datos son muy convenientes como ayuda para la comprensibilidad de
la información.
D.- Restricción de Accesos No autorizados

Es posible aplicar restricciones de seguridad
Cuando muchos usuarios comparten una misma base de datos, es probable que no todos tengan
autorización para tener acceso a toda la información que contiene. Al tener jurisdicción completa sobre
la base de datos, el DBMS puede:
a) Asegurar que el acceso a la base de datos sea sólo a través de canales apropiados y, por tanto,
b) Definir las verificaciones de seguridad por realizar cuando se intente acceder a información
delicada.
Por lo regular, a los usuarios o grupos de usuarios se les asignan números de cuenta protegidos con
contraseñas, mismos que sirven para tener acceso a la base de datos. El DBMS debe contar con un
susbsistema de seguridad y autorización que permita crear cuentas y especificar restricciones para
ellas. Luego, por tanto, deberá obligar automáticamente al cumplimiento de dichas restricciones.
E.- Suministro de múltiples interfaces con los usuarios
Puesto que muchos tipos de usuarios con diversos niveles de conocimientos técnicos utilizan las bases
de datos, el DBMS debe ofrecer diferentes interfases. Entre éstas podemos mencionar los lenguajes
de consulta para usuarios esporádicos, las interfases del lenguaje de programación para
programadores de aplicaciones, las formas y los códigos de órdenes para los usuarios paramétricos y
las interfases controladas por menús y en lenguaje natural para los usuarios autónomos.
Pág. 19 de 141
F.- Inferencias en la BD mediante reglas de deducción
Otra aplicación de los sistemas de bases de datos consiste en ofrecer recursos para definir reglas de
deducción que permitan deducir o inferir información nueva a partir de los datos almacenados. A estos
sistemas se los conoce como bases de datos deductivas.
Por ejemplo, puede haber reglas complejas en la aplicación de este ejemplo en particular: * cuándo
un estudiante debe ser admitido con “reservas” el la inscripción del curso posterior (tiene que ver con
su rendimiento académico, su desenvolvimiento disciplinario, el porcentaje de asistencias y/o llegadas
tardes, y otros parámetros evaluables en conjunto. Estas reglas se pueden especificar en forma
declarativa como reglas de deducción, con cuya aplicación será posible detectar este tipo de
alumnos (de inscripción condicional). En un DBMS tradicional se tiene que escribir un programa o
procedimiento explícito para apoyar estas aplicaciones, y si cambian las reglas, casi siempre es más
fácil modificar las reglas de deducción declaradas que volver a codificar los programas por
procedimiento.
G.- Representación de vínculos complejos entre los datos
Es preciso que el DBMS pueda representar diversos vínculos complejos con los datos y también
obtener y actualizar con rapidez y eficiencia datos que estén mutuamente relacionados, puesto que
una base de datos puede contener numerosos conjuntos de datos que están relacionados entre sí de
muchas maneras.
H.- Respaldo y recuperación
Todo DBMS debe contar con recursos para recuperarse de fallos de hardware o software. Para ello
está el sistema de respaldo y recuperación. Por ejemplo, si el sistema falla mientras se está
ejecutando un complejo programa de actualización, este subsistema se asegurará que la base de
datos se restaure al estado en el que estaba antes de que comenzara la ejecución del programa.
Como alternativa, también puede asegurarse de que el programa reanude su ejecución en el punto en
que fue interrumpido, de modo que su efecto completo se registre en la base de datos.
___________________________________________________________________________________
Como conclusión, el empleo del enfoque de bases de datos involucra otras implicaciones que
pueden resultar provechosas como:
 Menor tiempo en la creación de aplicaciones: de 6 a 4 veces menor que el enfoque

tradicional.
 Flexibilidad al modificar estructuras frente a cambios de requerimientos. (sin modif. de

datos)
 Disponibilidad de información actualizada, ya que está disponible a todos los usuarios.
 Potencial para imponer normas: aplicadas a nombres y formatos de los elementos de

información, formatos de presentación, estructuras de los informes, etc en toda la
organización.
Pág. 20 de 141
Funciones del DBMS
Examinemos ahora las funciones del DBMS con un poco más de detalle, que
seguramente incluirán, por lo menos, todas las siguientes:
Vamos a intentar ahora explicar brevemente, y en forma enumerativa dichas funciones:
Pág. 21 de 141
a) Definición de datos
El DBMS debe ser capaz de aceptar definiciones de datos (esquemas externos, el esquema
conceptual, el esquema interno, y todas las correspondencias asociadas), es decir, debe
incluir componentes procesadores de lenguajes para cada uno de los diversos lenguajes de
definición de datos (DDL)
b) Manipulación de datos
El DBMS debe ser capaz de atender las solicitudes del usuario para extraer, y quizá poner al
día, datos que ya existen en la base de datos, o para agregar en ella datos nuevos, es decir,
debe incluir un componente procesador de lenguaje de manipulación de datos (DML)
Una solicitud en DML puede ser planeada, es decir, prevista con mucho tiempo antes de su
primera ejecución, por lo que el DBA afinó el diseño físico de la base de datos a fin de
garantizar un buen desempeño. Y también puede ser no planeada, es decir, que surge de
improviso, por lo que el diseño físico de la base de datos puede ser o no ideal para la
solicitud específica de que se trate.
c) Seguridad e integridad de los datos

El DBMS debe supervisar las solicitudes de los usuarios y rechazar los intentos de violar las
medidas de seguridad e integridad definidas por el DBA.
d) Recuperación y concurrencia de los datos

El DBMS debe cuidar del cumplimiento de ciertos controles de recuperación y concurrencia, o
en su defecto delegarlo a algún componente de software relacionado como el Administrador
de transacciones.
e) Diccionario de datos
El DBMS debe incluir una función de diccionario de datos, entendiéndose éste como una base
de datos misma, no del usuario, sino del sistema. El contenido del diccionario puede
considerarse como datos acerca de los datos (Metadatos).
f) Desempeño
El DBMS debe ejecutar todas las funciones recién descriptas en la forma más eficiente
posible.
Como conclusión, una forma de caracterizar la función general del DBMS es decir que constituye la
interfaz entre el usuario y el sistema de base de datos.
La Interfaz del usuario puede definirse como una frontera del sistema,
más allá de la cual todo resulta invisible para el usuario. Por definición
entonces, la interfaz del usuario está en el nivel externo.
Componentes funcionales del DBMS
Pág. 22 de 141
Un DBMS son sistemas de software muy complejos. Existen distintos tipos de Componentes
del software que constituyen un DBMS, siendo los más representativos expuestos en este cuadro:
El acceso a disco suele controlarlo primordialmente el Sistema operativo (S.O.) que programa
la entrada/salida del disco.
Gestor de Archivos Un módulo gestor de datos almacenados del DBMS, de más alto nivel,
controla el acceso a la información almacenada en el disco, ya sea que
forme parte de la base de datos o del catálogo.
Las líneas punteadas y los círculos rotulados A, B, C, D y E ilustran accesos
que están bajo el control de este gestor de datos almacenados.
Este último puede emplear servicios básicos del S.O. para transferir los datos
de bajo nivel entre el disco y la memoria principal del com-putador, pero
controla otros aspectos de la transferencia de datos, como el manejo de las
áreas de almacenamiento intermedio (buffers) en la memoria principal. Una
vez que los datos estén en dicho almacenamiento intermedio, otros módulos
del DBMS podrán procesarlos.
Compilador de DDL
procesa las definiciones de esquemas, especificadas en el DDL, y almacena
las descripciones de los esquemas (metadatos) en el catálogo del DBMS. El
catálogo contiene información como los nombres de los archivos y de los
elementos de información, los detalles de almacenamiento de cada archivo,
la información de correspondencia entre los esquemas y restricciones. Los
módulos de DBMS que necesiten conocer esta información deberán consultar
al catálogo.
Procesador de la base de datos
Pág. 23 de 141
En tiempo de ejecución se encarga de los accesos a ella durante la
ejecución; recibe las operaciones de obtención o de actualización y las
ejecuta sobre la base de datos. El acceso a disco se tiene mediante el Gestor
de datos almacenados. El compilador de consultas maneja las consultas de
alto nivel que se introducen interactivamente. Analiza la sintaxis y el
contenido de las consultas y luego genera llamadas al procesador en tiempo
de ejecución para atender la solicitud.
Precompilador
Extrae órdenes en DML de un programa de aplicación escrito en un lenguaje
de programación anfitrión. Estas órdenes se envían al compilador de DML
para convertirlas en código objeto para el acceso a la base de datos, y el
resto del programa se envía al compilador del lenguaje anfitrión. El código
objeto de las órdenes en DML y el del resto del programa se enlazan como
formando una transacción programada cuyo código ejecutable incluye
llamadas al procesador del a base de datos durante el tiempo de ejecución.
En los párrafos precedentes, las descripciones de funciones dan lugar a la mención de diversos
lenguajes de bases de datos (DDL, DML, etc.) que ofrecen los DBMS a las distintas categorías de
usuario (analizadas anteriormente).
 Lenguaje de Definición de Datos  DDL

Permite especificar los esquemas conceptual e interno y las correspondencias entre ambos,
sobretodo en los DBMS en que no se mantiene una separación estricta de niveles. En ellos en
DBA y los diseñadores utilizan este mismo lenguaje.
 Lenguaje de Definición de Almacenamiento  SDL

Se utiliza para especificar solamente el esquema interno. Las correspondencias entre los dos
esquemas se pueden especificar en cualquiera de los dos lenguajes (SDL o DDL).
 Lenguaje de Definición de Vistas  VDL

Se utiliza para especificar las vistas del usuario y sus correspondencias con el esquema
conceptual. Es imprescindible en una verdadera arquitectura de tres esquemas.
 Lenguaje de manipulación de Datos  DML

Una vez que se han compilado los esquemas de la base de datos y que en ésta se introdujeron
datos, los usuarios requerirán algún mecanismo para manipularla (recuperar, insertar, eliminar y
modificar datos). Para estos fines el DBMS ofrece este lenguaje.
Pág. 24 de 141
Arquitectura de los Sistemas de Bases de Datos
Arquitectura de Tres Niveles

EL DBMS almacena el esquema en su catálogo, de modo que el software del DBMS pueda
consultarlo siempre que necesite hacerlo.
Para poder contar con las características deseables de a) independencia con respecto a programas
y datos, b) el manejo de múltiples vistas de usuario y c) el empleo de un catálogo para almacenar el
Esquema de la base de datos, se ha especificado una Arquitectura para los sistemas de bases de
datos denominada arquitectura de tres esquemas (también conocida como ANSI / SPARC).
El objetivo de la Arquitectura de Tres Esquemas consiste en formar una

separación entre las aplicaciones del usuario y la base de datos física.
Estos esquemas se pueden definir en estos tres niveles:
Pág. 25 de 141
1. El nivel Interno tiene un esquema interno que describe la estructura física de
almacenamiento de los datos.
El esquema interno emplea un modelo físico de los datos, y describe todos los detalles para
su almacenamiento, así como los caminos de acceso para la base de datos.
2. El nivel Conceptual tiene un esquema conceptual que describe la estructura de toda la

base de datos para una comunidad de usuarios.
El esquema conceptual oculta los detalles de las estructuras físicas de almacenamiento y
se concentra en describir entidades, tipos de datos, vínculos, operaciones de los usuarios y
restricciones.
>>>En este nivel podemos usar un modelo de datos de alto nivel o conceptual.<<<
3. El nivel externo o de vistas incluye varios esquemas externos o vistas de usuario.

Cada esquema externo describe la parte de la base de datos que interesa a un grupo de
usuarios determinado, y oculta a ése grupo el resto de la base de datos. >>>En este nivel
podemos usar un modelo de datos de alto nivel o de implementación.<<<
Si el nivel externo se ocupa de las vistas individuales de los usuarios, puede considerarse
que el nivel conceptual se ocupa de una vista comunitaria de los usuarios. Dicho de otro modo,
existirán muchas vistas externas distintas, cada una formada por una representación más o menos
abstracta de alguna parte de la base de datos total, y existirá sólo una vista conceptual formada por
una representación igualmente abstracta de la base de datos en su totalidad. De manera similar sólo
habrá una vista interna , la cual representará a toda la base de datos tal como está almacenada
físicamente.
 Cabe señalar que los tres esquemas no son más que descripciones de los
datos; los únicos datos que existen realmente están en el nivel físico.
Pág. 26 de 141
En un DBMS basado en la arquitectura de tres esquemas, cada grupo de usuarios hace
referencia exclusivamente a su propio esquema externo; por tanto el DBMS debe transformar una
solicitud expresada en términos de un esquema externo a una solicitud expresada en términos de un
esquema conceptual, y luego a una solicitud en el esquema interno que se procesará sobre la base
de datos almacenada.
Solicitud expresada en términos Solicitud expresada en términos Solicitud expresada en términos

del esquema externo del esquema conceptual del esquema interno
El proceso de transformar solicitudes y resultados de un nivel a otro se

denomina Correspondencia o Transformación (mapping).
Estas correspondencias pueden requerir bastante tiempo, por los que algunos DBMS no cuentan
con vistas externas.
Consideraciones:
En un porcentaje considerable de DBMS no se distinguen del todo los tres niveles, pero en algunos
de ellos se cuenta, en cierta medida, con la arquitectura de tres esquemas.
o Algunos incluyen detalles del nivel físico en el esquema conceptual.

o Algunos permiten utilizar diferentes modelos de datos en los niveles conceptual y externo.
o En casi todos los que manejan vistas de usuario, los esquemas externos se especifican en el
mismo modelo de datos que describe la información a nivel conceptual.
Independencia con respecto de los datos
Independencia con respecto de los datos: capacidad para modificar el esquema de un nivel de
la base de datos SIN tener que modificar el esquema del nivel inmediato superior
La Arquitectura de tres esquemas puede servir para explicar el concepto de independencia con
respecto de los datos, y para el que podemos distinguir dos tipos:
Pág. 27 de 141
a) Independencia lógica respecto de los datos: capacidad de modificar el esquema conceptual
sin tener que alterar los esquemas externos ni los programas de aplicación. Por ejemplo,
podemos ampliar la base de datos (añadiendo un nuevo registro o elemento de información),
o para reducir la misma (eliminando un tipo de registro o un elemento de información), en
ambos casos modificamos el esquema conceptual, lo que no deberá afectar los programas de
aplicación que deberán funcionar igual que antes, luego de esta reorganización lógica. Sólo
será preciso modificar la definición de la vista y las correspondencias
b) Independencia física respecto de los datos: capacidad de modificar el esquema interno sin
tener que alterar el esquema conceptual (o los externos). A veces es preciso modificar el
esquema interno por la necesidad de re-organizar ciertos archivos físicos – por ejemplo, al
crear estructuras de acceso adicionales- a fin de mejorar el rendimiento de las operaciones
de obtención o actualización. Si la base de datos aún contiene los mismos datos, no deberá
ser necesario modificar el esquema conceptual.
 Es más fácil de lograr que la anterior, puesto que sólo se refiere a la separación entre las
aplicaciones y las estructuras físicas de almacenamiento.
Resumiendo…
C.J. Date, uno de nuestros autores de cabecera pone especial énfasis en ésta última
(independencia física de los datos) como un objetivo primordial de los sistemas de bases de datos y
la define como:
Inmunidad de las aplicaciones ante los cambios en la estructura de almacenamiento y en la técnica de acceso.
Pág. 28 de 141
Vale la pena examinar con mayor detalle algunos ejemplos de los tipos de modificaciones
que se podrían querer realizar, y a los cuales deberían ser inmunes las aplicaciones.
Ejemplo. Vamos a suponer la existencia de una aplicación para procesar al archivo Empleados, y
también que se decidió, por razones de desempeño, almacenar el archivo indexándolo según el
campo Nro. de Empleado. En este caso, lo normal es que dicha aplicación tenga presente la
existencia del índice, así como también la secuencia del archivo definida por él, y la estructura
interna de la aplicación girará en torno de ése conocimiento.
En particular, la forma exacta de los diversos procedimientos de acceso a los datos y verificación de
excepciones dependerá en sumo grado de los detalles de la interfaz que los programas de
administración de datos presenten a la aplicación.
Esta es una aplicación dependiente de los datos porque es imposible alterar la estructura de
almacenamiento (organización física de los datos) o la técnica de acceso sin afectar (quizá
gravemente) a la aplicación. Por ejemplo, no sería factible sustituir el archivo indexado en cuestión
por un archivo con direccionamiento por dispersión (concepto analizado más adelante) sin hacer
modificaciones importantes al programa.
Por añadidura, es evidente que las partes del programa en donde se necesitarían alteraciones en un
caso así serían precisamente las que se comunican con los programas de administración de datos;
las dificultades que esto presentaría nada tienen que ver con el problema para cuya resolución se
escribió originalmente el programa, es decir, son problemas introducidos por la naturaleza de la
interfaz para la administración de datos.
Resumiendo, el DBMS funciona conceptualmente del siguiente modo:
1) Un usuario solicita acceso, empleando algún sub_lenguaje de datos determinado (SQL).

2) EL DBMS interpreta esa solicitud y la analiza.
3) El DBMS inspecciona, en orden,
 el esquema externo de ése usuario,
 la correspondencia externa / conceptual asociada,
 el esquema conceptual,
 la correspondencia conceptual / interna,
 y la definición de la estructura de almacenamiento.
4) El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.
Clasificación de los DBMS
Pág. 29 de 141
Para Elmasri/Navathe es posible clasificar los DBMS de varias maneras distintas teniendo
en cuenta criterios diversos a saber:
Entidad – Vínculo
Conceptuales o de alto nivel
Orientados a Objetos
categorías
Según el modelo de Datos
Relacional
(criterio principal) Basados
de Implementación de Red en
empleados con mayor frecuencia registros
en los DBMS comerciales actuales Jerárquico
Monousuario: atienden un usuario a al vez, y su principal

Según el número de usuarios uso se da en las computadoras personales
a los que da servicio el sistema
Multiusuario: atienden a varios usuarios al mismo tiem-
po, y conforman la mayoría de los DBMS
Centralizados: sus datos se almacenan en una sola

computadora, al igual que el DBMS,
Según el número de sitios en atendiendo a varios usuarios.
los que está distribuida la BD.
Distribuidos: la base de datos real y el DBMS pueden
estar distribuidos en varios sitios conec-
tados por una red de computadoras.
de Propósito General: es utilizado para diversas apli-

ciones.
Según el alcance o finalidad de propósito Especial: son diseñados y construidos

para una aplicación específica
cuando el rendimiento es de
primordial importancia.
Según el tipo de camino de acceso de que disponen para almacenar los archivos: una familia
muy conocida de DBMS se basan en estructuras de archivos invertidos.
Según el costo: los sistemas monousuario para computadores personales tiene un costo mucho
menor que los paquetes mucho más completos.
Aunque algunos serán tratados con detenimiento más adelante, resumimos la clasificación más
importante, analizando la primera clasificación. Los diversos modelos de datos propuestos son:
Pág. 30 de 141
Historia de los sistemas de bases de datos
Como se ha visto en este capítulo, los predecesores de los sistemas de bases de datos fueron
los sistemas de archivos tradicionales. No hay un momento concreto en que los sistemas de archivos
hayan cesado y hayan dado comienzo los sistemas de bases de datos.
De hecho, todavía existen sistemas de archivos en uso.
Comienzos de la década del ’60: Se dice que los sistemas de bases de datos tienen sus raíces en
el proyecto estadounidense Apolo de mandar al hombre a la luna, en los años sesenta. En aquella
época, no había ningún sistema que permitiera gestionar la inmensa cantidad de información que
requería el proyecto. La primera empresa encargada del proyecto, NAA (North American Aviation),
desarrolló un software denominado GUAM (General Update Access Method) que estaba basado en el
concepto de que varias piezas pequeñas se unen para formar una pieza más grande, y así
sucesivamente hasta que el producto final está ensamblado. Esta estructura, que tiene la forma de
un árbol, es lo que se denomina una estructura jerárquica.
A mediados de los ‘60: IBM se unió a NAA para desarrollar GUAM en lo que ahora se conoce como
IMS (Information Management System). El motivo por el cual IBM restringió IMS al manejo de
jerarquías de registros fue el de permitir el uso de dispositivos de almacenamiento serie, más
exactamente cintas magnéticas, ya q’ era un requisito del mercado por aquella época.
También en ésa época se desarrolló IDS (Integrated Data Store), de General Electric, trabajo dirigido
por uno de los pioneros en los sistemas de bases de datos, Charles Bachmann. IDS era un nuevo tipo
de sistema de bases de datos conocido como sistema de red, que produjo un gran efecto sobre los
sistemas de información de aquella generación. El sistema de red se desarrolló, en parte, para
satisfacer la necesidad de representar relaciones entre datos más complejas que las que se podían
modelar con los sistemas jerárquicos, y, en parte, para imponer un estándar de bases de datos. Para
ayudar a establecer dicho estándar, CODASYL (Conference on Data Systems Languages), formado
por representantes del gobierno de EEUU y representantes del mundo empresarial, formaron un
grupo denominado DBTG (Data Base Task Group), cuyo objetivo era definir unas especificaciones
estándar que permitieran la creación de bases y el manejo de los datos.
Principios de los ’70: El DBTG presentó su informe final en 1970 y aunque éste no fue
formalmente aceptado por ANSI (American National Standards Institute), muchos sistemas se
desarrollaron siguiendo la propuesta del DBTG. Estos sistemas son los que se conocen como
sistemas de red, o sistemas CODASYL o DBTG. Los sistemas jerárquico y de red constituyen la
primera generación de los SGBD. Pero estos sistemas presentan algunos inconvenientes: a) Es
necesario escribir complejos programas de aplicación para responder a cualquier tipo de consulta de
datos, por simple que ésta sea. b) La independencia de datos es mínima. c) No tienen un
fundamento teórico.
En 1971 Codd, de los laboratorios de investigación de IBM, escribió un artículo presentando el
modelo relacional. En este artículo, presentaba también los inconvenientes de los sistemas previos, el
jerárquico y el de red.
Entonces, se comenzaron a desarrollar muchos sistemas relacionales, apareciendo los primeros a
finales de los setenta y principios de los ochenta. a) Uno de los primeros es System R, de IBM, que
se desarrolló para probar la funcionalidad del modelo relacional, proporcionando una implementación
de sus estructuras de datos y sus operaciones. Esto condujo a dos desarrollos: El desarrollo de un
lenguaje de consultas estructurado denominado SQL, que se ha convertido en el lenguaje estándar
de los sistemas relacionales. b) La producción de varios DBMS relacionales durante los años ochenta,
como DB2 y SLQ/DS de IBM, y ORACLE de ORACLE Corporation.
A mediados de los ’70: En 1976, Chen presentó el modelo entidad-relación, que es la técnica más
utilizada en el diseño de bases de datos. En 1979, Codd intentó subsanar algunas de las
deficiencias de su modelo relacional con una versión extendida denominada RM/T (1979) y más
recientemente RM/V2 (1990). Los intentos de proporcionar un modelo de datos que represente al
mundo real de un modo más fiel han dado lugar a los modelos de datos semánticos.
Hoy en día, existen cientos de DBMS relacionales, tanto para microordenadores como para sistemas
multiusuario, aunque muchos no son completamente fieles al modelo relacional.
Pág. 31 de 141
CAPITULO II
El nivel interno
I ntroducción: Físicamente, las bases de datos casi siempre se almacenan en medios de

acceso directo, por lo regular discos magnéticos de cabeza móvil, aunque en algunos sistemas
pudieran utilizarse otros medios.
En estos dispositivos de almacenamiento secundario, la base de datos se organiza en uno o
varios archivos. Cada archivo está formado por una serie de registros, y cada registro se divide en
varios campos. Normalmente éstos archivos almacenados en disco se transfieren desde el disco a la
memoria principal a medida que se necesitan.
Evidentemente, los tiempos de acceso a disco son muchos más largos que los de acceso a
memoria principal, de hecho, el acceso a memoria principal será con toda probabilidad por lo menos
cuatro o cinco órdenes de magnitud más rápido que el acceso a disco de un sistema dado.
Los pasos que se deben llevar a cabo para almacenar y acceder a un registro de un
archivo es lo que se denomina un método de acceso. Hay distintos métodos de acceso,
algunos de los cuales sólo se pueden utilizar con determinadas estructuras de archivos.
No existe una sola estructura óptima para todas las aplicaciones. Algunas estructuras son
adecuadas para ciertas aplicaciones, otras son buenas para otras.
Se entiende por Estructura de almacenamiento a cualquier organización de los datos

en disco. Es posible desarrollar una gran cantidad de estructuras de almacenamiento
diferentes, y desde luego cada una de éstas tiene sus características de desempeño.
Por lo tanto, un buen sistema deberá poder utilizar varias estructuras distintas, a fin de
almacenar diferentes porciones de la base de datos en diversas formas, y deberá ser posible cambiar
la estructura de almacenamiento de una porción determinada cuando varíen o se comprendan mejor
los requerimientos de desempeño.
Por tanto, un objetivo prioritario de perfomance
(desempeño) en sistemas de bases de datos es reducir al
mínimo el número de accesos a disco (E/S a disco).
Pág. 32 de 141
Este capítulo se ocupa de las técnicas para lograr ése objetivo, es decir, técnicas para
organizar los datos almacenados en el disco de manera tal que un elemento de información
requerido, digamos un registro almacenado solicitado, se pueda localizar con un mínimo de E/S
Para ello es necesario comprender bien cómo se utilizará la base de datos, es decir, entender
a fondo las aplicaciones que se van a ejecutar con la base de datos y también la frecuencia relativa
de ejecución de ésas aplicaciones.
Se denomina Diseño físico de base de datos al proceso de elegir una representación

de almacenamiento apropiada para una cierta base de datos.
Sin embargo es igualmente importante incorporar las nociones básicas sobre el proceso
general de localizar y leer un registro específico en la base de datos almacenada, identificando los
principales componentes de software implicados en el mismo, entre ellos, el Manejador de Archivos y
el Manejador de Disco, temas que se abordan a continuación.
Proceso general de localizar y leer un registro
Localizar un elemento de información específico en la base de datos y presentarlo al usuario requiere

varios niveles de programas de acceso a datos. Por supuesto los detalles de ésos niveles varían en
forma apreciable en los distintos sistemas, pero los principios son bastante generales y pueden
explicarse de la siguiente manera:
1) En primer término el DBMS decide cuál registro almacenado se necesita, y pide al

manejador de archivos que extraiga ése registro. (En la práctica puede ser necesario extraer
un conjunto de varios registros y examinarlos en la memoria principal hasta encontrar el
que se busca)
2) A su vez el manejador de archivos decide cuál página contiene el registro deseado y pide al
manejador de disco que lea ésa página.
Una página es la unidad de E/S, es decir, la cantidad de datos transferidos entre el disco y
la memoria principal en un solo acceso a disco (2kb, 4kb, etc.) **
3) Por último, el manejador de disco determina la localización física de la página deseada en el

disco, y realiza la operación de E/S necesaria. (Sólo en el caso que la página requerida
estuviera ya en un área de almacenamiento temporal de la memoria principal como
resultado de una lectura anterior, no será necesario leerla otra vez).
DBMS
Solicita registro almacenado Devuelve registro almacenado
Manejador de
Archivos
Solicita página almacenada Devuelve página almacenada
Manejador
de Disco
Operación de E/S en disco Datos leídos del disco
Pág. 33 de 141
Dpto. Ciencias de la Computación BD
En términos generales, el DBMS percibe la base de datos como un conjunto de registros

almacenados, y el manejador de archivos apoya ésa percepción; el manejador de archivos, a su vez,
percibe la base de datos como un conjunto de páginas, y el manejador de disco apoya ésa
percepción. El manejador de disco percibe al disco “como es en realidad”.
El manejador de Disco es un componente del Sistema Operativo

subyacente. Es el encargado de todas las operaciones físicas de E/S.
El manejador de disco necesita conocer las direcciones físicas del disco. Sin embargo el
usuario del manejador de disco, o sea, el manejador de archivos no necesita conocer ésa
información, puesto que para éste el disco es tan solo una colección lógica de conjuntos de páginas,
cada uno de los cuales se compone de un grupo de páginas tamaño fijo.
** En este punto es adecuado completar brevemente el concepto de Página.
El conjunto completo de páginas del disco se divide en un grupo de subconjuntos sin

intersección llamados Conjuntos de páginas, entre los cuales está el conjunto de páginas del espacio
libre (reserva de páginas disponibles, -no utilizadas-) y los demás contienen datos significativos.
Cada conjunto de páginas se identifica mediante un identificador de conjuntos de páginas único, y
cada página, a su vez, se identifica mediante un número de página que es único dentro del disco.
El manejador de disco entiende y mantiene la correspondencia

entre números de página y direcciones físicas en el disco.
Es el responsable de la administración de páginas.
Una ventaja evidente de este arreglo es que todas las instrucciones codificadas específicas
para un dispositivo pueden aislarse dentro de un solo componente del sistema: el manejador de
disco y todos los componentes del nivel más alto (como el manejador de archivos) pueden ser
independientes del dispositivo.
Operaciones que puede realizar el manejador de disco con los conjuntos de páginas, o sea,
Operaciones que puede solicitar el manejador de archivos, son las siguientes:
 Leer la página p del conjunto de páginas C.

 Reemplazar la página p del conjunto de páginas C.
 Añadir una página nueva al conjunto de páginas C (es decir, obtener una página vacía del
conjunto de páginas del espacio libre y obtener el nuevo número de página p).
 Eliminar la página p del conjunto de páginas C ( es decir, volver la página p al conjunto de
páginas del espacio libre).
El manejador de Archivos utiliza los recursos del manejador de disco de

tal manera que su usuario  el DBMS, puede percibir el disco como un
conjunto de archivos almacenados.
Es el responsable de la administración de registros almacenados.
Cada conjunto de páginas contendrá uno o más archivos almacenados. Cada archivo
almacenado se identifica mediante un nombre de archivo o identificador de archivo, único, por lo
menos, en el conjunto de páginas que lo contiene, y cada registro almacenado, a su vez, se identifica
mediante un número de registro o identificador de registro único, al menos, dentro del archivo
almacenado que lo contiene.
Pág. 34 de 141
El DBMS sí necesita conocer que existen conjuntos de páginas, aunque no se encarga de

manejarlos en detalle, en particular, necesita saber cuándo dos registros almacenados comparten la
misma página, para evitar duplicación de accesos (la página ya estaría en RAM).
Operaciones que puede realizar el manejador de archivos con los archivos almacenados, o sea,
Operaciones que puede solicitar el DBMS, son las siguientes:
 Leer el registro almacenado r del archivo almacenado A.

 Reemplazar el registro almacenado r del archivo almacenado A.
 Añadir un registro nuevo al archivo almacenado A y devolver el nuevo identificador de
registro r).
 Eliminar el registro almacenado r del archivo almacenado A
 Crear un nuevo archivo almacenado A.
 Destruir el archivo almacenado A.
Con estas operaciones primitivas de manejo de archivos, el DBMS

es capaz de construir y manipular las estructuras de almacena-
miento mencionadas.
Administración de Páginas
El manejador de disco se encarga de los detalles de E/S
física del disco de modo que el manejador de archivos trabaje en términos de la E/S de páginas
(lógica). Para comprender mejor cómo funciona se analizará un ejemplo simplificado con tres
supuestos archivos: artículos, proveedores y solicitudes (pedidos). Otros supuestos:
o Cada registro almacenado requiere una página completa. (sólo es un ejemplo)

o El ordenamiento lógico deseado para cada archivo es numérico por la clave. Para los artículos
por número de artículo, para proveedores por número de proveedor y para las solicitudes por
número de artículo dentro de un orden por número de proveedor.
o Se observará el manejo del almacenamiento a través de una secuencia de eventos.
 Al principio la base de datos está vacía (sólo hay

páginas libres)
 Se solicita un conjunto de páginas para los registros

del proveedor.
Lo mismo sucede con las partes y los envíos
Pág.0 A1 A2 A3 A4 A5 Las páginas del 1 al 5 contienen

P1 P2 P3 P4 P5 P6 registros de artículos.
P1/A1 P1/A2 P1/A3 P1/A4 P1/A5 P1/A6 Las páginas del 6 al 11 contienen
registros de proveedores.
P2/A1 P2/A2 P3/A2 P4/A2 P4/A4 P4/A5
Las páginas del 12 al 23 contienen
registros de pedidos.
Las páginas restantes del 24 al 35
son páginas libres.
Pág. 35 de 141
 Luego se ingresa un nuevo registro de Artículo.

La primera página libre es la 24.
 Se elimina el registro del Artículo A2.
Se devuelve la página al conjunto de páginas libres.
 Se inserta un nuevo registro de Proveedor (P7).
La primera página libre es la 2
 Se elimina el registro almacenado del Artículo A4.
Se devuelve la página al conjunto de páginas libres.
Luego de todas estas operaciones realizadas por el manejador de archivos, la disposición es:
Pág.0 A1 P7 A3 -- A5
P1 P2 P3 P4 P5 P6
P1/A1 P1/A2 P1/A3 P1/A4 P1/A5 P1/A6
P2/A1 P2/A2 P3/A2 P4/A2 P4/A4 P4/A5
A6
Es posible comprender que al cabo de una buena cantidad de operaciones con los registros, ya no es
posible garantizar que las páginas adyacentes lógicamente sigan siendo adyacentes físicamente
(aunque así haya sido al principio).
Por esta razón, es preciso representar la secuencia lógica de páginas en un determinado

conjunto de páginas no mediante contigüidad física sino mediante “punteros”.
Veamos cómo sería en la representación anterior.
1 3 2 X 3 5 5 24
Pág.0 --
A1 P7 A3 A5
6 7 7 8 8 9 9 10 10 11 11 2
P1 P2 P3 P4 P5 P6
12 13 13 14 14 15 15 16 16 17 17 18
P1/A1 P1/A2 P1/A3 P1/A4 P1/A5 P1/A6

18 19 19 20 20 21 21 22 22 23 23 24
P2/A1 P2/A2 P3/A2 P4/A2 P4/A4 P4/A5

24 X
A6
 Cada página tendrá una cabecera de página, es decir, cierta información de control que incluye,
entre otras cosas, la dirección física en el disco de la página que sigue a ésta página dentro de la
secuencia lógica.
 Las cabeceras de página, en particular los punteros a la siguiente página, son administrados por
el manejador de disco (son invisibles para el manejador de archivos)
Pág. 36 de 141
 El manejador de disco casi siempre asigna páginas de conjuntos (no una por una como en el
ejemplo), es decir grupos físicamente contiguos. Esto permite que las páginas adyacentes
lógicamente estén lo más cerca posible de ser adyacentes lógicamente (como es conveniente).
 EL manejador de disco sólo precisa saber, entonces la dirección de la primera página (las
otras se conocen por los punteros dispuestos en las cabeceras de página). Esta información está
dispuesta en un lugar fijo del disco – la llamaremos página cero – y tiene la siguiente forma:
Conjunto de Dirección de la
Páginas primera página
Espacio libre 4
Artículos 1
Proveedores 6
Pedidos 12
El manejador de disco oculta detalles de E/S al Manejador de archivos que sólo ve páginas
lógicas, facilitando su labor. El manejador de archivos oculta detalles de E/S de páginas al
DBMS que sólo ve archivos y registros almacenados, facilitando su tarea.
Administración de Registros almacenados
E sta es la función del Manejador de archivos que facilita la tarea del DBMS, como se
señaló en el párrafo anterior. Para comprenderla someramente, recurrimos igualmente a un ejemplo,
que se acerca mucho más a la realidad. Supuestos:
o En una sola página caben varios registros almacenados.
o El archivo de Artículos y el ordenamiento deseado son los mismos del ejemplo anterior.
o La secuencia de acciones es la siguiente:
1. Se insertan los cinco registros de Artículos A1 a A5 y se graban juntos en alguna

página P, la cual todavía contiene espacios libres.
2. El DBMS inserta un nuevo registro de Artículo, por ejemplo, A9. El manejador de
archivos graba este registro en la página P (porque todavía hay espacio),
inmediatamente después del registro almacenado del artículo A5.
3. Luego se elimina el registro almacenado del Artículo A2. El Manejador de archivos
corre hacia arriba los registros de los artículos A3, A4, A5 y A9 para llenar el hueco.
4. El DBMS inserta un nuevo registro almacenado de Artículo para otro artículo A7. Se
graba nuevamente en la página P y se coloca inmediatamente después del registro
del Artículo A5, corriendo el registro del Artículo A9 hacia abajo para abrir un
espacio.
5. Y así sucesivamente.
El propósito del ejemplo es mostrar cómo la secuencia lógica de

registros almacenados dentro de cualquier página se puede
representar mediante la secuencia física dentro de ésa página.
Pág. 37 de 141
El manejador de archivos desplaza registros individuales hacia arriba y hacia abajo a fin de
lograr este objetivo manteniendo todos los registros de datos juntos en la parte superior de la página
y todo el espacio libre junto en la parte inferior.
Los registros almacenados se identifican internamente por su Identificador de registro, o
RID. El RID de un registro almacenado r se compone de dos partes: el número de la página P
donde está r, y un desplazamiento en bytes con respecto a la base de P, el cual identifica una ranura
que a su vez contiene el desplazamiento en bytes de r con respecto al tope de P.
Página P
Registro r
Desplazamiento con
Respecto a la base de la pág.
RID
de r
Núm. de página
Este sistema representa un buen equilibrio entre la velocidad de las direcciones directas y la
flexibilidad de las direcciones indirectas.
Los registros se pueden desplazar hacia arriba y hacia abajo dentro de su página, y sin
embargo el acceso a un registro determinado a partir de su RID es rápido, pues se requiere un solo
acceso de página.
Notas:
1. A consecuencia del análisis anterior, cualquier archivo almacenado siempre será posible un
acceso secuencial a todos los registros almacenados, donde Secuencial significa “secuencia
de registro almacenado dentro de una secuencia de página dentro de un conjunto de
páginas (o sea, en orden ascendente por RID).
2. El acceso secuencial a un archivo almacenado es posible aún cuando varios archivos

compartan el mismo número de páginas.
3. Por diversas razones un registro almacenado contiene a menudo, además de campos de

datos para el usuario, cierta información de control, denominada “prefijo de registro”. En
circunstancias normales esta información está oculta al usuario y puede estar referida al
identificador del archivo al cual pertenece el registro, un indicador de eliminación (para
efectuar eliminaciones lógicas), punteros, etc.
4. Los campos de datos para el usuario que se encuentran en el registro almacenado serán de
interés para el DBMS (para construir índices y otras tareas), pero no para el manejador de
archivos (ni para el manejador de disco).
Pág. 38 de 141
Agrupamiento
L a idea básica del agrupamiento es procurar almacenar juntos físicamente los registros que
tienen una relación lógica entre sí y que por eso se utilizan con frecuencia al mismo tiempo, lo cual
constituye un factor de importancia extrema para la perfomance o desempeño.
En muchas aplicaciones existen relaciones entre los registros de varios archivos distintos.
Estas relaciones se pueden representar mediante campos conectores. Por ejemplo, en el registro de
un empleado aparece un campo conector cuyo valor indica el código de la oficina a la que pertenece.
En el archivo de las oficinas, los registros tendrán un campo que será el código de oficina. Cuando se
quiere acceder a los campos de dos registros relacionados, por ejemplo, a los datos de un empleado
y los datos de su oficina, se debe acceder primero al registro del empleado y utilizar el campo
conector para obtener el registro con el que se relaciona en el archivo de las oficinas. De este modo,
las relaciones se están representando mediante referencias lógicas entre registros de distintos
archivos.
Cuando se utiliza el agrupamiento, se favorecen los accesos a través de la relación en la que
se basa dicho agrupamiento, pero se penalizan los accesos a través de cualquier otro campo., ya que
un archivo (o conjunto de archivos) puede agruparse físicamente en una y sólo una forma a la vez.
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 sí en la misma página cuando
sea posible y en páginas adyacentes cuando no lo sea. Por esta razón el DBMS debe saber acerca de
las páginas y no sólo de los archivos almacenados.
Un buen DBMS deberá permitir al DBA especificar diferentes clases de agrupamiento para
distintos archivos. También deberá permitir la modificación del agrupamiento de un archivo
determinado en caso de cambiar los requerimientos de perfomance. Desde luego, si ha de lograrse la
independencia de los datos, ninguno de estos cambios en el agrupamiento físico deberá requerir
cambios correspondientes en los programas de aplicación.
Además de lo expuesto, el resto del capítulo intenta explicar la idea fundamental de las
nociones de algunas de las estructuras de almacenamiento utilizadas con mayor frecuencia para
lograr “algo mejor” que la ruta de acceso por secuencia física en los sistemas como la Indexación,
Dispersión, Cadenas de Punteros y Técnicas de Compresión, desde un punto de vista conceptual, sin
demasiados detalles. Cabe aclarar que estas técnicas no deben considerarse mutuamente
excluyentes.
Indexación
L os índices son estructuras de acceso que se utilizan para acelerar el acceso a los registros
en respuesta a ciertas condiciones de búsqueda. Algunos tipos de índices, los denominados caminos
de acceso secundario, no afectan al emplazamiento físico de los registros en el disco y lo que hacen
es proporcionar caminos de acceso alternativos para encontrar los registros de modo eficiente
basándose en los campos de indexación.
El archivo en donde se encuentra el índice necesita muchos menos bloques que el archivo de
datos porque hay menos entradas que registros en el archivo de datos, y porque sus registros son
más pequeños que los del archivo de datos. Por lo tanto, una búsqueda binaria sobre el índice visita
menos bloques del disco que una búsqueda binaria sobre el archivo de datos.
Los tipo s de índices que más se utilizan son los que se basan en archivos ordenados (índices
de un solo nivel) y las estructuras en forma de árbol (índices multinivel, árboles B y árboles B+).
Además, los índices se pueden construir mediante dispersión u otras estructuras de datos, analizadas
más adelante.
Los índices tienen una ventaja primordial que es la velocidad de la obtención de datos,
sin embargo, existe una desventaja, a saber, se hace más lenta la actualización.
Pág. 39 de 141
Para indexar un campo será necesario responder a la siguiente pregunta: ¿Qué es más
importante, una eficiente recuperación de datos en base a los valores del campo en cuestión, o el
trabajo adicional de actualización requerido para lograr ésa eficiencia?
A.- Índices de un solo nivel
Los índices de un solo nivel están ordenados y son algo similar al índice de palabras de un
libro en donde cada palabra viene acompañada de una lista de números de página en donde aparece
la palabra. Para hacer una búsqueda se puede recurrir al índice o bien hacer una búsqueda lineal a lo
largo de todo el libro.
Un índice de un solo nivel es un archivo ordenado cuyos registros tienen dos campos: el
campo sobre el que se define el índice denominado campo de indexación (un campo de los registros
del archivo de datos) y una dirección de bloque en disco. Los valores del índice están ordenados, de
modo que se puede utilizar la búsqueda binaria.
Supongamos un archivo de Artículos y sus respectivas categorías, entre otros datos:
Bebidas A1 Atún al natural 20 Conservas

Conservas A2 Sorrentinos 15 Pastas
Granos A3 Leche descre. 32 Lácteos
Lácteos A4 Torta vienesa 10 Repostería
Pastas A5 Cerveza Norte 24 Bebidas
Repostería A6 Arroz Gallo x1k 18 Granos
El archivo de Categorías es un índice del archivo de Artículos, lo que equivale a decir que el
archivo de Artículos está indexado por este archivo según el campo categoría. Un índice es un tipo
especial de archivo almacenado.
En términos específicos, es un archivo en el cual cada entrada (reg.) se compone de sólo dos
valores, un DATO (que es la expresión que determina el ordenamiento) y un PUNTERO (RID).
¿Cómo se realizaría entonces esta tarea: “eliminar todos los registros de los artículos de la categoría
Bebidas”?
 Existen dos alternativas, donde la primera es muy simple, recorrer secuencialmente el archivo
preguntando en cada ocurrencia si el campo categoría contiene “bebidas”, o bien,
 Buscar en el archivo de categorías todos los registros de Bebidas, y para cada uno de ellos seguir
el puntero al registro correspondiente en el archivo de Artículos.
Hay varios tipos de índices de un solo nivel:

o Índices primarios
o Índices de agrupamiento
o Índices secundarios
A. 1- Índices Primarios
Cuando un archivo está ordenado por un campo de clave primaria (por ejemplo A#, que no
permite duplicación), el índice que se define sobre este campo es un índice primario.
Un índice primario es un archivo ordenado cuyos registros son de longitud fija y tienen dos
campos: el campo de ordenación del archivo de datos (hay un valor único de este campo para cada
registro) y un puntero a un bloque del disco (una dirección de bloque).
El campo de ordenación se suele denominar clave. Hay una entrada (registro) en el índice
por cada bloque del archivo de datos. Cada entrada tiene el valor de la clave del último registro del
bloque y un puntero a dicho bloque.
Pág. 40 de 141
Un índice primario organizado físicamente por la secuencia de la clave es un ejemplo de
índice no denso: hay una entrada por cada bloque de disco del archivo de datos, y no una entrada
por cada registro.
Nota
Indexación densa y no densa: si el objetivo fundamental de un índice es acelerar la obtención de
datos, es decir, reducir el número de E/S de disco para obtener un cierto registro almacenado, éste
objetivo se logra mediante el uso de punteros, que hasta ahora sólo apuntan a registros (RID). Un
índice denso contiene una entrada por cada registro del archivo de datos. Pero puede hacerse una
mejora si éstos fueran punteros de página.
Es muy importante darse cuenta que un cierto archivo almacenado sólo puede tener un
índice no denso, puesto que los índices de éste tipo dependen de la secuencia física (única) del
archivo en cuestión. Todos los demás índices deberán ser no densos por necesidad.
A. 2- Indices secundarios
Es un índice secundario todo aquel que se define sobre un campo de un archivo indexado
que no es el campo de clave primaria.
Un índice secundario también es un archivo ordenado con dos campos: el campo de
indexación (cualquier campo del archivo de datos que no es el de clave primaria) y un puntero a un
bloque o un puntero a un registro. Pueden definirse muchos índices secundarios sobre un mismo
archivo. Un índice de este tipo es un índice denso.
A. 3- Indices de agrupamiento
Si un archivo está ordenado por un campo no clave (que admite repetidos), un índice que se
define sobre este campo es un índice de agrupamiento, y al campo se le llama campo de
agrupamiento.
Se puede crear un índice distinto, un índice de agrupamiento, para acceder más rápido al
archivo a través de dicho campo. Un índice de agrupamiento es, también, un archivo ordenado con
dos campos: el campo de agrupamiento por el que está ordenado el archivo y un puntero a un
bloque de disco, por lo que también es un índice no denso.
 Hay una entrada en el índice por cada valor distinto del campo de agrupamiento, y el puntero
señala al primer bloque que contiene un registro con dicho valor. Nótese que la inserción y el
borrado de registros podrían ocasionar problemas, a menos que se reserve un bloque entero para
cada valor distinto. Si hacen falta más bloques para un valor, se añaden y se van enlazando. Esto
hace que la inserción y el borrado sean más simples.
Indexación según combinaciones de campos

También se puede construir un índice con base en los valores combinados de dos o más campos, por
ejemplo para Artículos por Categoría y Precio, donde el orden lo da el primer campo y ante iguales
ocurrencias para el mismo, se utiliza para ordenar el segundo campo. Y así sucesivamente en el
caso de ser varios los campos que componen el índice. Nótese que el número total de índices
necesarios para una indexación completa no es tan grande como podría parecer a primera vista.
B.- Índices multinivel
La razón para crear un índice es, en primer lugar, obviar la necesidad de una revisión física
secuencial del archivo indexado; si embargo, sigue siendo necesaria la revisión física secuencial del
archivo índice. Si el archivo indexado es de gran tamaño, el índice puede también llegar a ser muy
grande, y por tanto su revisión puede requerir bastante tiempo. Una solución es tratar al índice como
un archivo almacenado normal, y crear un índice para él (un índice para el índice. Cada nivel del
índice actúa como índice no denso del nivel inferior (debe ser no denso, por supuesto, pues de lo
contrario el problema persistiría); el nivel n tendría tantas entradas como el nivel n+1 y su revisión
ocuparía el mismo tiempo.
Este esquema multinivel se puede utilizar sobre cualquier tipo de índice, sea primario, de
agrupamiento o secundario, siempre que el primer nivel tenga valores distintos en el campo de
indexación y entradas de tamaño fijo.
Pág. 41 de 141
Cuando el índice del primer nivel es denso, se puede saber si existe un registro con un valor dado en
el campo de indexación (test de existencia) sin tener que acceder al archivo de datos, cosa que hay
que hacer siempre en un índice no denso.
Por ejemplo: responder a la consulta ¿Hay artículos de la categoría lácteos? La respuesta a esta
pregunta es afirmativa sí y sólo si existe una entrada para Lácteos en el archivo índice.
Por lo tanto los índices multinivel reducen el número de accesos a bloque cuando se busca
un registro a partir del valor de su campo de indexación.
Para mantener las ventajas que presentan los índices multinivel y reducir los problemas de las
inserciones y borrados, los diseñadores adoptan a menudo un índice multinivel que deja espacio en
cada uno de sus bloques para insertar nuevas entradas. Esto es lo que se denomina un índice
multinivel dinámico y se suele implementar mediante estructuras de datos denominadas árboles B y
árboles B+.
El árbol B es un tipo especial de índice con estructura de árbol. Los árboles B como tales
fueron descritos por primera vez en un artículo de Bayer y McCreight en 1972 y desde entonces
muchos investigadores han propuesto una cantidad de variaciones de la noción básica.
En la variación de Knuth, el índice tiene dos partes, el Conjunto Secuencia y el Conjunto
Indice.
 El conjunto secuencia consta de un índice de un solo nivel de los datos reales; en circunstancias
normales este índice es denso, pero podría ser no denso si el archivo indexado está agrupado
según el campo indexado.
Las entradas del índice, por supuesto, están agrupadas en páginas, y las páginas, por supuesto
están encadenadas entre sí, de manera que el orden lógico representado por el índice se obtiene
siguiendo las entradas en orden físico en la primera página de la cadena, seguidas de las
entradas en orden físico en la segunda página de la cadena, y así sucesivamente.
De esta manera, el conjunto secuencial permite un acceso secuencial rápido a los datos
indexados.
 El conjunto índice, a su vez, hace posible un acceso directo rápido al conjunto secuencia (y por
tanto también a los datos). El conjunto índice es en realidad un índice con estructura de árbol del
conjunto secuencia; de hecho, el conjunto índice es, en términos estrictos, el árbol B.
La combinación del conjunto índice y el conjunto

secuencia se denomina en ocasiones árbol B+.
El nivel superior del conjunto índice se compone de un solo nodo (es decir, una sola página,
pero desde luego con varias entradas de índice, como todos los demás nodos) que recibe el nombre
de RAIZ.
A continuación mostramos un ejemplo sencillo de árbol B:
50 82
12 32 58 70 89 94
------------------------------------------------------------------
6 8 12 15 18 32 35 40 50 51 52 58 60 62 70 71 78 82 83 85 89 91 93 94 96 97 99
Pág. 42 de 141
El árbol B (o sea, el conjunto índice) de esta figura no se ajusta mucho a una situación real
por estas dos razones:
 En circunstancias normales, no todos los nodos de un árbol B contienen el mismo número de

valores de datos.
 Sí contienen por lo regular una cierta cantidad de espacio libre.
Para buscar un valor V en la estructura de la figura, el algoritmo para el árbol general de

orden n es una simple generalización:
En general, “un árbol B de orden n” tiene por lo menos n pero no más de 2n valores de
datos en un nodo dado (y si tiene k valores de datos, tendrá por ende k+1 punteros).
Ningún valor de dato aparece más de una vez en el árbol.
sea N el nodo raíz;

repetir hasta que N sea un nodo de conjunto secuencia;
sean x,y los valores de datos en el nodo N /* x<y */;
si v <= x entonces hacer que N sea el nodo inferior izq. de N;
si x < v <= y ent. hacer que N sea el nodo inferior medio de N;
si v > y entonces hacer que N sea el nodo inferior derecho de N;
fin de la repetición;
si v ocurre en el nodo N entonces salir /* hallado */;
si v no ocurre en el nodo N entonces salir /* no hallado */;
 Un problema de las estructuras de árbol en general es que las inserciones y eliminaciones pueden
desequilibrar el árbol.
Un árbol está desequilibrado si los nodos hoja no están todos en el mismo nivel,
es decir, si diferentes nodos están a diferentes distancias del nodo raíz.
Como una búsqueda en el árbol requiere un acceso a disco por cada nodo visitado ( excepto
que en la práctica el nivel superior del índice, y partes del segundo nivel, se conservarán por regla general en la
memoria principal durante casi todo el procesamiento de la base de datos), los tiempos de búsqueda
pueden hacerse poco predecibles en un árbol desequilibrado.
La ventaja notable de los árboles B es que el algoritmo de inserción/eliminación garantiza

en todo momento el equilibrio del árbol.
Inserción de un nuevo valor
El algoritmo descrito atañe tan sólo al conjunto índice, dado que éste último es el árbol B
propiamente dicho; se requiere una extensión trivial para actualizar el conjunto secuencia también.
Pág. 43 de 141
Inicio
NO se busca en
el conjunto secuencia
Buscar un nodo N en el índice

(al cual pertenece v por lógica)
que esté en el nivel más bajo
Sí
N tiene
espacio libre?
V se inserta en él
El nodo N tiene No
2n valores
Dividir N en N1 y N2
Fin del proceso
Sea S el conjunto ordenado
formado por los 2n valores
originales, más el nuevo V,
en su secuencia lógica.
Los n valores más bajos de S
se colocan en el nodo izq. N1
Los n valores más altos de S

se colocan en el nodo derecho N2
W (el valor medio)

se promueve el valor padre de N (P)
y sirve como valor separador
de los nodos N1 y N2
Se intenta insertar W en P
En el peor de los casos, habrá una división continua hasta el nivel más alto del árbol; se creará un
nuevo nodo raíz (padre de la raíz anterior, la cual se habrá dividido ahora en dos), y la altura del
árbol aumentará un nivel (pero seguirá estando equilibrado).
Desde luego, el algoritmo de eliminación es en esencia el inverso del algoritmo de inserción descrito.
 La modificación de un valor se realiza eliminando el valor antiguo e insertando el nuevo.
Pág. 44 de 141
Dispersión
C onocida también como Direccionamiento por Dispersión, ésta es una técnica para
obtener acceso directo rápido a un registro almacenado específico con base en un valor dado para
un cierto campo. El campo en cuestión es con frecuencia, pero no por fuerza, la clave primaria.
En los archivos dispersos, la dirección de cada registro se calcula aplicando cierta
función sobre uno o varios de sus campos, denominados campos de dispersión. A la función se le
denomina función de dispersión. Los registros de este tipo de archivos parece que han sido
distribuidos de forma aleatoria por el mismo, por lo que a estos archivos también se les denomina
archivos aleatorios o archivos directos. El acceso a los datos es muy rápido sólo si se busca con la
condición de igualdad sobre el campo de dispersión.
La función de dispersión se debe escoger de modo

que los registros queden distribuidos uniformemente
en todo el archivo.
 La técnica más popular consiste en utilizar el resto de la división entera: se toma el valor de un
campo, se divide entre un valor determinado y se utiliza el resto de la división entera para
obtener la dirección en disco.
 Otra técnica es el plegado. Consiste en tomar distintas partes del campo de dispersión y
aplicarles alguna función aritmética. Por ejemplo, si el campo de dispersión es el DNI, se pueden
tomar sus dígitos por parejas y sumarlos. Si el campo tiene caracteres, se puede tomar su valor
ASCII para aplicar la operación aritmética.
En realidad, la función de dispersión produce un

número de bloque relativo. En una tabla que se
encuentra en la cabecera del archivo se convierte
este número en la dirección del bloque en el disco.
El problema que presentan la mayoría de las funciones de dispersión es que no garantizan

direcciones únicas, de modo que varios registros se asocian a una misma dirección de bloque. Si a
un bloque se asocian más registros de los que realmente caben, se producen colisiones que hay
que resolver. Los registros que se destinan a un mismo bloque se denominan sinónimos.
Hay varias técnicas para gestionar las colisiones:
 Direccionamiento abierto.
Cuando se produce una colisión, el sistema hace una búsqueda lineal a partir del bloque al
que iba destinado el registro para encontrar un hueco donde insertarlo. Si se llega al final del
archivo sin encontrar hueco, se continúa la búsqueda desde el principio.
 Encadenamiento.
En lugar de buscar un hueco libre, lo que se hace es disponer de una serie de bloques como
área de desborde. Cuando se produce una colisión, el registro se sitúa en el área de
desborde y mediante un puntero en el bloque colisionado, se apunta a la dirección del bloque
de desborde y la posición relativa del registro dentro del bloque. Además, todos los registros
que han colisionado en un mismo bloque se van encadenando mediante punteros.
Pág. 45 de 141
 Dispersión múltiple.
Consiste en utilizar una segunda función de dispersión cuando la primera ha producido una
colisión. El objetivo es producir una nueva dirección que no provoque colisión. Normalmente,
la segunda función da una dirección de bloque situada en un área de desborde.
Aunque la dispersión es el método de acceso directo más rápido a través del campo de
dispersión, no es muy útil cuando también se quiere acceder al archivo a través de otro campo. Ya
que la mayoría de las funciones de dispersión que se utilizan no mantienen el orden entre los
registros, tampoco es útil cuando se quiere leer los registros ordenadamente.
Buscar un registro a través de un campo que no es el de dispersión es tan caro como

buscar un registro en un archivo desordenado: es preciso realizar una búsqueda lineal.
A tener en cuenta...
 Para borrar un registro hay que eliminarlo del bloque en el que se encuentra.
 Si el bloque tiene una lista de desborde, se puede mover un registro de la lista al bloque.
 Si el registro a borrar está en la lista de desborde, sólo hay que eliminarlo de ella. En este
caso, será necesario mantener una lista enlazada de posiciones de desborde no utilizadas.
 Si al actualizar un registro se modifica el campo de dispersión, es muy probable que el registro

tenga que cambiar de posición, por lo que habrá que borrarlo e insertarlo de nuevo.
Otra desventaja  el espacio de almacenamiento es fijo, por lo cual es difícil que el archivo se
expanda o se comprima dinámicamente.
Si el archivo tiene bloques y en cada uno caben registros, como máximo se podrán almacenar
registros.
Si hay menos de registros  quedará espacio sin utilizar.
Si hay más de registros  habrá muchas colisiones

acceso sea más lento (habrá largas listas de desborde).
En este caso, puede ser preferible ampliar el espacio de
almacenamiento y cambiar a otra función de dispersión, lo que
implica que habrá que redistribuir todos los registros
(reorganizar el archivo).
Ya que el espacio de almacenamiento es fijo, a este tipo de dispersión se la denomina

dispersión estática.
Hay varios esquemas que tratan de remediar esta situación:

la dispersión dinámica y la dispersión extensible, que
almacenan una estructura de acceso además del archivo, y
la dispersión lineal, que no necesita dicha estructura.
En que consisten:
 Estas técnicas aprovechan el que las funciones de dispersión dan como resultado un valor
entero no negativo que, por tanto, se puede representar como un número binario.
 Los registros se distribuyen entre los bloques teniendo en cuenta los primeros bits de este
número, que se denomina valor de dispersión.
Pág. 46 de 141
Dispersión dinámica
Cuando se utiliza esta técnica, el número de bloques del archivo no es fijo, sino que crece y
disminuye conforme es necesario. El archivo puede empezar con un solo bloque y cuando éste se
llena, se toma un nuevo bloque. Los registros se distribuyen entre los dos bloques teniendo en
cuenta el primer bit de sus valores de dispersión. Los que tienen un 0 van a un bloque y los que
tienen un 1 van al otro. Además, se va formando un directorio con estructura de árbol binario que
tiene dos tipos de nodos:
 Nodos internos, que guían la búsqueda. Tienen un puntero izquierdo correspondiente al bit 0
y un puntero derecho correspondiente al bit 1.
 Nodos hoja, conteniendo el puntero al bloque de datos.
Para hacer una búsqueda se puede almacenar el directorio en memoria, a menos que sea
muy grande. Si no cabe en un bloque, habrá que distribuirlo en dos o más niveles.
Cada nodo interno puede tener también un puntero al padre. Se pueden utilizar
representaciones especiales de árboles binarios para reducir el espacio necesario para los tres
punteros (izquierdo, derecho y padre).
En general, un directorio de niveles puede necesitar hasta accesos a bloque para

alcanzar un registro.
Cuando un bloque se llena, se ``parte en dos" y los registros se redistribuyen según el

siguiente bit de su valor de dispersión. En este caso, el directorio se expande con un nuevo nodo
interno. Los niveles del árbol binario se expanden dinámicamente (nunca habrá más niveles que
número de bits hay en el valor de dispersión).
Si la función de dispersión distribuye los registros uniformemente, el árbol estará equilibrado.

Cuando un bloque se vacía, o si el número de registros en dos bloques vecinos cabe en un solo
bloque, el directorio pierde un nodo interno y los dos nodos hoja se combinan formando uno solo.
De este modo los niveles del árbol pueden disminuir dinámicamente.
Dispersión extensible
Básicamente podríamos sintetizar el método así:
 En la dispersión extensible el directorio es un vector de direcciones de bloque, donde
es la profundidad global del directorio. El entero formado por los primeros bits del valor
de dispersión es el índice que indica en qué entrada del vector se encuentra la dirección del
bloque que contiene al registro.
 Puede haber varias entradas en el directorio con los primeros bits en común (d’ < d)
apuntando al mismo bloque cuando los registros que van a parar a ellas caben en dicho
bloque.
 Cada bloque tiene una profundidad local (que se almacena con él), que especifica el
número de bits que tienen en común los valores de dispersión de los registros que en él se
encuentran.
 El valor de puede incrementarse o disminuirse en una unidad cada vez que se necesita
doblar o disminuir a la mitad el número de entradas en el vector directorio. Es necesario
doblar el directorio si un bloque con profundidad local , igual a la profundidad global ,
se llena.
Pág. 47 de 141
 El directorio se disminuye a la mitad si d > d’ para todos los bloques después de borrar algún
registro. Como mucho, son necesarios dos accesos a bloque para llegar a cualquier registro
(acceso al directorio y acceso al bloque que contiene el registro).
ítems de comparación Dispersión Dinámica Dispersión extensible
Directorio Estructura enlazada Arbol perfecto (se puede expresar

como un vector)
Crecimiento del directorio Crece más lentamente Va doblando su tamaño
Espacio de almacenamiento Los nodos deben almacenar Si el directorio se hace lo suficien-

punteros a los hijos (el doble de temente grande como para nece-
grande que la extensible). sitar memoria virtual, la dispersión
Como ésta utiliza una estructura extensible ofrece la ventaja de que
enlazada para el directorio, se puede acceder al directorio con
puede que se produzca más de no más de un fallo de página.
un fallo de página al moverse por
el mismo.
Dispersión lineal
El objetivo de la dispersión lineal es que el archivo pueda crecer y disminuir sin tener que
utilizar un directorio. Así se ahorra el tiempo extra que los anteriores tipos de dispersión necesitan
para acceder al directorio.
Supongamos que un archivo empieza con bloques, numerados ,
y utiliza la función de dispersión , a la que se denomina función inicial .
Cuando hay colisiones se utilizan listas de desborde, una lista para cada bloque. Además,
después de una colisión, uno de los bloques del archivo se parte en dos y no es necesariamente el
bloque en el que ha ocurrido la colisión.
Por ejemplo, se produce la primera colisión. Se inicia una lista de desborde asociada al bloque
colisionado y, además, el primer bloque del archivo, el bloque , se parte en dos bloques: el original
(bloque ) y uno nuevo al final del archivo (bloque ).
Los registros del bloque original se distribuyen entre los dos bloques utilizando una función de
dispersión diferente.
Pág. 48 de 141
CAPITULO III
Modelado Conceptual: El modelo Entidad-Relación

Introducción  Metodología de Diseño de Bases de Datos
El diseño de una base de datos es un proceso complejo que abarca decisiones a muy
distintos niveles, donde el concepto de Modelo de Datos es prioritario.
La complejidad se controla mejor si se descompone el problema en subproblemas y se

resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el
diseño de una base de datos se descompone en diseño conceptual, diseño convencional o lógico y
diseño físico (que como ya vimos no es tarea de los usuarios del DBMS).
Los modelos conceptuales se utilizan para representar la realidad a un alto nivel de
abstracción. Mediante los modelos conceptuales se puede construir una descripción de la realidad
fácil de entender.
Pág. 49 de 141
En los modelos lógicos, las descripciones de los datos tienen una correspondencia sencilla con la
estructura física de la base de datos.
En el diseño de bases de datos se usan primero los modelos conceptuales para lograr una
descripción de alto nivel de la realidad, y luego se transforma el esquema conceptual en un esquema
lógico. El motivo de realizar estas dos etapas es la dificultad de abstraer la estructura de una base de
datos que presente cierta complejidad. Un esquema es un conjunto de representaciones lingüísticas
o gráficas que describen la estructura de los datos de interés.
 Retomando la terminología y los conceptos del primer capítulo, recordemos que

el diseño lógico parte del esquema conceptual y da como resultado un esquema
lógico. Un esquema lógico es una descripción de la estructura de la base de
datos en términos de las estructuras de datos que puede procesar un tipo de
DBMS. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos
(modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de
DBMS que se vaya a utilizar, no depende del producto concreto.
El diseño conceptual parte de las especificaciones de requisitos de usuario y su

resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción
de alto nivel de la estructura de la base de datos, independientemente del DBMS que se vaya a
utilizar para manipularla.
Un modelo conceptual es un lenguaje que se utiliza

para describir esquemas conceptuales.
En general, un modelo no es capaz de expresar todas las propiedades de una

realidad determinada, por lo que hay que añadir aserciones que complementen el esquema.
Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por
lo que deben poseer las siguientes cualidades:
 Expresividad: deben tener suficientes conceptos para expresar perfectamente la realidad.

 Simplicidad: deben ser simples para que los esquemas sean fáciles de entender.
 Minimalidad: cada concepto debe tener un significado distinto.
 Formalidad: todos los conceptos deben tener una interpretación única, precisa y bien definida.
Pág. 50 de 141
ENTIDAD-RELACION
Propuesto por Chen en dos artículos ya históricos, en 1976 y 1977, el modelo
Entidad-Relación es el modelo conceptual más utilizado para el diseño conceptual
de bases de datos. Está formado por un conjunto de conceptos que permiten describir la
realidad mediante un conjunto de representaciones gráficas y lingüísticas.
Según Chen, “El Modelo E/R puede ser usado como una base para una vista unificada de los
datos”, adoptando “el enfoque más natural del mundo real que consiste en entidades y relaciones”.
Posteriormente otros autores lo han ampliado con importantes aportaciones, formándose en realidad
una familia de MD’s. En este tema vamos a exponer tanto los conceptos del modelo E/R básico,
como el modelo E/R extendido.
El Modelo E/R ha tenido una gran difusión en la comunidad informática dedicada a las BD,
prueba de ello es que ha sido el modelo más extendido en las herramientas CASE de ayuda al
diseño. En esencia, este modelo consiste en buscar las entidades que describan los objetos que
intervienen en el problema y las relaciones entre esas entidades. Todo esto se plasma en un
esquema gráfico que tiene por objeto, por una parte, ayudar al programador durante la codificación
y por otra, al usuario a comprender el problema y el funcionamiento del programa.
Entre las características del modelo, podemos destacar que es una excelente herramienta de
comunicación entre usuarios y desarrolladores, y es ideal para el modelado de sistemas de
envergadura. Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad,
relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las
jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido.
En el Modelo E/R, tal como fue propuesto por Chen, se distinguen los siguientes elementos
para la componente estática:
� Entidad (entity),
� Interrelación (relationship),
� Dominio (domain), y
� Atributo (atribute).
Entidad  Es un objeto del mundo real.

Mundo real Modelo de la realidad
PERSONA
CLASIFICACIÓN
COCHE
Es cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona,
concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios,
diseños de productos, conciertos, excursiones, etc.
Definiciones formales de Entidad:
 “Cualquier objeto (real o abstracto) que existe en la realidad y acerca del cual queremos
almacenar información en la base de datos”.
Pág. 51 de 141
 “Algo con realidad objetiva que existe o puede ser pensado”; Hall (1976).
 “Una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para la
empresa”.
En otra dimensión, también debemos distinguir entre:
 La extensión o conjunto de ejemplares de un tipo de entidad en un momento dado; y

 La intensión que es el tipo de entidad propiamente dicho. Chen le llamó conjunto de
entidades (entity set).
Una entidad pertenece a un tipo de entidad si cumple el predicado asociado a ese tipo de entidad.
Matemáticamente, un conjunto de ejemplares de un

tipo de entidad se define como:
{ e : p(E) } siendo e un ejemplar del tipo de

entidad E y p el predicado asociado a E.
 Ejemplo: el tipo de entidad PROFESOR, cuyo predicado asociado es “Persona que ejerce o
enseña una materia o arte” tiene un ejemplar “Sánchez” que pertenece a él si cumple dicho
predicado.
Tipo o conjunto de entidades  Es la clase o tipo al que pertenecen entidades con características
comunes. (Grupos de entidades con los mismos atributos)
Cada individuo puede pertenecer a diferentes conjuntos: habitantes de un país, empleados
de una empresa, miembros de una lista de correo, etc. Con los vehículos pasa algo similar, pueden
pertenecer a conjuntos como un parque móvil, vehículos de empresa, etc.
 El tipo de entidades o estructura genérica que describe un conjunto de

entidades aplicando la abstracción de clasificación; y
 Las entidades o ejemplares de ese tipo de entidad; por tanto, el tipo de
entidad es el resultado de la clasificación de un conjunto de entidades.
En el modelado de bases de datos trabajaremos con conjuntos de entidades, y no con

entidades individuales. La idea es generalizar de modo que el modelo se ajuste a las diferentes
situaciones por las que pasará el proceso modelado a lo largo de su vida. Será el usuario final de la
base de datos el que trabaje con entidades. Esas entidades constituirán los datos que manejará con
la ayuda de la base de datos.
Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el

interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.
Existen dos categorías de tipos de entidades:
 Regulares o fuertes, que son aquellas cuyos ejemplares tienen existencia por sí mismos
(como LIBRO y AUTOR), y
 Débiles, en las cuales la existencia de un ejemplar depende de que exista un cierto

ejemplar de otro tipo de entidad:
Pág. 52 de 141
 Ejemplo: EJEMPLAR depende de LIBRO, y por tanto, la desaparición de un determinado libro

de la base de datos hace que desaparezcan también todos los ejemplares de dicho libro.
Problema para identificarlas
Uno de los problemas que existirán en el diseño E/R es la decisión de si un determinado objeto o
concepto se modela como un tipo de entidad o no.
 Ejemplo: el Color es habitualmente una propiedad de una entidad (como es el caso del color de
un coche), pero en una fábrica de pinturas probablemente sería apropiado modelar el color como
una entidad con sus propias propiedades.
Por esta razón, algunos autores han intentado precisar el concepto de entidad. Así, TARDIEU et al.
(1979) proponen tres reglas generales que debe cumplir una entidad:
 tiene que tener existencia propia,
 cada ejemplar de un tipo de entidad debe poder distinguirse de las demás, y
 todos los ejemplares de un tipo de entidad deben tener las mismas propiedades.
Pero ...
o La primera de estas reglas no es aplicable a las entidades débiles.
o La segunda supone la obligación de un identificador que permita distinguir los
distintos ejemplares de un tipo de entidad, lo que tampoco es universalmente aceptado
(ni por los autores, ni por los modelos, ni por los productos). Y
o La tercera es relativa: ¿exactamente las mismas?, ¿las mismas entre las que nos
interesan?, ...
Relación o Vínculo (interrelación)
Se entiende por interrelación una asociación, vinculación o correspondencia entre entidades.
Igual que en el caso de las entidades, distinguiremos entre
 El tipo de relación (interrelación) o estructura genérica que

describe un conjunto de interrelaciones, y
 Cada relación (interrelación), es decir, cada uno de los
ejemplares concretos.
 Ejemplo: IMPARTE es un tipo de relación que vincula los tipos de entidad PROFESOR y
CURSO; un ejemplar del tipo de relación IMPARTE es la vinculación entre el profesor “Sánchez” y
el curso “Diseño de Bases de Datos Relacionales”.
Definiciones formales de Relación:
Cada relación tiene un nombre que describe su función (generalmente se usan verbos para
nombrarlas). Las entidades que están involucradas en una determinada relación se denominan
entidades participantes. Definición Formal:
Pág. 53 de 141
Si E1,E2, ..., En son conjuntos de entidades, entonces el

conjuntos de relaciones R es un subconjunto de
{(e1, e2 ,..., en)| e1 E1, e2 E2 ,........, en En} donde
(e1, e2 ,..., en) es una relación.
Atributo  propiedad específica de la entidad que describe.
Alumno DNI
Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos
representan las propiedades básicas de las entidades y de las relaciones. Toda la información
extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan
de las entidades o relaciones a las que pertenecen.
Definición Formal:
 Cada una de las propiedades o características que tiene un tipo de entidad o un tipo de relación.
Los atributos toman valores de uno o varios dominios (si es compuesto).
A diferencia de los dominios que existen por sí mismos, la existencia de un atributo está ligada a
la del correspondiente tipo (de entidad o de interrelación).
Pág. 54 de 141
Matemáticamente, un atributo consiste en una función de un tipo de

entidad o de interrelación sobre todos los posibles subconjuntos de los
valores de un dominio (o de un conjunto de dominios):
� A : E → S(D) ó A : E → S(D1) x S(D2) x ... x S(Dn)
� A : I → S(D) ó A : I → S(D1) x S(D2) x ... x S(Dn)
donde A es el atributo, S(Di) todos los posibles subconjuntos de los
valores de los dominios, E el tipo de entidad e I el tipo de interrelación.
Cada atributo tiene un conjunto de valores asociados denominado dominio.
Dominio  El dominio define todos los valores posibles que puede tomar un
atributo. Puede haber varios atributos definidos sobre un mismo
dominio.
Definición Formal de Dominio

 Un dominio se define como un conjunto de valores homogéneos con un nombre que lo
identifica.
 Un dominio lleva siempre asociado un predicado que permite comprobar si un determinado valor
pertenece al dominio; D = { vi : p(vi) } donde D es el dominio, vi es un valor y p es el predicado
asociado a dicho dominio.
Un dominio puede definirse:

 por intensión, especificando el tipo de datos (por
ejemplo, carácter 30 para el Nombre); o por
 extensión, enumerando los valores que
pertenecen al dominio (por ejemplo, los días de la
semana).
Pág. 55 de 141
Tipos de Atributos:
 Un atributo simple es un atributo que tiene un solo componente, que no se puede dividir en
partes más pequeñas que tengan un significado propio. Valor sencillo o atómico.
 Un atributo compuesto es un atributo con varios componentes, cada uno con un significado por
sí mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen
afinidad en cuanto a su significado, o en cuanto a su uso.
Domicilio Calle
Dirección
Número
Ciudad
 Un atributo monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o
relación a la que pertenece.
 Un atributo multivaluado es aquel que tiene varios valores para cada ocurrencia de la entidad o
relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden
tener un número máximo y un número mínimo de valores. (Por ej. (una persona puede tener
más de un teléfono, o precio si depende de la forma de pago).
 Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un
valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente
deben pertenecer a la misma entidad o relación.
Fecha_nac
Alumno
Edad
A tener en cuenta…
Opcionales: Por otro lado, puede obligarse a un atributo de un tipo de
entidad a que tome, como mínimo, un valor del (o de los) dominio(s)
subyacente(s) para cada ejemplar de entidad, es decir, el valor de ese
atributo es obligatorio (no puede ser nulo) para todo ejemplar de la entidad.
Pág. 56 de 141
Existe un atributo que es especial porque permite identificar a un tipo de entidades,

normalmente denominado, precisamente Identificador o Atributo clave de un tipo de entidades:
Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único
cada ocurrencia de esa entidad (unívocamente). Un identificador de una entidad debe cumplir dos
condiciones:
1. No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.
2. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las
relaciones no tienen identificadores.
Representación de entidades y relaciones: Diagramas
No hay unanimidad total con respecto a la representación de diagramas E-R, he encontrado

algunas discrepancias en los distintos documentos que he consultado, dependiendo de la variedad
concreta del modelo que usen. Pero a grandes rasgos todos están de acuerdo en lo que
expondremos aquí.
Entidad: Las entidades se representan con un rectángulo, y en su interior el nombre de la entidad:
Las entidades débiles pueden representarse mediante dos rectángulos inscritos. Ya sabemos que
existe una dependencia de existencia entre la entidad débil y la fuerte, esto se representa también
añadiendo una flecha a la línea que llega a la entidad débil.
Atributo: Los atributos se representan mediante elipses, y en su interior el nombre del atributo:
Para indicar que cierto atributo es una clave (identificador), se debe subrayar el nombre del atributo.
También es frecuente usar una doble elipse para indicar atributos multivaluados:
Relación o Vínculo: Las relaciones se representan mediante rombos, y en su interior el nombre de la

relación:
Pág. 57 de 141
En los extremos de las líneas que parten del rombo se añaden unos números que indican la cantidad
de entidades que intervienten en la interrelación: 1, n. Esto también se suele hacer modificando el
extremo de las líneas. Si terminan con un extremo involucran a una entidad, si terminan en varios
extremos, (generalmente tres), involucrarán a varias entidades:
El Diagrama
Un diagrama E-R consiste en representar mediante estas figuras un modelo completo del problema,
proceso o realidad a describir, de forma que se definan tanto las entidades que lo componen, como
las interrelaciones que existen entre ellas.
La idea es simple, aparentemente, pero a la hora de construir modelos sobre realidades concretas es
cuando surgen los problemas. La realidad es siempre compleja. Las entidades tienen muchos
atributos diferentes, de los cuales debemos aprender a elegir sólo los que necesitemos. Lo mismo
cabe decir de las interrelaciones. Además, no siempre está perfectamente claro qué es un atributo y
qué una entidad; o que ventajas obtenemos si tratamos a ciertos atributos como entidades y
viceversa.
Al final, nuestra mejor arma es la práctica. Cuantos más problemas diferentes modelemos más
aprenderemos sobre el proceso y sobre los problemas que pueden surgir. Podremos aplicar la
experiencia obtenida en otros proyectos, y, si no reducir el tiempo empleado en el modelado, al
menos sí reducir los retoques posteriores, el mantenimiento y el tiempo necesario para realizar
modificaciones sobre el modelo.
Construir un modelo E-R

Podemos dividir el proceso de construir un modelo E-R en varias tareas más simples. El proceso
completo es iterativo, es decir, una vez terminado debemos volver al comienzo, repasar el modelo
obtenido y, probablemente, modificarlo. Una vez satisfechos con el resultado (tanto nosotros, los
programadores, como el cliente), será el momento de pasar a la siguiente fase: el modelo lógico.
Uno de los primeros problemas con que nos encontraremos será decidir qué son entidades y qué
atributos. La regla principal es que una entidad sólo debe contener información sobre un único
objeto real.
Otro problema frecuente se presenta con los atributos multivaluados. Por ejemplo, cada persona
puede ser localizada en varios números de teléfono. Considerando el teléfono de contacto como un
atributo de persona, podemos afirmar que tal atributo es multivaluado.
Pero, aunque como su propio nombre indica no dejan de ser atributos, es mejor considerar a los
atributos multivaluados como entidades débiles subordinadas. Esto nos evitará muchos problemas
con el modelo lógico relacional.
Pág. 58 de 141
Consideraciones: A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos
problemas, denominados trampas, suelen producirse a causa de una mala interpretación en el
significado de alguna relación, por lo que es importante comprobar que el esquema conceptual
parece de dichas trampas. En general, para encontrar las trampas, hay que asegurarse de que se
entiende completamente el significado de cada relación. Si no se entienden las relaciones, se
puede crear un esquema que no represente fielmente la realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una
relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de
resolverla es reestructurando el esquema para representar la asociación entre las entidades
correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre
entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso,
se produce una pérdida de información que se puede subsanar introduciendo la relación que sugería
el esquema y que no estaba representada.
Otros Conceptos
Dos: Binaria,
Tres: Ternaria,
etc.
Cardinalidad
Grado de un Tipo de Vínculo  Es el número de participantes en una relación; generalmente

se intenta utilizar la relación de grado 2 (binaria). L ternaria no es aconsejable por la dificultad
que ocasiona para establecer la cardinalidad.
Cardinalidad  con la que una entidad participa en una relación especifica el número mínimo y
el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha
entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de
cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra
entidad participante. Si no, la participación es opcional (parcial).
Participación  asociación entre conjuntos de entidades.
Pág. 59 de 141
Formalmente decimos que el conjunto de entidades E1, E2, ....,En participan en el conjunto de
relaciones R. En el ejemplo gráfico de relación binaria leemos:
 El conjunto de entidades Cliente y el conjunto de entidades Cuenta participa en el vínculo

TIENE.
a) Grados de Participación: especifica si la existencia de una entidad depende de que esté

relacionada con otra entidad a través del tipo de vínculo. Esta puede ser Total o Parcial
Participación Total  toda entidad de A está relacionada con una entidad de B por el
vínculo.
Simple Doble
A R B
Participación total de B en R.
Participación Parcial  parte del conjunto de entidades A está relacionado con una entidad
del conjunto de entidades B, pero no todas.
Papel o Rol  todo tipo de entidades que participe en un tipo de vínculo desempeña un
papel en él.
El nombre del papel indica el rol que un tipo de entidades participante del
tipo desempeña en cada ejemplar de relación. Muchas veces es importante
indicar el rol, es decir, la función que desempeña un tipo de entidad en
una interrelación.
Los roles suelen ser implícitos y no se especifican, pero pueden ser útiles
si se necesita aclarar el significado de una interrelación.
Un caso típico en que se necesita precisar el rol de cada tipo de entidad

participante es cuando existe una interrelación recursiva (un tipo de
entidad asociado consigo mismo, es decir donde cada conjunto de
entidades participa más de una vez con distintos papeles).);
 Ejemplo, si tenemos el tipo de interrelación MADRE_DE, en el cual participa

repetido dos veces el tipo de entidad PERSONA; cada elemento del conjunto de
interrelaciones MADRE_DE es del tipo (p1, p2) siendo pi instancias de tipo
PERSONA. En este caso se hace necesario indicar el papel de cada entidad
participante, es decir, indicar que p1 es el hijo y p2 es la madre o viceversa.
Pág. 60 de 141
Restricciones
 Restricciones inherentes al modelo:

 Sólo permite establecer interrelaciones entre entidades, no estando admitidas
entre entidades e interrelaciones ni entre interrelaciones.
 Restricciones de integridad: Únicamente consideramos las restricciones específicas,

distinguiendo entre:
1) Las restricciones sobre valores, que se establecen mediante la
definición de dominio.
2) Las restricciones estructurales, que se refieren a:

a) Atributos:
(i) Identificadores
(ii) Cardinalidades
b) Interrelaciones:
Las restricciones sobre un tipo de relación limitan las posibles
combinaciones de entidades que pueden participar en los ejemplares
de vínculos. Veamos cuáles pueden ser las restricciones
estructurales de un tipo de relación:
(i) Cardinalidades mínima y máxima

(ii) Dependencias en existencia y en identificación
(iii) Otras restricciones
Restricciones de Integridad Estructurales
a).(i) Referidas a Atributos Identificadores

Entre todos los atributos de un tipo de entidad han de existir uno o varios conjuntos de
atributos (simples y/o compuestos) que identifiquen unívocamente cada una de los ejemplares de
ese tipo de entidad. Cada uno de estos conjuntos de atributos se denomina Identificador
Candidato (IC).
Todo IC debe cumplir la condición de ser unívoco y mínimo: cuando un IC es
compuesto, el número de los atributos que lo componen debe ser mínimo, en el sentido de que la
eliminación de cualquiera de ellos le haría perder su carácter de identificador.
Entre los IC se elige uno como Identificador Principal (IP) y el resto serán identificadores
Alternativos (IA).
Estaremos de acuerdo en que es muy importante poder identificar claramente cada entidad y
cada relación. Esto es necesario para poder referirnos a cada elemento de un conjunto de entidades
o relaciones, ya sea para consultarlo, modificarlo o borrarlo. No deben existir ambigüedades en ese
sentido. En principio, cada entidad se puede distinguir de otra por sus atributos. Aunque un
subconjunto de atributos puedan ser iguales en entidades distintas, el conjunto completo de todos
los atributos no se puede repetir nunca. Pero a menudo son sólo ciertos subconjuntos de atributos
los que son diferentes para todas las entidades.
Un ejemplo de identificador es el atributo "DNI" que, en la entidad

"EMPLEADOS" o “ALUMNOS”, identifica de forma única a cada uno de las
ocurrencias. Estos identificadores reciben en nombre de Identificador
Principal (IP) o Clave Primaria (PK-Primary Key-). Se puede dar el caso de
existir algún identificador más en la entidad, a estos se les denomina
Identificadores Candidatos (IC).
Pág. 61 de 141
Claves candidatas
Una característica que debemos buscar siempre en las claves es que contengan el número mínimo de
atributos, siempre que mantengan su función. Diremos que una clave es mínima cuando si se elimina
cualquiera de los atributos que la componen, deja de ser clave. Si en una entidad existe más de una
de estas claves mínimas, cada una de ellas es una clave candidata.
Clave principal
Si disponemos de varias claves candidatas no usaremos cualquiera de ellas según la ocasión. Esto
sería fuente de errores, de modo que siempre usaremos la misma clave candidata para identificar la
entidad. La clave principal (o primaria) es una clave candidata elegida de forma arbitraria, que
usaremos siempre para identificar una entidad.
Conclusión: Se usará el término clave primaria para denotar una clave

candidata que elige el diseñador de la base de datos como el medio principal de
identificar entidades dentro de un conjunto de entidades.
Es posible que un conjunto de entidades no tenga atributos suficientes para formar una clave
primaria. Un conjunto de entidades de este tipo se denomina Conjunto de Entidades Débiles.
a).(ii) Referidas a Cardinalidades de Atributos
Es necesario recordar los conceptos de atributos mono y multivaluados, y de opcionalidad:
b).(i) Referidas a Cardinalidades de Relaciones

Es decir, la cardinalidad es una restricción que dice cuántas entidades de
un conjunto están relacionadas con cuántas entidades del otro conjunto.
Y depende del dominio que estoy modelando!!!
Cardinalidad Máxima  se pregunta por el máximo (a los sumo).
1:1 – Una entidad del conjunto A se relaciona, a lo sumo, con una entidad del conjunto B.
1:N – Una entidad del conjunto A puede estar relacionada con “n” (varias) entidades del
conjunto B, mientras que cada entidad de B está relacionada con una entidad de A.
N:N – Cada entidad del conjunto A puede estar relacionada con “n” entidades de B y viceversa.
Cardinalidad Mínima  se pregunta por el mínimo (al menos).

(asociado al concepto de relaciones mandatorias  aquellas cuya cardinalidad mínima es 1)
1:0 – Una entidad de A puede relacionarse con una entidad del conjunto B o con ninguna.
0:1 – Una entidad de B puede relacionarse con una entidad del conjunto A o con ninguna.
0:0 – No tiene sentido pues implicaría que no existe relación.
Pág. 62 de 141
Uno a Uno
ADMINISTRA
juego
EMPLEADO
juego DEPARTAMENTO
r1 juego

e1 
e2 
e3   d1
r2
e4 
 d2

e5  r3  d3

e6 
e7 
Uno a muchos
TRABAJA_PARA
juego
EMPLEADO
juego DEPARTAMENTO
r1 juego

e1 
r2
e2  
r3
e3   d1

e4 
r4  d2

e5  r5  d3

e6  r6

e7 
r7

Muchos a muchos
TRABAJA_EN
juego
EMPLEADO
juego PROYECTO
r1 juego

e1 
r2
e2  
r3
e3   p1

e4 
r4  p2

r5  p3

r6

r7

Pág. 63 de 141
b).(ii) Referidas a Dependencias en Existencia y en Identificación
Los tipos de interrelación se clasifican también en regulares y débiles, según estén

asociando dos tipos de entidad regulares, o un tipo de entidad débil con un tipo de entidad (regular o
débil), respectivamente.
Un miembro de un conjunto de entidades fuertes es por definición una entidad dominante

mientras que un miembro de un conjunto de entidades débiles es una entidad subordinada.
Dentro del tipo de interrelación débil, se distinguen dos tipos especiales:
Dependencia en existencia:
los ejemplares de un tipo de
entidad (débil) no pueden existir
si desaparece el ejemplar del
tipo de entidad regular del cual
dependen.
Decimos que existe una
dependencia de existencia entre
una entidad, subordinada, y
otra, dominante, cuando la
eliminación de la entidad
dominante, conlleva también la
eliminación de la entidad o
entidades subordinadas.
Dependencia en identifica-
ción: además de cumplirse la
condición anterior, los ejempla-
res del tipo de entidad débil se
identifican mediante atributos
propios+el IP del tipo de enti-
dad regular del cual dependen.
Una dependencia en identificación es siempre una dependencia en existencia.
Entidades fuertes y débiles

A menudo la clave de una entidad está ligada a la clave principal de otra, aún sin tratarse de una
interrelación. Por ejemplo, supongamos una entidad viaje, que usa la clave de un vehículo y añade
otros atributos como origen, destino, fecha, distancia; decimos que la entidad viaje es una entidad
débil, en contraposición a la entidad vehículo, que es una entidad fuerte.
El discriminador de un conjunto de entidades débil es un conjunto de atributos que permite que se
haga una distinción. Por ejemplo: el discriminador del conjunto de entidades débil “transacción” es
el atributo #trans, ya que para cada cuenta, un número de transacción identifica de forma unívoca
una única transacción.
La clave primaria de un conjunto de entidades débiles está formada por

la clave primaria del conjunto de entidades fuertes de la cual depende su
existencia, conjuntamente a su propio discriminador.
Pág. 64 de 141
Modelo ER-Extendido: Entidades Compuestas
Desde fines de los años ’70, se han generalizado nuevas aplicaciones de estas tecnologías;
entre estas las bases de datos para Ingeniería, bases de datos de imágenes y gráficos, bases de
datos cartográficas y geológicas, bases de datos multimedia y bases de conocimientos para
Inteligencia Artificial. Estos tipos de bd’s tienen requerimientos más complejos que las aplicaciones
tradicionales. A fin de representar estos requerimientos de la manera más exacta y explícita posible,
los diseñadores deben utilizar conceptos adicionales de “modelado semántico”.
Extensiones al modelo
Existen otras restricciones que afectan a los tipos de interrelación y a sus ejemplares, y
permiten adecuar los requerimientos reales al esquema, que son incorporadas, a saber:
 Restricción de exclusividad,
 Restricción de exclusión,
 Restricción de inclusividad, y
 Restricción de inclusión.
El modelo EER abarca, sin embargo todos los conceptos del modelado ER presentados, pero
incluye los nuevos de Subclase y Superclase, y los conceptos relacionados de Especialización y
Generalización (con éste es posible incorporar la herencia de propiedades de unos tipos de
entidades desde otros tipos). Otro concepto que tiene el modelo EER es el de Categoría.
Finalmente, otro mecanismo de abstracción incorporado es la Agregación, en dos variantes:
o Agregación compuesto/componente.
o Agregación miembro/colección.
Restricciones entre Interrelaciones - Exclusividad
Dos (o más) tipos de interrelaciones tienen una restricción de Exclusividad con respecto a un tipo
de entidad que participa en ambas relaciones si cada ejemplar de dicho tipo de entidad sólo puede
participar en uno de los tipos de la relación a la vez (en el momento en que participa en uno ya no
podrá formar parte del otro).
(1,n) => Un ejemplar de PROFESOR participa en alguna de las dos Relaciones una o varias.
Pág. 65 de 141
Restricciones entre Interrelaciones - Exclusión

Todo ejemplar de profesor que esté unido a un ejemplar de curso mediante la interrelación imparte,
no podrá estar unido al mismo ejemplar de curso mediante la interrelación recibe.
=>un profesor no puede estar impartiendo y recibiendo el mismo curso a la vez.
Restricciones entre Interrelaciones - Inclusividad

Todo ejemplar del tipo de entidad afectado que participa en uno de los tipos de relación tiene
necesariamente que participar en la otra.
=> Si un profesor participa en imparte tiene necesariamente que participar en recibe.
Restricciones entre Interrelaciones - Inclusión
=> Todo ejemplar de profesor que esté unido a un ejemplar de curso mediante la relación
imparte tiene necesariamente que estar unido al mismo ejemplar de curso mediante la
relación recibe.
Pág. 66 de 141
Otros conceptos
Generalización y Herencia
La Generalización se considera como un caso especial de relación entre uno o varios

tipos de entidad (subtipos) y un tipo más general (supertipo), cuyas características son comunes a
todos los subtipos.
La interrelación que se establece entre los subtipos y el supertipo es de la forma “ES_UN”:

Ej: Un ejemplar de un subtipo ES_UN ejemplar (también) del supertipo. (al contrario no es seguro).
Las cardinalidades mínimas y máximas siempre son:

 (1,1) en el supertipo, y
 (0,1) en los subtipos.
El mecanismo de abstracción contrario se llama especialización.
Para comprender mejor….
E xisten ciertas estructuras que permiten, a partir de ciertos conjuntos de entidades datos,
armar nuevos conjuntos de entidades con una nueva estructura. Ellas son la generalización y la
especialización.
Cuando se detecta que entre distintas entidades definidas en el esquema existe una relación
de inclusión (esto es, que todas las ocurrencias de una entidad son a su vez ocurrencia de otra más
general), este hecho se expresa por medio de la Generalización/especialización.
Esto significa que la entidad más general se especializa en una o varias entidades
especializadas o subclases, o dicho a la inversa, que una o varias entidades se generalizan en una
clase general o superclase.
Este proceso se puede repetir a distintos niveles, siendo posible que una entidad tenga más
de una superclase, siempre que la clase más general del conjunto sea única. La clase más general
será además la única que tenga atributos identificadores. Todas las subclases de una clase tienen,
además de sus atributos propios, todos los atributos de sus superclases (en cualquier nivel), aunque
no se representan en el diagrama.
Una entidad puede participar en distintas Generalizaciones/especializaciones que se definen
atendiendo a criterios distintos. El criterio se puede indicar al lado del arco.
Pág. 67 de 141
Conceptualizaciones
Generalización  : es el proceso según el cual se crea un conjunto de en-

tidades a partir de otros que comparten ciertos atributos.
A veces existen situaciones en que sea conveniente crear una entidad como una fusión de otras, en
principio, diferentes, aunque con atributos comunes. Esto disminuye el número de conjuntos de
entidades y facilita el establecimiento de interrelaciones.
Por ejemplo, estamos modelando la gestión de una biblioteca, en la que además de libros se pueden
consultar y prestar revistas y películas. Desde el punto de vista del modelo E-R, deberíamos crear
conjuntos de entidades distintos para estos tres tipos de entidad, sin embargo, todos ellos tienen
comportamientos y características comunes: préstamos, ubicaciones, ejemplares, editorial. También
tienen atributos específicos, como el número de revista, o la duración de la película.
La idea es crear una entidad con una única copia de los atributos comunes y añadir los atributos no
comunes. Además se debe añadir un atributo que indique que tipo de entidad estamos usando, este
atributo es un discriminador.
La desventaja de la generalización es que se desperdicia espacio de almacenamiento, ya que sólo

algunos de los atributos no comunes contienen información en cada entidad, el resto se desperdicia.
La ventaja es que podemos establecer el mismo tipo de interrelación con cualquier entidad del
conjunto. En nuestro ejemplo, en lugar de tener que establecer tres interrelaciones de préstamo, o
ubicación, bastará con una de cada tipo.
La Generalización se usa, entonces, cuando ciertos conjuntos de entidades tienen atributos en

común, para obtener un conjunto de entidades abstracto (no tiene entidades) que posee los
atributos comunes a varios (dos o más) conjuntos de entidades.
Personal ApeNom, Dir, DNI
Médico Camillero Enfermero Administrativo
# matrícula función
 Todos los atributos generalizados en el conjunto de entidades superior, son heredados por los
subconjuntos de entidades. (Heredan atributos comunes y agregan los propios)
Jerarquía de generalización Una entidad E es una generalización de un grupo de

entidades E1, E2, ... En, si cada ocurrencia de cada una
de esas entidades es también una ocurrencia de E.
Pág. 68 de 141
Todos los atributos generalizados en el conjunto de entidades superior, son heredados por
los subconjuntos de entidades. Todas las propiedades de la entidad genérica E son heredadas por las
sub-entidades.
Una característica muy importante de esta clase de relaciones es la herencia:
Herencia  Toda propiedad (atributo, identificadores, o participación en tipos de

interrelación) del supertipo pasa a ser un atributo de los subtipos.
Las propiedades comunes a todos los subtipos se asignan al
supertipo, mientras que las propiedades específicas se asocian al
subtipo al cual pertenecen.
• La división en subtipos (especialización) puede venir determinada por una condición predefinida
(por ejemplo, en función de los valores de un atributo llamado discriminante).
• La Generalización/Especialización tiene dos restricciones semánticas asociadas:
 Totalidad (todo ejemplar del supertipo tiene que pertenecer a algún subtipo).
El caso contrario se llama Parcialidad.
 Solapamiento (un mismo ejemplar del supertipo puede pertenecer a más de un

subtipo). El caso contrario se llama Exclusividad.
Para sintetizar…
Cada jerarquía es total o parcial, y exclusiva o superpuesta.

Una jerarquía es total si cada ocurrencia de la entidad genérica corresponde al menos con una
ocurrencia de alguna sub-entidad.
Una jerarquía es parcial si existe alguna ocurrencia de la entidad genérica que no corresponde
con ninguna ocurrencia de ninguna sub-entidad.
Una jerarquía es exclusiva si cada ocurrencia de la entidad genérica corresponde, como mucho,
con una ocurrencia de una sola de las sub-entidades. Es superpuesta si existe alguna ocurrencia
de la entidad genérica que corresponde a ocurrencias de dos o más sub-entidades diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad como sub-entidad.
Un subconjunto siempre es una jerarquía parcial y exclusiva.
Pág. 69 de 141
Especialización : Es el proceso inverso al de generalización, en lugar

de crear una entidad a partir de varias, descomponemos una entidad en
varias más especializadas.
Es el proceso según el cual se crean varios tipos de entidades a partir de

uno. Cada una de los conjuntos de entidades resultantes contendrá sólo
algunos de los atributos del conjunto original.
La idea es lógica: si la generalización tiene ventajas e inconvenientes, cuando los inconvenientes

superan a las ventajas, será conveniente hacer una especialización.
Se trata de detectar atributos pertenecientes a un subconjunto de entidades de forma tal que

Subconjunto es un caso particular del conjunto original. Todos los atributos especializados en el
conjunto superior son heredados por el subconjunto. Este no es abstracto ya que tiene entidades.
Docente
# legajo, dni, nom, dir
Profesor
anfiteatro
La especialización de una entidad en varias subclases tiene las mismas propiedades de la

generalización.
La especialización se representa uniendo todas las entidades especializadas según un criterio
con la entidad general a través de un círculo en el que indicaremos las propiedades de la
Generalización/ Especialización.
Pág. 70 de 141
En el caso de que sólo haya una subclase, no hace falta el círculo.
DNI nS S
E m p le a d o
Cuerpo Contrato
D, P D, T
A d m in is t r a t iv o T é c n ic o I n g e n ie r o G erente A s a la r ia d o Por_horas
Ejemplo:
En este diagrama ER se expresa que los empleados de una empresa pueden especializarse según
tres criterios: según el cuerpo al que pertenece, según sea o no gerente y según el tipo de contrato
que tiene.
 En la generalización, toda instancia del nivel superior va a tener su

correspondiente en algunas de las entidades del nivel inferior.
 En la especialización hay entidades de nivel superior que pueden no tener su
correspondiente en el nivel inferior.
En el ME/R extendido…
Agregación es un tipo especial de relación en la cual las cardinalidades
mínima y máxima del tipo de entidad agregada siempre son (1,1), y por eso
no se indican.
Pág. 71 de 141
• Existen dos clases de agregaciones:
Compuesto/Componente: Abstracción que permite representar que un todo o agregado

se obtiene por la unión de diversas partes o componentes que pueden ser tipos de
entidades distintas y que juegan diferentes roles en la agregación.
Miembro/Colección: Abstracción que permite representar un todo o agregado como una

colección de miembros, todos de un mismo tipo de entidad y todos jugando el mismo rol.
Esta agregación puede incluir una restricción de orden de los miembros dentro de la
colección (indicando el atributo de ordenación).
Otros usos de la la Agregación…
Cuando la relación que vincula dos o más entidades tiene a su vez características de
entidad, de manera que se relaciona como tal con otras entidades, se aplica el concepto de
agregación.
En este caso, la Agregación, se utiliza para representar relaciones entre múltiples tipos de
entidad, pero manteniendo relaciones binarias. Es decir, resuelve relaciones ternarias, de modo de
poder representar la cardinalidad y establecer los nombres de las relaciones.
Este mecanismo sirve para expresar que las ocurrencias de la relación agregada se
comportan también como entidades. Para ello, se engloba el símbolo de la relación con un
rectángulo, lo que denota que esa relación es un objeto agregado.
Empleado Usa Proyecto
Máquina
1. Se re-interpreta un tipo de relación como si fuera un tipo de entidad

2. El nuevo tipo de entidad se utiliza como cualquier otro.
1
usa Máquina
Pág. 72 de 141
Las entidades agregadas:
- Nunca son débiles.
- Pueden sufrir restricciones de existencia.
- Ni tienen atributos identificadores ya que heredan la identificación de la relación que las define.
- Sí que pueden tener atributos con restricción de unicidad o valor no nulo.
Otros ejemplos…
Solución
Ejemplo de relaciones no permitidas.

(Restricción inherente al modelo ER)
Control de Redundancias
En los esquemas E/R, y en general en los de cualquier MD, es necesario evitar las redundancias
para no tener problemas de inconsistencias de la representación.
Un elemento de un esquema es redundante si puede

ser eliminado sin pérdida de semántica.
• Existen dos formas principales de redundancia:
 En los atributos (atributos derivados o calculados):
 Aunque son redundantes, no dan lugar a inconsistencias siempre que en el esquema se

indique su condición de derivados y la fórmula mediante la que han de ser calculados.
 En las interrelaciones (también llamadas interrelaciones derivadas):
 Una interrelación es redundante si su eliminación no implica pérdida de semántica

porque existe la posibilidad de realizar la misma asociación de ejemplares por medio de
otras interrelaciones.
 Para ello es condición necesaria pero no suficiente que forme parte de un ciclo.
Pág. 73 de 141
 Hay que estudiar detenidamente los ciclos en el diagrama E/R.
La existencia de un ciclo no implica la existencia de interrelaciones redundantes.
Para que una interrelación pueda ser eliminada por redundante se tiene que cumplir:
a) que exista un ciclo,
b) que las interrelaciones que componen el ciclo sean equivalentes semánticamente,
c) que después de eliminar la interrelación se puedan seguir asociando los ejemplares de las dos
entidades que estaban interrelacionadas, y
d) que la interrelación no tenga atributos o que éstos puedan ser transferidos a otro elemento del
esquema a fin de no perder su semántica.
Diseño de un esquema de bases de datos ER

El modelo de datos ER proporciona un alto grado de flexibilidad en el diseño del esquema
para modelar una realidad dada, considerando una amplia variedad de alternativas. Entre las
decisiones a tomar en cuenta se encuentran:
 El uso de una relación ternaria o un par de relaciones binarias
 Un concepto del mundo real se puede expresar mediante un conjunto de entidades o un

conjunto de relaciones, observar cual es mejor.
 El uso de un atributo o el uso de un conjunto de atributos
 El uso de un conjunto de entidades fuerte o débil
 La oportunidad de usar generalización
 La oportunidad de usar agregación
Pág. 74 de 141
Metodología de diseño conceptual

El primer paso en el diseño de una base de datos es la producción del esquema conceptual.
Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas
visiones que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a
las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos
humanos, etc. Estas visiones de la información, denominadas vistas, se pueden identificar de varias
formas. Una opción consiste en examinar los diagramas de flujo de datos, que se pueden haber
producido previamente, para identificar cada una de las áreas funcionales. La otra opción consiste en
entrevistar a los usuarios, examinar los procedimientos, los informes y los formularios, y también
observar el funcionamiento de la empresa.
A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina
esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones,
atributos, dominios de atributos e identificadores. El esquema conceptual también tendrá una
documentación, que se irá produciendo durante su desarrollo. Las tareas a realizar en el diseño
conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama entidad-relación.
8. Revisar el esquema conceptual local con el usuario.
1. Identificar las entidades
En primer lugar hay que definir los principales objetos que interesan al usuario. Estos objetos serán
las entidades. Una forma de identificar las entidades es examinar las especificaciones de requisitos
de usuario. En estas especificaciones se buscan los nombres o los sintagmas nominales que se
mencionan (por ejemplo: número de empleado, nombre de empleado, número de inmueble,
dirección del inmueble, alquiler, número de habitaciones). También se buscan objetos importantes
como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sólo son
propiedades de otros objetos. Por ejemplo, se pueden agrupar el número de empleado y el nombre
de empleado en una entidad denominada empleado, y agrupar número de inmueble, dirección del
inmueble, alquiler y número de habitaciones en otra entidad denominada inmueble.
Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por ej.,
empleado es una entidad porque los empleados existen, sepamos o no sus nombres, direcciones y
teléfonos. Siempre que sea posible, el usuario debe colaborar en la identificación de las entidades.
2. Identificar las relaciones
Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas. Del mismo
modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos,
para identificar las relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene
empleados, empleado gestiona inmueble, cliente visita inmueble). Si las especificaciones de
requisitos reflejan estas relaciones es porque son importantes para la empresa y, por lo tanto, se
deben reflejar en el esquema conceptual. Pero sólo interesan las relaciones que son necesarias. La
mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que también
puede haber relaciones en las que participen más de dos entidades, así como relaciones recursivas.
Es muy importante repasar las especificaciones para comprobar que todas las relaciones, explícitas o
implícitas, se han encontrado. Si se tienen pocas entidades, se puede comprobar por parejas si hay
alguna relación entre ellas. De todos modos, las relaciones que no se identifican ahora se suelen
encontrar cuando se valida el esquema con las transacciones que debe soportar.
Una vez identificadas todas las relaciones, hay que determinar la cardinalidad mínima y máxima con
la que participa cada entidad en cada una de ellas. De este modo, el esquema representa de un
modo más explícito la semántica de las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones
Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son
atributos los nombres que identifican propiedades, cualidades, identificadores o características de
entidades o relaciones.
Pág. 75 de 141
Lo más sencillo es preguntarse, para cada entidad y cada relación, ¿qué información se quiere saber
de ...? La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Pero, en
ocasiones, será necesario preguntar a los usuarios para que aclaren los requisitos. Al identificar los
atributos, hay que tener en cuenta si son simples o compuestos. Por ejemplo, el atributo dirección
puede ser simple, teniendo la dirección completa como un solo valor: `San Rafael 45, Almazora'; o
puede ser un atributo compuesto, formado por la calle (`San Rafael'), el número (`45') y la
población (Àlmazora'). El escoger entre atributo simple o compuesto depende de los requisitos.
Cuando se están identificando los atributos, se puede descubrir alguna entidad que no se ha
identificado previamente, por lo que hay que volver al principio introduciendo esta entidad y viendo
si se relaciona con otras entidades.
Hay que tener mucho cuidado cuando parece que un mismo atributo se debe asociar a varias
entidades. Esto puede ser por una de las siguientes causas:
 Se han identificado varias entidades, como director, supervisor y administrativo, cuando, de hecho,
pueden representarse como una sola entidad denominada empleado. En este caso, se puede escoger
entre introducir una jerarquía de generalización, o dejar las entidades que representan cada uno de los
puestos de empleado.
 Se ha identificado una relación entre entidades. En este caso, se debe asociar el atributo a una sola de
las entidades y hay que asegurarse de que la relación ya se había identificado previamente. Si no es
así, se debe actualizar la documentación para recoger la nueva relación.
4. Determinar los dominios de los atributos

El dominio de un atributo es el conjunto de valores que puede tomar el atributo. Por ejemplo el
dominio de los números de oficina son las tiras de hasta tres caracteres en donde el primero es una
letra y el siguiente o los dos siguientes son dígitos en el rango de 1 a 99; el dominio de los números
de teléfono y los números de fax son las tiras de 9 dígitos.
Un esquema conceptual está completo si incluye los dominios de cada atributo: los valores
permitidos para cada atributo, su tamaño y su formato. También se puede incluir información
adicional sobre los dominios como, por ejemplo, las operaciones que se pueden realizar sobre cada
atributo, qué atributos pueden compararse entre sí o qué atributos pueden combinarse con otros.
Aunque sería muy interesante que el sistema final respetara todas estas indicaciones sobre los
dominios, esto es todavía una línea abierta de investigación.
Toda la información sobre los dominios se debe anotar también en el diccionario de datos.
5. Determinar los identificadores
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los
identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos.
De cada entidad se escogerá uno de los identificadores como clave primaria en la fase del diseño
lógico. Cuando se determinan los identificadores es fácil darse cuenta de si una entidad es fuerte o
débil. Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son padre,
propietaria o dominante). Si una entidad no tiene atributos que le sirvan de identificador, es débil
(otras denominaciones son hijo, dependiente o subordinada).
Todos los identificadores de las entidades se deben anotar en el diccionario de datos.
6. Determinar las jerarquías de generalización
En este paso hay que observar las entidades que se han identificado hasta el momento. Hay que ver
si es necesario reflejar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirán
nuevas sub-entidades de esta entidad genérica; o bien, si hay entidades que tienen características en
común y que realmente son sub-entidades de una nueva entidad genérica.
En cada jerarquía hay que determinar si es total o parcial y exclusiva o superpuesta.
7. Dibujar el diagrama entidad-relación
Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad-relación
correspondiente a una de las vistas de los usuarios. Se obtiene así un esquema conceptual local.
8. Revisar el esquema conceptual local con el usuario
Antes de dar por finalizada la fase del diseño conceptual, se debe revisar el esquema conceptual local
con el usuario. Este esquema está formado por el diagrama entidad-relación y toda la documentación
que describe el esquema. Si se encuentra alguna anomalía, hay que corregirla haciendo los cambios
oportunos, por lo que posiblemente haya que repetir alguno de los pasos anteriores. Este proceso
debe repetirse hasta que se esté seguro de que el esquema conceptual es una fiel representación de
la parte de la empresa que se está tratando de modelar.
Pág. 76 de 141
CAPITULO IV
Modelado Lógico: El modelo Relacional
En 1970 Codd publicó un trabajo proponiendo un nuevo MD que perseguía una serie de
objetivos:
 Independencia física: El modo cómo se almacenan los datos no debe influir en su
manipulación lógica y, por tanto, los usuarios que acceden a esos datos no han de modificar
sus programas por cambios en el almacenamiento físico.
 Independencia lógica: Añadir, eliminar o modificar cualquier elemento de la BD no
debe repercutir en los programas y/o usuarios que están accediendo a subconjuntos
parciales de los mismos (vistas).
 Flexibilidad: Ofrecer a cada usuario los datos de la forma más adecuada a la
correspondiente aplicación.
 Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme
(tablas), lo que facilita la concepción y manipulación de la BD por parte de los usuarios.
 Sencillez: Las características anteriores, así como unos lenguajes de usuario muy
sencillos, producen como resultado que el modelo relacional (MR) sea fácil de comprender y
de utilizar por parte del usuario final.
Codd concedió mucha importancia al tema de la independencia de la representación lógica

de los datos respecto a su almacenamiento interno, que concretó en tres tipos de independencia:
de ordenación, de indización, y de los caminos de acceso. Importancia que Codd manifiesta
explícitamente:
“... se propone un modelo relacional de datos como una base para proteger a los
usuarios de sistemas de datos formateados de los cambios que potencialmente
pueden alterar la representación de los datos, causados por el crecimiento del
banco de datos y por los cambios en los caminos de acceso“.
Pág. 77 de 141
l modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el
Modelo Relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de
datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros.
Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al
registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un
puntero físico, siempre señalaría desde el registro al registro .
Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones
que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables
a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los
datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos.
Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que
constituyeron la primera generación de los DBMS.
El modelo relacional representa la segunda generación de los DBMS. En

él, todos los datos están estructurados a nivel lógico como tablas formadas
por filas y columnas, aunque a nivel físico pueden tener una estructura
completamente distinta.
Los avances más importantes que el MD Relacional incorpora respecto a los MD anteriores
fueron:
 Sencillez y uniformidad: Los usuarios ven la base de datos relacional como una
colección de tablas, y al ser la tabla la estructura fundamental del modelo, éste goza de
una gran uniformidad, lo que unido a unos lenguajes no navegacionales y muy
orientados al usuario final, da como resultado la sencillez de los sistemas relacionales.
 Sólida fundamentación teórica: Al estar el modelo definido con rigor matemático, el

diseño y la evaluación del mismo puede realizarse por métodos sistemáticos basados en
abstracciones.
 Independencia de la interfaz de usuario: los lenguajes relacionales, al manipular

conjuntos de registros, proporcionan una gran independencia respecto a la forma en la
que los datos están almacenados.
Un punto fuerte del modelo relacional es la sencillez de su estructura lógica,

basado en una estructura simple y uniforme –la relación-. Pero detrás de
esa simple estructura hay un fundamento teórico sólido del que carecen
los DBMS de la primera generación.
La aparición del MR representa un hito en el desarrollo de las BD, ya que ha marcado tres
etapas diferentes, conocidas como generaciones de los DBMS’s:
 Prerrelacional (primera generación), en la cual los SGBD se soportan en los

modelos Codasyl (en Red) y Jerárquico.
Pág. 78 de 141
 Relacional (segunda generación), donde los sistemas relacionales se van

aproximando a su madurez y los productos basados en este modelo van desplazando
poco a poco a los sistemas de primera generación, hasta conseguir una mayor cuota en
el mercado de las bases de datos.
 Postrelacional (tercera generación), en la que aparecen otros MD, en especial los

orientados al objeto, que están en estos momentos intentando abrirse un hueco en el
mercado de las bases de datos e integrándose como extensiones en los SGBD’s previos
de la generación relacional.
Las ventajas citadas han contribuido a que desde mediados de los años 80, el MR sea
utilizado por prácticamente la totalidad de los DBMS comerciales.
Este éxito se refleja en:
 Algunas de las principales empresas informáticas del mundo, son en origen,

empresas de DBMS: ORACLE, Sybase, INFORMIX, ...
 Los grandes fabricantes de software tienen “su” DBMS relacional: IBM, DB2,
Microsoft SQL Server, ...
 Existen varios DBMS diseñados para PC’s y usuarios no expertos: Microsoft Access,
etc
 El tremendo éxito real del MR ha supuesto que el cambio tecnológico a la siguiente

generación esté siendo evolutivo y no revolucionario:
 Triunfan los DBMS Objeto-Relacionales, y

 Fracasan, en general, los DBMS de Objetos
puros.
Pág. 79 de 141
En los últimos años, se han propuesto algunas extensiones al modelo relacional para
capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos
y para disponer de capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos
de los datos:
a) la estructura de datos,
b) la integridad de los datos y
c) la manipulación de los mismos. Los dos primeros son
componentes estáticos y el tercero es el componente dinámico.
A. - Estructura de datos relacional
Consistente en la relación, sus propiedades y tipos, y otros conceptos, analizamos los

siguientes elementos básicos:
• RELACIÓN: Es la estructura básica del modelo relacional. Se representa mediante una tabla.
• ATRIBUTO: Representa las propiedades de la relación. Se representa mediante una columna.
• DOMINIO: Es el conjunto válido de valores que toma un atributo.
• TUPLA: Es una ocurrencia de la relación. Se representa mediante una fila.
Como se dijo una relación se puede representar como una tabla:
Pero, ¡CUIDADO!, una relación no es una tabla. Existen

diferencias entre ambos conceptos.!!!!!
El modelo relacional se basa en el concepto matemático de relación, que gráficamente se representa

mediante una tabla. Codd, que era un experto, utilizó una terminología perteneciente a las
matemáticas, en concreto de la teoría de conjuntos y de la lógica de predicados.
 Una relación es una tabla con columnas y filas. Un DBMS sólo necesita que el usuario
pueda percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la
estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres
niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede
implementar con distintas estructuras de almacenamiento.
Pág. 80 de 141
 Un atributo es el nombre de una columna de una relación. En el modelo relacional, las

relaciones se utilizan para almacenar información sobre los objetos que se representan en la
base de datos. Una relación se representa gráficamente como una tabla bidimensional en la que
las filas corresponden a registros individuales y las columnas corresponden a los campos o
atributos de esos registros. Los atributos pueden aparecer en la relación en cualquier orden.
 Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios

constituyen una poderosa característica del modelo relacional. Cada atributo de una base de
datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el
mismo dominio. Un dominio D es un conjunto de valores atómicos. Por atómico se entiende
que cada valor del dominio es indivisible en lo tocante al modelo relacional.
El concepto de dominio es importante porque permite que el usuario defina, en un lugar

común, el significado y la fuente de los valores que los atributos pueden tomar.
Esto hace que haya más información disponible para el sistema cuando éste va a ejecutar
una operación relacional, de modo que las operaciones que son semánticamente incorrectas, se
pueden evitar.
Por ejemplo, no tiene sentido comparar el nombre de una calle con un número de teléfono,
aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler
de un inmueble no estará definido sobre el mismo dominio que el número de meses que dura el
alquiler, pero sí tiene sentido multiplicar los valores de ambos dominios para averiguar el importe
total al que asciende el alquiler.
Los DBMS relacionales no ofrecen un soporte completo de los dominios ya que su

implementación es extremadamente compleja.
 Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de
la tabla. Las tuplas de una relación no siguen ningún orden.
 El grado de una relación es el número de atributos que contiene. El grado de una

relación no cambia con frecuencia.
Pág. 81 de 141
 La cardinalidad de una relación es el número de tuplas que contiene. Ya que en las
relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía
constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas.
Veamos un ejemplo:
En relación a la terminología utilizada:
Modelo relacional DBMS relacionales Sistemas de Archivos

(teoría) (implementación) Tradicionales
Definiciones formales
Una BD relacional está compuesto por un conjunto de dominios {Di} y de relaciones {Ri}
definidas sobre los dominios.
• Un dominio es un conjunto nominado, finito y homogéneo de valores atómicos =>

 el dominio se identifica por un nombre,
 tiene un número finito de valores,
 todos los valores son del mismo tipo, y
 los valores son atómicos respecto del MR
• Cada dominio puede definirse de dos maneras:

o Extensión (dando sus posibles valores):
Pág. 82 de 141
días de la semana = {lunes, martes, miércoles, … sábado, domingo}
o Intensión (mediante un tipo de datos):
edad = entero
A veces se asocia unidad de medida (kilos, metros, etc.) y/o ciertas restricciones (como un
rango de valores).
• Un atributo (A) es la interpretación de un determinado dominio en una relación, es decir el

“papel” que juega en la misma. Notación:
D = Dom (A) => D es el dominio de A
• Un atributo y un dominio pueden llamarse igual, pero ..

 Un atributo está siempre asociado a una relación, mientras que un dominio tiene
existencia propia con independencia de las relaciones.
 Un atributo representa una propiedad de una relación.
 Un atributo toma valores de un dominio.
 Varios atributos distintos (de la misma o de diferentes relaciones) pueden tomar sus
valores del mismo dominio.
Además de los dominios y atributos simples, que acabamos de definir, en ampliaciones

posteriores del MR se ha introducido el concepto de dominio compuesto, que es muy útil en la
práctica.
• Un dominio compuesto se puede definir como una combinación de dominios simples a la que se
puede aplicar ciertas restricciones de integridad.
Ejemplo: el dominio compuesto denominado Fecha se construye por agregación de
los dominios simples Día, Mes y Año, incorporando las adecuadas restricciones de
integridad a fin de que no aparezcan valores no válidos para la fecha.
• Al igual que es posible definir dominios compuestos, existen también atributos compuestos.
• Tanto los atributos compuestos como los dominios compuestos pueden ser tratados, si así lo
precisa el usuario, como “piezas únicas” de información, es decir, como valores atómicos.
• Matemáticamente, una relación definida sobre un conjunto de dominios D1...Dn (no

necesariamen-te distintos) es un subconjunto del producto cartesiano de los n dominios, donde cada
elemento de la relación (tupla) es una serie de n valores ordenados:
siendo n el grado de la relación
Esta definición no tiene en cuenta a los atributos, por eso en Bases de Datos se utiliza otra definición
que incluye los siguientes elementos:
o nombre,
o cabecera,
o cuerpo,
o esquema, y
o estado.
• Nombre: Las relaciones se identifican por un nombre. Ciertas relaciones que no necesitan
identificarse (por ejemplo, resultados intermedios) pueden no tener nombre.
• Cabecera: Conjunto de n pares atributo-dominio subyacente,
Pág. 83 de 141
{ (Ai : Di) }i=1 n donde n es el grado;
Se corresponde con la primera fila cuando la relación se representa como tabla. El

conjunto A de atributos sobre los que se define la relación se llama contexto de la
misma.
• Cuerpo: Conjunto de m tuplas, { t1, t2, ..., tm }

siendo cada tupla un conjunto de n pares atributo-valor:
{ (Ai : Vij) } siendo Vij el valor j del dominio Di asociado al atributo Ai.
El número de tuplas m es la cardinalidad.
Mientras que la cabecera es invariante, el cuerpo varía en

el transcurso del tiempo, al igual que la cardinalidad.
• El esquema de una relación está constituido por el nombre R -si existe- y la cabecera:
R ({ Ai : Di } n i=1 )
representa la parte definitoria y estática y también se denomina intensión;
• El estado r de una relación de esquema R, al que también denominaremos simplemente

relación, se representa como r(R) y está constituido por el esquema y el cuerpo de la relación:
r(R) = <esquema, cuerpo>
siendo el cuerpo el conjunto de tuplas que, en un instante dado, satisface el

correspondiente esquema de relación. También se llama extensión.
Pág. 84 de 141
Clases de relaciones: En un DBMS relacional pueden existir varios tipos de relaciones, aunque no
todos manejan todos los tipos.
Persistentes: su definición (esquema) permanece en la base de datos, borrándose solamente

mediante una acción explícita del usuario.
Base: existen por sí mismas, no en función de otras relaciones.

o Se crean especificando explícitamente su esquema de relación (nombre y
o conjunto de pares atributo/dominio).
o Sus extensiones (ocurrencias de relación), al igual que su definición, también
o se encuentran almacenadas.
o Se corresponden con el nivel conceptual de la arquitectura ANSI.
Vistas (View): son relaciones derivadas que se definen dando un nombre a una expresión de
consulta.
o Se podría decir que son relaciones virtuales (como ventanas sobre otras
relaciones), en el sentido de que no tienen datos almacenados, sino que lo único que
se almacena es su definición en términos de otras relaciones con nombre, las cuales
pueden ser relaciones base, otras vistas o instantáneas.
o Se corresponden con el nivel externo de la arquitectura ANSI.
Instantáneas (Snapshot): son relaciones derivadas al igual que las vistas, pero tienen datos
propios almacenados, que son el resultado de ejecutar la consulta especificada.
o También se llaman vistas materializadas.
o Las instantáneas no se actualizan cuando cambian los datos de las relaciones sobre
las que están definidas, pero se “refrescan” cada cierto tiempo, de acuerdo con lo
indicado por el usuario en el momento de su creación.
o Son sólo de lectura, no pudiendo ser actualizadas por el usuario, sino únicamente
“refrescadas” por el sistema.
Temporales: a diferencia de las persistentes, una relación temporal desaparece de la BD en un

cierto momento sin necesidad de una acción de borrado específica del usuario; por ejemplo, al
terminar una sesión o una transacción.
Pág. 85 de 141
Conceptos ya estudiados…
En el capítulo anterior fueron definidos, en referencia a los atributos, algunos conceptos
importantes a la hora de tratar ciertas restricciones.
Por ejemplo:
 Identificador Clave,
 Claves Candidatas,
 Clave Primaria (PK),
 Claves secundarias, etc.
Recordemos…
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus
tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave
candidata y, por lo tanto, la relación siempre tiene clave primaria.
Una clave candidata es una superclave en la que ninguno de sus subconjuntos es

una superclave de la relación. El atributo o conjunto de atributos de la relación es una clave
candidata para si y sólo si satisface las siguientes propiedades:
 Unicidad: nunca hay dos tuplas en la relación con el mismo valor de .

 Irreducibilidad (minimalidad): ningún subconjunto de tiene la propiedad de unicidad, es
decir, no se pueden eliminar componentes de sin destruir la unicidad. Cuando una clave
candidata está formada por más de un atributo, se dice que es una clave compuesta. Una
relación puede tener varias claves candidatas.
Sin embargo, además de estas definiciones, el Modelo Relacional integra una nueva
conceptualización.
Una base de datos relacional es una

colección de relaciones, pero es necesario,
además ASOCIAR unas relaciones con
otras, de modo de completar su noción básica
de “conjunto de datos interrelacionados”.
Dentro del Modelo Relacional, surge un nuevo concepto, el de Clave Ajena. Analicemos:
Se denomina Clave Ajena de una relación R2 a un conjunto no vacío de atributos cuyos valores han
de coincidir con los valores de una clave candidata de una relación R1.
- R1 y R2 pueden ser la misma relación.

- La clave ajena y la correspondiente clave candidata han de estar definidas sobre el mismo dominio.
Pág. 86 de 141
Las claves ajenas están vinculadas armónicamente con las claves primarias, ya que en
conjunto permiten definir las asociaciones entre las relaciones. Ejemplo:
Una clave ajena es un atributo o un conjunto de atributos de

una relación cuyos valores coinciden con los valores de la clave
primaria de alguna otra relación (puede ser la misma).
Las claves ajenas representan relaciones entre datos.
Esquema de una base de datos relacional

Una base de datos relacional es un conjunto de relaciones normalizadas; un esquema de base
de datos relacional S es un conjunto de esquemas de relaciones S = R1, R2, ..., Rn y un conjunto
de restricciones de integridad.
Para representar el esquema de una base de datos relacional se debe dar el

nombre de sus relaciones, los atributos de éstas, los dominios sobre los que se
definen estos atributos, las claves primarias y las claves ajenas.
En sintesis…
Y el esquema de una base de

datos relacional será:
Ε < {Ri }, {Ii } >

Siendo…
Ε el nombre del esquema relacional,

{Ri} el conjunto de esquemas de relación, y
{Ii} el conjunto de restricciones de integridad
interelementos (afectan a más de una relación
y/o dominio).
Pág. 87 de 141
B. Reglas de integridad
Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas
de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son
correctos.
Las RESTRICCIONES INHERENTES vienen impuestas por el propio Modelo de Datos.
1. En el caso del MR, una relación tiene unas propiedades intrínsecas que no tiene una
tabla, y que se derivan de la misma definición matemática de relación, ya que, al ser un
conjunto:
 No puede haber dos tuplas iguales. (=> obligatoriedad de la clave primaria)

 El orden de las tuplas no es significativo.
 El orden de los atributos no es significativo.
 Cada atributo sólo puede tomar un único valor del dominio subyacente;
no
se admiten grupos repetitivos (ni otro tipo de estructuras) como valores
de los atributos de una tupla.
Se dice que la relación está normalizada (en Primera Forma Normal).
2. Otra restricción inherente es la regla de integridad de entidades:
 "Ningún atributo que forme parte de la clave primaria de una relación

puede tomar un valor nulo"; es decir, un valor desconocido o inexistente.
Nulos  Cuando en una tupla un atributo es desconocido,

se dice que es nulo.
Un nulo no representa el valor cero ni la cadena vacía, éstos
son valores que tienen significado. El nulo implica ausencia
de información, bien porque al insertar la tupla se desconocía
el valor del atributo, o bien porque para dicha tupla el
atributo no tiene sentido
Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa
problemas de implementación. De hecho, no todos los DBMS relacionales soportan los
nulos.
Para reflexionar…
No se deben confundir los conceptos de tabla y de relación, puesto que:
 Una relación es un concepto abstracto de origen matemático.

 Una tabla es una forma de representar (implementar) una relación
(una estructura de datos).
Una tabla no tiene las restricciones inherentes de una relación como conjunto:
Puede haber dos filas iguales.
Las filas están ordenadas en el orden de grabación física por defecto o según el valor
de la clave primaria.
Los atributos tienen un orden según se han definido en la tabla.
Pág. 88 de 141
En cada celda de una tabla puede haber uno o varios valores. Si bien en el segundo
caso se puede obtener una tabla equivalente que cumple la regla de normalización.
Las RESTRICCIONES de Integridad SEMÁNTICAS son definidas por el usuario.

Son facilidades que el modelo ofrece a los usuarios/diseñadores para que puedan reflejar en el
esquema, lo más fielmente posible, la semántica del mundo real. Los tipos de restricciones
semánticas permitidos en el MR (incorporados a SQL 92) son:
1. Clave Primaria (PRIMARY KEY),

2. Unicidad (UNIQUE),
3. Obligatoriedad (NOT NULL),
4. Integridad Referencial (FOREIGN KEY),
5. Restricciones de Rechazo:
 Verificación (CHECK), y
 Aserción (CREATE ASSERTION).
6. Disparador (trigger), incluido en SQL3 pero no en SQL92.
7. Dependencia (se estudiarán más tarde).
1) Clave Primaria (PRIMARY KEY):

Permite declarar un atributo o un conjunto de atributos como clave primaria de una relación.
 => sus valores no se podrán repetir ni se admitirán los nulos (o valores “ausentes”).
 Ni el SQL92 ni los SGBD’s relacionales obligan a la declaración de una clave primaria para
cada tabla (el modelo teórico sí la impone), aunque permiten la definición de la misma.
 Debemos distinguir entre la restricción inherente de obligatoriedad de la clave primaria y
la restricción semántica que le permite al usuario indicar qué atributos forman parte de la
clave primaria.
2) Unicidad (UNIQUE):
Los valores de un conjunto de atributos (uno o más) no pueden repetirse en una relación. Esta
restricción permite la definición de claves alternativas.
3) Obligatoriedad (NOT NULL):

El conjunto de atributos no admite valores nulos.
4) Integridad Referencial (FOREING KEY):

Si una relación R2 (relación que referencia) tiene un descriptor (subconjunto de atributos) CA
que referencia a una clave candidata CC de la relación R1 (relación referenciada), todo valor de
dicho descriptor CA debe coincidir con un valor de CC o ser nulo.
 La condición puede expresarse como R2.CA = R1.CC

 El descriptor CA es, por tanto, una clave ajena de la relación R2.
 Las relaciones R1 y R2 no son necesariamente distintas.
 La clave ajena puede ser también parte (o la totalidad) de la clave primaria de R2.
 CA puede admitir nulos o tener restricción de obligatoriedad (NOT NULL).
Todo atributo de una clave primaria compuesta de una relación R2 que no está definido sobre un
dominio compuesto, debe ser clave ajena de R2 referenciando a una relación R1, cuya clave
primaria sea simple.
Además de definir las claves ajenas, hay que determinar las consecuencias que pueden tener
ciertas operaciones (borrado y modificación) realizadas sobre tuplas de la relación referenciada;
pudiéndose distinguir, según el estándar SQL92, los siguientes Modos de Borrado y Modificación:
 NO ACTION: rechazar la operación de borrado o modificación. (Restringir)
Pág. 89 de 141
 CASCADE: Propagar la modificación (o borrado) de las tuplas de la tabla que referencia.
 SET NULL: poner valor nulo en la clave ajena de la tabla que referencia. (Anular)
 SET DEFAULT: poner un valor por defecto en la clave ajena de la tabla que referencia.
Ambos modos son independientes, es decir, cada uno tomará

una de las cuatro opciones por separado.
5) Restricciones de Rechazo: el usuario formula una condición mediante un predicado definido

sobre un conjunto de atributos, tuplas o dominios, que debe ser verificado en toda operación de
actualización para que el nuevo estado constituya una ocurrencia válida del esquema. Existen
dos clases:
 Verificación (CHECK): Comprueba, en toda operación de actualización, si el
predicado es cierto o falso y, en el segundo caso, rechaza la operación. La
restricción de verificación se define sobre un único elemento (dentro de un
CREATE TABLE) y puede o no tener nombre.
CHECK N_HORAS > 30 en CURSO_DOCTORADO
 Aserción (ASSERTION): Actúa de forma idéntica a la anterior, pero se

diferencia de ella en que puede afectar a varios elementos (por ejemplo, a dos
tablas distintas). Por tanto, su definición no va unida a la de un determinado
elemento del esquema y siempre ha de tener un nombre.
CREATE ASSERTION CONCEDE_SOLICITA AS

CHECK (SELECT Cod_Estudiante, Cod_Beca FROM
CONCEDE) IN
(SELECT Cod_Estudiante, Cod_Beca FROM
SOLICITA));
Pág. 90 de 141
6) Disparador (trigger): Restricción en la que el usuario pueda especificar libremente la respuesta
(acción) ante una determinada condición.
Así como las anteriores reglas de integridad son declarativas, los disparadores son
procedimentales, siendo preciso que el usuario escriba el procedimiento que ha de aplicarse
en caso de que se cumpla la condición.
Ejemplo: si una beca es solicitada por más de 50 alumnos, se introduce un texto en una tabla de
mensajes para que la persona que gestiona las becas considere si es necesario ofrecer más
becas;
CREATE TRIGGER Comprobar_Matriculados AFTER INSERT ON
SOLICITA DECLARE NUM_SOLICITUDES Number;
BEGIN
SELECT COUNT (*) INTO NUM_SOLICITUDES FROM
SOLICITA;
IF NUM_SOLICITUDES > 50 THEN
INSERT INTO MENSAJES VALUES (‘Hay más
de 50 solicitudes’);
END IF;
END Comprobar_Matriculados;
Reglas de negocio
Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la
base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas
de negocio. Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte
empleados, el DBMS debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla
respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya tiene los
veinte permitidos.
Hoy en día aún existen DBMS relacionales que no permiten definir este tipo de
restricciones ni las hacen respetar.
El Modelo Relacional se adapta a la arquitectura ANSI, pero con las siguientes

excepciones importantes:
 Al usuario se le permite ver, si tiene las correspondientes autorizaciones, tanto

las relaciones base como las vistas, mientras que en la arquitectura ANSI, para un
usuario, la BD está limitada al esquema externo -vistas-.
 Aunque las vistas se corresponden con los esquemas externos de ANSI y éstos
pueden actualizarse, en el MR no todas las vistas son actualizables.
 Además, en la práctica muchos DBMS relacionales no responden a la arquitectura

a tres niveles, ya que las definiciones del esquema conceptual y del esquema interno
no están claramente diferenciadas.
Pág. 91 de 141
Evolución del Modelo Relacional

Cuando el MR triunfó comercialmente, muchos fabricantes que tenían productos “antiguos”
no relacionales optaron por retocarlos o “camuflarlos” añadiéndoles la etiqueta relacional. Esto
supuso una confusión que Codd intentó arreglar publicando sus 12+1 reglas, que indican las
características que debe tener un DBMS para ser auténticamente relacional.
Regla 0: Un SGBD relacional debe emplear para gestionar la BD exclusivamente sus facilidades
relacionales. De esta regla genérica se derivan 12 reglas detalladas.
1. Regla de información: Toda la información en la Base de datos es representada en una y solo

una forma: valores en columnas de filas de tablas.
2. Regla de acceso garantizado: Cada valor escalar individual puede ser direccionado indicando
los nombres de la tabla, columna y valor de la clave primaria de la fila correspondiente.
3. Tratamiento sistemático de valores nulos: El SGBD debe soportar la representación y

manipulación de información desconocida y/o no aplicable.
4. Catálogo en línea (diccionario de datos) basado en el modelo relacional.
5. Sublenguaje de datos completo: El SGBD debe soportar al menos un lenguaje relacional:
a) con sintaxis lineal.

b) que pueda ser usado interactivamente o en programas (embebido).
c) con soporte para operaciones de:
- definición de datos (p.e. declaración de vistas).
- manipulación de datos (p.e. recuperación y modificación de tuplas).
- restricciones de seguridad e integridad.
- gestión de transacciones.
6. Actualización de vistas: todas las vistas teóricamente actualizables deben poder serlo en la
práctica.
7. Inserción, modificación y borrado de tuplas de alto nivel: todas las operaciones de

manipulación de datos deben operar sobre conjuntos de filas (lenguaje de especificación en vez de
navegacional).
8. Independencia física de los datos: cambios en los métodos de acceso físico o la forma de
almacenamiento no deben afectar al acceso lógico a los datos.
9. Independencia lógica de los datos: los programas de aplicación no deben ser afectados por
cambios en las tablas que preservan la integridad.
10. Independencia de la integridad: Las restricciones de integridad deben estar separadas de los
programas, almacenadas en el catálogo de la BD para ser editadas mediante un sublenguaje de
datos.
11. Independencia de la distribución: Las aplicaciones no deben verse afectadas al distribuir

(dividir entre varias máquinas), o al cambiar la distribución ya existente de la Base de Datos.
12. Regla de no subversión: Si el sistema posee un interface de bajo nivel (p.e. mediante
llamadas en C), éste no puede subvertir el sistema pudiendo evitar restricciones de seguridad o
integridad.
Pág. 92 de 141
Transformación de un diagrama E-R al Modelo Relacional (implementable)
Es posible derivar (obtener) un esquema de bases de datos relacional a partir de un

esquema conceptual creado empleando el modelo Entidad-vínculo (ER). Muchas herramientas CASE
(computer-aided software engineering) se basan en el modelo ER y en sus variaciones.
Los diseñadores de bases de datos utilizan interactivamente estas herramientas
computarizadas para crear un esquema ER o variaciones de ellos para crear el esquema
gráficamente y luego lo convierten automáticamente en un esquema de bases de datos relacional
expresado en el DDL de un DBMS relacional específico.
Es posible especificar un método de transformación mediante un Algoritmo De Siete Pasos,
puesto que una base de datos que se ajusta a un diagrama ER puede representarse por medio de
una colección de tablas. Para cada conjunto de entidades y para cada conjunto de relaciones en la
base de datos, existe una tabla única a la que se le asigna el nombre del conjunto de entidades o del
conjunto de relaciones correspondiente.
Pasos para la Reducción de un modelo E-R a un MR
1.- Representación de conjuntos de Entidades Fuertes.
2.- Conversión de Entidades Débiles.
3.- Representación de conjunto de relaciones o vínculos 1:1
4.- Representación de conjunto de relaciones o vínculos 1: N
5.- Representación de conjunto de relaciones o vínculos M: N
6.- Conversión de atributos multivaluados.
7.- Representación de conjunto de relaciones o vínculos n-arios R, con n>2. (ADICIONAL)
Para poder explicar más gráficamente, utilizaremos un ejemplo concreto que responde al
modelo E-R dispuesto a continuación:
EJEMPLO
La fase de recolección y análisis de requerimientos permitió a los diseñadores redactar una

descripción del “minimundo”, o parte de una compañía que se representará en la base de datos.
a) La compañía está organizada en departamentos. Cada departamento tiene un nombre (único) y

un cierto empleado que lo dirige, y nos interesa la fecha en que dicho empleado comenzó a
dirigir el dpto.
b) Cada departamento controla un cierto número de proyectos, cada uno de los cuales tiene un
nombre y un número (únicos), y se efectúa en un solo lugar.
c) Para cada empleado se almacena nombre, código de seguro social, dirección, sexo, fecha de
nacimiento y salario. Todo empleado está asignado a un departamento, pero puede trabajar en
varios proyectos, que no necesariamente estarán controlados por el mismo departamento. Lo
que sí interesa es el número de horas por semana que un empleado trabaja en un proyecto, y
también quién es el supervisor de cada empleado.
d) Para poder administrar los términos de sus seguros, es necesario estar al tanto de los
dependientes de cada empleado, por lo que se almacenarán nombre, sexo y fecha de nacimiento
de cada dependiente, y su parentesco con el empleado.
Pág. 93 de 141
La figura siguiente muestra cómo se puede presentar el esquema de esta aplicación mediante la
notación gráfica conocida como Diagramas E-R.
(1 , 1)
(0 ,N )
Diagrama ER del esquema COMPAÑIA con todo los nombres de papeles y restricciones estructurales
de los vínculos con la notación alternativa (min, máx)
De éste esquema E-R es posible derivar un esquema relacional (COMPAÑÍA) de acuerdo al

algoritmo de 7 pasos mencionado anteriormente. Al hacerlo se obtiene:
Empleado
NombreP Inic Apellido NSS FechaN Dirección Sexo Salario NSSSuper ND
Departamento
NombreD NúmeroD NSSGte FechaInicGte
Lugares_Dpto
NúmeroD LugarD
Proyecto
NombreP NúmeroP LugarP NúmD
Trabaja_EN
NSSE NúmP Horas
Pág. 94 de 141
Dependiente
NSSE Nombre_dependiente Sexo FechaN Parentesco
Paso 1:
Por cada tipo normal de entidades E del esquema E-R, se crea una relación R que contenga todos los
atributos simples de E. Se incluyen sólo los atributos simples de un atributo compuesto. Luego se
elige uno de los atributos como clave primaria.
En el ejemplo los tipos de entidades a representar en este primer paso son: Empleado,
Departamento y Proyecto. No se incluyen todavía los atributos de clave externa y de vínculo
(NSSSuper, Nd de Empleado; NSSGte y FechaInicGte de Departamento y NúmD de Proyecto).
Empleado
NombreP Inic Apellido NSS FechaN Dirección Sexo Salario
Departamento
NombreD NúmeroD
Proyecto
NombreP NúmeroP LugarP
Paso 2:
Por cada tipo de entidad débil D del esquema ER con tipo de entidades propietarias E, se crea una
relación R y se incluyen todos los atributos simples (o componentes simples de los atributos
compuestos) de D como atributos de R.
Además se incluyen como atributos de clave externa de R los atributos de clave primaria de la
relación o relaciones que corresponden al tipo de entidades propietarias.
La clave primaria de R es la combinación de las claves primarias de

las propietarias y la clave parcial de D, si existe.
En el ejemplo se crea entonces la relación Dependiente que corresponde al tipo de entidades débil
Dependiente. La relación o tipo de vínculo Dependiente_De no se transformará en los pasos
correspondientes a conversión de tipos de vínculos, puesto que es una relación mandatoria.
Dependiente
NSSE Nombre_dependiente Sexo FechaN Parentesco
Paso 3:
Por cada vínculo binario 1:1 R del esquema E-R, se identifican las relaciones S y T que corresponden
a los tipos de entidades que participan en R. S escoge una de las relaciones (supongamos S) y se
incluye como clave externa en S la clave primaria de T.
Es mejor elegir un tipo de entidades con participación Total en R en el papel de S. Se incluyen todos
los atributos simples (o componentes simples de atributos compuestos) del tipo de vínculos 1:1 R
como atributos de S.
Pág. 95 de 141
En el ejemplo el tipo de vínculo 1:1 Dirige de la figura será el que se transformará, eligiendo
Departamento para desempeñar el papel de S, debido a que su participación en Dirige es TOTAL
(todo departamento tiene un gerente).
Se incluirá la clave primaria de la relación Empleado como clave externa de la relación Departamento
y se cambia el nombre a SGte. También se incluye el atributo simple FechaInic de Dirige en la
relación Departamento y cambiamos su nombre a FechaInicGte.
Departamento Nuevos campos adicionados

NombreD NúmeroD NSSGte FechaInicGte
A tener en cuenta...
 Puede establecerse una transformación alternativa de un tipo de vínculos 1:1 si combinamos los
dos tipos de entidades y el vínculo en una sola relación. Esto resulta apropiado sobre todo cuando las
dos participaciones son totales y cuando los tipos de entidades no participan en ningún otro vínculo.
Paso 4:
Por cada tipo de vínculos normal (no débil) binario 1: N R, se identifica la relación S que representa
el tipo de entidades participante de lado [ :N] del tipo de vínculo. Se incluye como clave externa en S
la clave primaria de la relación T que representa al otro tipo de entidades que participa en R; la
razón es que cada ejemplar de entidad del lado N está relacionado con un máximo de un ejemplar de
entidad del lado 1:
Se incluyen todos los atributos simples (o componentes simples de los atributos compuestos) del tipo
de vínculos 1: N como atributos de S.
En el ejemplo, en este paso se produce la transformación de los tipos de vínculo Pertenece_A,

Controla y Supervisión.
 En el caso de Pertenece_A se incluye la clave primaria de la relación Departamento como clave
externa en la relación Empleado y la llamamos ND.
 En el caso de Supervisión, se incluye la clave primaria de la relación Empleado como clave
externa de la relación Empleado misma y la llamamos NSSSuper.
 El vínculo Controla corresponde al atributo de clave externa NúmD de Proyecto.
Empleado
NombreP Inic Apellido NSS FechaN Dirección Sexo Salario NSSSuper ND
Proyecto
NombreP NúmeroP LugarP NúmD
Paso 5:
Por cada tipo de vínculos binario M:N , se crea una nueva relación S para representar R. Se
incluyen como atributos de clave externa en S las claves primarias de las relaciones que representan
los tipos de entidades participantes; su combinación constituirá la clave primaria de S. También se
incluyen todos los atributos simples (o componentes simples de atributos compuestos) del tipo de
vínculos M:N como atributos de S.
No se puede representar un tipo de vínculos M:N con un solo atributo de clave externa en una de las
relaciones participantes (como se hizo en el caso de los tipos de vínculos 1:1 y 1:N) debido a la razón
de cardinalidad M:N.
Pág. 96 de 141
En el ejemplo, se establece la transformación del tipo de vínculos Trabaja_En, incluyendo las claves
primarias de las relaciones Proyecto y Empleado como claves externas en Trabaja_En y se cambian
sus nombres a NúmP y NSSE, respectivamente. También se incluye un atributo horas en Trabaja_En
para representar el atributo Horas del tipo de vínculos. La clave primaria de la relación Trabaja_En es
la combinación de los atributos de clave externa {NSSE, NúmP}.
Trabaja_EN
NSSE NúmP Horas
 Cabe destacar que siempre es posible transformar los vínculos 1:1 y 1:N de una manera similar a
como se hace con los vínculos M:N. Esta alternativa es útil sobre todo cuando hay pocos ejemplares
del vínculo, a fin de evitar valores nulos en las claves externas. En este caso, la clave primaria de la
relación “vínculo” será la clave externa de sólo una de las relaciones “entidad” participantes.
En el caso de un vínculo 1:N, esta será la relación entidad del lado N, en el caso 1:1, se
elegirá la relación con participación Total.
Paso 6:
Por cada atributo multivaluado A se crea una relación nueva R que contiene una atributo
correspondiente a A más el atributo de clave primaria K (como clave externa de R) de la relación que
representa el tipo de entidades o de vínculos que contiene a A como atributo. La clave primaria de R
es la combinación de A y K. Si el atributo multivaluado es compuesto, se incluyen sus componentes
simples.
En el ejemplo, se crea la relación Lugares_Dptos. El atributo LugarD representa el atributo

multivaluado Lugares de Departamento, en tanto que NúmeroD (como clave externa) representa la
clave primaria de la relación Departamento.
La clave primaria de Lugares_Dptos es la combinación }NúmeroD, LugarD}. Habrá una tupla en
Lugares_Dptos por cada lugar en que esté ubicado un departamento.
Lugares_Dpto
NúmeroD LugarD
Hasta aquí se ha realiza la transformación del esquema E-R de la figura a un esquema de base de
datos relacional descripto en su totalidad en la misma página. No se ha analizado todavía la
transformación de tipos de vínculos n-arios (n>2) porque no existe en el ejemplo ninguno. Sin
embargo estos pueden transformarse de manera similar a los tipos de vínculos M:N si se incluye el
siguiente paso ADICIONAL en el procedimiento de transformación:
Paso 7:
Por cada tipo de vínculos n-ario R, n>2, se crea una nueva relación S que represente a R. Se
incluyen como atributos de clave externa en S las claves primarias de las relaciones que representan
los tipos de entidades participantes. También se incluyen los atributos simples (o los componentes
simples de los atributos compuestos) del tipo de vínculos n-ario como atributos de S.
La clave primaria de S casi siempre es una combinación de todas las claves externas que hacen
referencia a las relaciones que representan los tipos de entidades participantes. No obstante, si la
restricción de participación (min, máx) de uno de los tipos de entidades E que participan en R tiene
máx=1, la clave primaria de S podrá ser el único atributo de clave externa que haga referencia a la
relación E’ que corresponde a E; la razón es que cada una de las entidades e de E participará, en
cuando más, un ejemplar de vínculo R, y por tanto, podrá identificar de manera única ese ejemplar.
Pág. 97 de 141
Modelo E-R extendido: transformación de generalizaciones, especializaciones y agregaciones
Tomando ejemplos particulares se pueden especificar además pasos para la conversión de estos
casos, existiendo en cada uno diferentes alternativas a analizar y escoger.
A.- Para transformar Generalizaciones:
Personal
dni, nyap, dir
Médico Enfermero Camillero Administrativo
#mat función
Existen tres formas para realizar la conversión:
1) Pasar sólo el conjunto de entidades superior.

Todos los atributos de la entidad superior, más cada uno de los atributos de las
entidades inferiores, más un atributo distintivo (que indique el tipo de personal).
Personal (dni, nyap, dir #mat, función, tipo_dist) menos recomendada, pues promueve
atributos nuevos y dificulta la
búsqueda
2) Pasar las entidades de todos los niveles a tablas y en las entidades de nivel
inferior, se pone la clave del nivel superior.
Personal (dni, nyap, dir)
Médico (dni, # mat)
Enfermero (dni)
Camillero (dni)
Administrativo (dni, función)
3) Representar sólo los niveles inferiores con los atributos propios, más lo de la
entidad superior.
Médico (dni, nyap, dir, # mat)
Enfermero (dni, nyap, dir)
Camillero (dni, nyap, dir)
Administrativo (dni, nyap, dir, función)
B.- Para transformar Especializaciones:
También existen dos formas de conversión, que

Docente dni, nyap, dir coinciden con las dos primeras de la
generalización. La tercera no es viable porque
pueden quedar filas en la entidad superior que no
Profesor pertenezcan a ninguna entidad inferior y se
categoría perdería información.
1) Docentes (dni, nyap, dir, categoría, tipo)  la menos recomendable.
2) Docentes (dni, nyap, dir) Profesor (dni, categoría)
C.- En el caso de Agregaciones:
1) Cada entidad del rectángulo pasa a ser una tabla. Las externas también.
2) Las relaciones dentro y fuera del rectángulo también.
Pág. 98 de 141
CAPÍTULO V
Manipulación de los datos
Como ya se dijo en el capítulo anterior, el modelo relacional, como todo modelo de datos,
tiene que ver con tres aspectos de los datos:
a) la estructura de datos,
b) la integridad de los datos y
c) la manipulación de los mismos.
El tercer aspecto, entonces, el de la manipulación, utiliza varios lenguajes para manejar las
relaciones. Vamos a explicar exactamente de qué se trata concretamente:
El modelo relacional (MR), como todo modelo de datos

(MD), lleva asociado a su parte estática (estructura y restricciones)
una dinámica que permite la transformación entre estados
de la base de datos.
Esta transformación de un estado origen a un estado objetivo se realiza aplicando un

conjunto de operadores, mediante los cuales se llevan a cabo los siguientes tipos de operaciones:
 inserción de tuplas
 borrado de tuplas
 modificación de tuplas
 consultas
Si O es un operador, el paso de un estado origen de la base de datos (BDi) a un estado

objetivo (BDj) se pueden expresar como:
O (BDi) = BDj
ambos estados deben satisfacer las restricciones de integridad

estáticas, y la transformación ha de cumplir las restricciones
de integridad dinámicas (entre estados).
Pág. 99 de 141
Los lenguajes relacionales (LR) operan sobre conjuntos de tuplas, es decir, no son
lenguajes navegacionales (que manipulan registros, como Pascal, Cobol, XBase…) sino de
especificación.
Se dividen en dos tipos:
Algebraicos: los cambios de estado se especifican mediante operaciones, cuyos

operandos son relaciones y cuyo resultado es otra relación. Genéricamente
se conocen como álgebra relacional.
Predicativos: los cambios de estado se especifican mediante predicados que definen el

estado objetivo sin indicar las operaciones que hay que realizar para llegar al
mismo. Genéricamente se conocen como cálculo relacional.
Se dividen en dos subtipos:
 orientados a tuplas y
 orientados a dominios.
Los lenguajes comerciales (SQL, QBE, etc.) están basados

en los anteriores pero con sintaxis más amigable.
Los lenguajes Algebraicos son también llamados Procedurales, mientras que los Predicativos
son No Procedurales. Según esta nueva clasificación, decimos que:
 los procedurales, son aquellos en los que el usuario dice al sistema

exactamente cómo debe manipular los datos, mientras los otros,
 los no procedurales, son aquellos en los que el usuario dice qué datos
necesita, en lugar de decir cómo deben obtenerse.
Se puede decir que el álgebra es un lenguaje procedural (de alto nivel), mientras que el
cálculo relacional es un lenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes:
para cada expresión del álgebra, se puede encontrar una

expresión equivalente en el cálculo, y viceversa.
El álgebra relacional (o el cálculo relacional) se utilizan para medir la potencia de los

lenguajes relacionales. Si un lenguaje permite obtener cualquier relación que se pueda
derivar mediante el álgebra relacional, se dice que es relacionalmente completo.
La mayoría de los lenguajes relacionales son relacionalmente completos, pero tienen más
potencia que el álgebra o el cálculo porque se les han añadido operadores especiales.
Tanto el álgebra como el cálculo son lenguajes formales no muy “amigables". Pero se deben
estudiar porque sirven para ilustrar las operaciones básicas que todo lenguaje de manejo datos debe
ofrecer. Además, han sido la base para otros lenguajes relacionales de manejo de datos de más alto
nivel.
Pág. 100 de 141

Algebra relacional
El álgebra relacional es un lenguaje formal de consulta procedural, consta con una serie de
operadores que trabajan sobre una o varias relaciones para obtener otra relación resultado, sin que
cambien las relaciones originales.
Tanto los operandos como los resultados son relaciones, por lo que la salida de
una operación puede ser la entrada de otra operación. Esto permite anidar expresiones del
álgebra, del mismo modo que se pueden anidar las expresiones aritméticas. A esta propiedad se le
denomina clausura: las relaciones son cerradas bajo el álgebra, del mismo modo que los números
son cerrados bajo las operaciones aritméticas.
Primero se describen los ocho operadores originalmente propuestos por Codd y después se
estudian algunos operadores adicionales que añaden potencia al lenguaje. Los operadores son:
1. Selección 2. Proyección 3. Producto
4. Unión 5. Intersección 6. Diferencia
7. JOIN 8. División
Tabla - Operadores del Algebra relacional
Podemos clasificar los operadores del AR de tres formas:
a) Según su origen:
 Procedentes de la teoría de conjuntos: unión, intersección, diferencia y producto
cartesiano.
 Relacionales especiales: restricción, proyección, combinación y división.
b) Según la completitud del lenguaje:

 Primitivos: operadores esenciales que no pueden obtenerse de otros (sin ellos, el
AR no sería un lenguaje completo).
 Derivados: se pueden obtener aplicando varios de los operadores primitivos.
Aunque se puede prescindir de ellos, son útiles para simplificar muchas operaciones
habituales.
c) Según el número de operandos:

 Unarios: actúan sobre una única relación. (Selección; Proyección)
 Binarios: el operador tiene dos relaciones como operandos.
Pág. 101 de 141

De estos ocho operadores, sólo hay cinco que son

fundamentales: selección, proyección, producto cartesiano, unión
y diferencia, que permiten realizar la mayoría de las operaciones
de obtención de datos (denominados “operadores primitivos”).
Los operadores no fundamentales son la concatenación
(join), la intersección y la división, que se pueden expresar a partir
de los cinco operadores fundamentales.
En las definiciones que se presentan a continuación, se supone que R y S son dos relaciones
cuyos atributos son A=(a , a , ..., a ) y B=(b , b , ..., b ) respectivamente.
Conjunto Completo de Operaciones:
Se ha demostrado que el conjunto de operaciones del Algebra Relacional:
{, , , -, X} Selección, Proyección, Unión, Diferencia y Producto Cartesiano
es un conjunto COMPLETO: es decir,
cualquiera de las operaciones del álgebra relacional puede

expresarse como una secuencia de operaciones de este
conjunto.
Pág. 102 de 141

Ejemplo:
Se hace necesario en este punto incluir un modelo de datos de ejemplo en el cual
trabajar para generar ejemplos de comandos y operadores. Para este efecto se incluye un modelo
básico de administración de RadioTaxis. El Gráfico que se presenta a continuación representa el
Modelo conceptual (Modelo Lógico) o Diagrama de Entidad-Relación:
Figura - Esquema de Relaciones de Ejemplo
Los Esquemas de relaciones (Modelo Relacional) que se pueden construir a partir de este
modelo son los siguientes:
Dueño = {rut, nombre, teléfono, dirección, vigencia}
Chofer = {rut, nombre, teléfono, dirección, fecha_licencia_desde, fecha_licencia_hasta, vigencia}
Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total}
Móvil = {patente, rut_dueño, rut_chofer, marca, modelo, año}
Viaje = {correlativo_vale, patente_movil, hora_Desde, hora_hasta, origen, destino, tarifa, metraje}
Definamos ahora la BD por extensión con algunos ejemplares u ocurrencias:
DUEÑO
Rut Nombre Teléfono Dirección Vigencia

5 Perez, Juan 4664333 Lavalle 523 S
13 Alvarez, Luis 4842445 San Luis 652 N
6 Luque, Alberto 4345543 Salta 1543 N
3 Juárez, Nicolás 4564433 Córdoba 123 S
11 Gómez, Ricardo 4664324 Gral. Paz 22 S
9 Salas, Dalmiro 4886436 Bolivar 2654 S
10 Reinoso, Rubén 4333556 Bernabé A.12 N
Pág. 103 de 141

CHOFER
Rut Nombre Teléfono Dirección Fec_Lic_desde Fec_Lic_hasta Vigencia

11 Gómez, Ricardo 4664324 Gral. Paz 22 12/03/2002 03/03/2012 S
4 Ruiz, Ernesto 4567678 Lamadrid 3466 29/11/2003 20/11/2011 S
10 Reinoso, Rubén 4333556 Bernabé A 12 05/04/1999 01/04/2009 N
2 Morán, Daniel 4321432 Jujuy 245 21/07/2007 15/07/2013 S
14 Toledo, Carlos 4879899 Ayacucho 76 09/04/2001 01/04/2010 N
5 Perez, Juan 4664333 Lavalle 523 11/09/2005 05/09/2014 S
1 Tula, Adalberto 4564654 Muñecas 333 03/08/2009 23/07/2016 S
12 Beltrán, Ramón 4777896 Maipú 2498 25/12/2004 20/12/2008 N
7 González, Raúl 4599965 Chacabuco 2 30/11/2006 24/11/2012 N
MOVIL
Patente Rut_Dueño Rut_Chofer Marca Modelo Año

BSF - 304 11 5 FORD FIESTA 2002
ERA-546 13 12 CITROEN C3 2004
HTE-123 10 10 HONDA FIT 2009
CPS-598 6 4 FIAT UNO 2001
KYA-683 3 14 VOLKSWAGEN GOL 1998
FRK-932 11 11 PEUGEOT 206 2005
STK-777 6 2 FIAT DUNA 1996
GWZ-394 9 1 FORD KA 2007
1. Selección
El operador de selección opta por tuplas que satisfagan cierto predicado.
Se utiliza la letra griega sigma minúscula (σ) para señalar la selección.
El predicado aparece como subíndice de σ; la Relación que constituye el argumento se da entre
paréntesis después de la σ. Ejemplos:
σ vigencia=”S” (DUEÑO)
RESULTADO
Rut Nombre Teléfono Dirección Vigencia

5 Perez, Juan 4664333 Lavalle 523 S
3 Juárez, Nicolás 4564433 Córdoba 123 S
11 Gómez, Ricardo 4664324 Gral. Paz 22 S
9 Salas, Dalmiro 4886436 Bolivar 2654 S
σpatente=”KYA-683” (MOVIL)
RESULTADO
Patente Rut_Dueño Rut_Chofer Marca Modelo Año

KYA-683 3 14 VOLKSWAGEN GOL 1998
Pág. 104 de 141

Características:
 La relación resultante tiene los mismos atributos que la relación especificada. (El
grado es el mismo)
 El operador es unario, se aplica a una sola relación, más aún, la operación se
aplica a cada tupla individualmente.
 Se pueden combinar una cascada (anidamiento) de operaciones σ en una sola
condición conjuntiva (AND)
2. Proyección.
La operación de proyección permite quitar ciertos atributos de la relación.
Esta operación es unaria, copiando su relación base dada como argumento y quitando ciertas
columnas.
La proyección se señala con la letra griega pi mayúscula (Π); como subíndice de Π se coloca una
lista de todos los atributos que se desea aparezcan en el resultado; la relación argumento se escribe
después de Π entre paréntesis. Ejemplos:
Π nombre,direccion (DUEÑO) Π rut,vigencia (CHOFER)
RESULTADO RESULTADO
Nombre Dirección Rut Vigencia

Perez, Juan Lavalle 523 11 S
Alvarez, Luis San Luis 652 4 S
Luque, Alberto Salta 1543 10 N
Juárez, Nicolás Córdoba 123 2 S
Gómez, Ricardo Gral. Paz 22 14 N
Salas, Dalmiro Bolivar 2654 5 S
Reinoso, Rubén Bernabé A.12 1 S
12 N
7 N
Características:
 El álgebra relacional, automáticamente, hace la eliminación de los duplicados,
para que la resultante sea una relación.
 El número de tuplas de la relación resultante es menor o igual que el número de
tuplas en la relación de origen. (Si la lista de proyección incluye una clave de la
relación será igual.)
Secuencia de Operaciones
Se puede operar:
 Usando una sola expresión del álgebra relacional, que combine varias operaciones:
Π Nombre,Dirección (σ Vigencia=“S”(DUEÑO)) RESULTADO
 Aplicar una operación a la vez y crear relaciones de resultados Nombre Dirección

intermedios. A estas relaciones hay que darles nombre. Perez, Juan Lavalle 523
Juárez, Nicolás Córdoba 123
DUEÑO_VIG  (σ Vigencia=“S”(DUEÑO) Gómez, Ricardo Gral. Paz 22
Resultado  Π Nombre,Dirección (DUEÑO_VIG) Salas, Dalmiro Bolívar 2654
Pág. 105 de 141

3. Producto Cartesiano.
En álgebra relacional el producto de dos relaciones A y B es: A Veces B o AXB
Produce el conjunto de todas las tuplas t tales que t es el encadenamiento de una tupla a
perteneciente a A y de una b que pertenece a B. se utiliza el símbolo X para representar el producto.
Dueño x Móvil Móvil x Chofer
Pág. 106 de 141

4. Unión.
DUEÑO UNION
En álgebra relacional la unión de dos relaciones compatibles A y B es: CHOFER
A UNION B o A U B Rut Vigencia

5 S
Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B
13 N
o a Ambas.
Al igual que en teoría de conjuntos el símbolo U representa aquí la unión 6 N
de dos relaciones. 3 S
11 S
Ejemplo: 9 S
10 N
Π rut,vigencia (DUEÑO)  Π rut, vigencia (CHOFER) 4 S
2 S
14 N
Devuelve todos los Dueños y los Choferes. 1 S
12 N
7 N
Características:
 Se realiza automáticamente la eliminación de duplicados.
 Es una operación asociativa y conmutativa. N-aria
 R1 y R2 deben ser UNION COMPATIBLES
Relaciones Compatibles: En el álgebra relacional la compatibilidad

se aplica a las operaciones de Unión, Intersección y Diferencia. Cada
operación requiere dos relaciones que deben ser compatibles, esto
significa que deben ser del mismo grado, n, y el i-ésimo atributo de
cada una (i= 1, 2...n) se debe basar en el mismo dominio.
5. Intersección.
En álgebra relacional la intersección de dos relaciones compatibles A y B
A INTERSECCION B o A∩B
Produce el conjunto de todas las tuplas pertenecientes a A y B.

Al igual que en teoría de conjuntos el símbolo ∩ representa aquí
la intersección entre dos relaciones.
Ejemplo:
Π rut,vigencia (DUEÑO)  Π rut, vigencia (CHOFER)
Devuelve todos los dueños que también son choferes DUEÑO y

CHOFER
Características: Rut Vigencia

 R1 y R2 deben ser unión compatibles 5 S
 El resultado respeta el esquema de R1. 11 S
 Es una operación conmutativa y asociativa 10 N
Pág. 107 de 141

6. Diferencia
En álgebra relacional la diferencia entre dos relaciones compatibles A y B
A MENOS B o A – B
Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B.

Ejemplo:
Π rut,vigencia (DUEÑO) - Π rut, vigencia (CHOFER) DUEÑO - CHOFER
Rut Vigencia
Devuelve todos los dueños que NO son choferes
13 N
Características: 6 N
 R1 y R2 deben ser unión compatibles 3 S
 El resultado respeta el esquema de R1. 9 S
7. Join o Reunión.
En álgebra relacional el JOIN entre el atributo X de la relación A con el atributo Y de la relación B

produce el conjunto de todas las tuplas t tal que t es el encadenamiento de una tupla a
perteneciente a A y una tupla b perteneciente a B que cumplen con el predicado “A.X comp B.Y es
verdadero” (siendo comp un operador relacional y los atributos A.X y B.Y pertenecientes al mismo
dominio).
Si el operador relacional “comp” es “=” entonces el conjunto resultante es un EQUI-JOIN; si se
quita uno de éstos (usando una proyección) entonces el resultado es un JOIN-NATURAL.
Ejemplo:
σ Dueño.rut=Movil.rut_dueño(DUEÑO x MOVIL)
Características:
 Sirve para combinar tuplas relacionadas de dos relaciones en una sola tupla.
R1 |X| cond. de reunión R2
 El resultado es una relación Q con n+m atributos. Q tiene una tupla por cada
combinación de tuplas (una de R1 y otra de R2), siempre que la condición satisfaga la
condición de reunión. (Si fueran todas, sería X, producto cartesiano)
 La condición de reunión se especifica en términos de los atributos de las dos relaciones

R1 y R2, y se evalúa para cada combinación de tuplas.
 La condición tiene la forma Ai operador Bi donde Ai es un atributo de R1 y Bi es un
atributo de R2. El operador es de comparación (Mayor, menor, igual, etc.).
Si es un = se llama Equirreunión
Pág. 108 de 141

7. b.- Reunión Natural
 Se trata de una EQUIRREUNION seguida de la eliminación de los

atributos superfluos.
R1 |X| R2
 Es una combinación una SELECCIÓN con el PRODUCTO CARTESIANO y

queda con las tuplas donde los valores de los atributos que tienen el mismo
nombre en ambas tablas, son iguales.
 El esquema resultante tiene una sola vez los nombres de los atributos repetidos.
 En general, si R1 tiene n1 tuplas y R2 tiene n2 tuplas, el resultado de una

operación de reunión natural tendrá entre 0 (cero) y n 1*n2 tuplas. Tendrá cero
tuplas (o será vacía) si ninguna combinación de tuplas satisface la condición de
reunión.
8. División
En álgebra relacional el operador de división divide la relación A con grado m + n por la relación B
entregando como resultado una relación con grado m.
El atributo m + i de A y el atributo i de B deben estar definidos dentro del mismo dominio.
Así el resultado de
A DIVIDIDO POR B o A / B
produce la relación C con un sólo atributo X, tal que cada valor de x de C.X aparece como un valor
de A.X, y el par de valores (x, y) aparece en A para todos los valores y que aparecen en B.
Ejemplo:
Selecciona todos los autos a cuyos choferes les caduca la licencia hasta el 01/01/2009
Características:
 Esto significa que, para que una tupla t aparezca en el resultado T de la división,
los valores de t deben aparecer en R en combinac. con TODAS las tuplas de S.
 El operador de división se puede expresar como una secuencia de operaciones

como sigue:
T1  y ( R ) T2  y ((S X T1) – R) T  T1 –T2
Pág. 109 de 141

Otro
ejemplo
Álgebra Relacional vs. Cálculo Relacional
El álgebra relacional y el cálculo relacional tienen el mismo poder de expresión; es decir,
Todas las consultas que se pueden formular utilizando

álgebra relacional pueden también formularse utilizando el
cálculo relacional, y viceversa.
Esto fue probado por E. F. Codd en 1972. Este profesor se basó en un algoritmo ("algoritmo
de reducción de Codd") mediante el cual una expresión arbitraria del cálculo relacional se puede
reducir a la expresión semánticamente equivalente del álgebra relacional.
Se dice a veces que los lenguajes basados en el cálculo relacional son de "más alto nivel" o
"más declarativos" que los basados en el álgebra relacional porque el álgebra especifica
(parcialmente) el orden de las operaciones, mientras el cálculo lo traslada a un compilador o
interprete que determina el orden de evaluación más eficiente.
Cálculo relacional
El álgebra relacional y el cálculo relacional son formalismos diferentes que representan
distintos estilos de expresión del manejo de datos en el ámbito del modelo relacional. El álgebra
relacional proporciona una serie de operaciones que se pueden usar para decir al sistema cómo
construir la relación deseada a partir de las relaciones de la base de datos. El cálculo relacional
proporciona una notación para formular la definición de la relación deseada en términos de las
relaciones de la base de datos.
DATE dice que los lenguajes basados en el CR son descriptivos,

mientras que los algebraicos son prescriptivos.
El cálculo relacional toma su nombre del cálculo de predicados, que es una rama de la lógica.
Los lenguajes de cálculo relacional pueden ser de dos tipos:
 orientados a tuplas, en los que una variable se interpreta como si

representase las tuplas de una relación. (Propuesto por Codd)
 orientados a dominios, en los que una variable se interpreta como si
representase los valores de un dominio. (Propuesto por otros autores)
Pág. 110 de 141

En el cálculo de predicados (lógica de primer orden), un predicado es una función con

argumentos que se puede evaluar a verdadero o falso. Cuando los argumentos se sustituyen por
valores, la función lleva a una expresión denominada proposición, que puede ser verdadera o falsa.
Por ejemplo, las frases `Carlos Baeza es un miembro de la plantilla' y `Carlos Baeza gana más que
Amelia Pastor' son proposiciones, ya que se puede determinar si son verdaderas o falsas. En el
primer caso, la función ès un miembro de la plantilla' tiene un argumento (Carlos Baeza) y en el
segundo caso, la función `gana más que' tiene dos argumentos (Carlos Baeza y Amelia Pastor).
Si un predicado tiene una variable, como en ` x es un miembro de la plantilla', esta variable

debe tener un rango asociado. Cuando la variable se sustituye por alguno de los valores de su rango,
la proposición puede ser cierta; para otros valores puede ser falsa. Por ejemplo, si el rango de x es el
conjunto de todas las personas y reemplazamos x por Carlos Baeza, la proposición `Carlos Baeza es
un miembro de la plantilla' es cierta. Pero si reemplazamos x por el nombre de una persona que no
es miembro de la plantilla, la proposición es falsa.
Si F es un predicado, la siguiente expresión corresponde al conjunto de todos los valores de
x para los que F es cierto: x WHERE F(x)
Los predicados se pueden conectar mediante AND, OR y NOT para formar predicados compuestos.
1 .- Cálculo orientado a tuplas
En el cálculo relacional orientado a tuplas, lo que interesa es encontrar tuplas para las que se
cumple cierto predicado. El cálculo orientado a tuplas se basa en el uso de variables tupla. Una
variable tupla es una variable cuyo rango de valores son las tuplas de una relación.
El cálculo relacional de tuplas describe la información deseada sin dar un procedimiento

específico para obtenerla. Las consultas en el cálculo relacional de tuplas se expresan como
{ t | P(t)}, es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada t.
Siguiendo la misma notación, se utiliza t[A] para el valor de la tupla t en el atributo A.

Si sólo se desea obtener un atributo de la tupla, se utiliza el constructor “Existe” de la lógica
matemática. Así, si lo que se desea es el Nombre de los dueños de taxis que estén vigentes:
"Conjunto de todas las tuplas t tales que existe una tupla s en la relación Dueño para la que
los valores de t y de s son iguales en el atributo Nombre y el valor de s para el atributo vigencia = ‘S’
". La variable de tupla t se define sólo en el atributo Nombre, puesto que éste es el único atributo
para el que se especifica una condición para t. Así, el resultado es una relación sobre (Nombre).
Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado todos los
móviles de marca “chevrolet”, la consulta requiere de dos cláusulas “Existe” conectadas por el
operador de conjunción lógica “y”. Que se lee como el conjunto de todas las tuplas (tarifa)
correspondientes a los viajes que han hecho todos los móviles de marca “chevrolet”.
Considérese ahora la consulta “obtener todos los RUT de los dueños de móviles, cuyos móviles no
hayan efectuado nunca un viaje”:
que ocupa la cláusula “Existe” para exigir que el
dueño posea un móvil y la cláusula “no existe” para
eliminar a aquellos móviles que tengan viajes
realizados.
Pág. 111 de 141

La consulta que se presenta a continuación utiliza la implicación, la fórmula “P implica Q”

significa que “si P es verdad entonces Q debe ser verdad”, se introduce el constructor “para todo”.
Se desea Selecciona todos los autos a cuyos choferes les caduca la licencia el “01/01/1999”. (Que
es equivalente al ejemplo dado en el punto 6. (Diferencia).
2. -Cálculo orientado a dominios
En el cálculo relacional orientado a dominios las variables toman sus valores en dominios, en
lugar de tomar valores de tuplas de relaciones. Otra diferencia con el cálculo orientado a tuplas es
que en el cálculo orientado a dominios hay un tipo de comparación adicional, a la que se denomina
ser miembro de. Esta condición tiene la forma:
R(a :v , a :v , ...)
donde los a son atributos de la relación R y los v son variables dominio o constantes. La condición
se evalúa a verdadero si existe alguna tupla en R que tiene los valores especificados en los atributos
especificados.
Otros lenguajes
Aunque el cálculo relacional es difícil de entender y de usar, tiene una propiedad muy atractiva: es
un lenguaje no procedural. Esto ha hecho que se busquen técnicas no procedurales algo más
sencillas, resultando en dos nuevas categorías de lenguajes relacionales: orientados a
transformaciones y gráficos.
 Los lenguajes orientados a transformaciones son lenguajes no procedurales que utilizan

relaciones para transformar los datos de entrada en la salida deseada. Estos lenguajes tienen
estructuras que son fáciles de utilizar y que permiten expresar lo que se desea en términos de lo
que se conoce. Uno de estos lenguajes es SQL (Structured Query Language).
 Los lenguajes gráficos visualizan en pantalla una fila vacía de cada una de las tablas que indica el
usuario. El usuario rellena estas filas con un èjemplo' de lo que desea y el sistema devuelve los
datos que siguen tal ejemplo. Uno de estos lenguajes es QBE (Query-by-Example).
Otra categoría son los lenguajes de cuarta generación (4GL), que permiten diseñar una aplicación a
medida utilizando un conjunto limitado de órdenes en un entorno amigable (normalmente un entorno
de menús). Algunos sistemas aceptan cierto lenguaje natural, una versión restringida del idioma
inglés, al que algunos llaman lenguaje de quinta generación (5GL), aunque todavía se encuentra en
desarrollo.
Vistas
En la arquitectura de tres niveles estudiada se describe una vista externa como la estructura
de la base de datos tal y como la ve un usuario en particular. En el modelo relacional, el término
`vista' tiene un significado un tanto diferente. En lugar de ser todo el esquema externo de un
usuario, una vista es una relación virtual, una relación que en realidad no existe como tal.
Pág. 112 de 141

Una vista se puede construir realizando operaciones como las del álgebra relacional:
restricciones, proyecciones, concatenaciones, etc. a partir de las relaciones base de la base de datos.
Las relaciones base son aquellas que forman parte directa de la base de datos, las que se encuentran
almacenadas físicamente. Un esquema externo puede tener tanto relaciones base como vistas
derivadas de las relaciones base de la base de datos.
Una vista es el resultado dinámico de una o varias operaciones relacionales realizadas

sobre las relaciones base. Una vista es una relación virtual que se produce cuando un usuario la
consulta. Al usuario le parece que la vista es una relación que existe y la puede manipular como si se
tratara de una relación base, pero la vista no está almacenada físicamente. El contenido de una vista
está definido como una consulta sobre una o varias relaciones base. Cualquier operación que se
realice sobre la vista se traduce automáticamente a operaciones sobre las relaciones de las que se
deriva. Las vistas son dinámicas porque los cambios que se realizan sobre las tablas base que
afectan a una vista se reflejan inmediatamente sobre ella. Cuando un usuario realiza un cambio
sobre la vista (no todo tipo de cambios están permitidos), este cambio se realiza sobre las relaciones
de las que se deriva. Las vistas son útiles por varias razones:
 Proporcionan un poderoso mecanismo de seguridad, ocultando partes de la base de datos a ciertos

usuarios. El usuario no sabrá que existen aquellos atributos que se han omitido al definir una vista.
 Permiten que los usuarios accedan a los datos en el formato que ellos desean o necesitan, de modo
que los mismos datos pueden ser vistos con formatos distintos por distintos usuarios.
 Se pueden simplificar operaciones sobre las relaciones base que son complejas. Por ejemplo, se puede
definir una vista como la concatenación de dos relaciones. El usuario puede hacer restricciones y
proyecciones sobre la vista, que el DBMS traducirá en las operaciones equivalentes sobre la
concatenación.
 Se puede utilizar una vista para ofrecer un esquema externo a un usuario de modo que éste lo
encuentre `familiar'.
Las vistas proporcionan independencia de datos a nivel lógico, que también se da cuando se
reorganiza el nivel conceptual. Si se añade un atributo a una relación, los usuarios no se percatan de
su existencia si sus vistas no lo incluyen. Si una relación existente se reorganiza o se divide en varias
relaciones, se pueden crear vistas para que los usuarios la sigan viendo como al principio.
Cuando se actualiza una relación base, el cambio se refleja automáticamente en todas las vistas que
la referencian. Del mismo modo, si se actualiza una vista, las relaciones base de las que se deriva
deberían reflejar el cambio. Sin embargo, hay algunas restricciones respecto a los tipos de
modificaciones que se pueden realizar sobre las vistas. A continuación, se resumen las condiciones
bajo las cuales la mayoría de los sistemas determinan si se permite realizar una actualización:
 Se permiten las actualizaciones de vistas que se definen mediante una consulta simple sobre
una sola relación base y que contienen la clave primaria de la relación base.
 No se permiten las actualizaciones de vistas que se definen sobre varias relaciones base.
 No se permiten las actualizaciones de vistas definidas con operaciones de agrupamiento

(GROUP BY).
Pág. 113 de 141

Resumen
La relación es la estructura de datos del modelo relacional. Las relaciones se representan

gráficamente como tablas, donde las filas corresponden a las tuplas y las columnas corresponden a
los atributos. Los atributos se definen sobre dominios.
Las relaciones de una base de datos tienen una serie de propiedades: en la intersección de
cada fila con cada columna hay un solo valor (valor atómico), los nombres de los atributos de una
relación son todos distintos entre sí, los atributos no están ordenados, las tuplas no están ordenadas
y no hay tuplas repetidas. El grado de una relación es el número de atributos y la cardinalidad es el
número de tuplas.
Una superclave es un conjunto de atributos que identifica las tuplas de una relación de modo
único. Una clave candidata es una superclave minimal o irreducible. La clave primaria es la clave
candidata que se escoge para identificar las tuplas de una relación. Toda relación tiene siempre clave
primaria. Una clave ajena es un atributo o un conjunto de atributos que hacen referencia a la clave
primaria de otra relación. Cuando un atributo no tiene valor para una determinada tupla, bien porque
se desconoce o bien porque no tiene sentido para dicha tupla, se dice que es nulo.
La regla de integridad de entidades es una restricción que dice que ninguno de los atributos
que forman la clave primaria puede ser nulo. La regla de integridad referencial dice que los valores
de las claves ajenas deben coincidir con alguno de los valores de la clave primaria a la que hacen
referencia, o bien ser completamente nulos.
Los lenguajes relacionales de manejo de datos se pueden clasificar como procedurales, no

procedurales, orientados a transformaciones, gráficos, de cuarta generación o de quinta generación.
El álgebra relacional es un lenguaje procedural formal. Sus operaciones son: restricción, proyección,
producto cartesiano, unión, intersección, diferencia, división y varios tipos de concatenación (join).
Una vista es una relación virtual. Las vistas proporcionan seguridad y permiten que el
diseñador haga esquemas a medida de cada usuario. Las vistas se generan dinámicamente y no
todas son actualizables.
Pág. 114 de 141

CAPITULO VI
Bases de datos normalizadas
Medidas informales de la calidad para el diseño de esquemas de relaciones
Hasta ahora se ha supuesto que los atributos agrupados para formar un esquema de relación
surgen del sentido común del diseñador de la base de datos, y luego de la transformación de un
esquema especificado en el modelo Entidad-Relación a un esquema relacional. Sin embargo, no se
había contado con una medida formal de por qué una agrupación de atributos para formar un
esquema de relación puede ser mejor que otra, es decir, contar con la mera intuición del diseñador
significa no fundarnos en ninguna medida de los apropiado del diseño o de su calidad.
Para intentar “elegir” buenos esquemas de relación se ha desarrollado una teoría que
pueda medir formalmente las razones por las que una agrupación de atributos es mejor que otra.
Existen dos niveles en los que podemos medir la “bondad” de los esquemas de relación: lógico y de
manipulación (o de almacenamiento).
Nivel lógico: se refiere a la manera en que los usuarios interpretan los esquemas de relación y el
significado de sus atributos.
Nivel de manipulación: se refiere a cómo se almacenan y actualizan las tuplas de una relación base.
Pautas informales de diseño para los esquemas de relaciones

 Semántica de los atributos
 Reducción de los valores redundantes en las tuplas
 Reducción de los valores nulos en las tuplas
 Prohibición de tuplas espurias.
El significado o semántica especifica cómo se han de interpretar los atributos almacenados

en una tupla. Cuanto más fácil sea de explicar la semántica de la relación, mejor será el diseño del
esquema correspondiente.
Pág. 115 de 141

En cuanto a la redundancia en los valores de las tuplas, uno de los objetivos del diseño es
minimizar el espacio de almacenamiento que ocupan las relaciones base (archivos). Los valores
redundantes provocan ciertas anomalías, de acuerdo a la tarea que se desea realizar.
a) Anomalías de Inserción: al insertar una nueva tupla, los valores de algunos atributos deben
ser congruentes con los valores de un atributo igual en otras tuplas. Para el/los atributo/s
redundantes será difícil insertar una tupla con valores nuevos.
b) Anomalías de Eliminación: si se elimina una tupla con la última información de un atributo
correspondiente a otra relación se perderá información de la base de datos.
c) Anomalías de Modificación: si alteramos el valor de uno de los atributos redundantes
deberemos actualizar todas las relaciones que los contengan.
Por otro lado, la reducción de valores nulos en las tuplas es muy importante para evitar que
ocurran los siguientes problemas:
- Desperdicio de espacio de almacenamiento

- Dificultad en la comprensión de la semántica de los atributos (varias
interpretaciones)
- Dificultad en las especificaciones de las operaciones de Reunión en el nivel lógico.
- No saber cómo manejarlos cuando se aplican funciones agregadas.
Finalmente, la presencia de tuplas espurias es prohibitiva, ya que representan información

errónea. Entonces, es importante hacer un buen diseño para:
 Evitar la repetición de la información, como también la pérdida de información.

 Posibilitar la representación de toda la información.
Pauta 1
Diseñe un esquema de relación de modo que sea fácil explicar su significado. No combine atributos
de varios tipos de entidades y tipos de vínculos en una sola relación. Es decir, que el esquema de
relación sea semánticamente claro y no confuso.
Pauta 2
Diseñe los esquemas de las relaciones de modo que no haya anomalías de actualización. Si las hay
señálelas con claridad para que los programas que actualicen la base de datos operen
correctamente.
Pauta 3
Hasta donde sea posible, evite incluir en una relación base atributos cuyos valores puedan ser nulos.
Si no es posible, asegúrese que se apliquen en casos excepcionales y no a la mayoría de las tuplas.
Pauta 4
Diseñe los esquemas de relación de modo que puedan reunirse mediante condiciones de igualdad
sobre atributos que sean claves primarias o externas, a fin de garantizar que no se formarán tuplas
espurias.
Una tabla o esquema de relación está bien diseñado cuando

cumple con las 6 (seis) formas normales, 1NF, 2NF, 3NF, BCNF,
5NF, 6NF, cuya base o fundamento es el concepto de
Dependencia Funcional.
Pág. 116 de 141

Dependencias Funcionales
Definición formal: Sea R una relación y sean x e y atributos de R, x  y se cumple en R,

entonces para cualquier par de tuplas t1 y t2 de R se cumple:
t1 [x] = t2 [x]  t1 [y] = t2 [y]
Así pues, x determina funcionalmente a y en un esquema de relación R si y sólo si, siempre que
dos tuplas r(R) coincidan en su valor x, necesariamente deben coincidir en su valor y.
¡Importante!
Si x es una clave candidata de R (no se puede repetir el valor de x en otra tupla) entonces x  y
para cualquier subconjunto de atributos y de R. Que x  y en R no dice absolutamente nada de y 
x en R.
 Las dependencias funcionales son propiedades inherentes al contenido semántico de los

datos, que se han de cumplir para cualquier extensión del esquema de relación y forman parte
de las restricciones del usuario.
 La principal utilidad de las dependencias funcionales es describir mejor un esquema de

relación mediante la especificación de restricciones sobre sus atributos que deben cumplirse
siempre.
 Las extensiones de relación r(R) que satisfagan las restricciones de dependencia funcional se
llaman extensiones permitidas de R (o estados de relación permitidos)
Desde este momento, se asociará un esquema de relación R,

sus atributos y sus dependencias funcionales, ya que una
dependencia funcional es una propiedad del esquema de
relación R (intensión) y no de un ejemplar de relación permitido
r de R (extensión).
Reglas de inferencia para las dependencias funcionales
El conjunto de todas las dependencias funcionales que se cumplen en todos los ejemplares
de relación permitidos que satisfagan las dependencias F se llama clausura transitiva de F (F*).
Tal conjunto se puede determinar a partir de F utilizando sólo las reglas de inferencia R1, R2,
y R3, conocidas como reglas de inferencia de Armstrong (son tres, pero de ellas se infieren otras
tres). Sólo serán mencionadas de la siguiente forma:
Axioma 1: Reflexividad  Un conjunto de atributos siempre se determina a sí mismo.
Axioma 2: Aumento  Añadir el mismo conjunto de atributos a ambos miembros de una

dependencia produce otra dependencia válida.
Pág. 117 de 141

Axioma 3: Transitividad  Las dependencias funcionales son transitivas.
Axioma 4: Descomposición
Axioma 5: Unión (o aditiva)
Axioma 6: PseudoTransitividad
Las reglas de inferencia de Armstrong son:

Correctas: dado un conjunto de dependencias funcionales especificado sobre el esquema e
relación R, cualquier dependencia que podamos inferir de F con los axiomas se cumplirá en todos
los estados de relación r de R que satisfagan las dependencias F.
Completas: El empleo repetido de (1,2,3) para inferir dependencias funcionales (hasta no poder
inferir más) producirá un conjunto completo de todas las dependencias posibles que e pueden
inferir de F.
Conjunto Canónico: es el conjunto mínimo de dependencias funcionales que nos permiten calcular
la clausura transitiva. Debe garantizar tres aspectos:
a) Que no existan dependencias redundantes (o sea que e puedan reducir en base a otras
aplicando los axiomas de Armstrong.)
b) Que no haya atributos extraños en las dependencias a izquierda y a derecha.
c) Que no existan dependencias de la forma: x1  y U x2  y porque en realidad esto

significa que x1 = x2
Proceso de normalización
La normalización de los datos es un proceso durante el cual los esquemas de relación
insatisfactorios se descomponen repartiendo sus atributos en esquemas de relación más pequeños
que tienen las propiedades deseables.
En el proceso de normalización, se somete un esquema de relación para certificar si
pertenece o no a cierta forma normal. Es un estándar que consiste, básicamente, en un proceso de
conversión de las relaciones entre las entidades, evitando redundancia de datos y anomalías.
Las formas normales proveen a los diseñadores de un marco formal para analizar los
esquemas de relación en base a sus claves y a las dependencias funcionales entre sus atributos, y de
una serie de pruebas que pueden efectuarse sobre esquemas de relación individuales de modo que
la base de datos relacional pueda normalizarse hasta el grado deseado.
Las formas normales consideradas aparte de otros factores no garantizan un buen
diseño de la base de datos. El proceso de normalización por descomposición debe confirmar también,
la existencia de propiedades adicionales que los esquemas e relación, en conjunto, deben poseer.
Dos de ellas son:
 Reunión sin pérdidas: garantizando que no se produzcan tuplas espurias.
 Conservación de las dependencias: asegurando que todas las dependencias

funcionales están representadas en algunas de las relaciones individuales
resultantes.
Los diseñadores
 de bases de datos deben normalizar hasta la forma normal más alta posible.
Pág. 118 de 141

Algunas definiciones...
 Una superclave de R es un conjunto de atributos S  R con la propiedad de que no habrá

un par de tuplas t1 y t2, en ningún estado de relación permitido r(R) tal que t1[S] = t2[S].
 Una clave de R es una superclave mínima. La eliminación de cualquier atributo K hará que
deje de ser una superclave.
 Se llama atributo primo a un atributo de un esquema de relación que es miembro de

cualquier clave de R.
 Se llama atributo no primo a un atributo que no es miembro de ninguna clave candidata.
Un ejemplo...
Tomando como referencia la tabla siguiente:
AUTORES Y LIBROS
NOMBRE NACION CODLIBRO TITULO EDITOR
Date USA 999 IBD AW
Ad.Mig. ESP 888 CyD RM
Ma.Piat. ITA 777 CyD RM
Date USA 666 BdD AW
Se plantean una serie de problemas:
 Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.
 Anomalías de modificación: Si Ad.Mig. y Ma.Piat. desean cambiar de editor, se modifica

en los 2 lugares. A priori no podemos saber cuántos autores tiene un libro. Los errores
son frecuentes al olvidar la modificación de un autor. Se pretende modificar en un sólo
sitio.
 Anomalías de inserción: Se desea dar de alta un autor sin libros, en un principio.

NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores nulos.
 Asegurando:
 Integridad entre los datos,
 Consistencia de la información.
Definición de la clave
Antes de proceder a la normalización de una tabla lo primero que debe definirse es la clave;
esta clave deberá contener un valor único para cada registro (no podrán existir dos valores iguales
en toda la tabla) y podrá estar formado por un único campo o por un grupo de campos.
En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el

nombre del alumno ya que pueden existir varios alumnos con el mismo nombre. Podríamos
considerar la posibilidad de definir como clave los campos nombre y apellidos, pero estamos en la
misma situación: podría darse el caso de alumnos que tuvieran los mismos apellidos y el mismo
nombre (Juan Fernández Martín).
La solución en este caso es asignar un código de alumno a cada uno, un número que identifique al
alumno y que estemos seguros que es único.
Pág. 119 de 141

Para especificar las formas normales continuaremos con el ejemplo analizado para el modelo
relacional de la COMPAÑÍA. Y retomamos el esquema obtenido luego de la transformación.
Primera forma normal (1NF)
Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de
los campos contiene un único valor para un registro determinado. Es decir, la misma establece que
“los dominios de los atributos deben incluir sólo valores atómicos (simples, indivisibles)
y que el valor de cada atributo en una tupla debe ser un valor individual proveniente del
dominio de ése atributo”.
Históricamente se definió para prohibir los atributos multivaluados, los atributos compuestos
y sus combinaciones. En otras palabras, 1FN prohíbe las “relaciones dentro de relaciones” o
relaciones como atributos de tuplas.
Consideremos el esquema de relación DEPARTAMENTO cuya clave primaria es NúmeroD, y

supongamos que la extendemos al incluir el atributo LugaresD. Un departamento puede tener varios
lugares.
NombreD NúmD NSSGte LugaresD
Investigación 5 333444555 Santiago, Salta Catamarca
Administración 4 987654321 Santiago
Dirección 1 888886555 Catamarca
Podemos observar que los registros de códigos 4 y 1 si cumplen la primera forma normal,
cada campo del registro contiene un único dato, pero no ocurre así con el registro 5 ya que en el
campo LugaresD contiene más de un dato cada uno. La solución en este caso es crear dos tablas del
siguiente modo:
Tabla A: Departamentos
NombreD NúmD NSSGte
Investigación 5 333444555
Administración 4 987654321
Dirección 1 888886555
Tabla B: Lugares_Dptos
NúmeroD Lugar
5 Santiago
5 Salta
5 Catamarca
4 Santiago
1 Catamarca
Como se puede comprobar ahora todos los registros de ambas tablas contienen valores
únicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.
Existe otra posibilidad, que cumple con la 1NF, pero que presenta redundancia:
Pág. 120 de 141

NombreD NúmD NSSGte LugaresD
Investigación 5 333444555 Santiago
Investigación 5 333444555 Salta
Investigación 5 333444555 Catamarca
Administración 4 987654321 Santiago
Dirección 1 888886555 Catamarca
Sin embargo, esta solución experimentará más descomposiciones durante los pasos de
normalización subsecuentes hasta dar con la solución arriba expuesta.
Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.
Segunda forma normal (2NF)
La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave
definida. Si todos los campos dependen directamente de la clave se dice que la tabla está es
segunda forma normal (2NF).
Se basa en el concepto de Dependencia Funcional Total. Una dependencia funcional x

y es total si la eliminación de cualquier atributo A de X hace que la dependencia deje de ser válida.
Un esquema de relación R está en 2NF si todo atributo no primo A en R depende
funcionalmente de manera total de la clave primaria de R.
Supongamos que en ejemplo de COMPAÑÍA se hubiese considerado necesario, por diseño, construir
una tabla que contenga los años que cada empleado ha estado trabajando en cada departamento:
Número Empleado Número Dpto. Nombre Departamento Años

1 5 Juan Contabilidad 6
2 1 Pedro Sistemas 3
3 4 Sonia I+D 1
4 1 Verónica Sistemas 10
2 5 Pedro Contabilidad 5
Tomando como punto de partida que la clave de esta tabla está formada por los campos
número de empleado y número de departamento, podemos decir que la tabla se encuentra en
primera forma normal, por tanto vamos a estudiar la segunda:
 El campo nombre no depende funcionalmente de toda la clave, sólo depende del código del
empleado.
 El campo departamento no depende funcionalmente de toda la clave, sólo del código del
departamento.
 El campo años si que depende funcionalmente de la clave ya que depende del código del
empleado y del código del departamento (representa el número de años que cada empleado
ha trabajado en cada departamento)
Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no está en
segunda forma normal, la solución es la siguiente:
Pág. 121 de 141

Tabla A Tabla B Tabla C

NúmeroE Nombre NúmeroD Dpto. NúmeroE NúmeroD Años
1 Juan 4 I+D 1 5 6
2 Pedro 1 Sistemas 2 1 3
3 Sonia 5 Contabilidad 3 4 1
4 Verónica 4 1 10
Podemos observar que ahora si se encuentras las tres tablas en segunda forma normal,
considerando que la tabla A tiene como índice el campo NúmeroE, la tabla B NúmeroD y la tabla C
una clave compuesta por los campos NúmeroE y NúmeroD.
Tercera forma normal (3NF)
Se dice que una tabla está en tercera forma normal si y solo si los campos de la tabla
dependen únicamente de la clave, dicho en otras palabras los campos de las tablas no dependen
unos de otros.
Se basa en el concepto de Dependencia Transitiva. Una dependencia funcional x y es

una dependencia transitiva si existe un conjunto de atributos Z que no sea un subconjunto de
cualquier clave de R, y se cumplen tanto x  z como z  y.
De acuerdo a la definición original de Codd, un esquema de relación R está en 3NF si

está en 2NF y ningún atributo no primo de R depende transitivamente de la clave
primaria.
Tomando como referencia el ejemplo anterior, supongamos que cada empleado sólo puede
estar asignado a un departamento a la vez y que deseamos almacenar el número de seguro social
del gerente de departamento De pronto podemos plantear la siguiente estructura:
NombreE NSS FechaN Dirección NúmeroD NombreD NSSGte
Estudiemos la dependencia de cada campo con respecto a la clave código:
 NombreD depende directamente del NúmeroD.

 NombreE depende de igual modo del número del empleado.
 El número de seguro social del Gerente, aunque en parte también interesa al empleado, está
más ligado al departamento donde trabaja el empleado.
Por esta última razón se dice que la tabla no está en 3NF. La solución sería la siguiente:
NombreE NSS FechaN Dirección NúmeroD ED1
ED2
NúmeroD NombreD NSSGte
Una vez conseguida la tercera forma normal, se puede estudiar la cuarta forma normal.
Pág. 122 de 141

Cuarta forma normal (4NF) o Forma Normal de Boyce-Codd (FNBC)
Una tabla está en cuarta forma normal si y sólo si para cualquier combinación clave - campo
no existen valores duplicados. Es más estricta que la 3NF, lo que significa que toda relación que está
en FNBC también está en 3NF; sin embargo, una relación en 3NF no está necesariamente en FNBC.
Un esquema de relación R está en BCNF si siempre que una dependencia funcional x  A

es válida en R, entonces x es una superclave de R.
Un esquema de relación R está en BCNF si para todas las dependencias funcionales que valen en R
de la forma x  y, y se cumple una de las siguientes condiciones:
a) x y es trivial ( y  x) o
b) x es superclave de R.
En la práctica, casi todos los esquemas de relación que están en 3NF, también están en BCNF
Veámoslo con un ejemplo:
Geometría
Figura Color Tamaño
Cuadrado Rojo Grande
Cuadrado Azul Grande
Cuadrado Azul Mediano
Círculo Blanco Mediano
Círculo Azul Pequeño
Círculo Azul Mediano
Comparemos ahora la clave (Figura) con el atributo Tamaño, podemos observar que Cuadrado
Grande está repetido; igual pasa con Círculo Azul, entre otras.
Estas repeticiones son las que se deben evitar para tener una tabla en 4NF.
La solución en este caso sería la siguiente:
Tamaño Color
Figura Color
Figura Tamaño
Cuadrado Rojo
Cuadrado Grande
Cuadrado Azul
Cuadrado Pequeño
Círculo Blanco
Círculo Mediano
Círculo Azul
Círculo Pequeño
Ahora si tenemos nuestra base de datos en BCNF
Otras formas normales

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que no detallo por su
dudoso valor práctico ya que conduce a una gran división de tablas y la forma normal dominio / clave
(FNDLL) de la que no existe método alguno para su implantación.
Pág. 123 de 141

CAPITULO VII
SQL como lenguaje de consultas relacionales

Los lenguajes formales proporcionan una notación concisa para la representación de
consultas. Sin embargo, los sistemas de base de datos necesitan un lenguaje de consultas más
cómodo para el usuario.
Aunque SQL se considere un lenguaje de consultas, contiene

muchas otras capacidades que incluyen características para
definir estructuras de datos, modificación de datos y la
especificación de restricciones de integridad.
Los sistemas de gestión de base de datos con soporte SQL más utilizados son: DB2, Oracle,
SQL Server, Sybase ASE, MySQL, PostgreSQL, Firebird.
SQL se ha establecido como el lenguaje estándar de base de datos relacionales. Hay

numerosas versiones de SQL. La versión original se desarrolló en el laboratorio de investigación de
San José, California (San José Research Center) de IBM, este lenguaje originalmente denominado
Sequel, se implementó como parte del proyecto System R, a principios de 1970. Desde entonces ha
evolucionado a lo que ahora se conoce como SQL (Structured Query Language, o lenguaje
estructurado de consultas).
En 1986, ANSI (American National Standards Institute, Instituto Nacional Americano de

Normalización) e ISO (International Standards Organization, Organización Internacional de
Normalización) Publicaron una norma de SQL denominada SQL-86. En 1987 IBM publicó su propia
norma de SQL denominada SAA-SQL (System Application Architecture Database Interfaz, Interfaz de
base de datos para arquitecturas de aplicación de sistemas).
En 1989 se publicó una norma extendida para SQL (SQL-89) y actualmente los DBMS son
compatibles al menos con esta norma. La norma actual de SQL de ANSI/ISO es la SQL-92. Se debe
tener en cuenta que algunas implementaciones de SQL pueden ser compatibles sólo con SQL-89, no
siéndolo con SQL-92. El ANSI SQL sufrió varias revisiones y agregados a lo largo del tiempo:
Pág. 124 de 141

Año Nombre Alias Comentarios
1986 SQL-86 SQL-87 Primera publicación hecha por ANSI. Confirmada por ISO en
1987.
1989 SQL-89 Revisión menor.
1992 SQL-92 SQL2 Revisión mayor.
1999 SQL:1999 SQL3 Se agregaron expresiones regulares, consultas recursivas

(para relaciones jerárquicas), triggers y algunas
características orientadas a objetos.
2003 SQL:2003 Introduce algunas características de XML, cambios en las

funciones, estandarización del objeto sequence y de las
columnas autonuméricas.
Características generales
 El SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los
sistemas relacionales permitiendo gran variedad de operaciones sobre los mismos.
 Es un lenguaje declarativo de alto nivel o de no procedimiento, que gracias a su fuerte
base teórica y su orientación al manejo de conjuntos de registros, y no a registros individuales,
permite una alta productividad en codificación. De esta forma una sola sentencia puede equivaler a
uno o más programas que utilizasen un lenguaje de bajo nivel orientado a registro.
Funcionalidad
El SQL proporciona funcionalidad más allá de la simple consulta (o recuperación) de datos.

Asume el papel de:
 lenguaje de definición de datos (LDD),
 lenguaje de definición de vistas (LDV) y
 lenguaje de manipulación de datos (LMD).
Además permite:
 la concesión y denegación de permisos,
 la implementación de restricciones de integridad y controles de transacción,
 y la alteración de esquemas.
Las primeras versiones del SQL incluían funciones propias de

lenguaje de definición de almacenamiento (LDA) pero fueron
suprimidas en los estándares más recientes con el fin de
mantener el lenguaje sólo a nivel conceptual y externo.
Pág. 125 de 141

Lenguaje de definición de datos (DDL – Data Definition Language)
Para representar un esquema de bases de datos se utiliza un sublenguaje especial

llamado lenguaje de definición de datos. El resultado de la compilación de estas instrucciones es un
conjunto de tablas, relaciones y reglas cuyas definiciones quedan almacenadas en un archivo (tabla u
otro medio de almacenamiento) que contiene “metadatos”, esto es, datos acerca de datos. Este
archivo comúnmente llamado diccionario de datos (o catálogo del sistema) es el que se consulta toda
vez que se quiere leer, modificar o eliminar los datos de la base de datos.
Además, permite cumplir otras características antes mencionadas (que no poseen los
lenguajes formales de consultas), estas son:
 Definición de vistas. El DDL de SQL incluye instrucciones para la definición de vistas.

 Autorización. El DDL de SQL incluye instrucciones para la especificación de los derechos de
acceso a los objetos de la base de datos.
 Integridad. El DDL de SQL también incluye un conjunto de sentencias para la especificación
de restricciones de integridad.
Lenguaje de manipulación de datos (DML – Data Manipulation Language)
Una vez definido el Esquema de una base de datos, contenido en el Catálogo del Sistema,
será necesario comenzar con la incorporación de los datos mismos y continuar con las demás
operaciones que convenientemente sean necesarias realizar. De ello se deriva que la manipulación
de datos implica entonces:
 Inserción de nueva Información.
 Eliminación (Borrado) de información existente.
 Modificación de Información Almacenada
 Recuperación de Información.
Otras características de SQL.
SQL no es un lenguaje de programación. Fue diseñado con el único propósito de acceder a datos
estructurales. Hay, sin embargo, capacidades que van más allá del cálculo o del álgebra relacional.
Aquí tenemos una lista de algunas características proporcionadas por SQL que no forman parte del
álgebra y del cálculo relacional:
 Comandos para inserción, borrado o modificación de datos.
 Funciones agregadas: Operaciones tales como promedio (average), suma (sum), máximo
(máx), etc. se pueden aplicar a las columnas de una relación para obtener una cantidad
única.
 Capacidades aritméticas: En SQL es posible incluir operaciones aritméticas así como

comparaciones, por ejemplo A < B + 3. Nótese que ni la suma (+) ni otros operadores
aritméticos aparecían en el álgebra relacional ni en cálculo relacional.
 Asignación y comandos de impresión: es posible imprimir una relación construida por

una consulta y asignar una relación calculada a un nombre de relación.
 Control de transacciones. SQL incluye órdenes para la especificación de los estados de

una transacción, algunas implementaciones permiten además el bloqueo explícito de objetos
de datos con el fin de manejar control de concurrencia.
Pág. 126 de 141

Recuperación de Datos
Select
El comando más usado en SQL es la instrucción SELECT, que se utiliza para recuperar datos. La
sintaxis es:
SELECT [ALL|DISTINCT|TOP n] { * | expr_1 [AS c_alias_1] [, ... [, expr_k [AS c_alias_k]]]}
FROM table_name_1 [t_alias_1] [, ... [, table_name_n [t_alias_n]]]
[WHERE condition]
[GROUP BY name_of_attr_i [,... [, name_of_attr_j]] [HAVING condition]]
[{UNION [ALL] | INTERSECT | EXCEPT} SELECT ...]
[ORDER BY name_of_attr_i [ASC|DESC] [, ... [, name_of_attr_j [ASC|DESC]]]];
Los siguientes predicados (entre la claúsula SELECT y la lista de selección) limitan las filas
seleccionadas:
 DISTINCT: Selecciona únicamente las filas con valor distinto en los campos
incluidos en el SELECT
 DISTINCTROW: Selecciona aquellas filas diferentes en todos sus campos,
independientemente de los campos seleccionados.
 TOP n: Limita la selección a las n primeras filas. Se puede indicar un valor
porcentual con TOP n PERCENT
* : Indica que se incluyen TODOS los atributos, a menos que se mencione una lista.
FROM : Indica de cuál/es tabla/s se extraerá la información.
WHERE : Permite el filtrado de filas, es decir, explicitar una condición de búsqueda de tuplas.
ORDER BY: Permite indicar el/los campos que mostrarán y liderarán el ordenamiento de las tuplas.
GROUP BY: Permite “agrupar” tuplas según un campo común. Permite funciones de agregación.
HAVING: Permite un nuevo filtrado, pero sobre las tuplas afectadas por el GROUP BY, en función
de una condición aplicable a cada grupo de filas.
UNION [ALL] | INTERSECT | EXCEPT: permiten implementar otras operaciones del AR, y en especial,
para la implementación de subconsultas o consultas anidadas.
En particular…
La cláusula WHERE es de fundamental importancia, ya que permite “definir” el criterio de búsqueda a

utilizar para la selección de tuplas, es decir, establecer las condiciones de filtrado.
Pág. 127 de 141

Las condiciones pueden ser de distintos tipos:
Comparación: Operadores >, <, >=, <= y <>.

SELECT campos FROM tabla WHERE campo > valor
Pertenencia a rango: Operador BETWEEN:

SELECT campos FROM tabla
WHERE campo BETWEEN inferior AND superior
Pertenencia a conjunto o lista: Operador IN seguido de una lista de elementos entre paréntesis.

WHERE campo IN (valor, valor, valor, …)
Operador LIKE

WHERE campo LIKE patron
El patrón permite búsquedas con comodines:

“%” Representa 0 o más caracteres
“_” Representa un carácter
(desconocidos): El operador IS NULL permite determinar si existe ó no valor:

WHERE campo IS NULL
En una cláusula WHERE Se pueden combinar múltiples condiciones (de cualquiera de los tipos)
mediante los operadores lógicos AND, OR y NOT, determinando con el uso de paréntesis el orden
de evaluación (y contrarrestando el efecto de la prioridad de operadores). Not niega una
expresión booleana y palabras claves como like, null, between e in.
Se ilustrará ahora la compleja sintaxis de la instrucción SELECT con varios ejemplos.
EJEMPLOS: Select sencillas
Aquí tenemos algunos ejemplos sencillos utilizando la instrucción SELECT:
Ejemplo 1. Query sencilla con cualificación

Para recuperar todas las tuplas de la tabla EMPLEADO donde el atributo SALARIO es mayor que 350
(filtrado de filas), formularemos la siguiente consulta:
SELECT * FROM EMPLEADO WHERE SALARIO > 350;
Utilizando "*" en la instrucción SELECT solicitaremos todos los atributos de la tabla. Si queremos
recuperar sólo los atributos APELLIDO, SEXO Y SALARIO de la tabla EMPLEADO utilizaremos
(filtrado de campos) la instrucción:
SELECT APELLIDO, SEXO, SALARIO FROM EMPLEADO WHERE SALARIO > 350;
Nótese que el SELECT anterior se corresponde, en su primera parte a la "proyección" en álgebra

relacional. Las cualificaciones en la cláusula WHERE, que se corresponden con la “selección”.
Pág. 128 de 141

Pueden también estas cualificaciones (expresiones lógicas), conectarse lógicamente utilizando las
palabras claves OR, AND, y NOT:
SELECT APELLIDO,SEXO,SALARIO FROM EMPLEADO

WHERE SEXO= 'F' AND (APELLIDO= “PEREZ” OR APELLIDO=”DIAZ”);
Las operaciones aritméticas se pueden utilizar en la lista de objetivos y en la claúsula WHERE.
Por ejemplo, si queremos conocer cuánto es el descuento para la jubilación del empleado,
consistente en el 13% del salario, y listar sólo de los que ése monto no supere los $50, podríamos
utilizar la siguiente consulta:
SELECT APELLIDO,SALARIO*0.12 AS PORCEN FROM EMPLEADO
WHERE SALARIO*0.12 <= 50
Nótese que la palabra PORCEN tras la palabra clave AS es el nuevo título de la segunda columna
(campo calculado; atributo derivado). Esta técnica puede utilizarse para cada elemento de la
lista objetivo para asignar un nuevo título a la columna resultante. Este nuevo título recibe el
calificativo de "un alias". El alias no puede utilizarse en todo el resto de la consulta.
Joins (Reunión)
Ejemplo 2. El siguiente ejemplo muestra como las joins se realizan en SQL.
Para cruzar tres tablas a través de sus atributos comunes, formularemos la siguiente instrucción:
SELECT E.APELLIDO, P.NOMBREP, T.HORAS FROM EMPLEADO E, PROYECTO P TRABAJAEN T

WHERE T.NSSE = E.NSS AND T.NUMP = P.NUMEROP;
En la cláusula FROM ES POSIBLE INTRODUCIR un alias al nombre para cada relación en caso que
existan atributos con nombre común en las relaciones. Podemos distinguir entre los atributos con
nombre común simplificando la adicción de un prefijo al nombre del atributo con el nombre del alias
seguido de un punto.
Operativamente, primero se realiza el producto cartesiano: EMPLEADO × PROYECTO × TRABAJAEN.

Luego se seleccionan únicamente aquellas tuplas que satisfagan las condiciones dadas en la cláusula
WHERE (es decir, los atributos con nombre común deben ser iguales). Finalmente se eliminan las
columnas repetidas.
Operadores Agregados
SQL proporciona operadores agregados (como son AVG, COUNT, SUM, MIN, MAX) que toman el
nombre de un atributo como argumento. El valor del operador agregado se calcula sobre todos los
valores de la columna especificada en la tabla completa. Si se especifican grupos en la consulta, el
cálculo se hace sólo sobre los valores de cada grupo (vean la siguiente sección).
Ejemplo 3. Funciones Agregadas

Si queremos conocer el SALARIO promedio de todos los empleados de la tabla EMPLEADO,
utilizaremos la siguiente consulta:
SELECT AVG(SALARIO) AS PROM_SALARIO FROM EMPLEADO;
Si queremos conocer cuántos proyectos se recogen en la tabla PROYECTO, utilizaremos la

instrucción:
SELECT COUNT(NUMEROP) FROM PROYECTO;
Pág. 129 de 141

Agregación por Grupos
SQL nos permite particionar, separar las tuplas de una tabla en grupos. En estas condiciones, los
operadores agregados descritos antes pueden aplicarse a los grupos (es decir, el valor del operador
agregado no se calculan sobre todos los valores de la columna especificada, sino sobre todos los
valores de un grupo. El operador agregado se calcula individualmente para cada grupo).
El particionamiento de las tuplas en grupos se hace utilizando las palabras clave GROUP BY
seguidas de una lista de atributos que definen los grupos. Si tenemos GROUP BY A1,..., Ak
habremos particionado la relación en grupos, de tal modo que dos tuplas son del mismo grupo si y
sólo si tienen el mismo valor en sus atributos A 1,..., Ak.
Ejemplo 4. Agregados
Si queremos conocer cuántos dependientes existen por cada empleado formularemos la consulta:
SELECT E.APELLIDO, E.NSS, COUNT(DE.NSSE) FROM EMPLEADO E, DEPEND DE

WHERE E.NSS = DE.NSSE GROUP BY E.NSS, E.APELLIDO;
En nuestro ejemplo, obtenemos varios grupos y ahora podemos aplicar el operador agregado COUNT
para cada grupo, obteniendo el resultado total de la consulta dada anteriormente.
Nótese que para el resultado de una consulta utilizando GROUP BY y operadores agregados para dar
sentido a los atributos agrupados, debemos primero obtener la lista objetivo. Los demás atributos
que no aparecen en la cláusula GROUP BY se seleccionarán utilizando una función agregada. Por otro
lado, no se pueden utilizar funciones agregadas en atributos que aparecen en la cláusula GROUP BY.
Having
La cláusula HAVING trabaja de forma muy parecida a la cláusula WHERE, y se utiliza para considerar
sólo aquellos grupos que satisfagan la cualificación dada en la misma. Las expresiones permitidas en
la cláusula HAVING deben involucrar funcionen agregadas. Cada expresión que utilice sólo atributos
planos deberá recogerse en la cláusula WHERE. Por otro lado, toda expresión que involucre
funciones agregadas debe aparecer en la cláusula HAVING.
Ejemplo 5. Having
Si queremos solamente los empleados que posean más de un 3 dependientes, utilizaremos la
consulta:
SELECT D.NUMEROD, D.NOMBRED, COUNT(P.NUMEROP)

FROM DEPART D, PROYECTO P
WHERE D.NUMEROD = P.NUMD GROUP BY .NUMEROD,
D.NOMBRE HAVING COUNT(P.NUMEROP) > 3;
Pág. 130 de 141

Subconsultas
En las clausulas WHERE y HAVING se permite el uso de subconsultas (subselects) en cualquier lugar
donde se espere un valor. En este caso, el valor debe derivar de la evaluación previa de la
subconsulta. El uso de subconsultas amplía el poder expresivo de SQL.
Ejemplo 6. SubSelect
Si queremos conocer los empleados que tienen mayor salario que el empleado de apellido 'Pérez',
utilizaremos la consulta:
SELECT * FROM EMPLEADOS

WHERE SALARIO > (SELECT SALARIO FROM EMPLEADO WHERE APELLIDO='Pérez');
Cuando revisamos la consulta anterior, podemos ver la palabra clave SELECT dos veces. La primera
al principio de la consulta - a la que nos referiremos como la SELECT externa - y la segunda en la
cláusula WHERE, donde empieza una consulta anidada - nos referiremos a ella como la SELECT
interna.
Para cada tupla de la SELECT externa, la SELECT interna deberá ser evaluada. Tras cada evaluación,
conoceremos el precio de la tupla llamada 'Pérez', y podremos chequear si el salario de la tupla
actual es mayor.
Si queremos conocer todos los empleados que no tienen ningún dependiente (por ejemplo, los
empleados solteros sin nadie a cargo), utilizaremos:
SELECT * FROM EMPLEADO E

WHERE NOT EXISTS (SELECT * FROM DEPEND DE WHERE DE.NSSE = E.NSS);
Nótese que utilizamos E.NSS de la SELECT externa en la cláusula WHERE de la SELECT interna.
Como hemos descrito antes, la subconsulta se evalúa para cada tupla de la consulta externa, es
decir, el valor de E.NSS se toma siempre de la tupla actual de la SELECT externa.
Definición de Datos
El lenguaje de Definición de datos, en inglés Data Definition Language (DDL), es el que se

encarga de la modificación de la estructura de los objetos de la base de datos. Existen cuatro
operaciones básicas: CREATE, ALTER, DROP y TRUNCATE.
Create Table
El comando fundamental para definir datos es el que crea una nueva relación (una nueva tabla). La
sintaxis del comando CREATE TABLE es:
CREATE TABLE table_name

(name_of_attr_1 type_of_attr_1 [, name_of_attr_2 type_of_attr_2 [, ...]]);
Ejemplo 7. Creación de una tabla

Para crear las tablas definidas en el ejemplo se utilizaron instrucciones de SQL, del mismo modo que
el sig. ej:
CREATE TABLE PROYECTO (NOMBREP VARCHAR(20), NUMEROP INTEGER,
LUGARP INTEGER, NUMD INTEGER);
Pág. 131 de 141

Tipos de Datos en SQL
A continuación sigue una lista de algunos tipos de datos soportados por SQL:
 INTEGER: entero binario con signo de palabra completa (31 bits de precisión).
 SMALLINT: entero binario con signo de media palabra (15 bits de precisión).
 DECIMAL (p [,q]): número decimal con signo de p dígitos de precisión, asumiendo q a la
derecha para el punto decimal. (15 ≥ p ≥ qq ≥ 0). Si q se omite, se asume que vale 0.
 FLOAT: numérico con signo de doble palabra y coma flotante.
 CHAR(n): cadena de caracteres de longitud fija, de longitud n.
 VARCHAR(n): cadena de caracteres de longitud variable, de longitud máxima n.
Restricciones de integridad
La sentencia CREATE TABLE permite especificar restricciones de integridad, en el momento de crear

las tablas:
 Clave Primaria: Se crean mediante una restricción PRIMARY KEY
CREATE TABLE tabla (campo tipo_datos CONSTRAINT nombre PRIMARY KEY)
La clave primaría siempre lleva asociado un índice que se crea automáticamente. Crea una clave
primaria en la columna “campo” y a su vez un índice de nombre “nombre”.
 Clave Candidata: pueden crearse con una restricción de tipo UNIQUE:
CREATE TABLE tabla (campo tipo_datos CONSTRAINT nombre UNIQUE)
También se crea un índice de nombre “nombre” para la clave candidata.
 Integridad Referencial: se define mediante restricciones de tipo clave externa ó ajena:
CREATE TABLE tabla1 (campo tipo_datos CONSTRAINT nombre FOREIGN KEY

REFERENCES tabla2)
Crea una relación entre la columna “campo” de la tabla1 con la clave primaria de la tabla
“tabla2”. Si la clave ajena hace referencia a una columna que no es clave primaria (pero si
candidata), habrá que indicar el nombre de esa columna:
CREATE TABLE tabla1 (campo tipo_datos CONSTRAINT nombre

FOREIGN KEY REFERENCES tabla2(columna))
Lo anterior es válido en el caso de que la restricción afecte únicamente a una columna de la

tabla. Para restricciones de múltiples columnas, la sintaxis será:
CREATE TABLE tabla (col1 tipo_datos, col2 tipo_datos, CONSTRAINT

Nombre PRIMARY KEY(col1, col2))
 Clave candidata:
Nombre UNIQUE(col1, col2))

Nombre FOREIGN KEY(col1, col2) REFERENCES tabla2)
Pág. 132 de 141

El significado de las distintas opciones es:
 UNIQUE: impide que se introduzcan valores repetidos para ese atributo. No se puede utilizar
junto con PRIMARY KEY.
 NOT NULL: evita que se introduzcan tuplas con valor NULL para ese atributo.
 PRIMARY KEY: establece ese atributo como la llave primaria de la tabla.
 CHECK (condición): permite establecer condiciones que deben cumplir los valores
introducidos en ese atributo. La condición puede ser cualquier expresión válida que sea
cierta o falsa. Puede contener funciones, atributos (de esa tabla) y literales. Si un CHECK se
especifica como una restricción de columna, la condición sólo se puede referir a esa
columna. Si el CHECK se especifica como restricción de tabla, la condición puede afectar a
todas las columnas de la tabla. Sólo se permiten condiciones simples, por ejemplo, no está
permitido referirse a columnas de otras tablas o formular subconsultas dentro de un CHECK.
En principio están permitidas comparaciones simples de atributos y operadores lógicos (AND,
OR y NOT). Además las funciones SYSDATE y USER no se pueden utilizar dentro de la
condición.
 PRIMARY KEY lista_columnas: sirve para establecer como llave primaria un conjunto de
atributos.
 FOREIGN KEY: define una llave externa de la tabla respecto de otra tabla. Esta restricción
especifica una columna o una lista de columnas como de clave externa de una tabla
referenciada.
La tabla referenciada se denomina tabla padre de la tabla que hace la referencia llamada
tabla hija. En otras palabras, no se puede definir una restricción de integridad referencial
que se refiere a una tabla antes de que dicha tabla haya sido creada. Es importante resaltar
que una clave externa debe referenciar a una clave primaria completa de la tabla padre, y
nunca a un subconjunto de los atributos que forman esta clave primaria.
 ON DELETE CASCADE: especifica que se mantenga automáticamente la integridad referencial

borrando los valores de la llave externa correspondientes a un valor borrado de la tabla
referenciada (tabla padre). Si se omite esta opción no se permitirá borrar valores de una
tabla que sean referenciados como llave externa en otras tablas.
. En la definición de una tabla pueden aparecer varias cláusulas

FOREIGN KEY, tantas como llaves externas tenga la tabla, sin
embargo sólo puede existir una llave primaria, si bien esta
llave primaria puede estar formada por varios atributos.
La utilización de la cláusula CONSTRAINT nombre_restricción establece un nombre

determinado para la restricción de integridad, lo cual permite buscar en el Diccionario de Datos
de la base de datos con posterioridad y fácilmente las restricciones introducidas para una
determinada tabla.
Las restricciones de integridad se pueden añadir o eliminar a una tabla existente con la
sentencia ALTER TABLE:
o Para eliminar una restricción existente:

ALTER TABLE tabla DROP CONSTRAINT nombre
Pág. 133 de 141

o Para añadir una restricción a una tabla que ya existe:
 PRIMARY KEY (campo)

 la ADD CONSTRAINT nombre UNIQUE (campo)
 FOREIGN KEY (campo)
REFERENCES tabla2 (campo)
Create Index
Se utilizan los índices para acelerar el acceso a una relación. Si una relación R tiene un índice en el
atributo A podremos recuperar todas la tuplas t que tienen t(A) = a en un tiempo aproximadamente
proporcional al número de tales tuplas t más que en un tiempo proporcional al tamaño de R.
Para crear un índice en SQL se utiliza el comando CREATE INDEX. La sintaxis es:
CREATE INDEX index_name ON table_name ( name_of_attribute );
Ejemplo 8. Create Index

Para crear un índice llamado APE sobre el atributo APELLIDO de la relación EMPLEADO, utilizaremos
la siguiente instrucción:
CREATE INDEX APE ON EMPLEADO (APELLIDO);
El índice creado se mantiene automáticamente, es decir, cada vez que una nueva tupla se inserte en
la relación EMPLEADO, se adaptará el índice APE. Nótese que el único cambio que un usuario puede
percibir cuando se crea un índice es un incremento en la velocidad.
Create View
Se puede ver una vista como una tabla virtual, es decir, una tabla que no existe físicamente en la
base de datos, pero aparece al usuario como si existiese. Por contra, cuando hablamos de una tabla
base, hay realmente un equivalente almacenado para cada fila en la tabla en algún sitio del
almacenamiento físico.
Las vistas no tienen datos almacenados propios, distinguibles y físicamente almacenados. En su
lugar, el sistema almacena la definición de la vista (es decir, las reglas para acceder a las tablas base
físicamente almacenadas para materializar la vista) en algún lugar de los catálogos del sistema.
En SQL se utiliza el comando CREATE VIEW para definir una vista. La sintaxis es:
CREATE VIEW view_name AS select_stmt
donde select_stmt es una instrucción select válida, como se definió en SELECT. Nótese que
select_stmt no se ejecuta cuando se crea la vista. Simplemente se almacena en los catálogos del
sistema y se ejecuta cada vez que se realiza una consulta contra la vista.
CREATE VIEW Sólo_Cónyuges AS SELECT E.APELLIDO, DE.NombreDependiente

FROM EMPLEADO E, DEPEND DE
WHERE E.NSS = DE.NSSE AND DE.PARENTESCO = 'Cónyuge';
Ahora podemos utilizar esta relación virtual Sólo_Cónyuges como si se tratase de otra tabla base:
SELECT * FROM Sólo_Cónyuges WHERE DE.Nombre_Dependiente = 'López';
Para calcular este resultado, el sistema de base de datos ha realizado previamente un acceso oculto
a las tablas de la base EMPLEADO Y DEPEND.
Pág. 134 de 141

Hace esto ejecutando la consulta dada en la definición de la vista contra aquellas tablas base. Tras
eso, las cualificaciones adicionales (dadas en la consulta contra la vista) se podrán aplicar para
obtener la tabla resultante.
Drop Table, Drop Index, Drop View
Se utiliza el comando DROP TABLE para eliminar una tabla (incluyendo las tuplas almacenadas):
DROP TABLE table_name;
 Para eliminar la tabla EMPLEADO, utilizaremos la instrucción:

DROP TABLE EMPLEADO;
 Se utiliza el comando DROP INDEX para eliminar un índice: DROP INDEX index_name;
 Finalmente, eliminaremos una vista dada utilizando el comando: DROP VIEW view_name;
Actualización de Datos
Insert Into
Una vez que se crea una tabla, puede ser llenada con tuplas mediante el comando INSERT INTO.
La sintaxis es:
INSERT INTO table_name (name_of_attr_1 [, name_of_attr_2 [,...]])
VALUES (val_attr_1 [, val_attr_2 [, ...]]);
Para insertar la primera tupla en la relación PROYECTO utilizamos la siguiente instrucción:
INSERT INTO PROYECTO (NOMBREP,NUMEROP,LUGARP,NUMD) VALUES (“Empr1”, 15, 2, 8);
Update
Para cambiar uno o más valores de atributos de tuplas en una relación, se utiliza el comando
UPDATE. La sintaxis es:
UPDATE table_name SET name_of_attr_1 = value_1 [, ... [,

name_of_attr_k = value_k]] WHERE co;
Para cambiar el valor del atributo SALARIO para el empleado 'Pérez' de la relación EMPLEADO,
utilizamos:
UPDATE EMPLEADO SET SALARIO = 384 WHERE APELLIDO = 'Pérez';
El nuevo valor del atributo SALARIO de la tupla cuyo apellido es 'Pérez' es ahora $384.
Delete
Para borrar una tupla de una tabla particular, utilizamos el comando DELETE FROM. La sintaxis es:
DELETE FROM table_name WHERE condition;
Ej: DELETE FROM EMPLEADO WHERE APELLIDO = 'Pérez';
Pág. 135 de 141

Anexo Explicativo; Lenguaje estructurado de consultas SQL
Consultas: Forma Básica
La forma básica de una instrucción SELECT consta de 3 (tres) cláusulas y se construye así:
SELECT <lista de atributos> Qué mostrar

From <lista de tablas> Dónde buscar los datos
Where <criterio de búsqueda> Condición que deben cumplir las tuplas
Ejemplo:
Select Fecha_Nac, Teléfono from Alumnos where Apellido=”PEREZ” and Nombre=”LUIS”
Esta consulta es equivalente a la expresión del algebra relacional que detallamos a continuación:
π Fecha_Nac, Teléfono ( σ Apellido=”PEREZ” and Nombre=”LUIS” (Empleado) )

Es decir que la aplicación de un criterio de búsqueda sobre las tuplas de una relación (en
este caso “Empleado”) se corresponde con la operación del AR denominada “Selección” y la
especificación de una lista de campos equivale a la operación denominada “Proyección“,
Entre las operaciones restantes, enumeramos “Unión”, “Intersección”, “Diferencia”,
“Producto” y “División”. Dejamos una última para el final: “Unión natural”
Las tres primeras se implementan directamente, y de un modo muy sencillo, siempre que
cumplan con una condición básica para su funcionamiento: que las relaciones intervinientes (tablas)
sean de tipo “unión compatibles”. Es decir, debemos asegurarnos que dos relaciones a las que
apliquemos la operación tengan los mismos atributos y que éstos aparezcan en el mismo orden en
ambas relaciones (en pocas palabras, tengan igual la estructura de campos).
Un ejemplo simple de Unión; mostrar todos los alumnos y docentes que vivan en la cuidad de Lules
Select Apellido, Teléfono from Alumnos where Localidad=”Lules” union

Select Apellido, Teléfono from Docentes where Localidad=”Lules”
Obtenemos todas las tuplas correspondientes a la tabla Alumnos (datos personales) y todas las de la
tabla Docentes (datos personales), contando desde ya con la necesaria condición de que los
“esquemas” (conjunto de atributos) de ambas son iguales, es decir son UNION COMPATIBLES.
Otro ejemplo, un tanto más complejo, para revisar en el ejemplo de esquemas de relaciones
obtenido al aplicar los siete pasos de transformación del modelo ER al Relacional: las tablas de
Empleados, Proyectos, Departamentos, Trabaja_en (sólo estas cuatro) e intentemos cumplir con el
siguiente requerimiento:
a) Preparar una lista con todos los números de proyectos en los que
participa un empleado de apellido “Silva”, sea como trabajador o
EL campo como gerente del departamento que controla el proyecto.
resultante es
el mismo Select NumeroP from Proyectos, Departamentos, Empleados
where NumD=NumeroD and NssGte=Nss and apellido=”Silva” UNION
(select NumeroP from Proyectos, Trabaja_en, Empleados Consulta

EJUNION
where NumP=NumeroP and NssE=Nss and apellido=”Silva”
Pág. 136 de 141

La Diferencia se implementa a partir de la cláusula Except, como podemos apreciar en éste ejemplo:
 Muestre todos nombres de todos los empleados de la empresa salvo los que tienen la categoría
más baja:
Select apellido||', '||nombre from Empleados Except

(Select apellido||', '||nombre from Empleados
where categoria = (Select min(categoria) from Empleados));
Nota: Este ejemplo es válido para mostrar el uso del Except, como también para ejemplificar el
método para visualizar campos “concatenados como apellido y nombre que se mostrarán unidos y
separados por una coma. También note cómo esta consulta es un claro ejemplo de Consultas
Anidadas.
Si en una consulta hacemos intervenir a dos tablas sin establecer ningún vínculo entre
campos comunes, (o bien porque no los hubiera), obtenemos el Producto, equivalente al Producto
Cartesiano en la Teoría de Conjuntos, donde las tuplas resultantes de dicha operación entre una
tabla A y una tabla B, tienen todos los atributos tanto de la primera como de la segunda tabla y los
datos correspondientes surgen de considerar por cada tupla de A n tuplas combinándola con B.
Ejemplo: Empleados
Departamento Número Lugar
Apellido Nombre NúmeroDpto Ventas 1 Entrepiso A
Compras 2 Segundo Piso
Alvarez Luis 5
Vercellone María 3 Planificación 3 Tercer Piso
Perez Angeles 2 Marketing 4 Entrepiso B
Lopez Juan 4 Producción 5 Primer Piso
Apellido Nombre NumeroDpto Departamento Número Lugar

Alvarez Luis 5 Ventas 1 Entrepiso A
Alvarez Luis 5 Compras 2 Segundo Piso
Alvarez Luis 5 Planificación 3 Tercer Piso
Alvarez Luis 5 Marketing 4 Entrepiso B
Alvarez Luis 5 Producción 5 Primer Piso
Vercellone María 3 Ventas 1 Entrepiso A
Vercellone María 3 Compras 2 Segundo Piso
Vercellone María 3 Planificación 3 Tercer Piso
Vercellone María 3 Marketing 4 Entrepiso B
Vercellone María 3 Producción 5 Primer Piso
Perez Angeles 2 Ventas 1 Entrepiso A
Perez Angeles 2 Compras 2 Segundo Piso
Perez Angeles 2 Planificación 3 Tercer Piso
Perez Angeles 2 Marketing 4 Entrepiso B
Perez Angeles 2 Producción 5 Primer Piso
Lopez Juan 4 Ventas 1 Entrepiso A
Lopez Juan 4 Compras 2 Segundo Piso
Lopez Juan 4 Planificación 3 Tercer Piso
Lopez Juan 4 Marketing 4 Entrepiso B
Lopez Juan 4 Producción 5 Primer Piso
Este es el resultado obtenido del comando -- Select * from Empleados, Departamentos
Pág. 137 de 141

Si en cambio, hacemos uso del campo común de ambas tablas (NúmeroDpto – Número), podríamos
adicionarle una cláusula Where como en este ejemplo
Select Apellido, Nombre, Lugar from Empleados, Departamentos where NúmeroDpto=Número
Y sabremos en qué piso trabaja cada empleado:
Apellido Nombre Lugar

Alvarez Luis Primer Piso
Vercellone María Tercer Piso
Perez Ángeles Segundo Piso
Lopez Juan Entrepiso B
Consultas Anidadas o Subconsultas
Supongamos ahora que necesitamos, a los fines estadísticos hacer un listado de todos los productos
cuyo precio supera el promedio de precios de todos los artículos. Por un lado, el cálculo de la media
es una función de agregación conocida como AVG().
Select NombreProd, Precio from Productos
 A continuación sabemos que el cálculo del promedio es sencillo, y obtenemos un único valor
a partir de:
Select AVG(Precio) as Promedio from Productos
 Ahora bien, retomemos el objetivo inicial, “todos los que superen la media”

where Precio>AVG(Nota)
No es posible convocar aquí a una función de agregación!
La forma correcta de obtener el resultado necesita la inclusión de la consulta que posee el

cálculo, dentro de la que compare cada tupla con el valor promedio.

where Precio> (select avg(precio) from Productos)
Este mismo razonamiento es posible de seguir en este ejemplo que adiciona complejidad al ejercicio:
Supongamos ahora que necesitamos, a los fines estadísticos hacer un listado de todos los alumnos
cuya nota final supera el promedio obtenido en la asignatura “Cálculo” en el presente ciclo lectivo.
Por un lado, el cálculo de la media es una función de agregación conocida como AVG().
 Sólo para analizar los dato, primero obtengamos un listado de los alumnos con sus notas
respectivas, sabiendo que los datos personales están en Alumnos y la calificación en Notas
Select Apellido, Nombre, Calific from Alumnos, Notas

where Alumnos.Lu=Notas.Lu and Notas.Asigntura=”Cálculo”
 A continuación sabemos que el cálculo del promedio es sencillo, y obtenemos un único valor
a partir de:
Pág. 138 de 141

Select AVG(Calific) as Promedio from Alumnos, Notas

where Alumnos.Lu=Notas.Lu and Notas.Asigntura=”Cálculo”
Ahora bien, retomemos el objetivo inicial, “todos los que superen la media”
Incorrecto!
where Alumnos.Lu=Notas.Lu and Notas.Asigntura=”Cálculo” and Notas.Nota=AVG(Nota)
La forma correcta de obtener el resultado necesita la inclusión de la consulta que posee el

cálculo, dentro de la que compare cada tupla con el valor promedio.

where Alumnos.Lu=Notas.Lu and Notas.Asigantura=”Cálculo”
and Notas.Calific> (select avg(calific) from Alumnos,Notas
where Alumnos.Lu=Notas.Lu and Notas.Asignatura=”Cálculo”)
Continuando con el tema de las subconsultas, analicemos ahora el uso de Operadores

especiales de estas consultas anidadas: IN – NOT IN como también EXISTS – NOT EXISTS.
Un caso simple para mostrar el uso del operador IN (operador de conjuntos) está
ejemplificado aquí: mostrar todas las conferencias que tendrán lugar un día Lunes o Martes o
Sábado.
Select Hora, Conferencia from Eventos where Día IN (Lunes, Martes, Sábado)
En realidad, este comando es una simplificación de una expresión lógica compuesta del siguiente
modo:
Select Hora, Conferencia from Eventos En realidad todas las
where Día=”Lunes” OR Día=”Martes” OR Día=”Sábado” posibilidades buscadas se
enumeran como un conjunto.
Comentario: Del mismo modo para simplificar la expresión de búsqueda en un intervalo,

reemplazamos la expresión Campo>=ValorMin and Campo<=ValorMáx por el operador BETWEEN
Pero volviendo al operador In, puede ser aplicado en la búsqueda de un valor contenido en
una subconsulta (como conjunto de valores), por ejemplo:
 Listar todos los empleados con la máxima categoría:
Select Apellido, Teléfono from Empleados

where Categoria IN (Select MAX(categoría) from Empleados)
Está claro que la subconsulta tiene que devolver como resultado una única columna que será
empleada por el Select más externo para comparar con el valor de cada tupla, considerando el
conjunto resultado de la subconsulta como un conjunto.
Pero observemos como “replantear” la consulta “EJUNION” de la página 9. Podemos

escribirla utilizando subconsultas y el operador de conjunto IN:
Select Distinct NumeroP from Proyectos

where NumeroP IN (Select NumeroP from Proyectos, Departamentos, Empleados
where NumD=NumeroD and NssGte=Nss and apellido=”Silva”)
OR
NumeroP IN (select NumP from Trabaja_En, Empleados
where NssE=Nss and apellido=”Silva”
Pág. 139 de 141

Completamos este punto con un ejemplo del contrario: Cláusula NOT IN.

where Alumnos.Lu=Notas.Lu and Notas.Asignatura=”Cálculo” and Notas.Calific NOT IN (4,6,10)
En cuanto a las Cláusulas EXISTS / NOT EXISTS, hay que prestar atención a ciertas
particularidades en el empleo de las mismas y en el armado de las consultas anidadas.
La forma general del uso de estas cláusulas es el siguiente:
Select col1 FROM tab1 where EXISTS (Select 1 FROM tab2 where col2 = tab1.col2);
Si prestamos atención, podemos notar que en la cláusula where se comparan dos campos
evidentemente comunes, uno de la primera tabla, y el otro, de la segunda. Es decir que no hace falta
especificar toda la vinculación en la consulta externa y antes del where, puesto que asume ambas
simultáneamente. Veamos si con el ejemplo podemos notarlo claramente:
 Listar todos los alumnos que no rindieron “Cálculo”
Select Apellido, Nombre from Alumnos

where NOT EXISTS (Select * from Notas
where Alumnos.Lu=Notas.Lu and Notas.Asignatura=”Cálculo”)
 Otro ejemplo: Mostrar los nombres de los Gerentes que tienen al menos un dependiente.
Select Apellido, Nombre from Empleados

where EXISTS (Select * from Dependiente where Nss=NssE)
and EXISTS (Select * from Departamento where Nss=NssGte)
(Recuerde de analizar bien los esquemas – estructuras de las tablas- de este ejemplo
explicado en la clase teórica, para comprender cabalmente el efecto producido)
Creación de Vistas
En la terminología SQL, una vista es una tabla derivada de otras tablas. Las “vistas” no
necesariamente existen en forma “física”: se las considera Tablas Virtuales, en contraste con las
tablas Base, cuyas tuplas se almacenan realmente en la base de datos; y si bien, esto limita las
operaciones de actualización que es posible aplicar a las vistas, no implica limitaciones para consultar
éstas últimas.
Podemos considerar una vista, entonces, como una forma de especificar una tabla a la que
tendremos que referirnos con frecuencia, aunque no posea existencia física.
El ejemplo responde a una consulta sobre la base de datos de la Bombonería, objeto del
trabajo práctico recientemente realizado.
Create View Importexpedido as

(Select pedidos.id_pedido, clientes.apellido, cajas.nombre,
sum(pedidos.cantidad*cajas.precio) as importe from Pedidos
Inner Join Cajas ON pedidos.id_caja = cajas.id_caja
Inner Join Clientes on pedidos.id_cliente=clientes.id_cliente
Group By pedidos.id_pedido, cajas.nombre, clientes.apellido;
Pág. 140 de 141

Esta vista denominada ImportexPedido nos permite obtener una lista de todos los pedidos
realizados, visualizando el Número de pedido, el Cliente que lo solicitó, la Caja pedida y el Importe a
Pagar, resultante del producto de la cantidad de cajas solicitada por el precio de la misma.
Si precisáramos obtener un listado de todos los pedidos cuyo importe supere la media:
Select Id_pedido, Importe from Importexpedido Utiliza la vista, previamente

where importe > (Select Avg (Importe) from Importexpedido); definida. (NO ES POSIBLE
resolverlo DE OTRO MODO)
Create View Maspedidas as (Select Cajas.Id_caja, Count(Pedidos.Id_caja) As cuenta

from Cajas, pedidos where Cajas.Id_caja=Pedidos.Id_caja
group by Cajas.Id_caja order by Cuenta desc limit 5;
Update Cajas Set Precio=Precio*1.10 where Id_caja = Maspedidas.Id_caja;
System Catalogs
En todo sistema de base de datos SQL se emplean catálogos de sistema para mantener el control de
qué tablas, vistas, índices, etc. están definidas en la base de datos. Estos catálogos del sistema se
pueden investigar como si de cualquier otra relación normal se tratase. Por ejemplo, hay un catálogo
utilizado para la definición de vistas.
Este catálogo almacena la consulta de la definición de la vista. Siempre que se hace una consulta
contra la vista, el sistema toma primero la consulta de definición de la vista del catálogo y materializa
la vista antes de proceder con la consulta del usuario.
SQL Embebido
En esta sección revisaremos como se puede embeber SQL en un lenguaje de host (p.e. C). Hay dos
razones principales por las que podríamos querer utilizar SQL desde un lenguaje de host:
 Hay consultas que no se pueden formular utilizando SQL puro (por ejemplo, las consultas
recursivas). Para ser capaz de realizar esas consultas necesitamos un lenguaje de host de
mayor poder expresivo que SQL.
 Simplemente queremos acceder a una base de datos desde una aplicación que está escrita
en el lenguaje del host (p.e. un sistema de reserva de billetes con una interface gráfica
escrita en C, y la información sobre los billetes está almacenada en una base de datos que
puede accederse utilizando SQL embebido).
Un programa que utiliza SQL embebido en un lenguaje de host consiste en instrucciones del lenguaje
del host e instrucciones de SQL embebido (ESQL). Cada instrucción de ESQL empieza con las
palabras claves EXEC SQL. Las instrucciones ESQL se transforman en instrucciones del lenguaje del
host mediante un precompilador (que habitualmente inserta llamadas a rutinas de librerías que
ejecutan los variados comandos de SQL).
Cuando vemos los ejemplos de Select observamos que el resultado de las consultas es algo muy
próximo a un conjunto de tuplas. La mayoría de los lenguajes de host no están diseñados para
operar con conjuntos, de modo que necesitamos un mecanismo para acceder a cada tupla única del
conjunto de tuplas devueltas por una instrucción SELECT. Este mecanismo puede ser proporcionado
declarando un cursor. Tras ello, podemos utilizar el comando FETCH para recuperar una tupla y
apuntar el cursor hacia la siguiente tupla.
Pág. 141 de 141

Torres Auad, Lía Fabiana
Conceptos de bases de datos : una

aproximación a los fundamentos . - 1a ed. –
San Miguel de Tucumán –

Universidad Nacional de Tucumán. Facultad de Ciencias
Exactas y Tecnología de la Universidad Nacional de Tucumán. ,
2006.
E-Book.
ISBN 978-950-554-921-4
1. Informática. 2. Base de Datos. I. Título CDD 005.754
Fecha de catalogación: 27/02/2015

CBD1 Ebook

Cargado por

Copyright:

Formatos disponibles

CBD1 Ebook

Cargado por

Información del documento

Descripción original:

Título original

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

CBD1 Ebook

Cargado por

Copyright:

Formatos disponibles

Lía F.

Una aproximación a los

Introducción a las Bases de Datos

n estas hojas he intentado compendiar las conceptualizaciones básicas referidas a las

 Sistemas de bases de datos. Conceptos fundamentales. Ramez Elmasri/S.Navathe –

 Fundamentos y Modelos de Bases de Datos. A. De Miguel, M. Piattini – RA-MA

 Bases de datos, modelos, lenguajes y diseño. James L. Johnson – OXFORD

Bases de Datos. Concepto

na primera aproximación al concepto, según Elmasri/Navathe, requiere

 Una BD es un conjunto de datos lógicamente coherente, con cierto significado inherente. No

A continuación, analicemos la concepción de base de datos de otro autor:

Finalmente, se incluye la de De Miguel y Piattini, que además de más reciente, es la más

Características del enfoque de Bases de Datos

Naturaleza autodescriptiva de los sistemas de bases de datos

“Los datos no deben depender de un programa para hacerlo

Esta descripción mencionada en las bases de datos (MetaDatos) se almacena en el Catálogo

Abstracción de los datos

“No es aconsejable que cada programador posea los archivos de datos

En el procesamiento de archivos tradicional, la estructura de los archivos de datos viene

Datos compartidos y procesamiento de transacciones multiusuario

“Sin bases de datos es más difícil compartir los datos; las

En este enfoque es totalmente viable el acceso simultáneo de varios usuarios a la base de

Manejo de Múltiples vistas de los datos

Las características hasta aquí mencionadas suponen implícitamente una comparación de

Las deficiencias de procesamiento de información antes de las bases de datos

 datos codificados (por cada programa/programador)

Modelos de Bases de Datos

U cierto nivel de abstracción de los datos al ocultar detalles de almacenamiento que la

Pero… ¿qué es un modelo?

Desde el punto de vista de los datos…

Un modelo de datos es un conjunto de conceptos que pueden

o de alto nivel o Conceptuales,

o Modelos de datos Conceptuales: disponen de conceptos muy cercanos al modo como la

 Modelo Relacional de Bases de Datos

 Modelo Jerárquico de Bases de Datos

 Modelo de Bases de Datos en Red

Modelos Lógicos basados en Objetos

 Modelo de Bases de Datos Orientados a Objetos

Entonces, el Esquema de la base de datos (Metadatos) es la descripción de la misma.

El diagrama del esquema es la representación del mismo. Muestra un

El Estado de la base de datos es el conjunto de datos, llamados ocurrencias

Es posible crear muchos estados de la base de datos que correspondan a un esquema en

Cuando se define una nueva base de datos, el estado correspondiente es

Sistemas de Gestión de Bases de Datos  DBMS

Software para tener acceso

Definición de la base Base de Datos

a. Coordina el trabajo de los diseñadores respecto a la Definición del Esquema, de la

b. Supervisa la modificación del esquema y la organización física.

c. Autoriza el acceso a la base de datos, de coordinar y vigilar su empleo.

d. Adquiere recursos necesarios de software y hardware.

e. Respecto a la Concesión de la autorización para el acceso a los datos, es responsable de

f. Especifica las restricciones de Integridad.

 Diseñadores: se encargan de identificar los datos que se almacenarán y de elegir las

a. Simples o paramétricos: constituyen la mayor porción de los usuarios finales y su

b. Los esporádicos: tienen acceso de vez en cuando y posiblemente requieran informa-ción

 Creadores de Herramientas: se ocupan de diseñar e implementar paquetes especiales

 Operadores y personal de mantenimiento: tiene a su cargo el funcionamiento y

Ahora analizaremos cuidadosamente cuáles son las características esperables en un