Databases Reference
In-Depth Information
and at home. Subsequently, I present the same story from an alternative viewpoint of maps, which
are key/value pairs.
Using Tables and Columns in Relational Databases
In an RDBMS, attributes of an entity are stored in table columns. Columns are defi ned upfront and
values are stored in all columns for all elements or rows in the table. See Figure 4-1 to reinforce
what you probably already know well.
Columns
First
Name
Middle
Name
Last
Name
Democrat(D)/
Republican(R)
ZIP
Jolly
NULL
Goodfellow
94301
D
Happy
Nice
Guy
94401
D
Rows
John
NULL
Doe
10001
R
Jane
Lily
Chiu
10001
D
Ajay
NULL
NULL
11375
NULL
FIGURE 4-1
This elementary example has fi ve columns. When you store this table in an RDBMS, you defi ne
the data type for each column. For example, you would set the column that stores the fi rst name
to
VARCHAR
, or variable character type, and ZIP to integer (in the United States all ZIP codes are
integers). You can have some cells, intersections of rows and columns, with nonexistent values (that
is,
NULL
). For example, Jolly Goodfellow has no middle name and so the middle name column value
for this person is
NULL
.
Typically, an RDBMS table has a few columns, sometimes tens of them. The table itself would hold
at most a few thousand records. In special cases, millions of rows could potentially be held in a
relational table but keeping such large amounts of data may bring the data access to a halt, unless
special considerations like denormalization are applied.
As you begin to use your table to store and access data, you may need to alter it to hold a few
additional attributes. Such attributes could be street address and food preferences. As newer records
are stored, with values for these newer attributes, you may have null values for these attributes in
the existing records. Also, as you keep greater variety of attributes the likelihood of sparse data
