Applied Mathematics for Database Professionals
This section provides a summary of this chapter, formatted as a bulleted list. • You usually implement a database design in order to build a business application on top of it. These applications normally are window-on-data (WoD) applications. Users query and transact data by using these applications...
| Main Author: | |
|---|---|
| Format: | Book |
| Language: | English |
| Published: |
Apress
2007
|
| Subjects: | |
| Online Access: | http://eprints.umpo.ac.id/927/ http://eprints.umpo.ac.id/927/1/Apress.Applied.Mathematics.for.Database.Professionals.Jun.2007.pdf |
| Summary: | This section provides a summary of this chapter, formatted as a bulleted list. • You usually implement a database design in order to build a business application on top of it. These applications normally are window-on-data (WoD) applications. Users query and transact data by using these applications. • All code of a WoD application can be classified into three classes: user interface code (UI code), business logic code (BL code), and data integrity code (DI code). UI code creates the user interface that the user sees, and it responds to events initiated by the user in the user interface. DI code is responsible for the continued validity of all data integrity constraints as users change data in the database. BL code is responsible for composing and executing queries and transactions. • This chapter’s main focus has been how to implement DI code in an efficient manner. • You can implement DI code using one of the following three strategies: declarative, triggered procedural, or embedded procedural. • You can state all attribute and tuple constraints declaratively. You can state only a few table and database constraints declaratively. • The majority of (multi-row) data integrity constraints must be implemented procedurally. In this chapter, the triggered procedural strategy is preferred over the embedded procedural strategy. • We introduced you to six execution models for implementing DI code for multi-tuple constraints. These range from rather inefficient (every constraint is fully checked for every DML statement), to rather efficient (a constraint is conditionally checked in a minimal way). • Given Oracle’s standard read-committed isolation level, you must programmatically serialize DI code. Failure to do so can result in constraint violations when transactions execute concurrently. Serializing DI code of transition constraints is particularly difficult. • Certain constraints cannot be validated at the statement level; they require a deferred execution model of the DI code. Extending the execution models to cater ... |
|---|