Plain cooking cannot be entrusted to plain cooks.--Countess Morphy
In the past, the process of designing a database has been a task performed by information technology (IT) personnel and professional database developers. These people usually had mathematical, computer science, or systems design backgrounds and typically worked with large mainframe databases. Many of them were experienced programmers and had coded a number of database application programs consisting of thousands of lines of code. (And these people were usually very overworked due to the nature and importance of their work!)
People designing database systems at that time needed to have a solid educational background because most of the systems they created were meant to be used companywide. Even when creating databases for single departments within a company or for small businesses, database designers still required extensive formal training because of the complexity of the programming languages and database application programs that they were using. As technology advanced, however, those educational requirements evolved.
Since the mid-1980s, many software vendors have developed database software programs that run on desktop computers and can be more easily programmed to collect, store, and manage data than their mainframe counterparts. They have also produced software that allows groups of people to access and share centralized data within a variety of environments, such as client/server architectures on computers connected within local-area networks (LANs) and wide-area networks (WANs), and even via the Internet. People within a company or organization are no longer strictly dependent on mainframe databases or on having their information needs met by centralized IT departments. Over the years, vendors have added new features and enhanced the tool sets in their database software, enabling database developers to create more powerful and flexible database applications. They've also improved the ease with which the software can be used, inspiring many people to create their own database applications. Today's database software greatly simplifies the process of creating efficient database structures and intuitive user interfaces.
Most programs provide sample database structures that you can copy and alter to suit your specific needs. Although you might initially think that it would be quite advantageous for you to use these sample structures as the basis for a new database, you should stop and reconsider that move for a moment. Why? Because you could easily and unwittingly create an improper, inefficient, and incomplete design. Then you would eventually encounter problems in what you believed to be a dependable database design. This, of course, raises the question, "What types of problems would I encounter?"
Most problems that surface in a database fall into two categories: application problems and data problems. Application problems include such things as problematic data entry/edit forms, confusing menus, confusing dialog boxes, and tedious task sequences. These problems typically arise when the database developer is inexperienced, is unfamiliar with a good application-design methodology, or knows too little about the software he's using to implement the database. Problems of this nature are common and important to address, but they are beyond the scope of this work.
NOTE: One good way to solve many of your application problems is to purchase and study third-party "developer" books that cover the software you're using. Such books discuss application-design issues, advanced programming techniques, and various tips and tricks that you can use to improve and enhance an application. Armed with these new skills, you can revamp and fine-tune the database application so that it works correctly, smoothly, and efficiently.
Data problems, on the other hand, include such things as missing data, incorrect data, mismatched data, and inaccurate information. Poor database design is typically the root cause of these types of problems. A database will not fulfill an organization's information requirements if it is not structured properly. Although poor design is typically generated by a database developer who lacks knowledge of good database-design principles, it shouldn't necessarily reflect negatively on the developer. Many people, including experienced programmers and database developers, have had little or no instruction in any form of database-design methodology. Many are unaware that design methodologies even exist. Data problems and poor design are the issues that this work will address.
What's New in the Second Edition
- I revised this edition to improve readability, update or extend existing topics, add new content, and enhance its educational value. Here is a list of the changes you'll find in this edition:
- Much of the text has been rewritten to improve clarity and reader comprehension.
- Many of the figures and illustrations have been revised to improve clarity.
- New figures and illustrations have been added as warranted by revisions of or additons to existing text.
- Discussions of relational database management systems and the relational model in Chapter 1 have both been expanded to include brief content on recent technological advances and general industry direction.
- The premise behind the design methodology presented in this book is explained in Chapter 2.
- Discussion of nulls and the many-to-many relationship in Chapter 3 have both been expanded to provide greater detail on these subjects.
- Web-page-based examples are now included as appropriate in Chapter 6.
- Discussions of multivalued fields and the subset tables in Chapter 7 have both been expanded to provide greater detail
- on these subjects.
- The discussion of primary keys in Chapter 8 has been expanded to provide greater detail on this subject.
- The Field Specifications sheet has been updated and redesigned for improved flow and readability.
- The discussion of the Data Type field specification element in Chapter 9 has been expanded to include an introduction to Structured Query Language (SQL) data types.
- Discussions of self-referencing relationships and the Deny, Nullify, and Set Default deletion rules have been added to Chapter 10.
- Review questions have been added at the end of Chapters 1 through 12, and the answers to the questions appear in Appendix A.
- A flowchart of the design process has been provided as a quick reference tool and is included in Appendix B.
- All of the various design guidelines have been compiled in Appendix C.
- A glossary has been added to provide a quick reference for various terms used throughout the book.
- The accompanying CD includes files in Adobe Acrobat PDF format. These files contain the material in Appendixes B through F.
Who Should Read This Book
No previous background in database design is necessary to read this book. The reason you have this book in your hands is to learn how to design a database properly. If you're just getting into database management and you're thinking about developing your own databases, this book will be very valuable to you. It's better that you learn how to create a database properly from the beginning than that you learn by trial and error. The latter method takes much longer, believe me.
If you fall into the category of those people who have been working with database programs for a while and are ready to begin developing new databases for your company or business, you should read this book. You probably have a good feel for what a good database structure should look like, but aren't quite sure how database developers arrive at an effective design. Maybe you're a programmer who has created a number of databases following a few basic guidelines, but you have always ended up writing a lot of code to get the database to work properly. If this is the case, this book is also for you.
It would be a good idea for you to read this book even if you already have some background in database design. Perhaps you learned a design methodology back in college or attended a database class that discussed design, but your memory is vague about some details, or there were parts of the design process that you just did not completely understand. Those points with which you had difficulty will finally become clear once you learn and understand the design process presented in this book.
This book is also appropriate for those of you who are experienced database developers and programmers. Although you may already know many of the aspects of the design process that are presented here, you'll probably find that there are some elements that you've never before encountered or considered. You may even come up with fresh ideas about how to design your databases by reviewing the material in this book because many of the design processes familiar to you are presented here from a different viewpoint. At the very least, this book can serve as a great refresher course in database design.
NOTE: Those of you who have a burning desire to immerse yourselves in the depths of the database field (i.e., to learn the intricacies of database theory and design, analysis, implementation, administration, application development, and so on) should make a point of reading most of the books on my recommended reading list. Although I do not cover any of the aforementioned topics, my book does serve as the beginning of your journey into the realm of the database professional.
The Purpose of This Book
In general terms, there are three phases to the overall database-development process.
- Logical design: The first phase involves determining and defining tables and their fields, establishing primary and foreign keys, establishing table relationships, and determining and establishing the various levels of data integrity.
- Physical implementation: The second phase entails creating the tables, establishing key fields and table relationships, and using the proper tools to implement the various levels of data integrity.
- Application development: The third phase involves creating an application that allows a single user or group of users to interact with the data stored in the database. The application-development phase itself can be divided into separate processes, such as determining end-user tasks and their appropriate sequences, determining information requirements for report output, and creating a menu system for navigating the application.
You should always go through the logical design first and execute it as completely as possible. After you've created a sound structure, you can then implement it within any database software you choose. As you begin the implementation phase, you may find that you need to modify the database structure based on the pros and cons or strengths and weaknesses of the database software you've chosen. You may even decide to make structural modifications to enhance data-processing performance. Performing the logical design first ensures that you make conscious, methodical, clear, and informed decisions concerning the structure of your database. As a result, you help minimize the potential number of further structural modifications you might need to make during the physical-implementation and application-development phases.
This book deals with only the logical-design phase of the overall development process, and the book's main purpose is to explain the process of relational database design without using the advanced, orthodox methodologies found in an overwhelming majority of database-design books. I've taken care to avoid the complexities of these methodologies by presenting a relatively straightforward, commonsense approach to the design process. I also use a simple and straightforward data-modeling method as a supplement to this approach, and present the entire process as clearly as possible and with a minimum of technical jargon.
There are many database-design books out on the market that include chapters on implementing the database within a specific database product, and some books even seem to meld the design and implementation phases together. (I've never particularly agreed with the idea of combining these phases, and I've always maintained that a database developer should perform the logical-design and implementation phases separately to ensure maximum focus, effectiveness, and efficiency.) The main drawback that I've encountered with these types of books is that it can be difficult for a reader to obtain any useful or relevant information from the implementation chapters if he or she doesn't work with the particular database software or programming language that the book incorporates. It is for this reason that I decided to write a book that focuses strictly on the logical design of the database.
NOTE: I do not cover implementation issues, SQL, or application-programming issues in this work, but there are various books that I do recommend on these topics. You can review my recommendations by accessing my Web site at http://www.ForMereMortals.com.
This book should be easier to read than other books you may have encountered on the subject. Many of the database-design books on the market are highly technical and can be difficult to assimilate. I think most of these books can be confusing and overwhelming if you are not a computer science major, database theorist, or experienced database developer. The design principles you'll learn within these pages are easy to understand and remember, and the examples are common and generic enough to be relevant to a wide variety of situations.
Most people I've met in my travels around the country have told me that they just want to learn how to create a sound database structure without having to learn about normal forms or advanced mathematical theories. Many people are not as worried about implementing a structure within a specific database software as they are about learning how to optimize their data structures and how to impose data integrity. In this book, you'll learn how to create efficient database structures, how to impose several levels of data integrity, as well as how to relate tables together to obtain information in an almost infinite number of ways. Don't worry; this isn't as difficult a task as you might think. You'll be able to accomplish all of this by understanding a few key terms and by learning and using a specific set of commonsense techniques and concepts.
You'll also learn how to analyze and leverage an existing database, determine information requirements, and determine and implement business rules. These are important topics because many of you will probably inherit old databases that you'll need to revamp using what you'll learn by reading this book. They'll also be just as important when you create a new database from scratch.
When you finish reading this book, you'll have the knowledge and tools necessary to create a good relational database structure. I'm confident that this entire approach will work for a majority of developers and the databases they need to create.
How to Read This Book
I strongly recommend that you read this book in sequence from beginning to end, regardless of whether you are a novice or a professional. You'll keep everything in context this way and avoid the confusion that generally comes from being unable to see the "big picture" first. It's also a good idea to learn the process as a whole before you begin to focus on any one part.
If you are reading this book to refresh your design skills, you could read just those sections that are of interest to you. As much as possible, I've tried to write each chapter so that it could stand on its own; nonetheless, I would still recommend that you glance through each of the chapters to make sure that you're not missing any new ideas or points on design that you may not have considered up to now.
How This Book Is Organized
Here's a brief overview of what you'll find in each part and each chapter.
Part I: Relational Database Design
This section provides an introduction to databases, the idea of database design, and some of the terminology you'll need to be familiar with in order to learn and understand the design process presented in this book.
Chapter 1, The Relational Database, provides a brief discussion of the types of databases you'll encounter, common database models, and a brief history of the relational database.
Chapter 2, Design Objectives, explores why you should be concerned with design, points out the objectives and advantages of good design, and provides a brief introduction to normalization and normal forms.
Chapter 3, Terminology, covers the terms you need to know in order to learn and understand the design methodology presented in this book.
Part II: The Design Process
Each aspect of the database-design process is discussed in detail in Part II, including establishing table structures, assigning primary keys, setting field specifications, establishing table relationships, setting up views, and establishing various levels of data integrity.
Chapter 4, Conceptual Overview, provides an overview of the design process, showing you how the different components of the process fit together.
Chapter 5, Starting the Process, covers how to define a mission statement and mission objectives for the database, both of which provide you with an initial focus for creating your database.
Chapter 6, Analyzing the Current Database, covers issues concerning the existing database. We look at reasons for analyzing the current database, how to look at current methods of collecting and presenting data, why and how to conduct interviews with users and management, and how to compile initial field lists.
Chapter 7, Establishing Table Structures, covers topics such as determining and defining what subjects the database should track, associating fields with tables, and refining table structures.
Chapter 8, Keys, covers the concept of keys and their importance to the design process, as well as how to define candidate and primary keys for each table.
Chapter 9, Field Specifications, covers a topic that a number of database developers tend to minimize. Besides indicating how each field is created, field specifications determine the very nature of the values a field contains. Topics in this chapter include the importance of field specifications, types of specification characteristics, and how to define specifications for each field in the database.
Chapter 10, Table Relationships, explains the importance of table relationships, types of relationships, setting up relationships, and establishing relationship characteristics.
Chapter 11, Business Rules, covers types of business rules, determining and establishing business rules, and using validation tables. Business rules are very important in any database because they provide a distinct level of data integrity.
Chapter 12, Views, looks into the concept of views and why they are important, types of views, and how to determine and set up views.
Chapter 13, Reviewing Data Integrity, reviews each of the levels of integrity that have been defined and discussed in previous chapters. Here you learn that it's a good idea to review the final design of the database structure to ensure that you've imposed data integrity as completely as you can.
Part III: Other Database-Design Issues
This section deals with topics such as avoiding bad design and bending the rules set forth in the design process.
Chapter 14, Bad Design--What Not to Do, covers the types of designs you should avoid, such as a flat-file design and a spreadsheet design.
Chapter 15, Bending or Breaking the Rules, discusses those rare instances in which it may be necessary to stray from the techniques and concepts of the design process. This chapter tells you when you should consider bending the rules, as well as how it should be done.
Part IV: Appendixes
Appendix A, Answers to Review Questions, contains the answers to all of the review questions in Chapters 1 through 12.
Appendix B, Diagram of the Database Design Process, provides a diagram that maps the entire database design process.
Appendix C, Design Guidelines, provides an easy reference to the various sets of design guidelines that appear throughout the book.
Appendix D, Documentation Forms, provides blank copies of the Field Specifications, Business Rule Specifications, and View Specifications sheets, which you can copy and use on your database projects.
Appendix E, Database Design Diagram Symbols, contains a quick and easy reference to the diagram symbols used throughout the book.
Appendix F, Sample Designs, contains sample database designs that can serve as the basis for ideas for databases you may want or need to create.
Appendix G, Recommended Reading, provides a list of books that you should read if you are interested in pursuing an in-depth study of database technology.
Glossary contains concise definitions of various words and phrases used throughout the book.
IMPORTANT: READ THIS SECTION!
A Word About the Examples and Techniques in This Book
You'll notice that there are a wide variety of examples in this book. I've made sure that they are as generic and relevant as possible. However, you may notice that several of the examples are rather simplified, incomplete, or even on occasion incorrect. Believe it or not, I created them that way on purpose.I've created some examples with errors so that I could illustrate specific concepts and techniques. Without these examples, you wouldn't see how the concepts or techniques are put to use, as well as the results you should expect from using them. Other examples are simple because, once again, the focus is on the technique or concept and not on the example itself. For instance, there are many ways that you can design an order-tracking database. However, the structure of the sample order-tracking database I use in this book is simple because the focus is specifically on the design process, not on creating an elaborate order-tracking database system.
So what I'm really trying to emphasize here is this:
Focus on the concept or technique and its intended results, not on the example used to illustrate it.
A New Approach to Learning
Here's an approach to learning the design process (or pretty much anything else, for that matter) that I've found very useful in my database-design classes.Think of all the techniques used in the design process as a set of tools; each tool (or technique) is used for a specific purpose. The idea here is that once you learn generically how a tool is used, you can then use that tool in any number of situations. The reason you can do this is because you use the tool the same way in each situation.
Take a Crescent wrench, for example. Generically speaking, you use a Crescent wrench to fasten and unfasten a nut to a bolt. You open or close the jaw of the wrench to fit a given bolt by using the adjusting screw located on the head of the wrench. Now that you have that clear, try it out on a few bolts. Try it on the legs of an outdoor chair, or the valve cover on an engine, or the side panel of an outdoor cooling unit, or the hinge plates of an iron gate. Do you notice that regardless of where you encounter a nut and bolt, you can always fasten and unfasten the nut by using the Crescent wrench in the same manner?
The tools used to design a database work in exactly the same way. Once you understand how a tool is used generically, it will work the same way regardless of the circumstances under which it is used. For instance, consider the tool (or technique) for decomposing a field value. Say you have a single Address field in a CUSTOMERS table that contains the street address, city, state, and zip code for a given customer. You'll find it difficult to use this field in your database because it contains more than one item of data; you'll certainly have a hard time retrieving information for a particular city or sorting the information by a specific zip code.
The solution to this apparent dilemma is to decompose the Address field into smaller fields. You do this by identifying the distinct items that make up the value of the field, and then treating each item as its own separate field. That's all there is to it! This process constitutes a "tool" that you can now use on any field containing a value composed of two or more distinct data items, such as these sample fields. Figure I.1 shows the results of the decomposition process.
NOTE: You'll learn more about decomposing field values in Chapter 7, "Establishing Table Structures."
You can use all of the techniques ("tools") that are part of the design process presented in this book in the same manner. You'll be able to design a sound database structure using these techniques regardless of the type of database you need to create. Just be sure to remember this:
Focus on the concept or technique being presented and its intended results, not on the example used to illustrate it.
0201752840P02272003