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.
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.
Address data in typical model
123 Some Street
456 Another Street
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.
Address data in a skinny model
123 Some Street
Search WWH ::