Base de Datos Modelado

Las bases de datos relacionales son el tipo de bases de datos actualmente ms difundido.
Los motivos de este xito son fundamentalmente dos: 1. ofrecen sistemas simples y eficaces para representar y manipular los datos 2. se basan en un modelo, el relacional, con slidas bases tericas El modelo relacional fue propuesto originariamente por E.F. Codd en un ya famoso artculo de 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido en los aos 80 en el ms usado para la produccin de DBMS. La estructura fundamental del modelo relacional es precisamente esa, "relacin", es decir una tabla bidimensional constituida por lneas (tuple) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la entidad encontrar sitio en una tupla de la relacin, mientras que los atributos de la relacin representarn las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, se podr definir una relacin llamada "Personas", cuyos atributos describen las caractersticas de las personas(Figura 2). Cada tupla de la relacin "Personas" representar una persona concreta.
En realidad, siendo rigurosos, una relacin es slo la definicin de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se puebla con las tuplas, se habla de "instancia de relacin". Por eso, la anterior Figura 2 representa una instancia de la relacin persona. Una representacin de la definiticn de esa relacin podra ser la siguiente: Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil) A continuacin, se indicarn ambas (relacin e instancia de relacin) con el trmino "relacin", a no ser que no quede claro por el contexto a qu acepcin se refiere. Las tuplas en una relacin son un conjunto en el sentido matemtico del trmino, es decir una coleccin no ordenada de elementos diferentes. Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de atributos que permiten identificar unvocamente una tupla en una relacin. Naturalmente, en una relacin puede haber ms combinaciones de atributos que permitan identificar unvocamente una tupla ("llaves candidatas"), pero entre stas se elegir una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitiran identificar una tupla concreta en una relacin. Esta propiedad de las relaciones y de sus llaves primarias est bajo el nombre de
integridad de las entidades (entity integrity). A menudo, para obtener una llave primaria "econmica", es decir compuesta de pocos atributos fcilmente manipulables, se introducen uno o ms atributos ficticios, con cdigos identificativos unvocos para cada tupla de la relacin. Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El dominio indica qu valores pueden ser asumidos por una columna de la relacin. A menudo un dominio se define a travs de la declaracin de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es posible definir dominios ms complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacion "Personas" podemos definir un dominio por el cual los nicos valores vlidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren vlidas slo las fechas de nacimiento despus del uno de enero de 1960, si en nuestra base de datos no est previsto que haya personas con fecha de nacimiento anterior a esa. El DBMS se ocupar de controlar que en los atributos de las relaciones se incluyan slo los valores permitidos por sus dominios. Caracterstica fundamental de los dominios de una base de datos relacional es que sean "atmicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios ms simples. Ms formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una caracterstica de las personas en nuestra base de datos fuese la de tener uno o ms hijos, no sera posible escribir la relacin Personas de la siguiente manera: Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos) En efecto, el atributo hijos es un atributo no-atmico, bien porque una persona puede tener ms de un hijo o porque cada hijo tendr diferentes caractersticas que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones: Personas (*nmero_persona, nombre, apellido, fecha_nacimiento, sexo, estado_civil) Hijos(*nmero_persona, *nombre_apellido, edad, sexo) En las relaciones precedentes, los asteriscos (*) indican los atributos que componen sus llaves primarias. Ntese la introduccin en la relacin Personas del atributo nmero_persona, a travs del cual se asigna a cada persona un identificativo numrico unvoco que se usa como llave primaria. Estas relaciones contienen slo atributos atmicos. Si una persona tiene ms de un hijo, stos se representarn en tuplas diferentes de la relacin Hijos. Las diferentes caractersticas de los hijos las representan los atributos de la relacin Hijos. La unin entre las dos relaciones est constituida por los atributos nmero_persona que aparecen en ambas relaciones y que permiten que se asigne cada tupla de la relacin hijos a una tupla concreta de la relacin Personas. Ms formalmente se dice que el atributo nmero_persona de la relacin Hijos es una llave externa (foreign key) hacia la relacin Personas. Una llave externa es una combinacin de atributos de una relacin que son, a su vez, una llave primaria para otra relacin.
Una caracterstica fundamental de los valores presentes en una llave externa es que, a no ser que no sean null, tienen que corresponder a valores existentes en la llave primaria de la relacin a la que se refieren. En nuestro ejemplo, esto significa que no puede existir en la relacin Hijos una tupla con un valor del atributo nmero_persona sin que tambin en la relacin Personas exista una tupla con el mismo valor para su llave primaria. Esta propiedad va bajo el nombre de integridad referencial (referential integrity) Una de las grandes ventajas del modelo relacional es que define tambin un lgebra, llamada "lgebra relacional". Todas las manipulaciones posibles sobre las relaciones se obtienen gracias a la combinacin de tan slo cinco operadores: RESTRICT, PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido tambin tres operadores adicionales que de todos modos se pueden obtener aplicando los cinco fundamentales: JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben como argumento una relacin o un conjunto de relaciones y restituyen una nica relacin como resultado. Veamos brevemente estos ocho operadores: RESTRICT: restituye una relacin que contiene un subconjunto de las tuplas de la relacin a la que se aplica. Los atributos se quedan como estaban. PROJECT: restituye una relacin con un subconjunto de los atributos de la relacin a la que viene aplicado. Las tuplas de la relacin resultado se componen de las tuplas de la relacion original, de manera que siguen siendo un conjunto en sentido matemtico. TIME: se aplica a dos relaciones y efecta el producto cartesiano de las tuplas. Cada tupla de la primera relacin est concatenada con cada tupla de la segunda. JOIN: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un conjunto de sus atributos. UNION: aplicando este operador a dos relaciones compatibles, se obtiene una que contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el mismo nmero de atributos y los atributos correspondientes en las dos relaciones tienen el mismo dominio. MINUS: aplicado a dos relaciones compatibles restituye una tercera que contiene las tuplas que se encuentran slo en la primera relacin. INTERSECT: aplicado a dos relaciones compatibles restituye una relacin que contiene las tuplas que existen en ambas. DIVIDE: aplicado a dos relaciones que tengan atributos comunes, restituye una tercera que contiene todas las tuplas de la primera relacin que se puede hacer que correspondan con todos los valores de la segunda relacin.
En las siguientes tablas, a ttulo de ejemplo, se representan los resultados de la aplicacin de algunos operadores relacionales a las relaciones Personas e Hijos. Como nombres para las relaciones resultado se han utilizado las expresiones que las producen. Personas
nmero_persona 2 1 3 nombre Mario Giuseppe apellido fecha_nacimiento sexo stado_civil Rossi Russo 29/03/1965 15/11/1972 13/06/1970 M M F Casado Soltero Soltera
Alessandra Mondella
Hijos
nmero_persona nombre_apellido edad sexo
2
2
Maria Rossi Gianni Rossi
3 5
F M
RESTRICT (Personas) sesso='M'

nmero_persona nombre apellido fecha_nacimiento sexo estado_civil 2 1 Mario Rossi 29/03/1965 15/11/1972 M M Casado Soltero Giuseppe Russo
PROJECT sexo (Personas) sexo M F RESTRICT (Personas) sexo='M'

n. nombre apellido nacimiento sexo stado_civil apellido 29/03/1965 M M Csado Casado nombre Maria Rossi Gianni Rossi edad sexo 3 5 F M Mario Rossi
Mario Rossi Apellido 29/03/1965
Las bases de datos relacionales efectan todas las operaciones en las tablas usando el lgebra relacional, aunque normalmente no le permiten al usuario usarla. El usuario interacciona con la base de datos a travs de una interfaz diferente el lenguaje SQL, un lenguaje declarativo que permite escribir conjuntos de datos. Las instrucciones SQL vienen descompuestas por el DBMS en una serie
de operaciones relacionales.
3. Modelo relacional
3.1 Introduccin
En el captulo anterior se mencionaron 3 tipos de modelado: conceptual, lgico y fsico. El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la informacin utilizada en algun problema o negocio. En este captulo nos concentraremos en desarrollar un buen modelo "lgico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podr realizar el modelado fsico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un fsico.
3.2 Por qu "modelo relacional" ?

Puede resultar confuso el concepto de modelo entidad-relacin vs modelo relacional, quizs porque ambos comparten casi las mismas palabras. Como se mencion en la seccin anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se mencionar posteriormente consiste de un conjunto de "tablas" que representan "relaciones", relaciones entre los datos. Estas tablas, pueden ser construdas de diversas maneras:
Creando un conjunto de tablas iniciales y aplicar operaciones de normalizacin hasta conseguir el esquema ms ptimo. Las tcnicas de nomalizacin se explican ms adelante en este captulo. Convertir el diagrama e-r a tablas y posteriormente aplicar tambin operaciones de normalizacin hasta conseguir el esquema ptimo.
La primer tcnica fue de las primeras en existir y, como es de suponerse, la segunda al ser ms reciente es mucho ms conveniente en varios aspectos:

El partir de un diagrama visual es muy til para apreciar los detalles, de ah que se llame modelo conceptual. El crear las tablas iniciales es mucho ms simple a travs de las reglas de conversin. Se podra pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo e-r es que la "normalizacin" es mnima por lo general. Lo anterior tiene otra ventaja, an cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer tcnica no es as.
3.3 Conceptos bsicos

3.3.1 Tablas El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relacin.
ttulo Star Wars Mighty Ducks Wayne's World ao duracin 1977 1991 1992 124 104 95 tipo color color color
Relacin Pelculas
La relacin Pelculas tiene la intencin de manejar la informacin de las instancias en la entidad Pelculas, cada rengln corresponde a una entidad pelcula y cada columna corresponde a uno de los atributos de la entidad. Sin embargo las relaciones pueden representar ms que entidades, como se explicar ms adelante. 3.3.2 Atributos Los atributos son las columnas de un relacin y describen caractersticas particulares de ella. 3.3.3 Esquemas Es el nombre que se le da a una relacin y el conjunto de atributos en ella. Pelculas (ttulo, ao, duracin, tipo) En un modelo relacin, un diseo consiste de uno o ms esquemas, a este conjunto se le conoce como "esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de datos" (database schema) 3.3.4 Tuplas Cada uno de los renglones en una relacin conteniendo valores para cada uno de los atributos. (Star Wars, 1977, 124, color) 3.3.5 Dominios Se debe considerar que cada atributo (columna) debe ser atmico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos. 3.3.6 Representaciones equivalentes de una relacin Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.
As mismo el orden de los atributos tampoco es relevante

ao 1991 1992 1977 ttulo Mighty Ducks Wayne's World Star Wars tipo color color color duracin 104 95 124
Otra representacin de la relacin Pelculas
3.4 Conversin del modelo e-r a un esquema de base de datos (Conversin a tablas)
3.4.1 Introduccin El modelo es una representacin visual que grficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organizacin. Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos. 3.4.2 Conversin a tablas desde un modelo con relaciones (11,1-m,m-m) Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.
modelo e-r conversin a tablas
una tabla por cada conjunto de entidades o nombre de tabla = nombre de conjunto de entidades
una tabla por cada conjunto de relaciones m-m o nombre de tabla = nombre de conjunto de relaciones definicin de columnas para cada tabla o conjuntos fuertes de entidades columnas = nombre de atributos o conjuntos dbiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) o conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) o conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) o conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R)
El diagrama anterior se convertira al siguiente esquema: Debil atribs_Debil A LLP_A B1 LLP_B1 atribs_B1 atribs_A LLP_A atribs_rel_0
B2 LLP_B2 atribs_B2 LLP_A attribs_rel_2 B3 LLP_B3 atribs_B3 LLP_A atribs_rel_3 A_B1 LLP_A donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X) LLP_B1 atribs_rel_1
Ejemplo:
Para el ejemplo de la figura tendramos el esquema:
escuela id url nombre
departamento clave curso clave seccion nombre clave_depto url nombre id_escuela
profesor id nombre extension
estudiante id nombre carrera
profesor_curso id_prof clave_curso seccion_curso
estudiante_curso id_estud clave_curso seccion_curso
3.4.3 Conversin a tablas desde un modelo con generalizacin

modelo e-r de generalizacin a tablas dos posibilidades: 1.
o
crear una tabla para el conjunto de entidades A de mayor nivel columnas (A) = atributos(A)
para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columns (B) = atributos (B) U llave_primaria (A)
2.
o
si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A)
La generalizacin se convertira al siguiente esquema: 1)
A LLP_A B1 atribs_B1 B2 atribs_B2 B3 atribs_B3 donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X) LLP_A LLP_A LLP_A atribs_A
2) B1 atribs_B1 B2 atribs_B2 B3 atribs_B3 donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X) LLP_A atribs_A LLP_A atribs_A LLP_A atribs_A
Es importante mencionar que a pesar de que existen 2 mtodos para convertir una generalizacin a tablas, no hay una regla exacta de cual usar en determinado caso. A continuacin se mencionan algunos consejos tiles para la determinacin de cual mtodo emplear: 1. Si la entidad de nivel superior est relacionada con otra(s) entidades puede sugerirse emplear el mtodo (1) ya que de esa manera la tabla (A) ser la nica involucrada en la relacin, de otra forma se tendran tres tablas (B1,B2 y B3) formando parte de la relacin 2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalizacin disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizs sea recomendable el mtodo (1), en otro caso se podra pensar en el mtodo (2). 3. Tambin es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto tambin determina en muchos casos el mtodo a emplear. 3.4.4 Descubrimiento de llaves en las relaciones Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera: 1) Cada tabla que provenga de una entidad contiene por si misma una llave 2) Para las tablas resultado de una relacin se toman las llaves primarias de ambas entidades y stas conforman la nueva llave primaria, excepto en un caso como el que sigue:
Podemos observar que existe una relacin m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas series tendrn a los mismos actores. La tabla que se creara sera: actor_serie id_actor Joaqun Pardav Evita Muoz (Chachita) Joaqun Pardav Evita Muoz (Chachita) id_serie Gnesis Qu bonita familia Gnesis Hermelinda linda id_personaje Abel hermano bueno Dulce abuelita Can hermano malo Bruja Hermelinda
si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinacin no identifica de manera nica a la tupla, como es el caso de "Joaqun Pardav, Gnesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Can hermano malo". La relacin es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo ms recomendable sera emplear los tres atributos de la relacin "id_actor, id_serie, id_personaje"
3.5 Normalizacin
Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son: 1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la relacin siguiente, length y filmType. 2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Si en la relacin encontramos que el length de StarWars es 125 podramos cambiarlo nicamente para la primer tupla y olvidar actualizar las dems. 3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio Estevez, perdemos tambin la tupla de la pelcula MightyDucks.
year length filmType studioName starName Carrie Star Wars 1977 124 color Fox Fisher Star Wars 1977 124 color Fox Mark Hamill Star Wars 1977 124 color Fox Harrison title
Mighty 1991 Ducks Wayne's 1992 World Wayne's 1992 World
104 95 95
color color color
Disney Paramount
Ford Emilio Estevez Dana Carvey
Paramount Mike Meyers
3.5.1 Dependencias funcionales (FD) 3.5.1.1 Definicin 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. Una dependencia funcional en una relacin R es una enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen B y se dice que "A1, A2,....An determina funcionalmente a B".
los mismos valores para cada atributo), entonces deben concordar tambin con otro atributo B" . Esta FD se escribira como A1,A2,....An -->
Por otro lado, si un conjunto de atributos A1,A2...An determina funcionalmente a ms de un atributo, A1, A2, ... An ---> B1 A1, A2, ... An ---> B2 A1, A2, ... An ---> Bm entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm Movies(title, year, length, filmType, studioName, starName)
title year length filmType studioName starName color Fox Carrie Fisher
Star Wars 1977 124
Star Wars 1977 124 Star Wars 1977 124 Mighty Ducks Wayne's World Wayne's World ... 1991 104 1992 95 1992 95
color color color color color
Fox Fox Disney Paramount Paramount
Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers
title, year --> length title, year --> filmType title, year --> studioName title, year -/-> starName podemos entonces afirmar que: title, year --> length, filmType, studioName Quizs las dependencias funcionales ms evidentes sean las llaves. Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si: 1. Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin. 2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An }) La definicin anterior de llave es similar a la que se mencion anteriormente de superllave, sin embargo las superllaves no son llaves "mnimas", recordemos que una llave primaria se escoge de entre el conjunto de superllaves mnimas. Es importante hacer notar que una llave mnima no se refiere al nmero de atributos includos, se puede tener una llave mnima ABC y otra DE donde ambas son mnimas an cuando una de ellas sea todava de menor tamao que la otra.
Al conjunto de dependencia funcionales de una relacin R se le denominar F.
3.5.1.2 Axiomas de Armstrong:
Reflexividad: sea y entonces Aumentacin: si entonces --> Transitividad: si
un conjunto de atributos --> * --> y es un conjunto de atributos --> y --> entonces -->
*Nota:
De manera general una dependencia funcional de la forma > se considera "dependencia funcional trivial" si
--
Si al menos algn elemento de no pertenece a se considera una dependencia no trivial. Si ningn elemento de pertenece a entonces se considera una dependencia completamente no trivial
3.5.1.3 Reglas adicionales

Unin: si --> y --> entonces --> Decomposicin: si --> entonces --> y --> Pseudotransitividad: si --> y --> entonces >
--
3.5.1.4 Cerradura de un conjunto de atributos Para un esquema R y un conjunto de atributos > R entonces es superllave para determinar lo anterior se puede encontrar que dependen funcionalmente de , si --
+, todos los atributos
teniendo R(A,B,C,D,E) si A+=(A,B,C,D,E), entonces A--> R entonces A es superllave La cerradura se puede calcular siguiendo el siguiente algoritmo: entrada: salida: +
result= while changes to result do for each ( do begin if result then result=result end end result --> (reflexividad) --> , (transitividad) --> --> F ) = =result
,F
teniendo R (A,B,C,D,E,F) y F las dependencias: AB-->C, BC-->AD, D-->E, CF-->B. Comprobar que {A,B}+ ={A,B,C,D,E}
Si {A,B}+ = {A,B,C,D,E,F} entonces podramos afirmar que AB es superllave, pero para ello sera necesaria alguna dependencia adicional ej. AB --> CF El calcular la cerradura es empleado para:

Verificar si es una superllave, calculando + y revisando si + contiene a todos los atributos de la relacin R. Verificar una dependencia funcional --> (es decir, si pertenece a F+) checando si +.
Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relacin R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional --> S.
3.5.2 Primera forma normal Una tabla se encuentra en 1a NF, si todos sus atributos son atmicos (indivisibles) El ejemplo clsico:
nombre direccin telfono
En 1a. NF
nombre apellido_paterno apellido_materno direccin telfono
3.5.3 Segunda forma normal Una tabla se encuentra en 2a NF, si est en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave. Si tenemos la tabla: calificaciones_cursos
id_estudiante depto clave_curso descripcin calificacin
NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin
Analizando todas las dependencias funcionales: { id,clave,depto} --> descripcin {clave,depto} --> descripcin { id,clave,depto} --> calificacin Para realizar la normalizacin (2NF) la relacin se descompondra en:
curso depto estud_curso id depto clave_curso calificacin clave_curso descripcin
La descomposicin se basa bsicamente en:

La intuicin Las dependencias funcionales
Es importante que al descomponer una relacin exista:

Descomposicin sin prdida Preservacin de dependencias funcionales
3.5.4 Descomposicin sin prdida
Al descomponer una relacin R en varias relaciones R1 y R2 se debe verificar que no haya prdidas, es decir, que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas. Decimos entonces que para una descomposicin en R1 y R2 no hay prdida si:
{ R1
R2 --> R1 }
F+
o bien si { R1 R2 --> R2 } F+
Para el ejemplo anterior la relacin

id_estudiante depto clave_curso descripcin calificacin
F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } tiene F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y dicha relacin se descompone en:
depto clave_curso descripcin
id_estudiante
depto
clave_curso
calificacin
donde R1 R2 = depto,clave_curso donde depto,clave_curso ->descripcin y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }
3.5.5 Preservacin de dependencias Al descomponer una relacin R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las dependencias funcionales iniciales. De esta manera se garantiza que una actualizacin no provoque una relacin invlida, verificando las FDs o bien a travs de
combinaciones de relaciones(productos o joins) aunque esto ltimo no es muy eficiente. Para ello se analizan todas la dependencias funcionales Fi para cada Ri que debern ser un subconjunto de F+ De manera que F' = F1 F2 ...Fn
y la preservacin se verifica si F'+= F+ para el ejemplo anterior teniendo: F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } F1= depto,clave_curso--> descripcin F2= id_estudiante,depto,clave_curso --> calificacin F' = F1 F2
depto,clave_curso--> descripcin id_estudiante,depto,clave_curso --> calificacin F'+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y como F'+= F+ entonces si hay preservacin de dependencias.
3.5.6 Forma normal de Boyce-Codd (BCNF) 3.5.6.1 Caractersticas Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:
X --> A es una dependencia funcional trivial
X es una super llave
BCNF no necesariamente preserva las dependencias funcionales F'+ != F+ 3.5.6.2 Algoritmo general de descomposicin tratando de alcanzar BCNF
result= {R} done=false calcular F+ while (! done) do if(existe un esquema Ri en result que no est en BCNF) then si no trivial en Ri --> es una dependencia funcional tal que est en F+ y else done=true end =0 result= ( result - Ri ) ( Ri ) ( , ) --> Ri no
Ejemplo: R(A,B,C,D)
B--> C B-->D (B)+ = {CD}
La superllave sera {AB} por lo tanto no cumple con BCNF (B-->CD y B no es superllave). Descomponiendo usando B-->CD (A,B) (B,C,D)
Esta ltima en BCNF
3.5.7 Tercera forma normal 3.5.7.1 Caractersticas Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:
X --> A es una dependencia funcional trivial
X es una super llave
A es miembro de una llave candidata de R Lo anterior no quiere decir que una sola llave candidata deba contener a todos los atributos de A, cada atributo de A puede estar contenido en llaves candidatas diferentes.
Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que da flexibilidad a las relaciones. Podemos afirmar entonces que: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". ejemplo, dada la relacin
branch-name customer-name banker-name office-number
banker-name --> branch-name office-number customer-name branch-name --> banker-name Se puede observar {customer-name branch-name} determina al resto de los atributos as que es la superllave de R.
No est en 3NF porque:

Las DFs no son triviales En la primer dependencia, "banker-name" no es superllave de R Se puede observar que office-number y banker-name no son parte de alguna llave candidata
se descompondra en:
banker-name branch-name office-number
banker-name --> branch-name office-number

customer-name branch-name banker-name
customer-name branch-name --> banker-name banker-name --> branch-name Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales En la segunda relacin, la segunda DF no cumple que banker-name es superllave
En la segunda relacin, la segunda DF, branch-name es miembro de la llave candidata {customer-name, branch-name}
Al cumplirse la 3er regla se confirma que la descomposicin est en 3NF. Se puede observar que al no cumplir con las 2 primeras no est en BCNF pero gracias al relajamiento si est en 3NF Otro ejemplo:
deptos nombre_depto extensin id_jefe
nombre_depto --> extensin, jefe
empleados id_empleado nombre_depto id_jefe
id_empleado --> nombre_depto, id_jefe nombre_depto --> id_jefe
No est en 3NF porque:

Las DFs no son triviales En la dependencia "nombre_depto-->id_jefe" de la segunda relacin, "nombre_depto" no es superllave de R Se puede observar nuevamente para la segunda relacin que id_jefe no es parte de alguna llave candidata
Aplicando la descomposicin:
deptos nombre_depto extensin id_jefe
nombre_depto --> extensin, jefe empleados id_empleado nombre_depto
id_empleado --> nombre_depto
Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales Para toda dependencia X--> A , X es superllave.
Se observa como la relacin no solo est en 3NF sino tambin en BCNF por cumplir con la segunda regla. 3.5.7.2 Algoritmo general de descomposicin tratando de alcanzar 3NF
3.5.7.2.1 Forma cannica de las FDs (Fc) La forma cannica de F es aquel conjunto mnimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias. Para obtener la Fc se deben extraer todos los miembros "extraos", suponga un conjunto F de dependencias funcionales y la dependencia --> est en F.
El atributo A es extrao en F lgicamente implica (F - { Ejemplo: F = { A --> C , AB --> C }
si A -->
y }) {( - A ) --> }
B es extrao en AB --> C porque { A --> C, AB --> C } lgicamente implica A --> C (el resultado de quitar B de AB --> C ).
El atributo A es extrao en si A el conjunto de dependencias (F - { implica lgicamente a F Ejemplo: F = { A --> C , AB --> CD}
y -->
})
--> (
-A)}
C es extrao en AB --> CD porque A B --> C puede ser inferido an despus de eliminar C Test para verificar si un atributo es extrao Dado un conjunto de dependencias F y
-->
est en F
Para verificar si A
o o
es extrao en } - A )+ usando las dependencias en F
calcular ( {
verificar si ( { } - A )+ contiene a , si lo hace entonces A es extrao Para verificar si A es extrao en o calcular + usando solo las dependencias en:
F'=(F - {
o
-->
})
--> (
- A) }
verificar si
+ contiene a A, si lo hace entonces A es extrao
3.5.7.2.2 Algoritmo basado en Fc

Fc: Forma cannica de las FDs
1. Para cada dependencia X --> Y en Fc, crear una relacin Ri (X,Y) 2. Si ninguna de las Ris contiene una de las superllaves de la relacin, crear Ri(X) donde X es una de las superllaves de la relacin original 3. Si Ri y Rj tienen una llave en comn, mezclar Ri y Rj 4. Eliminar relaciones redundantes
*El algoritmo anterior garantiza que en una descomposicin no haya prdida (al incluir por lo menos en una relacin una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas). Ejemplo:
sid name street city zip
student Fc: sid -->name,street,city street, city-->zip zip --> city Descomponer en 3NF 1. R1(sid, name, street, city), R2(zip, street, city), R3(zip, city) 2. 3. -
4. Eliminar R3
sid name street city
R1 sid -->name,street,city
zip street city
R2 street, city-->zip zip --> city 3.5.8 BCNF vs 3NF Como se mencion anteriormente: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". En la prctica la mayora de los esquemas en 3NF tambin estn en BCNF, contraejemplo: (Sucursal, Cliente, Banquero) banquero --> sucursal sucursal, cliente --> banquero est en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando: suc-banquero (sucursal, banquero) suc-cliente (sucursal, cliente) Nuevamente se presentan las prdidas de dependencias Qu es mejor ? BCNF o 3NF ?
De manera general se puede decir que ambas son buenas. El caso ideal es conseguir BCNF sin prdidas y con preservacin de dependencias. Si se alcanza BCNF pero no hay preservacin de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de prdidas y debe preservar dependencias).
3.6 Conclusiones
De manera que las metas del diseo de bases de datos con dependencias funcionales son:

BCNF* Descomposicin sin prdida Preservacin de dependencias
* Llegar a una forma BCNF puede llegar a ser complicado, debido a esto en muchas ocasiones es suficiente con alcanzar la 3NF para lograr un buen diseo.
EL MODELO RELACIONAL
1. INTRODUCCIN_____________________________________________________ 56 2. ESTRUCTURA DEL MODELO RELACIONAL____________________________ 57

Dominio y Atributo______________________________________________________ 58 Relacin______________________________________________________________ 59 Claves________________________________________________________________ 59 Restricciones__________________________________________________________ 60
3. El MODELO RELACIONAL Y LA ARQUITECTURA ANSI__________________ 62 4. LOS VALORES NULOS EN EL MODELO RELACIONAL___________________ 62 5. DINAMICA DEL MODELO RELACIONAL_______________________________ 63 6. ALGEBRA RELACIONAL______________________________________________ 63
OPERADORES PRIMITIVOS____________________________________________ 64 OPERADORES DERIVADOS_____________________________________________ 68
7. CALCULO RELACIONAL______________________________________________ 70
Clculo Relacional orientado a la tupla______________________________________ 70 Clculo relacional orientado a dominios._____________________________________ 72
8. SQL (STRUCTURED QUERY LANGUAGE)_______________________________ 73
1. INTRODUCCIN
La introduccin por Codd, muy a finales de los sesenta, de la teora de las relaciones en el campo de las bases de datos supuso un importante paso en la investigacin de los SGBD, suministrando un slido fundamento terico para el desarrollo, dentro de este enfoque relacional, de nuevos productos. El documento de Codd propone un modelo de datos basado en la teora de las relaciones, en donde los datos se estructuran lgicamente en forma de relaciones -tablas-, siendo un objetivo fundamental del modelo mantener la independencia de esta estructura lgica respecto al modo de almacenamiento y a otras caractersticas de tipo fsico.
El trabajo publicado por Codd (1970), presentaba un nuevo modelo de datos que persegua una serie de objetivos, que se pueden resumir en los siguientes.
Independencia fsica: es decir, el modo en el que se almacenan los datos no influya en su manipulacin lgica y, por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico.
Independencia lgica: esto es, que el aadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos (vistas).
Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en que ste prefiera.
Uniformidad: las estructuras lgicas de los datos presentan un aspecto uniforme, lo que facilita la concepcin y manipulacin de la base de datos por parte de los usuarios.
Sencillez: las caractersticas anteriores, as como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender y de utilizar por parte del usuario final.
Para conseguir los objetivos citados, Codd introduce el concepto de "relacin" (tabla) como una estructura bsica del modelo. Todos los datos de la BD se representan en forma de relaciones cuyo contenido vara en el tiempo.
Con respecto a la parte dinmica del modelo, se proponen un conjunto de operadores que se aplican a las relaciones. Todos ellos conforman el lgebra Relacional.
2. ESTRUCTURA DEL MODELO RELACIONAL

La relacin es el elemento bsico en el modelo relacional y se puede representar como una tabla:
Nombre
Atributo 1 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Atributo 2 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
..................... XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Atributo n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 1 Tupla 2 . . Tupla n
En ella podemos distinguir un conjunto de columnas, denominadas atributos, que representan propiedades de la misma y que estn caracterizadas por un nombre; y un conjunto de
filas llamadas tuplas que son las ocurrencias de la relacin. Existen tambin unos dominios donde los atributos toman sus valores.
El nmero de filas de una relacin se denomina cardinalidad de la relacin y el nmero de columnas es elgrado de la relacin.
Ejemplo: AUTOR
Nombre Pepe John Pierre
Nacionalidad Espaa EE.UU. Francia
Institucion O.N.U. O.M.S. N.A.S.A.
Una relacin se puede representar en forma de tabla, pero va a tener una serie de elementos caractersticos: No puede haber filas duplicadas, es decir, todas las tuplas tienen que ser distintas. El orden de las filas es irrelevante. La tabla es plana, es decir, en el cruce de una fila y una columna slo puede haber un valor (no se admiten atributos multivaluados).
DOMINIO Y ATRIBUTO
Un dominio D es un conjunto finito de valores homogneos y atmicos caracterizados por un nombre; decimos homogneos porque son todos del mismo tipo y atmicos porque son indivisibles.
Todo dominio ha de tener un nombre por el cual nos podamos referir a l y un tipo de datos; as el tipo de datos del dominio "nacionalidades" es una tira de caracteres de longitud 10.
El dominio "nacionalidades" tiene valores : Espaa, Francia,... Si descompusiramos Espaa en E,s,p,... perdera la semntica.
Ejemplos de dominios seran: Colores: Es el conjunto de los colores D={rojo, verde, azul,} Nmeros de DNI: Es conjunto de nmeros del DNI vlidos, formados por ocho dgitos. Edad: Edades posibles de los empleados entre 18 y 80 aos.
Un atributo es el papel que tiene un determinado dominio en una relacin.
Es muy usual dar el mismo nombre al atributo y al dominio. En el caso de que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habr que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre.
Por ejemplo los atributos edad_fsica y edad_mental pueden estar definidos sobre el mismo dominio edad; o loa atributos precio_compra y precio_venta pueden estar definidos sobre el mismo dominio de enteros de longitud 5.
Adems de los dominios y atributos simples que acabamos de definir, en los ltimos trabajos de algunos autores [Codd (1990), Date (1990)] se introduce el concepto de dominio compuesto.
Un dominio compuesto se puede definir como una combinacin de dominios simples que tiene un nombre y a la que se pueden aplicar ciertas restricciones de integridad. Por ejemplo, un usuario puede necesitar manejar, adems de los tres dominios Da, Mes y Ao, un dominio compuesto denominado Fecha que sera la combinacin de los tres primeros, y al que podramos aplicar las adecuadas restricciones de integridad a fin de que no aparecieran valores no vlidos para la fecha; algo anlogo ocurre Con el nombre y los apellidos, que, segn las aplicaciones, puede ser conveniente tratarlos en conjunto o por separado.
De la misma forma, es posible definir un atributo compuesto Fecha que tomara sus valores del dominio compuesto de igual nombre.
RELACIN
Matemticamente, una relacin se puede definir como un subconjunto del producto cartesiano de una lista de dominios, donde cada elemento de la relacin, tupla, es una serie de n valores ordenados.
En esta definicin matemtica de relacin, que es la que aparece en los primeros trabajos de Codd, no se alude a los atributos, es decir, al papel que tienen los dominios en la relacin y, adems, en ella el orden de los valores dentro o de una tupla es significativo. A fin de evitar estos inconvenientes, se puede dar otra definicin de relacin ms adecuada al punto de vista de las bases de datos, para lo cual es preciso distinguir, dos conceptos en la nocin de relacin :
Intensin o Esquema de relacin, denotado R (Al:D1, A2:D2, ..., An:Dn) es un conjunto de n pares atributo-dominio subyacente (Ai:Di). La intensin es la parte definitoria y esttica de la relacin, que se corresponde con la cabecera cuando la relacin se percibe como una tabla. Extensin u ocurrencia (instancia) de relacin (llamada a veces simplemente relacin), denotada por r(R) es un conjunto de m tuplas {t1, t2, ... tm} donde cada tupla es un conjunto de n pares atributo-valor.
Ejemplo:
Intensin de una relacin:
AUTOR (NOMBRE:Nombres, NACIONALIDAD:Nacionalidades, INSTITUCION: Instituciones)
Extensin de una relacin:

AUTOR Nombre Pepe John Pierre Nacionalidad Espaa EE.UU. Francia Institucion O.N.U. O.M.S. N.A.S.A.
CLAVES
Una clave candidata de una relacin es un conjunto no vaco de atributos que identifican unvoca y mnimamente cada tupla. Por la propia definicin de relacin, siempre hay al menos una clave candidata, ya que al ser la relacin un conjunto no existen tuplas repetidas y por tanto, el conjunto de todos los atributos identificar unvocamente a las tuplas. Una relacin puede tener ms de una clave candidata, entre las cuales se debe distinguir:
Clave primaria: es aquella clave candidata que el usuario escoger, por consideraciones ajenas al modelo relacional, para identificar a las tuplas de una relacin. Clave alternativa: son aquellas claves candidatas que no han sido elegidas.
Se denomina clave ajena de una relacin R2 a un conjunto no vaco de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relacin R1. La clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios.
RESTRICCIONES
En el modelo relacional, existen restricciones, es decir, estructuras u ocurrencias no permitidas, siendo preciso distinguir entre restricciones inherentes y restricciones de usuario.
Restricciones inherentes
Adems de las derivadas de la definicin matemtica de "relacin" como eran que:
No hay dos tuplas iguales. El orden de las tuplas no es significativo. El orden de los atributos (columnas) no es significativo. Cada atributo slo puede tomar un nico valor del dominio, no admitindose por tanto los grupos repetitivos.
Tenemos que la regla de integridad de entidad establece que "Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor nulo"; esto es, un valor desconocido o inexistente. Esta restriccin debera aplicarse tambin a las claves alternativas, pero el modelo no lo exige.
Restricciones de usuario
Podemos considerar la restriccin de usuario, dentro del contexto relacional, como un predicado definido sobre un conjunto de atributos, de tuplas o de dominios, que debe ser verificado por los correspondientes objetos para que stos constituyan una ocurrencia vlida del esquema.
Dentro de las restricciones de usuario destaca la restriccin de integridad referencial que dice que los valores de clave ajena deben coincidir con los de clave primaria asociada a ella o ser nulos.
La integridad referencial es una restriccin de comportamiento ya que viene impuesta por el mundo real y es el usuario quien la define al describir el esquema relacional; es tambin de tipo implcito, ya que se define en el esquema y el modelo la reconoce (o as algunos productos) sin necesidad de que se programe ni de que se tenga que escribir ningn procedimiento para obligar a que se cumpla.
EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS) LIBRO (CODIGO, TITULO, IDIOMA, ..., NOMBRE_E)
En este ejemplo el atributo nombre_e de la relacin LIBRO es clave ajena que referencia a EDITORIAL, de modo que debe concordar con la clave primaria de la relacin EDITORIAL o bien ser nulo, porque los libros de nuestra base de datos debern pertenecer a una editorial existente, o si se desconoce la editorial, no se tendr ningn valor para este atributo.
AUTOR (NOMBRE, NACIONALIDAD, INSTITUCION, ..) LIBRO (CODIGO, TITULO, IDIOMA, EDITORIAL, ...) ESCRIBE (NOMBRE, COD LIBRO)
En este ejemplo la relacin ESCRIBE posee dos claves ajenas: nombre, que referencia a la relacin AUTOR, ycod_libro, que referencia a la relacin LIBRO; en este caso ninguna de las dos claves ajenas puede tomar valores nulos, ya que forman parte de la clave primaria de la relacin ESCRIBE.
Adems de definir las claves ajenas, hay que determinar las consecuencias que pueden tener ciertas operaciones (borrado y modificacin) realizadas sobre tuplas de la relacin referenciada; pudindose distinguir, en principio, las siguientes opciones:
Operacin restringida: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada; slo se permite si no existen tuplas con dicha clave en la relacin que contiene la clave ajena. Esto nos llevara, por ejemplo, a que para poder borrar una editorial de nuestra base de datos no tendra que haber ningn libro que estuviese publicado por dicha editorial, en caso contrario el sistema impedira el borrado.
Operacin con transmisin en cascada: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo el borrado o modificacin en cascada de las tuplas de la relacin que contienen la clave ajena. En nuestro ejemplo, equivaldra a decir que al modificar el nombre de una editorial en la relacin EDITORIAL, se tendra que modificar tambin dicho nombre en todos los libros de nuestra base de datos publicados por dicha editorial.
Operacin con puesta a nulos: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner a nulos los valores de las claves ajenas de la relacin que referencia. Esto nos llevara a que cuando se borra una editorial, a los libros que ha publicado dicha editorial y que se encuentran en la relacin LIBROS se les coloque el atributo nombre_e a nulos. Esta opcin, obviamente, slo es posible cuando el atributo que es clave ajena admite el valor nulo.
Operacin con puesta a valor por defecto: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner el valor por defecto a la clave ajena de la relacin que referencia.
Operacin que desencadena un procedimiento de usuario: en este caso, el borrado o la modificacin de tuplas de la tabla referenciada pone en marcha un procedimiento definido por el usuario.
3. EL MODELO RELACIONAL Y LA ARQUITECTURA ANSI

El modelo relacional puede examinarse en el marco de la arquitectura ANSI a tres niveles. Todos los objetos que hemos visto hasta el momento, esto es, los dominios,
relaciones, claves y restricciones constituyen el esquema conceptual de la arquitectura ANSI. Las relaciones se denominan tablas base o reales, ya que tienen una representacin directa en el almacenamiento interno. Existe otro tipo de tablas, denominadas tablas virtuales o vistas, que se definen sobre una o ms tablas base. Las vistas son ventanas sobre tablas reales, de las que slo se almacena su definicin, y no tienen, por tanto, representacin directa en el almacenamiento; equivalen al esquema externo de la arquitectura ANSI. Por lo que respecta al esquema interno, el modelo relacional no especifica absolutamente nada puesto que se trata de un modelo lgico. Vemos, por tanto, que, el modelo relacional terico se adapta bastante bien a la arquitectura ANSI.
4. LOS VALORES NULOS EN EL MODELO RELACIONAL

Se puede definir el valor nulo como una marca utilizada para representar informacin desconocida. La necesidad de valores nulos es evidente por diversas razones:
Existencia de tuplas con ciertos atributos desconocidos en ese momento.
Necesidad de aadir un nuevo atributo a una tabla ya existente; atributo que en el momento de introducirse no tendr ningn valor para las tuplas de la relacin.
Posibilidad de atributos inaplicables a ciertas tuplas, como la editorial para un artculo.
5. DINAMICA DEL MODELO RELACIONAL
La dinmica del modelo relacional se expresa mediante lenguajes de manipulacin relacionales que asocian una sintaxis concreta a las operaciones. Los lenguajes relacionases operan sobre conjuntos de tuplas, y se dividen en dos tipos:
Algebraicos: Se caracterizan porque los cambios de estado se especifican mediante operaciones cuyos operandos son relaciones y cuyo resultado es otra relacin. Genricamente se conocen como lgebra relacional.
Predicativos: donde los cambios de estado se especifican mediante predicados que definen el estado objetivo sin indicar las operaciones que hay que realizar para llegar al mismo; se seleccionan, as, conjuntos de tuplas. Genricamente se conocen como clculo relacional y se dividen en dos tipos: orientados a la tupla y orientados al dominio.
6. ALGEBRA RELACIONAL
El aspecto dinmico del modelo relacional en lo que al lgebra se refiere, lo constituye una coleccin de operadores que, aplicados a las relaciones, dan como resultado nuevas relaciones (propiedad de cierre).
Los operandos del lgebra son las relaciones y los operadores se aplican a las relaciones a fin de formular consultas a la BD.
Son cinco los operadores que podramos llamar primitivos: los tradicionales de teora de conjuntos unin, diferencia y producto cartesiano, y los especialmente introducidos por Codd de restriccin y proyeccin; adems, existen otros operadores que se pueden considerar derivados, ya que se pueden deducir de los primitivos.
OPERADORES PRIMITIVOS
A) Unarios
Los operadores unarios tienen como operando una nica relacin; para su definicin utilizaremos la siguiente notacin:
Restriccin o seleccin
La restriccin, tambin llamada seleccin, de una relacin mediante una expresin lgica da como resultado una relacin formada por el subconjunto de tuplas que satisface dicha expresin lgica. Se denota mediante la letra .
condicion_de_seleccion (nombre_de_relacion)
Ejemplo: Dada la tabla AUTOR:
AUTOR Nombre Pepe John Perez Surez Pierre Nacionalidad Espaa EE.UU. Espaa Espaa Francia Institucion O.N.U. O.M.S. I.N.I. I.N.E. N.A.S.A.
Seleccin de nacionalidad espaola (AUTOR):
Nacionalidad=Espaa (AUTOR)
Nombre Pepe Perez Surez Nacionalidad Espaa Espaa Espaa Institucion O.N.U. I.N.I. I.N.E.
Proyeccin
La proyeccin de una relacin sobre un subconjunto de sus atributos es una relacin definida sobre ellos, eliminando las tuplas duplicadas que hubieran podido resultar. Se denota mediante la letra .
lista_de_atributos (nombre_de_relacion)
Ejemplo: Para la tabla AUTOR, la proyeccin de nacionalidad e institucin.
Nacionalidad, Institucion (AUTOR)
Nacionalidad
Institucion
Espaa EE.UU. Espaa Espaa Francia
O.N.U. O.M.S. I.N.I. I.N.E. N.A.S.A.
En general, es posible que deseemos aplicar varias operaciones de lgebra relacional una tras otra. Para ello podemos escribir las operaciones en una sola expresin del lgebra relacional, anidndolas, o bien, podemos aplicar las operaciones una a una y crear relaciones intermedias. En el segundo caso tendremos que nombrar las relaciones que contienen los resultados intermedios.
Ejemplo. Si se quiere obtener el nombre e institucin de los autores espaoles podemos escribir:
Nombre, Institucion (
Nacionalidad=Espaa (AUTOR) )
O bien mostrar explcitamente la secuencia de operaciones dando un nombre a cada una de ellas.
AUTOR_ESP Nacionalidad=Espaa (AUTOR) RESULTADO Nombre, Institucion (AUTOR_ESP)
B) Binarios
Los operadores binarios se aplican a dos relaciones, y algunos de ellos (unin, diferencia e interseccin) exigen que las dos relaciones involucradas sean compatibles en sus esquemas. Es decir deben estar definidas sobre el mismo dominios, lo que no quiere decir que los nombres de los atributos sean los mismos
Unin
La unin de dos relaciones compatibles en su esquema es otra relacin definida sobre el mismo esquema de relacin cuya extensin estar constituida por las tuplas que pertenezcan a una de las dos relaciones o a ambas (se eliminarn las tuplas duplicadas puesto que se trata de una relacin). Se denota mediante el smbolo .
Relacion1 Relacion2
Ejemplo de unin de dos relaciones.
AUTOR
Nombre John Juan Pedro Luigi
Nacionalidad EEUU Espaa Espaa Italia
Institucion I1 I2 I3 I4
EDITOR
Nombre Juan
Nacionalidad Espaa
Institucion I2
Chen Smith Pedro
EEUU EEUU Espaa
I5 I6 I3
AUTOR EDITOR
Nombre John Juan Pedro Luigi Chen Smith
Nacionalidad EEUU Espaa Espaa Italia EEUU EEUU
Institucion I1 I2 I3 I4 I5 I6
Nota: Si la correspondencia de los nombres de los atributos de las relaciones R y R' no fuese 1: 1 sera preciso aplicar la operacin de renombrado de atributo en la relacin resultante.
Diferencia
La diferencia de dos relaciones compatibles en su esquema es otra relacin definida sobre el mismo esquema de relacin, cuya extensin estar constituida por el conjunto de tuplas que pertenezcan a la primera relacin, pero no a la segunda. Se denota mediante el smbolo -
Relacion1 - Relacion2
Ejemplo de diferencia de dos relaciones.
AUTOR
Nombre John Juan Pedro Luigi
Nacionalidad EEUU Espaa Espaa Italia
EDITOR
Nombre Juan Chen Smith Pedro
Nacionalidad Espaa EEUU EEUU Espaa
AUTOR - EDITOR
Nombre John Luigi
Nacionalidad EEUU Italia
Institucion I1 I4
Producto cartesiano
Producto cartesiano de dos relaciones de cardinalidades m y n es una relacin cuyo esquema estar definido sobre la unin de los atributos de ambas relaciones, y cuya extensin estar constituida por las m x n tuplas formadas concatenando cada tupla de la primera relacin con cada una de las tuplas de la segunda. Se denota por la letra x. Relacion1 x Relacion2
Ejemplo:
SOCIO
Codigo 1 2
Nombre Elena Manuel
Direccion Madrid Bilbao
LIBRO
Libro BD INFORMIX
Autor Gardarin Zeroual
Editorial McGraw Ra-Ma
SOCIO x LIBRO
Codigo 1 1 2 2
Nombre Elena Elena Manuel Manuel
Direccion Madrid Madrid Bilbao Bilbao
Libro BD INFORMIX BD INFORMIX
Autor Gardarin Zeroual Gardarin Zeroual
Editorial McGraw Ra-Ma McGraw Ra-Ma
OPERADORES DERIVADOS
Los operadores derivados son aquellos que se pueden expresar siempre en funcin de operadores primitivos, pero su introduccin tiene por fin la simplificacin de las consultas.
Combinacin o join
La combinacin de dos relaciones respecto de sus columnas d y k es otra relacin constituida por todos los pares de tuplas concatenadas, tales que, en cada par, las columnas d y k de las correspondientes tuplas satisfacen la condicin especificada. Si la condicin es de igualdad se denomina combinacin por igualdad (tambin se denomina equijoin o join). La llamada combinacin natural (o join natual) es una combinacin por igualdad donde se ha eliminado en la relacin resultante uno de los atributos idnticos. Es el caso ms utilizado de combinacin para relaciones que tienen un atributo comn (se suele hablar de join para referirse a esta posibilidad por ser el caso ms usual). Se denota mediante el smbolo
Relacion1
Ejemplo:
Relacion2
AUTOR
Nombre A1 A2 A3 A4
Nacionalidad N1 N2 N3 N4
LIBRO
Libro
Autor
Editorial
L1 L2 L3 L4
A1 A4 A1 A2
E1 E2 E1 E3
Nombre, Nacionalidad, Institucion, Libro, Editorial (
AUTOR.Nombre=LIBRO.Autor(AUTOR x LIBRO))
Libro L1 L3 L4 L2 Editorial E1 E1 E3 E2
Nombre A1 A1 A2 A4
La combinacin es un producto cartesiano seguido de restriccin, y la combinacin natural es un producto cartesiano seguido de una restriccin por igualdad y de proyeccin.
Interseccin
La interseccin de dos relaciones compatibles en sus esquema es otra relacin definida sobre el mismo esquema de relacin, cuya extensin estar constituida por las tuplas que pertenezcan a ambas relaciones. Se denota por la letra.
Relacion1 Relacion2 = Relacion1 (Relacion1 Relacion2)
Ejemplo de interseccin de dos relaciones.
AUTOR
Nombre A1 A2 A3 A4
EDITOR
Nombre A2 A5 A6 A3
AUTOR EDITOR
Nombre A2 A3
Nacionalidad N2 N2
Institucion I2 I3
Divisin
La divisin de dos relaciones otra relacin cuya extensin estar formada por las tuplas que al completarse con las tuplas de la segunda relacin permiten obtener la primera. Se denota por el smbolo :
Relacion1 : Relacion2 = A(Relacion1) - A[(A(Relacion1) x Relacion2) - Relacion1] A = { Atributos Relacion1 Atributos Relacion 2}
Ejemplo de divisin de dos relaciones.
VINO
Tipo Albario Ulla Condado Condado Amandi
Cosecha 1977 1978 1977 1978 1978
Calidad Bueno Malo Bueno Bueno Bueno
CALIDAD_BUENA
Cosecha 1977 1978
Calidad Bueno Bueno
Vinos con calidad buena en todas las cosechas:
AUTOR : CALIDAD_BUENA
Tipo Condado
Es un operador muy til para simplificar consultas como en el ejemplo donde se desea obtener los vinos con buena calidad en todas las cosechas.
7. CALCULO RELACIONAL
El clculo relacional fue propuesto por Codd como alternativa al lgebra. La diferencia fundamental entre un lenguaje algebraico y un lenguaje predicativo (denominado as porque utiliza el clculo de predicados para la formulacin de consultas), es que en el primero hay que especificar que operadores se tienen que aplicar a las relaciones para obtener un resultado, mientras que en el segundo slo es preciso indicar el resultado que se quiere obtener.
Los lenguajes del clculo relacional pueden ser de dos tipos: orientados a la tupla y orientados al dominio.
CLCULO RELACIONAL ORIENTADO A LA TUPLA

Tiene las siguientes consideraciones:
Las variables se asocian a tuplas. Las constantes se asocian a variables de dominio.
Los operadores son los de comparacin, los lgicos NOT, AND, OR, as como el existencial ( ) y el universal ().
Una consulta en el clculo relacional orientado a tuplas obedece al siguiente esquema:
[definicin de las variables de fila] operador objetivo predicado
La sentencia de definicin de las variables de fila (o de tupla) declara una variable como movindose sobre las tuplas de una relacin y, en un determinado momento, representa indistintamente una cualquiera de las tuplas (filas) de la relacin especificada.
El operador determinar la accin que hay que realizar con los datos seleccionados (en clculo relacional puro se suele omitir siempre por ser una consulta).
El objetivo especifica qu atributos y de qu relaciones se desea recuperar, es la estructura lgica a recuperar.
El predicado especifica la condicin que deben verificar las tuplas a fin de ser seleccionadas.
Un ejemplo de clculo relacional orientado a tuplas es el lenguaje ALPHA que, si bien nunca fue instrumentado, ha tenido gran influencia en desarrollo de otros lenguajes como el QUEL de INGRES.
Ejemplo en lenguaje ALPHA. Obtener, a partir de las tablas AUTOR y LIBROS, el nombre de los autores junto con las editoriales en que han publicado.
GET
RESULTADO (AUTOR.nombre, LIBROS.editorial): AUTOR.nombre=LIBROS.autor Objetivo Predicado
Operador
Otro lenguaje relacional orientado a tuplas es el lenguaje QUEL de INGRES. La sintaxis de la sentencia de recuperacin es la siguiente:
RANGE OF <variable> IS <relacin> ...... RETRIEVE <lista atributos> [WHERE <condicin>]
Ejemplo. Obtener el nombre de las editoriales en las que hayan publicado autores de nacionalidad "N1.
RANGE OF A IS AUTORES RANGE OF L IS LIBROS RETRIEVE (L.editorial) WHERE A.nacionalidad ="N1" AND A.nombre = L.autor
El QUEL no incluye operaciones del lgebra relacional como la interseccin, unin o diferencia y no permite subconsultas anidadas.
CLCULO RELACIONAL ORIENTADO A DOMINIOS.

En el clculo relacional orientado a dominios existen variables de dominios en lugar de variables de tupla, las variables de dominio se definen sobre un dominio, tomando en cada momento un valor de ste.
El ejemplo ms caracterstico del clculo relacional orientado a dominios es el lenguaje QBE (Query by Example). Est concebido para su utilizacin desde un terminal, y por medio de una tecla de ste el usuario puede invocar esqueletos de tablas, las cuales tienen cuatro zonas:
Zona para el nombre de la tabla
Zona para el nombre de columnas
Zona para el operador de cada fila
Zona Para datos
Tambin el usuario puede obtener el esqueleto de una relacin sin ms que escribir el nombre de la misma.
Ejemplo: Entrada del usuario: AUTOR Respuesta QBE:
AUTOR
Nombre Nacionalidad Editorial
Entrada del usuario:
AUTOR
Nombre Nacionalidad Editorial P.
Respuesta QBE:
AUTOR
Nombre Nacionalidad Editorial John EEUU E
1 Juan Pedro Juan Espaa Espaa Espaa E1 E3 E2
8. SQL (STRUCTURED QUERY LANGUAGE)

El lenguaje SQL (Structured Query Language, "Lenguaje de Consulta Estructurado") es una evolucin del lenguaje SEQUEL (structured english query language) desarrollado en IBM.
El SQL se encuentra normalizado por el Instituto Americano de Normalizacin (ANSI) y fue construido en principio como un lenguaje algebraico, enriquecindose ms tarde con funciones predicativas como la clusula existencial,...
Estructura y caractersticas del lenguaje
El lenguaje SQL contiene un limitado nmero de verbos o palabras clave, distribuidos en tres grandes grupos funcionales: DDL (lenguaje de descripcin de datos), DML (lenguaje de manipulacin de datos) y DCL (lenguaje de control de datos).
DDL CREATE DROP ALTER
DML SELECT INSERT DELETE UPDATE
DCL GRANT REVOKE COMMIT ROLLBACK
DDL: Permite la descripcin de la estructura de la BD (tablas, vistas, ndices,...) DML: Permite el manejo de las tablas y las vistas mediante sus cuatro verbos, correspondientes a las cuatro operaciones fundamentales sobre los datos. DCL: Contiene los operadores para la gestin de transacciones (COMMIT y ROLLBACK) y prioridades de acceso a los datos (GRANT y REVOKE)
Caractersticas:
El SQL es manejable bajo dos modalidades distintas: como mdulo interactivo que proporciona un potente lenguaje de consultas interpretadas y como lenguaje husped de un lenguaje anfitrin.
Respeta la independencia entre el nivel conceptual y las aplicaciones (nivel externo), ya que permite la creacin de esquemas externos personalizados.
Garantiza una seguridad total de acceso a los datos, gracias a una distribucin selectiva de prioridades de acceso.
Garantiza la independencia entre el nivel conceptual y el nivel interno. El usuario no nota la presencia de un ndice, es asunto del administrador el conseguir la optimizacin de las ejecuciones.
Permite la gestin multiusuario de los datos. Cada fila a la que se accede para su modificacin queda automticamente bloqueada por el sistema. En particular, el SQL contiene el concepto de transaccin, que permite restaurar el estado anterior de la BD en caso de anomalas.
Independencia de los vendedores. El SQL es ofertado por los principales vendedores. Los programas que lo utilizan pueden transferirse de un sistema de gestin de BD a otro con mnimo esfuerzo de conversin.
Captulo 4: El modelo relacional

En este captulo se presenta el modelo relacional, que es el modelo lgico en el que se basan la mayora de los SGBD comerciales en uso hoy en da. En primer lugar, se trata la descripcin de los principios bsicos del modelo relacional: la estructura de datos relacional y las reglas de integridad. A continuacin, se presenta un tratamiento detallado del lgebra relacional, que es un conjunto de operaciones para manipular la estructura de datos relacional y especificar consultas de datos. El lgebra relacional es un lenguaje procedural, mientras que el clculo relacional, que tambin se estudia en este captulo, es un lenguaje equivalente no procedural.
Introduccin Es una buena justificacin para estudiar la teora que hay tras el modelo relacional, la que da Hernndez (1997): "Muchas disciplinas (y sus metodologas de diseo asociadas) tienen algn tipo de base terica. Los ingenieros industriales disean estructuras utilizando teoras de la fsica. Los compositores crean sinfonas utilizando conceptos de teora de la msica. La industria del automvil utiliza teoras de la aerodinmica para disear automviles con menor consumo. La industria aeronutica utiliza las mismas teoras para disear alas de aviones que reduzcan la resistencia al viento. Estos ejemplos demuestran que la teora es muy importante. La ventaja principal de la teora es que hace que las cosas sean predecibles: nos permite predecir qu ocurrir si realizamos una determinada accin. Por ejemplo, sabemos
que si soltamos una piedra, caer al suelo. Si somos rpidos, podemos apartar nuestros pies del camino de la teora de la gravedad de Newton. Lo importante es que siempre funciona. Si ponemos una piedra plana encima de otra piedra plana, podemos predecir que se quedarn tal y como las hemos puesto. Esta teora permite disear pirmides, catedrales y casas de ladrillos. Consideremos ahora el ejemplo de una base de datos relacional. Sabemos que si un par de tablas estn relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teora de las bases de datos relacionales. Los datos que se saquen de las dos tablas se basarn en los valores coincidentes del campo que ambas tienen en comn. Una vez ms, nuestras acciones tienen un resultado predecible. El modelo relacional se basa en dos ramas de las matemticas: la teora de conjuntos y la lgica de predicados de primer orden. El hecho de que el modelo relacional est basado en la teora de las matemticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemticas proporcionan los elementos bsicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las lneas que se utilizan para formular buenas metodologas de diseo. Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemticos para tan slo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teoras matemticas en las que se basa el modelo relacional y sus metodologas de diseo, no tienen relevancia en el mundo real o que no son prcticas. No es cierto: las matemticas son bsicas en el modelo relacional. Pero, por fortuna, no hay que aprender teora de conjuntos o lgica de predicados de primer orden para utilizar el modelo relacional. Sera como decir que hay que saber todos los detalles de la aerodinmica para poder conducir un automvil. Las teoras de la aerodinmica ayudan a entender cmo un automvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo. La teora matemtica proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teora describe los elementos bsicos que se utilizan para crear una base de datos relacional y proporciona las lneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseo." El modelo relacional En 1970, el modo en que se vean las bases de datos cambi por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros fsicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por
ejemplo, se quera relacionar un registro con un registro , se deba aadir al registro un campo conteniendo la direccin en disco del registro . Este campo aadido, un puntero fsico, siempre sealara desde el registro al registro . Codd demostr que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podan realizar sobre los datos. Adems, estas bases de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores de un nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se requera una conversin de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerrquico, los dos modelos lgicos que constituyeron la primera generacin de los SGBD. El modelo relacional representa la segunda generacin de los SGBD. En l, todos los datos estn estructurados a nivel lgico como tablas formadas por filas y columnas, aunque a nivel fsico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lgica. Pero detrs de esa simple estructura hay un fundamento terico importante del que carecen los SGBD de la primera generacin, lo que constituye otro punto a su favor. Dada la popularidad del modelo relacional, muchos sistemas de la primera generacin se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lgico que soportan (de red o jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visin relacional de los datos. En los ltimos aos, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientacin a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos: Estructura de datos. Integridad de datos. Manejo de datos.
Estructura de datos relacional En este apartado se presenta la estructura de datos del modelo relacional: la relacin Relaciones
Definiciones informales El modelo relacional se basa en el concepto matemtico de relacin, que grficamente se representa mediante una tabla. Codd, que era un experto matemtico, utiliz una terminologa perteneciente a las matemticas, en concreto de la teora de conjuntos y de la lgica de predicados. Una relacin es una tabla con columnas y filas. Un SGBD slo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepcin slo se aplica a la estructura lgica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura fsica de la base de datos, que se puede implementar con distintas estructuras de almacenamiento. Un atributo es el nombre de una columna de una relacin. En el modelo relacional, las relaciones se utilizan para almacenar informacin sobre los objetos que se representan en la base de datos. Una relacin se representa grficamente como una tabla bidimensional en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. Los atributos pueden aparecer en la relacin en cualquier orden. Por ejemplo, la informacin de las oficinas de la empresa inmobiliaria se representa mediante la relacin OFICINA, que tiene columnas para los atributos Onum (nmero de oficina), Calle, Area, Poblacin, Telfono y Fax. La informacin sobre la plantilla se representa mediante la relacin PLANTILLA, que tiene columnas para los atributos Enum (nmero de empleado), Nombre, Apellido, Direccin, Telfono, Puesto, Fecha_nac, Salario, DNI, Onum (nmero de la oficina a la que pertenece el empleado). A continuacin se muestra una instancia de la relacin OFICINA y una instancia de la relacin PLANTILLA. Como se puede observar, cada columna contiene valores de un solo atributo. Por ejemplo, la columna Onum slo contiene nmeros de oficinas que existen. OFICINA
Onum Calle O5 O7 O3 Enmedio, 8 Area Poblacin Telfono Fax
Centro Castelln 964 201 240 964 201 340
Moyano, s/n Centro Castelln 964 215 760 964 215 670 San Miguel, 1 Villarreal 964 520 250 964 520 255
O4 O2
Trafalgar, 23 Grao Cedre, 26
Castelln 964 284 440 964 284 420 Villarreal 964 525 810 964 252 811
PLANTILLA
Enu Nombr Apellid Direccin m e o EL21 Amelia Pastor Telfon Puesto o Fecha_na Salari DNI c o 12/10/62 30000 Onu m
Magallanes 964 284 Director , 15 560 Castelln
39432212 O5 E
EG3 Cubed 964 535 Superviso Pedro Bayarri, 11 24/3/57 7 o 690 r Villarreal EG1 Luis 4 Collad 964 522 Borriol, 35 Administ. 9/5/70 o 230 Villarreal EA9 Rita Renau Casalduch, 964 257 Superviso 19/5/60 32 550 r Castelln EG5 Julio Prats Melilla, 23 Villarreal EL41 Carlos Baeza Herrero, 51 Castelln 964 247 Superviso 29/2/67 250 r 964 524 Director 590 19/12/50
18000
38766623 O3 X
12000
24391223 O3 L
18000
39233190 O7 F
24000
25644309 O3 X
18000
39552133 O5 T
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen una poderosa caracterstica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La siguiente tabla muestra los dominios de los atributos de la relacin OFICINA. Ntese que en esta
relacin hay dos atributos que estn definidos sobre el mismo dominio, Telfono y Fax.
Atributo Onum Nombre del Dominio NUM_OFICINA Descripcin Posibles valores de nmero de oficina Definicin 3 caracteres; rango O1O99 Calle Area NOM_CALLE NOM_AREA Nombres de calles de Espaa Nombres de reas de las poblaciones de Espaa 25 caracteres 20 caracteres 15 caracteres 9 caracteres 9 caracteres
Poblacin NOM_POBLACION Nombres de las poblaciones de Espaa Telfono NUM_TEL_FAX Fax NUM_TEL_FAX Nmeros de telfono de Espaa Nmeros de telfono de Espaa
El concepto de dominio es importante porque permite que el usuario defina, en un lugar comn, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya ms informacin disponible para el sistema cuando ste va a ejecutar una operacin relacional, de modo que las operaciones que son semnticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un nmero de telfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un inmueble no estar definido sobre el mismo dominio que el nmero de meses que dura el alquiler, pero s tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominios ya que su implementacin es extremadamente compleja. Una tupla es una fila de una relacin. Los elementos de una relacin son las tuplas o filas de la tabla. En la relacin OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas de una relacin no siguen ningn orden. El grado de una relacin es el nmero de atributos que contiene. La relacin OFICINA es de grado seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con seis valores. El grado de una relacin no cambia con frecuencia.
La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas vara constantemente. Una base de datos relacional es un conjunto de relaciones normalizadas. Definiciones formales Una relacindefinida sobre un conjunto de dominios consta de: Cabecera: conjunto fijo de pares atributo:dominio
donde cada atributo corresponde a un nico dominio y todos los son distintos, es decir, no hay dos atributos que se llamen igual. El grado de la relacin es . Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de paresatributo:valor:
con , donde es la cardinalidad de la relacin . En cada par se tiene que . La relacin OFICINA tiene la siguiente cabecera:
{(Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA), (Poblacin:NOM_POBLACION), (Telfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:

{(Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Poblacin:Castelln), (Telfono:964 201 240), (Fax:964 201 340)}.
Este conjunto de pares no est ordenado, por lo que esta tupla y la siguiente, son la misma:
{(Calle:Enmedio,8), (Fax:964 201 340), (Poblacin:Castelln),
(Onum:O5), (Telfono:964 201 240), (Area:Centro)}
Grficamente se suelen representar las relaciones mediante tablas. Los nombres de las columnas corresponden a los nombres de los atributos y las filas son cada una de las tuplas de la relacin. Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del dominio sobre el que est definido el atributo correspondiente. Propiedades de las relaciones Las relaciones tienen las siguientes caractersticas: Cada relacin tiene un nombre y ste es distinto del nombre de todas las dems. Los valores de los atributos son atmicos: en cada tupla, cada atributo toma un solo valor. Se dice que las relaciones estn normalizadas. No hay dos atributos que se llamen igual. El orden de los atributos no importa: los atributos no estn ordenados. Cada tupla es distinta de las dems: no hay tuplas duplicadas. El orden de las tuplas no importa: las tuplas no estn ordenadas.
Tipos de relaciones En un SGBD relacional pueden existir varios tipos de relaciones, aunque no todos manejan todos los tipos. Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la base de datos almacenada (son autnomas). Vistas. Tambin denominadas relaciones virtuales, son relaciones con nombre y derivadas: se representan mediante su definicin en trminos de otras relaciones con nombre, no poseen datos almacenados propios. Instantneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son reales, no virtuales: estn representadas no slo por su definicin en trminos de otras relaciones con nombre, sino tambin por sus propios datos almacenados. Son relaciones de slo de lectura y se refrescan peridicamente.
Resultados de consultas. Son las relaciones resultantes de alguna consulta especificada. Pueden o no tener nombre y no persisten en la base de datos. Resultados intermedios. Son las relaciones que contienen los resultados de las subconsultas. Normalmente no tienen nombre y tampoco persisten en la base de datos. Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las instantneas, pero la diferencia es que se destruyen automticamente en algn momento apropiado. Claves Ya que en una relacin no hay tuplas repetidas, stas se pueden distinguir unas de otras, es decir, se pueden identificar de modo nico. La forma de identificarlas es mediante los valores de sus atributos. Una superclave es un atributo o un conjunto de atributos que identifican de modo nico las tuplas de una relacin. Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relacin. El atributo o conjunto de atributos de la relacin es una clave candidata para si y slo si satisface las siguientes propiedades: Unicidad: nunca hay dos tuplas en la relacin con el mismo valor de .
Irreducibilidad (minimalidad): ningn subconjunto de tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de sin destruir la unicidad. Cuando una clave candidata est formada por ms de un atributo, se dice que es unaclave compuesta. Una relacin puede tener varias claves candidatas. Por ejemplo, en la relacin OFICINA, el atributo Poblacin no es una clave candidata ya que puede haber varias oficinas en una misma poblacin. Sin embargo, ya que la empresa asigna un cdigo nico a cada oficina, el atributo Onum s es una clave candidata de la relacin OFICINA. Tambin son claves candidatas de esta relacin los atributos Telfono y Fax. En la base de datos de la inmobiliaria hay una relacin denominada VISITA que contiene informacin sobre las visitas que los clientes han realizado a los inmuebles. Esta relacin contiene el nmero del cliente Qnum, el nmero del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un
determinado nmero de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un nmero de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relacin VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinacin de los dos atributos s identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habra que incluir el atributo Fecha para identificar las tuplas de modo nico (aunque ste no es el caso de la empresa que nos ocupa). Para identificar las claves candidatas de una relacin no hay que fijarse en un estado o instancia de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia de duplicados en un estado de la base de datos s es til para demostrar que cierta combinacin de atributos no es una clave candidata. El nico modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Slo usando esta informacin semntica se puede saber con certeza si un conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la relacin PLANTILLA se podra pensar que el atributo Apellido es una clave candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos empleados con el mismo apellido, el atributo no es una clave candidata. La clave primaria de un relacin es aquella clave candidata que se escoge para identificar sus tuplas de modo nico. Ya que una relacin no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relacin siempre tiene clave primaria. En el peor caso, la clave primaria estar formada por todos los atributos de la relacin, pero normalmente habr un pequeo subconjunto de los atributos que haga esta funcin. Las claves candidatas que no son escogidas como clave primaria son denominadasclaves alternativas. Por ejemplo, la clave primaria de la relacin OFICINA es el atributo Onum, siendo Telfono y Fax dos claves alternativas. En la relacin VISITA slo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria. Una clave ajena es un atributo o un conjunto de atributos de una relacin cuyos valores coinciden con los valores de la clave primaria de alguna otra relacin (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena
representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla referenciada). Esquema de una base de datos relacional Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de stas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves ajenas. El esquema de la base de datos de la empresa inmobiliaria es el siguiente:
OFICINA PLANTILLA (Onum, Calle, Area, Poblacin, Telfono, Fax) (Enum, Nombre, Apellido, Direccin, Telfono, Puesto, Fecha_nac, Salario, DNI, Onum) INMUEBLE (Inum, Calle, Area, Poblacin, Tipo, Hab, Alquiler, Pnum, Enum, Onum) INQUILINO (Qnum, Nombre, Apellido, Direccin, Telfono, Tipo_pref, Alquiler_max) PROPIETARIO (Pnum, Nombre, Apellido, Direccin, Telfono) VISITA (Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos encerrados entre parntesis. Las claves primarias son los atributos subrayados. Las claves ajenas se representan mediante los siguientes diagramas referenciales.
PLANTILLA OFICINA : Oficina a la que pertenece el empleado.
INMUEBLE PROPIETARIO : Propietario del inmueble. INMUEBLE PLANTILLA INMUEBLE OFICINA : Empleado encargado del inmueble. : Oficina a la que pertenece el inmueble.
VISITA VISITA
INQUILINO INMUEBLE
: Inquilino que ha visitado el inmueble. : Inmueble que ha sido visitado.
A continuacin se muestra un estado (instancia) de la base de datos cuyo esquema se acaba de definir. OFICINA
Onum Calle O5 O7 O3 O4 O2 Enmedio, 8 Area Poblacin Telfono Fax
Centro Castelln 964 201 240 964 201 340
Moyano, s/n Centro Castelln 964 215 760 964 215 670 San Miguel, 1 Trafalgar, 23 Grao Cedre, 26 Villarreal 964 520 250 964 520 255 Castelln 964 284 440 964 284 420 Villarreal 964 525 810 964 252 811
PLANTILLA
39432212 O5 E
EG3 Cubed 964 535 Superviso Pedro Bayarri, 11 24/3/57 7 o 690 r Villarreal EG1 Luis 4 Collad 964 522 Borriol, 35 Administ. 9/5/70 o 230 Villarreal EA9 Rita Renau Casalduch, 964 257 Superviso 19/5/60 32 550 r
18000
38766623 O3 X
12000
24391223 O3 L
18000
39233190 O7 F
Castelln EG5 Julio Prats Melilla, 23 Villarreal EL41 Carlos Baeza Herrero, 51 Castelln 964 247 Superviso 29/2/67 250 r 18000 39552133 O5 T 964 524 Director 590 19/12/50 24000 25644309 O3 X
INMUEBLE
Inum Calle IA14 Enmedio, 128 IL94 Riu Ebre, 24 IG4 Sorell, 5 IG36 Alicante,1 IG21 San Francisco, 10 IG16 Capuchinos, 19 Area Centro Poblacin Tipo Hab Alquiler Pnum Castelln Casa 6 600 350 300 325 550 400 P46 P87 P40 P93 P87 P93
Ronda Sur Castelln Piso 4 Grao Castelln Piso 3 Segorbe Casa 3 Vinaroz Piso 5
Rafalafena Castelln Piso 4
PROPIETARIO
Pnum Nombre Apellido Direccin P46 P87 P40 P93 Amparo Felip Manuel Obiol Asensi 24, Castelln Av. Libertad 15, Vinaroz Telfono 964 230 680 964 450 760
Alberto Estrada Av. del Puerto 52, Castelln 964 200 740 Yolanda Robles Pursima 4, Segorbe 964 710 430
INQUILINO
Qnum Nombre Apellido Direccin Q76 Q56 Q74 Q62 Juan Ana Elena Alicia Felip Barcel 47, Castelln
Telfono
Tipo Alquiler
964 282 540 Piso 375
Grangel San Rafael 45, Almazora 964 551 110 Piso 300 Abaso Navarra 76, Castelln Mori Alloza 45, Castelln 964 205 560 Casa 700 964 229 580 Piso 550
VISITA
Qnum Inum Fecha Q56 Q76 Q56 Q62 Q56 Comentario
IA14 24/11/99 muy pequeo IG4 20/10/99 muy lejos IG4 26/11/99 IA14 14/11/99 no tiene saln IG36 28/10/99
Reglas de integridad Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos. Al definir cada atributo sobre un dominio se impone una restriccin sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denominarestricciones de dominios. Hay adems dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo. Nulos
Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vaca, stos son valores que tienen significado. El nulo implica ausencia de informacin, bien porque al insertar la tupla se desconoca el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido. Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas de implementacin. De hecho, no todos los SGBD relacionales soportan los nulos. Regla de integridad de entidades La primera regla de integridad se aplica a las claves primarias de las relaciones base:ninguno de los atributos que componen la clave primaria puede ser nulo. Por definicin, una clave primaria es un identificador irreducible que se utiliza para identificar de modo nico las tuplas. Que es irreducible significa que ningn subconjunto de la clave primaria sirve para identificar las tuplas de modo nico. Si se permite que parte de la clave primaria sea nula, se est diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad. Ntese que esta regla slo se aplica a las relaciones base y a las claves primarias, no a las claves alternativas. Regla de integridad referencial La segunda regla de integridad se aplica a las claves ajenas: si en una relacin hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos . La regla de integridad referencial se enmarca en trminos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cmo puede evitarse. La cuestin es qu hacer si estando en un estado legal, llega una peticin para realizar una operacin que conduce a un estado ilegal? Existen dos opciones: rechazar la operacin, o bien aceptar la operacin y realizar operaciones adicionales compensatorias que conduzcan a un estado legal. Por lo tanto, para cada clave ajena de la base de datos habr que contestar a tres preguntas: Regla de los nulos: Tiene sentido que la clave ajena acepte nulos?
Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciada por la clave ajena? o Restringir: no se permite borrar la tupla referenciada.
o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena. o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (slo si acepta nulos). Regla de modificacin: Qu ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena? o Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada. o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificacin a las tuplas que la referencian mediante la clave ajena. o Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (slo si acepta nulos). Reglas de negocio Adems de las dos reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones especficas sobre los datos, denominadas reglas de negocio. Por ejemplo, si en una oficina de la empresa inmobiliaria slo puede haber hasta veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debera permitir dar de alta un empleado en una oficina que ya tiene los veinte permitidos. Hoy en da an existen SGBD relacionales que no permiten definir este tipo de restricciones ni las hacen respetar. Lenguajes relacionales La tercera parte de un modelo de datos es la de la manipulacin. Son varios los lenguajes utilizados por los SGBD relacionales para manejar las relaciones. Algunos de ellos son procedurales, lo que quiere decir que el usuario dice al sistema exactamente cmo debe manipular los datos. Otros son no
procedurales, que significa que el usuario dice qu datos necesita, en lugar de decir cmo deben obtenerse. En este apartado se presentan el lgebra relacional y el clculo relacional, definidos por Codd como la base de los lenguajes relacionales. Se puede decir que el lgebra es un lenguaje procedural (de alto nivel), mientras que el clculo relacional es un lenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes: para cada expresin del lgebra, se puede encontrar una expresin equivalente en el clculo, y viceversa. El lgebra relacional (o el clculo relacional) se utilizan para medir la potencia de los lenguajes relacionales. Si un lenguaje permite obtener cualquier relacin que se pueda derivar mediante el lgebra relacional, se dice que es relacionalmente completo. La mayora de los lenguajes relacionales son relacionalmente completos, pero tienen ms potencia que el lgebra o el clculo porque se les han aadido operadores especiales. Tanto el lgebra como el clculo son lenguajes formales no muy "amigables". Pero se deben estudiar porque sirven para ilustrar las operaciones bsicas que todo lenguaje de manejo datos debe ofrecer. Adems, han sido la base para otros lenguajes relacionales de manejo de datos de ms alto nivel. lgebra relacional El lgebra relacional es un lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para obtener otra relacin resultado, sin que cambien las relaciones originales. Tanto los operandos como los resultados son relaciones, por lo que la salida de una operacin puede ser la entrada de otra operacin. Esto permite anidar expresiones del lgebra, del mismo modo que se pueden anidar las expresiones aritmticas. A esta propiedad se le denomina clausura: las relaciones son cerradas bajo el lgebra, del mismo modo que los nmeros son cerrados bajo las operaciones aritmticas. En este apartado se presentan los operadores del lgebra relacional de un modo informal. Las definiciones formales pueden encontrarse en la bibliografa que se comenta al final del captulo. Primero se describen los ocho operadores originalmente propuestos por Codd y despus se estudian algunos operadores adicionales que aaden potencia al lenguaje. De los ocho operadores, slo hay cinco que son fundamentales: restriccin,proyeccin, producto cartesiano, unin y diferencia, que permiten realizar la mayora de las operaciones de obtencin de datos. Los operadores no fundamentales son la concatenacin (join), la interseccin y
la divisin, que se pueden expresar a partir de los cinco operadores fundamentales. La restriccin y la proyeccin son operaciones unarias porque operan sobre una sola relacin. El resto de las operaciones son binarias porque trabajan sobre pares de relaciones. En las definiciones que se presentan a continuacin, se supone que R y S son dos relaciones cuyos atributos son A=(a , a , ..., a ) y B=(b , b , ..., b ) respectivamente. Restriccin : R WHERE condicin La restriccin, tambin denominada seleccin, opera sobre una sola relacin R y da como resultado otra relacin cuyas tuplas son las tuplas de R que satisfacen la condicin especificada. Esta condicin es una comparacin en la que aparece al menos un atributo de R, o una combinacin booleana de varias de estas comparaciones. Ejemplo 4.1 Obtener todos los empleados con un salario anual superior a 15.000 euros. PLANTILLA WHERE salario>15000
39432212 O5 E
EG3 Cubed 964 535 Superviso Pedro Bayarri, 11 24/3/57 7 o 690 r Villarreal EA9 Rita Renau Casalduch, 964 257 Superviso 19/5/60 32 550 r Castelln EG5 Julio Prats Melilla, 23 964 524 Director 590 19/12/50
18000
38766623 O3 X
18000
39233190 O7 F
24000
25644309 O3 X
Villarreal EL41 Carlos Baeza Herrero, 51 Castelln 964 247 Superviso 29/2/67 250 r 18000 39552133 O5 T
Ejemplo 4.2 Obtener todos los inmuebles de Castelln con un alquiler mensual de hasta 350 euros. INMUEBLE WHERE poblacin=`Castelln AND alquiler<=350
Inum Calle Area Poblacin Tipo Hab Alquiler Pnum 350 300 325 P87 P40 P93
IL94 Riu Ebre, 24 Ronda Sur Castelln Piso 4 IG4 Sorell, 5 IG36 Alicante,1 Grao Castelln Piso 3 Segorbe Piso 3
Proyeccin : R[a , ..., a ] La proyeccin opera sobre una sola relacin R y da como resultado otra relacin que contiene un subconjunto vertical de R, extrayendo los valores de los atributos especificados y eliminando duplicados. Ejemplo 4.3 Obtener un listado de empleados mostrando su nmero, nombre, apellido y salario. PLANTILLA [enum,nombre,apellido,salario]
Enum Nombre Apellido Salario EL21 Amelia Pastor 30000 EG37 Pedro EG14 Luis EA9 Rita Cubedo 18000 Collado 12000 Renau 18000
EG5 Julio
Prats
24000 18000
EL41 Carlos Baeza
Ejemplo 4.4 Obtener los distintos puestos que pueden ocupar los empleados. PLANTILLA [puesto]
Puesto Director Supervisor Administ.
Producto cartesiano : R TIMES S El producto cartesiano obtiene una relacin cuyas tuplas estn formadas por la concatenacin de todas las tuplas de R con todas las tuplas de S. La restriccin y la proyeccin son operaciones que permiten extraer informacin de una sola relacin. Habr casos en que sea necesario combinar la informacin de varias relaciones. El producto cartesiano "multiplica" dos relaciones, definiendo una nueva relacin que tiene todos los pares posibles de tuplas de las dos relaciones. Si la relacin R tiene tuplas y atributos y la relacin S tiene tuplas y atributos, la relacin resultado tendr tuplas y atributos. Ya que es posible que haya atributos con el mismo nombre en las dos relaciones, el nombre de la relacin se antepondr al del atributo en este caso para que los nombres de los atributos sigan siendo nicos en la relacin resultado. Ejemplo 4.5 Obtener los nombres de los inquilinos y los comentarios que stos han realizado cuando han visto algn inmueble. INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario]
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario Q76 Juan Felip Q56 IA14 muy pequeo
Q76 Q76 Q76 Q76 Q56 Q56 Q56 Q56 Q56 Q74 Q74 Q74 Q74 Q74 Q62 Q62 Q62 Q62 Q62
Juan Juan Juan Juan Ana Ana Ana Ana Ana Elena Elena Elena Elena Elena Alicia Alicia Alicia Alicia Alicia
Felip Felip Felip Felip
Q76 Q56 Q62 Q56
IG4 muy lejos IG4 IA14 no tiene saln IG36 IA14 muy pequeo IG4 muy lejos IG4 IA14 no tiene saln IG36 IA14 muy pequeo IG4 muy lejos IG4 IA14 no tiene saln IG36 IA14 muy pequeo IG4 muy lejos IG4 IA14 no tiene saln IG36
Grangel Q56 Grangel Q76 Grangel Q56 Grangel Q62 Grangel Q56 Abaso Q56 Abaso Q76 Abaso Q56 Abaso Q62 Abaso Q56 Mori Mori Mori Mori Mori Q56 Q76 Q56 Q62 Q56
Como se puede observar, la relacin resultado contiene ms informacin de la que se necesita. Por ejemplo, la primera tupla tiene distintos nmeros de inquilino: el comentario realizado en la visita no corresponde al inquilino cuyo nombre y apellido se muestra. Para obtener el listado que se pide en el ejemplo, es necesario realizar una restriccin para quedarse solamente con las tuplas en donde INQUILINO.Qnum = VISITA.Qnum.
(INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario]) WHERE inquilino.qnum=visita.qnum El resultado de esta operacin se muestra a continuacin.
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario Q76 Q56 Q56 Q56 Q62 Juan Ana Ana Ana Alicia Felip Q76 IG4 muy lejos IA14 muy pequeo IG4 IG36 IA14 no tiene saln
Grangel Q56 Grangel Q56 Grangel Q56 Mori Q62
La combinacin del producto cartesiano y la restriccin del modo en que se acaba de realizar, se puede reducir a la operacin de concatenacin ( join) que se presenta ms adelante. Unin : R UNION S La unin de dos relaciones R y S, con y tuplas respectivamente, es otra relacin que tiene como mucho tuplas siendo stas las tuplas que se encuentran en R o en S o en ambas relaciones a la vez. Para poder realizar esta operacin, R y S deben ser compatibles para la unin. Se dice que dos relaciones son compatibles para la unin si ambas tienen la misma cabecera, es decir, si tienen el mismo nmero de atributos y stos se encuentran definidos sobre los mismos dominios. En muchas ocasiones ser necesario realizar proyecciones para hacer que dos relaciones sean compatibles para la unin. Ejemplo 4.6 Obtener un listado de las reas en las que hay oficinas o inmuebles para alquilar. OFICINA[rea] UNION INMUEBLE[rea]
Area Centro Grao Ronda Sur Rafalafena
Diferencia : R MINUS S La diferencia obtiene una relacin que tiene las tuplas que se encuentran en R y no se encuentran en S. Para realizar esta operacin, R y S deben ser compatibles para la unin. Ejemplo 4.7 Obtener un listado de todas las poblaciones en donde hay una oficina y no hay inmuebles para alquilar. OFICINA[poblacin] MINUS INMUEBLE[poblacin]
Poblacin Villarreal
Concatenacin (Join) : R JOIN S La concatenacin de dos relaciones R y S obtiene como resultado una relacin cuyas tuplas son todas las tuplas de R concatenadas con todas las tuplas de S que en los atributos comunes (que se llaman igual) tienen los mismos valores. Estos atributos comunes aparecen una sola vez en el resultado. Ejemplo 4.8 Obtener los nombres y los comentarios que los inquilinos han realizado cuando han visto algn inmueble. INQUILINO JOIN VISITA
Esta expresin obtiene el mismo resultado que la expresin final del ejemplo 4.5, ya que la concatenacin es, en realidad, un producto cartesiano y una restriccin de igualdad sobre los atributos comunes. Concatenacin externa (Outer-join) : R JOIN S (+) La concatenacin externa es una concatenacin en la que las tuplas de R que no tienen valores en comn con ninguna tupla de S, tambin aparecen en el resultado. Ejemplo 4.9 Obtener un listado de todos los inmuebles y las visitas que han tenido. INMUEBLE JOIN VISITA (+)
Inum Calle IA14 Enmedio, 128 IA14 Enmedio, 128 IL94 Riu Ebre, 24 IG4 Sorell, 5 IG4 Sorell, 5 IG36 Alicante,1 Poblacin Qnum Fecha Castelln Q56 Castelln Q62 Castelln Castelln Q76 Castelln Q56 Segorbe Q56 20/10/99 muy lejos 26/11/99 28/10/99 Comentario
24/11/99 muy pequeo 14/11/99 no tiene saln
IG21 San Francisco, 10 Vinaroz IG16 Capuchinos, 19

Base de Datos Modelado

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de Datos Modelado

Transféré par

Droits d'auteur :

Formats disponibles

Las bases de datos relacionales son el tipo de bases de datos actualmente ms difundido.

Maria Rossi Gianni Rossi

RESTRICT (Personas) sesso='M'

PROJECT sexo (Personas) sexo M F RESTRICT (Personas) sexo='M'

Mario Rossi Apellido 29/03/1965

3.2 Por qu "modelo relacional" ?

3.3 Conceptos bsicos

As mismo el orden de los atributos tampoco es relevante

Otra representacin de la relacin Pelculas

modelo e-r conversin a tablas

Para el ejemplo de la figura tendramos el esquema:

escuela id url nombre

profesor id nombre extension

estudiante id nombre carrera

profesor_curso id_prof clave_curso seccion_curso

estudiante_curso id_estud clave_curso seccion_curso

3.4.3 Conversin a tablas desde un modelo con generalizacin

La generalizacin se convertira al siguiente esquema: 1)

Mighty 1991 Ducks Wayne's 1992 World Wayne's 1992 World

color color color

Ford Emilio Estevez Dana Carvey

Paramount Mike Meyers

Star Wars 1977 124

color color color color color

Fox Fox Disney Paramount Paramount

Al conjunto de dependencia funcionales de una relacin R se le denominar F.

3.5.1.2 Axiomas de Armstrong:

Reflexividad: sea y entonces Aumentacin: si entonces --> Transitividad: si

3.5.1.3 Reglas adicionales

+, todos los atributos

NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin

La descomposicin se basa bsicamente en:

La intuicin Las dependencias funcionales

Es importante que al descomponer una relacin exista:

Descomposicin sin prdida Preservacin de dependencias funcionales

3.5.4 Descomposicin sin prdida

Para el ejemplo anterior la relacin

X --> A es una dependencia funcional trivial

X es una super llave

Esta ltima en BCNF

X --> A es una dependencia funcional trivial

X es una super llave

No est en 3NF porque:

banker-name --> branch-name office-number

nombre_depto --> extensin, jefe

empleados id_empleado nombre_depto id_jefe

id_empleado --> nombre_depto, id_jefe nombre_depto --> id_jefe

No est en 3NF porque:

nombre_depto --> extensin, jefe empleados id_empleado nombre_depto

id_empleado --> nombre_depto

Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales Para toda dependencia X--> A , X es superllave.

El atributo A es extrao en F lgicamente implica (F - { Ejemplo: F = { A --> C , AB --> C }

es extrao en } - A )+ usando las dependencias en F

+ contiene a A, si lo hace entonces A es extrao

3.5.7.2.2 Algoritmo basado en Fc

BCNF* Descomposicin sin prdida Preservacin de dependencias

1. INTRODUCCIN_____________________________________________________ 56 2. ESTRUCTURA DEL MODELO RELACIONAL____________________________ 57

8. SQL (STRUCTURED QUERY LANGUAGE)_______________________________ 73

2. ESTRUCTURA DEL MODELO RELACIONAL

Atributo 1 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Atributo 2 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

..................... XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Atributo n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 1 Tupla 2 . . Tupla n

1. INTRODUCCIN_________________________ 56 2. ESTRUCTURA DEL MODELO RELACIONAL 57