Book description
Data modeling is one of the most critical phases in the database application development process, but also the phase most likely to fail. A master data modeler must come into any organization, understand its data requirements, and skillfully model the data for applications that most effectively serve organizational needs.
Mastering Data Modeling is a complete guide to becoming a successful data modeler. Featuring a requirements-driven approach, this book clearly explains fundamental concepts, introduces a user-oriented data modeling notation, and describes a rigorous, step-by-step process for collecting, modeling, and documenting the kinds of data that users need.
Assuming no prior knowledge, Mastering Data Modeling sets forth several fundamental problems of data modeling, such as reconciling the software developer's demand for rigor with the users' equally valid need to speak their own (sometimes vague) natural language. In addition, it describes the good habits that help you respond to these fundamental problems. With these good habits in mind, the book describes the Logical Data Structure (LDS) notation and the process of controlled evolution by which you can create low-cost, user-approved data models that resist premature obsolescence. Also included is an encyclopedic analysis of all data shapes that you will encounter. Most notably, the book describes The Flow, a loosely scripted process by which you and the users gradually but continuously improve an LDS until it faithfully represents the information needs. Essential implementation and technology issues are also covered.
You will learn about such vital topics as:
The fundamental problems of data modeling
The good habits that help a data modeler be effective and economical
LDS notation, which encourages these good habits
How to read an LDS aloud--in declarative English sentences
How to write a well-formed (syntactically correct) LDS
How to get users to name the parts of an LDS with words from their own business vocabulary
How to visualize data for an LDS
A catalog of LDS shapes that recur throughout all data models
The Flow--the template for your conversations with users
How to document an LDS for users, data modelers, and technologists
How to map an LDS to a relational schema
How LDS differs from other notations and why
"Story interludes" appear throughout the book, illustrating real-world successes of the LDS notation and controlled evolution process. Numerous exercises help you master critical skills. In addition, two detailed, annotated sample conversations with users show you the process of controlled evolution in action.
Table of contents
- Foreword
- Preface
- Chapter 1. Introduction
- Chapter 2. Good Habits
- Chapter 3. Reading an LDS with Sentences
-
Chapter 4. Vocabulary of LDS
-
Vocabulary Overview
- Entity and Entity Instance
- Attribute and Attribute Value
- Relationship and Relationship Instance
- Link and Link Value
- Maximum Degree
- Descriptor and Descriptor Value
- Identifier and Identifier Value
- Identifying Descriptor
- Degree-One Descriptor
- Degree-Many Descriptor
- One-Many Relationship
- Many-Many Relationship
- One-One Relationship
- To-be Relationship
- Not-to-be Relationship
- Described Entity and Describing Entity
- Tiebreaker
- A Bit More About Entities, Attributes, and Relationships
- LDS Reading Rules Revisited
- Responsibility for Speaking Well
-
Summary (and a Chance to Check Your Progress)
- Using a Plural Noun for the Described Entity
- Overlooking Links
- Overlooking the Conventional Role of Identifying Descriptors
- Confusing Identifiers with Identifying Descriptors
- Overlooking the Similarity Between an Identifying Attribute and an Identifying Link
- Neglecting to Read Both Links of a Relationship
- Exercises
-
Vocabulary Overview
-
Chapter 5. Visualizing Allowed and Disallowed Instances
- Show the Data and Say Something About It
-
Plan Your Notes by Considering Elemental Parts of the LDS
- Some Notes Apply Simply Because the Diagram Includes an Attribute
- Some Notes Apply Because the Diagram Includes a Degree-One Link
- Some Notes Apply Because the Diagram Includes a Degree-Many Link
- Some Notes Apply Because the Diagram Includes a Single-Descriptor Identifier
- Some Notes Apply Because the Diagram Includes a Multiple-Descriptor Identifier
- If an Identifier Has Three or More Descriptors, the Notes Can Be More Elaborate Than the Notes for a Two-Descriptor Identifier
- As You Visualize Data, Don’t Lose Sight of the Goal
- Exercises
- Chapter 6. A Conversation with Users About Creatures and Skills
- Story Interlude
-
Chapter 7. Introduction to Mastering Shapes
- Definition of Shape
- Mastering Shapes
- Reading a Shape Aloud in Several Ways
- Visualizing Sample Data in Several Formats
- Discussing and Illustrating Noteworthy Disallowed Data
- Finding and Focusing on Shapes Within a Large LDS
- Recognizing the Differences Between Shapes That Are Similar but Not Identical
- Recognizing the Similarity Between Seemingly Dissimilar Shapes
- Distinguishing Between Legitimate Shapes and Syntactically Invalid LDS Fragments
- Knowing How Shapes Are Likely to Evolve
- Asking Questions That Help Users Choose Between Two Similar Shapes
- Knowing When to Ask Questions of Users
- Knowing When and How to Modify the LDS to Make a Shape Evolve
- Understanding the Relative Frequency of the Various Shapes
- Referring to each Fundamental Shape by Its Name
- Exercises
- Chapter 8. One-Entity, No-Relationship Shapes
- Chapter 9. One-Attribute Shapes
-
Chapter 10. Two-Entity Shapes
- Two Entities, One Relationship
- One-Many Shapes
-
One-One Shapes
- Shape: Plain One-One Relationship
- Shape: One-One Relationship Making a Subordinate Entity
- Shape: To-be One-One Relationship
- Shape: Not-to-be One-One Relationship
- Shape: To-be One-One Relationship Making a Subordinate Entity
- Shape: Plain To-be One-One Relationship
- Shape: Plain Not-to-be One-One Relationship
- Shape: Not-to-be One-One Relationship Making a Subordinate Entity
- Thinking About One-One Relationship Shapes
- Many-Many Shapes
- Two Entities, Two Relationships
- One-One and One-Many Relationship
- Two One-Many Relationships
- Two Entities, n Relationships
- Exercises
- Chapter 11. Shapes with More Than Two Entities
- Chapter 12. Shapes with Reflexive Relationships
- Story Interlude
-
Chapter 13. LDS Syntax Rules
- Within Any LDS, Each Entity, Attribute, Relationship, and Link Has an Official Name That Is Unique
- No Reflexive Relationship Is a To-be Relationship
- Between Any Pair of Entities, There Is at Most One To-be Relationship
- Each Entity Has at Least One Identifier
- An Entity Can Have Several Identifiers
- No Identifier Can Be a Strict Subset of Another
- The LDS Cannot Contain Any Cycles of Identification Dependency
- No Link of a Reflexive Relationship Can Contribute to an Identifier
- Both Links of a Relationship Cannot Contribute to Identifiers
- A Single-Descriptor Identifier Cannot Include the Degree-One Link of a One-Many Relationship
- A Multiple-Descriptor Identifier Cannot Include a Link of a One-One Relationship
- A Multiple-Descriptor Identifier Cannot Include the Degree-Many Link of a One-Many Relationship
- A Relationship Has Either Two Labels or Zero Labels
- All One-One Relationships Have Labels
- All Reflexive Relationships Have Labels
- Between Any Pair of Entities, There Is at Most One Unlabeled Relationship
- Valid Relationships
- Exercises
-
Chapter 14. Getting the Names Right
- Entity Names
-
Working with Users to Get the Entity Names Right
- Expect to Work Hard on Naming Entities
- Be Willing to Work Hard Because It’s Worth It
- Manage the Difficulty: Choose the Right Moments to Work Hard
- Manage the Difficulty: Use the Expertise at Your Disposal
- Manage the Difficulty: Teach the Users a Helpful Basic Principle
- Example: Checking a Name That You Suspect is Too Coarse
- Naming Attributes
- Naming Relationships and Links
- Exercises
- Chapter 15. Official Names
- Chapter 16. Labeling Links
- Chapter 17. Documenting an LDS
- Story Interlude
-
Chapter 18. Script for Controlled Evolution: The Flow
- Script for The Flow
- Discussing a Not-to-be Relationship
- Flow Stage: Not-to-be Relationship
- Flow Investigation: Seek a Chicken Foot
- Flow Investigation: Seek a One-Many Relationship
- Flow Investigation: Seek a Many-Many Relationship
- Flow Stage: One-One, Not-to-be Relationship
- Flow Stage: One-Many Relationship
- Flow Stages: Initial Many-Many Relationship and New Intersection Entity
- Developing a Chicken-Feet-In Shape
- Flow Investigation: Seek Descriptors for Intersection Entity
- Flow Investigation: Seek Tiebreaker
- Flow Investigation: Consider Overidentification
- Flow Investigation: Seek Independent Entity
- Discussing a To-be Relationship
- Flow Investigation: Consider Synonymy
- Flow Investigation: Consider Subordination
- Continuing the Discussion
- Flow Continuation: Seek Other Relationships
- Flow Continuation: Seek Further Evolution for a One-Many Relationship
- Flow Continuation: Seek Further Evolution for the Chicken-Feet-Across Shape
- Flow Continuation: Seek Further Evolution for the Chicken-Feet-In Shape
- Exercises
- Chapter 19. Local, Anytime Steps of Controlled Evolution
- Chapter 20. Global, Anytime Steps of Controlled Evolution
- Chapter 21. Conversations About Dairy Farming
- Story Interlude
- Chapter 22. Constraints
- Chapter 23. LDS for LDS
-
Chapter 24. Decisions: Designing a Data-Modeling Notation
- Overall Decisions
- Decisions About Entities
- Decisions About Identifiers
- Decisions About Attributes
-
Decisions About Relationships
- Are All Relationships Binary?
- Is There a Difference Between Relationships and Entities?
- Can a Relationship Have Attributes?
- Can a Relationship Have Links?
- Can a Relationship Have an ID? Must a Relationship Have an ID?
- Is There a Difference Between Relationships and Entities? Revisited
- Do Relationships Have Names?
- Should There Be Different Notations for Different Kinds of Relationships?
- Should Relationship Names Be Verbs?
- What Does a Relationship Look Like on the Diagram?
- Decisions About Links
- Decisions About Descriptors
-
Decisions About Constraints
- Should the Diagram Capture Minimum Degree?
- Should the Diagram Capture Intrainstance, Intraattribute Constraints?
- Should the Diagram Capture Intrainstance, Interattribute Constraints?
- Should the Diagram Capture Intrainstance, Intralink Constraints?
- Should the Diagram Capture Intrainstance, Interdescriptor Constraints?
- Should the Diagram Capture Triangle Relationships?
- Should the Diagram Capture Interinstance, Intradescriptor Constraints?
- Should the Diagram Capture Interinstance, Interdescriptor, Intraentity Constraints?
- Should the Diagram Capture Interinstance, Interentity Constraints?
- Summary and Final Thoughts
- Exercises
- Chapter 25. LDS and the Relational Model
- Chapter 26. Cookbook: Recipes for Data Modelers
- Story Interlude
- Appendix: Exercises for Mastery
- Index
Product information
- Title: Mastering Data Modeling: A User-Driven Approach
- Author(s):
- Release date: November 2000
- Publisher(s): Addison-Wesley Professional
- ISBN: 9780133122633
You might also like
book
Hadoop: Data Processing and Modelling
Unlock the power of your data with Hadoop 2.X ecosystem and its data warehousing techniques across …
book
Expert Data Modeling with Power BI
Manage and work with business data effectively by learning data modeling techniques and leveraging the latest …
book
The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling
This third volume of the best-selling "Data Model Resource Book" series revolutionizes the data modeling discipline …
book
Data Modeling of Financial Derivatives: A Conceptual Approach
Written in plain English and based on successful client engagements, Data Modeling of Financial Derivatives: A …