La Reingeniera de Bases de Datos (DBRE)

La Reingeniera de Bases de Datos (DBRE) es el conjunto de tcnicas que permite la obtencin de una representacin conceptual de un esquema de base de datos a partir de su codificacin. Sus aplicaciones son mltiples, desde la redocumentacin de bases de datos que evolucionaron en el ambiente operativo hasta la reutilizacin de esquemas de bases de datos, pasando por el apoyo a la migracin y la construccin de metabases. El proceso de DBRE consiste en revertir las dos ltimas fases comnmente aplicadas en el proceso de "ingeniera hacia adelante". Especficamente, deben revertirse secuencialmente la fase lgica, donde a partir de un esquema conceptual se elabora un esquema lgico, y la fase fsica, donde el esquema lgico es optimizado para un DBMS en particular, generandose el esquema fsico de la base de datos. Se denomina a la primera fase de reversin, fase de extraccin; a la segunda fase de reversin se la denomina fase de conceptualizacin.

El proceso de DBRE consiste en revertir las dos ltimas fases comnmente aplicadas en el proceso de "ingeniera hacia adelante". Especficamente, deben revertirse secuencialmente la fase lgica, donde a partir de un esquema conceptual se elabora un esquema lgico, y la fase fsica, donde el esquema lgico es optimizado para un DBMS en particular, generndose el esquema fsico de la base de datos. Se denomina a la primera fase de reversin, fase de extraccin; a la segunda fase de reversin se la denomina fase de conceptualizacin. La fase de conceptualizacin, durante la cual se explicitan las estructuras conceptuales que derivaron en las estructuras de datos implementadas. La fase de conceptualizacin produce como salida un esquema conceptual utilizando algn modelo semntico que se almacena en una base de datos denominada base de datos semntica Entonces, durante el proceso de reingeniera de una base de datos se distinguen a su vez dos fases, denominadas fase de extraccin y fase de conceptualizacin, que revierten respectivamente a la fase fsica y a la fase lgica. La DBRE-KB almacena al esquema lgico extrado del esquema fsico de la base de datos fuente, y es utilizada como entrada para los procesos de la fase de conceptualizacin.

Posteriormente, sobre el esquema lgico extrado en la fase de extraccin se aplican diferentes procesos que permiten generar un esquema conceptual. Estos procesos ocurren durante la fase de conceptualizacin, en la cual se explicitan las estructuras conceptuales que derivaron en las estructuras de datos implementadas en la base de datos fuente. Esta fase produce como salida un esquema conceptual utilizando algn modelo semntico. Este modelo semntico se almacena en una estructura a la que genricamente se denomina base de datos semntica. En la base de datos semntica se almacenarn los objetos conceptuales y los vnculos existentes entre ellos. Los algoritmos de reingeniera obtienen informacin de diversos orgenes: el esquema de la base de datos fuente, la extensin de la misma y las operaciones SQL existentes en las aplicaciones. La intervencin del usuario experto es requerida por algunos algoritmos. La informacin obtenida, as tambin como el grado de confiabilidad de la misma dependiente del origen de donde se obtuvo dicha informacin se almacena como resultado intermedio, en el repositorio denominado base de conocimiento que se describe ms adelante. Sobre el esquema lgico extrado en la fase de extraccin se aplican diferentes procesos que permiten generar un esquema conceptual. Estos procesos ocurren en la fase de conceptualizacin, durante la cual se explicitan las estructuras conceptuales que derivaron en las estructuras de datos implementadas. Esta fase produce como salida un esquema conceptual utilizando algn modelo semntico. Este modelo semntico se almacena en una estructura a la que genricamente se denomina base de datos semntica. En la base de datos semntica se almacenarn los objetos conceptuales y los vnculos existentes entre ellos. La base de datos semntica. El propsito del modelo conceptual es describir el contenido de la informacin de la base de datos, en vez de las estructuras de almacenamiento que se requerirn para manejar esa informacin. Se expresa mediante un lenguaje de muy alto nivel. Es un modelo de datos que describe un conjunto de conceptos de una realidad. Los mdulos de conceptualizacin comprenden a los algoritmos utilizados en la fase de conceptualizacin. Estos algoritmos acceden al repositorio de la base de conocimiento y mapean sus objetos en objetos semnticos, que se almacenan en el repositorio de la base semntica. Los algoritmos de conceptualizacin se encargan de detectar los objetos, links entre objetos y tipos de links.

El proceso de reingeniera de bases de datos, consiste en la recuperacin mediante distintos mtodos de toda la informacin de las distintas vistas (fsica, conceptual y lgica) de la base de datos actual (LDB - Base de datos legada) para en posteriores etapas conseguir modificar y redisear 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 migracin de datos de la LDB a la NDB. El esquema lgico que se obtiene en esta fase ser la entrada de la siguiente fase, que como hemos comentado anteriormente, se denomina Abstraccin conceptual, la cual transformar el esquema lgico a un esquema conceptual equivalente basado en modelo entidad-relacin, el cual proporcionar una rica base en la fase de reingeniera de la base de datos (RBD). Tambin se conoce a esta fase como Interpretacin de las estructuras de datos, pues se va a realizar una optimizacin del esquema lgico. Un ejemplo de conceptualizacin bsica podra ser si tenemos campos que tienen la misma estructura y que se refieren a atributos de la entidad iguales, se transformarn en un atributo multivaluado. En el nivel conceptual se describe la estructura de toda la base de datos para una comunidad de usuarios mediante un esquema conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se concentra en describir entidades, atributos, relaciones operaciones de los usuarios y restricciones. En este nivel se puede utilizar un modelo conceptual o modelo lgico para especificar el esquema. La independencia lgica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de la aplicacin. Se puede modificarlo para ampliar la base de datos o para reducirla si por ejemplo se reduce la bdd eliminando la entidad los esquemas externos que no se refieren a ella no debern verse afectados. PARTICIPACIN DE LOS USUARIO EN LA RBD. En la reingeniera de bases de datos se conocen etapas en las que los desarrolladores necesariamente deben estar fuertemente relacionados con los usuarios ya que estos a mas de ser quienes finalmente utilicen la aplicacin, son los que conocen a mayor detalle el proceso y las transacciones que necesitan que se ejecuten y satisfagan sus necesidades; de ah la necesidad de implementar una reingeniera de base de datos, por lo tanto se identifican ciertas etapas que son las siguientes:

FASE 1 Extraccin automtica Mediante herramientas automticas se obtiene la estructura inicial de la bdd. Extraccin acumulativa Participacin de los usuarios del modelo de datos aprovechando su conocimiento. Unin de esquema Unir y reconvertir las estructuras y restricciones obtenidas en las dos fases anteriores informacin obtenida en la etapa 2 se pretende complementar la informacin obtenida en la etapa 1. Anlisis de programas Estudio del cdigo fuente existente Podramos incluir el anlisis de formularios, consultas, informes, FASE2 Conceptualizacin bsica Campos que tienen la misma estructura y que se refieren a atributos de la entidad iguales Normalizacin Pretende aportar un significado en la semntica de las construcciones explcitas El objetivo es representar la informacin con una metodologa estndar que sea altamente legible De las fases y etapas antes mencionadas cabe especificar en las cuales los usuarios tienen parte y ello depender no tanto del conocimiento en el proceso de reingeniera que estos tengan, mas bien del anlisis y evaluacin que ellos supongan del manejo y el procedimiento que el modelo deba tener. En la etapa de Extraccin acumulativa (etapa 2) los usuarios pueden requerir aadir informacin de la ya obtenida en la etapa de extraccin automtica.

Como hemos comentado anteriormente es posible que ciertas reglas no puedan obtenerse directamente en la de extraccin automtica, por lo que aprovechando el conocimiento adquirido por los usuarios en el trabajo diario se podr obtener informacin muy interesante Aqu la importancia del conocimiento de procesos de trabajo que poseen los usuarios quienes en el da a da conocen el manejo y tratamiento que debera tener la informacin sobretodo en el diseo de interfaces, como se presentar la informacin al usuario y como este la interpreta si se acopla o no a lo que se busca. A ms de estas actividades se puede identificar otros aspectos en los cuales la participacin de los usuarios es necesaria ya que finalmente el responsable del producto final de reingeniera no ser el usuario en si sino el desarrollador del modelo, y las necesidades, comentarios, o puntos de vista en los que el usuario convenga intervenir sern muy importantes, sean estos modificar la descripcin de campos, que acerquen mas a la realidad de la empresa y permitan identificar de mejor manera el rol y la funcin que determinada entidad cumple. Aunque se cuente con software capaz de agilizar el proceso de reingeniera, como se menciono anteriormente no se debe escatimar ningn aporte que el usuario desee realizar, tomando en cuenta que su perspectiva como tal no ser clara ante el punto de apreciacin de los desarrolladores sin embargo el cliente es quien debe tener claro su requerimientos y nuevos procesos a implementar y los desarrolladores debern tratar de captar las verdaderas necesidades del usuario y filtrar sus comentarios ya que as se evitar realizar nuevos procesos de reingeniera que a mas de costosos muchas veces son procesos que desde un inicio pudieron evitarse doble trabajo. Tablespace Un espacio de tablas es una divisin lgica de la BD. Cada BD tiene al menos uno (SYSTEM). Un espacio de tablas puede pertenecer slo a una BD. Los espacios de tablas se utilizan para mantener juntos los datos de usuarios o de aplicaciones para facilitar su mantenimiento o mejorar las prestaciones del sistema. De esta manera, cuando se crea una tabla se debe indicar el espacio de tablas al que se destina. Por defecto se depositan en el espacio de tablas SYSTEM, que se crea por defecto. Este espacio de tablas es el que contiene el diccionario de datos, por lo que conviene reservarlo para el uso del servidor, y asignar las tablas de usuario a otro.

Se pueden ver los espacios de tablas definidos en nuestra BD con el comando SQL siguiente:

SQL> select * from user_tablespaces; Una base de datos se divide en unidades lgicas denominadas TABLESPACES. Un tablespace no es un fichero fsico en el disco, simplemente es el nombre que tiene un conjunto de propiedades de almacenamiento que se aplican a los objetos (tablas, secuencias) que se van a crear en la base de datos bajo el tablespace indicado (tablas, secuencias). Un objeto en base de datos debe estar almacenado obligatoriamente dentro de un tablespace. Las propiedades que se asocian a un tablespace son: Localizacin de los ficheros de datos. Especificacin de mximas cuotas de consumo de disco. Control de la disponibilidad de los datos (en lnea o fuera de lnea). Backup de datos. Cuando un objeto se crea dentro de un cierto tablespace, este objeto adquiere todas las propiedades antes descritas del tablespace utilizado. En este esquema podemos ver que, por ejemplo, la tabla ARTICULO se almacena dentro del tablespace A, y que por lo tanto tendr todas las propiedades del tablespace A que pueden ser:

Sus ficheros de datos estn en $ORACLE_HOME/datos/datos_tablespace_A Los objetos no pueden ocupar ms de 10Mb de espacio de base de datos. En cualquier momento se puede poner fuera de lnea todos los objeto de un cierto tablespace. Se pueden hacer copiar de seguridad slo de ciertos tablespaces.Si nos fijamos, se puede apreciar que es posible tener una tabla en un tablespace , y los ndices deesa tabla en otro. Esto es debido a que los ndices no son ms que objetos independientes dentro dela base de datos, como lo son las tablas. Y al ser objetos independientes, pueden ir en tablespaces independientes.

El tablespace SYSTEM es uno de los que se crear por defecto en todas las bases de datos Oracle. En l se almacenan todos los datos de sistema, el catlogo y todo el cdigo fuente y compilado de procedimientos PL/SQL. Tambin es posible utilizar el mismo tablespace para guardar datos de usuario.En el esquema tambin vemos que hay un tablespace Temporal (en gris oscuro). Este representa las propiedades que tendrn los objetos que la base de datos cree temporalmente para sus clculos internos (normalmente para ordenaciones y agrupaciones). Su creacin difiere en una de sus clusulas de creacin. El tablespace RO (en gris claro) difiere de los dems en que es de solo lectura (Read Only), y que por lo tanto todos los objetos en l contenidos pueden recibir rdenes de consulta de datos, pero no de modificacin de datos. Estos puede residir en soportes de slo lectura, como pueden ser CDROMs, DVDs, etc. Cuando se crea un tablespace, ste se crea de lectura/escritura. Despus se puede modificar para que sea de solo lectura. Un tablespace puede estar en lnea o fuera de ella (Online o OffLine), esto es que todos los objetos contenidos en l estn a disposicin de los usuarios o estn inhabilitados para restringir su uso.Cualquier objeto almacenado dentro de un tablespace no podr ser accedido si este est fuera de lnea.

La Reingeniera de Bases de Datos (DBRE)

Ing. Felipe de Jess Ramrez Turrubiartes Base de datos para aplicaciones
Carlos Garca Valdez