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.