Bases de Datos

Mercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

Bases de datos

Mercedes Marqus

Departament Denginyeria i CinCia Dels ComputaDors

Codi dassignatura IG18


Edita: Publicacions de la Universitat Jaume I. Servei de Comunicaci i Publicacions Campus del Riu Sec. Edifici Rectorat i Serveis Centrals. 12071 Castell de la Plana http://www.tenda.uji.es e-mail: [email protected]

Collecci Sapientia, 18Primera edici, 2011www.sapientia.uji.es

ISBN: 978-84-693-0146-3

Aquest text est subjecte a una llicncia Reconeixement-NoComercial-Compartir Igual de Creative Commons, que permet copiar, distribuir i comunicar pblicament lobra sempre que especifique lautor i el nom de la publicaci i sense objectius comercials, i tamb permet crear obres derivades, sempre que siguen distribudes amb aquesta mateixa llicncia.http://creativecommons.org/licenses/by-nc-sa/2.5/es/deed.ca

iiiMercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

ndice general

1. Conceptos de bases de datos 11.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Sistema de gestin de bases de datos . . . . . . . . . . . . . . . 31.3. Personas en el entorno de las bases de datos . . . . . . . . . . . 41.4. Historia de los sistemas de bases de datos . . . . . . . . . . . . . 51.5. Ventajas e inconvenientes . . . . . . . . . . . . . . . . . . . . . . 9

2. Modelo relacional 132.1. Modelos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2. Estructura de datos relacional . . . . . . . . . . . . . . . . . . . 16

2.2.1. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2. Propiedades de las relaciones . . . . . . . . . . . . . . . . 192.2.3. Tipos de relaciones . . . . . . . . . . . . . . . . . . . . . 202.2.4. Claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3. Esquema de una base de datos relacional . . . . . . . . . . . . . 222.4. Reglas de integridad . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.1. Nulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.2. Regla de integridad de entidades . . . . . . . . . . . . . 252.4.3. Regla de integridad referencial . . . . . . . . . . . . . . . 262.4.4. Reglas de negocio . . . . . . . . . . . . . . . . . . . . . . 28

3. Lenguajes relacionales 293.1. Manejo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. lgebra relacional . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3. Clculo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1. Clculo orientado a tuplas . . . . . . . . . . . . . . . . . 373.3.2. Clculo orientado a dominios . . . . . . . . . . . . . . . 39

3.4. Otros lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4. Lenguaje SQL 414.1. Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . . 424.2. Descripcin de la base de datos . . . . . . . . . . . . . . . . . . 424.3. Visin general del lenguaje . . . . . . . . . . . . . . . . . . . . . 44

4.3.1. Creacin de tablas . . . . . . . . . . . . . . . . . . . . . 45

iii

ivMercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

4.3.2. Insercin de datos . . . . . . . . . . . . . . . . . . . . . . 484.3.3. Consulta de datos . . . . . . . . . . . . . . . . . . . . . . 484.3.4. Actualizacin y eliminacin de datos . . . . . . . . . . . 49

4.4. Estructura bsica de la sentencia SELECT . . . . . . . . . . . . . 494.4.1. Expresiones en SELECT y WHERE . . . . . . . . . . . . . . 504.4.2. Nulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.3. Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . 51

4.5. Funciones y operadores . . . . . . . . . . . . . . . . . . . . . . . 514.5.1. Operadores lgicos . . . . . . . . . . . . . . . . . . . . . 514.5.2. Operadores de comparacin . . . . . . . . . . . . . . . . 524.5.3. Operadores matemticos . . . . . . . . . . . . . . . . . . 524.5.4. Funciones matemticas . . . . . . . . . . . . . . . . . . . 534.5.5. Operadores y funciones de cadenas de caracteres . . . . . 534.5.6. Operadores y funciones de fecha . . . . . . . . . . . . . . 554.5.7. Funcin CASE . . . . . . . . . . . . . . . . . . . . . . . . 574.5.8. Funciones COALESCE y NULLIF . . . . . . . . . . . . . . . 574.5.9. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6. Operaciones sobre conjuntos de las . . . . . . . . . . . . . . . . 594.6.1. Funciones de columna . . . . . . . . . . . . . . . . . . . 604.6.2. Clusula GROUP BY . . . . . . . . . . . . . . . . . . . . . 624.6.3. Clusula HAVING . . . . . . . . . . . . . . . . . . . . . . 634.6.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.6.5. Algunas cuestiones importantes . . . . . . . . . . . . . . 65

4.7. Subconsultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.7.1. Subconsultas en la clusula WHERE . . . . . . . . . . . . . 664.7.2. Subconsultas en la clusula HAVING . . . . . . . . . . . . 724.7.3. Subconsultas en la clusula FROM . . . . . . . . . . . . . 734.7.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.7.5. Algunas cuestiones importantes . . . . . . . . . . . . . . 75

4.8. Consultas multitabla . . . . . . . . . . . . . . . . . . . . . . . . 764.8.1. La concatenacin: JOIN . . . . . . . . . . . . . . . . . . . 764.8.2. Sintaxis original de la concatenacin . . . . . . . . . . . 804.8.3. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.8.4. Algunas cuestiones importantes . . . . . . . . . . . . . . 82

4.9. Operadores de conjuntos . . . . . . . . . . . . . . . . . . . . . . 834.9.1. Operador UNION . . . . . . . . . . . . . . . . . . . . . . . 844.9.2. Operador INTERSECT . . . . . . . . . . . . . . . . . . . . 844.9.3. Operador EXCEPT . . . . . . . . . . . . . . . . . . . . . . 854.9.4. Sentencias equivalentes . . . . . . . . . . . . . . . . . . . 854.9.5. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.10. Subconsultas correlacionadas . . . . . . . . . . . . . . . . . . . . 874.10.1. Referencias externas . . . . . . . . . . . . . . . . . . . . 884.10.2. Operadores EXISTS, NOT EXISTS . . . . . . . . . . . . . 884.10.3. Sentencias equivalentes . . . . . . . . . . . . . . . . . . . 89

iv

vMercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

4.10.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5. Diseo de bases de datos 945.1. Necesidad de metodologas de diseo . . . . . . . . . . . . . . . 955.2. Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2.1. Planicacin del proyecto . . . . . . . . . . . . . . . . . 975.2.2. Denicin del sistema . . . . . . . . . . . . . . . . . . . . 985.2.3. Recoleccin y anlisis de los requisitos . . . . . . . . . . 985.2.4. Diseo de la base de datos . . . . . . . . . . . . . . . . . 995.2.5. Seleccin del SGBD . . . . . . . . . . . . . . . . . . . . . 995.2.6. Diseo de la aplicacin . . . . . . . . . . . . . . . . . . . 995.2.7. Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . 1005.2.8. Implementacin . . . . . . . . . . . . . . . . . . . . . . . 1005.2.9. Conversin y carga de datos . . . . . . . . . . . . . . . . 1015.2.10. Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.11. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . 101

5.3. Diseo de bases de datos . . . . . . . . . . . . . . . . . . . . . . 1015.3.1. Diseo conceptual . . . . . . . . . . . . . . . . . . . . . . 1025.3.2. Diseo lgico . . . . . . . . . . . . . . . . . . . . . . . . 1025.3.3. Diseo fsico . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.4. Diseo de transacciones . . . . . . . . . . . . . . . . . . . . . . . 1045.5. Herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . 105

6. Diseo conceptual 1066.1. Modelo entidad-relacin . . . . . . . . . . . . . . . . . . . . . . 106

6.1.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.1.2. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.1.3. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.1.4. Dominios . . . . . . . . . . . . . . . . . . . . . . . . . . 1146.1.5. Identicadores . . . . . . . . . . . . . . . . . . . . . . . . 1146.1.6. Jerarquas de generalizacin . . . . . . . . . . . . . . . . 1156.1.7. Diagrama entidad-relacin . . . . . . . . . . . . . . . . . 116

6.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.3. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7. Diseo lgico relacional 1257.1. Esquema lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.2. Metodologa de diseo . . . . . . . . . . . . . . . . . . . . . . . 127

7.2.1. Entidades fuertes . . . . . . . . . . . . . . . . . . . . . . 1287.2.2. Entidades dbiles . . . . . . . . . . . . . . . . . . . . . . 1297.2.3. Relaciones binarias . . . . . . . . . . . . . . . . . . . . . 1307.2.4. Jerarquas de generalizacin . . . . . . . . . . . . . . . . 1367.2.5. Normalizacin . . . . . . . . . . . . . . . . . . . . . . . . 137

7.3. Restricciones de integridad . . . . . . . . . . . . . . . . . . . . . 142

v

viMercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

7.4. Desnormalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . 1447.5. Reglas de comportamiento de las claves ajenas . . . . . . . . . . 1467.6. Cuestiones adicionales . . . . . . . . . . . . . . . . . . . . . . . 1497.7. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

8. Diseo fsico en SQL 1538.1. Metodologa de diseo . . . . . . . . . . . . . . . . . . . . . . . 154

8.1.1. Traducir el esquema lgico . . . . . . . . . . . . . . . . . 1548.1.2. Disear la representacin fsica . . . . . . . . . . . . . . 1568.1.3. Disear los mecanismos de seguridad . . . . . . . . . . . 1608.1.4. Monitorizar y anar el sistema . . . . . . . . . . . . . . . 161

8.2. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

vi

157161162162

viiMercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

Prefacio

Este texto se ha elaborado para dar soporte a un curso sobre Bases deDatos orientado a las Ingenieras Informticas.

Los cuatro primeros captulos realizan un estudio del modelo relacional:la estructura de datos, las reglas para mantener la integridad de la base dedatos y los lenguajes relacionales, que se utilizan para manipular las bases dedatos. Dentro de los lenguajes relacionales se hace una presentacin exahustivadel lenguaje SQL, que es el lenguaje estndar de acceso a las bases de datosrelacionales.

Los cuatro captulos que vienen despus plantean una metodologa de di-seo de bases de datos relacionales, comenzando por el diseo conceptual me-diante el modelo entidad-relacin. La siguiente etapa del diseo se abordaestableciendo una serie de reglas para obtener el esquema lgico de la base dedatos, y la tercera y ltima etapa trata del diseo fsico en SQL, al que se haceuna introduccin en el ltimo captulo de este texto.

Un estudio ms profundo del diseo fsico de bases de datos, as como elestudio de la funcionalidad de los sistemas de gestin de bases de datos, sontemas que se deben incluir en un curso ms avanzado sobre la materia.

Al comienzo de cada captulo se incluye un apartado titulado Introducciny objetivos en el que se motiva el estudio del tema y se plantean los objetivosde aprendizaje que debe conseguir el estudiante. El texto incluye ejemplosy ejercicios resueltos, para ayudar a la comprensin de los contenidos. Estematerial se complementa con actividades a realizar por el estudiante, que sernpublicadas en un entorno virtual de aprendizaje.

Aunque existe una amplia bibliografa sobre bases de datos, al nal deltexto se incluye slo una breve seleccin de aquellos textos que han tenido msrelevancia para la autora de estos apuntes.

1Mercedes Marqus - ISBN: 978-84-693-0146-3 Bases de datos - UJI

Captulo 1

Conceptos de bases de datos

Introduccin y objetivos

El inicio de un curso sobre bases de datos debe ser, sin duda, la denicinde base de datos y la presentacin de los sistemas de gestin de bases de datos(el software que facilita la creacin y manipulacin de las mismas por partedel personal informtico). Algunos de estos sistemas, ampliamente utilizados,son PostgreSQL, MySQL y Oracle.

Ya que este texto est dirigido a estudiantado de las ingenieras inform-ticas, es interesante conocer qu papeles puede desempear el personal infor-mtico en el entorno de una base de datos. stas han tenido sus predecesoresen los sistemas de cheros y tienen por delante un amplio horizonte, por loque antes de comenzar su estudio resulta conveniente ubicarse en el tiempohaciendo un recorrido por su evolucin histrica. El captulo termina con unaexposicin sobre las ventajas y desventajas que las bases de datos conllevan.

Al nalizar este captulo, el estudiantado debe ser capaz de:

Denir qu es una base de datos y qu es un sistema de gestin de basesde datos.

Reconocer los subsistemas que forman parte de un sistema de gestin debases de datos.

Enumerar las personas que aparecen en el entorno de una base de datosy sus tareas.

Asociar los distintos tipos de sistemas de gestin de bases de datos a lasgeneraciones a las que pertenecen.

Enumerar las ventajas y desventajas de los sistemas de bases de datos yasociarlas al motivo por el que se producen: la integracin de datos o elsistema de gestin de la base de datos.

1


1.1. Base de datos

Una base de datos es un conjunto de datos almacenados en memoria externaque estn organizados mediante una estructura de datos. Cada base de datosha sido diseada para satisfacer los requisitos de informacin de una empresau otro tipo de organizacin, como por ejemplo, una universidad o un hospital.

Antes de existir las bases de datos se trabajaba con sistemas de cheros.Los sistemas de cheros surgieron al informatizar el manejo de los archivadoresmanuales para proporcionar un acceso ms eciente a los datos almacenadosen los mismos. Un sistema de cheros sigue un modelo descentralizado, en elque cada departamento de la empresa almacena y gestiona sus propios datosmediante una serie de programas de aplicacin escritos especialmente para l.Estos programas son totalmente independientes entre un departamento y otro,y se utilizan para introducir datos, mantener los cheros y generar los informesque cada departamento necesita. Es importante destacar que en los sistemasde cheros, tanto la estructura fsica de los cheros de datos como la de susregistros, estn denidas dentro de los programas de aplicacin.

Cuando en una empresa se trabaja con un sistema de cheros, los departa-mentos no comparten informacin ni aplicaciones, por lo que los datos comunesdeben estar duplicados en cada uno de ellos. Esto puede originar inconsisten-cias en los datos. Se produce una inconsistencia cuando copias de los mismosdatos no coinciden: dos copias del domicilio de un cliente pueden no coincidirsi slo uno de los departamentos que lo almacenan ha sido informado de queel domicilio ha cambiado.

Otro inconveniente que plantean los sistemas de cheros es que cuando losdatos se separan en distintos cheros, es ms complicado acceder a ellos, yaque el programador de aplicaciones debe sincronizar el procesamiento de losdistintos cheros implicados para garantizar que se extraen los datos correctos.Adems, ya que la estructura fsica de los datos se encuentra especicada enlos programas de aplicacin, cualquier cambio en dicha estructura es difcil derealizar. El programador debe identicar todos los programas afectados por elcambio, modicarlos y volverlos a probar, lo que cuesta mucho tiempo y estsujeto a que se produzcan errores. A este problema, tan caracterstico de lossistemas de cheros, se le denomina tambin falta de independencia de datoslgica-fsica.

Una base de datos se puede percibir como un gran almacn de datos quese dene y se crea una sola vez, y que se utiliza al mismo tiempo por distintosusuarios. En una base de datos todos los datos se integran con una mnimacantidad de duplicidad. De este modo, la base de datos no pertenece a un solodepartamento sino que se comparte por toda la organizacin. Adems, la basede datos no slo contiene los datos de la organizacin, tambin almacena unadescripcin de dichos datos. Esta descripcin es lo que se denomina metadatos,se almacena en el diccionario de datos o catlogo y es lo que permite que existaindependencia de datos lgica-fsica.

2


1.2. Sistema de gestin de bases de datos

El sistema de gestin de la base de datos (en adelante SGBD) es una apli-cacin que permite a los usuarios denir, crear y mantener la base de datos,adems de proporcionar un acceso controlado a la misma. Se denomina sistemade bases de datos al conjunto formado por la base de datos, el SGBD y losprogramas de aplicacin que dan servicio a la empresa u organizacin.

El modelo seguido con los sistemas de bases de datos es muy similar almodelo que se sigue en la actualidad para el desarrollo de programas con len-guajes orientados a objetos, en donde se da una implementacin interna de unobjeto y una especicacin externa separada. Los usuarios del objeto slo venla especicacin externa y no se deben preocupar de cmo se implementa in-ternamente el objeto. Una ventaja de este modelo, conocido como abstraccinde datos, es que se puede cambiar la implementacin interna de un objeto sinafectar a sus usuarios ya que la especicacin externa no se ve alterada. Delmismo modo, los sistemas de bases de datos separan la denicin de la estruc-tura fsica de los datos de su estructura lgica, y almacenan esta denicin enla base de datos. Todo esto es gracias a la existencia del SGBD, que se sitaentre la base de datos y los programas de aplicacin.

Generalmente, un SGBD proporciona los servicios que se citan a continua-cin:

El SGBD permite la denicin de la base de datos mediante un lenguajede denicin de datos. Este lenguaje permite especicar la estructura yel tipo de los datos, as como las restricciones sobre los datos.

El SGBD permite la insercin, actualizacin, eliminacin y consulta dedatos mediante un lenguaje de manejo de datos. El hecho de disponerde un lenguaje para realizar consultas reduce el problema de los siste-mas de cheros, en los que el usuario tiene que trabajar con un conjuntojo de consultas, o bien, dispone de un gran nmero de programas deaplicacin costosos de gestionar. Hay dos tipos de lenguajes de mane-jo de datos: los procedurales y los no procedurales. Estos dos tipos sedistinguen por el modo en que acceden a los datos. Los lenguajes pro-cedurales manipulan la base de datos registro a registro, mientras quelos no procedurales operan sobre conjuntos de registros. En los lenguajesprocedurales se especica qu operaciones se debe realizar para obtenerlos datos resultado, mientras que en los lenguajes no procedurales se es-pecica qu datos deben obtenerse sin decir cmo hacerlo. El lenguajeno procedural ms utilizado es el SQL (Structured Query Language) que,de hecho, es un estndar y es el lenguaje de los SGBD relacionales.

El SGBD proporciona un acceso controlado a la base de datos mediante:

Un sistema de seguridad, de modo que los usuarios no autorizadosno puedan acceder a la base de datos.

3


Un sistema de integridad que mantiene la integridad y la consisten-cia de los datos.

Un sistema de control de concurrencia que permite el acceso com-partido a la base de datos.

Un sistema de control de recuperacin que restablece la base de da-tos despus de que se produzca un fallo del hardware o del software.

Un diccionario de datos o catlogo, accesible por el usuario, quecontiene la descripcin de los datos de la base de datos.

A diferencia de los sistemas de cheros, en los que los programas de aplica-cin trabajan directamente sobre los cheros de datos, el SGBD se ocupa de laestructura fsica de los datos y de su almacenamiento. Con esta funcionalidad,el SGBD se convierte en una herramienta de gran utilidad. Sin embargo, desdeel punto de vista del usuario, se podra discutir que los SGBD han hecho lascosas ms complicadas, ya que ahora los usuarios ven ms datos de los querealmente quieren o necesitan, puesto que ven la base de datos completa. Cons-cientes de este problema, los SGBD proporcionan un mecanismo de vistas quepermite que cada usuario tenga su propia vista o visin de la base de datos. Ellenguaje de denicin de datos permite denir vistas como subconjuntos de labase de datos.

Todos los SGBD no presentan la misma funcionalidad, depende de cadaproducto. En general, los grandes SGBD multiusuario ofrecen todas las funcio-nes que se acaban de citar e incluso ms. Los sistemas modernos son conjuntosde programas extremadamente complejos y sosticados, con millones de lneasde cdigo y con una documentacin consistente en varios volmenes. Lo quese pretende es proporcionar un sistema que permita gestionar cualquier tipode requisitos y que tenga un 100% de abilidad ante cualquier tipo de fallo.Los SGBD estn en continua evolucin, tratando de satisfacer los requisitos detodo tipo de usuarios. Por ejemplo, muchas aplicaciones de hoy en da necesi-tan almacenar imgenes, vdeo, sonido, etc. Para satisfacer a este mercado, losSGBD deben evolucionar. Conforme vaya pasando el tiempo, irn surgiendonuevos requisitos, por lo que los SGBD nunca permanecern estticos.

1.3. Personas en el entorno de las basesde datos

Hay cuatro grupos de personas que intervienen en el entorno de una basede datos: el administrador de la base de datos, los diseadores de la base dedatos, los programadores de aplicaciones y los usuarios.

El administrador de la base de datos se encarga de la implementacin fsicade la base de datos: escoge los tipos de los cheros de datos y de los ndices quedeben crearse, determina dnde deben ubicarse cheros e ndices y, en general,

4


toma las decisiones relativas al almacenamiento fsico en funcin de las posibi-lidades que le ofrezca el SGBD con el que trabaje. Adems, el administradorde la base de datos se encarga de establecer la poltica de seguridad y delacceso concurrente. Tambin se debe preocupar de que el sistema se encuen-tre siempre operativo y procurar que los usuarios y las aplicaciones obtenganbuenas prestaciones. El administrador debe conocer muy bien el SGBD con elque trabaja, as como el equipo informtico sobre el que est funcionando.

Los diseadores de la base de datos realizan el diseo de la base de datos,debiendo identicar los datos, las relaciones entre ellos y las restricciones sobrelos datos y sobre sus relaciones. El diseador de la base de datos debe tener unprofundo conocimiento de los datos de la empresa y tambin debe conocer susreglas de negocio. Las reglas de negocio describen las caractersticas principalessobre el comportamiento de los datos tal y como las ve la empresa. Para obtenerun buen resultado, el diseador de la base de datos debe implicar en el procesoa todos los usuarios de la base de datos, tan pronto como sea posible.

Una vez se ha diseado e implementado la base de datos, los programadoresde aplicaciones se encargan de implementar los programas de aplicacin queservirn a los usuarios nales. Estos programas de aplicacin son los que per-miten consultar datos, insertarlos, actualizarlos y eliminarlos. Estos programasse escriben mediante lenguajes de tercera generacin o de cuarta generacin.

Los usuarios nales son los clientes de la base de datos: la base de datosha sido diseada e implementada, y est siendo mantenida, para satisfacer susrequisitos en la gestin de su informacin.

1.4. Historia de los sistemas de bases de datos

Los predecesores de los sistemas de bases de datos fueron los sistemas decheros. Un sistema de cheros est formado por un conjunto de cheros dedatos y los programas de aplicacin que permiten a los usuarios nales trabajarsobre los mismos. No hay un momento concreto en el que los sistemas decheros hayan cesado y hayan dado comienzo los sistemas de bases de datos.De hecho, todava existen sistemas de cheros en uso.

Se dice que los sistemas de bases de datos tienen sus races en el proyectoestadounidense de mandar al hombre a la luna en los aos sesenta, el proyectoApolo. En aquella poca, no haba ningn sistema que permitiera gestionar lainmensa cantidad de informacin que requera el proyecto. La primera empre-sa encargada del proyecto, NAA (North American Aviation), desarroll unaaplicacin denominada GUAM (General Update Access Method) que estababasada en el concepto de que varias piezas pequeas se unen para formar unapieza ms grande, y as sucesivamente hasta que el producto nal est ensam-blado. Esta estructura, que tiene la forma de un rbol, es lo que se denominauna estructura jerrquica. A mediados de los sesenta, IBM se uni a NAA pa-ra desarrollar GUAM en lo que despus fue IMS (Information Management

5


System). El motivo por el cual IBM restringi IMS al manejo de jerarquas deregistros fue el de permitir el uso de dispositivos de almacenamiento serie, msexactamente las cintas magnticas, ya que era un requisito del mercado poraquella poca.

A mitad de los sesenta, General Electric desarroll IDS (Integrated DataStore). Este trabajo fue dirigido por uno de los pioneros en los sistemas debases de datos, Charles Bachmann. IDS era un nuevo tipo de sistema de basesde datos conocido como sistema de red, que produjo un gran efecto sobre lossistemas de informacin de aquella generacin. El sistema de red se desarroll,en parte, para satisfacer la necesidad de representar relaciones entre datos mscomplejas que las que se podan modelar con los sistemas jerrquicos y, enparte, para imponer un estndar de bases de datos. Para ayudar a establecerdicho estndar, el grupo CODASYL (Conference on Data Systems Langua-ges), formado por representantes del gobierno de EEUU y representantes delmundo empresarial, fundaron un grupo denominado DBTG (Data Base TaskGroup), cuyo objetivo era denir unas especicaciones estndar que permitie-ran la creacin de bases de datos y el manejo de los datos. El DBTG presentsu informe nal en 1971 y aunque ste no fue formalmente aceptado por AN-SI (American National Standards Institute), muchos sistemas se desarrollaronsiguiendo la propuesta del DBTG. Estos sistemas son los que se conocen comosistemas de red, sistemas CODASYL o DBTG.

Los sistemas jerrquico y de red constituyen la primera generacin de losSGBD. Estos sistemas presentan algunos inconvenientes:

Es necesario escribir complejos programas de aplicacin para respondera cualquier tipo de consulta de datos, por simple que sta sea.

La independencia de datos es mnima.

No tienen un fundamento terico.

En 1970, Edgar Frank Codd de los laboratorios de investigacin de IBM,escribi un artculo presentando el modelo relacional. En este artculo presenta-ba tambin los inconvenientes de los sistemas previos, el jerrquico y el de red.Pas casi una dcada hasta que se desarrollaron los primeros sistemas relacio-nales. Uno de los primeros es System R, de IBM, que se desarroll para probarla funcionalidad del modelo relacional, proporcionando una implementacinde sus estructuras de datos y sus operaciones. Esto condujo a dos grandesdesarrollos:

El desarrollo de un lenguaje de consultas estructurado denominado SQL,que se ha convertido en el lenguaje estndar de los sistemas relacionales.

La produccin de varios SGBD relacionales durante los aos ochenta,como DB2 y SLQ/DS, de IBM, y Oracle, de Oracle Corporation.

6


Hoy en da, existen cientos de SGBD relacionales, tanto para microordenadorescomo para sistemas multiusuario, aunque muchos no son completamente elesal modelo relacional.

Los SGBD relacionales constituyen la segunda generacin de los SGBD.Sin embargo, el modelo relacional tambin tiene sus debilidades, siendo unade ellas su limitada capacidad al modelar los datos. Se ha desarrollado muchainvestigacin desde entonces tratando de resolver este problema. En 1976, Pe-ter Chen present el modelo entidad-relacin, que es la tcnica ms utilizadaen el diseo de bases de datos. En 1979, Codd intent subsanar algunas delas deciencias de su modelo relacional con una versin extendida denominadaRM/T (1979) y ms recientemente RM/V2 (1990). Los intentos de proporcio-nar un modelo de datos que represente al mundo real de un modo ms el handado lugar a los modelos de datos semnticos.

La evolucin reciente de la tecnologa de bases de datos viene marcada poruna mayor solidez en las bases de datos orientadas a objetos, la extensin delas bases de datos relacionales y el procesamiento distribuido. Esta evolucinrepresenta la tercera generacin de los SGBD.

Por su parte, los sistemas de gestin de bases de datos relacionales han idoevolucionando estos ltimos aos para soportar objetos y reglas, y para ampliarel lenguaje SQL y hacerlo ms extensible y computacionalmente completo,dando lugar a lo que se conoce como sistemas objeto-relacionales.

Durante la ltima dcada, el impacto de los avances en la tecnologa delas comunicaciones ha sido muy importante. Esto ha contribuido a que en lasempresas se haya producido una mayor distribucin de la gestin automticade la informacin, en contraste con la losofa centralizadora predominanteen la tecnologa inicial de bases de datos. Las bases de datos distribuidasposibilitan el procesamiento de datos pertenecientes a distintas bases de datosconectadas entre s. El emplazamiento lgico de cada una de las bases de datosse denomina nodo, conteniendo cada uno su sistema de gestin de bases dedatos, junto con las utilidades y facilidades propias del soporte distribuido.Los nodos, por lo general, estn ubicados en emplazamientos fsicos distantesgeogrcamente, y se encuentran conectados por una red de comunicacin dedatos.

Por otra parte, los sistemas de bases de datos activas han sido propuestoscomo otro paradigma de gestin de datos que satisface las necesidades de aque-llas aplicaciones que requieren una respuesta puntual ante situaciones crticas.Como ejemplos se puede citar el control del trco areo o las aplicaciones decontrol de plantas industriales. Este paradigma tambin puede ser utilizadopara soportar varias de las funciones del propio sistema de gestin de bases dedatos, como son: el control de accesos, el control de la integridad, el manteni-miento de vistas o el mantenimiento de atributos derivados. El factor comnen todas estas aplicaciones es la necesidad de responder a sucesos, tanto ex-ternos como internos al propio sistema. A diferencia de los sistemas pasivos,un sistema de gestin de bases de datos activas responde automticamente

7


ante determinadas circunstancias descritas por el diseador. La mayora de lossistemas de gestin de bases de datos comerciales incorporan la posibilidad dedenir reglas, por lo que son, en cierto modo, sistemas activos.

Las investigaciones sobre la relacin entre la teora de las bases de datos yla lgica se remontan a nales de la dcada de los setenta. Estas investigacioneshan dado lugar a las bases de datos deductivas, que permiten derivar nuevasinformaciones a partir de las introducidas explcitamente por el usuario. Estafuncin deductiva se realiza mediante la adecuada explotacin de ciertas re-glas de conocimiento relativas al dominio de la aplicacin, utilizando para ellotcnicas de programacin lgica y de inteligencia articial.

Los sistemas de mltiples bases de datos permiten realizar operaciones queimplican a varios sistemas de bases de datos, cada uno de los cuales puede sercentralizado o distribuido. Cada sistema de bases de datos que participa esdenominado componente. Si todos los sistemas de gestin de bases de datos delos diferentes componentes son iguales, el sistema de mltiples bases de datoses homogneo; en caso contrario, es heterogneo. Un sistema de mltiples basesde datos es un sistema federado de bases de datos si permite una doble gestin:una de carcter global, realizada por el sistema de gestin de bases de datosfederadas y otra en modo autnomo e independiente del sistema federado,realizada por parte de los sistemas componentes.

La inuencia de la Web lo abarca todo. En su desarrollo se han ignoradolas tcnicas de bases de datos, por lo que se han repetido los errores cometidosen las primeras generaciones de los sistemas de gestin de bases de datos.La Web se puede ver como una nueva interfaz de acceso a bases de datos, ymuchos sistemas de gestin de bases de datos ya proporcionan almacenamientoy acceso a datos a travs de XML. Pero la Web puede tambin ser consideradacomo una inmensa base de datos, siendo ste un tema de investigacin en plenoauge.

Por otra parte, los grandes almacenes de datos (data warehouses) ya handemostrado que si son implementados convenientemente, pueden ser de granayuda en la toma de decisiones y en el procesamiento analtico en tiempo realOLAP (On-Line Analytical Processing). Los datos son extrados peridicamen-te de otras fuentes y son integrados en el almacn. Estos datos, relevantes parala empresa, son no-voltiles y se agrupan segn diversas granularidades en eltiempo y en otras dimensiones. En la actualidad, existe una gran competenciaentre las extensiones de los sistemas de gestin de bases de datos comercialespara incorporar las caractersticas de este tipo de sistemas, y la creacin deproductos especcos.

La explotacin de datos (data mining o knowledge discovery in databases)trata de descubrir conocimientos tiles y previamente no conocidos a partir degrandes volmenes de datos, por lo que no slo integra tcnicas de bases dedatos, sino tambin de estadstica y de inteligencia articial. Las investigacio-nes se han plasmado rpidamente en productos comerciales, con un desarrolloreciente bastante importante.

8


Existen tambin muchos trabajos de investigacin en temas tales como lasbases de datos temporales y las bases de datos multimedia. Las bases de datostemporales intentan, en primer lugar, denir un modelo de datos que capturela semntica del tiempo en el mundo real, y, en segundo lugar, realizar unaimplementacin eciente de tal modelo. Los recientes avances en el almacena-miento de distintos tipos de informacin, como voz, imgenes o sonido, hantenido su inuencia en las bases de datos, dando lugar a las bases de datosmultimedia.

La rpida evolucin que la tecnologa de bases de datos ha experimentadoen la ltima dcada, as como la variedad de nuevos caminos abiertos, hanconducido a investigadores y asociaciones interesadas, a reexionar sobre elfuturo de esta tecnologa. Estas reexiones quedan recogidas en numerososdebates y maniestos que intentan poner orden en un campo en continuaexpansin.

1.5. Ventajas e inconvenientes de los sistemas debases de datos

Los sistemas de bases de datos presentan numerosas ventajas gracias, fun-damentalmente, a la integracin de datos y a la interfaz comn que proporcionael SGBD. Estas ventajas se describen a continuacin.

Control sobre la redundancia de datos. Los sistemas de cheros almace-nan varias copias de los mismos datos en cheros distintos. Esto haceque se desperdicie espacio de almacenamiento, adems de provocar fal-tas de consistencia de datos (copias que no coinciden). En los sistemasde bases de datos todos estos cheros estn integrados, por lo que no sealmacenan varias copias de los mismos datos. Sin embargo, en una basede datos no se puede eliminar la redundancia completamente, ya que enocasiones es necesaria para modelar las relaciones entre los datos, o bienes necesaria para mejorar las prestaciones.

Control sobre la consistencia de datos. Eliminando o controlando las re-dundancias de datos se reduce en gran medida el riesgo de que hayainconsistencias. Si un dato est almacenado una sola vez, cualquier ac-tualizacin se debe realizar slo una vez, y est disponible para todos losusuarios inmediatamente. Si un dato est duplicado y el sistema conoceesta redundancia, el propio sistema puede encargarse de garantizar quetodas las copias se mantengan consistentes. Desgraciadamente, no todoslos SGBD de hoy en da se encargan de mantener automticamente laconsistencia.

Comparticin de datos. En los sistemas de cheros, los cheros pertene-cen a los departamentos que los utilizan, pero en los sistemas de bases de

9


datos, la base de datos pertenece a la empresa y puede ser compartidapor todos los usuarios que estn autorizados. Adems, las nuevas aplica-ciones que se vayan creando pueden utilizar los datos de la base de datosexistente.

Mantenimiento de estndares. Gracias a la integracin es ms fcil respe-tar los estndares necesarios, tanto los establecidos a nivel de la empresacomo los nacionales e internacionales. Estos estndares pueden estable-cerse sobre el formato de los datos para facilitar su intercambio; puedenser estndares de documentacin, procedimientos de actualizacin y tam-bin reglas de acceso.

Mejora en la integridad de datos. La integridad de la base de datos sereere a la validez de los datos almacenados. Normalmente, la integridadse expresa mediante restricciones o reglas que no se pueden violar. Estasrestricciones se pueden aplicar tanto a los datos, como a sus relaciones,y es el SGBD quien se encargar de mantenerlas.

Mejora en la seguridad. La seguridad de la base de datos consiste la pro-teccin de la base de datos frente a usuarios no autorizados. Sin unasbuenas medidas de seguridad, la integracin de datos en los sistemas debases de datos hace que stos sean ms vulnerables que en los sistemasde cheros. Sin embargo, los SGBD permiten mantener la seguridad me-diante el establecimiento de claves para identicar al personal autorizadoa utilizar la base de datos. Las autorizaciones se pueden realizar a ni-vel de operaciones, de modo que un usuario puede estar autorizado aconsultar ciertos datos pero no a actualizarlos, por ejemplo.

Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan len-guajes de consulta o generadores de informes que permiten al usuariohacer cualquier tipo de consulta sobre los datos, sin que sea necesarioque un programador escriba una aplicacin que realice tal tarea.

Mejora en la productividad. El SGBD proporciona muchas de las fun-ciones estndar que el programador necesita escribir en un sistema decheros. A nivel bsico, el SGBD proporciona todas las rutinas de mane-jo de cheros tpicas de los programas de aplicacin. El hecho de disponerde estas funciones permite al programador centrarse mejor en la funcinespecca requerida por los usuarios, sin tener que preocuparse de losdetalles de implementacin de bajo nivel. Muchos SGBD tambin pro-porcionan un entorno de cuarta generacin consistente en un conjunto deherramientas que simplican, en gran medida, el desarrollo de las apli-caciones que acceden a la base de datos. Gracias a estas herramientas,el programador puede ofrecer una mayor productividad en un tiempomenor.

10


Mejora en el mantenimiento gracias a la independencia de datos. En lossistemas de cheros, las descripciones de los datos se encuentran inmer-sas en los programas de aplicacin que los manejan. Esto hace que losprogramas sean dependientes de los datos, de modo que un cambio en suestructura, o un cambio en el modo en que se almacena en disco, requierecambios importantes en los programas cuyos datos se ven afectados. Sinembargo, los SGBD separan las descripciones de los datos de las aplica-ciones. Esto es lo que se conoce como independencia de datos, gracias ala cual se simplica el mantenimiento de las aplicaciones que acceden ala base de datos.

Aumento de la concurrencia. En algunos sistemas de cheros, si hay va-rios usuarios que pueden acceder simultneamente a un mismo chero,es posible que el acceso interera entre ellos de modo que se pierda infor-macin o, incluso, que se pierda la integridad. La mayora de los SGBDgestionan el acceso concurrente a la base de datos y pueden garantizarque no ocurran problemas de este tipo.

Mejora en los servicios de copias de seguridad y de recuperacin antefallos. Muchos sistemas de cheros dejan que sea el usuario quien pro-porcione las medidas necesarias para proteger los datos ante fallos en elsistema o en las aplicaciones. Los usuarios tienen que hacer copias deseguridad cada da, y si se produce algn fallo, utilizar estas copias pararestaurarlos. En este caso, todo el trabajo realizado sobre los datos desdeque se hizo la ltima copia de seguridad se pierde y se tiene que volvera realizar. Sin embargo, los SGBD actuales funcionan de modo que seminimiza la cantidad de trabajo perdido cuando se produce un fallo.

La integracin de los datos y la existencia del SGBD tambin planteanciertos inconvenientes, como los que se citan a continuacin.

Alta complejidad. Los SGBD son conjuntos de programas muy comple-jos con una gran funcionalidad. Es preciso comprender muy bien estafuncionalidad para poder sacar un buen partido de ellos.

Gran tamao. Los SGBD son programas complejos y muy extensos querequieren una gran cantidad de espacio en disco y de memoria para tra-bajar de forma eciente.

Coste econmico del SGBD. El coste de un SGBD vara dependiendo delentorno y de la funcionalidad que ofrece. Por ejemplo, un SGBD para unordenador personal puede costar 500 e, mientras que un SGBD para unsistema multiusuario que d servicio a cientos de usuarios puede costarentre 10000 y 100000 e. Adems, hay que pagar una cuota anual demantenimiento que suele ser un porcentaje del precio del SGBD. En losltimos aos han surgido SGBD libres (open source) que ofrecen unagran funcionalidad y muy buenas prestaciones.

11


Coste del equipamiento adicional. Tanto el SGBD, como la propia basede datos, pueden hacer que sea necesario adquirir ms espacio de alma-cenamiento. Adems, para alcanzar las prestaciones deseadas, es posibleque sea necesario adquirir una mquina ms grande o una mquina quese dedique solamente al SGBD. Todo esto har que la implantacin deun sistema de bases de datos sea ms cara.

Coste de la conversin. En algunas ocasiones, el coste del SGBD y elcoste del equipo informtico que sea necesario adquirir para su buenfuncionamiento es insignicante comparado al coste de convertir la apli-cacin actual en un sistema de bases de datos. Este coste incluye el costede ensear a la plantilla a utilizar estos sistemas y, probablemente, elcoste del personal especializado para ayudar a realizar la conversin yponer en marcha el sistema. Este coste es una de las razones principalespor las que algunas empresas y organizaciones se resisten a cambiar susistema actual de cheros por un sistema de bases de datos.

Prestaciones. Un sistema de cheros est escrito para una aplicacin es-pecca, por lo que sus prestaciones suelen ser muy buenas. Sin embargo,los SGBD estn escritos para ser ms generales y ser tiles en muchasaplicaciones, lo que puede hacer que algunas de ellas no sean tan rpidascomo antes.

Vulnerable a los fallos. El hecho de que todo est centralizado en elSGBD hace que el sistema sea ms vulnerable ante los fallos que puedanproducirse.

12


Captulo 2

Modelo relacional


En este captulo se presentan los principios bsicos del modelo relacional,que es el modelo de datos en el que se basan la mayora de los SGBD en usohoy en da. En primer lugar, se presenta la estructura de datos relacional y acontinuacin las reglas de integridad que deben cumplirse sobre la misma.

Al nalizar este captulo, el estudiante debe ser capaz de:

Denir qu es un modelo de datos y describir cmo se clasican losmodelos de datos.

Denir los distintos modelos lgicos de bases de datos.

Denir la estructura de datos relacional y todas sus partes.

Enumerar las propiedades de las relaciones.

Denir los tipos de relaciones.

Denir superclave, clave candidata, clave primaria y clave ajena.

Denir el concepto de nulo.

Denir la regla de integridad de entidades y la regla de integridad refe-rencial.

Denir qu es una regla de negocio.

Dar un ejemplo completo de una base de datos formada por, al menos,dos relaciones con claves ajenas.

13


2.1. Modelos de datos

Una de las caractersticas fundamentales de los sistemas de bases de datoses que proporcionan cierto nivel de abstraccin de datos, al ocultar las caracte-rsticas sobre el almacenamiento fsico que la mayora de usuarios no necesitaconocer. Los modelos de datos son el instrumento principal para ofrecer di-cha abstraccin a travs de su jerarqua de niveles. Un modelo de datos es unconjunto de conceptos que sirven para describir la estructura de una base dedatos, es decir, los datos, las relaciones entre los datos y las restricciones quedeben cumplirse sobre los datos. Los modelos de datos contienen tambin unconjunto de operaciones bsicas para la realizacin de consultas (lecturas) yactualizaciones de datos. Adems, los modelos de datos ms modernos inclu-yen mecanismos para especicar acciones compensatorias o adicionales que sedeben llevar a cabo ante las acciones habituales que se realizan sobre la basede datos.

Los modelos de datos se pueden clasicar dependiendo de los tipos de con-ceptos que ofrecen para describir la estructura de la base de datos, formandouna jerarqua de niveles. Los modelos de datos de alto nivel, o modelos con-ceptuales, disponen de conceptos muy cercanos al modo en que la mayora delos usuarios percibe los datos, mientras que los modelos de datos de bajo nivel,o modelos fsicos, proporcionan conceptos que describen los detalles de cmose almacenan los datos en el ordenador. Los conceptos de los modelos fsicosestn dirigidos al personal informtico, no a los usuarios nales. Entre estosdos extremos se encuentran los modelos lgicos, cuyos conceptos pueden serentendidos por los usuarios nales, aunque no estn demasiado alejados de laforma en que los datos se organizan fsicamente. Los modelos lgicos ocultanalgunos detalles de cmo se almacenan los datos, pero pueden implementarsede manera directa en un SGBD.

Los modelos conceptuales utilizan conceptos como entidades, atributos yrelaciones. Una entidad representa un objeto o concepto del mundo real como,por ejemplo, un cliente de una empresa o una de sus facturas. Un atributorepresenta alguna propiedad de inters de una entidad como, por ejemplo, elnombre o el domicilio del cliente. Una relacin describe una interaccin entredos o ms entidades, por ejemplo, la relacin que hay entre un cliente y lasfacturas que se le han realizado.

Cada SGBD soporta un modelo lgico, siendo los ms comunes el relacional,el de red y el jerrquico. Estos modelos representan los datos valindose deestructuras de registros, por lo que tambin se denominan modelos orientadosa registros. Hay una familia ms moderna de modelos lgicos, son los modelosorientados a objetos, que estn ms prximos a los modelos conceptuales. Enel modelo relacional los datos se describen como un conjunto de tablas conreferencias lgicas entre ellas, mientras que en los modelos jerrquico y de red,los datos se describen como conjuntos de registros con referencias fsicas entreellos (punteros).

14


Los modelos fsicos describen cmo se almacenan los datos en el ordena-dor: el formato de los registros, la estructura de los cheros (desordenados,ordenados, agrupados) y los mtodos de acceso utilizados (ndices, tablas dedispersin).

A la descripcin de una base de datos mediante un modelo de datos se ledenomina esquema de la base de datos. Este esquema se especica durante eldiseo, y no es de esperar que se modique a menudo. Sin embargo, los datosque se almacenan en la base de datos pueden cambiar con mucha frecuencia:se insertan datos, se actualizan, se borran, etc. Los datos que la base de datoscontiene en un determinado momento conforman el estado de la base de datos,o como tambin se denomina: una ocurrencia de la base de datos.

La distincin entre el esquema y el estado de la base de datos es muyimportante. Cuando denimos una nueva base de datos, slo especicamos suesquema al SGBD. En ese momento, el estado de la base de datos es el estadovaco, sin datos. Cuando se cargan datos por primera vez, la base datos pasaal estado inicial. De ah en adelante, siempre que se realice una operacin deactualizacin de la base de datos, se tendr un nuevo estado. El SGBD seencarga, en parte, de garantizar que todos los estados de la base de datos seanestados vlidos que satisfagan la estructura y las restricciones especicadas enel esquema. Por lo tanto, es muy importante que el esquema que se especiqueal SGBD sea correcto y se debe tener gran cuidado al disearlo. El SGBDalmacena el esquema en su catlogo o diccionario de datos, de modo que sepueda consultar siempre que sea necesario.

En 1970, el modo en que se vean las bases de datos cambi por completocuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, elenfoque existente para la estructura de las bases de datos utilizaba punterosfsicos (direcciones de disco) para relacionar registros de distintos cheros. Si,por ejemplo, se quera relacionar un registro A con un registro B, se debaaadir al registro A un campo conteniendo la direccin en disco (un punterofsico) del registro B. Codd demostr que estas bases de datos limitaban engran medida los tipos de operaciones que los usuarios podan realizar sobrelos datos. Adems, estas bases de datos eran muy vulnerables a cambios en elentorno fsico. Si se aadan los controladores de un nuevo disco al sistema y losdatos se movan de una localizacin fsica a otra, se requera una conversin delos cheros de datos. Estos sistemas se basaban en el modelo de red y el modelojerrquico, los dos modelos lgicos que constituyeron la primera generacin delos SGBD.

El modelo relacional representa la segunda generacin de los SGBD. Enl, todos los datos estn estructurados a nivel lgico como tablas formadaspor las y columnas, aunque a nivel fsico pueden tener una estructura com-pletamente distinta. Un punto fuerte del modelo relacional es la sencillez desu estructura lgica. Pero detrs de esa simple estructura hay un fundamentoterico importante del que carecen los SGBD de la primera generacin, lo queconstituye otro punto a su favor.

15


Dada la popularidad del modelo relacional, muchos sistemas de la primerageneracin se han modicado para proporcionar una interfaz de usuario rela-cional, con independencia del modelo lgico que soportan (de red o jerrquico).

En los ltimos aos, se han propuesto algunas extensiones al modelo re-lacional para capturar mejor el signicado de los datos, para disponer de losconceptos de la orientacin a objetos y para disponer de capacidad deductiva.

El modelo relacional, como todo modelo de datos, tiene que ver con tres as-pectos de los datos, que son los que se presentan en los siguientes apartados deeste captulo: qu caractersticas tiene la estructura de datos, cmo mantenerla integridad de los datos y cmo realizar el manejo de los mismos.

2.2. Estructura de datos relacional

La estructura de datos del modelo relacional es la relacin. En este apartadose presenta esta estructura de datos, sus propiedades, los tipos de relaciones yqu es una clave de una relacin. Para facilitar la comprensin de las denicio-nes formales de todos estos conceptos, se dan antes unas deniciones informalesque permiten asimilar dichos conceptos con otros que resulten familiares.

2.2.1. Relaciones

Deniciones informales

El modelo relacional se basa en el concepto matemtico de relacin, quegrcamente se representa mediante una tabla. Codd, que era un experto ma-temtico, utiliz una terminologa perteneciente a las matemticas, en concretode la teora de conjuntos y de la lgica de predicados.

Una relacin es una tabla con columnas y las. Un SGBD slo necesitaque el usuario pueda percibir la base de datos como un conjunto de tablas.Esta percepcin slo se aplica a la estructura lgica de la base de datos, no seaplica a la estructura fsica de la base de datos, que se puede implementar condistintas estructuras de almacenamiento.

Un atributo es el nombre de una columna de una relacin. En el mode-lo relacional, las relaciones se utilizan para almacenar informacin sobre losobjetos que se representan en la base de datos. Una relacin se representagrcamente como una tabla bidimensional en la que las las corresponden aregistros individuales y las columnas corresponden a los campos o atributos deesos registros. Los atributos pueden aparecer en la relacin en cualquier orden.

Por ejemplo, la informacin de los clientes de una empresa determinada serepresenta mediante la relacin CLIENTES de la gura 2.1, que tiene columnaspara los atributos codcli (cdigo del cliente), nombre (nombre y apellidosdel cliente), direccin (calle y nmero donde se ubica el cliente), codpostal(cdigo postal correspondiente a la direccin del cliente) y codpue (cdigo dela poblacin del cliente). La informacin sobre las poblaciones se representa

16


mediante la relacin PUEBLOS de la misma gura, que tiene columnas para losatributos codpue (cdigo de la poblacin), nombre (nombre de la poblacin)y codpro (cdigo de la provincia en que se encuentra la poblacin).

CLIENTEScodcli nombre direccin codpostal codpue333 Sos Carretero, Jess Mosen Compte, 14 12964 53596336 Miguel Archils, Ramn Bernardo Mundina, 132-5 12652 07766342 Pinel Huerta, Vicente Francisco Sempere, 37-10 12112 07766345 Lpez Botella, Mauro Avenida del Puerto, 20-1 12439 12309348 Palau Martnez, Jorge Raval de Sant Josep, 97-2 12401 12309354 Murra Vinaiza, Jos Ciudadela, 90-18 12990 12309357 Huguet Peris, Juan ngel Calle Mestre Rodrigo, 7 12930 12309

PUEBLOScodpue nombre codpro07766 Burriana 1212309 Castelln 1217859 Enramona 1246332 Soneja 1253596 Vila-real 12

Figura 2.1: Relaciones que almacenan los datos de los clientes y sus poblaciones.

Un dominio es el conjunto de valores legales de uno o varios atributos. Losdominios constituyen una poderosa caracterstica del modelo relacional. Cadaatributo de una base de datos relacional se dene sobre un dominio, pudiendohaber varios atributos denidos sobre el mismo dominio. La gura 2.2 muestralos dominios de los atributos de la relacin CLIENTES.

Atributo Dominio Descripcin Denicincodcli codli_dom Posibles cdigos de cliente. Nmero hasta 5 dgitos.nombre nombre_dom Nombres de personas: apelli-

do1 apellido2, nombre.50 caracteres.

direccin direccin_dom Domicilios de Espaa: calle,nmero.

50 caracteres.

codpostal codpostal_dom Cdigos postales de Espaa. 5 caracteres.codpue codpue_dom Cdigos de las poblaciones de

Espaa.5 caracteres.

Figura 2.2: Dominios de los atributos de la relacin que almacena los datos de los clientes.

El concepto de dominio es importante porque permite que el usuario dena,en un lugar comn, el signicado y la fuente de los valores que los atributospueden tomar. Esto hace que haya ms informacin disponible para el sistemacuando ste va a ejecutar una operacin relacional, de modo que las operacionesque son semnticamente incorrectas, se pueden evitar. Por ejemplo, no tienesentido comparar el nombre de una calle con un nmero de telfono, aunquelos dos atributos sean cadenas de caracteres. Sin embargo, el importe mensualdel alquiler de un inmueble no estar denido sobre el mismo dominio que

17


el nmero de meses que dura el alquiler, pero s tiene sentido multiplicar losvalores de ambos dominios para averiguar el importe total al que asciende elalquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominiosya que su implementacin es extremadamente compleja.

Una tupla es una la de una relacin. Los elementos de una relacin sonlas tuplas o las de la tabla. En la relacin CLIENTES, cada tupla tiene cincovalores, uno para cada atributo. Las tuplas de una relacin no siguen ningnorden.

El grado de una relacin es el nmero de atributos que contiene. La relacinCLIENTES es de grado cinco porque tiene cinco atributos. Esto quiere decir quecada la de la tabla es una tupla con cinco valores. El grado de una relacinno cambia con frecuencia.

La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya queen las relaciones se van insertando y borrando tuplas a menudo, la cardinalidadde las mismas vara constantemente.

Una base de datos relacional es un conjunto de relaciones normalizadas.Una relacin est normalizada si en la interseccin de cada la con cada co-lumna hay un solo valor.

Deniciones formales

Una relacin R denida sobre un conjunto de dominios D1, D2, . . . , Dnconsta de:

Cabecera: conjunto jo de pares atributo:dominio

{(A1 : D1), (A2 : D2), . . . , (An : Dn)}

donde cada atributo Aj corresponde a un nico dominio Dj y todos losAj son distintos, es decir, no hay dos atributos que se llamen igual. Elgrado de la relacin R es n.

Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de paresatributo:valor :

{(A1 : vi1), (A2 : vi2), . . . , (An : vin)}

con i = 1, 2, . . . , m, donde m es la cardinalidad de la relacin R. En cadapar (Aj : vij) se tiene que vij Dj .

A continuacin se muestra la cabecera de la relacin CLIENTES de la gu-ra 2.1, y una de sus tuplas.

{ (codcli:codcli_dom), (nombre:nombre_dom),(direccin:direccin_dom), (codpostal:codpostal_dom),(codpue:codpue_dom) }

18


{ (codcli:333), (nombre:Sos Carretero, Jess),(direccin:Mosen Compte, 14), (codpostal:12964),(codpue:53596) }

Este conjunto de pares no est ordenado, por lo que la tupla anterior y lasiguiente son la misma:

{ (nombre:Sos Carretero, Jess), (codpostal:12964),(codcli:333), (direccin:Mosen Compte, 14),(codpue:53596) }

Las relaciones se suelen representar grcamente mediante tablas. Los nom-bres de las columnas corresponden a los nombres de los atributos, y las lasson cada una de las tuplas de la relacin. Los valores que aparecen en cadauna de las columnas pertenecen al conjunto de valores del dominio sobre elque est denido el atributo correspondiente.

2.2.2. Propiedades de las relaciones

Las relaciones tienen las siguientes caractersticas:

Cada relacin tiene un nombre, y ste es distinto del nombre de todaslas dems.

Los dominios sobre los que se denen los atributos son escalares, porlo que los valores de los atributos son atmicos. De este modo, en cadatupla, cada atributo toma un solo valor. Se dice que las relaciones estnnormalizadas.

No hay dos atributos que se llamen igual.

El orden de los atributos no importa: los atributos no estn ordenados.

Cada tupla es distinta de las dems: no hay tuplas duplicadas.

El orden de las tuplas no importa: las tuplas no estn ordenadas.

19


2.2.3. Tipos de relaciones

En un SGBD relacional hay dos tipos de relaciones:

Relaciones base. Son relaciones reales que tienen nombre, y forman partedirecta de la base de datos almacenada. Se dice que las relaciones baseson relaciones autnomas.

Vistas. Tambin denominadas relaciones virtuales, son relaciones connombre y derivadas (no autnomas). Que son derivadas signica quese obtienen a partir de otras relaciones; se representan mediante su de-nicin en trminos de esas otras relaciones. Las vistas no poseen datosalmacenados propios, los datos que contienen corresponden a datos al-macenados en relaciones base.

2.2.4. Claves

Ya que en una relacin no hay tuplas repetidas, stas se pueden distinguirunas de otras, es decir, se pueden identicar de modo nico. La forma deidenticarlas es mediante los valores de sus atributos. Se denomina superclave aun atributo o conjunto de atributos que identican de modo nico las tuplas deuna relacin. Se denomina clave candidata a una superclave en la que ningunode sus subconjuntos es una superclave de la relacin. El atributo o conjuntode atributos K de la relacin R es una clave candidata para R si, y slo si,satisface las siguientes propiedades:

Unicidad: nunca hay dos tuplas en la relacin R con el mismo valor de K.

Irreducibilidad (minimalidad): ningn subconjunto de K tiene la propie-dad de unicidad, es decir, no se pueden eliminar componentes de K sindestruir la unicidad.

Cuando una clave candidata est formada por ms de un atributo, se diceque es una clave compuesta. Una relacin puede tener varias claves candidatas.Por ejemplo, en la relacin PUEBLOS de la gura 2.1, el atributo nombre noes una clave candidata ya que hay pueblos en Espaa con el mismo nombreque se encuentran en distintas provincias. Sin embargo, se ha asignado uncdigo nico a cada poblacin, por lo que el atributo codpue s es una clavecandidata de la relacin PUEBLOS. Tambin es una clave candidata de estarelacin la pareja formada por los atributos nombre y codpro, ya que no haydos poblaciones en la misma provincia que tengan el mismo nombre.

Para identicar las claves candidatas de una relacin no hay que jarse enun estado u ocurrencia de la base de datos. El hecho de que en un momentodado no haya duplicados para un atributo o conjunto de atributos, no garanti-za que los duplicados no sean posibles. Sin embargo, la presencia de duplicados

20


en un estado de la base de datos s es til para demostrar que cierta combi-nacin de atributos no es una clave candidata. El nico modo de identicarlas claves candidatas es conociendo el signicado real de los atributos, ya queesto permite saber si es posible que aparezcan duplicados. Slo usando estainformacin semntica se puede saber con certeza si un conjunto de atributosforman una clave candidata. Por ejemplo, viendo la ocurrencia anterior de larelacin CLIENTES se podra pensar que el atributo nombre es una clave can-didata. Pero ya que este atributo es el nombre de un cliente y es posible quehaya dos clientes con el mismo nombre, el atributo no es una clave candidata.

Se denomina clave primaria de una relacin a aquella clave candidata quese escoge para identicar sus tuplas de modo nico. Ya que una relacin notiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, larelacin siempre tiene clave primaria. En el peor caso, la clave primaria estarformada por todos los atributos de la relacin, pero normalmente habr unpequeo subconjunto de los atributos que haga esta funcin.

Las claves candidatas que no son escogidas como clave primaria son de-nominadas claves alternativas. Por ejemplo, la clave primaria de la relacinPUEBLOS es el atributo codpue, siendo la pareja formada por nombre y codprouna clave alternativa. En la relacin CLIENTES slo hay una clave candidataque es el atributo codcli, por lo que esta clave candidata es la clave primaria.

Una clave ajena es un atributo o un conjunto de atributos de una relacincuyos valores coinciden con los valores de la clave primaria de alguna otrarelacin (puede ser la misma). Las claves ajenas representan relaciones entredatos. Por ejemplo, el atributo codpue de CLIENTES relaciona a cada clientecon su poblacin. Este atributo en CLIENTES es una clave ajena cuyos valoreshacen referencia al atributo codpue de PUEBLOS (su clave primaria). Se diceque un valor de clave ajena representa una referencia a la tupla que contieneel mismo valor en su clave primaria (tupla referenciada).

Si nos jamos en los datos de la gura 2.1, para conocer el nombre de lapoblacin del cliente con codcli = 333, debemos seguir la clave ajena codpueque aparece en la tupla de dicho cliente y que tiene el valor 53596. Seguirla referencia que implica la clave ajena conlleva visitar la relacin PUEBLOS ylocalizar la la que tiene el valor 53596 en su clave primaria. Ntese que, eneste ejemplo, la clave ajena tiene el mismo nombre que la clave primaria a laque hace referencia. Esto no es un requisito, las claves ajenas no precisan tenerel mismo nombre que la clave primaria a la que referencian; sin embargo, si seutilizan los mismos nombres (o nombres compuestos derivados de los mismos)es ms fcil reconocer las claves ajenas.

Al hablar de claves primarias y de claves ajenas es importante darse cuen-ta de que los valores de una clave primaria no se pueden repetir, mientrasque no sucede lo mismo con las claves ajenas que le hacen referencia. As, enlas tablas de la gura 2.1 no es posible encontrar dos tuplas con el mismovalor en PUEBLOS.codpue (cada poblacin debe aparecer en la relacin unasola vez), pero s es posible encontrar varias tuplas con el mismo valor en

21


CLIENTES.codpue, ya que es posible que haya varios clientes que se ubiquenen la misma poblacin.

2.3. Esquema de una base de datos relacional

Una base de datos relacional es un conjunto de relaciones. Para representarel esquema de una base de datos relacional se debe dar el nombre de susrelaciones, los atributos de stas, los dominios sobre los que se denen estosatributos, las claves primarias y las claves ajenas.

El esquema de la base de datos de la empresa con la que trabajaremos eneste libro es el siguiente:

CLIENTES(codcli, nombre, direccin, codpostal, codpue)VENDEDORES(codven, nombre, direccin, codpostal, codpue, codjefe)

PUEBLOS(codpue, nombre, codpro)PROVINCIAS(codpro, nombre)ARTCULOS(codart, descrip, precio, stock, stock_min, dto)FACTURAS(codfac, fecha, codcli, codven, iva, dto)

LNEAS_FAC(codfac, lnea, cant, codart, precio, dto)

En el esquema anterior, los nombres de las relaciones aparecen seguidos delos nombres de los atributos encerrados entre parntesis. Las claves primariasson los atributos subrayados. Las claves ajenas se representan mediante lossiguientes diagramas referenciales:

CLIENTEScodpue PUEBLOS : Poblacin del cliente.

VENDEDOREScodpue PUEBLOS : Poblacin del vendedor.

VENDEDOREScodjefe VENDEDORES : Jefe del vendedor.

PUEBLOScodpro PROVINCIAS : Provincia en la que se encuentra la po-

blacin.

FACTURAScodcli CLIENTES : Cliente al que pertenece la factura.

FACTURAScodven VENDEDORES : Vendedor que ha realizado la venta.

LNEAS_FACcodfac FACTURAS : Factura en la que se encuentra la lnea.

LNEAS_FACcodart ARTCULOS : Artculo que se compra en la lnea de

factura.

La tabla PROVINCIAS almacena informacin sobre las provincias de Es-paa. De cada provincia se almacena su nombre (nombre) y un cdigo quela identica (codpro). La tabla PUEBLOS contiene los nombres (nombre) delos pueblos de Espaa. Cada pueblo se identica por un cdigo que es nico(codpue) y tiene una referencia a la provincia a la que pertenece (codpro).La tabla CLIENTES contiene los datos de los clientes: cdigo que identica a

22


cada uno (codcli), nombre y apellidos (nombre), calle y nmero (direccin),cdigo postal (codpostal) y una referencia a su poblacin (codpue). La ta-bla VENDEDORES contiene los datos de los vendedores de la empresa: cdigoque identica a cada uno (codven), nombre y apellidos (nombre), calle y n-mero (direccin), cdigo postal (codpostal), una referencia a su poblacin(codpue) y una referencia al vendedor del que depende (codjefe), si es elcaso. En la tabla ARTCULOS se tiene el cdigo que identica a cada artcu-lo (codart), su descripcin (descrip), el precio de venta actual (precio), elnmero de unidades del artculo que hay en el almacn (stock), la cantidadmnima que se desea mantener almacenada (stock_min) y, si el artculo esten oferta, el descuento (dto) que se debe aplicar cuando se venda. La tablaFACTURAS contiene las cabeceras de las facturas correspondientes a las com-pras realizadas por los clientes. Cada factura tiene un cdigo nico (codfac),la fecha en que se ha realizado (fecha), as como el IVA (iva) y el descuen-to que se le ha aplicado (dto). Cada factura hace referencia al cliente al quepertenece (codcli) y al vendedor que la ha realizado (codven). Las lneas decada factura se encuentran en la tabla LNEAS_FAC, identicndose cada unapor el nmero de lnea que ocupa dentro de la factura (codfac, lnea). Encada una de ellas se especica la cantidad de unidades (cant) del artculo quese compra (codart), el precio de venta por unidad (precio) y el descuento quese aplica sobre dicho precio (dto), si es que el artculo estaba en oferta cuandose vendi.

A continuacin se muestra un estado de la base de datos cuyo esquema seacaba de denir.

CLIENTEScodcli nombre direccin codpostal codpue333 Sos Carretero, Jess Mosen Compte, 14 12964 53596336 Miguel Archils, Ramn Bernardo Mundina, 132-5 12652 07766342 Pinel Huerta, Vicente Francisco Sempere, 37-10 12112 07766345 Lpez Botella, Mauro Avenida del Puerto, 20-1 12010 12309348 Palau Martnez, Jorge Raval de Sant Josep, 97-2 12003 12309354 Murra Vinaiza, Jos Ciudadela, 90-18 12003 12309357 Huguet Peris, Juan ngel Calle Mestre Rodrigo, 7 12100 12309

VENDEDOREScodven nombre direccin codpostal codpue codjefe

5 Guilln Vilar, Natalia Sant Josep, 110 12597 53596 105105 Poy Omella, Paloma Sanchis Tarazona, 103-1 12257 46332155 Rubert Cano, Diego Benicarl Residencial, 154 12425 17859 5455 Agost Tirado, Jorge Pasaje Peagolosa, 21-19 12914 53596 5

PUEBLOScodpue nombre codpro07766 Burriana 1212309 Castelln 1217859 Enramona 1246332 Soneja 1253596 Vila-real 12

23


PROVINCIAScodpro nombre

03 Alicante12 Castelln46 Valencia

ARTCULOScodart descrip precio stock stock_min dtoIM3P32V Interruptor magnetotrmico 4p, 2 27.01 1 1im4P10L Interruptor magnetotrmico 4p, 4 32.60 1 1 15L14340 Bases de fusibles cuchillas T0 0.51 3 3L17055 Bases de fusible cuchillas T3 7.99 3 3L76424 Placa 2 E. legrand serie mosaic 2.90 5 2L85459 Tecla legrand marfil 2.80 0 4L85546 Tecla difusores legrand bronce 1.05 13 5 5L92119 Portalmparas 14 curvo 5.98 2 1ME200 Marco Bjc Ibiza 2 elementos 13.52 1 1N5072 Pulsador luz piloto Niessen trazo 1.33 11 2N8017BA Reloj Orbis con reserva de cuerda 3.40 7 4P605 Caja 1 elem. plastimetal 1.65 16 9P695 Interruptor rotura brusca 100 A M 13.22 1 1P924 Interruptor marrn dec. con visor 2.39 8 3REF1X20 Regleta fluorescente 1x36 bajo F 8.71 1 1S3165136 Bloque emergencia Satf 150 L 4.81 6 3T4501 Tubo empotrar 100 2.98 0 5TE7200 Doble conmutador Bjc Ibiza blanco 13.22 1 1TFM16 Curva tubo hierro 11 0.33 23 13TH11 Curva tubo hierro 29 1.42 20 3THC21 Placa mural Felmax 1.56 1 1ZNCL Base T,t lateral Ticino S, Tekne 41.71 1 1 10

FACTURAScodfac fecha codcli codven iva dto6643 16/07/2010 333 105 18 106645 16/07/2010 336 105 0 206654 31/07/2010 357 155 8 06659 08/08/2010 342 5 0 06680 10/09/2010 348 455 8 06723 06/11/2010 342 5 18 06742 17/12/2010 333 105 8 20

LNEAS_FACcodfac linea cant codart precio dto6643 1 6 L14340 0.51 206643 2 1 N5072 1.33 06643 3 2 P695 13.22 06645 1 10 ZNCL 41.71 06645 2 6 N8017BA 3.40 06645 3 3 TE7200 13.22 06645 4 4 L92119 5.98 06654 1 6 REF1X20 8.71 506659 1 8 THC21 1.56 06659 2 12 L17055 7.99 256659 3 9 L76424 2.90 06680 1 12 T4501 2.98 06680 2 11 im4P10L 32.60 06723 1 5 L85459 2.80 56742 1 9 ME200 13.52 06742 2 8 S3165136 4.81 5

24


2.4. Reglas de integridad

Una vez denida la estructura de datos del modelo relacional, pasamos aestudiar las reglas de integridad que los datos almacenados en dicha estructuradeben cumplir para garantizar que son correctos.

Al denir cada atributo sobre un dominio se impone una restriccin sobre elconjunto de valores permitidos para cada atributo. A este tipo de restriccionesse les denomina restricciones de dominios. Hay adems dos reglas de integridadmuy importantes que son restricciones que se deben cumplir en todas las basesde datos relacionales y en todos sus estados (las reglas se deben cumplir todoel tiempo). Estas reglas son la regla de integridad de entidades y la regla deintegridad referencial. Antes de denirlas, es preciso conocer el concepto denulo.

2.4.1. Nulos

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Unnulo no representa el valor cero ni la cadena vaca ya que stos son valoresque tienen signicado. El nulo implica ausencia de informacin, bien porque alinsertar la tupla se desconoca el valor del atributo, o bien porque para dichatupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo quecausa problemas de implementacin. De hecho, no todos los SGBD relacionalessoportan los nulos.

2.4.2. Regla de integridad de entidades

La primera regla de integridad se aplica a las claves primarias de las re-laciones base: ninguno de los atributos que componen la clave primaria puedeser nulo.

Por denicin, una clave primaria es una clave irreducible que se utilizapara identicar de modo nico las tuplas. Que es irreducible signica queningn subconjunto de la clave primaria sirve para identicar las tuplas demodo nico. Si se permitiera que parte de la clave primaria fuera nula, seestara diciendo que no todos sus atributos son necesarios para distinguir lastuplas, con lo que se estara contradiciendo la irreducibilidad.

Ntese que esta regla slo se aplica a las relaciones base y a las clavesprimarias, no a las claves alternativas.

25


2.4.3. Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas: si en unarelacin hay alguna clave ajena, sus valores deben coincidir con valores de laclave primaria a la que hace referencia, o bien, deben ser completamente nulos.

En la base de datos presentada en el apartado anterior hay ocho clavesajenas que mantienen relacionada la informacin almacenada en las tablas.As, a travs de la clave ajena FACTURAS.codcli se puede conocer los datospersonales del cliente al que pertenece una determinada factura buscando en larelacin CLIENTES la tupla en cuya clave primaria aparece el valor de codclial que se hace referencia en la factura. El nombre de la poblacin del cliente sepodr conocer siguiendo la clave ajena CLIENTES.codpue y, una vez localizadala poblacin con dicho codpue en PUEBLOS, se podr acceder al nombre de suprovincia siguiendo la clave ajena PUEBLOS.codpro.

Pues bien, la regla de integridad referencial exige que los valores que apa-recen en la clave ajena FACTURAS.codcli aparezcan como clave primaria enCLIENTES. De ese modo, todas las facturas correspondern a clientes cuyos da-tos se encuentran en la base de datos. Del mismo modo, la regla exige que losvalores de CLIENTES.codpue aparezcan en la clave primaria de PUEBLOS y quelos valores de PUEBLOS.codpro aparezcan en la clave primaria de PROVINCIAS.

La regla de integridad referencial se enmarca en trminos de estados dela base de datos: indica lo que es un estado ilegal, pero no dice cmo puedeevitarse. Por lo tanto, una vez establecida la regla, hay que plantearse qu hacersi estando en un estado legal, llega una peticin para realizar una operacinque conduce a un estado ilegal. Existen dos opciones: rechazar o aceptar laoperacin y realizar operaciones adicionales compensatorias que conduzcan aun estado legal.

Para hacer respetar la integridad referencial se debe contestar, para cadaclave ajena, a las tres preguntas que se plantean a continuacin y que deter-minarn su comportamiento:

Regla de los nulos: Tiene sentido que la clave ajena acepte nulos?

Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciadapor la clave ajena?

Restringir: no se permite borrar la tupla referenciada. Propagar: se borra la tupla referenciada y se propaga el borrado alas tuplas que la referencian mediante la clave ajena.

Anular: se borra la tupla referenciada y las tuplas que la referen-ciaban ponen a nulo la clave ajena (slo si acepta nulos).

Valor por defecto: se borra la tupla referenciada y las tuplas que lareferenciaban ponen en la clave ajena el valor por defecto establecidopara la misma.

26


Regla de modicacin: Qu ocurre si se intenta modicar el valor dela clave primaria de la tupla referenciada por la clave ajena?

Restringir: no se permite modicar el valor de la clave primaria dela tupla referenciada.

Propagar: se modica el valor de la clave primaria de la tupla refe-renciada y se propaga la modicacin a las tuplas que la referencian,mediante la clave ajena.

Anular: se modica la tupla referenciada y las tuplas que la refe-renciaban ponen a nulo la clave ajena (slo si acepta nulos).

Valor por defecto: se modica la tupla referenciada y las tuplasque la referenciaban ponen en la clave ajena el valor por defectoestablecido para la misma.

As, en el caso del esquema de la base de datos presentada en el apartadoanterior, deberemos determinar las reglas de comportamiento para cada claveajena. Por ejemplo, para la clave ajena FACTURAS.codcli se ha escogido elsiguiente comportamiento:

Regla de los nulos: la clave ajena acepta nulos, por lo que es posibleencontrar facturas cuyo cliente se ignore (esto se ha decidido as porquelo impone un requisito del usuario).

Regla de borrado: anular. Cuando se elimine un cliente de la base de datosy se proceda a borrarlo de la relacin CLIENTES, se debern anular todaslas referencias que hubiera desde FACTURAS.codcli. De este modo, todaslas facturas que tena ese cliente pasarn a tener un nulo en el cdigo delcliente.

Regla de modicacin: propagar. En caso de que se modique el cdigo aun cliente (quiz porque el sistema de codicacin se cambie por parte dela empresa), todas las facturas de dicho cliente actualizarn el valor deFACTURAS.codcli para continuar haciendo referencia a la misma tupla.

Del mismo modo, se deber escoger reglas para el resto de las claves aje-nas de la base de datos. Una vez establecidas todas las reglas, el sistema secomportar de manera coherente obedeciendo a todas las reglas impuestas.Por ejemplo, si la regla de borrado para LNEAS_FAC.codfac es propagar yla regla de borrado para FACTURAS.codven es restringir, cuando se borre unatupla en FACTURAS se propagar el borrado a LNEAS_FAC, y se borrarn todaslas lneas de la factura referenciada. Sin embargo, cuando se intente borrarla tupla de un vendedor que aparezca en alguna factura, la regla impuestasobre FACTURAS.codven rechazar el borrado del vendedor y no se procederal borrado ni de sus facturas, ni de las lneas de factura de stas. Lo que sser posible es el borrado de un vendedor cuyo cdigo no aparezca en ningunafactura.

27


2.4.4. Reglas de negocio

Adems de las dos reglas de integridad anteriores, es posible que sea necesa-rio imponer ciertas restricciones especcas sobre los datos que forman parte dela estrategia de funcionamiento de la empresa. A estas reglas se las denominareglas de negocio.

Por ejemplo, si en cada ocina de una determinada empresa slo puedehaber hasta veinte empleados, el SGBD debe dar la posibilidad al usuariode denir una regla al respecto y debe hacerla respetar. En este caso, nodebera permitir dar de alta a un empleado en una ocina que ya tiene losveinte permitidos. No todos los SGBD relacionales permiten denir este tipode restricciones y hacerlas respetar.

28


Captulo 3

Lenguajes relacionales


La tercera parte de un modelo de datos es la de la manipulacin de losdatos. En este captulo se presentan el lgebra relacional y el clculo relacional,denidos por E. F. Codd como la base de los lenguajes relacionales.

Al nalizar este captulo, el estudiante debe ser capaz de:

Emplear los operadores del lgebra relacional para responder a cualquierconsulta de datos.

Emplear los operadores del clculo relacional orientado a tuplas pararesponder a consultas de datos que no requieran operaciones de resumen.

Describir la diferencia entre el clculo relacional orientado a tuplas y elclculo relacional orientado a dominios.

Enumerar otros lenguajes relacionales distintos al lgebra y el clculorelacional.

3.1. Manejo de datos

Son varios los lenguajes utilizados por los SGBD relacionales para manejarlas relaciones. Algunos de ellos son procedurales, lo que quiere decir que el usua-rio indica al sistema exactamente cmo debe manipular los datos. Otros sonno procedurales, que signica que el usuario indica qu datos necesita, en lugarde establecer cmo deben obtenerse. Se puede decir que el lgebra relacionales un lenguaje procedural de alto nivel, mientras que el clculo relacional es unlenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes: paracada expresin del lgebra, se puede encontrar una expresin equivalente en elclculo, y viceversa.

El lgebra relacional (o el clculo relacional) se utiliza para medir la po-tencia de los lenguajes relacionales. Si un lenguaje permite obtener cualquier

29


relacin que se pueda derivar mediante el lgebra relacional, se dice que esrelacionalmente completo. La mayora de los lenguajes relacionales son rela-cionalmente completos, pero tienen ms potencia que el lgebra o el clculoporque se les han aadido operadores especiales.

Tanto el lgebra como el clculo son lenguajes formales no muy amigables;sin embargo, es conveniente estudiarlos porque sirven para ilustrar las opera-ciones bsicas que todo lenguaje de manejo de datos debe ofrecer. Adems,han sido la base para otros lenguajes relacionales de manejo de datos de msalto nivel.

3.2. lgebra relacional

El lgebra relacional es un lenguaje formal con una serie de operadores quetrabajan sobre una o varias relaciones para obtener otra relacin resultado, sinque cambien las relaciones originales. Tanto los operandos como los resultadosson relaciones, por lo que la salida de una operacin puede ser la entrada de otraoperacin. Esto permite anidar expresiones del lgebra, del mismo modo quese pueden anidar las expresiones aritmticas. A esta propiedad se le denominaclausura: las relaciones son cerradas bajo el lgebra, del mismo modo que losnmeros son cerrados bajo las operaciones aritmticas.

En este apartado se describen, en primer lugar, los ocho operadores ori-ginalmente propuestos por Codd, y despus se estudian algunos operadoresadicionales que aaden potencia al lenguaje.

De los ocho operadores, slo hay cinco que son fundamentales: restriccin,proyeccin, producto cartesiano, unin y diferencia. Los operadores fundamen-tales permiten realizar la mayora de las operaciones de obtencin de datos.Los operadores no fundamentales son la concatenacin (join), la intersecciny la divisin, que se pueden expresar a partir de los cinco operadores funda-mentales.

La restriccin y la proyeccin son operaciones unarias porque operan sobreuna sola relacin. El resto de las operaciones son binarias porque trabajansobre pares de relaciones. En las deniciones que se presentan a continuacin, sesupone que R y S son dos relaciones cuyos atributos son A = (a1,a2,...,aN)y B = (b1,b2,...,bM) respectivamente.

A continuacin, se presentan los operadores del lgebra relacional, mos-trando su uso mediante breves ejemplos. Todos estos ejemplos estn basadosen el esquema de la base de datos relacional presentada en el captulo anterior(apartado 2.3).

30


Restriccin: R WHERE condicinLa restriccin, tambin denominada seleccin, opera sobre una solarelacin R y da como resultado otra relacin cuyas tuplas son lastuplas de R que satisfacen la condicin especicada. Esta condicines una comparacin en la que aparece al menos un atributo de R, ouna combinacin booleana de varias de estas comparaciones.

Ejemplo 3.1 Obtener todos los artculos que tienen un precio superior a 10 e.

Expresin del lgebra relacional que obtiene los datos especicados:

ARTICULOS WHERE precio>10

Resultado:

codart descrip precio stock stock_min dtoIM3P32V Interruptor magnetotrmico 4p, 2 27.01 1 1im4P10L Interruptor magnetotrmico 4p, 4 32.60 1 1 15ME200 Marco Bjc Ibiza 2 elementos 13.52 1 1P695 Interruptor rotura brusca 100 A M 13.22 1 1TE7200 Doble conmutador Bjc Ibiza blanco 13.22 1 1ZNCL Base T,t lateral Ticino S, Tekne 41.71 1 1 10

Ejemplo 3.2 Obtener los artculos cuyo stock es de menos de 5 unidades yadems se ha quedado al mnimo o por debajo.


ARTCULOS WHERE stock


VENDEDORES[codven,nombre,codpostal]

Resultado:

codven nombre codpostal5 Guilln Vilar, Natalia 12597

105 Poy Omella, Paloma 12257155 Rubert Cano, Diego 12425455 Agost Tirado, Jorge 12914

Ejemplo 3.4 Obtener los cdigos de las poblaciones donde hay clientes.


CLIENTES[codpue]

Resultado:

codpue535960776612309

Producto cartesiano: R TIMES SEl producto cartesiano obtiene una relacin cuyas tuplas estn for-madas por la concatenacin de todas las tuplas de R con todas lastuplas de S.

La restriccin y la proyeccin son operaciones que permiten extraer in-formacin de una sola relacin. Habr casos en que sea necesario combinar lainformacin de varias relaciones. El producto cartesiano multiplica dos relacio-nes, deniendo una nueva relacin que tiene todos los pares posibles de tuplasde las dos relaciones. Si la relacin R tiene p tuplas y n atributos y la relacinS tiene q tuplas y m atributos, la relacin resultado tendr p q tuplas y n+matributos. Ya que es posible que haya atributos con el mismo nombre en lasdos relaciones, el nombre de la relacin se antepondr al del atributo en estecaso para que los nombres de los atributos sigan siendo nicos en la relacinresultado.

Una vez realizado el producto cartesiano de dos relaciones, se puede realizaruna restriccin que elimine aquellas tuplas cuya informacin no est relaciona-da, como se muestra en el siguiente ejemplo.

Ejemplo 3.5 Obtener los nombres de las poblaciones en las que hay clientes.


(CLIENTES[codpue] TIMES PUEBLOS)WHERE CLIENTES.codpue = PUEBLOS.codpue

32


Resultado:

CLIENTES.codpue PUEBLOS.codpue nombre codpro53596 53596 Vila-real 1207766 07766 Burriana 1212309 12309 Castelln 12

La combinacin del producto cartesiano y la restriccin del modo en quese acaba de realizar, se puede reducir a la operacin de concatenacin (JOIN)que se presenta ms adelante.

Unin: R UNION SLa unin de dos relaciones R y S, con P y Q tuplas respectivamente,es otra relacin que tiene como mucho P +Q tuplas siendo stas lastuplas que se encuentran en R o en S o en ambas relaciones a la vez.Para poder realizar esta operacin, R y S deben ser compatibles parala unin.

Se dice que dos relaciones son compatibles para la unin si ambas tienenla misma cabecera, es decir, si tienen el mismo nmero de atributos y stosse encuentran denidos sobre los mismos dominios en ambas tablas respecti-vamente. En muchas ocasiones ser necesario realizar proyecciones para hacerque dos relaciones sean compatibles para la unin.

Ejemplo 3.6 Obtener un listado de los cdigos de las poblaciones donde hayclient

Bases de Datos

Documents

Transcript of Bases de Datos