1. Evolución e Historia de las BDs 2. BDOO: Motivación

1. Evolución e Historia de las BDs 2. BDOO: Motivación
Índice 1. Evolución e Historia de las BDs 2. BDOO: Motivación 3. SGBDOO vs. SGBD de tercera generación 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3ª generación 3.3. Productos y estándares 3.4. Convergencia 4. Características de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD Persistencia Concurrencia Procesamiento de consultas ad-hoc Seguridad y control de acceso Otras

BREVE HISTORIA de las BDs
Sistemas de archivos (1950s) Se conservan los datos después de que el proceso que los creó deja de existir BDs Jerárquicas y de Red (1960s) Concurrencia, Recuperación, rápido acceso, estructuras complejas, etc. BDs Relacionales ( s) Mayor confiabilidad, menor redundancia, más flexibilidad, manejo de vistas, etc. ODBMS (1990s) Manejo de tipos de datos complejos, más relaciones (agregación, especialización), un mismo lenguaje p/ BD y programación, manejo de versiones, no es necesario “reconstruir” objetos, reusabilidad, etc.

Evolución de la tecnología de BD: Dimensiones
FUNCIONALIDAD/ INTELIGENCIA BD Activas BD Temporales BD Deductivas BD Seguras BD OO BD OR … RENDIMIENTO BD Distribuidas Multi BD BD Federadas BDweb BD Móviles … BD BD Paralelas BD en Memoria Principal BD Grid BD en Tiempo Real … DISTRIBUCIÓN/ INTEGRACIÓN

1. Evolución e Historia… 1960 Primeros productos de bases de datos
Estándar Codasyl (Modelo de Red) Modelo Relacional Prototipos SGBDR Trabajos teóricos relacionales Los tres niveles de la arquitectura (ANSI) Modelo E/R Primeros productos relacionales del mercado Arquitectura cliente/servidor de 2 capas Bases de datos distribuidas Estándares SQL (ANSI/ISO) Herramientas CASE Manifiesto sobre bases de datos orientadas a objetos Manifiesto sobre la 3ra generación de Bases de datos Primeros productos de bases de objeto Modelos de referencia (ISO/ANSI) SQL 92 (Revisión mayor) Consorcio ODMG (Estándares OO) Almacenes de datos SQL:1999 (expres. regulares, consultas recursivas) Arquitectura Cliente/Servidor en tres capas Modelo Objeto-Relacional Bases de datos multimedia Bases de datos móviles SQL/MM (texto, espacial, imagen, minería de datos) Bases de datos XML, SQL: 2003 (XML)

Standard CODASYL Modelo Relacional Modelo E-R SQL:1999 ODMG 1.0
Hierarchical Network Relational Object-Oriented Object-Relational Semi-Structured XML Modelo Relacional Standard CODASYL SQL Modelo E-R SQL-86 ODMG 1.0 SQL:1999 ODMG 3.0 1. Evolución e Historia… ver>>>

Base de Datos Orientadas a Objetos (BDOO)
Orígenes OOPLs. tienen sus raices en el lenguaje SIMULA el cual fue introducido a finales de la decada de los 60. SIMULA es una extensión de ALGOL 60. Sin embargo, el primer lenguaje que popularizó la aproximación a objetos fue Smalltalk (1976); este puede considerarse una síntesis de Lisp y de Simula. En los años 80, aparecen numerosos lenguajes OO inspirados en Simula o Smalltalk. Los más célebres, entre los compilados, son C++ y Objective C. La mayoría de los lenguajes OO interpretados son extensiones del Lisp; por ejemplo, Loops y Clos Base de Datos Orientadas a Objetos (BDOO)

Orígenes BDOO Base de Datos Orientadas a Objetos (BDOO) El concepto de O.O. se vino a relacionar con las bases de datos a mediados de los 80, el termino "object-oriented database system" apareció por primera vez en el año 1985

Primeros sistemas… …principio de los 1980s
1. Evolución e historia… Primeros sistemas… …principio de los 1980s Won Kim en Microelectronics and Computer Technology Corporation (MCC) inicia el proyecto ORION. Dos productos surgen luego ITASCA y Versant. …final de los 1980s – 1ros productos comerciales. “Graphael”, un sistema basado en Lisp, aparece en Francia, de él surge luego Matisse. Servo-Logic comienza a trabajar en GemStone (ahora Servo-Logic es GemStone Systems). Se inicia el desarrollo de O2 (en INRIA –Francia). El fundador de O2 es Francois Bencilhon. Tom Atwood de Ontologic produce Vbase, luego Ontologic se convierte en ONTOS, y Vbase es re-escrito para soportar C++. Tom Atwood funda luego Object Design con ObjectStore (basado en C++). Otro producto de aquel tiempo es Objectivity/DB.

Buscando establecer un estandar…
1. Evolución e historia… Buscando establecer un estandar… The OODBMS Manifesto (ATKINSON ) Manifiesto de los Sistemas de Bases de Datos OO puras. Enfoque purista que sostiene que los SGBDOO deben soportar un modelo de objetos puros y no basarse en extensiones semánticas de modelos clásicos como el relacional. 1990 -Third Generation Database System Manifesto (STONEBRAKER) Considera: 1ra generación de BD son jerárquica y Red; 2da generación es Relacional y para la 3ra generación (“omite” mencionarla como OO) establece una serie de proposiciones y principios. La idea básica es que los SGBD de 3ra generación deberían mantener las ventajas del modelo relacional, especialmente su DML no procedural, por lo tanto propone SGBD Relacionales extendidos que sean capaces de soportar los conceptos de orientación a objeto. Postura que comparten los principales vendedores de productos relacionales. ODMG Rick Cattell inicia el ODMG con 5 vendedores de OODBMS. El primer estandar ODMG-93 surge en Durante los 90s, el ODMG trabaja con el comité X3H2 (SQL) en un lenguaje query común. Aunque no logran el objetivo, sus esfuerzos tuvieron influencia en OQL (object query language).

Buscando establecer un estandar…
1. Evolución e historia… Buscando establecer un estandar… El Tercer Manifiesto (DARWEN y DATE) Es un documento más formal que los otros 2 manifiestos. Reinterpreta el modelo relacional bajo una visión orientada a objetos. Propone un lenguaje D con algunas ventajas de la OO como son los tipos de datos definidos por el usuario y la herencia, manteniendo el fundamento teórico del modelo relacional. No se trata de una extensión del lenguaje SQL(opinan que SQL no es adecuado como base para el futuro lenguaje). Según el manifiesto, tal lenguaje D, debe estar sujeto a una serie de prescripciones, proscripciones y lo que denomina “sugerencias muy fuertes” que divide en dos categorías: • Las que surgen del Modelo Relacional (RM) • Las que no surgen del Modelo de Objetos (OM) 2001 – Aparición del estandar ODMG 3.0 El estandar ODMG 3.0 en liberado. Poco después el grupo ODMG da las bases para la especificación de Java Data Objects (JDO) y luego el grupo se disuelve.

1. Evolución e historia … Historia reciente… 2004 – El Advenimiento del código abierto (Open Source) db4o es liberado como ODBMS de “código abierto”. Para Noviembre de 2005, db4o es el primero en soportar Queries “nativos” (Native Queries). Posee una librería que trabaja directamente con objetos y permite realizar consultas usando lenguajes de programación (Java/C#). No obstante existen en el mercado los llamados ORM (Object-Relational Mapping) para pasar las acciones que se realizan sobre objetos (guardar, leer, consultar, etc.) a su correspondiente secuencia SQL. Un ORM de los más conocidos en el mercado es Hibernate (“Hibernate mapea a los objetos con tablas del mundo relacional”). Otros productos “open source” son, por ejemplo, EyeDB, NeoDatis ODB, Ozone, Perst, Zope (ZODB)

Productos comerciales recientes (listado parcial)
Db4objects: versión comercial de db4o Objectivity/DB: Maneja BDs localizadas, centralizadas o distribuidas mediante una arquitectura de software escalable de procesamiento distribuido SOA (Arquitectura Orientada a Servicios) ObjectStore: Es un ODBMS (SGBDOO “Puro”) que anuncia solidez y alta performance para aplicaciones en ambientes empresariales. Versant Object Database: Es un ODBMS (SGBDOO “Puro”) que maneja objetos complejos modelados en java y C++, ofrece alta performance, escalabilidad, alta concurrencia, etc. ObjectDB: Es una Base de Datos java pura, ObjectDB está escrita enteramente en java y cumple con el estandar JDO (Java Data Objects). Se ofrece como compacta, rápida y fácil de usar. Maneja BDs, desde unos pocos KBs hasta cientos de GBs. Trabaja tanto en modo embebido como en modo cliente-servidor. 1. Evolución e historia…

Productos comerciales recientes (continuación..)
GemStone: Es un SGBDOO “Puro” que ofrece las características propias de un ODBMS y extiende algunas de ellas para abordar la persistencia de objetos de manera diferente a las BDs tradicionales. Los objetos no son aplanados o serializados, sino que se almacenan como un todo. Matisse 8: Una base de datos .NET Matisse 8 es una BD Post-Relational que ofrece “lo mejor de dos mundos”. Tiene la capacidad de mapear objetos desde .NET directamente a la base de datos, soporta lenguaje query estandar (SQL-99) y la escalabilidad de los productos relacionales. …Airbus usa Matisse en el diseño de componentes de aviación. Otros productos y prototipos que podemos agregar a este “listado parcial” son: ORION, OpenOODB , IRIS, ONTOS de Ontologic, O2 , ObjectDB etc. Respecto a las relacionales, todas (Oracle, IBM DB2, Informix, PostgreSQL, etc.) están cubriendo, en mayor o menor grado, aspectos de SGBD OR. 1. Evolución e historia…

¿Porqué surgen las BDOO?
BDOO: Motivación ¿Porqué surgen las BDOO? 1. Por necesidades de los lenguajes de programación OO 2. Por las limitaciones de las BD relacionales

1. Por necesidades de los lenguajes de programación OO …
BDOO: Motivación 1. Por necesidades de los lenguajes de programación OO … Las BD pueden proporcionar a los OOPLs: PERSISTENCIA DE OBJETOS (los objetos sobreviven a la ejecución del proceso que los creó) Eficiente almacenamiento y gestión de datos en memoria secundaria Independencia de los datos respecto de los programas Lenguaje de consulta eficiente y de alto nivel (independiente de la estructura física) Gestión de transacciones que permita: acceso concurrente, integridad, seguridad y recuperación ante fallos, Control de integridad (mediante restricciones, disparadores, etc.) 6

2. Las limitaciones de las BD relacionales...
BDOO: Motivación 2. Las limitaciones de las BD relacionales... Estructuras muy simples (1FN) Poca riqueza semántica No soportan tipos definidos por el usuario (sólo dominios) No soportan recursividad Falta de procedimientos/disparadores No admiten herencia Si se quieren almacenar datos alfanuméricos de pacientes, por ej., sus datos personales, historial de enfermedades, tratamientos recibidos, y resultados de exámenes de sangre, el esquema conceptual se puede implementar eficientemente en un RDBMS. Sin embargo, si la historia médica incluye imágenes de resonancia magnética, video de alguna cirugía, fotos del paciente, etc., el modelo relacional es completamente inconveniente, pues no tiene estructura ni operaciones apropiadas para manejar esos datos. Existen muchas aplicaciones con necesidades similares a la aplicación descrita, por ejemplo, las de CAD/CAM, los sistemas de información geográficos, las bases de datos multimedia, etc. Características Inadecuadas Para Aplicaciones Complejas

Necesidades de las nuevas aplicaciones:
BDOO: Motivación Necesidades de las nuevas aplicaciones: ►Soporte de objetos complejos y datos multimedia ►Identificadores únicos ►Soporte de referencias e interrelaciones ►Manipulación navegacional y de conjunto de registros ►Jerarquías de objetos y herencia ►Integración de los datos y procedimientos asociados ►Modelos extensibles mediante TD definidos por el usuario ►Gestión de versiones ►Facilidades de evolución ►Transacciones de larga duración ►Interconexión e interoperabilidad El conjunto de tipos predefinidos del sistema de BD debe ser Extensible, permitiendo definir tipos nuevos. No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos

Lenguaje de Programación
SGBDOO vs. SGBD de tercera generación... Lenguaje de Programación Orientado a Objetos Persistencia Base de Datos Orientada a Objetos Base de Datos Relacional Orientación a Objetos Objeto - Relacional

• Los Sistemas de Bases de Datos Orientadas a Objetos soportan un modelo de objetos puro, debido a que no están basados en extensiones de otros modelos más clásicos como el relacional: • Están fuertemente influenciados por los lenguajes de programación orientados a objetos. • Pueden verse como un intento de añadir la funcionalidad de un SGBD a un lenguaje de programación.

Base de Datos Objeto-Relacional (BDOR)
• Conserva un modelo compatible con el Modelo Relacional, el cual posee: • Fundamentos teóricos muy sólidos. • Más de 40 años de investigación. • Extensión del MR para incorporar características deseables de OO y otras. • Extension de SQL para incorporar nuevas características: Extensión de tipos, objectos, herencia, Consultas recursivas, SQL/XML ... • Estandar SQL:1999, revisado en SQL:2003 Base de Datos Objeto-Relacional (BDOR)

SGBD “Revolucionarios”
3. SGBDOO vs. SGBD de tercera generación Enfoques de implementación de SGBD de Objetos SGBDR “Extendidos” SGBD “Evolutivos” TERCERA GENERACIÓN OBJETO-RELACIONAL SGBD “Revolucionarios” SGBD OO “Puros” SGB DE OBJETOS OBJECTSTORE, O2, ONTOS, VERSANT, POET, GEMSTONE, .. ORACLE, IBM, MICROSOFT, INFORMIX, SYBASE, ... SQL:2003 Continuidad con la tecnología relacional / Conservación de las inversiones realizadas ODMG 3.0 Ruptura con la anterior tecnología / Riguroso apego a los principios de la OO

Manifiesto de los SGBDOO
3. SGBDOO vs. SGBD de tercera generación Manifiesto de los SGBDOO Atkinson, Bancilhon, DeWitt. Dittrich, Maier, Adonik (1989) Tres tipos de características: OBLIGATORIAS: Imprescindible satisfacerlas para merecer el calificativo de OO. OPCIONALES: Pueden añadirse para mejora el sistema. ABIERTAS: Soluciones igualmente aceptables que quedan al arbitrio del diseñador.

Overriding, overloading and late binding
3. SGBDOO vs. SGBD de tercera generación Manifiesto de los SGBDOO Características obligatorias: las reglas de oro Por ser SGBD • Persistencia • Concurrencia • Recuperación ante fallos • Gestión del almacenamiento secundario • Lenguajes ad-hoc para manipulación Por ser OO • Objetos complejos • Identidad del objeto • Encapsulamiento • Tipos o clases • Herencia • Polimorfismo, sobrecarga y vinculación dinámica • Extensibilidad • Completitud computacional (lenguaje de propósito general) volver Overriding, overloading and late binding

Manifiesto de los SGBDOO
3. SGBDOO vs. SGBD de tercera generación Manifiesto de los SGBDOO Características opcionales • Herencia múltiple • Verificación e inferencia de tipos • Distribución • Transacciones de diseño • Versiones Opciones abiertas • Paradigma de programación • Sistema de representación (tipos atómicos y constructores) • Sistema de tipos • Uniformidad (¿todo objetos?)

Principio 1: “Además de los servicios tradicionales de
3. SGBDOO vs. SGBD de 3ra generación Manifiesto de los SGBD de 3º Generación Stonebraker, Lindsay, Gray, Carey, Brodie, Bernstein, Beech (1990) Principio 1: “Además de los servicios tradicionales de gestión de datos, los SGBD-3G proporcionarán gestión de objetos y reglas más ricas” 1.1 Un SGBD-3G debe disponer de un rico sistema de tipos 1.2 La herencia es una buena idea 1.3 Las funciones (procedimientos y métodos) son una buena idea 1.4 Los IDOs para los registros deberían ser asignados por el SGBD sólo si no se dispone de una clave primaria 1.5 Las reglas (disparadores, restricciones) se convertirán en una característica primordial de los sistemas futuros.

Principio 2: “Los SGBD-3G deben subsumir los SGBD-2G”
3. SGBDOO vs. SGBD de 3ra generación Manifiesto de los SGBD de 3º Generación Principio 2: “Los SGBD-3G deben subsumir los SGBD-2G” 2.1 Lenguaje de acceso declarativo (no procedimental) y de alto nivel 2.2 Dos formas de especificar colecciones: enumeración de miembros y lenguajes de consulta para especificar la condición de pertenencia 2.3 Vistas actualizables 2.4 Los indicadores de rendimiento no deben aparecer en los modelo de datos, ya que no tiene prácticamente nada que ver con los modelos de datos.

Principio 3: “Los SGBD-3G deben ser abiertos a otros subsistemas”
3. SGBDOO vs. SGBD de 3ra generación Manifiesto de los SGBD de 3º Generación Principio 3: “Los SGBD-3G deben ser abiertos a otros subsistemas” 3.1 Los SGBD-3G deben ser accesibles desde múltiples lenguajes de alto nivel 3.2 Persistencia de variables 3.3 El SQL es una forma “intergaláctica” de expresión de datos 3.4 Las consultas y las respuestas resultantes deben ser el nivel más bajo de comunicación entre un cliente y un servidor volver

Pros de los OODBMS Base de Datos Orientadas a Objetos (BDOO) •la cantidad de información que puede modelarse con un OODBMS se incrementa, y también es más fácil modelar esta información. •Los OODBMS también son capaces de tener mayores capacidades de modelado por medio de la extensibilidad. Permitiendo de este modo modelar sistemas aún más complejos. Esta extensibilidad brinda una solución para incorporar bases de datos existentes y futuras en un solo entorno.

Pros de los OODBMS Base de Datos Orientadas a Objetos (BDOO) •Además de ventajas de modelado, un OODBMS también tienen ventajas de sistema. En un OODBMS, el manejo de versiones está disponible para ayudar a modelar cambios sobre los sistemas. Con el manejo de versiones, uno sería capaz de volver a conjuntos de datos previos, y comparar los conjuntos actuales con los anteriores. •La reutilización de clases juega un rol vital en el desarrollo y mantenimiento más rápido de aplicaciones. Las clases genéricas son potentes, pero más importante es que ellas pueden ser usadas nuevamente. Ya que las clases pueden reutilizarse, no se necesita diseñar material redundante. Esto lleva a la más rápida producción de aplicaciones y más fácil mantenimiento de dichas aplicaciones y bases de datos.

Contras de los OODBMS Base de Datos Orientadas a Objetos (BDOO) - Bajo impacto en el mercado de las BDOO. La falta de estandares en la industria orientada a objetos.

Base de Datos Objeto-Relacional (BDOR)
BDOR: “ventajas extendidas” • Modelo compatible con el Modelo Relacional. • Fundamentos teóricos más sólidos. • Presencia en el mercado: -Adoptado por numerosos SGBDR Oracle, IBM DB2, Informix, PostgreSQL etc. • Incorpora características deseables de OO sin perder lo bueno de los SGBDR  SGBDOR • Estandar SQL:1999, revisado en SQL:2003 Base de Datos Objeto-Relacional (BDOR)

Combina capacidades de BD OO y activas con BD relacionales. • ORACLE
3. SGBDOO vs. SGBD de tercera generación Productos y estándares Objeto-Relacional estandar: SQL: 1999, Melton (1999) SQL: 2003, Melton (2003) Productos: • POSTGRE Combina capacidades de BD OO y activas con BD relacionales. • ORACLE Extiende el modelo relacional del SQL2 con capacidades de objetos. • Universal Server de Informix, etc.

• ObjectStore de Object Design Persistencia de objetos en C++, Java
3. SGBDOO vs. SGBD de tercera generación Productos y estándares Objetos puros estandar: ODMG-93, Cattell (1994), Cattell (1995) ODMG V.2.0 Cattell (1997) ODMG V.3.0 Cattell (2000) Productos: • ObjectStore de Object Design Persistencia de objetos en C++, Java • O2 de O2, Leeluse et al. (1988) Lenguajes: C++, lenguajes de consulta (O2SQL) y programación (O2C) propios. Java • Gemstone de Servi Logic, Meier y Stone (1987) Persistencia de objetos en Samalltalk. Soporta también C++ y Java • POET de Poet Corporation Persistencia de objetos C++, Java

Comparación de standards para DBMS

Programa orientado a objetos
Integración Programa orientado a objetos Programa relacional BDOO BD relacional 3. SGBDOO vs. SGBD de tercera generación 3.4 Convergencia

Necesidad de convergencia
3. SGBDOO vs. SGBD de tercera generación 3.4 Convergencia Necesidad de convergencia “Es hora de que pongamos a nuestros clientes en primer lugar y les ayudemos a salir del falso dilema que hemos creado. La base de datos del futuro será, de hecho, orientada a objetos, pero retendrá todas las ventajas del modelo relacional”, Taylor (1992) Convergencia de estándares OBJECT MERGER GROUP.- grupo formado por integrantes del ODMG y del SQL3 cuyo objetivo es lograr la integración de los lenguajes de consulta de ambos estándares, a fin de conseguir el entendimiento entre BD3G y BDOO Convergencia de productos UniSQL, permite la coexistencia entre BD relacionales y BD orientadas a objeto.

4. Características de los SGBDOO
Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en la manipulación de tipos de datos complejos. Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programación. Los ODBMS tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

Funcionalidades de un SGBDOO = Funcionalidades de un SGBD +
4. Características de los SGBDOO SGBDOO = SGBD+ OO Funcionalidades de un SGBDOO = Funcionalidades de un SGBD + Funcionalidades de la OO

● Identificador de objeto ● Soporte de objetos complejos
4. Características de los SGBDOO 4.1. Funcionalidades de la OO ● Identificador de objeto ● Soporte de objetos complejos ● Sistema de tipos extensible ● Encapsulamiento ● Herencia ● Soportar un lenguaje completo ● Polimorfismo y sobrecarga Repaso

4.2. Funcionalidades de un SGBD ● Persistencia ● Manipulación del esquema ● Gestión de memoria secundaria ● Control de concurrencia: ● Gestión de transacciones ● Recuperación ante fallos ● Procesamiento de consultas ad-hoc ● Seguridad y control de acceso ● Otras: ● Soporte de restricciones ● Soporte de vistas

4.2.1 Persistencia y manipulación del esquema OBJETOS TRANSITORIOS/PERMANENTES Soportar persistencia requiere proporcionar mecanismos eficientes para representar y acceder a pequeños o grandes volúmenes de objetos en medios de almacenamiento no volátiles. Mantener índices, asignar el almacenamiento en disco, seleccionar caminos de acceso, optimizar consultas, o trasladar los datos entre el disco y la memoria principal, deben ser aspectos no visibles al usuario. Creándose de esta forma una independencia entre los niveles lógicos y físicos del sistema. El SGBD debe ser capaz de manejar el esquema de la BD: BD relacionales → → definición del esquema mediante SQL BDOO → → definición del esquema mediante un LPOO

4.2.1 Persistencia y manipulación del esquema Las BD sin OO almacenan sólo datos Las BDOO almacenan objetos (estructuras de datos + operaciones) Ventajas de almacenar juntas las estructuras de datos y las operaciones en la BO: Mejorar la manipulación y administración de los módulos de código, eliminando la necesidad de vincular (link) dicho código con las aplicaciones Aumentar la flexibilidad permitiendo especificar en que sitio de una red se va a ejecutar una operación

4.2.1 Persistencia Operaciones: lenguaje y almacenamiento Gemstone y OpenODB soportan lenguajes para la definición completa de los métodos (Opal y OSQL). Ambos productos almacenan y ejecutan las operaciones en el motor de la BD en lugar de hacerlo en el espacio de la aplicación. Sin embargo en muchos de los SGBDOO que soportan C++, las operaciones tienen que ser programadas en C++; se almacenan en ficheros .cxx para ser vinculadas (linked) con la aplicación.

4.2.1 Persistencia ejemplo: Persistencia en POET ► Una clase es persistente si se declara como tal. ► Todo objeto de una clase persistente puede almacenarse a si mismo. ► Modelo de persistencia explícito: cuando se crea un objeto persistente en la RAM, hay que almacenarlo explícitamente en la BD (método Assign). ► Si se almacena un objeto, se almacenan todos los objetos a los que hace referencia. ► Si se carga un objeto en la RAM, se cargan todos los objetos a los que haga referencia.

4.2.1 Persistencia ejemplo: Persistencia en POET Para cada clase declarada se crea un conjunto, AllSet, que guarda todos los objetos (extensión). Cada objeto puede existir una sola vez en memoria. Si una operación de la BD busca un objeto, primero se comprueba que no esté ya en memoria; si lo está, se devuelve el puntero al objeto. Las clases pueden contener punteros a objetos persistentes, y set de punteros. No pueden contener punteros a objetos no persistentes. Una clase persistente puede contener objetos embebidos (no tienen OID) que existen sólo como miembros del objeto contenedor.

4.2.2 Concurrencia BO accesibles por múltiples usuarios o aplicaciones Para asegurar que los objetos puedan ser compartidos se utilizan técnicas de BD: Control de concurrencia: permite que varios usuarios o aplicaciones compartan objetos de un modo seguro. Gestión de transacciones: incluye capacidades de recuperación ante fallos de la BD.

4.2.3 Procesamiento de consultas ad-hoc Técnicas para consultar objetos en una BDOO: Utilizando el propio LPOO para consultar a la BDOO. Mediante un lenguaje de consulta de objetos con una sintaxis similar a la del SQL. Este lenguaje soporta la noción de consulta basada en valores -de las BDs relacionales- y además soporta consultas basadas en relaciones (capacidad navegacional) y en valores que resultan de ejecutar una operación.

4.2.4 Seguridad y control de acceso Muchos SGBDOO utilizan los recursos de seguridad que brinda el Sistema Operativo subyacente (UNIX o Windows). Otros sistemas utilizan mecanismos de protección de esquemas mediante password, pero sin proporcionar ninguna técnica adicional para controlar el acceso y la seguridad a otros niveles (a nivel de objeto, a nivel de miembro…). Los SGBD relacionales continúan siendo mucho más potentes en este sentido.

Otras funcionalidades RESTRICCIONES: Los SGBDOO no soportan restricciones. Las restricciones soportadas por los SGBD relacionales se soportan mediante operaciones VISTAS: Los SGBDOO no soportan vistas. Las vistas soportadas por los SGBD relacionales se soportan mediante operaciones

4.2.5 Otras 4. Características de los SGBDOO En general: Los SGBDOR son más potentes que los SGBDOO en cuanto a capacidades propias del sistema de gestión. Los SGBDOO tienen un modelo más rico y otras facilidades.

"Nombre de alumnos que cursan Teología“
Modelo Relacional : ejemplo Alumno–Curso Alumno Alumno# NombreAlumno Dirección 1 Hidalgo Juan M. Zaballa 100 N 2 Gonzales Irene 3 Sanchez Clara Inés 4 Romero Diego 5 Martinez Analía Curso# C1 T2 Q9 F3 NombreCurso Computación Filosofía Quimica Teología Los Alerces 810 S Mendoza 536 N Mitre 213 O Ig. De la Roza 5410 O Estudia Para obtener: "Nombre de alumnos que cursan Teología“ ‘Ir’ a curso para encontrar el curso# corresp. a Teología (i.e.T2) ‘Ir’ a Estudia y retornar todos los Alumno#s con T2 ‘Ir’ a Alumno para retornar el NombreAlumno corresp. A cada Alumno# Curso

"Nombre de alumnos que cursan Teología“
Modelo De Objetos: ejemplo Alumno–Curso Curso=Teología Curso# =T2 Alumnos OBJETO CURSO OBJETO ALUMNO Alumno# =2 NombreAlumno=Gonzales Irene Curso Alumno# =3 NombreAlumno=Sanchez Inés Next Nil Para obtener: "Nombre de alumnos que cursan Teología“ Buscar en índice de curso para hallar curso# (i.e. T2) Seguir punteros a Alumno para hallar cada NombreAlumno Este proceso es llamado navegación, notar que depende de punteros y que muchos de ellos deberán ser persitentes.

(un hijo sólo un padre; un padre varios hijos)
Bases de Datos Jerárquicas ●Datos organizados en árbol ● Relaciones 1:N (un hijo sólo un padre; un padre varios hijos) Todas las instancias de un registro específico se reúnen bajo un tipo ‘registro’. Estos ‘record types’ son los equivalentes a las tablas del MR, y los registros individuales a las tuplas. Para crear links entre estos ‘record types’, el modelo Jerárquico usa las relaciones Padre-Hijo (mapeo 1:N). ● Query by path navigation Ejemplos: →Sistema de archivos (File system) → LDAP: (Lightweight Directory Access Protocol), (Protocolo Ligero de Acceso a Directorios) permite el acceso a un servicio de directorio ordenado y distribuido para buscar información en un entorno de red. → Registro de Windows → Documentos XML – Xquery volver Autor Artículo Bibliografía Libro

Bases de Datos de Red Otros Ejemplos: ●Datos organizados en grafo
(el modelo de Red permite la relación ‘muchos a muchos’ en los datos) ●Estandard CODASYL: en 1971 CODASYL (Conference on Data Systems Languages) define formalmente el modelo de Red. El modelo CODASYL está basado en la teoría de conjuntos. La estructura básica del modelo es el conjunto (‘set’). Un ‘set’ consiste de un tipo de registro propietario (padre) y un tipo de registro miembro (hijo). Este último puede tener rol de miembro en más de un ‘set’ ( multi-padre). A su vez un registro propietario puede ser miembro o propietario en otro set. Como vemos dichos tipos de registros mantienen una relación de ‘muchos a muchos’. ●Query by graph navigation Otros Ejemplos: → existen algunos DBMSs de red que no siguen las especificaciones CODASYL. volver Autor Bibliografía Libro Artículo

Que es una Base De Datos Orientada a Objetos?
“Base de Datos Relacional” de un gato “Base de Datos Orientada a Objetos” de un gato ● ● ● En las BDR la normalización “fuerza a un mundo plano” Un ODBMS (Object DataBase Management System), también referido como OODBMS (Object-Oriented DataBase Management System), es un DBMS que soporta el modelado y creación de datos como objetos. Esto supone también, en alguna medida, dar soporte a clases de objetos y herencia de propiedades y métodos para las subclases. volver

BDs Activas Una Base de Datos activa es una BD que incluye el manejo de reglas activas, las cuales, mediante un potente mecanismo de procesamiento de reglas, enriquecen la funcionalidad de las BD tradicionales. Las BD activas tienen la capacidad para manejar restricciones de integridad, autorizaciones, flujo de trabajos, acciones de monitoreo y alerta, sistemas expertos, etc. volver

BDs Temporales Una Base de datos temporal es una BD que incorpora aspectos de tiempo. Para ello utiliza un modelo de datos temporal y una versión temporal de lenguaje query. Dichos aspectos de tiempo incluyen un tiempo válido ( valid-time ) y un tiempo de transacción (transaction-time ), atributos que juntos conforman datos bitemporales. El tiempo válido denota el período de tiempo durante el cual un hecho es verdadero con respecto al mundo real. El tiempo de transacción es el periodo de tiempo durante el cual un hecho es almacenado en la BD. Un dato bitemporal combina ambos: tiempo válido y tiempo de transacción. Ambos períodos de tiempo no tienen porque ser iguales para un hecho cualquiera. Supongamos tener una BD con datos del siglo pasado. El tiempo válido para un hecho será un intervalo de tiempo entre 1901 y 2000, mientras que el tiempo de transacción arranca cuando insertamos dicho hecho en la BD, por ejemplo 21 de febrero de volver

BDs Seguras En las BDs se plantean problemas vinculados a la seguridad como la compartición y acceso a los datos, protección contra fallos, protección contra accesos no permitidos, etc. El SGBD cuenta con mecanismos -para prevenir, detectar y corregir fallos- provistos por los subsistemas de control, de detección y de recuperación de fallos respectivamente. Temas relativos a la seguridad: Confidencialidad -► No revelar datos a usuarios no autorizados Privacidad -► protección de datos personales. Integridad -► Permite asegurar que los datos no han sido falseados o modificados de forma indebida. mecanismos de seguridad -► privilegios de usuarios; cuentas de acceso; grupos de usuarios o roles. cifrado de de datos. etc. volver

Sistemas Multi-Databases
Un sistema multi-Database soporta operaciones en múltiples Sistemas de Base de Datos Componentes (SBDC). Cada SBDC es manejado por un DBMS. Un SBDC puede ser centralizado o distribuido y puede residir en la misma computadora o en múltiples computadoras conectadas por un subsistema de comunicaciones. Un sistema multi-Database es llamado homogéneo si todos los DBMSs componentes son iguales; si son diferentes entonces es llamado heterogéneo. El proyecto HeD-DBM (Heterogeneous Distributed DataBase Management) comenzó en los 80s y continúa hoy enfocado en desarrollar métodos para integrar sistemas heterogéneos y autónomos asumiendo que dichos sistemas usan diferentes modelos de datos y diferentes lenguajes transaccionales y de consulta. volver

Sistema de Base de Datos No–Federada
Sistemas Multi-Databases… …Un sistema multi-Database puede ser clasificado en dos tipos basados en la autonomía de los SBDCs: sistemas de BD no–federada y sistemas de BD federada. Sistema de Base de Datos No–Federada En un sistema de base de datos no federado los SBDCs no tienen autonomía y cualquier operación debe hacerse sobre la BD global. Un sistema de este tipo no distingue entre usuarios locales y usuarios no–locales. Un tipo particular de sistema de base de datos no–federado en el cual todas las bases están completamente integradas para proveer un esquema global simple es llamado Sistema Multibase de Datos unificado. Esto lógicamente luce ante los usuarios como un sistema de base de datos distribuida. sigue…

Sistema de Base de Datos Federada
Sistemas Multi-Databases… Sistema de Base de Datos Federada Un sistema de base de datos federada (SBDF) está compuesto por SBDCs que son autónomos e integran una federación para permitir la compartición parcial y controlada de sus datos. El concepto de autonomía implica que los SBDCs tienen control sobre los datos que ellos manejan; dichos SBDCs cooperan para permitir diversos grados de integración. No hay control centralizado en una arquitectura federada debido a que los SBDCs (y sus DBAs) controlan el accesos a sus datos. volver

Arquitectura Web de 3 capas (Three-Tier Web Architecture)
Capa cliente Capa servidor Capa Intermedia sigue...

volver Arquitecturas C/S y Web. Bases de Datos Web.
Arquitectura Web Abreviada. (3 capas) de un SGBD. Capa 1, Cliente (Front End con el Navegador del Usuario) Browser Internet Capa 2, 1eros. Servidores (Intermedia) Servidor Web y Servidor de Aplicaciones Bases de Servidor de Datos Capa 3, 2°Servidor (Back End) Bases de Datos volver

Esquema de arquitectura Cliente/Servidor genérica
La arquitectura C/S genérica tiene dos tipos de nodos en la red: clientes y servidores. Por ello se la denomina también arquitectura de dos capas. Esta arquitectura consiste básicamente en un programa cliente que realiza peticiones a otro programa -el servidor- que las responde. Aunque esta idea puede aplicarse a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. volver

Arquitectura Cliente/Servidor en tres capas (three-tier)
Esta arquitectura dispone de tres tipos de nodos: ► Clientes que interactúan con los usuarios finales. ► Servidores de aplicación que procesan los datos para los clientes. ► Servidores de la base de datos que almacenan los datos para los servidores de aplicación. Ventajas de la arquitectura de 3 capas: mejora el balance de carga en los diversos servidores; es más escalable. Desventajas: Pone más carga en la red, debido a que aumenta en ella el tráfico; es más difícil programar y probar el software que con 2 capas, porque tienen que comunicarse más dispositivos al ejecutar una transacción. volver

Semistructured Model En las bases de datos semiestructurados la información que corresponde normalmente al esquema está contenida en los datos, lo cual se denomina “auto-descripción” (self-describing‘). En tal tipo de BD no hay una clara separación entre datos y esquema y el grado de estructuración depende de la aplicación. Los datos semiestructurados son modelados mediante grafos con etiquetas que agregan semántica a la estructura subyacente. Las bases de datos semiestructurados han emergido recientemente como un importante tópico de estudio por una variedad de razones. Primero, hay fuentes de datos como la Web, que no puede tratarse como BDs porque no está restringida por un esquema. Segundo, es deseable tener un formato flexible para intercambiar datos entre BDs dispares. Tercero, aún disponiendo de datos estructurados a veces es útil tener acceso a ellos como si fueran semiestructurados. volver

XML (eXtensible Markup Language) es un lenguaje orientado a identificar estructuras de datos en un documento. La especificación XML define un estándar de cómo se debe realizar el marcado de expresiones en un documento no estructurado para definir así una determinada estructura de datos. Cuando se usan datos semiestructurados la información que corresponde normalmente al esquema está contenida en los datos, lo cual se denomina “auto-descripción” (self-describing). Historía y Objetivos XML fue creado al amparo del Word Wide Web Consortium (W3C) organismo que vela por el desarrollo de WWW partiendo de las amplias especificaciones de SGML. Su desarrollo se comenzó en 1996 y la primera versión salió a la luz el 10 de febrero de 1998. ● Inicialmente fue definido como: Sistema para definir, validar y compartir formatos de documentos en la web.

● Un documento XML es un documento que puede ser leído y entendido por una persona y a la vez puede ser procesado por un sistema para extraer información. ¿Para qué podemos usar XML? ● XML permite definir estructuras de datos susceptibles de ser procesadas por una gran variedad de aplicaciones y realizar intercambio electrónico de datos. El hecho de transformar datos en información, añadiéndoles un significado concreto y asociándolos a un contexto, siempre genera valor en la cadena de utilización de los datos fuente por parte de sus clientes. Consideremos la siguiente expresión: "Con fecha , remito el paciente J.J.C. HC a Neumología por presentar bronquitis aguda con broncoespasmo"

La pieza de texto mostrada, no dispone de ninguna estructura subyacente, sólo es significativa para el especialista que sabe de antemano que: HC es el número de historia clínica de un paciente, que Neumología es un punto de asistencia ambulatorio, etc. etc. Sin embargo, que pasaría si mediante un agente de búsqueda intentáramos recuperar información relativa a los casos clínicos tratados... Transformar datos en información <Derivacion> Con fecha <FechaEntrada> </FechaEntrada>remito el paciente <Paciente>HC334455</Paciente> a <Servicio>Neumología</Servicio> por presentar <Diagnostico>bronquitis aguda </Diagnostico> con broncoespasmo </Derivacion>

●no usa un conjunto fijo de etiquetas o tags ( X = “extensible”)
¿Si todo el mundo conoce HTML, porqué no seguir usándolo? HTML (Hypertex Mark Up Language) es el estándar de facto en la web. Dispone de un número limitado de etiquetas (tags) diseñadas en su mayoría para mostrar textos en los navegadores (browsers). Es útil para definir la presentacion de las páginas web pero no para describir la información que éstas contienen. XML es parecido a HTML pero: ●no usa un conjunto fijo de etiquetas o tags ( X = “extensible”) ●no tiene fijada la semantica de las etiquetas ( es determinada por la aplicación) ●no tiene fijada la estructura (esquemas definidos por el usuario) Por ello XML ofrece una gran potencia y flexibilidad para estructurar documentos y realizar intercambio electrónico de datos de manera eficiente.

Volver

.NET es la plataforma de Microsoft orientada a la creación de software para Internet. Esta plataforma ha sido diseñada para posibilitar el desarrollo y ejecución de software en la forma de servicios que puedan ser tanto publicados como accedidos a través de Internet. Opera de manera independiente al lenguaje de programación, modelo de objetos, sistema operativo y hardware utilizados. El corazón de dicha plataforma es CLR (Common Language Runtime), que es una aplicación similar a un máquina virtual que se encarga de gestionar la ejecución de las aplicaciones. volver

Overriding (redefinición de Métodos)
En una clase que hereda un método de una superclase, se tiene la oportunidad de redefinir o sobrescribir dicho método, a menos que ese método esté marcado como “final”. El beneficio clave de sobreescribir un método heredado es la habilidad de definir un comportamiento específico para los objetos de la subclase (esto requerirá el uso de “bind tardío”). Overloading (Sobrecarga de Métodos) Facilidad que le permite a una clase tener múltiples métodos con el mismo nombre, siempre y cuando tengan diferentes “signaturas” (La signatura de un método consiste en: el nombre del método, el número de parámetros y el tipo tanto de los parámetros como del resultado). Disponer de “overloading” de funciones y métodos da soporte al llamado polimorfismo ad-hoc, que permite que objetos de diferentes tipos sean tratados uniformemente como miembros de una superclase común. volver Polimorfismo

El estándar ODMG-93: Un estándar para bases de datos orientadas a objeto puras [cattell 94]
Es el resultado de trabajos que duraron 18 meses, de los 5 principales distribuidores de OODBMS (formaron el Object Database Management Group). Su objetivo fue asegurar la portabilidad de las aplicaciones de un sistema a otro. Siguiendo este objetivo son definidas tres interfaces: 1) ODL (Lenguaje de Definición de Objetos) Extensión de IDL, el lenguaje del OMG. Permite la definición de: objetos complejos, la relación entre esos objetos y métodos asociados a dichos objetos. 2) OQL (Lenguaje de Consulta de Objetos) Lenguaje no-procedural que permite realizar consultas sobre objetos, enviar mensajes a objetos, efectuar join y otras operaciones de tipo asociativo. Su sintaxis es del tipo SQL pero con soporte a objetos. El resultado de un Query puede ser ,por ejemplo, un set, bag, array, lista… de objetos. 3)Conexión con los lenguajes C++, Smalltalk y Java Esta interface permite y especifica como se debe hacer la programación de una aplicación en C++, Smalltalk o java, sobre una base de datos que ha sido declarada en ODL. volver

Identidad La identidad es la característica del objeto que lo hace ser único y lo distingue del resto de los objetos. Es importante destacar que la identidad de un objeto es independiente de los valores actuales de sus atributos, por ejemplo si tenemos un objeto libro, y cambiamos el valor del ISBN, éste va a tener la misma identidad. En los OOPLs, los objetos se identifican con nombres de variables o a través de su OID (Object Identifier) generados por el sistema. Un nombre de variable es asignado por el programador, y el sistema se encarga de asociar ese nombre con el OID correspondiente. Utilizando los OIDs, los objetos pueden compartir otros objetos y se pueden crear redes entre ellos. La Identidad de un objeto hace que tengamos dos nociones de igualdad: Igualdad por identidad. Dos objetos son iguales si tienen el mismo OID, es decir, son el mismo objeto. Igualdad por valor. Dos objetos son iguales si los valores de sus atributos son recursivamente iguales.

Objetos complejos Para poder implementar este tipo de objetos es necesario contar con mecanismos que permitan tener atributos multivaluados (como listas, conjuntos, arreglos, etc.), identificadores únicos y referencias a otros objetos. Mediante la agregación y la composición podemos definir objetos arbitrariamente complejos.

Tipos (tipificación) Los conceptos de clases y tipos son muy similares, puesto que un tipo es la implementación de una clase, pero los tipos ponen énfasis en el significado de una abstracción de manera diferente: “Los tipos son la puesta en vigor de la clase de los objetos, de modo que los objetos con tipos distintos no pueden intercambiarse El objetivo de contar con tipos, es evitar que se mezclen abstracciones de manera equivocada. Para lograrlo se debe realizar una comprobación de tipos, durante el proceso de compilación, que puede ser estricta o débil. Mediante la comprobación estricta de tipos se pueden detectar errores como: referencias a atributos inexistentes, invocación de métodos inexistentes, invocación de métodos con parámetros no válidos (Ej.: se espera un objeto del tipo automóvil, pero se recibe uno del tipo persona).

Encapsulamiento El encapsulamiento es uno de los pilares fundamentales en que se basa la orientación a objeto, éste consiste en agrupar en una única entidad los atributos y los métodos de un objeto, ocultando los detalles de su implementación. Para lograr esto, el objeto tiene dos partes, una pública o visible denominada Interfaz y otra privada u oculta llamada implementación. Al momento de definir la clase del objeto, se establece qué atributos y métodos van a ser públicos, y cuáles privados. En el caso de los métodos públicos, el algoritmo que utilizan para ejecutar el trabajo queda oculto (forma parte de la implementación). Con el concepto de encapsulamiento podemos decir que la abstracción de un objeto corresponde a su interfaz.

Cabe destacar que un encapsulamiento real se logra solamente cuando todos los atributos son privados, y la única forma de acceder a ellos, es a través de métodos públicos. Si un objeto permite que sus atributos sean públicos pierde el control sobre los valores que les son asignados, no pudiendo realizar la validación de los datos que se ingresan (riesgo de atributos inválidos). Un encapsulamiento real, hace que los métodos públicos sean como una muralla que garantice la integridad y validez de los datos guardados por el objeto en sus atributos. Esto permite además cambiar la estructura interna del objeto sin que dichos cambios afecten a los que lo utilizan. Lo mismo pasa con los algoritmos implementados por los métodos. Esto trae como beneficio una facilidad de mantención del sistema

Jerarquía de Clases: Herencia
Para modelar una determinada aplicación, no es suficiente definir todas las clases que la componen, es necesario describir además las relaciones que existen entre dichas clases. Recordemos que todo sistema es un conjunto de partes que interactúan entre sí. Existen cuatro tipos básicos de relaciones entre clases: 1) Herencia (Inheritance) -> un objeto comparte características con otro 2) Agregación (Aggregation) -> un objeto está compuesto de otros 3) Inversa (Inverse or Parent) -> un objeto es parte de otro (is-part-of) 4) Asociación (Association) -> un objeto está “conectado” con otros La primera denota una relación “Es un”( is-a), por ejemplo un automóvil es un medio de transporte. En la segunda un objeto “conoce” sus partes (una mariposa sabe que tiene alas) En la tercera “las alas saben que son parte de una mariposa, pero la mariposa no necesariamente sabe que tiene alas”. En la cuarta “un chofer puede ser asociado con un vehículo”

La idea de polimorfismo es: permitir que diferentes métodos tengan el mismo nombre. Éste concepto esta íntimamente ligado al de herencia. Pensemos en una superclase llamada figura_geométrica, que tenga como subclases a triángulo, cuadrado, circulo. Así, si tenemos un arreglo de figuras geométricas y queramos dibujar cada una de ellas. Una alternativa de implementación (sin polimorfismo) es la siguiente: pseudo código Inicio Defina A[1..10] de figuras_geométricas Llenar el arreglo A con figuras_geométricas Para i = 1 hasta 10 haga En caso que A[i] sea triangulo entonces A[i].dibujarTriángulo cuadrado entonces A[i].dibujarCuadrado circulo entonces A[i].dibujarCirculo fin en caso que Fin Para Fin Esto se puede simplificar enormemente. Podemos agregar un método en la superclase llamado Dibujar Figura_geométrica. De esta manera todas las subclases heredarían este método, cuya implementación deberá ser redefinida en las subclases (ya que cada una de ellas tiene un modo particular de dibujarse). Esta redefinición de un método se denomina suplantación (overriding).

De esta manera logramos tener un mismo nombre de método, pero diferentes implementaciones de él (polimorfismo). Así, el algoritmo antes presentado se reduce a : Inicio Defina A[1..10] de figuras_geométricas Llenar el arreglo A con figuras_geométricas Para i = 1 hasta 10 haga A[i].Dibujar() Fin Esto trae como consecuencia un diseño más simple, una herencia más efectiva, y en casos como el ejemplo anterior, menos líneas de código. Para lograr esta nueva funcionalidad el sistema tiene que asociar la invocación al método con el método correspondiente en tiempo de ejecución. Esto se denomina ligadura tardía (late binding). Otra manera de lograr el polimorfismo es la sobrecarga de métodos que consiste en tener dos o más métodos con el mismo nombre pero con distintos argumentos. En este caso, que suele denominarse polimorfismo ad-hoc, no es necesario hacer una ligadura tardía, se puede hacer de manera normal, es decir, en tiempo de compilación. volver

1. Evolución e Historia de las BDs 2. BDOO: Motivación

Presentaciones similares

Presentación del tema: "1. Evolución e Historia de las BDs 2. BDOO: Motivación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

1. Evolución e Historia de las BDs 2. BDOO: Motivación

Presentaciones similares

Presentación del tema: "1. Evolución e Historia de las BDs 2. BDOO: Motivación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback