rea de Matemticas

Estrategias para el Desarrollo de Sistemas

Ciclo de Vida Clsico del Desarrollo de Sistemas (Senn 33)

Es el conjunto de actividades que los analstas, diseadores y usuarios realizan para desarrollar e implantar un sistemas de informacin. En la mayor parte de las situaciones dentro de una empresa, las 6 actividades que constituyen este ciclo, estn muy relacionadas, en general son inseparables, y quiz sea dificil determinar el orden de los pasos que se siguen para efectuarlas. Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases del desarrollo; algunos componentes en la fase de anlisis mientras que otros en etapas avanzadas de diseo.

Consta de las siguientes actividades:

1. Investigacin preliminar (Estrategia)

2. Determinacin de los requerimientos del sistema (Anlisis)

3. Diseo del sistema (Diseo)

4. Desarrollo del software (Construccin / Documentacin)

5. Prueba de los sistemas (Transicin)

6. Implantacin y evaluacin (Produccin)

Investigacin preliminar

El proceso se inicia siempre con la peticin de una persona administrador, empleado o especialsta en sistemas-.

Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigacin preliminar. Esta actividad tiene tres partes: aclaracin de la solicitud, estudio de factibilidad y aprobacin de la solicitud.

Aclaracin de la solicitud

Muchas solicitudes que provienen de empleados y usuarios no estn formuladas de manera clara. Por consiguiente, antes de considerar cualquier investigacin de sistemas, la solicitud de proyecto debe examinarse para determinar con precisin lo que el solicitante desea.

Estudio de factibilidad

Un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. En la investigacin preliminar existen tres aspectos relacionados con el estudio de factibilidad:

7. Factibilidad Tcnica: el trabajo para el proyecto, puede realizarse con el equipo actual, la tecnologa existente de software y el personal disponible? Si se necesita tecnologa, cul es la posibilidad de desarrollarla?

8. Factibilidad Econmica: al crear el sistema, los beneficios que se obtienen sern suficientes para aceptar los costos?, los costos asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar el proyecto?

9. Factibilidad Operacional: si se desarrolla e implanta, ser utilizado el sistema?, existir cierta resistencia al cambio por parte de los usuarios que d como resultado la disminucin de los posibles beneficios de la aplicacin?

En general, las personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos.

Aprobacin de la solicitud

No todos los proyectos solicitados son deseables o factibles. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administracin decide qu proyectos son los ms importantes y decide el orden en que se llevarn a cabo.

Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta informacin se determina dnde ubicarlo dentro de la lista existente de proyectos.

Determinacin de los requerimientos del sistema

El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

10. Qu es lo que se hace?

11. Cmo se hace?

12. Con qu frecuencia se presenta?

13. Qu tan grande es el volumen de transacciones o de decisiones?

14. Cul es el grado de eficiencia con el que se efectan las tareas?

15. Existe algn problema?

16. Si existe un problema, que tan serio es?

17. Si existe un problema, cul es la causa que lo origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso.

Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad.

Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida.

Diseo del sistema

El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan diseo fsico.

Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema est terminado.

El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los procedimientos de clculo y los datos individuales. Los diseadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento.

La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software. Los diseadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas.

Desarrollo de software

Los encargados de desarrollar software pueden instalar (o modificar y despus instalar) software comprado a terceros o escribir programas diseados a la medida del solicitante.

Los programadores tambin son responsables de la documentacin de los programas y de proporcionar una explicacin de cmo y por qu ciertos procedimientos se codifican en determinada forma. La documentacin es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicacin se encuentra instalada.

Prueba de sistemas

Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.

En ocaciones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas.

En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable.

Implantacin y evaluacin

La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla.

Una vez instaladas, las aplicaciones se emplean durante muchos aos. Sin embargo las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones; realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de informacin deben mantenerse siempre al da. En este sentido, la implantacin es un proceso en constante evolucin.

La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones:

Evaluacin operacional: valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin.

Impacto organizacional: identificacin y medicin de los beneficios para la organizacin en eras tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin interno y externo.

Opinin de los administradores: evaluacin de las actitudes de directivos y administradores dentro de la organizacin as como de los usuarios finales.

Desempeo del desarrollo: la evaluacin del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos.

Mtodo de desarrollo por anlisis estructurado (Senn 38)

Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis estructurado tiene como finalidad superar dificultad por medio de 1) la divisin del sistema en componentes y 2) la construccin de un modelo del sistema. El mtodo incorpora elementos tanto de anlisis como de diseo.

Qu es el anlisis estructurado?

El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadoras, terminales, sistemas de almacenamiento, etc.)

Elementos del anlisis estructurado

Descripcin grfica

Una de las formas de describir un sistema es preparar un bosquejo que seale sus caractersticas, identifique la funcin para la que sirve e indique cmo ste interacta con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fcil omitir algn detalle o dar una explicacin que quiz de los dems no entiendan.

En lugar de las palabras del anlisis estructurado utiliza smbolos, o conos, para crear un modelo grfico del sistema. Los modelos de este tipo muestran los detalles del sistema pero sin introducir procesos manuales o computarizados, archivos en cinta o disco magntico, o procedimientos operativos y de programas. Si se seleccionan los smbolos y notacin correctos entonces cualquier persona puede seguir la forma en que los componentes se acomodarn entre s para formar el sistema.

El diagrama lgico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una funcin con otra y seala los almacenes de datos a los que se tiene acceso.

Diagramas de flujo de datos (DFD)

La descripcin completa de un sistema est formada por un conjunto de diagramas de flujo de datos. Para desarrollar una descripcin del sistema por el mtodo de anlisis estructurado se sigue un proceso descendente (top-down). El modelo original se detalla en diagramas de bajo nivel que muestran caractersticas adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez ms detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigacin.

Diccionario de datos

Todas las definiciones de los elementos en el sistema flujos de datos, procesos y almacenes de datos estn descritos en forma detallada en el diccionario de datos. Si algn miembro del equipo encargado del proyecto desea saber alguna definicin del nombre de un dato o el contenido particular de un flujo de datos, esta informacin debe encontrarse disponible en el diccionario de datos.

Qu es el diseo estructurado?

El diseo estructurado, otro elemento del anlisis estructurado que emplea la descripcin grfica, se enfoca en el desarrollo de especificaciones del software. La meta del diseo estructurado es crear programas formados por mdulos independientes unos de otros desde el punto de vista funcional. Este enfoque no slo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo.

El diseo estructurado es un tcnica especfica para el diseo de programas y no un mtodo de diseo de comprensin. Es decir, no indica nada relacionado con el diseo de archivos o bases de datos, la presentacin de entradas o salidas, la secuencia de procesamiento o el hardware que dar soporte a la aplicacin. Esta tcnica conduce a la especificacin de mdulos de programa que son funcionalmente independientes.

La herramienta fundamental del diseo estructurado es el diagrama estructurado. Su finalidad no es mostrar la lgica del programa (que es la tarea de los diagramas de flujo). Los diagramas estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l. Estas especificaciones funcionales para los mdulos se proporcionan a los programadores antes que d comienzo la fase de escritura de cdigo.

Mtodo del Prototipo de Sistemas (Senn 43)

Este mtodo hace que el usuario participe de manera ms directa en la experiencia de anlisis y diseo que los mtodos de Ciclo de Vida y el Anlisis Estructurado,

Qu es un prototipo?

El prototipo es un sistema que funciona no slo una idea en el papel -, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Esta constituido por software que acepta entradas, realiza clculos, produce informacin ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versin, o iteracin de un sistema de informacin; es el modelo original.

Razones para desarrollar prototipos de sistemas

Los requerimientos de informacin no siempre estn bien definidos o pueden ser demasiado vagos aun al formular el diseo.

Los prototipos permiten evaluar situaciones extraordinarios donde los encargados de disear e implantar sistemas no tienen informacin ni experiencia, o tambin donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseo propuesto es novedoso y an no ha sido probado.

El prototipo es, en realidad, un modelo piloto o de prueba; el diseo evoluciona con el uso. Aunque el prototipo es un sistema que funciona, est diseado para ser modificado con facilidad. La informacin obtenida con su uso se aplica en un nuevo diseo que se emplea, otra vez, como prototipo y que revela ms informacin valiosa sobre el diseo. El proceso se repite las veces que sea necesario para revelar los requerimientos esenciales del diseo.

Los prototipos tienen mayor utilidad bajo las siguientes condiciones:

Los encargados de disear e implantar sistemas nunca han desarrollado uno con las caractersticas del sistema propuesto.

Se conoce slo una parte de las caractersticas esenciales del sistema; las dems no son identificables a pesar de un cuidadoso anlisis de requerimientos.

La experiencia con el uso del sistema aadir una lista significativa de requerimientos que el sistema debe satisfacer (ms que la que puede obtenerse con cualquier otro mtodo de desarrollo).

Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus caractersticas.

Los usuarios del sistema participan en el proceso de desarrollo.

El principio fundamental del desarrollo de prototipos es el siguiente:

Los usuarios pueden sealar las caractersticas que les agradara o no tener, junto con los problemas que presenta un sistema que existe y funciona, con mayor facilidad que si se les pidiese que las describieran en forma terica o por escrito. El uso y la experiencia producen comentarios ms significativos que el anlisis de diagramas y las propuestas por escrito.

El desarrollo de prototipos de sistemas es un proceso interactivo. Comienza con unas cuantas funciones y crece al incluir otras que son identificadas con posterioridad. Tambin puede comenzar con un conjunto de funciones que tanto el analista como los usuarios consideran completo y que puede aumentar o disminuir con el uso y la experiencia. En general, los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:

18. Identificar los requerimientos de informacin que el usuario conoce junto con las caractersticas necesarias del sistema.

19. Desarrollar un prototipo que funcione.

20. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos.

21. Revisar el prototipo con base en la informacin obtenida a travs de la experiencia del usuario.

22. Repetir los pasos anteriores las veces que sea necesario, hasta obtener un sistema satisfactorio.

Tal como lo sugieren los pasos anteriores, la construccin de prototipos no es un proceso de desarrollo por prueba y error. Antes que d inicio cualquier actividad de diseo o programacin, el analista se rene con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construccin del prototipo.

El dilogo de interfase permite a los usuarios actuar recprocamente con el sistema, las rutinas de procesamiento y las salidas deben ser adecuadas (aunque no necesariamente completas) para que las personas puedan comprender cmo utilizar el sistema para realizar estas funciones. Los mensajes y pantallas no incluidos en el prototipo se aaden ms tarde, cuando se conoce un conjunto ms completo de requerimientos.

Cuando el analista y el usuario deciden que cuentan ya con la suficiente informacin proveniente del proceso de construccin del prototipo, determinan cmo satisfacer los requerimientos ya identificados. En general, se opta por una de las siguientes cuatro opciones:

23. Volver a desarrollar el prototipo. Esta alternativa quiz signifique volver a programar por completo, empezando desde el principio.

24. Implantar el prototipo como sistema terminado. La eficiencia en el funcionamiento junto con los mtodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tal como est.

25. Abandonar el proyecto. En este caso el prototipo ha proporcionado informacin suficiente para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del marco de la tecnologa existente o de lineamientos econmicos u operacionales.

26. Iniciar otra serie de construccin de prototipos. La informacin ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o caractersticas contrastantes.

Cada una de estas opciones se considera como un xito en el proceso de la construccin de prototipos.

Mtodos para el desarrollo de prototipos

Con los prototipos la velocidad de desarrollo es ms importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, frecuentemente en das o semanas, siendo el costo menor comparado con el de un sistema convencional, aun a pesar de no ser tan eficiente como los sistemas desarrollados sobre periodos de meses.

Los sistemas prototipo pueden desarrollarse con mtodos y lenguajes de programacin convencionales, aunque no contengan todas las caractersticas y toques finales que normalmente se incluyen en un sistema terminado. Por ejemplo, en los reportes pueden faltar los encabezados, ttulos y nmeros de pgina. La organizacin de los archivos puede ser temporal y las estructuras de registros pueden dejarse incompletas. Quiz falten los controles de entrada y procesamiento y, en general, la documentacin del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hiptesis relacionadas con los requerimientos y no la eficiencia y perfeccin alcanzadas.

Durante la construccin de prototipos los analistas enlazan partes de cdigo reutilizable con cdigo que ellos mismos escriben con la finalidad de tener listo el sistema para su operacin y evaluacin.

En algunos casos, aquellos donde el sistema ser utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado.

Estructuracin de Datos (Senn 657, Date 522)

Normalizacin

La normalizacin es el proceso de simplificar la relacin entre los campos de un registro. Por medio de la normalizacin, un conjunto de datos en un registro se reemplaza por varios registro que son ms simples y predecibles y, por lo tanto, ms manejables. La normalizacin se lleva a cabo por cuatro razones:

27. Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos

28. Permitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y reportes

29. Simplificar el mantenimiento de los datos o actualizndolos, insertndolos y borrndolos

30. Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones

Los analistas de sistemas deben familiarizarse con los pasos de la normalizacin, ya que este proceso puede mejorar la calidad del diseo de una aplicacin.

31. Descomponer todos los grupos de datos en registros bidimensionales.

32. Eliminar todas las relaciones en las que los datos no dependan completamente de la llave primaria del registro.

33. Eliminar todas las relaciones que contengan dependencias transitivas.

Primera Forma Normal

La primera forma normal se alcanza cuando se quitan todos los grupos de repeticin, es decir, la aparicin repetida de un dato o grupo de datos dentro de un registro, es en realidad otra relacin. Por lo tanto, se quita del registro y se le considera como una parte del mismo o como una relacin adicional.

Consideremos la informacin contenida en el pedido de un cliente:

No

PedidoNo

ClienteNombre

ClienteDirecc.

ClienteFecha

Solic.No

ArtculoDescrip.

ArtculoPrecio

ArtculoCant.

SolicitaCosto

Total

101456812Harper University33 whipple Lane,Rosboro,NY 1351412/01T101Manteles.95100185.40

B16Cobijas1.5550

C118Sbanas.2930

B14Toallas.4210

1027211319McGraw Manufacturing90 Main, Endicott, NY 1376012/01C118Sbanas.29105.80

1036542107Union Hospital1021 6th Avenue, NY,NY 1002112/02B14Toallas.4260118.20

Existen 4 nmeros de artculos, cuatro precios de artculo y cuatro especificaciones de cantidad. El pedido se puede considerar como cuatro registros separados, en cada uno de los cuales se incluya la informacin sobre el pedido y el cliente. Sin ambargo, al considerar cada registro como un pedido aparte se aumenta la complejidad para el cambio de los detalles de cualquier parte del pedido y utiliza espacio adicional.

Cuando un pedido especifica un artculo, los detalles es ste se establecen slo una vez. Cuando se piden cuatro, los detalles del artculo se repiten cuatro veces. La parte del registro de los datos que se repite de denomina grupo de repeticin.

La primera forma normal se alcanza cuando un registro se disea de longitud fija. Esto se lleva a cabo quitando el grupo de repeticin y creando un archivo o relacin aparte que contenga al grupo de repeticin. El registro original y el nuevo se interrelacionan mediante un punto comn de los datos.

Registro de Pedidos

No

PedidoNo

ClienteNombre

ClienteDireccin

ClienteFecha

Solic.Costo

Total

101456812Harper University33 Whipple Lane, Rosboro, NY 1351412/01185.40

1027211319Mcgraw Manufacturing98 Main, Endicott, NY 1376012/015.80

1036542107Union Hospital1021 6th Avenue, NY, NY 1002112/02118.20

105489824Hara EnterprisesCommerce Circle, Endicott, NY 1376011/3084.00

Registro de Artculos

No

PedidoNo

ArtculoDescripcin

ArtculoPrecio

ArtculoCantidad

Solicitada

101456T101Manteles.95100

101456B16Cobijas.3350

101456C118Sbanas.2930

101456B14Toallas.1210

102721C118Cobijas.2920

103654B14Toallas.1260

103654B16Cobijas.3360

105489N38Servilletas.84100

Segunda Forma Normal

La segunda forma normal se alcanza cuando un registro est en la primera forma normal y cada campo depende totalmente de la llave del registro (en el almacenamiento y recuperacin). En otras palabras el analista busca la dependencia funcional: un campo es funcionalmente dependiente si su valor est asociado de manera nica con un campo especfico.

Para alcanzar la segunda forma normal, cada campo del registro que no dependa de la llave primaria del registro debe quitarse y utilizarse para formar otra relacin aparte.

Consideremos el ejemplo de los pedidos. El registro de los pedidos esta en la primera forma normal, pero tambin est en la segunda forma normal? Intente esta prueba. Si se conoce el nombre del proveedor, conoce el nmero de pedido?, existe una relacin uno a uno o muchos a uno entre el nombre del proveedor y el nmero del artculo?

Puesto que el nombre del cliente depende del nmero del cliente y no del nmero de pedido, y ya que la relacin entre la llave primaria del nmero de cliente y nmero de artculo no es uno a uno, sabemos que no se ha alcanzado la segunda forma normal. Por lo tanto, se disean dos nuevas estructuras de registro.

Registro de Pedidos

PedidoClienteFechaTotal

10145681212/01185.40

120721131912/015.80

103654210712/02118.20

10548982411/3084

10549083611/2878.50

Registro de Proveedores

Nmero ClienteNombre ClienteDireccin Cliente

812Harper University33 whipple Lane, Rosboro, NY 13514

1319McGraw Manufacturing98 Main, Endicott, NY 13760

2107Union Hospital1021 6th Avenue, NY, NY 10021

824Hara EnterprisesCommerce Circle, Endicott, NY 13760

836Holiday Inn Downtown10 Downey Street, Buffalo, NY 13240

Anlogamente, el registro de partes contiene la llave de nmero de parte y todos los dems datos en el registro dependen funcionalmente de l.

Tercera Forma Normal

La tercera forma normal se alcanza cuando se quitan las dependencias transitivas de un diseo de registro. El caso general es el siguiente:

A, B, y C son tres datos en un registro

Si C es funcionalmente dependiente de B y

B es funcionalmente dependiente de A,

entonces C es funcionalmente dependiente de A

Por lo tanto, existe una dependencia transitiva

En el manejo de datos, la dependencia transitiva es una preocupacin, ya que los datos pueden perderse de manera inadvertida cuando la relacin est oculta. En el caso anterior si se quita A, entonces tambin se quitan B y C, sea o no sta la intencin. Este problema se elimina diseando el registro para la tercera forma normal. La conversin a la tercera forma normal quita la dependencia transitiva dividiendo la relacin en dos relaciones separadas.

Consideremos este ejemplo. Al utilizar la informacin sobre el proveedor de:

No del productoNo del proveedorNombre proveedorDireccin proveedorNo de parteDescrip. ParteCantidad utilizadaDescrip. ProductoCosto del producto

podemos ver que PARTE depende de PRODUCTO, y PROVEEDOR depende de PARTE. Si quitamos un cierto producto de la base de datos, no sera adecuado eliminar las partes y los proveedores, los cuales podran estar asociados con otros productos.

Para quitar la dependencia transitiva en esta situacin, se crean los registros PRODUCTO, PARTE y PROVEEDOR.

Producto

Nmero del productoDescripcin del productoCosto del producto

Componentes del producto

Nmero del productoNmero del productoCantidad utilizada

Parte

Nmero de parteDescripcin de parteNmero proveedor

Proveedor

Nmero del proveedorNombre del proveedorDireccin proveedor

Los registros adicionales dan mayor flexibilidad para cubrir los requerimientos futuros a la vez que eliminan las dificultades mencionadas arriba.