Summary

In the introduction to this appendix, I said it was my position that database professionals should have at least a nodding acquaintance with the basic concepts of relational calculus (or predicate logic it comes to the same thing). I'd like to conclude by trying to justify that position.

My basic point is simply that a knowledge of logic helps you think precisely (and in our field, the importance of thinking precisely is surely paramount). In particular, it forces you to appreciate the significance of proper quantification. Natural language is so often imprecise; however, careful consideration of what quantification is needed allows you to pin down the meaning of what can otherwise be very imprecise natural-language statements. By way of example, you might like to meditate on exactly what Abraham Lincoln meant or might have meant, or thought he might have meant, or might have thought he meant when he famously said: "You can fool some of the people some of the time, and some of the people all the time, but you cannot fool all the people all of the time."

Of course, I'm well aware there are many people who disagree with me here; that is, there are many people who feel ordinary mortals shouldn't have to grapple with a subject as abstruse as logic seems to be. In effect, they claim that logic is just too difficult for most people to deal with. Now, that claim might be true in general (logic is a big subject), but you don't need to understand the whole of logic for the purpose at hand; in fact, I doubt whether you need much more than what I've covered in this appendix. And the benefits are so huge! I made essentially the same point in a 2004 article "The Logic of Business Rules," www.dbdebunk.com (June 2004), on which much of the present appendix is based and I'd like to quote the concluding remarks from that article here:

Surely it's worth investing a little effort up front in becoming familiar with [the material in this appendix] in order to avoid the problems associated with [business rules that are stated ambiguously]. Ambiguity in business rules leads to implementation delays at best or implementation errors at worst (possibly both). And such delays and errors certainly have costs associated with them, costs that are likely to outweigh those initial learning costs many times over. In other words, framing business rules properly is a serious matter, and it requires a certain level of technical competence.

As you can see, these remarks are set in the context of business rules specifically, but I think they're of wider applicability.