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

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
Primera Forma Normal.
2FN
Segunda Forma Normal.
3FN
Tercera Forma Normal.
ER
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
Ante esta situación la migración de los datos requiere de un minucioso y lento
proceso de validación para poder migrar toda la información a los nuevos esquemas
relacionales, por lo cual no se pudo cumplir con el objetivo de realizar pruebas con al
menos uno de los sistemas más críticos y evaluar su funcionamiento sobre la base de
datos normalizada.
Resulta importante señalar que los esquemas relacionales, diccionarios de datos,
los modelos conceptuales en ER, y los esquemas relacionales normalizados no se
presentan en este informe de pasantía, porque se consideran de carácter privado para
la organización y su exposición en este informe no fue autorizada.
29
VII. CONCLUSIONES Y RECOMENDACIONES
En este capitulo se presentan las conclusiones obtenidas luego del trabajo
realizado durante la ejecución de este proyecto de pasantía y luego se exponen una
serie de recomendaciones y que se considera pueden ser tomadas en cuenta por la
organización en el futuro.
VII.1. Conclusiones:
Encontrar soluciones a un conjunto de problemas presentes en las bases de
datos de FOGADE, como diseños inválidos, replicación y redundancia de datos e
inconsistencias en los datos, motivaron la realización de este proyecto de pasantía.
Para solucionar dichos problemas se utilizó una metodología de Ingeniería de Reverso,
con la finalidad de obtener los esquemas relacionales implementados en las bases de
datos, a partir de los cuales se elaboraron diccionarios de datos que permitieron realizar
los modelos conceptuales correspondientes a las bases de datos. Luego se aplicaron
las formas Normales de Codd hasta la tercera forma normal, en la elaboración de
nuevos esquemas relacionales implementados en Microsoft SQL Server 2000, que
garantizan un mejor diseño para las bases de datos, evitando inconsistencias en los
datos, así como la eliminación de muchos de los problemas con la replicación y
redundancia de información.
Entre las mayores dificultades encontradas tenemos la ausencia total de
documentación con respecto a las bases de datos utilizadas por los sistemas. Para
generar dicha documentación necesaria en el proceso de normalización, se realizó
Ingeniería de reverso sobre las bases de datos, encontrando en muchos casos la
ausencia total de un modelo relacional implementado en las bases de datos, por lo cual
en muchos casos no habían definiciones de claves primarias, claves foráneas, ni
restricciones de no nulidad sobre atributos. Por estas razones la elaboración de los
diccionarios de datos y modelos conceptuales, se convirtió en un análisis exhaustivo de
una gran cantidad de datos.
La inconsistencia de los datos actualmente almacenados en las bases de datos,
30
hace de la migración de información hacia las nuevas bases de datos normalizadas,
una tarea ardua y tediosa, que escapa del alcance de este proyecto.
Resulta importante concluir que la falta de personal encargado de las actividades
de diseño, implementación y mantenimiento de las bases de datos en la organización, y
la ausencia de ejecución de esas actividades por parte de los analistas encargados de
los sistemas a lo largo de varios años, constituyeron errores graves dentro de la
organización, llegando al punto en que la consistencia, confiabilidad e integridad de la
información almacenada en sus bases de datos no está garantizada. Como resultado
ahora es necesaria la inversión de una gran cantidad de tiempo y dinero, en la
migración de la información hacia bases de datos normalizadas, y la modificación de
todos los sistemas actualmente en producción para adaptarlos a los nuevos esquemas
relacionales, lo cual representa un trabajo que consumirá mucho tiempo, pues en
ocasiones hasta las relaciones entre las tablas de un esquema relacional se manejan
de forma manual en la capa de aplicación de los sistemas.
VII.2. Recomendaciones:
La más importante recomendación como resultado de este proyecto de pasantía,
es que la organización enfoque recursos hacia el diseño, implementación y
mantenimiento de las bases de datos, tanto para los sistemas en producción actuales,
como para los nuevos desarrollos. Esto debe convertirse en una prioridad, ya que, si los
datos almacenados pueden ser inconsistentes y no confiables, la fiabilidad de los
sistemas y el funcionamiento de toda la organización pueden resultar afectados.
Igualmente debe encargarse personal especializado para el proceso de migración de
datos hacia los nuevos esquemas relacionales normalizados.
Es importante que en futuros desarrollos los analistas tomen en cuenta las
restricciones y facilidades inherentes a las bases de datos relacionales y a su
implementación tales como:
31
•
Se deben elaborar modelos conceptuales ER antes de implementar las
bases de datos en los manejadores.
•
Los modelos conceptuales ER se deben traducir en esquemas
relacionales y se deben crear diccionarios de datos donde se describan
las tablas, sus atributos y las relaciones existentes.
•
Toda tabla de la base de datos debe poseer una clave primaria, para
prevenir inconsistencias y errores en la manipulación de los datos.
•
Las relaciones se deben establecer mediante el uso de claves foráneas en
la base de datos. No se deben manejar las relaciones entre los datos en la
capa de aplicación.
•
En la capa de aplicación se debe hacer uso del lenguaje de consulta de
bases de datos SQL de forma mas completa. El lenguaje SQL permite
hacer un uso eficiente de las bases de datos implementadas en un
manejador de base de datos relacionales, liberando la capa de aplicación
de cargas de trabajo que puede realizar de manera más eficiente, segura
y confiable por el manejador de base de datos mediante consultas SQL.
32
VIII. REFERENCIAS BIBLIOGRÁFICAS
[BCN, 1992] Batini C., Ceri, S. y Navathe, S. “Conceptual Database Design. An entity
relationship approach.” Benjammin Cummings, 1992.
[Elmasri/Navathe, 1997] Elmasri, Ramez, Navathe Shamkant B., “Sistemas de Bases de
Datos. Conceptos Fundamentales”, Segunda Edición, Pearson Education, México,
1997.
[Gio Wiederhold, 1983] Gio Wiederhold: “Database Design, Second Edition”. McGrawHill. 1983.
33
IX. REFERENCIAS ELECTRÓNICAS
[FOGADE 2005a] FOGADE, “Información institucional”.
http://www.fogade.gov.ve/informacion.html. Marzo 2005
[FOGADE 2005b] FOGADE, “Personal Ejecutivo”.
http://www.fogade.gov.ve/personalejecutivo.html. Marzo 2005
[FOGADE 2005c] FOGADE, “Preguntas Frecuentes”.
http://www.fogade.gov.ve/preguntas.html. Marzo 2005
[FOGADE 2005d] FOGADE, “Misión y Visión”.
http://www.wlab.com.ve/nuestra_institucion/misionvision.php. Marzo 2005
[FOGADE 2005e] FOGADE, “Valores y Principios”.
http://www.wlab.com.ve/nuestra_institucion/valoresyprincipios.php. Marzo 2005
[FOGADE 2005f] FOGADE, “Estructura Organizativa”.
http://www.wlab.com.ve/nuestra_institucion/est_organizativa.php. Marzo 2005
34