Teoria de Bases de Datos

Indice
I
Bases de Datos
Tema 1.Introduccin.
1.1. Objetivos de los sistemas de bases de datos.
1.2. Abstraccin de datos.
1.3. Modelos de datos.
1.3.1. Modelos lgicos basados en objetos.
1.3.1.1. El modelo entidad-relaccin.
1.3.1.2. El modelo orientado a objetos.
1.3.2. Modelos lgicos basados en registros.
1.3.2.1. Modelo relaccional.
1.3.2.2. Modelo de red.
1.3.2.3. Modelo jerrquico.
1.3.2.4. Diferencias entre modelos.
1.3.3. Modelos fsicos de datos.
1.4. Instancias y esquemas.
1.5. Independencia de datos.
1.6. Lenguaje de definicin de datos.
1.7. Lenguaje de manipulacin de datos.
1.8. Gestor de base de datos.
1.9. Administrador de bases de datos.
1.10. Usuarios de bases de datos.
1.11. Estructura del sistema global.
Tema 2.Modelo entidad-relacin.
2.1. Entidades y conjuntos de entidades.
2.2. Relaciones y conjuntos de relaciones.
2.3. Atributos.
2.4. Restricciones de asignacin (mapping).
2.5. Claves.
2.6. Diagrama entidad-relacin.
2.7. Reduccin de los diagramas E-R a tablas.
2.7.1. Representacin de conjuntos de entidades fuertes.
2.7.2. Representacin de conjuntos de entidades dbiles.
2.7.3. Representacin de conjuntos de relaciones.
2.8. Generalizacin.
2.9. Agregacin.
2.10. Diseo de un esquema de base de datos E-R.
2.10.1. Cardinalidades de asignacin.
2.10.2. Uso de conjuntos de entidades o de conjuntos de relaciones.
2.10.3. Uso de caractersticas de E-R ampliado.
Tema 3.Modelo relacional.
3.1. Estructura de las bases de datos relacionales.
3.1.1. Estructuras bsicas.
3.1.2. Esquema de la base de datos.
3.1.3. Claves.
3.1.4. Lenguajes de consulta.
3.2. El lgebra relacional.
3.2.1. Operaciones fundamentales.
Indice
II
3.2.1.1. La operacin seleccionar.
3.2.1.2. La operacin proyectar.
3.2.1.3. La operacin producto cartesiano.
3.2.1.4. La operacin renombrar.
3.2.1.5. La operacin unin.
3.2.1.6. La operacin diferencia de conjuntos.
3.2.2. Definicin formal del lgebra relacional.
3.2.3. Operaciones adicionales.
3.2.3.1. La operacin interseccin de conjuntos.
3.2.3.2. La operacin producto natural.
3.2.3.3. La operacin divisin.
3.2.3.4. La operacin asignacin.
3.3. El clculo relacional de tuplas.
3.3.1. Consultas ejemplo.
3.3.2. Definicin formal.
3.3.3. Seguridad de expresiones.
3.3.4. Poder expresivo de los lenguajes.
3.4. El clculo relacional de dominios.
3.4.3. Seguridad de las expresiones.
3.5. Modificacin de la base de datos.
3.5.1. Eliminacin.
3.5.2. Insercin.
3.5.3. Actualizacin.
3.6. Vistas.
3.6.1. Definicin de vista.
3.6.2. Actualizacin por medio de vistas y valores nulos.
Tema 4.Lenguajes relacionales comerciales.
4.1. SQL.
4.1.1. Estructura bsica.
4.1.2. Operaciones de conjuntos y tuplas duplicadas.
4.1.3. Operaciones de conjuntos.
4.1.4. Predicados y conectores.
4.1.5. Pertenencia a un conjunto.
4.1.6. Variables de tupla.
4.1.7. Comparacin de conjuntos.
4.1.8. Pruebas para relaciones vacas.
4.1.9. Ordenacin de la presentacin de tuplas.
4.1.10. Funciones de agregacin.
4.1.11. La potencialidad de SQL.
4.1.12. Modificacin de la Base de Datos.
4.1.13. Valores nulos.
4.1.14. Vistas.
4.1.15. Definicin de datos.
4.2. Query By Example (QBE).
4.2.2. Consultas sencillas.
4.2.3. Consulta sobre varias relaciones.
4.2.4. El cuadro de condiciones.
4.2.5. La relacin resultado.
4.2.6. Ordenacin de la presentacin de las tuplas.
4.2.7. Operaciones de agregacin.
4.3. QUEL.
Indice
III
Tema 5.Restricciones de integridad.
5.1. Restricciones de dominio.
5.1.1. Tipos de dominios.
5.1.2. Tipos de dominios en SQL.
5.2. Integridad referencial.
5.2.1. Conceptos bsicos.
5.2.2. Integridad referencial en el modelo E-R.
5.2.3. Modificacin de la base de datos.
5.2.4. Integridad referencial en SQL.
5.3. Dependencias funcionales.
5.3.2. Cierre de un conjunto de dependencias funcionales.
5.3.3. Cierre de conjuntos de atributos.
5.3.4. Recubrimiento cannico.
5.4. Afirmaciones.
5.5. Disparadores.
Tema 6.Diseo de Bases de Datos relacionales.
6.1. Peligros en el diseo de Bases de Datos relacionales.
6.1.1. Representacin de la informacin.
6.1.2. Perdida de informacin.
6.2. Normalizacin por medio de dependencias funcionales.
6.2.1. Propiedades deseables de una descomposicin.
6.2.1.1. Descomposicin de producto sin prdida.
6.2.1.2. Conservacin de las dependencias.
6.2.1.3. Repeticin de informacin.
6.2.2. Forma normal Boyce-Codd.
6.2.3. Tercera forma normal.
6.2.4. Comparacin de BCNF y 3NF.
6.3. Normalizacin por medio de dependencias multivaluadas.
6.3.1. Dependencias multivaluadas.
6.3.2. Teora de dependencias multivaluadas.
6.3.3. Cuarta forma normal.
6.4. Normalizacin por medio de dependencias de interseccin.
6.4.1. Dependencias de interseccin.
6.4.2. Forma normal de proyecto-producto.
6.5. Forma normal de dominio-clave.
6.6. Enfoques alternativos de diseo de Bases de Datos.
Tema 7.Estructura de archivos y sistemas.
7.1. Estructura general del sistema.
7.2. Medios de almacenamiento fsico.
7.3. Organizacin de archivos.
7.3.1. Registros de longitud fija.
7.3.2. Registros de longitud variable.
7.4. Organizacin de registros en bloques.
7.5. Archivos secuenciales.
7.6. Asignacin (mapping) de datos relacionales a archivos.
7.7. Almacenamiento de diccionario de datos.
7.8. Gestin de registros intermedios (buffer).
Tema 8.Indexacin y asociatividad (hashing).
Indice
IV
8.1. Conceptos bsicos.
8.2. Indexacin.
8.2.1. ndice primario.
8.2.2. Indices secundarios.
8.3. Archivos indexados de rboles B
+
.
8.4. Archivos indexados de rboles B.
8.5. Funciones de asociacin (hash) esttica.
8.6. Funciones de asociacin (hash) dinmica.
8.7. Comparacin de indexacin y asociacin (hash).
8.8. Definicin de ndice en SQL.
8.9. Acceso por claves mltiples.
8.9.1. Estructura de rejilla.
8.9.2. Funcin de asociacin dividida.
Tema 1. Introduccin
1
Tema 1.Introduccin.
Un sistema de gestin de bases de datos (DBMS database management system) consiste en una coleccin de
datos interrelacionados y un conjunto de programas para acceder a ellos. La coleccin de datos se denomina base de
datos (BD). El objetivo primordial de un DBMS es proporcionar que a su vez sea conveniente y eficiente para ser
utilizado al extraer o almacenar informacin en la BD.
Los sistemas de bases de datos estn diseados para gestionar grandes bloques de informacin, que implica
tanto la definicin de estructuras para el almacenamiento como de mecanismos para la gestin de la informacin.
Adems los DBMS deben mantener la seguridad de la informacin almacenada pese a la cada del sistema o accesos no
autorizados.
1.1. Objetivos de los sistemas de bases de datos.
Considrese parte de una empresa bancaria que guarda la informacin sobre todos los clientes y cuentas en
archivos de sistemas permanentes. Adems, el sistema tiene diversos programas de aplicacin que permiten al usuario
manejar los archivos, como hacer abonos, aadir cuentas, gestionar el saldo, etc. Segn surge la necesidad se aaden
nuevos programas de aplicacin al sistema.
El tpico sistema de procesamiento de archivos descrito est apoyado por un sistema operativo convencional.
Los registros permanentes se almacenan en varios archivos, y se escribe un nmero de diferentes programas de aplicacin
para manipular los archivos apropiados. Este sistema tiene un nmero de desventajas importante, como :
1.- Redundancia e inconsistencia de los datos. Puesto que los archivos y los programas de aplicacin son
creados por distintos programas durante un periodo largo de tiempo, es probable que tengan distintos formatos, y
pueden estar duplicados en varios sitios. Por ejemplo, la direccin de un cliente puede aparecer en ms de un archivo.
Esta redundancia aumenta los costes de almacenamiento y acceso, y puede llevar a la inconsistencia de los datos, esto es,
las diversas copias de los mismos datos no concuerdan entre si.
2.- Dificultad para tener acceso a los datos. Supngase que se necesita averiguar los nombres de los clientes que
viven en una ciudad. Puesto que esta solicitud no fue prevista, no hay ningn programa que la satisfaga. Tenemos dos
opciones, coger la lista de todos los clientes y extraer la informacin manualmente, o escribir el programa de aplicacin
necesario. Obviamente ninguna de las dos opciones es satisfactoria. Lo que se trata de probar es que los entornos
convencionales de procesamiento de archivos no permiten recuperar los datos necesarios de un forma conveniente y
eficiente. Deben sistemas de recuperacin de datos para uso general.
3.- Aislamiento de los datos. Puesto que los datos estn repartidos en varios archivos, y estos pueden tener
diferentes formatos, es difcil escribir nuevos programas para obtener los datos apropiados.
4.- Anomalas del acceso concurrente. Para mejorar el funcionamiento del sistema y obtener un tiempo de
respuesta ms rpido, muchos sistemas permiten que los usuarios actualicen los datos simultneamente. En un
entorno as, las actualizaciones concurrentes pueden dar por resultados datos inconsistentes. Si una cuenta tiene 500$, y
dos clientes retiran 50$ y 100$ casi al mismo tiempo, el resultado de las ejecuciones concurrentes puede dejar la cuneta en
un resultado incorrecto o inconsistente, la cuenta puede contener 450$ o 400$, en vez de 350$. Para prevenir esta
posibilidad, debe mantenerse alguna forma de supervisin en el sistema. Puesto que se puede acceder a los datos por
medio de diversos programas de aplicacin, esta supervisin es muy difcil de proporcionar.
5.- Problemas de seguridad. No todos los usuarios del sistema de BD deben poder acceder a todos los datos.
Por ejemplo, el personal de nminas no necesita acceder a la informacin sobre la direccin de los clientes. Puesto que los
programas de aplicacin se aaden al sistema de una forma precisa, es difcil implantar tales restricciones de seguridad.
6.- Problemas de integridad. Los valores de datos almacenados en la BD deben satisfacer ciertos tipos de
restricciones de consistencia. Por ejemplo, el saldo de una cuenta no debe caer por debajo de una cantidad prefijada.
Estas restricciones se hacen cumplir aadiendo cdigos apropiados en los programas. Sin embargo, cuando se aaden
restricciones nuevas, es difcil cambiar los programas para hacerlas cumplir. El problema se complica ms cuando las
restricciones implican varios elementos de informacin de distintos archivos.
Estas dificultades, entre otras, han fomentado el desarrollo de DBMS.
1.2. Abstraccin de datos.
Un DBMS es una coleccin de archivos interrelacionados y un conjunto de programas que permiten a los
usuarios acceder y modificar esos archivos. Uno de sus objetivos ms importantes es proporcionar a los usuarios una
visin abstracta de los datos, es decir, el sistema esconde ciertos detalles de como se almacenan y mantienen los datos,
pero sin embargo se deben extraer eficientemente. Este requerimiento ha llevado al diseo de estructuras de datos
complejas para la representacin de datos en la BD. Se esconde esta complejidad a travs de distintos niveles de
abstraccin para simplificar la interaccin con el sistema.
1.- Nivel fsico. El nivel ms bajo de abstraccin describe como se almacenan realmente los datos, se describen
en detalle las estructuras de datos complejas del nivel bajo.
2.- Nivel conceptual. Describe qu datos son realmente almacenados en la BD y las relaciones que existen
entre ellos. Aqu se describe la BD completa en trminos de un nmero pequeo de estructuras sencillas. El nivel
conceptual de abstraccin lo usan los administradores de BD, quienes deben decidir que informacin se va a guardar en
la BD.
Bases de datos
2
3.- Nivel de visin. El nivel ms alto de abstraccin describe slo parte de la BD completa. Muchos usuarios
no se interesan por toda la informacin, slo necesitan una parte de la BD. Para simplificar su interaccin con el sistema
se define el nivel de abstraccin de visin. El sistema pude proporcionar muchas visiones para la misma BD.
En el nivel fsico, un registro puede describirse como un bloque de posiciones de memoria consecutivas. En el
nivel conceptual, cada registro se describe por medio de una definicin de tipo, y se define la interrelacin entre los tipos.
Finalmente, en el nivel de visin, se definen varias visiones de la BD. Por ejemplo, los cajeros slo ven la informacin
sobre las cuentas de los clientes, sin poder acceder a los salarios de los empleados.
1.3. Modelos de datos.
Para describir la estructura de una BD es necesario definir el concepto de modelo de datos, una coleccin de
herramientas conceptuales para describir datos, relaciones entre ellos, semntica asociada a los datos y restricciones de
consistencia. Los diversos modelos de datos se dividen en tres grupos : modelos lgicos basados en objetos, modelos
lgicos basados en registros y modelos fsicos de datos.
1.3.1. Modelos lgicos basados en objetos
Los modelos lgicos basados en objetos se usan para describir datos en el nivel conceptual y de visin. Se
caracterizan porque proporcionan capacidad de estructuracin bastabte flexible y permiten especificar restricciones de
datos explcitamente. Hay muchos modelos diferentes, y aparecern ms. Algunos de los ms conocidos son el modelo
entidad-relacin, el orientado a objetos, el binario, el semtico de datos, el infolgico y el modelo muncional de datos.
El modelo entidad-relacin ha ganado aceptacin y se utiliza ampliamente en la prctica, el modelo orientado a
objetos incluye muchos conceptos del anterior, y esta ganado aceptacin rpidamente.
1.3.1.1. El modelo entidad-relaccin.
El modelo de datos entidad-relacin (E-R) se basa en una percepcin de un mundo real que consiste en una
coleccin de objetos bsicos llamados entidades, y relaciones entre estos objetos. Una entidad es un objeto distinguible
de otros por medio de un conjunto de atributos. Por ejemplo, los atributos nmero y saldo describen una cuenta
particular. Una relacin es una asociacin entre varias entidades. Por ejemplo, una relacin Clicta asocia a un cliente con
cada cuenta que posee. El conjunto de todas las entidades del mismo tipo y relacciones del mismo tipo se denomina
conjunto de entidades y conjunto de relaciones.
Adems el modelo E-R representa ciertas restricciones a las que deben ajustarse los contenidos de una BD. Una
restriccin importante es la cardinalidad de asignacin, que expresa el nmero de entidades a las que puede asociarse otra
entidad mediante un conjunto de relacin.
La estructura lgica global de una BD puede expresarse grficamente por un diagrama E-R que consta de:
1.- Rectngulos, que representan conjuntos de entidades.
2.- Elipses, que representan atributos.
3.- Rombos, que representan relaciones entre conjunto de entidades.
4.- Lneas, que conectan atributos a conjuntos de entidades y conjuntos de entidades a relaciones.
Cada componente se etiqueta con el nombre de lo que representa.
1.3.1.2. El modelo orientado a objetos.
Al igual que el modelo E-R, el modelo orientado a objetos se basa en una coleccin de objetos. Un objeto
contiene valores acumulados en variables instancia dentro de l, y estos valores son objetos por si mismos. As, los
objetos contienen objetos a un nivel de anidamiento arbitrario. Un objeto tambin contiene partes de cdigo que
operan sobre el objeto, que se denominan mtodos.
Los objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupan en clases. Una clase
puede se vista como una definicin de tipo para objetos.
La nica forma en la que un objeto puede acceder a los datos de otro objeto es invocando a un mtodo de ese
otro objeto. Esto se llama envo de un mensaje al objeto. As, la interfaz de llamada de los mtodos de un objeto define
su parte visible externamente, la parte interna del objeto (las variables de instancia y el cdigo de mtodo) no son visibles
externamente. El resultado es dos niveles de abstraccin de datos.
Tema 1. Introduccin
3
Para ilustrar el concepto, considrese un objeto que representa una cuenta. Dicho objeto contiene las variables
instancia nmero y saldo, y el mtodo inters de pago, que aade inters al saldo. Supngase que se paga el 6% en todas
las cuentas, pero ahora se va a pagar el 5% si el saldo es menor que 1000$, y el 6% si es mayor o igual.. Bajo la mayora de
los modelos de datos, esto implicara cambiar de cdigo en uno o ms programas de aplicacin. Bajo este modelo, slo
se hace un cambio dentro del mtodo inters de pago. El interfaz externo del objeto permanece sin cambios.
A diferencia de las entidades en el modelo E-R, cada objeto tiene su propia identidad nica independiente de
los valores que contiene. As dos objetos que contienen los mismos valores son distintos. La distincin entre objetos
individuales se mantiene en el nivel fsico por medio de identificadores de objeto.
1.3.2. Modelos lgicos basados en registros.
Los modelos lgicos basados en registros se utilizan para describir datos en los modelos conceptual y fsico. A
diferencia de los modelos lgicos basados en objetos, se usan para especificar la estructura lgica global de la BD y para
proporcionar una descripcin a nivel ms alto de la implementacin.
Los modelos basados en registros se llaman as porque la BD est estructurada en registros de formato fijo de
varios tipos. Cada tipo de registro define un nmero fijo de campos, o atributos, y cada campo normalmente es de
longitud fija. La estructura ms rica de estas BD a menudo lleva a registros de longitud variable en le nivel fsico.
Los modelos basados en registros no incluyen un mecanismo para la representacin directa de cdigo de la BD,
en cambio, hay lenguajes separados que se asocian con el modelo para expresar consultas y actualizaciones
Los tres modelos de datos ms aceptados son los modelos relacional, de red y jerrquico. El modelo relacional
ha ganado aceptacin por encima de los otros.
1.3.2.1. Modelo relacional.
El modelo relacional representa los datos y relaciones entre los datos mediante una coleccin de tablas, cuyas
columnas tienen nombres nicos.
Nombre Calle Ciudad Nmero Nmero Saldo
Lowery Mapple Queens 900 900 55
Shiver North Bronx 556 556 100.000
Shiver North Bronx 647 647 105.366
Hodges Sidehill Brooklyn 801 801 10.533
Hodges Sidehill Brooklyn 647
1.3.2.2. Modelo de red.
Los datos en el modelo de red se representan mediante colecciones de registros y las relacciones entre los datos
se representan mediante enlaces, los cuales pueden verse como punteros.
1.3.2.3. Modelo jerrquico.
El modelo jerrquico es similar al modelo de red, los datos y las relaciones se representan mediante registros y
enlaces. Se diferencia del modelo de red en que los registros estn organizados como colecciones de rboles.
Bases de datos
4
1.3.2.4. Diferencias entre modelos.
Los modelos relacionales se diferencian de los modelos de red y jerrquico en que no usan punteros o enlaces.
En cambio, el modelo relacional conecta registros mediante los valores que stos contienen. Esta libertad del uso de
punteros permite que se defina una base matemtica formal.
1.3.3. Modelos fsicos de datos.
Los modelos fsicos de datos se usan para describir datos en el nivel ms bajo. Hay muy pocos de modelos
fsicos de datos en uso, siendo los ms conocidos el modelo unificador y de memoria de elementos.
1.4. Instancias y esquemas.
Las BD cambian a lo largo del tiempo segn se aade y se suprime informacin. La coleccin de informacin
almacenada en un determinado momento en el tiempo, se llama instancia de la BD. El diseo global de la BD se llama
esquema de la BD, y se cambian muy raras veces.
El concepto de esquema corresponde a la nocin de definicin de tipo en un lenguaje de programacin, y el
concepto del valor de una variable corresponde al concepto de una instancia de un esquema de la BD.
Los sistemas de BD tienen varios esquemas, divididos de acuerdo a los niveles de abstraccin tratados, el
esquema fsico, el esquema conceptual y los subesquemas. En general, los sistemas de BD soportan un esquema fsico,
otro conceptual y varios subesquemas.
1.5. Independencia de datos.
La capacidad de modificar una definicin de un esquema de un nivel sin afectar la definicin de un esquema en
el nivel superior siguiente se llama independencia de datos. Hay dos niveles de independencia de datos:
1.- Independencia fsica de datos. Es la capacidad de modificar el esquema fsico sin provocar que se vuelvan a
escribir los programas de aplicacin.
2.-Independencia lgica de datos. Es la capacidad de modificar el esquema conceptual sin provocar que se
vuelvan a escribir los programas de aplicacin.
La independencia lgica de datos es ms difcil de lograr, ya que los programas de aplicacin son fuertemente
dependientes de la estructura lgica de los datos a los que acceden.
El concepto de independencia de datos es similar al concepto de tipos abstractos de datos, ambos ocultan
detalles de implementacin.
1.6. Lenguaje de definicin de datos.
Un esquema de BD se especifica por medio de un conjunto de definiciones que se expresan mediante un
lenguaje especial llamado lenguaje de definicin de datos (data definition language, DDL). El resultado de la
compilacin de sentencias de DDL es un conjunto de tablas que se almacenan en un archivo especial que llamado
diccionario de datos o directorio.
Un directorio de datos es un archivo que contiene metadatos, es decir, datos sobre datos. Este archivo se
consulta antes de leer o modificar los datos reales en el sistema de BD.
La estructura de almacenamiento y los mtodos de acceso se especifican por medio de un conjunto de
definiciones en un tipo especial de DDL llamado lenguaje de almacenamiento y definicin de datos. El resultado de la
compilacin de estas definiciones es un conjunto de instrucciones que especifican los detalles de implementacin de los
esquemas que normalmente se esconden a los usuarios.
1.7. Lenguaje de manipulacin de datos.
Por manipulacin de datos entendemos la recuperacin y modificacin de la informacin almacenada y la
insercin y supresin de informacin.
A nivel fsico, debemos definir algoritmos que permitan acceso eficiente a los datos. En los niveles de
abstraccin ms altos, se pone nfasis en la facilidad de uso. El objetivo es proporcionar una interaccin eficiente entre las
personas y el sistema.
Un lenguaje de manipulacin de datos (data manipulation lenguage, DML) es un lenguaje que capacita a los
usuarios a acceder o manipular los datos. Existen bsicamente dos tipos :
1.- Procedimentales : requieren que el usuario especifique qu datos se necesitan y cmo conseguirlos.
2.- No procedimentales :el usuario debe especificar qu datos se necesitan, pero no cmo obtenerlos.
Los DML no procedimentales normalmente son ms sencillos de aprender y usar, sin embargo pueden generar
cdigo que no sea tan eficiente como el producido por los lenguajes procedimentales. Esta dificultad puede remediarse a
travs de varias tcnicas de optimizacin.
Una consulta es una sentencia que solicita la recuperacin de informacin. El trozo de un DML que implica
recuperacin de informacin se llama lenguaje de consultas. Aunque es incorrecto, suelen utilizarse los trminos lenguaje
de consultas y lenguaje de manipulacin de datos como sinnimos.
Tema 1. Introduccin
5
1.8. Gestor de base de datos.
Generalmente, las BD requieren una gran cantidad de espacio de almacenamiento, se miden en gigabytes.
Puesto que la memoria principal no puede almacenar toda esa informacin, se almacena en discos. Ya que el
movimiento de los datos y el disco son lentos comparado con la UCP, es imperativo que el sistema de la BD estructure
los datos de forma que minimice la necesidad de mover los datos entre el disco y la memoria.
El objetivo de un sistema de BD es simplificar y facilitar el acceso a los datos. Las vistas de alto nivel ayudan a
lograrlo. Un factor para la satisfaccin o insatisfaccin del usuario con un sistema de BD es su funcionamiento. El
funcionamiento de un sistema depende de la eficiencia de las estructuras de datos usadas para representar los datos y de
la capacidad de eficiencia de operar sobre estas estructuras de datos que el sistema tiene. Se debe llegar a un compromiso
entre espacio, tiempo y eficiencia.
Un gestor de BD es un mdulo de programa que proporciona el interfaz entre los datos debajo nivel
almacenados y los programas de aplicacin y consultas, y es responsable de las siguientes tareas :
1.- Interaccin con el gestor de archivos. El gestor de BD traduce las distintas sentencias DML a comandos del
sistema de archivos de bajo nivel. As, es responsable del verdadero almacenamiento de los datos.
2.-Implantacin de la integridad. Los valores de los datos que se almacenan deben satisfacer ciertos tipos de
restricciones de consistencia, que debe especificar explcitamente el administrador de la BD. El gestor de la BD entonces
puede determinar si se produce una violacin de la restriccin, si es as, se debe tomar la accin apropiada.
3.- Implantacin de la seguridad. Es trabajo del gestor de la BD debe hacer que se cumplan los requisitos de
seguridad.
4.- Copia de seguridad y recuperacin. Un sistema informtico, como cualquier otro dispositivo, esta sujeto a
fallos. Es responsabilidad del gestor de BD detectar fallos y restaurar la BD al estado que exista antes de ocurrir el fallo.
Esto se lleva a cabo normalmente con procedimientos de copias de seguridad y recuperacin.
5.- Control de concurrencia. Cuando varios usuarios actualizan la BD de forma concurrente, es posible que no
se conserve la consistencia de los datos. Controlar la interaccin entre los usuarios concurrentes es otra responsabilidad
del gestor de la BD.
Los sistemas de BD diseados para computadores personales pequeos pueden no tener todas las
caractersticas apuntadas.
1.9. Administrador de bases de datos.
Una de las razones principales para tener DBMS es tener control central de los datos y de los programas que
acceden a esos datos. La persona que tiene dicho control central sobre el sistema se llama administrador de la BD
(database administrator, DBA). Las funciones del DBA son :
1.- Definicin de esquema. El esquema original de la BD se crea escribiendo un conjunto de definiciones que
son traducidas por el compilador de DDL a un conjunto de tablas, almacenadas permanentemente en el diccionario de
datos.
2.- Definicin de la estructura de almacenamiento y del mtodo de acceso. Se crean escribiendo un conjunto de
definiciones traducidas por el compilador del lenguaje de almacenamiento y definicin de datos.
3.- Modificacin del esquema y de la organizacin fsica. Las modificaciones son poco comunes, pero se logran
escribiendo un conjunto de definiciones usadas por el compilador DDL para generar modificaciones a las tablas internas
apropiadas.
4.- Concesin de autorizacin para el acceso a los datos. La concesin de diferentes tipos de autorizacin
permite al DBA regular qu partes de la BD van a poder ser accedidas por varios usuarios.
5.- Especificacin de las restricciones de integridad. Las restricciones de integridad se mantienen en una
estructura especial del sistema que consulta el gestor de la BD cada vez que tiene lugar una actualizacin.
1.10. Usuarios de bases de datos.
Un objetivo principal de un DBMS es proporcionar un entorno para recuperar y almacenar informacin en la
BD. Hay cuatro tipos de usuarios, diferenciados por la forma de interaccionar con el sistema:
1.- Programadores de aplicaciones. Los profesionales en computacin interaccionan con el sistema por medio
de llamadas en DML, incorporadas en un programa escrito en un lenguaje principal (como Pascal o C). Estos
programas se denominan comnmente programas de aplicacin.
Puesto que la sintaxis de DML es normalmente diferente de la del lenguaje principal, las llamadas en DML van
normalmente precedidas de un carcter especial de forma que se pueda generar el cdigo apropiado. Un preprocesador
especial, llamado precompilador de DML, convierte las sentencias en DML a llamadas en el lenguaje principal. El
programa resultante se ejecuta entonces por el compilador del lenguaje principal, que genera el cdigo objeto apropiado.
Hay tipos especiales de lenguajes de programacin que combinan estructuras de control de lenguajes como
Pascal con estructuras de control para el manejo de un objeto de la BD, como relacciones. Estos lenguajes. A veces
llamados lenguajes de cuarta generacin, a menudo incluyen caractersticas especiales para facilitar la generacin de formas
y la presentacin de datos en pantalla. La mayora de los DBMS comerciales incluyen un lenguaje de cuarta generacin.
Bases de datos
6
2.- Usuarios sofisticados. Interaccionan con el sistema sin escribir programas, en cambio escriben sus preguntas
en un lenguaje de consultas. Cada consulta se somete a un procesador de consultas, cuya funcin es tomar una sentencia
en DML y descomponerla en instrucciones que entienda el gestor de la BD.
3.- Usuarios especializados. Algunos usuarios sofisticados escriben aplicaciones de BD especializadas que no
encajan en el marco tradicional de procesamiento de datos, como diseo asistido por computador, sistemas basados en
el conocimiento, etc.
4.- Usuarios ingenuos. Los usuarios no sofisticados interactuan con el sistema invocando a uno de los
programas de aplicacin permanentes que se han escrito anteriormente.
1.11. Estructura del sistema global.
Un DBMS se divide en mdulos que tratan cada una de las responsabilidades del sistema general. En la
mayora de los casos, el sistema operativo proporciona nicamente los servicios bsicos, y el sistema de be partir de esa
base. As, el diseo de un DBMS debe incluir la consideracin del interfaz entre la BD y el sistema operativo.
Los componentes funcionales de un DBMS incluyen :
1.- Gestor de archivos. Gestiona la asignacin de espacio en la memoria del disco y de las estructuras de datos
usadas para representar la informacin almacenada en el disco.
2.- Gestor de base de datos. Proporciona el interfaz entre los datos de bajo nivel almacenados y los programas
de aplicacin y las consultas al sistema.
3.- Procesador de consultas. Traduce sentencias en un lenguaje de consultas a intrucciones de bajo nivel que
entiende el gestor de la BD.
4.- Precompilador de DML. Convierte las sentencias DML incorporadas en un programa de aplicacin en
llamadas normales a procedimientos del lenguaje principal. Debe interaccionar con el procesador de consultas para
generar el cdigo apropiado.
5.- Compilador de DDL. Convierte sentencias DDL en un conjunto de tablas que contienen metadatos.
Adems se requieren varias estructuras de datos como parte de la implementacin del sistema fsico, cmo :
1.- Archivos de datos. Para almacenar la BD.
2.- Diccionario de datos. Que almacena metadatos sobre la estructura de la BD. Se usa ampliamente, por lo que
debe ponerse mucho nfasis en le desarrollo de un buen diseo y una implementacin eficiente del diccionario.
3.- Indices. Proporcionan acceso rpido a los elementos de datos que contienen valores determinados.
Tema 1. Introduccin
7
Bases de datos
8
Tema 2. Modelo entidad-relacin
9
Tema 2.Modelo entidad-relacin.
El modelo de datos entidad-relacin (E-R) se basa en una percepcin de un mundo real que consiste en un
conjunto de objetos bsicos llamados entidades y relaciones entre estos. Se desarrollo para facilitar el diseo de BD
permitiendo la especificacin de un esquema empresarial, que representa la estructura lgica global de la BD.
2.1. Entidades y conjuntos de entidades.
Una entidad es un objeto que existe y es distinguible de otros objetos, por ejemplo John Harris, con nmero
de seguridad social 890-12-3456, es una entidad, ya que indica nicamente una persona especifica. Una entidad puede ser
concreta, como un libro, o abstracta, como un concepto.
Un conjunto de entidades es un grupo de entidades del mismo tipo, por ejemplo, en un banco, el conjunto de
entidades cliente. Los conjuntos de entidades no necesitan ser disjuntos, es posible definir los conjuntos de entidades de
empleados y clientes de un banco, pudiendo existir una persona ser ambas o ninguna de las dos cosas.
Una entidad est representada por un conjunto de atributos, que formalmente es una funcin que asigna un
conjunto de entidades a un dominio. As, cada entidad se describe por medio de un conjunto de pares (atributo, valor
de dato), un par cada elemento del conjunto de entidades.
El concepto de un conjunto de entidades corresponde a la nocin de definicin de tipo en un lenguaje de
programacin.
Por tanto, una BD incluye una coleccin de conjuntos de entidades cada uno de los cuales contiene un nmero
cualquiera de entidades del mismo tipo.
En este tema trabajaremos con cinco conjuntos de entidades :
1.- Sucursal. El conjunto de todas las sucursales de un banco. Cada sucursal se describe por los atributos
nombre_sucursal, ciudad_sucursal y activo.
2.- Cliente. El conjunto de todas las personas que tienen cuentas en el banco, y se describen por medio de los
atributos nombre_cliente, seguridad_social, calle y ciudad_cliente.
3.- Empleado. El conjunto de todas las personas empleadas en el banco, que se describen por los atributos
nombre_empleado y nmero_telfono.
4.- Cuenta. El conjunto de todas las cuentas de banco, descritas por nmero_cuenta y saldo.
5.- Transaccin. El conjunto de todas las transacciones de cuentas ejecutadas en le banco. Cada transaccin se
describe por los atributos nmero_transaccin, fecha y cantidad.
2.2. Relaciones y conjuntos de relaciones.
Una relacin es una asociacin entre varias entidades, por ejemplo, podemos definir una relacin que asocia al
cliente Harris con la cuenta 401.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo. Formalmente es un relacin de n2
conjuntos de entidades (posiblemente no distintos). Si E1, E2, ...,En son conjuntos de entidades, entonces un conjunto
de relaciones R es un subconjunto de
{(e1, e2, ..., en)| e1E1, e2E2, ..., enEn}
donde (e1, e2, ..., en) es una relacin.
La mayora de los conjuntos de relaciones en un sistema de BD son binarios, aunque ocasionalmente hay
conjuntos de relaciones que implican ms de dos conjuntos de entidades, como la relacin entre cliente, cuenta y
sucursal. Siempre es posible sustituir un conjunto de relaciones no binario por varios conjuntos de relaciones binarias
distintos. As, conceptualmente, podemos restringir el modelo E-R para incluir slo conjuntos binarios de relaciones,
aunque no siempre es deseable.
La funcin que juega una entidad en una relacin se llama papel, y normalmente son implcitos y no se suelen
especificar. Sin embargo son tiles cuando el significado de una relacin necesita ser clarificado. Tal es el caso cuando los
conjuntos de entidades de un conjunto de relaciones no son distintos. Por ejemplo, el conjunto de relaciones
trabaja_para podra modelarse por pares ordenados de entidades empleado. El primer empleado de cada par toma el
papel de director, mientras el segundo toma el papel de trabajador.
Una relacin tambin puede tener atributos descriptivos, por ejemplo fecha en el conjunto de relaciones
cuenta_cliente que especifica la ltima fecha en la que el cliente tuvo acceso a su cuenta.
2.3. Atributos.
Es posible definir un conjunto de entidades y sus relaciones de varias formas diferentes. La principal diferencia
est en la forma en que tratamos los diversos atributos. Considrese el conjunto de entidades empleado con atributos
nombre_empleado y nmero_telfono. Se puede argumentar fcilmente que un telfono es una entidad en s mismo
con atributos nmero_telfono y situacin (la oficina donde est). Si tomamos este punto de vista, el conjunto de
entidades empleado debe redefinirse como sigue:
1.- El conjunto de entidades empleado con atributo nombre_empleado.
2.- El conjunto de entidades telfono con atributo nmero_telfono y situacin.
3.- El conjunto de relaciones empltelf, que indica la asociacin entre los empleados y los telfonos que tienen.
Bases de datos
10
En el primer caso, la definicin implica que cada empleado tiene exactamente un nmero de telfono asociado.
En el segundo, la definicin afirma que los empleados pueden tener varios nmeros de telfono asociados. As, la
segunda definicin es ms general que la primera, y puede reflejar con ms precisin la situacin del mundo real.
No sera apropiado aplicar la misma tcnica al atributo nombre_empleado, ya que es difcil argumentar que sea
una entidad en si misma, as que es adecuado tener nombre_empleado como un argumento del conjunto de entidades
empleado.
Surge entonces una pregunta qu constituye un atributo y que constituye un conjunto de entidades ?.
Desafortunadamente, no hay una respuesta sencilla, la distincin depende principalmente de la estructura de la empresa
que se est modelando y de la semntica asociada con el atributo en cuestin.
2.4. Restricciones de asignacin (mapping).
Una planificacin E_R de una empresa puede definir ciertas restricciones a las cuales deben ajustarse los
contenidos de una BD. Una restriccin importante es la de las cardinalidades de asignacin, que expresa el nmero de
entidades con las que puede asociarse otra entidad mediante un conjunto de relaciones.
Las cardinalidades de asignacin son ms tiles al describir conjuntos binarios de relaciones, por lo que nos
centraremos slo en ellas.
Para un conjunto binario de relaciones R entre los conjuntos de entidades A y B, la cardinalidad de asignacin
debe ser una de las siguientes :
1.- Una a una. Una entidad en A est asociada a lo sumo con una entidad en B, y una de B a lo sumo con una
de A.
2.- Una a muchos. Una entidad en A est asociada con un nmero cualquiera de entidades de B, pero una de B
slo puede estar asociada a una de A.
3.- Muchas a una. Una entidad en A est asociada con una sola de B, sin embargo, en de B puede estar asociada
con varias de A.
4.- Muchas a muchas. Una entidad en A est asociada con un nmero cualquiera en B, y una en B est asociada
con un nmero cualquiera en A.
La cardinalidad de asignacin adecuada para un conjunto de relaciones determinado es dependiente del mundo
real que el conjunto de relaciones est modelando.
Las dependencias de existencia constituyen otra clase importante de restricciones. Especficamente, si la
existencia de la entidad x depende de la existencia de la entidad y, entonces se dice que es dependiente por existencia de y.
Operativamente, esto significa que si se suprime y, tambin se suprime x. La entidad y se dice que es una entidad
dominante, mientras que x se dice que es una entidad subordinada.
Para ilustrar esto, consideremos los conjuntos de entidades cuenta y transaccin. Cada entidad transaccin debe
estar asociada con una entidad cuenta, si se suprime una entidad cuenta, entonces todas sus entidades transaccin
asociadas deben tambin suprimirse. Por el contrario, las entidades transaccin pueden suprimirse de la BD sin afectar a
ninguna cuenta. El conjunto de entidades cuenta es dominante, y transaccin es subordinado.
2.5. Claves.
Es importante poder especificar cmo se distinguen las entidades y las relaciones. Conceptualmente, las
entidades individuales y las relaciones son distintas, pero, desde la perspectiva de una BD, la diferencia entre ellas debe
expresarse en trminos de sus atributos. El concepto de superclave nos permite hacer dicha distincin.
Una superclave es un conjunto de uno o ms atributos que, considerados conjuntamente, nos permiten
identificar de forma nica a una entidad dentro del conjunto de entidades. Por ejemplo, el atributo seguridad_social, del
conjunto de entidades cliente es una superclave. Anlogamente la combinacin de nombre_cliente y seguridad_social es
una superclave, as que si K es una superclave, entonces tambin lo ser algn subconjunto de K. A menudo estamos
interesados en superclaves mnimas para las cuales ningn subconjunto propio es superclave, y se denominan claves
candidatas.
Usaremos el trmino clave primaria para denotar una clave candidata que elige el diseador de la BD 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 dbil, mientras que se denominar conjunto de
entidades fuerte si tiene una clave primaria.
Para ilustrarlo considrese el conjunto de entidades transaccin, distintas entidades asociadas a distintas cuentas
pueden tener el mismo valor del atributo nmero_transaccin. As este conjunto de entidades es dbil, ya que no tiene
clave primaria. Para que un conjunto de entidades dbil sea significativo, debe ser parte de un conjunto de relaciones una
a muchas, y que no debe tener atributos descriptivos, ya que cualquier atributo que se necesite puede estar asociado con le
conjunto de entidades dbil.
Los conceptos de entidades fuertes y dbiles estn relacionados con las dependencias por existencia. Un
miembro de un conjunto de entidades fuerte es, por definicin una entidad dominante, mientras que un miembro de
un conjunto de entidades dbil es una entidad subordinada por definicin.
Aunque un conjunto de entidades dbil no tiene clave primaria debe tener un medio de distinguir entre todas
aquellas entidades en el conjunto de entidades que dependen de una entidad fuerte determinada.
11
El discriminador de un conjunto de entidades dbil es un conjunto de atributos que permite que se haga esta
distincin. Por ejemplo, el discriminador del conjunto de entidades dbil transaccin es el atributo nmero_transaccin,
ya que para cada cuenta un nmero de transaccin identifica de forma nica una entidad.
La clave primaria de un conjunto de entidades dbil esta formada por la clave primaria del conjunto de
entidades fuerte de la que depende su existencia y su discriminador. En el caso del conjunto transaccin, la clave primaria
es {nmero_cuenta, nmero-transaccin}, donde nmero_cuenta identifica a la entidad dominante de una transaccin y
nmero_transaccin distingue entidades transaccin dentro de la misma cuenta.
Sea R un conjunto de relaciones que implica a los conjuntos E1, E2, ..., En. Sea (Ei) la clave primaria que denota
el conjunto de atributos que forma la clave primaria para el conjunto de entidades Ei. Supngase que R no tiene
atributos. Entonces los atributos que describen las relaciones individuales del conjunto R, denotadas por el atributo(R),
son :
Clave_primaria (E1) Clave_primaria (En)... Clave_primaria (En)
En el caso de que R tenga atributos descriptivos, digamos {a1, a2, ...,am}, entonces el conjunto atributo(R)
consta de:
Clave_primaria (E1)... Clave_primaria (En) {a1, a2, ...,am}
Considrese el conjunto de relaciones CtaCli, que implica a los conjuntos de entidades cliente, con clave
primaria seguridad_social, y cuenta, con clave primaria nmero_cuenta. Puesto que el conjunto de relaciones tiene el
atributo fecha, el conjunto atributo(CtaCli) se compone de los tres atributos, seguridad_social, nmero_cuenta y fecha.
Ahora ya podemos explicar que constituye la clave primaria de un conjunto de relaciones R. La composicin de
la clave primaria depende de la cardinalidad de asignacin y de la estructura de los atributos asociados con el conjunto de
relaciones R.
Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto atributo(R) forma una
superclave. Esta superclave es una clave primaria si la cardinalidad de asignacin es muchas a muchas.
Considrese el conjunto de relaciones CtaCli. Si el conjunto de relaciones es muchas a muchas su clave primaria
ser {seguridad_social, nmero_cuenta}, si es muchas a una, de cliente a cuenta, entonces su clave primaria ser
{seguridad_social}, ya que una persona puede tener una sola cuenta asociada.
Si el conjunto de relaciones R tiene varios atributos asociados con l, entonces una superclave est formada
como antes, ms la posible adicin de uno o ms de estos atributos. La estructura de la clave primaria depende tanto de
la cardinalidad de asignacin como de las semnticas del conjunto de relaciones.
Considrense los conjuntos de entidades cliente y banquero y un conjunto de relaciones BanqueroCli.
Supngase que ste conjunto de relaciones tiene el atributo tipo asociado con l que representa la naturaleza de la relacin
con el cliente (prestamista o banquero). Si un banquero determinado puede representar dos papeles distintos en una
relacin con un cliente determinado, entonces la clave primaria de BanqueroCli consta de la unin de las claves primarias
cliente y banquero, as como del atributo tipo. Sin embargo, si un banquero slo puede tener una relacin con un cliente
determinado, entonces tipo no es parte de la clave primaria, que ser nicamente la unin de las claves primarias cliente y
banquero.
2.6. Diagrama entidad-relacin.
Como vimos, la estructura global de una BD puede representarse grficamente por medio de un diagrama de
E-R, que consta de:
1.- Rectngulos, que representan conjuntos de entidades.
2.- Elipses, que representan atributos.
3.- Rombos, que representan conjuntos de relaciones.
4.- Lneas, que enlazan atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones.
Para distinguir entre las diferentes cardinalidades, dibujaremos lneas, con o sin direccin entre los conjuntos de
relaciones y el conjunto de entidades en cuestin. Una lnea con direccin () marcar la cardinalidad una, mientras que
una lnea sin flecha (--) indicar la cardinalidad muchas.
Adems, un conjunto de entidades dbil se
indica por medio de un rectngulo de doble contorno.
2.7. Reduccin de los diagramas E-R a tablas.
Bases de datos
12
Una BD que se ajusta a un diagrama E-R puede representarse por medio de una coleccin de tablas. Para cada
conjunto de entidades y para cada conjunto de relaciones en la BD, existe una tabla nica a la que se le asigna el nombre
del conjunto correspondiente. Cada tabla tiene un nmero de columnas, que tienen nombres nicos.
2.7.1. Representacin de conjuntos de entidades fuertes.
Sea E un conjunto de entidades fuerte con los atributos descriptivos a1, a2, ..., an. Representamos esta entidad
por medio de una tabla llamada E con n columnas distintas que corresponden a los n atributos de E. Cada fila de esta
tabla corresponde a una entidad del conjunto de entidades E.
Por ejemplo, considrese el conjunto de entidades cuenta, con los atributos nmero_cuenta y saldo.
Representaremos este conjunto mediante una tabla llamada cuenta, con dos columnas, llamadas nmero_cuenta y saldo.
Podemos aadir una nueva cuenta a la BD con aadir una sola fila en la tabla.
Sea D1 el conjunto de todos los nmeros de cuenta, y sea D2 el conjunto de todos los saldos. Cualquier fila de
la tabla cuenta debe consistir en una tupla binaria (v1, v2), donde v1es un nmero de cuenta, y v2 es un saldo. En general
la tabla cuenta contendr nicamente un subconjunto de los conjuntos de todas las filas posibles. Nos referimos al
conjunto de todas las filas posibles de cuenta como el producto cartesiano de D1 y D2, que se expresa:
D1 x D2
En general, si tenemos una tabla de n columnas, indicamos el producto cartesiano por :
D1 x D2 x ... x Dn-1 x Dn
2.7.2. Representacin de conjuntos de entidades dbiles.
Sea A un conjunto de entidades dbil con atributos a1, a2, ..., ar. Sea B el conjunto de entidades fuerte del que
depende A. La clave primaria de B consta de los atributos b1, b2, ..., bs. Representamos el conjunto de entidades A
mediante una tabla llamada A con una columna para cada atributo del conjunto :
{a1, a2, ..., ar} {b1, b2, ..., bs}
Considrese el conjunto de entidades transaccin, con atributos nmero_transaccin, fecha y cantidad. La clave
primaria del conjunto de entidades cuenta, de la que transaccin es dependiente, es nmero_cuenta. As, la tabla
transaccin tendr cuatro columnas etiquetadas nmero_cuenta, nmero_transaccin, fecha y cantidad.
2.7.3. Representacin de conjuntos de relaciones.
Sea R un conjunto de relaciones que implica a los conjuntos de entidades E1, E2, ..., Em. Supongamos que
atributo(R) consta de n atributos. Representamos este conjunto de relaciones mediante una tabla llamada R con n
columnas distintas, cada una de las cuales corresponde a uno de los atributos de atributo(R).
Considrese el conjunto de relaciones CtaCli, que implica a los conjuntos de entidades cliente y cuenta, con
claves primarias seguridad_social y nmero_cuenta. Puesto que el conjunto de relaciones tiene el atributo fecha, la tabla
CtaCli tiene tres columnas etiquetadas seguridad_social, nmero_cuenta y fecha.
El caso de relaciones que conectan un conjunto de entidades dbil con su correspondiente conjunto fuerte es
especial. Estas relaciones son muchas a una y no tienen atributos descriptivos. Adems la clave primaria de un conjunto
de entidades dbil incluye la del fuerte. Consideremos el conjunto de entidades dbil transaccin dependiente del
conjunto de entidades fuerte cuenta a travs del conjunto de relaciones log. La clave primaria de transaccin es
{nmero_cuenta, nmero_transaccin}, y la de cuenta {nmero_cuenta}. Puesto que log no tiene atributos descriptivos,
la tabla de log tendra dos columnas, nmero_cuenta y nmero_transaccin. La tabla para el conjunto de entidades
transaccin tiene cuatro columnas, nmero_cuenta, nmero_transaccin, fecha y cantidad. As, la tabla log es redundante.
En general, la tabla para el conjunto de relaciones que conecta un conjunto de entidades dbil con su
correspondiente conjunto de entidades fuerte es redundante y no necesita presentarse en una presentacin tabular de un
diagrama E-R.
2.8. Generalizacin.
Considrese el conjunto de entidades cuenta, con atributos nmero_cuenta y saldo. Ampliamos nuestro
ejemplo anterior clasificando cada cuenta entre cuenta_ahorros y cuenta_cheques. Cada una de stas se describe mediante
un conjunto de atributos que incluye todos los atributos del conjunto de entidades cuenta ms atributos adicionales.
Por ejemplo, las entidades cuenta_ahorros se describen adems con el atributo tasa_inters, y las
cuenta_cheques con el atributo saldo_deudor. Existen aspectos similares entre los conjuntos, en el sentido de que tienen
varios atributos en comn (los originales de cuenta).
Esto puede expresarse por generalizacin, que es una relacin de inclusin que existen entre un conjunto de
entidades de un nivel ms alto y uno o ms conjuntos de entidades de nivel ms bajo. En el ejemplo anterior, cuenta es
el conjunto de nivel ms alto, y cuenta_ahorros y cuenta_cheques son los conjuntos de entidades de nivel ms bajo.
13
En trminos de un diagrama E-R, la generalizacin se representa por medio de un componente tringulo
etiquetado ISA (is a, es un/ a) y representa, por ejemplo, que una cuenta de ahorros es una cuenta.
La generalizacin se usa para hacer resaltar los parecidos entre tipos de entidades de nivel ms bajo y ocultar sus
diferencias. La distincin se hace a travs de un proceso llamado herencia de atributos. Los atributos de entidades de
nivel ms alto se dice que son heredados por los conjuntos de entidades de nivel ms bajo.
Por ejemplo, cuenta_ahorros hereda los atributos de cuenta, por lo que tendr tres atributos, nmero_cuenta,
saldo y tasa_inters.
Existen dos mtodos diferentes para transformar un diagrama E-R que incluye generalizacin en una forma
tabular :
1.- Crear una tabla para el conjunto de entidades de nivel ms alto. Para cada conjunto de entidades de nivel
ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades, ms una
columna para cada atributo de la clave primaria del conjunto de entidades del nivel ms alto. As, para el ejemplo anterior
tendremos tres tablas : cuenta (nmero_cuenta, saldo), cuenta_ahorros (nmero_cuenta, tasa_inters) y cuenta_cheques
(nmero_cuenta, saldo_deudor).
2.- No crear una tabla para el conjunto de entidades de nivel ms alto. En cambio, para cada conjunto de
entidades de nivel ms bajo, crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de
entidades, ms una columna para cada atributo del conjunto de nivel ms alto. Entonces, para el ejemplo, tendremos:
cuenta_ahorros (nmero_cuenta, saldo, tasa_inters) y cuenta_cheques (nmero_cuenta, saldo, saldo_deudor).
2.9. Agregacin.
Una limitacin del modelo E-R es que no es posible expresar relaciones entre relaciones. Para ilustrar la
necesidad de una construccin as, considrese una BD que describe informacin acerca de empleados que trabajan en un
proyecto determinado y usan varias mquinas distintas.
Puede ocurrir que los conjuntos de relaciones trabajo y usa se combinen en un nico conjunto de relaciones. Sin
embargo, no deben combinarse, puesto que oscurecera la estructura lgica del esquema.
La solucin es usar agregacin. La agregacin es una abstraccin a travs de la cual las relaciones se tratan como
entidades de nivel ms alto. As, para nuestro ejemplo, recordamos el conjunto de relaciones trabajo y los conjuntos de
entidades empleado y proyecto como un conjunto de entidades de nivel ms alto llamado trabajo, as, se trata de la
misma forma que cualquier otro conjunto de entidades.
Bases de datos
14
La transformacin de un diagrama E-R que incluya agregacin a una forma tabular es directa, creando las tablas
empleado, proyecto, trabajo, maquinaria y usa. La tabla para el conjunto de relaciones usa incluye una columna para cada
atributo en la clave primaria del conjunto de entidades maquinaria y del conjunto de relaciones trabajo. Tambin incluye
una columna para cada atributo del conjunto de relaciones usa.
2.10. Diseo de un esquema de base de datos E-R.
El modelo de datos E-R proporciona un alto grado de flexibilidad en el diseo de un esquema de BD, entre
una amplia variedad de alternativas, el diseador de la BD debe tomar varias decisiones como :
1.- El uso de una relacin ternaria o de un par de relaciones binarias.
2.- Si un concepto de un mundo real se expresa mejor como un conjunto de entidades que como un conjunto
de relaciones.
3.- El uso de un atributo o de un conjunto de entidades.
4.- El uso de un conjunto de entidades fuerte o dbil.
5.- La oportunidad de usar agregacin.
6.- La oportunidad de usar generalizacin.
2.10.1. Cardinalidades de asignacin.
Considrese el conjunto ternario de relaciones de la figura. Esta relacin especifica que un cliente puede tener
varias cuentas, cada una en una sucursal, y que una cuenta puede pertenecer a varios clientes.
Este conjunto de relaciones podra sustituirse por un par de conjuntos de relaciones, como el de la siguiente
figura, pero aqu, cada cuenta est situada en una sucursal. El conjunto de relaciones muchas a muchas CtaCli especifica
que un cliente puede tener varias cuentas y que una cuenta puede pertenecer a varios clientes diferentes.
Hay una sutil distincin entre ambos diagramas, en el primero, la relacin entre un cliente y una cuenta puede
representarse nicamente si hay una sucursal correspondiente, mientras que en el segundo, una cuenta puede estar
relacionada con una sucursal sin el cliente correspondiente, o con un cliente sin la sucursal correspondiente.
2.10.2. Uso de conjuntos de entidades o de conjuntos de relaciones.
No siempre est claro si un objeto se expresa mejor mediante un conjunto de entidades o mediante un
conjunto de relaciones. En el ejemplo desarrollado, las cuentas se pueden representar como relaciones entre clientes y
sucursales, con nmero_cuenta y saldo como atributos descriptivos. En este diseo, un cliente puede tener una cuenta
en muchas sucursales y una sucursal puede tener muchos clientes. Cada cuenta se representa mediante una relacin entre
un cliente y una sucursal.
Pero este diseo no puede representar convenientemente una situacin en la varios clientes tienen una cuenta
en comn, se debe definir una relacin separada para cada titular de la cuenta, con los mismos valores en los atributos
descriptivos, desperdiciando espacio de almacenamiento. Sin embargo, si cada cuenta tiene exactamente un titular, el
diseo ser satisfactorio.
2.10.3. Uso de caractersticas de E-R ampliado.
15
El diseador de un esquema de BD debe decidir cuando es conveniente el uso de conjuntos de entidades
dbiles, generalizacin y agregacin para modelar una empresa con el modelo de datos E-R. Cada una de estas
caractersticas contribuye a la modularidad del diseo :
1.- Un conjunto de entidades fuerte y sus conjuntos de entidades dbiles dependientes pueden ser
considerados como un objeto nico en la BD, ya que las entidades dbiles son dependientes por existencia de una
entidad fuerte.
2.- La agregacin agrupa una parte del diagrama E-R en un conjunto de entidades nicas. Es posible tratar el
conjunto de entidades agregado como una unidad nica sin preocuparse de los detalles de estructura interna.
3.- Generalizacin, o jerarqua de relaciones ISA, contribuye a la modularidad permitiendo que atributos
comunes de conjuntos de entidades similares sean representados una sola vez en un diagrama E-R.
Sin embargo, el uso excesivo de estas caractersticas puede introducir una complejidad innecesaria en el diseo.
Bases de datos
16
Tema 3. Modelo relacional.
17
Tema 3.Modelo relacional.
El modelo de datos relacional es relativamente nuevo. Tras la introduccin del modelo relacional se ha
desarrollado una teora esencial para las BD relacionales, que ayuda al diseo de BD relacionales y al procesamiento
eficiente de solicitudes de informacin.
El modelo relacional se ha establecido como el principal modelo de datos para aplicaciones comerciales de
procesamiento de datos.
3.1. Estructura de las bases de datos relacionales.
Una BD relacional consiste en una coleccin de tablas, a cada una de las cuales se les asigna un nombre nico.
Una fila de la tabla representa una relacin entre un conjunto de valores, puesto que una tabla es una coleccin de dichas
relaciones, hay una estrecha correspondencia entre el concepto de tabla y el concepto matemtico de relacin, del cual
toma su nombre el modelo de datos relacional.
3.1.1. Estructuras bsicas.
Considrese la tabla depsito, con cuatro atributos : nombre_sucursal, nmero_cuenta, nombre_cliente y
saldo. Para cada atributo hay un conjunto de valores permitidos, llamado dominio, de este atributo, por ejemplo, para
nombre_sucursal, el dominio ser el conjunto de todos los nombres de la sucursales.
Sea D1 el dominio de nombre_sucursal, y D2, D3 , D4 los dominios de los otros atributos. Cada una de las
filas de depsito debe constar de 4 tuplas (v1, v2, v3, v4), perteneciendo cada una a su dominio correspondiente. En
general, depsito contendr nicamente un subconjunto del conjunto de todas las filas posibles, por tanto, depsito es
un subconjunto de: D1 x D2 x D3 x D4
En general, una tabla de n columnas debe ser un subconjunto de:
D1 x D2 x ... x Dn-1 x Dn
Los matemticos definen una relacin como un subconjunto de un producto cartesiano de una. lista de
dominios, lo que se corresponde casi exactamente con nuestra definicin de tabla.
Puesto que las tablas son esencialmente relaciones, usaremos los trminos matemticos relacin y tupla en
lugar de los trminos tabla y fila.
Sea la variable tupla t la primera tupla de la relacin. Usamos la notacin t[nombre_sucursal] para indicar el
valor de t en el atributo nombre_sucursal, alternativamente, podemos escribir t[1] para indicarlo. Puesto que una
relacin es un conjunto de tuplas, usamos la notacin matemtica t r para indicar que la tupla t est en la relacin r.
Necesitaremos que, para todas las relaciones r, los dominios de todos los atributos sean atmicos,
entendiendo coma tal a aquel en el que sus elementos se consideran unidades indivisibles, por ejemplo, los nmeros
naturales. En todos nuestros ejemplos supondremos dominios atmicos.
3.1.2. Esquema de la base de datos.
Cuando hablamos de una BD debemos diferenciar entre el esquema de la BD o el diseo lgico de la BD, y
una instancia de la BD, que son los datos en la BD en un instante de tiempo dado. El concepto de esquema de una
relacin corresponde a la nocin de definicin de tipo en los lenguajes de programacin, mientras que el de instancia de
una relacin se corresponde con el de variable.
Es conveniente dar un nombre al esquema de una relacin, por lo que adoptamos el convenio de usar
nombres en minsculas para relaciones y nombres, empezando por una letra mayscula para los esquemas de relaciones.
Siguiendo esta notacin usamos esquema_depsito para indicar el esquema de relacin para la relacin depsito. As :
Esquema_depsito = (nombre_sucursal, nmero_cuenta, nombre_cliente, saldo)
Indicamos el hecho de que depsito es una relacin sobre el esquema depsito por :
depsito (esquema_depsito)
En general, el esquema de una relacin es una lista de atributos y sus correspondientes dominios. No nos
preocuparemos, por ahora, de dar una definicin precisa del dominio de cada atributo, sin embargo, cuando queramos
definir nuestros dominios, para definir el esquema de relacin para la relacin depsito, usaremos la notacin :
(nombre_sucursal: cadena, nmero_cuenta: entero, nombre_cliente: cadena, saldo: entero)
Considrese la relacin cliente, con el esquema para esa relacin que sigue:
Esquema_cliente = (nombre_cliente, calle, ciudad_cliente)
Obsrvese que el atributo nombre_cliente aparece en los dos esquemas de relaciones. Esto no es una
coincidencia, el uso de atributos comunes en esquemas de relaciones es una forma de relacionar tuplas de distintas
relaciones.
Se podra pensar en trminos de un esquema de relaciones en vez de en varios. Supngase que usamos slo
una relacin para nuestro ejemplo con el esquema:
Esquema_info_cuenta = (nombre_sucursal, nmero_cuenta, nom,bre_cliente, saldo, calle, ciudad_cliente)
Obsrvese que si un cliente tiene varias cuentas debemos listar su direccin una vez para cada cuenta, es decir,
debemos repetir informacin, lo que supone un desperdicio y se evita mediante el uso de dos relaciones.
Adems, si un cliente tiene una o ms cuentas pero no ha dado una direccin, no podemos construir una tupla
en esquema_info_cuenta, ya que no se conocen los valores para calle y ciudad_cliente. Para representar tuplas incompletas
Bases de Datos
18
debemos usar valores nulos. Usando dos relaciones, podemos representar clientes cuya direccin se desconozca sin usar
valores nulos, simplemente usamos una tupla en esquema_depsito y no creamos tupla en esquema_cliente hasta que
la informacin est disponible.
No siempre es posible eliminar los valores nulos, supngase que incluimos el atributo nmero_telfono en el
esquema_cliente. Puede ocurrir que un cliente no tenga telfono, entonces tendramos que recurrir a los valores nulos.
Veremos ms adelante que los valores nulos causan diversas dificultades en el acceso o actualizxacin de la BD y, por
tanto, deben eliminarse cuando sea posible.
Para el propsito de este captulo supondremos una empresa bancaria con el diagrama E-R de la figura. Las
claves primarias para los conjuntos entidad cliente y sucursal son nombre_cliente y nombre_sucursal. Ls esquemas de
relaciones para esta empresa son :
Esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal)
Esquema_cliente = (nombre_cliente, calle, ciudad_cliente)
Esquema_depsito = (nombre_sucursal, nmero_cuenta, nombre_cliente, saldo)
Esquema_prstamo = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
3.1.3. Claves.
Las nociones de superclave, clave candidata y clave primaria tambin pueden aplicarse al modelo relacional, por
ejemplo, en esquema_sucursal, {nombre_sucursal} y {nombre_sucursal, ciudad_sucursal} son superclaves, la primera
es una clave candidata, no as la segunda, que contiene a la primara, por lo que la primera es la clave primaria, y la clave
primaria para esquema_cliente es {nombre_cliente}.
Sea R un esquema de relacin. Si decimos que un subconjunto K de R es una superclave para R estamos
retringindonos a considerar las relaciones r(R), en las que no haya dos tuplas distintas que tengan los mismos valores
en todos los atributos de K. Es decir, si t1 y t2 estn en r y t1 t2, entonces t1[K] t2[K].
3.1.4. Lenguajes de consulta.
Un lenguaje de consulta es un lenguaje en el que el usuario solicita informacin de la BD. Son, normalmente,
de ms alto nivel que los estndar de programacin. Los lenguajes de consulta pueden clasificarse en lenguajes
procedimentales y no procedimentales. En un lenguaje procedimental, el usuario da instrucciones al sistema para que
realice una serie de operaciones en la BD para calcular el resultado deseado. En uno no procedimental, el usuario describe
la informacin deseada sin dar un procedimiento especifico para obtenerla.
La mayor parte de los sistemas comerciales de BD relacionales, ofrecen un lenguaje de consulta que incluye
elementos de los dos enfoques.
En este captulo examinamos dos lenguajes puros, el lgebra relacional es procedimental, mientras que el
clculo relacional de tuplas y el clculo relacional de dominios son no procedimentales. Estos lenguajes de consulta son
concisos y formales, pero ilustran las tcnicas fundamentales para extraer datos de la BD.
Inicialmente nos interesaremos nicamente por las consultas, aunque un lenguaje de manipulacin de datos
completo incluye, adems de un lenguaje de consulta, un lenguaje para la modificacin de la BD.
3.2. El lgebra relacional.
El lgebra relacionales un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que
toman una o dos relaciones como entrada y producen una nueva relacin como resultado. Las operaciones
fundamentales en el lgebra relacional son seleccionar, proyectar, producto cartesiano, renombrar, unin y diferencia de
conjuntos. Adems, existen otras operaciones, interseccin de conjuntos, producto natural, divisin y asignacin, que se
definiran en trminos de las operaciones fundamentales.
3.2.1. Operaciones fundamentales.
19
Las operaciones seleccionar, proyectar y renombrar se llaman operaciones unitarias, ya que operan sobre una
relacin. Las otras tres operaciones operan sobre pares de relaciones y se llaman operaciones binarias.
3.2.1.1. La operacin seleccionar.
La operacin seleccionar selecciona tuplas que satisfacen un predicado dado. Usamos la letra griga minscula
sigma () para indicar la seleccin. El predicado aparece como subndice de . As, para selecconar aquellas tuplas de la
relacin prstamo en las que la sucursal es Perrydge, escribimos :
nombre_sucursal=Perrydge (prstamo)
En general, permitimos las comparaciones usando =, , <, , >, ., en el predicado de seleccin. Adems,
pueden combinarse varios predicados en un predicado ms complejo usando los conectores y () y o (). As :
nombre_sucursal=Perrydge cantidad>1200 (prstamo)
El predicado de seleccin puede incluir comparaciones entre dos atributos, como :
nombre_cliente=nombre_banquero (servicio)
3.2.1.2. La operacin proyectar.
La operacin proyectar es una operacin unitaria que devuelve su relacin argumento con ciertas columnas
omitidas. Puesto que una relacin es un conjunto, se eliminan todas las filas duplicadas. La proyeccin se indica con la
letra griega pi (). Listamos los atributos que queremos que aparezcan en el resultado como subndices de . La relacin
argumento se escribe a continuacin de entre parntesis. As :
nombre_sucursal, nombre_cliente (prstamo)
mostrar solo los atributos nombre_sucursal y nombre_cliente.
En vez de dar una relacin como argumento podemos dar el resultado de otra operacin, como
nombre_cliente ( nombre_cliente=nombre_banquero (servicio))
3.2.1.3. La operacin producto cartesiano.
Las operaciones que hemos tratado hasta ahora nos permiten extraer informacin nicamente de una relacin
cada vez. La operacin producto cartesiano, representada por una cruz (x) es una operacin binaria. Describimos el
producto cartesiano de las relaciones r1 y r2 como r1 x r2. Recurdese que una relacin se define como un subconjunto de
un producto cartesiano de un conjunto de dominios. Sin embargo, nos enfrentamos al problema de elegir los nombres
de los atributos para la relacin que resulta de un producto cartesiano.
Supngase que queremos encontrar a todos los clientes del banquero Johnson, as como las ciudades en las
que viven. El esquema de relaciones para r es :
(servicio.nombre_cliente, servicio.nombre_banquero, cliente.nombre_cliente, cliente.calle, cliente.ciudad_cliente)
Es decir, simplemente listamos todos los atributos de las dos relaciones, y adjuntamos el nombre de la
relacin de la que procede el atributo. Necesitamos adjuntar el nombre de la relacin para distinguir entre
servicio.nombre_cliente y cliente.nombre_cliente. Para aquellos atributos que solo aparecen en uno de los dos esquemas
omitiremos el prefijo nombre_relacin, lo que no producir ninguna ambigedad :
(servicio.nombre_cliente, nombre_banquero, cliente.nombre_cliente, calle, ciudad_cliente)
Ahora que ya conocemos el esquema de relaciones para r=servicio x cliente, qu tuplas aparecen en r?.
Construiremos una tupla de r por cada par posible de tuplas : una de la relacin servicio y otra de cliente.
Supngase que tenemos n1 tuplas en servicio y n2 tuplas en cliente. Entonces existen n1n2 formas de elegir un
par de tuplas, de forma que hay n1n2 tuplas en r. Obsrvese que puede darse el caso para algunas tuplas t en r que
t[servicio.nombre_cliente] t[cliente.nombre_cliente].
En general, si tenemos las relaciones r1(R1) y r2(R2), entonces r1xr2 es una relacin cuyo esquema es la
concatenacin de R1 y R2. La relacin R contiene todas las tuplas t para las cuales existe una tupla t1 en r1 y t2 en r2 para las
que t[R1]=t1[R1] y t[R2]=t2[R2].
Volviendo a la pregunta, (clientes de Johnson y sus ciudades), considerando r=servicioxcliente, tenemos
nombre_banquero=Johnson (servicioxcliente)
Puesto que la operacin producto cartesiano asocia todas las tuplas de cliente con todas las tuplas de servicio,
sabemos que alguna tupla en servicioxcliente tiene la direccin del cliente del banquero. Esto ocurre en aquellos casos en
los que sucede que servicio.nombre_cliente=cliente.nombre_cliente, as que escribimos :
servicio.nombre_cliente=cliente.nombre_cliente ( nombre_banquero=Johnson (servicioxcliente))
Finalmente, puesto que solo queremos el nombre y la ciudad del cliente debemos realizar una proyeccin :
servicio.nombre_cliente, ciudad_cliente( servicio.nombre_cliente=cliente.nombre_cliente ( nombre_banquero=Johnson (servicioxcliente)))
3.2.1.4. La operacin renombrar.
Introdujimos el convenio de nombrar atributos nombre_relacin.nombre_atributo para eliminar
ambigedades. Otra forma de ambigedad potencial surge cuando la misma relacin aparece ms de una vez en una
pregunta.
Bases de Datos
20
Considrese encontrar los nombres de todos los clientes que viven en la misma calle y ciudad que Smith.
Podemos encontrar la calle y la ciudad de Smith escribiendo :
calle, ciudad_cliente( nombre_cliente=Smith (cliente))
Sin embargo, para encontrar otros clientes con esa calle y esa ciudad debemos hacer referencia una segunda vez a
la relacin cliente
P(cliente) x calle, ciudad_cliente( nombre_cliente=Smith (cliente))
donde P es un predicado de seleccin que requiere que los valores de calle y ciudad_cliente sean iguales. Para especificar a
qu valor de calle nos referimos, no podemos usar cliente.calle, ya que ambos valores de calle se toman de la misma
relacin cliente, y lo mismo pasa con ciudad_cliente. Este problema se resuelve usando el operando renombrar,
representado por . La expresin
x(r)
devuelve la relacin r con el nombre x. Usaremos sta para renombrar una referencia a la relacin cliente, y as hacer
referencia a la relacin dos veces sin ambigedad.
cliente.nombre_cliente(cliente2.calle=cliente.calle cliente2.ciudad_cliente=cliente.ciudad_cliente (cliente x (calle,ciudad_cliente
(nombre_cliente=Smith(cliente2(cliente))))))
3.2.1.5. La operacin unin.
Consideremos ahora una consulta que podra plantearse el departamento de publicidad de un banco:
encontrar a todos los clientes de una sucursal, es decir, los que tienen una cuenta, un prstamo o ambos.
Sabemos encontrar a todos los clientes con un prstamo y a los de una cuenta. Para contestar la consulta,
necesitamos la unin de estos dos conjuntos. Esto se logra mediante la operacin binaria unin () ,y ser:
nombre_cliente (nombre_sucursal=Nombre (prstamo) nombre_cliente (nombre_sucursal=nombre(depsito))
En nuestro ejemplo tomamos la unin de dos conjuntos, ambos formados por valores de nombre_cliente.
En general debemos asegurarnos de que las uniones se toman entre relaciones compatibles. Por tanto, para que una
operacin de unin rs sea vlida exigimos que se cumplan dos condiciones:
1.- Las relaciones r y s deben tener el mismo nmero de atributos.
2.- Los dominios del atributo isimo de r y del atributo isimo de s deben ser los mismos.
3.2.1.6. La operacin diferencia de conjuntos.
La operacin diferencia de conjuntos (-) nos permite encontrar tuplas que estn en una relacin pero no en otra.
La expresin r-s da como resultado una relacin que contiene aquellas tuplas que estn en r pero no en s.
Podemos encontrar a todos los clientes de una sucursal que tiene cuenta all, pero no un prstamo:
nombre_cliente (nombre_sucursal=Nombre (depsito) - nombre_cliente (nombre_sucursal=nombre(prstamo))
Considrese la consulta encontrar el saldo de cuenta mayor en el banco. Nuestra estrategia para hacer esto es
calcular primero una estrategia temporal que conste de aquellos saldos que no son los ms grandes, y entonces tomar la
diferencia de conjuntos entre la relacin depsito y la relacin temporal que acaba de ser calculada para obtener el
resultado. La relacin temporal se calcula por medio de:
saldo.depsito (saldo.depsito<d.saldo (depsito x d(depsito))
El resultado contiene todos los saldos excepto el mayor de todos los saldos menos el mayor de todos. La
consulta puede escribirse tomando la diferencia entre el conjunto de todos los saldos y la relacin temporal:
saldo (depsito) - saldo.depsito (saldo.depsito<d.saldo (depsito x d(depsito))
3.2.2. Definicin formal del lgebra relacional.
Una expresin bsica en el lgebra relacional consta de cualquiera de las siguientes: una relacin de la BD, y una
relacin constante.
Una expresin general en el lgebra relacional se construye a partir de subexpresiones. Sean E1 y E2 expresiones
del lgebra relacional. Entonces las siguientes son todas expresiones del lgebra relacional:
E1E2, E1-E2, E1xE2, P(E1), S(E1), X(E1)
3.2.3. Operaciones adicionales.
Las operaciones fundamentales del lgebra relacional son suficientes para expresar cualquier consulta en lgebra
relacional. Sin embargo, si nos restringimos slo a las operaciones fundamentales, algunas consultas comunes son largas
de expresar. Por tanto definimos operaciones adicionales que no aaden ninguna potencia al lgebra, pero que
simplifican consultas comunes.
3.2.3.1. La operacin interseccin de conjuntos.
21
La interseccin de conjuntos () comunes a dos relaciones, por ejemplo encontrar los clientes que tienen una
cuenta y un prstamo en una sucursal sera:
nombre_cliente (nombre_sucursal=Nombre (prstamo) nombre_cliente (nombre_sucursal=nombre(depsito))
Cualquier expresin del lgebra relacional que use la interseccin de conjuntos puede reescribirse sustituyendo la
operacin interseccin por un par de operaciones diferencia de conjuntos: rs = r-(r-s).
As, la interseccin de conjuntos no es una operacin fundamental y no aade potencia al lgebra.
3.2.3.2. La operacin producto natural.
Tpicamente, una consulta que implica un producto cartesiano incluye una operacin de seleccin en el
resultado del producto. Considrese la consulta encontrar a todos los clientes que tiene un prstamo y las ciudades en
las que viven. Primero formamos el producto cartesiano de las relaciones prstamo y cliente, despus seleccionamos
aquellas tuplas que presenten un nico nombre_cliente.
prstamo.nombre_cliente, ciudad_cliente (prestamo.nombre_cliente=cliente.nombre_cliente (prstamo x cliente))
El producto natural es una operacin binaria que nos permite combinar ciertas selecciones y un producto
cartesiano en una operacin. Se representa por el simbolo | x| . La operacin producto natural forma un producto
cartesiano de sus dos argumentos, realiza una seleccin formando la igualdad en aquellos atributos que aparezcan en
ambas relaciones y, finalmente quita las columnas duplicadas. As, la consulta anterior sera:
nombre_cliente, ciudad_cliente (prstamo | x| cliente)
Puesto que muchos esquemas de prstamo y cliente tiene el atributo nombre_cliente en comn, la operacin
producto natural considera slo pares de tuplas que tienen el mismo valor de nombre_cliente. Combina cada uno de
estos pares de tuplas en un nico par en la unin de los dos esquemas.
Ahora estamos preparados para la definicin formal del producto natural. Considrese dos esquemas de
relaciones R y S, que son listas de nombres de atributos. Si consideramos los esquemas como conjuntos mejor que
como listas, podemos representar aquellos atributos que estn en R y S por RS, y representar aquellos valores que
aparecen en R, en S o en ambas por RS. Ntese que nos referimos a conjuntos de atributos, no de relaciones.
Considrese las dos relaciones r(R ) y s(S). El producto natural de r y s, representado por r | x| s es una relacin
del esquema RS. Es la proyeccin sobre RS de una seleccin en r x s, donde el predicado de seleccin requiere que
r.A=s.A para cada atributo A en RS. Formalmente:
r | x| s= RS (r.A1=s.A1 r.A2=s.A2 r.An=s.An r x s)
Como propiedad, dgase que el producto natural es asociativo, y adems, sean r(R ) y s(S) relaciones sin ningn
atributo en comn, es decir RS=. Entonces r | x| s = r x s.
Puesto que el producto natural es muy importante, damos varios ejemplos de su uso:
1.- Encontrar el activo y el nombre de todas las sucursales que tienen depositantes que viven en Stanford.
nombre_sucursal, activo (ciudad_cliente=Stanford (cliente | x| depsito | x| sucursal))
2.- Encontrar a todos los clientes que tienen una cuenta y un prstamo en la sucursal Perrydge.
nombre_cliente (nombre_sucursal=Perrydge (prstamo | x| depsito))
3.2.3.3. La operacin divisin.
La operacin divisin () se establece para aquellas consultas que incluyen la frase para todos2. Supngase que
queremos encontrar a todos los clientes que tienen una cuenta en todas las sucursales que estn en Brooklyn. Podemos
obtener todas las sucursales en Brooklyn mediante:
r1 = nombre_sucursal (ciudad_sucursal=Brooklyn(depsito)
Podemos encontrar todos los pares nombre_cliente, nomre_sucursal para los cuales el cliente tiene una cuenta
en una sucursal escribiendo:
r2 = nombre_cliente, nombre_sucursal (depsito)
Ahora necesitamos encontrar los clientes que aparecen en r2 con cada nombre se sucursal en r1.La operacin que
proporciona exactamente esos clientes es la operacin de dividir. La consulta puede expresarse con:
nombre_cliente, nombre_sucursal (depsito) nombre_sucursal (ciudad_sucursal=Brooklyn(depsito)
Formalmente, sean r(R ) y s(S) relaciones, y SR. La relacion rs es una relacin de esquema R-S. Una tupla t
est en rs si para cada tupla ts es s existe una tupla tr en r que satisface estas dos condiciones:
ts [R] = tr[S]
ts [R-S] = t[R-S]
Definida en trminos de operaciones fundamentales, la operacin dividir resulta:
rs = R-S(r ) - R-S((R-S(r ) x s) - r)
3.2.3.4. La operacin asignacin.
A veces es conveniente escribir una expresin del lgebra relacional por partes usando la asignacin a una
variable de relacin temporal. La operacin asignacin (), funciona de forma parecida a la asignacin de los lenguajes de
programacin.
Bases de Datos
22
La evaluacin de una asignacin no da como resultado una relacin que se presenta al usuario, ms bien, el
resultado de la expresin a la derecha de es asignado a la variable de relacin de la parte izquierda. Esta variable de
relacin puede usarse en subsiguientes expresiones.
Con la operacin asignacin, una consulta puede escribirse como un programa secuencial que consta de una
serie de asignaciones seguidas de una expresin cuyo valor se presenta como el resultado de la consulta. En lgebra
relacional, la asignacin debe hacerse siempre a una variable de relacin temporal. Es importante observar que la
operacin de asignacin no proporciona potencia adicional al lgebra, es una forma conveniente de expresar consultas
complejas de forma ms sencilla.
3.3. El clculo relacional de tuplas.
Cuando escribimos una expresin en lgebra relacional, damos una secuencia de procedimientos que genera la
respuesta a nuestra consulta. El clculo relacional de tuplas, en cambio, es un lenguaje de consultas no procedimental.
Describe la informacin deseada sin dar un procedimiento especfico para obtener esa informacin.
Una consulta en el clculo relacional de tuplas se expresa como
{t| P(t)}
es decir, el conjunto de todas las tuplas t, tal que el predicado P es verdadero para t. Usamos t[A] para representar el valor
de la tupla t en el atributo A, y usamos tr para indicar que la tupla t est en la relacin r.
Encontrar el nombre_sucursal, nmero_prstamo, nombre_cliente y cantidad para prstamos mayores de
1200 dlares:
{t| tprstamo t[cantidad]>1200}
Supngase que queremos nicamente el atributo nombre_cliente. En el clculo relacional de tuplas necesitamos
escribir una expresin para una relacin sobre el esquema (nombre_cliente). Necesitamos aquellas tuplas en
(nombre_cliente) tales que exista una tupla en prstamo correspondiente a ese nombre_cliente con el atributo
cantidad>1200. Para expresar esto necesitamos la construccin existe ()de la lgica matemtica.
tr(Q(t))
que significa existe una tupla t en la relacin r tal que el predicado Q(t) es verdadero.
Usando esta notacin podemos escribir la consulta encontrar a todos los cliente con un prstamo superior a
1200 como
{t| sprstamo (t[nombre_cliente] = s[nombre_cliente] s[cantidad]>1200}
La expresin anterior se lee el conjunto de todas las tuplas t tal que existe una tupla s en la relacin prstamo
para la cual los valores de t y s para el atributo nombre_cliente son iguales y el valor de s para el atributo cantidad es
mayor de 1200 dlares.
La variable de tupla t se define slo en el atributo nombre_cliente, puesto que ste es el nico atributo para el
que se especifica una condicin para t. As, el resultado es una relacin sobre (nombre_cliente).
Considrese la consulta encontrar a todos los clientes que tienen un prstamo de la sucursal Perrydge y las
ciudades en las que viven. Esta consulta implica dos relaciones, por lo que requiere que tengamos dos clausulas existe
conectadas por un y ().
{t| sprstamo (t[nombre_cliente] = s[nombre_cliente] s[nombre_sucursal] = Perrydge ucliente
(u[nombre_cliente] = s[nombre_cliente] t[ciudad_cliente] = u[ciudad_cliente]))}
Este es el conjunto de todas las tuplas (nombre_cliente, ciudad_cliente) para las cuales nombre_cliente es un
receptor de prstamo en la sucursal Perrydge y ciudad_cliente es la ciudad de nombre_cliente. La variable de tupla s
asegura que el cliente tiene un prstamo en la sucursal Perrydge, y u tiene la restriccin que debe pertenecer al mismo
cliente que s, y u asegura que ciudad_cliente es la ciudad del cliente.
Ahora considrese la consulta encontrar a todos los clientes que tienen una cuenta en Perrydge pero no un
prstamo en ella.
{t| udepsito (t[nombre_cliente] = u[nombre_cliente] u[nombre_sucursal] = Perrydge
sprstamo (t[nombre_cliente] = s[nombre_cliente] s[nombre_sucursal] = Perrydge)}
Esta expresin usa la clusula udepsito () para exigir que el cliente tenga una cuenta en Perrydge y la
clusula sprstamo () para eliminar los que tengan tambin un prstamo.
La consulta que vamos a considerar a continuacin usa la implicacin (). La frmula PQ significa P
implica Q; es decir, si P es verdadera, Q debe ser verdadera, y es equivalente lgicamente a PQ. El uso de la
implicacin a menudo sugiere una interpretacin ms intuitiva de una consulta.
Considrese la consulta encontrar a todos los clientes que tienen una cuenta en todas las sucursales de
Brooklyn. Para esta consulta introducimos la construccin para todos, representada por . La notacin
tr(Q(t))
significa Q es verdadera para todas las tuplas t en la relacin r. La consulta sera:
{t| usucursal (u[ciudad_sucursal]=Brooklyn sdepsito (t[nombre_cliente]=s[nombre_cliente]
u[nombre_sucursal]=s[nombre_sucursal]))}
23
Interpretamos la expresin como el conjunto de todos los clientes (t[nombre_cliente]) tal que para todas las
tuplas u en la relacin sucursal, si el valor de u en el atributo ciudad_sucursal es Brooklyn entonces el cliente tiene una
cuenta en la sucursal cuyo nombre aparece en el atributo nombre_sucursal de u.
Ahora estamos preparados para la definicin formal. Una expresin del clculo relacional de tuplas es de la
forma: {t| P(t)}
donde P es una frmula. En una frmula pueden aparecer varias variables de tuplas. Se dice que una variable de tupla es
una variable libre a menos que este cuantificada por un o por un , que entonces se dice variable limite.
Una frmula en el clculo relacional de tuplas se compone de tomos. Un tomo tiene una de las siguientes
formas:
1.- sr, donde s es una variable de tupla y r es una relacin. No se permite la operacin .
2.- s[x]u[y], donde s y u son variables de tuplas, x e y son atributos sobre los que estn definidos s y u
respectivamente, y es un operador de comparacin (<, , =, , >). Se requiere que los atributos x e y tengan dominios
cuyos miembros puedan compararse por medio de .
3.- s[x] c, donde s es una variable de tupla, x es una atributo sobre el que s esta definida, es un operador de
comparacin, y c es una constante en el dominio del atributo x.
Las frmulas se construyen a partir de tomos usando las siguientes reglas:
1.- Un tomo es una frmula.
2.- Si P1 es una frmula, entonces tambin lo son P1 y (P1).
3.- Si P1 y P2 son frmulas, entonces tambin lo son P1P2, P1P2 y P1P2.
4.- Si P1(s) es una frmula que contiene una variable de tupla libre, entonces sr(P1(s)) y sr(P1(s)) tambin
lo son.
Como en el lgebra relacional, es posible escribir expresiones equivalentes que en apariencia no son idnticas,
como estas tres:
1.- P1P2 es equivalente a (P1P2).
2.- tr(P1(t)) es equivalente a tr(P1(t)).
3.- P1P2 es equivalente a P1P2
3.3.3. Seguridad de expresiones.
Una relacin en el lgebra relacional de tuplas puede generar una relacin infinita. Supngase:
{t| (tprstamo)}
Existe un nmero infinito de tuplas que no estn en prstamo. La mayora contienen valores que ni siquiera
estn en la BD, por lo que no queremos permitir estas expresiones.
Para ayudarnos a definir una restriccin introducimos el concepto de dominio de una frmula relacioanl de
tuplas, P. El dominio de P, representado dom(P) es el conjunto de todos los valores referenciados por P. as, como el
conjunto de todos los valores que aparecen en una o ms relaciones cuyos nombres aparecen en P. Por ejemplo,
dom(tprstamo t[cantidad]>1200) es el conjunto de todos los valores que aparecen en prstamo mayores que 1200,
y dom((tprstamo)) es el conjunto de todos los valores que no aparecen en prstamo.
Decimos que una expresin {t| P(t)} es segura si todos los valores que aparecen en el resultado son valores de
dom(P).
El clculo relacional de tuplas restringido es equivalente en poder expresivo al lgebra relacional. Esto quiere
decir que para cada expresin en el lgebra relacional existe una relacin equivalente en el lgebra relacional de tuplas.
3.4. El clculo relacional de dominios.
Existe una segunda forma de clculo relacional llamada clculo relacional de dominios. Esta forma usa variables
de dominio que toman valores del dominio de un atributo ms que valores de una tupla completa, y esta intimamente
relacionado con el clculo relacional de tuplas.
Una expresin en el clculo relacional de dominios es de la forma {<x1, x2, , xn>| P(x1, x2, , xn)}, donde x1,
x2, , xn reprsentan variables de dominio. P representa una frmula compuesta por tomos, siendo un tomo una
expresin con una de estas formas:
1.- <x1, x2, , xn>r, donde r es una relacin de n atributos, y x1, x2, , xn son variables de dominio o
constantes de dominio.
Bases de Datos
24
2.- xy, donde x e y son variables de dominio, y es un operador de comparacin (<, , =, , >). Es requisito
de los atributos x e y tengan dominios que puedan compararse.
3.- xc, donde x es una variable de dominio, es un operador de comparacin, y c es una constante en el
dominio del atributo para el cual x es una variable de dominio.
Las frmulas se construyen a partir de tomos usando las siguientes reglas:
1.- Un tomo es una frmula.
2.- Si P1 es una frmula, entonces tambin lo son P1 y (P1).
3.- Si P1 y P2 son frmulas, entonces tambin lo son P1P2, P1P2 y P1P2.
4.- Si P1(x) es una frmula en x, donde x es una variable de dominio, entonces x(P1(x)) y x(P1(x)) tambin
son frmulas.
Para abreviar la notacin escribimos a,b,c(P(a,b,c)) en lugar de a(b(c(P(a,b,c))))
Ahora damos consultas en el clculo relacional de dominios para los ejemplos ya considerados. Obsrvese el
parecido con las correspondientes del clculo relacional de tuplas.
1.- Encontrar nombre_sucursal, nmero_prstamo, nombre_cliente y cantidad de prstamos > 1200.
{<b,l,c,a>| <b,l,c,a>prstamo a>1200}
2.- Encontrar a todos los clientes que tienen un prstamo en Perrydge y las ciudades en que viven.
{<c,x>| b,l,a(<b,l,c,a>prstamo b=Perrydge y(<c,y,x>cliente))}
3.- Encontrar a todos los clientes que tienen una cuenta en todas las sucursales de Brooklyn.
{<c>| x,y,z(<x,y,z>sucursal zBrooklyn (a,n(<x,a,c,n>depsito)))}
Interpretamos esta expresin como el conjunto de todas las tuplas nombre_cliente <c> tal que para todas las
tuplas (nombre_sucursal, activo, ciudad_sucursal) <x,y,z>, al menos una de las siguientes declaraciones es verdadera.
<x,y,z> no es una tupla de la relacin sucursal, y por tanto no corresponde a una sucursal de Brooklyn.
z no tiene el valor Brooklyn.
El cliente c tiene una cuenta (con nmero de cuenta a y saldo n)en la sucursal x.
3.4.3. Seguridad de las expresiones.
Una expresin como {<b,c,l,a>| (<b,c,l,a>prstamo)} no es segura porque permite valores en el resultado
que no estn en el dominio de la expresin.
Para el clculo relacional de dominios debemos preocuparnos tambin por la forma de las frmulas dentro de
las clasulas existe y para todos.
En el clculo relacional de tuplas restringimos cualquier variable cuantificada existencialmente a moverse sobre
una relacin especfica. Ahora aadimos reglas a la definicin de seguridad para tratar con casos como el ejemplo anterior.
Decimos que una expresin
{<x1, x2, , xn>| P(x1, x2, , xn)}
es segura si se cumplen todas las condiciones siguientes:
1.- Todos los valores que aparecen en tuplas de la expresin son valores de dom(P).
2.- Para cada subfrmula existe de la forma x(P1(x)), la subfrmula es verdadera si, y slo si, existe un valor
x de dom(P1) tal que P1(x) es verdadero.
3.- Para cada subfrmula para todos de la forma x(P1(x)), la subfrmula es verdadera si, y slo si, P1(x) es
verdadero para todos los valores de x de dom(P1).
El propsito de estas reglas adicionales es asegurar que podemos probar las subfrmulas para todos y
existe sin tener que probar infinitas posibilidades.
Como el clculo relacional de dominios se restringe a expresiones seguras, es equivalente al clculo relacional de
tuplas restringido a expresiones seguras, por lo que es equivalente al lgebra relacional.
3.5. Modificacin de la base de datos.
Las modificaciones de la BD se expresan usando el operador asignacin. Las asignaciones se hacen a relaciones
ya existentes en la BD.
3.5.1. Eliminacin.
Una solicitud de eliminacin se expresa muy parecida a una consulta. Sin embargo, en vez de presentar tuplas al
usuario, quitamos las tuplas seleccionadas de la BD. Slo podemos eliminar tuplas completas, no nicamente valores de
determinados atributos. En lgebra relacional, una eliminacin se expresa:
r r - E
donde r es una relacin y E es una consulta del lgebra relacional. Ejemplo, eliminar todas las cuentas de Smith:
25
depsito deposito - nombre_cliente=Smith (depsito)
3.5.2. Insercin.
Para insertar datos en una relacin, bien especificamos la tupla que se va a insertar o escribimos una consulta
cuyo resultado sea un conjunto de tuplas que se va a insertar. En este ltimo caso, los valores de los atributos para las
tuplas insertadas deben ser miembros del dominio de los atributos, y las tuplas insertadas deben ser del mismo orden.
En lgebra relacional una insercin se representa:
r r E
La insercin de una sola tupla se expresa haciendo que E sea una relacin constante que contiene una tupla.
Supngase que queremos insertar el hecho de que Smith tiene 1200 dlares en la cuenta 9732 de Perrydge.
depsito depsito {(Perryde, 9732, Smith, 1200)}
Podramos querer insertar tuplas basadas en el resultado de una consulta. Supngase que queremos
proporcionar a todos los clientes con prstamos en Perrydge una cuenta de ahorros de 200 dlares. EL nmero de
prstamo servir como nmero de cuenta.
r1 (nombre_sucursal=Perrydge (prstamo))
r2 nombre_sucursal,nmero_prstamo, nombre_cliente (r1)
depsito depsito (r2 x {(200)})
3.5.3. Actualizacin.
En ciertas ocasiones podemos querer cambiar un valor en una tupla sin cambiar todos los valores de la tupla.
Para ello usamos el operador actualizacin que tiene la forma:
A
E (r )
donde r es una relacin con atributo A al cual se le asigna el valor de la expresin E. La expresin E es cualquier
expresin aritmtica que implica constantes y atributos de planificacin de relacin r. Sopngase que estamos pagando el
5% de inters a todas las cuentas:
saldo
saldo * 1,05(depsito)
La sentencia anterior se aplica una vez a cada tulpa de depsito. Pero ahora supngamos que queremos dar el
6% a cuentas de ms de 10000 dlares y el 5% al resto:
saldo
saldo * 1,06 (saldo>10.000 (depsito)

saldo
saldo * 1,05(saldo>10.000 (depsito)

Es importante el orden en que aplicamos las expresiones de actualizar. Si cambiamos el orden, una cuenta cuyo
saldo estuviera justo por debajo de 10000 recibira el 11,3% de inters.
3.6. Vistas.
En los ejemplos expuestos hemos operado en el nivel del modelo conceptual, es decir, hemos supuesto que la
coleccin de relaciones que se nos dan son las relaciones reales almacenadas en la BD.
No es conveniente que todos los usuarios vean el modelo conceptual completo. Las consideraciones de
seguridad pueden requerir que se escondan ciertos datos al usuario.
Cualquier relacin que no es parte del modelo conceptual, pero se hace visible al usuario como una relacin
virtual se llama vista.
Puesto que las relaciones reales en el modelo conceptual pueden modificarse, generalmente no es posible
almacenar una relacin correspondiente a una vista. Una vista debe volverse a calcular para cada consulta que se refiere a
ella.
Cuando se define una vista, el DBMS debe almacenar la definicin de la vista. As, la definicin de vista no es
una expresin del lgebra relacional. Ms bien, hace que se guarde una expresin que se va a sustituir en consultas
utilizando la vista.
3.6.1. Definicin de vista.
Una vista se define usando la sentencia create view de la forma
create view v as <expresin de consulta>
donde <expresin de consulta> es cualquier expresin legal de consulta en lgebra relacional. El nombre de la vista se
representa por v.
Considerse la vista que consta de sucursales y sus clientes:
create view todos_clientes as nombre_sucursal, nombre_cliente(depsito) nombre_sucursal, nombre_cliente (prstamo)
Una vez que se ha definido la vista, el nombre de la vista puede usarse para referirse a la relacin virtual que
genera la vista. Los nombres de vistas pueden aparecer en cualquier lugar que pueda aparecer el nombre de una relacin.
3.6.2. Actualizacin por medio de vistas y valores nulos.
Bases de Datos
26
Aunque las vistas son una herramienta til para las consultas, presentan valores importantes si las
actualizaciones, inserciones o eliminaciones se expresan usando vistas. La dificultad es que una modificacin de la BD
expresada en trminos de vistas debe traducirse en una modificacin de las relaciones reales en el modelo conceptual de la
BD.
Para ilustrar el problema considrese la vista info_prstamo, definida
create view info_prstamo as nombre_sucursal, nmero_prstamo, nombre_cliente(prstamo)
Puesto que permitimos que un nombre de vista aparezca en cualquier lugar, podramos escribir
info_prstamo info_prstamo {(Perrydge, 3, Ruth)}
Esta insercin debe estar representada por una insercin en la relacin prstamo, ya que prstamo es la relacin
real. Sin embargo, para insertar una tupla en prstamo, debemos tener algn valor para cantidad. Existen dos enfoques:
1.- Rechazar la insercin y devolver un mensaje de error al usuario.
2.- Insertar una tupla (Perrydge, 3, Ruth, null) en la relacin prstamo.
El simbolo null representa un valor_nulo o valor_en_lugar_de. Significa que el valor es desconocido o no
existe. Todas las comparaciones que implican null son falsas por definicin.
El problema general de la modificacin de BD por medio de vistas ha sido el tema de investigaciones
sustanciales.
Otro rea de inters relacionado con vistas es el modelo de relacin universal. En este modelo se da al usuario
una vista que consta de una relacin. Esta relacin es el producto natural de todas las relaciones en la BD relacional real.
La principal ventaja de este modelo es que los usuarios no necesitan preocuparse de recordar que atributos estn en la
relacin. As, la mayor parte de las consultas son ms fciles de formular en un DBMS de relacin universal que en uno
de relacin estndar.
Quedan cuestiones sin resolver referentes a modificaciones de BD de relacin universal y todava no se ha
llegado a un consenso acerca de cul es la mejor definicin del significado de ciertos tipos complejos de consultas de
relacin universal.
Tema 4. Lenguajes relacionales comerciales.
27
Tema 4.Lenguajes relacionales comerciales.
Los lenguajes formales descritos en el captulo 3 proporcionan una notacin concisa para representar consultas.
Sin embargo los sistemas comerciales de BD requieren un lenguaje de consulta ms amigable para el usuario.
Estudiaremos tres lenguajes comerciales: SQL, QBE y Quel, que representan una variedad de estilos. QBE est basado
en el clculo relacional de dominios; Quel en el clculo relacional de tuplas y SQL usa una combinacin del lgebra
relacional y del clculo relacional. Los tres han sido influyentes en sistemas de BD de investigacin y en sistemas
distribuidos comercialmente.
Aunque nos referimos a estos lenguajes como lenguajes de consulta, contienen muchas otras capacidades
adems de consultar la BD., como caractersticas para definir la estructura de la BD, para modificar los datos y para
especificar restricciones de seguridad.
No presentaremos una gua de usuario, sino sus construcciones y conceptos fundamentales.
4.1. SQL.
Existen numerosas versiones de SQL. La versin original fue desarrollada en el San Jos Research Laboratory
de IBM, y originalmente se llam Sequel. Fue implementado como parte del Sistema R en los primeros setenta. Ha
evolucionado hasta cambiar su nombre a SQL (Structured Query Language, Lenguaje de consulta estructurado). Ahora
numerosos productos soportan el SQL.
En 1986, el American National Standards Institute (ANSI) public un SQL estndar. IBM ha publicado su
propio estndar de SQL inmerso, el Systems Application Architecture Database Interface (SAA-SQL).
SQL se ha establecido claramente como el lenguaje de BD relacional estndar.
El lenguaje SQL tiene varias partes:
n Lenguaje de definicin de datos (DDL). El SQL-DDL proporciona rdenes para definir esquemas de
relacin, eliminar relaciones, crear ndices y modificar esquemas de relacin.
n Lenguaje de manipulacin de datos interactivo. El SQL-DML incluye un lenguaje de consultas basado en el
lgebra relacional y el clculo relacional de tuplas. Tambin incluye ordenes para insertar, eliminar y
modificar tuplas de la BD.
n Lenguaje de manipulacin de datos inmerso (DML). La forma inmersa de SQL est diseada para usar
dentro de los lenguajes de programacin de propsito general, como Cobol, Pascal, o C.
n Definicin de vista. El SQL-DDL incluye ordenes para definir vistas.
n Autorizacin. El SQL-DDL incluye rdenes para especificar derechos de acceso a relaciones y vistas.
n Integridad. El lenguaje Sequel original incluye rdenes para especificar restricciones de integridad complejas.
Versiones recientes de SQL proporcionan nicamente una forma limitada de comprobacin de integridad.
n Control de transacciones. SQL incluye rdenes para especificar el comienzo y final de las transacciones.
Varias implementaciones permiten el bloqueo explcito de los datos de control de concurrencia.
En esta seccin cubrimos solo el DDL bsico, el DML interactivo y las vistas.
La estructura bsica en una instruccin en SQL constra de tres clusulas: select, from y where.
n La clusula select corresponde a la operacin proyeccin del lgebra relacional. Se usa para listar los atributos
que se desean en el resultado de una consulta.
n La clusula from corresponde a la operacin de producto cartesiano del lgebra relacional. Lista las relaciones
que se van a examinar en la evaluacin de la expresin.
n La clusula where corresponde al predicado de seleccin del lgebra relacional. Consta de un predicado que
incluye atributos de las relaciones que aparecen en la clusula from.
Una consulta tpica en SQL tiene la forma
select A1, A2, , An
from r1, r2, , rm
where P
es equivalente a la expresin del lgebra relacional:
A1, A2, , An (P(r1 x r2 x x rm))
Si se omite la clusula where, el predicado P es verdadero. La lista de atributos puede sustituirse por un
asterisco (*) para seleccionar todos los atributos de todas las relaciones que aparecen en la clusula from.
SQL forma el producto cartesiano de las relaciones nombradas en from, realiza una seleccin del lgebra
relacional usando el predicado de la clusula where y despus proyecta el resultado a los atributos de la clusula select.
El resultado de una consulta en SQL es una relacin.
Ejemplo: select nombre_sucursal
from depsito
4.1.2. Operaciones de conjuntos y tuplas duplicadas.
Los lenguajes de consulta formales se basan en la nocin matemtica de relacin como un conjunto. Por ello
nunca aparecen tuplas duplicadas en las relaciones. En la prctica, la eliminacin de duplicados lleva bastante tiempo, por
Bases de Datos
28
lo que SQL permite duplicados en las relaciones. En aquellos casos en los que queremos forzar la eliminacin de
duplicados, insertamos la palabra clave distinct despus de select.
select distinct nombre_sucursal
from depsito
SQL permite el uso de la palabra all para especificar explcitamente que no se eliminen duplicados.
select all nombre_sucursal
from depsito
SQL incluye las operaciones union, intersect y minus que operan sobre relaciones y corresponden a las
operaciones del lgebra relacional , , -.
Para encontrar a todos los clientes que tienen que tienen un prstamo, una cuenta, o los dos en la sucursal
Perryridge escribimos:
(select nombre_cliente
from depsito
where nombre_sucursal = Perryridge)
union
from prstamo
Por omisin la operacin union elimina las tuplas duplicadas. Para retener duplicados se debe escribir union
all.
Aunque la operacin union es parte del SQL estndar de ANSI, varios productos no la soportan. Las
operaciones intersect y minus eran parte del Sequel, pero no estn incluidas en el estndar. Es posible expresar estas
operaciones utilizando otras caractersticas del SQL estndar de ANSI.
4.1.4. Predicados y conectores.
SQL no tiene una representacin directa del producto natural, sin embargo, puesto que el producto natural se
define en funcin de un producto cartesiano, una seleccin y una proyeccin, es relativamente sencillo escribir una
expresin en SQL para el producto natural.
Por ejemplo, encontrar el nombre y la ciudad de todos los clientes que tienen un prstamo en alguna sucursal:
select distinct cliente.nombre_cliente, ciudad_cliente
from prstamo, cliente
where prstamo.nombre_cliente = cliente.nombre_cliente
Obsrvese que SQL usa la notacin nombre_relacin.nombre_atributo, como el lgebra relacional, para evitar
ambigedad.
Ampliemos la consulta anterior, requiriendo tambin que todos los clientes tengan un prstamo en la sucursal
Perryridge. Para escribir esta consulta, necesitamos declarar los limites en la clusula where, conectados por el conector
lgico and.
select distinct cliente.nombre_cliente, ciudad_cliente
from prstamo, cliente
where prstamo.nombre_cliente = cliente.nombre_cliente and nombre_sucursal = Perryridge
SQL usa los conectores lgicos and or y not en vez de los smbolos matemticos , , . Muchas
implementaciones de SQL incluyen funciones aritmticas especiales para tipos de datos particulares, por ejemplo , IBM
SAA-SQL incluye numerosas funciones para el tipo de datos fecha.
SQL incluye un operador de comparacin between para simplificar clusulas where que especifican que un valor
sea menor o igual que un valor dado y mayor o igual que otro.
select nmero_cuenta select nmero_cuenta
from depsito from depsito
where saldo >= 9000 and saldo <= 10000 where saldo between 9000 and 10000
Anlogamente, podemos usar el operador de comparacin not between.
SQL tambin incluye un operador dde seleccin para comparaciones de cadenas de caracteres. Los modelos se
describen usando dos caracteres especiales:
n tanto por ciento (%). El carcter % es igual a cualquier subcadena.
n subrayado (_). El carcter _ es igual a cualquier carcter.
Los modelos son sensibles al tipo de letra, es decir, los caracteres en mayscula no son iguales a los caracteres en
minscula. Para mostrar la igualdad, consideremos los ejemplos:
Perry% es igual a cualquier subcadena que empiece por Perry
%idge% es igual a cualquier cadena que contenga idge
_ _ _ es igual a cualquier cadena de tres caracteres
_ _ _ % es igual a cualquier subcadena de al menos tres carcteres
Los modelos se expresan en SQL usando el operador de comparacin like. Considrese la consulta encontrar
los nombres de todos los clientes cuya calle incluya la cadena Main :
select nombre_cliente
29
from cliente
where calle like %Main%
Para que los modelos incluyan caracteres de modelos especiales (% y _), SQL permite la especificacin de un
carcter de escape carcter. El carcter de escape se usa inmediatamente antes de un carcter de modelo especial para indicar
que el carcter de modelo especial se va a tratar como un carcter normal. Definimos el carcter de escape para una
comparacin like usando la palabra clave escape. Considrense los ejemplos con el carcter \ como carcter de escape:
like ab\ %cd% escape \ es igual a todas las cadenas que empiezan por ab%cd
like ab\ \ cd% escape \ es igual a todas las cadenas que empiezan por ab\ cd.
SQL permite buscar desigualdades en vez de igualdades usando el operador de comparacin not like.
4.1.5. Pertenencia a un conjunto.
SQL se basa en el clculo relacional para operaciones que permiten probar la pertenencia de tuplas a una relacin.
El conector in prueba si se es miembro de un conjunto, donde el conjunto es una coleccin de valores producidos por
una clusula select. El conector not inprueba la no pertenencia.
Considrese encontrar a todos los clientes que tienen un prstamo y una cuenta en la sucursal Perryridge.
Empezamos encontrando a todos los clientes que tienen cuenta, con la subconsulta:
from depsito
Despus necesitamos encontrar los clientes con prstamos de Perryridge y que aparecen en la lista de clientes que
tienen cuenta que acabamos de conseguir. Hacemos esto incorporando la subconsulta en un select externo. La consulta
resultante es:
select nombre_cliente
from depsito
where nombre_sucursal = Perryridge and
nombre_cliente in (select nombre_cliente
from depsito
Este ejemplo muestra que es posible escribir la misma consulta de varias formas en SQL.
Hemos probado la pertenencia a una relacin de una atributo. Es posible probar la pertenencia a una relacin
arbitraria. SQL usa la notacin <v1, v2, , vn> para representar una tupla con n atributos que contiene los valores v1, v2,
, vn. Utilizando esta notacin, podemos encontrar a todos los clientes que tienen una cuenta y un prstamo en la
sucursal Perryridge.
select distinct nombre_cliente
from depsito
where nombre_sucursal = Perryridge and
<nombre_sucursal, nombre_cliente> in (select nombre_sucursal, nombre_cliente
from depsito)
SQL toma prestada la notacin de variables de tupla del clculo relacional de tuplas. Una variable de tupla en
SQL debe estar asociada con una relacin determinada. Las variables de tuplas se definen en la clusula from. Por
ejemplo, encontrar el nombre y la ciudad de todos los clientes que tienen un prstamo en alguna sucursal.
select distinct T.nombre_cliente, ciudad_cliente
from prstamo S, cliente T
where S.nombre_cliente = T.nombre_cliente
Ntese que una variable de tupla se define en la clusula from colocndola despus del nombre de la relacin
con que esta asociada, separada por uno o ms espacios.
En consultas que contienen subconsultas, se aplica una regla de mbito a las variables de tupla. En una
subconsulta, est permitido usar slo variables definidas en la misma subconsulta o en cualquier consulta que la
contenga. Si una variable de tupla est definida tanto localmente como globalmente en una consulta que la contiene, se
aplica la definicin local. Cuando escribimos nombre_relacin.nombre_atributo, el nombre de la relacin es una variable
de tupla definida implcitamente.
Las variables de tupla son muy tiles para comparar dos tuplas de la misma relacin. En tales casos el lgebra
relacional usa la operacin renombrar.
select distinct T.nombre_cliente
from depsito S, depsito T.
where S.nombre_cliente = Jones and
S.nombre_sucursal = T.nombre_sucursal
4.1.7. Comparacin de conjuntos.
Considrese la consulta Encontrar los nombres de todas las sucursales que tienen un activo mayor que alguna
sucursal de Brooklyn. SQL ofrece la frase mayor que algn y se representa por > some.
Bases de Datos
30
select nombre_sucursal
from sucursal
where activo > some
(select activo from sucursal
where ciudad_sucursal = Brooklyn)
La subconsulta interior genera el conjunto de todos los valores de los activos de las sucursales de Brooklyn. La
comparacin > some en la clusula where del select externo es verdadera si el valor activo de la tupla es mayor que al
menos un miembro del conjunto de los activos de las sucursales de Brooklyn.
SQL tambin permite las comparaciones >some, some, some, = some y some. La palabra clave any es
sinnimo de some en SQL.
Ahora modifiquemos la consulta. Encontremos los nombres de todas las sucursales que tienen un activo
mayor que todas las sucursales de Brooklyn. La construccin > all corresponde a la frase mayor que todos.
select nombre_sucursal
from sucursal
where activo > all
(select activo from sucursal
SQL permite las comparaciones < all, all, all, = all, all.
Puesto que un select genera un conjunto de tuplas, podemos querer comparar conjuntos para determinar si un
contiene todos los miembros de algn otro conjunto. Tales comparaciones se hacen en SQL usando las contrucciones
contains y not contains.
Considrese encontrar a todos los clientes que tienen una cuenta en todas las sucursales de Brooklyn. Para cada
cliente, necesitamos ver si el conjunto de todas las sucursales en las que el cliente tiene una cuenta contiene al conjunto de
todas las sucursales de Brooklyn.
select distinct S.nombre_cliente
from depsito S
where (select T.nombre_sucursal from depsito
where S.nombre_cliente = T.nombre_cliente)
contains
(select nombre_sucursal from sucursal
La contruccin contains fue introducida en el Sequel original, pero fue omitida en versiones posteriores y no
aparece en el ANSI estndar, probablemente por que es extremadamente caro.
4.1.8. Pruebas para relaciones vacas.
SQL incluye una caracterstica para probar si una subconsulta tiene alguna tupla en su resultado. La construccin
exists devuelve el valor true si la subconsulta del argumento no est vaca. Podemos encontrar a todos los clientes que
tienen una cuenta y un prstamo en la sucursal Perryridge escribiendo:
select nombre_cliente from cliente
where exists (select * from depsito
where depsito.nombre_cliente = cliente.nombre_cliente and
nombre_sucursal = Perryridge)
and exists (select * from prstamo
where prstamo.nombre_cliente = cliente.nombre_cliente and
nombre_sucursal = Perryridge)
La no existencia de tuplas en una subconsulta puede probarse usando la construccin no exists.
Considrese de nuevo encontrar a todos los clientes que tienen una cuenta en todas las sucursales de Brooklyn.
Usando la construccin minus, podemos escribir la consulta como:
select distinct Snombre_cliente from depsito S
where not exists ((select nombre_sucursal from sucursal
minus
(select T.nombre_sucursal from depsito T
where S.nombre_cliente = T.nombre_cliente))
La segunda subconsulta encuentra todas las sucursales en las que el cliente S.nombre_cliente tiene una cuneta.
As, el select externo toma a cada cliente y prueba si el conjunto de todas las sucursalessituadas en Brooklyn menos el
conjunto de todas las sucursales en las que el cliente tiene cuenta, est vaco.
4.1.9. Ordenacin de la presentacin de tuplas.
31
SQL ofrece al usuario cierto control sobre el orden en que se van a presentar las tuplas en una relacin. La
clusula order by hace que las tuplas del resultado salgan en un orden determinado. Para listar en orden alfabtico todos
los clientes escribiremos:
order by nombre_cliente
despus de la clusula where.
Por omisin, SQL muestra los elementos en orden ascendente. Para especificar el tipo de ordenacin, podemos
especificar desc para orden descendente y asc para el ascendente. Adems el orden puede realizarse sobre mltiples
atributos, si queremos listar la relacin prstamo completa en orden descendente de cantidad, y si varios prstamos
tienen la misma cantidad, los ordenamos en orden ascendente por nmero de prstamo con:
order by cantidad desc, nmero_prstamo asc
Puesto que ordenar tuplas es muy costoso, lo ms conveniente es hacerlo slo cuando sea necesario.
SQL ofrece la posibilidad de calcular funciones en grupos de tuplas usando la clusula group by, el atributo o
atributos dados en ella se usan para formar grupos. Las tupas con el mismo valor en todos los atributos en la clusula
group by se colocan en un grupo. SQL incluye funciones para calcular: promedio (avg), mnimo (min), mximo (max),
total (sum) y contar (count).
Las operaciones como avg se llaman funciones de agregacin porque operan sobre grupos de tuplas. El
resultado de una funcin de agregacin es un valor nico. Considrese encontrar el saldo promedio de las cuentas de
todas las sucursales.
select nombre_sucursal, avg (saldo)
from depsito
group by nombre_sucursal
La retencin de duplicados es importante al calcular un promedio.
Hay casos prcticos en los los duplicados deben eliminarse antes de calcular la funcin de agregacin. Si
queremos eliminar duplicados, usamos la palabra clave distinct en la expresin de agregados:
select *, count (distinct nombre_cliente)
A veces es til declarar una condicin que se aplica a los grupos ms que a las tuplas. Por ejemplo, podriamos
estar interesados en las sucursales en las que el saldo promedio de las cuentas es mayor que 1200$. Esta condicin se
aplica a cada grupo construido por group by. Para expresar una consulta de este tipo, usamos la clusula having, que se
aplica despus de la formacin de grupos, por lo que pueden utilizarse funciones de agregacin. Expresamos esta
consulta como:
select nombre_sucursal, avg (saldo)
from depsito
having avg (saldo) > 1200
Considrese encontrar las sucursales con el saldo promedio mayor. Las funciones de agregados no pueden
componerse en SQL, por lo que no se puede utilizar max(avg()). Por lo que tendremos que encontrar las sucursales
para las que el saldo promedio es mayor o igual que todos los saldos promedio.
select nombre_sucursal from depsito
having avg (saldo) all (select avg (saldo) from depsito
group by nombre_sucursal)
A veces deseamos tratar la relacin completa como un grupo nico. En tales casos no usamos la clusula group
by, por lo que la funcin de agregacin count se usa frecuentemente para contar el nmero de tuplas en una relacin. La
notacin para esto en SQL es count (*).
select count (*)
from r
Si en la misma consulta aparecen una clusula where y una clusula having, primero se aplica el predicado de la
where, las tuplas que lo satisfacen son colocadas en grupos por la clusula group by, y despus se aplica la having a cada
grupo. Los grupos que satisfacen el predicado de having son utilizados por la clusula select para generar las tuplas del
resultado. Si no hay clusula having, el conjunto completo de tuplas que satisfacen la clusula where se trata como un
grupo nico.
Por ejemplo, queremos encontrar el saldo promedio de todos los clientes con depsitos que viven en Harrison
y tiene por lo menos tres cuentas:
select avg (saldo) from depsito, cliente
where depsito.nombre_cliente = cliente.nombre_cliente and
ciudad_cliente = Harrison
group by depsito_nombre_cliente
having count (distinct nmero_cuenta) > 3
La versin estndar ANSI de SQL exige que se use count solamente como count (*) o count (distict ). Est
permitido usar distinct con max y min aunque el resultado no cambie. La palabra clave all puede usarse en vez de distinct
para especificar retencin de duplicados, pero puesto que all esta implcito no es necesario.
4.1.11. La potencialidad de SQL.
Bases de Datos
32
SQL es tan poderoso en expresividad como el lgebra relacional, incluye las operaciones fundamentales del
lgebra. En SQL el producto cartesiano se representa por from, la proyeccin con select, los predicados de seleccin en
where, y adems incluye la unin y la diferencia. As, pues, podemos codificar cualquier expresin del lgebra relacional en
SQL.
Observamos que minus e intersect no son parte del SQL estndar, pero es posible expresarlas por medio de in
y not in de SQL.
SQL ofrece una rica coleccin de caractersticas, que incluyen funciones de agregacin, ordenacin de tuplas y
otras capacidades no incluidas en los lenguajes formales de consulta. As, pues, SQL es estrictamente ms poderoso que
el lgebra relacional.
Muchas implementaciones de SQL permiten hacer consultas en SQL desde un programa escrito en un lenguaje
de programacin de propsito general como Pascal o C. Esta forma incorporada de SQL ampla an ms la capacidad del
programador para manipular la BD.
SQL no es tan potente como un lenguaje de programacin de propsito general.
Ahora mostraremos como aadir, eliminar o modificar informacin utilizando SQL.
n Eliminacin.
Una solicitud de eliminacin se expresa casi de la misma forma que una consulta. Podemos suprimir
solamente tuplas completas, y en SQL se expresan por medio de:
delete r where P
donde P representa un predicado y r representa una relacin. Las tuplas t de r para las que P(t) es cierto son eliminadas de
r.
Una orden delete opera sobre una sola relacin. El predicado de la clusula where puede ser tan complicado
como en una consulta, e incluso puede estar vaco, eliminando todas las tuplas de la relacin.
Algunos ejemplo de eliminacin son:
- Suprimir todos los prstamos.
delete cliente
- Suprimir todas las cuentas en las sucursales de Perryridge.
delete depsito
where nombre_sucursal in (select nombre_sucursal from sucursal
where ciudad_sucursal = Perryridge)
Si la solicitud delete contiene un select incorporado que hace referencia a la relacin de la que se van a suprimir
tuplas, nos enfrentamos a anomalas potenciales, por ejemplo, si que remos suprimir las cuentas con saldos inferiores a
la media, cada vez que suprimimos tuplas el promedio cambia. El SQL estndar trata esto simplemente no permitiendo
solicitudas de supresin de este tipo.
n Insercin.
Para insertar datos en una relacin, especificamos una tupla que se va a insertar o escribimos una consulta cuyo
resultado es un conjunto de tuplas que se van a insertar. Las tuplas a insertar deben tener el nmero exacto de atributos,
y los valores de atributos para las tuplas insertadas deben ser miembros del dominio de los atributos.
La sentencia insert ms sencilla es una solicitud para insertar una tupla.
insert into depsito
valuse (Perryridge, 9732, Smith, 1200)
Si no se recuerda el orden de los atributos, SQL permite especificar los atributos como parte de la sentencia
insert.
insert into depsito (nombre_sucursal, nmero_cuenta, nombre_cliente, saldo)
valuse (Perryridge, 9732, Smith, 1200)
Podramos querer insertar tuplas basadas en el resultado de una consulta. Supngase que queremos
proporcionar a todos los clientes con prstamos en Perryrige una cuenta de 200$. El nmero de prstamo sirve como
nmero de cuenta.
insert into depsito
select nombre_sucursal, nmero_prstamo, nombre_cliente, 200
from prstamo
where nombre_sucursal = Perryridge
Usamos un select para especificar un conjunto de tuplas. Cada tupla tiene el nombre_sucursal, un
nmero_prstamo, el nombre_cliente y el saldo inicial de 200$.
El SQL estndar prohibe el select inmerso que haga referencia a la relacin en la que las tuplas van a ser
insertadas, ya que podran insertarse infinitas tuplas, dependiendo de la consulta.
n Actualizaciones
33
En ciertas situaciones podemos desear cambiar un valor en una tupla sin cambiar todos los valores en la tupla.
Para ste propsito puede usarse la sentencia update, y tambin podemos elegir las tuplas que se van a actualizar por
medio de una consulta.
Supngase que queremos pagar el 5% de inters a todas las cuentas:
update depsito
set saldo = saldo * 1,05
Supngase ahora que queremos pagar el 6% de inters a las cuentas con ms de 10000$:
update depsito
set saldo = saldo * 1,06
where saldo > 10000
La clusula where de la sentencia update puede contener cualquier construccin legal, incluyendo selects
anidados. Adems como en insert y delete, cualquier select incorporado en la clusula where de un update no debe hacer
referencia a la relacin que se est actualizando.
Es posible que para las tuplas insertadas se den valores nicamente en algunos atributos del esquema. El resto
de los atributos son asignados a valores nulos representados por null.
insert into depsito
values (Perryridge, null, Smith, 1200)
Sabemos que Smith tiene una cuenta en Perryridge de 1200$, pero se desconoce el nmero de cuenta. Si
quisiramos encontrar los datos de una cierta cuenta, no se podra determinar si es esa o no, ya que todas las
comapraciones con null son falsas por definicin. Sin embargo, la palabra clave especial null puede usarse en un
predicado para probar si hay un valor nulo. As, para encontrar a todos los clientes que aparecen en prstamo con valores
nulos para cantidad, escribimos:
select distinct nombre_cliente
from depsito
where cantidad is null
El predicado is not null prueba la ausencia de un valor nulo.
La existencia de valores nulos complica el procesamiento de los operadores de agregacin. Supngase que
algunos valores de prstamo tienen un valor nulo en cantidad. Considrese:
select sum (cantidad)
from prstamo
Los valores que se van a sumar en la consulta anterior incluyen valores nulos, pero no es posible llevar a cabo la
adicin usando null, por tanto, necesitamos una regla especial para manejar funciones de agregacin cuando aparecen
valores nulos. Como resultado, todas las operaciones de agregacin, excepto count, ignoran tuplas con valores nulos en
los atributos de los argumentos. Es posible prohibir la insercin de valores nulos usando el lenguaje de definicin de
datos de SQL, que veremos en el 4.1.15.
4.1.14. Vistas.
Una vista se define en SQL usando la orden create view. Para definir una vista debemos darla un nombre y
declarar la consulta que calcula la vista. La forma de la orden create view es:
create view v as >expresin de consulta>
donde >expresin de consulta> es cualquier consulta permitida y v el nombre que le damos a la vista..
Como ejemplo, considrese la vista que consta de nombres de sucursales y de los nombres de los clientes,
llamada todos_clientes. Definimos esta vista por medio de:
create view todos_clientes as
(select nombre_sucursal, nombre_cliente from depsito)
union
(select nombre_sucursal, nombre_cliente from prstamo)
Los nombres de vistas pueden aparecer en cualquier sitio en que puede aparecer un nombre de relacin.
Usando la vista todos_clientes podemos encontrar a todos los clientes de la sucursal Perryridge.
select nombre_cliente from todos_clientes
where nombre_sucursal = Perryridge
La anomala en la actualizacin de vistas, que se estudio en el lgebra relacional, tambin existe en SQL.
Considrese la vista info_prstamo definida por
create view info_prstamo as
(select nombre_sucursal, nmero_prstamo, nombre_cliente from prstamo)
Puesto que SQL permite que un nombre de vista aparezca donde puede aparecer el de una relacin, podemos
escribir:
insert into info_prstamo
values (Perryridge, 3, Ruth)
Esta insercin est representada por una insercin en la relacin prstamo, ya que prstamo es la relacin real de
la cual se deriva la vista info_prstamo. Por tanto, debemos tener algn valor para cantidad. Este valor es un valor vaco,
as, el insert anterior resulta en la insercin de la tupla:
Bases de Datos
34
(Perryridge, 3, Ruth, null)
en la relacin prstamo.
Como resultado, muchos DBMS basados en SQL imponen la siguiente condicin a las modificaciones que se
permiten hacer a las relaciones a travs de vistas:
n Se permite una modificacin a travs de una vista solo si la vista en cuestin est definida en terminos de
una relacin de la BD relacional real, es decir, la BD del nivel conceptual.
4.1.15. Definicin de datos.
Hasta ahora hemos supuesto que se nos da un conjunto de relaciones. Pero el conjunto de relaciones en una
BD debe ser especificado al sistema por medio de un lenguaje de definicin de datos DDL.
El SQL-DDL permite la especificacin no solo de un conjunto de relaciones, sino tambin de informacin
sobre cada relacin, incluyendo: el esquema de cada relacin, el dominio de valores asociado a cada atributo, el conjunto
de indices que se va a mantener para cada relacin, la informacin de seguridad y autorizacin para cada relacin, los
limites de integridad y la estructura fsica de almacenamiento de cada relacin del disco.
Trataremos aqu la definicin del esquema, dejando el resto para ms adelante.
Una relacin en SQL se define usando la orden create table:
create table r (A1 D1, A2, D2, , An Dn)
donde r es el nombre de la relacin, cada Ai es el nombre de un atributo del esquema de relacin r, y Di es el tipo de
datos de los valores en el dominio del atributo correspondiente. La orden create table tambin incluye opciones para
especificar ciertas restricciones de integridad.
Una relacin recin creada est inicialmente vaca. La orden insert puede usarse para cargar datos en la relacin.
Para eliminar una relacin de una BD en SQL, usamos la orden drop table. La orden drop table elimina toda
la informacin sobre la relacin sacada de la BD. Elimina no slo todas las tuplas de la relacin, como hara delete, sino
tambin el esquema de r. Despus no se puede insertar ninguna tupla en r a menos que se vuelva a crear.
drop table r
La orden alter tablese usa para aadir atributos a una relacin existente. Atodas las tuplas en la relacin se les
asigna null como valor del nuevo atributo. La forma de la orden alter table es
alter table r add A D
donde r es el nombre de una relacin existente, A es el nombre del nuevo atributo y D su dominio.
La orden alter aparece en algunas versiones de SQL pero no en el ANSI SQL.
4.2. Query By Example (QBE).
Query-By-Example (QBE) es el nombre de un lenguaje de manipulacin de datos DML y del DBMS que lo
incluye. El DBMS QBE fue desarrollado en T.J. Watson Research Center de IBM a principios de los setenta. Est fuera
de uso, pero su DML es parte de Query Management Facility (QMF) de IBM. Estudiaremos slo el DML. Existen dos
caractersticas distintivas del QBE:
n A diferencia de la mayoria de los lenguajes de consulta, QBE tiene una sintaxis bidimensional (necesita dos
dimensiones para expresar una consulta), si bien existe una versin unidimensional.
n Las consultas en QBE se expresan por ejemplo. En vez de dar un procedimiento para obtener la
respuesta deseada, el usuario da un ejemplo de lo que desea. El sistema generaliza este ejemplo para calcular
la respuesta a la consulta.
Las consultas en QBE se expresan utilizando tablas de esqueletos. Estas tablas muestran el esquema de la
relacin. En vez de llenar la pantalla con todos los esqueletos, el usuario selecciona los esqueletos que necesita para una
consulta y los rellena con filas ejemplo . Una fila ejemplo esta formada por constantes y elementos ejemplo que son
en realidad variables de dominio. Para evitar confusin, en QBE las variables de dominio van precedidas de un carcter
de subrayado (_), como _x, y las constantes aparecen solas.
Un ejemplo de tabla esqueleto para la relacin prstamo es:
Prstamo Nombre_sucursa
l
Nmero_prestam
o
Nombre_cliente Cantidad
Para encontrar a todos los clientes que tienen una cuenta en la sucursal Perryridge sacamos el esqueleto para la
relacin depsito y lo rellenamos como sigue:
Depsito Nombre_sucursa
l
Nmero_cuenta Nombre_cliente Saldo
Perrydridge P._x
35
La consulta anterior hace que el sistema busque en depsito las tuplas que tengan el valor Perryridge en al
atributo nombre_sucursal. Para cada una de estas tuplas, el valor del atributo nombre_cliente se asigna a la variable x. El
valor de la variable x se presenta, ya que la orden P. aparece en la columna nombre_cliente al lado de la variable x.
QBE supone que una posicin en blanco en una fila contiene una variable nica. Como resultado, si una
variable no aparece ms de una vez en una consulta, puede omitirse, por ejemplo, en la consulta anterior podiamos
haber escrito P. en la columna nombre_cliente.
QBE realiza la eliminacin de duplicados automticamente, para evitarla hay que insertar la orden ALL.
despues de la orden P. (P.ALL.)
Para representar una relacin completa, podemos crear una sola fila que contenga P. en cada campo.
Alternativamente, podemos colocar una nica P. en la columna encabezada por el nombre de la relacin.
QBE permite consultas que implican comparaciones aritmticas:
l
Nmero_prestam
o
P. > 1200
Las comparaciones pueden implicar slo una expresin aritmtica en la parte derecha de la operacin de
comparacin (por ejemplo, >(_x + _y -20)). La expresin puede incluir variables y constantes. El espacio en la parte
izquierda de la operacin de comparacin debe estar en blanco. Las operaciones de comparacin que soporta QBE son
=, <, , >, y .
Restringir la parte derecha a una sola operacin aritmtica implica que no podemos comparar dos variables con
nombres distintos.
El propsito general de las variables en QBE es forzar a que los valores de determinadas tuplas tengan el
mismo valor en determinados atributos. Considrese encontrar a todos los clientes que tienen una cuenta tanyto en la
sucursal Perrydridge como en la sucursal Redwood.
l
Perryridge P._x
Redwood _x
El sistema encuentra dos tuplas distintas en depsito que coinciden en el atributo nombre_cliente, donde el
valor para el atributo nombre_sucursal es Perryridge, para una tupla y Renwood para la otra. Entonces se presenta el
valor del atributo nombre_cliente.
4.2.3. Consulta sobre varias relaciones.
QBE permite consultas que se extienden sobre varias relaciones diferentes. Las conexiones entre las diversas
relaciones se logran a travs de variables que fuerzan a determinadas tuplas a tener el mismo valor en determinados
atributos. Supngase que queremos encontrar el nombre y la ciudad de todos los clientes que tienen un prstamo de la
sucursal Perryridge.
l
Nmero_prestam
o
Perryridge _x
Cliente Nombre_cliente Calle Ciudad_cliente
P._x P._y
Cosideremos encontrar el nombre de todos los clientes que tienen una cuenta en la sucursal Perryridge pero que
no tienen un prstamo de esa sucursal. Las consultas que implican negacin en QBE se expresan colocando un signo
not () debajo del nombre de la relacin y al lado de una fila ejemplo.
l
Perryridge P._x
l
Nmero_prestam
o
PErryridge _x
El puede leerse como no existe. El hecho de colocar el debajo del nombre de la relacin en vez de
debajo del atributo es importante. El uso de un debajo de un nombre de atributo es equivalente a .
4.2.4. El cuadro de condiciones.
A veces resulta inconveniente o imposible expresar todos los limites de las variables de dominio dentro de las
tablas de esqueletos, ya que las comparaciones no pueden implicar dos variables distintas. Para superar esta dificultad,
QBE incluye una caracterstica de cuadro de condiciones que permite la expresin de dichos lmites. Supngase que
queremos encontrar a todos los clientes cuyo nombre no sea Jones que tengan cuentas en dos sucursales diferentes.
Queremos incluir una restriccin xjones en la consulta. Esto se hace imponiendo el cuadro de condiciones e
introduciendo el lmite x=Jones.
Condiciones
x=Jones
Bases de Datos
36
Para encontrar todos los nmeros de prstamo con cantidades entre 1300$ y 1500$ escribimos:
l
Nmero_prestam
o
P. _x
Condiciones
_x1300
_x1500
QBE tambin permite que aparezcan expresiones aritmticas complejas en un cuadro de condiciones, como
_y>2*_z, y tambin permite que aparezcan expresiones lgicas utilizando los operadores lgicos and y or, o los
simbolos & y | , como _x=(1300 and 1500).
QBE incluye un uso no convencional de la construccin or para permitir la comparacin con un conjunto de
valores constantes. Para encontrar todas las sucursales que estn situadas en Brooklyn o en Queens, escribimos:
Sucursal Nombre_sucursal Activo Ciudad_sucursal
P. _x
Condiciones
_x=(Brooklyn or Queens)
4.2.5. La relacin resultado.
Si el resultado de una consulta incluye atributos de ms de una relacin, necesitamos un mecanismo para
representar el resultado deseado en una sola tabla. Para realizar esto, declaramos una relacin resultado temporal que
incluye todos los atributos del resultado de la consulta. La impresin del resultado deseado se hace incluyendo la orden
P. solamente en la tabla esqueleto de resultado.
Considrese lencontrar nombre_cliente, ciudad_cliente y nmero_cuenta para todos los clientes que tienen una
cuenta en la sucursal Perryridge. Para realizar esto en QBE hacemos:
n Creamos una tabla esqueleto, llamada resultado, con atributos nombre_cliente, ciudad_cliente y
nmero_cuenta. El nombre de la tabla esqueleto recin creada debe ser diferente de cualquiera de los
nombres de relacin de la BD que existan anteriormente.
n Escribimos la consulta:
l
Perryridge _z _x
_x _y
La consulta resultante es:
Resultado Nombre_cliente Ciudad_client
e
Nmero_cuenta
P. _x _y _z
4.2.6. Ordenacin de la presentacin de las tuplas.
QBE ofrece al usuario un cierto control sobre el orden en el que se presentan las tuplas en una relacin. Esto
puede realizarse la orden AO. (orden ascendente) o bien DO. (orden descendente) en la columna apropiada.
QBE proporciona un mecanismo para clasificar y presentar datos en mltiples columnas. El orden en el que
debe llevarse a cabo la clasificacin s eespecifica incluyendo con cada operador de clasificacin un entero entre parntesis.
P.AO(1). P.DO(2).
4.2.7. Operaciones de agregacin.
QBE incluye los operadores de agragados AVG, MAX, MIN, SUM y CNT. Estos operadores deben ser
postfijos con ALL. Para asegurar que todos los valores apropiados son considerados, por ejemplo P.SUM.ALL.
Supngase que queremos eliminar los duplicados cuando se usa un operador de agregacin. Puesto que todos
los operadores de agregados deben ser postfijos con ALL, debe aadirse un nuevo operador, UNQ, para especificar que
queremos los duplicados eliminados, como en P.CNT.UNQ.ALL.
QBE tambin ofrece la posibilidad de calcular funciones en grupos de tuplas usando el operador G., que es
anlogo a la construccin group by de SQL. As, para encontrar el saldo promedio en todas las sucursales podemos
escribir:
l
P.AO.G. P.AVG.ALL._x
37
La cuenta se puede usar para comprobar informacin negativa. Para encontrar a todos los clientes que tienen
una cuenta en la sucursal Perryridge, pero para quienes no hay direccin en el fichero, escribimos:
l
Perryridge _x
CNT.ALL._x
Condiciones
CNT.ALL._x=0
El enfoque es contar el nmero de tuplas de cliente pertenecientes a cada cliente con depsito en Perryridge. Si
para un cliente la cuenta es 0, sabemos que para ese cliente la direccin no est disponible.
Considrese encontrar a todos los clientes que tienen una cuenta en todas las sucursales situadas en Brooklyn.
l
CNT.UNQ.ALL_
y
P.G._x
_y Brooklyn
_z Brooklyn
Condiciones
CNT.UNQ.ALL._y=CNT.UNQ.ALL._z
La variable de dominio z puede contener el valor de nombres de sucursales situadas en Brooklyn. As,
CNT.UNQ.ALL._z es el nmero de sucursales distintas en Brooklyn. La variable de dominio y puede contener el valor
de sucursales que cumplen: estar situadas en Brooklyn y que el cliente cuyo nombre es x tiene una cuenta en la sucursal.
As, CNT.UNQ.ALL._y es el nmero de sucursales distintas en Brooklyn en las que el cliente x tiene una cuenta. Si
CNT.UNQ.ALL._y=CNT.UNQ.ALL._z, entonces el cliente x debe tener una cuenta en todas las sucursales de
Brooklyn.
En esta seccin mostramos como aadir, suprimir o cambiar informacin usando QBE.
n Supresin.
La supresin de tuplas de una relacin se expresa casi de la misma forma que una consulta. La principal
diferencia es el empleo de D. en lugar de P. En QBE podemos eliminar tuplas completas as como valores en columnas
seleccionadas. En el caso en que eliminamos informacin solamente en algunas de las columnas, se insertan valores
nulos representados por -.
Una orden D. opera nicamente sobre una relacin. Si queremos eliminar tuplas de distintas relaciones,
debemos usar un operador D. para cada relacin.
Algunos ejemplos son:
Eliminar el valor de ciudad_sucursal de la sucursal Perryridge:
Perryridge D.
Eliminar las cuentas con nmeros de cuenta entre 1300 y 1500:
l
D. _x
Condiciones
_x=(1300 and 1500)
n Insercin.
Para insertar datos en una relacin, podemos especificar una tupla que se va a insertar o escribir una consulta
cuyo resultado sea un conjunto de tuplas que se va a insertar. La insercin se hace colocando el operador I. en la
expresin de la consulta.
La insercin ms sencilla es una solicitud de insertar una tupla:
l
I. Peryridge 9732 Smith 1200
Tambin podemos insertar una tupla que contiene solamente informacin parcial.
De forma ms general podramos querer insertar tuplas basadas en el resultado de una consulta. Consideremos
de nuevo la situacin en la queremos dar a todos los clientes de prstamos de Perryridge una cuenta de 200$, siendo el
nmero de prstamo el nmero de cuenta. Escribimos:
Bases de Datos
38
l
I. Perryridge _x _y 200
l
Nmero_prstam
o
Perryridge _x _y
n Actualizaciones
Existen situaciones en las que se desea cambiar un valor en una tupla sin cambiar todos los valores en la tupla.
Para este propsito utilizamos el operador U.. Podemos elegir las tuplas que se van a actualizar usando una consulta.
QBE, sin embargo, no permite que los usuarios actualicen los campos de claves primarias.
Supngase que actualizamos el activo de Perryridge a 10.000.000$:
Perryridge U.10000000
El campo en blanco del atributo ciudad_sucursal implica que no se necesita actualizacin de ese valor.
La consulta anterior actualiza el activo sin tener en cuenta el valor anterior. Hay circunstancias en las que
necesitamos actualizar un valor de campo usando el valor anterior del campo. Esto puede expresarse usando dos filas:
una especificando las tuplas antiguas que necesitan ser actualizadas y otra indicando las nuevas tuplas actualizadas que se
van a insertar en la BD.
Supngase que se estn haciendo pagos de intereses, al 5%. Escribimos:
l
Nmero_prstam
o
U. _x*1,05
_x
Esta consulta especifica que cada vez recuperamos una tupla de la relacin depsito, determinamos el saldo _x,
y actualizamos el saldo a _x*1,05.
4.3. QUEL.
Quel se introdujo como lenguaje de consulta para el DBMS Ingres, desarrollado en la Universidad de
California, Berkeley. Una versin comercial de Ingres fue desarrollada por Relational Technology Inc.. El sistema Ingres
acadmico ofreci solo el lenguaje Quel, mientras que el comercial actual ofrece Quel y SQL.
La estructura bsica de Quel sigue muy de cerca la del clculo relacional de tuplas. Gran parte de las consultas en
Quel se expresan mediante el uso de tres tipos de clusulas: range of, retrieve y where.
Cada una de las variables de tupla se declara en una clusula range of. Decimos range of t is r para declarar que t
es una variable de tupla restringida a tomar valores de tuplas en la relacin r.
La clusula retrieve tiene una funcin similar a la clusula select de SQL.
La clusula where contiene el presicado de seleccin.
Una consulta tpica en Quel es de la forma:
range of t1 is r1
range of tm is rm
retrieve (ti.Aj, , tk.Al)
where P
Las tx son las variables de tupla, rx son relaciones y las Ax son atributos. Quel, como SQL, usa la notacin t.A
para expresar el valor de la variable de tupla t en el atributo A Esto significa lo mismo que t[a] en el clculo relacional de
tuplas.
Quel no incluye operaciones del lgebra relacional como intersect, union y minus. Adems, Quel no permite
subconsultas anidadas. Estas limitaciones no reducen el poder expresivo de Quel, ms bien eliminan algunas formas
alternativas de expresar una consulta cara al usuario.
Para encontrar el nombre de todos los clientes que tienen una cuneta en Perryridge escribimos:
range of t is depsito
retrieve (t.nombre_cliente)
where t.nombre_sucursal = Perryridge
Esta consulta no elimina duplicados. Para eliminarlos debemos aadir la palabra clave unique a la clusula
retrieve de la forma:retrieve unique (t.nombre_cliente).
Para mostrar una consulta en Quel que implique ms de una relacin, consideremos encontrar el nombre y la
ciudad de todos los clientes que tienen un prstamo en Perryridge:
range of t is prstamo
39
range of s is cliente
retrieve (t.nombre_cliente, s.ciudad_cliente)
where t.nombre_sucursal = Perryridge and t.nombre_cliente= s.nombre_cliente
Obsrvese que Quel, como SQL, usa los conectores lgicos and, or y not, en vez de los matemticos , , y .
Como en SQL, necesitamos expresar el predicado del producto explcitamente. Quel no tiene una notacin especial para
el producto natural.
Para ciertas consultas necesitamos tener dos variables de tupla que tengan como rango la misma relacin.
Considrese encontrar los nombres de todos los clientes que tienen una cuenta en la misma sucursal en la que Jones
tiene una cuenta.
range of s is depsito
retrieve (t.nombre_cliente)
where s.nombre_cliente = Jones and t.nombre_sucursal= s.nombre_sucursal
Puesto que la consulta anterior necesita que comparemos las tuplas pertenecientes a Jones con cada tupla de
depsito, necesitamos dos variables de tupla distintas cuyo rango sea depsito. Sin embargo, es frecuente el caso de que
una consulta requiera solo una variable de tupla cuyo rango sea una relacin. En dichos casos, podemos omitir la
sentencia range of para esa relacin y usar el nombre de relacin como una variable de tupla declarada implcitamente.
Siguiendo este convenio, para encontrar el nombre de todos los clientes que tienen un prstamo y una cuenta en la
sucursal Perryridge:
retrieve unique (prstamo.nombre_cliente)
where depsito.nombre_sucursal = Perryridge and
prstamo.nombre_sucursal = Perryridge and
depsito.nombre_cliente = prstamo.nombre_cliente
El Quel acadmico original no permite el uso de variables de tupla declaradas implcitamente.
Las funciones de agregacin en Quel calculan funciones sobre grupos de tuplas. Toman una forma diferente de
la de SQL, en Quel, el agrupamiento se especifica como parte de cada expresin de agregacin.
Las expresiones de agregacin en Quel pueden tomar las formas siguientes:
funcin de agregacin (t.A)
funcin de agregacin (t.A where P)
funcin de agregacin (t.A by S.B1, , S.Bn where P)
donde funcin de agregacin puede ser count, sum, avg, max, min, countu, sumu, avgu, o any; t es una variable de
tupla; A, B1 y Bn son atributos, y P es un predicado similar al de la clusula where. Una expresin de agregacin puede
aparecer en cualquier lugar donde puede aparecer una constante. El significado intuitivo de count, sum, avg, max y min
es intuitivo, any se explicar ms adelante y countu, sumu y avgu son idnticas a count, sum y avg respectivamente,
excepto que eliminan duplicados de sus operandos.
Para encontrar el saldo promedio de cuenta para todas las cuentas de la sucursal Perryridge, escribimos:
retrieve avg (t.saldo where t.nombre_sucursal = Perryridge)
En la clusula pueden aparecer valores de agregacin. Supngase que queremos encontrar todas las cuentas cuyo
saldo sea mayor que el promedio de todos los saldos del banco:
range of u is depsito
retrieve (t.nmero_cuenta)
where t.saldo > avg (u.saldo)
Consideremos ahora una modificacin de esta consulta. En vez de usar el saldo promedio del banco,
consideremos solo la sucursal Perryridge
where t.saldo > avg (u.saldo where u.nombre_sucursal = Perryridge)
Modifiquemos an ms la consulta. Ahora queremos encontrar a todos los clientes cuyo saldo sea mayor que el
saldo promedio de la sucursal donde se tiene la cuenta. En este caso necesitamos calcular para cada tupla t de depsito el
saldo promedio en la sucursal t.nombre_sucursal. Para formar estos grupos de tuplas necesitamos usar la construccin
by en la expresin de agregacin:
where t.saldo > avg (u.saldo by t.nombre_sucursal where u.nombre_sucursal = Perryridge)
El efecto de la construccin by en Quel es diferente al de group by en SQL. La fuente principal de esa diferencia
es el papel de las variables de tupla. La variable de tupla t usada en by es la misma que se utiliza en el resto de la consulta.
Bases de Datos
40
Sin embargo, todas las dems variables de tuplas son locales de la misma expresin de agregacin, incluso si una variable
con el mismo nombre aparece en otra parte de la consulta.
Consideremos encontrar el nombre de todos los clientes que tienen una cuenta en Perryridge, epro no tienen
un prstamo en Perryridge. Podemos escribir esta consulta en Quel usando la operacin de agregacin count si
pensamos en la consulta de la forma encontrar el nombre de todos los clientes que tienen una cuenta en Perryridge y
para quienes el nmero de prstamos en la sucursal Perryridge es cero.
Range of t is depsito
range of u is prstamo
retrieve unique (t.nombre_cliente)
where t.nombre_sucursal = Perryridge and
count (u.nmero_prstamo by t.nombre_cliente
where u.nombre_sucursal = Perryridge
and u.nombre_cliente = t,nombre_cliente) = 0
Quel ofrece otra funcin de agregacin que es aplicable a este ejemplo, llamada any. Si sustituimos count en la
consulta por any, obtenemos 1 si la cuenta es mayor que 0, de lo contrario obtenemos 0. La funcin any permite la
ejecucin ms rpida de la consulta, ya que el procesamiento puede detenerse tan pronto como se encuentre una tupla.
El uso de una comparacin con any es anlogo al cuantificador existe del clculo relacional.
Como un ejemplo ms complicado, considrese encontrar el nombre de todos los clientes que tienen una
cuenta en todas las sucursales de Brooklyn. Nuestra estrategia ser averiguar cuantas sucursales hay en Brooklyn y
despus comparar este nmero con el nmero de sucursales distintas en Brooklyn en las que cada cliente tiene una
cuenta:
range of s is sucursal
range of u is sucursal
where countu (s.nombre_sucursal by t.nombre_cliente
where s.ciudad_sucursal = Brooklyn and
s.nombre_sucursal = t,nombre_sucursal) =
countu (u.nombre_sucursal where u.ciudad_sucursal = Brooklyn)
Usamos by en la primera expresin countu, puesto que debemos restringir la consideracin a un nico cliente
cada vez. Sin embargo, no usamos by en la ltima expresin countu, puesto que estamos interesados en contar todas las
sucursales en Brooklyn independientes de las variables de tupla obligatorias a esta expresin countu.
La modificacin de la BD en Quel es similar a la modificacin en SQL, aunque la sintaxis es un poco distinta.
n Eliminacin.
La forma de una eliminacin en Quel es
range of t is r
delete t
where P
La variable de tupla t puede estar definida explcitamente. El predicado P puede ser cualquier predicado vlido
en Quel. Si se omite la clusula where, se eliminan todas las tuplas en la relacin..
Por ejemplo, eliminar todas las cuentas de las sucursales de Needham ser:
range of u is sucursal
delete t
where t.nombre_sucursal = u.nombre_sucursal and u.ciudad_sucursal = Needham
n Insercin.
La insercin en Quel toma dos formas generales: insercin de una sola tupla e insercin de un conjunto de
tuplas. Quel usa la palabra clave append para insercin.
Como ejemplos pondremos, insertar el hecho de que Smith tiene 1200$ en la cuenta 9732 en Perryridge:
append to depsito (nombre_sucursal = Perryridge, , saldo = 1200)
Proporcionar a todos los clientes con prstamos en Perryridge una cuenta de 200$, siendo el nmero de
prstamo el nmero de cuenta:
range of t is prstamo
append to depsito (t.nombre_sucursal, nmero_cuenta = t.nmero_prstamo,
t.nombre_cliente, saldo = 200)
where t.nombre_sucursal = Perryridge
n Actualizaciones.
Las actualizaciones se expresan en Quel usando la orden replace. Por ejemplo, para pagar el 6% de inters a las
cuentes de ms de 10000$ y el 5% al resto. Escribiremos:
replace t (saldo = 1,06 * saldo)
41
where t.saldo > 10000
replace t (saldo = 1,05 * saldo)
where t.saldo 10000
Consideremos una consulta para la cual se us la operacin union en SQL, como es encontrar el nombre de
todos los clientes que tienen una cuenta, un prstamo o ambos en Perryridge. Puesto que no tenemos una operacin
union en Quel, y sabemos que Quel est basado en el clculo relacional de tuplas, podramos guiarnos por la expresin
del clculo relacional de tuplas para esta consulta:
{t| sprstamo (t[nombre_cliente] = s[nombre_cliente] s[nombre_sucursal] = Perryridge)
udepsito (t[nombre_sucursal] = u[nombre_sucursal] u[nombre_sucursal] = Perryridge)}
La expresin anterior no nos conduce a una consulta en Quel. El problema es que en la copnsulta del clculo
relacional de tuplas, obtenemos los clientes tanto de variable de tupla s como de la u. En Quel, la clusula retrieve debe
ser una de las siguientes:
retrieve s.nombre_cliente retrieve u.nombre_cliente
Si elegimos la primera, excluimos a los clientes que tienen depsitos pero no prstamos, si elegimos la segunda
sucede lo contrario.
Para escribir esta consulta en Quel, debemos hacer una nueva relacin e insertar tuplas en ella, llamada temp.
Obtenemos los clientes con depsitos de la sucursal Perryridge escribiendo:
retrieve into temp unique (u.nombre_cliente)
La clusula into temp hace que se cree una nueva relacin, que contiene el resultado de esta consulta. Ahora
podemos encontrar a todos los clientes con prstamos de la sucursal Perryridge e insertarlos en la recin creada relacin
temp. Hacemos esto por medio de la orden append:
range of s is prstamo
append to temp unique (s.nombre_cliente)
where s.nombre_sucursal = Perryridge
Ahora tenemos una relacin temp que contiene a todos los clientes que tienen una cuenta, un prstamo, o
ambos, en Perryridge. El uso de la palabra clave unique asegura que se han eliminado todos los duplicados.
La estrategia de utilizar append nos permite realizar uniones en Quel. Para realizar una diferencia de conjuntos
r-s creamos una relacin temporal representada por r y eliminamos las tuplas de esta relacin temporal que tambin
estn en s.
Por ejemplo, si queremos encontrar el nombre de todos los clientes que tienen una cuenta en Perryridge pero
que no tienen un prstamo de Perryridge:
retrieve into temp unique (u.nombre_cliente)
range of s is prstamo
range of t is temp
delete (t)
where s.nombre_sucursal = Perryridge and t.nombre_cliente = s.nombre_cliente
La relacin temp contiene la lista de clientes deseada, por lo que escribimos el final de la consulta:
range of t is temp
Tema 5. Restricciones de integridad.
43
Tema 5.Restricciones de integridad.
Las restricciones de integridad proporcionan una medio de asegurar que los cambios que se hacen en la BD por
usuarios autorizados no resultan en una perdida de consistencia de los datos. As pues, las restricciones de integridad
protegen la BD contra daos accidentales.
Ya hemos visto una forma de restriccin de integridad para el modelo E-R en el capitulo 2. Estas restricciones
estaban en forma de:
n Declaraciones de clave. La estipulacin de que ciertos atributos forman una clave candidata para un conjunto
de entidades dado. El conjunto de inserciones y actualizaciones permitidas estn limitadas a aquellas que no
crean dos entidades con el mismo valor en una clave candidata.
n Forma de una relacin. Muchos a muchos, uno a muchos, uno a uno. Una relacin uno a uno o uno a
muchos restringe el conjunto de relaciones permitidas entre entidades de una coleccin de conjuntos de
entidades.
En general, una restriccin de integridad puede ser un predicado arbitrario perteneciente a la BD. Sin embargo,
los predicados arbitrarios pueden ser costosos de probar, as, normalmente los limitamos a restricciones de integridad
que pueden probarse con un mnimo tiempo extra.
5.1. Restricciones de dominio.
Hemos visto anteriormente que un dominio de valores posible puede estar asociado con cada atributo. Los
lmites de dominios son la forma ms elemental de restricciones de integridad. Son fciles de probar por el sistema
siempre que se introduce un nuevo dato en la BD.
5.1.1. Tipos de dominios.
Es posible que varios atributos tengan el mismo dominio, como ocurre con nombre_cliente y
nombre_empleado, que tienen como dominio el conjunto de todos los nombres de personas. Sin embargo los
dominios de saldo y nombre_sucursal deben ser distintos.
El principio que hay detrs de los dominios de atributo es similar al que hay detrs de la asignacin de tipos a
variables en los lenguajes de programacin.
5.1.2. Tipos de dominios en SQL.
El SQL estndar soporta un conjunto restringido de tipos de dominios:
n Cadena de caracteres de longitud fija, con longitud especificada por el usuario.
n Nmero en coma fija, con precisin especificada por el usuario.
n Entero, que es dependiente de la mquina.
n Entero pequeo, tambin es dependiente de la mquina.
n Nmeros en coma flotante y en coma flotante de doble de precisin dependiente de la mquina.
Varias implementaciones de SQL incluyen un tipo fecha.
A menudo resulta til poder comparar valores de dominios compatibles. Por ejemplo, puesto que todos los
enteros pequeos son enteros, una comparacin x < y, con x entero pequeo e y entero, tiene sentido. Una comparacin
de este tipo se hace convirtiendo el entero pequeo en entero. Una transformacin de este tipo se llama coaccin de
tipo. La coaccin de tipo se usa de forma rutinaria en los lenguajes comunes de programacin, as como en los DBMS.
As, vemos que en el SQL estndar, nombre_sucursal y nombre_cliente tendran el dominio de cadena de
caracteres. Aunque las longitudes de las cadenas podran ser diferentes, SQL considerara los dos dominios compatibles.
Vimos que la insercin de tuplas incompletas pueden introducir valores vacos en la BD. Para determinados
atributos, los valores nulos pueden ser inapropiados.
Considrese una tupla en la relacin cliente en la que nombre_cliente es un valor vaco. En casos como ste,
deseamos prohibir los valores nulos, restringiendo el dominio de nombre_cliente para que excluya los valores nulos.
El SQL estndar permite que la declaracin del dominio de un atributo incluya la especificacin not null. Esto
prohibe la insercin de un valor nulo para este atributo. Cualquier modificacin de la BD que causara que se insertase un
valor nulo en un dominio not null genera un diagnstico de error.
Hay muchas situaciones en las que la prohibicin de valores nulos es deseable. Un caso particular en el que es
esencial prohibir los valores nulos es en la clave primaria de un esquema de relacin.
5.2. Integridad referencial.
A menudo queremos asegurar que un valor que aparece en una relacin para un conjunto de atributos dado
tambin aparece para un cierto conjunto de atributos en otra relacin. Esto se llama integridad referencial.
Bases de Datos
44
Considrese un par de relaciones r(R ) y s(S) y el producto natural r| x| s. Puede darse el caso de que haya una
tupla t en r que no se corresponda con ninguna tupla en s. Es decir, no hay ninguna t en s tal que tr[RS]=ts[RS].
Dichas tupla se llaman tuplas colgadas.
Supngase que hay una tupla t en depsito con t1[nombre_sucursal = Lunartown], pero no hay no hay
ninguna tupla en la relacin sucursal para Lunartown. Esta sera una situacin no deseable. Esperamos que la relacin
sucursal liste todas las sucursales, por tanto, t hara referencia a una cuenta de una sucursal que no existe. Esta claro que
queremos tener una restriccin de integridad que prohiba tuplas colgadas de este tipo.
Sin embargo, no todas las instancias de tuplas colgadas son no deseables. Supngase que hay una tupla t en la
relacin sucursal con t2[nombre_sucursal = Mokan], pero no hay ninguna tupla en depsito para Mokan. En este
caso existe una sucursal que no tiene cuentas, y aunque no es deseable es posible esta situacin.
Para ver la diferencia entre estos dos ejemplos, recordamos que nombre_sucursal es la clave primaria de
esquema_sucursal. Puesto que nombre_sucursal aparece en esquema_depsito, las tuplas depsito hacen referencia a la
clave primaria de sucursal. decimos que el atributo nombre_sucursal en esquema_depsito es una clave exterior, ya que
nombre_sucursal es la clave primaria de una planificacin de relaciones distinta de esquema_depsito. Sin embargo, el
atributo nombre_sucursal en esquema_sucursal no es una clave exterior ya que nombre_sucursal no es la clave de
ningn otro esquema de relaciones.
As, la distincin entre estos dos ejemplos de tuplas colgadas es la presencia de una clave exterior.
Sean r1(R1) y r2(R2) relaciones con claves primarias K1 y K2 respectivamente. Decimos que un subconjunto de
R2 es una clave exterior con referencia K1 en la relacin r1 si es necesario que para cada t2 en r2 haya una tupla t1 en r1 tal
que t1[K1] = t2[].El ltimo trmino surge del hecho de que la restriccin de integridad anterior puede escribirse como
(r2)k1(r1). Ntese que para que una restriccin de integridad referencial tenga sentido, o bien = K1, o y K1
deben ser conjuntos de atributos compatibles.
5.2.2. Integridad referencial en el modelo E-R.
Las restricciones de integridad referencial se presentan frecuentemente. Si obtenemos el esquema de BD
relacional construyendo tablas desde diagramas E-R, entonces todas las relaciones que surgen de un conjunto de
relaciones tienen restricciones de integridad referencial. Por ejemplo, un conjunto de relaciones n-ario R, referente a los
conjuntos de entidades E1, E2, , En. Ki representa la clave primaria de Ei. Los atributos del esquema de relaciones para
el conjunto de relaciones R incluyen K1 K2 Kn. Cada Ki del esquema de R es una clave exterior que conduce a
una restriccin de integridad referencial.
Otra fuente de restricciones de integridad referencial son los conjuntos de entidades dbiles. Recuerdese que el
esquema de relaciones para un conjunto de entidades dbil debe incluir la clave primaria del conjunto de entidades del
cual depende. As pues, el esquema de relaciones para cada conjunto de entidades dbil uncluye una clave exterior que
conduce a una restriccin de integridad referencial.
5.2.3. Modificacin de la base de datos.
Las modificaciones de la BD pueden causar violaciones de la integridad referencial. A continuacin listamos la
prueba que debe hacerse para cada tipo de modificacin de la BD para proteger la restriccin de integridad referencial
siguiente:
(r2) k(r1)
n Insertar. Si una tupla t2 se inserta en r2, el sistema debe asegurar que existe una tupla t1 en r1, tal que t1[K] =
t2[]. Es decir:
t2[]k(r1)
n Eliminar. Si una tupla t1 se elimina en r1, el sistema debe calcular el conjunto de tuplas en r2 que hacen
referencia a t1:
=t1[K](r2)
Si este conjunto no est vaco, o la orden de eliminar se rechaza como un error, se deben eliminar las tuplas
que hacen referencia a t1. La ltima solucin puede llevar a eliminaciones en forma de cascada, ya que las
tuplas pueden hacer referencia a t1, y as respectivamente.
n Actualizar. Debemos considerar dos casos para actualizar: actualizaciones a la relacin que hace referencia (r2)
y actualizaciones a la relacin referenciada (r1).
45
Si se actualiza una tupla t2 en la relacin r2 y la actualizacin modifica valores para la clave exterior ,
entonces se hace una prueba similar a la del caso de insertar.t2 representa el nuevo valor de la tupla t2. El
sistema debe asegurar que:
t2[]k(r1)
Si se actualiza una tupla t1 en r1 y la actualizacin modifica valores para la clave primaria (K), entonces se
hace una prueba similar a la del caso de eliminar. El sistema debe calcular:
=t1[K](r2)
usando el valor antiguo de t1 (se aplica el valor de antes de la actualizacin). Si el conjunto no est vaco, la
actualizacin se rechaza como un error.
5.2.4. Integridad referencial en SQL.
El SQL estndar original no inclua sentencias para especificar claves exteriores. Una caracterstica de
intensificacin de la integridad ha sido aprobada como un aadido al estndar. Esta caracterstica permite la especificacin
de claves primarias y candidatas y de claves exteriores como parte de la sentencia create table:
n La clusula primary key de la sentencia create table incluye una lista de los atributos que comprenden la
clave primaria.
n La clusula unique key incluye una lista de los atributos que comprenden una clave candidata.
n La clusula foreign key incluye una lista de los atributos que comprenden la clave exterior y el nombre de la
relacin a la que hace referencia la clave exterior.
create table depsito
(nombre_sucursal char (15) not null,
nmero_cuenta char (10)
nombre_cliente char (20) not null
saldo integer,
primary key (nmero_cuenta, nombre_cliente),
foreign key (nombre_sucursal) references sucursal
foreign key (nombre_cliente) references cliente) )
Cualquier atributo que sea miembro de una clave candidata debe ser not null. As pues, en la definicin de
depsito necesitamos especificar nmero_cuenta y nombre_cliente como not null. Esta permitido tener valores vacos
en una clave exterior a menos que dicha clave exterior sea miembro de una clave candidata.
5.3. Dependencias funcionales.
Esta seccin se centra en un tipo particular de restriccin llamado dependencia funcional. La nocin de
dependencia funcional es una generalizacin de la nocin de clave.
Las dependencias funcionales son una restriccin al conjunto de relaciones legales. Nos permiten expresar
hechos acerca de la empresa que estamos modelando con la BD.
Anteriormente definimos la nocin de superclave como sigue: sea R un esquema de relaciones, un
subconjunto K de R es una superclave de R si, en cualquier relacin legal r(R ), para todos los pares t1 y t2 de tuplas en r
tales que t1 t2, t1[K] t2[K]. Es decir, dos tuplas en cualquier relacin legal r(R ) no pueden tener el mismo valor en el
conjunto de atributos K.
La nocin de dependencia funcional generaliza la nocin de superclave. Sea R y R. La dependencia
funcional
se cumple en R si en cualquier relacin legal r(R ), para todos los pares de tuplas t1 y t2 en r tales que t1[] = t2[],
tambin se cumple que t1[] = t2[]
Utilizando la notacin de la dependencia funcional, decimos que K es una superclave de R si K R. Es decir,
K es una superclave si siempre que t1[K] = t2[K], tambin se cumple que t1[R] = t2[R], es decir, t1 = t2.
Las dependencias funcionales nos permiten expresar restricciones que no pueden expresarse por medio de
superclaves. Considrese el esquema:
Esquema_prstamo = ( nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
Si un prstamo dado puede hacerse a ms de un cliente, entonces no esperaramos que el atributo
nmero_prestamo fuenra una superclave. Sin embargo, esperamos que la dependencia funcional
nmero_prestamo cantidad
se cumpla, puesto que sabemos que cada nmero de prstamo est asociado precisamente a una cantidad.
Usaremos las dependencias funcionales de dos formas:
n Para especificar restricciones en el conjunto de relaciones legales. As pues, nos interesaremos slo por las
relaciones que satisfagan un conjunto dado de dependencias funcionales. Si queremos limitarnos a las
relaciones de esquema R que satisfacen F, decimos que F se cumple e R.
n Para probar si una relacin es legal bajo un conjunto dado de dependencias funcionales. Si una relacin r es
legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a F.
Bases de Datos
46
Consideremos la siguiente relacin:
A B C D
a1
a1
a2
a2
a3
b1
b2
b2
b3
b3
c1
c1
c2
c2
c2
d1
d2
d2
d3
d4
Obsrvese que A C se satisface. Hay dos tuplas que tienen el valor a1 en A, y que tienen el mismo valor c1 en
C, de la misma forma que ocurre con los valores a2 y c2. No existen otros pares de tuplas distintos que tengan el mismo
valor en A. sin embargo no se satisface la dependencia funcional C A.
La relacin r satisface muchas otras dependencias funcionales, incluyendo, por ejemplo, la dependencia
funcional AB D, usando AB como abreviatura de {A, B}. Obsrvese que no hay ningn par de tuplas distintas t1 y t2
tales que t1[AB] = t2[AB]. Por tanto, si t1[AB] = t2[AB] debe cumplirse que t1 = t2 y, as, t1[D] = t2[D]. De este modo, r
satisface AB D.
Se dice que algunas dependencias funcionales son triviales porque se satisfacen por todas las relaciones. Por
ejemplo, todas las relaciones que incluyen el atributo A satisfacen A A, y de manera similar, todas las relaciones que
incluyen el atributo A satisfacen AB A. En general, una dependencia funcional de la forma es trivial si .
Para distinguir entre los conceptos de una relacin que satisface una dependencia y una dependencia que se
cumple en un esquema volvemos al ejemplo bancario.
Consideremos la relacin cliente. Vemos que se satisface calle ciudad_cliente, pero es posible que dos
ciudades tengan calles con el mismo nombre. As pues, es posible tener una instancia de la relacin cliente en la que no se
satisfaga calle ciudad_cliente. Por tanto, no incluiramos calle ciudad_cliente en el conjunto de dependencias
funcionales que se cumplen en esquema_cliente.
En la relacin prstamo vemos que se satisface nmero_prstamo cantidad, ya que cada prstamo debe
tener una nica cantidad. Por tanto, queremos exigir que la relacin prstamo satisfaga nmero_prstamocantidad en
todo momento. En otras palabras, imponemos la restriccin de que se cumpla nmero_prstamo cantidad en
esquema_prstamo.
En lo que sigue suponemos que al disear una BD relacional primero listamos aquellas dependencias
funcionales que se deben cumplir siempre. En el ejemplo bancario la lista de dependencias incluye:
Esquema_sucursal: nombre_sucursal ciudad_sucursal
nombre_sucursal activo
Esquema_cliente: nombre_cliente ciudad_cliente
nombre_cliente calle
Esquema prstamo: nmero_prstamo cantidad
nmero_prstamo nombre_sucursal
Esquema_depsito: nmero_cuenta saldo
nmero_cuenta nombre_sucursal
5.3.2. Cierre de un conjunto de dependencias funcionales.
No es suficiente considerar un conjunto dado de dependencias funcionales. Ademas necesitamos considerar
todas las dependencias funcionales que se cumplen. Veremos que, dado un conjunto F de dependencias funcionales,
podemos probar que se cumplen otras ciertas dependencias funcionales. Se dice que F implica lgicamente dichas
dependencias funcionales.
Supngase que nos dan un esquema de relaciones R = (A, B, C, G, H, I) y el conjunto de dependencias
funcionales:
A B A C CG H CG I B H
La dependencia funcional A H se implica lgicamente. Es decir, podemos demostrar que siempre que se
cumpla el conjunto dado de dependencias funcionales, A H tambin debe cumplirse. Supngase que t1 y t2 son
tuplas tales que t1[A] = t2[A]. Puesto que nos dan que A B, se deduce de la definicin de dependencia funcional que
t1[B] = t2[B]. Entonces, puesto que nos dan B H se deduce que t1[H] = t2[H]. Por tanto, hemos demostrado que
siempre que t1 y t2 son tuplas tales que t1[A] = t2[A], tambin se cumple que t1[H] = t2[H]. Pero sta es exactamente la
definicin de A H.
Sea F un conjunto de dependencias funcionales. El cierre de F es el conjunto de dependencias funcionales que
F implica lgicamente. Indicamos el cierre de F por F
+
. Dado F podemos calcular F
+
directamente de la definicin formal
de dependencia funcional, pero si F es grande este proceso sera largo y difcil, por lo que existen tcnicas ms sencillas
para deducir dependencias funcionales.
La primera tcnica se basa en tres axiomas o reglas de inferencia para dependencias funcionales. Aplicando estas
reglas repetidamente, podemos encontrar F
+
completo dado F.. Adoptaremos el convenio de usar letras griegas para
conjuntos de atributos y letras latinas maysculas para atributos individuales, as mismo utilizamos para representar
.
n Regla de reflexividad. Si es un conjunto de atributos y , entonces se cumple .
n Regla de aumento. Si se cumple y es un conjunto de atributos, entonces se cumple .
47
n Regla de transitividad. Si se cumple , y se cumple , entonces se cumple .
Estas reglas son seguras porque no generan dependencias funcionales incorrectas, y son completas porque
para un conjunto F de dependencias funcionales, nos permiten generar F
+
por completo. Esta coleccin de reglas se
llama axiomas de Armstrong en honor de la persona que los propuso.
Aunque los axiomas de Armstrong son completos, resulta pesado usarlos directamente para el clculo de F
+
,
por lo que existen unas reglas adicionales para facilitar esta tarea:
n Regla de unin. Si se cumplen y , entonces se cumple .
n Regla de descomposicin. Si se cumple , entonces se cumplen y .
n Regla de pseudotransitividad. Si se cumplen y , entonces se cumple .
Apliquemos estas reglas al ejemplo anterior del esquema R=(A, B, C, G, H, I) y el conjunto F de dependencias
funcionales {AB, AC, CGH, CGI, BH}. Algunos miembros de F
+
son:
AH. Puesto que se cumplen AB y BH, aplicamos la regla de la transitividad, cumplindose AH.
CGHI. Puesto que se cumplen CGH y CGI, la regla de unin implica CGHI.
AGI. Necesitamos varios pasos para demostrarla. Primero, como se cumple AC, con la regla de aumento
vemos que AGCG, y como tenemos CGI, por la regla de la transitividad AGI.
5.3.3. Cierre de conjuntos de atributos.
Para comprobar que un conjunto es una superclave debemos idear un algoritmo para calcular el conjunto de
atributos determinados funcionalmente por . Veremos que un algoritmo de este tipo, tambin es til como parte del
clculo del cierre de un conjunto F de dependencias funcionales.
Sea un conjunto de atributos. Al conjunto de todos los atributos determinados funcionalmente por bajo
un conjunto F de dependencias funcionales se le llama cierre de bajo F y re representa por
+
.
Ahora mostramos un algoritmo para calcular
+
. La entrada es un conjunto F de dependencias funcionales y el
conjunto de atributos. La salida se almacena en la variable resultado.
resultado:= ;
while (cambios en resultado) do
for each dependencia funcional in F do
begin
if resultado then resultado:= resultado ;
end
Usemos el algoritmo para calcular (AG)
+
con las dependencias funcionales definidas anteriormente.
Empezamos con resultado = AG. La primera vez que ejecutamos el bucle while para probar cada dependencia funcional
encontramos que:
AB nos hace incluier B en el resultado, ya que AB esta en F, Aresultado (que es aG), por tanto
resultado:=resultadoB.
AC hace que el resultado se convierta en ABCG.
CGH hace que el resultado sea ABCGH.
CGI hace que el resultado se convierta en ABCGHI.
La segunda vez que ejecutamos el bucle while, no se aaden atributos a resultado y el algoritmo termina.
La regla de unin implica que resultado , as determina funcionalmente cualquier resultado nuevo
generado por el bucle while. Por tanto, cualquier atributo devuelto por el algoritmo est en
+
.
Es fcil ver que el algoritmo encunetra
+
completo. Si hay algn atributo en
+
que no est todava en
resultado, entonces debe haber una dependencia funcional para la cual resultado y al menos un atributo de F
no est en resultado.
Resulta ser que en el peor de los casos este algoritmo puede tardar un tiempo que es una funcin cuadrtica del
tamao de F, as que existen algoritmos ms rpidos.
5.3.4. Recubrimiento cannico.
Para minimizar el nmero de dependencias funcionales que necesitan ser probadas en caso de actualizacin,
restringimos un conjunto dado F de dependencias funcionales a un recubrimiento cannico de F. Un recubrimiento
cannico de F es un conjunto de dependencias tal que F implica lgicamente a todas las dependencias en Fc y Fc implica
lgicamente a todas las dependencias de F. Adems Fc debe tener las siguientes propiedades:
n Cada una de las dependencias funcionales en Fc no contiene atributos extraos a . Los atributos
extraos son atributos que pueden eliminarse de sin cambiar F
+
c. As A es extrao a si A y Fc
implica lgicamente a (Fc-{}){-A}.
n Cada una de las dependencias funcionales en Fc no contiene atributos extraos a . Los atributos
extraos son atributos que pueden eliminarse de sin cambiar F
+
c. As A es extrao a si A y (Fc-
{}){-A}. implica lgicamente a Fc.
n Cada lado izquierdo de una dependencia funcional en Fc es nico. Es decir, no existe dos dependencias
11 y 22 en Fc tales que 1=2.
Bases de Datos
48
Para calcular un recubrimiento cannico para F, utilcese la regla de unin para sustituir cualquier dependencia en
F de la forma 11 y 12 con 112 . Prubese cada dependencia funcional para ver si hay un atributo
extrao a . Para cada dependencia comprubese si hay un atributo extrao a . Este proceso se debe repetir
hasta que no ocurra ningn cambio en el bucle.
Considrese el siguiente conjunto de dependencias funcionales F={ABC, BC, AB, ABC} en el
esquema (A, B, C). Calculemos el recubrimiento cannico de F.
Hay dos dependencias con el mismo atributo en el lado izquierdo de la flecha ABC y AB, por lo que las
combinamos en ABC.
A es extrao a ABC porque BC implica lgicamente a ABC, y as ((F-{ABC}){BC} implica
lgicamente a Fc. Como resultado de suprimir A de ABC, obtenemos que BC, la cual ya est en el conjunto de
dependencias funcionales.
En este momento, el conjunto de dependencias funcionales es F={ABC, BC}.
Obsrvese que ahora se cumplen las propiedades de un recubrimiento cannico.
5.4. Afirmaciones.
Una afirmacin es un predicado que expresa una condicin que se desea que siempre satisfaga la BD. Las
restricciones de dominio, las dependencias funcionales y las restricciones de integridad referencial son formas especiales
de afirmacin, sin embargo, existen muchas restricciones que no pueden expresarse usando solamente estas tres formas
especiales. Entre los ejemplos de dichos lmites estn: que cada cliente de prstamos debe tener una cuenta con un saldo
mnimo de 1000$, y que cada sucursal no puede prestar ms dinero que su activo.
Cuando se hace una afirmacin, el sistema prueba su validez. Si la afirmacin es vlida, entonces cualquier
futura modificacin de la BD est permitida slo si no se provoca que se viole la afirmacin.
El elevado tiempo de prueba y mantenimiento de las afirmaciones ha llevado a la mayora de los que
desarrollan los sistemas a omitir el soporte para afirmaciones generales. La propuesta original para el lenguaje SQL
inclua una construccin de propsito general assert, para la expresin de restricciones de integridad.
Una afirmacin perteneciente a una nica relacin toma la forma:
assert <nom_afirmacin> on nom_relacin> : <predicado>
Por ejemplo, si queremos definir una restriccin de integridad que ningn saldo de cuenta sea negativo:
assert limite_saldo on depsito : salo 0
Podamos haber escrito la afirmacin anterior como una restriccin de dominio. Sin embargo, la sentencia
assert nos permite especificar restricciones en una relacin que no pueden expresarse como un lmite del dominio:
assert limite_banquero on persona: nombre_cliente nombre_empleado
Las afirmaciones pueden restringirse para aplicarse slo a modificaciones de la BD como en el caso de que
queremos prevenir la adicin de una cuenta a menos que el nombre del cliente aparezca en la relacin cliente. Escribimos
la afirmacin siguiente:
assert limite_direccin on insertion to depsito
exists (select * from cliente
where cliente.nombre_cliente = depsito.nombre_cliente)
De hecho, la afirmacin anterior es una restriccin de integridad referencial.
La forma ms general de afirmacin es:
assert <nom_afirmacin> : <predicado>
donde >predicado> es cualquier clusula where vlida en SQL
Debido al elevado tiempo que lleva la prueba de afirmaciones arbitrarias, la sentencia assert ha desaparecido de
las versiones ms recientes de SQL, incluyendo la estndar. En lugar de las afirmaciones estn las restricciones ms fciles
de probar, como las de dominio, las de clave y las de integridad referencial. Sin embargo, existe una propuesta para
incluir afirmaciones generales en una futura revisin del SQL estndar.
5.5. Disparadores.
Un disparador es una sentencia que el sistema ejecuta automticamente como un efecto secundario de una
modificacin de la BD.
Para disear un mecanismo de parador debemos:
n Especificar las condiciones bajo las cuales se va a ejecutar el disparador.
n Especificar las acciones que se van a tomar cuando se ejecute el disparador.
Supngase que en lugar de permitir saldos negativos, el banco trata los saldos deudores poniendo el saldo de
cuenta a cero y creando un prstamo en la cantidad del saldo deudor. A ste prstamo se le da un nmero igual al
nmero de cuenta de la cuenta deudora.. Sea t la tupla con un saldo negativo, las acciones que se deben realizar son las
siguientes:
Insertar una nueva tupla s en la relacin prstamo con:
s[nombre_sucursal] = t[nombre_sucursal] s[nmero_prstamo] = t [nmero_prstamo]
s[cantidad] = t[saldo] s[nombre_cliente] = t [nombre_cliente]
Poner t[saldo] a cero.
El disparador de ste ejemplo sera:
49
define trigger saldo_deudor
on update of depsito T
(if new T.saldo < 0
then (insert into prstamo values
(T.nombre_sucursal, T,nmero_cuenta,
T.nombre_cliente, - new T.saldo)
update depsito S
set S.saldo = 0
where S.nmero_cuenta = T.nmero_cuenta))
El SQL estndar no incluye disparadores, aunque el Sequel original inclua caractersticas de disparador
limitadas. Existen diversos sistemas con sus propias caractersticas de disparadores no estndar.
Tema 6. Diseo de Bases de Datos relacionales.
51
Tema 6.Diseo de Bases de Datos relacionales.
En general el objetivo del diseo de una BD relacional es generar un conjunto de esquemas de relaciones que
nos permitan almacenar informacin sin redundancia, pero que a la vez nos permitan recuperar informacin fcilmente.
Una tcnica consiste en disear esquemas que tengan una forma normal adecuada. Para determinar si un esquema tiene
una de las formas normales, necesitaremos informacin adicional sobre la empresa del mundo real. En este captulo
definimos formas normales usando dependencias funcionales y usando otros tipos de dependencias de datos.
6.1. Peligros en el diseo de Bases de Datos relacionales.
Entre las propiedades indeseables que un mal diseo puede tener estn:
n Repeticin de informacin.
n Incapacidad para representar cierta informacin.
n Prdida de informacin.
A continuacin tratamos stas con mayor detalle utilizando el ejemplo bancario, con los dos siguientes
esquemas de relacin:
Esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal)
Esquema_prstamo = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
6.1.1. Representacin de la informacin.
Considrese un diseo alternativo para la BD bancaria en la que sustituimos los dos esquemas anteriores por
un solo esquema:
esquema_prestar=(nombre_sucursal,activo, ciudad_sucursal, nmero_prstamo, nombre_cliente, cantidad)
Una instancia de la relacin prestar se produce al hacer el producto natural de las instancias sucursal y prstamo.
Supngase que queremos aadir un nuevo prstamo a la BD. En el diseo original aadiriamos la tupla
(Perryridge, 31, Turner, 1500) a la relacin prstamo. Bajo el diseo alternativo debemos repetir los datos de activo y
ciudad_sucursal para Perryridge a aadir la tupla (Perryridge, 1700000, Horseneck, 31, Turner, 1500) a la relacin prestar.
En general, los datos de activo y ciudad_sucursal deben aparecer una vez por cada prstamo que hace la sucursal.
La repeticin de informacin que requiere el uso del diseo alternativo no es conveniente, porque desperdicia
espacio y complica la actualizacin de la BD. Supngase que la sucursal Perryridge se traslada de ciudad. Bajo el diseo
original solo se necesita cambiar una tupla de la relacin sucursal, bajo el diseo alternativo, se necesita cambiar muchas
tuplas de la relacin prestar. As pues las actualizaciones son ms costosas, ya que debemos asegurarnos que se realizan
en cada tupla perteneciente a Perryridge.
La observacin anterior es esencial para comprender porque es malo el diseo alternativo. Sabemos que una
sucursal est situada exclusivamente en una sucursal, y que una sucursal puede hacer muchos prstamos, en otras
palabras, sabemos que la dependencia funcional nombre_sucursal ciudad_sucursal se cumple en esquema prestar,
pero no esperamos que se cumpla la dependencia nombre_sucursal nmero_prstamo. El hecho de que una sucursal
est situada en una ciudad y el hecho de que una ciudad hace un prstamo son independientes y, como hemos visto, se
representan mejor en relaciones separadas. Vemos que las dependencias funcionales se pueden especificar para especificar
normalmente cuando el diseo de una BD es bueno.
Otro problema con esque_prestar es que no podemos representar directamente la informacin referente a una
sucursal a menos que exista por lo menos un prstamo, lo que se debe a que es necesario que las tuplas de la relacin
prestar tengan valores en todos sus atributos. Una solucin a este problema es introducir valores nulos, pero son
difciles de tratar. Peor an, tendramos que suprimir esta informacin cuando se hubieran pagado todos los prstamos.
Esta claro que esto no es conveniente.
6.1.2. Perdida de informacin.
El diseo anterior de un mal diseo sugiere que debemos descomponer un esquema de relaciones con muchos
atributos en varios esquemas con menos atributos. Sin embargo, si la descomposicin se hace sin cuidado puede llegarse
a otra forma de diseo defectuoso.
Considrese un diseo alternativo en el que esquema_prstamo se descompone en:
esquema_cant = (cantidad, nombre_cliente)
esquema prest = (nombre_sucursal, nmero_prstamo, cantidad)
Por supuesto hay casos en los que necesitamos reconstruir la relacin prstamo. Por ejemplo, supngase que
queremos encontrar aquellas sucursales que han prestado a Jones. Ninguna de las relaciones de la BD alternativa contiene
ese dato. Necesitamos reconstruir la relacin prstamo con
cant | x| prest
Pero cuando comparamos esta relacin con la de prstamo original, observamos algunas diferencias. Aunque
cada una de las tuplas de prstamo esta en cant | x| prest, existen tuplas en cant | x| prest que no estn en prstamo, ya
que si sucede que tenemos varios prstamos con la misma cantidad, no podemos decir a que cliente corresponde cada
prstamo. As, cuando efectuamos el producto de cant y prest, no solo obtenemos las tuplas que tenamos en prstamo,
sino tambin varias tuplas adicionales. Aunque tenemos ms tuplas en cant | x| prest, realmente tenemos menos
informacin. Ya no podemos representar que clientes tienen prstamos de que sucursal. Debido a esta perdida de
Bases de Datos
52
informacin, la descomposicin de esquema_prstamo en esquema_cant y esquema_prest la llamamos descomposicin
con prdida, descomposicin de producto con prdida. Una descomposicin diferente se llama descomposicin de
producto sin prdida. Una descomposicin de producto con prdida es un mal diseo de la BD.
Examinemos la descomposicin ms de cerca para ver porque tiene prdida. Esquema_prest y esquema_cant
tienen una atributo en comn: cantidad. La nica forma de representar una relacin entre cant y prest es a travs de
cantidad. Esto no es conveniente, ya que puede ocurrir que varios clientes tengan prstamos por las misma cantidad,
pero no necesariamente en las mismas sucursales. Del mismo modo puede ocurrir que varios clientes tengan prstamos
en la misma sucursal sin que haya relacin entre las cantidades de sus respectivos prstamos.
Comprese esto con esquema_prestar, si descompusiramos esquema_prestar en esquema_prstamo y
esquema_sucursal, estos dos esquemas tienen una atributo en comn: nombre_sucursal. As, la nica forma en que
podemos representar una relacin entre nombre_cliente y activo es a travs de nombre_sucursal. La diferencia entre este
ejemplo y el anterior es que el activo de una sucursal es el mismo sin importar a que cliente nos estamos refiriendo,
mientras que la sucursal asociada con la cantidad de un prstamo determinado depende del cliente al que nos referimos.
Para un nombre_sucursal dado, existe nicamente un valor de activo y uno de ciudad_sucursal, mientras que no puede
decirse los mismo de cantidad. Es decir la dependencia funcional
nombre_sucursal activo ciudad_sucursal
se cumple, pero cantidad no determina funcionalmente a nombre_sucursal.
La descomposicin de esquema_prestar en esquema_prstamo y esquema_sucursal es sn prdida debido a la
dependencia funcional nombre_sucursal activo ciudad_sucursal.
Decimos que una relacin es legal si satisface todas las reglas, o restricciones, que imponemos a la BD.
Sea C un conjunto de restricciones de la BD. Una descomposicin {R1, R2, , Rn} de un esquema de relaciones
R es una descomposicin de producto sin prdida de R si para todas las relaciones r del esquema R que sean legales bajo
C: r=R1(r ) | x| R2(r ) | x| | x| Rn(r )
6.2. Normalizacin por medio de dependencias funcionales.
Puede utilizarse un conjunto dado de dependencias funcionales al disear una BD relacional en la que no
ocurran la mayora de la propiedades no deseables tratadas. Puede llegar a ser necesario descomponer una relacin en
varias ms pequeas. Usando dependencias funcionales, podemos definir varias formas normales que representen
diseos buenos, aunque existe un gran nmero de formas normales.
6.2.1. Propiedades deseables de una descomposicin.
Ilustraremos los conceptos considerando el esquema:
esquema_prestar = (nombre_sucursal, activo, ciudad_sucursal, nmero_prstamo, nombre_cliente, cantidad)
El conjunto F de dependencias funcionales que es necesario que se cumplan en esquema_prestar es:
nombre_sucursal activo ciudad_cusursal nmero_prstamo cantidad nombre_sucursal
Supngase que la descomponemos en las tres relaciones siguientes:
esquema_sucursal = ( nombre_sucursal, activo, ciudad_sucursal)
esquema_info_prstamo = (nombre_sucursal, nmero_prstamo, cantidad)
esquema_prstamo_cliente = ( nombre_cliente, nmero_prstamo)
Decimos que esta descomposicin tiene varias propiedades deseables, como vamos a ver.
6.2.1.1. Descomposicin de producto sin prdida.
Es esencial que la descomposicin sea sin prdida, como lo es la anterior. Para demostrarlo, primero debemos
presentar un criterio para determinar si una relacin tiene prdida.
Sea R un esquema de relaciones y F un conjunto de dependencias funcionales en R. R1 y R2 forman una
descomposicin de R. Esta es una descomposicin de producto sin prdida de R si por lo menos una de las
dependencias funcionales siguientes est en F:
R1 R2 R1 R1 R2 R2
Empezamos descomponiendo Esquema_prestar en ods esquemas:
esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal)
esquema_prstamo = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
Puesto que nombre_sucursal activo ciudad_sucursal, la regla de aumento para dependencias funcionales
implica que:
nombre_sucursal nombre_sucursal activo ciudad_sucursal
Puesto que esquema_sucursal esquema_prstamo = {nombre_sucursal}, se sigue que la descomposicin
inicial es una descomposicin de producto sin prdida.
A continuacin descomponemos esquema_prstamo en:
esquema_prstamo_cliente = (nombre_cliente, nmero_prstamo)
Este paso da como resultado una descomposicin de producto sin prdida, ya que nmero_prstamo es un
atributo comn y nmero_prestamo cantidad nombre_sucursal.
53
6.2.1.2. Conservacin de las dependencias.
Es preciso considerar un objetivo ms al disear BD relacionales: la conservacin de las dependencias. Cuando
se hace una actualizacin de la BD, el sistema debe poder comprobar que la actualizacin no crear una relacin ilegal, es
decir, una que no satisfaga las dependencias funcionales dadas. Para comprobar las actualizaciones eficientemente es
conveniente disear esquemas de la BD relacionales que permitan validar una actualizacin sin calcular los productos que
reconstruyen las relaciones.
Para decidir si se deben calcular los productos, necesitamos determinar que dependencias funcionales se deben
probar mediante la comprobacin de cada relacin individualmente. Sea F un conjunto de dependecias funcionales en el
esquema R, y sea R1, R2, , Rn una descomposicin de R. La restriccin de F a Ri es el conjunto Fi de todas las
dependencias funcionales en F
+
que incluyen nicamente atributos de Ri. Puesto que que todas las dependencias
funcionales en una restriccin implican atributos de slo un esquema de relaciones, es posible probar que se satisface una
dependencia de este tipo comprobando solamente una relacin.
El conjunto de restricciones F1, F2, , Fn es el conjunto de dependencias que pueden comprobarse de manera
eficiente. Ahora debemos preguntar si es suficiente probar slo las restricciones. Sea F=F1F2Fn. F es un
conjunto de dependencias funcionales en el esquema R, pero en general FF. Sin embargo, an cuando FF, puede ser
que F
+
=F
+
. Si esto es cierto, entonces F implica lgicamente a todas las dependencias de F
+
, y si verificamos que se
satisface F, hamos verificado que se satisface F. Decimos que una descomposicin que satisface F
+
=F
+
es una
descomposicin que conserva las dependencias.
Ahora presentamos el algoritmo que sirve para probar la conservacin de dependencias. La entrada es un
conjunto D = {R1, R2, , Rn} de esquemas de relaciones descompuestos y un conjunto F de dependencias funcionales:
calcular F
+
;
for each esquema R1 en D do
begin
Fi := restriccin de F
+
a Ri;
end
F :=
for each restriccin Fi do
begin
F = F Fi
end
calcualr F
+
if (F
+
= F
+
) then return (verdadero)
else return (falso)
Ahora podemos demostrar que la descomposicin de esquema_prestar conserva las dependencias. Para ver
esto, consideramos cada uno de los miembros del conjunto F de dependencias funcionales que necesitamos que se
cumplan en esquema_prestar y mostramos que cada uno puede probarse en por lo menos una relacin de la
descomposicin.
La dependencia funcional nombre_sucursal activo ciudad_sucursal puede probarse usando
esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal).
La dependencia funcional nmero_prstamo cantidad nombre_sucursal puede probarse usando
esquema_info_prstamo = (nombre_sucursal, nmero_prstamo, cantidad).
Como vemos, a menudo es ms fcil no aplicar al algoritmo para probar la conservacin de dependencias, ya
que el primer paso, el clculo de F
+
, se lleva un tiempo exponencial.
6.2.1.3. Repeticin de informacin.
La descomposicin de esquema_prestar no padece del problema de la repeticin de informacin. La
descomposicin separa los datos de la sucursal y de prstamo en relaciones distintas, eliminando redundancias. En la
descomposicin, la relacin del esquema esquema_prstamo_cliente contiene la relacin nmero_prstamo,
nombre_cliente, cosa que no sucede en los dems esquemas. Por tanto, tenemos una tupla para cada cliente para un
prstamo en la relacin de esquema_info_prstamo. En las otras relaciones que incluyen nmero_prstamo, solo se
necesita que aparezca una tupla por prstamo.
Claramente, la falta de redundancia que presenta la descomposicin es deseable. Las distintas formas normales
representan los grados de eliminacin de redundancia que pueden lograrse.
6.2.2. Forma normal Boyce-Codd.
Una de las formas normales ms deseables que podemos obtener es la forma normal Boyce-Codd (BCNF).
Un esquema de relaciones de R est en BCNF con respecto a un conjunto F de dependencias funcionales si para todas las
dependencias en F
+
de la forma , donde R y R, por lo menos se cumple una de las siguientes condiciones:
n es una dependencia funcional trivial, es decir .
n es una superclave del esquema R.
Bases de Datos
54
Un diseo de BD est en BCNF si cada uno de los miembros del conjunto de los esquemas de relacin que
corresponde el diseo est en BCNF.
Para ilustrarlo, consideremos los esquemas de relacin siguientes, y sus respectivas dependencias funcionales:
esquema_sucursal = (nombre_sucursal, activo, ciudad_sucursal)
esquema_cliente = (nombre_cliente, calle, ciudad_cliente)
nombre_cliente calle ciudad_cliente
esquema_depsito = (nombre_sucursal, nmero_cuenta, nombre_cliente. saldo)
nmero_cuenta saldo nombre_sucursal
esquema_prstamo = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
nmero_prstamo cantidad nombre_sucursal
Decimos que esquema_cliente est en BCNF. Obsrvese que una clave candidata del esquema es
nombre_cliente. Las nicas dependencias no triviales que se cumplen en esquema_cliente tienen nombre_cliente en el
lado izquierdo de la flecha. Puesto que nombre_cliente es una clave candidata, las dependencias funcionales con
nombre_cliente en el lado izquierdo no violan la definicin de BCNF. De la misma forma se puede demostrar que
esquema_sucursal est en BCNF.
Sin embargo, esquema_prstamo no est en BCNF., obsrvese que nmero_prstamo no es una superclave de
esquema prstamo, puesto que podramos tener un par de tuplas representando un nico prstamo que se hizo a dos
personas.
Como no se listaron las dependencias funcionales que excluyen el caso anterior, nmero_prstamo no es una
clave candidata. Sin embargo, la dependencia funcional nmero_prstamo cantidad no es trivial. Por tanto
esquema_prstamo no satisface la definicin de BCNF.
Decimos que esquema_prstamo no est en forma deseable, ya que padece el problema de repeticin de
informacin, ya que si hay varios nombres de clientes asociados con un prstamo, estamos forzados a repetir el nombre
de la sucursal y la cantidad. Podemos eliminar esta redundancia rediseando la BD de forma que todos los clientes estn
en BCNF, descomponiendo esquema_prstamo en:
Esta es una descomposicin de producto sin prdida. Para determinar si estos esquemas estn en BCNF,
necesitamos saber que dependencias funcionales les son aplicables.
Nmero_prstamo cantidad nombre_sucursal se aplica a esquema_info_prstamo, y que solo se aplican
dependencias funcionales triviales a esquema_prstamo_cliente. Aunque nmero_prestamo no es una superclave dse
esquema_prstamo, si es una clave candidata de esquema_info_prstamo. As, los dos esquemas de la descomposicin
estn en BCNF.
Ahora es posible evitar la redundancia en el caso en que varios clientes estn asociados a un prstamo. Existe
exactamente una tupla por cada prstamo en la relacin esquema_info_prstamo, y una tupla por cada cliente de cada
prstamo en la relacin esquema_prstamo_cliente. As, no tenemos que repetir el nombre de la sucursal y la cantidad
una vez por cada cliente asociado a un prstamo.
Para que el diseo completo de la BD este en BCNF, debemos descomponer esquema_depsito de una forma
parecida en los esquemas:
esquema_info_depsito = (nombre_sucursal, nmero_cuenta, saldo)
esquema_depsito_cliente = (nombre_cliente, nmero_cuenta)
Ahora ya podemos establecer un mtodo general para generar una coleccin de esquemas BCNF. Si R no est
en BCNF, no podemos descomponer R en una coleccin de esquemas BCNF R1, R2, , Rn usando el siguiente
algoritmo, que genera no slo una descomposicin BCNF sino tambin una descomposicin de producto sin prdida.
Para ver que el algoritmo genera solamente descomposiciones sin prdida, obsrvese que cuando sustituimos un
esquema Ri por (Ri-) y (, ), se cumple la dependencia y (Ri-)(, )=.
resultado := {R};
listo := falso;
calcular F
+
;
while (not listo) do
if (existe un esquema Ri en resultado que no est en BCNF) then begin
sea una dependencia funcional no trivial que se cumple
en Ri tal que Ri no est en F
+
, y =;
resultado := (resultado - Ri) (Ri-) (, );
end
eslse listo := verdadero;
Apliquemos el algoritmo de descomposicin BCNF al esquema:
esquema_prestar = ( nombre_sucursal, activo, ciudad_sucursal, nmero_prstamo, nombre_cliente, cantidad)
El conjunto de dependencias funcionales que necesitamos que se cumplan en esquema_prestar es:
nmero_prstamo cantidad nombre_sucursal
Una clave candidata de este esquema es {nmero_prstamo, nombre_cliente}.
Podemos aplicar el algoritmo as:
55
La dependencia funcional nombre_sucursal activo ciudad_sucursal se cumple en esquema_prestar, pero
nombre_sucursal no es una superclave. As, esquema_prestar no esta en BCNF. Sustituimos esquema prestar por:
esquema_sucursal = (nombre_sucursal, ciudad_sucursal, activo)
esquema_depsito = (nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad)
Las nicas dependencias funcionales no triviales que se cumplen en esquema_sucursal incluyen
nombre_sucursal en el lado izquierdo de la flecha. Puesto que nombre_sucursal es una clave de esquema_sucursal, la
relacin esquema_sucursal est en BCNF.
La dependencia funcional nmero_prstamo cantidad nombre_sucursal se cumple en esquema_depsito,
pero nmero_prstamo no es una clave de esquema_depsito. Sustituimos esquema_depsito:
que si estn en BCNF.
As, la descomposicin de esquema_prestar da como resultado los tres esquemas de relaciones
esquema_sucursal, esquema_info_prstamo y esquema_prstamo_cliente, cada una de las cuales est en BCNF.
No todas las descomposiciones BCNF conservan las dependencias, considrese el esquema:
esquema:_banquero = (nombre_sucursal, nombre_cliente, nombre_banquero)
El conjunto F de dependencias funcionales que necesitamos que se cumpla en esquema_banquero es:
nombre_banquero nombre_sucursal
nombre_cliente nombre_sucursal nombre_banquero
Claramente esquema_banquero no est en BCNF puesto que nombre_banquero no es una superclave.
Si aplicamos el algoritmo de descomposicin BCNF obtenemos:
esquema_sucursal_banquero = (nombre_bamquero, nombre_sucursal)
esquema_banquero_cliente = (nombre_cliente, nombre_banquero)
Los esquemas descompuestos conservan slo nombre_banquero nombre_sucursal y las dependencias
triviales, pero el cierre de {nombre_banquero nombre_sucursal} no incluye nombre_cliente nombre_sucursal
nombre_banquero. La violacin de esta dependencia no puede detectarse a menos que se calcule un producto.
Encontramos que las restricciones F1 y F2 de F a cada uno de los esquemas son las siguientes, en su
recubrimiento cannico:
F1 = {nombre_banquero nombre_sucursal}
F2 = (slo se cumplen dependencias triviales es esquema_banquero_cliente)
As un recubrimiento cannico para el conjunto F es F1.
Es fcil ver que la dependencia nombre_sucursal nombre_banquero no est en F
+
aunque si est en F
+
. Por
tanto, F
+
F
+
y la descomposicin no conserva las dependencias. Adems, demuestra que no siempre es posible
satisfacer los tres objetivos de diseo:
BCNF Producto sin prdida Conservacin de dependencias
6.2.3. Tercera forma normal.
En aquellos casos en los que no pueden satisfacerse los tres criterios de diseo, abandonamos BCNF y
aceptamos una forma normal ms dbil llamada tercera forma normal (3NF). Veremos que siempre es posible
encontrar una descomposicin de producto sin prdida que conserve las dependencias que estn en 3NF.
BCNF requiere que todas las dependencias no triviales sean de la forma , donde es una superclave. NF
hace un poco menos estricta esta restriccin permitiendo las depepndencias funcionales no trivilaes cuyo lado izquierdo o
sea una superclave.
Un esquema de relaciones R est en 3NF con respecto a un conjunto F de dependencias funcionales si para
todas las dependencias en F
+
de la forma , donde R y R, por lo menos se cumple una de las condiciones
siguientes:
n es una depeendencia funcional trivial.
n es una superclave de R.
n Cada atributo A en est contenido en una clave candidata de R.
La definicin de 3NF permite ciertas dependencias funcionales que no se permitan en BCNF. Una dependencia
que satisface slo la tercera condicin de la definicin se llama dependencia transitiva.
Obsrvese que si un esquema de relaciones est en BCNF, entonces todas las dependencias funcionales son de
la forma la superclave determina un conjunto de atributos, o la dependencia es trivial. As, un esquema BCNF no
puede tener ninguna dependencia transitiva. Como resultado, todo esquema BCNF est en 3NF.
Volvamos al ejemplo esquema_banquero. Este esquema no tiene una descomposicin BCNF de producto sin
prdida que conserve las dependencias, pero si est en 3NF. Obsrvese que {nombre_cliente, nombre_sucursal} es una
clave candidata de esquema_banquero; as, el nico atributo que no est contenido en una calve candidata es
nombre_banquero. La nica dependencia funcional no trivial de la forma nombre_banquero es:
Puesto que {nombre_cliente, nombre_sucursal} es una clave candidata, esta dependencia no viola la definicin
de 3NF.
Ahora mostramos el algoritmo que encuentra una descomposicin en 3NF de producto sin prdida que
conserva las dependencias. El hecho de que cada esquema de relaciones Ri est en 3NF se sigue directamente del requisito
Bases de Datos
56
de que el conjunto F de dependencias funcionales est en forma cannica. El algoritmo asegura la conservacin de las
dependencias construyendo explcitamente un esquema para cada dependencia dada. Asegura la descomposicin de
producto sin prdida garantizando que por lo menos un esquema contiene una clave candidata del esquema que se est
descomponiendo.
Sea Fc un recubrimiento cannico de F;
i:=0;
for each dependencia funcional en Fc do
if ninguno de los esquemas Rj 1ji contiene then
begin
i:= i +1;
Ri:= ;
end
if ninguno de los esquemas Rj 1ji contiene una clave candidata de R then
begin
i:= i +1;
Ri:= cualqueir clave candidata de R;
end
return (R1, R2, , Ri)
Para ilustrar el algoritmo, considrese el esquema:
esquema_info_banquero = (nombre_sucursal, nombre_cliente, nombre_banquero, nmero_oficina)
y las dependencias funcionales:
nombre_banquero nombre_sucursal nmero oficina
En bucle for del algoritmo hace que incluyamos los siguientes esquemas en la descomposicin:
esquema_oficina_banquero = ( nombre_banquero, nmero_oficina)
esquema_banquero = (nombre_cliente, nombre_sucursal, nombre_banquero)
Puesto que esquema_banquero contiene una clave candidata de esquema_info_banquero, hemos hecho el
proceso de descomposicin.
6.2.4. Comparacin de BCNF y 3NF.
Hemos visto dos formas normales: 3NF y BCNF. 3NF tiene la ventaja de que sabemos que siempre es posible
obtener un diseo 3NF sin sacrificar un producto sin prdidas o la conservacin de las dependencias, pero tiene una
desventaja, si no eliminamos todas las dependencias transitivas, puede ser necesario utilizar valores vacos para
representar algunas de la relaciones significativas entre los datos, y est el problema de la repeticin de la informacin.
Si no vemos obligados a elegir entre BCNF y la conservacin de las dependencias con 3NF, generalmente es
preferible optar por 3NF. Si no podemos probar la conservacin de las dependencias eficientemente, pagamos un alto
precio en el rendimiento del sistema, o un riesgo en la integridad de la BD.
Con tales alternativas, la cantidad limitada de redundancia impuesta por las dependencias transitivas permitida
en 3NF es la menos mala. As pues, normalmente elegimos asegurar la conservacin de las dependencias y sacrificar
BCNF.
Para resumir, decimos que el objetivo de un diseo de BD relacional es:
BCNF Producto sin prdida Conservacin de dependencias
Si no podemos lograr esto, aceptamos:
3NF Producto sin prdida Conservacin de dependencias
6.3. Normalizacin por medio de dependencias multivaluadas.
Hay esquemas de relaciones que estn en BCNF, las cuales no parecen estar suficientemente normalizadas el
sentido de que todava padecen el problema de la repeticin de la informacin. Supongmos que en algn diseo
alternativo del sistema bancario tenemos el esquema:
esquma_BC = (nmero_prstamo, nombre_cliente, calle, ciudad_cliente)
que es un esquema no BCNF debido a la dependencia funcional nombre_cliente calle ciudad_cliente, y al hecho de
que nombre_cliente no es una clave de esquema_BC. Sin embargo, supongamos que el banco atrae a clientes ricos con
varias direcciones. Entonces no queremos que se cumpla la dependecnia anterior. Si eliminamos esta dependencia
funcional, encontramos que esquema BC est en BCNF con respecto al conjunto modificado de dependencias
funcionales. A pesar del hacho de que esquema_BC esta ahora en BCNF, todava tenemos el problema de la repeticin
de la informacin.
Para tratar esto, debemos definir una nueva forma de restriccin, llamada dependencia multivaluada, y las usaremos para
definir una forma normal de esquemas de relaciones llamada cuarta forma normal (4NF), que es ms restrictiva que
BCNF, ya que cada esquema 4NF est tambin en BCNF, pero no ocurre lo mismo a la inversa.
57
6.3.1. Dependencias multivaluadas.
Las dependencias funcionales excluyen el que ciertas tuplas estn en una relacin. Si AB, entonces no
podemos tener dos tuplas con los mismos valores en A y distintos en B. Las dependencias multivaluadas no excluyen la
existencia de ciertas tuplas, en cambio exigen que otras tuplas de una forma determinada estn presentes en la relacin.
Por esta razn las dependencias funcionales se conocen como dependencias generadoras de igualdad y las
multivaluadas como dependencias generadoras de tuplas.
Sea R un esquema de relaciones y sea R y R. La dependencia multivaluada
se cumple en R si en cualquier relacin legal r(R ), para todos los pares de tuplas t1 y t2 en r tales que t1[]=t2[], existen
las tuplas t3 y t4 en r tales que:
t1[] = t2[] = t3[] = t4[]
t3[] = t1[]
t3[R-] = t2[R-]
t4[] = t2[]
t4[R-] = t1 [R-]
Como ejemplo, damos un cuadro tabular de t1, t2, t3 y t4.
R--
t1
t2
a1ai
a1ai
ai+1aj
bi+1bj
aj+1an
bj+1bn
t3
t4
a1ai
a1ai
ai+1aj
bi+1bj
bj+1bn
aj+1an
Intuitivamente, la dependencia multivaluada dice que la relacin entre y es indepepndiente de la
relacin entre y R-. Si todas las relaciones del esquema R satisfacen la dependencia multivaluada , entonces
es una dependencia multivaluada trivial del esquema R. As, es trivial si o =R.
Para ilustrar la diferencia entre dependencias funcionales y multivaluadas, considrese el
esquema_BC=(nmero_prstamo, nombre_cliente, calle, ciudad_cliente). Debemos repetir el nmero de prstamo una
vez por cada direccin del cliente, y debemos repetir la direccin por cada uno de los prstamos que tiene el cliente. esta
repeticin no es necesaria, ya que la relacin entre un cliente y su direccin es independiente de la relacin entre ese cliente
y un prstamo. Si un cliente tiene un prstamo, queremos que ese prstamo est asociado con todas las direcciones del
cliente. As, la siguiente relacin es ilegal:
Nmero_prstamo Nombre_cliente Calle Ciudad_cliente
23
27
Smith
Smith
North
Main
Rye
Manchester
Para hacer que esta relacin sea legal, necesitamos aadir las tuplas (23, Smith, Main, Manchester) y (27, Smith,
North, Rye).
Comparando el ejemplo anterior con la definicin de dependencia multivaluada, vemos que queremos que la
dependencia multivaluada nombre_cliente calle ciudad_cliente se cumpla. La dependencia multivaluada
nombre_cliente nmero_prstamo, tambin se cumplir, porque como veremos son equivalentes.
Como en el caso de dependencias funcionales, usaremos dependencias multivaluadas de dos formas:
n Para probar relaciones para determinar si son legales bajo un conjunto dado de dependencias funcionales y
multivaluadas.
n Para especificar restricciones del conjunto de relaciones legales. Por tanto, slo nos preocuparmos de las
relaciones que satisfagan un conjunto de dependencias funcionales y multivaluadas.
Ntese que si una relacin r no satisface una dependencia multivaluada dada, podemos construir una relacin r
que satisfaga la dependencia multivaluada aadiendo tuplas a r.
6.3.2. Teora de dependencias multivaluadas.
Como en le caso de las dependencias funcionales y de 3NF y de BCNF, necesitaremos dependencias
multivaluadas que implica lgicamente un conjunto dado de dependencias multivaluadas.
Sea D un conjunto de dependencias funcionales y multivaluadas. El cierre D
+
de D es el conjunto de todas las
dependencias funcionales y multivaluadas que D implica lgicamente. Podemos calcular D
+
a partir de D usando las
definiciones formales de dependencias funcionales y multivaluadas. Sin embargo, normalmente es ms fcil deducir los
conjuntos de dependencias usando un sistema de reglas de inferencia.
La lista siguiente de reglas de inferencia para dependencias funcionales y multivaluadas es segura y completa, es
decir, segura porque no generan dependencias que D no implique lgicamente, y comlpeta porque nos permiten generar
todas las dependencias de D
+
. Las tres primeras son los axiomas de Armstrong ya conocidos.
n Regla de reflexividad. Si es un conjunto de atributos y entonces .
n Regla de aumento. Si se cumple y es un conjunto de atributos, entonces se cumple .
n Regla de transitividad. Si se cumplen y , entonces se cumple .
n Regla de complementacin. Si se cumple , entonces se cumple R--.
Bases de Datos
58
n Regla de aumento multivaluada. Si se cumple y R y , entonces se cumple .
n Regla de transitividad multivaluada. Si se cumple y , entonces se cumple -.
n Regla de repeticin. Si se cumple , entonces se cumple .
n Regla de condensacin. Si se cumple y y existe tal que R y = y , entonces se
cumple .
Podemos simplificar el clculo del cierre utilizando las siguientes reglas:
n Regla de unin multivaluada. Si se cumple y , entonces se cumple .
n Regla de interseccin. Si se cumplen y , entonces se cumple .
n Regla de diferencia. Si se cumplen y , entonces se cumplen y .
Apliquemos estas reglas al siguiente ejemplo. Sea R=(A, B, C, G, H, I) con el conjunto de dependencias
D={AB, BHI, CGH}. Ahora listamos algunos miembros de D
+
.
ACGHI: Puesto que AB, la regla de complementacin implica que AR-B-A. R-B-A=CGHI,
por tanto, ACGHI.
AHI: Puesto que AB y BHI, la regla de transitividad multivaluada implica AHI-B. Puesto
HI-B=HI, AHI.
BH: Para demostrar esto nocesitamos aplicar la regla de condensacin. Se cumple BHI. Puesto que
HHI y CGH y CGHI=, se satisface el enunciado de la regla de condensacin si es B, es HI, es CG y es
H. Se concluye que BH, y por la regla de repeticin BH.
ACG: Ya sabemos que ACGHI, y que AHI. Por la regla de diferencia ACGHI -HI, puesto
que CGHI-HI=CG, ACG.
6.3.3. Cuarta forma normal.
Volvamos al ejemplo esquema_BC=(nmero_prstamo, nombre_cliente, calle, ciudad_sucursal) en el que se
cumple la dependencia multivaluada nombre_clientecalle ciudad_cliente, pero no se cumplen dependencias
funcionales no triviales. Vimos anteriormente que, aunque esquema_BC est en BCNF, no es un diseo ideal, puesto
que debemos repetir la informacin de la direccin de un cliente para cada prstamo. Podemos usar la dependencia
multivaluada dada para mejorar el diseo de la BD, descomponiendo esquema_BC en una descomposicin de cuarta
forma normal (4NF).
Un esquema de relaciones R est en 4NF con respecto a un conjunto D de dependencias funcionales y
multivaluadas si para todas las dependencias multivaluadas en D
+
de la forma , donde R y R, se cumple
por lo menos una de las siguientes condiciones:
n es una dependencia multivaluada trivial
n es una superclave del esquema R.
Un diseo de BD est en 4NF si cada miembro del conjunto de esquemas de relaciones que comprende el
diseo est en 4NF.
La definicin de 4NF es distinta de la definicin de BCNF slo en el uso de dependencias multivaluadas en vez
de dependencias funcionales. Todo esquema 4NF est en BCNF, ya que si un esquema R no est en BCNF, entonces
existe una dependencia funcional no trivial que se cumple en R, donde no es una superclave. Puesto que
implica , por la regla de repeticin, R no puede estar en 4NF.
La analoga entre 4NF y BCNF se aplica al algoritmo para descomponer un esquema en 4NF, es idntico al
algoritmo de descomposicin en BCNF excepto en el uso de dependencias multivaluadas en vez de funcionales.
resultado := {R};
listo := falso;
calcular F
+
;
while (not listo) do
if (existe un esquema Ri en resultado que no est en 4NF) then begin
sea una dependencia multivaluada no trivial que se cumple
en Ri tal que Ri no est en F
+
, y =;
resultado := (resultado - Ri) (Ri-) (, );
end
eslse listo := verdadero;
Si aplicamos el algoritmo a esquema:_BC, encontramos que nombre_clientenmero_prstamo es una
dependencia multivaluada no trivial y que nombre_cliente no es una superclave de esquema_BC. Siguiendo el algoritmo
descomponemos esquema_BC en:
esquema_cliente = (nombre_cliente, calle, ciudad_cliente)
Este par de esquemas que estn en 4NF elimina el problema de la redundancia de esquema_BC.
Al igual que el caso en que se trataban nicamente dependencias funcionales, tambin estamos interesados en
las descomposiciones de producto sin prdida y que conservan las dependencias.. El siguiente hecho sobre dependencias
multivaluadas y productos sin prdida muestra que el algoritmo anterior genera solamente descomposiciones de
producto sin prdida.
59
Sea R un esquema de relaciones y D un conjunto de dependencias en R. R1 y R2 forman una descomposicin
de R. Esta es una descomposicin de producto sin prdida de R si, y slo si, por lo menos una de las dependencias
multivaluadas siguientes est en D
+
:
R1R2R1 R1R2R2
Recurdese que si R1R2R1 o R1R2R2, entonces R1 y R2 son una descomposicin de producto sin
prdida de R. El hecho anterior referente a las dependencias multivaluadas es una sentencia ms general de los productos
sin prdida. Dice que para cada descomposicin de producto sin prdida de R en dos esquemas R1 y R2, se debe cumplir
una de las dos dependencias R1R2R1 o R1R2R2.
La cuestin de la conservacin de las dependencias cuando tenemos dependencias multivaluadas no es tan
sencilla como en el caso de las funcionales. Sea R un esquema de relaciones y sea R1, R2, , Rn una descomposicin de R.
Para un conjunto F de dependencias funcionales, la restriccin Fi de F a Ri es todas las dependencias funcionales en F
+
que incluyen nicamente atributos de Ri. Ahora considrese un conjunto D de dependencias funcionales y
multivaluadas. La restriccin de D a Ri es el conjunto Di, que consta de:
n Todas las dependencias funcionales en D
+
que incluyen nicamente atributos de Ri
n Todas las dependencias multivaluadas de la forma Ri, donde Ri y est en D
+
.
Una descomposicin del esquema R en las planificaciones R1, R2, , Rn es una descomposicin que conserva
las dependencias con respecto a D si para cada conjunto de relaciones r1(R1), r2(R2), , rn(Rn) tal que para todo i, ri
satisface Di, existe una relacin r(R ) que satisface D y para la cual ri=Ri(r ) para todo i.
Apliquemos el algoritmo de descomposicin 4NF al esquema R=(A, B,C,G,H,I) con el conjunto de
dependencias D={AB, BHI, CGH}.
R no est en 4NF. Obsrvese que AB no es trivial, sin embargo A no es una superclave. Usando A en la
primera iteracin del bucle while, sustituimos R por dos esquemas (A, B) y (A, C, G, H, I). (A, B) esta en 4NF, ya que
todas las dependencias multivaluadas que cumplen (A, B) son triviales. Sin embargo, (A, C, G, H, I) no est en 4NF.
Aplicando la dependencia CGH, sustituimos el esquema por (C, G, H) y (A, C, G, I). El primero est en 4NF, ya
que AHI est en D
+
. Por tanto AI est es la restriccin D a (A, C, G, I). As, en una tercera iteracin del bucle
while, sustituimos (A, C, G, I) por (A, I) y (A, C, G).
Entonces termina el algoritmo y la descomposicin 4NF resultante es {(A, B), (C, G, H), (A, I), (A, C, G)}
Esta descomposicin 4NF no conserva las dependencias ya que falla en la conservacin de BHI.
Considrense las siguientes relaciones:
r1 r2 r3 r4
A B C G H A I A C G
a1
a2
b1
b1
c1
c2
g1
g2
h1
h2
a1
a2
i1
i2
a1
a2
c1
c2
g1
g2
como resultado de una proyeccin de la descomposicin de una relacin en (A, B, C, G, H, I). La restricin de D a (A,
B,) es AB y algunas dependencias triviales., y es fcil ver que se satisface, ya que no hay dos valores de a iguales.
Obsrvese que r2 satisface todas las dependencias funcionales y multivaluadas ya que no hay dos tuplas en r2 que tengan
el mismo valor en ningn atributo. Lo mismo puede decirse de la otras dos relaciones. Por tanto, la versin
descompuesta de la BD satisface todas las dependencias en la restriccin de D. Sin embargo, no hay ninguna relacin r en
(A, B, C, G, H, I) que satisfaga D y se descomponga en esas cuatro relaciones. Ya que r=r1| x| r2| x| r3| x| r4. La relacin
r no satisface BHI. Cualquier relacin s que contiene a r y satisface BHI debe incluir la tupla (a2, b1, c2, g2, h1, i1).
Sin embargo CGH(s) incluye una tupla (c2, g2, h1) que no est en r2. As, la descomposicin falla al detectar una violacin
de BHI.
Hemos visto que si nos dan un conjunto de dependencias funcionales y multivaluadas, resulta provechoso
encontrar un diseo de BD que se ajuste a los tres criterios siguientes:
4NF Conservacin de dependencias Producto sin prdida
Si todo lo que tenemos son dependencias funcionales, el primer criterio es justo el de BCNF.
Tambin hemos visto que no siempre es posible lograr estos tres criterios. Cuando no se puedan lograr,
abandonamos el objetivo de 4NF y aceptamos BCNF o incluso 3NF, si es necesario para asegurar la conservacin de las
dependencias.
6.4. Normalizacin por medio de dependencias de interseccin.
La propiedad de producto sin prdida es una de las diversas caractersticas de un buen diseo de BD. De hecho,
esta propiedad es esencial, ya que sin ella se pierde informacin. Cuando restringimos el conjunto de relaciones legales a
aquellas que satisfacen un conjunto de dependencias funcionales y multivaluadas, podemos utilizar estas dependencias
para mostrar que ciertas descomposiciones son de producto sin prdida.
Debido a la importancia de este concepto, es til poder limitar el conjunto de relaciones legales sobre un
esquema R a aquellas relaciones para las que una descomposicin dada es una descomposicin de producto sin prdida.
Definimos una restriccin de este tipo, llamado dependencia de interseccin, que llevan a otra forma normal llamada
forma normal de proyecto producto.
6.4.1. Dependencias de interseccin.
Bases de Datos
60
Sea R un esquema de relaciones y sea R1, R2, , Rn una descomposicin de R. Se utiliza la dependencia de
interseccin *(R1, R2, , Rn) para restringir el conjunto de relaciones legales a aquellas para las cuales R1, R2, , Rn es una
descomposicin de producto sin prdida de R. Formalmente, si R= R1 R2 Rn decimos que una relacin r(R )
satisface la dependencia de interseccin *(R1, R2, , Rn) si:
r = R1(r )| x| R2(r )| x| | x| Rn(r )
Una dependencia de interseccin es trivial si una de las Ri es R.
Considrese la dependencia de interseccin *(R1, R2) en el esquema R. Esta dependencia requiere que para todas
las r(R ) legales:
r = R1(r )| x| R2(r )
Sea R una relacin que contiene las dos tuplas t1 y t2 definida como sigue:
t1[R1-R2]=(a1, a2, , ai) t2[R1-R2]=(b1, b2, , bi)
t1[R1R2]=(ai+1, , aj) t2[R1R2]=(ai+1, , aj)
t1[R2-R1]=(aj+1, , an) t2[R2-R1]=(bj+1, , bn)
As, t1[R1R2]= t2[R1R2], pero t1 y t2 tienen valores diferentes en todos los demas atributos. Vamos a calcular
R1(r )| x| R2(r ). Cuando calculamos el producto, obtenemos dos tuplas adicionales, que son t3 y t4.
Si se cumple *(R1, R2), siempre que tengamos las tuplas t1 y t2 debemos tener tambin t3 y t4. As vemos una
representacin tabular de la dependencia de interseccin *(R1, R2).
R1-R2 R1R2
R2-R1
t1
t2
a1, a2, , ai
b1, b2, , bi
ai+1, , aj
ai+1, , aj
aj+1, , an
bj+1, , bn
t3
t4
a1, a2, , ai
b1, b2, , bi
ai+1, , aj
ai+1, , aj
aj+1, , an
bj+1, , bn
De hecho, *(R1, R2) no es ms que otra forma de expresar R1R2R1. Usando las reglas de
complementacin y aumento para dependencias multivaluadas, podemos demostrar que R1R2R1 implica que
R1R2R2. As, *( R1, R2) es equivalente a R1R2R2.
Toda dependencia de producto de la forma *( R1, R2) es equivalente a una dependencia multivaluada. Sin
embargo, hay dependencias de producto que no son equivalentes a una dependencia multivaluada. El ejemplo ms
sencillo de una dependencia de ste tipo est en el esquema R=(A, B, C). La dependencia de producto *((A, B), (B, C),
(A, C)) no es equivalentea ninguna coleccin de dependencias multivaluadas.
*((A, B), (B, C), (A, C)) r(A, B, C)
A B C A B C
a1
a2
b1
b1
c2
c1
a1
a2
b1
b1
c2
c1
a1
a1
b2
b1
c1
c1
a1
a1
b2
b1
c1
c1
Para ver que ningn conjunto de dependencias multivaluadas implca lgicamente a ((A, B), (B, C), (A. C)),
considrese una relacin r(A, B, C). La relacin r satisface la dependencia de producto *((A, B), (B, C), (a, C)), como
puede verificarse calculando:
AB(r )| x| BC(r )| x| AC(r )
y demostrando que el resultado es exactamente r. Sin embargo, r no satisface ninguna dependencia multivaluada que no
sea trivial. Para ver esto, comprubese que r no satisface ninguna de AB, AC, BA, BC, CA,
CB.
As como una dependencia multivaluada es una forma de expresar la independencia de un par de relaciones,
una dependencia de producto es una forma de expresar que todas las relaciones de un conjunto son independientes.
Esta nocin de independencia de relaciones es una consecuencia natural de la forma en la que generalmente definimos
una relacin.
Considrese esquema_prestamo = ( nombre_sucursal, nmero_prstamo, nombre_cliente, cantidad).
Podemos definir una relacin prstamo como el conjunto de todas las tuplas de esquema_prstamo tales que:
- El prstamo representado por nmero_prstamo lo haga la sucursal nombre_sucursal.
- El prstamo representado por nmero_prstamo lo reciba el cliente nombre_cliente.
- El prstamo representado por nmero_prstamo sea por cantidad$.
Esta definicin de la relacin prstamo es una conjuncin de tres predicados. Sorprendentemente, puede
demostrarse que esta definicin intuitiva de prstamo implica lgicamente la dependencia de producto
*((nmero_prstamo, nombre_sucursal), (nmero_prstamo, nombre_cliente), (nmero_prstamo, cantidad)).
As, las dependencias de producto tienen un atractivo intuitivo y corresponden a uno de los tres criterios de un
buen diseo de una BD.
Para dependencias funcionales y multivaluadas, fue posible dar un sistema de reglas de inferencia seguras y
completas. Desafortunadamente, no se conoce un tipo de reglas as para dependencias de interseccin.
6.4.2. Forma normal de proyecto-producto.
61
Un esquema de relaciones R est en forma normal de proyecto-producto (PJNF) con respecto a un conjunto D
de dependencias funcionales, multivaluadas y de interseccin si para todas las dependencias de D
+
de la forma *(R1, R2,
, Rn) donde cada RiR y R=R1R2Rn, se cumple por lo menos una de las siguientes condiciones:
n *(R1, R2, , Rn) es una dependencia de producto trivial.
n Cada Ri es una superclave de R.
Un diseo de BD est en PJNF si cada miembro del conjunto de esquema de relaciones que comprende el
diseo est en PJNF. PJNF se llama en ocasiones quinta forma normal (5NF).
Volvamos al ejemplo bancario, dada la dependencia de producto *(nmero_prstamo, cantidad),
esquema_prstamo no est en PJNF. Para poner esquema_prstamo en PJNF debemos descomponerla en las tres
planificaciones especificadas por la dependencia de producto: (nmero_prstamo, nombre_sucursal),
(nmero_prstamo, nombre_cliente) y (nmero_prstamo, cantidad).
Puesto que cada dependencia multivaluada es tambin una dependencia de interseccin, es fcil ver que cada
esquema PJNF est tambin en 4NF. As, en general, no es posible encontrar una descimposicin que conserve las
dependencias para un esquema dado en PJNF.
6.5. Forma normal de dominio-clave.
Hemos enfocado la normalizacin a la definicin de una forma de restriccin (dependencia funcional,
multivaluada o de interseccin) y despus al uso de esa forma de restriccin para definir una forma normal. La forma
normal de dominio-clave est basada en tres nociones:
n Declaracin de dominio. Sea A un atributo, y sea dom un conjunto de valores. La declaracin de dominio
Adom requiere que el valor de A de todas las tupas sean valores de dom.
n Declaracin de clave. Sea R un esquema de relaciones en que KR. La declaracin de clave key (K) requiere
que K sea una superclave de R, es decir KR. Obsrvese que todas las declaraciones de clave son
dependencias funcionales, pero no todas las dependencias funcionales son declaraciones de clave.
n Restriccin general. Una restriccin general es un predicado en el conjunto de todas las relaciones de un
esquema dado. Las dependencias que hemos estudiado son ejemplos de restricciones generales. En general,
una restriccin general es un predicado expresado es un predicado expresado en alguna forma previamente
establecida, como en lgica de primer orden.
Ahora damos un ejemplo de una restriccin general que no es una dependencia de las estudiadas. Supngase
que todas las cuentas cuyo nmero_cuenta empieza por 9 son cuentas especiales de alto inters con un saldo mnimo de
2500$. Entonces incluiramos como restriccin general si el primer dgito de t[nmero_cuenta] es 9, entonces
t[saldo]2500.
Las declaraciones de dominio y las relaciones de clave son fciles de probar. Sin embargo, las restricciones
generales pueden ser extremadamente costosas de probar. El propsito de un diseo de BD en forma normal de
dominio-clave es permitir que las restricciones generales se prueben usando solamente las testricciones de dominio y
clave.
Formalemente, sea D un conjunto de restricciones de dominio y sea K un conjunto de restricciones de clave
para una planificacin de relaciones R. G representa las restricciones generales de R. El esquema R est en forma normal
de dominio-clave (DKNF) si DK implica lgicamente a G.
Volvamos a la restriccin general que dimos arriba para las cuentas. La restriccin implica que el diseo de BD
no est en DKNF. Para crear un diseo DKNF necesitamos dos esqumas en lugar de esquema_info_cuenta:
esquema_cuenta_regular = (nombre_sucursal, nmero_cuenta saldo)
esquema_cuenta_especial = (nombre_sucursal, nmero_cuenta, saldo)
Conservamos todas las dependencias que tuvimos en esquema_info_cuenta como lmites generales. Las
restricciones de dominio para esquema_cuenta_especial exigen que para cada cuenta: el nmero de cuenta empiece por 9 y
que el saldo sea mayor de 2500. Las restricciones de dominio de esquema_cuenta_regular exigen que nmero_cuenta no
empiece por 9. El diseo que resulta est en DKNF aunque la demostracin est mas all de este texto.
Comparemos DKNF con las otras formas normales que hemos estudiado. Bajo las otras formas normales, no
consideramos las restricciones de dominio, supusimos que el dominio de cada atributo era infinito. Permitimos las
restricciones de clave, de hecho permitimos las dependencias funcionales. Para cada forma normal permitimos una forma
restringida de restriccin general, como son un conjunto de dependencias. As, podemos volver a escribir las definiciones
de PJNF, 4NF, BCNF y 3NF de una forma que las presenta como casos especiales de DKNF.
La siguiente es una reexpresin inspirada en DKNF de la definicin de PJNF. Sea R=(A1, A2, , An) un
esquema de relaciones, dom(Ai) representa el dominio del atributo Ai, y todos estos dominios son infinitos. Entonces
todas las restricciones de dominio D son de la forma Aidom(Ai). Sean las restricciones genrales un conjunto G de
dependencias funcionales, multivaluadas o de interseccin. Si F es el conjunto de dependencias funcionales en G, sea el
conjunto K de restriccin de clave aquellas dependencias funcionales no triviales de F
+
de la forma R. El esquema R
est en PJNF si, y slo si, est en DKNF con respecto a D, K y G.
Una consecuencia de DKNF es que se eliminan todas las anomalas de insercin y supresin.
DKNF representa una ltima forma normal, ya que permite restricciones arbitrarias adems de dependencias;
sin embargo, permite pruebas eficientes de estas restricciones. Si un esquema no est en DKNF podemos lograr que lo
est mediante descomposicin, pero tales descomposiciones no siempre conservan dependencias. As, mientras DKNF
es un objetivo del diseador de BD, es posible que sea necesario sacrificarla en un diseo prctico.
Bases de Datos
62
6.6. Enfoques alternativos de diseo de Bases de Datos.
Hemos tomado el enfoque de empezar con un esquema de relaciones sencillo y descomponerlo. Uno de
nuestros objetivos al elegir una descomposicin era que la descomposicin fuese de producto sin prdida.
Considrese una BD en PJNF que presenta una relacin en la que faltan datos, pero deseamos registrar el resto
de los datos. Si calculamos el producto natural de estas relaciones descubrimos que todas las tuplas referentes a la tupla
imcompleta desaparecen. Nos referimos a estas tuplas que desaparecen como tuplas colgantes. Formalmente, sea r1(R1),
r2(R2), , rn(Rn) un conjunto de relaciones. Una tupla t de la relacin ri es una tupla colgante si t no est en la relacin:
R1(r1| x| r2| x| | x| rn)
Las tuplas colgantes pueden presentarse en aplicaciones prcticas de BD. Representan informacin incompleta.
La relacin r1| x| r2| x| | x| rn se llama relacin universal, ya que incluye todos los atributos en el universo definido
por R1R2Rn.
La nica forma en la que podemos escribir una relacin universal para el ejemplo anterior, es incluir valores
nulos en la relacin universal, aunque presentan serias dificultades. Debido a la dificultad de manejar valores nulos,
puede ser deseable ver las relaciones del diseo descompuesto como si representaran a la BD, ms que a la relacin
universal cuyo esquema descompusimos durante el proceso de normalizacin. En el ejemplo, no es posible incluir la
informacin incompleta en la BD sin recurrir a los valores nulos.
As, una descomposicin determinada definen una forma restringida de informacin incompleta que es
aceptable por la BD.
Las formas normales que hemos definido generan buenos diseos de BD desde el punto de vista de la
representacin de informacin incompleta.
En otras palabras, no queremos almacenar datos para los que se desconocen los atributos clave. Obsrvese que
las formas normales que hemos definido no nos permiten almacenar ese tipo de informacin a menos que utilicemos
valores vacos. As, las formas normales permiten la representacin de informacin incompleta aceptable por medio de
tuplas colgantes mientras que prohiben el almacenamiento de informacin incompleta indeseable.
Si permitimos tuplas colgantes en la BD puede ser preferible enfocar de otra manera el diseo de la BD. En vez
de descomponer una relacin universal podemos sintetizar una coleccin de esquemas en forma normal a partir de un
conjunto de atributos dado. Estamos interesados en las formas normales, sin importar si las conseguimos por
descomposicin o sntesis. El enfoque de la descomposicin se comprende mejor y se usa ms extensamente.
Otra consecuencia de este enfoque de diseo de BD es que los nombres de los atributos deben ser nicos en la
relacin universal. No podemos usar nombre para referirnos a nombre:_sucursal y nombre_cliente. generalmente es
preferible utilizar nombre nicos.
La suposicin de nico papel, de que cada nombre de atributo tiene un nico significado en la BD;
generalmente es preferible la reutilizacin del mismo nombre en mltiples papeles. Cuando no se hace la suposicin de
nico papel, el diseador de la BD debe tener especial cuidado al construir un diseo normalizao de BD relacional.
63
Tema 7. Estructura de archivos y sistemas.
65
Tema 7.Estructura de archivos y sistemas.
El objetivo de un DBMS es simplificar y facilitar el acceso a los datos. No se debe cargar innecesariamente a los
usuarios del sistema con los detalles fsicos de la implementacin del sistema. Un factor importante para que el usuario
quede satisfecho con un DBMS es su rendimiento, que depende de la eficiencia de la estructura de datos que se utiliza
para representar la informacin en la BD y de la eficiencia del sistema para operar sobre esas estructuras de datos.
Es preciso alcanzar un equilibrio no slo entre el espacio y el tiempo, sino tambin entre la eficiencia de un tipo
de operacin y la de otro.
7.1. Estructura general del sistema.
En esta seccin dividimos un DBMS en mdulos que tratan cada una de las responsabilidades del sistema
global. El sistema operativo del computador puede proporcionar algunas de las funciones del DBMS. En la mayora de
los casos, slo proporciona nicamente los servicios ms bsicos y el DBMS debe construir sobre esa base. Por tanto,
nuestro tratamiento sobre el diseo del sistema incluir la consideracin del interfaz entre el DBMS y el sistema
operativo.
Un DBMS consta de varios componentes funcionales, entre los que estn:
n El gestor de archivos. Se encarga de asignar el espacio en la memoria del disco y la estructura de datos que
se usa para representar la informacin almacenada en el disco.
n El gestor de registros intermedios buffer. Es responsable de transferir la informacin entre la memoria del
disco y la memoria principal.
n El analizador sintctico (parser) de consultas. Traduce sentencias de un lenguaje de consulta a un lenguaje
de nivel ms bajo.
n El selector de estrategias. Intenta transformar la solicitud del usuario en una forma equivalente pero ms
eficiente.
n El gestor de autorizacin e integridad. Prueba la satisfaccin de la restricciones de integridad y comprueba
que el usuario est autorizado para acceder a los datos.
n El gestor de recuperaciones. Asegura que la BD permanezca en un estado consistente a pesar de que ocurran
fallos en el sistema.
n El controlador de concurrencia. Asegura que las interacciones concurrentes con la BD se llevan a cabo sin
conflictos entre ellas.
Adems, se requieren varias estructuras de datos como parte de la implementacin fsica:
n Archivo de datos. Almacena la BD.
n Diccionario de datos. Almacena informacin acerca de la estructura de la BD, y la informacin de
autorizacin, como las restricciones de clave.
n Indices. Permiten el acceso rpido a datos que tienen determinados valores.
n Datos estadsticos. Almacenan informacin acerca de los datos de la BD. Esta informacin la utiliza el
selector de estrategias.
Bases de Datos
66
En este captulo estudiaremos como pueden implementarse el gestor de archivos, el gestor de buffer, los
archivos de datos y el diccionario de datos.
7.2. Medios de almacenamiento fsico.
En la mayora de los sistemas de computadores existen varios tipos de almacenamiento de datos. Estos
medios de almacenamiento se clasifican segn la velocidad con que pueden tener acceso a los datos, segn el coste por
unidad de datos, y segn la fiabilidad que tienen. Entre los medios con que normalmente se cuenta estn:
n Prximo (cach). Esta es la forma de almacenamiento ms rpida y ms costosa. El tamao de la memoria
cach es muy pequeo y el sistema operativo gestiona su utilizacin. No necesitaremos preocuparnos de la
gestin de la memoria cach en el sistema de BD.
n Memoria principal. Este es el medio de almacenamiento que se emplea para los datos disponibles sobre los
cuales se va a operar. Las instrucciones de mquina de propsito general operan sobre la memoria principal.
Aunque puede contener varios megabytes, casi siempre es demasiado pequea para almacenar la BD entera.
Normalmente el contenido de la memoria principal se pierde si hay un corte de corriente o si se cae el
sistema.
n Almacenamiento en disco. Este es el medio principal para el almacenamiento de datos a largo plazo. Lo
comn es que toda la BD est almacenada en disco. Los datos deben trasladarse del disco a la memoria
principal para poder operar sobre ellos, despus de realizar las operaciones, deben devolverse al disco. El
almacenamiento en disco se denomina almacenamiento de acceso directo, porque es posible leer los datos
en disco en cualquier orden. Normalmente, el almacenamiento en disco sobrevive a los cortes de energa y
las cadas de sistema. Los dispositivos de almacenamiento en disco pueden fallar y destruir los datos, pero
estos fallos son muy poco frecuentes.
n Almacenamiento en cinta. Este tipo de almacenamiento se usa principalmente para copias de seguridad y
datos de archivo. Aunque la cinta es mucho ms barata que el disco, el acceso a los datos es mucho ms
lento, puesto que la cinta debe leerse secuencialmente desde el principio. Por esta razn se denomina
almacenamiento de acceso secuencial, y se usa principalmente para recuperarse de fallos en el disco. Los
dispositivos de cinta son menos complejos que los de disco, por lo que son ms fiables.
Puesto que el almacenamiento en disco es de vital importancia para la implementacin de la BD, examinaremos
las caractersticas de los discos con ms detalle.
La cabeza es un dispositivo que se coloca muy
cerca de la superficie del plato y lee o escribe informacin
codificada magnticamente en el plato. El plato est
organizado en pistas concntricas de datos. El brazo
puede colocarse sobre cualquiera de las pistas. El plato
gira a alta velocidad. Para leer o escribir informacin, el
brazo se coloca sobre la pista correcta, y cuando los
datos a los que se va a acceder pasan por debajo de la
cabeza, se realiza la operacin de lectura o escritura.
Puesto que el plato rota a gran velocidad, no se
requiere mucho tiempo para que todo el contenido de
una pista pase por debajo de la cabeza. Esta cantidad de tiempo se conoce como tiempo de latenciadel disco. El
tiempo en volver a colocar el brazo, el tiempo de bsqueda, aumenta conforme se incrementa la distancia a que debe
moverse el brazo. Resulta til almacenar informacin relacionada en la misma pista o en pistas cercanas fsicamente
siempre que sea posible para minimizar el tiempo de bsqueda.
Existen discos de platos mltiples, denominados paquetes de discos, y de aqu en adelante, cuando usemos el
trmino disco, nos referiremos a discos de platos mltiples..
El impulsor, une todos los brazos y los mueve como una unidad. Cada brazo tiene dos cabezas, una para leer
y escribir en la superficie superior del plato que est bajo la cabeza, y una para leer y escribir en la superficie inferior del
disco que est sobre la cabeza. El conjunto de pistas sobre las que estn colocadas las cabezas forma un cilindro. El
cilindro tiene los datos que pueden accederse sin ningn movimiento del impulsor. Es decir, todos los datos del cilindro
son accesibles dentro del tiempo de latencia del disco. Es eficiente almacenar datos relacionados en el mismo cilindro, o ,
si no es posible, en cilindro prximos entre s.
Los datos se transfieren entre el disco y la memoria principal en unidades llamadas bloques. Un bloque es una
secuencia contigua de bytes de una sola pista de un plato. Si es necesario transferir varios bloques de un cilindro a la
memoria principal, podemos ahorrar tiempo pidiendo los bloques en el orden en que van a pasar por debajo de las
cabezas. Si los bloques requeridos estn en cilindros distintos, resulta ventajoso pedir los bloques en un orden que
minimice el movimiento del impulsor.. La forma ms sencilla de optimizar el tiempo de acceso al bloque es organizar
los bloques en el disco de una forma que corresponda fielmente a la manera en la que esperamos que se acceda a los
datos. Sin embargo, puede ser costoso mantener esta organizacin cuando se inserta o elimina informacin.
7.3. Organizacin de archivos.
Un archivo est organizado lgicamente como una secuencia de registros. Estos registros se asignan a bloques
del disco. Los archivos se dan como construcciones bsicas en los sistemas operativos, por lo que supondremos que
67
existe un sistema de archivos subyacente. Necesitamos considerar formas de representar modelos lgicos de datos en
trminos de archivos.
Aunque los bloques son de tamao fijo, los tamaos de los registros varan. En una BD relacional, las tuplas
de relaciones distintas son ,por lo general, de tamaos distintos. En una BD de datos de red es probable que el tipo de
registro propietario sea de distinto tamao que el tipo de registro miembro.
Una forma de enfocar la asignacin de la BD a los archivos a almacenar en un archivo dado solamente registros
de una longitud fija. Una alternativa es estructurar los archivos de una forma tal que podamos acomodar registros de
varias longitudes diferentes. Los archivos de registros de longitud fija son ms fciles de implementar.
7.3.1. Registros de longitud fija.
Como ejemplo, consideremos un archivo de registros depsito, definidos:
type depsito = registro
nombre_sucursal: char (20);
nmero_cuenta: integer;
nombre_cliente: char (20);
saldo: real;
end
Si suponemos que cada carcter ocupa un byte, un entero cuatro, y un real ocho, el registro depsito tiene 52
bytes. Un enfoque sencillo es utilizar los primeros 52 bytes para el primer registro, los siguientes 52 para el segundo y as
sucesivamente. Sin embargo este enfoque presenta dos problemas:
1.- Es difcil eliminar un registro de esta estructura. El espacio que ocupa el registro que se va a eliminar debe
llenarse con otro registro, o debemos marcarlo para que sea ignorado.
2.- A menos que el tamao del bloque sea mltiplo de 52, algunos registros pasarn los lmites del bloque, lo
que requerira tener acceso a dos bloques para leer o escribir el registro.
Cuando se elimina un registro podramos mover el registro que le segua un espacio para delante, y as
sucesivamente, pero esto requiere mover muchos registros, o se podra mover el ltimo registro al hueco libre. No es
deseable mover registros para ocupar el espacio que deja libre un registro eliminado, ya que esto requiere tener acceso a
bloques adicionales. Puesto que las inserciones suelen ser ms frecuentes que las eliminaciones, es aceptable dejar abierto
el espacio que ocupa el registro eliminado y esperar una insercin posterior para ocupar el espacio. No basta simplemente
marcar el registro eliminado, ya que no es fcil encontrar el espacio disponible cuando se va a realizar una insercin. Por
tanto, necesitamos introducir una estructura adicional.
Al principio del archivo asignamos un cierto nmero de bytes como encabezamiento del archivo. El
encabezamiento contendr informacin diversa acerca del archivo. Por ahora, todo lo que hace falta almacenar aqu es la
direccin del primer registro cuyo contenido se haya eliminado. Utilizamos este primer registro para almacenar la
direccin del segundo registro disponible, y as, sucesivamente. Podemos considerar estas direcciones almacenadas como
punteros.
Al insertarse un nuevo registro, utilizamos el registro al que apunta el encabezamiento; y ste se cambia para
que apunte al siguiente registro disponible. Si no hay espacio disponible aadimos el registro al final del archivo. El uso
de punteros requiere mucho cuidado en la programacin.
La insercin y eliminacin en archivos de registros de longitud fija es bastante fcil de implementar, porque el
espacio que deja disponible un registro es exactamente el que se necesita para insertar otro. Si permitimos registros de
longitud variable en un archivo, la situacin cambiara, es posible que un registro insertado no quepa en el espacio que
deja libre otro eliminado, o que llene solamente parte del espacio.
7.3.2. Registros de longitud variable.
Los registros de longitud variable se presentan en los DBMS de varias formas:
n Almacenamiento de varios tipos de registros en un archivo.
n Tipos de registros que permiten uno o ms campos de longitudes variables.
n Tipos de registros que permiten campos repetidos.
Existen varias tcnicas para implementar los registros de longitud variable. Para ilustrarlas utilizaremos el
mismo ejemplo. El formato de registro es:
type lista_depsito = record
nombre_sucursal: char (20);
info_cuenta: array [1..] of
record
nmero_cuenta: integer;
nombre_cliente: char (20);
saldo: real;
end
end
Bases de Datos
68
Definimos info_cuenta como un array con un nmero arbitrario de elementos de manera que el tamao del
registro no tiene lmite.
Representacin en cadena de bytes.
Un mtodo sencillo para implementar los registros de longitud variable es aadir un smbolo especial de fin de
registro () al final de cada registro. As podemos almacenar cada registro como una cadena de bytes consecutivos.
La representacin en cadena de bytes tiene varias desventajas, las ms serias son:
1.- No es fcil volver a utilizar el espacio que ocupaba un registro eliminado. Aunque existen tcnicas para
gestionar la insercin y eliminacin, resultan en un gran nmero de fragmentos pequeos de espacio que se desperdician.
2.- En general, los registros no disponen de espacio para crecer. Si un registro de longitud variable se hace ms
largo debe moverse, y si el registro est sujeto, el movimiento resulta costoso.
Por tanto, la representacin en cadena de bytes, normalmente, no se utiliza para almacenar registros de longitud
variable.
Representacin de longitud fija.
Para implementar los registros de longitud variable de manera eficiente en un sistema de archivos, utilizamos
uno o ms registros de longitud fija para representar un registro de longitud variable.
Existen dos tcnicas para implementar archivos de registros de longitud variable utilizando registros de
longitud fija:
n Espacio reservado. Si hay una longitud mxima de registro que nunca se excede, podemos utilizar registros
de longitud fija de esa longitud. El espacio no utilizado se llena con smbolo especial nulo o de fin de
registro.
n Punteros. El registro de longitud variable se representa por una lista de registros de longitud fija
encadenado por medio de punteros.
El mtodo de espacio reservado es til cuando gran parte de los registros es de longitud cercana al mximo. Si
no es as, puede desperdiciarse una cantidad apreciable de espacio.
Para representar el archivo empleando el mtodo de punteros, aadimos un campo que corresponda al
puntero. Utilizamos los punteros solamente para encadenar los registros de una determinada sucursal.
Una desventaja del mtodo de punteros es que desperdiciamos espacio en todos los registros menos en el
primero de la cadena. Es preciso que el primero incluya el valor de nombre_sucursal, pero no los subsiguientes registros.
El espacio desperdiciado es considerable, ya que esperamos que las sucursales tengan gran nmero de cuentas. Para
resolver este problema permitimos dos tipos de bloques en el archivo:
n Bloque ancla. Contiene el primer registro de la cadena.
n Bloque de desbordamiento. Contiene registros que no son el primero.
As, todos los registros dentro de un bloque tienen la misma longitud, aunque no todos los registros del
archivo tienen la misma longitud.
7.4. Organizacin de registros en bloques.
Un archivo puede considerarse como una coleccin de registros. Sin embargo, como los datos se transfieren
entre el disco y la memoria en unidades de bloque, vale la pena asignar los registros a los bloques de tal forma que un
simple bloque contenga registros relacionados entre si. El acceso a disco es generalmente el cuello de botella en el
rendimiento del sistema, una asignacin con cuidado de registros a los bloques puede mejorar significativamente el
rendimiento.
Anteriormente describimos una estructura de archivos en la que toda la informacin relativa alas cuentas de una
sucursal apareca en un registro (longitud variable9. Es fcil agrupar registros de esta manera si la BD nunca cambia. Sin
embargo, supngase que se abre una nueva cuenta. Si estamos utilizando esta estructura, desearamos aadir el registro
que corresponde a esta cuenta al mismo bloque en que estn el resto de las cuentas de la sucursal. Sin embargo, lo ms
probable es que el bloque ya est lleno con registros de cuentas de otras sucursales. Debemos mover algunos de estos
registros o abandonar el objetivo de agrupar los registros que representan a un nico registro de longitud variable.
Ninguna de estas opciones es deseable.
Como alternativa, consideremos una estructura que ocupa un espacio un poco mayor, pero que permite
mejorar la eficiencia de acceso a la informacin. A cada valor de nombre_sucursal le asignamos una cadena de bloques.
Cada cadena de bloques contiene el registro de longitud variable completo para una sucursal. Una cadena consta de
tantos bloques como sean necesarios para representar los datos, pero dos cadenas diferentes nunca comparten bloques.
Las cadenas tienen una estructura ligeramente diferente de las dems estructuras de registros de longitud fija que hemos
utilizado:
n El primer registro de la cadena contiene el valor nombre_sucursal de la cadena.
n Los siguientes registros contienen los campos que se repiten. No hace falta repetir nombre_sucursal.
Obsrvese que hay dos longitudes de registro diferentes en cada cadena. El primer registro y todos los dems.
Puesto que todas las cadenas deben tener nicamente un registro que contenga el valor nombre_sucursal, no hay
problema para realizar inserciones y eliminaciones.
Al crecer una cadena por insercin de registros, puede que se necesite aadirle nuevos bloques. Al eliminar
registros, un bloque podra quedar vaco. Como hicimos en el caso de los registros borrados, podemos mantener una
cadena de bloques disponibles y volver a utilizarlos para otras cadenas que se extiendan ms all de los bloques que
ocupan.
69
Esta estrategia no es la mejor desde el punto de vista de rapidez de acceso. Cuando se hace una busqueda en
una cadena se deben leer todos los bloques. Para minimizar el tiemo que se lleva una bsqueda necesitamos minimizar
el tiempo que lleva transferir estos bloques a la memoria.
Por tanto, conviene que los bloques de una cubeta estn almacenados en el mismo cilindro del disco o en
cilindros adyacentes. Una cubeta es un conjunto de uno o ms bloques encadenados. Si quedara vaco el bloque, sera
preferible que volviera a ser utilizado por la misma cadena que lo contena anteriormente.
En la prctica, no es posible mantener una colocacin perfecta de los bloques en el disco sin dejar vaca una gran
cantidad de espacio. Tarde o temprano, las cadenas rebosarn su cilindro y puede que no exista espacio disponible en
cilindros cercanos. Si la cadena queda tan fragmentada que el rendimiento empieza a disminuir, puede reorganizarse la
BD.
La BD se copia en cinta y se vuelve a cargar con los bloques cambiados de sitio de forma que las cadenas no
queden fragmentadas, y exista un espacio razonable para su crecimiento. Generalmente es necesario prohibir el acceso de
los usuarios a la BD durante estas reorganizaciones.
7.5. Archivos secuenciales.
Un archivo secuencial esta diseado para procesar de manera eficiente registros en un determinado orden
basndose en alguna clave de bsqueda. Para permitir una recuperacin rpida los registros se encadenan por medio de
punteros. El puntero de cada registro apunta al siguiente registro en el orden de la clave de bsqueda. Adems para
minimizar el nmero de accesos a bloque en el procesamiento de archivos secuenciales, los registros se almacenan
fsicamente en el orden de la clave de bsqueda o tan cerca de ste como sea posible.
Es difcil mantener el orden secuencial fsico cuando se insertan o eliminan registros, ya que es costoso mover
muchos registros. La eliminacin puede manejarse utilizando cadenas de punteros, como vimos anteriormente. Para la
insercin aplicamos las siguientes reglas:
1.- Localizar el registro en el archivo que precede al registro que se va a insertar en el orden de la clave de
bsqueda.
2.- Si existe algn registro libre dentro del mismo bloque, se inserta all el nuevo registro. Si no, se inserta un
nuevo bloque de desbordamiento. En cualquier caso, se ajustan los punteros para que los registros queden encadenados
en el orden de la clave de bsqueda.
Si los registros que se necesitan almacenar en bloques de desbordamiento son relativamente pocos, este
enfoque funciona bien. Sin embargo, puede llegar a ocurrir que se pierda totalmente la correspondencia entre el orden de
la clave de bsqueda y el orden fsico, y el procesamiento secuencial llegue a ser mucho menos eficiente. En este punto es
preciso reorganizar el archivo para que quede otra vez en orden secuencial fsicamente. Estas reorganizaciones son
costosas y se hacen en momentos en los que la carga del sistema es baja.
7.6. Asignacin (mapping) de datos relacionales a archivos.
Muchos DBMS relacionales almacenan cada relacin en un archivo separado. Esto permite al DBMS aprovechar
al mximo el sistema de archivos que forma parte del sistema operativo. Normalmente las tuplas de una relacin pueden
representarse como registros de longitud fija, por tanto, las relaciones pueden asignarse a una estructura simple de
archivos. Esta implementacin sencilla se adapta bien a computadores personales, ya que el tamao de la BD es
pequeo, por lo que no se aprovechara una estructura de datos sofisticada. Adems, en algunos computadores
personales es fundamental que el cdigo objeto del DBMS no ocupe mucho espacio, si la estructura de archivos es
simple, se reduce la cantidad de cdigo necesaria para implementar el sistema.
Este enfoque sencillo de la implementacin de BD relacionales se vuelve menos satisfactorio al aumentar el
tamao de la BD. Hemos visto que puede mejorarse el rendimiento si se tiene cuidado al asignar registros a los bloques
y al organizarlos. As, es aparente que una estructura de archivos ms complicada pueda resultar ventajosa.
Sin embargo, muchos DBMS a gran escala no dependen del sistema operativo subyacente para la gestin de
archivos. En vez de ello se asigna un archivo grande del sistema operativo al DBMS. Todas las relaciones se almacenan
en este archivo y se deja la gestin de ste al DBMS. Para ver la ventaja de almacenar muchas relaciones en un archivo,
considrese la siguiente consulta SQL para la BD bancaria:
select nmero_cuenta, nombre_cliente, calle, ciudad_cliente
from depsito, cliente
where depsito,nombre_cliente = cliente.nombre_cliente
Esta consulta calcula un producto de las relaciones depsito y cliente. As, para cada tupla de depsito, el
sistema debe localizar las tuplas de cliente que tengan el mismo en nombre_cliente. Lo ideal sera localizar estos registros
con la ayuda de ndices, que se estudian en el tema siguiente, pero, sin importar la forma en que se hayan localizado estos
registros, es necesario transferirlos del disco a la memoria. En el peor de los casos, cada registro residir en un bloque
diferente, obligando a leer un bloque por cada registro que requiera la consulta.
Como un ejemplo concreto, considrense las relaciones depsito y cliente. Una estructura de archivo diseada
para ejecutar de manera eficiente consultas que impliquen a depsito| x| cliente, almacena las tuplas depsito de cada
nombre_cliente, cerca de la tupla cliente del nombre_cliente correspondiente. Esta estructura mezcla tuplas de dos
relaciones, pero permite el procesamiento eficiente del producto. Cuando se lee una tupla de la relacin cliente, el bloque
completo que contiene esa tupla se copia del disco a la memoria. Puesto que las tuplas depsito correspondientes estn
almacenadas en el disco cerca de la tupla cliente, el bloque que contiene la tupla cliente contiene las tuplas de la relacin
prstamo que se necesitan para procesar la consulta. Si un cliente tiene tantas cuentas que los registros depsito no caben
Bases de Datos
70
en un bloque, los registros restantes aparecern en bloques cercanos. Esta estructura de archivos, llamada agrupacin,
nos permite leer muchos de los registros que se requieren leyendo slo un bloque.
El uso de la agrupacin mejora el procesamiento de un producto especfico, pero resulta en un procesamiento
ms lento de otros tipos de consulta, ya que para localizar todas las tuplas de una nica relacin, necesitamos encadenar
todos sus registros por medio de punteros.
Para determinar cuando conviene utilizar la agrupacin hay que tener en cuenta cuales son los tipos de consulta
que el diseador de la BD cree que van a ser ms frecuentes. Si se utiliza con cuidado la agrupacin, puede mejorar
considerablemente el rendimiento en el procesamiento de consultas.
7.7. Almacenamiento de diccionario de datos.
Hasta ahora slo hemos considerado la representacin de las relaciones mismas. Un DBMS relacional necesita
mantener datos acerca de las relaciones. Esta informacin se denomina diccionario de datos o catlogo de sistema. Entre
los tipos de informacin que el sistema debe almacenar estn: los nombres de las relaciones, los nombres de los
atributos de las relaciones, los dominios de los atributos, los nombres de las vistas definidas y su definicin y las
restricciones de integridad de cada relacin. Adems de esto, muchos sistemas conservan los datos de los usuarios:
nombre de los usuarios autorizados e informacin contable sobre ellos. Adems, en los sistemas que utilizan
estructuras altamente sofisticadas, pueden conservarse datos estadsticos y descriptivos acerca de las relaciones: nmero de
tuplas por relacin y mtodo de almacenamiento para cada relacin.
En el siguiente captulo, veremos que es necesario almacenar informacin acerca de cada ndice de cada relacin:
nombre del ndice, nombre de la relacin que indexa, atributos sobre los que est el ndice y tipo de ndice.
Toda esta informacin constituye una base de datos en miniatura. Algunos DBMS almacenan esta informacin
empleando estructuras de datos y cdigo de propsito especial. Generalmente es preferible almacenar los datos acerca de
la BD en la propia BD. Si se utiliza la BD para almacenar datos del sistema, simplificamos la estructura global del sistema
y permitimos aprovechar toda la capacidad de aquella para agilizar el acceso a los datos del sistema.
La eleccin precisa de como se van a representar los datos por medio de relaciones debe hacerla el diseador del
sistema. Una posible representacin es:
esquema_catlogo_sistemas = (nombre_relacin, numero_de_atributos)
esquema_atributo = (nombre_atributo, nombre_relacin, tipo_dominio, posicin)
esquema_usuario = (nombre_usuario, clave_codificada, grupo)
esquema_ndice = (nombre_ndice, nombre_relacin, tipo_ndice, atributos_ndice)
esquema_vista = (nombvre_vista, definicin).
7.8. Gestin de registros intermedios (buffer).
Ya hemos mencionado la necesidad de utilizar almacenamiento en disco para la BD, y la necesidad de transferir
bloques de datos entre la memoria y el disco. Un objetivo principal de las estructuras de archivo que se presentaron es
minimizar el nmero de bloques a los que se debe acceder. Otra forma de reducir el nmero de accesos a disco es
mantener tantos bloques en memoria como sea posible. El objetivo es incrementar al mximo la posibilidad de que,
cuando se necesite acceder a un bloque, ste ya est en la memoria, y por lo tanto no se requiera acceder al disco.
Puesto que no es posible mantener todos los bloques en memoria, es preciso gestionar la asignacin del
espacio disponible en memoria para almacenamiento de bloques. Los registros intermedios (buffer) son aquella parte de
la memoria principal disponible para almacenar copias de bloques de disco. Siempre se guarda una copia de todos los
bloques en el disco, pero la copia en el disco puede ser una versin antigua de la del bloque distinta de la versin del
buffer. El responsable del subsistema para la asignacin de espacio en el buffer se denomina gestor del buffer.
El gestor de buffer intercepta todas las solicitudes que hace el resto del sistema pidiendo bloques de la BD. Si el
bloque ya est en el buffer, se pasa al solicitante la direccin del bloque en la memoria. Si el bloque no est en el buffer, el
gestor lo lee del disco y lo escribe en el buffer, y pasa la direccin del bloque al solicitante. As, el gestor de buffer es
transparente para aquellos programas del sistema que solicitan bloques del disco. Con el fin de servir adecuadamente al
sistema, el gestor de buffer debe utilizar tcnicas sofisticadas de gestin del buffer:
n Estrategia de reemplazo. Cuando no queda espacio libre en el buffer, debe sacarse un bloque antes de que
pueda escribirse uno nuevo. Los sistemas operativos ms comunes emplean el esquema de menos
recientemente utilizado (LRU). Este enfoque sencillo puede mejorarse en una aplicacin de BD.
n Bloques sujetos. Para que el DBMS pueda recuperarse de cadas, es necesario restringir las oportunidades en
las que se puede grabar un bloque en el disco. Un bloque al que no se permite que se vuelva a grabar en el
disco se dice que est sujeto. Aunque muchos sistemas operativos no soporten bloques sujetos, una
caracterstica as es esencial para la implementacin de un DBMS que sea resistente a las cadas.
n Salida forzada de bloques. Existen situaciones en las que es necesario escribir el bloque en el disco, aunque
no se necesite el espacio que ocupa en el buffer. Esto se denomina salida forzada de un bloque. El requisito
se debe al hecho de que los contenidos de la memoria , y por tanto del buffer, se pierden en una cada
mientras que los datos en disco generalmente sobreviven a ella.
71
El objetivo de una estrategia de reemplazo de bloques en el buffer es la minimizacin de accesos a disco. Los
sistemas operativos utilizan el patrn de referencias anteriores a bloques para predecir las referencias que se harn en el
futuro segn el principio de localidad. La suposicin que se hace es que es probable que se vuelva a hacer referencia a los
bloques a los que se hizo referencia recientemente. Por tanto, si se debe sustituir un bloque, se sustituye aquel al que se
hizo referencia menos recientemente. Esto se denomina esquema de reeemplazo de bloques LRU.
El LRU es un esquema de reemplazo aceptable en sistemas operativos. Sin embargo, un DBMS puede predecir
el patrn de referencias futuras con ms exactitud que un sistema operativo. Las solicitudes que hacen los usuarios al
sistema operativo implican varios pasos, pero muchas veces el DBMS puede determinar por adelantado qu bloques va a
necesitar cada uno de los pasos. As, los DBMS pueden tener informacin referente, por lo menos, del futuro a corto
plazo.
Considrese el procesamiento de un producto natural de dos relaciones, y que para procesarlo, se procesa la
segunda relacin entera por cada tupla de la primera relacin. Supngase que las dos relaciones estn almacenadas en
archivos separados.. Por tanto, una vez que se procese un bloque de la primera relacin, no se va a volver a necesitar hasta
que se procese toda la segunda relacin, por lo que se puede eliminar de la memoria, a pesar de que se uso recientemente.
El gestor del buffer debe recibir instrucciones de dejar libre el espacio que ocupa ese bloque. Esta estrategia de gestin de
buffer se conoce como desechar de inmediato.
Considrense ahora los bloques que contienen tuplas de la segunda relacin. Necesitamos examinar todos
estos bloques una vez por cada tupla de la primera relacin. Cuando se termina el procesamiento de un bloque de la
segunda relacin, sabemos que no volver a ser accedido hasta que todos los dems bloques de esta segunda relacin
sean procesados. Por tanto el bloque de esta relacin que se utiliz el ltimo ser el que tarde ms en ser referenciado, y
bloque ms antiguo ser el primero en ser llamado. Esto es exactamente lo opuesto a la estrategia LRU. De hecho, la
estrategia ptima para sustituir bloques es la estrategia mas recientemente utilizado (MRU). Si es preciso sacar un
bloque del buffer, la estrategia MRU elige el bloque que se utiliz ms recientemente.
Para que la estrategia MRU funcione correctamente en este ejemplo, el sistema debe sujetar el bloque, de la
segunda relacin, que se est procesando en ese momento. Despus de que se haya procesado la ltima tupla del bloque,
se libera y se convierte en el bloque utilizado ms recientemente.
El gestor del buffer puede utilizar informacin estadstica referente a la probabilidad de que una solicitud haga
referencia a una determinada relacin. El diccionario de datos es una de las partes de la BD a la que se accede ms
frecuentemente. Por ello, el gestor de buffer debe procurar no sacar los bloques del diccionario de la memoria. A menos
que otros factores dicten lo contrario. Como puede ser que se acceda al ndice con mayor frecuencia que al mismo archivo,
el gestor del buffer no deber, en general, sacar los bloques de ndice de la memoria mientras tenga alguna alternativa.
La estrategia ideal de reemplazo de bloques de la BD necesita conocer las operaciones que se estn realizando en
ella. No se conoce una sola estrategia que maneje bien todas las situaciones posibles. De hecho, un gran nmero de
sistemas utiliza la estrategia LRU a pesar de sus fallos.
La estrategia que utiliza el gestor de buffer para sustituir los bloques se ve influenciada por otros factores. Si el
sistema est procesando en forma concurrente solicitudes de varios usuarios, puede que el subsistema de control de
concurrencia tenga que retrasar ciertas solicitudes para garantizar la conservacin de la consistencia de los datos. Si el
subsistema de control de concurrencia proporciona informacin al gestor del bufffer acerca de cuales son las solicitudes
que se van a retrasar, el gestor del buffer puede utilizar esta informacin para alterar su estrategia de reemplazo de
bloques. Los bloques que requieren las solicitudes activas (no retrasadas) pueden conservarse en el buffer a expensas de
los bloques que necesitan las solicitudes retrasadas.
El subsistema de recuperacin de cadas impone restricciones muy estrictas sobre la sustitucin de bloques. Si
se ha modificado algn bloque, no se permitir que el gestor del buffer escriba en el disco la nueva versin del bloque del
buffer, ya que esto destruira la versin antigua. En vez de ello, el gestor de bloques debe pedir la autorizacin del
subsistema de recuperacin de cadas antes de grabar el bloque. Es posible que el subsistema de recuperacin de cadas
exija la salida forzada de determinados bloques antes de permitir que se grabe el bloque solicitado.
Tema 8. Indexacin y asociatividad (hashing).
73
Tema 8.Indexacin y asociatividad (hashing).
Muchas consultas hacen referencia a slo una pequea parte de los registros de un archivo. Es ineficiente que el
sistema tenga que leer todos los registros. Lo ideal es que el sistema pueda localizar directamente estos registros. Para
permitir estas formas de acceso diseamos estructuras adicionales que asociamos con archivos. Consideraremos dos
formas generales de atacar ste problema: la construccin de ndices y la construccin de funciones de asociatividad
(hash).
8.1. Conceptos bsicos.
Un ndice de un archivo funciona de manera similar a un catlogo en una biblioteca. Si estamos buscando un
libro por un autor determinado, buscamos en autores y una tarjeta de catlogo nos dice dnde encontrar el libro. Para
facilitarnos la bsqueda, las tarjetas se guardan en orden alfabtico, de forma que no tenemos que comprobar todas para
encontrar la que queremos.
En las BD es posible que estos tipos de ndices sean demasiado grandes para manejarse eficientemente. En vez
de ello, pueden utilizarse tcnicas de indexacin ms sofisticadas. Como alternativa a la indexacin se utilizan funciones
de asociatividad. Consideraremos varias tcnicas tanto de asociatividad como de indexacin. Ninguna de ellas es la
mejor, sino que cada una es ms apropiada para una aplicacin especfica de BD. Cada tcnica debe evaluarse en base a:
n Tiempo de acceso. El tiempo que se tarda en encontrar un dato determinado.
n Tiempo de insercin. El tiempo que se tarda en insertar un dato nuevo. Esto incluye el tiempo que se tarda
en encontrar el lugar correcto, as como el que se tarda en actualizar la estructura de indexacin.
n Tiempo de eliminacin. El tiempo que se tarda en eliminar un dato. Esto incluye el tiempo que se tarda en
encontrar el dato, as como el que se tarda en actualizar la estructura de indexacin.
n Espacio extra. El espacio adicional que ocupa la estructura de indexacin. Siempre que este espacio no sea
muy grande, merece la pena sacrificar el espacio por una mejora en el rendimiento.
Muchas veces queremos tener ms de un ndice o funcin de aosciatividad para un archivo. El atributo o
conjunto de atributos que se usa para buscar registros en un archivo se llama clave de bsqueda.. Obsrvese que sta
definicin de clave difiere de las de clave primaria, clave candidata y superclave.
8.2. Indexacin.
Para pemitir el acceso aleatorio rpido a los registros de un archivo se utiliza una estructura de ndice. Cada
estructura de ndice est asociada con una clave de bsqueda determinada. Si el archivo est ordenado secuencialmente y
elegimos incluir varios ndices en diferentes claves de busqueda, el ndice cuya clave de bsqueda especifca el orden
secuencial del archivo es el ndice primario. Los dems se llaman ndices secundarios. La clave de bsqueda de un
ndice primario es normalmente la clave primaria.
En esta seccin suponemos que todos los archivos estn ordenados secuencialmente y , por tanto, tienen una
clave de bsqueda primaria. Dichos archivos, junto con un ndice primario, se llaman archivos de ndices secuenciales.
Se encuentran entre los esquemas de indexacin ms antiguos usados en los BDMS. Estn diseados para aplicaciones
que requieren tanto un procesamiento secuencial del archivo completo como un acceso aleatorio a registros individuales.
Hay dos tipos de ndices que pueden usarse;
n ndice denso. Aparece un registro ndice para cada valor de la clave de bsqueda en el archivo. El registro
contiene el valor de la clave de bsqueda y un puntero al registro.
n ndice escaso. Se crean registros ndices solamente para algunos de los registros. Para localizar un registro,
encontramos el registro ndice con el valor de la clave de bsqueda ms grande que sea menor o igual que el
valor que estamos buscando. Empezamos en el registro al que apunta el registro ndice y seguimos los
punteros del archivo hasta encontrar el registro deseado.
8.2.1. ndice primario.
Generalmente es ms rpido localizar un registro con un ndice denso que con uno escaso. Sin embargo, los
ndices escasos requieren menos espacio e imponen menos mantenimiento adicional para inserciones y eliminaciones.
Bases de Datos
74
El diseador del sistema debe lograr un equilibrio entre el tiempo de acceso y el espacio extra. Un buen
compromiso es tener un ndice escaso con una entrada de ndice por bloque.
Para que esta tcnica sea completamente general, debemos considerar el caso en el que los registros para un valor
de la clave de bsqueda ocupan varios bloques. Es fcil modificar el esquema para manejar esta situacin.
An cuando utilizamos un ndice escaso, el ndice puede llegar a ser demasiado grande para un procesamiento
eficiente. En la prctica, no es raro tener un archivo con 100.000 registros. Con 10 registros por bloque. Si tenemos un
registro ndice por bloque, el ndice tiene 10.000 registros. Los registros ndice son ms pequeos que los de datos, por
lo que podemos suponer que entran 100 por bloque, as pues el ndice ocupa 100 bloques.
Si un ndice es lo bastante pequeo como para guardarlo en memoria, el tiempo de bsqueda es corto. Sin
embargo, si le ndice es tan grande que debe guardarse en disco, una bsqueda puede ser costosa.
Para resolver este problema, tratamos el ndice como cualquier otro archivo secuencial, y construimos un ndice
escaso sobre el ndice primario, que puede almacenarse en memoria.
Utilizando los dos niveles de indexacin, hemos ledo nicamente un bloque de ndices en vez de 100. Si
suponemos que el ndice externo ya est en la memoria. Si el fichero es extremadamente grande, es posible que ni
siquiera el ndice exterior quepa en memoria principal, en este caso, podemos crear otro nivel de indexacin. En la
prctica, lo normal es que basten dos niveles.
Frecuentemente, cada nivel de ndice corresponde a una unidad de almacenamiento fsico. As, podemos tener
ndices en los niveles de pista, cilindro y disco.
Sin importar cual sea la forma de ndice que se utilice, se deben actualizar todos los ndices cada vez que se
inserta o elimina un registro del archivo. A continuacin describimos algoritmos para actualizar ndices de un slo nivel:
n Eliminacin. Para eliminar un registro, es necesario buscar el registro que se va a eliminar. Si el registro
eliminado era el ltimo que quedaba con ese valor particular de la clave de bsqueda, entonces eliminamos
el valor de la clave de bsqueda del ndice. Para ndices densos, eliminamos un valor de la clave de bsqueda
de la misma manera que se suprime en un archivo. Para ndices escasos, eliminamos un valor de clave
sustituyendo su entrada en el ndice por el siguiente valor de la clave de bsqueda. Si el siguiente valor ya
tiene una entrada de ndice, eliminamos la entrada.
n Insercin. Se hace una bsqueda usando el valor de la clave de bsqueda que aparece en el registro que se va
a insertar. Si el ndice es denso y el valor de la clave de bsqueda no aparece en el ndice, lo inserta. Si el ndice
es escaso no se necesita hacer ningn cambio en el ndice a menos que se cree un nuevo bloque. En este
caso, el primer valor de la clave de bsqueda que aparezca en el nuevo bloque se inserta en el ndice.
8.2.2. Indices secundarios.
Los ndices secundarios pueden estructurarse de forma diferente a los ndices primarios. Los punteros en el
ndice secundario no sealan directamente al archivo, en vez de ello, cada uno de esos punteros seala a una cubeta que
contiene punteros al archivo.
Este enfoque permite almacenar juntos todos los punteros de un valor de clave de bsqueda secundaria
determinado. Un enfoque as es til en ciertos tipos de consultas para los que podemos hacer una parte considerable de
procesamiento usando nicamente los punteros.
Para las claves primarias, podemos obtener todos los punteros para un valor de la clave de bsqueda primaria
determinado utilizando una revisin secuencial. Una revisin secuencial en orden de clave primaria es eficiente porque los
registros estn almacenados fsicamente en un orden que se aproxima al orden de la clave primaria. Sin embargo, no
podemos almacenar un archivo fsicamente ordenado tanto por la clave primaria como por una clave secundaria. Como
elorden de clave secundaria y el de clave fsica son distintos, si intentamos examinar el archivo secuencialmente en orden
de clave secundaria, es probable que la lectura de cada registro requiera la lectura de un nuevo bloque de disco.
Almacenando punteros en una cubeta, eliminamos la necesidad de punteros adicionales en los registros
mismos y de revisiones secuenciales en orden de clave secundaria.
El ndice secundario puede ser denso o escaso. Si es denso, entonces el puntero de cada cubeta individual seala
a los registros con el valor de la clave de bsqueda apropiado. Si el ndice secundario es escaso, entonces el puntero de
cada cubeta individual seala a los valores de la clave de bsqueda en un rango apropiado. En este caso, cada entrada de
cubeta es un puntero nico o bien un registro que consta de dos campos: un valor de la clave de bsqueda y un puntero
a algn registro de archivo.
Si las cubetas contienen nicamente punteros, debemos leer todos los registros a los que apunta la cubeta.
Asociando un valor de la clave de bsqueda con cada puntero de la cubeta, eliminamos la necesidad de leer registros con
un valor de la clave de bsqueda secundaria distinto del que estamos buscando.
La estructura de la cubeta puede eliminarse si el ndice secundario es denso y los valores de la clave primaria
forman parte de la clave de bsqueda.
El procedimiento descrito para la insercin y eliminacin puede aplicarse a un archivo con mltiples ndices.
Cada vez que se modifique el archivo es necesario actualizar todos los ndices.
Los ndices secundarios mejoran el rendimiento en las consultas que utilizan claves que no son primarias, sin
embargo, implican un gasto extra considerable en la modificacin de la BD. El diseador de una BD decide que ndices
secundarios son deseables, basndose en una estimacin de la frecuencia relativa de consultas y modificaciones.
8.3. Archivos indexados de rboles B
+
.
75
La desventaja principal de la organizacin de archivo secuencial indexado es que el rendimiento baja al crecer el
archivo.: la estructura de archivo de rbol B
+
es la ms ampliamente utilizada de varias estructuras de archivo que
mantienen su eficiencia a pesar de inserciones y eliminaciones. Un ndice de rbol toma B
+
la forma de un rbol
equilibrado en el que cualquier camino desde la raz del rbol hasta una hoja tiene la misma longitud. Todos los nodos
del rbol tienen entre [n/ 2] (entero, redondeo superior) y n hijos, donde n es fijo para un determinado rbol.
Veremos que la estructura de rbol B
+
impone un cierto gasto extra durante la insercin y la eliminacin,
adems de requerir un determinado espacio extra. No obstante, esto es aceptable en el caso de archivos con una
frecuencia alta de modificacin, ya que se evita el coste de la reorganizacin del archivo.
Un ndice de rbol B
+
tiene varios niveles, pero tiene una estructura que difiere de la del archivo secuencial de
ndices de varios niveles. Un nodo tpico de un rbol B
+
es de la forma:
P1 K1 P2 Pn-1 Kn-1 Pn
Contiene hasta n-1 valores de clave de bsqueda K, y n punteros P. Los valores de la clave de bsqueda dentro
de un nodo se guardan en un determinado orden, as, si i<j, entonces Ki<Kj.
Consideramos primero la estructura de los nodos hoja. Para 1i<n, Pi apunta a cualquier registro del archivo
con un valor de clave de bsqueda Ki o a una cubeta de punteros, cada uno de los cuales apunta a un registro del archivo
con valor clave de bsqueda Ki. La estructura de cubeta se utiliza solamente si la clave de bsqueda no forma una clave
primaria y el archivo no est ordenado en el orden del valor de la clave de bsqueda. El puntero Pn tiene un propsito
general que indicaremos despus.
Ahora que hemos visto la estructura de un nodo hoja, consideremos como se asignan valores de clave de
bsqueda a nodos especficos. Cada nodo hoja puede tener hasta n-1 valores, y se permite que tengan un mnimo de
[(n-1)/ 2] valores, adems, los rangos de valores de cada hoja no se solapan. As, si Li y Lj son nodos hoja e i<j, entonces
todos los valores de la clave de bsqueda en Li son menores que cualquiera de la clave Lj. El conjunto de nodos hoja de
un rbol B
+
debe formar un ndice denso de manera que cada valor de la clave de bsqueda aparezca en algun nodo hoja.
Ahora podemos explicar el uso del puntero Pn. Ya que existe un orden lineal de las hojas, basado en los valores
de clave de bsqueda que contienen, usamos Pn para encadenar los nodos hoja en orden de clave de bsqueda.. Esto
permite un procesamiento secuencial del archivo en forma eficiente.
Los nodos del rbol B
+
que no son hojas, forman un ndice escaso de varios niveles. La estructura de los
nodos que no son hoja es la misma que la de los hoja, excepto que todos los punteros apuntan a nodos del rbol. Un
nodo puede tener hasta n punteros, pero debe tener por lo menos [n/ 2] punteros. Consideremos un nodo que
contiene m punteros. Si 1<i<m, el puntero Pi apunta la estructura que contiene los valores de la clave de bsqueda
menores que Ki y mayores o iguales a Ki-1. El puntero Pm apunta a la parte del subrbol que contiene aquellos valores de
la clave mayores que o iguales a Km-1, y el puntero P1 apunta a la parte del subrbol que contiene aquellos valores de la
clave de bsqueda menores que K1.
El requisito de que cada nodo tenga por lo menos [n/ 2] punteros es obligatorio en todos los niveles del rbol
excepto en la raz.
Un rbol B
+
para el archivo depsito, con n=3, suprimiendo los punteros al archivo por simplicidad, ser de la
forma:
Siempre es posible construir un rbol B
+
, para cualquier n, en el que todos los nodos distintos del raz
contienen por lo menos [n/ 2] punteros.
Todos los ejemplos que hemos dado de rboles B
+
han sido equilibrados. Es decir, la longitud de cualquier
camino desde la raz hasta un nodo hoja es la misma. Esta propiedad es un requisito de un rbol B
+
. De hecho, la B
significa balanced (equilibrado). La propiedad de equilibrio de los rboles B
+
es la que asegura un buen rendimiento en
las bsquedas, inserciones y eliminaciones.
Supngase que queremos encontrar todos los registros con un valor de clave de bsqueda k. Primero
examinamos el nodo raz y buscamos el valor de clave de bsqueda ms pequeo mayor que k. Supngase que el valor
de la clave de bsqueda es Ki. Seguimos el puntero Pi-1 a otro nodo. Si tenemos m punteros en el nodo, y KKm-1,
entonces seguimos Pm a otro nodo. Una vez ms buscamos el valor de la clave de bsqueda ms pequeo mayor que k y
seguimos el correspondiente puntero. Finalmente llegamos a un nodo hoja, donde el puntero nos seala en registro o
la cubeta deseada.
As, al procesar una consulta se atraviesa un camino en el rbol desde la raz a una hoja. Si hay K valores de la
clave de bsqueda en el archivo, el camino no es ms largo que log[n/ 2](K). En la prctica, significa que slo se necesita
tener acceso a unos pocos nodos aunque el archivo sea muy grande. En la mayora de los casos, un nodo se hace para
que tenga el mismo tamao de un bloque del disco.
Bases de Datos
76
La insercin y la eliminacin son ms complicadas que la bsqueda, ya que puede ser necesario partir un nodo,
o combinar dos si se hacen demasiado pequeos. Adems, cuando se parte un nodo o se combinan un par de nodos,
debemos asegurarnos de que el equilibrio se conserva. Para introducir la idea de insercin y eliminacin en un rbol B
+
,
supongamos temporalmente que los nodos nunca llegan a ser demasiado grandes o demasiado pequeos. Bajo esta
suposicin, la insercin y la eliminacin son de la forma:
n Insercin. Utilizando la misma tcnica de la bsqueda, encontramos el nodo hoja en el que aparecera l valor
de la clave de bsqueda. Si el valor de la clave de bsqueda ya aparece en el nodo hoja, aadimos el nuevo
registro al archivo, y si es necesario un puntero a la cubeta. Si el valor de la clave de bsqueda no aparece,
insertamos el valor en el nodo hoja y lo posicionamos de forma que las claves de bsqueda estn todava en
orden. Entonces, insertamos el nuevo registro en el archivo, y si es necesario, creamos una nueva cubeta con
el puntero apropiado.
n Eliminacin. Utilizando la misma tcnica de la bsqueda, encontramos el registro que se va a eliminar y lo
quitamos del archivo. El valor de la clave de la bsqueda se quita del nodo hoja si no hay ninguna cubeta
asociada con el valor de la clave de bsqueda o si la cubeta queda vaca como resultado de la eliminacin.
Ahora consideremos un ejemplo en el que es necesario partir un nodo. Supngase que queremos insertar un
registro con un valor nombre_sucursal=Clearview en el rbol B
+
de la figura anterior. Empleando el algoritmo de
bsqueda vemos que Clearview aparecera en el nodo que contiene Brighton y Downttown., y no hay espacio para
insertarlo. Por tanto, el nodo se parte en dos, quedando en uno Brighton y Clearview y en el otro Downtown. En
general tomamos los n valores de clave de bsqueda (los n-1 de la hoja ms el que se inserta) y ponemos el primero en
el nodo existente y los valores restantes en el nuevo nodo.
Habiendo partido un nodo hoja, debemos insertar el nodo hoja nuevo en la estructura del rbol B
+
. En
nuestro ejemplo, el nodo nuevo tiene a Downtown como valor ms pequeo de la clave de bsqueda. Necesitamos
insertar este valor de clave de bsqueda en el padre del nodo hoja que se parti. En nuestro ejemplo se inserta el valor
Downtown en el padre, porque hay espacio disponible de clave de bsqueda. Si no hubiera sido as se hubiera tenido
que partir el padre. En el peor de los casos, se deben partir todos los nodos a lo largo del camino hacia la raz. Si la
misma raz se parte, el rbol se hace ms profundo.
La tcnica general de insercin en un rbol B
+
es determinar el nodo hoja l en el que se debe hacer la insercin. Si
tiene lugar una particin, se inserta el nuevo nodo en el padre del nodo l. Si esta insercin causa una particin, se procede
recursivamente hasta que o bien una insercin no cause una particin o se cree una nueva raz.
Ahora consideramos las eliminaciones que causan que tres nodos contengan muy pocos punteros. Primero
eliminemos Downtown del rbol B
+
resultado de la insercin anterior. Localizamos la entrada de Downtown usando el
algoritmo de bsqueda. Cuando eliminamos la entrada de Downtown de su nodo hoja, la hoja queda vaca. Puesto que
el ejemplo n=3, y 0<[(n-1)/ 2], se debe eliminar este nodo del rbol B
+
. Para eliminar un nodo hoja, debemos eliminar
el puntero que le apunta desde el padre. ste deja el nodo padre, que tena tres punteros, con slo dos punteros. Puesto
que 2[n/ 2], el nodo todava es suficientemente grande y se ha finalizado la operacin de eliminacin.
Cuando se hace una eliminacin en un padre de un nodo hoja, es posible que el nodo padre se vuelva
demasiado pequeo. Esto es exactamente lo que ocurre si eliminamos Perryridge. Cuando eliminamos el puntero a este
nodo hoja en su padre, el padre queda con slo un apuntador. Puesto que n=3, [n/ 2=2], y, por tanto, un nico
puntero es muy poco. Sin embargo, como el nodo contiene informacin til, no podemos simplemente eliminarlo. En
vez de ello, examinamos el nodo hermano. Este nodo hermano tiene espacio para incluir la informacin del nodo que
ahora es demasiado pequeo, por lo que podemos juntar estos nodos, de forma que el nodo hermano ahora contiene
las claves Mianus y Redwood. El otro nodo, el primero, ahora contiene informacin redundante y puede eliminarse de
su padre. Obsrvese que la raz quedo vaca despus de la eliminacin, por lo que se redujo en un nivel la profundidad
del rbol B
+
.
No siempre es posible fusionar nodos, lo que ocurre cuando el nodo hermano ya contiene el mximo de
punteros. La solucin en este caso es redistribuir los punteros de forma que cada hermano tenga los mismos punteros.
Obsrvese que la redistrubicin de valores necesita un cambio de un valor de clave de bsqueda en el padre de los dos
hermanos. En general, para eliminar un nodo en el rbol B
+
, realizamos una bsqueda del valor y lo eliminamos. Si el
nodo es demasiado pequeo, lo eliminamos de su padre.
Aunque las operaciones de insercin y eliminacin en rboles B
+
son complicadas, requieren relativamente
pocas operaciones. Puede demostrarse que el nmero de operaciones que se necesita en el peor de los casos para una
insercin o eliminacin es proporcional al logaritmo del nmero de claves de bsqueda. La velocidad de las operaciones
en los rboles B
+
es la que hace que se utilicen frecuentemente como estructuras de ndices en implementaciones de BD.
8.4. Archivos indexados de rboles B.
Los ndices de rboles B son similares a los ndices de rboles B
+
. La principal diferencia entre los dos enfoques
es que un rbol B elimina el almacenamiento redundante de valores de clave de bsqueda. Todos los valores de la clave
de bsqueda aparecen en algn nodo hoja.
Un rbol B permite que los valores de clave de bsqueda aparezcan una sola vez. Puesto que no se repiten las
claves de bsqueda en el rbol B, podemos almacenar el ndice utilizando menos nodos que en el rbol B
+
correspondiente. Sin embargo, puesto que las claves de bsqueda que aparecen en los nodos no aparecen en ningn otro
sitio del rbol B, estamos obligados a incluir un campo de puntero adicional para cada clave de bsqueda en un nodo
que no sea hoja. Estos punteros adicionales apuntan a registros de archivos o cubetas para la clave de bsqueda asociada.
Los rboles B ofrecen una ventaja adicional con respecto a los rboles B
+
aparte de eliminar el almacenamiento
redundante de claves de bsqueda. En una bsqueda en un rbol B
+
, siempre es necesario recorrer un camino desde la
77
raz del rbol hasta algn nodo hoja. Sin embargo, en un rbol B, a veces es posible encontrar el valor deseado antes de
leer un nodo hoja. As, la bsqueda es ligeramente ms rpida en un rbol B, aunque en general el tiempo de bsqueda
todava es proporcional al logaritmo del nmero de claves de bsqueda.
Estas ventajas del rbol B sobre el B
+
se compensan con varias desventajas:
n Los nodos hojas y los que no son hoja tienen el mismo tamao en una rbol B
+
. En un rbol B, los
nodos que no son hoja son ms grandes, lo que complica la gestin del almacenamiento del ndice.
n La eliminacin de un rbol B es ms complicada. En un rbol B
+
, la entrada eliminada siempre aparece en
una hoja. En un rbol B, la entrada puede aparecer en un nodo que no sea hoja. Se debe seleccionar del
subrbol del nodo que contiene la entrada eliminada el valor apropiado para sustituirlo. De manera
especfica, si se elimina la clave de bsqueda Ki, la clave de bsqueda ms pequea que aparece en el subrbol
del puntero Pi+1 debe pasarse al campo que antes ocupaba Ki.
Las ventajas de los rboles B son de poca importancia para ndices grandes. As, muchos implementadores de
DBMS prefieren la simplicidad estructural de los rboles B
+
.
8.5. Funciones de asociacin (hash) esttica.
Una desventaja de los esquemas de ndices es que debemos acceder a una estructura de ndices para localizar
datos. La tcnica de asociacin (hashing) nos permite evitar el acceso a una estructura de ndices. Suponemos que el ndice
denso est dividido entre un nmero de diferentes cubetas. La direccin de la cubeta que contiene un puntero al dato
deseado se obtiene directamente calculando una funcin sobre el valor de la clave de bsqueda del registro deseado.
Formalmente, K representa el conjunto de todos los valores de la clave de bsqueda, y B el conjunto de todas las
direcciones de la cubeta. Una funcin de asociacin (hash) h es una funcin de K a B.
El principio bsico de la asociatividad es que, aunque el conjunto K de las claves sea grande, el conjunto {K1,
K2, , Kn} de valores de clave de bsqueda realmente almacenados en la BD es mucho ms pequeo que K. En el
momento de hacer el diseo no conocemos los valores de la clave de bsqueda que se almacenarn, pero sabemos que
hay demasiados valores posibles para justificar la asignacin de una cubeta a cada uno de ellos. Sin embargo, sabemos en
el momento de hacer el diseo, aproximadamente cuantos valores de clave de bsqueda van a ser almacenados en la BD.
Elegimos el nmero de cubetas para hacer la correspondencia con el nmero de valores de la clave de bsqueda que
esperamos tener almacenados. La funcin de asociacin es la que define la asignacin de valores de la clave de bsqueda a
cubetas especficas.
Las funciones de asociacin deben disearse con cuidado. Una funcin de asociacin deficiente puede resultar
en una bsqueda que tarde un tiempo proporcional al nmero de claves de bsqueda en el archivo. Una funcin bien
diseada da un tiempo de bsqueda promedio que es una constante (pequea), independiente del nmero de claves de
bsqueda en el archivo. Esto se logra asegurndose de que, en promedio, los registros se distribuyen uniformemente
entre las cubetas.
Sea h una funcin. Para realizar una bsqueda del valor de clave Ki, simplemente calculamos h(Ki) y buscamos
la cubeta con esa direccin. Supngase que dos claves de bsqueda, K5 y K7, tienen el mismo valor de asociacin, es decir,
h(K5)=h(K7). Si buscamos K5, la cubeta h(K5) contiene registros con valores de la clave de bsqueda K5 y de K7. As,
tenemos que comprobar el valor de la clave de bsqueda de todos los registros de la cubeta para verificar que el registro es
uno de los que queremos.
La peor funcin de asociacin posible asigna todos los valores de clave de bsqueda a la misma cubeta. Esto es
indeseable, ya que el ndice denso completo se guarda en la misma cubeta, y , por tanto, la bsqueda requiere la revisin
del ndice completo. Una funcin de asociacin ideal asigna cada valor de la clave de bsqueda a una cubeta distinta. Una
funcin as es ideal porque cada registro de la cubeta que se examina, como resultado de una bsqueda tiene el valor de
clave de bsqueda deseado.
Puesto que en el momento de hacer el diseo no sabemos con precisin los valores de clave de bsqueda,
queremos elegir una funcin de asociacin que asigne valores de la clave de bsqueda a las cubetas, de manera que:
n La distribucin sea uniforma. Es decir, se asigne a cada cubeta el mismo nmero de valores de la clave de
bsqueda del conjunto de todos los valores posibles de la clave de bsqueda.
n La distribucin sea al azar. Es decir, en el caso promedio, cada cubeta tendr casi el mismo nmero de
valores asignados.
Intentemos elegir una funcin de asociacin para el archivo depsito utilizando la clave de bsqueda
nombre_sucursal. Supngase que decidimos tener 26 cubetas y definimos una funcin de asociacin que asigna
nombres que empiezan con la letra i del alfabeto a la cubeta i-sima. Esta funcin de asociacin es muy sencilla, pero falla
en la distribucin uniforme, ya que esperamos ms nombres de sucursales que empiecen con B y R que con Q y X.
Las funciones de asociacin tpicas realizan algn clculo sobre la representacin binaria interna a la mquina de
los caracteres de la clave de bsqueda. Una funcin de asociacin sencilla de este tipo es calcular la suma, el mdulo del
nmero de cubetas de la representacin binaria de los caracteres de una clave que se han asignado.
La insercin es casi tan simple como la bsqueda. Si el valor de la clave de bsqueda del registro que se va a
insertar es Ki, calculamos h(Ki) para localizar la cubeta para ese registro.
La eliminacin es tan directa como la insercin. Si el valor de la clave de bsqueda del registro que se va a
eliminar es Ki, calculamos h(Ki) y buscamos la cubeta correspondiente para ese registro.
La forma de estructura de asociatividad que hemos descrito a veces se conoce como asociatividad abierta.
Bajo un enfoque alternativo, llamado asociatividad cerrada, se almacenan todos los registros en una cubeta y la
funcin de asociacin calcula las direcciones dentro de la cubeta. La asociatividad cerrada se utiliza frecuentemente en la
Bases de Datos
78
construccin de tablas de smbolos para compiladores y ensambladores, pero se prefiere la asociatividad abierta para
DBMS. La razn es que la eliminacin resulta problemtica cuando se emplea asociatividad cerrada.
Una desventaja importante de la forma de asociatividad que acabamos de describir es que la funcin de
asociacin debe elegirse cuando implementamos el sistema y no se puede cambiar fcilmente despus. Puesto que la
funcin h asigna valores de la clave de bsqueda a un conjunto fijo B de direcciones de cubetas, desperdiciamos si B es
excesivamente grande. Si B es demasiado pequeo, las cubetas contendrn registros de muchos valores diferentes de la
clave de bsqueda y el rendimiento disminuir. Normalmente, eligiendo el tamao de B el doble del nmero de valores
de la clave de bsqueda en el archivo puede lograrse un buen equilibrio entre espacio y rendimiento.
8.6. Funciones de asociacin (hash) dinmica.
Como hamos visto, la necesidad de fijar el conjunto B de direcciones de cubetas es un problema serio de la
tcnica de asociacin esttica. La mayora de las BD crecen conforme pasa el tiempo. Si vamos a usar asociacin esttica es
una BD de este tipo, se presentan tres clases de opciones:
n Elegir una funcin de asociacin basada en el tamao actual del archivo. Dar como resultado una
degradacin del rendimiento conforme crezca la BD.
n Elegir una funcin de asociacin basada en el tamao anticipado del archivo en el mismo punto en el
futuro. Aunque se evita la degradacin, al principio se desperdicia mucho espacio.
n Reorganizar peridicamente la estructura de asociacin como respuesta al crecimiento del archivo. Una
reorganizacin as implica la eleccin de una nueva funcin de asociacin, volver a calcular la funcin de
asociacin para cada uno de los registros y generar nuevas asignaciones de las cubetas, lo que conlleva un
elevado consumo de tiempo. Adems es necesario prohibir el acceso al archivo durante la reorganizacin.
Existen varias tcnicas de asociacin que permiten modificar de manera dinmica la funcin de asociacin para
compensar el crecimiento o reduccin de la BD. Estas tcnicas se llaman funciones de asociacin (hash) dinmica. A
continuacin describimos una forma de asociacin dinmica llamada asociacin extensible.
La asociacin extensible maneja los cambios en el tamao de la BD dividiendo y fusionando cubetas conforme
la BD crece y se reduce. Como resultado se mantiene la eficiencia de espacio. Adems, puesto que la reorganizacin se
realiza cada vez nicamente en una cubeta, el tiempo extra requerido es aceptablemente bajo.
Con la asociacin extensible elegimos una funcin de asociacin h con las propiedades deseables de
uniformidad y aletoriedad. Sin embargo, esta funcin de asociacin genera valores en un rango relativamente grande de
enteros binarios de b bytes.
No creamos una cubeta para cada valor de asociacin, creamos cubetas segn la demanda, segn se insertan
registros. Inicialmente no usamos los b bytes de la asociacin. En un momento dado utilizamos i bytes, donde 0ib..
Estos i bytes representan una posicin relativa en una tabla adicional de direcciones de cubetas. El valor de i aumenta y
disminuye con el tamao de la BD.
Aunque se requieren i bytes para encontrar la entrada correcta en la tabla de direcciones de cubetas, varias
entradas consecutivas de la tabla pueden apuntar a la misma cubeta. Todas esas entradas tendrn un prefijo comn de
asociacin, pero la longitud de este prefijo puede ser menor que i. Por tanto, con cada cubeta asociamos un entero dando
la longitud del prefijo comn de asociacin.
Para localizar la cubeta que tiene el valor de la clave de bsqueda Kl tomamos los primeros i bytes de h(Kl),
vemos la entrada de la tabla que corresponde a esa cadena da bytes, y seguimos el puntero de la cubeta en la entrada de la
tabla..
Para insertar un registro con valor de clave de bsqueda Kl, seguimos el mismo procedimiento que antes para la
bsqueda, terminando en alguna cubeta, llammosla j. Si hay sitio en la cubeta insertamos la informacin apropiada y
despus insertamos el registro en el archivo. Si la cubeta est llena, debemos partirla y redistribuir los registros actuales
ms el nuevo. Para partir la cubeta, primero debemos determinar si necesitamos aumentar el nmero de bytes que
usamos en la asociacin.
n Si i=ij. Entonces solamente una entrada en la tabla de direcciones de cubetas apunta a la cubeta j. Por tanto,
necesitamos aumentar el tamao de la tabla de direcciones de cubetas de forma que podamos incluir
punteros en las dos cubetas que resultan de la particin de j. Hacemos esto considerando un bit adicional
de la asociacin. Incrementamos el valor de i en 1, duplicando as el tamao de la tabla. Cada entrada se
79
sustituye por dos, cada una de las cuales contiene el mismo puntero que la original. Ahora dos entradas en
la tabla de direcciones de cubetas apuntan a la cubeta j. Asignamos una nueva cubeta (z, por ejemplo) y
hacemos que la segunda entrada apunte a la nueva cubeta. Ponemos ij e iz a i. A continuacin, se reasocia
cada registro de la cubeta j y dependiendo de los i (ahora vale iinicial+1) o se guarda en la cubeta j o bien se
asigna a la cubeta z recin creada. Ahora reintentamos la insercin del nuevo registro, y normalmente tendr
xito, sin embargo, si todos los registros de la cubeta j y el nuevo registro tienen el mismo prefijo de valor
de asociacin, ser necesario volver a partir una cubeta. Si la funcin de asociacin se elige con cuidado, no es
probable que una nica insercin requiera que una cubeta se parta ms de una vez.
n Si i>ij. Entonces ms de una entrada en la tabla apuntan a la cubeta j. As, podemos partir la cubeta j sin
aumentar el tamao de la tabla de direcciones de cubetas. Obsrvese que todas las entradas que apuntan a la
cubeta j corresponden a prefijos de asociacin que tienen el mismo valor en los bytes ij ms ala izquierda.
Asignamos una nueva cubeta (digamos z) y ponemos ij e iz al valor que resulta de aadir 1 al valor ij
original. A continuacin necesitamos ajustar las entradas en la tabla de direcciones de cubetas que
anteriormente apuntaban a la cubeta j. Dejamos la primera mitad de las entradas como estaban y ponemos
todas las dems en la recin creada z. A continuacin, como en el caso que vimos antes, se reasocia cada
registro de la cubeta j y se reasignan a j o z segn corresponda. Se reintenta la insercin En el caso menos
probable de que vuelva a fallar, aplicamos uno de estos dos casos de nuevo.
Obsrvese que en ambos caos necesitamos volver a calcular la funcin de asociacin nicamente en los registros
de la cubeta j.
Para eliminar un registro con valor de clave de bsqueda Kl, seguimos el mismo procedimiento que antes para
la bsqueda, terminando en alguna cubeta, digamos j. Sacamos la clave de bsqueda de la cubeta y el registro del archivo.
La cubeta tambin se elimina si queda vaca, en este momento se pueden unir varias cubetas y el tamao de la tabla de
direcciones de cubetas se puede partir en dos.
Examinemos ahora las ventajas y desventajas de la asociacin extensible comparada con las otras planificaciones
que se han estudiado. La ventaja principal de la asociacin extensible es que el rendimiento no disminuye conforme crece
el archivo. Adems, se requiere un mnimo espacio adicional. Aunque la tabla de direcciones de cubetas ocupa un espacio
extra adicional, contiene un puntero para cada valor de asociacin con la longitud del prefijo actual, as pues la tabla es
pequea, y no es necesario reservar cubetas para un crecimiento futuro; las cubetas pueden asignarse de manera dinmica.
Una desventaja de la asociacin extensible es que la bsqueda implica un nivel de indireccin especial, ya que
debemos tener acceso a la tabla de direcciones de cubetas antes de acceder a la cubeta en s. Esta referencia extra slo tiene
un impacto de poca importancia en el rendimiento, impacto que aumenta al llenarse la BD.
As pues, la asociacin extensible parece ser una tcnica muy atractiva, siempre que se quiera aceptar la
complejidad aadida que implica su implementacin.
8.7. Comparacin de indexacin y asociacin (hash).
La mayor parte de los DBMS utilizan slo unas pocas o una forma de indexacin o de asociacin. Para tomar la
decisin apropiada, el implementador o el diseador de la BD deben considerar los siguientes factores:
n Es aceptable el coste de la reorganizacin peridica del ndice o estructura de asociacin?
n Cul es la frecuencia relativa de inserciones y eliminaciones?
n Es deseable optimizar el tiempo de acceso promedio a expensas de aumentar el tiempo de acceso en el
peor de los casos?
n Qu tipos de consultas harn normalmente los usuarios?
Ya hemos examinado los tres primeros factores en la revisin de los mriots relativos de las tcnicas
especificadas de asociacin. El cuarto factor, el tipo esperado de consulta, es crtico para la eleccin de indexacin o
asociacin.
Si la mayor parte de las consultas son de la forma:
select A1, A2, , An
from r
where Ai=c
entonces, al procesar esta consulta, el sistema realizar una bsqueda en el ndice o estructura de asociacin
correspondiente al atributo Ai para el valor c. Para consultas de esta forma es preferible un esquema de asociacin. La
bsqueda en un ndice requiere un tiempo proporcional al logaritmo del nmero de valores de Ai en r, sin embargo, en
una estructura de asociacin, el tiempo promedio de bsqueda es una constante independiente del tamao de la BD. La
nica ventaja del ndice para esta forma de consulta es que el tiempo de bsqueda en el peor de los casos es proporcional
al logaritmo del nmero de valores de Ai en r, en cambio, con la asociacin, el tiempo de bsqueda en el peor de los
casos es proporcional al nmero de valores de Ai en r.
Las tcnicas de indexacin son preferibles a la asociacin en los casos en los que se especifica un rango de valores
en la consulta. Una consulta de este tipo tiene la forma siguiente:
select A1, A2, , An
from r
where Aic2 and Aic1
En otras palabras, esta consulta encuentra todos los registros con valores de Ai entre c1 y c2.
Utilizando un ndice, primero buscamos el valor c1, y seguimos la cadena de punteros del ndice para leer la
siguiente cubeta en orden alfabtico y continuar de esta manera hasta alcanzar c2.
Bases de Datos
80
Si tenemos una estructura de asociacin, podemos buscar c1 y localizar la cubeta correspondiente, pero no es
fcil determinar cul es la siguiente cubeta. La dificultad surge del hecho de que una funcin de asociacin buena asigna
valores a las cubetas aleatoriamente.
Si queremos atender consultas de rangos utilizando una estructura de asociacin, debemos elegir una funcin
de asociacin que conserve el orden, es decir, si K1 y K2 son valores de la clave de bsqueda y K1<K2, entonces
h(K1)<h(K2). Una funcin de este tipo asegura que las cubetas estn en orden de clave. Es difcil encontrar una funcin
de asociacin que conserve el orden y cumpla los requisitos de aletoriedad y uniformidad.
Debido a la dificultad para encontrar una buena funcin de asociacin que conserve el orden, la mayor parte de
los sistemas utilizan indexacin.
8.8. Definicin de ndice en SQL.
El estndar permite al compilador de SQL la libertad de elegir cmo implementar el cumplimiento de las
claves. Las implementaciones tpicas hacen cumplir una declaracin de clave creando un ndice con la clave declarada como
la clave de bsqueda del ndice.
Algunas implementaciones de SQL incluyen ordenes especficas de definicin de datos para crear y truncar
ndices, entre las que estn el Sequel original y el SAA-SQL de IBM. A continuacin presentamos las ordenes de ndice
del SAA-SQL.
Un ndice se crea mediante la orden create index, que tiene la forma:
create index <nom_ndice> on <nom_relacin> (<lista_de_atributos>)
La lista_de_atributos es la lista de atributos de las relaciones que forman la clave de bsqueda para el ndice.
Para definir un ndice en la relacin sucursal con clave de bsqueda nombre_sucursal, escribimos:
create index ndice_b on sucursal (nombre_sucursal)
Si deseamos declarar que la clave de bsqueda es una clave candidata, aadimos el atributo unique a la
definicin de ndice, entre create e index.
Si en el momento en que se introduce create unique index, el atributo no es una clave candidata, se presentar
un mensaje de error y fallar el intento de crear el ndice. Si el intento de crear el ndice tiene xito, cualquier intento
subsiguiente de insertar una tupla que viole la declaracin de clave fallar.
El nombre de ndice especificado para un ndice se requiere de forma que sea posible truncar ndices. La orden
drop index tiene la forma:
drop index <nom_ndice>
8.9. Acceso por claves mltiples.
Para ciertos tipos de consultas resulta til usar ndices mltiples, si existen.
Supngase que el archivo depsito tiene dos ndices, uno por nombre_sucursal y otro por nombre_cliente.
Considrese encontrar todas las cuentas de un cliente en una sucursal. Existen tres posibles estrategias para procesar esta
consulta:
n Utilizar el ndice de nombre_sucursal para encontrar todas las cuentas de la sucursal y examinar todos esos
registros para ver cuales son los de el cliente.
n Utilizar el ndice de nombre_cliente para encontrar todas las cuentas del cliente y examinar todos esos
registros para ver cuales son los de la sucursal.
n Tomar la interseccin de estos dos conjuntos de punteros. Aquellos punteros que estn en la interseccin
apuntan a registros pertenecientes tanto al cliente como a la sucursal.
La tercera estrategia es la nica de las tres que aprovecha la existencia de ndices mltiples. Sin embargo. Incluso
esta estrategia puede ser pobre si se cumplen las siguientes condiciones: existen muchos registros para una sucursal,
existen muchos registros para el cliente, hay pocos registros que pertenezcan al cliente y a la sucursal.
Si se cumplen estas condiciones, debemos examinar un gran nmero de punteros para producir un resultado
pequeo.
Para acelerar el procesamiento de consultas con mltiples claves de bsqueda pueden mantenerse varias
estructuras especiales. Consideraremos dos de estas estructuras: la estructura de rejilla y las funciones de asociacin
divididas.
8.9.1. Estructura de rejilla.
Una estructura de rejilla para estructuras que usan dos claves de bsqueda es un array bidimensional indexado
por los valores de las claves de bsqueda. Para realizar una bsqueda, buscamos una de las claves en las columnas y la
otra en las filas. Esa entrada contiene punteros a todos los registros en los que coinciden las claves de bsqueda pedidas.
No es necesario realizar clculos especiales, y solamente se accede a los registros necesarios para responder a la
consulta.
La estructura de rejilla tambin es apropiada para consultas que implican una sola clave de bsqueda., los
punteros que aparecen en toda la fila o columna de la clave buscada son la respuesta a la consulta.
81
Conceptualmente es sencillo extender el enfoque de estructura de rejilla a cualquier nmero de claves de
bsqueda.
Las estructuras de rejilla proporcionan una mejora importante en el tiempo de procesamiento para las consultas
de claves mltiples. Sin embargo, requieren cierta cantidad de espacio y tiempo extra en las inserciones y eliminaciones de
registros.
8.9.2. Funcin de asociacin dividida.
Otra manera de enfocar las consultas de claves mltiples es usando una funcin de asociacin dividida.
Supngase que deseamos construir una estructura adecuada para consultas en el archivo depsito que implican tanto a
nombre_cliente como a nombre_sucursal. Construimos una estructura de asociacin para la clave (nombre_cliente,
nombre_sucursal). La nica diferencia entre la estructura que vamos a crear y las que vimos anteriormente es que
imponemos una restriccin adicional sobre la funcin de asociacin h. Los valores de asociacin se dividen en dos partes.
La primera parte depende slo del valor de nombre_cliente y la segunda depende slo de nombre_sucursal. La funcin
de asociacin se denomina dividida porque los valores de asociacin se dividen en segmentos que dependen de cada
elemento de la clave. As, si utilizamos valores de bsqueda de seis bits, los tres primeros dependen del valor de
nombre_cliente y los tres ltimos de nombre_sucursal.
Como era el caso del archivo de rejilla, la asociacin dividida se extiende a un nmero arbitrario de atributos.
Podemos hacer varias mejoras en la asociacin dividida si sabemos con que frecuencia especificar el usuario cada uno de
los atributos en una consulta.
Existen otras varias tcnicas hbridas para procesar consultas de claves mltiples. Tales tcnicas pueden ser tiles
en aplicaciones en las que la persona que implementa el sistema sabe que la mayora de las consultas sern de una forma
restringida.

Teoria de Bases de Datos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Teoria de Bases de Datos

Transféré par

Droits d'auteur :

Formats disponibles

Indice

saldo * 1,06 (saldo>10.000 (depsito)

saldo * 1,05(saldo>10.000 (depsito)

Vous aimerez peut-être aussi