System Design (Relationship)

Slides:



Advertisements
Similar presentations
Alternative Approach to Systems Analysis Structured analysis
Advertisements

Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Modeling the Data: Conceptual and Logical Data Modeling
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 7.1.
System Analysis - Data Modeling
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model.
Review Questions What is data modeling? What is the actual data model that is created called? Data modeling is a technique for organizing and documenting.
Data Modeling Entity - Relationship Models. Models Used to represent unstructured problems A model is a representation of reality Logical models  show.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Fundamentals, Design, and Implementation, 9/e COS 346 Day 2.
Lesson-19 Data Modeling and Analysis
BIS310: Week 7 BIS310: Structured Analysis and Design Data Modeling and Database Design.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
Entity Relationship Modeling Objectives: To illustrate how relationships between entities are defined and refined. To know how relationships are incorporated.
Copyright Irwin/McGraw-Hill Data Modeling Introduction  The presentation will address the following questions:  What is systems modeling and what.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
CSE314 Database Systems Data Modeling Using the Entity- Relationship (ER) Model Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Chapter 4 The Relational Model.
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.
IMS 4212: Introduction to Data Modeling—Relationships 1 Dr. Lawrence West, Management Dept., University of Central Florida Relationships—Topics.
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling.
Lecture # 14 Chapter # 5 The Relational Data Model and Relational Database Constraints Database Systems.
Data Modeling Using the Entity- Relationship (ER) Model
COP Introduction to Database Structures
Modeling data in the Organization
Database Design Chapters 17 and 18.
Entity Relationship Modeling
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Logical Database Design and the Rational Model
Business System Development
Entity- Relationship (ER) Model
Chapter 5 Database Design
DATA REQIREMENT ANALYSIS
Entity Relationship (E-R) Modeling
The presentation will address the following questions:
Chapter 6 Structuring System Requirements: Conceptual Data Modeling
Entity Relationship (E-R) Modeling
Chapter 5: Logical Database Design and the Relational Model
Outline of the ER Model By S.Saha
Lecture on Data Modeling and Analysis
Accounting Information Systems 9th Edition
ERD :: 19 / 1 / Entity-Relationship (ER) Modeling. ER Modeling is a top-down approach to database design. Entity Relationship (ER) Diagram –A.
Database Design Using the REA Data Model
COS 346 Day 8.
Overview of Entity‐Relationship Model
Chapter 7 Structuring System Requirements: Conceptual Data Modeling
Entity-Relation Modeling
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Chapter 20 Object-Oriented Analysis and Design
Database Design Chapters 17 and 18.
Database Systems Instructor Name: Lecture-9.
Chapter 5 Advanced Data Modeling
The presentation will address the following questions:
Chapter 3: Modeling Data in the Organization
Chapter 4 Entity Relationship (ER) Modeling
Database Processing: David M. Kroenke’s Chapter Five:
Entity-Relationship Diagram (ERD)
Chapter 7 Structuring System Requirements: Conceptual Data Modeling
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
From conceptual to relational data model
Entity Relationship (ER) Modeling
Relationships—Topics
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

System Design (Relationship) Dr. M. A. Rouf Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Conceptually, entities and attributes do not exist in isolation. Entities interact with, and impact one another via relationships to support the business mission. A relationship is a natural business association that exists between one or more entities. The relationship may represent an event that links the entities, or merely a logical affinity that exists between the entities. A connecting line between two entities on an ERD represents a relationship. A verb phrase describes the relationship. All relationships are implicitly bidirectional, meaning that they can interpreted in both directions. 179 Consider, for example the entities STUDENT and CURRICULUM. We can make the following business assertions that link students and courses: a current STUDENT IS ENROLLED IN one or more CURRICULA a CURRICULUM IS BEING STUDIED BY zero, one, or more STUDENTs The underlined verb phrases define business relationships that exist between the two entities. Because a STUDENT can be enrolled in many CURRICULA, and a CURRICULUM can enroll many STUDENTs, this is often called a many-to-many relationship. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

179-180 Figure 5.2 A Relationship (Many-to-Many) The figure above also shows the complexity or degree of each relationship. For example, in the above business assertions, we must also answer the following questions: Must there exist an instance of STUDENT for each instance of CURRICULUM? No! Must there exist an instance of CURRICULUM for each instance of STUDENT? Yes! How many instances of CURRICULUM can exist for each instance of STUDENT? Many! How many instances of STUDENT can exist for each instance of CURRICULUM? Many! Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Cardinality: Each relationship on an ERD also depicts the complexity or degree of each relationship and this is called cardinality. Cardinality defines the minimum and maximum number of occurrences of one entity for a single occurrence of the related entity. Because all relationships are bi-directional, cardinality must be defined in both directions for every relationship. 180 Consider, for example the entities STUDENT and CURRICULUM. We can make the following business assertions that link students and courses: a current STUDENT IS ENROLLED IN one or more CURRICULA a CURRICULUM IS BEING STUDIED BY zero, one, or more STUDENTs The underlined verb phrases define business relationships that exist between the two entities. Because a STUDENT can be enrolled in many CURRICULA, and a CURRICULUM can enroll many STUDENTs, this is often called a many-to-many relationship. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

180-181 Figure 5.3 Cardinality Notations Conceptually, cardinality tells us the following rules about the data we want to store: When we insert a STUDENT instance in the database, we must link (associate) that STUDENT to at least one instance of CURRICULUM. In business terms, “a student cannot be admitted without declaring a major.” (Note: Most schools would include an instance of CURRICULUM called “undecided” or “undeclared”.) A STUDENT can study more than one CURRICULUM, and we must be able to store data that indicates all CURRICULA for a given STUDENT. We must insert a CURRICULUM before we can link (associate) STUDENTs to that CURRICULUM. That is why a CURRICULUM can have zero students – no students have yet to be admitted to that CURRICULUM. Once a CURRICULUM has been inserted into the database, we can link (associate) many STUDENTs with that CURRICULUM. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Degree: The degree of a relationship is the number of entities that participate in the relationship. A binary relationship has a degree = 2, because two different entities participated in the relationship. Relationships may also exist between different instances of the same entity. This is called a recursive relationship (sometimes called a unary relationship; degree = 1). 180 For example, in your school a course may be a prerequisite for other courses. Similarly, a course may have several other courses as its prerequisite Prof Dr. M. A. Rouf, Dept. of CSE, DUET

181 Figure 5.4 A Recursive Relationship No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Degree: (continued) Relationships can also exist between more than two different entities. These are sometimes called N-ary relationships. A relationship existing among three entities is called a 3-ary or ternary relationship. An N-ary relationship maybe associated with an associative entity. An associative entity is an entity that inherits its primary key from more than one other entity (parents). Each part of that concatenated key points to one and only one instance of each of the connecting entities. 180 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

181-182 Figure 5.5 A Ternary Relationship In the figure above, the associative entity SCHEDULED CLASS (notice the unique shape) matches a COURSE, a ROOM, and an INSTRUCTOR. For each instance of SCHEDULED CLASS the key indicate which COURSE ID, which ROOM ID and which INSTRUCTOR ID is combined to form that class. Also shown above, an associative entity can be described by its own non-key attributes. In addition to the primary key, a SCHEDULED CLASS is described by the attributes DIVISION NUMBER, DAYS OF WEEK, START TIME, AND END TIME. If you think about it, none of these attributes describes a COURSE, ROOM, or INSTRUCTOR – they describe a single instance of the relationship between an instance of each of those three entities. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Foreign Keys: A relationship implies that instances of one entity are related to instances of another entity. To be able to identify those instances for any given entity, the primary key of one entity must be migrated into the other entity as a foreign key. A foreign key is a primary key of one entity that is contributed to (duplicated in) another entity for the purpose of identifying instances of a relationship. A foreign key (always in a child entity) always matches the primary key (in a parent entity). 182-183 For example, consider a relationship between the entities MAJOR and DEPARTMENT. A CURRICULUM is taught by exactly one DEPARTMENT. For a CURRICULUM, which DEPARTMENT teaches it? A DEPARTMENT teaches one or more CURRICULA. For a CURRICULUM, which STUDENTs are enrolled in that CURRICULUM? Prof Dr. M. A. Rouf, Dept. of CSE, DUET

183 Figure 5.6 How to Show Foreign Keys In the figure above, we demonstrate the concept of foreign keys with our simple data model. In this case, DEPARTMENT is called the parent entity and CURRICULUM is the child entity. The primary key is always contributed by the parent to the child as a foreign key. Thus, an instance of CURRICULUM now has an foreign key DEPARTMENT NAME whose value points to the correct instance of DEPARTMENT that offers that curriculum. (Foreign keys are never contributed from child-to-parent.) Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Foreign Keys: (continued) When you have a relationship that you cannot differentiate between parent and child it is called a non-specific relationship. A non-specific relationship (or many-to-many relationship) is one in which many instances of one entity are associated with many instances of another entity. Such relationships are suitable only for preliminary data models, and should be resolved as quickly as possible. All non-specific relationships can be resolved into a pair of one-to-many relationships by inserting an associative entity between the two original entities. 183 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

183-184 Figure 5.7 Resolving Nonspecific Relationships with an Associative Entity In figure (a) above, we see that a CURRICULUM is being studied by zero, one, or more STUDENTs. At the same time, we see that a STUDENT is studying one or more CURRICULA. The maximum cardinality on both sides is ‘many’. So, which is the parent and which is the child? You can’t tell! This is called a non-specific relationship. All non-specific relationships can be resolved into a pair of one-to-many relationships. As illustrated in figure (b) above, each entity becomes a parent. A new, associative entity is introduced as the child of each parent. In the figure above, each instance of MAJOR represents a one STUDENT’s enrollment in one CURRICULUM. If a student is pursuing two majors, that student will have two instances of the entity MAJOR. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Generalization: Generalization is an approach that seeks to discover and exploit the commonalties between entities. Generalization is a technique wherein the attributes that are common to several types of an entity are grouped into their own entity, called a supertype. An entity supertype is an entity whose instances store attributes that are common to one or more entity subtypes. The entity supertype will have one or more one-to-one relationships to entity subtypes. These relationships are sometimes called IS A relationships (or WAS A, or COULD BE A) because each instance of the supertype ‘is also an’ instance of one or more subtypes. 183-184 Most people associate the concept of generalization with modern object- oriented techniques. In reality, the concepts have been applied by data modelers for many years. Consider, for example, an extension of the hypothetical academic scenario we’ve been using throughout this chapter. Our school enrolls STUDENTs and employs EMPLOYEEs. There are several attributes that are common to both entities; for example, NAME, GENDER, RACE, MARITAL STATUS, and possibly even a key based on SOCIAL SECURITY NUMBER. What if we consolidated these common attributes into an entity supertype called PERSON. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

System Concepts for Data Modeling Relationships Generalization: (continued) An entity subtype is an entity whose instances inherit some common attributes from an entity supertype, and then add other attributes that are unique to an instances of the subtype. An entity can be both a supertype and subtype. Through inheritance, the concept of generalization in data models permits the reduction of the number of attributes through the careful sharing of common attributes. The subtypes not only inherit the attributes, but also the data types, domains, and defaults of those attributes. In addition to inheriting attributes, subtypes also inherit relationships to other entities. 185-186 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

185-186 Figure 5.8 A Generalization Hierarchy In the above example, “a PERSON is an employee, or a student, or both.” The top half of the figure illustrates this generalization as a hierarchy. Notice that the subtypes STUDENT and EMPLOYEE have inherited attributes from PERSON, as well as adding their own. (Unfortunately, most CASE tools do not actually migrate the inherited attributes.) Notice that a STUDENT (which was a subtype of PERSON) has its own subtypes. In the diagram, we see that a STUDENT is either a PROSPECT, or a CURRENT STUDENT, or a FORMER STUDENT (having left for any reason other than graduation), and a STUDENT could be an ALUMNUS. Each of these additional subtypes inherit all of the attributes from STUDENT, as well as those from PERSON. Notice also that all EMPLOYEEs and STUDENTs inherit the relationship between PERSON and PERSONAL ADDRESS. But only EMPLOYEEs inherit the relationship with EMPLOYMENT CONTRACTs. And only an ALUMNUS can be related to a DEGREE. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Strategic Data Modeling Many organizations select application development projects based on strategic information system plans. Strategic planning is a separate project. This project produces an information systems strategy plan that defines an overall vision and architecture for information systems. Almost always, the architecture includes an enterprise data model. 186 Data modeling may be performed during various types of projects, and in multiple phases of projects. Data models are progressive—there is no such thing as the ``final’’ data model for a business or application. Instead, a data model should be considered a living document that will change in response to a changing business. Data models should ideally be stored in a repository so that they can be retrieved, expanded, and edited over time. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Strategic Data Modeling An enterprise data model typically identifies only the most fundamental of entities. The entities are typically defined (as in a dictionary) but they are not described in terms of keys or attributes. The enterprise data model may or may not include relationships (depending on the planning methodology’s standards and the level of detail desired by executive management). If relationships are included, many of them will be non-specific. The enterprise data model is usually stored in a corporate repository. 186 How does an enterprise data model impact subsequent applications development? Part of the information strategy plan identifies application development projects and prioritizes them according to whatever criteria that management deems appropriate. As those projects are started, the appropriate subsets of the information system architecture – including a subset of the enterprise data model – are provided to the application development team as a point of departure. The enterprise data model is usually stored in a corporate repository. When the application development project is started, the subset of the enterprise data model (as well as the other models) is exported from the corporate repository into a project repository. Once the project team completes systems analysis and design, the expanded and refined data models are imported back into the corporate repository Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Data Modeling During Systems Analysis The data model for a single system or application is usually called an application data model. Logical data models have a DATA focus and a SYSTEM USER perspective. Logical data models are typically constructed as deliverables of the study and definition phases of a project. Logical data models are not concerned with implementation details or technology, they may be constructed (through reverse engineering) from existing databases. Data models are rarely constructed during the survey phase of systems analysis. 187-188 Data models are rarely constructed during the survey phase of systems analysis. The short duration of that phase makes them impractical. On the other hand, if an enterprise data model exists, the subset of that model that is applicable to the project might be retrieved and reviewed as part of the survey phase requirement to establish context. Alternatively, the project team could identify a simple list of entities; the things about which they think the system will have to capture and store data. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

187 Figure 5.9 Data Modeling in the FAST Methodology No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Data Modeling During Systems Analysis Data modeling is rarely associated with the study phase of systems analysis. Most analysts prefer to draw process models to document the current system. Many analysts report that data models are far superior for the following reasons: Data models help analysts to quickly identify business vocabulary more completely than process models. Data models are almost always built more quickly than process models. A complete data model can be fit on a single sheet of paper. Process models often require dozens of sheets of paper. Process modelers too easily get hung up on unnecessary detail. 188 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Data Modeling During Systems Analysis Many analysts report that data models are far superior for the following reasons: (continued) Data models for existing and proposed systems are far more similar than process models for existing and proposed systems. Consequently, there is less work to throw away as you move into later phases. A study phase model should include only entities relationships, but no attributes – a context data model. The intent is to refine the understanding of scope; not to get into details about the entities and business rules. 188 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Data Modeling During Systems Analysis The definition phase data model will be constructed in at least two stages: A key-based data model will be drawn. This model will eliminate non-specific relationships, add associative entities, include primary, alternate keys, and foreign keys, plus precise cardinalities and any generalization hierarchies. A fully attributed data model will be constructed. The fully attributed model includes all remaining descriptive attributes and subsetting criteria. Each attribute is defined in the repository with data types, domains, and defaults. The completed data model represents all of the business requirements for a system’s database. 188 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET

The Process of Logical Data Modeling Looking Ahead to Systems Configuration and Design The logical data model from systems analysis describes business data requirements, not technical solutions. The purpose of the configuration phase is to determine the best way to implement those requirements with database technology. During system design, the logical data model will be transformed into a physical data model (called a database schema) for the chosen database management system. This model will reflect the technical capabilities and limitations of that database technology, as well as the performance tuning requirements suggested by the database administrator. The physical data model will also be analyzed for adaptability and flexibility through a process called normalization. 188 No additional notes provided. Prof Dr. M. A. Rouf, Dept. of CSE, DUET