Definición de un SGBD orientado a objetosKim (1991) define un modelo de datos orientado a obajetos y una base de datos orientada a objetos y un SGBD orientado a objetos (SGBDOO) de la forma siguiente:

Modelo de datos orientado a objetos: Un modelo de datos (lógico) que captura la semántica de los objetos soportados en la programación orientada a objetos.

Base de datos orientada a objetos: Una colección persistente y compatible de objetos definida por un modelo de datos orientado a objetos.

SGBDOO: El gestor de un base de datos orientada a objetos.

Estas definiciones no son muy descriptivas y tienden a reflejar el hecho de que no existe ningún modelo de datos orientado a objetos que sea equivalente al modelo de datos subyacente a los sistemas relacionales. Cada sistema proporciona su propia interpretación de la funcionalidad básica. Por ejemplo, Zdonik y Maier (1990) presentan una serie de umbrales que un SGBDOO debe como mínimo satisfacer:

(1) debe proporcionar funcionalidad de base de datos;

(2) debe soportar el concepto de identidad de los objetos;

(3) debe proporcionar un mecanismo de encapsulación;

(4) debe soportar objetos con estado complejo.

Los autores argumentan que, aunque la herencia puede ser útil, no resulta esencial para la definición, y un SGBDOO podría existir sin dicho mecanismo. Por el contrario, Khoshafian y Abnous (1990) definen un SGBDOO como:

(1) orientación a objetos = tipos de datos abstractos de datos + herencia + identidad de los objetos;

(2) SGBDOO = orientación a objetos + capacidades de base de datos.

Otra definición más de un SGBDOO es que proporciona Parsaye et al. (1989):

(1) un lenguaje de consulta de alto nivel con capacidades de optimización de las consultas en el sistema subyacente;

(2) soporte para la persistencia, transacciones atómicas y control de concurrencia y recuperación;

(3) soporte para el almacenamiento de objetos complejos, índices y métodos de acceso para una extracción rápida y eficiente de los datos;

(4) SGBDOO = sistema orientado a objetos + (1) + (2) + (3).

Bibliografía: Thomas M. Connolly, Carolyn E. Begg, Sistemas de bases de datos, Un enfoque práctico para diseño, implementación y gestión, Ed. Pearson Addison Wesley, 4a. Edición.

* Orientado a objetos: define a la base de datos en términos de objetos, sus propiedades y sus operaciones. Todos los objetos que tienen la misma estructura y comportamiento pertenecen a una clase y las clases de organizan en jerarquías.

Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.

Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programación.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

Historia

Los orígenes del término orientados a objetos (abreviado OO) se remontan a los lenguajes de programación orientadas a objetos. Los lenguajes de programación OO tienen sus raíces en el lenguaje SIMULA 67, propuesto a finales de la década de 1960. En Simula, el concepto de clase agrupa la estructura de datos interna de un objeto en una declaración de clase, es decir, introduce en el lenguaje Algol los conceptos de objeto y de clase. Como Algol, Simula es un lenguaje fuertemente tipado para entornos compilados. Sin embargo, el primer lenguaje que popularizó la aproximación a objetos fue Smalltalk (1976); este puede considerarse una síntesis de años del lenguaje Lisp, que ofrece una gran flexibilidad gracias a la interpretación, y de Simula, añadiendo el concepto de metaclase. Smalltalk ha podido responder a las necesidades de flexibilidad presentadas por el desarrollo de entornos de programación gráficos, favoreciendo la rápida creación de prototipos de interfaces de usuarios amigables. Fue utilizado con éxito en la primera estación gráfica de Xerox.

Con la llegada de las estaciones de trabajo en los años 80, han crecido numerosos lenguajes orientados a objetos inspirados en Simula o Smalltalk. Entre los lenguajes compilados, los más celebres son C++, Objective C y Eiffel, debido a la compatibilidad del lenguaje o del código producido con el lenguaje de programación C. La mayor parte de los lenguajes interpretados son extensiones del Lisp; por ejemplo, Loops y CLOS. Es interesante notar que la mayor parte de los lenguajes populares existentes se encuentran en curso de ampliación para convertirse en

orientados a objetos, incluyendo al Cobol y Ada (más exactamente Ada 9X, que aporta la herencia).

En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Y entre los sistemas disponibles en el mercado están: GEMSTONE/OPAL de ServicLogic, ONTOS de Ontologic, Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjecStore de Object Design y O2 de O2 Technology. Esta es solo una lista parcial de los prototipos experimentales y de los sistemas de bases de datos comerciales orientados a objetos. Desafortunadamente, es aún demasiado pronto para saber cuáles sistemas se instalarán como líderes en este campo.

Las bases de datos orientados a objetos han adoptado muchos de los objetos creados para los lenguajes de programación orientados a objetos.

SISTEMAS GESTORES DE BASES DE DATOS ORIENTADAS A OBJETOS

BASES DE DATOS ORIENTADAS A OBJETOS

Hasta la aparición de las Bases de Datos (BD) Orientadas a Objetos (BDOO), las Bases de Datos tradicionales no estaban diseñadas para almacenar objetos, con lo que al guardar los datos de un programa Orientada a Objetos se incrementaba significativamente la complejidad del programa, dando lugar a más código y más esfuerzos de programación.

Las BDOO están diseñadas para simplificar la Programación Orientada a Objetos (POO):

• Almacenan los objetos directamente en la BD, y emplean las mismas estructuras y relaciones que los lenguajes de POO.

• Se pueden tratar directamente con objetos, no teniendo que hacer la traducción a tablas o registros.

• Los objetos se conservan, pueden ser gestionados aunque su tamaño sea muy grande, pueden ser compartidos entre múltiples usuarios, y se mantienen tanto su integridad como sus relaciones. Una clase después de programada es transportada a la BD tal como es, al contrario de lo que sucede en los SGBD relacionales donde el modelo de datos se distribuye en tablas

• Las BDOO permiten implementar los tres componentes de un modelo de datos:

1. Propiedades estáticas (objetos, atributos y relaciones)

2. Reglas de integridad de los objetos y operaciones

3. Propiedades dinámicas

Las BDOO surgen de la combinación de las BD tradicionales y la POO.

Un Sistema Gestor de Base de Datos Orientados a Objetos (SGBDOO) es un Sistema de Objetos y un Sistema Gestor de Base de Datos (SGBD). Se puede decir que un SGBDOO es un SGBD que almacena objetos incorporando así todas las ventajas de la POO.

CARACTERÍSTICAS BÁSICAS DE UN SGBDOO

Un SGBDOO debe satisfacer dos criterios:

1. Ser un SGBD lo que se traduce en 5 características principales:

• Persistencia

• Concurrencia

• Recuperación ante fallos

• Gestión del almacenamiento secundario

• Facilidad de Consultas.

2. Ser un Sistema Orientado a Objetos (OO) por lo que debe cumplir algunas características como:

• Encapsulación

• Identidad

• Herencia

• Polimorfismo.

[pic]

Extensibilidad

El sistema de base de datos viene con un conjunto de tipos predefinidos Estos tipos pueden ser utilizados por los programadores para escribir sus aplicaciones y tiene la capacidad de crear nuevos tipos basados en los predefinidos

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.

La gestión del almacenamiento secundario

La gestión del almacenamiento secundario es una característica clásica de los sistemas de gestión de base de datos Por lo general, el apoyo es a través de un conjunto de mecanismos Estas incluyen administración de índices, agrupación de datos, almacenamiento temporal de datos ,selección de la ruta de acceso y optimización de consultas.

Concurrencia

Con respecto a la gestión de múltiples usuarios al mismo tiempo que interactúan con el sistema, el sistema debe ofrecer el mismo nivel de servicio como los actuales sistemas de bases de datos proporcionan.

Recuperación ante fallos

En caso de fallos de hardware o software, el sistema debe recuperar, es decir, llevar en sí de nuevo a un estado coherente de los datos. Los fallos de hardware incluyen tanto los fallos de procesador y disco.

Fondo Especial de consultas

Permitir al usuario hacer consultas simples a la base de datos.

Debe satisfacer los tres criterios siguientes:

• Debe ser capaz de expresar en pocas palabras o en unos clics del ratón las consultas

• Debe ser eficiente.

• Debe ser independiente de la aplicación, es decir, que debería funcionar en cualquier base de datos posible.

Encapsulación

Consiste en la necesidad de distinguir entre la especificación y la implementación de una operación.

Abstracción

Denota las características esenciales de un objeto que lo distinguen de todos los demás tipos objeto, y proporciona así fronteras conceptuales nítidamente definidas respecto a la perspectiva del observador". Una abstracción se centra en la visión externa de un objeto, y, por tanto sirve para separar el comportamiento esencial de un objeto de su implantación.

Clase

Las clases se utilizan para crear y manipular objetos.

Herencia

Un ejemplo ayudará a ilustrar el interés en que el sistema de proporcionar un mecanismode herencia. Supongamos que tenemos empleados y estudiantes. Cada empleado tiene un nombre, una edad superior a 18 y un salario, él o ella puede morir, casarse y serpagado (como aburrida es la vida de los empleados!).

Cada estudiante tiene una edad, un nombre y un conjunto de grados. Él o ella puede morir, casarse y tener su promedio calculado.

En un sistema relacional, el diseñador de la base de datos define una relación de los empleados, una relación de los estudiantes, escribe el código de la matriz, se casan ypagar las operaciones en la relación del empleado, y escribe el código de la matriz, se casan y el cálculo del GPA para el Relación con los estudiantes. Por lo tanto, la aplicación programador escribe seis programas.

En un sistema orientado a objetos, utilizando la propiedad de herencia, reconocemos que los empleados y estudiantes son las personas, por lo que tienen algo en común (el hecho de ser una persona), y también tienen algo específico.

Sobre escritura

En contraste con el ejemplo anterior, existen casos en que uno quiere tener el mismo nombre utilizado para diferentes operaciones.

CARACTERISTICAS OPCIONALES DE LOS SGBOO

Herencia múltiple

Una clase puede heredar de varias clases.

La verificación de tipos y la inferencia de tipo

El grado de comprobación de tipos que el sistema funcionará en tiempo de compilación se deja abierto, pero mientras más, mejor. La situación óptima es aquella donde un programa que fue aceptado por el compilador no puede producir en tiempo de ejecución los errores de tipo. El importe de la inferencia de tipo también se deja abierta a la

diseñador del sistema: cuanto más mejor, la situación ideal es aquella en la que sólo los tipos de base tienen que ser declarados y el sistema deduce el tipo temporal

Distribución

Debe quedar claro que esta característica es ortogonal a la naturaleza orientada a objetos del sistema. Así, el sistema de base de datos puede ser distribuido o no.

Versiones

Tener soporte para versiones

Paradigma de programación

Se puede elegir entre distintos tipos de programación: el estilo de programación lógica, el estilo de programación funcional o el estilo de programación imperativa o de soporte de múltiples paradigmas de programación

Bloqueo

Los SGBDOO te pueden proporciona el bloqueo:

• Bloqueos de Lectura.- Leer una dato y que no quieres que nadie lo modifique mientras los estas usando.

• Bloqueos de Escritura.- Bloquear el Objeto mientras yo estoy escribiendo (nadie más puede escribir).

MODELO PROPUESTO POR EL OBJECT DATABASE MANAGEMENT GROUP (ODMG)

INTRODUCCIÓN

El ODMG es un consorcio industrial de vendedores de SGBDOO que después de su creación se afilió al Object Management Group (OMG). El ODMG no es una organización de estándares acreditada en la forma en que lo es ISO o ANSI pero tiene mucha influencia en lo que a estándares sobre SGBDO se refiere.

En 1993 publicó su primer conjunto de estándares sobre el tema, el ODMG-93, que en 1997 evolucionado hacia el ODMG 2.0, en enero de 2000 se publico el ODMG 3.0 aun a estos esfuerzos en

el caso de las BDOO la carencia de un estándar es la mayor limitación para su uso generalizado.

ODMG-93 adopta una arquitectura que consta de:

• 1 Sistema de gestión que soporta un lenguaje de BDOO, con una sintaxis similar a un lenguaje de programación OO (C++, Smalltalk, por ejemplo).

El lenguaje de BD es especificado mediante:

• 1 Lenguaje de Definición de Objetos (ODL) que se corresponde con el DDL de los SGBD tradicionales,

• 1 Lenguaje de Manipulación de Objetos (OML)

• 1 Lenguaje de Consulta (OQL).

En esta arquitectura:

1. El programador escribe declaraciones para el esquema de la aplicación, y un programa fuente para la implementación.

2. El programa fuente se escribe en un lenguaje de programación orientado a objetos

3. Las declaraciones del esquema pueden escribirse mediante una extensión del lenguaje de programación o en un lenguaje de programación independiente ODL.

4. Las declaraciones y el programa fuente son compilados con el SGBDOO para producir la aplicación ejecutable. La aplicación accede a BD nuevas o ya existentes, cuyos tipos deben estar de acuerdo con las declaraciones.

EL MODELO DE OBJETOS

El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean portables entre los sistemas que lo soportan.

Dispone de las siguientes primitivas de modelado:

1. Los componentes básicos de una base de datos orientada a objetos son los objetos y los literales.

2. Un objeto es una instancia autocontenida de una entidad de interés del mundo real.

3. Los objetos tienen algún tipo de identificador único.

4. Un literal es un valor específico, como “Amparo” o 36.

5. Los literales no tienen identificadores.

6. Un literal no tiene que ser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre.

7. Los objetos se dividen en tipos.

8. Los objetos de un mismo tipo tienen un mismo comportamiento y muestran un rango de estados común

9. El comportamiento se define por un conjunto de operaciones que pueden ser ejecutadas por un objeto del tipo.

10. El estado de los objetos se define por los valores que tienen para un conjunto de propiedades.

11. Las propiedades pueden ser:

• Atributos del objeto: Los atributos toman literales por valores y son accedidos por operaciones del tipo get_value y set_value.

• Relacionales entre el objeto y uno o más objetos: Son propiedades que se definen entre tipos de objetos, no entre instancias.

12. Las relaciones pueden ser:

• 1 a 1

• 1 a muchos

• Muchos a muchos.

13. Un tipo tiene una interfaz y una o más implementaciones.

14. La interfaz define las propiedades visibles externamente y las operaciones soportadas por todas las instancias del tipo.

15. La implementación define la representación física de las instancias del tipo y los métodos que implementan las operaciones definidas en la interfaz.

16. Los tipos pueden tener las siguientes propiedades:

• Supertipos. Los tipos se pueden jerarquizar. Todos los atributos, relaciones y operaciones definidas sobre un supertipo son heredadas por los subtipos.

• Los subtipos pueden añadir propiedades y operaciones adicionales para proporcionar un comportamiento especializado a sus instancias.

• Además de la herencia simple, se admite la herencia múltiple, y en el caso de que 2 propiedades heredadas coincidan en el subtipo, se redefinirá el nombre de una de ellas.

17. Claves: propiedad o conjunto de propiedades que identifican de forma única las instancias de un tipo. Las claves simples están constituidas por una única propiedad. Las claves compuestas están constituidas por un conjunto de propiedades. Las claves pueden estar constituidas no sólo por atributos, sino también por relaciones.

18. Un tipo puede tener una o más implementaciones. A cada una de estas implementaciones se le da un nombre, que además debe ser único dentro del ámbito definido por un tipo. Las implementaciones asociadas a un tipo son separadas léxicamente en el Lenguaje de Definición de Objetos (ODL). Una clase, en este modelo, es la combinación de la interfaz del tipo y una de las implementaciones definidas. El hecho de permitir varias implementaciones presenta varias ventajas. La primera de ellas es que soporta fácilmente BD que están sobre redes, donde puede haber máquinas con arquitecturas diferentes (soportando mezcla de lenguajes y compiladores). La segunda es que facilita al programador su tarea al poder comparar fácilmente cuál de las implementaciones se comporta mejor. La implementación que emplee un objeto se especifica en tiempo de creación.

LENGUAJE DE DEFINICION DE DATOS (ODL)

El ODL es el equivalente del Lenguaje de Definición de Datos (DDL) de los SGBD tradicionales.

Define:

• Los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones.

En una BD relacional define las tablas, los atributos en la tabla, el dominio de los atributos y las restricciones sobre un atributo o una tabla. El ODL además debe poder definir también métodos, jerarquías, herencia, etc.

Tipos en el lenguaje ODL

El ODL ofrece al diseñador de BD un sistema de tipos semejantes a los de otros lenguajes de programación comunes:

• Se pueden crear tipos complejos a partir de otros más simples.

• Los tipos permitidos son:

1. Tipos básicos que son:

a. Tipos atómicos:

✓ Enteros,

✓ De punto flotante,

✓ Caracteres

✓ Cadenas de caracteres

✓ Booleanos.

b. Enumeraciones.- Conjunto de valores.

2. Tipos de interfaz o estructurados.- Son tipos complejos obtenidos al combinar tipos básicos por medio de los siguientes constructores de tipos

3. Lista.- Denota el tipo cuyos valores son listas ordenadas finitas conteniendo 0 o más elementos del tipo

4. Array (Array) denota el tipo cuyos elementos son arrays de i elementos del tipo tipo.

5. Estructura

• Hay reglas sobre qué tipos pueden asociarse a atributos y cuáles a relaciones

o El tipo de un atributo se construye partiendo de un tipo básico o de una estructura cuyos campos sean básicos.

o El tipo de una relación es un tipo de interfaz o un tipo de colección que se aplica a un tipo de interfaz.

LENGUAJE DE MANIPULACION DE OBJETOS (OML)

El OML es empleado para la elaboración de programas que permitan crear, modificar y borrar datos que constituyen la BD. El ODMG no propone un OML estándar, simplemente sugiere que este lenguaje sea la extensión de un lenguaje de programación, de forma que se puedan realizar, entre otras, las siguientes operaciones sobre la BD:

• Creación de un objeto

• Borrado de un objeto

• Modificación de un objeto

• Identificación de un objeto

LENGUAJE DE CONSULTA DE OBJETOS (OQL)

El OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras.

Está basado en SQL-92, proporcionando un superconjunto de la sintaxis de la sentencia SELECT.

OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los métodos que estos poseen.

SISTEMAS GESTORES DE BASES DE DATOS

|# |SOFTWARE |COMPAÑIA |AÑO |CONSEGUIDO |

|1 |Shore |Shore |1997 |NO |

|2 |Texas |Shingai |1992 | |

|3 |Thor |Thor |1997 | |

|4 |BDOviedo3 | | | |

|5 |O2 |O2 Technology | | |

|6 |Gemstone |Serviologic | |SI |

|7 |Ontos |OntologicSystem | |NO |

|8 |G-Base |Graphael | | |

|9 |Orion 2 |Itasca Systems | | |

|10 |Statice |Symbolics | | |

|11 |Vision |Innovative Systems | | |

|12 |Observer |Object Design | | |

|13 |Orion |MCC | | |

|14 |Encore |Brown University | | |

|15 |O2 |Altair | | |

|16 |Iris |HP | | |

|17 |ZeitGest |Texas Instruments | | |

|18 |ODE |AT&T | | |

|19 |Jazmine |Fujitsu | | |

|20 |Itasca |Itasca Systems | | |

|21 |Objectivity | | | |

|22 |Object Store | | |SI |

|23 |Versant | | | |

|24 |Object DB3 | | | |

|25 |DB4o | | | |

|26 |Matisse |Matisse | | |

|27 |Informix |IBM | | |

MATISSE: UN EJEMPLO DE UN SGDBOO

Matisse de ADB Inc. es un SGBDOO con soporte para C, C++, Eiffel y Java.

Matisse es un diseño atrevido con muchas ideas no convencionales. Está especialmente orientado a grandes bases de datos con una rica estructura semántica, y puede manipular objetos muy grandes como imágenes películas y sonidos.

Aunque admite los conceptos básicos de la orientación a objetos, tales como la herencia múltiple.

Matisse se abstiene de imponer demasiadas restricciones como lo tocante al modelo de datos y sirve en su lugar como un potente motor de base de datos orientadas a objetos.

VENTAJAS:

• Una técnica de representación original que hace posible fragmentar un objeto, especialmente un objeto grande, en varios discos, para optimizar así el tiempo de acceso.

• Una ubicación optimizada de los objetos en los discos.

• Un mecanismo automático de duplicación que proporciona una solución software a los fallos de tolerancia del hardware: los objetos (en lugar de los discos en sí) se pueden duplicar especularmente en varios discos, con recuperación automática en caso de fallo del disco.

• Un mecanismo de versiones de objetos incorporado.

• Soporte para las transacciones.

• Soporte para una arquitectura cliente-servidor en la cual un servidor central gestiona los datos para un número posiblemente elevado de clientes, que mantienen una “reserva” de objetos a los que se haya accedido recientemente.

• Proporciona un entorno gráfico que permite la definición del esquema de la base de datos sin necesidad de conocer la sintaxis ODL

DEFINICION DE UNA BDOO EN MATISSE

interface Persona : persistent { attribute String nombre; attribute String ape1; attribute String ape2; relationship List posee[0, -1] inverse Coche::es_poseido; }; interface Coche : persistent { attribute String matricula; relationship Persona es_poseido inverse Persona::posee; };

GENERACIÓN DE FICHEROS FUENTE

Para ello se recurre a un comando del tipo mt_sdl stubgen -[cxx|eiffel|java] [-n paquete] fichero.odl

Persona.h

#ifndef Persona_H #define Persona_H 1

#include #include class Coche; using namespace matisse; using namespace matisse::reflect;

class Persona : public virtual MtObject { public: static MtObject *newStub(const MtDatabase &db, ::MtOid oid); private: static const MtStub stub; protected: Persona(const MtDatabase &db, ::MtOid oid); virtual ~Persona(); private: static const unsigned int CID; public: static MtClass &getClass(const MtDatabase &db); static MtObjectIterator instanceIterator(const MtDatabase &db); static unsigned int getInstanceNumber(const MtDatabase &db);

/* Attribute 'nombre' */ private: static const unsigned int nombreCID;

public: static MtAttribute &getNombreAttribute(const MtDatabase &db); std::string getNombre() const; void setNombre(const std::string & val) const; void removeNombre() const;

/* Relationship 'posee' */ private: static const unsigned int poseeCID; public:

static MtRelationship &getPoseeRelationship(const MtDatabase &db); MtObjectArray getPosee() const; unsigned int getPoseeSize() const; MtObjectIterator poseeIterator() const; void setPosee(const MtObjectArray &succs) const; void prependPosee(const Coche &succ) const; void appendPosee(const Coche &succ) const; void appendPosee(const MtObjectArray &succs) const; void removePosee(const MtObjectArray &succs) const; void removePosee(const Coche &succ) const; void clearPosee() const;

// END of mt_odl generated code // You may add your own code here... /*COMO INDICA EL COMENTARIO ANTERIOR AQUÍ SE PUEDE AÑADIR NUEVOS MÉTODOS*/ void imprime_ncompleto(){ std::cout

[pic]

Escuchar

Leer fonéticamente

Diccionario - Ver diccionario detallado

Escuchar

Leer fonéticamente

Diccionario - Ver diccionario detallado

1. nombre

1. recuperación

2. cobro

3. reactivación

4. recobro

5. restablecimiento

6. rescate

7. mejoría