Modelo de datos entidad relaci�n extendido by 7dfAuu

VIEWS: 39 PAGES: 31

									Modelo de datos entidad relación extendido

El MERE comprende todos los conceptos de modelado ER presentados en cursos
anteriores, pero además incluye los conceptos de subclase y superclase y los
conceptos relacionados de especialización, generalización, y el de categoría.

En muchos casos, un tipo de entidad tiene varias subagrupaciones que son
significativas y que deben representarse explícitamente por su importancia para la
aplicación de la base de datos. Por ejemplo, las entidades que son miembros del
tipo de entidad EMPLEADO pueden agruparse en entidades SECRETARIA,
INGENIERO,TECNICO, siendo cada una de estas agrupaciones un subconjunto de
las entidades que pertenecen al tipo EMPLEADO. En consecuencia toda entidad que
sea miembro de una de estas subagrupaciones también será un empleado. Cada
una de estas agrupaciones es una subclase del tipo de entidad EMPLEADO, y
EMPLEADO es la superclase de cada una de estas clases.

La relación entre un superclase y cualquiera de sus subclases es un vínculo
clase/subclase. Una ocurrencia de entidad miembro de la subclase representa a
la misma entidad del mundo real que algún miembro de la superclase. La secretaria
Ana López es también el empleado Ana López, lo que quiere decir que el miembro
de la subclase es igual a la entidad de la superclase, pero tiene un papel específico
distinto. Una entidad de la subclase representa la misma entidad del mundo real de
la superclase, por lo tanto debe poseer valores para sus atributos específicos
además de valores de sus atributos como miembro de la superclase. Decimos
entonces que una entidad miembro hereda todos los atributos de la entidad como
miembro de la superclase.

La especialización es el proceso de definir un conjunto de subclases de un tipo de
entidades denominado la superclase de la especialización. Así, el conjunto
{SECRETARIA,INGENIERO,TECNICO} es una especialización de la superclase
EMPLEADO, que se distingue entre las entidades según el tipo de trabajo de cada
entidad.

Es posible tener varias especializaciones del mismo tipo de entidades basadas en
diferentes características distintivas. Por ejemplo, otra especialización del tipo
EMPLEADO puede originar el conjunto de subclases {EMPLEADO_DE_PLANTA,
EMPLEADO_CONTRATA} que distingue a los empleados según el método de
compensación económica que reciben.

La figura muestra la forma como representamos una especialización en forma
gráfica. Las subclases que definen una especialización se conectan con líneas a un
semi-círculo, el cual se conecta a la superclase.
La flecha indica la dirección del vínculo superclase/clase, es decir especialización, o
generalización, la doble línea señala una especialización total, la línea simple una
especialización parcial.

La cruz dentro del semicírculo indica exclusión mutua, es decir las subclases de una
especialización deben ser disjuntas. Un empleado está en la planta ó está a
contrata.

Cualquier atributo que se aplique sólo a entidades de una determinada subclase -
grado técnico- se incorporan al diagrama, denominándose atributos específicos
de la subclase.

De manera similar, una subclase puede participar en tipos de vínculos
específicos, como la participación de EMPLEADO_CONTRATA en afiliado_a.

Un vínculo superclase/subclase como EMPLEADO/SECRETARIA se parece un poco a
un vínculo 1:1, con la diferencia que en este último caso, dos entidades distintas
están relacionadas . Podemos considerar que una entidad de la subclase es lo
mismo que la entidad de la superclase pero con un papel especializado; por
ejemplo, un EMPLEADO especializado en el papel de SECRETARIA, o un empleado
especializado en el papel de TECNICO.

      Empleado{e1,e2,e3,e4,e5,e6,e7....,e500}
      Secretaria{e1,e4,e5...}
      Ingeniero{e2,e7,..}
      Tecnico{e3,e8,..}
Hay dos razones principales para incluir vínculos clase/subclase en un modelo de
datos.

La primera es que ciertos atributos pueden aplicarse a algunas de las entidades,
pero no a todas. Se define entonces una subclase para agrupar las entidades a las
que se aplican estos atributos. Los miembros de la subclase pueden compartir la
mayor parte de sus atributos con los demás miembros de la superclase. Es el caso
de las subclases SECRETARIA e INGENIERO, que comparten sus demás atributos,
como miembros del tipo EMPLEADO.

La segunda razón es que en algunos tipos de vínculos sólo pueden participar
entidades que sean miembros de la subclase. Es el caso de la subclase
EMPLEADO_CONTRATA, que fue necesario crearla para indicar que sólo sus
miembros pueden relacionarse con un sindicato.

Lo que hemos hecho hasta el momento nos permite:

      definir un conjunto de subclases de un tipo de entidades
      asociar atributos específicos adicionales a cada clase
      establecer vínculos específicos adicionales entre cada subclase y otros tipos
       de entidades, u otras subclases.

Sin . embargo, es posible concebir un proceso inverso de abstracción en el que
suprimimos las diferencias entre varios tipos de entidades, identificamos sus rasgos
comunes y los generalizamos para formar una sola superclase de la cual los
tipos de entidades originales sean subclases especiales.

Observemos que el proceso de generalización puede considerarse como el inverso
funcional del proceso de especialización, por ello podemos ver {COCHE, CAMION}
como una especialización de VEHICULO, en vez de ver Vehiculo como una
generalización de coche y camion.

Las restricciones que comentaremos se aplican tanto a la generalización como a la
especialización. En general, puede haber varias especializaciones definidas sobre la
misma superclase. En un caso así, las ocurrencias pueden pertenecer a subclases
en cada una de las especializaciones. Puede darse el caso también, que una
especialización consista de una sola subclase -GERENTE-. En algunas
especializaciones podemos determinar con exactitud las ocurrencias que se
convertirán en miembros de cada subclase, para lo cual especificamos una
condición en términos del valor de algún atributo de la superclase. Tales subclases
se llaman subclases definidas por predicado o por condición. Por ejemplo, si
la entidad EMPLEADO tiene un atributo tipo de trabajo, podemos especificar la
condición de pertenencia a la subclase SECRETARIA mediante el predicado (tipo de
trabajo = "secretaria") al cual llamamos predicado de definición de la subclase.
Esta condición es una restricción que especifica que los miembros de la subclase
SECRETARIA deben satisfacer el predicado y que todas las ocurrencias de
EMPLEADO cuyo valor para el atributo tipo de trabajo sea "Secretaria" deben
pertenecer a la subclase.
Si la condición de pertenencia de todas las subclases de una especialización están
definidas en términos del mismo atributo de la superclase, se dice que la
especialización misma es una especialización definida por atributo, y el atributo
se denomina atributo de definición de la especialización.

Cuando no tenemos una condición que determine la pertenencia, se dice que la
subclase está definida por el usuario. La pertenencia a tales subclases la
determinan los usuarios de la base de datos cuando aplican la operación de añadir
una ocurrencia a la subclase; así entonces, el usuario especifica
individualmente la pertenencia a la subclase y no hay una condición que pueda
evaluarse automáticamente.

Esta restricción especifica que las subclases de una especialización deben ser
disjuntas, lo que significa que una ocurrencia de entidad puede ser miembro de
cuando más una de las subclases de la especialización.

Una especialización definida por atributo implica la restricción de disyunción si el
atributo con que se define el predicado de pertenencia es monovaluado.

Si las subclases no son disjuntas, sus ocurrencias pueden traslaparse, es decir, la
misma ocurrencia puede ser miembro de más de una subclase de la especialización.
Este, que es el caso por omisión, se indica colocando una o como lo indica la
siguiente figura.
La segunda restricción sobre la especialización se denomina restricción de
compleción, la cual puede ser total o parcial.

Una restricción de especialización total especifica que toda ocurrencia de la
superclase debe ser miembro de alguna subclase de la especialización. Por ejemplo
si todo EMPLEADO debe ser EMPLEADO_DE_PLANTA ó EMPLEADO_CONTRATA, la
especialización {EMPLEADO_DE_PLANTA, EMPLEADO_CONTRATA} es una
especialización total de EMPLEADO; esto se indica en los diagramas con una línea
doble.
Las restricciones de disyunción y de compleción son independientes, de modo que
distinguiremos 4 tipos de especialización :

                                  disjunta, total
                                  disjunta, parcial
                                  traslapada, total
                                  traslapada, parcial

Como consecuencia de las restricciones señaladas, se aplican ciertas reglas de
inserción y de eliminación a la especialización y a la generalización.

      la eliminación de una ocurrencia de una superclase implica que
       automáticamente se le elimina de todas las subclases a las que pertenece.
      la inserción de una ocurrencia en una superclase implica que se debe
       insertar por fuerza en todas las subclases definidas por predicado para las
       cuales la ocurrencia satisface el predicado de definición.
      la inserción de una ocurrencia en una superclase de una especialización
       total implica que la ocurrencia se insertará por fuerza en por lo menos una
       de las subclases de la especialización.
Es posible especificar subclases de una subclase, formando una jerarquía o retícula
de especializaciones.

Por ejemplo, en la figura anterior, INGENIERO es una subclase de EMPLEADO y
también es superclase de GERENTE INGENIERIA; esto representa la restricción del
mundo real según la cual todo gerente de ingeniería debe ser un ingeniero.

Una jerarquía de especialización tiene la restricción de que toda subclase
participa -como subclase- en un vínculo clase/subclase, a diferencia de una
retícula de especialización en que una subclase puede ser subclase en más de
un vínculo clase/subclase.
En una retícula o jerarquía de especialización como ésta, una subclase hereda los
atributos no sólo de su superclase directa, sino también de todas sus superclases
predecesoras, incluída la raíz.

Una subclase con más de una superclase se denomina subclase compartida. Por
ejemplo, si todo gerente de ingeniería debe ser ingeniero pero además debe ser de
planta, entonces GERENTE_INGENIERIA debería ser una subclase compartida de ls
tres superclases.

Esto lleva al concepto de herencia múltiple , ya que la subclase compartida
hereda diractamente atributos y vínculos de múltiples subclases.

Observe que las subclases compartidas dan origen a una retícula; si no existieran
subclases compartidas, tendríamos una jerarquía en vez de una retícula.

Aunque sólo nos hemos referido a la especialización, conceptos similares se aplican
de igual manera a la generalización.

En el proceso de especialización, por lo regular comenzamos con un tipo de
entidades y luego definimos subclases por especialización sucesiva; esto es,
definimos repetidamente agrupaciones más específicas de la entidad.
Por ejemplo, al definir la retícula de especialización de la figura anterior, podríamos
primero especificar un tipo de entidades PERSONA, para una BD universitaria, luego
descubrimos que se representarán tres tipos de personas en la BD: empleados de
la universidad, ex-alumnos y estudiantes, creando las respectivas especializaciones,
observando que existe traspale porque una persona puede pertenecer a más de
una subclase. Luego especializamos EMPLEADO y ESTUDIANTE y finalmente
especializamos AYUDANTE.




Aqui


Esta especialización sucesiva corresponde a un proceso de refinación conceptual
descendente durante el diseño conceptual del esquema. Hasta aquí tenemos una
jerarquía, pero al incorporar la clase compartida AYUDANTE, damos lugar a una
retícula.

Es posible llegar a la misma jerarquía o retícula desde la dirección opuesta.. En un
caso así, el proceso implica generalización más que especialización y corresponde a
una síntesis conceptual ascendente.

En términos estructurales, las jerarquías o retículas que resultan de cualquiera de
los dos procesos pueden ser idénticas; la única diferencia tiene que ver con la
manera o el orden en que se especificaron las superclases y subclases del
esquema.

En la práctica, es probable que no se sigan estrictamente ni el proceso de
generalización ni el de especialización, sino que se utilice una combinación de
ambos. En tal caso, se incorporan continuamente nuevas clases en una jerarquía o
retícula conforme se hacen obvias para los usuario y los diseñadores.

Esta idea de representar lo datos y conocimientos mediante jerarquías y retículas
de superclases y subclases es muy común en los sistemas basados en
conocimientos y en los sistemas xpertos, que combinan la tecnología de bases de
datos con técnicas de inteligencia artificial.

Todos los vínculos vistos hasta el momento tienen una sola superclase, incluso la
subclase compartida GERENTE_INGENIERIA es subclase en tres vínculos
superclase/subclase distintos, y cada uno de los vínculos tiene una sola
superclase.

Hay algunos casos en que es necesario modelar un solo vínculo superclase/subclase
con más de una superclase, donde las superclases representan diferentes
entidades.

En este caso decimos que la subclase es una categoría.

Supongamos que tenemos tres tipos de entidades: PERSONA, BANCO y COMPAÑIA.
En una BD para registro de vehículos, el dueño de un vehículo puede ser una
persona, un banco, -con embargo preventivo sobre el vehículo- o una compañía.
Necesitamos crear una clase que incluya ocurrencias de los tres tipos para
desempeñar el papel de dueño del vehículo. Para este fin se crea una categoría
DUEÑO que es una subclase de la unión de las tres clases PERSONA,BANCO y
COMPAÑIA.




Las superclases COMPAÑIA, BANCO y PERSONA se conectan con el símbolo U , que
representa la operación de unión de conjuntos. Si se necesita un predicado de
definición, se muestra junto a la línea que proviene de la superclase a la que se
aplica el predicado. En la figura tenemos dos categorías : DUEÑO y VEHICULO
REGISTRADO.
Una categoría tiene dos o más superclases que pueden representar distintos tipos
de entidades, mientras que otros vínculos superclase/subclase siempre tienen una
sola superclase.

Podemos comparar una categoría, como DUEÑO, con la subclase compartida
GERENTE INGENIERIA. La segunda es una subclase de cada una de las tres
superclases INGENIERO, GERENTE y EMPLEADO DE PLANTA, así una ocurrencia
miembro de GERENTE INGENIERIA deberá existir en las tres , lo que significa
GERENTE INGENIERIA es un subconjunto de la intersección de las tres
superclases.

Por otro lado, una categoría es un subconjunto de la unión de sus superclases, por
ello una ocurrencia de DUEÑO deberá existir en por lo menos una de las
superclases pero no tiene que ser miembro de todas ellas. Esto representa la
restricción de que un DUEÑO puede ser una COMPAÑIA, un BANCO o una
PERSONA.

La herencia de atributos funciona de manera más selectiva en las categorías. Por
ejemplo, cada ocurrencia de DUEÑO hereda los atributos de una COMPAÑIA, una
PERSONA o un BANCO, dependiendo de la superclase a la que pertenezca la
ocurrencia. Esto se denomina herencia selectiva . Por otro lado, una subclase
compartida hereda todos los atributos de sus superclases.

Observemos la diferencia entre la categoría VEHICULO REGISTRADO y la superclase
generalizada VEHICULO de la figura siguiente:




En esta última, cada automóvil y cada camión es un vehículo, en cambio la
categoría VEHICULO REGISTRADO contiene algunos automoviles y algunos
camiones, pero no necesariamente todos ellos -pudiera haber automóviles o
camiones no registrados-.

En general una especialización o generalización, si fuera parcial, no impediría que
VEHICULO contuviera otros tipos de de ocurrencias como las motocicletas. Sin
embargo, una categoría como VEHICULO REGISTRADO implica que sólo
automóviles y camiones, y ninguna otro tipo de ocurrencia, puedan ser miembros
de VEHICULO REGISTRADO.

Una categoría puede ser parcial o total, por ejemplo CUENTA CORRENTISTA es una
categoría parcial definida por predicado donde c1 y c2 son condiciones de
predicado que especifican cúales entidades COMPAÑIA y PERSONA,
respectivamente, son miembros de CUENTA CORRENTISTA.




Las superclases de una categoría pueden tener diferentes atributos clave, -DUEÑO-
; o bién pueden tener el mismo atributo clave -VEHICULO REGISTRADO-.

Por otro lado la categoría PROPIEDAD de la figura B es total -señalada con doble
línea- porque todo lote y edificio debe ser miembro de ella. Este caso también se
puede representar como una especialización o generalización. ¿Cúal elegir? Si las
dos clases representan los mismos objetos y comparten numeros atributos, así
como las claves, es preferible la especialización/generalización; en caso contrario,
la categorización es más apropiada.
Hemos extendido el modelo básico ER con los conceptos de subclase, vínculo
clase/subclase, especialización, generalización y categorización. El resultado de esto
lo llamamos MERE. Ahora formalizaremos estos conceptos.

Una clase es un conjunto de ocurrencias, una subclase S es una clase cuyas
ocurrencias siempre deben ser un subconjunto de las ocurrencias de otra clase,
llamada la superclase C del vínculo supeclase/subclase ó es-un. Para un
vínculo superclase/subclase como éste debe cumplirse que S esté incluído en C .

Una especialización Z = {s1,s2,…,sn } es un conjunto de subclases que tienen la
misma superclase G; estos es, G/Si es un vínculo superclase/subclase para i =
1,2,…,n. Se dice que G es un tipo de entidad generalizado (o la superclase de la
especialización, o una generalización de las subclases {s 1,s2,…,sn}).

Se dice que Z es total si siempre se cumple que : USi = G , i = 1,.. n, de lo
contrario se dice que Z es parcial.

Se dice que Z es disjunta si siempre se cumple que: Si intersección Sj es vacía para
i .ne. j. En caso contrario, se dice que Z es traslapada.

Se dice que una subclase S de C está definida por predicado si se usa un
predicado p sobre los atributos de C para especificar cúales ocurrencias de C son
miembros de S; esto es, S = C[p], donde C[p] es el conjunto de ocurrencias de C
que satisfacen p. Una subclase que no está definida por un predicado se denomina
definida por el usuario.

Se dice que una especialización Z (ó generalización G) está definida por atributo
si se usa un predicado (A = ci), donde A es un atributo de G y ci es un valor
constante del dominio de A, para especificar la pertenencia a cada subclase Si de Z.
Cabe señalar que, si ci .ne. cj, para i .ne. j, y A es un atributo monovaluado, la
especialización es disjunta.

Una categoría T es una clase que es un subconjunto de la unión de n superclases
definidoras D1, D2,…Dn, con n > 1, y se especifica formalmente como sigue : T
subconjunto de (D1U D2U…U Dn).

Se puede usar un predicado pi sobre los atributos de Di para especificar los
miembros de cada Di que son miembros de T. Si se especifica un predicado sobre
cada Di , tenemos:

                             T = (D1[p1]U D2[p2]U…U Dn[pn]).

Hay varias opciones para transformar varias subclases que juntas constituyen una
especialización ( o bién que se generalizan para originar una superclase), como las
subclases de EMPLEADO {SECRETARIA, TECNICO, INGENIERO}. Al ya estudiado
mecanismo de migración podemos agregar un paso más. Usaremos Atrs(R) para
anotar los atributos de la relación R y CLP(R) para la clave primaria de R.

Algoritmo de migración

Convertir cada especialización con m subclases {s1,s2,…,sn } y superclase
(generalizada) C, donde los atributos de C son {k, a1,...,an} y k es la clave
primaria, en esquemas de relación empleando una de estas cuatro opciones:
1. Crear una relación L para C con atributos Atrs(L) = {k, a1,...,an} y CLP(L) =
   k. Crear una relación Li por cada subclase Si 1<=i<=m, con los atributos
   Atrs(L i)= {k}U{atributos de Si } y CLP(Li) = k.

    Por ejemplo :

                  EMPLEADO(rut,nombre_empleado,apellido,fecha_nac,direccion
                   )
                 SECRETARIA(rut, velocidad_de_tipeo)
                 TECNICO(rut,grado_tecnico)
                 INGENIERO(rut,especialidad)
   Esta opción funciona para cualesquier restriccion sobre la especialización:
    disjunta o traslapada, total o parcial. Observemos que la restricción p<k>(Li)
    Í p<k>(L ) se debe cumplir para cada Li. Esto especifica una dependencia
    de inclusiónLi.k < L.k.
   Las dependencias de inclusión se definen para formalizar las restricciones
    entre relaciones. Por ejemplo, la restricción de integridad referencial no
    puede especificarse como dependencia funcional o multivaluada porque
    relaciona atributos de varias relaciones; pero sí puede especificarse como
    una dependencia de inclusión.
   En términos formales, una dependencia de inclusión R.X<S.Y entre dos
    conjuntos de atributos -X del esquema R, Y del esquema S- especifica la
    restricción de que si r es un estado de relación de R y s es un estado de
    relacion de S, debe cumplirse: Pi<x>(r) este incliuído en Pi<Y>(s).
   Elvìnculo inclusión no tiene que ser un subconjunto propio. Por supuesto,
    que los conjuntos de atributos sobre los cuales se especifica la dependencia
    de inclusión X de R e Y de S, deben tener el mismo número de atributos.
    Además, los dominios de atributos correspondientes deben ser compatibles.
    Por ejemplo: si X = {A1,A2,..An} e Y = {B1,B2,..Bn}, una posible
    correspondencia es que DOM(Ai) sea compatible con DOM(Bi) para
    1<=i<=n. En este caso decimos que Ai se corresponde con Bi.
   Consideremos el siguiente esquema:
        o EMPLEADO(nombre.rut, fechanac, direccion,nrodepto)
        o DEPARTAMENTO(nomdepto,nrodepto)
        o PROYECTO(nombre,nroproy, presupuesto)
        o trabaja_en( rut,nroproy, horas)

    Podemos especificar las siguientes dependencias de inclusión:

        o   trabaja_en.rut < empleado.rut
        o   empleado.nrodepto< departamento.nrodepto
        o   trabaja_en.nroproy < proyecto.nroproy

2. Crear una relación Li por cada subclase Si, 1<=i<=n, con los atributos
   Atrs(Li)= {atributos de Si} U {k, a1,...,an} y CLP(Li)=k.

    Por ejemplo:

        o   VEHICULO(nropatente,precio,velocimax, nropasaj)
        o   CAMION(nropatente,precio,nroejes,tonelaje)

3. Crear una sola relación L con atributos Atrs(L)={k, a1,...,an} U {atributos
    de Si} U..U {atributos de Sm} U {t} y CLP(L)=k.

    Esta opción es para una especialización cuyas subclases son disjuntas, y t es
    un atributo de tipo que indica la subclase a la que pertenece cada tupla,
    si la hay. Esta opción tiene el potencial de crear un gran número de valores
    nulos. Ejemplo :

    EMPLEADO(rut,nombre_empleado, apellido,fecha_nac,
    direccion,tipo_trabajo,velocidad tipeo, grado tecnico, especialidad)

   Crear un solo esquema de relación L con atributos ATRS(L) = {k,a 1,..,an} U
    {atributos de S1}U..U{atributos de Sm} U {t1,t2,..tm } y CLP(L)=k. Esta
    opción es para una especialización cuyas subclases se traslapan –no son
    disjuntas- y cada ti , 1<=i<=m, es un atributo booleano que indica si una
    tupla pertenece o no a una subclase Si. Por ejemplo :
    Componente(nro,descripción, señalF, fecha_fab, nro_lote, señalC ,
    proveedor, precio) Las dos últimas opciones crean una sóla relación para
    representar la superclase C y todas sus subclases. Una entidad que no
    pertenezca a alguna de las subclases tendrá valores nulos para los atributos
    específicos de esas subclases. Por esto, las opciones mencionadas no se
    recomiendan si se han definido muchos atributos específicos para las
    subclases. Sin embargo, si hay pocos atributos específicos, estas opciones
    son preferibles a las opciones a y b porque hacen innecesario especificar
    operaciones de equirreunión y unión externa
        o EQUIRREUNION consideran como único criterio de reunión la
           igualdad.
        o UNION EXTERNA –creada para efectuar la unión de tuplas de dos
           relaciones que no son compatibles con la unión, es decir efectuará la
           unión de dos relaciones parcialmente compatibles lo que significa que
           sólo algunos atributos son compatibles para la unión. En el resultado
           se conservan los atributos no compatibles de cualquiera de las
           relaciones, y las tuplas que no tienen valores para dichos atributos se
           rellenan con valores nulos-

          Dados:

                  ESTUDIANTE(nombre, rut, carrera, nivel)
                  PROFESOR(nombre, rut, carrera, grado).
                  El esquema resultante es R(nombre, rut, carrera, nivel,
                   grado),
                  donde las tuplas de estudiante tendrán nulo el atributo grado
                   y las tuplas de profesor el atributo nivel.

    y por tanto pueden producir una implementación más eficiente.

    La opción c sirve para manejar clases disjuntas mediante la inclusión de un
    solo atributo de tipo t para indicar la subclase a la que cada tupla pertenece;
    así, el dominio de t podría ser {1,2..,m}. Si la especialización es parcial, t
    puede tener valores nulos en las tuplas que no pertenezcan a ninguna
    subclase. Si la especialización está definida por atributo, ese atributo hará
    las funciones de t y éste no será necesario.

    Con la opción d se manejan subclases traslapadas mediante la inclusión de
    m campos de tipo booleanos, uno para cada subclase. Cada campo de tipo ti
    puede tener un dominio {sí,no}, donde un valor de sí indica que la tupla es
    miembro de la subclase Si. En el ejemplo, los atributos señalF y señalC
    cumplen ese cometido.

    Cuando tenemos una jerarquía o retícula de especialización –ó
    generalización- de múltiples niveles, no tenemos que seguir la misma opción
de transformación para todas las especializaciones; podemos usar una
opción para una parte de ella y otras opciones para el resto. Utilicemos la
retícula definida anteriomente y veamos una alternativa de transformación,
usando diferentes estrategias.

   o   PERSONA(rut,nombre,sexo,direccion,fechanac)
   o   EMPLEADO(rut, sueldo, tipoempleado, puesto, jerarquía, nro_horas, señalAI,señalAD,
       proyecto, curso)
   o   EXALUMNO(rut)
   o   GRADOSEXALUMNO(rut,añograduación, carrera, grado)
       ESTUDIANTE(rut,departamento,carrera,señalPost,señalLic,programa,especialidad,señalAyud
       ante)


Una subclase compartida como GERENTE INGENIERIA, es una subclase de
varias superclases, que deben tener el mismo atributo clave, de lo contrario,
la subclase se modelaría como una categoría. Podemos aplicar cualquiera de
las opciones analizadas a una subclase compartida, aunque por lo regular se
utiliza la opción a. Para transformar la subclase compartida AYUDANTE,
utilizamos la opción d.

Una categoría es una subclase de la unión de dos o más superclases que
pueden tener diferentes claves porque pueden ser de distintas
entidades. DUEÑO es un ejemplo de categoría que proviene de subclases
con claves diferentes y VEHICULO REGISTRADO de subclases son la misma
clave, son ejemplos que hemos visto.

Para establecer la transformación de una categoría cuyas superclases tiene
distintas claves, se acostumbra a especificar un nuevo atributo clave,
llamado clave sustituta . Esto se hace porque las claves de las clases de
definición son distintas y no es posible usar ninguna de ellas
exclusivamente para identificar todas las ocurrencias de la categoría.

Ahora podemos crear un esquema para la categoría DUEÑO, siendo su clave
primaria, la clave sustituta idDueño, agregándola también como clave
externa a cada relación que corresponda a una superclase de la categoría,
para especificar las correspondencias en valores entre la clave sustituta y la
clave de cada superclase.

En aquellas categorías cuyas superclases tengan la misma clave, no hay
necesidad de una clave sustituta.

   o   PERSONA(rut, nro licencia, nombre_persona, direccion, iddueño)
   o   BANCO( nombre Banco,direccion banco,iddueño)
   o   COMPAÑIA( nombre compañía, direccion compañia, iddueño)
   o   DUEÑO(iddueño)
   o   VEHICULO REGISTRADO( nro patente)
   o   VEHICULO( nro patente, marca,modelo.año,nro motor)




Conceptos de abstracción de datos y de representación del
conocimiento

La terminología se usa tanto en el modelado de datos conceptual como en la
literatura de inteligencia artificial cuando se habla de la representación de
conocimientos, (RC ) cuyo objetivo es desarrollar conceptos para modelar
con exactitud algún dominio de discurso y así almacenar y manipular
conocimientos para deducir inferencias, tomar decisiones o simplemente
responder preguntas. Los objetivos de la RC son similares a los de los
modelos semánticos de los datos, pero también hay algunas diferencias
importantes entre las dos disciplinas.

   o   Ambas disciplinas emplean un proceso de abstracción para identificar
       propiedades comunes y aspectos importantes de objetos del
       minimundo, al tiempo que suprimen diferencias insignificantes y
       detalles sin importancia.
   o   Ambas disciplinas cuentan con conceptos, restricciones, operaciones
       y lenguajes para definir datos y representar conocimientos.
   o   La RC tiene en general un alcance más amplio que los modelos
       semánticos de los datos. En los esquemas de RC se representan
       diferentes formas de conocimientos, como reglas (empleadas para
       inferir, deducir y buscar), conocimientos incompletos y por omisión, y
       conocimiento temporales y espaciales. Los modelos semánticos de los
       datos se están, expandiendo para incluir algunos de estos conceptos.
   o   Los esquemas RC cuentan con mecanismos de razonamiento que
       deducen hechos adicionales a partir de los hechos almacenados en
       una base de datos. Así pues, mientras que la mayoría de los sistemas
       de bases de datos actuales están limitados a contestar consultas
       directas, los sistemas basados en conocimientos que utilizan
       esquemas de RC pueden contestar consultas que impliquen
       inferencias sobre los datos almacenados. Por ello existen
       extensiones de la tecnología de bases de datos que incluyen
       mecanismos de inferencia.
   o   En tanto que la mayoría de los modelos de datos se concentran en la
       representación de esquemas de BD, o metaconocimientos, los
       esquemas de RC a menudo combinan los esquemas con las
       ocurrencias mismas a fin de lograr flexibilidad en la representación
       de excepciones. Con frecuencia, esto provoca ineficiencias cuando se
       implementan dichos esquemas de RC, en comparación con las BD,
       sobre todo cuando es preciso almacenar una gran cantidad de datos
       o hechos.

El proceso de clasificación implica asignar sistemáticamente objetos
similares a clases de objetos. Ahora podemos describir (en BD) o razonar
(en RC) sobre la clases más que sobre los objetos individuales mismos. Los
grupos de objetos comparten los mismos tipos de atributos y restricciones, y
al clasificar los objetos simplificamos el proceso de descubrir sus
propiedades.

La generación de ejemplares es el inverso de la clasificación y se refiere a
la producción y examen específico de los objetos distintos de una clase. Así,
un ejemplar de objeto está relacionado con su clase mediante el vínculo
ES_UN EJEMPLAR_DE.

En general, los objetos de una clase deben tener una estructura de tipo
similar, sin embargo algunos de ellos pueden exhibir propiedades que
difieran en algunos aspectos de los demás; estos objetos llamados objetos
de excepción también se tienen que modelar,y los esquemas RC permiten
excepciones más variadas que los modelos semánticos de los datos. Aún
más, ciertas propiedades se aplican a la clase como un todo y no a los
objetos individuales mismos; los esquemas de RC permiten semejantes
propiedades de clase.
En el MERE, las entidades se clasifican en tipos de entidades según sus
propiedades y estructuras básicas. Las entidades se clasifican también en
subclases y categorías dependiendo de las similitudes y diferencias
adicionales entre ellas.

Los MRC permiten múltiples esquemas de clasificación en los que una clase
es una ocurrencia de otra (llamada metaclase ). Cabe señalar que esto no
se puede representar directamente en el MER, porque sólo tenemos dos
niveles: clase y ocurrencias. El único vínculo de clases en el MERE es un
vínculo superclase/subclase, mientras que en algunos esquemas de RC se
pueden representar un vínculo adicional clase/ocurrencia directamente en
una jerarquía de clases. Una ocurrencia puede ser en sí otra clase, lo que
hace posible esquemas de clasificación de múltiples niveles.

La identificación es el proceso de abstracción mediante el cual las clases y
los objetos se hacen identificables de manera única por medio de algún
identificador . Por ejemplo un nombre de clase identifica de manera única
toda una clase. Se requiere de un mecanismo adicional para distinguir los
diferentes ejemplares de objetos mediante identificadores de objetos.
Además, es preciso identificar múltiples manifestaciones en la BD del mismo
objeto del mundo real. Por ejemplo podríamos tener una tupla <Luis Pérez,
5.123.456-7,234112> en una relación PERSONA y otra tupla <402, CC,
3.8>en una relación ESTUDIANTE que casualmente representa la misma
entidad del mundo real. No hay manera de identificar el hecho de que estos
dos objetos de la BD representan la misma entidad del mundo real, si no
tomamos medidas durante el diseño para efectuar referencias cruzadas
apropiadas que proporcionen dicha identificación. Así entonces, la
identificación es necesaria en dos niveles:

   o   para distinguir entre los objetos y las clases de la BD
   o   para identificar los objetos de la BD y relacionarlos con sus
       contrapartes del mundo real.

En el MERE, la identificación de los elementos de un esquema se basa en un
sistema de nombre únicos para los mismos. Por ejemplo, todas la clases de
un esquema MERE, sean entidades, subclases, categorías o tipos de
vínculos, deben tener un nombre distinto. Los nombres de los atributos de
una clase deben ser también distintos. Además, se requieren reglas para
identificar de manera no ambigua las referencias a los nombres de atributos
en una retícula o jerarquía de especialización o generalización.

En el nivel de objetos, los valores de los atributos clave sirven para
distinguir entre las entidades de un tipo dado. En el caso de las entidades
débiles, las entidades se identifican con una combinación de los valores de
su propia clave parcial más la de las entidades con las que están
relacionadas.

La especialización es el proceso por el que se clasifica aún más una clase
de objetos en subclases ,más especializadas. La generalización es el proceso
inverso por el que se generalizan varias clases para obtener una clase
abstracta de más alto nivel que incluya los objetos de todas estas clases. La
especialización es refinación conceptual, y la generalización es síntesis
conceptual. En el MERE la especialización y la generalización se representan
con subclases. Al vínculo entre una subclase y su superclase lo llamamos
vínculo ES_UNA_SUBCLASE_DE .
La agregación es un concepto de abstracción para construir objetos
compuestos a partir de sus objetos componentes. Hay dos casos en los que
es posible relacionar este concepto con el MERE.

   o   El primero, es la situación en la que agregamos valores de atributos
       de un objeto para formar el objeto completo.
   o   El segundo caso, que no contempla explícitamente el MERE, implica
       la posibilidad de combinar objetos que se relacionen mediante una
       ocurrencia de vínculo específico para formar un objeto agregado de
       más alto nivel. En ocasiones esto es útil cuando el propio objeto
       agregado de más alto nivel se debe relacionar con otro objeto.

Al vínculo entre los objetos primitivos y su objeto agregado se le llama
vínculo ES_PARTE_DE, y al inverso se le denomina ES_UN
COMPONENTE_DE.

La abstracción de asociación sirve para asociar objetos de varias clases
independientes; por tanto, es similar a la segunda aplicación de la
agregación. Se representa en el MERE mediante un vínculo, denominado
ESTA_ASOCIADO_A.




La figura anterior identifica un tipo de vínculo entrevista.




La figura anterior muestra la inclusión de OFERTA_EMPLEO en un tipo de
vínculo ternario. Es incorrecto porque requiere que cada ocurrencia de
entrevista tenga una oferta de empleo.
La figura anterior muestra la inclusión de OFERTA_EMPLEO creando un
vínculo en el que otro vínculo participa. No es permitido, el MERE no permite
vínculos entre vínculos.




Una solución es creau una clase agregada de más alto nivel formada por
COMPAÑIA, ENTREVISTA ySOLICITANTE_EMPLEO y en relacionar esta clase
con OFERTA. El MERE no cuenta con este recurso, pero algunos modelos
semánticos sí lo permiten, y al objeto resultante lo denominan objeto
compuesto molecular

Para resolver correctamente el problema necesitamos crear una entidad
débil ENTREVISTA y relacionarlo con OFERTA_DE_EMPLEO
La diferencia principal entre agregación y asociación es que, cuando se
elimina una ocurrencia de asociación, los objetos participantes siguen
existiendo. Sin embargo, si manejamos la noción de objeto agregado, por
ejemplo VEHICULO, que se compone de los objetos MOTOR, CHASIS y
RUEDAS, entonces, la eliminación del objeto agregado equivale a eliminar
sus objetos componentes.

Una BD almacena información sobre alguna parte del mundo real, a la que
denominamos universo de discurso. Ciertas reglas, las restricciones de
integridad , gobiernan este minimundo, y nosotros las conocimos con el
nombre de reglas del negocio. Es nuestra responsabilidad identificar estas
restricciones.

Las restricciones de dominio son restricciones sobre los tipos de valores que
puede tener un atributo, que se especifican a través de un tipo de datos. Las
definiicones de los tipos de datos en los sistemas de BD son objeto de
constante expansión e modo que reflejen algo más del significado asociado a
los valores de los datos. Ya es común en los sistemas orientados a objetos
definir el conjunto apropiado de operaciones asociadas a cada tipo de datos.
Algunos tipos de datos que suelen incluirse en los SGBD son:

                            Tipos   de   datos   numéricos
                            Tipos   de   datos   de caracteres y de cadenas
                            Tipos   de   datos   booleanos
                            Tipos   de   datos   enumerados
                            Tipos   de   datos   fechas y hora
                            Tipos   de   datos   definidos por el usuario

La restricción de clave es una de las restricciones estándar que con
frecuencia aparecen en las aplicaciones de BD. Un tipo de entidad normal
puede tener una o más claves; una entidad débil no tiene clave, pero casi
siempre tiene una clave parcial cuyos valores identifican de manera única las
entidades débiles que están relacionadas a la misma entidad propietario a
través de un vínculo identificador. Las subclases heredan la clave de su
superclase.

Las cardinalidades especifican si una entidad puede participar sólo en una
ocurrencia de vínculo o en varios.

La restricción de participación especifica si una entidad debe participar en
una ocurrencia de vínculo o si puede existir de manera independiente ya sea
que esté relacionada o no con otra entidad. Lo primero se llama
participación total o dependencia de existencia y lo segundo se
denomina participación parcial.

En el modelo relacional los vínculos se representan mediante claves
externas. En SQL podemos especificar el comportamiento de cada clave
externa, cuando la clave primaria referida se actualiza o elimina, con una de
las opciones REJECT, PROPAGATE, SET TO NULL, SET TO DEFAULT.

Muchas restricciones se pueden especificar como restricciones claves y
vínculos, sin embargo hay otras más complejas, conocidas como
restricciones de integridad semántica, que los gestores de BD
comerciales todavía están refinando. En general, se han propuesto dos
estrategias para especificar estas restricciones : la estrategia por
procedimientos y la declarativa.

Este método consiste en escribir instrucciones que verifiquen las
restricciones en las transacciones.

Por ejemplo, consideremos la restricción general que " un empleado no
puede tener un sueldo mayor que el del gerente del departamento al
cual pertenece dicho empleado".

Para asegurar una imposición correcta, esta restricción debe verificarse en
cada transacción de actualización que pudiera violar la restricción. Esta
técnica la utilizan muchos gestores en la actualidad, y también SGBDOO que
pueden codificar restricciones explícitas como parte de los métodos que se
encapsulan con los objetos.

Esta estrategia es completamente general, ya que las verificaciones se
programan en un lenguaje de programación de propósito general, con todas
las consecuencias que eso conlleva. Una omisión, malentendido o error por
parte del programador puede dejar la base de datos en un estado
inconsistente.

Otra desventaja, es que las restricciones pueden modificarse con el tiempo,
al cambiar las reglas de negocios. Si eso sucede el administrador debe
ordenar a los programadores apropiados que recodifiquen todas las
transacciones y operaciones afectadas por la alteración, generándose una
probable fuente de errores.

Una técnica más formal la constituye la alternativa de utilizar un lenguaje de
especificación de restricciones, que suele basarse en una variante del cálculo
relacional. Este enfoque declarativo establece una separación clara entre
la base de restricciones y el subsistema de control de la integridad del
SGBD.

Cuando se usa esta técnica, las restricciones suelen llamarse aserciones .
Su uso ha sido sugerido para SBGD relacionales, de modo que el subsistema
de control de integridad las tome del catálogo para imponerlas
automáticamente. Esta estrategia es muy atractiva desde el punto de vista
de los usuarios y programadores, por su flexibilidad. Desafortunadamente,
se ha demostrado que esta técnica es muy difícil de implementar con
eficiencia, porque los subsistemas de control de la integridad han resultado
ser muy complejos.
Las investigaciones para hacer más eficiente este enfoque continúan:
incluyen el empleo de sistemas de reglas, bases de datos deductivas y bases
de datos activas- aplicaciones restringidas por el tiempo, donde es
preciso vigilar la ocurrencia de condiciones basadas sobre el estado
de la BD, y en caso de ocurrir, invocar acciones específicas-

Cada modelo de datos tiene un conjunto de restricciones asociadas a los
elementos del modelo de datos, que llamamos inherentes , y no es preciso
especificarlas en el LDD -por ejemplo, en el MER toda ocurrencia de vínculo
de un tipo de vínculo n-ario relaciona exactamente una entidad de cada tipo
de entidades que participa en la asociación-.

Las restricciones implícitas, se especifican mediante LDD, durante el
proceso de creación del esquema.El compilador de LDD interpreta y
almacena estas restricciones en el catálogo para que el software de
aplicación pueda imponerlas automáticamente cada vez que se realice una
transacción.

Sin embargo, ningún software es capaz de representar todos los tipos de
restricciones que pueden ocurrir en el universo del discurso, por tanto hay
que definirlas en forma explícita. Las restricciones generales de integridad
semántica caen en esta situación y los programadores especifican estas
restricciones ya sea por procedimientos cuando implementan las
transacciones de la BD o declarativamente por medio de un lenguaje de
especificación de aserciones.

Otra clasificación de las restricciones, depende de si se hace referencia a un
solo estado de la BD o a múltiples estados. Una restricción de estado es
una restricción que vale para todos los estados no transitorios de la BD, esto
es, todos los estados en los que la BD no está en proceso de actualizarse.

Las restricciones de estado deben verificarse siempre que una transacción
de actualización modifique el estado de la BD. Una transacción debe incluir
verificaciones suficientes para garantizar que, si el estado de la BD es
consistente antes de ejecutarse la transacción, su estado también será
consistente después de su ejecución.

Otro tipo de restricciones se aplica a múltiples estados de la BD y se
denomina restricción de transición. Esta es una restricción sobre la
transición de un estado a otro, no sobre un estado individual. Por ejemplo,
el atributo sueldo_base sólo se puede aumentar; esto significa que cualquier
actualización se aceptará sólo si el nuevo valor es mayor que el anterior.

Debe señalarse     que la restricción no se aplica al estado de la BD antes de la
actualización ni   a su estado después de la actualización; se especifica sobre
la transición de   estados y abarca los valores de los atributos tanto antes
como después       de la transacción.

Según vimos el semestre anterior, hay dos partes en el proceso de diseño
de BD. Hasta ahora nos hemos concentrado en el diseño conceptual de los
requerimientos, pero como sabemos, se debe desarrollar también los
aspectos relativos al procesamiento. Primero veremos 8 operaciones básicas
para especificar actualizaciones en el MERE y luego veremos como se
pueden especificar transacciones usando estas operaciones.
   o   insertar_E nombre-entidad atributos nombre_de_atributo <-
       valor,...
   o   eliminar_E nombre-entidad donde condición
   o   añadir_V nombre-vínculo donde nombre-entidad: condición,...
       atributos nombre_de_atributo <- valor,...
   o   quitar_V nombre-vínculo donde nombre-entidad : condición,...
   o   modificar_E nombre-entidad donde condición ... atributos
       nombre_de_atributo <- valor,...
   o   añadir_C nombre_subclase ó categoría de nombre-superclase
       donde condición atributos nombre_de_atributo <- valor,...
   o   quitar_C nombre_subclase ó categoría donde condición

Un valor puede ser un valor constante del dominio o un parámetro que
contiene un valor.

Condición especifica un predicado que selecciona una o más entidades o
clase. Ejemplos:

   o   insertar_E Proyecto atributos Nombre <-"producto A", Número <-
       9, Lugar<- "Arica";
   o   eliminar_E proyecto donde (Nombre= "ProductoA");
   o   añadir_V Trabaja_en donde Proyecto:(Nombre ="ProductoA"),
       Empleado:(Rut="2.344.567-6") atributos horas<-20;
   o   quitar_V Trabaja_en donde Proyecto:(Nombre ="ProductoA"),
       Empleado:(Rut="2.344.567-6");
   o   modificar_E Trabaja_en donde Proyecto:(Nombre ="ProductoA"),
       Empleado:(Rut="2.344.567-6") atributos horas<-40;

Observemos que los ejemplares de vínculos se identifican especificando una
condición sobre cada una se las entidades que participan en el vínculo. Si
cualquiera de estas condiciones especifica más de una entidad, más de un
ejemplar de vínculo resultará afectado por la orden. Por ejemplo :

       quitar_V Trabaja_en donde PROYECTO:(Lugar = "ARICA"),
       EMPLEADO :(SUELDO > 50000);

especifica la eliminación de todos los ejemplares de vínculos que relacionen
cualquier empleado cuyo sueldo sea > que 50000 con cualquier proyecto
ubicado en ARICA.

Si no se es más explícito, se seleccionarán todas las ocurrencias. Por
ejemplo, la operación

quitar_V Trabaja_en donde PROYECTO:(Nombre = "Producto A"),

especificaría la eliminación de todos los ejemplares de vínculos que
relacionen cualquier EMPLEADO con la entidad proyecto especificada.

Estas operaciones básicas de actualización se pueden combinar para
especificar transacciones lógicas de actualización sobre un esquema
determinado durante el diseño de la BD. Para ello debemos definir un
nombre para la transacción, parámetros, y un código que incluya las
operaciones de BD requeridas.
DEFINIR TRANSACCION
contratar_empleado
PARAMETROS rut, nom, fechanac, sexo, sueldo, dir, depto, nombre
_director, nrosuper INICIAR_TRANS

       insertar_E Empleado atributos rut <-rut, nombre<-nom, f_nac<-
       fechanac, sexo<-sexo, sueldo<-sueldo, direccion<-
       dir;                                                anadir_V
       Pertenece_A donde EMPLEADO:(rut=rut ), DEPARTAMENTO:(nombre
       =
       nombre_director)
                   anadir_V Supervision donde
       EMPLEADO.supervisor:(rut=nrosuper),EMPLEADO.supervisado:(rut=r
       ut);

FIN-TRANS;




Consideremos el esquema Universidad y la transacción contratación de un
nuevo profesor.

DEFINIR TRANSACCION contratar_profesor

 PARAMETROS rut, nom, fechanac, sexo, sueldo, rango, oficina,fono,
nombre _depto INICIAR_TRANS

 insertar_E Persona atributos rut <-rut, nombre<-nom, f_nac<-fechanac,
sexo<-sexo, direccion<-dir;

anadir_C Profesor de Persona

donde rut=rut atributos

rango=rango, sueldo=sueldo, oficina=oficina, telefono=fono,

anadir_C Profesor_investigador de Profesor donde rut=rut

anadir_V Pertenece donde

Profesor:(rut=rut),

Departamento: (depto=nombre_depto);

FIN-TRANS;




Observemos que atributos heredados como Rut de profesor pueden servir
para especificar condiciones sobre una subclase.

El proceso de especificar transacciones simples es basante directo, sin
embargo en transacciones más complejas, es necesario utilizar instrucciones
if, case, ciclos, E/S, etc.
Modelo Funcional

Los modelos de datos funcionales (MDF) usan el concepto de función
matemática como elemento de modelamiento. Cualquier solicitud de
información se puede visulizar como una llamada a una función, la cual
retorna la información solicitada.

Las principales primitivas utilizadas son las entidades y los vínculos
funcionales. Hay varios tipos de entidades estándar en elnivel más básico:
string, integer, character, y real entre otras, y se denominan entidades
imprimibles . Los tipos más abstractos, que corresponden a objetos del
mundo real se denominan entity. Hay varias propuestas de modelos de
datos y lenguajes de consulta funcionales, sin embargo el modelo DAPLEX y
su lenguaje son tal vez el ejemplo mejor conocido.

Una especificación similar a la usada por DAPLEX, utilizaremos para
representar la entidades PERSONA, ESTUDIANTE, CURSO, SECCION y
DEPARTAMENTO.

PERSONA() -> ENTITY

ESTUDIANTE()->ENTITY

CURSO()->ENTITY

SECCION() ->ENTITY

DEPARTAMENTO ->ENTITY

Estas especificaciones significan que las funciones mencionadas devuelven
entidades abstractas.

Un tipo de atributo también se especifica como una función cuyo argumento
(dominio) es del tipo de entidades y cuyo resultado (intervalo) es una
entidad imprimible.

rut(PERSONA) ->string

fechanac(PERSONA)->string

sexo(PERSONA)->char

Al aplicar la función rut a una entidad de tipo PERSONA se devuelve el
número de rut de la PERSONA, que es un valor imprimible de tipo string.

Para declar vínculos, le damos un nombre de rol en una dirección y lo
definimos también como función. Así, los vínculos CARRERA y
ESPECIALIDAD se pueden declarar:

CARRERA(ESTUDIANTE)->DEPARTAMENTO
ESPECIALIDAD(ESTUDIANTE)->DEPARTAMENTO

La declaración de un rol inverso, para los mismos vínculos sería :

CARRERA_EN(DEPARTAMENTO) ->> ESTUDIANTE INVERSE OF CARRERA

ESPECIALIDAD_EN(DEPARTAMENTO) ->> ESTUDIANTE INVERSE OF
ESPECIALIDAD

La cláusula INVERSE OF declara que estas funciones son los inversos de las
dos funciones definidas previamente y que por ello especifican los mismos
vínculos que las otras dos, pero en la dirección opuesta.

La doble flecha señala una asociación del tipo 1:n. Esta notación también
puede servir para especificar atributos multivaluados. Las relaciones del tipo
n:m se especifican con flechas dobles en ambas direcciones.

CURSOS_COMPLETADOS(ESTUDIANTE)->>SECCION

estudiantes_que_asistieron(SECCION)->>ESTUDIANTE INVERSE OF
CURSOS_COMPLETADOS

Algunas funciones pueden tener más de un atributo; por ejemplo, el atributo
notas de BOLETA, se describe como:

NOTAS(ESTUDIANTE,SECCION)->char

Observemos que no es preciso declarar un inverso para cada vínculo. Es el
caso de :

DEPARTAMENTO_OFRECE(CURSO) ->DEPARTAMENTO

SECCIONES_DE(CURSO)->>SECCION

El concepto fundamental en MDF es la composición de funciones.

Al escribir

              NOMBRED (DEPARTAMENTO_OFRECE(CURSO))

componemos dos funciones NOMBRED y DEPARTAMENTO_OFRECE. Esto se
denomina expresión de camino y se puede escribir con una notación de
punto alternativa como

              CURSO.DEPARTAMENTO_OFRECE.NOMBRED.

Las funciones NOMBREP(PERSONA) ó NOMBREP(ESTUDIA NTE) se
declaran como composiciones de funciones previamente declaradas:

NOMBREP(NOMBRE)-->STRING

NOMBRE(PERSONA)-->NOMBRE

NOMBREP(PERSONA)-->NOMBREP(NOMBRE(PERSONA))
La composición de funciones es también el principal concepto empleado en
los lenguajes de consulta funcionales. Suponga que se desea obtener los
nombres de todos los estudiantes de COMPUTACION.

RETRIEVE NOMBREP(CARRERA_EN (DEPARTAMENTO))

WHERE NOMBRED(DEPARTAMENTO)="COMPUTACIÓN"

La función inversa CARRERA_EN(DEPARTAMENTO), devuelve entidades
ESTUDIANTE.




Modelo de datos relacional anidado

El modelo relacional anidado elimina la restricción de 1FN del modelo
relacional básico. El modelo resultante se conoce también como modelo
relacional no-1FN o N1FN. En el modelo estándar, también llamado modelo
palno, los atributos deben ser monovaluados y tener dominios atómicos.

El modelo relacional anidado permite atributos compuestos y multivaluados,
lo que conduce a tuplas complejas con una estructura jerárquica, lo cual
resulta útil para objetos con esa característica. La figura siguiente, muestra
el esquema DEPTO que ofrece una tupla N1FN. La definición del esquema es
el siguiente:

DEPTO=(NUMD,NOMBRD,GERENTE,EMPLEADOS, PROYECTOS,
LUGARES)

EMPLEADOS=(NOMBREE,DEPENDIENTES)

PROYECTOS=(NOMBREPR, LUGARP)

LUGARES=(LUGARD)

DEPENDIENTES=(NOMBRED,EDAD)




Primero se definen todos los atributos de la relación DEPTO, luego sus
atributos anidados, -empleados, proyectos y lugares-. A continuación, se
definen atributos anidados de segundo nivel -dependientes, empleados- y
así sucesivamente.

Observemos que los atributos anidados suelen ser atributos multivaluados
compuestos , lo que da pié a una relación anidada dentro de cada tupla. Por
ejemplo, el valor del atributo proyectos dentro de cada tupla DEPTO es una
relación con dos atributos (nombrepr, lugarp), que muestra tres tuplas en la
figura (b).

Un esquema de BD relacional anidado consiste de varios esquemas
externos que definen el nivel superior de las relaciones anidadas
individuales; además los atributos anidados se denominan relaciones
internas porque definen estructuras relacionales que están anidadas dentro
de otra relación.
En nuestro ejemplo, DEPTO es la única relación externa, todas las demás -
empleados, proyectos, lugares- son internas. Por último aparecen atributos
a nivel de hojas y no están anidados. La figura (c) representa el árbol donde
la raíz es la relación externa, las hojas son atributos y los nodos internos son
esquemas de relaciones internas.

Es importante darse cuenta de que las tres relaciones anidadas de primer
nivel de DEPTO representan información independiente. Así, EMPLEADOS
representa a los empledos que pertenecen al departamento, PROYECTOS
representa los proyectos controlados por el departamento y LUGARES
representa las diversas ubicaciones de los departamentos.

El vínculo entre EMPLEADOS y PROYECTOS no se representa en el esquema;
se trata de un vínculo n:m, que es difícil de representar en una estructura
jerárquica.

Dos instrucciones SQL para relaciones anidadas, mostraremos a
continuación. Supongamos que se desea proyectar la relación EMP_PROY,
como sigue :

          EMP_PROY_PLANA <-¨Pirut,nombree,numerop,horas (EMP_PROY)

La versión anidada de esta relación, donde hay una tupla por cada empleado
y (numerop, horas) están anidadas es la siguiente :

         EMP_PROY_ANIDADA<--ANIDAR PROYS =(NUMEROP,HORAS)
                     (EMP_PROY_PLANA)

El efecto de esta operación es crear una relación anidada interna
PROYS=(numerop, horas) dentro de la relación externa
EMP_PROY_ANIDADA.

Así, ANIDAR agrupa las tuplas que tienen el mismo valor para los atributos
que no se especifican en la operación ANIDAR -rut y nombree-

La operación DESANIDAR es la inversa de ANIDAR. Podemos reconvertir
EMP_PROY_ANIDADA a EMP_PROY_PLANA como sigue :

EMP_PRY_PLANA<--DESANIDAR         PROYS =(NUMEROP,HORAS)
(EMP_PROY_ANIDADA).

Acá, el atributo anidado se aplana para dar sus componentes -numerop,
horas-.




Modelo de datos estructural

Representa una extensión del modelo relacional, que utiliza dos tipos de
estructuras:relaciones -similar al modelo plano- y conexiones, clasificadas
en varios tipos para indicar su comportamiento de actualización y sus
conexiones con otras relaciones.
Cada relación en el Modelo Estructural tiene una parte gobernante que
comprende al concepto de clave primaria, seis tipos de relaciones:
primaria, referidas, dependientes, de asociación, de léxico y
subrelaciones y tres tipos de conexiones: propiedad, referencia y
conexión de identidad.

Las relaciones primarias son aquellas a las que no se hace referencia; por
tanto se pueden eliminar tuplas de ellas sin necesidad de verificar
referencias a otras relaciones. En la figura, PROYECTO es la única relación
primaria.

Las relaciones referidas tienen un atributo en alguna otra relación que hace
referencia a su parte gobernante; por tanto correspoden a relaciones a las
que hace referencia una clave externa. Sin embargo, en las relaciones
referidas, el comportamiento de la clave externa es por definición rechazar
en caso de eliminación. Esto significa que si se intenta eliminar una tupla
referida, la eliminación se rechaza a menos que ninguna tupla de la relación
de referencia se refiera realmente a la tupla por eliminar.

En la figura DEPTO y EMPLEADO son relaciones referidas, que se conectan a
sus relaciones de referencia a través de una conexión de referencia , que
se indica con una flecha.

Las relaciones dependientes por lo general corresponden a atributos
multivaluados o entidades débiles en el MER, y suelen representarse con una
relación interna anidada en el modelo relacional anidado. En el modelo
estructural, una relación dependiente es propiedad de otra relación. Por
ejemplo DEPENDIENTE es una relación dependiente propiedad de
EMPLEADO. Una relación dependiente incluye un atributo de clave externa
dentro de su parte gobernante que hace referencia a la relación propietario.

El comportamiento definido para la clave externa es propagar al eliminar, lo
que significa que si se elimina la tupla propietario (referida), las tuplas
dependientes (de referencia) se eliminan automáticamente.

Las relaciones de asociación por lo regular representan vínculos binarios
M:N o n-arios. Su parte gobernante está formada por dos ó más claves
externas, cada una de la cuales hace referencia a una relación propietario.
Las claves externas se definen también con el comportamiento propagar al
eliminar . TRABAJA_EN es una relación de asociación.

La conexiones de propiedad sirven para conectar una relación propietario
con una dependiente, por lo que representa una clave externa desde la
relación poseída al propietario, con semántica de propagar al eliminar. Se
representa con una línea con asterisco en el extremo de la relación
dependiente.

La diferencia principal entre las relaciones dependientes y las de asociación
es que las primeras sólo tienen un propietario, en tanto que una asociación
tiene dos o más propietarios.

Las relaciones de léxico sirven para almacenar correspondencias uno a uno
entre pares de atributos. Por ello, las claves secundarias se pueden pasar a
un léxico si así se desea. LEXICO_DEPTP y LEXICO_PRY ilustran estas
relaciones.
Las relaciones de identidad se usan para representar vínculos
clase/subclase, especialización y generalización. Una conexión de identidad
representa una clave externa -que también es clave primaria- de una
subrelación a otra relación, con semántica de propagar al eliminar.

								
To top