Database Reference
In-Depth Information
phone number always has the area code. If your data isn't consistent, you
(or the users of the system you design) will spend too much time trying to
figure it out and too little time leveraging it. Granted, you probably won't
spend a lot of time modeling data to be stored in a spreadsheet, but these
same kinds of things can happen in a database.
Scalability
When all is said and done, you want to build a database that the customer
can use immediately and also for the foreseeable future. No matter how
good a job you do on the data model, things change and new data becomes
available. A sound data model will provide for scaling. This means that
customers can continue to add records to the database, and the model will
not run into problems. Similarly, adding new information to existing enti-
ties should be no harder than adding an attribute (discussed later in this
chapter). In contrast, a poorly modeled database will be difficult or even
impossible to alter. Take as an example the entity in Figure 1.2 (entities are
discussed later in this chapter). This entity holds the data relating to a cus-
tomer, including the customer's address information.
F IGURE 1.2
A simple customer entity containing address data
This design works well if each customer has only a single address. In
the real world, customers have multiple addresses for work, home, vaca-
tion homes, or Grandma's house. How can we change this model to store
the extra addresses? Because of the way this model was built, the easiest
way to add the data is to add attributes (Address1, Address2, Address3), as
shown in Figure 1.3.
 
Search WWH ::




Custom Search