• Aucun résultat trouvé

Should You Normalize Your Data?

Dans le document Oracle Essentials Oracle Database 11g (Page 125-128)

Whenever possible, we recommend that yougo through the process of designing a nor-malized structure for your database.

Data normalization has been proven, both theoretically and in decades of practice, to provide concrete benefits. In addition, the process of creating a normalized data design is intimately intertwined with the process of understanding the data requirements for your application system. You can improve even the simplest database by the discover-ies made during the process of normalization.

However, there may be times when youfeel that the benefits of a fully normalized design will counteract the performance penalty that a design imposes on your produc-tion systems. For example, youmay have one, two, or three contact names to be placed in their own table, with a foreign key linking back to the main row for the organization.

But because you want to see all the contact names every time you request contact infor-mation, youmight decide to save the overhead and added development effort of the join and simply include the three contact names in your organization table. This tech-nique is common in decision-support/data warehousing applications.

Of course, this violation of the rules of normalization limits the flexibility of your appli-cation systems—for example, if youlater decide that youneed four contact names, some modification of every application and report that uses the contact names will be necessary. Normalization leads to a more flexible design, which is a good thing in the constantly changing world we live in.

For this reason, we suggest that you always implement a fully normalized database design and then, if necessary, go back and denormalize certain tables as needed. With this approach, youwill at least have to make a conscious decision to “break” the nor-malization, which involves an active consideration of the price of denormalization.

106 | Chapter 4: Oracle Data Structures Foreign key

The foreign key constraint is defined for a table (known as thechild) that has a relationship with another table in the database (known as theparent). The value entered in a foreign key must be present in a unique or primary key of another specific table. For example, the column for a department ID in an employee table might be a foreign key for the department ID primary key in the depart-ment table.

A foreign key can have one or more columns, but the referenced key must have an equal number of columns. You can have a foreign key relate to the primary key of its own table, such as when the employee ID of a manager is a foreign key referencing the ID column in the same table.

A foreign key can contain a NULL value if it’s not forbidden through another constraint.

By requiring that the value for a foreign key exist in another table, the foreign key constraint enforces referential integrity in the database. Foreign keys not only provide a way to join related tables but also ensure that the relationship between the two tables will have the required data integrity.

Normally, youcannot delete a row in a parent table if it causes a row in the child table to violate a foreign key constraint. However, youcan specify that a foreign key constraint causes a cascade delete, which means that deleting a referenced row in the parent table automatically deletes all rows in the child table that refer-ence the primary key value in the deleted row in the parent table.

Check

A check constraint is a more general-purpose constraint. A check constraint is a Boolean expression that evaluates to either TRUE or FALSE. If the check con-straint evaluates to FALSE, the SQL statement that caused the result returns an error. For example, a check constraint might require the minimum balance in a bank account to be over $100. If a user tries to update data for that account in a way that causes the balance to drop below this required amount, the constraint will return an error.

Some constraints require the creation of indexes to support them. For instance, the unique constraint creates an implicit index used to guarantee uniqueness. You can also specify a particular index that will enforce a constraint when you define that constraint.

All constraints can be either immediate or deferred. An immediate constraint is enforced as soon as a write operation affects a constrained column in the table. A deferred constraintis enforced when the SQL statement that caused the change in the constrained column completes. Because a single SQL statement can affect several rows, the choice between using a deferred constraint or an immediate constraint can significantly affect how the integrity dictated by the constraint operates. Youcan

Triggers | 107 specify that an individual constraint is immediate or deferred, or you can set the tim-ing for all constraints in a stim-ingle transaction.

Finally, you can temporarily suspend the enforcement of constraints for a particular table. When youenable the operation of the constraint, youcan instruct Oracle to validate all the data for the constraint or simply start applying the constraint to the new data. When youadd a constraint to an existing table, youcan also specify whether you want to check all the existing rows in the table.

Triggers

You use constraints to automatically enforce data integrity rules whenever a user tries to write or modify a row in a table. There are times when youwant to use the same kind of timing for your own application-specific logic. Oracle includestriggers to give you this capability.

Although you can write triggers to perform the work of a constraint, Oracle has optimized the operation of constraints, so it’s best to always use a constraint instead of a trigger if possible.

A trigger is a block of code that is fired whenever a particular type of database event occurs to a table. There are three types of events that can cause a trigger to fire:

• A database UPDATE

• A database INSERT

• A database DELETE

You can, for instance, define a trigger to write a customized audit record whenever a user changes a row.

Triggers are defined at the row level. Youcan specify that a trigger be fired for each row or for the SQL statement that fires the trigger event. As with the previous discus-sion of constraints, a single SQL statement can affect many rows, so the specification of the trigger can have a significant effect on the operation of the trigger and the per-formance of the database.

There are three times when a trigger can fire:

• Before the execution of the triggering event

• After the execution of the triggering event

• Instead of the triggering event

Combining the first two timing options with the row and statement versions of a trigger gives youfour possible trigger implementations: before a statement, before a row, after a statement, and after a row.

108 | Chapter 4: Oracle Data Structures

Oracle Database 11g introduced the concept of compound triggers; with this enhancement, a single trigger can have a section for the different timing implementa-tions. Compound triggers help to improve performance, since the trigger has to be loaded only once for multiple timing options.

INSTEAD OF triggers were introduced with Oracle8. The INSTEAD OF trigger has a specific purpose: to implement data-manipulation operations on views that don’t normally permit them, such as a view that references columns in more than one base table for updates. You should be careful when using INSTEAD OF triggers because of the many potential problems associated with modifying the data in the underlying base tables of a view. There are many restrictions on when youcan use INSTEAD OF triggers. Refer to your Oracle documentation for a detailed description of the for-bidden scenarios.

Youcan specify atrigger restrictionfor any trigger. A trigger restriction is a Boolean expression that circumvents the execution of the trigger if it evaluates to FALSE.

Triggers are defined and stored separately from the tables that use them. Since they contain logic, they must be written in a language with capabilities beyond those of SQL, which is designed to access data. Oracle8 and later versions allow youto write triggers in PL/SQL, the procedural language that has been a part of Oracle since Ver-sion 6. Oracle8iand beyond also support Java as a procedural language, so you can create Java triggers with those versions.

Youcan write a trigger directly in PL/SQL or Java, or a trigger can call an existing stored procedure written in either language.

Triggers are fired as a result of a SQL statement that affects a row in a particular table. It’s possible for the actions of the trigger to modify the data in the table or to cause changes in other tables that fire their own triggers. The end result of this may be data that ends up being changed in a way that Oracle thinks is logically illegal.

These situations can cause Oracle to return runtime errors referring to mutating tables, which are tables modified by other triggers, orconstraining tables, which are tables modified by other constraints. Oracle8ieliminated some of the errors caused by activating constraints with triggers.

Oracle8ialso introduced a very useful set of system event triggers (sometimes called database-level event triggers), and user event triggers (sometimes calledschema-level event triggers). For example, youcan place a trigger on system events such as data-base startup and shutdown and on user events such as logging on and logging off.

Dans le document Oracle Essentials Oracle Database 11g (Page 125-128)