ELIZABETH LEON TORRES

INSTITUTO TECNOLOGICO DE TLALNEPANTLA

Nombre: Len
Torres
Elizabeth
No.Control:
14250867
Nombre del
profesor: Daz
Rincn Hilda
Grupo: T-33

BASE DE DATOS ORIENTADA A

OBJETOS
FUNDAMENTOS DE BASE DE DATOS

Ingeniera en tecnologas de la Informacin y

Comunicaciones

Len Torres Elizabeth

INDICE

Abstrac (Espaol) Pgina. 2

Abstrac (English) .Pgina 4

Objetivo de la investigacin Pgina 6

Introduccin . Pgina 6

Desarrollo

Pgina 7 - 17

o 7.1 Visin general.. Pgina 7

o 7.2 Tipos de datos complejos... Pgina
7
o 7.3 Tipos estructurados y herencia en SQL.. Pgina 8
o 7.4 Herencia de tablas..Pgina
10
o 7.5 Tipos de arreglo multiconjunto en SQL.. Pgina
12
o 7.6 Identidad de los objetos y tipos de referencia en SQL Pgina
13
o 7.7 Implementacin de las caractersticas OR Pgina
14

Conclusin Pgina 18

Referencias bibliogrficas...Pgina 18

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

ABSTRAC (ESPAOL)
El modelo de datos relacional orientado a objetos extiende el modelo de datos
relacional proporcionando un sistema de tipos enriquecido que incluye tipos
coleccin y orientacin a objetos.
La orientacin a objetos proporciona herencia con subtipos y subtablas, as como
referencias a objetos (tuplas).
Los tipos coleccin incluyen relaciones anidadas, conjuntos, multiconjuntos y
arrays, y el modelo relacional orientado a objetos permite que los atributos de las
tablas sean colecciones.
La norma SQL extiende el lenguaje de definicin de datos, as como el lenguaje
de consultas, y en particular da soporte a atributos de tipo coleccin, herencia y
referencias a tuplas. Estas extensiones intentan preservar los fundamentos
relacionales (en particular, el acceso declarativo a los datos) a la vez que se
extiende la potencia de modelado.
Los sistemas relacionales orientados a objetos (es decir, sistemas de bases de
datos basados en el modelo relacional orientado a objetos) proporcionan un
subcamino de migracin adecuado para los usuarios de las bases de datos
relacionales que desean usar las caractersticas de la orientacin a objetos.
Tambin se han descrito extensiones procedimentales proporcionadas por SQL
Se han discutido las diferencias entre los lenguajes de programacin persistente
y los sistemas relacionales orientados a objetos, y se han mencionado criterios
para escoger entre ellos.
Cabe mencionar algunas ventajas y desventajas del uso de los Sistemas Gestores
de Base de Datos Orientadas a Objetos.
Las ventajas de un SGBDOO son:

Mayor capacidad de modelado: Un objeto permite encapsular tanto un

estado como un comportamiento. Un objeto puede almacenar todas las
relaciones que tenga con otros objetos. Los objetos pueden agruparse para
formar objetos complejos (herencia).

Ampliabilidad: Se pueden construir nuevos tipos de datos a partir de los ya

existentes. Agrupar propiedades comunes de diversas clases e incluirlas en
una superclase, lo que reduce la redundancia. Reusabilidad de clases, lo
que repercute en una mayor facilidad de mantenimiento y un menor tiempo
de desarrollo.

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

Lenguaje de consulta ms expresivo: El acceso de navegacin desde un

objeto al siguiente es la forma ms comn de acceso a datos en un
SGBDOO. Mientras que SQL utiliza el acceso asociativo. El acceso de
navegacin es ms adecuado para gestionar operaciones como los
despieces, consultas recursivas, etc.

Adecuacin 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 SGBDOO han hecho que esos sistemas s resulten
efectivos para este tipo de aplicaciones.

Mayores prestaciones: Los SGBDOO proporcionan mejoras significativas

de rendimiento con respecto a los SGBD relacionales.

Las Desventajas de un SGBDOO son:

Carencia de un modelo de datos universal: No hay ningn modelo de datos

que est universalmente aceptado para los SGBDOO y la mayora de los
modelos carecen una base terica.

Carencia de experiencia: Todava no se dispone del nivel de experiencia del

que se dispone para los sistemas tradicionales.

Carencia de estndares: Existe una carencia de estndares general para

los SGBDOO.

Competencia. Con respecto a los SGBDR y los SGBDOR: Estos productos

tienen una experiencia de uso considerable. SQL es un estndar aprobado
y ODBC es un estndar de facto. Adems, el modelo relacional tiene una
slida base terica y los productos relacionales disponen de muchas
herramientas de soporte que sirven tanto para desarrolladores como para
usuarios finales.

La optimizacin de consultas compromete la encapsulacin: La

optimizacin de consultas requiere una compresin de la implementacin
de los objetos, para poder acceder a la base de datos de manera eficiente.
Sin embargo, esto compromete el concepto de encapsulacin.

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

El modelo de objetos an no tiene una teora matemtica coherente que le

sirva de base.
ABSTRAC (ENGLISH)

The relational data model extends the object-oriented relational data model
providing a rich type system including collection types and object orientation.
Object orientation provides heritage with subtypes and subtables as well as
references to objects (tuples).
The collection types include nested relations, sets, multisets and arrays, objectoriented and relational model allows attributes of the tables are collections.
The rule extends the SQL data definition language and query language, and in
particular supports collection type attributes, inheritance and references to tuples.
These extensions try to preserve relational bases (particularly, declarative data
access) while modeling power extends.
Object-oriented relational systems (ie, systems database based on objectoriented relational model) provide a subpath appropriate migration for users of
relational databases wanting to use the features of object orientation .
They have also described procedural SQL extensions provided by
We have discussed the differences between persistent programming languages
and object-oriented relational systems, and mentioned criteria for choosing
between them.
Include some advantages and disadvantages of using the Management Systems
Oriented Database Objects.
The advantages of OODBMS are:

Increased capacity for modeling: An object can encapsulate both a state and
a behavior. An object can store all the relationships you have with other
objects. Objects can be grouped to form complex objects (inheritance).

Expandability: You can build new data types from existing ones. Group
common properties of various kinds and include them in a superclass, which
reduces redundancy. Reusability of classes, which results in greater ease of
maintenance and reduced development time.

More expressive query language: Access navigation from one object to the
next is the most common form of access to data in OODBMS. While SQL

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

uses the associative access. Access navigation is best suited to manage

operations such as cuts, recursive queries, etc.

Adaptation to advanced database applications: There are many areas

where traditional DBMS have not had much success as CAD, CASE, OIS,
multimedia systems, etc. where the modeling capabilities of OODBMS have
made these systems do prove effective in these applications.

Increased performance: The OODBMS provide significant performance

improvements compared to relational DBMS.

Disadvantages of OODBMS are:

Lack of a universal data model: There is no data model that is universally

accepted for OODBMS and most models lack a theoretical basis.

Lack of experience: We still do not have the level of experience that is

available to traditional systems.

Lack of standards: There is a lack of overall standards for OODBMS.

Competition. Regarding the RDBMS and SGBDOR: These products have a

considerable use experience. SQL is a standard approved and ODBC is a
de facto standard. In addition, the relational model has a solid theoretical
foundation and relational products have many support tools that serve to
both developers and end users.

Query optimization compromises encapsulation: Query optimization requires

an understanding of the implementation of objects, for accessing the
database efficiently. However, this compromises the concept of
encapsulation.

The object model does not have a consistent mathematical theory that
serves as a base.

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

OBJETIVO DE LA INVESTIGACIN

Crear el modelado de bases de datos orientadas a objetos.

INTRODUCCIN

Los lenguajes de programacin persistentes aaden la persistencia y otras

caractersticas de las bases de datos a los lenguajes de programacin existentes
con sistemas de tipos orientados a objetos. Por el contrario, los modelos de datos
relacionales orientados a objetos extienden el modelo de datos relacional
proporcionando un sistema de tipos ms rico e incluyendo tipos de datos
complejos y la programacin orientada a objetos. Los lenguajes de consulta
relacionales como SQL tambin necesitan ser extendidos para trabajar con el
sistema de tipos enriquecido. Estas extensiones intentan conservar los
fundamentos relacionales en concreto, el acceso declarativo a los datos al
tiempo que extienden la capacidad de modelado.
Los sistemas de bases de datos relacionales orientados a objetos (es decir, los
sistemas de bases de datos basados en el modelo objeto-relacin) proporcionan
un modo de cambio adecuado para los usuarios de las bases de datos
relacionales que deseen utilizar caractersticas orientadas a objetos.
En primer lugar, se presenta la motivacin del modelo relacional anidado, que
permite relaciones que no cumplen la primera forma normal y permite la
representacin directa de las estructuras jerrquicas. Posteriormente se muestra
la manera de extender SQL aadiendo varias caractersticas relacionales
orientadas a objetos. El estudio se basa en la norma SQL.
Finalmente se analizan las diferencias entre los lenguajes de programacin
persistentes y los sistemas relacionales orientados a objetos y se mencionan los
criterios para la eleccin entre unos y otros.

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

DESARROLLO
7.1 Visin general
El modelo de datos relacional orientado a objetos extiende el modelo de datos
relacional ofreciendo un sistema de tipo ms rico que incluye tipos de datos
complejos y orientados a objetos. (M. Kroenke)
Los sistemas de bases de datos relacionales basado en objetos, es decir, los
sistemas de bases de datos basados en modelos objeto-relacin, ofrece un medio
de migracin cmodo para los usuarios de las bases de datos relacionales que
deseen usar caractersticas orientadas a objetos. (M. Kroenke)
El termino lenguajes de programacin persistentes hace referencia a las
extensiones de los lenguajes de programacin existentes que aaden persistencia
y otras caractersticas de las bases de datos usando el sistema de tipo nativo de
lenguaje de programacin. El termino sistema de bases de datos orientadas a
objetos se usa para hacer referencia a los sistemas de bases de datos que
soportan sistemas de tipos orientados a objetos permiten el acceso a directo a los
datos desde los lenguajes de programacin orientados a objetos usando el
sistema de tipo nativo del lenguaje. (M. Kroenke)
7.2 Tipos de datos complejos.
Se les llama datos complejos a aquellos que no son bsicos son aquellos datos
primitivos que contiene un lenguaje de programacin como: int, float, double,
boolean, char, etc. Tambin se puede decir que los datos bsicos son registros
bastante pequeos cuyos campos son atmicos, es decir, que no contienen
estructuras adicionales. (Date)
Los datos complejos o agrupados son aquellos que puedan contener un conjunto
de datos, en el caso de bases de datos podran ser atributos compuestos,
multivalorados, o atributos que representan cadenas grandes de string como
direcciones, fechas de nacimiento, etc. (Date)
Las siguientes estructuras son 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.
Pilas: Una pila es una lista de elementos en la que se pueden insertar y
eliminar elementos slo por uno de los extremos. (Date)
Colas: Son listas lineales de informacin a las se accede de un modo
determinado siendo el tipo FIFO (First In, First Out), lo que quiere decir es
que el primer dato en entrar tambin es el primer dato en salir, en las colas
no se permite el acceso aleatorio a ningn elemento concreto. (Date)

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

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 Gbytes. (Date)
Matrices o arrays: Los arrays son agrupaciones de datos homogneas,
contiguas y estticas. Los elementos que contienen son todos del mismo
tipo. El nmero de elementos que podemos guardar se define inicialmente
cuando escribimos el programa. (Date)

7.3 Tipos estructurados y herencia en SQL

Los tipos estructurados permiten representar
compuestos de los diagramas E-R. (Silberschatz)

directamente

los

atributos

Los tipos estructurados permiten representar directamente a los atributos

compuestos de los diagramas E-R. (Silberschatz)
Tomemos como ejemplo el siguiente caso: 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), cdigo_postal
varchar (9)) not final
En SQL estos tipos se dominan tipos definidos por el usuario. La especificacin
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. Se pueden usar esos tipos para crear atributos compuestos en la
relaciones, como solo declarar que un atributo es de uno de estos tipos.
(Silberschatz) Por ejemplo:
create tabla ciente (nombre Nombre, direccin Direccin, fecha_nacimiento date)
O bien, realizando una estructura ms del tipo cliente y generar la tabla a partir
de ella:
create type TipoClienteas (nombre Nombre, direccin Direccin, fecha_ncimiento
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
Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

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, direccin.ciudad from cliente.
Una manera alternativa de definir los atributos compuestos en SQL es usar tipos
de filas sin nombre. Sobre los tipos estructurados se pueden definir mtodos.
(Silberschatz)
-Herencia de tipos
Los mtodos de los tipos estructurados se heredan por sus subtipos, igual que los
tributos. Sin embargo, cada subtipo puede redefinir el efecto de los mtodos
volviendo a declararlos, usando overriding method en lugar de method en la
declaracin del mtodo. (Leon)
La norma de SQL tambin exige un campo adicional al final de la definicin de los
tipos, cuyo valor es final o not final. La palabra clave final indica que no se pueden
crear subtipos a partir del tipo dado, mientras que not final indica que se pueden
crear subtipos. Las herencias mltiples no en todas las versiones de SQL lo
permiten. (Leon)
Supngase que se dispone de la siguiente definicin de tipos para las personas:
create type Persona (nombre varchar(20), direccin varchar(20))
Puede que se desee guardar en la base de datos ms informacin sobre las
personas que sean estudiantes y sobre las que sean profesores. Dado que los
estudiantes y los profesores tambin son personas, se puede utilizar la herencia
para definir los tipos estudiante y profesor en SQL: (Jos)
create type Estudiante under Persona (curso varchar(20), departamento
varchar(20))
create type Profesor under Persona (sueldo integer, departamento varchar(20))
Tanto Estudiante como Profesor heredan los atributos de Persona, es decir,
nombre y direccin. Estudiante y Profesor se denominan subtipos de Persona y
sta, a su vez, es un supertipo de Estudiante y de Profesor. (Jos)
Los mtodos de un tipo estructurado se heredan por sus subtipos, al igual que los
atributos. Sin embargo, un subtipo puede redefinir el efecto de un mtodo
declarando de nuevo el mtodo, usando overriding method en lugar de method en
la declaracin del mtodo. (M. Kroenke)
Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

10

Supngase ahora que se desea guardar la informacin sobre los ayudantes, que
son simultneamente estudiantes y profesores, quizs incluso en departamentos
diferentes. Esto se puede hacer usando la herencia mltiple. Lo que se expone a
continuacin se basa en los borradores de la norma. (M. Kroenke)
Por ejemplo, si el sistema de tipos permite la herencia mltiple, se puede definir un
tipo para los ayudantes de la manera siguiente: (M. Kroenke)
create type Ayudante under Estudiante, Profesor
7.4 Herencia de tablas
Las subtablas de SQL se corresponden con el concepto de especializacin/
generalizacin de E-R. (Silberschatz)
Por ejemplo, supngase que se define la tabla personas de la manera siguiente:
create table persona of Persona
Se pueden definir entonces las tablas estudiantes y profesores como subtablas de
persona:
create table estudiantes of Estudiante under persona
create table profesores of Profesor under persona
Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre. Por tanto,
cada atributo presente en persona debe estar tambin presente en las subtablas.
(Silberschatz)
Adems, cuando se declaran estudiantes y profesores como subtablas de
persona, cada tupla presente en estudiantes o profesores tambin estn presentes
implcitamente en persona. As, si una consulta usa la tabla persona, encontrar
no slo las tuplas insertadas directamente en la tabla, sino tambin las tuplas
insertadas en sus subtablas estudiantes y profesores. Sin embargo, slo se puede
acceder a los atributos que estn presentes en persona. (Silberschatz)
Es posible la herencia mltiple con las tablas, como con los tipos. (Ntese, sin
embargo, que la herencia mltiple de tablas no se soporta en SQL) Por ejemplo,
se puede crear una tabla del tipo Ayudante:
create table ayudantes of Ayudante under estudiantes, profesores
Como resultado de la declaracin, cada tupla presente en la tabla ayudantes
tambin est presente implcitamente en las tablas profesores y estudiantes, y a
su vez en la tabla persona. SQL permite buscar tuplas que estn en persona pero
no en sus subtablas usando only persona en lugar de persona en la consulta.
(Silberschatz)
Hay algunos requisitos de consistencia para las subtablas. Antes de indicar las
restricciones es necesaria una definicin: se dice que las tuplas de una subtabla
Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

11

corresponden a las tuplas de una tabla padre si tienen los mismos valores para
todos los atributos heredados. As, las tuplas correspondientes representan la
misma entidad. (Silberschatz)
Los requisitos de consistencia para las subtablas son:
1. Cada tupla de la supertabla puede corresponder a lo sumo con una tupla de
cada una de sus tablas inmediatas.
2. SQL tiene una restriccin adicional que establece que todas las tuplas que
se correspondan se deben derivar de una tupla (insertada en una tabla).
(Silberschatz)
Por ejemplo, sin la primera condicin se podran tener dos tuplas en estudiantes (o
en profesores) correspondiente a la misma persona. La segunda condicin
descarta
una
tupla
en
persona
correspondiente
a
tuplas
de
estudiantes.estudiantes y profesores, a menos que esas tuplas estn presentes
implcitamente porque se insert una tupla en la tabla ayudantes, que es una
subtabla de profesores y estudiantes. (Silberschatz)
Dado que SQL no soporta herencia mltiple, la segunda condicin realmente
impide que una persona sea tanto profesor como estudiante. El mismo problema
surgira si no existiese la subtabla ayudantes, incluso si hubiese herencia mltiple.
Obviamente sera til modelar una situacin donde una persona pueda ser
profesor y estudiante, incluso si no est presente la subtabla comn ayudantes.
Por tanto, puede ser til eliminar la segunda restriccin de consistencia.
(Silberschatz)
Las subtablas pueden guardarse de manera eficiente sin rplica de todos los
campos heredados de una de las dos siguientes formas:

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 hace falta guardarlos y pueden obtenerse mediante
una reunin con la supertabla basada en la clave primaria.
Cada tabla almacena todos los atributos heredados y definidos localmente.
(Silberschatz)

Cuando se inserta una tupla se almacena slo en la tabla 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. Sin embargo, en el
caso de que no se considere la segunda restriccin de integridad es decir, una
entidad se puede representar en dos subtablas sin estar presente en una subtabla
comn de ambas esta representacin puede resultar en duplicacin de
informacin. (Silberschatz)
7.5 Tipos de arreglo multiconjunto en SQL

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

12

Cabe mencionar que multiconjunto es un conjunto no ordenado, en el que cada

elemento puede aparecer varias veces. Los multiconjuntos son como los
conjuntos, salvo que los conjuntos, salvo que los conjuntos permiten que cada
elemento aparezca, como mucho, una vez. (M. Kroenke)
En general, los atributos multivalorados de los esquemas E-R se pueden asignar
en SQL a atributos valorados como multiconjuntos; si el orden es imprtate, se
pueden usar los arrays de SQL en lugar de los multiconjuntos. (M. Kroenke)
-Consulta de los atributos valorados como conjuntos
Ahora se considerara 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
clausulas from. (M. Kroenke)
Dado que el atributo es un campo que se valora como conjunto, unnest puede
usarse en una clusula from en la que se espere una relacin. Tngase en cuenta
que la variable tupla es visible para esta expresin, ya que se ha definido en la
clusula from. (M. Kroenke)
Al desanidar un array la consulta anterior pierde informacin sobre el orden de los
elementos del array. Se pueden usar las clusula unnest with ordinality para
obtener esta informacin. (M. Kroenke)
La clusula with ordinality genera un atributo adicional que registra la posicin del
elemento en el array. Se puede usar una consulta parecida, pero sin la clusula
with ordinality, para generar la relacin. (M. Kroenke)
-Anidamiento y des anidamiento.
La transformacin de una relacin anidada en una forma con menos atributos de
tipo relacin se denomina des anidamiento. (M. Kroenke)
El proceso inverso de transformar una relacin en una relacin anidada se
denomina anidamiento. El anidamiento puede realizarse mediante una expresin
de la agrupacin en SQL. La funcin collect devuelve el multiconjunto de valores;
en lugar de crear un solo valor se puede crear una relacin anidada. (M. Kroenke)
SQL ofrece gran variedad de operadores para multiconjuntos, incluido la funcin
set, que calcula versin libre duplicada del multiconjunto, la operacin agregada
intersection, cuyo resultado es la interseccin de todos los multiconjuntos de un
grupo, y el predicado submultiset, comprueba si el multiconjunto est contenido en
otro multiconjunto. (M. Kroenke)
7.6 Identidad de los objetos y tipos de referencia SQL
Los lenguajes orientados a objetos proporcionan la posibilidad de hacer referencia
a los objetos. El atributo de un tipo puede ser una referencia a un objeto de un tipo

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

13

especificado. Por ejemplo, en SQL se puede definir un tipo Departamento, con

campos nombre y director, que es una referencia al tipo Persona, y una tabla
departamentos de tipo Departamento, como sigue (Silberschatz):
create type Departamento(nombre varchar(20), director ref(Persona) scope
persona)
create table departamentos of Departamento
La referencia en este ejemplo est restringida a tuplas de la tabla persona. La
restriccin de scope de una referencia a las tuplas de una tabla es obligatoria en
SQL y hace que las referencias se comporten como claves externas.
(Silberschatz)
Se puede omitir la declaracin scope persona de la declaracin de tipos y en su
lugar aadirla a la instruccin create table. (Silberschatz)
create table departamentos of Departamento (director with options scope persona)
Para inicializar un atributo referencia es necesario obtener el identificador de la
tupla a la que se va a hacer referencia. Se puede obtener el valor del identificador
de una tupla mediante una consulta. As, para crear una tupla con el valor
referencia, se puede crear en primer lugar la tupla con una referencia nula y
despus establecer la referencia (Silberschatz):
insert into departamentos values (Informtica, null) update departamentos
set director = (select ref(p) from persona as p where nombre = Juan) where
nombre = Informtica
Esta sintaxis para acceder al identificador de una tupla est basada en la sintaxis
de Oracle. SQL adopta un enfoque diferente, en el que la tabla referenciada debe
tener un atributo que almacene el identificador de la tupla. Este atributo,
denominado atributo autorreferencial, se declara aadiendo la clusula ref is a la
instruccin create table. (Silberschatz)
create table persona of Persona ref is ido system generated
Donde ido es un nombre de atributo, no una palabra clave (Silberschatz).
La subconsulta anterior podra usar select p.ido en lugar de select ref(p).
Una alternativa a los identificadores generados por el sistema es permitir a los
usuarios generar identificadores. (Silberschatz)
El tipo del atributo autorreferencial se debe especificar como parte de la definicin
de tipos de la tabla referenciada, y la definicin de tabla debe especificar que la
referencia la genera el usuario (user generated). (Silberschatz)
create type Persona (nombre varchar(20), direccin varchar(20)) ref using
varchar(20) create table persona of Persona ref is ido user generated
Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

14

Al insertar una tupla en persona se debe proporcionar un valor para el

identificador:
insert into persona values (01284567, Juan, Plaza Mayor, 1)
Ninguna otra tupla de persona o sus supertablas pueden tener el mismo
identificador. Se puede entonces usar el valor del identificador al insertar una tupla
en departamentos, sin necesitar una consulta separada para obtener el
identificador. (Silberschatz)
insert into departamentosvalues (Informtica, 01284567)
Es posible incluso usar un valor existente de clave primaria como identificador,
incluyendo la clusula ref from en la definicin de tipos (Silberschatz):
create type Persona (nombre varchar(20) primary key, direccin varchar(20)) ref
from nombre
create table persona of Persona ref is ido derived
Ntese que la definicin de tabla debe especificar que la referencia es derivada y
an debe especificar un nombre de atributo autorreferencial. Al insertar una tupla
en departamentos, se puede usar: (Silberschatz)
insert into departamentos values (Informtica, Juan)
7.7 Implementacin de las caractersticas O-R
Las modificaciones resultan claramente necesarias en muchos niveles del sistema
de bases de datos. Sin embargo, para minimizar las modificaciones en el cdigo
del sistema de almacenamiento (almacenamiento de relaciones, ndices, etc.). Los
tipos de datos complejos soportados por los sistemas relacionales orientados a
objetos se pueden traducir al sistema de tipos ms cansillos de las bases de datos
relacionales. (Jos)
Las subtablas se pueden almacenar de manera eficiente, sin rplica de todos los
campos heredados, de una de esta manera: (Jos)

Cada tabla almacena la clave primaria (que puede a ver heredado de una
tabla madre) y los atributos que se definen de localmente. No hace falta
almacenar los atributos heredados (que no sea la clave primaria), se
pueden obtener mediante una reunin con la supertabla, de acuerdo con la
clave primaria. (Jos)

Cada tabla almacena todos los atributos heredados y definidos localmente

cuando se inserta una tupla solo se almacena en la tabla en la que se
inserta en su presencia que se infiere en cada una de las supertablas. El
acceso de todos los atributos es ms rpido, ya que no hace falta ninguna
reunin. (Jos)

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

15

Lenguajes de programacin persistentes

Los lenguajes de las bases de datos se diferencian de los lenguajes de
programacin tradicionales que trabajan directamente con datos que son
persistentes; es decir, los datos siguen existiendo una vez el programa que los
creo all concluido. (Jos)
Los lenguajes de programacin persistentes son lenguajes de programacin
extendidos con estructuras para el tratamiento de los datos persistentes. Los
lenguajes de programacin persistente pueden distinguirse con los lenguajes SQL
incorporando, al menos, de dos maneras: (Jos)
1.

En los lenguajes incorporados el sistema de tipos de lenguaje anfitrin

suele ser diferente del sistema de tipos de lenguajes por el tratamiento de
los datos. (Jos)

2.

Los programadores que usan lenguajes de consultas incorporados son

responsables de la escritura de cdigo explicito para la bsqueda en la
memoria de los datos de la base de datos. (Jos)

Persistencia de los objetos

Persistencia por clases. El enfoque ms sencillo pero el menos

conveniente, consisten en declarar que una clases es persistente. Todos los
objetos de la clase son, por tanto, persistentes de manera predeterminada.
Todos los objetos de las clases no persistentes son transitorios. (Jos)
Persistencia por creacin. En este enfoque se introduce una sintaxis nueva
para crear los objetos persistentes mediante la extensin de la sintaxis.
(Jos)
Persistencia por marcas. Una variante del enfoque anterior es marcar los
objetos como persistentes despus de haberlos creado. Todos los objetos
se crean como transitorios pero, si un objeto tiene que persistir ms all de
la ejecucin del programa, hay que marcarlo como persistente de manera
explcita antes de que este concluya. (Jos)
Persistencia por alcance.
Uno o varios objetos declaran objetos
persistentes (objetos de raz) de manera explcita. Todos los dems objetos
sern persistencia si (y solo s) se puede alcanzar mediante un objeto raz
mediante una secuencia mediante una secuencia de una o varias
referencias. (Jos)

Identidad de los objetos y punteros

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

16

Dentro de los procedimientos. La identidad solo persiste durante la

ejecucin de un nico procedimiento. Un ejemplo de identidad dentro de los
programas son las variables locales de los procedimientos. (M. Kroenke)
Dentro de los programas. La identidad solo persiste durante la ejecucin de
un nico programa o de una nica consulta. (M. Kroenke)
Entre programas. La entidad persiste de una ejecucin del programa a otra.
Los punteros a los datos del sistema de archivos del disco ofrecen identidad
entre programa a otra. Los punteros a los datos del sistema de archivos del
disco ofrecen identidad entre los programas, pero pueden cambiar si se
modifica la manera en que los datos se guardan en el sistema de archivos.
(M. Kroenke)
Persistente. La identidad no solo persiste entre las ejecuciones del
programa sino tambin entre reorganizaciones estructurales de los datos.
Es la forma persistente de identidad necesaria para los sistemas orientados
a objetos. (M. Kroenke)

Sistemas orientados a objetos y sistemas relacionales orientados a objetos

Ya se han estudiado las bases de datos relacionales orientadas a objetos, que son
bases de datos orientadas a objetos construidos sobre el modelo relacional, asi
como las bases de datos orientados a objetos, que se crean alrededor de los
lenguajes de programacin persistentes. (M. Kroenke)
Los puntos fuertes de los diversos tipos de sistemas de bases de datos pueden
resumirse de la manera siguiente: (M. Kroenke)

Sistemas relacionales: Tipos de datos sencillos, consultas potentes,

proteccin elevada. (M. Kroenke)
Bases de datos orientadas a objetos basadas en lenguajes de
programacin persistentes: Tipos de datos complejos, integracin con los
lenguajes de programacin, elevado rendimiento. (M. Kroenke)
Sistemas relacionales orientados a objetos: Tipos de datos complejos,
lenguajes de consultas potentes, proteccin elevada (M. Kroenke)

Caractersticas de las Bases de Datos Orientadas a Objetos y diferencias de stas

con respecto a las relacionales.
Mientras que en una BDR los datos a almacenar se almacenan representados en
tablas en un BDOO los datos se almacenan como objetos. Un objeto en BDOO
como en POO es una entidad identificable unvocamente que describe tanto el
estado como el comportamiento de una entidad del mundo real. El estado de un
objeto es descrito mediante atributos mientras que su comportamiento es definido
mediante mtodos. (Jos)

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

17

Las caractersticas asociadas a las BDOO son:

Objetos: cada entidad del mundo real se modela como un objeto (Jos).
La forma de identificar objetos es mediante un identificador de objetos (OID,
Object Identifier), nico para cada objeto. Generalmente este identificador
no es accesible ni modificable para el usuario (modo de aumentar la
integridad de entidades y la integridad referencial). Los OID son
independientes del contenido. Es decir, si un objeto cambia los valores de
atributos, sigue siendo el mismo objeto con el mismo OID. Si dos objetos
tienen el mismo estado pero diferentes OID, son equivalentes pero tienen
identidades diferentes. (Jos)
Encapsulamiento: cada objeto contiene y define procedimientos (mtodos)
y la interfaz mediante la cual se puede acceder a l y otros objetos pueden
manipularlo. La mayora de los SGBDOO permite el acceso directo a los
atributos incluyendo operaciones definidas por el propio SGBDOO las
cuales leen y modifican los atributos para evitar que el usuario tenga que
implementar una cantidad considerable de mtodos cuyo nico propsito
sea el de leer y escribir los atributos de un objeto. Generalmente, los
SGBDOO permiten al usuario especificar qu atributos y mtodos son
visibles en la interfaz del objeto y pueden invocarse desde afuera. (Jos)

Base de datos orientada a objetos|Fundamentos de base de datos

Len Torres Elizabeth

18

CONCLUSIN

La BDOO permite el desarrollo y mantenimiento de aplicaciones complejas con un

costo bajo. Permitiendo al modelo conceptual aplicarse al anlisis, diseo,
programacin, definicin, acceso a la BD.
La BDOO ofrece un mayor rendimiento de la mquina, que las bases de datos por
relacin, para aplicaciones o clases con estructuras complejas de datos.

REFERENCIAS BIBLIOGRAFICAS
(Date) Introduccin a los sistemas de Bases de Datos Relacionales - Sptima
Edicin - C.J. Date
(Jos) Torres Piqueres, Jos (Bases de Datos Orientadas a Objetos)
(Silberschatz) Silberschatz, A., Korth, H.F. y Sudarshan, S., (2007) Fundamentos
de bases de dato, McGraw-Hill,S.A.,Espana.
(Leon) Tema 8. Bases de datos orientadas a objetos. Juan Ignacio Rodrguez de
Leon
(M. Kroenke)M, Kroenke, David, (2003), Procesamiento de Base de Datos
Orientada a Objetos en Procesamiento de Base de Dato, Pearson Educacin
(Mxico) p.555, 556,557.

Base de datos orientada a objetos|Fundamentos de base de datos