Indice

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.8. Generalizacin. 2.9. Agregacin. 2.10. Diseo de un esquema de base de datos E-R.

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.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 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.1. Consultas ejemplo. 3.3.2. Definicin formal. 3.3.3. Seguridad de expresiones. 3.3.4. Poder expresivo de los lenguajes. 3.4.1. Definicin formal. 3.4.2. Consultas ejemplo. 3.4.3. Seguridad de las expresiones. 3.4.4. Poder expresivo de los lenguajes. 3.5.1. Eliminacin. 3.5.2. Insercin. 3.5.3. Actualizacin.

3.3. El clculo relacional de tuplas.

3.4. El clculo relacional de dominios.

3.5. Modificacin de la base de datos.

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.1. Estructura bsica. 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.2.8. Modificacin de la Base de Datos. 4.3.1. Estructura bsica. 4.3.2. Consultas sencillas. 4.3.3. Variables de tupla. 4.3.4. Funciones de agregacin. 4.3.5. Modificacin de la Base de Datos.

4.2. Query By Example (QBE).

4.3. QUEL.

II

Indice 4.3.6. Operaciones de conjuntos.

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.1.3. Valores nulos. 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.1. Conceptos bsicos. 5.3.2. Cierre de un conjunto de dependencias funcionales. 5.3.3. Cierre de conjuntos de atributos. 5.3.4. Recubrimiento cannico.

5.2. Integridad referencial.

5.3. Dependencias funcionales.

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.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.1. Dependencias multivaluadas. 6.3.2. Teora de dependencias multivaluadas. 6.3.3. Cuarta forma normal. 6.4.1. Dependencias de interseccin. 6.4.2. Forma normal de proyecto-producto. 6.1.1. Representacin de la informacin. 6.1.2. Perdida de informacin.

6.3. Normalizacin por medio de dependencias multivaluadas.

6.4. Normalizacin por medio de dependencias de interseccin. 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.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).
7.3.1. Registros de longitud fija. 7.3.2. Registros de longitud variable.

Tema 8.Indexacin y asociatividad (hashing).

III

Indice

8.1. Conceptos bsicos. 8.2. Indexacin.

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.

8.2.1. ndice primario. 8.2.2. Indices secundarios.

IV

Tema 1. Introduccin

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 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 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 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

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 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

Bases de datos

Tema 2. Modelo entidad-relacin

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 E 1, E 2, ...,En son conjuntos de entidades, entonces un conjunto de relaciones R es un subconjunto de {(e1, e2, ..., en)|e1E 1, e2E 2, ..., enE n} 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 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.

10

Tema 2. Modelo entidad-relacin 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 E 1, E 2, ..., E n. 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.

11

Bases de datos 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} {b 1, b 2, ..., b s} 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.

12

Tema 2. Modelo entidad-relacin 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.

13

Bases de datos 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.

14

Tema 2. Modelo entidad-relacin 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.

15

Bases de datos

16

Tema 3. Modelo relacional.

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

17

Bases de Datos 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.

18

Tema 3. Modelo relacional. 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 n 1 tuplas en servicio y n 2 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 r (R1) y r2(R2), entonces r xr2 es una relacin cuyo esquema es la 1 1 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.

19

Bases de Datos 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_cl iente (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: E 1E 2, E 1-E 2, E 1xE2, 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.

20

Tema 3. Modelo relacional. 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.

21

Bases de Datos 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. 3.3.1. Consultas ejemplo. 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 P Q 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]))}

22

Tema 3. Modelo relacional. 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. 3.3.2. Definicin formal. 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). 3.3.4. Poder expresivo de los lenguajes. 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. 3.4.1. Definicin formal. 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.

23

Bases de Datos 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)))) 3.4.2. Consultas ejemplo. 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. 3.4.4. Poder expresivo de los lenguajes. 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: rr-E donde r es una relacin y E es una consulta del lgebra relacional. Ejemplo, eliminar todas las cuentas de Smith:

24

Tema 3. Modelo relacional. 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: rrE 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: AE (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: saldosaldo * 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: saldosaldo * 1,06 (saldo>10.000 (depsito) saldosaldo * 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.

25

Bases de Datos 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.

26

Tema 4. Lenguajes relacionales comerciales.

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. 4.1.1. Estructura bsica. 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

27

Bases de Datos 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 4.1.3. Operaciones de conjuntos. 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 (select nombre_cliente from prstamo where nombre_sucursal = Perryridge) 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_sucu rsal = 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

28

Tema 4. Lenguajes relacionales comerciales. 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 in prueba 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: (select nombre_cliente from depsito where nombre_sucursal = Perryridge) 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 where nombre_sucursal = Perryridge) 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) 4.1.6. Variables de tupla. 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.

29

Bases de Datos 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 where ciudad_sucursal = Brooklyn) 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 where ciudad_sucursal = Brooklyn) 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 where ciudad_sucursal = Brooklyn) 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.

30

Tema 4. Lenguajes relacionales comerciales. 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. 4.1.10. Funciones de agregacin. 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 group by nombre_sucursal 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 group by nombre_sucursal 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.

31

Bases de Datos 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. 4.1.12. Modificacin de la Base de Datos. 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

32

Tema 4. Lenguajes relacionales comerciales. 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. 4.1.13. Valores nulos. 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:

33

Bases de Datos (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 table se 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. 4.2.1. Estructura bsica. 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

4.2.2. Consultas sencillas. 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 Perrydridge Nmero_cuenta Nombre_cliente P._x Saldo

34

Tema 4. Lenguajes relacionales comerciales. 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:
Prstamo P. Nombre_sucursa l Nmero_prestam o Nombre_cliente Cantidad > 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.
Depsito Nombre_sucursa l Perryridge Redwood Nmero_cuenta Nombre_cliente P._x _x Saldo

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.
Prstamo Nombre_sucursa l Perryridge Cliente Nmero_prestam o Nombre_cliente _x Calle Ciudad_cliente P._y Cantidad

Nombre_cliente P._x

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.
Depsito Nombre_sucursa l Perryridge Nombre_sucursa l PErryridge Nmero_cuenta Nombre_cliente P._x Nmero_prestam o Nombre_cliente _x Cantidad Saldo

Prstamo

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 x jones en la consulta. Esto se hace imponiendo el cuadro de condiciones e introduciendo el lmite x=Jones.
Condiciones x=Jones

35

Bases de Datos Para encontrar todos los nmeros de prstamo con cantidades entre 1300$ y 1500$ escribimos:
Prstamo Nombre_sucursa l Nmero_prestam o P. Condiciones _x1300 _x1500 Nombre_cliente Cantidad _x

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 P. Activo Ciudad_sucursal _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:
Depsito Nombre_sucursa l Perryridge Cliente Nmero_cuenta _z Calle Nombre_cliente _x Ciudad_cliente _y Nmero_cuenta _z Saldo

Nombre_cliente _x Nombre_cliente _x

La consulta resultante es:

Resultado P. Ciudad_client e _y

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.
Cliente Nombre_cliente P.AO(1). Calle Ciudad_cliente 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:
Depsito Nombre_sucursa l P.AO.G. Nmero_cuenta Nombre_cliente Saldo P.AVG.ALL._x

36

Tema 4. Lenguajes relacionales comerciales. 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:
Depsito Nombre_sucursa l Perryridge Cliente Nmero_cuenta Nombre_cliente _x Calle Ciudad_cliente Saldo

Nombre_cliente 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.
Depsito Nombre_sucursa l CNT.UNQ.ALL_ y Nmero_cuenta Nombre_cliente P.G._x Activo Ciudad_sucursal Brooklyn Brooklyn Saldo

Sucursal

Nombre_sucursal _y _z

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. 4.2.8. Modificacin de la Base de Datos. 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:
Sucursal Nombre_sucursal Perryridge Nombre_sucursa l Nmero_cuenta _x Condiciones _x=(1300 and 1500) Activo Ciudad_sucursal D. Saldo

Eliminar las cuentas con nmeros de cuenta entre 1300 y 1500:

Depsito D. Nombre_cliente

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:
Depsito I. Nombre_sucursa l Peryridge Nmero_cuenta 9732 Nombre_cliente Smith Saldo 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:

37

Bases de Datos
Depsito I. Depsito Nombre_sucursa l Perryridge Nombre_sucursa l Perryridge Nmero_cuenta _x Nmero_prstam o _x Nombre_cliente _y Nombre_cliente _y Saldo 200 Cantidad

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$:
Sucursal Nombre_sucursal Perryridge Activo U.10000000 Ciudad_sucursal

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:
Depsito U. Nombre_sucursa l Nmero_prstam o Nombre_cliente Cantidad _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. 4.3.1. Estructura bsica. 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. 4.3.2. Consultas sencillas. 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

38

Tema 4. Lenguajes relacionales comerciales. 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. 4.3.3. Variables de tupla. 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 t is depsito 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. 4.3.4. Funciones de agregacin. 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: range of t is depsito 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 range of t 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 range of u is depsito range of t is depsito retrieve (t.nmero_cuenta) 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: range of u is depsito range of t is depsito retrieve (t.nmero_cuenta) 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.

39

Bases de Datos 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 t is depsito range of s is sucursal range of u is sucursal retrieve unique (t.nombre_cliente) 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. 4.3.5. Modificacin de la Base de Datos. 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 t is depsito 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: range of t is depsito replace t (saldo = 1,06 * saldo)

40

Tema 4. Lenguajes relacionales comerciales. where t.saldo > 10000 replace t (saldo = 1,05 * saldo) where t.saldo 10000 4.3.6. Operaciones de conjuntos. 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: range of u is depsito retrieve into temp unique (u.nombre_cliente) where u.nombre_sucursal = Perryridge 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: range of u is depsito retrieve into temp unique (u.nombre_cliente) where u.nombre_sucursal = Perryridge 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 retrieve unique (t.nombre_cliente)

41

Tema 5. Restricciones de integridad.

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. 5.1.3. Valores nulos. 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. 5.2.1. Conceptos bsicos.

43

Bases de Datos 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 K 1 y K 2 respectivamente. Decimos que un subconjunto de R2 es una clave exterior con referencia K 1 en la relacin r1 si es necesario que para cada t2 en r2 haya una tupla t1 en r1 tal que t1[K 1] = 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 E 1, E 2, , E n. K i representa la clave primaria de E i. Los atributos del esquema de relaciones para el conjunto de relaciones R incluyen K 1 K2 Kn. Cada K i 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).

44

Tema 5. Restricciones de integridad. 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. 5.3.1. Conceptos bsicos. 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.

45

Bases de Datos Consideremos la siguiente relacin: A B C D a1 b1 c1 d1 a1 b2 c1 d2 a2 b2 c2 d2 a2 b3 c2 d3 a3 b3 c2 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: AB AC CG H CG I BH 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 .

46

Tema 5. Restricciones de integridad. 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 A B esta en F, A resultado (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.

47

Bases de Datos 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:

48

Tema 5. Restricciones de integridad. 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.

49

Tema 6. Diseo de Bases de Datos relacionales.

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

51

Bases de Datos 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_info_prstamo = (nombre_sucursal, nmero_prstamo, cantidad) 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.

52

Tema 6. Diseo de Bases de Datos relacionales. 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 F de todas las i + dependencias funcionales en F que incluyen nicamente atributos de R. Puesto que que todas las dependencias i 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.

53

Bases de Datos 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) 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: esquema_info_prstamo = (nombre_sucursal, nmero_prstamo, cantidad) esquema_prstamo_cliente = (nombre_cliente, nmero_prstamo) 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 R , R2, , Rn usando el siguiente 1 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: nombre_sucursal activo ciudad_sucursal nmero_prstamo cantidad nombre_sucursal Una clave candidata de este esquema es {nmero_prstamo, nombre_cliente}. Podemos aplicar el algoritmo as:

54

Tema 6. Diseo de Bases de Datos relacionales. 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: esquema_info_prstamo = (nombre_sucursal, nmero_prstamo, cantidad) esquema_prstamo_cliente = (nombre_cliente, nmero_prstamo) 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 F y F2 de F a cada uno de los esquemas son las siguientes, en su 1 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 +F+ y la descomposicin no conserva las dependencias. Adems, demuestra que no siempre es posible tanto, F 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 ( NF). Veremos que siempre es posible 3 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: nombre_cliente nombre_sucursal nombre_banquero 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

55

Bases de Datos 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 nombre_cliente nombre_sucursal nombre_banquero 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.

56

Tema 6. Diseo de Bases de Datos relacionales. 6.3.1. Dependencias multivaluadas. Las dependencias funcionales excluyen el que ciertas tuplas estn en una relacin. Si A B, 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 a1ai ai+1 aj aj+1 an t2 a1ai bi+1 bj bj+1 bn t3 a1ai ai+1 aj bj+1 bn t4 a1ai bi+1 bj aj+1 an 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 Smith North Rye 27 Smith Main 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--.

57

Bases de Datos Regla de aumento multivaluada. Si se cumple y R y , entonces se cumple . Regla de transitividad multivaluada. Si se cumple y , entonces se cumple -. Regla de repeticin. Si se cumple , entonces se cumple . 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. n n n n 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_prstamo_cliente = (nombre_cliente, nmero_prstamo) 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.

58

Tema 6. Diseo de Bases de Datos relacionales. 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 b1 c1 g1 h1 a1 i1 a1 c1 g1 a2 b1 c2 g2 h2 a2 i2 a2 c2 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, b 1, c2, g2, h 1, i1). Sin embargo CGH(s) incluye una tupla (c2, g2, h 1) 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.

59

Bases de Datos 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, b 2, , b i) t1[R1R2]=(ai+1 , , aj) t2[R1R2]=(ai+1 , , aj) t1[R2-R1]=(aj+1 , , an) t2[R2-R1]=(bj+1 , , b n) 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 R2-R1 R1R2 t1 a1, a2, , ai ai+1 , , aj aj+1 , , an t2 b1, b 2, , b i ai+1 , , aj bj+1 , , b n t3 a1, a2, , ai ai+1 , , aj aj+1 , , an t4 b1, b 2, , b i ai+1 , , aj bj+1 , , b n 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 b1 c2 a1 b1 c2 a2 b1 c1 a2 b1 c1 a1 b2 c1 a1 b2 c1 a1 b1 c1 a1 b1 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.

60

Tema 6. Diseo de Bases de Datos relacionales. 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(A i). 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.

61

Bases de Datos

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.

62

Tema 6. Diseo de Bases de Datos relacionales.

63

Tema 7. Estructura de archivos y sistemas.

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.

65

Bases de Datos 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 latencia del 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

66

Tema 7. Estructura de archivos y sistemas. 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

67

Bases de Datos 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.

68

Tema 7. Estructura de archivos y sistemas. 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

69

Bases de Datos 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.

70

Tema 7. Estructura de archivos y sistemas. 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.

71

Tema 8. Indexacin y asociatividad (hashing).

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.

73

Bases de Datos 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+.

74

Tema 8. Indexacin y asociatividad (hashing). 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 K i<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 K i 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 K i y mayores o iguales a K i-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 K 1. 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.

75

Bases de Datos 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

76

Tema 8. Indexacin y asociatividad (hashing). 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 K i, la clave de bsqueda ms pequea que aparece en el subrbol del puntero Pi+1 debe pasarse al campo que antes ocupaba K i. 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 {K 1, 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, K 5 y K 7, 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 K i, 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 K i, 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

77

Bases de Datos 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 K l, 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

78

Tema 8. Indexacin y asociatividad (hashing). 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 i j 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 K l, 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.

79

Bases de Datos 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.

80

Tema 8. Indexacin y asociatividad (hashing). 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.

81