PLANTILLA DE ESTADO DEL ARTE

Autor: Dra. Anaisa Hernández González

Title of paper: Un Método para el Diseño de la Base de Datos a partir del Modelo
Orientado a Objetos
Journal:
Volume(issue):
Pag – pag(war): 224 – 238

Estado del arte que hace el autor

La complejidad para producir un software de calidad que abarca un diseño de base de datos en los
diferentes productos y el trabajo consciente y disciplinado en la aplicación de técnicas de ingeniería que
estas requieren han provocado una revolución en los conceptos de la informática siendo el cambio más
importante el del paradigma de la orientación a objetos, impactando en mayor escala en los lenguajes
de programación de alto nivel y en las metodologías de análisis y diseño de sistemas informáticos; ha
hecho que se tomen diferentes puntos de vistas sobre dicho tema, tales como: el punto de vista
estructural o estático hay bastante consenso ya que están definidos los diferentes conceptos de clase,
atributo, relaciones entre clases, herencia y agregación, pero no en su mayoría que validan la inserción
inapropiada de elementos dado que los diagramas que reflejan estas características, no se construyen en
función de su aporte al diseño de la base de datos, ni mucho menos nos dice cómo utilizar la información
que contienen en la etapa de implementación; el otro punto de vista es del metodológico, nos informa
que en el diseño de la base de datos, la mayoría de las metodologías no incluyen un modelo de
persistencia, olvidando de esta manera que los objetos en su definición incluyen el comportamiento, el
modelo relacional y el de cómo diseñar la base de datos, dicho de otra manera estas metodologías
ofrecen poca o ninguna recomendación para construir los modelos y diagramas que incluyen, y resultan
insuficientes en la explicación de cómo transformar la información contenida en los diagramas hacía el
medio de almacenamiento. A partir de esto, se definió como problema de investigación: El desarrollo
de un método, denominado DIBAO (diseño de la base de datos a partir de un modelo orientado a
Objetos) que se base en un formalismo y que garantice: la transformación de la semántica asociada a un
objeto hacía el medio de almacenamiento que se utilice, y conservar en la transformación las principales
características del paradigma de la orientación a objetos.

Motivación del autor

El autor hace la critica que no siempre se tienen en cuenta todas las restricciones estáticas que validan
la inserción inapropiada de elementos desde un punto de vista estructural o estático en el cual hay
aprobación ya que por lo general están definidos los conceptos de clase, atributo, relaciones entre clases,
herencia y agregación, pero no de una manera global. Por otro lado el autor hace mención que el
comportamiento dinámico de los objetos es tomado insuficientemente dado que, aunque se incluyen
casi siempre diagramas que reflejan estas características, no se construyen en función de su aporte al
diseño de la base de datos, ni se define cómo utilizar la información que contienen en la etapa de
implementación. También hace la crítica a las propuestas de metodologías que por lo general comienzan
con una definición de los principales conceptos que caracterizan al enfoque, pero salvo excepciones, se
basan en definiciones informales. Muchos métodos se han introducido sin formalización, sobre el diseño
de la base de datos la mayoría de las metodologías no incluyen un modelo de persistencia. Las
propuestas de metodologías por lo general comienzan con una definición de los principales conceptos
que caracterizan al enfoque, pero salvo excepciones, se basan en definiciones informales. Muchos
métodos se han introducido sin formalización.

Esta situación era lógica si tenemos en cuenta la poca fortaleza de los gestores orientados a objetos. Hay
una tendencia a convertir clases a tablas, pero teniendo en cuenta, y no de forma completa, la parte
estructural. Por lo general olvidan que los objetos en su definición incluyen el comportamiento, y que
el modelo al que se transforma (el modelo relacional) centra su atención en los datos. Además las
metodologías definen por lo general los pasos para construir una aplicación, pero no cómo diseñar la
BD; ofrecen poca o ninguna recomendación para construir los modelos y diagramas que incluyen, y
resultan insuficientes en la explicación de cómo transformar la información contenida en los diagramas
hacía el medio de almacenamiento.

Algunos trabajos muestran una inclinación hacía la definición de una capa de interfaz entre la
información almacenada y la aplicación. A esta capa se le conoce como capa persistente y aísla a las
clases del dominio de la forma en que se almacenó la información.

Descripción del aporte del autor

Las propuestas de metodologías por lo general comienzan con una definición de los principales
conceptos que caracterizan al enfoque, pero salvo excepciones, se basan en definiciones informales.
Muchos métodos se han introducido sin formalización.

La complejidad para producir un software de calidad que abarca un diseño de base de datos en los
diferentes productos que han provocado una revolución en los conceptos de la Informática siendo el
cambio más importante el del paradigma de la orientación a objetos.

La falta de información en los conceptos de clase, atributo, relaciones entre clases, herencia y
agregación, que en su mayoría que no validan la inserción inapropiada de elementos dado que los
diagramas que reflejan estas características, no se construyen en función de su aporte al diseño de la
base de datos, ni mucho menos nos dice cómo utilizar la información que contienen en la etapa de
implementación.

La escases de metodologías en el diseño de la base de datos que no incluyen un modelo de persistencia,

olvidando de esta manera que los objetos en su definición incluyen el comportamiento, el modelo
relacional y el de cómo diseñar la base de datos, dicho de otra manera estas metodologías ofrecen poca
o ninguna recomendación para construir los modelos y diagramas que incluyen, y resultan insuficientes
en la explicación de cómo transformar la información contenida en los diagramas hacía el medio de
almacenamiento.
Las dificultades para almacenar los objetos persistentes, y que no permiten completar la semántica de
los objetos en aspectos que son importantes referentes a su estructura estática y comportamiento
dinámico.
La transformación, la dificultad de conservar la semántica asociada a un objeto hacía el medio de
almacenamiento que se utiliza en la transformación de las principales características del paradigma de
la orientación a objetos.

Proceso para obtener el aporte que considera el autor

MODELO DE PERSISTENCIA
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 referentes a su estructura y comportamiento.
Los pasos que se proponen son:
 1. Definir las clases persistentes, tomando en cuenta que la persistencia es la capacidad de un objeto
de mantener su valor en el espacio y en el tiempo.
2. Clasificar las clases y atributos en simples, compuestas y complejas.
3. Realizar el diagrama de clases persistentes cuya notación para el diagrama de clases toma como
base la del diagrama de clases de UML, añadiendo nuevas características usando estereotipos, la
definición de OO - Method de dimensión estática/dinámica (E/D). Además hay que buscar
patrones comunes que compliquen el diseño físico para darles solución tales como las relaciones
n-arias, de m: n y de 1:1 y la herencia múltiple.
4. Realizar el diagrama de estado para mostrar la dinámica del comportamiento de un sistema y
utilizar los diagramas de transición de estado en función del diseño de la base de datos. El método
DIBAO propone dos criterios para agrupar por niveles. Un criterio está relacionado con los
atributos, de manera que si existen varios eventos que afectan a un mismo atributo ubicando al
objeto en estados diferentes, con todos estos estados podría definirse uno agregado. Otro criterio
sería agrupar a estados que están fuertemente acoplados. Así como también Balancear los
diferentes niveles de diagramas en cuanto a las transiciones de entrada y salida. Así como también
clasificar los atributos dinámicos en 1) Cardinales, identificando los eventos que lo afectan
teniendo en cuenta cuáles aumenta su valor, 2) Característicos de un estado: identificando los
eventos y el efecto que provocan, 3) Perteneciente a una situación, identificando todos los eventos,
el nuevo valor que provocan y el valor del atributo para el cual ese evento tiene sentido.
5. Obtener las restricciones estáticas y las fórmulas dinámicas. El formato general que se propone en
este trabajo para expresar estas restricciones es: <atributo> = <condición>. En la condición hay
que indicar las tablas involucradas y se puede usar NOT, EXIST, funciones de agregación, AND,
OR, IN, BETWEEN. Validando cada vez que se intente cambiar el valor de los atributos a los que
se asocia cada una.
En función del diseño de la BD, se pueden derivar de diferentes formas tales como:
Precondiciones, disparadores, derivación, especificación de métodos.
6. Convertir las clases al medio de almacenamiento conjuntamente con la implementación de la
persistencia para el almacenamiento en ficheros, formar el modelo de objeto de ODMG y convertir
clases a tablas.
CAPA PERSISTENTE
El método DIBAO propone incluir una subcapa de especificación que describa las características de las
relaciones entre los objetos en correspondencia con lo definido en el DC.

Proceso para resolver el problema considerado por el autor

Para la descomposición de diagramas de transición de estado, el método DIBAO propone dos criterios
para agrupar por niveles. Un criterio está relacionado con los atributos, de manera que si existen varios
eventos que afectan a un mismo atributo ubicando al objeto en estados diferentes, con todos estos
estados podría definirse uno agregado. Otro criterio sería agrupar a estados que están fuertemente
acoplados.

Para el resto de estas restricciones estáticas que no sean las de integridad, el método DIBAO sugiere
que se especifiquen textualmente completando para cada atributo de cada clase: si toma valor único, si
puede ser nulo, rango (para el caso de numérico y enumerativo), valor por defecto y fórmula de
derivación (para los atributos derivados).
El método DIBAO propone que la especificación de los mecanismos de disparo debe seguir el siguiente
formato: <causa que lo provoca><tabla>: condición]/<acción> {ANTES/DESPUES}. Donde:
Causa: INSERT-adición DELETE-borrado UPDATE-modificación.
Tabla: Nombre de la tabla o Nombre de la tabla, atributo y valor
Acción: Acciones que se ejecutan como efecto del disparo.
Antes/Después: Momento en que se producen las acciones con relación al cambio que provoca el
disparo.
El modelo de objetos es la base del estándar ODMG en el cual en el método DIBAO las definiciones de
clases, con sus comportamientos estático y dinámico, incluyen totalmente los conceptos de este modelo
y van más allá. Esto último sugiere que con el gestor y lenguaje de programación con que se trabaje
tendrán que implementarse algunas características (por ejemplo, las fórmulas de evaluación, las
restricciones asociadas a las relaciones entre clases).
En la capa de clases persistente, el método DIBAO propone incluir una subcapa de especificación que
describa las características de las relaciones entre los objetos en correspondencia con lo definido en el
DC. Además modifica la estructura de las clases persistentes adicionando métodos que recogen las
restricciones de integridad y las fórmulas dinámicas antes descritas.
Asociadas a las restricciones al dominio de los atributos, la forma en que toman valor los atributos
dinámicos y las fórmulas dinámicas, obtenidas al aplicar el modelo de persistencia del método DIBAO;
es necesario añadir a las clases persistentes lo siguiente:
 Por cada atributo, independientemente de su clasificación, un método que verifique sus
restricciones de dominio
 Un método para cada uno de los algoritmos que le asignan un valor en el caso de que sea un
atributo dinámico.
 Un método que implemente la fórmula de derivación para los atributos derivados.
 Para el caso de los disparadores se definen nuevos métodos (invocados por los métodos de
creación, destrucción o actualización de un objeto en dependencia de lo que indique, como
evento que lo provoca, la especificación del mecanismo de disparo), que verificarán la
condición, en caso de existir, e implementarán las acciones.
En la fase de diseño de la BD, el método DIBAO ha adicionado características a las clases y sus
relaciones que, aunque están relacionadas con el comportamiento de los objetos en el mundo real
(por ejemplo, la dimensión entre compuesta y componente), no son propiedades semánticas como
el color de los ojos o del cabello. La definición de nuevos atributos tiene aparejada la creación de
métodos que los actualicen y garanticen las restricciones a ellos asociadas.

Matrices que autor usa y resultado que obtiene

Para guardar los objetos persistentes que dependen del medio de persistencia seleccionado, considero
yo que además de realizar un grupo de pasos que permiten completar la semántica de los objetos, se
deben realizar comparaciones con otros objetos persistentes y de esta manera definir las clases
persistentes con mayor profundidad.
Al momento de realizar el diagrama de clases persistentes si bien se va añadiendo nuevas características
usando estereotipos, estas características deben de involucrarse entre ellas.
Al momento de realizar el diagrama de estado para mostrar la dinámica del comportamiento de un
sistema lo cual creo yo que favorece el entendimiento de las partes que conforman el sistema, porque
de una manera u otra para entender el sistema es necesario entender las partes y utilizar así los diagramas
de transición de estado en función del diseño de la base de datos.
Al obtener las restricciones estáticas y las fórmulas dinámicas. El formato general que se propone en
este trabajo para expresar estas restricciones es: <atributo> = <condición>. En la condición hay que
indicar las tablas involucradas y se puede usar NOT, EXIST, funciones de agregación, AND, OR, IN,
BETWEEN. Validando cada vez que se intente cambiar el valor de los atributos a los que se asocia cada
una.
Al momento de derivar los diagramas si bien es claro que se pueden hacer de diferentes maneras tales
como: precondiciones, disparadores, derivación, especificación de métodos se pudo agregar una que
comprende algunas o todas estas anteriormente mencionadas.
Cuando se hace mención sobre convertir las clases al medio de almacenamiento conjuntamente con la
implementación de la persistencia para el almacenamiento en ficheros y convertir clases a tablas no solo
se puede convertir las clases a tablas sino también a subclases y estas últimas a tablas.

Observaciones y/o critica suyas al articulo

Mi crítica es lo siguiente: si bien afirma que “existe insuficiencia de información y/o recomendaciones
para la construcción de un diseño de base de datos tales como en la construcción de los modelos y
diagramas que incluyen. Y que para esto es necesario el desarrollo de un método denominado DIBAO
que se basa en un formalismo”.

¿Formalismo?, si bien es bueno aprender los métodos y fórmulas de una escuela; pero no todo es
aprender, el ser humano como sabemos es ingenioso, creativo, etc.; es decir que crea o tiene su propia
solución o los diversos problemas que aqueja, un ejemplo claro sería el de un alumno que no hiso su
tarea y convence al profesor para que no lo castigue. El alumno no aprendió esto de algo o alguien, el
simplemente lo creo en el momento. Dicho de esta forma, el ser humano no se debe basar de forma
completa en la enseñanza que le brindan, si no en el de descubrir nuevos métodos, formulas, etc., para
dar solución a algo, siempre en cuando estas sean correctas.