Академический Документы
Профессиональный Документы
Культура Документы
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 1
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.
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.
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.
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.
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.
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.
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.
10
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
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
11
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.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
12
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
13
14
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.
15
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
16
17
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 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 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
19