CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

MAESTRIA EN CIENCIAS DE LA COMPUTACION

cenidet GENERADOR DEL ESQUEMA DE UNA BASE DE

DATOS A PARTIR DE Los REQUERIMIENTOS DEL SISTEMA DE INFORMACION

(GERSI)

T E S I S OUE PARA OBTENER EL GRADO DE CENTRO DE INFORMAC~ON

MAESTRO EN CIENCIAS DE LA C E N I D E T C O M P U T A C I O N

P R E S E N T A :

M I G U E L P E R E Z R A M I R E Z

DIRECTOR DE TESIS: DR. RODOLFO PMOS RANGEL

CUERNAVACA. MOR. MARZO DE 1996

S(][' SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

Centro Nacional de Investigación y Desarrollo Tecnológico ACADEMIA DE LA MAESTRIA EN CIENCIAS

DE LA COMPUTACION

Cuernavaca Mor., a 7 de diciembre de 1995

Dr. Juan Manuel Ricaño Castillo Director del CENIDET P r e s e n t e

At'n: Dr. José Ruíz Ascencio Jefe del, Dpto. de Computación

Nos es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de maestría de este centro, y después de haber sometido a revisión académica el trabajo de tesis titulado:

"Generador del Esquema de una Base de Datos a Partir de los Requerimientos del Sistema de Información"

que presenta el L.C. MIGUEL PEREZ RAWREZ, y habiendo cumplido con todas las correcciones que le fueron indicadas, estamos de acuerdo con su contenido, por lo que aprobamos que el trabajo sea presentado en examen oral.

Sin más por el momento, quedamos de usted.

A t e n t a m e n t e

.!.,-"<,", '.í : . , . . .

..>,.< .. r , .!,',, . . . '.

Director de Tesis C. C.^ M.C. Joaqufn Perez Ortega

Presidente de la Academia

Inierior Internado Pulniira SIN C.P. 62490 Apnrtado Push1 5-164, C.P. 62050, Cuernavncn Mor., MQicci cenidetl

Tek. (73) 18-77-41 y 12-76-13, Fax. 12-24-34

- - - _ - - . - - sup 1 ' SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

I Centro Nacional de Investigación y Desarrollo Tecnológico

Subdirección Académica' Of. No. CCS-O35/96

Cuemavaca Mor., a 4 de marzo de 1996.

L.I. Miguel Pérez Ramirez Candidato al grado de Maestro en Cienciq de la Computación P R E S E N T E

Dado que el proceso de revisión de su trabajo de tesis ha concluido con la autorización de todo el jurado para que se imprima, y considerando que cumple con los lineamientos establecidos en el reglamento académico para la obtención del grado de maestría de este centro, me es grato comunicarle que se le concede la autorización para que proceda con la impresión de su tesis. Al mismo tiempo, aprovecho para indicarle que deberá acordar con los miembros del jurado la fecha y hora de presentación del examen respectivo.

Sin más por el momento, reciba mis felicitaciones por el término de su trabajo de tesis, deseandole éxito en el examen correspondiente.

. . , - ,,:r .:;. 1 : :

Dr. José. Ruiz Ascencio Jefe del Depto. de Ciencias

Computacionales.

i ..

C.C.P. M.C. Wilberth Alcocer R. C.C.P. C.P. Ing. David Chavez A.

Subdirección Académica Dpto. de Servicios Escolares

cenidetl Interior internado Palmira S/N C.P. 12490

Aparlado Postal 5-164, C.P. 62050, Cuernavacr Mor., Mfnico Tels. (73) 18-77-41 y 12-76-13, Far. 12-24-34

Dedicatorias

Este. trabajo está dedicado desde su inicio a mis padres Glona Ramírez de Pérez y Miguel Pérez Gutiérrez por esa mentalidad progresista y llena de esfueno.

Quiero también dedicar este. Abajo a José Miguel Pérez Ontiveros para quién espero ser un buen amigo y un buen guía.

Al. M.I. Victor M. Arellano Gómez y al M.C. Juan Arellano Gómez por su apoyo

AI Ing. Carmelo Hernandez ibarra también por su apoyo durante los trámites para

incondicional desde el mismo inicio de los trámites para ser aceptado en el CENIDET.

ingresar al CENiDET.

Al Ing. Saul Chico Muñoz y al Lic. Ricardo Calderón CNZ por su confianza, amistad y apoyo que son invaluables.

A la M. C. Norma J. Ontiveros Hemández y a la Lic. Yolanda Terán Salgado por su amistad durante la realización de la maestría.

Al Dr. Rodolfo Pazos R. que asesoró este trabajo.

Al M.C. Joaquín Pérez O. por sus valiosos comentarios.

Al Dr. Guillero Rodriguez O. por su apoyo para la presentación final de este trabajo.

AI M.C. Alvaro Barba M., al M.C. Manuel Mejfa L., al M.C. Jorge González S. quienes revisaron este trabajo y fungieron como jurados.

A Mario Guillen Rodríguez, Alberto Rueda Valle, Jod Antonio Esparza Garcia, Victor Sosa, Gustavo Alanis Puebla, Matilde Velazco Soni, Ricardo Calderón Cruz y Ana Silvia Agiiera Hemández por su valiosa ayuda durante las pruebas del sistema GERSI.

Al Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) por permitirme realizar mis estudios de maestría, al tecnologtco de Z a a t e p por su apoyo para ingresar al CENiDET, al CONACYT por la ayuda recibida para realizar este trabajo de tesis y al iiE por las facilidades para su desarrollo.

I . .

Resumen

Una de las etapar más importma durante el desarrollo de un Sistema de Información (SI) es el dise& de la base de datos. proceso que involucra la obtención de un esquema.

El esquema de la base de datos implica para el diseffndor, el tomar decisiones acerca de qué informacidn debe estar contenida en la base de datos. pero además de cómo esta ir&ormación debe estar organizada y relacionada. Este tipo de decisiones es crucial dado que de ellas depende en gran medida la eficiencia del SI que se implemente bashdose en dicho esquema.

Este trabajo propone un metodología para obtener el esquema de una base de duos partiendo del docwnento de requerimientos del SI.

Un primer análisis del problema de cdmo obtener el esquema de una base de datos, llevd a la conclusidn de que era necesario obtener conocimiento experto,& asícomo la metodología propuesta, que constituye una serie de ideas dentro de una secuencia ordenada, se cons~myó recopilando, tanto conocimiento de expertos en dise& de bases de datos, como en libros y material aJn.

Como parte de este trabajo se desarrolló también el sistema GERSl que implementa la metodología propuesta, es decir, el sistema contiene cod@cado el conocimiento recopilado.

Por otra parte, el sistema también es capaz de mostrar explicaciones de lo que hace, sin embargo debe aclararse que el sistema GERSI no es un sistema experto, más bien es un sistema basado en el conocimiento de expertos y una herramienta de ayuda durante la obtencidn del esquema de una base de datos. En lo que respecta a los resultaa'os. el sistema fue sometido a pruebas en las que a juicio de expertos los usuarios que utilizaron el sistema obtuvieron mejores esquemas que los que no lo utilizaron (ver CapMo 5).

INDICE

Capitulo 1: introducci6n ................................................................................ 1

1.1 Objetivo de la tesis .................................................................. 2 1.2 Metodología propuesta .............................................................. 3 1.3 Calidad en el esquema de una base de datos .................................... 2 1.4 Beneficios ............................................................................. 8 1.5 Estado del arte ........................................................................ 8 1.6 Distribuci6n del contenido ......................................................... 9

Capítulo 2: Conceptos básicos sobre las disciplinas hvolucradas .............................. 11

2.1 Esquema de una base de datos .................................................... 12 2.2 Lenguaje SQL ....................................................................... 14 2.3 Modelo ELKA ...................................................................... 24

2.3.1 Representación gráfica de en la metodología ELKA .............. 26 2.4 Normalización ...................................................................... 28 2.5 Sistemas expertos .................................................................. 32

2.5.1 Arquitectura básica de un sistema experto .......................... 33

Capítulo 3: Planteamiento y análisis del problema ............................................... 36

3.1 Planteamiento del problema ...................................................... 36 3.2 Análisis del problema .............................................................. 41 3.3 Establecimiento de una metodología ............................................. 42 3.4 Modelo conceptual del sistema .................................................. 60 3 3 Alcance del sistema ................................................................ 63

Capitulo 4: Implementaci6n del sistema GERSI .................................................. 64

4.1 Obtención del conocimiento ........................................................ 65 4.1.2 Representación del conocimiento ..................................... 69

4.2 Implementación del sistema GERSI .............................................. 76 4.3 Clases y sus funciones miembro .................................................. 80 4.4 Componentes del sistema .......................................................... 90 4.5 Recursos de implementación ...................................................... 93

Capítulo 5: Pruebas de funcionalidad ............................................................... 94

5.1 Funcionamiento del sistema GERSI .............................................. 94 5.2 Pruebas del sistema GERSI ........................................................ 122

1

Capitulo& Conclusiones ............................................................................... 136

6.1 Metas logradas ..................................................................... 136 6.2 Trabajos futuros ................................................................... 137 6.3 Observaciones ...................................................................... 138

Referencias ............................................................................................... 140

Apendice: L i i d o del código delsistema GERSI .................................................. 143

ii

Capítulo 1 Introducción

Un sistema de información (SI) es un sistema computacional cuya característica principal es que opera sobre un volumen de información (grande o pequeño) utilizando técnicas de bases de datos. El tipo de información que puede ser mantenido mediante los sistemas de información es muy variado, y puede ser tan simple como el inventario de un establecimiento pequeño, o tan complicado y voluminoso como pueda requerirlo cualquier gran corporación que lleve un buen control de su nómina, presupuestos e inventario al mismo tiempo.

Según Moms (1992), un Sistema de Información consiste de programas de aplicación, una base de datos y procedimientos para procesar datos. Es claro que para implementar los programas de aplicación que van a operar sobre la base de datos, es necesario primero saber cómo debe estar constituida dicha base de datos. En realidad esta toma de decisiones de cómo será la base de datos, constituye una de las primeras etapas de la implementación de los sistemas de información.

Por otra parte, el diseño de una base de datos queda plasmado en el esquema de la base

Además el objetivo de este trabajo de tesis incluye la elaboracibn del sistema GEM1 que implementa la metodología propuesta para comprobar los resultados que ésta proporciona.

1.2 Metodología propuesta i

Durante el desarrollo de este trabajo se llega a la conclusión de que parte del problema se reduce a la obtención y manejo de conocimiento especializado, es decir, obtener y utilizar la experiencia o heurísticas de expertos en el área. De este modo también se decide utilizar técnicas de sistemas expertos para alcanzar el objetivo planteado.

Cabe aclarar aquí que el sistema GERSI no es un sistema experto, el indicar que se utilizaron este tipo de técnicas para su desarrollo, se refiere únicamente al proceso de obtención de conocimiento que Penny Nii (Feigenbaum, 1983), utiliza para construir un sistema experto.

A grandes rasgos, el proceso seguido por Penny Nii es el siguiente: primero se hace una primera recopilación de conocimiento especializado y después debe ,desarrollarse un primer prototipo con el conocimiento obtenido. Despuh se inicia un ciclo en el que los resultados del prototipo estarán sujetos a la modificación, ampliación y aprobación del experto y que termina precisamente cuando el experto indica que los resultados del sistema son correctos.

Esta manera de obtener conocimiento, fue utilizada para desarrollar el sistema GERSI, con la diferencia de que el sistema GERSI no tiene una estructura de sistema experto (Base de Conocimiento, Máquina de Inferencia, etc). Sin embargo durante esta redacción se dan y usan algunos conceptos de sistemas expertos dado que se desean dejar algunas bases que permitan en un trabajo futuro presentar al sistema GERSI como un sistema experto formalmente.

Lo anterior es porque el problema de ¿cómo obtener el esquema de una base de datos? presenta todas las características para ser abordado por un sistema de este tipo, ya que se trata de una herramienta de ayuda durante el diseño de bases de datos, que requiere de la recopilación de más conocimiento, que sea utilizado para monitorear el proceso de diseño y que pueda explicar lo que hace.

El sistema GERSI puede ser visto como la etapa inicial de un proyecto en la que se recopiló el conocimiento suficiente para estructurar una metodología para obtener el esquema de una base de datos, pero que necesita refinarse y ampliarse para constituirse como un sistema experto.

Una vez aclarado lo anterior, a continuación se presenta de manera resumida la metodología propuesta que surge como parte del conocimiento obtenido y que consta de los siguientes pasos:

P.#g 3

Capftulo 1 lntroducci6n

de las veces), y nuevamente el problema del uso innecesario de espacio debido a que el campo puede ser sustituido por una clave.

Determinación de llaves primarias

Determinación de los enlaces entre las tablas

Etapa I:

Etapa 8:

En esta etapa se detecta cuando haya datos en común entre las diferentes tablas para proponer enlaces, y despuh interaccionar con el diseñador para determinar exactamente el tipo de enlace.

Etapa 9: Normalización de las tablas de la base de datos

Existen cinco formas de normalización de una base de datos (Date, 1981), pero en este proyecto se considerará sólo hasta la tercera forma.

Etapa 10: Generación de documentos

En esta etapa se genera el documento con el esquema de la base de datos expresado en SQL; este esquema contiene información. de tablas, atributos (con sus respectivos tipos de dato), llaves y enlaces.

También en esta etapa se genera otro documento con la información del esquema, pero que no se expresa en SQL. Este documento es una descripción del esquema de la base de datos.

Todas estas' etapas describen de manera muy general la metodología que se esti4 proponiendo para obtener el esquema de una base de datos, pero además se recopiló una sene de heurísticas que se aplican a través de dicha metodología (Capítulo 4).

.

1.3 Calidad en el esquema de una base de datos

Además de establecer una metodología para obtener el esquema de una base de datos, la calidad de dicho esquema es uno de los puntos en discusión en este trabajo. Una primera impresión, indicafa que si para obtener la metodología se le preguntó a expertos en el kea, entonces los esquemas obtenidos tendrían una calidad aceptable. Sin embargo lo anterior podría parecer poco preciso. Así que era necesario tratar de investigar si había algún tipo de parámetro o parámetros que proporcionaran más información al respecto. De esta manera ahora la pregunta era ¿qué es la calidad en un esquema? La respuesta a esta pregunta iambién fue obtenida en la misma forma que la metodología, preguntando a personas con experiencia en el diseño de bases

Pdg 5

cI9pftulo 1 lntroducudn

- Complejidad de desarrollo de los programas de aplicación

Si la integridad referencial debe ser implementada en los programas de aplicación, ésto puede ser muy complejo si se tiene el problema de la redundancia de información.

- Poca flexibilidad en el mantenimiento de los programas de aplicación

Este problema es heredado de la complejidad de la implementación de los programas originales. En principio será más difícil entender dichos programas y después su actualización seguirá el mismo grado de complejidad original. Lo anterior implicará un mayor tiempo de actualización y por lo tanto un mayor costo.

Normalización

El proceso de normalización juega un papel importante en la calidad de un esquema, ya que es un proceso mediante el cual se verifican las listas entidad-atributos para asegurar que los atributos estén donde pertenecen (Hogan, 1990). Por lo anterior, el proceso de normalización también permite evitar redundancias y establecer nuevos enlaces.

rn Optimización del espacio de almacenamiento

El utilizar espacio de almacenamiento indiscriminadamente, podría eventualmente ocasionar problemas de falta de espacio.

Los parámetros anteriores son los que se han tomado en cuenta para este trabajo, aclarando además que dichos puntos en el sistema GERSI están incluidos como parte de la metodología que implementa y pueden ser considerados por el diseñador, queriendo indicar con lo anterior que el sistema no le forzará a realizarlos. El hecho de que el sistema sugiera en lugar de obligar a hacer algo se sustenta en el hecho de que no todas las observaciones pueden ser aplicadas a cualquier esquema, lo siguiente ilustrará un posible caso.

Como puede observarse el proceso de normalización es determinante en la calidad del esquema de una base de datos, sin embargo, y esto basado en opinión de expertos, puede darse un caso en el que para alguna aplicación un diseñador sabiendo que alguna relación no está normalizada en determinada forma, él decida que debe quedarse así a fin de tener una mayor rapidez de acceso sin importar que la tabla esté normalizada o no.

P4g 7

Introducúdn capftulo 1

Herramientas llamadas "frontend", como es el caso de SQL-Windows (Gupta, 1994).

Herramienta de diseño ERwinlERX (Logic Works, 1989-91).

Todas las referencias y herramientas mencionadas presentan diferencias con el presente trabajo, y como factor común, todas parten del hecho de que el diseñador ya conoce qué información será parte de la base de datos, mientras que en este trabajo se parte solamente del documento de requerirnientos del sistema de información.

En la Sección 3.1 se detallan las diferencias de cada una de las referencias mostradas comparadas con este trabajo.

1.6 Distribución del contenido

El Capítulo 2 presenta una serie de conceptos sobre las disciplinas del conocimiento involucradas en el desarrollo del presente trabajo, entre las cuales se pueden mencionar las siguientes: conceptos de bases de datos tales como definición del esquema de una base de datos, normalización y SQL; también se presentan las principales definiciones del modelo ELKA; por último se presentan algunos conceptos de sistemas expertos tales como representación de conocimiento y mecanismos de inferencia. Este capítulo presenta conceptos ya conocidos, es por ello que al lector ya instruido en bases de datos y sistemas expertos se le recomienda pasar directamente al Capítulo 3.

El Capítulo 3 es uno de los más importantes, dado que es aquí donde se plantea y describe el problema que ha sido abordado por el presente trabajo y como consecuencia de ello presenta el objetivo de la tesis. Posteriormente en este mismo capítulo se hace un análisis del problema planteado y también se propone una solución (metodología) y un modelo conceptual del sistema GERSI.

El Capítulo 4 describe los detalles de la implementación del sistema GERSI, lo cual incluye la manera en que el conocimiento fue obtenido y representado, y una descripción de las diferentes clases implementadas y cómo se utilizaron para la implementación de cada uno de los módulos del modelo conceptual del sistema.

El Capítulo 5 contiene las pruebas de funcionalidad del sistema, lo cual a su vez refleja la efectividad de la metodología propuesta. Como ejemplo se toman los requerimientos de un sistema pequeño a fin de no utilizar tanto espacio con los datos, pero por otra parte se hace énfasis en lo que el sistema es capaz de hacer.

El Capítulo 6 contiene los comentarios finales y además da un panorama en el cual se

Pdg 9 I

Capítulo 2 Conceptos básicos sobre las disciplinas involucradas

Ei objetivo de este capítulo es presentar brevemente los conceptos más relevantes acerca de las disciplinas involucradas en este trabajo.

Como se mencionó en el capítulo introductorio, el propósito del sistema GERSI es constituirse como una herramienta que proporcione ayuda durante el diseno de una base de datos (BD), es decir, se trata de una herramienta que conjunta para su desarrollo conceptos sobre diseño de BDs. Por tal motivo se abordan tópicos como SQL que es un lenguaje de datos, el modelo ELKA que es una técnica de modelado de BDs y normalización que es una forma de optimización del diseño de la BD.

Para finalizar este capítulo, se incluye también la definición de un sistema experto, dado que se recurrió a algunas de estas técnicas durante el desarrollo del sistema GERSI.

P6g 11

capitulo 2 Conceptos básicos sobra las dismphas involuuedas 1 /-

conceptual puede ser considerado como el que define una vista de la comunidad de usu&os, es decir, existen muchas vistas externas, cada una de las cuales puede involucrar parte de la BD, mientras que habrá sólo una vista conceptual que incluye la totalidad de la BD (Date, 1986).

Considerando nuevamente la arquitectura de un sistema de BD pero ahora en términos de vistas, esquemas y los lenguajes en los que pueden ser representados, se tiene lo siguiente:

La vista de un usuario individual se llama vista externa. Una vista externa se define por medio de un esquema externo, el cual se compone en esencia de las definiciones de cada uno de los tipos de registros externos' de cada una de esas vistas externas. El esquema externo se escribe usando el DDL (del inglés: Data Definition hguaje) del lenguaje de datos y por ello algunas veces también se le llama DDL externo.

I ,

Una vista interna se describe por medio de un esquema interno, el cual no sólo define los diversos tipos de registros almacenados de la totalidad de la BD, sino también especifica cuáles índices existen, de qué manera se representan los campos almacenados, en qué secuencia física se hallan los registros almacenados, etc. El esquema interno se escribe utilizando un DDL interno.

La vista conceptual es una representación del contenido total de una BD, se pretende que sea una vista de cómo son los datos en realidad, y no de cómo los usuarios están obligados a verlos por las restricciones @or ejemplo) del lenguaje particular o del "hardware" que utilizan. La vista conceptual se define por medio de un esquema conceptual, el cual incluye definiciones de cada uno de los distintos tipos de registros conceptuales. El esquema conceptual se escribe usando un DDL llamado DDL conceptual.

Para otros autores como Mahler (1990), la vista conceptual de la BD se define en un esquema de vista conceptual, este esquema incluye las definiciones de cada una de sus tablas en la BD y sus partes constituyentes.

Por otra parte Korth (1987), nos presenta una relación entre el diseño de una BD y su esquema: "El diseño general de la BD se llama esquema de la BD. Los esquemas se alteran muy raras veces, o nunca".

Enfocándose más aún en el diseño de BDs, Atre (1980) nos dice: "Las técnicas estructuradas para el diseño de bases de datos incluyen el diseño de un modelo conceptual, el diseño de un modelo lógico y el diseño de un modelo físico".

A continuación se describe lo que en este trabajo se considera como el esquema de una base de datos, pnmemmenie tal esquema se basará en la camcteMca del esquema conceptual de Date, el cual incluirá a la totalidad de la base de datos; por otm parte al igual que el

Pbg 13

cap~tulo 2 Conceptos básicos sobra las disciplinas involucradas

ANSI más algunas mejoras (para más información acerca de este SQL extendido ver: Arellano, 1992).

En la Figura 2.2 se presentan una serie de gráficas con la sintaxis de las instrucciones del DDL que deberán ser soportadas por el sistema desarrollado en este trabajo.

A la izquierda de cada gráfica se encuentra un letrero que indica lo que ésta define, el letrero es seguido por una sene de rectángulos, elipses y círculos. Cada rectángulo representa un elemento no terminal (definido en otra gráfica), los círculos y elipses indican que se trata de un símbolo terminal y éste deberá ser incluido en una expresión tal como está.

Para verificar que una instrucción haya sido construida correctamente o para producir una instrucción válida del DDL, s610 se tienen que seguir las flechas empezando por la izquierda de cualquiera de las gráficas y continuar por donde se desee (respetando siempre la dirección de las flechas) hasta salir por la flecha de la derecha.

A manera de ejemplo, haciendo uso de la sintaxis mostrada en la Figura 2.2, se puede definir una base de datos, ésta podrá contener, por ejemplo, información acerca de una colección de discos compactos, de este modo se necesitan al menos una tabla para almacenar información de los discos ("cd") y otra para almacenar información de quienes los publican ("publishers"). Así, las tablas podrían quedar definidas de la siguiente manera (ejemplo basado en Mahler, 1990):

Ejemplo I: Definición de tablas usando el DDL.

CREATE TABLE cd CREATE TABLE publisher (

performer CHAR(18), cd name CHAR(30), catalog CHAR(10)

)

( idqublisher CHAR(8), pubname CHAR( 18), performer CHAR(18)

)

El esquema de una BD incluye principalmente la definición de tablas como las mostradas en el Ejemplo 1, claro que ésto será el resultado de un previo análisis que incluye restricciones de unicidad y normalización entre otras cosas (estos tópicos serán detallados más adelante).

11

Para las tablas del ejemplo también se podrían definir sus llaves primarias, utilizando las gráficas de sintaxis. Específicamente la gráfica de "especificación de restricción de unicidad para una tabla" (que forma parte de la Figura 2.2.c) nos proporciona una manera de definir las llaves

Pág 15

2 Conceptos básicos sobre las disciplnas involuwadas

I tipo de dato

@ +

número exacto I I* I , númm ++"úmmap+-t- >

Figura 2.2.b Gráfica de sintaxis del DDL

cap ftulo '2 Conceptos bás¡cos sobra las disciphnas invducradas

,

, : Figura 2.2.d Gr@ca de sintaxis del DDL

primarias. Para la tabla "cd" el número de catálogo podría usarse como llave primaria, y quedaría definido de la siguiente manera:

1 CREATE TABLE publisher (

CREATE TABLE cd . , (

performer CHAR(18), idqublisher"CHAR(8) NOT NULL

catalog CHAR(10) NOT NULL, PRIMARY KEY (catalog)

pub-name CHAR(18), performer CHAR( 18),

cd name CHAROO), (

' PRIMARY KEY (idqublisher) ' 1

) )

Análogamente queda definida la tabla publisher tomando como llave idqublisher.

Las gráficas de la Figura 2.2 proporcionan la sintaxis suficiente para crear el esquema de una base de datos, en este caso el esquema será expresado en el SQL extendido ya mencionado.

, -

Lenguqie de manipuiación de datos

En io que respecta ai DML @e SQL, éste permite a los usuarios manejar o tener acceso a los datos que estén organizados por medio de un modelo apropiado; esta manipulaci6n consiste

PBg 19

caprtuio 2 Conceptos besrcos sobra les disa.jMinas involucrades

expresión. se compone de un predicado que incluye columnas de las tablas que aparecen en la cláusula FROM. representan columnas (puede ser * para indicar todas las columiias de las tablas que aparecen en la cláusula FROM).

es un predicado (si se omite, es verdadero).

WHERE

a,

ri representan tablas. P

E.jempZo 2: Se desea saber qué d i k s son interpretados por "Talking Heads". La expresión en SQL sería la siguiente:

SELECT c d - m FROM cd WHERE performer = "Taiking He&"

El resultado de la consulta sería la siguiente lista:

Speaking in Tongues Little Creatures Stop Making Sense

Entre las instrucciones del DML de SQL que permiten inseriar, modificar y eliminar información de la BD se tienen INSERT, UPDATE y DELETE respectivamente y se presentan a continuación:

b).- Inserción

Una inserción en SQL tiene la siguiente forma:

INSERT INTO r [al, a2, ..., aJ VALUES (v,, v2, ..., vJ

donde

r v, a,

es una tabla donde se de& insertar los nuevos datos. son los valores correspondientes uno a uno a las columnas de la tabla r. representan columnas y los corchetes indican que son opcionales.

Para insertar datos en una tabla debe especificarse el renglón que va a insertarse. Los valores de las columnas de los renglones que se inserten deben pertenecer al dominio de estas columnas, además los renglones que se inserten deben ser del mismo grado.

Ejemplo 3: Se desea insertar un nuevo renglón en la tabla "cd", cuyos campos son los

Pdg 21

CENTRO DE INFORMACION ~ y C E M I D E T

' caprtuio 2 Conceptos bBsicos sobre les disdpiines involucedas

r es una tabla.

Los renglones t en r para los cuales P(t) se cumpla serán eliminados de r. En la cláusula DELETE s610 una tabla puede ser incluida, si se desean borrar renglones de varias tablas, deberá haber un DELETE por cada tabla. Si la cláusula WHERE se omite, todas los renglones de la relación r serán borradas.

qemplo 5: Se desea eliminar totdos los renglones de la tabla "cd" cuyo valor en performer es "Talking Heads"! La expresión en SQL es la siguiente:

i1

,I DELETE FROM cd WHERE performer = "Talking Heads"

El resultado de ejecutar esta cláusula, esque los tres renglones de la tabla "cd" que cumplen con el predicado performer = "Talking Heads", serán borrados.

'1

' Date (1981), menciona algunas ventajas del DML de SQL cuando se compara con DMLs de niveles más bajos.

Varios de los puntos siguientes se aplican también a otros DMLs relacionales de nivel de conjunto (Date, 1981):

w Sencillez (nSimpíicity*l) Muchos problemas se pueden expresar con mayor facilidad y concisión en SQL que en lenguajes de nivel más bajo, la sencillez redunda en una mayor productividad.

u Completitud ("Completeness") El lenguaje es relacionalmente completo, ésto significa que para una clase muy grande de consultas, el usuario nunca necesita recumr a ciclos 6 bifurcaciones (ésto no es del todo cierto para SQL intercalado).

w Aprocedimentalidad ("Nonprocedudity") Esto se refiere a que SQL es más indicativo, ya que para recuperar alguna información simplemente se indican los datos que se desean en lugar de elaborar un procedimiento de recuperación. Para indicar los datos que se desean, se utiliza alguna instrucción la cual es una "declaración de intención" de alto nivel por parte del usuario. Esto es importante porque significa que el sistema es capaz de capturar la intención del usuario, es decir, puede entender lo que el usuario trata de hacer a un nivel muy alto.

Independencia de Datos ("Data independence") Las instrucciones del DML de SQL no incluyen ninguna referencia a rutas de acceso explícitas, tales como índices o secuencias físicas (pueden insistir en una secuencia

L Póg 23

/I

I

cspRu/o 2 ;i Conceptos bBsic0s sobre las disci*Mnas involtmadas

I/ a).- Uno a uno

: b).- Uno a N débil (cero, uno o más) c).- Uno a N fuerte (uno o más)

I1 Estos tipos de enlace se detallan más adelante. i

Es una característica de un elemento de una enti implementa computacionalmente p m o un registro (tamb

elemento de una enti_-- se mado tupla). Un atributo será

entonces un campo de una tupla o registro, y se reprksenta como una pareja compuesta de un nombre de atributo y un valor, por ejemplo el siguiente conjunto de atributos representa una entidad (en este caso discos compactos) que posee tres atributos de interés

id. in 1

{performer : Talking Heads cd-name : S&ng in Tongues catalog : 2530154 }

El nombre de un atributo representa un tipo de propiedad, por ejemplo, ”ai-name” es

Una clase de entidades es’ un conjunto de entidades que se agrupan porque poseen el mismo tipo y número de atributos de interés para la base de datos, en la metodología ELKA a una clase de entidades se le debe asignar un nombre único que será el nombre de cualquiera de las entidades que pertenecen a la clase, Por ejemplo, el siguiente conjunto es una clase con dos entidades:

el nombre de un conjunto de valokes que representan los nombres de discos compactos.

{performer : Talking Heads cd-name : Speaking in Tongues catalog : 2530154 }

{performer : Wang Chung ai-name catalog : 4004-2}

: Poih on the Curve

Se reconoce que las dos entidades corresponden a “discos compactos”, y por lo tanto se podría asignar este nombre a la cl&e de entidades, aunque para abreviar se puede usar también cd (“compact disk”).

Pág 25

Capltub 2 I * i . Conceptos básicos sobre las disciprinas involucradas

~~~ ~ ~

FEgura 2.3 E n l y e Uno a Uno (Uodelo ELM)

entidad "a" que pertenece a la clase de entidades A, existen cero, una o más entidades "b" que pertenecen a la clase de entidles B, y para cada entidad "b" que pertenece a la clase de entidades B, existe exactamenteluna entidad "a" que pertenece a la clase de entidades A.

! I

Rgura 2.4 Enlbce Uno a N débil f l o ~ ! ~ l o UM) ! m Enlace Uno a N fuerte

Esto representa que la entidad A hereda a la entidad B la llave y. Para cada entidad "a" que pertenece a la clase de entidades A, existen una o más entidades "b" que pertenecen a la clase de entidades B, y para cada entidad "b" que pertenece a la clase de entidades B, existe exactamente una entidad "a" quk pertenece a la clase de entidades A.

m Enlace N a M I

Pág 27

I ! !

~

!

I

i t

I I I

I

capftulo 2 Conceptos básicos sobre les disciplinas involucrades

4

Figura 2.8 Enlace N a M (Modelo ELKA) 1 't

siempre están normalizadas (ai' I menos en 1 a forma normal), de esta manera es importante que quien diseñe una BD esí6 familiarizado con la teOria de normaliición.

I,/

I l l Date (1986) nos habla de cinco formas normales, donde una relación, se dice que está en determinada forma normal d satisface cierto conjunto de restricciones y donde las relaciones que están en 2p forma normalbson preferibles a las que están en la, las que están en 3a son preferibles a las que están en 2a y 1 a , y así sucesivamente. Esto se debe a que las relaciones que están en determinada forma normal ya están en las formas normales anteriores, por ejemplo las formas que están en 3a forma'hormal también lo están en 2a y la forma normales.

A pesar de que haya varias formas normales no puede adopiarse con grado de ley que una relación siempre deba es& en una forma normal elevada como 4a o 5a. Sin embargo es

Pdg 29

It

1 11

__-

dependencia multivaluada I

. .

.I

-._I_ ~

:I"

. .

R.A +P R.B

I !

Segunda fonna normal

Una relación está en I

. . . .

I ! '

2a:,forma normal (2NF) si y s610 si está en.la forma normal (1NF)

I I Tercena forma normal I :

I I El estudio y desarrollo1 de los SEs constituyen una de las áreas de estudio de la

i I

explicaciones). La existencia de SE. Así, se podrán encontrarISEs numéricos a grar,escala, o (ver Figura 2.8).

' i

Base de Conocimiento . . 'I

'i

alguna otra componente, está determinada por la aplicación del con capacidad para hacer gráficas, para hacer cálculos

que:presenten más de una de'estas características al mismo tiempo

:

. , L ,>

I .

Conceptos bBsicos sobre las disciplinas involuuadas

1 I

capltu10 2

m Debe presentar los resultados en forma clara para el usuario. Las preguntas y explicaciones deben ser comprensibles.

, Además de las ya mencionadas, los sistemas expertos pueden incluir otras componentes,

tales como módulo de explicaciones y componente de adquisición del conocimiento. Pueden existir otras componentes, pero estás están determinadas por la aplicación del sistema experto.

1 ~

Módulo de explicaciones I I

I Este módulo se encarga de proporcionar información respecto a la linea de razonamiento que sigue un SE para llegar a sus conclusiones, &to es importante para que pueda inspirar confianza a un usuario.

Nebendahl (1988) nos dipe ai respecto: A pesar de insistir sobre la importancia de una componente de explicaciones (CE), es m y dijTcil y harta ahora no se ha conseguido cumplir con todos los requisitos de una buer;ia CE. Agrega además que las componentes existentes de este tipo pueden ser suficientes para @l ingeniero del conocimiento, porque está familiarizado con el entorno del procesamiento de datos, pero para el usuario, son todavía demasiado insatisfactorias.

i

!

I

?

Pdg 35

/I,

Figura 3.1): '

! .. . .,. / / *' .

Planteamiento y análisis del problema capltul0 3

, . .t - 1: Pág 37

. . I Estado del arte., : . .

2' . requerimientos 'del: &ma de información) y después tendría que aceptar, rechazar, o

Pdg 39 I!: ;i i !i . i /

* ^ , ?. . . , .

L , . . .

CBpltUO 3 Planteamiento y andfisis del problma

cuenta con una caja de herra4ientas para crear el modelo entidad relación de un esquema, verificando al tiempo de ejecución si cada uno de los símbolos predefinidos se están utilizando correctamente, además tiene &xiones para generar el esquema basándose en diferentes manejadores de bases de datos. 1

Nuevamente la diferencia entre ERwin/ERX con la metodología que aquí se propone, es que dicho paquete parte del hecho de que el usuario ya sabe qué atributos y tablas son los que formarán la base de datos, mientras que la metodología propuesta incluye la determinación de estos datos.

I

3.2 Análisis del problema

La metodología requerida en el planteamiento del problema debe proporcionar la manera de poder hacer la transición del documento de requerimientos al esquema de la base de datos. El problema fundamental al que dicha metodología debe proponer una solución, es ayudar al diseñador a decidir qué infordación se debe almacenar en la base de datos y cómo se debe organizar esta información, \s decir, la metodología debe ayudar al diseñador en la determinación de cuántas y cuáles son las tablas que deberá contener la base de datos y qué columnas contendrá cada una de ellas, asf como sus llaves primarias. Además de ésto también deberá ser capaz de ayudar a dtablecer los diferentes enlaces que habrá entre las tablas.

Despub de haber determinado toda la información referente a tablas, columnas, llaves primarias y enlaces, también el esquema debe quedar normalizado hasta la 3a forma. Finalmente debe ser generado un documento del esquema expresado en SQL. En las secciones subsecuentes se irá planteando la manera en que los problemas serán abordados y qué herramientas se utilizarán. I

Herramienta utilizada para obtener la metodologla

Se ha mencionado antes que el tránsito de los requerimientos al q u e m a de la base de datos irivolucra en gran medida la experiencia del diseñador, es decir, el diseño de una BD es una tarea que puede ser realiihda con mayor eficiencia por personas que poseen una amplia experiencia en este campo. 'I

Por lo anterior puede verse que aquí lo que está en juego es la obtención, manipulación, I I

I t

y aprovechamiento del conocimiento de personas expertas en el diseño de bases de datos.

Así, la metodologfa obtenida se basa en entrevistas con diseñadores especializados. De esta manera, y para el propósito de este trabajo ha sido necesario recurrir a estas personas y

Pdg 41 !

capitulo 3 , '

,

.!l.

i

i

!

Cuadro 3.1 Metodc

de experiencia ai ejercer su p

I Para la metodología ql privado, y para ello es necesax

I de bases de datos, al mismo ti el conocimiento para poder u1

Después de algunas en1 es parte del conocimiento I 1 conocimiento, más adelante SI

Feigenbaum (1982) af

Planteamiento y andlisis del problma 1 -

¡a de Penny Nii para construir sistemas expertos

, .

i.

:/>

!'

.i. ... .

. .

esión, este conocimiento es propio de cada persona.

se requiere en este trabajo es necesario obtener conocimiento tener entrevistas con personas con amplia experiencia en el área po debe determinarse la manera en la que se puede representar WlO.

ristas se ha logrado obtener una metodología. Esta metodología enido, y cada paso de esta metodologia también incluye etailan las heuristicas obtenidas.

ia el proceso de obtención de conocimiento es una tarea que

Pdg 43

cápltUl0'3 ' plenteatnhto- y análísis d d problema

. . . .

l l

'I

I '

111 , Como puede observarse en la función cuatro del kquerimiento aparece una lista de los

datos que el usuario desea vermdurante la consulta, de la misma forma el requerimiento de un reporte o cualquier requerimiey/o que involucre información que el usuario desee con el uso del sistema, también podría aportar información sobre los datos de salida del sistema de información. Es recomendable esta etapa que aún cuando el documento de requerimientos no lo indique, cuando los datos sean alimentados ai sistema, éstos sean precisados hasta donde sea posible, dado que &to puede kvim confusiones más adelante, por ejemplo si se tuviera un documento de requerimientosI\para un sistema de información sobre proveedores, partes, y clientes, para cada una de estas entidades podría requerirse un nombre, en este caso sería muy impreciso y habría mucha ambtgüedad si se indicara tres veces "nombre" uno para cada una de las entidades. Una manera de./precisar !a información sería indicar "nombre del proveedor", "nombre de la parte", y "nombre del cliente". Esta recomendación debe seguirse para todos y

1'

I1 :. 'I P6g 45

Planteamiento y análisis del problema

2.1.- Determinar a partir de intermedios

s El objetivo de almacenarse en la base

de ayudar al diseñador a decidir qué datos pueden realizar una identificación de los datos de entrada

separadamente de los datos de la raz6n de esta separación se detalla en la Etapa 2.

4 1, 'i

t

1.3.- Captu, de los datos del sistema de informaci6n I

qué datos de entrada se pueden obtener los datos de"saIida e / / I ,

I1 I Nuevamente, los datos pueden ser capturados de la misma manera que los datos de

entrada y salida. En este trabajo se considera como un dato intermedio a algún dato que surja como resultado de algún tipo de proceso (cálculo numérico por ejemplo), antes de llegar a un resultado final. Algunos de estol' datos intermedios pueden formar parte de la base de datos. Por ejemplo, si es necesario reali4Lrepetidamente un proceso en el que siempre se deba reproducir cierto tipo de informaci6n intermedia, tal vez sea preferible que este dato solamente sea obtenido la primera vez y después ya s6io sea utilizado. Esto indiscutiblemente lo tiene que decidir el diseñador. ,111

!i I 'I Etag 2.- Identificación de los datos de la base de datos

El propósito de esta etapa es obtener una primera versión tan completa como sea posible de los datos que son candida$s a ser almacenados en la base de datos. En esta etapa se aprovecha el hecho de que en la etapa anterior se hayan obtenido en forma separada los datos de entrada y los datos de salida( del sistema de información.

Inicialmente en esta etay es necesario realizar un m a p entre los da& de salida y los datos entrada, ésto con el pro#sito de identificar a partir de qué datos de entrada se pueden obtener los datos de salida del sistema de información. Este mapeo tiene la finalidad de resolver tres posibles problemas:

I

1

il li

P6g 47

'! Planteamiento y aniílisis del problma cI3pftulo 3

la necesidad de generar datos in@rmedios que también se podrían almacenar en la base de datos. i

2.3.- Fusión de datos I

Como resultado del m a p de los datos y sólo después de que verificar que no existen datos supertiuos y tampoco datos que no se sepa de donde vienen, se obtendrá una sola lista que constituye la primera versión de los datos que podrán ser almacenados en la base de datos.

I

Para el ejemplo, el sigyiente paso es fusionar las dos (tres en caso de haber datos intermedios) listas de datos (de entrada, de salida e intermedios) en una sola sin admitir repetidos, y de esta manera se obtiene el primer borrador de los datos que son candidatos a ser almacenados en la base de datos. Así, se tiene lo siguiente:

Datos CANDIDATOS a estar contenidos en la base de datos

- No. de catálogo de la parte - Descripción de la parte C6digo de la cladificación de tipo Peso de la parte '' - Color de la parte

- Precio de la parte

- -

Etapa 3.- Asignación de nombres únicos y tipos a los datos determinados en la Etapa 2

Contando con el primer borrador de los datos que son candidatos a ser almacenados en la base de datos, el siguiente paso es asignarles un nombre Único a cada uno de ellos y sus correspondientes tipos, para el ejemplo de la etapa anterior, la lista podría quedar de la siguiente manera:

I

NoCatalogo CHAR(8) No. de catálogo de la parte DescParte CHAR(20) Descripción de la parte Tipoparte CHAR(6) Código de la clasificación de tipo Peso FLOAT Peso de la parte Color CHAR( 10) Color de la parte Precio DECIMAL(5,2) Precio de la parte

Así, los datos contenidos en la lista que se obtuvo en la Etapa 2 podrían constituirse I como comentarios para cada uno de los nombres de datos que se obtienen en este punto.

i Piíg 49

i

I

i

I

I i I I

i I

planteemiento y análisis d e l p b l m a

, .

(Identificador del proveedor} {Nombre del proveedor} {Nombre de la compañía del proveedor}

Glpitlllo3 :

. ..

, /I

mismo dato "NomCompañia", que aparentemente es el mismo, pero no es así. En el primer caso "NomCompafiia", es el nombre de la compañía donde el cliente trabaja, m i e n d que en el segundo caso "NomCompañia", es el nombre de la compañía donde trabaja el provkor; es decir, se está utilizando el mismo nombre para dos atributos diferentes cuyos contehdos tienen significados diferentes, Paral eliminar este problema basdcon cambiar de nombre a'hguno de los dos datos. ,

c).- Información redundante

.

. , j : 'll

, * , Podría da& el &so en información redundante por ejemplo en los siguientes

{Número de empleado} > {Nombre del empleado} , . , a

datos:

Nompmpleado . I , ' EdadEhpleado {Edad del empleado}

i 4: {Fecha de nacimiento del empleado} , .

La edad del alguno de los datos podría eliminarse

d).- Datos

Este problema es un tanio similar al anterior, pero aquí en lugar de poder calcular un dato a partir de otro, un dato puhe ser deducido a partir de otro. Nuevamente consideremos un ejemplo con los siguientes dato&

I1

de nacimiento, por io cual puede eliminarse. Por ejemplo

'i

{Número de empleado} NoEmpleado NomEmpleado {Nombre del empleado} Fecha$acEmp {Fecha de nacimiento del empleado}

w Casad? {Indicador de si el empleado es casado} w Soltero {Indicador de si el empleado es soltero}

1

,:I En este caso teniendo algún valor para el dato "Casado", puede deducirse un valor para

el dato "Soltero", es decir, es sdficiente con s610 uno de los datos. Como el problema involucra

Pág 51 't

I , I B

ca~turo 3 I Pianteatnhto y analisis del problema

descripción P a Pew precio

1 ' 5 ! 1

1

Así el sistema proponda al u s u a ~ la palabra "parte" como el nombre de un posible objeto (tabla).

t

Etapa 5.- Definición de las tablas de la base de datos I

El objetivo de esta etapa es obtener una primera versión de las tablas que constituyen la base de datos. Esto involucra la asociación los diferentes datos de la lista resultante en la Etapa 3 a cada una de la tablas. Dicho de otra manera, en esta etapa se quiere la primera versión de la definición de las tablas juntc con sus datos correspondientes.

Durante la asignación de atributos a tablas puede darse el caso en el que queden atributos que no se hayan asignado a alguna tabla, &o podría indicar ya sea que falte alguna tabla o que existen datos que no deben es@ presentes, es decir, lo anterior podría indicar también que existe alguna información redundante' que podría ser eliminada.

En un intento de ayudar ai diseñador, podría tambien hacerse una asignación automática, dado que si los nombres de algunas de las tablas surgen de las ocurrencias de dicho nombre en los datos, entoces se poddan agrupar todos los datos donde aparezca un nombre de tabla como posibles atributos de esa tab1a.j

, Etapa 6.- Optimización del espacio de almacenamiento de la base de datos I

En la Etapa 5 ya se ha obtenido una primera versión de las tablas de la base de datos con sus respectivos datos (columnas). En esta etapa lo que se desea es determinar la posible existencia de otras tablas como solución a determinados tipos de problemas. A continuación se I presentan dos ejemplos repre6ntativos.

I I

a).- Desperdicio de espacio de almacenamienro

Supóngase que dentro ;de una tabla existe una columna que tiene una longitud de 200 caracteres, y que se trata de una tabla que podrá contener hasta 10,OOO renglones, pero que este campo se encuentra vacío en el 90% de los renglones (debe ser preguntado al usuario), ésto

1 P4g 53

/ ' I I

tablas, y de la misma mane? descomposición que el diseñador

I '

!I

que en etapas anteriores, el sistema s610 sugerirá alguna podría considerar para un mejor diseño.

1

Pianteamiento y an4üsis del problema 1 capnulo 3

cada tabla con las restantes, de establecer un enlace entre

que si se da relación entre dos tablas, es posible

por ayudar al diseñador en esta siempre el diseñador es quién decide si los

El obtener los etapa, estos enlaces acepta o no, permitiéndole en &a etapa hacer cambios o borrar enlaces. Por supuesto el diseñador siempre tendrá la opcikn de dar de alta los enlaces manualmente.

11

P4g 55

I

I ) p/anteam;ento y anhlisis del problma CBpltUlo 3

i 1

EMPLEADO ' I

DEPARTAMENTO NoDepto NoEmpleado

b NoEmpleado t

Empezando directamente' en el Paso 2, dado que el proceso no se hará sobre toda una base de datos, una de las condiciones para que las tablas esten en 1 * forma normal se expresó en el inciso b anterior. Este se :$fíere a que debe haber un lsolo valor posible para cada atributo. De esta manera puede observarse que la columna "NoEmpleado" no cumple la condición, ya que para cada departamento existe1 más de un empleado, entonces existen muchos valores de "NoEmpleado" . Paso 3.- Se está suponi$do que la columna "NoEmpleado" existe también en la tabla

EMPLEADO, así que el Paso 4 procede1 inmediatamente y la columna debe eliminarse de la hbla DEPARTAMENTO.

' I

Paso 5.- Para determinar el enlace entre las tablas DEPARTAMENTO y EMPLEADO, simplemente se'pueden responder a las siguientes dos preguntas: - ¿Para cada dephamento existen uno o muchos empleados? R = Muchos - ¿Un empleado pertenece a un departamento o a muchos?

I Así que el eniak es Uno a Muchos (1:M)I

R = Uno

' I m Enlace Uno a Muchos incluyendo la creación de una nueva tabla

11 Supóngase que se cuenta con siguiente tabla:

I

REVISTA CodigoRevista

DirRevista b FechaEdicion

NombreRevista 11

Paso 2.- Nuevamente verificando la condición b),pnkrior para la tabla REVISTA, la columna "Fec~akdicion" no cumple la condición ya que para una revista hay varias ediciones'y por lo tanto varias fechas de edición.

Aquí se esta; suponiendo que no existe otra tabla donde la columna "FechaEdicion" aparezca. il r Paso 3.-

Pdg 57

cepltulo 3 Planteamiento y andlisis del problema

11 ' 1 1

Paso 3.-

Paso 4.-

Paso 5.-

Paso 9.-

Paso 10.-

ll Nocatalogo NoOrden

I I

2'Forma No& I I x Para la 2a forma normal es necesario que se cumpla la siguiente condición:

Cada atributo que M pertenece a la llave &be depender completanume de la llave.

El proceso para normalizar hasta la 2a forma es idéntico al de la l a forma, es decir, puede seguir el, mismo algoritmo, sólo que esta vez fa condición a cumplirse dentro del algoritmo debe ser la condición de normalización de la 2a forma normal.

I 111 'I

3" Forma N o d

Para la 3a forma normal es necesario que se cumpla la siguiente condición:

Un atributo que M penenece a la llave M &be depender & algún otro atributo que M I

sea llave, I

P4g 59 I/

GERSI I I I

Figura 3.2 Modelo conceptual 41 sisfema GERSI

m Define datos

Permite asignar nobrei ly tipos a los datos candidatos a estar en la base de datos, es decir, a los posibles atributos!

Identifica tablas 1 1

l ' I )

Permite proponer los n'ombres de las tablas mediante el submódulo de análisis léxico y también permite que el diseñador haga cambios a los nombres propuestos.

¡I

Análisis léxico

Este módulo y su objetivo una vez que se cuenta con todos los datos (entrada, salida e intermedios),

Púg 61

un proceso intermedio es parte de la metodología propuesta

1 1

!

~ 1 I/

Capitdo 3 Pianteamhnto y anáüsis del problema

I I 11 proveniente del documeyto de requerimientos adem& de algún otro dato requerido por

el sistema. También a l/ravt% de esta interfaz, el Sistema podrá mostrar algunos de sus resultados y el usuario idteraccionará con el sistemh. Será también a través de la interfaz hombre-máquina que un1 usuario podrá ver algunas expiicaciones sobre algún proceso.

3.5 Alcance del sistema

que deben ser alcanzadas por (el sistema.

B

I , Con el tin de establecer !os límites de este continuación se establecen las metas

I 11

El sistema podrá ser alimentado con datos que surjan del documento de requerimientos de un sistema de información y como resultado el generador podrá obtener semiautomáticamente (con ayuda del diseñador) el esquema conceptual de la base de datos expresado en SQL (ver Capitulo 2).

El diseño generado Cbnsided al menos hastamlla primera forma de normalización, aunque el sistema permitirá analizar hasta la 3a forma normal. i It I)

El sistema será capaz de generar los siguientes ddcumentos: a).-

b).-

El esquema de ia base de datos, es decir, el código en SQL extendido para crear la base de datos! Un documento que contenga el esquema con una descripción de cada uno de los atributos.

Pisg 63

ImplementeWdn del sistema GERSI 1 , I ceprtulo 4 1

I \ !I //

11

i . . 4.1 Obtención del conocimiento

4 i 'i

La metodología de Penny Nii (ver Sección 3.2) para construir sistemas expertos proporciona los lineamientos paia la obtención del conocimiento, principalmente en la estrategia interactiva para obtenerlo y refinarlo.

1:

Dicha estrategia puede describirse de manera muy simple como sigue: Una vez teniendo un problema cuya solución fequiera de la experiencia de determinado tipo de personas (expertos), este problema se $k plantea para recolectafl las ideas o procedimientos que los expertos utilizan para resolverid. Con este conjunto de ideas y procedimientos recolectados, se implementa un primer prototit del sistema que resolvek el mismo tipo de problemas que el experto. Después se observan los resultados que el prototipo es capaz de producir, y si éstos no son satisfactorios a juicio del experto, con su ayuda se revisa, modifica o amplía el conocimiento que el prototipo contiene y nuevamente se observan los resultados que éste proporciona, y así sucesivamente hasta que el sisteha es capaz de resolver el problema correctamente.

De esta manera durante el proceso de obtención del conocimiento, y teniendo el problema ya bastante claro, éste se podría plantear de manera muy simple, por ejemplo:

, ,

'I

!I

II procedimiento que .dyes para obtener el esquema de o&s, e& ya yemias con el documento de

requedientos del sistema de iqfonnación? 1 1 1 1

No obstante se presentó el siguiente problema: así como en el capítulo anterior se explicó que, si se le pedía a N diseñadores obtener el esquema de una base de datos se podrían obtener ' N esquemas diferentes, ésto mismo ocurre cuando a N diseñadores se les plantea la pregunta dada arriba. Esto t d a como consecuencia el tener N metodologías y el correspondiente problema para unificarlas o extraer una sola a partir de todas ellas.

Para evitar el problema anterior, como primer paso se decidió reducir el número de diseñadores a los que se les '&fa plantear el problema a s610 dos o como máximo tres. A continuación se presentan a i g u k ejemplos de las pnmeb respuestas obtenidas ai plantear el problema, estas respuestas se yuestran aquí con el fin de ilustrar lo diferente que es la manera en la que diferentes personas abordan el mismo problema, y que no son totalmente consideradas en este trabajo.

I 1 II

I

Respuesta 1: G u h de tipo crltico

1.- Es necesario saber bajp qué recursos de implementación se puede desarroiiar el sistema

il Pág 65

I

Implementeci6n del sistema GERSl I/

I/ I1

~ I111

1 I/

ceplturo 4

II O

O

O

Identificar todos los dato: involucrados en los reportes.

Separar los datos que hap sido calculados a partir de otros.

Son candidatos a almacenarse en la BD los que no son obtenidos a partir de otros.

0 Separar los datos que se calculan. I 1 1 1

0 Agrupamiento de dato: en tablas. I

- I !I - I /I

Dar nombres Únicos a los datos.

Podrían agrupafF;e datos requeridos por cada informe (como un primer intento de agrupación de datos en tablas).

captura de los DE. - Para los DE un Iposible agrupamiento sería el identificador de los formatos de

Pág 67

caplruo 4 Implementacidn del sistema QERSI

0

0 Las llaves

Se pueden determinar las dependencias funcionales verificando si los DI de una misma tabla dependen de de la misma tabla, y,,éSto servirá para la 3a forma normal.

ELKA corresponden a los enlaces 1 a 1 y 1 a N.

I 1 anteriores, no tiene por objetivo poner a discusión simplemente'se desea ilustrar el hecho de que las

respuestas son diferentes en cad? caso y que cada respuesta dependerá de la persona a la que se le haga la pregunta ¿cómo p r i d e s para obtener el esquema de una base de datos, si ya cuentas con el documento de requerimientos del sistema de información?

En io que respecta a la validez de las respuestas, se encontró lo siguiente: en algunos casos un experto proponía alguna heurística para evitar o corregir determinado problema. Pero otro experto podía no estar del todo de acuerdo con dicha heurística y también contaba con algún fundamento para no estar de aherdo. Este tipo de problema lievó a la conclusión de que algunas heurísticas podían ser válidas k!~ algunos casos, pero no dn otros. La posición adoptada aquí es que si una heurística tenía vahdez para algunos casos, edtonces merecia ser tomada en cuenta. En lo que respecta al sistemaiGERS1, si alguna de dichh heurísticas podía ser implementada, bta no ocasionaría ningún problema, ya que el sistemaIs610 propone o sugiere, no obliga al usuario a cumplir dicha h e u r d a , es decir, el usuario puede considerar o no las sugerencias del sistema, pero la decisión final es de él. I

11 4.2 Representación del conocimiento

La representación de cbhocimiento es un paso importante para la mejor utilización de las ideas en un sistema compudcional. Existe toda unal teoría y formas de representar el conocimiento, entre eiias se plhen mencionar las siguientes, redes semánticas, marcos, regias deprodwcidn, "scripts', procedimientos, etc. Para may& información consulte a los siguientes autores: Rich (1983) y Rolston~ (1990).

Durante el desarrollo del sistema GERSI, el conocimiento se codificó principalmente mediante procedimientos y reglas de prodwcidn. Esta decisión se tomó basándose en el tipo de ideas sugeridas por los expertos. Estas ideas proponían acciones si se cumplían ciertas condiciones y por otra parte proponían procedimientos (y algoritmos) a seguir. Más adelante se presentan algunos ejemplos. 1

Representacidn pmcedimentql I '1 I

Durante la obtención dki conocimiento se adopta una metodología (Sección 3.3) para

P& 69

!

lmpIementeU6n del sistema GERSI IIE >

CBplUlO 4

I ' m Obtencidn del esquema de la base de daros

Este es el procedimiento principal que engloba todo el proceso a seguir para obtener el esquema de una base de datos.

I - Procedimiento i' MetodologiaPropuesta" 11 I 11 Etapa I! .,- Etapa 2' /- Etapa 3, .:- Etapa 4 .'-

Etapa 5' I .- Etapa 4 11- Etapa 8, 1- Etapa 9~ .- Etapa 10;-

I~

Etapa 6 '11-

1 1

Capturar datos (de, 0 entrada, salida e intermedios) del sistema de información Identificar los datos de la base de datos Asignar nombres únicos y tipos a los datos determinados en la etapa 2 Identificar las tablas de la base de datos Definir las tablas de la base de datos Optimizar el espacio'de almacenamiento de la base de datos

I/ Determinar las llaves primarias Determinar los enlaks entre las tablas Normalizar las tablas de la base de datos Generar el esquema de la base de datos

Durante la captura de daros ,I I is Una manera de ayudaval diseñador a establecer fas tablas desde la captura de'datos, es

que para cada dato deba indikk su pertenencia @asánddse en la definición de que un atributo da más información de una entibad), que en la mayoría d{ las veces (no siempre) indica el objeto (tabla) al que pertenece. Poi! ejemplo para los datos' "nombre del proveedor", "edad del proveedor", .y "dirección del ,proveedor", se están indicando "nombre", "edad", y "dirección", pero todos estos datos indican que se refieren al "proveedor"; de esta manera durante el análisis léxico y conteo de palabras se podría proponer a "proveedor" como un posible objeto. Así, una regla podría quedar de la siguiente manera:

I

- I I; IF dato de entrada NO contiene la paladkra DE o DEL THEN el dato bk entrada probablemente NO contiene información de pertenencia

IF THEN indicar'& usuario que el dato no contiene información de pertenencia

'I 1 1 ' ' IF - el dato de: entrada probablemente NO contiene información de pertenencia

jse captura el dato? (sh):

Las dos reglas anteriores valen para datos de entrada, datos de salida y datos intermedios 1 /I . $

P4g 71

capltulo 4 1 Implemeniación del sistema GERSI

I THEN palabra puede ser contabilizada como posible objeto (tabla)

- IF palabra tiene número de ocurrencias gmde THEN palabra puede ser propuesta como objeto (tabla)

- IF se desea proponer II una lista de objetosi I (tablas) THEN realizar ~l procedimiento IdentificaObjetos

"NomProveedor" "CHAR(3O)" "{Nombre del proveedor}"

- Procedimiento IdentificaObjetos

será el nombre del dato, será el tipo del datojy es el dato original que pasa a ser la descripción del dato. 1

t I

I

Detección de sinónimos , '.

Si existen dos datos 4" el mismo nombre pero descripción diferente, se tiene un sinónimo; y si existe un sinónimo, debe cambiarse alguno de los nombres para corregir este posible error. De aquf surgen %os reglas. ! iI" j

Pi4g 73

I

I l l

- IF Existe información mutuamente excluyente THEN Eliminar; alguno de los datos

Espacio no ocupado

Si existe una columna

i I1 I I Si existe una columna qfanumérica extensa que yntendrá información repetida, sería

conveniente crear otra tabla como catálogo que contenga s610 las ocurrencias de esa columna. La regla podría quedar de la siguiente manera:

II

:/I o alfanumérica extensa que en la mayoría de las veces (90%) quedará

i ~j 1

8 ,

P4g 75

Implmentacidn del sistema GERSI, I1 P

cep/tulo 4

su vez, están agrupados las cuales también son transformadas durante la normalización, y que finalmente proporcionan el esquema de una base de datos cuya calidad quedará sustentada por la metodología y los algoritmos que se utilizan.

Enfatizando aún más, durante el proceso de obpnción del esquema, siempre están

datos @E, DI, DS), se están mbipuiando datos; y cuando se les asignan nombres a los datos, se esta haciendo una transformF6n para identificar a los( datos iniciales mediante un nombre. Despub, cuando se quieren agnipar estos nombres en tablas, es necesario asignar datos a tablas, y cuando se da el proceso de normalización se hacen movimientos de datos entre tablas.

presentes la manipulación y I hnsfo~~nación de datos. Por ejemplo, cuando se capturan los

De lo anterior, podía infenrse que el sistema GERSI debía contar con un mecanismo para la manipulación de datos.

Por otra parte, tamblén se utilizó como herramienta de desarrollo el lenguaje de programación C+ + de Boridd, es decir, el paradigma he programación orientado a objetos.

De esta manera se llegó a la conclusión de que era necesario hacer uso de una de las estructuras de datos más conocidas para la manipulación de datos, las listas iigadas (Figura 4.1).

'I 1 I L ff-

Fii

Tabla 2

-

I'

Figura 4.1 Repmentacidn g r @ ~ de UM lista ligada que contiene información de tablar (aquema)

Nodb de la lista

.ii ! I, 'I1

Implsmentación del sistema GERSl capltulo 4

Cuadro 4.1 Definición de los registros para cada UM de las listar irnpkmentadm en el sisiema GEM1 I

I'

II P4g 79 '1

~p/ t lJ lo 4

Clase i i S M

! lmplmentad6n del sistema GERSI I1 11

I El objetivo de esta clase es poder operar sobre una lista doblemente ligada (Cuadro 4.2) utilizando memoria dinámid) que es la estructura Principal sobre la cual se basa la implementación del sistema (Skión 4.2). Algunas de las principales funciones miembros de esta clase son las siguientes: I '

I

LiSim I . . . Constructor de la clase LiSim, inicializa los apuntadores al inicio y final de una lista.

I1 I

-LiSim

cada una de ellas.

Destructor de la clase lista.

I !!

I

.iSim, libera el espacio en memoria asignado dinámicamente a la

I/ 1 Piíg 81

cspltulo 4 I lmplementecidn del sistema GERSI

Modifica un dato de la lista.

8 libera

Verifica si existe un dato' en ia lista.

Pdg 83

LeeDeDisco

I II Cepltulo 4 Implementac¡ón del sistema GERSI

despliegue en pantalla de columnas, tablas y enlaces. Esta clase hereda las propiedades de la clase LiSim, así que sus funciones [miembros se basan en las/funciones miembros de esta clase, y por io cual indirectamente operan sobre la estructura de la lista ligada. Además cuenta con una variable del mismo tipo del nodo de la lista, la cual se utiliza principalmente como variable común para intercambio de información. Entre sus principaled funciones miembros se encuentran las siguientes (Cuadro 4.3):

iI I, , I,

I/ 11 Cuadro 4.3 Implementacidn de la el&e BDOpera del sistema GERSI I

InsertaDato

' Jl Ill Inserta un dato en una lista doblemente ligada. Durante su utilización se toma la decisión de si el dato a insertar se I t a de un requerimiento, una tabla, una columna, o un enlace.Esta función miembro se basa en la función/ miembro "inserta" de la clase "LiSim".

BonaDato I lb Ill

Borra un dato de una lista ya sea un requerimiento, una tabla, una columna, un enlace, etc. Este función miembro se basa en la función miembro "borra" de la clase "LiSim". I I

Pág 85

cepltulo 4 1 ' 11 lmplmtmtecidn del sistema GERSI

I 11 Constructor de la clase Raton, s610 posiciona el Cursor del "mouse" en la esquina superior izquierda (1,l).

1 m mstatus

Determina la existencia de un "mouse" y el número de botones que éste tiene.

mshow ! II il

Muestra en pantalla el cursor del "mouse". I1

' 11 11

t

mhide

Oculta el cursor del "mouse".

mput

Posiciona el cursor del "mouse" en algún lugar de la .t pantalla indicada en sus parámetros. I

mpos II

Determina la posicisn del cursor del "mouse" y determina también si se ha presionado alguno de sus botones. I1 /I

mvlimit Ill il

Limita verticalmente el área del video donde el cursor del "mouse" puede moverse.

I

Clase portada I

El objetivo de esta clase es soportar el uso de portadas y menús de barras (con "mouse") para cada una las pantallas del sistema GERSI. Las funciones miembro de esta clase hacen uso de un arreglo para conservar el número de la Última opciód seleccionada de algún menú. Además hereda de la clase Raton todas sus propiedades. Esta clase no cuenta con un "destructor". A continuación se listan algunas de sus principales funciones miembro.

I Pdg 87

capltuio 4 Implementacibn del sistema GERSl

f / ! I 1

Esta rutina se utiliza principalmente para navegar sobre los menús y seleccionar alguna de sus opciones.

D MouseEnMenu 1, I1 I Determina si el cursor del ,;mouse" se encuentra derfro del espacio en video de alguna

both del "mouse". I

de las opciones de un menúi. 1 1 Esta función miembro se,activa cuando se ha presionado un

' I

MenuConMouse

Permite el soporte del "mouse" para seleccionar de las opciones de un menú. 1 ril

Menu I1

Traza una portada para un: menú y permite seimionar alguna de las opciones de un menú, ya sea a través del '*lado o de un "mouse". ~ ' '

/ I ( Relaciones de herencia entre las; clases ,411

Las ,relaciones de herencia entre las clases mencionadas son las siguiente: * I - La clase portada hereda las lpropiedades de la clase ?ton, ya que en la clase poriada se

implementan las portadas "mouse". I1

menús, pero los menús se pueden utilizar mediante un

- . La clase BDOpera hereda las propiedades de las clases poriada y LiSim, dado que las diferentes etapas para obteTer el esquema de una b+ de datos se hacen a través de pantallas con menús (que pueden operarse con un "mouse"), pero todas las operaciones con los datos se hacen sobre fistas ligadas. II

- Finalmente ¡a ya se explicó), se a los diferentes m6dulos o concephial, '.hace uso o @or decirlo de otra

manera), hereda las'propiedades de todas las clases anteriores para implementar su objetivo propio.

Todas las aplicaciones tienen esta misma reiaci6n'ide herencia; es decir, todas las aplicaciones se basan en las clasks ya descritas, y la implementación de cada módulo, de la arquitectura depende de * cómo-las utiliza . "I. cada aplicación. Tod& . ./ las clases son idénticas para cada

Pág 89

i mi

I

I

capltulo 4 ' ! lmplmentad6n del sistema GERSl

contenidos en la lista. Más tarde estos nombres pasan a ser los datos candidatos. En este mismo módulo, también el usuario puye'i dar los tipos de los dad! candidatos, y tanto los nombres

w Identificación de las (tablas) de la base de datos

como los tipos de los datos quedd en la lista. I1 I

Se mencionó ya en el Capítulo 3 que la obtención de las tablas de la base de datos se obtendría mediante un análisis léxib. Este análisis se real¡¡ sobre los datos fusionados, leídos de un archivo y guardando sus res111tados en una lista sobre la cual el usuario podrá operar, por ejemplo, para eliminar o agregar tablas. I / I 1 rn Análisis léxico ' I

Este proceso se basa en lal,lectura de disco de cierta información, la cual se compara inmediatamente con un conjunto de palabras contenida en este módulo, de tal manera que, si concuerda con alguna de ellas, éstas son discriminadas, o en caso contrario la palabra se almacena en una lista donde se va contabilizando su número le ocurrencias. Finalmente, de las palabras que queden en la lista,/ ke seleccionan las de mayor número de ocurrencias, para proponer el 25 % de éstas como posibles objetos. Este proced, como puede observarse, es parte de la Etapa 4. i 1 -

Asignación de datos a tablas

Este módulo utiliza dos list&: en una tiene los nombres de las tablas, y en la otra, los nombres de todos los datos; de tal' manera que el usuario puede operar en las dos listas para seleccionar de la lista de datos, 185 que correspondan a ca4 una de las tablas que están en la otra lista. Cuando el usuario sele&ona un dato para una tabla, el nombre del dato se inserta en una sublista del nodo de la lista & tablas; es decir, durand este proceso la lista de tablas se convierte en una lista de sublistas, en la que cada tabla (nodo de la lista) tiene asociada su lista de datos (ver Figura 4.2).

i l b Determinación de llaves 9 ,I

I , : J j 41 Este módulo es muy p*fo al de "Asignación de datos a tablas", dado-que la llave

primaria de una tabla estA formada por columnas; así que do se explicará más, dado que las operaciones sobre la lista son i d mismas que en la etapa mencionada; ~510 cambian las condiciones bajo las cuales se realiw dichas operaciones. .,

1, I

I !

PBg 91

cepltulo 4 " lmpitnnentecidn del sistema GERSI

propio conjunto de reglas y procedimientos y por lo tanto su propio conjunto de explicaciones.

En lo que respecta a la implementación, las reglas de producción se irnplementaron como if s, mientras que los quedan expresados como funciones del lenguaje C.

I Explicaciones

Las explicaciones en el sistema GERSI quedan implementadas como mensajes que el sistema muestra s610 a petición del,usuarío. Durante el proceso de obtención del esquema de una base de datos, el sistema toma decisiones y ofrece al diseñador una explicación de lo que hace, si éste acepta la explicación, el sistema instancía la explicación con los datos correctos y la muestra en la pantalla (el Capítulo 5 muestra ejemplos de explicaciones que el sistema proporciona). Las explicaciones $mbién están presentes cuando el diseñador desea hacer algo que no es válido, primero el sistema le advierte al diseñador'que algo anda mal y le ofrece una explicación ("Desea una explicación? (SIN): "), nuevamente si el diseñador acepta, el sistema instancía la explicación con los datos correctos y la muestra en pantalla.

I1

I Interfaz hombre-máquina

La interfaz hombre-máqui(a está basada en una serie de menús que vistos de manera secuencial, describen paso a pasolla metodología propuesta! Cada opción del menú principal conduce a una pantalla que también contiene un menú con el que es posible operar sobre los datos para irlos transformando hasta obtener el esquema. También en cada etapa el sistema solicita al diseñador la información que necesita y muestra mensajes y explicaciones acordes ai proceso en turno. En cada opción del menú el diseñador puede ver el estado actual de los datos dinámicamente, es decir, mientras el usuario opera sobre los datos, dichos cambios están siendo reflejados en los datos visibles en la pantalla.

4.5 Recursos de implementación

El sistema se desarrolló utilizando el paradigma de programación orientada a objetos, ésto a través de la versi6n 3.0 de C++ de Borland para DOS. El desarrollo se llevó a cabo en una computadora personal SX 386 con la versión 5.0 del sistema operativo MS-DOS.

I 11 /I

I 1 1

! j !I1 I'

I I/

Pdg 93

*eta de crédito o al recibir el artículo pedido.

Entre los requerimientos jpueden mencionarse los siguientes: el sistema basado en el esquema que se genere debe incluir las órdenes de los clientes, debe permitir llenar órdenes desde el almacén, monitorear cantidades del inventario y actualizar información de los anuncios de las revistas para poder reemplazarlos por anuncios nuevos.

/I i i

1

1

Arranque del sistema GERSI 111 /I

Unicamente debe teclearse GERSI desde la línea de comandos de DOS, después de lo cual aparece la portada principal del sistema (Figura S.l), y después el menú principal (Figura 5.2).

I I t I/

I

I Figura 5.1 Portada del sistema GERSI

I 'I El menú principal del sistema GERSI, de la opción 1 'a la opción 10 refleja los pasos de la metodología propukta, y p q odtener un esquema deben-rkrrerse todas estas.opciones. La opción 11 pehite ai ,usuario &ir temporalmente ai sistema ope&tivo y d&pués continuar , i: il

i (Figura 5.2).

i

..,.

, ,

Capturn de datos I 1

Esta etapa tiene un submen) para la captura de los *os de e n h a , datos de salida y datos intermedios del sistema de información, los cuales deben ser obtenidos del documento de

"I 1 1 a!

I Pdg 95

i

,/ ,I

P8g 97

I Pruebes de iuncionalided

11 I’

I I CepRulo 5

I Figura 5.5 Estabiechfo las dependencias de los d o s de salida 1 1 1 , t

I IAaxpUue i60 t I I I

I 1 1 -Lad&-- I I I

\ I ‘ I Figura 5.6 Explicaniio por qué no es posiblefilionar los datos

. ilL

I . ¿!

ii I

... :* <

.., 1. . ..<

v ..

P.4g 99

I G7pítulo 5 Pruebes de fufldofl8fidüd !

1 'P . LOS datos BANDERA DE AUTOMOVILISTICOS y BANDERA DE EQiJiPo DEPoRTlVO por un solo identificador de tipo

CLIENTE y NUMERO, DE TELEFONO DEL CLIENTE, ambos podrían identificar a un cliente, así que podría eliminarse IDENTIPICADOR DE UN CLIENTE

denotan tipos de éstos podrían ser de artículo, por D e ARTICULO. . LOS datos

y dejar d 0 a NUMERO DE TELEFONO DEL CLIENTE.

El dato BANDERA QUE rNDicy COBRAR AL MOMENTO DE ENTREGA, no es necesario ya que podría suponerse que si no se cuenta con el número de tarjeta a la cual se cargará la orden, entonces la orden &I cobrada al momento de la entrega.

Como puede no s610 el evitar homónimos, sino que también'se trató de Sección 3.3 pueden verse más detalles acerca de este tipo mostradas pueden corregirse en la etapa de captura. En el de datos ya corregida con sus respectivos nombres y tipos.

I 11 , m

I 1' ii Cuadro 5.2 Dalos Fusionals y sus tipos después de rentoy? redundancias

II Pruebas de funcionadad ii ' . ,I.~

I " caplulo 5

I .!I: .I).

Figura 5.0 Erplic<lo como se proponen lar tab&.

, 'I

I :I '1 I i

Para esta etapa el usuario que no sepa completamentehda sobre diseño de base de datos, puede basarse en las definiciones de entidad (tabla) que es un objeto del cual se desea guardar

un elemento (tupla) de una entidad los atributos que la

no es defmitiva, y si el usuario etapa de normalización donde se

al final de esta etapa, es que todas

se equivoca, siempre podrá verificará que cada atributo

y es en

La única las tablas tengan atributos y que,;todos los atributos hayan sido asignados a alguna tabla. El Cuadro 5.5 presenta un ejemplo de atributos asignados a tablas.

' ,

I Asignacidn de lbves a iablas

en el sistema GERSI, el usuariolencontrará en la ventana superior cada una de las tablas, y en la ventana inferior aparecen los athbutos correspondientes acada tabla, lo único que el usuario debe hacer es seleccionar de edtre los atributos los que considere que son parte de la llave primaria para cada tabla.

1/ En esta etapa el usuario las llaves primarias a ?da una de las tablas. Nuevamente

, ,

Pbg 103

capftu/o 5

'1 I

Figura 5.9 Erplica la etapa anterior quedd inconcha I1

Pruebas de funaónalidad

mayor de 80 caracteres. Como selexplicó en la Sección 3.3, se trata de optimizar el espacio de almacenamiento de la base de. datos. Así que automáticamente se detectan estos campos y se pregunta al usuario si desea optimizarlos dando las explicaciones correspondientes.

Para el ejemplo presentado aquí no existe ningún campo alfanumérico cuya longitud sea

No obstante podemos simular esta situación a fin de ilustrar el comportamiento del sistema, aunque estos resultados no¡ sean considerados en etapas posteriores. Suponiendo que el atributo DIRAD de la tabla REVISTA tiene una longitud de 90,caracteres. Las Figuras 5.10 y 5.11 muestran las explicaciones durante esta etapa de optimiyción.

Como resultado de la optimización, el sistema crea automáticamente una nueva tabla (TABDIRAD), a la cual ie inciuyejei campo DIRAD y ie c& una iiave CVEDIRAD, ia cual además sustituye en la tabla REVkTA al campo DIRAD. Este proceso se repite para todos los campos alfanuméricos que encuende con Iongitud mayor que'80 caracteres, aunque siempre es el usuario quién decide si se optikza o no.

mayor de 80 caracteres, es decir, no es necesario optimizar. !

t 'I 1 ' I

6 . 11

1 I : Genemción de enlaces I

En esta etapa el sistema GERSI puede proponer automáticamente los enlaces mediante'

~ Pdg 105

1 :

i :

CBpltuIo 5 I ” Pruebas de funcionatidad ,I I/

Figura 5.11 W i i c a h porqué se p u d e oprimiuir (2‘ pane) I !

I

Figura 5.12 por qué no se puede dar de alta un enlace

Pruebas de fumhnefidad

I EAQON t

i

Figura 5.13 Menú ponnalizacidn

I !.

I I '! , .L

I !I Figura 5.14 No p u q e esfablecer las dependencias df los dafos de enfrada

I

i

P

Pdg 109

cepltulo 5

figura 5.16 Estoblehdo las dependencias de los dnros de enrrada

I li i

normalización. Por ejemplo, no permitirá normalizar en la 2a 6 3a forma normal si aún no Se ha normalizado en 1 a si no se ha normalizado en la normal.

es decir, no permitirá normalizar en alguna forma normal normal anterior, por supuesto a excepción de la l a forma

algunos detalles del comporhmiento del sistema GERSI iI A continuación se durante cada una de formas normales.. 11

!I

Primern forma normal i , . , ,

Como se mencionó en !el párrafo precedente, el sistema GERSI cuenta con la implementación del algoritmo de normalización presentado en la Sección 3.3. Una vez que el diseñador selecciona la opción /";INF" correspondiente a ,la l a forma normal, el sistema automáticamente y como lo ilusU#el algoritmo, hace un recbmdo por todos y cada uno de los atributos de todas tablas exceptuando las llaves primarias. EA este recomdo el algoritmo y con ayuda del diseñador, verifica quflcada atributo cumpla la dndición de la l a forma normal. Tomando en cuenta que en esta etapa el diseñador ya cuenta con las llaves primarias de cada una de las tablas, la condición que debe cumplirse es la siguiente:

~

Para cualquier registro de una tabla, cada atributo debe tener uno y s610 un valor I

Pdg 111

Pruebas de funcioneliad

!! I

ca~tlllo 5 I

PIUebsS de f~~t~c~bnaiidded

5.19 sería: "Para cada registro en tabla REVISTA".

el tabla REVISTAFECREV cuántas ocurrencias habrá en la '11 ,lb II 1s

I caplulo 5 Pruebas da funcioneldud

I I II a la existencia de un enlace N a M.

'1 Resumiendo, el proceso delnormalización 1 'I aplicado a' las tablas del Cuadro 5.6, es el

siguiente: I I

I1

Pdg 115

cepltulo 5 huebas de funabnafided

REVISTAFECREV. ~n este d o NOMREV no estaría enlla 2 a forma normal, porque dio depende de CODREV, por lo d t a tendría que ser eliminado de esa tabla, y debido a que el mismo atributo ya se encuentr$en la 2a forma normallen la tabla REVISTA, debería establecerse un enlace entre las tablas REVISTA y REVISTA-FECREV, pero este ya existe como resultado de la 1 a forma nohal. De esta manera d10 sería necesario eliminar el atributo NOMREV de la tabla REVISTAlFECREV.

I I

Tercena forma n o d

Una vez más, el proceso normalizar en la 3a f o e normal, como ya se indicó en la Secci6n 3.3, es el mismo que ha explicado para la l a y 2a formas normales. Y también lo único que cambia es la condicibn que deben cumplir todos los atributos exceptuando los atributos que formen parte de la llave. La condición para la 3' forma normal es la siguiente:

Cada atributo que no es Uade NO debe depender de otro atributo que no sea Uave ~'

P4g 117

cepltulo 5

Phg 779

Pruabas de funmbnalidad

Capftulo 5 I

NOMREV CHAROO), TELINP CHAR(U),

PRIMARY KEY (CODREV) 1

NOTARCRE CHAR(16). i

,,

TELCLI CHAR(I2). PRIMARY KEY (NOORDEN)

( NOMTAR CHAR(20). NOTAR CHAR(Ió),

PRIMARY KEY (NOTAR) )

) I FOREIGN KEY ORDEN(TELcL1) REFERENCES CLIENTE(TELCL1)

# Creando la t a b PROVEEDOR CREATE TABLE PROVEEDOR (

CODPROV CHAR(@, DIRPROV CHAR(@), NOMPROV CHAR(@).

I

/I

PRIMARY KEY (CODPROV) , 11 )

'/I

I Creanda la tabla PROVEEDOR-ARTIdhO

I I iIIi CREATE TABLE PROVEEDOR-ARTIC~O

CODPROVCHAR(@, 1 ii NOART CHARO, I

PRIMARV KEY (CODPROV, NOART b

'FOREIGN KEY PROVEEDOR-ARTIC+O(NOART) REFERENCES ARTICULO(NOART) FOREIGN KEY PROVEEDOR_ARTICUU>(CODPROVl REFERENCES PROVEEWR(CODPR0V)

I C d o Ii iabü REVISTA CREATE TABLE REVlSTA 1

I

( CODREV CHAR(4), FECREV DATE,

PRIMARY KEY (CODREV, PECREV) ) I '

END MAlN

Pág 727

huebas de funcionatidad capftulo 5

*BANDERA DE iQulPO DEPORlNO *COD100 DE U TANETA DE CREDIT0 T O W R DELARTICUW VENDIW *DESCRIPCION DELARnCUW ANUNCIADO

Lita de posibles d a w !

11 .BANDERA DE ARTiCUWS AUiUMOYIUSllCOS *BANDERA QUE INDICA COBRAR U MOMENTU DE PFlREOA

COMPRAR *NOMBRE DEL CUENTE

I 'I *NOMBRE DEL PROVEEWR .NUMERO DE DIAS DESDEQUE LA ORDW FUE -ADA . N U M E R O D E O R D E N E N E N O U E A P ~ E E L A R n C U W *NUMERO DE U TAPJETA IIIIFNTA , /

LA QUE SERA CARGADA U _ _ _ ... *NUMERO DE ORDEN AUN NO REcIBlDA POR ELCUENTE .NUMERO DE -NO DEL CUENTE 'NUMERO DErrLEWNO PARA INPORMACION DE ANUNCIOS VESO DEL ENVIO DELAmCUW VENDIW

.PRECIO DE VENTA DELARllCUW VENDIDO *PORCENTAIE DE cmim DEL c u m

Rquenmicntos:

El esquema de la base de datos debe incluir lo siguiente: i

Dar nombrui y tipos a los datos (abibutos) Decidir que tablas formaran p h y del esquema Defuiir las tablas wn su8 atridutos Definir las llaves primarias dd &da tabla Determinar los posibles enlac&i/atrc Las tablas Normalizar Obtener un esquema de la base I datos expresado en SQL

I

i , 1)

Procedimiento

Para realizar la prueba se procedió de la siguiend manera: II - Se seleccionó a un grupo de 6 participantes con las características mencionadas

anteriormente. I

I1

Pág 123

PIuebes de funcionalidud. I ceplhrl0 5 .. z

'I

PARTICIPANTE No 2.

Perfil - Edad:

- Profesión: 25 años

I: It

Lic. en informática

Estudiante

Metodologia ELKA

DOS cursos de bases de datos a nivel maestría

- Ocupaci6n actual:

- Herramientas de d i d o que conoce

- Experiencia en diseño:

Esquema

COD-TAR CHAR(z0). ID-CUWie C W I I ) . PRIMARY KEY (COD-TAR, lD_CUENTEJ 6

)

P.4g 125

CREATE TABLE ORDEN (

NUMERO-om FECHA DA? DIR-ENTRE0 CHAROO). BAND-coB_ENTR ¿+it PRIMARY K E Y W - O R D . lD_CUENT!3

) I Nil !I

FOREIGN KEY ORDENGD-CUENlEJ R a E R M C l CUENTFOD-CUWm

CREATE TABLE ORDEN-ENTREGADA I

NUMERO-ORD NUM-DIAS PRIMARY KEY0

)

D$lMAL

I DECIMAL

CPEATE TABLE ANUNCIOS

pruebas de funurnatidad

PARTICIPANTE No 4.

Perfil - Edad: 33 años - Profesión: Lic. en computación - Ocupación actual: idvestigador

- Herramientas de diseño que conoce: Metodología ELKA, Microsoft &Cess

- Experiencia en diseño: Ha hecho dos diseños de bases de datos

I/

Esquema

CPEATE TTI-5 ARTICULO (

AFT-ANUN-DBCR W W . ART-ANUN-ID I m E R AFT-COLOR W W . ART-PESO M A T . ART-PRECIO M0NEYíS.Z). - m u IN7F.GER

PRIMARY KEY (ART-ANUN-ID) )

II CREATE TABLE ARTICUWORDEN (

ART-ANUN-ID INTEGER ORDEN-NUM-NR IKI)%ER

PRlMARY KEY (ART-ANUNJD. ORDEN-NUM-NR) )

Pdg 127

pruebes de funeionalidad cepltulo 5

, I!,

Esquema 1

CRWTE TABLE INVENTAlUO

CREATE TABLE PROVEEDOR (

WE-PROV. NOMBRE DIRECCION. PRIMARY KEY(cve-PRoY)

i II )

Mnd M mba ( I a N) de INV_PROV n PROVEEDOR I

CREATE TABLE INV-eROV I/

( 1 II

) 1 111

CVE-ART.

PESO_ORDEN. CV-PROV.

P W Y KEY(CVE-ART, CVE-PROW

CREATE TABLE ORDENES (

CVE-ORDW. CVE ART

CVE-ART,

CRPAlZ TABLE CU- (

CVE-CUENTE NOMBRE. I DIRECCION. I T F L W N O . PRIMARY KEY(CVE-CUENlD ,

)

CRUTE TABLE TARJETA-CREDITO 1 (

CVE-CUENTE I

CVE-TAWA. nm. u m - c R E D i T O PRIMARY KEY(CVE-CUWre. CVE-TANETA)

)

CREATE TABU ANUN-REV (

CVE-REV. ?E-ART. CVE-PROV. NOMBRE FFCHA_PMISION. PRIMARY KEY(CVE REV, , CVE-ART. CVE-PROW

PARTICIPANTE No 6.

Perfil - Edad:

- Profes\6n:

- Ocupación actual:

- Hemhentas de diseño que conoce:

- Experiencia en diseño:

30 años

Lic. en informática

Investigador en el iiE

Metodología ELKA

Ha hecho dos diseños

Esquema

CRUTE TABLE ANUNCIOS ( 11

cwAm w n . CVEwv w n . F E C W DATE, PRIMARY KEY (CVEWi. CVEREV)

)

FORBON KEY ANUNCiOS(CVE4Rl) REFERRiCES

FOREIGN KEY ANUNCIOS(CVEREV) REFERENCES REVISTA(CVEREV)

Aml cu ID( c v FA RTJ

Pdg 129

Cepltu0 5 Pruebm de íunaonelidad

1 U!, I1

Anáüsis de los resuliados

Los resultados fueron pyntados en desorden, de tal manera que los dos grupos, el primero de los cuales obtuvo el esquema sin utilizar alguna herramienta y el segundo que obtuvo el esquema utilizando el sistema'iGERS1 son los siguientes,;

I dl 11

Grupo 1: No utilizó el sistema GERSI Grupo 2: Utilizó el sistema GERSI I

ParticipanteNo. 1 Participante No. 3 ParticipanteNo. 5 1

,I barticipante NO. 2 Participante No. 4 Participante No. 6 1

lr Comentarios del experto NO.,1 1

les asignó una calificación dentro de una escala de 1 a !O. Las calificaciones se muestran a continuación:

I

Los resultados obtenidos II por los participantes fueron revisados por expertos, uno de ellos

1

Calif. para el esquemal No. 1 = 8 Calif. para el esquema No. 2 = 5 calif. para ei esquema No. 3 = 9 calif. para ellesquema NO. 4 = 9 Calif. para el esquema No. 5 = 3 Calif. para el esquema No. 6 = 9

Algunos de sus comentarios para los esquemas son los siguientes: I II IF

I II II 11 I

I t

Participante No. 1

- Podría incluirse el atributo color en la tablas pedidos.

proveedores I

- Un artículo puede ser,$urtido por varios proveedores, entonces falta una tabla que relacione pedidos y proveedores y también faltaluna tabla que relacione a artículos y

No está normalizada la tabla de pedidos - I1 1 111

Participante No. 2

- Le faltan dos ligas importantes

La tabla proveedor no se asoció con artfculos - La tabla de órdenes nol/se asoció con clientes

I i, -

Participante No. 3

Pdg 131

Pruebes de funcionalided Cepltulo 5 I1 ,b

Participante No. 2:

- Datos mal ubicados: 1 ;;, O - Tablas no normalizadas:, 0 - Errores de enlaces: - Falta de enlaces: 3 - Falta de enlaces: - Otros errores: I l l o 11

Calificación de estructura: 8 Calificación de correctez:

, - Datos faltanies:

' 11

I Participante No. 3:

-Datos mal ubicados: 1 2 - Tablas no normalizadas: 2

- Otros errores: O

Calificación de estructura: 6

- Falta de enlaces: II I 1

1 II

Participante No. .4: 1 :, li - Datos mal ubicados: ! 11 ' 5

- Tablas no normalizad4: O 1 - Falta de enlaces:

- Otros errores:

Calificación de estructura: 7

~ .'I . 1 ?

, ,I

I1 Participante No. 5: 1 '11

- Datos mal ubicados: O - Tablas no normaliza+: 1 - Falta de enlaces: 1 - Otros errores: 1, 1

J /I Calificación de estructuh: 7

I I1

3 O .O

8

- Datos faltantes: 1 - Errores de enlaces: 2 - Falta'!de enlaces: O

Califi&ón de correctez: 7

1 - Datos faltantes:

- Falta de enlaces: 3

'11

- Erroks de enlaces: O I/

Calificación de correctez: 8 I/

11' - Datos faltantes: 7 - Errores de enlaces: 3 - Fald de enlaces: O

I/ Ill

'I

Calificación de correctez: 5

I1

PBg 133

, ii I/

I Pruebas de funcionelidad cepltulo 5

Tabla 5.1 Emluad6n de nsuUad0s obtenidos cvn y sin el s h t q GERSI ~ '1 i/

sistema GERSI

sistema GERSI

'1.t /i !I

I

III I,

h

P& 135

propuesta, y cuya finalidad es verificar los resultados que ésta proporciona.

El sistema GERSI permite en la etapa fuial generar el documento del esquema de una base de datos, expresado kn SQL, y además un documento con la descripción y tipo de todos los datos de la baselde datos.

En las pruebas realizadasi'/al sistema GERSI se comprobó a juicio de expertos que las personas que utilizaron el sistema obtuvieron mejores esquemas que las que no lo utilizaron (Sección 5.2).

Se utilizó exitosamente el paradigma de programación orientada a objetos (PPOO) durante el desarrollo del sistema GERSI y teoría de bases de datos.

Se cuenta ahora con un conjunto de clases que podrían ser reutilizadas por alguna otra

4l rn

. 1 ' Jj .

t . aplicación (Capftuio 4 y Apéndice). II

6.2 Trabqjos futuros ' 11 I

Prácticamente todos 10s;trabajos en computación son susceptibles a ser ampliados o mejorados. Este trabajo no es la excepción y presenta varias opciones de mejora, muchas de las

A continuación se pmytan algunas opciones delmejora al presente trabajo. Estas se clasifican en mejoras a corto plazo, las cuales no involucrarían una carga excesiva de trabajo o de investigación, y las mejoras a largo plazo que bien podrían justificar nuevos temas de tesis.

I 1

I II cuales podrían justificar nuevos 1 temas de tesis.

I1

t Ill

. El sistema G W I podría ampliarse para que pueda cubrir las otras formas normales (BCNF', 4NF y 5NF). II II . Dado el gran auge quel, ha tenido el ambiente gqfico de Microsoft Windows, podría actualizarse la clase portada del sistema GERSI para que su interfaz quede bajo Windows. I, I . Una de las etapas que podría 1 r i llegar a ser laboriosa'durante i/ el uso del sistema GERSI, es la alimentación de los datos obtenidos del documento de requerimientos del sistema de información en la primera etapa: Etapa de captu? de datos. Una opción para evitar que esta etapa llegue a ser laboriosa, es la siguiente: Si el usuario del sistema GERSI cuenta

Pág 137

Conclusiones CepRUlo 6

EI p p o o y las esmctud de datos utilizadas agilizaron la implementación del sistema 'GERSI. Por ejemplo se pÚdo reutilizar software, al[implementar un gmpo de funciones o clases para manipular información en una de las etapas del diseño, y bajo el paradigma de PO0 las mismas rutinas fueron reutilizadas en otras etapas del diseño. No obstante, probablemente no hub id sido necesario impleme$ar dichas funciones si se hubieran aprovechado las ventajasibe un manejador de bases de datos, para deswgar en él todo el manejo de información.

Desde este punto de vista, podría recomendarse para trabajos futuros agregar como herramienta de desarrolld un manejador de bases de datos.

Otra observación no menos importante durante el desarrollo de este trabajo es la siguiente: el sistema GhRSI no pudo ser presedtado formalmente como un sistema experto debido a que, en (algunas de las etapas del diseño, el comportamiento del sistema todavía depende de lo que el usuario haga; por ejemplo, el sistema ya teniendo las llaves primarias podrá propoik automáticamente en Uha etapa posterior cuáles serán los enlaces, pero no puede proponer las llaves primarias, ésto es aún decisión del diseñador. Problemas como el menhionado caen dentro del á)mbito del procesamiento de lenguaje natural, y aunque aquí se realiza un análisis léxico, no se profundiza en esta área que queda fuera del alcance de este trabajo.

111 I,

P I

'I 1 Sin embargo, mediante la obtención de más heurísticas, se propone que el sistema GERSI sí podría ser presentado !formalmente como un sispma experto.

!i

P6g 739

Referencias

[FEIGENBAUM, 1977

[FEIGENBAUM, 19821

[FEIGENBAUM, 19831

[GEVARTER, 19821

[GUPTA, 19941

WAYES, 19831

[HOGAN, 19901

[HSIAO, 19911

[INGLE, 19791

WOSHAFIAN, 19901

~ [KORTH, 1987

FeigLnbaum, Edward A. ' h e Art of Artificial Intelligence: Themes and Case Estudies of,Knowledge Engineering". In UCAI 5 , pp. 1014-1029. , , I j

' I

'I

Feigenbaum, Edward A. "Knowledge Engineering for the 1980's". Compu~rs Science Dept., Sdnford University, 1982.

Feigenbaum, Edward A., ,'McCorduck, Pamela. "La quinta i genkraci6n". Planeta. t , . , , 'I

Gevarter, William B. "The Basic Principles of Expen Systems". Exbrpted: from: An Overhew of Expert Systems. National Budeau of Síandars Report #fNBSIR 82-2505. National Technical Infhnation Center ISocu@t # PB83-217562. (Referencia ext)aída de Raeth, 1990).

G$pta. "SQLWindows 5, 'Quick and Powerful Client/Server Development System". U.S. A.

Hayes, Roth. "Building ?&pen Systems". Addison-Wesley Publishing Company, Inc.

Hogan, Rex. "A Practical Guide to Data Base Design". Prentice- ',Hail, Inc. Englewood Cliffs, New Jersey

H. Hsiao y M. Evens, "DBSGen -- Database Design and Development System". Proceedings of The Fourth International Cbnference on Industrial &I Engineering Application of Artificial Inklligence & Expert System, The University of Tennessee Space Institute (UTSI), Koloa, Hawaii, Jun. 1991, pp.491-497.

Inglis J. David. "Distribution Data Base Design". EPRI EL-1 150 vol. 1. Electric Power Research Institute. Palo Alto California

1 I I

"I1 iI

.II. .lb

'I1 ,I)/

!I 94304.

Khoshafian, Setrag y Abnous, Razmik. "Object Oriented Concepts, Gnguages, Databases, Use: Interfaces". John Wiley & Sons, Inc. New York

Korth, F. Henry. Silberschatz, Abraham. "Fundamenros de Bases de Datos". McGraw-Hill. Co., U.S.A.

'I I1

Pbg 141

Apéndice ,; '!

.1!11.

'1

II

II

Listado del código I del sistema I GERSI

A continuación se prdnta un listado con una selección del código más importante del 11. '1' sistema GERSI.

int opcion;

I1 DBOpcn: Rognrm dc aplicacion. quo implcmcnis 11 bs wind&(1,1,80,2(); / I opcncionci iobrc la cipliin de loa datas do c/nda. ulidi c

/I tcsnsol~,r(wHm,

Yinoluds 'spoi(.d..hpp' cpnnll('\n\r\n\r >>>>>>> E i a p l y 2 üinsludc 'cmcMr.hpp' I1

EIRE@;

I1 inicmdios tcxtbackgmund@LUE);

üinslude 'cMopcn.hpp' x.~cn~,~ConCusdmSimplc~,2,79,24, Taptun de Datos');

< < < < < < h\rh\r*h cp"ntf(l\n\r 1.- CAPTURA de los datoa de SALiDA'); cpnntr\n\r 2.- CAPTURA do los &toa de ENTRADA"); cp&í(%\r 3.- CAPTURA de los &tos IKTERMEDIOS'); cpnntr\n\r 4.- Salida icmpml a DOS'); cpdntf('\n\r 0.- Salir*); cpnntf('\n\n\n\r Opcion: '); cin > > opcion; WiadOW(l, 1, 80,Z);

I1 MinArch F; portada x; eupal BDOpsn Da; 11 objeto pan openr en Datos dc &urn& SoopCra Ds, I/ objeto pan opcnr en Datos dc Salida B o g C r a DI; I1 objeto pan opcnr sob= los datos intcmcdioa inl rqa ldo= I;

11 objeto p i n mutejar archiv- 11 objeto pan desplegar pintall+ y mew6 de la

char ss<lucrm[30]; ~Nrn(opci0n); )

int cispas120 (

PBg 143

'! !I

I / Dñüpcn: Rograma de aplicacion. quo implementa lea ' ''

/ I dcpcndcmiai de loa d a m da entrada, salida C intermedios

#include 'dbdopcra.hpp' #include 'dporuida.hpp" #include "manar.hpp'

pNda I;

BDüpcn DE; // objeto pan openr en Datos de Entnda BDopen DS; I1 objclo para ~ p c n r en Dalos de Salida BDOped DI; // objeto p a n operar sabn los datos intermedios BDCQCd copia;// objeto p a n operar sabre los datos intemisdios BWpcn AS; // Dam de mlida iin ami idos B o g c r a AI; // Dam inaemisdiw sin aaochdw BDOped SI; // Dami inlcmdioa supernuor (que no han sido asignad+) ñDCQCn SE; I / Datos de enirada superfluos (que no han sido anignsdoa) B W e m FUE; / I objeto pars coiitemr'ls fusion de DE, DS y DI MinArch F;

I . '1

4 I/ objcto pan dcaplcgar panullis y menus de la

etapal ;

l / objeto pan Mmjar archivos

int respaldo= I; char esqucmal30);

I1

in1 etapea120

in1 opcion; (

window(l.1 ,SO.ZS); 0lnCIQ;

. . ,

" 9 .. ,

Pág 145 .J<

;.a . , I

!i Listedo del c6digo del sistema (IERSI ~.

. . . j . . . . ..

... . Apéndice

_._. ifCDSaD1.r P 1) DI.CopiiADidO(Mmbra.tipo)i

cprintf('\n\rRespaldo term¡nadO. FTedOM R E ~ ~ J R N para continuar...');

41: / I Busca cn R los dama sin asociados y los deja en S int BuacaDatosSinAsociados(BWpcra8tR, BDOpera &S) (

char nombre[951; id huboDatos=O;

R.Com¡cntcAFinO; Ilsctualiuir el apunlador a final de la lista

S.inicio=S.libcra(S.ini~¡~); // por si hubo ai& cambio R.CorrienteAlnioio0; .ij if (R.eorr¡cnic != NULL) 'I while(l) I

( II . if(!R.TieneDaosAsocisdos(R.eomentc))

,I R.DamcNombraComcntc("ombrc); S.InscrtaDatoDirac(no~b~); huboDatos= I ; /I si hubo datos sin asociados

(

I1

) ,:

if(R.corricntc = = R . f i ~ l ) b d t : R.AvanuiComicnIe0; 1

relurn(huboDa1os); I

!I in1 hub?Dauii=O;

D.ConCcnteAF¡nO: / I acuialuar el apunlador a f i ~ l do la lilts D.ComenteAúiicioO; S.inici~=S.liben[S.iNc¡o~// por si hubo a w n cambio

D .DameNombraComente(nombn): if(!DI.NombraEala@I.~~c~o, nombra) Brdr

!DS.NombraEsia @S.inicio, nombra))

s.uiscmDamDirac(nombra); huboDams= I ; / I si hubodamsminasociados

(

) il@.codcntc == D . f i ~ l ) breat; D.AvamComenwO,

11 ) rewm(huboDams); ) J

void UdDamsO

in1 huboDS, huboDI; in! huboSE, hubaSl; char'h, nombra[401;

(

'! x.vcnla~ConCuadroSi~Ie(~,5,75.20, 'Error: *); if(DS.corr¡cntc= =NULL)

cphntfp No hay datos.de salida pira fusiomr'); if(D6.comicntc= =NULL) c&l('\n\P No hay dams de entrada para fusionar');

lf(DS.comentc= =NULL I I DE.comente= =NULL) ( ' cprintf('\n\ria** No puede pmedcr l a hinión de datos, porque

Noti: no hay datos.

Antes de h i s i o ~ r e s neccssno csuibleier las dependekiasde lob \n\r datos (opciones 1 y 2 del menú: \'Dependencia y F$d6n de Datos\' \n\r Si ya cslablcfi6 1.8 dcpcndcnciasdc los dalos, cntn a cualquiera in\r dc las opciones (I 6 2) y IC. los archivos donde quedamn mgislra-\n\r das dicha. dependencias. Desputs intende fusionar nucvamerae. .I);

cpr¡n~q'\n\n\rPrasione R E " para continuar...'); geicti0: reuim;

hu~DI=NavegnDamnSinAsociadoa(DI,AI, "WTERhíEDIüS'); / I DI ain asociados

huboSE=NivcgnDauisSuerOuo.OE.DE, DI, DS, 'de ENTRADA'); / I DS sin asoiiados I i. :

hub~I=NavcgiDsmsSupc~"~(SI,DI, DI, DS, 'iNTERMEDIOS'); / I DI sin asoiiados

) hubaDS=N.vcgaDatosSinAloFiados@S.AS. 'de SALkA.1;

Pág 147

Ii Listado del código del sistema G E R S Apúndice .. I

I break cam 2 : copiar DI;

EupJ@I,DE,coph, I , 'DEPENDENCIA DE DATOS ncrcah<~~i~d*) ; I / 1 DI

b r u k 'I cam 3 : UncDaiosO;

case 4 : ooushciio; .!I break

break caw O. : F.Rcsp.i&E.q"ema(~u~ma);~rn; default: F.Reipal&E.qucma(eqUelucmr); m m ; '

1 . } )

) I/ ' Ii

11 DBOpcn: Pmgnma de aplicacion. que implaj,Cnt. el aIgonUna I/ de ~mializasión

ñiffiludc 'nbdopcn.hpp' #include 'nporuda.hpp' Xiffiludc 'maMr.hpp'

ponida x; BDOpcra U; ., / I objeto pan a!rmiCcNr las at$buun, llaves y hi tablas BDOpcm T; 11 objeto pan almacenar los e&es BDOpcm N; I1 objeto temporal para las ubl?i y sus ivlbuun BDOpen L; / I objeto temporal p i n los posibles nuevos enlaces BDOpcra D; 11 Lisla de dependencbidc daun de cnlnd. UanArch F; I1 p a n operar en el equsma '11

char mnmcl301; 11 archivo o6giMl de atrib&

in1 primcna0, scgund.=O,terccra-O, respaldo=l; im emdo;

/I Busca en N la8 ublas donde Y onc~cmlc *I 'atribulo' excepto 11 en la 'ubla' c m UN I ¡ de tablas y lis dija en L. void Bulsa~ible~W.co~(charublan, char dtributoll)

.. :I ~ I !I1

11 objeto pan dciplegarpnullas,y mcms

char csqu~mal501; I1

r r It {

char nombrel951;

N.CorricnteAFin0; IlasNaliur el apuntador i RNI de la lista

L.inicio-L.libcnB.inisio);l/cn L la infapr,siónm<i miente

in1 1; al!

N.CorricnteAIMsioO; dl

if (N.comcnte != NULL) I whilc(l) i

'I N.DamcNombrcConicn~c(ndmbrc);

{

i f ( ( < = N . C l a s e [ X A l n ~ u U ) ( N . c o ~ ~ ~ t e ~ > ~ . ~ . d ~ r i ~ ~ D , I auibuto)) > O)

L.lnscniDatoDirw(nombre); 11 L.corriente- >ocurrcnsisi=i: ,,

(

)

if(N.carricnte = = N.fml) b r u k N .AvanuComcnteO;

1 return;

)

'1 void ExplicacionZ(char ublil[l. char ubb2[1. char nucvau, char atributoll)

x.ven&naConCuaddimpie~, IO, 79, 23,"Explicasi6n'); taxlcol~r(L1GHTCY AN);

c p h ~ r Dunnte el pmccso de NORMALIZACION, m ha indicado quein\rcxim un enlace N a U cnm las ublan %s\n\r y %s&r ello 51 neicsariocrur UN tabla nucva.%l en eale caso %a, la CUI hereda la1 llaves de hinb tablas OrigiMlca y el atributo que es16 iendo m>mliudo,inbcs decir. %s \n\r Dichoatributo será bomdode la tabla %a', tablal, tabla2, nuev.? atributo, tabid); ~ p ~ i n i í p d A & R c ~ i o ~ REi7JRN p a n coniinuar ...' ); getch0; tenColor(LlGHT0RAi'); x.vcntaMConCuiddimpk(Z, IO, 79, 7.3. 'Atributos'); R.Rcfrclsa@,

- 1 ubla %s., nueva); cpri"tf('\n\rLksea una explisssión? (SIN):-");

, ~* , :. . ,! :j : Listedo del código del sistema GERSl Apéndice . .

/i ..

Pág 151

Apéndice Y li Listado del código del sistema GERSI

I . '

void NFiOnt xforma)

Pág 153

'I

, J j Listado del &&o del sistema' GERSl Apéndice ~ , . .

I / DBOpcn: Pmgnma de aplioacionpin csubkcr lo i ENLACES

#include 'ebdopen.hpp' h c l u d c 'cpodn.hpp' Uiffilude 'maNr.hpp'

I1 podada I; I 1 objeto p a n dssplemr panulha y mnus B W p n R; B W p n 1;; B W p n I; ManArch Pi

/ I &jeto pars almacenar lis llaves y lis labhi I / objeto pan almacenar br ublas y sus enlaces

I 1 p a n operar en e1 cquema (todos los archivos de / I pars cbkncr UN copia da R

todas lis fara)

introspddo-I; . char mm0[50]; 11 archivo OngiMl de atributos char csquema(5Ol;

void cxplicacion(char ublalIl, char iabli2[1)

ii

!I

( x.vcn1?~ConCuadroSimple(2,4, 79, 8, Tmor.); cprintn'b**No e8 poiibb asignar esle cnlacc.\n\rDe- UM

cxplición? (SIN): 7; if(toupper@khO)= ='S? (

x.vcn/naConCuadmSimple(2, IO, 79,U:Explicacidn'); 1ensoloqLJGMCYAN); cprintl('No CI posible caablcicr un enlace de ii ubli 768 a W\+r ubla %a parque NO IC obrrva que 1. ubla 168 hercdc\n\rn> llave primaria a la ubla %a.\n\r', ublal, ubli2, u b b l . ubli2); cDrintf('\n\rin\rRcsiOnc RüiüüN v a n continuar ...' ii

Pdg 155

return: \ I!

RR.AvinuComeMC0; T.AvaresComcnicO; ni

1 )

cpnntl('\a\n\r> >>Fin de la gtncncióndc c n l i s c s . ~ \ i Rtiionc URN in continuar...'): 1 x.vcnu~ConCuadroSimplcn.4. 79, 8, 'x

" Listado del cúdigo del sistmü GERSl

brut ; c i f f i 4 x.vcntamConCuidroSimpplc(2,10. 79,23, 'Sclcccionc

ENLACE a bomr'); T.BomDsu>lnlegmlO;

respaldo-0; brut ;

case 5: CambiaEnlasc(I); 1 respsldo=0; break;

cam 6: x.ventaMConCuadmSimple(2, IO, 79, 23,'Waics asociados');

T.DesplicgaDawsAsoci.do.0; b m l ;

c.c.c 7: GcncnEnlasclO; ' respaldo-0;

break c i s 8: LecArchivos(R);

rcspildo=O; " bmk;

caffi 9 x.~cntamConCuidroSi~l~(2,4, 79,s. 'Respaldo de archivos');

if(mmbm[O]= ='\o') , drcpy(nombre. F.archivos[lll); I / enlaces

( cpnnlf('\n\rDar nombre de archivo para respaldar ');

I cpnntl('\n\r Enlaces asignadosa ublas: 3; R.Mgcla(nombrc); ií(nombre[Ol= =NüU)brenk;

drcpy(P.irshivoi[l I], nombre); ) '1 cprintl('\n\rRespaldo en pmg rem..."); T.CopULilaccsADisco(nombrc.'- >* ENLACES <-*k

PBg 157

listado del código del sistema GERSI

bruk I! Caw 3: x.vcnuMConCuadroSinmk~. 10. 79. U. ~ l c s i o n s

'I . . . atribulo'); &kCCiOMr<R): I1 rcspaldo=O; break

cprintT('\nir Dar nombm de archivo p i n re8pald.r 1 I d ) ;

cprinti("\n\r UAVES uigmdu a ubi': .h

I!

void minCint srgs, char *argvn)

char nombrcl50); ( 't

Púg 159

Listado del código del sistema GERSl

<I ' ., , . I .. ,void 6ptimizaBDO !i

! char nombmWJl. CadCM[W]. cidcnall4!% in1 Iongilud;

{

11: i&T.inicio= =NULL) I1

' 'I ~.venunsConCusdmSimplc(2,4 19.8, 'Enor"); cpr¡ntl('h**No exisen daiw pa+ opiimirar.inir

cprintf('\n\rPRsionc R E " pan somimur...'); Pmbablcmcnle no ha leido lo8 &milde disoo:);

void OptimUa(BDOpcn U)

( 1 1 . im opcion: char nombrel301, c01~ndol701;

x.pON&oplimv10;

R.ActualizaAntsriores(R.inic¡o); R.ComcntcAinisioO; x.v~~nnConCiuddmS¡mplc(2.4, 79, 8, 'Tabla'); EscribcDaloDcSali&(R);

x.vén~MConCuadmSimple(2, IO, 79, 73,'Alributos'); if(R.in¡cio != NULL) R.duplicgs1 I(R.inici*>a.z.dcrivaD);

$1

&hO; - iil ~.vcnrsnaConCudmSimpleR,4. ;P. 8. '7:

opoion=x.McnuüptimáO; nviich(opcion)

case 1: ii(!optimv1do) OpliMuBDO; I$

01%

{ x.~enisnaConCuadmSimpIe(2,4,19, 8, "); ClrsS@;

cprinlf('\n\rhLos dams ya han sido

'1 cprinif("\n\rRtdonc RETURN pan o p l i d d o a ' ) ;

continuar.. , 7; *L geah0; 'f 1

rcapaldor0; break

b m t ;

b m k

C.& 1: hri0qR);

C.D 3: siguic"lc(R); I

'I

Pdg 161

!I

Aphdica . 'I/ Listado del cád&o del sistema GERSl

II

i~.NombrcEsca(apl->a.z.derivaD, tabla)) (

í " Poaicioni!&n(apl- > nombre, R. I); FomiaUavc(R.sonicnie. hvc);

I ill.

void OtncraCodigoMice(FaE *pf, I t lus l ' d o L *ap. char tabiafl)

amct nodoL %pl; char cnlace1600l,IliveIS001;

iflap= =NULL I I tabisIOl- -'\O') return;. apl =T.inicia;

whilc(apl != NULL)

(

/j

void GcnCodSQUchar csquemafl)

char dmbrc[SOI; int i;

FiLE ipf; s l l Y E t d 0 L sap;

(

arcpy(nombm. esquema); whilc(nombnli]!='.'kk nombreIil!='\o') ¡++; nomb&[i+ +I='.'; nombre[¡+ +I- '9; nombre[¡+ + I = 'Q; nombre[i++]='L';// CiimiMci . e q nombre[¡ + + I ='\o';

I/

¡f(@f=fopen(Mmbm, 'W'))- =NULL) i

sprintf[' E m r en Ii apriun de: %s.\n\rFTesiom RE" p a k conrinuir..:,nombre); gcifh0;

puucn(2.4.19, ü,imgcn); ,8 return;

) forinifíd'ü henma en SOL PUC EM la Base de Datos

Pdg 163

Apéndice . I Listado del cddigo del Sistema GERSl

int menu0

in1 %io". e; {

windw(l,l,SO,25); clncro; RuehallO; tcnbackgmund(BLUE); t c c n c o l ~ ~ ; 1 venUniCanCuadmSimplc~~2,79.24, 'OERSI: MENU PRINCIPAL-); II cprimr\n\r\n\r > > > > > > > ü a r do D a t ~ . < < < < < C <in\rin\r?; cprintr\n\r I .- Cipwn de Datos ~ 3; cpnntf('in\r 2.- Dcpendench y Fusión de.Datoi oprinif('in\r 3.- higna Nombrei y ' l i ic i . a 'klributoi '); cpnntr\n\r 4.- klmII¡ni y Angiu Nmnbj i a Tablas.); cprinif('\n\r 5.- h ¡ g M Aú-ibutor Tablas 3; cprintrin\r 6.- hip U w o I Tabhi '1 .); cprintf('\n\r 7.- Optimiución de Ii üam de'Ditos 3; cprimf('\n\r 8.- Deicmiini Mics. .I e);

cprintf('\n\r 9.- N o m l h c i d n 3; cphT('\n\rlO.- Cenen Documnms e);

sprimr\n\ri I .- salida Tcmpod I WS 'I, *); cprimf('in\r 0.- Tamiini 3; cprinir\n\nin\r Opcion: ,, 3:

{

Raw de Diwb do UN

.);

do

Ij RuahallO ; goioxy(l5,ZO); e =rani(. %d., Btopcion);

ií(!(O<=opcionaopcian < m i l ) 11'L) I

goloxy(l5,l9); cprintf('\iEmr: Dck dar un nilmcm,cnrC O y 113; gotoxy(l5,20); cprintrRCsiona REruRN p i n Conünulr ...') ; geUh0; gotoxy(l5,19); cprintf(' -); gotory(l5,20): cpr intr 7;

!

1 gotOxy(l7,20);

)while(!(O < =opcion&& +on < = I I)); window(1, I . 80, U); rcturn(opcion);

)

( void main0

in1 opcion; char nombreI501, inugcn[7501. pI801, ca+do[100);

sy&rn('pnmn'); putrcn(S.20.75.24. inupen); delay(1@3l); whilc(l) {

¿pion-menu¡); witch(opcion) {

cw I : Iprinif(comando;upain %@', nombre); syncm(comndo); break

cam 2 : sprinlf(comndo.'dcpcndde a@', mimbre); iynOm(c0nundo); break

c m 3 : sprimf(conundo.'nombnat %s',nombre); 8ymcm(comuido); break;

cam 4 : Iplintf(conundo.'nombnU %",nombre); It symcm(comando); break

cam 5 : iprintf(comindo,'au.ub %s*, nombre); syacm(comndo); break

cam 6 : spriMf(comando.'llave~ %s', nombre); iyaem(conundo); break

cam 7 : iprintf(comndo,'optimYa %s',nombre); ryaern(comndo); breab

c m S : sprimf(comando;cnlsces %s". nombre); iyaem(comando); bruik

cam 9 : sprintf(cormndo.'nomuI %s., nombre); ryacm(comando); break

cam I O iprinrf(comado,'documcn %s". nombre); systcm(comando); break

cam I I : ooSShcii0; brear; cam O : 01rwcrO; crit(0):

:

)

P& 765

c m o DE INFORMACION 11 C E N I D E T _- .