Modelos de análisis estructurado

26
Instituto Universitario Politécnico “Santiago Mariño” Extensión Barinas Materia: Bachiller: Planificación de sistemas Modelos de análisis estructurad

Transcript of Modelos de análisis estructurado

Instituto Universitario Politécnico

“Santiago Mariño”

Extensión Barinas

Materia:

Bachiller: Planificación de sistemas

Yolimar Guerrero Prof: Jhoann Zambrano

C.I.V-20.964.550

Modelos de

análisis

estructurado.

Barinas, Julio de 2015.

ÍNDICE.

Introducción

4

Diagrama de flujo de datos DFD 5

Elementos del DFD 6

Bases de Datos 12

DBMS 13

Modelo Relacional 13

Modelado de datos  14

Modelo entidad relación 15

Conclusión 21

Bibliografía 22

Introducción.

El diagrama de flujo de datos es un modelo que describe los flujos

de datos o tuberías, los procesos que cambian o transforman los datos

en un sistema, las entidades externas que son fuente o destino de los

datos (y en consecuencia los límites del sistema) y los almacenamientos

o depósitos de datos a los cuales tiene acceso el sistema, permitiendo

así describir el movimiento de los datos a través del sistema.

Una base de datos proporciona a los usuarios el acceso a datos,

que pueden visualizar, ingresar o actualizar, en concordancia con los

derechos de acceso que se les hayan otorgado. Se convierte más útil a

medida que la cantidad de datos almacenados crece.

Una base de datos puede ser local, es decir que puede utilizarla

sólo un usuario en un equipo, o puede ser distribuida, es decir que la

información se almacena en equipos remotos y se puede acceder a ella

a través de una red.

La principal ventaja de utilizar bases de datos es que múltiples

usuarios pueden acceder a ellas al mismo tiempo.

Rápidamente surgió la necesidad de contar con un sistema de

administración para controlar tanto los datos como los usuarios. La

administración de bases de datos se realiza con un sistema llamado

DBMS (Database management system [Sistema de administración de

bases de datos]). El DBMS es un conjunto de servicios (aplicaciones de

software) para administrar bases de datos, que permite un fácil acceso

a los datos, el acceso a la información por parte de múltiples usuarios y

4

la manipulación de los datos encontrados en la base de datos (insertar,

eliminar, editar).

Diagrama de Flujo de Datos.

Es un gráfico lógico del plan de trabajo que se ejecutara para la

solución de un determinado problema. A través de él, se planifica la

solución del problema independiente del lenguaje de computación a

usar. De esta manera se separa loas instrucción es un lenguaje

determinado con todas las reglas.

Las capacidades humanas necesarias para elaborar un diagrama

de flujo correcto son: Lógico, Prácticas, y Atención.

El empleo de la maquina en las funciones del procediendo de

datos han hecho necesario un flujo ordenado de la información. La

secuencia en que deberán ejecutarse las operaciones tendrá que

definirse claramente, y cuando se combine con los datos a los que debe

aplicarse, esa secuencia creara el flujo de información.

No puede hacerse mucho hincapié en documentación, ósea el

registro de Información .Sin Instrucciones escritas y sin

representación gráfica del flujo de trabajo sería muy difícil de llevar

una tarea de procediendo de datos en forma apropiada. Hay varios

métodos más eficientes organizados y normalizados, es el de los

diagramas de Flujo que el Futuro programador comprenda la necesidad

de los diagrama de flujo.

Objetivos de un diagrama de flujo.

5

Estructura la solución del problema independiente del lenguaje a

utilizar.

Separar la solución lógica de programación de la parte de reglas y

sintaxis de codificación con esta división del trabajo se obtiene mayor

eficiencia.

Dar una visión completa del problema al programador ya que

pierde en un programa ya codificado.

Permitir una compresión más rápida del programa a otros

programadores.

Elementos Básicos.

El diagrama de flujo de datos (DFD) proporciona una

representación del sistema a nivel lógico y conceptual, para lo cual

utiliza una notación y unas reglas predeterminadas.

La técnica de representación dará lugar a un DFD (Diagrama de

Flujo de Datos) en el que se muestran los principales procesos o

acciones a desarrollar, los mismos que se van detallando según se baje

de nivel, es decir al EXPLOSIONAR cada uno de los procesos.

La comunicación existente entre esas actividades se representa

entre el resto de los elementos.

Los elementos básicos que aparecen en cualquier Diagrama de

Flujo de Datos, son los siguientes:

o Entidad Externa.

o Proceso.

o Almacén de Datos.

6

o Flujo de Datos.

Varios de ellos pueden tener alguna restricción, únicamente con

respecto al nivel en el cual pueden o deben aparecer.

Entidad Externa.

Las Entidades Externas representan entes ajenos a nuestra

aplicación, pero que aportan o reciben información de la misma. Se

representa mediante una elipse o un rectángulo con un nombre

significativo dentro.

Reglas de Construcción:

1. Representa personas, organizaciones o sistemas que no

pertenecen al sistema.

2. En el caso que las entidades externas se comuniquen entre

sí, ésto, no se contemplaría en el diagrama, por estar fuera

del ámbito de nuestro sistema.

3. Puede aparecer en los distintos niveles del DFD.

4. Puede aparecer varias veces en un mismo diagrama, para

evitar entrecruzamientos de líneas.

5. Suministra información acerca de la conexión del sistema

con el mundo exterior.

7

Proceso.

Es una actividad que transforma o manipula datos. Se representa

mediante un rectángulo, de la siguiente manera:

En la parte de PROCESO, se expresa el nombre correspondiente.

Dependiendo del nivel de detalle en que nos encontremos dentro

de un DFD, el nombre del proceso simbolizará bien el sistema concreto

(nivel sistema), bien el subsistema de que se trate (nivel subsistema), o

bien acciones concretas y detalladas en niveles inferiores.

En la parte superior izquierda se coloca un número que

identifique al proceso que permitirá, además, indicar el nivel del DFD

en que nos encontramos. Esto se explicará más en detalle cuando se

hable de la descomposición por niveles.

Es importante poner énfasis en que este número no indica

secuencia de realización del proceso, dado que los DFD no representan

una continuidad en el tratamiento de los datos.

8

La parte de localización expresa la unidad o área dentro de la

organización donde se realiza este proceso.

Reglas de Construcción:

1. Cuando un Flujo de datos entra en un proceso, sufre una

transformación. Un proceso no es ni origen ni final de los

datos, sólo lugar de transformación de los mismos. Por ello,

cualquier flujo de datos que entre en un proceso, ha de

transformarse.

2. Un proceso puede transformar un dato, en varios.

3. Es necesario un proceso como intermediario entre una

Entidad Externa y un Almacén de Datos.

Almacén de Datos.

Un almacén de datos representa un depósito de información

dentro del sistema.

Se representa dentro del DFD con la siguiente figura:

9

En la parte derecha se indica el nombre del almacén de datos y en

la parte izquierda se representa la identificación de dicho almacén

dentro del DFD.

En el caso que dentro de un DFD aparezca repetido el mismo

almacén de datos, se puede representar de la siguiente forma:

Es conveniente distinguir las diferentes utilidades que presentan

los almacenes de datos.

o En primer lugar, el almacenamiento permanente de datos,

donde se guardan los datos que sirven de referencia de uso

del sistema, es decir, los datos permanentes, sobre los que

el sistema necesita guardar información (ALMACENES

PRINCIPALES).

o Por otra parte, el almacenamiento transitorio de los datos

antes de ser usados por un proceso.

Para entender el significado de estos almacenes transitorios, se

puede imaginar la situación del ejemplo de la figura siguiente:

10

En este ejemplo, el proceso RECOGER SOLICITUDES, que se

ejecuta continuamente a lo largo de la jornada, genera los datos de

salida representados por el flujo de datos SOLICITUDES. Estos datos

constituyen los datos de entrada al proceso VALIDAR SOLICITUD, que

se ejecuta al final de la jornada. En el intervalo, esos datos de solicitud

"reposarían" en el almacén SOLIC. PROV. Cuya utilidad básica es

establecer una sincronización en el funcionamiento de ambos procesos.

Los almacenes transitorios suelen representar restricciones

físicas del sistema y por tanto en un DFD, que expresa la lógica de los

tratamientos realizados por el sistema, en muchos casos no será

necesario representarlos.

Sin embargo, hay ocasiones en que estos almacenes simbolizan

"ficheros de movimientos" donde se guardan los datos, porque el

proceso siguiente necesita manejarlos todos al mismo tiempo (por

ejemplo, en un proceso que compara un conjunto de registros, será

necesario mantenerlos guardados en un almacén transitorio, para que

11

dicho proceso los lea todos al mismo tiempo). En este caso sí será

conveniente representarlos.

Por último, para asegurar la consistencia entre todas las técnicas

utilizadas en la Fase de Análisis, se establecerá una relación precisa

entre los almacenes de datos "principales" de un DFD y las entidades

de los Diagramas de Estructura de Datos (DED): "cada almacén

principal de un DFD representa un conjunto completo de entidades del

DED (una o varias entidades) y cada entidad de un DED pertenece a un

único almacén principal de un DFD". Esto facilitará las validaciones

cruzadas entre los dos diagramas.

Reglas de construcción:

3. Representa la información en reposo.

4. No puede crear, destruir ni transformar datos.

5. No puede estar comunicado directamente con otro Almacén

o Entidad Externa.

6. El flujo de datos (Entrada o Salida) no lleva nombre cuando

incide sobre su contenido completo.

7. El almacén de datos aparecerá por vez primera en aquel

nivel en que sea accedido por dos o más procesos y en modo

lectura y/o escritura.

8. No debe estar referido al entorno físico y por tanto, no se

diferencian los ficheros convencionales de las Bases de

Datos.

9. No se representa la clave de acceso a ese almacén, sino sólo

la operación que se realiza (lectura, escritura,

actualización).

Flujo de Datos.

12

Los Flujos de Datos establecen la comunicación entre procesos,

almacenes y entidades externas, llevando información necesaria.

Reglas de construcción:

1. El concepto de flujo de datos es similar al de una "tubería",

a través de la cual fluye una información de estructura

conocida.

2. Los datos no pueden ser creados ni destruidos por un flujo

de datos.

3. Sirve para conectar el resto de los componentes del DFD.

4. No es un activador de procesos.

5. Cuando un proceso almacena datos, la flecha de flujo de

datos se indica en la dirección del almacén de datos y a la

inversa, si es el proceso el que lee datos en el almacén.

Bases de datos.

Son un sistema formado por un conjunto de datos almacenados en

discos que permiten el acceso directo a ellos y un conjunto de

programas que manipulen ese conjunto de datos.

Cada base de datos se compone de una o más tablas que guarda

un conjunto de datos. Cada tabla tiene una o más columnas y filas. Las

columnas guardan una parte de la información sobre cada elemento

que queramos guardar en la tabla, cada fila de la tabla conforma un

registro.

Se define una base de datos como una serie de datos organizados

y relacionados entre sí, los cuales son recolectados y explotados por los

sistemas de información de una empresa o negocio en particular.

13

Características.

Entre las principales características de los sistemas de base de datos

podemos mencionar:

Independencia lógica y física de los datos.

Redundancia mínima.

Acceso concurrente por parte de múltiples usuarios.

Integridad de los datos.

Consultas complejas optimizadas.

Seguridad de acceso y auditoría.

Respaldo y recuperación.

Acceso a través de lenguajes de programación estándar.

DBMS.

(Data Base Management System). Son las siglas en inglés para los

Sistemas de Gestión de Bases de Datos (SGBD).

El Sistema de administración de bases de datos es el software que

controla la organización, almacenamiento, recuperación, seguridad e

integridad de los datos en una base de datos. Acepta solicitudes de la

aplicación y ordena al sistema operativo transferir los datos apropiados.

Los DBMS pueden trabajar con lenguajes de programación

tradicionales (COBOL, C, etc.) O pueden incluir su propio lenguaje de

programación. Por ejemplo, dbase y Paradox son programas de base de

datos con un DBMS, un lenguaje completo de programación y un

lenguaje de cuarta generación, haciendo de ellos sistemas completos de

desarrollo de aplicaciones.

14

Los comandos de los lenguajes de cuarta generación permiten a

los usuarios crear en forma interactiva archivos de bases de datos,

editarlos, formular preguntas e imprimir informes sin necesidad de

programación. Miles de aplicaciones han sido desarrolladas en

ambientes como éstos.

Modelo Relacional.

El modelo relacional para la gestión de una base de datos es

un modelo de datos basado en la lógica de predicados y en la teoría de

conjuntos. Es el modelo más utilizado en la actualidad para modelar

problemas reales y administrar datos dinámicamente. Tras ser

postuladas sus bases en 1970 por Edgar Frank Codd, de los

laboratorios IBM en San José (California), no tardó en consolidarse

como un nuevo paradigma en los modelos de base de datos.

Su idea fundamental es el uso de «relaciones». Estas relaciones

podrían considerarse en forma lógica como conjuntos de datos llamados

«tuplas». Pese a que ésta es la teoría de las bases de datos relacionales

creadas por Edgar Frank Codd, la mayoría de las veces se

conceptualiza de una manera más fácil de imaginar, esto es, pensando

en cada relación como si fuese una tabla que está compuesta

por registros (cada fila de la tabla sería un registro o tupla),

y columnas (también llamadas campos).

En este modelo todos los datos son almacenados en relaciones, y

como cada relación es un conjunto de datos, el orden en el que éstos se

almacenen no tiene relevancia (a diferencia de otros modelos como

el jerárquico y el dered). Esto tiene la considerable ventaja de que es

más fácil de entender y de utilizar por un usuario no experto. La

información puede ser recuperada o almacenada por medio de

15

consultas que ofrecen una amplia flexibilidad y poder para administrar

la información.

Este modelo considera la base de datos como una colección de

relaciones. De manera simple, una relación representa una tabla que no

es más que un conjunto de filas, cada fila es un conjunto de campos y

cada campo representa un valor que interpretado describe el mundo

real. Cada fila también se puede denominar tupla o registro y a cada

columna también se le puede llamar campo o atributo.

Para manipular la información utilizamos un lenguaje relacional,

actualmente se cuenta con dos lenguajes formales el Álgebra

relacional y el Cálculo relacional. El Álgebra relacional permite

describir la forma de realizar una consulta, en cambio, el Cálculo

relacional sólo indica lo que se desea devolver.

Modelado De Datos

El modelado de datos es una técnica independiente de la

implementación a la base de datos. Esto es importante, porque

la metodología L5, siempre busca que se saque el máximo provecho de

diversas herramientas. En particular, el esquema final y su

implementación pueden sufrir cambios sin afectar de manera drástica

la Lógica de Programación.

Uno de los puntos importantes que se deben indicar es que el

modelado de los datos, debe ser llevado como una guía general. Para

los profesionales expertos, esto implica el desarrollo de los Diagramas

de Entidades y del Modelo Entidad-Relación. Independientemente de la

metodología a utilizar, esta herramienta siempre será importante, para

16

entender las relaciones entre las diversas entidades en la Base de

Datos.

Modelo entidad-relación.

Los diagramas o modelos entidad-relación (denominado por su

siglas, ERD “Diagram Entity relationship”) son una herramienta para el

modelado de datos de un sistema de información. Estos modelos

expresan entidades relevantes para un sistema de información, sus

inter-relaciones y propiedades.

Cardinalidad de las Relaciones.

El diseño de relaciones entre las tablas de una base de datos puede ser

la siguiente:

Relaciones de uno a uno: una instancia de la entidad A se

relaciona con una y solamente una de la entidad B.

Relaciones de uno a muchos: cada instancia de la entidad A se

relaciona con varias instancias de la entidad B.

17

Relaciones de muchos a muchos: cualquier instancia de la

entidad A se relaciona con cualquier instancia de la entidad B.

Representación del Objeto de Estudio en el Mundo de los Datos.

• Entidades.

• Atributos de las Entidades.

• Atributo llave.

• Relaciones entre las Entidades.

• Modelo gráfico de las Entidades y sus Relaciones. (Diagrama Entidad

Relación)

• Modelo Lógico de los Datos.

Obtención del Diagrama Entidad Relación

18

Componentes y Diagrama E-R

Entidad Regular: Una Entidad fuerte (también conocida como

entidad regular es aquella que sí puede ser identificada unívocamente.

En los casos en que se requiera, se puede dar que una entidad fuerte

"preste" algunos de sus Atributos a una entidad débil para que, esta

última, se pueda identificar.

Entidad débil: Es aquella que no puede existir sin participar en

la relación, es decir, aquella que no puede ser unívocamente

identificada solamente por sus atributos como Clave.

Relaciones: La relación existente entre las entidades. Inscriben a

cada entidad en un Conjunto de entidades. Un conjunto de entidades

dentro de una entidad, tiene valores específicos asignados para cada

uno de sus atributos, de esta forma, es posible su identificación

unívoca.

19

Ejemplos:

A la colección de entidades Alumnos, con el siguiente conjunto de

atributos en común, (id, nombre, edad, semestre), pertenecen las

entidades: (1, Sofía, 18 años, 2)(2, Josefa, 19 años, 5) (3, Gabriela, 20

años, 29).

Conector: Separador Una Clave principal se utiliza para

relacionar una tabla con claves externas de otras tablas.) Consta de dos

campos: las claves externas Clave externa: uno o más campos de tabla

(columnas) que hacen referencia al campo o campos de clave principal

de otra tabla.

Una Clave externa indica cómo están relacionadas las tablas A y

B. Una relación de Varios a varios no es sino dos relaciones de Uno a

varios con una tercera tabla. Por ejemplo, la tabla Pedidos y la tabla

Productos tienen una relación de Varios a varios que se define mediante

la creación de dos relaciones de Uno a varios con la tabla Detalles de

pedidos.

Un pedido puede incluir muchos productos, y cada producto

puede aparecer en muchos pedidos. Ejemplo: personas y viviendas.

Ejemplo de modelo de entidad-relación.

Se desea almacenar la información de una compañía aérea en una

B.D relacional.

La compañía aérea tiene tres recursos principales: Aviones, pilotos,

tripulación. De cada pila se desea conocer su cod. Nombre y horas de

20

vuelo. De los miembros de la tripulación solo se tendrá el cod y el

nombre.

Pilotos y tripulación tienen una base a la que regresan después de

cada jornada un vuelo va desde un origen a un destino a una hora

concreta y tiene # de vuelo, de cada vuelo que se va a realizar durante

los próximos 3 meses, así como de los vuelos que se han realizado se

desea saber el avión en el que se va a hacer o en el que se ha hecho, el

piloto y la tripulación. Cada avión tiene un cod, es de un tipo (boing,

airbus, entre otros). Y tiene una base donde es sometido a

mantenimiento.

21

22

Conclusión.

Cuando se utiliza una base de datos para gestionar información,

se está plasmando una parte del mundo real en una serie de tablas,

registros y campos ubicados en un ordenador; creándose un modelo

parcial de la realidad. Antes de crear físicamente estas tablas en el

ordenador se debe realizar un modelo de datos.

Se suele cometer el error de ir creando nuevas tablas a medida que

se van necesitando, haciendo así el modelo de datos y la construcción

física de las tablas simultáneamente. El resultado de esto acaba siendo

un sistema de información parcheado, con datos dispersos que

terminan por no cumplir adecuadamente los requisitos necesarios.

El modelo relacional para la gestión de una base de datos es un

modelo de datos basado en la lógica de predicados y en la teoría de

conjuntos. Es el modelo más utilizado en la actualidad para modelar

problemas reales y administrar datos dinámicamente.

23

Bibliografía.

Http://mundoinformatico321.blogspot.com/2013/02/diagrama-de-flujo-

de-datos.html

Http://www.ongei.gob.pe/publica/metodologias/lib5081/cap0302.htm

Http://www.maestrosdelweb.com/que-son-las-bases-de-datos/

Http://basdatos.tripod.com/ejercicios.html

Http://www.mastermagazine.info/termino/4544.php

Https://es.wikipedia.org/wiki/Modelo_relacional

Http://www.maestrosdelweb.com/modelado-de-datos-e-implementacion-

de-la-base-de-datos-primer-nivel-l5/

24