**Logic: Introduction**

“Everything should be made as simple as possible, but not simpler”– Albert Einstein

The first chapter of Applied Mathematics for Database Professionals is on logic. This chapter is actually available to download from Apress as a free sample chapter. I think this is one of the harder chapters in part 1: the mathematics, so if you can understand this one, I think you’ll be fine with this book. I studied logic in a pure mathematics course in first year at University, and a lot of these terms rung some bells. But this was nearly 2 decades ago, so those bells were quite distant and ringing quite softly.

I also really like how each chapter starts with a page outlining what is going to be covered within the chapter, and each chapter finishes with a series of bullet points highlighting the key features that were covered. This technique really adds to the pedagogic nature of the book.

Chapter 1 begins with a brief introduction to Logic, which obviously goes way back to Ancient Greece. Explains that the relational model is based on logic and that:

“one of the goals of the book is to explain the mathematical concepts on which relational data management is based”

Some definitions of values, variables and types.

A value is a constant, cannot be changed.

A variable is a holder for a value, variables can change over time.

variables (and values) are always of a particular type. A type is the set of values from which a variable is allowed to hold its values, e.g. integers, characters, etc.

Discussion of propositional logic. A proposition is a *declarative* statement that is either TRUE or FALSE. Examples of things that are not propositions, including equations that can be true or false depending on the values of the variables.

Found the discussion on predicate logic quite hard going, states that a predicate is something having the form of a declarative statement that has variables that once the values of which are known turns the statement into a proposition. Essentially a predicate only can be evaluated (as TRUE or FALSE) when it is invoked with a set of parameters.

Logical connectives (operators) are introduced, they take one or more predicate and return another predicate. Predicates without connectives are known as simple predicates, while those with connectives are compound predicates. The logical operators have precendence rules.

The going got a bit easier with the discussion of truth tables.

Finishes with discussion of logical equivalence and rewrite rules, and I’m afraid the going gets hard again. A rewrite rule allows a proposition in one form to be replaced by another proposition such that is has the same truth values. Includes a discussion on De Morgans Laws.

This becomes mathematically challenging very quickly, and while this chapter felt very far removed from my life as a database professional, I’ve had a sneak peak at chapter 2 and that seems more familiar, so I’m going to carry on with thisl.

I started reading this book a while back but haven’t picked it up in a while, not through lack of want, just haven’t had the time. I can’t remember where I got to but will probably have to backtrack to remember the fundamentals from the earlier chapters. Hopefully this will help cement the knowledge learned from part 1.

Not having studied mathematics formally for a long time I agree that it is fairly hard going in parts (glad it wasn’t just me!) but I found it a very interesting read. I hope to have the time to finish it soon and expect that it will become clearer when I move on to the sections describing the practical application of the theory.

“Finishes with discussion of logical equivalence and rewrite rules, and I’m afraid the going gets hard again.”

Just a short “author’s comment” here. Rewrite rules will become a very important concept in later chapters. And many more examples of rewrite rules will follow.

Of the ones in table 1-11, most are trivial, right? But if you didn’t already know a) the De Morgan laws, b) the distribution rewrite, and c) the implication rewrite, then you should just learn them by heart right now, as they will return quite a few times in later chapters.

Especially the implication rewrite:

“P implies Q” is equivalent to “(not P) or Q”.

Memorize it :-). Database designs are full of constraints that are or contain implications. And the implication connective, is one we do not have available to us in SQL. So this rewrite rule needs to be employed all the time.

A simple example: suppose we want to introduce a business rule on the EMP table stating that employees whose job equals ‘manager’ should always earn a salary greater than 4200.

Formally this rule is an implication of the followning form:

“job = ‘manager’ implies salary > 4200”

We cannot put this in a CHECK constraint, as the implication is not available to us. But we can, confidently, rewrite the implication according to the rewrite rule into:

“job != ‘manager’ or salary > 4200”

This expression we can now put in a CHECK constraint easily.

Also suppose you would first want to check the contents of the table and find the rows that do not match this constraint. So you want to find the rows for which the negated constraint expression holds true:

not (“job != ‘manager’ or salary > 4200”)

This expression can already be used in the WHERE-clause of the query seeking the constraint violating rows.

Or we can apply De Morgan first, to get rid of the parenthesis, and rewrite it into:

“not(job != ‘manager’) and not(salary > 4200)”

Which further rewrites into (applying the not’s):

“job = ‘manager’ and salary <= 4200”

Now this is all very simple, since this is a simple rule, and you can probably come up with the CHECK constraint and the WHERE-clause without formal knowledge of the rewrite rules. But when constraints become more complex, it’s very powerfull to be able to (blindly) apply the rewrite rules to come up with alternative, logically equivalent, expressions that can be used in SQL.

Toon

There is one more thing I’d wanted to comment.

Often I see the example business rule above,

“job = ‘manager’ implies salary > 4200″

implemented as:

CHECK(job != ‘manager’ or (job = ‘manager’ and salary > 4200))

Looks familiar?

A very lengthy manner to state the business rule….

Just apply the distribution rule that distributes OR over AND, and see what you come up with. Then apply some other rewrite rules that are in table 1-11, and see what you end up with… 🙂

Hi Toon,

Thanks for taking the time to respond! It’s very helpful. I remember struggling with De Morgan at Uni, circa 1991 😉

I found it quite an insight to see later on in the book when seeing the constraints being expressed. What you write above explains it very nicely, thanks

regards,

jason.