Modelo ER Y DFD - Examen (2015-2016)

Summary

This document is a past paper for the preparation of technical assistants for information technology related professional exams. The paper covers data modeling techniques, diagrams, and concepts. It includes detailed examples and exercise questions.

Full Transcript

2015-2016 Bloque 3 - Tema 1 MODELO CONCEPTUAL DE DATOS. ENTIDADES, ATRIBUTOS Y RELACIONES. REGLAS DE MODELIZACIÓN. DIAGRAMAS DE FLUJO DE DATOS. REGLAS DE CONSTRUCCIÓN. DESCOMPOSICIÓN EN NIVELES. FLUJOGRAMAS PREPARACIÓN OPOSICIONES TÉCNICOS AUXILIARES DE INFORMÁTICA B3T1...

2015-2016 Bloque 3 - Tema 1 MODELO CONCEPTUAL DE DATOS. ENTIDADES, ATRIBUTOS Y RELACIONES. REGLAS DE MODELIZACIÓN. DIAGRAMAS DE FLUJO DE DATOS. REGLAS DE CONSTRUCCIÓN. DESCOMPOSICIÓN EN NIVELES. FLUJOGRAMAS PREPARACIÓN OPOSICIONES TÉCNICOS AUXILIARES DE INFORMÁTICA B3T1 MODELO ER Y DFD TAI ÍNDICE ÍNDICE............................................................................................................................................................ 2 1. INTRODUCCIÓN......................................................................................................................................... 3 2. MODELO ENTIDAD/RELACIÓN EXTENDIDO............................................................................................... 4 1. Entidad................................................................................................................................................. 5 2. Atributo................................................................................................................................................ 6 3. Relación................................................................................................................................................ 8 4. Dominio.............................................................................................................................................. 12 5. Extensiones del modelo Entidad-Relación.......................................................................................... 13 6. Ejemplo modelo ER extendido............................................................................................................ 15 3. CONSTRUCCIÓN Y VALIDACIÓN DEL MODELO ER.................................................................................... 17 4. DIAGRAMAS DE FLUJO DE DATOS............................................................................................................ 18 1. Entidad externa.................................................................................................................................. 18 2. Proceso............................................................................................................................................... 19 3. Almacén de datos............................................................................................................................... 21 4. Flujo de datos..................................................................................................................................... 21 5. Procesos de control y flujos de control............................................................................................... 23 6. Ejemplo DFD....................................................................................................................................... 23 5. CONSTRUCCIÓN DE UN DFD.................................................................................................................... 25 6. CONSISTENCIA DE LOS DFD: DESCOMPOSICIÓN EN NIVELES.................................................................. 28 7. EJEMPLO DE CONSTRUCCIÓN DE UN DFD............................................................................................... 31 8. FLUJOGRAMAS........................................................................................................................................ 35 PABLO ARELLANO www.theglobeformacion.com Página 2 B3T1 MODELO ER Y DFD TAI 1. INTRODUCCIÓN Este primer tema del bloque de desarrollo de sistemas se centra en el análisis de los datos y de los procesos de negocio de un sistema de información, evidentemente desde un enfoque estructurado. Por un lado, el objetivo de la modelización de datos es el conocimiento profundo de los datos que va a manejar el sistema de información (en adelante SI) objeto de estudio, representado por un modelo de datos, que permite obtener estructuras de datos no redundantes, sin inconsistencias, seguras e íntegras. Al modelo que surge como primera aproximación de ese mundo real se le llama esquema conceptual. De otra parte, los diagramas de flujo de datos nos permiten representar los procesos de negocio que representan el SI, mediante el análisis de las necesidades de usuario. PABLO ARELLANO www.theglobeformacion.com Página 3 B3T1 MODELO ER Y DFD TAI 2. MODELO ENTIDAD/RELACIÓN EXTENDIDO Comenzamos definiendo un modelo de datos como una representación gráfica orientada a la obtención de estructuras de datos de una forma metódica, es decir, se puede considerar un instrumento que nos facilita la representación de las necesidades del usuario. El modelo de datos se suele representar mediante el Modelo Entidad-Relación Extendido, que es la técnica que propone Métrica v3 (metodología de desarrollo de sistemas de información por las Administraciones Públicas), parte de los conceptos y simbología del Modelo Entidad- Relación creado por Peter Chen en 1.976. Por tanto, en el desarrollo de SI siguiendo un enfoque estructurado el Modelo E-R Extendido es el más utilizado en el campo del diseño de bases de datos. Como ya se ha comentado en la introducción este modelo es asimilable al esquema conceptual definido por la arquitectura ANSI/X3/SPARC, la cual será tratada en el tema siguiente. Así pues, el Modelo Entidad-Relación Extendido se trata de una técnica cuyo objetivo es la representación y definición de todos los datos que se introducen, almacenan, transforman y producen dentro de un sistema de información, sin tener en cuenta las necesidades de la tecnología existente, ni otras restricciones. Dado que el modelo de datos es un medio para comunicar el significado de los datos, las relaciones entre ellos y las reglas de negocio de un sistema de información, una organización puede obtener numerosos beneficios de la aplicación de esta técnica, pues la definición de los datos y la manera en que éstos operan son compartidos por todos los usuarios. Las ventajas de realizar un modelo de datos son, entre otras: - Comprensión de los datos de una organización y del funcionamiento de la organización. - Obtención de estructuras de datos independientes del entorno físico. - Control de los posibles errores desde el principio, o al menos, darse cuenta de las deficiencias lo antes posible. - Mejora del mantenimiento. Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es mucho más estable que la estructura de procesos. Como resultado, una estructura de datos estable e integrada proporciona datos consistentes que puedan ser fácilmente accesibles según las necesidades de los usuarios, de manera que, aunque se produzcan cambios organizativos, los datos permanecerán estables. Este diagrama se centra en los datos, independientemente del procesamiento que los transforma y sin entrar en consideraciones de eficiencia. Por ello, es independiente del entorno físico y debe ser una fiel representación del sistema de información objeto del PABLO ARELLANO www.theglobeformacion.com Página 4 B3T1 MODELO ER Y DFD TAI estudio, proporcionando a los usuarios toda la información que necesiten y en la forma en que la necesiten. El modelo Entidad-Relación Extendido describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema, existiendo dos elementos principales: las ENTIDADES y las RELACIONES. Las extensiones al modelo básico añaden además los atributos de las entidades y la jerarquía entre éstas. Estas extensiones tienen como finalidad aportar al modelo una mayor capacidad expresiva. Antes de detallar este modelo, existen otras técnicas para crear modelos conceptuales de base de datos, entre las que destacamos: - Diagramas ORM. - Diagramas IDEF1X. - Diagramas UML. - Diagramas CASE*Method. 1. Entidad Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la base de datos. La estructura genérica de un conjunto de entidades con las mismas características se denomina tipo de entidad. Existen dos clases de entidades: - Regulares: tienen existencia por sí mismas. - Débiles: cuya existencia depende de otra entidad. Las entidades deben cumplir las siguientes tres reglas: - Tienen que tener existencia propia. - Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás. - Todas las ocurrencias de un tipo de entidad deben tener los mismos atributos. Asociado al concepto de entidad surge el concepto de ocurrencia de entidad. Una ocurrencia de entidad es una realización concreta de una entidad. Por ejemplo, si LIBROS es un tipo de entidad, una ocurrencia de la misma es “UML”. Notación La representación gráfica de un tipo de entidad regular es un rectángulo etiquetado con el nombre del tipo de entidad. Un tipo de entidad débil se representa con dos rectángulos concéntricos con su nombre en el interior. PABLO ARELLANO www.theglobeformacion.com Página 5 B3T1 MODELO ER Y DFD TAI Ejemplo: son tipos de entidades regulares libros, facturas, cuentas, clientes, ciudadanos, ciudades, municipios. Ejemplo: son tipos de entidades débiles ejemplar, línea de factura, movimientos. Así, la existencia de un ejemplar depende un libro, la de una línea de factura de una factura y la de un movimiento de una cuenta. 2. Atributo Es una propiedad o característica de un tipo de entidad. Se trata de la unidad básica de información que sirve para identificar o describir la entidad. Un atributo se define sobre un dominio. Por tanto, un atributo es una propiedad común a todas las ocurrencias de una entidad. Ejemplo: son atributos nombre, edad, DNI o fecha de alta. Cada tipo de entidad ha de tener un conjunto mínimo de atributos que identifiquen unívocamente cada ocurrencia del tipo de entidad. Este atributo o atributos se denomina identificador principal o clave primaria. Supongamos que existen varios conjuntos de atributos que identifiquen unívocamente cada ocurrencia del tipo de entidad. Solo uno será el identificador principal o clave primaria. El resto de los conjuntos de atributos se denominarán claves candidatas o alternativas. También ha de conocerse el concepto de superclave, que es un conjunto de atributos (no mínimo) que permite distinguir unívocamente cada ocurrencia del tipo de entidad. Si otro atributo unido al anterior subconjunto, el resultado seguirá siendo una superclave. Claves candidatas Ì Superclaves. Ejemplo: dado el tipo de entidad CONTRIBUYENTE(DNI, nombre, apellidos, dirección, nacionalidad), podemos concluir que: Nombre no es una clave Apellidos no es una clave PABLO ARELLANO www.theglobeformacion.com Página 6 B3T1 MODELO ER Y DFD TAI (nombre, apellidos) no es una clave DNI es una clave candidata à DNI es clave primaria (DNI, nombre) es una superclave (DNI, dirección) es una superclave Se pueden definir restricciones sobre los atributos, según las cuales un atributo puede ser: - Simple: son atributos que no están divididos en partes, es decir, representan un valor indivisible. - Compuesto: atributo que puede ser subdividido en atributos más elementales. Ejemplo: atributo Dirección à vía, nombre, ciudad, provincia y código postal. - Univaluado: atributo que sólo puede tomar un valor para todas y cada una de las ocurrencias del tipo de entidad al que pertenece. - Multivaluado: atributo que puede tomar más de un valor para algunas de las ocurrencias del tipo de entidad al que pertenece. Ejemplo: atributo teléfono puede tomar más de un valor a la vez. - Obligatorio: atributo que tiene que tomar al menos un valor para todas y cada una de las ocurrencias del tipo de entidad al que pertenece. - Derivado: atributo cuyo valor se obtiene a partir de los valores de otros atributos de la misma o de diferente tipo de entidad. Ejemplo: atributo edad deriva del atributo fecha de nacimiento. Notación Un atributo se representa mediante una elipse, con su nombre dentro, conectada por una línea al tipo de entidad o relación. En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un círculo más pequeño con el nombre del atributo a un lado. También pueden representarse en una lista asociada a la entidad. El identificador aparece con el nombre marcado o subrayado, o bien con su círculo en negro. PABLO ARELLANO www.theglobeformacion.com Página 7 B3T1 MODELO ER Y DFD TAI Ejemplo: atributos del tipo de entidad Cliente. Destaca el atributo Dirección que es multivaluado. 3. Relación Es una asociación o correspondencia existente entre una o varias entidades. Una ocurrencia de la relación es la asociación concreta de ocurrencias de entidad de diferentes entidades. Así, por ejemplo, si tenemos las entidades EMPLEADO y DEPARTAMENTO, y la relación Trabaja en, una ocurrencia será “Pepe” trabaja en el “Departamento de Informática”. La relación puede ser: - Regular: si asocia tipos de entidad regulares. - Débil: si asocia un tipo de entidad débil con un tipo de entidad regular. Dentro de las relaciones débiles se distinguen: o La dependencia en existencia: cuando las ocurrencias de un tipo de entidad débil no pueden existir sin la ocurrencia de la entidad regular de la que dependen. o La dependencia en identificación: cuando, además de lo anterior, las ocurrencias del tipo de entidad débil no se pueden identificar sólo mediante sus propios atributos, sino que se les tiene que añadir el identificador de la ocurrencia de la entidad regular de la cual dependen. Clave primaria entidad débil = clave primaria entidad fuerte + clave entidad débil Ejemplo: el tipo de entidad regular CUENTA(numero_cuenta, saldo) se relaciona a través de la relación “Compuesta por” con el tipo de entidad débil MOVIMIENTO(numero_mvto, valor). La relación “Compuesta por” es débil (asocia un tipo regular con un tipo de entidad débil) y la dependencia es en identificación ya que un movimiento concreto no se puede identificar si no se conoce la cuenta sobre la que se hace. Por tanto, tenemos: PABLO ARELLANO www.theglobeformacion.com Página 8 B3T1 MODELO ER Y DFD TAI numero_cuenta es la clave primaria de CUENTA. numero_cuenta, numero_mvto es la clave primaria de MOVIMIENTO. Además, se dice que una relación es exclusiva cuando la existencia de una relación entre dos tipos de entidades implica la no existencia de las otras relaciones. Ejemplo: el tipo de entidad FUNCIONARIO tiene una relación con el tipo de entidad CCAA y otra con el tipo de entidad AYUNTAMIENTOS. Pues ambas relaciones son exclusivas ya que un funcionario solo podrá trabajar en una administración a la vez. Una relación se caracteriza por: - Nombre: que lo distingue unívocamente del resto de relaciones del modelo. - GRADO: número de tipos de entidad sobre las que se establece la relación. La relación del ejemplo anterior es binaria, es decir, de grado dos. En función del grado las relaciones se clasifican en: o Unarias: una entidad se relaciona consigo misma (relaciones reflexivas). GRADO 1 o Binarias: entidades relacionadas dos a dos. GRADO 2 o Ternarias: relación entre tres entidades. GRADO 3 o N-arias: relación entre n entidades. GRADO 4 - TIPO DE CORRESPONDENCIA (o razón de cardinalidad): es el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de la relación que se está tratando. Conceptualmente se pueden identificar tres clases de relaciones: o Relaciones 1:1 (uno a uno): cada ocurrencia de una entidad se relaciona con una y sólo una ocurrencia de la otra entidad. o Relaciones 1:N (uno a muchos): cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra entidad. o Relaciones M:N (muchos a muchos): cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra entidad y cada ocurrencia de la otra entidad puede corresponder a cero, una o varias ocurrencias de la primera. PABLO ARELLANO www.theglobeformacion.com Página 9 B3T1 MODELO ER Y DFD TAI - CARDINALIDAD: representa la participación en la relación de cada una de las entidades afectadas, es decir, el número máximo y mínimo de ocurrencias de un tipo de entidad que pueden estar interrelacionadas con una ocurrencia de otro tipo de entidad (min, max). La cardinalidad máxima coincide con el tipo de correspondencia. MAX= 1, n Según la cardinalidad, una relación es: o Obligatoria: cuando para toda ocurrencia de un tipo de entidad existe al menos una ocurrencia del tipo de entidad asociado. (1, max) o Opcional: cuando, para toda ocurrencia de un tipo de entidad, puede existir o no una o varias ocurrencias del tipo de entidad asociado. (0, max) Las relaciones pueden tener atributos propios, de forma similar que los atributos de los tipos de entidad Notación Se representa por un rombo unido a las entidades relacionadas por dos líneas rectas a los lados. El tipo de correspondencia se representa gráficamente con una etiqueta 1:1, 1:N o M:N, cerca de alguno de los vértices del rombo, o bien situando cada número o letra cerca de la entidad correspondiente, para mayor claridad. La representación gráfica de las cardinalidades se realiza mediante una etiqueta del tipo (0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que corresponda. Si se representan las cardinalidades, la representación del tipo de correspondencia es redundante. Las relaciones reflexivas se consideran un caso particular, en las que una entidad se relaciona consigo misma. Cabe resaltar el concepto de ROL o papel de la entidad (extensible a todo tipo de relaciones pero que resulta agravado en las relaciones reflexivas), esto es, el significado que tiene la participación de las ocurrencias en la relación. El rol se especifica en los extremos de la relación. PABLO ARELLANO www.theglobeformacion.com Página 10 B3T1 MODELO ER Y DFD TAI Para relaciones reflexivas el rol de la entidad debe especificarse, en el resto se considera opcional. Ejemplo: en la siguiente relación entre ocurrencias del tipo de entidad EMPLEADO, conviene distinguir a los empleados que asumirán el rol de “JEFE” y a los empleados que adoptarán el papel de “SUBORDINADO”. SUBORDINADO JEFE En la representación de las relaciones exclusivas se incluye un arco sobre las líneas que conectan el tipo de entidad a los dos o más tipos de relación. Ejemplo: dados los tipos de entidad PERSONA y EDIFICIO y las relaciones USA y POSEE entre ambos tipos de entidad, tenemos: PABLO ARELLANO www.theglobeformacion.com Página 11 B3T1 MODELO ER Y DFD TAI Una persona usa uno o más edificios y un edificio puede ser usado (o no) por una o varias personas. Por otro lado, una persona posee uno o más edificios y un edificio es poseído por una persona. Entonces, el tipo de correspondencia y la cardinalidad es la que se presenta a continuación (se advierte que por claridad expositiva se van a representar ambas, pero se reitera que la cardinalidad incluye el tipo de correspondencia): N:M TIPO DE CORRESPONDENCIA 1:N (1,n) (0,n) CARDINALIDAD (0,1) (1,n) 4. Dominio Es un conjunto nominado de valores homogéneos. El dominio tiene existencia propia con independencia de cualquier entidad, relación o atributo. Así pues, una cierta característica o propiedad (atributo) de un objeto toma valores que pertenecen a un determinado dominio. PABLO ARELLANO www.theglobeformacion.com Página 12 B3T1 MODELO ER Y DFD TAI El dominio para un atributo puede ser, entre otros, un conjunto de enteros, de números reales o de caracteres. 5. Extensiones del modelo Entidad-Relación Además de estos elementos, existen extensiones del modelo entidad/relación que incorporan determinados conceptos o mecanismos de abstracción para facilitar la representación de ciertas estructuras del mundo real: - La GENERALIZACIÓN permite abstraer un tipo de entidad de nivel superior (supertipo) a partir de varios tipos de entidad (subtipos); en estos casos los atributos comunes y relaciones de los subtipos se asignan al supertipo. Se pueden generalizar por ejemplo los tipos profesor y estudiante obteniendo el supertipo persona. - La ESPECIALIZACIÓN es la operación inversa a la generalización, en ella un supertipo se descompone en uno o varios subtipos, los cuales heredan (automáticamente) todos los atributos y relaciones del supertipo, además de tener los suyos propios. Se denominan relaciones "es un". Ejemplo: es el caso del tipo empleado, del que se pueden obtener los subtipos Profesor y PAS. - CATEGORÍAS. Se denomina categoría al subtipo que aparece como resultado de la unión de varios tipos de entidad. En este caso, hay varios supertipos y un sólo subtipo. Si por ejemplo se tienen los tipos persona y compañía y es necesario establecer una relación con vehículo, se puede crear propietario como un subtipo unión de los dos primeros. - La AGREGACIÓN consiste en construir un nuevo tipo de entidad como composición de otros y su tipo de relación y así poder manejarlo en un nivel de abstracción mayor. Ejemplo: se tienen los tipos de entidad empresa y solicitante de empleo relacionados mediante el tipo de relación entrevista, pero es necesario que cada entrevista se corresponda con una determinada oferta de empleo. Como no se permite la relación entre PABLO ARELLANO www.theglobeformacion.com Página 13 B3T1 MODELO ER Y DFD TAI tipos de relación, se puede crear un tipo de entidad compuesto por empresa, entrevista y solicitante de empleo y relacionarla con el tipo de entidad oferta de empleo. El proceso inverso se denomina desagregación. - La ASOCIACIÓN, consiste en relacionar dos tipos de entidades que normalmente son de dominios independientes, pero coyunturalmente se asocian. La existencia de supertipos y subtipos, en uno o varios niveles, da lugar a una jerarquía, que permitirá representar una restricción del mundo real. Notación La representación de las jerarquías se realiza mediante un triángulo invertido, con la base paralela al rectángulo que representa el supertipo y conectando a éste y a los subtipos. Si la división en subtipos viene determinada en función de los valores de un atributo discriminante, éste se representará asociado al triángulo que representa la relación. En el triángulo se representará: - Con una letra d el hecho de que los subtipos sean disjuntos. - Con un círculo o una O si los subtipos pueden solaparse. - Con una U el caso de uniones por categorías. - La presencia de una jerarquía total se representa con una doble línea entre el supertipo y el triángulo. De las representaciones anteriores podemos enunciar las siguientes definiciones: - Jerarquía TOTAL: toda ocurrencia del supertipo pertenece siempre a algún subtipo. PABLO ARELLANO www.theglobeformacion.com Página 14 B3T1 MODELO ER Y DFD TAI - Jerarquía PARCIAL: una ocurrencia del supertipo no pertenece a algún subtipo. - Jerarquía DISJUNTA: una ocurrencia del supertipo solo puede pertenecer a uno de los subtipos. - Jerarquía SOLAPADA: una ocurrencia del supertipo puede pertenecer a varios subtipos. A partir de ahí, se puede mezclar cualquiera de las opciones {total | parcial} con cualquier otra de las siguientes {disjunta | solapada}. 6. Ejemplo modelo ER extendido Modelo entidad-relación extendido para un sistema de gestión de técnicos y su asignación a proyectos dentro de una empresa u organización. Como se aprecia en el diagrama, TÉCNICO es un subtipo de EMPLEADO, generado por especialización, pues era necesario para establecer la relación Trabaja en con PROYECTO, ya que no todos los empleados de la empresa, como los administrativos, son susceptibles de trabajar en un proyecto. La entidad TÉCNICO tendrá los atributos de EMPLEADO más el atributo nivel. PABLO ARELLANO www.theglobeformacion.com Página 15 B3T1 MODELO ER Y DFD TAI PABLO ARELLANO www.theglobeformacion.com Página 16 B3T1 MODELO ER Y DFD TAI 3. CONSTRUCCIÓN Y VALIDACIÓN DEL MODELO ER Podemos establecer para la construcción del modelo conceptual de datos las siguientes fases: 1. Identificar las entidades del SI objeto de desarrollo. Para identificar los tipos de entidad sirve de ayuda clasificar la información en: - Objetos reales: máquinas, edificios, almacenes. - Personas: empleados, funcionarios, clientes, proveedores. - Actividades del sistema: licencias, facturas, albaranes, expedientes, documentos. - Objetos abstractos: categorías de personal, departamentos. 2. Determinar los identificadores principales de las entidades. Para determinarlos, se obtendrán aquellos atributos que identifiquen unívocamente cada ocurrencia de cada tipo de entidad. Si para un tipo de entidad hubiera varios, se elegirá solo uno. Aunque resulta obvio, el conjunto de atributos que forman el identificador principal no pueden tomar valores sin información (nulos). 3. Establecer las relaciones entre las entidades y el grado de las mismas. Para establecer las asociaciones o relaciones entre entidades, se estudia cada una de las relaciones de una entidad con las demás entidades identificadas, para comprobar si dichas relaciones tienen sentido e importancia para el sistema que se está desarrollando. Del conjunto de relaciones se estudiará su cardinalidad y la posibilidad de relaciones exclusivas. 4. Dibujar el modelo de datos. Dibujar el diagrama según la notación descrita. 5. Identificar y describir los atributos de cada entidad. Para identificar los atributos de cada entidad, habrá que tener en cuenta todas aquellas propiedades de cada entidad en las que el sistema tenga interés. Luego se incorporarán al diagrama. 6. Verificaciones. Una vez construido el modelo Entidad-Relación, hay que analizar si se presentan redundancias. Para poder asegurar su existencia se deben estudiar con mucho detenimiento las cardinalidades mínimas de las entidades, así como la semántica de las relaciones. Los atributos redundantes, los que se derivan de otros elementos mediante algún cálculo, deben ser eliminados del modelo Entidad-Relación o marcarse como redundantes. Igualmente, las relaciones redundantes deben eliminarse del modelo, comprobando que al eliminarlas sigue siendo posible el paso, tanto en un sentido como en el inverso, entre las dos entidades que unían. PABLO ARELLANO www.theglobeformacion.com Página 17 B3T1 MODELO ER Y DFD TAI 4. DIAGRAMAS DE FLUJO DE DATOS Durante el análisis de un SI siguiendo un enfoque estructurado, se establece según las especificaciones de los usuarios el conjunto de procesos que conforman el sistema, permitiendo identificar los subsistemas objeto de análisis y, a partir de ellos, la descomposición en sucesivos niveles de procesos, describiendo la estructura de los flujos y de los almacenes de datos. El objetivo del diagrama de flujo de datos (en adelante DFD) es la obtención de un modelo lógico de procesos que represente el sistema, con independencia de las restricciones físicas del entorno. Así se facilita su comprensión por los usuarios y los miembros del equipo de desarrollo. El sistema se divide en distintos niveles de detalle, con el objetivo de: - Simplificar la complejidad del sistema, representando los diferentes procesos de que consta. - Facilitar el mantenimiento del sistema. Un diagrama de flujo de datos es una técnica muy apropiada para reflejar de una forma clara y precisa los procesos que conforman el sistema de información. Permite representar gráficamente los límites del sistema y la lógica de los procesos, estableciendo qué funciones hay que desarrollar. Además, muestra el flujo o movimiento de los datos a través del sistema y sus transformaciones como resultado de la ejecución de los procesos. Esta técnica consiste en la descomposición sucesiva de los procesos, desde un nivel general, hasta llegar al nivel de detalle necesario para reflejar toda la semántica que debe soportar el sistema en estudio. Seguiremos las indicaciones propuestas por la metodología Métrica versión 3 en cuanto a notación de los elementos propios de un DFD. Esta técnica se compone de varios elementos que trataremos a continuación. 1. Entidad externa Una entidad externa representa un ente ajeno al sistema que proporciona o recibe información del mismo. Puede hacer referencia a departamentos, personas, máquinas, recursos u otros sistemas. El estudio de las relaciones entre entidades externas no forma parte del modelo. En definitiva, una entidad externa establece los límites de nuestro sistema. Puede aparecer varias veces en un mismo diagrama, así como en los distintos niveles del DFD para mejorar la claridad del diagrama. Queda fuera del ámbito del sistema las comunicaciones entre entidades externas. PABLO ARELLANO www.theglobeformacion.com Página 18 B3T1 MODELO ER Y DFD TAI Una entidad externa se representa mediante una elipse con un identificador y un nombre significativo en su interior. Si la entidad externa aparece varias veces en un mismo diagrama, se representa con una línea inclinada en el ángulo superior izquierdo. 2. Proceso Un proceso representa una funcionalidad que tiene que llevar a cabo el sistema para transformar o manipular datos. El proceso debe ser capaz de generar los flujos de datos de salida a partir de los de entrada, más una información constante o variable al proceso. El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de datos de entrada en varios de salida y siempre es necesario como intermediario entre una entidad externa y un almacén de datos. Un proceso debe poder generar flujos de salida a partir de los de entrada más, quizás alguna información local al proceso (constante o variable). Cuando el proceso no recibe los flujos de entrada suficientes para generar los de salida, existe un error en la conservación de los datos (Regla de Conservación de Datos). La situación contraria a la anterior, llamada pérdida de información, se produce cuando un flujo de datos de entrada no se utiliza para generar ningún flujo de salida. Un proceso se representa por un rectángulo subdividido en tres casillas donde se indica el nombre del proceso, un número identificativo y la localización. PABLO ARELLANO www.theglobeformacion.com Página 19 B3T1 MODELO ER Y DFD TAI Si el proceso es de último nivel, se representa con un asterisco en el ángulo inferior derecho separado con una línea inclinada (proceso primitivo). El nombre del proceso debe ser lo más representativo posible. Normalmente estará constituido por un verbo más un sustantivo. El número identificativo se representa en la parte superior izquierda e indica el nivel del DFD en que se está. Hay que resaltar que el número no indica orden de ejecución alguno entre los procesos ya que en un DFD no se representa una secuencia en el tratamiento de los datos. El número que identifica el proceso es único en el sistema y debe seguir el siguiente estándar de notación: - El proceso del diagrama de contexto se numera como cero. - Los procesos del siguiente nivel se enumeran desde 1 y de forma creciente hasta completar el número de procesos del diagrama. - En los niveles inferiores se forma con el número del proceso en el que está incluido seguido de un número que lo identifica en ese contexto. La localización expresa el nombre del proceso origen de la descomposición que se esté tratando. PABLO ARELLANO www.theglobeformacion.com Página 20 B3T1 MODELO ER Y DFD TAI 3. Almacén de datos Un almacén de datos representa la información en reposo utilizada por el sistema independientemente del sistema de gestión de datos, ya sea un fichero, una base de datos, un archivador o cualquier otro sistema. Contiene la información necesaria para la ejecución del proceso. Restricciones: - El almacén no puede crear, transformar o destruir datos. - El almacén no puede estar comunicado con otro almacén o entidad externa. - El almacén aparecerá por primera vez en aquel nivel en que dos o más procesos accedan a él. Se representa por dos líneas paralelas cerradas en un extremo y una línea vertical que las une. En la parte derecha se indica el nombre del almacén de datos y en la parte izquierda el identificador de dicho almacén en el DFD. Si un almacén aparece repetido dentro un DFD se puede representar de la siguiente forma: 4. Flujo de datos Un flujo de datos representa el movimiento de los datos, y establece la comunicación entre los procesos y los almacenes de datos o las entidades externas. Un flujo de datos entre dos procesos sólo es posible cuando la información es síncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza su función. Los flujos de datos que comunican procesos con almacenes pueden ser de los siguientes tipos: - De CONSULTA: representan la utilización de los valores de uno o más campos de un almacén o la comprobación de que los valores de los campos seleccionados cumplen unos criterios determinados. - De ACTUALIZACIÓN: representan la alteración de los datos de un almacén como consecuencia de la creación de un nuevo elemento, por eliminación o modificación de otros ya existentes. PABLO ARELLANO www.theglobeformacion.com Página 21 B3T1 MODELO ER Y DFD TAI - De DIÁLOGO: es un flujo entre un proceso y un almacén que representa una consulta y una actualización. Los flujos de datos no pueden crear ni destruir datos y no activan procesos. Únicamente conectan los demás componentes del DFD. Ahora bien, no todas las conexiones entre componentes están permitidas. El siguiente cuadro muestra las conexiones y si están permitidas o no. DESTINO E. externa Proceso Almacén E. externa NO SÍ NO ORIGEN Proceso SÍ SÍ SÍ Almacén NO SÍ NO Otras características de los flujos de datos: - Deben tener un nombre representativo de la información que fluye entre ellos. - Si los datos que viajan por un flujo tienen propósitos distintos o no lo hacen simultáneamente, se trata realmente de dos o más flujos de datos. - Los flujos de datos no indican el control de la ejecución de un proceso, ni cuándo va a comenzar o finalizar su ejecución. - El contenido de un flujo de datos puede ser un dato elemental o un conjunto de varios elementos. Un flujo de datos se representa por una flecha que indica la dirección de los datos, y que se etiqueta con un nombre representativo. La representación de los flujos de datos entre procesos y almacenes es la siguiente: PABLO ARELLANO www.theglobeformacion.com Página 22 B3T1 MODELO ER Y DFD TAI 5. Procesos de control y flujos de control Existen sistemas que precisan de información orientada al control de datos y requieren flujos y procesos de control, así como los mecanismos que desencadenan su ejecución. Para que resulte adecuado el análisis de estos sistemas, se ha ampliado la notación de los diagramas de flujo de datos incorporando los siguientes elementos: - Proceso de control: representa procesos que coordinan y sincronizan las actividades de otros procesos del diagrama de flujo de datos. - Flujo de control: representa el flujo entre un proceso de control y otro proceso. El flujo de control que sale de un proceso de control activa al proceso que lo recibe y el que entra le informa de la situación de un proceso. A diferencia de los flujos tradicionales, que pueden considerarse como procesadores de datos porque reflejan el movimiento y transformación de los mismos, los flujos de control no representan datos con valores, sino que en cierto modo, se trata de eventos que activan los procesos (señales o interrupciones). Un proceso de control se representa por un rectángulo, con trazo discontinuo, subdividido en tres casillas donde se indica el nombre del proceso, un número identificativo y la localización. Se representa por una flecha con trazo discontinuo que indica la dirección de flujo y que se etiqueta con un nombre representativo. 6. Ejemplo DFD La figura es un diagrama de flujos de un Sistema Gestor de Pedidos. En él están representados todos los elementos que pueden intervenir en una Diagrama de Flujo de Datos. PABLO ARELLANO www.theglobeformacion.com Página 23 B3T1 MODELO ER Y DFD TAI PABLO ARELLANO www.theglobeformacion.com Página 24 B3T1 MODELO ER Y DFD TAI 5. CONSTRUCCIÓN DE UN DFD Los diagramas de flujo de datos han de representar el sistema de la forma más clara posible, por ello su construcción se basa en el principio de descomposición o explosión en distintos niveles de detalle. La descomposición por niveles se realiza de arriba abajo (top-down), es decir, se comienza en el nivel más general y se termina en el más detallado, pasando por los niveles intermedios necesarios. De este modo se dispondrá de un conjunto de particiones del sistema que facilitarán su estudio y su desarrollo. La explosión de cada proceso de un DFD origina otro DFD y es necesario comprobar que se mantiene la consistencia de información entre ellos, es decir, que la información de entrada y de salida de un proceso cualquiera se corresponde con la información de entrada y de salida del diagrama de flujo de datos en el que se descompone. En cualquiera de las explosiones puede aparecer un proceso que no necesite descomposición. A éste se le denomina Proceso primitivo y sólo se detalla en él su entrada y su salida, además de una descripción de lo que realiza. En la construcción hay que evitar en lo posible la descomposición desigual, es decir, que un nivel contenga un proceso primitivo, y otro que necesite ser particionado en uno o varios niveles más. El modelo de procesos deberá contener: - Un diagrama de contexto (Nivel 0). - Un diagrama 0 (Nivel 1). - Tantos diagramas 1, 2, 3,... n como funciones haya en el diagrama 0 (Nivel 2). - Tantos niveles intermedios como sea necesario. - Varios DFD en el último nivel de detalle. El diagrama de contexto tiene como objetivo delimitar el ámbito del sistema con el mundo exterior definiendo sus interfaces. En este diagrama se representa un único proceso que corresponde al sistema en estudio, un conjunto de entidades externas que representan la procedencia y destino de la información y un conjunto de flujos de datos que representan los caminos por los que fluye dicha información. A continuación, este proceso se descompone en otro DFD, diagrama 0, en el que se representan los procesos principales o subsistemas. Un subsistema es un conjunto de procesos cuyas funcionalidades tienen algo en común. Éstos deberán ser identificados en base a determinados criterios, como por ejemplo: funciones organizativas o administrativas propias del sistema, funciones homogéneas de los procesos, localización geográfica de los mismos, procesos que actualicen los mismos almacenes de datos, etc. Cada uno de los procesos principales se descompone a su vez en otros que representan funciones más simples y se sigue descomponiendo hasta que los procesos estén PABLO ARELLANO www.theglobeformacion.com Página 25 B3T1 MODELO ER Y DFD TAI suficientemente detallados y tengan una funcionalidad concreta, es decir, sean procesos primitivos. Como resultado se obtiene un modelo de procesos del sistema de información que consta de un conjunto de diagramas de flujo de datos de diferentes niveles de abstracción, de modo que cada uno proporciona una visión más detallada de una parte definida en el nivel anterior. Además de los diagramas de flujo de datos, el modelo de procesos incluye la especificación de los flujos de datos, de los almacenes de datos y la especificación detallada de los procesos que no precisan descomposición, es decir los procesos de último nivel o primitivos. En la especificación de un proceso primitivo se debe describir, de una manera más o menos formal, cómo se obtienen los flujos de datos de salida a partir de los flujos de datos de entrada y características propias del proceso. Dependiendo del tipo de proceso se puede describir el procedimiento asociado utilizando un lenguaje estructurado o un pseudocódigo, apoyándose en tablas de decisión o árboles de decisión. A continuación, se muestra un ejemplo gráfico que representa la de descomposición jerárquica de los diagramas de flujo de datos. PABLO ARELLANO www.theglobeformacion.com Página 26 B3T1 MODELO ER Y DFD TAI PABLO ARELLANO www.theglobeformacion.com Página 27 B3T1 MODELO ER Y DFD TAI 6. CONSISTENCIA DE LOS DFD: DESCOMPOSICIÓN EN NIVELES Una vez construidos los diagramas de flujo de datos que componen el modelo de procesos del sistema de información, es necesario comprobar y asegurar su validez. Para ello, se debe estudiar cada diagrama comprobando que es legible, de poca complejidad y si los nombres asignados a sus elementos ayudan a su comprensión sin ambigüedades. Además, los diagramas deben ser consistentes. En los diagramas hay que comprobar que en un DFD resultado de una explosión: - No falten flujos de datos de entrada o salida que acompañaban al proceso del nivel superior. - No aparezca algún flujo que no estuviese ya asociado al proceso de nivel superior. - Todos los elementos del DFD resultante deben estar conectados directa o indirectamente con los flujos del proceso origen. A continuación, se incluyen ejemplos de la consistencia o inconsistencia de los diagramas de flujo de datos. Ejemplo de consistencia de DFD Sea el diagrama de contexto de la figura siguiente. Los flujos A, C y D, entran al sistema, y el flujo B sale de él. En la explosión del sistema en el diagrama de nivel 1, aparecen todos los flujos, y en su sentido correcto: A y C entran al subsistema o proceso 1, B sale del proceso 2, y D entra en el proceso 3. Se observa que el proceso 3, origina dos flujos de salida: E que va a al proceso 1, y F al proceso 2. PABLO ARELLANO www.theglobeformacion.com Página 28 B3T1 MODELO ER Y DFD TAI La descomposición del proceso 1, muestra los flujos A, C y E correctamente, como entradas a las funciones del diagrama. Los demás flujos están enlazados con los almacenes A1 y A2 del mismo modo que en el diagrama anterior. Ejemplo de inconsistencia de DFD Partiendo del mismo diagrama de contexto utilizado en el anterior ejemplo, los flujos A, C y D, que entran al sistema, y el flujo B, que sale de él, deben aparecer en la primera descomposición, el diagrama de nivel 1. En la figura se aprecia que falta el flujo D, y hay un flujo G que o bien falta en el nivel anterior, sobra en este. PABLO ARELLANO www.theglobeformacion.com Página 29 B3T1 MODELO ER Y DFD TAI Por otro lado, en el proceso 3 no entra ningún flujo, no es posible por tanto que transforme datos saliendo los flujos E y F y además está desconectado del nivel anterior. En el siguiente paso, la inconsistencia más clara es la falta del flujo C, que entra al proceso 1, y sin embargo no aparece en su explosión. Además, hay otra inconsistencia respecto al almacén A1: en el diagrama del nivel anterior, el proceso 1 se conectaba con un flujo de entrada-salida este almacén, cosa que no se refleja en el diagrama de este proceso, en el que sólo aparece uno de entrada. PABLO ARELLANO www.theglobeformacion.com Página 30 B3T1 MODELO ER Y DFD TAI 7. EJEMPLO DE CONSTRUCCIÓN DE UN DFD El caso en estudio es un modelo de procesos de un sistema de información de Conocimientos de técnicos. Según estos conocimientos, los técnicos podrán ser asignados a determinados proyectos de la organización. El sistema recogerá la información referente a los técnicos, procedente de la Dirección técnica de la organización y de los proyectos, procedente de cualquier sección o Unidad de Negocio en las que está dividida dicha organización. Las entidades externas son pues Dirección Técnica y Unidad de Negocio, que introducen los datos al sistema y hacen peticiones de consultas e informes sobre los técnicos y sus conocimientos. El diagrama de contexto será el siguiente: Los flujos de entrada son: Datos Técnicos, con datos de los técnicos introducidos por la Dirección Técnica, así como posibles peticiones de información sobre ellos; y Datos Unidad, que proviene de la Unidad de Negocio, conteniendo datos referentes a la unidad, de proyectos y clientes, así como posibles peticiones de consultas sobre los mismos. Los flujos de salida son: Información Técnicos, que contendrá datos de técnicos, de consulta o informes, para uso de la Dirección Técnica y Consultas Unidad, con datos requeridos por la Unidad de Negocio. El sistema de Conocimientos se descompone en el diagrama de nivel 1, conteniendo dos subsistemas. El subsistema 1 recogerá las funciones a realizar con los datos de los técnicos de la organización (actualizaciones, consultas, informes, etc.), por lo que se denomina Tratar PABLO ARELLANO www.theglobeformacion.com Página 31 B3T1 MODELO ER Y DFD TAI Técnicos. El subsistema 2 contendrá las funciones asociadas al procesamiento de datos de proyectos, por lo que se le da el nombre Tratar Proyectos. En el diagrama se encuentran cuatro almacenes, tres de los cuales son accedidos por funciones de los dos subsistemas: A1 Conocimientos, A2 Proyectos y A3 Técnicos. El cuarto, A4 Clientes, sólo es accedido por el subsistema Tratar Proyectos. Los flujos sin nombre indican que hay entrada y/o salida de todos los datos del almacén. En este diagrama siguen apareciendo las entidades externas para la mayor comprensión del mismo. A partir de ahora, se centrará el ejemplo en la descomposición del subsistema 1 Tratar Técnicos, hasta llegar a su nivel más detallado. PABLO ARELLANO www.theglobeformacion.com Página 32 B3T1 MODELO ER Y DFD TAI En el diagrama resultado de la explosión de Tratar Técnicos, se incluyen cuatro procesos o funciones para el tratamiento completo de éstos. El flujo de entrada Datos Técnicos se compone tanto de los datos profesionales de los técnicos, como de datos de peticiones de información sobre los mismos, por lo cual se ha dividido en dos: Datos Profesionales, que es entrada del proceso 1.1 Validar datos Técnicos y Peticiones Información Técnicos, que entra en la función 1.4 Informar. Para la validación, el proceso 1.1 Validar Datos Técnicos obtiene información del almacén A3 Técnicos y genera una salida, el flujo Datos Técnicos Correctos, que lleva los datos válidos a la función 1.2 Actualizar Almacenes Técnicos. Esta función se encarga de actualizar los almacenes A3 Técnicos y A1 Conocimientos, pero también emite un flujo al proceso 1.3 Asignar a Proyectos. Éste se encarga de hacer asignaciones de técnicos en el almacén A2 Proyectos. PABLO ARELLANO www.theglobeformacion.com Página 33 B3T1 MODELO ER Y DFD TAI La función 1.4 Informar, recibe las peticiones de información sobre técnicos, las procesa utilizando los almacenes necesarios y genera el flujo Información Técnicos que irá a la entidad Dirección Técnica, según muestran los primeros diagramas. Obsérvese que para mayor claridad no se ha incluido ya ninguna entidad externa, y además, se ha repetido el almacén A3 Técnicos, evitando que el cruce de flujos oscurezca la lectura del diagrama. En este momento, todos los procesos se consideran primitivos, excepto el proceso 1.4 Informar, del que se obtiene su descomposición. Sus funciones han de obtener Informes Técnicos y Consultas Técnicos, flujos que componen Información Técnicos que aparecía en el nivel anterior. Por otro lado, también aparece dividido el flujo de entrada Peticiones Información Técnicos, diferenciando la entrada al proceso de consultas o al de emisión de informes. Por último, se puede apreciar que los almacenes son los mismos que se conectaban con el proceso en el nivel anterior y los flujos son de entrada a las funciones. PABLO ARELLANO www.theglobeformacion.com Página 34 B3T1 MODELO ER Y DFD TAI 8. FLUJOGRAMAS Un flujograma o diagrama de flujo consiste en representar gráficamente hechos, situaciones, movimientos o relaciones de todo tipo por medio de símbolos. Un flujograma expresa gráficamente las distintas operaciones que componen un procedimiento o parte de éste, estableciendo su secuencia cronológica, siendo ésta la principal diferencia con un DFD. Los flujogramas son importantes para el diseñador porque le ayudan en la definición, análisis y solución del problema. Según su forma, los flujogramas, pueden ser: - De formato vertical: en los que el flujo o la secuencia de operaciones va de arriba hacia abajo. - De formato horizontal: en los que el flujo o la secuencia de operaciones va de izquierda a derecha. - De bloques: en los que la rutina se representa a través de una secuencia de bloques, cada cual con su significado y encadenados entre sí. Utilizan una simbología más rica y variada que los diagramas anteriores. Por el contenido de lo que representan, nos interesan los flujogramas de sistema y los flujogramas de programa. Los flujogramas de sistema son representaciones gráficas de alto nivel que muestran la forma en que funciona un sistema, ilustrando al menos el orden de los pasos. Son representaciones gráficas que son útiles para usuarios pero que no son formales como los DFD que además tienen mucho más en consideración la información que transita entre lo procesos. Los flujogramas de programa se usan en parte la parte de algorítmica del diseño de los programas (por tanto, en el proceso de diseño de Métrica versión 3) y se basan en estructurar de forma gráfica el algoritmo del programa antes de pasar a su codificación. Para ello, se dispone de grafismos para representar el diagrama. También se utilizan a la hora de especificar los procesos. Los símbolos más utilizados en la construcción de los flujogramas son los siguientes: PABLO ARELLANO www.theglobeformacion.com Página 35 B3T1 MODELO ER Y DFD TAI Símbolo Significado Uso Indica el inicio y el final del diagrama de Inicio / Fin flujo Símbolo de proceso, representa la Operación / Actividad realización de una operación o actividad relativas a un procedimiento Representa cualquier tipo de documento Documento que entra, se utilice, se genere o salga del procedimiento Datos Indica la salida y entrada de datos Indica el depósito permanente de un Almacenamiento / documento o información dentro de un Archivo archivo Indica un punto del flujo en que son Decisión posibles varios caminos alternativos Conecta los símbolos señalando el orden Líneas de flujo en que se deben realizar las distintas operaciones Conector dentro de página. Representa la continuidad del diagrama dentro de la Conector misma página. Enlaza dos pasos no consecutivos en una misma página Representa la continuidad del diagrama en otra página. Representa una conexión o Conector de página enlace con otra hoja diferente en la que continua el diagrama de flujo Entrada manual Representa una entrada manual de datos Representa un proceso predefinido, no es Proceso predefinido necesario detallarlo más Cinta magnética / almacenamiento Almacén de datos secuencial Disco magnético / Almacén de datos base de datos PABLO ARELLANO www.theglobeformacion.com Página 36

Use Quizgecko on...
Browser
Browser