Procesamiento de Transacciones.

Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro

de los sistemas de base de datos, donde se usaba para auxiliar en el
mantenimiento de los datos de las aplicaciones y que dependían de la
consistencia de la información almacenada.

Las transacciones son un mecanismo que ayuda a simplificar la

construcción de sistemas confiables a través de procesos que proveen soporte
uniforme para invocar y sincronizar operaciones como:

 Operaciones de compartición de datos.

 Aseguramiento de la seriabilidad de las transacciones con otras.
 Atomicidad en su comportamiento.
 Recuperación de fallas provocadas en red y nodos.

El término transacción es usado dentro del dominio de la base de datos

como una unidad básica de cómputo consistente y confiable. Cabe destacar
que una transacción es una colección de acciones que hacen transformaciones
consistentes de los estados de un sistema, preservando la consistencia del
sistema. Una base de datos está en un estado consistente si obedece todas las
restricciones de integridad definidas sobre ella. Los cambios de estado ocurren
debido a actualizaciones, inserciones, y supresiones de información. Por
supuesto, se quiere asegurar que la base de datos nunca entra en un estado de
inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de
datos puede estar temporalmente en un estado inconsistente. El punto
importante aquí es asegurar que la base de datos regresa a un estado
consistente al fin de la ejecución de una transacción.

Si las operaciones no modifican ningún dato, sino que sólo recuperan

datos, la transacción es de sólo lectura. Las transacciones más conflictivas
pero más habituales, son las que modifican la base de datos. Las
transacciones no pueden violar ninguna restricción de integridad de la base de
datos, es decir, si la base de datos era consistente cuando empezó una
transacción, también debe serlo cuando termine con éxito.

Lo que se persigue con el manejo de transacciones es por un lado tener

una transparencia adecuada de las acciones concurrentes a una base de datos
y por otro lado tener una transparencia adecuada en el manejo de las fallas que
se pueden presentar en una base de datos.
 Como puede percibirse, el procesamiento de transacciones es una de las
tareas más importantes dentro de un sistema de base de datos, pero a la vez,
es una de las más difíciles de manejar. Se puede controlar la lógica de
transacciones con el uso de las sentencias COMMIT, SAVEPOINT y
ROLLBACK.

Los pasos para usar transacciones en MySQL son:

 Iniciar una transacción con el uso de la sentencia BEGIN.

 Actualizar, insertar o eliminar registros en la base de datos.

· Si se quieren los cambios a la base de datos, completar la transacción con el

uso de la sentencia COMMIT. Únicamente cuando se procesa un COMMIT los
cambios hechos por las consultas serán permanentes.

· Si sucede algún problema, podemos hacer uso de la

sentencia ROLLBACK para cancelar los cambios que han sido realizados por
las consultas que han sido ejecutadas hasta el momento.

OPERACIONES DE LECTURA Y ESCRITURA Y BUFERS DEL SISTEMA DE

MANEJADOR DE BASE DE DATOS

Los usuarios de la base de datos acceden a la base de datos de dos maneras:

 Con operaciones de lectura (Sentencia SELECT).

 Con operaciones de escritura (Sentencias INSERT, UPDATE y

DELETE).

Las operaciones de lectura y escritura a la base de datos aseguran una vista

consistente de los datos. De igual modo las operaciones de lectura no ven datos
que estén en un proceso de cambio. Las operaciones de escritura aseguran que
los cambios a la base de datos sean hechos en un camino consistente.
Estos cambios hechos por una operación de escritura no interrumpen ni entran
 en conflicto con los cambios hechos por otra operación de escritura, para que
resulte esto, se necesitan lecturas consistentes.

El propósito de las lecturas consistentes es asegurar que cada usuario

vea los datos que existieron hasta el último commit, antes de que una operación
DML inicie.

Para el control de la concurrencia y la recuperación, las operaciones de

acceso a una base de datos que una transacción puede incluir son:

1. Leer_ítem(X): Lee el ítem X y almacena su valor en una variable.

2.Escribir_ítem(X): Graba el valor de la variable de programa X en el ítem X.

La ejecución de una operación Leer_ítem(X) supone los siguientes pasos:

1.Encontrar la dirección del bloque de disco que contiene los datos del ítem X.

2.Copiar el bloque de disco a un buffer en memoria principal en caso de no existir.

3.Copiar el ítem X desde el buffer a la variable X.

La ejecución de una operación Escribir_ítem(X) incluye los siguientes pasos:

1.Encontrar la dirección del bloque de disco que contiene los datos del ítem X.

2. Copiar el bloque de disco a un buffer en memoria principal en caso de no existir.

3.Copiar el ítem X desde la variable X a su localización correcta en el buffer.

4.Almacenar el buffer modificado en el bloque de disco dicha la grabación física

puede no ser inmediata.

Los elementos de datos que lee una transacción se dice que constituyen
el conjunto de lectura(RS). Similarmente, los elementos de datos que una
transacción escribe se les denominan el conjunto de escritura (WS). Los
conjuntos de lectura y escritura no tienen que ser necesariamente disjuntos, la
unión de ambos conjuntos se le conoce como el conjunto base de la
transacción BS = RS U WS.

ESTADOS DE UNA TRANSACCIÓN

Una transacción es una unidad atómica de trabajo que es completada

enteramente o no realizada ninguna parte de ella. La colección de operaciones
físicas que forman una transacción constituye una unidad lógica de proceso.
Para propósitos de recuperación, el sistema necesita conocer cuando una
transacción comienza, aborta o termina. El Gestor de Recuperaciones debe
conocer la situación de las siguientes operaciones:
  BEGIN: Esta operación marca el comienzo de la ejecución de la
transacción.

 READ ó WRITE: Especifican operaciones de lectura y/o escritura de

ítems que son ejecutadas como parte de una transacción.

 END: Indica que las operaciones de lectura y escritura de la transacción

han concluido y marca el fin de la ejecución de la transacción. En este
punto es necesario chequear si los cambios realizados por la transacción
pueden ser aplicados permanentemente a la base de datos o si la
transacción ha sido abortada.

 COMMIT: Señala un final adecuado de la transacción y que cualquier

modificación de ítems ejecutada por la transacción puede ser transferida
definitivamente a la base de datos y no será desecha.

 ROLLBACK (ABORT): Indica que la transacción ha concluido de forma

inadecuada y por tanto, cualquier cambio o efecto que la transacción haya
podido tener sobre la base de datos debe ser desecho.

Además de las operaciones anteriores, en algunas técnicas de recuperación

específicas se utilizan otras operaciones, entre las cuales están:

 UNDO: Parecido a rollback, excepto que se aplica a una operación simple

en vez de a una transacción completa.
 REDO: Especifica que ciertas operaciones de la transacción deben ser
rehechas para asegurar que todas las operaciones han sido
sucesivamente aplicadas a la BD.

Una transacción pasa al estado ACTIVO inmediatamente después de

comenzar su ejecución, sin cambiar de estado con las diversas operaciones de
lectura y escritura de ítems. Cuando acaba (END) pasa al estado de
PARCIALMENTE CONFIRMADO. En este punto, algunas técnicas de control de
concurrencia requieren la realización de ciertos chequeos para asegurar que la
transacción no interfiere con otras transacciones que se ejecutan al mismo
tiempo. Además, algunos protocolos de recuperación necesitan comprobar que
un fallo del sistema no inhabilitará la grabación de los cambios de la transacción
de forma permanente. Cuando ambos controles se han realizado, se dice que la
transacción ha llegado al estado CONFIRMADO ó punto de confirmación (punto
commit) y ha concluido su ejecución.

En otros casos, una transacción puede llegar al estado FALLIDO si uno

de los chequeos falla o si es abortada durante su estado activo. La transacción
puede tener que ser desecha hacia atrás para deshacer los efectos de sus
operaciones de escritura sobre la base de datos, pasando entonces al estado
ABORTADO. Una transacción pasa al estado de TERMINADA cuando
desaparece del sistema. Las transacciones fallidas o abortadas pueden ser
reiniciadas posteriormente, bien automáticamente, o bien reejecutándolas como
una nueva transacción.
 Las operaciones BEGIN, READ ó WRITE, END, COMMIT, ROLLBACK
(ABORT), hacen que una transacción cambie de un estado a otro, como se
muestra a continuación:

PROPIEDADES DESEABLES EN LAS TRANSACCIONES

Atomicidad: Se refiere al hecho de que una transacción se trata como una

unidad de operación. Por lo tanto, o todas las acciones de la transacción se
realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una
transacción se interrumpe por una falla, sus resultados parciales deben ser
deshechos. La actividad referente a preservar la atomicidad de transacciones en
presencia de abortos debido a errores de entrada, sobrecarga del sistema o
interbloqueos se le llama recuperación de transacciones. La actividad de
asegurar la atomicidad en presencia de caídas del sistema se le
llama recuperación de caídas.

Consistencia: La consistencia de una transacción es simplemente su

correctitud. En otras palabras, una transacción es un programa correcto que lleva
la base de datos de un estado consistente a otro con la misma característica.
Debido a esto, las transacciones no violan las restricciones de integridad de una
base de datos.
Aislamiento: Una transacción en ejecución no puede revelar sus resultados a
otras transacciones concurrentes antes de su commit. Más aún, si varias
transacciones se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).

Durabilidad: Es la propiedad de las transacciones que asegura que una vez que
una transacción hace su commit, sus resultados son permanentes y no pueden
ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los
resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad
motiva el aspecto de recuperación de bases de datos, el cual trata sobre como
recuperar la base de datos a un estado consistente en donde todas las acciones
que han hecho un commit queden reflejadas.

En resumen, las transacciones proporcionan una ejecución atómica y

confiable en presencia de fallas, una ejecución correcta en presencia de accesos
de usuario múltiples y un manejo correcto de réplicas en el caso de que se
soporten.

SOPORTE DE TRANSACCIONES EN SQL.

Definición de transacciones SQL:

 Inicio de transacción: es implícito en SQL

 Final de transacción: en SQL

 COMMIT
 ROLLBACK

Características de una transacción SQL mediante SET TRANSACTION:

 Violaciones posibles según el nivel de aislamiento:

 Lectura sucia: una transacción T1 puede leer la actualización de T2 que

todavía no ha confirmado. Si T2 aborta, T1 habría leído un dato incorrecto.
 Lectura no reproducible: Si una transacción lee dos veces un mismo
dato y en medio una transacción lo modifica, verá valores diferentes para
el dato.
 Fantasmas: una transacción T1 puede leer un conjunto de filas (que
cumplan una condición). Si una transacción T2 inserta una fila que
también cumple la condición y T1 se repite verá un fantasma, una fila que
previamente no existía.

El servidor de bases de datos MySQL soporta distintos tipos de tablas,

tales como ISAM, MyISAM, InnoDB y BDB (Berkeley Database). De éstos,
InnoDB es el tipo de tabla más importante después del tipo predeterminado,
MyISAM.

Las tablas del tipo InnoDB están estructuradas de forma distinta que MyISAM,
ya que se almacenan en un sólo archivo en lugar de tres, y sus principales
características son que permite trabajar con transacciones, y definir reglas de
integridad referencial.
 El soporte de transacciones que provee MySQL no es algo nuevo en
MySQL 4, ya que desde la versión 3.23 se podía hacer uso de tablas InnoDB, la
única diferencia es que con la llegada de la versión 4.0 de MySQL, el soporte
para este tipo de tablas es habilitado por default.

Las transacciones aportan una fiabilidad superior a las bases de datos.

Si disponemos de una serie de consultas SQL que deben ejecutarse en conjunto,
con el uso de transacciones podemos tener la certeza de que nunca nos
quedaremos a medio camino de su ejecución. De hecho, podríamos decir que
las transacciones aportan una característica de "deshacer" a las aplicaciones de
bases de datos.

Para este fin, las tablas que soportan transacciones, como es el caso de
InnoDB, son mucho más seguras y fáciles de recuperar si se produce algún fallo
en el servidor, ya que las consultas se ejecutan o no en su totalidad. Por otra
parte, las transacciones pueden hacer que las consultas tarden más tiempo en
ejecutarse.

Para asegurarnos que tenemos soporte para el tipo de tablas InnoDB

podemos ejecutar la siguiente sentencia:

mysql> SHOW VARIABLES LIKE '%innodb%';

REINGENIERÍA DE BDD

La reingeniería de bdd se basa en un sistema ya existente por lo tanto es un

proceso de reconstrucción que permite mejorar los procesos de una base de
datos en producción esto quiere decir que la misma este siendo suministrada
de datos en este momento
¿Por qué hacer una reingeniería de bdd? Unareingeniería de base de datos se
lo realiza porque nacen nuevos requerimientos, procesos, objetos y
necesidades de acuerdo al crecimiento de una empresa Si se cambia la
estructura los cambios se reflejan en el software.
¿Cuando realizar una reingeniería de bdd? Sepodría tener en cuenta una
reingeniería cuando las consultas no satisfacen las necesidades o cuando el
tiempo de ejecución es demasiado alto; esto es el indicador de que mi bdd
necesita una reingeniería
El 10% de los análisis terminan en una reingeniería, esto quiere decir que de
cada 10 análisis 1 necesita una reingeniería; las demás realizan una ingeniería
nueva de bdd! El costo en función de tiempo y dinero es sumamente elevado

La reingeniería es una alternativa útil para la industria del software, ya que se

trata de Una actividad que permita incrementar la facilidad de mantenimiento,
reutilización y evolución de Sistemas software. En concreto, su aplicación a las
bases de datos es una necesidad que surge muy A menudo. La reingeniería de
base de datos es Una tarea de gran utilidad para las empresas turísticas, pues
su aplicación conlleva una mejora en Los productos y servicios que ofertan. El
proceso de reingeniería de bases de datos, consiste en la recuperación
Mediante distintos métodos de toda la información de las distintas vistas (física,
Conceptual y lógica) de la base de datos actual (LDB - Base de datos legada)
para en Posteriores etapas conseguir modificar y rediseñar el esquema
conceptual, Transformando la base de datos anterior (LDB) en otra base de
datos (NDB – Base de Datos nueva). Este proceso conlleva entre otros
aspectos de vital importancia, la Migración de datos de la LDB a la NDB.

2. Metodología para la obtención de modelos de datos en sistemas de

Información
Dentro de la metodología que proponemos, encontramos en primer lugar una
Etapa de ingeniería inversa, que podemos dividir en dos actividades que se
denominan Análisis de datos y Abstracción Conceptual (Hausi et al., 2000), y
posteriormente una Etapa de reingeniería. La primera fase de análisis de datos,
pretende recuperar un esquema de datos Lógico completo, que esté lo
suficientemente bien documentado y con su semántica Correctamente
identificada.
PROBLEMAS COMUNES PARA REALIZAR UNA REINGENIERÍA O
INGENIERÍA INVERSA
a) Estructuras implícitas: algunas estructuras no fueron declaradas en el
momento de Su diseño de forma explícita en la especificación DDL de la base
de datos, sino que Para completar la semántica de la base de datos se han
utilizado triggers, checks, Procedimientos, etc., por lo que para encontrar
características como la integridad no Basta con observar las definiciones de las
tablas (DDL). b) Diseño pobre o construcciones poco legibles: no todas las
bases de datos son Perfectas aunque funcionen correctamente, a veces
podemos encontrar Estructuras pobres o incluso erróneas, redundantes o
simplemente poco Legibles al tener nombres los campos poco clarificadores,
etc. c) Poca documentación: se realizó poca o no existe documentación sobre
el Diseño. d) Migrar los datos desde modelos de datos antiguos al modelo
relacional. e) Cambiar sistema de gestión de base de datos. f) Detección de
errores de integridad. g) Migración de modelos de datos relacionales a modelo
orientado a objetos.

3. INGENIERÍA INVERSA DE BASES DE DATOS

Como hemos comentado anteriormente el proceso de Ingeniería Inversa sobre

las Bases de datos, es comúnmente dividido en dos fases claramente
diferenciadas. a) Extracción de las estructuras de datos, obteniendo como
resultado el Esquema lógico. (Fase I) b) Conceptualización de las estructuras
de datos, obteniendo como resultado el Esquema conceptual. (Fase II)

Fase I.
En esta fase se va a realizar una extracción de las estructuras existentes
Actualmente en el sistema de información, dividiéndose en dos etapas de
extracción de Información. Etapa 1: Extracción automática. Inicialmente
debemos extraer mediante herramientas automáticas todas las Estructuras de
la base de datos cómo fueron diseñadas inicialmente por los Desarrolladores.
Se trata por tanto de una etapa típica de traducción inmediata del código Para
así extraer las estructuras de datos explícitas. Etapa 2: Extracción acumulativa.
Se trata de una etapa en la que la participación de los usuarios del modelo de
Datos con el que trabaja supondrá acumular más información de la obtenida en
la etapa Anterior. Como hemos comentado anteriormente es posible que
ciertas reglas no puedan Obtenerse directamente en la etapa 1, por lo que
aprovechando el conocimiento adquirido Por los usuarios en el trabajo diario se
podrá obtener información muy interesante. Así, aspectos importantes, sobre
los que los usuarios nos pueden ayudar son: a) Análisis de Nombres: el usuario
hará una descripción de aquellos campos en Los que es posible que tengamos
dudas acerca de su rol, tipos de datos, Relación, etc. b) Extracción de claves
externas: sabemos que en la etapa 1, de forma sencilla se Pueden obtener las
claves principales, pero la obtención de claves externas a Veces no es tarea
sencilla, y la información aportada por el usuario es vital.

Etapa 3: Unión del Esquema:

Se trata de una etapa ciertamente compleja, y de la que su éxito depende en

gran Medida el proceso de reingeniería, pues consiste en unir y reconvertir las
estructuras y Restricciones obtenidas en las dos fases anteriores. Así, con la
información obtenida en la Etapa 2 se pretende complementar la información
obtenida en la etapa 1, ya sea para Encontrar estructuras no explícitas o que
fueron perdidas cuando la base de datos fue Diseñada. Para ello se
localizarán: a) Campos multivaluados. b) Tipos registros e identificadores de
campos multivaluados. c) Campos opcionales. d) Claves. e) Redundancias. f)
Dominios. g) Significado de los campos.
Etapa 4: Análisis de Programas. En esta fase se realiza un estudio del código
fuente existente, para comprobar que las restricciones, forma de procesar los
datos, significado, etc. se corresponde con el estudio realizado en las fases
anteriores. Es posible que esta etapa modifique el resultado obtenido en las
etapas anteriores, pero sería deseable que no existieran cambios, pues de esa
forma podríamos asegurarnos que lo hecho en las etapas anteriores es
correcto y vamos por un buen camino. En esta misma etapa podríamos incluir
el análisis de formularios, consultas, informes, etc. que puedan existir, ya que
de esa forma podemos ver si los resultados obtenido con la LBD coinciden con
el modelo extraido.
Fase II.
En esta fase se extrae el esquema conceptual a partir del esquema lógico. En
mucha bibliografía, a esta fase se le denomina Interpretación de las estructuras
de datos, pues se va a realizar una optimización del esquema lógico. Etapa 1:
Conceptualización básica. Así, un ejemplo de conceptualización básica podría
ser si tenemos campos que tienen la misma estructura y que se refieren a
atributos de la entidad iguales, se transformarán en un atributo multivaluado.
Por ejemplo, en la entidad cliente tenemos el campo Teléfono1, Teléfono2, etc..
Otro ejemplo, podría ser cuando campos con distinta estructura pero que se
refieren a subcampos de un campo multivaluado. Por ejemplo, el V Congreso
“Turismo y Tecnologías de la Información y las Comunicaciones” TuriTec 2004
261 campo habitación, puede venir determinado por Planta, Número,
Orientación, Número de camas, … Etapa 2: Normalización. La reforma del
esquema conceptual tiene como objeto hacer una comprensión de dicho
modelo. En esta etapa de pretende aportar un significado en la semántica de
las construcciones explícitas. El objetivo es representar la información con una
metodología estándar que sea altamente legible.
 BASES DE DATOS ORIENTADOS A OBJETOS
Las Bases de datos orientados a objetos se propusieron con la idea de
satisfacer las necesidades de las aplicaciones más complejas. El enfoque
orientado a objetos ofrece la flexibilidad para cumplir con algunos de estos
requerimientos sin estar limitado por los tipos de datos y los lenguajes de
consulta disponibles en los sistemas de bases de datos tradicionales.
Como cualquier Bases de Datos programable, una Base de Datos Orientada a
Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y
un depósito persistente listo para su explotación. Una BDOO almacena y
manipula información que puede ser digitalizada (presentada) como objetos,
además proporciona un acceso ágil y permite una gran capacidad de
manipulación.
Los principales conceptos que se utilizan en las Bases de Datos Orientada
a Objetos (BDOO) son las siguientes:
· Identidad de objetos
· Constructores de tipos
· Encapsulamiento
· Compatibilidad con los lenguajes de programación
· Jerarquías de tipos y herencia
· Manejo de objetos complejos
· Polimorfismo y sobrecarga de operadores y
· Creación de versiones.

Bases De Datos Orientadas A Objetos

Artículo principal: Base de datos orientada a objetos
Este modelo, bastante reciente, y propio de los modelos informáticos
orientados a objetos, trata de almacenar en la base de datos los
objetos completos (estado y comportamiento).
Una base de datos orientada a objetos es una base de datos que incorpora
todos los conceptos importantes del paradigma de objetos:
Encapsulación – Propiedad que permite ocultar la información al resto de los
objetos, impidiendo así accesos incorrectos o conflictos.
Herencia – Propiedad a través de la cual los objetos heredan comportamiento
dentro de una jerarquía de clases.
Polimorfismo – Propiedad de una operación mediante la cual puede ser
aplicada a distintos tipos de objetos.
En bases de datos orientadas a objetos, los usuarios pueden definir
operaciones sobre los datos como parte de la definición de la base de datos.
Una operación (llamada función) se especifica en dos partes. La interfaz (o
signatura) de una operación incluye el nombre de la operación y los tipos de
datos de sus argumentos (o parámetros). La implementación (o método) de la
operación se especifica separadamente y puede modificarse sin afectar la
interfaz. Los programas de aplicación de los usuarios pueden operar sobre los
datos invocando a dichas operaciones a través de sus nombres y argumentos,
sea cual sea la forma en la que se han implementado. Esto podría
denominarse independencia entre programas y operaciones.
SQL: 2003, es el estándar de SQL92 ampliado, soporta los conceptos
orientados a objetos y mantiene la compatibilidad con SQL92.
Estructura de una BD OO
El paradigma orientado a objetos se basa en el encapsulamiento de datos
y del código relacionado con cada objeto en una sola unidad.
Conceptualmente, todas las interacciones entre cada objeto y el resto del
sistema se realizan mediante mensajes. Por lo tanto, la interfaz entre cada
objeto y el resto del sistema se define mediante un conjunto de mensajes
permitidos.
En general, cada objeto esta asociado con:
Un conjunto de variables que contiene los datos del objeto; las variables
corresponden con los atributos del modelo E-R.
Un conjunto de mensajes a los que responde; cada mensaje puede o no tener
parámetros o tener uno o varios.
Un conjunto de métodos, cada uno de los cuales es el código que implementa
un mensaje; el método devuelve un valor como respuesta al mensaje.
Mensaje en entorno OO no implica uso de mensajes físicos en redes
informáticas. Por el contrario, hace referencia al intercambio de solicitudes
entre los objetos, independientemente de los detalles correctos de su
implementación. Se utiliza a veces la expresión invocar un método para
detonar al hecho de enviar un mensaje a un objeto y la ejecución del método
correspondiente.
A. IDENTIDAD DE OBJETOS
Un sistema de BDOO provee una identidad única a cada objeto independiente
almacenado en la base de datos. Esta identidad única suele implementarse con
un identificador de objeto único, generado por el sistema, u OID. El valor de un
OID no es visible para el usuario externo, sino que el sistema lo utiliza a nivel
interno para identificar cada objeto de manera única y para crear y manejar las
referencias entre objetos.
La principal propiedad que debe tener un OID es la de ser inmutable; es decir,
el valor del OID para un objeto en particular nunca debe cambiar. Esto preserva
la identidad del objeto del mundo real que se está presentando. También es
preferible que cada OID se utilice sólo una vez; esto es aunque un objeto se
elimine de la Base de datos, su OID no se deberá asignar a otro objeto. Estas
dos propiedades implican que el OID no debe depender del valor de ningún
atributo del objeto, pues estos valores pueden cambiar. También suele
considerarse inapropiado basar el OID en la dirección física del objeto en el
almacenamiento, ya que una reorganización de los objetos de la base de datos
podría cambiar los OID. Sin embargo, algunos sistemas sí usan la dirección
física como OID para aumentar la eficiencia de la obtención de los objetos. Si la
dirección física cambia, puede colocarse un apuntador indirecto en la dirección
anterior, dando la nueva ubicación física del objeto. Un sistema de BDOO debe
contar con algún mecanismo para generar los OID con la propiedad de
inmutabilidad.
Algunos modelos de datos OO requieren que todo se represente como un
objeto, ya sea un valor simple o un objeto complejo; así, todo valor básico,
como un entero, una cadena o un valor booleano, tiene un OID. Con ello dos
valores básicos pueden tener diferentes OID, lo cual es muy útil en algunos
casos. Por ejemplo, en algunas ocasiones se podría usar el valor entero 50
para representar un peso en Kilogramos, y en otras para referirse a la edad de
una persona. Así podrían crearse dos objetos básicos con diferentes OID, y
ambos tendrían el mismo valor básico de 50. Aunque resulta útil como modelo
teórico, esto no es muy práctico porque puede obligar a generar demasiados
OID. Por ello también, la mayor parte de los sistemas de BDOO permiten
representar tanto objetos como valores. Todo objeto debe tener un OID
inmutable, pero los valores no tienen OID y se representan así mismo.
Los objetos tienen identidades únicas, independientes de los valores de sus
atributos.
La estructura orientad a objetos automáticamente impone las restricciones
relacionales, generalmente más aplicables: dominio, llave integridad de entidad
e integridad referencial.
B. CONSTRUCTORES DE TIPOS
En las BDOO, los valores (o estados) de los objetos complejos se pueden
construir a partir de otros objetos mediante ciertos constructores de tipos. Una
forma de representar tales objetos es considerar a cada objeto como tripleta (i,
c, v), donde i es un identificador de objeto único (el OID), c es un constructor
(esto es, una indicación de cómo se construye el valor del objeto) y v es el valor
(o estado) del objeto. Puede haber varios constructores, según el modelo de
datos y el sistema OO.
Los tres constructores básicos son:
constructores de átomos.
constructores de tuplas.
constructores de conjuntos.
Otros constructores de uso más común son los de listas y de arreglos. También
existe un dominio D que contiene todos los valores atómicos básicos que están
disponibles directamente en el sistema. Por lo regular estos incluyen los
enteros, los números reales, las cadenas de caracteres, los tipos boléanos, las
fechas y cualesquiera otros tipos de datos que el sistema maneje directamente.
C. ENCAPSULAMIENTO:
Tanto la estructura de los objetos como las operaciones que se pueden aplicar
a ellos se incluyen en las definiciones de clases de los objetos.
D. COMPATIBILIDAD CON LENGUAJES DE PROGRAMACION
Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-Relación
para modelar los datos y luego se convierten de manera manual en un conjunto
de relaciones; por lo tanto los conceptos de la Programación Orientada a
Objetos se utilizan simplemente como herramientas de diseño y se codifican,
utilizándose para trabajar con una base de datos.
Hay varios lenguajes posibles en los que se pueden integrar estos conceptos:
Una opción es extender un lenguaje para el tratamiento de datos como el SQL
añadiendo tipos complejos y la programación orientada a objetos. Los sistemas
proporcionan extensiones orientadas a objetos a los sistemas relacionales se
denominan sistemas relacionales orientados a objetos.
Otra opción es tomar un lenguaje de programación orientado a objetos ya
existente y extenderlo para que trabaje con las bases de datos. Estos lenguajes
se denominan lenguajes de programación persistentes. Estos lenguajes
permiten a los programadores trabajar directamente con los datos, desde el
lenguaje de programación; sin tener que pasar por un lenguaje para el
tratamiento de datos como SQL. Se denominan persistentes porque los
datos siguen existiendo una vez que el programa que los creó ha concluido.
A la hora de decidir que opción utilizar se debe tener en cuenta que los
Lenguajes Persistentes suelen ser potentes y resulta relativamente sencillo
cometer errores de programación que dañen las bases de datos. La
complejidad de los lenguajes hace la optimización automática de alto nivel,
como la reducción de E/S de disco, resulte difícil. En muchas aplicaciones, la
posibilidad de las consultas declarativas es de gran importancia, pero los
lenguajes persistentes no permiten actualmente las consultas declarativas sin
que aparezcan problemas de algún tipo.
E. JERARQUIA DE TIPOS Y HERENCIA
Los esquemas de BDOO suelen necesitar un gran número de clases. Sin
embargo, varias clases son parecidas entre sí.
Para permitir la representación directa de parecidos entre las clases, hay que
ubicarlas en una jerarquía de especializaciones. El concepto de jerarquía de
clases es parecido al de especialización del modelo E-R. Las especializaciones
de las clases son denominadas subclases; lo cual especifica atributos y
métodos adicionales para una clase existente. Los objetos creados por medio
de unas subclases heredan todos los atributos y métodos de la clase padre.
Algunas de estas características heredadas pueden ellas mismas haber sido
heredadas de clases más altas en la jerarquía.
F. MANEJO DE OBJETOS COMPLEJOS
Los objetos se consideran complejos porque requieren un área de
almacenamiento sustancial y no forman parte de los tipos de datos estándar
que suelen ofrecer los SGBD. Puesto que el tamaño de los objetos es
considerable, un SGBD podría obtener una porción del objeto y proporcionarla
al programa de aplicación antes de obtener todo el objeto. El SGBD podría
también usar técnicas de almacenamiento intermedio y caché para obtener por
anticipado porciones del objeto, antes de que el programa de aplicación
necesite tener acceso a ellas.
En un SGBOO, esto puede lograrse definiendo un nuevo tipo de datos
abstracto para los objetos no interpretados y suministrados los médos para
seleccionar, comprar y exhibir tales objetos.
Como un SGBOO permite a los usuarios crear nuevos tipos, y como un tipo
incluye tanto estructura como operaciones, podemos considerar que un
SGBOO tiene un sistema de tipos extensibles. Podemos crear bibliotecas de
nuevos tipos definiendo su estructura y operaciones, incluso con tipos
complejos.
Muchos SGBDOO pueden almacenar y obtener objeto no estructurado extenso
en forma de cadenas y caracteres o de bits, que se pueden pasar “tal cual” al
programa de aplicación para que las interprete.
Es posible almacenar y manipular objetos complejos tanto estructurados como
no estructurados.
G. POLIMORFISMO
El polimorfismo se refiere al uso de la misma firma de mensaje para dirigir
diferentes métodos en diferentes clases. Cuando el diseñador envía una señal
a un objeto, el método de la clase de objeto, posiblemente heredado, procesa
la señal.
Un método puede tener acceso directamente a atributos de un objeto destino
por no nombre, al incluir cualesquiera atributos heredados de clases padres,
pero debe tener acceso a atributos de otros objetos con señales secundarias.
En síntesis este concepto permite enlazar el mismo nombre o símbolo de
operador a dos o más implementaciones diferentes del operador, dependiendo
del tipo de objetos a los que éste se aplique.
H. CREACION DE VERSIONES
Muchas aplicaciones de bases de datos que usan sistemas OO requieren la
existencia de varias versiones del mismo objeto.
Por lo regular, se aplican actividades de mantenimiento a un sistema de
software conforme sus requerimientos evolucionan. Por lo regular, el
mantenimiento implica modificar algunos de los módulos de diseño y de
implementación. Si el sistema ya está en operación, y si es preciso modificar
uno o más módulos, el diseñador deberá crear una nueva versión de cada uno
de ellos para efectuar cambios.
Cabe señalar que puede haber más de dos versiones de un objeto.
En caso que se requieran dos versiones, además del módulo original. Se
puede actualizar concurrentemente las propias versiones del mismo módulo del
software. Esto se llama ingeniería concurrente. Sin embargo, siempre llega el
momento en que es preciso combinar (fusionar) estas dos versiones para que
la versión hibrida incluya los cambios realizados. Es necesario de que sus
cambios sean compatibles.
Un objeto complejo, como un sistema de software, puede constar de muchos
módulos. Cuando se permite la creación de múltiples versiones, es posible que
cada una de esos módulos tenga varias versiones distintas y un grafo de
versiones.
Como se deduce del análisis anterior, un SGBDOO debe ser
capaz de almacenar y controlar múltiples versiones del mismo objeto.
Características de BD OO
Se intenta definir un sistema de BDOO y describe las principales
características en tres grupos:
Mandatorias: son las que el Sistema debe satisfacer a orden de tener un
sistema de BDOO y estos son: Objetos complejos, Identidad de Objetos,
Encapsulación, Tipos o clases, Sobre paso con unión retardada, Extensibilidad,
Completación Computacional, Persistencia y Manejador de almacenamiento
secundario, Concurrencia, Recuperación y Facilidad de Query.

CARACTERISTICAS OBLIGATORIAS
Este es un punto que no debe faltar en BD.
Predominancia combinada con enlace retardado: se puede definir que sea
Excel, Autocad, etc. desde la programación.
Extesibilidad: Proporciona los tipos de datos como: Carácter, booleano, string,
etc.
Concurrencia: permite que varios usuarios tengan acceso a una BD al
mismo tiempo.
Recuperación: Cuando se hace una transacción pero no se puede realizar y se
regresa al mismo estado.
Facilidad de “Consultas a Modo”. Esto es cuando se tienen diferentes
estándares.
Ventajas
La clave que posee la BDOO es el poder que confieren al diseñador para
especificar tanto la estructura de objetos complejos como las operaciones que
se pueden aplicar a esos objetos.
– Está su flexibilidad, y soporte para el manejo de tipos de datos
complejos. Por ejemplo: En una base de datos convencional, si una empresa
adquiere varios clientes por referencia de clientes servicio, pero la base de
datos existente, que mantiene la información de clientes y sus compras, no
tiene un campo para registrar quién proporcionó la referencia, de qué manera
fue dicho contacto, o si debe compensarse con una comisión, sería necesario
reestructurar la base de datos para añadir este tipo de modificaciones. 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 estos campos
Naturalmente se generan los espacios para almacenar la información adicional
de los nuevos campos. 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.
POSIBLES DESVENTAJAS DE UNA BDOO
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 la línea de producción sustantiva. Por eso en este
artículo se propone que se explore esta tecnología en un proyecto piloto.
El segundo problema es la falta de estándares en la industria orientadas a
objetos. 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 orientados a objetos en ambiente de cómputos de 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. Sin embargo, para aquellos que
planean a un futuro intermedio con una visión tecnológica avanzada, el uso de
tecnología avanzada, el uso de tecnología orientada a objetos, paulatinamente
compensará todos los riesgos.