Datasheet

21
Chapter 1: Relational Database Fundamentals
compatibility with the standard. Thus, whereas the SQL-92 standard
describes a purely relational database model, SQL:1999 describes an object-
relational database model. SQL:2003 has more object-oriented features, and
SQL:2008 goes even further in that direction.
In this book, I describe ISO/IEC international standard SQL. This is primarily
a relational database model. I also include the object-oriented extensions to
the standard that were introduced in SQL:1999, and the additional extensions
included in SQL:2003 and SQL:2008. The object-oriented features of the new
standard allow developers to apply SQL databases to problems that are too
complex to address with the older, purely relational, paradigm. Vendors of
DBMS systems are incorporating the object-oriented features in the ISO
standard into their products. Some of these features have been present for
years, while others are yet to be included.
Database Design Considerations
A database is a representation of a physical or conceptual structure, such as
an organization, an automobile assembly, or the performance statistics of all
the major-league baseball clubs. The accuracy of the representation depends
on the level of detail of the database design. The amount of effort that you
put into database design should depend on the type of information you want
to get out of the database. Too much detail is a waste of effort, time, and hard
drive space. Too little detail may render the database worthless.
Decide how much detail you need now and how much you may need in the
future — and then provide exactly that level of detail in your design (no more
and no less). But don’t be surprised if you have to adjust the design eventually
to meet changing real-world needs.
Today’s database management systems, complete with attractive graphical
user interfaces and intuitive design tools, can give the would-be database
designer a false sense of security. These systems make designing a database
seem comparable to building a spreadsheet or engaging in some other relatively
straightforward task. No such luck. Database design is difficult. If you do it
incorrectly, not only is your database likely to suffer from poor performance,
but it also may well become gradually more corrupt as time goes on. Often the
problem doesn’t turn up until after you devote a great deal of effort to data
entry. By the time you know that you have a problem, it’s already serious.
In many cases, the only solution is to completely redesign the database and
reenter all the data. The up side is that by the time you finish your second
version of the same database, you realize how much better you understand
database design.