• No se han encontrado resultados

Caso B: Desarrollo de una BD (Objeto-)Relacional

In document Universidad Rey Juan Carlos (página 53-58)

3.2 Proceso

3.2.2 MIDAS/DB

3.2.2.3.2 Caso B: Desarrollo de una BD (Objeto-)Relacional

En este supuesto, se realizará el diseño de la BD partiendo de cero. Además, se desea tener una BD (objeto-)relacional que se integrará con el hipertexto en XML, extrayendo los datos dinámicamente para construir las páginas Web. Este caso es especialmente adecuado cuando la BD tiene otros usos además de la publicación de su información en las páginas Web, por ejemplo, una BD corporativa que incluye la gestión de empleados, la contabilidad de la empresa, etc. En este

caso, no toda la información almacenada en la BD tiene que estar accesible desde las páginas Web. Si el volumen de información es grande, también es más recomendable la utilización de tecnología más implantada.

La Figura 9 muestra el proceso de desarrollo de la BD Web para este caso. Como se observa, las tareas de diseño lógico de la BD y del hipertexto se realizan en paralelo y la implementación se hace de modo independiente.

MIDAS/DB MIDAS/HT Implementacion Diseño Análisis Páginas WEB estáticas en HTML Diseño Coneptual Refinado de Datos Diseño Lógico del Hipertexto Diseño Conceptual Refinado del Hipertexto Diseño Lógico BD (OR) Implementación BD (SQL) Implemen-tación Hipertexto BDOR Páginas WEB Dinámicas en XML Integración BD-XML

Figura 9. Proceso de desarrollo para el desarrollo de una BD OR Web

La Tabla 4 resume las tareas a realizar durante las actividades de análisis, diseño e implementación de la iteración MIDAS/DB para desarrollar una BD Web en el caso B.

Tabla 4. Actividades para la iteración MIDAS/DB (casos A y B)

Fase: Base de Datos Web (MIDAS/DB)

Actividad Tarea Técnica Notación

Análisis Diseño Conceptual Refinado Modelos Conceptuales UML

Diseño

Diseño Lógico de los Datos Diseño Lógico de Consultas

Diseño Lógico del Hipertexto Refinado

Modelo (Objeto-) Relacional Modelo Lógico de Consultas Modelo Lógico de Fragmentos

(RMM) Modelo Lógico Navegacional

(RMM) Diagrama OR (MIDAS/DB-UML) Diagrama de Consultas (MIDAS/DB-UML) XML Schema (MIDAS-UML) XLink (MIDAS-UML) Implemen. Implementación BD Implementación Hipertexto + Implementación Refinada de la Interfaz de Usuario Integración XML-SQL

SQL del Producto Concreto Tecnología XML: XML/XML Schema/ XLink/XSL

JSP/ASP/…

Diseño e Implementación de la BD

El desarrollo de la BD Web propone tres fases: análisis, diseño e implementación. La Figura 10 muestra el detalle de la tarea de diseño de la BD que se definirá partiendo del modelo conceptual de datos refinado, obtenido durante la actividad de análisis de esta iteración.

La fase de diseño de la BD se divide en dos pasos:

o Diseño Lógico Estándar, es decir, el diseño lógico independiente de

cualquier producto.

o Diseño Lógico Específico, es decir, el diseño para un producto específico (por ejemplo, Oracle8i u Oracle9i), sin considerar en este punto aspectos de optimización.

MIDAS/DB

BDOR

Análisis Diseño Implementación

Diseño Coneptual Refinado de Datos (Diagrama de Clases UML)

Diseño Lógico BD (OR)

Implementación BD (SQL) Diseño Lógico Estándar (UML + Estereotipos SQL:1999) Diseño Lógico Específico (UML + Estereotipos Producto) Diseño Coneptual de Consultas Diseño Lógico de Consultas Implementación de Consultas

Figura 10. Diseño de Bases de Datos (Objeto-)Relacionales

El diseño lógico estándar es especialmente importante en el proceso de diseño de una base de datos (objeto-)relacionales porque cada producto implementa un modelo objeto-relacional diferente. Esta actividad proporciona una especificación (objeto-)relacional en SQL: 1999, que es independiente de producto, mejorando el mantenimiento de la base de datos y facilitando la migración entre productos. Se proponen dos técnicas alternativas: la definición del esquema en lenguaje SQL: 1999; y la utilización de un lenguaje que permita describir el esquema (objeto-)relacional estándar del SQL:1999 en notación gráfica. Esta notación gráfica se correspondería con el grafo relacional que representa el diseño lógico en el caso del tradicional diseño de bases de datos relacionales. Como notación gráfica se propone la utilización de las extensiones de UML definidas en el apartado 3.3.1.2.1 y resumidas en el apéndice B. Las dos notaciones, textual en SQL y gráfica en UML, son equivalentes; ambas representan un esquema (objeto-) relacional en SQL: 1999 y, por tanto, independiente de producto.

En el diseño lógico específico (etapa intermedia entre el diseño y la implementación) debe especificarse el esquema en el lenguaje SQL específico del producto elegido, que en nuestro caso es Oracle8i y 9i. Además, se propone de forma opcional el uso de una técnica gráfica que mejore la documentación y la comprensión del código SQL generado. Esta técnica, además, facilita la compilación del esquema de la BD mostrando el orden apropiado en el que deben compilarse los

nuevos tipos definidos por el usuario, así como las tablas. La notación gráfica propuesta es también UML, sustituyendo los estereotipos definidos para SQL: 1999 por los estereotipos para el producto elegido. En el apartado 3.3.1.2.2 se propone una extensión para Oracle (versiones 8i y 9i).

Finalmente, la fase de implementación incluye las tareas de diseño físico. En esta fase, el esquema obtenido en la fase anterior se refinará, realizando un ajuste que mejore los tiempos de respuesta y el espacio de almacenamiento, de acuerdo con las necesidades específicas de la aplicación.

Además, en esta actividad, se propone también realizar el diseño lógico de consultas. Si el diseño conceptual de consultas es una consulta al modelo conceptual de datos, el diseño lógico es una consulta al diseño lógico de datos; es decir, al modelo (objeto-)relacional de la BD. Para ello se propone, al igual que para el modelado conceptual de consultas, utilizar notación UML. El modelo lógico de consultas será pues una consulta (expresada en UML) al modelo lógico de datos. En el apartado 3.3.1.2 se presenta la extensión propuesta para el modelado de consultas en UML, y en el apartado 3.3.1.4 el modo en que estas modelos se integran con el modelo de hipertexto.

Diseño e Implementación del Hipertexto

El diseño el hipertexto incluye dos técnicas: el modelo de fragmentos y el modelo de navegación. Para construir el modelo lógico del hipertexto, se partirá de los modelos conceptuales de hipertexto refinados, incluyendo el de fragmentos y el de navegación. Los fragmentos se representan a nivel lógico con esquemas XML (W3C, 2001b) y los modelos de fragmentos y de navegación con XLink (W3C, 2001a). Como para todas las demás técnicas, se propone UML como notación, tanto para los XML esquemas, como para el XLink. Las correspondientes extensiones se describen en los apartados 3.3.2.2 y 3.3.2.4, respectivamente. Para hacer la transición desde el nivel conceptual al nivel lógico del hipertexto, cada uno de los fragmentos del diagrama de fragmentos se transforma en un esquema XML y los enlaces entre los fragmentos que aparecen en los diagramas de fragmentos y de navegación, se transforman usando XLink. En el apartado 3.3.2.5 se definen también unas guías básicas para la transformación entre modelos.

La implementación final incluye la implementación del hipertexto utilizando tecnología XML y su integración con la BD mediante tecnologías como ASP, JSP, etc. Los documentos XML obtenidos pueden almacenarse en un repositorio de XML

nativo, o bien, en un sistema de ficheros tradicional. Para finalizar (en la etapa de pruebas), se realizarían las pruebas del funcionamiento final de la BD Web.

Aplicando la correspondiente plantilla XSL a los documentos XML obtenidos, se obtendrán las páginas HTML (o WML, etc.) con la información recuperada dinámicamente de la BD.

In document Universidad Rey Juan Carlos (página 53-58)