You’ve reached the last chapter of this book. In this chapter we’ll provide a brief summary first and then give some conclusions.

Summary

In Part 1 of this book, we presented two important mathematical disciplines: logic and set theory. These two disciplines are the most relevant ones in the application of mathematics to the field of databases.

Chapter 1 offered an introduction to logic. We presented the concepts of a proposition and a predicate, and showed how you can use logical connectives (conjunction, disjunction, implication, equivalence, and negation) to describe compound propositions and predicates. The chapter ended by establishing the very important concept of a rewrite rule. You’ve seen many applications of rewrite rules throughout this book; they enable you to transform predicates into other equivalent predicates.

Chapter 2 offered an introduction to set theory. We presented several ways to specify sets, discussed the concept of a subset, and explored the common set operators union, intersection, and difference. The chapter ended with a treatment of powersets and ordered pairs. As you saw in Part 2 of this book, set theory provides an excellent language to reliably describe complex database designs, data retrieval, and data manipulation.

Chapter 3 continued the treatment of logic that was started in the first chapter. It introduced you to the key concepts of universal and existential quantification and identified important rewrite rules concerning these two quantifiers. One of these rewrite rules demonstrated that you can transform the existential quantifier into a universal quantifier, and vice versa—a rewrite rule that has been applied many times in this book.

Chapter 4 continued the set theory basics laid down in Chapter 2, and introduced some more concepts in this area. You saw how you can use a function to represent a tuple. We’ve also shown how you can use a special kind of function, a set function, to characterize something of the real world that needs to be represented in the database.

Chapters 5 and 6 demonstrated how you can apply set theory and logic to describe important concepts in the field of databases. We used these mathematical disciplines to formally describe the following:

• Tables and database states
• Common table operators such as projection, extension, restriction, and join—to name a few
• Tuple, table, and database predicates—the building blocks for specifying constraints

At the end of Chapter 6 we also explored common types of data integrity predicates: unique identification, subset requirements, specialization, generalization, and tuple-in-join predicates.

Chapter 7 brought everything together and demonstrated the main topic of this book: how you can apply all introduced mathematical concepts to create a solid database design specification (a database universe). The layered approach in which this was done gives us a good and clear insight into the relevant data integrity constraints. It established several classes of constraints: attribute, tuple, table, and database constraints. Chapter 8 explored another class of constraints: state transition constraints. As you’ve seen, you can also specify this class of constraints in a formal way. Clear insight in all involved constraints is a prerequisite to performing a reliable and robust implementation of the design using an SQL DBMS.

Chapters 9 and 10 discussed the application of the mathematics in the areas of specifying data retrieval (queries) and data manipulation (transactions).

Finally, in Chapter 11 we explored the challenges of implementing a database design— specifically all its data integrity constraints—in a well-known SQL DBMS (Oracle). As you’ve seen, for some classes of constraints, the implementation is trivial (they can be declared to the DBMS), but for other classes of constraints the implementation turns out to be a complex task. Implementing an efficient execution model, serializing transactions, and sometimes deferring the execution of checking the constraints are some of the aspects that make this task a serious challenge.

Conclusions

The unique aspect of this book is captured by its title: applied mathematics for database professionals. We’ve described two disciplines of mathematics that can act as high-quality toolsets for a database professional. We’ve described how to apply these toolsets in the area of data integrity constraints.

Data integrity constraints add semantic value to the data captured by a database design by describing how the table structures represent the real world that we work in. For this reason, data integrity constraint specifications are an integral part of a database design specification. The formal methodology described in this book enables us to specify a database design precisely, and in particular to specify all involved data integrity constraints precisely.

Here is quote that reiterates the importance of data integrity constraints:

It should be clear that integrity constraints are crucially important, since they control the correctness of the data. In many ways, in fact, integrity constraints are the most important part of the system.

C. J. Date, What Not How (Addison-Wesley, 2000)

Why are formal constraint specifications so important?

Well, if we use plain English, or some awkward derivative, to express data integrity constraints we’ll inevitably hit the problem of how the English sentence maps, unambiguously, into the database design. Different software developers will implement such specifications diversely, because they all try to convert the sentence—everybody in his or her own way—to something that will map into the database design, and then code it.

Every informal language is bound to be ambiguous. This is unsolvable. An informal or natural language effort to capture data integrity constraints will always fail in exposing, unambiguously, how such a constraint maps into the database design, because there exists no mapping from the informal natural language to the formal world of a database design. This data integrity constraint problem is inevitable unless we adopt a formal methodology. With a formal language, we can unambiguously describe how a constraint maps into a database design.

Within the IT profession we should recognize that database design is a task for properly educated database professionals. Their education must involve enough set theory and logic, including how these disciplines can be applied in the field of designing databases. This book aims to provide this formal education.

How can you start applying this knowledge in your job as a database professional? Here’s a little roadmap that you can adopt.

1. Whenever you design your next database, start by specifying the involved data integrity constraints in a formal way. Specify them as data integrity predicates and adopt the classification scheme introduced in Chapters 7 and 8.
2. Apply this formalism to queries too, especially the more complex ones. Use rewrite rules in the formal world to come up with expressions that can easily be transformed to SQL.
3. Finally, you can move on to specifying transactions formally too. This should avoid all ambiguities when software is developed to implement the business logic of a WoD application.

You’ll get the biggest gains from step 1. It ensures that there is a documented single truth of the meaning (semantics) of the database design, which in turn makes certain that all software developers will understand and therefore use the database design in the same way.

Once you formally specify the database design, a good implementation of the database design becomes possible. We’ve discussed various strategies for implementing the important part of every database design: the data integrity constraints.

Implementing data constraints declaratively is easy. Implementing data constraints procedurally is by far not a trivial task (as discussed in Chapter 11). It’s time consuming and will produce more lines of complex procedural code than you might have expected (part of which can be generated, though). The current status of DBMS technology, such as Oracle’s SQL DBMS, enables us to implement database designs in a robust way; that is, including the DI code for all data integrity constraints in a triggered procedural way.

Still, few database professionals actually do this. Why? Probably because designing DI code that is fully detached from BL code (the triggered procedural strategy) is indeed truly complex given the current state of DBMSes available to us. However, this neglects the big picture. Failing to fully detach DI code from BL code implies not being able to efficiently maintain and manage the DI code and thus the constraints.

We should not underestimate the gains we receive once all DI code is implemented separately. Data integrity constraints have then finally become manageable. There is an interesting opportunity for DBMS vendors to evolve their products into data integrity constraint engines. It is up to the scientific world to come up with more meaningful subclasses of constraints first. The DBMS vendors, in their turn, should then provide us with new declarative constructs at the DBMS level to implement these easily.

Once more declarative constructs are available, there is not only a huge potential of much more rapid construction of WoD applications, but also the potential of achieving considerable savings in the cost of maintaining such an application.