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 J uan 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 ROJ O, 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 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",
"J uan", 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:
atrib
1
: E
i
D
i1
x D
i2
x .....x D
in


atrib
2
: R
i
D
i1
x D
i2
x .....x D
in

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 e
j
usa una mquina e
i
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
e
i

e
j



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
TRABAJ ADOR
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-id
TRABAJ ADOR
ADMINISTRATIVO DIRIGENTE
OBRERO
Si tenemos una entidad TRABAJ ADOR 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
TRABAJ ADOR
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
TRABAJ ADOR
ADMINISTRATIVO DIRIGENTE
OBRERO
n 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
TRABAJ ADOR
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
TRABAJ ADOR
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, TRABAJ ADOR, 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
ARENAS
VALLE
LPEZ
30
10
20
20
15
CERRO
PLAZA
CERRO
PLAYA
PLAYA


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
P
O 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
L
A
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
EJ EMPLO: 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
u
nommerc cmerc moneda nompa
MERCANCIA
pas-merc
PAIS TRANSPORTACION
embarque
m
numal
diralm
calm
m
almacn
n
nomemp
1
distribucin empresa
1
condtcn capna
numnave
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" 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.
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.
Metodologa para el diseo de bases de datos.
La metodologa para el diseo de la base de datos, consta de los siguientes pasos:
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.
42
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:

OPERACIONES SUSPENDIDAS
En el da:
de de 19
Paciente Historia Clnica Edad Causa
Para el da:
de de 19
PROGRAMACIN QUIRRGICA
Paciente Hist Edad Sexo Diagnstico Intervenc. Hora Saln Cirujano
Cln. Pre-Oper. Indicada



43






RESUMEN DE ACTIVIDADES QUIRURGICAS Mes:
Cantidad de Operaciones Electivas:
Cantidad de Operaciones Urgentes:
Especialidad Cantidad de Operaciones
INFORME OPERATORIO
Fecha de Operacin:

Hora Comienzo Hora Terminacin

Situacin Final del Paciente:
Satisfactoria No Satisfactoria Fallecido
Especialidad Tipo de Operacin Realizada
Electiva Urgente
Cirujano:
Paciente Historia Clnica Edad
Diagnstico Clnico:
Operacin Realizada:
Diagnstico Operatorio:
44

Paciente Hist. Edad Hora Patologa Cd. Descr. Cantidad
Costo
Cln Com Mat Mater
En el da:
de de 19
GASTO DE MATERIALES DE OPERACIN

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.
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 siguientes. relaciones o
entidades iniciales:
1. PQ(Fecha, NomPac, HC, Ed, Sexo, DiagPre, Interv, Hora, Saln, Cirujano)
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, 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)
45
Saln se decide teniendo en cuenta la distribucin de los salones, que en este caso, es por da de la
semana:
=> DS (Saln, DaSem, Espec)
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)
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)
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)
46
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, DescMat, Cant, 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)
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 = 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 operaciones las 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)
Determinar las relaciones entre las entidades (DER)
Si hay alguna entidad cuya llave es combinacin de llaves de otras entidades, generalmente, es porque
representa una relacin entre ellas (m: n)
47
Analizar cada entidad con las restantes para determinar si existe relacin, determinando tipo de
proyeccin.
Ir confeccionando el DER
Analizar entidades agregadas, entidades dbiles y sus relaciones con otras

HC
nompac
sexo
ed
n

m
1
1
1
DS
n
GMO
cant
n
1
m
1

m
1
fecha
hora diapre
operacin
1
m
sitpac
diagoper
horater
horacom
fecha
IO
tipoopreal
cirreal
INTERVENCION
espec
cirujano
PACIENTE
MATERIAL
precio
descmat cdmat
m
SALONES
DIASEMAN
OS
causa
espec
tiempopro
m
saln
dasem
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.
Obtener el modelo lgico global de los datos
Aqu se deben seguir los pasos para llevar del DER al modelo lgico global de los datos.
48
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 segungo paso (Normalizar las entidades). Supongamos que en
nuestro ejemplo, este es el caso. Entonces:
Diseo lgico:
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)
Diseo fsico de la BD
En este paso hay que tener en cuenta:
Aplicaciones a realizar sobre los datos
Caractersticas particulares del SGBD
Ejemplos de estos dos aspectos a tener en cuenta:
ficheros ndices
ficheros para reportes
considerar la inclusin de campos que sean secundarios debido a la cantidad de veces que habra que
calcularlos en una determinada aplicacin.
separar un fichero en varios debido a la cantidad de campos y lo que se accesa cada vez
49