It has been estimated that more than 80 percent of all computer programming is database-related.
A database can be a powerful tool for doing exactly what computer programs do best:
store,
manipulate, and
display data.
Even many programs that seem at first glance to have little to do with traditional business-oriented data use databases to make processing easier.
In fact, looking back on more than 20 years of software development experience, I am hard pressed to think of a single non-trivial application that I have worked on that did not use some kind of database.
Not only do databases play a role in many applications, but they also often play a critical role. If the data is not properly stored, it may become corrupted and the program will be unable to use it meaningfully.
If the data is not properly organized, the program may be unable to find what it needs in a reasonable amount of time.
Unless the database stores its data safely and effectively, the application will be useless no matter how well-designed the rest of the system may be. The database is like the foundation of a building: without a strong foundation,
even the best crafted building will fail, sometimes spectacularly.
With such a large majority of applications relying so heavily on databases, you would expect everyone involved with application development to have a solid, formal foundation in database design and construction.
What makes a good Database Design?
Everyone including
database designers,
application architects,
programmers,
database administrators, and
project managers
should ideally understand what makes a good database design. Even an application's key customers and users could benefit from understanding how databases work. Many IT professionals have learned what they know about databases through rumor, trial-and-error, and painful experience. Over the years, some develop an intuitive feel for what makes a good database design but they may still not understand the reasons why a design is good or bad, and they may leave behind a trail of rickety,
poorly constructed programs built on shaky database foundations.
This book provides the tools you need to design a database. It explains how to determine what should go in a database and how a database should be organized to ensure data integrity and a reasonable level of performance.
It explains techniques for designing a database that is strong enough to store data safely and consistently, flexible enough to allow the application to retrieve the data it needs quickly and reliably, and adaptable enough to accommodate a realistic amount of change.
Database Modeling
1) Business objects are identified and described.
2) Business objects are grouped according to subject.
3) Databases are created for each subject area.
4) User applications are created to interact with databases