Modelo de Entidad Relación

Resumen

El modelos entidad relación es un concepto utilizado para el diseño de bases de datos, está formado por un conjunto de definiciones que permiten describir la realidad mediante distintas representaciones graficas. Para su realización se comienza de una situación real a partir de la cual se definen entidades y relaciones. Las entidades son  objetos del mundo real donde se almacena la información, están compuestas por atributos que son los datos que definen el objeto y en donde existirán una o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad; en toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla y la relación que se encargar de crear una asociación entre las entidades la cuales serán inexistente en el mundo real pero muy necesarias para reflejar la interacción que existe entre dichas entidades.

Modelo de Entidad Relación

Es un modelo de datos basado en una percepción del mundo real que consiste en un conjunto de objetos básicos llamados entidades y relaciones entre estos objetos.

Componentes del Modelo Entidad-Relación

• Entidades: Representa un objeto del mundo real con existencia independiente (Una persona, un automóvil, una casa).
• Atributos: Son las propiedades que describen las entidades, con valores específicos para cada atributo (Para una persona: Id, Nombre, Edad, etc.)
• Relaciones: Describe la dependencia de entidades y permite la asociación de las mismas.

Representación Gráfica

Las entidades están representadas con rectángulos, los atributos con óvalos y las relaciones con rombos.

Palabras Clave: Modelo, Entidad-Relación.

Referencias

 [1] http://www.tejedoresdelweb.com/wiki/images/c/c7/Basesdatos_teo3_modelo_er.pdf

[2] http://www.belgrano.esc.edu.ar/matestudio/carpeta_de_access_introduccion.pdf

Diego Garrido
Luis Boada
Rómulo Romero

Estrategias de análisis de decisión

Autores:

Hernández, Andry     Mafer_17_71_28@hotmail.com

Rosa, Ali                      Aligrm@gmail.com

Palabras Claves:  atributos, decisión, decisor, análisis, Estrategia, arboles de decisión, tablas de decisión, lenguaje estructurado, técnicas.

La capacidad de decidir es uno de los atributos mas altos del ser humano y la calidad de las decisiones frecuentemente hacen la diferencia entre el éxito y el fracaso.

El análisis de decisión se orienta a la lógica de las decisiones que se toman o se necesitan tomar dentro de las organizaciones para llevar a cabo los objetivos de las empresas.

El objetivo del análisis de decisión es que al concluir el proceso de análisis , el decisor sepa lo que desea y cuanto lo valora, la naturaleza de la situación que enfrenta y el efecto de las acciones que puede emprender, como resultado de esto el decisor sabrá con claridad lo que le conviene hacer.

Aunque las situaciones de decisiones son muy diversas, estas tienen tres elementos característicos :

1. Valores y preferencias: Estos son de orden interno y personal e indican lo que el decisor desea lograr y cuanto valora cada posible resultado o consecuencia.
2. Decisiones y alternativas: estas son decisiones bajo el control del decisor, el o ella tiene plena libertad de selección entre las alternativas.
3. Eventos inciertos: estos están fuera del control del decisor, afectan los resultados que les interesa y el decisor no sabe con certeza cual de los resultados del evento va a suceder (aunque puede asignar distribuciones de probabilidad a los eventos)

Existen gran variedad de técnicas usadas para el análisis de decisión, algunas de ellas son:

1. Jerarquía de datos.
2. Análisis probabilísticos.
3. Diagrama de influencia.
4. Mapa de conocimiento.
5. Análisis de sensibilidad.
6. Calculo del valor de la información.
7. Curvas de aptitud de riesgo.
8. Modelos reusables de decisión
9. Arboles de decisión.
10. Tablas de decisión.
11. Lenguaje estructurado.

Siendo estas tres ultimas las utilizadas y explicadas en otros capítulos de este mismo blog.

Es importante señalar que para que un análisis de decisión sea de alta calidad, el proceso debe reunir las siguientes características:

1. Enmarca miento apropiado de la decisión, esto significa que se va trabajar en el problema correcto y no en algún problema reducido o demasiado general para los intereses actuales del decisor.
2. Objetivos completos y bien planteados identificando las relaciones entre ellos.
3. Identificación y generación de alternativas creativas.
4. Obtención de información relevante o confiable sobre las consecuencias y los eventos inciertos.
5. Razonamiento lógicamente correcto para evaluar las alternativas en base a los objetivos.
6. Generación del convencimiento y compromiso de apoyo (personal e institucional) a las acciones seleccionadas.

Atender estos seis factores garantiza que el análisis sea de calidad y que las recomendaciones tengan una alta probabilidad de alcanzar los objetivos del decisor.

¿Cuando seleccionar una técnica de análisis de decisión?

Basándonos en las tres ultimas técnicas mencionadas en que son; lenguaje estructurado, tablas de decisión y arboles de decisión, aunque no es necesario que sea utilizadas en forma excluyente

 Por lo general se selecciona una de estas técnicas en vez utilizar las tres, los siguientes lineamientos le enseñan una manera de seleccionar  algunas de las tres técnicas para usar en casos particulares:

1. Use lenguaje estructurado cuando:
1. Haya muchas acciones repetitivas.
2. Sea importante la comunicación con los usuarios finales.
2. Use tablas de decisión cuando:
1. Se encuentre combinaciones complejas de condiciones, acciones y reglas.
2. Requiera un método que evite en forma efectiva situaciones imposibles, redundancia y contradicciones.
3. Use arboles de decisión cuando:
1. La secuencia de condiciones y acciones es crítica.
2. Cuando no son relevantes todas las condiciones para todas las acciones (las ramas son diferentes).

Referencias:

Análisis y diseño de sistemas. Kenneth E. Kendall, Julie E. Kendall,  3ª edición. 

Análisis de decisión: la ingeniería industrial para el nivel directivo; ponencias hechas por: Dr. Roberto Ley Borras, instituto tecnológico de Orizaba. Bajadas de la página web: www.decidir.org 

Estrategias de análisis de decisión

Autores:

Hernández, Andry     Mafer_17_71_28@hotmail.com

Rosa, Ali                      Aligrm@gmail.com

Palabras Claves:  atributos, decisión, decisor, análisis, Estrategia, arboles de decisión, tablas de decisión, lenguaje estructurado, técnicas.

La capacidad de decidir es uno de los atributos mas altos del ser humano y la calidad de las decisiones frecuentemente hacen la diferencia entre el éxito y el fracaso.

El análisis de decisión se orienta a la lógica de las decisiones que se toman o se necesitan tomar dentro de las organizaciones para llevar a cabo los objetivos de las empresas.

El objetivo del análisis de decisión es que al concluir el proceso de análisis , el decisor sepa lo que desea y cuanto lo valora, la naturaleza de la situación que enfrenta y el efecto de las acciones que puede emprender, como resultado de esto el decisor sabrá con claridad lo que le conviene hacer.

Aunque las situaciones de decisiones son muy diversas, estas tienen tres elementos característicos :

1. Valores y preferencias: Estos son de orden interno y personal e indican lo que el decisor desea lograr y cuanto valora cada posible resultado o consecuencia.
2. Decisiones y alternativas: estas son decisiones bajo el control del decisor, el o ella tiene plena libertad de selección entre las alternativas.
3. Eventos inciertos: estos están fuera del control del decisor, afectan los resultados que les interesa y el decisor no sabe con certeza cual de los resultados del evento va a suceder (aunque puede asignar distribuciones de probabilidad a los eventos)

Existen gran variedad de técnicas usadas para el análisis de decisión, algunas de ellas son:

1. Jerarquía de datos.
2. Análisis probabilísticos.
3. Diagrama de influencia.
4. Mapa de conocimiento.
5. Análisis de sensibilidad.
6. Calculo del valor de la información.
7. Curvas de aptitud de riesgo.
8. Modelos reusables de decisión
9. Arboles de decisión.
10. Tablas de decisión.
11. Lenguaje estructurado.

Siendo estas tres ultimas las utilizadas y explicadas en otros capítulos de este mismo blog.

Es importante señalar que para que un análisis de decisión sea de alta calidad, el proceso debe reunir las siguientes características:

1. Enmarca miento apropiado de la decisión, esto significa que se va trabajar en el problema correcto y no en algún problema reducido o demasiado general para los intereses actuales del decisor.
2. Objetivos completos y bien planteados identificando las relaciones entre ellos.
3. Identificación y generación de alternativas creativas.
4. Obtención de información relevante o confiable sobre las consecuencias y los eventos inciertos.
5. Razonamiento lógicamente correcto para evaluar las alternativas en base a los objetivos.
6. Generación del convencimiento y compromiso de apoyo (personal e institucional) a las acciones seleccionadas.

Atender estos seis factores garantiza que el análisis sea de calidad y que las recomendaciones tengan una alta probabilidad de alcanzar los objetivos del decisor.

¿Cuando seleccionar una técnica de análisis de decisión?

Basándonos en las tres ultimas técnicas mencionadas en que son; lenguaje estructurado, tablas de decisión y arboles de decisión, aunque no es necesario que sea utilizadas en forma excluyente

 Por lo general se selecciona una de estas técnicas en vez utilizar las tres, los siguientes lineamientos le enseñan una manera de seleccionar  algunas de las tres técnicas para usar en casos particulares:

1. Use lenguaje estructurado cuando:
1. Haya muchas acciones repetitivas.
2. Sea importante la comunicación con los usuarios finales.
2. Use tablas de decisión cuando:
1. Se encuentre combinaciones complejas de condiciones, acciones y reglas.
2. Requiera un método que evite en forma efectiva situaciones imposibles, redundancia y contradicciones.
3. Use arboles de decisión cuando:
1. La secuencia de condiciones y acciones es crítica.
2. Cuando no son relevantes todas las condiciones para todas las acciones (las ramas son diferentes).

Referencias:

Análisis y diseño de sistemas. Kenneth E. Kendall, Julie E. Kendall,  3ª edición. 

Análisis de decisión: la ingeniería industrial para el nivel directivo; ponencias hechas por: Dr. Roberto Ley Borras, instituto tecnológico de Orizaba. Bajadas de la página web: www.decidir.org 

Diccionario de Datos

Tema: Diccionario de Datos

Integrantes: Rosmary Márquez y Tania López

Resumen:

Diccionario de Datos ^[4]

Un diccionario de datos contiene las características lógicas de los datos que se van a utilizar en un sistema, incluyendo nombre, descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, evitando así malas interpretaciones o ambigüedades, su contenido también se emplea durante el diseño del proyecto.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

La necesidad de la notación en el diccionario de datos ^[1]

En la mayoría de los sistemas reales con los que se trabaja, los paquetes o elementos de datos, serán lo suficientemente complejos como para que se necesite describirlos en términos de otras cosas. Los elementos complejos de datos se definen en términos de elementos más sencillos, y los sencillos en términos de valores y unidades legítimos que pueden asumir.

Como se podrá imaginar, se vuelve algo tedioso describir la composición de los elementos de datos en una forma narrativa. Necesitamos una notación concisa y compacta, así como un diccionario normal tiene notación compacta y concisa para definir el significado de las palabras ordinarias.

En general: “El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema. El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades. Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los diagramas de entidad-relación, etc.” ^[3]

Notación del diccionario de datos ^{[1] [2]}

Existen muchos esquemas de notación comunes utilizados por el analista de sistemas. El que se muestra a continuación es de los más comunes y utiliza varios símbolos sencillos.

= "está compuesto de"

+ "y"

( ) "optativo (puede o no estar presente)"

{ } "iteración"

[] "seleccionar una de varias alternativas"

** "comentario"

@ "identificador (campo clave) para un almacén”

| “separador, opción”

Definiciones: La definición de un dato se introduce con el símbolo "=". En este contexto el "=" se lee: "se define como", o "se compone de", o simplemente "significa".

Para definir completamente un dato, nuestra definición debe incluir lo siguiente:

• El significado del dato dentro del contexto de la aplicación de este usuario. Por lo común se ofrece como comentario utilizando la notación "**".
• La composición del dato, si se compone de partes elementales con significado.
• Los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.

Ejemplo de DD: en el siguiente ejemplo se muestra el diccionario de datos del sistema del control de ventas de productos de una tienda.

Diccionario de datos

ü       clientes = cod_cliente + cliente + id + dirección

cod-cliente: character (3) *Código del cliente, no puede ser nulo*

cliente: character varing(25) *nombre complete del cliente, no puede ser nulo *

id: character varing(12) *numero de identificación del cliente, no puede ser nulo *

*formato: V-0000000000

               J-0000000000

               E-0000000000

direccion: character varing(40)

clientes = cod_cliente

 ü       telefonos  = cod_c_telf  + (telf1) + (telf2) + (telf3)

 

cod_c_telf: character(3) *Código del cliente al cual pertenecen los números telefónicos, no puede ser nulo y debe estar registrado en la tabla de clientes*

Telf1: character(15) *numero de teléfono fijo*

Telf2: character(15) *numero de celular*

Telf2: character(15) *número de fax*

*formato: 0000-0000000

telefonos = cod_c_telf

Ingresar Cliente: @clientes+@telefonos

Modificar Cliente: @clientes+@telefonos

Consultar Cliente: @clientes+@telefonos

Eliminar Cliente: @clientes+@telefonos

Reportes de Clientes:

-Todos: @clientes +@telefonos

-Morosos: @clientes+@telefonos+@ventas

-Con Pedidos:@clientes+@telefonos+@pedidos

 

ü       productos = cod_prod + producto + descripcion + precio

 

cod_prod: character(3) *código del producto, no puede ser nulo*

producto: character varing(15) *nombre del producto, no puede ser nulo*

descripcion: character varing(20) *descripción breve del producto*

precio: real *precio del producto, no puede ser nulo*

Productos = cod_prod

 

Ingresar Producto: @productos

Modificar Producto: @productos

Consultar Producto: @productos

Eliminar Producto: @productos

Reportes Productos:

       -Todos: @productos

                   - En existencia: @productos+@existencia

 

ü       existencia = cod_p_exist + cantidad

cod_p_exist: charater(3) *código del producto que se encuentra en existencia, no puede ser nulo y debe ser un producto registrado*

cantidad: integer, no puede ser nulo, pero si cero.

Existencia =cod_p_existencia

Modificar existencia: @existencia

 

ü       ventas = cod_venta + sub_total  + total + fecha + cod_c_venta + tipo + pago

cod_venta: character(4) *código para cada venta, no puede ser nulo*

sub_total: real *subtotal de la venta, no puede ser nulo*

total: real *total de la venta, no puede ser nulo*

fecha = date *fecha en que se realizo la venta, no puede ser nula*

cod_c_venta: character(3) *código del cliente que realizo la compra del producto, no puede ser nulo y el cliente debe estar registrado*

tipo: char *indica el tipo de forma en que se realizo la venta, sea a crédito o de contado, no puede ser nulo*

*formato: C, a crédito

              E, contado

ventas = cod_venta

 

ü       detalles_ventas = cod_v_detalle + cod_detalle + cod_p_venta + cant_prod + total_det

cod_v_detalle: character(4) *código de la venta a la cual pertenece el detalle, no puede ser nulo y debe estar registrada la venta*

cod_detalle: character(2) *código del detalle de la venta, no puede ser nula*

cod_p_venta: character(3) *código del producto perteneciente a una determinada venta, no puede ser nulo y el producto debe estar registrado*

cant_pro: integer *numero de productos comprados en cada detalle de venta, no puede ser nulo y debe ser mayor a 0*

total_det: real *es el total de que se paga por el detalle cada detalle de la venta, no puede ser nulo*

detalles_ventas = cod_v_detalle + cod_detalle

 

Registrar Venta: @ventas+@detalles_ventas+@clientes

Modificar Venta: @ventas+@detalles_ventas+(@clientes)

Reportes de Ventas:

         -Todas: @ventas

            -Mes: @ventas

            -Por Cliente: @ventas+@clientes

            -A Credito: @ventas

 

ü       pedidos = cod_pedido + cod_c_pedido + fecha_pedido + fecha_entrega +estado +listo

cod_pedido: character(4) *código del pedido, no puede ser nulo*

cod_c_pedido: character(3) *código del cliente que hace el pedido, no puede ser nulo y el cliente debe estar registrado*

fecha_pedido: date *fecha en que se realiza el pedido*

fecha_entrega: date *fecha en que se entregara el pedido*

estado: char *estado del pedido, bien sea entregado o por entregar, no puede ser nulo*

*formato: E, entregado

              P, por entregar

listo: char *estado de elaboración del pedido, bien sea listo o no, no puede ser nulo*

*formato: S, para cuando está listo

              N, si no está listo

 pedidos = cod_pedido

 

ü       detalles_pedidos = cod_d_pedido + cod_p_detalle + cod_p_pedido + cant_p_pedido

 

cod_d_pedido: character(2) *código del detalle perteneciente a un determinado pedido, no puede ser nulo*

cod_p_detalle: character(4) *código del pedido al cual pertenece el detalle, no puede ser nulo y el pedido debe estar registrado*

cod_p_pedido: character(3) *código del producto del detalle del pedido, no puede ser nulo y el producto debe estar registrado*

cant_p_pedido: integer *cantidad de un determinado producto del pedido, no puede ser nulo y debe ser mayor a cero*

 detalles_pedidos = cod_d_pedido + cod_p_detalle

 

Registrar Pedido: @pedidos+@detalles_pedidos+@clientes

Modificar Pedido: @pedidos+@detalles_ventas+(@clientes)

Reportes de Pedidos:

         -Todos: @pedidos

            -Mes: @pedidos

            -Por Cliente: @pedidos+@clientes

            -Entregados: @pedidos

            -Por Entregar: @pedidos

 

Palabras Claves

• Almacenamiento: es el proceso de retención y guardado de datos para su posterior recuperación.
• Datos: Son la materia prima para la información y se definen como grupos de símbolos no aleatorios que presentan cantidades, acciones, objetos, etc.
• Diccionario: Colección ordenada de palabras de una o más lenguas o lenguajes especializados, con sus correspondientes definiciones o explicaciones.
• Diagrama: Es una forma de representar gráficamente un fenómeno, proceso u organización determinado.
• Flujo: Movimiento o circulación de cierta variable en el interior del sistema.
• Flujograma: Los flujogramas o diagramas de flujo son representaciones gráficas de los procesos, muestran las diferentes integraciones que cada uno de los procesos tienen con otros y las unidades administrativas que involucran.
• Proceso: (del latín processus) es un conjunto de actividades o eventos que se realizan o suceden (alternativa o simultáneamente) con un fin determinado. Este término tiene significados diferentes según la rama de la ciencia o la técnica en que se utilice.
• Sistema: Conjunto de elementos interrelacionados en torno a un objetivo común

Referencias

[1] Carlos A. Ijelchuk
ijelchuk@noanet.com.ar     http://www.monografias.com/trabajos5/filoinf/filoinf5.shtml

[2] http://es.wikipedia.org/wiki/Diccionario_de_datos

[3] http://www.alegsa.com.ar/Dic/diccionario%20de%20datos.php

[4] http://www.nocturnabsas.com.ar/forum/programacion/188323-que-diccionario-de-datos

Actividades Asignadas

Primer Proyecto:

Se debe entregar un anteproyecto que debe contener las siguientes caracteristicas:

• Titulo
• Objetivo General
  
• Objetivo Especifico
• Alcance del Proyecto
  
• Justificación

Se trata de un análisis de un pequeño sub-sistema de una organización mayor.

____________________________________________________________________

Para la segunda asignación se debe entregar un Análisis del Sistema Actual del anteproyecto entregado.

____________________________________________________________________

Segundo Proyecto

Se trata de una aplicacion que grabe y consulte en una BD.

Requisitos:

• Servidor Linux
• Apache
• Postgres
• PHP

____________________________________________________________________

Recordar que se debe entregar una idea por parejas para un proyecto via web, dicha idea debe ser original.

____________________________________________________________________
Datos para acceder a la cuenta de google:

usuario: administracionuneg99
contraseña: uneg1234

Ejemplos De Diagrama de Flujo de Datos (DFD)

Autores:

Gabriela Reyes - gabrielajreyesr@hotmail.com

César Sánchez - cesara87@gmail.com

Un diagrama de flujo de datos (DFD) es una representación gráfica del flujo de datos en un sistema de información, este también es utilizado para visualizar el procesamiento de datos. es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que los datos que éste maneja. los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios.

Los componentes de un diagrama típico de flujo de datos:

• Proceso.
• Flujo.
• Almacén.
• Terminador.

[1]

[2]
Referencias:

[1]

http://www.elprisma.com/apuntes/administracion_de_empresas/quesonlosdiagramasdeflujo/

[2] 

http://external.doyma.es/images/261v4n2/grande/261v4n2-13091835tab02.gif

Arbol de Decisión

---

Autores:

Antony Petrocelli: petrocellia@gmail.com

Daniel Acosta: shagdan01@hotmail.com

---

Palabras Claves: Arbol, Decisión

---

Resumen:

Para tomar una decisión, no importa su naturaleza, es necesario conocer, comprender, analizar un problema, para así poder darle solución; en algunos casos por ser tan simples y cotidianos, este proceso se realiza de forma implícita y se soluciona muy rápidamente, pero existen otros casos en los cuales las consecuencias de una mala o buena elección puede tener repercusiones en la vida y si es en un contexto laboral en el éxito o fracaso de la organización, para los cuales es necesario usar un método más estructurado que puede dar más seguridad e información para resolver el problema.

¿Que es un árbol de decisión?

Un árbol de decisión, es un método que nos permite representar de forma gráfica (diagrama, árbol), un problema o interrogante presente en un determinado momento; que a través de una serie de alternativas de acciones y condiciones, se tome una decisión para resolver el problema.

Aplicación de los Arboles de Decisión

La construcción de árboles de decisión, también denominados árboles de clasificación o de identificación, es sin duda el método de aprendizaje automático más utilizado. El dominio de aplicación de los árboles de decisión no está restringido a un ámbito concreto sino que pueden ser utilizados en diversas áreas (desde aplicaciones de diagnóstico médico hasta juegos como el ajedrez o inteligencia artificial).

Partes de un Arbol de Decisión

• Nodo de decisión (Raíz): Indica que una decisión necesita tomarse

• Nodo de probabilidad (Hijos): Indica que en ese punto del proceso ocurre un evento aleatorio (estado de la naturaleza)

• Rama (arista): Nos muestra los distintos posibles caminos que se pueden emprender dado que tomamos una decisión u ocurre algún evento aleatorio
  

Construcción de un árbol de decisión

La construcción de los árboles de decisión se hace recursivamente de forma descendente (se parte de conceptos generales que se van especificando conforme se desciende en el árbol), por lo que se emplea el acrónimo TDIDT [Top-Down Induction on Decision Treess] .

Ejemplo de Arbol de Decisión

---

Referencias:
[1]: Toma de decisiones
http://es.wikipedia.org/wiki/Toma_de_decisiones

[2]: Arboles de Decisión
http://www.investigacion-operaciones.com/Curso_inv-Oper_carpeta/

[3]: Clasificación Aprendizaje Clasificado
http://elvex.ugr.es/etexts/spanish/proyecto/

Diagrama de Flujo de Datos (DFD)

Antonella Franchini; Julio Truyol

antonella_franchini@hotmail.com; julio_truyol@hotmail.com.

Resumen

La invención de Constantine de un diagrama que describa el movimiento sin tomar en cuenta el orden de los procesos, y analice la forma en que se transforman los datos en información, a simple vista no suena productivo; pero al diseñar un sistema de información, esta técnica es útil para visualizar el procesamiento de datos.

Los diagramas de flujos de datos los componen cuatro elementos; Entidad externa (cuadrado), son las fuentes de origen o destino de la transacción; Almacén (Líneas paralelas), son archivos lógicos donde se guardan o extraen los datos; Procesos (óvalos), donde la información es procesada; y Flujo de datos (flechas), camino que sigue la información.

Consta de tres niveles; Nivel 0: Diagrama de Contexto, sólo tiene contacto con las entidades externas; Nivel 1 Diagrama de nivel superior, aquí se encuentran los procesos que describen al proceso principal; Nivel 2 Diagrama de detalle, en este se generan procesos de los niveles anteriores.

Para construir un DFD, se lista los eventos, se crea un proceso para cada uno, los cuales deben estar relacionados entre sí y modelados por una salida de flujo datos.

„El resultado de este análisis deberá ser:

• §Gráfico.
• §Lógico , nunca referido a entornos físicos.
• §Preciso y breve.
• §Comprensible.
• §Debidamente particionado.
• §Bien documentado.
• §Nunca redundante.
• §No ambiguo

En los DFD no se deberá modelar:

• §Procedimientos, puntos de inicio y de terminación del DFD.
• §condiciones, tratamientos de errores poco relevantes

Palabras claves: Diagrama | flujo | DFD | Datos.

I ¿Qué es un Diagrama de flujo de datos (DFD)?

Inventados por Larry Constantine, el desarrollador original de diseño estructurado [1], sobre la base de Martin y Estrin de “flujo de datos gráfico”.

Diagramas de flujo de datos describe y analiza el movimiento de datos a través del sistema, ya sea que éste fuera manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. [2]

II Componentes de un Diagrama de Flujo de datos (Simbología) [4]:

III Características

Ø Notación Grafica

Ø Representan flujo de información

Ø Fácilmente intangibles

Ø Permiten descomposición en submodelos [3]

IV Los diagramas derivados de los procesos principales se clasifican en niveles:

Diagrama de contexto de nivel: Este nivel muestra el contexto general del sistema y su entorno operativo y muestra el sistema como un sólo proceso.

Nivel 1 (Diagrama de alto nivel): muestra todos los procesos del nivel 0, almacenes de datos, entidades externas y los flujos de datos entre ellos. El propósito de este nivel es importante para mostrar el alto nivel de los procesos del sistema y su interrelación.

Nivel 2 (bajo nivel): Este nivel es una descomposición de los procesos mostrados en el nivel 1, por lo tanto debe haber un diagrama de nivel 2 para cada proceso que se muestra en el diagrama de nivel 1. [4]

V Construir detalladamente un diagrama de flujo de datos [4].

1. Lista de todos los eventos a realizar.

2. Se construye un proceso para cada caso.

3. Cada proceso está relacionado directamente con otro proceso o a través de almacenes de datos, para que tenga suficiente información para responder a un determinado evento.

4. La reacción de cada proceso de determinado evento es modelada por un saliente de flujo de datos

Referencias:

[1]: W. Stevens, G. Myers, Constantine L, IBM Systems Journal.

[2]: James A. Senn, Mexicano, Autor: sistemas de información, análisis de la información, escritor reconocido de Mc-Graw-Hill

[3] "Structured analysis and system specification", Yourdon, Ing. Informático, consultor, autor y profesor, reconocido por la metodología de la ing. de software. Y DeMarco, Ing. Informático, autor, profesor, y orador de la ing. Del software, reconocido como uno de los desarrolladores de análisis estructurado de la década 1980.

[4] Denis Wilxon Roth, Análisis de Sistemas y Diseño. 3 ª Edición. Wiley Educación Superior (2005)