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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. 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.
No additional notes provided.
Prof Dr. M. A. Rouf, Dept. of CSE, DUET

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

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

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

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

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

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

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

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

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