Transformación del Modelo Relacional en UML a XML

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Transformación del Modelo Relacional en UML a XML"

Transcripción

1 Transformación del Modelo Relacional en UML a XML Leonardo Rodríguez Daniel Perovich INCO - PEDECIBA Facultad de Ingeniería Universidad de la República Uruguay Enero 14, 2002 Resumen El proceso de integración de bases de datos heterogéneas requiere llevar los distintos esquemas a un modelo común que permita facilitar el proceso de integración. XML es un lenguaje estándar diseñado especialmente para describir la estructura de la información, convirtiéndolo en una alternativa interesante para representar dicho modelo común. El presente trabajo describe la estructura que debe tener un documento XML para representar un Esquema Relacional, partiendo de la especificación del mismo en UML. Para ello propone un mecanismo genérico para transformar un Diagrama de Estructura Estática de UML a un DTD el cual define la estructura de un documento XML que permite almacenar la información modelada por el diagrama. También presenta un mecanismo completamente automático para generar un DTD el cual representa las instancias de un Esquema Relacional particular. 1. Introducción Contexto El modelo relacional [4] desde sus comienzos se ha transformado en el principal modelo para la representación de la información almacenada en las bases de datos. Ofrece una forma clara y bien estructurada para representar la información a almacenar. Con el paso del tiempo las bases de datos han aumentado considerablemente su tamaño y plantean nuevos requerimientos, lo cual ha llevado a la aparición de estrategias para solucionar estos problemas. Una de estas estrategias es la integración de bases de datos, la cual se ha vuelto necesaria para resolver distintas realidades. La aparición de esta estrategia está motivada por la complejidad del diseño de bases de datos de dimensiones importantes, la cual es una tarea muy complicada para realizarse en forma centralizada. El utilizar una estrategia de integración plantea un enfoque más razonable, en el cual cada parte de la empresa desarrolla su propia vista de la base de datos, para luego integrar estas vistas en un esquema global [3]. El proceso de integración se divide en varias etapas, a saber, transformación al modelo canónico, identificación de correspondencias, conformación de esquemas, población de los esquemas homogéneos, y merge. El presente artículo ataca la primer etapa del proceso. La misma consiste en llevar todas las vistas que se van a integrar a un modelo canónico. Para representar el modelo canónico es necesario el uso de un lenguaje simple y genérico. Una interesante posibilidad es que XML (extensible Markup Language) [9] cumpla dicha función. XML es un lenguaje de tags diseñado especialmente para describir la estructura de la información. El presente artículo plantea dos objetivos principales. El primero consiste en la definición de la estructura que debe tener un documento XML para poder representar el Esquema Relacional canónico. El segundo objetivo consiste en resolver el caso particular de la conversión de Esquemas Relacionales a la representación canónica en XML de los mismos. Para definir la estructura de un documento XML se utiliza un DTD [2] (Document Type Definition). El DTD permite definir la estructura del documento dando una lista de los elementos legales que tiene un documento XML y las relaciones que existen entre ellos. 1

2 Para llegar al DTD deseado, se presenta un mecanismo general de transformación de Diagramas de Clase de UML [1, 7]. Una vez presentado el mecanismo de transformación, se aplica el mismo para generar el DTD correspondiente al Modelo Relacional. Para ello, consideramos como entrada del algoritmo el Diagrama de Clases en UML de un Modelo Relacional presentado en [6]. Estructura del artículo La Sección 2 presenta dos mecanismos para transformar un Diagrama de Clases de UML en un DTD. La Sección 3 presenta el Diagrama de Clases del Modelo Relacional, y aplica el mecanismo al mismo, de forma de construir el DTD buscado. La Sección 4 construye un DTD para una instancia del Esquema Relacional utilizando XSL (extensible Stylesheet Language) [10, 11]. Finalmente, la Sección 5 concluye. 2. Diagrama de Clases de UML a DTD La presente Sección introduce dos mecanismos generales para transformar un Diagrama de Clases de UML en un DTD que permita almacenar la información que el Diagrama de Clases modela. El primer mecanismo que se presenta genera como resultado un DTD con un alto grado de redundancia entre sus elementos. Sobre este primer mecanismo solamente se va a presentar el conjunto de reglas y los lineamientos generales del mismo. Por otro lado, el segundo mecanismo tiene como resultado un DTD en donde se utilizan apuntadores entre elementos, de forma de no incurrir en redefiniciones. Los casos considerados por estos mecanismos no son exhaustivos, ya que no analizan todos los elementos sintácticos de un Diagrama de Estructura Estática de UML. Se considera solamente las construcciones más características de éste Mecanismo de transformación con redundancia Este es un mecanismo simple, directo y rudimentario para transformar un Diagrama de Clases en UML a un DTD. El mismo se basa en un conjunto de reglas para transformar elementos del Diagrama de Clases a elementos de un DTD. El DTD generado por este mecanismo tiene la caracterísitca de presentar un alto grado de redefinición de elementos. Más concretamente, este mecanismo va a llevar a que cada clase del Diagrama de Clases se va a mapear a un elemento del DTD y este elemento va a ser definido un número de veces igual a la cantidad de clases que tengan navegabilidad sobre la clase correspondiente al elemento. Esta característica lleva, por un lado, a que la estructura del archivo XML sea fácil de leer y entender, pero por otro, tiene mucha redundancia de elementos lo cual también puede llevar a inconsistencias. A continuación se presenta el conjunto de reglas del mecanismo de transformación. El mismo consistiría en recorrer los elementos del Diagrama de Clases de UML y aplicar la o las reglas que más se adecúen al caso para construir el DTD. La Figura 2.1 presenta siete construcciones características en la estructura de un Diagrama de Clases de UML. Algunos elementos como las clases de asociación o la compocisión, entre otras, pueden ser representados basándose en las estructuras presentadas en la Figura 2.1. Regla 1 Conversión de una clase ClaseA y sus atributos. <!ELEMENT ClaseA (Atrib1, Atrib2)> Regla 2 Conversión de una asociación de multiplicidad 1. <!ELEMENT ClaseA (Atrib1, ClaseB)> 2

3 Figura 2.1: Estructuras de un Diagrama de Clases de UML Regla 3 Conversión de una asociación de multiplicidad <!ELEMENT ClaseA (Atrib1, ClaseB?)> Regla 4 Conversión de una asociación de multiplicidad 1..*. Para esta regla se plantean dos alternativas: 1) <!ELEMENT ClaseA (Atrib1, ClaseB+)> 2) <!ELEMENT ClaseA (Atrib1, ColB)> <!ELEMENT ColB (ClaseB+)> Regla 5 Conversión de una asociación de multiplicidad 0..*. Para esta regla se plantean dos alternativas: 1) <!ELEMENT ClaseA (Atrib1, ClaseB*)> 2) <!ELEMENT ClaseA (Atrib1, ColB)> <!ELEMENT ColB (ClaseB*)> Regla 6 Conversión de una asociación de multiplicidad 1 con una superclase y sus subclases. Al aplicar esta regla deben incluirse todas las clases que no sean abstractas. <!ELEMENT ClaseA (Atrib1, ClaseB ClaseC ClaseD)> <!ELEMENT ClaseC (Atrib2,Atrib3)> <!ELEMENT Atrib3 (#CDATA)> <!ELEMENT ClaseD (Atrib2,Atrib4)> <!ELEMENT Atrib4 (#CDATA)> Regla 7 Conversión de una asociación de multiplicidad 0..* con una superclase y sus subclases. Al aplicar esta regla deben incluirse todas las clases que no sean abstractas. <!ELEMENT ClaseA (Atrib1, ColB)> <!ELEMENT ColB (ClaseB ClaseC ClaseD)*> <!ELEMENT ClaseC (Atrib2,Atrib3)> <!ELEMENT Atrib3 (#CDATA)> <!ELEMENT ClaseD (Atrib2,Atrib4)> <!ELEMENT Atrib4 (#CDATA)> 3

4 Estas transformaciones exigen como entrada un Diagrama de Clases más que un Modelo Conceptual, dado que antes de aplicarla es necesario haber tomado algunas decisiones de diseño que en este último aún no están presentes. Por ejemplo, es necesario determinar la navegabilidad de las asociaciones, cuales son las colecciones que integran el diagrama, entre otras. Este mecanismo presenta problemas en casos en los cuales un elemento debe hacer referencia a otro, el cual no basta con la información del mismo para identificarlo (por ejemplo los atributos de una tabla, solo con la información del atributo propiamente no basta para identificar el elemento, es necesaria la información de la tabla a la que pertenece). Para solucionar este problema habría que incorporar información extra como un identificador que permita identificar de manera única estos elementos Mecanismo de transformación con apuntadores El mecanismo con apuntadores busca eliminar los problemas de redundancia de datos que presenta en el mecanismo anterior. Se logra este objetivo utilizando los atributos IDREF cuando se debe hacer referencia a elementos pertenecientes a una colección o cuando se refiere a elementos que ya fueron definidos en el DTD. En el Diagrama de Clases esto se puede ver en las clases que son navegables desde más de una clase. El parser XML, como parte del proceso de validación del documento, se encarga de chequear si para cada IDREF que se hace referencia existe un elemento correspondiente con un ID. El parser solo es capaz de chequear si existe el elemento, pero no puede chequear si el elemento es del tipo esperado. El mecanismo de transformación con apuntadores, al igual que el descrito en la Subsección anterior, también se basa en un conjunto de reglas para realizar la transformación. En este caso se muestra un algoritmo más elaborado y requiere un conjunto de pasos previos a realizar la transformación. Se presentan siete reglas, cada una correspondiente a una construcción de un Diagrama de Clases de UML presentados en la Figura 2.1. El conjunto de reglas en los que se basa el algoritmo se presenta a continuación. Regla 1 Conversión de una clase ClaseA y sus atributos. <!ELEMENT ClaseA (atrib1, atrib2)> <!ELEMENT atrib2 (#PCDATA)> Regla 2 Conversión de una asociación de multiplicidad 1. Si ClaseB no es navegable desde más de una clase <!ELEMENT ClaseA (atrib1, ClaseB) > Si ClaseB es navegable desde más de una clase Si pertenece a una colección <!ELEMENT ClaseA (atrib1,apclaseb)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> Si no pertenece a una colección Si no está definida, marcar el elemento ClaseB como que requiere ID 1. 1 El marcar un elemento como que requiere ID se realiza a los efectos de recordar que cuando se defina el elemento marcado, va a ser necesario definir el ID del mismo. 4

5 <!ELEMENT ClaseA (atrib1, ClaseB) > Si está definida <!ELEMENT ClaseA (atrib1,apclaseb)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> Regla 3 Conversión de una asociación de multiplicidad Si ClaseB no es navegable desde más de una clase <!ELEMENT ClaseA (atrib1, ClaseB?) > Si ClaseB es navegable desde más de una clase Si pertenece a una colección <!ELEMENT ClaseA (atrib1,apclaseb?)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> Si no pertenece a una colección Si no está definida, marcar ClaseB como que requiere ID <!ELEMENT ClaseA (atrib1, ClaseB?)> Si está definida <!ELEMENT ClaseA (atrib1,apclaseb?)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> Regla 4 Conversión de una asociación de multiplicidad 1..*. Si ClaseB pertenece a más de una colección, si aún no se determinó, hay que determinar qué colección es la que lleva los IDs 2 Si ésta es la colección que lleva los IDs, se debe marcar ClaseB como que requiere ID. <!ELEMENT ClaseA (atrib1,colclaseb)> <!ELEMENT colclaseb (ClaseB+)> Si ésta no es la colección que lleva los IDs <!ELEMENT ClaseA (atrib1,colclaseb)> <!ELEMENT colclaseb (apclaseb+)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> 2 La colección que lleva los IDs se le llama a la colección que va a tener efectivamente los elementos dentro, es una colección de elementos no una colección de apuntadores a elementos. Si hay más de una colección de elementos, solo una colección puede ser la que lleva los IDs. 5

6 Regla 5 Conversión de una asociación de multiplicidad 0..*. Si ClaseB pertenece a más de una colección, si aún no se determinó, hay que determinar qué colección es la que lleva los IDs Si ésta es la colección que lleva los IDs, marcar la ClaseB como que requiere ID. <!ELEMENT ClaseA (atrib1,colclaseb)> <!ELEMENT colclaseb (ClaseB*)> Si ésta no es la colección que lleva los IDs <!ELEMENT ClaseA (atrib1,colclaseb)> <!ELEMENT colclaseb (apclaseb*)> <!ELEMENT apclaseb EMPTY> <!ATTLIST apclaseb point IDREF #REQUIRED> Regla 6 Conversión de una asociación de multiplicidad 1 con una superclase y sus subclases. Si la clase ClaseB no es navegable por más de una clase <!ELEMENT ClaseA (atrib1,(claseb ClaseC ClaseD))> Si la clase ClaseB es navegable por más de una clase Si pertenece a una colección <!ELEMENT ClaseA (atrib1,apclasebcd)> Si no está definido apclasebcd, entonces: <!ELEMENT apclasebcd EMPTY> <!ATTLIST apclasebcd point IDREF #REQUIRED> Si no pertenece a una colección Si no está definido, marcar ClaseB, ClaseC y ClaseD como que requieren ID. <!ELEMENT ClaseA(atrib1,(ClaseB ClaseC ClaseD))> Si está definido <!ELEMENT ClaseA(atrib1,apClaseBCD)> <!ELEMENT apclasebcd EMPTY> <!ATTLIST apclasebcd point IDREF #REQUIRED> Regla 7 Conversión de una asociación de multiplicidad 0..* con una superclase y sus subclases. Si ClaseB pertenece a más de una colección, si aún no se determinó, hay que determinar qué colección es la que lleva los IDs Si ésta es la colección que lleva los IDs, marcar ClaseB, ClaseC y ClaseD como que requieren ID <!ELEMENT ClaseA (atrib1,colclasebcd)> <!ELEMENT colclasebcd (ClaseB ClaseC ClaseD)*> 6

7 Si ésta no es la colección que lleva los IDs <!ELEMENT ClaseA (atrib1,colclasebcd)> <!ELEMENT colclaseb (apclasebcd*)> Si no está definido apclasebcd, entonces: <!ELEMENT apclasebcd EMPTY> <!ATTLIST apclasebcd point IDREF #REQUIRED> Este mecanismo requiere seguir un determinado orden al momento de aplicar las reglas antes descritas a las distintas clases del Diagrama de Clases. Se utiliza una tabla auxiliar con cuatro columnas, cuyos compenentes son: Nombre: Contiene el nombre de las clases del Diagrama de Clases. Grado de Entrada: El grado de entrada de una clase del diagrama es la cantidad de clases que tienen navegabilidad hacia ella. Requiere Id: Tiene SIen el caso que se llegó a la conclusión de que esta clase requiere un ID propio y NOen el caso que no se requiera un ID. Procesada: A medida que se van procesando las clases, se van marcando como procesadas. El mecanismo debe pasar por un proceso de inicialización en donde se debe construir la tabla con los nombres de todas las clases del Diagrama de Clases y sus grados de entrada calculados. Las clases abstractas se marcan como procesadas desde un principio. Terminado el proceso de inicialización se comienza a procesar las clases, aplicando las reglas de transformación. El orden y la forma en que se van procesando las clases es el siguiente: 1. Procesar las colecciones principales, i.e. las colecciones en las cuales se definen los elementos de las mismas, no simplemente se hace referencia a ellos. Considere el siguiente ejemplo: si se está modelando una biblioteca, la colección de libros es una colección principal por ser en la que se definen los libros; en cambio la colección de libros asociada a un préstamo no lo es dado que ésta hace referencia a los libros que la otra define. Estas colecciones se procesan según su grado de entrada, comenzando por la de menor grado y continuando en orden ascendente. Se aplica la o las reglas que mejor se adecúen. Si la colección a procesar esta marcada como que requiere ID, tiene un grado de entrada mayor igual a 2 o es el elemento de una colección, se debe agregar un ID al elemento que representa la colección. Luego de aplicar la regla o las reglas apropiadas, marcamos el elemento como procesado y pasamos a la siguiente colección. De no haber más colecciones principales, pasamos al paso Una vez que se procesaron todas las colecciones principales, quedan un conjunto determinado de clases sin procesar. Nuevamente, se ordenan estas clases de menor a mayor según el grado de entrada de las mismas y se pasa a procesar una a una, buscando la o las reglas que mejor se adapten al caso. Cada vez que se procesa una clase nueva, ésta se marca como procesada. El mecanismo termina cuando todas las clases quedaron marcadas como procesadas y el resultado es un DTD que nos permite mantener la información representada por el Diagrama de Clases Limitaciones propias del pasaje a DTD El realizar este tipo de transformación lleva a que se pierda parte de la información disponible en el Diagrama de Clases ya que el DTD no es capaz de reflejarla. Un claro ejemplo de ello son las restricciones OCL [5, 8] establecidas sobre el Diagrama de Clases, las cuales generalmente no va a ser posible reflejarlas con el DTD. Tampoco es posible reflejar conceptos como la herencia, ya que el DTD no brinda herramientas para su representación. 7

8 Figura 3.2: Diagrama de Clases del Modelo Relacional 3. Construcción del DTD para el Modelo Relacional La presente Sección introduce la construcción del DTD para representar un Esquema Relacional. El Diagrama de Clases del Modelo Relacional puede encontrarse en [6]. La Figura 3.2 presenta una versión simplificada del Diagrama de Clases allí planteado. Se aplicará el mecanismo de transformación con apuntadores introducido en la Subsección 2.2 para generar el DTD apartir del diagrama Construcción del DTD Inicio Se construye la tabla auxiliar como se presentada a continuación. Nombre Grado de entrada Requiere ID Procesada DatabaseSchema 0 RelationSchema 1 Constraint 1 PrimaryKey 1 Unique 1 ForeignKey 1 NotNull 1 Domain 2 Attribute 6 Paso 1 Las colecciones principales que hay en el Modelo Relacional son: DataBaseSchema-Constraint, DataBaseSchema-RelationSchema, DataBaseSchema-Domain y RelationSchema-Attribute. Considerando los grados de entrada de las clases que tienen las colecciones, se comienza por DataBaseSchema, la cual tiene grado 0. Ésta no tiene grado mayor o igual a 2 y no es parte de una colección, por lo cual no requiere de un ID. Aplicando las reglas: 5 (Domain), 5 (RelationSchema) y 7 (Constraint) obtenemos: <!ELEMENT DatabaseSchema (namedatabaseschema, RelationSchemas, Constraints, Domains)> <!ELEMENT RelationSchemas (RelationSchema*)> Se marca RelationSchema como que requiere un ID. <!ELEMENT Constraints (PrimaryKey Unique ForeignKey NotNull)*> Se marca a PrimaryKey, Unique, ForeignKey y NotNull como que requieren ID. 8

9 <!ELEMENT Domains (Domain*)> Se marca Domain como que requiere ID. Se marca como procesada la clase DataBaseSchema. <!ELEMENT namedatabaseschema (#PCDATA)> Hasta el momento se procesaron las tres primeras colecciones, ahora resta para terminar el primer paso procesar la cuarta y última colección. RelationSchema está marcada como que requiere un ID, por lo cual se le debe agregar un ID en el momento de la construcción. Aplicando la regla 4 obtenemos: <!ELEMENT RelationSchema (namerelationschema, Attributes)> <!ATTLIST RelationSchema id ID #REQUIRED> <!ELEMENT Attributes (Attribute+)> Se marca Attribute como que requiere ID, aparte se marca como procesada RelationSchema. <!ELEMENT namerelationschema (#PCDATA)> Así se termina de procesar las colecciones principales y concluye el primer paso de la transformación. Se muestra a continuación el estado de la tabla auxiliar al final del primer paso. Nombre Grado de entrada Requiere ID Procesada DatabaseSchema 0 RelationSchema 1 SI Constraint 1 SI PrimaryKey 1 SI Unique 1 SI ForeignKey 1 SI NotNull 1 SI Domain 2 SI Attribute 6 SI Paso 2 Se procede a procesar el resto de las clases del diagrama. Éstas también se van a procesar de menor a mayor según el grado de entrada de la clase. Las clases PrimaryKey, Unique, ForeignKey y Domain tienen todas grado 1. De forma arbitraria se comienza por PrimaryKey. La misma está marcada como que requiere un ID, el cual se debe agregar después de aplicar la regla. Aplicando la regla 4 se obtiene: <!ELEMENT PrimaryKey (nameconstraint, apattributes)> <!ATTLIST PrimaryKey id ID #REQUIRED> <!ELEMENT nameconstraint (#PCDATA)> <!ELEMENT apattributes (apattribute+)> <!ELEMENT apattribute EMPTY> <!ATTLIST apattribute id IDREF #REQUIRED> Se marca PrimaryKey como procesada y se continúa con la clase Unique. Esta última es análoga a PrimaryKey. <!ELEMENT Unique (nameconstraint, apattributes)> <!ATTLIST Unique id ID #REQUIRED> Notar que los elementos nameconstraint y apattributes ya están definidos por lo cual no es necesario volver a hacerlo. Se marca Unique como procesada. La siguiente es ForeignKey la cual de forma similar aplicando la regla 4 en dos oportunidades se obtiene: <!ELEMENT ForeignKey (nameconstraint, apattributes,apattributes)> <!ATTLIST ForeignKey id ID #REQUIRED> Se marca ForeignKey como procesada. La siguiente es NotNull a la cual se le aplica la regla 2 y se obtiene: 9

10 <!ELEMENT NotNull (nameconstraint, apattribute)> <!ATTLIST NotNull id ID #REQUIRED> Notar que apattribute ya está definido por lo cual no es necesario hacerlo. Siguiendo con el orden por grado, ahora debe ser procesado Domain la cual tiene grado 2. Ésta esta marcada como que requiere ID por lo cual se le va a agregar después de aplicar la regla correspondiente. De la aplicación de la regla 1 se obtiene: <!ELEMENT Domain (DomainName, DomainDescription, DomainDatatype, DomainFormat)> <!ATTLIST Domain id ID #REQUIRED> <!ELEMENT DomainName (#PCDATA)> <!ELEMENT DomainDescription (#PCDATA)> <!ELEMENT DomainDatatype (#PCDATA)> <!ELEMENT DomainFormat (#PCDATA)> Se marca Domain como procesada. La última clase que resta por procesar es Attribute la cual tiene grado de entrada 6. Ésta también está marcada como que requiere ID y se va a aplicar la regla 1, de la cual se obtiene: <!ELEMENT Attribute (nameattribute, apdomain)> <!ATTLIST Attribute id ID #REQUIRED> <!ELEMENT nameattribute (#PCDATA)> <!ELEMENT apdomain EMPTY> <!ATTLIST apdomain id IDREF #REQUIRED> Marcando Attribute como procesada tendríamos todas las clases procesadas, por lo cual culmina el proceso de transformación. El estado de la tabla auxiliar al final del proceso de transformación es como el de la Figura 3.1 donde todas las clases estan marcadas como procesadas. Finalmente, reuniendo todas las definiciones que se fueron generando a través de todo el proceso obtenemos el siguiente DTD: <!ELEMENT DatabaseSchema (namedatabaseschema, RelationSchemas, Constraints, Domains)> <!ELEMENT RelationSchemas (RelationSchema*)> <!ELEMENT Constraints (PrimaryKey Unique ForeignKey NotNull)*> <!ELEMENT Domains (Domain*)> <!ELEMENT namedatabaseschema (#PCDATA)> <!ELEMENT RelationSchema (namerelationschema, Attributes)> <!ATTLIST RelationSchema id ID #REQUIRED> <!ELEMENT Attributes (Attribute+)> <!ELEMENT namerelationschema (#PCDATA)> <!ELEMENT PrimaryKey (nameconstraint, apattributes)> <!ATTLIST PrimaryKey id ID #REQUIRED> <!ELEMENT nameconstraint (#PCDATA)> <!ELEMENT apattributes (apattribute+)> <!ELEMENT apattribute EMPTY> <!ATTLIST apattribute id IDREF #REQUIRED> <!ELEMENT Unique (nameconstraint, apattributes)> <!ATTLIST Unique id ID #REQUIRED> <!ELEMENT ForeignKey (nameconstraint, apattributes,apattributes)> <!ATTLIST ForeignKey id ID #REQUIRED> <!ELEMENT NotNull (nameconstraint, apattribute)> <!ATTLIST NotNull id ID #REQUIRED> <!ELEMENT Domain (DomainName, DomainDescription, DomainDatatype, DomainFormat)> <!ATTLIST Domain id ID #REQUIRED> <!ELEMENT DomainName (#PCDATA)> <!ELEMENT DomainDescription (#PCDATA)> <!ELEMENT DomainDatatype (#PCDATA)> <!ELEMENT DomainFormat (#PCDATA)> <!ELEMENT Attribute (nameattribute, apdomain)> <!ATTLIST Attribute id ID #REQUIRED> <!ELEMENT nameattribute (#PCDATA)> <!ELEMENT apdomain EMPTY> <!ATTLIST apdomain id IDREF #REQUIRED> 4. Construcción de un DTD para la instancia del MR En la Sección 3 se presentó un DTD que permite definir la estructura que debe de tener un documento XML para representar el Esquema Relacional. El mismo permite definir las tablas que 10

11 componen un determinado esquema relacional y las restricciones de integridad que existen entre ellas. Por otro lado también es necesario contar con un documento XML que permita representar la información propiamente que se almacena dentro del mismo (la instancia del Esquema Relacional). Esta Sección define el DTD necesario para representar una instancia de un Esquema Relacional. Este DTD es propio de cada base de datos, depende de las tablas y restricciones que existan en cada base de datos puntualmente. Por ello, para construir este DTD es necesario partir del documento XML que define la estructura de esquema relacional, documento generado a partir del DTD presentado en la Sección 3. Para construir este DTD, se introduce un mecanismo simple y automático que se basa en XSL. XSL es un lenguaje que permite transformar documentos XML en otros documentos. En este caso lo utilizaremos para transformar el documento XML que define un Esquema Relacional en un DTD necesario para representar la instancia del Esquema Relacional. El documento XSL encargado de realizar la transformación es: <?xml version= 1.0?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/xsl/transform" version="1.0"> <xsl:template match="databaseschema"> <!-- Tables of the Relational Schema --> <!ELEMENT Tablas ( <xsl:for-each select="relationschemas/relationschema"> <xsl:if test="position()!= last()"> <xsl:value-of select="namerelationschema"/>, </xsl:if> <xsl:if test="position() = last()"> <xsl:value-of select="namerelationschema"/>)> </xsl:if> </xsl:for-each> <xsl:for-each select="relationschemas/relationschema"> <!ELEMENT <xsl:value-of select="namerelationschema"/> (Tupla_<xsl:value-of select="namerelationschema"/>*)> </xsl:for-each> <xsl:for-each select="relationschemas/relationschema"> <!ELEMENT Tupla_<xsl:value-of select="namerelationschema"/> ( <xsl:variable name="nomtabla" select="namerelationschema"/> <xsl:for-each select="attributes/attribute"> <xsl:value-of select="$nomtabla"/>_<xsl:value-of select="nameattribute"/> <xsl:variable name="idatributo" <xsl:choose> <xsl:when test= = $idatributo > </xsl:when> <xsl:when test= = $idatributo > </xsl:when> <xsl:otherwise> <xsl:text>?</xsl:text> </xsl:otherwise> </xsl:choose> <xsl:if test="position()!= last()"> <xsl:text>, </xsl:text> </xsl:if> <xsl:if test="position() = last()"> <xsl:text>)></xsl:text> </xsl:if> </xsl:for-each> </xsl:for-each> <xsl:for-each select="relationschemas/relationschema"> <xsl:variable name="nomtabla" select="namerelationschema"/> <xsl:for-each select="attributes/attribute"> <!ELEMENT <xsl:value-of select="$nomtabla"/>_<xsl:value-of select="nameattribute"/> (#PCDATA)> </xsl:for-each> </xsl:for-each> </xsl:template> </xsl:stylesheet> 11

12 5. Conclusiones Conclusiones XML presenta una alternativa muy interesante para la representación del modelo canónico requerido para la integración de bases de datos. Se presentaron dos mecanismos para la generación de definición de documentos XML a partir de UML. Estos mecanismos no son exhaustivos dado que no abarcan todas las construcciones presentes en un modelo. Sin embargo, las reglas presentadas fueron suficientes para su aplicación sobre el modelo conceptual en UML del Modelo Relacional. Mediante la aplicación de uno de estos mecanismos se logró la definición de un DTD para representar un Esquema Relacional y se aprovechó las ventajas de la herramienta XSL de forma de generar automáticamente un documento DTD que define la estructura de un documento con una instancia de un esquema de base de datos. No se debe confundir lo presentado en este artículo con lo que define XMI (XML Metadata Interchange). XMI permite el intercambio de metadatos (e.g. datos estructurados describiendo modelos orientados a objetos) entre herramientas de modelado basados en UML mediante la representación de la estructura de los diagramas propiamente. Sin embargo, no permite la representación en XML de la información que los diagramas definen, esto es lo desarrollado en el presenta artículo. Trabajo Futuro El presente artículo se enmarca en un proyecto más ambicioso que busca la especificación de un componente de software general, sobre el cual desarrollar herramientas que asistan al proceso de integración de bases de datos. Este componente de software estará basado en el modelo presentado en [6], el cual fue utilizado aquí en la transformación del modelo relacional a XML. El trabajo futuro incluye la creación del proxy que implemente la especificación del componente mencionado antes, utilizando XML como repositorio de la información. Asímismo se estudiarán las herramientas relacionadas de forma de simplificar el desarrollo de dicho proxy. También es de interés el desarrollo de los mecanismos presentados para incorporar todas las construcciones sintácticas de los Diagramas de Estructura Estática de UML. Referencias [1] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, [2] DTD Tutorial. [3] A. Elmagarmid, M. Rusinkiewicz, and A. Sheth. Management of Heterogeneous and Autonomous Database Systems. Morgan Kauffman Publishers, [4] Ramez Elmasri and Shamkant B. Navathe. Fundamentals of Database Systems. Benjamin/Cummings Publishers, [5] Object Management Group. Object Constraint Language Specification, March [6] Daniel Perovich and Leonardo Rodríguez. Especificación en uml del modelo relacional. Technical report, INCO - PEDECIBA, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay, [7] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, [8] Jos Warmer and Anneke Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, Reading, MA, USA, [9] XML Tutorial. [10] XSL Tutorial. [11] XSL Tutorial. 12

Transformación de documentos XML con

Transformación de documentos XML con Transformación de documentos XML con X S L T Necesidad de las transformaciones XML se presenta como un estándar para transmitir datos a través de Internet. Ante la posibilidad de que distintos centros

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Tema IV. XML. VI. XSL (XPath & XSLT) Desarrollo de Aplicaciones para Internet Curso 12 13

Tema IV. XML. VI. XSL (XPath & XSLT) Desarrollo de Aplicaciones para Internet Curso 12 13 Tema IV. XML VI. XSL (XPath & XSLT) Desarrollo de Aplicaciones para Internet Curso 12 13 Índice 1.Introducción 2.XPath i. Introducción ii. Rutas y Expresiones 1. Nodos 2. Ejes 3. Predicados iii.tipos de

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

Bases de Datos XML 1 XML. Jorge Pérez Rojas Universidad de Talca, II Semestre 2006

Bases de Datos XML 1 XML. Jorge Pérez Rojas Universidad de Talca, II Semestre 2006 Bases de Datos XML 1 XML Jorge Pérez Rojas Universidad de Talca, II Semestre 2006 Bases de Datos XML 2 Motivación Web Semántica: La Web se ha convertido en un gran repositorio de información. La info en

Más detalles

Agenda XML XML XML XML XML. 1.1 Conceptos básicos de XML. 1.2 Ejemplos de lenguajes basados en XML. 1.3 Estructura de un documento XML

Agenda XML XML XML XML XML. 1.1 Conceptos básicos de XML. 1.2 Ejemplos de lenguajes basados en XML. 1.3 Estructura de un documento XML Agenda 1.1 Conceptos básicos de 1.2 Ejemplos de lenguajes basados en M.C. Juan Carlos Olivares Rojas 1.3 Estructura de un documento 1.4 Tecnologías extensible Markup Language (Lenguaje de Marcado extensible)

Más detalles

Transformación documentos XML. Jose Emilio Labra Gayo Departamento de Informática Universidad de Oviedo

Transformación documentos XML. Jose Emilio Labra Gayo Departamento de Informática Universidad de Oviedo Transformación documentos XML Jose Emilio Labra Gayo Departamento de Informática Universidad de Oviedo Hojas de estilos para XML Antecedentes SGML tenía DSSSL (Document Style Semantics and Specification

Más detalles

Enterprise Architect y UML Basic

Enterprise Architect y UML Basic Enterprise Architect y UML Basic Diciembre 2008 Carlos Alexander Zuluaga Agenda Presentación del curso. Introducción a Enterprise Architect. Exploración del modelo de ejemplo. Introducción a UML. Definición

Más detalles

Metodología de Diseño para Gestión de Procesos Documentales (MDPD)

Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Aquilino A. Juan Fuente Profesor de la Universidad de Oviedo aquilino@lsi.uniovi.es Juan Manuel Cueva Lovelle Catedrático de Escuela de

Más detalles

PONTIFICIA UNIVERSIDAD JAVERIANA ANEXO 6: DOCUMENTACIÓN OBJETOS VIRTUALES DE APRENDIZAJE CREADOS Y SUS CORRESPONDIENTES ESPECIFICACIONES

PONTIFICIA UNIVERSIDAD JAVERIANA ANEXO 6: DOCUMENTACIÓN OBJETOS VIRTUALES DE APRENDIZAJE CREADOS Y SUS CORRESPONDIENTES ESPECIFICACIONES PONTIFICIA UNIVERSIDAD JAVERIANA ANEXO 6: DOCUMENTACIÓN OBJETOS VIRTUALES DE APRENDIZAJE CREADOS Y SUS CORRESPONDIENTES ESPECIFICACIONES ANGELICA MARIA VERGARA GRANADOS PONTIFICIA UNIVERSIDAD JAVERIANA

Más detalles

Topicos Avanzados de Bases de Datos en la Web

Topicos Avanzados de Bases de Datos en la Web Topicos Avanzados de Bases de Datos en la Web Introducción a XML Profesor: Alejandro Vaisman 1er. Cuatrimestre, 2007 4/16/2007 1 XML XML es el lenguaje estándar para intercambiar información en la Web.

Más detalles

Hojas de Estilos XSLT en el aula. Nieves Carralero Colmenar I.E.S Ramón y Cajal. Albacete ncarralero@jccm.es

Hojas de Estilos XSLT en el aula. Nieves Carralero Colmenar I.E.S Ramón y Cajal. Albacete ncarralero@jccm.es Hojas de Estilos XSLT en el aula Nieves Carralero Colmenar I.E.S Ramón y Cajal. Albacete ncarralero@jccm.es Resumen Según la Orden EDU/2887/2010, de 2 de noviembre, por la que se establece el currículo

Más detalles

extensible Markup Language (XML)

extensible Markup Language (XML) extensible Markup Language (XML) 1. INTRODUCCIÓN Jennifer Pérez Benedí Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia C/Camino de Vera s/n E-46071 Valencia- España

Más detalles

Análisis y Diseño de Sistemas de

Análisis y Diseño de Sistemas de Análisis y Diseño de Sistemas de Información para Internet 1. Introducción a XML Luís Rodríguez Baena (luis.rodriguez@upsam.net) Universidad Pontificia de Salamanca (campus Madrid) Facultad de Informática

Más detalles

"Módulo OOWS para StarUML" INTRODUCCIÓN

Módulo OOWS para StarUML INTRODUCCIÓN UNA HERRAMIENTA PARA DIAGRAMAS OOWS: "Módulo OOWS para StarUML" Richard Medina Z. Universidad de Concepción, Chile INTRODUCCIÓN Una herramienta CASE (Computer Aided Software Engineering,

Más detalles

rg.o cm a Diseñ e o o c o c n o ce c p e tual l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Diseñ e o o c o c n o ce c p e tual l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Diseño conceptual Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos 5. Modelo de datos

Más detalles

XSL: extensible Style Language. Anabel Fraga

XSL: extensible Style Language. Anabel Fraga XSL: extensible Style Language Anabel Fraga 1 Tabla de Contenidos La Familia XML Presentación en XML XSL XSLT Elementos XSL-FO Referencias 2 3 La Familia XML Presentación en XML La presentación en HTML

Más detalles

Primeros pasos con XML y XSL Ricardo Borillo Domenech

Primeros pasos con XML y XSL Ricardo Borillo Domenech Primeros pasos con XML y XSL Ricardo Borillo Domenech Table of Contents 1.Apartadosprincipales...1 2. Introducción al lenguaje de marcas XML... 2 3. Estructura de los documentos: DTDs... 2 3.1. Asociar

Más detalles

XML práctico Bases esenciales, conceptos y casos prácticos (2ª edición)

XML práctico Bases esenciales, conceptos y casos prácticos (2ª edición) Introducción al lenguaje XML 1. De SGML a XML 17 2. Los conceptos básicos del XML 18 2.1 Recordatorio sobre el HTML 18 2.2 Creación de un primer documento XML 19 2.3 Las ventajas del XML 21 3. La sintaxis

Más detalles

Diagramas de clases de UML

Diagramas de clases de UML Qué es UML? UML ( Unified Modeling Language ) es un lenguaje visual para crear modelos de sistemas. Diagramas de clases de UML Franco Guidi Polanco Escuela de Ingeniería Industrial Pontificia Universidad

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Notación UML para modelado Orientado a Objetos

Notación UML para modelado Orientado a Objetos 1 Notación UML para modelado Orientado a Objetos 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación Orientada a Objetos?3

Más detalles

Transformación de documentos : XSLT

Transformación de documentos : XSLT Transformación de documentos : XSLT XSL : Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar cómo debería estar estructurado el contenido, cómo debería ser diseñado el contenido

Más detalles

Asignaturas, profesores, alumnos. Profesores, grupos, asignaturas, aulas

Asignaturas, profesores, alumnos. Profesores, grupos, asignaturas, aulas Introducción a las bases de datos Fundamentos de diseño de bases de datos Introducción a las bases de datos Organización lógica de los datos Sistemas basados en archivos Concepto intuitivo de base de datos

Más detalles

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b El ciclo de vida de un sistema de información El ciclo de vida de un sistema de información El proceso de desarrollo de software Modelos de ciclo de vida El ciclo de vida de una base de datos El proceso

Más detalles

Arquitectura Básica CÍCLOPE CMS

Arquitectura Básica CÍCLOPE CMS Arquitectura Básica CÍCLOPE CMS Introducción. Arquitectura Colaborativa. El diseño de la arquitectura documental de CÍCLOPE CMS permite crear y administrar documentos electrónicos y mantenerlos disponibles

Más detalles

Apéndice 1. DMOF Y MOF 2

Apéndice 1. DMOF Y MOF 2 Apéndice C DMOF y MOF 1. DMOF Y MOF 2 PROCESO DE DESARROLLO PARA GENERAR REPOSITORIOS DE META DATA BASADOS EN MOF. 2 DMOF IMPLEMENTA LOS MAPEOS POSIBLES DE MOF 5 MOF IDL MAPPING 5 MOF XMI MAPPING 7 UN

Más detalles

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107 I. DATOS INFORMATIVOS Carrera Especialidad Curso Código Ciclo : Tercero Requisitos Duración Horas Semana : 06 horas Versión : v.0110 II. SUMILLA: : COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Gestión de Bases de Datos Gestión de Bases de Datos Base de datos una colección de datos relacionados organizados de manera de

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Modelado de datos. Bibliografía. Representación de la información Modelos de datos Modelado semántico

Modelado de datos. Bibliografía. Representación de la información Modelos de datos Modelado semántico Modelado de datos Representación de la información Modelos de datos Modelado semántico El modelo entidad/relación Elementos: Entidades, atributos, claves y relaciones Representación gráfica: Diagramas

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

Curso de Java POO: Programación orientada a objetos

Curso de Java POO: Programación orientada a objetos Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos

Más detalles

Ingeniería de Programa(s) Educativo(s): Software. Clave de la materia: IS201. UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H

Ingeniería de Programa(s) Educativo(s): Software. Clave de la materia: IS201. UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU007H Clave: 08USU4053W FACULTAD DE INGENIERÍA PROGRAMA DEL CURSO: INGENIERÍA DE SOFTWARE Y COMPUTACIÓN II DES: Ingeniería Ingeniería de Programa(s) Educativo(s):

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

Generación de código para Hibernate desde modelos UML

Generación de código para Hibernate desde modelos UML Generación de código para Hibernate desde modelos UML Alejandro Nogueiro Mariscal Ingeniería Técnica en Informática de Sistemas, Universidad de Cádiz 24 de Septiembre 2012 1 / 35 Índice 1 Motivación y

Más detalles

TEMA 35: Estándares SGML y XML. Entornos de aplicación.

TEMA 35: Estándares SGML y XML. Entornos de aplicación. Entornos de aplicación TEMA 35: Estándares SGML y. Entornos de aplicación. Índice 1 INTRODUCCIÓN 1 2 SGML 2 2.1 Cómo funciona SGML? 2 2.2 Definición de la sintaxis de un lenguaje SGML 3 2.3 Declaración

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

rg.o cm a Diseñ e o o l óg ó ico c l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s s r e r la l c a i c o i nal a e l s

rg.o cm a Diseñ e o o l óg ó ico c l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s s r e r la l c a i c o i nal a e l s Diseño lógico Diseño de bases de datos relacionales Diseño lógico de bases de datos relacionales El modelo relacional: El concepto de relación: tuplas, atributos y dominios. Restricciones de integridad

Más detalles

procesamientodedatosconjava modalidadteleformación 210horas completamentegratuito

procesamientodedatosconjava modalidadteleformación 210horas completamentegratuito curso: procesamientodedatosconjava modalidadteleformación 210horas completamentegratuito +información a/a Zully Montelongo Teléfono: 91 532 93 65 Móvil: 696 42 95 89 Correo electrónico: fcontinua3@viaformacion.com

Más detalles

Documentación Electrónica

Documentación Electrónica Modelado de datos: Document Type Definition (DTD) Ofimática Avanzada Curso 2010/2011 Ofimática Avanzada 2010/2011 2 Ofimática Avanzada 2010/2011 3 1 Introducción XML es flexible, permitiendo a los usuarios

Más detalles

Sistema de consulta de Indicadores de calidad del aire en ciudades mexicanas

Sistema de consulta de Indicadores de calidad del aire en ciudades mexicanas MATÍAS S O F T W A R E G R O U P Sistema de consulta de Indicadores de calidad del aire en ciudades mexicanas REPORTE FINAL Asesoría a cargo de: Dirección General de Investigación sobre la Contaminación

Más detalles

Tema 4 Metadatos. Eduardo Martínez Graciá Humberto Martínez Barberá

Tema 4 Metadatos. Eduardo Martínez Graciá Humberto Martínez Barberá Tema 4 Metadatos Eduardo Martínez Graciá Humberto Martínez Barberá Departamento de Ingeniería de la Información y las Comunicaciones Universidad de Murcia Metadatos Definición: datos sobre datos Fichero:

Más detalles

BASES DE DATOS, MODELOS DE DATOS Y DBMS

BASES DE DATOS, MODELOS DE DATOS Y DBMS BASES DE DATOS, MODELOS DE DATOS Y DBMS Maestría en Bioinformática Marzo 2010 Bases de Datos Algunas definiciones: Bases de Datos y DBMS Procesos y Actores Involucrados Por qué usar DBMSs? Cuándo no usar

Más detalles

INTRODUCCION. entidades. Modelo lógico de la base de datos. Matricula. carne. codigo_curso. año semestre nota. propiedades

INTRODUCCION. entidades. Modelo lógico de la base de datos. Matricula. carne. codigo_curso. año semestre nota. propiedades INTRODUCCION Uno de los objetivos del curso es modelar a través de un diagrama las estructuras lógicas requeridas para almacenar los datos y resolver las consultas del sistema información que requiera

Más detalles

DISEÑO BASE DE DATOS I. Propósito del Curso : Al final del curso el estudiante: Ingeniería Ingeniería en Sistemas. Hardware. Clave de la materia: 643

DISEÑO BASE DE DATOS I. Propósito del Curso : Al final del curso el estudiante: Ingeniería Ingeniería en Sistemas. Hardware. Clave de la materia: 643 UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H Clave: 08USU4053W FACULTAD DE INGENIERÍA PROGRAMA DEL CURSO: DISEÑO I DES: Ingeniería Ingeniería en Sistemas Programa(s) Educativo(s): Computacionales

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

Diagrama de actividad

Diagrama de actividad Diagrama de actividad Se utiliza para representar los procedimientos o secuencia de pasos dentro de procedimientos, procesos o flujo de información. Contenido Generalidades de un diagrama de actividad...

Más detalles

Resumen. El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl

Resumen. El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl Resumen demandas de almacenamiento y procesamiento de datos. Es el conjunto de estas dos capacidades

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

1 Introducción a XML

1 Introducción a XML 1 Introducción a XML Introducción (I)! Qué es XML?! Últimamente todo el mundo habla sobre XML!! Dicen que es un lenguaje etiquetado...es decir: Es un lenguaje como HTML, pero con nuevas etiquetas?! Dicen

Más detalles

IIC3432 - Tópicos Avanzados en Bases de Datos. Una introducción a XML

IIC3432 - Tópicos Avanzados en Bases de Datos. Una introducción a XML IIC3432 - Tópicos Avanzados en Bases de Datos Una introducción a XML Documentos versus Bases de Datos Documentos estáticos estructura implícita semi-estructurados fácil de entender para una persona importa:

Más detalles

Introducción a XML - Validación y Parseo. Huibert Aalbers, Senior Certified Software IT Architect

Introducción a XML - Validación y Parseo. Huibert Aalbers, Senior Certified Software IT Architect Introducción a XML - Validación y Parseo Huibert Aalbers, Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast a través de

Más detalles

Práctica de introducción a

Práctica de introducción a Práctica de introducción a XML El trabajo consiste en una introducción al uso del lenguaje XML y su aplicación en documentos y sistemas de caracteristicas multimedia. 1.- Qué es XML? XML (extensible Markup

Más detalles

Introducción a XML. Taller de Producción de Software 2º Semestre 2008 H.Astudillo / P.Inostroza

Introducción a XML. Taller de Producción de Software 2º Semestre 2008 H.Astudillo / P.Inostroza Taller de Producción de Software 2005 Introducción a XML Taller de Producción de Software 2º Semestre 2008 H.Astudillo / P.Inostroza Indice Qué es XML? Breve Historia de XML Anatomía de un Documento XML

Más detalles

ACCESS 2010 OFIMÁTICA AULA MENTOR

ACCESS 2010 OFIMÁTICA AULA MENTOR ACCESS 2010 OFIMÁTICA AULA MENTOR Módulo I: Introducción UNIDADES DIDÁCTICAS: 1. Unidad didáctica 1 2 Introducción a las Bases de Datos 2. Unidad didáctica 2 10 Comenzar a trabajar con Access Página 1

Más detalles

XML, DTD y hojas de estilo

XML, DTD y hojas de estilo XML, DTD y hojas de estilo Introducción XML existe porque HTML ha tenido mucho éxito. Pero con objeto de corresponder a este éxito, se le ha extendido introduciéndose muchas etiquetas nuevas (más de 100

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

XML Schema. Sergio Luján Mora. sergio.lujan@ua.es http://gplsi.dlsi.ua.es/~slujan/

XML Schema. Sergio Luján Mora. sergio.lujan@ua.es http://gplsi.dlsi.ua.es/~slujan/ XML Schema Sergio Luján Mora sergio.lujan@ua.es http://gplsi.dlsi.ua.es/~slujan/ 1 XML SCHEMA... 3 Introducción... 3 Ventajas... 3 Qué necesito para usar XML Schema... 4 Diseño de un documento XML... 5

Más detalles

Desarrollo de una Base de Datos Nativa XML

Desarrollo de una Base de Datos Nativa XML Desarrollo de una Base de Datos Nativa XML Luis Fernando Espino Barrios Instituto Tecnológico de Costa Rica luisespino@yahoo.com Noviembre 2009 Resumen: En este artículo se tratan elementos conceptuales

Más detalles

Diagrama de casos de uso

Diagrama de casos de uso Diagrama de casos de uso Se utiliza para capturar los requerimientos funcionales de un sistema, de tal forma que plasman las relaciones entre los usuarios y el sistema. Contenido Pasos de construcción

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Unidad 4: XSLT y XPATH. JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012

Unidad 4: XSLT y XPATH. JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012 Unidad 4: XSLT y XPATH JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012 Guíon del tema Qué es XSLT? Aplicación de las transformaciones Estructura

Más detalles

Unidad 6: DTD. JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012

Unidad 6: DTD. JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012 Unidad 6: DTD JJ Taboada León IES San Sebastián, Departamento de Informática LENGUAJE DE MARCAS Y SGI Curso 2011 / 2012 Guíon del tema Qué es un DTD? Declaración de DTD Declaración de Elementos Declaración

Más detalles

Validación de un XML

Validación de un XML Validación de un XML 32 Introducción Se dice que un XML está bien formado cuando esta escrito sintácticamente de forma correcta Como se puede validar sintácticamente un XML? Document Type Definition (DTD)

Más detalles

Unidad 1. Introducción a los conceptos de Bases de Datos

Unidad 1. Introducción a los conceptos de Bases de Datos Unidad 1 Introducción a los conceptos de Bases de Datos 1.1 Definición de Base de Datos Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o alfanuméricos. Información:

Más detalles

Mantenimiento de bases de datos alimentadas con páginas web

Mantenimiento de bases de datos alimentadas con páginas web Maestría en Informática PEDECIBA Mantenimiento de bases de datos alimentadas con páginas web Autor: Miriam Steiner Tutor: Dr. Alejandro Gutiérrez Facultad de Ingeniería, Universidad de la República Montevideo,

Más detalles

extensible Markup Language

extensible Markup Language extensible Markup Language ISLN ISLN () XML 1 / 26 Librería LWP::Simple Bajarse el archivo de internet Para bajar archivos de internet se puede usar alguno de los módulos del CPAN http://search.cpan.org

Más detalles

PREGUNTAS TIPO (EXAMEN DE OFIMÁTICA AVANZADA)

PREGUNTAS TIPO (EXAMEN DE OFIMÁTICA AVANZADA) PREGUNTAS TIPO (EXAMEN DE OFIMÁTICA AVANZADA) El examen constará de 2 partes. Se evaluará sobre 10 puntos y representará el 60% de la nota final de la asignatura. Para que la calificación en esta prueba

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Bases de Datos 3º Informática de Sistemas

Bases de Datos 3º Informática de Sistemas TEMA 2.- EL SISTEMA GESTOR DE BASES DE DATOS. Concepto y Funciones del SGBD. Lenguajes de los SGBD. Niveles de Abstracción. Arquitectura ANSI/SPARC. Componentes del SGBD. 1. Concepto y Funciones del SGBD.

Más detalles

umodelfactory: software para modelado de sistemas embebidos

umodelfactory: software para modelado de sistemas embebidos umodelfactory: software para modelado de sistemas embebidos L. Sugezky, N. González, Y. Kuo, M. Prieto, P. D Angelo, M. Trujillo, M. Giura, J. Cruz Departamento de Ingeniería Electrónica Facultad Regional

Más detalles

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

UNIVERSITAT OBERTA DE CATALUNYA. Capa de persistencia en.net.

UNIVERSITAT OBERTA DE CATALUNYA. Capa de persistencia en.net. UNIVERSITAT OBERTA DE CATALUNYA Capa de persistencia en.net. Alumno: FERNANDO CUTILLAS TERUEL. ETIS. Dirigido por: DAVID GAÑÁN JIMÉNEZ. 18/06/2004 Resumen. En este proyecto de final de carrera se ha implementado

Más detalles

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Ing. Marcela Daniele AC. Daniel Romero Dpto. de Computación. Facultad: Ciencias Exactas,

Más detalles

Patrones para persistencia (I) Ingeniería del Software II

Patrones para persistencia (I) Ingeniería del Software II Patrones para persistencia (I) Ingeniería del Software II 1 Patrones para la construcción del esquema relacional En todos los ejemplos realizaremos transformaciones del siguiente diagrama de clases: Figura

Más detalles

Perfil UML para el desarrollo de aplicaciones WAP

Perfil UML para el desarrollo de aplicaciones WAP Perfil UML para el desarrollo de aplicaciones WAP Ricardo Soto D., Mauricio Camara J. Escuela de Ingeniería Informática, Pontificia Universidad Católica de Valparaíso, Chile E-mail: ricardo.soto@ucv.cl,

Más detalles

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS Dámaso López Aragón Introducción En la actualidad, la orientación a objetos es una nueva forma de comprender los problemas y modelar el negocio de una empresa,

Más detalles

Microsoft SQL Server Conceptos.

Microsoft SQL Server Conceptos. Microsoft Conceptos. Microsoft 2005 es una plataforma de base de datos a gran escala de procesamiento de transacciones en línea (OLTP) y de procesamiento analítico en línea (OLAP). La siguiente tabla muestra

Más detalles

Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos.

Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos. Definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos. Autora: MSc. Martha D. Delgado Dapena. Centro de Estudios de Ingeniería de Sistemas. e-mail: marta@ceis.ispjae.edu.cu

Más detalles

Secretaría de Docencia Dirección de Estudios Profesionales

Secretaría de Docencia Dirección de Estudios Profesionales PROGRAMA DE ESTUDIO POR COMPETENCIAS BASES DE DATOS AVANZADAS I. IDENTIFICACIÓN DEL CURSO Espacio Educativo: Facultad de Ingeniería Licenciatura: Área de docencia: Tratamiento de la Información Año de

Más detalles

11. Seguridad en sistemas de bases de datos

11. Seguridad en sistemas de bases de datos 11. Seguridad en sistemas de bases de datos Objetivos Comprender la necesidad de controlar el acceso a la información almacenada por parte de usuarios no autorizados Conocer las posibilidades que puede

Más detalles

Visualización y Transformaciones en XML

Visualización y Transformaciones en XML Visualización y Transformaciones en XML 106 Visualización Los archivos XLM pueden ser vistos prácticamente en cualquier browser 107 Visualización Los XML en los web browsers no se despliegan como páginas

Más detalles

Desarrollo de un Administrador de Base de Datos Relacional TecnoDB

Desarrollo de un Administrador de Base de Datos Relacional TecnoDB Desarrollo de un Administrador de Base de Datos Relacional TecnoDB Autores: Iris Gastañaga Ing. en Sistemas de Información y Especialista en Docencia Universitaria, Investigadora Categoría III. Teléfono:

Más detalles

Fundamentos de Sistemas Multimedia. Práctica Documentos estructurados y publicación electrónica. XML y XSLT

Fundamentos de Sistemas Multimedia. Práctica Documentos estructurados y publicación electrónica. XML y XSLT Fundamentos de Sistemas Multimedia Práctica Documentos estructurados y publicación electrónica. XML y XSLT Manuel Agustí, Félix Buendía, Jose V. Benlloch y Vicente Atienza Curso 2008 / 2009 1 1 Presentación

Más detalles

Proyecto de Normalización Automática de Base de Datos

Proyecto de Normalización Automática de Base de Datos Proyecto de Normalización Automática de Base de Datos Lic. Beatriz Steimberg * Resumen En el primer cuatrimestre del año 2003 se encaró el proyecto de Normalización Automática de Base de Datos. El objetivo

Más detalles

UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H. Clave: 08USU4053W FACULTAD DE INGENIERÍA PROGRAMA DEL CURSO: BASES DE DATOS II

UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H. Clave: 08USU4053W FACULTAD DE INGENIERÍA PROGRAMA DEL CURSO: BASES DE DATOS II UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU007H Clave: 08USU4053W FACULTAD DE INGENIERÍA PROGRAMA DEL CURSO: BASES DE DATOS II DES: Programa(s) Educativo(s): Tipo de materia: Clave de la materia: Semestre:

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

Metodologías para generación de Sistemas Orientados a Objetos

Metodologías para generación de Sistemas Orientados a Objetos Metodologías para generación de Sistemas Orientados a Objetos Análisis y Diseño (Tecnologías) Orientado a Objetos Dr. Leopoldo Altamirano Robles 22 septiembre, 2003 Alicia Morales Reyes Alma Rosa Rugerio

Más detalles

XML. María Consuelo Franky. Universidad Javeriana 2009

XML. María Consuelo Franky. Universidad Javeriana 2009 XML María Consuelo Franky Universidad Javeriana 2009 1 XML: meta-lenguaje para definir lenguajes de etiquetas 2 Origen de XML SGML: Standard Generalized Markup Language: demasiado complejo para definir

Más detalles

Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO

Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS270T. Bases de Datos I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1 CARRERA

Más detalles