A database is a reposi tory designed for organizing and accessing information. For simple data, management is easy. For example, a grocery list may be written on scratch paper, and contact information may be kept in an address book. Both the scratch paper and address book are examples of databases.

:Te~d'

Name ff#~' "~#d~Jn#

Business address / ~ "Pi~C ~'~

City "PQI'['d# State ~ Zip ;?'~:?~?

Address

Home phone:

Work phone: ( ~ / 3 / 2 ~ " ? ~ " ~ ~ '

Fax:

Mobile:,,, (_ ~/5/,~ ~"?.~--~f'/? ~

Chapter 1: Databasics m

Basic lists may work for very simple da tabases . However, the l imita t ions of this approach can make even s imple tasks difficult. Let's look at our address book example again. One problem is that it has space for informat ion we don' t know/need (e.g., home address) , whereas it does not have space for informat ion we need to know (e.g., pager number) . Searching presen ts another problem. An address book is typical ly o rgan ized a lphabet ical ly by name. What if we want to search using some other criteria? Finding all of our fr iends who live in a par t icular city requires an exhaust ive search. Data en t ry and main tenance can also be problemat ic . Paper-based address books are fine for a small set of people; however, it would be very t ime-consuming to add all of the people in your com- pany. Keeping up with the changes quickly becomes unmanageab le . Another p rob lem is relat ing our paper -based address book with other da tabases . If we wanted to call all of the individuals on our softball team, we would need to combine the informat ion f rom our team roster with our address book. Clearly, addi t ional complexi ty makes it harder and harder to effectively represen t the various data re la t ionships . Likewise, as the vo lume of data increases, the complexi ty of managing and query ing informat ion grows.

Lucky for us, compu te r s are especial ly adep t at managing and quickly access ing infor- mation. Software des igned to store, manipula te , and retr ieve data in a da tabase is called a Database management system (DBMS). Here, we focus exclusively on a specific (and by far the most common) type of DBMS, the relational DBMS. There are many relational DBMSs (see the book Web site for poin ters to some examples). Fortunately, relational DBMSs speak a c o m m o n language called SQL. Using SQL, we can define, manipula te , and query our data. SQL is correct ly p ronounced as S-Q-L; however, many people also pronounce it see-kwel.

This text is based on the ANSI 2003 SQL s tandard . NOTE: Each DBMS does things dif- ferently, and no major DBMS follows the specification exactly. The specifics of a par t icular DBMS can be found in its documenta t ion . There are many reasons a DBMS may vary from the s tandard, including per formance , legacy, or market ing. Fortunately, the basic syntax of SQL is the same for all DBMS. See the book Web site for informat ion on DBMS-specific syntax.

SQL is divided into three major parts. Data manipulation language (DML) is used to store and retr ieve data from the database. The major i ty of this book is on SQL DML, and that will be the part of SQL used by the mos t people. Data description language (DDL) is used to define the s t ruc ture of the data. Chapters 9 and 10 cover the basics in SQL DDL. Data control language (DCL) is used to restr ict access to data by certain users. We in t roduce DCL in Chapter 12.

We as sume that you have a DBMS already instal led and are able to enter SQL com- mands . Consult your DBMS documen ta t ion for ins t ruc t ions on how to do this. If you do not have a DBMS, consider downloading one from the Internet . There are some free rela- t ional da tabases , and several commercia l DBMSs provide a free version of their p roduc t for exper imenta t ion . See the book Web site for sugges t ions of DBMSs.

The best way to unde r s t and how a relat ional da tabase works is to consider a spe- cific applicat ion. Imagine that you are the proud owner of a res tauran t named Garden Variety Salads. You need to manage informat ion about a var ie ty of real-world ent i t ies to run your es tab l i shment . For example, you need to main ta in a list of food i tems so your cus tomers will have someth ing to purchase. Each food i tem is made from one or more

" 1.1 Tables 3

different ingredients , such as lettuce, tomatoes , and so on. You also want to track how much each ingredient costs so you can de termine how much to charge and how much profit you're making. If you don' t want to grow the ingredients yourself , you should keep a list of vendors .

Let's look at represent ing this informat ion in a relational database called the Restaurant Database. Our design is contr ived solely for the purpose of teaching SQL, not database design. Proper database design is a difficult problem, well beyond the scope of this text. Most in t roduc tory database texts address design.

I . 1 T a b l e s

In the relational model, a database contains a set of tables. A table is made up of rows and columns. Each table has a name, which is unique within the database. Each column has a name and a data type. We discuss data types in the next section. The name of a column need only be unique within a table so other tables in the same database can have co lumns of the same name. Each row const i tu tes one record in the table. A table may contain zero or more rows. A row is subdivided into fields, one per column. Tables may be used to model real-world objects and relat ionships.

Let's look at an example table. In our Restaurant Database, we record informat ion about the suppl iers of our ingredients in a table named vendors.

Each row in the vendors table records informat ion about a part icular vendor. For example, the row with a vendorid of VGRUS is a record represent ing the vendor named Veggies_R_Us. The a t t r ibutes that we wish to record for each vendor are represen ted by the five co lumns of the vendors table: a unique vendor identifier (vendorid), the name of the vendor (companyname), the first and last name of the vendor representa t ive (repfname and replname), and an identifier for the vendor (referredby) who r ecommended this vendor .

Not everybody uses the same terminology. A table may also be called a relation. Technically, a table and a relation are not exactly the same thing. Unlike a table, a relat ion

4 Chapter 1: Databasics m

cannot contain dupl icate rows. A row is somet imes called a tuple. Finally, a co lumn may also be called an attribute of the relation. A table may be r ep resen ted by its name fol lowed by a comma-de l imi ted list of columns:

vendors(vendorid, companyname , repfname, replname, referredby)

We refer to individual co lumns of a table using the tablename.columnname nota t ion (e.g., vendors, vendorid).

1.2 Data Types

Every column has a declared data type, which specifies what kind (e.g., characters , num- bers, t ime, etc.) of informat ion may be conta ined in the column. Your DBMS may not suppor t all of these types, and it may have some addi t ional types as well. Consul t your DBMS documen ta t ion for details. We divide the SQL data types into five categories: character string, numeric , temporal , binary, and boolean.

1.2.1 Character String

Attr ibutes such as names and addresses are typical ly r ep resen ted by str ings of charac te rs (e.g., 'Bob Smith'). There are many database types for charac ter str ings. The mos t c o m m o n are as follows:

CHARACTER[ (L)~! specifies a fixed-length character s tr ing conta ining exactly L characters . If the length is not specified, SQL uses a length of 1. If the str ing contains fewer than L characters , the remaining characters contain padding charac ters (usually spaces). CHARACTER may be abbrevia ted as CHAR.

CHARACTER VARYING(L) specifies a var iable- length charac ter s tr ing that may hold up to L characters . Only the specified characters are s tored so there is no padding. CHARACTER VARYING may be abbrevia ted as CHAR VARYING or, mos t often, VARCHAR.

String literals are enclosed in single quotes (e.g., 'Bob'). A single quote within a literal is indicated by two single quotes (e.g., 'Bob"s Car').

The inclusion of trailing spaces is the pr imary difference be tween CHAR and VARCHAR. For example, vendorid is defined as CHAR(5) and repfname is defined as VARCHAR(20). Assume we add a row such as the following:

to vendors. Because vendorid is CHAR(5), two extra spaces are s tored. However, repfname is VARCHAR(20), so no extra spaces are added. This also makes a difference when we retr ieve data from the database . The vendorid 'BOBuu' will match 'BOB' or 'B0guu ' , but the repfname 'Bob' will not match 'Bobuu ' .

a 1.2 Data Types 5

The default character set for your DBMS may be limited in the kinds of characters it can represent. For example, if your DBMS uses the ASCII (American Standard Code for Infor- mation Interchange) character encoding, it can only represent English characters. Unfor- tunately, this doesn ' t work well for internationalization. The national character string type can represent internationalized character sets such as Unicode. The fixed-length national character string type is NATIONAL CHARACTER (abbreviated NATIONAL CHAR or NCHAR). The variable-length national character string type is NATIONAL CHARACTER VARYING (abbreviated NATIONAL CHAR VARYING or NCHAR VARYING). String literals for NATIONAL CHARACTER types are prefixed with an N (e.g., N'Bob').

Most DBMSs place an upper limit on the size of a character string. To store large strings, SQL provides the CHARACTER LARGE OBJECT data type (abbreviated as CHAR LARGE OBJECT or CLOB). SQL allows the use of the national character string encoding with NATIONAL CHARACTER LARGE OBJECT (abbreviated NCHAR LARGE OBJECT or NCLOB).

1.2.2 Numer ic

SQL includes several different types to store numeric information, such as age and salary. In specifying a numeric type, we need to consider three questions: 1) Are our data limited to whole numbers, 2) What range of values do we wish to support , and 3) How much control do we need over precision?

INTEGER, SMALLINT, and BIGINT--INTEGER, SMALLINT, and BIGINT store signed whole numbers. The range of possible values is DBMS dependent; however, the range of values for SMALLINT is less than or equal to the range of value for INTEGER, which is less than or equal to the range of values for BIGINT. INTEGER may be abbreviated as INT.

NUMERIC[(P [, S])] and DECIMAL[(P [, S])]--NUMERIC(P, S) specifies a signed, fixed- point number where P (precision) specifies the total number (to the left and right of the decimal) of digits in the number and S (scale) specifies the number of digits to the right of the decimal place. For example, NUMERIC(5, 2) specifies a type ranging from -999 .99 to 999.99. DECIMAL(P, S) is the same as NUMERIC(P, S) except that the actual precision may exceed the specification. For both NUMERIC and DECIMAL, if P or S are not specified, default values will be used. DECIMAL may be abbreviated as DEC.

REAL and DOUBLE PRECISION~REAL specifies a signed, single-precision, floating-point number. The range is DBMS specific. DOUBLE PRECISION is the same as REAL except it supports a greater range of values.

FLOAT[(P)I~FLOAT(P) specifies a signed, floating-point number with a precision of at least P. Here P specifies the number of binary digits.

Numeric literals look like you would expect. For REAL, DOUBLE, and FLOAT, literals may be written in exponential notation as nEp representing n x 10P where n is a signed, floating- point number and p is a signed, whole number (e.g., 7.4E-3).

6 Chapter 1: Databasics �9

If you try to use a n u m b e r with an absolute value that is too large for the data type, the da tabase should generate an except ion. For example, an except ion would be raised if we tr ied to put - 1 0 0 0 into a NUMERIC(5,2) field. If you use a n u m b e r with too many digits to the right of the decimal point, the DBMS may ei ther t runcate or round the value. So, placing 0.0001 into a NUMERIC(5,2) field resul ts in a value of 0.00. A number with fewer digits than the limit of the data type can be placed into a co lumn wi thout except ion or change. For example, 9.9 fits in a NUMERIC(5,2) field.

1.2.3 Tempora l

SQL provides several data types specific to s tor ing informat ion about t empora l infor- mat ion. Represent ing and ut i l iz ing data and t ime informat ion can be compl ica ted with cons idera t ions of t ime zone, dayl ight savings time, and so on. As a result , t empora l data tend to be more DBMS specific than other types. If the syntax p resen ted here does not work on your database , check your DBMS documenta t ion . SQL divides its tempora l types into two categories: da te t ime and interval. We begin by looking at the date and t ime types in SQL.

Datetime Datetime types store date, time information, or both.

i

Type Stores Literal

DATE

TIME

TIMESTAMP

year, month, day hour, minute, and second year, month, day, hour,

minute, and second

DATE 'YYYY-MM-DD' TIME 'HH:MM:SS' TIMESTAMP 'YYYY-MM-DD HH:MM:SS'

Seconds may contain fractional values (e.g., 32.456 seconds). An opt ional precis ion for fractional seconds may be given for TIME and TIMESTAMP. TIME and TIMESTAMP may include t ime zone information. Consul t your DBMS documen ta t i on for details on WITH TIMEZONE.

Use DATE for co lumns where you do not care about the t ime of an event, only the specific day (e.g., bir thday). Use TIME type where you do not care about the date, only the specific time. An example is the t ime of a college class, which might be at 8 AM on Tuesday and Thursday for a semester . TIMESTAMP covers the o ther cases. An example of a TIMESTAMP might be the t ime when an order is placed. In this case, we want to know both the date and the time.

Interval In addi t ion to dates and t imes, SQL can represen t t ime intervals. Such a data type might be useful for represent ing concepts such as a war ran ty period (e.g., 90 days). Interval data

m 1.2 Data Types 7

types come in two flavors:

Y e a r - M o n t h m l n t e r v a l expressed in years a n d / o r months . A Year-Month interval data type can be INTERVAL YEAR, INTERVAL MONTH, or INTERVAL YEAR TO MONTH.

Day-T ime- - In t e rva l expressed in days, hours, minutes , a n d / o r seconds. A Day-Time interval data type is of the following form:

INTERVAL <start interval value> [TO <stop interval value> ]

where the possible interval values are DAY, HOUR, MINUTE, and SECOND. If the optional <stop interval value> is specified, it mus t be an interval with a smaller granular i ty than the <start interval value>. For example, if the <start interval value> is HOUR, the only valid values for the <stop interval value> are MINUTE and SECOND.

Creating an interval literal is a two-step process. First, de te rmine the interval type (e.g., DAY TO MINUTE). Second, place an interval literal s tr ing between INTERVAL and the interval value range specification. Here are some example interval literals:

Type Example Literal Description

Year-Month INTERVAL '5' YEAR INTERVAL '2' MONTH INTERVAL '3-1' YEAR TO MONTH

5 years 2 months 3 years and 1 month

Day-Time INTERVAL '5 10:30:22.5' DAY TO SECOND

INTERVAL '-5' DAY INTERVAL '2 18:00' DAY TO MINUTE

5 days, 10 hours, 30 minutes, and 22.5 seconds

5 days ago 2 days and 18 minutes

1.2.4 Binary

Although everyth ing on the compute r is u l t imate ly s tored as binary data, SQL binary data types are des igned to store sequences of binary digits. Binary types differ f rom charac- ter str ing and numeric types in that they are more l imited in the allowable compar i sons , searches, and other funct ions. Common uses for binary types include s torage of multi- media, such as photographs , sounds, and movies, and storage of scanned images, as in a documen t imaging and retrieval sys tem.

BIT[(L)] specifies a fixed-length binary str ing conta ining exactly L bits. If the length, L, is not specified, SQL uses a length of 1. The behavior for a t t empt ing to inser t fewer than L bits is sys tem specific. Some sys t ems will reject the inser t ion a t tempt ; others will pad with zeros.

BIT VARYING(L) specifies a var iable- length binary str ing that may hold up to L bits.

8 Chapter 1: Databasics m

BINARY LARGE OBJECT[(L)] specifies a large, variable-length binary string that may hold up to L bytes. If the length, L, is not specified, the system default length is used. BINARY LARGE OBJECT may be abbreviated as BLOB.

BIT and BIT VARYING literals may be wri t ten ei ther in binary fo rm- -a single quote enclosed sequence of Os and l s prefixed with a B (e.g., B'101 lO')--or hexadecimal f o r m m a single quote enclosed sequence of hexadecimal digits prefix with an X (e.g., X'3AF'). Note that the 2003 SQL specification drops both BIT and BIT VARYING so sys t ems suppor t ing these types may exclude them in future releases.

1.2.5 Boolean

Truth gets a category all its own in SQL with the BOOLEAN data type. The BOOLEAN data type has three possible values: true, false, and unknown. The unknown value may sur- prise those familiar with boolean types in mos t p rog ramming languages. We discuss the unknown value in Section 2.8. BOOLEAN literals are (surprise) TRUE, FALSE, and UNKNOWN. The BOOLEAN type is not widely suppor ted , but it is hoped that it will be in the near future.

1.2.6 Other Data Types

Most DBMSs include a slew of cus tom data types (e.g., money, network, geometric). Using such data types is convenient but may limit portabil i ty. Note that not all SQL s tandard data types are suppor ted by every DBMS. Consult your DBMS documen ta t i on for a list of suppor ted types.

1.3 NULL

What if a par t icular a t t r ibute for a row isn't known? A value may be unknown because there is no applicable value, the value is current ly missing, or the value is purposefu l ly omit ted . Let's look more carefully at the referredby column in the vendors table. For each vendor , this field contains the identifier of the r ecommend ing vendor . Flavorful Creams was r e c o m m e n d e d to you by Veggies_R_Us so the referredby field of the row in vendors for Flavorful Creams contains the value VGRUS. What value should referredby contain for a vendor wi thout a r ecommenda t ion? We could try to pick a special identifier value to indicate that the referredby identifier is not valid (say, XXXXX); however, we would need to ensure that this identifier could never be a valid vendor identifier. Also, any appl icat ion using this da tabase would have to know about this special identifier and enforce its special meaning.

To avoid these difficulties, relat ional da tabases provide a special value, called NULL, indicat ing that a field's value is unknown. In the vendors table, referredby is NULL for all vendors where we do not have a r ecommend ing vendor . Unless explicit ly forbidden, NULL is a valid value for a column of any data type. For example, NULL is a valid value for a column of type NUMERIC. This means that NULL can be a valid value in a column

�9 1.5 Table Relationships 9

of type FLOAT. NULLs are a st icky subject , and how they are handled may not always be obvious. We address the special s ta tus of NULLs whenever applicable.

1.4 Primary Key

The primary key of a table is a column or set of co lumns whose values uniquely ident i fy a row. Using the values of the p r imary key, we can refer to a specific row in a table. In the vendors table, each vendor has a unique identifier, vendorid, which we use as the p r imary key. If we declare a p r imary key on a table, the DBMS will enforce the following rules:

�9 The value of a p r imary key for a par t icular row mus t be unique.

�9 None of the pr imary key column values can be NULL.

Why is a p r imary key so impor tant? Suppose we did not have this unique ident i ty and we wanted to change the company name for a representa t ive named Bob Snitch. If there are mult iple represen ta t ives with this name, we have no way of knowing which Snitch is which. By having a p r imary key like vendorid, we can tell our Snitches apart .

In this text, we indicate the column(s) of the pr imary key for a table with the ~ symbol. Note that a relational DBMS may allow tables to be created wi thout p r imary keys; however, good da tabase design calls for a p r imary key in vir tual ly all tables.

1.5 Table Relationships

A database typically contains several tables. Each table in a da tabase usual ly has one or more re la t ionships to other tables in the database . In addi t ion to the vendors table, your res taurant appl icat ion has a separate table of ingredients:

ingredients

I 0 Chapter 1: Databasics �9

Each ingredient used in your r e s t au ran t has a row in the ingredients table, and each ingre- dient can be uniquely identified by its ingredientid, the p r imary key of ingredients. Each row in ingredients also contains the identifier of the vendor that suppl ies it. The vendorid in ingredients connects each row with the cor respond ing row in the vendors table. Note that having co lumns with the same name in different tables doesn ' t confuse SQL (e.g., vendorid in both vendors and ingredients). SQL does not require that related co lumns be named the same, nor do co lumns named the same have to be related.

1.5.1 Foreign Key A foreign key is a column or set of co lumns in a table that refers to a co lumn or set of col- umns in some (possibly the same) table. In the Restaurant Database, ingredients.vendorid is a foreign key referencing vendors.vendorid. Consider the table excerpts in Figure 1.1. The Grape ingredient has a vendorid of FRTFR, which refers to the vendor identifier for "Fruit Eating" Friends. Veggies_R_Us provides two of the ingredients in the figure example.

A foreign key depends on the row it is referencing in another table for comple teness . In the ingredients table, a vendorid at t r ibute value makes little sense wi thout a corre- sponding row in the vendors table. For example, the vendorid for Cheese in ingredients is DNDRY, which has little meaning unless we can find out informat ion about the vendor with that identifier. The table conta ining the foreign key is called the child table, and the table containing the at tr ibute(s) it references is called the parent table. The at t r ibute(s) values referenced in the parent table are required to be unique. Usually, these referenced a t t r ibu tes are the pr imary keys of the parent table, but this is not a requi rement . A foreign key (or referential) integrity constraint requires that any foreign key value in a child table mus t have one of the following character is t ics :

�9 Have a matching value in the parent table OR

�9 Be NULL

Figure 1.1- Foreign keys.

-, 1.5 Table Relationships 1 I

Consider the tables in Figure 1.1. If we try to acid a row for the ingredient eggplant with a vendor identifier of FAKVD, the DBMS will not allow the addition because the vendorid value FAKVD does not exist in the vendors table. Note that several rows in the child (ingredients) table may" reference the same row in the parent (vendors) table.

If a foreign key is declared, the DBMS will enforce the foreign key integrity constraint by never allowing the existence of a violating row in the child table. Like the primary key, a foreign key may have multiple attributes. Foreign keys can even refer to attr ibutes in the same table. For example, vendors.referredby is a foreign key to vendors.vendorid (see Figure 1.1). Here the DBMS will not allow a row containing a value for referredby that does not already exist in the vendorid column of vendors.

1.5.2 Relationship Types There are three basic types of relationships between tables: one-to-many, many-to-many, and one-to-one.

One-to-Many In a one-to-many relationship between tables T1 and T2, each row from TI relates to zero or more rows in T2, and each row in T2 relates to at most one row in T1. To model this relationship, T2 will have a foreign key referencing attributes in T1. For the Restau- rant Database, the relationship between vendors and ingredients is one-to-many. Each vendor can supply many different ingredients; however, an ingredient may be supplied by at most one vendor. Figure 1.2 shows the one-to-many relationship between vendors

Figure 1.2: One-to-many relationship between vendors and ingredients.

| ~ Chapter 1: Databasics m

and ingredients. Each row from ingredients contains the identifier of the supply ing vendor (or NULL). A part icular vendor identifier can show up in mult iple ingredient rows. For example, you get cheese from the vendor with identifier DNDRY. Looking up DNDRY in the vendors table, we see the name of the cheese vendor is Don's Dairy. To find the ingre- dients provided by Veggies_R_Us, first look up its vendor identifier in the vendors table (i.e., VGRUS) and then look up the ingredients for that vendor identifier in the ingredients table. We make the vendorid at t r ibute in ingredients a foreign key to the vendorid at t r ibute in vendors to enforce this relat ionship.

A vendor can exist wi thout providing any ingredients . Such a vendor will have a row in the vendors table but no matching rows in the ingredients table. In the vendors table, the Flavorful Creams vendor does not provide any ingredients . Conversely, an ingredient may exist wi thout a vendor. In this case, the vendorid at t r ibute in the ingredients table will be NULL. Your Secret Dressing ingredient doesn ' t have a vendor because you make it yourself .

The vendors table also part ic ipates in a one- to-many relat ionship with itself. A vendor may recommend many other vendors; however, a vendor may be r e c o m m e n d e d by at most one vendor. To represent this one- to-many relat ionship, vendors.referredby is a foreign key that references vendors.vendorid.

Many-to-Many

In a many-to-many relationship between tables T1 and T2, each row from T1 relates to zero or more rows in T2, and each row in T2 relates to zero or more rows in T1. To make money, you need some food items to sell to cus tomers . To represent this, our Restaurant Database contains a table of items. Each item is made from many ingredients , and each ingredient can be used in many items. Consequent ly , we have a many-to-many relationship between i tems and ingredients . Let's first look at the items table.

Each item has an item identifier, itemid, the pr imary key for the items table. Each item also has a full name, a menu price, and the date the item was added to the menu. To express

�9 1.5 Table Relationships |

the many-to-many relationship, we need some way to match items to ingredients and vice versa. To do this, we create a new table, called a madewith table, that pairs ingredients with items.

For each ingredient in an item, the madewith table has a row containing the corre- sponding item and ingredient identifiers. A table like madewith that links rows from one table to another is called a join table. Figure 1.3 shows the many-to-many relationship between ingredients and items. The Chicken Salad item has 4 ingredients, represented by 4 rows in madewith with an itemid of CHKSD. The Cheese ingredient is used in two items, represented by 2 rows in madewith with an ingredientid of CHESE.

You can see that the relational model doesn' t have explicit many-to-many relation- ships. It implements a many-to-many relationship using 2 one-to-many relationships. To record how much of each ingredient to include in an item, we add a quantity attribute. For example, each fruit salad has 10 grapes and 5 watermelon cubes.

The primary key for madewith consists of two attributes: itemid and ingre- dientid. As you might suspect, madewith.ingredientid is a foreign key referencing ingredients.ingredientid, and madewith.itemid is a foreign key referencing items.itemid. Given these primary and foreign keys, the DBMS will enforce the following constraints for the madewith table:

�9 Every itemid, ingredientid pair in a madewith must be unique (primary key).

�9 Neither the itemid nor the ingredientid column may contain NULL (primary key).

�9 Any itemid/ingredientid value must already exist in the item/ingredient table (foreign key).

| 4 Chapter 1: Databasics u

Figure 1.3: Many-to-many relationship between ingredients and items.

One-to-One Usually, one-to-one re la t ionships are represented by a t t r ibutes within a single table. That is, all of the a t t r ibutes of a table exhibit a natural one-to-one relat ionship. In the vendors table, a row relates one vendor identifier to one company name to one representa t ive .

In a one-to-one relat ionship between tables T1 and T2, each row from T1 relates to at mos t one row in T2 and vice versa. In reality, a one-to-one relat ionship between tables is often jus t a special case of a one- to-many relat ionship.

1.5.3 Schemas

The collection of tables and other data descr ip t ion objects in a database is called the schema. We populate the database by adding data to the tables in the schema. Note that the schema does not include the data but only the descr ipt ion of the data. Whereas we expect the data to change often (with every insert, update, and delete), the schema of a database should change infrequently.

" 1.6 Restaurant Database I 5

Figure 1.4: Schema for the Restaurant Database.

1.6 Restaurant Database

We presen t the s c h e m a and data for our sample Res tau ran t Database . Figure 1.4 gives an overview of the Res tauran t Database by showing the tables and re la t ionsh ips . This sec t ion will be useful as a re fe rence so note where it is. To help find it again, this par t i cu la r page is 2 mic rons 1 taller and wider than all of the o ther pages, which should make it s t ick out.

v e n d o r s - - V e n d o r s who supp ly ing red ien t s for the r e s t au ran t .

Column Type Description

vendorid~ CHAR(5) companyname VARCHAR(30) repfname VARCHAR(20) replname VARCHAR(20)

re ferredby ~ CHAR( 5 )

Unique vendor identifier Vendor company name Vendor representative first name Vendor representative last name

Identifier of vendor that referred this vendor to you. Foreign key referencing vendors.vendorid

II

1 Because of variations in the publishing process, page widths may vary up to 125 microns.

| 6 Chapter 1" Databasics []

vendors

i n g r e d i e n t s - - l n g r e d i e n t s provided by vendors for use in i tems. i

Column Type Description

ingredientid CHAR(5) name VARCHAR(30) unit CHAR(10) unitprice NUMERIC(5,2) foodgroup CHAR(15) inventory INTEGER vendorid CHAR(5)

Unique ingredient identifier Ingredient name Ingredient serving size Cost of an ingredient serving Ingredient food group Number of available ingredient servings Identifier of vendor supplying ingredient. Foreign key

referencing vendors, vendorid i

n 1.6 Restaurant Database | 7

i t e m s m B a s i c i t ems for sale to c u s t o m e r s . nnnnl I

Column Type Description

itemid~ ~ CHAR(5) Unique item identifier name VARCHAR(30) Item name price NUMERIC(5,2) Item price dateadded DATE Date item added to menu

I

i tems

m a d e w i t h ~ I t e m ingredients" Join table for the m a n y - t o - m a n y r e l a t i onsh ip b e t w e e n ingredients and items.

I I I I IIII I l l II I II I

Column Type Description

itemid CHAR(5)

ingredientid CHAR(5)

quantity INTEGER m l Ill

madewith

Identifier of item that uses the ingredient. Foreign key referencing items.itemid.

Identifier of ingredient used in the item. Foreign key referencing ingredients, ingredientid.

Number of units of specified ingredient to use in item.

Continued on next page

| 8 Chapter 1" Databasics n

madewith (cont'd)

m e a l s ~ A meal is a co l lec t ion of i tems. To ent ice c u s t o m e r s to buy more food, you c o m b i n e i t ems t o g e t h e r into a meal and sell it at a d i s coun t . For example , ou r Chicken N Suds meal c o m b i n e s a ch icken sa lad wi th a soda .

Column Type Description

mealid CHAR(5 ) Unique meal identifier name CHAR(10) Meal name

meals

p a r t o f D M e a l i tems: Join table for the m a n y - t o - m a n y r e l a t i onsh ip b e t w e e n meal s and i tems.

i lu i i i i iiiii IlmlmllHHIII I I I I II II III I I IIIIHIm HI I INIIlUl II IIIIH IIIIIH I IIII IIIIIIII

Column Type Description

mealid CHAR(5)

itemid CHAR(5)

quantity INTEGER discoun t DECIMAL( 2,2 )

Identifier of meal that includes the item. Foreign key referencing meals.mealid.

Identifier of item to be used in the meal. Foreign key referencing items.itemid.

Number of specified items to use in meal. Percentage discount for item when part of this meal. To compute

the price of a meal, sum the discounted individual price of all items. For example, Chicken N Suds meal costs

2 .85 * 98% + 0 . 9 9 * 90% = 3 .68 . i iiiiii iii i iiiiiiiii iii ii iiiii iiiiiiiii

m 1.6 Restaurant Database | 9

a d s m P o s s i b l e a d v e r t i s i n g s logans for the r e s t au ran t . i

Column Type Description

slogan CHAR(50) Advertising slogan

m e n u i t e m s - - C o m b i n a t i o n of bo th mea l s and i t ems to go on the r e s t a u r a n t menu . We i m p l e m e n t menu i t ems as a view (see Chap te r 10).

i

Column Type Description

menuitemid~ CHAR(5) Item or meal identifier name VARCHAR(30) Menu item name price NUMERIC(5 ,2) Item price

i ii i l i l l i i i i

s toresmStores f r anch i sed ac ross the count ry . i i

Column Type Description

storeid~ CHAR(5) street VARCHAR(2 5) city VARCHAR(2 5) state CHAR(2) zip CHAR(10) operator VARCHAR(41)

Unique store identifier Street address of the store City of the store U.S. state of the store U.S. zip code in XXXXX-XXXX format Name of the operator of the store (e.g., owner or the manager)

2 0 Chapter 1" Databasics n

s tores

o r d e r s - - l n f o r m a t i o n about each order placed at every store. Each order that a cus tomer places is given a unique order number . Each i tem within an order is given a line number , which is unique within the order. The menuitemid is not declared as a foreign key to allow for future delet ion of menu items.

I

Column Type Descript ion

" 1.7 Wrap Up 2 1

orders (cont'd)

1.7 Wrap Up

Like any language, the best way to learn is to use it over and over again. The way to try SQL is to create a schema in a DBMS, load some data, and bang out some SQL. We encourage execut ing each and every SQL s t a t emen t in this book, exper iment ing with new queries, and working the exercises at the end of each chapter . Unfortunately, each DBMS is different. Even worse, how someth ing is imp lemen ted in a par t icular DBMS changes with new releases. Given this, we do not include DBMS specifics in this book; however, the book Web site includes mater ia ls on the major DBMSs, such as scripts to create and popula te the Restaurant Database.

~ Chapter 1: Databasics m

Review Questions

1. A row in a table can be uniquely identified by

2. The includes the set of tables but not the data.

3. What is the difference between the literal 'Bob' s tored as a CHAR(5) versus a VARCHAR(5)?

4. Can an at t r ibute of type INTEGER have the value NULL?

5. In the Restaurant Database, an i tem may have between and ingredients .

6. If we added a new row to vendors in the Restaurant Database with vendorid = HMFDS, give the list of all possible values for referredby.

7. In the Restaurant Database, would the DBMS allow a row in the vendors table with a vendorid of NULL? Explain.

8. Give a type and an example literal for the following data:

Data Type Literal

Weight NUMERIC(5, 2) 129.3

Street

Birthday

Contract Length

Salary

Gender i i

9. What is the difference between a database and a DBMS?

10. In the Restaurant Database, give the name of all of the ingredients in the Vegan Eatin' meal.

11. If a vendor could be r ecommended by multiple vendors , how would our res taurant schema change?

12. We must call our vendors to place new orders; unfor tunate ly , we don' t know their phone numbers . Of course, a vendor may have several phone numbers . For the res taurant schema, how would you add the number and phone type (e.g., office, home, cell, fax, etc.)? Assume that a phone number is ass igned to only one vendor.

13. For your res taurant , you need to create a table for cus tomers containing an iden- tifier, name, number of visits, and percent discount . Give the column names and data types of this table. What is the pr imary key of this new table?

m Practice 2 3

14. In the Restaurant Database, we want to add 2 more scoops of cheese to the Chicken Salad item. We could s imply increase the value of the quant i ty field in the madewith table for the row pairing Chicken Salad with cheese. Could we also jus t add another row to madewith containing the values (CHKSD, CHESE, 2)? Explain.

15. In the Restaurant Database, you have a new vendor , "Homemade Foods", that makes a single ingredient , "Homemade Bread". Give the new rows to add to the various tables to add this new informat ion and include two slices of bread in the "Chicken N Suds" meal.

16. Can any of the numeric fields have a negative value?

17. Provide an example of an a t t r ibute that would require a time interval.

18. In the Restaurant Database, can FRPLT be the name of an item?

19. Consider the ads table in the res taurant schema. Could we make slogan the pr imary key? Explain.

20. Can a table have no rows?

21. Give a data type to represent a number wi thout loss of precision that can range f r o m - 1 3 9 7 to 24892.99.

Practice

To practice SQL, we introduce a new database applicat ion. The Employees Database stores informat ion about a business, including employees , depar tments , and projects . Each employee works for one depa r tmen t and is ass igned many projects. Each depa r tmen t has many employees, has many projects, and may be a subdepa r tmen t of one depa r tmen t (e.g., Accounting is a subdepa r tmen t of Administrat ion). Each project is ass igned to one depa r tmen t and is worked on by many employees . Figure 1.5 gives the schema for the Employees Database.

e m p | o y e e s m E m p l o y e e s who work for the company.

Column Type Description

employeeid ~ NUMERIC(9) first name VARC HAR( I 0) l as tnam e VAR CHAR ( 20)

d e p t c o d e ~ CHAR(5)

salary NUMERIC(9,2) i i

Unique employee identifier Employee first name Employee last name

Identifier of department the employee works for. Foreign key referencing departments.code

Employee salary i

2 4 Chapter 1" Databasics []

Figure 1.5: Schema for the Employees Database.

d e p a r t m e n t s - - C o m p a n y depa r tmen t s .

Column Type Description

code~ name

managerid

s u b d e p t o f ~

CHAR(5) VARCHAR(30)

NUMERIC(9)

CHAR(S)

Unique department identifier Department name

Identifier of employee who manages the department. Foreign key referencing employees.employeeid

Code of department that includes this department as one of its immediate subdepartments. Foreign key referencing departments.code

�9 Practice 25

departments

code ~ name

ADH I N Administration

ACCNT Accounting

HDI~RE Hardware

CNSLT Consulting

managerid~

1 2 3 4

subdeptof~

NULL

ADMIN

CNSLT

ADMIN

pro jec t s - -Pro jec t s managed by company.

Column Type Description

projectid CHAR(8)

deptcode CHAR(5)

description VARCHAR(200) startdate DATE stopdate DATE

revenue NUMERIC( 12, 2)

Unique project identifier

Identifier of department managing this project. Foreign key referencing departments.code

Project description Project start date Project stop date. NULL value indicates that the project is

ongoing Total project revenue

projects

workson - -P ro j ec t employees" Join table for the many- to-many relat ionship between employees and departments.

ii,

Column Type Description

employeeid ~ NUMERIC(9)

projectid ~( ~ CHAR(8)

assignedtime DECIMAL(3,2)

Identifier of employee working on a project. Foreign key refer- encing employees.employeeid

Identifier of project that employee is working on. Foreign key referencing projects.projectid

Percentage of time employee is assigned to project

26 Chapter 1: Databasics m

w o r k s o n

1. What must be true about the values of projectid and deptcode in a row of the projects table?

2. Can an employee who works on no projects be in this database?

3. Can an employee work on a project that is ass igned to a depa r tmen t o ther than the one he or she works for?

4. Describe the various re la t ionships in the Employees Database. For example, employ- ees has a one- to-many relat ionship with departments because an employee works for one depa r tmen t and a depa r tmen t has many employees .

5. Which a t t r ibutes in the departments table can be NULL?

6. Which is higher, the largest possible employee ID or the highest salary?

7. For each table, give an example of a new row that could be added.

8. Can a depa r tmen t be a subdepa r tmen t of itself?. Explain.

9. Can an employee be assigned hours on a project that is not in the database? Explain.

10. Can the end date of a project precede the start date of the project?

11. Can the revenue of a project be negative?