II.

MODELAMIENTO
El desarrollo de modelos en Bases de Datos tiene por objetivo representar las estructuras
de los datos en el mundo real, estableciendo las características necesarias de acuerdo al
contexto en que se trabaja.

A través de la historia se han empleado varios tipos de diagramas para representar los
modelos de datos, en lo referente a Bases de Datos Relacionales, durante mucho tiempo
se ha empleado el Modelo Entidad – Relación y más recientemente se ha hecho una
aproximación del Modelo de Clases de UML para realizar el modelamiento de datos. El
siguiente cuadro presenta diferentes notaciones para el modelado de datos.

Figura 5. Comparativo de los elementos en las principales notaciones de modelo de datos .Quintero, Juan B,;
Hernández, Diana M. y Yanza, Andrea. Directrices para la construcción de artefactos de persistencia en el proceso
de desarrollo de Software. En: Revista EIA, Numero 9, Julio 2008. Medellín. Pag. 77-90.

ELEMENTOS DEL MODELO DE DATOS

Un modelo de datos (relacional) se compone básicamente de dos elementos: Uno que

representa las tablas que se implementarán finalmente en la base de datos y que
normalmente se denominan entidades y las relaciones que se establecen entre estas
entidades.

Entidad: Una entidad es la representación de una “cosa” u “objeto” físico o lógico que existe
en el mundo real. Algunas reglas básicas permiten definir si un objeto es una entidad válida
para el modelo:
 • Múltiples ocurrencias: Las entidades deben tener múltiples ocurrencias, si para el
modelo propuesto, solamente existe una ocurrencia de una entidad, debe
examinarse mejor, ya que lo más posible es que no se requiera modelar como
entidad independiente. Se entiende por ocurrencia un caso particular de la entidad,
por ejemplo la UAO es una ocurrencia de la entidad Universidad, Juan Gómez es una
ocurrencia de la entidad Estudiante.
• Múltiples atributos: Toda entidad contendrá atributos o características que la
definen, por ejemplo la entidad persona, puede tener como atributos: nombre,
edad, sexo, teléfono, dirección. Una entidad válida debe contener varios atributos,
si una entidad tiene solamente un atributo es posible que corresponda a otra
entidad.
• Exclusividad de ocurrencias: Las ocurrencias de una entidad deben pertenecer
solamente a ella; en ningún caso, una ocurrencia puede corresponder a dos
entidades. Por ejemplo, si todas las ocurrencias de la entidad Profesor, también son
ocurrencias de la entidad empleado, es muy probable que una de las dos entidades
sobre.
• Exclusividad de atributos: Cada atributo debe ser definido dentro de una entidad, no
es válido que el mismo atributo pertenezca a dos entidades diferentes. Por ejemplo,
si todos los atributos de la entidad programa se repiten en la entidad grupo, es
probable que una de las dos entidades sobra.

Observación: Dos entidades pueden tener atributos con el mismo nombre, siempre
y cuando no hagan referencia a lo mismo. Por ejemplo el empleado tiene código y
el departamento también tiene código; lo cual es válido si el primero se refiere al
código del empleado y el segundo al código del departamento.

Gráficamente las entidades se representan como clases, en las que se incluyen solamente
los atributos. Por convención el nombre de la clase (o entidad) se escribe en singular.

Por ejemplo:
PERSONA ESCENA

Atributos: Un atributo es una característica relevante de una entidad. Cualquier entidad

tiene múltiples atributos, pero es parte de la habilidad del diseñador definir cuáles son
necesarios para la situación que se quiere modelar.
Los atributos que se definan deben tener las siguientes características:
• Simplicidad: Cada atributo debe representar una única característica, no deben existir
atributos compuestos.
• Univaluados: Cada atributo debe tomar un único valor para cada ocurrencia de la
entidad.
• Exclusividad: Cada atributo debe ser exclusivo e independiente de los otros atributos
que se encuentren en la misma o en otra entidad.
• No calculables: Un atributo válido no es calculable a partir de otros atributos de la misma
o de otra entidad, ya que esto generaría redundancia y posible inconsistencia de los
datos.
• Dominio: Cada atributo tiene un dominio particular, es decir, un conjunto de valores que
puede tomar, este conjunto puede ser finito o infinito y enumerable o no enumerable.
• Obligatoriedad: Dependiendo del modelo que se está representando, cada atributo es
obligatorio u opcional. Cuando se declara un atributo obligatorio, implica que para la
creación de la entidad es necesario que se conozca el valor de ese atributo, cuando se
declara un atributo opcional, implica que al momento de la creación de la entidad se
puede tener o no el valor del atributo.

Los atributos se escriben en singular, con un nombre corto que indique con claridad aquella
característica que representan. Para facilitar la implementación posterior de la Base de
Datos, conviene indicar el tipo de dato que se maneja en el atributo (caracter, texto,
numérico, booleano o fecha). Si un atributo es opcional, se puede indicar que su
multiplicidad es de 0 a 1 ([0..1]), entendiendo que puede presentarse 0 ó 1 vez.

Por ejemplo:

PERSONA

nombre: texto
cedula: numerico
direccion: texto [0..1]
telefono: numerico

Relaciones: Las relaciones en un modelo de datos, definen cuales entidades tienen alguna
relación con otra, estas relaciones pueden ser de múltiples tipos y nuevamente, serán
importantes o no, dependiendo de la situación que están representando.

En las bases de datos relacionales, cada relación es realmente una interrelación, es decir
que representa las dos relaciones que existen entre dos entidades (de la entidad A hacia la
entidad B y de la entidad B hacia la entidad A). Si la entidad Persona tiene una relación con
compra, es porque la entidad compra tiene a su vez, una relación con persona.
Cada una de las relaciones tiene algunas características que la definen:

• Nombre: identifica la relación que representa, generalmente es un verbo de una o dos

palabras y debe ser claro, sencillo y representativo (se sugiere evitar verbos genéricos
como tiene o es). El nombre de la relación, otorga mucha claridad al modelo, ya que
entre dos entidades pueden pensarse muchas relaciones y el nombre permite
comprender la relación particular que el modelador está representando.
• Sentido: Debido a que una relación, realmente representa dos relaciones, es
conveniente indicar el sentido en el que se está manejando la relación (de A hacia B o
de B hacia A).
• Cardinalidad: Indica el número de ocurrencias que pueden eventualmente participar en
la relación. Aunque se entiende que en una relación particular participa una ocurrencia
de cada entidad, la Base de Datos va a representar muchas relaciones en el tiempo, por
lo tanto, bajo esta consideración, las cardinalidades pueden ser múltiples (con número
definido de ocurrencias o con número indeterminado de ocurrencias). Bajo este mismo
concepto se puede incluir la obligatoriedad de la relación, de forma que se especifique
si la relación debe ocurrir siempre o no.

Por ejemplo:

El siguiente diagrama indica que existe una relación entre la entidad Persona y la Entidad
escena, pero no indica más características. La relación podría ser: crea, publica, juega,
termina, etc. por ello es importante indicar el nombre de la relación.

PERSONA ESCENA

Nombre: texto
Cedula: numerico Tipo: texto
Direccion: texto [0..1] Nivel: numerico
Telefono: numerico

El nombre de la relación, da mayor información sobre la misma y debería estar acompañado

de la dirección de la misma; en el siguiente caso sería: “Persona crea escena”.

PERSONA ESCENA

crea
Nombre: texto
Cedula: numerico Tipo: texto
Direccion: texto [0..1] Nivel: numerico
Telefono: numerico
Sin embargo, aún faltaría mucha información respecto a la relación: ¿cuántas personas
crean una escena? ¿Cuántas escenas puede crear una persona? ¿Todas las personas deben
crear una escena o pueden existir personas que no creen escenas? ¿Todas las escenas
deben ser creadas por una persona o pueden existir escenas anónimas?

Las respuestas a estas preguntas dependen del contexto de la aplicación, una empresa en
particular puede exigir que toda escena tenga una persona como creador, mientras para
otra empresa, este requisito no es necesario.

A continuación se especifica la cardinalidad de la relación, en este caso se indica que:

• Una persona puede crear de 0 a muchas (*) escenas, es decir que no todas las personas
crean escenas y una misma persona puede crear 1,2, 20, 100 escenas.
• Una escena debe ser creada por 1 y sólo 1 persona. Todas las escenas tendrán un autor
y no más de uno.

PERSONA ESCENA

1 crea 0..*
Nombre: texto
Cedula: numerico Tipo: texto
Direccion: texto [0..1] Nivel: numerico
Telefono: numerico

La cardinalidad de la relación se puede marcar con número exactos o con * para indicar que
son muchos. Por ejemplo:

1 Uno y solo uno

0..1 Cero o uno (equivalente a opcional)
0..* Cero o más
1..2 Uno o dos
2..* 2 o más

Relaciones recursivas
La relación recursiva o auto-asociación, es una forma particular de relación que se puede
hallar en el modelo de datos, como su nombre lo indica se refiere a relaciones de una
entidad consigo misma.
En este caso, debe entenderse que la relación se dará entre dos ocurrencias diferentes de
la entidad (por ejemplo, dos empleados diferentes) y no la ocurrencia consigo misma (el
empleado Pedro Pérez consigo mismo).

Por ejemplo:

En este caso, la relación indica que una página puede enlazar a otra u otras páginas. Se
entiende que una página no enlaza a sí misma sino a otras ocurrencias de la misma entidad.

Supertipos y subtipos
Cuando un grupo de entidades se pueden agrupar en un mismo conjunto y tienen atributos
y/o relaciones comunes, se puede emplear un esquema de Supertipo y Subtipo, donde el
Supertipo corresponde a la entidad que agrupa y en ella se incluyen los atributos y
relaciones que sean comunes a todas las entidades subtipo, estas últimas incluirán
solamente aquellos atributos o relaciones que le sean propios. Los subtipos que se incluyan
deben ser mutuamente excluyentes.

Los supertipos y subtipos se representan mediante relaciones de herencia entre las clases
involucradas. Tal como sucede en este tipo de relaciones, cada una de las clases puede tener
atributos y relaciones propias, además de las que tenga la clase padre.
Por ejemplo:

En este caso se representa que los empleados (supertipo) pueden ser de dos clases
(subtipos): fijos o temporales. Todos los empleados, independiente de su tipo, se
identifican con la cedula y deben tener un nombre, adicionalmente están asignados a un
departamento. Los empleados fijos son los únicos que tienen definido un salario. Los
empleados temporales tienen asignado un valor por hora y pertenecen a una empresa de
temporales.

Al igual que otras entidades, los supertipos y subtipos deben tener una clave o llave; si la
clave se ha definido para el supertipo (como en el ejemplo anterior), se entiende que es la
misma para todos los subtipos; de otra forma, cada subtipo deberá definir su propia clave.

¿Qué pasa si no se usan los supertipos y subtipos?

R// Debido a que el Modelo de datos es un modelo conceptual, el manejo
de supertipos y subtipos ayuda a representar mejor el mundo real,
identificando atributos comunes; sin embargo, no es obligatoria su
utilización, pero sí debe asegurarse que toda la información necesaria se
represente en el modelo; en el caso del ejemplo, deberían entonces
crearse dos entidades: empleado fijo y empleado temporal con sus
respectivos atributos y relaciones.