Notación del modelo ER

Símbolo Significado

Tipo de entidad

Tipo de entidad débil

Tipo de relación

Tipo de relación identificador

Atributo

Atributo clave o llave Atributo compuesto Atributo multivaluado Atributo derivado Participación total Participación parcial 1 N E1 R E2 Razón de cardinalidad. Fig. 3.7

Un ejemplo de requerimiento y desarrollo del modelo conceptual.

En esta sección describiremos una base de datos de ejemplo, llamada COMPAÑIA, que servirá para ilustrar los conceptos del modelo ER y su uso en el diseño de esquemas. Aquí vamos a mencionar los requerimientos de información de esta base de datos, y en seguida crearemos su esquema conceptual paso a paso.

La base de datos COMPAÑIA se ocupa de los empleados, departamentos y proyectos de una empresa. Vamos a suponer que, una vez concluida la fase de recolección y análisis de requerimientos, los diseñadores de bases de datos redactaron la siguiente descripción del „minimundo‟ (la parte de la compañía que se representará en la base de datos):

1. La compañía está organizada en departamentos. Cada departamento tiene un nombre único, un número único y un empleado que lo dirige, y nos interesa la fecha en que dicho empleado comenzó a dirigir el departamento. Un departamento puede estar distribuido en varios lugares.

2. Cada departamento controla un cierto número de proyectos, cada uno de los cuales tiene un nombre y un número únicos, y se efectuará en un solo lugar.

3. Se almacenará el nombre, número de matrícula, dirección, salario, sexo y fecha de nacimiento de cada empleado. Todo empleado está asignado a un departamento, pero puede trabajar en varios proyectos, que no necesariamente estarán controlados por el mismo departamento. Nos interesa el número de horas por semana que un empleado trabaja en cada proyecto, y también quién es el supervisor de cada empleado.

4. Se quiere mantener al tanto de los dependientes de cada empleado con el fin de administrar los términos de sus seguros. Se almacenará el nombre, sexo y fecha de nacimiento de cada dependiente, y su parentesco con el empleado.

Tipos de entidades y atributos en la base de datos COMPAÑIA.

Se pueden identificar cuatro tipos de entidades, uno para cada uno de los cuatro elementos (el sujeto que más destacan en cada uno de los cuatro puntos indicado en negrita.):

1. Un tipo de entidad DEPARTAMENTO con atributos Nombre, Número, Lugares. Lugares es un atributo multivaluado. Pueden ser el Nombre o el Número como atributo llave. En este caso se toma como atributo llave el Número y queda como atributo llave candidato a Nombre.

2. Un tipo de entidad PROYECTO con los atributos Nombre, Número y Lugar. Tanto Nombre como Número pueden ser atributo llave. Se escoge el Número como atributo llave, quedando el Nombre como atributo llave candidato.

3. Un tipo de entidad EMPLEADO con los atributos Nombre, Matricula, Sexo, Dirección, Salario, FechaNac y Departamento. Tanto Nombre como Dirección pueden ser atributos compuestos, aunque esto no se especificó en los requerimientos. Se debe de remitir a los usuarios para ver si alguno de ellos va a hacer referencia a los componentes individuales de Nombre – Paterno, Materno, NombPil- o de dirección. 1. Un tipo de entidad débil DEPENDIENTES con el tipo de entidad EMPLEADO, sus

atributos son: NombreDependiente, Sexo, FechaNac y Parentesco (con el empleado). Ninguno de los atributos figuran como llave primaria, por lo que se escoge a un atributo como llave parcial, en este caso es el atributo NombreDependiente.

El diseño preliminar de los tipos de entidades para la base de datos se indica enseguida: DEPARTAMENTO

Nombre, Número, {Lugares} PROYECTO

Nombre, Número, Lugar EMPLEADO

Nombre,(NombPila, Paterno, Materno), Matricula, sexo, Dirección, Salario FechaNac, Departamento.

Siendo los atributos multivaluados indicados entre claves { }; los componentes de un atributo compuesto aparecen entre paréntesis ( ).

Tipos de relaciones y sus restricciones en la base de datos COMPAÑIA.

1. DIRIGE, un tipo de relación 1:1 entre EMPLEADO y DEPARTAMENTO. La participación de EMPLEADO es parcial, pero la de DEPARTAMENTO es total ya que cada departamento siempre debe tener un gerente.

2. PERTENECE_A, un tipo de relación 1: N entre DEPARTAMENTO y EMPLEADO. Ambas participaciones son totales.

3. CONTROLA, un tipo de relación 1: N entre DEPARTAMENTO y PROYECTO. La participación de PROYECTO es total; luego de consultar con los usuarios, se determina que la participación de DEPARTAMENTO es parcial.

4. SUPERVISION, un tipo de relación 1: N entre EMPLEADO (en el papel de supervisor) y EMPLEADO (en el papel de supervisado). Los usuarios nos dicen que no todo empleado es un supervisor y no todo empleado tiene un supervisor, de modo que ambas participaciones son parciales.

5. TRABAJA_EN que, después de que los usuarios indican que varios empleados pueden trabajar en un proyecto y que un empleado puede trabajar en varios proyectos, resulta ser un tipo de relación M: N. El atributo Horas pertenece al tipo de relación TRABAJA_EN ya que no pertenece al proyecto como tal ni al empleado, pertenece a la acción. Se determina que ambas participaciones son totales.

6. DEPENDIENTES_DE, un tipo de relación 1: N entre EMPLEADO y DEPENDIENTE, que también es el tipo de relación identificador del tipo de entidad débil DEPENDIENTE. La participación de EMPLEADO es parcial, en tanto que la de DEPENDIENTE es total.

Es importante tener el mínimo de redundancia posible cuando diseñemos en esquema conceptual de una base de datos.

El diagrama ER del esquema COMPAÑIA.

NomPila Paterno Materno Dirección Número

Nombre Sexo Salario Nombre Lugares PERTENECE_A Matricula N 1 empleado departamento EMPLEADO DEPARTAMENTO gerente departamento FechaN 1 dirigido 1 Departamento 1 DIRIGE controlador

supervisor supervisado fechaInic CONTROLA

1 N M proyecto

SUPERVISION trabajador Horas controlado N proyecto TRABAJA_EN PROYECTO empleado N 1 Nombre Número Lugar DEPENDIENTES_DE N dependiente DEPENDIENTE

Nombre Sexo FechaNac Parentesco Fig. 3.8

Nombres apropiados para los elementos de esquema.

No siempre es trivial la elección de nombres para los tipos de entidades, los atributos, los tipos de relación y sobre todo los papeles que desempeñan. Debemos elegir nombres que comuniquen, hasta donde sea posible, los significados conferidos a los distintos elementos del esquema. Optamos en usar nombres en singular para los tipos de entidades, y no en plural, porque el nombre del tipo de entidades se aplica a cada una de las entidades individuales que pertenecen a ese tipo. En nuestros diagramas ER aplicamos la convención de que los nombres de los tipos de entidades y tipos de relación van en

mayúscula, los nombres de atributos comienzan con mayúscula, y los nombres de papeles van con minúsculas.

Como práctica general, dada una descripción narrativa de los requerimientos de la base de datos, los sustantivos que aparezcan en la narración tenderán a originar nombres de tipos de entidades, y los verbos tenderán a indicar nombres de tipos de relación. Los nombres de los atributos generalmente surgen de los sustantivos adicionales que describen a los sustantivos correspondientes a los tipos de entidades. Otra consideración en lo tocante a los nombres es que los de los tipos de relación deben de elegirse de modo que el diagrama ER del esquema se pueda leer de izquierda a derecha y de arriba hacia abajo.

Tipos de relación con grado mayor que dos.

Ya se definió el grado de un tipo de relación como el número de tipos de entidades participantes, y dijimos que un tipo de relación de grado dos era binario y uno de grado tres era ternario. La notación de diagrama ER para un tipo de relación ternario se ilustra enseguida donde se muestra el esquema del tipo de relación SUMINISTRA. En general, un tipo de relación R de grado n tendrá n aristas conectadas en un diagrama ER, y cada una conectará a R con un tipo de entidad participante.

NumrProv Cantidad NombreProy

PROVEEDOR SUMINISTRA PROYECTO

NúmComp

COMPONENTE Fig. 3.9

En la siguiente figura se muestra un diagrama ER para los tres tipos de relación binarios PUEDE_SUMINISTRAR, UTILIZA y SUMINISTRA.

NomProv NombreProy

M N

PROVEEDOR SUMINISTRA PROYECTO

M M

PUEDE_SUMINISTRAR NúmCo UTILIZA

N

N COMPONENTE

En general, un tipo de relación ternario representa más información que tres tipos de relación binaria. A menudo resulta difícil decidir si un cierto tipo de relación es de grado n o si se debe descomponer en varios tipos de relación de menor grado. El diseñador debe basar su decisión en la semántica o significado de la situación específica que se va a representar. La solución más común es incluir el vínculo ternario junto con uno o más de los vínculos binarios, según se necesite.

Algunas de las herramientas que se emplean en el diseño de bases de datos tienen su fundamento en variaciones del modelo ER que sólo permiten vínculos binarios. En este caso, los tipos de relación ternarios como SUMINISTRAR se deben representar como tipos de entidades débiles, sin clave parcial y con tres vínculos identificadores. Los tres tipos de entidades participantes PROVEEDOR, COMPONENTE y PROYECTO, en conjunto, son los tipos de entidades propietarios; por tanto, una entidad del tipo de entidades débil SUMINISTRAR se identifica mediante la combinación de sus tres entidades propietarias provenientes de PROVEEDOR, COMPONENTE y PROYECTO.

NomProv Cantidad NombreProv

PROVEEDOR VS SUMINISTRA SCP PROYECTO

SC

NúmComp COMPONENTE

Fig. 3.11