JESSE URIEL LOPEZ LOPEZ

ENSAYO
7MA
UNIDAD

Utilizando la programacin orientada

a objetos es ms fcil modelar un
problema de la vida real con objetos.

BASES DE DATOS
ORIENTADOS A OBJETOS

INTRODUCCION
Las bases de datos orientadas a objetos son lo ms moderno en este siglo XXI
esto se debe al poder que tiene el paradigma de programacin orientada a
objetos, utilizando la programacin orientada a objetos es ms fcil modelar un
problema de la vida real con objetos y as lo agrupamos en clases, es ms fcil de
optimizar el problema, en este ensayo hablaremos sobre la programacin
orientada a objetos referente a las bases de datos, sus caractersticas, tambin
hablaremos sobre los datos complejos y datos bsicos y tambin hablaremos
sobre el concepto de herencia en SQL y herencia en tablas.

7.1 Visin general.

En una base de datos orientada a objetos, la informacin se representa mediante
objetos como los presentes en la programacin orientada a objetos. Cuando se
integra las caractersticas de una base de datos con las de un lenguaje de
programacin orientado a objetos, el resultado es un sistema gestor de base de
datos orientada a objetos (ODBMS, object database management system).

Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de
un lenguaje de programacin en uno o ms lenguajes de programacin a los que
d soporte.

Las bases de datos orientadas a objetos se disean para trabajar bien en

conjuncin con lenguajes de programacin orientados a objetos como Java, C#,
Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que
estos lenguajes de programacin.

Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un
buen rendimiento en la manipulacin de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo ms bajos y el mejor

rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y
tienen una integracin transparente con el programa escrito en un lenguaje de
programacin orientado a objetos, al almacenar exactamente el modelo de objeto
usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.
(WIKIPEDIA, 2015)

7.2 Tipos de datos complejos.

Los modelos de bases de datos tradicionales (relacional, red y jerrquico) han sido
capaces de satisfacer con xito las necesidades, en cuanto a bases de datos, de
las aplicaciones de

Gestin tradicional. Sin embargo, presentan algunas deciencias cuando se trata

de aplicaciones ms complejas o sosticadas como, por ejemplo, el diseo y
fabricacin en ingeniera (CAD/CAM, CIM), los experimentos cientcos, los
sistemas de informacin geogrca o los sistemas multimedia.
Los requerimientos y las caractersticas de estas nuevas aplicaciones dieren en
gran medida de las tpicas aplicaciones de gestin: la estructura de los objetos es
ms compleja, las transacciones son de larga duracin, se necesitan nuevos tipos
de datos para almacenar imgenes y textos, y hace falta denir operaciones no
estndar, especcas para cada aplicacin. Las bases de datos orientadas a
objetos se crearon para tratar de satisfacer las necesidades de estas nuevas
aplicaciones.
La orientacin a objetos ofrece exibilidad 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. Una caracterstica clave de las
bases de datos orientadas a objetos es la potencia que proporcionan al diseador
al permitirle especicar tanto la estructura de objetos complejos, como las
operaciones que se pueden aplicar sobre dichos objetos.
(Marqus, 2002)
Tipos de datos complejos:
Colecciones: Tambin conocidos como conjuntos, este tipo de datos clasifican los
arrays y los conjuntos en que los elementos pueden aparecer varias veces.
Tipos estructurados: Los tipos estructurados permiten representacin directa de
los atributos compuestos en los diagramas entidad-relacin.
Objetos de gran tamao: Desde ya hace varios aos que se necesita almacenar
datos con atributos muy grandes (Varios Mbytes), como libros, canciones, etc. E
incluso an ms grandes; como mapas de alta resolucin, video, etc. que puede
llegar fcilmente a los Gigabytes.
(WIKIPEDIA, 2015)

7.3 Tipos estructurados y herencia en SQL.

Los tipos estructurados permiten representar directamente los atributos
compuestos de los diagramas E-R. Por ejemplo, se puede definir el siguiente tipo
estructurado para representar el atributo compuesto nombre con los atributos
componentes nombre_pila y apellidos:

create type Nombre as

(nombre_pila varchar(20),
apellidos varchar(20))
final
De manera parecida, el tipo estructurado siguiente puede usarse para representar
el atributo compuesto direccin:
create type Direccion as
(calle varchar(20),
ciudad varchar(20),
codigo_postal varchar(9))
not final
En SQL estos tipos se denominan tipos definidos por el usuario. Las
especificaciones final indica que no se puede crear subtipos de nombre, mientras
que la especificacin not final de direccin indica que se pueden crear subtipos
de direccin. Ahora se pueden usar estos tipos para crear atributos compuestos en
las relaciones, con slo declarar que un atributo es de uno de estos tipos. Por
ejemplo, se puede crear una tabla cliente de la siguiente manera:
create table cliente (
nombre Nombre,
direccion Direccion,
fecha_nacimiento date)
O bien, realizando una estructura ms del tipo Cliente y generar la tabla a partir de
ella:
create type TipoCliente as
(nombre Nombre,
direccion Direccion,

fecha_nacimiento date)
not final
create table cliente of TipoCliente
Se puede tener acceso a los componentes de los atributos compuestos usando la
notacin punto; por ejemplo, nombre.nombre_pila devuelve el componente
nombre de pila del atributo nombre. El acceso al atributo nombre devolvera un
valor del tipo estructurado Nombre.
La siguiente consulta ilustra la manera de tener acceso a los atributos
componentes de los atributos compuestos. La consulta busca el apellido y la
ciudad
de
cada
cliente.
select nombre.apellido, direccion.ciudad
from cliente
Herencia.
La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En
primer lugar se considerar la herencia de los tipos y despus en el nivel de las
tablas:
Herencia de tipos: Los tipos derivados heredan los atributos de superclase; los
mtodos tambin se heredan por sus subtipos, al igual que los atributos. Sin
embargo, un subtipo puede redefinir el efecto de un mtodo declarndolo de
nuevo, y esto ser lo que se conoce como sobre escritura (overriding) del mtodo.
Supngase que se tiene la siguiente definicin de tipo para las personas:
create type Persona
(nombre varchar(20),
direccion varchar(20))
Puede que se desee almacenar en la base de datos informacin adicional sobre
las personas que son estudiantes y sobre las que son profesores. Dado que los
estudiantes y los profesores tambin son personas, se puede usar la herencia
para definir en SQL los tipos estudiante y profesor:
create type Estudiante
under Persona
(grado varchar(20),
departamento varchar(20))

create type Profesor

under Persona
(sueldo Integer,
departamento varchar(20))
(Abraham Silberschatz, 2002)
7.4 Herencia de tablas.
Cada tabla almacena la clave primaria, que se puede heredar de una tabla padre;
y los atributos definidos localmente. Los atributos heredados, aparte de la clave
primaria, no ser necesario guardarlos, podrn obtenerse mediante una reunin
con la super tabla basada en la clave primaria. Por lo que cada tabla almacena
todos los atributos heredados y definidos localmente. Cuando se inserta una tupla,
se almacena slo en la subtabla en la que se inserta y su presencia se infiere en
cada supertabla. El acceso a todos los atributos de una tupla es ms rpido, dado
que no se requiere una reunin:
Las subtablas de SQL se corresponden con el concepto de
especializacin/generalizacin de E-R Por ejemplo, supngase que se define la
tabla personas de la siguiente manera:
create table personas of Persona
A continuacin se puede definir las tablas estudiantes
como subtablas de personas, de la manera siguiente:

profesores

create table estudiantes of Estudiante

under personas
create table profesores of Profesor
under personas
Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Por tanto,
todos los atributos presentes en personas tambin estn presentes en las
subtablas.
Adems, cuando se declaran estudiantes y profesores como subtablas de
personas, todas las tuplas presentes en estudiantes y profesores pasan a estar
tambin presentes de manera implcita en personas. Por tanto, si una consulta usa
la tabla personas, no slo encuentra tuplas directamente insertadas en esa tabla,
sino tambin tuplas insertadas en sus subtablas, es decir, estudiantes y
profesores. No obstante, esa consulta slo puede tener acceso a los atributos que
estn presentes en personas.

SQL permite hallar tuplas que se encuentran en personas pero no en sus

subtablas usando en las consultas only personas en lugar de personas. La
palabra clave only tambin puede usarse en las sentencias delete y update.
Sin la palabra clave only, la instruccin delete aplicada a una supertabla, como
personas, tambin borra las tuplas que se insertaron originalmente en las
subtablas (como estudiantes); por ejemplo, la instruccin
delete from personas where P
Borrar todas las tuplas de la tabla personas, as como de sus
subtablas estudiantes y profesores, que satisfagan P. Si se aade la palabra
clave only a la instruccin anterior, las tuplas que se insertaron en las subtablas
no se ven afectadas, aunque satisfagan las condiciones de la clusula where.
(Abraham Silberschatz, 2002)
7.5 Tipos de arreglo multiconjunto en SQL.

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se
aadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en
SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento
puede aparecer varias veces.

Supngase que se desea registrar informacin sobre libros, incluido un conjunto

de palabras clave para cada libro. Supngase tambin que se deseara almacenar
almacenar el nombre de los autores de un libro en forma de array; a diferencia de
los elementos de los multiconjuntos, los elementos de los arrays estn ordenados,
de modo que se puede distinguir el primer autor del segundo autor, etc. El ejemplo
siguiente ilustra la manera en que se puede definir en SQL estos atributos como
arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),
sucursal varchar(20))

create type Libro as

(titulo varchar(20),
array_autores varchar(20) array[10],
fecha_publicacion date,
editor Editor,
conjunto_palabras_clave varchar(20) multiset)

create table libros of Libro

Creacin y acceso a los valores de los conjuntos

En SQL:1999 se puede crear un array de valores de esta manera:

array[Silberschartz, Korth, Sudarshan]

De manera parecida, se puede crear un multiconjunto de palabras clave de la

manera siguiente:

multiset[Silberschartz, Korth, Sudarshan]

Por lo tanto, se puede crear una tupla definido por la relacin libros como:

insert into libros

values
(Compiladores, array[Gmez, Santos],
new Editor(McGraw-Hill, Nueva York),
multiset[anlisis sintctico, anlisis])

Se puede tener acceso a los elementos del array o actualizarlos especificando el

ndice del array, por ejemplo, array_autores[1].

Consulta
de
los
atributos
valorados
como
conjuntos
Ahora se considerar la forma de manejar los atributos que se valoran como
conjuntos. Las expresiones que se valoran como conjuntos pueden aparecer en
cualquier parte en la que pueda aparecer el nombre de una relacin, como las
clusulas from.
Si se desea averiguar todos los libros que contengan las palabras base de datos
entre sus palabras clave, se puede usar la consulta siguiente:
select titulo
from libros
where base de datos in
(unnest(conjunto_palabras_clave))

(Abraham Silberschatz, 2002)

7.6 Identidad de los objetos y tipos de referencia en SQL.

Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a
objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos
de un tipo concreto. Por ejemplo, en SQL se puede definir el
tipo Departamento con el campo nombre y el campo director, que es una
referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la
manera siguiente:
create type Departamento(
nombre varchar(20),
director ref(Persona) scope personas)
create table departamentos of Departamento
En este caso, la referencia est restringida a las tuplas de la tabla personas. La
restriccin del mbito de referencia a las tuplas de una tabla es obligatoria en
SQL, y hace que las referencias se comporten como las claves externas.
La tabla a la que hace referencia debe tener un atributo que guarde el identificador
para cada tupla. Ese atributo, denominado atributo autorreferenciable (selfreferential attribute), se
instruccin create table:

declara

aadiendo

una

clusula ref

is a

la

create table personas of Persona

ref is id_persona system generated
En este caso, id_persona es el nombre del atributo, no una palabra clave, y la
instruccin system generated especifica que la base de datos genera de manera
automtica el identificador.
Para inicializar el atributo de referencia hay que obtener el identificador de la tupla
a la que se va a hacer referencia. Se puede conseguir el valor del identificador de
la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de
referencia, primero se puede crear la tupla con una referencia nula y luego definir
la referencia de manera independiente:

insert into departamentos

values (CS, null)
update departamentos set director = (select p.id_persona
from persona as p
where nombre = Martn)
where nombre = CS
Una alternativa a los identificadores generados por el sistema es permitir que los
usuarios generen los identificadores. El tipo del atributo autoreferencial debe
especificarse como parte de la definicin de tipos de la tabla a la que se hace
referencia, y la definicin de la tabla debe especificar que la referencia
estgenerada por el usuario (user generated):
create type Persona
(nombre varchar(20),
direccion varchar(20))
ref using varchar(20)
create table personas of Persona
ref is id_persona user generated
Al insertar tuplas en personas hay que proporcionar el valor del identificador:
insert into personas (id_persona, nombre, direccion) values
(01284567, Martn, Av del Segura, 23)
(Abraham Silberschatz, 2002)

7.7 Implementacin de las caractersticas OR.

Los sistemas de bases de datos relacionales orientadas a objetos son

bsicamente extensiones de los sistemas de bases de datos relacionales ya
existentes. Las modificaciones resultan claramente necesarias en muchos niveles
del sistema de base de datos.

Las interfaces de programas de aplicacin como ODBC y JDBC se han extendido

para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el
mtodo getObject() que devuelve un objeto Java Struct, a partir del cual se pueden
extraer los componentes del tipo estructurado. Tambin es posible asociar clases
de Java con tipos estructurados de SQL, y JDCB puede realizar conversiones
entre los tipos.
Lenguajes de programacin persistentes
Los lenguajes de las bases de datos se diferencan de los lenguajes de
programacin tradicionales en que trabajan directamente con datos que son
persistentes; es decir, los datos siguen existiendo una vez que el programa que los
cre haya concluido. Las relaciones de las bases de datos y las tuplas de las
relaciones son ejemplos de datos persistentes.

El acceso a las bases de datos es slo un componente de las aplicaciones del

mundo real. Mientras que los lenguajes para el tratamiento de datos como SQL
son bastante efectivos en el acceso a los datos, se necesita un lenguaje de

programacin para implementar otros componentes de las aplicaciones como las

interfaces de usuario o la comunicacin con otras computadoras. La manera
tradicional de realizar las interfaces de las bases de datos con los lenguajes de
programacin es incorporar SQL dentro del lenguaje de programacin.

Los lenguajes de programacin persistentes son lenguajes de programacin

extendidos con estructuras para el tratamiento de los datos persistentes. Los
lenguajes de programacin persistentes pueden distinguirse de los lenguajes con
SQL incorporado, al menos, de dos maneras:

1.- En los lenguajes incorporados el sistema de tipos del lenguaje anfitrin suele
ser diferente del sistema de tipos del lenguaje para el tratamiento de los datos. Los
programadores son responsables de las conversiones de tipo entre el lenguaje
anfitrin y SQL. Hacer que los programadores lleven a cabo esta tarea presenta
varios inconvenientes:

El cdigo para la conversin entre objetos y tuplas opera fuera del sistema
de tipos orientado a objetos y, por lo tanto, tiene ms posibilidades de presentar
errores no detectados.
La conversin en la base de datos entre el formato orientado a objetos y el
formato relacional de las tuplas necesita gran cantidad de cdigo. El cdigo para la
conversin de formatos, junto con el cdigo para cargar y descargar datos de la
base de datos, puede suponer un porcentaje significativo del cdigo total
necesario para la aplicacin.
Por el contrario, en los lenguajes de programacin persistentes, el lenguaje de
consultas se halla totalmente integrado con el lenguaje anfitrin y ambos
comparten el mismo sistema de tipos. Los objetos se pueden crear y guardar en la
base de datos sin ninguna modificacin explcita del tipo o del formato; los
cambios de formato necesarios se realizan de manera transparente.

2.- Los programadores que usan lenguajes de consultas incorporados son

responsables de la escritura de cdigo explcito para la bsqueda en la memoria
de los datos de la base de datos. Si se realizan actualizaciones, los
programadores deben escribir explcitamente cdigo para volver a guardar los
datos actualizados en la base de datos.

Por

el

contrario,

en

los

lenguajes

de

programacin

persistentes,

los

programadores pueden trabajar con datos persistentes sin tener que escribir
explcitamente cdigo para buscarlos en la memoria o volver a guardarlos en el
disco.

Sin embargo, los lenguajes de programacin persistentes presentan ciertos

inconvenientes que hay que tener presentes al decidir su conviene usarlos. Dado
que los lenguajes de programacin suelen ser potentes, resulta relativamente
sencillo cometer errores de programacin que daen las bases de datos.
La complejidad de los lenguajes hace que la optimizacin automtica de alto nivel,
como la reduccin de E/S de disco, resulte ms difcil. En muchas aplicaciones el
soporte de las consultas declarativas resulta de gran importancia, pero los
lenguajes de programacin persistentes no soportan bien actualmente las
consultas declarativas (SQL es un ejemplo).
(Abraham Silberschatz, 2002)
CONCLUSION
Sabemos que las BDOO representan el siguiente paso en la evolucin de las
bases de datos, para soportar el Anlisis, Diseo y Programacin OO. Las BDOO
permiten el desarrollo y mantenimiento de aplicaciones complejas con un costo
Significativamente menor.
Permiten que el mismo modelo conceptual se aplique al Anlisis, diseo,
programacin, definicin y acceso a la base de datos. Esto reduce el problema del
operador de traduccin entre los diferentes modelos a travs de todo el ciclo de
vida. El modelo conceptual debe ser la base de las herramientas CASE OO
totalmente integradas, las cuales ayudan a generar la estructura de datos y los
mtodos.
Las BDOO ofrecen un mucho mejor rendimiento de la mquina que las bases de
datos relacionales para aplicaciones o clases con estructuras complejas de datos.
Sin embargo, Las BDOO coexistirn con las bases de datos relacionales durante
los prximos aos, puesto que a menudo se utilizar un modelo relacional como
una forma de estructura de datos dentro de una BDOO.

Bibliografa
Abraham Silberschatz, H. F. (2002). FUNDAMENTOS DE BASES DE DATOS.
Madrid, Espaa: McGraw-Hill Inc. .
Marqus, M. (2002). Bases de Datos Orientado a Objetos. En M. Marqus,
Diseo de Sistemas de Bases de Datos (pg. 34).
WIKIPEDIA. (10 de Noviembre de 2015). WIKIPEDIA. Obtenido
https://es.wikipedia.org/wiki/Base_de_datos_orientada_a_objetos

de

WIKIPEDIA. (12 de Agosto de 2015). WIKIPEDIA.

https://es.wikipedia.org/wiki/Base_de_datos_objetorelacional#Tipos_Complejos

de

Obtenido