Para trasformar un esquema FuzzyEER con grados de pertenencia de un atributo con respecto a una entidad, el analista puede asignar cardinalidades mínimas 0 a todos aquellos atributos cuyo grado de pertenencia sea menor a 1. Esto es análogo a admitir valores nulos en dichos atributos. Otro criterio puede ser simplemente eliminar del diseño aquellos atributos que posean un grado de pertenencia menor a un umbral definido por el analista (por ejemplo > 0,5). En este caso, la ventaja de tener además del modelo entidad relación el modelo FuzzyEER, es que éste último provee de información adicional, y no se restringe a las limitaciones impuestas por las herramientas de implementación.

Para la transformación de EER-OO se usan los lenguajes:

• Lenguaje ODL
• Lenguaje OML
• Lenguaje OQL

Uso de los objetos complejos estructurados, los no estructurados y la extensibilidad de tipos

Objetos complejos estructurados, no estructurados

Un sistema de BDOO debe poder dar cabida a diferentes tipos de datos, desde los más sencillos a objetos más complejos, todos ellos de pueden resumir en estos ocho:

• Tipo abstracto para construir otros tipos. Permite construir nuevos tipos a partir de caracteres, float, enteros. Por ejemplo: punteros, números complejos, cadenas de bits…
• Array. Son matrices de elementos de datos, como los que podemos encontrar en innumerables aplicaciones científicas.
• Secuencia de tipo: Insertar elementos en una matriz en cualquier posición.
• Tuplas: Forma natural de representar las propiedades de una entidad.
• Conjunto: Forma natural de representar los grupos del mundo real.
• Funciones: Para crear, modificar y borrar otros objetos
• Uniones: Elementos de datos que pueden tomar diferentes valores de los diferentes tipos, es decir, matrices heterogéneas.
• Composición recursiva del resto de tipos, se utiliza para representar objetos complejos, tales como documentos.

Extensibilidad de tipos

El conjunto de tipos predefinidos que aporta el sistema de base de datos debe ser extensible mediante algún mecanismo que permita definir tipos nuevos. No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos.

Ejemplos de SGBDOO (Sistema Gestor de Base de Datos Orientada a Objetos)

1)

2)

las jerarquías de tipos, de clases y herencia.

Jerarquías de tipos y herencia

Un requisito importante en las bases de datos orientadas a objetos es la jerarquía de tipos. Esta es la posibilidad de definir nuevos tipos basándose en otros tipos predefinidos. Para poder definir un tipo, se le asigna un nombre de tipo y sus respectivas funciones, estas incluyen atributos y métodos. Hay casos en el que las funciones de algún tipo están incluidas en las de otro. Es estos casos es conveniente que sea un subtipo, esto quiere decir que hereda las variables del otro tipo, el cual se denomina supertipo. En otras palabras, el subtipo tiene todas las funciones del supertipo y algunas funciones propias adicionales. Los vínculos que se generan al crear estos tipos se llaman vínculos supertipo/subtipo

Jerarquía de clases

Una clase es una colección de objetos que tienen el mismo tipo. Generalmente, se define por un nombre y por la colección de objetos que incluyen. En las clases también es conveniente definir subclases y superclases. Algunos sistemas orientados a objetos tienen una clase predefinida.

La clasificación de las clases es mediante la especialización de objetos, se analizan los objetos y se buscan las semejanzas entre sus atributos. De este modo se logra la jerarquía de clases.

Anteriormente vimos que hay dos tipos de objetos: persistentes y transitorios. Si en una clase tienen objetos transitorios, esta será una clase transitorio. Al contrario, si la clase contiene objetos persistentes, esta es una clase persistente.

Estructuras de objetos, constructores de tipos, encapsulamiento de operaciones, métodos y persistencia.

Base de datos orientados a objetos.

 El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. Puesto que el valor de un dato en un objeto también es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.

Estructura de objetos.

El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto.

Un objeto tiene asociado: 

·  Un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.

·  Un conjunto de mensajes a los que el objeto responde.

·  Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje.

La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos.

Tipos de datos

En el modelo se propone un sistema de tipos consistente en un conjunto de tipos básicos (atómicos) y un conjunto de constructores de tipos.

Tipos básicos (

n2,...nm

Constructores de tipos (

tipos estructurados):

Colecciones:

- array <T,I>

- set <T>

- bag <T>

- list <T>

- dictionary <K,T>

Estructuras:

- struct S {C1 T1, C2 T2, ...Cn Tn}: tupla de estructura {C1 T1, C2 T2, ...Cn Tn}

Encapsulamiento

El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación. 

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

MODELO DE PERSISTENCIA

Un modelo es un conjunto de reglas, conceptos y convenciones que nos permiten describir “algo”. Independientemente del medio de persistencia seleccionado para almacenar los objetos persistentes, se deben realizar un grupo de pasos que permiten completar la semántica de los objetos en aspectos que son importantes.

Los pasos que propone el modelo de persistencia para el diseño de la BD son:

1. Definir las clases persistentes.

La persistencia es la capacidad de un objeto de mantener su valor en el espacio y en el tiempo. Es responsabilidad del diseñador definir cuáles clases son las que deben ser persistentes.

2. Refinar las clases.

El objetivo de este paso es la obtención de la jerarquía de clases y la definición de nuevas clases. No es obligatorio que aparezcan nuevas clases, se recomienda revisar si existe algún comportamiento de interés que no haya sido tomado en cuenta y sea trascendental en la solución del problema, para incluirlo.

3. Clasificar las clases y los atributos.

Clasificar las clases en dependencia de los atributos que la integran y los atributos teniendo en cuenta si son o no afectados por los eventos.

4. Realizar el diagrama de clases.

5. Realizar el diagrama de transición de estado.

6. Obtener las restricciones estáticas y las fórmulas dinámicas.

Especificando textualmente o derivando a partir de los diagramas de clases y transición de estado.

7. Convertir las clases al medio de almacenamiento.

Es en este paso en el que se tiene en cuenta hacía qué lugar se guardarán los objetos.

: secuencia de pares (clave, valor): lista finita de elementos de tipo T: bolsa (multiconjunto) finito de elementos de tipo T: conjunto finito de elementos de tipo T: vector unidimensional de I elementos de tipo T

tipos atómicos): char, string, float, double, boolean, enum N {n1,}, …

Uso de las categorías y la categorización:

En el caso que una subclase tenga mas de una superclase se la llama categoría. Esta es la representación de una clase que es la unión de todas las entidades que se necesita representar.

Una categoría tiene dos o más superclases que representan diferentes tipos de entidades, una entidad que sea miembro de una categoría debe estar por lo menos en algunas de las superclases, pero no necesariamente en todas.

Ej: En una BD que registre vehículos (considerando como tal únicamente coches y camiones), un propietario puede ser una persona, un banco o una compañía. Se define una categoría PROPIETARIOS como una subclase de la UNION de PERSONAS, BANCOS y COMPAÑIAS. VEHÍCULOS REGISTRADOS es una subclase de la UNION de COCHES y CAMIONES.

Modelado de datos con especialización y generalización

Generalización.

La generalización consiste en identificar todos aquellos atributos iguales de un conjunto de entidades para formar una entidad(es) global(es) con dichos atributos semejantes, dicha entidad(es) global(es) quedara a un nivel más alto al de las entidades origen. Es decir que trata de eliminar la redundancia (repetición) de atributos, al englobar los atributos semejantes. La entidad(es) de bajo nivel cuentan (heredan) todos los atributos correspondientes.

Especialización

En un diagrama E-R tanto la generalización como la especialización se representan a través de un triángulo ES-UN (ISA). La generalización se distingue de la especialización mediante arcos dobles entre el triángulo y los subtipos de entidades.

Diferencias entre el modelo ER y el modelo ER extendido (EER)

El Modelo Entidad-Relación Extendido incluye todos los conceptos del Entidad-Relación e incorpora los conceptos de Subclase y Superclase con los conceptos asociados de Especialización y Generalización. Otro nuevo concepto incluido por el ERE es el de Categoría. Asociado a estos conceptos está el importante mecanismo de Herencia de atributos.

MODELADO

1)     SUBCLASE: Grupo de elementos con algo en común, que pertenecen a una ENTIDAD.

2)     SUPERCLASE: Entidad de la que procede una SUBCLASE.

3)     RELACIÓN: Es una relación 1:1 en la que ambos elementos son el mismo. Se suele representar por ES_UN.

4)     Especialización: Es un proceso en el cual se define un conjunto de subclases a partir de un tipo de entidad. Este tipo de entidad de llama superclase de la especialización. Se puede tener varias especializaciones del mismo tipo de entidad, estas se basan en diferentes características.

5)     Retícula de especialización: Es una retícula de especialización cuando una subclase puede ser subclase de varias superclases.

6)     Generalización: Es un proceso en el cual se define superclases, para ello se trata de eliminar las diferencias existentes entre varios tipos de entidades, se busca rasgos comunes y se generaliza para obtener una sola superclase. Las superclases de esta superclase se llaman subclases especiales.

7)     Agregación: La agregación surge de la limitación que existe en el modelado de E-R, al no permitir expresar las relaciones entre relaciones de un modelo E-R en el caso de que una relación X se quiera unir con una entidad cualquiera para formar otra relación.

8)     La Generalización: consiste en agrupar por medio de un rectángulo a la relación (representada por un rombo) junto con las entidades y atributos involucrados en ella, para formar un grupo que es considerado una entidad y ahora sí podemos relacionarla con otra entidad

Diagrama de esquema jerárquico para una base de datos y el lenguaje de manipulación de datos para el modelo jerárquico

Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo dos entidades(binarias ) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo descriptivo en la relación.

La forma de diagramado consta de dos componentes básicos:

   

Celdas: representan a los campos del registro.

   

Líneas: representan a los enlaces entre los registros. 

    Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su representación gráfica se basa en el acomodo de los campos de un  registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos esto de la siguiente manera:

Consideremos  la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos :

Las estructuras de datos según la cardinalidad se representan en los siguientes casos:

Cuando el enlace no tiene atributos descriptivos 

Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

Cuando el enlace tiene atributos descriptivos.

   Consideremos que a la relación cursa le agregamos el atributo Cal (calificación), nuestro modelo E-R quedaría de la siguiente manera:

    La forma de convertir a diagramas de estructura de datos consiste en realizar lo siguiente:

    1. Realizar la representación de los campos del registro agrupándolos

        en sus celdas correspondientes.

    2. Crear nuevo registro, denominado Calif, para este caso, con un

        solo campo, el de cal (calif).

    3. Crear los enlaces indicando la cardinalidad de :

        AluCal, del registro Calif al registro Alumno.

        MatCal, del registro Calif al registro Materia.

    AluCal y MatCal son solo los nombres que emplearemos para

identificar el enlace, pueden ser otros y no son empleados para

otra cosa.

Los diagramas de estructuras de datos según la cardinalidad

se transforman en:

Caso 1. Cardinalidad uno a uno.

Caso 2. Cardinalidad Uno a muchos.

Caso 3. Cardinalidad Muchos a muchos.

    

Diagramas de estructura de datos cuando intervienen

más de dos entidades y el enlace no tiene atributos descriptivos.

  

Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro, quien es el que imparte dicha materia.

   

Nuestro diagrama E-R quedaría de la siguiente manera:

    La transformación a diagramas de estructura de datos se realiza mediante los siguientes pasos:

1.Crear los respectivos registros para cada una de las entidades que intervienen en el modelo.

2. Crear un nuevo tipo de registro que llamaremos Renlace, que puede no tener campos o tener solo uno que contenga un identificador único, el identificador lo proporcionará el sistema y no lo utiliza directamente el programa de  aplicación, a este registro se le denomina también como registro ficticio o de enlace o unión.

    Siguiendo los pasos anteriores nuestra estructura finalmente es: (Considerando una relación con cardinalidad Uno a Uno)

    Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se liga indicando el tipo de cardinalidad de que se trate.

    En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos a la relación el atributo calif. (calificación).

    Considerando el anterior diagrama de estructura de datos, una instancia de este seria:

La estructura quedaría:

Transformación ER-Jerarquico para el diseño de bases de datos

Diagramas de estructura de árbol
Un diagrama de estructura de árbol en el esquema de una base de datos jerárquica. Este tipo de diagrama esta formado por dos componentes básicos:

• Cajas, que corresponden a tipos de registro.
• Líneas, que corresponden a enlaces.

Un diagrama de estructura de árbol tiene el mismo propósito que un diagrama de entidad-relación; a saber, especificar la estructura lógica global de la base de datos. Un diagrama de estructura de árbol es similar a un diagrama de estructura de datos en el modelo de red. La principal diferencia es que en este último los tipos de registro se organizan en forma de grafo arbitrario, mientras que en el primero se organizan en forma de árbol con raíz.
Tenemos que ser más precisos en lo que quiere decir árbol con raíz. En primer lugar, el grafo no puede contener ciclos. En segundo lugar, Las relaciones formadas en el grafo deben ser de tal forma que solo existan relaciones uno a muchos o uno a uno entre un padre y un hijo. La forma general de una estructura de árbol. Nótese que las flechas están apuntando de padres a hijos. Un padre puede tener una flecha apuntando a un hijo, pero un hijo siempre debe tener una flecha apuntando a su padre.
...
...
El esquema de base de datos se representa como una colección de diagramas de estructura de árbol. Para cada diagrama existe una única instancia del árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de este nodo son instancias del tipo de registro adecuado. Cada una de esas instancias de hijo puede tener, a su vez, varias instancias de varios tipos de registro, según se especifica en el diagrama de estructura de árbol correspondiente.
Para comprender como están formados los diagramas de estructura de árbol, veremos como transformar los diagramas de entidad-relación en sus correspondientes diagramas de estructura de árbol. Primero mostraremos como pueden aplicarse estas transformaciones a una sola relación. Después trataremos el tema de cómo asegurar que los diagramas resultantes tengan forma de árboles con raíz.
Relaciones únicas
Las relaciones entre los atributos en la entidad relación, que consta de los dos conjuntos de entidades cliente y cuenta relacionados por medio de la relación binaria uno a muchos CliCta sin atributos descriptores. Este diagrama especifica que un cliente puede tener varias cuentas pero que una cuenta solo puede pertenecer a un cliente. El diagrama de estructura de árbol correspondiente se muestra en la Figura.
El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos: nombre, calle y ciudad. De manera similar, cuenta es el tipo de registro que corresponde al conjunto de entidades cuenta. Incluye dos campos: numero y saldo. Finalmente, la relación CliCta se ha sustituido por el enlace CliCta, con una flecha apuntando a tipo de registro cliente.
Así una instancia de una base de datos que corresponda al esquema que se acaba de Describir puede contener varios registros cliente enlazados a varios registros cuenta, como se muestra en la Figura. Puesto que la relación es uno a muchos de cliente a cuenta, un cliente puede tener más de una cuenta.
Sin embargo, una cuenta no puede pertenecer a más de un cliente, como puede verse en el ejemplo de base de datos. Si la relación CliCta es uno a uno, entonces el enlace CliCta tiene dos flechas, una apuntando al tipo de registro cuenta y otra apuntando al tipo de registro cliente. En la figura aparece un ejemplo en el que la relaciones uno a uno, una cuenta puede pertenecer a exclusivamente a un cliente, y un cliente puede tener exclusivamente una cuenta, como puede verse en el ejemplo de base de datos.
Si la relación CliCta es muchos a muchos, entonces la transformación del diagrama E-R a un diagrama de estructura de árbol es más complicada. Esto se debe a que en el modelo jerárquico solo pueden representarse directamente las relaciones uno a muchos y uno a uno.
Existen varias formas distintas de transformar este diagrama E-R en un diagrama de Estructura de árbol. Sin embargo, todos estos diagramas comparten la propiedad de que el árbol (o árboles) de base de datos tendrá(n) registros repetidos.
La decisión de que método de transformación debe utilizarse depende de muchos factores, entre los que se incluyen:

• El tipo de consultas esperadas en la base de datos.
• El grado al que el esquema global de base de datos que se esta modelando se ajusta al modelo E-R dado.

Si una relación incluye también un atributo descriptivo, la transformación de un diagrama E-R a un diagrama de estructura de árboles mas complicada. Esto se debe a que un enlace no puede contener un valor de un dato. En este caso se necesita crear un nuevo tipo de registro y establecer los enlaces adecuados. La forma de establecer los enlaces dependerá de cómo se defina la relación CliCta.
Si la relación CliCta fuera uno a uno con el atributo fecha, entonces el algoritmo de transformación seria similar al descrito arriba. La única diferencia es que los dos enlaces CliFecha y FechaCta serian uno a uno.
Si la relación CliCta fuera muchos a muchos con el atributo fecha, entonces habría de nuevo varias transformaciones alternativas. Usaremos la transformación más general, similar a la que se aplico en el caso en que la relación CliCta no tenia atributo descriptivo. Los tipos de registro cliente, cuenta y fecha necesitan repetirse y se deben crear dos diagramas de estructura de árbol.


Cliente, Fecha, Cuenta, Cliente, Cuenta, Sucursal 

Considérese el diagrama de entidad-relación de la figura, que consta de tres conjuntos de entidades, cliente, cuenta y sucursal, relacionados mediante el conjunto de relaciones general sin atributo descriptivo. Este diagrama especifica que un cliente puede tener varias cuentas, cada una de las cuales se localiza en una sucursal bancaria especifica, y que una cuenta puede pertenecer a varios clientes distintos.
Existen varias formas de transformar este diagrama E-R en un diagrama de estructura de árbol. De nuevo, todos tienen la propiedad de que el árbol (o árboles) de la base de datos se encuentran registros repetidos. La transformación mas directa es crear dos diagramas de estructura de árbol, como se ilustra en la Figura.
Este algoritmo de transformación puede extenderse de una manera directa para tratar relaciones que abarcan más de tres conjuntos de entidades. Simplemente repetimos los distintos tipos de registros y generamos tantos diagramas de estructura de árbol como sea necesario. Este enfoque, a su vez, puede extenderse para tratar una relación general que tenga algunos atributos descriptivos. Todo lo que hace falta es crear un nuevo tipo de registro con un campo para cada atributo descriptivo, y después insertar ese tipo de registro en el lugar apropiado en el diagrama de estructura de árbol.