Tema 1: Conceptos bsicos Contenido:

Introduccin Surgimiento histrico de las bases de datos integradas. Objetivos de los SBD. Arquitectura de un sistema de base de datos. Representacin de la Informacin

Introduccin
El trmino base de datos fue acuado por primera vez en 1963, en un simposio celebrado en California. De forma sencilla podemos indicar que una base de datos no es ms que un conjunto de informacin relacionada que se encuentra agrupada o estructurada. El archivo por s mismo, no constituye una base de datos, sino ms bien la forma en que est organizada la informacin es la que da origen a la base de datos. Las bases de datos manuales, pueden ser difciles de gestionar y modificar. Por ejemplo, en una gua de telfonos no es posible encontrar el nmero de un individuo si no sabemos su apellido, aunque conozcamos su domicilio. Del mismo modo, en un archivo de pacientes en el que la informacin est desordenada por el nombre de los mismos, ser una tarea bastante engorrosa encontrar todos los pacientes que viven en una zona determinada. Los problemas expuestos anteriormente se pueden resolver creando una base de datos informatizada. Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista ms formal, podramos definir una base de datos como un conjunto de datos estructurados, fiables y homogneos, organizados independientemente en mquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de informacin diferente y no predecible en el tiempo.

Surgimiento histrico de las bases de datos integradas.

Al estudiar el desarrollo del procesamiento automatizado de datos, en lo que se refiere al aseguramiento tcnico, se habla de diferentes generaciones. Desde el punto de vista del aseguramiento matemtico y en particular, el aseguramiento de programas, algunos autores reconocen 3 generaciones: a) Solucin de tareas aisladas. b) Integracin de tareas aisladas en sistemas particulares. c) Integracin de sistemas particulares en sistemas automatizados de direccin. Este proceso de integracin ocurre paralelamente, aunque no simultneamente, en dos esferas: a) Integracin de los programas.
1

b) Integracin de los datos. a) Ha estado facilitada por el uso de lenguajes de programacin cada vez ms sofisticados y de redactores que permiten el acoplamiento de mdulos escritos en lenguajes diferentes. b) En la integracin de los datos se han producido tres categoras de tcnicas para su manipulacin:

1- Sistemas orientados a los dispositivos.

Programas y ficheros son diseados y empleados de acuerdo a las caractersticas fsicas de la unidad central y los perifricos. sistemas es imposible prcticamente. Cada programa est altamente interconectado con sus ficheros, por lo que la integracin de datos de diferentes

2- Sistemas orientados a los ficheros.

La lgica de los programas depende de las tcnicas de organizacin de los ficheros (secuencial, directo, etc.). Cada usuario organiza su fichero de acuerdo con sus necesidades y las relaciones entre los elementos se establecen a travs de los programas de aplicacin. Esta forma de trabajo implica redundancia de datos que trae aparejada mayor gasto de memoria y complica las operaciones de actualizacin (modificar un dato donde quiera que aparezca). Esto aumenta el tiempo de tratamiento y atenta contra la integridad de la informacin. Integridad: que en todo momento los datos almacenados estn correctos en correspondencia con la realidad. Adems, en la vida real se establecen relaciones entre los objetos que son muy difciles de representar u obtener a partir de sistemas tradicionales de ficheros. Por ejemplo, si se tiene informacin sobre trabajadores y estudiantes de una facultad, las aplicaciones requeridas van a definir la manera de organizar y estructurar los ficheros. Si se desea obtener datos como: - Calificaciones promedio de cada estudiante. - Listado de estudiantes por grupos. - Categora cientfica y docente de cada profesor. - Salario de cada profesor. Resulta adecuado establecer dos ficheros: uno de profesores y uno de estudiantes. Qu ocurre si se quiere establecer vnculos entre los profesores y estudiantes?
2

Por ejemplo, si se desea obtener: - Los estudiantes de un profesor. - Los profesores de un estudiante. Se estructurara un fichero de profesores y estudiantes que resolvera algunas demandas, pero sera ineficiente para otras. Ser posible representar de manera eficiente, utilizando los medios de cmputo, los fenmenos o procesos de la realidad objetiva, aunque sea por supuesto de forma esquemtica, pero en la que se establezcan determinados vnculos entre los elementos u objetos que forman parte de esos procesos o fenmenos? Veremos que esto es posible hacerlo a travs de la utilizacin de bases de datos (BD) y de los sistemas de gestin de bases de datos (SGBD) que dirigen su manipulacin.

3- Sistemas orientados a BD
En ellos hay una dbil interdependencia entre los programas de aplicacin y la organizacin fsica de los datos. Qu es una base de datos? Definicin: Conjunto de datos interrelacionados entre s, almacenados con carcter ms o menos permanente en la computadora. O sea, que una BD puede considerarse una coleccin de datos variables en el tiempo. El software que permite la utilizacin y/o la actualizacin de los datos almacenados en una (o varias) base(s) de datos por uno o varios usuarios desde diferentes puntos de vista y a la vez, se denomina sistema de gestin de bases de datos (SGBD). Es importante diferenciar los trminos BD y SGBD. El objetivo fundamental de un SGBD consiste en suministrar al usuario las herramientas que le permitan manipular, en trminos abstractos, los datos, o sea, de forma que no le sea necesario conocer el modo de almacenamiento de los datos en la computadora, ni el mtodo de acceso empleado. Los programas de aplicacin operan sobre los datos almacenados en la base utilizando las facilidades que brindan los SGBD, los que, en la mayora de los casos, poseen lenguajes especiales de manipulacin de la informacin que facilitan el trabajo de los usuarios.

Objetivos de los SBD

3

Existen muchas formas de organizar las bases de datos, pero hay un conjunto de objetivos generales que deben cumplir todas los SGBD, de modo que faciliten el proceso de diseo de aplicaciones y que los tratamientos sean ms eficientes y rpidos, dando la mayor flexibilidad posible a los usuarios. Estos objetivos son:

a. Independencia de los datos y los programas de aplicacin.

Ya vimos que con ficheros tradicionales la lgica de la aplicacin contempla la organizacin de los ficheros y el mtodo de acceso. Por ejemplo, si por razones de eficiencia se utiliza un fichero secuencial indexado, el programa de aplicaciones debe considerar la existencia de los ndices y la secuencia del fichero. Entonces es imposible modificar la estructura de almacenamiento o la estrategia de acceso sin afectar el programa de aplicacin (naturalmente, lo que se afecta en el programa son las partes de ste que tratan los ficheros, lo que es ajeno al problema real que el programa de aplicacin necesita resolver. En un SBD sera indeseable la existencia de aplicaciones y datos dependientes entre s, por dos razones fundamentales: 1. Diferentes aplicaciones necesitarn diferentes aspectos de los mismos datos (decimal o binario). 2. Se debe poder modificar la estructura de almacenamiento o el mtodo de acceso segn los cambios en el fenmeno o proceso de la realidad sin necesidad de modificar los programas de aplicacin (tambin para buscar mayor eficiencia). Independencia de los datos: inmunidad de las aplicaciones a los cambios en la estructura de almacenamiento y en la estrategia de acceso, constituye el objetivo fundamental de los SBD.

b. Minimizacin de la redundancia
Habamos visto cmo, con los ficheros tradicionales, se produce redundancia de la informacin. Uno de los objetivos de los SBD es minimizar la redundancia de los datos. Se dice disminuir la redundancia, no eliminarla, pues, aunque se definen las BD como no redundantes, en realidad existe redundancia en un grado no significativo para disminuir el tiempo de acceso a los datos o para simplificar el mtodo de direccionado. Lo que se trata de lograr la eliminacin de la redundancia superflua.

c. Integracin y sincronizacin de las bases de datos

La integracin consiste en garantizar una respuesta a los requerimientos de diferentes aspectos de los mismos datos por diferentes usuarios, de forma que, aunque el sistema almacene la informacin con cierta estructura y cierto tipo de representacin, debe garantizar entregar al programa de aplicacin los datos que solicita y en la forma en que
4

lo solicita. Esta se encuentra vinculada a la sincronizacin, que consiste en la necesidad de garantizar el acceso mltiple y simultneo a la BD, de modo que los datos puedan ser compartidos por diferentes usuarios a la vez. Estn relacionadas, ya que lo usual es que diferentes usuarios trabajen con diferentes enfoques y requieran los mismos datos, pero desde diferentes puntos de vista.

d. Integridad de los datos

Consiste en garantizar la no contradiccin entre los datos almacenados de modo que, en cualquier momento del tiempo, los datos almacenados sean correctos, es decir, que no se detecte inconsistencia entre los datos. Est relacionada con la minimizacin de redundancia, ya que es ms fcil garantizar la integridad si se elimina la redundancia.

e. Seguridad y proteccin de los datos

Proteccin: garantizar el acceso autorizado a los datos, de forma de interrumpir cualquier intento de acceso no autorizado, ya sea por error del usuario o por mala intencin. Seguridad: que el sistema de bases de datos disponga de mtodos que garanticen la restauracin de las BD al producirse alguna falla tcnica, interrupcin de la energa elctrica, etc.

f. Facilidad de manipulacin de la informacin

Los usuarios de una BD pueden referirse a ella con las solicitudes para resolver muchos problemas diferentes. El SBD debe contar con la capacidad de una bsqueda rpida por diferentes criterios, permitir que los usuarios planteen sus demandas de una forma simple, aislndolo de las complejidades del tratamiento de los ficheros y del direccionado de los datos. Los SBD actuales brindan lenguajes de alto nivel con diferentes grados de facilidad para el usuario no programador que garantizan este objetivo, los llamados sublenguajes de datos.

g. Control centralizado
Uno de los objetivos ms importantes de los SBD es garantizar el control centralizado de la informacin, es decir, controlar de manera sistemtica y nica los datos que se almacenan en la BD, as como el acceso a ella. Lo anterior implica que debe existir una persona o conjunto de personas que tenga la responsabilidad de los datos operacionales: el administrador de la BD, que puede considerarse parte integrante del SBD. Entre las tareas del administrador de la BD est: decidir el contenido informativo de la BD decidir la estructura de almacenamiento y la estrategia de acceso garantizar el enlace con los usuarios
5

 definir los chequeos de autorizacin y procedimientos de validacin definir la estrategia de reorganizacin de las BD para aumentar la eficiencia del sistema Existen otros objetivos que deben cumplir los SBD que en muchos casos dependen de las condiciones o requerimientos especficos de utilizacin del sistema.

Arquitectura de un SBD
Presentaremos a continuacin la arquitectura de un SBD, aunque no podemos asegurar que cualquier SBD se corresponda exactamente con ella. Sin embargo, esta arquitectura se corresponde suficientemente bien con un gran nmero se sistemas. Adems, est de acuerdo con la arquitectura propuesta por el grupo ANSI/SPARC. La arquitectura se divide en tres niveles generales: interno, lgico global y externo. NIVEL EXTERNO (Vistas de usuarios individuales)

.... ....

NIVEL LGICO GLOBAL (Vista general)

NIVEL INTERNO (Vista de almacenamiento) El nivel interno es el ms cercano al almacenamiento fsico, o sea, es el relacionado con la forma en que los datos estn realmente almacenados. El nivel externo es el ms cercano a los usuarios, o sea, es el relacionado con la forma en que los datos son vistos por cada usuario individualmente. El nivel lgico global es un nivel intermedio entre los dos anteriores. Existirn varias "vistas externas, siendo cada una representacin ms o menos abstracta de alguna porcin de la BD total y existiendo una nica "vista general", consistente en una representacin tambin abstracta de la BD en su totalidad. Igualmente, existir una nica "vista interna" que representa a la BD completa, tal y como est realmente almacenada. A continuacin estudiaremos con mayor detalle cada uno de los niveles de la arquitectura vista anteriormente y la forma en que ellos interactan.
6

A. El nivel externo
Es el nivel del usuario individual, donde un usuario puede ser bien un programador de aplicacin o un usuario final con cualquier grado de sofisticacin. Cada usuario tiene un lenguaje a su disposicin: - Para el programador, ese lenguaje ser bien un lenguaje sistema, tal como el FoxPro. - Para el usuario final, el lenguaje ser bien un lenguaje de consulta (interrogaciones, query) o un lenguaje de propsito especial, quizs basado en sistemas de menes y construido para satisfacer los requerimientos de un usuario, encontrndose soportado por algn programa de aplicacin en lnea. Es importante sealar que todo lenguaje incluir un sublenguaje de datos, o sea, un subconjunto del lenguaje que trata especficamente con los objetos de la base de datos y sus operaciones. Se dice que el sublenguaje de datos (DSL) est embebido dentro del correspondiente lenguaje husped. Este lenguaje husped es el encargado de asegurar otras facilidades ajenas a la base de datos, tales como variables locales, operaciones de clculo, lgica if-then-else, etc. Un sistema dado, puede soportar mltiples lenguajes husped y mltiples sublenguajes de datos. En principio, cualquier sublenguaje de datos es realmente una combinacin de, al menos, dos lenguajes subordinados: un lenguaje de definicin de datos (DDL), el cual garantiza la definicin o descripcin de los objetos de la base de datos, y un lenguaje de manipulacin de datos (DML), el que garantiza la manipulacin o procesamiento de esos objetos. Ya se ha indicado que un usuario individual estar generalmente interesado slo en cierta porcin de la BD completa. An ms, la vista de esa porcin ser generalmente abstracta cuando se compara con la forma en que los datos estn fsicamente almacenados. El trmino definido por el comit ANSI/SPARC para una vista de un usuario es vista externa, la cual es el contenido de la BD como es vista particular. O sea, para ese usuario, la vista externa es la BD. En general, una vista externa consiste en mltiples ocurrencias de mltiples tipos de artculos externos. Un artculo externo no es necesariamente igual a un artculo almacenado. El sublenguaje de datos del usuario se define en trminos de artculos externos; por ejemplo, una operacin del DML que sea recuperar artculos, recuperar una ocurrencia
7

de programacin

convencional, tal como Pascal o C, o bien un lenguaje de programacin especfico de un

por un usuario en

de artculos externos y no una ocurrencia de artculos almacenados. Cada vista externa se define mediante un esquema externo, consistente, bsicamente, en definiciones de cada uno de los diferentes tipos de artculos externos en esa vista. El esquema externo se escribe usando la porcin del DDL del sublenguaje de datos del usuario, adems tiene que existir una definicin de la correspondencia entre el esquema externo y el esquema lgico global.

B. El nivel lgico global

La vista lgica es una representacin del contenido informativo total de la BD. Es una forma abstracta en comparacin con la forma en que los datos estn almacenados fsicamente. Esta vista puede ser bien diferente de la forma en la que los datos son vistos por un usuario en particular. La vista lgica pretende ser una vista de los datos tal como son, en lugar de cmo los usuarios estn forzados a verlos por las restricciones, digamos, de un lenguaje particular o de un determinado hardware que utilicen. La vista lgica consiste en mltiples ocurrencias de mltiples tipos de artculos lgicos. Por ejemplo, puede ser una coleccin de ocurrencias de artculos de departamentos, ms una coleccin de ocurrencia de artculos de empleados, etc. Un artculo lgico no es necesariamente igual a un artculo externo ni a un artculo almacenado. La vista lgica se define mediante el esquema lgico que incluye las definiciones de cada uno de los diferentes tipos de artculos lgicos. El esquema lgico se describe usando otro lenguaje de definicin de datos: el DDL lgico. Si se desea lograr la independencia de los datos, entonces las definiciones del DDL lgico no deben comprender ninguna consideracin sobre la estructura de almacenamiento ni la estrategia de acceso. Ellas tienen que ser definiciones slo referentes al contenido informativo. Si el esquema lgico logra verdaderamente la independencia de los datos, entonces los esquemas externos que se definen sobre el esquema lgico lograrn tambin, necesariamente, la independencia de los datos. La vista lgica es entonces una vista del contenido total de la BD y el esquema lgico es una definicin de esa vista. Sin embargo, el esquema lgico no es simplemente un conjunto de definiciones como las que se encuentran, por ejemplo, en un programa Pascal. Las definiciones en el esquema lgico deben incluir una gran cantidad de aspectos adicionales, tales como los chequeos de proteccin y los chequeos de integridad. En la mayora de los sistemas actuales, el esquema lgico es realmente slo un poco ms
8

que la simple unin de todos los esquemas externos individuales, posiblemente con la adicin de algunos chequeos simples de proteccin e integridad. Sin embargo, est claro que los sistemas del futuro soportarn un nivel lgico mucho ms sofisticado, que permita tambin describir la forma en que se usan los datos, cmo fluyen de un punto a otro, para qu se usan en cada punto, a qu controles son sometidos, etc.

C. El nivel interno
La vista interna es una representacin de bajo nivel de la BD completa, que consiste en mltiples ocurrencias de mltiples tipos de artculos internos. "Artculo interno" es el trmino definido por ANSI/SPARC para la construccin que hasta ahora hemos llamado artculo almacenado. La vista interna est entonces an a un paso del nivel fsico, ya que ella no opera en trmino de artculos fsicos (tambin llamados pginas o bloques) ni con consideraciones especficas de los equipos, tales como tamaos de sectores o pistas. Bsicamente, la vista interna asume un espacio de direccin lineal infinita. Los detalles de cmo se hace corresponder ese espacio con el almacenamiento fsico son muy especficos de un sistema y deliberadamente se omitieron de la arquitectura. La vista interna se describe mediante el esquema interno, el cual no slo define los diferentes tipos de artculos almacenados, sino que tambin especifica los ndices que existen, la representacin de los campos almacenados, la secuencia fsica en que estn los artculos almacenados, etc. El esquema interno se describe usando otro lenguaje de definicin de datos: el DDL interno. En el esquema presentado de la arquitectura de un SBD, se observan los niveles de correspondencias, una entre los niveles externo y lgico global y otra entre los niveles lgico global e interno. La correspondencia lgica/interna especifica la forma en que los artculos y campos lgicos se representan en el nivel interno. Si se cambia la estructura de la vista interna, o sea, si se hace un cambio en el esquema interno, entonces la correspondencia lgica/interna tiene tambin que cambiar en consecuencia, de modo que el esquema lgico permanezca invariable. En otras palabras, los efectos de estos cambios deben ser aislados por debajo del nivel lgico para que se mantenga la independencia datos. Existe tambin una correspondencia externo/lgica entre cada vista externa particular y la vista lgica. Las diferencias que pueden existir entre estos dos niveles son similares a las que pueden existir entre la vista lgica y la interna. Por ejemplo, los campos pueden tener diferente tipos de datos, se pueden cambiar los nombres de artculos y campos, mltiples campos lgicos pueden ser combinados en un nico campo externo, etc. Puede
9

existir al mismo tiempo cualquier cantidad de vistas externas; cualquier cantidad de usuarios puede compartir una vista externa dada; las diferentes vistas externas se pueden solapar. Algunos sistemas permiten la definicin de una vista externa a partir de otra (mediante una correspondencia externa/externa); esta caracterstica es til cuando varias vista externas estn estrechamente relacionadas entre si. Es importante sealar que en la arquitectura de un sistema de bases de datos tambin es usual que se considere, como parte de ella, al administrador de la base de datos, quien es la persona o grupo de personas responsable del control total de todo el sistema. El SGBD interacta con cada uno de los niveles y las correspondencias entre ellos.

Representacin de la informacin
En el proceso y construccin de todo sistema informativo automatizado, el diseo de la BD ocupa un lugar importante, a tal punto que sta puede verse como un proceso relativamente independiente dentro del diseo del sistema y compuesto por una serie de etapas. Es por ello que resulta de inters el estudio de los problemas relacionados con el diseo de las bases de datos y la modelacin de la informacin. Cuando se habla de informacin, se hace referencia, de forma general, a tres niveles diferentes, tendindose a saltar de uno a otro sin establecer una advertencia previa. 1. El primero de estos niveles es el del MUNDO REAL, en el que existen entidades u objetos, que no son ms que cosas o elementos que existen y estn bien diferenciados entre si, que poseen propiedades y entre los cuales se establecen relaciones. Por ejemplo, una silla es una entidad u objeto, un automvil, un empleado, un profesor, un estudiante, que son cosas concretas; pero tambin puede ser algo no tangible, como un suceso cualquiera, una cuenta de ahorro, o un concepto abstracto. Entre las propiedades que caracterizan a una entidad u objeto pudieran encontrarse el color, el valor monetario, el nombre, etc. De las relaciones entre las entidades u objetos hablaremos ms adelante. La determinacin de cierta entidad u objeto correspondiente a un fenmeno o proceso, est muy relacionada con el nivel de abstraccin en que se est realizando el anlisis. As, por ejemplo, si se estudia el comportamiento de un insecto especifico en determinadas condiciones climticas, las propiedades y relaciones que interesan son de un cierto tipo; sin embargo, si se estuviera realizando un estudio de las diferentes especies de insectos, entonces seran otros los objetos a definir, as como las propiedades que los caracterizaran y las relaciones que se estableceran. Si se estuviera analizando todo el reino animal, seran tambin otros los objetos a definir, con sus
10

caractersticas y propiedades. 2. El segundo nivel es el dominio de las ideas (Sistema Objeto) y es en el que se decide la informacin que debe existir en la BD sobre un fenmeno o proceso del mundo real, o sea, qu informacin debe almacenarse. En este nivel es donde realmente se define el contenido informativo que representar al fenmeno, proceso o ente de la realidad objetiva que se est analizando. De modo que, en este nivel, se definen cules objetos y qu propiedades de stos son representativos y sobre los cuales es necesario almacenar informacin. En este nivel es donde se trabaja con los conceptos ms importantes del modelo de datos, que establecen la relacin entre el mundo real y la informacin almacenada fsicamente en la base de datos: Campo o atributo: es la unidad menor de informacin sobre un objeto (almacenada en la base) y representa una propiedad de un objeto (por ejemplo, el color). Sin embargo, hay que distinguir entre el nombre o tipo del atributo y el valor del atributo, ya que un nombre de atributo puede tomar diferentes valores sobre un cierto conjunto que se denomina dominio. A un valor de un atributo determinado o definido en el dominio dado, en un cierto momento del tiempo, se denomina ocurrencia del atributo. Ejemplo: Atributo Dominio Ocurrencia Color {Azul,Rojo,Verde,...} Rojo Cat_Doc {PT, PA, A, I} A

Ahora bien, una coleccin identificable de campos asociados es un artculo o registro y representa un objeto con sus propiedades. Una vez ms, es imprescindible distinguir entre nombre o tipo de artculo y ocurrencia de artculo. Una ocurrencia de artculo o tuplo o uplo consiste en un grupo de ocurrencias de campos relacionados, representando una asociacin entre ellos. Por ejemplo, tenemos un artculo correspondiente al objeto profesor, en un fenmeno o proceso de la realidad que pretenda representar el comportamiento de una Facultad. El nombre o tipo de artculo puede ser PROFESOR, que est formado por los siguientes tipos de campos o atributos: NUM_IDENT : nmero de identidad del profesor NOM_PROF : nombre del profesor CAT_DOC : categora docente del profesor
11

DPTO

: departamento docente al que pertenece el profesor

Una ocurrencia de este artculo puede ser: 45112801731 Hernndez Juan PA Computacin.

Un fichero o archivo o conjunto de datos puede ser definido como un conjunto de ocurrencias de un mismo tipo de artculo. En la prctica, a menudo interesan las colecciones o conjuntos de objetos similares, necesitndose almacenar la informacin de las mismas propiedades para cada uno de ellos, por ejemplo, el conjunto de profesores de la Facultad. Entonces, una base de datos contendr muchas ocurrencias de cada uno de los tipos de artculos, lo que implica que la base de datos, por supuesto, tambin contendrn muchas ocurrencias de los distintos tipos de atributos. Uno de los momentos cruciales en el diseo de un fenmeno de la realidad objetiva que se concreta en una base de datos es, precisamente, la seleccin de los conjuntos de objetos y sus propiedades. Adems, existe otro concepto muy importante en este nivel, que es el concepto de llave o clave: un atributo o conjunto de atributos de un artculo que define que cada ocurrencia de artculo de la base de datos sea nico. En principio, cada artculo tiene una llave, ya que se tiene como hiptesis que cada elemento u ocurrencia del artculo es diferente de las dems. Por ejemplo, nmero de identidad del trabajador. 3. El tercer nivel es de los datos propiamente dichos, representados mediante cadenas de caracteres o de bits. En este nivel es necesario tener en cuenta la diferencia entre tipo de dato y valor del dato. El tipo de dato corresponde a un atributo o tipo de atributo, que est asociado a un tipo de artculo correspondiente, mientras que el valor corresponde a una ocurrencia del atributo. Sin embargo, una coleccin de bits o caracteres que representa un nico valor de datos y que puede existir independientemente de cualquier informacin que se almacena, adquiere significado slo cuando se le asocia a un tipo de atributo. Se puede, por ejemplo, almacenar permanentemente los valores ROJO, AZUL , VERDE, etc. y asociarlo en un momento determinado a un tipo de atributo a travs de los valores que toma, representando una ocurrencia en un tuplo. Es importante notar que, en general, habr asociaciones o relaciones enlazando las entidades bsicas. Estos enlaces se pueden establecer entre diferentes objetos o tipos de artculos o entre un mismo tipo de artculo. Por ejemplo, cuando se tiene una base de datos
12

formada por dos tipos de objetos: SUMINISTRADOR y PRODUCTO, se puede tener la relacin "CANTIDAD", que establece la cantidad de cada producto que abastece un suministrador dado. Otro ejemplo pudiera ser con el artculo PERSONA, sobre el que se pudiera representar la relacin "SER MADRE DE", que no es ms que una relacin que se establece entre elementos de un mismo tipo de artculo. Es necesario profundizar acerca de los diferentes tipos de relaciones que pueden ocurrir en la prctica.

Relaciones de correspondencia:
Es necesario establecer la correspondencia que existe entre los datos; esta relacin puede ser simple o compleja. Por relacin simple se entiende una correspondencia biunvoca (de uno a uno) entre las ocurrencias de los objetos, o sea, entre los artculos. Si, por ejemplo, los atributos son Nro_Identidad y nombre del profesor la correspondencia entre ellos es simple: a cada nombre corresponde un nmero de identidad y viceversa. Relacin de uno a uno (1:1) Nombre <--------> Nro_Identidad Si los atributos son Nro_identidad y departamento, la relacin es ms complicada, porque a cada departamento corresponden varios empleados. La terminologa corriente expresa que la correspondencia de empleado a departamento es simple (cada empleado es miembro de un nico departamento), mientras que la correspondencia de departamento a empleado es compleja, pues cada departamento tiene, por lo general, muchos empleados. Relacin de uno a muchos (1:M) Nro_Dpto. <------>> Nro_Identidad Hay cuatro tipos de relaciones posibles entre dos tipos de artculos A y B: La correspondencia de A a B puede ser simple y la recproca compleja. La correspondencia de A a B puede ser compleja y la recproca simple. Ambas correspondencias pueden ser complejas o ambas pueden ser simples, es decir. A <<-----> B A <<----->> B A <----->> B A <-----> B

Un ejemplo donde ambas correspondencias son complejas, lo es la relacin que se

13

establece entre PROFESOR y ESTUDIANTE por la imparticin de clases, ya que un profesor puede impartir clases a varios estudiantes, pero, a su vez, un estudiante puede recibir clases de varios profesores: Relacin de muchos a muchos (N:M) PROFESOR <<----->> ESTUDIANTE Las relaciones pueden tener diferentes caractersticas: Aunque la mayora de las relaciones asocian dos tipos de entidades, ste no es

siempre el caso. Por ejemplo, PROFESOR_HORARIO_ESTUDIANTE. Esto podra representar el hecho de que un profesor imparte clases a una cierta hora a un cierto estudiante. Esto no es lo mismo que la combinacin PROFESOR_HORARIO y HORARIO_ESTUDIANTE, ya que la informacin de que "el profesor P5 imparte clases en el horario H1 al estudiante E4" dice ms que la combinacin "el profesor P5 imparte clases en el horario H1" y "el estudiante E4 recibe clases en el horario H1"

Las relaciones pueden establecerse entre un mismo tipo de entidad. Por

ejemplo, una asociacin entre un profesor y otro puede venir dada por el hecho de que un profesor sea el jefe de otros profesores. Es importante sealar que una asociacin entre entidades puede ser considerada

en s como una entidad, ya que una relacin se puede ver como un objeto bien diferenciado sobre el cual se desea almacenar informacin. Entonces, un modelo de datos no es ms que la representacin de un fenmeno de la realidad objetiva a travs de los objetos, sus propiedades y las relaciones que se establecen entre ellos.

14

Tema 2: El modelo relacional

Relacin El Modelo Relacional y sus componentes Caractersticas del Modelo Conceptual. Modelo Entidad-Relacin y su representacin grfica. Operaciones sobre los objetos bsicos del Modelo Entidad-

Caractersticas del Modelo Conceptual

El proceso de diseo de la BD transita a travs de una serie de pasos en los cuales se va avanzando de un nivel de abstraccin menor a otro ms profundo, mediante la elaboracin de una sucesin de modelos. En los ltimos aos se ha generalizado la concepcin del diseo de las BD propuestas por el grupo ANSI/SPARC, la cual constituye, al mismo tiempo, una arquitectura para los SBD, tal y como la acabamos de estudiar. Hemos visto en esta arquitectura que cada nivel de la misma es una cierta forma de representacin abstracta de la informacin y una de las funciones ms importantes del SGBD consiste precisamente en permitirle al usuario la interaccin con los datos en estos trminos abstractos, en lugar de tenerlo que hacer directamente con la forma en que esos datos estn fsicamente almacenados. Es por ello que, al acometerse la tarea de diseo de una BD, la atencin se debe centrar en el aspecto lgico de la informacin, ya que los detalles relacionados con el almacenamiento fsico son parte de todo SGBD comercial que se utilice, y por tanto, no pueden ser modificados. Los SGBD existentes utilizan diferentes modelos de datos para la representacin en el nivel lgico global. Son comunes a todos ellos las siguientes caractersticas: 1. La representacin de la informacin se basa en el uso de de datos que poseen una capacidad semntico: el tipo de proyeccin (1 : 1 , 1 : N , N : M ). 2. Utilizan una terminologa que no es familiar al usuario del dificultan la comunicacin usuario-diseador. Adems, cada uno de estos modelos est vinculado con un tipo particular de SGBD. Por todo ello, es necesario tratar con otro tipo de modelo cuando se aborda el problema del diseo de las BD, el cual debe superar los problemas anteriores y constituye un nivel de abstraccin intermedio entre la realidad informativa y el nivel lgico global de la arquitectura. A este nuevo tipo de modelo se le denomina modelo conceptual. O sea, el modelo conceptual se define exteriormente al SGBD, realizndose manualmente la transformacin entre el modelo conceptual y el lgico global.
16

determinadas estructuras

descriptiva limitada (slo diferencian un rasgo sistema, por lo que

....

Nivel Externo

Nivel Lgico Global

SGBD

Modelo Conceptual Diseador de la BD

Nivel Interno El proceso de modelacin conceptual es denominado tambin modelacin semntica, ya que con estos modelos se pretende reflejar en mayor medida la semntica, el significado de los datos y sus interrelaciones.

El Modelo Entidad-Relacin (MER)

Este modelo fue propuesto en 1976 y ha encontrado una amplia aceptacin como instrumento para modelar el mundo real en el proceso de diseo de las bases de datos. El MER opera con los conceptos de entidad y relacin que vimos anteriormente. Las entidades ( ocurrencia de entidades) se clasifican en distintos conjuntos entidades ( entidades). Ejemplos: "empleado", "departamento", etc. Existir un predicado asociado con cada conjunto entidad (entidad ) que permitir comparar si una entidad arbitraria pertenece a un conjunto dado. Las entidades pueden pertenecer a ms de un conjunto, o sea, los conjuntos entidad no son mutuamente disjuntos. Por ejemplo: Una entidad del conjunto "mujeres" tambin pertenece al conjunto "personas". Un conjunto relacin es una relacin matemtica entre n entidades. { (e1, e2, ....en) | e1 E1, e2 E2, ...., en En } y cada tuplo ( e1, e2, ....en) es una relacin, donde las Ei y ei no tienen que ser necesariamente diferentes. El rol de una entidad en una relacin expresa la funcin que desempea dicha entidad en la relacin. En el conjunto de relacin "matrimonio" definido entre entidades del conjunto "personas", o sea "matrimonio" { [e1, e2] | e1 "persona", el segundo, en el rol de "esposa". Informacin adicional sobre una entidad (adems de los predicados y las relaciones) se obtiene mediante un conjunto de pares atributo-valor ( atributo ) asociados con la entidad. Ejemplos de valores son "rojo", "3", "Juan", etc. y ellos se clasifican en conjuntos valor mutuamente disjuntos, tales como "color", "edad", etc. Un valor de un conjunto puede ser equivalente a otro valor en un conjunto diferente. Por ejemplo, "100" en el conjunto valor "centmetros" es equivalente a "1" en el conjunto valor "metro". Un atributo se define en el MER como una funcin matemtica que establece una
17

e2 "persona" }, el primer elemento en el tuplo puede aparecer en el rol de "esposo" y

correspondencia desde un conjunto entidad o conjunto relacin hacia un conjunto valor o un producto cartesiano de conjuntos valor: atrib1: Ei ---> Vi1 x Vi2 x .....x Vin atrib2: Ri ---> Vi1 x Vi2 x .....x Vin En la figura siguiente se muestran los atributos definidos en el conjunto entidad (entidad) EMPRESA. El atributo NOMBRE hace corresponder a las entidades empresas (ocurrencias de empresa) con elementos del conjunto valor (dominio) NOMBRE DE EMPRESA. El atributo DIRECCIN establece una correspondencia desde el conjunto entidad (entidad ) EMPRESA hacia el par de conjuntos valor NOMBRE DE CIUDAD, NOMBRE DE CALLE. INGRESO Y EFECTIVO establecen ambos una correspondencia desde el conjunto entidad (entidad) EMPRESA hacia el conjunto valor VALOR MONETARIO. Ntese que un atributo se define siempre como una funcin, por lo que siempre hace corresponder a una entidad dada (ocurrencia) con un nico valor de una tupla, pues se define un producto cartesiano de conjuntos valor (dominios). CONJUNTO ENTIDAD ATRIBUTOS
NOMBRE NOMBRE DE EMPRESA CEDICO NOMBRE DE CIUDAD INGRESO La Habana NOMBRE DE CALLE EFECTIV OO Ave 26 VALOR MONETARIO 35 200 2 500

CONJUNTO DE VALORES

DIRECCION

e ii

Las relaciones pueden tambin tener atributos. En la figura siguiente, el atributo CONJUNTO CONJUNTO ATRIBUTOS UTILIZACIN define el nmero de horas que un obrero especfico ej usa una mquina CONJUNTO ENTIDAD RELACION DE VALORES ei y constituye un atributo de la relacin correspondiente. El no es ni un atributo del
MAQUINA

OBRERO ni de la MAQUINA, ya que su significado depende de la relacin entre ellos ei dos.

OBRERO UTILIZACIO N HORAS 18

r[ei, ej]

ej

25

Es importante destacar las siguientes caractersticas de los atributos en este modelo: 1. Los atributos slo son correspondencias funcionales. As, por ejemplo, si tenemos el conjunto entidad (entidad ) AUTOMVIL y el atributo COLOR, el hecho de que un auto pueda tener ms de un color no se puede representar como un atributo en este modelo. 2. El nico hecho que puede ser registrado sobre los valores en este modelo es su pertenencia a un conjunto valor. Si se desea representar otra propiedad, el valor tiene que ser convertido en una entidad. Por ejemplo, si queremos registrar la longitud de onda de cada color no podemos hacerlo en el MER, sino convirtiendo el conjunto de valores COLOR en un conjunto entidad (entidad ).

Representacin grfica del MER

El MER tiene asociada una representacin grfica denominada Diagrama EntidadRelacin (DER). En un DER, cada entidad se representa mediante un rectngulo, cada relacin mediante un rombo y cada dominio mediante un crculo. Mediante lneas se conectan las entidades con las relaciones, igual que las entidades con los dominios, representando a los atributos. Los atributos llaves se representan subrayando el correspondiente conjunto de valores. En ocasiones, una entidad no puede ser identificada nicamente por el valor de sus propios atributos. En estos casos, se utilizan conjuntamente las relaciones con los atributos para lograr la requerida identificacin unvoca. Estas entidades reciben el nombre de entidades dbiles y se representan en el DER con un doble rectngulo. El MER restringe las relaciones a usar para identificar las entidades dbiles a relaciones binarias del tipo 1:n. As, por ejemplo, una ocurrencia de "trabajador" puede tener n ocurrencias "persona-dependiente" asociadas, donde adems, la existencia de las ocurrencias en la segunda entidad depende de la existencia de una ocurrencia que le
19

corresponda en la primera entidad. Por ejemplo, en el modelo habr personas dependientes de un trabajador slo si ese trabajador existe. Para indicar esa dependencia en la existencia se usa una saeta en el DER. La llave de una entidad dbil se forma combinando la llave de la entidad regular que la determina con algn otro atributo que defina unvocamente cada entidad dbil asociada a una entidad regular dada. (Una entidad se denomina regular si no es dbil). En una relacin, la llave es la combinacin de las llaves de todas las entidades asociadas. Para cada relacin se determina su tipo (simple o complejo) y en el DER se escribe el tipo de correspondencia. Por ejemplo, una empresa puede tener varios (n) trabajadores asociados y un trabajador pertenece a una sola empresa (1). En la relacin Trabajador-Mquina-Pieza, un trabajador puede trabajar en n mquinas, produciendo p piezas, o una pieza puede ser producida por m trabajadores en n mquinas. Aqu, m, n y p no identifican un nmero especfico, sino solamente el tipo de correspondencia que se establece en la relacin.

20

Nombrede empresa

Valormonetario Presupuesto EMPRESA Horas 1

Num-id Empresatrabajador Nombrespropios Nombre Apellidos Salario Valormonetario Calificacin Trab-Persdep n PIEZA Precio PERSONADEPENDIENTE Nombre Edad No.Pieza Valormonetario n TRABAJADOR 1 trab-maqpieza p m n m trab-maq n

#-mquina

MAQUINA

Valor Valormonetario

Cantidad Nmero

Nombre-mquina

Nombrespropios

Aos

21

Operaciones sobre los objetos bsicos del MER

Es posible extender la capacidad semntica del MER aplicando sobre sus objetos bsicos ( entidad y relacin ) diferentes operaciones: 1. Agregacin: Construye una nueva entidad sobre la base de una relacin. 2. Generalizacin: Permite formar una nueva entidad, mediante la unin de otras entidades. El proceso inverso se denomina especializacin y divide una entidad en cierto nmero de otras entidades. 3. Agrupamiento: Define una nueva entidad, donde cada ocurrencias de la entidad fuente. A las entidades, relaciones y conjuntos definidos hasta ahora les llamaremos tipos bsicos para distinguirlos de los nuevos tipos de datos que se obtendrn con las operaciones anteriores. Veamos cada una de las operaciones: 1. Generalizacin / Especializacin Si T1, T2, ....Tn son conjuntos entidad (que pueden a su vez ser resultado de una generalizacin), la generalizacin define un nuevo conjunto entidad T con el sgte. significado: T = { t | t Ti , 1 i n} o sea, existe para cada entidad ( ocurrencia ) t en T al menos un conjunto Ti que contiene a esa entidad (ocurrencia). Por ejemplo, en el DER anterior, puede ser necesario distinguir los trabajadores de una empresa de acuerdo a su ocupacin como obreros, dirigentes y administrativos. Esto no puede ser representado en el modelo anterior y slo a travs del hecho de que el conjunto entidad (entidad) "obrero", por ejemplo, es siempre (o sea, en todo momento) un subconjunto del conjunto entidad ( entidad ) "trabajador", podemos deducir cierta clase de dependencia entre los dos tipos. Usando la generalizacin podemos obtener un nuevo diagrama como se muestra parcialmente en la figura siguiente:
Num-id

ocurrencia es un grupo de

TRABAJADOR

ADMINISTRATIVO

DIRIGENTE

Tipo deTrabajo
OBRERO

22

Ntese que hemos introducido un nuevo par adicional atributo-valor ( atributo ) para el conjunto trabajador. Este atributo nos permite distinguir entre los miembros de diferentes clases de trabajadores. Si tenemos un conjunto entidad ( entidad ) TRABAJADOR y queremos usar la operacin de Especializacin como inversa a la generalizacin, tenemos que especificar "roles" en el modelo, o sea, reglas que definan cundo una entidad (ocurrencia ) TRABAJADOR pertenece a uno u otro componente del conjunto entidad (entidad ). Entonces la representacin de esta operacin en el DER se generaliza como se muestra en la figura siguiente:

TRABAJADOR Tipo de trabajo=1

Tipo de trabajo=2

Tipo de trabajo=3

ADMINISTRATIVO

DIRIGENTE

OBRERO

Si por cada entidad Trabajador nosotros podemos siempre deducir a cul conjunto entidad componente pertenece usando alguna propiedad ya representada, entonces no es necesario introducir un nuevo par atributo-valor ( atributo ) Tipo de Trabajo. Las reglas que definen la especializacin de un conjunto entidad (entidad ) se denominan "caracterizaciones". Por ejemplo, Tipo de Trabajo = 1 es la caracterizacin del conjunto entidad (entidad) Administrativo dentro del conjunto entidad (entidad) Trabajador. En una Generalizacin / Especializacin, los atributos y relaciones del conjunto entidad "generalizado" (entidad generalizada) son heredados por los conjuntos entidad componentes (entidades especializadas). Adems, se pueden definir nuevos atributos y relaciones para cada conjunto entidad especializada. Por ejemplo, la relacin ObreroMquina se define ahora slo para la entidad especializada Obrero, componente de la
23

entidad generalizada Trabajador:

Num-id TRABAJADOR

ADMINISTRATIVO

DIRIGENTE

TipodeTrabajo
OBRERO

m Obr-Maq

MAQUINA

TrabDep

. .

2. Agregacin
Obsrvese en el ejemplo que representa la situacin de la produccin en las empresas, que la relacin ternaria Trab-Mq-Pieza representa la idea de que una actividad en la empresa se describe en trminos de "un obrero en alguna mquina produce una pieza dada en alguna cantidad especfica". Sin embargo, la misma situacin puede ser vista de forma algo diferente. En la empresa las mquinas pueden estar asignadas a los obreros y estos "equipos", producir piezas en cierta cantidad. En el MER original esta situacin no hubiera podido ser modelada correctamente, ya que una relacin no puede relacionarse con otra relacin o entidad. Con la operacin de Agregacin esta situacin se resuelve fcilmente, tal y como se muestra en la figura siguiente:

EQUIPO m

OBRERO

Obrero-maq

MAQUINA

1 Nmero 24

EquipoPieza

Cantidad

p PIEZA

La agregacin se define de la siguiente forma: Si T1, T2,....Tn son conjuntos entidad (entidad), la operacin define un nuevo conjunto entidad (entidad) T con el significado siguiente. T = {t | t1, t2,....TN (t1 T1

t2 T2... ten <t1, t2,TN> = t)}

O sea, las nuevas entidades (ocurrencias) se forman como duplas de entidades (ocurrencias) a partir de los conjuntos entidad (entidades ) componentes. Para que la operacin tenga sentido, los conjuntos entidad ( entidades ) T1,T2,...Tn tienen que formar parte en alguna relacin comn y esa relacin siempre ser incluida en la representacin del conjunto entidad (entidad) generado. Al nuevo conjunto entidad (entidad ) se le pueden asignar atributos. Tambin puede tomar parte en cualquier relacin. Otro ejemplo de Agregacin se muestra a continuacin:
ENVIO SuministradorPieza-Proyecto Fecha del envo Fecha

m
SUMINISTRADOR

n p
PIEZA PROYECTO

Cantidad Enviada Nmero

El nuevo conjunto entidad (entidad) ENVO se define como una agregacin de tres conjuntos entidad ( entidades ): Suministrador, Pieza y Proyecto con los nuevos atributos Fecha de envo y Cantidad enviada. Hay una diferencia importante entre estos dos atributos: Esta claro que la Fecha de envo no puede pertenecer a ninguno de los conjuntos entidad (entidad) componentes, sin embargo, la Cantidad enviada se refiere
25

claramente a las piezas. Diremos entonces, que la Cantidad enviada es una "caracterizacin" del conjunto entidad (entidad) PIEZA con respecto al ENVO. 3. Agrupamiento Si T designa a algn conjunto entidad (entidad) y T1, T2 ...Tn son bien conjuntos valor (dominios) asociados con T o conjuntos entidad (entidades) relacionados con T va alguna relacin, entonces el operador de Agrupamiento construye un nuevo conjunto entidad agrupado ( entidad agrupada o agrupamiento) Tg donde cada elemento es un conjunto de entidades (ocurrencias) de T, tales que, dentro de cada uno de tales conjuntos, todas las entidades (ocurrencias) tienen los mismos valores y entidades relacionadas desde los conjuntos entidad (entidad) T1, T2,..Tn asociados. Los tipos T1, T2,...Tn se llamarn tipos ndice y T se llamar base. Por ejemplo, podemos usar el par Salario-Valor Monetario del DER anterior para formar un conjunto entidad (entidad) agrupado a partir del conjunto entidad Trabajador. Cada entidad (ocurrencia) Trabajador dentro de un grupo, que representa a una entidad (ocurrencia) en Trabajadores de igual salario, tiene el mismo valor del salario.
Trabajadores de igual salario

SALARIO

TRABAJADOR

Para el MER, incluyendo las tres operaciones estudiadas pueden plantearse una serie de restricciones de integridad: 1. Al aplicar la generalizacin/especializacin, una entidad puede pertenecer a una jerarqua de diferentes conjuntos entidad ( entidades ). Por ejemplo, los conjuntos entidad (entidades) PERSONA, TRABAJADOR, OBRERO forman una jerarqua de conjuntos (entidades) sucesivamente ms especializados. Entonces, una entidad existente en un nivel dado, tiene que existir en todos los niveles superiores. De forma inversa, si una entidad se elimina de un conjunto en un nivel i, debe ser eliminada tambin en los niveles ms bajos. 2. La agregacin constituye un conjunto entidad (entidad agregada) sobre la base de una relacin, por lo que dicho conjunto se comportar de forma similar a como se comporta la relacin. Entonces, para que el conjunto agregado exista, deben existir
26

todos los conjuntos entidad (entidades) que toman parte en la relacin. Lo inverso no tiene que ocurrir necesariamente, ya que, por ejemplo, en el caso visto del ENVO, pueden existir suministradores que no abastezcan a ningn proyecto, sino que se registran como tales porque en determinado momento pudieran estar activos. Desde luego, si la poltica de la organizacin es tal que un suministrador se considera como tal slo si realmente suministra piezas a algn proyecto, entonces la existencia de la entidad agregacin ENVO es indispensable para la existencia del conjunto entidad SUMINISTRADOR. 3. Al aplicar el agrupamiento, por lo general la existencia de todos los componentes del conjunto. ndice es necesaria para que exista la entidad agrupada. Por otra parte la base es indispensable slo en el sentido de que para que exista cada entidad agrupada en el conj. de entidad obtenido. al menos tiene que existir una entidad en la base. Lo inverso no se requiere, o sea, no es necesario que cada entidad en el conjunto base sea miembro de alguna entidad en el conjunto agrupado.

EL Modelo Relacional y sus Componentes

Uno de los modelos matemticos ms importantes, actuales y con mayores perspectivas para la representacin de las bases de datos, es el enfoque relacional. Este se basa en la teora matemtica de las relaciones, suministrndose con ello una fundamentacin terica que permite aplicar todos los resultados de dicha teora a problemas tales como el diseo de sublenguajes de datos y otros.

Componente Estructural del Modelo Relacional

La nica componente estructural del modelo relacional es la relacin o tabla. El trmino relacin se puede definir matemticamente como sigue:

Definicin: Relacin
Dados los conjuntos de dominios D1, D2, .....Dn (no necesariamente distintos), R es una relacin sobre esos n conjuntos si est constituida por un conjunto de ntuplos ordenados d1,d2,...dn tales que d1 D1, d2 D2, ..., dn Dn. Los conjuntos D1, D2, ....Dn se llaman dominios de R y n constituye el grado de la relacin. Las relaciones son representadas mediante tablas bidimensionales donde cada fila representa un n-tuplo o articulo y cada columna un atributo o campo. COLUMNAS . . . . . .

(atributos o Campos)
FILAS

(artculos o tuplos)
27

. . .

En el modelo relacional, tanto los objetos o entidades, como las relaciones que se establecen entre ellos, se representan a travs de las "tablas", que en la terminologa relacional se denominan relaciones. Cada relacin est compuesta de filas (las ocurrencias de las entidades ) y se les denomina, en la terminologa relacional, como tuplos o uplos (en realidad, n-tuplos, pero en muchos casos se suprime la n cuando no existe posibilidad de confusin). Tambin la relacin est compuesta por columnas (los atributos o campos) que toman valores en sus respectivos dominios. Denotndose la relacin por: R ( D1, D2, D3, . Dn). Entonces se tendr que: R ( D1, D2, D3, . Dn) = { (d1, d2, .., dn) | d1 D1 , d2 D2 , , dn Dn } Cada valor dentro de la relacin (cada valor de un atributo) es un dato atmico (o elemental), es decir, no descomponible; por ejemplo: un nmero, una cadena de caracteres. En otras palabras, en cada posicin (fila, columna) existe un solo valor, nunca un conjunto de valores. Propiedades de una Relacin Grado.- Cantidad de dominios en que esta definida la relacin. Esquema.- Lo compone el nombre de la relacin y el de sus atributos. Ejemplo: Trabajadores ( CI, Edad, Sexo, Ecivil) Intensin.- Compuesto por el Esquema ms un conjunto de Predicados, que nos permite determinar cuando un tuplo pertenece o no a la relacin. Ejemplo: Estudiantes ( {CI, Edad }, { Matriculados en Nivel Superior}) La intensin es una propiedad esttica de la relacin. Extensin.- Cantidad de tuplos que pertenecen a la relacin en un tiempo t. La extensin es una propiedad dinmica de la relacin. Llave Candidata.- K es una llave candidata de la relacin R ( D1, D2, Dn } , si y slo si: 1. K { D 1. , D 2 , .. D n } 1. Permite identificar sin ambigedad a cada tuplo de la relacin, es decir sea nica, o sea no podr existir dos tuplos de R con igual
28

valor de K. Esto se expresa: K

2.

Di

Sea minimal, es decir, no existe K1 K que cumpla 1. Nota: Aquellos K que slo cumplen 1 se le denominan Sper

LLave Llave Primaria.- Es aquella llave candidata que sea tomada como llave de la relacin. Toda relacin tendr al menos una llave candidata { D1, D2, Dn} Orden. El orden de las filas no es significativo. El orden de las columnas no es significativo. Siendo rigurosos, el orden de las columnas s es significativo, pues representa el orden de los dominios implicados, pero como siempre nos referimos a una columna por su nombre y nunca por su posicin relativa.

Componentes restrictivos del modelo relacional

1. Toda Relacin tiene una llave primaria, la que sus valores no pueden estar indefinidos, ni ser repetitivos. Este tipo de integridad del Modelo Relacional se denomina Integridad de Entidades.
2.

Donde quiera que aparezca un atributo (o combinacin de ellos) en una relacin R2 , cuyos valores casen con la llave primaria de una relacin R1 , entonces cada valor de esos atributos d de R2 tiene que ser igual al valor de la llave primaria en alguna tupla de R1. Este tipo de integridad del Modelo Relacional es llamado Integridad Referencial.

Ejemplo: Veamos cmo nuestro ejemplo de Suministrador y Producto puede ser representado fcil y claramente mediante el modelo relacional. Suministrador ( NSuministrador, Nombre, Tipo, Municipio) Producto ( NProducto, Nombre, Precio Unitario, Peso) Se conoce la cantidad de un determinado producto que suministra un suministrador dado. SNUM S1 S2 S3 S4 S5 SUMINISTRADOR SNOM TIPO PREZ RAMOS ARENAS VALLE LPEZ 30 10 20 20 15 MUN CERRO PLAZA CERRO PLAYA PLAYA

29

PRODUCTO
PNUM P1 P2 P3 P4 P5 P6 PNOM CLAVO TUERCA MARTILO TORNILLO ALICATE SERRUCHO PRECIO 0.10 0.15 3.50 0.20 2.00 4.00 PESO 12 17 80 10 50 90 S S1 S1 S1 S1 S1 S1 S2 S2 S3 S3 S4 S4 S4

SP
P P1 P2 P3 P4 P5 P6 P1 P2 P3 P5 P2 P4 P5 CANT 3 2 4 2 1 1 3 4 4 2 2 3 4

Con estas 3 tablas se tiene todo el modelo representado. Una de la principales ventajas del Modelo Relacional es su simplicidad, pues el usuario formula sus demandas en trminos del contenido informativo de la Base Datos, sin tener que atender a las complejidades de la realizacin del sistema, lo que implica gran independencia de los datos. - La informacin se maneja en forma de tablas, lo que constituye una manera familiar de representarla. Veamos en el modelo del SUMINISTRADOR-PRODUCTO visto anteriormente un ejemplo de cada tipo de operacin de actualizacin: Insercin: Aadir un producto P7, se agregara una nueva ocurrencia en la tabla PRODUCTO. Lo cual ser posible hacerlo aunque ningn suministrador lo suministre. Supresin: Se puede eliminar el suministrador S1 sin perder el producto P6, a pesar de que es el nico suministrador que lo suministra sea S1.
30

Modificacin: Se puede cambiar el precio del producto P2 sin necesidad de bsquedas adicionales ni posibles inconsistencias.

La Desventajas del Modelo Relacional

consiste en la dificultad de lograr

productividad adecuada de los sistemas, ya que no se fabrican los medios tcnicos idneos, tales como las memorias asociativas, siendo necesario simular este proceso, pero, en realidad, la eficiencia y productividad de los sistemas actuales resultan realmente satisfactorias. Ejemplo de SGBD relacionales Query By Example (QBE)(IBM) dBase, DataEase, FoxPro, Visual FoxPro, Clipper, Informix , MSAccess (micros)

Componentes Operacionales del Modelo Relacional.

En el modelo relacional el resultado de una demanda es tambin una relacin. Slo tiene que indicar qu relacin desea recuperar. Las diversas formas de hacer las recuperaciones dan lugar a los lenguajes relacionales cuyas formas ms representativas son:

lgebra relacional (basado en las operaciones del lgebra de relaciones). Clculo relacional ( basado en el clculo de predicados)

El lgebra Relacional y sus operadores.

Cada operador del lgebra relacional toma una o dos relaciones como entrada y produce una nueva relacin como salida. Originalmente se definen ocho operadores.

Las operadores tradicionales conocidos de la teora de conjuntos: unin, Las operadores relacionales especiales: seleccin, proyeccin,

interseccin, diferencia y producto cartesiano.

concatenacin y divisin. Para simplificar la discusin de cada una de estas operaciones, asumiremos que el orden de izquierda a derecha de los atributos dentro de una relacin es significativo. Adems, asumiremos que un atributo de una relacin puede tener siempre un nombre calificado, o sea, si R es el nombre de relacin y A es de un atributo dentro de R, entonces ste puede ser referenciado con el nombre calificado de R.A.
31

A.- Operadores tradicionales

Sean R1 y R2 dos relaciones 1. UNION ( Operador Binario Bsico) R1 UNION R2 es una nueva relacin T cuyas tuplas pertenecen a la relacin R1 o a la R2 o a ambas, es decir, R1 R2 = { t | t R1 t R2 } Nota: R1 y R2 tienen que tener el mismo grado y el i-simo atributo ( 1 i n ) de cada relacin tiene que estar definido sobre el mismo dominio. Externos No Nombre Edad Estudiante 1 Carlos 16 2 Luis 23 Ao 2 3 Becados No Nombre Edad Estudiante 3 Heribert 19 o 4 Teresa 21 5 Pedro 22 6 Sandra 20 Ao 2 2 4 5

T = Estudiantes = Externos
No Estudiante 1 2 3 4 5 6

Becados
Edad 16 23 19 21 22 20 Ao 1 3 2 2 4 5

Nombre Carlos Luis Heriberto Teresa Pedro Sandra

Numero de Elementos = Numero de elementos de R1 + Numero de Elementos de R2 - Numero de elementos Comunes a R1 y R2 2.- DIFERENCIA ( Operador Binario Bsico) R1 MENOS R2 es una nueva relacin T en que sus tuplas pertenecen a la relacin R1 y no a la R2, es decir: R1 - R2 = { t | t R1 t R2 } Ejemplo: Estudiantes Becados No Estudiante 3 4 5 6 Nombre Heriberto Teresa Pedro Sandra

32

Estudiantes de 2do Ao No Nombre Estudiantes 1 Carlos 3 Heriberto 4 Teresa Entonces: T = Estudiantes Becados que no son de 2do Ao = Estudiantes Becados - Estudiantes de 2do Ao No Nombre Estudiante 5 Pedro 6 Sandra

No Elementos T

= No de Elementos - No de Elementos R1 Comunes

3.- INTERSECCION ( Operador Binario no bsico) R1 INTERSECCION R2 es una nueva relacin T cuyas tuplas pertenecen a la relaciones R1 y R2, es decir, R1

R2 = { t | t R1 t R2 }

Nota: R1 y R2 tienen que tener el mismo grado y el i-simo atributo ( 1 i n ) de cada relacin tiene que estar definido sobre el mismo dominio. Ejemplo: Estudiantes Becados No Estudiante 3 4 5 6 Nombre Heriberto Teresa Pedro Sandra

Estudiantes de 2do Ao No Estudiante 1 3 4 Nombre Carlos Heriberto Teresa

33

Entonces T = Estudiantes becados de 2do Ao = Estudiantes Becados Estudiantes 2do Ao No Nombre Estudiante 3 Heriberto 4 Teresa

La operacin de Interseccin se deriva de la operacin de diferencia como sigue: A

B = A - ( A - B)

de ah que sea una operacin no bsica, le proponemos la comprobacin de dicha igualdad. No de Elementos de T = No de Elementos Comunes . 4.- PRODUCTO CARTESIANO (Operador Binario bsico) R1 X R2 es una nueva relacin T en que sus tuplos t son la concatenacin de un tuplo r1 R1 y un tuplo r2 R2, es decir: R1 X R2 = { ( r1 , r2) | r1 R1 r2 R2 } R1 R2 T=R1 X R2

123 456

1234 3586 9840

1 2 3

1 2 3 4

1 1 4 4 4
r1

2 2 5 5 5

3 3 6 6 6

3 9 1 3 9

5 8 2 5 8

8 4 3 8 4

6 0 4 6 0
r2

En este caso R1 y R2 no tiene que ser del mismo grado y sus respectivos atributos no tienen que estar definidos en el mismo dominio. El grado de T ser igual a la suma de los grados de R1 y de R2.

34

Las operaciones de unin, interseccin y producto son asociativas, no as la diferencia

B.- Operadores especiales

1. Seleccin ( Operador Unario bsico) Sea (zita) cualquier operador de comparacin ( = , <, >, , , ). Entonces la seleccin de R bajo el predicado R.X R.Y, es una nueva relacin T formada por las tuplas t de R tales que el predicado t.x t.y toma valor verdadero. Los atributos X y Y deben estar definidos en el mismo dominio y la operacin debe tener sentido en ese dominio. En lugar de X de Y se puede especificar una constante, o sea R.X constante. Denotndose la operacin por: R R.X R R.X
R.Y R.Y.

Entonces se tendr que:

= { t | t R t.X t.Y sea cierta }

La operacin de seleccin constituye un corte "horizontal" de la relacin R, o sea,

R
r

T
R.Y R.X (FILTRO)
m r

T tendr igual dominio y grado ( r ) que R pero en general diferente Extensin ( m s ). Ejemplo: Dada la relacin Becados (No Estudiante, Nombre, Edad) obtener la relacin T de Estudiantes becados con edad mayor de 20 aos. T = Becados Becados.Edad > 20 A su vez los predicados pueden ser combinados con uso de los operadores lgicos AND, OR y NOT, as se C1 y C2 son predicados Entonces:
35

- RC1 AND C2 equivalente a RC1 RC2 - RC1 OR C2 equivalente a RC1 RC2 - RNOT C quivalente a R - RC

2.

Proyeccin (Operador unario bsico)

La proyeccin de una relacin R sobre los atributos X, Y,..., Z es una nueva relacin

T cuyos tuplos (x, y, , z) aparecen en la relacin R con el valor x en X, y en Y, , z en Z, es decir, la proyeccin de una relacin R constituye un corte vertical de la misma, o sea:

R
r

T
El grado de T ( p ) ser por lo general menor o igual al de R ( r ). Esta operacin se denotar por R [ X, Y, .,Z] Ejemplo: Dada la relacin Externos ( NoEstudiante, Nombre, Edad, ao), la nueva relacin en la que solo aparece los atributos NoEstudiante y ao se obtendra: Externos [NoEstudiante,Ao] Puesto que consideramos significativo el orden de los atributos en la relacin, la proyeccin nos brinda una forma de reordenar los atributos de esta. Ningn atributo puede ser especificado ms de una vez en la lista de atributos de la
36

proyeccin. Omitir dicha lista es equivalente a especificar todos los atributos en su correspondiente orden de izquierda a derecha, o sea, dicha proyeccin sera idntica a la relacin dada, eliminndose las tuplas repetidas. Es comn la existencia de situaciones en las que sean necesario hacer uso tanto la seleccin como la proyeccin, por ejemplo, asi por ejemplo que necesitemos obtener el nombre de los estudiantes becados de 2do ao. (Becados Becados.Ao = 2) [Nombre] 3. Concatenacin (Operador binario no bsico) Sea cualquier operador de comparacin (al igual que en la seleccin). Sean R1 y R2 dos relaciones. La concatenacin, mediante el predicado R1.X R2.Y , de la relacin R1 sobre su atributo X , con la relacin R2 sobre su atributo Y, es una nueva relacin T cuyos tuplos t son la concatenacin de un tuplo r1 de R1 con un tuplo r2 de R2 para los cuales el predicado r1.x r2.y toma valor verdadero. r1.x y r2.y deben estar definidos sobre el mismo dominio y la operacin debe tener sentido en l. Denotndose esta operacin por : R1 R1.X Entonces tendremos que:

R2
R2.Y

R1
R1.X

R2 = { (r1 , r2) | r1 R1 , r2 R2 r1.X r2.Y sea cierta }

R2.Y

La operacin de concatenacin es asociativa. Si es el operador = , la operacin se denomina "equijoin". Entonces, el

resultado de un equijoin tiene que incluir a dos atributos idnticos. Si uno de ellos se elimina en la relacin resultante, entonces el resultado se denomina concatenacin natural (join natural) o simplemente Join. El JOIN es equivalente a realizar una seleccin sobre el producto cartesiano de las relaciones, veamos: Sean R1 y R2 las relaciones siguientes: A R1
a1 a2 a3

B
b1 b2 b2

B R2 b2
b3 b1

C
c1 c2 c3

El JOIN de las relaciones R1 y R2 sobre el atributo B comn de ambas seria la

37

relacin: A R1 JOIN R2
a1 a2 a3

B
b1 b2 b2

C
c1 c2 c2

lo que equivale a :
a1 a1 a1 b1 b1 b1 b2 b2 b2 b1 c1 b2 c2 b3 c3 b1 c1 b2 c2 b3 c3 b1 c1 b2 c2 b3 c3

T = R1 X R2 R1. B = R2.B
a1 a2 a3 b1 b2 b2 b1 b2 b2 c1 c2 c2

R1 X R2

a2 a2 a2

a3 b2 a3 b2 a3 b2

a1 b1 c1 a2 b2 c2 a3 b2 c2

T A, B, C As tendremos que en nuestro modelo Suministradores - Productos: SUMINISRADOR JOIN SP sobre los atributos SNUM en SUMINISTRADOR y S en SP, que estn definidos sobre el mismo dominio, que equivaldra a: ((SUMINISTRADOR X SP)SUM.SNUM=SP.S)

[SUM.SNUM, SUM.SNOM, SUM.TIPO, SUM.MUN, SP.P, SP.CANT]

Si las relaciones sobre las que se aplica la operacin JOIN no

tienen ningn

atributo con igual nombre, entonces se supone que la concatenacin se realice segn el ltimo atributo de la primera relacin y el primero de la segunda. En este caso puede ser necesario plantear las correspondientes proyecciones antes de realizar el Join con el objetivo de reordenar los atributos convenientemente, as por ejemplo en el caso anterior de SUMINISTRADOR JOIN SP debi plantear: SUMINISTRADOR
[SNOM, TIPO, MUN, SNUM]

JOIN SP

De las tres operaciones relacionales especiales vistas, la seleccin es la de mayor prioridad, seguida de la proyeccin y por ltimo la unin. Como es frecuente, es posible usar los parntesis para combinar dichas operaciones alternando sus prioridades.
38

Ejemplos: Usando el modelo Suministrador - Producto Obtengamos el nombre de los suministradores que suministran el producto P2 ( (SUMINISTRADORES[SNOM,SNUM] JOIN SP) P = P2 ) [ SNOM] Se proyecta SUMINISTRADORES con el objetivo de reordenar sus atributos con vista al JOIN y a la vez para escoger los atributos necesarios. Luego se concatena la relacin obtenida de la proyeccin con la relacin SP ( destaquemos que como los atributos que se toman para realizar la concatenacin no tienen igual nombre, en la relacin obtenida de la proyeccin de SUMINISTRADOR es nombrado por SNUM y en la relacin SP por S, al no especificarse el predicado del JOIN se tomar el ltimo atributo de la proyeccin es decir SNUM y el primer atributo de SP, o sea , S), obtenindose una nueva relacin con los atributos: SNOM, SNUM, P, CANT. De esta se realiza la seleccin para escoger los tuplos que hagan verdadero el predicado P = P2 y por ltimo la relacin obtenida se proyecta sobre SNOM, puesto que este es el atributo que nos interesa recuperar. Una forma ms eficiente de realizarlo sera: ( SUMINISTRADOR [ SNOM, SNUM ] JOIN SP p = P2 ) [ SNOM]

Por qu ?
2.- Obtengamos los nombres de los suministradores que suministran al menos un producto de precio igual a 0.10.

( ( ( PRODUCTO PRECIO = 0.10 )[ PNUM] JOIN SP [ S, P ] ) [ S ] JOIN SUMINISTRADOR ) [SNOM] Se realiza una seleccin de la relacin PRODUCTO de los productos cuyo precio es de 10 centavos. En esta seleccin mediante una proyeccin se toma slo el atributo PNUM (nmero del producto). La relacin obtenida de la proyeccin se concatena con la relacin obtenida mediante el reordenamiento de la relacin SP mediante una proyeccin en la cual se toma de SP slo los atributos necesarios: S y P. La relacin obtenida como resultado de la concatenacin se le realiza una proyeccin con vista a obtener otra relacin que contenga slo el atributo S. Esta ltima relacin obtenida se concatena con la relacin SUMISTRADORES obtenindose una nueva relacin de la cual se obtiene el nombre de los suministradores mediante una proyeccin 4. Divisin (Operador binario no bsico)
39

La operacin de divisin divide una relacin dividiendo R1 de grado m + n entre una relacin divisor R2 de grado n, produciendo una relacin cociente T de grado m. El atributo m + i de R1 y el atributo i-simo de R2 (i= 1,2,...n) deben estar definidos sobre el mismo dominio, es decir si la relacin R1 esta definida en el dominio X y la relacin R2 esta definida en el dominio Y, ser necesario para que la relacin cociente T = R1 / R2 exista, que Y X, encontrndose T definida en el dominio X - Y La relacin cociente T estar formada por todos los tuplos t tales que para todos los tuplos r2 de la relacin R2, el tuplo ( t , r2 ) pertenece a la relacin R1, es decir: T X R2 = R1 Luego : Ejemplos: 1.- Sean las relaciones: Estudiantes ( NumEst, NomEst ) Asignaturas ( NumAsig, NomAsig, Crditos ) Notas ( NumEst, NumAsig, Nota) Obtener el nombre de todos los estudiantes que tengan examinadas todas las asignaturas. ( ( (NOTAS [ NUMEST, NUMASIG] ) / (ASIGNATURA [ NUMASIG] ) ) JOIN ESTUDIANTES ) [NOMEST] Si por ejemplo se tiene que: R1 / R2 = { t | r2 R2 ( t , r2 ) R1 }

Estudiantes
NUMEST 1 2 3 4 NOMEST Salvador Antonio Susana Luisa

Asignaturas
NUMASIG 1 2 3 4 NOMASIG Estructura de Datos Sistema Operativo Programacin Avanzada Base de Datos Crditos 3 3 3 3

40

NOTAS
NUMEST 1 1 1 1 2 2 2 3 3 4 4 NUMASIG 1 2 3 4 1 2 4 1 3 1 4 NOTA 3 4 3 4 5 2 4 5 2 2 3

Entonces el resultado de: C = (Notas [ NUMEST, NUMASIG ] ) / ( Asignatura [ NUMASIG ] ) = [ 1 ] Entonces: C JOIN ESTUDIANTES = [ 1, Salvador] La que al proyectarse sobre NOMEST se obtendra Salvador El cociente tiene la misma prioridad que la operacin de concatenacin Usando el modelo SUMISTRADOR - PRODUCTO obtenga : 2.- El nombre de los suministradores que suministran todos los productos (SP [S , P] / PRODUCTOS [PNUM] JOIN SUMINISTRADORES) [SNOM] Al proyectar PRODUCTOS sobre PNUM se obtienen todos los PNUM de

existentes, por tanto, cuando se hace la divisin se obtienen los nmeros la relacin divisora

suministradores tales que en SP cada uno de ellos tiene asociados todos los valores de (la proyeccin de PRODUCTOS). Slo resta concatenar con SUMINISTRADORES para obtener los correspondientes nombres. 3. - El nmero de los suministradores que sirven al menos aquellas piezas suministradas por S2 SP [ S , P ] / (SP S='S2' ) [ P ] La relacin cociente se forma tomando como divisor la relacin obtenida por los
41

nmeros de productos servidos por S2. Para obtenerla, utilizamos la seleccin con el predicado S = S2 y la relacin obtenida la proyectamos sobre P. El dividendo ser la relacin que contendr slo los atributos S y P ya que dividiremos entre P y slo nos interesa obtener S. Al efectuar el cociente, obtendremos una relacin que contendr los nmeros de suministrador S que en la relacin SP tienen asociadas cada uno todos los nmeros de productos del divisor (al menos). Como vimos estas operaciones permiten realizar la recuperacin de datos, aunque este no es su nico objetivo pues en general el lgebra relacional posibilita tambin la escritura de expresiones que pueden ser utilizadas con diversos fines y no slo para la recuperacin, por ejemplo: definir derechos de acceso, restricciones de integridad, datos virtuales, etc Por ltimo diremos que las expresiones algebraicas pueden ser manipuladas para encontrar otras equivalentes, pero ms eficientes para realizar las recuperaciones, por lo que el lgebra puede ser utilizada como base para el proceso de optimizacin de las solicitudes de informacin a la BD. El proceso de optimizacin debe realizarlo el SGBD y no ser objeto de estudio en nuestro curso. Por ejemplo: ( SUMINISTRADOR [SNUM] JOIN SP ) P='P1' es equivalente a: SUM [SNUM] JOIN SP P='P1' Sin embargo la segunda expresin es ms eficiente. Por qu ? Otra alternativa para definir la parte manipulativa del modelo relacional es el Clculo Relacional.

El Clculo Relacional y sus Expresiones

El clculo relacional representa una alternativa al lgebra para la parte manipulativa del modelo relacional. La diferencia entre ellos es la siguiente: El lgebra ofrece una coleccin de operaciones explcitas (join, unin, proyeccin, seleccin, etc) que pueden ser usadas para construir una relacin deseada a partir de las relaciones existentes en la Base de Datos. El clculo slo ofrece una notacin para formular la definicin de la relacin deseada a partir de las relaciones existentes en la Base de Datos. Por ejemplo, consideremos la solicitud siguiente: "Obtener el nmero y municipio de los suministradores que sirven la Pieza P2" Una formulacin hecha con uso del lgebra Relacional sera la siguiente:
42

- Proyectar SUMINISTRADORES en MUN y SNUM - Hacer un JOIN de la proyeccin obtenida con la relacin SP - Realizar en la relacin obtenida con el JOIN anterior una seleccin de los tuplos con P = 'P2' - Proyectar la relacin obtenida de la seleccin anterior sobre SNUM y MUN Una formulacin hecha con el clculo sera algo as: - Obtener SNUM y MUN para los suministradores tales que exista un suministro SP con el mismo valor de SNUM y con el valor de P = 'P2' Aqu se estable las caractersticas definitorias de la relacin deseada y se le deja al sistema la decisin de que operaciones deben ejecutar para construirla. Podemos decir entonces que la formulacin del clculo es "descriptiva" mientras que la del lgebra es "deductiva"; el clculo simplemente establece cul es el problema, mientras que el lgebra da un procedimiento para resolver el problema. O sea el lgebra es procedural y el clculo no es procedural. Sin embargo, debe recalcarse que esta distincin entre uno y otro es superficial. Es un hecho que el lgebra y el clculo son equivalentes uno al otro. Para cada expresin del lgebra existe una expresin equivalente en el clculo. Igualmente para cada expresin del clculo existe una expresin equivalente del lgebra. Hay una correspondencia uno a uno entre las dos. el lgebra es quizs Los diferentes formalismos simplemente representan diferentes estilos de expresin (el clculo es ms cercano al lenguaje natural, ms parecida a un lenguaje de programacin convencional), pero estas diferencias son ms aparentes que reales, en particular, ningn enfoque es realmente menos procedural que otro. El clculo relacional se basa en una rama de la lgica matemtica llamada clculo de predicados. El elemento fundamental del Clculo Relacional es la nocin de "variable de tupla" (tambin conocida como "variable de rango"). Una variable de tupla es una variable que toma valores sobre una relacin, o sea, una variable cuyos nicos valores permitidos son tuplas de una relacin determinada. En otras palabras, si la variable de tupla T toma valores sobre la relacin R, entonces en cualquier momento del tiempo, T representa a algn tuplo t de la relacin R. Una variable de tupla se define con la siguiente instruccin: RANGE OF T IS R (siendo T la variable de tupla y R una relacin). As por ejemplo las variables SX, SY, PZ, PX, SPY sern definidas: RANGE OF SX IS SUMINISTRADOR RANGE OF SY IS SUMINISTRADOR
43

RANGE OF PZ IS PRODUCTO RANGE OF PX IS PRODUCTO RANGE OF SPY IS SP

Expresiones del clculo relacional

Una instruccin de recuperacin del clculo relacional tendr la siguiente forma general:

lista objeto | predicado

donde: lista objeto: Especifica qu atributos y de qu relaciones se desean recuperar. Est formada por nombres calificados de atributos separados por comas (la calificacin se hace sobre variables de tuplas). predicado: Especifica las condiciones que deben verificar los tuplos seleccionados y es opcional. El predicado puede estar formado por relaciones, con uso de un operador de comparacin ( >, <, =, etc), entre dos nombres de atributos o entre un nombre de atributo y una constante, siendo tambin predicado: - NOT predicado - predicado AND predicado - predicado OR predicado - Var_Tupla (predicado existencial) - Var_Tupla (predicado universal) La "ocurrencia de una variable de tupla" ser la aparicin del nombre de la variable dentro del predicado en cuestin. Luego una variable de tupla T ocurre dentro de un predicado bien en el contexto de una referencia a un atributo, como por ejemplo T.A., donde A es un atributo de la relacin sobre la que T toma valor, o como la variable que sigue inmediatamente a uno de los cuantificadores (existencial) o (universal), es decir, T T. As si se tiene que las variables tuplas: RANGE OF SPX IS SP RANGE OF SX IS SUMINISTRADOR RANGE OF PX IS PRODUCTO Tendrn las ocurrencias: a) SPX (SPX.S=SX.SNUM SPX.P='P2') Cuya interpretacin es: "Existe un tuplo de SP con valor de S igual al valor de SX.SNUM "(cualquiera que sea ste)" y el valor del PNUM es igual a P2" . b) PX (PX.PRECIO='1.00')
44

Cuya interpretacin es: "Para todos los tuplos de la relacin PRODUCTO, su precio es de $1.00". Ejemplos Dada las variables tuplas: RANGE SX IS SUMINISTRADOR RANGE SY IS SUMINISTRADOR RANGE SZ IS SUMINISTRADOR RANGE PX IS PRODUCTO RANGE PY IS PRODUCTO RANGE PZ IS PRODUCTO RANGE SPX IS SP RANGE SPY IS SP RANGE SPZ IS SP 1. Obtener el nmero de los suministradores del municipio "10 de Oct" con SX.SNUM | SX.MUN = "10 de Octubre" AND SX.TIPO > 20 2. Obtener todos los pares ordenados de nmeros de suministradores tales que en cada par los dos suministradores estn en el mismo municipio SX.SNUM, SY.SNUM | SX.MUN = SY.MUN AND SX.SNUM < SY.SNUM 3. Obtener los nombres de los suministradores que sirven el producto P2 SX.SNOM | SPX (SPX.S = SX.SNUM AND SPX.P = 'P2') 4. Obtener los nombres de los suministradores que sirven, al menos, un producto de PESO = 30 SX.SNOM | SPX (SX.SNUM=SPX.S AND PX (SPX.P=PX.PNUM AND PX.PESO=30)) 5. Obtener los nombres de los suministradores que sirven al menos un producto suministrado tambin por S2. SX.SNOM | SPX (SPX.S=SX.SNUM AND SPY (SPX.P=SPY.P AND SPY.S='S2')) 6. Obtener los nombres de los suministradores que sirven todos los productos SX.SNOM | PX ( SPX (SPX.S=SX.SNUM AND SPX.P = PX.PNUM)) 7. Obtener los nombres de los suministradores que no sirven el producto P2 SX.SNOM | NOT SPX (SPX.S=SX.SNUM AND SPX.P = 'P2') tipo > 20

Lenguaje SQL
Entre los lenguajes relacionales comerciales se encuentra el SQL ( STRUCTURE
45

QUERY LANGUAGE). Este al igual que todo lenguaje estar compuesto por:

Lenguaje de Definicin de Datos (DDL) Lenguaje de Manipulacin de Datos (DML) Lenguaje de Control de Datos (DCL)

Por lo que nos permitir: consultar actualizar y administrar la Base de Datos.

Lenguaje de Definicin de Datos (DDL)

CREATE TABLE | INDEX (permite crear una nueva tabla en la Base de Datos o Indice en una Tabla) Ejemplos:
1.

CREATE TABLE [Esta tabla] ([nombre]TEXT, [Apellidos]TEXT) CREATE TABLE MiTabla ([Nombre]TEXT, [Apellidos]Text, [Fecha de Nac] DATETIME) CONSTRAINT IndiceMitabla UNIQUE ([Nombre], [Apellidos])

Crea una nueva tabla llamada Esta Tabla con dos campos de texto.
2.

Crea una nueva tabla llamada MiTabla con dos campos texto, un campo fecha y un ndice nico formado por dos campos.
3.

CREATE TABLE NuevaTabla ([nombre]TEXT, [Apellidos]TEXT, [NSUM]INTEGER CONSTRAINT IndiceMiCampo PRIMARY, [Fecha de Nacimiento]DATETIME Crea una nueva tabla con dos campos de texto, uno de tipo entero y uno de tipo fecha. El campo de tipo entero es llave principal.
4.

CREATE INDEX NuevoIndice ON Empleados ([Telefono domocilio]

Extension) Crea en la Tabla Empleados un indice consistente en los campos Telfono domicilio y Extension
5.

CREATE UNIQUE INDEX MiIndice ON Empleados (NSS) WITH

DISALLOW NULL Crea un indice en la tabla Empleados utilizando el campo NSS (Numero de la Seguridad Social). No puede haber dos registros con el mismo valor en el campo NSS, y no se admite en este el valor Nulo. ALTER TABLE ( permite modificar el diseo de una tabla.) Ejemplos:
1.

ALTER TABLE Empleados ADD COLUMN Salario CURRENCY ALTER TABLE Empleados DROP COLUMN Salario ALTER TABLE Pedidos ADD CONSTRAINT RelacionPedidos FOREIGNKEY
46

Agrega el campo Salario de tipo Moneda a la tabla Empleados

2.

Elimina el campo Salario de la tabla Empleados

3.

([Id de Empleado]) REFERENCES Empleados ([Id de Empleado]) Agrega una llave externa a la tabla Pedidos. La llave externa se basa en el campo ID de Empleado y se refiere al campo ID de Empleado de la tabla Empleados. En caso que el campo de la tabla REFERENCES sea llave principal de esta no ser necesario sealar su nombre.
4.

ALTER TABLE Pedidos DROP CONSTRAINT RelacionPedidos Elimina la llave externa de la Tabla Pedidos

DROP TABLE | INDEX (permite eliminar una tabla de una Base de Datos o un Indice de una tabla) Ejemplos:
1.

DROP INDEX MiIndice ON Empleados DROP TABLE [Esta Tabla] Elimina Esta Tabla en la Base de Datos

Elimina MiIndice de la tabla Empleados

2.

Lenguaje de Manipulacin de Datos (DML)

SELECT (permite realizar consultas sobre tablas existentes) SELECT generalmente es la primera palabra de una instruccin SQL. La mayora de las instrucciones SQL son del tipo SELECT. La sintaxis mnima de una instruccin SELECT es: SELECT [predicados] ListaAtributos FROM Listatablas [IN nombrebaseDatosExterna ] es posible el uso de asterisco para seleccionar todos los atributos de una tabla, as por Ejemplo: SELECT Empleados.* FROM Empleados Cuando es usada una instruccin SELECT se incluye todas las tuplas de la relacin. Para realizar una seleccin sobre la relacin es usada la clusula WHERE. Ejemplos:
1.

SELECT [Apellidos], [Nombre] FROM Empleados WHERE [Apellidos] = King para la seleccin donde el apellido es King

Realiza una proyeccin sobre los atributos Apellidos y Nombre de la relacin Empleados
2.

SELECT [Apellidos], [Nombre] FROM Empleados WHERE [Apellidos] LIKE S*

Realiza una proyeccin sobre los atributos Apellidos y Nombre de la relacin Empleados para la seleccin donde el apellido comience con la letra S
3.

SELECT [Apellidos], Salario FROM Empleados WHERE Salario BETWEEN

47

20000 AND 30000 Realiza una Proyeccin sobre los atributos Apellidos y Salario de la relacin Empleados para la seleccin donde el atributo salario este comprendido entre los $200.00 y $ 300.00 inclusive.
4.

SELECT [D de Pedido], [Fecha de Pedido] FROM Pedidos WHERE [Fecha de pedido] BETWEEN #1-1-94# AND #30-6-94#

Realiza la proyeccin de los atributos ID de Pedido y Fecha de Pedido de la relacin Pedidos para la seleccin en que el atributo Fecha de Pedido sea del primer semestre.
5.

SELECT [Apellidos], [Nombre], Cuidad FORM Empleados WHERE Cuidad IN ( Sevilla, Los Angeles, Barcelona)

Realiza la proyeccin sobre los atributos Apellidos, Nombre y Cuidad de la relacin Empleados para la seleccin en que el atributo cuidad tome el valor de Sevilla Los Angeles de Barcelona .
6.

SELECT [Apellidos], Salario*1.1 AS Propuesto FROM Empleados Realiza la proyeccin de los atributos Apellidos y Salario de la relacin Empleados mostrado el valor tomado por el atributo Salario multiplicado por 1.1 y con el nombre de Propuesto (no cambia los valores originales del atributo Salario) Algunos predicados nos permiten realizar determinadas selecciones as con los

predicados:

DISTINCT, nos permitir omitir tuplas con valores duplicados en los campos

seleccionados. La salida de una consulta que use DISTINCT no podr actualizarse Ejemplo: SELECT DISTINCT Apellidos FROM Empleados

TOP, nos permitir obtener el nmero de tuplas especificado, los que sern los

primeros o ltimos segn la clusula ORDER BY Ejemplo: SELECT TOP 25 Nombre, Apellidos FROM Estudiantes WHERE [Ao de graduacin ] = 1994 ORDER BY [Puntuacin Media] DESC En este caso se obtendr los 25 mejores estudiantes de la promocin 1994

DISTINCTROW, cuando se desee omitir datos en base a tuplas completas

duplicadas de la relacin y no solamente en atributos duplicados. Ejemplo: Sea una consulta que una las relaciones Clientes y Pedidos segn el atributo ID del Cliente. La tabla Clientes no tiene valores del atributo ID del Cliente duplicados, sin embargo la tabla Pedidos si puesto que un Cliente puede tener varios pedidos. La siguiente expresin SQL muestra como obtener una relacin de las compaas que
48

tengan al menos un pedido, haciendo uso de la clusula DISTINCTROW. SELECT DISTINCTROW Cliente] El ordenamiento de los resultados de la consulta es posible realizarlo usando la clusula ORDER BY la cual es opcional salvo en el caso que sea utilizado el predicado TOP Ejemplos:
1.

[Nombre de la compaa] FROM Clientes, Pedidos,

Clientes INNER JOIN Pedidos ON Clientes.[ID de Cliente] = Pedidos.[ID de

SELECT Apellidos, Salario FROM Empleados ORDER BY Salario DESC, [Apellidos]

Ordena los registros de la proyeccin obtenida de la relacin Empleados por el atributo Salario de forma Descendente y para las tuplas con igual valor en el atributo salario las ordenar por el atributo apellido de forma ascendente
2.

SELECT

[Id de categora] , [Nombre de Producto], [Precio Unitario] FROM

Productos ORDER BY [Id de categora], [Nombre de Producto] Primero ordena por ID de categora y despus por Nombre de Producto El SQL contiene diversas funciones de agrupamiento como:

COUNT (cuenta el nmero de registros seleccionados) AVG (calcula la media aritmtica del conjunto de valores tomados por el atributo especificado) SUM (suma el conjunto de valores tomados por el atributo especificado) MAX (calcula el valor mximo del conjunto de valores tomado por el atributo especificado) MIN (calcula el valor mnimo del conjunto de valores tomado por el atributo especificado)

Ejemplos:
1.

SELECT COUNT ([Pas destinatario]) AS [Pedidos Espaa] FROM Pedidos Calcula el nmero de pedidos enviados a Espaa. SELECT COUNT (*) AS [Total Empleados], AVG (Salario) AS [Salario Medio], MAX (Salario) AS [Salario Mximo] FROM Empleados Muestra el nmero de empleados y los salarios promedio y mximo

2.

3.

SELECT AVG ([gastos de envo]) AS [Gastos promedios] FROM Pedidos Calcula el gasto promedio de los envo con gasto de ms de $ 100.00

WHERE [gastos de envo] > 100

4.

SELECT SUM ([Precio Unitario]*[Cantidad]) AS [Ventas totales a Espaa]

FROM Pedidos INNER JOIN [Detalles de Pedidos] ON Pedidos.[ID de Pedidos] =

49

[Detalles de Pedidos].[ID de Pedidos] WHERE ([Pas destinatario] = Espaa)

Tema 3 : Diseo de Bases de Datos Relacionales Contenido:

Normalizacin Primera Forma Normal (1FN) Segunda Forma Normal (2FN) Tercera Forma Normal (3FN) Forma Normal de Boyce-Codd (FNBC) Obtencin del Modelo Lgico Global a partir del DER. Metodologa para el diseo de bases de datos.

Normalizacin
La teora de la normalizacin se ha desarrollado para obtener estructuras de datos eficientes que eviten las anomalas de actualizacin. El concepto de normalizacin fue introducido por E.D. Codd para aplicarse a sistemas relacinales. Sin embargo, tiene aplicaciones ms amplias. La normalizacin es la expresin formal del modo de realizar un buen diseo. Provee los medios necesarios para describir la estructura lgica de los datos en un sistema de informacin.

Ventajas de la Normalizacin:
50

Evita anomalas en la actualizacin.

Mejora la independencia de los datos, permitiendo realizar extensiones de la BD, afectando muy poco, o nada, a los programas de aplicacin existentes que accedan a la base de datos. La normalizacin involucra varias fases que se realizan en orden. La realizacin de la 2da fase supone que se ha concluido la 1ra y as sucesivamente. Tras completar cada fase se dice que la relacin est en: Primera Forma Normal (1FN) Segunda Forma Normal (2FN) Tercera Forma Normal (3FN) Forma Normal de Boyce-Codd (FNBC) Existen, adems 4FN y 5FN Las relaciones en 1FN son un subconjunto del universo de todas las relaciones posibles. Las relaciones en 2FN son un subconjunto de las que estn en 1FN y as sucesivamente, como se muestra en la siguiente figura. UNIVERSO DE RELACIONES PRIMERA FORMA NORMAL SEGUNDA FORMA NORMAL TERCERA FORMA NORMAL FORMA NORMAL BOYCE-CODD CUARTA FORMA NORMAL QUINTA FORMA NORMAL

51

Primera Forma Normal:

Una relacin se encuentra en 1FN si: Sus atributos son atmicos No contiene grupos repetitivos Desarrollaremos un ejemplo para ilustrar las fases de normalizacin desde la 1FN hasta la 3FN , el mismo consiste en el diseo de una Base de Datos para la automatizacin del control de los pedidos de productos:

FECHA: 25/4/86

PEDIDO NO. : PROVEEDOR NO. : NOMBRE PROVEEDOR: DIRECCION PROVEEDOR:

123456 75621 J. PREZ CERRO

DESEAMOS QUE NOS ENVEN:

NMERO PRODUCTO

DESCRIPCIN

PRECIO UNITARIO

CANTIDAD

TOTAL

969715

TELEVISOR

600

600

439124

ANTENA

20

10

200

439126

ENCHUFE

10

10 IMPORTE TOTAL:

100 900

El anlisis del modelo del pedido nos muestra que los siguientes datos son de inters: NUPED (Nmero del Pedido, el cual es nico y ser usado como llave ) FECHA ( Fecha del Pedido) NUMPROV (Nmero del Proveedor) NOMPROV ( Nombre del Proveedor) DIREC (Direccin del Proveedor) NUMPROD (Nmero del Producto) DESC (Descripcin del Producto) PRUN (Precio Unitario del Producto) CANT (Cantidad solicitada del Producto)
52

Los atributos PRPROD ( Precio del Producto) y PRPED (Precio del Pedido) pueden calcularse mediante otros, por lo cual no los tendremos en cuenta. En forma de relacin se escribira PEDIDO (NUMPED, FECHA, NUMPROV, NOMPROV, DIREC, NUMPROD, DESC, PRUN, CANT) Esta relacin contiene 4 grupos repetitivos: NUMPROD, DESC, PRUN, CANT, ya que puede estar contenidos en ms de una lnea del pedido. Para llevar la relacin a 1FN es necesario eliminar los grupos repetitivos, para lo cual se crear: 1. Una relacin para los atributos que sean nicos. 2. Una relacin para los grupos repetitivos. As se tendr las relaciones: 1) PEDIDO (NUMPED, FECHA, NUMPROV, NOMPROV, DIREC). 2) PED-PROD (NUMPED, NUMPROD, DESC, PRUN, CANT). Ambas relaciones tienen como llave, o parte de esta, a NUMPED. Pero en la relacin PED-PROD es necesario tomar la llave compuesta para poder identificar a los productos individuales. Esta 1FN presenta los siguientes problemas de actualizacin: Insercin: La informacin sobre un nuevo producto no se puede insertar si no hay un pedido que lo incluya. Supresin: Al eliminar una lnea un pedido que sea el nico que pida un determinado producto implicar perder tambin la informacin de ese producto. Modificacin: Para cambiar la informacin de un Producto ser necesario tambin hacerlo en todos los tuplos de la relacin PED-PRO en que aparezca el Producto.

Segunda Forma Normal

Para poder caracterizar cuando una relacin se encuentra en 2FN, ser necesario abordar algunas definiciones previas: Dependencia Funcional (DF): Dada una relacin R se dice que el atributo Y de R es funcionalmente dependiente del atributo X de R, si y slo si, cada valor X en R tiene asociado a l, precisamente, un valor de Y en R en cualquier momento del tiempo. Ejemplo: En la relacin SUMINISTRADOR
53

SNOM, TIPO y MUN son funcionalmente dependientes cada uno de SNUM, ya que para un valor de SNUM existe un valor correspondiente de SNOM, TIPO y MUN.
SNUM SNOM SNUM SNOM SNUM TIPO TIPO MUN SNUM SNUM SNOM TIPO MUN

SNUM SNOM TIPO

Estas son tres formas posibles de representar las dependencias funcionales. MUN

MUN

El reconocimiento de las dependencias funcionales es una parte esencial de la comprensin de la semntica, del significado del dato. El hecho de que MUN dependa funcionalmente de SNUM significa que cada suministrador esta situado en un municipio. La nocin de dependencia funcional puede ser extendida hasta cubrir el caso en que X, Y o ambos atributos sean compuestos. Ejemplo: En la relacin SP El atributo CANT es funcionalmente dependiente del par de atributos (S,P)
S P CANT P CANT

Dependencia funcional completa El atributo Y es funcionalmente dependiente y completamente del atributo X, si es funcionalmente dependiente de X y no es funcionalmente dependiente de algn subconjunto de X. Se representa: X--->Y Ejemplo: En la relacin SUMINISTRADOR MUN es funcionalmente dependiente de (SNUM, SNOM), pero no es funcionalmente dependiente y completamente de (SNUM, SNOM), ya que tambin es funcionalmente dependiente de SNUM. Ejemplo: En la relacin SP
54

CANT es funcional y completamente dependiente de (S,P) Determinante Cualquier atributo del cual depende funcional y completamente cualquier otro atributo. O sea, la parte izquierda de la implicacin cuando la dependencia funcional es completa. Ejemplo: En la relacin SUMINISTRADOR: SNUM es un determinante. Al hablar de entidad en el MER, se asumi que existe una llave, un conjunto de atributos que definen de forma nica una entidad. Un concepto anlogo se define para las relaciones.

Llave Si R es una relacin con atributos A1, A2, ....An y X es un subconjunto de A1, A2, ...An, X es una llave de R si: 1. X---> A1, A2, ...An o sea, todos los atributos de la relacin dependen funcionalmente de X. 2.

YX |Y

A1, A2, ...An

(esta condicin de minimalidad no se requera para el concepto de llave en el MER). Una relacin puede tener varias llaves. Una de ellas se nombra "llave primaria" (la que se escoja para trabajar) y las restantes se nombran "llaves candidatas". Una superllave ser cualquier superconjunto de una llave. Entonces, una llave es un caso especial de superllave.

Procedimiento para hallar la llave Supongamos una relacin R(A,B,C,D,E) con las dependencias funcionales: 1. A-->B 2. BC-->D 3. AB->E

Para comenzar, se parte de que no pueden existir ms llaves que dependencias

55

funcionales, pues el concepto de llave incluye la existencia de dependencia funcional. Se analiza, por tanto, cada una de las DF presentes en la relacin. Aadiendo los atributos que sean imprescindibles en la parte izquierda para lograr determinar a todos los atributos de la relacin. El conjunto de atributos as formado debe ser mnimo. Luego se analiza cada uno de esos conjuntos mnimos, de forma que, si alguno es un superconjunto de otro, ya no es llave, sino superllave. Pueden resultar varias llaves candidatas. En el ejemplo anterior tendremos: 1. A-->B 2. BC-->D 3. AB->E entonces AC-->A B E C D ------> AC es llave

entonces BCA-->B C D A E ------> BCA es superllave entonces ABC-->A B E C D ------> ABC es superllave

La nica llave es AC. No hay ninguna otra llave candidata, pues en las otras DF se obtiene el mismo conjunto (ABC) el que contiene a AC. Ejemplo: Sea la relacin R (ciudad, calle, cdigo postal) C A P donde se tiene que: CA--->P (una calle en una ciudad tiene un cdigo postal). P---->C (el cdigo postal tiene una estructura tal que su valor determina la ciudad, pero en una ciudad, varias calles pueden tener el mismo cdigo, por lo que no se cumple P--->A. Entonces, CA es llave, ya que determina a todos los atributos de R (determina a P y obviamente a si mismo), o sea, CA--->CAP. P determina a C pero no a A, pero haciendo: PA--->CA, es obvio que PA--->PA tambin, entonces PA--->CAP, por tanto, PA tambin es llave. PA y CA son llaves candidatas. En ninguno de estos casos un subconjunto de ellas es tambin llave. Un atributo Ai de R es un atributo llave ( principal ) si l es (o es miembro de) una llave (candidata o primaria). Un atributo Aj de R es un atributo no llave ( secundario) si l no es miembro de ninguna llave. En el ejemplo tendremos que: C, A y P son todos atributos llaves principales.

56

Segunda Forma Normal

Una relacin R se dice que est en 2FN si y slo s: Est en 1FN Los atributos no llaves (secundarios) de R, si los hubiese, son funcional y completamente dependientes de la llave primaria de R, o sea no exista dependencia parcial de los atributos secundarios respecto a la llave. Entonces, este segundo paso en la normalizacin se aplica slo a relaciones que tengan llaves compuestas. As en el ejemplo de los Pedidos de Productos, habamos visto que en la relacin PED-PROD subsistan problemas de actualizacin. Analicemos las DF existentes en dicha relacin:
NUMPED NUMPROD

CANT DESC PRUN

Esta relacin no est en 2FN, pues los atributos secundarios DESC y PRUN no dependen funcional y completamente de la llave compuesta (NUMPED, NUMPROD). Para llevarla a 2FN es necesario crear: 1. Una relacin que contenga a todos los atributos secundarios que dependen funcional y completamente de la llave y los atributos que forman la llave. 2. Una relacin para los atributos secundarios que dependan de parte de la llave, aadiendo a ella el atributo principal del cual estos atributos dependen completamente. As se tendr las relaciones: PED-PROD (NUMPED,NUMPROD, CANT) PRODUCTO (NUPROD, DESC, PRUN) Con la 2FN sern resueltos los problemas planteados en la 1FN, veamos: Insercin: Se puede insertar la informacin de un nuevo producto sin necesidad que tenga que existir un pedido del mismo. Supresin: Se puede eliminar una lnea de pedido y no se pierde la informacin sobre el producto, aunque sea el nico pedido en que se pide ese producto.
57

Modificacin: Si cambia un atributo del producto, slo hay que cambiarlo en un lugar. Se elimina redundancia. Pero an persisten problemas de actualizacin similares a las vistos, pero en la relacin PEDIDO y, especficamente, cuando se trata de insertar, eliminar o modificar la informacin de PROVEEDORES, veamos: Insercin: No podemos insertar informacin de proveedores en que no hayan un pedido para l. Supresin: Se perder la informacin sobre un proveedor al borrar un pedido en que sea el nico para ese proveedor. Modificacin: Para cambiar la informacin sobre un proveedor, hay que hacerlo en todos los tuplos de pedidos en que aparezca ese proveedor.

Tercera Forma Normal

Una relacin R est en 3FN si y slo si: Se encuentra en 2FN No exista dependencia entre los atributos secundarios Esto es lo mismo que decir que se deben eliminar las dependencias transitivas de atributos secundarios respecto a la llave, estando ya la relacin en 2FN. Dependencia transitiva: Sean A, B y C conjuntos de atributos de una relacin R. Si B es dependiente funcionalmente de A y C lo es de B, entonces C depende transitivamente de A. A B C

Este paso se ejecuta examinando todas las relaciones para ver si hay atributos no secundarios que dependan unos de otros. Si se encuentran, se forma una nueva relacin con ellos. NUMPROV NOMPROV NUMPED DIREC
58

FECHA PEDIDO (NUMPED, NUMPROV, FECHA) PROVEDORES (NUMPROV, NOMPROV, DIREC) (Si se analizan las otras relaciones, podr ver que no hay dependencia entre atributos secundarios) La 3FN ha elimina los problemas de actualizacin sobre el proveedor sealados en la 2FN. Ya en esta etapa se puede optimizar la 3FN. Puede haber relaciones degeneradas que contengan slo la clave, por lo que se pueden eliminar. Puede que otras relaciones tengan la misma clave, por lo que se pueden combinar en una sola, siempre que el resultado sea lgico y tenga sentido. Los analistas y diseadores con experiencia producen relaciones en 3FN casi sin darse cuenta, sin tener que preocuparse para ello, este se debe a que utilizan el sentido comn y la experiencia para escribir relaciones ya normalizadas. No obstante, no siempre la instuicin es suficiente y la metodologa para normalizar las Bases de Datos se convierte en una herramienta imprescindible, con la que se garantiza un diseo idneo de los datos. An en la 3FN pueden existir problemas y habrn de ser resueltos con las siguiente forma normal:

Forma Normal de Boyce-Codd (FNBC)

La definicin de la 3FN puede resultar inadecuada en el caso de una relacin donde ocurre lo siguiente: 1. La relacin tiene varias llaves candidatas 2. Las llaves candidatas son compuestas 3. Las llaves candidatas se solapan (o sea, tienen al menos un atributo comn). Una relacin donde no tengan lugar las tres condiciones anteriores, la FNBC coincidir con la 3FN, por lo cual no ser necesario analizar si la relacin cumple la FBC en caso contrario ser necesario realizar el anlisis. Esas tres condiciones son necesarias, pero no suficientes, para que la relacin viole la FNBC, ms adelante con un ejemplo veremos esto. Caractericemos primero cuando una relacin se dice que cumple la FNBC

Forma Normal de Boyce-Codd FNBC)

59

Una relacin R est en FNBC si, y slo si cada determinante es una llave (candidata o primaria). Ejemplo1.Sea la relacin EAP (Estudiante, Asignatura, Profesor), donde una tupla significa que un estudiante E recibe la asignatura A impartida por el profesor P y en la cual se cumple: O sea, Para cada asignatura, cada estudiante tiene un solo profesor. Cada profesor imparte slo una asignatura. Cada asignatura es impartida por varios profesores.

EA--->P P--->A

E A

y no existe DF de P con respecto a A

pero si P--->A, entonces EP--->A tambin, por lo que EP es una llave candidata de la relacin, ya que determina a todos los atributos (E, P, A). Ambas llaves candidatas (EA y EP) son compuestas y se solapan, por lo que debe analizarse la FNBC Esta relacin est en 3FN, pero no en FNBC, ya que el determinante P no es llave de la relacin. As por ejemplo si: E Prez Prez Rodrguez Rodrguez A Matemtica Fsica Matemtica Fsica P Blanco Valds Blanco Hernndez

Esta relacin presenta anomalas de actualizacin, por ejemplo: Eliminacin: Si queremos eliminar la informacin de que Rodrguez estudia Fsica, perdemos la informacin de que el profesor Hernndez imparte Fsica. Estos problemas pueden ser resueltos sustituyendo la relacin EAP por las relaciones: EP (E,P) y PA (P,A)

O sea, separando la DF problemtica (P--->A) en una relacin independiente, donde

60

el determinante ser la llave (P), y se forma la otra relacin de manera que dicho determinante P participar como atributo, pero en la cual no puede participar el atributo determinado en la dependencia funcional conflictiva o sea A Ejemplo2.Sea la relacin R1 (C, A, P) C- Ciudad A- calle P- cdigo postal donde CA ---> P y P ---> C, con llaves candidatas CA y PA. Esta relacin no est en FNBC, ya que existe un determinante (P) que no es superllave. La solucin ser dividir R1 en: R2 (P, C) Ejemplo3.Sea la relacin EXAM (E, A, L) donde: E - Estudiante A - Asignatura L . Lugar en el escalafn alcanzado por un estudiante en una asignatura y en la que se supone que 2 estudiantes no pueden alcanzar el mismo lugar en una asignatura. Entonces:
A L A E

R3 (A,P)

Como se ve, existen dos llaves candidatas, EA y AL, las cuales se solapan, pero no existen otros determinantes que no sean esas llaves candidatas (que son casos especiales de superllaves), por lo que la relacin EXAM est en FNBC. Por ltimo, es necesario destacar que la descomposicin de una relacin para obtener la FNBC puede implicar que se pierdan dependencias funcionales. Por ejemplo en la relacin EAP donde EA-->P y P-->A al descomponerse en EP (E,P) y PA (P,A)
61

se pierde la DF EA-->P ya que esta DF no puede ser deducida a partir de las que existen en EP y PA (que slo es P-->A), lo cual implica que ambas relaciones EP y PA no pueden ser actualizadas "independientemente", sino que una actualizacin en un lugar conlleva un chequeo de actualizacin en el otro lugar (para aadir un profesor a un estudiante hay que chequear la materia que el profesor imparte y hay que chequear si el estudiante ya tiene un profesor de esa materia y en ese caso no se puede aadir). Entonces, para el proceso de normalizacin se deben dar los siguientes pasos:

RELACIN NO NORMALIZADA

1FN

Eliminar los grupos repetitivos.

2FN

Eliminar las dependencias funcionales incompletas de los atributos secundarios respecto a la llave.

3FN

Eliminar dependencias transitivas respecto a la llave

FNBC

Eliminar las dependencias en las que el determinante no sea llave candidata.

EJEMPLO DE NORMALIZACIN HASTA FNBC.

Se desea disear una BD para controlar la disponibilidad de materiales de construccin. De cada proveedor de materiales se conoce su cdigo (CPROV), que lo identifica, su nombre (NOMPROV) y el municipio en que radica (MUN). De cada material se sabe su cdigo (CMAT), que lo identifica, su descripcin (DESC), la unidad de medida que se aplica al material (UM) y el precio por unidad de medida (PRECIO). Para guardar estos materiales hasta su posterior distribucin existen diversos almacenes. De cada almacn se conoce su cdigo (CALM), que lo identifica, su
62

direccin (DIRALM) y la capacidad de almacenaje (CAPAC). Un proveedor puede suministrar varios materiales y un material puede ser suministrado por diferentes proveedores. Se sabe que un material suministrado por un proveedor est en un solo almacn y adems, se sabe qu cantidad de un material suministrado por un proveedor se encuentra en el almacn (CANTMAT). En un almacn slo se guarda un tipo de material, aunque puede proceder de distintos proveedores y pueden existir varios almacenes donde se guarde un mismo material. Veamos las dependencias funcionales que se derivan de esta situacin: Como CPROV identifica al proveedor entonces, 1) CPROV --> NOMPROV, MUN es el determinante de NOMPROV y MUN

2) CMAT --> DESC, UM, PRECIO anlogo a lo anterior pero para materiales 3) CALM --> DIRALM, CAPAC, CMAT, DESC, UM, PRECIO 1 2 3 4 5 6 Esta ltima dependencia funcional tiene la siguiente explicacin: Los atributos 1 y 2 dependen funcionalmente de CALM pues CALM identifica al almacn. Pero se sabe que en un almacn slo se guarda un material, por lo que conocido CALM se conoce CMAT y, por lo tanto, el atributo 3 depende funcionalmente de CALM, pero como 4, 5 y 6 dependen funcionalmente de 3, ellos estn incluidos tambin en la dependencia funcional expresada anteriormente 3). 4) CPROV, CMAT --> NOMPROV, MUN, DESC, DIRALM, 1 2 3 4 CAPAC, CANTMAT 8 9 En esta dependencia funcional los atributos: 1 y 2: por lo explicado para 1) 3, 4 y 5 por lo explicado para 2) 6 porque dado un proveedor y un material se conoce en qu UM, 5 PRECIO, CALM, 6 7

almacn se guarda ese material suministrado por ese proveedor. 7 y 8 porque 6 se incluye y entonces vale lo explicado para 3) 9 porque dado un proveedor y un material se conoce tambin en qu cantidad se guarda en el almacn correspondiente. 5) CPROV, CALM DESC, --> NOMPROV, MUN, DIRALM, CAPAC, CMAT,
63

UM, PRECIO, CANTMAT 7 8 9 Se incluyen en esta dependencia funcional los atributos: 1 y 2 por lo explicado para 1) 3, 4, 5, 6, 7 y 8: por lo explicado para 3)

9 porque se incluyen en los atributos implicados el atributo 5 y CPROV y 5 determinan 9, segn lo explicado para el atributo 9 en 4)

Entonces: CPROV, CMAT son ambas llaves candidatas ya que todos los atributos dependen funcionalmente de ellas y CPROV, CALM no existe ningn subconjunto propio del cual todos los atributos dependan. Escojamos como llave primaria CPROV CMAT R 1FN La relacin original est en 1FN, pues no existen grupos repetitivos. 2FN No est en 2FN pues existen dependencias funcionales incompletas de atributos no llaves respecto a la llave primaria (segn se aprecia en las dependencias funcionales 1) y 2) ) por lo que se separan las relaciones siguientes: (I) PROVEDOR (CPROV, NOMPROV, MUN) (CPROV, CMAT, NOMPROV, MUN, DESC, UM, PRECIO, CALM, DIRALM, CAPAC, CANTMAT)

(II) MATERIAL (CMAT, DESC, UM, PRECIO) 3FN Las relaciones anteriores (I y II) estn en 3FN, pero la relacin restante de la original, no, ya que existe dependencia transitiva respecto a la llave primaria pues: CPROV, CMAT --> CALM y CALM --> DIRALM, CAPAC por lo que se separa en la siguiente relacin :
64

(III) ALMACEN (CALM, DIRALM, CAPAC) FNBC Luego de haberse obtenido, es decir, separado, las relaciones I, II y III al analizarse la 2FN y la 3FN, resta la relacin: (1) SUMINISTRO (CPROV, CMAT, CALM, CANTMAT) que est en 3FN. Analicemos las dependencias funcionales que existen en esta relacin: a. CPROV, CMAT --> CALM, CANTMAT b. CALM --> CMAT Luego no est en FNBC, pues existe un determinante (CALM) que no es superllave. Para llevarla a FNBC hay que separar la dependencia funcional problemtica (b.), obtenindose de la relacin suministro las siguientes: (2) SUMINISTRO (CPROV, CALM, CANTMAT) aparecer CMAT. en esta relacin no puede

(3) DISTRIBUCION (CALM, CMAT) Ahora bien, debe sealarse que al descomponerse la relacin suministro (1) de esta manera (suministro (2) y distribucin) deja de poder expresarse el hecho de que el CALM depende del conjunto CPROV, CMAT. Finalmente, analizando la relacin distribucin (3) y la relacin almacn (III) puede apreciarse que ambas pueden unirse: tienen la misma llave y tiene sentido la unin de ambas. Entonces las relaciones obtenidas son:

PROVEEDOR (CPROV, NOMPROV, MUN) MATERIAL (CMAT, DESC, UM, PRECIO) ALMACEN ( CALM, DIRALM, CAPAC, CMAT) SUMINISTRO (CPROV, CALM, CANTMAT)

65

Obtencin del Modelo Lgico Global a partir del DER

Para obtener el modelo lgico global de los datos segn el enfoque relacional a partir del DER, se sigue un procedimiento que iremos describiendo paso a paso a medida que lo apliquemos al ejemplo siguiente:
nompa moneda cmerc nommerc tipo arribo tarifa cantem b

u m

PAIS

MERCANCIA

TRANSPORTACION

n p pas-merc embarque

cantembalm

emb-alm numalm calm diral m n nomemp rama

almacn 1

distribucin

empresa

alm-nav

nave nave

En numnave el DER

anterior se representa el fenmeno del movimiento mercantil de un

capna v

condtcn

organismo. En el organismo existen mercancas de las que se conoce su cdigo, nombre y unidad de medida. Las mercancas proceden de diferentes pases de los que se sabe
66

nombre y rea de moneda. Para la transportacin de las mercancas existen diversas formas, cada una de las cuales se caracteriza por su tipo (barco, avin, tren, etc.) y tarifa. De un pas se reciben muchas mercancas y una mercanca puede venir de muchos pases. Para cada mercanca de un pas existen diferentes formas de transportacin y una forma de transportacin puede serlo de diferentes mercancas de diferentes pases. Una mercanca procedente de un pas transportada de una forma dada constituye un embarque y para ste se conoce su fecha de arribo y cantidad. Un embarque se distribuye entre diferentes almacenes y en un almacn se tienen diferentes embarques, cada uno en cierta cantidad. De cada almacn se tiene su cdigo y direccin. Un almacn enva sus productos a una sola empresa y cada empresa recibe productos de diferentes almacenes. Una empresa se caracteriza por su nmero, nombre y rama econmica. Cada almacn tiene distintas naves subordinadas. De cada nave se conoce su nmero (que se puede repetir en diferentes almacenes), capacidad y condiciones tcnicas.

PASO # 1 Representar cada entidad regular en una tabla relacional. a. b. c. d. e. pas (nompa, moneda) mercanca (cmerc, nommerc, um) transportacin (tipo, tarifa) almacn (calm, diralm) empresa (numemp, nomemp, rama)

PASO # 2 Representar en una tabla relacional cada entidad agregada con sus correspondientes atributos (entre ellos un identificador si fue definido) y, las llaves de las entidades que forman la agregacin embarque (nompa, cmerc, tipo, arribo, cantemb) Ntese que la llave estara formada por las llaves de las 3 entidades regulares que intervienen en la agregacin. Pero poda haberse definido un identificador para la entidad embarque (Adase en el DER lo que est oscuro: idemb). Entonces se aadira como atributo llave en la agregacin y los 3 atributos nompa, cmerc y tipo permaneceran en la relacin pero no como llaves: embarque (idemb, nompa, cmerc, tipo, arribo, cantemb)
67

PASO # 3 Representar cada entidad generalizada en una tabla que contendr sus atributos (slo los de la generalizada) y, entre ellos, la llave. Representar cada entidad especializada en una tabla que contendr la llave de la generalizacin y los atributos propios slo de la especializacin. En el ejemplo que estamos desarrollando no tenemos Generalizacion-Especializacin PASO # 4 Representar en una tabla relacional cada relacin de n : m, incluyendo las llaves de las entidades relacionadas y los atributos de la relacin si los hubiese. emb-alm (nompa, cmerc, tipo, calm, cantembalm) Esta relacin sera de esta forma sin considerar la existencia del idemb. Caso de que ste estuviera definido quedara: emb-alm (idemb, calm, cantembalm) ya que entonces la llave de la entidad embarque sera idemb. PASO # 5 Para cada relacin de 1 : m, aadir la llave de la entidad del extremo "1" como un nuevo atributo a la entidad del extremo "m" y los atributos de la relacin si existe n. En nuestro ejemplo, se da la relacin almacn <<--------------> empresa por lo que la llave de la entidad empresa (numemp) debe aadirse como atributo en la tabla que representa la entidad almacn. Esto hace que la relacin d, obtenida en el paso # 1 quede modificada de la siguiente manera: almacn (calm, diralm, numemp) Al agregarse el atributo numemp en la relacin almacn se sabe entonces a qu empresa abastece el almacn. Est claro que muchas ocurrencias de almacn pueden tener el mismo valor en el atributo numemp, pues una empresa recibe mercancas de varios almacenes, en general.

PASO # 6 Representar cada entidad dbil en una tabla relacional que contendr la llave de la entidad regular determinante y el identificador de la entidad dbil con sus atributos.
68

nave (calm, numnav, capnav, condtcn) Estas son las tablas relacionales que se derivan del DER del ejemplo. Ahora es preciso analizar cada una de las relaciones para asegurarse que estn normalizadas hasta FNBC. En este caso, puede verse que todas las relaciones cumplen con la FNBC, por lo que no es preciso hacer nada ms. En caso de que no estuvieran debidamente normalizadas, era preciso aplicar el proceso de normalizacin tal y como lo vimos anteriormente.

69

Metodologa para el diseo de bases de datos.

Determinacin de entidades y atributos Normalizacin de entidades Determinacin de relaciones (DER) Obtencin del modelo lgico global de los datos Diseo fsico de la BD

Cuando se va a realizar el diseo de la base de datos para un sistema determinado, es necesario determinar los datos que es necesario tomar en cuenta y las dependencias funcionales existentes entre ellos. Rigurosamente, esto se obtiene luego de realizada la etapa de anlisis del sistema y partiendo de lo obtenido en sta, pero trataremos de dar indicaciones que permitan lograr un buen diseo de la BD a partir de lo que conocemos. La situacin a partir de la cual se discutir la metodologa para disear la base de datos es la siguiente: En un hospital Clnico Quirrgico se desea automatizar el control de la actividad quirrgica. En el hospital se tienen varios quirfanos y se realizan intervenciones quirrgicas en diferentes especialidades. Las intervenciones quirrgicas pueden ser electivas (planificadas) o urgentes (no planificadas). Se tiene la planificacin de las operaciones quirrgicas a realizar cada da. Las operaciones planificadas pueden ser suspendidas por distintas causas. Para cada operacin realizada (haya sido planificada o no), se confecciona un informe operatorio. En cada operacin realizada se emplean materiales cuyo gasto se controla. Con el sistema automatizado se pretende obtener las siguientes salidas:

PROGRAMACIN QUIRRGICA Paciente Hist Cln.

Para el da: de

de 19

Edad Sexo Diagnstico Intervenc. Hora Saln Cirujano Pre-Oper. Indicada

OPERACIONES SUSPENDIDAS

En el da: de Edad Causa

de 19

Paciente

Historia Clnica

70

Fecha de Operacin: INFORME OPERATORIO Paciente Hora Comienzo Hora Terminacin

Historia Clnica

Edad

Diagnstico Clnico: Operacin Realizada: Diagnstico Operatorio: Situacin Final del Paciente: Satisfactoria

No Satisfactoria

Fallecido

Especialidad

Tipo de Operacin Realizada Electiva

Urgente

Cirujano:

RESUMEN DE ACTIVIDADES QUIRURGICAS Cantidad de Operaciones Electivas: Cantidad de Operaciones Urgentes: Especialidad Cantidad de Operaciones

Mes:

71

GASTO DE MATERIALES DE OPERACIN Paciente Costo Hist. Edad Hora Patologa Cd. Cln. Com. Mat.

En el da: de

de 19

Descr. Cantidad Mater.

Para comenzar a estudiar la metodologa de diseo de la base de datos, partiremos de una premisa: lo que se obtiene con un sistema automatizado son sus salidas, es decir, el resultado que se desea obtener, lo que llega al usuario, son justamente las salidas del sistema y para ello se desarrolla; por lo tanto, lo que no sea necesario para obtener las salidas del sistema, no tiene por qu estar almacenado en la base de datos. En fin, lo que debe almacenarse en la base de datos es lo que es imprescindible para obtener las salidas. Es por esta razn que para el diseo de la base de datos, se parte del anlisis de las salidas que se desea obtener con el sistema.

I.- Determinar las entidades y los atributos

Para cada salida: Consultar su formato Determinar datos que se calculen u obtengan a partir de otros e ir sustituyndolos hasta llegar a los primarios Determinar existencia de ficheros con informacin normativa y/o de consulta Cada salida y cada fichero, tomarlos como entidad y relacionar sus atributos En el ejemplo, representando cada una de las salidas por una relacin, se tienen las sgtes. relaciones o entidades iniciales: 1. PQ (Fecha, NomPac, HC, Ed, Sexo, DiagPre, Interv, Hora, 2. OS (Fecha, NomPac, HC, Ed, Causa) 3. IO (Fecha, HoraCom, HoraTerm, NomPac, HC, Ed, DiagCln, Operac, DiagOper, SitPac, Espec, TipoOpReal, CirReal) 4. RAQ (Mes, Elect, Urg, Espec, Cant) 5. GMO (Fecha, NomPac, HC, Ed, HoraCom, Patologa, CdMat, DescMat,
72

Saln, Cirujano)

Cant, Costo) Analizando cada dato se ve que: En 1. Hora se calcula segn el tiempo promedio de demora para cada operacin., por lo que es necesario un fichero normativo: => TPO (Operacin, Tiempo Prom)

Saln se decide teniendo en cuenta la distribucin de los salones, que en este caso, es por da de la semana: => En 2. Todos son datos primarios En 3. Todos son datos primarios En 4. Elect, Urg y Cant son datos que se calculan a partir de contar en IO (relacin 3), por lo que la relacin 4 se puede eliminar completamente para el anlisis, pues al ser calculables todos los datos contenidos en ella, no aporta informacin nueva a almacenar en la base de datos. En 5. Costo = cant x precio, por lo que se sustituye costo por precio (ya cant est en el modelo) => necesidad de existencia de un fichero de consulta MATERIAL (puede salir en entrevistas a usuarios) DS (Saln, DaSem, Espec)

II. Normalizar las entidades

Determinar las DF Normalizar cada entidad Fusionar, de ser lgico, las entidades normalizadas que tengan la misma llave 1. PQ (Fecha, NomPac, HC, Ed, Sexo, DiagPre, Interv, Hora, Saln, Cirujano) Normalizando: a. Paciente (HC, NomPac, Ed, Sexo) b. PQ (Fecha, HC, DiagPre, Interv, Hora, Saln, Cirujano)
73

2. OS (Fecha, NomPac, HC, Ed, Causa) Normalizando: c. Paciente1 (HC, NomPac, Ed) d. OS (Fecha, HC, Causa) 3. IO (Fecha, HoraCom, HoraTerm, NomPac, HC, Ed, DiagCln, Operac, DiagOper, SitPac, Espec, TipoOpReal, CirReal) Normalizando: 2FN: Paciente2 ( HC, NomPac, Ed) PlanOperac ( Fecha, HC, DiagCln, Operac, Espec) IO ( Fecha, HoraCom, HC, HoraTerm, DiagOper, SitPac, TipoOpReal, CirReal, OperReal) 3FN: e. Paciente2 ( HC, NomPac, Ed) f. PlanOperac ( Fecha, HC, DiagCln, Operac) g. ClasifOperac ( Operac, Espec) h. IO ( Fecha, HoraCom, HC, HoraTerm, DiagOper, SitPac, TipoOpReal, CirReal, OperReal) 4. (Se elimina para este anlisis) 5. GMO (Fecha, NomPac, HC, Ed, HoraCom, Patologa, CdMat, Precio) (Precio en lugar de Costo) i. Paciente3 ( HC, NomPac, Ed) j. Diagstico ( Fecha, HC, Patologa) k. Material ( CdMat, DescMat, Precio) l. GMO ( Fecha, HC, HoraCom, CdMat, Cant) Adems, se tienen los dos ficheros normativos o de consulta: m. TPO (Operacin, Tiempo Prom)
74

DescMat, Cant,

n. DS (Saln, DaSem, Espec) Fusionando las entidades normalizadas con igual llave, siempre que sea lgico, se tiene: . De a, c, e y i ==> Paciente ( HC, NomPac, Ed, Sexo) . De b, d, f y j ==> f est contenida en b y j est contenida en b tambin ( DiagPre = DiagCln = Patologa ) Son alias diferentes para indicar un mismo atributo, que tiene el mismo dominio Pero d, a pesar de tener igual llave, est representando otra entidad, la Operacin Suspendida; semnticamente, no representa lo mismo que una Operacin Planificada y, por lo tanto, no tiene sentido unirlas. Es ms, si se hiciera, todas las operaciones tendran el atributo Causa, y en la mayora de las ocurrencias, este atributo estara vaco, pues slo son algunas las operaciones que se suspenden. PQ (Fecha, HC, DiagPre, Interv, Hora, Saln, Cirujano) OS (Fecha, HC, Causa) . De m y g ==> Intervencin ( Operacin, TiempoProm, Espec) . De n ==> DS ( Saln, DaSem, Espec) . De h ==> IO ( Fecha, HoraCom, HC, HoraTerm, DiagOper, SitPac, TipoOpReal, CirReal, OperReal) . De k ==> Material ( CdMat, DescMat, Precio) . De l ==> GMO ( Fecha, HC, HoraCom, CdMat, Cant)

III. Determinar las relaciones entre las entidades (DER)

75

Si hay alguna entidad cuya llave es combinacin de llaves de otras entidades, Analizar cada entidad con las restantes para determinar si existe relacin, Ir confeccionando el DER Analizar entidades agregadas, entidades dbiles y sus relaciones con otras

generalmente, es porque representa una relacin entre ellas (n : m) determinando tipo de proyeccin.

76

operacin tipoopreal sitpac diagoper horaterm horacom fecha fecha cant n

GMO

cirreal 1 m

tiempoprom INTERVENCION espec 1

IO

diapre m PQ n 1 m 1 m

hora cirujano

ed

1 PACIENTE

1 SALO N

MATERIAL L precio cdmat

1 sexo nompac HC OS

m
DS

espec

descmat

n DIASEM

causa En este paso se puede comprobar si lo que se ha realizado es correcto o si surge alguna contradiccin, se puede completar el modelo con nuevos elementos que se hayan podido obtener en intercambios con los usuarios, ya que con el DER se tiene un modelo menos abstracto, ms cercano al fenmeno. El analista puede proponer nuevas posibilidades a los usuarios y agregarlas en caso de acordarse esto, etc.

IV. Obtener el modelo lgico global de los datos

Aqu se deben seguir los pasos para llevar de DER al modelo lgico global de los datos. Si en el paso anterior no se modifica el DER obtenido, entonces las tablas que se obtienen en este paso, en general, son las mismas que las obtenidas en el paso II. Supongamos que en nuestro ejemplo, este es el caso. Entonces: Diseo lgico:
77

Paciente (HC, NomPac, Ed, Sexo) Intervencin (operacin, TiempoProm, Espec) Material ( CdMat, DescMat, Precio) PQ (Fecha, HC, DiagPre, Interv, Hora, Saln, Cirujano) IO (Fecha, HoraCom, HC, HoraTerm, DiagOper, SitPac, TipoOpReal, CirReal, OperReal) OS (Fecha, HC, Causa) DS (Saln, DaSem, Espec) GMO (Fecha, HC, HoraCom, CdMat, Cant)

V. Diseo fsico de la BD
En este paso hay que tener en cuenta: . Aplicaciones a realizar sobre los datos . Caractersticas particulares del SGBD Ejemplos:

ficheros ndices ficheros para reportes cantidad de veces que habra que calcularlos en una determinada aplicacin.

considerar la inclusin de campos que sean secundarios debido a la

separar un fichero en varios debido a la cantidad de campos y lo que se accesa cada vez.

VI. Proteccin de las bases de datos

Contenido: 1. Procesamiento de Transacciones. Recuperacin.
78

 Concurrencia. 2. Seguridad. 3. Integridad. Desarrollo Las Funciones de un SGBD son: 1. Disponibilidad de Datos para los usuarios. 2. Identificacin de usuarios legales. 3. Actualizacin de Datos. 4. Consultas a los Datos. 5. Proteccin de los Datos. 6. Herramientas para desarrollo de Aplicaciones. 7. etc. Los peligros a los que se enfrenta una BD pueden ser Intencionales o accidentales. La proteccin, como funcin de los SGBD, se encarga de garantizar que el contenido de la BD sea consistente, aun cuando ocurran eventos que eventualmente producen dao. Se denomina proteccin de datos, a todas las acciones que realizan el programador o el SGBD, para garantizar la consistencia de la BD. La funcin de proteccin de lo datos de los SGBD se encarga de: 1. La recuperacin de la BD ante fallos y del control de concurrencia como parte del procesamiento de transacciones. 2. La integridad de los datos contenidos en la BD. En este tema se discutirn, a un nivel elemental: La recuperacin ante fallos. (Ts) El control de concurrencia (Ts) y La seguridad de los datos en la BD. La integridad de los datos en la BD.

Recuperacin ante fallos. Uno de los eventos ms dainos para la consistencia de la BD, es la ocurrencia de fallos. Los tipos de que sern considerados son: Fallo del disco duro. Fallo del fluido elctrico. Errores del SW. Incendio del local de la mquina. Fallo por concurrencia o por error de integridad.(Concurrencia).

Para estudiar las caractersticas de estos eventos y las formas de evitar el dao que pueden producir, resulta muy importante conocer que se entiende por Transaccin. Recuperacin ante fallos Si al producirse un fallo el sistema est atendiendo a uno o ms programas (multiprogramacin), los resultados que se obtienen pudieran no ser consistentes. Los SGBD operan con procedimientos que se tienen que ejecutar totalmente o no ejecutarse
79

Transaccin: Grupo de operaciones sobre la BD que forman una unidad lgica de trabajo. Ej. Transferencia de fondos entre cuentas.
T E2

Las operaciones a realizar como unidad son: Deducir una cantidad dada de la cuenta A. Aadir esa cantidad en la cuenta B.

E1

Si en el ejemplo no se realizan las dos operaciones, la BD queda en un estado inconsistente. Muchos tipos de fallos pueden impedir que se realice una T completamente. Si el SGBD realiza procesamiento concurrente de transacciones, como tales conjuntos de operaciones son atmicos, si ocurre un fallo durante su ejecucin, el sistema tiene que garantizar su atomicidad.(Todo o nada). El manejador de T es el componente del sistema encargado de esta atomicidad. Los mecanismos de recuperacin varan segn el medio de almacenamiento utilizado.

Voltil. La informacin en este tipo de medio no sobrevive a fallos del fluido elctrico o del sistema. No voltil. Normalmente sobreviven a cadas del sistema pero estn sujetos otro tipo de fallos como por Ej Rotura del cabezal. Estable. No voltil redundante, con medios de actualizacin controlada.

Tipos de fallos ms frecuentes.

Errores lgicos. La T no puede continuar por alguna condicin interna (overflow) o un exceso de recursos solicitados no disponibles. Errores del sistema. La T entra en estado no deseable (bloqueada) pero puede continuar ejecutando ms tarde. Cada del Sistema. Error de Hardware que provoca la prdida de la memoria voltil. Fallo de disco. Fallo en una operacin de E/S o Rotura del cabezal del disco duro. Los atiende

Errores lgicos. Gestor de Transacciones Errores del sistema. Gestor de Transacciones Cada del sistema. Gestor de Transacciones Fallo de disco. Medios de salva. Procesamiento de Transacciones. Una T comienza al ejecutarse con xito un Begin Transaction y termina cuando llega a su final felizmente o se ejecuta un Commit o un RollBack. El Commit convierte en permanentes todos los cambios realizados a la BD y establece lo que se llama un punto de sincronizacin. En estos puntos, se supone que la BD est en un estado consistente. Este punto representa el lmite entre dos T consecutivas
80

El RollBack provoca que se deshagan todas las acciones ejecutadas desde el anterior Begin, hasta el estado que tena antes de ese Begin. Tanto uno como el otro, terminan la transaccin y no al programa. Las T deben cumplir: Propiedad ACAD.

Atomicidad. Se ejecuta todo o nada. (Commit o Rollback). Consistencia. Lleva a la BD de un estado consistente a otro. Puede ser responsabilidad del programador. Aislamiento. Las T se ejecutan aisladas unas de otras, aun cuando exista concurrencia. Para cualquier par de Ts T1 y T2. A T1 se le permite ver las actualizaciones de T2 despus del commit de T2 y a T2 se le permite ver las actualizaciones de T1 despus del commit de T1 pero nunca ambos. Durabilidad. Una vez que una T ha ejecutado un commit, sus actualizaciones sobreviven aun si el sistema falla.

Estados de una T
Despus de ejecutarse una sentencia puede producirse un fallo que la haga abortar Cuando se ha grabado en disco el nuevo estado del sistema

Parcialmente ejecutada

Cometida

Activa

En fallo

Abortada

Cuando no se puede seguir su ejecucin normal

Despus que se retrocede y la base de datos ha sido llevada a su estado anterior

Despus que se ha abortado una T, se tienen dos posibilidades:

Reiniciarla. Si no abort por fallo en su lgica interna o falta de datos en la BD. Eliminarla. Si abort por fallos de lgica interna o falta de datos en la BD.

Los comandos COMMIT y ROLLBACK le comunican al Gestor de T respectivamente si:

se ha llegado a un nuevo estado consistente y debe hacerlo permanente. (COMMIT) se deben deshacer las modificaciones realizadas hasta el momento. (Si hizo alguna). ROLLBACK

La ejecucin de uno de ellos establece, como se ha dicho, un Punto de Sincronizacin. Tambin se establece uno, cuando comienza un programa y no se establece otro explcitamente.(todo el programa es una T). Se producen automticamente los Commit y los Rollback, dependiendo de si se termina o no satisfactoriamente. Cuando los programas (Acciones) son cortas, no hay grandes problemas pero si son
81

largas, se debe dividir el programa en pequeas T utilizando los comandos: BeginTransaction y EndTransaction. Esquemas o herramientas de Recuperacin ante fallos. Los Esquemas de Recuperacin ante fallo ms usados son: 1- Basada en diario o Bitcora. 2- Doble paginacin.(No se discutir). Los basados en diario o Bitcora pueden ser :

Con modificacin diferida de la BD. se espera hasta el comando Commit. Con modificacin inmediata de la BD. se graba cada cambio inmediatamente en la BD

Basada en Diario. Se mantiene en memoria interna (on line) y en externa (off line), una lista de todas las actualizaciones realizadas a la BD para cada T. Si una T es cometida, el sistema debe garantizar la actualizacin de la BD aun cuando el sistema se caiga en el siguiente
T

Una act.

Otra

Commit Cada del Sist.

momento. Cuando la lista on line se llena, se pasa su contenido a la lista off line. La diferencia entre actualizacin inmediata y diferida, radica en que en la de actualizacin inmediata, se graba en la BD cada cambio en el momento que ocurre y en la diferida, se espera hasta el siguiente comando Commit. Las T Cometidas antes del fallo, se Rehacen con el diario y las que no se terminaron, se Deshacen hasta el estado anterior, para luego volver a intentar su ejecucin. Informacin del diario para realizar este trabajo. 1.- Un registro para cada actualizacin con los datos : Nombre de la T. Nombre del campo. ValorViejo. ValorNuevo. <Ti,Ci,Vv,Vn> 2.- Un registro para indicar el inicio de cada T. <Inicia Ti> 3.- Un registro para indicar el final exitoso de T. <Termina Ti> Las tres primeras causas de fallos las gestiona el Gestor de Transacciones; la cuarta, se maneja con los medios de Salva. El estado de las Ts activas en el momento de un fallo global es desconocido, por lo que al arrancar el sistema, deben ser deshechas y reiniciadas. Incluso es posible que sea necesario hacer lo mismo con Ts que terminaron antes fallo pero antes tambin de grabarse en la BD (punto de sincronizacin). Cmo saber cules Ts deshacer y cules rehacer al arrancar el sistema? Cada determinado tiempo (cuando cierta cantidad de acciones se escriben en el diario), el sistema produce una seal que provoca la grabacin de los buffers de la BD en memoria, en la BD fsica y a esto se le llama puntos de chequeo y grabar el registro de
82

punto de revisin en la bitcora. La figura que se muestra ms adelante, se lee de la forma siguiente: 1. 2. 3. 4. 5. 6. 7. Ocurri un fallo global en tf. El punto de chequeo anterior ocurri en tc. Las Ts de tipo T1 comienzan y terminan antes de tc. Las Ts de tipo T2 comienzan antes de tc y terminan entre tc y tf. Las Ts de tipo T3 comienzan antes de tc y terminan despus de tf.. Las Ts de tipo T4 comienzan despus de tc y terminan antes de tf. Las Ts de tipo T5 comienzan despus de tc y terminan despus de tf.

Ejemplo . T 1 T 2 T 3 T 4 T 5

TpoChequeo

Tpo de Fallo. Informacin del Diario <PtoDeSincronizacin, T2, T3> -- Actualizacin de T2 y T3 <TerminaT2> --Actualizacin de T3 <ComienzaT4> --Actualizacin de T3 y T4 <ComienzaT5> -- Actualizacin de T3, T4 y T5 <TerminaT4> -- Actualizacin de T3 y T5 >Fallo

tc

tf

Ejemplo. Sea T1 la T que transfiere $10.00 de la cuenta A hacia la B y T2 la que resta 100 de C. T1: Leer A T2: Leer C A= A -10.00 C= C - 100.00 Act. A Act. C Leer B Supngase que se ejecutan B=B + 10.00 una seguida de la otra con Act. B valores A= 100, B=100, C=600. Un viaje desde Alaska hasta Chile sin "Puntos de Sincronizacin", obliga a regresar hasta Alaska para iniciar el viaje, cada vez que se produzca algn problema en el mismo. Si se usan "Puntos de Sincronizacin", slo se regresa hasta el ltimo "Punto al que se lleg" o Puntos de Sincronizacin que se registr. Estos puntos implican lo siguiente: a.- Grabar fsicamente los buffers de Datos en la BD. b.- Grabar un registro de <PuntoDeChequeo > en el diario. De esta manera, slo se usar la informacin del diario que sigue al ltimo Punto de
83

Chequeo. Los "Puntos de Sincronizacin" son paradas seguras e intermedias en los viajes que realiza la BD. El estado del diario despus de este proceso slo registra las actualizaciones de las Ts que no han terminado y sern las nicas activas. Las que terminaron antes del fallo, dejan de manera permanente sus acciones en la BD al concluir el Rehacer. El fallo global provoc un punto de chequeo y es a partir de ese momento en adelante que se definen las acciones del diario para continuar el procesamiento. CONCURRENCIA La multiprogramacin, como ventaja de los sistemas actuales, introduce un posible problema en los SGBD y es el que se presenta cuando "la ejecucin de T correctas, concurrentemente, produce resultados incorrectos". Los SGBD concurrentes necesitan de un mecanismo de control de concurrencia para evitar esos problemas. Se pueden presentar tres tipos de problemas: 1. Actualizacin perdida. 2. Acceso a datos no Cometidos. 3. Anlisis Inconsistente. Actualizacin perdida. Sean Ta y Tb dos T que ejecutan concurrentemente como sigue:

La Ta Lee algn registro R en t1, Tb lo lee en t2 pero Ta lo actualiza antes que Tb, de modo que el valor final de R ser el que deje Tb independiente del que le corresponda al de Ta. Se pierde una actualizacin.

Ta Leer R Act. R

Tb t1 t2 Leer R t3 t4 Act. R

Acceso a datos no confirmados

Ta Tb Se presenta cuando se permite a una T 1 leer (o peor) t1 Act. R actualizar un registro que ha sido actualizado por otra Leer R t2 Fallo local T2 pero esta ltima aun no se ha cometido. El problema t3 Rollback se presenta cuando T2 es retrocedida. La primera lee datos que no existieron nunca en la BD. Sean Ta y Tb dos T que ejecutan concurrentemente como sigue: Tb Act. un registro en t1 que es ledo por Ta en t2 y Tb es deshecha en t3. Ta est ejecutando con un valor errado de R y si es cometida antes de una cada del sistema se llega a resultado errneos.

Anlisis Inconsistente. Se presenta cuando una T capta datos de un estado inconsistente de la BD y por tanto llega a resultados inconsistentes. En este caso no es una actualizacin no cometida. Es
84

una actualizacin hecha sobre un registro que ya se trat en la Tb pasando un valor para una cuenta que ya fue atendida en Ta. Sean Ta y Tb dos T que ejecutan concurrentemente como sigue: Los valores iniciales de las cuentas son Cuenta1=40, Cuenta2=50, Cuenta3=30. Ta Lectura irrepetible porque ya se ley Cuenta1 Tpo Tb

Lee Cuenta1 t1 Se necesita un mecanismo de control del uso concurrente de recursos para evitar estos Suma=40 casos. Algunos de ellos son: 1.-Cierre o bloqueo. 2.-Marcas de tiempo. 3.-Tcnicas de validacin. 4.-Esquemas multiversin Lee Cuenta2 Suma=90 t2

t3 Lee Cuenta3(30) t4 Act.Cuenta3 (20) -----t5 Lee Cuenta1(40) -----t6 Act.Cuenta1 (50) Cierre o bloqueo. ----t7 Commit Tb Lee Cuenta3 t8 Los tres problemas planteados anteriormente se pueden resolver usando tcnicas de Suma=110 cierre o bloqueo. Cuando una T necesita que 120 Debe ser un recurso (un registro) no cambie mientras ella lo utiliza, lo bloquea. As, la T que solicit el bloqueo, puede ejecutar con confianza. Tipos de bloqueos: Exclusivo(x) y Compartido(s) Exclusivo.- Si una Ti tiene un x/R, a las dems que solicitan s/R o x/R se les obliga a esperar. Compartido.- Si una Ti tiene un s/R, las dems slo pueden obtener otro s/R. Para obtener un x/R tienen que esperar. Estas reglas definen lo que se conoce como Protocolo de acceso a datos. Matriz de Compatibilidad.
X X S NO NO NO SI S NO SI SI NO SI SI SI

Solucin a los problemas planteados usando el Bloqueo. 1.- Actualizacin perdida. En la figura se muestra como la actualizacin de t3 no se puede realizar porque la solicitud implcita para escribir que genera, no se otorga debido a que Tb tiene un bloqueo de lectura sobre ese recurso y en ese caso se pone en espera.

85

2.- Acceso a datos no

Sean Ta y Tb dos T que ejecutan concurrentemente confirmados como sigue: sobre R Sean Ta y Tb dos T que ejecutan concurrentemente Ta Tb sobre R R t1 sigue: Leer como

Abrazo fatal.

Ta adq.S/R t2 Tb Leer R t1 actualizar R Leer R Adquirir X/R No se pierde la actualizacin pero aparece otro problema. El bloqueo mutuo. Solic S/R t2 Situacin en la que dos o ms T caen t3 adq.S/R simultnea porque una de ellas en espera espera un recurso que necesita otra. Para su solucin, se puede hacer una de dos cosas: actulizar R leer R t3 SolicX/R Rollback implica adquirir S/R liberar bloqueos. t4 1.- Evitarlo. Es un punto de espera 2.- Detectarlo y romperlo. Sincronizacion actulizar R SolicX/R Evitarlo. espera espera

retiene

1.- Que cada T bloquee todos sus recursos al inicio. 2.- Ordenacin parcial de datos. 3.- Retroceder a cualquier T que intente utilizar recursos reservados.. Este ltimo camino cuenta con un algoritmo interesante por lo eficiente y simple basado en marcas de tiempo que se recomienda estudiar, si alguna vez es necesario profundizar en el tema. Detectarlo y romperlo. Casi todos los sistemas de gestin de Ts cuentan con algoritmos para detectar los abrazos fatales y destruirlos. La deteccin de los abrazos fatales consiste en detectar ciclos en el Grafo de espera. Los grafos de espera, bsicamente, son grafos donde se representa mediante nodos a las Ts y mediante arcos, a la secuencia de espera entre las Ts por recursos ocupados. Un ciclo en tal grafo, significa que hay un abrazo fatal y para romperlo es necesario hacer que retroceda Sean Ta y Tb dos T que ejecutan alguna T involucrada en el ciclo. concurrentemente cul sigue: Hay variadas polticas para determinar como de las Ts se elige para el retroceso. No es inters de este curso profundizar en tales aspectos . Baste decir que a la T elegida se le Ta Tb denomina vctima y que se debe garantizar que la vctima no sea siempre la misma porque nunca terminara de ejecutar, crendose otro problema denominado Inanicin. Lee X t1 X=40 sum=40 Adq S/X 3.- Anlisis inconsistente. Leer Y t2 Y=50 sum=90 Adq S/Y En la figura de la derecha, se muestra como la actualizacin de t6 no se puede realizar t3 Lee Z porque la solicitud implcita para escribir que genera, no se otorga debido a que Ta Adq S/Z Z=30 tiene un bloqueo de escritura sobre ese recurso y por lo tanto, se pone en espera. . Lo t Act Z Z=30mismo ocurre en t7 cuando Ta solicita4una lectura sobre Z, recurso que est bloqueado 10 para escritura por Tb. Note que Tb aun no ha terminado. Ambas Ts quedan en un abrazo fatal, e la misma forma que en el primer Adq X/ Z caso. t5 Leer X Adq S/X t6 Actualiza X Soli X/ X espera 86 Leer Z t7 Solic X/Z espera

INTEGRIDAD La Integridad como concepto est muy ligada a la seguridad aunque ella se ocupa de otra cosa. La diferencia est en que mientras:

La seguridad protege contra accesos no legales La integridad protege contra valores ilegales en la BD.

Los SGBD no siempre garantizan este tipo de proteccin y los programadores no siempre tienen la suficiente capacidad para considerarla en toda su dimensin. Una Restriccin de integridad (RI) es un Predicado (L) que debe ser satisfecho en todos los estados legales de la BD. Si un usuario realiza una operacin cuyo resultado es ilegal, el SGBD debe rechazarlo de alguna manera Consideraciones necesarias. En este tema se tratarn las RI especficas de las BD que se suelen llamar Reglas del Negocio. Es importante tener presente que: Se acostumbra a pensar en RI aplicables slo a tablas base. Sin embargo, las relaciones derivadas tambin tienen que responder a semejantes reglas. Las relaciones derivadas heredan algunas RI pero en algunos casos, ellas tienen que responder a reglas especficas de mayor o menor fuerza que las heredadas. Es claro que en muchos casos sera saludable poder definir reglas (de llaves candidatas por ejemplo), para algunas relaciones derivadas.

Se concentra la explicacin en RI declarativas, a pesar de que los SGBD ms recientes, ponen el nfasis en reglas procedurales o basadas en triggers, es decir, reglas activas. Se dice que si los SGBD soportan RI declarativas, el 90% de las reglas necesarias queda incluido en ellas. Si no es este el caso, los programadores de sistemas tendrn una gran responsabilidad y una enorme carga de trabajo. El soporte de RI declarativas, es un rea sumamente importante. El trmino Integridad, tiene que ver con la consistencia o correccin de los datos que forman la BD. Decir que una BD est en un estado de integridad, significa que la BD es correcta, que no viola ninguna RI conocida. En otras palabras: "una BD es correcta si y slo si, satisface el AND de todas las RI definidas para ella". Un sistema que no tenga un soporte fuerte de RI, tendr un sentido muy dbil del concepto de consistencia. En los temas Recuperacin y Concurrencia, la premisa era que la BD se movera entre estados consistentes y el papel ms importante en esta definicin
87

le corresponde a las RI. Sin embargo, no se debe confundir la consistencia con la integridad. Una BD puede ser ntegra y no consistente. La integridad es necesaria pero no suficiente para la consistencia. Ej. Los valores de saldos de las cuentas bancarias pueden cumplir con todas las reglas de integridad sin embargo es posible que la suma de efectivo que se supone que existe no se corresponda con el real en caja sin que se produjeran sustracciones ilegales. Esto se puede pasar por efectos de actualizaciones perdidas.

Tanto las RI como las restricciones de seguridad, se mantienen en el catlogo de la BD y el subsistema de integridad del SGBD se encargar de chequear su cumplimiento, mientras los usuarios manipulan la BD.

RI. Para explicar la estructura de una RI, se usa un ejemplo: CREATE INTEGRITY RULE Pp4 FOR ALL PX ( PX . Peso > 0 ) ON ATTEMPTED VIOLATION Reject Se usa en este ej. el lenguaje hipottico de costumbre para declarar que, el peso de las piezas tiene que ser positivo. El propsito del ej. es, definir las tres partes que forman a las RI. .Nombre. Identificador de la regla en el catlogo del sistema. .Restriccin. Expresin que tendr que satisfacer el objeto de datos. Violacin. Indica que accin tomar el sistema si es falsa la expresin. Nota de sintaxis: La restriccin en las reglas, casi siempre comienzan con un cuantificador universal y si no es as, colocar uno no cambia el significado. Por esa razn, se omiten los cuantificadores (para simplificar) y se supone que siempre estn presentes. Al crear una RI, el sistema tiene que comprobar si la BD cumple con ella. En caso que no, se rechaza a la regla; en caso que si, se almacena en el catlogo y se aplica en el futuro. Se requiere tambin de un comando para destruir a las RI: DESTROY INTEGRITY RULE Pp4 Las RI se clasifican en cuatro categoras que son:

Una RI de dominio especifica valores legales para un dominio. Una RI de atributo especifica valores legales para un atributo. Una RI de relacin especifica valores legales para una relacin. Una Regla de BD especifica valores legales para una BD dada.

Reglas de dominios. Las RI de dominios son las definiciones extensionales o intensionales, de los conjuntos de valores que forman a esos dominios. En este sentido, no es necesaria una RI de dominio si existe el comando CREATE DOMAIN.
88

Ejemplo: CREATE DOMAIN Cantidad Numeric (9) FORALL Cantidad (Cantidad > 0 AND Cantidad 5000 AND Mod (Cantidad, 50 ) = 0 ); donde: El nombre de la regla es el nombre del dominio. Se chequea a los atributos. No existe el concepto de violacin de la regla. La restriccin para un dominio se especifica como una frmula del clculo relacional (clculo de dominios), en la que: a) hay exactamente una variable. b) est cuantificada universalmente. c) su valor pertenece al dominio. La destruccin de una regla de restriccin de dominio slo

Ejemplo de definicin extensional de un dominio. CREATE DOMAIN Colores Char (9) VALUES ("Rojo", "Amarillo", Azul", "Verde"); o tambin: CREATE DOMAIN Colores Char(9) FORALL Colores (Colores = "Rojo" OR Colores = Amarillo" OR Colores = "Azul" OR Colores = "Verde"); Reglas de integridad de atributos. La RI de un atributo dado, es la definicin del dominio del cual se extraen los valores que tomar ese atributo. En este sentido, no es necesario una RI de atributos. Esto se hace en la definicin del atributo. Ejemplo: Snombre DOMAIN (Nombre) Este comando se ejecuta como parte de la definicin de la BD al ejecutar: CREATE BASE RELATION Suministrador Reglas de relaciones. Una regla de relacin, para una tabla base dada, es una regla para esa relacin especfica. Por ejemplo: CREATE INTEGRITY RULE Sr7 FORALL S(If S.Ciudad= "Cerro" Then S.Prov = "C.Habana") ON ATTEMPTED VIOLATION Reject; Los suministradores del Cerro viven en C.Habana.

Seguridad en las bases de datos

89

VII. Bases de datos distribuidas

CONTENIDO: 1. Surgimiento de los SBDD 2. Definicin de SBDD 3. Objetivos de los SBDD 4. Funciones del SGBDD 5. Diseo del los SBDD 6. Arquitectura de las BDD 7. Distribucin de los datos 8. Dificultades de los SBDD DESARROLLO: 1. Surgimiento de los SBDD Premisas:

Desarrollo de redes de MCE en los 70-80 => acceso de datos a distancia, intercambio y actualizacin de datos (tambin redes locales). Desarrollo del Hardware y Software => acceso a las computadoras por no especialistas Reduccin del costo del Hardware => uso de micros y minis a bajo costo en forma local, se mantiene el costo de utilizacin de las lneas => no provechoso MCE central transmitiendo mucho desde y hacia terminales.

Vas a partir de las cuales surgen los SBDD: Son dos: Los SBD centralizados: -dificultades en la transportacin de datos -alargamiento de los plazos de entrega Soluciones a esos dos problemas: terminales no inteligentes con MCE central que poco a poco fueron adquiriendo ms funciones y capacidad de procesamiento y almacenamiento de pequeas BD hasta lograr que su interconexin de paso a las BDD. La existencia de BD sobre micro y mini y su posterior interconexin llevan a la descentralizacin.
90

Aspectos generales: Ambas vas permitieron desconcentrar medios tcnicos y distribuir funciones y datos que provocaron el surgimiento de las BDD. 2. Definicin de los SBDD Sistemas distribuidos: varios nodos conectados por canales cada nodo puede procesar programas y almacenar datos cada nodo no necesita tener igual configuracin los nodos son equivalentes y deciden autnomamente si procesan una tarea o la pasan a otro nodo el sistema es transparente para los usuarios. Date: "Un sistema distribuido es cualquier sistema que comprenda mltiples nodos interconectados en algn tipo de red de comunicacin, en el cual un usuario (usuario final o programador de aplicaciones) en cualquier nodo puede accesar a datos almacenados en cualquier nodo" Cada nodo puede a su vez ser visto como un SBD con su DBA, terminales y usuarios, CPU, memoria y DBMS. 3. Objetivos de los SBDD a. Comparticin de los datos entre los nodos b. Almacenamiento de datos en los lugares de su uso frecuente (evita costos de transmisin y reduce tiempos de respuesta) c. Accesos transparentes a la ubicacin del dato d. Crecimiento (nuevos nodos y aumento de la base de datos en cada nodo). e. Confiabilidad (funcionamiento de nodos restantes dado falla en uno o mas nodos) Date plantea b. d. y e. como "ventajas" Los SBDD estn formados por varios SGBD ubicados en cada uno de los nodos de una red de MCE, compartiendo datos, Sw y Hw. Segun Date:

Accesos transparentes a la ubicacin del dato Fragmentacin de datos (un objeto lgico se divide en fragmentos.Un fragmento es cualquier subrelacion arbitraria que es derivable de la relacin original mediante seleccin y proyeccin, excepto que en el caso de la proyeccin se debe preservar la llave primaria de la relacin original. Transparencia de la fragmentacin (facilidad del modelo relacional para la fragmentacin y su transparencia). Ser capaz de permitir la existencia de datos replicados y que ello sea transparente para el usuario. Desventaja de esto: actualizar todas las rplicas.

Si hay fragmentacin, la unidad de replica es el fragmento, no la relacin lgica completa. 4. Funciones de los SGBDD
91

Los SGBDD externamente trabajan como un SGBD, con sus mismas funciones y otras adicionales: Descripcin de la BDD Define el esquema global que contemple cada uno de las BD locales (ubicacin fsica y descripcin lgica) Diferencias entre BDD y BD descentralizada: transparencia en la distribucin (visto como objetivo de los SBDD) Manipulacin de la BDD Posibilidad de obtener datos que se encuentren en cualquier nodo. Para ello, un requerimiento global se descompone en subrequerimientos locales que se dirigen a los nodos. Pasos del SGBDD para acceder a un dato: -determinar si el dato es local o no -si no es local, determinar ubicacin y rutas de acceso -enviar subrequerimientos a los nodos -recibir respuestas en una respuesta global Todo esto debe ser transparente al usuario. Control total Se ejerce descentralizadamente. El SGBD interacta sobre los medios de comunicacin.

5. Diseo de los SBDD Enfoque descendente:

El sistema se disea como distribuido, definiendo y asignando las funciones entre los nodos. El resultado es un sistema homogneo con un solo tipo de SGBD y solo un tipo de modelo de datos. Enfoque ascendente:

Se integran varios SGBD en un todo nico. El resultado es un sistema heterogneo. 6. Arquitectura de las BDD Se define por niveles. Cada nivel es una vista diferente de la BD y consta de un procesador encargado del tratamiento de las transacciones interniveles. Se definen las funciones propias de cada nivel, las que dependen solo de los niveles adyacentes. Los niveles son: VU- (vista del usuario). Asociada al esquema externo. VS- (vista del sistema). Se corresponde con el esquema global. VDESL-(vista de la descomposicin lgica). descompone al esquema global de dos formas posibles: horizontal (proyeccin) vertical (seleccin) VDIS- (vista distribuida). Se define la ubicacin geogrfica de las particiones en los nodos de la red. Es el ncleo del SBDD. Estas particiones corresponden con la descomposicin del nivel anterior. VN- (vista del nodo). Se realiza el encadenamiento de la transaccin con el nodo en cuestin. VAA- (vista de acceso y asociacin). Define el acceso a los datos a travs de las relaciones de los diferentes ficheros. VF- (vista fsica). Define las caractersticas fsicas de los ficheros y sus campos.
92

Las VU, VS, VDESL y VDIS son iguales es cada nodo y VN, VAA y VF son desiguales. Ventajas de la tcnica de niveles:

Reduce tiempo promedio de respuesta Existe un mayor control local de forma directa Fcil aumento del volumen de las BD y (o) aadirle nuevos nodos. Crece el grado de disponibilidad del sistema.

7. Distribucin de los datos

Segn la redundancia que posea la BDD (o sea, segn la duplicidad de los datos), pueden estar distribuidos segn tres mtodos:
1.

Cada BD de un nodo tiene copia completa de la BD total. Es poco practica (por tamao y dificultad de actualizacin) y redundancia total. Cada BD contiene datos que no estn en ningn otro nodo. Cero redundancia, pero si se requiere un dato con igual frecuencia en dos lugares, donde ponerlo?; adems, si hay fallo en un nodo implica la cada de todo el sistema.

2.

3. Cada BD tiene subconjuntos de datos, almacenados al mismo tiempo en otros nodos. Redundancia parcial.

Segn los segmentos del esquema global (obtenidos por proyecciones), vista a travs del modelo de datos:

Distribucin de las relaciones por nodo Por ejemplo:

Nodo 1 R1 R2

Nodo 2 R3 R4

Nodo 3 R1 R2 R3

Hay cierta redundancia Distribucin de las ocurrencias de una BD entre los nodos Combinacin de las dos anteriores. 8. Dificultades de los SBDD Procesamiento distribuido de preguntas

Es posible que haya que acceder a varios nodos => retraso en el procesamiento, pero existe posibilidad de procesamiento paralelo, Dado por los nodos involucrados en una pregunta. O sea, una pregunta se descompone en subpreguntas tratadas en diferentes nodos. Cuidar la estrategia de acceso a cada nodo para optimizar tiempo
93

Segn Date: si la BD no es relacional (que obtiene la respuesta una vez en una relacin), puede ocurrir el intercambio de muchos mensajes entre nodos, pues cada vez solo se recupera un articulo. Siendo relacional, es importante optimizar la solucin a la solicitud para que implique la transmisin del menor volumen de informacin posible. (Las operaciones relacionales son optimizables, las que recuperan record a record, no)

Restauracin de la base de datos.

En un SBDD las fallas son parciales lo que => un nodo no afecta todo el sistema (al menos que el dato este solo en el, lo que => la transaccin no se puede hacer) Recuperacin con nodo en falla: Sin problema, pues existen copias en otros nodos Actualizacin: se actualizan todos los que tengan la informacin, excepto el que esta en falla, arriesgndose la consistencia de la base. Distintas tcnicas para restaurar la BD de un nodo a partir de una falla:

Vaciados peridicos de la BD (parciales o totales) Ptos. de chequeo que recogen el estado de la BD Diario de las transacciones de actualizacin Diario de la BD, almacenando imagen antes y despus de la actualizacin. (Tcnicas iguales a las BD centralizadas)

Pasos para realizar la restauracin

Almacenar la BD desde el ultimo vaciado Ejecutar todas las modificaciones hasta el ultimo punto de chequeo (que refleja un estado de consistencia de la BD)

Despus del ltimo punto de chequeo o vaciado se pierden todas las actualizaciones. Tiene que hacerlas los usuarios. Puede haber situaciones ms complejas como por ejemplo, que ms nodos pierdan la comunicacin, etc. La recuperacin depende de la semntica de los datos, tipos de transacciones, etc. y necesita intervencin humana. (Segn Ullman): En el diario: escribir que se comienza y termina una transaccin. El nodo que hace la transaccin enva mensaje de terminacin a cada nodo en el que haya escrito informacin (antes de desbloquear). Se detecta un nodo en falla mandando un mensaje y esperando "agradecimiento" del otro nodo que no llega. En este caso se comprueba si en alguno de los nodos restantes se concluyo una transaccin y entonces todos los que tienen esa informacin la consideran completa. Si en ninguno se recibi el mensaje de concluida la transaccin, se vuelve atrs en todos los nodos. Para restaurar un nodo Cuando se concluye una transaccin si un nodo A descubre que otro nodo B que tiene
94

copia de ese mismo articulo afectado en la transaccin esta en falla, lo seala en su diario. Cuando ese nodo B va a recuperarse, manda mensajes a cada nodo, que examinan su diario hacia atrs hasta el punto en que descubri la falla y envan a B el mas reciente valor de cada dato que tiene en comn con B (Durante la restauracin de B, los valores de esos datos estn bloqueados) Sincronizacin de los procesos de actualizacin Una de las cuestiones que mas afecta la integridad y consistencia es sincronizacin de los procesos de actualizacin. Hay dos casos: varios procesos actualizando el mismo dato en diferentes nodos actualizacin con nodo en falla Pero la concurrencia de transacciones es ms general e incluye el primer caso. la

Tcnica usual: bloquear todas las porciones de la BD que estn siendo ledas y escritas. Se corre el riesgo del abrazo fatal. Se requiere tiempo para avisar a las partes de las BD en los diferentes nodos que se van a actualizar. Tiempo de ejecucin de la transaccin se hace mayor. El segundo caso se resuelve volviendo atrs o siguiendo y actualizando el nodo en falla cuando este se restaure.

95