TEMA1

UD012107_V(02) MD.PlantillaTexto(04)Esp.
dot
MODELO CONCEPTUAL DE DATOS

ÍNDICE
TU RETO EN ESTA UNIDAD ........................................................................ 3

1. INTRODUCCIÓN. LÓGICA DE PROGRAMACIÓN ...................................... 5
2. BASES DE DATOS .................................................................................. 7
2.1. TIPOS DE BASES DE DATOS ......................................................................... 9
3. DISEÑO DE BASES DE DATOS .............................................................. 11
4. FASES DEL DISEÑO DE BASE DE DATOS ............................................. 14
4.1. ESPECIFICACIÓN DE REQUISITOS .............................................................. 15
4.2. FASES. ESQUEMATIZACIÓN ....................................................................... 16
5. FASE 1. DISEÑO CONCEPTUAL ........................................................... 18
5.1. ESQUEMA CONCEPTUAL ............................................................................ 19
5.1.1. EL MODELO CONCEPTUAL ....................................................................... 19
5.1.2. MODELO ENTIDAD-RELACIÓN (E/R) DE PETER CHEN (1976) ..................... 21
5.1.2.1. Entidad (entity). Tipos ............................................................................ 22
5.1.2.2. Relación entre entidades........................................................................ 23
5.1.2.2.1. Obligatoriedad .............................................................................................. 26
5.1.2.3. Atributo (attribute) .................................................................................. 27
5.1.2.4. Relaciones modelo extendido ................................................................ 31
5.1.2.4.1. Nombre ......................................................................................................... 32
5.1.2.4.2. Cardinalidad .................................................................................................. 32
5.1.2.4.3. Tipo de Correspondencia ............................................................................. 32
5.1.2.5. Jerarquías de generalización/especialización...................................... 34
5.2. CONSTRUCCIÓN DEL MODELO CONCEPTUAL DE DATOS.
METODOLOGÍA ............................................................................................ 35
5.3. DIAGRAMAS DE FLUJO DE DATOS............................................................. 40
5.3.1. ELEMENTOS. NOTACIÓN ......................................................................... 42
5.3.2. REPRESENTACIÓN GRÁFICA DE LA NOTACIÓN ........................................... 45
5.3.3. DESCOMPOSICIÓN O EXPLOSIÓN EN NIVELES ............................................ 46
1
5.3.4. FLUJOGRAMAS ...................................................................................... 51

5.3.4.1. Tipos ........................................................................................................ 52
5.3.4.2. Elementos y su notación ........................................................................ 52
5.3.4.3. Reglas de construcción .......................................................................... 55
5.3.4.4. Ejemplos de Flujogramas ....................................................................... 56
6. PENSAR COMO UN PROGRAMADOR ................................................... 58
¿QUÉ HAS APRENDIDO? .......................................................................... 61
AUTOCOMPROBACIÓN ............................................................................ 63
SOLUCIONARIO ........................................................................................ 67
BIBLIOGRAFÍA .......................................................................................... 69
2
TU RETO EN ESTA UNIDAD
Si quisieras construir una casa…
¿Empezarías por el tejado? ¿Empezarías a construir directamente… o hablarías

con un arquitecto para que dibujase unos planos?
¿Podrías resolver un problema del mundo real, con la construcción de

un sistema de información (base de datos, programa, etcétera)?
Debes seguir un planteamiento:
 Observa y comprende el problema.
 Concreta los elementos importantes en el problema y no prestes aten-

ción al resto (abstracción). Será como un plano, diseño conceptual,
donde podemos ver las partes del sistema y cómo se relacionan. Para
realizarlo utilizamos un modelo conceptual. Con este diseño crea un
esquema conceptual.
 Ya puedes, basándote en ese esquema, crear un diseño lógico.
 Construye el sistema.
Cuando termines esta unidad didáctica quizás sigas sin saber construir una casa…
pero sabrás realizar un modelo conceptual de datos.
3
1. INTRODUCCIÓN. LÓGICA DE PROGRAMACIÓN

Lo fundamental es que conozcas bien las necesidades del usuario, para que
puedas diseñar correctamente la base de datos y crear el programa.
Debes entender bien lo que el usuario pide y necesita, y adelantarte añadiendo

las necesidades que podrá tener posteriormente.
Veamos cómo debe pensar un programador para poder realizar el diseño de

una Base de Datos.
Si tenemos un concesionario de Venta de coches, turismos de segunda mano,

qué datos hay que conocer y tener almacenados.
 Coches: matricula, marca, modelo, motor, nº de puertas, color, …

 Vendedores: código de vendedor, nombre y apellido, DNI, teléfono…
 Clientes: código de cliente, nombre y apellido, DNI, teléfono…
Estos datos los reflejamos en tablas, que tienen filas y columnas:
TABLA COCHES
Nombre Nº de
Matricula Marca Modelo Motor Color
Dato puertas
Fila 1 Z-1010-B Seat León Diesel 5 Verde
Fila 2 M-2189-X Ford Focus Gasolina 3 Rojo
Fila 3 M-8596-J Citroën Xara Diesel 5 Verde
Columna Columna Columna Columna Columna Columna Columna

1 2 3 4 5 6 7
5
A cada fila de información excepto la del nombre del dato, le corresponde un

único coche.
A cada columna de información se le asignará un valor que podrá estar o no

repetido, (color verde aparece 2 veces) excepto la columna Matricula que será
única (no puede haber 2 coches con la misma matricula). Por tanto, nuestra
columna matricula será nuestra clave principal de la tabla.
Analizando los datos vemos que:
 Dato matricula es alfanumérico, contiene números y letras.
 Dato nº de puertas es numérico, (y será  o = 3 y  o = a 5).
 Dato Color es Alfabético.
¿Cómo haríamos un diagrama de la secuencia de venta de un coche?
Este es un diagrama básico para entender la lógica de programar, pero debe

cumplir unas normas que iremos viendo a lo largo del tema.
6
2. BASES DE DATOS
Fuete: Pxfuel
Una base de datos, es un conjunto organizado de datos y/o información.
“Es un conjunto exhaustivo, no redundante de datos estructurados, organizados (in-

dependientemente de su utilización y su implementación), accesibles a tiempo real y
que pueden ser leídos al mismo tiempo por diferentes usuarios (usuarios concurren-
tes), y que, realizando procesos sobre ellos, obtenemos diferentes informaciones en
momentos no predecibles en el tiempo.”
Es el elemento más importante del sistema de información y, debe de estar su-

jeto a medidas de seguridad (definidas en los procedimientos) que garanticen
su integridad y eviten el acceso por personal no autorizado.
Deben cumplir unas determinadas normas, para que el uso de datos sea efi-
ciente y el resultado fiable.
7
Forma un conjunto de archivos electrónicos. Las bases de datos tradicionales se

organizan por campos, registros y archivos.
El diseño, desarrollo y gestión de bases de datos ha evolucionado mucho y, en

la actualidad, es una parte esencial de cualquier entorno informático, por lo que
es imprescindible tener conocimiento sobre ellas.
Ya has aprendido en unidades anteriores las estruc-

turas de datos: ficheros, árbol, array…
Procedimiento
Un procedimiento, subrutina o subprograma es un fragmento del

programa que realiza una tarea concreta y recibe un nombre por el que
puede ser llamado o activado desde otra parte del programa (Prieto, 2006).
Un procedimiento puede tener argumentos, que son una serie de variables de

comunicación, que permiten el paso de información entre el programa y el pro-
cedimiento.
Sistema gestor de bases de datos (SGBD)
Es un software que define y controla una estructura de datos, su almacena-

miento, método de acceso y manipulación, tanto para el gestor de la base de
datos como para los usuarios, manteniendo la integridad, confidencialidad y
seguridad de dichos datos.
(Un software, sabemos que es un conjunto coordinado de programas, procedimien-

tos, lenguajes, etcétera).
Su objetivo principal es simplificar y facilitar el acceso a datos, de forma rápida y

fiable.
8
2.1. TIPOS DE BASES DE DATOS

 Bases de datos relacionales.
El Modelo Relacional.
Como MySQL, SQL Server y Oracle. Como su nombre lo indica utilizan

el modelo relacional y siempre es mejor usarlas cuando los datos son
consistentes y ya tienes algo planificado.
 Bases de datos no relacionales, conocidas como NO-SQL.
Difieren del modelo clásico de SGBDR (Sistema de Gestión de Bases de

Datos Relacionales) en aspectos importantes, siendo el más destacado
que no usan SQL como lenguaje principal de consultas. Los datos al-
macenados no requieren estructuras fijas como tablas, normalmente
no soportan operaciones JOIN, ni garantizan completamente ACID
(atomicidad, consistencia, aislamiento y durabilidad) y habitualmente
escalan bien horizontalmente. Los sistemas NoSQL se denominan a ve-
ces "no solo SQL" para subrayar el hecho de que también pueden so-
portar lenguajes de consulta de tipo SQL.
La más conocidas son MongoDB y Redis, conocidas como NO-SQL (Not

Only SQL). Estas son más flexibles en cuanto a consistencia de datos y
se han convertido en una opción que intenta solucionar algunas limita-
ciones que tiene el modelo relacional.
 Bases de Datos transaccionales.
Su único fin es el envío y recepción de datos a grandes velocidades, es-

tas bases son muy poco comunes y están dirigidas por lo general al en-
torno de análisis de calidad, datos de producción e industrial.
Es importante entender que su fin único es recolectar y recuperar los

datos a la mayor velocidad posible, por lo tanto, la redundancia y dupli-
cación de información no es un problema como con las demás bases
de datos.
Generalmente, para poderlas aprovechar al máximo permiten algún ti-

po de conectividad a bases de datos relacionales.
Ejemplo: transacciones entre cuentas bancarias.
 Modelo orientado a objetos.
 El modelo de base de datos plana.
 El modelo de base de datos jerárquica.
9
 Modelo de Red.
 Modelo Multidimensional.
 Basadas en grafos.
Representa la información como nodos de un grafo y sus relaciones

con las aristas del mismo, de manera que se pueda usar teoría de gra-
fos para recorrer la base de datos ya que esta puede describir atribu-
tos de los nodos y las aristas.
 Base de Datos Geográfica (BDG).
Es un conjunto de datos geográficos organizados de tal manera que

permiten la realización de análisis y la gestión del territorio dentro de
aplicaciones de Sistemas de Información Geográfica (SIG). Además, una
BDG se utiliza de soporte para la implantación de servicios.
Vas a estudiar, en las siguientes unidades, el modelo relacional, no

relacional o NoSQL y el modelo orientado a objetos.
10
3. DISEÑO DE BASES DE DATOS
Fuente: Public domain vectors
El diseño de la base de datos, es la base de todo el funcionamiento de un pro-

grama, nos debe proporciona las mejores condiciones del tratamiento de datos
para que el programa que creemos sea eficaz y eficiente.
Todo debe estar totalmente especificado y concretado al máximo.
El diseño de bases de datos, lo realiza un analista y/o un programador.
11
Objetivos de un buen diseño
Debe definir la estructura de datos, tipo, si es o no un dato obligatorio etc.
Un buen diseño de base de datos es importante para:
 Obtener un resultado que satisfaga los requisitos del software (y por

lo tanto nuestras necesidades o las de nuestros clientes).
 Ser fácil de mantener.
 Evitar problemas, como pueden ser:
 Redundancia:
Repetición de información (información duplicada).
 Inconsistencia:
Existe información contradictoria o incongruente.
 Dificultad de acceso a los datos:
Si el formato de la información no es uniforme, habría que reali-

zar una conversión y combinación de los datos de distintas tablas
o archivos.
 Acceso concurrente no controlado:
No se tienen los mecanismos adecuados para la sincronización

de procesos que acceden simultáneamente a la base de datos.
 Problemas de seguridad:
Posibilidad de accesos por parte de personal no autorizado.
 Dificultad en el procesamiento de datos:
Puede ocurrir que, debido al formato, no pueda ser utilizado por

otras herramientas como, por ejemplo, herramientas de genera-
ción de informes.
 Integridad:
Es muy importante, debe evitar:
 Datos duplicados.
 Datos faltantes.
 Datos alterados.
 Datos incorrectos.
12
Integridad:
Si un dato está en varias tablas (o ficheros) y se modi-
fica en una de ellas, (modificamos el DNI en la tabla
de empleados,) este debe modificarse en todas las
tablas o ficheros donde aparezca).
Cualidades de un buen diseño
Según Thomas H. Grayson, un buen diseño de base de datos debe poseer las
siguientes cualidades:
 Reflejar la estructura del problema en el mundo real.
 Ser capaz de representar todos los datos esperados, incluso con el paso
del tiempo.
 Evitar el almacenamiento de información redundante.
 Proporcionar un acceso eficaz a los datos.
 Mantener la integridad de los datos a lo largo del tiempo.
 Ser claro, coherente y de fácil comprensión.
13
4. FASES DEL DISEÑO DE BASE DE DATOS

El objetivo de dividir el diseño en Fases, es conseguir un esquema físico que,
posteriormente, se plasmará en un SGBD dando lugar a nuestra base de datos.
Para diseñar una base de datos, partimos de la especificación de

requisitos del usuario (aquí se indican las necesidades que hay que cubrir).
Las fases del diseño que nos proporcionará una buena Base de Datos son:
 Estudio inicial: Especificación de requisitos.
 Fase 1: Diseño conceptual.
 Fase 2: Diseño Lógico.
 Fase 3: Diseño Físico.
En esta unidad vas a estudiar:

 La Especificación de requisitos.
 Fase 1: Diseño Conceptual.
14
Dependencia de cada fase con el SGBD
En la siguiente tabla puedes observar la dependencia de cada una de las fases de

diseño con el tipo de sistema gestor de base de datos y con un SGBD específico.
Fase Tipo de SGBD SGBD específico
Diseño conceptual No No
Diseño lógico Sí No
Diseño físico Sí Sí
4.1. ESPECIFICACIÓN DE REQUISITOS
Es un paso fundamental, nuestro cliente, nos solicita un programa que debe

cubrir las necesidades concretas de los usuarios que lo utilizarán, y el programa
que creemos debe satisfacer totalmente.
Para ello es imprescindible:
 Entender perfectamente lo que el usuario nos pide.
 A partir de los que nos pide, concluir otras necesidades que también
necesita, aunque no sea consciente de ellas. (Entender lo que el usua-
rio no puede pedir.
 Añadir cosas que el usuario no ha pedido o aún no necesita, pero que

sabemos que necesitará más adelante.
Es muy importante que el cliente y los usuarios participen durante todo el pro-
ceso para asegurar que al final se consiga lo que necesitan.
Los requisitos definen qué debe hacer un sistema (el

problema), mientras que el diseño define cómo ha-
cerlo (la solución).
15
4.2. FASES. ESQUEMATIZACIÓN
Los pasos básicos son los siguientes:
Metodología de diseño de bases de datos
Fase 1: Diseño Conceptual
Ya has visto, que consiste en, a partir de la especificación de requisitos, crear un

Esquema Conceptual, que utilizaras para la siguiente fase 2: Diseño Lógico.
Etapa del diseño conceptual. Entradas y salidas
16
Fase 2: Diseño Lógico
Con el esquema conceptual creado en la Fase 1, se realiza La fase 2.
La Fase 2: Diseño Lógico, la estudiaras en la siguiente unidad.
Etapa del diseño lógico. Entradas y salidas
Fase 3: Diseño Físico
Por último, con el esquema lógico creado en la Fase 2, se realiza la última fase.
Fase 3: Diseño Físico, la estudiaras en la siguiente unidad.
Etapa del diseño físico. Entradas y salidas
17
5. FASE 1. DISEÑO CONCEPTUAL

El diseño conceptual, es saber, a partir de las especificaciones de requisitos de
usuario, crear el esquema conceptual de la base de datos, (utilizando unas de-
terminadas herramientas).
Para ello se utiliza un modelo conceptual Entidad/Relación.
El objetivo del diseño conceptual, es realizar posteriormente un esquema físico

que se plasmara en un Sistema Gestor de Base de Datos (SGBD) dando lugar
a la base de datos que necesaria en la creación del programa.
El diseño conceptual describe las estructuras de da-

tos y las restricciones de integridad.
Representa los elementos que intervienen en un
problema y sus relaciones.
El más utilizado es el modelo entidad-relación, intro-
ducido por Peter Chen en 1976.
18
5.1. ESQUEMA CONCEPTUAL
“Descripción de alto nivel de la información (datos) que se va a almacenar

y la estructura de la base de datos.”
Es independiente del SGBD que se vaya a utilizar y de todos los detalles de im-
plementación de la base de datos.
El objetivo es conseguir un esquema físico que, posteriormente, se plasmará en

un SGBD dando lugar a nuestra base de datos.
En la metodología del diseño conceptual se construye un esquema conceptual

local para cada vista de usuario.
Vamos a asegurarnos de que no haya confusión entre

modelo conceptual y esquema conceptual.
 El modelo conceptual es el lenguaje que usa-
mos para representar el esquema conceptual.
 El esquema conceptual describe la estructura
de los datos que vamos a almacenar.
“Sin embargo, es muy común utilizar el término “modelo
conceptual” para referirse al esquema conceptual”.
5.1.1. EL MODELO CONCEPTUAL
“El modelo conceptual es el lenguaje que utilizamos para representar el esquema

conceptual. No se representa la estructura física de la información (cómo serán los
tipos de datos a manejar).”
Nos ofrece unas herramientas, para describir una realidad mediante una repre-
sentación gráfica, obteniendo un esquema conceptual.
19
Modelo conceptual: herramientas  esquema conceptual.
Estas herramientas del modelo conceptual, de una forma gráfica, nos tienen
que permitir y servir una serie de conceptos:
 Permitirnos las propiedades:
 Expresividad.
 Simplicidad.
 Minimalidad.
 Formalidad.
 No tiene en cuenta el lenguaje de programación que utilizaremos.
 Servirnos para:
 Describir datos. (pero no su estructura física).
 Describir relaciones entre datos.
 Semántica.
 Restricciones de consistencia.
El modelo conceptual es un conjunto de herramien-

tas graficas (conceptuales) para describir datos, sus
relaciones, su significado y sus restricciones de con-
sistencia, en forma de esquemas conceptuales
(forma visual).
Existen diferentes tipos de modelos conceptuales, a estudiar, el más

utilizado, introducido por Peter Chen en 1976.
20
5.1.2. MODELO ENTIDAD-RELACIÓN (E/R) DE PETER CHEN (1976)
“Es la forma de realizar un modelo conceptual, cumpliendo una

metodología concreta con unas determinadas reglas y símbolos.”
El objetivo es, de una forma gráfica, representar la descripción de datos, relacio-

nes entre datos, semántica de los datos y restricciones de consistencia, creando
una visión real y natural (mediante entidades e interrelaciones).
El modelo original utilizaba 3 conceptos:
 Entidad.
 Relación entre entidades.
 Atributo.
Posteriormente se añadió:
 Cardinalidad.
Se añadió como concepto importante, para determinar los tipos de re-

lación entre entidades.
Más adelante, también se han ido añadiendo nuevos conceptos para mejorar su
capacidad expresiva, convirtiéndolo en modelo Relación/Entidad extendido me-
diante:
 Dominios de atributos.
 Identificadores.
 Atributos compuestos.
 Jerarquías de generalización/especialización.
21
5.1.2.1. Entidad (entity). Tipos
Representa “algo” del mundo real con existencia independiente y única, por
lo que sólo puede aparecer una vez el en esquema conceptual (aparece
como una entidad, con un nombre).
Es un tipo de objeto sobre el que se recoge información. Puede ser una perso-
na, una cosa, un concepto o un suceso.
Un nombre de entidad sólo puede aparecer una vez en el esquema

conceptual.
Una entidad puede tener atributos.
Tipos de Entidades
Hay dos tipos de entidades:
 Entidades fuertes.
Objeto con existencia física (persona, animal, coche, árbol de la natura-

leza…) Sus ocurrencias no dependen, para existir, de la presencia de
ocurrencias en ninguna otra entidad.
Se representa gráficamente con un cuadrado con el nombre de la enti-

dad en el interior. (el color de relleno no es necesario).
22
 Entidades débiles.
Tiene una existencia conceptual, no física (un oficio o puesto de trabajo,

carpinteo, secretaria…).
Son aquellas cuyas ocurrencias solo pueden aparecer cuando existen

ocurrencias en la entidad fuerte de la que dependen. (Un puesto de
trabajo existe si existe una persona que lo ocupe).
Se representa con un cuadrado contenido dentro de otro.
Si tenemos un concesionario de venta de coches,

“coche” podría ser una entidad.
Podríamos tener dos coches:
 Un Ford Mondeo, con cinco puertas, color gris
y motor de gasolina.
 Un Renault Clío con tres puertas, color blanco y
motor diésel.
Cada coche sería una instancia u ocurrencia de la en-
tidad coche.
Por lo tanto, la entidad coche es una generalización y
las ocurrencias son casos específicos (modelos de
coche).
5.1.2.2. Relación entre entidades
Describe cierta dependencia entre entidades o permite la asociación de las

mismas.
La relación, nos permite definir una dependencia entre varias entidades o la

asociación de las mismas.
23
Es decir, nos permite exigir que varias entidades compartan ciertos atributos de
forma indispensable, o que no lo hagan.
Relación, es una correspondencia o asociación entre dos o más entidades.
Los empleados de una empresa de venta de coches,

(de la entidad "Empleados") tienen un cargo (según la
entidad "Cargo del empleado").
Las relaciones se representan gráficamente mediante rombos con el nombre en

el interior.
Un ejemplo de relación entre las entidades “cliente” y “coche” podría ser

“ha_comprado”.
Métrica 3
Se concibe como una Metodología de Planificación, Desarrollo y Mantenimiento

de Sistemas de Información. Puede ser utilizada libremente con la única restric-
ción de citar la fuente de su propiedad intelectual: el Ministerio de Adminis-
traciones Públicas.
24
La metodología MÉTRICA Versión 3 ofrece a las Or-

ganizaciones un instrumento útil para la sistematiza-
ción de las actividades que dan soporte al ciclo de vi-
da del software.
Fuente original:
http://administracionelectronica.gob.es
Este Ministerio, ofrece a las Organizaciones, desde el Consejo Superior de In-

formática, un método para la sistematización de las actividades que dan soporte
al ciclo de vida del software en el desarrollo de Sistemas de Información, y un
marco de gestión para asegurar que los proyectos cumplen sus objetivos en
términos de calidad, coste y plazos.
A la relación entre conjuntos de entidades se le denomina Participación.
Conjuntos de entidades "cliente" y "coche" participan

en el conjunto de relaciones cliente-coche.
Clasificaciones
Una relación también puede clasificarse de 2 formas:
 Por el grado de participación:
Al conjunto de entidades que participan en un tipo de relación se de-

nomina “grado de participación”.
Puede ser:
 Binaria: es el más frecuente, grado 2.
 Ternaria: grado 3.
 Reflexiva o recursiva: grado 1.
25
 Por las restricciones de participación:
Restricciones de participación, son reglas que han de cumplir las rela-

ciones.
Dependiendo de estas restricciones, una relación se puede clasificar en

dos tipos:
 Total.
Cuando las entidades participan al menos una vez.
Ejemplo:
Si el concesionario otorga a todos sus vendedores un seguro mé-

dico gratuito a escoger entre tres compañías distintas, la relación
“afiliado_a” que relaciona las entidades “vendedores” y “compa-
ñías_de_seguro” sería (N:1) total.
 Parcial.
Cuando al menos una entidad no participa siempre.
Ejemplo:
En el ejemplo de la relación “ha_comprado”, un cliente puede ha-

ber comprado uno o más coches, mientras que un coche ha sido
comprado por un cliente o por ninguno, por lo que no hay una
correspondencia siempre.
5.1.2.2.1. Obligatoriedad
 0: no obligatoriedad.
A cada elemento de la entidad puede corresponderle uno o ningún

elemento de la otra entidad.
Una relación es opcional cuando, para toda ocurrencia de un tipo de

entidad, puede existir o no, una o varias ocurrencias del tipo de entidad
asociada.
 1: obligatoriedad.
A cada elemento de la entidad le corresponde otro de la otra entidad.
Una relación es obligatoria, cuando, para toda ocurrencia de un tipo de

entidad, existe al menos una ocurrencia del tipo de entidad asociada.
26
 N.
Indica que a cada elemento de la entidad le puede corresponder nin-

guno, uno, o más de 1 de la otra entidad.
El mínimo y máximo se representan separados por una “coma” y entre

paréntesis (n,n).
La Cardinalidad es el número de entidades con la cual otra entidad se

puede asociar mediante una relación binaria.
En el ejemplo de los coches, un cliente puede haber

comprado uno o más coches, mientras que un coche
solamente puede haber sido comprado por un único
cliente (o por ninguno si aún está en venta).
5.1.2.3. Atributo (attribute)
Atributo es una característica o propiedad de un tipo de entidad.
Los atributos son la unidad básica de información que sirve para definir las ca-
racterísticas de la entidad; “para identificar la entidad”.
(Puede ser un número elevado, el diseñador decidirá cuales indicar, los más
significativos).
Cada entidad debe contener un número mínimo de distintos atributos, que la

identifiquen inequívocamente.
Los atributos pueden ser de distintos tipos (numéricos, texto, etcétera).
Tanto las relaciones como las entidades pueden tener atributos.
27
Se representan como círculos conectados a la entidad por una línea.
Cada entidad se diferencia de las demás por el valor de sus atributos.
Dos o más entidades, nunca tendrán el mismo valor en todos sus atributos
(podrán coincidir en uno o varios, pero nunca en todos).
Restricciones sobre atributos
Si defines restricciones sobre los atributos, estos pueden ser:
 Univaluado: atributo, que sólo puede tomar un valor, para todas y ca-
da una de las ocurrencias del tipo de entidad al que pertenece.
 Obligatorio: atributo, que tiene que tomar como mínimo, un valor para
todas y cada una de las ocurrencias del tipo de entidad al que pertenece.
Los atributos identificativos permiten diferenciar a una instancia de la entidad

de otra distinta. (Por ejemplo, en una entidad vendedor, el atributo identificativo
sería el código de vendedor).
En el ejemplo de los coches, los atributos de la enti-

dad “coche” serían:
 Modelo. Ejemplo: Ford Mondeo (tipo texto).
 NPuertas. Ejemplo: 5 (tipo numérico entero).
 Color. Ejemplo: gris (tipo texto).
 Motor. Ejemplo: gasolina (tipo texto).
28
Atributo Identificador de una Entidad (Identificadores)
El identificador de una entidad es un atributo o conjunto de atributos que

identifica unívocamente a cada ocurrencia de esa entidad.
El identificador de una entidad debe cumplir dos condiciones:
 No pueden existir dos ocurrencias de la entidad con el mismo valor del

identificador.
 No se puede omitir ningún atributo identificador (no pueden contener

un valor nulo).
Toda entidad tiene al menos un identificador y puede tener varios

identificadores alternativos.
La Clave se utiliza para relacionar registros de diferentes tablas. Hay varios

tipos:
 Clave principal (o primaria):
Identifica inequívocamente el registro de una tabla (DNI).
 Clave candidata o secundaria:
También identifica inequívocamente el registro de una tabla, pero el

programador no la ha definido como clave principal. (nº de teléfono).
 Superclave:
Combinación de campos clave, por tanto, identificará inequívocamente

el registro de una tabla.
 Clave externa:
Es un campo en una tabla que contiene la clave principal de otra tabla.

Su objetivo es asegurar la integridad referencial de los datos. Es decir,
ese campo sólo podrá ser un dato que existirá como clave primaria en
la otra tabla. Ejemplo: en una tabla de un pedido, el campo código-
articulo deberá ser la clave principal de la tabla artículos.
29
El programado puede crear un campo clave principal, cuyo valor, será creado
automáticamente cada vez que se añada una fila a nuestra tabla de datos. (sue-
le ser autonumérica, por ejemplo, código de vendedor o código de cliente).
Atributos Compuestos
Son aquellos que se pueden dividir en subpartes más pequeñas, que represen-
tan atributos más básicos con significado propio.
Ejemplo:
Ejemplo de atributo compuesto
Para cada atributo, definiremos el tipo de valor que puede tomar, restringiendo
así el tipo de dato que almacenaremos. (sólo cadenas de caracteres, sólo núme-
ros, solo números mayores que cero… en el caso de atributo de nº de teléfono
de una entidad persona, exigiremos que sean 9 números).
Atributos Atómicos
Los atributos que no son compuestos, no pueden dividirse, se denominan

atómicos o de valor simple.
Son los que tienen un solo valor para una entidad particular. No pueden dividir-
se (no son compuestos).
30
Dominio de Atributos (values set)
Dominio de un atributo es el conjunto de todos los posibles valores que puede

tomar el atributo (el tipo de datos).
Por ejemplo, un tipo de dato “entero” podrá tomar todos los valores enteros (1,
2, 3, etcétera) pero no otro tipo de valores como decimales, letras, fechas… Un
tipo de dato lógico, solo podrá tomar el valor verdadero o falso.
También definiremos si es obligatorio o no que exista un valor para ese atributo.
Cuando un atributo no tiene un valor determinado, recibe el valor nulo.
En el ejemplo de los coches, los atributos de la entidad “coche” serían:
 Modelo. Ejemplo: Ford Mondeo (tipo texto).

 NPuertas. Ejemplo: 5 (tipo numérico entero).
 Color. Ejemplo: gris (tipo texto).
 Motor. Ejemplo: gasolina (tipo texto).
El atributo “kilómetros” puede tomar un valor ente-

ro positivo. Si establecemos que no se venderán co-
ches con más de 500.000 km, el dominio sería
[0,500000] (el conjunto de los números enteros
comprendidos entre 0 y 5.000.000).
El atributo “motor” puede tomar varios valores es-
pecíficos. Su dominio de atributos sería la lista: {“ga-
solina”, “diésel”, “eléctrico”, “híbrido”}.
5.1.2.4. Relaciones modelo extendido
En el modelo Entidad/Relación extendido, Según Métrica v3, se definen las

relaciones por:
 Nombre.
 Cardinalidad.
 Tipo de correspondencia.
31
5.1.2.4.1. Nombre
El nombre de la relación la distingue unívocamente del resto de relaciones del

modelo.
5.1.2.4.2. Cardinalidad
Es el número máximo y mínimo de ocurrencias de un tipo de entidad que pue-

den estar interrelacionadas con una ocurrencia de otro tipo de entidad.
Se puede definir la cardinalidad de muchas formas, para que entiendas bien el

concepto, que es lo importante, te indicamos varias de sus características:
 Representa la participación en la relación de cada una de las entidades

afectadas.
 La cardinalidad nos indica, en una relación entre dos o más entidades,

para una “entidadX”, el número de entidades con la que se relaciona di-
cha “entidadX” (número de ocurrencias).
 La cardinalidad, mide la obligatoriedad de la ocurrencia y el número

de veces mínimos y máximos que una misma ocurrencia de esa enti-
dad puede aparecer en una ocurrencia de la relación.
 El tipo de correspondencia coincide con la cardinalidad máxima.
5.1.2.4.3. Tipo de Correspondencia
También se le denomina, por algunos autores, Correspondencia de Cardinalida-

des.
Grado de cardinalidad: número de veces que se produce una ocurrencia

(relación entre entidades).
En una ocurrencia de una relación que estamos tratando, es el número máximo

de ocurrencias de cada tipo de entidad que pueden intervenir. (Veremos 3 cla-
ses de relaciones: 1:1, 1:N, N:M).
32
Dado un conjunto de relaciones en el que participan dos o más conjuntos de

entidades, la cardinalidad de la correspondencia indica el número de entidades
con las que puede estar relacionada una entidad dada.
Los tipos de correspondencia que podemos encontrarnos son:
 Relaciones Uno a Uno (1:1).
Una ocurrencia de la entidad-origen puede relacionarse con una sola

ocurrencia de la entidad-destino y viceversa.
Ejemplo:
Un coche solo puede estar aparcado en una plaza y una plaza solo
puede contener un coche.
 Relaciones 1:N.
Cada ocurrencia de una entidad puede estar relacionada con cero, una
o varias ocurrencias de la otra entidad:
 Uno a Varios (1:N).

Una ocurrencia de la entidad-origen puede relacionarse con más
de una ocurrencia de la entidad-destino.
Sin embargo, una ocurrencia de la entidad-destino solo puede re-
lacionarse con una ocurrencia de la entidad-origen.
Ejemplo:
Un coche puede haber sido vendido por un vendedor (o no ha-
berse vendido), mientras que un vendedor podría haber vendido
0, 1 o varios coches.
 Varios a Uno (N:1).
Exactamente igual que la anterior, pero la entidad que puede tomar

más de un valor es la entidad-origen en lugar de la entidad- destino.
Ejemplo:
Un garaje tiene una o más plazas de coches; sin embargo, una
plaza de coche solamente puede pertenecer a un único garaje.
Una entidad origen “entidad-coche” sólo puede ocupar una plaza
de garaje. Pero una entidad destino “entidad-garaje”, puede con-
tener 0 coches o más de 1 coche. Y una “entidad-coche” sólo
puede haber sido vendida pon una “entidad-vendedor”.
33
 Relaciones Varios a Varios (N:M).
Una ocurrencia de la entidad-origen puede relacionarse con cero, una o

varias de una ocurrencia de la entidad-destino.
Igualmente, una ocurrencia de la entidad-destino puede relacionarse

con cero, una o varias de una ocurrencia de la entidad-origen.
Ejemplo:
Si definimos la relación “probarCoche”, un coche puede haber sido pro-

bado por más de un cliente, y un cliente puede probar más de un coche.
5.1.2.5. Jerarquías de generalización/especialización
Una entidad A es una generalización de un grupo de entidades (A1, A2, …, An) si

cada ocurrencia de cada una de esas entidades es también una ocurrencia de A.
Las entidades A1, A2, …, An serán, a su vez, especializaciones de la entidad A.
Todas las propiedades de la entidad genérica A son heredadas por las sub-
entidades.
La entidad “empleados” sería una generalización de

las entidades “vendedores” y “mecánicos”.
La entidad “mecánicos” sería una especialización de
la entidad “empleados”.
Cada jerarquía es, por un lado, total o parcial, y por el otro, exclusiva o super-
puesta.
 Jerarquía total.
Cada ocurrencia de la entidad genérica corresponde al menos con una

ocurrencia de alguna subentidad.
 Jerarquía parcial.
Alguna ocurrencia de la entidad genérica no corresponde con ninguna

ocurrencia de las subentidades.
34
 Jerarquía exclusiva.
Cada ocurrencia de la entidad genérica corresponde, como mucho, con

una ocurrencia de una de las subentidades.
 Jerarquía superpuesta.
Alguna ocurrencia de la entidad genérica corresponde a ocurrencias de

dos o más subentidades diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad

como subentidad. Un subconjunto siempre es una jerarquía parcial y exclusiva.
5.2. CONSTRUCCIÓN DEL MODELO CONCEPTUAL

DE DATOS. METODOLOGÍA
La metodología nos indica unos pasos a seguir.
Sirve de guía, pero no es rígida, es adaptable a nuestras.
Hay muchas variantes dependiendo del autor. La iremos adaptando, pudiendo

repetir alguno de los pasos (o parte de ellos) de forma iterativa cuando sea ne-
cesario.
Los pasos propuestos son:
1. Recopilar información.
2. Identificar entidades.
3. Identificar las relaciones entre entidades.
4. Identificar atributos.
5. Determinar los dominios de los atributos.
6. Determinar los atributos clave candidata, principal y alternativa.
7. Identificar generalizaciones/especializaciones.
8. Identificar las entidades débiles.
9. Comprobar si hay redundancia.
35
10. Validar el modelo conceptual para ver si cumple los requisitos.
11. Repasar el modelo conceptual con los usuarios.
12. Generar documentación.
1. Recopilar información
Recopilar información: Especificación de Requisitos.
Es el primer paso, recoger la información relevante del universo que se quiere

representar.
Debemos conocer toda la información necesaria para lograr los objetivos de la

programación a realizar. El usuario debe indicarnos todos los datos que utiliza,
así como cuáles son sus necesidades. Añadiendo también las que nosotros pre-
veamos que necesitará.
2. Identificar entidades
Identificamos los objetos que tengan existencia propia.
Definimos los objetos principales en los que los usuarios están interesados, les
asignamos un nombre.
3. Identificar las relaciones entre entidades
Asignar nombre a las relaciones.
Les asignamos un nombre a las relaciones de las entidades definidas en el

punto anterior: verbos o expresiones verbales.
36
4. Identificar atributos
Identificar características posibles.
Buscamos las características de cada entidad, y les asignamos un nombre

(nombre del atributo).
5. Determinar los dominios de los atributos
Decidir valores y su rango.
Definimos todos los posibles valores (y rango de valores) que puede tomar el
atributo (el tipo de datos).
6. Determinar los atributos clave candidata, principal y alternativa
Escogemos la clave principal y si lo consideramos necesario también las

alternativas.
Determinamos que atributos o conjuntos de atributos son claves candidatas

(pueden identificar unívocamente una ocurrencia de la entidad).
7. Identificar generalizaciones/especializaciones
Ya hemos visto los conceptos de generalización y especialización, pero

vamos a recordarlo.
La especialización es el proceso para clasificar una clase de objetos en subcla-

ses más especializadas.
37
La generalización es el proceso inverso. Se generalizan varias clases para obtener

una abstracta de más alto nivel que incluya los objetos de todas estas clases.
Los atributos identificadores y los descriptores comunes a todas las entidades

estarán en la entidad general y el resto en las entidades especializadas.
8. Identificar las entidades débiles
Especificar las relaciones entre las entidades.
Determinamos si las entidades son entidades fuertes (concretas) o débiles (abs-

tracta).
Una entidad débil sufre dependencia de identificación.
Para identificarse necesita la ocurrencia de otras entidades con las que está
relacionada. Debemos especificar la relación o relaciones que identifican a cada
entidad débil.
9. Comprobar si hay redundancia
No debe haber redundancia.
Tras construir el modelo entidad/relación, debe ser analizado para comprobar si

se presentan redundancias.
Los atributos redundantes, que se derivan de otros elementos mediante algún

calculo, deben ser eliminados o marcarse como redundantes.
Hay que estudiar detenidamente las cardinalidades mínimas de las entidades, y

la semántica de las relaciones. Las relaciones redundantes deben eliminarse del
modelo, asegurándose que eliminándolas sigue siendo posible el paso, tanto en
un sentido como en el inverso, entre las dos entidades que unían.
38
Debemos eliminar las relaciones o entidades redundantes. Las entidades re-

dundantes se funden en una sola. La clave principal de una de ellas pasa a ser
clave principal de la nueva entidad y la clave principal de la otra pasa a ser clave
alternativa de la nueva entidad.
En un hotel, las entidades “huésped” y “cliente” serían

redundantes.
10. Validar el modelo conceptual para ver si cumple los requisitos
Repasar el trabajo realizado.
Antes de repasar el modelo con el usuario, es importante repasarlo, para garan-

tizar que se cumplen los requisitos.
11. Repasar el modelo conceptual con los usuarios
Mostrar el trabajo realizado a los usuarios, nuestro objetivo es que lo

entiendan.
Los usuarios deben estar implicados en este proceso y deben entender y validar
que lo representado en el modelo conceptual es lo que ellos necesitan.
Si no entienden el modelo, generalmente, habrá que revisarlo hasta que se

cumpla este requisito.
39
12. Generar documentación
Imprescindible tener el trabajo bien documentado.
La documentación servirá de soporte para posteriores etapas de diseño. Toda

la información recopilada queda definida en el diccionario de datos.
El diccionario de datos puede incluir:
 El modelo gráfico utilizado (por ejemplo, el modelo E/R).
 El esquema de base de datos.
 Catálogo de requisitos.
 Especificación del problema.
 Descripción de cada elemento del modelo (entidades, relaciones y atri-

butos).
 Dominio de los atributos.
 Cualquier documentación adicional que el diseñador considere opor-

tuna.
 Diagramas de flujo de datos. Reglas de construcción.
5.3. DIAGRAMAS DE FLUJO DE DATOS
Un diagrama de flujo de datos (DFD) es una representación gráfica que muestra

de forma clara y lógica los procesos del sistema de información.
Para ello se realiza una descomposición sucesiva de los diferentes procesos,

desde el nivel más general hasta el nivel de detalle suficiente, mostrando la rela-
ción entre ellos.
El DFD establece las funciones que hay que desarrollar sin indicar cómo hacerlo.
Es independiente de las restricciones físicas del entorno.
40
Objetivo
El objetivo principal es simplificar el entendimiento y mantenimiento del sistema.
Proporcionar una representación del sistema a nivel lógico y conceptual que

facilite su comprensión al equipo de desarrollo y a los usuarios.
Permite representar gráficamente:
 El flujo o movimiento de los datos a través del sistema.

 La lógica de los procesos.
 Las trasformaciones de los datos al pasar por un proceso.
 Los límites del sistema.
El DFD, establece las funciones que hay que desarrollar,

sin indicar cómo hacerlo.
Características
Un diagrama de Flujo de Datos, debe cumplir unas determinadas características,

para que sea útil y de fácil comprensión.
La información debe ser:
 Sintética.
Debe ser resumido, de forma que un proceso debe verse en una sola
hoja.
 Simbolizada.
Hay que utilizar unos símbolos concretos para cada elemento, de esta
forma, visualmente, el símbolo utilizado ya nos proporciona rápidamen-
te información.
 Gráfica.
De una forma visual, podemos ver rápidamente todos los procesos,
mostrando unos rasgos principales, sin necesidad de leer notas. A su
vez, con mayor atención podemos ver detalles.
41
Como analista, debes asegurar:
 Que ha desarrollado todas las partes del procedimiento.
 Que sirve para escribir un informe lógico con claridad.
 Que garantiza que, al mostrarlo al usuario, entienda los requisitos que

solicito y cumple sus objetivos.
5.3.1. ELEMENTOS. NOTACIÓN
Ya hemos indicado que debemos descomponer los procesos desde un nivel

general, hasta el máximo nivel de detalle necesario para reflejar toda la semán-
tica del sistema.
Las conexiones permitidas entre los elementos de un DFD son:
 ENTIDAD – PROCESO.
 PROCESO – PROCESO.
 PROCESO – ALMACÉN.
Notación
El diagrama de flujo de datos se compone de los siguientes elementos:
 Almacén de datos:
 Representa una colección de datos en reposo, almacenada, y que

es controlada por el sistema de gestión de datos.
 Deben estar todos los datos que se necesitará en la ejecución de

procesos.
 No puede crear, transformar ni destruir datos.
 No está comunicado con otro almacén o entidad externa.
 Aparecerá por primera vez en el nivel en que dos o más procesos

accedan a él.
42
 Entidad externa:
 Representa un ente ajeno al sistema (personas, organizaciones u

otros sistemas) que proporciona o recibe información de este.
 Las relaciones entre entidades externas no se estudian en el mo-
delo.
 Normalmente solo aparece en el diagrama de contexto, aunque
puede aparecer en niveles inferiores si ayuda a la comprensión
del diagrama.
 Puede repetirse en un mismo nivel diagrama para no entrecruzar
líneas.
 Nos proporciona información de la relación del sistema con el
mundo exterior.
 Proceso:
 Muestra una funcionalidad que debe realizar el sistema para
transformar o manipular datos los datos de entrada, generando
datos de salida.
 El proceso no puede ser el origen ni el final de los datos.
 Una entidad externa y un almacén de datos solamente se pueden
relacionar a través de un proceso (no directamente).
 Un proceso puede transformar un flujo de datos en varios.
 Los procesos siempre están en continua ejecución. No se inician
ni se detienen.
Un proceso, representa una función que tiene que realizar el sis-
tema para transformar o manipular datos, debe generar los flujos
de datos de salida a partir de los de entrada, más una informa-
ción constante o variable al proceso.
El proceso nunca es el origen ni el final de los datos, puede trans-
formar un flujo de datos de entrada en varios de salida, y es ne-
cesario siempre, como intermediario entre entidad externa y al-
macén de datos.
Todo proceso, independientemente del nivel del diagrama, debe
tener al menos una entrada y una salida.
 Flujo de datos:
 Representa el movimiento de los datos.
 Muestra la comunicación entre los procesos y los almacenes o
entidades externas.
43
 Para darse un flujo de datos entre dos procesos, estos deben es-
tar sincronizados.
El flujo de datos entre dos procesos, sólo es posible si la informa-

ción es síncrona, es decir, el proceso destino comienza cuando fi-
naliza su función el proceso origen.
 Los flujos de datos entre procesos y almacenes pueden ser de

tres tipos:
 De consulta.
El flujo es desde el almacén a la entidad externa, se utilizan

los datos o se comprueba que cumplen unos determinados
criterios.
 De actualización.
Flujo desde la entidad externa hasta el almacén, dónde los

datos se alteran, creando, modificando o eliminando los ya
existentes.
 De diálogo.
Debe haber flujo en ambas direcciones, entre proceso-

almacén y almacén-proceso (consulta y actualización).
 Proceso de control: (En sistemas orientados al control de datos).
Representa procesos que coordinan y sincronizan las actividades de

otros procesos del diagrama de flujo de datos.
 Flujo de control: (En sistemas orientados al control de datos).
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).
44
Muchas veces, se relaciona el almacén con ficheros o

bases de datos, pero, un almacén puede ser cual-
quier soporte de información (documentos en papel,
fichas, etcétera).
5.3.2. REPRESENTACIÓN GRÁFICA DE LA NOTACIÓN
Hay varios tipos de notación y cada uno muestra sus variantes según el autor.
Sin embargo, hay dos tipos de notación que son los más utilizados:
 Yourdon & Coad.

 Gane & Sarson.
Definen los mismos objetos, pero con distintas representaciones visuales.
Elemento Yourdon & Coad Gane & Sarson
Entidad
Proceso
Almacén de datos
Flujo de datos
45
Yourdon & Coad es el más utilizado para análisis y di-

seño de sistemas. (También es parecida, la notación
de Yourdon & DeMarco).
Sin embargo, Gane & Sarson posiblemente sea el más
utilizado para representar sistemas de información.
5.3.3. DESCOMPOSICIÓN O EXPLOSIÓN EN NIVELES
Técnica top-down.
Los diagramas de flujo de datos han de representar el sistema de la forma más

clara posible.
Para ello, su construcción se basa en el principio de descomposición o explo-

sión en distintos niveles de detalle, que se realiza de arriba abajo (top-down), es
decir, se empieza en el nivel más general y se termina con el máximo nivel de
detalle, pasando por sucesivos niveles intermedios.
La descomposición de cada proceso de un DFD origina otro DFD. Las

entradas y salidas (E/S) de un proceso deben ser iguales a las del DFD en
que se descompone.
La explosión de cada proceso de un DFD origina otro DFD.
Es imprescindible comprobar que se mantiene la consistencia de información

entre ellos: la información de E/S de un proceso cualquiera, se corresponde con
la información de E/S del DFD en el que se descompone.
En cualquiera de las explosiones puede aparecer un proceso que no

necesite descomposición, se le denomina Proceso primitivo.
46
En un Proceso Primitivo, sólo se detalla su entrada y su salida, y una descripción

de lo que realiza.
En la construcción, debemos evitar si es posible, la descomposición desigual, es

decir, que un nivel necesite ser particionado en uno o varios niveles más y otro
nivel contenga un proceso primitivo.
Composición
El modelo de procesos deberá́ contener:
 Diagrama de contexto (nivel 0).
El diagrama de contexto tiene como objetivo delimitar el ámbito del sis-

tema con el mundo exterior definiendo sus interfaces.
 Diagrama 0 (nivel 1).
 N diagramas de nivel 2, donde N es el número de procesos del nivel1.
En función a la complejidad del proceso habrá:
 Los DFD de niveles intermedio que sean necesarios.
 Varios procesos primitivos (DFD en el último nivel de detalle).
Construcción
Aunque el número de niveles depende del sistema y de su tamaño, seguiremos

normalmente los siguientes pasos:
 1º
Se crea el diagrama de contexto, conocido como DFD de Nivel "0".
Diagrama de contexto tiene como objetivo delimitar el ámbito del sis-

tema con el mundo exterior definiendo sus interfaces. Es el de más alto
nivel.
Es de gran utilidad para los niveles posteriores de análisis como herra-
mienta de balanceo.
47
Contendrá:
 Un único proceso que corresponde con el sistema en estudio.
 Un conjunto de entidades externas que representan la proce-
dencia y destino de la información.
 Un conjunto de flujos de datos que representan los caminos por
los que fluye dicha información.
 2º
Se descompone el proceso en otro Diagrama: Nivel 1, subsistemas.
Cada subsistema:
 Contendrá los procesos principales o subsistemas.
 Un subsistema es un conjunto de procesos que colaboran para
ofrecer una funcionalidad.
 3º
Se crean N diagramas de Nivel 2: funciones de cada subsistema.
Donde N es el número de procesos del nivel1.

 4º
Se crean DFD intermedios: subfunciones asociadas.
Se siguen descomponiendo los procesos hasta llegar a nivel suficiente

de detalle.
 5º
Procesos primitivos.
DFD en el último nivel de detalle, aquel que no se puede descomponer.

Se detallará su entrada, su salida y una descripción de lo que realiza.
También se denomina función elemental o proceso elemental.
48
El número de niveles depende del sistema y de su

tamaño, por lo que no hay que esforzarse demasiado
en conseguir esta estructura.
A continuación, se muestra un ejemplo gráfico que representa la de descompo-

sición jerárquica de los diagramas de flujo de datos.
Descomposición jerárquica de los DFD
49
Ejemplo
Vamos a ver un ejemplo, para que veas de forma gráfica la técnica top-down, y
comprendas mejor lo estudiado.
Ejemplo de un servicio técnico de informática, teniendo en cuenta sólo averías

de hardware:
50
5.3.4. FLUJOGRAMAS
Un flujograma (también conocido como diagrama de flujo) es la representación

gráfica de un algoritmo o proceso.
Estos diagramas utilizan símbolos con significados definidos que representan

los pasos del algoritmo y representan el flujo de ejecución mediante flechas que
conectan los puntos de inicio y de fin de proceso.
¿Para qué sirve un flujograma?
Las principales utilidades del flujograma son (Pardo, 2012):
 El proceso se entiende más fácilmente que leyendo un texto, incluso

para personas no familiarizadas con él.
 Los agentes involucrados al observar visualmente el proceso pueden lle-

gar más fácilmente a un acuerdo sobre los métodos que hay que seguir.
 Se puede utilizar para mejorar, identificar problemas, establecer recur-

sos, coordinar acciones, delimitar tiempos…
 Deja bien definidas las responsabilidades y funciones de cada uno de

los agentes que intervienen.
 Es útil para establecer indicadores operativos.
51
 Facilita el diseño de nuevos procesos.
 Apoya en la formación personal.
 Permite mejorar la gestión de la organización.
5.3.4.1. Tipos
Los flujogramas pueden ser de dos tipos:
 Tipo matricial: los agentes que intervienen en el proceso aparecen en

la cabecera del dibujo y las actividades desempeñadas se encuentran
subordinadas a ellos. Se pueden construir de arriba abajo (recomenda-
do) o de izquierda a derecha.
 Tipo lineal: las actividades del proceso aparecen una debajo de otra
por orden de ejecución.
Te aconsejamos utilizar el lineal. Es más fácil de cons-

truir.
5.3.4.2. Elementos y su notación
Hay múltiples signos que se utilizan para la generación de flujogramas. Sin em-
bargo, hay algunos básicos que son los más utilizados:
 Inicio/fin:
 Indica el inicio y el final del diagrama de flujo.
 Está reservado a la primera y última actividad.
 Un proceso puede tener varios inicios y finales.
52
 Actividad o tarea:
 El nombre debe incluir siempre un verbo de acción (aunque a ve-
ces se utiliza una operación matemática).
 Las cajas se pueden numerar.
 Decisión:
 Según el valor de la respuesta, tomará un camino u otro.
 El nombre debe ser una pregunta.
 Flujo:
 Se representa como una flecha con una única dirección.
 Indica la dirección en que se van ejecutando los distintos elemen-
tos del proceso.
 Une símbolos entre sí.
 Pueden tener una etiqueta.
Por ejemplo, las salidas de una decisión pueden tener “sí” y “no”
para indicar la salida cuando la respuesta es sí y la salida cuando
es no.
53
 Subproceso:
 Es un proceso que se ejecuta dentro del proceso principal.
 Se podrá desarrollar con otro diagrama de flujo.
 Entradas y salidas:
 Representan entradas que se utilizan en las actividades y salidas

generadas por el proceso.
 Existen muchos tipos.
Algunos ya no se utilizan (como la lectura de tarjetas perforadas).

Vamos a ver los más interesantes.
 Referencias o conectores:
 Indican que el flujo continúa por otro lugar.
 Pueden conectar dos lugares de la misma página o de distintas

páginas.
54
No tienen por qué tener color, aunque estos hacen

que sea más agradable y más sencillo de visualizar.
5.3.4.3. Reglas de construcción
Existen un conjunto de reglas básicas para la construcción de un diagrama de flujo.
 Regla 1.
Todo diagrama de flujo debe tener un inicio y un final.

 Regla 2.
Las líneas utilizadas para indicar la dirección del flujo del diagrama de-
ben ser rectas: verticales u horizontales.
 Regla 3.
Todas las líneas utilizadas para indicar la dirección del flujo del diagra-
ma deben estar conectadas. La conexión puede ser a un símbolo que
exprese lectura, proceso, decisión, impresión, conexión o fin del dia-
grama.
 Regla 4.
Los diagramas de flujos deben construirse de arriba hacia abajo (top-
down) y de izquierda a derecha (right to left).
 Regla 5.
La notación utilizada en el diagrama de flujo no debe depender del len-

guaje de programación. La solución presentada se puede escribir des-
pués en varios lenguajes de programación.
 Regla 6.
Al realizar una tarea compleja, es conveniente escribir comentarios que

expresen o ayuden a entender lo que hayamos hecho.
 Regla 7.
Si la construcción del diagrama de flujo ocupara más de una hoja, utili-

zaríamos los conectores adecuados y enumeraríamos las páginas co-
rrespondientes.
55
 Regla 8.
Esta última regla expresa que no podemos llegar con más de una línea
a un símbolo determinado.
5.3.4.4. Ejemplos de Flujogramas
Ahora que has aprendido conceptos, normas y reglas para realizar un

análisis de datos y procesos, vas a ver dos ejemplos.
Ejemplo: “Suma de dos números”
Vamos a leer dos números por teclado, los vamos a sumar y mostraremos el
resultado en un documento.
Suma de dos números
56
Un programador o analista, concluye que tiene que obtener 2 datos A y B, que

(podrían estar almacenados o ser introducidos por pantalla), que hay que reali-
zar un proceso de suma, y después mostrar el resultado.
57
6. PENSAR COMO UN PROGRAMADOR

Es hora de que pienses como un programador.
Veamos qué tal se te da con el próximo ejemplo.
Fuente: Public domain vectors
Para comprobar todo lo que has aprendido, vamos a ver un algoritmo de para
quedar con un amigo/a.
Hay una posible situación, que no está reflejada,

intenta saber cuál es antes de continuar al siguiente
apartado. Ahora tienes que utilizar la lógica de ser
programador. Y también te sirve tu experiencia a la
hora de quedar con amigos o amigas…
58
Solución
¿Has detectado algún error?
59
Este diagrama da por supuesto, que la persona a la que has llamado, si no está
en casa, va a devolverte la llamada.
¿Pero… y si no te llama?
¿La volverías a llamar?
Cuantas veces volverías a llamar si no está en casa y no te devuelve la llamada…
Ahora ya empiezas a pensar cómo un programador.

Adelantándote a las necesidades que el usuario aún
no sabe que tiene o que podrá tener en el futuro.
60
¿QUÉ HAS APRENDIDO?
Ya puedes resolver un problema del mundo real, con la construcción

de un sistema de información.
Sabes abstraer el problema y comprender todas las partes que se relacionan

entre sí, y realizar un modelo conceptual de datos a partir de un esquema con-
ceptual.
Partiendo del diagrama de contexto, puedes ir añadiendo varios niveles de deta-

lle, descomponiendo procesos, hasta llegar a procesos que no pueden ser des-
compuestos.
Conoces el modelo entidad-relación (E/R), y los símbolos que debes utilizar para
crear un diagrama de Flujo de Datos, que permitirá su comprensión de un mo-
do visual.
Sigues sin saber construir una casa, pero estás listo para el diseño Lógico y
Físico de una base de datos.
61
AUTOCOMPROBACIÓN
1. El paso de la especificación de requisitos al esquema conceptual se

consigue mediante:
a) El diseño conceptual.
b) El diseño lógico.
c) El análisis conceptual.
d) El análisis físico.
2. Describe la estructura de los datos que vamos a almacenar:
a) Modelo conceptual.
b) Diseño conceptual.
c) Esquema conceptual.
d) Todas son correctas.
3. En el modelo entidad relación, una persona sería:
a) Una entidad.
b) Un atributo.
c) Una relación.
d) Un Identificador.
63
4. ¿Cuál debería ser el primer paso para la construcción del modelo con-
ceptual de datos?
a) Identificar entidades.
b) Identificar las relaciones entre entidades.
c) Identificar atributos.
d) Recopilar información.
5. Si decimos que alguna ocurrencia de la entidad genérica no corres-

ponde con ninguna ocurrencia de las subentidades, nos referimos a la
jerarquía:
a) Total.
b) Parcial.
c) Exclusiva.
d) Superpuesta.
6. Un diagrama de flujo de datos representa gráficamente:
a) El flujo o movimiento de los datos a través del sistema.
b) La lógica de los procesos.
c) Las trasformaciones de los datos al pasar por un proceso.
d) Todas ellas.
7. ¿Cuál de los siguientes no es un elemento de los DFD?
a) Entidad externa.
b) Proceso.
c) Actividad.
d) Almacén de datos.
64
8. ¿Cuál de las siguientes afirmaciones es falsa respecto a una entidad

externa?
a) Representa un ente ajeno al sistema (personas, organizaciones u otros

sistemas) que proporciona o recibe información de este.
b) Las relaciones entre entidades externas se estudian en el modelo.
c) Normalmente solo aparece en el diagrama de contexto, aunque puede

aparecer en niveles inferiores si ayuda a la comprensión del diagrama.
d) Puede repetirse en un mismo nivel de diagrama para no entrecruzar líneas.
9. ¿Cuál es el primer diagrama que se debe hacer en un DFD?
a) Diagrama de contexto.
b) Diagrama de nivel 1.
c) Diagrama de subsistemas.
d) Las respuestas a y b son correctas.
10. ¿Cuál de los siguientes no es un elemento de los flujogramas?
a) Tarea.
b) Flujo.
c) Entidad.
d) Decisión.
65
SOLUCIONARIO
1. a 2. c 3. a 4. d 5. b
6. d 7. c 8. b 9. a 10. c
67
BIBLIOGRAFÍA
 SILBERSCHATZ, A., KORTH, H., SUDARSHAN, S. Fundamentos de bases de

datos. 4.ª edición. Madrid: Editorial McGraw-Hill, 2002.
 http://www3.uji.es/~mmarques/f47/teoria/tema6.pdf.
 https://es.slideshare.net/ruthamada/modelo-conceptual-de-la-base-de-
datos-360327.
 https://es.scribd.com/document/365899939/En-Que-Consiste-El-
Modelo-Conceptual-de-Una-Base-de-Datos.
 https://en.wikipedia.org.
 https://es.wikipedia.org.
 http://www.unirioja.es/cu/arjaime/Temas/02.Modelo_E_R.pdf.
 http://bibliotecaprofesional.com/el-modelo-entidad-relacion-en-bases-
de-datos/.
 https://gsitic.wordpress.com/2018/04/17/biii6-modelizacion-
conceptual-el-modelo-entidad-relacion-extendido-e-r-elementos-
reglas-de-modelizacion-validacion-y-construccion-de-modelos-de-
datos/.
 https://archivos.csif.es/archivos/andalucia/ensenanza/revistas/csicsif/re
vista/pdf/Numero_24/ANGEL_COBO_2.pdf.
 https://es.slideshare.net/ruthamada/modelo-conceptual-de-la-base-de-
datos-360327.
 https://es.slideshare.net/Viv091/ejemplo-dfd-48917546.
 ftp://www.dlsi.ua.es/people/jaime/apuntes/aesi_cap4.pdf.
69
 https://manuel.cillero.es/doc/metrica-3/.
 https://www.smartdraw.com/data-flow-diagram/.
 https://www.lucidchart.com/pages/es/qu%C3%A9-es-un-diagrama-de-
flujo-de-datos.
 https://uvadoc.uva.es/bitstream/10324/12095/5/GUIA%20METODOL%C
3%93GICA%20PARA%20LA%20ELABORACI%C3%93N%20DE%20UN%2
0FLUJOGRAMA.pdf.
 https://www.enciclopediadetareas.net/2016/08/reglas-para-hacer-un-
diagrama-de-flujo.html.
 http://www.areatecnologia.com/diagramas-de-flujo.htm.
 https://www.monografias.com/trabajos60/diagrama-flujo-
datos/diagrama-flujo-datos2.shtml.
 https://vignette.wikia.nocookie.net/bigbangtheory/images/0/0a/Friend2.j
pg/revision/latest?cb=20121011222713.
 https://vignette.wikia.nocookie.net/bigbangtheory/images/6/69/The_Frie
ndship_Algorithm.jpg/revision/latest?cb=20100104100357.
 Piluca Tomás Escobar. Técnico de Harware, Software, Redes y Progra-

mación.
70

TEMA1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TEMA1

Cargado por

Copyright:

Formatos disponibles

UD012107_V(02) MD.PlantillaTexto(04)Esp.

MODELO CONCEPTUAL DE DATOS

TU RETO EN ESTA UNIDAD ........................................................................ 3

5.3.4. FLUJOGRAMAS ...................................................................................... 51

TU RETO EN ESTA UNIDAD

Si quisieras construir una casa…

¿Empezarías por el tejado? ¿Empezarías a construir directamente… o hablarías

¿Podrías resolver un problema del mundo real, con la construcción de

Debes seguir un planteamiento:

 Observa y comprende el problema.

 Concreta los elementos importantes en el problema y no prestes aten-

 Ya puedes, basándote en ese esquema, crear un diseño lógico.

1. INTRODUCCIÓN. LÓGICA DE PROGRAMACIÓN

Debes entender bien lo que el usuario pide y necesita, y adelantarte añadiendo

Veamos cómo debe pensar un programador para poder realizar el diseño de

Si tenemos un concesionario de Venta de coches, turismos de segunda mano,

 Coches: matricula, marca, modelo, motor, nº de puertas, color, …

Estos datos los reflejamos en tablas, que tienen filas y columnas:

Fila 1 Z-1010-B Seat León Diesel 5 Verde

Fila 2 M-2189-X Ford Focus Gasolina 3 Rojo

Fila 3 M-8596-J Citroën Xara Diesel 5 Verde

Columna Columna Columna Columna Columna Columna Columna

A cada fila de información excepto la del nombre del dato, le corresponde un

A cada columna de información se le asignará un valor que podrá estar o no

Analizando los datos vemos que:

 Dato matricula es alfanumérico, contiene números y letras.

 Dato nº de puertas es numérico, (y será  o = 3 y  o = a 5).

 Dato Color es Alfabético.

¿Cómo haríamos un diagrama de la secuencia de venta de un coche?

Este es un diagrama básico para entender la lógica de programar, pero debe

Una base de datos, es un conjunto organizado de datos y/o información.

“Es un conjunto exhaustivo, no redundante de datos estructurados, organizados (in-

Es el elemento más importante del sistema de información y, debe de estar su-

Forma un conjunto de archivos electrónicos. Las bases de datos tradicionales se

El diseño, desarrollo y gestión de bases de datos ha evolucionado mucho y, en

Ya has aprendido en unidades anteriores las estruc-

Un procedimiento, subrutina o subprograma es un fragmento del

Un procedimiento puede tener argumentos, que son una serie de variables de

Sistema gestor de bases de datos (SGBD)

Es un software que define y controla una estructura de datos, su almacena-

(Un software, sabemos que es un conjunto coordinado de programas, procedimien-

Su objetivo principal es simplificar y facilitar el acceso a datos, de forma rápida y

2.1. TIPOS DE BASES DE DATOS

Como MySQL, SQL Server y Oracle. Como su nombre lo indica utilizan

 Bases de datos no relacionales, conocidas como NO-SQL.

Difieren del modelo clásico de SGBDR (Sistema de Gestión de Bases de

La más conocidas son MongoDB y Redis, conocidas como NO-SQL (Not

 Bases de Datos transaccionales.

Su único fin es el envío y recepción de datos a grandes velocidades, es-

Es importante entender que su fin único es recolectar y recuperar los

Generalmente, para poderlas aprovechar al máximo permiten algún ti-

Ejemplo: transacciones entre cuentas bancarias.

 Modelo orientado a objetos.

 El modelo de base de datos plana.

 El modelo de base de datos jerárquica.

Representa la información como nodos de un grafo y sus relaciones

 Base de Datos Geográfica (BDG).

Es un conjunto de datos geográficos organizados de tal manera que

Vas a estudiar, en las siguientes unidades, el modelo relacional, no

3. DISEÑO DE BASES DE DATOS

Fuente: Public domain vectors

El diseño de la base de datos, es la base de todo el funcionamiento de un pro-

Todo debe estar totalmente especificado y concretado al máximo.

El diseño de bases de datos, lo realiza un analista y/o un programador.