88-271 Homepage
Display in Printable Format

Home
Lecture Notes
   Lecture 1
   Lecture 2
   Lecture 3
   Lecture 4
   Lecture 5
   Lecture 6
   Lecture 7
   Lecture 8
   Lecture 9
   Lecture 10
   Lecture 11
Sample Solutions
   Homework #1
   Homework #2
   Homework #3
   Homework #4
   Homework #5
Common Homework Errors
   Homework #1
   Homework #2
   Homework #3
   Homework #4
   Homework #5
Exams
   Exam 1 Sample Solution
UML Use Case FAQ

88-271 Homework #4: Common Errors

The homework was worth 10 points; students could lose a maximum of 6 points on problem 1, 3 points on problem 2, and 1 point on problem 3. Unlike our other homeworks in this course, there really is only one correct answer, posted as the sample solution. Please refer to it when examining your own work.
Error #Explanation
1 Incorrect or missing column data type: The table columns defined in SQL statements required in problem 1 should have had datatypes such as DECIMAL or INTEGER, CHAR, etc., along with a width for these types (i.e. DECIMAL(8)).
2 Inconsistent or nonsensical example data: The example data you filled in to the graphical tables was not consistent with either the datatypes you specified or with the other tables. For example, the data given in the Reserves table was not the same as data from the object tables.
3 Bad or missing ID column or primary key: Every table must have a primary key, typically one column, whose values are unique to each row. This error was flagged on your paper if you did not provide a sufficient primary key column. In this assignment, none of the domain properties (fare, fareCode, recordLocator) were sufficient to uniquely distinguish the rows of their respective tables, so you were expected to create an ID column for each table.
4 Poor choice of column width: The datatype definitions of the columns in the table should have had width specifications (i.e. DECIMAL(8)). For primary keys, the columns should be made wide enough to accomodate enough distinct rows to make the database useful. If you choose this width to be too small, you will create a limit on how many records the database can contain (like a Y2K problem.) To avoid this, use a reasonable number like 8 (100 million records) or more.
5 Incorrect use of INSERT: We did not ask you to use the SQL INSERT statement to add the example data to your tables, but if you did and you received this mark, it is because you did it wrong. Thought you'd like to know. The correct syntax for inserting a simgle row of data into a table is:

INSERT INTO TableName ( Field1, Field2, ... ) VALUES ( Datum1, Datum2, ... )
6 Inconsistent SQL and diagrams: You may have drawn diagrams that reflected different tables from those that were defined in the CREATE TABLE statements you were asked to compose.
7 Reserves is a many-to-one association: Your table structure did not reflect the Reserves association's ability to be many-to-one between Flights and FlightReservations.
8 Extra columns in tables: Some of you included additional columns in your table definitions that either belonged elsewhere, were redundant, or simply didn't belong in the solution at all. The only columns that should have appeared were (a) the domain attributes given in the Class diagram, and at most one ID column that you created as a primary key.
9 ID values are not used to relate rows between tables: We just wanted to remind you that the ID values you choose for your primary key columns are arbitrary and unimportant. The fact that two rows from two different tables have the same value does not indicate that they are related in any way; realtions (associations are shown with relational tables such as the Reserves table.
10 Incorrect expression of association: This error should indicate to you that your design does not correctly support the Reserves association. Please refer to the sample solution for an explanation of how to do this.
11 Not enough example data: We expected at least three rows from each table to adequately indicate to us that you understood the meanings of the rows. We marked this error to indicate that you had too few examples.
12 Incorrect CREATE TABLE syntax: You may not have used the create table statement correctly. The syntax for creating a table with SQL is:

CREATE TABLE TableName (Field1 Type1(Width1), Field2 Type2(Width2), ..., PRIMARY KEY(KeyField))
13 Examples not demonstrative of table examples: The uniqueness and duplicatability properties of the tables you created should have been illustrated by your choice of the sample data, but your choice was "safer" than that.
14 Missing SQL statements: You did not complete the part of question 1 that asked you to write the SQL CREATE TABLE statements.
15 Table names should correspond to object names: Your choices for table names should have corresponded to the names of the objects given in the analysis Class diagram given to you (i.e. Flight, FlightReservation, TripReservation, and Ticket.)
16 Missing PRIMARY KEY definition: All tables must have a primary key, and it must be specified in the CREATE TABLE statement.
17 Missing field headings: Your diagram should have had field headings on the tables, corresponding to the attributes of the objects.
18 Sample data inconsistent with Reserves association: The Reserves table should not contain multiple occurances of a single FlightReservation object; this would violate the cardinality of the association, which states that each FlightReservation must have exactly one Flight, no more.

Copyright © 1998, Carnegie Mellon University
Site maintained by Ben Ziskind