ENT-REL2 Vdoc

DISEO LOGICO DE UNA BASE DE DATOS
ENFOQUE ENTIDAD - RELACION
POR:
Ingeniero Ismael Castaeda Fuentes, Profesor de la Universidad Nacional de Colombia.
Fuente Principal.
Artculo "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 colaboracin.
Dirigido a.
Estudiantes del curso de Base de Datos.
1. INTRODUCCION
La administracin 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 informacin,
el cmo 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 actualizacin 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 publicacin es proveer una metodologa que hace ms fcil el
entendimiento y uso del proceso de organizar los datos.
1.1TERMINOLOGIA BASICA.
En esta seccin, se explican algunos conceptos bsicos en la administracin de datos.
Curso de Base de Datos - Documento borrador de trabajo - ICF.
Pgina 1
Figura 1 Registro de un empleado.
RegistroEs una coleccin 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".
Pgina 1
Figura 2 Archivo de empleados.
ArchivoEs una coleccin de registros del mismo tipo. Por ejemplo, el archivo de EMPLEADO es
una coleccin de registros EMPLEADO, ver figura 2.
Pgina 1
Figura 3 Una base de datos con dos tipos de registros.
Figura 4 Registros relevantes se encadenan en la base de datos (estructura fsica de la

base de datos).
Pgina 1
Figura 5 Estructura lgica de datos de la base de datos.
Base de datos
Es una coleccin 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 fcil
encontrar los trabajadores de un departamento en particular. La figura 4 ilustra que la
estructura fsica 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
de los registros en la base de datos, pero es demasiado detallado para usarlo en la
comunicacin de las relaciones de las diferentes llaves de la base de datos. La figura 5
es una representacin ms simple de la organizacin de los registros de la figura 4.
Cada caja rectangular representa un tipo de registro y la flecha representa la
asociacin del registro EMPLEADO con su registro DEPARTAMENTO. Hay otra
distincin entre las figuras 4 y 5. La figura 5 representa la estructura lgica 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 conexin.
1.2DISEO LOGICO Y FISICO DE LA BASE DE DATOS.
Pgina 1
Figura 6 Diseo lgico y fsico de la base de datos.
Pgina 1
El diseo de una base de datos puede ser dividido en dos etapas: diseo lgico y diseo fsico, ver
figura 6.
"Diseo fsico de la base de datos" es el proceso de seleccin de una estructura fsica para una
estructura lgica dada. Por ejemplo, hay al menos tres (3) posibles estructuras fsicas en un sistema
de base de datos CODASYL para soportar la misma estructura lgica, 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 atrs, 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 fcil de implementar y sirve para procesos
secuenciales de los registros EMPLEADO. La segunda permite la bsqueda fcil de un registro
EMPLEADO en la cadena, a expensas de un mayor espacio de almacenamiento para los apuntadores
hacia atrs, tambin realiza borrados ms eficientemente. La ventaja clave de la tercera configuracin
fsica es que todos los registros EMPLEADO que pertenecen al mismo departamento pueden
recuperarse de inmediato. Es importante notar que no hay una estructura fsica universalmente
ptima.
El objetivo del diseo de una estructura fsica es seleccionar la estructura que ms se acomode al
ambiente de una aplicacin dada. Aunque el diseo fsico de una base de datos es un tpico
importante, no se tratar ms en esta publicacin.
"El diseo lgico de la base de datos" es el proceso de disear la estructura lgica de la base de
datos, ver figura 6. Cubre un anlisis del ambiente de la aplicacin y la disponibilidad de los tipos de
estructuras lgicas en el sistema de la base de datos. Generalmente hay pocas herramientas para la
ayuda del proceso del diseo lgico de la base de datos; el diseador se apoya en la intuicin y la
experiencia. Como resultado, muchas de las bases de datos existentes no estn bien diseadas.
En esta publicacin, se presenta el proceso del diseo lgico y algunas herramientas tiles y prcticas
para ayudar al diseador de la base de datos.
1.3 SISTEMAS DE BASE DE DATOS Y MODELOS DE DATOS.
Pgina 1
Figura 7 Estructura jerrquica de datos.
Figura 8 Estructura de datos en red.
Pgina 1
Figura 9 Estructura relacional de datos.
Pgina 1
Hay muchos sistemas de bases de datos en el momento. Pueden clasificarse en tres (3) grandes
categoras: Jerrquico, Red y Relacional. La mayor diferencia es el tipo de estructura lgica que las
soporta. Los sistemas de base de datos Jerrquicos, tales como IMS de IBM, requiere que los tipos
de registros sean organizados en forma jerrquica, ver figura 7. La estructura de datos jerrquica
trabaja bien con algunas bases de datos pero se hace difcil cuando la naturaleza jerrquica 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 ms compleja
y ms capaz que los sistemas de bases de datos jerrquico. Por ejemplo sistemas de base de datos en
red permite a un tipo de registro tener como sus padres mltiples tipos de registros, ver figura 8. Los
sistemas relacionales usan tablas como estructuras lgicas, ver figura 9.
Figura 10 Diseo lgico de la base de datos.
En resumen, el diseo lgico de la base de datos trata la organizacin de los datos para sostener el
sistema de la base de datos de forma aceptable, ver figura 10.
1.4 PROBLEMAS DEL DISEO LOGICO DE UNA BASE DE DATOS.
El diseo de una base de datos actualmente es un proceso complicado ya que el diseador tiene que
considerar no solamente como modelar el mundo real, sino tambin las limitaciones del sistema de la
base de datos y la eficiencia de recuperacin y actualizacin. Ejemplos:
Pgina 1
1.-El diseador 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 diseador 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
implcitamente se asume que el registro EMPLEADO tiene como va de acceso el
correspondiente registro DEPARTAMENTO.
3.-El diseador de una base de datos debe considerar como hacer ms eficiente una recuperacin o
una actualizacin. As un dato de una entidad del mundo real puede ser colocado en ms 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 diseo de una base de datos:
1.-El diseador de una base de datos tiene que considerar muchos problemas al mismo tiempo, lo
que hace que el diseo de la base de datos sea un trabajo muy difcil.
2.-El resultado final del proceso del diseo de una base de datos es un esquema para el usuario, por
ejemplo una descripcin de la vista del usuario de la base de datos. Ya que el esquema del
usuario representa la solucin del diseo de la base de datos, complica los problemas
mencionados anteriormente, por esto el esquema del usuario generalmente es difcil de
entender y difcil de modificar.
1.5UN NUEVO ENFOQUE AL DISEO DE LA BASE DE DATOS: EL ENFOQUE
ENTIDAD RELACION.
Pgina 1
Figura 11 Esquema del estudio. Etapa intermedia en el diseo lgico de la base de datos.
Pgina 1
Primero se describe nuevo enfoque al diseo lgico de una base de datos llamado enfoque
entidad-relacin (E-R). La idea clave del enfoque E-R es agregar una etapa intermedia en el diseo
lgico de la base de datos, ver figura 11. El diseador de la base de datos primero identifica las
entidades y las relaciones que son de inters a la empresa usando tcnicas de diagramacin
Entidad-Relacin (E-R). En esta etapa, el diseador 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 descripcin 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 representacin pura del mundo real y
debe ser independiente de las consideraciones de almacenamiento y eficiencia. El diseador de la base
de datos primero disea 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-RELACIN.
El enfoque convencional del diseo lgico de la base de datos usualmente tiene una sola fase: mapeo
de la informacin de los objetos en el mundo real al esquema de usuario. El enfoque E-R para el
diseo lgico consiste de dos grandes fases: (1) definir el esquema de la empresa usando diagramas
de entidad-relacin, y (2) trasladar el esquema de la empresa al esquema de usuario. Las ventajas del
enfoque E-R son:
(1)La divisin de funciones y trabajo en dos fases hacen el proceso de diseo de la base de datos
ms simple y mejor organizada.
(2)El esquema de empresa es ms fcil de disear 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 ms 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 aplicacin, 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-relacin es ms fcilmente de
entender por la mayora de la gente.
Pgina 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 informacin (abreviado como
comite X3) del INSTITUTO NACIONAL AMERICANO DE ESTANDARES (ANSI) form un
grupo especial de estudio para determinar cul (si alguno) de los aspectos de los sistemas de la
administracin de las bases de datos eran candidatos para desarrollo de estndares. El grupo especial
de estudio, llamado comite de Planeacin de estndares 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 teora de base de datos y el desarrollo de un vocabulario que fuera consistente y mutuamente
comprensible. Como resultado, el reporte provisional caus considerable atencin en la comunidad
de bases de datos.
Pgina 1
Figura 12 Arquitectura ANSI/X3/SPARC.
Pgina 1
Lo que el grupo ANSI/X3/SPARC encontr fue que no era deseable desarrollar estndares que
especifiquen como deben trabajar los componentes de un sistema de administracin 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
administracin de base de datos (ver figura 12). Usualmente los sistemas corrientes de administracin
de base de datos tiene una estructura de dos niveles: la estructura lgica (por ejemplo la estructura de
los datos como la ve el programador) y la estructura fsica (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 descripcin de datos visibles a un programa de aplicacin en trminos de
nombres y caractersticas del dato. El esquema interno representa la organizacin fsica de los datos
en los equipos de almacenamiento. Tambin contiene los detalles de integridad, recuperacin y
eficiencia en los procesos de obtencin y actualizacin de datos. El esquema conceptual representa el
punto de vista de empresa. O sea una descripcin del modelo de la empresa en trminos de sus
entidades, atributos y relaciones entre ellos. Tambin contiene los requerimientos para las
operaciones permitidas, integridad semntica y privacidad. El esquema conceptual est orientado a
proveer un punto de vista estable del dato.
2.2 Esquema conceptual y esquema de empresa.
Cul es la diferencia entre esquema conceptual propuesto por el grupo ANSI/X3/SPARC y el
esquema empresa discutido en esta publicacin? 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).
Pgina 1
Figura 13 Traducciones necesarias entre el esquema externo y el esquema interno sin un

modelo conceptual.
Pgina 1
Figura 14 Uso del esquema conceptual como interfaz entre los esquemas externo e
interno.
Una razn para usar el esquema conceptual como interfase es para reducir el nmero 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 nmero 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
difcil 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 fsica del dato. Por lo tanto,
cuando la organizacin fsica 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 organizacin, se
puede disear un esquema externo para l sin cambiar el esquema conceptual ni el esquema interno.
Pgina 1
Figura 15 El esquema externo se puede representar con diferentes tipos de estructura de

datos.
Pgina 1
Adems 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-relacin para describir el
esquema conceptual. En adicin, ya que el esquema externo se puede expresar en trminos de
diferentes tipos estructuras de datos tales como red (CODASYL), jerrquica, o relacional (ver figura
15), las reglas de traslacin entre los diagramas de Entidad-Relacin y los diferentes tipos de
estructuras de datos se vern ms adelante en esta publicacin y sern muy tiles en la
implementacin 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 informacin (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 disea la estructura fsica, esquema
de codificacin, caminos de acceso, y ubicacin de un dato en la unidad de almacenamiento. Es el
responsable por la utilizacin eficiente del espacio de almacenamiento como del comportamiento
eficiente del sistema de la base de datos.
(3)Administrador de la aplicacin.
Un esquema externo representa la vista del programador de la aplicacin. Esto lleva a que cada rea
de aplicacin general tendr su propio administrador de la aplicacin quien provee el esquema
externo para esa rea. Pero estos esquemas externos deben ser consistentes y derivables de un simple
esquema conceptual. Ntese 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 trminos 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 trminos del
objetivo de sta publicacin, 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
aplicacin (por ejemplo el trabajo del diseo del esquema externo).
2.4 Importancia del enfoque E-R.
Pgina 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 diseo del esquema conceptual.
(2) En la traslacin del esquema conceptual al esquema
externo.
3. DIAGRAMA ENTIDAD -RELACION (E-R).

En este capitulo, se introduce la tcnica de diagramacin de entidad-relacin. Primero se discutir
que son entidad y relacin y entonces explicar como se describe las propiedades de entidad y
relacin.
3.1 ENTIDAD Y RELACION.
Figura 16 Tipos de entidades y entidad.
Pgina 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 inters de la empresa, y el resto
no. Es responsabilidad del diseador seleccionar los tipos de entidades que sirven para su compaa.
3.1.2 tipo de relacin.
Figura 18 Matrimonio representado como relacin entre dos personas de una entidad.
Pgina 1
Figura 19 Relaciones representadas como diamantes.
Las relaciones existen entre las entidades. Por ejemplo, MATRIMONIO es una relacin 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 notacin de
diagramacin entidad-relacin, un tipo de relacin es representada por una caja en forma de diamante
con lneas que conectan las entidades relacionadas (ver figura 19). La notacin "m" y "1" asociada
con el tipo de relacin 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 relacin 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. Ntese que ms mapeos entre entidades es posible. Como caso, el
tipo de relacin MATRIMONIO es un mapeo uno a uno entre personas (entidades) ver figura 20.
Pgina 1
Figura 20 Matrimonio representado como relacin entre dos personas de la entidad

Persona.
Figura 21 Informacin sobre la relacin Parte-proveedor-proyecto.
Es posible definir un tipo de relacin 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 relacin definida sobre tres entidades: PARTE,
PROVEEDOR, y PROYECTO (figura 22).
Pgina 1
Figura 22 Relacin Parte-proveedor-proyecto.
Pgina 1
Figura 23 Informacin de las relaciones binarias: Parte-proveedor, Proveedor-proyecto y

Proyecto-parte.
Note que una relacin triple usualmente no puede ser representada por tres relaciones binarias.
Ejemplo, la relacin 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 relacin triple
comenzando con estas tres relaciones binarias, se obtienen cosas "nuevas" (ver figura 24 entradas).
Pgina 1
Figura 24 Informacin generada de las tres relaciones binarias mostradas en la figura

23.
Hay muchos tipos de relaciones entre entidades, y algunas de ellas son de inters a la empresa; el
diseador de la base de datos es el responsable por la seleccin de las relaciones importantes a la
empresa. Debe tambin especificar el tipo de mapeo de las relaciones (por ejemplo uno a uno, uno a
varios, varios a varios).
3.2 Descripcin de entidades y relaciones.
Pgina 1
Figura 25 Atributos y sus valores.
Las entidades y las relaciones tienen propiedades, que pueden ser expresadas en trminos de pares
valor-atributo. Por ejemplo, en la afirmacin " 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-AOS, CANTIDAD, y COLOR. En la notacin 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 ms 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 mltiples 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.
Pgina 1
Figura 26 Atributos de una relacin.
Hasta ahora slo se han considerado los atributos de las entidades. Algunos veces nos interesa las
propiedades de las relaciones, como cuando se quiere conocer cundo 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, FECHAINICIO es un atributo de la relacin PROYECTO-EMPLEADO. Otro ejemplo de atributo de
relacin 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 relacin es importante
para entender la semntica del dato. El concepto es similar al "dato relacionado" en "red"
(CODASYL) sistemas de base de datos y similar al "dato interseccin" en los sistemas de base de
datos jerrquicos (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 identificacin
trabaja para muy pocos objetos, y caer en dificultades cuando se quiere comunicar esta informacin
de una variedad de objetos a mucha gente. Por lo tanto, en ambos en la conversacin diaria o en el
Pgina 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 pequea empresa, pero no para una grande.
Esta seleccin de los atributos de la entidad se llaman identificadores de la entidad. En algunos casos,
puede ser difcil 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 relacin.
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 relacin PROYECTO-EMPLEADO es identificado
por ambos PROYECTO-NO y EMPLEADO-NO. En algunas situaciones, un tipo de relacin es
definido entre dos ocurrencias de el mismo tipo de entidad. Es el caso, de MATRIMONIO es un tipo
de relacin 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 tambin el
papel que juega la entidad en la relacin. En el caso de MATRIMONIO, los nombres MARIDO y
MUJER son los papeles que ellos juegan en la relacin MATRIMONIO.
3.3 Tipos especiales de entidades y relaciones.
En este numeral se discuten algunos tipos especiales de entidades y relaciones que se encuentran
comnmente.
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 compaa, no se mantendr ms la informacin de sus hijos.
Pgina 1
Figura 27 Relacin dependiente de existencia.
La figura 27 ilustra el diagrama E-R para esta situacin. HIJO es representado por una caja
rectangular doble, que significa que es un tipo de entidad "dbil". La existencia de una entidad dbil
depende de la existencia de otras entidades. La "E" dentro de la caja de relacin indica que es una
relacin existencia dependiente; la flecha asociada indica la direccin de dependencia.
Figura 28 Relacin dependiente de existencia con mapeo muchos a muchos.
Es posible que la relacin "dependencia de existencia" es un mapeo de varios a varios. Por

ejemplo, si el padre deja la compaa, el HIJO puede permanecer si la madre continua trabajando en
la compaa. Esta situacin se representa en el diagrama E-R mostrada en la figura 28.
Pgina 1
3.3.2 Dependencia ID.
Pgina 1
Figura 29 Dependencia de existencia e identificacin.

Pgina 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 pas. En orden de identificar la direccin de un local, se debe especificar el nombre de la
ciudad, estado, y pas adicionalmente a la calle. L dependencia ID es indicada por la caja de relacin
"ID" y la direccin de la relacin es indicada por la flecha (ver figura 29); muchas de las
Pgina 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 identificacin.
4. PASO DEL DIAGRAMA E-R A DIAGRAMAS DE ESTRUCTURA-DATO.

4.1 Diagramas de estructura - dato.
Pgina 1
Figura 33 Diagrama de estructura de estructura de datos.
Las estructuras lgicas 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 ms
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 asociacin 1:n (uno-a-varios) entre el registro amo y el
registro miembro. Esta clase de asociacin puede ser tambin representado en forma de tabla (figura
35).
Pgina 1
Figura 34 Registro propietario con cero, uno o muchos registros miembros.
Pgina 1
Figura 35 Correspondencia uno a muchos entre Empleado y Dependencia.
Pgina 1
Figura 36 Dos estructuras de datos apuntando al mismo registro miembro.
La figura 36 ilustra una estructura de datos ms 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 tambin 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 informacin de referencia
cruzada acerca de EMPLEADOS y LENGUAJE. Esta informacin puede ser representada en forma
de tabla, como se muestra en la figura 37.
Pgina 1
Figura 37 Referencia cruzada de empleado y lenguaje.
Se puede apreciar de la figura 37 que un empleado puede tener uno o ms lenguajes, y que
usualmente ms de un empleado tiene un lenguaje particular. Por lo tanto, la relacin 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 lneas salidas, y el
conjunto estructura-dato entre el tipo de registro LENGUAJE y el tipo de registro
EMPLEADO-LENGUAJE es representado por lneas punteadas.
Pgina 1
Figura 38 Implementacin de la estructura de datos mostrada en la figura 37 utilizando

apuntadores.
En la figura 38, cmo 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 algn otro mtodo. El segundo paso es encontrar el primer registro EMPLEADO-LENGUAJE
relacionado con este empleado. Por va de un apuntador mostrado en lnea 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 (va
apuntadores de lnea salida). Desde el registro EMPLEADO-LENGUAJE, se puede ir a travs del
apuntador de lnea punteada a localizar un registro LENGUAJE con LENGUAJE-NOMBRE= PL/1.
No se pueden encontrar ms registros EMPLEADO-LENGUAJE relacionados con los mismos
registros EMPLEADO (por ejemplo, se ha encontrado la informacin que se requera: el empleado
EMPLEADO- NO=2142 tiene dos lenguajes: COBOL y PL/1.
Cmo 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 va apuntadores de lnea salida el
correspondiente registro EMPLEADO. Haciendo esto, se sabe que hay dos empleados poseyendo la
lenguaje COBOL, y sus nmeros de empleado son 2142 y 1781.
Pgina 1
Figura 39 Implementacin 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 lneas slidas conectan todos los registros
EMPLEADO-LENGUAJE relacionados con el mismo registro EMPLEADO. Las lneas punteadas
conectan todos los registros EMPLEADO-LENGUAJE relacionados con el mismo registro
LENGUAJE. Cmo encontrar las lenguajes de un empleado con EMPLEADO-NO=2142? Primero
se encuentra el primer registro EMPLEADO-LENGUAJE va la cadena de lnea slida. Desde el
registro EMPLEADO- LENGUAJE, se encuentra el registro lenguaje va la cadena punteada. Desde
el registro EMPLEADO-LENGUAJE, se busca el prximo registro EMPLEADO- LENGUAJE va
la cadena de lnea slida. Desde el segundo registro EMPLEADO-LENGUAJE, se puede determinar
el correspondiente registro LENGUAJE a travs de la cadena de lnea punteada. Desde el segundo
registro
EMPLEADO-LENGUAJE,
no
se
pueden
encontrar
ms
registros
EMPLEADO-LENGUAJE en la cadena de lnea slida. Ahora, se conocen todos los lenguajes que
tiene el empleado 2142. Similarmente, se pueden encontrar a todos los empleados con una lenguaje
movindonos a travs de las cadenas.
Pgina 1
Figura 40
miembro.
Dos estructuras de datos que tienen los mismos registros propietario y
Figura 41 Relacin de manufactura entre partes.
Pgina 1
Figura 42 Implementacin de la estructura de datos de la figura 41.
Pgina 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
(relacin- 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 informacin acerca de una "parte" particular. El tipo de registro RELACIONFABRICACION contiene la informacin acerca de la relacin 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 tambin 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 lneas slidas representan el
encadenamiento a COMPONENTE y las lneas punteadas representan la cadena USADA-EN. En
orden a saber los componentes de una parte particular, primero se recuperan todos los registros
RELACION-FABRICACION va el encadenamiento COMPONENTE y luego se recuperan las
correspondientes sub-partes va 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 cundo una parte
particular es usada para manufacturar otras partes , primero se recuperan todos los registros
RELACION-FABRICACION relacionados con aquel registro particular PARTE va la cadena
USADA-EN, y luego se recuperan los correspondientes registros PARTE va el encadenamiento
COMPONENTE. Haciendo esto, se puede averiguar que dos PARTE#5 son usadas en la
manufacturacin de PARTE#4.
Las figuras 33, 36, y 40 son los tipos bsicos de diagramas de estructura-dato. Una base de datos
se puede expresar en un gran diagrama de estructura-dato basado en estos tres bloques bsicos de
construccin.
4.2 Reglas de Traduccin.
Como se ha visto en la seccin precedente, los diagramas estructura-dato estn ms prximos a la
organizacin fsica de una base de datos, que los diagramas de entidad-relacin. Usualmente es difcil
dibujar un diagrama estructura-dato para las entidades y relaciones que son de inters para la
empresa. Por lo tanto, se propone que el diseador de la base de datos primero dibuje un diagrama
E-R que represente la visin de la empresa sobre los datos y que luego los traslade a un diagrama
estructura-dato. En este numeral se discute cmo trasladar un diagrama E-R en un diagrama
estructura-dato. Se Identifican varias reglas bsicas de traduccin basadas en el tipo de relaciones
entre entidades. Se empieza con relaciones definidas entre dos tipos de entidades, luego con
relaciones definidas con ms de dos tipos de entidades, y finalmente relaciones del mismo tipo de
entidad. Las siguientes son las reglas de traduccin:
Pgina 1
Figura 43
Figura 44
(1) Relaciones definidas sobre dos tipos de entidades
diferentes:
Pgina 1
(a)La relacin es una correspondencia uno-a-muchos (o uno-a-uno). Por ejemplo, el tipo de

relacin DEPARTAMENTO- EMPLEADO en la figura 43(a) es una correspondencia uno-amuchos 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 relacin
DEPARTAMENTO-EMPLEADO es representada por un conjunto estructura-dato(una flecha) en el
diagrama estructura-dato. Similarmente, el tipo de relacin PROYECTO-ADMINISTRADOR en la
figura 44(a) que restringe a un gerente por proyecto pero permite que mltiples proyectos tengan un
mismo gerente, es representado por una flecha en el diagrama de estructura-dato mostrado en la
figura 44(b).
Figura 45
Pgina 1
Figura 46
(b)La relacin es una correspondencia muchos-a-muchos. Por ejemplo, el tipo de relacin

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
relacin PROYECTO-EMPLEADO no es trasladado en una flecha, sino en un tipo de registro. Se
puede concluir que si el tipo de relacin es una correspondencia de muchos-a-muchos, ser
trasladada en un tipo de registro con dos flechas sealando 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 relacin
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 ms de dos tipos de entidades:
Pgina 1
Figura 47
En este caso el tipo de relacin en el diagrama E-R ser trasladado en un tipo de registro relacional
en el diagrama estructura-dato, no importa que la relacin sea una correspondencia uno-a-muchos, o
de otro tipo. Por ejemplo, el tipo de relacin PARTE-PROYECTO-PROVEEDOR en la figura 47(a)
es un tipo de relacin 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:
Pgina 1
Figura 48
Pgina 1
Figura 49
Si la relacin binaria es una correspondencia uno-a- muchos, tal como el tipo de relacin
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 mayora 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 relacin con tipo de correspondencia muchos-a-muchos, y es
equivalente al diagrama estructura-dato mostrado en la figura 49 (b).
V. PASOS EN EL DISEO LOGICO DE BASE DE DATOS Y EJEMPLOS.
En este numeral primero se delinean los grandes pasos en el diseo lgico de una base de datos, y
luego se dan tres ejemplos de diseo de base de datos usando la aproximacin E-R.
5.1 Grandes pasos en el diseo lgico de base de datos.
La aproximacin entidad-relacin al diseo de bases de datos consiste de los siguientes pasos:
Pgina 1
(1) Identificar los tipos de entidad.

(2) Identificar los tipos de relacin.
(3)Dibujar diagrama E-R con tipos de entidad y relacin.
(4) Identificar tipos de valores y atributos.
(5) Trasladar diagramas E-R a diagramas estructura-dato.
(6) Disear formatos de registros.
5.2 Ejemplo 1: Una compaa manufacturera.
5.2.1 Identificar los tipos de entidad.
El primer paso es identificar los tipos de entidad de inters para la compaa. En una empresa
manufacturera. los tipos de entidades primarios son PARTE, PROVEEDOR, PROYECTO,
EMPLEADO, DEPARTAMENTO. Hay otros tipos de entidades que pueden ser de inters para una
empresa manufacturera, pero por simplicidad, solo se toman estos tipos importantes de entidad.
5.2.2 Identificar los tipos de relacin.
Pgina 1
Figura 50 Diagrama ER para una empresa de manufactura.
Pgina 1
Se puede al menos identificar los siguientes tipos de relacin (ver figura 50):
(a)El tipo de relacin DEPARTAMENTO-EMPLEADO describe la afiliacin de los departamentos
con los empleados y es un mapeo uno-a- muchos.
(b)El tipo de relacin PROYECTO-EMPLEADO describe la afiliacin de los proyectos con los
empleados y es un mapeo muchos-a- muchos. Esto es, cada empleado puede trabajar en ms de un
proyecto y cada proyecto puede involucrar a ms de un empleado.
(c)El tipo de relacin 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 ms de un proyecto.
(d)El tipo de relacin PROYECTO-PROVEEDOR-PARTE describe cul proveedor provee cual
producto para un proyecto en particular y es un mapeo muchos-a-muchos de tres vas. Esto es, para
una parte particular puede haber ms de un proveedor que puede proveer esta parte a ms de un
proyecto. Similarmente, cada proyecto puede usar ms de una parte, la cual puede tener ms de un
proveedor.Tambin, cada proveedor puede proveer a un proyecto con ms de una parte. Una razn
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 ms por ella, comprndola en una compaa local. En general, este
tipo de relacin de tres vas no puede ser reemplazada por tres relaciones binarias tales como
PROYECTO- PROVEEDOR, PROVEEDOR-PARTE, PARTE-PROYECTO.
(e)El tipo de relacin 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 ms de un
proveedor potencial y cada proveedor puede ser capaz de suplir ms de una parte.
(f)El tipo de relacin INVENTARIO guarda la pista de cul parte es almacenada en cul depsito y
es mapeo muchos-a- muchos.
5.2.3 Dibujar diagrama E-R con tipos entidad y relacin.
El tercer paso es dibujar un diagrama E-R con los seis tipos de entidad y los siete tipos de relacin
mencionados arriba. Ciertamente, se pueden identificar tipos de entidades y relaciones diferentes a
los mencionados arriba. Sin embargo, desde que nuestro propsito es introducir los conceptos claves
de la aproximacin entidad-relacin, no se entra en mayores detalles al respecto. El lector de esta
publicacin puede agregar ms tipos de entidad y de relacin 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 inters
para la empresa. Esto es, se quieren identificar atributos y tipos de valores para las entidades y
relaciones en la figura 50.
Pgina 1
Figura 51 Atributos y valores de entidades y relaciones.
Pgina 1
Figura 52 Versin simplificada de la figura 51.
Se comienza con los tipos de entidad DEPARTAMENTO y EMPLEADO y su relacin

DEPARTAMENTO-EMPLEADO. La figura 51 ilustra los atributos y tipos de valores para
DEPARTAMENTO y EMPLEADO. Los tipos de entidad y los tipos de relacin estn en el dominio
conceptual superior, y los atributos y tipos de valores estn 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-AO, y PRESUPUESTODEL-AO-PASADO; EMPLEADO tiene cinco atributos: EMPLEADO-NO, FECHANACIMIENTO, 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 ms de un
atributo relacionado con el mismo tipo de valor. Por ejemplo, PRESUPUESTO-DE-ESTE-AO y
PRESUPUESTO-DEL-AO-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 versin 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
tambin cinco atributos en la figura 53 (an cuando algunos nombres de atributos se omitieron en el
diagrama): %ESFUERZO, FECHA-INICIO-PROYECTO, PROYECTO-NO, PRESUPUESTO,
PROYECTO-NOMBRE. Note que la relacin PROYECTO-EMPLEADO tiene dos atributos:
FECHA-INICIO-PROYECTO y %ESFUERZO. El FECHA-INICIO-PROYECTO, es la fecha en la
Pgina 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 relacin de especial inters.
Pgina 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
relacin
PROYECTOPROVEEDOR-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 relacin
PROYECTO-PROVEEDOR-PARTE tiene el atributo CANTIDAD el cual es la cantidad de cierta
parte proveda por cierto proveedor para un cierto proyecto. La relacin
POTENCIAL-PROVEEDOR no tiene un atributo. Los atributos de la entidad PROYECTO ya han
sido mostrados en la figura 53.
Pgina 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 relacin INVENTARIO tiene
el atributo CANTIDAD-A-MANO; el cual es la cantidad de una parte almacenada en un deposito.
La relacin 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 inters 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
traduccin discutidas en la seccin 4.2.
Pgina 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 relacin 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 relacin PROYECTO-ADMINISTRADOR es tambin un
mapeo uno-a-muchos y es trasladado en un conjunto estructura-dato. Como el tipo de relacin
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 relacin PROYECTO-PROVEEDOR- PARTE es un mapeo
muchos-a-muchos de tres vas, es trasladado en un tipo de registro. El tipo de relacin RELACIONFABRICACION es trasladada en un tipo de registro desde que es un tipo de relacin 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 Disear formatos de registros.
Pgina 1
El sexto paso es agrupar atributos de entidades y relaciones en registros y decidir cmo implementar
los conjuntos de estructura- dato (usando "cadenas"? matrices de apuntadores? etc.).
Las pautas bsicas para agrupar atributos en registros son:
Figura 57 Registro Departamento.
(1)Todos los atributos de una entidad sern puestos en el mismo tipo de registro, Por ejemplo, los
atributos de DEPARTAMENTO sern 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 relacin es un mapeo uno-a-muchos, los atributos de la relacin sern tratados como
campos en el mismo registro miembro del conjunto estructura-dato. Por ejemplo, el tipo de relacin
Pgina 1
DEPARTAMENTO-EMPLEADO (figura 52) es un mapeo uno-a-muchos t su atributo FECHAINICIO-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 relacin es trasladado a un tipo de registro, entonces los atributos de la relacin sern
tratados como campos en ese tipo de registro. Por ejemplo, el tipo de relacin
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.
Pgina 1
Figura 61 Registro Proveedor.
Figura 62 Registro Parte.
Pgina 1
Figura 63 Registro Parte-proveedor-proyecto.
Figura 64 Registro Proveedor-potencial.
Se pueden aplicar estas reglas a otros tipos de entidad y de relacin. Como todos los tipos de entidad
y de relacin, excepto PROYECTO-ADMINISTRADOR en la figura 50, son trasladados
directamente en tipos de registro, la agrupacin de atributos en tipos de registros es directa. La figura
53 es trasladada a las figuras 59 y 60. Note que el tipo de relacin
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.
Pgina 1
Figura 65 Registro Almacn.
Figura 66 Registro Inventario.
Despus de poner todos los atributos en los tipos de registros, la siguiente cuestin es decidir
como implementar los conjuntos estructura-dato. En este ejemplo de la empresa manufacturera, se
usan "cadenas" como implementacin fsica de los conjuntos estructura-dato. Esto es, se usan las
figuras 39 y 42 como implementacin fsica de las figuras 36 y 40 respectivamente. De estas figuras,
se pueden hacer las siguientes observaciones sobre cmo 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 prxima 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.
Pgina 1
(3)Si un tipo de registro est envuelto en mltiples 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 prxima 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 ningn proyecto, el
valor del apuntador es nulo. Ya que el tipo de registro EMPLEADO es tambin 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 prxima ocurrencia del registro
PROYECTO-EMPLEADO para el mismo empleado, y el otro apunta a la prxima ocurrencia del
registro PROYECTO-EMPLEADO para el mismo proyecto (ver figuras 56 y 60).
Se considera un caso ms 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 Identificacin de los tipos de entidades.
Un pedido-entrada maneja los pedidos de los clientes sobre artculos, 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 "lneas" , cada una contiene el
numero de la parte y la cantidad ordenada.
5.3.2 Identificacin de los tipos de relaciones.
Se pueden identificar los siguientes tipos de relaciones:
(1) La relacin 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.
Pgina 1
(2)La relacin ORDEN-LINEA indica que las entidades LINEA son dependiente-existencia y
dependiente ID en la correspondiente entidad de pedido. Cada "pedido" tiene varias "lneas", pero
cada "lnea" pertenece solamente a un "pedido".
(3) La relacin LINEA-PARTE describe que "parte" esta en la lnea del pedido. Tambin describe
la cantidad de las partes pedidas. Esta clase de relacin es un mapeo uno-a-muchos; cada "lnea"
contiene una sola parte, pero cada parte puede tener muchas lneas (usualmente en diferentes
"pedidos").
(4) La relacin 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 relacin.
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 Identificacin de valores, tipos y atributos.
Pgina 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, LIMITECREDITO, DESCUENTO y DIRECCION-ENVIO. Cada cliente puede tener ms de una direccinde-envo. Una entidad ORDEN tiene tres atributos: ORDEN-NO, DIRECCION-ENVIO, y FECHA.
Cada pedido tiene una sola direccin-de-envo. La relacin CLIENTE-ORDEN no tiene atributos.
Pgina 1
Figura 69 Atributos y valores para Lnea y Parte-lnea.
La figura 69 ilustra los tipos de valores y atributos de las propiedades de la entidad LINEA y la
relacin LINEA-PARTE. La entidad LINEA tiene un atributo: LINEA-NO. La relacin
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 envos.
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.
Pgina 1
Figura 70 Diagrama estructura-dato derivado del diagrama ER de la figura 67.
Usando las reglas de traslacin discutidas en la seccin 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 relacin
INVENTARIO es un mapeo muchos-a-muchos, se traslada en un tipo registro.
5.3.6 Diseo del formato de registro.
Pgina 1
Figura 71 Registro Orden.
Figura 72 Registro Orden.
Pgina 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 relacin LINEA-PARTE (ver figura 69 y 73). En este ejemplo de
base de datos pedido-entrada, se escoge "cadenas" como la implementacin fsica 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 redisear
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 Identificacin de los tipos de entidades.
Pgina 1
Figura 75 Diagrama ER para una base de datos de una Biblioteca.
Pgina 1
Una biblioteca quiere conocer sus libros y proveer un sistema computarizado para la bsqueda de
libros por categoras, palabras claves o autores. tipos de entidades importantes son: LIBRO,
AUTOR, CLAVE, CATEGORIA y EMPLEADO (ver figura 75).
5.4.2 Identificacin 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
adicin 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 categora primaria pero puede pertenecer
a varias categoras secundarias. Por ejemplo, un libro relacionado con "qumica fsica" puede tener
"qumica" como categora primaria y "fsica" como categora secundaria. Hay tambin un tipo de
relacin llamado SUBCATEGORIA que es definida entre la entidades CATEGORIA ; esto es, cada
categora puede ser dividida en subcategoras. Por ejemplo, "ciencia" puede ser dividida en "fsica",
"qumica", "matemtica", 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 adicin, cada palabra clave puede
tener varios sinnimos. Por ejemplo, "memoria del computador", "memoria principal" y "memoria
central" son sinnimos. 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 relacin
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.
Pgina 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.
Pgina 1
Figura 77 Atributos y valores para Categora 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 "fsica" o "qumica".
Una relacin SEGUNDO-DIRECTOR tiene un atributo llamado RELEVANCIA que es un valor
numrico (tal como 0.1, 0.55, 0.9) asignado por un bibliotecario para indicar el grado de
acercamiento entre un libro y una categora secundaria. La categora primaria tiene 1.0 como
acercamiento. El concepto de "RELEVANCIA" estrecha la bsqueda en la base de datos.
Pgina 1
Figura 78 Atributos y valores para Clave y Clasificacin-secundaria.

Similarmente, Una relacin CLASIFICACION-SECUNDARIA en la figura 78 tiene un atributo
llamado RELEVANCIA.
Pgina 1
Figura 79 Atributos y valores para Empleado, Prstamo 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 relacin
PRESTAMO tiene dos atributos: FECHA-PRESTAMO y FECHA-ENTREGA. Esta informacin
puede ayudar al bibliotecario que libro no ha sido devuelto. Una relacin SOLICITUD tiene un
atributo llamado FECHA-SOLICITUD, que provee la informacin necesaria para el bibliotecario
para asignar el libro al empleado apropiado cuando el libro se encuentre disponible.
5.4.5 Traslacin del diagrama E-R al diagrama estructura dato.
Pgina 1
Figura 80 Diagrama Estructura-dato derivado del diagrama ER de la figura 75.
Utilizando las reglas de traslacin discutidas en la seccin 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 relacin 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 relacin 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 tambin trasladadas en tipos
de registros. Por ejemplo, el tipo de relacin SUBCLAVE es trasladado en un tipo de registro.
5.4.6 Diseo 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 discusin aqu.
6. OTRAS CONSIDERACIONES EN EL DISEO LOGICO DE BASE DE DATOS
6.1 Otras reglas de traslacin diagramas E-R a diagramas
estructura-dato.
Pgina 1
Las reglas de traslacin de diagramas E-R a diagramas estructura-dato discutidas en la seccin

4.2 son generalmente utilizadas, pero no son las nicas. Se puede usar una regla de traslacin 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.
Pgina 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 envs de la figura
56. El diagrama en la figura 67 debe ser trasladado en la figura 82 envs de la figura 70. Note que
todos los tipos de relacin son trasladados en tipos de registros excepto los tipos de relaciones de
dependencia "existencia y ID". Por ejemplo, el tipo de relacin 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 ms complicado y
menos eficiente en la recuperacin y actualizacin. 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 relacin 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 traslacin de la seccin 4.2 se utilizan, pero ningn
cambio se requiere si la regla simple de esta seccin es usada.
6.2 Modificaciones del diagrama estructura-dato por razones de
eficiencia y almacenamiento.
Pgina 1
Figura 83 Registro Empleado-maestro.
Figura 84 Registro Empleado-detalle.
Pgina 1
Figura 85 Diagrama estructura-dato para Empleado-maestro y Empleado-detalle.
Despus de obtener los diagramas estructura-dato de el diagrama E-R usando las reglas de
traslacin, 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 aadiendo la figura 85. Una de las razones para abrir un registro en dos o tres
registros es mejorar la eficiencia de recuperacin. Por ejemplo, se podra esperar que el campo en el
registro MAESTRO-EMPLEADO sern utilizados ms que los campos en el registro DETALLEEMPLEADO. Ya que no se quiere recuperar el dato que no se necesita, es buena idea abrir el
registro en dos registros. Otra razn para abrir un registro en dos se debe a las limitaciones de
tamao. En algunos casos debido a limitaciones de Hardware/ software, es preferible limitar el
tamao del registro a una longitud fija (sea 256 bytes). Si un registro "conceptual" es mayor que el
mximo de longitud del registro, el registro "conceptual" debe abrirse en dos o ms.
Figura 86 Un nuevo registro Cliente.
Pgina 1
Figura 87 Registro Direccin-envo.
Otra prctica comn 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 modificarn agregando la figura 88 a
los diagramas.
Figura 88 Diagrama Estructura-dato para Cliente y Direccin- envo.
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 diseador de la base de
datos comience con diagramas de E-R y entonces traslade a diagramas estructura-dato ajustables a
este ambiente.
VII DISEO DE BASES DE DATOS JERARQUICOS.
Un sistema de base de datos jerrquico tal como IBM IMS, los datos se organizan en registros
jerrquicos (ver figura 7). En esta seccin se da una breve discusin sobre como usar el diagrama
E-R para el diseo de la base de dato jerrquico.
Pgina 1
7.1 Reglas de traslacin.
Figura 89 Mapeo muchos a muchos.
Ya que los tipos de las relaciones jerrquicas permiten mapeos uno-a-muchos, se traslada los tipos
de relaciones con mapeos muchos-a-muchos en estructura jerrquicas. Hay al menos cinco posibles
estructuras lgicas para el diagrama E-R de el PROYECTO-EMPLEADO en la figura 89. Estas
cinco estructuras lgicas 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 lgica 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 bsqueda exhaustiva de toda la base de datos.
Pgina 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 bsqueda 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 lgica 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.
Pgina 1
Figura 93 Proyecto como padre lgico de Proyecto-empleado.
(4)En IMS, se escoge la estructura lgica en la figura 93 tal que el tipo de registro EMPLEADO ser
"el padre fsico" de PROYECTO-EMPLEADO, y el tipo de registro PROYECTO ser el "padre
lgico".
Figura 94 Empleado como padre lgico de Proyecto-empleado.
(5)Una alternativa en IMS es hacer el tipo de registro EMPLEADO "el padre lgico" envs de
"padre fsico" de el tipo de registro PROYECTO-EMPLEADO (ver figura 94).
7.2 Ejemplo.
Pgina 1
Figura 95 Base de datos jerrquica 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 lgicas jerrquicas. Una estructura se muestra en la figura 95 en donde el tipo de
registro LINEA es el "hijo fsico" de el tipo de registro ORDEN y el "hijo lgico" 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 publicacin, se ha trazado un nuevo enfoque al diseo lgico de las bases de datos:
Enfoque Entidad-Relacin. La base del enfoque ha sido probada en ambientes reales y se ha
encontrado fcil de entender y fcil de usar. En particular, los diagramas E-R son valiosos y
herramientas efectivas de comunicacin 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 diseo de
base de datos o en sistemas de planeacin. En la referencia se dan algunos trabajos importantes
realizados. Cualquier sugerencia para mejoramiento del enfoque E-R ser bienvenida.
Pgina 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

DISEO LOGICO DE UNA BASE DE DATOS

ENFOQUE ENTIDAD - RELACION

La administracin de datos ha llegado ha ser una de las mayores actividades en muchas

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

Figura 1 Registro de un empleado.

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

Figura 2 Archivo de empleados.

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

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

Figura 4 Registros relevantes se encadenan en la base de datos (estructura fsica de la

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

Figura 5 Estructura lgica de datos de la base de datos.

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

Figura 6 Diseo lgico y fsico 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.

Figura 7 Estructura jerrquica de datos.

Figura 8 Estructura de datos en red.

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

Figura 9 Estructura relacional de datos.

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

Figura 10 Diseo lgico 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.

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

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

2. EL ENFOQUE E-R Y EL PROPOSITO ANSI/X3/SPARC.

2.1 PROPOSITO ANSI/X3/SPARC.

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

Figura 12 Arquitectura ANSI/X3/SPARC.

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

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

Figura 13 Traducciones necesarias entre el esquema externo y el esquema interno sin un

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

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

Figura 15 El esquema externo se puede representar con diferentes tipos de estructura de

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

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

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

Figura 16 Tipos de entidades y entidad.

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

Figura 17 Entidades representadas en cajas rectangulares.

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

Figura 19 Relaciones representadas como diamantes.

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

Figura 20 Matrimonio representado como relacin entre dos personas de la entidad

Figura 21 Informacin sobre la relacin Parte-proveedor-proyecto.

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

Figura 22 Relacin Parte-proveedor-proyecto.

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

Figura 23 Informacin de las relaciones binarias: Parte-proveedor, Proveedor-proyecto y

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

Figura 24 Informacin generada de las tres relaciones binarias mostradas en la figura

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

Figura 25 Atributos y sus valores.

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

Figura 26 Atributos de una relacin.

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

Figura 27 Relacin dependiente de existencia.

Figura 28 Relacin dependiente de existencia con mapeo muchos a muchos.

Es posible que la relacin "dependencia de existencia" es un mapeo de varios a varios. Por

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

3.3.2 Dependencia ID.