3-relmodel

1

Topic 3

The Relational Data Model I

Learning Objectives To know the structural components of the relational data model. To be able to map ER models into relational models

Contents 3.1 Relational Model vs Relational DBMS ...................................................................................................... 3

3.2 The Three Parts of the Relational Model ................................................................................................. 3

3.3 The Structural Part of the Relational Model ............................................................................................ 4

3.3.1 Describing the Model Structure ........................................................................................................ 4

3.3.2 Properties of Relations ...................................................................................................................... 5

3.3.3 Domains ............................................................................................................................................. 6

3.3.4 Notations to Describe the Relational Schema ................................................................................... 7

3.3.5 Representing an ER Model as a Relational Model ............................................................................ 8

3.3.5.1 Representing Entity Types as Relations ...................................................................................... 9

3.3.5.2 Representing 1:1 Relationships .................................................................................................. 9

3.3.5.3 Representing 1:N Relationships ............................................................................................... 11

3.3.5.4 Representing M:N Relationships .............................................................................................. 12

3.4 Relational Modelling Tutorial ................................................................................................................. 13

3.4.1 Relational Model of Geographical Features ...................................................................................... 14

3.4.3 Relational Model of a University ........................................................................................................ 15

Q2 Convert the University ER model from Section 2.4.3 into a relational model. .......................... 15

3.4.3 Relational Model of Sir Edward Kelly Case Study .............................................................................. 15

3.5 Answers to questions and activities .......................................................................................................... 16

3.5.1 Relational Model of Geographical Features ...................................................................................... 16

3.5.2 Relational Model of a University ........................................................................................................ 17

2

3.5.3 Relational Model of Sir Edward Kelly Case Study .............................................................................. 18

This topic provides an introduction to relational data models. The relational data model was first introduced by Ted Codd of IBM Research in 1970. This topic provides an understanding of what a relational model is, as well as how we might approach model development. The relevant sections of the recommended course texts are as follows:

El Masri and Navathe, Chapter 5

you may also like to consult C J Date, Chapters 11 and 12

If you are unable to locate the above text books there are other sources of information that may prove useful. Remember to check out the details of the recommended reading that were detailed in Topic 1 of this module.

There are three main subtopics that cover the core material in this topic:

Relational Model vs Relational DBMS The Three Parts of the Relational Model The Structural Part of the Relational Model

There is a substantial tutorial to be completed at the end of this topic, which provides an opportunity for you to develop and test the skills and knowledge acquired from this topic. The tutorial includes two separate activities, which follow on from the activities in the Topic 2 tutorial.

Relational Model of Geographical Features: provides practise in developing a relational model of geographical features, considering rivers and the cities that they flow through.

Relational Model of Sir Edward Kelly Case Study: provides you with an opportunity to examine the Sir Edward Kelly case study introduced in Topic 1.

3

3.1 Relational Model vs Relational DBMS

Before proceeding to look at relational data modelling in detail, let us consider a comparison between the relational model and relational Database Management System (DBMS). The relational model is concerned with what is required, which separates it from concerns of how the model will be implemented. The how is the concern of the relational DBMS. The relational model focuses on representing data through relationships held between those data items. This approach has its theoretical basis in set theory and predicate logic - data is therefore represented in the form of tuples. The data in the relational model is queried/manipulated using relational algebra or relational calculus. The Relational DBMS is concerned with how the relational model will be implemented. The data from the relational data model is represented in the form of tables and rows. The data is queried using particular query languages, most commonly this is a language known as SQL (Sequential Query Language).

3.2 The Three Parts of the Relational Model

The relational model can be considered as having three parts and these are covered in sequence below: 1. Structural: defines the core of the data and the relationships involved. The model structure is described in terms of relations, tuples, attributes and domains. 2. Manipulative: defines how the data in the model will be accessed and manipulated. This concerns how relations in the model will be manipulated to produce other relations, which in turn provide the answer to some question posed by a user of the data. The manipulation is achieved though relational algebra or relational calculus.

3. Constraints: defines limits on the model. The constraints determine valid ranges and values of data to be included in the model.

4

3.3 The Structural Part of the Relational Model

Learning Objective

To know the structural components of the relational data model.

This subtopic describes the structural part of the relational model: it defines the core of the data and the relationships involved. The model structure is described in terms of relations, tuples, attributes and domains.

The following are considered here:

Describing the Model Structure Properties of Relations Domains Notation to Describe the Relational Schema Representing an ER Model as a Relational Model

3.3.1 Describing the Model Structure

This section describes the structural part of the relational model. This is achieved through a number of constructs which are illustrated in Figure 3.1 and described below.

Relation: A relation comprises a set of tuples. Figure 3.1 is a tabular representation of the Student relation containing five tuples.

Tuple: A tuple is a sequence of attributes i.e. a row in the relation table. There are five tuples shown in the Student relation in Figure 3.1 - the one highlighted concerns Student identified by the MatricNo 's07'.

Attribute: An attribute is a named column in the relation table. The Student relation in Figure 3.1 contains four attributes - the MatricNo attribute is highlighted, other attributes are Name, Registered and Counsellor.

Domain: The domain construct is important as it identifies the type of an attribute. More formally the domain is a named set of values which have a common meaning - the domain of an attribute defines the set of values from which an attribute can draw.

5

For example, Figure 3.1 highlights the domain Years for the attribute Registered. This determines that the Registered attribute will draw a value from the valid set of integers which represent a year. It is likely that additional constraints would be enforced to restrict the domain of the Registered attribute further such that it may, for example, fall between an acceptable range of years, e.g. 1990 .. 2015.

Student

Attribute Domain Tuple

MatricNo: MatricNos

Name: PersonNames

Registered: Years

Counsellor: StaffNos

S01 Bloggs 1993 4523

S02 Smith 1998 3412

S05 Jones NULL 4523

S07 Stewart 1996 4538

S09 MacDonald 1995 4523

Figure 3.1: Relation Constructs

Figure 3.1 shows a particular attribute value of NULL. This is a special value that may be assigned to an attribute, however it is desirable to avoid assigning the NULL values as its meaning can be ambiguous. For example, with regard to the Student relation, the fact that the Registered attribute is shown to have a NULL value could mean that we do not know the year in question, or it could mean that the student has not in fact registered yet.

3.3.2 Properties of Relations

Relations have three important properties. Each relation has a name, a cardinality and a degree. These properties help us to further define and describe relations. The three properties introduced above are defined as follows:

6

1. Name: The first property is that a relation has a name which identifies it, for example the Student relation illustrated in Figure 3.1.

2. Cardinality: The second property of a relation it its cardinality. This refers to the number of tuples in the relation. If we again take Figure 3.1 as our example, then the cardinality of the Student relation is 5.

3. Degree: The third and final property of a relation is its degree. The degree of a relation refers to the number of attributes in each tuple. Again, with reference to Figure 3.1, the degree of the Student relation is 4, the attributes being MatricNo, Name, Registered and Counsellor.

3.3.3 Domains

The domain of an attribute defines the set of values which can apply to that attribute. The domain can be considered similar to the simple data types in programming languages, such as int or char types in programming languages such as C++.

Domains are always atomic. This means that they have no structure. Figure 3.2 illustrates the example domains relevant to the Student relation in Figure 3.1.

MatricNos = S01..S99 PersonNames = string StaffNos = 1000..9999 Years = 1960..2040

Figure 3.2: Domains for the Student Relation

The most important consequence of two attributes being defined on the same domain is that their attribute values are comparable. It is important to make the distinction that two attributes are not comparable if they have been declared in different domains, even if the underlying data type is the same. For example, the underlying data type of both the Year and StaffNos domains is the basic data type int. However, this does not mean that the Registered and Counsellor attributes are comparable. To attempt to compare such attributes would not be meaningful.

7

3.3.4 Notations to Describe the Relational Schema

The previous subtopics demonstrated how the relational schema can be graphically illustrated as a table. The table representation can be helpful, as it allows a number of tuples to be illustrated. However, there are times when a more concise representation is helpful. There are two alternative notations that we will introduce here. The first is more explicit, detailing the domains of the attributes. This is illustrated in Figure 3.3.

Relation Student

MatricNo: MatricNos

Name: PersonNames

Registered: Years


primary key MatricNo

Figure 3.3: Relational Schema Notation (1) An alternative, more concise representation is illustrated in Figure 3.4.

Student(MatricNo, Name, Registered, Counsellor)

Figure 3.4: Relational Schema Notation (2)

The notation identifies the key to the relation. The key is the attribute(s) that uniquely identifies onetuple in a relation from another. In Figure 3.3 the key is explicitly identified by the keywords primary key. In the alternative notation Figure 3.4), the key is identified by underlining the attribute(s). Throughout the remainder of this topic the more detailed notation style shown in Figure 3.3 will be used. There are many attributes that can be considered as candidate keys. One of the candidate keys is chosen as the primary key - this is the key that performs the unique identification of a given tuple. In the Student relation it is reasonable that the student's MatricNo serves this purpose. A relation will also often include one or more foreign keys. A foreign key is an attribute that represents a relationship with another relation: it is the primary key of one relation which is included as an attribute in another relation. For example, the Counsellor attribute is a foreign key in the Student relation. It is reasonable to consider that there is also a Staff relation that will be introduced into our relational model. The Staff relation will have the same attribute which will be the primary key of the Staff relation. That attribute will have the domain StaffNos.

8

3.3.5 Representing an ER Model as a Relational Model

This looks at how the entity relationship (ER) model can be represented as a lower level relational model. This process can be summarised as the following translations:

1. Entity types map to Relations : The entities identified in the ER model become

relations in the relational model.

2. Attributes map to Attributes: The attributes of the entity map directly to attributes in the relation.

3. Identifiers map to Keys: The identifiers of the entity become keys of the relation in

the relational model.

4. 1:1 and 1:N relationships map to Foreign keys:The 1:1 and 1:N degrees of relationships in the entity model become the foreign keys in the relational model.

5. M:N relationships map to Relations: The M:N degree relationships in the entity

model map to relations in the relational model.

This considers the mapping process with regard to the University data model. At this point you may like to re-familiarise yourself with the ER model of the University that was developed in the Constructing an ER Model from Data Requirements Description subtopic of Topic 2. The following provide a breakdown on the mapping process of the University ER model into a relational model:

Representing Entity Types as Relations Representing 1:1 Relationships Representing 1:N Relationships Representing M:N Relationships

9

3.3.5.1 Representing Entity Types as Relations

Each entity type in the ER model becomes a candidate entity relation in the relational model. The attributes of the entity type become attributes of the entity relation. We consider here what this means with regard to the Staff and Student entity types from the University data model, depicted in Figures 3.5 and 3.6.

Figure 3.5: Staff and Student Entity Type Diagrams

Student(MatricNo, Name, Registered) Staff(StaffNo, Name)

Figure 3.6: Staff and Student Entity Types

These entity types from the ER model can be rewritten in the form of entity relations as shown in Figure 3.7. The attribute names are maintained from the entity descriptions given in Figure 3.6. The additional domain information provides additional information regarding the attribute types.

Relation Student

MatricNo: MatricNos

Name: PersonNames

Registered: Years


Relation Staff

StaffNo: StaffNos

Name: PersonNames

primary key StaffNo

Figure 3.7: Representing Staff and Student Entity Types as Relations At this initial step we are concerned with simple representation of the entity type and its attributes. The subsequent steps examine the implications of mapping identifiers.

3.3.5.2 Representing 1:1 Relationships

Consider the ER model section shown in Figure 3.8. This shows two entity types, Staff and Department. The relationship between them is described as Heads. This captures the fact that a member of staff is the head of a department.

10

Figure 3.8: Example 1:1 Relationship ER Model

The corresponding relational schema for these entity types is shown in Figure 3.9.

Relation Staff

StaffNo: StaffNos

Name: PersonNames

primary key StaffNo

Relation Department

DeptNo: DeptNos

DeptName: DeptNames

primary key DeptNo

Figure 3.9: Relational Schema for Staff and Department Entities The tabular form of the Staff and Department relations (Figure 3.10 and Figure 11) show how we represent the 1:1 Heads relationship by including the primary key of the Staff member who is the head, into the Department. This key is termed a foreign key.

StaffNo Name

4523 Evans

3412 Wyatt

4538 Lenzie

Figure 3.10: Staff Relation

DeptNo DeptName HeadOfDept

D01 Computing 3412

D02 Chemistry 4523

Figure 3.11: Department Relation

The modifications to the relational schema are shown in Figure 3.12. Crucially, we include the staff member in the department relation, as every department has a head. In contrast not every member of staff is the head of a department, so including the department key in

staff would result in many Null values.

11

Relation Staff

StaffNo: StaffNos

Name: PersonNames

primary key StaffNo

Relation Department

DeptNo: DeptNos

DeptName: DeptNames

HeadOfDepartment: StaffNo

primary key DeptNo foreign key HeadOfDepartment references Staff

Figure 3.12: Example 1:1 Relationship encoded in a Relational Schema

3.3.5.3 Representing 1:N Relationships

A one-to-many (1:N) relationship is represented by including the primary key of the ‘many’ relation as a foreign key in the ‘one’ relation. Consider the counsels relationship between staff and students. Each student has just one counsellor, but a staff member may counsel many students. We include the primary key from Staff (i.e. StaffNo) as a foreign key in the Student relation, as illustrated in Figure 3.13

Relation Student

MatricNo: MatricNos

Name: PersonNames

Registered: Years



foreign key Counsellor references Staff

Relation Staff

StaffNo: StaffNos

Name: PersonNames

primary key StaffNo

Figure 3.13: Example 1:N Relationship encoded in a Relational Schema

12

Corresponding example relation instances are shown in Figure 3.14 and Figure 3.15 in tabular form, showing that Lenzie counsels Smith and Jones, Wyatt counsels Jackson and Evans counsels no-one.

StaffNo Name

4523 Evans

3412 Wyatt

4538 Lenzie

Figure 3.14: Staff Relation

MatricNo Name Registered Counsellor

s04 Smith 1986 4538

s08 Jones 1990 4538

s11 Jackson 1990 3412

Figure 3.15: Student Relation

3.3.5.4 Representing M:N Relationships

Consider the ER model section shown in Figure 3.17. This shows two entity types, Course and Location. The relationship between them is described as taught in. This captures that fact that a course may be taught in one or more rooms, and a room may be used to teach one or more courses.

Figure 3.17: ER Diagram of Course and Location Entities

Corresponding example relations for Course and Location are shown in Figure 3.18 and Figure 3.19.

CourseCode Title Credit

C01 Maths 5

C02 Computing 5

Figure 3.18: Course Relation

RoomNo Capacity

r01 50

r02 40

r03 110

Figure 3.19: Location Relation

13

The relationship taught at is represented as a third relation in Figure 3.20.

CourseCode RoomNo

C01 r02

C02 r01

Figure 3.20: taught at Relation The relational schema for Course and Location are shown in Figure 3.21, which clarifies the primary and foreign keys that describe the relation. This shows how the M:N relationship is captured through a separate relation, taught at. This additional relation has two attributes - these are both foreign keys as well as the primary key to each tuple in the relation.

relation Course

CourseCode: CourseCodes

Title: CourseTitles

Credit: Integer

primary key CourseCode

relation Location

RoomNo: RoomNumbers

Capacity: Integer

primary key RoomNo

relation TaughtAt


RoomNo: RoomNos

Primary key (CourseCode, RoomNo)

Foreign key CourseCode references Course

Foreign key RoomNo references Room

Figure 3.21: Example M:N Relationship encoded in a Relational Schema

3.4 Relational Modelling Tutorial

Learning Objective To develop expertise in creating relational models from ER models. This tutorial includes two separate activities, which follow on from the activities in the Topic 2 tutorial.

Relational Model of Geographical Features: provides practise in developing a relational model of geographical features, considering rivers and the cities they flow through.

Relational Model of Sir Edward Kelly Case Study: provides an opportunity develop a relational model of the Sir Edward Kelly case study for use later in the course.

14

3.4.1 Relational Model of Geographical Features

Read through the question below in detail. It is important that you have completed the ER Modelling tutorial in Topic 2 prior to attempting this tutorial.

Consider the domain information provided in Figure 3.22.

Domains

Names = string

Areas = integer

Populations = integer

Lengths = integer

Figure 3.22: Domain Information

Consider the ER model and entity information presented in Figure 3.23 and Figure 3.24.

Figure 3.23: Mini Geographical ER Diagram

Country(CountryName, Area, Population)

City(CountryName, CityName, Population)

River(RiverName, Length)

Figure 3.24: Mini Geographical Entity Types

Q1: Use the above information to produce a relational model.

15

3.4.3 Relational Model of a University

Q2 Convert the University ER model from Section 2.4.3 into a relational model. Make a slight

extension of the model studied earlier to associate each student and each staff member with a

region number between 1 and 9.

3.4.3 Relational Model of Sir Edward Kelly Case Study

Read through the question in detail. It is important that you have completed the ER Modelling tutorial in Topic 2 prior to attempting this tutorial.

Consider the domains shown in Figure 3.25. Domains

ContractNos = string

Despriptions = string

Comments = string

Money = integer

ShippingSheetNos = integer

VesselNames = string

Volumes = float

PlaceName = string

CompanyName = string

BillOfLadingNos = integer

InsuranceState = {OK, Pending, None}

Sizes = string

Qualities = {Whitewood, Darkwood, Softwood, HardWood}

OrderNos = string

TimberConditions = string

Figure 3.25: Sir Edward Kelly Domains

Q3: This question assumes that you have completed the activity 'An ER Model of Timber Handling in Sir Edward Kelly Case Study' of the Database Fundamentals topic of this module. Using the ER model produced in that tutorial, and the above domain information, convert the ER model into a relational model. Your model should include domains, and both primary and foreign keys. Do not include any constraints for now. You may add new domains if you require.

16

3.5 Answers to questions and activities

3.5.1 Relational Model of Geographical Features

Q1: The key aspects of the modelling process are to

select a suitable primary key, and to

use foreign keys to represent relationships.

The full relational model would be written as follows:

model Geographical domains Names = string Areas = integer Populations = integer Lengths = integer relation Country CountryName: Names Area: Areas Population: Populations Capital: Names primary key CountryName foreign key (CountryName,Capital) references City relation City CountryName: Names CityName: Names Population: Populations primary key (CountryName,CityName) foreign key CountryName references Country relation River RiverName: Names Length: Lengths primary key RiverName relation FlowsIn RiverName: Names CountryName: Names primary key (RiverName,CountryName) foreign key CountryName references Country foreign key RiverName references River

17

3.5.2 Relational Model of a University

Q2:

model University

domains

MatricNos = s01..s99

PersonNames = string

StaffNos = 1000..9999

Years = 1960..2040

CourseCodes = c1 .. c9

CreditValues = 1 .. 100

AssignmentNos = 1 .. 5

Grades = 1 .. 100

Regions 1 .. 9

relation Student

MatricNo: MatricNos

Name: PersonNames

Registered: Years


Region: Regions


foreign key Counsellor references Staff

relation Staff

StaffNo: StaffNos

Name: PersonNames

Region: Regions

primary key StaffNo

relation Course


Title: CourseTitles

Credit: CreditValues

primary key CourseCode

relation Enrolment

MatricNo: MatricNos


Tutor: StaffNos

primary key (MatricNo, CourseCode)

foreign key MatricNo references Student

foreign key CourseCode references Course

foreign key Tutor references Staff

relation Assignment

MatricNo: MatricNos


AssignmentNo: AssignmentNos

Grade: Grades

primary key (MatricNo, CourseCode, AssignmentNo)

foreign key (MatricNo, CourseCode) references Enrolment

18

3.5.3 Relational Model of Sir Edward Kelly Case Study

Q3: model EdwardKelly domains ContractNos = string Descriptions = string Comments = string Money = integer ShippingSheetNos = integer VesselNames = string Volumes = float PlaceName = string CompanyName = string BillOfLadingNos = integer InsuranceState = {OK,None,Pending} Sizes = string Qualities = string WoodType = {Whitewood, Darkwood, Softwood, Hardwood} OrderNos = string TimberConditions = string relation PurchaseContract ContractNo: ContractNos ContractDate: Date ShippingDate: Date Description: Descriptions Lengths: string UnitPrice: Money CurrencyRestrictions: string primary key ContractNo relation ContractItem ContractNo: ContractNos BillOfLadingNo: BillOfLadingNos ShipmentDate: Date Shipment: string Comments: string primary key (ContractNo,BillOfLadingNo) foreign key ContractNo references PurchaseContract relation ShippingSheet ShippingSheetNo: ShippingSheetNos ContractNo: ContractNos Vessel: VesselNames ShippingAgent: CompanyName CustomsAgent: CompanyName TotalVolume: Volumes DateShipped: Date Dock: PlaceName ExQuayPeriod: integer PortOfShipment: PlaceName FreightCharge: Money Insurance: InsuranceState ExchangeRate: string DateArrived: Date Berth: PlaceName ExQuayRate: Money primary key (ShippingSheetNo) foreign key ContractNo references PurchaseContract relation ShippingItem ShippingSheetNo: ShippingSheetNos BillOfLadingNo: BillOfLadingNos Size: Sizes Quality: Qualities Type: WoodType NumPacks: integer

19

NumPieces: integer Volume: Volumes Destination: PlaceName Haulier: CompanyName OrderNo: OrderNos DateInStock/Invoiced: Date primary key (ShippingSheetNo,BillOfLadingNo) foreign key ShippingSheetNo references ShippingSheet relation BillOfLading BillOfLadingNo: BillOfLadingNos ShippingSheetNo: ShippingSheetNos ContractNo: ContractNos LoadingDate: Date Description: Descriptions Size: Sizes Quality: Qualities L51, L47, L45, L42, L39, L36, L33, L30, L27, L24, L21, L18: integer NumPieces: integer TotalLength: integer Volume: Volumes primary key BillOfLadingNo foreign key ShippingSheetNo references ShippingSheet relation OutTurnReport BillOfLadingNo: BillOfLadingNos TimberCondition: TimberConditions NumPacks: integer NumPieces: integer primary key BillOfLadingNo foreign key BillOfLadingNo references BillOfLading relation StockSheet BillOfLadingNo: BillOfLadingNos ContractNo: ContractNos ShippingSheetNo: ShippingSheetNos Stowage: PlaceName Cost: Money Condition: TimberConditions Size: Sizes Quality: Qualities Type: WoodType Vessel: VesselNames primary key BillOfLadingNo foreign key BillOfLadingNo references BillOfLading relation StockItem BillOfLadingNo: BillOfLadingNos ReferenceNo: ReferenceNos SDate: Date L51, L47, L45, L42, L39, L36, L33, L30, L27, L24, L21, L18: integer NumPieces: integer NumPacks: integer Volume: Volumes Balance: Money primary key (BillOfLadingNo,ReferenceNo)

foreign key BillOfLadingNo references StockSheet

3-relmodel

Documents