Java Reference
In-Depth Information
that are required for the particular operation are included in the update or query.
Furthermore, a denormalized model can make efficient indexing impossible.
i
BATIS
works with both denormalized models and overnormalized models. It
makes no assumptions about the granularity of your object model or database,
nor does it assume that they are the same or even remotely alike. i
BATIS
does the
best job possible of separating the object model from the relational model.
1.4.5
Skinny data models
Skinny data models are one of the most notorious and problematic abuses of rela-
tional database systems. Unfortunately, they're sometimes necessary. A skinny data
model basically turns each table into a generic data structure that can store sets of
name and value pairs, much like a properties file in Java or an old-school
INI
(ini-
tialization) file in Windows. Sometimes these tables also store metadata such as
the intended data type. This is necessary because the database only allows one
type definition for a column. To better understand a skinny data model, consider
the following example of typical address data, shown in table 1.2.
Table 1.2
Address data in typical model
ADDRESS_ID
STREET
CITY
STATE
ZIP
COUNTRY
1
123 Some Street
San Francisco
California
12345
USA
2
456 Another Street
New York
New York
54321
USA
Obviously this address data could be normalized in a better way. For example, we
could have related tables for
COUNTRY
,
STATE
and
CITY
, and
ZIP
. But this is a sim-
ple and effective design that works for a lot of applications. Unless your require-
ments are complex, this is unlikely to be a problematic design.
If we were to take this data and arrange it in a skinny table design, it would
look like table 1.3.
Table 1.3
Address data in a skinny model
ADDRESS_ID
FIELD
VALUE
1
STREET
123 Some Street
1
CITY
San Francisco
1
STATE
California
1
ZIP
12345
