UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN

UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN Ingeniería de Reverso y Normalización de las base de datos de los sistemas en producción de FOGADE Por Leonardo Rada INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar al Título de Ingeniero en Computación Sartenejas, Abril de 2005

UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN ACTA FINAL DE CURSOS EN COOPERACIÓN Ingeniería de Reverso y Normalización de las base de datos de los sistemas en producción de FOGADE Presentado por: Leonardo Rada Este trabajo de cursos en cooperación ha sido aprobado en nombre de la Universidad Simón Bolívar por el siguiente jurado examinador: Prof. Anna Grimán Jurado Prof. Ana María Borges Tutor Académico Sartenejas, Abril de 2005

Ingeniería de Reverso y Normalización de las base de datos de los sistemas en producción de FOGADE Por Leonardo Rada RESUMEN Este proyecto de pasantía fue realizado en el Fondo de Garantía de Depósitos y de Protección Bancaria, FOGADE. El proyecto surge por la necesidad de obtener los modelos de datos conceptuales y lógicos de las bases de datos utilizadas por los sistemas en la organización, con la finalidad de realizar un proceso de normalización de las bases de datos, que permita corregir problemas en cuanto a la replicación y redundancia de datos, inconsistencias y anomalías que se presentan en la manipulación de los datos. Para cumplir con las necesidades planteadas se realizó un proceso de Ingeniería de Reverso a las bases de datos, obteniendo los esquemas lógicos, construyendo los diccionarios de datos y modelos conceptuales de las mismas. Luego se realizó el proceso de normalización, aplicando las formas normales de Codd, para obtener esquemas relacionales normalizados implementados en Microsoft SQL Server 2000. Adicionalmente se migraron datos desde una base de datos no normalizada hacia la nueva base de datos normalizada, para realizar pruebas en uno de los sistemas de la organización. Como resultado de este proyecto se obtuvieron los esquemas lógicos relacionales, los diccionarios de datos, los modelos conceptuales en ER y los esquemas relacionales normalizados para sesenta y cuatro sistemas en producción de FOGADE. Los nuevos esquemas relacionales normalizados permitirán tener bases de datos consistentes, que minimizan la redundancia de datos y garantizan la integridad de los mismos en una organización tan relevante como FOGADE. iii

DEDICATORIA A mis padres por su continuo apoyo y motivación. A mi familia por estar siempre presente en mi vida. A mis amigos de la universidad, por toda su ayuda y dedicación durante la carrera. En especial a Edgar Peña, Adriana Calderón, Alberto Croes, Juan López, Samuel Beltrán, Daniel Luna, Jenny Ng, Rosa Ramírez, y Ulidzan Jaspe. A los profesores de la universidad, que me brindaron los conocimientos necesarios y siempre me exigieron al máximo. A mi novia, Luvia Villarroel, quien se convirtió en fuente de mi motivación y felicidad, y quien me brinda todo su amor y apoyo aún en los momentos mas difíciles. iv

AGRADECIMIENTOS Muchas gracias a FOGADE por permitirme realizar mi proyecto de pasantía. Al Ingeniero Juan Barone, mi tutor industrial, por su continuo apoyo y ayuda brindada. A la profesora Ana María Borges, mi tutora académica, por toda su colaboración y orientación. A todas aquellas personas en FOGADE que me brindaron su ayuda y su amistad, y con las cuales compartí un agradable ambiente de trabajo. v

ÍNDICE GENERAL I. Introducción... 1 II. Entorno Empresarial... 3 II.1 Descripción de la empresa... 3 II.1.1 Historia de FOGADE 3 II.1.2 Misión y Visión... 4 II.1.2.1 Misión.4 II.1.2.2 Visión.4 II.2 Valores 4 II.3 Estructura Organizativa de FOGADE....5 II.3.1 Organigrama 6 III. Planteamiento del Problema....7 III.1 Antecedentes...7 III.2 Objetivo General.. 8 III.3 Objetivos Específicos..9 III.4 Alcance..9 IV. Marco Teórico..10 V. Metodología de desarrollo aplicada.....17 V.1 Ingeniería de Reverso...17 V.2 Normalización.....19 VI. Desarrollo del proyecto.. 21 VI.1 Ingeniería de Reverso...21 VI.2 Normalización.27 VII. Conclusiones y recomendaciones... 29 VII.1 Conclusiones...29 VII.2 Recomendaciones...30 VIII Referencias Bibliograficas... 31 IX Referencias Electrónicas...32 vi

ÍNDICE DE FIGURAS Figura 1. Organigrama estructural de FOGADE...6 Figura 2. Esquema relacional en Visio 2003... 22 Figura 3. Detalles de una relación de un esquema relacional en Visio 2003...22 Figura 4. Notación utilizada en los diagramas ER...25 Figura 5. Ejemplo de diagrama ER...26 vii

LISTA DE SÍMBOLOS Y ABREVIATURAS A continuación se presenta un listado de los símbolos y abreviaturas utilizadas en el presente informe de pasantía. 1FN 2FN 3FN ER Primera Forma Normal. Segunda Forma Normal. Tercera Forma Normal. Entidad Relación. viii

I. INTRODUCCIÓN Las bases de datos constituyen una pieza fundamental en los sistemas de información de cualquier organización. En ellas se almacenan grandes cantidades de datos que se utilizan como herramientas de apoyo a la gestión empresarial y que además permiten el funcionamiento de sistemas que soportan el trabajo en áreas vitales dentro de una organización. A pesar de la gran importancia de las bases de datos, son pocas las organizaciones que invierten suficientes recursos en el diseño, implementación y mantenimiento de sus bases de datos. Lo que generalmente trae como consecuencia problemas en las bases de datos, como diseños no adecuados, replicación, redundancia e inconsistencias en los datos. En FOGADE se presentan esos problemas en las bases de datos de los sesenta y cuatro sistemas que se encuentran en producción. La Gerencia de Informática conciente de esta realidad planteó la necesidad de realizar este proyecto de pasantía, con lo cual espera encontrar soluciones a los problemas presentes en las bases de datos. Para encontrar las soluciones deseadas, en este proyecto de pasantía se hace uso de un método para la Ingeniería de Reverso de las bases de datos existentes y se utilizan técnicas de normalización de esquemas de bases de datos relacionales, que garantizarán la consistencia e integridad de los datos y una disminución de los datos redundantes y replicados. La estructuración del presente informe se realizó por capítulos, los cuales describen los resultados de cada una de las etapas que se llevaron a cabo para la realización de este proyecto. Dichos capítulos son los siguientes: 1

Capítulo II - Entorno Empresarial. En este capítulo se describe el entorno empresarial donde se desarrolló este proyecto de pasantía. Se presenta la descripción de la empresa, su estructura organizativa y la ubicación del pasante dentro de la misma. Capítulo III Planteamiento del Problema. Se describen las razones por las cuales se emprendió este proyecto de pasantía y los objetivos del mismo. Capítulo IV - Marco Teórico. En este capítulo se presentan los fundamentos teóricos relacionados con este proyecto de pasantía. Capítulo V Metodología de desarrollo aplicada. Se especifica y se muestra la metodología de desarrollo utilizada durante el desarrollo de este proyecto. Capítulo VI - Desarrollo del Proyecto. Se presentan los resultados obtenidos durante el desarrollo de este proyecto de pasantía. Se describen cada una de las etapas aplicadas de la metodología, así como los problemas y dificultades encontradas y las soluciones aplicadas. Capítulo VII - Conclusiones y Recomendaciones. Se presentan las conclusiones y las recomendaciones obtenidas durante el desarrollo del proyecto de pasantía. En el siguiente capítulo se describe el entorno empresarial en el que se desarrolló este proyecto de pasantía. 2

II. ENTORNO EMPRESARIAL En este capítulo se describe el entorno empresarial donde se desarrolló este proyecto de pasantía. Para ello se dividió en tres secciones: descripción de la empresa, valores y estructura organizativa de la misma. II.1 Descripción de la empresa. II.1.1 Historia de FOGADE. Un fondo de garantías es una institución oficial legalmente facultada para proteger los depósitos realizados por los ciudadanos en moneda nacional en instituciones financieras contempladas por la normativa vigente en un país. [FOGADE 2005a]. El Fondo de Garantía de Depósitos y Protección Bancaria (FOGADE), fue creado por Decreto n.º 540 del 20 de marzo de 1985, publicado en la Gaceta Oficial de la República de Venezuela n.º 32.190 del 22 de marzo de ese mismo año, con el fin de garantizar los depósitos de los ahorristas en caso de intervención o liquidación de instituciones financieras y prestar apoyo económico a esas instituciones, ante problemas de liquidez o solvencia. [FOGADE 2005a] En Venezuela, la institución legalmente facultada par ejercer esta función es el Fondo de Garantía de Depósitos y Protección Bancaria, instituto autónomo con personalidad jurídica y patrimonio propio e independiente de la Hacienda Pública Nacional, adscrito al Ministerio de Finanzas a los efectos de la tutela administrativa. [FOGADE 2005a] La necesidad de crear una institución de esta naturaleza surgió a comienzos de la década de los ochenta, cuando el sistema financiero nacional se vio debilitado por una serie de factores tales como la fuga masiva de capitales, las fluctuaciones de las tasas de interés y el aceleramiento de los procesos inflacionarios nacionales e internacionales. [FOGADE 2005a] 3

En este clima nace FOGADE, respondiendo a la necesidad de restablecer la seguridad de los ahorristas y fomentar el ahorro, a través de un sistema de aseguramiento de depósitos en caso de intervención o liquidación de instituciones financieras. Asimismo, se determinó que este organismo brindase apoyo económico a las instituciones amparadas por las leyes vigentes, a fin de restablecer su normal funcionamiento, ante situaciones críticas como las vividas en los ochenta. [FOGADE 2005c]. II.1.2 Misión y Visión de FOGADE. II.1.2.1 Misión. Producir y gestionar conocimientos relacionados con aspectos emergentes de carácter financiero, económico, político y social que permitan tomar decisiones correctas en el manejo de la incertidumbre financiera, prevención de discontinuidades y protección de los ahorros; anticipar y aportar soluciones a los problemas relacionados con la Banca y las finanzas e incorporar a la comunidad organizada a los programas de formación técnico-financiera así como a los procesos de vigilancia y protección de los ahorros. [FOGADE 2005d]. II.1.2.2 Visión. Ser una comunidad de profesionales comprometidos con el interés nacional, altamente competitivos y capaces de proteger los depósitos de los ahorristas y minimizar los efectos de la volatilidad financiera. [FOGADE 2005d]. FOGADE se vinculará a otras instituciones y democratizará el conocimiento generado en su seno para educar a la comunidad, incentivar el ahorro, profundizar la corresponsabilidad social, contribuir con la estabilidad financiera, el progreso económico y la seguridad nacional. [FOGADE 2005d]. II.2. Valores. El trabajo desempeñado por FOGADE se rige por los siguientes valores: [FOGADE 2005e]. 4

Salvaguarda del futuro. Compromiso nacional. Satisfacción del cliente. Respeto por los trabajadores. Mejora continua. Respeto por el ambiente en cooperación con la comunidad organizada. Seguridad nacional. II.3. Estructura organizativa de FOGADE. Las máximas autoridades de FOGADE son la Asamblea General, la Junta Directiva, y la Presidencia. La Asamblea General es presidida por el Ministro de Finanzas, e incluye al Presidente del Banco Central de Venezuela, un Directivo Ejecutivo del Consejo Superior y el Presidente del Consejo Bancario Nacional. [FOGADE 2005b]. La Junta Directiva es el máximo órgano de dirección y administración del Fondo y está integrada por el Presidente y seis directores principales con sus respectivos suplentes. Tanto el Presidente como cuatro de los directores principales y sus respectivos suplentes, son designados por el Presidente de la República. Los otros dos directores principales y sus respectivos suplentes tendrán el carácter de directores laborales y serán designados de conformidad con lo establecido en el Título X de la Ley Orgánica del Trabajo. Uno de los cuatro directores principales designados por el Presidente de la República y su respectivo suplente, son escogidos de una terna que deberá presentar el Consejo Bancario Nacional. [FOGADE 2005f]. Los miembros de la Junta Directiva durarán cinco años en el ejercicio de sus funciones y podrán ser reelectos. Al Presidente de la Junta Directiva del Fondo corresponde, según la Ley General de Bancos, la administración diaria e inmediata de los negocios de la institución. Por su parte, los empleados del Fondo son funcionarios públicos, regidos por la Ley de Carrera Administrativa. [FOGADE 2005f]. 5

La gerencia de informática es una unidad asesora adscrita a la presidencia del Fondo, cuyo objetivo es brindar asesoría a todas las unidades del fondo en materia de recursos de información. Entre sus principales funciones se tiene: el diseño, desarrollo, implementación y mantenimiento de los sistemas requeridos por las distintas unidades del fondo, así como el soporte técnico requerido por los usuarios de los mismos. II.3.1 Organigrama. En la figura 1 se presenta el organigrama estructural de FOGADE, donde se resalta en azul la Gerencia de Informática, unidad en la cual se efectuó este proyecto de pasantía. FIGURA 1. - ORGANIGRAMA ESTRUCTURAL DE FOGADE En el siguiente capitulo se describen los problemas que se presentan en fogade por los cuales se emprendió este proyecto de pasantía, se plantean los objetivos y el alcance del mismo. 6

III. PLANTEAMIENTO DEL PROBLEMA El objetivo principal de este capítulo es la descripción de la situación de FOGADE, las razones por las cuales se emprendió este proyecto de pasantía, los objetivos y el alcance del mismo. III.1. Antecedentes. FOGADE no dispone de modelos de datos conceptuales ni lógicos de las bases de datos utilizadas por los sistemas en producción de la organización; los sistemas en producción son aquellos que se encuentran en funcionamiento y al servicio de los usuarios. En total existen sesenta y cuatro sistemas en producción, desarrollados en Microsoft Visual Basic y que utilizan como manejadores de bases de datos Microsoft Access y dbase V. En la organización se presentan problemas en cuanto a la manipulación de los datos, relacionados con la replicación y redundancia de datos entre las diferentes base de datos de los sistemas. Estos problemas se presentan por la inexistencia de una metodología de desarrollo y la carencia de cumplimento de estándares para el desarrollo de sistemas, así como la falta de trabajo en equipo. Al no existir una metodología para el desarrollo de sistemas, los analistas sólo se enfocan en la implementación, sin realizar documentación alguna, por lo cual no se dispone ningún tipo de documentos ni modelos de datos sobre los sistemas. Existen ocho analistas encargados del desarrollo y mantenimiento de los sistemas; sin embargo, cada analista tiene asignado un conjunto de sistemas sobre los cuales trabaja y es responsable. Muchos de los sistemas en producción están relacionados entre sí, a nivel de los datos que requieren para funcionar; sin embargo, debido a la falta de una metodología de desarrollo y a la carencia de trabajo en equipo, cuando un sistema requería datos que se almacenan en las bases de datos de otro sistema, los datos eran replicados en la base de datos del nuevo sistema. 7

Entre los problemas encontramos gran cantidad de tablas replicadas entre diferentes sistemas, lo que trae como consecuencia graves problemas para la actualización y mantenimiento de los datos, ya que, cuando se realiza una actualización a nivel de una tabla replicada en un sistema fuente, los cambios deben actualizarse también en las base de datos de todos los sistemas donde se encuentra replicada la tabla. Cómo dichas actualizaciones no son automáticas, se pueden encontrar inconsistencias entre las tablas y datos replicados entre diferentes sistemas. Las bases de datos también presentan una serie de problemas asociados al modelo relacional o esquema lógico de las bases de datos, entre dichos problemas tenemos la utilización de bases de datos relacionales como repositorios planos de datos, es decir, sin la presencia de relaciones entre los datos, y la inexistencia de claves primarias y foráneas, lo que elimina cualquier garantía de consistencia en los datos de los sistemas. Las relaciones entre los datos son ineficazmente manejadas en la capa de aplicación de los sistemas, y no en las bases de datos. Otros problemas se presentan en cuanto a atributos nunca utilizados y mal uso de los tipos de datos en las bases de datos. III.2. Objetivo General. Obtener mediante ingeniería de reverso los modelos de datos a nivel conceptual y lógico presentes en las base de datos de la organización, con el fin de realizar un estudio de dichos modelos y proponer soluciones que permitan eliminar la replicación y redundancia de datos, inconsistencias y anomalías que se presentan en la manipulación de los datos, aplicando las formas normales de Codd y buscando la mayor integración posible a nivel de base de datos. III.3. Objetivos Específicos. III.3.1. Obtener mediante ingeniería de reverso los modelos de datos lógico con su diccionario de datos, para las base de datos existentes y utilizadas por los sesenta y cuatro sistemas en producción de la organización. 8

III.3.2. Elaborar modelos conceptuales utilizando el modelo Entidad Relación (ER) con sus respectivos diccionarios de datos, a partir de los modelos de datos lógicos obtenidos mediante ingeniería de reverso. III.3.3. Elaborar modelos lógicos relacionales, que cumplan con el nivel de normalización más adecuado en cada caso. Alcanzando como máximo el nivel tres de normalización o Tercera Forma Normal (3FN). Los esquemas relacionales normalizados serán implementados en el manejador de bases de datos Microsoft SQL Server 2000. III.3.4. Realizar pruebas sobre al menos uno de los sistemas más críticos de la organización, con la finalidad de evaluar su funcionamiento sobre la base de datos normalizada. III.4. Alcance. El alcance del proyecto viene dado por el cumplimiento de los objetivos específicos propuestos. Sin embargo, se pretende colaborar y brindar todo el apoyo posible durante la ejecución del proyecto de pasantía. Luego de haber expuesto el problema, en el próximo capitulo se presenta la base teórica que sustenta el desarrollo de este proyecto de pasantía. 9

IV. MARCO TEÓRICO En este capítulo se presentan los conceptos básicos que se manejan en este informe de pasantía. Se pretende facilitar la lectura y entendimiento de los aspectos importantes que se abordan en el mismo. Se comenzará introduciendo los conceptos de bases de datos, el proceso de diseño de bases de datos, luego se explicará brevemente el modelo conceptual Entidad-Relación (ER) y el modelo relacional asociado a una base de datos, presentando una introducción a la normalización de bases de datos y las formas normales de Codd. Bases de Datos. El término base de datos es muy utilizado en la actualidad; sin embargo, es pertinente establecer una definición concreta de lo que se considera una base de datos. Para Elmasri y Navathe (1997) Una base de datos es un conjunto de datos relacionados entre sí. Por datos entendemos hechos conocidos que pueden registrarse y que tienen un significado implícito. Por ejemplo, consideremos los nombres, números telefónicos y direcciones de personas que conocemos. En otras palabras, una base de datos tiene una fuente de la cual se derivan los datos, cierto grado de interacción con los conocimientos del mundo real y un público que está activamente interesado en el contenido de la base de datos [Elmasri/Navathe, 1997]. Resulta muy común confundir el término base de datos con los sistemas de gestión de base datos (DataBase Management System: DBMS), también conocidos como manejadores de base de datos, que son el conjunto de programas que permiten crear y mantener bases de datos, como por ejemplo Microsoft SQL Server 2000 y Oracle 9i. 10

Diseño de bases de datos. El proceso de diseño de bases de datos consta de cuatro pasos fundamentales. El primer paso es la recolección y análisis de requerimientos, durante la cual los diseñadores entrevistan a los futuros usuarios de la base de datos para entender y documentar sus requerimientos de información. Una vez recabados y analizados los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel. El tercer paso consiste en el diseño lógico de la base de datos, y su resultado es un esquema de base de datos especificado en el modelo de datos de implementación del manejador de base de datos. El cuarto y último paso es el diseño físico de la base de datos, durante el cual se especifican las estructuras de almacenamiento internas y la organización de los archivos de la base de datos. [Elmasri/Navathe, 1997]. Modelo de datos conceptual Entidad-Relación. El modelo Entidad-Relación (ER), es un modelo de datos conceptual de alto nivel muy utilizado en la actualidad. Los modelos ER nos permiten el diseño de bases de datos en forma gráfica, incorporando información relativa a los datos y la relación existente entre ellos, para poder así plasmar una visión del mundo real sobre un soporte informático. [BCN 1992]. Las características fundamentales de los modelos ER son: Reflejan tan sólo la existencia de los datos sin expresar lo que se hace con ellos. Son independientes de las bases de datos y de los sistemas de operación. Incluyen todos los datos que se estudian sin tener en cuenta las aplicaciones que se van a tratar. En el modelo ER las entidades se representan como rectángulos, los atributos como elipses y las relaciones como rombos. Una entidad es una cosa del mundo real con existencia independiente. Una entidad puede ser un objeto con existencia física, como una persona o una casa, o un 11

objeto con existencia conceptual, como una compañía o un puesto de trabajo. [BCN 1992]. Las entidades poseen características o atributos. Los atributos son aquellas propiedades específicas que describen una entidad, como por ejemplo el nombre y la edad de una persona. Cada entidad debe poseer un atributo o conjunto de atributos que las identifican unívocamente. [BCN 1992]. Una relación es una asociación entre entidades. Por ejemplo, un Empleado Trabaja en un Departamento. Un dominio es el conjunto de valores que puede tomar cada uno de los atributos. Una entidad débil es aquella que no posee una clave propia y se identifican por su relación con otras entidades. Las relaciones pueden ser binarias, cuando asocian a dos entidades, o enarias cuando relacionan n entidades. [Gio Wiederhold 1983]. Una clave candidata es un atributo o conjunto de atributos que pueden distinguir de forma unívoca una instancia de una entidad. Puede haber varias claves candidatas para distinguir una misma entidad. Se elegirá como clave candidata aquel atributo que posea un dominio en el que se tenga valores únicos. Si esto no es posible, entonces se usa como clave candidata la combinación de varios atributos, de manera que esta combinación sí sea única. [Elmasri/Navathe, 1997]. Una clave principal es aquella de las claves candidatas que es designada para distinguir de forma unívoca cada instancia de una entidad. Una clave foránea es un atributo que es clave principal en otra entidad. [Elmasri/Navathe, 1997] 12

Las relaciones entre dos entidades cualesquiera pueden ser de tres tipos: uno-auno, uno-a-muchos y muchos-a-muchos. [Gio Wiederhold 1983]. Relaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad X se puede asociar con tan sólo un ejemplar de la entidad Y, entonces decimos que la asociación es uno-a-uno. [Gio Wiederhold 1983]. Relaciones uno-a-muchos: Es el tipo de asociación más común, donde un solo ejemplar de una entidad se puede asociar con cero, uno o muchos ejemplares de otra entidad. Por ejemplo, un empleado puede tener varios números de teléfono. [Gio Wiederhold 1983]. Relaciones muchos-a-muchos: Ocurre cuando cualquier ejemplar de la entidad X se puede asociar con cero, uno o muchos ejemplares de la entidad Y. Por ejemplo, los clientes compran en muchas tiendas, una tienda tiene muchos clientes. [Gio Wiederhold 1983]. Modelo Relacional. El modelo relacional fue propuesto originariamente por E.F. Codd en 1970. El modelo relacional representa la base de datos como una colección de relaciones, también llamado esquema relacional. En términos informales, cada relación semeja una tabla, donde cada fila de la tabla representa una colección de valores de datos relacionados entre sí. Dichos valores se pueden interpretar como hechos que describen una entidad o una relación entre entidades. [Elmasri/Navathe, 1997]. En la terminología del esquema relacional, una fila se denomina tupla, una cabecera de columna es un atributo y la tabla es una relación. Por ejemplo tenemos la relación Empleado(Cédula, Nombre, Teléfono), donde Cédula, Nombre y Teléfono son atributos de la relación Empleado. Una tupla de la relación Empleado sería (123456, Juan, 02123334455). En el esquema relacional también se manejan los conceptos de clave primaria y claves foráneas. Una clave primaria es el atributo o conjunto de 13

atributos que identifica unívocamente cada tupla de una tabla. Una clave foránea representa una asociación entre dos tablas. [Elmasri/Navathe, 1997]. Existen algoritmos y herramientas CASE que permiten convertir un esquema ER a un modelo relacional e incluso obtener el modelo relacional expresado en el lenguaje de especificación de un manejador de base de datos específico [Elmasri/Navathe, 1997]. Normalización de bases de datos y formas normales de Codd. El proceso de normalización consiste en someter un esquema relacional a una serie de pruebas para certificar si pertenece o no a una cierta forma normal. En un principio Codd propuso tres formas normales, conocidas como la primera, segunda y tercera formas normales. Durante el proceso de normalización los esquemas relacionales insatisfactorios se descomponen repartiendo sus atributos entre esquemas relacionales más pequeños que poseen propiedades deseables. Unos de los objetivos principales del proceso de normalización es garantizar que no ocurran anomalías de actualización [Elmasri/Navathe, 1997]. Una anomalía de actualización que ocurre frecuentemente al traducir un modelo conceptual ER en un esquema relacional, se presenta cuando una entidad del modelo ER queda representada dentro de la relación que representa otra entidad del modelo ER. Por ejemplo, supongamos que en el modelo ER tenemos las entidades Empleado y Departamento, y que al traducir el modelo ER a un esquema relacional, dentro de la relación Empleado incluimos el departamento en el cual trabaja cada empleado, Empleado(Cédula, Nombre, NombreDepartamento). En dicho esquema relacional se puede perder la información de un Departamento si se eliminan todos los empleados que trabajan en ese Departamento, ya que, el NombreDepartamento se guarda en la relación Empleado y no de forma independiente. Otro problema como consecuencia de dicho esquema relacional consiste en la inserción de nuevos empleados, porque la información del Departamento al cual 14

pertenece el empleado se debe introducir por cada nuevo empleado, y basta con introducir un error en la información del Departamento para crear una inconsistencia en los datos. También se presenta un grave problema de redundancia de datos, porque la información de un departamento se encuentra repetida un número de veces igual al número de empleados tenga ese departamento. Para evitar éstos y otros problemas que se pueden presentar en los esquemas relacionales tenemos las formas normales: Primera Forma Normal (1FN): Establece que el valor de un atributo en una tupla debe ser un valor individual, y que los posibles valores de los atributos sólo pueden ser valores atómicos (simples e indivisibles). Por ejemplo el atributo Lugar de una relación en un esquema relacional, sólo podrá contener valores atómicos como Belén, Santiago o Higueras, y no podrá contener un conjunto de esos valores como (Belén, Santiago, Higueras) [Elmasri/Navathe, 1997]. Para entender la segunda forma normal debemos conocer primero los conceptos de dependencia funcional, atributos primos y no primos en un esquema relacional. Una dependencia funcional, denotada por X => Y, se establece entre dos conjuntos de atributos X y Y que son subconjuntos de una relación R. Se dice que existe una dependencia funcional de X a Y en un esquema relacional R si y sólo si, siempre que dos tuplas de R coincidan en su valor X, necesariamente deben coincidir en su valor Y. Esto significa que los valores del componente Y de una tupla en R dependen de los valores del componente X, o están determinados por ellos. Por ejemplo si tenemos la relación Empleado(Cédula, Nombre), existe una dependencia funcional Cédula => Nombre, ya que, el número de cédula de un empleado determina de manera única el nombre de ese empleado. Una dependencia funcional X =Y es total si la eliminación de cualquier atributo A de X hace que la dependencia deje de ser válida [Elmasri/Navathe, 1997]. Los atributos primos en una relación R de un esquema relacional son aquellos que forman parte de cualquier clave de R, y los atributos no primos son aquellos que no son miembros de ninguna clave candidata de R. [Elmasri/Navathe, 1997] 15

Segunda Forma Normal (2FN): Un esquema relacional R está en 2FN si todo atributo no primo A en R depende funcionalmente de manera total de la clave primaria de R, es decir, todos los atributos que no pertenecen a una clave en R, deben depender funcionalmente de la clave primaria de R [Elmasri/Navathe, 1997]. Tercera Forma Normal (3FN): La tercera forma normal se basa en el concepto de dependencia transitiva. Una dependencia funcional X => Y en un esquema relacional R es una dependencia transitiva si existe un conjunto de atributos Z que no sea un subconjunto de cualquier clave de R y se cumple tanto X => Z como Z => Y. Un esquema relacional R está en 3FN si todo atributo no primo de R es: dependiente funcionalmente de manera total de toda clave de R, y dependiente de manera no transitiva de toda clave de R [Elmasri/Navathe, 1997]. Luego de haber expuesto el problema, en el próximo capítulo se presentará la metodología de desarrollo aplicada durante la realización del proyecto. 16

V. METODOLOGÍA DE DESARROLLO APLICADA La finalidad de este capítulo es especificar y mostrar la metodología de desarrollo que se decidió utilizar para llevar a cabo este proyecto de pasantía. En primer lugar se explica la metodología aplicada para la Ingeniería de reverso de las base de datos y luego la metodología aplicada para la normalización e implementación de las mismas. V.1. Ingeniería de Reverso: La ingeniería de reverso para obtener los modelos relacionales y conceptuales en ER de las base de datos, se basó en los pasos números dos y tres para el diseño de bases de datos especificados por Elmasri y Navathe (1997). Sin embargo, dichos pasos se deben seguir en orden inverso, porque se dispone de las bases de datos ya implementadas, y se requiere obtener a partir de ellas el esquema relacional con un diccionario de datos y un modelo conceptual en ER que describa los datos. A partir de los esquemas relacionales, diccionarios de datos y esquemas conceptuales obtenidos mediante ingeniería de reverso, se procede a una reingeniería de las bases de datos, que consiste en la normalización de los esquemas relacionales y su implementación en el manejador Microsoft SQL Server 2000. El primer paso de la ingeniería de reverso consiste en obtener el esquema relacional de las base de datos, para ello se utilizó la herramienta Microsoft Visio 2003. Dicha herramienta posee la funcionalidad de obtener el esquema relacional de una base de datos, conectándose a la misma y extrayendo toda la información necesaria. El esquema relacional obtenido contiene todas las tablas, atributos, tipos de datos de los atributos, y las claves primarias y foráneas. A partir del esquema relacional obtenido se procede a elaborar un diccionario de datos, que debe contener descripciones detalladas de las tablas, los atributos y las relaciones. El segundo paso consiste en el análisis del esquema relacional para elaborar un modelo conceptual ER que describa los datos. Este paso es fundamental en el proceso de ingeniería de reverso, ya que, se debe realizar un análisis de cada tabla en el esquema relacional y determinar qué representación conceptual tiene. Una tabla en un 17

esquema relacional puede ser la representación de una entidad, o una relación en un modelo conceptual ER. Para determinar si una tabla representa una entidad o una relación debemos realizar una serie de pruebas que permitan determinar cada caso. En primer lugar debemos determinar si la tabla corresponde a una entidad solitaria, es decir, sin relaciones hacia otras entidades, esto significa que la tabla no posea claves foráneas a otras tablas en el esquema relacional, sin embargo, no se puede conocer hasta finalizar el análisis de todas las tablas una tabla corresponde a una entidad solitaria, ya que otra tabla puede tener una clave foránea hacia ella. Al finalizar este análisis para todas las tablas del esquema relacional, encontraremos aquellas entidades que en el modelo conceptual no poseen relaciones con otras entidades y que por lo tanto no representan una relación en el modelo conceptual. Luego debemos determinar si una tabla puede corresponder a una relación, al llegar a este punto sabemos que no corresponde a una entidad solitaria por la prueba anterior, y que la tabla posee al menos una clave foránea. Si los atributos que forman la clave primaria de la tabla componen a su vez más de una clave foránea, nos encontramos con que la tabla representa una relación en el modelo conceptual. En el caso de que los atributos que forman la clave primaria componen sólo una clave foránea nos encontramos con que la tabla puede representar una categorización en el modelo conceptual. La siguiente prueba será para determinar si la tabla representa una entidad que participa en relaciones 1-1 o 1-N. En este punto sabemos que debe participar en alguna relación de este tipo, porque no representa una entidad solitaria, ni una relación ni una categorización. Las claves foráneas de esta tabla representan una relación binaria, ya que, las relaciones binarias son las únicas que pueden representarse sin utilizar una tabla aparte, y por lo tanto las relaciones en las que puede participar deben ser de tipo 1-1 o 1-N. Si la tabla que se esta comprobando posee una clave foránea a otra tabla, los atributos que forman la clave foránea son únicos y la otra tabla también posee una clave foránea a ésta, la relación presente será 1-1 con mutua referencia. Si 18

la tabla sólo posee una clave foránea a otra tabla, los atributos que forman la clave foránea son únicos y la otra no posee clave foránea a ésta, nos encontramos con una relación 1-1 sin mutua referencia. En el caso en que los atributos que forman la clave foránea no están declarados como únicos, sería una relación 1-N. V.2. Normalización: El proceso de normalización consiste en analizar un esquema relacional, verificando si cumple las formas normales de Codd. Este proceso de normalización incluye un aspecto subjetivo, porque durante el análisis se debe decidir hasta que nivel de normalización se desea llevar el esquema relacional. No siempre un esquema relacional que cumpla la tercera forma normal nos garantizará que éste sea un buen diseño para la base de datos. En ocasiones por razones de rendimiento o complejidad, un esquema que cumpla la primera forma normal puede resultar mejor que uno que cumpla la tercera forma normal, y por lo tanto se debe tomar la decisión de hasta que nivel de normalización llevar un esquema relacional. El análisis y normalización de un esquema relacional es un proceso progresivo, ya que, se debe verificar en orden el cumplimiento de las formas normales, según el orden que indica el propio nombre de cada forma normal, primera forma normal, segunda forma normal y luego la tercera forma normal. Debido a la imposibilidad de asignar un conjunto de valores a un atributo en los manejadores de bases de datos relacionales actuales, tenemos que cualquier esquema relacional implementado cumple con 1FN. Por lo tanto el proceso de normalización consistirá en verificar si un esquema relacional cumple con la segunda y tercera formas normales. Si un esquema relacional no cumple con la 2FN, dicho esquema debe ser modificado para que cumpla con 2FN. La modificación consiste en crear nuevas relaciones que cumplan con 2FN, donde los atributos no primos estén asociados sólo a la parte de la clave primaria de la que dependen funcionalmente de manera total. 19

En el caso de considerarse necesario, se verifica el cumplimiento de la tercera forma normal, y si el esquema no cumple con 3FN, se descomponen las relaciones que no están en 3FN, por relaciones que cumplan 3FN. Luego de obtener los esquemas relacionales normalizados, se implementan en Microsoft SQL Server 2000, para posteriormente realizar pruebas sobre los sistemas y las nuevas bases de datos. Para ello es necesario migrar datos desde las bases de datos no normalizadas, a las nuevas implementadas en SQL Server 2000. SQL Server 2000 provee una útil herramienta para la migración de datos, llamada Data Transformation Services (Servicios de transformación de datos) que incluye la importación de datos desde base de datos en Access y dbase. Una vez migrados los datos se pueden realizar pruebas ejecutando conexiones y consultas a la base de datos. Una vez descrita la metodología y sus etapas, se procederá a explicar como se realizaron cada una de las etapas de la metodología para poder cumplir con los objetivos generales y específicos de este proyecto de pasantía. 20

VI. DESARROLLO DEL PROYECTO En este capitulo se presentan los resultados obtenidos durante el desarrollo de este proyecto de pasantía. Se describen cada una de las etapas aplicadas de la metodología, así como, los problemas y dificultades encontradas, y las soluciones aplicadas. VI.1. Ingeniería de Reverso: Esta etapa del proyecto resultó ser la más complicada y compleja debido a la una gran cantidad de problemas que se presentaron. La primera dificultad encontrada fue el número de bases de datos que manejan los sistemas en producción de FOGADE. A pesar de ser 64 sistemas, se manejan 354 bases de datos, de las cuáles 320 se encuentran implementadas en Microsoft Access, y 34 en dbase V. El número de bases de datos es tan elevado, porque los históricos de los sistemas se guardan en bases de datos separadas, por ejemplo, se posee una base de datos para el año 1997, otra para 1998, etc. Y al estudiar cada una de las bases de datos para cada año, se encontraron diferencias estructurales entre ellas, por lo que el esquema relacional obtenido con Visio para el año 1997 podía ser diferente al esquema relacional obtenido para el año 1998. Las diferencias entres las bases de datos históricas son consecuencia de cambios realizados a los sistemas, debido a cambios en los requerimientos por parte de los usuarios. Por dichas diferencias presentes en las bases de datos históricas de un mismo sistema se debían obtener los esquemas relacionales para todas las bases de datos. Una dificultad inherente a la herramienta utilizada para obtener los esquemas relacionales, Microsoft Visio 2003, es que en los esquemas obtenidos, todas las tablas quedan desordenadas en la hoja de trabajo, y se deben ordenar a mano para que el esquema sea entendible, lo cual en ciertas ocasiones resulta una tarea larga y tediosa al tener que ordenar más de 30 tablas en un esquema. 21

A continuación se presenta un ejemplo de un esquema relacional en Microsoft Visio 2003: Figura 2. Esquema relacional en Visio 2003. En el esquema relacional de la Figura 2, observamos dos tablas, una llamada Empleado y otra llamada Departamento. La tabla Empleado posee cuatro atributos, de los cuales el atributo Cédula es la clave primaria y se denota con el PK de la columna izquierda, además del subrayado del atributo. En la columna a la derecha de los atributos encontramos el tipo de dato para cada atributo. Podemos observar que el atributo Nombres se escribe en negrita, esto significa que dicho atributo no puede tomar valores nulos. El FK1 a la izquierda del atributo NúmeroDep especifica que dicho atributo es una clave foránea hacia otra tabla, lo cual representa una relación entre las tablas, dicha relación se observa con la flecha guiada que parte de la tabla Empleado a la tabla Departamento. Al hacer clic en la flecha guiada se muestran los atributos relacionados, como se aprecia en la Figura 3: 22

Figura 3. - Detalles de una relación de un esquema relacional en Visio 2003. Luego de obtener y ordenar los esquemas relacionales para todas las bases de datos, se presentaron las mayores dificultades. En primer lugar la gran mayoría de las bases de datos no cumplían el modelo relacional, solo eran repositorios planos de datos, es decir, se guardaban los datos sin ningún tipo de relaciones, y dichas relaciones se manejan en la capa de aplicación de los sistemas. La gran mayoría de las tablas no tenían definidas claves primarias ni foráneas. Por ésta razón los esquemas relacionales obtenidos no proporcionaban suficiente información para generar los modelos conceptuales de las bases de datos. Para afrontar esta situación, la elaboración de los diccionarios de datos para los esquemas relacionales adquirió una nueva dimensión. En ellos no sólo se iban a plasmar las descripciones de las tablas, atributos y relaciones del esquema. Los diccionarios de datos debían realizarse con el análisis de los datos en las bases de datos, para incluir toda la información que los esquemas relacionales no proporcionaban. Se debían determinar los atributos que nunca eran utilizados, atributos con tipos de datos erróneos, se debían encontrar las relaciones entre las tablas del esquema que no estaban definidas mediante claves foráneas. La elaboración de los diccionarios de datos se convirtió entonces en un análisis intensivo de los datos almacenados en todas las bases de datos. 23

Para almacenar toda la información encontrada mediante el análisis de datos en los diccionarios, éstos fueron elaborados en Microsoft Word, y se utilizó un código de colores para ciertas propiedades de los atributos y tablas, y se agregaron datos adicionales a las descripciones de los atributos. A continuación tenemos el código de colores utilizado: Atributo o Tabla: un atributo o tabla se resaltaba en amarillo cuando faltaba especificar su descripción. Atributo o Tabla: un atributo o tabla se resaltaba en rojo cuando no se almacenaban datos en él. Era un atributo o una tabla que no contenía ningún dato guardado. Atributo o Tabla: un atributo o tabla se resaltaba en azul cuando se almacenaban datos en él, a diferencia de otra versión del sistema en el cual no se le almacenaban datos. Esto ayudó a establecer las diferencias entre las diferentes versiones de las bases de datos de un mismo sistema. Atributo o Tabla: un atributo o tabla se resaltaba en verde cuando se encontraba en una versión de una base de datos, a diferencia de otra versión en la cual no estaba presente. Esto también contribuyó a establecer las diferencias entre las diferentes versiones de las bases de datos de un mismo sistema. Los datos adicionales que se agregaron a las descripciones de los atributos servían para señalar las relaciones encontradas durante el análisis de los datos. Se utilizó la siguiente notación: Atributo: descripción. Tipo de dato. [PK]. [FK]. [Asociado a nombre_atributo en nombre_tabla]. Donde la descripción es una breve explicación del dato almacenado en el atributo. El tipo de dato es el tipo de datos especificado en el manejador de Base de 24

Datos para ese atributo, por ejemplo Varchar(10). PK es opcional e indica si el atributo forma parte de la clave primaria de la tabla. FK es opcional e indica si el atributo forma parte de una clave foránea hacia otra tabla. Asociado a nombre_atributo en nombre_tabla es opcional e indica si durante el análisis de los datos se encontró que el atributo es una clave foránea hacia el atributo con nombre nombre_atributo en otra tabla con nombre nombre_tabla y el atributo no está especificado en el esquema relacional como clave foránea. Es importante destacar que la elaboración de los diccionarios de datos se realizó en dos fases, debido al poco tiempo con el cual podían colaborar los analistas encargados de los sistemas. En una primera fase se construyeron los 354 diccionarios de datos correspondientes a cada uno de los esquemas relacionales, y durante dicha construcción se analizaron los datos almacenados, en la búsqueda de relaciones no especificadas, descripciones de tablas y atributos, y las propiedades de los atributos. La segunda fase consistió en revisar cada diccionario junto con el analista encargado del sistema correspondiente, para agregar y corregir descripciones, relaciones y propiedades de atributos, no especificadas durante la fase de análisis. Una vez culminados los diccionarios, se procedió a elaborar los modelos conceptuales en ER para cada sistema, a partir de los esquemas relacionales y la información adicional almacenada en los respectivos diccionarios. En este caso resultó necesario elaborar un solo diagrama ER por cada sistema, porque a nivel conceptual, las entidades y relaciones de los sistemas eran las mismas. Debido a la gran cantidad de atributos, éstos no se representaron en los diagramas ER. La notación utilizada en los diagramas ER se presentan en la Figura 4: 25

Figura 4. Notación utilizada en los diagramas ER. El ejemplo de esquema relacional de la Figura 2, se representa conceptualmente en el diagrama ER de la Figura 5. Donde la relación existente entre un Empleado y un Departamento, es el concepto de Trabajar, un empleado trabaja en un departamento. La cardinalidad nos especifica aún mas la relación, se utiliza la notación (min, max) donde min es el mínimo número de veces que una instancia de la entidad participa en la relación, y max es el máximo número de veces que una instancia de la entidad participa la relación. En la Figura 5, para el empleado su cardinalidad o participación en la relación trabaja es (0, 1), lo que significa que un empleado puede no trabajar para algún departamento y puede trabajar como máximo para un solo departamento; para los departamentos la cardinalidad es (0, n), lo que significa que un departamento puede no poseer empleados que trabajen en él, y como máximo puede tener n números de empleados que trabajen en él. 26

Figura 5. Ejemplo de diagrama ER. Durante la elaboración de los diagramas ER se encontraron otra serie de irregularidades importantes en las bases de datos. Entre ellas y con mucha relevancia tenemos la concatenación de atributos para establecer relaciones, el siguiente ejemplo ilustrarla ésta situación: Se tienen tres entidades, Empleado, Departamento y Proyecto. Se desea representar la relación de los empleados con el departamento al cual pertenecen, y la relación entre los empleados y los proyectos en los cuales trabajan. Supongamos que cada Departamento posee un atributo que es clave primaria llamado ClaveDepartamento, y que cada Proyecto posee como clave primaria un atributo llamado ClaveProyecto. Para establecer las relaciones entre los empleados y su departamento, y los empleados con sus proyectos, se definió una clave para la entidad Empleado que es la concatenación de las claves ClaveDepartamento y ClaveProyecto, por ejemplo, si ClaveDepartamento es 002, y ClaveProyecto es 401, la clave del empleado sería 002401. La concatenación y manejo de esas extrañas relaciones se hacen en la capa de aplicación de los sistemas, pero no pueden representarse en un modelo ER ni en un esquema relacional, por lo cual debían ser corregidos. Otra irregularidad se refiere a las entidades débiles, muchas de las entidades débiles presentes en los diagramas ER, no eran en realidad entidades débiles y se apreciaban como tales por la mala implementación presente en las bases de datos. 27

La utilización de Microsoft Access y dbase V como manejadores de bases de datos contribuyeron a la gran cantidad de problemas encontrados en las bases de datos. En ambos manejadores se pueden crear esquemas sin claves primarias y sin restricciones de unicidad, por lo cual no existe garantía de integridad en los datos guardados. V.2. Normalización: En la fase de normalización las dificultades encontradas fueron las inherentes a la subjetividad del proceso de normalización, en cuanto al nivel de normalización a alcanzar. Sin embargo debido a la simplicidad de los esquemas relacionales, para muchos de los sistemas bastó con garantizar el primer nivel de forma normal, y en algunos esquemas específicos se llegó a la segunda forma normal. No se consideró necesario alcanzar el tercer nivel de normalización para ninguno de los sistemas. Cuando un esquema relacional no cumple con la 2FN, dicho esquema se modifica creando nuevas relaciones que cumplan con 2FN, donde los atributos no primos estén asociados sólo a la parte de la clave primaria de la que dependen funcionalmente de manera total. El proceso de normalización es mecánico, es decir, se siguen los mismos pasos de análisis y normalización para cada uno de los esquemas relacionales sometidos a verificación. Por ello esta fase consistió en la verificación y modificación de los esquemas relacionales, implementándolos luego en Microsoft SQL Server 2000. Luego se procedió a realizar pruebas sobre la base de datos normalizada del sistema de Inmuebles, en Microsoft SQL Server 2000. Para realizar la prueba en primer lugar se debían migrar los datos del esquema relacional viejo, al nuevo esquema normalizado. Utilizando la herramienta Data Transformation Services para la migración de datos de Microsoft SQL Server 2000, se encontraron errores en la integridad de los datos, tuplas con claves primarias repetidas, valores nulos para atributos requeridos, claves foráneas hacia tuplas inexistentes. 28