Scrapbooking Digitally or Database Design for Mere Mortals

Scrapbooking Digitally: The Ultimate Guide to Saving Your Memories Digitally with DVD

Author: Kerry Arquett

Forget about traditional scrapbooking! Throw out the scissors and glue and save your memories in a whole new way. Scrapbooking Digitally is a complete reference book for people of all ages. A step-by-step guide, Scrapbooking Digitally takes readers through every step of the scrapbooking process—from picking the right camera to working with software to learning creative tools, like altering images, typefaces, and backgrounds. It even offers inspirational sample pages and tips on how to go beyond paper to create one-of-a-kind clothing, jewelry, and home decorations. Complete with a CD of downloadable "paper" patterns and ornaments to help replicate what's on the page, this book is just what the savvy scrapbooker interested in going digital is looking for.

Look this: Cooking the RealAge Way or Paula Deen

Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design

Author: Michael J Hernandez

“This book takes the somewhat daunting process of database design and breaks it into completely manageable and understandable components. Mike’s approach whilst simple is completely professional, and I can recommend this book to any novice database designer.”

     —Sandra Barker, Lecturer, University of South Australia, Australia
“Databases are a critical infrastructure technology for information systems and today’s business. Mike Hernandez has written a literate explanation of database technology—a topic that is intricate and often obscure. If you design databases yourself, this book will educate you about pitfalls and show you what to do. If you purchase products that use a database, the book explains the technology so that you can understand what the vendor is doing and assess their products better.”

     —Michael Blaha, consultant and trainer, author of A Manager’s Guide to Database Technology
“If you told me that Mike Hernandez could improve on the first edition of Database Design for Mere Mortals I wouldn’t have believed you, but he did! The second edition is packed with more real-world examples, detailed explanations, and even includes database-design tools on the CD-ROM! This is a must-read for anyone who is even remotely interested in relational database design, from the individual who is called upon occasionally to create a useful tool at work, to the seasoned professional who wants to brush up on the fundamentals. Simply put, if you want to do it right, read this book!”

     —Matt Greer, Process Control Development, The Dow Chemical Company
“Mike’s approach to database design is totally common-sense based, yet he’s adhered to all the rules of good relational database design. I use Mike’s books in my starter database-design class, and I recommend his books to anyone who’s interested in learning how to design databases or how to write SQL queries.”

     —Michelle Poolet, President, MVDS, Inc.
“Slapping together sophisticated applications with poorly designed data will hurt you just as much now as when Mike wrote his first edition, perhaps even more. Whether you’re just getting started developing with data or are a seasoned pro; whether you've read Mike’s previous book or this is your first; whether you're happier letting someone else design your data or you love doing it yourself—this is the book for you. Mike’s ability to explain these concepts in a way that’s not only clear, but fun, continues to amaze me.”

     —From the Foreword by Ken Getz, MCW Technologies, coauthor ASP.NET Developer's JumpStart
“The first edition of Mike Hernandez’s book Database Design for Mere Mortals was one of the few books that survived the cut when I moved my office to smaller quarters. The second edition expands and improves on the original in so many ways. It is not only a good, clear read, but contains a remarkable quantity of clear, concise thinking on a very complex subject. It’s a must for anyone interested in the subject of database design.”

      —Malcolm C. Rubel, Performance Dynamics Associates
“Mike’s excellent guide to relational database design deserves a second edition. His book is an essential tool for fledgling Microsoft Access and other desktop database developers, as well as for client/server pros. I recommend it highly to all my readers.”

     —Roger Jennings, author of Special Edition Using Access 2002
“There are no silver bullets! Database technology has advanced dramatically, the newest crop of database servers perform operations faster than anyone could have imagined six years ago, but none of these technological advances will help fix a bad database design, or capture data that you forgot to include! Database Design for Mere Mortals™, Second Edition, helps you design your database right in the first place!”

     —Matt Nunn, Product Manager, SQL Server, Microsoft Corporation
“When my brother started his professional career as a developer, I gave him Mike’s book to help him understand database concepts and make real-world application of database technology. When I need a refresher on the finer points of database design, this is the book I pick up. I do not think that there is a better testimony to the value of a book than that it gets used. For this reason I have wholeheartedly recommended to my peers and students that they utilize this book in their day-to-day development tasks.”

     —Chris Kunicki, Senior Consultant, OfficeZealot.com
“Mike has always had an incredible knack for taking the most complex topics, breaking them down, and explaining them so that anyone can ‘get it.’ He has honed and polished his first very, very good edition and made it even better. If you're just starting out building database applications, this book is a must-read cover to cover. Expert designers will find Mike’s approach fresh and enlightening and a source of great material for training others.”

     —John Viescas, President, Viescas Consulting, Inc., author of Running Microsoft Access 2000 and coauthor of SQL Queries for Mere Mortals
“Whether you need to learn about relational database design in general, design a relational database, understand relational database terminology, or learn best practices for implementing a relational database, Database Design for Mere Mortals™, Second Edition, is an indispensable book that you’ll refer to often. With his many years of real-world experience designing relational databases, Michael shows you how to analyze and improve existing databases, implement keys, define table relationships and business rules, and create data views, resulting in data integrity, uniform access to data, and reduced data-entry errors.”

     —Paul Cornell, Site Editor, MSDN Office Developer Center
Sound database design can save hours of development time and ensure functionality and reliability. Database Design for Mere Mortals™, Second Edition, is a straightforward, platform-independent tutorial on the basic principles of relational database design. It provides a commonsense design methodology for developing databases that work.

Database design expert Michael J. Hernandez has expanded his best-selling first edition, maintaining its hands-on approach and accessibility while updating its coverage and including even more examples and illustrations.

This edition features a CD-ROM that includes diagrams of sample databases, as well as design guidelines, documentation forms, and examples of the database design process.

This book will give you the knowledge and tools you need to create efficient and effective relational databases.

Table of Contents:

Foreword.
Preface.
Introduction.

I. RELATIONAL DATABASE DESIGN.

1. What Is a Relational Database.
Types of Databases.
Early Database Models.
The Hierarchical Database Model.
The Network Database Model.

The Relational Database Model.
Retrieving Data.
Advantages of a Relational Database.

Relational Database Management Systems.
Beyond the Relational Model.
What the Future Holds.
A Final Note.

Summary.
Review Questions.

2. Design Objectives.
Why Should You Be Concerned with Database Design?
The Importance of Theory.
The Advantage of Learning A Good Design Methodology.
Objectives of Good Design.
Benefits of Good Design.
Database Design Methods.
Traditional Design Methods.
The Design Method Presented in This Book.

Summary.
Review Questions.

3. Terminology.
Why This Terminology Is Important.
Value-related Terms.
Data.
Information.
Null.

Structure-related Terms.
Table.
Field.
Record.
View.
Keys.
Index.

Relationship-related Terms.
Relationships.
Types of Relationships.
Types of Participation.
Degree of Participation.

Integrity-related Terms.
Field Specification.
Data Integrity.

Summary.
Review Questions.

II. THE DESIGN PROCESS.

4. Conceptual Overview.
The Importance of Completing the Design Process.
Define a Mission Statement and Mission Objectives.
Analyze the Current Database.
Create the Data Structures.
Determine and Establish Table Relationships.
Determine and Define Business Rules.
Determine and Define Views.
Review Data Integrity.
Summary.
Review Questions.

5. Starting the Process.
Conducting Interviews.
Participant Guidelines.
Interviewer Guidelines.

The Case Study: Mike's Bikes.
Defining the Mission Statement.
The Well-written Mission Statement.
Composing a Mission Statement.
Case Study.

Defining the Mission Objectives.
Well-written Mission Objectives.
Composing Mission Objectives.
Case Study.

Summary.
Review Questions.

6. Analyzing the Current Database.
Getting to Know the Current Database.
Paper-based Databases.
Legacy Databases.

Conducting the Analysis.
Looking at How Data Is Collected.
Looking at How Information Is Presented.
Conducting Interviews.
Basic Interview Techniques.
Before You Begin the Interview Process.

Interviewing Users.
Reviewing Data Type and Usage.
Reviewing the Samples.
Reviewing Information Requirements.

Interviewing Management.
Reviewing Current Information Requirements.
Reviewing Additional Information Requirements.
Reviewing Future Information Requirements.
Reviewing Overall Information Requirements.

Compiling a Complete List of Fields.
The Preliminary Field List.
The Calculated Field List.
Reviewing Both Lists with Users and Management.

Case Study.
Summary.
Review Questions.

7. Establishing Table Structures.
Defining the Preliminary Table List.
Identifying Implied Subjects.
Using the List of Subjects.
Using the Mission Objectives.

Defining the Final Table List.
Refining the Table Names.
Indicating the Table Types.
Composing the Table Descriptions.

Associating Fields with Each Table.
Refining the Fields.
Improving the Field Names.
Using the Ideal Field to Resolve Anomalies.
Resolving Mulit-part Fields.
Resolving Multi-valued Fields.

Refining the Table Structures.
A Word about Redundant Data and Duplicate Fields.
Using the Ideal Table to Refine Table Structures.
Establishing Subset Tables.

Case Study.
Summary.
Review Questions.

8. Keys.
Why Keys Are Important.
Establishing Keys for Each Table.
Candidate Keys.
Primary Keys.
Alternate Keys.
Non-keys.
Table-Level Integrity.

Reviewing the Initial Table Structures.
Case Study.
Summary.
Review Questions.

9. Field Specifications.
Why Field Specifications Are Important.
Field-Level Integrity.
Anatomy of a Field Specification.
General Elements.
Physical Elements.
Logical Elements.

Using Unique, Generic, and Replica Field Specifications.
Defining Field Specifications for Each Field in the Database.
Case Study.
Summary.
Review Questions.

10. Table Relationships.
Types of Relationships.
One-to-One Relationships.
One-to-Many Relationships.
Many-to-Many Relationships.
Self-referencing Relationships.

Identifying Existing Relationships.
Establishing Each Relationship.
One-to-One and One-to-Many Relationships.
Many-to-Many Relationships.
Self-referencing Relationships.
Reviewing the Structure of Each Table.

Refining All Foreign Keys.
Elements of a Foreign Key.

Establishing Relationship Characteristics.
Defining a Deletion Rule for Each Relationship.
Identifying the Type of Participation for Each Table.
Identifying the Degree of Participation for Each Table.
Verifying Table Relationships with Users and Management.
A Final Note.

Relationship-Level Integrity.
Case Study.
Summary.
Review Questions. Chapter 11: Business Rules.
What Are Business Rules?
Types of Business Rules.

Categories of Business Rules.
Field-specific Business Rules.
Relationship-specific Business Rules.

Defining and Establishing Business Rules.
Working with Users and Management.
Defining and Establishing Field-Specific Business Rules.
Defining and Establishing Relationship-Specific Business Rules.

Validation Tables.
What Are Validation Tables?
Using Validation Tables to Support Business Rules.

Reviewing the Business Rule Specification Sheets.
Case Study.
Summary.
Review Questions.

12. Views.
What Are Views?
Anatomy of a View.
Data View.
Aggregate View.
Validation View.

Determining and Defining Views.
Working with Users and Management.
Defining Views.
Reviewing the Documentation for Each View.

Case Study.
Summary.
Review Questions.

13. Reviewing Data Integrity.
Why You Should Review Data Integrity.
Reviewing and Refining Data Integrity.
At the Table Level.
At the Field Level.
At the Relationship Level.
At the Level of Business Rules.
At the Level of Views.

Assembling the Database Documentation.
Done at Last!
Case Study—Wrap up.
Summary.

III. OTHER DATABASE DESIGN ISSUES.

14. Bad Design—What Not To Do.
Flat-File Design.
Spreadsheet Design.
Dealing with the Spreadsheet View Mind-set.

Database Design Based on Database Software.
A Final Thought.
Summary.

15. Bending or Breaking the Rules.
When May You Bend or Break the Rules?
Designing an Analytical Database.
Improving Processing Performance.

Documenting Your Actions.
Summary.

In Closing.

IV. APPENDIXES.

Appendix A: Answers to Review Questions.
Appendix B: Diagram of the Database Design Process.
Appendix C: Design Guidelines.
Appendix D: Documentation Forms.
Appendix E: Database Design Diagram Symbols.
Appendix F: Sample Designs.
Appendix G: Recommended Reading.
Glossary.
References.
Index.

Forewords & Introductions

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 company wide. 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 changed and 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), wide are networks (WANs), and even via the Internet. People within a company or organization are no longer strictly dependenton mainframe databases or 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 could be quite advantageous for you to use these sample structures as the basis of 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, begs 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 a 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 will be addressed in this work.

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 illustration added as warranted by revisions of or additons to exisitng text.
• Discussions on Relational Database Management Systems and the Relational Model in Chapter One 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 Two.
• Discussions on nulls and the many-to-many relationship in Chapter Three have both been expanded to provide greater detail on these subjects.
• Web page-based examples are now included as appropriate in Chapter Six.
• Discussions on multi-valued fields and the subset tables in Chapter Seven have both been expanded to provide greater detail on these subjects.
• The discussion on primary keys in Chapter Eight 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 on the Data Type field specification element in Chapter Nine has been expanded to include an introduction to SQL data types.
• Discussions on self-referencing relationships and the Deny, Nullify, and Use Default deletion rules have been added to Chapter Ten.
• Review questions have been added at the end of chapters one through twelve, and the answers to the questions appear in Appendix A.
• All of the various design guidelines have been compiled together in Appendix C.
• A flowchart of the design process has been provided for use as a quick-reference tool and is included in Appendix B.
• A Glossary has been added to provide throughout the book.
• The accompanying CD includes files in Adobe Acrobat PDF format that contain the material in appendices 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 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 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 on 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 yourself in depths of the database field (i.e., learn the intricacies of database theory & design, analysis, implementation, administration, application development, etc.) 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 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 together, 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 strictly focuses 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 website and clicking on "Book Selections."

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 is 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 be able 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, What Is a 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 Two, 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.

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 have noticed 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.

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 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.

0201752840P10292002