Managing Tables |
Tables are the basic unit of data storage in an Oracle database. They hold all user-accessible data. A table is two-dimensional object comprised of columns and rows. For example the employees table includes (vertical) columns called first_name, last_name, and employee_id. Each (horizontal) row in the table contains a value for employee name and Id number. The most common type of table in an Oracle database is a relational table.
This topic contains the following topics:
|
See Also:
|
Data types are required elements that define the nature of the data to be stored in the columns of a table. Data types might include a value to indicate the longest value that can be placed in the column. When you create a table, you must specify a data type for each of its columns. For a discussion of data types, see Data Types: Usage Information.
These data types define the domain of values that each column can contain or each argument can have. For example, DATE columns cannot accept the value February 29 (except for a leap year) or the values 2 or SHOE. Each value subsequently placed in a column assumes the column data type. For example, if you insert 17-JAN-2004 into a date column, then Oracle treats the 17-JAN-2004 character string as a date value after verifying that it translates to a valid date.
|
See Also: Oracle Database SQL Reference for a complete list of Oracle's built-in data types. |
In most cases, you should only need columns of NUMBER, VARCHAR2, and DATE data types when creating a definition of a table.
When defining numeric data, you can use the precision option to set the maximum number of digits in the number, and the scale option to define how many of the digits are to the right of the decimal point. For example, a field to hold monetary values might be defined as NUMBER(12,2), providing ten digits for the primary unit of currency (dollars, pounds, marks, and so on) and two digits for the secondary unit (cents, pennies, pfennigs, and so on).
To define a VARCHAR2 field for character data, you must include the size value. Set the size to the maximum number of bytes (or, optionally, characters) to be stored in the column. A column to hold postal codes for different countries, for example, might be restricted to 12 bytes by defining it as VARCHAR2(12).
DATE columns are automatically formatted by Oracle to include a date and time component. Although both the date and time are stored in a date column, by default, the date portion is automatically displayed for you, when retrieving date data. However, Oracle Database enables you great flexibility in how you can display your dates and times.
Default values are values that are automatically stored into the column whenever a new row is inserted without a value being provided for the column. When you define a column with a default value, any new rows inserted into the table store the default value unless the row contains an alternate value for the column. Assign default values to columns that contain a typical value. For example, in the departments table, if most departments are located at one site, then the default value for the location_id column can be set to this value, such as 1700.
Default values can help avoid errors where there is a number, such as zero, that applies to a column that has no entry. For example, a default value of zero can simplify testing, by changing a test like this:
IF salary >= 0 AND salary < 50000
to the simpler form:
IF salary < 50000
Depending upon your business rules, you might use default values to represent zero or FALSE, or leave the default values as NULL to signify an unknown value.
Default values can be defined using any literal, or almost any expression including SYSDATE, which is a SQL function that returns the current date.
You can define integrity constraints to enforce business rules on data in your tables. Business rules specify conditions and relationships that must always be true, or must always be false.
When an integrity constraint applies to a table, all data in the table must conform to the corresponding rule. When you issue a SQL statement that inserts or modifies data in the table, Oracle Database ensures that the new data satisfies the integrity constraint, without the need to do any checking within your program.
You can enforce rules by defining integrity constraints more reliably than by adding logic to your application. Oracle Database can check that all the data in a table obeys an integrity constraint faster than an application can.
Some constraints can be defined at the column level or at the table level. Column level constraints are syntactically defined where the column to which the constraint applies is defined. Table level constraints are syntactically defined at the end of the table definition.
Column constraints are optional elements that determine what values are valid in the column.
The NOT NULL constraint on a column requires that the column must contain a value whenever a row is inserted or updated. Unlike other constraints described in "Table-Level Constraints", which may be defined as part of the column definition or part of the table definition, the NOT NULL constraint must be defined as part of the column definition.
Use a NOT NULL constraint when the data is required for the integrity of the database. For example, if all employees must belong to a specific department, then the column that contains the department identifier should be defined with a NOT NULL constraint. On the other hand, do not define a column as NOT NULL if the data may be unknown or may not exist when rows are added or changed, for example, the second, optional line in a mailing address.
A primary key constraint automatically adds a NOT NULL constraint to the column or columns included in the primary key, in addition to enforcing uniqueness among the values.
You can apply rules to preserve the integrity of your data. For example, in a table containing employee data, the employee email column must be unique. Similarly, in this table you cannot have two employees with the same employee Id.
Oracle Database enables you to apply data integrity rules as constraints on columns at the table level. Any attempt to insert, update, or remove a row that violates a constraint results in an error and the statement is rolled back. Likewise, any attempt to apply a new constraint to a populated table also results in an error if any existing row violates the new constraint.
The types of constraints you can apply at the table level are as follows:
Constraints can be created and, in most cases, modified with a number of different status values. The options include enabled or disabled, which determine if the constraint is checked when rows are added, modified, or removed; and deferred or immediate, which cause constraint validation to occur at the end of a transaction or at the end of a statement, respectively.
|
See Also: Oracle Database Concepts for more information on constraints. |
A primary key requires that a column (or combination of columns) be the unique identifier of the row and ensures that no duplicate rows exist. A primary key column cannot contain NULL values. Each table can have only one primary key.
Use the following guidelines when selecting a primary key:
Whenever practical, create a sequence number generator to generate unique numeric values for your primary key values.
Choose a column whose data values are unique, because the purpose of a primary key is to uniquely identify each row of the table.
Choose a column whose data values are never changed. A primary key value is only used to identify a row in the table, and its data should never be used for any other purpose. Therefore, primary key values should rarely or never be changed.
Choose a column that does not contain any nulls. A PRIMARY KEY constraint, by definition, does not allow any row to contain a null in any column that is part of the primary key.
Choose a column that is short and numeric. Short primary keys are easy to type.
Minimize your use of composite primary keys. A composite primary key constraint applies to more than one column. Although composite primary keys are allowed, they do not satisfy all of the other recommendations. For example, composite primary key values are long and cannot be assigned by sequence numbers.
A unique key requires that every value in a column be unique. That is, no two rows can have duplicate values in a specified column or combination of columns.
Choose columns for unique keys carefully. The purpose of these constraints is different from that of primary keys. Unique key constraints are appropriate for any column where duplicate values are not allowed. Primary keys identify each row of the table uniquely, and typically contain values that have no significance other than being unique. In the employees table, the email column has a unique key constraint because it is important that the emails for each employee are unique. Note that the email column has a NOT NULL constraint.
Some examples of good unique keys include:
An employee social security number where the primary key might be the employee number
A truck license plate number where the primary key might be the truck number
A customer phone number, consisting of the two columns area_code and local_phone where the primary key might be the customer number
A department name and location where the primary key might be the department number
A check constraint requires that a column (or combination of columns) satisfy a condition for every row in the table. A check constraint must be a boolean expression that is evaluated using the column value about to be inserted or updated to the row.
Use CHECK constraints when you need to enforce integrity rules based on logical expressions, such as comparisons. Never use CHECK constraints when any of the other types of integrity constraints can provide the necessary checking.
Examples of CHECK constraints include the following:
A CHECK constraint on employee salaries so that no salary value is less than 0.
A CHECK constraint on department locations so that only the locations Boston, New York, and Dallas are allowed.
A CHECK constraint on the salary and commissions columns to prevent the commission from being larger than the salary.
Whenever two tables contain one or more common columns, you can enforce the relationship between the tables through a referential integrity constraint with a foreign key. A foreign key requires that all column values in the child table exist in the parent table. The table that includes the foreign key is called the dependent or child table. The table that is referenced is called the parent table.
An example of a foreign key constraint is when the department column of the employees table (child) must contain a department ID that exists in the parent departments table.
Foreign keys can be comprised of multiple columns. Such a composite foreign key must reference a composite primary or unique key of the exact same structure, with the same number of columns and the same data types. Because composite primary and unique keys are limited to 32 columns, a composite foreign key is also limited to 32 columns. You must use the same data type for corresponding columns in the parent and child tables. The column names do not need to match.