Capitulo 5- Diseño de Datos

Diseo de Software Gustavo A. Donoso M.

Diseo de SoftwareGustavo A. Donoso M.

Capitulo 4: Diseo de Datos. (work in progress, casi casi)

4.1.- Objetivos

Conocer y aplicar lo que se entiende por diseo y especificacin de datos.

4.2.- Introduccin

Como ya se ha visto en captulos anteriores, el diseo de datos no cumplira con la lgica de un gran espacio de solucin que contiene alternativas divergentes. Si no ms bien se trata de un modelo de una realidad que deriva en un diseo.

Tambin se revis, en forma general, algunas soluciones estndar de representacin de relaciones entre datos; las estructuras de datos. En este captulo veremos como los diseos de estructuras de datos pueden ser especificados.

Las bases de datos corresponden a repositorios de datos que se organizan en torno al modelo relacional y cmo a travs de ese modelo se puede describir una realidad y la manera en que esos diseos pueden ser especificados.

4.3.- Estructuras de Datos

Como se vea anteriormente la estructura de datos es la forma de representar una realidad de modo de hacerla automatizable.

Un dato es un par (atributo, valor) que permite representar algo. Un valor como 35 no significa, normalmente, nada del mundo real, es cuando le asociamos un atributo que adquiere capacidad de representar: (edad en aos, 35), (peso en kilos, 35), (altura en metros, 35), etc.

Una estructura de datos corresponde a la representacin de un conjunto de datos relacionados de alguna forma. La relacin ms simple es la de pertenencia.

Supongamos que se quiere saber el peso y la altura de un nio, entonces se requiere al menos tres datos relacionados, nombre del nio, peso en kilos (kg) y altura en metros (m). As por ejemplo, Pedro que mide 1.35 m y pesa 28.6 kg se representa como el conjunto de esos tres datos:

(Nombre, Pedro) + (Altura en m, 1.35) + (Peso en kg, 28.6)

Captulo4.DiseodeDatosPgina1de20


Es lo que llamamos usualmente un registro y permite representar elementos de un conjunto segn un criterio de abstraccin dado por una problemtica.

El conjunto de datos anterior tiene una cohesin dada por la relacin de pertenencia a un conjunto, en este caso sera al conjunto de caractersticas que representa a un nio. As, normalmente, todos los registros permiten representar caractersticas especficas de elementos de un conjunto. As como el conjunto de los registros permitira representar el conjunto de los elementos.

Por ejemplo, si el registro anterior de (nombre, peso, altura) fuera para un conjunto de nios de un curso de colegio entonces se tendra una tabla de la siguiente forma:

Nombre Peso en kg Altura en mPedro 1.35 28.6Mara 1.30 25.8Juan 1.40 38.3Rosa 1.33 33.4

La tabla, como se vea, permite modelar relaciones de pertenencia de los elementos a un conjunto, del mismo modo que el registro permitira modelar los elementos de un conjunto a partir de la abstraccin de sus caractersticas y la representacin de stas como datos.

Los lenguajes de programacin desde hace muchos aos tienen estructuras que permiten representar conjuntos como los anteriores, lo que no hay para aquellos lenguajes es formas de representar lo mismo a ms alto nivel, a nivel de especificacin de diseo.

Desde la perspectiva de orientacin a objetos aquello se ha subsanado. El diagrama de clases establece una capa de representacin a un nivel ms abstracto. Por ejemplo lo anterior se puede representar como:

Donde un curso es una agregacin de Nio. Los atributos de Nio son los considerados: nombre, peso y altura. Con ello se ha modelado el conjunto de datos necesarios para manejar esa situacin desde la perspectiva de lenguajes de modelacin.



Ahora la pregunta que queda es si aquello es un diseo de la estructura de datos o slo un modelo?

En trminos generales tiene ambos componentes, de modelo y de especificacin de diseo ya que, y esto es importante, los elementos de representacin aportados por los lenguajes plantean una restriccin fuerte al espacio de solucin, de manera que el diagrama de clases descrito, en cuanto a un modelo adecuado de los datos del problema es muy probable que sea tambin un adecuado modelo de la solucin.

Es probable que ese diseo requiera refinamientos y la incorporacin de otros elementos ms detallados pero como solucin inicial resulta adecuada, principalmente por qu cumple con el criterio de representatividad que hemos definido como importante en el diseo de datos.

Ejercicios1.HagaundiseoenDiagramadeClasesparalasestructurasdedatosclsicas:ListaLineal,Pila,Fila,ListaDoblementeLigadayArbol.

2.Cmorepresentaraunestacionamiento,demodoqueesaestructurasealabasedeunsistemadecontroldeocupacindelmismo.

3.Representelashorasdelda,paramanejarunrelojcontrol.

4.Representeyhagaeldiseodelaestructuradedatosparalascancionesdeundiscocompacto.

5.Representeyhagaeldiseodelaestructuradedatosparaunconjuntodediscoscompactos.

Para continuar con el tema de cmo representamos/diseamos revisaremos el caso del polinomio. Si observamos un polinomio como el siguiente:

p(x) = -4,5X3+5,0X2+X-3

Vemos que ste corresponde a una suma de trminos, donde cada trmino est compuesto por un coeficiente (un nmero real), la variable (x) y un exponente (que se ha determinado como un entero).

Es decir, de la misma forma que los nios han sido representados a travs de la clase Nio, los trminos que componen un polinmio tambin tienen atributos o son datos, por ejemplo, el primer trmino se puede representar como dos datos:

(coeficiente, -4.5) (exponente, 3)



As, una clase trminos debera contener aquellos dos atributos:

Como un polinomio entonces es un conjunto de trminos, el modelo del mismo sera similar al del curso de nios:

4.4.- Tipos Abstractos de Datos

Actualmente se entiende por Tipo Abstracto de Datos una estructura de datos diseada para representar situaciones de datos del mundo real que incluye en s las operaciones asociadas a dicha estructura. En ese sentido, la representacin de polinomios como se hizo en el punto anterior solo correspondera a una estructura y no a un Tipo Abstracto de Datos, faltan las operaciones.

Si un polinomio nos interesa por que se est en una problemtica de clculos de reas bajo curvas que se representan mediante estructuras polinomiales, una de las operaciones que debera estar incluida en su representacin es aquella o aquellas que permitan la integracin.

Si, en caso contrario, nos interesa un espacio en que la suma entre polinomios es fundamental o su evaluacin, entonces el TAD debera considerar aquel tipo de operaciones. Como los clases u objetos son los elementos adecuados para la representacin de TAD, entonces se puede modificar el modelo anterior para incluir ese tipo de operaciones (ver figura).

Si se quisiera ser ms preciso en el modelado, como los dos problemas son distintos, entonces debera haber un TAD con la operacin de integracin y otro con la de la suma. En diseo, sera adecuado pensar en integrar ambos (producto de un criterio de economa).



4.5.- Criterio de Seleccin para un TAD

Ya se ha hablado que un adecuado criterio de seleccin para estructuras de datos corresponde al nivel de representatividad que esta alcanza como modelo de la realidad. Pero tambin es un criterio de diseo la complejidad de mantener una estructura de datos como la diseada.

Es decir, los procesos asociados a la mantencin de los elementos de la estructura son un importante selector de la misma.

Por ejemplo, una fila ligada puede organizarse de las siguientes dos formas:

Suponiendo que un puntero indica el inicio (I) de la fila, donde se agregan los nuevos elementos, y en el otro extremo estara el puntero al final (F) de la misma. Podemos ver que la estructura de los enlaces genera distintos procesos tanto para agregar a la fila como para eliminar de la misma.

Aparentemente iguales, la configuracin (2) resulta ms adecuada ya que el proceso de quitar de la fila es sustancialmente menos complejo que para la estructura configurada como (1), donde el puntero ubicado al final es intil.



Entonces, desde la perspectiva de una estructura de datos que incorpore los procesos,en muchos casos es la complejidad de stos los que determinan la calidad de la estructura como solucin.

4.6.- Diseo de Bases de Datos Relacionales

La creacin de una Base de Datos Relacional es una tarea larga y de alto costo. Con ello, entonces, existe la necesidad de contar con procedimientos ordenados que faciliten el desarrollo de una, ya que esto tiene una incidencia en costos y plazos de entrega, adems de la calidad y facilidad de mantenimiento del mismo.

Segn Sommerville (1988) "Un buen diseo es la clave de una eficiente ingeniera del software. Un software bien diseado es fcil de aplicar y mantener, adems de ser comprensible y fiable. Los sistemas mal diseados, aunque puedan funcionar, sern costosos de mantener, difciles de probar y poco fiables".

Muchas veces, en el pasado, el diseo de una base de datos se limitaba aplicar la teora de normalizacin, cuando en realidad debera abarcar muchas otras etapas, que van desde la concepcin hasta la instrumentacin.

As, una metodologa es un conjunto de modelos y herramientas que permiten pasar de una etapa a la siguiente en el proceso de diseo de la base de datos.

En la determinacin de las fases de la metodologa debemos definir una jerarqua de niveles de abstraccin que resulte apropiada, en el sentido de ser lo suficientemente amplia para que a cada nivel le correspondan decisiones de diseo bien definidas, pero, a la vez, no proponer demasiados niveles, ya que sera muy sensible a la interpretacin del diseador.

No existe una metodologa establecida para el diseo de bases de datos, sin embargo, ciertas etapas son distinguibles:

Diseo Conceptual, cuyo objetivo es obtener una buena representacin de los recursos de informacin de la empresa, el modelo, con independencia de usuarios o aplicaciones en particular y fuera de consideraciones de eficiencia del computador.

Diseo Lgico, cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptndolo al modelo de datos en el que se apoya el Sistema de Gestin de Bases de Datos (SGBD) que se va a utilizar (normalmente el modelo relacional).



Diseo Fsico, cuyo objetivo es conseguir una instrumentacin lo mas eficiente posible del esquema lgico.

Normalmente las causas de los malos diseos, en general, y en particular para las bases de datos, son atribuibles a dos aspectos claves en todo proceso de desarrollo:

Falta de conocimiento del dominio de la aplicacin, conocimiento que no posee el informtico, pero si el usuario (aunque no sepa estructurarlo ni expresarlo de forma precisa).

Falta de experiencia en el modelado.

4.7.- Diseo Conceptual Corresponde a, bsicamente, 2 etapas:

Etapa de anlisis de requisitos Etapa de conceptualizacin

El anlisis de requisitos debe responder a la pregunta: qu representar? Para ello hay que estudiar las reglas del negocio a diferentes niveles de la organizacin y, a partir de aquello, elaborar una descripcin de la misma. Esto corresponde al modelo de lo percibido.

Para especificarlo la idea es usar el lenguaje natural, de modo de permitir cierta sistematizacin posterior al proceso, como se ver ms adelante.

La segunda etapa responde a la pregunta del como representar?. Aqu se utilizan los lenguajes de modelado conceptual, como por ejemplo MER y sus extensiones. Aquellos define entidades, atributos, relaciones y restricciones semnticas. El resultado de esta etapa es el Modelo Conceptual.

En el paso del Modelo Percibido al Modelo Conceptual. No existen reglas claras que permitan decidir que elemento es una entidad o cual otro una interrelacin. Existen 2 enfoques que pueden ayudar:

El enfoque lingstico, que asocia a elementos del lenguaje natural categoras del los lenguajes de modelado, considerara lo siguiente:

Un sustantivo (nombre comn) que acta como sujeto o complemento directo en un frase es por lo general una entidad, aunque podra ser un atributo. Por ejemplo si tenemos los socios piden prestados libros entonces existen 2 posibles entidades: Socio y Libro.



Los nombres propios indican ocurrencias de una entidad. Por ejemplo, Pablo Neruda indica una ocurrencia de Autor.

un verbo transitivo o una frase verbal es, muy probablemente, una relacin. Por ejemplo, El socio puede pedir prestado un Libro est indicando una relacin entre las entidades Libro y Socio.

Una preposicin entre 2 nombres suele ser una relacin o tambin establece la asociacin entre una entidad y sus atributos. Por ejemplo, si tenemos la frase: la institucin del autor, se puede pensar en la relacin entre Autor e Institucin o bien, el atributo Institucin de Autor.

Por su parte el enfoque de categorizacin de objetos (Navathe, 1983) que declara en forma ms especfica las estrategias de identificacin de objetos de la base de datos considera lo siguiente:

Una entidad es un objeto de datos que tiene ms propiedades que su nombre o se utiliza como operando en una sentencia de seleccin, borrado o insercin. Por ejemplo, en la biblioteca existen libros que poseen una serie de propiedades, como son el ttulo, idioma, nmero de copias, etc. Libro es una entidad, ya que tiene varias propiedades. Por otro lado, cuando un socio deja serlo, es preciso eliminarlo de la base de datos, as Socio es una entidad, por ser un operando en una sentencia de borrado.

Un atributo es un objeto de datos al que se asigna un valor o se utiliza como operando en una operacin aritmtica, boolean, u otra. Por ejemplo, se puede consultar si el ttulo de un libro es Veinte Poemas de Amor..., con ello se puede deducir, entonces que, ttulo es un atributo.

Una relacin es un objeto de datos que hace posible la seleccin de una entidad por medio de una referencia a un atributo de otra entidad. Por ejemplo, seleccionar los libros que ha escrito un determinado autor, con lo cual escribir sera una relacin, ya que permite seleccionar una entidad, Libro, por medio de una referencia a un atributo de otra entidad: Nombre de Autor.

En esta tcnica ha cosas especiales que es bueno consignar:

"Es_Un" permite crear jerarquas de entidades y corresponde al concepto de generalizacin. Por ejemplo, tanto un Libro como un Artculo son Documentos. Donde los atributos de Documento son heredados por Articulo y Libro. Tambin pueden haber atributos que son exclusivos de las sub_entidades, por ejemplo, Editorial podra ser un atributo de



Libro pero no de Articulo.

El verbo Tiene posee muchas interpretaciones. Puede interpretarse como ocurrencia de. Por ejemplo un

Libro tiene varios Ejemplares, en el sentido que un ejemplar es una ocurrencia de libro. Cual sera el identificador de la entidad Ejemplar?. Se forma con el identificador de la entidad principal (Libro) junto a un atributo discriminante de la ocurrencia.

Como Relacin entre entidades. Por ejemplo, los libros pueden tener mas de un autor, acta como interrelacin entre Autor y Libro.

Como asociacin de las entidades con sus atributos (agregacin). Por ejemplo los libros tienen un ttulo, un ao de publicacin y un idioma. Se est asociando a la entidad Libro una serie de atributos: ttulo, ao de publicacin e idioma.

Algunos detalles que ayudan: Si decimos los socios piden prestados libros, estaramos

generando un diagrama con entidades Libro, Socio, Ejemplar, e relaciones Presta(Libro, Socio) y Tiene(Libro,Ejemplar), lo que es incorrecto. Por qu realmente lo que se presta es un ejemplar de libro as, con las mismas entidades pero diferentes configuracin de las relaciones Tiene(Libro, Ejemplar) y Presta(Ejemplar,Socio).

En las jerarquas de supertipo y subtipos, los atributos deben definirse a un nivel adecuado, es decir, si tanto Libros como Artculos tienen titulo e idioma, estos atributos deben estar en Documento.

4.8.- Caractersticas de un Modelo Conceptual

La fase de modelacin conceptual cumple los siguientes objetivos:

Captar y almacenar el Universo del Discurso (UD) mediante una descripcin rigurosa, representando la informacin que describe a la organizacin y que es necesaria para su funcionamiento.

Aislar la representacin de la informacin de los requisitos de la mquina y exigencias de cada usuario en particular.

Independizar la definicin de la informacin de los Sistemas de Gestin de Bases de Datos en concreto.

Los modelos conceptuales se caracterizan por:



Claridad, la significacin es no ambigua. Coherencia, sin contradicciones o confusiones Plenitud, representa lo esencial sin ser exhaustivo. Fidelidad, la representacin del universo del discurso ha de

hacerse sin desviaciones ni deformaciones. Simplicidad, mxima sencillez (nmero reducido de

componentes, conceptos separados, redundancia controlada).

Notar que desde un mismo Universo del Discurso se pueden obtener distintos Modelos Conceptuales (MC). El problema de la equivalencia entre Modelos Conceptuales es importante. Algunos criterios de equivalencia son:

Compatibilidad de dominios de datos, de modo que los Modelos Conceptuales representen al mismo Universo del Discurso.

Equivalencia de dependencias de datos, de modo que representen las mismas restricciones.

Equivalencia de ocurrencias de datos.

Existen ciertas restricciones de tipo semnticas que no son posibles de describir a travs del MER extendido. Muchas de estas se escriben en lenguaje natural dentro del mismo Modelo Conceptual.

4.9.-Metodologa Descendentes y Ascendentes

En las metodologas descendentes (top-down) la filosofa es que el esquema conceptual refleje directamente la visin de la empresa que se intenta modelar en la Base de Datos. Se parte por el estudio del Universo del Discurso para elaborar el modelo conceptual y sobre el se definen posteriormente vistas de usuario como subconjuntos de este modelo.

En las metodologas ascendentes (bottom-up), se entiende el modelo conceptual como el resultado de la integracin de las vistas de los distintos usuarios, por lo que empieza construyendo las distintas vistas de usuario y teniendo en cuenta las restricciones entre stas, luego se elabora un modelo conceptual mediante un proceso de integracin de aquellas vistas.

4.9.1.- Proceso de integracin de vistas

Las vistas se dividen en idnticas y no idnticas. Las idnticas contienen los mismos tipos de objetos aunque puede que con distintos nombres. Las no idnticas, poseen diferentes tipos de objetos (todo o en parte). Dentro de estas ultimas hay que distinguir las que son equivalentes de las que no lo son.



La integracin de vistas consiste en que a partir de dos vistas se llega a obtener una tercera que las englobe, as sucesivamente hasta llegar al esquema global. Al querer integrar vistas surgen algunos problemas:

1.- Conflictos de nombres:

Homonimia, a dos objetos se les ha asignado el mismo nombre Sinonimia, un mismo objeto con ms de un nombre para las

distintas vistas. Por ejemplo, una vista trata con Autor y con codigo_autor como atributo identificador y otro, con Escritor y codigo_escritor, la solucin es optar por usar una de las dos entidades con su respectivo identificador. En el caso de relaciones, por ejemplo, una Revista Publica Articulo o bien, en una Revista Aparece un Articulo. La solucin es, nuevamente, adoptar uno solo.

2.- Conflictos entre entidades:

Una entidad es un subconjunto de otra. Solucin: introducir un subtipo. Ej: entidades Revista y Publicacin, donde esta ultima incluye revistas, recopilaciones y otros tipos, este conflicto se puede resolver introduciendo la revista como un subtipo de publicacin. Se llama restriccin de seleccin.

Una entidad es disjunta con respecto a otra, pero ambas poseen atributos comunes, es decir, son un subtipo de una tercera entidad. Solucin: crear el supertipo. Se llama restriccin de disyuncin.

3.- Conflicto entre tipos de objetos en los que un atributo en una vista es una entidad en otra o viceversa:

La solucin es transformar el atributo en entidad o la entidad en atributo segn convenga. Por ejemplo es Editorial una entidad o es un atributo de Libro?. Si vemos que es importante almacenar informacin de la editorial la consideraremos una entidad, sino ser atributo. En este caso tambin puede ser importante para evitar redundancias, el que Editorial sea una entidad en el entendido que lo que se almacena es el nombre de la editorial.

4.- Conflicto de cardinalidades en interrelaciones:

Por ejemplo la relacin Escribe entre Autor y Documento, en un caso (1,n) y en otro (n,n).



Si se trata de la misma relacin, en este caso se deja la

menos restrictiva n,n. Si se trata de dos relaciones distintas como Escribe de

tipo n,n y Edita de tipo 1,n (suponiendo que un documento puede ser editado por una persona). En este caso se deben reflejar ambas interrelaciones con distintos nombres.

Puede ser que mientras la entidad Autor tiene una relacin con Documento que es Escribe, mientras que un subtipo de ella (que es Editor) tiene otra relacin con Documento, que es Edita.

Puede ser que existan dos subtipos de la entidad Autor, que poseen relaciones distintas con Documento, por ejemplo, el subtipo Escritor y el subtipo Editor con las interrelaciones Escribe y Edita, respectivamente.

5.- Anlisis de redundancia de interrelaciones:

Una vez integradas las vistas, habr que analizar si se producen redundancias de relaciones, lo que grficamente se reflejan en ciclos.

4.10.- Diseo Lgico

En esta etapa se transforma el Modelo Conceptual obtenido en la faseanterior a un Modelo Relacional. Este Modelo sigue siendoindependiente del Sistema de Gestin de Bases de Datos que seutilizar en la siguiente etapa..

Dominios (MER)En el modelo relacional estndar un dominio es un objeto ms, propio de la estructura del modelo que, como tal, debe tener su definicin concreta en el lenguaje de definicin de datos DDL que se elija. (Muchos SGBDR comerciales no proveen esta definicin).

Por ejemplo:CREATE DOMAIN Estado_Civil AS CHAR(1)CHECK (VALUE IN (S, C, V, D))

Entidades (MER)Cada entidad se convierte en una relacin. Cada relacin que corresponda a una entidad llevar su mismo nombre. Para su definicin fsica se usa la sentencia CREATE TABLE.



Atributos compuestos y polivalentes (MEREx).

El modelo relacional admite slo atributos simples, monovalentes.Cada atributo compuesto se puede transformar segn las siguientes dos alternativas:

Eliminar el atributo compuesto considerando todos sus componentes como atributos individuales, o

eliminar los componentes individuales y considerar el atributo compuesto entero como un slo atributo.

Direccin

Calle

Nmero

Rut

Nombre

Ciudad

Persona

Modelos Relacionales posibles:

1ro. Persona (Rut, Nombre, Calle, Nmero, Ciudad)2do. Persona (Rut, Direccin)

Los atributos polivalentes requieren la introduccin de relaciones nuevas; cada atributo polivalente distinto requiere una relacin en la cual pueda estar representado como atributo monovalente. La nueva relacin contiene el atributo polivalente ms el identificador de la entidad original; el identificador de la nueva relacin es el conjunto de todos sus atributos.

Direccin

Calle

Nmero

Rut

Nombre

Ciudad

Persona(1,n)

Modelo Relacional:

Persona(Rut, Nombre)Direccin(Rut, Calle, Nmero, Ciudad) con Rut clave fornea que referencia a Persona.



Atributos identificadores (MER)

El o los atributos identificadores de cada tipo de entidad pasan a ser la clave de la relacin si es que son los identificadores principales. Se usa la clusula PRIMARY KEY en el Modelo Fsico.

Respecto a los identificadores alternativos, se utiliza la clusula UNIQUE a nivel del SGBDR.

Otros atributos (MER)Los atributos no identificadores pasan a ser columnas de la tabla, las cuales tienen permitido tomar valores nulos, a no ser que se indique lo contrario.

Relaciones (MER)Dependiendo del tipo de correspondencia de la interrelacin, variar la manera de realizar la transformacin del esquema.

Relaciones N:M (muchos a muchos) (MER)Un tipo de interrelacin N:M se transforma en una relacin que tendr como clave primaria la concatenacin de los identificadores de las entidades que asocia.

No hay manera de diferenciar en el Modelo Relacional cuales relaciones provienen de Entidad y cuales provienen de otras Relaciones. Utilizando alguna norma en los nombres se puede superar de algn modo esta prdida de semntica.

Cada uno de los atributos que forman la clave primaria de una relacin derivada de un tipo de interrelacin N:M son clave fornea respecto de cada una de las relaciones derivadas de las entidades que relaciona. Esto se especifica, en el Modelo Fsico, a travs de la clausula FOREIGN KEY dentro de la sentencia de creacin de la tabla.

EscribeAutor Libro(1,n) (0,n)

@cod-autor @cod-libro + ttulo

El modelo relacional resultante:

Autor (cod-autor)Libro(cod-libro, ttulo)Escribe(cod-libro, cod-autor ) con cod-libro clave fornea que referencia a Libro y cod-autor clave fornea que referencia a Autor



Relaciones 1:NAqu existen dos casos a considerar.a. La entidad del lado de muchos tiene una participacin obligatoria.

Pertenecea

Ciudad Regin(1,1) (1,n)

@nombre + habitantes @nmero + nombre + habitantes

El modelo relacional resultante:Ciudad( Nombre-Ciudad, Nmero Regin, habitantes) Regin( Nmero-Regin, nombre, habitantes)

b. La entidad del lado de muchos tiene una participacin parcial.

Pertenecea

Pedido Vendedor(0,1) (1,n)

@num-pedido + fecha tasa-descuento @nombre + fono

Los pedidos pueden hacerse por medio de vendedores, en cuyo caso se aplica una tasa de descuento, y tambin directamente sin vendedores (sin aplicar una tasa de descuento). De este modo, existe la posibilidad de valores nulos de nombre-vendedor y tasa-descuento en relacin a Pedido si se usa el siguiente esquema:

Pedido( Num-Pedido, fecha, nombre-vendedor, tasa descuento)Vendedor( Nombre, fono)

Si el nmero relativo de esos pedidos es grande, y no se puede admitir valores nulos, una mejor alternativa sera establecer tres relaciones (lo cual es el caso ms general):

Vendedor ( nombre, fono)Pedido (num-pedido, fecha)Pedido-ventas (num-pedido, nombre-vendedor, tasa-descuento)

(num-pedido en Pedido ventas es clave fornea, referenciando a Pedido).

Relaciones 1:1Aqu consideramos dos alternativas, la integracin en una relacin y la definicin de una relacin aparte.

La opcin de integracin en una relacin tiene sentido cuando la participacin de las dos entidades en la relacin es total (cardinalidad mnima 1). Hay dos posibilidades:



a. Las dos entidades tienen las mismas claves primarias. En este caso las dos relaciones correspondientes se integran en una relacin combinando todos los atributos e incluyendo la clave primaria slo una vez.

ConCliente InfoEnvo(1,1) (1,1)

@num-cliente + nombre-cliente @num-cliente + direccin-envo

El esquema relacional resultante:Envo-Cliente( num-cliente, nombre-cliente, direccin-envo)

b. Las dos entidades tienen claves primaria diferentes.Supongamos que Cliente e Info Envo tienen claves primarias diferentes, num-cliente y direccin-envo respectivamente. En este caso tambin se integran en una relacin combinando todos los atributos e incluyendo las claves primarias de ambas. La clave primaria de la relacin ser una de las dos, por ejemplo, la relacin que sigue usa num-cliente como clave primaria:

Envo-Cliente (num-cliente, nombre-cliente, direccin-envo)

La opcin de definicin de una relacin aparte se usa cuando una o las dos entidades tienen una participacin parcial (cardinalidad mnima 0). Aqu tambin hay dos posibilidades:a. Una entidad tiene participacin parcial.

PoseeCliente TarjetaCrdito

(0,1) (1,1)

@num-cliente + nombre @(tipo-tarjeta + nmero) + crdito

El esquema relacional resultante:Cliente (num-cliente, nombre-cliente)Tarjeta Crdito ( tipo-tarjeta, nmero, crdito) Posee Tarjeta( tipo-tarjeta, nmero, num-cliente)

b. Las dos entidades tiene participacin parcial.

MatrimonioHombre Mujer(0,1) (0,1)

@rut + nombre fecha @rut + nombre

El esquema relacional resultante:Hombre (rut-hombre, nombre)Mujer (rut-mujer, nombre)Matrimonio (rut-hombre, rut-mujer, fecha)



Atributos de RelacionesSi la relacin se transforma en una relacin del Modelo Relacional, todos sus atributos pasan a ser columnas de la relacin.

En caso de que la relacin se transforme mediante propagacin de clave, sus atributos migran junto con la clave a la relacin que corresponda, aunque puede ser mejor crear una nueva relacin para representar un interrelacin que tiene atributos.

Relaciones exclusivas (MEREs)Para soportar interrelaciones exclusivas se deben definir las restricciones pertinentes en cada caso.

edita1Libro

edita2

Universidad

Editorial

(1,n)

(1,n)

(0,1)

(0,1)

Modelo Relacional:

Libro(Id-Libro, ..., Id-Editorial, Id-Universidad)Universidad (Id-Universidad, ...)Editorial (Id-Editorial, ...)

En este caso, se propagan las claves de Universidad y Editorial a Libro. Para obligar a que se cumpla la exclusividad hay que introducir las correspondientes restricciones en una clasula CHECK:CHECK (( Id-Editorial IS NULL and Id-Universidad IS NOT NULL) OR (Id-Editorial IS NOT NULL and Id-Universidad IS NULL))

Generalizaciones (MEREx)Las generalizaciones no son objetos que puedan representarse directamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformacin, con la consiguiente prdida de semntica dependiendo de la estrategia elegida, las cuales son 3:

1. Integrar la jerarqua de generalizacin en una sola entidad uniendo los atributos de las subentidades y aadiendo estos atributos a los de la superentidad. Esto se permite si la distincin entre las subentidades no es significativa desde el punto de vista de una aplicacin. Ms an, se aade un atributo discriminativo para indicar el caso al cual pertenece la



entidad en consideracin. Esta alternativa es aplicable a todos los casos, con todas las coberturas, teniendo el problema de tener que manejar en algunos casos demasiados valores nulos y que las operaciones que slo actuaban sobre una subentidad tendrn que buscar ahora los casos correspondientes dentro del conjunto completo de casos.

Estudiante

Pregrado Postgrado

(p,e)

Estudiante = @ nmero-matrcula + nombrePregrado = CarreraPostgrado = Ttulo-tesis

Esquema Relacional resultante:Estudiante ( Nmero-matrcula, nombre, carrera, ttulo-tesis, tipo)

Adems se debe verificar la exclusividad: CHECK ( (tipo = Postgrado AND carrera IS NULL AND titulo-tesis IS NOT NULL) OR (tipo = Pregrdao AND carrera IS NOT NULL AND titulo-tesis IS NULL))

2. Eliminar la superentidad reteniendo las subentidades. Aqu los atributos heredados deben propagarse entre las subentidades. Esta alternativa no es prctica para generalizaciones superpuestas o parciales; slo lo es para jerarquas totales y exclusivas. Adems, si el nmero de atributos de la superentidad (comunes a toda las subentidades) es excesivo, su duplicacin en el esquema de cada subentidad no se justifica.

Empleado

Ingeniero Gerente

(t,e)

Empleado = @ rut + nombreIngeniero = especialidadGerente = Nmero-supervisados

Esquema Relacional resultante:



Ingeniero (rut, nombre, especialidad)Gerente (rut, nombre, Nmero-supervisados)

3. Retener todas las entidades y establecer explcitamente las interrelaciones entre la superentidad y las subentidades. Esta alternativa se puede considerar como la ms general de las tres, ya que siempre es posible. Las desventajas de este enfoque son que el esquema resultante es bastante complejo y hay una redundancia inherente al representar cada eslabn ES-UN en la jerarqua original a travs de una relacin explcita. Las ventajas, por otra parte, son que modela todos los casos, lo que la hace ms flexible ante cambios de requerimientos, y es conveniente si la mayora de las operaciones son estrictamente locales respecto a la superentidad o a una de las subentidades.

Proyecto

DesarrolloSw Subcontrato

(p,s)

Proyecto = @Nmero-proyecto + nombre-proyectoDesarrollo-Sw = Nmero mdulosSubcontrato = contratista-principal

Esquema Relacional resultante:Proyecto (Nmero-proyecto, nombre-proyecto)Desarrollo-Sw (Nmero-proyecto, Nmero Mdulos)Subcontrato(Nmero-proyecto, contratista-principal)

Donde en Desarrollo-Sw y subcontrato las claves primarias son a su ves claves forneas que referencias a proyecto, implementando de ese modo las relaciones ES-UN.

Atributos Derivados (MEREx)No existe para los atributos derivados una representacin directa y concreta en el modelo relacional y sus SGBD. En este caso, los atributos se tratan de la forma usual, implementando los procedimientos que calculen el valor del atributo derivado cada vez que inserten o borren las ocurrencias de los atributos que intervienen en el clculo de este y aadir las restricciones correspondientes.Transformacin de dependencias en identificacin y en existencia

LIBRO tiene EJEMPLAR( , )1 1 ( ,n)0



En MR: LIBRO(cod_libro,...)

EJEMPLAR(cod_libro, cod_ejemplar,...)clave fornea, NOT NULL, ON DELETE CASCADE, ON UPDATE

CASCADE.

Para dependencia en identificacin, la clave primaria de la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades participantes en la interrelacin.


En esta etapa se transforma el Modelo Conceptual obtenido en la faseanterior a un Modelo Relacional. Este Modelo sigue siendoindependiente del Sistema de Gestin de Bases de Datos que seutilizar en la siguiente etapa..Dominios (MER)Entidades (MER)Atributos compuestos y polivalentes (MEREx).Atributos identificadores (MER)Otros atributos (MER)

Relaciones (MER)Relaciones N:M (muchos a muchos) (MER)Relaciones 1:NRelaciones 1:1

Atributos de RelacionesRelaciones exclusivas (MEREs)Generalizaciones (MEREx)Atributos Derivados (MEREx)Transformacin de dependencias en identificacin y en existencia

Documents

Capitulo 5- Diseño de Datos