Capitulo 5 - Diseño de Datos

Diseo de Software
Gustavo A. Donoso M.
Diseo de Software
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
Diseo de Software
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 m
Pedro
1.35
28.6
Mara
1.30
25.8
Juan
1.40
38.3
Rosa
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.
Diseo de Software
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.
Ejercicios
1.HagaundiseoenDiagramadeClasesparalasestructurasdedatos
clsicas:ListaLineal,Pila,Fila,ListaDoblementeLigadayArbol.
2.Cmorepresentaraunestacionamiento,demodoqueesaestructura
sealabasedeunsistemadecontroldeocupacindelmismo.
3.Representelashorasdelda,paramanejarunrelojcontrol.
4.Representeyhagaeldiseodelaestructuradedatosparalas
cancionesdeundiscocompacto.
5.Representeyhagaeldiseodelaestructuradedatosparaun
conjuntodediscoscompactos.
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)
Diseo de Software
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).
Diseo de Software
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.
Diseo de Software
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 de Software
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.
Diseo de Software
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
Diseo de Software
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:
Diseo de Software
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.
Diseo de Software
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).
Diseo de Software
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 fase
anterior a un Modelo Relacional. Este Modelo sigue siendo
independiente del Sistema de Gestin de Bases de Datos que se
utilizar 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.
Diseo de Software
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.
Rut
Nombre
Calle
Persona
Direccin
Nmero
Ciudad
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.
Rut
Nombre
Persona
Calle
(1,n)
Direccin
Nmero
Ciudad
Modelo Relacional:
Persona(Rut, Nombre)
Direccin(Rut, Calle, Nmero, Ciudad) con Rut clave fornea que
referencia a Persona.
Diseo de Software
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.
Autor
(1,n)
Escribe
@cod-autor
(0,n)
Libro
@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
Diseo de Software
Relaciones 1:N
Aqu existen dos casos a considerar.
a. La entidad del lado de muchos tiene una participacin
obligatoria.
Ciudad
(1,1)
@nombre + habitantes
Pertenece
a
(1,n)
Regin
@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.
Pedido
(0,1)
Pertenece
a
@num-pedido + fecha tasa-descuento
(1,n)
Vendedor
@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:1
Aqu 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:
Diseo de Software
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.
Cliente
(1,1)
(1,1)
Con
@num-cliente + nombre-cliente
InfoEnvo
@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.
Cliente
(0,1)
@num-cliente + nombre
Posee
(1,1)
Tarjeta
Crdito
@(tipo-tarjeta + nmero) + crdito

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.
Hombre
(0,1)
@rut + nombre
Matrimonio
fecha
(0,1)
Mujer
@rut + nombre

Hombre (rut-hombre, nombre)
Mujer (rut-mujer, nombre)
Matrimonio (rut-hombre, rut-mujer, fecha)
Diseo de Software
Atributos de Relaciones
Si 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.
Libro
(0,1)
edita1
(1,n)
Universidad
(0,1)
edita2
(1,n)
Editorial
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 (IdEditorial 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
Diseo de Software
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
(p,e)
Pregrado
Postgrado
Estudiante = @ nmero-matrcula + nombre

Pregrado = Carrera
Postgrado = 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
(t,e)
Ingeniero
Gerente
Empleado = @ rut + nombre

Ingeniero = especialidad
Gerente = Nmero-supervisados
Diseo de Software
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 ESUN 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
(p,s)
DesarrolloSw
Subcontrato
Proyecto = @Nmero-proyecto + nombre-proyecto

Desarrollo-Sw = Nmero mdulos
Subcontrato = contratista-principal
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
(1,1)
tiene
(0,n)
EJEMPLAR
Diseo de Software
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.

Capitulo 5 - Diseño de Datos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Capitulo 5 - Diseño de Datos

Transféré par

Droits d'auteur :

Formats disponibles

Diseo de Software

Conocer y aplicar lo que se entiende por diseo y especificacin

Es lo que llamamos usualmente un registro y permite representar

La tabla, como se vea, permite modelar relaciones de pertenencia de

Donde un curso es una agregacin de Nio. Los atributos de Nio son

Ahora la pregunta que queda es si aquello es un diseo de la

Para continuar con el tema de cmo representamos/diseamos

As, una clase trminos debera contener aquellos dos atributos:

Como un polinomio entonces es un conjunto de trminos, el modelo

4.4.- Tipos Abstractos de Datos

4.5.- Criterio de Seleccin para un TAD

Suponiendo que un puntero indica el inicio (I) de la fila, donde se

Entonces, desde la perspectiva de una estructura de datos que

Diseo Conceptual, cuyo objetivo es obtener una buena

Diseo Lgico, cuyo objetivo es transformar el esquema

Diseo Fsico, cuyo objetivo es conseguir una instrumentacin

Normalmente las causas de los malos diseos, en general, y en

Falta de conocimiento del dominio de la aplicacin,

Falta de experiencia en el modelado.

4.7.- Diseo Conceptual

El anlisis de requisitos debe responder a la pregunta: qu

Un sustantivo (nombre comn) que acta como sujeto o

Los nombres propios indican ocurrencias de una entidad. Por

un verbo transitivo o una frase verbal es, muy probablemente,

Una preposicin entre 2 nombres suele ser una relacin o

Por su parte el enfoque de categorizacin de objetos (Navathe, 1983)

Una entidad es un objeto de datos que tiene ms propiedades

Un atributo es un objeto de datos al que se asigna un valor o se

Una relacin es un objeto de datos que hace posible la seleccin

En esta tcnica ha cosas especiales que es bueno consignar:

"Es_Un" permite crear jerarquas de entidades y corresponde al

Libro pero no de Articulo.

El verbo Tiene posee muchas interpretaciones.

Puede interpretarse como ocurrencia de. Por ejemplo un

Como Relacin entre entidades. Por ejemplo, los libros

Como asociacin de las entidades con sus atributos

Algunos detalles que ayudan:

Si decimos los socios piden prestados libros, estaramos

En las jerarquas de supertipo y subtipos, los atributos deben

4.8.- Caractersticas de un Modelo Conceptual

Captar y almacenar el Universo del Discurso (UD) mediante una

Aislar la representacin de la informacin de los requisitos de la

Independizar la definicin de la informacin de los Sistemas de

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

Simplicidad, mxima sencillez (nmero reducido de

Notar que desde un mismo Universo del Discurso se pueden obtener

Compatibilidad de dominios de datos, de modo que los Modelos

Equivalencia de dependencias de datos, de modo que

Equivalencia de ocurrencias de datos.

Existen ciertas restricciones de tipo semnticas que no son posibles

La integracin de vistas consiste en que a partir de dos vistas se llega

Homonimia, a dos objetos se les ha asignado el mismo nombre

Sinonimia, un mismo objeto con ms de un nombre para las

2.- Conflictos entre entidades:

Una entidad es un subconjunto de otra. Solucin: introducir un

Una entidad es disjunta con respecto a otra, pero ambas poseen

La solucin es transformar el atributo en entidad o la entidad en

4.- Conflicto de cardinalidades en interrelaciones:

Por ejemplo la relacin Escribe entre Autor y Documento, en