Sie sind auf Seite 1von 19

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

Conten ts 3. Relational Model vs Relational DBMS


1 3. 2 3. 3

......................................................................................................3 The Three Parts of the Relational Model .................................................................................................3 The Structural Part of the Relational Model ............................................................................................4 3.3. Describing the Model Structure 1 ........................................................................................................4 3.3. Properties of Relations 2 ......................................................................................................................5 3.3. Domains............................................................................................................... 3 ..............................6 3.3. Notations to Describe the Relational 4 Schema...................................................................................7 3.3. Representing an ER Model as a Relational Model 5 ............................................................................8 3.3.5. Representing Entity Types as 1 Relations......................................................................................9 3.3.5. Representing 1:1 Relationships 2 ..................................................................................................9 3.3.5. Representing 1:N Relationships 3 ...............................................................................................11 3.3.5. Representing M:N Relationships 4 ..............................................................................................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 1

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

The Three Parts of the Relational Model

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. Describing the Model 1 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 tabular representation of the Student relation containing five tuples. is a

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.

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 MatricNo: MatricNos S01 S02 S05 S07 S09 Name: PersonNames Bloggs Smith Jones Stewart MacDonald Domain Registered: Years 1993 1998 NULL 1996 1995 Tuple Counsellor: StaffNos 4523 3412 4523 4538 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. Properties of 2 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:

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

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.

3.3. Notations to Describe the 4 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 Counsellor: StaffNos 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.

3.3. Representing an ER Model as a 5 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

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 primary key MatricNo 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 Relationships

1:1

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

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 4523 3412 4538 Name Evans Wyatt Lenzie Figure 3.10: Staff Relation DeptName HeadOfDept Computing 3412 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.

DeptNo D01 D02

1 0

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 Counsellor: StaffNos primary key MatricNo 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

1 1

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 4523 3412 4538 Name Evans Wyatt Lenzie Figure 3.14: Staff Relation MatricNo s04 s08 s11 Name Smith Jones Jackson Registered 1986 1990 1990 Counsellor 4538 4538 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 C01 C02 Title Maths Computing Credit 5 5

Figure 3.18: Course Relation RoomNo Capacity r01 50 r02 40 r03 110 Figure 3.19: Location Relation

1 2

The relationship taught at is represented as a third relation in Figure 3.20. CourseCode C01 C02 RoomNo r02 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 CourseCode: CourseCodes 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.

1 3

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.

1 4

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


Consider the domains shown in Figure 3.25.

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.

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.

1 5

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

City

1 6

3.5.2 Relational Model of a University


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 Counsellor: StaffNos Region: Regions primary key MatricNo foreign key Counsellor references Staff relation Staff StaffNo: StaffNos Name: PersonNames Region: Regions primary key StaffNo relation Course CourseCode: CourseCodes Title: CourseTitles Credit: CreditValues primary key CourseCode relation Enrolment MatricNo: MatricNos CourseCode: CourseCodes 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 CourseCode: CourseCodes AssignmentNo: AssignmentNos Grade: Grades primary key (MatricNo, CourseCode, AssignmentNo) foreign key (MatricNo, CourseCode) references Enrolment

1 7

3.5.3 Relational Model of Sir Edward Kelly Case Study


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, 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

Hardwood}

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 18

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 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 BillOfLading

Balance: Money primary key (BillOfLadingNo,ReferenceNo) foreign key BillOfLadingNo references StockSheet

1 9

Das könnte Ihnen auch gefallen