Scribd
Upload
523 views2 pages

Ch3 Exercise

The document describes the requirements for a university database to track student enrollments and grades. The database needs to store information about colleges, departments, courses, instructors, students, and course sections. It must keep track of which department and instructor each section is associated with, as well as which students are enrolled in each section and their grades. Several attribute combinations must be unique for each section, such as the section number, semester, year, and course, to ensure sections don't overlap.

Uploaded by

Toqa Hayajneh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
523 views2 pages

Ch3 Exercise

The document describes the requirements for a university database to track student enrollments and grades. The database needs to store information about colleges, departments, courses, instructors, students, and course sections. It must keep track of which department and instructor each section is associated with, as well as which students are enrolled in each section and their grades. Several attribute combinations must be unique for each section, such as the section number, semester, year, and course, to ensure sections don't overlap.

Uploaded by

Toqa Hayajneh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

University Database

Suppose that a database is needed to keep track of student enrollments in classes and students’ final grades. After analyzing the
miniworld rules and the users’ needs, the requirements for this database were determined to be as follows:
 The university is organized into colleges (COLLEGE), and each college has a unique name (CName), a main office
(COffice) and phone (CPhone), and a particular faculty member who is dean of the college.
 Each college administers a number of academic departments (DEPT). Each department has a unique name (DName), a
unique code number (DCode), a main office (DOffice) and phone (DPhone), and a particular faculty member who
chairs the department. We keep track of the start date (CStartDate) when that faculty member began chairing the
department.
 A department offers a number of courses (COURSE), each of which has a unique course name (CoName), a unique
code number (CCode), a course level (Level: this can be coded as 1 for freshman level, 2 for sophomore, 3 for junior, 4
for senior, 5 for MS level, and 6 for PhD level), a course credit hours (Credits), and a course description (CDesc).
 The database also keeps track of instructors (INSTRUCTOR); and each instructor has a unique identifier (Id), name
(IName), office (IOffice), phone (IPhone), and rank (Rank); in addition, each instructor works for one primary
academic department.
 The database will keep student data (STUDENT) and stores each student’s name (SName, composed of first name
(FName), middle name (MName), last name (LName)), student id (Sid, unique for every student), address (Addr),
phone (Phone), major code (Major), and date of birth (DoB). A student is assigned to one primary academic
department. It is required to keep track of the student’s grades in each section the student has completed.
 Courses are offered as sections (SECTION). Each section is related to a single course and a single instructor and has a
unique section identifier (SecId). A section also has a section number (SecNo: this is coded as 1, 2, 3, . . . for multiple
sections offered during the same semester/year), semester (Sem), year (Year), classroom (CRoom: this is coded as a
combination of building code (Bldg) and room number (RoomNo) within the building), and days/times (DaysTime: for
example, ‘MWF 9am-9.50am’ or ‘TR 3.30pm-5.20pm’—restricted to only allowed days/time values). (Note: The
database will keep track of all the sections offered for the past several years, in addition to the current offerings. The
SecId is unique for all sections, not just the sections for a particular semester.) The database keeps track of the students
in each section, and the grade is recorded when available (this is a many-to-many relationship between students and
sections). A section must have at least five students.
Notice that for the SECTION entity type, we only showed SecID as an underlined key, but because of the miniworld
constraints, several other combinations of values have to be unique for each section entity. For example, each of the following
combinations must be unique based on the typical miniworld constraints:
1. (SecNo, Sem, Year, CCode (of the COURSE related to the SECTION)): This specifies that the section numbers of a
particular course must be different during each particular semester and year.
2. (Sem, Year, CRoom, DaysTime): This specifies that in a particular semester and year, a classroom cannot be used by two
different sections at the same days/time.
3. (Sem, Year, DaysTime, Id (of the INSTRUCTOR teaching the SECTION)): This specifies that in a particular semester and
year, an instructor cannot teach two sections at the same days/time. Note that this rule will not apply if an instructor is allowed
to teach two combined sections together in the particular university.

Can you think of any other attribute combinations that have to be unique?

You might also like