ENT-REL2 Vdoc

DISEÑO LOGICO DE UNA BASE DE DATOS
ENFOQUE ENTIDAD - RELACION
POR:
Ingeniero Ismael Castañeda Fuentes, Profesor de la Universidad Nacional de Colombia.
Fuente Principal.
Artículo "THE ENTITY-RELATIONSHIP APPROACH TO LOGICAL DATABASE DESIGN" de
PETER PIN y SHAN CHEN
Documento borrador de trabajo.

Este documento es un borrador de trabajo. Está incompleto y posiblemente tiene errores que se
esperan corregir con su colaboración.
Dirigido a.
Estudiantes del curso de Base de Datos.
1. INTRODUCCION
La administración de datos ha llegado ha ser una de las mayores actividades en muchas

organizaciones. A medida que nos movemos hacia una sociedad dirigida al aumento de información,
el cómo manejar los datos para maximizar su utilidad es un problema mayor. Sistemas de archivos
computarizados y sistemas de base de datos facilitan la tarea de mantenimiento y actualización de
gran cantidad de datos. Sin embargo, el problema de como organizar los datos para utilizar
completamente la capacidad del archivo o el sistema de base de datos no lo entiende la gente que
trabaja con ellos. El objetivo de esta publicación es proveer una metodología que hace más fácil el
entendimiento y uso del proceso de organizar los datos.
1.1TERMINOLOGIA BASICA.
En esta sección, se explican algunos conceptos básicos en la administración de datos.
Curso de Base de Datos - Documento borrador de trabajo - ICF.
Página 1
Figura 1 Registro de un empleado.
RegistroEs una colección de datos. Por ejemplo, un registro EMPLEADO contiene los datos
relevantes de un empleado en particular, ver figura 1. Un registro se divide en
diferentes campos. En la figura 1, NOMBRE, SUELDO, y DIRECCION son los
nombres de los campos de un registro EMPLEADO. Los nombres de los campos se
usan para interpretar el significado del valor del dato en el registro. Por lo tanto,
"Sergio Mantilla" es el "NOMBRE" de un empleado, y "900.000" es su "SUELDO".
Página 1
Figura 2 Archivo de empleados.
ArchivoEs una colección de registros del mismo tipo. Por ejemplo, el archivo de EMPLEADO es
una colección de registros EMPLEADO, ver figura 2.
Figura 3 Una base de datos con dos tipos de registros.
Página 1
Figura 4 Registros relevantes se encadenan en la base de datos (estructura física de la
base de datos).
Figura 5 Estructura lógica de datos de la base de datos.
Base de datos
Es una colección de registros de diferentes tipos, ver figura 3. Los registros en la base de datos son
encadenados de tal manera que los datos relevantes en diferentes registros pueden ser
recuperados sin dificultad. Por ejemplo, se pueden encadenar todos los registros
EMPLEADO que trabajen en el mismo departamento, ver figura 4; así es fácil
encontrar los trabajadores de un departamento en particular. La figura 4 ilustra que la
estructura física de la base de datos; allí se muestran las conexiones entre los registros
DEPARTAMENTO y los registros EMPLEADO las cuales se implementan por
encadenamientos. Un registro DEPARTAMENTO tiene un apuntador al primer
registro EMPLEADO en la cadena. Cada registro EMPLEADO tiene un apuntador
al siguiente registro EMPLEADO en la cadena. El último registro EMPLEADO
apunta al registro DEPARTAMENTO. La figura 4 ilustra las relaciones de ocurrencia
Página 1
de los registros en la base de datos, pero es demasiado detallado para usarlo en la
comunicación de las relaciones de las diferentes llaves de la base de datos. La figura 5
es una representación más simple de la organización de los registros de la figura 4.
Cada caja rectangular representa un tipo de registro y la flecha representa la
asociación del registro EMPLEADO con su registro DEPARTAMENTO. Hay otra
distinción entre las figuras 4 y 5. La figura 5 representa la estructura lógica de la base
de datos, ya que muestra solamente las conexiones entre los tipos de registros
DEPARTAMENTO y EMPLEADO, pero no muestra como se hace la conexión.
1.2DISEÑO LOGICO Y FISICO DE LA BASE DE DATOS.
Página 1
Figura 6 Diseño lógico y físico de la base de datos.
Página 1
El diseño de una base de datos puede ser dividido en dos etapas: diseño lógico y diseño físico, ver
figura 6.
"Diseño físico de la base de datos" es el proceso de selección de una estructura física para una
estructura lógica dada. Por ejemplo, hay al menos tres (3) posibles estructuras físicas en un sistema
de base de datos CODASYL para soportar la misma estructura lógica, ver figura 6. La primera usa
un apuntador hacia adelante para encadenar todos los registros EMPLEADO del mismo
departamento. La segunda tiene adicionalmente un apuntador hacia atrás, al registro anterior de
EMPLEADO. La tercera usa un arreglo de apuntadores en donde el registro DEPARTAMENTO
tiene apuntadores a todos los registros EMPLEADO relacionados. Cada una de estas tres estructuras
tiene sus ventajas y desventajas. La primera es fácil de implementar y sirve para procesos
secuenciales de los registros EMPLEADO. La segunda permite la búsqueda fácil de un registro
EMPLEADO en la cadena, a expensas de un mayor espacio de almacenamiento para los apuntadores
hacia atrás, también realiza borrados más eficientemente. La ventaja clave de la tercera configuración
física es que todos los registros EMPLEADO que pertenecen al mismo departamento pueden
recuperarse de inmediato. Es importante notar que no hay una estructura física universalmente
óptima.
El objetivo del diseño de una estructura física es seleccionar la estructura que más se acomode al
ambiente de una aplicación dada. Aunque el diseño físico de una base de datos es un tópico
importante, no se tratará más en esta publicación.
"El diseño lógico de la base de datos" es el proceso de diseñar la estructura lógica de la base de
datos, ver figura 6. Cubre un análisis del ambiente de la aplicación y la disponibilidad de los tipos de
estructuras lógicas en el sistema de la base de datos. Generalmente hay pocas herramientas para la
ayuda del proceso del diseño lógico de la base de datos; el diseñador se apoya en la intuición y la
experiencia. Como resultado, muchas de las bases de datos existentes no están bien diseñadas.
En esta publicación, se presenta el proceso del diseño lógico y algunas herramientas útiles y prácticas
para ayudar al diseñador de la base de datos.
1.3 SISTEMAS DE BASE DE DATOS Y MODELOS DE DATOS.
Página 1
Figura 7 Estructura jerárquica de datos.
Figura 8 Estructura de datos en red.
Página 1
Figura 9 Estructura relacional de datos.
Página 1
Hay muchos sistemas de bases de datos en el momento. Pueden clasificarse en tres (3) grandes
categorías: Jerárquico, Red y Relacional. La mayor diferencia es el tipo de estructura lógica que las
soporta. Los sistemas de base de datos Jerárquicos, tales como IMS de IBM, requiere que los tipos
de registros sean organizados en forma jerárquica, ver figura 7. La estructura de datos jerárquica
trabaja bien con algunas bases de datos pero se hace difícil cuando la naturaleza jerárquica entre los
registros no existe. Sistemas de base de datos en red (o CODASYL), tales como IDS de Honeywell,
DMS-1100 de UNIVAC e IDMS de CULLINANE, proveen una estructura de datos más compleja
y más capaz que los sistemas de bases de datos jerárquico. Por ejemplo sistemas de base de datos en
red permite a un tipo de registro tener como sus padres múltiples tipos de registros, ver figura 8. Los
sistemas relacionales usan tablas como estructuras lógicas, ver figura 9.
Figura 10 Diseño lógico de la base de datos.
En resumen, el diseño lógico de la base de datos trata la organización de los datos para sostener el
sistema de la base de datos de forma aceptable, ver figura 10.
1.4 PROBLEMAS DEL DISEÑO LOGICO DE UNA BASE DE DATOS.
El diseño de una base de datos actualmente es un proceso complicado ya que el diseñador tiene que
considerar no solamente como modelar el mundo real, sino también las limitaciones del sistema de la
base de datos y la eficiencia de recuperación y actualización. Ejemplos:
Página 1
1.-El diseñador de la base de datos está restringido por las limitaciones de los tipos de estructuras
soportadas por el sistema de la base de datos. Por ejemplo, las relaciones muchos a muchos
entre dos tipos de entidades, tales como las relaciones entre empleados y proyectos, no
pueden ser representadas directamente en muchas bases de datos.
2.-El diseñador de una base de datos debe considerar el camino de acceso de los registros, por
ejemplo como acceder a un tipo de registro particular. Para el caso de la figura 3
implícitamente se asume que el registro EMPLEADO tiene como vía de acceso el
correspondiente registro DEPARTAMENTO.
3.-El diseñador de una base de datos debe considerar como hacer más eficiente una recuperación o
una actualización. Así un dato de una entidad del mundo real puede ser colocado en más de
un registro para mejorar eficiencia. Por ejemplo, los datos de un empleado pueden ser
agrupados en dos registros: MAESTRO-EMPLEADO y DETALLE-EMPLEADO.
Hay dos problemas en el enfoque convencional del diseño de una base de datos:
1.-El diseñador de una base de datos tiene que considerar muchos problemas al mismo tiempo, lo
que hace que el diseño de la base de datos sea un trabajo muy difícil.
2.-El resultado final del proceso del diseño de una base de datos es un esquema para el usuario, por
ejemplo una descripción de la vista del usuario de la base de datos. Ya que el esquema del
usuario representa la solución del diseño de la base de datos, complica los problemas
mencionados anteriormente, por esto el esquema del usuario generalmente es difícil de
entender y difícil de modificar.
1.5UN NUEVO ENFOQUE AL DISEÑO DE LA BASE DE DATOS: EL ENFOQUE

ENTIDAD RELACION.
Página 1
Figura 11 Esquema del estudio. Etapa intermedia en el diseño lógico de la base de datos.
Página 1
Primero se describe nuevo enfoque al diseño lógico de una base de datos llamado enfoque
entidad-relación (E-R). La idea clave del enfoque E-R es agregar una etapa intermedia en el diseño
lógico de la base de datos, ver figura 11. El diseñador de la base de datos primero identifica las
entidades y las relaciones que son de interés a la empresa usando técnicas de diagramación
Entidad-Relación (E-R). En esta etapa, el diseñador de la base de datos debe ver los datos desde el
punto de vista de toda la empresa, no la vista particular de un programador.
Por lo tanto, la descripción de los datos desde el punto de vista de la empresa se denomina el
esquema de la empresa. El esquema de la empresa debe ser una representación pura del mundo real y
debe ser independiente de las consideraciones de almacenamiento y eficiencia. El diseñador de la base
de datos primero diseña el esquema de la empresa y entonces lo traslada al esquema del usuario para
su sistema de la base de datos, ver figura 11.
1.6 VENTAJAS DEL ENFOQUE ENTIDAD-RELACIÓN.
El enfoque convencional del diseño lógico de la base de datos usualmente tiene una sola fase: mapeo
de la información de los objetos en el mundo real al esquema de usuario. El enfoque E-R para el
diseño lógico consiste de dos grandes fases: (1) definir el esquema de la empresa usando diagramas
de entidad-relación, y (2) trasladar el esquema de la empresa al esquema de usuario. Las ventajas del
enfoque E-R son:
(1)La división de funciones y trabajo en dos fases hacen el proceso de diseño de la base de datos
más simple y mejor organizada.
(2)El esquema de empresa es más fácil de diseñar que el esquema de usuario ya que no está
restringida por las capacidades del sistema de la base de datos, y es independiente de las
consideraciones de almacenamiento y eficiencia.
(3)El esquema de empresa es más estable que el esquema de usuario. Si se quiere cambiar de un
sistema de base de datos a otro, probablemente se tendrá que cambiar el esquema de usuario
pero no el esquema de la empresa, ya que el esquema de la empresa es independiente del
sistema de la base de datos usada. Se requiere un nuevo mapeo del esquema de la empresa al
nuevo esquema de usuario del nuevo sistema de la base de datos. Similarmente, si uno quiere
cambiar el esquema del usuario para optimizar una nueva aplicación, no se requiere cambiar
el esquema de la empresa, sino realizar un nuevo mapeo del esquema de la empresa al nuevo
esquema de usuario.
(4)El esquema de la empresa, representado en el diagrama entidad-relación es más fácilmente de

entender por la mayoría de la gente.
Página 1
2. EL ENFOQUE E-R Y EL PROPOSITO ANSI/X3/SPARC.
2.1 PROPOSITO ANSI/X3/SPARC.
El concepto de esquema de la empresa es muy similar al concepto del esquema conceptual

presentado por el grupo ANSI/X3/SPARC. En esta parte, se presenta brevemente la arquitectura
ANSI/X3/SPARC y como aplicar el enfoque E-R a esta arquitectura.
A finales de 1971, el comite sobre computadores y procesamiento de información (abreviado como

comite X3) del INSTITUTO NACIONAL AMERICANO DE ESTANDARES (ANSI) formó un
grupo especial de estudio para determinar cuál (si alguno) de los aspectos de los sistemas de la
administración de las bases de datos eran candidatos para desarrollo de estándares. El grupo especial
de estudio, llamado comite de Planeación de estándares y requerimientos (SPARC), estaba formado
por representantes de usuarios, productores de hardware y universidades.
El grupo ANSI/X3/SPARC gastó mucho tiempo y esfuerzo; consideraron diferentes puntos de vista
de la teoría de base de datos y el desarrollo de un vocabulario que fuera consistente y mutuamente
comprensible. Como resultado, el reporte provisional causó considerable atención en la comunidad
de bases de datos.
Página 1
Figura 12 Arquitectura ANSI/X3/SPARC.
Página 1
Lo que el grupo ANSI/X3/SPARC encontró fue que no era deseable desarrollar estándares que
especifiquen como deben trabajar los componentes de un sistema de administración de base de datos
en cambio se debe enfocar en como se debe mezclar los componentes (ejemplo las interfases). Con
esto en mente, el reporte provisional presentó un esquema triple de la arquitectura de un sistema de
administración de base de datos (ver figura 12). Usualmente los sistemas corrientes de administración
de base de datos tiene una estructura de dos niveles: la estructura lógica (por ejemplo la estructura de
los datos como la ve el programador) y la estructura física (por ejemplo la estructura de los datos
como la ve el computador).
La propuesta de la ANSI/X3/SPARC tiene una estructura de tres niveles: esquema externo,
esquema conceptual y esquema interno (ver figura 12). El esquema externo (esquema del usuario)
representa el punto de vista del usuario (por ejemplo del programador). En otras palabras, un
esquema externo es una descripción de datos visibles a un programa de aplicación en términos de
nombres y características del dato. El esquema interno representa la organización física de los datos
en los equipos de almacenamiento. También contiene los detalles de integridad, recuperación y
eficiencia en los procesos de obtención y actualización de datos. El esquema conceptual representa el
punto de vista de empresa. O sea una descripción del modelo de la empresa en términos de sus
entidades, atributos y relaciones entre ellos. También contiene los requerimientos para las
operaciones permitidas, integridad semántica y privacidad. El esquema conceptual está orientado a
proveer un punto de vista estable del dato.
2.2 Esquema conceptual y esquema de empresa.
Cuál es la diferencia entre esquema conceptual propuesto por el grupo ANSI/X3/SPARC y el

esquema empresa discutido en esta publicación? La respuesta es que ellos son los mismos excepto
que el esquema conceptual se requiere como interfase entre el esquema externo y el interno (ver
figura 12).
Página 1
Figura 13 Traducciones necesarias entre el esquema externo y el esquema interno sin un
modelo conceptual.
Página 1
Figura 14 Uso del esquema conceptual como interfaz entre los esquemas externo e
interno.
Una razón para usar el esquema conceptual como interfase es para reducir el número de mapeos
entre el esquema externo e interno. Por ejemplo, si hay M esquemas externos y N esquemas internos,
se necesitan M*N programas para hacer el mapeo entre los esquemas externos e internos (ver figura
13). Si hay un esquema conceptual entre los esquemas externos e internos, M+N programas para
hacer el mapeo (figura 14). Por lo tanto, el número de programas de mapeo se reduce
considerablemente.
Uno de los objetivos de la arquitectura ANSI/X3/SPARC es mantener el esquema conceptual

estable mientras se permite cambios en los esquemas externos e internos. Este objetivo no parece
difícil de obtener ya que el esquema conceptual representa la vista de empresa del dato y debe ser
relativamente estable comparado con la vista del usuario de la vista física del dato. Por lo tanto,
cuando la organización física de la base de datos es cambiada o el dato es pasado de un tipo viejo de
almacenamiento a uno nuevo, solamente se cambiará el esquema interno, y no el esquema conceptual
o el externo. Similarmente, si el usuario quiere ver el dato como una cierta clase de organización, se
puede diseñar un esquema externo para él sin cambiar el esquema conceptual ni el esquema interno.
Página 1
Figura 15 El esquema externo se puede representar con diferentes tipos de estructura de
datos.
Página 1
Además de servir como interfase entre los esquemas externo e interno, el esquema conceptual es
el mismo esquema de la empresa, y se pueden usar los diagramas Entidad-relación para describir el
esquema conceptual. En adición, ya que el esquema externo se puede expresar en términos de
diferentes tipos estructuras de datos tales como red (CODASYL), jerárquica, o relacional (ver figura
15), las reglas de traslación entre los diagramas de Entidad-Relación y los diferentes tipos de
estructuras de datos se verán más adelante en esta publicación y serán muy útiles en la
implementación de la arquitectura ANSI/X3/SPARC.
2.3 Tres tipos de administradores de base de datos.
El grupo ANSI/X3/SPARC ha identificado tres tipos de administradores de base de datos:
(1) Administrador empresa
El administrador empresa define el esquema conceptual y, si es posible, lo valida. El debe entender

muy bien ambos las operaciones de la empresa y el significado de su información (dato). Es el
responsable por la integridad, contenido y seguridad de la base de datos.
(2)Administrador de la base de datos.
El administrador de la base de datos define el esquema interno. El diseña la estructura física, esquema
de codificación, caminos de acceso, y ubicación de un dato en la unidad de almacenamiento. Es el
responsable por la utilización eficiente del espacio de almacenamiento como del comportamiento
eficiente del sistema de la base de datos.
(3)Administrador de la aplicación.
Un esquema externo representa la vista del programador de la aplicación. Esto lleva a que cada área
de aplicación general tendrá su propio administrador de la aplicación quien provee el esquema
externo para esa área. Pero estos esquemas externos deben ser consistentes y derivables de un simple
esquema conceptual. Nótese que el mismo esquema externo puede ser usado por varios
programadores , no necesariamente trabajando en el mismo programa.
Estos tres tipos de administradores representan tres diferentes trabajos que deben ser realizados
por un individuo o un grupo de personas. Aunque las distinciones entre estos tres tipos de
administradores de base de datos es clara en términos del triple esquema de arquitectura
ANSI/X3/SPARC, esto no es claro en ambientes de bases de datos convencionales. Como es el caso,
el "administrador de la base de datos" como se define en muchas organizaciones de bases de datos,
tiene toda la responsabilidad mencionada para los tres tipos de administradores.En términos del
objetivo de ésta publicación, primero se tratará con la responsabilidad de el administrador de empresa
(por ejemplo el trabajo de modelar el mundo real) y la responsabilidad del administrador de la
aplicación (por ejemplo el trabajo del diseño del esquema externo).
2.4 Importancia del enfoque E-R.
Página 1
En resumen, La arquitectura ANSI/X3/SPARC llegará a ser realidad, y el enfoque E-R podrá ser
usado en los siguientes casos:
(1) En el diseño del esquema conceptual.
(2) En la traslación del esquema conceptual al esquema externo.
3. DIAGRAMA ENTIDAD -RELACION (E-R).
En este capitulo, se introduce la técnica de diagramación de entidad-relación. Primero se discutirá

que son entidad y relación y entonces explicar como se describe las propiedades de entidad y
relación.
3.1 ENTIDAD Y RELACION.
Figura 16 Tipos de entidades y entidad.
Página 1
Figura 17 Entidades representadas en cajas rectangulares.
Una entidad es una "cosa" quien puede ser claramente identificada. Las entidades pueden
clasificarse en diferentes tipos de entidades, tales como EMPLEADO y BODEGUERO (ver figura
16). En el diagrama E-R, un tipo de entidad esta representado por caja rectangular (ver figura 17).
Hay muchas "cosas" en el mundo real. Algunas de estas son de interés de la empresa, y el resto
no. Es responsabilidad del diseñador seleccionar los tipos de entidades que sirven para su compañía.
3.1.2 tipo de relación.
Figura 18 Matrimonio representado como relación entre dos personas de una entidad.
Página 1
Figura 19 Relaciones representadas como diamantes.
Las relaciones existen entre las entidades. Por ejemplo, MATRIMONIO es una relación entre dos
entidades personas (ver figura 18). Las relaciones se pueden clasificar en tipos de relaciones. Por
ejemplo, PROYECTO-EMPLEADO y PROYECTO-ADMINISTRADOR son dos tipos diferentes
de relaciones entre dos tipos de entidades PROYECTO y EMPLEADO. En la notación de
diagramación entidad-relación, un tipo de relación es representada por una caja en forma de diamante
con líneas que conectan las entidades relacionadas (ver figura 19). La notación "m" y "1" asociada
con el tipo de relación PROYECTO-ADMINISTRADOR en la figura 16 indica que cada proyecto
tiene un solo gerente, pero que un empleado puede ser el gerente de muchos proyectos. La "m" y "n"
asociada con el tipo de relación PROYECTO-EMPLEADO indica que hay muchos a muchos
mapeos. Esto es, cada proyecto puede consistir de varios empleados, y cada empleado puede estar
asociado con varios proyectos. Nótese que más mapeos entre entidades es posible. Como caso, el
tipo de relación MATRIMONIO es un mapeo uno a uno entre personas (entidades) ver figura 20.
Página 1
Figura 20 Matrimonio representado como relación entre dos personas de la entidad
Persona.
Figura 21 Información sobre la relación Parte-proveedor-proyecto.
Es posible definir un tipo de relación entre dos tipos de entidades . Por ejemplo,
PARTE-PROVEEDOR-PROYECTO , quien describe que partes son suministradas por un particular
a un proyecto (figura 21), es un tipo de relación definida sobre tres entidades: PARTE,
PROVEEDOR, y PROYECTO (figura 22).
Página 1
Figura 22 Relación Parte-proveedor-proyecto.
Figura 23 Información de las relaciones binarias: Parte-proveedor, Proveedor-proyecto y

Proyecto-parte.
Página 1
Note que una relación triple usualmente no puede ser representada por tres relaciones binarias.
Ejemplo, la relación triple PARTE-PROVEEDOR-PROYECTO en la figura 21 es reemplazado por
tres relaciones binarias: PARTE-PROVEEDOR, PROVEEDOR-PROYECTO, Y
PROYECTO-PARTE (ver figura 23). Sin embargo, si se quiere construir una relación triple
comenzando con estas tres relaciones binarias, se obtienen cosas "nuevas" (ver figura 24 entradas).
Figura 24 Información generada de las tres relaciones binarias mostradas en la figura

23.
Hay muchos tipos de relaciones entre entidades, y algunas de ellas son de interés a la empresa; el
diseñador de la base de datos es el responsable por la selección de las relaciones importantes a la
empresa. Debe también especificar el tipo de mapeo de las relaciones (por ejemplo uno a uno, uno a
varios, varios a varios).
3.2 Descripción de entidades y relaciones.
Página 1
Figura 25 Atributos y sus valores.
Las entidades y las relaciones tienen propiedades, que pueden ser expresadas en términos de pares
valor-atributo. Por ejemplo, en la afirmación " la edad de un empleado X es 24", "edad" es un
"atributo" del empleado X, y "24" es el "valor" del atributo edad. Los valores pueden ser clasificados
en diferentes tipos de valores como NO-DE-AÑOS, CANTIDAD, y COLOR. En la notación de
diagrama E-R, un tipo de valor es representado por un circulo (ver figura 25) y un atributo es
representado por una flecha dirigida de la entidad al valor deseado.
En algunos casos, un atributo puede tener más de un valor para una entidad dada. como puede
ser, "TELEFONO" del empleado X puede tener dos valores: 2684062 y 2680603. En este caso, se
coloca "1:n" en la flecha para indicar que es un atributo de múltiples valores. Esto es similar al
concepto de "grupo repetitivo" en el procesamiento de datos convencional. Sin embargo, muchos
atributos, tales como "edad" y "IDENTIFICACION" son valores simples. Por simplicidad, no se
asocia "1:1" en las flechas del diagrama E-R para estos atributos.
Página 1
Figura 26 Atributos de una relación.
Hasta ahora sólo se han considerado los atributos de las entidades. Algunos veces nos interesa las
propiedades de las relaciones, como cuando se quiere conocer cuándo el empleado X comenzó a
trabajar en un proyecto en particular. El FECHA-INICIO no es un atributo del empleado ni del
proyecto, ya que el valor depende de ambos del trabajador y del proyecto. Por lo tanto, FECHA-
INICIO es un atributo de la relación PROYECTO-EMPLEADO. Otro ejemplo de atributo de
relación es el PORCENTAJE-DE-ESFUERZO, que es el porcentaje de tiempo que un trabajador
dedica a un proyecto en particular (ver figura 26). El concepto de atributo de relación es importante
para entender la semántica del dato. El concepto es similar al "dato relacionado" en "red"
(CODASYL) sistemas de base de datos y similar al "dato intersección" en los sistemas de base de
datos jerárquicos (IMS).
3.2.2 Identificador entidad.
La entidad hasta el momento vista existe en la mente o puede ser identificada colocando el dedo
sobre él. Cuando alguien pregunta "Esto de qué color es?" "Esto" es entendido por ambos
interlocutores o es identificado colocando el dedo sobre el objeto. Este esquema de identificación
trabaja para muy pocos objetos, y caerá en dificultades cuando se quiere comunicar esta información
de una variedad de objetos a mucha gente. Por lo tanto, en ambos en la conversación diaria o en el
Página 1
procesamiento de datos en el computador, se necesita otro esquema para identificar las entidades.
Cada entidad tiene muchos atributos, pero cual debe escoger? La respuesta es que los atributos
escogidos sean capaces de identificar absolutamente la entidad. Se da el caso, se puede usar el
atributo NOMBRE para identificar los empleados de una pequeña empresa, pero no para una grande.
Esta selección de los atributos de la entidad se llaman identificadores de la entidad. En algunos casos,
puede ser difícil o inconveniente usar atributos disponibles como identificadores de la entidad. En
cambio es mejor crear un atributo artificial capaz de identificar bien la entidad. Ejemplos son
"IDENTIFICACION", "EMPLEADO-NO", y "PROYECTO-NO" . El concepto de identificador de
entidad es similar al concepto de "llave primaria" en el procesamiento de datos convencional.
3.2.3 Identificador de relación.
Las relaciones son identificadas por el uso de los identificadores de las entidades involucradas en
las relaciones. Por ejemplo, si un proyecto es identificado por su PROYECTO-NO y un empleado es
identificado por EMPLEADO-NO, entonces la relación PROYECTO-EMPLEADO es identificado
por ambos PROYECTO-NO y EMPLEADO-NO. En algunas situaciones, un tipo de relación es
definido entre dos ocurrencias de el mismo tipo de entidad. Es el caso, de MATRIMONIO es un tipo
de relación definido entre ocurrencia del mismo tipo de entidad, PERSONA. En orden a identificar
positivamente tales relaciones, no solamente se usará el identificador de la entidad sino también el
papel que juega la entidad en la relación. En el caso de MATRIMONIO, los nombres MARIDO y
MUJER son los papeles que ellos juegan en la relación MATRIMONIO.
3.3 Tipos especiales de entidades y relaciones.
En este numeral se discuten algunos tipos especiales de entidades y relaciones que se encuentran
comúnmente.
3.3.1 Dependencia de existencia.
La existencia de una entidad depende de la existencia de otra entidad. Por ejemplo, la existencia
de entidad HIJO en una base de datos depende de la existencia de el empleado asociado. En otras
palabras, si un empleado deja la compañía, no se mantendrá más la información de sus hijos.
Página 1
Figura 27 Relación dependiente de existencia.
La figura 27 ilustra el diagrama E-R para esta situación. HIJO es representado por una caja
rectangular doble, que significa que es un tipo de entidad "débil". La existencia de una entidad débil
depende de la existencia de otras entidades. La "E" dentro de la caja de relación indica que es una
relación existencia dependiente; la flecha asociada indica la dirección de dependencia.
Figura 28 Relación dependiente de existencia con mapeo muchos a muchos.
Es posible que la relación "dependencia de existencia" es un mapeo de varios a varios. Por

ejemplo, si el padre deja la compañía, el HIJO puede permanecer si la madre continua trabajando en
la compañía. Esta situación se representa en el diagrama E-R mostrada en la figura 28.
3.3.2 Dependencia ID.
Página 1
Figura 29 Dependencia de existencia e identificación.
Página 1
Si una entidad no puede ser identificada únicamente por sus atributos y tiene que ser identificado
por sus relaciones con otras entidades, tiene una dependencia ID sobre otras entidades. Por ejemplo,
"CALLE" es única dentro de una ciudad, ciudad es única dentro de un estado, y estado es única
dentro de un país. En orden de identificar la dirección de un local, se debe especificar el nombre de la
ciudad, estado, y país adicionalmente a la calle. L dependencia ID es indicada por la caja de relación
"ID" y la dirección de la relación es indicada por la flecha (ver figura 29); muchas de las
Página 1
dependencias ID son asociadas con las dependencias de existencia. Sin embargo, la dependencia de
existencia no implica dependencia de ID. Por ejemplo, la entidad HIJO en la figura 30 es identificado
por sus atributos y de sus padres ID (ver figura 31), mientras la entidad HIJO en la figura 27 puede
ser identificado por su HIJO-NO (figura 32).
Figura 32 Sin dependencia de identificación.
4. PASO DEL DIAGRAMA E-R A DIAGRAMAS DE ESTRUCTURA-DATO.
4.1 Diagramas de estructura - dato.
Página 1
Figura 33 Diagrama de estructura de estructura de datos.
Las estructuras lógicas de las bases de datos soportadas por sistemas de base de datos
CODASYL (red) pueden ser expresados en diagramas de estructuras - dato. La figura 33 ilustra un
diagrama de estructura - dato. Cada caja rectangular representa un tipo de registro, como
EMPLEADO y DEPARTAMENTO. La flecha representa un conjunto de estructura - dato que
conecta los dos registros. El registro donde se origina la flecha es el registro amo del conjunto de
estructura - datos, y el registro en donde la flecha termina es el registro miembro del conjunto
estructura de datos. En la figura 33, EMPLEADO es el registro amo, DEPARTAMENTO es el
registro miembro. En un conjunto de estructura - datos, el registro amo tiene cero, uno, o más
registros miembros (ocurrencias). Un registro miembro en un conjunto estructura-dato tiene
exactamente un registro amo. En nuestro ejemplo, cada registro EMPLEADO puede ser conectado a
varios registros DEPARTAMENTO, o a ninguno. Sin embargo, cada registro DEPARTAMENTO
debe ser asociado con exactamente con un registro EMPLEADO. Esto se ilustra en la figura 34.
Conceptualmente, la flecha representa una asociación 1:n (uno-a-varios) entre el registro amo y el
registro miembro. Esta clase de asociación puede ser también representado en forma de tabla (figura
35).
Página 1
Figura 34 Registro propietario con cero, uno o muchos registros miembros.
Página 1
Figura 35 Correspondencia uno a muchos entre Empleado y Dependencia.
Página 1
Figura 36 Dos estructuras de datos apuntando al mismo registro miembro.
La figura 36 ilustra una estructura de datos más complicada. El tipo de registro EMPLEADO es
el tipo de registro amo del conjunto estructura-dato, en el cual EMPLEADO-LENGUAJE es el tipo
de registro miembro. El tipo de registro EMPLEADO-LENGUAJE es también un tipo de registro
miembro de otro conjunto estructura-dato, en el cual el tipo de registro LENGUAJE es un registro
amo. Actualmente, el registro EMPLEADO-LENGUAJE contiene una información de referencia
cruzada acerca de EMPLEADOS y LENGUAJE. Esta información puede ser representada en forma
de tabla, como se muestra en la figura 37.
Página 1
Figura 37 Referencia cruzada de empleado y lenguaje.
Se puede apreciar de la figura 37 que un empleado puede tener uno o más lenguajes, y que
usualmente más de un empleado tiene un lenguaje particular. Por lo tanto, la relación entre
empleados y lenguajes es m:n (muchos-a-muchos). Esta correspondencia m:n entre empleados y
lenguajes puede derivarse de la figura 36. El conjunto estructura-dato en la figura 36 muestra que
existe un mapeo 1:m (uno-a-muchos) entre el tipo de registro EMPLEADO y el tipo de registro
EMPLEADO-LENGUAJE, y un mapeo similar (1:n) existe entre el tipo de registro LENGUAJE y
el tipo de registro EMPLEADO-LENGUAJE. Por lo tanto, la correspondencia entre el registro
EMPLEADO y el tipo de registro lenguaje es m:n (muchos-a-muchos).
El diagrama estructura-dato en la figura 36 puede ser implementado usando una matriz de

apuntadores como se muestra en la figura 38. El conjunto estructura-dato entre el tipo de registro
EMPLEADO y el tipo de registro EMPLEADO-LENGUAJE es representado por líneas salidas, y el
conjunto estructura-dato entre el tipo de registro LENGUAJE y el tipo de registro
EMPLEADO-LENGUAJE es representado por líneas punteadas.
Página 1
Figura 38 Implementación de la estructura de datos mostrada en la figura 37 utilizando
apuntadores.
En la figura 38, cómo se determinan los lenguajes de un empleado particular? El primer paso es
localizar el registro EMPLEADO con EMPLEADO-NO =2142 usando un algoritmo de hashing o
con algún otro método. El segundo paso es encontrar el primer registro EMPLEADO-LENGUAJE
relacionado con este empleado. Por vía de un apuntador mostrado en línea punteada, puede
encontrar un registro lenguaje con LENGUAJE-NOMBRE= COBOL. Luego se encuentra el
segundo registro EMPLEADO-LENGUAJE relacionado con el mismo registro de empleado (vía
apuntadores de línea salida). Desde el registro EMPLEADO-LENGUAJE, se puede ir a través del
apuntador de línea punteada a localizar un registro LENGUAJE con LENGUAJE-NOMBRE= PL/1.
No se pueden encontrar más registros EMPLEADO-LENGUAJE relacionados con los mismos
registros EMPLEADO (por ejemplo, se ha encontrado la información que se requería: el empleado
EMPLEADO- NO=2142 tiene dos lenguajes: COBOL y PL/1.
Cómo se encuentran todos los empleados con un lenguaje particular, por ejemplo COBOL?
primero, se localiza el registro LENGUAJE con LENGUAJE-NOMBRE= COBOL. Luego se
recuperan todos los registros EMPLEADO-LENGUAJE relacionados con el registro LENGUAJE.
Para cada registro EMPLEADO-LENGUAJE, se recupera vía apuntadores de línea salida el
correspondiente registro EMPLEADO. Haciendo esto, se sabe que hay dos empleados poseyendo la
lenguaje COBOL, y sus números de empleado son 2142 y 1781.
Página 1
Figura 39 Implementación de la estructura de datos de la figura 22 utilizando cadenas.
Otro modo de implementar el diagrama de estructura-dato en el figura 36, es usar "cadenas"

como se muestra en la figura 39. Las líneas sólidas conectan todos los registros
EMPLEADO-LENGUAJE relacionados con el mismo registro EMPLEADO. Las líneas punteadas
conectan todos los registros EMPLEADO-LENGUAJE relacionados con el mismo registro
LENGUAJE. Cómo encontrar las lenguajes de un empleado con EMPLEADO-NO=2142? Primero
se encuentra el primer registro EMPLEADO-LENGUAJE vía la cadena de línea sólida. Desde el
registro EMPLEADO- LENGUAJE, se encuentra el registro lenguaje vía la cadena punteada. Desde
el registro EMPLEADO-LENGUAJE, se busca el próximo registro EMPLEADO- LENGUAJE vía
la cadena de línea sólida. Desde el segundo registro EMPLEADO-LENGUAJE, se puede determinar
el correspondiente registro LENGUAJE a través de la cadena de línea punteada. Desde el segundo
registro EMPLEADO-LENGUAJE, no se pueden encontrar más registros
EMPLEADO-LENGUAJE en la cadena de línea sólida. Ahora, se conocen todos los lenguajes que
tiene el empleado 2142. Similarmente, se pueden encontrar a todos los empleados con una lenguaje
moviéndonos a través de las cadenas.
Página 1
Figura 40 Dos estructuras de datos que tienen los mismos registros propietario y
miembro.
Figura 41 Relación de manufactura entre partes.
Página 1
Figura 42 Implementación de la estructura de datos de la figura 41.
Página 1
Otro tipo de estructura de datos, que son usualmente encontradas en bases de datos comerciales,
es mostrada en la figura 40. Hay dos tipos de registros: PARTE y RELACION-FABRICACION
(relación- manufactura). Cada producto a ser manufacturado consiste de muchas "partes"
(componentes). Cada parte es a su turno realizada con otras partes. El tipo de registro PARTE
contiene información acerca de una "parte" particular. El tipo de registro RELACION-
FABRICACION contiene la información acerca de la relación entre las partes. La figura 41 ilustra
esta clase de relaciones. Allí se indica que en orden a manufacturar PARTE#1 se necesitan cinco
PARTE#2 y dos PARTE#3. Se puede ver también que PARTE#3 es una sub-parte de ambos
PARTE#1 y PARTE#4. Hay dos conjuntos de estructura-dato en la figura 40 y ellos pueden ser
implementados como "cadenas" como se muestra en la figura 42. Las líneas sólidas representan el
encadenamiento a COMPONENTE y las líneas punteadas representan la cadena USADA-EN. En
orden a saber los componentes de una parte particular, primero se recuperan todos los registros
RELACION-FABRICACION vía el encadenamiento COMPONENTE y luego se recuperan las
correspondientes sub-partes vía la cadena USADA-EN. Haciendo esto, se puede averiguar que
PARTE#4 consiste de una PARTE#3 y dos PARTE#5. En orden a encontrar cuándo una parte
particular es usada para manufacturar otras partes , primero se recuperan todos los registros
RELACION-FABRICACION relacionados con aquel registro particular PARTE vía la cadena
USADA-EN, y luego se recuperan los correspondientes registros PARTE vía el encadenamiento
COMPONENTE. Haciendo esto, se puede averiguar que dos PARTE#5 son usadas en la
manufacturación de PARTE#4.
Las figuras 33, 36, y 40 son los tipos básicos de diagramas de estructura-dato. Una base de datos
se puede expresar en un gran diagrama de estructura-dato basado en estos tres bloques básicos de
construcción.
4.2 Reglas de Traducción.
Como se ha visto en la sección precedente, los diagramas estructura-dato están más próximos a la
organización física de una base de datos, que los diagramas de entidad-relación. Usualmente es difícil
dibujar un diagrama estructura-dato para las entidades y relaciones que son de interés para la
empresa. Por lo tanto, se propone que el diseñador de la base de datos primero dibuje un diagrama
E-R que represente la visión de la empresa sobre los datos y que luego los traslade a un diagrama
estructura-dato. En este numeral se discute cómo trasladar un diagrama E-R en un diagrama
estructura-dato. Se Identifican varias reglas básicas de traducción basadas en el tipo de relaciones
entre entidades. Se empieza con relaciones definidas entre dos tipos de entidades, luego con
relaciones definidas con más de dos tipos de entidades, y finalmente relaciones del mismo tipo de
entidad. Las siguientes son las reglas de traducción:
Página 1
Figura 43
Figura 44
(1) Relaciones definidas sobre dos tipos de entidades diferentes:
Página 1
(a)La relación es una correspondencia uno-a-muchos (o uno-a-uno). Por ejemplo, el tipo de
relación DEPARTAMENTO- EMPLEADO en la figura 43(a) es una correspondencia uno-a-
muchos y puede ser transformada en un diagrama de estructura-dato mostrado en la figura 43(b).
Note que los tipos de entidad como DEPARTAMENTO y EMPLEADO en el diagrama E-R son
tratados como tipos de registro en el diagrama estructura-dato, mientras el tipo de relación
DEPARTAMENTO-EMPLEADO es representada por un conjunto estructura-dato(una flecha) en el
diagrama estructura-dato. Similarmente, el tipo de relación PROYECTO-ADMINISTRADOR en la
figura 44(a) que restringe a un gerente por proyecto pero permite que múltiples proyectos tengan un
mismo gerente, es representado por una flecha en el diagrama de estructura-dato mostrado en la
figura 44(b).
Figura 45
Página 1
Figura 46
(b)La relación es una correspondencia muchos-a-muchos. Por ejemplo, el tipo de relación

PROYECTO-EMPLEADO en la figura 45(a) es una correspondencia muchos-a-muchos. El
correspondiente diagrama estructura-dato es mostrado en el figura 45(b). Note que el tipo de
relación PROYECTO-EMPLEADO no es trasladado en una flecha, sino en un tipo de registro. Se
puede concluir que si el tipo de relación es una correspondencia de muchos-a-muchos, será
trasladada en un tipo de registro con dos flechas señalando desde los tipos de registros relacionados.
El tipo de registro PROYECTO- EMPLEADO usualmente es llamado un "tipo de registro
relacional". Un ejemplo similar es mostrado en la figura 46. Desde que el tipo de relación
EMPLEADO-LENGUAJE es una correspondencia muchos-a-muchos, ella es trasladada a un tipo
de registro(relacional) en el diagrama estructura-dato.
(2) Relaciones definidas en más de dos tipos de entidades:
Página 1
Figura 47
En este caso el tipo de relación en el diagrama E-R será trasladado en un tipo de registro relacional
en el diagrama estructura-dato, no importa que la relación sea una correspondencia uno-a-muchos, o
de otro tipo. Por ejemplo, el tipo de relación PARTE-PROYECTO-PROVEEDOR en la figura 47(a)
es un tipo de relación definido por tres tipos de entidad y será trasladado en un tipo de registro en un
diagrama estructura-dato como el mostrado en la figura 47(b).
(3)Relaciones binarias definidas sobre el mismo tipo de entidad:
Página 1
Figura 48
Página 1
Figura 49
Si la relación binaria es una correspondencia uno-a- muchos, tal como el tipo de relación
ADMINISTRADA en la figura 48(a), esta puede ser transformada en al menos dos posibles
diagramas estructura-dato como se muestra en la figura 48(b) y 48(c). Como la mayoría de los
sistemas de base de datos tipo CODASYL (red) no permiten que el mismo tipo de registro sea usado
tanto como el tipo de registro a uno y como tipo de registro miembro en un conjunto de
estructura-dato, la figura 48 (b) es ilegal. Por lo tanto, se usa la figura 48 (c) como el diagrama
estructura-dato contraparte del diagrama E-R en la figura 48 (a).Para relaciones binarias con otros
tipos de correspondencia, se usa el mismo tipo de diagramas estructura-dato. Por ejemplo
RELACION-FABRICACION es una relación con tipo de correspondencia muchos-a-muchos, y es
equivalente al diagrama estructura-dato mostrado en la figura 49 (b).
V. PASOS EN EL DISEÑO LOGICO DE BASE DE DATOS Y EJEMPLOS.
En este numeral primero se delinean los grandes pasos en el diseño lógico de una base de datos, y
luego se dan tres ejemplos de diseño de base de datos usando la aproximación E-R.
5.1 Grandes pasos en el diseño lógico de base de datos.
La aproximación entidad-relación al diseño de bases de datos consiste de los siguientes pasos:

(1) Identificar los tipos de entidad.
Página 1
(2) Identificar los tipos de relación.
(3)Dibujar diagrama E-R con tipos de entidad y relación.
(4) Identificar tipos de valores y atributos.
(5) Trasladar diagramas E-R a diagramas estructura-dato.
(6) Diseñar formatos de registros.
5.2 Ejemplo 1: Una compañía manufacturera.

5.2.1 Identificar los tipos de entidad.
El primer paso es identificar los tipos de entidad de interés para la compañía. En una empresa
manufacturera. los tipos de entidades primarios son PARTE, PROVEEDOR, PROYECTO,
EMPLEADO, DEPARTAMENTO. Hay otros tipos de entidades que pueden ser de interés para una
empresa manufacturera, pero por simplicidad, solo se toman estos tipos importantes de entidad.
5.2.2 Identificar los tipos de relación.
Página 1
Figura 50 Diagrama ER para una empresa de manufactura.
Página 1
Se puede al menos identificar los siguientes tipos de relación (ver figura 50):
(a)El tipo de relación DEPARTAMENTO-EMPLEADO describe la afiliación de los departamentos

con los empleados y es un mapeo uno-a- muchos.
(b)El tipo de relación PROYECTO-EMPLEADO describe la afiliación de los proyectos con los
empleados y es un mapeo muchos-a- muchos. Esto es, cada empleado puede trabajar en más de un
proyecto y cada proyecto puede involucrar a más de un empleado.
(c)El tipo de relación PROYECTO-ADMINISTRADOR identifica los gerentes de los proyectos y es
un mapeo uno-a-muchos. Esto es, cada proyecto tiene un solo gerente, pero cada empleado puede
estar asociado con más de un proyecto.
(d)El tipo de relación PROYECTO-PROVEEDOR-PARTE describe cuál proveedor provee cual
producto para un proyecto en particular y es un mapeo muchos-a-muchos de tres vías. Esto es, para
una parte particular puede haber más de un proveedor que puede proveer esta parte a más de un
proyecto. Similarmente, cada proyecto puede usar más de una parte, la cual puede tener más de un
proveedor.También, cada proveedor puede proveer a un proyecto con más de una parte. Una razón
para que la empresa desee buscar diferentes proveedores para la misma parte usada por diferentes
proyectos es que en un proyecto particular la empresa pudiera necesitar la parte inmediatamente y
por tanto estar dispuesta a pagar más por ella, comprándola en una compañía local. En general, este
tipo de relación de tres vías no puede ser reemplazada por tres relaciones binarias tales como
PROYECTO- PROVEEDOR, PROVEEDOR-PARTE, PARTE-PROYECTO.
(e)El tipo de relación POTENCIAL-PROVEEDOR guarda una lista de proveedores potenciales para
una parte particular y es un mapeo muchos-a-muchos. Esto es, cada parte puede tener más de un
proveedor potencial y cada proveedor puede ser capaz de suplir más de una parte.
(f)El tipo de relación INVENTARIO guarda la pista de cuál parte es almacenada en cuál depósito y
es mapeo muchos-a- muchos.
5.2.3 Dibujar diagrama E-R con tipos entidad y relación.
El tercer paso es dibujar un diagrama E-R con los seis tipos de entidad y los siete tipos de relación
mencionados arriba. Ciertamente, se pueden identificar tipos de entidades y relaciones diferentes a
los mencionados arriba. Sin embargo, desde que nuestro propósito es introducir los conceptos claves
de la aproximación entidad-relación, no se entra en mayores detalles al respecto. El lector de esta
publicación puede agregar más tipos de entidad y de relación a la figura 50 para satisfacer sus propias
necesidades.
5.2.4 Identificar tipos de valores y atributos.
El cuarto paso es identificar las propiedades de las entidades y de las relaciones que son de interés
para la empresa. Esto es, se quieren identificar atributos y tipos de valores para las entidades y
relaciones en la figura 50.
Página 1
Figura 51 Atributos y valores de entidades y relaciones.
Página 1
Figura 52 Versión simplificada de la figura 51.
Se comienza con los tipos de entidad DEPARTAMENTO y EMPLEADO y su relación

DEPARTAMENTO-EMPLEADO. La figura 51 ilustra los atributos y tipos de valores para
DEPARTAMENTO y EMPLEADO. Los tipos de entidad y los tipos de relación están en el dominio
conceptual superior, y los atributos y tipos de valores están en el dominio conceptual inferior. En la
figura 51 se han identificado los siguientes tipos de valores: DEPARTAMENTO-NO,
PRESUPUESTO, EMPLEADO-NO, FECHA, SUELDO, TELEFONO; DEPARTAMENTO tiene
tres atributos: DEPARTAMENTO-NO, PRESUPUESTO-DE-ESTE-AÑO, y PRESUPUESTO-
DEL-AÑO-PASADO; EMPLEADO tiene cinco atributos: EMPLEADO-NO, FECHA-
NACIMIENTO, SUELDO, TELEFONO-CASA, TELEFONO-OFICINA. Note que los atributos
pueden no tener el mismo nombre que los tipos de valores y de que es posible tener más de un
atributo relacionado con el mismo tipo de valor. Por ejemplo, PRESUPUESTO-DE-ESTE-AÑO y
PRESUPUESTO-DEL-AÑO-PASADO de DEPARTAMENTO usa el mismo tipo de valor
PRESUPUESTO, otro ejemplo son los atributos TELEFONO-OFICINA Y TELEFONO-CASA de
EMPLEADO, los cuales tienen el mismo tipo de valor TELEFONO. Para simplificar el diagrama, se
omiten los nombres de atributo en el diagrama si ellos son iguales a los tipos de valores. Entonces, la
figura 52 es una versión simplificada de la figura 51.
Ahora, se consideran los tipos de entidad PROYECTO y EMPLEADO y sus tipos de relaciones
PROYECTO-ADMINISTRADOR y PROYECTO-EMPLEADO. Hay cinco tipos de valores:
%ESFUERZO, FECHA, PROYECTO-NO, PRESUPUESTO, PROYECTO-NOMBRE. Hay
también cinco atributos en la figura 53 (aún cuando algunos nombres de atributos se omitieron en el
diagrama): %ESFUERZO, FECHA-INICIO-PROYECTO, PROYECTO-NO, PRESUPUESTO,
PROYECTO-NOMBRE. Note que la relación PROYECTO-EMPLEADO tiene dos atributos:
FECHA-INICIO-PROYECTO y %ESFUERZO. El FECHA-INICIO-PROYECTO, es la fecha en la
Página 1
cual el empleado empezó a trabajar en un proyecto particular y %ESFUERZO es el porcentaje de
tiempo que se espera que un empleado gaste en un proyecto particular. Note que el tipo valor
PRESUPUESTO es el mismo que el tipo de valor PRESUPUESTO en la figura 52. Por lo tanto, se
puede decir que los atributos nos pueden ayudar a interpretar el significado de los valores.
Figura 53 Atributos y valores de una entidad y una relación de especial interés.
Página 1
Figura 54 Atributos y valores para Proveedor, Parte y Proyecto-proveedor-parte.
La figura 54 ilustra los tipos de valor y los atributos para los tipos de entidades PROVEEDOR y
PARTE y los tipos de relación PROYECTO- PROVEEDOR-PARTE y
POTENCIAL-PROVEEDOR. La entidad PROVEEDOR tiene dos atributos: PROVEEDOR-NO y
DIRECCION. La entidad PARTE tiene los atributos PARTE-NO, PESO, y COLOR. La relación
PROYECTO-PROVEEDOR-PARTE tiene el atributo CANTIDAD el cual es la cantidad de cierta
parte proveída por cierto proveedor para un cierto proyecto. La relación
POTENCIAL-PROVEEDOR no tiene un atributo. Los atributos de la entidad PROYECTO ya han
sido mostrados en la figura 53.
Página 1
Figura 55 Atributos y valores de entidades y relaciones.
La figura 55 muestra los atributos y los tipos de valor de las propiedades de la cantidad
ALMACEN y las relaciones INVENTARIO y RELACION-FABRICACION. La cantidad
ALMACEN tiene los atributos ALMACEN-NO Y DIRECCION. La relación INVENTARIO tiene
el atributo CANTIDAD-A-MANO; el cual es la cantidad de una parte almacenada en un deposito.
La relación RELACION-FABRICACION tiene el atributo CANTIDAD-POR-FABRICACION, el
cual es la cantidad de una sub-parte necesitada para fabricar una super-parte. Note que
CANTIDAD-A-MANO y CANTIDAD-POR-FABRICACION comparten el mismo tipo de valor
CANTIDAD.
Las figuras 52-55 ilustran los atributos y los tipos de valor necesitados para describir las
propiedades de las entidades y relaciones que son de interés para la empresa manufacturera.
5.2.5 Trasladar el diagrama E-R en un diagrama estructura-dato.
El quinto paso es trasladar el diagrama E-R en un diagrama estructura-dato usando las reglas de
traducción discutidas en la sección 4.2.
Página 1
Figura 56 Diagrama Estructura-Dato derivado del diagrama ER de la figura 50.
Considere el diagrama E-R en la figura 50. Puede ser trasladado en el diagrama estructura-dato
mostrado en la figura 56. Todos los tipos de entidades en el diagrama E-R comienzan a ser tipos de
registros en el diagrama estructura-dato. Como el tipo de relación DEPARTAMENTO-EMPLEADO
es un mapeo uno-a-muchos, es trasladado en un conjunto estructura-dato (una flecha) en el diagrama
estructura-dato. Similarmente, el tipo de relación PROYECTO-ADMINISTRADOR es también un
mapeo uno-a-muchos y es trasladado en un conjunto estructura-dato. Como el tipo de relación
PROYECTO-EMPLEADO es un mapeo muchos-a-muchos, es trasladado en un tipo de registro con
flechas apuntando desde las entidades relacionadas en forma de tipos de registro EMPLEADO y
PROYECTO. Debido a que el tipo de relación PROYECTO-PROVEEDOR- PARTE es un mapeo
muchos-a-muchos de tres vías, es trasladado en un tipo de registro. El tipo de relación RELACION-
FABRICACION es trasladada en un tipo de registro desde que es un tipo de relación definido en el
mismo tipo de entidad. Note que el tipo de registro RELACION-FABRICACION en la figura 42
tiene dos flechas (p.e. conjunto de estructura-dato) apuntando desde el mismo tipo de registro
PARTE. Note que el tipo de registro PROYECTO-PROVEEDOR-PARTE es apuntado por tres
flechas desde el tipo de registro (entidad) relacionado.
5.2.6 Diseñar formatos de registros.
Página 1
El sexto paso es agrupar atributos de entidades y relaciones en registros y decidir cómo implementar
los conjuntos de estructura- dato (usando "cadenas"? matrices de apuntadores? etc.).
Las pautas básicas para agrupar atributos en registros son:
Figura 57 Registro Departamento.
(1)Todos los atributos de una entidad serán puestos en el mismo tipo de registro, Por ejemplo, los
atributos de DEPARTAMENTO serán tratados como nombres de campos en el tipo de registro
DEPARTAMENTO (vea figura 52 y 57).
Figura 58 Registro Empleado.
(2)Si el tipo de relación es un mapeo uno-a-muchos, los atributos de la relación serán tratados como
campos en el mismo registro miembro del conjunto estructura-dato. Por ejemplo, el tipo de relación
Página 1
DEPARTAMENTO-EMPLEADO (figura 52) es un mapeo uno-a-muchos t su atributo FECHA-
INICIO-EN-DEPARTAMENTO será incluido como un campo en el registro miembro del conjunto
estructura-dato (p.e. el tipo registro EMPLEADO; vea figura 56 y 58).
Figura 59 Registro Proyecto.
Figura 60 Registro Proyecto-empleado.
(3)Si el tipo de relación es trasladado a un tipo de registro, entonces los atributos de la relación serán
tratados como campos en ese tipo de registro. Por ejemplo, el tipo de relación
PROYECTO-EMPLEADO en la figura 53 es trasladado en un tipo de registro y los atributos
%ESFUERZO y FECHA-INICIO-EN-PROYECTO son los campos en el tipo de registro mostrado
en la figura 60.
Página 1
Figura 61 Registro Proveedor.
Figura 62 Registro Parte.
Página 1
Figura 63 Registro Parte-proveedor-proyecto.
Figura 64 Registro Proveedor-potencial.
Se pueden aplicar estas reglas a otros tipos de entidad y de relación. Como todos los tipos de entidad
y de relación, excepto PROYECTO-ADMINISTRADOR en la figura 50, son trasladados
directamente en tipos de registro, la agrupación de atributos en tipos de registros es directa. La figura
53 es trasladada a las figuras 59 y 60. Note que el tipo de relación
PROYECTO-ADMINISTRADOR es trasladado a un conjunto estructura-dato. La figura 54 es
trasladada a las figuras 61-64; la figura 55 es trasladada a las figuras 65 y 66.
Página 1
Figura 65 Registro Almacén.
Figura 66 Registro Inventario.
Después de poner todos los atributos en los tipos de registros, la siguiente cuestión es decidir
como implementar los conjuntos estructura-dato. En este ejemplo de la empresa manufacturera, se
usan "cadenas" como implementación física de los conjuntos estructura-dato. Esto es, se usan las
figuras 39 y 42 como implementación física de las figuras 36 y 40 respectivamente. De estas figuras,
se pueden hacer las siguientes observaciones sobre cómo implementar cadenas de apuntadores:
(1)Si el registro es un tipo de registro amo de un conjunto estructura-dato , debe tener un
apuntador apuntando a la primera ocurrencia de un registro miembro.
(2)Si el registro es un tipo de registro miembro de un conjunto estructura-dato, debe tener un

apuntador apuntando a la próxima ocurrencia de un registro miembro de la misma cadena o a una
ocurrencia de un registro amo, si es el último registro de la cadena.
Página 1
(3)Si un tipo de registro está envuelto en múltiples conjuntos de estructura-dato, debe contener
varios apuntadores, uno para cada conjunto de estructura-dato.
usando estas reglas, pueden definir los apuntadores en los tipos de registro como se muestra en
las figuras 57-66. Primero se considera la figura 57, como el tipo de registro DEPARTAMENTO es
un tipo de registro amo del conjunto estructura-dato, tiene un apuntador apuntando a la primera
ocurrencia del registro EMPLEADO en ese departamento. El tipo de registro EMPLEADO en la
figura 58 tiene tres apuntadores desde que está involucrado en tres conjuntos estructura-dato. Puesto
que el tipo de registro EMPLEADO es un tipo de registro miembro del conjunto estructura-dato
cuyo amo es el tipo de registro DEPARTAMENTO, el tipo de registro EMPLEADO guardará un
apuntador hacia la próxima ocurrencia del registro EMPLEADO en el mismo departamento. Como
el tipo de registro EMPLEADO es el registro amo en el conjunto estructura-dato cuyo tipo de
registro miembro es PROYECTO, él guarda un apuntador a la primera ocurrencia del registro
PROYECTO gerenciado por ese empleado. Si el empleado no es gerente de ningún proyecto, el
valor del apuntador es nulo. Ya que el tipo de registro EMPLEADO es también un tipo de registro
amo del conjunto estructura-dato cuyo tipo de registro miembro es PROYECTO-EMPLEADO, el
mantiene un apuntador a la primera ocurrencia del registro PROYECTO- EMPLEADO en la
cadena..
Ya que PROYECTO-EMPLEADO es un tipo de registro miembro de dos conjuntos de

estructura-datos, el mantiene dos apuntadores; uno apunta a la próxima ocurrencia del registro
PROYECTO-EMPLEADO para el mismo empleado, y el otro apunta a la próxima ocurrencia del
registro PROYECTO-EMPLEADO para el mismo proyecto (ver figuras 56 y 60).
Se considera un caso más complicado: el tipo de registro PROYECTO-PROVEEDOR-PARTE

en la figura 56 y 63. Ya que este es un tipo de registro miembro de tres conjuntos de estructura-dato,
tiene tres apuntadores, uno para cada cadena. Similares explicaciones pueden ser dadas para
apuntadores en otros tipos de registros.
5.3 Ejemplo 2: Una base de datos de pedidos-entradas.
5.3.1 Identificación de los tipos de entidades.
Un pedido-entrada maneja los pedidos de los clientes sobre artículos, quienes pueden ser
almacenados en bodegas. Los tipos de entidades importantes son: CLIENTE, ORDEN, LINEA,
PARTE, ITEM Y ALMACEN (figura 69). Cada "pedido" tiene varias "líneas" , cada una contiene el
numero de la parte y la cantidad ordenada.
5.3.2 Identificación de los tipos de relaciones.
Se pueden identificar los siguientes tipos de relaciones:

(1) La relación CLIENTE-ORDEN describe que cliente hizo un pedido particular y es un mapeo
uno-a-muchos. Esto es, un cliente puede tener muchos pedidos, pero cada pedido solamente un
cliente.
Página 1
(2)La relación ORDEN-LINEA indica que las entidades LINEA son dependiente-existencia y
dependiente ID en la correspondiente entidad de pedido. Cada "pedido" tiene varias "líneas", pero
cada "línea" pertenece solamente a un "pedido".
(3) La relación LINEA-PARTE describe que "parte" esta en la línea del pedido. También describe
la cantidad de las partes pedidas. Esta clase de relación es un mapeo uno-a-muchos; cada "línea"
contiene una sola parte, pero cada parte puede tener muchas líneas (usualmente en diferentes
"pedidos").
(4) La relación INVENTARIO mantiene el seguimiento de que parte es almacenada en cual

bodega, y es un mapeo muchos-a-muchos.
5.3.3 Dibujar un diagrama E-R con los tipos entidad y relación.
Figura 67 Diagrama ER para una base de datos de Ordenes.
La figura 67 es un diagrama E-R para la base de datos pedido-entrada. Note que dos tipos de
entidades PARTE y ALMACEN fueron ya discutidas en el ejemplo 1. Así, es posible unir la figura 67
y 50 para hacer un diagrama E-R grande.
5.3.4 Identificación de valores, tipos y atributos.
Página 1
Figura 68 Atributos y valores de las entidades Cliente y Orden.
La figura 68 muestra los tipos de valores y atributos para los tipos de entidades CLIENTE y
ORDEN. Una entidad CLIENTE tiene cinco atributos: CLIENTE-NO, BALANCE, LIMITE-
CREDITO, DESCUENTO y DIRECCION-ENVIO. Cada cliente puede tener más de una dirección-
de-envío. Una entidad ORDEN tiene tres atributos: ORDEN-NO, DIRECCION-ENVIO, y FECHA.
Cada pedido tiene una sola dirección-de-envío. La relación CLIENTE-ORDEN no tiene atributos.
Página 1
Figura 69 Atributos y valores para Línea y Parte-línea.
La figura 69 ilustra los tipos de valores y atributos de las propiedades de la entidad LINEA y la
relación LINEA-PARTE. La entidad LINEA tiene un atributo: LINEA-NO. La relación
LINEA-PARTE tiene dos atributos: CANTIDAD-SOLICITADA y CANTIDAD-DESPACHADA.
El valor de CANTIDAD-DESPACHADA es inicialmente igual al CANTIDAD-SOLICITADA y
gradualmente se reduce hasta cero a medida que se hacen los envíos.
Los tipos de valores y atributos para PARTE, INVENTARIO, ALMACEN se encuentran en las
figuras 54 y 55.
5.3.5 Trasladar el diagrama E-R a diagrama estructura-dato.
Página 1
Figura 70 Diagrama estructura-dato derivado del diagrama ER de la figura 67.
Usando las reglas de traslación discutidas en la sección 4.2, el diagrama E-R de la figura 67 puede
ser trasladada al diagrama estructura-dato mostrado en la figura 70. Todos los tipos entidades llegan
a ser tipos de registro en el diagrama de estructura-dato. Ya que los tipos de relaciones
CLIENTE-ORDEN, ORDEN- LINEA, LINEA-PARTE son mapeos uno-a-muchos, son trasladados
en conjunto estructura-dato en el diagrama estructura-dato. Ya que el tipo de relación
INVENTARIO es un mapeo muchos-a-muchos, se traslada en un tipo registro.
5.3.6 Diseño del formato de registro.
Página 1
Figura 71 Registro Orden.
Figura 72 Registro Orden.
Página 1
Las figuras 71 y 74 ilustran los formatos de registros para cuatro tipos de registros CLIENTE,
ORDEN, LINEA, y PARTE en la figura 70. El registro LINEA no contiene atributos de la entidad
LINEA, tampoco atributos de la relación LINEA-PARTE (ver figura 69 y 73). En este ejemplo de
base de datos pedido-entrada, se escoge "cadenas" como la implementación física del conjunto
estructura- dato. Los formatos de registro para los tipos de registro ALMACEN y INVENTARIO
se muestran en las figuras 65 y 66. Note que si se fusionan las figuras 56 y 70, se tienen que rediseñar
los formatos de registro para el registro PARTE; esto es, para fusionar la figura 62 con la 74.
5.4 Ejemplo 3: La base de datos de una biblioteca.
5.4.1 Identificación de los tipos de entidades.
Página 1
Figura 75 Diagrama ER para una base de datos de una Biblioteca.
Página 1
Una biblioteca quiere conocer sus libros y proveer un sistema computarizado para la búsqueda de
libros por categorías, palabras claves o autores. tipos de entidades importantes son: LIBRO,
AUTOR, CLAVE, CATEGORIA y EMPLEADO (ver figura 75).
5.4.2 Identificación de tipos de relaciones.
Hay dos clases de relaciones entre las entidades AUTOR y LIBRO. Una es AUTOR-PRINCIPAL, y
el otro es CO-AUTOR (ver figura 75). Cada libro tiene un único autor principal, pero un autor
puede ser autor principal de varios libros. Por otro lado, cada libro puede tener varios co-autores (en
adición al autor principal), y cada autor puede ser co-autor de muchos libros. Hay dos clases de
relaciones entre las entidades CATEGORIA y LIBRO: Una es PRIMER-DIRECTOR, y la otra es
SEGUNDO-DIRECTOR. Cada libro pertenece a una sola categoría primaria pero puede pertenecer
a varias categorías secundarias. Por ejemplo, un libro relacionado con "química física" puede tener
"química" como categoría primaria y "física" como categoría secundaria. Hay también un tipo de
relación llamado SUBCATEGORIA que es definida entre la entidades CATEGORIA ; esto es, cada
categoría puede ser dividida en subcategorías. Por ejemplo, "ciencia" puede ser dividida en "física",
"química", "matemática", etc. Similarmente, hay dos clases de relaciones entre las entidades CLAVE
y LIBRO: una es CLASIFICACION-PRIMARIA, y otro es CLASIFICACION-SECUNDARIA.
Cada palabra clave puede ser dividida en varias sub-llaves. En adición, cada palabra clave puede
tener varios sinónimos. Por ejemplo, "memoria del computador", "memoria principal" y "memoria
central" son sinónimos. Hay dos clases de relaciones entre las entidades EMPLEADO Y LIBRO:
una es PRESTAMO, y el otro es SOLICITUD. Cada empleado puede prestar varios libros, pero un
libro usualmente es autorizado por un solo empleado. Si un empleado no puede encontrar un libro en
la biblioteca, el puede solicitar a la biblioteca se lo guarde cuando lo regresen. La relación
SOLICITUD es un mapeo muchos-a- muchos.
5.4.3 Dibujar un diagrama E-R.
El diagrama E-R de la base de datos de la biblioteca se muestra en la figura 75. Note que se
puede combinar la figura 75 con la figura 50 y la figura 67 para obtener un diagrama E-R grande.
5.4.4 Identificar los tipos de valores y atributos.
Página 1
Figura 76 Atributos y valores para Autor y Libro.
La figura 76 muestra los tipos de valores y atributos para AUTOR y LIBRO. Una entidad
AUTOR tiene dos atributos: NOMBRE y FECHA-NACIMIENTO. Un entidad LIBRO tiene cuatro
atributos: FECHA-PUBLICACION, TITULO, EDICION, y ISBN.
Página 1
Figura 77 Atributos y valores para Categoría y Segundo-director.
La figura 77 ilustra los tipos de valores y atributos para CATEGORIA Y

SEGUNDO-DIRECTOR. Cada entidad CATEGORIA tiene un nombre como "física" o "química".
Una relación SEGUNDO-DIRECTOR tiene un atributo llamado RELEVANCIA que es un valor
numérico (tal como 0.1, 0.55, 0.9) asignado por un bibliotecario para indicar el grado de
acercamiento entre un libro y una categoría secundaria. La categoría primaria tiene 1.0 como
acercamiento. El concepto de "RELEVANCIA" estrecha la búsqueda en la base de datos.
Página 1
Figura 78 Atributos y valores para Clave y Clasificación-secundaria.
Similarmente, Una relación CLASIFICACION-SECUNDARIA en la figura 78 tiene un atributo

llamado RELEVANCIA.
Página 1
Figura 79 Atributos y valores para Empleado, Préstamo y solicitud.
Los tipos de valores y atributos para EMPLEADO, PRESTAMO, y SOLICITUD son mostrados
en la figura 79. Un EMPLEADO tiene dos atributos: EMPLEADO-NO y NOMBRE. Una relación
PRESTAMO tiene dos atributos: FECHA-PRESTAMO y FECHA-ENTREGA. Esta información
puede ayudar al bibliotecario que libro no ha sido devuelto. Una relación SOLICITUD tiene un
atributo llamado FECHA-SOLICITUD, que provee la información necesaria para el bibliotecario
para asignar el libro al empleado apropiado cuando el libro se encuentre disponible.
5.4.5 Traslación del diagrama E-R al diagrama estructura dato.
Página 1
Figura 80 Diagrama Estructura-dato derivado del diagrama ER de la figura 75.
Utilizando las reglas de traslación discutidas en la sección 4.2, el diagrama E-R en la figura 75 se
traslada al diagrama estructura-dato mostrada en la figura 80. Todos los tipos de relaciones que son
mapeos uno-a-muchos son trasladados en conjuntos estructura-dato (flechas). Por ejemplo, el tipo
de relación AUTOR-PRINCIPAL se traslada en flecha. Todos los
tipos de relaciones que son mapeos muchos-a-muchos son trasladados en tipos de registros. Se da el
caso, la relación CO-AUTOR se traslada en un tipo de registro apuntado por dos flechas (una para el
registro AUTOR y otra para el tipo de registro LIBRO).
Los tipos de relaciones definidas entre entidades del mismo tipo son también trasladadas en tipos
de registros. Por ejemplo, el tipo de relación SUBCLAVE es trasladado en un tipo de registro.
5.4.6 Diseño del formato de registro.
Los formatos de los registros son similares a los discutidos en los dos ejemplos anteriores. Por lo
tanto, se omite la discusión aquí.
6. OTRAS CONSIDERACIONES EN EL DISEÑO LOGICO DE BASE DE DATOS
6.1 Otras reglas de traslación diagramas E-R a diagramas estructura-dato.
Página 1
Las reglas de traslación de diagramas E-R a diagramas estructura-dato discutidas en la sección
4.2 son generalmente utilizadas, pero no son las únicas. Se puede usar una regla de traslación simple
que traslada todos los tipos de relaciones en tipos de registros, sin importar que tipo de mapeos
tienen (muchos-a-muchos, uno-a-muchos, etc.).
Figura 81 Diagrama estructura-dato derivado del diagrama ER de la figura 50.
Página 1
Figura 82 Otro diagrama Estructura-dato derivado del diagrama ER de la figura 67.
Usando esta regla, el diagrama E-R de la figura 50 será trasladado a la figura 81 envés de la figura
56. El diagrama en la figura 67 debe ser trasladado en la figura 82 envés de la figura 70. Note que
todos los tipos de relación son trasladados en tipos de registros excepto los tipos de relaciones de
dependencia "existencia y ID". Por ejemplo, el tipo de relación entre ORDEN y LINEA en la figura
67 es trasladado en un conjunto estructura-dato (una flecha) en la figura 67.
Usando esta regla simplificada, el diagrama resultante estructura-dato será más complicado y
menos eficiente en la recuperación y actualización. Sin embargo, puede proveer un alto nivel de
independencia de los datos. Esto es, los programas y las estructuras de las bases de datos no
necesariamente se cambian cuando se cambia un tipo particular de relación de uno-a-muchos a
muchos-a-muchos. Este cambio en los tipos de mapeos convertirá el conjunto estructura-dato en un
tipo de registro o viceversa si las reglas de traslación de la sección 4.2 se utilizan, pero ningún
cambio se requiere si la regla simple de esta sección es usada.
6.2 Modificaciones del diagrama estructura-dato por razones de eficiencia y almacenamiento.
Página 1
Figura 83 Registro Empleado-maestro.
Figura 84 Registro Empleado-detalle.
Página 1
Figura 85 Diagrama estructura-dato para Empleado-maestro y Empleado-detalle.
Después de obtener los diagramas estructura-dato de el diagrama E-R usando las reglas de
traslación, se quieren modificar los diagramas para obtener una eficiencia del sistema mejor o para
utilizar mejor el espacio de almacenamiento. Por ejemplo, se puede abrir el registro EMPLEADO en
las figuras 56, 58 y 81 en dos registros. Un registro MAESTRO-EMPLEADO que contiene los
campos EMPLEADO-NO, FECHA-NACIMIENTO Y SUELDO (ver figura 83). Otro es el registro
DETALLE-EMPLEADO que contiene los campos FECHA-INICIO-EN- DEPARTAMENTO,
TELEFONO-OFICINA Y TELEFONO-CASA (ver figura 84). Note que un apuntador es necesario
para conectar la ocurrencia de estos dos tipos de registros. El diagrama estructura-dato en las figuras
56 y 81 se modifican añadiendo la figura 85. Una de las razones para abrir un registro en dos o tres
registros es mejorar la eficiencia de recuperación. Por ejemplo, se podría esperar que el campo en el
registro MAESTRO-EMPLEADO serán utilizados más que los campos en el registro DETALLE-
EMPLEADO. Ya que no se quiere recuperar el dato que no se necesita, es buena idea abrir el
registro en dos registros. Otra razón para abrir un registro en dos se debe a las limitaciones de
tamaño. En algunos casos debido a limitaciones de Hardware/ software, es preferible limitar el
tamaño del registro a una longitud fija (sea 256 bytes). Si un registro "conceptual" es mayor que el
máximo de longitud del registro, el registro "conceptual" debe abrirse en dos o más.
Figura 86 Un nuevo registro Cliente.
Página 1
Figura 87 Registro Dirección-envío.
Otra práctica común es factorizar los grupos repetitivos. Por ejemplo, el DIRECCION-ENVIO
en la figura 68 y 71 es un grupo repetitivo (p.e. hay muchos valores de datos para este atributo). Se
puede sacar este campo y ponerlo en un nuevo registro llamado DIRECCION-ENVIO (ver figura 86
y 87). Los diagramas de estructura-dato en la figura 70 y 82 se modificarán agregando la figura 88 a
los diagramas.
Figura 88 Diagrama Estructura-dato para Cliente y Dirección- envío.
Note un diagrama E-R puede ser trasladado en muchos diagramas diferentes estructura-dato para
satisfacer los diferentes procesos de datos. Por lo tanto, se recomienda que el diseñador de la base de
datos comience con diagramas de E-R y entonces traslade a diagramas estructura-dato ajustables a
este ambiente.
VII DISEÑO DE BASES DE DATOS JERARQUICOS.
Un sistema de base de datos jerárquico tal como IBM IMS, los datos se organizan en registros
jerárquicos (ver figura 7). En esta sección se da una breve discusión sobre como usar el diagrama
E-R para el diseño de la base de dato jerárquico.
7.1 Reglas de traslación.
Página 1
Figura 89 Mapeo muchos a muchos.
Ya que los tipos de las relaciones jerárquicas permiten mapeos uno-a-muchos, se traslada los tipos
de relaciones con mapeos muchos-a-muchos en estructura jerárquicas. Hay al menos cinco posibles
estructuras lógicas para el diagrama E-R de el PROYECTO-EMPLEADO en la figura 89. Estas
cinco estructuras lógicas de datos se listan así:
Figura 90 Proyecto como registro hijo de Empleado.
(1) El tipo de registro PROYECTO es tratado como un registro "hijo" (o registro subordinado)
para tipo de registro EMPLEADO (ver figura 90). Esta estructura lógica será eficiente para ciertos
tipos de colas no para todas. Por ejemplo, si se quieren encontrar todos los empleados asociados con
un proyecto particular, se tiene que hacer una búsqueda exhaustiva de toda la base de datos.
Página 1
Figura 91 Empleado como registro hijo de Proyecto.
(2)El tipo de registro EMPLEADO es tratado como un registro "hijo" para el tipo de registro
PROYECTO (ver figura 91). Una búsqueda exhaustiva de toda base de datos será necesaria si se
quieren encontrar todos los proyectos asociados con empleado particular.
Figura 92 Dos bases de datos.
(3)Ya que ni la estructura lógica en la figura 90 ni en la figura 91 puede ser eficiente para todo tipo
de colas, se debe mantener dos bases de datos como se muestra en la figura 92. Pero requiere el
mantenimiento de datos redundantes.
Página 1
Figura 93 Proyecto como padre lógico de Proyecto-empleado.
(4)En IMS, se escoge la estructura lógica en la figura 93 tal que el tipo de registro EMPLEADO será
"el padre físico" de PROYECTO-EMPLEADO, y el tipo de registro PROYECTO será el "padre
lógico".
Figura 94 Empleado como padre lógico de Proyecto-empleado.
(5)Una alternativa en IMS es hacer el tipo de registro EMPLEADO "el padre lógico" envés de
"padre físico" de el tipo de registro PROYECTO-EMPLEADO (ver figura 94).
7.2 Ejemplo.
Página 1
Figura 95 Base de datos jerárquica para el diagrama ER de la figura 67.
Para el diagrama E-R de la base de datos pedido-entrada (figura 67), se puede derivar muchas
posibles estructuras lógicas jerárquicas. Una estructura se muestra en la figura 95 en donde el tipo de
registro LINEA es el "hijo físico" de el tipo de registro ORDEN y el "hijo lógico" de el tipo de
registro PARTE.
Note que la figura 95 puede ser modificada (p.e. abriendo o fusionando tipos de registros) para
cumplir los requerimientos de eficiencia y almacenamiento.
VIII ANOTACIONES FINALES.
En este publicación, se ha trazado un nuevo enfoque al diseño lógico de las bases de datos:
Enfoque Entidad-Relación. La base del enfoque ha sido probada en ambientes reales y se ha
encontrado fácil de entender y fácil de usar. En particular, los diagramas E-R son valiosos y
herramientas efectivas de comunicación entre gente de sistemas y gente que no trabaja con sistemas.
Uno de cada cuatro proyectos del M.I.T. desarrolla diagramas detallados y estandarizados E-R
para varias industrias como manufacturera, bancos, ventas, etc, para ser utilizados en el diseño de
base de datos o en sistemas de planeación. En la referencia se dan algunos trabajos importantes
realizados. Cualquier sugerencia para mejoramiento del enfoque E-R será bienvenida.
Página 1

ENT-REL2 Vdoc

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ENT-REL2 Vdoc

Cargado por

Copyright:

Formatos disponibles

DISEÑO LOGICO DE UNA BASE DE DATOS

ENFOQUE ENTIDAD - RELACION

Documento borrador de trabajo.

La administración de datos ha llegado ha ser una de las mayores actividades en muchas

En esta sección, se explican algunos conceptos básicos en la administración de datos.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 3 Una base de datos con dos tipos de registros.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 5 Estructura lógica de datos de la base de datos.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

1.2DISEÑO LOGICO Y FISICO DE LA BASE DE DATOS.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

1.3 SISTEMAS DE BASE DE DATOS Y MODELOS DE DATOS.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 8 Estructura de datos en red.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 10 Diseño lógico de la base de datos.

1.4 PROBLEMAS DEL DISEÑO LOGICO DE UNA BASE DE DATOS.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

1.5UN NUEVO ENFOQUE AL DISEÑO DE LA BASE DE DATOS: EL ENFOQUE

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

1.6 VENTAJAS DEL ENFOQUE ENTIDAD-RELACIÓN.

(4)El esquema de la empresa, representado en el diagrama entidad-relación es más fácilmente de

Curso de Base de Datos - Documento borrador de trabajo - ICF.

2.1 PROPOSITO ANSI/X3/SPARC.

El concepto de esquema de la empresa es muy similar al concepto del esquema conceptual

A finales de 1971, el comite sobre computadores y procesamiento de información (abreviado como

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Cuál es la diferencia entre esquema conceptual propuesto por el grupo ANSI/X3/SPARC y el

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Uno de los objetivos de la arquitectura ANSI/X3/SPARC es mantener el esquema conceptual

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

2.3 Tres tipos de administradores de base de datos.

El grupo ANSI/X3/SPARC ha identificado tres tipos de administradores de base de datos:

(1) Administrador empresa

El administrador empresa define el esquema conceptual y, si es posible, lo valida. El debe entender

(2)Administrador de la base de datos.

2.4 Importancia del enfoque E-R.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

(1) En el diseño del esquema conceptual.

(2) En la traslación del esquema conceptual al esquema externo.

3. DIAGRAMA ENTIDAD -RELACION (E-R).

En este capitulo, se introduce la técnica de diagramación de entidad-relación. Primero se discutirá

3.1 ENTIDAD Y RELACION.

Figura 16 Tipos de entidades y entidad.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

3.1.2 tipo de relación.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 21 Información sobre la relación Parte-proveedor-proyecto.

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 23 Información de las relaciones binarias: Parte-proveedor, Proveedor-proyecto y

Curso de Base de Datos - Documento borrador de trabajo - ICF.

Figura 24 Información generada de las tres relaciones binarias mostradas en la figura

3.2 Descripción de entidades y relaciones.

Curso de Base de Datos - Documento borrador de trabajo - ICF.