Herramientas de Anlisis Estructurado

Diagramas de Flujo de Datos

Los diagramas de flujo de datos (DFD) son utilizados para modelar la funcionalidad de
un sistema. Tal como es descripto por DeMarco [DeMarco 79] y Gane & Sarson [Gane 79], un
DFD permite representar un sistema como una red de procesos de transformacin de datos que
intercambian informacin por medio de flujos de datos.
Un proceso en un DFD puede representar funcionalidad en distintos niveles de
abstraccin, desde unidades funcionales de una organizacin (por ejemplo: departamento de
recursos humanos, seccin de ventas, etc.) hasta expresiones simples (por ejemplo: clculo de la
taza nominal anual de un prstamo). La figura 1 presenta un ejemplo no necesariamente
completo, pero que ilustra las distintas componentes de un DFD.
Datos del
Cliente

Proceso

Clientes

Validar
Cliente

Pedido

Flujo de Datos

Nuevo Cliente

Cliente
Mensaje
de Error

Informar
Error

Confirmacin
de Pedido
Agente Externo

Mercaderias

Pedido
Validar
Existencia

Mercaderia
Invlida
Cliente
Invlido

Datos de
Mercaderia

Mercaderia no
Disponble

Informacin
de Embarque

Datos del
Cliente
Validados

Registrar
Pedido
Pendiente

Tarifas de Pedido
Informacin
de las Tarifas

Generar
Pedido del
Cliente

Pedido del
Cliente

Pedido
Pendiente
Pedidos Pendientes

Pedidos Aceptados

Depsito de Datos

Fig1.:Ejemplo de DFD - "Procesar Pedido de Clientes"

Cuando un pedido es ingresado, se consultan los datos del cliente y se valida su estado de cuenta.
Luego, se verifica la existencia en stock de la mercaderia pedida. Si hay existencia suficiente, se registra
como Pedido Aceptado y se genera una confirmacin del pedido. Si no hay existencia suficiente, el
pedido se registra como pendiente. Si los datos ingresados no son vlidos, un mensaje de error es
generado.

El diagrama de flujo de datos describe cmo los datos fluyen a travs del sistema, pero no
proveen informacin acerca de estruturas de control o de secuencias de ejecucin. La nica
secuencia que puede ser reconocida en un DFD es la determinada por la necesidad de

informacin: el proceso Generar Pedido del Cliente puede completar su funcionalidad slo en el
caso que los flujos de datos Datos del Cliente Validados, Informacin de Embarque e
Informacin de las Tarifas estn disponibles (fig.1). Por otra parte, los procesos Validar Cliente
y Validar Existencia no tienen un orden definido de ejecucin relativo entre ellos, puesto que
ninguno de ellos recibe flujos de salida del otro proceso.
Podemos considerar al diagrama de flujo de datos como un lenguaje grfico, til para
describir la funcionalidad de un sistema, en un cierto grado de detalle. La sintaxis de dicho
lenguaje comprende los siguientes smbolos:
Flujos de Datos: Informacin pasada de una componente a otra. Son representados por
flechas rotuladas.
Procesos: Porciones de funcionalidad del sistema. Son representados por burbujas o
crculos con un nombre descriptivo de dicha funcionalidad.
Depsitos de Datos: Representan un archivo, rea de memria compartida o cualquier
mecanismo de almacenamiento de datos. Son representados por dos lneas paralelas.
Agentes Externos: Es una caja negra que genera flujos hacia el sistema o recibe
respuestas de l. Representa alguna cosa o entidad externa que interactua con el
sistema.

Flujos de Datos
Los flujos de datos son representados por arcos o flechas rotuladas. La flecha apunta en
la direccin del flujo de la informacin, los datos fluyen en esa direccin. El nombre con el que
se rotula el arco debe ser representativo de los datos contenidos en l. En algunos casos, cuando
el nombre es obvio, puede ser omitido (por ejemplo: un flujo que entra o sale de un depsito de
datos representando un registro completo) pero, en general, esa prctica no es recomendable.
Se han propuesto extensiones a la notacin utilizada por DeMarco y Gane & Sarson
[Ward 85, 86; Gane 79; Yourdon 89] algunas de ellas destinadas a hacer mas descriptivo el DFD,
incorporando informacin adicional por medio de convenciones de diseo de los flujos. En la
tabla siguiente se presenta un resumen de las notaciones mas utilizadas.
Flujos de Datos - Notaciones mas utilizadas
Flujo
Discreto
Flujo
Contnuo
Flujo de
Dilogo

Fb
A

A
Fa
B

La informacin contenida en F solamente esta disponible para el

proceso A, en un momento dado y con periodicidad discreta.
La informacin contenida en F esta disponible, para el proceso A, en
forma continua en un intervalo de tiempo. Es utilizado para modelar
cantidades medibles (ej.: temperatura) en sistemas de tiempo real.
El flujo de datos de dilogo es una simplificacin, de dos flujos de
datos relacionados (uno es consecuencia del otro).

Flujo de
Control
Activaci
n
Suspensi
n
Flujo
Temporal

Destino
Mltiple
Conjunci
n
Divisin

Un flujo de control que representa la necesidad de activacin de un

proceso. Es utilizado en protocolos de sincronizacin entre procesos.

Un flujo de control que representa la necesidad de desactivacin o

suspensin de un proceso. Es utilizado en protocolos de sincronizacin
entre procesos.
Un flujo de control que modela la ocurrencia de un evento temporal
especificado por la condicin temporal Ct (ej.: fin del dia, etc.).
Tpicamente se rotulan con un nombre con el prefijo: es hora de
El flujo de datos F es provisto por una de dos fuentes. El proceso A
precisa de los datos contenidos en el flujo pero no tiene mayor
importancia la fuente.
El flujo de datos F es generado por el proceso A y es enviado a dos
destinatarios diferentes (simultaneamente).

Ct

Fuente
Mltiple

Y
A

Un flujo con lnea de trazos es utilizado para modelar la ocurrencia

de un evento que precisa que se ejecute una accin del sistema. Este
flujo no transporta datos.

El flujo de datos F es la unin de los flujos X e Y generados por

fuentes diferentes.

Dos subconjuntos diferentes del flujo de datos F (X e Y) son

enviados hacia dos destinatarios diferentes.

Procesos
Un proceso representa una componente funcional del sistema. Un proceso transforma,
distribuye o genera datos. Por ejemplo, los procesos pueden realizar operaciones aritmticas o
lgicas sobre los datos que recibe para producir algn resultado. Los procesos en un DFD son
representados por un crculo (en la notacin de DeMarco) o como una caja con bordes
redondeados (en la notacin de Gane & Sarson) con el nombre del proceso en su interior. Deben
utilizarse nombres significativos, conteniendo por lo menos un verbo, para definir la operacin
desempeada.
Notacin de Gane & Sarson

Notacin de DeMarco

1.5

Referencia al proceso
comunmente un nmero
compuesto representando
niveles de refinamiento

1.5

Validar
Cliente

Validar
Cliente

Respecto de los procesos, un DFD describe nicamente los nombres y los flujos de
entrada y salida, sin aportar ninguna otra informacin sobre las actividades internas de los
procesos. Para describir con mayor detalle, y especificar la funcionalidad por la que es
responsable el proceso, se utilizan tcnicas de especificacin de procesos, que sern descriptas
mas adelante.
Proceso
Ct

Flujo Temporal

Proceso
A

de
Control
Controlar
Ejecuin
de A y B
3

Flujo de Control

Inactivacin

Proceso
B

Ocacionalmente, un proceso tendr por funcin la de controlar la ejecucin de otros

procesos del DFD, en lugar de tener por funcionalidad la de transformar datos. Esos procesos son
denominados procesos de control. Los procesos de control son representados por lneas de trazo
en su contorno.

Depsitos de Datos
Un depsito de datos es incluido en un DFD para modelar la necesidad de almacenar
datos. Un depsito de datos puede representar un archivo en el disco de la computadora o un rea
de memria global a los procesos. En la literatura es posible encontrar que este mismo concepto
puede recibir otros nombres como por ejemplo: Archivo, Almacenamiento de Datos o
Repositorio.
Notacin de DeMarco

Notacin de Gane & Sarson

Cliente

A1

Cliente

Las lecturas que se realizan a un depsito de datos son representadas por flujos de salida
(del depsito), y las actualizaciones de informacin se representan por flujos de entrada (al
depsito). Comunmente, el nombre de un depsito de datos es un sustantivo y puede estar
compuesto tambin por adjetivos. Los verbos no son vlidos como parte del nombre, puesto que
los almacenamientos de datos en los DFDs representan una entidad esttica, carente de
funcionalidad o comportamiento alguno. La estructura de datos contenida en el archivo es
documentada en un diccionrio de datos, como se mostrar ms adelante.

Agentes Externos
Un agente externo establece el origen o fuente de los datos utilizados por el sistema o el
receptor de los datos producidos por l.
Los agentesNotacin de DeMarco
externos
Notacin de Gane & Sarson
(tambin
denominados
Departamento
Departamento
de Ventas
entidades externas) de Ventas
no son parte del
sistema.
Son
modelados como
cajas negras que generan o reciben datos del sistema. Su funcionalidad y comunicacin con
otros agentes externos son irrelevantes, desde el punto de vista del sistema siendo desarrollado.
Un agente externo puede representar algn rea funcional de una organizacin, o el cargo
de un funcionario, una agencia del gobierno, un dispositivo generador de datos contnuos u otro
sistema que debe interactuar con el sistema modelado.

Refinamiento de Procesos en un DFD

Un DFD es una herramienta comunmente utilizada para anlisis top-down, es decir que
permite realizar un anlisis que va de lo general a lo particular del problema. Los DFDs son
utilizados para modelar tanto vistas detalladas como de alto nivel de un sistema o programa
[Yourdon 78]. La funcionalidad de un proceso puede llegar a ser tan compleja que para
comprenderlo sea necesario detallar sus actividades de manera separada. Como ejemplo,
consideremos un proceso representando el trabajo de toda un rea funcional de una organizacin.
En ese caso, el proceso complejo puede ser especificado con otro DFD mas detallado. As, un
rbol de DFDs puede ser desarrollado presentando diferentes niveles de abstraccin en el
modelado de un sistema.
La figura , presenta la especificacin de un proceso utilizando otro DFD. El proceso P
resulta muy complejo y debe ser refinado para obtener una mejor comprensin de su
Fs1

A
Fa

Fa

Fs2

Nivel N

Fs1

Ap

Fig 2.: Especificacin

del proceso P con un DFD mas detallado (Refinamiento)
P1
z

w
P2

Nivel N + 1

P3
Fs2

funcionalidad.
El refinamiento de DFDs tiene una regla de validacin cruzada para garantizar
consistencia en el modelado de los procesos, en los diferentes niveles de abstraccin:
Los flujos de entrada y salida de un proceso deben ser preservados en el
refinamiento. Es decir, todos los flujos de entrada y de salida de un proceso
deben ser los mismos flujos de entrada y salida del DFD de nivel
inmediatamente inferior, en el rbol de niveles generado por el proceso de
refinamiento.
La figura presenta un ejemplo de refinamiento. Este ejemplo representa una vista mas
detallada del proceso Validar Cliente del DFD de Procesar Pedido de Clientes presentado en la
figura .

Datos del
Cliente

Datos del
Nuevo Cliente

Obtener
datos del
o
Cliente

Pedido

Datos
de Cliente
Existente

Cliente
Invlido

El Depsito de datos "Cliente"

se representa nuevamente en este este
Nivel para destacar que es actualizado
nvel

Cliente

Nuevo Cliente
Crear
Registro de
nuevo
Cliente

Verificar
Crdito del
Cliente
Datos del
Cliente Validados

Flujos de Entrada y Salida

en el DFD de nivel inmediato superior

Fig 3.: Refinamiento del proceso Validar Cliente

Reglas de Validacin
El DFD es una herramienta de modelado muy simple de utilizar. La notacin incluye
solamente cuatro tipos de smbolos, lo que permite una buena y rpida comprensin de los
modelos. Si bien las reglas de construccin son simples y flexibles, existen algunas
combinaciones de smbolos invlidas, que constituyen errores estructurales.
Errores Estructurales
Depsitos
Activos
Depsitos
Mgicos
Depsitos
Sumideros
Depsitos
Externos
Agentes
Vinculados
Procesos
Mgicos
Procesos
Sumideros

Da

Dm
Ds
Ag

Dos depsitos de datos no pueden estar unidos por un flujo

de datos sin un proceso que oficie de intermediario.

Debe existir al menos un flujo de entrada y un flujo de

salida en todos los depsitos de datos.

Los depsitos no pueden generar "mgicamente" ni ser

"sumideros" de datos.

Un agente externo no puede comunicarse directamente con

un depsito de datos.

Ag2

Las vinculaciones entre agentes externos no son relevantes

para el sistema. Ellos son cajas negras.

f
Ag1

Debe existir, al menos un flujo de entrada1 y un flujo de

salida en todos los procesos.

Los procesos no pueden generar "mgicamente", ni ser

"sumideros de", datos.

Pm

Ps

Adems, debern tenerse en cuenta reglas de balance en los flujos de entrada y de

salida de procesos y depsitos, con el objetivo de mantener el modelo del sistema consistente y
completo.
Balance de Entradas y Salidas

1 Sin considerar flujos de lectura de depsitos de datos.

Depsitos
de Datos

z
d

Procesos

z
P

Los flujos de entrada y salida de un depsito slo pueden

contener un subconjunto de la estructura de datos
almacenada en l. As, observando el ejemplo de la
izquierda, la estructura de datos de d debe ser tal que:
((x y) d)(z d)
En general, un principio a tener en cuenta en el diseo de
la estructura de un depsito de datos y de los flujos de
entrada y salida de este, es el de:
Todo lo que se ingresa en un depsito debe ser extrado
en algn momento, de lo contrario no tiene sentido
almacenarlo. Y todo lo que se extrae de l debe haber sido
ingresado antes, o no podra encontrarlo.
Los flujos de salida de un proceso deben poder ser
definidos como una funcin de los flujos de entrada:
z = p(x, y) = f(p'(x), p''(y), ) en la especificacin provista
para el proceso p, debe resultar natural y simple de
interpretar esa correspondencia (f), principalmente (que
puede representar, por ej. , estados locales).

Construccin Sistemtica del DFD

Al desarrollar sistemas grandes y complejos, en general, no existen medios que guien al
analista de sistemas en el diseo de un DFD. El Analista se sienta en su mesa, contemplando una
hoja de papel, esperando por un momento de inspiracin divina o saturandose de ideas que le son
imposibles de expresar todas a la vez. Esta incertidumbre puede eliminarse intentando aplicar un
mtodo de construccin sistemtico, asistido por herramientas complementarias que ayudan a
desglosar el problema en partes y tratarlas una por vez en una manera organizada.
A continuacin se desarrollar un ejemplo concreto de construccin sistemtica de
DFDs. El mtodo que aplicaremos es descripto de manera informal, a fin de presentar algunas
otras herramientas que asisten en la construccin de un modelo funcional de un sistema,
expresado en una jerarqua de DFDs. El mtodo, as como los modelos, herramientas y criterios
que apoyan las decisiones que involucra, ser descripto en mayor detalle en el contexto de la
metodologa de Anlisis Estructurado Moderno.
Al desarrollar un sistema, cualquiera fuere su tamao, es necesario contar en primer
trmino, con una narrativa textual y una declaracin concisa de los objetivos del sistema (la
funcionalidad que se requiere, es decir lo que se espera que el sistema haga), por supuesto
validada con el usuario del sistema (las personas a las que l esta destinado).
A continuacin, se presenta una narrativa textual, y su correspondiente declaracin de
objetivos, referente al caso de estudio que abordaremos: el desarrollo de un sistema de
informacin para la administracin de un hotel.

Caso de Estudio - Administracin Hotelera

Un hotel acepta reservas de habitaciones y exige el pago de un adelanto del 50% de la
tarifa (precio de la habitacin * cant. de das). En la operacin de reservas, un pasajero, consulta
sobre sus necesidades de alojamiento. El recepcionista, para poder responder, arma un cdigo
segn lo que el cliente demande. Con este cdigo verifica la disponibilidad, y se la comunica al
pasajero junto con el precio, o si no tiene lo requerido, pide alternativas. Al confirmar el pasajero
su reserva, el empleado toma los datos personales y le da un nmero de reserva. Ante el pago de
la reserva, se la registra junto con la fecha de pago y se enva un recibo a vuelta de correo.
Este hotel tiene un concesionario en el servicio de bar y restaurante, cuyos comensales no
necesariamente estn alojados. En el caso que s lo estn, los vales firmados por los clientes son
procesados por la administracin del hotel, que agregar el importe de esas consumiciones a la
factura que emita cuando el pasajero se retire del hotel. Ante el pago de los clientes se
confeccionan y entregan recibos. Una vez por semana la administracin confecciona un informe
para el concesionario del bar con el detalle de las consumiciones realizadas por los clientes,
acompaado por el importe correspondiente.
La gerencia, semanalmente recibe un informe de la facturacin emitida. A pedido de la
misma se confecciona un informe estadstico de ocupacin de habitaciones.
Objetivos Funcionales:

Administracin de Informacin sobre Reservas.

Administracin de Informacin sobre Pasajeros.

Administracin de tarifas y ocupacin de habitaciones.

Facturacin en lnea.

Generacin de Informe Semanal de Servicios.

Generacin de Informe Semanal de Facturacin.

Generacin de Estadsticas de Ocupacin de Habitaciones.

A partir de esta narrativa, se debe obtener una descripcin de los hechos, que ocurren en
el entorno o ambiente en el que el sistema funcionar, y a los que el sistema debe dar una
respuesta preplaneada. Es decir, podemos ver al sistema como un agente que reacciona ante
determinados estmulos que ocurren en su mundo exterior. Una vez conocido lo que estimula al
sistema, nuestra tarea consistir en planificar sus reacciones acorde con los objetivos.
Utilizaremos, para describir y enumerar los hechos o eventos que estimulan al sistema y
que hacen a este reaccionar, una herramienta denominada lista de eventos.

Construccin de la Lista de Eventos

Para detectar los eventos se deben analizar todas las oraciones de la narrativa, analizando
fundamentalmente, los diferentes sustantivos que aparecen. A partir de ellos podremos reconocer
sujetos externos, es decir entidades que pueden generar estmulos al sistema, y otros objetos
candidatos de los cuales el sistema mantenga informacin, es decir que constituiran su memoria
esencial.
En la mayora de los casos, el medio ms facil para identificar los eventos relevantes para
un sistema es visualizar al sistema en accin: implica examinar cada sujeto (entidad, agente)
externo y preguntar cual es el efecto que sus acciones pueden tener en el sistema.
Al extraer los eventos de la narrativa y construir la lista de eventos, es necesario tener en
cuenta que un evento:

Ocurre en el ambiente del sistema (es generado por algn sujeto externo al sistema).

Genera una respuesta, del sistema, preplaneada.

Ocurre en un punto del tiempo.

Los eventos detectados se redactan de la siguiente forma:
<sujeto> <verbo> <objeto>
Para los sujetos utilizaremos el artculo indefinido en forma singular (un, una).

Lista de Eventos construida para el Caso de Estudio:

1.
2.
3.
4.
5.
6.
7.
8.
9.

Un pasajero realiza un pedido de reserva

Un pasajero acepta la reserva
Un pasajero paga la reserva
Un pasajero cancela la reserva
Un pasajero se presenta para alojarse
Un pasajero informa que se retira
Un pasajero paga la factura
El concesionario entrega factura por consumicin
Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una
semana desde el ltimo informe)
10. Es hora de confeccionar el informe de facturacin para la Gerencia (C.t.: ha pasado
una semana desde el ltimo informe)
11. La Gerencia realiza un pedido de estadsticas de ocupacin
12. La Gerencia enva nuevas tarifas para habitaciones

Adems de una descripcin de los estmulos a los que el sistema responde, es necesaria
tambin, una descripcin de los lmites que separan al sistema de su medio ambiente. Con esta
descripcin tendremos una buena comprensin de los alcances que tiene el sistema. Utilizaremos
para describir esto, el Diagrama de Contexto. Este diagrama es un caso especial del diagrama de

flujo de datos, en el cual una nica burbuja representa al sistema entero. El nombre que se le da a
dicha burbuja (proceso) es normalmente, el nombre del sistema o una sigla patrn o modelo.
Construccin del Diagrama de Contexto
La construccin del diagrama de contexto involucra los siguientes pasos:

Para cada sujeto de la lista de eventos se dibuja una entidad externa.

Para cada evento, buscar un nombre para el paquete de datos que sirve de estmulo.

Para cada evento dibujar un flujo de la entidad externa al sistema, colocndole el

nombre y el nmero de evento que lo genera.

Dibujar la respuesta del sistema a cada estmulo y colocarle el nmero de evento

correspondiente. (Si la respuesta es interna, es decir no sale del sistema, no se dibuja.
Las externas se dibujan todas, y pueden ser ms de una por evento).

Por ltimo, se debe controlar la falta de estmulos necesarios, observando otras

respuestas en la narrativa.

Otra herramienta utilizada para describir los estimulos y respuestas del sistema es la tabla de
estmulo-respuesta, que generalmente se construye junto con el diagrama de contexto. Esta tabla
asocia cada estmulo que se produce en el ambiente con las respuestas que el sistema produce,
describiendo adems las respuestas internas o actividades que el sistema realiza ante cada evento.
Diagrama de Contexto y Tabla de Estmulo-Respuesta para el Caso de Estudio
Hasta aqu lo que se ha logrado es comprender mejor el problema, es decir el sistema que
debemos desarrollar. Conocemos los eventos que lo estimulan (Lista de Eventos) y las respuestas
que se generan por cada evento, como as tambin qu agentes externos estn involucrados
(Diagrama de Contexto, figura ). Tambin tenemos una idea, aunque poco precisa, de las
actividades a desarrollar ante cada evento (respuestas internas en Tabla Estmulo-Respuesta).
Los modelos construidos hasta aqu se denominan comnmente, en su conjunto, Modelo
Ambiental.
Al final de la etapa de contruccin del modelo ambiental tambin se dispone de una
primera versin del Diccionario de Datos (DD) conteniendo, al menos, una descripcin de cada
uno de los flujos de datos del diagrama de contexto. El DD ser omitido por simplicidad, y a los
efectos de no saturar la exposicin en desarrollo. La construccin del diccionario de datos ser
objeto de una seccin posterior.
A partir del modelo ambiental tendremos que descubrir y modelar la manera en que el
sistema trata los diferentes eventos que recibe para generar las respuestas deseadas por los
agentes externos y, tambin, se deben descubrir y modelar los depsitos persistentes que
contendrn la informacin esencial a ser manejada por el sistema. Esto es, tendremos que

10

modelar todo lo que acontece en el interior del nico proceso del diagrama de Contexto, que
representa al sistema.
pedido reserva (1)
informe ocupacin (11)
reserva disponible (1)

Gerente

confirmacin reserva (2)

informe facturacin (10)
nmero reserva (2)
pedido informe
ocupacin (11)

datos ingreso (5)

nmero habitacin (5)

Pasajero

recibo reserva (3)

pago reserva (3)

Sistema de
Administracin
Hotel

nuevas tarifas (12)

Es hora de confeccionar informe al
concesionario y pagar (9)
Es hora de confeccionar informe de
facturacin para la gerencia (10)

recibo factura (7)

pago factura (7)

1 semana
1 semana

factura consumicin (8)

cancelacin reserva (4)

Concesionario

factura (6)

informe pago (9)

aviso retiro (6)

En este punto, podramos

aplicar deunContexto
enfoque
clsico
de anlisis estructurado para
Fig 7: Diagrama
del caso
de estudio
descomposicin descendente o top-down [DeMarco 79; Gane 79]. Este enfoque propone la
construccin de una jerarqua de DFDs, cada una representando un nivel de abstraccin
diferente. Se comienza con la construccin de un DFD de primer nivel (o nivel 0), que constituye
la explosin del diagrama de contexto. Para la construccin del DFD de primer nivel, el analista
(o el grupo de analistas) estudia el diagrama de contexto y crea un DFD (de nivel 0) sin una
estrategia que lo asista. Utilizando su propio conocimiento del problema, o del tipo de
aplicacin, y su sentido comn, divide al sistema en "Burbujas Importantes" (representando por
ejemplo subsistemas). Estas burbujas importantes, o subsistemas principales, son particionadas a
su vez en otras, representando un nuevo nivel de descripcin acerca del detalle de las
transformaciones que el sistema produce sobre los datos que recibe. Este proceso de
descomposicin se aplica a cada burbuja en cada nivel, describindola con un nuevo DFD, hasta
alcanzar una burbuja que denominaremos atmica y que no requiere de mayor
descomposicin, y cuyo funcionamiento pueda ser descripto por medio de una tcnica de
especificacin complementaria (estas se vern en detalle ms adelante).

11

Estmulos
Respuestas
Eve
Entidad
Estmulo
Externa
Entidad
Interna
nto
Externa
(Flujo
de
(Flujo
de Externa
(Actividades o
Origen
datos)
datos)
Destino
Procesos que involucra)
1
Pasajero
Pedido_Res
Reserva_Dispo
Pasajero

Codificar
las
erva
nible
necesidades
del
pasajero

Verificar
disponibilidad

Informar al pasajero
precio
y
disponibilidad
2
Pasajero
Confirmacin_ Nmero_Reserva Pasajero

Registrar reserva
Reserva

Registrar pasajero
3
Pasajero
Pago_Reserva
Recibo_Reserva
Pasajero

Registrar pago reserva

4
Pasajero
Cancelacin_
------------------------- ---------------
Registrar cancelacin
Reserva
reserva
5
Pasajero
Datos_Ingreso Nmero_Habitaci Pasajero

Completar
datos
n
pasajero

Asignarle habitacin

Actualizar reservas

Abrir cuenta y factura

6
Pasajero
Aviso_Retiro
Factura
Pasajero

Cerrar
cuenta
y
factura
7
Pasajero
Pago_Factura
Recibo_Factura
Pasajero

Registrar pago

Registrar
consumiciones
pagadas
8
Concesionario Factura_
------------------------- -------------
Registrar
consumicin
consumiciones
para
cada pasajero
9
Evento
Informe_Pago
Concesionario Seleccionar
Temporal
consumiciones
pagadas

Emitir
informe
concesionario

Pagar concesionario
10
Evento
Informe_Facturaci Gerencia

Confeccionar informe
Temporal
n
semanal
de
facturacin
11
Gerencia
Pedido_Inform Informe_Ocupaci Gerencia

Confeccionar informe
e_Ocupacin
n
semanal de ocupacin
12
Gerencia
Nuevas_Tarifas

Registrar
nuevas
tarifas
Fig 8: Tabla Estimulo-Respuesta del caso de estudio

Aunque el enfoque clsico de descomposicin descendente constituye el pilar

fundamental en el que se apoya el anlisis estructurado, en la prctica presenta varios problemas:

12

parlisis e incertidumbre en el anlisis, particin fsica arbitraria del sistema, etc. Estos
problemas se deben fundamentalmente a la falta de una estrategia robusta que conduzca la
descomposicin.
Podramos entonces, utilizar un enfoque ms sistemtico para hacer frente a los
problemas mencionados, intentando explotar la burbuja del diagrama de contexto utilizando el
lgebra de descomposicin de procesos, descripta en la seccin anterior. Utilizaremos sin
embargo, otro enfoque, con el objeto de presentarlo quedando su descripcin detallada para la
seccin que cubre la metodologa de Anlisis Estructurado Moderno. El enfoque que
utilizaremos aqu se denomina comnmente Enfoque Medio, o como fuera llamado por
McMenamim y Palmer, de particin por eventos [McMenam 84].
El enfoque de derivacin del DFD por particin de eventos propone desarrollar un
Diagrama de Flujo de Datos Preliminar y al nivel de detalle dado por los eventos en la lista de
eventos, que describir las transformaciones que el sistema produce sobre los datos como
respuesta a los eventos. Este enfoque, suele denominarse Enfoque Medio debido a que no es una
actividad puramente top-down ni tampoco es puramente bottom-up. Una vez que el DFD
preliminar est listo, puede ser necesario crear algunos niveles superiores (abstraccin de
funciones) y/o algunos niveles inferiores (descomposicin de funciones).
El DFD construido con este enfoque (DFD preliminar) presenta una burbuja por cada
evento existente en la lista de eventos, y estas burbujas no se comunican directamente unas con
otras, sino que la comunicacin se da a travs de depsitos de datos. Esto ltimo se debe a que
las burbujas o procesos del DFD preliminar representan funciones que generan las respuestas que
el sistema da ante cada uno de los eventos, y los eventos que ocurren en el medio ambiente
externo son, en general, asincrnicos. Es decir, no hay forma de garantizar que dos eventos
ocurrirn en el mismo instante, o con segundos de diferencia, o con algn otro intervalo
especfico de tiempo. Los eventos ocurren cuando tienen que ocurrir, por lo tanto, como la
respuesta a un evento puede requerir de datos producidos por otro proceso atendiendo otro
evento, la nica manera de sincronizar los mltiples procesos interdependientes del DFD
preliminar es mediante depsitos de datos.
Derivacin del DFD preliminar por eventos

Para cada evento:

Dibujar una burbuja que se ocupe de l.
Ponerle un nombre acorde con la transformacin que el sistema realiza con el estmulo y
observando la respuesta que debe dar.
Aadir los flujos existentes en el Diagrama de Contexto, asociados al evento.

13

Contestar para cada burbuja la pregunta: Qu datos necesita para producir la respuesta?
y agregar los flujos que se necesiten para aportar estos datos.

Contestar para cada burbuja la pregunta: Qu otros datos produce? y agregar los flujos
que se necesiten para producir y responder estos datos.
Estas ltimas preguntas pueden ser contestadas apoyndose en la narrativa, y en la tabla
de estmulo-respuesta.
A continuacin se presenta el resultado de aplicar estos pasos a los eventos en nuestro
caso de estudio.
1. Un pasajero realiza un pedido de reserva

pedido
reserva
reserva
disponible

reserva

Informar
Disponibilidad
habitacin

2. Un pasajero acepta la reserva

confirmar

nmero
reserva

reserva
Registrar
Reserva
habitacin

3. Un pasajero paga la reserva

recibo
pago reserva
Registrar
Pago
Reserva
pago
reserva

cancelacin de
reserva
Registrar
Cancelacin
reserva

Cancelacin de reserva
registrada

14

4. U
n
pasaj
ero
canc
ela la
reser
va

5. Un pasajero se presenta para alojarse

datos
ingreso
reserva
nmero
habitacin

Registrar
Alojamiento

datos

6. Un pasajero informa que se retira

Lliberacin habitacin
aviso
retiro

pasajero

factura
Facturar

servicio

7. Un pasajero paga la factura

pago
recibo
Registrar
Pagos
pago

8. El concesionario entrega factura por consumicin

factura
consumicin

Registrar
Consumicin

factura
consumicin

15

ingreso

9. Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una

semana desde el ltimo informe)

servicio
Es hora de confeccionar informe
De acturacin para gerencia
Pagar
Concesionario

informe de pago

10. Es hora de confeccionar el informe de facturacin para la Gerencia (C.t.: ha pasado una
semana desde el ltimo informe)
informe de
facturacin

servicio

Confeccionar
Informe de
Facturacin
es hora de confeccionar informe
De facturacin para Gerencia

11. La Gerencia realiza un pedido de estadsticas de ocupacin

pedido de informe de ocupacin
habitacin

Confeccionar
Informe
Estadstico
Ocupacin
informe de ocupacin

nro.de habitacin

12. La Gerencia enva nuevas tarifas para habitaciones

nuevas
tarifas
Registrar

16
tarifa

Nuevas
Tarifas

Luego de desarrollar un diagrama por cada evento se deben conectar los diagramas en
uno nico, agregando los repositorios necesarios entre los datos que una burbuja produce y que
otra consume. Conviene tener en cuenta en este paso, que toda informacin entrante a un proceso
que no proviene del medio ambiente externo, debe provenir necesariamente de un
almacenamiento. Por otra parte, toda informacin generada que no se emita directamente al
medio ambiente, deber almacenarse. Este paso puede apoyarse tambin en la construccin de un
modelo de datos (objeto de estudio de una seccin posterior) y en los objetos candidatos a
memoria esencial observados en la lista de eventos, para identificar los repositorios de datos. En
el caso de estudio, los repositorios identificados son: Reservas, Habitaciones, Pasajeros, y
Servicios.

17

DFD Preliminar Administracin Hotelera

recibo

pago
reserva

pedido
reserva

Registrar

cancelacin de
reserva

Pago
Reserva

reserva
disponible

Disponibilidad
confirmar
reserva

Registrar

reserva

Informar

Cancelacin
de reserva
pago
reserva
nuevas
tarifas

habitacin
reserva

nmero
reserva

Nuevas
Tarifas

Registrar
Reserva
habitacin

habitacin

Habitacione
s

reserva
Registrar

pedido de informe
de ocupacin

tarifa

datos
ingreso
nmero
habitacin

Registrar

Reservas

reserva

lliberacin

habitacin

nro. reserva

Confeccionar
Informe
Estadstico
de Ocupacin
informe de ocupacin

nro. habitacin

Alojamiento

Pasajeros
informe de
facturacin

datos ingreso

aviso
retiro

nro. habitacin
pasajero

factura

servicio

Servicios

Facturar

Confeccionar
Informe de
Facturacin
es hora de confeccionar informe de
facturacin para Gerencia

servicio
servicio
pago
recibo

es hora de confeccionar informe para el

concesionario y pagar

factura
consumicin

Pagar

Registrar

Concesionario

Pagos
Registrar

pago

Consumicin
informe de pago
factura
consumicin

Por ltimo, habr que refinar el diagrama verificando que no tiene errores estructurales y
corregir las fallas de comunicacin (agregar o refinar eventos).
Es necesario observar que el DFD resultante (DFD preliminar) se compone de un solo
nivel con un proceso por cada uno de los eventos. Para un sistema mediano o grande (50 o ms
eventos), el DFD preliminar contendr demasiados procesos y se presentar probablemente muy
desnivelado, estando representados diferentes niveles de abstraccin de manera simultnea. Para
mejorar su comprensin, precisamos subdividirlo realizando abstracciones. Esto quiere decir
que deseamos agrupar los procesos estrechamente relacionados en funciones de ms alto nivel de
abstraccin, en un diagrama de ms alto nivel. Se deben generar abstracciones para la obtencin

18

de un DFD de nivel 0 de complejidad adecuada, esto es, uno de no ms de 7 2 procesos. Este

nmero no es arbitrario como tampoco debe ser rgido, y representa un lmite para la
comprensin humana, que han encontrado expertos en ciencias de la comunicacin.
Una vez obtenido el DFD de nivel 0 se procede a realizar nivelaciones descendentes o
explosiones, las que se consideren adecuadas para lograr especificaciones adecuadas de las
funciones del sistema. Es decir, posiblemente los procesos identificados en el DFD de nivel 0,
resulten no ser procesos atmicos o primitivos y requieran particiones descendentes en DFDs de
nivel inferior, esto significa que dichos procesos pueden resultar demasiado complejos para ser
descriptos adecuadamente en una especificacin de proceso de una pgina.
Queda como ejercicio para el lector realizar abstracciones y explosiones adecuadas para
lograr un modelo funcional completo de nuestro caso de estudio, compuesto por una jerarqua de
DFDs.
Adems, sera interesante completar el sistema con la funcionalidad que considere
faltante, agregando nuevos eventos, y determinar el impacto que producimos en nuestro anlisis
al incorporar nuevos requerimientos funcionales. Como sugerencia, mnimamente debiera
atenderse lo siguiente: Todos los das acumular ocupacin y servicios; y Registrar
habitacin fuera de servicio.

19

Diccionario de Datos (DD)

El diccionario de datos es una herramienta fundamental en el modelado de sistemas. Las
herramientas grficas, como los diagramas de flujo de datos, los diagramas de estructura, los
diagramas de transicin de estados, etc., son de mucha importancia al modelar la estructura de
los sistemas (estructuras funcionales, estructuras de mdulos, estructuras de comportamiento,
etc.) y permiten una interpretacin general de las ideas modeladas pero, no son completos. Para
contar con una especificacin completa es preciso tener una descripcin textual de los detalles
que no pueden ser especificados en el diagrama.
El diccionario de datos es una lista organizada de todos los elementos de datos que le son
pertinentes al sistema (todos los nombres de las componentes de los diagramas), con definiciones
precisas y rigurosas para que el usuario y el analista de sistemas puedan conocer todas las
entradas, salidas, componentes de depsitos y estructuras intermedias existentes en el sistema. El
diccionario de datos describe:
El significado de los flujos y depsitos presentes en los DFDs.
La composicin de los paquetes agregados de datos (paquetes compuestos o tems
compuestos) que son transportados por los flujos de datos y que pueden ser divididos
en tems ms elementales.
La composicin de las estructuras de datos en los depsitos.
Los valores y unidades relevantes de los tems elementales de informacin de los flujos
de datos y depsitos de datos.
Los detalles de las relaciones entre los depsitos de datos.

Notacin
Existen muchas propuestas para la notacin a ser utilizada en el diccionario de datos. La
que se presenta a continuacin es una de las ms comunes, que utiliza un conjunto reducido y
simple de smbolos:
Smbolo
Se lee
Ejemplo de la
Interpretacin
Sintaxis
Se define por o
El tem I est definido por la expresin Y
:=
I := Y
+

Se compone de
Junto con o Y

()

Opcional

{}

Repeticiones de
o Iteraciones de
o Secuencia de

i{}s
[|]

Uno
O

entre"

I := A + B
I := A + ( B )

I := { A }
I := 1 { A } 10
I := [ A | B | C
]

El tem I est compuesto de A y B (la concatenacin

de A con B)
El tem I est compuesto de A y B , o de A slo (B
es opcional)
El tem I est compuesto de una secuencia de As
(iteracin)
El tem I est compuesto de una secuencia de As
(mnimo 1 y mximo 10).
El tem I est compuesto de A o B o C. Slo uno de
ellos. (o exclusivo)

20

**
@

Comentario
Campo Clave

* Texto *
@A

El Texto entre asteriscos es un comentario

El elemento A es uno de los campos clave de un
depsito de datos.

Ejemplos
CLIENTE

:= { cliente } * el archivo de Clientes *

cliente

:= @nro_cliente + nombre_cliente + direccin_para_remito + crdito

nro_cliente

:= * identificador interno de un cliente, campo clave del depsito CLIENTES *

* [ 1 ... 999 ]* * un nmero entre 1 y 999 *

crdito

:= [Positivo | Negativo]

nombre_cliente := ttulo_de_cortesa + primer_nombre + (nombre-intermedio) + apellido

ttulo_de_cortesa

:= [ Sr. | Srta. | Sra. | Dr. | Prof. | Don | Doa]

primer_nombre

:= 1{ caracter_vlido }30

nombre_intermedio := 1{ caracter_vlido }30

apellido

:= 1{ carcter_vlido }30

carcter_vlido

:= [ letra | dgito | ' | - | ]

dgito

:= [0 | 1 | 2 | 3 | 4| 5| 6| 7| 8| 9]

letra

:= [letra_en_mayscula | letra_en_minscula] * [A ... Z | a ... z]*

direccin_para_remito := calle + nmero_dir + (departamento) + (localidad) *si la localidad

no se detalla, la direccin es de Tandil*
calle

:= {carcter_valido}

nmero_dir

:= {dgito}

localidad

:= [Tandil | Villa Cacique | Barker | Jurez | Lobera | Posadas] * localidades en

las que se entregan pedidos *

pedido

:= nro_cliente + nombre_cliente + direccin_para_remito + 1 {item_pedido}

10 * un pedido puede contener hasta 10 items *

item_pedido

:= cdigo_artculo + nombre_artculo + cantidad

cdigo_artculo := 1 {dgito} 3 * identificador interno de un artculo, un nmero de hasta tres

dgitos *

21

Modelo Entidad Relacin (ERD)

La construccin del modelo entidad relacin (ERD) es el paso previo a la creacin y uso
de bases de datos en un desarrollo. El proceso de generacin de la base de datos comienza desde
la etapa de anlisis y se va completando hasta llegar a la etapa de implementacin.
El modelo entidad relacin es una herramienta que permite especificar la estructura
esttica de la aplicacin, modela dnde se encontrarn y cul ser la estructura de los datos. Los
datos deben estar bien organizados ya que si datos que se refieren a algn objeto especfico son
almacenados en diferentes lugares la bsqueda de estos datos resulta muy difcil. Este modelo
tiene los siguientes requisitos:

Accesibilidad: Si los datos no son fciles de acceder es muy difcil que sean utilizados.

Oportunidad: Los datos deben reflejar un pasado relativamente inmediato. Los datos
que no reflejan la situacin presente con suficiente validez no tienen valor para tomar
decisiones.

Precisin: Cada valor almacenado debe estar dentro de un rango aceptable de

precisin alrededor del valor real.

Consistencia: Los datos deben representar fielmente la realidad.

Disponibilidad: Un dato que se necesita pero que no puede ser accedido es un sntoma
de mala organizacin.

El modelo entidad relacin permite describir la informacin involucrada en un sistema

como un conjunto de entidades y las relaciones existentes entre ellas.
Nombre

Salario
Empleado

Sexo
Fecha de
Nacimento

Ttulo
Cdigo de
Funcin

Trabaja
en
1
Departamento

Fig. 9: Ejemplo simple de diagrama de Entidad Relacin

La figura 9 presenta un ejemplo de diagrama entidad relacin. En esta figura se pueden

distinguir tres tipos de componentes diferentes:

Entidades: Tambin llamado Tipo de Objetos o Clase de Objetos. Es diseada como

una caja y representa un conjunto de objetos, llamados instancias, que tienen
caractersticas comunes. Por ejemplo, en la figura 9 la entidad Empleado representa el
conjunto de todos los empleados que trabajan en una organizacin.

22

Atributos: Los valos vinculados a una entidad son llamados atributos. Representan
caractersticas comunes a todas las instancias de una entidad.

Relaciones: Son diseadas como un rombo y representan la relacin entre algunas

instancias de una entidad con instancias de otra. Por ejemplo, en la figura 9 la relacin
Trabaja en indica que un empleado (instancia de una entidad Empleado) trabaja en un
Departamento. La notacin 1 del lado del Departamento y N del lado del Empleado
indica que la relacin es uno a muchos, 1:N, y es interpretado como: varios empleados
trabajan en un departamento, o en un departamento trabajan varios empleados.

Entidades y Atributos
Una entidad representa la informacin que es necesario almacenar, pudiendo esa
necesidad de informacin abarcar personas o cosas tangibles como un empleado, un cliente o
materiales. Puede ser intangible como el ttulo de una funcin, una asociacin, un prstamo, una
compra o un pedido de seguro.
Una entidad tiene varios atributos que describen la informacin que se desea mantener:
tamao, valor, cdigo, fecha de nacimiento, direccin. Generalmente, en el procesamiento de
datos se almacena una coleccin de objetos semejantes tales como los empleados y se registra la
misma informacin para cada uno de ellos.
Comnmente, el programador mantiene un registro sobre cada instancia de una entidad, y
un tem de dato relacionado a cada atributo en cada uno de los registros. Los registros similares
son agrupados en archivos y pueden presentarse como una tabla de dos dimensiones como la
siguiente.
Estructura del Registro (Atributos de la Entidad)
Nmero de
Empleado

Nombre

Ocurrencia de un registro

Sexo

Fecha de
Nacimiento

Depto

...

Perez Jos
Balanagan
Jos
Lawrence
Rockefeller
Mara
Fred
Horseradish
Freda
...

Identificador
registro
(entidad)
del

Ttulo

Salario

(Instancia de una entidad)

Archivo lgico o relacin

53730
28719
53550
79632
15971

Cdigo
de
Funcin
la

M
M
F
M
F
...

10/03/3
5
10/10/1
9
09/09/3
01/11/3
2
2
25/02/6
3
...

Conjunto de valores
de un atributo o tipo
de item de
datos

(Entidad)
044
172
044
090
172

73
43
02
11
07

Contado
Abogado
r
Escribano
Consulto
Ingeniero
r

2.000
1.800
1.100
5.000
2.500

...

...

...

...

Algunos atributos son

si
identificadores de
por
otro registro (entidad)

Valores
atributo
s

En el cuadro hay un conjunto de tems de datos y es mostrado el valor de cada uno. Cada
lnea contiene los valores de los atributos de una instancia en particular de la entidad. Cada

23

columna contiene un tipo especfico de tem de datos, relativo a un tipo de atributo dado. La
columna de la izquierda contiene los tems de datos que identifican a la entidad. En este ejemplo,
la entidad es un empleado y el atributo designado como identificador de las instancias es el
nmero de empleado.
En un modelo de entidad relacin bien definido, las entidades y las relaciones deben estar
en tercera formal normal [Chen 76], sin embargo, frecuentemente las entidades no estn bien
definidas e incluyen caractersticas de otras entidades.

Relaciones
Una relacin representa un conjunto de vnculos lgicos entre instancias de dos o ms
entidades. Cada una de las relaciones en un diagrama entidad relacin tiene una semntica propia
que es definida por el tipo de vnculo existente en el dominio del problema modelado. Desde un
punto de vista matemtico puede ser definido como:
Una relacin entre entidades simples es una lista ordenada de entidades
y una entidad dada puede aparecer una o ms veces en la lista [Ullman 82].
Si en un diagrama entidad relacin hay una relacin R entre las entidades E1, E2, ..., En,
representa un conjunto compuesto por las listas (e1, e2, ..., en), (e1',e2', ..., en') ...; donde las
componentes ei, ei', ... son instancias diferentes de la entidad Ei. La cantidad de entidades que
participan en una relacin es arbitraria, sin embargo, se recomienda la utilizacin de relaciones
entre dos entidades, es decir, relaciones binarias.
Una entidad dada puede participar en ms de una relacin. Se pueden clasificar las
relaciones binarias en diferentes tipos como base en la cantidad de participantes de cada una de
las entidades.
En las siguientes secciones se definen los diferentes tipos de relaciones. Existen
diferentes convenciones para la notacin grfica de las relaciones. En las secciones siguientes se
utilizan las ms usadas: la notacin original de Chen [Chen 76] y la notacin utilizada por James
Martin [Martin 81], denominada tambin diagrama de Bachmann.
Relacin Uno-a-Uno
Una lnea uniendo las entidades A y B representa una relacin uno-a-uno. La barra corta,
ms interna, cruzando la lnea de la relacin (notacin de Martin) indica la obligatoriedad de la
relacin, es decir, una ocurrencia de la entidad tiene que existir para que la relacin tenga
sentido.

24

Notacin de Martin

Solo una instancias

es permitida

Notacin de Chen
1

Obligatoriedad

La figura representa grficamente la siguiente regla:

Cada ocurrencia de la entidad A esta relacionada a una y solo una ocurrencia de la

entidad B.

Cada ocurrencia de la entidad B esta relacionada a una y solo una ocurrencia de la

entidad A.

Por lo tanto, una ocurrencia, ni ms ni menos, de la entidad A puede existir con una, ni
ms ni menos, ocurrencia de la entidad B. Esta relacin es denominada relacin uno-a-uno
obligatoria. Las ocurrencias de las entidades A o B no pueden existir independientemente, una
depende de la otra para existir.
Chen, no considera la interpretacin de la obligatoriedad en las relaciones. La notacin en
la parte superior de la relacin es interpretada como la cantidad permitida de B depende de la
existencia de la entidad A, se disea una flecha apuntando a la entidad B.
Notacin de Chen
1

Opcionalidad
Un crculo sobre la lnea de la relacin de lado de la entidad B indica una relacin de
opcionalidad. Mientras que la relacin de B a A es obligatoria, la relacin de A para B es
opcional.
Notacin de Martin

Notacin de Chen

Opcionalidad

0,1

Esto es interpretado de la siguiente manera:

Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la

entidad B.

Cada ocurrencia de la entidad B (si existe) esta relacionada a una y solamente una
ocurrencia de la entidad A.

Una entidad A puede existir sin la presencia de una entidad B. Mientras que si la entidad
B existe, no puede haber mas que una ocurrencia de la entidad A relacionada. La entidad B no

25

puede existir sin la presencia de la entidad A. La figura siguiente presenta una relacin uno-auno opcional en los dos sentidos:
Notacin de Chen*

Notacin de Martin

0, 1

0,1

Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la

entidad B.

Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la

entidad A.

Tanto la ocurrencia de la entidad A como de la entidad B puede existir sin la presencia de

la otra. Si la relacin existe, cada ocurrencia de A puede estar relacionada solamente a una
ocurrencia de la entidad B y viceversa.
Relacin uno-a-muchos
Las relaciones con varias instancias de una entidad se representa por medio del signo
menor. Los siguientes ejemplos utilizan este tipo de relacin:
Notacin de Chen*

Notacin de Martin

1,n

Este ejemplo representa una relacin uno-a-muchos obligatoria, debido a que las barras
cortas cruzan a la lnea de la relacin. Este diagrama es interpretado de la siguiente manera:

Cada ocurrencia de la entidad A esta relacionada a una o varias ocurrencias de la

entidad B.

Cada ocurrencia de la entidad B esta relacionada a uno y solamente una ocurrencia de

la entidad A.

Ninguna de las entidades A o B pueden existir sin la presencia de la otra. La relacin

debe existir entre ocurrencias especficas de las entidades A y B. Una ocurrencia de la entidad A
en particular puede estar relacionada a varias ocurrencias de la entidad B, debe haber por lo
menos una ocurrencia de la entidad B. Por otro lado, una ocurrencia de la entidad B debe estar
relacionada, siempre, a una y solo una ocurrencia de la entidad A.
Opcionalidad
La siguiente relacin indica una relacin uno-a-muchos opcional con B:

Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de
la entidad B.

26

Cada ocurrencia de la entidad B, si existe, ser relacionada con una y solamente una
ocurrencia de la entidad A.
Notacin de Chen

Notacin de Martin

0,n

Siempre que existe una ocurrencia de la entidad B ella debe estar relacionada a una
ocurrencia de la entidad A y no ms ni menos que una. Si una ocurrencia en particular de la
entidad A esta relacionada a cero ocurrencias de la entidad B, la relacin no existe para esa
ocurrencia de la entidad A. Por otro lado, si la relacin existe, ella puede ser con una o varias
ocurrencias de la entidad B.
Notacin de Chen*

Notacin de Martin

0,1

0,n

La relacin anterior indica una relacin uno-a-muchos opcional entre A y B:

Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de
la entidad B.

Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la

entidad A.

Las entidades A o B no necesitan existir. Si existen, deben estar relacionadas. Si existe

una relacin entre ellas, una ocurrencia especfica de la entidad A puede estar relacionada con
cero, una o varias ocurrencias de la entidad B. Cada una de las ocurrencias de la entidad B
pueden estar relacionadas a solamente una ocurrencia de la entidad A. Por lo tanto, las
ocurrencias de la entidad B relacionadas a una ocurrencia de la entidad A no pueden estar
relacionadas a ninguna otra ocurrencia de la entidad A.
Relacin muchos-a-muchos
Dos relaciones uno-a-muchos para ambos lados pueden existir entre entidades, ellas se
convierten en una sola relacin muchos-a-muchos y es representada de la siguiente manera:
Notacin de Chen*

Notacin de Martin

1,m

1,n

Cada ocurrencia de la entidad A esta relacionada con una o varias ocurrencias de la

entidad B.

Cada ocurrencia de la entidad B esta relacionada con una o varias ocurrencias de la

entidad A.

27

Opcionalidad
Notacin de Chen*

Notacin de Martin

0,m

1,n

Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de
la entidad B.

Cada ocurrencia de la entidad B, si existe, esta relacionada con una o varias ocurrencias
de la entidad A.
Notacin de Chen*

Notacin de Martin

0,m

0,n

Cada ocurrencia de la entidad A, si existe, esta relacionada con cero, una o varias
ocurrencias de la entidad B.

Cada ocurrencia de la entidad B, si existe, esta relacionada con cero, una o varias
ocurrencias de la entidad A.

Relaciones Indefinidas
Se ha descripto cmo se representan grficamente las relaciones uno-a-uno y uno-amuchos, obligatoria y opcional. Sin embargo, cuando se esta desarrollando un modelo entidad
relacin puede suceder que no se conozca el tipo de relacin existente y que el tipo de relacin
no este hasta el momento definida. En estos casos la relacin es descripta de la siguiente manera:
Notacin de Chen

Notacin de Martin

Mecanismos de Abstraccin
En la construccin de diagramas entidad relacin existen mecanismos que permiten
modelar diversos tipos de abstraccin, muy tiles en la organizacin conceptual de los modelos
de datos.
Clasificacin
El mecanismo de clasificacin fue introducido intuitivamente, puesto que los tres
conceptos bsicos en los que se basan los diagramas entidad relacin fueron desarrollados como
una aplicacin de abstracciones de clasificacin:

Entidad: Una entidad es una clasificacin que representa un conjunto de objetos con
caractersticas comunes.

28

Atributos: Un atributo es una clasificacin que representa un conjunto de valores de una

propiedad atmica de una entidad o una relacin.

Relacin: Una relacin es una clasificacin que representa el conjunto de vnculos entre
objetos integrantes del mismo conjunto de entidades.

Agregacin de Atributos (atributos compuestos)

Un atributo de una entidad o relacin puede ser una estructura compuesta de tems que se
desean identificar. La figura siguiente presenta una entidad Cliente que tiene un atributo
compuesto Direccin.
Calle
Cliente

Direccin

Nmero
Ciudad

Provincia

CP

Especializacin (es-un o es-subtipo-de)

La relacin es-un o es-subtipo-de es una relacin muy comn en una clasificacin de
entidades. Es til si existen entidades con la mayora de la caractersticas comunes, pero con
algunas caractersticas diferentes. La figura siguiente presenta un ejemplo.
Notacin de Martin

Notacin de Chen*

Nombre

Nombre

Edad

Alumno de
Grado

Alumno

Edad

Alumno de
Grado

Alumno de
Pos-Grado

Alumno

Alumno de
Pos-Grado

Una especializacin tambin puede ser til si solamente un sub-conjunto de ocurrencias

de las entidades, a ser relacionadas, participan en la relacin.
Agregacin de Entidades (compuesto-por)
La relacin compuesto-por es una relacin que permite describir composicin, por
ejemplo la composicin de una factura como se describe en el siguiente ejemplo.

29

Notacin de Martin

Notacin de Chen*
Factura

Factura

1
Comp
por
1
Encabezado

Linea

1,n

Encabezado

Totales

Linea

1
Totales

Entidades Relacionantes
Existen situaciones en las cuales una relacin se convierte en una entidad. Por ejemplo, si
una relacin tiene atributos asociados a ella, es una entidad sin perder su propiedad de vinculo
entre entidades. La figura siguiente muestra un ejemplo.
Notacin de Martin

Notacin de Chen*

Matricula

Alumno

Matricula

Alumno

Disciplina

1,n

1,n

Disciplina

Note que, la notacin de Martin no hace diferencia entre los dos tipos de entidades. Sin
embargo, en la notacin de Chen la relacin convertida en entidad es notoriamente identificable.

Construccin de un Diagrama Entidad-Relacin

Existe un conjunto de pasos los cuales guian el proceso de contruccin de un modelo
entidad relacin, a partir de una lista de eventos, los cuales son descriptos a continuacin:
1.- Para cada evento construir una relacin
a.) El sujeto del evento es una de las entidades de la relacin.
b.) El predicado del evento es la otra entidad de la relacin.
c.) El verbo del evento es el nombre de la relacin.
Cliente

Factura

paga

2.- Eliminar las entidades que no posean datos que identifiquen instancias diferentes.
Instancia nica

BCRA

recibe

30

Balance

3.- Identificar relaciones que puedan servir como entidades asociativas

Cliente

pide

Cliente

Articulo

Articulo

Pedido

4.- Construir el modelo resultante.

5.- Identificar entidades demasiado generales o grupos de entidades demasiado particulares
y construir relaciones de especializacin.
6.- Identificar relaciones de composicin.
7.- Identificar entidades poco significativas:
8.- Completar el modelo de datos. Para cada entidad, cada relacin y cada entidad
asociativa, completar la correspondiente entrada en el diccionario de datos.

31