Free Press

El modelo de datos entidad relación (ER) existe desde hace más de 35 años. Es muy adecuado para el modelado de datos para su uso con bases de datos porque es bastante abstracto y es fácil de discutir y explicar. Los modelos ER se traducen fácilmente en relaciones. Los modelos ER, también llamados esquema ER, se representan mediante diagramas ER.

El modelado ER se basa en dos conceptos:

• Entidades, definidas como tablas que contienen información específica (datos)
• Relaciones, definidas como las asociaciones o interacciones entre entidades

Aquí hay un ejemplo de cómo estos dos conceptos podrían combinarse en un modelo de datos ER: El profesor Ba (entidad) enseña (relación) el curso de Sistemas de Bases de Datos (entidad).

Para el resto de este capítulo, utilizaremos una base de datos de ejemplo llamada base de datos EMPRESA para ilustrar los conceptos del modelo ER. Esta base de datos contiene información sobre empleados, departamentos y proyectos. Los puntos importantes a tener en cuenta son:

• Hay varios departamentos en la empresa. Cada departamento tiene una identificación única, un nombre, la ubicación de la oficina y un empleado concreto que gestiona el departamento.
• Un departamento controla varios proyectos, cada uno de los cuales tiene un nombre único, un número único y un presupuesto.
• Cada empleado tiene un nombre, un número de identificación, una dirección, un salario y una fecha de nacimiento. Un empleado está asignado a un departamento pero puede participar en varios proyectos. Necesitamos registrar la fecha de inicio del empleado en cada proyecto. También necesitamos saber el supervisor directo de cada empleado.
• Queremos llevar un registro de los dependientes de cada empleado. Cada dependiente tiene un nombre, una fecha de nacimiento y una relación con el empleado.

Entidad, conjunto de entidades y tipo de entidad

Una entidad es un objeto del mundo real con una existencia independiente que puede diferenciarse de otros objetos. Una entidad puede ser

Las entidades pueden clasificarse en función de su fuerza. Una entidad se considera débil si sus tablas dependen de la existencia.

• Es decir, no puede existir sin una relación con otra entidad
• Su clave primaria se deriva de la clave primaria de la entidad padre
  • La tabla Cónyuge, en la base de datos EMPRESA, es una entidad débil porque su clave primaria depende de la tabla Empleado. Sin un registro de empleado correspondiente, el registro de cónyuge no existiría.

Una entidad se considera fuerte si puede existir aparte de todas sus entidades relacionadas.

• Los núcleos son entidades fuertes.
• Una tabla sin clave ajena o una tabla que contiene una clave ajena que puede contener nulos es una entidad fuerte

Otro término a conocer es el de tipo de entidad que define una colección de entidades similares.

Un conjunto de entidades es una colección de entidades de un tipo de entidad en un momento determinado. En un diagrama entidad relación (ERD), un tipo de entidad se representa con un nombre en una caja. Por ejemplo, en la Figura 8.1, el tipo de entidad es EMPLEADO.

Dependencia de existencia

La existencia de una entidad depende de la existencia de la entidad relacionada. Es dependiente de la existencia si tiene una clave foránea obligatoria (es decir, un atributo de clave foránea que no puede ser nulo). Por ejemplo, en la base de datos EMPRESA, una entidad Cónyuge es dependiente de la existencia de la entidad Empleado.

Tipos de Entidades

También debe estar familiarizado con los diferentes tipos de entidades, incluyendo entidades independientes, entidades dependientes y entidades características. Estas se describen a continuación.

Entidades independientes

Las entidades independientes, también denominadas núcleos, son la columna vertebral de la base de datos. En ellas se basan las demás tablas. Los núcleos tienen las siguientes características:

• Son los bloques de construcción de una base de datos.
• La clave primaria puede ser simple o compuesta.
• La clave primaria no es una clave foránea.
• No dependen de otra entidad para su existencia.

Si nos referimos de nuevo a nuestra base de datos EMPRESA, los ejemplos de una entidad independiente incluyen la tabla Cliente, la tabla Empleado o la tabla Producto.

Entidades dependientes

Las entidades dependientes, también denominadas entidades derivadas, dependen de otras tablas para su significado. Estas entidades tienen las siguientes características:

• Las entidades dependientes se utilizan para conectar dos núcleos entre sí.
• Se dice que dependen de la existencia de dos o más tablas.
• Las relaciones de muchos a muchos se convierten en tablas asociativas con al menos dos claves foráneas.
• Pueden contener otros atributos.
• La clave foránea identifica cada tabla asociada.
• Hay tres opciones para la clave primaria:
  1. Utilizar un compuesto de claves foráneas de tablas asociadas si son únicas
  2. Utilizar un compuesto de claves foráneas y una columna calificativa
  3. Crear una nueva clave primaria simple

Entidades características

Las entidades características proporcionan más información sobre otra tabla. Estas entidades tienen las siguientes características:

• Representan atributos multivaluados.
• Describen otras entidades.
• Típicamente tienen una relación de uno a muchos.
• La clave foránea se utiliza para identificar aún más la tabla caracterizada.
• Las opciones para la clave primaria son las siguientes:
  1. Utilizar un compuesto de clave foránea más una columna calificadora
  2. Crear una nueva clave primaria simple. En la base de datos EMPRESA, éstas podrían ser:
     • Empleado (EID, Nombre, Dirección, Edad, Salario) – EID es la clave primaria simple.
     • Teléfono del empleado (EID, Teléfono) – EID es parte de una clave primaria compuesta. Aquí, EID es también una clave foránea.

Atributos

Cada entidad está descrita por un conjunto de atributos (por ejemplo, Empleado = (Nombre, Dirección, Fecha de Nacimiento (Edad), Salario).

Cada atributo tiene un nombre, y está asociado con una entidad y un dominio de valores legales. Sin embargo, la información sobre el dominio de los atributos no se presenta en el ERD.

En el diagrama entidad relación, mostrado en la Figura 8.2, cada atributo está representado por un óvalo con un nombre dentro.

Tipos de atributos

Hay algunos tipos de atributos con los que hay que familiarizarse. Algunos de ellos deben dejarse como están, pero otros deben ajustarse para facilitar la representación en el modelo relacional. En esta primera sección se hablará de los tipos de atributos. Más adelante hablaremos de la fijación de los atributos para que encajen correctamente en el modelo relacional.

Atributos simples

Los atributos simples son los que se extraen de los dominios de valores atómicos; también se denominan atributos de un solo valor. En la base de datos EMPRESA, un ejemplo sería: Nombre = {Juan} ; Edad = {23}

Atributos compuestos

Los atributos compuestos son aquellos que constan de una jerarquía de atributos. Utilizando el ejemplo de nuestra base de datos, que se muestra en la Figura 8.3, la dirección puede estar formada por el número, la calle y el barrio. Así, se escribiría como → Dirección = {59 + ‘Meek Street’ + ‘Kingsford’}

Atributos multivaluados

Los atributos multivaluados son atributos que tienen un conjunto de valores para cada entidad. Un ejemplo de atributo multivaluado de la base de datos EMPRESA, como se ve en la Figura 8.4, son los títulos de un empleado: BSc, MIT, PhD.

Atributos derivados

Los atributos derivados son atributos que contienen valores calculados a partir de otros atributos. Un ejemplo de ello puede verse en la figura 8.5. La edad puede derivarse del atributo Fecha de nacimiento. En esta situación, Fecha de nacimiento se denomina atributo almacenado, que se guarda físicamente en la base de datos.

Claves

Una restricción importante en una entidad es la clave. La clave es un atributo o un grupo de atributos cuyos valores pueden utilizarse para identificar de forma exclusiva una entidad individual en un conjunto de entidades.

Tipos de claves

Hay varios tipos de claves. Se describen a continuación.

Clave candidata

Una clave candidata es una clave simple o compuesta que es única y mínima. Es única porque no hay dos filas en una tabla que puedan tener el mismo valor en cualquier momento. Es mínima porque cada columna es necesaria para lograr la unicidad.

De nuestro ejemplo de base de datos EMPRESA, si la entidad es Empleado(EID, Nombre, Apellido, SIN, Dirección, Teléfono, Fecha de Nacimiento, Salario, DepartamentoID), las posibles claves candidatas son:

• EID, SIN
• Nombre y Apellido – suponiendo que no hay nadie más en la empresa con el mismo nombre
• Apellido y DepartmentID – suponiendo que dos personas con el mismo apellido no trabajan en el mismo departamento

Clave compuesta

Una clave compuesta se compone de dos o más atributos, pero debe ser mínima.

Usando el ejemplo de la sección de claves candidatas, las posibles claves compuestas son:

• Nombre y Apellido – suponiendo que no hay nadie más en la empresa con el mismo nombre
• Apellido e ID de departamento – suponiendo que dos personas con el mismo apellido no trabajan en el mismo departamento

Clave primaria

La clave primaria es una clave candidata que es seleccionada por el diseñador de la base de datos para ser utilizada como mecanismo de identificación para todo el conjunto de entidades. Debe identificar de forma exclusiva las tuplas de una tabla y no ser nula. La clave primaria se indica en el modelo ER subrayando el atributo.

• Una clave candidata es seleccionada por el diseñador para identificar de forma exclusiva las tuplas de una tabla. No debe ser nula.
• El diseñador de la base de datos elige una clave para utilizarla como mecanismo de identificación para todo el conjunto de entidades. Se denomina clave primaria. Esta clave se indica subrayando el atributo en el modelo ER.

En el siguiente ejemplo, EID es la clave primaria:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Clave secundaria

Una clave secundaria es un atributo utilizado estrictamente para fines de recuperación (puede ser compuesto), por ejemplo: Teléfono y Apellido.

Clave alternativa

Las claves alternativas son todas las claves candidatas no elegidas como clave primaria.

Clave foránea

Una clave foránea (FK) es un atributo de una tabla que hace referencia a la clave primaria de otra tabla O puede ser nula. Tanto las claves externas como las primarias deben ser del mismo tipo de datos.

En el ejemplo de la base de datos EMPRESA que se muestra a continuación, DepartmentID es la clave externa:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Nulls

Un null es un símbolo especial, independiente del tipo de datos, que significa desconocido o inaplicable. No significa cero o blanco. Las características de los nulos incluyen:

• Sin entrada de datos
• No se permite en la clave primaria
• Debe evitarse en otros atributos
• Puede representar
  • Un valor de atributo desconocido
  • Un valor conocido, pero que falta, valor de atributo
  • Una condición «no aplicable»
• Puede crear problemas cuando se utilizan funciones como COUNT, AVERAGE y SUM
• Puede crear problemas lógicos cuando se enlazan tablas relacionales

NOTA: El resultado de una operación de comparación es nulo cuando cualquiera de los argumentos es nulo. El resultado de una operación aritmética es nulo cuando cualquiera de los argumentos es nulo (excepto las funciones que ignoran los nulos).

Ejemplo de cómo se pueden utilizar los nulos

Use la tabla Salary (Salary_tbl) de la figura 8.6 para seguir un ejemplo de cómo se pueden utilizar los nulos.

Para empezar, busque todos los empleados (emp#) en Ventas (bajo la columna jobName) cuyo salario más comisión sea superior a 30.000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (commission + salary) > 30,000 -> E10 y E12

Este resultado no incluye E13 debido al valor nulo en la columna commission. Para asegurarnos de que se incluye la fila con el valor nulo, tenemos que mirar los campos individuales. Al sumar la comisión y el salario del empleado E13, el resultado será un valor nulo. La solución se muestra a continuación.

Relaciones

Las relaciones son el pegamento que mantiene unidas las tablas. Se utilizan para conectar información relacionada entre tablas.

La fuerza de la relación se basa en cómo se define la clave primaria de una entidad relacionada. Existe una relación débil, o no identificable, si la clave primaria de la entidad relacionada no contiene un componente de clave primaria de la entidad matriz. Los ejemplos de bases de datos de empresas incluyen:

• Cliente(CustID, CustName)
• Orden(OrderID, CustID, Date)

Una relación fuerte, o de identificación, existe cuando la clave primaria de la entidad relacionada contiene el componente de clave primaria de la entidad padre. Los ejemplos incluyen:

• Curso(CrsCode, DeptCode, Descripción)
• Clase(CrsCode, Sección, ClassTime…)

Tipos de Relaciones

A continuación se describen los distintos tipos de relaciones.

Relación uno a muchos (1:M)

Una relación uno a muchos (1:M) debería ser la norma en cualquier diseño de base de datos relacional y se encuentra en todos los entornos de bases de datos relacionales. Por ejemplo, un departamento tiene muchos empleados. La figura 8.7 muestra la relación de uno de estos empleados con el departamento.

Relación uno a uno (1:1)

Una relación uno a uno (1:1) es la relación de una entidad con sólo otra entidad, y viceversa. Debería ser poco frecuente en cualquier diseño de base de datos relacional. De hecho, podría indicar que dos entidades pertenecen realmente a la misma tabla.

Un ejemplo de la base de datos EMPRESA es que un empleado está asociado a un cónyuge, y un cónyuge está asociado a un empleado.

Relaciones de muchos a muchos (M:N)

Para una relación de muchos a muchos, considere los siguientes puntos:

• No puede implementarse como tal en el modelo relacional.
• Puede cambiarse a dos relaciones 1:M.
• Puede implementarse rompiendo para producir un conjunto de relaciones 1:M.
• Implica la implementación de una entidad compuesta.
• Crea dos o más relaciones 1:M.
• La tabla de entidad compuesta debe contener al menos las claves primarias de las tablas originales.
• La tabla de enlace contiene múltiples apariciones de los valores de clave foránea.
• Se pueden asignar atributos adicionales según sea necesario.
• Puede evitar los problemas inherentes a una relación M:N creando una entidad compuesta o entidad puente. Por ejemplo, un empleado puede trabajar en muchos proyectos O un proyecto puede tener muchos empleados trabajando en él, dependiendo de las reglas de negocio. O, un estudiante puede tener muchas clases y una clase puede contener muchos estudiantes.

La Figura 8.8 muestra otro aspecto de la relación M:N donde un empleado tiene diferentes fechas de inicio para diferentes proyectos. Por lo tanto, necesitamos una tabla JOIN que contenga el EID, el código y la fecha de inicio.

Ejemplo de mapeo de un tipo de relación binaria M:N

• Para cada relación binaria M:N, identifique dos relaciones.
• A y B representan dos tipos de entidad que participan en R.
• Cree una nueva relación S para representar a R.
• S necesita contener los PKs de A y B. Estos juntos pueden ser el PK en la tabla S O estos junto con otro atributo simple en la nueva tabla R pueden ser el PK.
• La combinación de las claves primarias (A y B) hará la clave primaria de S.

Relación unaria (recursiva)

Una relación unaria, también llamada recursiva, es aquella en la que existe una relación entre ocurrencias del mismo conjunto de entidades. En esta relación, las claves primaria y foránea son las mismas, pero representan dos entidades con roles diferentes. Véase un ejemplo en la figura 8.9.

Para algunas entidades en una relación unaria, se puede crear una columna separada que haga referencia a la clave primaria del mismo conjunto de entidades.

Relaciones ternarias

Una relación ternaria es un tipo de relación que implica relaciones de muchos a muchos entre tres tablas.

Consulte la figura 8.10 para ver un ejemplo de asignación de un tipo de relación ternaria. Tenga en cuenta que n-ary significa varias tablas en una relación. (Recuerde, N = muchos.)

• Para cada relación n-aria (> 2), cree una nueva relación para representar la relación.
• La clave primaria de la nueva relación es una combinación de las claves primarias de las entidades participantes que mantienen el lado N (muchos).
• En la mayoría de los casos de una relación n-aria, todas las entidades participantes mantienen un lado muchos.

Atribución

Este capítulo de Diseño de Bases de Datos (incluyendo las imágenes, salvo que se indique lo contrario) es una copia derivada de Data Modeling Using Entity-Relationship Model de Nguyen Kim Anh con licencia Creative Commons Attribution License 3.0 license

El siguiente material fue escrito por Adrienne Watt:

1. Sección de nulos y ejemplo
2. Términos clave
3. Ejercicios