DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE …
62
ISC-2003-1-25 DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN DIAGRAMA DE CLASES JOSÉ ALEJANDRO MANRIQUE FRAGOSO UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2003
Transcript of DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE …
ISC-2003-1-25
DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE
SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN
DIAGRAMA DE CLASES
JOSÉ ALEJANDRO MANRIQUE FRAGOSO
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ, D.C.
2003
ISC-2003-1-25
iv
DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE
SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN
DIAGRAMA DE CLASES
JOSÉ ALEJANDRO MANRIQUE FRAGOSO
Tesis para optar al título de Ingeniero de Sistemas
Asesora:
ÁNGELA CRISTINA CARRILLO
Ingeniera de Sistemas
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ, D.C.
2003
ISC-2003-1-25
A toda mi familia por todo el apoyo y cariño, y en especial a mis padres que han
procurado darme siempre lo mejor.
Y a Toya por su infinito amor que siempre me ha demostrado.
ISC-2003-1-25
AGRADECIMIENTOS
Deseo agradecer a todas aquellas personas que de una u otra forma me ayudaron para
realizar esta tesis. En especial a Ángela Carrillo, por su guía y orientación en la elaboración
y culminación de este trabajo de grado, y por su infinita paciencia y amabilidad con
nosotros sus estudiantes. A Rodrigo Cardozo, Fernando de la Rosa, Maria del Pilar
Villamil, y a todos los profesores del departamento de Ingeniería de Sistemas, cuyos
aportes a nuestra formación han sido vitales para que seamos unos excelentes profesionales.
ISC-2003-1-25
TABLA DE CONTENIDO
1 OBJETIVOS................................................................................................................... 1
2 ALCANCE ..................................................................................................................... 1
3 PRODUCTO A REALIZAR.......................................................................................... 1
4 PRODUCTOS RELACIONADOS EN EL MERCADO ............................................... 2
4.1 COCOBASE ENTERPRISE O/R [1] ..................................................................... 2
4.1.1 Características Adicionales de CocoBase....................................................... 3
4.1.2 Precio de CocoBase ........................................................................................ 3
4.2 THE VISUAL BUSINESS SIGHT FRAMEWORK [2]........................................ 4
4.2.1 Características ................................................................................................. 5
4.2.2 Precio de VBSF .............................................................................................. 5
4.2.3 Tipos de licencia ............................................................................................. 6
4.3 OBJECT RELATIONAL BRIDGE [3] .................................................................. 8
4.3.1 Características ................................................................................................. 8
4.4 CONCLUSIÓN....................................................................................................... 8
5 MOTIVACIÓN............................................................................................................... 9
6 MODELO DE TRASLACIÓN DE MODELOS ORIENTADOS-OBJETOS A
MODELOS DE DATOS-RELACIONAL ........................................................................... 10
6.1 INTRODUCCIÓN................................................................................................ 10
6.2 DE UML AL MODELO DE DATOS RELACIONAL ...................................... 11
6.2.1 REPRESENTACIÓN LÓGICA DEL DIAGRAMA DE CLASES ............. 12
6.3 REPRESENTACIÓN LÓGICA DEL MODELO DE DATOS RELACIONAL.16
6.3.1 REGLAS DE MANIPULACIÓN DE DIAGRAMAS DE CLASES........... 17
6.3.2 REGLAS DE TRANSPOSICIÓN................................................................ 19
6.3.3 CONCLUSIONES ........................................................................................ 27
7 LEVANTAMIENTO DE REQUERIMIENTOS ......................................................... 27
7.1 HERRAMIENTAS Y DESARROLLO................................................................ 28
7.2 VISUALIZACIÓN ............................................................................................... 28
7.3 INTERACCIÓN ................................................................................................... 29
ISC-2003-1-25
vi
7.4 OPERACIÓN ....................................................................................................... 29
7.5 DESEMPEÑO ...................................................................................................... 30
7.6 COMPATIBILIDAD............................................................................................ 30
7.7 ROBUSTEZ Y RECUPERACIÓN DE ERROR................................................. 32
7.8 MANTENIBILIDAD ........................................................................................... 32
7.9 CONTROL DE ACCESO .................................................................................... 33
8 DEFINICIÓN DE LOS CASOS DE USO ................................................................... 34
8.1 DIAGRAMAS DE CASOS DE USO................................................................... 34
8.2 CASOS DE USO.................................................................................................. 34
8.3 DIAGRAMA DE CLASES DE DISEÑO............................................................ 37
8.4 DIAGRAMAS DE SECUENCIA ........................................................................ 38
8.4.1 Creación del modelo orientado por objetos formal a partir de un diagrama de
clases:............................................................................................................................ 38
8.4.2 Creación del diagrama de datos relacional formal a partir del diagrama orientado
por objetos formal:........................................................................................................ 39
8.4.5 Generación de los scripts de creación de tablas a partir de un modelo de
datos relacional formal: ................................................................................................ 39
9 CONSIDERACIONES PARA EL USO DE LA APLICACIÓN................................. 40
9.1 CONSIDERACIONES INICIALES .................................................................... 40
9.2 CONSIDERACIONES PARA LO SCRIPTS DE CREACIÓN DE TABLAS.... 40
9.3 EJEMPLO DE UTILIZACIÓN DE LA APLICACIÓN...................................... 41
9.4 CONSIDERACIONES PARA FUTUROS DESARROLLOS ............................ 43
10 CONCLUSIONES .................................................................................................... 44
11 BIBLIOGRAFÍA ...................................................................................................... 46
ISC-2003-1-25
vii
LISTA DE TABLAS
TABLA 1. PRECIOS LICENCIA BINARIA VBSF ............................................................. 7
TABLA 2. PRECIOS LICENCIA FUENTE VBSF............................................................... 7
TABLA 3. TABLA COMPARATIVA ENTRE HERRAMIENTAS .................................... 8
TABLA 4. CONSTRUCCIÓN DE REGLAS DE TRANSPOSICIÓN............................... 20
ISC-2003-1-25
viii
LISTA DE FIGURAS
FIGURA 1. EJEMPLO DE UN DIAGRAMA DE CLASES DE UML .............................. 14
FIGURA 2. EJEMPLO DE DIAGRAMA DE CLASES ANTES DE LA
MANIPULACIÓN DE LA REGLA 2. ........................................................................ 18
FIGURA 3. EJEMPLO DE DIAGRAMA DE CLASES DESPUÉS DE LA
MANIPULACIÓN DE LA REGLA 2. ........................................................................ 18
FIGURA 4. EL PROCESO DE INTRODUCIR UNA TABLA ASOCIATIVA ................. 23
FIGURA 6. DIAGRAMA DE CLASE DE DISEÑO. ......................................................... 37
FIGURA 7. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DEL MODELO
ORIENTADO POR OBJETOS. ................................................................................... 38
FIGURA 8. DIAGRAMA DE SECUENCIA DE LA CREACIÓN DEL DIAGRAMA DE
DATOS RELACIONAL FORMAL A PARTIR DEL DIAGRAMA DE ORIENTADO
POR OBJETOS FORMAL. ......................................................................................... 39
FIGURA 9. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DE LOS SCRIPT DE
CREACIÓN DE TABLAS A PARTIR DE UN MODELO DE DATOS
RELACIONAL FORMAL ........................................................................................... 39
FIGURA 10. VENTANA INICIAL DE LA APLICACIÓN. .............................................. 41
FIGURA 11. VENTANA PARA ABRIR EL DIAGRAMA DE CLASES. ........................ 41
FIGURA 12. VENTANA CON EL SCRIPT DE CREACIÓN DE TABLAS..................... 42
FIGURA 13. VENTANA PARA GUARDAR EL SCRIPT DE CREACIÓN DE TABLAS.
...................................................................................................................................... 42
FIGURA 14. DIAGRAMA DE CLASES EJEMPLO.......................................................... 47
ISC-2003-1-25
ix
LISTA DE ANEXOS
ANEXO 1. SECUENCIA DE EJECUCIÓN DE LA APLICACIÓN.................................. 47
ISC-2003-1-25
DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE
SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN
DIAGRAMA DE CLASES
1 OBJETIVOS
w Desarrollar una aplicación que transforme un modelo orientado-objeto a un modelo de
datos relacional.
w Generar a partir del modelo de datos relacional los scripts necesarios para la creación de
una base de datos en un Sistema Manejador de Bases de Datos Oracle 8i.
2 ALCANCE
Desarrollar una aplicación que tome un modelo orientado por objetos generado por DIA
v9.01, lo traslade a un modelo de datos relacional y a partir de este modelo, crear un script
de generación de tablas a una base de datos Oracle8i.
3 PRODUCTO A REALIZAR
Al final de este trabajo se espera tener un producto, que permita mejorar el desempeño en la
construcción de aplicaciones, mediante la traslación automática de un modelo orientado a
objetos a un modelo de datos relacional, debido a que muchas de las aplicaciones que se
desarrollan en la actualidad tienden a crearse bajo la programación por objetos y la
1 DIA v9.0, es un programa especializado en la graficación de diagramas estructurados. DIA es un software con licencia GNU. http://www.lysator.liu.se/~alla/dia/dia.html
ISC-2003-1-25
2
persistencia se realiza bajo bases de datos relacionales basadas en un modelo de datos
relacional.
La aplicación tendrá una interfaz gráfica que permitirá al usuario abrir un modelo orientado
a objetos (diagrama de clases en UML) creado en Dia v 0.90 o anteriores. Luego la
aplicación procederá a procesar el diagrama de clases y trasladarlo a un modelo orientado
por objeto formal, y a su vez realizar la traslación a un modelo de datos relacional.
Finalmente la aplicación creará un Script de creación de tablas a partir del modelo de datos
relacional, mostrando el script gráficamente y con la opción de guardarlo en un archivo.
Si el tiempo lo permite, se intentará extender la lectura de modelos UML a varios formatos,
tales como Rational Rose o Poseidón, etc.
4 PRODUCTOS RELACIONADOS EN EL MERCADO
En el mercado actual se encuentran tres productos muy importantes relacionados con la
propuesta de la presente Tesis, desarrollados por organizaciones muy importantes tales
como el Grupo Jakarta, Cocobase y Objectmatter Inc.
4.1 COCOBASE ENTERPRISE O/R [1]
CocoBase Enterprise O/R es una aplicación que provee un nivel de traslación dinámica O/R
que se sitúa por encima del driver JDBC entre los objetos de la aplicación (a menudo están
en un servidor de aplicación) y la base de datos (que usualmente es una base de datos
relacional para muchas organizaciones IT). CocoBase administra la persistencia y recupera
los datos desde la aplicación a un lugar donde es guardada en la base de datos relacional.
CocoBase toma el código específico de la base de datos y prescribe SQL de los objetos y
guarda esta información a un nivel de mapa. De este modo desacopla el objeto de su código
interno para adaptarlo a la base de datos. El código específico de la base de datos es
ISC-2003-1-25
3
dinámicamente creado en tiempo de ejecución. Esto permite que los objetos sean
fácilmente usados una y otra vez. Esta capa dinámica provee una multitud de
optimizaciones de desempeño que son fácilmente modificados por el programador para
mejorar sus necesidades específicas.
Si se está trabajando con clases de Java, Tablas de Datos relacionales y/o Modelos de
Objetos CocoBase ofrece las siguientes funcionalidades:
w Crea mapas de objetos a tablas, tablas a objetos, objetos existentes con tablas existentes,
modelos existentes de objetos que utilizan persistencia transparente, modelo de objetos
UML/XML.
w Genera código java a partir de plantillas editables, Persistencia Dinámica Transparente,
clases persistentes de Java, EJB CMP/BMP Beans de Entidad, Beans de Sesión, JSPs y
Servlets.
w Realiza el deploy de Clases de Java y/o EJB’s para todos los servidores de Aplicación
más populares tal como J2SE/J2EE.
4.1.1 Características Adicionales de CocoBase
w CocoBase Enterprise O/R ofrece un sistema flexible y sofisticado para reunir las
necesidades de traslación de modelaje Objetos a Relacional. La herramienta soporta
características tales como mapas que se extienden a través de tablas, uno-uno uno-
Muchos Muchos-Muchos, mapas en subconjuntos de tablas.
w CocoBase ofrece un acceso centralizado a la administración de la base de datos
permitiendo que la administración de la base de datos se realice desde allí.
w La herramienta está escrita completamente en Java permitiendo una alta portabilidad.
w Alto nivel de ejecución O/R
w Soporta automáticamente todos los tipos de relaciones. Detecta llaves foráneas, bean to
bean y bean a relaciones de objetos.
4.1.2 Precio de CocoBase
CocoBase tiene un precio de $US6,000 por desarrollador. Incluye CocoBase Enterprise
O/R Runtime, GUI Mapping admin. Tool, CMP Installer, documentación, y un año de
ISC-2003-1-25
4
soporte técnico vía e-mail y actualizaciones. Dos años de soporte técnico vía e-mail y
actualizaciones: Costo de $US1,250 por cada desarrollador. Todos los precios están sujetos
a cambios sin previo aviso.
Cocobase entiende por desarrollador a cualquiera que utilice el GUI (interfaz), las
herramientas, el API o el Runtime – “Directamente o indirectamente” para utilizar un
objeto que tenga acceso directamente o indirectamente a CocoBase Runtime o CocoBase
Map durante las etapas iniciales o finales para el despliegue del desarrollo en orden para
realizar una función durante el proceso de desarrollo de una nueva lógica. Cada
desarrollador requiere una licencia de desarrollador individual por separado.
4.2 THE VISUAL BUSINESS SIGHT FRAMEWORK [2]
Visual BSF™ (VBSF) aplicación desarrollado completamente en un sistema Java objeto-
relacional que permite que los objetos en Java sean persistentes en una base de datos
relacional. Aunque Java es un lenguaje orientado objeto, las aplicaciones que acceden a
bases de datos relacionales deben trabajar con tablas, filas y columnas. Esto es indiferente
de cualquier JDBC, o cualquier otra librería que Java use para acceder a una base de datos.
Esto tiene un desafortunado efecto colateral de forzar a programador para cambiar entre el
modelo de objetos de la aplicación y el modelo de datos relacional.
Porque los objetos de Java no pueden ser directamente salvado o recuperado de una base de
datos relacional, los desarrolladores trabajan sobre las aplicaciones en Java que tienen
acceso a bases de datos relacionales son forzados a escribir masivas rutinas de conversión
para poder usar los dos lenguajes diferentes, SQL y Java, Además, ellos tienen que
preocuparse sobre el API del Driver (por ejemplo, JDBC). VBSF sobrelleva la
correspondencia de tipo entre objetos de java y bases de datos relacionales resolviendo los
complejos problemas envueltos en la traslación. VBSF contiene un motor de traslación
objeto/relacional que permite a un programador estar atento sobre el modelo de objetos.
Los objetos de Java pueden ser fácilmente salvados y recuperados por un simple llamado de
ISC-2003-1-25
5
métodos, tales como update() y get(). Soporta cargar y salvar colecciones de objetos, al
igual que búsquedas complejas.
VBSF está compuesto de dos componentes: una herramienta de traslación gráfica (GUI) y
soportado por la librería interna que provee los servicios en tiempo de ejecución de la capa
de persistencia. La herramienta de traslación permite visualizar la traslación de las clases
del negocio a tablas y columnas de la base de datos, y para especificar las relaciones de los
objetos. Pueden ser usados para definir el lado del servidor SQL, validar las
comprobaciones, y personalizar la configuración de la base de datos. Si es necesario, los
modelos pueden también ser definidos o modificados enteramente en código sin el uso de la
herramienta. La capa de persistencia puede generar objetos persistentes en una
configuración local o en una distribuida.
4.2.1 Características
w Completo Modelaje de Objetos: Parte de la falta de correspondencia de tipos entre los
modelo objeto-relacional gira alrededor de las diferentes formas en que las relaciones
son mantenidas. En el modelo de datos relacional una fila referencia a una fila en otra
tabla mediante llaves. Para recuperar la referencia de una fila en un join en la base de
datos debe ser desarrollado. En el modelo de objetos, un objeto puede acceder a otro
objeto por referencia directa. VBFS permite mantener el modelo de objetos intacto
manteniendo la traslación entre los dos modelos, entonces las relaciones entre objetos
puede ser mantenida usando referencias directas. Todos los tres tipos de relaciones uno
a uno, uno a muchos, y muchos a muchos son completamente soportados usando
referencias directas a objetos. VBFS distingue entre la diferencia entre agregación y
asociación y permite recorrer una jerarquía de agregación desde el todo a una parte.
4.2.2 Precio de VBSF
Todos los precios para Visual BSF 3.x son por desarrollador y por aplicación o proyecto.
Todos los precios están definidos en dólares Estadounidenses. Una licencia es válida por la
vida de un proyecto o aplicación y no puede ser reutilizada cuando un nuevo proyecto o
aplicación comienza.
ISC-2003-1-25
6
Para propósitos de la licencia, un desarrollador es definido como alguien que usa la
herramienta de traslación o el API de VBSF directa o indirectamente. El uso Indirecto
ocurre cuando se tiene acceso al API dentro de la aplicación en turno que utiliza VBSF para
completar sus funciones. Un caso común es cuando se construye una capa de persistencia
en la aplicación que envuelve funciones de VBSF. Otro caso común de uso indirecto es
cuando el servicio de persistencia está incorporado dentro de los objetos del negocio.
VBSF es también disponible en paquetes de desarrollo y en licencias para organizaciones
con descuentos sustanciales. También se ofrecen descuentos para organizaciones educativas
sin ánimo de lucro, como también para estudiantes.
4.2.3 Tipos de licencia
VBSF es ofrecida bajo dos modos de licencias: Binarios y fuentes. La licencia Binaria
incluye sólo los ejecutables. La licencia Fuente incluye los fuentes y los ejecutables. Una
organización puede tener ambos tipos de licencia si lo desea. Por ejemplo, una organización
con diez desarrolladores trabajando con VBSF puede destinar a dos desarrolladores para
mantener el código de VBSF, y el resto para desarrollar aplicaciones que utilizan los
ejecutables personalizados de VBSF. En este caso, la organización deberá comprar dos
licencias de Fuente y ocho licencias Binarias.
Licencia Binaria incluye las licencias de redistribución de todos los binarios de VBSF, con
la excepción de los binarios de la herramienta de traslación. (maptool2.jar).
ISC-2003-1-25
7
TABLA 1. PRECIOS LICENCIA BINARIA VBSF
La licencia Fuente incluye la capa de persistencia y el fuente de la herramienta de
traslación para las ediciones Profesional y Enterprise. La licencia Fuente permite las clases
binarias resultado de la compilación y modificación de los archivos fuente para ser
vendidos o redistribuidos dentro o fuera de la organización. Hay que notar que el código
fuente y de los binarios de la herramienta de mapeo (maptool2.jar) no puede ser
redistribuida. Todas las licencias de los códigos fuentes deben estar explícitamente de
acuerdo a los términos de la licencia del código fuente firmando la sección apropiada en la
forma de orden.
Producto Precio ($US)
Nueva licencia del código fuente 3,995.00
Actualización de la licencia de la fuente
v2.x 1,995.00
Mantenimiento y soporte básico anual 495.00
Mantenimiento y Soporte completo
anual 695.00
TABLA 2. PRECIOS LICENCIA FUENTE VBSF
Productos de Edición Profesionales Precio ($US)
Nueva Licencia Binaria 895.00
Licencia de Actualización de v2.x 295.00
Soporte y Mantenimiento básico
anual 195.00
Soporte y Mantenimiento completo
anual 345.00
ISC-2003-1-25
8
4.3 OBJECT RELATIONAL BRIDGE [3]
Object Relational Bridge (OJB) es una herramienta de traslación Objeto/Relacional que
permite la persistencia transparente para objetos de Java contra bases de datos relacionales.
4.3.1 Características
w OJB soporta múltiples APIs de persistencia.
w OJB ha sido diseñado para un gran número de aplicaciones, desde sistemas embebidos
hasta aplicaciones de clientes orientados multinivel con arquitecturas basadas en J2EE.
w OJB utiliza un mapeo Objeto/Relacional basado en XML. El mapeo reside en una capa
dinámica de MetaData que puede ser manipulada en tiempo de ejecución a través de un
protocolo de Meta Objetos (MOP) para cambiar el comportamiento de la persistencia
del Kernel.
w Se encuentra actualmente en desarrollo por el grupo Apache.
4.4 CONCLUSIÓN
A continuación se presenta un cuado comparativo entre las herramientas expuestas y la
herramienta que se desea implementar, como objeto de esta propuesta de tesis.
CocoBase Visual BSF™ Object Relational Bridge
Portabilidad Completa Completa Completa
Costos
$US6000
por
desarrollador
$US895 por
desarrollador Gratis
Estado Desarrollado Desarrollado En desarrollo
Mantenimiento No es posible
Es posible,
sólo bajo
licencia Fuente
Si es posible
Licencia EULA GNU
Interfaz
Gráfica Sí Si Sí
TABLA 3. TABLA COMPARATIVA ENTRE HERRAMIENTAS
ISC-2003-1-25
9
5 MOTIVACIÓN
En los proyectos de desarrollo de software, el punto de partida para poder entender el
sistema a diseñar es generar un diagrama orientado por objetos. Esto se logra utilizando el
modelo UML; este modelo describe los objetos que pertenecen al sistema y las relaciones
que los objetos tienen entre sí.
Es frecuente que durante el desarrollo de un proyecto se tome la decisión de utilizar un
Sistema Manejador de Bases de Datos para el manejo de la persistencia de la información.
La dificultad existente en ese momento es la traslación del modelo orientado por objetos,
que se ha realizado para poder entender el sistema, a un modelo de datos relacional que es
el que se utiliza para poder realizar un diseño de la base de datos necesaria para la
realización de la persistencia.
El interés de esta propuesta de Tesis es diseñar una aplicación que tome un modelo
orientado por objetos, lo traslade a un modelo de datos relacional para aumentar la
eficiencia del desarrollo de software y posteriormente generar un script de creación de
tablas tomando como base el modelo de datos relacional.
Después de una intensa búsqueda de software disponible relacionado con el objetivo de esta
propuesta, se ha encontrado con productos de alta calidad pero con ciertas restricciones
sobre su uso. Algunos productos no son fácilmente accesibles por sus altos costos, como
CocoBase y VBFS, y otros porque se encuentran actualmente en desarrollo.
Una de las principales motivaciones es realizar una aplicación libre, la cual pueda ser
actualizada o extendida hacia otras funcionalidades. Actualizada a nuevos estándares de
modelaje de objetos o de lenguaje SQL para Oracle, o extendida a lenguaje SQL de otras
bases de datos como Postgres o MySQL.
ISC-2003-1-25
10
6 MODELO DE TRASLACIÓN DE MODELOS
ORIENTADOS-OBJETOS A MODELOS DE DATOS-
RELACIONAL
6.1 INTRODUCCIÓN
El crecimiento del valor estratégico y la importancia del software, aumenta la necesidad de
sistemas integrados que contribuyan a la supresión de las necesidades para tener una vista
global y comprensiva sobre los procesos de la concepción del sistema.
UML responde estas inquietudes, proveyendo un conjunto de diagramas que dan la
capacidad de modular diferentes perspectivas del sistema, incluyendo el modelo orientado a
objetos (Diagrama de Clases).
UML llegó a ser una metodología estándar para el diseño y concepción de los sistemas. Por
ello, las herramientas centrales que se encuentran en el mercado están basados en UML.
Las dificultades ocurren cuando se tiene que manejar con sistemas reales que implementan
modelos de objetos en paradigmas relacionales debido a que los dos modelos no tienen una
transformación de uno al otro, usualmente la implementación llega a ser deficiente o
inconsistente.
Actualmente se piensa que el mapeo objeto-relacional es un paso necesario para establecer
la forma en que los dos modelos puedan cohabitar. Sin embargo, en la literatura no es
posible encontrar análisis sólidos sobre ese modelo de traslación. Algunos sistemas de
desarrollo proponen sus propias reglas de traslación, pero usualmente no cubre todos los
alcances de la expresión del modelo de objetos.
ISC-2003-1-25
11
El paradigma orientado a objeto está llegando a ser el principal soporte para el modelaje de
sistemas, pero infortunadamente las bases de datos orientadas a objetos no progresan en la
misma velocidad, haciendo que las bases relacionales el estándar para el almacenamiento
de datos.
6.2 DE UML AL MODELO DE DATOS RELACIONAL
El modelo de lenguaje unificado (UML) es un lenguaje para visualización, especificación,
construcción y documentación de los componentes del sistema de software, también para el
modelaje de negocios y otros sistemas que no son software. UML representa la colección
de las mejores prácticas ingenieriles que han tenido éxito en el modelaje de una gran
cantidad de sistemas complejos.
UML, un lenguaje visual de modelaje, no tiene la intención de ser un lenguaje de
programación, en el sentido de tener todo el soporte visual y semántico necesarios para
remplazar a los lenguajes de programación visuales.
UML es un conjunto de diagramas que provee múltiples perspectivas del sistema bajo el
análisis o el desarrollo. El diagrama de clases muestra la estructura estática del modelo, en
particular, de las cosas que existen (tales como clases y tipos), su estructura interna y sus
relaciones con otras cosas.
El estándar UML está definido por una organización independiente, Object Management
Group (OMG), y el primer objetivo de OMG fue permitir la Interoperabilidad entre
herramientas. UML es usado para el modelaje de objetos debido a que las herramientas más
populares lo usan y además es un estándar que está bien establecido y mantenido por OMG.
Las bases de datos relacionales son usadas en lugar de bases de datos orientadas a objetos,
debido a que las bases de datos relacionales están bien establecidas. Las bases de datos
relaciones son el estándar para el almacenamiento de datos y una de las características que
le da la mayor contribución para la importancia de su éxito es que es muy conocido y está
ISC-2003-1-25
12
soportada por una teoría matemática. En comparación, las bases de datos orientadas a
objetos son inmaduras y tienen muy pocos progresos.
Es posible trasladar el diagrama de clases de UML a un modelo de datos relacional
correspondiente. Para alcanzar este objetivo se debe establecer una representación formal
para los dos y un conjunto de reglas que deben ser seguida para trasladar un diagrama de
clases en un modelo de datos relacional.
Una combinación efectiva de UML y bases de datos relacionales permite la verdadera
compleja traslación Objeto/Relacional en momento del diseño. La traslación en el momento
del diseño asegura que el código del acceso de los datos del sistema, que se trabajen con
objetos y bases de datos está bien estructurada. Inconsistencias que son descubiertas en el
momento del desarrollo, son más difíciles y costosas de arreglar.
Para comenzar es necesario representar y formalizar cada modelo. Se decidió utilizar el
cálculo de predicados. Las razones principales para tomar esta decisión están basados sobre
las características principales de la lógica matemática, tales como la universalidad, la
flexibilidad y la expresividad.
Teniendo una formal representación de los dos modelos es posible establecer un conjunto
de reglas lógicas para trasladar de un modelo a otro.
6.2.1 REPRESENTACIÓN LÓGICA DEL DIAGRAMA DE CLASES
El primer paso en orden para construir un modelo de datos relacional crear una lógica
representación del diagrama de clases de UML. Esto implica la existencia de una
conceptualización lógica del Universo (el diagrama de clases). El modelo de la
conceptualización es descrita por la tupla:
M = {D, R}
En donde D para el universo en discurso, significado de los objetos del dominio en que el
conocimiento es expresado:
ISC-2003-1-25
13
R es el conjunto de relaciones a través de cómo los objetos interactúan.
D = { todas las expresiones comienzan por pequeñas capas }
R = {
Clases(cl),
Asociacion(as),
Generalizacion(g),
Agregacion(ag), Composicion(comp),
MiembroAsociacion(as, cl, role, lower_mult, upper_mult),
Atributo(cl, at),
AtributoID(g, cl)
Especificación(g, cl),
ParteAgregación(ag, cl),
ParteComposición(comp, cl),
ClaseAsociativa(asc) }
Clases(cl), esta relación enumera todas las clases.
Asociacion(as), esta relación enumera todas las asociaciones.
Generalizacion(g), esta relación enumera todas las generalizaciones,
Agregacion(ag), esta relación enumera todas las agregaciones,
Composición (comp), esta relación enumera todos las composiciones,
MiembroAsociacion(as, cl, role, lower_mult, upper_mult), relaciona las
Clases(cl), con las asociacion(as) que tienen un role(role) y multiplicidad
(lower_mult...upper_mult), donde lower_mult es el límite inferior y upper_mult es el
limite superior.
Atributo(cl, at), asocia una tributo (at) a una clase (cl).
AtributoID(cl, at), asocial los atributos a las clases que ellos identifican.
Especificacion(g, cl), socia la clase que es un caso particular de la
Generalización (g) respectiva.
ParteAgregacion(ag,x,lower_mult, upper_mult), asocial las clases
envueltas en la agregación.
ISC-2003-1-25
14
ParteComposicion(comp, cl, lower_mult, upper_mult), asocia las
clases envueltas en una composición (comp.).
ClaseAsociativa(asc), enumera las clases que son simultáneamente clases y
asociaciones.
Una clase asociativa es una asociación con propiedades de clase (o una clase con
propiedades de clases). Una clase asociativa es simplemente una asociación con atributos,
que significa que la representación de una Clase de Asociación es representada también
como una clase y una relación de asociación. Los atributos de la Clase de Asociación son
representados como los atributos de las clases correspondientes.
A continuación es presentado un diagrama de clases en UML para la explicación de las
reglas y una mejor comprensión de las mismas:
FIGURA 1. EJEMPLO DE UN DIAGRAMA DE CLASES DE UML
Este ejemplo es conceptualizado al modelo orientado objetos formal a continuación:
ISC-2003-1-25
15
Clase(Compania)
AtributoID(Compania, comp_nombre)
Clase(Producto)
AtributoID(Producto, producto_ID)
Atributo(Producto, nombre)
Atributo(Producto, precio)
Clase(Departamento)
AtributoID(Departamento, dep_ID)
Atributo(Departamento, nombre)
Atributo(Departamento, ubicación) Clase(Productos_plasticos)
Atributo(Productos_plasticos, tipo_plastico)
Clase(Productos_metalicos)
Atributo(Productos_metalicos, tipo_metal)
Clase(persona)
AtributoID(persona, persona_ID)
Atributo(persona, nombre)
Clase(direccion)
AtributoID(direccion, direccion_ID)
Atributo(direccion, calle) Atributo(direccion, pais)
Atributo(direccion, ciudad)
Atributo(direccion, cod_postal)
Clase(labor)
Atributo(labor, labor_nombre)
Atributo(labor, salario)
Agregacion(Compania)
ParteAgregacion(Compania, Departamento, 1,*)
Composición(Persona)
ISC-2003-1-25
16
ParteComposicion(persona, direccion, 1,*)
Asociacion(labor)
MiembroAsociacion(labor, Compania, empleado, 0,*)
MiembroAsociacion(labor, Persona, empleado, 1,*)
Asociacion(dirige)
MiembroAsociacion(dirige, labor, jefe, 0,1)
MiembroAsociacion(dirige, jefe, trabajador, 1,*)
MiembroAsociacion(produce, Compania, hace, 1, 1)
MiembroAsociacion(produce, Producto, hecho, 0,*)
Generalización(Producto)
Especificación(Producto, Productos_plastico)
Especificación(producto, Productos_metalico
6.3 REPRESENTACIÓN LÓGICA DEL MODELO DE DATOS
RELACIONAL
El segundo paso es para usar la lógica para representación del modelo para realizar la
traslación. El modelo de datos relacional es descrito por la tupla:
MR = { DMR, RMR }
En el que DMR, representa el universo en discurso, esto es, los objetos del dominio sobre el
cual el conocimiento es expresado.
RMR es el conjunto de relaciones a través de los cuales los objetos interactúan.
DMR = { todas las expresiones comienzan por pequeñas capas }
RMR = {
Tabla(tb),
Columna(tb, col),
Llave(tb, k),
LlaveForanea(fk, tbo, tbd),
MiembroFK(fk, co) }
ISC-2003-1-25
17
Tabla(tb), esta relación enumera todas las tablas,
Columna(tb, co), asocia una columna (co) con una tabla (tb),
Llave(tb, k), asocia el atributo con la llave que identifica la tabla,
LlaveForanea(fk, tbo, tbd), asocia las tablas con las relaciones entre ellos.
MiembroFk(fk, co), asocia las relaciones con los atributos que lo implementan.
6.3.1 REGLAS DE MANIPULACIÓN DE DIAGRAMAS DE CLASES
Estos axiomas presentados en esta sección intentan realizar la transposición entre los dos
modelos más fácilmente. Ellos hacen algunos cambios a los diagramas de clases UML,
haciendo el proceso de transposición más fácil, sin alterar su semántica. Los siguientes
axiomas ayudan este objetivo.
Como se verá más adelante, las asociaciones "uno a muchos” no originan tablas,
incluyendo asociaciones con atributos (clases asociativas). En el último caso, el proceso de
transposición puede llegar a ser difícil si la clase asociativa está envuelta en otras
asociaciones. El hecho que ellos no originan tablas se debe al desplazamiento de los roles
que juegue esta clase para otras clases.
REGLA 1: todas las clases que son una asociación son denominadas clases asociativas.
))()()(( xativaClaseAsocixAsociacionxClassx ⇔∧∀
REGLA 2: todas las clases asociativas en que una de los participantes como “0..1” o “1..1”
de la multiplicidad, transfiere sus atributos y roles en sus asociaciones para las clases que
participan en esas asociaciones (solo aquella que participa con una multiplicidad mayor que
uno (1)).
∀a(∀x(∀b(∀r(∀lm(∀um(∀lm1(∀um1(∀at(
ClaseAsociativa(a) ∧ MiembroAsociativo(a,x,r,lm,um) ∧um>1∧
∃y(MiembroAsociativo(a,y,r1,lm1,um1) ∧um1=1∧
Atributo(a, at) ⇒ Atributo(x, at))))))))))
ISC-2003-1-25
18
Ejemplo de un diagrama de clases, antes de la REGLA 2:
FIGURA 2. EJEMPLO DE DIAGRAMA DE CLASES ANTES DE LA MANIPULACIÓN DE LA REGLA
2.
Después de la REGLA 2:
FIGURA 3. EJEMPLO DE DIAGRAMA DE CLASES DESPUÉS DE LA MANIPULACIÓN DE LA
REGLA 2.
REGLA 3: todas las clases asociativas que no están incluidas en el axioma anterior tienen
como identificación atributos el conjunto de identificación de atributos todas las clases que
participan en la asociación.
∀a(∀x(∀b(∀r(∀lm(∀um(∀r1(∀um1(∀r2(∀lm2(∀um2(
ClaseAsociativa(a) ∧MiembroAsociativo(a,x,r,lm,um) ∧um>1∧
∃y(MiembroAsociativo(a,y,r1,lm1,um1) ∧um1=1∧
MiembroAsociacion(b,a,r2,lm2,um2) ⇒
MiembroAsociacion(b,x,r2,lm2,um2))))))))))))
Aplicando esta regla al ejemplo de diagramas de clase en la figura 1, se tiene:
ISC-2003-1-25
19
ClaseAsociacion(labor)
AtributoID (labor, Labor, comp_nombre)
AtributoID (labor, persona_ID)
6.3.2 REGLAS DE TRANSPOSICIÓN
Las reglas de transposición tienen el propósito de expresar un conjunto de reglas que
realizan la transposición entre el diagrama de clases y el modelo de datos relacional. El uso
de estas reglas será la base para la creación del modelo de datos relacional basado en la
conceptualización lógica del diagrama de clases.
Las reglas de transposición están divididas en dos clases:
w Las reglas de construcción, que son el conjunto de reglas básicas que implementan la
trasposición entre los dos modelos.
w Las reglas que son definidas por el usuario, haciendo posible para el usuario controlar el
proceso, adaptándolo en orden para cubrir sus necesidades.
Las reglas de construcción son un conjunto de reglas predefinidas que no pueden ser
manipuladas por el diseñador del proceso. Antes de comenzar la enumeración de las reglas,
es necesario introducir dos conceptos que se usarán a menudo para explicar la semántica de
las reglas, ellos son: la relación de identidad y la relación de no-identidad.
La relación de identidad es una relación entre dos tablas dependientes, en donde una tabla
hijo no puede existir sin la tabla padre. La llave primaria de la tabla padre llega a ser parte
de la llave primaria de la tabla hijo y es una llave foránea de la tabla hijo.
La relación de no-identidad representa la relación entre dos tablas independientes. La
columna de la llave foránea no participa en la llave de la tabla hijo.
ISC-2003-1-25
20
La tabla 3 define una secuencia de pasos para trasladar un Diagrama de Clases de UML en
un Modelo de Datos Relacional:
Regla Descripción
1 Traslada las clases y asociaciones de muchos-a-muchos a tablas.
2 Traslada atributos a columnas.
3 Traslada identificadores de clases a llaves de tablas.
4 Generar relaciones de identidad a tablas originados por asociaciones
de muchos a muchos y clases asociativas
5 Trasladar asociaciones uno a muchos a relaciones de no-identidad.
6 Traslación de Generalización a relaciones de identidad.
7 Traslación de agregación por referencia a relaciones de no-
identidad.
8 Traslación de agregación compuesta a relaciones de identidad.
TABLA 4. CONSTRUCCIÓN DE REGLAS DE TRANSPOSICIÓN.
Regla 1: Trasladar clases y asociaciones de muchos a muchos en tablas
Cada clase y asociación de muchos a muchos se traslada a una tabla.
Para implementar esto se necesitan dos axiomas:
Las clases, excluyendo aquellas que son clases asociativas, se trasladan a tablas:
( ) ( ) ( )( )xTablaxativaClaseAsocixClasex ⇒¬∧∀
Las asociaciones de muchos-a-muchos, incluyendo aquellas que son clases asociativas, se
trasladan a tablas asociativas; el nombre de la tabla será el nombre de la asociación.
( ) ( )( ) ( )( )( )( )( )xTablaumumlmrzxciacionMiembroAsozxAsociacionumlmrx ⇒≡∧¬∃∧∀∀∀∀ 1,,,,
Esta tabla asociativa es necesaria porque en modelo de datos relacional no permite las
relaciones muchos-a-muchos. Una tabla asociativa es un dato de entidad donde su único
propósito es mantener la asociación entre dos o mas tablas en una base de datos relacional.
Esas relaciones entre tablas serán creadas en la regla número cuatro.
ISC-2003-1-25
21
Aplicando la Regla 1 al ejemplo propuesto (ver figura 1) se obtiene:
Tabla (Compania)
Tabla (Departamento)
Tabla (Producto)
Tabla (Persona)
Tabla (Direccion)
Tabla (Productos_plasticos)
Tabla (Productos_metalicos)
Tabla (Labor)
Regla 2: Trasladar atributos a columnas
Los atributos de las clases y las clases asociativa, que originaron las tablas, se trasladan a
columnas de las tablas relacionadas. Traslación de los atributos de las clases:
( ) ( ) ( ) ( )( )( )yxColumnayxAtributoxativaClaseAsocixClaseyx ,, ⇒∧¬∧∀∀
Traslación de los atributos de las clases asociativas, se deben excluir las asociaciones que
no originan tablas:
∀x(∀a(∀r(∀lm(∀um(
ClaseAsociacion(x) ∧¬∃z(MiembreoAsociacion(x,z,r,lm,um) ∧um=1)∧
Atributo(x,a) ⇒ Columna(x,a)))))
Estas reglas sólo trasladan atributos que no son parte de los identificadores de Clases. Estas
últimas serán trasladadas por la siguiente regla.
Usando el ejemplo previo, y aplicando la Regla 2, se tiene:
Columna (Persona, nombre) Columna (Labor, labor_nombre)
Columna (Labor, salario)
ISC-2003-1-25
22
Columna (Departamento, nombre)
Columna (Departamento, ubicacion)
Columna (Direccion, calle)
Columna (Direccion, pais)
Columna (Direccion, cod_postal)
Columna (Direccion, ciudad)
Columna (Producto, nombre)
Columna (Producto, precio)
Columna (Productos_plasticos, tipo)
Columna (Productos_metalicos, tipo)
Regla 3:Traslación de Identificadores de Clases a Llaves de Tablas
Todos los atributos que son parte de los identificadores de clases, serán trasladados a llaves
primarias de columnas de la tabla asociada:
( ) ( ) ( ) ( ) ( )( )( )yxLlaveyxColumnayxAtributoIDxacionClaseAsocixClaseyx ,,, ∧⇒∧¬∧∀∀
Utilizando el ejemplo propuesto, y aplicando la Regla 3, se obtiene:
Llave (Persona, persona_ID)
Llave (Compania, comp_nombre)
Llave (Producto, producto_ID)
Llave (Departamento, dep_ID)
Llave (Direccion, direccion_ID)
Regla 4: Generar las relaciones de identidad a tablas originadas por asociaciones de
muchos-a-muchos y clases asociativas
Por la regla 1, las clases asociativas se trasladaron a tablas asociativas. Además se necesitan
generar las relaciones ( llaves y llaves foráneas).
Paso Uno – La Llave:
La llave de tabla asociativa será la combinación de las llaves en las tablas envueltas en la
relación.
ISC-2003-1-25
23
Paso Dos – Las llaves foráneas:
La regla usada para generar las relaciones es descrita en el siguiente diagrama:
FIGURA 4. EL PROCESO DE INTRODUCIR UNA TABLA ASOCIATIVA
La tabla de asociación divide la asociación muchos a muchos (no soportada en el modelo
de datos relacional) en dos relaciones uno-dos-muchos (soportadas por el modelo de datos
relacional) usando relaciones de identidad. Para mantener la semántica es necesario
implementar una llave foránea por cada tabla envuelta en la relación.
∀a(∀x(∀r1(∀lm1(∀um1(∀r(∀lm(∀um(
Clase(x)∧ Asociacion(a) ∧MiembroAsociacion(a,x,r1,lm1,um1) ∧um1>1∧
¬∃z(MiembreoAsociacion(a,z,r,lm,um) ∧um=1) ⇒
LlaveForanea(r1,a,x))))))))
∀a(∀x(∀r1(∀lm1(∀um1(∀r(∀lm(∀um(∀at(
Clase(x)∧ Asociacion(a) ∧MiembroAsociacion(a,x,r1,lm1,um1) ∧um1>1∧
¬∃z(MiembreoAsociacion(a,z,r,lm,um) ∧um=1) ∧
AtributoID(x,at) ⇒ Columna(a,at) ∧Llave(a,at)
∧MiembroFK(r1,at)))))))))
Utilizando el ejemplo propuesto y aplicando la Regla 4, se tiene:
Columna(Labor, jefe)
Columna(Labor, comp_nombre)
Llave(Labor, persona_ID)
B
B
M N
N M 1 1
A
A Tabla
asociati
ISC-2003-1-25
24
Llave(Labor, comp_nombre)
LlaveForanea (empleado, Labor, Persona)
LlaveForanea (empleador, Labor, compania)
MiembroFK (empleado, persona_ID)
MiembroFK (empleador, comp_nombre)
Regla 5: Traslación de las asociaciones de uno a muchos a relaciones de no-identidad.
Cada instancia del lado muchos necesita una asociación a exactamente una instancia del
lado Uno. Una llave foránea es generada para construir la relación
Los atributos que implementan el identificador de la clase en el lado muchos, generarán
columnas en la tabla de asociación con la clase del lado uno. El rol de estas columnas es
implementar las llaves foráneas. Eso pasa porque en el paso anterior se estableció la
relación y ahora es necesario especificar las columnas que lo implementan.
Usando el ejemplo previo y aplicando la Regla 5, se obtiene:
Columna (Labor, comp_nombre)
Columna (Labor, persona_ID)
LlaveForanea(jefe, Labor, Labor)
MiembroFK(jefe, comp_name) MiembroFK(jefe, persona_ID)
Columna(Producto,comp_name)
LlaveForanea (hecho, Producto, Compania)
MiembroFK (hecho, comp_name)
Regla 6: Traslación de Generalización a relaciones de identidad
La traslación de la generalización en una tabla por clase, cada clase da lugar a una tabla. La
tabla padre es unida a cada una de las tablas hijo por una relación de identidad. Además,
cada tabla hijo contiene una llave primaria/foránea relacionada a la llave primaria de la
tabla padre.
ISC-2003-1-25
25
( ) ( ) ( )( )( )( )gxFKgxconcateaLlaveForanxgcionEspecificagcionGeneralizaxg ,,'_',,, ⇒∧∀∀
∀g(∀x(
Generalización(g) ∧Especificacion(g,x) ∧
AtributoID(g,y) ⇒Columna(x,y) ∧Llave(g,y)
∧MiembroFK(concat(x,g,’_FK’), y))))
Utilizando el ejemplo y aplicando la Regla 6, se obtiene:
Columna (Productos_metalicos, producto_ID) Llave (Productos_metalicos, producto_ID)
LlaveForanea (productos_metalicos_producto_FK,
Productos_metalicos,
Producto)
Columna (Productos_plasticos, producto_ID)
Llave (Productos_plasticos, producto_ID)
LlaveForanea (productos_plasticos_producto_FK,
Productos_plasticos,
Producto)
ISC-2003-1-25
26
Regla 7: Traslación de agregación por referencia a relaciones de no-identidad
Traslación de la agregación por referencia (conocida como agregación) a relaciones de no-
identidad. La agregación es usada cuando se tienen múltiples instancias de una clase padre
que posee clases dependientes. Una agregación es el rey de la asociación donde una clase
padre es requerida por el uso de una multiplicidad “1..N”. La diferencia entre asociación y
agregación es cuan listo esta los objetos limitados a cada uno entre sí. Para implementar
esta relación la llave primaria de la tabla de agregación migra a las tablas de agregación de
partas como llaves foráneas.
( ) ( ) ( )( )( )abbeaLlaveForanbaacionParteAgregaAgregacionba ,,, ⇒∧∀∀
( ) ( ) ( )( ) ( )
⇒∧∧∀∀∀
xbMiembroFKxbColumnaxaAtributoIDbagacionParteAggreaAgregacion
xba,,,
,,
Usando el ejemplo y aplicando la Regla 7, se obtiene:
LlaveForanea (departamento, Departamento, Compania)
Columna (Departamento, comp_nombre)
MiembroFK (Departamento, comp_nombre)
Regla 8: Traslación de agregación compuesta a relaciones de identidad
La agregación compuesta consiste de un todo y una parte, donde la parte no puede existir
sin el todo. La llave primaria de la tabla de Composición migra a la tabla de
ComposiciónParte como llave foránea y también como llave primaria – relación de
identidad.
( ) ( ) ( )( )( )abbeaLlaveForanbasicionParteCompoanComposicioba ,,, ⇒∧∀∀
( ) ( ) ( )( ) ( ) ( )
∧∧
⇒∧∧∀∀∀
xbMiembroFKxbLlavexbColumnaxaAtributoIDbasicionParteCompoanComposicio
xba,,,
,,
ISC-2003-1-25
27
Usando el ejemplo propuesto y aplicando la Regla 8, se obtiene:
LlaveForanea(direccion, Direccion, Compania)
Columna (Direccion, persona_ID) Llave (Direccion, persona_ID)
MiembroFk (direccion, persona_ID)
6.3.3 CONCLUSIONES
La expresividad de la lógica formal permite definir fácilmente un conjunto de reglas de
traslación entre el modelo orientado a objetos y modelos relacionales. Estas reglas pueden
ser enriquecidas con un conjunto de reglas específicas que expresan las preferencias del
diseñador. La lógica representación relacional puede ser fácilmente trasladada a otros
lenguajes, tales como, SQL, XML, etc.
7 LEVANTAMIENTO DE REQUERIMIENTOS
Los requerimientos son una descripción de las necesidades o deseos de un producto. La
meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se
necesita, en una forma que claramente se lo comunique al cliente. El reto consiste en
definirlos de manera inequívoca, de modo que se detecten los riesgos y no se presenten
sorpresas al momento de entregar el producto[5].
Es por ello que se definen a continuación los siguientes requerimientos funcionales y no
funcionales.
ISC-2003-1-25
28
7.1 HERRAMIENTAS Y DESARROLLO
IDENTIFICADOR:
1.0
NOMBRE:
Plataforma de desarrollo
Descripción:
La plataforma que se empleará para el desarrollo de esta tesis será Windows.
CRITERIOS DE ACEPTACIÓN
Cualquier versión de Windows tales como 98, Me, XP y 2000.
IDENTIFICADOR:
1.1
NOMBRE:
Lenguaje de programación.
Descripción:
El lenguaje de programación que se utilizará para el desarrollo de esta aplicación será Java JDK
1.4.1.
CRITERIOS DE ACEPTACIÓN
Ejecución de la aplicación en una versión de JDK 1.4.1 o superior.
7.2 VISUALIZACIÓN
IDENTIFICADOR:
2.1
NOMBRE:
Interfaz
Descripción:
Se proveerá al usuario final una interfaz provista de ventanas para la visualización de la
aplicación
CRITERIOS DE ACEPTACIÓN
La aplicación será implementada con Frames, que permite crear ventanas durante su ejecución.
ISC-2003-1-25
29
7.3 INTERACCIÓN
IDENTIFICADOR:
3.1
NOMBRE:
Interacción
Descripción:
w La interacción del usuario con la aplicación se desarrollará de la siguiente forma:
w El usuario escogerá la opción de cargar el archivo, con formato DIA v9.0, con el diagrama
de clases, para crear el modelo orientado por objeto formal. La aplicación realizará la
traslación del modelo orientado por objeto formal al modelo de datos relacional formal.
w Finalmente, el sistema mostrará gráficamente el script de creación de tablas, a partir del
modelo de datos relacional formal ya existente, con la opción de guardar el script en un
archivo.
CRITERIOS DE ACEPTACIÓN
Debido a que la interfaz es de ventanas, la interacción de la aplicación con el usuario final se
realizará a través del teclado y del mouse.
7.4 OPERACIÓN
IDENTIFICADOR:
4.1
NOMBRE:
Operación
Descripción:
Se dará la opción al usuario de poder abrir el archivo con el diagrama de clases y luego de
guardar el script de creación de tablas en un archivo.
CRITERIOS DE ACEPTACIÓN
El usuario podrá realizar la creación de tablas a partir del archivo que contiene el script.
ISC-2003-1-25
30
7.5 DESEMPEÑO
IDENTIFICADOR:
5.1
NOMBRE:
Desempeño
Descripción:
Se intentará optimizar la aplicación al máximo logrando tiempos de respuestas muy
pequeños, se limitará la creación del modelo orientado por objetos, un tiempo de
traslación entre modelos, y la generación de los scripts de creación de tablas.
CRITERIOS DE ACEPTACIÓN
Se diseñarán pruebas detalladas que permitan validar el óptimo desempeño de la
aplicación, ya sea por tiempos estimados por número de clases o tiempo global de
ejecución.
7.6 COMPATIBILIDAD
IDENTIFICADOR:
6.1
NOMBRE:
Formato del archivo de entrada
Descripción:
El archivo que contiene el diagrama de clases inicial debe estar en el formato que
genera DIA v9.0.
CRITERIOS DE ACEPTACIÓN
El archivo DIA v9.0 debe ser un diagrama de clases, y no otro modelo.
ISC-2003-1-25
31
IDENTIFICADOR:
6.2
NOMBRE:
Formato del archivo de salida
Descripción:
El archivo que se guarda con el script de generación de tablas al final de utilizar la
aplicación será de texto plano.
El formato a utilizar será:
w Una línea por cada definición de tablas
w Dentro de la definición de la tabla una línea por definición de cada columna de la
tala
w Una línea por cada definición de llaves dentro de la definición de una tabla.
w Entre cada definición de tabla una línea vacía.
w Si es necesario, una línea por cada definición de índices.
Los scripts de creación de tablas se realizará con base al estándar SQL92, y dirigido a
un Sistema Manejador de Bases de Datos Oracle8i.
CRITERIOS DE ACEPTACIÓN
El script podrá ser ejecutado directamente sobre un sistema manejador de bases de
datos Oracle8i, y se crearán las tablas que se describen en el script de creación de
tablas.
ISC-2003-1-25
32
7.7 ROBUSTEZ Y RECUPERACIÓN DE ERROR
IDENTIFICADOR:
7.1
NOMBRE:
Manejo de errores
Descripción:
En el momento en el que se generé un error durante la ejecución de la aplicación, la
aplicación continuará su ejecución y mostrará al usuario por medio de una ventana
gráfica el tipo de error que ocurrió, junto con una pequeña descripción del error.
Existirán 3 tipos de errores principales:
w El formato del archivo que contiene el diagrama de clases no tiene formato DIA.
w No existe un diagrama orientado a objetos formal válido, para su traslación a un
diagrama de datos relacional.
w No existe un diagrama de datos relacional válido, para la generación de scripts de
creación de tablas.
CRITERIOS DE ACEPTACIÓN
Se mostrará una ventana con el error y su descripción, y la aplicación seguirá en su ejecución normal.
7.8 MANTENIBILIDAD
IDENTIFICADOR:
8.1
NOMBRE:
Estándares de documentación
Descripción:
La metodología para el desarrollo de la aplicación será UML:
La estructura interna de los archivos fuentes será documentada con Javadoc, para una
mayor mantenibilidad.
CRITERIOS DE ACEPTACIÓN
Se hará revisión periódica de los formatos de los documentos Javadoc, verificando su
consistencia.
ISC-2003-1-25
33
IDENTIFICADOR:
8.2
NOMBRE:
Capas de desarrollo
Descripción:
La aplicación estará soportada por tres capas, una capa externa que es la de
visualización, una capa con la lógica de la aplicación, y por último, una capa que se
encarga del manejo con fuentes externas a la aplicación (archivos, bases de datos, etc.).
CRITERIOS DE ACEPTACIÓN
w Para validar la capa de visualización se tendrá en cuenta si la aplicación muestra el
diagrama de clases.
w Para validar la capa de manejo de fuentes externas y la de lógica, primero la
visualización del diagrama de clases, ya que con eso se verifica que se esta leyendo
el archivo generado por DIA y además el modelo lógico para la carga del diagrama
se ejecuta satisfactoriamente, y por último al momento de crear los scripts de
creación de tablas se valida que el modelo está realizando la traslación de forma
normal y la capa de fuentes externas esta creando el archivo de creación de tablas.
w Igualmente, durante el ciclo de desarrollo se hará revisión de integración de capas.
7.9 CONTROL DE ACCESO
IDENTIFICADOR:
9.1
NOMBRE:
Control de acceso
Descripción:
La aplicación no tendrá control de acceso de ningún tipo.
CRITERIOS DE ACEPTACIÓN
El usuario podrá acceder a la ejecución de la aplicación si la aplicación es ejecutada
sobre un sistema operativo windowsm, y además posee un JDK 1.4.1 o superior.
ISC-2003-1-25
34
8 DEFINICIÓN DE LOS CASOS DE USO
A continuación se describen clara y concisamente los casos de uso que definen las acciones
que la aplicación debe realizar.
8.1 DIAGRAMAS DE CASOS DE USO
FIGURA 5. DIAGRAMA DE CASO DE USO
8.2 CASOS DE USO
Nombre Caso de Uso: Traslación de un diagrama de clases expresado en UML a un
modelo orientado a objetos formal
Iteración: Filled
Resumen:
El usuario al abrir en la aplicación un archivo con el diagrama de
clases, con formato de DIA v9.0, la aplicación traslada el
diagrama de clases a un modelo orientado por objetos formal.
Curso Básico
Eventos:
Este caso de uso comienza cuando un usuario decide abrir el
diagrama de clases en UML, que se encuentra en formato de DIA
v9.0.
El sistema procede a abrir el archivo, y lee la información
contenida en el archivo.
Luego, realiza la transformación del diagrama de clases a un
modelo orientado a objetos formal.
ISC-2003-1-25
35
modelo orientado a objetos formal.
Por ultimo, grafica el diagrama de clases.
Caminos de
Excepción:
Si no existe el archivo con el diagrama de clases se produce un
error.
Si el formato que se intenta abrir no es el de DIA v9.0, se produce
una excepción.
Puntos de Extensión:
Triggers: A solicitud del usuario
Suposiciones: El archivo está en el formato que DIA v9.0 solicita, es decir es un
diagrama de clases válido.
Pre-condiciones: El archivo que contiene el diagrama de clases tiene el formato
generado por DIA v9.0.
Post- Condiciones: Se genera el modelo conceptual formal en la aplicación y se
grafica el diagrama de clases en la aplicación.
Nombre Caso de Uso: Creación de un modelo de datos relacional formal a partir de un
modelo orientado por objetos formal
Iteración: Filled
Resumen:
A petición de usuario la aplicación crea el modelo de datos
relacional formal a partir de la traslación del modelo orientado
por objetos formal.
Curso Básico
Eventos:
Este caso de uso comienza cuando un usuario decide transformar
el diagrama de orientado por objetos a un diagrama de objetos
relacional.
El sistema procede a tomar el modelo orientado a objetos formal,
lo traslada a un modelo de datos relacional formal.
Luego, la aplicación visualiza el diagrama de objetos relacional.
Caminos de Si no se encuentra el modelo orientado por objetos formal se
ISC-2003-1-25
36
Excepción: genera una excepción.
Puntos de Extensión:
Triggers:
A solicitud del usuario o cuando se invoque algún método de
ejecución directa de creación de scripts de creación de tablas al
momento de realizar la lectura de un diagrama de clases.
Suposiciones: Existe un modelo orientado por objetos formal válido.
Pre-condiciones: La aplicación contiene un modelo orientado por objetos formal
Post- Condiciones: La generación de un modelo de datos relacional formal y la
graficación de este modelo.
Nombre Caso de Uso: Generación de los scripts de creación de tablas a partir de un
modelo de datos relacional formal
Iteración: Filled
Resumen:
A petición de usuario la aplicación crea el modelo de datos
relacional formal a partir de la traslación del modelo de datos
relacional formal.
Curso Básico
Eventos:
w Este caso de uso comienza cuando un usuario decide crear los
scripts de creación de tablas, a partir del diagrama relacional
que se muestra en la aplicación.
w El sistema procede a tomar el modelo de datos relacional
formal, y crea el script de creación de tablas.
w Y finalmente muestra el script en la aplicación
Caminos de
Excepción:
Si no se encuentra el modelo de datos relacional se genera una
excepción.
Puntos de Extensión:
Triggers:
A solicitud del usuario o cuando se invoque algún método de
ejecución directa de creación de scripts de creación de tablas al
momento de realizar la ejecución directa de la creación de un
diagrama de datos relacional formal o la lectura de un diagrama
de clases.
Suposiciones: Existe un modelo de datos relacional válido.
ISC-2003-1-25
37
Pre-condiciones: La aplicación contiene un modelo de datos relacional formal
Post- Condiciones: La generación de un scripts de creación de tablas para una base de
datos Oracle.
8.3 DIAGRAMA DE CLASES DE DISEÑO
A continuación se presenta el diagrama de diseño propuesto:
FIGURA 6. DIAGRAMA DE CLASE DE DISEÑO.
ISC-2003-1-25
38
8.4 DIAGRAMAS DE SECUENCIA
8.4.1 Creación del modelo orientado por objetos formal a partir de un diagrama de clases:
FIGURA 7. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DEL MODELO ORIENTADO POR OBJETOS.
ISC-2003-1-25
39
8.4.2 Creación del diagrama de datos relacional formal a partir del diagrama
orientado por objetos formal:
FIGURA 8. DIAGRAMA DE SECUENCIA DE LA CREACIÓN DEL DIAGRAMA DE DATOS RELACIONAL
FORMAL A PARTIR DEL DIAGRAMA DE ORIENTADO POR OBJETOS FORMAL.
8.4.5 Generación de los scripts de creación de tablas a partir de un modelo de datos
relacional formal:
FIGURA 9. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DE LOS SCRIPT DE CREACIÓN DE
TABLAS A PARTIR DE UN MODELO DE DATOS RELACIONAL FORMAL
ISC-2003-1-25
40
9 CONSIDERACIONES PARA EL USO DE LA APLICACIÓN
A continuación se presentan las consideraciones que se deben tener en cuenta al momento de
ejecutar la aplicación. Para ello, se definen las consideraciones iniciales, las cuales hacen
referencia al formato de los archivos, a los formatos de las cadenas de las multiplicidades y
nombres de los objetos en el diagrama de clases, y posteriormente un ejemplo de utilización de la
aplicación.
9.1 CONSIDERACIONES INICIALES
w El archivo generado por DIA debe estar comprimido con formato GZIP (esto lo realiza
automáticamente DIA v9.0), y con extensión *.dia. Por ejemplo: compras.dia, prueba.dia, etc.
w Los nombres de las clases y atributos en el diagrama de clases pueden contener espacios entre
ellos, ya que la aplicación, basada en el estándar SQL92 reemplaza el carácter ‘ ‘ (espacio)
por el carácter ‘_’. Por ejemplo: si se tiene una clase en el diagrama de clases llamada “el
curso”, en el modelo de datos relacional se llamará “el_curso”.
w La aplicación en ningún momento toma los nombre de los métodos definidos en el diagrama
de clases.
w Las multiplicidades deben ser definidas con el formato: [mult]..[mult], donde [mult] puede
tomar cualquier valor numérico o el carácter ‘*’. Por ejemplo: 0..1 ó 1..*.
9.2 CONSIDERACIONES PARA LO SCRIPTS DE CREACIÓN DE
TABLAS
w Los tipos de datos de los atributos de clases en el diagrama de clases, tales como int y String,
son trasladados a tipos de datos de tablas en la base de datos, como Integer y Varchar,
respectivamente. En el caso de Oracle Integer es un tipo de dato con 38 bytes, y en el caso de
Postgres de 8 bytes.
ISC-2003-1-25
41
9.3 EJEMPLO DE UTILIZACIÓN DE LA APLICACIÓN
Al ejecutar la aplicación se muestra la siguiente ventana:
FIGURA 10. VENTANA INICIAL DE LA APLICACIÓN.
Luego, se escoge la opción de abrir, la cual permite abrir el archivo que contiene el diagrama de
clases generado por DIA v9.0:
FIGURA 11. VENTANA PARA ABRIR EL DIAGRAMA DE CLASES.
Luego de realizar la lectura del diagrama de clases, se realizan una serie de pasos al interior de la
aplicación, los cuales realizan la traslación del diagrama de clases a un modelo orientado por
ISC-2003-1-25
42
objetos, del modelo orientado a objetos formal al modelo de datos relacional formal (Ver Anexo
1), y finalmente la generación de los scripts de creación de tablas a partir del modelo de datos
relacional formal.
Este es el resultado de la traslación del modelo de datos orientado por objetos al modelo de datos
relacional y a su vez a un script de creación de tablas:
FIGURA 12. VENTANA CON EL SCRIPT DE CREACIÓN DE TABLAS.
Finalmente se da la opción al usuario de guardar el script de creación de tablas en un archivo:
FIGURA 13. VENTANA PARA GUARDAR EL SCRIPT DE CREACIÓN DE TABLAS.
ISC-2003-1-25
43
9.4 CONSIDERACIONES PARA FUTUROS DESARROLLOS
Debido al alcance que posee el ciclo de desarrollo de proyecto de grado, no fue posible realizar el
desarrollo completo de todas las características que se consideraron deseables, para ser
implementadas en la aplicación desarrollada en este proyecto de grado, por ello se mencionan
algunos aspectos a tener en cuenta en el caso de que se decida continuar el desarrollo de la
aplicación propuesta en este proyecto de grado:
w Permitir la lectura de formatos adicionales de diagramas de clases, generados por otras
aplicaciones, tales como Together, Poseidón, Visio, etc.
w Adicionar un módulo de interfaz gráfica que permita visualizar el diagrama de clases que se
quiere realizar la traslación.
w Adicionar un módulo de interfaz gráfica que permita visualizar el diagrama de datos
relacionado que genera la aplicación. Adicionalmente, desarrollar un módulo que permita
realizar las modificaciones al diagrama de datos, y que el script de creación de tablas se
modifique automáticamente.
w Extender el rango de la sintaxis del script de generación de tablas, a otros sistemas
manejadores de bases de datos, y/o que se implementen nuevas funcionalidades en la
aplicación para el manejo de bases de datos.
ISC-2003-1-25
44
10 CONCLUSIONES
Se logró implementar una herramienta útil y práctica para el proceso de desarrollo de software,
con la intención de disminuir el tiempo y aumentar la eficiencia de dicho proceso, mediante la
generación de scripts de creación de tablas a partir de un diagrama de clases expresado en UML,
creado a partir de DIA v9.0.
La aplicación permite al usuario escoger el archivo donde se encuentra la aplicación generado por
DIA v9.0, realiza la traslación del diagrama de clases a un modelo orientado por objetos formal, y
a su vez, a un modelo de datos relacional formal. Finalmente se obtiene un script de creación de
tablas, que el usuario puede guardar en un archivo.
El script de creación de tablas generado por la aplicación está basado en el estándar SQL92, el
cual permite que este mismo script pueda ser ejecutado por cualquier sistema manejador de bases
de datos que haya sido desarrollado bajo el estándar SQL92, por ejemplo, oracle, postgres y
mysql.
Para ello, se debieron tener algunas consideraciones y restricciones, las cuales obedecen a los
tipos de datos que utilizan los diferentes sistemas manejadores de bases de datos, ya que todos
poseen diferentes implementaciones de los tipos de datos básicos. Para los tipos de datos que se
definen en el diagrama de clases como ”int” se utilizó “Integer”, y para el tipo de dato “String” se
utilizó “Varchar”.
Inicialmente, al momento de implementar la creación automática de los scripts de creación de
tablas se pensó que para el tipo de dato “Integer” en la base de datos se le debía definir el número
de dígitos, por ejemplo Integer(10), Integer(20), pero según en el estándar SQL92, el tipo de dato
“Integer” no se le debe definir el número de dígitos. Igualmente, se llegó a pensar que el tipo de
dato “Varchar2” estaba definido en el estándar SQL92, pero ocurrió que este tipo de dato sólo
está definido en el sistema manejador de bases de daos Oracle, razón por la cual se decidió
utilizar “Varchar”.
ISC-2003-1-25
45
Para las tablas que poseen más de una columna en la definición de la llave primaria, por ejemplo:
CONSTRAINT curso_pk PRIMARY KEY (curso_id, profesor_id)
Y en otra tabla se define una llave foránea, que hace referencia a una de las columnas que hacen
parte de la llave primaria, por ejemplo:
CONSTRAINT tiene_fk FOREIGN KEY curso (curso_id)
La columna curso_id debe definirse como UNIQUE para que pueda ser referenciada en la otra
tabla, por ejemplo:
curso_id INTEGER UNIQUE
Como resultado del proyecto de grado cursado, se desarrolló una aplicación que permite la
creación de script de creación de tablas a partir de un diagrama de clases, expresado en UML y
creado en DIA v9.0, la cual fue probada en los diferentes sistemas manejadores de bases de datos,
que son Oracle, Postgres y Mysql, y en los diferentes sistemas operativos Windows 95, 98, 200 y
XP.
ISC-2003-1-25
46
11 BIBLIOGRAFÍA
[1]. http://www.thoughtinc.com/index.html
[2]. http://www.objectmatter.com/
[3]. http://jakarta.apache.org/ojb/
[4]. Mapping Object Oriented Models into Relational Models: a formal approach, Luis Rio y
Pedro Ramos
[5]. Larman, Craig. “UML y Patrones, Introducción al Análisis y diseño orientado a objetos”.
Prentice Hall, Inc, Mexico, 1999.
[6] http://www.lysator.liu.se/~alla/dia/dia.html
ISC-2003-1-25
47
ANEXO 1. SECUENCIA DE EJECUCIÓN DE LA APLICACIÓN
A continuación se presenta la secuencia de ejecución que realiza la aplicación dado un diagrama
de clases, para la generación de scripts de creación de tablas.
FIGURA 14. DIAGRAMA DE CLASES EJEMPLO.
Secuencia:
Paso 1: Traslación de clases a tablas, y generación de las clases asociativas.
Tanto por cada clase definida en el diagrama de clase como por cada asociación de muchos a
muchos, se genera una tabla. Para el ejemplo:
profesor ();
ISC-2003-1-25
48
curso ();
estudiante ();
tiene ();
Paso 2: Traslación de los atributos de las clases a columnas de las tablas.
Por cada atributo que posee la clase se crea un nueva columna en la tabla, y se intenta realizar la
traslación de los tipos de datos del diagrama de clases a los tipos de datos de la base de datos. Si
ningún tipo de dato es definido, se le asigna “int” por defecto, y se traslada a “Integer”.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30));
curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30)); tiene ();
Paso 3: Creación de las llaves primarias de las tablas.
Por cada una de las tablas se define una columna que será llave primaria de la tabla.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30),
profesor_id:INTEGER PK);
curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK); estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK);
tiene (tiene_id:INTEGER PK);
Paso 4: Generación de los atributos de las tablas asociativas.
Para las tablas que son asociativas, se generan columnas adicionales de las tablas que se deben
asociar. Además, se definen las llaves foráneas para cumplir con las relaciones asociativas.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30),
profesor_id:INTEGER PK);
ISC-2003-1-25
49
curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK);
tiene (tiene_id:INTEGER PK, curso_id:INTEGER PK,
estudiante_id:INTEGER PK);
Llaves Foráneas
tiene_fk (curso, tiene, [curso_id:INTEGER PK])
tiene_1_fk (estudiante, tiene, [estudiante_id:INTEGER PK])
Paso 5: Traslación de las relaciones de asociación uno a muchos.
Para las asociaciones de uno a muchos se crea una nueva columna en las tablas poseen la que
corresponden a muchos, que corresponde a la llave primaria de la tabla uno.
En el ejemplo se observa como existe una relación de uno a muchos entre las clases profesor
(relación de uno) y curso (relación a muchos). Debido a esto, en la tabla curso se adiciona una
columna adicional profesor_id que corresponde a la llave primaria de la tabla profesor.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30),
profesor_id:INTEGER PK); curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK, profesor_id:INTEGER PK);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK);
tiene (tiene_id:INTEGER PK, curso_id:INTEGER PK,
estudiante_id:INTEGER PK);
Llaves foráneas
tiene_fk (curso, tiene, [curso_id:INTEGER PK])
tiene_1_fk (estudiante, tiene, [estudiante_id:INTEGER PK])
Es_dictado_fk (profesor, curso, [profesor_id:INTEGER PK])
ISC-2003-1-25
50
Paso 6: Traslación de las relaciones de Generalización.
Se realiza la traslación de las asociaciones de generalización, creando una nueva columna,
llegando a ser esta columna parte de la llave primaria de la tabla, en las tablas que son
especificación de una tabla generalización, creando sus respectivas llaves foráneas, para
conservar su relación. No aplicable para este ejemplo.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30),
profesor_id:INTEGER PK); curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK, profesor_id:INTEGER PK);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK);
tiene (tiene_id:INTEGER PK, curso_id:INTEGER PK,
estudiante_id:INTEGER PK);
Llaves foráneas
tiene_fk (curso, tiene, [curso_id:INTEGER PK])
tiene_1_fk (estudiante, tiene, [estudiante_id:INTEGER PK])
Es_dictado_fk (profesor, curso, [profesor_id:INTEGER PK])
Paso 7 : Traslación de las Relaciones de agregación
Se realiza la traslación de las asociaciones de agregación, creando una nueva columna en las
tablas que son parte de una tabla de agregación, creando sus respectivas llaves foráneas, para
conservar su relación.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30), profesor_id:INTEGER PK);
curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK, profesor_id:INTEGER PK);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK);
ISC-2003-1-25
51
tiene (tiene_id:INTEGER PK, curso_id:INTEGER PK,
estudiante_id:INTEGER PK);
Llaves Foráneas
tiene_fk (curso, tiene, [curso_id:INTEGER PK])
tiene_1_fk (estudiante, tiene, [estudiante_id:INTEGER PK])
Es_dictado_fk (profesor, curso, [profesor_id:INTEGER PK])
Paso 8: traslación de las relaciones de composición.
Se realiza la traslación de las asociaciones de composición, creando una nueva columna en las
tablas que son partes de una tabla todo, creando sus respectivas llaves foráneas, para conservar su
relación. No aplicable para este ejemplo.
profesor (nombre:VARCHAR(30), cedula:VARCHAR(30),
profesor_id:INTEGER PK);
curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER,
curso_id:INTEGER PK, profesor_id:INTEGER PK);
estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30),
cedula:VARCHAR(30), estudiante_id:INTEGER PK); tiene (tiene_id:INTEGER PK, curso_id:INTEGER PK,
estudiante_id:INTEGER PK);
Llaves foráneas
tiene_fk (curso, tiene, [curso_id:INTEGER PK])
tiene_1_fk (estudiante, tiene, [estudiante_id:INTEGER PK])
Es_dictado_fk (profesor, curso, [profesor_id:INTEGER PK])
ISC-2003-1-25
52
Como resultado de esta traslación se genera el siguiente script de creación de tablas:
CREATE TABLE profesor
( nombre VARCHAR(30),
cedula VARCHAR(30),
profesor_id INTEGER,
CONSTRAINT profesor_pk PRIMARY KEY (profesor_id)
);
CREATE TABLE curso
(
departamento INTEGER,
cupo INTEGER,
asignados INTEGER,
curso_id INTEGER UNIQUE,
profesor_id INTEGER, CONSTRAINT es_dictado_fk FOREIGN KEY profesor (profesor_id),
CONSTRAINT curso_pk PRIMARY KEY (curso_id, profesor_id)
);
CREATE TABLE estudiante
(
nombre VARCHAR(30),
codigo VARCHAR(30),
cedula VARCHAR(30),
estudiante_id INTEGER UNIQUE,
CONSTRAINT estudiante_pk PRIMARY KEY (estudiante_id)
);
CREATE TABLE tiene
(
tiene_id INTEGER,
ISC-2003-1-25
53
curso_id INTEGER,
estudiante_id INTEGER,
CONSTRAINT tiene_fk FOREIGN KEY curso (curso_id),
CONSTRAINT tiene_1_fk FOREIGN KEY estudiante (estudiante_id),
CONSTRAINT tiene_pk PRIMARY KEY (tiene_id, curso_id, estudiante_id)
);
