Date post: | 14-Aug-2015 |
Category: |
Documents |
Upload: | luiscarballoc |
View: | 110 times |
Download: | 6 times |
REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
BARINAS EDO. BARINAS
INTEGRANTE:PROFESOR: Ing. Jhoann Zambrano
Colmenares Luis.
C.I: 16.126.937
Sección: S6
Carrera: 47
SAIA
BARINAS, JULIO DE 2015
INTRODUCCION
El presente trabajo es denominado diagrama de flujo de datos. Ilustra una de las
técnicas para representar soluciones a problemas del mundo real en forma visual, es
decir en forma grafica. Esta técnica mediante graficas de flujo ilustra cómo diseñar
los procedimientos o sentencias con coherencia lógica, que representan la solución al
problema planteado.
Hasta la presente década para el desarrollo de cursos, tales como algoritmos y
estructura de datos, no ha existido un software que permita implementar el diagrama
de flujo y en especial permita su ejecución (compilación) y ver los resultados dentro
del mismo diagrama de flujo, según el objetivo del problema; es decir, puede
comprobar la lógica de su algoritmo o lenguaje de programación especifico.
Usando el software DFD (Diagrama de Flujo de Datos).Este producto, cubre en
forma eficiente la ejecución de programas usando Estructuras de control, vectores,
matrices y programación modular dependiente, pero el software tiene limitaciones
para implementar problemas usando Registros, Archivos, Punteros y Diseño de
Programación Independiente.
DIAGRAMA DE FLUJO DE DATOS.
Un Diagrama de Flujo de Datos es una descripción gráfica de un procedimiento
para la resolución de un problema. Son frecuentemente usados para describir
algoritmos y programas de computador. Los diagramas de flujo de datos están
compuestos por figuras conectadas con flechas. Para ejecutar un proceso comienza
por el INICIO y se siguen las flechas de figura a figura, ejecutándose las acciones
indicadas por cada figura; el tipo de figura indica el tipo de paso que representa.
Del Software, DFD es un software diseñado para construir y analizar
algoritmos Ud. puede crear diagramas de flujo de datos para la representación de
algoritmos de programación estructurada a partir de las herramientas de edición que
para éste propósito suministra el programa. Después de haber ingresado el algoritmo
representado por el diagrama, podrá ejecutarlo, analizarlo y depurarlo en un entorno
interactivo diseñado para éste fin. La interfaz gráfica de DFD, facilita en gran medida
el trabajo con diagramas ya que simula la representación estándar de diagramas de
flujo en hojas de papel.
El Diagrama de Flujo de Datos, ilustra una de las técnicas para representar
“Soluciones” a problemas del Mundo Real en forma visual, es decir; en forma
grafica. Esta técnica mediante graficas de Diagrama de Flujo, ilustra como diseñar los
procedimientos o sentencias con coherencia lógica, que representan la solución al
problema planteado. A continuación se muestra una representación gráfica según
algunos autores en cuanto a la simbología para los diagramas de flujo de datos.
Figura: símbolo según algunos autores.
Proceso
Flujo Flujo de Datos
ConectoresEn la página Fuera de la página
Entrada/Salida Mostrada en las líneas de flujo
Almacenamiento de Datos oarchivos
Fuentes o destino de los datos
Figura: Paleta de símbolos para los diagramas de flujo de datos.
Procesamiento deDatos
Materiales
Figura: símbolo según algunos autores.
Proceso
Flujo Flujo de Datos
ConectoresEn la página Fuera de la página
Entrada/Salida Mostrada en las líneas de flujo
Almacenamiento de Datos oarchivos
Fuentes o destino de los datos
Figura: Paleta de símbolos para los diagramas de flujo de datos.
Procesamiento deDatos
Materiales
Figura: símbolo según algunos autores.
Proceso
Flujo Flujo de Datos
ConectoresEn la página Fuera de la página
Entrada/Salida Mostrada en las líneas de flujo
Almacenamiento de Datos oarchivos
Fuentes o destino de los datos
Figura: Paleta de símbolos para los diagramas de flujo de datos.
Procesamiento deDatos
Materiales
También en concepto es el modelo del sistema. Es la herramienta más
importante y la base sobre la cual se desarrollan otros componentes. El modelo
original se detalla en diagramas de bajo nivel que muestran características adicionales
del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez
más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles
para que el analista comprenda la parte del sistema que se encuentra bajo
investigación.
El diagrama físico de datos da un panorama del sistema en uso, dependiente de
la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen
nombres de personas, nombres o números de formato y documento, nombres de
departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados,
ubicaciones, nombres de procedimientos.
El diagrama lógico de datos da un panorama del sistema, pero a diferencia del
físico es independiente de la implantación, que se centra en el flujo de datos entre los
procesos, sin considerar los dispositivos específicos y la localización de los
almacenes de datos o personas en el sistema. Sin indicarse las características físicas.
Características
Sintética: La representación que se haga de un sistema o un proceso deberá
quedar resumido en pocas hojas, de preferencia en una sola. Los diagramas
extensivos dificultan su comprensión y asimilación, por tanto dejan de ser
prácticos.
Simbolizada: La aplicación de la simbología adecuada a los diagramas de
sistemas y procedimientos evita a los analistas anotaciones excesivas,
repetitivas y confusas en su interpretación.
De forma visible a un sistema o un proceso: Los diagramas nos permiten
observar todos los pasos de un sistema o proceso sin necesidad de leer notas
extensas. Un diagrama es comparable, en cierta forma, con una fotografía
aérea que contiene los rasgos principales de una región, y que a su vez permite
observar estos rasgos o detalles principales.
Permitir al analista asegurarse que ha desarrollado todos los aspectos del
procedimiento.
Dar las bases para escribir un informe claro y lógico.
Es un medio para establecer un enlace con el personal que eventualmente
operará el nuevo procedimiento.
Como se Construye
Debe de indicar claramente dónde inicia y dónde termina el diagrama.
Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin.
Organizar los símbolos de tal forma que siga visualmente el flujo de arriba
hacia abajo y de izquierda a derecha.
No usar lenguaje de programación dentro de los símbolos.
Centrar el diagrama en la página.
Las líneas deben ser verticales u horizontales, nunca diagonales.
Ejemplo: DFD de nivel alto de un sistema de procesamiento de pedidos
Cliente
1
Procesar elpedido
3
Procesarfactura
2
Procesarlos datos
deembarque
4
Procesar elembarque
Documentos deEmbarque
Pedido Datos del Pedido
Datos de Embarque
Datos de laFactura
Factura
Pago
Materiales
ELEMENTOS DEL DIAGRAMA DE FLUJO DE DATOS DFD
Los diagramas de flujo son usados comúnmente por los analistas de sistemas
para visualizar las series de procesos en un sistema de negocios. Un diagrama de flujo
es una útil herramienta para diseñar un sistema de negocios eficiente y para
solucionar problemas o mejorar un sistema existente. Estos diagramas están
compuestos por elementos como terminadores, símbolos de procesos, de subprocesos,
de decisiones, líneas con flechas y conectores.
Terminador
Un terminador es representado por un pequeño rectángulo con esquinas
curvas. Los terminadores aparecen al inicio y al final de los diagramas de flujo. El
terminador final aparece solamente una vez en un diagrama.
Procesos
Un proceso es representado por un rectángulo. Éste se refiere a una acción en
un proceso de negocios y debe describirse de forma clara y concisa. Un proceso
puede ser descrito usando una frase única del tipo verbo-sustantivo, por ejemplo
"Ordenar material de oficina". Este mismo nivel de detalle debe mantenerse en los
procesos de un diagrama de flujo.
Subprocesos
Un subproceso está representado por un rectángulo con líneas dobles en cada
lado. Un subproceso es un proceso importante que puede descomponerse en procesos
más simples que pueden desarrollarse en otro diagrama de flujo.
Decisión
Una decisión está representada por un diamante. Un proceso que puede
responder a una decisión de "sí" o "no" requiere un cuadro de decisión.
Conector
Un conector está representado por un pequeño círculo o un cuadro conector y
se etiqueta usando letras. Un diagrama de flujo escrito en una sola página es más
claro que un diagrama en varias páginas. Un conector asegura que los procesos estén
conectados de forma lógica y correcta en varias páginas.
Líneas de flecha
Las líneas de flecha dibujadas en una dirección, de preferencia de arriba hacia
abajo, mantienen la claridad de un diagrama de flujo. Evita líneas de flecha que se
ciclen debido a que esto puede indicar redundancia en el proceso de negocios. Si los
ciclos son necesarios extiende las líneas de flecha hacia arriba y a la izquierda para
mayor claridad.
Bases de datos
Una base de datos es un “almacén” que nos permite guardar grandes
cantidades de información de forma organizada para que luego podamos encontrar y
utilizar fácilmente. Desde el punto de vista informático, la base de datos es 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.
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). Bajo este nombre se conoce a productos de
fabricantes como Oracle, Sybase, Informix, Ingres, Borland, Microsoft, IBM, etc.
Sistema de administración de bases de datos. 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. 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.
Características de DBMS
Bases de datos Jerárquicos: Los datos se organizan en grupos unidos entre ellos por
relaciones de “posesión”, en las que un conjunto de datos puede tener otros conjuntos
de datos, pero un conjunto puede pertenecer sólo a otro conjunto. La estructura
resultante es un árbol de conjuntos de datos.
Bases de datos Reticulares: El modelo reticular es muy parecido al jerárquico, y de
hecho nace como una extensión de este último. También en este modelo conjunto de
datos están unidos por relaciones de posesión, pero cada conjunto de datos puede
pertenecer a uno o más conjuntos.
Bases de datos Relacionales: Las bases de datos que pertenecen a esta categoría se
basan en el modelo relaciones, cuya estructura principal es la relación, es decir una
tabla bidimensional compuesta por líneas y columnas. Cada línea, que en
terminología relacional se llama tulpa, representa una entidad que nosotros queremos
memorizar en la base de datos. Las características de cada entidad están definidas por
las columnas de las relaciones, que se llaman atributos. Entidades con características
comunes, es decir descritas por el mismo conjunto de atributos, formarán parte de la
misma relación.
Base de datos por Objetos (Object-Oriented): El esquema de una base de datos por
objetos está representado por un conjunto de clases que definen las características y el
comportamiento de los objetos que poblarán la base de datos. La diferencia principal
respecto a los modelos examinados hasta ahora es la no positividad de los datos. En
efecto, con una base de datos tradicional (entendiendo con este término cualquier
base de datos no por objetos), las operaciones que se tienen que efectuar en los datos
se les piden a las aplicaciones que los usan. Con una base de datos object-oriented, al
contrario, los objetos memorizados en la base de datos contienen tanto los datos como
las operaciones posibles con tales datos. En cierto sentido, se podrá pensar en los
objetos como en datos a los que se les ha puesto una inyección de inteligencia que les
permite saber cómo comportarse, sin tener que apoyarse en aplicaciones externas.
MODELO RELACIONAL
El modelo relacional constituye una alternativa para la organización y
representación de la información que se pretende almacenar en una base de datos. Se
trata de un modelo teórico matemático que, además de proporcionarnos los elementos
básicos de modelado (las relaciones), incluye un conjunto de operadores (definidos
en forma de un álgebra relacional) para su manipulación, sin ambigüedad posible.
El carácter formal del modelo relacional hace relativamente sencilla su
representación y gestión por medio de herramientas informáticas. No es casual,
pues, que haya sido elegido como referencia para la construcción de la gran
mayoría de los Sistemas de Gestión de Bases de Datos comerciales disponibles en
el mercado; ni tampoco que sea también habitualmente seleccionado como modelo
de referencia para la elaboración del esquema lógico de una base de datos, como
tercer paso de la habitual metodología de diseño de BDs (después del análisis de
requerimientos y la elaboración del esquema conceptual).
En el modelo relacional se basa en el concepto matemático de relación. En este
modelo, la información se representa en forma de “tablas” o relaciones, donde cada
fila de la tabla se interpreta como una relación ordenada de valores (un
conjunto de valores relacionados entre sí).
El siguiente Ejemplo presenta una relación que representa al conjunto de
los departamentos de una determinada empresa, y que recoge información sobre los
mismos.
Num Nombre LocalidadD-01 Ventas ACoruñaD-02 I+D Ferrol
MODELADO DE DATOS
Es una representación abstracta de los datos de una organización y las
relaciones entre ellos. Más aún, podemos decir que, en cierta medida, un modelo de
datos describe una organización. El propósito de un modelo de datos es, por una
parte, representar los datos y, por otra, ser comprensible. El modelado de datos es uno
de los elementos más importantes a la hora de iniciar el desarrollo de cualquier
proyecto. Esta es la estructura, sobre la que realmente reside la verdadera esencia de
la aplicación. Incluso determina si el proyecto va a cumplir con su verdadero
objetivo.
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 entender las relaciones entre las diversas entidades en la Base de
Datos.
Ejemplo:
MODELO ENTIDAD RELACIÓN E-R
Las bases de datos son un gran pilar de la programación actual, ya que nos
permiten almacenar y usar de forma rápida y eficiente cantidades ingentes de datos
con cierta facilidad. En la actualidad se usa de forma mayoritaria las bases de datos
relacionales (dominadas por distintos gestores a través del lenguaje SQL, en gran
medida). Pero ahora vamos a dar un pequeño repaso a lo más esencial del modelo
entidad-relación, que es y ha sido durante años la mejor forma de representar la
estructura de estas bases de datos relacionales (o de representar sus esquemas).
Como ya he comentado este modelo es solo y exclusivamente un método del
que disponemos para diseñar estos esquemas que posteriormente debemos de
implementar en un gestor de BBDD (bases de datos). Este modelo se representa a
través de diagramas y está formado por varios elementos.
Este modelo habitualmente, además de disponer de un diagrama que ayuda a
entender los datos y como se relacionan entre ellos, debe de ser completado con un
pequeño resumen con la lista de los atributos y las relaciones de cada elemento.
Elementos del modelo entidad-relación
Entidad
Las entidades representan cosas u objetos (ya sean reales o abstractos), que se
diferencian claramente entre sí. Para poder seguir un ejemplo durante el artículo
añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes
entidades:
Coches (objeto físico): contiene la información de cada taller.
Empleado (objeto físico): información de los trabajadores.
Cargo del empleado (cosa abstracta): información de la función del
empleado.
Estas entidades se representan en un diagrama con un rectángulo, como los
siguientes.
Ejemplo:
Atributos
Los atributos definen o identifican las características de entidad (es el contenido
de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre
esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha)
Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad
“Coches“, que nos darán información sobre los coches de nuestro supuesto taller.
Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI
del propietario, marca, modelo y muchos otros que complementen la información de
cada coche.
Los atributos se representan como círculos que descienden de una entidad, y no
es necesario representarlos todos, sino los más significativos, como a continuación.
Coches (objeto físico): contiene la información de cada taller.
Empleado (objeto físico): información de los trabajadores.
Cargo del empleado (cosa abstracta): información de la función del
empleado.
Estas entidades se representan en un diagrama con un rectángulo, como los
siguientes.
Ejemplo:
Atributos
Los atributos definen o identifican las características de entidad (es el contenido
de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre
esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha)
Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad
“Coches“, que nos darán información sobre los coches de nuestro supuesto taller.
Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI
del propietario, marca, modelo y muchos otros que complementen la información de
cada coche.
Los atributos se representan como círculos que descienden de una entidad, y no
es necesario representarlos todos, sino los más significativos, como a continuación.
Coches (objeto físico): contiene la información de cada taller.
Empleado (objeto físico): información de los trabajadores.
Cargo del empleado (cosa abstracta): información de la función del
empleado.
Estas entidades se representan en un diagrama con un rectángulo, como los
siguientes.
Ejemplo:
Atributos
Los atributos definen o identifican las características de entidad (es el contenido
de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre
esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha)
Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad
“Coches“, que nos darán información sobre los coches de nuestro supuesto taller.
Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI
del propietario, marca, modelo y muchos otros que complementen la información de
cada coche.
Los atributos se representan como círculos que descienden de una entidad, y no
es necesario representarlos todos, sino los más significativos, como a continuación.
En un modelo relacional (ya implementado en una base de datos) un ejemplo de tabla
dentro de una BBDD podría ser el siguiente.
Ejemplo:
Número de chasis Matrícula DNI del propietario
5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J
Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese
necesario) y seguirían la misma estructura de columnas, tras implementarlo en una
BBDD.
Relación
Es un vínculo que nos permite definir una dependencia entre varias entidades,
es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma
indispensable.
En un modelo relacional (ya implementado en una base de datos) un ejemplo de tabla
dentro de una BBDD podría ser el siguiente.
Ejemplo:
Número de chasis Matrícula DNI del propietario
5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J
Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese
necesario) y seguirían la misma estructura de columnas, tras implementarlo en una
BBDD.
Relación
Es un vínculo que nos permite definir una dependencia entre varias entidades,
es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma
indispensable.
En un modelo relacional (ya implementado en una base de datos) un ejemplo de tabla
dentro de una BBDD podría ser el siguiente.
Ejemplo:
Número de chasis Matrícula DNI del propietario
5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J
Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese
necesario) y seguirían la misma estructura de columnas, tras implementarlo en una
BBDD.
Relación
Es un vínculo que nos permite definir una dependencia entre varias entidades,
es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma
indispensable.
Por ejemplo, los empleados del taller (de la entidad “Empleados“) tienen un
cargo (según la entidad “Cargo del empleado“). Es decir, un atributo de la entidad
“Empleados“especificará que cargo tiene en el taller, y tiene que ser idéntico al que
ya existe en la entidad “Cargo del empleado“.
Las relaciones se muestran en los diagramas como rombos, que se unen a las
entidades mediante líneas.
Ejemplo:
Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como participen en ellas
las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero
un mismo cargo lo pueden compartir varios empleados. Esto complementa a las
representaciones de las relaciones, mediante un intervalo en cada extremo de la
relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en
esa relación.
Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por
ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas
deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada
matrícula un chasis, ni más en ningún caso).
Ejemplo:
Por ejemplo, los empleados del taller (de la entidad “Empleados“) tienen un
cargo (según la entidad “Cargo del empleado“). Es decir, un atributo de la entidad
“Empleados“especificará que cargo tiene en el taller, y tiene que ser idéntico al que
ya existe en la entidad “Cargo del empleado“.
Las relaciones se muestran en los diagramas como rombos, que se unen a las
entidades mediante líneas.
Ejemplo:
Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como participen en ellas
las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero
un mismo cargo lo pueden compartir varios empleados. Esto complementa a las
representaciones de las relaciones, mediante un intervalo en cada extremo de la
relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en
esa relación.
Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por
ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas
deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada
matrícula un chasis, ni más en ningún caso).
Ejemplo:
Por ejemplo, los empleados del taller (de la entidad “Empleados“) tienen un
cargo (según la entidad “Cargo del empleado“). Es decir, un atributo de la entidad
“Empleados“especificará que cargo tiene en el taller, y tiene que ser idéntico al que
ya existe en la entidad “Cargo del empleado“.
Las relaciones se muestran en los diagramas como rombos, que se unen a las
entidades mediante líneas.
Ejemplo:
Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como participen en ellas
las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero
un mismo cargo lo pueden compartir varios empleados. Esto complementa a las
representaciones de las relaciones, mediante un intervalo en cada extremo de la
relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en
esa relación.
Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por
ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas
deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada
matrícula un chasis, ni más en ningún caso).
Ejemplo:
Uno a varios o varios a uno: Determina que un registro de una entidad puede
estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez.
Como ha sido en el caso anterior del trabajador del taller.
Ejemplo:
Varios a varios: Determina que una entidad puede relacionarse con otra con
ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser
reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios
coches distintos.
Ejemplo:
Los indicadores numéricos indican el primero el número mínimo de registros en una
relación y posteriormente el máximo (si no hay límite se representa con una “n“).
Claves
Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de
los demás registros (no permitiendo que el atributo específico se repita en la entidad)
o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son
los distintos tipos:
Uno a varios o varios a uno: Determina que un registro de una entidad puede
estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez.
Como ha sido en el caso anterior del trabajador del taller.
Ejemplo:
Varios a varios: Determina que una entidad puede relacionarse con otra con
ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser
reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios
coches distintos.
Ejemplo:
Los indicadores numéricos indican el primero el número mínimo de registros en una
relación y posteriormente el máximo (si no hay límite se representa con una “n“).
Claves
Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de
los demás registros (no permitiendo que el atributo específico se repita en la entidad)
o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son
los distintos tipos:
Uno a varios o varios a uno: Determina que un registro de una entidad puede
estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez.
Como ha sido en el caso anterior del trabajador del taller.
Ejemplo:
Varios a varios: Determina que una entidad puede relacionarse con otra con
ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser
reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios
coches distintos.
Ejemplo:
Los indicadores numéricos indican el primero el número mínimo de registros en una
relación y posteriormente el máximo (si no hay límite se representa con una “n“).
Claves
Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de
los demás registros (no permitiendo que el atributo específico se repita en la entidad)
o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son
los distintos tipos:
Superclave: Aplica una clave o restricción a varios atributos de la entidad, para
así asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en
dudas al querer identificar un registro.
Clave primaria: identifica inequívocamente un solo atributo no permitiendo
que se repita en la misma entidad. Como sería la matrícula o el número de chasis de
un coche (no puede existir dos veces el mismo).
Clave externa o clave foránea: este campo tiene que estar estrictamente
relacionado con la clave primaria de otra entidad, para así exigir que exista
previamente ese clave. Anteriormente hemos hablado de ello cuando comentábamos
que un empleado indispensablemente tiene que tener un cargo (que lo hemos
representado numéricamente), por lo cual si intentásemos darle un cargo inexistente
el gestor de bases de datos nos devolvería un error.
CONCLUSION
Se puede concluir del trabajo antes presentado que muchas personas consideran
a un algoritmo y a un diagrama de flujo de datos como herramienta de gran
importancia para la programación de computadora y están en lo cierto para la
resolución de problemas mediante algoritmos y diagramas de flujo se ha convertido
hoy en día en un instrumento efectivo para el desarrollo de habilidades y destrezas
lógicas de y creativas del pensamiento humano.
Hoy diferentes formas de resolver un problema, esto es debido a la forma de
razonar del ser humano, al igual que cada algoritmo, o diagrama de flujo de datos
elaborado. El término lógica define la exposición de leyes, modos y formas aplicadas
al razonamiento. El ser humano aplica la lógica para la resolución de problemas de
diferentes tipos. Algunos instructores del área de computación no hacen mucho
hincapié sobre el desarrollo de algoritmo y diagramas de flujo de datos.
Cabe destacar, que el lenguaje utilizado para especificar la función del
diagrama de flujo, no es más que el lenguaje que utilizamos diariamente, pero
adoptando ciertos verbos y frases imperativas, para describir de manera exacta y
precisa lo que se quiere realizar.
BIBLIOGRAFIA
www.maestrosdelweb.com
www.monografias.com
http://www.mastermagazine.info/termino/4544.php
www.genbetadev.com/bases-de-datos/fundamento-de-las-bases-de-datos-
modelo-entidad-relación.
http://mundoinformatico321.blogspot.com/2013/02/diagrama-de-flujo-de-
datos.html