SQL and Relational Theory, 2nd Edition

HORIZONTAL DECOMPOSITION

In horizontal decomposition, the dividing lines in the decomposition are between rows (so to speak) instead of between columns. The basic motivation for such decomposition is this: We shouldn’t try to use the same table to represent two or more different predicates. For example, consider table SC again as shown in either Figure C-2 or Figure C-3. In that table, the row for supplier S1 means: Supplier S1 is located in London. By contrast, the row for supplier S2 means: We don’t know where supplier S2 is located (at any rate, let’s agree that’s what it means for the time being). So different rows correspond to different predicates, and the predicate I gave for SC earlier—Supplier SNO is located in city CITY—doesn’t in fact apply to every row.

Now, we might try a different predicate, perhaps like this (note the OR, which I’ve shown in uppercase bold for emphasis):

Supplier SNO is located in city CITY OR we don’t know where supplier SNO is located.

But this predicate doesn’t work either. If we try to instantiate it with values (or “values,” rather) from the row for supplier S2, we get:

Supplier S2 is located in city ░ OR we don’t know where supplier S2 is located.

And the first half of this sentence—Supplier S2 is located in city ░ —still makes no sense, because ░ isn’t a legitimate city name and can’t legitimately be substituted as an argument for the CITY parameter in the putative predicate. So what we need to do is break the predicate into two separate pieces, ...