Technics Publications

NoSQL and SQL Data Modeling

$29.95
$39.95

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.