1. No category

1. Preamble
Date Last Modified: May 8, 2009
By: Gautam Sharma – [email protected]
Project: Electronic Supplementary Lecture Summaries
Background Summary:
Students and professors attend the University of Rochester to learn and teach. They expect a solid
education, which they can use when they pursue their future ambitions. In order to achieve a excellent
education, I introduce electronic Supplemental Lecture Summaries. eSLS takes into consideration the
limited access students may have to the University of Rochester’s Learning Assistance Services. This
fulfills the value of education and level of guidance that students expect when attending the University of
Rochester. Students will know the information from classes well enough not only to perform well on
exams and homework, but also to use this knowledge elsewhere with ease.
Honesty Statement:
Mindful of the University's policy on plagiarism, I hereby solemnly declare that, aside from high level
ideas, all project materials, including but not restricted to descriptions, diagrams, schemas, SQL
statements and web pages and programs, will be developed uniquely, exclusively and independently by
me.
Gautam Sharma
_______________________
2. Domain Description:
eSLS provides access to additional resources that students can access at any time and through any internet
accessible location. It is a student-run service, but professors can view it as well. Students can register as
employees to submit lecture summaries, which are accessible through video links. They can also register
as users to order and view the lecture summaries. Submitters will submit lecture summaries for each class
session of a particular class for the entire academic school year. They must have a GPA above 3.0 and be
approved by an administrator to submit summaries. If students only want to order lecture summaries,
they can do so by signing up as viewers. They will need to provide their email address, first name, last
name, and GPA regardless of whether they are signing up as employees or viewers. They will log in
using their UR email address. In order to make it easier for those who would like to order the lecture
summaries, users will be able to search and view the lecture summaries by course registration number
(CRN), subject, course number, professor, semester, year, and date of each class session. Viewers can
also submit ratings of each lecture summary, which will be recorded. Much of the information, such as
the email address and first and last name will be used to send out newsletters, updates, and make sure that
those who submit and view the lecture summaries are only students and professors at the University of
Rochester.
3. Sample Queries - English
1. Find all the viewers whose email addresses contain the letter “g” and have ordered a lecture summary.
2. List each lecture summary that is a 200-level class and submitted by a submitter who has a GPA of 3.7
or higher.
3. How many viewers have GPA above 3.8, have Professor Koomen as their professor and submit and
view lecture summaries?
4. Find courses that have received perfect (10) quality ratings but are not for Computer Science classes.
5. Find all summaries from March 16, 2009 that were submitted and viewed by those whose names start
with “He” or whose last names start with “S.”
6. Submit a new lecture summary for ECO211 with Professor Michael Rizzo during Spring 2009 with
course registration number 38745 and then order it.
4. Entity-Relationship Diagram
Dated: March 17, 2009
FIRSTNAME
GPA
EMAILADDRESS
LASTNAME
VIEWERS
PASSWORD
COULD
BE
MAKE
EMPLOYEE
ORDERS
SUBMITS
ORDERNUMBER
DATE
VIDEOLINK
LECTURES
LECTURENO.
QUALITY
CONTAIN
PROFESSOR
CRN
CLASSES
SUBJECT
SEMESTER
COURSENO.
YEAR
Dated: April 1, 2009
Dated: April 15, 2009
5. Relational Schema 1
Viewers(Emailaddress, Firstname, Lastname, GPA, Employed)
Order(OrderNo., LectureNo., Emailaddress)
Lectures(LectureNo., CRN, Date, Quality, Videolink)
Classes(CRN, Subject, CourseNo., Professor, Semester, Year)
6. Sample Queries Relational algebra 1
7. Functional Dependencies 1
ViewersEmailaddress ViewersFirstname, ViewersLastname, GPA, Employed)
OrdersOrderNo. OrdersEmailaddress, OrdersLectureNo.
LecturesLectureNo. LecturesCRN, LecturesDate, LecturesQuality, LecturesVideoLink
ClassesCRN ClassesSubject, ClassesCourseNo., ClassesProfessor, ClassesSemester,
ClassesYear
8. Proof of Normal Form 1
There are redundancies so the Functional Dependencies are not in Normal Form. The Relational
Schema is not in proper form so it also contains redundancies such as the use of two LectureNo.
when it is unnecessary to mention both.
9. Relational Schema 2
Viewer(EmailAddress, FirstName, LastName, Approved, GPA)
Order(OrderNo, OrderDate)
Place(OrderNo, EmailAddress)
Summary(SummaryID, URL, SummaryDate)
Ordered(SummaryID, OrderNo)
Submit(SummaryID, EmailAddress, SubmitDate)
Rate(SummaryID, EmailAddress, Rating)
Course(CRN, Subject, CourseNo, Semester, Year, Professor)
Lecture(LectureNo, CRN, LectureDate)
Summarizes(SummaryID, LectureNo, CRN)
Contain(LectureNo., CRN)
10. Functional Dependencies 2
EmailAddress FirstName, LastName, Approved, GPA
OrderNo OrderDate
SummaryID URL, SummaryDate
CRN Subject, CourseNo, Semester, Year, Professor
LectureNo, CRN LectureDate
11. Proof of Normal Form 2
3NF, BNCF
Every non-prime attribute is directly dependent on every key of the relations.
•
•
•
•
•
FirstName, LastName, Approved, and GPA are non-prime attributes, and they are
directly dependent on the only key in the Viewer relation, EmailAddress
Date is a non-prime attribute, and it is directly dependent on the only key in the Order
relation, OrderNo
URL and Date are non-prime attributes, and they are directly dependent on the only key
in the Summary relation, SummaryID
Subject, CourseNo, Semester, Year, and Professor are non-prime attributes, and they are
directly dependent on the only key in the Course relation, CRN
Date is a non-prime attribute, and it is directly dependent on the only keys in the weakentity and relation Lecture, LectureNo and CRN
All functional dependencies are non-trivial. All the attributes left of the arrows in the functional
dependencies are superkeys.
Since every determinant is a candidate key (it determines the rest of the attributes in the relation)
and occurs in no more than one tuple, my relational schema is in BCNF as well.
Since there are no multivalued functional dependencies, my database is not in 4NF.
12. Sample Queries – Relational algebra 2
1) Find all the viewers whose email addresses contain the letter “g” and have ordered a lecture summary.
πFirstName, LastName(σ(EmailAddress = ‘%g%’)(Viewer |X| Place))(Viewer)
2) List each lecture summary that is a 200-level class and submitted by a submitter who has a GPA of 3.7
or higher.
πSummaryID(σ(CourseNo ≥ ‘200’) (σ(GPA ≥ ‘3.5’)(Submit |X| Viewer)))(Submit |X| Summary |X| Summaries
|X| Lecture |X| Contain |X| Course)(Summary)
3) How many viewers have GPA above 3.8, have Professor Koomen as their professor and submit and
view lecture summaries?
πCOUNT(EmailAddress)
((σ(GPA > ‘3.8’)(Submit |X| Viewer |X| Place))
(σ(Professor = ‘Koomen’)(Submit |X| Viewer |X| Summaries |X| Summarizes |X| Lecture |X| Contain |X| Course)))
(Viewer)
4) Find viewer who rated a summary of a non-CSC course perfect (10) quality ratings but are not for
Computer Science classes.
πEmailAddress(σ(Rating = ‘1’ AND Subject <> ‘CSC’)(Rate |X| Summary |X| Summaries |X| Summarizes |X| Lecture |X|
Contain |X| Course))(Rate)
5) Find all summaries from March 16, 2009 that were submitted and viewed by those whose names start
with “He” or whose last names start with “S.”
πSummaryID(σ(SubmitDate = ‘2009-03-16’ AND OrderDate = ‘2009-03-16’ AND FirstName = LIKE ‘HE%’ OR LastName = LIKE
‘S%’)(Submit
|X| Viewer |X| Place |X| Order))(Summary)
13. Database Implementation Status
http://betaweb.csug.rochester.edu/csc290c/gsharma4/dbsetup-sharma.sql
http://betaweb.csug.rochester.edu/csc290c/gsharma4/testqueries-sharma.sql
http://betaweb.csug.rochester.edu/csc290c/gsharma4/testqueriesout-sharma.txt
CREATE TABLE `Viewer` (
`EmailAddress` VARCHAR(50),
`GPA` FLOAT(3),
`FirstName` VARCHAR(20),
`LastName` VARCHAR(20),
`Approved` VARCHAR(1) BINARY,
PRIMARY KEY(`EmailAddress`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
11 rows
CREATE TABLE `Order` (
`OrderNo.` INT(11) AUTO_INCREMENT,
`OrderDate` DATETIME,
PRIMARY KEY(`OrderNo.`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
12 rows
CREATE TABLE Summary (
SummaryID INT(11) AUTO_INCREMENT,
URL VARCHAR(50),
SummaryDate DATETIME,
PRIMARY KEY(SummaryID) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
20 rows
CREATE TABLE Course (
CRN INT(5),
Subject VARCHAR(3),
`CourseNo.` INT(3),
Semester VARCHAR(6),
Year INT(4),
Professor VARCHAR(20),
PRIMARY KEY(CRN) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
3 rows
CREATE TABLE Lecture (
`LectureNo.` INT(11) AUTO_INCREMENT,
CRN INT(5),
LectureDate DATETIME,
PRIMARY KEY(`LectureNo.`),
FOREIGN KEY(CRN) REFERENCES Course(CRN)
ON DELETE SET NULL
ON UPDATE CASCADE )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
8 rows
CREATE TABLE Place (
EmailAddress VARCHAR(50),
`OrderNo.` INT(11),
FOREIGN KEY (EmailAddress) REFERENCES `Viewer`(`EmailAddress`),
FOREIGN KEY (`OrderNo.`) REFERENCES `Order`(`OrderNo.`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
12 rows
CREATE TABLE Ordered (
SummaryID INT(11),
`OrderNo.` INT(11),
FOREIGN KEY(SummaryID) REFERENCES `Summary`(`SummaryID`),
FOREIGN KEY(`OrderNo.`) REFERENCES `Order`(`OrderNo.`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
12 rows
CREATE TABLE Submit (
SummaryID INT(11),
EmailAddress VARCHAR(50),
SubmitDate DATETIME,
FOREIGN KEY(SummaryID) REFERENCES `Summary`(`SummaryID`),
FOREIGN KEY(EmailAddress) REFERENCES `Viewer`(`EmailAddress`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
20 rows
CREATE TABLE Rate (
SummaryID INT(11),
EmailAddress VARCHAR(50),
Rating INT(2),
FOREIGN KEY(SummaryID) REFERENCES `Summary`(`SummaryID`),
FOREIGN KEY(EmailAddress) REFERENCES Viewer(`EmailAddress`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
20 rows
CREATE TABLE Summarizes (
SummaryID INT(11),
`LectureNo.` INT(11),
CRN INT(5),
FOREIGN KEY(SummaryID) REFERENCES `Summary`(`SummaryID`),
FOREIGN KEY(`LectureNo.`) REFERENCES `Lecture`(`LectureNo.`),
FOREIGN KEY(CRN) REFERENCES `Course`(`CRN`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
20 rows
CREATE TABLE Contain (
`LectureNo.` INT(11),
`CRN` INT(5),
FOREIGN KEY(`LectureNo.`) REFERENCES `Lecture`(`LectureNo.`),
FOREIGN KEY(CRN) REFERENCES `Course`(`CRN`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
8 rows
14. Website Query Status 1
This query lists all the viewers of the database. A user can click on his/her name or another
person’s name and further delve into the database, but retrieving information regarding whether
or not they can submit summaries, what they’re display First Name and Last Name is, what
summaries they have submitted, and what summaries they have ordered. In order to display
summaries viewers have submitted, I had to natural join four relations. In order to display
ordered summaries, I had to natural join fix relations. Additionally, the ratings the viewer has
given per summary ordered are listed below as well, requiring four relations to be natural joined.
http://betaweb.csug.rochester.edu/csc290c/gsharma4/mvc/index.php
Other than an exercise of retrieving information from numerous parts of the database, my
objective was to provide a central location where user can view and edit their information.
15. Website Query Status 2
This query allows user to access their centralized page by entering their email address or entering
their First and Last Names into text fields and retrieving the centralized information page
following a click of a button. Users have the ability to access their information through different
means. Such accessibility accommodates the diverse group of students and faculty that are going
to be the database’s target users.
http://betaweb.csug.rochester.edu/csc290c/gsharma4/mvc/index.php
16. Website Query Status 3
When you have reached the centralized page, you can click on the user’s name. This allows you
to retrieve more information regarding the user, specifically his GPA, which correlates directly
with his ability to submit summaries. Furthermore, the user has the capacity to modify his GPA
as it changes per semester by simply entering his email address and his revised GPA. From the
index.php page, students interested can also sign up to become viewers. After submitting their
information, they can click on “list all viewers” button and see their name on the user list. After
being entered into the system, they can view their centralized homepage as well and monitor it as
they submit and order more summaries.
http://betaweb.csug.rochester.edu/csc290c/gsharma4/mvc/index.php
17. Additional Database Capabilities
There are constraints in my database between the relations that make sure that there is
consistency between the tables. By implementing foreign keys, such that for example, the
SummaryID in the Summary and Submit relations have to be the same as do the CRNs, I was
very close to having a submit and order query, but it did not work due to previous auto-increment
and constraint problems.
18. Additional Website Capabilities
In order to make it easier to fill forms, I have implemented an echo effect that allows users to
view previously submitted information in the text fields.
In order to make sure viewers know that they are modifying their GPA, they must re-enter their
email address and enter a new GPA.
I have used several link capabilities that were generated through while loops in order to access
user information, such as upon listing viewers, viewers can click on their first and last name in
order to access their information. When editing their GPA, they click on their name yet again.
19. Project Demo
I will briefly touch upon the background behind the database and website. I will talk about the
domain description, after which I will describe my E-R diagram. Then I will proceed to describe
my Relational Schema, Functional Dependencies, Normalization, and Website Queries.