II Modelacin conceptual de las Bases de Datos.

Cuntas corrientes tenemos? Cuntas cuentas de ahorro? Cuntos clientes? Cuntos clientes tienen ambos tipos de cuentas? Qu porcentaje de nuestras cuentas de ahorro tienen un saldo superior a $1000? Qu tipo de cliente tiende a tener el mayor saldo promedio en sus cuentas? Cuntos clientes tienen prstamos por encima de sus cuentas corrientes de ahorros? Un presidente de un banco est frustrado porque no puede tener diariamente las respuestas a este tipo de preguntas. Mientras tanto, la jefa de contadura, necesita estar segura de que cada cliente recibe mensualmente el estado de cuenta, y el jefe de prstamos a clientes, necesita un informe semanal de los pagos vencidos de los prstamos y necesita tambin una aplicacin que genere automticamente las cartas de recordatorios. Claramente cada una de estas necesidades de los usuarios puede satisfacerse con un sistema de Base de Datos. Tambin est claro que estos tres usuarios tienen necesidades diferentes. Es fcil ver que hay bastante solapamiento en los tipos de datos que los tres usuarios requieren. La tarea durante la definicin de los requisitos y el diseo conceptual es identificar las necesidades bsicas de datos y crear los modelos conceptuales de los datos que nos aseguren registrar los datos necesarios y las relaciones entre stos. 2.1 Realidad, definicin de requisitos y modelado conceptual de datos. Los procesos de definicin de los requisitos y el diseo conceptual exigen identificar las exigencias de la informacin de los usuarios y representar stos en un modelo bien definido. Para llevar a cabo esto necesitamos observar cuidadosamente la naturaleza de las condiciones de los usuarios y el significado preciso de la representacin lgica de los mismos. 2.2 Realidad y modelos Qu es un modelo? Un modelo es una representacin de la realidad que conserva slo detalles relevantes. Por ejemplo, consideremos una transaccin bancaria tal como un depsito en una cuenta corriente. Contadura desea conservar ciertos detalles (nmero de la cuenta, monto del depsito, tiempo, fecha, nmero del cajero) e ignorar otros (las palabras que se han intercambiado durante la transaccin, el nmero de gente en el banco, el nmero de personas que estaban esperando en la cola, la msica que estaba tocando en el audio local, las condiciones del clima fuera del banco, etc.). La realidad involucra un sinnmero de detalles, pero Contadura considerar a la mayora de ellos irrelevantes para la transaccin. De modo que un modelo, desde el punto de vista de Contadura, conservar slo aquellos detalles que sta considere relevante. Por supuesto, algunos detalles considerados irrelevantes por el usuario pueden ser muy importantes para otros usuarios. Imaginemos, por ejemplo, que se est desarrollando un sistema de Base de Datos para un restaurante de comida rpida. Las condiciones del clima pueden ser aspectos significativos de la realidad del administrador del restaurante, puesto que un da fro debe ofertar un conjunto de ensaladas bastante diferentes del de un da clido. Como resultado, el administrador debe desear poder tener en cuenta estos cambios del clima y las rdenes que han sido suministradas de acuerdo con esto. El nmero de personas esperando en la cola puede ser otro aspecto importante para la realidad del administrador, puesto que ste necesita esta informacin para poder planificar la cantidad de cajeros y minimizar el tiempo de espera de un cliente.

Una Base de Datos incorpora un modelo de la realidad. El SGBD administra la Base de Datos de modo que cada usuario pueda registrar, acceder y manipular los datos que constituyen su modelo de la realidad. Manipulando los datos en una amplia variedad de formas los usuarios pueden obtener la informacin necesaria para conducir una empresa con xito. Por lo tanto, los modelos son herramientas poderosas para eliminar los detalles irrelevantes y comprender la realidad de los usuarios individuales. Modelar la realidad es en muchas maneras similar a resolver un problema de una historieta. Ambos requieren que nos desprendamos de los detalles para crear un modelo correcto de una porcin de la realidad. Esto significa que se debe asociar, o identificar, elementos de la realidad con elementos en el modelo. Si esta asociacin se hace correctamente, entonces el modelo se puede usar para resolver el problema. De lo contrario, el modelo no puede producir una solucin correcta. Mucha gente encuentra que el problema de las historietas es difcil porque no se sienten cmodos con el proceso de asociacin en s mismo.

En el nivel ms bajo se dice que el estado en curso de una Base de Datos en particular es un modelo de la realidad porque es un registro de hechos seleccionados sobre la realidad que son verdaderos. Por ejemplo, la Base de Datos puede registrar el hecho: Juan Prez vive en Avenida Garzn 845 . Si Juan cambia de direccin, entonces el estado de la Base de Datos debe de cambiar si quiere continuar con un modelo preciso de la realidad. En el prximo nivel del esquema se describe en la estructura de la Base de Datos como un modelo de un conjunto de modelos (estos es, un modelo de un conjunto de estado de la Base de Datos). El esquema modela un enorme rango de estados de la Base de Datos, definiendo aquellas caractersticas que todos estos estados tienen en comn. As, nombre y direccin se registran en el modelo como caractersticas que se aplican a diferentes personas y que cambian de tiempo en tiempo. Al nivel ms alto, la metodologa de diseo describe las construcciones y reglas que pueden ser utilizadas en la formulacin de un esquema. Por lo tanto, este nivel es tambin un modelo de un conjunto de modelos (posibles esquemas de Bases de Datos). Una metodologa dada de diseo, tal como el modelo conceptual de datos o el modelo relacional, es un modelo al nivel ms alto y describe en trminos generales un conjunto potencialmente enorme de esquemas En resumen, se habla del modelo conceptual de datos como una metodologa para la creacin de esquemas de Bases de Datos para situaciones particulares de aplicacin. Estos esquemas de Bases de Datos son en s mismos modelos que proveen una estructura lgica para capturar hechos sobre una porcin particular de la realidad. Cuando estos hechos son capturados y registrados en un sistema de Base de Datos, entonces la Base de Datos en s misma es un modelo del estado actual de la realidad. Cada uno de los dos niveles superiores de la figura 16 es un modelo del nivel que tiene debajo. 2.3 Diseo de bases de datos relacionales. 2.3.1 Conceptos bsicos. Un campo o atributo es la unidad menor de informacin sobre un objeto (almacenada en la base) y representa una propiedad de un objeto (por ejemplo, el color). Sin embargo, hay que distinguir entre el nombre o tipo del atributo y el valor del atributo, ya que un nombre de atributo puede tomar diferentes valores sobre un cierto conjunto que se denomina dominio. A un valor de un atributo determinado o definido en el dominio dado, en un cierto momento del tiempo, se denomina ocurrencia del atributo.

Ejemplo: Atributo Dominio Ocurrencia Color {Azul,Rojo,Verde,...} Rojo Categora Docente {PT, PA, A, I} A

Ahora bien, una coleccin identificable de campos asociados es un artculo o registro y representa un objeto con sus propiedades. Una vez ms, es imprescindible distinguir entre nombre o tipo de artculo y ocurrencia de artculo. Una ocurrencia de artculo o tuploconsiste 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 Juan Prez 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 Datoscontendr muchas ocurrencias de cada uno de los tipos de artculos, lo que implica que la Base de Datos, por supuesto, tambin contendr 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 candidata, el cual no es ms que 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, el nmero de identidad del trabajador.

2.3.2 Las relaciones. 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

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. A partir de ahora, para abreviar, cuando mencionemos la palabra entidad estaremos haciendo referencia realmente a un conjunto de entidades. 2.3.3 Relaciones de correspondencia: Es necesario establecer la correspondencia que existe entre los datos; esta relacin puede ser simple o compleja. Por relacin simple se entiende una correspondencia biunvoca (de uno a uno) entre las ocurrencias de los objetos, o sea, entre los artculos. Si, por ejemplo, los atributos son Nro_Identidad y nombre del profesor,la correspondencia entre ellos es simple: a cada nombre corresponde un nmero de identidad y viceversa. Relacin Nombre 1 : 1 Nro_Identidad de uno a uno

Si los atributos son Nro_identidad y departamento, la relacin es ms complicada, porque a cada departamento corresponden varios empleados. La terminologa corriente expresa que la correspondencia de empleado a departamento es simple (cada empleado es miembro de un nico departamento), mientras que la correspondencia de departamento a empleado es compleja, pues cada departamento tiene, por lo general, muchos empleados.

Relacin Nro_Dpto. 1 : M Nro_Identidad de uno a muchos

La relacin que se establece entre PROFESOR y ESTUDIANTE es ms compleja 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 N : M ESTUDIANTE de muchos a muchos

Las relaciones pueden tener diferentes caractersticas: y Aunque la mayora de las relaciones asocian dos tipos de entidades, ste no es siempre el caso. Por ejemplo, PROFESOR_HORARIO_ESTUDIANTE. Esto podra representar el hecho de que un profesor imparte clases a una cierta hora a un cierto estudiante. Esto no es lo mismo que la

combinacin PROFESOR_HORARIO y HORARIO_ESTUDIANTE, ya que la informacin de que "el profesor P5 imparte clases en el horario H1 al estudiante E4" dice ms que la combinacin "el profesor P5 imparte clases en el horario H1" y "el estudiante E4 recibe clases en el horario H1". y 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. 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.

2.4 Modelo Entidad-Relacin. El Modelo Entidad-Relacin (MER) fue propuesto en 1976 por Peter Sin ShanChen 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 describe los datos en trminos de entidades, atributos y relaciones. 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 conjunto valor. Si se desea representar otra propiedad, el valor tiene que ser convertido en una entidad. Por ejemplo, si queremos registrar la longitud de onda de cada color no podemos hacerlo en el MER, sino convirtiendo el conjunto de valores COLOR en 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 atributo mediante un crculo. Mediante lneas se conectan las entidades con las relaciones, igual que las entidades con los atributos. Los atributos llaves se representan subrayando el correspondiente conjunto de valores. En una relacin, la llave es la combinacin de las llaves de todas las entidades asociadas. Para cada relacin se determina su tipo (simple o complejo) y en el DER se escribe el tipo de correspondencia. En ocasiones, una entidad no puede ser identificada nicamente por el valor de sus propios atributos. En estos casos, se utilizan conjuntamente las relaciones con los atributos para lograr la requerida identificacin unvoca. Estas entidades reciben el nombre de entidades dbiles y se representan en el DER con un doble rectngulo. El MER restringe las relaciones a usar para identificar las entidades dbiles a relaciones binarias del tipo 1:n. As, por ejemplo, una ocurrencia de "trabajador" puede tener n ocurrencias "persona-dependiente" asociadas, donde adems, la existencia de las ocurrencias en la segunda entidad depende de la existencia de una ocurrencia que le 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. La gran ventaja de los diagramas Entidad-Relacin es que son fciles de dibujar y fciles de comprender. En la figura 1.3 se muestra un ejemplo de un Modelo Entidad-Relacin. ste contiene 4 conjuntos de entidades: EMPRESA, PIEZA, MQUINA y TRABAJADOR y 3 relaciones. En ella puede notar cmo una empresa puede tener varios (n) trabajadores asociados y un trabajador pertenece a una sola empresa (1). En la relacin TRABAJADOR-MQUINA-PIEZA, un trabajador puede trabajar en n mquinas, produciendo p piezas, o una pieza puede ser producida por m trabajadores en n mquinas. Aqu, m, n y p no identifican un nmero especfico, sino solamente el tipo de correspondencia que se establece en la relacin. Cada uno de los conjuntos de entidades tiene asociado un conjunto de atributos y su llave.

Nombrede empresa EMPRESA 1 Num-id Nombrespropios Empresatrabajador

Valormonetario Presupuesto Hora s trabmaq m n TRABAJADOR 1 trab-mqpieza Nombremquina Cantidad #mquina n MQUINA m n Valor monetario

Apellidos Salario

Calificacin

TrabPersdep n n

PIEZA Precio No.Pieza Valormonetario

PERSONADEPENDIENTE

Nombrespropios

Aos

Fig.1.3 Un ejemplo de Modelo Entidad-Relacin.

Es posible extender la capacidad semntica del MER aplicando sobre sus objetos bsicos (entidad y relacin) diferentes operaciones: 1. Agregacin: Construye una nueva entidad sobre la base de una relacin. 2. Generalizacin: Permite formar una nueva entidad, mediante la unin de otras entidades. El proceso inverso se denomina especializacin y divide una entidad en cierto nmero de otras entidades. 3. Agrupamiento: Define una nueva entidad, donde cada ocurrencia es un grupo de ocurrencias de la entidad fuente. 2.4.1 Agregacin. Obsrvese en el ejemplo que representa la situacin de la produccin en las empresas (mostrado en la figura 1.3), 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 1.4.

EQUIPO OBRERO m Obrero-mq n MQUINA

1 EquipoPieza p PIEZA

Cantidad

Fig. 1.4 Un ejemplo de Agregacin.

Otro ejemplo de agregacin se muestra a continuacin en la figura 1.5. 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.

2.4.2 Generalizacin / Especializacin. Por ejemplo, en el DER mostrado en la figura 1.3, puede ser necesario distinguir los trabajadores de una empresa de acuerdo a su ocupacin como obreros, dirigentes y administrativos. Esto no puede ser representado en el modelo anterior y slo a travs del hecho de que el conjunto de entidades OBRERO, por ejemplo, es siempre un subconjunto del conjunto de entidades 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 1.6. Ntese que hemos introducido un nuevo atributo (Tipo de Trabajo) para el conjunto de entidades TRABAJADOR. Este atributo nos permite distinguir entre los miembros de diferentes clases de trabajadores.

ENVO Suministrador -PiezaProyecto m n p Cantidad Enviada

PROYECTO

Fecha del envo

SUMINISTRADOR

PIEZA

Nmero Fig. 1.5 Otro ejemplo de agregacin. Num-id TRABAJADOR Tipo deTrabajo
ADMINISTRATIVO DIRIGENTE

OBRERO

Fig. 1.6 Ejemplo de generalizacin.

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

2.4.3 Agrupamiento. Si T designa a algn conjunto de entidades y T1, T2 ...Tn son bien conjuntos valor (dominios) asociados con T o conjuntos de entidades relacionados con T mediante alguna relacin, entonces el operador de Agrupamiento construye un nuevo conjunto de entidades agrupado (entidad agrupada o agrupamiento) Tg donde cada elemento es un conjunto de entidades (ocurrencias) de T, tales que, dentro de cada uno de tales conjuntos, todas las entidades (ocurrencias) tienen los mismos valores y entidades relacionadas desde los conjuntos de entidades T1, T2 ...Tn asociados. Los tipos T1, T2 ...Tn se llamarn tipos ndice y T se llamar base. Por ejemplo, podemos usar el atributo Salario del DER mostrado en la figura 1.3 para formar un conjunto entidad (entidad) agrupado a partir del conjunto entidad TRABAJADOR. Cada entidad (ocurrencia) Trabajador dentro de un grupo, que representa a una entidad (ocurrencia) en Trabajadores de igual salario, tiene el mismo valor del salario. Observe la figura 1.7.

Trabajadores de igual salario SALARIO TRABAJADOR

Fig. 1.7 Ejemplo de agrupamiento.

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

visto del ENVO, pueden existir suministradores que no abastezcan a ningn proyecto, sino que se registran como tales porque en determinado momento pudieran estar activos. Desde luego, si la poltica de la organizacin es tal que un suministrador se considera como tal slo si realmente suministra piezas a algn proyecto, entonces la existencia de la entidad agregacin ENVO es indispensable para la existencia del conjunto entidad SUMINISTRADOR. 3. Al aplicar el agrupamiento, por lo general la existencia de todos los componentes del conjunto ndice es necesaria para que exista la entidad agrupada. Por otra parte la base es indispensable slo en el sentido de que para que exista cada entidad agrupada en el conjunto de entidades 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. 2.5 Modelo relacional. Uno de los modelos matemticos ms importantes, actuales y con mayores perspectivas para la representacin de las Bases de Datos es el enfoque relacional. Este modelo 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: 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, ...., dnDn. 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. Observe la figura 1.8.

. . . . . .

COLUMNAS (atributos)

. . .

FILAS (ocurrencias)

Fig. 1.8 Una relacin representada mediante una tabla bidimensional.

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 n-uplos. Tambin la relacin est compuesta por columnas que son los atributos o campos que toman valores en sus respectivos dominios.

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. Es importante tener en cuenta lo siguiente: 1. No hay dos filas (n-uplos) iguales. 2. El orden de las filas no es significativo. (Las condiciones 1 y 2 se deben a que la relacin es un conjunto). 3. El orden de las columnas no es significativo. Siendo rigurosos, el orden de las columnas s es significativo, pues representa el orden de los dominios implicados, pero como siempre nos referimos a una columna por su nombre y nunca por su posicin relativa 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 estudiaremos ms adelante. 2.6 Transformacin del MER en un Modelo Relacional. 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, mediante un ejemplo. Supongamos que tenemos el Modelo Entidad-Relacin mostrado en la figura 1.9.

nombre moneda cmerc nommerc

um

tipo

arribo

tarifa cantemb

PAS

MERCANCA

TRANSPORTACIN

n pasmerc m cantembalm emb-alm numemp n nomemp rama p EMBARQUE

calm diralm ALMACN 1 m Distribucin 1 EMPRESA

En el DER anterior se representa elelfenmeno del movimiento mercantil de un organismo. En el Fig. 1.9 MER para problema del movimiento mercantil. 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. Para hacer la conversin hay que realizar los siguientes pasos: 1. Representar cada entidad regular en una tabla relacional. Pas (nombre, moneda) Mercanca (cmerc, nommerc, um) Transportacin (tipo, tarifa) Almacn (calm, diralm) Empresa (numemp, nomemp, rama)

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 (nombre, 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 (idemb). Entonces se aadira como atributo llave en la agregacin y los 3 atributos nombre, cmerc y tipo permaneceran en la relacin pero no como llaves. Esto es, Embarque (idemb, nompa, cmerc, tipo, arribo, cantemb) 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. 4. Representar en una tabla relacional cada relacin de m:n, incluyendo las llaves de las entidades relacionadas y los atributos de la relacin si los hubiese. Emb-alm (idemb, calm, cantembalm) 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 existen. 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 Almacn 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. 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)

Resumiendo, el Modelo Relacional del ejemplo mostrado en la figura 1.9 es: Pas (nombre, moneda) Mercanca (cmerc, nommerc, um) Transportacin (tipo, tarifa) Almacn (calm, diralm, numemp) Empresa (numemp, nomemp, rama)

Embarque (idemb, nompa, cmerc, tipo, arribo, cantemb) Emb-alm (idemb, calm, cantembalm) Nave (calm, numnav, capnav, condtcn) Analicemos otro ejemplo. Veamos cmo el siguiente problema se puede representar fcil y claramente mediante el modelo relacional. Se tiene un conjunto de suministrador y productos. De cada suministrador se conoce su nmero, nombre, tipo y municipio donde radica. Por otra parte, de cada producto se conoce su nmero, nombre, precio de la unidad y peso. Se conoce, adems, la cantidad de un determinado producto que suministra un suministrador dado. El Modelo Entidad-Relacin de este problema se muestra en la figura 1.10. Si sigue los pasos vistos anteriormente debe obtener el Modelo Relacional siguiente: Suministrador (SNmero, SNombre, Tipo, Municipio) Producto (PNmero, PNombre, Precio, Peso) Suministra (SNmero, PNmero, Cantidad)

4.3.10.1.1

Nombre

SUMINISTRADOR Tipo m Suministra n Peso Cant. Fig. 1.10 MER de Suministrador-Producto. Municipio
4.3.10.1.2 N

Nombre

PRODUCTO Precio U.

Note cmo cada conjunto de entidades y cada relacin del MER se convierte en una relacin en el Modelo Relacional. La llave de la relacin Suministra est formada por los atributos SNmero y PNmero. La representacin mediante tablas de este modelo se muestra a continuacin.

SUMINISTRADOR

SNUM S1 S2 S3 S4 S5

SNOM PREZ RAMOS ARENAS VALLE LPEZ

TIPO 30 10 20 20 15

MUN CERRO PLAZA CERRO PLAYA PLAYA

PRODUCTO

SUMINISTRA

PNUM P1 P2 P3 P4 P5 P6

PNOM

PRODUCTO

PRECIO 0.10 0.15 3.50 0.20 2.00 4.00

PESO 12 17 80 10 50 90

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

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

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

CLAVO TUERCA MARTILO TORNILLO ALICATE SERRUCHO

En el Modelo Relacional el resultado de una demanda es tambin una relacin. Slo tiene que indicar qu relacin desea recuperar. Las diversas formas de hacer las recuperaciones dan lugar a los lenguajes relacionales cuyas formas ms representativas son: - lgebra relacional (basado en las operaciones del lgebra de relaciones). - Clculo relacional (basado en el clculo de predicados). 2.7 Dependencia funcional. El concepto de dependencia funcional es una herramienta extremadamente til para concebir las estructuras de datos. Dada una tuplaT, con dos conjuntos de atributos {X1,...,Xn} y {Y1,...,Yn} (los conjuntos no tienen por qu ser mutuamente exclusivos), entonces el conjunto Y es funcionalmente dependiente del conjunto X si, para cualquier valor vlido de X slo existe un valor vlido de Y. Por ejemplo, en el MER de la figura 1.10, el atributo SNmerodetermina funcionalmente a {SNombre, Tipo, Municipio} y se representa como: SNmerop {SNombre, Tipo, Municipio} Si { X} es una llave candidata, entonces todos los atributos { Y } deben ser, necesariamente, funcionalmente dependientes de { X }; esto se deduce de la definicin de llave candidata. Si { X } no es una llave candidata y la dependencia funcional no es trivial (es decir, { Y } no es subconjunto de { X }), entonces la relacin necesariamente incluir una redundancia, siendo necesaria una normalizacin.

EJERCICIOS:

1. Utilizando una modelacin conceptual realice un modelo de los siguientes escenarios: Banco, Farmacia, Biblioteca? Considere al menos tres entidades en cada caso. 2. Disee los modelos Entidad-Relacin y Relacional para el siguiente problema: en un huerto se cultivan diversos rboles. Cada huerto esta relacionado con los rboles que estn plantados en el huerto. Cada rbol fue plantado en un determinado ao y puede o no haber muerto ya. Si el rbol muri, entonces AO DE MUERTE contiene un valor; de lo contrario, es nulo. Los rboles tienen especie y las especies tienen variedades. Por ejemplo, Manzana es una especie y Jonatan y Red Delicious son variedades. Puesto que los rboles pueden tener ramas injertadas, una misma especie de rbol podra soportar mas de una variedad. De esta manera, un Manzano que fue originalmente Red Delicious podra tambin tener Jonatan y Romn Beauty. Cada rbol tiene solo una especie pero podra tener mltiples variedades. 3. Disee los Modelos Entidad-Relacin y Relacional para el siguiente problema: De cada Empleado se conoce su identificador el nombre y el apellido, direccin y fecha de nacimiento. Existen diferentes puestos de trabajo que se caracterizan por su identificador, titulo y estudios realizados. Los Empleados ocupan los puestos de trabajo en una determinada fecha y reciben un salario. Se desea poder determinar el historial de puestos de trabajo de un empleado.

4. En una empresa se controlan los datos de los trabajadores, almacenando el nombre, su direccin, telfono y correo electrnico. A cada uno se le asigna un nmero o ID que lo identifica de forma nica en la empresa. Cada trabajador pertenece a un departamento, en la empresa existen varios y de ellos se guarda el nombre. En la empresa, el trabajo se desarrolla por proyectos, de los cuales se tiene el titulo, resultado esperado y beneficio econmico que reporta ( en miles de dlares). Cada trabajador puede participar en mas de un proyecto. Se desea conocer cuantos trabajadores tienen asignado el proyecto que mas beneficios brindan. A dems, para un departamento, saber cuales son los proyectos con los cuales se vinculan por la participacin de sus trabajadores. Elabore el diseo conceptual que refleja toda la informacin acerca de la empresa. Convierta el diseo conceptual en un modelo relacional e implemente un subsistema con el cual pueda obtenerse la informacin solicitada.

5. En una biblioteca se almacenan documentos de diferentes tipos, pueden ser revistas, libros o CDs con informacin. De cada una de ellos se guarda la informacin suficientemente descriptiva: de las revistas se conoce el nombre, el volumen, el nmero, el mes y el ao. De los libros, el autor, el titulo y un conjunto de palabras clave asociadas con el tema del libro. De los CDs se guarda el titulo. Se desea controlar los prstamos que se realizan en la biblioteca para conocer en cada momento si determinado documento est o no disponible, conociendo la fecha en que fue prestado y la fecha en que ser devuelto. Adems, poder determinar la cantidad de revistas de un titulo que existen, poder conocer todos los libros que hay asociados con una palabra clave o con un autor. La consulta de los CDs debe poder realizarse en orden alfabtico para facilitar la localizacin de uno. Elabore el diseo conceptual que refleje toda la informacin acerca de la biblioteca.

6. Convierta el diseo conceptual en un Modelo relacional e implemente un subsistema cual pueda controlarse la informacin solicitada.

con el

7. Un restaurante tiene un almacn donde guarda los productos con los que elabora los platos. En el almacn los productos se agrupan por tipo, as, estn juntos los diferentes tipos de arroz que se han adquirido, las distintas clases de caf comprado, etctera. De cada uno de estos elementos especficos, o sea, de un tipo de arroz, est guardada la cantidad comprada (en Kg.) y el precio. Adems, tienen recogida las recetas de los platos que ofertan, donde se especifica el nombre del plato, qu tipo de producto debe usarse y en que cantidad (en gramos). De acuerdo a los datos de la receta, y con el precio del tipo de producto que est en el almacn, se determina el precio del plato. Diariamente, se almacena la cantidad de producto utilizado teniendo en cuenta los platos que se van elaborando. El dueo del restaurante suele consultar qu cantidad de cada producto tiene, es decir, cuntos kilogramos de arroz o de azcar hay en el almacn. Algunas personas se interesan por saber cules son los platos que incluyen un tipo de producto o por conocer el precio de un plato. Debe consultarse diariamente la cantidad de un tipo de producto utilizado para realizar ajustes en las compras. Elabore el diseo conceptual que refleje toda la informacin acerca del restaurante.

8. Elabore una propuesta de sistema para el control de las llamadas telefnicas usted debe seleccionar las entidades que intervienen y los atributos asociados. Construya el Diagrama E-R y el modelo relacional de esta propuesta. 9. Elabore una propuesta de sistema de bases de datos para el control de matricula en una Universidad. Elabore el Diagrama E-R y el modelo relacional de su propuesta.