actividad 2

Diseño de Bases de Datos

Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseño de la base de datos, quizá las más fuertes sean:

• La velocidad de acceso,
• El tamaño de la información,
• El tipo de la información,
• Facilidad de acceso a la información,
• Facilidad para extraer la información requerida,
• El comportamiento del manejador de bases de datos con cada tipo de información.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia más alto en lo que se refiere a almacenamiento y recuperación de la información.

De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.

Diseño de las bases de datos

El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la información que necesitamos.

La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los valores o datos que contendrá cada uno de esos campos.

Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.

Los registros constituyen la información que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.

Generalmente los diferente tipos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numérico (números), Fecha / Hora, Lógico (informaciones lógicas si/no, verdadero/falso, etc., imágenes.

En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud.

Pasos necesarios para elaborar un sistema con base de datos

• Identificación de problemas, oportunidades y objetivos.
• En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el éxito del resto del proyecto, pues nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado.
• La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organización hará notar los problemas. Muchas veces esto ya fue realizado previamente: y por ello. es que se llega a invitar al analista.

2) Determinación de los requerimientos de información.

• La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de los usuarios particularmente involucrados. Para identificar los requerimientos de información dentro de ¡a empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios: la observación de la conducta de quien toma las decisiones, así como de su ambiente y también el desarrollo de prototipos.
• En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas. Puede ver, cómo varios de los métodos para establecer las necesidades de información, lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo de los sistemas. El analista es el especialista que emprende esta clase de estudios.

3) Análisis de las necesidades del sistema.

• La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema. Una vez más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen el uso de los diagramas de flujo de datos (DFD)que cuentan con una técnica estructurada para representar en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus especificaciones, si son alfanuméricos, descripción, clave primaria, entre otros.

4) Diseño del sistema recomendado.

• En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con anterioridad y elabora el diseño lógico del sistema de información. El analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. El analista también diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de pantallas.
• Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario.

5) Desarrollo y documentación del software

• En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación de! software se tienen: el método HIPO, los diagramas de flujo. los diagramas Nassi-Schneiderman, los diagramas Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite al programador los requerimientos de programación.
• Durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del software, incluyendo los manuales de procedimientos. La documentación le dirá al usuario como operar el software, y así también, qué hacer en caso de presentarse algún problema.

6) Pruebas y mantenimiento del sistema.

• El sistema de información debe probarse antes de utilizarlo. E! costo es menor si se detectan los problemas antes cié la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista de sistemas. En un principio, se hace una serie de pruebas, con datos tipo, para identificar las posibles fallas del sistema: más adelante, se utilizarán los datos reales.
• El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después, esta función se realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina
• del programador, que para las empresas llegan a simplificar importantes sumas de dinero. Sin embargo, el costo del mantenimiento disminuye de manera importante cuando el analista aplica procedimientos sistemáticos en el desarrollo de los sistemas.

7) Implantación y evaluación del sistema.

• En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de información. Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales, la supervisión del adiestramiento es una responsabilidad del analista de sistemas. Más aún, el analista necesita planear la suave transición que trae consigo un cambio de sistemas.
• Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los sistemas; realmente, la evaluación toma parte en cada una de las etapas. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado.

Proceso de diseño de bases de datos

Si usa un proceso de diseño de base de datos establecido, puede crear de forma rápida y efectiva una base de datos bien diseñada que le proporciona acceso conveniente a la información que desea. Con un diseño sólido tardará menos tiempo en construir la base de datos y obtendrá resultados más rápidos y precisos.

Nota Los términos "base de datos" y "tabla" no son sinónimos en Visual FoxPro. El término base de datos (archivo .dbc) se refiere a una base de datos relacional que almacena información sobre una o más tablas (archivos .dbf) o vistas.

La clave para obtener un diseño de base de datos eficaz radica en comprender exactamente qué información se desea almacenar y la forma en que un sistema de administración de bases de datos relacionales, como Visual FoxPro, almacena los datos. Para ofrecer información de forma eficiente y precisa, Visual FoxPro debe tener almacenados los datos sobre distintos temas en tablas separadas. Por ejemplo, puede haber una tabla donde sólo se almacenen datos sobre empleados y otra tabla que sólo contenga datos de ventas.

Al organizar los datos de forma apropiada, proporciona flexibilidad a la base de datos y tiene la posibilidad de combinar y presentar información de muchas formas diferentes.

Al diseñar una base de datos, en primer lugar debe dividir la información que desea almacenar como temas distintos y después indicar a Visual FoxPro cómo se relacionan estos temas para que pueda recuperar la información correcta cuando sea necesario. Si mantiene la información en tablas separadas facilitará la organización y el mantenimiento de los datos y conseguirá aplicaciones de alto rendimiento.

A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.

1. Determinar el propósito de la base de datos Este paso le ayudará a decidir los datos que desea que Visual FoxPro almacene.
2. Determinar las tablas necesarias Cuando ya conozca claramente el propósito de la base de datos, puede dividir la información en temas distintos, como "Employees" u "Orders". Cada tema será una tabla de la base de datos.
3. Determinar los campos necesarios Tiene que decidir la información que desea incluir en cada tabla. Cada categoría de información de una tabla se denomina campo y se muestra en forma de columna al examinar la tabla. Por ejemplo, un campo de la tabla Employee podría ser Last_name y otro podría ser Hire_date.
4. Determinar las relaciones Observe cada tabla y decida cómo se relacionan sus datos con los de las tablas restantes. Agregue campos a las tablas o cree tablas nuevas para clarificar las relaciones, si es necesario.
5. Perfeccionar el diseño Busque errores en el diseño. Cree las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desea de sus tablas. Haga los ajustes necesarios al diseño.

No se preocupe si se equivoca o si olvida algunos aspectos en el diseño inicial. Piense en él como en un borrador que podrá mejorar posteriormente. Pruebe con datos de ejemplo y con prototipos de los formularios e informes. Con Visual FoxPro resulta sencillo modificar el diseño de la base de datos durante su creación. Sin embargo, es mucho más difícil modificar las tablas cuando ya están llenas de datos y se han generado formularios e informes. Por este motivo, debe asegurarse de tener un diseño sólido antes de llegar demasiado lejos en la programación de una aplicación.

Modelos Conceptuales.

Pueden entenderse como un mapa de conceptos y sus relaciones, incluyendo suposiciones acerca de la naturaleza tanto de los fenómenos que esos conceptos representan como sus relaciones. Estos modelos implican un alto nivel de abstracción, concentrándose en aspectos de categorías semánticas o conceptuales que son considerados fundamentales para la comprensión de lo representado. (ejemplos: Modelo atómico de Bohr. El Modelo OSI; descripción de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones, y el Modelo cíclico de la evolución del Universo) . Los modelos conceptuales se podrían clasificar en modelos que se refieren a entidades o fenómenos aislados o únicos (el átomo, el universo) y los que se refieren a entidades especificas por lo menos en principio en relación a un grupo de tales entidades. (una estrella y sus características en relación a otras. Una molécula y su energía cinética en relación a la temperatura de un cuerpo)

Existen distintos tipos de modelos conceptuales:

Basados en registros

• Jerárquico: datos en registros, relacionados con apuntadores y organizados como colecciones de árboles
• Redes: datos en registros relacionados por apuntadores y organizados en gráficas arbitrarias
• Relacional: datos en tablas relacionados por el contenido de ciertas columnas

Basados en objetos

• Orientado a objetos: datos como instancias de objetos (incluyendo sus métodos)
• Entidad-relación: datos organizados en conjuntos interrelacionados de objetos (entidades) con atributos asociados

Claves

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.

Una superclave es un atributo o un conjunto de atributos que identifican de modo único las tuplas de una relación.

Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación. El atributo o conjunto de atributos de la relación es una clave candidata para si y sólo si satisface las siguientes propiedades:

• Unicidad: nunca hay dos tuplas en la relación con el mismo valor de .
• Irreducibilidad (minimalidad): ningún subconjunto de tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de sin destruir la unicidad.

Cuando una clave candidata está formada por más de un atributo, se dice que es una clave compuesta. Una relación puede tener varias claves candidatas. Por ejemplo, en la relación OFICINA, el atributo Población no es una clave candidata ya que puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna un código único a cada oficina, el atributo Onum sí es una clave candidata de la relación OFICINA. También son claves candidatas de esta relación los atributos Teléfono y Fax.

En la base de datos de la inmobiliaria hay una relación denominada VISITA que contiene información sobre las visitas que los clientes han realizado a los inmuebles. Esta relación contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un número de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinación de los dos atributos sí identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habría que incluir el atributo Fecha para identificar las tuplas de modo único (aunque éste no es el caso de la empresa que nos ocupa).

Para identificar las claves candidatas de una relación no hay que fijarse en un estado o instancia de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia de duplicados en un estado de la base de datos sí es útil para demostrar que cierta combinación de atributos no es una clave candidata. El único modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la relación PLANTILLA se podría pensar que el atributo Apellido es una clave candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos empleados con el mismo apellido, el atributo no es una clave candidata.

La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que haga esta función.

Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas. Por ejemplo, la clave primaria de la relación OFICINA es el atributo Onum, siendo Teléfono y Fax dos claves alternativas. En la relación VISITA sólo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.

Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de alguna otra relación (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla referenciada).

modelo de la Entidad-relación

Un modelo/un diagrama (o un ERD) de la entidad-relación es una representación conceptual abstracta de datos estructurados. el modelar de la Entidad-relación es un esquema emparentado el modelar de la base de datos método, usado adentro tecnología de dotación lógica para producir un tipo de modelo conceptual de los datos (o modelo semántico de los datos) de un sistema, a menudo a base de datos emparentada, y sus requisitos en a de arriba hacia abajo manera. Los diagramas creados usando este proceso se llaman diagramas de la entidad-relación, o ER diagramas para el cortocircuito. Propuesto originalmente en 1976 cerca El Dr. Perno-Shan (Peter) Chen (陳品山), muchas variantes del proceso se han ideado posteriormente.

La primera etapa de sistema de información el diseño utiliza estos modelos durante análisis de requisitos para describir las necesidades de información o el tipo de información ése debe ser almacenado en a base de datos. el modelar de los datos la técnica se puede utilizar para describir cualesquiera ontology (es decir. una descripción y clasificaciones de términos usados y de sus relaciones) para un seguro universo del discurso (es decir. campo de interés). En el caso del diseño de un sistema de información que se base en una base de datos, el modelo conceptual de los datos está, ulteriormente (generalmente llamado diseño lógico), traz a un modelo lógico de los datos, tal como modelo emparentado; esto alternadamente traz a un modelo físico durante diseño físico. Observe eso a veces, ambas fases se refieren como “diseño físico”.

Hay un número de convenciones para los diagramas de la entidad-relación (ERDs). La notación clásica se describe en el resto de este artículo, y se relaciona principalmente con modelar conceptual. Hay una gama de las notaciones empleadas más típicamente en el diseño de base de datos lógico y físico, incluyendo IDEF1x (Lengua de la definición de ICAM) y el modelar dimensional.

Conexión

Entidad representa a objeto discreto. Las entidades se pueden pensar en como sustantivos. Ejemplos: una computadora, empleado, una canción, un teorema matemático. Las entidades se representan como rectángulos.

Capturas de una relación cómo dos o más entidades se relacionan con una otra. Las relaciones se pueden pensar en como verbos, ligando dos o más sustantivos. Ejemplos: posee relación entre una compañía y una computadora, a supervisa relación entre un empleado y un departamento, a se realiza relación entre un artista y una canción, a probado relación entre un matemático y un teorema. Las relaciones se representan como diamantes, conectados por las líneas con cada uno de las entidades en la relación.

El aspecto lingüístico del modelo descrito arriba se utiliza en la base de datos lenguaje de interrogación ERROL.

Las entidades y las relaciones pueden ambas tienen cualidades. Ejemplos: empleado la entidad pudo tener a Número de Seguridad Social Cualidad (SSN); probado la relación puede tener a fecha cualidad. Las cualidades se representan como elipses conectadas con sus sistemas de la entidad que poseen por una línea.

Cada entidad (a menos que es a entidad débil) debe tener un sistema mínimo únicamente de identificar cualidades, que se llama la entidad llave primaria.

Los diagramas de la Entidad-relación no demuestran solas entidades o solos casos de relaciones. Algo, demuestran sistemas de la entidad y sistemas de la relación. Ejemplo: un detalle canción es una entidad. La colección de todas las canciones en una base de datos es un sistema de la entidad. comido la relación entre un niño y su almuerzo es una sola relación. El sistema de todas tales relaciones del niño-almuerzo en una base de datos es un sistema de la relación.

Las líneas se dibujan entre los sistemas de la entidad y los sistemas de la relación que son pulg. implicados. Si todas las entidades en un sistema de la entidad deben participar en el sistema de la relación, se dibuja una línea gruesa o doble. Esto se llama a constreñimiento de la participación. Si cada entidad del sistema de la entidad puede participar en a lo más una relación en el sistema de la relación, una flecha se dibuja del sistema de la entidad al sistema de la relación. Esto se llama un constreñimiento dominante. Para indicar que cada entidad en el sistema de la entidad está implicada en exactamente una relación, una flecha gruesa se dibuja.

Entidad sociable se utiliza solucionar el problema de dos entidades con una relación múltiple .

Relaciones singulares - una relación singular es una relación entre las filas de una sola tabla.

Convenciones diagramming del alternativa

Pie del cuervo

La notación del pie “del cuervo” representa relaciones con las líneas que conectan entre las entidades, y pares de símbolos en los extremos de esas líneas para representar cardinality de la relación. La notación del pie del cuervo se utiliza adentro Notación de Barker y en metodologías por ejemplo SSADM y Ingeniería de información. También esta notación está ganando la aceptación con uso común adentro Oracle textos y en herramientas por ejemplo Visio, PowerDesigner, Modeler de los datos del sapo, OmniGraffle y Diámetro.

Tres símbolos se utilizan para representar cardinality:

• anillo representa “cero”
• rociada representa “uno”
• pie del cuervo representa “más” o “muchos”

Estos símbolos se utilizan en pares para representar los cuatro tipos de cardinality que una entidad puede tener en una relación.

• anillo y rociada → cero o uno
• rociada y rociada → exactamente uno
• anillo y pie del cuervo → cero o más
• rociada y pie del cuervo → uno o más

Elementos del modelo entidad-relación

Entidad

Se trata de un objeto del que se recoge información de interés de cara a la base de datos. Gráficamente se representan mediante un rectángulo. Un ejemplo seria la entidad banco, donde se recogerían los datos relativos a ese banco, como puede ser el nombre, el número de sucursal, la dirección, etc.

Dentro de las entidades pueden ser fuertes o débiles. Las fuertes son las que no dependen de otras entidades para existir, mientras que las entidades débiles siempre dependen de otra entidad sino no tienen sentido por ellas mismas.

Relación

Podemos definir la relación como una asociación de dos o más entidades. A cada relación se le asigna un nombre para poder distinguirla de las demás y saber su función dentro del modelo entidad-relación. Otra característica es el grado de relación, siendo las de grado 1 relaciones que solo relacionan una entidad consigo misma. Las de grado 2 son relaciones que asocian dos entidades distintas, y las de grado n que se tratan de relaciones que unen mas de dos entidades.

Las relaciones se representas gráficamente con rombos, dentro de ellas se coloca el nombre de la relación.

Otra característica es el tipo de correspondencia entre dos relaciones;

• 1:1. Uno a uno, a cada ocurrencia de una entidad le corresponde como máximo una ocurrencia de la otra entidad relacionada.
• 1:N. Uno a Mucho, a cada ocurrencia de la entidad A le pueden corresponder varias de la entidad B.
• N:M. Muchos a muchos, cada ocurrencia de una entidad puede contener varias de la otra entidad relacionada y viceversa.

Para finalizar las características de la relación tenemos la cardinalidad que define el número máximo y mínimo de ocurrencias de cada tipo de entidad. Se representa con los valores máximo coma mínimo encerrados entre paréntesis encima de la relación. (máximo, mínimo)

Atributo

Se define como cada una de las propiedades de una entidad o relación. Cada atributo tiene un nombre y todos los posibles valores que puede tener. Dentro de una entidad tiene que haber un atributo principal que identifica a la entidad y su valor tiene que ser único. Un ejemplo de atributo principal seria el dni dentro de la entidad persona.

Transformación del modelo conceptual al lógico.

El diseño de las DDBB del sistema se llevara a cabo aplicando la arquitectura ANSI de tres niveles, por tanto debemos partir del modelo conceptual y llegar hasta el esquema físico o interno.

El esquema conceptual representa los recursos del sistema y se define sin tener en consideración cuestiones físicas.

Para la definición de este esquema nos podemos ayudar de herramientas de modelado como los diagramas.

El modelo E/R (entidad relación) fue propuesto por Chen y posteriormente algunas aportaciones de han dado lugar E/R extendido.

Los componentes del modelo E/R son:

- Entidades: representan un objeto real o abstracto sobre el que queremos almacenar información.

- Relación: define una asociación entre entidades.

- Grado de una relación: número de entidades que participan en una relación, pudiendo ser reflexivas (una entidad se relaciona con ella misma), binaria (participan 2 entidades) y n-aria (participan n entidades).

- Cardinalidad: define el número máximo de ocurrencias de una entidad que participan en una relación. Puede ser de uno a uno, de uno a muchos y de muchos a muchos.

- Atributos: representan propiedades o características de una entidad o relación.

Dentro del modelo E/R extendido aparecen además otros conceptos:

- Jerarquía: una entidad puede mantener una relación de supertipo con otras entidades. Es el caso de la generalización y especialización.

- Agregación: conversión de una relación junto con sus entidades participantes, en una entidad para poder relacionarse con otra entidad.

- Exclusividad: es un tipo especial de relación en la que una entidad se asocia con varias entidades. La exclusividad relaciona una entidad con otra de entre varias posibles.

Una vez obtenido el modelo conceptual (representado en el diagrama E/R) debe ser transformado a un modelo lógico. La secuencia de pasos a aplicar para dicha transformación son:

1. Cada entidad se transforma en una tabla y los atributos de dicha entidad en atributos de la tabla.

2. Las relaciones de muchos a muchos se transforman en tablas cuya clave estará formada por la clave primaria de las entidades relacionadas. Las relaciones de uno a muchos propagan la clave principal de la entidad cuya cardinalidad es uno a la entidad de cardinalidad n.

Este tipo de esquema solo admite relaciones entre dos entidades, en caso de modelar relaciones en las que intervengan más de dos entidades debemos redefinir el esquema reduciéndolo a relaciones binarias.

Se puede establecer una correspondencia entre diagramas E/R y diagramas de estructura de datos, pudiendo pasar de un tipo de diagrama al otro.