Anonymous
Posted Mon Feb 14 00:00:00 EST 2005
Relational databases have a well developed theory underpinning them. Often described in formal maths language that can be offputting to a newcomer without that background. The merit of Riordan's book is to show that you can often understand and design such databases, without recourse to such formalisms, which greatly expands the potential audience for the book. There's scarcely an equation here. But you can understand the essence of different normal forms and what Boyce and Codd contributed to shoring up this field. Instead of equations, the author demonstrates what may be more intuitive to many of you - Modelling diagrams that show relationships in a visual form that is easy to grasp. You can see how a diagram can convey the essence of many relationships, and thus form the skeleton of a database. This visual understanding may be one of the most useful teaching results of the book. Riordan uses Microsoft packages to demonstrate how to make example databases. Commendably, she writes broadly enough that you should be able to recast these examples in another database if you wish.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
More About This Textbook
Overview
World-renowned expert Rebecca M. Riordan has written the definitive database design book for working developers who aren’t database experts. No matter how messy or complex your data challenge, Designing Effective Database Systems shows you how to design an effective, high-performance database to solve it.
Riordan begins by thoroughly demystifying the principles of relational design, making them accessible to every professional developer. Next, she offers the field’s clearest introduction to dimensional database modeling—practical insight for designing today’s increasingly important analytical applications.
One task at a time, the author illuminates every facet of database analysis and design for both traditional databases and the dimensional databases used for data warehousing, showing how to avoid common architectural pitfalls that complicate development and reduce extensibility. The book concludes with comprehensive, expert guidance on designing databases for maximum usability.
This book will teach you to
Riordan has helped thousands of professionals master database design and development, earning Microsoft’s coveted MVP honor for her exceptional contributions. Nobody is more qualified to help you master database design and apply it in your real-world environment.
Editorial Reviews
From Barnes & Noble
The Barnes & Noble ReviewThis book brings together more real-world wisdom about database design than we’ve ever seen in one place before. If you’re trying to design databases without formal training, it’s like winning the lottery.
Rebecca Riordan writes with wit and clarity, and experience oozes out of every paragraph. Sure, you’ll learn what normalization and entity-relationship diagrams are. But, more important, you’ll get solutions to the problems you’ll really encounter. How to capture users’ work processes. How to keep system goals and data models simple. How to provide for domain integrity, step by step. How to avoid the pitfalls of fact and dimension tables.
Riordan’s examples use Access (Jet) and SQL Server. The book will be immensely valuable even if you use Oracle, MySQL, whatever. But if you do work with Microsoft databases, you’ve just won the lottery twice. Bill Camarda, from the March 2005 Read Only
Product Details
Related Subjects
Meet the Author
Rebecca M. Riordan has more than fifteen years of experience designing and developing databases and other applications. She is a Microsoft MVP and a frequent speaker at conferences, including Microsoft TechEd. She is the author of many books, including Seeing Data: Designing User Interfaces for Database Systems Using .NET (Addison-Wesley, 2005). Her other highly respected books include Designing Relational Database Systems (1999), Microsoft SQL Server 2000 Programming Step by Step (2000), and ADO.NET Step by Step (2002), all published by Microsoft Press.
Read an Excerpt
Relational databases are tricky beasts. Other kinds of commercial software are infinitely easier to understand. Word processors are really just high-tech typewriters, and it’s pretty clear that the backspace key beats that little jar of white stuff cold. Spreadsheets present a familiar enough paradigm, even to non-accountants, and email is close enough to the postal system for the model to be comprehensible.
Databases are different. Other kinds of software have a real-world analogy. Sometimes, as in the Windows desktop, the analogy is a little tenuous, but the analogies are close enough; you can get there from here. But relational databases are completely artificial. They’re like geometry: They can be used to build models of the real world, but they don’t exist in the real world. When was the last time you poured some wine for you and your sweetie and went out on the front porch to watch the geometry frolic on the lake?
Now, I’m talking about databases here, not tables. Tables exist aplenty, from the telephone book to the dictionary. But relational databases? Nope. Uh-uh. You’re not going to find them frolicking on the lake, either. The card files at the library, which contain author, title, and subject files, come close to being a database but they’re still separate sets of data that are only correlated by the good graces of the local librarian.
This book is about designing database systems. My intention is to give you the knowledge you need to take a messy, complex, real-world situation and turn it into an effective database design. I assume that you have some development experience and generally know your way around a computer, but I don’t assume that you have any background in databases.
After reading the book you still won’t be able to watch the databases frolic on the lake, but if I’ve done my job well you’ll be able to design and implement a relational model of the fish, the seagulls, and the effects of the plankton on them both.
The book is divided into four parts. Part I, “Relational Database Theory,” covers the fundamental principles of the relational model. This is where the really ugly, theoretical stuff is. But don’t worry; it will get easier. Part II, “Dimensional Database Theory,” covers the same information for dimensional databases, a special type of relational database used for analysis. Part III, “Designing Database Systems,” examines the analysis and design process—what you should do to get from the real world to a reliable database system design. Finally, Part IV, “Designing the User Interface,” discusses the most important aspect of a database system from a user’s point of view: the user interface.
Although we’ll talk about implementation issues in the next few hundred pages, this isn’t a “how to program” book. There are a few coding examples, but I’ve kept them to a minimum, and you should be able to follow them even if you’ve never seen a programming language before. The database examples are based on the Northwind sample database that comes with Microsoft Access. (The version of Northwind that comes with SQL Server is very similar.) By the time you’re finished reading this book, you’ll have picked up most of what you need to get started building database systems, and you’ll be ready to turn to one of the sources listed in the Bibliography for the finer points of programming style. And you’ll be confident that your data architecture is sound and unlikely to get you into trouble later in your project.
A note on English usage: As you’ll discover as you read this book, I’m a stickler for terminology. But that said, I don’t think syntax ought to draw attention to itself. If an author writes “he or she” or (heavens forefend) “s/he,” I’m busy thinking about gender politics and no longer paying attention to the text. If I read “the data are,” I’m just as likely to be thinking about the nature of the English language as whatever the author is trying to say.
Now, the pronoun issue is fairly simple to work around. You’ll find a great many repetitions of “the user” in this text. But the adoption of Latin terms into English is a more complex issue, particularly in a book about data.
For the record, I had a classical education, and I’m perfectly aware that in Latin, “data” is a plural noun, and ought to take a plural verb. I’m also aware that in the field of statistics, one still refers to a “datum,” a single data point. But this isn’t statistics, and I’m not writing in Latin. In English, we have a long history of adopting plural Latin nouns as corporate nouns, and in American English, those nouns take a singular verb. It’s what we do when we speak, and it’s what I’ve done in the text.
We say “the data is reliable” not “the data are reliable.” (I have actually heard “the datums are reliable,” but that’s just sad.) This usage has been adopted by several influential publications, and I have adopted it here. Not because I don’t know how Latin works, but because I’ve carefully considered the issue and decided to write American English as I, as a well-educated native American English speaker, speak it. Now ain’t that just about enough on the subject?
0321290933P12232004
Table of Contents
Preface.
Acknowledgments.
I. RELATIONAL DATABASE THEORY.
1. Basic Concepts.
What Is a Database?
Database Tools
The Relational Model
Relational Terminology
The Data Model
Summary
2. Database Structure.
Eliminating Redundancy
Ensuring Flexibility
Basic Principles
First Normal Form
Second Normal Form
Third Normal Form
Further Normalization
Summary
3. Relationships.
Terminology
Modeling Relationships
One-to-One Relationships
One-to-Many Relationships
Many-to-Many Relationships
Unary Relationships
Ternary Relationships
Relationships of Known Cardinality
Summary
4. Data Integrity.
Integrity Constraints
Implementing Data Integrity
Summary
5. Relational Algebra.
Nulls and Three-Valued Logic (One More Time)
Relational Operations
Set Operators
Special Relational Operators
Summary
II. DIMENSIONAL DATABASE THEORY.
6. Basic Dimensional Concepts.
The Dimensional Database Model
Terminology
A Potted History of Business Intelligence
Summary
7. Fact Tables.
The Structure of a Fact Table
The Characteristics of a Fact Attribute
Summary
8. Dimension Tables.
The Structure of a Dimension Table
Snowflaking
Changing Dimensions
Summary
III. DESIGNING DATABASE SYSTEMS.
9. The Design Process.
Life Cycle Models
The Database Design Process
A Note on Design Methodologies and Standards
10. Defining the System Parameters.
Determining the System Goals
Developing the Design Criteria
Determining the System Scope
Summary
11. Defining the Work Processes.
Determining Current Work Processes
Analyzing Work Processes
Documenting Work Processes
User Scenarios
Summary
12. The Conceptual Data Model.
Identifying the Data Objects
Defining Relationships
Reviewing Entities
Domain Analysis
Restricting the Range of Values
Normalization
Summary
13. The Database Schema.
Systems Architectures
Database Schema Components
Security
Summary
14. Communicating the Design.
Audience and Purpose
Document Structure
Executive Summary
System Overview
Work Processes
Conceptual Data Model
Database Schema
User Interface
Change Management
Summary
IV. DESIGNING THE USER INTERFACE.
15. The Interface as Mediator.
Effective Interfaces
Interface Models
User Levels
Putting Users in Charge
Minimizing the Memory Load
Being Consistent
Summary
16. User Interface Architectures.
Supporting the Work Processes
Document Architectures
Summary
17. Representing Entities in Form Design.
Simple Entities
One-to-One Relationships
One-to-Many Relationships
Hierarchies
Many-to-Many Relationships
Summary
18. Choosing Windows Controls.
Representing Logical Values
Representing Sets of Values
Representing Numbers and Dates
Representing Text Values
Summary
19. Maintaining Database Integrity.
Classes of Integrity Constraints
Intrinsic Constraints
Business Constraints
Summary
20. Reporting.
Sorting, Searching, and Filtering Data
Producing Standard Reports
Producing Ad Hoc Reports
Summary
21. User Assistance.
User Levels
Passive Assistance Mechanisms
Reactive Assistance Mechanisms
Proactive Assistance
User Training
Summary
Bibliography.
Glossary.
Index.
Preface
Relational databases are tricky beasts. Other kinds of commercial software are infinitely easier to understand. Word processors are really just high-tech typewriters, and it’s pretty clear that the backspace key beats that little jar of white stuff cold. Spreadsheets present a familiar enough paradigm, even to non-accountants, and email is close enough to the postal system for the model to be comprehensible.
Databases are different. Other kinds of software have a real-world analogy. Sometimes, as in the Windows desktop, the analogy is a little tenuous, but the analogies are close enough; you can get there from here. But relational databases are completely artificial. They’re like geometry: They can be used to build models of the real world, but they don’t exist in the real world. When was the last time you poured some wine for you and your sweetie and went out on the front porch to watch the geometry frolic on the lake?
Now, I’m talking about databases here, not tables. Tables exist aplenty, from the telephone book to the dictionary. But relational databases? Nope. Uh-uh. You’re not going to find them frolicking on the lake, either. The card files at the library, which contain author, title, and subject files, come close to being a database but they’re still separate sets of data that are only correlated by the good graces of the local librarian.
This book is about designing database systems. My intention is to give you the knowledge you need to take a messy, complex, real-world situation and turn it into an effective database design. I assume that you have some development experience and generally know your way around a computer, but I don’t assume that you have any background in databases.
After reading the book you still won’t be able to watch the databases frolic on the lake, but if I’ve done my job well you’ll be able to design and implement a relational model of the fish, the seagulls, and the effects of the plankton on them both.
The book is divided into four parts. Part I, “Relational Database Theory,” covers the fundamental principles of the relational model. This is where the really ugly, theoretical stuff is. But don’t worry; it will get easier. Part II, “Dimensional Database Theory,” covers the same information for dimensional databases, a special type of relational database used for analysis. Part III, “Designing Database Systems,” examines the analysis and design process—what you should do to get from the real world to a reliable database system design. Finally, Part IV, “Designing the User Interface,” discusses the most important aspect of a database system from a user’s point of view: the user interface.
Although we’ll talk about implementation issues in the next few hundred pages, this isn’t a “how to program” book. There are a few coding examples, but I’ve kept them to a minimum, and you should be able to follow them even if you’ve never seen a programming language before. The database examples are based on the Northwind sample database that comes with Microsoft Access. (The version of Northwind that comes with SQL Server is very similar.) By the time you’re finished reading this book, you’ll have picked up most of what you need to get started building database systems, and you’ll be ready to turn to one of the sources listed in the Bibliography for the finer points of programming style. And you’ll be confident that your data architecture is sound and unlikely to get you into trouble later in your project.
A note on English usage: As you’ll discover as you read this book, I’m a stickler for terminology. But that said, I don’t think syntax ought to draw attention to itself. If an author writes “he or she” or (heavens forefend) “s/he,” I’m busy thinking about gender politics and no longer paying attention to the text. If I read “the data are,” I’m just as likely to be thinking about the nature of the English language as whatever the author is trying to say.
Now, the pronoun issue is fairly simple to work around. You’ll find a great many repetitions of “the user” in this text. But the adoption of Latin terms into English is a more complex issue, particularly in a book about data.
For the record, I had a classical education, and I’m perfectly aware that in Latin, “data” is a plural noun, and ought to take a plural verb. I’m also aware that in the field of statistics, one still refers to a “datum,” a single data point. But this isn’t statistics, and I’m not writing in Latin. In English, we have a long history of adopting plural Latin nouns as corporate nouns, and in American English, those nouns take a singular verb. It’s what we do when we speak, and it’s what I’ve done in the text.
We say “the data is reliable” not “the data are reliable.” (I have actually heard “the datums are reliable,” but that’s just sad.) This usage has been adopted by several influential publications, and I have adopted it here. Not because I don’t know how Latin works, but because I’ve carefully considered the issue and decided to write American English as I, as a well-educated native American English speaker, speak it. Now ain’t that just about enough on the subject?
0321290933P12232004