SISTEMAS MANEJADORES DE BASES DE DATOS ORIENTADAS A OBJETOS SMBDOO

1
SISTEMAS MANEJADORES DE BASES DE DATOS ORIENTADAS
A OBJETOS (SMBDOO)
2
INTRODUCCIÓN A LOS SISTEMAS DE BASES DE DATOS OO
(SBDOO)
3

• INTRODUCCIÓN
• Hace algunos años, la creación de nuevas
  aplicaciones requerían de una difícil selección
  de información para muchas fuentes.
• Los programas eran dependientes de las
  estructuras de los datos almacenados, haciendo
  estas estructuras difíciles al cambio.
• Sin embargo, los Sistemas de BD (SBD) han
  mejorado los procesos de desarrollo de aplicación
  en grandes ambientes de datos intensivos,
  proporcionando una sencilla y uniforme vista de
  datos expresada en términos de estructuras
  independientes.

4

• INTRODUCCIÓN
• Su alto nivel de características lingüísticas y
  sus facilidades para compartir información de una
  manera controlada, hace posible que se puedan
  crear aplicaciones integradas más fácilmente.
• La integridad de los datos está controlada por el
  SBD.
• Es decir, el SBD debe ser responsable de cada
  programa de aplicación, dentro de la BD.
• Existe un conjunto de rutinas que facilitan el
  formateo de datos y accesos a los mismos.

5

• INTRODUCCIÓN
• En la década pasada se generó mucho interés sobre
  los SBDOO.
• Estos sistemas tienen su origen en los lenguajes
  de POO.
• Donde los usuario no tienen que luchar contra las
  construcciones orientadas a la máquina (p. e.
  campos, atributos, etc).
• Sino que en su lugar deben tener la posibilidad
  de manejar objetos y operaciones sobre esos
  objetos, que se asemejan mucho más a sus
  contrapartes en la realidad.

6

• INTRODUCCIÓN
• En otras palabras, la idea fundamental es elevar
  el nivel de abstracción.
• Elevar el nivel de abstracción es
  incuestionablemente un objetivo valioso y el
  paradigma de objetos ha tenido mucho éxito para
  satisfacer ese objetivo.
• La pregunta sería Si el paradigma de la POO
  también puede ser aplicado satisfactoriamente en
  las BD.

7

• INTRODUCCIÓN
• La idea de manejar una BD que está compuesta de
  objetos complejos, en lugar de tener que
  manejar atributos, inserción de tuplas y claves
  externas, etc., es obviamente más atractiva desde
  el punto de vista del usuario.
• Aunque las disciplinas de los lenguajes de
  Programación y la Administración de BD tienen
  mucho en común, también difieren en determinados
  aspectos
• Un programa de aplicación está hecho, por
  definición, para resolver algún problema
  específico.

8

• INTRODUCCIÓN
• Por el contrario, una BD está hecha para resolver
  una variedad de problemas diferentes, y algunos
  de ellos ni siquiera son conocidos el momento de
  establecer las BD.
• Mucha gente cree que los Sistemas de Objetos
  representan un gran salto hacia delante en la
  tecnología de BD.
• Creen que las técnicas de objetos son el enfoque
  a escoger para las áreas de aplicaciones
  complejas.

9

• Actualmente, los sistemas de software han puesto
  un ambiente típico, incluyen herramientas,
  editores de esquema, verificadores de diseño y
  programas de circuito disponibles, y todo
  integrado.
• La disponibilidad de alta ejecución en las
  estaciones de trabajo gráfica, se han
  incrementado tanto en la expansión como en la
  complejidad de las aplicaciones de los datos
  intensivos.
• Algunos ejemplos son
• Diseño y Manufactura Asistido por Computadora
  (CAD/CAM)
• Ingeniería de Software Asistida por Computadora
  (CASE).

10

• Sistemas de Información de Oficinas (OIS).
• Manufactura Interada por Computadora (CIM).
• Sistema de Información Geográfica (GIS).
• Ciencia y Medicina.
• Todas éstas son áreas en las que los productos
  SQL clásicos tienden a incurrir en problemas.
• Sin embargo, a lo largo de los años han sido
  publicados muchos artículos técnicos sobre estos
  temas y más recientemente, han entrado al mercado
  varios productos comerciales.

11

• Pero el problema continúa, sobre todo en nuevas
  herramientas, que utilizan subsistemas que
  requieren de muchos números de datos
  persistentes.
• Donde el nivel de complejidad de estos programas
  y de los datos, han llegado más allá de la
  capacidad de los SBD tradicionales.
• Actualmente los programas de aplicación, en
  ambientes de diseño, almacenan sus datos en
  estructuras de archivos de aplicación específica.

12

• Aquí el estado del arte es difícil, como en la
  misma etapa que existió después de introducir la
  tecnología de BD.
• El desarrollo de las Bases de Datos Orientadas a
  Objetos (BDOO), con una gran cobertura, han
  surgido por esta necesidad.
• Además combina las mejores cualidades de los
  archivos planos, las bases jerárquicas y
  relacionales.
• Las BDOO representan el siguiente paso (?) en la
  evolución de las BD para soportar el análisis,
  diseño y Programación Orientada a Objetos (POO).

13

• Estás permiten el desarrollo y mantenimiento de
  aplicaciones complejas, ya que se puede utilizar
  un mismo modelo conceptual y así aplicarlo al
  análisis, diseño y programación.
• Reduciendo el problema entre los diferentes
  modelos a través de todo el ciclo de vida, con un
  costo significativamente menor.
• Como cualquier BD programable, una BDOO da un
  ambiente para el desarrollo de aplicaciones con
  un depósito persistente listo para su explotación.

14

• Permiten que el mismo modelo conceptual se
  aplique al análisis, diseño, programación,
  definición y acceso a la BD.
• Esto reduce el problema del operador de
  traducción entre los diferentes modelos a través
  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 métodos.

15

• Además las BDOO ofrecen un mejor rendimiento en
  las máquinas que las BD por relación, para
  aplicaciones o clases con estructuras complejas
  de datos.
• Sin embargo, las BDOO coexistirán con las BD
  Relacionales, como una forma de estructura de
  datos dentro de una BDOO.

16
ANTECEDENTES
17

• El propósito de los Sistemas de Bases de Datos
  (SBD) es la gestión de grandes cantidades de
  información.
• Las primeras BD surgieron del desarrollo de los
  sistemas de gestión de archivos.
• Estos sistemas primero evolucionaron en BD de Red
  o en BD Jerárquicas y, más tarde, en BD
  Relacionales.
• Las aplicaciones de BD tradicionales consisten en
  tareas de procesamiento de datos, tales como
  servicios bancarios y la gestión de nómina.

18

• Tales aplicaciones presentan conceptualmente
  tipos de datos simples.
• Los elementos de datos básicos son registros
  bastante pequeños y cuyos campos son atómicos.
• Es decir, estos campos no contienen estructuras
  adicionales y en los que se cumple la primera
  forma normal.

19

• Las BD Relacionales (BDR) almacenan los datos en
  forma de tablas, renglones y columnas.
• De tal manera, la BDR no son adecuadas para
  almacenar objetos, ya que pueden contener
  estructuras complejas de elementos de datos y
  también apuntadores a otros objetos.
• Además, los objetos incluyen instrucciones
  ejecutables, o métodos, y para hacer persistentes
  a los objetos también deben proporcionar ciertos
  medios para almacenarlos.
• Los SMBDOO, se desarrollaron a principios de la
  década de los 90s para proporcionar un
  almacenamiento de objetos persistentes.

20

• Sin embargo estos productos no se han
  comercializado con éxito debido a que necesitan
  convertir los datos al formato MDOO.
• Las organizaciones no realizan esta conversión
  porque es muy costosa y las ganancias no
  compensan la inversión.
• En respuesta a esto, los proveedores de los DBMS
  tradicionales están aumentando las capacidades de
  sus productos para permitir el almacenamiento de
  objetos.
• Así como también, el almacenamiento tradicional
  de datos relacionales.

21

• A tales productos se les llama SMBD de Objeto/
  Relacionales, y probablemente su uso aumentará en
  los próximos años.
• En particular Oracle, ha desarrollado diversos
  recursos para la modelación y almacenamiento de
  objetos.
• Existen dos estándares importantes de objetos El
  SQL3 y el ODMG-93

22

• Las aplicaciones de las BD en áreas como el
  Diseño Asistido por Computadora, la Ingeniería de
  Software y el Procesamiento de Documentos no se
  ajustan al conjunto de suposiciones que se hacen
  para aplicaciones del estilo de procesamiento de
  datos.
• El Modelo de Datos Orientado a Objetos (MDOO) se
  ha propuesto para tratar algunos de estos nuevos
  tipos de aplicaciones.
• El MDOO es una adaptación a los SBD tradicionales.

23

• El enfoque OO para la programación fue
  introducida por primera vez con el lenguaje
  Simula 67.
• Que se diseñó para la programación de simulación.
• Smalltalk fue uno de los primeros lenguajes de
  Programación OO (POO) para aplicaciones
  generales.
• Actualmente, los lenguajes Java y C son los
  lenguajes de POO más usados.

24

• La POO se basa en el concepto de encapsulamiento
  de datos y código que opera sobre éstos en un
  objeto.
• La ventaja de la encapsulación es que permite que
  la representación interna de los objetos, sea
  cambiada sin necesidad de que las aplicaciones
  que los usan tengan que ser reescritas.
• La encapsulación implica la Independencia Física
  de los Datos.
• Los objetos encapsulados son descritos por
• Una Memoria Privada (Miembros o Atributos).
• Interfaz Pública (Métodos).

25

• Los objetos estructurados se agrupan en clases.
• El conjunto de clases está estructurado en sub y
  superclases, basado en una extensión del concepto
  ISA del modelo Entidad - Relación.
• Puesto que el valor de un dato en un objeto,
  también puede ser un objeto, es posible
  representar el contenido del objeto dando como
  resultado un objeto compuesto.

26
PRINCIPIOS DE OO
27

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Es conveniente aclarar que muchos conceptos de
  objetos (o definiciones de éstos) son bastante
  imprecisos y hay muy poco consenso verdadero y
  mucho desacuerdo, incluso en el nivel más básico.
• En particular, no hay un Modelo de datos de
  objetos abstracto ni formalmente definido.

28

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• En una BDOO, cualquier cosa es un objeto y se
  manipula como tal.
• Un Objeto es una instancia que responde a
  mensajes activando un método.
• La estructura interna no es visible para los
  usuarios de ese objeto.
• Los sistemas OO proporcionan el concepto de
  Identificador del Objeto (OID) para identificar a
  los objetos.

29

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Los identificadores de los objetos son únicos.
• Cada objeto tiene un solo identificador y no hay
  dos objetos que tengan el mismo identificador.
• Generalmente el identificador lo genera el
  sistema de manera automática.
• A diferencia de las BD relacionales donde un
  valor de dato único, se genera de manera externa
  al sistema.

30

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Hay muchas situaciones en las que hacer que el
  sistema genere identificadores de manera
  automática resulta una ventaja.
• Dado que libera a los seres humanos de llevar a
  cabo esa tarea.
• Sin embargo, esta característica debe manejarse
  con precaución.
• Los identificadores generados por el sistema
  suelen ser específicos el mismo.

31

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Si se desplazan los datos a un sistema de BD
  diferente, hay que traducirlos.
• Además, los identificadores generados por el
  sistema pueden resultar redundantes, si las
  entidades que se modelan ya disponen de
  identificadores unívocos externos al sistema.
• Por lo general, los SMBDR se apoyan en claves
  definidas y controladas por el usuario (claves de
  usuario), para efectos de identificación y
  referencia de entidades.
• En realidad los apuntadores estilo OID están
  expresamente prohibidos en las BDR.

32

• PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Los objetos soportan una serie de
  características
• Se agrupan en tipos denominados clases.
• Contienen datos internos que definen su estado
  actual.
• Soportan ocultación de datos.
• Pueden heredar propiedades de otros objetos.
• Pueden comunicarse con otros objetos enviando o
  pasando mensajes.
• Tienen métodos que definen su comportamiento.

33

• Las clases son una colección de objetos con
  propiedades similares, compartimiento común,
  relaciones comunes a otras clases.
• La instancia es un objeto con propiedades
  definidas en su descripción de la clase.
• El mensaje es una clase que debe tener un método
  correspondiente.  Un mensaje puede ser enviado a
  un objeto a ejecutar una acción.
• El método es una lista de instrucciones
  detalladas que definen cómo responde un objeto a
  un mensaje en particular.

34

• La superclase es la clase que deriva a otra
  clase.
• La subclase es la clase derivada de una
  superclase.
• La liga expresa compatibilidad de relaciones
  entre las clases.
• Los objetos heredan las características de su
  clase y de todas las clases de nivel superior a
  la que pertenecen.
• Estos principios  y técnicas hacen que las BDOO
  estén adecuadas a aplicaciones que implican tipos
  de datos complejos.

35

• Tipos de datos complejos, tales como documentos
  compuestos o de diseño asistidos por computadora
  que combinan texto, gráficos y hojas de cálculo.
• La BD proporciona un modo natural de representar
  las jerarquías que aparecen en los datos
  complejos.
• La jerarquía de clases permite a la BD seguir la
  pista del tipo de cada objeto en el documento.
• Finalmente, el mecanismo de mensajes ofrece
  soporte natural para una interfaz de usuario
  gráfica.

36

• BASES DE DATOS ORIENTADAS A OBJETOS (BDOO)
• El campo de las BDOO se ha introducido como una
  nueva área de investigación.
• Los campos de Lenguajes de Programación,
  Inteligencia Artificial e Ingeniería de Software
  han contribuido con el uso de la tecnología OO en
  el área de las BD.
• El desafío del área de BD es integrarlos en un
  diseño de sistema simple que mantenga el equipo
  deseado para cada campo.

37

• El resultado es conservar las características
  centrales de las BD  modernas, incluyendo
• Persistencia
• Control de Concurrencia
• Recuperación
• Consistencia
• Lenguaje de Consulta.

38

• BASES DE DATOS ORIENTADAS A OBJETOS (BDOO)
• Desde el punto de vista del desarrollador las
  ventajas están dadas en ganancias de
  productividad, dado su modelado más simple que
  facilita el desarrollo de aplicaciones.
• El modelado de aplicaciones es mucho más sencillo
  gracias al concepto de objetos complejos y el
  modelo obtenido es fácilmente comprensible para
  el usuario.
• Este modelo puede ser validado directamente por
  el cliente de la aplicación.

39

• BASES DE DATOS ORIENTADAS A OBJETOS (BDOO)
• El enfoque OO favorece la reutilización.
• Porque gracias al encapsulamiento y a la
  herencia, es fácil especializar un componente
  existente para responder a las necesidades
  particulares de la aplicación.
• Desde el punto de vista del usuario final, los
  SMBDOO, proporcionan mayor aporte en la calidad
  en términos de ergonomía, fiabilidad, evolución y
  desempeño.

40

• ESTRUCTURA DE OBJETOS
• El Modelo Orientado a Objetos (MOO) se basa en
  encapsular código y datos en una única unidad,
  llamada objeto.
• La 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.

41

• La capacidad de modificar la definición de un
  objeto sin afectar al resto del sistema, está
  considerada como una de las mayores ventajas del
  modelo de POO.
• JERARQUÍA DE CLASES.
• En una BD existen objetos que responden a los
  mismos mensajes, utilizan los mismos métodos y
  tienen variables del mismo nombre y tipo.
• Sería inútil definir cada uno de estos objetos
  por separado por lo tanto se agrupan los objetos
  similares para que formen una clase, a cada uno
  de estos objetos se le llama instancia de su
  clase.

42

• Todos los objetos de su clase comparten una
  definición común, aunque difieran en los valores
  asignados a las variables.
• Así que básicamente las BDOO tienen la finalidad
  de agrupar aquellos elementos que sean semejantes
  en las entidades para formar una clase, dejando
  por separado aquellas que no lo son.

43

• Por ejemplo Tomemos como referencia la entidad
  Alumno y la entidad Maestro.
• Donde los atributos considerados para cada uno,
  son en Alumno
• Nombre
• Dirección
• Teléfono
• Especialidad
• Semestre
• Grupo

44

• Maestro
• Nombre
• Dirección
• Teléfono
• Número económico
• Plaza
• RFC
• Los atributos de Nombre, Dirección y Teléfono se
  repiten en la entidad Alumno y Maestro, así que
  podemos agrupar estos elementos para formar la
  clase Persona, con dichos campos.

45

• Quedando por separado en Alumno
• Especialidad
• Semestre
• Grupo.
• Y en Maestro
• Número Económico
• Plaza
• RFC.

46
CLASE PERSONA
Nombre Dirección Teléfono
HERENCIA SUPERCLASE SUBCLASES
Número Económico Plaza RFC
Especialidad Semestre Grupo
CLASE ALUMNO
CLASE MAESTRO
47
PROBLEMAS A RESOLVER POR LOS SMBDOO
48

• Un programa de datos intensivo es aquel que
  produce y/o requiere de un gran número de datos
  (muchos de ellos no podrían introducirse al mismo
  tiempo dentro de la memoria virtual de un
  programa).
• Programar a lo grande se refiere a que los
  procesos de Ingeniería de Software requieran de
  múltiples programadores para producir programas
  grandes y complejos.
• La complejidad de estos sistemas no sólo se
  muestra en los programas que manipulan datos sino
  en los datos mismos.

49

• Por ejemplo Los datos que son usados en la
  aplicación de diseños eléctricos contienen muchas
  interconexiones complejas, con muchas
  limitaciones complejas en la forma de que éstas
  son usadas.
• Un circuito usa muchos componentes de diferentes
  tipos, y éstos tienen que hacer referencia a
  otros componentes a los que están conectados.
• Un problema en el desarrollo de aplicaciones en
  las BD es la incompatibilidad entre el Lenguaje
  de Manipulación de Datos (DML) de las BD, y el
  Lenguaje de Programación de Propósito General, en
  el cual el resto de las aplicaciones son escritas.

50

• En los sistema OO, se utiliza un Lenguaje
  Integrado para las operaciones de BD y para las
  que no lo son.
• El lenguaje anfitrión y el lenguaje de BD están
  fuertemente acoplados en estos sistemas, de hecho
  son los mismos. A diferencia del SQL.
• Una ventaja importante es que permite una mejor
  verificación de tipo.
• Se dice que en este lenguaje unificado no hay
  desacoplo de impedancia entre un lenguaje de
  programación procedural y el lenguaje de
  manipulación de datos.

51

• Donde desacoplo de impedancia se refiere a la
  diferencia entre el nivel de registro (manejado
  por un lenguaje de programación) y el nivel de
  conjunto (como la hace SQL).
• De hecho los lenguajes de objetos están en el
  nivel de registros (o procedimientos).
• Son lenguajes 3GL, no manejan conjuntos sólo
  procedimientos.
• El rendimiento queda en gran parte en manos de
  los usuarios (programadores o el ASBD).

52

• Los Lenguajes de Programación de BD resuelven el
  problema de incompatibilidad, documentando los
  tipos de datos de un Lenguaje de Propósito
  General persistente, o agregando tipos de
  sistemas de un lenguaje.
• Sin embargo, cuando se accesan a los datos de
  otros lenguajes, el problema de la
  incompatibilidad realmente existe.
• Las BDOO tratan de mejorar el problema de la
  incompatibilidad, extendiendo el DML.

53

• Sin embargo, pocas BDOO pueden expresar las
  aplicaciones complejas por sí mismas.
• El DML carece de una manipulación de datos de la
  Aplicación.
• El lenguaje de propósito general tiene
  persistencia de datos sólo en la forma de los
  archivos.
• Careciendo de un modo sofisticado de memoria
  persistente que incluye tipos de alto nivel,
  limitaciones y consultas.

54

• Para preservar la exactitud de las BD en la
  ejecución de procesos concurrentes, los sistemas
  de BD definen el concepto de Transacciones
  Atómicas.
• Las transacciones son unidades  de trabajo que se
  permiten procesar de manera concurrente,
  garantizando resultados que son equivalentes a
  los resultados producidos por algunas ejecuciones
  seriales.
• Definimos esta propiedad de equivalencia como
  Seriabilidad.

55

• Existen muchas implementaciones que garantizan
  las ejecuciones seriabilizables, en las
  transacciones de Read-Write.
• Si existen transacciones de Read y Write al mismo
  tiempo sobre el dato x, entonces surgirá un
  conflicto al escribir el dato x, por lo que el
  manejador de datos tomará la decisión
  correspondiente.
• Las BDOO presentan una  oportunidad para dar más
  concurrencia que otros enfoques tradicionales.

56

• En el enfoque OO, los sistemas de BD conocen
  acerca de las operaciones que van a ser
  ejecutadas.
• Para aplicaciones cooperativas, como en el diseño
  de ambientes, la noción de seriabilidad es muy
  exacto.
• El diseño cooperativo está basado en la noción de
  unidades de trabajo, que puedan interactuar como
  resultados inesperados.
• Esta observación ha creado una nueva área de
  interés de investigación, basada en la Tecnología
  OO en el control de concurrencia.

57

• Por ejemplo, es muy común ver las BDOO
  implementadas como un interprete de un manejador
  de almacenamiento.
• Este es el responsable de los movimientos de los
  objetos desde el disco hacia la memoria
  principal, para el manejador del Buffer y algunas
  transacciones de bajo nivel y tareas de
  recuperación.
• El interprete es el responsable de proveer las
  facilidades requeridas en las vistas de objetos,
  tipos y métodos.
• Esta arquitectura aparece en los sistemas de BD
  Relacionales.

58

• Existen varias BD comerciales OO actualmente bajo
  desarrollo, pero sólo un grupo de ellas están
  disponibles hoy en día como productos
  comerciales.
• Sin embargo, las BDOO ya han provocado una
  tormenta de controversias en la comunidad de las
  BD.
• Los lenguajes de consultas para BDOO son aún
  difíciles de implementar.
• Existe una tensión entre encapsulación y la vista
  estructural de datos característicos de lenguajes
  de consulta tales como SQL y QUEL.

59

• Una BDOO debe tener por lo mismo los siguientes
  requerimientos
• Debe proporcionar  funcionalidad en la BD.
• Incluir todas las características esenciales.
• Debe soportar la Identificación de Objetos (OID).
• Debe proporcionar Encapsulamiento. Esta
  encapsulación puede ser la base por la cual todos
  los objetos abstractos son definidos.
• Debe soportar objetos con estado complejo.  El
  estado de un objeto puede referirse a otros
  objetos.

60

• HERENCIA.
• Las clases en un Sistema OO se representan en
  forma jerárquica.
• Así que las propiedades o características de un
  elemento, las contendrán (o heredarán) los
  elementos que de ésta se deriven.
• Decimos por lo tanto que las entidades derivadas
  son subclases de la clase padre o Superclase.
• Se pueden crear muchas agrupaciones (clases) para
  simplificar un modelo.

61

• CONSULTAS ORIENTADAS A OBJETOS.
• Los lenguajes de POO, requieren que toda la
  interacción con objetos se realice mediante el
  envío de mensajes.
• El término mensaje en un entorno OO no implica el
  uso de mensajes físicos en la red.
• Por el contrario hace referencia al intercambio
  de solicitudes entre los objetos.
• Se utiliza a veces la expresión invocar a un
  método para denotar el hecho de enviar un mensaje
  a un objeto y la ejecución del método
  correspondiente.

62

• CONSULTAS ORIENTADAS A OBJETOS.
• Dado que la única interfaz externa presentada por
  cada objeto es el conjunto de mensajes a los que
  responde, resulta posible modificar las
  definiciones de los métodos y de las variables
  sin afectar al resto del sistema.
• La posibilidad de modificar la definición de un
  objeto sin afectar al resto del sistema se
  considera una de las mayores ventajas del
  paradigma de la POO.
• Consideremos un ejemplo con una entidad Alumno, y
  deseamos que la consulta realice la búsqueda de
  todos los alumnos que cursan la materia de Base
  de Datos II.
• Para realizar esta consulta, se tendría que
  enviar un mensaje a cada instancia Alumno dentro
  del sistema.

63

• Generalmente en una BD hay muchos objetos
  similares.
• Por similar se entiende que responden a los
  mismos mensajes, utilizan los mismos métodos y
  tienen variables del mismo nombre y del mismo
  tipo.
• Así un lenguaje de consultas para un sistema de
  BDOO, debe incluir tanto el modelo de pasar el
  mensaje de objeto a objeto, como el modelo de
  pasar el mensaje de conjunto en conjunto.

64
Ejemplo del lenguaje para Manipulación de objetos
C de ODMG int crear_titular_cuenta(String
nombre, String direccion d_Database
bd_banco_obj d_Database bd_banco
bd_banco_obj bd_banco-gtopen(BD-Banco)
d_Transacction Trans Trans.begin()
d_RefltCuentagt cuenta new(bd_banco,
Cuenta)Cuenta d_RefltClientegt clien
new(bd_banco, Cliente)Cliente
clien-gtnombre nombre clien-gtdirección
dirección clien-gtcuentas.insert_element(cuent
a) cuenta-gttitulares.insert_element(clien)
.. Trans.commit() Bd_banco-gtclose()

65

• COMPLEJIDAD DE MODIFICACIÓN.
• En las BDOO pueden existir los siguientes
  cambios
• Adición de una nueva clase Para realizar este
  proceso, la nueva clase debe colocarse en la
  jerarquía de clase o subclase, cuidando las
  variables o métodos de herencia correspondientes.
• Eliminación de una clase Se requiere la
  realización de varias operaciones, se debe de
  cuidar los elementos que se han heredado de esa
  clase a otras y reestructurar la jerarquía.
• En sí la estructuración de modelos OO simplifica
  la estructura, evitando elementos o variables
  repetidas en diversas entidades.

66

• COMPLEJIDAD DE MODIFICACIÓN.
• Sin embargo el precio de esto es dedicarle un
  minucioso cuidado a las relaciones entre las
  clases cuando el modelo es complejo.
• La dificultad del manejo de objetos radica en la
  complejidad de las modificaciones y eliminaciones
  de clases.
• Ya que de tener variables que heredan de otros
  objetos, se tiene que realizar una
  reestructuración que involucra una serie de pasos
  complejos.

67

• PROGRAMACIÓN ORIENTADA A OBJETOS.
• POO (Object-Oriented Programming).
• Muchas organizaciones que actualmente usan
  tecnología orientada a objetos también desean los
  beneficios de los SMBDOO.
• En otras palabras, se desea la migración de BD y
  aplicaciones de BD Relacionales a OO.

68

• PROGRAMACIÓN ORIENTADA 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 BD.
• El objetivo de la migración de la BD es tener un
  esquema equivalente y la BD disponibles bajo los
  nuevos SMBDOO.
• Esto desde luego puede ser logrado por medio de
  la transformación manual del código de los
  programas lo cual resulta demasiado complicado.

69

• PROGRAMACIÓN ORIENTADA A OBJETOS.
• Para esto existen tres enfoque que hacen uso de
  la tecnología de objetos para BD Relacionales
  (BDR).
• Construir una interface OO sobre el Sistema de
  BDR.
• La migración a un SBD Objetos/Relacional.
• Conversión del esquema de BDR a uno OO.

70

• PROGRAMACIÓN ORIENTADA A OBJETOS.
• Construir una interface OO sobre el Sistema de
  BDR.
• El primer enfoque retiene la BDR y crea una
  interface OO encima de ésta.
• Este enfoque es el más fácil.
• No existe interrupción del sistema para la
  migración de datos y no existe pérdida semántica
  de la información.
• Por otro lado el rendimiento disminuye debido que
  no existe un buen acoplamiento entre los dos
  paradigmas en el tiempo de ejecución.

71

• PROGRAMACIÓN ORIENTADA A OBJETOS.
• La migración a un SBD Objetos/Relacional.
• En el segundo enfoque, los datos deben ser
  migrados de acuerdo con el SMBD (por ejemplo
  Oracle 7 a 8).
• Y las características Orientadas a Objetos sólo
  pueden ser explotadas con la modificación o
  extensión del esquema.

72

• PROGRAMACIÓN ORIENTADA A OBJETOS.
• Conversión del esquema de BDR a uno OO.
• El tercer enfoque es la migración de la base de
  datos en donde un nuevo esquema bajo el SMBDOO es
  creado.
• Y los datos son migrados de la Base de Datos
  Relacional a la Orientada a Objetos.
• Cada uno de los tres enfoques anteriores tiene
  sus ventajas y desventajas.
• Especialmente el tercero, una metodología y
  herramientas de soporte son críticas para una
  migración exitosa.

73
DISEÑO DE DISTRIBUCIÓN DE OBJETOS
74

• DISTRIBUCIÓN DE OBJETOS.
• Dos aspectos importantes del diseño de
  distribución son La Fragmentación y la
  Colocación.
• El diseño de la distribución en el mundo de
  objetos trae nuevas complejidades, debido al
  encapsulamiento de métodos junto con los estados
  de los objetos.
• Un problema es que los métodos están
  implementados y compartidos por todas las
  instancias de objetos de ese tipo.

75

• DISTRIBUCIÓN DE OBJETOS.
• Se tiene que decidir si la fragmentación se
  realiza solamente sobre los atributos, duplicando
  los métodos en cada fragmento.
• O si los métodos se puedan fragmentar.
• Hay que recordar que algunos dominios de algunos
  atributos pueden ser clases.
• Por lo que la fragmentación de clases con
  respecto a tales atributos puede afectar en otras
  clases.

76

• DISTRIBUCIÓN DE OBJETOS.
• Y si la fragmentación se lleva a cabo con
  respecto a los métodos, es necesario distinguir
  entre métodos simples y métodos compuestos.
• Métodos Simples son aquellos que no invocan a
  otros métodos.
• Mientras que los Complejos invocan métodos de
  otras clases.
• PARTICIONAMIENTO DE CLASE HORIZONTAL
• Comencemos con una fragmentación de una clase con
  métodos y atributos simples.

77

• DISTRIBUCIÓN DE OBJETOS.
• PARTICIONAMIENTO DE CLASE HORIZONTAL
• Para este caso, el particionamiento horizontal
  primario se puede lograr de acuerdo a un
  predicado definido en un atributo de la clase.
• Donde cada clase (o subclase) derivada satisface
  el predicado de particionamiento particular de la
  clase original.
• Si estos predicados son mutuamente exclusivos,
  entonces las instancias de la clases son
  disjuntos.

78

• DISTRIBUCIÓN DE OBJETOS.
• PARTICIONAMIENTO DE CLASE VERTICAL
• La fragmentación vertical es considerablemente
  más compleja.
• Por ejemplo al fragmentar una clase verticalmente
  produce un número de clases (o subclases), cada
  una conteniendo algunos atributos y métodos.
• Por lo que cada uno de los fragmentos tiene menos
  definiciones que la clase original.

79

• DISTRIBUCIÓN DE OBJETOS.
• PARTICIONAMIENTO DE CLASE VERTICAL
• Si los métodos son simples, entonces los métodos
  pueden particionarse fácilmente.
• Y cuando no son simples, la ubicación de estos
  métodos llega a ser un verdadero problema.

80

• COLOCACIÓN DE OBJETOS.
• El problema de la colocación de datos, para las
  BDOO, involucra la ubicación de métodos y clases.
• Y como las aplicaciones de las BDOO invocan
  métodos, la ubicación de éstos afecta el
  rendimiento de las aplicaciones.
• La colocación de métodos los cuales necesitan
  accesar múltiples clases en diferentes sitios, es
  un problema el cual aún no ha sido abordado.
• Existen cuatro alternativas para la colocación de
  objetos.

81

• COLOCACIÓN DE OBJETOS.
• Comportamiento Local Objeto Local. Tanto el
  comportamiento (método) del objeto, como los
  argumentos se encuentran de manera local.
• Comportamiento Local Objeto Remoto. En este
  caso el comportamiento y el objeto al cual se le
  aplica, están localizados en diferentes sitios.
• Una alternativa consiste en mover el objeto
  remoto al sitio donde el comportamiento se
  localiza.
• Otra es enviar la implementación del
  comportamiento al sitio donde reside el objeto.

82

• COLOCACIÓN DE OBJETOS.
• Comportamiento Remoto Objeto Local. Es el caso
  inverso del punto 2.
• Función Remota Argumento Remoto. Caso inverso
  del punto 1.
• REPLICACIÓN
• La replicación agrega una nueva dimensión al
  problema del diseño.
• Objetos, Clases de Objetos, o Colecciones de
  Objetos ( o todo) pueden ser replicados.

83
ARQUITECTURA DE UNA BDOO
84

• ARQUITECTURA.
• Una manera de desarrollar un sistema distribuido
  es la de Cliente/Servidor.
• La mayoría de los actuales SMBDOO son sistemas
  cliente/servidor.
• Donde el cliente solicita objetos del servidor.
• Y el servidor los obtiene de la BD y los regresa
  al cliente solicitante.
• Estos sistemas son llamados Servidor de Objetos.

85

• ARQUITECTURA DE UNA BDOO.
• En la siguiente se muestran algunos de los
  principales productos de BDOO y sus vendedores.

Seis Productos de BDOO y sus Proveedores.
86

• Arquitectura de una BDOO
• Los primeros se diseñaron como una extensión de
  los lenguajes de programación como Smalltalk ó
  C.
• Por ejemplo el sistema GemStone y su lenguaje
  OPAL, están basados en Smalltalk, uno de los
  lenguajes de objetos más puros.
• Aunque recientemente los lenguajes de objetos más
  importantes son Java y C en ese orden, que han
  desplazado a otros.
• A pesar del hecho de que estos dos son menos
  puros que smalltalk.

87

• Arquitectura de una BDOO
• El DML (Lenguaje para La Manipulación de Datos) y
  el DDL (Lenguaje para la Definición de los Datos)
  constituyen un lenguaje OO común.
• El diseño de las BDOO actuales deben aprovechar
  al máximo las características del CASE, e
  incorporar métodos creados con cualquier técnica
  poderosa.

88

• Desarrollo con Bases de Datos OO
• Las BDOO se desarrollan al describir, en primer
  lugar, los tipos de objetos importantes del
  dominio.
• Estos tipos de objetos determinan las clases que
  conformarán la definición de la BDOO.
• Por ejemplo Una BD diseñada para almacenar la
  geometría de ciertas partes mecánicas incluiría
  clases como CILINDRO, ESFERA y CUBO.

89

• Desarrollo con Bases de Datos OO
• El comportamiento de CILINDRO podría incluir
  información relativa a sus dimensiones, volumen,
  área, etc.
• Clase de CILINDRO ALTURA FLOTANTE () RADIO
  FLOTANTE () VOLUMEN FLOTANTE () AREA
  FLOTANTE ()
• Se puede llegar a definiciones similares para el
  cubo y la esfera.

90

• Desarrollo con Bases de Datos OO
• En la definición anterior, ALTURA, RADIO y ÁREA
  representan los mensajes que se pueden enviar a
  un objeto CILINDRO.
• La Implantación se lleva a cabo en el mismo
  lenguaje, escribiendo funciones correspondientes
  a las solicitudes OO
• CILINDROALTURA ( ) RETORNA CILINDRO_ALTURA
• CILINDROVOLUMEN ( ) RETORNA PI RADIO ( )
  ALTURA ( )

91

• Desarrollo con Bases de Datos OO
• En este caso, la Altura se almacena como un
  elemento de los datos, mientras que Volumen se
  calcula mediante la fórmula apropiada.
• Observe que la implantación interna de Volumen
  utiliza solicitudes para obtener Altura y Radio.
• Sin embargo, el aspecto más importante es la
  sencillez y uniformidad que experimentan los
  usuarios de CILINDRO.

92

• Desarrollo con Bases de Datos OO
• Sólo necesitan conocer la forma de enviar una
  solicitud y las solicitudes disponibles.
• TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.
• Las BDOO se pueden construir mediante alguno de
  los tres enfoques siguientes
• El Primero.- se puede utilizar el código actual
  altamente complejo de los sistemas de
  administración de las BD, de modo que una BDOO se
  implante más rápido sin tener que iniciar de cero.

93

• TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.
• El Primero
• Las Técnicas OO se pueden utilizar como medios
  para el diseño sencillo de sistemas complejos.
• Los sistemas se construyen a partir de
  componentes ya probados con un formato definido
  para las solicitudes de las operaciones del
  componente.

94

• TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.
• El Segundo Considera a la BDOO como una
  extensión de la tecnología de las BD por
  Relación.
• De este modo, las herramientas, técnicas, y vasta
  experiencia de la tecnología por relación se
  utilizan para construir un nuevo SMBD.
• Se pueden añadir apuntadores a las tablas de
  relación para ligarlas con objetos binarios de
  gran tamaño.
• La BD también debe proporcionar a las
  aplicaciones clientes, un acceso aleatorio y por
  partes a grandes objetos, con el fin de que sólo
  sea necesario recuperar a través de la red la
  parte solicitada de los datos.

95

• TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.
• El Tercero reflexiona sobre la arquitectura de
  los SBD y produce una nueva arquitectura
  optimizada, que cumple las necesidades de la
  tecnología OO.
• Las compañías como Versant, Objectivity, Itasca,
  etc., utilizan este enfoque y afirman que la
  tecnología de relación es un subconjunto de una
  capacidad más general.
• Además mencionan que las BDOO son aproximadamente
  dos veces más rápidas que las bases de datos por
  relación, para almacenar y recuperar la
  información compleja.

96

• TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.
• El Tercero
• Por lo tanto, son esenciales en aplicaciones como
  CAD y permitirían que un depósito CASE fuera una
  facilidad de tiempo real en vez de una facilidad
  por lotes.
• La Arquitectura de Versant está orientada al
  soporte Cliente/Servidor con acercamiento a la
  computación distribuida.
• Cualquier petición del Cliente, el Servidor la
  procesa. Los servidores pueden cooperar en una BD
  distribuida de Versant.
• Las BD pueden estar levantadas como un sistema
  m-Cliente/n-Servidor.

97

• IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA
  INGENIERÍA DEL SOFTWARE.
• En las BDOO, la organización "Grupo de
  Administración de Datos Objeto (ODMG)" representa
  el 100 de las BDOO industriales.
• Y ha establecido un estándar de BD equivalente a
  SQL
• ODL.- Lenguaje de Definición de Datos Objetos, y
• OQL.- Lenguaje de Consulta a Objetos.
• Respecto a las relacionales, todas (Oracle,
  Informix, etc.) están añadiendo en mayor o menor
  grado algunos aspectos de la OO.

98

• IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA
  INGENIERÍA DEL SOFTWARE.
• ANSI (Instituto Nacional Americano de Estándar),
  por su parte, está definiendo un SQL-3 que
  incorpora muchos aspectos de la OO.
• El futuro del SQL-3 es sin embargo incierto, ya
  que ODMG ha ofrecido a ANSI su estándar para que
  sirva de base para un nuevo SQL.
• Con lo que sólo habría un único estándar de BD.

99

• IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA
  INGENIERÍA DEL SOFTWARE.
• El grupo ODMG (Grupo Manejador de Datos Objeto)
  nació de un grupo más grande, llamado "Grupo
  Manejador de Objetos (OMG).
• Este grupo está definiendo un estándar universal
  por objetos.
• Este estándar permitirá que un objeto sea
  programado en cualquier lenguaje y sistema
  operativo.
• Facilitando enormemente el desarrollo de sistemas
  abiertos cliente-servidor.

100

• VENTAJAS EN BDOO.
• Está su flexibilidad, y soporte para el manejo de
  tipos de datos complejos.
• Por ejemplo, en una BD convencional
• Si una empresa adquiere varios clientes por
  referencia de clientes- servicio.
• Pero la BD existente, que mantiene la información
  de clientes y sus compras, no tiene un campo para
  registrar quién proporcionó la referencia.
• O de qué manera fue dicho contacto.
• O si debe compensarse con una comisión, sería
  necesario reestructurar la BD para añadir este
  tipo de modificaciones o de datos.

101

• VENTAJAS EN BDOO.
• Por el contrario, en una BDOO, el usuario puede
  añadir una "subclase" de la clase de clientes
  para manejar las modificaciones que representan
  los clientes por referencia.
• La subclase heredará todos los atributos,
  características de la definición original, además
  se especializará en especificar los nuevos campos
  que se requieren así como los métodos para
  manipular solamente esos campos.
• Naturalmente se generan los espacios para
  almacenar la información adicional de los nuevos
  campos.

102

• VENTAJAS EN BDOO.
• Esto presenta la ventaja adicional que una BDOO
  puede ajustarse a usar siempre el espacio de los
  campos que son necesarios, eliminando espacio
  desperdiciado en registros con campos que nunca
  usan.
• La segunda ventaja de una BDOO, es que manipula
  datos complejos en forma rápida y ágilmente.
• La estructura de la base de datos está dada por
  referencias (o apuntadores lógicos) entre
  objetos, los famosos IDOs.

103

• POSIBLES DESVENTAJAS.
• Al considerar la adopción de la tecnología
  orientada a objetos, la inmadurez del mercado de
  BDOO constituye una posible fuente de problemas.
• Por lo que debe analizarse con detalle la
  presencia en el mercado del proveedor para
  adoptar su producto en una línea de producción
  sustantiva.
• El segundo problema es la falta de estándares en
  la industria OO.

104

• POSIBLES DESVENTAJAS.
• Sin embargo, el "Grupo Manejador de Objetos"
  (OMG), es una organización Internacional de
  proveedores de sistemas de información y usuarios
  dedicada a promover estándares para el desarrollo
  de aplicaciones y sistemas OO en ambientes de
  cómputo en red.
• La implantación de una nueva tecnología requiere
  que los usuarios iniciales acepten cierto riesgo.
• Aquellos que esperan resultados a corto plazo y
  con un costo reducido quedarán desilusionados.

105

• POSIBLES DESVENTAJAS.
• Sin embargo, para aquellos usuarios que planean
• A un futuro intermedio con una visión tecnológica
  avanzada.
• El uso de tecnología avanzada o de punta.
• Y el uso de Tecnología OO.
• Paulatinamente compensarán todos los riesgos.

106

• RENDIMIENTO.
• Las BDOO permiten que los objetos hagan
  referencia directamente a otros mediante
  apuntadores suaves.
• Esto hace que las BDOO pasen más rápido del
  objeto A al objeto B que las BDR.
• Las cuales deben utilizar comandos JOIN para
  lograr ésto.
• Incluso el JOIN optimizado es más lento que un
  recorrido de los objetos.

107

• RENDIMIENTO.
• Así, incluso sin alguna afinación especial, una
  BDOO es en general más rápida en esta mecánica de
  caza-apuntadores.
• Las BDOO hacen que el agrupamiento sea más
  eficiente.
• La mayoría de los SBD permiten que el operador
  coloque cerca las estructuras relacionadas entre
  sí, en el espacio de almacenamiento en disco.
• Esto reduce en forma radical el tiempo de
  recuperación de los datos relacionados, puesto
  que todos los datos se leen con una lectura de
  disco, en vez de varias.

108

• RENDIMIENTO.
• Sin embargo, en una BDR, los objetos de la
  implantación se traducen en representaciones
  tabulares que generalmente se dispersan en varias
  tablas.
• Así, en una BDR, estos renglones relacionados
  deben quedar agrupados, de modo que todo el
  objeto se pueda recuperar mediante una única
  lectura del disco.
• Esto es automático en una BDOO.
• Además, el agrupamiento de los datos
  relacionados, como todas las subpartes de un
  ensamble, puede afectar radicalmente el
  rendimiento general de una aplicación.

109

• RENDIMIENTO.
• Esto es relativamente directo en una BDOO, puesto
  que representa el primer nivel de agrupamiento.
• Por el contrario, el agrupamiento físico es
  imposible en una BDR, puesto que esto requiere un
  segundo nivel de agrupamiento
• Un nivel para agrupar las hileras que representan
  a los objetos individuales
• Y un segundo para los grupos de hileras que
  representan a los objetos relacionados.

110

• RENDIMIENTO.
• Un SMBDOO debe satisfacer dos criterios
• Ser un Sistema OO.
• Y ser un Sistema de Administración de BD.
• El primer criterio se traduce en ocho
  características generales Abstracción,
  encapsulación, modularidad, jerarquía, control de
  tipos, concurrencia, persistencia y genericidad.
• El segundo criterio se traduce en cinco
  características principales Persistencia,
  concurrencia, recuperación ante fallos del
  sistema, gestión del almacenamiento secundario y
  facilidad de consultas.

111
Características de SGBDOO .
Primer Criterio. Con 8 características.
Segundo Criterio. Con 5 características.
112

• RENDIMIENTO.
• Como se puede observar la Persistencia, al igual
  que la Concurrencia, son características del
  SMBDOO heredadas tanto del SMBD como del Modelo
  de Objetos.
• La Persistencia en el caso del SMBD hace
  referencia a la conservación de los datos después
  de la finalización del proceso que los creó.
• En el caso del Modelo de Objetos, se refiere no
  sólo a la conservación del estado de un objeto,
  si no también a la conservación de la clase, que
  debe trascender a cualquier programa individual.

113

• RENDIMIENTO.
• De forma que todos los programas interpreten de
  la misma manera el estado almacenado.
• La Concurrencia heredada del SMBD se refiere a la
  capacidad del sistema para gestionar a múltiples
  usuarios interactuando concurrentemente sobre el
  sistema.
• Mientras que la concurrencia heredada del Modelo
  de Objetos, hace referencia a la capacidad de
  distinguir a un objeto activo de otro que no lo
  está.

114

• RENDIMIENTO.
• Persistencia.- Es la capacidad que tiene el
  programador para que sus datos se conserven al
  finalizar la ejecución de un proceso, de forma
  que se puedan reutilizar en otros procesos.
• Concurrencia.- Se relaciona con la existencia de
  muchos usuarios interactuando concurrentemente en
  el sistema.
• Éste debe controlar la interacción entre las
  transacciones concurrentes, para evitar que se
  destruya la consistencia de la BD.

115

• RENDIMIENTO.
• Recuperación.- Proporcionar como mínimo el mismo
  nivel de recuperación que los SBD actuales.
• De forma que, tanto en caso de fallo de hardware
  como de software, el sistema pueda retroceder
  hasta un estado coherente de los datos.
• Gestión del almacenamiento secundario.- Es
  soportada por un conjunto de mecanismos que no
  son visibles al usuario.
• Tales como gestión de índices, agrupación de
  datos, selección del camino de acceso,
  optimización de consultas, etc.

116

• RENDIMIENTO.
• Gestión del almacenamiento secundario
• Estos mecanismos evitan que los programadores
  tengan que escribir programas para mantener
  índices, asignar el almacenamiento en disco, o
  trasladar los datos entre el disco y la memoria
  principal.
• Creándose de esta forma una independencia entre
  los Niveles Lógicos y Físicos del sistema.
• Facilidad de Consultas.-
• Permitir al usuario hacer cuestiones sencillas a
  la BD. Este tipo de consultas tienen como misión
  proporcionar la información solicitada por el
  usuario de una forma correcta y rápida.

117

• INTEGRIDAD.
• Los sistemas de objetos no soportan generalmente
  restricciones de integridad declarativas.
• En vez de ello, requieren que tales restricciones
  se hagan cumplir por medio de código procedural
  (por métodos o programas de aplicación).
• Niveles
• Ningún soporte del sistema.
• Validación de referencias.
• Mantenimiento del sistema
• Semántica personalizada

118

• CONTROVERSIA.
• Las BD de Objetos surgieron por la necesidad que
  tenían los programadores de aplicaciones OO, de
  conservar sus objetos en una memoria persistente.
• Esa memoria persistente podría considerarse una
  BD, pero el punto importante es que en realidad
  fue especificada por la aplicación.
• No era una BD compartida, de propósito general
  que pretendiera ser adecuada para aplicaciones
  que no hubieran sido previstas al momento de
  definir la BD.

119

• CONTROVERSIA.
• Muchas características que son esenciales en los
  SBD, sencillamente no fueron requerimiento en el
  mundo de los objetos, al menos no originalmente.
• Se podría decir que un SBDOO no es un SMBD, por
• Un SMBDR ya viene listo para ser usado. Tan
  pronto como el sistema está instalado, los
  usuarios pueden comenzar a construir y manipular
  las BDs.
• Un SMBDOO, por el contrario, puede ser visto como
  un Kit de Construcción de SMBD. Cuando es
  instalado por primero vez, NO está disponible
  para su uso inmediato. Primero debe ser adaptado
  por técnicos capaces y experimentados.

120

• CONTROVERSIA.
• Estos técnicos son quienes también definen las
  clases y métodos necesarios para la BD. Y sólo
  cuando esta actividad de adaptación haya
  terminado, el sistema estará disponible para que
  los programadores de aplicaciones y los usuarios
  finales lo utilicen.
• Se puede observar, que el SMBD adaptado
  resultante será específico de una aplicación en
  particular.
• Podría por ejemplo, ser adaptado para
  aplicaciones CAD/CAM, pero esencialmente inútil
  para otro tipo de aplicaciones (médicas,
  documentos, etc).
• En otras palabras, todavía no sería un SMBD de
  propósito general, como lo son los SMBDRs.

121

• CONTROVERSIA.
• En esencia el modelo de objetos dice que podemos
  almacenar cualquier cosa que queramos, cualquier
  estructura de datos que podamos definir.
• El modelo relaciona dice lo mismo, pero además
  insiste en que cualquier cosa que almacenemos
  debe ser presentada ante el usuario en forma
  relacional pura.
• El modelo relacional no dice nada acerca de lo
  que puede ser almacenado físicamente.

122

• CONTROVERSIA.
• Por lo tanto no impone límites sobre cuáles
  estructuras de datos son permitidas en el nivel
  físico.
• El único requerimiento es que cualquier
  estructura que de hecho esté guardada
  físicamente, debe ser transformada a relaciones
  en el nivel lógico y por lo tanto, debe ser
  oculta ante el usuario.
• Los sistemas relacionales hacen una distinción
  clara entre lo lógico y lo físico (el modelo de
  datos contra la implementación).

123

• CONTROVERSIA.
• Mientras que los sistemas basados en objetos no
  lo hacen.

124
SMBD DE OBJETOS/RELACIONALES
125

• SMBD O/R.
• Recientemente varios fabricantes han lanzado
  productos SMBD de Objetos/Relacionales.
• También conocidos en el mercado, como Servidores
  Universales.
• Ejemplos de éstos
• Universal Database de DB2.
• Universal Data Option para Informix Dynamic
  Server.
• Oracle 8i Universal Server, Database Server o
  Enterprise Server.

126

• SMBD O/R.
• La idea general es que los productos deben
  soportar posibilidades de objetos y relacionales.
• Los productos en cuestión son intentos de un
  acercamiento entre las dos tecnologías.
• En los SBDR, se complica el manejar estructuras
  complejas, pero el soporte ya está ahí en forma
  de Dominios.
• No se necesita hacer nada, para lograr la
  funcionalidad de objetos en los sist