Base de datos orientada a objetos

Universidad Nacional de Cajamarca
UNIVERSIDAD NACIONAL
DE CAJAMARCA
FACULTAD DE INGENIERÍA
Escuela Académico Profesional de
Ingeniería de Sistemas
BASE DE DATOS ORIENTADA A OBJETOS
ASIGNATURA : Base de datos I
ALUMNOS : Coba Salazar, Franklin Jhonatan
Príncipe Cerquin, Gustavo Adolfo
DOCENTE : Ing. Carlos E Aparicio Arteaga
GRUPO : “B”
CICLO : IV
Cajamarca, noviembre del 2015
BASE DE DATOS ORIENTADAA OBJETOS

INTRODUCCIÓN
Los lenguajes de programación orientado a objeto tienen sus raíces en el lenguaje SIMULA
67, propuesto a finales de la década de 1960. En Simula, el concepto de clase agrupa la
estructura de datos interna de un objeto en una declaración de clase, Simula es un lenguaje
fuertemente tipado para entornos compilados. Sin embargo, el primer lenguaje que
popularizó la aproximación a objetos fue Smalltalk (1976); que ofrece una gran flexibilidad
gracias a la interpretación, y de Simula, añadiendo el concepto de metaclase.
Con la llegada de las estaciones de trabajo en los años 80, han crecido numerosos
lenguajes orientados a objetos inspirados en Simula o Smalltalk Entre los lenguajes
compilados, los más célebres son C++, Objective C y Ediffel.
En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases
de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas
ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Y entre los sistemas
disponibles en el mercado están: GESTONE/OPAL de ServioLogic, ONTOS de Ontologic,
Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjectStore de
ObjectDesign y O2 de O2 Technology.

ORIGEN DE LABASE DE DATOS ORIENTADAS A OBJETOS
El origen se encuentra básicamente en las siguientes razones:
La existencia de problemas para representar cierta información y modelar ciertos aspectos
del "mundo real", puesto que los modelos clásicos permiten representar gran cantidad de
datos, pero las operaciones y representaciones que se pueden realizar sobre ellos son
bastante simples.
El paso del modelo de objetos al modelo relacional genera dificultades que en el caso no
surgen ya que el modelo es el mismo.Por lo tanto, las bases de datos orientadas a objetos
surgen básicamente para tratar de paliar las deficiencias de los modelos anteriores y para
proporcionar eficiencia y sencillez a las aplicaciones.
Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos Orientadas a
Objetos son:
● Pobre representación de las entidades del "mundo real".
● Sobrecarga y poca riqueza semánticas.
● Soporte inadecuado para las restricciones de integridad y empresariales
● Estructura de datos homogénea
● Operaciones limitadas
● Dificultades para gestionar las consultas recursivas
● Desadaptación de impedancias
● Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado
acceso navegacional.
● No ofrecen soporte para tipos definidos por el usuario (sólo dominios)
Mientras que las necesidades de las aplicaciones actuales con respecto a las bases de
datos son:
● Soporte para objetos complejos y datos multimedia
● Identificadores únicos

● Soporte a referencias e interrelaciones
● Manipulación navegacional y de conjunto de registros
● Jerarquías de objetos o tipos y herencia
● Integración de los datos con sus procedimientos asociados
● Modelos extensibles mediante tipos de datos definidos por el usuario
● Gestión de versiones
● Facilidades de evolución
● Transacciones de larga duración
● Interconexión e interoperabilidad
Debido a las limitaciones anteriormente expuestas, su uso es más ventajoso si se presenta
en alguno de los siguientes escenarios:
● Un gran número de tipos de datos diferentes
● Un gran número de relaciones entre los objetos
● Objetos con comportamientos complejos
Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones entre
objetos y comportamiento de los objetos principalmente en aplicaciones de ingeniería,
manufacturación, simulaciones, automatización de oficina y en numerosos sistemas de
información. No obstante, las BDOO no están restringidas a estas áreas. Ya que al ofrecer
la misma funcionalidad que su precursoras relacionales, el resto de campos de aplicación
tiene la posibilidad de aprovechar completamente la potencia que las BDOO ofrecen para
modelar situaciones del mundo real.
CARACTERÍSTICAS
Una de las características mandatorias de o reglas son:
1.-Debe tener un motor de base de datos.
2.-Debe ser un sistema orientado a objetos.
Mandatorias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de base
de datos orientadas a objetos y estos son: Objetos complejos, Identidad de objetos,
Encapsulación, Tipos ó Clases, Sobre paso combinado con unión retardada, Extensibilidad,
Completación Computacional, Persistencia y Manejador de almacenamiento secundario,
Concurrencia, Recuperación y Facilidad de Query.
Opcional.- Son las que pueden ser añadidas para hacer el sistema mejor pero que no son
Mandatorias estas son de: herencia múltiple, chequeo de tipos e inferencia distribución y
diseño de transacciones y versiones.

Abiertas.- Son los puntos donde el diseñador puede hacer un número de opciones y estas
son el paradigma de la programación la representación del sistema ó el tipo de sistema y su
uniformidad.
El modelo orientado a objetos se basa en encapsular código y datos en una única unidad,
llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un
conjunto de mensajes. El término mensaje en un contexto orientado a objetos, no implica el
uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de
solicitudes entre objetos sin tener en cuenta detalles específicos de implementación. El
modelo de datos orientado a objetos es una extensión del paradigma de programación
orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a
objetos son análogos a las entidades que se utilizan en las bases de datos orientadas a
objetos puros, pero con una gran diferencia: los objetos del programa desaparecen cuando
el programa termina su ejecución, mientras que los objetos de la base de datos
permanecen. A esto se le denomina persistencia.
VENTAJAS E INCONVENIENTES DE LAS BASE DE DATOS ORIENTADAS A OBJETOS
Aunque los Sistema Gestor de Bases de Datos Orientadas a Objetos pueden proporcionar
soluciones apropiadas para muchos tipos de aplicaciones avanzadas de bases de datos,
también tienen sus desventajas.
Las ventajas de un Sistema Gestor de Bases de Datos Orientadas a Objetos son:
● Mayor capacidad de modelado. El modelado de datos orientado a objetos permite
modelar el "mundo real" de una manera mucho más fiel. Esto se debe a:
1. un objeto permite encapsular tanto un estado como un comportamiento
2. un objeto puede almacenar todas las relaciones que tenga con otros objetos
3. los objetos pueden agruparse para formar objetos complejos (herencia).
● Ampliabilidad. Esto se debe a:
1. Se pueden construir nuevos tipos de datos a partir de los ya existentes.
2. Agrupación de propiedades comunes de diversas clases e incluirlas en una
superclase, lo que reduce la redundancia.
3. Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento
y un menor tiempo de desarrollo.

● Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al
siguiente es la forma más común de acceso a datos en un Sistema Gestor de Bases
de Datos Orientadas a Objetos. Mientras que SQL utiliza el acceso asociativo. El
acceso navegacional es más adecuado para gestionar operaciones como los
despieces, consultas recursivas, etc.
● Adecuación a las aplicaciones avanzadas de base de datos. Hay muchas áreas en
las que los SGBD tradicionales no han tenido excesivo éxito como el CAD, CASE,
OIS, sistemas multimedia, etc. en los que las capacidades de modelado de los
Sistema Gestor de Bases de Datos Orientadas a Objetos han hecho que estos
sistemas sí resultan efectivos para este tipo de aplicaciones.
● Mayores prestaciones. Los Sistema Gestor de Bases de Datos Orientadas a Objetos
proporcionan mejoras significativas de rendimiento con respecto a los Sistema
Gestor de Bases de Datos Orientadas a Objetos relacionales. Aunque hay autores
que han argumentado que los bancos de prueba usados están dirigidos a
aplicaciones de ingeniería donde los Sistema Gestor de Bases de Datos Orientadas
a Objetos son más adecuados. También está demostrado que los SGBDR tienen un
rendimiento mejor que los Sistema Gestor de Bases de Datos Orientadas a Objetos
en las aplicaciones tradicionales de bases de datos como el procesamiento de
transacciones en línea (OLTP).
Los inconvenientes de un Sistema Gestor de Bases de Datos Orientadas a Objetos son:
● Carencia de un modelo de datos universal. No hay ningún modelo de datos que esté
universalmente aceptado para los SGBDOO y la mayoría de los modelos carecen
una base teórica.
● Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se
dispone para los sistemas tradicionales.
● Carencia de estándares. Existe una carencia de estándares general para los
Sistema Gestor de Bases de Datos Orientadas a Objetos.
● Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen
una experiencia de uso considerable. SQL es un estándar aprobado y ODBC es un
estándar de facto. Además, el modelo relacional tiene una sólida base teórica y los
productos relacionales disponen de muchas herramientas de soporte que sirven
tanto para desarrolladores como para usuarios finales.
● La optimización de consultas compromete la encapsulación. La optimización de
consultas requiere una compresión de la implementación de los objetos, para poder
acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el
concepto de encapsulación.

● El modelo de objetos aún no tiene una teoría matemática coherente que le sirva de
base.
CONCEPTOS BÁSICOS ORIENTADO AOBJETOS.
Clase :Una clase se le define como un modelo que agrupa a un conjunto de objetos de
características comunes. También es definida como una plantilla que contiene la definición
de los datos y métodos para los objetos instanciados por la clase.
Identidad de Objetos: Un objeto es cualquier cosa sea real o abstracta a través del cual
almacenamos datos y definimos métodos para controlar estos datos.
La identidad es una propiedad de todo objeto que permite diferenciar a los demás objetos.
Todo objeto se identifica por un identificador de objeto, el cual es único, y a través de éste
se puede invocar un objeto para realizar una operación.
Encapsulamiento:Hay muchos datos que no tienen que ser “expuestos” cuando se utiliza
un objeto, ya que solamente funcionan de manera interna, esto es encapsulamiento; hacer
que los atributos no interactúen con el usuario y solo son llamadas por funciones dentro del
objeto.
Proporciona una lógica independiente de los datos, porque se puede cambiar la
implementación de un comportamiento sin cambiar el programa que uso dicho
comportamiento.
Jerarquía de Tipos y Herencia:En los modelos de datos de una base de datos orientada a
objetos, se necesitan un número limitado de clases; pero algunas de estas clases se
parecen entre sí.
Para representar estas clases, se defina una especialización. Las especializaciones de una
clase (clase base) son definidas como subclases (clases heredadas), las cuales heredan las
características y los métodos de la clase base.
Polimorfismo:El polimorfismo se refiere a definir diferentes comportamientos a los métodos
que tienen la misma firma en diferentes clases. Esto quiere decir, sobreescribir los métodos
de las clases heredadas, los cuales estos métodos se encuentran definidos en las clases
base.
Manejo de objetos complejos:Hay dos tipos de objetos complejos
a. Objetos no Estructurados: necesita de una gran espacio de almacenamiento: tipo de
dato imagen (mapa de bits) o cadena texto extenso (documento)
b. Objetos Estructurados: constituidos por componentes, se define en diversos niveles.

Compatibilidad con lenguajes de programación: Los lenguajes de programación que
utiliza una base de datos orientada a objetos utilizan herramientas de diseño para el
modelado de objetos y codificación. En la actualidad, existen varios lenguajes de
programación: C++, Java, PHP, etc
a. Extender el lenguaje a través de las llamadas expresiones de consulta, que son
parecidas a las sentencias SQL y pueden ser usadas para extraer y procesar
convenientemente bases de datos relacionales.
b. Un lenguaje de programación orientado a objetos que trabaje en forma directa con la
base de datos a través de un Modelo de Datos persistente.
EL MODELO ORIENTADO AOBJETOS
El modelo de datos orientado a objetos es una extensión del paradigma de programación
orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a
objetos son análogos a las entidades que se utilizan en las bases de datos orientadas a
objetos puras, pero con una gran diferencia: los objetos del programa desaparecen cuando
el programa termina su ejecución, mientras que los objetos de la base de datos
permanecen. A esto se le denomina persistencia.
Persistencia.
Esta se refiere a la capacidad de manipular directamente los datos almacenados en una
base de datos usando un lenguaje de programación orientado a objetos.
Relaciones.
Las bases de datos relacionales representan las relaciones mediante las claves ajenas. No
tienen estructuras de datos que formen parte de la base de datos y que representen estos
enlaces entre tablas. Las relaciones se utilizan para hacer concatenaciones (join) de tablas.
Por el contrario, las bases de datos orientadas a objetos implementan sus relaciones
incluyendo en cada objeto los identificadores de los objetos con los que se relaciona.
Integridad de las relaciones.
Para que las relaciones funcionen en una base de datos orientada a objetos pura, los
identificadores de los objetos deben corresponderse en ambos extremos de la relación. Por
ejemplo:
si los aparejadores de una empresa de control de calidad se deben relacionar con las obras
de construcción que supervisan, debe haber algún modo de garantizar que, cuando un
identificador de un objeto Obra se incluye en un objeto Aparejador, el identificador de este
mismo objeto Aparejador se debe incluir en el objeto Obra anterior. Este tipo de integridad
de relaciones, que es de algún modo análogo a la integridad referencial en las bases de
datos relacionales, se gestiona especificando relaciones inversas.
La clase Aparejador tiene un atributo de tipo conjunto llamado supervisa. Del mismo modo,
la clase Obra tiene un atributo llamado es supervisada. Para garantizar la integridad de esta

relación, un SGBD orientado a objetos puro deberá permitir que el diseñador de la base de
datos puede especificar dónde debe aparecer el identificador del objeto inverso.
ejemplo:
En la clase Aparejador:
relationship set<Obra> supervisa
inverse Obra::es_supervisada
En la Clase Obra:
relationship Aparejador es_supervisada
inverse Aparejador::supervisa
Siempre que un usuario o un programa de aplicación inserta o elimina un identificador de
objeto de la relación supervisa en un objeto Aparejador, el SGBD actualizará
automáticamente la relación es supervisada en el objeto Obra relacionado. Cuando se hace
una modificación en el objeto Obra, el SGBD lo propagará automáticamente al objeto
Aparejador. Del mismo modo que en las bases de datos relacionales es el diseñador de la
base de datos el que debe especificar las reglas de integridad referencial, en las bases de
datos orientadas a objetos es también el diseñador el que debe especificar las relaciones
inversas cuando crea el esquema de la base de datos.
DISEÑO CON EL DIAGRAMA DE CLASE
El Diagrama de Clase es el el diagrama principal de diseño y análisis para un sistema. En
él, la estructura de clases del sistema se especifica, con relaciones entre clases y
estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando
una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para
satisfacer los detalles de las implementaciones.
UML proporciona mecanismos para representar los miembros de la clase, como atributos y
métodos, así como información adicional sobre ellos.
En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado
(UML) es un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las
relaciones entre los objetos.
Es un diagrama que muestra un conjunto de interfaces, colaboraciones y sus relaciones.
Gráficamente es una colección de nodos y arcos. Los diagramas de clases contienen

Clases. Interfaces,Relaciones de dependencia, generalización y asociación. Notas.
Restricciones(Pueden o no contener), Paquetes. Subsistemas( se usan para agrupar los
elementos de un modelo en partes más grandes)
Modelan: Vista de diseño estática de un sistema. El vocabulario del sistema. Las
colaboraciones. Los esquemas, son la base para: Los diagramas de componentes. Los
diagramas de despliegue.
Son importantes para: Visualizar. Especificar,Documentar modelos estructurales; Construir
sistemas ejecutables. Aplicando: Ingeniería directa o Inversa.
Los usos más comunes de los diagramas de clase son:
● Modelar la vista de diseño estática de un sistema.
● Para modelar el vocabulario de un sistema. Implica decidir que abstracciones son
parte del sistema y cuáles no y así especificar esas abstracciones y sus
responsabilidades.
● Para modelar colaboraciones simples. Se emplean para visualizar un conjunto. de
datos y sus colaboraciones.
● Para modelar un esquema lógico de base de datos. Se necesitará almacenar
información persistente en una base de datos relacional o en una base de datos
orientada a objetos. Una colaboración es un conjunto de clases, interfaces y otros
elementos que colaboran para proporcionar un comportamiento cooperativo mayor
que la suma de todos los elementos.
Las clases colaboran unas con otras para llegar a una semántica mayor que la asociada a
cada clase individual, por lo que a parte de capturar el vocabulario del sistema hay que
prestar atención a la visualización, especificación, construcción y documentación(las
técnicas mas comunes de modelado) de la forma en que estos elementos del vocabulario
colaboran entre sí.
Para modelar una colaboración:
❖ Hay que identificar los mecanismos que se quieren modelar.
❖ Hay que identificar las clases, interfaces y otras colaboraciones que participan en
esta colaboración, y las relaciones entre estos elementos.
❖ Hay que usar escenarios para recorrer la interacción entre estos elementos. Se
descubrirán partes del modelo que faltaban y otras que eran semánticamente
incorrectas.
❖ Rellenar estos elementos con su contenido. Para las clases se realiza un reparto
equilibrado de responsabilidades. Después, hay que convertir estas en atributos y
operaciones concretos.
Cuando se modela con diagramas de clases se permite el modelado del comportamiento de
los datos a almacenar.
Para modelar un esquema:

➢ Hay que identificar aquellas clases del modelo cuyo estado debe trascender el
tiempo de vida de las aplicaciones.
➢ Hay que crear un diagrama de clases que contenga estas clases.
➢ Hay que expandir los detalles estructurales de estas clases. Es especificar los
detalles de sus atributos.
➢ Buscar patrones comunes que complican el diseño físico de bases de datos
(asociaciones cíclicas y uno a uno). Se deben crear abstracciones intermedias para
simplificar la estructura lógica.
➢ Hay que considerar el comportamiento de las clases persistentes expandiendo las
operaciones que sean importantes para el acceso a los datos y la integridad de
estos.
➢ Hay que usar herramientas que ayuden a transformar un diseño lógico en un diseño
físico
.
El diagrama de clases puede tener como ejemplo: una clase que sería un objeto o persona
misma en la cual se especifica cada acción y especificación.
Propiedades de objetos que tienen propiedades y/u operaciones que contienen un contexto
y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de
negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las
operaciones.
El diagrama de clases incluye mucha más información como la relación entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que
son implementadas para una interfaz gráfica.
Presenta las clases del sistema con sus relaciones estructurales y de herencia.
El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.
EJEMPLO:
Se quiere desarrollar un sistema de información para la Universidad de Oriente según la
descripción siguiente.
La Universidad se caracteriza mediante su nombre y la ciudad donde se sitúa. En la
Universidad están vinculados dos tipos de Persona:Trabajadores, que la Universidad
emplea, y Estudiantes, que estudian en la Universidad. Cada Persona tiene una CI y un
nombre. Los Trabajadores pertenecen a dos grupos: PDI y PAS. Cada Trabajador tiene

asociada una fecha de inicio de su contrato. Cada miembro del PDI también tiene una
categoría, mientras que cada miembro del PAS tiene un puesto. Los miembros del PDI
pueden o no ser Doctores. Las actividades que desarrolla el PDI son investigar y enseñar,
mientras que la actividad que desarrolla el PAS es administrar. La Universidad se compone
de un conjunto de Departamentos, cada uno de los cuales tiene un nombre y un conjunto de
Trabajadores adscrito. Un Trabajador no puede estar adscrito a más de un Departamento.
Un PDI está adscrito obligatoriamente a un Departamento, mientras que un PAS, no. Cada
Departamento está dirigido por un Doctor. Un Estudiante' puede ser buen 'Estudiante de
grado, de una determinada titulación, bien 'Estudiante de Doctorado, de un determinado
programa de Doctorado. Un Estudiante de grado puede también colaborar con un
Departamento como becario y puede realizar un PFC dirigido por un miembro del PDI'. Un
'Estudiante de Doctorado realiza una tesis dirigida por un Doctor. Puede suponer que un
Estudiante no puede estudiar en más de una Universidad y que un Trabajador no puede ser
empleado por más de una Universidad. Proporcione un modelo de esta descripción en
forma de un diagrama de clases UML utilizando para nombres de clases únicamente las
palabras que aparecen en negrita en la descripción anterior. Las palabras que aparecen en
cursiva proporcionan pistas para la definición de los otros elementos del modelo. No hace
falta proporcionar información de tipado para las propiedades que pueda definir. Para más
puntuación, añada a su modelo los elementos necesarios para tomar en cuenta lo siguiente:
● Una Persona puede ser a la vez Trabajador y Estudiante,
● Un Estudiante no puede ser a la vez 'Estudiante de grado y 'Estudiante de
Doctorado,
● Los únicos tipos de Trabajador que existen son PDI y PAS,
● Un Trabajador no puede ser a la vez PDI y PAS.

CONCLUSIONES
● Una base de datos orientada a objetos es una base de datos donde los elementos
son objetos. Estos pueden ser bases de datos multimedia (videos, imágenes y
sonidos), donde la herencia nos permita una mejor representación de la información,
estas bases de datos tienen una identidad de ser un Todo, y no solo una parte de
una gran base, por ejemplo una base de secuencias de ADN.
● El objetivo de una base de datos orientada a objetos son los mismos que los de las
bases de datos tradicionales, pero con la ventaja de representar las modelos de
datos con un marco mucho más eficiente, manteniendo la integridad y relación entre
ellos.
● Recordemos que un objeto es una estructura que tiene asociado un estado y un
comportamiento (propiedades y métodos). Estas bases tienen las características de
todo lo que es orientado a objeto que son Herencia, Polimorfismo, Abstracción y
Encapsulamiento.
● Un objeto puede heredar comportamiento de otro tipo de objetos(herencia) y puede
adaptarse para responder de diferentes maneras ante la solicitud de una acción
(polimorfismo), lo importante es que permite representar cosas de la vida real con
relativa facilidad(abstracción) y que todo esto se puede implementar de manera que
no nos importe el código, sino sólo la manera de comunicarnos con estos objetos
pensando en ellos como una sola unidad (encapsulamiento).Las bases de datos
orientados a objetos han adoptado muchos de los objetos creados para los
lenguajes de programación orientados a objetos.
●
● La utilización de una BDOO simplifica la conceptualización ya que la utilización de
objetos permite representar de una manera más natural la información que se quiere
guardar.

● Para modelar la estructura o vista lógica de la BD, se utiliza el Diagrama de clases
que permite presentar las clases con sus respectivas relaciones estructurales y de
herencia.
BIBLIOGRAFÍA
http://www.monografias.com/trabajos87/base-datos-orientada-objetos/base-datos-orientada-objetos.shtml
http://www.monografias.com/trabajos79/base-datos-orientadas-objetos/base-datos-orientadas-objetos.shtml
https://www.google.com.pe/search?q=BASE+DE+DATOS+ORIENTADA+A+OBJETOS&biw=1280&bih=675&sou
rce=lnms&tbm=isch&sa=X&ved=0ahUKEwiQl7_2h7jJAhUKTSYKHc7dDCIQ_AUIBigB&dpr=1
https://www.buenastareas.com/inscribirse?redirectUrl=%2Fensayos%2FBase-De-Datos-Orientada-a-
Objetos%2F7759553.html&from=essay

Base de datos orientada a objetos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Base de datos orientada a objetos

Semelhante a Base de datos orientada a objetos (20)

Último

Último (20)

Base de datos orientada a objetos