Modelo de Entidad - Relación de una

BBDD
El modelo entidad-relación es una herramienta clave para gestionar proyectos de una base de
datos. Este diagrama permite representar de forma visual cómo se estructuran los datos antes de
crear una base de datos real.

Qué es el modelo entidad relación

El modelo entidad-relación, diagrama entidad relación o ERD, es una herramienta que se

utiliza en la segunda fase del diseño de una base de datos.

Este diagrama, creado por el informático Peter Chen, representa, de forma visual y
simplificada, cómo se conectan entre sí personas, objetos o conceptos dentro de un sistema.

El modelo ER permite organizar y visualizar la estructura de la información antes de

crear la base de datos definitiva, proporcionando un esquema claro y fácil de entender
para diseñar cómo se almacenarán y relacionarán los datos.

Elementos del modelo entidad-relación

El diagrama ER se compone de cuatro elementos básicos:

• Entidades
• Relaciones
• Atributos
• Cardinalidades
•

Esquema simple de una relación entre dos entidades y sus cardinalidades.

P á g i n a 1 | 24
Entidad

Los conjuntos de entidades son elementos sobre los que se recopila información para
representar en la base de datos. Existen dos tipos de entidades y se representan
gráficamente con un rectángulo:

• Entidades fuertes: No dependen de otras entidades para existir. Por ejemplo, un alumno
en una base de datos de una escuela es una entidad fuerte porque existe de manera
independiente.
• Entidades débiles: Dependen de una entidad fuerte para tener sentido. Este es el caso de
un pedido en una tienda online es una entidad débil porque siempre está vinculado a un
cliente.

Relación

Una relación indica cómo interactúan o se conectan dos o más entidades. Se representa
con un rombo y suele expresarse como un verbo. Existen distintos tipos de relaciones
según su grado:

• Grado 1 o relación urinaria: Relaciona una entidad consigo misma. Este es el caso de un
delegado de alumnos de un curso que también es alumno del curso.
• Grado 2 o relación binaria: Conecta dos entidades distintas. Por ejemplo, un proveedor
que suministra artículos.
• Grado 3 o relación ternaria: Vincula tres o más entidades. Por ejemplo, un cliente de un
banco que tiene varias cuentas y cada una en una sucursal.

Las relaciones entre entidades pueden tener diferentes tipos de correspondencia, que
indican cómo se conectan entre sí:

• 1:1 (Uno a uno): A cada elemento de la primera entidad le corresponde uno y solo uno
de la segunda entidad, y viceversa. Por ejemplo, un cliente de un hotel ocupa una única
habitación, o un curso de alumnos está asignado a un solo aula, y solo ese grupo de
alumnos asiste a esa aula.
• 1:N (Uno a muchos): A cada elemento de la primera entidad le corresponde uno o más
elementos de la segunda entidad, pero a cada elemento de la segunda entidad solo le
corresponde uno de la primera entidad. Un ejemplo sería un proveedor que suministra
varios artículos, pero cada artículo tiene un único proveedor.
• N:M (Varios a varios): Varias ocurrencias de una entidad pueden estar asociadas a varias
de la otra. Por ejemplo, un estudiante puede inscribirse en varios cursos, y cada curso
puede tener varios estudiantes inscritos.

Atributos

Los atributos son las características o detalles que describen una entidad. Son como las
propiedades que definen a un elemento dentro de las bases de datos existentes.

Por ejemplo, si tenemos una entidad llamada Persona, algunos de sus atributos podrían ser:
P á g i n a 2 | 24
 • Nombre
• Edad
• DNI (que sería único para cada persona)

El conjunto de atributos ayudan a dar más información sobre una entidad, como el nombre
de un estudiante o la fecha de nacimiento de un cliente. En un diagrama, los atributos se
representan con círculos.

Cardinalidad

La cardinalidad define cuántas veces una entidad puede estar relacionada con otra.
Básicamente, muestra cuántos elementos de una entidad pueden asociarse con los de otra
entidad.

Por ejemplo, en una relación de 1:1, como un coche y su matrícula, cada coche tiene solo
una matrícula, y cada matrícula pertenece a un solo coche. En una relación de 1:N, como
un cliente y sus pedidos, un cliente puede hacer varios pedidos, pero cada pedido solo
pertenece a un cliente.

En una relación N:M, como la de estudiantes y cursos, varios estudiantes pueden estar
inscritos en varios cursos, y cada curso puede tener varios estudiantes.

Cómo diseñar un esquema conceptual de base de datos

El esquema conceptual de una base de datos ofrece una visión general de cómo se
organizarán los datos y qué relaciones existirán entre ellos. Es el primer paso para
estructurar correctamente la base de datos, y los pasos a seguir para diseñarlo son los
siguientes.

Recopilar la información del cliente

Es fundamental recopilar toda la información necesaria del cliente para entender sus
necesidades. Esto permite diseñar una base de datos que realmente cumpla con los
requisitos del usuario y se ajuste a sus objetivos.

Diseñar el modelo entidad-relación

En este paso, se crea el diagrama del modelo entidad-relación (ER), volcando los datos
que se han recopilado. Se siguen las reglas gráficas estándar: las entidades se representan
con rectángulos, las relaciones con rombos y los atributos con círculos.

Este modelo ayuda a visualizar cómo se conectan los diferentes elementos dentro de la base
de datos.

P á g i n a 3 | 24
Ejemplos de entidad - relación

A continuación, se muestra un ejemplo de cómo se representaría gráficamente una base de

datos con las siguientes entidades: autor, libro, ejemplar y usuario:

• Autor: Los atributos de la entidad autor son código y nombre. El código es el atributo
principal, ya que es único para cada autor.
• Libro: Los atributos de la entidad libro son páginas, código, título, ISBN y editorial. El
código es el atributo principal y es único para cada libro.
• Ejemplar: Los atributos de la entidad ejemplar son código y localización. El código es el
atributo principal y único para cada ejemplar.
• Usuario: Los atributos de la entidad usuario son código, nombre, teléfono y dirección. El
código es el atributo principal y único para cada usuario.

En este modelo, hay tres relaciones principales:

• Autor - Libro: Un autor puede haber escrito varios libros. Esta es una relación entre las
entidades autor y libro.
• Libro - Ejemplar: Un libro puede tener varios ejemplares. Esta relación conecta las
entidades libro y ejemplar.
• Usuario - Ejemplar: Un usuario puede tener varios ejemplares prestados. Esta es la
relación entre las entidades usuario y ejemplar.

P á g i n a 4 | 24
REGLAS GRÁFICAS ESTÁNDAR PARA REALIZAR UN DIAGRAMA ENTIDAD
RELACION

Las reglas gráficas estándar para realizar un diagrama Entidad-Relación (ER) fueron establecidas
por Peter Chen y posteriormente se han adaptado en distintas variantes como UML, pero aquí te
presento las más comunes y aceptadas para diagramas ER clásicos:

🔷 1. Símbolos principales
Representación
Elemento Descripción
Gráfica

Representa una cosa u objeto con existencia propia (por

Entidad Rectángulo
ejemplo, Producto, Cliente).

Describe propiedades de una entidad o relación (por ejemplo,

Atributo Elipse (óvalo)
nombre, precio).

Clave
Elipse subrayada Es un atributo que identifica de forma única una entidad.
primaria

Representa la asociación entre entidades (por ejemplo,

Relación Rombos (diamantes)
realiza, contiene).

Línea Línea recta Une entidades con relaciones, y relaciones con atributos.

🔢 2. Cardinalidad

La cardinalidad muestra cuántas instancias de una entidad pueden participar en una relación:

Cardinalidad Representación Significado

1:1 1 ———— 1 Uno a uno

1:N 1 ———— N Uno a muchos

M:N M ———— N Muchos a muchos

🔁 3. Tipos especiales de atributos

Tipo de Atributo Representación Ejemplo

Compuesto Óvalo con sub-óvalos Nombre (dividido en nombre y apellido)

Multivaluado Óvalo doble Teléfonos (puede haber más de uno)

Derivado Óvalo punteado Edad (derivada de fecha de nacimiento)

P á g i n a 5 | 24
Descripción

El modelo entidad/relación extendido describe con un alto nivel de abstracción la

distribución de datos almacenados en un sistema. Existen dos elementos principales: las
entidades y las relaciones. Las extensiones al modelo básico añaden además los atributos de
las entidades y la jerarquía entre éstas. Estas extensiones tienen como finalidad aportar al
modelo una mayor capacidad expresiva.

Los elementos fundamentales del modelo son los siguientes:

Entidad

Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la base
de datos. La estructura genérica de un conjunto de entidades con las mismas características
se denomina tipo de entidad.

Existen dos clases de entidades: regulares, que tienen existencia por sí mismas, y débiles
cuya existencia depende de otra entidad. Las entidades deben cumplir las siguientes tres
reglas:

• Tienen que tener existencia propia.

• Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás.
• Todas las ocurrencias de un tipo de entidad deben tener los mismos atributos.

Relación

Es una asociación o correspondencia existente entre una o varias entidades. La relación

puede ser regular, si asocia tipos de entidad regulares, o débil, si asocia un tipo de entidad
débil con un tipo de entidad regular. Dentro de las relaciones débiles se distinguen la
dependencia en existencia y la dependencia en identificación.

Se dice que la dependencia es en existencia cuando las ocurrencias de un tipo de entidad

débil no pueden existir sin la ocurrencia de la entidad regular de la que dependen. Se dice
que la dependencia es en identificación cuando, además de lo anterior, las ocurrencias del
tipo de entidad débil no se pueden identificar sólo mediante sus propios atributos, sino que
se les tiene que añadir el identificador de la ocurrencia de la entidad regular de la cual
dependen.

Además, se dice que una relación es exclusiva cuando la existencia de una relación entre
dos tipos de entidades implica la no existencia de las otras relaciones.

Una relación se caracteriza por:

• Nombre: que lo distingue unívocamente del resto de relaciones del modelo.

P á g i n a 6 | 24
 • Tipo de correspondencia: es el número máximo de ocurrencias de cada tipo de entidad
que pueden intervenir en una ocurrencia de la relación que se está tratando.
Conceptualmente se pueden identificar tres clases de relaciones:
o Relaciones 1:1: Cada ocurrencia de una entidad se relaciona con una y sólo una
ocurrencia de la otra entidad.
o Relaciones 1:N: Cada ocurrencia de una entidad puede estar relacionada con cero,
una o varias ocurrencias de la otra entidad.
o Relaciones M:N: Cada ocurrencia de una entidad puede estar relacionada con
cero, una o varias ocurrencias de la otra entidad y cada ocurrencia de la otra
entidad puede corresponder a cero, una o varias ocurrencias de la primera.
• Cardinalidad: representa la participación en la relación de cada una de las entidades
afectadas, es decir, el número máximo y mínimo de ocurrencias de un tipo de entidad que
pueden estar interrelacionadas con una ocurrencia de otro tipo de entidad. La
cardinalidad máxima coincide con el tipo de correspondencia.

Según la cardinalidad, una relación es obligatoria, cuando para toda ocurrencia de un tipo
de entidad existe al menos una ocurrencia del tipo de entidad asociado, y es opcional
cuando, para toda ocurrencia de un tipo de entidad, puede existir o no una o varias
ocurrencias del tipo de entidad asociado.

Dominio

Es un conjunto nominado de valores homogéneos. El dominio tiene existencia propia con

independencia de cualquier entidad, relación o atributo.

Atributo

Es una propiedad o característica de un tipo de entidad. Se trata de la unidad básica de

información que sirve para identificar o describir la entidad. Un atributo se define sobre un
dominio. Cada tipo de entidad ha de tener un conjunto mínimo de atributos que identifiquen
unívocamente cada ocurrencia del tipo de entidad. Este atributo o atributos se denomina
identificador principal. Se pueden definir restricciones sobre los atributos, según las cuales
un atributo puede ser:

• Univaluado, atributo que sólo puede tomar un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.
• Obligatorio, atributo que tiene que tomar al menos un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.

Además de estos elementos, existen extensiones del modelo entidad/relación que

incorporan determinados conceptos o mecanismos de abstracción para facilitar la
representación de ciertas estructuras del mundo real:

• La generalización, permite abstraer un tipo de entidad de nivel superior (supertipo) a

partir de varios tipos de entidad (subtipos); en estos casos los atributos comunes y
relaciones de los subtipos se asignan al supertipo. Se pueden generalizar por ejemplo los
tipos profesor y estudiante obteniendo el supertipo persona.
P á g i n a 7 | 24
 • La especialización es la operación inversa a la generalización, en ella un supertipo se
descompone en uno o varios subtipos, los cuales heredan todos los atributos y relaciones
del supertipo, además de tener los suyos propios. Un ejemplo es el caso del tipo
empleado, del que se pueden obtener los subtipos secretaria, técnico e ingeniero.
• Categorías. Se denomina categoría al subtipo que aparece como resultado de la unión de
varios tipos de entidad. En este caso, hay varios supertipos y un sólo subtipo. Si por
ejemplo se tienen los tipos persona y compañía y es necesario establecer una relación con
vehículo, se puede crear propietario como un subtipo unión de los dos primeros.
• La agregación, consiste en construir un nuevo tipo de entidad como composición de otros
y su tipo de relación y así poder manejarlo en un nivel de abstracción mayor. Por ejemplo,
se tienen los tipos de entidad empresa y solicitante de empleo relacionados mediante el
tipo de relación entrevista; pero es necesario que cada entrevista se corresponda con una
determinada oferta de empleo. Como no se permite la relación entre tipos de relación, se
puede crear un tipo de entidad compuesto por empresa, entrevista y solicitante de empleo
y relacionarla con el tipo de entidad oferta de empleo. El proceso inverso se denomina
desagregación.
• La asociación, consiste en relacionar dos tipos de entidades que normalmente son de
dominios independientes, pero coyunturalmente se asocian.

La existencia de supertipos y subtipos, en uno o varios niveles, da lugar a una jerarquía,

que permitirá representar una restricción del mundo real.

Una vez construido el modelo entidad/relación, hay que analizar si se presentan

redundancias. Para poder asegurar su existencia se deben estudiar con mucho detenimiento
las cardinalidades mínimas de las entidades, así como la semántica de las relaciones.

Los atributos redundantes, los que se derivan de otros elementos mediante algún calculo,
deben ser eliminados del modelo entidad/relación o marcarse como redundantes.

Igualmente, las relaciones redundantes deben eliminarse del modelo, comprobando que al
eliminarlas sigue siendo posible el paso, tanto en un sentido como en el inverso, entre las
dos entidades que unían.

Notación

Entidad
La representación gráfica de un tipo de entidad regular es un rectángulo etiquetado con el
nombre del tipo de entidad. Un tipo de entidad débil se representa con dos rectángulos
concéntricos con su nombre en el interior.

Relación
P á g i n a 8 | 24
Se representa por un rombo unido a las entidades relacionadas por dos líneas rectas a los
lados. El tipo de correspondencia se representa gráficamente con una
etiqueta 1:1, 1:N o M:N, cerca de alguno de los vértices del rombo, o bien situando cada
número o letra cerca de la entidad correspondiente, para mayor claridad.

La representación gráfica de las cardinalidades se realiza mediante una etiqueta del

tipo (0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que
corresponda. Si se representan las cardinalidades, la representación del tipo de
correspondencia es redundante.

Atributo

Un atributo se representa mediante una elipse, con su nombre dentro, conectada por una
línea al tipo de entidad o relación.

En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un círculo más
pequeño con el nombre del atributo a un lado. También pueden representarse en una lista
asociada a la entidad. El identificador aparece con el nombre marcado o subrayado, o bien
con su círculo en negro.

P á g i n a 9 | 24
Exclusividad

En la representación de las relaciones exclusivas se incluye un arco sobre las líneas que
conectan el tipo de entidad a los dos o más tipos de relación.

Jerarquía (tipos y subtipos)

La representación de las jerarquías se realiza mediante un triángulo invertido, con la base

paralela al rectángulo que representa el supertipo y conectando a éste y a los subtipos. Si la
división en subtipos viene determinada en función de los valores de un atributo
discriminante, éste se representará asociado al triángulo que representa la relación.

P á g i n a 10 | 24
En el triángulo se representará: con una letra d el hecho de que los subtipos sean disjuntos,
con un círculo o una O si los subtipos pueden solaparse y con una U el caso de uniones por
categorías. La presencia de una jerarquía total se representa con una doble línea entre el
supertipo y el triángulo.

Ejemplo

Modelo entidad-relación extendido para un sistema de gestión de técnicos y su asignación a

proyectos dentro de una empresa u organización.

Como se aprecia en el diagrama, TÉCNICO es un subtipo de EMPLEADO, generado por

especialización, pues era necesario para establecer la relación Trabaja en con PROYECTO,
ya que no todos los empleados de la empresa, como los administrativos, son susceptibles de
trabajar en un proyecto. La entidad TÉCNICO tendrá los atributos de EMPLEADO más el
atributo nivel.

P á g i n a 11 | 24
Los tipos de correspondencia son 1:N entre DEPARTAMENTO y EMPLEADO, pues un
departamento tiene 1 o varios empleados. Entre TÉCNICO y PROYECTO es M:N, pues un
técnico puede trabajar en 1 o varios proyectos, y en un proyecto trabajan 1 o varios
técnicos.

Por otro lado, se han incluido atributos que caracterizan la relación Trabaja en, como
son fecha de asignación y fecha de cese, ya que un técnico no siempre estará trabajando en
un proyecto, sino en determinado periodo. (Nota.- Esta notación es la más habitual, pero
MÉTRICA Versión 3 no exige su utilización).

P á g i n a 12 | 24
Normalización
La teoría de la normalización tiene por objetivo la eliminación de dependencias entre
atributos que originen anomalías en la actualización de los datos, y proporcionar una
estructura más regular para la representación de las tablas, constituyendo el soporte para el
diseño de bases de datos relacionales.

Como resultado de la aplicación de esta técnica se obtiene un modelo lógico de datos

normalizado.

Descripción

La teoría de la normalización, como técnica formal para organizar los datos, ayuda a
encontrar fallos y a corregirlos, evitando así introducir anomalías en las operaciones de
manipulación de datos.

Se dice que una relación está en una determinada forma normal si satisface un cierto
conjunto de restricciones sobre los atributos. Cuanto más restricciones existan, menor será
el número de relaciones que las satisfagan, así, por ejemplo, una relación en tercera forma
normal estará también en segunda y en primera forma normal.

Antes de definir las distintas formas normales se explican, muy brevemente, algunos
conceptos necesarios para su comprensión.

Dependencia funcional

Un atributo Y se dice que depende funcionalmente de otro X si, y sólo si, a cada valor de X
le corresponde un único valor de Y, lo que se expresa de la siguiente forma: X → Y
(también se dice que X determina o implica a Y).

X se denomina implicante o determinante e Y es el implicado.

Dependencia funcional completa

Un atributo Y tiene dependencia funcional completa respecto de otro X, si depende

funcionalmente de él en su totalidad, es decir, no depende de ninguno de los posibles
atributos que formen parte de X.

Dependencia transitiva

Un atributo depende transitivamente de otro si, y sólo si, depende de él a través de otro
atributo. Así, Z depende transitivamente de X, si:

X --→ Y
Y -/→ X
Y --→ Z
P á g i n a 13 | 24
Se dice que X implica a Z a través de Y.

Una vez definidas las anteriores dependencias, se pueden enunciar las siguientes formas
normales:

Primera forma normal (1FN)

Una entidad está en 1FN si no tiene grupos repetitivos, es decir, un atributo sólo puede
tomar un único valor de un dominio simple.

Una vez identificados los atributos que no dependen funcionalmente de la clave principal,
se formará con ellos una nueva entidad y se eliminarán de la antigua. La clave principal de
la nueva entidad estará formada por la concatenación de uno o varios de sus atributos más
la clave principal de la antigua entidad.

Segunda forma normal (2FN)

Una entidad está en 2FN si está en 1FN y todos los atributos que no forman parte de las
claves candidatas (atributos no principales) tienen dependencia funcional completa respecto
de éstas, es decir, no hay dependencias funcionales de atributos no principales respecto de
una parte de las claves. Cada uno de los atributos de una entidad depende de toda la clave.

Una vez identificados los atributos que no dependen funcionalmente de toda la clave, sino
sólo de parte de la misma, se formará con ellos una nueva entidad y se eliminarán de la
antigua. La clave principal de la nueva entidad estará formada por la parte de la antigua de
la que dependen funcionalmente.

Tercera forma normal (3FN)

Una entidad está en 3FN si está en 2FN y todos sus atributos no principales dependen
directamente de la clave primaria, es decir, no hay dependencias funcionales transitivas de
atributos no principales respecto de las claves.

Una vez identificados los atributos que dependen de otro atributo distinto de la clave, se
formará con ellos una nueva entidad y se eliminarán de la antigua. La clave principal de la
nueva entidad será el atributo del cual dependen. Este atributo en la entidad antigua, pasará
a ser una clave ajena.

Notación

Una herramienta muy útil para visualizar las dependencias funcionales es el grafo o
diagrama de dependencias funcionales, mediante el cual se representa un conjunto de
atributos y las dependencias funcionales existentes entre ellos.

En el grafo aparecen los nombres de los atributos unidos por flechas, las cuales indican las
dependencias funcionales completas que existen entre ellos, partiendo del implicante hacia
P á g i n a 14 | 24
el implicado. Cuando el implicante de una dependencia no es un único atributo, es decir, se
trata de un implicante compuesto, los atributos que lo componen se encierran en un
recuadro y la flecha parte de éste, no de cada atributo.

En la figura se presenta un ejemplo de cómo se visualizan las dependencias. Se puede

observar que cod_libro determina funcionalmente el título del libro y la editorial, como
indica la correspondiente flecha; de forma análoga, num_socio determina el nombre,
domicilio y el tel. del socio (suponiendo que sólo se proporciona un teléfono); mientras que
ambos atributos en conjunto cod_libro y num_socio (lo que se indica mediante el recuadro
que los incluye) determinan fecha_préstamo y fecha_dev.

Ejemplo

Sea una entidad TÉCNICOS de un grupo de empresas, con los siguientes atributos:

• cod_empresa
• cod_técnico
• nombre_técnico
• cod_categoría
• categoría
• nombre_empresa
• fecha_alta
• fecha_baja
• cod_conoc
• título_conoc
• área_conoc
• grado
• cod_proyecto
• nombre_proyecto
• f_inicio
• f_fin
• f_asignación
• f_cese
• cod_cliente
• nombre_cliente

La entidad TÉCNICOS tiene la clave principal compuesta por cod_empresa y cod_técnico,

ya que, al ser varias empresas, el código de técnico no será único, sino que puede coincidir
con otros de otras empresas.
P á g i n a 15 | 24
Primera forma normal (1FN)

Evidentemente no se cumple la primera forma normal, ya que un técnico tendrá más de un

conocimiento (lenguajes, sistemas operativos, bases de datos, etc.), es decir habrá varios
valores de cod_conoc, por lo que este atributo y los asociados a conocimientos no dependen
funcionalmente de la clave principal.

Los atributos cod_conoc, título_conoc, área_conoc y grado identificados como no

dependientes, formarán la nueva entidad CONOCIMIENTOS y desaparecerán de la entidad
TÉCNICOS. La clave de la nueva entidad será cod_conoc concatenada con cod_empresa y
cod_técnico.

Por otro lado, en este sistema un técnico puede trabajar en más de un proyecto a tiempo
parcial, por lo que cod_proyecto tampoco depende funcionalmente de la clave principal de
TÉCNICOS.

Se obtiene entonces la entidad PROYECTOS con los atributos de los proyectos, y su clave
compuesta de cod_proyecto concatenada con cod_empresa y cod_técnico de la antigua
entidad.

Esta situación se completará con dos tipos de relaciones: Poseen, cuyo tipo de
correspondencia es 1:N entre TÉCNICOS y CONOCIMIENTOS y Están asignados,
también del tipo M:N entre TÉCNICOS y PROYECTOS, tal y como muestra el diagrama
siguiente.

P á g i n a 16 | 24
Como se aprecia en la figura, se ha trasladado el atributo grado de la entidad
CONOCIMIENTOS a la relación Poseen, pues es un atributo que determina la relación
entre las dos entidades. También han sido trasladado los atributos que caracterizan la
relación Están asignados, como son f_asignación y f_cese, ya que un técnico no siempre
estará trabajando en un proyecto, sino en determinado periodo.

Segunda forma normal (2FN)

En la entidad TÉCNICOS se observa que el atributo nombre_empresa no tiene una

dependencia funcional completa de la clave, sino que la tiene sólo de una parte de la
misma: cod_empresa.

El atributo identificado formará parte de una nueva entidad, EMPRESAS, siendo eliminado
de la antigua. La clave principal de la nueva entidad será cod_empresa.

Para representar la segunda forma normal en el modelo de datos, deberá añadirse un tipo de
relación, Se componen, y el tipo de correspondencia 1:N.

P á g i n a 17 | 24
Tercera forma normal (3FN)

En la entidad TÉCNICOS de la figura se puede observar que para un cod_técnico hay un

único cod_categoría, es decir, el segundo depende funcionalmente del primero; para un
cod_categoría hay una única categoría, es decir, que este atributo depende funcionalmente
del cod_categoría; y por último, para un cod_categoría hay varios valores de cod_técnico.
Así pues, la categoría depende transitivamente del cod_técnico, por lo que la entidad
TÉCNICOS no está en 3FN.

Una vez identificado el atributo categoría que depende de otro atributo distinto de la clave,
cod_categoría, se formará con él una nueva entidad y se quitará de la antigua. La clave
principal de la nueva entidad será el atributo del cual depende cod_categoría y en la
entidad antigua pasará a ser una clave ajena.

P á g i n a 18 | 24
Del mismo modo, puede observarse que la entidad PROYECTOS tampoco está en 3FN,
pues el nombre_cliente depende de cod_cliente, que no forma parte de la clave de la
entidad.

Así pues, aparecen dos entidades nuevas en el modelo: CATEGORÍAS y CLIENTES, y sus
respectivas relaciones y tipos de correspondencias: Están clasificados 1:N y Tiene
contratados 1:N.
P á g i n a 19 | 24
Optimización
El objetivo de esta técnica es reestructurar el modelo físico de datos con el fin de asegurar
que satisface los requisitos de rendimiento establecidos y conseguir una adecuada eficiencia
del sistema.

Descripción

La optimización consiste en una desnormalización controlada del modelo físico de datos

que se aplica para reducir o simplificar el número de accesos a la base de datos.

Para ello, se seguirán alguna de las recomendaciones que a continuación se indican:

• Introducir elementos redundantes.

• Dividir entidades.
• Combinar entidades si los accesos son frecuentes dentro de la misma transacción.
• Redefinir o añadir relaciones entre entidades para hacer más directo el acceso entre
entidades.
• Definir claves secundarias o índices para permitir caminos de acceso alternativos.

Con el fin de analizar la conveniencia o no de la desnormalización, se han de considerar,

otros, los siguientes aspectos:

• Los tiempos de respuesta requeridos.

• La tasa de actualizaciones respecto a la de recuperaciones.
• Las veces que se accede conjuntamente a los atributos.
• La longitud de los mismos.
• El tipo de aplicaciones (en línea / por lotes).
• La frecuencia y tipo de acceso.
• La prioridad de los accesos.
• El tamaño de las tablas.
• Los requisitos de seguridad: accesibilidad, confidencialidad, integridad y disponibilidad que
se consideren relevantes.

Reglas de Obtención del Modelo Físico a

partir del Lógico
El objetivo de esta técnica es obtener un modelo físico de datos a partir del modelo lógico
de datos normalizado. Para ello es necesario aplicar un conjunto de reglas que conserven la
semántica del modelo lógico.

P á g i n a 20 | 24
Descripción

Cada uno de los elementos del modelo lógico se tiene que transformar en un elemento del
modelo físico. En algunos casos la transformación es directa porque el concepto se soporta
igual en ambos modelos, pero otras veces no existe esta correspondencia, por lo que es
necesario buscar una transformación que conserve lo mejor posible la semántica, teniendo
en cuenta los aspectos de eficiencia que sean necesarios en cada caso.

Transformación de entidades

Una entidad se transforma en una tabla.

Transformación de atributos de entidades

Cada atributo se transforma en una columna de la tabla en la que se transformó la entidad a

la que pertenece. El identificador único se convierte en clave primaria.

Si existen restricciones asociadas a los atributos, éstas pueden recogerse con algunas
cláusulas del lenguaje lógico, que se convertirán en disparadores cuando éstos sean
soportados por el sistema gestor de base de datos.

Transformación de relaciones

Según el tipo de correspondencia:

• Relaciones 1:N, se propaga el identificador de la entidad de cardinalidad máxima 1 a la

que es N, teniendo en cuenta que:
o Si la relación es de asociación, la clave propagada es clave ajena en la tabla a la
que se ha propagado.
o Si la relación es de dependencia, la clave primaria de la tabla correspondiente a la
entidad débil está formada por la concatenación de los identificadores de ambas
entidades.
• Relaciones 1:1, es un caso particular de las 1:N y por tanto se propaga la clave en las dos
direcciones. Se debe analizar la situación, intentando recoger la mayor semántica posible,
y evitar valores nulos.

Las relaciones de agregación se transforman del mismo modo que las 1:N.

Transformación de relaciones exclusivas

Después de haber realizado la transformación según las relaciones 1:N, se debe tener en
cuenta que si los identificadores propagados se han convertido en claves ajenas de la tabla
originada por la entidad común a las relaciones, hay que comprobar que una y sólo una de
esas claves es nula en cada ocurrencia. En otro caso, estas comprobaciones se deben hacer
en las tablas resultantes de transformar las relaciones.

P á g i n a 21 | 24
Transformación de la jerarquía

Existen varias posibilidades que deben ser evaluadas por el diseñador a fin de elegir la que
mejor se ajuste a los requisitos. Las opciones para tratar la transformación de la jerarquía
son:

• Opción a: Consiste en crear una tabla para el supertipo que tenga de clave primaria el
identificador y una tabla para cada uno de los subtipos que tengan el identificador del
supertipo como clave ajena.
Esta solución es apropiada cuando los subtipos tienen muchos atributos distintos y se
quieren conservar los atributos comunes en una tabla. También se deben implantar las
restricciones y aserciones adecuadas. Es la solución que mejor conserva la semántica.
• Opción b: Se crea una tabla para cada subtipo, los atributos comunes aparecen en todos
los subtipos y la clave primaria para cada tabla es el identificador del supertipo.
Esta opción mejora la eficiencia en los accesos a todos los atributos de un subtipo, sean los
comunes al supertipo o los específicos.
• Opción c: Agrupar en una tabla todos los atributos de la entidad supertipo y de los
subtipos. La clave primaria de esta tabla es el identificador de la entidad. Se añade un
atributo que indique a qué subtipo pertenece cada ocurrencia (el atributo discriminante
de la jerarquía). Esta solución puede aplicarse cuando los subtipos se diferencien en pocos
atributos y las relaciones entre los subtipos y otras entidades sean las mismas. Para el caso
de que la jerarquía sea total, el atributo discriminante no podrá tomar valor nulo (ya que
toda ocurrencia pertenece a alguna de las entidades subtipo).

Notación

Tabla

La representación gráfica de una tabla es un rectángulo con una línea horizontal que lo
divide en dos. La parte superior, de ancho menor, se etiqueta con el nombre de la tabla.

Relación

La relación entre tablas se representa gráficamente mediante una línea que las une. En ella
pueden aparecer en sus extremos diversos símbolos para indicar la cardinalidad de la
relación, como se muestra a continuación:

P á g i n a 22 | 24
Ejemplo

Sea el diagrama entidad-relación del ejemplo realizado para la Normalización sobre

conocimientos de técnicos informáticos y su asignación a proyectos.

El modelo físico de la figura muestra que cada una de las entidades se ha convertido en una
tabla, cuyo contenido coincide con los atributos de la entidad. Pero hay dos tablas más:
POSEEN, que surge de la relación del mismo nombre y ASIGNACIONES, que se origina a
partir de la relación Están asignados.

P á g i n a 23 | 24
La tabla POSEEN está formada por su atributo grado, más cod_empresa, cod_tecnico y
cod_conoc. La tabla ASIGNACIONES se forma con los atributos clave cod_empresa,
cod_tecnico y cod_proyecto y los propios f_asignación y f_cese.

La relación entre EMPRESAS y TÉCNICOS era 1:N, y la cardinalidad de la figura así lo

muestra, pues la empresa siempre estará compuesta de uno o varios técnicos. Lo mismo
sucede entre CLIENTES y PROYECTOS: un cliente siempre tendrá 1 o varios proyectos
contratados.

El caso de CATEGORÍAS y TÉCNICOS es (0,n). Cada técnico es de una categoría y una

categoría corresponde, por regla general, a varios técnicos, pero puede existir alguna en la
que no encaje ningún técnico (contable, secretaria de dirección, etc.).

La situación del subconjunto TÉCNICOS-POSEEN-CONOCIMIENTOS tiene algo más de

complejidad. Un técnico posee normalmente varios conocimientos, pero debe poseer al
menos uno para que tenga sentido su situación. La cardinalidad es pues (1,n) entre
TÉCNICOS y POSEEN. En el otro lado, lo natural es que un conocimiento sea poseído por
varios técnicos, sin embargo puede existir algún conocimiento que no sea poseído por
ningún técnico, por lo que la cardinalidad es (0,n) y dibujada desde la tabla
CONOCIMIENTOS a POSEEN.

Por último, en el subconjunto TÉCNICOS-ASIGNACIONES-PROYECTOS, se dispone

de: una cardinalidad (0,n), pues a un proyecto estarán asignados uno o más técnicos, pero
puede haber algún técnico que, en un momento dado, no esté asignado aún a ningún
proyecto y una cardinalidad (1,n), pues un proyecto siempre tendrá asignado al menos a un
técnico, o varios.

(Nota.- La notación utilizada para el ejemplo es la más habitual, pero MÉTRICA Versión 3
no exige su utilización).

P á g i n a 24 | 24