DISEO de

BASES DE DATOS

LIC. ROSA MARIA MATO GARCIA

OCTUBRE 1999

TABLA DE CONTENIDOS

TEMA I: ASPECTOS INTRODUCTORIOS 1 Contenido: 1

Surgimiento histrico de las bases de datos integradas. 1 Objetivos de los SBD. 3 Arquitectura de un SBD 4

TEMA II: MODELACION CONCEPTUAL 8 Contenido: 8

Representacin de la informacin. 8 Caractersticas del modelo conceptual. 11 El Modelo Entidad-Relacin (MER). 12

TEMA III: MODELO LGICO-GLOBAL DE LOS DATOS. MODELO RELACIONAL 22 Contenido: 22

Modelo relacional. 22 Normalizacin. 25 Primera Forma Normal (1FN). 26 Segunda Forma Normal(2FN). 28 Tercera Forma Normal (3FN). 31 Forma Normal de Boyce-Codd (FNBC). 33 Obtencin del modelo relacional a partir del DER. 40 Metodologa para el diseo de bases de datos. 42

SISTEMAS DE BASES DE DATOS

TEMA I: ASPECTOS INTRODUCTORIOS

Contenido:

-Surgimiento histrico de las bases de datos integradas. -Objetivos de los SBD. -Arquitectura de un sistema de base de datos.

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:

1. Solucin de tareas aisladas.

2. Integracin de tareas aisladas en sistemas particulares.

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

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. Integracin de los datos.

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. Cada programa est altamente interconectado con sus ficheros, por lo que la integracin de datos de diferentes sistemas es imposible prcticamente.

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

1

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

Entonces, es 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.

Se tiene entonces la 3ra. categora:

3. Sistemas orientados a BD

en los que 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.

2

Objetivos de los SBD. 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.

Los objetivos fundamentales de los SBD 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 y 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 es 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 datos que solicita y en la forma en que lo solicita.

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

Seguridad (tambin llamada 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.

Recuperacin: 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.

3

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. Permite 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 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)

NIVEL LGICO GLOBAL

(Vista general)

NIVEL INTERNO

(Vista de almacenamiento)

4

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" diferentes, siendo cada una una representacin ms o menos abstracta de alguna porcin de la BD total y existir nicamente una "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.

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 de programacin convencional, tal como Pascal o C, o bien un lenguaje de programacin especfico de un 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 por un usuario en 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 articulo externo no es necesariamente igual a un articulo 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 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

5

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

6

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

7

TEMA II: MODELACION CONCEPTUAL

Contenido:

Representacin de la informacin Caractersticas del modelo conceptual. Modelo Entidad - Relacin.

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 caractersticas y propiedades.

2. El segundo nivel es el dominio de las ideas 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:

8

Atributo Color Cat_Doc

Dominio {Azul, Rojo, Verde,...} {PT, PA, A, I}

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

DPTO : departamento docente al que pertenece el profesor

Una ocurrencia de este artculo puede ser :

45112801731 Hdez 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 formada por dos tipos de objetos: SUMINISTRADOR y PRODUCTO, se puede tener la relacin "CANTIDAD", que establece la cantidad de

9

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, de los artculos. Si, por ejemplo, los objetos o entidades son Carn_Identidad y Persona, la correspondencia entre ellos es simple: a cada persona le corresponde un carn de identidad y viceversa.

Relacin

Persona Carn_Identidad de uno 1 : 1 a uno

Si las entidades son Profesor y Departamento, la relacin es ms complicada, porque en cada departamento trabajan varios profesores. La terminologa corriente expresa que la correspondencia de profesor a departamento es simple (cada profesor es miembro de un nico departamento), mientras que la correspondencia de departamento a profesor es compleja, pues cada departamento tiene, por lo general, muchos profesores.

Relacin

Departamento > Profesor de uno 1 : M a muchos

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.

A B A B A B Un ejemplo donde ambas correspondencias son complejas, lo es la relacin que se 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

PROFESOR ESTUDIANTE de muchos N : M a muchos

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

10

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.

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 determinadas estructuras de datos que poseen una capacidad descriptiva limitada (slo diferencian un rasgo semntico: el tipo de proyeccin (1:1, 1:n, n:m)).

2. Utilizan una terminologa que no es familiar al usuario del sistema, por lo que 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.

11

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 estudiamos anteriormente.

Las ocurrencia de entidades se clasifican en distintas entidades Ei, tales como "empleado", "departamento", etc. Existir un predicado asociado con cada entidad que permitir comparar si una ocurrencia arbitraria pertenece a una entidad dada. Las ocurrencias pueden pertenecer a ms de una entidad, o sea, las entidades no son mutuamente disjuntas. Por ejemplo: Una ocurrencia de la entidad "mujeres" tambin pertenece a la entidad "personas".

Una relacin es una relacin matemtica entre n entidades.

{ (e1, e2, ....en) | e1 E1, e2 E2, ...., en En } y cada elemento de esa relacin es una ocurrencia de relacin (e1, e2, ....en), 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 la re cin "matrimo " definida entre ocurrencias de la entidad "personas", o sea, "matrimonio" ={[e1, e2] | e1 "persona", e2 la nio "persona" }, el primer elemento en el tuplo puede aparecer en el rol de "esposo" y el segundo, en el rol de "esposa".

Informacin adicional sobre una entidad (adems de los predicados y las relaciones) se obtiene mediante los atributos asociados con la entidad. Ejemplos de valores que pueden tomar los atributos son: "rojo", "3", "Juan", etc. y ellos se clasifican en dominios mutuamente disjuntos, tales como "color", "edad", nombre, etc.

Un valor de un dominio puede ser equivalente a otro valor en un dominio diferente. Por ejemplo, "100" en el dominio "centmetros" es equivalente a "1" en el dominio "metros".

Un atributo se define en el MER como una funcin matemtica que establece una correspondencia desde una entidad o relacin hacia un dominio o un producto cartesiano de dominios:

atrib1: Ei Di1 x Di2 x .....x Din

atrib2: Ri Di1 x Di2 x .....x Din

SGBD Nivel Lgico Global

. . . . Nivel Externo

Modelo Conceptual

Nivel Interno Diseador de la BD

12

En la figura siguiente se muestran los atributos definidos para la entidad EMPRESA. El atributo NOMBRE hace corresponder a las ocurrencias de empresa con elementos del dominio NOMBRE DE EMPRESA. El atributo DIRECCIN establece una correspondencia desde la entidad EMPRESA hacia el par de dominios NOMBRE DE CIUDAD, NOMBRE DE CALLE. INGRESO Y EFECTIVO establecen ambos una correspondencia desde la entidad EMPRESA hacia el dominio VALOR MONETARIO. Ntese que un atributo se define siempre como una funcin, por lo que siempre hace corresponder a una ocurrencia dada con un nico valor de una tupla, pues se define un producto cartesiano de dominios.

ENTIDAD ATRIBUTOS DOMINIOS

Las relaciones pueden tambin tener atributos. En la figura siguiente, el atributo UTILIZACIN define el nmero de horas que un obrero especfico ej usa una mquina ei y constituye un atributo de la relacin correspondiente. l no es ni un atributo del OBRERO ni de la MQUINA, ya que su significado depende de la relacin entre ellos dos.

VALOR MONETARIO

NOMBRE

EFECTIVO

CEDICO

La Habana

NOMBRE DE EMPRESA

NOMBRE DE CIUDAD

Ave 26

NOMBRE DE CALLE

3 500

2 500

DIRECCION

INGRESO

e

13

RELACIN

HORAS

MQUINA

OBRERO

UTILIZACI

ei

ej

ENTIDAD ATRIBUTOS DOMINIOS

Es importante destacar las siguientes caractersticas de los atributos en este modelo:

1. Los atributos slo son correspondencias funcionales. As, por ejemplo, si tenemos la 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 dominio. Si se desea representar otra propiedad, el atributo asociado 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 atributo COLOR en una entidad.

El MER tiene asociada una representacin grfica denominada Diagrama Entidad-Relacin (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 de las entidades se representan subrayndolos.

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 de, a lo sumo, 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 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 corrrespondencia. Por ejemplo, una empresa puede tener varios (n) trabajadores asociados y un trabajador pertenece a una sola (1)empresa. 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.

14

Es posible extender la capacidad semntica del MER aplicando sobre sus objetos bsicos (entidad y relacin) diferentes operaciones:

Valormonetario

Salario

Aos

Precio

Valormonetario No.Pieza

n

1

Trab-Persdep

Nmero

Cantidad

p

Valormonetario Nombre-mquina

#-mquina

Valor

Horas

n

Nombre n

1

Valormonetario

Presupuesto

Nombrede empresa

EMPRESA

TRABAJADOR

Empresa-trabajador

Num-id

Nombrespropios

Apellidos

trab-mq

Calificacin

trab-maq-pieza

MQUINA

m

m

PIEZA

Nombrespropios

Edad Nombre

PERSONA-

DEPENDIENTE

15

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

2. Agregacin: Construye una nueva entidad sobre la base de una relacin.

3. Agrupamiento: Define una nueva entidad, donde cada ocurrencia es un grupo de 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 entidades (que pueden a su vez ser resultado de una generalizacin), la generalizacin define una nueva entidad T con el siguiente significado:

T = { t | t Ti , 1 i n} o sea, para cada ocurrencia t en T existe, al menos, un conjunto Ti que contiene a esa 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 la entidad "obrero", por ejemplo, es siempre (o sea, en todo momento) un subconjunto de la 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:

Ntese que hemos introducido un nuevo atributo para la entidad

trabajador. Este atributo nos permite distinguir entre los miembros de diferentes clases de trabajadores.

Tipo de Trabajo

Num-idTRABAJADOR

ADMINISTRATIVO DIRIGENTE

OBRERO

Si tenemos una 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 ocurrencia de TRABAJADOR pertenece a uno u otro componente de la entidad. Entonces la representacin de esta operacin en el DER se generaliza como se muestra en la figura siguiente:

16

Tipo de trabajo=1

Tipo de trabajo=2

Tipo de trabajo=3

ADMINISTRATIVO DIRIGENTE OBRERO

TRABAJADOR

Si para cada ocurrencia de la entidad Trabajador nosotros podemos siempre deducir a cul entidad componente pertenece usando alguna propiedad ya representada, entonces no es necesario introducir un nuevo atributo Tipo de Trabajo.

Las reglas que definen la especializacin de una entidad se denominan "caracterizaciones". Por ejemplo, Tipo de Trabajo = 1 es la caracterizacin de la entidad Administrativo dentro de la entidad Trabajador.

En una Generalizacin / Especializacin, los atributos y relaciones de la entidad "generalizada" son heredados por las entidades componentes (entidades especializadas). Adems, se pueden definir nuevos atributos y relaciones para cada conjunto entidad especializada. Por ejemplo, la relacin Obrero-Mquina se define ahora slo para la entidad especializada Obrero, componente de la entidad generalizada Trabajador:

Si bien es cierto que, segn lo visto hasta anteriormente, las operaciones de Generalizacin y Especializacin pueden denotarse de modo diferente, no es menos cierto que, con la notacin empleada para la generalizacin, pueden expresarse las entidades generalizadas y especializadas perfectamente y es sta la empleada normalmente.

S es importante agregar algo ms a lo visto hasta ahora para poder expresar las siguientes situaciones que se presentan :

TipodeTrabajo

Num-id

TrabDep

MQUINA

TRABAJADOR

ADMINISTRATIVO DIRIGENTE

OBREROn m

Obr-Mq

17

Las ocurrencias de las especializaciones pueden abarcar o no el universo de las ocurrencias de la generalizacin, es decir, la totalidad de las ocurrencias de la generalizacin pueden o no estar contenidas en alguna o algunas de las especializaciones. Por lo tanto, las especializaciones pueden se totales (T) o parciales (P).

Una ocurrencia de la generalizada puede o no estar en ms de un conjunto Ti, o lo que es lo mismo, la interseccin entre algunos de los conjuntos Ti puede o no ser vaca. Es decir, las especializaciones pueden ser solapadas (S) o disjuntas (D).

Es por ello que, en el DER, se aade en cada generalizacin, entre parntesis, la especificacin:

(T, S): indicando que la especializacin realizada es total y solapada (T, D): indicando que la especializacin realizada es total y disjunta (P, S): indicando que la especializacin realizada es parcial y solapada (P, D): indicando que la especializacin realizada es parcial y disjunta

Entonces, el ejemplo visto anteriormente quedara: Num-id

T (total): ya que todo trabajador en el ejemplo es administrativo o dirigente u obrero y D (disjunto): pues un trabajador pertenece slo a una de las especializaciones.

Otro ejemplo de Generalizacin/Especializacin podra ser el caso de Estudiante, Alumno Ayudante y Becario. Un alumno ayudante es un caso especial de estudiante. Lo mismo ocurre con becario. Pero un alumno ayudante tambin puede ser becario. Hay muchos estudiantes que no son alumnos ayudantes ni becarios. Obviando los atributos en el DER, se representara del modo siguiente:

ESTUDIANTE

ALUMAYUD

(P, S)

BECARIO

Tipo de Trabajo

TRABAJADOR

ADMINISTRATIVO DIRIGENTE

OBRERO(T, D)

18

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:

Cantidad

Nmero

p

1

Equipo-Pieza

n m Obrero-mq OBRERO MQUINA

EQUIPO

PIEZA

La agregacin se define de la siguiente forma:

Si T1, T2, ...., Tn son entidades, la operacin define una nueva entidad T con el significado siguiente:

T = {t | t1, t2, ...., tn (t1 T1 t2 T2 ... tn Tn (t1, t2,.., tn) = t)} O sea, las nuevas ocurrencias se forman como tuplas de ocurrencias de las entidades componentes. Para que la operacin tenga sentido, las entidades T1, T2,..., Tn tienen que formar parte en alguna relacin comn y esa relacin siempre ser incluida en la representacin de la entidad generada (entidad agregada).

A la nueva entidad se le pueden asignar atributos. Tambin puede tomar parte en cualquier relacin. Otro ejemplo de Agregacin se muestra a continuacin:

19

Cantidad Enviada

Fecha del envo

Fechas

p

n

m

Suministrador-Pieza-Proyecto

ENVO

Nmero SUMINISTRADOR PIEZA PROYECTO

La nueva entidad ENVO se define como una agregacin de tres entidades: Suministrador, Pieza y Proyecto con los nuevos atributos Fecha de envo y Cantidad enviada. Hay una diferencia importante entre estos dos atributos: Est claro que la Fecha de envo no puede pertenecer a ninguna de las entidades componentes, sin embargo, la Cantidad enviada se refiere claramente a las piezas. Diremos entonces, que la Cantidad enviada es una "caracterizacin" de la entidad PIEZA con respecto al ENVO.

3. Agrupamiento

Si T designa a alguna entidad y T1, T2, ..., Tn son dominios asociados con T o entidades relacionadas con T va alguna relacin, entonces, el operador de Agrupamiento construye una nueva entidad agrupada o agrupamiento Tg, donde cada elemento es un conjunto de ocurrencias de T, tales que, dentro de cada uno de tales conjuntos, todas las ocurrencias tienen los mismos valores y entidades relacionadas desde las entidades T1, T2,, Tn asociadas. Los tipos T1, T2,., Tn se llamarn tipos ndice y T se llamar base.

Por ejemplo, podemos usar el atributo Salario del DER anterior para formar una entidad agrupada a partir de la entidad Trabajador. Cada ocurrencia de Trabajador dentro de un grupo, que representa a una ocurrencia en Trabajadores de igual salario, tiene el mismo valor del salario.

SALARIO

TRABAJADOR

Trabajadores de igual salario

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 entidades. Por ejemplo, las entidades PERSONA, TRABAJADOR, OBRERO forman una jerarqua de entidades, sucesivamente ms especializadas. Entonces, una entidad existente en un nivel dado, tiene que

20

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 una entidad agregada sobre la base de una relacin, por lo que dicha entidad se comportar de forma similar a como se comporta la relacin. Entonces, para que una ocurrencia de la agregacin exista, deben existir las ocurrencias de todas las 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, al menos, una ocurrencia de la entidad agregada ENVO para un suministrador es indispensable para la existencia de la ocurrencia de ese suministrador en la 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 conjunto 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.

21

TEMA III: MODELO LGICO-GLOBAL DE LOS DATOS. MODELO RELACIONAL

Contenido:

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

Modelo relacional. Uno de los modelos matemticos ms importantes y actuales para la representacin de las bases de datos, es el enfoque relacional.

Se basa en la teora matemtica de las relaciones, suministrndose por 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.

El trmino relacin se puede definir matemticamente como sigue:

Definicin: Relacin

Dados los conjuntos D1, D2, .....Dn (no necesariamente distintos), R es una relacin sobre esos n conjuntos si est constituida por un conjunto de n-tuplos 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.

Es conveniente representar una relacin como una tabla bidimensional donde cada fila representa un n-tuplo.

COLUMNAS(atributos)

FILAS (ocurrencias)

. . .

. . .

22

En el modelo relacional, tanto los objetos o entidades, como las relaciones que se establecen entre ellos, se representan a travs de "tablas", que en la terminologa relacional se denominan relaciones.

Cada relacin est compuesta de filas (las ocurrencias de los objetos) 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)

Es importante lo siguiente:

1. No hay dos filas (tuplos) iguales.

2. El orden de las filas no es significativo.

(1 y 2 se deben a que la relacin es un conjunto)

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:

3. El orden de las columnas no es significativo.

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

Una relacin que satisface este ltimo punto se denomina "Normalizada".

La teora de la normalizacin se basa en la necesidad de encontrar una representacin del conjunto de relaciones que en el proceso de actualizacin sea ms adecuada. Llevar una relacin no normalizada a normalizada es muy simple. Existen diferentes niveles de normalizacin que se llaman formas normales que veremos ms adelante.

Ejemplo:

Veamos cmo nuestro ejemplo de suministrador y producto se puede representar fcil y claramente mediante el modelo relacional.

Suministrador: Nmero, Nombre, Tipo y Municipio donde radica.

Producto: Nmero, Nombre, Precio unitario y Peso.

Se conoce la cantidad de un determinado producto que suministra un suministrador dado.

SUMINISTRADOR SNUM SNOM TIPO MUN

S1 S2 S3 S4 S5

PREZ RAMOS ARENASVALLE LPEZ

30 10 20 20 15

CERROPLAZACERROPLAYAPLAYA

23

La representacin en el modelo relacional es ms simple que con el modelo jerrquico y el modelo reticular, ya que con 3 tablas se tiene todo el modelo representado.

En el modelo relacional el resultado de una demanda es tambin una relacin.

Demandas simtricas ====> Operaciones simtricas

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) Ventajas:

Una de la principales ventajas es su simplicidad, pues el usuario formula sus demandas en trminos del contenido informativo de la BD 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. Al igual que en el modelo reticular, si se tienen relaciones normalizadas, no surgen dificultades grandes en

la actualizacin.

Veamos en el modelo del SUMINISTRADOR-PRODUCTO, visto anteriormente, un ejemplo de cada tipo de operacin de actualizacin:

Creacin: Aadir un producto P7. Se agrega la nueva ocurrencia en la tabla PRODUCTO. Es 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.

PRODUCTO

S P CANT

S1 S1 S1 S1 S1 S1 S2 S2 S3 S3 S4 S4 S4

P1 P2 P3 P4 P5 P6 P1 P2 P3 P5 P2 P4 P5

3 2 4 2 1 1 3 4 4 2 2 3 4

PNUM PNOM PRECIO PESO

P1 P2 P3 P4 P5 P6

CLAVO TUERCA MARTILO TORNILLO ALICATE SERRUCHO

0.10 0.15 3.50 0.20 2.00 4.00

12 17 80 10 50 90

SP

24

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

Veremos que el proceso de normalizacin no es suficiente hasta el punto aqu visto.

Desventajas: Se dice que la fundamental 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 II, III, IV, DataEase, FoxPro, Informix (micros)

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 y fue pensado para aplicarse a sistemas relacionales. 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:

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

25

UNIVERSO DE RELACIONES

PRIMERA FORMA NORMAL

SEGUNDA FORMA NORMAL

TERCERA FORMA NORMAL

FORMA NORMAL BOYCE-CODD

CUARTA FORMA NORMAL

QUINTA FORMA NORMAL

Primera Forma Normal (1FN). Definicin: Primera Forma Normal

Formalmente: Una relacin est en (1FN) si cumple la propiedad de que sus dominios no tienen elementos que, a su vez, sean conjuntos.

Toda relacin normalizada, o sea, con valores atmicos de los atributos. La relacin no incluye ningn grupo repetitivo. Desarrollaremos un ejemplo que consiste en el diseo de la base de datos para la automatizacin del control de los pedidos de productos para ilustrar las fases de 1FN hasta 3FN. Supongamos que los modelos para pedir los productos sean como se muestra en la siguiente figura:

26

DESEAMOS ENVEN:

NMERO PRODUCTO

DESCRIPCIN PRECIO UNITARIO

CANTIDAD TOTAL

969715

439124

439126

TELEVISOR

ANTENA

ESPIGA

600

20

10

1

10

10

600

200

100

IMPORTE TOTAL: 900

123456 75621 J. PREZ CERRO

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

FECHA: 25/4/99

El anlisis de este pedido muestra que los siguientes. datos son de inters. El nmero de pedido es nico y se utiliza para referirse a un pedido, por tanto, se usar como clave (llave).

NUPED FECHA NUPROV NOPROV DIREC NUPROD DESC PRUN CANT PRPROD PRPED

En forma de relacin se escribira:

PEDIDO (NUPED, FECHA, NUPROV, NOPROV, DIREC, NUPROD, DESC, PRUN, CANT, PRPROD, PRPED)

Este pedido contiene 5 grupos repetitivos: NUPROD, DESC, PRUN, CANT, PRPROD, ya que puede contener ms de una lnea de pedido.

Hay que eliminar esos grupos. Para ello se crea:

1. Una relacin para los campos que sean nicos.

PEDIDO (NUPED, FECHA, NUPROV, NOPROV, DIREC, PRPED).

2. Una relacin para los grupos repetitivos.

PED-PROD (NUPED, NUPROD, DESC, PRUN, CANT, PRPROD).

Ambos tienen como llave, o parte de la llave, a NUPED. Pero en PED-PROD es necesario la llave compuesta para identificar los productos individuales.

Esta 1FN tiene problemas de actualizacin:

Creacin: La informacin sobre un nuevo producto no se puede insertar si no hay un pedido que lo incluya.

27

Supresin: Eliminar una lnea de pedido que sea la nica que pida un producto implica perder la informacin del producto.

Modificacin: Cada lnea de pedido en la que se solicite determinado artculo repite la informacin sobre ste. Si cambia algn atributo del artculo, entonces es necesario hacer muchas actualizaciones.

Segunda Forma Normal(2FN). Antes de pasar a la 2FN, es necesario abordar algunas definiciones previas:

Definicin: 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.

X ----> Y

Ejemplo en la relacin SUMINISTRADOR:

SNOM, TIPO y NUM 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

TIPO

MUN

SNUM

SNOM

TIPO

MUN

SNUM SNOM

SNUM TIPO

SNUM MUN

SNUM SNOM TIPO MUN

Estas 4 son formas de representar las dependencias funcionales.

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)

28

S

P CANT

S

P

CANT

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

CANT es funcional y completamente dependiente de (S,P)

Definicin: 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.

Definicin: 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. Y X | 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 siguientes dependencias funcionales:

1. A-->B

29

2. BC-->D

3. AB->E

Para comenzar, se parte de que no existen ms llaves que dependencias 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:

1. A-->B AC---->A B E C D ====> AC es llave

2. BC-->D BCA-->B C D A E ====> BCA es superllave

3. AB->E 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) y contiene a AC.

Ejemplo: Sea la relacin R (ciudad, calle, cdigo postal). Para abreviar, R(C, A, P)

donde se tiene que:

Una calle en una ciudad tiene un cdigo postal: CA--->P

El cdigo postal tiene una estructura tal que su valor determina la ciudad: P---->C

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 s mismo), CA--->CAP. P determina a C y 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 los casos un subconjunto de ellas es tambin llave.

Definicin: Atributo llave.

Un atributo Ai de R es un atributo llave si l es (o es miembro de) una llave (candidata o primaria).

Definicin: Atributo no llave.

Un atributo Aj de R es un atributo no llave si l no es miembro de ninguna llave candidata.

En el ejemplo, C, A y P son todos atributos llaves.

Definicin: Segunda Forma Normal

Una relacin R se dice que est en 2FN si est en 1FN y si, y slo si, los atributos no llaves (ni primarias, ni candidatas) de R, si los hubiese, son funcional y completamente dependientes de la llave primaria de R.

Entonces, este segundo paso se aplica slo con relacin a llaves compuestas.

Continuando con el ejemplo de los pedidos de productos, habamos visto que en la relacin PED-PROD subsistan problemas de actualizacin. Analicemos las DF que existen en dicha relacin:

30

CANT

NUPED

NUPROD DESC

PRUN

PRPROD

Esta relacin no est en 2FN, pues DESC y PRUN no dependen funcional y completamente de la llave (NUPED, NUPROD).

La 2FN se hace:

1. Creando una relacin para todos los atributos que dependen funcional y completamente de la llave (y los atributos que no se analizan por ser atributos llaves, pertenecientes a claves candidatas).

PED-PROD (NUPED, NUPROD, CANT, PRPROD)

2. Y una relacin para los atributos que dependan de parte de la llave.

PRODUCTO (NUPROD, DESC, PRUN)

Los problemas planteados en la 1FN se resuelven con la 2FN.

Creacin: Se puede insertar la informacin sobre un producto.

Supresin: Se puede eliminar una lnea de pedido y no se pierde la informacin sobre el producto, aunque sea el nico pedido que pide ese producto.

Modificacin: Si cambia un atributo del producto, slo hay que cambiarlo en un lugar. Se elimina redundancia.

Pero an tenemos problemas en este caso que son similares a las vistos, pero con la relacin PEDIDO y, especficamente, cuando se trata de insertar, eliminar o modificar la informacin de PROVEEDORES:

Creacin: No podemos insertar informacin de proveedores, a menos que haya un pedido para l.

Supresin: Se perder la informacin sobre un proveedor al borrar un pedido que es el nico que se le haca a l.

Modificacin: Para cambiar informacin sobre un proveedor, hay que recorrer todos los pedidos de ese proveedor.

Tercera Forma Normal (3FN). Definicin: Tercera Forma Normal

Una relacin R est en 3FN si est en 2FN y si, y slo si, los atributos no llaves son independientes de cualquier otro atributo no llave primaria.

Esto es lo mismo que decir que se deben eliminar las dependencias transitivas de atributos no llaves respecto a la llave primaria, estando ya la relacin en 2FN.

Definicin: 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.

31

A

B C

Este paso se ejecuta examinando todas las relaciones para ver si hay atributos no llaves que dependan unos de otros. Si se encuentran, se forma una nueva relacin para ellos.

Analicemos las dependencias funcionales que existen en la relacin PEDIDO:

FECHA

NUPROV

La 3FN se hace:

1. Creando una relacin para los atributos no llaves que no dependen transitivamente de la llave primaria (y los atributos que no se analizan por ser atributos llaves, pertenecientes a claves candidatas).

PEDIDO (NUPED, FECHA, NUPROV, PRPED)

2. Y una relacin para los atributos no llaves que dependen transitivamente de la llave primaria.

PROV (NUMPROV, NOPROV, DIREC)

(Analizar las otras relaciones. No hay dependencia entre atributos no llaves)

La 3FN ha eliminado los problemas asociados con la informacin sobre el proveedor 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 saber o preocuparse de esto y es que utilizan el sentido comn y la experiencia para escribir relaciones normalizadas. No obstante, no siempre la intuicin es suficiente y la metodologa para normalizar las bases de datos se convierte en una herramienta imprescindible, que garantiza un diseo idneo de los datos.

Merece la pena destacar en este momento algunas otras cuestiones que, aunque no estn relacionadas diractamente con la teora de la normalizacin, s propician tambin la realizacin de un buen diseo de la base de datos:

1. En el ejemplo, se consideran atributos calculables, o tambin llamados secundarios, que no deben aparecer en el modelo lgico de la base de datos, como, por ejemplo, PRPROD y PRPED. La modificacin del precio unitario de un producto (PRUN), que se logr que apareciera como una nica ocurrencia de ese atributo, gracias a la aplicacin de la 2FN, implicara que hubiera que modificar el valor de los atributos calculables PRPROD y PRPED en todas aquellas ocurrencias relacionadas con el producto cuyo precio

NOPROV NUPED

DIREC

PRPED

32

se modifica, donde quiera que aparecieran, lo cual trae problemas de actualizacin, que son, precisamente, los que se tratan de evitar con la normalizacin. Por ello, en el modelo lgico, no deben aparecer atributos calculables. (Se incluyeron en el ejemplo para poder realizar la presente explicacin).

2. Siempre que en una relacin se escoja correctamente la llave primaria, esa relacin ya est en 1FN, debido a la propia definicin de llave. En este ejemplo, inicialmente, se parti de trabajar con el atributo NUPED como llave primaria cuando, en realidad, no lo es. La llave primaria sera el par de atributos NUPED, NUPROD, que son los que garantizan que cada ocurrencia de atributo tenga un solo valor. (Se parti de esa llave no correcta para poder aplicar la 1FN).

An en la 3FN existen problemas y habrn de ser resueltos con las siguientes formas normales:

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

2. esas llaves candidatas son compuestas y

3. esas llaves candidatas se solapan (o sea, tienen al menos un atributo comn).

Es decir, para una relacin donde no tengan lugar las tres condiciones anteriores, la FNBC es idntica a la 3FN. Esas tres condiciones son necesarias, pero no suficientes, para que la relacin no est en FNBC.

Definicin: Forma Normal de Boyce-Codd(FNBC)

Una relacin R est en FNBC si, y slo si, cada determinante es una llave (candidata o primaria).

Obsrvese que se habla en trminos de llaves candidatas y no slo de la llave primaria, ya que una llave es un caso especial de superllave y la llave puede ser candidata o primaria.

Adems, la definicin de FNBC es conceptualmente ms simple, aunque es una FN ms "fuerte". Una relacin que est en FNBC est tambin en 1FN, 2FN y 3FN.

Por ejemplo, la relacin

PRODUCTO (PNUM, PNOM, PRECIO, PESO)

con las DF : PNUM--->PNOM, PRECIO, PESO.

PNOM--->PNUM, PRECIO, PESO.

suponiendo que PNUM y PNOM sean llaves candidatas, est en FNBC, ya que, en todas las DF que existen, los determinantes son llaves candidatas y, por tanto, superllaves de PRODUCTO.

Analicemos otro ejemplo:

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:

para cada asignatura, cada estudiante tiene un solo profesor. cada profesor imparte slo una asignatura. cada asignatura es impartida por varios profesores.

33

E

A

PO sea, EA--->P

P --->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 (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.

Supongamos las siguientes ocurrencias de esta relacin EAP:

EAP

E A P Prez Matemtica prof. Blanco

Prez Fsica prof. Valds

Rdguez Matemtica prof. Blanco

Rdguez Fsica prof. Hdez

Esta relacin presenta anomalas de actualizacin, por ejemplo:

Eliminacin: Si queremos eliminar la informacin de que Rdguez estudia Fsica, perdemos la informacin de que el profesor Hdez imparte Fsica.

Estos problemas pueden eliminarse sustituyendo la relacin original EAP por dos relaciones:

EP (E,P) y PA (P,A)

A sea, se separa la DF problemtica (P--->A) en una relacin independiente, donde el determinante ser la llave (P), y se forma otra relacin, donde dicho determinante P participar como atributo, pero en la cual no puede participar el atributo determinado en la dependencia funcional conflictiva (A).

Otro ejemplo: 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) y R3 (A,P)

Otro ejemplo:

Sea la relacin EXAM (E, A, L) donde:

E: estudiante

A: asignatura

34

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:

E

A

LA

L

E

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)

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

35

Entonces, para el proceso de normalizacin se deben dar los siguientes pasos:

Reducir a valores elementales de los atributos.

Eliminar las dependencias funcionales incompletas de los atributos no llaves respecto a la llave primaria. Eliminar dependencias transitivas Eliminar las dependencias en las que el determinante no sea superllave.

1FN

RELACIN NO NORMALIZADA

2FN

3FN

FNBC

36

EJEMPLO: 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 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,

1) cprov --> nomprov mun es el determinante de nomprov y mun

2) cmat --> desc um precio anlogo al 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 3)expresada anteriormente.

1 2 3 4 5 6 7 8 9 4) cprov cmat --> nomprov mun desc um precio calm diralm capac cantmat

Se incluyen 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 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.

1 2 3 4 5 6 7 8 9 5) cprov calm --> nomprov mun diralm capac cmat desc um precio cantmat

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:

37

cprov cmat y cprov calm son ambas llaves candidatas ya que todos los atributos dependen funcionalmente de ellas y no existe ningn subconjunto propio del cual todos los atributos dependan.

Escojamos como llave primaria cprov cmat

R (cprov, cmat, nomprov, mun, desc, um, precio, calm, diralm, capac, cantmat)

1FN

La relacin original est en 1FN, pues no existen grupos repetitivos. Siempre que se escoja bien la llave, la relacin estar en 1FN, pues ello implica que, para un valor de la llave, habr un nico valor de cada atributo.

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) proveedor (cprov, nomprov, mun)

(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 la siguiente relacin:

(III) almacn (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. cprov calm --> cmat cantmat

c. 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 (c.), obtenindose de la relacin suministro las siguientes:

(2) suministro (cprov, calm, cantmat) (en esta relacin no puede aparecer ya cmat) (3) distribucin (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:

38

proveedor (cprov, nomprov, mun)

material (cmat, desc, um, precio)

almacn ( calm, diralm, capac, cmat)

suministro (cprov, calm, cantmat)

39

Obtencin del modelo relacional 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 y aplicndolo, as mismo, al ejemplo siguiente:

rama

cantembalm

emb-alm

cantemb

arribo

p n

m

tarifa tipo

unommerc cmercmoneda nompa

MERCANCIA

pas-merc

PAIS TRANSPORTACION

embarque

m

numal

diralm

calm

m almacn

n

nomemp

1 distribucin empresa

1

condtcncapnanumnave

alm-nav

nave

n

40

En el DER anterior se representa el fenmeno del movimiento mercantil de un 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 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. pas (nompa, moneda)

b. mercanca (cmerc, nommerc, um)

c. transportacin (tipo, tarifa)

d. almacn (calm, diralm)

e. 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 (Supngase aadido en el DER un atributo de la entidad embarque, que sera su llave: 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 llave:

embarque (idemb, nompa, cmerc, tipo, arribo, cantemb)

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.

PASO # 4

Representar en una tabla relacional cada relacin de m:m, incluyendo las llaves de las entidades relacionadas y los atributos de la relacin, si los hubiese.

emb-alm (nompa, cmerc, tipo, calm, cantembalm)

41

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"