Data Management for Decision Support BIS4435/21 Wee… · Web viewGo to specific sites, such as ,...

UNIT 3 Entity Relationship Modelling: A Traditional vs. Object Oriented Approach CHAPTER=UNIT3

STARTSECTION=scope_1 Context.htm= SECTION~

SCOPEContext

After introducing the basic concepts of data, database, and database management systems, we will begin to deal with the extremely important topic of database design. Designing a database means defining its structure, characteristics, and contents. This is a process in which many delicate decisions must be taken. The use of the appropriate techniques is therefore essential for the creation of a high-quality product.

The main approach described in this unit is called Entity-Relationship Modelling (E-R). This technique has become a widely used approach in the development of database applications. The approach is essentially top-down, in that the first step is to look at overall requirements for the application being developed, identifying the entities involved. The approach progresses from that point through the development of a detailed model of the entities, their attributes and relationships. The Entity-Relationship Modelling process is not formal, in the mathematical sense, but to accomplish the process well, requires a consistent precision to be applied to the way that entities, their relationships and their attributes are discussed.

However, to cope with the present days challenges it is required to have an extended modelling technique where business rules can be captured to represent complex scenarios. In the view of this, object modelling technique has emerged as an aid that addresses the shortcomings of E-R modelling.

In this unit, we will begin by discussing the importance of data modelling. An overall picture of the design and development of database applications will be presented with an emphasis on the structured approach to the design process. We will illustrate the Entity-Relationship (ER) model, which provides the designer with a means of data representation, known as the conceptual schema, which is used during the conceptual database design. The unit also investigates the need for further extension of the E-R modelling approach, called Enhanced E-R. This extended E-R modelling technique

captures business rules and implements constraints that enhance data quality. Furthermore, the unit shows how Unified Modelling Laguage (UML), a widely accepted object oriented modelling technique, can be applied to model business data in order to represent complex world with more semantics.

Relationship to Other Units

This unit serves as a good foundation for the rest of the module. In particular, it helps you understand the Structured Query Language (SQL) discussed in unit 4.

The E-R Modelling approach can be supplemented by methods or approaches which are more formal, and that provides a bottom-up perspective to the design process. The most commonly used of these approaches is Normalisation, which will be a core topic of learning unit 5.

ENDSECTION STARTSECTION=scope_2 Learning Outcomes.htm= SECTION~

Learning Outcomes

At the end of this unit you should be able to:

Analyse cases to identify the entities and their relationships involved Apply Entity Relationship modelling to represent entities, their relationships and

extend it further by identifying attributes for each entity

Transform the model into relations suitable for Relational database implementation

Identify the need of object oriented approach for semantic data modelling

Apply Unified modelling language to model database objects

ENDSECTION STARTSECTION=scope_3 Required Study Time.htm= SECTION~

Required Study Time

You should plan to spend approximately 18 hours studying this unit. You may find it convenient to break up your study as follows:

Activity Time

Preparation (Introduction and On-line Planning):

0.5 hrs

Disk-based Content: 4 hrs

Application: 4 hrs

Set textbook Content: 4 hrs

Thinking (On-line discussions, Review questions):

4 hrs

Tutorial Work: 1.5 hrs

Related Course Work: 0 hrs

Total: 18 Hours

ENDSECTION STARTSECTION=scope_4 Equipment and Software Required.htm= SECTION~

Equipment/Software Required

A Web browser – for browsing Web sites and Web-based database applications. Internet Explorer 5.0 is recommended.

Word Processor, i.e. Microsoft Word

ENDSECTION STARTSECTION=scope_5 Learning Journal.htm= SECTION~

Learning Journal

You will be expected to keep a learning journal throughout this module. It will help, if you keep a record of new/difficultconcepts, unusual rules and lessons learnt from the activities. You can refer to your Learning Journal at any point.

ENDSECTION STARTSECTION=scope_6 Reading Materials.htm= SECTION~

Reading Materials

Connolly, T.M., and Begg, C.E., Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 4th Edition, ISBN: 0321210255;

ENDSECTION STARTSECTION=content_1 Entities, Attributes, Values and Keys.htm= SECTION~

CONTENT3.1 Entities, Attributes, Values and Keys

Entities

Many organisations (such as businesses, government departments, supermarkets, universities, and hospitals for example) have a number of branches, divisions or sections in order to deal with a variety of functions or different geographical areas. Each branch, division or section may itself be split up into smaller units. It is possible to regard each branch, division or section (or each unit within these) as an organisation in its own right. Organisations require information in order to carry out the tasks and activities for which they are responsible. The information that these organisations need could be categorised in a number of ways, for example:

People

Payroll

Pensions

Annual leave

Sick leave

Things

Furniture

Equipment

Stationery

Fire extinguishers

Locations

Offices

Warehouses

Stock rooms

Events

Sale is made

Purchase order is raised

Item is hired

Invoice is issued

Concepts

Image of product

Advertising

Marketing

Research and development

Each of these can be regarded as an entity.

Entity

An entity may represent a category of people, things, events, locations or concepts within the area under consideration.

An entity can be of strong or weak type. The strong and weak entities can be defined as:

Strong entity: If an entity does not require any other entities to represent it, then we call it strong entity. For example, an Employee entity is a strong entity in an organisation as it is independent of any other entities.

Weak entity: On the other hand, there are entities in the business world that does not exist without the existence of some other entities. For instance, an organisation wants to keep records of the employees who have computing or typing skills. Computing or typing skills entity is a weak entity as it depends on the Employees. An employee may or may not have these skills.

Attributes

Entities have attributes. The following are typical of the attributes that an entity might possess:

Entity: House

Attributes:

Number of bedrooms Location Area of grounds type

Table 3.1

Entity: Book

Attributes:

Author Title Category Publisher ISBN

Table 3.2

Entity: Employee

Attributes:

Name address Job title Division staff number

Table 3.3

Attribute

An entity may have one or more attributes associated with it. These attributes represent certain characteristics of the entity; for a person, attributes might be name, age, address, etc.

Values

Using the entities and attributes shown above, the following are examples of two sets of values for a particular instance of each entity. Every occurrence of an entity will have its own set of values for attributes it possesses.

Entity: House

Attributes:

number of bedrooms Location area of grounds Type

Table 3.4

Values:

3 London 75 sq metres Terraced

5 Paris 125 sq metres Detached

Table 3.5

Entity: Book

Attributes:

Author Title category publisher ISBN

Table 3.6

Values:

Hanson Data Files Computing Pitman 580239

Carter Night Sun Fiction Portland 504297

Table 3.7

Entity: Employee

Attributes:

Name Address Job title Division Staff number

Table 3.8

Values:

Tan 24 Barn Lane Manager Customer Liaison

23563

Smith 99 Red Road Accountant Finance 93845

Table 3.9

Key Data Elements

If the value of certain attributes (or perhaps just one attribute) is known for a particular entity, this enables us to discover the value of other attributes associated with that entity. The attributes (or attribute) which possess this quality are known as keys, because they are able to "unlock" the values of the other attributes that are associated with that specific instance of an entity. Why do we need a key? Suppose we had two members of staff with the same (or similar) names, such as Linda Clark and Lydia Clark. It would be a simple mistake to record something in the file of Linda Clark that should be kept in the file for Lydia Clark (or the other way around). It would be even more difficult to tell them apart if the name was given as just an initial and surname.

Some names may be spelt slightly differently, but sound similar (such as Clark and Clarke), and therefore pose a further risk of identifying the wrong member of staff.

The addition of a staff number, as the primary key, would enable us to be sure that when we needed to refer to one or other of these members of staff we had identified the correct individual. In this way 11057 Clark can be distinguished from 28076 Clark.

Key

One or more attributes may act as a key, "unlocking" the other information stored about an individual. An attribute that uniquely identifies a particular instance of an entity is known as the primary key or sometimes just the key.

The following are examples of key data elements:

The payroll number (primary key) of a member of staff enables us to find out the name, job title and address for that individual.

The account number (primary key) enables us to find out whether the balance of that account is overdrawn.

The item code (primary key) in a stationery catalogue enables us to order a particular item in a particular size and colour (e.g. a red A4 folder).

Sometimes we may need to use more than one attribute in order to arrive at a key that will provide unique identification for all the other data elements. When considering which attribute (or combination of attributes) might be used as a primary key, these attributes are known as candidate keys.

Candidate keys

Where there is more than one set of attributes which could be chosen as the primary key for an entity, each of these attributes or groups of attributes are known as candidate key.

A company might choose either an employee’s staff number or an employee’s National Insurance number as the primary key, as each will provide unique identification of an individual. (Note that in different countries, a slightly different term might be used for a national code that is used to identify any one individual. Such terms might include: National ID number, etc.) The staff number and the National Insurance number are candidate keys, until one is selected as the primary key.

Sometimes we may refer to a collection of attributes that includes the primary key (for example, staff number and staff name); this group of attributes is sometimes known as a superkey.

When we need to connect together different items of data (for example, customers and items in stock can be linked together in order to produce orders and invoices), we can do this by including the primary key of one entity as a data item in another entity, for example, we would include the primary key of Customer in the Order entity in order to link customers to the Orders they have placed.

Foreign keys

When a copy of the primary key for one entity is included in the collection of attributes of another entity, the copy of the primary key held in the second entity is known as a foreign key.

A foreign key enables a link to be made between different entities.

Now carry out Activity 3.1 – Identify Entity and Attributes

Learning Outcome: Analyse cases to indentify the entities and their relationships

Now carry out Activity 3.2 – Identification of keys

Learning Outcome: Analyse cases to indentify the entities and their relationships involved.

Keep notes in your learning journal of your learning process before you proceed to the next section.

Now do Review Question 3.1



ENDSECTION STARTSECTION=content_2 Entity-Relationship Modelling.htm= SECTION~

3.2 Entity-Relationship Modelling

The relationships that exist between any two entities can be categorised in the following ways:

one-to-one one-to-many

many-to-many

One-to-One Relationships Between Two Entities

In a concert hall, each ticket holder has a seat for a single performance (the seat number will appear on the ticket). Only one person can sit in one seat at each performance; the relationship between a member of the audience and a seat is therefore one-to-one.

Pagination for paper copy only BIS4222 Unit 11 Draft V1.0 AGS Last saved: 17-Nov-09

Copyright © Middlesex University, 1999 Page 1of 77 filename: document.docAGS

TicketHolder

ConcertHall Seat

Figure 3.1

Each seat in the concert hall can be sold to one person only for a particular performance; the relationship between the seat and the member of the audience with a ticket for that seat is also one-to-one.

Figure 3.2

Relationships between entities and attributes, between attributes, and between entities can be shown in a variety of diagrammatic formats. One common method is to use entity-relationship diagrams, where each entity is represented by a box, and each relationship is shown as a line. You may also come across diagrams which employ ellipses to represent the attributes that belong to each entity. The style of the line shows the type of relationship being represented. Here, in order to represent a one-to-one relationship, a single straight line is used between the two entities.

Figure 3.3

The overall relationship between ticket holders and seats is one-to-one for each performance. The entity-relationship diagram above shows the one-to-one link between a ticket holder and a concert hall seat.

One-to-Many Relationships Between Two Entities

In an orchestra, each individual will play one type of musical instrument; for example, a person who plays a violin will not play a trumpet. The relationship is one-to-one from a member of the orchestra to a type of instrument.

TicketHolder

ConcertHall Seat

TicketHolder

ConcertHall Seat

Member of

Orchestra

MusicalInstrument

Type

1:1

1:1

1:1

Figure 3.4

An orchestra will have more than one musician playing a particular type of instrument; for example, it is likely that there will be several members of the orchestra each playing a violin. The relationship is therefore one-to-many from a type of musical instrument to a member of the orchestra

Figure 3.5

The overall relationship between these two entities is therefore one-to-many.

Figure 3.6The entity-relationship diagram shows that there is a one-to-many relationship between musical instrument types and members of the orchestra. The “crow’s foot” link shows that there may be more than one member of the orchestra for each type of musical instrument.

Many-to-Many Relationships between Two Entities

An individual may attend a series of concerts during each season as a member of the audience; the relationship between an individual and the concerts is one-to-many.

Figure 3.7

Many ticket holders will attend each concert; the relationship between a concert and members of the audience is also one-to-many.

Figure 3.8

As the relationship is one-to-many on both sides, the relationship that exists between the two entities can be described as many-to-many.

Figure 3.9

TicketHolder

ConcertPerforman

ce

TicketHolder

ConcertPerformance

Member of

Orchestra

MusicalInstrument

Type

Member of

Orchestra

MusicalInstrument

Type

N:1

1:N

M:1

TicketHolder

ConcertPerformance

The entity-relationship diagram above has a “crow’s foot” connection at each end, illustrating that there is a many-to-many relationship between ticket holders and concert performances, as one ticket holder may attend many performances, and each performance is likely to have many ticket holders present.

As it is difficult to implement a many-to-many relationship in a database system, we may need to decompose a many-to-many relationship into two (or more) one-to-many relationships. Here, we might say that there is a one-to-many relationship between a ticket holder and a ticket (each ticket holder may have several tickets, but each ticket will be held by only one person).

We could also identify a one-to-many relationship between a concert performance and a ticket (each ticket for a particular seat will be for only one performance, but there will be many performances each with a ticket for that seat).

Figure 3.10

This allows us to represent the many-to-many relationship between ticket holder and concert performance by two one-to-many relationships involving a new entity, ticket for seat. This new structure can then be implemented within a Relational database system.

ENDSECTION STARTSECTION=content_3 Degree of relationship.htm= SECTION~

3.3 Degree of Relationship

The degree of a relationship depends on the number of entities that are associated in a relationship. A relationship can be of degree 2, called binary or can be of degree 3, called ternary. It is also possible that entities estabslish a relation with its own instances and therefore, can establish a unary relationship. The unary relationship is also known as recursive relationship. The types of relationship degrees are decribed below.

Recursive Relationships

The relationships that we have seen so far have all been between two entities; this does not have to be the case. It is possible for an entity to have a relationship with

TicketHolder

Ticket for seat

Concert Performance

itself; for example an entity staff could have a relationship with itself, as one member of staff could supervise other staff. This is known as a recursive relationship, and would be represented in an entity-relationship diagram as shown below.

Figure 3.11

It is also possible for more than two entities to participate in a relationship.

Binary relationship

A binary relationship involves two entities that are associated with each other. For example, figure 3.12 shows a binary relationship. The E-R diagram indicates that a teacher teaches a module where teacher and module entities are associated with each other.

Figure 3.12

Ternary relationship

A ternary relationship involves three entities that are associated with each other. For example, figure 3.13 shows a ternary relationship. The E-R diagram indicates that a product line describes a product and keeps record of the parts that are used to build the product.

Staff

Teacher Module

Describes

Figure 3.13

Text Book Based Reading:

Connolly, T.M., and Begg, C.E., Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 4th Edition, ISBN: 0321210255

Chapter 11; Section: 11.1- 11.6.3

Now carry out Activity 3.3 – Identification of Relationship(I)

Learning Outcome: Apply Entity Relationship modelling to represent entities, their relationships and extend it further by identifying attributes for each entity

Now carry out Activity 3.4 – Identification of Relationship(II)


Now carry out Activity 3.5 – Identification of Relationship(III)


Degree of a relationship

The degree of a relationship indicates the number of entities involved.

A binary relationship (i.e. between two entities) has degree 2, a ternary relationship (between three entities) has degree 3.

In general, an n-ary relationship exists when n entities participate.

Product Line

Product

Parts




ENDSECTION STARTSECTION=content_4 Relationship Participation Condition - Membership Class.htm= SECTION~

3.4 Relationship Participation Condition (Membership Class)

Mandatory and Optional Relationships

We can extend the entity-relationship model by declaring that some relationships are mandatory, whereas others are optional. In a mandatory relationship, every instance of one entity must participate in a relationship with another entity. In an optional relationship, any instance of one entity might participate in a relationship with another entity, but this is not compulsory.

As there are two kinds of participation condition (mandatory and optional), and most entities are involved in binary relationships, it follows that there are four main types of membership relationships, as follows:

1. Mandatory for both entities2. Mandatory for one entity, optional for the other

3. Optional for one entity, mandatory for the other

4. Optional for both entities

Participation condition/Membership class

The participation condition defines whether it is mandatory or optional for an entity to participate in a relationship. This is also known as the membership class of a relationship.

It might be tempting to think that options 2 and 3 are the same, but it is important to recognise the difference, particularly when thinking about whether the relationship is one-to-one, one-to-many or many-to-many. A useful analogy is to think of a bank, with customers who have savings accounts and loans. It may be the bank's policy that any customer must have a savings account before they are eligible to receive a loan, but not all customers who have savings accounts will require a loan.

We can examine how these different types of membership class can be used to reflect the policies of allocating staff within departments. We would expect any member of staff in an organisation to work in a given department, but what happens if a new department is created, or a new member of staff joins? If we look at each combination in turn, we can see what the possibilities are:

1. Mandatory for both entities

A member of staff must be assigned to a given department, and any department must have staff. There can be no unassigned staff, and it is not possible to have an "empty" department.

2. Mandatory for one entity, optional for the other

Any member of staff must be attached to a department, but it is possible for a department to have no staff allocated.

3. Optional for one entity, mandatory for the other

A member of staff does not have to be placed in a department, but all departments must have at least one member of staff.

4. Optional for both entities

A member of staff might be assigned to work in a department, but this is not compulsory. A department might, or might not, have staff allocated to work within it.

We can elaborate the standard entity-relationship notation with a solid circle to indicate a mandatory entity, and a hollow circle for an optional entity (think of the hollow circle like "o" for optional). (You may find alternative notations in other texts, for example, a solid line to represent a mandatory entity, and a dotted line to indicate

an optional entity. Another method places solid circles inside entity boxes for mandatory participation, or outside entity boxes for optional membership.) The use of a graphical technique enables us to represent the membership class or participation condition of an entity and a relationship in an entity-relationship diagram.

We will now explore these possibilities using a performer, agents and bookings scenario as an example, but experimenting with different rules to see what effect they have on the design of the database. Supposing to start with, we have the following situation:

There are a number of performers who are booked by agents to appear at different venues. Performers are paid a fee for each booking, and agents earn commission on the fee paid to each performer. We will now consider relationships of different kinds between these entities.

One-to-One Relationships and Participation Conditions

Both ends mandatory:

It might be the case that each performer has only one agent, and that all bookings for any one performer must be made by one agent, and that agent may only make bookings for that one performer. The relationship is one-to-one, and both entities must participate in the relationship.

Figure 3.19

The solid circle at each end of the relationship shows that the relationship is mandatory in both directions; each performer must have an agent, and each agent must deal with one performer.

One end mandatory, other end optional:

performer agent

It might be possible for agents to make bookings that do not involve performers, for example, a venue might be booked for an art exhibition. Each performer, however, must have an agent, although an agent does not have to make a booking on behalf of a performer.

Figure 3.20

The solid circle at the performer end of the relationship illustrates that a performer must be associated with an agent. The hollow circle at the agent end of the relationship shows that an agent could be associated with a performer, but that this is not compulsory. Each performer must have an agent, but not all agents represent performers.

One end optional, other end mandatory:

It might be possible for performers to make bookings themselves, without using an agent. In this case, one performer might have an agent, and that agent will make bookings for that performer. One the other hand, a different performer might elect to make their own bookings, and will not be represented by an agent. All agents must represent a performer, but not all performers will be represented by agents. The relationship is optional for the performer, but mandatory for the agent, as shown in the diagram below.

Figure 3.21

The solid circle at the agent end of the relationship shows each agent must be associated with a performer. The hollow circle at the performer end of the relationship indicates that a performer could be represented by an agent, but that this is not compulsory. Each agent must deal with only one performer, but each performer does not have to have an agent.

Both ends optional:

performer agent

agentperformer

Another possibility is that agents may make bookings that do not involve performers, for example, a venue might be booked for an art exhibition. In addition, performers may make bookings themselves, or might have bookings made by an agent, but if a performer has an agent, there must be a one-to-one relationship between them. This relationship is optional for both entities.

Figure 3.22

The hollow circles show that there is an optional relationship between a performer and an agent; if there is a relationship, it will be one-to-one, but it is not compulsory either for the performer, or for the agent.

One-to-Many Relationships and Participation Conditions

It might be the case that a performer has only one agent, and that all bookings for any one performer must be made by one agent, although any agent may make bookings for more than one performer.


A performer must have one or more bookings; each booking must involve one performer.

Figure 3.23

The membership class is mandatory for both entities, as shown by the solid circle. In this case, it is not possible for a booking to be made for an event that does not involve a performer (for example, a booking could not be for an exhibition).


performer agent

BookingPerformer

A performer must have one or more bookings, but a booking might not involve a performer (e.g. a booking might be for an exhibition, not a performer).

Figure 3.24

The solid circle shows the compulsory nature of the relationship for a performer; all performers must have bookings. The hollow circle shows that it is optional for a booking to involve a performer. This means that a performer must have a booking, but that a booking need not have a performer.


A performer might have one or more bookings; each booking must involve one performer.

Figure 3.25

The membership class is mandatory for a booking, but optional for a performer. This means that it would not be possible for a booking to be for an exhibition, as all bookings must involve a performer. On the other hand, it is not compulsory for a performer to have a booking.

Both ends optional:

A performer might have one or more bookings; a booking might be associated with a performer.

BookingPerformer

BookingPerformer

Figure 3.26

In this case, a booking could be for an exhibition as it is optional for a booking to involve a performer, as indicated by the hollow circle. A performer might decline to accept any bookings; this is acceptable, as it is optional for a performer to have a booking (shown by the hollow circle).

Many-to-Many Relationships and Participation Conditions

We could say that there is a many-to-many relationship between performers and agents, with each agent making bookings for many performers, and each performer having bookings made by many agents.

We know that we need to decompose many-to-many relationships into (usually) two one-to-many relationships, but we can still consider what these many-to-many relationships would look like before this decomposition has taken place. We will see later that many-to-many relationships can be converted into relations either after they have been decomposed, or directly from the many-to-many relationship. The result of the conversion into relations will be the same in either case.


An example here might be where each performer must be represented by one or more agents, and each agent is required to make bookings for a number of performers.

Figure 3.27

There is a many-to-many relationship between the two entities, in which both entities must participate. Agents are not allowed to make bookings for events that do not

BookingPerformer

performer agent

involve performers (such as conferences or exhibitions). Performers must have bookings made by agents, and are not allowed to make their own bookings.


In this example, it is still necessary for performers to be represented by a number of agents, but the agents now have more flexibility as they do not have to make bookings for performers.

Figure 3.28

There is a many-to-many relationship between the two entities; one must participate, but it is optional for the other entity.


Here, performers have the flexibility to make their own bookings, or to have bookings made by one or more agents. Agents are required to make bookings for performers, and may not make arrangements for any other kind of event.

Figure 3.29

There is a many-to-many relationship between the two entities; it is optional for one to participate, but participation is mandatory for the other entity.

Both ends optional:

performer agent

performer agent

Here, performers and agents are both allowed a degree of flexibility. Performers may make their own bookings, or may have agents make bookings for them. Agents are permitted to make bookings for a number of performers, or have the ability to make other kinds of bookings where performers are not required.

Figure 3.30

There is a many-to-many relationship between the two entities; participation is optional for both entities.

These many-to-many relationships are likely to be decomposed into one-to-many relationships. The mandatory/optional nature of the relationship must be preserved when this happens.



Chapter 11 – Section 11.6.5

Now carry out Activity 3.6 – Case study: Theatrical Database


Use the online discussion facility and post your comments on the topic for discussion for your group to share in.


ENDSECTION STARTSECTION=content_5 Converting Entity Relationships into Relations.htm= SECTION~

performer agent

3.5 Converting Entity Relationships into Relations

When we have identified the main entities and the relationships that exist between them, we are in a position to translate the entity-relationship model that we have built from a diagram into tables of data that will form the relations for our database. The nature of the relationships between entities will make a difference to the nature of the relations that we construct; the cardinality, degree and membership class will all affect the structure of the database.

If we design a database by using an entity-relationship model, we need to be able to convert our design from a diagrammatic format into a series of relations that will hold the values of the actual data items.

It would be possible to create a number of relations so that each represented either an entity or relationship. This approach would generate a relational database that represented the entities and the relationships between them as identified in our data model, but it would suffer from a number of disadvantages. One disadvantage would be that the number of relations created could result in the database being unnecessarily large. There are also a number of insertion, update and deletion anomalies that will be examined in the unit on Normalisation, to which a database created in such a way would be vulnerable. In order to avoid these problems, we need to specify a method that allows us to create only those relations that are strictly necessary to represent our data model as a database. The way in which we do this is guided by the nature of the relationships between the entities, in terms of the cardinality and the membership class (participation condition).

Converting One-to-One Relationships into Relations

We can transform entity-relationship diagrams into relations by following simple rules which will specify the number of relations needed, depending on the cardinality (one-to-one, one-to-many or many-to-many) and the membership class (mandatory or optional) of the entities participating in the relationship. In the case of one-to-one relationships, the creation of one or two relations is sufficient, depending on whether participation is mandatory or optional.

Mandatory for Both Entities

A single relation will be able to represent the information represented by each entity and the relationship that exists between them.

If we consider an earlier example, with a one-to-one mandatory relationship between performers and agents, this could now be converted from a diagram into a relation as part of our database.

Figure 3.31

This part of an entity-relationship model can be converted into a single relation, Performer-details. This relation holds information about all the performers and their agents. The agents do not need to be held in a separate relation as each performer has one agent, and each agent represents only one performer.

Relation: Performer-details

Perf-id

Perf-name Perf-type

Perf-Loc’n

Agent-id

Agent-name

Agent-Loc’n

0548 Takis Bakalis Comedian York 1653 Smith Moscow0556 Mary Marsh Singer Dublin 1304 Alton Sydney0717 Anjuli Misra Dancer Paris 1592 West Penang0832 David Ho Actor Beijing 1727 Elgin Rome

Table 3.10

In the relation Performer-details above, we can see that all performer information is stored and can be accessed by the performer-id attribute, and all agent information can be extracted by means of the agent-id attribute.

As the relationship is one-to-one and mandatory in both directions, we do not need to store the performers and agents in separate relations although we could choose to do so. (If we stored performers and agents in separate relations, we would then need to use the identifying attributes of performer-id and agent-id as foreign keys. This means that we would be able to identify the relevant agent in the performer relation, and identify the appropriate performer in the agent relation.)

Mandatory for One Entity, Optional for the Other Entity

Performer Agent

In this case, two relations will be needed, one for each entity. The relationship could be mandatory for the first entity and optional for the second, or the other way around. There are therefore two possibilities for performers and agents.

In this first example, a performer must be represented by an agent, but an agent does not have to represent a performer. The relationship is therefore mandatory for a performer, but optional for an agent.

Figure 3.32

This would convert into two relations, one for each entity. The agent identifier is stored in the Performer relation in order to show the connection between agents and performers where appropriate. This is known as posting an identifier (or posting an attribute). It is important that the value of a posted identifier is not null.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n Agent-id1589 Thomas Wong Magician Taipei 48371873 Shirley Sure Dancer Chicago 54901903 Darryl Burns Comedian Berlin 29362005 Charlotte Chong Musician Beijing 3895

Table 3.11

Note that the agent identifier, agent-id, is held in the Performer relation. The attribute agent-id is a foreign key in the Performer relation. This means that we can identify which agent represents a particular performer.

We would not want to store the performer-id in the Agent relation for this example, as there are agents who do not represent performers, and there would therefore be a null value for the performer-id attribute in the Agent relation. We can see that there are agents in the Agent relation who do not represent performers, but all performers are represented by only one agent.

Relation: Agent

Performer Agent

Agent-id Agent-name Agent-Loc’n2936 Alice Truman London3246 Jaimin Khetia Nairobi3895 Steve Murphy Cairo4837 Angela Demetriou Athens5386 Priti Popat Chicago5490 Charles Patterson Rome

Table 3.12

In the second example, an agent must represent a performer, but a performer does not need to have an agent. Here, the relationship is optional for a performer, but mandatory for an agent.

Figure 3.33

Again, this would translate into two relations, one for each entity. On this occasion, however, the link between performers and agents will be represented in the Agent relation rather than the Performer relation. This is because every agent will be associated with a performer, but not all performers will be linked to agents. The performer-id is a foreign key in the agent relation. We cannot have the agent identifiers in the Performer relation as in some instances there will be no agent for a performer, and a null value for an agent identifier is not allowed, as it would contravene the rules on entity integrity.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n1597 Andrew Chase Singer London1896 Michael Castle Actor Madrid1976 Sau Mun Lo Dancer Penang1988 William Chong Actor Rome1990 David Collins Musician Paris

Table 3.13

Relation: Agent

Agent-id Agent-name Agent-Loc’n Perf-id 8393 Davidson Paris 19908467 Gordon Sydney 18968476 Lopez Lima 1976

Table 3.14

Performer Agent

Optional for Both Entities

In this scenario, a performer might or might not have an agent. Similarly, an agent might or might not represent a performer. However, if a performer does have an agent, that agent will not represent any other performers. The relationship between the two entities is one-to-one, but optional on both sides. In order to convert this relationship into a relational format, three relations will be needed, one for each entity and one for the relationship.

Figure 3.34

This means that it is possible to have a performer without an agent, and it is also permissible for an agent to have no performers. All performer details will be stored in the performers relation, and all agent data will be held in the agent relation. Where there is a performer with an agent, this will be shown in the relation “Works-with” that represents the relationship between the two entities.

Relation: Performers

Perf-id Perf-name Perf-type Perf-Loc’n0549 Mavis Ringer Dancer Taipei1454 Claude Poisson Actor Leeds2079 Nita Chotalia Singer Chicago3127 Walter Tan Magician Berlin

Table 3.15

The relation Performers holds details of all the performers relevant to the database.

Relation: Agents

Agent-id Agent-name Agent-Loc’n1053 Walter Woo Penang1279 Chris Batten Athens1738 Lisa Chong London1885 Irene Locke Los Angeles

Table 3.16

All agents within the database are stored in the relation Agents.

Performer Agent

Relation: Works-with

Perf-id Agent-id2079 18853127 1053

Table 3.17

Note that the relation Works-with only has entries for those agents and performers who are linked together.

Converting One-to-Many Relationships into Relations


If we consider the situation where a performer has a single agent, but each agent may represent a number of performers, and the relationship is mandatory for both entities, we have an entity-relationship as shown below.

Figure 3.35

If we convert this part of our data model into tables of data, we will have two relations (one for each entity). In order to maintain the relationship that exists between the two entities, we will hold a copy of the primary key of the entity at the “one” end of the relationship as one of the attributes associated with the entity at the “many” end of the relationship. In this example, the attribute agent-id is a foreign key in the relation Performers.

Relation: Performers

Perf-id Perf-name Perf-type Perf-Loc’n Agent-id0468 Gerry Wise Musician Bombay 19710591 Margaret Gupta Actor Paris 13050844 Terry Peace Singer Milan 19711447 Rupert Mendez Dancer Sydney 28572718 Gloria Yeung Actor Toronto 28573762 Hsiao Kang Kim Magician London 2348

Table 3.18

Performer Agent

Relation: Agents

Agent-id Agent-name Agent-Loc’n1305 Alex Sheraton Cairo1971 Cliff Drysdale Rome2348 Amy Newton Tokyo2857 Sarah Ng Lisbon

Table 3.19

Mandatory for one entity, optional for another entity: many end mandatory

In this example, all performers must be represented by agents, and each performer has only one agent. The agents themselves need not be responsible for making bookings for performers, and can be involved in other activities.

Figure 3.36

The mandatory nature of the relationship for the performer is shown by the solid circle; the hollow circle indicates an optional relationship for an agent. This means that there must be a relation to represent performers, and another relation to represent agents. The links between performers and agents are shown by having the agent identifier stored against the appropriate performer in the performer relation. The attribute agent-id is therefore a foreign key in the Performer relation. All performers must have an agent associated with them, but not all agents will be involved in a booking for a performer.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n Agent-id1204 Anna Church Singer Kiev 38951589 Thomas Wong Magician Taipei 48371873 Shirley Sure Dancer Chicago 54901903 Darryl Burns Comedian Berlin 29361982 Emily Spencer Dancer Paris 48372005 Charlotte Chong Musician Beijing 3895

Table 3.20

Relation: Agent

Performer Agent


Table 3.21

Mandatory for one entity, optional for another entity: many end optional

Here, agents may make bookings for performers, and performers may also make bookings for themselves. It is only possible for agents to make bookings for functions that involve performers. An agent may be responsible for making bookings for more than one performer. If a performer is represented by an agent, each performer may have only one agent.

Figure 3.37

The mandatory nature of the relationship for the agent is shown by the solid circle; the hollow circle indicates an optional relationship for a performer. This means that there must be a relation to represent performers, another relation to represent agents, and a third relation to represent those occasions when performers have booked through agents. The links between performers and agents are shown by having the agent identifier stored against the appropriate performer in the third relation.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n1204 Anna Church Singer Kiev1589 Thomas Wong Magician Taipei1873 Shirley Sure Dancer Chicago1903 Darryl Burns Comedian Berlin1982 Emily Spencer Dancer Paris2005 Charlotte Chong Musician Beijing

Table 3.22

Relation: Agent

Agent-id Agent-name Agent-Loc’n

Performer Agent

2936 Alice Truman London3246 Jaimin Khetia Nairobi

Table 3.23

Relation: Agent-Performer

Perf-id Agent-id1204 29361873 29361982 3246

Table 3.24


Here, agents may make bookings for performers, and performers may also make bookings for themselves. It is also possible for agents to make bookings for other functions that do not involve performers. An agent may be responsible for making bookings for a number of performers. If a performer is represented by an agent, each performer may have only one agent. The relationship is optional for both entities.

Figure 3.38

This relationship can be converted into three relations. There will be one relationship to represent the performers, another for the agents, and a third will store details of the relationship between performers and agents (where such a relationship exists).

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n1204 Anna Church Singer Kiev1589 Thomas Wong Magician Taipei1873 Shirley Sure Dancer Chicago1903 Darryl Burns Comedian Berlin1982 Emily Spencer Dancer Paris2005 Charlotte Chong Musician Beijing

Table 3.25

Relation: Agent

Performer Agent


Table 3.26

Relation: Agent-Performer

Perf-id Agent-id1204 38951589 48371982 48372005 3895

Table 3.27

We can see from these relations that a performer may be represented by an agent, and an agent may represent more than one performer. Some performers do not have agents, and some agents do not represent performers.

Converting Many-to-Many Relationships into Relations

We know that if we are dealing with many-to-many relationships that we have to decompose them into two one-to-many relationships. Here we can see that if we leave a many-to-many relationship as it is, it will be represented by three relations just as if we had converted into two one-to-many relationships.


In this example, all performers must be represented by agents, and all agents must represent performers. It is not possible for performers to represent themselves when making bookings, neither is it possible for agents to make bookings that do not involve performers. (Note that this does not imply that each performer has one agent, and each agent represents one performer; that would imply a one-to-one relationship).

Performer Agent

Figure 3.39

Three relations are required to represent a relationship of this kind between two entities, one for each entity and one for the relationship itself.

Three relations are required; one to represent the performers, another to represent the agents, and a third to represent the relationship between the performers and the agents.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n1654 Anita Hall Dancer Chicago1953 Sam Wilton Singer London1982 Fergus Lance Comedian New York1993 Deepti Ghadia Dancer Milan2002 David Tsang Actor Moscow2015 Lauren Greene Actor Paris

Table 3.28

Relation: Agent


Table 3.29

Relation: Agent-for-Performer

Perf-id Agent-id1654 53861654 29361953 54901982 54901993 48372002 53862002 38952015 3246

Table 3.30

The Agent-for-Performer relation shows us that all performers are represented by agents, and that all agents represent performers. Some performers are represented by more than one agent, and some agents represent more than one performer. We now have three relations representing the many-to-many relationship mandatory for both entities.

Mandatory for One Entity, Optional for the Other Entity

The first possibility is that the performer entity is mandatory, but the agent entity is optional. This would mean that performers cannot make bookings for themselves, but depend on a number of agents to make bookings for them. The relationship is mandatory for the performer. An agent, however, is allowed to make bookings for a number of performers, and may also agree bookings for events that do not involve performers, such as exhibitions or conferences. The relationship is optional for the agent.

Figure 3.40

The entity relationship diagram above shows that it is mandatory for performers, but optional for agents to participate. This is translated into three relations below. Note that in the relation Agent-Perf that all performers are represented by an agent (or more than one agent). There are some agents in the Agent relation who do not appear in Agent-Perf because they do not represent performers.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n4240 Nita Shah Dancer Paris4598 Reena Chotalia Dancer Rome4837 Panos Kotzias Actor Milan5930 Yuen Chan Musician Taipei5928 Terry Ford Singer Sydney6050 Keith Buchanan Musician Beijing

Table 3.31

Relation: Agent

Agent-id Agent-name Agent-Loc’n2936 Alice Truman London

Performer Agent

3246 Jaimin Khetia Nairobi3895 Steve Murphy Cairo4837 Angela Demetriou Athens5386 Priti Popat Chicago5490 Charles Patterson Rome

Table 3.32

Relation: Agent-Perf

Perf-id Agent-id4240 29364240 53864598 53864837 29365930 38955930 53865928 38956050 2936

Table 3.33

The second possibility for this kind of relationship is that the performer entity is optional but the agent entity is mandatory. In this case, a performer might have one or more agents, but an agent must represent several performers. Here, a performer could make a booking personally, or could have a booking made by a number of different agents. The agents can only make bookings for performers, and for no other kind of event.

Figure 3.41

The entity relationship diagram above illustrates optional participation for a performer, but mandatory participation by an agent.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n1403 Michael Simpson Actor Bombay1906 Theo Berdekas Singer Athens1974 Anil Shah Actor Los Angeles1935 Kang Hae Lin Dancer London1968 Suk Lo Musician Beijing2027 Ruth Windsor Actor London

Table 3.34

Performer Agent

Relation: Agent


Table 3.35

Relation: Perf-Agent

Perf-if Agent-id1403 29361403 32461974 54901935 48371935 38951968 54901968 5386

Table 3.36

The relation Perf-Agent shows that all agents represent one or more performers. Some performers are represented by more than one agent, whereas other performers are not represented by agents at all.


We could imagine a situation where each performer could be represented by a number of different agents, and could also make bookings without using an agent. In addition, each agent could act for a number of different performers, and the agents could also make bookings that did not involve performers. This would be modeled by a many-to-many relationship between performers and agents that was optional for both entities.

Figure 3.42

Performer Agent

In order to represent this relationship between two entities we would need three relations, one for each entity and one for the relationship itself. The reason that we need three relations rather than just two (one for each entity) is that the relationship is optional. This means that if we were to store the identifier of one entity in the relation of the other, there would be times when we would have a null value for the identifier as no relationship exists for a particular instance of the entity. We cannot have a null value for an identifier, and therefore we show the relationships that do exist explicitly in a third relation.

Relation: Performer

Perf-id Perf-name Perf-type Perf-Loc’n4374 Mary East Singer Tokyo5495 Gordon Tripp Actor Sydney6087 Donna Apinoko Dancer Moscow7343 Frances Heaton Actor Kiev8903 Hilary Wishart Comedian Los Angeles8342 Liang Hong Singer New York9475 Wing Keung Lee Musician Paris

Table 3.37

Relation: Agent

Agent-id Agent-name Agent-Loc’n2936 Alice Truman London3246 Jaimin Khetia Nairobi3617 Andreas Pericleous Nicosia3895 Steve Murphy Cairo4837 Angela Demetriou Athens5386 Priti Popat Chicago5421 Mei Choo Lin Taipei5490 Charles Patterson Rome

Table 3.38

Relation: Agent&Perf

Perf-id Agent-id4374 48376087 29366087 36176087 53867343 29368342 48378342 54909475 5386

Table 3.39

The many-to-many relationship between two entities with optional membership converts into three relations. We can see from the relation Agent&Perf that some agents represent more than one performer, while others do not represent any performers. Similarly, some performers are represented by more than one agent, whereas other performers do not have an agent.

Conversion Rules

The following table provides a summary of the guidelines for converting components of an entity-relationship diagram into relations. We need to be certain that if we store an identifier for one entity in a relation representing another entity that the identifier never has a null value. If we have a null value for an identifier we will never be able to find the other details that should be associated with it.

CardinalityMembership Class

Number of Relations

Notes

1 : 1 Both Mandatory 1 all attributes in a single table1 : 1 One Mandatory

One Optional2 Identifier of optional entity held in

the mandatory entity relation1 : 1 Both Optional 3 one relation for each entity and the

relationship between them1 : N Both Mandatory 2 One relation for each entity and

identifier of "one" end held in "many" end entity relation

1 : N One Mandatory One Optional

2 if the many end is mandatory: one relation for each entity and identifier of the optional entity (the "one" end) held in the mandatory entity relation (the "many" end)

1 : N One MandatoryOne Optional

3 if the many end is optional:one relation for each entity and one for the relationship between them

1 : N Both Optional 3 one relation for each entity and one for the relationship between them

M : N Both Mandatory 3 one relation for each entity and one for the relationship between them

M : N One Mandatory One Optional

3 one relation for each entity and one for the relationship between them

M : N Both Optional 3 one relation for each entity and one for the relationship between them

Table 3.40

Now carry out Activity 3.7 – Transforming E-R into Relations

Learning Outcome: Transform the model into tables suitable for relational database implementation.



ENDSECTION STARTSECTION=content_6 Data Modelling for Data Semantics.htm= SECTION~

3.6 Data Modelling for Data Semantics

E-R modelling, the widely used approach for modelling data is able to capture the most common business problems. However, it is required to add more data semantics to the data models to deal with present business challenges. Hence, many researches are going on and new approaches are emerging to model modern industrial data as well as other complex data behaviour and business rules. Nowadays, it is necessary to accommodate real and very complex business world scenarios in order to conceptualise the data representation. To achieve this the modelling techniques not only require to demonstrate data relationships but also need to include users’ perceptions, data behaviour and business rules. To achieve this, researchers propose an extension of E-R which is called Enhance Entity Relationship Modelling (EER).

One of the most important aims of extended data modelling is to increase the level of semantics in data modelling which can not be achieved by deriving a set of simple tables. The semantics can be added in data model by applying different types of abstractions. These abstractions are:

Generalisation Aggregation

Association

Generalisation: is a process where an entity is constructed from two or more existing entities based on the similarities they have. For example, an entity Employee is constructed from two entities, Part-Time Employee and Full-Time Employee. Therefore it can be said that the generalisation process is a bottom up approach.

Aggregation: is a process where an entity is constructed from two or more existing entities that are the essential components of the entitiy that is being defined. For example, entity Employee consists of Name, Address and DateOfBirth entities. The

Name, Address and DateOfBirth entities are essential components of entity Employee.

Association: is a process where an entity is constructed from the relationships that are defined between two entities. For example, an entity Emplyee-Department is constructed from two entities Employee and Department to show the departments that are assigned to each employee.

Generalisation and Specialisation in EER

The generalisation process is implemented in EER by modelling supertype and subtype. The major challenge in constructing supertype and subtype is to recognise the level of similarities within the entities and to represent them in a hierarchical order. It is also necessary to recognise how the entities share common properties but they have their own distinctive features to be recognised as an individual entity. For example, Employee is an entity where Full-time Employee and Part-time Employee share the common properties that of Employee entity. But Full-time Employee and Part-Time employee have their own distinctive features to be recognised as individual enitity. May be these distinctive features are, the Full-time employee is paid monthly and the Part-time employee is paid hourly and that is the reason that an organisation may wish to keep their records separately. In this example, the entity Employee is a supertype entity whereas the entities Full-time and Part-time Employee are of subtype. Hence, it can be said that a subtype is a collection of entities that share the common properties with the supertype entity but have their own distinctive features and therefore, it can be represented as follows:

Full-time Employee and Part-time Employee are subtypes of Employee

Employee is supertype of Full-time Employee and of Part-time EmployeeThe example above can be represented in EER model using the following notations:

Employee

Part-timeEmployee

Full-timeEmployee

Monthly salary

Address

Name

Employee ID

Hourly Rate salary

Date of Birth

Figure 3.43

The example above depicts that the Part-time and Full-time employee entities are generalised to entity Employee which is a bottom up view. On the other hand, we will have the same EER diagram if we analyse the process in top-down approach. For example, we may think that an organisation has an entity which is Employee and then talking to users later on we discover that there are two types of employees, Part-time and Full-time employees. In this case the entities Part-time employee and Full-time employee are derived from Employee entity and specialised with its own attributes and therefore, it is called specialisation. The generalisation and specialisation approaches of EER modelling are complementary to each other and can be used to detect correctness of the modelling.

The choice of using EER modelling technique depends on the following factors:

some entities share common attributes with others but not with all an entity type that shares common attributes with others, has very specific

relationship and that is unique to that entity type

specific business rules/constraints need to be applied

an entity has an especial relationship with its own instances, in other words when entities demonstrate recursive relationships

if ‘is a’ and ‘has a’ relationships are identified, for example, a Truck is a Vehicle and Truck has a Part.

However, the EER model has its own limitations and the international community is attempting with a great deal of effort to overcome those problems by applying the Object Oriented approach. The next section discusses this issue.



Chapter 13 – Section 12.1-12.1.5

Now carry out Activity 3 .8 – Transforming E-R into EER

Learning Outcome: Identify the need of object oriented approach for semantic data modelling

Object oriented approach for semantic modelling

The EER model, described above, lacks the following measures of quality:

Ability of enforcing business rules: the model is unable to capture complex business rules.

Ability of data reuse: the model is unable to reuse data that are specific for particular entities for any other purposes that have not been aniticipated before.

Stability of the model: model is unable to accommodate any changes that are discovered later without much modification.

Flexibility of the model: the model is not flexible enough to include new extensions without affecting its structure.

Ability to integrate: the model is unable to fit with other existing model without a great deal of integration effort.

Ability to support data query: the model focuses on a number of tables and they may confuse users while generating queries.

Object oriented approach offers a wide range of modelling facilities by constructing data abstraction. These data abstractions are called classes, in other words, classes are collection of entities that share common properties. Unlike entitiy relational modelling where the fundamental is to define relationships with their own attributes, in object oriented data modelling approach the major challenge is to define classes. The classes define the relationships and construct inheritance and constraints requirements to ensure business rules. The class instances are dynamic in nature and thus objects are reused according to the need of business requirements. Further to the facilities that are offered by EER, for example, generalisation and specialisation, the object oriented approach offers the following facilities:

membership relationship: where different objects types are modelled in a higher level of single object type as part-of relationship, called aggregation

constraints implementation: where restrictions are imposed on the objects or on the operations by defining object behaviour

dynamic object creation: objects can be created at run time and therefore, independent to any modification of business rules.

modelling operations: modelling of operations implements object behaviour and can define static-dynamic state of the objects

metaclass support: a metaclass which is a class of classes can provide support for knowledge discovery.

improved communication: the model is explicit to users, designers and programmers

identify communalities: it increases the consistency and reusability

The next section will explore a widely used object oriented methodology for data modelling, called Unviersal Modelling Language (UML), that captures more semantics in data model.

Now carry out Activity 3.9 – Traditional vs. Object oriented approach of data modelling

Learning Outcome: Identify the need of object oriented approach for semantic data modelling


ENDSECTION STARTSECTION=content_7 UML based Data Modelling.htm= SECTION~

3.7 UML Based Data Modelling

Universal modelling language (UML) is the result of combining a number of object oriented modelling techniques, for example, Object Modelling Technique (OMT). Object Oriented Analysis and Design (OOAD) and Object Oriented Software Engineering (OOSE). UML is now a widely accepted model as it provides more semantics, provides more flexibility and supports more data abstractions.

UML uses Object and Class diagrams, the static structure of the model to define classes and their behaviours, classifications, interfaces and visibility requirements. Applying constraints by the means of object constraint language is considered astrength of the UML approach. The UML is also considered as a flexible modelling approach in the sense that it allows generating a new class by taking the elements from an existing class.

Although UML is an acceptable approach for object oriented software development modelling, design and documentation by using Use Case, Interaction and Sequence diagram, we will confine our discussions only to UML based data modelling, hence on the Class diagram.

The notations of class diagrams

Class

The class is shown as a rectangular box. The rectancle has three separate compartments. The name of the class appears at the top and then the list of attributes is presented in the second compartment. The third one holds the operations that are permitted to be executed on the attributes.

An Employee class can be represented in class diagram as:

Figure 3.44

The class Employee in the above example is a schema for its instances. All employee instances of an organisation belong to the class Employee. It is also notable that each employee instance in the class Employee also shares the same operations and relationships with other objects. For example, all employees need to be assigned to a Job and therefore establish a relationship, named AssignJob, with class Job.

Association

An association is a relationship between instances of object classes. Like E-R modelling, the association between instances of object classes can be of unary, binary or ternary or even higher. The association is represented as a line with a role name attached to it. The role has upper bound and lower bound values to indicate the number of objects that participate in a given relationship.

In UML it is possible to represent one-to-one, one-to-many and many-to-many associations. For example,

Employee

EIDNameAddressDateOfBirth.

CalcHour()CalcAmount()AssignJob(Job)

Class Name

Operations

Attributes

One-to-one

Figure: 3.45

In the example above the instances of class Employee is assigned to the instances of class Job. The role of this association is named as AssignJob and supported by values that show the number of possible instances, called multiplicity. The lower bound of the multiplicity shows the mimumum number of objects and upper bound of the multiplicity shows the maximum number of objects. In the figure, it can be said that an employee is assigned to a job or not at all. On the other hand it demonstrates that a job is assigned to an employee or not at all.

One-to-many

Figure: 3.46

The example above shows that an employee must be assigned to one or many jobs, hence, we can say that it is not optional any more as it was in previous example. On the other hand it shows that a Job must be assigned to only one employee. Here note that the * symbol denotes the many upperbound.

Many-to-many

Figure: 3.47

The example above demonstrates that an employee can be assigned for multiple jobs and a job can be allocated to many employees.

Generalisation

Employee Job0..1 AssignJob 0..1

Employee Job1 AssignJob 1..*

Employee Job* AssignJob *

In UML technique a superclass is a class that generalise the classes of common properties. The specialised classes are called subclasses. The generalisation technique in UML is shown as an arrow with hollow head pointing toward the superclass.

An Employee superclass with two subclasses PartTimeEmployee and FullTimeEmployee can be shown in UML as:

Figure 3.48

The class Employee, in the above diagram, is a superclass and generalise FullTimeEmployee and PartTimeEmployee, hence, an abstract class for employee.

Aggregation

In the business world we often come across many objects that consist of many objects, in other words, there are many objects which are part of an object. In UML this semantic is shown as part-of relationship, called aggregation. This semantic is represented as a solid line with a diamond at the end. This diamond can be of type hollow or solid. The hollow diamond represents a weak aggregation when a solid diamond represents a strong aggregation. It means that there are many situations in real world where a component may exist without being the part of its whole object, but in many cases a component must exist as part of its whole object. These business rules can be represented by hollow and solid diamonds respectively.

Employee


AssignJob(Job)

FullTimeEmployee

SalaryGrade

CalcPension()

PartTimeEmployee

HourRate

CalcWeeklyAmount()

employeeType

Suppose the class Employee along with classes Student and Course are the essential components of a class School. This aggregation can be modelled as:

Figure 3.49

In the above example, note that the agreegation contains the multiplicity. In this case School comprises of at least one Course, Employee and Student and to demonstrate a mandatory part-of relationship a solid diamond is used. The main difference between aggregation and generalisation is that generalisation does not contain any multiplicity.



Employee


AssignJob(Job)

FullTimeEmployee

SalaryGrade

CalcPension()

PartTimeEmployee

HourRate

CalcWeeklyAmount()

employeeType

StudentCourse

School

1..* 1..*1..*

1

Chapter 25 – Section 25.7

Now carry out Activity 3.10 – Draw a UML class diagram for the business rules

Learning Outcome: Apply UML to model database objects



Use the online discussion facility and post your comments on the topic for discussion for your group to share in.


ENDSECTION STARTSECTION=content_8 Unit Summary.htm= SECTION~

3.8 Unit Summary

This unit provides a fundamental concept of entity relational modelling. It highlights the major components of entity modelling and has demonstrated the concepts of one-to-one, one-to-many and many-to-many relationships. The concepts are extended further by highlighting the importance of having primary and foreign keys in the business environment in order to establish entity relationship. The unit has examined the concepts of degree of relationships and degree of participation in order to capture business rules and the discussion has been extended further to demonstrate the techniques of converting the entity model into tables with the aid of examples.

The issues of semantic data modelling are also discussed in the unit. It is shown in the unit that Enhanced E-R (EER) modelling has the ability to add more data semantics. The topic is disucussed further by drawing a comparison between EER and object oriented modelling approach. Finally, UML based modelling approach has

been applied to demonstrate how object oriented techniques allow designers to capture more business rules than the EER model.

Unit 5 will re-examine the modelling techniques that are presented in this unit and will demonstrate how the technique can be supplemented by using bottom up approach. Unit 4 will apply SQL and Object based query language on the basis of relationships modelling that are presented here.

Before you move onto the next unit you must complete the end of unit self assessment.

ENDSECTION STARTSECTION=activity_1 Activity 3.1.htm= SECTION~

Activity 3.1 - Identifying Entities and Attributes

Benchmarque International, a furniture company keeps details of items it supplies to homes and offices (tables, chairs, bookshelves, etc).

Now, take a pencil and list the entities and attributes that the furniture company would need to represent in order to keep record of their items and relevant transactions.

ENDSECTION STARTSECTION=activity_2 Feedback on Activity 3.1.htm= SECTION~

Feedback on Activity 3.1 - Identifying Entities and Attributes

The furniture company is likely to want to maintain records of its customers, suppliers, items of furniture for sale, customer orders, purchase orders and the company employees.

You may be able to think of other details that the company would require, for example, financial records for taxation purposes, or details of buildings for maintenance work, but these are not part of the company’s main area of business.

Possible entities and likely attributes include:

Customer: customer number, customer name, address, telephone number, fax number, name of contact, credit limit.

Supplier: supplier number, supplier name, address, telephone number, fax number, name of contact.

Furniture: item code, item name, unit price, dimensions (height, width and depth), weight, material.

Customer order: order number, customer number, furniture ordered, delivery details, delivery date, method of payment.

Purchase order: order number, supplier number, items required, cost, delivery details.

Employee: employee number, employee name, home address, telephone number, marital status, gender, job title, salary, office address, office telephone, manager.

It is not likely that the furniture company would want to identify types of furniture as entities (for example, tables, chairs, desks), although a furniture maker might wish to do so.


Activity 3.2 - Identification of the Keys

What do you think would make a suitable primary key for the entity (or entities) representing the tables, chairs, bookshelves and other items of furniture for Benchmarque International, the furniture company?

Is there any other candidate key than you have suggested?

Now identify an entity for Benchmarque International that has a relationship with the entity that represents the furnitures and by drawing lines show how the foreign key attributes can establish the relationship.


Feedback on Activity 3.2 - Identification of the Keys

A good candidate for primary key for maintaining details of items of furniture would be an item code.

It is possible that the code could be constructed in such a way that it would be possible to tell something about the furniture from the code.

For example, a code beginning with 0 – 3 might represent furniture made from wood, 4 – 6 might be used to represent metal furniture, etc.

It would not be such a good idea to use a description or name of the furniture as a key, as these might not be able to give a unique identification of an item. The price of an item of furniture would not be a good choice either, as the price may change, and there could be several items at the same price. This means that we would not be able to identify an item easily.

One possible entity that would have a relationship with the furniture entity is Customer_Order entity. Customer_Order entity has a relationship with the Furniture entity. This can be shown as

Furniture_Code Furniture_codeof Furniture entity of Customer_order entity


Activity 3.3 - Identifying Relationships I

At a conference each delegate is given a bound copy of the proceedings, containing a copy of all the papers being presented at the conference and biographical details of the speakers.

With the aid of entity relationship diagram show the relationship between a delegate and a copy of the proceedings?


Feedback on Activity 3.3 - Identifying Relationships I

Each delegate has one copy of the proceedings, so the relationship between a delegate and a copy of the proceedings is one-to-one.

Each copy of the proceedings is given to one delegate, and the relationship here is also one-to-one.

The overall relationship between delegates and copies of the proceedings is therefore one-to-one, as shown in the entity-relationship diagram below.

ConferenceDelegate

ConferenceProceedings

ConferenceDelegate

ConferenceProceedings

1:1

ConferenceDelegate

ConferenceProceedings1:1


Activity 3.4 - Identifying Relationships II

Many papers may be presented at a conference.

Each paper will be presented once only by one individual (even if there are multiple authors).

Many delegates may attend the presentation of a paper.

Papers may be grouped into sessions (two sessions in the morning and three in the afternoon).

With the help of entity-relationship diagram show the relationship between:

a speaker and a paper a paper and a session


Feedback on Activity 3.4 - Identifying Relationships II

a speaker and a paper

Each speaker will present only one paper; the relationship is therefore one-to-one. Each paper will be presented by one speaker, also demonstrating a one-to-one relationship.

The overall relationship between conference speakers and conference papers is therefore one-to-one.

a paper and a session

Each paper will form part of one session; this is a one-to-one relationship between a paper and a session. Each session will contain the presentation of several papers; the relationship between a session and a paper is one-to-many.

The overall relationship between conference papers and conference sessions is therefore many-to-one.


Activity 3.5 - Identifying Relationships III

A conference session will be attended by a number of delegates.

Each delegate may choose a number of sessions.

With the aid of entity-relationship diagram show the relationship between conference delegates and sessions?


ConferenceSpeaker

ConferencePaper

ConferencePaper

ConferenceSession

Feedback on Activity 3.5 - Identifying Relationships III

The relationship between delegate and session is many-to-many as each delegate may attend many sessions, and each session may be attended by many delegates.

This many-to-many relationship can be broken down into two one-to-many relationships:


Activity 3.6 - Case Study - Theatrical Database

Consider the design of a database in the context of the theatre. From the description given below, identify the entities and the relationships that exist between them. Use this information to create an entity-relationship diagram, with optional and mandatory membership classes marked. How many entities have you found? Now translate this data model into relations (tables of data). Don't forget the guidelines in order to decide how many relations you will need to represent entities and the relationships between them. You should also think about areas where you don't have enough information, and how you would deal with this kind of problem. You might also find that there is information that you don't need for building the data model.

"Authors are responsible for writing plays that are performed in theatres. Every time a play is performed, the author will be paid a royalty (a sum of money for each performance).

delegate session

delegate sessiondelegate-session

Plays are performed in a number of theatres; each theatre has maximum auditorium size, and many people attend each performance of a play. Many of the theatres have afternoon and evening performances.

Actors are booked to perform roles in the plays; agents make these bookings and take a percentage of the fee paid to the actor as commission. The roles in the plays can be classified as leading or minor roles, speaking or non-speaking, and male or female."


Feedback on Activity 3.6 - Theatrical Database

An example of a model for the Theatre database application is shown below. If your model does not correspond exactly to the model solution provided, this does not necessarily mean your solution is incorrect. If your solution is different, you should examine the ways in which it varies from the example solution, and satisfy yourself that you understand the reasons for any variations.

Case Study: Theatrical Database

Here is an example of an entity-relationship model that you might have developed as part of the case study. You may have noticed some of the following points:

the method of calculation of the fee paid to an actor wasn't specified the price of theatre tickets wasn't mentioned

the location of theatre seats wasn't discussed - this could affect the price

You might have suggested that interviews, phone calls, checking documentation, etc. would all be good ways of finding out more about these details. Alternatively, you could work on a reasonable assumption until you have the information you need.

In the model below it is assumed that the fee is an attribute of the entity actor, and not a separate entity in its own right. We know that there are a number of ways that the fee could be calculated, based on the role, the location of the theatre, the actor, etc. In this case study we will assume that each actor is paid their own individual fee

which doesn't change for different roles or locations. You might have had the fee as a separate entity, depending on the assumptions you made for how the fee is calculated.

There is a many-to-many relationship between performance and theatre. How could you decompose this into two one-to-many relationships?

The relationship between the entity play and the entity theatre is shown as optional at both ends, as there will be plays that are not performed, and the theatre might have productions that are not plays (e.g. ballet performances, or concerts).


Activity 3.7 - Transforming E-R into Relations

For the E-R diagram given below:

a) Identify the number of relations you needb) Draw the relations with appropriate attributes

c) Identify primary key and foreign key to represent relationships

author

royalty

play

roletheatre

performance

actor

agent

Feedback on Activity 3.7 - Transforming E-R into Relations

You will need 3 relations to transform the E-R diagram into tables. These entities are:

Student Entity

Register entity

Module entity

In this activity you may have your own assumptions. However, a guideline for the activity is as follows:

The attributes for the relations may be:

Student relation: Student_ID, Student_Name, Student_Address

Module relation: Module_code, Module_name

Register relation: Register_date, Mode

Student_ID and Module_Code are the primary keys for Student and Module relations respectively. Now to establish a relation between Student and Module relations you need to include Student_ID and Module_Code attributes in the Register relation. These attributes are foreign keys in Register table and will form a composite primary key for the relation.


Activity 3.8 - Transforming E-R into EER

For the E-R diagram given below:

a) Include Person supertypeb) Include Employee subtype

c) Include a relationship:

Student Register Module

A department has many employees


Feedback on Activity 3.8 - Transforming E-R into EER

At the end of this activity you should produce the following EER. If you find any variation identify the reasons of the variations or differences. Keep the record in your learning journal.


Activity 3.9 - Traditional vs. Object Oriented Data Modelling

Student Register Module

Person

StudentEmployee

Register

ModuleDepartment

Given the statements below:

i. For each statement identify which quality measures are reffered to ii. Find two articles on data model quality measures by visiting your local library.

Identify two more quality measures that you have not identified already in (i) and show how they are achieved in the tranditional or object oriented approach

Statements Quality measures

Object oriented approach is flexible and stable enough to accommodate changes according to the need of business requirements without much modification.

Object oriented technique allows object reuse

Traditional EER modelling requires much effort to integrate with the existing structure

Traditional EER modelling supports wide range of data queries but as the number of tables grows it becomes more complex


Feedback on Activity 3.9 - Traditional vs. Object Oriented Data Modelling

The first statement refers to quality measure stability and flexibility

The second statement refers to quality measure data reuse

The third statement refers to quality measure ability to integrate

The fourth statement refers to quality measure query support

For the second part of the activity, you may identify any quality measure that you have come across while reading the articles. However, a few more quality measures may be, ability to balance conflicting business requirements, ability to avoid repeating data while defining the entities etc.


Activity 3.10 - Draw a UML Class Diagram for the Business Rules

Given the business rules as follows, draw a UML class diagram.

Business rules:

a) An order is composed of customer, product and supplierb) There can be many products and suppliers in an order

c) Customer can be of regional or international customer

d) Customers are served by salesmanagers

e) A product has one or many items

f) Suppliers supply at least one item


Feedback on Activity 3.10 - Draw a UML Class Diagram for the Business Rules

Revisit the notations for UML generalisation (superclass/subclass), aggregations, associations and multiplicity.

Order is an aggregation of customer, product and supplier. For each order there should be only one customer and therefore multiplicity for customer is 1. But there can be many products and suppliers for an order and therefore, the multiplicity for products and suppliers are 1..*. The specialisation of Customer is regionalCustomer and internationalCustomer. Customer has association with salesManagers. The multiplicity for Customer and salesManagers are 1..*. Product has association with items and item has association with suppliers. The multiplicity for item and supplier is 1..*.

Now draw the UML using the appropriate notations.

ENDSECTION STARTSECTION=think_1 Review Questions.htm= SECTION~

THINK

Review Questions

Review Question 3.1

Explain the difference between entities and attributes. Give examples of each.

Review Question 3.2

Distinguish between the terms “entity type” and “entity instance”, giving examples.

Review Question 3.3

What is the difference between a candidate key and a primary key?

Review Question 3.4

Explain what is meant by:

One to one relationship One to many relationship

many to many relationship

For each relationship give an example.

Review Question 3.5

Identify the degree of relationship for the followings and explain why:

a) A course is the prerequisite for other coursesb) A student can register for many courses

Review Question 3.6

How are many-to-many relationships implemented in Relational databases?

Review Question 3.7

Compare and contrast traditional entity modelling and object oriented modelling approach.

Review Question 3.8

For the statements below show how one-to-many and many-to-many associations are implemented in UML class diagram.

a) A part is supplied by many vendors

b) A vendor supplies many items and an item is supplied by many vendors

Review Question 3.9

Match the following statements to the appropriate UML data modelling terms.

a) UML modelling has the ability to define a part-of relationship.b) UML has the ability to define the classes that are equivalent to EER

supertype and subtype.

c) A class not only lists the attributes but also it operations.

d) UML has the ability to demonstrate upper bound and lower bound class instances.

Terms: Multiplicity Aggregation, Association, Generalisation, Methods,

ENDSECTION STARTSECTION=think_2 Answers to Review Questions.htm= SECTION~

Answers to Review Questions

Answer to Review Question 3.1

Entities are major categories of data items about which we wish to store information. They usually have a lifecycle, in that they are created, altered and finally removed. Typical examples of entities include products, orders, customers, employees.

There will usually be a number of different aspects of an entity about which we wish to record information. Each of these is represented by an attribute. For example, if we wish to record the total price of orders, this would be recorded by having a TOTAL_PRICE attribute within the ORDER entity. An important aspect of database design is to ensure that each attribute is recorded in its correct entity.


An entity type is a particular class or collection of entities about which we wish to store data. For example, if we say we wish to create the entity type customer, this means that we wish to create an entity type in which we will store the details of all customers.

Each customer for which we wish to store details in the entity type Customer, is known as an instance of entity type customer. An instance therefore means specific example of the entity about which we wish to store information. So in the entity type Customer, we will store the details of many instances of customers (for example Customer #101: Smith, Customer #104: Patel, etc.) each instance corresponding to an actual customer about whom we are storing information.


A candidate key is any data item, or combination of data items, that might be used to identify the instances of an entity type uniquely. For example, if we could guarantee that each of our different customers had a different telephone number, then telephone number would be a candidate key. It could be used as a way of distinguishing one customer from another.

A primary key is the candidate key chosen to uniquely identify each entity instance. Supposing, even if as above we could assume telephone numbers were unique to each customer, we still chose to allocate each customer a unique 4 digit number, and use that customer number as the unique identifier. In this situation customer number would be the primary key, but telephone number would still be a candidate key, providing the assumption about unique telephone numbers still holds. It follows then that any primary key must be a candidate key, and that there may also be other unique identifiers which are not used as the primary key, but which are candidate keys. In a sense they are “candidates” to be chosen as a primary key.


A one to one relationship exists when an instance of one entity type is associated with exactly one instance of another (or possibly the same) entity type. For example, if it is assumed that employees in an organisation are allocated a particular car to use for company business, and that each car is only used by a specific employee, then there is a one to one relationship between employee and car.

One to many relationships arise very frequently. They exist whenever an instance of one entity type is associated with zero, one or more instances of another (or possibly the same) entity type. For example the usual situation where a customer may place a number of orders is a one to many relationship, as any single entity instance of customer may be associated with several instances of entity type order.

A many-to-many relationship exists when instances of an entity type may be associated with many instances of another entity type. For example, an order will often be placed for a number of products, and a particular type of product may appear on many orders. In this situation, a many-to-many relationship exists between instances of entity type order and instances of entity type product.


a) recursive. Entity Course has a relation with its own instancesb) binary. Entity student has a relation with enity course.


Many to many relationships are difficult to implement directly in Relational systems. This is because we don’t know in advance the number of entity instances of one entity type that will be associated with instances of the other entity type. For this reason, when we have a many to many relationship, it is reduced to two one to many relationships, by introducing a 3rd entity type, sometimes called an “intersection” entity type.

For example, if we have the two entity types Order and Product, because an order can be for many products, and an product may appear on a number of orders, there is a many to many relationship between the entity types order and product. This is resolved by introducing the intersection entity order_line, which is used to resolve the many-to-many relationship between order and product. The many-to-many relationship is replaced by the one-to-many relationship between order and order_line, and the one-to-many relationship between product and order_line. That is, the order_line entity type allows us to represent the fact that a number of products are associated with an order, each product being appearing in a different order_line, and that each product might appear in a different order, again each case of this appearing in a different order_line.


Traditional entity modelling:

focus is on relationship modelling support generalisation and specialisation

support aggregation

focus on data modelling

capture very limited business rules

Object oriented modelling:

focus is on class modelling object operations and behaviour are modelled

support supertype, subtype and aggregation

constraints are implemented in class descriptions

more business rules can be captured by defining membership class, modelling operations, defining object states and object interactions


a)

b)


a) Aggregationb) Generalisation

c) Method

d) Multiplicity

ENDSECTION STARTSECTION=think_3 Group Discussion.htm= SECTION~

Group Discussion

Part Vendor1 suppliedBy 1..*

Part Vendor1..* suppliedBy 1..*

Entity-relationship and Object oriented class diagrams can be drawn using elementary drawing tools, such as those found in the MS-Word package, but more usually, a package specifically designed for developing these diagrams is used. The use of such tools can greatly speed up the development of larger Entity-relationship and Object oriented data models, and have a major impact in reducing the number of errors in the development of a model. You are encouraged to discuss with one another, the features you would like to see in an Entity-relationship and Class diagramming tool, for example, Select Enterprise or Eclipse.

Think about the different elements of ER and Class diagrams, and also the sequence of steps you go through when creating an ER and Class digram.

If you have had previous experience of using such a tool, your comments on the usability of the tool and extent to which it supports different elements and stages of ER and Class diagrams will be useful.


ENDSECTION STARTSECTION=think_4 Contribution to Discussion.htm= SECTION~

Contribution to Discussion

Features you might identify help the following aspects of model development:

Entity/class and attribute/operation identification Relationship/Association modelling

Cardinalities and multiplicity determination

Model validation

Automatic table/class generation

Aggregation and Generalisation generation

For each of the phases of model development listed above, you should consider what facilities an Entity-relationship and Class diagramming tool could provide to assist the process.

ENDSECTION STARTSECTION=think_5.htm= SECTION~

Learning Journal

In your learning Journal write up your experience of your learning on this unit. Say what you thought was good or bad, what you had difficulty understanding, and how you resolved your problems.

Log errors and difficulties to assist in future programming learning. Make notes of key points or issues to follow up from the activities.

Log issues raised during your group discussion.

ENDSECTION STARTSECTION=think_6.htm= SECTION~

End of Unit Self Assessment

Before proceeding to the next unit you should work through the End of Unit Self-Assessment on Web CT. When you have completed the questions you will be able to obtain sample answers for future reference.

Your performance with these questions will not affect your grade for the module, but may be monitored so that your tutor can be alerted if you are having difficulty.

Please contact your tutor if you feel you have not done as well as you expected.

Don’t forget to complete the End of Unit Self-Assessment

ENDSECTION STARTSECTION=extra_1.htm= SECTION~

EXTRA

Extra Content and Activities

Further Information

Following on from the discussion of computer-based support for drawing Entity-relationship models, you should be aware that such tools provide just one aspect of the computer-based support for application development. In general, the term used for computer-based tools to support application development is CASE (Computer Aided Software Engineering). A very large range of CASE tools have been developed to assist with all aspects of applications development, including Entity-relationship modelling. A valuable additional piece of work which supplements the material covered in this unit, is to conduct some research into CASE tools in general, and Entity-relationship modelling tools in particular. It is recommended therefore that you carry out research on the WWW to extend your knowledge of the software support available for Application development. This can be done in two ways:

1. Use search engines such as 37.com and yahoo.com, in order to find links to sites containing information on CASE. Some suggested search terms are as follows:

a) CASE and toolsb) Data and modelling

c) Process and modelling

d) Entity and relationship and diagramming

e) Database and design and tools

2. Go to specific sites, such as www.oracle.com, www.sybase.com etc. to find out about the extent to which major database vendors provide automatic support for application development. Oracle’s set of products in this area include Designer 2000 for example. In general major vendors have developed tools from very high level concept mapping tools which enable an overall view of an organisation to be developed, through to very low level tools which take into account some aspects of the physical design of the database, or even lightweight tools which enable data and/or process modelling on a relatively modest hardware/software platform.

http://www.sybase.com/

http://www.oracle.com/

Elmasri, R. and Navathe, S.B., 2000, Fundamentals of Database Systems, Addison-Wesley

Chapter 7: The Relational Data Model, Relational Constraints and the Relational Algebra

Atzeni, P., Cert, S. Paraboschi, S. and Torlone, R., 1999, Database Systems, McGraw Hill

Chapter 2: The Relational Model

Rob, P. and Coronel. C. (2004) Thomson Publication.

Chapter 11: Object Oriented Database

Reference

Codd, E.F., “A Relational Model for Large Shared Data Banks”, Communications of the ACM, Vol. 13, No. 6, pp.377-387, 1970.

2. Chapter 7 of the 7th edition of the Introduction to Database Systems, by C. J. Date,

3. Straube, D. D., and Ozsu, M. T. (1990); Queries and Query processing in object oriented database systems. ACM transactions on information systems 8(4).

4. Fowler, M., 2000. UML Distilled: A brief guide to the standard object modelling language, 2d ed. Rading, MA: Addison Wesley Longman.

ENDSECTION ENDCHAPTER

Data Management for Decision Support BIS4435/21 Wee… · Web viewGo to specific sites, such as ,...

Documents

Transcript of Data Management for Decision Support BIS4435/21 Wee… · Web viewGo to specific sites, such as ,...