NoSQL and SQL Data Modeling
NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software, by Ted Hills
How do we design for data when traditional design techniques cannot extend to new database technologies?
Topics
Introduction
Taking Care of Data
Plant Change Control 2.0
Where did the Savings Come From?
Why Model?
Why COMN?
Book Outline
Book Audience
NoSQL Database Developer
SQL Database Developer
Data Modeler
Software Developer
Ontologist
Part I: Real Words in the Real World
Chapter 1: It’s All about the Words
References
Chapter 2: Things: Entities, Objects, and Concepts
Chapter Glossary
Chapter 3: Containment and Composition
Containment
Composition
Chapter Glossary
Chapter 4: Types and Classes in the Real World
Collections of Objects
Sets of Concepts
Sets of Objects
Types and Classes
Types Designate Sets
Classes Describe Objects
Three Aspects of Types and Classes
Chapter Glossary
Part II: The Tyranny of Confusion
Chapter 5: Entity-Relationship Modeling
Logical E-R Data Models
Multiple Levels of Abstraction
Limitations of E-R Modeling Notation
NoSQL Arrays and Nested Data Structures
Lack of Reusable Composite Types
Lack of Place
Modeling the Real World
Representing Individual Entities
Mapping Between Models
Data in Software
Terminology
Entity
Conceptual
E-R Terms Mapped to COMN Terms
References
Chapter 6: The Unified Modeling Language
Class Diagrams
Stereotyping
Limitations of the UML
Lack of Keys
Middling Level of Abstraction
Lack of Concept
Subclassing versus Subtyping
Terminology
Relationship, Composition and Aggregation
Type and Implementation Class
UML Terms Mapped to COMN Terms
References
Chapter 7: Fact-Based Modeling Notations
Facts and Relationships
Limitations of Fact-Based Modeling
Lack of Instances
Incompleteness
Difficulty
Terminology
Fact-Based Modeling Terms Mapped to COMN Terms
References
Chapter 8: Semantic Notations
Predicates and RDF Statements
Doubles and Quadruples
OWL
Graphical Notations for Semantics
Terminology
Chapter 9: Object-Oriented Programming Languages
Classes, Objects, Types, and Variables
Terminology
Part III: Freedom in Meaning
Chapter 10: Objects and Classes
Material Objects
Objects with States
Meaning of States
Objects with More States
Even More States
Methods
Material Objects in Computers
Summary
Computer Object Defined
Composing Objects
Software Object Composition
Authorizing Certain Routines
Summary
Chapter Glossary
Chapter 11: Types in Data and Software
Types in Programming and Databases
What does a Type tell us?
Classes in Object-Oriented Software
Separating Type and Class
Simple Types
References
Chapter Glossary
Chapter 12: Composite Types
Composite Types as Logical Record Types
Types Representing Things in the Real World: Identification
Stepwise Refinement and Completeness
Types Representing Other Types
Measures as Composite Types
Nested Types
Modeling Documents
Arrays
Chapter Glossary
References
Chapter 13: Subtypes and Subclasses
Subtypes
Restriction is Subtyping
Subclasses
Subtypes and Extensions: Perfect Together
Inheritance
Using Subtype Variables and Values
Using Extending Types and Classes
Projection: The Inverse of Extension
Chapter Glossary
Chapter 14: Data and Information
Information
Is Information Always True?
From Information to Data
Data en Masse
Variable Names
Summary
Information and Data as Colloquialisms
Information En Masse
It’s Just Data
Putting it all Together
“Unstructured Data” and “Semi-Structured Data”
Data Object
Chapter Glossary
Chapter 15: Relationships and Roles
Arrivals and Departures
Labeling Relationship Lines
Cleaning up the Model
Roles, Predicates, and Relationships
Chapter Glossary
Chapter 16: The Relational Theory of Data
What is a Relation?
The Order of Rows
The Uniqueness of Rows
The Significance of Columns
Summary
Technical Relational Terminology
Tuple and Relation Schemes
Giving Data to the System
Data Attribute Versus Attribute
Relational Terminology Reprise
Composite Data Attributes
Relational Operations
NoSQL Versus the Relational Model
SQL Versus the Relational Model
Terminology
Chapter Glossary
Chapter 17: NoSQL and SQL Physical Design
What’s Different about NoSQL?
Database Performance
ACID versus BASE and Scalability
ACID
Atomicity
Consistency
Isolation
Durability
BASE and CAP
NoSQL and SQL Data Organization
Key/Value DBMS
Graph DBMS
Document DBMS
Columnar DBMS
Tabular DBMS
Summary
References
Part IV: Case Study
Chapter 18: The Common Coffee Shop
Analysis: Documenting Real-World Entities
Logical Data Modeling: Designing the Data
Physical Data Modeling: Designing the Implementation
In this era of big data and the Internet of Things, it is essential that we have the tools we need to understand the data coming to us faster than ever before, and to design databases and data processing systems that can adapt easily to ever-changing data schemas and ever-changing business requirements. There must be no intellectual disconnect between data and the software that manages it. It must be possible to extract meaning and knowledge from data to drive artificial intelligence applications. Novel NoSQL data organization techniques must be used side-by-side with traditional SQL databases. Are existing data modeling techniques ready for all of this?
The Concept and Object Modeling Notation (COMN) is able to cover the full spectrum of analysis and design. A single COMN model can represent the objects and concepts in the problem space, logical data design, and concrete NoSQL and SQL document, key-value, columnar, and relational database implementations. COMN models enable an unprecedented level of traceability of requirements to implementation. COMN models can also represent the static structure of software and the predicates that represent the patterns of meaning in databases.
This book will teach you:
- the simple and familiar graphical notation of COMN with its three basic shapes and four line styles
- how to think about objects, concepts, types, and classes in the real world, using the ordinary meanings of English words that aren’t tangled with confused techno-speak
- how to express logical data designs that are freer from implementation considerations than is possible in any other notation
- how to understand key-value, document, columnar, and table-oriented database designs in logical and physical terms
- how to use COMN to specify physical database implementations in any NoSQL or SQL database with the precision necessary for model-driven development
“I believe that this is a breakthrough modeling technique – and it is technique, not just notation. COMN provides notation to handle all of the constructs that E-R techniques don’t do well, and it steps up to the problem of linking physical and conceptual models. . . . I’m convinced that COMN is the future of data modeling.”
Dave Wells, BI and Analytics Educator and Consultant, Infocentric
About Ted
Ted Hills has been active in the Information Technology industry since 1975. Starting with microprocessor design and “bare metal” programming, Ted moved gradually up through device drivers and operating systems to communications software, applications, and finally information architecture. Experience applying his top-to-bottom understanding of data, software, and computer architecture for many companies, including AT&T Bell Laboratories, Dow Jones, Bloomberg, Merrill Lynch, and Bank of America, has given Ted a deep understanding of the needs of modern business and of how to apply theory to practice. At LexisNexis, Ted co-leads the work of establishing enterprise data architecture standards and governance processes, working with data models and business and data definitions for both structured and unstructured data. Ted has always been an active researcher, with interests in software and data integration, data modeling notations, and improving the expressivity of languages while keeping them type-safe.
Bestsellers
Faculty may request complimentary digital desk copies
Please complete all fields.