vb.net 2d barcode dll Figure 1-1. The DEPARTMENTS table in Java

Encode Data Matrix ECC200 in Java Figure 1-1. The DEPARTMENTS table

The only way you can associate data in a relational database is by comparing column values. This principle, known as the information principle, is applied very strictly, and it is at the heart of the term relational. An important property of sets is the fact that the order of their elements is meaningless. Therefore, the order of the rows in any relational table is meaningless, too, and the order of columns is also meaningless. Because this is both very fundamental and important, let s rephrase this in another way: in a relational database, there are no pointers to represent relationships. For example, the fact that an employee works for a specific department can be derived only from the two corresponding tables by comparing column values in the two department number columns. In other words, for every retrieval command, you must explicitly specify which columns must be compared. As a consequence, the flexibility to formulate ad hoc queries in a relational database has no limits. The flip side of the coin is the risk of (mental) errors and the problem of the correctness of your results. Nearly every SQL query will return a result (as long as you don t make syntax errors), but is it really the answer to the question you had in mind

One of the tasks during data modeling is also to decide which values are allowed for each attribute. As a minimum, you could allow only numbers in a certain column, or allow only dates or text. You can impose additional restrictions, such as by allowing only positive integers or text of a certain maximum length. A set of allowed attribute values is sometimes referred to as a domain. Another common term is datatype (or just type). Each attribute is defined on a certain type. This can be a standard (built-in) type or a user-defined type.

Each relational table must have at least one candidate key. A candidate key is an attribute (or attribute combination) that uniquely identifies each row in that table, with one additional important property: as soon as you remove any attribute from this candidate key attribute combination, the property of unique identification is gone. In other words, a table cannot contain two rows with the same candidate key values at any time. For example, the attribute combination course code and start date is a candidate key for a table containing information about course offerings. If you remove the start date attribute, the remaining course code attribute is not a candidate key anymore; otherwise, you could offer courses only once. If you remove the course code attribute, the remaining start date attribute is not a candidate key anymore; otherwise, you would never be able to schedule two different courses to start on the same day. In case a table has multiple candidate keys, it is normal practice to select one of them to become the primary key. All components (attributes) of a primary key are mandatory; you must specify attribute values for all of them. Primary keys enforce a very important table constraint: entity integrity. Sometimes, the set of candidate keys doesn t offer a convenient primary key. In such cases, you may choose a surrogate key by adding a meaningless attribute with the sole purpose of being the primary key.

Note Using surrogate keys comes with advantages and disadvantages, and fierce debates between database experts. This section is intended to only explain the terminology, without offering an opinion on the use of surrogate keys.

A relational table can also have one or more foreign keys. Foreign key constraints are subset requirements; the foreign key values must always be a subset of a corresponding set of primary key values. Some typical examples of foreign key constraints are that an employee can work for only an existing department and can report to only an existing manager. Foreign keys implement referential integrity in a relational database.