Databases Demystified a self teaching guide phần 7 docx

However, unlike primary key constraints, a table may havemultiple unique constraints, and the columns in a unique constraint maycontain null values that is, they may be specified with th

Composite Default screen

This page intentionally left blank.

CHAPTER 8

Physical Database Design

As introduced in Chapter 5 in Figure 5-1, once the logical design phase of a project is

complete, it is time to move on to physical design Other members of a typical

pro-ject team will define the hardware and system software required for the application

system We will focus on the database designer’s physical design work, which is

transforming the logical database design into one or more physical database designs

In situations where an application system is being developed for internal use, it is

normal to have only one physical database design for each logical design However,

if the organization is a software vendor, for example, the application system must

run on all the various platform and RDBMS versions that the vendor’s customers

use, and that requires multiple physical designs The sections that follow cover each

of the major steps involved in physical database design

203

Designing Tables

The first step in physical database design is to map the normalized relations shown inthe logical design to tables The importance of this step should be obvious becausetables are the primary unit of storage in relational databases However, if adequatework was put into the logical design, then translation to a physical design is thatmuch easier As you work through this chapter, keep in mind that Chapter 2 contains

an introduction to each component in the physical database model, and Chapter 4contains the SQL syntax for the DML commands required to create the variousphysical database components (tables, constraints, indexes, views, and so on).Briefly, the process goes as follows:

1 Each normalized relation becomes a table A common exception to this iswhen super types and subtypes are involved, a situation we will look at inmore detail in the next section

2 Each attribute within the normalized relation becomes a column in thecorresponding table Keep in mind that the column is the smallest division

of meaningful data in the database, so columns should not have subcomponentsthat make sense by themselves For each column, the following must bespecified:

• A unique column name within the table Generally, the attribute namefrom the logical design should be adapted as closely as possible However,adjustments may be necessary to work around database reserved words and

to conform to naming conventions for the particular RDBMS being used.You may notice some column name differences between the Customerrelation and the CUSTOMER table in the example that follows The reasonfor this change is discussed in the “Naming Conventions” section later inthis chapter

• A data type, and for some data types, a length Data types vary from oneRDBMS to another, so this is why different physical designs are neededfor each RDBMS to be used

• Whether column values are required or not This takes the form of a NULL

or NOT NULL clause for each column Be careful with defaults—they canfool you For example, when this clause is not specified, Oracle assumesNULL, but Sybase and Microsoft SQL Server assume NOT NULL It’salways better to specify such things and be certain of what you are getting

• Check constraints These may be added to columns to enforce simplebusiness rules For example, a business rule requiring that the unit price on

an invoice must always be greater than or equal to zero can be implemented

Composite Default screen

with a check constraint, but a business rule requiring the unit price to belower in certain states cannot be Generally, a check constraint is limited to

a comparison of a column value with a single value, with a range or list ofvalues, or with other column values in the same row of table data

3 The unique identifier of the relation is defined as the primary key of the

table Columns participating in the primary key must be specified as NOTNULL, and in most RDBMSs, the definition of a primary key constraintcauses automatic definition of a unique index on the primary key column(s)

Foreign key columns should have a NOT NULL clause if the relationship ismandatory; otherwise, they may have a NULL clause

4 Any other sets of columns that must be unique within the table may have a

unique constraint defined As with primary key constraints, unique constraints

in most RDBMSs cause automatic definition of a unique index on the uniquecolumn(s) However, unlike primary key constraints, a table may havemultiple unique constraints, and the columns in a unique constraint maycontain null values (that is, they may be specified with the NULL clause)

5 Relationships among the normalized relations become referential constraints

in the physical design For those rare situations where the logical modelcontains a one-to-one relationship, you can implement it by placing theprimary key of one of the tables as a foreign key in the other (do this foronly one of the two tables) and placing a unique constraint on the foreignkey to prevent duplicate values For example, Figure 2-2 in Chapter 2 shows

a one-to-one relationship between Employee and Automobile, and we chose

to place EMPLOYEE_ID as a foreign key in the AUTOMOBILE table

We should also place a unique constraint on EMPLOYEE_ID in theAUTOMOBILE table so that an employee may be assigned to only oneautomobile at any point in time

6 Large tables (that is, those that exceed several gigabytes in total size) should

be partitioned if the RDBMS being used supports it Partitioning is a databasefeature that permits a table to be broken into multiple physical components,each stored in separate data files, in a manner that is transparent to thedatabase user Typical methods of breaking tables into partitions use a range

or list of values for a particular table column (called the partitioning column)

or use a randomizing method known as hashing that evenly distributes tablerows across available partitions The benefits of breaking large tables intopartitions are easier administration (particularly for backup and recoveryoperations) and improved performance, achieved when the RDBMS can run

an SQL query in parallel against all (or some of the) partitions and then

206 Databases Demystified

Demystified / Databases Demystified / Oppel/ 225364-9 / Chapter 8

combine the results Partitioning is solely a physical design issue that isnever addressed in logical designs After all, a partitioned table really isstillone table There is wide variation in the way database vendors haveimplemented partitioning in their products, so you need to consult yourRDBMS documentation for more details

7 The logical model may be for a complete database system, whereas thecurrent project may be an implementation of a subset of that entire system.When this occurs, the physical database designer will select and implementonly the subset of tables required to fulfill current needs

Here is the logical design for Acme Industries from Chapter 6:

PRODUCT: # Product Number, Product Description,

List Unit Price CUSTOMER: # Customer Number, Customer Name,

Customer Address, Customer City, Customer State, Customer Zip Code, Customer Phone

INVOICE: # Invoice Number, Customer Number, Terms,

Ship Via, Order Date INVOICE LINE ITEM: # Invoice Number, # Product Number,

Quantity, Sale Unit Price

And here is the physical table design we created from the logical design, shown

in the form of SQL DDL statements These statements are written for Oracle andrequire some modification, mostly of data types, to work on other RDBMSs:

CREATE TABLE PRODUCT (PRODUCT_NUMBER VARCHAR(10) NOT NULL, PRODUCT_DESCRIPTION VARCHAR(100) NOT NULL, LIST_UNIT_PRICE NUMBER(7,2) NOT NULL);

ALTER TABLE PRODUCT ADD CONSTRAINT PRODUCT_PK_PRODUCT_NUMBER PRIMARY KEY (PRODUCT_NUMBER);

CREATE TABLE CUSTOMER (CUSTOMER_NUMBER NUMBER(5) NOT NULL, NAME VARCHAR(25) NOT NULL, ADDRESS VARCHAR(255) NOT NULL, CITY VARCHAR(50) NOT NULL, STATE CHAR(2) NOT NULL, ZIP_CODE VARCHAR(10));

Composite Default screen

ALTER TABLE CUSTOMER ADD CONSTRAINT CUSTOMER_PK_CUST_NUMBER PRIMARY KEY (CUSTOMER_NUMBER);

CREATE TABLE INVOICE (INVOICE_NUMBER NUMBER(7) NOT NULL, CUSTOMER_NUMBER NUMBER(5) NOT NULL, TERMS VARCHAR(20) NULL, SHIP_VIA VARCHAR(30) NULL, ORDER_DATE DATE NOT NULL);

ALTER TABLE INVOICE ADD CONSTRAINT INVOICE_PK_INVOICE_NUMBER PRIMARY KEY (INVOICE_NUMBER);

ALTER TABLE INVOICE ADD CONSTRAINT INVOICE_FK_CUSTOMER_NUMBER FOREIGN KEY (CUSTOMER_NUMBER)

REFERENCES CUSTOMER (CUSTOMER_NUMBER);

CREATE TABLE INVOICE_LINE_ITEM (INVOICE_NUMBER NUMBER(7) NOT NULL, PRODUCT_NUMBER VARCHAR(10) NOT NULL, QUANTITY NUMBER(5) NOT NULL, SALE_UNIT_PRICE NUMBER(7,2) NOT NULL);

ALTER TABLE INVOICE_LINE_ITEM ADD CONSTRAINT INVOICE_LI_PK_INV_PROD_NOS PRIMARY KEY (INVOICE_NUMBER, PRODUCT_NUMBER);

ALTER TABLE INVOICE_LINE_ITEM ADD CONSTRAINT INVOICE_CK_SALE_UNIT_PRICE CHECK (SALE_UNIT_PRICE >= 0);

ALTER TABLE INVOICE_LINE_ITEM ADD CONSTRAINT INVOICE_LI_FK_INVOICE_NUMBER FOREIGN KEY (INVOICE_NUMBER)

REFERENCES INVOICE (INVOICE_NUMBER);

ALTER TABLE INVOICE_LINE_ITEM ADD CONSTRAINT INVOICE_LI_FK_PRODUCT_NUMBER FOREIGN KEY (PRODUCT_NUMBER)

REFERENCES PRODUCT (PRODUCT_NUMBER);

Implementing Super Types and Subtypes

Most data modelers tend to specify every conceivable subtype in the logical datamodel This is not really a problem because the logical design is supposed to encom-pass not only where things currently stand, but also where things are likely to end up

in the future The designer of the physical database therefore has some decisions tomake in choosing to implement or not implement the super types and subtypes de-picted in the logical model The driving motivators here should be reasonablenessand common sense These, along with input from the application designers abouttheir intended uses of the database, will lead to the best decisions

Looking back at Figure 7-6 in Chapter 7, you will recall that we ended up with twosubtypes for our Customer entity: Individual Customer and Commercial Customer.There are basically three choices for physically implementing such a logical design,and we will explore each in the subsections that follow

This design alternative is favored when there are many common attributes cated in the super type table) as well as many attributes particular to one subtype oranother (located in the subtype tables) In one sense, this design is simpler than theother alternatives because no one has to remember which attributes apply to whichsubtype On the other hand, it is also more complicated to use because the databaseuser must join the CUSTOMER table to either the INDIVIDUAL_CUSTOMERtable or the COMMERCIAL_CUSTOMER table, depending on the value ofCUSTOMER_TYPE The data-modeling purists on your project team are guaran-teed to favor this approach, but the application programmers who must write theSQL to access the tables may likely take a counter position

(lo-Implementing Each Subtype as a Discrete Table

This is called the “two-table” solution because it involves creating one table for eachsubtype and including all the columns from the super type table in each subtype

At first, this may appear to involve redundant data, but in fact there is no redundant

Composite Default screen

storage because a given customer can be only one of the two subtypes However,

some columns are redundantly defined Figure 8-2 shows the physical design for this

alternative

This alternative is favored when very few attributes are common between the

sub-types (that is, when the super type table contains very few attributes) In our

exam-ple, the situation is further complicated because of the CUSTOMER_CONTACT

table, which is a child of the super type table (CUSTOMER) You cannot (or at least

should not) make a table the child of two different parents based on the same foreign

key Therefore, if we eliminate the CUSTOMER table, we must create two versions

Figure 8-1 Customer subclasses: three-table physical design

Figure 8-2 Customer subclasses: two-table physical design

of the CUSTOMER_CONTACT table—one as a child of INDIVIDUAL_CUSTOMER and the other as a child of COMMERCIAL_CUSTOMER Althoughthis alternative may be a viable solution in some situations, the complication of theCUSTOMER_CONTACT table makes it a poor choice in this case.

Collapsing Subtypes into the Super type Table

This is called the “one-table” solution because it involves creating a single table thatencompasses the super type and both subtypes Figure 8-3 shows the physical designfor this alternative Check constraints are required to enforce the optional columns.For the CUSTOMER_TYPE value that signifies “Individual,” DATE_OF_BIRTHand ANNUAL_HOUSEHOLD_INCOME would be allowed to (or required to)contain values, and COMPANY_NAME, TAX_IDENTIFICATION_NUMBER,ANNUAL_GROSS_INCOME, and COMPANY_TYPE would be required to benull For the CUSTOMER_TYPE value that signifies “Commercial,” the behaviorrequired would be just the opposite

This alternative is favored when relatively few attributes are particular to anygiven subtype In terms of data access, it is clearly the simplest alternative because

no joins are required However, it is perhaps more complicated in terms of logic cause one must always keep in mind which attributes apply to which subtype (that is,which value of CUSTOMER_TYPE in this example) With only two subtypes, and atotal of six subtype-determined attributes between them, this seems a very attractivealternative for this example

Figure 8-3 Customer subclasses: one-table physical design Composite Default screen

Naming Conventions

Naming conventions are important because they help promote consistency in the

names of tables, columns, constraints, indexes, and other database objects Every

or-ganization should develop a standard set of naming conventions (with variations as

needed when multiple RDBMSs are in use), publish it, and enforce its use The

con-ventions offered here are only suggestions based on current industry best practices

Table Naming Conventions

Here are some suggested naming conventions for database tables:

• Table names should be based on the name of the entity they represent They

should be descriptive, yet concise

• Table names should be unique across the entire organization (that is, across

all databases), except where the table really is an exact duplicate of another(that is, a replicated copy)

• Some designers prefer singular words for table names whereas others prefer

plural names (for example, CUSTOMER versus CUSTOMERS) OracleCorporation recommends singular names for entities and plural names fortables (a convention this author has never understood) It doesn’t matterwhich convention you adopt as long as you are consistent across all yourtables, so do set one or the other as your standard

• Do not include words such as “table” or “file” in table names

• Use only uppercase letters, and use an underscore to separate words Not

all RDBMSs have case-sensitive object names, so mixed-case names limitapplicability across multiple vendors

• Use abbreviations when necessary to shorten names that are longer than the

RDBMS maximum (typically 30 characters or so) Actually, it is a good idea

to stay a few characters short of the RDBMS maximum to allow for suffixeswhen necessary All abbreviations should be placed on a standard list andthe use of nonstandard abbreviations discouraged

• Avoid limiting names such as WEST_SALES Some organizations add

a two- or three-character prefix to table names to denote the part of theorganization that owns the data in the table However, this is not considered

a best practice because it can lead to a lack of data sharing Moreover, placinggeographic or organizational unit names in table names plays havoc everytime the organization changes

Column Naming Conventions

Here are some suggested naming conventions for table columns:

• Column names should be based on the attribute name as shown in thelogical data model They should be descriptive, yet concise

• Column names must be unique within the table, but where possible, it isbest if they are unique across the entire organization Some conventionsmake exceptions for common attributes such as City, which might describeseveral entities such as Customer, Employee, and Company Location

• Use only uppercase letters, and use an underscore to separate words Notall RDBMSs have case-sensitive object names, so mixed-case names limitapplicability across multiple vendors

• Prefixing column names with entity names is a controversial issue Someprefer prefixing names For example, in the CUSTOMER table, they woulduse column names such as CUSTOMER_NUMBER, CUSTOMER_NAME,CUSTOMER_ADDRESS, CUSTOMER_CITY, and so forth Others (thisauthor included) prefer to prefix only the primary key column name (forexample, CUSTOMER_NUMBER), which leads easily to primary key andmatching foreign key columns having exactly the same names Still othersprefer no prefixes at all, and end up with a column name such as ID for theprimary key of every single table

• Use abbreviations when necessary to shorten names that are longer than theRDBMS maximum (typically 30 characters or so) All abbreviations should beplaced on a standard list and the use of nonstandard abbreviations discouraged

• Regardless of any other convention, most experts prefer that foreign keycolumns always have exactly the same name as their matching primarykey column This helps other database users understand which columns

to use when coding joins in SQL

Constraint Naming Conventions

In most RDBMSs, the error message generated when a constraint is violated containsthe constraint name Unless you want to field questions from database users every timeone of these messages shows up, you should name the constraints in a standard waythat is easily understood by the database users Most database designers prefer a con-vention similar to the one presented here

Constraint names should be in the format TNAME_TYPE_CNAME, where:

• TNAME is the name of the table on which the constraint is defined,abbreviated if necessary

Composite Default screen

• TYPE is the type of constraint:

• “PK” for primary key constraints

• “FK” for foreign key constraints

• “UQ” for unique constraints

• “CK” for check constraints

• CNAME is the name of the column on which the constraint is defined,

abbreviated if necessary For constraints defined across multiple columns,another descriptive word or phrase may be substituted if the column namesare too long (even when abbreviated) to make sense

Index Naming Conventions

Indexes that are automatically defined by the RDBMS to support primary key or

unique constraints are typically given the same name as the constraint name, so you

seldom have to worry about them For other types of indexes, it is wise to have a

naming convention so that you know the table and column(s) on which they are

de-fined without having to look up anything The following is a suggested convention

Index names should be in the format TNAME_TYPE_CNAME, where:

• TNAME is the name of the table on which the index is defined, abbreviated

if necessary

• TYPE is the type of index:

• “UX” for unique indexes

• “IX” for nonunique indexes

• CNAME is the name of the column on which the index is defined, abbreviated

if necessary For indexes defined across multiple columns, another descriptiveword or phrase may be substituted if the column names are too long (even whenabbreviated) to make sense

Also, any abbreviations used should be documented in the standard abbreviations list

View Naming Conventions

View names present an interesting dilemma The object names used in the FROM

clause of SQL statements can be for tables, views, or synonyms A synonym is an

alias (nickname) for a table or view So how does the DBMS know whether an object

name in the FROM clause is a table or view or synonym? Well, it doesn’t until it

looks up the name in a metadata table that catalogs all the objects in the database

This means, of course, that the names of tables, views, and synonyms must come

from the same namespace, or list of possible names Therefore, a view name must be

unique among all table, view, and synonym names

214 Databases Demystified

Demystified / Databases Demystified / Oppel/ 225364-9 / Chapter 8

Because it is useful for at least some database users to know if they are ing a table or a view, and as an easy way to ensure that names are unique, it is com-mon practice to give views distinctive names by employing a standard that appends

referenc-“VW” to the beginning or end of each name, with a separating underscore Again,the exact convention chosen matters a lot less than picking one standard conventionand sticking to it for all your view names Here is a suggested convention:

• All view names should end with “_VW” so they are easily distinguishablefrom table names

• View names should contain the name of the most significant base tableincluded in the view, abbreviated if necessary

• View names should describe the purpose of the views or the kind of dataincluded in them For example, CALIFORNIA_CUSTOMERS_VW andCUSTOMERS_BY_ZIP_CODE_VW are both reasonably descriptive viewnames, whereas CUSTOMER_LIST_VW and CUSTOMER_JOIN_VWare much less meaningful

• Any abbreviations used should be documented in the standard abbreviations list

Integrating Business Rules

and Data Integrity

Business rules determine how an organization operates and utilizes its data ness rules exist as a reflection of an organization’s policies and operational proce-dures and because they provide control Data integrity is the process of ensuring thatdata is protected and stays intact through defined constraints placed on the data Wecall these database constraints because they prevent changes to the data that wouldviolate one or more business rules The principal benefit of enforcing business rulesusing data integrity constraints in the database is that database constraints cannot becircumvented Unlike business rules enforced by application programs, databaseconstraints are enforced no matter how someone connects to the database The onlyway around database constraints is for the DBA to remove or disable them.Business rules are implemented in the database as follows:

Busi-• NOT NULL constraints

• Primary key constraints

• Referential (foreign key) constraints

• Unique constraints

Composite Default screen

TEAM FLY

• Check constraints

• Data types, precision and scale

• Triggers

The subsections that follow discuss each of these implementation techniques and

the effect the constraints have on database processing Throughout this topic, we

will use the following table definition as an example A remark (REM statement) has

been placed above each component to help you identify it Note that the INVOICE

table used here has a column difference—TERMS is replaced with CUSTOMER_

PO_NUMBER, which is needed to illustrate some key concepts A DROP statement

is included to drop the INVOICE table in case you created it when following

previ-ous examples

REM Drop Invoice Table (in case there already is one)

DROP TABLE INVOICE CASCADE CONSTRAINTS;

REM Create Invoice Table

CREATE TABLE INVOICE

(INVOICE_NUMBER NUMBER(7) NOT NULL,

CUSTOMER_NUMBER NUMBER(5) NOT NULL,

CUSTOMER_PO_NUMBER VARCHAR(10) NULL,

SHIP_VIA VARCHAR(30) NULL,

ORDER_DATE DATE NOT NULL);

REM Create Primary Key Constraint

ALTER TABLE INVOICE

ADD CONSTRAINT INVOICE_PK_INVOICE_NUMBER

PRIMARY KEY (INVOICE_NUMBER);

REM Create Referential Constraint

ALTER TABLE INVOICE

ADD CONSTRAINT INVOICE_FK_CUSTOMER_NUMBER

FOREIGN KEY (CUSTOMER_NUMBER) REFERENCES CUSTOMER (CUSTOMER_NUMBER);

REM Create Unique Constraint

ALTER TABLE INVOICE

ADD CONSTRAINT INVOICE_UNQ_CUST_NUMB_PO

UNIQUE (CUSTOMER_NUMBER, CUSTOMER_PO_NUMBER);

REM Create CHECK Constraint

ALTER TABLE INVOICE

ADD CONSTRAINT INVOICE_CK_ORDER_DATE

CHECK (ORDER_DATE <= SYSDATE);

NOT NULL Constraints

As you have already seen, business rules that state which attributes are requiredtranslate into NOT NULL clauses on the corresponding columns in the table design

In fact, the NOT NULL clause is how we define a NOT NULL constraint on tablecolumns Primary keys must always be specified as NOT NULL (Oracle will auto-matically do this for you, but most other RDBMSs will not) And, as already men-tioned, any foreign keys that participate in a mandatory relationship should also bespecified as NOT NULL

In our example, if we attempt to insert a row in the INVOICE table and fail to vide a value for any of the columns that have NOT NULL constraints (that is, theINVOICE_NUMBER, CUSTOMER_NUMBER, and ORDER_DATE columns),the insert will fail with an error message indicating the constraint violation Also, if

pro-we attempt to update any existing row and set one of those columns to a NULL value,the update statement will fail

Primary Key Constraints

Primary key constraints require that the column(s) that make up the primary keycontain unique values for every row in the table In addition, primary key columnsmust be defined with NOT NULL constraints A table may have only one primarykey constraint The RDBMS will automatically create an index to assist in enforcingthe primary key constraint

In our sample INVOICE table, if we attempt to insert a row without specifying avalue for the INVOICE_NUMBER column, the insert will fail because of the NOTNULL constraint on the column If we instead try to insert a row with a value for theINVOICE_NUMBER column that already exists in the INVOICE table, the insertwill fail with an error message that indicates a violation of the primary key con-straint This message usually contains the constraint name, which is why it is such agood idea to give constraints meaningful names Finally, assuming the RDBMS inuse permits updates to primary key values (some do not), if we attempt to update theINVOICE_NUMBER column for an existing row and we provide a value that isalready used by another row in the table, the update will fail

Referential (Foreign Key) Constraints

The referential constraint on the INVOICE table defines CUSTOMER_NUMBER

as a foreign key to the CUSTOMER table It takes some getting used to, but tial constraints are always defined on the child table (that is, the table on the “many”

Composite Default screen

side of the relationship) The purpose of the referential constraint is to make sure that

foreign key values in the rows in the child table always have matching primary key

values in the parent table

In our INVOICE table example, if we try to insert a row without providing a value

for CUSTOMER_NUMBER, the insert will fail due to the NOT NULL constraint on

the column However, if we try to insert a row and provide a value for CUSTOMER_

NUMBER that does not match the primary key of a row in the CUSTOMER table, the

insert will fail due to the referential constraint Also, if we attempt to update the value

of CUSTOMER_NUMBER for an existing row in the INVOICE table and the new

value does not have a matching row in the CUSTOMER table, the update will fail,

again due to the referential constraint

Always keep in mind that referential constraints work in both directions, so they

can prevent a child table row from becoming an “orphan,” meaning it has a value that

does not match a primary key value in the parent table Therefore, if we attempt to

delete a row in the CUSTOMER table that has INVOICE rows referring to it (or if

we attempt to update the primary key value of such a row), the statement will fail

be-cause it would be-cause child table rows to violate the constraint However, many

RDBMSs provide a feature with referential constraints written as ON DELETE

CASCADE, which causes referencing child table rows to be automatically deleted

when the parent row is deleted Of course, this option is not appropriate in all

situa-tions, but it is nice to have when you need it

Unique Constraints

Like primary key constraints, unique constraints ensure that no two rows in the table

have duplicate values for the column(s) named in the constraint However, there are

two important differences:

• Although a table may have only one primary key constraint, it may have as

many unique constraints as necessary

• Columns participating in a unique constraint do not have to have NOT NULL

constraints on them

As with a primary key constraint, an index is automatically created to assist the

DBMS in efficiently enforcing the constraint

In our example, a unique constraint is defined on the CUSTOMER_NUMBER

and CUSTOMER_PO_NUMBER columns, to enforce a business rule that states

that customers may only use a PO (purchase order) number once It is important to

understand that it is the combination of the values in the two columns that must be

unique There can be many invoices for any given CUSTOMER_NUMBER, and

there can be multiple rows in the INVOICE table with the same PO_NUMBER (wecannot prevent two customers from using the same PO number, nor do we wish to).However, no two rows for the same customer number may have the same PO number.

As with the primary key constraint, if we attempt to insert a row with values forthe CUSTOMER_NUMBER and PO_NUMBER columns that are already in use byanother row, the insert will fail Similarly, we cannot update a row in the INVOICEtable if the update would result in the row having a duplicate combination ofCUSTOMER_NUMBER and PO_NUMBER

we attempt to insert or update a row with an INVOICE_DATE set to a future date, thestatement will fail

Data Types, Precision, and Scale

The data type assigned to the table columns automatically constrains the data to ues that match the data type For example, anything placed in a column with a dateformat must be a valid date You cannot put nonnumeric characters in numeric col-umns However, you can put just about anything in a character column

val-For data types that support the specification of the precision (maximum size) andscale (positions to the right of the decimal point), these specifications also constrain

Composite Default screen

the data You simply cannot put a character string or number larger than the

maxi-mum size for the column into the database Nor can you specify decimal positions

beyond those allowed for in the scale of a number

In our example, CUSTOMER_NUMBER must contain only numeric digits and

cannot be larger than 99,999 (five digits) or smaller than –99,999 (again, five digits)

Also, because the scale is 0, it cannot have decimal digits (that is, it must be an

inte-ger) It may seem silly to allow negative values for CUSTOMER_NUMBER, but

there is no SQL data type that restricts a column to only positive integers However,

if it is easy enough to restrict a column to only positive numbers using a check

con-straint if such a concon-straint is required

Triggers

As you may recall, a trigger is a unit of program code that executes automatically

based on some event that takes place in the database, such as inserting, updating, or

deleting data in a particular table Triggers must be written in a language supported

by the RDBMS For Oracle, this is either a proprietary extension to SQL called PL/

SQL (Procedural Language/SQL) or Java (available in Oracle8i or later) For Sybase

and Microsoft SQL Server, the supported language is Transact-SQL Some

RDBMSs have no support for triggers, whereas others support a more general

pro-gramming language such as C Trigger code must either end normally, which allows

the SQL statement that caused the trigger to fire to end normally, or must raise a

data-base error, which in turn causes the SQL statement that caused the trigger to fire to

fail as well

Triggers can enforce business rules that cannot be enforced via database

con-straints Because they are written using a full-fledged programming language, they

can do just about anything that can be done with a database and a program (some

RDBMSs do place some restrictions on triggers) Whether a business rule should be

enforced in normal application code or through the use of a trigger is not always an

easy decision The application developers typically want control of such things, but

on the other hand, the main benefit of triggers is that they run automatically and

can-not be circumvented (unless the DBA removes or disables them), even if someone

connects directly to the database, bypassing the application

A common use of triggers in RDBMSs that do not support ON DELETE

CASCADE in referential constraints is to carry out the cascading delete For

exam-ple, if we want invoice line items to be automatically removed from the INVOICE_

LINE_ITEM table when the corresponding invoice in the INVOICE table is deleted,

we could write a trigger that carries that out The trigger would be set to fire when a

delete from the INVOICE table takes place It would then issue a delete for all the