Creating the ARTIST Table
Creating the ARTIST Table
We will start by considering two of the tables in the View Ridge database design we developed at the end of Chapter 6, the ARTIST table and the WORK table. These tables are shown in Figure 7-1, and Figures 7-5 and 7-6 show the column characteristics for these tables. Three new features are shown in these figures.
The first is the Microsoft SQL Server IDENTITY({StartValue}, {Increment}) property, which is used to specify surrogate keys. In the ARTIST table, the expression IDENTITY (1, 1) means that ArtistID is to be a surrogate key with values starting at 1 and incremented by 1. Thus, the value of ArtistID for the second row in ARTIST will be (1 + 1) = 2. In the WORK table, the expression IDENTITY (500, 1) means that WorkID is to be a surrogate key with values starting at 500 and incremented by 1. Thus, the value of WorkID for the second row in WORK will be (500 + 1) = 501.
The second new feature is the designation of (LastName, FirstName) in ARTIST as an alternative key. This indicates that (LastName, FirstName) is a candidate key for the ARTIST table. Alternative keys are defined using the UNIQUE constraint.
The third new feature is the use of the DEFAULT column constraint in the Description column of the WORK table. The DEFAULT constraint is used to set a value that will be inserted into each row unless some other value is specified.
Figure 7-7 describes in tabular form the M-O relationship between ARTIST and WORK shown in Figure 7-1, and Figure 7-8 [based on the template in Figure 6-28(a)] details the
Figure 7-5
Column Characteristics for
referential integrity actions that will be needed to enforce the minimum cardinalities in
the ARTIST Table
the ARTIST-to-WORK relationship.
ARTIST
Column Name
Type
Key
NULL Status
Primary Key
NOT NULL
Surrogate Key IDENTITY (1,1)
LastName
AK1 FirstName
Char (25)
Alternate Key NOT NULL
AK1 Nationality
Char (25)
Alternate Key NOT NULL
Column Name
Type
Key
NULL Status
Primary Key
NOT NULL
Surrogate Key IDENTITY (500,1)
NOT NULL
NOT NULL
Figure 7-6
value = Column
‘Unknown Characteristics
provenance’ for the WORK
ArtistID
Int
Foreign Key
NOT NULL
Chapter 7 SQL for Database Construction and Application Processing
Cardinality Figure 7-7
Nonidentifying 1:N M-O Relationship
The ARTIST-to-WORK
Action on ARTIST
Action on WORK
Is Required Parent (Parent)
Get a parent
Modify key or
Prohibit—ARTIST uses a
Prohibit—ARTIST uses a
Foreign key
surrogate key
surrogate key
Delete
Prohibit if WORK exists—
None
data related to a
Figure 7-8
transaction is never deleted (business rule)
Actions to Enforce Minimum
Allow if no WORK exists
Cardinality for the ARTIST-
(business rule)
to-WORK Relationship
Figure 7-9
SQL Statements to Create the Initial Version of the ARTIST Table
Figure 7-9 shows the SQL CREATE TABLE statement for constructing the ARTIST table. (All of the SQL in this chapter runs on SQL Server. If you are using a different DBMS, you may need to make adjustments so consult the chapter or appendix for the DBMS you are using.) The format of CREATE TABLE is the name of the table followed by a list of all column definitions and constraints enclosed in parentheses and ending with the ubiquitous SQL semicolon (;).
As stated earlier, SQL has several column and table constraints: PRIMARY KEY, NULL, NOT NULL, UNIQUE, FOREIGN KEY, and CHECK. The PRIMARY KEY constraint is used to define the primary key of the table. Although it can be used as a column constraint, because it has to be used as a table constraint to define compound primary keys, we prefer to always use it as a table constraint, as shown in Figure 7-9. The NULL and NOT NULL column constraints are used to set the NULL status of a column, indicating whether data values are required in that column. The UNIQUE constraint is used to indicate that the values of a column or columns must not use repeated values. The FOREIGN KEY constraint is used to define referential integrity constraints, and the CHECK constraint is used to define data constraints.
In the first section of the CREATE TABLE statement for the ARTIST table, each column is defined by giving its name, data type, and null status. If you do not specify the null status using NULL or NOT NULL, then NULL is assumed.
In this database, DateOfBirth and DateDeceased are years. YearOfBirth and YearDeceased would have been better column names, but that is not how the gallery personnel refer to them. Because the gallery is not interested in the month and day of an artist’s birth and death, those columns are defined as Numeric (4, 0), which means a four-digit number with zero places to the right of the decimal point.
The last two expressions in the SQL table definition statement in Figure 7-9 are constraints that define the primary key and a candidate, or alternate, key. As stated in Chapter 6, the
Part 3 Database Implementation
primary purpose of an alternate key is to ensure uniqueness of column values. Thus, in SQL, alternate keys are defined using the UNIQUE constraint.
The format of such constraints is the word CONSTRAINT followed by a constraint name provided by the developer followed by either the PRIMARY KEY or UNIQUE keyword and then one or more columns in parentheses. For example, the following statement defines a constraint named MyExample that ensures that the combination of first and last name is unique:
CONSTRAINT MyExample UNIQUE (FirstName, LastName),
As stated in Chapter 6, primary key columns must be NOT NULL, but candidate keys can be NULL or NOT NULL.
SQL originated in the era of punch-card data processing. Punched cards had only uppercase letters, so there was no need to think about case sensitivity.
When cards were replaced by regular keyboards, DBMS vendors chose to ignore the difference between uppercase and lowercase letters. Thus, CREATE TABLE, create table, and CReatE taBle are all the same in SQL. NULL, null, and Null are all the same as well.
Notice that the last line of the SQL statement in Figure 7-9 is a closed parenthesis followed by a semicolon. These characters could be placed on the line above, but dropping them to a new line is a style convention that makes it easy to determine the boundaries of CREATE TABLE statements. Also notice that column descriptions and constraints are separated by commas but that there is no comma after the last one.
Many organizations have developed SQL coding standards of their own. Such standards specify not only the format of SQL statements, but also
conventions for naming constraints. For example, in the figures in this chapter we use the suffix PK on the names of all primary key constraints and the suffix FK for all foreign key constraints. Most organizations have standards that are more comprehensive. You should follow your organization’s standards, even if you disagree with them. Consistent SQL coding improves organizational efficiency and reduces errors.