ent-rel2_vdoc (1)

DISEÑO LOGICO DE UNA BASE DE DATOSENFOQUE 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.

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".


Figura 1 Registro de un empleado.

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 2 Archivo de empleados.

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

Base de datosEs 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


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.

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 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.



Figura 6 Diseño lógico y físico de la base de datos.

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.



Figura 7 Estructura jerárquica de datos.

Figura 8 Estructura de datos en red.


Figura 9 Estructura relacional de datos.

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.

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:


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

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.



Figura 11 Esquema del estudio. Etapa intermedia en el diseño lógico de la base de datos.

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.


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.



Figura 12 Arquitectura ANSI/X3/SPARC.

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).



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

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.


Figura 14 Uso del esquema conceptual como interfaz entre los esquemas externo e interno.


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

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 .

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.

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 17 Entidades representadas en cajas rectangulares.

Figura 18 Matrimonio representado como relación entre dos personas de una entidad.

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.


Figura 19 Relaciones representadas como diamantes.

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).


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.


Figura 22 Relación Parte-proveedor-proyecto.

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 23 Información de las relaciones binarias: Parte-proveedor, Proveedor-proyecto y Proyecto-parte.

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.


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

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.


Figura 25 Atributos y sus valores.

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


Figura 26 Atributos de una relación.

información de una variedad de objetos a mucha gente. Por lo tanto, en ambos en la conversación diaria o en el 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.


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.

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.


Figura 27 Relación dependiente de existencia.

Figura 28 Relación dependiente de existencia con mapeo muchos a muchos.


Figura 29 Dependencia de existencia e identificación.

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




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).

4. PASO DEL DIAGRAMA E-R A DIAGRAMAS DE ESTRUCTURA-DATO.

4.1 Diagramas de estructura - dato .


Figura 32 Sin dependencia de identificación.

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).


Figura 33 Diagrama de estructura de estructura de datos.


Figura 34 Registro propietario con cero, uno o muchos registros miembros.


Figura 35 Correspondencia uno a muchos entre Empleado y Dependencia.

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.


Figura 36 Dos estructuras de datos apuntando al mismo registro miembro.

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.


Figura 37 Referencia cruzada de empleado y lenguaje.

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.


Figura 38 Implementación de la estructura de datos mostrada en la figura 37 utilizando apuntadores.

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.


Figura 39 Implementación de la estructura de datos de la figura 22 utilizando cadenas.


Figura 40 Dos estructuras de datos que tienen los mismos registros propietario y miembro.

Figura 41 Relación de manufactura entre partes.


Figura 42 Implementación de la estructura de datos de la figura 41.

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:


(1) Relaciones definidas sobre dos tipos de entidades diferentes:


Figura 43

Figura 44

(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

(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:


Figura 46

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:


Figura 47


Figura 48

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:


Figura 49

(1) Identificar los tipos de entidad. (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.



Figura 50 Diagrama ER para una empresa de manufactura.

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.



Figura 51 Atributos y valores de entidades y relaciones.

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,


Figura 52 Versión simplificada de la figura 51.

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 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.

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.


Figura 54 Atributos y valores para Proveedor, Parte y Proyecto-proveedor-parte.

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.


Figura 55 Atributos y valores de entidades y relaciones.

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.


Figura 56 Diagrama Estructura-Dato derivado del diagrama ER de la figura 50.

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:

(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 57 Registro Departamento.

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 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).

(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.


Figura 59 Registro Proyecto.

Figura 60 Registro Proyecto-empleado.


Figura 61 Registro Proveedor.

Figura 62 Registro Parte.

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.


Figura 63 Registro Parte-proveedor-proyecto.

Figura 64 Registro Proveedor-potencial.

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.


Figura 65 Registro Almacén.

Figura 66 Registro Inventario.

(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.

(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.

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.


Figura 68 Atributos y valores de las entidades Cliente y Orden.

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 .


Figura 69 Atributos y valores para Línea y Parte-línea.

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.


Figura 70 Diagrama estructura-dato derivado del diagrama ER de la figura 67.


Figura 71 Registro Orden.

Figura 72 Registro Orden.

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.



Figura 75 Diagrama ER para una base de datos de una Biblioteca.

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.


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.


Figura 76 Atributos y valores para Autor y Libro.

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.


Figura 77 Atributos y valores para Categoría y Segundo-director.

Similarmente, Una relación CLASIFICACION-SECUNDARIA en la figura 78 tiene un atributo llamado RELEVANCIA.


Figura 78 Atributos y valores para Clave y Clasificación-secundaria.

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 .


Figura 79 Atributos y valores para Empleado, Préstamo y solicitud.

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


Figura 80 Diagrama Estructura-dato derivado del diagrama ER de la figura 75.

6.1 Otras reglas de traslación diagramas E - R a diagramas estructura - dato .

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.

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 .


Figura 82 Otro diagrama Estructura-dato derivado del diagrama ER de la figura 67.


Figura 83 Registro Empleado-maestro.

Figura 84 Registro 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 85 Diagrama estructura-dato para Empleado-maestro y Empleado-detalle.

Figura 86 Un nuevo registro Cliente.

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.

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.


Figura 87 Registro Dirección-envío.

Figura 88 Diagrama Estructura-dato para Cliente y Dirección- envío.

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í:

(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.


Figura 89 Mapeo muchos a muchos.

Figura 90 Proyecto como registro hijo de Empleado.

(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.

(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.


Figura 91 Empleado como registro hijo de Proyecto.

Figura 92 Dos bases de datos.

(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".

(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.


Figura 93 Proyecto como padre lógico de Proyecto-empleado.

Figura 94 Empleado como padre lógico de Proyecto-empleado.

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


Figura 95 Base de datos jerárquica para el diagrama ER de la figura 67.

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.


ent-rel2_vdoc (1)

Documents