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

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

by Michael J. Hernandez
Pub. Date:


View All Available Formats & Editions
Current price is , Original price is $54.99. You
Select a Purchase Option
  • purchase options
    $29.87 $54.99 Save 46% Current price is $29.87, Original price is $54.99. You Save 46%.
  • purchase options


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

The #1 Easy, Commonsense Guide to Database Design! Michael J. Hernandez’s best-selling Database Design for Mere Mortals® has earned worldwide respect as the clearest, simplest way to learn relational database design. Now, he’s made this hands-on, software-independent tutorial even easier, while ensuring that his design methodology is still relevant to the latest databases, applications, and best practices. Step by step, Database Design for Mere Mortals ® , Third Edition, shows you how to design databases that are soundly structured, reliable, and flexible, even in modern web applications. Hernandez guides you through everything from database planning to defining tables, fields, keys, table relationships, business rules, and views. You’ll learn practical ways to improve data integrity, how to avoid common mistakes, and when to break the rules.

Coverage includes

Understanding database types, models, and design terminology

Discovering what good database design can do for you—and why bad design can make your life miserable

Setting objectives for your database, and transforming those objectives into real designs

Analyzing a current database so you can identify ways to improve it

Establishing table structures and relationships, assigning primary keys, setting field specifications, and setting up views

Ensuring the appropriate level of data integrity for each application

Identifying and establishing business rules

Whatever relational database systems you use, Hernandez will help you design databases that are robust and trustworthy. Never designed a database before? Settling for inadequate generic designs? Running existing databases that need improvement? Start here.

Product Details

ISBN-13: 9780321884497
Publisher: Addison-Wesley
Publication date: 02/28/2013
Series: For Mere Mortals Series
Pages: 610
Sales rank: 233,859
Product dimensions: 7.20(w) x 9.00(h) x 1.50(d)

About the Author

Michael J. Hernandez, a relational database developer with more than twenty years of experience, was a program manager and product manager for Microsoft’s Visual Studio group. He has been a premier instructor with organizations such as AppDev Training Co., Focal Point, Inc., and Deep Training, and was a top-rated speaker at technical conferences across the United States, Europe, and South America. With John L. Viescas, he coauthored SQL Queries for Mere Mortals®, Second Edition (Addison-Wesley, 2008).

Read an Excerpt

Chapter 11: Business Rule

Reviewing the Business Rule Specification Sheets

Once you've established the Business Rules you believe to be appropriate, review their specification sheets. Carefully examine the specification sheet and make certain that the rule has been properly established and that all the appropriate areas on the sheet are clearly marked. If you find an error, make the necessary modifications and review it once more. Repeat this process until you've reviewed every Business Rule.

Business Rules are an important component of the database. Along with contributing to overall data integrity, Business Rules impose integrity constraints that are specific to the organization. As you've seen, these rules help to ensure the validity and consistency of the data within the context of the manner in which the organization functions or conducts its business. Furthermore, these rules will affect the manner in which the database is implemented in an RDBMS and how it works with the application program used to work with the database.

It's important to understand that you will revisit these rules quite often. As you review the final structure, for example, you may determine that additional Business Rules are necessary. You may discover that several of the rules will not provide the results you had initially envisioned, and thus they need to be modified. It's also possible to determine that some of the rules aren't necessary after all. (In this instance, be absolutely sure to examine the rules carefully before you remove them.)

Keep in mind that the Business Rules you define now are bound to require modifications in the future; you will most likely need to add Business Rules in due course because of changes in the way the organization functions or conducts its business. The need to modify existing Business Rules or develop new ones comes up naturally-the organization inevitably grows and matures, and so does the manner in which it acts upon or reacts to external forces. These forces affect the manner in which the organization perceives and uses its data, which, in turn, changes the nature of the organization's requirements in terms of Business Rules.

The task of defining and establishing Business Rules is-as are so many other tasks within the database design process-ongoing. Don't be discouraged if you have to perform this task several times. Your efforts will pay great dividends in the long run.

Case Study

Now it's time to establish Business Rules for Mike's database. You schedule a meeting with Mike and his staff to review the tables and relationships in their database. The first order of business is to define and establish field-specific Business Rules.

You begin the process by reviewing the PRODUCTS table. As you begin to examine each field, you try to determine whether any constraints are required. Upon reviewing the CATEGORY field, you remember that there was some question as to the values that could be entered into the field. (Refer to the Case Study in Chapter 9.) After some discussion with Mike and his staff, you compile a list of categories. Then Mike decides that the values for the CATEGORY field should be limited to those on this list to make certain that the staff does not arbitrarily invent new categories. Because Mike wants to limit the values that can be entered in the CATEGORY field, you define an appropriate Business Rule to properly establish the constraint. The new rule is stated as follows:

"Invalid product categories are not allowed."

Because there are a number of items in the list of possible categories, you decide that the best way to establish this rule is to create and use a CATEGORIES validation table. So you create the table and establish a relationship between it and the PRODUCTS table. After you establish the relationship, you make the appropriate settings to its characteristics. The new validation table, relationship, and its table relationship characteristics are shown in the diagram depicted in Figure 11-18.

These are the settings you've made for the table relationship characteristics:

  • There is a restrict deletion rule for the relationship.
  • The type of participation for the CATEGORIES table is set to "Mandatory."
  • The type of participation for the PRODUCTS table is set to "Optional."
  • The degree of participation for CATEGORIES is set to "(1,1)."
  • The degree of participation for PRODUCTS is set to "(O,N)."

Remember that by establishing this relationship, you've replaced the existing CATEGORY field in the PRODUCTS table with a copy of the CATEGORY ID field from the new CATEGORIES table. Because the CATEGORY ID field in the PRODUCTS table is a Foreign key, you now make certain that it conforms to the Elements of a Foreign key and make the appropriate modifications to its Field Specifications. Then you modify the Range of Values element to read "Any value within the CATEGORY ID field in the CATEGORIES table." Figure 11-19 shows the Logical Elements settings of the Field Specifications for the CATEGORY ID field in the PRODUCTS table.

Now you must decide when the rule should be tested. As you already know, you typically want to test a rule established with a validation table if the user attempts to insert a value into the field or update an existing value within the field.

Finally, you complete a Business Rule Specification sheet for this new Business Rule. This specification sheet will reflect the modifications you've made to the Field Specifications for the CATEGORY ID field as well as the characteristics of the relationship between the CATEGORIES and PRODUCTS tables...

Table of Contents

Foreword xxi

Preface xxv

Acknowledgments xxvii

Introduction xxix

Part I: Relational Database Design 1

Chapter 1: The Relational Database 3

Topics Covered in This Chapter 3

Types of Databases 4

Early Database Models 5

The Hierarchical Database Model 5

The Network Database Model 9

The Relational Database Model 12

Retrieving Data 15

Advantages of a Relational Database 16

Relational Database Management Systems 18

Beyond the Relational Model 19

What the Future Holds 21

A Final Note 22

Summary 22

Review Questions 24

Chapter 2: Design Objectives 25

Topics Covered in This Chapter 25

Why Should You Be Concerned with Database Design? 25

The Importance of Theory 27

The Advantage of Learning a Good Design Methodology 29

Objectives of Good Design 30

Benefits of Good Design 31

Database Design Methods 32

Traditional Design Methods 32

The Design Method Presented in This Book 34

Normalization 35

Summary 38

Review Questions 39

Chapter 3: Terminology 41

Topics Covered in This Chapter 41

Why This Terminology Is Important 41

Value-Related Terms 43

Data 43

Information 43

Null 45

The Value of Nulls 46

The Problem with Nulls 47

Structure-Related Terms 49

Table 49

Field 52

Record 53

View 54

Keys 56

Index 58

Relationship-Related Terms 59

Relationships 59

Types of Relationships 60

Types of Participation 65

Degree of Participation 66

Integrity-Related Terms 67

Field Specification 67

Data Integrity 68

Summary 69

Review Questions 70

Part II: The Design Process 73

Chapter 4: Conceptual Overview 75

Topics Covered in This Chapter 75

The Importance of Completing the Design Process 76

Defining a Mission Statement and Mission Objectives 77

Analyzing the Current Database 78

Creating the Data Structures 80

Determining and Establishing Table Relationships 81

Determining and Defining Business Rules 81

Determining and Defining Views 83

Reviewing Data Integrity 83

Summary 84

Review Questions 86

Chapter 5: Starting the Process 89

Topics Covered in This Chapter 89

Conducting Interviews 89

Participant Guidelines 91

Interviewer Guidelines (These Are for You) 93

The Case Study: Mike’s Bikes 98

Defining the Mission Statement 100

The Well-Written Mission Statement 100

Composing a Mission Statement 102

Defining the Mission Objectives 105

Well-Written Mission Objectives 106

Composing Mission Objectives 108

Summary 112

Review Questions 113

Chapter 6: Analyzing the Current Database 115

Topics Covered in This Chapter 115

Getting to Know the Current Database 115

Paper-Based Databases 118

Legacy Databases 119

Conducting the Analysis 121

Looking at How Data Is Collected 121

Looking at How Information Is Presented 125

Conducting Interviews 129

Basic Interview Techniques 130

Before You Begin the Interview Process . . . 137

Interviewing Users 137

Reviewing Data Type and Usage 138

Reviewing the Samples 140

Reviewing Information Requirements 144

Interviewing Management 152

Reviewing Current Information Requirements 153

Reviewing Additional Information Requirements 154

Reviewing Future Information Requirements 155

Reviewing Overall Information Requirements 155

Compiling a Complete List of Fields 157

The Preliminary Field List 157

The Calculated Field List 164

Reviewing Both Lists with Users and Management 165

Case Study 166

Summary 171

Review Questions 172

Chapter 7: Establishing Table Structures 175

Topics Covered in This Chapter 175

Defining the Preliminary Table List 176

Identifying Implied Subjects 176

Using the List of Subjects 178

Using the Mission Objectives 182

Defining the Final Table List 184

Refining the Table Names 186

Indicating the Table Types 192

Composing the Table Descriptions 192

Associating Fields with Each Table 199

Refining the Fields 202

Improving the Field Names 202

Using an Ideal Field to Resolve Anomalies 206

Resolving Multipart Fields 210

Resolving Multivalued Fields 212

Refining the Table Structures 219

A Word about Redundant Data and Duplicate Fields 219

Using an Ideal Table to Refine Table Structures 220

Establishing Subset Tables 228

Case Study 233

Summary 240

Review Questions 242

Chapter 8: Keys 243

Topics Covered in This Chapter 243

Why Keys Are Important 244

Establishing Keys for Each Table 244

Candidate Keys 245

Primary Keys 253

Alternate Keys 260

Non-keys 261

Table-Level Integrity 261

Reviewing the Initial Table Structures 261

Case Study 263

Summary 269

Review Questions 270

Chapter 9: Field Specifications 273

Topics Covered in This Chapter 273

Why Field Specifications Are Important 274

Field-Level Integrity 275

Anatomy of a Field Specification 277

General Elements 277

Physical Elements 285

Logical Elements 292

Using Unique, Generic, and Replica Field Specifications 300

Defining Field Specifications for Each Field in the Database 306

Case Study 308

Summary 310

Review Questions 311

Chapter 10: Table Relationships 313

Topics Covered in This Chapter 313

Why Relationships Are Important 314

Types of Relationships 315

One-to-One Relationships 316

One-to-Many Relationships 319

Many-to-Many Relationships 321

Self-Referencing Relationships 329

Identifying Existing Relationships 333

Establishing Each Relationship 344

One-to-One and One-to-Many Relationships 345

The Many-to-Many Relationship 352

Self-Referencing Relationships 358

Reviewing the Structure of Each Table 364

Refining All Foreign Keys 365

Elements of a Foreign Key 365

Establishing Relationship Characteristics 372

Defining a Deletion Rule for Each Relationship 372

Identifying the Type of Participation for Each Table 377

Identifying the Degree of Participation for Each Table 380

Verifying Table Relationships with Users and Management 383

A Final Note 383

Relationship-Level Integrity 384

Case Study 384

Summary 389

Review Questions 391

Chapter 11: Business Rules 393

Topics Covered in This Chapter 393

What Are Business Rules? 393

Types of Business Rules 397

Categories of Business Rules 399

Field-Specific Business Rules 399

Relationship-Specific Business Rules 401

Defining and Establishing Business Rules 402

Working with Users and Management 402

Defining and Establishing Field-Specific Business Rules 403

Defining and Establishing Relationship-Specific Business Rules 412

Validation Tables 417

What Are Validation Tables? 419

Using Validation Tables to Support Business Rules 420

Reviewing the Business Rule Specifications Sheets 425

Case Study 426

Summary 431

Review Questions 434

Chapter 12: Views 435

Topics Covered in This Chapter 435

What Are Views? 435

Anatomy of a View 437

Data View 437

Aggregate View 442

Validation View 446

Determining and Defining Views 448

Working with Users and Management 449

Defining Views 450

Reviewing the Documentation for Each View 458

Case Study 460

Summary 465

Review Questions 466

Chapter 13: Reviewing Data Integrity 469

Topics Covered in This Chapter 469

Why You Should Review Data Integrity 470

Reviewing and Refining Data Integrity 470

Table-Level Integrity 471

Field-Level Integrity 471

Relationship-Level Integrity 472

Business Rules 472

Views 473

Assembling the Database Documentation 473

Done at Last! 475

Case Study—Wrap-Up 475

Summary 476

Part III: Other Database Design Issues 477

Chapter 14: Bad Design—What Not to Do 479

Topics Covered in This Chapter 479

Flat-File Design 480

Spreadsheet Design 481

Dealing with the Spreadsheet View Mind-set 483

Database Design Based on the Database Software 485

A Final Thought 486

Summary 487

Chapter 15: Bending or Breaking the Rules 489

Topics Covered in This Chapter 489

When May You Bend or Break the Rules? 489

Designing an Analytical Database 489

Improving Processing Performance 490

Documenting Your Actions 493

Summary 495

In Closing 497

Part IV: Appendixes 499

Appendix A: Answers to Review Questions 501

Chapter 1 501

Chapter 2 502

Chapter 3 504

Chapter 4 505

Chapter 5 506

Chapter 6 508

Chapter 7 510

Chapter 8 513

Chapter 9 516

Chapter 10 518

Chapter 11 520

Chapter 12 521

Appendix B: Diagram of the Database Design Process 525

Appendix C: Design Guidelines 543

Defining and Establishing Field-Specific Business Rules 543

Defining and Establishing Relationship-Specific Business Rules 543

Elements of a Candidate Key 544

Elements of a Foreign Key 544

Elements of a Primary Key 545

Rules for Establishing a Primary Key 545

Elements of the Ideal Field 545

Elements of the Ideal Table 546

Field-Level Integrity 546

Guidelines for Composing a Field Description 547

Guidelines for Composing a Table Description 547

Guidelines for Creating Field Names 548

Guidelines for Creating Table Names 548

Identifying Relationships 549

Identifying View Requirements 549

Interview Guidelines 550

Participant Guidelines 550

Interviewer Guidelines 550

Mission Statements 551

Mission Objectives 551

Relationship-Level Integrity 551

Resolving a Multivalued Field 552

Table-Level Integrity 552

Appendix D: Documentation Forms 553

Appendix E: Database Design Diagram Symbols 557

Appendix F: Sample Designs 559

Appendix G: On Normalization 567

Please Note . . . 568

A Brief Recap 569

How Normalization Is Integrated into My Design Methodology 572

Logical Design versus Physical Design and Implementation 575

Appendix H: Recommended Reading 577

Glossary 579

References 595

Index 597


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.


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.


Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews