M358 - Structure of Domains
fellstrider.com - the logo!
Home| OU Study Rooms | M358 Index | Block 1 - Information Systems | Block 2 - Relational Theory
Structure of Domains

A domain is a named set of values, with a common meaning, from which one or more attributes draw their actual values.

Attributes in the same domain have values that are comparable. Attributes declared in different domains do not have comparable values even if the domains are of the same data type.

User defined data types must be named and the base data type given:

domains
   IdentifiersOfStudents = s01 .. s99	
   PersonNames = string
   Years = Yearnumber	
   StaffNumbers = 1000 .. 9999
   Regions = 1 ..9	
   CodesOfCourses = c1 .. c9
   TitlesOfCourses = string	
   CreditValues = (30, 60)
   AssignmentNumbers = 1 .. 5	
   Grades = 0 .. 100

This is not notation specific to any DBMS.

IdentifiersOfStudents = s01 .. s99 - indicates that the range takes only values of s01 to s99. Double dots indicate that all values between these are included.

CreditValues = (30, 60) - indicates that only the specified values of 30 and 60 are included.

TitlesOfCourses = string - indicates that any sequence of characters can be given.

Developing a Relational Model

A relational model consists of the definition of the domains and relations that make up the model.

Declaring relations

model University
domains
   IdentifiersOfStudents = s01 .. s99	
   PersonNames = string
   Years = Yearnumber	
   StaffNumbers = 1000 .. 9999
   Regions = 1 ..9	
   CodesOfCourses = c1 .. c9
   TitlesOfCourses = string	
   CreditValues = (30, 60)
   AssignmentNumbers = 1 .. 5	
   Grades = 0 .. 100
relation Student
   StudentId: IdentifiersOfStudents	
   Name: PersonNames
   Registered: Years	
   CounsellorNo: StaffNumbers
   Region: Regions	
   primary keyStudentId
relation Course
   CourseCode: CodesOfCourses	
   Title: TitlesOfCourses
   Credit: CredutValues		
   primary keyCourseCode
relation Enrolment
   StudentId: IdentifiersOfStudents	
   CourseCode: CodesOfCourses
   TutorNo: StaffNumbers		
   primary key(StudentId, CourseCode)
relation Staff
   StaffNo: StaffNumbers	
   Name: PersonNames
   Region: Regions		
   primary keyStaffNo
relation Assignment
   StudentId: IdentifiersOfStudents	
   CourseCode: CodesOfCourses
   AssignmentNo: AssignmentNumbers
   Grade: Grades		
   primary key(StudentId, CourseCode, AssignmentNo)

Domains express some of the meaning of the data by limiting the allowable comparisons and operations. The value of StudentId in a tuple of Student is comparable with the value of StudentId in a tuple of Enrolment as these will lie in the same domain. The value of an AssignmentNumber in a tuple of Assignment cannot be compared to the value of Region in a tuple of a Student even though the underlying data type may be the same.

There can be only one primary key. If there are numerous attributes linked to being the primary key, these must be viewed as a whole. They are not different primary keys.

Attempting to include a tuple that includes a primary key value that already exists within the database will fail. Attempting to include a tuple where one or more of the values fall outside the permitted range for a given attribute will fail. The semantic constraints will not allow for such circumstances.

Formal definition of a relation

A relation R on domains D1, D2 ...,Dn, not neccessarily distinct, consists of a heading and a body.

The heading (also referred to as the intension) consists of a set of attributes (A1, A2, ...,An) such that each attribute Ai corresponds to exactly one domain Di(i=1, 2, ...n).

The body (or extension) consists of a variable set of distinct tuples each of the form <A1 :v1, A2 :v2, ..., An :vn >, such that each vi is a value from the unique domain Di corresponding to the attribute Ai (i=1, 2, ..., n).

Home| OU Study Rooms | M358 Index | Block 1 - Information Systems | Block 2 - Relational Theory
Back to Structure of Relational Models - Relations.
Move on to Structure of Relational Models - Keys.

Valid CSS! Valid XHTML 1.0!

Comments, suggestions, ideas to
Stuart Banner