To understand the concept of candidate and primary keys and their application in table creation.

Transcription

1 CM0719: Database Modelling Seminar 5 (b): Candidate and Primary Keys Exercise Aims: To understand the concept of candidate and primary keys and their application in table creation. Outline of Activity: 1. Declare candidate and primary keys for the tables previously established. The following pages give you detailed instructions for performing this task.

2 In a relational database, each table (relation) must have at least one Candidate Key. Remember, tuples must have unique values on the Candidate Key(s) at all times. Exercise 2.2: What Candidate Key(s) can you identify for the EMP table? and for the DEPT table? and for the PROJ table? One Candidate Key per table is selected to be the Primary Key, and an appropriate constraint is set up in Oracle 11g. However, if there are any other Candidate Keys (Alternate Keys), it is possible, and indeed desirable, to constrain them also to have unique values. SETTING PRIMARY AND ALTERNATE KEYS IN SQL The CHECK constraint can be used to implement the PRIMARY KEY constraint. As with other types of constraint, each one should be given a name, and it is helpful if we adopt a consistent convention. We shall use names of the form PKEYunderscore-tablename, e.g. PKEY_EMP for the EMP table. Implement the constraint by dropping the existing EMP table from the database and then re-creating it with a modified CREATE TABLE statement (the columns, the datatypes and the other constraints are as shown above) SQL> DROP TABLE EMP; Table dropped. SQL> CREATE TABLE EMP 2 (EMP_NO CHAR(2) 3 CONSTRAINT PKEY_EMP PRIMARY KEY, 4 EMP_NAME CHAR(10), 5 SALARY NUMBER(10), 6 MARITAL_STATUS CHAR(1) 7 ); Table created. In the case of the EMP table, there was only one Candidate Key, which has now become the Primary Key. DEPT on the other hand has two Candidate Keys, DEPT_NO (the obvious one) and also DEPT_NAME. Although a company could conceivably have two departments with the same name, it clearly does not make sense to give the same name to more than one Department. We will make DEPT_NO the Primary Key, but will also set a UNIQUE constraint on the Alternate Key, DEPT_NAME:

3 Exercise 2.3: You should complete and run the following SQL statement to recreate the DEPT table. What else do you need to do first? SQL> CREATE TABLE DEPT 2 (DEPT_NO CHAR(2) 3 CONSTRAINT PKEY_DEPT PRIMARY KEY, 4 DEPT_NAME CHAR(10) 5 CONSTRAINT UNIQ_DEPT_NAME UNIQUE, : : ADDING CONSTRAINTS TO AN EXISTING ORACLE TABLE You will probably have decided by now that it is exceedingly cumbersome to drop and re-create a table whenever an additional constraint needs to be added. Fortunately, SQL provides an ALTER TABLE statement which, among other uses, enables us to add constraints more simply. A partial description of its syntax is: ALTER TABLE table-name <add clause> ; where the add clause may be defined, again partially, as: ADD ( {<table constraint> } ) Constraints are dealt with more generally in the exercises for week 3. The important thing to note for present purposes is that we must specify which column(s) of the table a PRIMARY KEY or UNIQUE constraint refers to. Here is an example to try out, in which an additional constraint is added to the DEPT table. It happens to be company policy that no-one can manage more than one department at the same time hence the MANAGER_NO column in DEPT has unique values. That does not in fact make MANAGER_NO another Alternate Key (for reasons which will become apparent later), but it does allow us to set a UNIQUE constraint:

4 SQL> ALTER TABLE DEPT 2 ADD CONSTRAINT UNIQ_MANAGER UNIQUE (MANAGER_NO); Table altered. COMPOSITE KEYS IN SQL Candidate Keys do not always consist of just one column. When we have a choice, we normally select the smallest candidate to be the Primary Key, but nevertheless it sometimes happens that we end up with a composite Primary Key of more than one column. In such a case it is not possible to set the Primary Key by means of a column constraint; we are obliged to use a table constraint even when setting the key at the same time as we create the table. For this purpose we need to use the extension of the CREATE TABLE syntax that we saw in Exercise 2, when setting a table constraint to prevent the DEADLINE for a project being before it s START_DATE: CREATE TABLE table-name ( <column definition> [, etc.] [, <table constraint> [, etc.] ] ) ; This indicates that the column definitions may optionally be followed, still within brackets, by one or more table constraints, separated from the column definitions and from each other by commas. By way of an example, here is an additional table for your database, to indicate which employees are working on which projects: Table Column Name Description Data-type Name ALLOC EMP_NO An Employee s Number. CHAR(2) PROJ_NO The Number of a Project. CHAR(2) Exercise 2.4: Why is EMP_NO on its own not a Candidate Key? Why is PROJ_NO not a Candidate Key? Hence the only Candidate Key consists of both columns. Set up the table as follows:

5 SQL> CREATE TABLE ALLOC 2 (EMP_NO CHAR(2), 3 PROJ_NO CHAR(2), 4 CONSTRAINT PKEY_ALLOC PRIMARY KEY (EMP_NO, PROJ_NO) 5 );