Data Modeling for Quality
Data Modeling for Quality, by Graham Witt
This book is for all data modelers, data architects, and database designers―be they novices who want to learn what’s involved in data modeling, or experienced modelers who want to brush up their skills.
Topics
Abbreviations
What is a data model?
Why develop one?
Use cases
Benefits
Everyone’s a data modeler
Users
The importance of getting it right
Notation
Why not develop the logical data model immediately?
Why not document requirements using a logical data model?
Role concepts
Persistent roles and event roles
Documenting concepts
Does a business information model need attributes?
Normalization
Functional dependency
Why are there no foreign keys?
Functional dependency on more than one attribute
Functional dependency on a relationship
Derived attributes
Composite attributes
Addresses
Documenting composite attributes
Other composite attributes
Multi-valued attributes
Independent and coupled multi-valued attributes
Sequence in a multi-valued attribute
Functional dependency and multi-valued attributes
Multi-valued composite attributes
Attribute classes
Identifier attributes
Boolean attributes
Set selection attributes
Descriptor attributes
Temporal attributes
Quantifier attributes
Media attributes
Documenting simple attribute classes
Attribute class operations
Comparisons
Arithmetic operations
Documenting relationships
Cardinality and optionality
When not to use a 1:n relationship
n:n relationships
n:n relationship or multi-valued attribute?
n:n relationship or time-variant 1:n relationship?
1:1 relationships
Recording changes in time-variant data
Recursive relationships
Derived relationships
Attributes of relationships
Documenting attributes of relationships
Subtypes with different attributes
Mutually exclusive taxonomies
Jointly exhaustive taxonomies
Subtypes with different relationships
Documenting subtypes in a data modeling tool
Attribute generalization
Attribute generalization across role entity classes
Attribute generalization across subtypes
Attribute generalization within an entity class
Relationship generalization
Hierarchy generalization
Naming entity classes
Quality criteria for entity class names
Terms with multiple meanings
What does each entity instance look like?
Terms with specialized meanings
General and specific names
Subtype names
Naming attributes
Naming relationships
Relationship names in diagrams
Using a taxonomic glossary to manage names
Why a taxonomic glossary?
What does a taxonomic glossary look like?
Entity class and attribute definitions
Entity class definitions
Quality criteria for entity class definitions
Some examples
Attribute definitions
When should data rules be documented?
Rule statements
Attribute rules
Attribute cardinality rules
Mandatory attribute rules
Conditional mandatory attribute rules
Prohibited attribute rules
Mandatory attribute group rules
Multi-valued attribute cardinality rules
Attribute content rules
Value set rules
Range rules
Attribute uniqueness
Data consistency rules
Temporal data rules
Spatio-temporal data rules
Attribute format rules
Variant and invariant attributes
Relationship rules
Cardinality and optionality
Conditional cardinality
Mandatory relationship groups
Recursive relationships
Hierarchies
Non-homogenous hierarchies
Recursive relationship rules generally
Quasi-recursive relationship pairs
Irreflexive relationship pairs
Symmetric relationship pairs
Acyclic relationship pairs
Non-transferable relationships
Uniqueness rules
Documenting data rules
Documenting attribute rules
Documenting mandatory attributes
Documenting other single-attribute rules
Documenting data consistency rules
Where to document attribute rules
Documenting relationship rules
Relationship markings in a data model diagram
Other relationship rules
Where to document relationship rules
Documenting uniqueness rules
Decision rules
Data-driven rules
Rule volatility
Decision support data
Rules that vary according to location or situation
Making sure that other data complies with rule data
Pre- and post-event rules
What should a business information model include?
What should a business information model not include?
Isn’t that just a conceptual data model?
Getting started
Selecting a data modeling tool
What tool functionality is required?
Diagramming functionality
Metadata functionality
Reporting functionality
Alternative tooling
Sourcing data requirements
Requirements specifications
Workshops
Developing the model
Data modeling in an Agile project
Data modeling in other projects
Building the initial model
Documenting assumptions and questions
Managing data model change
Renaming an entity class or attribute
Moving an attribute between entity classes
Generalizing
Documenting changes
Alternative models of the same reality
Communicating the model
Data model diagrams
Subject areas
Sharing and presentation
Describing the model verbally
Assertion templates
Entity class assertions
Attribute assertions
Relationship assertions
Attribute rule assertions
Relationship rule assertions
Uniqueness rule assertions
Completing data rule capture, analysis, and review
Generating a logical data model from a business information model
Removing derived data items
Naming tables
Naming columns
Adding primary keys
Using business information model attributes
Adding non-visible primary keys
Adding primary keys: a summary
Handling columns
Choosing DBMS data types
Columns representing identifier attributes
Columns representing Boolean attributes
Columns representing set selection attributes
Columns representing descriptor attributes
Columns representing temporal attributes
Columns representing quantifier attributes
Columns representing media attributes
Internal and external representations
Representing composite and multi-valued attributes
Handling relationships
1:n relationships
1:1 relationships
Overlapping foreign keys
n:n relationships
Nested tables
Hierarchies and acyclic relationship pairs
Handling composite attributes
Handling multi-valued attributes
Available options
Multi-valued attribute sequencing
Handling supertypes and subtypes
Handling history recording
Recording history in the system being modeled
n:n relationships
Versioning granularity
Versioning integrity
6th Normal Form
Data warehousing
Data vault
Dimensional models
Handling data rules
Rules inherited from the business information model
Attribute rules
Relationship rules
Uniqueness rules
Additional rules
Supporting programming, improving performance
Views
Denormalization
Replicating business information model changes
Implementing in a relational DBMS
Managing other data rules
Documented data rules
Relationships that are mandatory at the n end
Supertypes and subtypes
Hierarchies and acyclic relationship pairs
Updating data
Improving performance
Indexes
Other performance improvement measures
Managing security
XML data structures
XML schemas
A novice will not only gain an overview of data modeling, they will also learn how to follow the data modeling process, including the activities required for each step. The experienced practitioner will discover (or rediscover) techniques to ensure that data models accurately reflect business requirements.
This book describes rigorous yet easily implemented approaches to:
- modeling of business information requirements for review by business stakeholders before development of the logical data model
- normalizing data, based on simple questions rather than the formal definitions which many modelers find intimidating
- naming and defining concepts and attributes
- modeling of time-variant data
- documenting business rules governing both the real world and data
- data modeling in an Agile project
- managing data model change in any type of project
- transforming a business information model to a logical data model against which developers can code
- implementing the logical data model in a traditional relational DBMS, an SQL:2003-compliant DBMS, an object-relational DBMS, or in XML.
Part 1 describes business information models in-depth, including:
- the importance of modeling business information requirements before embarking on a logical data model
- business concepts (entity classes)
- attributes of business concepts
- attribute classes as an alternative to DBMS data types
- relationships between business concepts
- time-variant data
- generalization and specialization of business concepts
- naming and defining the components of the business information model
- business rules governing data, including a distinction between real-world rules and data rules.
Part 2 journeys from requirements to a working data resource, covering:
- sourcing data requirements
- developing the business information model
- communicating it to business stakeholders for review, both as diagrams and verbally
- managing data model change
- transforming the business information model into a logical data model of stored data for implementation in a relational or object-relational DBMS
- attribute value representation and data constraints (important but often overlooked)
- modeling data vault, dimensional and XML data.
About Graham
Graham first became aware of IT when, at the end of his second year at Adelaide University (South Australia), where he was majoring in Mathematics, he saw a notice advertising a 1-week Fortran course. He attended out of curiosity and was immediately captivated by the possibilities. The following year, the university introduced a 3rd year Computing course, covering such subjects as sort routines, data storage options, languages (assembler, Algol and Lisp), Turing’s work and much else. Graham now knew what he wanted to do when he grew up. However, when he graduated in 1969, the only IT jobs in Adelaide were sales positions for a well-known hardware vendor, so Graham became a secondary mathematics teacher instead.
The following year, it was clear this wasn’t his calling, but by chance while at a party, a friend of a friend mentioned that a software development centre had just been established and was hiring. That led to Graham’s first fulltime IT job, which was to code operating system and DBMS components then design and build an interpreter and compiler for a mainframe vendor. He then designed and built an early CAD system with text input and plotter output – this was before VDUs. Other system design and build work followed for various businesses and government departments, until he talked his way into a database design role for a major new system for a government department. While on that project he attended a data modeling course given by Graeme Simsion, who later offered him a data modeling consultant job. Graham soon realised that it was not enough to model data and design a database; data quality could only be maintained by rigorous application of business rules and a well-designed user interface. After co-writing Ed3 of Graeme Simsion’s Data Modeling Essentials, Graham went on to write three other books, the last two of which have been published by Technics Publications.
He has developed innovative techniques in data modelling, natural language system description and natural language business rules.
He has presented papers at conferences in Australia, the US, the UK, France and Germany, as well as meetings of DAMA (the Data Management Association) – in Australia and the US – and ACS (the Australian Computer Society). He has developed and delivered training courses in data modeling, database design and business rules, and delivered them in Australia, the US and Canada.
Graham has many other interests, including linguistics, music, and photography. He has performed with a variety of rock, folk and world music groups, mainly on bass, and has worked as a session musician on various recordings. His favorite photographic subjects are landscapes and architecture. Graham has attached some of his favorite photographs.
Bestsellers
Faculty may request complimentary digital desk copies
Please complete all fields.