1

DISEO DE BASES DE DATOS RELACIONALES.

Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo ms utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones (relaciones) entre los datos (que estn guardados en tablas), y a travs de dichas conexiones relacionar los datos de ambas tablas, de ah proviene su nombre: "Modelo Relacional". Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos.

Al disear intuitivamente una base de datos relacional se obtiene un esquema; diferentes observadores generarn, sin duda, esquemas alternativos; el problema que se presenta es evaluar la calidad o bondad de dicho esquema. La calidad de un esquema estar determinada por el comportamiento o reaccin a determinadas operaciones de manipulacin, de modo que un buen esquema presentar buen comportamiento mientras que otros ofrecern ciertos inconvenientes o anomalas de manipulacin (actualizacin, insercin y borrado) al escribir transacciones contra dicho esquema.

4.1 CARACTERSTICAS DEL DISEO RELACIONAL. El objetivo de las tcnicas de diseo de bases de datos relacionales es obtener esquemas exentos de anomalas de manipulacin. Ejemplo: Sean los esquemas relacionales 1 y 2 :

En primer lugar, en el esquema 2 algunos datos son redundantes: los datos de piezas (Color y Peso) aparecen tantas veces como dicha pieza es suministrada. Esta redundancia conlleva unos riesgos de incoherencia. Al cambiar el Peso de una pieza de 200 a 220 hay que actualizar en todas las tuplas en las que aparece. Se producen por tanto anomalas de actualizacin (debe actualizarse slo en una tupla y evitar que haya ms de una tupla con diferente peso de la misma pieza). No se pueden guardar datos de piezas (P#, Peso y Color) hasta que no sean suministradas (S# es parte de la clave primaria y por tanto no puede tener valor null); presenta anomalas de insercin. Por ltimo, surgen las anomalas de eliminacin o borrado. Cuando se elimina una tupla de Suministra_Pieza y la pieza slo aparece en dicha tupla (ej. P#=P2) se pierde la informacin de la pieza. El esquema 2 presenta estos problemas inconvenientes debido a que no sigue un principio intuitivo bsico: conceptos o hechos independientes deben recogerse en (relaciones) distintas o especficas. El esquema relacional 1 no presenta las anomalas anteriores. Puede afirmarse que este esquema es mejor que el anterior. La teora de dependencias se ha desarrollado para medir formalmente la calidad de un diseo y proponer medidas que resuelvan las anomalas de manipulacin (formas normales). Incluye el concepto de dependencia funcional y sus propiedades, que es la principal herramienta para medir la idoneidad de un esquema relacional.

4.2 DOMINIOS ATMICOS Y LA PRIMERA FORMA NORMAL.

Cuando pasamos al modelo relacional debemos aplicar ciertas reglas las de estandarizacin, de normalizacin del todo las tablas, a este conjunto de reglas se le conoce con el nombre de normalizacin de base de datos, que consiste en aplicar una serie de relacin las relaciones obtenidas tras el paso del modelo entidad relacin al modelo relacional. Las base de datos relacionales se normalicen para evitar redundancia de los datos, evitar problemas de actualizacin de los datos en las tablas, para proteger la integridad de los datos. Una tabla est en Primera Forma Normal slo si 1. Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, mnimos. 2. La tabla contiene una clave primaria 3. La tabla no contiene atributos nulos 4. Si no posee ciclos repetitivos Una columna no puede tener mltiples valores. Los datos son atmicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X).... La primera forma normal (1NF o forma mnima) es una forma normal usada en normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1NF es una que satisface cierto conjunto mnimo de criterios. Estos criterios se refieren bsicamente a asegurarse que la tabla es una representacin fiel de una relacin y est libre de "grupos repetitivos". Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes tericos. Como una consecuencia, no hay un acuerdo universal en cuanto a qu caractersticas descalificaran a una tabla de estar en 1NF. Muy notablemente, la 1NF, tal y como es definida por algunos autores excluye "atributos relacin-valor", es decir, tablas dentro de tablas. Por otro lado, segn lo definido por otros autores, la 1NF s los permite. LAS TABLAS 1NF COMO REPRESENTACIONES DE RELACIONES Segn la definicin de Date de la 1NF, una tabla est en 1NF si y solo si es "isomorfa a alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones: 1. No hay orden de arriba-a-abajo en las filas. 2. No hay orden de izquierda-a-derecha en las columnas. 3. No hay filas duplicadas. 4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada ms). 5. Todas las columnas son regulares, es decir, las filas no tienen componentes como IDs de fila, IDs de objeto, o timestamps13 ocultos. La violacin de cualquiera de estas condiciones significara que la tabla no es estrictamente relacional, y por lo tanto no est en 1NF. Algunos ejemplos de tablas (o de vistas14) que no satisface esta definicin de 1NF son:

Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas
duplicadas, en violacin de la condicin 3. Una vista cuya definicin exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrnseco y significativo de la vista. Esto viola la condicin 1. Las tuplas en relaciones verdaderas no estn ordenadas una con respecto de la otra. Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estara en violacin de la condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe ser observado que este aspecto de la condicin 4 es controvertido. Muchos autores consideran que una tabla est en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan stos para atributos (campos) que no sean clave, segn el modelo original de Codd sobre el modelo relacional, el cual hizo disposicin explcita para los nulos. Grupos repetidos La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la caracterstica que define la 1NF", concierne a grupos repetidos. El siguiente ejemplo ilustra cmo un diseo de base de datos puede incorporar la repeticin de grupos, en violacin de la 1NF. Ejemplo 1: Dominios y valores Suponga que un diseador principiante desea guardar los nombres y los nmeros telefnicos de los alumnos. Procede a definir una tabla de ALUMNO como la que sigue:

En este punto, el diseador se da cuenta de un requisito: debe guardar mltiples nmeros telefnicos para algunos alumnos. Razona que la manera ms simple de hacer esto es permitir que el campo "Telfono" contenga ms de un valor en cualquier registro dado:

Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio de nmero telefnico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representacin de arriba no est en 1NF. La 1NF (y, para esa materia) prohbe a un campo contener ms de un valor de su dominio de columna.

Ejemplo 2: Grupos repetidos a travs de columnas El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico:

Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definicin de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseo no est en armona con el espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del nmero de telfono en tres encabezados es artificial y causa problemas lgicos. Estos problemas incluyen: Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como "Qu alumnos tienen el telfono X?" y "Qu pares de alumnos comparten un nmero de telfono?". La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono por medio del RDBMS. Al alumno 9101 se le puede dar equivocadamente un valor para el Telfono 2 que es exactamente igual que el valor de su Telfono 1. La restriccin de los nmeros de telfono por alumno a tres. Si viene un alumno con cuatro nmeros de telfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos est imponiendo restricciones al proceso de la institucin, en vez de (como idealmente debe ser el caso) al revs. Ejemplo 3: Repeticin de grupos dentro de columnas El diseador puede, alternativamente, conservar una sola columna de nmero de telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar mltiples nmeros telefnicos:

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu de la 1NF. El encabezado "Telfono" llega a ser semnticamente difuso, ya que ahora puede representar, o un nmero de telfono, o una lista de nmeros de telfono, o de hecho cualquier cosa. Una consulta como "Qu pares de clientes comparten un nmero telefnico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de nmeros telefnicos as como nmeros telefnicos individuales. Con este diseo en la RDBMS, son tambin imposibles de definir significativas restricciones en nmeros telefnicos.

4.3 DEPENDENCIAS FUNCIONALES.

En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias multivaluadas y las restricciones de integridad referencial. Como

vimos anteriormente, las relaciones pueden usarse como modelos del mundo real, estos hechos del mundo real implican que no todo conjunto de tuplas conforman una instancia vlida del esquema de relacin, an cuando los valores de las tuplas hayan sido tomados de los dominios correctos. Por ejemplo, si tenemos el esquema: Alumnos= {Cdigo, Nombre, Edad, Curso} La siguiente instancia no es vlida:

Podemos distinguir dos tipos de restricciones sobre las relaciones: Restricciones que dependen de la semntica del dominio. Estas restricciones surgen de comprender el significado de las componentes de las tuplas. En el ejemplo anterior, David Bustamante no puede tener 314 aos y Humberto Lpez no puede estar en Tercero de Bachillerato cuando slo tiene 12 aos de edad. Conocer estas restricciones no ayudan a lograr un buen diseo de la base de datos, pero es necesario considerarlas para que el DBMS chequee los errores que posiblemente ocurrirn en el momento de cargar los datos. Restricciones que dependen de la igualdad o desigualdad de valores. Estas restricciones no dependen de qu valor tiene una tupla en una componente dada, sino que se basan en que dos tuplas coinciden en ciertas componentes. En el ejemplo anterior, no puede suceder que Pedro y Mario Osorio tengan el mismo valor en el campo CDIGO, ms all de cul sea ese valor. Estas restricciones se conocen con el nombre de dependencias. Existen distintos algunos tipos de dependencias: funcionales, multivaluadas, de inclusin y de producto (join). Cada tipo de dependencia es un caso particular de la que le sigue. Si deseamos disponer de mtodos algortmicos eficientes para el diseo de una base de datos relacional debemos primero estudiar y resolver problemas relacionados con la manipulacin de dependencias entre los datos. Por alcance de ste curso analizaremos solamente las dependencias funcionales. Entonces qu es la Dependencia funcional? Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera: FechaDeNacimiento - Edad Aqu a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. Las dependencias funcionales representan restricciones de la realidad. Por consiguiente, la nica manera de determinar las dependencias funcionales que se cumplen en una tabla R es analizando cuidadosamente las restricciones de la realidad que estamos representando. Las dependencias funcionales son afirmaciones del mundo real que nos dicen qu instancias son vlidas para un esquema R.

4.4 SEGUNDA FORMA NORMAL.

Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. La segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de datos. La 2NF fue definida originalmente por E.F. Codd en 1971. Una tabla que est en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Especficamente: una tabla 1NF est en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la clave candidato, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella. En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus atributos no principales (que no son clave) son funcionalmente dependientes en una parte (subconjunto apropiado) de una clave candidata. Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidata consistiendo en ms de un atributo), la tabla est automticamente en 2NF. Ejemplo Considere una tabla describiendo los clubes a los que asisten los alumnos:

La nica clave candidata de la tabla es {ALUMNO, CLUB}. El atributo restante, CURSO, es dependiente en solo parte de la clave candidata, llamada ALUMNO. Por lo tanto la tabla no est en 2NF. Observe la redundancia de la manera en que son CURSO: nos dicen tres veces que David Bustamante est en Dcimo y dos veces que Humberto Lpez est en Tercero de Bachillerato. Esta redundancia hace a la tabla vulnerable a anomalas de actualizacin: por ejemplo, es posible actualizar el CURSO de David Bustamante en sus registros "Ftbol" y "Ajedrez" y no actualizar su registro "Msica". Los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el lugar CURSO actual de David Bustamante?". Una alternativa 2NF a este diseo representara la misma informacin en dos tablas:

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF. Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un ejemplo de una tabla 2NF que sufre de anomalas de actualizacin es:

Aunque el COLEGIO y la DIRECCIN DEL COLEGIO del campen estn determinadas por una clave completa {DEPORTE, AO} y no son partes de ella, particularmente las combinaciones COLEGIO/DIRECCIN DEL COLEGIO del campen son mostradas redundantemente en mltiples registros. Este problema es tratado por la tercera forma normal (3NF).

4.5 TERCERA FORMA NORMAL.

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria. La tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos. La definicin de Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se mantienen: La tabla est en la segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente en una clave candidata Un atributo no-primario es un atributo que no pertenece a ninguna clave candidato. Una dependencia transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, XZ por virtud de X Y y Y Z.

10

Una formulacin alternativa de la definicin de Codd. Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionales X A, por lo menos una de las condiciones siguientes se mantiene: X contiene A, X es una superclave, A es un atributo primario (es decir, A est contenido dentro de una clave candidato) La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario"). Ejemplo: Una tabla 2NF que falla en satisfacer los requisitos de la 3NF es:

La violacin de la 3NF ocurre porque el atributo no primario DIRECCIN COLEGIO es dependiente transitivamente de {DEPORTE, AO} va el atributo no primario COLEGIO. El hecho de que la DIRECCIN DEL COLEGIO del campen es funcionalmente dependiente en el COLEGIO hace la tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida al mismo COLEGIO ser mostrado con diferentes DIRECCIN DE COLEGIO en diversos registros. Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

11

4.6 FORMA NORMAL BOYCE-CODD.

Edgar Frank Codd a finales defini las bases del modelo relacional a finales de los 60. Trabajaba para IBM empresa que tard un poco en implementar sus bases. Pocos aos despus el modelo se empez a implementar cada vez ms, hasta ser el modelo de bases de datos ms popular. En las bases de Codd se definan los objetivos de este modelo: Independencia fsica. La forma de almacenar los datos, no debe influir en su manipulacin lgica Independencia lgica. Las aplicaciones que utilizan la base de datos no deben ser modificadas por que se modifiquen elementos de la base de datos. Flexibilidad. La base de datos ofrece fcilmente distintas vistas en funcin de los usuarios y aplicaciones. Uniformidad. Las estructuras lgicas siempre tienen una nica forma conceptual (las tablas) Sencillez. La Forma Normal Boyce-Codd (Denominada por sus siglas en ingles como BCNF or FNBC) es una forma normal utilizada en la normalizacin de bases de datos. Es una adaptacin vagamente ms segura de lo establecido en la Tercera Forma Normal (3FN). Es una etapa en que se deben agrupar los datos por afinidad, formando tablas las cuales se relacionan entre si mediante campos comunes; una tabla se considera en esta forma si y slo s cada determinante o atributo es una llave candidata. La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En base de datos un atributo determinante es un atributo del que depende funcionalmente de manera completa algn otro atributo. Todo determinante es una clave candidata. Como una tabla est en Forma Normal de Boyce-Codd si solo existen dependencias funcionales elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria est formada por un solo atributo y est en 3FN, sta a su vez est en FNBC. Cmo en una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales). Se dice que una tabla est en FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En trminos menos formales, una tabla est en FNBC si est 3FN y los nicos determinantes son claves candidata La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todava pueden existir sobre otras claves candidatas, si stas existen. La BCFN es ms fuerte que la 3FN, por lo tanto, toda relacin en BCFN est en 3FN. La violacin de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relacin viola la BCFN si tiene dos o ms claves candidatas compuestas que tienen al menos un atributo en comn.

12

Un ejemplo tpico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, puede ser una tabla que posee los atributos Direccin, Cdigo Postal y Ciudad, deduciendo que a Ciudades diferentes le corresponden cdigos postales distintos.

Tabla en tercera forma normal CPost Dir 3000 C/ Las Flores N17 Ciud Merida

4858 Av. Bolvar este N72 Maracay

En este caso hay dependencia entre el Cdigo Postal y la Ciudad, ya que, conocido el Cdigo Postal se puede conocer la Ciudad, y conocida la Direccin y la Ciudad, se conoce el Cdigo Postal. Para transformar la tabla en una tabla en FNBC se crea una tabla de Cdigos Postales y Ciudades, eliminando de la tabla original la Ciudad, obtenindose dos tablas, una con los atributos Direccin y Cdigo Postal y otra con el Cdigo Postal y la Ciudad

Tabla en forma normal de Boyce-Codd CPost 3000 4858 Dir C/ Las Flores N17 Av. Bolvar este N72

Tabla en forma normal de Boyce-Codd CPost 3000 4858 Ciud Merida Maracay

En la mayora de los casos, las relaciones en 3FN estarn en FNBC. Para Validar esto se deben ubicar todos los determinantes existentes en la relacin as como todas las claves candidatas, se comparan ambos conjuntos y si encuentra que hay algn determinante que no resulta ser clave candidata se demuestra que no esta en FNBC. Se comprueba que la relacin est en 1FN, todos los atributos son atmicos. Tambin est en 2FN ya que no hay dependencias funcionalmente completas entre atributos que no sean clave (formen parte de la clave). Y finalmente se verifica que no hay ningn atributo que dependa de forma transitiva de la clave Primaria, luego est en 3FN. Usualmente se considera aceptable tener relaciones que lleguen slo hasta la FNBC. La definicin de la 3FN no produce diseos satisfactorios cuando se dan las siguientes condiciones, o lo que es lo mismo, cuando una relacin NO ESTE EN FNBC concurrirn las siguientes circunstancias:

Existen varias claves candidatas. Las claves candidatas son compuestas. Las claves candidatas se encubren, tienen al menos un atributo en comn.

13

No hay un teorema sobre la divisin de la relacin, el motivo es que no se puede asegurar que al descomponer una relacin en dos para conseguir la FNBC el significado de las relaciones obtenidas se corresponda semnticamente a lo que representa la relacin inicial. En otras palabras, se puede tomar una decisin equivocada al descomponer ya que puede que perdamos parte de la semntica de la relacin anterior.

CUARTA FORMA NORMAL (4FN)

Se dice que una tabla que est en forma normal de Boyce-Codd y de la cual se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos; es una tabla en 4 forma Normal Al hablar de dependencia funcional multivaluadas o de mltiples valores, se refiere a la existencia a la relacin que pudiera darse por ejemplo dados tres atributos de una tabla, si para cada valor del primer atributo existen mltiples valores en el segundo atributo y no hay ninguna relacin entre el tercer atributo y el primero, a no ser a travs del segundo atributo. Una tabla est en Cuarta Forma Normal o 4FN si est en FNBC y las nicas dependencias funcionales multivaluadas que existen son las dependencias funcionales de la clave con los atributos que no forman parte de la misma. Estas dependencias multivaluadas de la clave con los atributos que no forman parte de la misma son dependencias triviales, por lo que algunos autores dicen que no existen dependencias multivaluadas en 4FN. En base de datos se entiende por dependencia Multivaluada el caso en que en una tupla (X,Y,Z). se dice que Y esmultidependiente de X (X ---> Y) si y slo si el conjunto de valores de Y correspondiente a un par (X,Z) depende slo del valor de X y es independiente del valor de Z. Las dependencias multivaluadas slo se presentan si existen tres atributos y cuando lo hacen es a pares, es decir ocurre que Y es multidependiente de X y Z es tambinmultidependiente de X. Consideremos que los atributos de una tabla Transporte son Conductor, Tipo de Vehculo y Tipo de Carga, formando los tres campos la clave primaria. A cada Conductor se le puede asignar un Vehculo u otro y cada Vehculo puede transportar varios Tipos de Carga.

Tabla que no esta en cuarta forma normal Transporte Conductor Tipo Vehculo Tipo Carga Juan Marcos Juan Marcos Juan Marcos Camioneta Camioneta Camioneta Camioneta Camin Camin Perecederos Perecederos Muebles Muebles Mudanza Mudanza

14

Bajo estas condiciones, los Conductores son independientes de la carga; el Tipo de Vehculos depende del Conductor y el Tipo de Vehculo depende de la Carga. En este caso hay dependencias funcionales multivaluadas, ya que algunos atributos que forman la clave dependen de otro atributo que tambin la forman. Para conseguir que esta tabla est en 4FN se necesita crear dos nuevas tablas en lugar de la tabla actual, manteniendo en cada una de ellas una dependencia mltiple. La primera tabla tendr los atributos conductor y tipo de vehculo y la segunda, tipo de vehculo y tipo de carga. De este modo la tabla en 4FN debido a que la clave primaria de ambas tablas son todos los campos que la forman. Resultado:

Tabla en cuarta forma normal Tipo Vehculo Tipo Carga Camioneta Camioneta Camioneta Camioneta Camin Camin Perecederos Perecederos Muebles Muebles Mudanza Mudanza

Tabla en cuarta forma normal Conductor Tipo Vehculo Camioneta Juan Marcos Juan Marcos Juan Marcos Camioneta Camioneta Camioneta Camin Camin

En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla. La 4FN es en cierto modo bastante compleja de identificar, hay que tener muy claro sobre todo el significado de lo que representa la relacin analizada. Para verlo de forma prctica procederemos a definir una nueva relacin para comprobar despus si est en 4FN. Algo que vital y que se aplica para cualquier estado de la normalizacin es que se debe tener siempre en cuenta el significado semntico de las relaciones de lo contrario se puede caer en el error de descomponer o disear una base de datos que, aunque est perfectamente

15

Una relacin est en cuarta forma normal (4FN) si est en FNBC y todas las dependencias multivaluadas en ella son de hecho dependencias funcionales.

4.7 ALGORITMOS DE DESCOMPOSICIN. 4.8 FORMAS NORMALES SUPERIORES.

La normalizacin es un proceso que pretende conseguir tablas con una estructura ptima y eficaz. El proceso de normalizacin est basado en lograr la independencia de los datos respecto a las aplicaciones que los usan. Antes de empezar el proceso, se han de conocer las tablas que intervendrn y las relaciones que las unen. Si no se conocen a partir del anlisis previo, se buscan todos los nombres (sustantivos) que han sido empleados en la definicin del problema. Algunos de esos nombres sern las entidades, otros dependern de ellas y sern los atributos. Otros no formarn parte ni de las entidades ni de los atributos, son parte del lenguaje necesario para describir el problema a solucionar mediante la creacin de una base de datos. Ejemplo prctico. <<...a cada cliente, al pasar por Caja... se marcan por la caja registradora los artculos que ha comprado. Con los datos de los artculos se hace una factura por el importe total de las mercancas adquiridas que se imprime y se entrega al cliente. Los datos de la factura se almacenan para su posterior tratamiento informtico que comprende...>>. Las tablas son sustantivos, por lo que tenemos los siguientes: cliente, Caja, caja registradora, artculos, datos de los artculos, factura, importe total, mercancas adquiridas, datos de la factura. De estos nombres, algunos son atributos de otros: datos de los artculos y artculos, datos de la factura, importe total y factura. De cada cliente no se piden datos, por lo que aunque sea una tabla, si no se necesitan sus datos, no se crear esa entidad. Caja con mayscula se refiere a un objeto con el que se realizan procesos, por lo que no se necesita almacenar informacin de ellos. De cada una de las cajas registradoras, tal vez se necesite para las facturas, el nmero de caja, por lo que se considera una entidad ms. Mercancas adquiridas y artculos que ha comprado son sinnimos, por lo que solo se tratar de artculos. Las tablas encontradas tras el anlisis son: artculos, factura y caja registradora. Caja registradora se puede considerar un atributo de factura, por lo que tenemos dos tablas. Las relaciones se pueden encontrar conociendo todos los verbos que aparecen en la definicin del problema. Se eliminan aquellos verbos que son necesarios para el lenguaje y se buscan aquellos que implican dos o ms entidades (sustantivos) que ya se han encontrado. En el ejemplo han aparecido los verbos: pasar, se marcan, ha comprado, se hace una factura, imprime, entrega, almacena. De estos verbos, los que asocian entidades son: marcar, comprar. Los verbos pasar, hacer factura, imprimir, entregar, almacenar, se refieren a procesos que se van a realizar, no a asociaciones entre entidades. Se han obtenido las siguientes entidades con sus relaciones: clientes, comprar artculos y marcar artculos en factura. Como no se necesitan los datos de los clientes, queda la relacin marcada (en la caja registradora) que une las tablas artculos, y factura. La

16

operacin marcar en la caja registradora significa que los artculos se incluyen en una factura que se entregar al cliente para su liquidacin, consiguindose obtener el modelo entidad-relacin siguiente:

Para bases de datos relativamente sencillas se puede terminar la normalizacin en el tercer nivel o tercera forma normal. El proceso de normalizacin se basa en la descomposicin sin prdida de las tablas que estn en una forma normal inferior, obtenindose una forma normal superior. El proceso de descomposicin sin prdida, significa que se ha de dividir o descomponer la tabla en otras con menor cantidad de atributos sin que haya prdida de informacin.

4.9 INTEGRIDAD DE LAS BASES DE DATOS.

El trmino integridad de datos se refiere a la correccin y completitud de los datos en una base de datos. Cuando los contenidos se modifican con sentencias INSERT, DELETE o UPDATE, la integridad de los datos almacenados puede perderse de muchas maneras diferentes. Pueden aadirse datos no vlidos a la base de datos, tales como un pedido que especifica un producto no existente. Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios en la base de datos pueden perderse debido a un error del sistema o a un fallo en el suministro de energa. Los cambios pueden ser aplicados parcialmente, como por ejemplo si se aade un pedido de un producto sin ajustar la cantidad disponible para vender. Una de las funciones importantes de un DBMS relacional es preservar la integridad de sus datos almacenados en la mayor medida posible. Condiciones de la Integridad Las condiciones que garantizan la integridad de los datos pueden ser de dos tipos: 1. Las restricciones de integridad de usuario: son condiciones especficas de una base de datos concreta; son las que se deben cumplir en una base de datos articular con unos usuarios concretos, pero que no son necesariamente relevantes en otra Base de Datos. 2. Las reglas de integridad de modelo: son condiciones propias de un modelo de datos, y se deben cumplir en toda base de datos que siga dicho modelo. Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de una base de datos y una vez definida, debe velar por su cumplimiento. Las reglas de integridad del modelo, en cambio, no se deben definir para cada base de datos concreta, porque se consideran preestablecidas para todas las base de datos de un modelo. Un SGBD de un modelo determinado debe velar por el cumplimiento de las reglas de integridad preestablecidas por su modelo.

17

REGLAS DE INTEGRIDAD

Regla de integridad de unicidad de la clave primaria

La regla de integridad de unicidad est relacionada con la definicin de clave primaria que establece que toda clave primaria que se elija para una relacin no debe tener valores repetidos por lo que el conjunto de atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede tener en ningn momento dos tuplas con la misma combinacin de valores para los atributos de CP.

Regla de integridad de entidad de la clave primaria

La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una relacin no pueden tener valores nulos. Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran distinguir. Un SGBD relacional tendr que garantizar el cumplimiento de esta regla de integridad en todas las inserciones y en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relacin.

Regla de integridad referencial

La regla de integridad referencial est relacionada con el concepto de clave fornea, lo que determina que todos los valores que toma una clave fornea deben ser valores nulos o valores que existen en la clave primaria que referencia. La necesidad de esta regla es debido a que las claves forneas tienen por objetivo establecer una conexin con la clave primaria que referencian. Si un valor de una clave fornea no estuviese presente. Restriccin La restriccin en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave primaria referenciada por alguna clave fornea y la restriccin en caso de modificacin consiste en no permitir modificar ningn atributo de la clave primaria de una tupla si tiene una clave primaria referenciada por alguna clave fornea. Actualizacin en cascada La actualizacin en cascada consiste en permitir la operacin de actualizacin de la tupla, y en efectuar operaciones compensatorias que propaguen en cascada la actualizacin a las tuplas que la referenciaban; se acta de este modo para mantener la integridad referencial. La actualizacin en cascada en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave primaria referenciada, y borrar tambin todas las tuplas que referencian t y la actualizacin en cascada en caso de modificacin consiste en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y modificar del mismo modo todas las tuplas que referencian t. Anulacin La anulacin consiste en permitir la operacin de actualizacin de la tupla y en efectuar operaciones compensatorias que pongan valores nulos a los atributos de la clave fornea de las tuplas que la referencian; esta accin se lleva a cabo para mantener la integridad referencial. Los SGBD relacionales permiten establecer que un determinado atributo de una relacin no admite valores nulos, slo se puede aplicar la poltica de anulacin si los atributos de la clave fornea s los admiten. Ms concretamente, la anulacin en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave referenciada y,

18

adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos y la anulacin en caso de modificacin consiste en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos.

Regla de integridad de dominio

La regla de integridad de dominio est relacionada con la nocin de dominio. Esta regla establece dos condiciones. La primera condicin consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta condicin implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo. La segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un operador determinado slo se puede aplicar sobre valores que tengan dominios que le sean adecuados.

19

20

LENGUAJE SQL
Los lenguajes formales proporcionan una notacin concisa para la representacin de consultas. Sin embargo, los sistemas de bases de datos comerciales necesitan un lenguaje de consultas cmodo para el usuario. En este captulo se estudia el lenguaje comercial de mayor influencia, SQL. SQL usa una combinacin de lgebra relacional y construcciones del clculo relacional.

6.1 INTRODUCCIN.
El lenguaje Sequel ha evolucionado desde entonces y su nombre ha pasado a ser SQL (Structured Query Language, Lenguaje estructurado de consultas). Actualmente, numerosos productos son compatibles con el lenguaje SQL. SQL se ha establecido como el lenguaje estndar de bases de datos relacionales. Tambin hay ser consciente de que algunos sistemas de bases de datos ni siquiera soportan todas las caractersticas de SQL-92 y de que muchas bases de datos proporcionan caractersticas no estndar que no se tratan aqu. El lenguaje SQL tiene varios componentes: Lenguaje de definicin de datos (LDD). El LDD de SQL proporciona rdenes para la definicin de esquemas de relacin, borrado de relaciones, creacin de ndices y modificacin de esquemas de relacin. Lenguaje interactivo de manipulacin de datos (LMD). El LMD de SQL incluye un lenguaje de consultas, basado tanto en el lgebra relacional como en el clculo relacional de tuplas. Incluye tambin rdenes para insertar, borrar y modificar tuplas de la base de datos. Definicin de vistas. El LDD de SQL incluye rdenes para la definicin de vistas. Control de transacciones. SQL incluye rdenes para la especificacin del comienzo y final de transacciones. SQL incorporado y SQL dinmico. SQL dinmico e incorporado define cmo se pueden incorporar las instrucciones SQL en lenguajes de programacin de propsito general, tales como C, C++, Java, PL/I, Cobol, Pascal y Fortran. Integridad. El LDD de SQL incluye rdenes para la especificacin de las restricciones de integridad que deben satisfacer los datos almacenados en la base de datos. Las actualizaciones que violen las restricciones de integridad se rechazan. Autorizacin. El LDD de SQL incluye rdenes para especificar derechos de acceso para las relaciones y vistas. Se describe brevemente SQL incorporado y dinmico, incluyendo las normas ODBC y JDBC para la interaccin con una base de datos desde programas escritos en lenguajes C y Java. Las caractersticas de SQL que dan soporte a la integridad y autorizacin, mientras que esboza las extensiones orientadas a objeto de SQL. Los ejemplos se basarn en una empresa bancaria, con los siguientes esquemas de relacin: Esquema-sucursal = (nombre-sucursal, ciudad-sucursal, activo) Esquema-cliente = (nombre-cliente, calle-cliente, ciudad-cliente) Esquema-prstamo = (nmero-prstamo, nombre-sucursal, importe) Esquema-prestatario = (nombre-cliente, nmero-prstamo)

21

Esquema-cuenta = (nmero-cuenta, nombresucursal, saldo) Esquema-impositor = (nombre-cliente, nmero-cuenta) Sin embargo, en los sistemas SQL actuales, los guiones no son partes vlidas de un nombre (se tratan como el operador menos). Una forma simple de traducir los nombres que se usan aqu a nombres SQL vlidos es reemplazar todos los guiones por el smbolo de subrayado (_). Por ejemplo, se usa nombre_sucursal en lugar de nombre-sucursal.

6.2 DEFINICIN DE DATOS.

El conjunto de relaciones de cada base de datos debe especificarse en el sistema en trminos de un lenguaje de definicin de datos (LDD). El LDD de SQL no solo permite la especificacin de un conjunto de relaciones, sino tambin de la informacin relativa a esas relaciones, incluyendo: El esquema de cada relacin El dominio de valores asociados a cada atributo. Las restricciones de integridad. El conjunto de ndices que se debe mantener para cada relacin. La informacin de seguridad y de autorizacin de cada relacin La estructura de almacenamiento fsico de cada relacin en el disco Sucursal (nombre_sucursal, ciudad_sucursal, activos) Cliente (nombre-cliente, calle_cliente, ciudad_cliente) Prstamo (numero-prestamo, nombre_sucursal, importe) Prestatario (nombre-cliente, numero-prestamo) Cuenta (numero-cuenta, nombre_sucursal, saldo) Impostor (nombre-cliente,numero-cuenta ) A continuacin se analizara la definicin de los esquemas y los valores bsicos de los dominios; el anlisis de las dems caractersticas del LDD de SQL. TIPOS BSICOS DE DOMINIO La norma SQL soporta gran variedad de tipos de dominios predefinidos, entre ellos: Char(n). Una cadena de caracteres de longitud fija, con una longitud n especificada por el usuario. Tambin se puede utilizar la palabra completa charcter. Varchar(n). una cadena de caracteres de longitud variable con una longitud mxima n especificada por el usuario. La forma completa, charcter varying, es equivalente. Int. Un entero (un subconjunto finito de los enteros dependientes de la maquina). La palabra completa, integer, es equivalente. Smallint. Un entero pequeo (un subconjunto dependiente de la maquina del tipo dominio entero.) Numeric (p,d). un nmero de coma fija, cuya precisin la especifica el usuario. El numero est formado por p dgitos (mas el signo), y de esos p digitos, d pertenecen a la parte decimal. Asi, numeric (3,1) permite que el nmero 44.5 se almacene exactamente, pero ni 444.5 ni 0.32 se pueden almacenar exactamente en un campo de este tipo. Real, doubl presicion. Nmeros de coma flotante y nmeros de coma flotante de doble precisin, con precisin dependiente de la maquina.

22

Float (n). un nmero de coma flotante cuya presicion es, la menos, de n digitos.

DEFINICIN BSICA DE ESQUEMAS SQL Las relaciones se definen mediante el comando create table: Create table r (A1 D1, A2 D2,..An Dn) (restriccion-integridad1) ., (restriccin-integridad) Donde r es el nombre de la relacin, cada Ai es el nombre de un atributo del esquema de la relacin r y Di es el tipo de dominio de los valores del dominio del atributo Ai. Hay varias restricciones de integridad validas. En este aparato solo se estudiaran las de clave primaria (primary key), que adopta la forma: o Primary key (Aj1, Aj2,., Ajm). La especificacin de clave primaria determina que los atributos Aj1, Aj2,..,Ajm forma la clave primaria de la relacin. Los atributos de la clave primaria tienen que ser no nulos y nicos; es decir, ninguna tupla puede tener un valor nulo para un atributo de la clave primaria y ningn par de tuplas de la relacin puede ser igual en todos los atributos de la clave primaria para cada relacin. Ejemplo: Obsrvese que, no se intenta modelar con precisin el mundo real e el ejemplo de la base de datos bancaria. En el mundo real, varias personas pueden llamarse igual, por lo que nombre_clientes no seria clave primaria del cliente; probablemente se utilizara un id_cliente como clave primaria. Create table cliente (nombre_cliente char(20) Calle_cliente char (30) Ciudad_cliente char(30) Primary key (nombre_cliente) Create table sucursal (nombre_sucursal char(15) Ciudad_sucursal char(30) Activos numeric(16,2) Primary key (numero_sucursal)) Create table cuenta (numero_cuenta char(10) Nombre_sucursal char(15) Saldo numeric(12,2) Primary key (numero_cuenta) Create table impositor (nombre_cliente char(20) Numero_cuenta char(10) Primary key (nombre_cliente, numero_cuenta)) Definicin de datos en SQL para parte de la base de datos del banco

23

Aqu se utiliza nombre_cliente como clave primaria para mantener el esquema de la base de datos sencillo y de pequeo tamao. Si una tupla recin insertada o recin modificada de una relacin contiene valores nulos para cualquiera de los atributos que forma parte de la clave primaria, o si tiene el mismo valor en ellos que otra tupla de la relacin, SQL notifica el erro e impide la actualizacin. Las relaciones recin creadas estn inicialmente vacas. Se puede utilizar el comando insert para aadir datos a la relacin. Por ejemplo, si se desea aadir en hecho de que haya una cuenta C-9732 en la sucursal de NAVACERRADA con un saldo de 1,200, hay que escribir. Insert into cuenta Values (C-9732, NAVACERRADA, 1,200) Los valores se especifican en el orden en que se relacionan los atributos correspondientes en el esquema de la relacin. El comando insert ofrece una serie de caractersticas tiles. Se puede utilizar el comando delet para borrar tuplas de una relacin. El comando Delet from cuenta Borrara todas las tuplas de la relacin cuenta. Otras formas del comando delet permite borrar solo tuplas correctas. Para eliminar una relacin de una base de datos SQL se utiliza el comando drop table. Este comando elimina de la base de datos toda la informacin de la relacin. La instruccin. Drop table r es una accin ms drstica que delet from r La ultima conserva la relacin r pero borra todas sus tuplas. La primera no solo borra todas las tuplas de la relacin r , sino que tambin elimina su esquema. Una vez eliminada r no se puede insertar ninguna tupla en dicha relacin, a menos que se vuelva a crear con la instruccin create table. El comando alter table se utiliza para aadir atributos a una relacin existente. Se asignas a todas las tuplas de la relacin un valor nulo como la del atributo nuevo. La forma del comando alter table es: Alter table r add A D Donde r es el nombre de una relacin ya existente, A es el nombre del atributo que se desea aadir y D es el dominio del atributo aadido. Se pueden eliminar atributos de una relacin utilizando el comando Alter table r drop A Donde r es el nombre de una relacin existente y A es el nombre de un atributo de la relacin. Muchos sistemas de bases de datos no permiten el borrado de atributos, aunque si permiten el borrado de las tablas completas.

6.3 ESTRUCTURA BSICA DE LAS CONSULTAS.

24

Las bases de datos relacionales estn formadas por un conjunto de relaciones, a cada una de las cuales se le asignan un nombre nico. Cada relacin posee una estructura similar SQL que permite el uso de valores nulos para indicar que el valor es desconocido o no existe. La estructura bsica de una expresin SQL consta de tres clausulas: select,from y where. La clausula select se corresponde con la operacin proyeccin del algebra relacional. Se usa para tener una relacin de los atributos deseados en el resultado de una consulta. La clausula from se corresponde con la operacin producto cartesiano del algebra relacional. Genera una lista de las relaciones que deben ser analizadas en la evaluacin de la expresin. La clausula where se corresponde con el predicado seleccin del algebra relacional. Es un predicado que engloba a los atributos de las relaciones que aparecen en la clausula from. Las consultas habituales de SQL tienen la forma. Select A, A, .., An From r, r, .., rm Where P Cada A, representa un atributo y cada r, una relacin. P es un predicado. La consulta es equivalente a la expresin del algebra relacional. II A, A,., An ( P(r x r x rm)) Si se omite la clausula where, el predicado P es cierto. Si embargo, la diferencia de la expresin del algebra relacional, el resultado del a consulta SQL puede contener varias copias de alguna tuplas. SQL forma el producto carteciano de las relaciones incluidas en la clausula from, lleva acabo las seleecion del algebra relacional utilizando del algebra relacional utilizando el predicado de la clausula where y despus proyecta el resultado sobre los atributos de la clausula select. en la practica.

6.4 OPERACIONES SOBRE CONJUNTOS.

Las operaciones de SQL-92 union, intersect y except operan sobre relaciones y corresponden a las operaciones del lgebra relacional , y . Al igual que la unin, interseccin y diferencia de conjuntos en el lgebra relacional, las relaciones que participan en las operaciones han de ser compatibles; esto es, deben tener el mismo conjunto de atributos. Se demuestra cmo se pueden formular en SQL varias de las consultas de ejemplo consideradas utilizando consultas que incluyen las operaciones union, intersect y except de dos conjuntos. Los dos conjuntos utilizados sern: el conjuntos de todos los clientes que tienen una cuenta en el banco, que puede obtenerse con: select nombre-cliente from impositor y el

25

conjunto de todos los clientes que tienen un prstamo en el banco, que puede obtenerse con: select nombre-cliente from prestatario A partir de ahora, las letras i y p se utilizarn para hacer referencia a las relaciones obtenidas como resultado de las dos consultas anteriores. LA OPERACION UNIN Para encontrar todos los clientes que poseen un prstamo, una cuenta o las dos cosas en el banco, se escribir: (select nombre-cliente from impositor) union (select nombre-cliente from prestatario) A diferencia de la clusula select, la operacin unin (unin) elimina duplicados automticamente. As, en la consulta anterior, si un cliente por ejemplo, Santos tiene varias cuentas o prstamos (o ambas cosas) en el banco, entonces Santos aparecer slo una vez en el resultado. Para conservar los duplicados, se utilizar union all en lugar de union: (select nombre-cliente from impositor) union all (select nombre-cliente from prestatario) El nmero de tuplas duplicadas en el resultado es igual al nmero total de duplicados que aparecen en i y p. As, si Santos tuviese tres cuentas y dos prstamos en el banco, entonces en el resultado apareceran cinco tuplas con el nombre de Santos. LA OPERACIN INTERSECCIN Para encontrar todos los clientes que tienen tanto un prstamo como una cuenta en el banco, se escribir: (select distinct nombre-cliente from impositor) intersect (select distinct nombre-cliente from prestatario) La operacion intersect (interseccin) elimina duplicados automticamente. As, en la consulta anterior, si un cliente por ejemplo, Santos tiene varias cuentas o prstamos (o ambas cosas) en el banco, entonces Santos aparecer solo una vez en el resultado. Para conservar los duplicados se utilizar intersect all en lugar de intersect: (select nombre-cliente from impositor)

26

intersect all (select nombre-cliente from prestatario) El nmero de tuplas duplicadas en el resultado es igual al mnimo nmero de duplicados que aparecen en i y p. As, si Santos tuviese tres cuentas y dos prstamos en el banco, entonces en el resultado de la consulta apareceran dos tuplas con el nombre de Santos. LA OPERACIN EXCEPTO Para encontrar todos los clientes que tienen cuenta pero no tienen ningn prstamo en el banco se escribir: (select distinct nombre-cliente from impositor) except (select distinct nombre-cliente from prestatario) La operacion except (excepto) elimina duplicados automticamente. As, en la consulta anterior, una tupla con el nombre de Santos aparecer en el resultado (exactamente una vez), slo si Santos tiene una cuenta en el banco, pero no tiene ningn prstamo en el mismo. Para conservar los duplicados, se utilizar except all en lugar de except: (select nombre-cliente from impositor) except all (select nombre-cliente from prestatario) El nmero de copias duplicadas de una tupla en el resultado es igual al nmero de copias duplicadas de dicha tupla en i menos el nmero de copias duplicadas de la misma tupla en p, siempre que la diferencia sea positiva. As, si Santos tuviese tres cuentas y un prstamo en el banco, entonces en el resultado apareceran dos tuplas con el nombre de Santos.

6.5 FUNCIONES DE AGREGACIN.

Las funciones de agregacin son funciones que toman una coleccin (un conjunto o multiconjunto) de valores como entrada y producen un nico valor como salida. SQL proporciona cinco funciones de agregacin primitivas: Media: avg Mnimo: min Mximo: max Total: sum Cuenta: count La entrada a sum y avg debe ser una coleccin de nmeros, pero los otros operadores pueden operar sobre colecciones de datos de tipo no numrico, tales como las cadenas.

27

Como ejemplo, considrese la consulta Obtener la media de saldos de las cuentas de la sucursal Navacerrada . Esta consulta se puede formular del modo siguiente: select avg (saldo) from cuenta where nombre-sucursal = Navacerrada El resultado de esta consulta ser una relacin con un nico atributo, que contendr una nica fila con un valor numrico correspondiente al saldo medio de la sucursal. Navacerrada. Opcionalmente se puede dar un nombre alatributo resultado de la relacin, usando la clusula as. El atributo o atributos especificados en la clusula group by se usan para formar grupos. Las tuplas con el mismo valor en todos los atributos especificados en la clusula group by se colocan en un grupo. Como ejemplo, considrese la consulta Obtener el saldo medio de las cuentas de cada sucursal. Dicha consulta se formular del modo siguiente: select nombre-sucursal, avg (saldo) from cuenta group by nombre-sucursal La conservacin de duplicados es importante al calcular una media. Supngase que los saldos de las cuentas en la (pequea) sucursal de nombre Galapagar son 1.000 , 3.000 , 2.000 y 1.000 . El saldo medio es 7.000/4 =1.750 . Si se eliminasen duplicados se obtendra un resultado errneo (6.000/3 = 2.000 ). Hay casos en los que se deben eliminar los duplicados antes de calcular una funcin de agregacin. Para eliminar duplicados se utiliza la palabra clave distinct en la expresin de agregacin. Como ejemplo considrese la consulta Obtener el nmero de impositores de cada sucursal. La consulta se formular del modo siguiente: select nombre-sucursal, count (distinct nombrecliente) from impositor, cuenta where impositor.nmero-cuenta = cuenta.nmerocuenta group by nombre-sucursal A veces es ms til establecer una condicin que se aplique a los grupos que una que se aplique a las tuplas. Por ejemplo, podemos estar interesados slo en aquellas sucursales donde el saldo medio de cuentas es superior a 1.200 . Esta condicin no es aplicable a una nica tupla; se aplica a cada grupo construido por la clusula group by. Para expresar este tipo de consultas se utiliza la clusula having de SQL. Los predicados de la clusula having se aplican despus de la formacin de grupos, de modo que se pueden usar las funciones de agregacin. Esta consulta se expresa en SQL del modo siguiente:

28

select nombre-sucursal, avg (saldo) from cuenta group by nombre-sucursal having avg (saldo) > 1200 A veces se desea tratar la relacin entera como un nico grupo. En casos de este tipo no se usa la clusula group by. Considrese la consulta Obtener el saldo medio de todas las cuentas. Esta consulta se formulardel modo siguiente: select avg (saldo) from cuenta Con mucha frecuencia se usa la funcin de agregacin count para contar el nmero de tuplas de una relacin. La notacin para esta funcin en SQL es count (*). As, para encontrar el nmero de tuplas de la relacin cliente, se escribir select count (*) from cliente SQL no permite el uso de distinct con count (*). S se permite, sin embargo, el uso de distinct con max y min, incluso cuando el resultado no cambia. Se puede usar la palabra clave all en lugar de distinct para especificar la retencin de duplicados, pero como all se especifica de manera predeterminada, no es necesario incluir dicha clusula. Si en una misma consulta aparece una clusula where y una clusula having, se aplica primero el predicado de la clusula where. Las tuplas que satisfagan el predicado de la clusula where se colocan en grupos segn la clusula group by. La clusula having, si existe, se aplica entonces a cada grupo; los grupos que no satisfagan el predicado de la clusula having se eliminan. La clusula select utiliza los grupos restantes para generar las tuplas resultado de la consulta. Para ilustrar el uso de la clusula where y la clusula having dentro de la misma consulta considrese el ejemplo Obtener el saldo medio de cada cliente que vive en Madrid y tiene como mnimo tres cuentas. select impositor.nombre-cliente, avg (saldo) from impositor, cuenta, cliente where impositor.nmero-cuenta = cuenta.nmero-cuenta and impositor.nombre-cliente = cliente.nombre-cliente and ciudad-cliente = Madrid group by impositor.nombre-cliente having count (distinct impositor.nmero-cuenta) >= 3

6.6 VALORES NULOS.

SQL permite el uso de valores nulos para indicar la ausencia de informacin sobre el valor de un atributo. En un predicado se puede usar la palabra clave especial null para

29

comprobar si un valor es nulo. As, para encontrar todos los nmeros de prstamo que aparecen en la relacin prstamo con valores nulos para importe se escribe select nmero-prstamo from prstamo where importe is null

El predicado is not null pregunta por la ausencia de un valor nulo. El uso de un valor nulo en las operaciones aritmticas y de comparacin causa varias complicaciones. El resultado de una expresin aritmtica (incluyendo por ejemplo +,,* o /) es nulo si cualquiera de los valores de entrada es nulo. SQL trata como desconocido el resultado de cualquier comparacin que implique un valor nulo (aparte de is null e is not null). Dado que el predicado en una clusula where puede incluir operaciones booleanas tales como and, or y not sobre los resultados de las comparaciones, las definiciones de estas operaciones se extienden para manejar el valor desconocido, como se describe en el Apartado and: el resultado de cierto and desconocido es desconocido, falso and desconocido es falso, mientras que desconocido and desconocido es desconocido. or: el resultado de cierto or desconocido es cierto, falso or desconocido es desconocido, mientras que desconocido or desconocido es desconocido.

SQL define el resultado de una instruccin SQL de la forma: select from R1, ., Rn where P para contener (proyecciones de) tuplas en R1 Rn para las que el predicado P se evala a cierto. Si el predicado se evala a falso o desconocido para una tupla de R1 Rn (la proyeccin de) la tupla no se aade al resultado. SQL tambin permite determinar si el resultado de una comparacin es desconocido en lugar de cierto o falso usando las clusulas is unknown (es desconocido) e is not unknown (no es desconocido) La existencia de valores nulos tambin complica el procesamiento de los operadores de agregacin. Supngase que algunas tuplas en la relacin prstamo tienen valor nulo para el atributo importe. Considrese en ese caso la siguiente consulta, que calcula el total de todas las cantidades prestadas: select sum (importe) from prstamo Los valores que van a ser sumados en la consulta anterior incluyen valores nulos, puesto que algunas tuplas tienen valor nulo para el atributo importe. En lugar de decir que la suma total es nula, la norma SQL establece que el operador sum debera ignorar los valores nulos de su entrada. En general, las funciones de agregacin tratan los valores nulos segn la regla siguiente: todas las funciones de agregacin excepto count(*) ignoran los valores nulos de la coleccin de datos de entrada. El clculo de count de una coleccin vaca se define como

30

0 y todas las dems operaciones de agregacin devuelven un valor nulo cuando se aplican sobre una coleccin de datos vaca.

6.7 CONSULTAS ANIDADAS.

SQL proporciona un mecanismo para las subconsultas anidadas. Una subconsulta es una expresin select-fromwhere que se anida dentro de otra consulta. PERTENENCIA A CONJUNTOS SQL utiliza el clculo relacional para las operaciones que permiten comprobar la pertenencia de una tupla a una relacin. La conectiva in comprueba la pertenencia a un conjunto, donde el conjunto es la coleccin de valores resultado de una clusula select. La conectiva not in comprueba la no pertenencia a un conjunto. Como ejemplo considrese de nuevo la consulta Encontrar todos los clientes que tienen tanto un prstamo como una cuenta en el banco. Anteriormente escribimos esta consulta como la interseccin de dos conjuntos: el conjunto de los impositores del banco y el conjunto de los prestatarios del banco. Claramente, esta formulacin genera el mismo resultado que la anterior, pero obliga a formular la consulta usando la conectiva in de SQL. A continuacin, se van a obtener todos los tenedores de cuentas formulando as la siguiente subconsulta: (select nombre-cliente from impositor) A continuacin es necesario encontrar aquellos clientes que son prestatarios del banco y que aparecen en la lista de tenedores de cuenta, obtenida como resultado de la subconsulta anterior. Esto se consigue anidando la subconsulta en un select ms externo. La consulta resultante es la siguiente: select distinct nombre-cliente from prestatario where nombre-cliente in (select nombre-cliente from impositor) Este ejemplo muestra que es posible escribir la misma consulta de diversas formas en SQL. Esta flexibilidad es de gran utilidad, puesto que permite al usuario pensar en una consulta del modo que le parezca ms natural. En el ejemplo anterior se comprobaba la pertenencia a un conjunto en una relacin de un solo atributo. As, se puede formular la consulta Listar los clientes que tienen tanto una cuenta como un prstamo en la sucursal Navacerrada de un modo distinto al visto anteriormente: select distinct nombre-cliente from prestatario, prstamo where prestatario.nmero-prstamo = prstamo.nmero-prstamo and nombre-sucursal = Navacerrada and (nombre-sucursal, nombre-cliente) in (select nombre-sucursal, nombre-cliente from impositor, cuenta

31

where impositor.nmero-cuenta = cuenta. nmero-cuenta) A continuacin, se ilustra el uso de la constructora not in. Por ejemplo, para encontrar todos los clientes que tienen un prstamo en el banco, pero no tienen una cuenta en el banco, se puede escribir select distinct nombre-cliente from prestatario where nombre-cliente not in (select nombre-cliente from impositor) Los operadores in y not in tambin se pueden usar sobre conjuntos enumerados. La consulta siguiente selecciona los nombres de los clientes que tienen un prstamo en el banco y cuyos nombres no son ni Santos ni Gmez. select distinct nombre-cliente from prestatario where nombre-cliente not in (Santos, Gmez) COMPARACIN DE CONJUNTOS Considrese la consulta Obtener los nombres de todas las sucursales que poseen un activo mayor que al menos una sucursal situada en Barcelona. En el Apartado se formulaba esta consulta del modo siguiente: select distinct T.nombre-sucursal from sucursal as T, sucursal as S where T.activo > S.activo and S.ciudad-sucursal = Barcelona SQL ofrece, sin embargo, un estilo alternativo de formular la consulta anterior. La expresin: mayor que al menos una se representa en SQL por > some. Esta constructora permite reescribir la consulta en una forma ms parecida a la formulacin de la consulta en lenguaje natural. select nombre-sucursal from sucursal where activo > some (select activo from sucursal where ciudad-sucursal = Barcelona) La subconsulta (select activo from sucursal where ciudad-sucursal = Barcelona) genera el conjunto de todos los valores de activo para todas las sucursales sitas en Barcelona. La comparacin> some, en la clusula where de la clusula select ms externa, es cierta si el valor del atributo activo de la tupla es mayor que al menos un miembro del conjunto de todos los valores de activo de las sucursales de Barcelona. SQL tambin permite realizar las comparaciones <some, <= some, >= some, = some y <>

32

some. Como ejercicio, se puede verificar que = some es idntico a in, mientras que <= some no es lo mismo que not in. En SQL, la palabra clave any es sinnimo de some. Las versiones ms antiguas de SQL slo admitan any. Sin embargo, versiones posteriores aadieron la alternativa some para evitar la ambigedad lingstica de la palabra inglesa any. Ahora la consulta se modificar ligeramente a fin de obtener los nombres de todas las sucursales que tienen un activo superior al de todas las sucursales de Barcelona. La constructora > all corresponde a la expresin superior a todas. Utilizando esta constructora la consulta se podra formular del modo siguiente: select nombre-sucursal from sucursal where activo > all (select activo from sucursal where ciudad-sucursal = Barcelona) Al igual que con some, SQL tambin permite utilizar las comparaciones < all, <= all, >= all, = all y <> all. Como ejercicio se puede verificar que <= any es lo mismo que not in. Como otro ejemplo de comparaciones considrese la consulta Encontrar la sucursal que tiene el mayor saldo medio. En SQL, las funciones de agregacin no se pueden componer. As, no est permitido el uso de max (avg ()). Por ello, para la formulacin de esta consulta se seguir la estrategia siguiente: para empezar se formula una consulta para encontrar todos los saldos medios, y luego se anida sta como subconsulta de una consulta ms larga que encuentre aquellas sucursales para las que el saldo medio es mayor o igual que todos los saldos medios: select nombre-sucursal from cuenta group by nombre-sucursal having avg (saldo) >= all (select avg (saldo) from cuenta group by nombre-sucursal)

COMPROBACIN DE RELACIONES VACAS SQL incluye la posibilidad de comprobar si una subconsulta no produce ninguna tupla como resultado. Laconstructora exists devuelve el valor cierto si la subconsulta argumento no es vaca. Usando la constructora exists se puede formular la consulta Obtener los clientes que tienen tanto una cuenta como un prstamo en el banco de otra nueva forma: select nombre-cliente where exists (select * from impositor where impositor.nombre-cliente = prestatario.nombre-cliente)

33

Utilizando la constructora not exists se puede comprobar la inexistencia de tuplas en el resultado de una subconsulta. Adems, es posible usar la constructora not exists para simular la operacin de continencia de conjuntos (es decir, superconjunto). As, se puede escribir la expresin la relacin A contiene a la relacin B como not exists (B except A). Aunque no forma parte de SQL estndar, el operador contains aparece en algunos sistemas relacionales. Para ilustrar el operador not exists considrese otra vez la consulta Obtener todos los clientes que tienen una cuenta en todas las sucursales de Barcelona. Ser necesario comprobar para cada cliente si el conjunto de todas las sucursales en las que dicho cliente tiene cuenta contiene al conjunto de todas las sucursales de Barcelona. Utilizando el operador except se puede formular la consulta del modo siguiente: select distinct S.nombre-cliente from impositor as S where not exists ((select nombre-sucursal from sucursal where ciudad-sucursal = Barcelona) except (select R.nombre-sucursal from impositor as T, cuenta as R where T.nmero-cuenta = R.nmero-cuenta and S.nombre-cliente = T.nombre-cliente )) En este ejemplo, la subconsulta (select nombre-sucursal from sucursal where ciudad-sucursal = Barcelona) obtiene todas las sucursales de Barcelona. Por otro lado, la subconsulta (select R.nombre-sucursal from impositor as T, cuenta as R where T.nmero-cuenta = R.nmero-cuenta and S.nombre-cliente = T.nombre-cliente ) obtiene todas las sucursales en las cuales el cliente S.nombre-cliente tiene una cuenta. Por ltimo, el select ms externo toma cada cliente y comprueba si el conjunto de todas las sucursales en las que dicho cliente tiene cuenta, contiene al conjunto de todas las sucursales de Barcelona. En consultas que contengan subconsultas se aplica una regla de visibilidad para las variables tupla. En una subconsulta, slo se pueden usar variables tupla que estn definidas en la propia subconsulta o en cualquier consulta que contenga a dicha subconsulta. COMPROBACIN DE TUPLAS DUPLICADAS

34

SQL incluye la posibilidad de comprobar si una subconsulta produce como resultado tuplas duplicadas. La constructora unique devuelve el valor cierto si la subconsulta que se le pasa como argumento no produce tuplas duplicadas. Usando la constructora unique se puede formular la consulta Obtener todos los clientes que tienen slo una cuenta en la sucursal de nombre Navacerrada del siguiente modo: select T.nombre-cliente from impositor as T where unique (select R.nombre-cliente from cuenta, impositor as R where T.nombre-cliente = R.nombre-cliente and R.nmero-cuenta = cuenta.nmero-cuenta and cuenta.nombre-sucursal = Navacerrada) La existencia de tuplas duplicadas en una subconsulta se puede comprobar utilizando la constructora not unique. Para ilustrar esta constructora considrese la consulta Obtener todos los clientes que tienen al menos dos cuentas en la sucursal Navacerrada, que se puede formular del modo siguiente: select distinct T.nombre-cliente from impositor as T where not unique (select R.nombre-cliente from cuenta, impositor as R where T.nombre-cliente = R.nombre-cliente and R.nmero-cuenta = cuenta.nmero-cuenta and cuenta.nmero-sucursal = Navacerrada) Formalmente, la comprobacin hecha por la constructora unique sobre una relacin debera fallar si y slo si en la relacin existieran dos tuplas t1 y t2 tales que t1 = t2. Como la comprobacin t1 = t2 slo falla si cualquier campo de t1 o de t2 es nulo, entonces es posible que el resultado de unique sea cierto incluso si existen varias copias de una tupla, siempre que al menos uno de los atributos de la tupla sea nulo.

6.8 CONSULTAS COMPLEJAS.

Las consultas complejas son a menudo difciles o imposibles de escribir como un nico bloque SQL o una unin, interseccin o diferencia de bloques SQL (un bloque SQL consiste en una nica instruccin select from where, posiblemente con clusulas groupby y having). Aqu se estudian dos formas de componer varios bloques SQL para expresar una consulta compleja: las relaciones derivadas y la clusula with. RELACIONES DERIVADAS

35

SQL permite el uso de una expresin de subconsulta en la clusula from. Si se usa una expresin de este tipo se debe dar un nombre a la relacin resultado y se pueden renombrar los atributos usando la clusula as. Por ejemplo, considrese la subconsulta (select nombre-sucursal, avg (saldo) from cuenta group by nombre-sucursal) as media-sucursal (nombre-sucursal, saldo-medio) Esta subconsulta produce una relacin consistente en los nombres de todas las sucursales y sus correspondientes saldos de cuenta medios. El resultado de la subconsulta recibe el nombre de media-sucursal y contiene los atributos nombre-sucursal y saldo-medio. Para ilustrar el uso de una expresin de subconsulta en la clusula from considrese la consulta Obtener el saldo medio de las cuentas de aquellas sucursales donde dicho saldo medio sea superior a 1.200 . En el Apartado se formulaba esta consulta utilizando la clusula having. Ahora se puede reescribir dicha consulta sin usar esta clusula de la siguiente forma: select nombre-sucursal, saldo-medio from (select nombre-sucursal, avg (saldo) from cuenta group by nombre-sucursal) as resultado (nombre-sucursal, saldo-medio) where saldo-medio > 1200 En esta formulacin no es necesario el uso de la clusula having puesto que la relacin temporal resultado se calcula en la clusula from, y los atributos de resultado se pueden usar directamente en la clusula where. Otro ejemplo que se desea hallar el mximo del total de saldos de todas las sucursales. La clusula having no sirve en este caso, pero se puede escribir fcilmente esta consulta usando una subconsulta en la clusula from, como se muestra a continuacin: select max(saldo-total) from (select nombre-sucursal, sum(saldo) from cuenta group by nombre-sucursal) as total-sucursal(nombre-sucursal, saldo-total) LA CLUSULA WITH La clusula with proporciona una forma de definir una vista temporal cuya definicin est disponible slo para la consulta en la que aparece esta clusula. Considrese la siguiente consulta, que selecciona cuentas con el saldo mximo; si hay muchas cuentas con el mismo saldo mximo, todas ellas se seleccionan. with saldo-mximo(valor) as select max (saldo) from cuenta select nmero-cuenta from cuenta, saldo-mximo

36

where cuenta.saldo = saldo-mximo.valor . Se podra haber escrito la consulta anterior usando una subconsulta anidada tanto en la clusula from como en la where. Sin embargo, el uso de subconsultas anidadas hace que la consulta sea ms difcil de leer y entender. La clusula with hace que la lgica de la consulta sea ms clara; tambin permite usar una definicin de vista en varios lugares de una consulta. Por ejemplo, supngase que se desea encontrar todas las sucursales donde el depsito de cuentas es mayor que la media del total de depsitos de cuentas en todas las sucursales. Se puede escribir la consulta con la clusula with como se muestra a continuacin. with total-sucursal(nombre-sucursal,valor) as select nombre-sucursal, sum(saldo) from cuenta group by nombre-sucursal with total-media-sucursal(valor) as select avg(sa valor ldo) from total-sucursal select nombre-sucursal from total-sucursal, total-media-sucursal where total-sucursal.valor > = total-mediasucursal. Valor Por supuesto, se puede crear una consulta equivalente sin la clusula with, pero sera ms complicada y difcil de entender. Como ejercicio, se puede escribir la consulta equivalente.

6.9 VISTAS.
Las vistas SQL se definen mediante la instruccin crate view. Para definir una vista hay que darle un nombre e indicar la consulta que la va a calcular. La forma de la instruccin crate view es: Creat view as <expresin de consulta> Donde <expresin de consulta> es cualquier expresin legal de consulta. El nombre de la vista se representa mediante . A modo de ejemplo, considere la vista consistente en las sucursales y sus clientes. Supngase que se desea que esta vista se denomine todos_los_clientes. Esta vista se define de la manera siguiente: Creat view todos_ los_ clientes as (select nombre_ sucursal, nombre_ cliente From impositor, cuenta Where impositor, numero_ cuenta = cuenta. Numero_ cuenta) Unin (select nombre_ sucursal, nombre_ cliente From prestatario, prstamo

37

Where prestatario. Numero_ prstamo = prstamo. Numero_ prstamo). Una vez definida la vista se puede utilizar su nombre para hacer referencia a la relacin virtual que genera. Utilizando la vista todos_ los_ clientes se puede determinar el nombre de todos los clientes de la sucursal de Navacerrada escribiendo. Select nombre_ cliente From todos_ los_ clientes Where nombre_ sucursal = Navacerrada Los nombres de las vistas pueden aparecer en cualquier lugar en el que puedan hacerlo los nombres de las relaciones, siempre y cuando no se ejecuten sobre las vistas operaciones de actualizacin. Los nombres de los atributos de las vistas se pueden especificarse de manera explicita de la manera siguiente: Creat view total_ prestamos_ sucursal(nombre_ sucursal, total_ prestamos) as Selecte nombre_ sucursal, sum (importe) From prestamo Group by nombre _ sucursal. La vista anterior da la suma del importe de todos los creditos de cada sucursal. Dado que la expresin sum (importe) no tiene nombre, el nombre del atributo se especifica de manera explicita en la definicin de la vista. De manera intuitiva, el conjunto de tuplas de la relacin de vistas es el resultado de la evaluacin de la expresin de consulta que define en ese momento la vista. Por tanto, si las relaciones de vistas se calculan y se guardan, pueden quedar desfasadas si las relaciones usadas para definirlas se modifican. Cuando se define una vista, el sistema de la base de datos guarda la definicin de la vista, en vez del resultado de la evolucin de la expresin de algebra relacional que la define. Siempre que aparece una relacin de vistas en una consulta, se sustituye por la expresin de consulta almacenada. Algunos sistemas de bases de datos permiten que se guarden las relaciones de vistas, pero se aseguran de que, si las relaciones reales utilizadas en la definicin de la vista cambian, la vista se mantenga actualizada. Estas vistas se denominan vistas materializadas. El proceso de mantener actualizada la vista se denomina mantenimiento de vistas. VISITAS DEFINIDAS EN FUNCIONE DE OTRAS. Las relaciones de vistas pueden aparecer en cualquier lugar en que puedan hacerlo los nombres de las relaciones, salvo las restricciones al uso de las vistas en expresiones de actualizacin. Por tanto, se pueden utilizar vistas en las expresiones que definen otras visitas. Por ejemplo, se puede definir la vista cliente_ Navacerrada de la manera siguiente: Crate view cliente_ Navacerrada as Select nombre_cliente From todos_ los_ clientes Where nombre_ sucursal = Navacerrada

38

Donde todos_ los_ clientes es, a su vez, una relacin de vistas. La expansion de vistas es una manera de definir el significado de las vistas no son recursivas; es decir, no se utiliza ninguna vista en su propia definicin, ni directa ni indirectamente mediante otras definiciones de vistas. Por ejemplo, si 1 se utiliza en la definicin de 2, 2 se utiliza en la definicin 3 y 3 se usa en la definicin de 1, entonces 1, 2 y 3 son recursivas. Supongase una vista 1 definida mediante una expresin que puede contener a su vez relaciones de vistas. Las relaciones de vistas representan a las expresiones que definen las vistas y, por tanto, se pueden sustituir por las expresiones que las definen. Si se modifica una expresin sustituyendo una relacin de vistas por su definicin, la expresin resultante puede seguir conteniendo otras relaciones de visitas por su definicin, la expresin resultante puede seguir conteniendo otras relaciones de vistas. Por tanto, la expansin de vistas de una expresin repite la etapa de sustitucin de la manera siguiente: Repeat Buscar todas las relaciones de vistas de Sustituir la relacin de vistas por la expresin que define Until no queden mas relaciones de vistas en Mientras las definiciones de la vistas no sean recursivas, el bucle concluir. Por tanto, una expresin que contenga relaciones de vistas pueden entenderse como la expresin resultante de la expansin de vistas de , que no contiene ninguna relacin de vistas. Como ilustracin de la expansin de vistas considrese la expresin siguiente: Select* From cliente_ navacerrada Where nombre_ cliente = Martin

El procedimiento de expansin de vistas produce inicialmente Selecet* From (select nombre_ cliente From todos_ los_ clientes Where nombre_ sucursal = Navacerrada) Where nombre_ cliente = Martin Luego produce. Select* From(select nombre_ cliente From((select nombre_ sucursal, nombre_ cliente From impositor, cuenta Where impositor. Numero_ cuenta= cuenta.numero_ cuenta) Union (select nombre_ sucursal, nombre_ cliente

39

From prestario, prestamo Where prestario.numero_ prestamo= prestamo. Numero_ prestamo)) Where nombre_ sucursal= Navacerrada) Where nombre_ cliente =Martin

6.10 MODIFICACIN DE LAS BASES DE DATOS. Un borrado se expresa de igual modo que una consulta. Se pueden borrar slo tuplas completas, es decir, no se pueden borrar valores de atributos concretos. Un borrado se expresa en SQL del modo siguiente: delete from r where P Donde P representa un predicado y r representa una relacin. La declaracin delete selecciona primero todas las tuplas t en r para las que P (t) es cierto y a continuacin las borra de r. La clusula where se puede omitir, en cuyo caso se borran todas las tuplas de r. Hay que sealar que una orden delete opera slo sobre una relacin. Si se desea borrar tuplas de varias relaciones, se deber utilizar una orden delete por cada relacin. El predicado de la clusula where puede ser tan complicado como el where de cualquier clusula select, o tan simple como una clusula where vaca. La consulta delete from prstamo Borra todas las tuplas de la relacin prstamo (los sistemas bien diseados requerirn una confirmacin del usuario antes de ejecutar una consulta tan devastadora). A continuacin se muestran una serie de ejemplos de borrados en SQL. Borrar todas las cuentas de la sucursal Navacerrada. delete from cuenta where nombre-sucursal = Navacerrada Borrar todos los prstamos en los que la cantidad est comprendida entre 1.300 y 1.500 . delete from prstamo where importe between 1300 and 1500 Borrar las cuentas de todas las sucursales de Navacerrada. delete from cuenta where nombre-sucursal in (select nombre-sucursal from sucursal where ciudad-sucursal = Navacerrada) El borrado anterior selecciona primero todas las sucursales con sede en Navacerrada y a continuacin borra todas las tuplas cuenta pertenecientes a esas sucursales. Ntese que, si bien slo se pueden borrar tuplas de una sola relacin cada vez, se puede utilizar cualquier nmero de relaciones en una expresin select-fromwhere anidada en la

40

clusula where de un delete. La orden delete puede contener un select anidado que use una relacin de la cual se van a borrar tuplas. Por ejemplo, para borrar todas las cuentas cuyos saldos sean inferiores a la media del banco se puede escribir: delete from cuenta where saldo < (select avg (saldo) from cuenta) La orden delete comprueba primero cada tupla de la relacin cuenta para comprobar si la cuenta tiene un saldo inferior a la media del banco. A continuacin se borran todas las tuplas que no cumplan la condicin anterior, es decir, las que representan una cuenta con un saldo menor que la media. INSERCIN. Para insertar datos en una relacin, o bien se especifica la tupla que se desea insertar o se formula una consulta cuyo resultado sea el conjunto de tuplas que se desean insertar. Obviamente, los valores de los atributos de la tuplas que se inserten deben pertenecer al dominio de los atributos. La instruccin insert ms sencilla corresponde a la de insercin de una tupla. Supongamos que se desea insertar en la base de datos el hecho de que hay una: Cuenta C-9732 en la sucursal Navacerrada y que dicha Cuenta tiene un saldo de 1.200 . La insercin se puede formular del modo siguiente: insert into cuenta values (C-9732, Navacerrada, 1200) En este ejemplo los valores se especifican en el mismo orden en que los atributos se listan en el esquema de relacin. Para beneficio de los usuarios, que pueden no recordar el orden de los atributos, SQL permite que los atributos se especifiquen en la clusula insert. As, el siguiente ejemplo tiene una funcin idntica al anterior : insert into cuenta (nombre-sucursal, nmero cuenta ,saldo) values (Navacerrada, C-9732, 1200) insert into cuenta (nmero-cuenta, nombre sucursal,saldo) values (C-9732, Navacerrada, 1200) Por ejemplo, si a todos los clientes tenedores de prstamos en la sucursal Navacerrada se les quisiera regalar, como gratificacin, una cuenta de ahorro con 200 por cada cuenta de prstamo que tienen, se podra escribir: insert into cuenta select nombre-sucursal, nmero-prstamo, 200 from prstamo where nombre-sucursal = Navacerrada En lugar de especificar una tupla, como se hizo en los primeros ejemplos de este apartado, se utiliza una instruccin select para especificar un conjunto de tuplas.

41

La instruccin select se evala primero, produciendo un conjunto de tuplas que a continuacin se insertan en la relacin cuenta. Cada tupla tiene un nombre-sucursal (Navacerrada), un nmero-prstamo (que sirve como nmero de cuenta para la nueva cuenta) y un saldo inicial de la cuenta (200 ). Adems es necesario aadir tuplas a la relacin impositor; para hacer esto, se escribir: insert into impositor select nombre-cliente, nmero-prstamo from prestatario, prstamo where prestatario.nmero-prstamo = prstamo.nmero-prstamo and nombre-sucursal = Navacerrada Esta consulta inserta en la relacin impositor una tupla (nombre-cliente, nmeroprstamo) por cada nombre-cliente que posea un prstamo en la sucursal Navacerrada, con nmero de prstamo nmero-prstamo. Es importante que la evaluacin de la instruccin select finalice completamente antes de llevar a cabo ninguna insercin. Si se realizase alguna insercin antes de que finalizase la evaluacin de la instruccin select, una consulta del tipo: insert into cuenta select * from cuenta La primera tupla de la relacin cuenta se insertara de nuevo en cuenta, creando as una segunda copia de la tupla. Como esta segunda copia ya sera parte de cuenta, la instruccin select podra seleccionarla, insertando as una tercera copia en la relacin cuenta. Esta tercera copia podra ser seleccionada a continuacin por el select e insertar una cuarta copia y as infinitamente. Evaluando completamente toda la instruccin select antes de realizar ninguna insercin se evitan este tipo de problemas. Por ahora, en el estudio de la instruccin insert slo se han considerado ejemplos en los que se especificaba un valor para cada atributo de las tuplas insertadas. A cada uno de los atributos restantes, se les asignar un valor nulo, que se denota por null. Como ejemplo considrese la consulta: insert into cuenta values (C-401, null, 1200) En la que se sabe que la cuenta C-401 tiene un saldo de 1.200 , pero no se conoce el nombre de la sucursal.

Considrese ahora la consulta: select nmero-cuenta from cuenta where nombre-sucursal = Navacerrada

42

Como el nombre de la sucursal de la cuenta C-401 es desconocido, no se puede determinar si es igual a Navacerrada. ACTUALIZACIONES En determinadas situaciones puede ser deseable cambiar un valor dentro de una tupla, sin cambiar todos los valores de la misma. Para este tipo de situaciones se utiliza la instruccin update. Al igual que ocurre con insert y delete, se pueden elegir las tuplas que van a ser actualizadas mediante una consulta. Por ejemplo, si hubiera que realizar el pago de intereses anuales y todos los saldos se incrementasen en un 5 %, habra que formular la siguiente actualizacin: update cuenta set saldo = saldo * 1.05 Esta actualizacin se aplica una vez a cada tupla de la relacin cuenta. Si se paga el inters slo a las cuentas con un saldo de 1.000 o superior, se puede escribir update cuenta set saldo = saldo * 1.05 where saldo >= 1000 En general, la clusula where de la instruccin update puede contener cualquier constructor legar en la clusula where de una instruccin select (incluyendo instrucciones select anidadas). Como con insert y delete, un select anidado en una instruccin update puede referenciar la relacin que se est actualizando. Por ejemplo, se puede escribir Pagar un inters del 5% a las cuentas cuyo saldo sea mayor que la media como sigue: update cuenta set saldo = saldo * 1.05 where (saldo > select avg(saldo) from cuenta) Si se supone que las cuentas con saldos superiores a 10.000 reciben un 6% de inters, mientras que las dems un 5%, se debern escribir dos instrucciones de actualizacin: update cuenta set saldo = saldo * 1.06 where saldo > 10000 update cuenta set saldo = saldo * 1.05 where saldo <= 10000 El orden en el que se ejecutan dos instrucciones de actualizacin es importante. Si se invierte el orden de las dos instrucciones anteriores, una cuenta con un saldo igual o muy poco inferior a 10.000 recibira un 11,3% de inters. SQL ofrece una constructora case, que se puede usar para formular las dos instrucciones de actualizacin anteriores en una nica instruccin de actualizacin, evitando el problema del orden de actualizacin.

43

update cuenta set saldo = case when saldo <= 10000 then saldo * 1.05 else saldo * 1.06 end La forma general de la instruccin case es la siguiente: case when pred1 then result1 when pred2 then result2 when predn then resultn else result0 end La operacin devuelve resulti, donde i es el primero de result1, result2, ,resultn que se satisface; si ninguno de ellos se satisface, la operacin devuelve result0. Las instrucciones case se pueden usar en cualquier lugar donde se espere un valor. ACTUALIZACIN DE VISTAS. La anomala de la actualizacin de vistas que se produce en SQL. Como ejemplo considrese la siguiente definicin de vista: create view prstamo-sucursal as select nombre-sucursal, nmero-prstamo from prstamo Como SQL permite que el nombre de una vista aparezca en cualquier lugar en el que pueda aparecer el nombre de una relacin, se puede formular: insert into prstamo-sucursal values (Navacerrada, P-307) SQL representa esta insercin mediante una insercin en la relacin prstamo, puesto que prstamo es la relacin real a partir de la cual se construye la vista prstamosucursal. Por lo tanto, debera especificarse un valor para el atributo importe. Este valor es un valor nulo. De este modo, la insercin anterior es equivalente a la insercin de la tupla (P-307, Navacerrada, null) En la relacin prstamo. La anomala de la actualizacin de vistas se agrava cuando una vista se define en trminos de varias relaciones. Como resultado, muchas bases de datos basadas en SQL imponen la siguiente restriccin a las modificaciones de vistas: Una modificacin de una vista es vlida slo si la vista en cuestin se define en trminos de la base de datos relacional real, esto es, del nivel lgico de la base de datos (y sin usar agregacin).

44

Bajo esta restriccin, las operaciones update, insert y delete realizadas sobre el ejemplo de la vista todos-losclientes definida anteriormente, estaran prohibidas. TRANSACCIONES Una transaccin consiste en una secuencia de instrucciones de consulta y actualizaciones. La norma SQL especifica que una transaccin comienza implcitamente cuando se ejecuta una instruccin SQL. Una de las siguientes instrucciones SQL debe finalizar la transaccin: Commit work compromete la transaccin actual; es decir, hace que los cambios realizados por la transaccin sean permanentes en la base de datos. Despus de que se comprometa la transaccin se inicia una nueva transaccin automticamente. Rollback work causa el retroceso de la transaccin actual; es decir, deshace todas las actualizaciones realizadas por las instrucciones SQL de la transaccin; as, el estado de la base de datos se restaura al que exista previo a la ejecucin de la transaccin. La palabra work es opcional en ambas instrucciones. El retroceso de transacciones es til si se detecta alguna condicin de error durante la ejecucin de una transaccin. Una vez que una transaccin haya ejecutado commit work, sus efectos no se pueden deshacer con rollback work. El sistema de bases de datos garantiza que en el caso de una cada, los efectos de la transaccin se retrocedern si no se hubo ejecutado commit work. Un error durante la ejecucin de una de las instrucciones de una transaccin resultara en deshacer los efectos de las instrucciones anteriores de la transaccin, de manera que la base de datos no se quedase en un estado parcialmente actualizado, las actualizaciones se comprometen o retroceden.

BASES DE DATOS ORIENTADAS A OBJETOS

7.1 VISION GENERAL
El primer obstculo al que se enfrentan los programadores que usan el modelo relacional de datos es el limitado sistema de tipos soportado por el modelo relacional. Los dominios de aplicacin complejos necesitan tipos de datos del mismo nivel de

45

complejidad, como las estructuras de registros anidados, los atributos multivalorados y la herencia, que los lenguajes de programacin tradicionales soportan. La notacin E-R y las notaciones E-R extendidas soportan, de hecho, estas caractersticas, pero hay que trasladarlas a tipos de datos SQL ms sencillos. Los sistemas de bases de datos relacionales basadas en objetos, es decir, los sistemas de bases de datos basados en el modelo objeto-relacin, ofrecen un medio de migracin cmodo para los usuarios de las bases de datos relacionales que deseen usar caractersticas orientadas a objetos. El segundo obstculo es la dificultad de acceso a los datos de la base de datos desde los programadores mas escritos en lenguajes de programacin como C + + o Java. La mera extensin del sistema de tipos soportado por las bases de datos no resulta suficiente para resolver completamente este problema. Las diferencias entre el sistema de tipo de las bases de datos y el de los lenguajes de programacin hace ms complicados el almacenamiento y la recuperacin de datos, y se debe minimizar. El trmino de LENGUAJES DE PROGRAMACION PERSISTENTES hace referencia a las extensiones de lenguajes de programacin existentes que aaden persistencia y otras caractersticas de las bases de datos usando el sistema de tipos nativo del lenguaje de programacin. E l termino SISTEMAS DE BASES DE DATOS ORIENTADA A OBJETOS se usa para hacer referencia a los sistemas de bases de datos que soportan el sistema de tipos orientados a objetos y permiten el acceso directo a los datos desde los lenguajes de programacin orientados a objetos usando el sistema nativo del lenguaje.

7.2 TIPOS DE DATOS COMPLEJOS

Las aplicaciones de bases de datos tradicionales consisten en tareas de procedimiento de datos, tales como la banca y la gestin de nominas. Dichas aplicaciones presentan conceptualmente tipos de datos simples. Los elementos de datos bsicos son registros bastante pequeos y cuyos campos son atmicos, es decir, no contienen estructuras adicionales y en los que se cumple la primera forma normal. Mientras que una direccin completa se puede considerar como un elemento de datos atmicos del tipo cadena de caracteres, esa forma de verlo esconde detalles como la calle, provincia, y el cdigo postal, que pueden ser interesantes para las consultas. Por otra parte, si una direccin se representa dividindola en sus componentes (calle, poblacin, provincia, cdigo postal) la escritura de las consultas ser ms complicada, pues tendran que mencionar cada campo. Una alternativa mejor es permitir tipos de datos estructurados, que admiten el tipo de direccin con los subpartes calle, poblacin, provincia, cdigo postal etc. Estos atributos resultan naturales, por ejemplo, para la representacin de nmeros de telfono, que las personas pueden tener ms de un telfono. L a alternativa de la normalizacin mediante la creacin de una nueva relacin resulta costosa y artificial para este ejemplo. Con sistemas de tipo complejos se pueden representar directamente conceptos del modelo E-R, como los atributos compuestos, los atributos multivalorados, la

46

generalizacin y la especializacin, sin necesidad de una compleja traduccin del modelo racional. Considrese por ejemplo, una aplicacin para una biblioteca y supngase que desea almacenar la informacin siguiente para cada libro: Ttulo del libro Lista de autores Editor Conjunto de palabras clave Es evidente que, si se define una relacin para esta informacin varios dominios no son atmicos. AUTORES: Cada libro puede tener una lista de autores, que se pueden representar como array. Pese a todo, puede que se desee averiguar todos los libros de los que es autor Santos. Por tanto, lo que interesa es una subparte del elemento domino de autores. PALABRAS CLAVE: Si se almacena un conjunto de palabras clave para cada libro, se espera poder recuperar todos los libros cuyas palabras clave incluyan uno o ms trminos dados. Por tanto, se considera el dominio del conjunto de palabras clave como no atmico. EDITOR: A diferencia de palabras clave y autores, editor no tiene un dominio que se evale en forma de conjunto. No obstante, se puede considerar que el editor consta de subcampos nombre y sucursal. Este punto de vista hace que el dominio de editor no sea atmico. Por otro lado, en otras situaciones puede resultar ms conveniente usar una representacin en la primera forma normal en lugar de conjuntos. Por ejemplo, considrese la relacin impositor del ejemplo bancario. La relacin es de varios a varios entre cuentas y clientes. Tericamente, se podra almacenar un conjunto de cuentas con cada cliente, o un conjunto de clientes con cada cuenta, o ambas cosas.

7.3 TIPOS ESTRUCCTURADOS Y HERENCIA EN SQL

SQL: Aadi un sistema de tipos extenso a SQL, lo que permite los tipos estructurados y la herencia de tipos. Esta suposicin no se cumple en el mundo real. Los libros se suelen identificar por un numero de IBSN de diez cifras que identifica de manera univoca cada libro publicado. editor (nombre, sucursal) Compiladores [Gmez, Santos] (McGraw-Hill, Redes [Santos, Escudero] Nueva York)(Oxford, Londres) VERSIN EN LA 4FN DE LA RELACIN LIBROS Titulo Autor Posicin titulo array_autores conjunto_palabras_claves {anlisis sintctico, anlisis}{internet, Web}

47

Gmez Compiladores Santos Compiladores Santos Redes Escudero Redes

1 2 1 2

Titulo Compiladores Compiladores Redes Redes

Palabra_clave Anlisis sintctico Anlisis Internet Web

AUTORES Titulo Compiladores Redes Nombre_editor McGraw-Hill Oxford LIBROS4

PALABRAS_CLAVE Sucursal_editor Nueva York Londres

TIPOS ESTRUCTURADOS Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el atributo compuesto nombre con los atributos componentes nombredepila y apellidos. create type Nombre as (nombredepila varchar(20), apellidos varchar(20)) final De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto direccin: Create type Direccion as (calle varchar(20), Ciudad varchar(20), Codigopostal varchar(9)) Not final En SQL estos tipos se denominan tipos definidos por el usuario. Las especificaciones FINAL y NOT FINAL estn relacionadas con la subtipificacion. Ahora se pueden usar esos tipos para crear atributos compuestos en las relaciones, con solo declarar que un atributo es de uno de estos tipos. Por ejemplo, se puede crear la tabla cliente de la manera siguiente: Create table cliente ( Nombre Nombre, Direccin Direccin, fechaDeNacimiento date) Se puede tener acceso a los componentes de los atributos compuestos usando la notacin punto; por ejemplo, nombre, nombredepila devuelve el componente nombre de pila del atributo nombre. El acceso al atributo nombre devolvera un valor del tipo estructurado Nombre. ejemplo, se puede definir el tipo tipocliente y crear la tabla cliente de manera siguiente:

48

Create table cliente ( Nombre tow (nombredepila varchar(20). apellidos varchar(20)), direccin row (calle varchar(20), ciudad varchar(20), cdigopostal varchar(9)), fechaDeNacimiento date) Esta definicin es equivalente a la anterior definicin de la tabla, salvo en que los atributos nombre y direccin tienen tipos sin nombre y las filas de la tabla tambin tienen un tipo sin nombre. La consulta siguientr ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente. Select nombre,apelldos,direccion,ciudad From cliente Sobre los tipos estructurados se pueden definir mtodos. Los mtodos se declaran como parte de la definicin de los tipos de los tipos estructurados: create type tipocliente as ( nombre Nombre, direccion Direccion, not final method edadAFecha(aFecha date) returns interval year El cuerpo del mtodo se crea por separado. create instance method edadAFecha (aFecha date) returns interval year for TipoCliente begin return aFecha- self.fechaDeNacimiento; end Tngase en cuenta que la clausula for indica el tipo al que se aplica el mtodo, mientras que la palabra clave instance indica que el mtodo se ejecuta sobre un ejemplar del tipo cliente. La variable self hace referencia al ejemplar de cliente sobre el que se invoca el mtodo. Los mtodos se pueden invocar sobre los ejemplares de los tipos. Si se hubiera creado la tabla cliente del tipo Tipocliente, se podra invocar el mtodo edadAFecha () para averiguar la edad del cliente. Select nombre, apellidos, edadAFecha(current_date) From cliente Las funciones con el mismo nombre que un tipo estructurado son funciones constructoras de ese tipo estructurado. Por ejemplo, se puede declarar una funcin constructora para el tipo Nombre de esta manera:

49

create function Nombre (nombredepila vachar(20)) returns Nombre begin set self.nombredepila=nombrede pila); set self.apellidos=apellidos; end Se puede usar new Nombre (Martin, Gmez) para crear un valor del tipo Nombre. Se puede crear un valor de fila haciendo una relacin de sus atributos entre parntesis. Por ejemplo si se declara el atributo NOMBRE como tipo de fla con los componentes nombredepila y apellidos, se pude crear para el este valor (Ted.Codd) sin necesidad de funcin constructora. De manera predeterminada, cada tipo estructurado tiene una funcin constructora sin argumentos, que configura los atributos con sus valores predeterminados. Cualquier otra funcin constructora hay que crearla de manera explcita. La instruccin siguiente ilustra la manera de crear una nueva tupla de la relacin cliente. Se da por supuesto que se ha definido una funcin constructora para direccin, igual que la funcin constructora que se defini para Nombre. insert into Cliente values (new Nombre(Martin, Gomez), New Direccion(Calle Mayor,20,Madrid;28045), Date22-8-1960)

7.4 HERENCIA DE TABLAS

Las subtablas de SQL se corresponden con el concepto de especializacin/generalizacin de E-R. Por ejemplo, supngase que se define la tabla de personas de la manera siguiente: create table personas of Persona Se pueden definir las tablas estudiantes y profesores como subtablas de personas, de la manera siguiente: create table estudiantes of Estudiante under personas create table profesores of Profesor under personas Adems cuando se declaran estudiantes o en profesores como subtablas de personas, todas las tuplas presentes en estudiantes o en profesores pasan a estar tambin presentes de manera implcita en personas. Por tanto, si una consulta usa la tabla personas, no solo encuentra tuplas directamente insertadas en esa tabla, sino tambin tuplas insertadas en subtablas, es decir, estudiantes y profesores..

50

SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas only personas en lugar de personas. La palabra clave only tambin puede usarse en las sentencias delete y update. Sin la palabra clave only, la instruccin delete aplicada a una supertabla, como personas, tambin borra tuplas que se insertaron originalmente en las subtablas (como estudiantes); por ejemplo la instruccin Delete from personas where P, borrara todas las tuplas de la tabla personas, as como de sus subtablas estudiantes y profesores, que satisfagan P. Si se aade la palabra clase only a la instruccin anterior, las tuplas que se insertaron en las subtablas no se ven afectadas, aunque satisfagan las condiciones de la clausula where. Tericamente, la herencia mltiple es posible con las tablas, igual que con los tipos. Por ejemplo, se puede crear una tabla del tipo ProfesorAyudante: create table profesores_ayudantes of Profesor Ayudante under estudiantes, profesores Como consecuencia de la declaracin, todas las tuplas presentes en la tabla profesores_ayudantes tambin se hallan presentes de manera implcita en las tablas profesores y estudiantes y, a su vez, en la tabla personas. Los requisitos de consistencia de las subtablas son: 1. Cada tupla de la supertabla puede corresponderse, como mximo, con una tupla de cada una de sus subtablas inmediatas. SQL posee una restriccin adicional que hace que todas las tuplas que se corresponden entre s deben proceder de una tupla (insertada en una tabla). Por ejemplo, sin la primera condicin no se podran tener dos tuplas de estudiantes (o de profesores) que correspondieran a la misma persona. La segunda condicin excluye que haya una tupla de personas correspondiente a una tupla de estudiantes y a una tupla de profesores, a una tupla de profesores, a menos que todas esas tuplas se hallen presentes de manera implcita porque se haya insertado una tupla en la tabla profesores_ayudantes, que es la subtabla tanto de profesores como de estudiantes. Dado que SQL no soporta la herencia mltiple, la segunda condicin impide realmente que ninguna persona sea a la vez profesor y estudiante. Aunque se soportara la herencia mltiple, surgira el mismo problema si tuviera ausente la subtabla profesores_ayudantes. Evidentemente, resultara til modelar una situacin en la que alguien pudiera ser a la vez estudiante, aunque no se hallara presente la subtabla profesores_ayudantes. Por tanto, puede resultar til eliminar la segunda restriccin de consistencia. Hacerlo permitira que cada objeto tuviera varios tipos, sin necesidad de que tuviera un tipo ms concreto.

7.5 TIPOS DE ARREGLO MULTICONJUNTO EN SQL

Los multiconjuntos son como los conjuntos, salvo que los conjuntos permiten que cada elemento aparezca, como mucho, una vez. Suponga que se desea registrar informacin sobre libros, incluido un conjunto de palabras clave para cada libro. Suponga tambin que se deseara almacenar el nombre de los

51

autores de un libro en forma array; a diferencia de los elementos de los multiconjuntos, los elementos de los arrays estn ordenados, de modo que se puede distinguir el primer autor del segundo etc. El ejemplo siguiente ilustra la manera en que se pueden definir en SQL estos atributos valorados como arrays y como multiconjuntos. create type Editor as (nombre varchar(20), Sucursal varcha(20)) create type Libro as (titulo varchar(20), array_autores varchar(20) array [10], fecha_publicacion date, editor Editor, conjunto_palabras_clave varchar(20)multiset) create table libros of Libro La primera instruccin define el tipo denominado Editor, que tiene dos componentes: nombre y sucursal. La segunda instruccin define el tipo estructurado Libro, que contiene un titulo, un array_autores, que es un array de hasta diez nombres de autor, una fecha de publicacin, un editor (del tipo Editor), y un multiconjuntos de palabras clave. Finalmente, se crea la tabla libros, que contiene las tuplas del tipo Libro. Tngase en cuenta que se ha usado un array, en lugar de un multiconjuntos, para almacenar el nombre de los autores, ya que el orden de los autores suele tener cierta importancia, mientras que se considera que el orden de las palabras asociadas con el libro no es significativo. En general, los atributos multivalorados de los esquemas E-R se pueden asignar en SQL atributos valorados como multiconjuntos; si el orden es importante, se pueden usar array de SQL en lugar de los multiconjuntos. CREACION Y ACCESO A LOS VALORES DE LOS CONJUNTOS En SQL: 1999 se puede crear un array de los valores de esta manera: array[Silberschatz,Korth,Sudarshan] De manera parecida, se puede crear un multiconjunto de palabras clave de la manera siguiente: multiset[computadora,base de datos,SQL] Por tanto, se puede crear una tupla del tipo definido por la relacin libros como: (compiladores,array[Gomez,Santos],new Editor(McGraw-Hill,Nueva York), multiset[nalsis sintactico,nalisis]) En este ejemplo se ha creado un valor para el atributo Editor mediante la invocacin a una funcin constructora para Editar con los argumentos correspondientes. Tngase en cuenta que esta constructora para Editor se debe crear de manera explcita y no se halla presente de manera predeterminada; se puede declarar como la constructora para Nombre, si desea insertar la tupla anterior en la relacin libros, se puede ejecutar la instruccin

52

insert into libros values (compiladores,array[Gomez,Santos], new Editor(McGraw-Hill,Nueva York), multiset[anlisis sintctico,nalisis]) Se puede tener acceso a los elementos del array o actualizarlos especificando el ndice del array, por ejemplo, array_autores. CONSULTA DE LOS ATRIBUTOS VALORADOS COMO CONJUNTOS Las expresiones que se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre de una relacin, como las clausulas from, se usara la tabla libros. Si se desea averiguar todos los libros que tienen las palabras base de datos entre sus palabras clave se puede usar la consulta siguiente: select titulo from libros were base de datosin (unnest(conjunto_palabras_clave) Obsrvese que se ha usado unnest (conjunto_palabras_clave) en una posicin en la que SQL sin las relaciones anidadas habra exigido una superexpresion select-from-where. Si se sabe que un libro concreto tiene tres autores, se puede escribir: select array_autores[1],array_autores[2],array-autores[3] from libros where titulo = Fundamentos de bases de datos Ahora supngase que se desea unja relacin que contenga parejas de la forma titulo, nombre_autor para cada libro y para cada uno de sus autores. Se puede usar esta consulta: Select L. titulo, A.autores from libros as L, unnest(L.array_autores) as A(autores) Dado que el atributo array_autores de libros es un campo que se valora como conjunto unnest (L.array_autores) puede usarse en una clausula from en la que se espere una relacin. Tngase en cuenta que la variable tupla B es visible para esta expresin, ya que se ha definido anteriormente en la clausula from. Al desanidar un array la consulta anterior pierde informacin sobre el orden de los elementos del array. Se puede usar la clausula unnest with ordinalty para obtener esta informacin.

7.6 IDENTIDAD DE LOS OBJETOS Y TIPOS DE REFRENCIA EN SQL

Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo persona, y la tabla departamentos del tipo Departamento, de la manera siguiente: create type Departamento (

53

nombre varchar(20), director ref(persona) scope personas ) Create table departamentos of departamento En este caso, la referencia esta restringida a las tuplas de la tabla personas. La restriccin del mbito (scope) de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como claves externas. Se puede omitir la declaracin scope personas de la declaracin de tipos y hacer en su lugar, un aadido a la instruccin create table: create table departamentos of Departamento (director with options scope personas). La tabla a la que se hace referencia debe tener un atributo que guarde el identificador de cada tupla. Ese atributo, denominado atributo autorreferencial (self-referential attribute), se declara aadiendo una clausula re fis a la instruccin create table: create table personas of Persona ref is id-personal system generated En este caso, id_personal es el nombre de un atributo, no de una palabra clave, y la instruccin create table especifica que la base de datos genera de manera automtica el identificador. Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente. insert into departamentos values (CS,null) update departamentos set director= (select p.id_personal from personal as p where nombre= Martin) where nombre= CS El tipo del atributo autorrefencial debe especificarse como parte de la definicin de tipos de la tabla a la que se hace referencia, y la definicin de la tabla debe especificar que la referencia esta generada por el usuario (user generated)

7.7 IMPLEMENTACION DE LAS CARACTERISTICAS O-R

Los sistemas de bases de datos relacionales orientadas a objetos son bsicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Por ejemplo, los atributos multivalorados del modelo E-R se corresponden con los atributos valorados como multiconjuntos del modelo relacional orientado a objetos. Los atributos compuestos se corresponden grosso modo con los tipos estructurados.

54

Las jerarquas ES del modelo E-R se corresponden con la herencia de tablas del modelo racional orientado a objetos. Las subtablas se pueden almacenar de manera eficiente, sin rplica de todos los campos heredados, de una de estas maneras: Cada tabla almacena la clave primaria (que puede haber heredado de una tabla madre) y los atributos que se definen de localmente. No hace falta almacenar los atributos heredados (que no sean clave primaria), se pueden obtener mediante una reunin con la supertabla, de acuerdo con la clave primaria. Cada tabla almacena todos los atributos heredados y definidos localmente. Cuando se inserta una tupla, solo se almacena en la tabla en la que se inserta, y su presencia se infiere en cada una de las supertabla. El acceso a todos los atributos de las tuplas es ms rpido, ya que no hace falta ninguna reunin. No obstante, en caso de que el sistema de tipos permita que cada entidad se represente en dos subtablas sin estar presente en una subtabla comn a ambas, esta representacin puede dar lugar a la rplica de informacin.

55