SlideShare ist ein Scribd-Unternehmen logo
1 von 7
Downloaden Sie, um offline zu lesen
UNIVERSIDAD NACIONAL DE CHIMBORAZO
FACULTAD DE CIENCIAS DE LA EDUCACIÓN HUMANAS Y
TECNOLÓGICAS
ESCUELA INFORMÁTICA APLICAD A LA EDUCACIÓN
NOMBRE: HECTOR LUMISACA
SEMESTRE: SEXTO
TEMA: TRABAJO DE INVESTIGACIÓN - UNIDAD 1
DOCENTE: ING LEONARDO AYAVACA
MATERIA: BASE DE DATOS II
PERIODO: SEPTIEMBRE_MARZO
RIOBAMBA-ECUADOR
CONCEPTO BASES DE DATOS ORIENTADOS A OBJETOS
Una base de datos es una colección de datos que puede constituirse de forma que sus contenidos
puedan permitirse el encapsular, tramitarse y renovarse sencillamente, elementos de datos, sus
características, atributos y el código que opera sobre ellos en elementos complejos llamados
objetos. Las base de datos están constituida por objetos, que pueden ser de muy diversos tipos, y
sobre los cuales se encuentran definidas unas operaciones donde interactúan y se integran con las
de un lenguaje de programación orientado a objetos, es decir, que los componentes de la base de
datos son objetos de los lenguajes de programación además que este tipo de base de datos están
diseñadas para trabajar con lenguajes orientados a objetos también manipulan datos complejos de
forma rápida y segura.
Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de
estas nuevas aplicaciones. La orientación a objetos ofrece flexibilidad para manejar algunos de
estos requisitos y no está limitada por los tipos de datos y los lenguajes de consulta de los
sistemas de bases de datos tradicionales.
Los objetos estructurados se agrupan en clases. Las clases utilizadas en un determinado lenguaje
de programación orientado a objetos son las mismas clases que serán utilizadas en una base de
datos; de tal manera, que no es necesaria una transformación del modelo de objetos para ser
utilizado. De forma contraria, el modelo relacional requiere abstraerse lo suficiente como para
adaptar los objetos del mundo real a tablas. El conjunto de las clases se estructuran en subclases
y superclases, los valores de los datos también son objetos.
Muchas organizaciones que actualmente usan tecnología orientada a objetos también desean los
beneficios de los sistemas de gestión de base de datos orientados a objetos. En otras palabras, se
desea la migración de bases de datos y aplicaciones de bases de datos relacionales a orientadas a
objetos. La migración a la tecnología de objetos consiste de la ingeniería reversa de los programas
de aplicación y la migración de la base de datos. El objetivo de la migración de la base de datos es
tener un esquema equivalente y la base de datos disponibles. Esto desde luego puede ser logrado
por medio de la transformación manual del código de los programas lo cual resulta demasiado
complicado. Para esto existen tres enfoques que hacen uso de la tecnología de objetos para bases
de datos relacionales.
Características
Una de las características mandatarias de o reglas son:
1.-Debe tener un motor de base de datos.
2.-Debe ser un sistema orientado a objetos.
Mandatarias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de base de
datos orientados a objetos y estos son: Objetos complejos, Identidad de objetos, Encapsulación,
Tipos o 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
Mandatarias 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 o 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 Y DESVENTAJAS 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).
 Aplicabilidad. 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 esos sistemas sí resulten 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.
(torre, 2010)
BASES DE DATOS RELACIONALES VS ORIENTADAS A OBJETOS
Como hemos podido observar en la definición de ambos paradigmas de gestión e implementación
de bases de datos, hay grandes diferencias entre el modelo más utilizado en la actualidad, el
Modelo Relacional y el paradigma más utilizado en la informática en los últimos tiempos, el Modelo
Objeto. En este apartado vamos a tratar de dar una visión global de ambos sistemas presentando
las diferencias más importantes que se observan tratando de encontrar una explicación al hecho
de que aún se siga utilizando en las bases de datos el modelo relacional y si, es mejor que el
orientado a objetos, ¿por qué se sigue desarrollando este 2º modelo?
Una principal diferencia la vemos ya al comparar la definición de las unidades básicas de
información de cada caso. El modelo relacional define las tuplas como “instancias específicas de
una entidad” con un identificador único y las propiedades de esa entidad. En cambio, en el caso de
las bases de datos orientadas a objetos, se almacenan los objetos que se definen como “un objeto
está modelando una situación o entidad del mundo real al tener una identificación única,
propiedades específicas a sí misma, y la habilidad de trabajar en conjunto con objetos tanto de la
misma o distinta especificación”. Las tuplas del modelo relacional carecen de esa habilidad de
trabajar con otras tuplas ya que carecen de comportamiento. Además, el modelo objeto es capaz
de representar situaciones del mundo real, en cambio el modelo relacional sólo trabaja con
entidades, por lo tanto, si se quisiera modelar situaciones habría que adaptarlas, convirtiéndolas en
entidades perdiendo por el camino parte de la información, o creando un modelo extremadamente
complejo.
La identificación única de las entidades/objetos también difiere en ambos casos. El modelo
relacional utiliza el concepto de Clave Primaria para identificar a sus entidades de una manera
única. Esta clave es un valor que puede introducir y cambiar el usuario del sistema gestor con la
única restricción de que no se repita con ninguna otra clave primaria que contenga la tabla en ese
momento, aunque también puede asignarla el propio sistema gestor. En cambio, el modelo objeto
define el OID (Object Identity) que proveerá el sistema y le otorgará al objeto su identidad única.
No puede ser cambiado ni introducido por el usuario. Al desaparecer el objeto, el sistema elimina
ese OID pero no vuelve a asignárselo nunca a ningún objeto nuevo.
Los modelos relacionales tradicionales sólo permitían tipos de datos simples ofrecidos por SQL y
en última instancia por el sistema gestor. Esto hace bastante costoso trabajar con atributos
multivariados pudiendo hacerse este tratamiento de 2 formas, o bien saltándose la 1FN o
separando esos atributos en más tablas lo que, sin duda, carga mucho el sistema y convierte las
consultas en algo muy complejo. El modelo objeto, por definición provee de un sistema de tipos
análogo al lenguaje de programación con el que se utiliza. De esta forma permite definir nuevas
clases así como utilizar la herencia para extender las ya creadas. Así se consigue aplicar toda la
potencia de la Orientación a Objetos en las bases de datos.
Los modelos relacionales utilizan el lenguaje estándar de consultas SQL, que es declarativo lo que
hace que las consultas no vayan a la forma de encontrar el dato sino que sea el sistema gestor el
que realice esta tarea. Además, el hecho de ser estándar permite que las aplicaciones lo utilicen
sin importar el lenguaje de programación en el que están escritas. Por contra carga mucho el
procesamiento y hace que haya que tratar los datos para convertirlos a objetos en el lenguaje de
programación utilizado.
El modelo objeto difiere en este sentido bastante. Utiliza varios sistemas diferentes dependiendo
de la implementación que se esté utilizando. Hay sistemas, directamente imbuidos en el lenguaje
de programación que hacen esta recuperación de los datos transparente al programador,
trabajando con los objetos persistentes como si fueran objetos de memoria normales. Esta visión
es muy eficiente e intuitiva pero al no tener un lenguaje específico para trabajar con las consultas
no controla de forma alguna este acceso siendo vulnerable a errores del programador.
Otra forma de implementar las consultas ha sido el estándar OQL (Object Query Language)
definido por el Object Data Management Group (ODMG) que busca ser un estándar declarativo
para consultas a bases de datos orientadas a objetos. Su uso sería análogo al de SQL pero,
debido a su complejidad aún no hay ninguna implementación completa del estándar, sólo se han
llegado a realizar subconjuntos como JDOQL y EJB QL.
La forma de trabajar con los datos persistentes en el modelo relacional es seleccionando los datos
que queremos que persistan en el tiempo y grabándolos de manera explícita mediante consultas
de alta/modificación de SQL, previa transformación de los datos. Los objetos trabajan de otra
forma. Dependiendo de la implementación particular puede ser que haya clases persistentes,
cuyos objetos siempre se almacenen en disco, marcar especiales para los objetos que permitan
discriminar cuáles se almacenarán, y otras técnicas.
Esta es una de las partes más complejas de implementar de un sistema gestor de bases de datos
orientados a objetos ya que se busca que este paso a datos persistentes sea lo más transparente
posible para el programador de aplicaciones orientadas a objetos.
Obviamente el modelo objeto es una forma de centrar el desarrollo y explotación de un sistema en
la semántica del dato. En el modelo relacional había que adaptar la semántica a las capacidades
del sistema de una manera bastante estricta. En cambio, cuando trabajamos con objetos podemos
aplicar la semántica propia del problema de una manera mucho más natural, ya que este
paradigma se basa en modelar el mundo real.
Las relaciones entre entidades des modelo es una característica muy importante que cualquier
base de datos moderna debe poseer. La orientación a objetos facilita mucho esta tarea gracias a
los OID y a la herencia. Las relaciones de herencia, para lo cual se permite la herencia entre clases
de la misma forma que en los lenguajes de programación, heredando el hijo todos los atributos y
métodos que hubiera definido su padre. El resto de relaciones que hubiera que representar se
haría mediante los OID que identifican unívocamente a un objeto.
En las bases de datos relaciones, las relaciones de herencia se pueden simular mediante
complejos sistemas que obligaban al programador a aplicar una serie de mecanismos que
garantizaran la integridad. Y el resto de relaciones, por norma general crean una serie de tablas
intermedias que complica las sentencias SQL necesarias para recuperar los datos.
El acceso a los datos, en la gran mayoría de los sistemas gestores de bases de datos orientados a
objetos, se realiza de una forma navegacional, al estilo de los modelos jerárquico y red lo cual
obliga al usuario a conocer la ruta de acceso a los objetos. Esto, además de complicar el uso para
usuarios no programadores, unido a la necesidad de requisitos indirectos de hardware y software
debido al uso de objetos ralentiza las transacciones respecto al modelo relacional, lo que lo
convierte en muchos casos en algo inaceptable.
Las bases de datos orientadas a objetos permiten el almacenamiento de archivos multimedia ya
que un objeto puede ser cualquier cosa. Las bases de datos relacionales no permiten esto y hay
que simularlo guardando la dirección del archivo, con lo que no se garantiza que el archivo exista,
o almacenando en un campo binario de longitud indeterminada el archivo completo sin capturar la
propia base de datos de qué tipo de archivo se trata.
Los sistemas gestores de bases de datos orientados a objetos proporcionan un importante control
de versiones sobre los objetos almacenados, característica que junto a la capacidad de almacenar
objetos multimedia antes citada, hace a estos sistemas muy válidos en campos como el CAD,
aplicaciones científicas y otras aplicaciones igualmente específicas.
(Luis, 2011)
Bibliografía
Luis, E. V. (25 de 10 de 2011). Bases de Datos Relacionales vs Orientadas a Objetos. Recuperado el
16 de 11 de 2014, de Bases de Datos Relacionales vs Orientadas a Objetos:
http://twisensblog.blogspot.com/2011/10/bases-de-datos-relacionales-vs.html
torre, a. d. (15 de 5 de 2010). base de datos orientadas a objetos. Recuperado el 16 de 11 de 2014,
de base de datos orientadas a objetos: http://www.monografias.com/trabajos79/base-
datos-orientadas-objetos/base-datos-orientadas-objetos2.shtml

Weitere ähnliche Inhalte

Was ist angesagt?

Base de datos-objeto-relacional
Base de datos-objeto-relacionalBase de datos-objeto-relacional
Base de datos-objeto-relacional
Eduar Alfons Leon
 
Base de datos 1
Base de datos 1Base de datos 1
Base de datos 1
alejandro
 
Clasificación y modelos de bases de datos
Clasificación y modelos de bases de datosClasificación y modelos de bases de datos
Clasificación y modelos de bases de datos
astrid2014
 
Base de datos 5º (2)
Base de datos 5º (2)Base de datos 5º (2)
Base de datos 5º (2)
eleanavaleria
 
Universidad tecnológica de tehuacá modelos
Universidad tecnológica de tehuacá modelosUniversidad tecnológica de tehuacá modelos
Universidad tecnológica de tehuacá modelos
Victor Dolores Marcos
 
Bases de Datos Relacionales
Bases de Datos RelacionalesBases de Datos Relacionales
Bases de Datos Relacionales
Arnulfo Gomez
 

Was ist angesagt? (20)

Basen de Datos I
Basen de Datos IBasen de Datos I
Basen de Datos I
 
Base de datos
Base de datosBase de datos
Base de datos
 
Modelo de base de datos orientados a objetos
Modelo de base de datos orientados a objetosModelo de base de datos orientados a objetos
Modelo de base de datos orientados a objetos
 
Base de datos-objeto-relacional
Base de datos-objeto-relacionalBase de datos-objeto-relacional
Base de datos-objeto-relacional
 
DISEÑO DE BASE DE DATOS
DISEÑO DE BASE DE DATOSDISEÑO DE BASE DE DATOS
DISEÑO DE BASE DE DATOS
 
Actividad 5, bases de datos, rubrica 3 contenido.docx
Actividad 5, bases de datos, rubrica 3 contenido.docxActividad 5, bases de datos, rubrica 3 contenido.docx
Actividad 5, bases de datos, rubrica 3 contenido.docx
 
Base de datos 1
Base de datos 1Base de datos 1
Base de datos 1
 
Clasificación y modelos de bases de datos
Clasificación y modelos de bases de datosClasificación y modelos de bases de datos
Clasificación y modelos de bases de datos
 
Base de datos 5º (2)
Base de datos 5º (2)Base de datos 5º (2)
Base de datos 5º (2)
 
Universidad tecnológica de tehuacá modelos
Universidad tecnológica de tehuacá modelosUniversidad tecnológica de tehuacá modelos
Universidad tecnológica de tehuacá modelos
 
Base De Datos Orientada A Objetos
Base De Datos Orientada A ObjetosBase De Datos Orientada A Objetos
Base De Datos Orientada A Objetos
 
Actividad 5, bases de datos, rubrica 2 material
Actividad 5, bases de datos, rubrica 2 materialActividad 5, bases de datos, rubrica 2 material
Actividad 5, bases de datos, rubrica 2 material
 
Abd - funciones de dba y tipos de bd
Abd -  funciones de dba y tipos de bdAbd -  funciones de dba y tipos de bd
Abd - funciones de dba y tipos de bd
 
Base de datos orientada a objetos
Base de datos orientada a objetosBase de datos orientada a objetos
Base de datos orientada a objetos
 
Tipos de bases de datos
Tipos de bases de datosTipos de bases de datos
Tipos de bases de datos
 
Modelado De Datos
Modelado De  DatosModelado De  Datos
Modelado De Datos
 
Bases de Datos Relacionales
Bases de Datos RelacionalesBases de Datos Relacionales
Bases de Datos Relacionales
 
Modelo de datos.
Modelo de datos.Modelo de datos.
Modelo de datos.
 
Base de datos
Base de datosBase de datos
Base de datos
 
Presentacion bases de datos
Presentacion bases de datosPresentacion bases de datos
Presentacion bases de datos
 

Andere mochten auch (18)

6. sql structured query language
6. sql   structured query language6. sql   structured query language
6. sql structured query language
 
Data warehouse
Data warehouseData warehouse
Data warehouse
 
Ejercicios sql access
Ejercicios sql accessEjercicios sql access
Ejercicios sql access
 
My sql workbench
My sql workbenchMy sql workbench
My sql workbench
 
Bases de datos access
Bases de datos accessBases de datos access
Bases de datos access
 
Lumisaca hector bdii_t8
Lumisaca hector bdii_t8Lumisaca hector bdii_t8
Lumisaca hector bdii_t8
 
4. normalización
4. normalización4. normalización
4. normalización
 
Lumisaca hector rl_1
Lumisaca hector rl_1Lumisaca hector rl_1
Lumisaca hector rl_1
 
Hector lumisaca 6 s_ti_2
Hector lumisaca 6 s_ti_2Hector lumisaca 6 s_ti_2
Hector lumisaca 6 s_ti_2
 
Lumisaca hector bdii_t1
Lumisaca hector bdii_t1Lumisaca hector bdii_t1
Lumisaca hector bdii_t1
 
5. ejercicios normalización
5. ejercicios normalización5. ejercicios normalización
5. ejercicios normalización
 
Lumisaca hector bdii_t7
Lumisaca hector bdii_t7Lumisaca hector bdii_t7
Lumisaca hector bdii_t7
 
1 bases de-datos
1 bases de-datos1 bases de-datos
1 bases de-datos
 
Lumisaca hector bdii_t3
Lumisaca hector bdii_t3Lumisaca hector bdii_t3
Lumisaca hector bdii_t3
 
3 diseño de-bd
3 diseño de-bd3 diseño de-bd
3 diseño de-bd
 
7. sgbd sistema gestor de bases de datos
7. sgbd   sistema gestor de bases de datos7. sgbd   sistema gestor de bases de datos
7. sgbd sistema gestor de bases de datos
 
Lumisaca hector bdii_t2
Lumisaca hector bdii_t2Lumisaca hector bdii_t2
Lumisaca hector bdii_t2
 
Unidad 2. analisis
Unidad 2. analisisUnidad 2. analisis
Unidad 2. analisis
 

Ähnlich wie Lumisaca hector 6_s_ti_1.pdf

Instituto distrital evardo turizo palencia
Instituto distrital evardo turizo palenciaInstituto distrital evardo turizo palencia
Instituto distrital evardo turizo palencia
LeidyOsorioM
 
Aguagallo doris 6_s_ts.1 (1)
Aguagallo doris 6_s_ts.1 (1)Aguagallo doris 6_s_ts.1 (1)
Aguagallo doris 6_s_ts.1 (1)
Doris Aguagallo
 
Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1
Doris Aguagallo
 
Modelos de base de datos exp.4
Modelos de base de datos exp.4Modelos de base de datos exp.4
Modelos de base de datos exp.4
Yudy Reyes
 

Ähnlich wie Lumisaca hector 6_s_ti_1.pdf (20)

Saula ana 6_s_ti_1
Saula ana 6_s_ti_1Saula ana 6_s_ti_1
Saula ana 6_s_ti_1
 
Basededatos.pdf
Basededatos.pdfBasededatos.pdf
Basededatos.pdf
 
Trabajo bdoo
Trabajo bdooTrabajo bdoo
Trabajo bdoo
 
Yupa cesar 6_s_ti_1
Yupa cesar 6_s_ti_1Yupa cesar 6_s_ti_1
Yupa cesar 6_s_ti_1
 
Base de datos
Base de datosBase de datos
Base de datos
 
Instituto distrital evardo turizo palencia
Instituto distrital evardo turizo palenciaInstituto distrital evardo turizo palencia
Instituto distrital evardo turizo palencia
 
Sgbdoo
SgbdooSgbdoo
Sgbdoo
 
Modelo de una b.d
Modelo de una b.dModelo de una b.d
Modelo de una b.d
 
Modelo de Datos
Modelo de DatosModelo de Datos
Modelo de Datos
 
Aguagallo doris 6_s_ts.1 (1)
Aguagallo doris 6_s_ts.1 (1)Aguagallo doris 6_s_ts.1 (1)
Aguagallo doris 6_s_ts.1 (1)
 
Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1
 
Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1
 
Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1Aguagallo doris 6_s_ts.1
Aguagallo doris 6_s_ts.1
 
Mora diego 6_s_ti_1
Mora diego 6_s_ti_1Mora diego 6_s_ti_1
Mora diego 6_s_ti_1
 
Modelos de base de datos
Modelos de base de datosModelos de base de datos
Modelos de base de datos
 
Modelos de base de datos exp.4
Modelos de base de datos exp.4Modelos de base de datos exp.4
Modelos de base de datos exp.4
 
Gestores de bases de datos
Gestores de bases de datosGestores de bases de datos
Gestores de bases de datos
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 
Bases de datos orientadas a objetos y bases de datos objeto-relacionales
Bases de datos orientadas a objetos y bases de datos objeto-relacionalesBases de datos orientadas a objetos y bases de datos objeto-relacionales
Bases de datos orientadas a objetos y bases de datos objeto-relacionales
 
¿QUE ES UNA BASE DE DATOS? ¿COMO ES? ¿Y PARA QUE SIRVE?
¿QUE ES UNA BASE DE DATOS? ¿COMO ES? ¿Y PARA QUE SIRVE?¿QUE ES UNA BASE DE DATOS? ¿COMO ES? ¿Y PARA QUE SIRVE?
¿QUE ES UNA BASE DE DATOS? ¿COMO ES? ¿Y PARA QUE SIRVE?
 

Mehr von Hector Lumisaca Pinduisaca (13)

Word excel
Word excelWord excel
Word excel
 
Informaticabasica2
Informaticabasica2Informaticabasica2
Informaticabasica2
 
Informatica basica
Informatica basicaInformatica basica
Informatica basica
 
La planificación educativa y sus etapas
La planificación educativa y sus etapasLa planificación educativa y sus etapas
La planificación educativa y sus etapas
 
Hector mportaciom
Hector mportaciomHector mportaciom
Hector mportaciom
 
Tutorial de after efect hector lumisaca
Tutorial de after efect hector lumisacaTutorial de after efect hector lumisaca
Tutorial de after efect hector lumisaca
 
Lumisaca hector 6_a _t22
Lumisaca hector 6_a _t22Lumisaca hector 6_a _t22
Lumisaca hector 6_a _t22
 
Lumisaca hector 6_a _t21
Lumisaca hector 6_a _t21Lumisaca hector 6_a _t21
Lumisaca hector 6_a _t21
 
H multimedia ii_unidad_iii
H multimedia ii_unidad_iiiH multimedia ii_unidad_iii
H multimedia ii_unidad_iii
 
Pasos para vectorizar una imagen
Pasos para vectorizar una imagenPasos para vectorizar una imagen
Pasos para vectorizar una imagen
 
Hector lumisaca 6 a_t15
Hector lumisaca 6 a_t15Hector lumisaca 6 a_t15
Hector lumisaca 6 a_t15
 
Lumisaca hector_6_a_t11
Lumisaca  hector_6_a_t11Lumisaca  hector_6_a_t11
Lumisaca hector_6_a_t11
 
Lumisaca hector 6_a_tunidad 1
Lumisaca hector 6_a_tunidad 1Lumisaca hector 6_a_tunidad 1
Lumisaca hector 6_a_tunidad 1
 

Lumisaca hector 6_s_ti_1.pdf

  • 1. UNIVERSIDAD NACIONAL DE CHIMBORAZO FACULTAD DE CIENCIAS DE LA EDUCACIÓN HUMANAS Y TECNOLÓGICAS ESCUELA INFORMÁTICA APLICAD A LA EDUCACIÓN NOMBRE: HECTOR LUMISACA SEMESTRE: SEXTO TEMA: TRABAJO DE INVESTIGACIÓN - UNIDAD 1 DOCENTE: ING LEONARDO AYAVACA MATERIA: BASE DE DATOS II PERIODO: SEPTIEMBRE_MARZO RIOBAMBA-ECUADOR
  • 2. CONCEPTO BASES DE DATOS ORIENTADOS A OBJETOS Una base de datos es una colección de datos que puede constituirse de forma que sus contenidos puedan permitirse el encapsular, tramitarse y renovarse sencillamente, elementos de datos, sus características, atributos y el código que opera sobre ellos en elementos complejos llamados objetos. Las base de datos están constituida por objetos, que pueden ser de muy diversos tipos, y sobre los cuales se encuentran definidas unas operaciones donde interactúan y se integran con las de un lenguaje de programación orientado a objetos, es decir, que los componentes de la base de datos son objetos de los lenguajes de programación además que este tipo de base de datos están diseñadas para trabajar con lenguajes orientados a objetos también manipulan datos complejos de forma rápida y segura. Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientación a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no está limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. Los objetos estructurados se agrupan en clases. Las clases utilizadas en un determinado lenguaje de programación orientado a objetos son las mismas clases que serán utilizadas en una base de datos; de tal manera, que no es necesaria una transformación del modelo de objetos para ser utilizado. De forma contraria, el modelo relacional requiere abstraerse lo suficiente como para adaptar los objetos del mundo real a tablas. El conjunto de las clases se estructuran en subclases y superclases, los valores de los datos también son objetos. Muchas organizaciones que actualmente usan tecnología orientada a objetos también desean los beneficios de los sistemas de gestión de base de datos orientados a objetos. En otras palabras, se desea la migración de bases de datos y aplicaciones de bases de datos relacionales a orientadas a objetos. La migración a la tecnología de objetos consiste de la ingeniería reversa de los programas de aplicación y la migración de la base de datos. El objetivo de la migración de la base de datos es tener un esquema equivalente y la base de datos disponibles. Esto desde luego puede ser logrado por medio de la transformación manual del código de los programas lo cual resulta demasiado complicado. Para esto existen tres enfoques que hacen uso de la tecnología de objetos para bases de datos relacionales. Características Una de las características mandatarias de o reglas son: 1.-Debe tener un motor de base de datos. 2.-Debe ser un sistema orientado a objetos. Mandatarias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de base de datos orientados a objetos y estos son: Objetos complejos, Identidad de objetos, Encapsulación, Tipos o 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 Mandatarias 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 o el tipo de sistema y su uniformidad.
  • 3. 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 Y DESVENTAJAS 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).  Aplicabilidad. 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 esos sistemas sí resulten 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).
  • 4. 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. (torre, 2010) BASES DE DATOS RELACIONALES VS ORIENTADAS A OBJETOS Como hemos podido observar en la definición de ambos paradigmas de gestión e implementación de bases de datos, hay grandes diferencias entre el modelo más utilizado en la actualidad, el Modelo Relacional y el paradigma más utilizado en la informática en los últimos tiempos, el Modelo Objeto. En este apartado vamos a tratar de dar una visión global de ambos sistemas presentando las diferencias más importantes que se observan tratando de encontrar una explicación al hecho de que aún se siga utilizando en las bases de datos el modelo relacional y si, es mejor que el orientado a objetos, ¿por qué se sigue desarrollando este 2º modelo? Una principal diferencia la vemos ya al comparar la definición de las unidades básicas de información de cada caso. El modelo relacional define las tuplas como “instancias específicas de una entidad” con un identificador único y las propiedades de esa entidad. En cambio, en el caso de las bases de datos orientadas a objetos, se almacenan los objetos que se definen como “un objeto está modelando una situación o entidad del mundo real al tener una identificación única, propiedades específicas a sí misma, y la habilidad de trabajar en conjunto con objetos tanto de la misma o distinta especificación”. Las tuplas del modelo relacional carecen de esa habilidad de trabajar con otras tuplas ya que carecen de comportamiento. Además, el modelo objeto es capaz de representar situaciones del mundo real, en cambio el modelo relacional sólo trabaja con entidades, por lo tanto, si se quisiera modelar situaciones habría que adaptarlas, convirtiéndolas en entidades perdiendo por el camino parte de la información, o creando un modelo extremadamente complejo.
  • 5. La identificación única de las entidades/objetos también difiere en ambos casos. El modelo relacional utiliza el concepto de Clave Primaria para identificar a sus entidades de una manera única. Esta clave es un valor que puede introducir y cambiar el usuario del sistema gestor con la única restricción de que no se repita con ninguna otra clave primaria que contenga la tabla en ese momento, aunque también puede asignarla el propio sistema gestor. En cambio, el modelo objeto define el OID (Object Identity) que proveerá el sistema y le otorgará al objeto su identidad única. No puede ser cambiado ni introducido por el usuario. Al desaparecer el objeto, el sistema elimina ese OID pero no vuelve a asignárselo nunca a ningún objeto nuevo. Los modelos relacionales tradicionales sólo permitían tipos de datos simples ofrecidos por SQL y en última instancia por el sistema gestor. Esto hace bastante costoso trabajar con atributos multivariados pudiendo hacerse este tratamiento de 2 formas, o bien saltándose la 1FN o separando esos atributos en más tablas lo que, sin duda, carga mucho el sistema y convierte las consultas en algo muy complejo. El modelo objeto, por definición provee de un sistema de tipos análogo al lenguaje de programación con el que se utiliza. De esta forma permite definir nuevas clases así como utilizar la herencia para extender las ya creadas. Así se consigue aplicar toda la potencia de la Orientación a Objetos en las bases de datos. Los modelos relacionales utilizan el lenguaje estándar de consultas SQL, que es declarativo lo que hace que las consultas no vayan a la forma de encontrar el dato sino que sea el sistema gestor el que realice esta tarea. Además, el hecho de ser estándar permite que las aplicaciones lo utilicen sin importar el lenguaje de programación en el que están escritas. Por contra carga mucho el procesamiento y hace que haya que tratar los datos para convertirlos a objetos en el lenguaje de programación utilizado. El modelo objeto difiere en este sentido bastante. Utiliza varios sistemas diferentes dependiendo de la implementación que se esté utilizando. Hay sistemas, directamente imbuidos en el lenguaje de programación que hacen esta recuperación de los datos transparente al programador, trabajando con los objetos persistentes como si fueran objetos de memoria normales. Esta visión es muy eficiente e intuitiva pero al no tener un lenguaje específico para trabajar con las consultas no controla de forma alguna este acceso siendo vulnerable a errores del programador. Otra forma de implementar las consultas ha sido el estándar OQL (Object Query Language) definido por el Object Data Management Group (ODMG) que busca ser un estándar declarativo para consultas a bases de datos orientadas a objetos. Su uso sería análogo al de SQL pero, debido a su complejidad aún no hay ninguna implementación completa del estándar, sólo se han llegado a realizar subconjuntos como JDOQL y EJB QL.
  • 6. La forma de trabajar con los datos persistentes en el modelo relacional es seleccionando los datos que queremos que persistan en el tiempo y grabándolos de manera explícita mediante consultas de alta/modificación de SQL, previa transformación de los datos. Los objetos trabajan de otra forma. Dependiendo de la implementación particular puede ser que haya clases persistentes, cuyos objetos siempre se almacenen en disco, marcar especiales para los objetos que permitan discriminar cuáles se almacenarán, y otras técnicas. Esta es una de las partes más complejas de implementar de un sistema gestor de bases de datos orientados a objetos ya que se busca que este paso a datos persistentes sea lo más transparente posible para el programador de aplicaciones orientadas a objetos. Obviamente el modelo objeto es una forma de centrar el desarrollo y explotación de un sistema en la semántica del dato. En el modelo relacional había que adaptar la semántica a las capacidades del sistema de una manera bastante estricta. En cambio, cuando trabajamos con objetos podemos aplicar la semántica propia del problema de una manera mucho más natural, ya que este paradigma se basa en modelar el mundo real. Las relaciones entre entidades des modelo es una característica muy importante que cualquier base de datos moderna debe poseer. La orientación a objetos facilita mucho esta tarea gracias a los OID y a la herencia. Las relaciones de herencia, para lo cual se permite la herencia entre clases de la misma forma que en los lenguajes de programación, heredando el hijo todos los atributos y métodos que hubiera definido su padre. El resto de relaciones que hubiera que representar se haría mediante los OID que identifican unívocamente a un objeto. En las bases de datos relaciones, las relaciones de herencia se pueden simular mediante complejos sistemas que obligaban al programador a aplicar una serie de mecanismos que garantizaran la integridad. Y el resto de relaciones, por norma general crean una serie de tablas intermedias que complica las sentencias SQL necesarias para recuperar los datos. El acceso a los datos, en la gran mayoría de los sistemas gestores de bases de datos orientados a objetos, se realiza de una forma navegacional, al estilo de los modelos jerárquico y red lo cual obliga al usuario a conocer la ruta de acceso a los objetos. Esto, además de complicar el uso para usuarios no programadores, unido a la necesidad de requisitos indirectos de hardware y software debido al uso de objetos ralentiza las transacciones respecto al modelo relacional, lo que lo convierte en muchos casos en algo inaceptable. Las bases de datos orientadas a objetos permiten el almacenamiento de archivos multimedia ya que un objeto puede ser cualquier cosa. Las bases de datos relacionales no permiten esto y hay que simularlo guardando la dirección del archivo, con lo que no se garantiza que el archivo exista, o almacenando en un campo binario de longitud indeterminada el archivo completo sin capturar la propia base de datos de qué tipo de archivo se trata. Los sistemas gestores de bases de datos orientados a objetos proporcionan un importante control de versiones sobre los objetos almacenados, característica que junto a la capacidad de almacenar objetos multimedia antes citada, hace a estos sistemas muy válidos en campos como el CAD, aplicaciones científicas y otras aplicaciones igualmente específicas. (Luis, 2011)
  • 7. Bibliografía Luis, E. V. (25 de 10 de 2011). Bases de Datos Relacionales vs Orientadas a Objetos. Recuperado el 16 de 11 de 2014, de Bases de Datos Relacionales vs Orientadas a Objetos: http://twisensblog.blogspot.com/2011/10/bases-de-datos-relacionales-vs.html torre, a. d. (15 de 5 de 2010). base de datos orientadas a objetos. Recuperado el 16 de 11 de 2014, de base de datos orientadas a objetos: http://www.monografias.com/trabajos79/base- datos-orientadas-objetos/base-datos-orientadas-objetos2.shtml