SICI-4030 Base de Datos Prof. Nelliud D. Torres Análisis/Diseño y Data Modeling - Introducción.

Presentación del tema: "SICI-4030 Base de Datos Prof. Nelliud D. Torres Análisis/Diseño y Data Modeling - Introducción."— Transcripción de la presentación:

1 SICI-4030 Base de Datos Prof. Nelliud D. Torres Análisis/Diseño y Data Modeling - Introducción

2 OBJETIVOS (Parte 1) Enterprise Data Model Information Systems Architecture (ISA) Dos enfoques (aproach) en las bases de datos –Systems Development Life Cycle (SDLC) –Prototyping Database Methodology Uso del CASE en las bases de datos Normas del negocio (Business Rules) Data names (Nombre de los datos) Modelación –Modelo Conceptual –Modelo Lógico –Modelo Físico Terminología de Datos

3 OBJECTIVOS (Parte 2) Definiciones base de datos –Entidades Definición Ejemplo de Entidades Entity Type vs Entity Instance Strong Entity vs Weak Entity Reglas para nombres de Entidades –Atributos Definición Ejemplos de Atributos Required Atribute vs Optional Atribute Simple Atribute vs Composite Atribute Single-Value Atribute vs Multivalued Atribute Stored Atribute vs Derived Atribute Simple Identifier vs Composite Identifier Ejemplos de UID Reglas para nombrar y definir Atributos Información adicional sobre Atributos –Relaciones Definición Grado (degree) de relaciones Tipos de relaciones –Temas adicionales de Relaciones

4 ENTERPRISE DATA MODEL Volver a los Objetivos

5 Enterprise Data Model Es el primer paso en el desarrollo de la base de Datos Se especifica el alcance (scope) y el contenido en general. Este paso de planificación ocurre durante el análisis del sistema. Es una imagen general (Overall picture) de la data de la organización a un alto nivel de abstración Trabaja con los diagramas Entity-relationship Describe los tipos de entidades y las relaciones entre las entidades Se estudian las políticas del negocio (Business rules) para poder diseñar apropiadamente las relaciones. Págs. 37 - 38

6 INFORMATION SYSTEMS ARCHITECTURE (ISA) Volver a los Objetivos

7 Information Systems Architecture (ISA) Plano conceptual (conceptual blueprint) que contiene la estructura deseada de su sistema de información Consiste de: –Data - (ejemplo; Enterprise Data Model – simplified ER Diagram) –Processes – Que manipulan datos. Ejemplo: Processes – data flow diagrams, process decomposition, etc. –Networks - Transportan data por la organización y entre sus asociados. Se utilizan diagramas tipo Data Network – topology como el ejemplo de la: Fig 1-9. –People - Gerencia de proyectos y recursos. (People – people management) utilizando herramientas de gerencia de proyectos como por ejemplo el uso de Gantt charts. –Events and points in time - Cuando los procesos se ejecutan. –Reasons - Razones para eventos y reglas (ejemplo, decision tables) Págs. 38 - 39

8 Ejemplos A continuación se muestran algunos ejemplos de algunos diagramas que se utilizan bajo la arquitectura de Sistemas de Información. Como este curso sólo se enfoca en el diseño e implementación de las Bases de Datos, no vamos a profundizar en estos tópicos.

9 Figure 2-1 Segment from enterprise data model Enterprise data model - Describe entidades de alto nivel en una organización y las relaciones entre las entidades. Pág. 38 Ejemplo - 1

10 Figure 2-2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition = breaking large tasks into smaller tasks in a hierarchical structure chart Pág. 41 Ejemplo - 2

11 Ejemplo - 3 Planning Matrixes Describen relaciones entre diferentes objetos en la organización Tipos de matrices: (no se van a discutir) –Function-to-data entity –Location-to-function –Unit-to-function –IS-to-data entity –Supporting function-to-data entity –IS-to-business objective Pág. 42

12 Ejemplo - 3 Example business function- to-data entity matrix (Fig. 2-3) Pág. 42

13 DOS ENFOQUES (APROACH) EN LAS BASES DE DATOS Volver a los Objetivos

14 Two Approaches to Database and IS Development SDLC –System Development Life Cycle –Es un proceso detallado y bien planificado del desarrollo de un Sistema de Información o en este caso de una Base de Datos –Consume mucho tiempo, pero se entienden todos sus componentes. –Es un ciclo de desarrollo largo (toma mucho tiempo) Prototyping –Rapid Application Development (RAD) –Define la Base de Datos durante el desarrollo inicial del prototipo –Repite las actividades de implementación y mantenimiento con nuevas versiones de prototipos hasta completar una versión aceptable. Pág. 43

15 Systems Development Life Cycle

16 Systems Development Life Cycle (see also Figures 2.4, 2.5 Pags. 43-47) Planning Analysis Physical Design Implementation Maintenance Logical Design

17 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Planning – Purpose – preliminary understanding – Deliverable – request for study – Database activity – enterprise modeling and early conceptual data modeling

18 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Analysis Purpose–thorough requirements analysis and structuring Deliverable–functional system specifications Database activity – Thorough and integrated conceptual data modeling

19 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose–information requirements elicitation and structure Deliverable–detailed design specifications Database activity– logical database design (transactions, forms, displays, views, data integrity and security)

20 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Physical Design Purpose–develop technology and organizational specifications Deliverable–program/data structures, technology purchases, organization redesigns Database activity– physical database design (define database to DBMS, physical data organization, database processing programs)

21 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Implementation Purpose–programming, testing, training, installation, documenting Deliverable–operational programs, documentation, training materials Database activity– database implementation, including coded programs, documentation, installation and conversion

22 Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Analysis Physical Design Implementation Maintenance Logical Design Maintenance Purpose–monitor, repair, enhance Deliverable–periodic audits Database activity– database maintenance, performance analysis and tuning, error corrections

23 Prototyping Database Methodology

24 Prototyping Database Methodology (Fig. 2.6) Pág. 47

25 Prototyping Database Methodology (Figure 2.6) Pág. 47

26 Prototyping Database Methodology (Figure 2.6)

27 Pág. 47 Prototyping Database Methodology (Figure 2.6)

28 Pág. 47 Prototyping Database Methodology (Figure 2.6)

29 USO DEL CASE EN LAS BASES DE DATOS Volver a los Objetivos

30 The Role of CASE Computer-Aided Software Engineering (CASE)– Herramientas de software que proveen un apoyo automatizado en el desarrollo de los sistemas de información. Tres herramientas para las Bases de Datos: –Data modeling – Dibuja o crea los diagramas de entidad - relación –Code generation – Genera código en SQL para la creación de tablas. –Repositories – Base de conocimientos para la información de la empresa. Pág. 49

31 NORMAS DEL NEGOCIO (Business Rules) Volver a los Objetivos

32 NORMAS DEL NEGOCIO (Business Rules) Declaraciones que definen o limitan algunos aspectos del negocio. Controla en influye en la conducta del negocio. Expresado en términos familiares para los end users. Se automatiza con el DBMS software. Influye en el diagrama ERD. Pág. 87

33 UNA BUENA REGLA (NORMA) DE NEGOCIO Debe ser declarativa. Que diga el que, no el como Precisa y clara, que tenga significado. Que sea Atomic. Que se pueda definir en una sola oración. Consistente. Interna y externamente Expresable, estructurada y en lenguaje natural. No debe ser redundante. Debe ser entendible por los usuarios de negocios. Pág. 89

34 CARACTERÍSTICAS DE UNA BUENA REGLA DE NEGOCIO Pág. 89

35 DATA NAMES (NOMBRE DE LOS DATOS) Volver a los Objetivos

36 UN BUEN DATA NAME DEBE: Estar relacionado al negocio, no a características técnicas. Tener significado y auto documentada. Legible Compuesto de palabras de una lista previamente aprobada. Repetible Pág. 91

37 MODELACIÓN (MODELING) Volver a los Objetivos

38 MODELACIÓN (MODEL) Herramienta útil para comunicar y organizar ideas. Debe ser lo más estándar posible y debe evitar ambigüedades Los flujogramas, PAC, diagramas jerárquicos, diagrama estructurado, etc. son ejemplos de modelación. El modelo que nos interesa es el modelo entidad-relación.

39 MODELACIÓN - 2 Es una forma de recolectar la información sobre la organización. Presenta la información de una forma clara y precisa. Debe ser fácil de desarrollar y modificar. Minimiza cambios en el sistema y en caso de haberlos, facilita la evaluación. Facilita el trabajo en equipo al mejorar la comunicación de las ideas.

40 TIPOS DE MODELOS Los modelos tienen diferentes niveles de abstracción. En este caso los niveles son Conceptual, lógico y físico. Cada uno tiene su propósito y se van a discutir en los próximos slides. No existe un acuerdo estándar que indique en donde termina un nivel y comienza el otro, pero si existen unos conceptos que más o menos indican las peculiaridades de cada nivel.

41 MODELO CONCEPTUAL Muestra las necesidades de la Base de Datos a nivel general. Sólo se muestran los conceptos más básicos. No se especifican todos los atributos de las tablas, ni se resuelven las relaciones muchos a muchos. Tampoco hay que poner todos los UID (Unique ID o primary key) de las tablas. El propósito es dar una idea general de la Base de Datos.

42 MODELO LÓGICO Se ajusta al modelo de Base de Datos en particular. En el caso del modelo relacional, se resuelven las relaciones muchos a muchos, se identifican todos los atributos, UID y campos foráneos. La Base de Datos debe estar normalizada y preparada para poder implementarse físicamente.

43 MODELO FÍSICO La Base de Datos se implementa en una computadora utilizando el software apropiado. Por ejemplo Oracle, SQL server, MySql, DB2, Informix, etc. Aquí se debe tomar en cuenta las llaves foráneas (foreign keys), los índices, las vistas (views), integridad referencial, restricciones (constraints) entre otras cosas.

44 TERMINOLOGÍA DE DATOS Volver a los Objetivos

45 TERMINOLOGÍA DE DATOS TRADICIONALBASE DE DATOS BASE DE DATOS RELACIONAL ArchivoEntidadTabla RecordInstancia, tuploFila CampoAtributoColumna

46 DEFINICIONES BASE DE DATOS Volver a los Objetivos

47 BASE DE DATOS - Definiciones Entidades – Algo importante que deseamos almacenar. Por ejemplo: Una persona, evento, lugar, categoría o cualquier otra cosa que se le pueda nombrar. Atributos – Datos que describen a la entidad y por lo tanto necesitamos almacenarlas. Relaciones – Define como las entidades se relacionan entre si.

48 ENTIDADES Volver a los Objetivos

49 ENTIDADES Una ENTIDAD representa una persona, lugar, objeto, evento o concepto dentro del ambiente de Sistemas de información. Por lo tanto a cada entidad se le asigna un nombre propio. Deseamos guardar datos dentro de una entidad. A continuación mostramos ejemplos de entidades. Pág. 96

50 EJEMPLO DE ENTIDADES PERSONA: ESTUDIANTE, EMPLEADO, PACIENTE LUGAR: ALMACEN, WAREHOUSE, ESTADO, PUEBLO OBJETO: MAQUINA, EDIFICIO, AUTOMOVIL, LIBRO EVENTO: VENTA, MATRICULA, RENOVACION, QUEJA, COBRO, PAGO, TRASLADO, TAREA, TRANSFERENCIA, ASIGNACION, CONTACTO CONCEPTO: CUENTA, CURSO, CENTRO DE TRABAJO Pág. 96

51 UNA ENTIDAD DEBE SER: –Un objeto que tenga muchas instancias en la Base de Datos. –Un objeto que se componga de múltiples atributos –Un objeto que se pueda diseñar y representar (model). NO DEBE SER: –Un usuario del sistema de Base de Datos –Un resultado (output) de la Base de Datos (ejemplo; un reporte)

52 Inappropriate entities Systemuser System output Figure 3-4 Example of inappropriate entities Appropriate entities Pág. 97

53 Entities “something that users track” Page 49 Figure 3-1 © 2000 Prentice Hall Yufei Yuan Course Web Site

54 ENTITY TYPE VS ENTITY INSTANCE Un entitity type es una colección de entidades que comparten propiedades o características comunes. Un entity instance es una sola ocurrencia de un entity type. Hay que tener cuidado en no confundir ambos términos. Pág. 96

55 ENTITY TYPE VS ENTITY INSTANCE - EJEMPLO Pág. 96

56 STRONG VS WEAK ENTITY Strong Entity - Una entidad que existe independientemente de cualquier otra entidad. Weak Entity - Una entidad cuya existencia depende de alguna otra entidad. Identifying Owner - El tipo de entidad en el cual el tipo de entidad débil (weak) depende. Identifying Relationship - Relación entre una entidad débil y su owner. Págs. 97 - 98

57 STRONG VS WEAK ENTITY (CONT.) Strong entities –Existen independientemente de otros tipos de entidades –Tienen su propio identificador único (unique identifier, campo clave) Weak entity –Depende de una entidad fuerte (strong), no puede existir por cuenta propia –No tiene un identificador único, solo uno parcial Págs. 97 - 98

58 EJEMPLO DE LA RELACIÓN ENTRE UNA ENTIDAD FUERTE (STRONG) Y OTRA DÉBIL (WEAK) Pág. 98

59 REGLAS PARA DAR NOMBRE A LAS ENTIDADES Una entidad debe tener un nombre singular. (ejemplo CLIENTE, ESTUDIANTE, etc.) Debe ser específico para la organización. (ejemplo; una organización puede utilizar el nombre CUSTOMER y otra CLIENT o CLIENTE vs CONSUMIDOR) Debe ser conciso ya que debe utilizar la menor cantidad de palabras posible (preferiblemente una). Págs. 98 - 99

60 REGLAS PARA DAR NOMBRE A LAS ENTIDADES (CONT.) - 1 Si se utiliza abreviaciones, también deben ser específicas y descriptivas. Se debe mantener el mismo nombre en toda la base de datos. No duplicados. El nombre a utilizarse puede ser el resultado de un evento. Por ejemplo si se va a registrar los proyectos asignados a un empleado ASIGNACION puede ser un nombre. Si un estudiante esta contactando a un profesor y ese proceso se quiere registrar, se puede llamar CONTACTO. Págs. 98 - 99

61 ATRIBUTOS Volver a los Objetivos

62 ATRIBUTOS Pág. 100 Attribute – Propiedad o característica de una entidad o de un tipo de relación. Tipos de atributos: (se discuten más adelante) –Required versus Optional Attributes –Simple versus Composite Attribute –Single-Valued versus Multivalued Attribute –Stored versus Derived Attributes –Identifier Attributes

63 EJEMPLOS DE ATRIBUTOS ENTIDAD CLIENTE número nombre dirección teléfono crédito e-mail ENTIDAD ESTUDIANTE número nombre edad genero departamento igs escuela procedencia

64 ATRIBUTOS - Required versus Optional Required attribute - Necesita tener un valor por cada instancia que tenga la entidad. –Ejemplo: nombre, género, seguro social, etc. Optional attribute - No es necesario que toda instancia de una entidad tenga un valor en ese atributo en particular. –Ejemplo: teléfono, celular, etc. Pág. 100

65 Required versus Optional - EJEMPLO Mal ejemplo Pág. 101

66 ATRIBUTOS - Simple versus Composite Attribute Simple (or atomic) Attribute - Un atributo que no se puede descomponer en sub- componentes que sean significativos para la organización. –Ejemplo; edad, género, peso, etc. Composite Attribute - Un atributo que tiene componentes significativos (sub- componentes). –Ejemplo; nombre, dirección, etc. Pág. 101

67 Simple versus Composite Attribute - EJEMPLO Págs. 101 - 102 Composite Simple Figure 3-7 A composite attribute

68 ATRIBUTOS - Single-Valued versus Multivalued Attribute Single-Valued Attribute - Atributo que sólo puede tomar un valor en cualquier instancia de una entidad. –Ejemplo: género, fecha de nacimiento, etc. Multivalued Attribute - Atributo que puede tomar más de un valor para cualquier instancia de una entidad. –Ejemplo; en la figura del slide anterior, el atributo skill de la entidad EMPLOYEE tiene más de un valor. Otros ejemplos podrían ser: fecha de contacto, puesto, tareas, etc. Pág. 102

69 ATRIBUTOS - Stored versus Derived Attributes Stored Attributes - Su valor no se deriva ni se calcula utilizando otros valores. –Ejemplo: salario por hora, horas trabajadas, etc. Derived Attributes - Atributos cuyos valores pueden ser calculados de otros atributos relacionados. También pueden ser creados por data fuera del sistema como lo son la fecha y la hora o algún código entrado por un usuario. Ejemplo; el tiempo que lleva trabajando un empleado en la empresa. –Ejemplo: Sueldo bruto, edad actual, total de ventas, años en la empresa Pág. 102

70 Multivalued an employee can have more than one skill Derived from date employed and current date Págs. 101 - 102 Figure 3-8 Entity with multivalued attribute (Skill) and derived attribute (Years_Employed) Atributos multivalued & derived - Ejemplos

71 ATRIBUTOS - Identifier Attributes Identifier - Atributo (o combinación de atributos) que distingue cada instancia de la entidad haciéndola única. Debe ser un atributo cuyo valor nunca se repita. Simple identifier - Su valor no está sub- dividido en más de un atributo. –Ejemplo: Seguro social, número de empleado Composite identifier - Un identifier que tiene valores de más de un atributo. –Ejemplo: numero de cliente + número de orden Pág. 103

72 Identifier Attributes (simple vs composite)- Ejemplos Composite identifier Simple Identifier Pág. 103

73 Figure 3-19 Simple example of time-stamping This attribute that is both multivalued and composite Ejemplo de un atributo multivalued y composite

74 Características de los Identifiers (Primary Key) No cambiará de valor No será Nulo (null) No pueden ser “inteligentes”. Por ejemplo no pueden tener valores que puedan cambiar como una dirección, nombre, edad o algún código que represente un valor que sea variable. Trate de utilizar identifiers simples (de un solo atributo) siempre que se pueda. A los identifiers se les conoce también como UID (Unique Identifier) y primary key. Pág. 103

75 Ejemplos de UID CLIENTE número nombre seguro social dirección teléfono crédito e-mail ESTADIO (PARQUE) id nombre dirección teléfono capacidad sillas capacidad carros El número del cliente es muy buen candidato para un UID ya que su valor es único El seguro social también podría ser un buen candidato para un UID. En el caso de un estadio, necesitamos crear un atributo artificial que posea un valor único para que identifique cada instancia de la entidad.

76 REGLAS PARA NOMBRAR Y DEFINIR ATRIBUTOS Un atributo debe llevar un nombre o frase singular. Ejemplo; cliente, precio del producto Deben ser únicos. No pueden existir dos atributos de la misma entidad con el mismo nombre. Para lograr que un atributo sea único, se sugiere el uso de alguna regla estándar. Por ejemplo el uso de prefijos. Pág. 104

77 REGLAS PARA NOMBRAR ATRIBUTOS (GUÍAS) Su nombre establece lo que es el atributo y porque es importante. También establece claramente que incluye o no. El alias (aliases) o nombre alterno del atributo, puede ser especificado. Es deseable que el nombre establezca la fuente del valor del atributo (de donde proviene). Pág. 105

78 INFORMACIÓN ADICIONAL SOBRE ATRIBUTOS Los atributos deben describir a una entidad en una de las siguientes formas: –Identificándola –Calificándola –Clasificándola –Cuantificándola –Expresando su estado Pág. 105

79 INFORMACIÓN ADICIONAL SOBRE ATRIBUTOS - Cont. Ejemplo, en la ENTIDA EMPLEADO: –El número lo identifica –El nombre lo califica –El puesto lo clasifica –La edad lo cuantifica –El estado (status) expresa su estado. (activo, con licencia, retirado, etc.) Pág. 105

80 RELACIONES Volver a los Objetivos

81 RELACIONES Es una asociación bidireccional (ambas direcciones) e imprescindible entre dos o tres entidades o entre una entidad y ella misma. La relación entre las entidades se conoce como Degree.

82 Degree of Relationships Indica el número de tipos de entidades que participan en la relación –Unary Relationship - Entre la misma entidad. –Binary Relationship - Entre dos entidades. –Ternary Relationship - Entre tres entidades. Pág. 109 - 112

83 Degree of relationships – from Figure 3-2 Entities of two different types related to each other Entities of three different types related to each other One entity related to another of the same entity type Pág. 95

84 Figure 3-12 Examples of relationships of different degrees a) Unary relationships Pág. 110

85 Figure 3-12 Examples of relationships of different degrees (cont.) b) Binary relationships Pág. 110

86 Figure 3-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own Pág. 110

87 OTRO EJEMPLO DEL GRADO DE RELACIONES Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

88 Tipos de Relaciones One-to-One (uno a uno) –Cada entidad en la relación va a tener exactamente una relación en sus instancias. One-to-Many (uno a muchos) –La entidad de una parte tiene relación con muchas instancias de la otra entidad, pero cada instancia de la otra entidad sólo puede tener relación con una instancia de la primera entidad. Many-to-Many (muchos a muchos) –En ambas entidades en la relación, existen relaciones de muchos a muchos.

89 UNO A UNO - EJEMPLOS 11 CARRO tablilla marca modelo MOTOR número descripción posee está asignado

90 UNO A MUCHOS - EJEMPLOS DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por estar asignado M∞M∞ 1

91 MUCHOS A MUCHOS - EJEMPLOS M∞M∞ M∞M∞ ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar tomado por

92 TEMAS ADICIONALES DE RELACIONES Volver a los Objetivos

93 Temas adicionales de Relaciones Relationship Types vs. Relationship Instances –Relationship Types - El tipo de relación se modela como líneas entre los tipos de entidades. –Relationship Instances - La instancia se refiere a instancias específicas de la relación Las relaciones pueden tener atributos –Estos describen capacidades pertinentes a la asociación entre las entidades en la relación. Dos entidades pueden tener más de un tipo de relación entre ellos (multiple relationships) Associative Entity – Combinación de relaciones y entidad Pág. 107

94 Strong entity Weak entity Identifying relationship Pág. 98 Relación entre una entidad fuerte y otra débil

95 a) Mandatory cardinalities A patient must have recorded at least one history, and can have many A patient history is recorded for one and only one patient Pág. 116 Figure 3-17 Examples of cardinality constraints Relación con Cardinalidad Mandatoria

96 b) One optional, one mandatory An employee can be assigned to any number of projects, or may not be assigned to any at all A project must be assigned to at least one employee, and may be assigned to many Pág. 116 Figure 3-17 Examples of cardinality constraints (cont.) Relación con una Cardinalidad Mandatoria y otra Opcional

97 Figure 3-10 Relationship types and instances a) Relationship type b) Relationship instances Pág. 106 Tipos de Relaciones y Relaciones de Instancias

98 a) Optional cardinalities A person is married to at most one other person, or may not be married at all Pág. 116 Figure 3-17 Examples of cardinality constraints (cont.) Relación con Cardinalidad Opcional

99 Entities can be related to one another in more than one way a) Employees and departments Pág. 120 Figure 3-21 Examples of multiple relationships Ejemplo de Múltiples Relaciones

100 b) Professors and courses (fixed lower limit constraint) Here, min cardinality constraint is 2 Pág. 120 Figure 3-21 Examples of multiple relationships (cont.) Ejemplo de Múltiples Relaciones (cont.)

101 simple composite Pág. 114 Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships Atributos Multivalorados que pueden ser Representados como Relaciones

102 Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship Pág. 108 Ejemplo de Relación Binaria que Contiene un Atributo

103 Figure 3-11b An associative entity (CERTIFICATE) Pág. 108 Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right. Note that the many-to-many cardinality between entities in Figure 3-11a has been replaced by two one-to-many relationships with the associative entity. Ejemplo de Relación con Entidad Asociativa

104 Figure 3-13c An associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call Pág. 111 Otro Ejemplo de Relación con Entidad Asociativa

105 Figure 3-18 Ternary relationship as an associative entity Pág. 112 Ejemplo de Relación Ternaria con una Entidad Asociativa

106 REFERENCIAS Modern Database Management 8th Edition, Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Yufei Yuan Course Web Site Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel