Ir al contenido

Usuario:Reingenieria de base de datos

De Wikipedia, la enciclopedia libre

REINGENIERÍA DE BDD


Lareingenierí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.