The purpose of this course is to introduce the fundamental concepts of database management, including aspects of data models, database languages, and database design. At the end of this course, a student will be able to understand and apply the fundamental concepts required for the use and design of database management systems.

Through this course, students shall

• become proficient at modeling databases at conceptual and logical levels of design,
• be able to develop database schemas with principled design that enforce data integrity,
• become knowledgeable in the creation, altering, and manipulation of tables, indexes, and views using relational algebra and SQL,
• become proficient at casting queries in SQL,
• and at writing database application programs with an understanding of transaction management, concurrency control, and crash recovery.

Topics to be covered include the following.

1. design:
   • conceptual design (E-R modeling)
   • the relational model
   • normalization (What are the criteria of good design?)
2. queries:
   • algebra and logic (relational algebra and calculus)
   • relational query languages and queries (namely SQL)
     • select, project, join
     • union, intersection, except
     • recursion
     • aggregation
   • data manipulation
3. applications:
   • application development
     • database application interfaces (e.g., JDBC)
     • internet applications
     • proper database application paradigms
   • transactions
     • transaction management
     • concurrency control
     • crash recovery

Course materials will be primarily drawn from the assigned readings from the course textbook (Garcia-Molina, Ullman, & Widom, 2009).

Useful reference books for the course include:

Jim Melton and Alan R. Simon.

SQL 1999: Understanding Relational Language Components.

First Edition, 1999.

Morgan Kaufmann Publishers.

ISBN: 1-55860-456-1

Don Chamberlin.

Using the New DB2: IBM's Object-Relational Database System.

First Edition, 1996.

Morgan Kaufmann Publishers.

ISBN: 1-55860-373-5

The tests (including the final exam) are cumulative, testing all the material up to that point.

The grading policy is standard for tests, exams, and projects. For projects, discussion is fine, but your work must be your own.

York University's rules for academic honesty and plagiarism are always in effect. ( See below.) Discussion is fine on the assignments and projects. However, collaboration is not. The work must be your own.

There will be four projects over the term.

The projects will use the IBM DB2 Universal Database system (v10). In project 1, students will design an ER schema for a given problem domain. In project 2, students will design and implement a relational database under our DB2 system. In project 3, students will compose sophisticated SQL, XPath, and XQuery queries for existing databases. Project 4 will involve programming to implement a database application program.

All work for the projects should be prepared in a professional manner. Work should be typeset, and run through a spell-checker. Due dates are as indicated in the schedule above. Projects (P₁–P₄) will be due by 11:59pm on Friday of the week indicated. The last project (P₄) is due on Monday 5 December. Each project should be turned in both via the submit program and/or by hard copy in the class dropbox, as will be indicated for each project.

Late projects will be accepted up to 48 hours after the due date with a 20% penalty.

Further details will be established as the project assignments are posted.

Exams must be taken when scheduled unless the student has a medical documentation or can demonstrate special circumstances for a need for a rescheduled exam. The student must obtain approval from the instructor.

Class attendance is useful and encouraged as the student will have an opportunity to ask for clarification of course and text material. There will be problem solving sessions during class period so that students gain experience applying the theory in practice. However, class attendance will not be monitored and is not part of the grade.

On e-mail from students with questions regarding course materials.

• I will not answer these e-mails by e-mail reply, in general.

  My time is spent more productively for the class's sake in different ways. For pertinent questions on the materials that students send me by e-mail — or for questions that many people seem to be having — I will try to address them in class.

  If you have an urgent question I have not addressed, come see me during my office hours, or make an appointment if you need to. Many students do this already; it is a good use of my time and theirs. I can usually answer a question a student asks in person in about a tenth the time than by an e-mail exchange. Writing it out takes much longer. And for many of the questions people send me, the question is often unclear. It then requires a back and forth by e-mail several times.

On e-mail from students with issues regarding administrative matters.

• For administrative requests (e.g., “I cannot make the test,”), e-mail is fine, of course, and I will attempt to answer you directly.

Please use a York University account when e-mailing me (with regards to the course), so that I can know who it is. Please include [3421] at the beginning of the subject line so I am able to sort it.

I do not mind students sending questions by e-mail. Just do not necessarily expect a direct reply. I do read them, and I try to address the issues and questions people raise. If your question or issue remains after some time, do let me know.

The Department of Electrical Engineering & Computer Science's Academic Honesty Guidelines are in effect for this course, as, indeed, they are for any EECS course.

Plagiarism is defined as taking the language, ideas, or thoughts of another, and representing them as your own. If you use someone else's ideas, cite them. If you use someone else's words, clearly mark them as a quotation. Note that plagiarism includes using another's computer programs or pieces of a program. All noted instances of plagiarism will be reported.

These policies are not intended to keep students from working with other students. One can learn much working with others, so this is to be encouraged. Should you encounter any situations for which you are uncertain whether the collaboration is permitted or not, please ask.