Modelado Conceptual

Introducción
Para diseñar datos, se sigue una metodología básica de la informática: refinamientos sucesivos.
En una primera fase o etapa se hace un diseño conceptual, de alto nivel de abstracción, determinando conjuntos
de datos y de relaciones, y atributos característicos de los mismos desde el punto de vista del sistema de
información1 que se analiza. Para esto se utiliza un lenguaje gráfico de modelado conceptual, como el de
Entidades y Relaciones (ER), propuesto originalmente por el Dr. Peter Pin-Shan Chen en 1976, del cual existen
actualmente diversas versiones, o bien UML, que permita representar el modelo de datos del sistema de
información en un diagrama o conjunto de diagramas (en el caso de UML, el modelo de análisis de dominio).
En la siguiente etapa se hace un diseño lógico, que consiste en transformar el modelo o representación del diseño
conceptual para poder implementarlo en un sistema informático, es decir, desde el punto de vista de cómo se
codificarán los datos. En este punto se distinguen los modelos de programación, y los modelos de base de datos.
Para los modelos de programación orientada a objetos, se transforman los diagramas de análisis de dominio en
diagramas de diseño de dominio (según el Proceso Unificado de Desarrollo), y para los modelos de base de datos
de derivan de los diagramas conceptuales (ER o de análisis de dominio) a especificaciones de estructuras de datos
según el modelo de base de datos que se utilizará; por ejemplo, para el modelo relacional, se puede utilizar un
lenguaje gráfico o una convención para expresar las especificaciones en formato de texto.
Y en la última etapa se hace un diseño físico, que consiste en traducir el modelo o representación del diseño
lógico a especificaciones de implementación en un lenguaje de definición de datos en un Sistema de Gestión de
Bases de Datos.

Principios de Abstracción del Diseño Conceptual

Diseñar datos a nivel conceptual implica:

▪ Detectarlos en el sistema de información para el que se está desarrollando el sistema informático que
los gestionará y especificar vínculos entre los mismos, en un proceso de abstracción que se denomina
clasificación: se trata de identificar datos que representen cosas (clientes, productos, servicios, etc.),
eventos (pedidos y ventas de productos, reservas y ventas de servicios, etc. –tienen fecha de ocurrencia)
y procesos (trámites, órdenes de servicio –tienen un estado que cambia cronológicamente), así como de
identificar vínculos entre ellos, y asignarles un conjunto o clase de pertenencia, que en el caso de que
sean datos se denomina “entidad”, y en el caso de que sean vínculos, “relación”.
Las entidades que agrupan representaciones de cosas se dicen “maestras”, y las que agrupan
representaciones de eventos o de procesos, “transaccionales”.
La clasificación de los vínculos ente datos comprende también determinar la cardinalidad de cada
entidad en una relación, es decir, la cantidad mínima y máxima de datos de esta, otra u otras entidades
que constituyen la relación con las que se puede vincular un dato individual de la entidad.

1 Conjunto de personas, datos, actividades y recursos materiales organizado para satisfacer las necesidades de
información de una organización (empresa o institución pública o privada) para que ésta cumpla sus objetivos. La
información puede ser operacional (de gestión o producción) o analítica (para toma de decisiones).

FIUBA Base de Datos – Curso Servetto Página 1 de 17

 Modelado Conceptual

▪ Especificar las características o atributos de los datos y de los vínculos entre éstos que sean pertinentes
para el sistema de información, en un proceso de abstracción que se denomina análisis: se determina las
cualidades o estado de los datos y de los vínculos entre datos.
La especificación de los atributos implica también determinar la cardinalidad de los valores que pueden
tomar para un dato en particular, es decir la cantidad mínima y máxima de valores atómicos que puede
tener cada atributo para un dato.
Hay atributos que se pueden describir en términos de otros atributos: son llamados atributos
compuestos. Tanto el atributo compuesto como sus componentes tienen su propia cardinalidad.

Clasificación
Cardinalidad de Entidades y de Relaciones como Conjuntos de Datos y
Vínculos
Si bien no se denota la cardinalidad de estos conjuntos porque depende de la cantidad de datos y de
vínculos entre ellos que existan en un momento determinado en el sistema de información que se modela,
conviene tener en cuenta una estimación de estos valores para evitar problemas de diseño como entidades
o relaciones unitarias (con un solo dato o vínculo). Por ejemplo, no es recomendable representar como
entidad al sistema mismo sobre el que se hace el diseño, ya que implicaría un conjunto unitario.

Identificación de Datos
Cada representación de una cosa, evento o proceso perteneciente a una entidad, debe ser un elemento
único e identificable de alguna manera: debe haber al menos un atributo o conjunto mínimo2 de ellos que
identifique unívocamente al dato conformando lo que se llama un identificador de la entidad. Para
descubrir un identificador, se toma un dato individual representativo de la misma, y se valida que el valor de
algún atributo o la combinación de valores de un subconjunto mínimo de atributos, no se repita en el
conjunto.
Los identificadores con un único atributo se clasifican como “simples”, y si requieren dos o más atributos,
como “compuestos”. Todo atributo que integre un identificador debe ser obligatorio y monovalente, es
decir, debe tener la cardinalidad por defecto, que es 1.
Una entidad puede tener más de un identificador.
Hay datos que no se pueden identificar mediante un atributo ni un conjunto mínimo de atributos propios,
porque su existencia depende de un dato de otra entidad -la cardinalidad de la entidad a la que pertenece
en la relación con la otra entidad es 1: la identificación de un dato individual es dependiente o relativa a la
identificación del dato de la entidad de la que depende o, en caso de depender de más de una entidad, de
los identificadores de un dato de cada una de dichas entidades. Se denominan identificadores mixtos,
cuando intervienen atributos propios como discriminantes, o externos, cuando intervienen exclusivamente
datos externos a la entidad dependiente. Cuando una entidad tiene un identificador mixto o externo,
además de ser dependiente, se denomina “débil”.
En esta fase de diseño, no deben agregarse identificadores que no sean naturales en el sistema de información.

Identificación de Vínculos entre Datos

Cada vínculo entre datos de una misma entidad (relaciones reflexivas) o entre datos de dos o más entidades
pertenecientes a una relación también debe ser un elemento único e identificable del conjunto.

2 Un conjunto de atributos conforma un identificador si quitando del conjunto a uno cualquiera de los atributos, los
que quedan no permiten identificar a cada dato individual del conjunto.

FIUBA Base de Datos – Curso Servetto Página 2 de 17

 Modelado Conceptual

▪ Los de una relación de uno a uno, se pueden identificar con el identificador de uno cualquiera de los dos
datos vinculados. P. ej., si una empresa provee estacionamiento a sus empleados que tengan auto, un vínculo
entre un empleado y un auto se puede identificar unívocamente tanto por un identificador del empleado
como por un identificador de su auto.

▪ Los de una relación de uno a muchos, se deben identificar con el identificador del dato perteneciente a la
entidad que participa en la relación con cardinalidad máxima 1. P. ej., un vínculo entre un movimiento de una
cuenta bancaria y la cuenta cuyos fondos afectó, suponiendo que los movimientos tienen un identificador
propio, se puede determinar unívocamente por el identificador de movimiento.

▪ Los de una relación de muchos a muchos, se deben identificar con la composición de los identificadores de los
datos vinculados. Debe verificarse que ningún par de datos compuesto por elementos de cada entidad
relacionada se repita en el conjunto de vínculos; si se detecta que esto no sucede, y que para resolver la
redundancia es necesario considerar el valor de algún atributo del vínculo (atributo de relación), entonces los
vínculos no pueden representarse como relación, sino como una entidad débil con identificador mixto.

Los identificadores de relaciones no se denotan en los modelos gráficos, pero para verificar la corrección de las
relaciones es necesario validar que representen vínculos identificables según las cardinalidades de las entidades en
ellas.

Análisis
Cardinalidad de Atributos
Hay atributos que pueden desconocerse al momento de registrar un dato o representar una característica
que un dato particular puede no tener: son denominados atributos opcionales. Los atributos opcionales
tienen cardinalidad mínima 0.
Hay atributos que pueden describirse en términos de una lista de valores del mismo tipo o estructura: son
conocidos como atributos polivalentes. Los atributos polivalentes tienen cardinalidad máxima fija (una
constante) o indeterminada (*).
Como la cardinalidad más común de los atributos es 1, es decir, la mayoría de los atributos son obligatorios y
monovalentes, ésta se asume por defecto sin necesidad de denotarla.

Cardinalidad de Entidades en Relaciones

La cardinalidad de una entidad en una relación con otra (entre datos de dos entidades) se determina
considerando un dato individual representativo de una entidad, y analizando con cuántos datos de la otra entidad
relacionada se puede vincular al menos (cardinalidad mínima) y a lo sumo (cardinalidad máxima). Si en la relación
participan más de dos entidades, se analiza, para combinaciones al azar de datos del resto de las entidades
relacionadas, con cuántos datos de cada entidad se puede vincular.
Cuando la cardinalidad máxima de una o más entidades en una relación con otra es indeterminada, se denota con
un asterisco. La convención de representación de cardinalidades o multiplicidades en los modelos de clases de
UML es:
Cardinalidad Representación
Ninguno o uno 0..1
Uno y sólo uno 1
Ninguno o muchos *
Uno o muchos 1..*
Al menos x, con x constante x..*
A lo sumo y, con y constante 0..y o 1..y según corresponda
Exactamente z, con z constante z

FIUBA Base de Datos – Curso Servetto Página 3 de 17

 Modelado Conceptual

La cardinalidad de una entidad en una relación consigo misma, esto es, en una relación reflexiva, debe estar
precedida por el nombre del rol del dato de la entidad que se vincula con otro u otros de la misma, p. e., si una
entidad con datos de personas se relaciona consigo misma para representar vínculos progenitor-hijo, como
cualquier persona puede vincularse con ninguna o muchas si se la considera progenitor, o con ninguna o hasta
dos si se la considera hijo (puede que ningún progenitor se encuentre en el conjunto), las cardinalidades han de
denotarse hijo 0..* y padre 0..2.
Se debe tener cuidado en la determinación de la cardinalidad mínima, ya que para ésta se debe contemplar la
dinámica operacional sobre los datos: fijar una cardinalidad mínima 1 implica la obligatoriedad de que en una
misma operación sobre el sistema se deba registrar un nuevo dato de la entidad, así como también vincularlo a
otro de la entidad relacionada.
La cardinalidad 1 se aplica a los datos que dependen de otro de la entidad relacionada: la entidad que participa de
una relación con esta cardinalidad se denomina “dependiente” de la otra relacionada. Hay casos en los que una
entidad puede depender de más de una entidad.
Las relaciones de dependencia se dan usualmente entre entidades maestras, para representar cosas compuestas
(p. ej., para un sistema de venta de localidades numeradas para funciones teatrales, cada sala teatral se
compondrá de secciones, cada sección de filas, y cada fila de butacas o localidades numeradas dentro de la fila,
ésta a su vez numerada dentro de la sección, y ésta a su vez numerada o designada dentro de cada sala), o entre
entidades maestras y transaccionales, ya que éstas últimas representan eventos o procesos asociados a cosas
(entidades maestras) del sistema de información (p. ej., ventas de productos o servicios, con registro cronológico,
o pedidos a proveedores, con registro de estados cronológicos).

Generalización / Especialización
Una vez definidas varias entidades, puede detectarse que dos o más de ellas tienen atributos o relaciones en
común: se pueden definir una entidad general que reúna los atributos o relaciones comunes, aplicando el
principio de generalización.
Una vez definida una entidad, se puede detectar distintos subconjuntos de atributos opcionales o distintas
relaciones con cardinalidad mínima 0, que representan subconjuntos de datos dentro de la misma entidad:
se puede clasificar los atributos o relaciones opcionales y definir subentidades que los reúnan
obligatoriamente, aplicando el principio de especialización.
Las jerarquías de entidades obtenidas aplicando generalización o especialización tienen la propiedad de
cobertura, que indica cuántos de los datos de la entidad general se pueden encontrar en las subentidades, y
si las subentidades representan subconjuntos disjuntos o superpuestos de la entidad general: el primer
componente de cobertura es T (total) o P (parcial), y el segundo E (exclusiva) o S (superpuesta). La
determinación se efectúa considerando un dato de la entidad general y analizando si puede o no estar en
alguna subentidad, para el primer componente, y si puede estar en a lo sumo una única subentidad o en más
de una, para el segundo.
Una entidad puede tener un único subconjunto de especialización, en cuyo caso la cobertura es, por defecto,
(P, E).
Una misma entidad puede tener más de una especialización en subconjuntos, por criterios independientes.
Por ejemplo, si se consideran operaciones en cuentas bancarias, se pueden especializar según el tipo de
débito o crédito (en efectivo, por cheque, transferencia, pago de servicio, débito automático de servicio) e,
independientemente, según el medio por el que se efectuaron (por cajero automático, por caja o por home
banking).
Las jerarquías de entidades representan abstracciones de herencia: si se considera un dato en una entidad
especializada, se asume que hereda los identificadores, atributos, vínculos con datos de entidades
relacionadas y posible pertenencia a subentidades especializadas de otras jerarquías de la entidad general
(herencia descendente); y si se considera un dato en una entidad general, se asume que hereda
opcionalmente los atributo y vínculos con datos de entidades relacionadas (con cardinalidad mínima 0) y

FIUBA Base de Datos – Curso Servetto Página 4 de 17

 Modelado Conceptual

pertenencia a subentidades especializadas (con cobertura parcial) de todas sus subentidades especializadas
(herencia ascendente). En la herencia ascendente, los identificadores de entidades especializadas dejan de
serlo para la entidad general.
Si en un diagrama de entidades y relaciones se persigue la máxima expresividad, es lícito modelar
subentidades que no tengan ni atributos ni relaciones propias: siempre son preferibles las jerarquías con
cobertura (T, E), y como estas son las más comunes y frecuentes, si no se denota una cobertura, se asume por
defecto que es (T, E). Sin embargo, si se detecta que un dato de un subconjunto puede, con el tiempo,
cambiar a otro, entonces la especialización no es pertinente (no se puede especializar procesos según
estados).

Ejemplos
Se usan estereotipos para subclasificar entidades según sean Cosas, Eventos, Procesos o Atributos, para mayor
claridad.

Los atributos con restricción {unique} son identificadores simples internos.

Los atributos con restricción {id} son componentes de un único identificador interno compuesto.

Para poder representar identificadores externos o mixtos, se define un estereotipo de asociación <<Id>>, para
indicar que el identificador de una entidad débil se compone de un identificador de la entidad de la que depende.

Entidad fuerte
La entidad Persona es fuerte
porque tiene un identificador
interno, en este caso simple y
constituido por el atributo dni.

Entidad Débil
La entidad Reserva (p.e. de un
salón de fiestas) es débil porque
no tiene identificador interno.
Una reserva en particular se
identifica a partir del cliente que
la efectúa más la fecha y hora de
inicio: cliente, fecha, horaInicio.

Relación Uno a Uno

Un empleado puede tener
asignada una cochera para
estacionar su auto. Un auto con
cochera asignada corresponde a
un único empleado.

Relación de Uno a Muchos

Una empresa puede tener
ninguno o muchos empleados
registrados. Un empleado tiene a
una única empresa como
empleador.

Relación de Muchos a Muchos

Una película puede tener ninguno
o muchos actores intérpretes
registrados. Un actor registrado
puede estar relacionado a la
interpretación de ninguna o
muchas películas.

FIUBA Base de Datos – Curso Servetto Página 5 de 17

 Modelado Conceptual

Atributos Opcionales,
Multivaluados y Compuestos
Un docente debe tener registrada
al menos una dirección
electrónica, y puede tener
registrado o no un número de
celular; además, debe tener
registrado un domicilio.
Un domicilio se identifica a por el
docente al que pertenece.

Relación Recursiva
Un empleado puede no tener
supervisados o tener muchos.
Un empleado puede no tener
supervisor o tener uno solo.

Relaciones con Atributos

El vínculo entre una factura y un
producto tiene como atributos la
cantidad y el precio de venta
unitario del producto en la venta
que representa la factura.

Relación Ternaria
Un vínculo de venta de un
servicio a un consumidor tiene
como atributos la fecha en que se
presta el servicio y el precio del
servicio en la fecha de venta.
A un consumidor cualquiera, un
servicio cualquiera puede no
habérsele vendido nunca o
habérsele vendido muchas veces.
En una venta tomada al azar, a un
consumidor también considerado
al azar, puede no habérsele
vendido ningún servicio o
habérsele vendido muchos.
Considerados un servicio y una
venta cualesquiera, tomados
como representantes de sus
respectivos conjuntos, puede que
no se halle ningún vínculo entre
ellos o a lo sumo uno.

FIUBA Base de Datos – Curso Servetto Página 6 de 17

 Modelado Conceptual

Jerarquía de Generalización o
Especialización
Una persona, puede ser de tipos
física o jurídica.
Toda persona es física o jurídica
(cobertura total).
Ninguna persona puede ser física
y jurídica (subconjuntos
exclusivos).

Modelado Conceptual
El modelado conceptual de datos para un sistema, como todo problema de ingeniería, implica una resolución
sistemática, disciplinada y cuantificable. Entonces, para que el modelado conceptual sea sistemático se debe
respetar un proceso; para que sea disciplinado, en dicho proceso deben utilizarse instrumentos (lenguajes de
modelado) y obtener productos (diagramas) con las reglas de la disciplina (la Informática), y para que sea
cuantificable se deben usar métricas, también definidas en la disciplina, para evaluar la calidad o complejidad de
los productos obtenidos.

El Proceso de Modelado Conceptual

El modelado conceptual es un proceso evolutivo incremental, en el que se va resolviendo la complejidad
mediante refinamientos sucesivos y modularización.

Refinamientos Sucesivos
Se recomienda seguir los siguientes pasos de refinamiento en forma evolutiva:
1. Individualizar y representar entidades y relaciones, determinando cardinalidades de las entidades en las
relaciones, subconjuntos de especialización que resulten evidentes, y coberturas de jerarquías.

2. Representar atributos que formen parte de identificadores, y verificar:

▪ Que toda entidad tenga al menos un identificador, y que los subconjuntos de especialización hereden
adecuadamente identificadores más allá de que puedan tener uno o más propios.

▪ La consistencia de las cardinalidades de las entidades en las relaciones, cuidando que los vínculos que
representen las relaciones se puedan identificar exclusivamente a partir de identificadores de las
entidades.

3. Determinar los restantes atributos característicos de las entidades y de las relaciones que los requieran,
denotando cardinalidades especiales, y analizar también

▪ Si se detectan más identificadores (para completar el modelo).

▪ Si se detectan más generalizaciones o especializaciones a partir del análisis de:

∙ Atributos comunes en distintas entidades (para generalizar) o de atributos opcionales en una misma
entidad (para especializar).

∙ Entidades con más de una relación con cardinalidad mínima 0 (para especializar).

FIUBA Base de Datos – Curso Servetto Página 7 de 17

 Modelado Conceptual

▪ Si se puede agrupar atributos en atributos compuestos, si un subconjunto de atributos de una entidad

representa una misma característica o propiedad (mejorar expresividad).

4. Evaluar la completitud y consistencia del diagrama obtenido:

▪ Verificar que todas las entidades tengan al menos un identificador, aunque sea heredado, y que tengan
todos los identificadores posibles.

▪ Verificar que todas las entidades tengan denotada la cardinalidad en cada relación que participen.

▪ Detectar y eliminar entidades colgantes: con sólo un atributo identificador y con una única relación con
otra entidad.

▪ Detectar y corregir redundancias: ninguna entidad puede tener como componentes atributos que sean
propios de otra entidad existente en el modelo; esto sólo puede representarse mediante una relación
con la otra entidad. Los únicos casos que no implican redundancia o que implican redundancia
justificada son:

∙ La copia de atributos de una entidad maestra a una relación transaccional o transacción

dependiente de la misma (por ejemplo, el precio de productos o servicios: no hay redundancia
porque el precio de un producto o servicio puede cambiar con el tiempo, pero el precio al que se
vendió en una transacción no).

∙ Los atributos derivados (por ejemplo, el total de una factura de venta: hay redundancia porque el
precio puede obtenerse a partir de cantidades y precios de venta copiados al momento de facturar,
pero puede justificarse si hay consultas frecuentes del total de facturas –redundancia justificada).

▪ Verificar que los subconjuntos de especialización de una jerarquía sean todos correspondientes a
entidades del mismo tipo (todas deben representar conjuntos de cosas o conjuntos de eventos) y que no
representen procesos en distinto estado (ya que esto significaría cambiar a un dato de conjunto cada vez
que cambie su estado, y es funcionalmente ineficiente).

▪ Detectar y eliminar ciclos redundantes (entidades relacionadas conformando un ciclo tal que, por las
cardinalidades de las relaciones, a partir de un dato de cualquiera de ellas se puede obtener el mismo
dato transitivamente por las relaciones) quitándoles alguna relación.

▪ Para cada consulta u operación frecuente, listar entidades y relaciones involucradas en el orden en que
deban recorrerse para resolverla, y constatar la consistencia del recorrido: que exista una relación,
aunque sea transitiva, entre las entidades que se recorran y que las cardinalidades permitan obtener el
resultado que se espera.

Modularización
Cuando se enfrenta un sistema de información de gran complejidad, es decir, con gran número de entidades y
relaciones, su abordaje suele efectuarse por divisiones propias del sistema o unidades de gestión, p. ej., una
empresa puede estar organizada en departamentos o gerencias. Entonces el problema de modelar los datos de la
empresa se descompone en el modelado de datos de cada departamento o gerencia, y si un departamento o
gerencia resulta muy complejo por la cantidad de funciones u objetivos, se puede descomponer el problema de
su modelado en el modelado de los datos involucrados en distintas funciones u objetivos. Como el resultado de
esta descomposición será un conjunto de diagramas, posiblemente realizados por distintas personas, que pueden
tener entidades y relaciones comunes (acoplamiento), se requiere un trabajo de integración consistente en:

▪ Detectar entidades sinónimas (con distinto nombre en distintos diagramas pero que representan al mismo
conjunto de datos), y reducirlas a una única entidad con la unión de atributos (también con reducción de
sinónimos), que servirá de acoplamiento entre los distintos diagramas que la compartan.

FIUBA Base de Datos – Curso Servetto Página 8 de 17

 Modelado Conceptual

▪ Detectar relaciones sinónimas y también reducirlas.

▪ Detectar entidades homónimas (con el mismo nombre en distintos diagramas pero que representan distintos
conjuntos de datos) y renombrar las necesarias para resolver el conflicto. Hacer lo mismo para relaciones
homónimas.
El tamaño óptimo de modelos o diagramas se alcanza cuando pueden distinguirse con claridad en una hoja de
papel (alrededor de seis entidades).

El Producto del Modelado Conceptual

Diagramas
Existen diferentes versiones del lenguaje gráfico para modelar entidades y relaciones, que se diferencian,
fundamentalmente, en las convenciones para representar relaciones, cardinalidades de entidades en relaciones, y
atributos. Se recomienda el uso del lenguaje UML para modelar entidades con clases de ese estereotipo (entity
classes).

Cualidades
Los diagramas de entidades y relaciones producto del modelado conceptual involucran un proceso que además
de sistemático y disciplinado, es esencialmente creativo, por lo que dependen en gran medida de la subjetividad y
estilo de quien modela y de las cualidades que busque para sus diagramas: se puede buscar simplicidad, para una
comprensión inmediata de la estructura estática de un sistema, o se puede buscar expresividad, para representar
en detalle propiedades y restricciones de los datos. Estas dos cualidades son incompatibles, ya que los modelos
simples implican pasar a la especificación funcional del sistema las propiedades y restricciones no contempladas
en el modelo estático, y los modelos muy expresivos, requerirán menos especificaciones funcionales, pero
requerirán más esfuerzo de análisis para comprender la estructura estática de un sistema y distinguir entidades y
relaciones importantes de otras que no lo sean.

Una cualidad siempre asequible para todo diagrama es la claridad, y para obtener diagramas claros se debe
cuidar la disposición espacial de entidades y relaciones de manera que no se crucen líneas de relación y que las
entidades que se relacionen se encuentren lo más próximas que sea posible en el diagrama; para esto, es posible
que en el paso 1 o 2 del proceso de modelado, cuando la reproducción de diagramas no resulta demasiado
costosa, sea necesario repetir intentos cambiando la disposición de las entidades. Asimismo, para obtener
diagramas con esta cualidad también es necesario seguir criterios uniformes para nombrar entidades y relaciones.

Métricas
Las métricas de calidad implican la determinación de pesos de entidades, en función de atributos, relaciones y
participación en jerarquías, y de pesos de relaciones, en función de atributos y cardinalidades de entidades
participantes. Su objetivo es evaluar diagramas en busca de entidades y relaciones con pesos alejados del
promedio y revisar su pertinencia (si se pueden fusionar o partir entidades o remodelar relaciones para
homogeneizar pesos). También se puede calcular pesos de diagramas para revisar su homogeneidad.

Las métricas de complejidad implican sumas ponderadas de pesos de entidades y relaciones de un modelo
completo (o de sus diagramas) con el objeto de graduar el esfuerzo requerido para un modelo o asignarle valor
económico.

FIUBA Base de Datos – Curso Servetto Página 9 de 17

 Modelado Conceptual

Convenciones para la Designación de Entidades, Relaciones y

Atributos
A efectos de obtener diagramas con mayor claridad y facilitar la comprensión de estos, conviene adoptar criterios
comunes para nombrar entidades y relaciones. Los criterios recomendados son:

▪ Usar sustantivos con mayúscula inicial para nombrar entidades, siempre con el mismo número (siempre en
singular o siempre en plural). Si se requiriera más de una palabra para nombrar a una entidad, se puede usar
siglas (letras iniciales de las palabras) o acrónimos3, p. ej., PA para Persona Autorizada o PPAA si se usan
nombres en plural (siglas), o PersAut (acrónimo). Los nombres de entidades deben ser únicos en cada
modelo, aun cuando éste consistiere de varios diagramas.
▪ En UML, pueden nombrarse las relaciones o asociaciones con mayúscula inicial, o bien usar nombres de rol
con minúscula inicial (que por defecto puede ser igual al de la entidad relacionada) en uno o ambos extremos
de la relación, según las necesidades de acceso a los datos.

Los nombres de relaciones deben ser únicos en cada modelo, aun cuando éste consistiere de varios
diagramas.

▪ Usar nombres o acrónimos en minúsculas para nombrar atributos. Puede haber atributos homónimos en un
mismo diagrama o modelo, siempre que no pertenezcan a una misma entidad o relación.

Caso de Estudio
Una concesionaria de automóviles vende unidades 0Km de una única marca. Un automóvil tipo de la marca se
distingue por su modelo, caracterizado por un nombre único y un año de salida, por una terminación,
caracterizada también por un nombre único y cantidad de puertas, y por una motorización, que se distingue
según el combustible, la cilindrada y la transmisión, por el precio de lista y por varios colores opcionales. Distintos
autos tipo pueden tener igual modelo, o igual terminación o igual motorización. La concesionaria tiene en
exhibición o en depósito unidades de autos tipo que se identifican tanto por su número de chasis como por su
número de motor, y se caracterizan además por su color, fecha de ingreso y su disponibilidad para la venta.
Las ventas se inician una fecha determinada con el encargo de un auto tipo de determinado color por parte de un
cliente, quien debe pagar un adelanto, del cual se registra su monto, forma de pago, descripción y número de
recibo entregado al cliente. De las ventas debe registrarse también monto total, el saldo a cobrar, el empleado
responsable, y la unidad que se vende, que si estuviera en depósito o exhibición se asociaría inmediatamente a la
venta y se marcaría como vendido, o de lo contrario se registraría un número de orden a fábrica, y cuando se
recibiese, se registraría su ingreso y se asociaría a la venta.
Las ventas se concretan cuando el cliente cubre el saldo a pagar, por lo que se registra un número de factura. El
saldo se puede cobrar con uno o más pagos de los que se registra su fecha, monto, forma, descripción, y número
de recibo que los identifica. Una forma de pago puede implicar la entrega de un vehículo usado, en cuyo caso
debe registrarse su marca, modelo, tipo, patente y año de patentamiento. Tanto de empleados como de clientes
se registran datos personales e información de contacto, y de empleados en particular, la fecha de ingreso y una
fecha y motivo de baja opcionales.

3 Vocablo formado por la unión de elementos de dos o más palabras: el principio de la primera y el principio de la
última, p. ej., LiqSue para liquidaciones de sueldos, u otras combinaciones, p. ej., FacCltes para facturas de clientes.

FIUBA Base de Datos – Curso Servetto Página 10 de 17

 Modelado Conceptual

Primera Aproximación
Representación inicial de entidades y relaciones, estereotipando las entidades para la mejor comprensión del
modelo, sin tener en cuenta atributos, y asignando cardinalidades a las relaciones.

FIUBA Base de Datos – Curso Servetto Página 11 de 17

 Modelado Conceptual

Refinamiento
En principio, sólo se definen atributos que contribuyan a la identificación de entidades; luego, validando las
relaciones de manera que los vínculos que contengan se puedan identificar a partir de los datos vinculados, y
aplicando generalización cuando sea posible; y finalmente, agregando el resto de los atributos.

El atributo saldo de Venta es derivado porque el saldo que se registra inicialmente es el monto de la venta menos
el monto del pago inicial; luego, por cada pago posterior se descuenta su monto del saldo.

FIUBA Base de Datos – Curso Servetto Página 12 de 17

 Modelado Conceptual

La baja de un empleado se podría modelar como un atributo.

El atributo disponib de Unidad se modela como derivado porque se considera que una unidad en exhibición o en
depósito está “disponible”, pero cuando se asocia a una venta se cambia su estado a “no disponible”: la
disponibilidad se puede determinar verificando si tiene una venta asociada. Podría considerarse como atributo
normal si se pensara que sus valores pudieran ser “exhibición”, “depósito” o “vendida”, como se muestra en el
siguiente diagrama, equivalente al anterior.

Problemas
Se debe modelar cada problema con uno o más diagramas de clases entidad (modelos de dominio).
Para cada problema, se deben proponer y discutir con el profesor o auxiliares operaciones y consultas adicionales
a las que se sugieran o expliciten, para determinar direcciones de navegación en los diagramas, así como la
frecuencia estimada de cada una, para optimizar diseños.
Como se trata de problemas, no de ejercicios, la determinación de atributos e identificadores puede no surgir
completa o naturalmente de las especificaciones. Se debe consultar con el profesor o auxiliares el añadido de
atributos que no se expliciten, más aún si resultaren identificadores.
1. Negocio de indumentaria deportiva con varias sucursales
a. Gerencia comercial
Un usuario de gestión comercial debe monitorear las tendencias de ventas por marca, categoría de
artículo y artículos por talles en general y en cada sucursal, así como la cantidad de cada talle de artículo
disponible para la venta en cada sucursal. También se encarga de establecer los precios de venta de los
artículos, que pueden variar por talles, así como de establecer descuentos promocionales para categorías
de artículos y/o marcas y/o artículos para períodos de fechas especiales o finales de temporada.

FIUBA Base de Datos – Curso Servetto Página 13 de 17

 Modelado Conceptual

Para cada artículo se registra el año de origen, temporada o temporadas de uso (otoño e invierno,
invierno, primavera y verano, verano, todo el año) y una graduación del período de vigencia (corto -una
temporada-, medio -dos o tres temporadas-, indefinido). Esta información sirve para definir promociones
especiales de mesa de saldos, así como marcar artículos como discontinuados.
Asimismo, un usuario con este perfil puede generar órdenes de compra con especificaciones de
cantidades parciales a entregar en cada sucursal de cada artículo que se compra.
b. Compras
Un usuario con perfil de compras lleva registro de proveedores y gestiona las órdenes de compra de la
gerencia comercial mediante pedidos a los mismos. También registra los artículos remitidos a cada
sucursal. Una orden de compra puede implicar uno o más pedidos al mismo o distintos proveedores, y un
pedido a un proveedor, uno o más remitos. Como puede haber diferencias entre lo pedido y lo remitido,
ya sea en cantidades solicitadas versus enviadas, como por la no remisión de algún artículo, éstas deben
poder consultarse.
c. Ventas
Un usuario con perfil de ventas se encarga de facturar las ventas de artículos, con actualización de
cantidades en existencia de talles de artículos en la sucursal correspondiente. También registra la
información pertinente según el tipo de pago: para pagos con tarjetas, DNI y apellido y nombre del
comprador, y para tarjetas de crédito en particular, la cantidad de cuotas, y tasa de interés, si es que la
tiene. Si el pago es con cheque, se registra la información correspondiente al mismo. Puede haber pagos
fraccionados para una misma compra, es decir, combinando medios de pago (efectivo con uno o más
cheques, o cheque/s más tarjeta de débito o crédito, etc.).
2. Departamentos de la FIUBA
Los departamentos de la FIUBA se ocupan de la gestión de la actividad académica de grado. Sus laboratorios
llevan a cabo actividades complementarias a la enseñanza de grado en su vinculación con la investigación
científica. En paralelo, son los responsables de impulsar transferencia tecnológica al sector público-privado.
Se requiere modelar los datos inherentes a la gestión de departamentos, para un sistema web con alcance
para toda la facultad.
Para la gestión académica de grado se requiere el registro de carreras, áreas de docencia, asignaturas, cursos
de asignaturas, docentes, cargos docentes, desempeño de docentes por cargo, designaciones de docentes en
un cargo, asignaciones de docentes por desempeño de cargo, tanto a cursos, para cargos de cualquier
dedicación, como a laboratorios, para cargos con dedicación semiexclusiva o exclusiva. También se debe
registrar las clases de cada curso para cada cuatrimestre de cada año.
Los docentes se identifican por su CUIL, y una vez designados en algún cargo, por un número de legajo
docente. Además de sus datos personales (nombres, apellido/s, fecha de nacimiento, domicilio -calle,
ubicación, localidad y número de teléfono fijo-, celular, cuentas de correo electrónico), cuentan con una fecha
relativa de ingreso a la docencia, que determina su antigüedad.
Los cargos docentes se caracterizan por una jerarquía (profesor titular, profesor asociado, profesor adjunto,
jefe de trabajos prácticos, ayudante primero o ayudante segundo) y una dedicación (exclusiva, semiexclusiva
o parcial).
Un docente puede desempeñar un mismo cargo en virtud de una o más designaciones consecutivas, que se
caracterizan por un número de expediente, tipo y número de resolución, fecha de la resolución, un carácter
de la designación (regular -por concurso- o interina), remuneración del desempeño (rentado o ad-honorem),

FIUBA Base de Datos – Curso Servetto Página 14 de 17

 Modelado Conceptual

fecha de inicio de funciones, fecha de fin de funciones, área de docencia, y, si fuera con dedicación
semiexclusiva o exclusiva, un área de investigación. Las designaciones de un docente también pueden tener
una fecha y motivo de baja, para casos de renuncias o fallecimientos, y pueden ser para un cargo de la
jerarquía inmediata inferior, pero para cumplir funciones en el cargo con la jerarquía correspondiente. Una
misma resolución puede designar a muchos docentes en distintos cargos.
Un docente puede desempeñar simultáneamente más de un cargo con la misma jerarquía y dedicación; en
este caso, cada desempeño se distinguiría por la fecha de inicio de funciones de la primera designación;
también puede desempeñar simultáneamente cargos con distintas jerarquías o dedicaciones.
Un desempeño también se puede registrar en virtud de una solicitud de designación, en cuyo caso, la única
información común con una designación efectiva sería el número de expediente por el que se tramita o
solicita la designación.
Por cada desempeño de un cargo, un docente puede tener una o más asignaciones consecutivas a cursos
(historial), y en caso de dedicaciones semiexclusiva y exclusiva, puede tener dos o más asignaciones
simultáneas. Las asignaciones se caracterizan por fecha de inicio, y, opcionalmente, por fecha y motivo de
cese. Hay casos especiales de asignaturas que difieren en su código, pero sus cursos y clases son coincidentes;
en estos casos se debe registrar esta circunstancia, y puede resultar que un docente que desempeñe un cargo
con dedicación parcial tenga más de una asignación por tratarse de asignaturas unificadas.
Un docente también puede tener licencias, que se caracterizan por su tipo (con o sin goce de haberes) una
fecha de inicio, un motivo, y una fecha opcional de finalización. Las licencias por enfermedad afectan todos
los desempeños del docente, pero puede haber licencias específicas para un cargo en particular (cuando son
sin goce de haberes por motivos particulares o por desempeño de cargo de mayor jerarquía).
Los cursos de una asignatura se caracterizan por un número de orden relativo a la asignatura, y por la
indicación de si se dictan en los dos cuatrimestres o en uno de cada año en particular, así como el historial de
asignaciones docentes. Las clases de cada curso se registran para cada cuatrimestre de cada año que se dicte,
con detalle de tipo (teórica, práctica, teórico-práctica, de laboratorio, de consulta) carácter (obligatoria o no),
aula, hora de comienzo y hora de finalización. Para la planificación de clases de un cuatrimestre, se debe
poder replicar las mismas del cuatrimestre anterior para cursos que se dicten en los dos cuatrimestres, o las
mismas del mismo cuatrimestre del año previo, para los que se dicten un solo cuatrimestre por año.
Como las designaciones interinas suelen ser por el término de doce meses, a partir del 1° de febrero de cada
año, cada departamento debe solicitar la renovación de designaciones interinas para el año siguiente antes
de terminar cada año.
3. Una empresa de transporte de pasajeros requiere un sistema para la venta de pasajes. La compañía tiene
rutas de media y larga distancia, de las cuales sólo se registra un nombre único. Para cada ruta la compañía
ofrece servicios que se individualizan por la cantidad de paradas en terminales (expresos o locales) y por el
modelo de coche que se usa para el servicio.
De los modelos de coches sólo se registra un nombre único, y para cada modelo, cada uno de sus asientos
con número y tipo (semicama, cama o ejecutivo), ya que un mismo modelo de coche puede tener asientos de
distinto tipo.
Para cada servicio de una ruta, los precios de pasajes se establecen y registran según la terminal de origen y la
de destino dentro de la ruta y el tipo de asiento. Además, por cada servicio se debe registrar la programación
de prestaciones por días de semana y horas de salida y de llegada, según corresponda, para cada terminal de
la ruta, así como el número de parada que corresponde a la terminal. Las terminales se identifican por

FIUBA Base de Datos – Curso Servetto Página 15 de 17

 Modelado Conceptual

nombre, localidad y provincia en la que se encuentran, y se caracterizan además por su dirección y número
de teléfono.
Para la venta de pasajes con origen y destino en cualesquiera de las terminales de las rutas de la compañía, se
debe informar las prestaciones de servicios, fechas y horarios de salida de la terminal de origen y de llegada a
la de destino y asientos disponibles para el trayecto entre ambas terminales, por lo que para cada prestación
de servicio se necesita registrar la fecha y hora de salida de la terminar de origen, y para cada terminal de
salida, los asientos libres para el modelo de coche correspondiente al servicio.
Para la venta de pasajes debe registrarse dni, apellido y nombre del pasajero y el asiento que ocupa al salir de
cada terminal (inicial e intermedia de la ruta) para la prestación del servicio que compró el pasaje. Los pasajes
se identifican con un número único.
Las consultas más frecuentes para este sistema serían:
a. Dadas las localidades y provincias de origen y destino, buscar información sobre las prestaciones de
servicios, fechas y horarios de salida de la terminal de origen y de llegada a la de destino, incluyendo
precios por tipo de asiento e información de la terminal de destino.
b. Dadas las terminales de origen y destino, un tipo de asiento y fecha y hora de prestación de un servicio,
buscar información sobre los asientos libres en la terminal de origen y en las intermedias.
4. Un taller de mecánica automotor requiere un sistema para administrar y facturar sus servicios, que pueden
ser de urgencia o programados por turnos, y que en ambos casos se gestionan mediante órdenes de trabajo.
Se debe llevar registro de clientes, que pueden ser personas o empresas. De las personas debe registrarse
CUIToL, apellido y nombre, domicilio, teléfonos y tipo de contribuyente; de las empresas CUIT, nombre,
domicilio y teléfonos.
Asimismo, se debe llevar registro de los automotores que se reparan, indicando dominio (patente), marca,
modelo, tipo y año de fabricación.
Una OT (orden de trabajo) se caracteriza por la fecha y hora de solicitud, el automotor, el cliente, la
descripción del problema, la fecha y hora de finalización del servicio, la fecha y hora de retiro del automotor
por parte del cliente y el estado de la orden (sin atención, en elaboración de presupuesto, en espera de
aceptación de presupuesto, en espera de repuesto, en progreso, cancelada, liquidada y completada).
Además, si la orden es programada, la fecha y hora del turno para ingresar el vehículo al taller, y si es de
urgencia, la fecha y hora de ingreso del vehículo al taller.
Para cada orden se debe registrar también los servicios de mano de obra efectuados con sus montos, así
como los repuestos que se emplearon con sus descripciones y montos y, en caso de que se compraren
especialmente para la reparación, cuit y número de factura del proveedor. A efectos de registrar servicios de
mano de obra y repuestos comunes, éstos deben estar codificados con sus descripciones y precios actuales.
Las consultas más frecuentes para este sistema serían:
a. Dada una fecha y una hora, reportar la cantidad de turnos dados con fecha y hora iguales o mayores.
b. Dada una fecha, buscar información de clientes con órdenes de trabajo liquidadas.
c. Dado un cliente, buscar información sobre las órdenes de trabajo no completadas que le correspondan,
incluyendo los servicios de mano de obra y los repuestos que tuviere asignados con sus respectivos
montos.
d. Dada una orden de trabajo, buscar información sobre el cliente a quien le corresponde.

FIUBA Base de Datos – Curso Servetto Página 16 de 17

 Modelado Conceptual

e. Dada una orden de trabajo, calcular el monto de liquidación de la misma.

5. Una agencia de viajes especializada en turismo aventura ofrece expediciones. Las expediciones se
caracterizan por un nombre que las identifica, descripción, la temporada en la que se programan (estival,
invernal o todo el año), la duración en días, el tipo (travesía, ascenso, multiaventura o cabalgata), un cupo
mínimo de reservas para su realización y otro máximo, el nivel de dificultad (básica, intermedia, exigente o
muy exigente), y el precio actual por persona. También se debe registrar qué servicios incluye y excluye cada
expedición (por ejemplo, pasajes en ómnibus o aéreos, noches adicionales de alojamiento, etc.). Además, se
registra información sobre los elementos indispensables para las expediciones (bolsa de dormir, aislantes,
mochila, polainas, protector solar, etc.), algunos de los cuales la agencia ofrece la opción de alquilar. De los
elementos se registra el nombre y, si es alquilable, el precio actual de alquiler por día. De los servicios se
registra un nombre que los identifica.
De las expediciones que ofrece la agencia, algunas son de organización propia, y otras de agencias asociadas.
De las expediciones externas se registra el nombre, CUIT, dirección, teléfonos y cuentas bancarias para
transferencia de pagos (tipo de cuenta y CBU -Código Bancario Unificado- de cada una de ellas). Toda
expedición externa, es organizada por una única agencia asociada, y una agencia asociada puede ser
responsable de varias expediciones ofrecidas.
La agencia almacena información sobre las salidas que ofrece para las expediciones. Para cada salida de una
expedición se registra: la fecha posible de salida y los paquetes reservados y vendidos para esa salida. De
cada paquete se almacena el número de factura de la seña para su reserva, que lo identifica, el monto de la
seña, la fecha de reserva, el monto total a cobrar y los datos personales de cada uno de los clientes que
realizará la salida (dni, nombre completo, fecha de nacimiento). Y si el cliente es responsable de la reserva se
almacena además domicilio, teléfono y dirección electrónica. Al momento de completarse el cobro de un
paquete reservado, se debe registrar el número de factura por el saldo del paquete y la fecha del pago.
La compra de un paquete puede incluir adicionalmente alquiler de elementos. Para cada tipo de elemento
alquilado se debe registrar la cantidad de elementos alquilados, por cuantos días se alquila y el precio de
alquiler de cada elemento por día.
Las consultas más frecuentes para este sistema serían:
a. Dado un tipo de expedición y una fecha, buscar información sobre expediciones y salidas a partir de esa
fecha.
b. Dada una expedición, buscar información sobre responsables de reserva que hayan comprado paquetes
para expediciones de ese tipo y que no hayan comprado paquetes para salidas de esa expedición.
c. Dado un nivel de dificultad y una fecha, buscar información sobre expediciones y salidas a partir de esa
fecha.
d. Dada una expedición, buscar información sobre responsables de reserva que hayan comprado paquetes
para expediciones con el mismo nivel de dificultad de la expedición pero que no hayan comprado
paquetes para salidas de la misma.
e. Dada una expedición y una fecha de salida, contar la cantidad de personas involucradas en paquetes
reservados para esa salida.
f. Dada una expedición y una fecha de salida, buscar información de personas involucradas en paquetes
para esa salida.
g. Dada una expedición y una fecha de salida, buscar información sobre responsables de reserva que aún no
hayan pagado los paquetes.

FIUBA Base de Datos – Curso Servetto Página 17 de 17