(SQL): A Primer on Data Definition Language (DDL) Konana, 2000 Prabhudev Konana, Ph.D. Assistant Professor The Graduate School of Business The University of Texas at Austin Austin, TX 78712
Introduction to Structured Query Language (SQL) Structured Query Language (SQL) is an international standard (and American National Standards Institute ANSI) for definition and manipulation of databases. Almost all database vendors support SQL while adding their own SQL extensions. Originally developed by IBM as a result of the work on the relational model, it was first made commercial by Relational Systems, now called Oracle Corporation in late 1970s. D. Chamberlin of IBM first defined a language that was called Structured English Query Language (SEQUEL) where the programmer or the business user could define, query or manipulate database with simple English-like statements. These English-like statements could be embedded within other procedural languages (e.g., COBOL, C, Pascal etc.) saving significant amount of coding that programmers typically wrote. Why SQL SQL has been created such that it is intuitive, simple (relatively speaking ), non-procedural (that is, one need not specify step-by-step instructions to execute certain actions) and maps human s cognitive model. Ideally, programmers and business users need not know how or where data is stored. They should be able to specify what they want and how they want given their requirements (e.g., conditions or additional computations such as sum, average, and maximum). Furthermore, they should be able to specify according to how our human mind conceptualizes the query in mind. Albeit, translating certain complex queries into SQL statements may be difficult and the constructs may not be powerful enough to define certain requirements. However, despite the limitations, SQL provides a convenient method to create and manipulate databases. And, SQL makes developing applications relatively easier. Anyone who has done programming in COBOL or other languages and then used SQL (and SQL within other languages) will appreciate the power of SQL. SQL Objectives The main objectives of SQL are (Note: This is not an exhaustive list. Complex constructs not relevant for introductory material have been skipped): a. Define database such as tables, attributes, data type, relational keys (primary key, foreign key, referential integrity constraints), domain constraints and indexes. b. Defining data access controls on tables (and other database objects) through Grants, Views. c. Altering, dropping, and replacing the above d. Inserting, updating, and deleting data in the tables e. Performing queries that involve table joins, various types of conditions and nested-queries (i.e., queries within queries). The Objectives (a), (b) and (c) are generally called Data Definition Language (DDL) since they involve definition and management of the basic structure of the database. Items (d) and (e) are referred to Data Manipulation Language. 1
Data Definition Language (DDL) This section covers the basic DDL useful for business users and application programmers. The basic DDL constructs are: a. CREATE TABLE, CREATE VIEWS, CREATE INDEX b. GRANT and REVOKE. c. ALTER TABLE, DROP TABLE, DROP VIEWS CREATE Table The purpose of CREATE Table is to define the table structure along with integrity constraints. The basic structure is as follow ([.] implies optional, italics implies you need to enter appropriate text, bold words are reserved words): CREATE Table table-name ( attribute-name attribute-datatype, attribute-name attribute-datatype,.. [PRIMARY KEY (attribute-name)], [FOREIGN KEY (attribute-name) REFERENCES table-name ON delete-or-update cascade-or-restrict-ornullify] Attribute-datatype are data types that may be vendor specific. The following are some typical data types that most vendors support: Number, char(), varchar2(), Date, and Time. There are other data types to store large binary objects such as images, video etc. usually referred to as BLOB (Binary Large Objects) or CLOB (Character Large Objects). Primary key and Foreign key can be defined is various ways. For example, in Oracle we can define them as CONSTRAINTS. Creating Tables and Primary Key Example 1a: Consider the table CUSTOMER with following attributes: CUSTOMER (custid, custname, phonenum, company, faxnum) The CUSTOMER table will be used to store necessary customer information when they log into a system. Following is the CREATE Table statement for the above example: CREATE TABLE customer ( custid NUMBER(6), custname VARCHAR2(15) phonenum VARCHAR2(20), company VARCHAR2(25), faxnum VARCHAR2(20), PRIMARY KEY (custid) 2
In the above table, custid is the primary key. This attribute is a number of maximum size 6 digits (i.e., 0 to 100,000). VARCHAR2 is a variable character data type (Ignore why it is called varchar2 that is, the system allocates variable size character length for attributes. The number next to VARCHAR2 specifies the maximum size of the character string. Example 1b: The above example has only one attribute in the primary key. We can have two or more attributes as part of the primary key. Consider the following generic example. Assume Attribute-A and Attribute- B are composite primary key. We define the primary key as follows: CREATE TABLE table-name ( Attribute-A Datatype, Attribute-B Datatype, Attribute-C Datatype, Attribute-D Datatype, Attribute-E Datatype, PRIMARY KEY (Attribute-A, Attribute-B) CONSTRAINT Clause Constraints are named items (objects) in Oracle. Using the name of the constraint we can drop or modify them easily. There are two types of constraints: table-level constraints and column-level constraints. Column-level constraints are defined as part of the column definition as in the primary key definition described in Example 2. Table-level constraints are not defined as column-level but at as a separate constraint within CREATE statement. We can define the primary key of Example 1 as column-level constraint as below: Example 2: Note, there is no comma after the data type. Comma comes after Constraint definition CREATE TABLE customer ( custid NUMBER(6) CONSTRAINT pk_customer_custid PRIMARY KEY, custname VARCHAR2(15) phonenum VARCHAR2(20), company VARCHAR2(25), faxnum VARCHAR2(20), When there are multiple attributes in the PRIMARY Key then the constraint should be a table-level constraint, defined as: CONSTRAINT pk_somename PRIMARY KEY (attribute1, attribute2, ) UNIQUE Constraints: UNIQUE constraints refer to Alternate keys. We may have candidate keys that are not chosen as primary keys. Such candidate keys can be defined as UNIQUE constraints so that some 3
combination of attribute values is not repeated. We can define UNIQUE constraints in both column definition and table constraint. When UNIQUE key involves only one attribute then it can be column-level constraint. However, when there are two or more attributes, the UNIQUE constraint must be a table-level constraint. Example 3: The following statement creates the Supplier table and defines and enables a unique key on the name column. The SUPPLIER table will be used to store all the suppliers information. Supplier (supplierid, name, contact, company, faxnum, phonenum) CREATE TABLE supplier ( supplierid VARCHAR2(4) CONSTRAINT pk_supplier_supplierid PRIMARY KEY, name VARCHAR2(20) CONSTRAINT unq_name UNIQUE, contact VARCHAR2(20), faxnum VARCHAR2(14), phonenum VARCHAR2(14) The constraint unq_name identifies the name column as a unique key. This constraint ensures that no two suppliers in the table have the same name. However, the constraint does allow suppliers without names. Alternatively, you can define and enable this constraint with the table_constraint syntax: CREATE TABLE supplier ( supplierid VARCHAR2(4) CONSTRAINT pk_supplier_supplierid PRIMARY KEY, name VARCHAR2(20) contact VARCHAR2(20), Note the comma to end faxnum VARCHAR2(14), phonenum column phonenum VARCHAR2(14), CONSTRAINT unq_name UNIQUE(name) Composite Unique Keys The example for unique key given above has only one attribute. In Oracle, we can define composite unique key with a maximum of 16 attributes. No two rows with the exactly the same set of values for the attributes cannot be input with this composite unique constraints. Composite unique key must be a table constraint rather than a column-level constraint. Example 4 The following example below is shown to demonstrate how to define composite unique key. Here custname and phonenum must be unique (that is, no two records must have exactly the same combination of values for these two attributes). 4
CREATE TABLE customer ( custid NUMBER(6) CONSTRAINT pk_customer_custid PRIMARY KEY, custname VARCHAR2(15) phonenum VARCHAR2(20), contact VARCHAR2(25), company VARCHAR2(25), faxnum VARCHAR2(20), password VARCHAR2(20), CONSTRAINT unq_custname UNIQUE (custname, phonenum) Referential Integrity Constraints Consider the following Category and Model tables: Category (categoryid, categoryname) CREATE TABLE category ( categoryid VARCHAR2(4) CONSTRAINT pk_category_categoryid PRIMARY KEY, categoryname VARCHAR2(20) Model (modelid, name, description) CREATE TABLE model ( modelid VARCHAR2(4) CONSTRAINT pk_model_modelid PRIMARY KEY, name VARCHAR2(20), description VARCHAR2(40) Let us define a part table with the following attributes: Part (partid, name, description, qtyonhand, reorderlevel, categoryid) Here categoryid of Part table references categoryid in Category table. CREATE TABLE part ( partid VARCHAR2(4) CONSTRAINT pk_part_partid PRIMARY KEY, name VARCHAR2(30), Note the missing data type description VARCHAR2(30), definition. The data type is inherited qtyonhand NUMBER(3), from the category table. reorderlevel NUMBER(3), categoryid CONSTRAINT fk_part_categoryid REFERENCES Category(categoryid) ON DELETE CASCADE 5
In the part table definition, the last attribute categoryid references Category table with cascade referential integrity on delete. Please note the Foreign Key is not explicitly defined on categoryid since REFERENCES automatically infers foreign key (assuming that categoryid is defined as a primary key or unique key already. You cannot define part table first and then the category table). The attribute name categoryid in the two tables need not match. However, the data type should match. In order to avoid non-matching attributes, the data type definition can be ignored in the referencing table (i.e., part table). The implicit referencing inherits the data type in the part table! Also, the foreign key is defined as a column constraint rather than table constraint. The example below provides a table-level constraint: Madeof (modelid, partid, qty) CREATE TABLE madeof ( modelid, partid, qty NUMBER(3), CONSTRAINT fk_madeof_modelid FOREIGN KEY (modelid) REFERENCES model (modelid) ON DELETE CASCADE, CONSTRAINT fk_madeof_partid FOREIGN KEY (partid) REFERENCES part (partid) ON DELETE CASCADE Here again, we ignore to define the data type for modelid and partid attributes. These are inherited by defining the FOREIGN KEY explicitly as table constraints. Whenever there is more than one attribute in the FOREIGN KEY definition then it must be defined as a table-level constraint. Summary CONSTRAINT fk_somename FOREIGN KEY (attributename1, attributename2,..) REFERENCES tablename (attributename1, attributename2, ) ON.. Primary Key and Foreign Key definition without Constraint: Typically defined after defining all the attributes (/* */ implies comments) PRIMARY KEY (attributename) /* when only one attribute is involved */ PRIMARY KEY (attributename1, attributename2, ) /* with many attributes */ FOREIGN KEY (attributename) REFERENCES tablename (attributename) ON DELETE {or UPDATE} CASCADE {or RESTRICT} FOREIGN KEY (attributename1, attributename2,..) REFERENCES tablename (attributename1, attributename2,.) ON DELETE {OR UPDATE} CASCADE {or RESTRICT} 6
Column-level Constraint: Only when the constraint involves ONE attribute. For instance, primary key or unique key consists of only ONE attribute. This CONSTRAINT definition immediately after the data type definition of a column (there is no comma between the data type and the constraint definition) CONSTRAINT pk_somename PRIMARY KEY CONSTRAINT unq_somename UNIQUE CONSTRAINT fk_somename REFERENCES tablename (attributename) ON. Table-level Constraint: Required when there are more than one attribute in the primary key or unique key (composite primary or unique key). CONSTRAINT pk_somename PRIMARY KEY (attributename1, attributename2,..) CONSTRAINT unq_somename UNIQUE (attributename1, attributename2,..) CONSTRAINT fk_somename FOREIGN KEY (attributename1, attributename2,..) REFERENCES tablename (attributename1, attributename2,..) ON.. 7
Other Integrity Constraints Oracle and other database vendors provide explicit constraints that can be defined on an attribute value. The constraint can refer to values within a given list of values, check against values in another attribute, or verify certain conditions on the attribute value. This value checking is done in Oracle using CHECK constraints. A few examples are given below. A CHECK constraints can be defined using various built-in functions. Readers can refer to Oracle use guide for an exhaustive list of builtin functions. Example 5: Orders (orderid, custid, orderdate, ordertype, modelid, delivdate, qty, advance, ccnum, cctype, priceunit, orderstatus) The following statement creates the P_ORDERS table and defines a CHECK constraint in each of the table s columns: CREATE TABLE Orders ( orderid NUMBER(3) CONSTRAINT pk_order_orderid PRIMARY KEY, custid CONSTRAINT fk_order_custid REFERENCES customer(custid) ON DELETE CASCADE, orderdate DATE DEFAULT SYSDATE, ordertype VARCHAR2(1) DEFAULT 'I' CONSTRAINT check_type CHECK (ordertype IN ('I','O')), modelid CONSTRAINT fk_order_modelid REFERENCES model(modelid) ON DELETE CASCADE, delivdate DATE, qty NUMBER(3), advance NUMBER(6,2), ccnum NUMBER(20), cctype VARCHAR2(3), priceunit NUMBER(4,2), orderstatus VARCHAR2(1) DEFAULT 'I' CONSTRAINT check_status CHECK (orderstatus IN ('I','D')) /* I means In progress D means Delivered */ Each constraint restricts the values of the column in which it is defined: CHECK_TYPE restricts the check type to either a inquiry or a order. CHECK_STATUS ensures that the status is either in progress or delivered. /* I means Inquiry O means Order */ 8