Friday, August 31st, 2007
Introducing Keys As you can see in the previous example, we have purposely set up the three tables to link to one another. The EMPLOYEE table contains a column that has the department number that the employee belongs in. This department number also appears in the DEPARTMENT table, which describes each department in the company. The EMPLOYEE and CONFIDENTIAL tables are related, but we still need to add one corresponding entry (row) in one table for each entry in the other, the distinction coming from the employee s number. The link employee number and department number we have set up can be thought of as a key. A key is used to identify information within a table. Each individual employee or department should have a unique key to aid in various functions performed on the tables. In keeping with the relational model, the key is supposed to be unique within the table: No other entry in the table may have the same primary key. A single column is sometimes enough to uniquely identify a row, or entry. However, a combination of rows can be used to compose a primary key for example, we might want to just use the combination of the title and city location of a department to comprise the primary key. In SQL, columns defined as primary keys must be defined. They cannot be undefined (also known as NULL). Using Multiple Tables And Foreign Keys As we have shown, it s best to split data into tables so that the data contained within a table is logically associated. Oftentimes, the data will belong logically in more than one table, as is the case of the employee number in the EMPLOYEE and CONFIDENTIAL tables. We can further define that if a row in one table exists, a corresponding row must exist in another table; that is, we can say that if there is an entry in the EMPLOYEE table, there must be a corresponding entry in the CONFIDENTIAL table. We can solidify this association with the use of foreign keys, where a specific column in the dependent table matches a column in a parent table. In essence, we are linking a virtual column in one table to a real column in another table. In our example database, we link the CONFIDENTIAL table s employee number column to the employee number column in the EMPLOYEE table. We are also specifying that the employee number is a key in the CONFIDENTIAL table (hence the term foreign key). A composite primary key can contain a foreign key if necessary. We can create a logical structure to our data using the concept of a foreign key. However, in preparation, you ll have to put quite a bit of thought into creating your set of tables; an efficient and planned structure to the data by way of the tables and keys requires good knowledge of the data that is to be modeled. Unfortunately, a full discussion on the techniques of the subject is beyond the scope of this book. There are several different ways to efficiently model data; Figure 2.4 shows one visualization of the database we have created. The SQL queries we perform in the examples of this book are not very complex, so the information outlined in this section should suffice to convey a basic understanding of the example databases created throughout the following chapters.
With our Unix hosting accounts you have total control of your Web site content from anywhere in the world.For more information please follow link Unix Web Hosting.