Download Full Version ebookmass - Visit ebookmass.

com

NoSQL and SQL data modeling: bringing together

data, semantics, and software Hills

https://ebookmass.com/product/nosql-and-sql-data-modeling-
bringing-together-data-semantics-and-software-hills/

OR CLICK HERE

DOWLOAD NOW

Discover More Ebook - Explore Now at ebookmass.com

 Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Getting Started with SQL and Databases: Managing and

Manipulating Data with SQL Mark Simon

https://ebookmass.com/product/getting-started-with-sql-and-databases-
managing-and-manipulating-data-with-sql-mark-simon/

ebookmass.com

Getting Started with SQL and Databases: Managing and

Manipulating Data with SQL 1st Edition Mark Simon

https://ebookmass.com/product/getting-started-with-sql-and-databases-
managing-and-manipulating-data-with-sql-1st-edition-mark-simon/

ebookmass.com

Applied Data Analysis and Modeling for Energy Engineers

and Scientists

https://ebookmass.com/product/applied-data-analysis-and-modeling-for-
energy-engineers-and-scientists/

ebookmass.com

Psychoanalytic Case Formulation 1st Edition, (Ebook PDF)

https://ebookmass.com/product/psychoanalytic-case-formulation-1st-
edition-ebook-pdf/

ebookmass.com
Hope on the Range Cindi Madsen

https://ebookmass.com/product/hope-on-the-range-cindi-madsen-3/

ebookmass.com

Total Chemical Synthesis of Proteins 1st Edition Ashraf

Brik

https://ebookmass.com/product/total-chemical-synthesis-of-
proteins-1st-edition-ashraf-brik/

ebookmass.com

Civil War in Central Europe, 1918-1921: the Reconstruction

of Poland Böhler

https://ebookmass.com/product/civil-war-in-central-
europe-1918-1921-the-reconstruction-of-poland-bohler/

ebookmass.com

Psychic Whispers: Psychic Mystery Romance (Woodward Hill

Mystery Romance Book 1) Arial Burnz [Burnz

https://ebookmass.com/product/psychic-whispers-psychic-mystery-
romance-woodward-hill-mystery-romance-book-1-arial-burnz-burnz/

ebookmass.com

Sustainable Energy: Towards a Zero-Carbon Economy using

Chemistry, Electrochemistry and Catalysis Julian R.H. Ross

https://ebookmass.com/product/sustainable-energy-towards-a-zero-
carbon-economy-using-chemistry-electrochemistry-and-catalysis-julian-
r-h-ross/
ebookmass.com
Bombshell (Judgement Series Book 1) Abbi Glines

https://ebookmass.com/product/bombshell-judgement-series-book-1-abbi-
glines/

ebookmass.com
 Bringing Together
Data, Semantics, and Software

first edition

Ted Hills
Published by:

2 Lindsley Road
Basking Ridge, NJ 07920 USA
https://www.TechnicsPub.com
Cover design by John Fiorentino
Technical reviews by Laurel Shifrin, Dave Wells, and Steve Hoberman

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording or by any information storage and retrieval system, without written
permission from the publisher, except for the inclusion of brief quotations in a review.
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of
any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential
damages in connection with or arising out of the use of the information or programs contained herein.
All trade and product names are trademarks, registered trademarks, or service marks of their respective companies, and
are the property of their respective holders and should be treated as such.
Copyright © 2016 by Theodore S. Hills, [email protected]
ISBN, print ed. 9781634621090
ISBN, Kindle ed. 9781634621106
ISBN, ePub ed. 9781634621113
ISBN, PDF ed. 9781634621120
First Printing 2016
Library of Congress Control Number: 2016930173
To my wife Daphne Woods, who
has always believed in me, and
gave me the space and support
I needed to write this book.
 Contents at a Glance

Part I: Real Words in the Real World

Chapter 1: It’s All about the Words
Chapter 2: Things: Entities, Objects, and Concepts
Chapter 3: Containment and Composition
Chapter 4: Types and Classes in the Real World

Part II: The Tyranny of Confusion

Chapter 5: Entity-Relationship Modeling
Chapter 6: The Unified Modeling Language
Chapter 7: Fact-Based Modeling Notations
Chapter 8: Semantic Notations
Chapter 9: Object-Oriented Programming Languages

Part III: Freedom in Meaning

Chapter 10: Objects and Classes
Chapter 11: Types in Data and Software
Chapter 12: Composite Types
Chapter 13: Subtypes and Subclasses
Chapter 14: Data and Information
Chapter 15: Relationships and Roles
Chapter 16: The Relational Theory of Data
Chapter 17: NoSQL and SQL Physical Design
Part IV: Case Study
Chapter 18: The Common Coffee Shop

APPENDIX: COMN Quick Reference

 Table of Contents
Acknowledgements
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
Methods
Material Objects in Computers
Summary

Computer Object Defined

Composing Objects

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
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
APPENDIX COMN Quick Reference
Glossary
Photo and Illustration Credits
Index
 Acknowledgements
I am very grateful to Tony Shaw of Dataversity for giving me the opportunity to present
this new modeling notation to a wider audience, first at the NoSQL Now! conference in
San Jose in 2015, and then at the Enterprise Data World conference in San Diego in 2016.
Daniel Upton attended my workshop at the NoSQL Now! conference, and introduced me
to Steve Hoberman, data modeling enthusiast, leading author, and publisher. I met with
Steve to talk about my ideas. Steve accepted my proposal for this book, and that is how it
came into being.
The fundamental ideas behind concept and object modeling notation arose from my work
on object-oriented programming language design, and from tackling the difficult problem
of integrating objects and data. In the latter effort, I was helped tremendously by the many
writings of C. J. Date, most especially Foundations for Future Database Systems: The
Third Manifesto, Second Edition (by C. J. Date and Hugh Darwen). I had the opportunity
to correspond with and speak to Mr. Date about this topic, and this finally enabled me to
perceive the difference between data and objects. Mr. Date is not aware of the debt I owe
him for the clarity of his thinking on all things relational. One should not read this
acknowledgement as his endorsement of my ideas.
I have had the opportunity to discuss the Concept and Object Modeling Notation
(COMN), and the ideas behind it, with colleagues at LexisNexis, most notably Roger
Cass, Matthew Johnson, Michael Khatib, and Paul Rogers. They gave me the opportunity
to test my ideas and my expression of them. Roger has the additional distinctions of
having introduced me to Object Role Modeling, and of having put the “N” in COMN so
that the acronym became pronounceable as “common”. My immediate manager and
longtime friend Greg Saxton and our chief architect Ian Koenig encouraged me to pursue
this work.
My wife Daphne Woods, a brilliant novelist, long ago trained this technologist in the
mysteries of English grammar and composition. She also trained our daughter Heather
through ten years of home schooling to near perfection in these fields. Consulting with
these two during the writing of this book helped me with clarity and structure.
It was wonderful to have my colleague Laurel Shifrin, respected educator Dave Wells, and
Steve Hoberman as technical reviewers. Laurel’s knowledge of unstructured data and
Dave’s knowledge of structured data helped keep some unsupported assumptions out of
the work. Dave’s early enthusiasm for COMN has been a tremendous boost. What a
pleasure to have Steve, a leading author of data modeling books and my publisher,
encouraging and promoting this work.
Here’s to all who have struggled to tame their data. I hope you find this makes the journey
more pleasurable and more successful.
 Introduction
S am came barreling into the plant manager’s office, clutching a roll of blueprints in one
hand. He was so excited. “Joe, have I got great news!” he called out.
Joe looked up from his desk behind the office counter. He looked weary. Well, keeping
track of everything that goes on in a 150-acre refinery that processes 200,000 barrels of oil
a day could make anyone weary. He pushed back his chair, got up, and ambled over to the
counter.
“What’s the news?” Joe asked.
“The boys in engineering have figured out that, by just combining a few material flows
earlier in the process, the petrochemical plant could reduce emissions, produce more
product from the same input flows, and add $5,000 a day to the plant’s bottom line in
reduced expenses! So I’ve come down here to find out what it will take to implement
these changes.” Joe placed the rolled-up blueprints on the counter and spread them out.
Sam started studying the drawings, running his finger over the many lines and shapes that
represented the thousands of pipes visible out the office windows. He licked his finger and
pulled the top drawing back to look at the next blueprint, and then the next, all while Joe
watched excitedly but silently. Sam had a reputation. He knew his stuff. If Sam said it
could be done, it could be done, and if he said it couldn’t, well, you’d better do a ton of
research before you said Sam was wrong.
Finally Sam looked up from the counter. “I think I get it. This isn’t too bad. We’ll just
have to re-route a few pipes and this could be implemented pretty easily.”
Joe was happy and relieved. “So, how long do you think it will take?”
Sam kept his look level when he delivered the blow. “I think about six months.”
“Six months!” Joe nearly shouted. “I thought you said this was easy! Why, in six months
we will have lost”—Joe figured fast in his head—“nearly a million dollars in savings!”
“I know, but it can’t be helped,” Sam explained. “You see, although the change is easy, we
have to be really careful we don’t mess up any downstream product flows that could be
inadvertently affected by this change. And that takes time to figure out.”
“It takes six months to look at these drawings and figure out what the impact of the change
is?” Joe asked, somewhat incredulously.
Sam’s poker face began to show a little discomfort. “Well, that’s the problem,” Sam said.
“You see, the drawings engineering used weren’t up to date, so we have to check them
against the actual piping, and update them, and then look at the change request again.”
Joe wasn’t just going to accept this as the final verdict. “Why do you have to look at the
actual piping? Why not pull out the latest drawings that engineering should have used, and
compare to them?”
Sam began to turn a little red. “I’m not quite sure how to say this, but engineering did use
the latest drawings we have on file. The problem is that they don’t match what’s actually
been implemented in the plant.”
Joe felt the tension rising, and realized that now was the time to pull out all his diplomatic
skills, to avoid a confrontation that could hide the truth. He paused a moment, looked
down at the counter to collect his thoughts, put on his best “professor” demeanor, and then
looked up at Sam. “So I guess what you’re saying is that changes were made in the field,
but the drawings weren’t updated to reflect them.”
“That’s right,” Sam said quietly. “The project office doesn’t like us spending time on
drawings when we should be out in the field fixing things, and no one ever asks us for the
drawings, so we just do stuff to make the plant run better and the drawings stay in the
filing drawer.”
Joe was surprised and a bit distressed, but kept his voice level. “Interesting. What kinds of
changes do you do out in the field that don’t require engineering’s involvement?”
“We’ve got this great guy—Manny. He’s worked here for 30 years, and knows where
every pipe goes and how every fitting fits together. When something goes wrong, we call
Manny, and he usually fixes the problem and finds an improvement that the engineering
guys overlooked. So we discuss it and then implement the improvement, and everything
runs better.”
“But no one updates the drawings,” Joe said quietly.
“Well, yeah,” Sam muttered embarrassedly, looking away from Joe.
“And no one tells engineering what changed,” Joe added. Sam didn’t say anything. “Well,
Sam, thanks for explaining the situation. I’ll go back to the project office and we’ll see if
we can figure out any way to update the drawings with the current process flows in less
than six months.” Joe turned to go, but then hesitated and turned back. “Could Manny
work with the engineers to document his changes? I presume that would be faster than
having someone check every single connection.”
Sam turned white. He didn’t want to break this news. “Manny doesn’t work here
anymore.”
Joe’s shoulders slumped. “What happened to him?”
“He retired last month.”

TAKING CARE OF DATA

This sad story of plant change control gone awry, changes made in the field without
engineering involvement or approval, and a lack of any documentation about the current
state of things, will likely be all too familiar to many readers. This is often how we treat
our databases and our software. When we roll out a new system, our documentation will
be pretty good for a few months, but then, as the changes accumulate, the documentation
moves from being an asset to being overhead, and eventually even becoming a liability, as
there is a risk that someone might rely on what it says when it’s completely wrong.
This plant change control story is, of course, fictitious, and not at all representative of
what goes on in chemical plants or in most construction-based industries. Such industries
learned long ago that they need a strictly controlled process for making changes in a
physical plant. Changes can originate with an engineer, a field operator, or a product
manager, but all change requests follow the same strict process:
1. Take a copy of the strictly controlled current drawing and update it with the
requested change.
2. Obtain engineering approval for the change.
3. Implement the change according to the drawing.
4. Check when the change is complete that the drawing matches the implementation
exactly. Update the drawing if necessary to reflect the “as-built” condition of the
plant.
5. File the updated drawing as the latest, fully reliable picture of reality.
There is never any debate about whether the “overhead” of following this process is
“worth it”. Everyone knows that a mistake could lead to a fire or an explosion in a
chemical plant, a building collapse, or other possibilities we don’t even want to think
about.
Unfortunately, we’re not so smart when it comes to our data designs. If someone has a
bright idea how to make things better, then we say, sure, let’s give it a try. It might really
be a bright idea, too, but someone needs to think through the potential unintended
consequences of what an “improvement” could do to the rest of the system. But it’s really
hard to think through the potential unintended consequences when an up-to-date drawing
of a database design does not exist. Every change, even a trivial change, becomes slow,
tedious, and full of risk.
Let’s fast forward a year to how things have worked out in our fictitious petrochemical
plant.

PLANT CHANGE CONTROL 2.0

Sam was in his office, happily conversing with one of his field operators. Life was good.
Costs were down and profits were up. The Environmental Protection Agency was happy
about the recent reduction in emissions. And things didn’t seem to be breaking as often as
they used to.
Joe walked into the plant manager’s office. As soon as he saw Joe, Sam came over to
shake his hand. “How are things, Joe? Have any more brilliant money-saving ideas for
us?”
“Not today, Sam. Just thought I’d see how implementation is going on the last one.”
“Well,” Sam said, “Robbie is out there right now making a final check on the actual piping
versus the as-built drawings. As soon as he’s done that, he’ll implement the change. He’ll
be done checking today, and he’ll start the changes tomorrow.”
“Done today?” Joe exclaimed. “I thought he only started checking today.”
“That’s right.” Sam smiled. “Robbie is fast.”
“Faster than Manny,” Joe joked, and winked.
“You got that,” Sam retorted.

WHERE DID THE SAVINGS COME FROM?

You see, Robbie is a robot. Robbie is comparing the pipes and fittings he sees to an
electronic drawing that shows what they should be. If there are any differences—which
could only come about if someone deviated from the change-control process—Robbie will
report exactly what those differences are, the drawings will be updated to reflect the
changes, and engineering will be notified of a change they didn’t authorize.
It’s relatively easy to envision drawings of pipes and fittings, and the pipes and fittings
themselves. With data, it’s not so easy. Data is abstract. You can’t walk up to it and touch
it, or pick it up and move it around. Nonetheless, our databases are very much like the
pipes and fittings of a petrochemical plant. They define what the data is and how it is
interconnected. A data model gives us a way to visualize the data and its inter-
relationships. A data model is our tool to design and plan for our data before a database is
created, and to keep track of changes to the database after it’s been implemented.
It sounds a bit far-fetched—or at least a little bit futuristic—to imagine a robot looking at
pipes and fittings and comparing them to drawings, but this capability exists for the
majority of our databases today. Most database designs to this point have been
implemented using something called the Structured Query Language, or SQL. Software
tool vendors have done a superb job building so-called “data modeling tools” that enable a
person to draw a graphical design for a database at a high level of abstraction,
progressively add detail to that design (a process called stepwise refinement) until it is
detailed enough to implement, then literally “push a button” and have the tool generate the
database itself. The same tools enable a person to read the design of a database and
generate a graphical model which is an “as-built” drawing. The first process—from
drawing to implementation—is called forward engineering, and the second process—
generating a drawing from an actual implementation—is called reverse engineering. The
forward-engineered model can be compared to the reverse-engineered model in order to
ensure that they stay in sync—that no unauthorized changes have been made to the
implementation without first updating the design. This process of forward- and reverse-
engineering with comparison is called round-trip engineering. When combined with a
disciplined change-control process that makes sure every change starts with the design
drawings, the process is called model-driven development.
There are many stories of disciplined data modeling leading to faster delivery and fewer
bugs. Figure 1 below shows what happened after data modeling was introduced to the
database implementation of one agile software development project.
There are many other such stories that can and have been told, where disciplined data
modeling saved a project, and ongoing data modeling processes kept a system healthy.

Figure 1. Defects per Object Before and After Data Modeling Adopted. Courtesy of Ron Huizenga.
I have personally had positive experiences in my career with model-driven development.
It leads to many happy people:
Engineers (often referred to as “data modelers”, “data architects”, and “database
administrators” in IT projects) are happy because they know that the database they
are responsible for is truly under their control. All changes go through them, and
they can look for the far-reaching implications of what may appear to be simple
changes.
Implementers (called “software developers” and “database developers” in IT
projects) are happy because they can trust that someone thought about potential
unintended consequences before a change was made, and in fact the engineers
included them in that process.
Managers, operational personnel, marketers, sales people, and other business
stakeholders are happy because change requests are handled quickly and efficiently,
with the utmost automation possible.
Everyone is happy because the design documentation is a living, breathing thing that
is an asset to the corporation.
I have written this book for many reasons, but many of those reasons could be summed up
as my desire to see model-driven development become the norm in information
technology.
There are two barriers to this happening and this book is aimed at destroying both of them.
First, there aren’t enough people who know what data modeling is and how to use it
effectively. There needs to be a cadre of well-trained data modelers who know how to use
data modeling notations, techniques, and tools to do forward and reverse engineering of
databases. This book is intended to educate such people.
Second, existing theories of data aren’t enough. Although data modeling tools can do
forward and reverse engineering of SQL databases, there is a relatively new set of
database technologies collectively called NoSQL database management systems (DBMSs)
not yet supported by traditional tools. Some of the difficulties the data modeling tool
vendors are having adapting to these newer tools originate with defective theories of data.
This book refines our current data theories so they work just as well with NoSQL
databases as they do with SQL databases. These updated theories of data also mesh with
semantics and with software design, so that data designs can make sense as a description
of real world objects and concepts, can meet business requirements, and can guide
implementation.
Business stakeholders, software developers, and many others need to learn about the
pitfalls of poorly managed data and the advantages of model-driven development. For
them, there will be white papers, seminars, conference presentations, and more. But for
you—whether you are a seasoned data modeler or just getting started—this book will
teach you how to be the master of any data design problem that comes your way.
As the title implies, NoSQL and SQL Data Modeling teaches techniques for database
design that are applicable to both the newer NoSQL (No SQL or Not Only SQL) databases
and the traditional SQL databases. It draws connections to representations of the real
world, and of meaning (semantics) in the real world and in data. It shows how data is
represented in and manipulated by object-oriented software. It introduces the Concept and
Object Modeling Notation or COMN (pronounced “common”) for documenting data
designs.

WHY MODEL?
Creating a model is not an absolutely necessary step before implementing a database. So,
why would we want to take the time to draw up a data model at all, rather than just diving
in and creating the database and storing data? A data model describes the schema of a
database or document, but if our NoSQL DBMS is “schema-less” or “schema-free”,
meaning that we don’t need to dictate the schema to the DBMS before we start writing
data, what sense does it make to model at all?
The advantage of a schema-less DBMS is that one can start storing and accessing data
without first defining a schema. While this sounds great, and certainly facilitates a speedy
start to a data project, experience shows that a lack of forethought is usually followed by a
lot of afterthought. As data volumes grow and access times become significant, thought
needs to be given to re-organizing data in order to speed access and update, and sometimes
to change tradeoffs between the speed, consistency, and atomicity of various styles of
access. It is also commonly the case that patterns emerge in the data’s structure, and the
realization grows that, although the DBMS demands no particular data schema, much of
the data being stored has some significant schema in common.
So, some vendors say, just reorganize your data dynamically. That’s fine if the volume
isn’t too large. If a lot of data has been stored, reorganization can be costly in terms of
time and even storage space that’s temporarily needed, possibly delaying important
customers’ access to the data. And schema changes don’t just affect the data: they can
affect application code that must necessarily be written with at least a few assumptions
about the data’s schema.
A data model gives the opportunity to play with database design options on paper, on a
whiteboard, or in a drawing tool such as Microsoft Visio, before one has to worry about
the syntax of data definitions, data already stored, or application logic. It’s a great way to
think through the implications of data organization, and/or to recognize in advance
important patterns in the data, before committing to any particular design. It’s a lot easier
to redraw part of a model than to recreate a database schema, move significant quantities
of data around, and change application code.
If one is implementing in a schema-less DBMS without a model, then, after
implementation is complete, the only ways to understand the data will be to talk to a
developer or look at code. Being dependent on developers to understand the data can
severely restrict the bandwidth business people have available to propose changes and
expansions to the data, and can be a burden on developers. And although you might have
friendly developers, trying to deduce the structure of data from code can be a very
unfriendly experience. In such situations, a model might be your best hope.
Beside schema-less DBMSs, some NoSQL DBMSs support schemas. Document DBMSs
often support XML Schema, JSON Schema, or other schema languages. And, even when
not required, it is often highly desirable to enforce conformance to some schema for some
or all of the data being stored, in order to make it more likely that only valid data is stored,
and to give guarantees to application code that a certain degree of sanity is present in the
data.
And this is not all theory. I have seen first-hand the failure of projects due to a lack of a
data model or a lack of data modeling discipline. I have also seen tremendous successes
resulting from the intelligent and disciplined application of data modeling to database
designs.
Here are some stories of failure and of success:
A customer data management system was designed and developed using the latest
object-oriented software design techniques. Data objects were persisted and
reconstituted using an object/relational mapping tool. After the system was
implemented, performance was terrible, and simple queries for customer status
either couldn’t be done or were nearly impossible to implement. Almost everyone
on the project, from the manager to the lowliest developer, either left the company
or was fired, and the entire system had to be re-implemented, this time successfully
using a data model and traditional database design.
Two customer relationship management (CRM) systems were implemented. One
followed the data model closely; the other deviated from the model to “improve”
things a bit. The CRM system that deviated from the model had constant data
quality problems, because it forced operational personnel to duplicate data manually,
and of course the data that was supposed to be duplicated never quite matched. It
also required double the work to maintain the data that, in the original model, was
defined to be in only one place. In contrast, the CRM system that followed the data
model had none of these data quality or operational problems.
A major financial services firm developed a database of every kind of financial
instrument traded in every exchange around the world. The database was multi-
currency and multi-language, and kept historical records plus future-dated data for
new financial instruments that were going to start trading soon. The system was a
success from day one. A model-driven development process was used to create the
system, and to maintain it as additional financial instrument types were added, so
that all database changes started with a data modeler and a data model change.
Database change commands were generated directly from the model. The system
remained successful for its entire lifetime.
A business person requested that the name of a product be changed on a report, to
match changes in how the business was marketing its products. Because the
database underlying the report had not been designed with proper keys, the change,
which should have taken a few minutes, took several weeks.
You see, developing a data model is just like developing a blueprint for a building. If
you’re building a small building, or one that doesn’t have to last, then you can risk
skipping the drawings and going right to construction. But those projects are rare. Besides,
those simple, “one-off” projects have a tendency to outlive early expectations, to grow
beyond their original requirements, and become real problems if implemented without a
solid design. For any significant project, to achieve success and lasting value, one needs a
full data model developed and maintained as part of a model-driven development process.
If you skip the modeling process, you risk the data equivalents of painting yourself into
corners, disabling the system from adapting to changing requirements, baking in quality
problems that are hard to fix, and even complete project failure.

WHY COMN?
There are many data modeling notations already in the world. In fact, Part II of this book
surveys most of them. So why do we need one more?
COMN’s goal is to be able to describe all of the following things in a single notation:
the real world, with its objects and concepts
data about real-world objects and concepts
objects in a computer’s memory whose states represent data about real-world
objects and concepts
COMN connects concepts, real-world objects, data, and implementation in a single
notation. This makes it possible to have a single model that represents everything from the
nouns of requirements all the way down to a functional database running in a NoSQL or
SQL database management system. This gives a greater ability to trace requirements all
the way through to an implementation and make sure nothing was lost in translation along
the way. It enables changes to be similarly governed. It enables the expression of reverse-
engineered data and the development of logical and conceptual models to give it meaning.
It enables the modeling of things in the Internet of Things, in addition to modeling data
about them. No other modeling notation can express all this, and that is why COMN is
needed.

BOOK OUTLINE
The book is divided into four parts. Part I lays out foundational concepts that are
necessary for truly understanding what data is and how to think about it. It peels back the
techno-speak that dominates data modeling today, and recovers the ordinary meanings of
the English words we use when speaking of data. Do not skip part I! If you do, the rest of
the book will be meaningless to you.
Part II reviews existing data modeling, semantic, and software notations, and object-
oriented programming languages, and creates the connections between those and the
COMN defined in this book. If you are experienced with any of those notations, you
should read the relevant chapter(s) of part II. COMN uses some familiar terms in
significantly different ways, so it is critical that you learn these differences. Those
chapters about notations you are not familiar with are optional, but will serve as a handy
reference for you when dealing with others who know those notations.
Part III introduces the new way of thinking about data and semantics that is the essence of
this book and of the Concept and Object Modeling Notation. Make sure you’ve read part I
carefully before starting on Part III.
Part IV walks through a realistic data modeling example, showing how to apply COMN to
represent the real world, data design, and implementation. By the time you finish this part,
you should feel comfortable applying your COMN knowledge to problems at hand.
Each chapter ends with a summary of key points and a glossary of new terms introduced.
There is a full glossary at the end, along with a comprehensive index. In addition, an
Appendix provides a quick reference to COMN. You can download the full reference and
a Visio stencil from http://www.tewdur.com/. This will enable you to experiment with
drawing models of your own data challenges while you read this book.

BOOK AUDIENCE
Each person who picks up this book comes to it with a unique background, educational
level, and set of experiences. No book can precisely match every reader’s needs, but this
book was written with the following readers in mind in order to come as close as possible.
NoSQL Database Developer
You might be someone excited to use the newest NoSQL database management software,
but are aware of pitfalls that can hamper the performance and/or flexibility of NoSQL
database designs. You may have found that established data modeling notations, such as
E-R, fact-based, or the UML, can’t be used directly for NoSQL designs, without at least
some non-standard extensions. This book will teach you COMN, which can express your
NoSQL designs precisely enough to be used in model-driven development.
You might be surprised to find that the most difficult problems to solve in database design
are logical and not physical. Since the differences between NoSQL and SQL databases are
mostly physical and not logical, the bulk of this book is focused on enabling you to think
through the logical design of data apart from physical considerations, and then to step
through the process of physical database design while remaining faithful to the logical
design. Make sure you read part I carefully, then dig into part III and learn these
techniques. We’ll cover the differences between NoSQL and SQL in chapter 17. If you
have a software development background, you should also read chapter 9 on object-
oriented programming languages.
SQL Database Developer
You might be an experienced developer of SQL databases who always created designs
directly in SQL, or used your own informal or home-grown data modeling notation—
perhaps on a whiteboard or the back of a napkin—before you dove into specifying
primary keys, indexes, partitions, and constraints. You’re intrigued by the idea of data
modeling, or you just want to know if there’s something you’ve been missing. This book
will teach you how to think about data at a logical level, before those critical physical
design decisions come into play. Read part I carefully, then all of part III. We’ll get to the
physical issues where you’re already an expert in chapter 17.
Data Modeler
You might be an experienced data modeler, already using an E-R or fact-based modeling
notation, or the UML, to design your databases. But there are some niggling design
problems that you always felt should not be so hard to tackle. Or, you might want to fold
semantics into your data models but aren’t sure how to do that. You’ll find that learning
COMN will build on the data modeling knowledge you’ve already acquired, and expand
how far you can use that knowledge to include NoSQL databases, semantics, and some
aspects of software development. Make sure you read part I, then the relevant chapters in
part II, before you dig into part III and learn how to think differently about data and data
models. After you’ve learned COMN, you’ll find that much of the advice on data
modeling you’ve already learned is still valuable, but you’ll be able to apply it much more
effectively than before.
Software Developer
You might be a software developer who knows that there’s more to data than meets the
eye, and has decided to set aside some time to think about it. This book will help you do
just that. Make sure you read part I, then chapter 9 on object-oriented programming
languages. Chapter 9 will be especially relevant for you, as it will draw connections
between data and the object-oriented programming that you’re already familiar with. If
you design software with the Unified Modeling Language (UML), you should also read
chapter 6.
Ontologist
You’ve begun to apply semantic languages like OWL to describing the real world.
However, you find the mapping from semantics to data tedious and also incomplete. It’s
difficult to maintain a mapping between a model of real-world things and a model of data.
COMN is a tool you can use to express that mapping. Make sure you read part I carefully,
and chapter 8 on semantic notations, before continuing on to part III.

Key Points
The Concept and Object Modeling Notation (COMN, pronounced “common”) can represent data designs and their
connections to the real world, to meaning (semantics), to database implementations, and to software.
A data model is essential to any successful database design project, and helps to meet requirements, build in flexibility, and
avoid quality problems and project failure.
Everyone should read all of part I of this book.
Part II contains chapters relevant to those who already know the notations and languages discussed.
The meat of the book is in part III, but will only make sense to those who read part I and the relevant chapters of part II.
This book should deliver value to NoSQL and SQL database developers, new and experienced data modelers, software
developers, and ontologists.
 Part I
Real Words in the Real World

In designing databases and data systems, we seek to accurately represent the real world
and data about the real world. But our ability to think about the real world is hampered by
the special meanings we have attached to ordinary words, making it difficult or impossible
to reason without inadvertently carrying along the intellectual baggage of a particular
technical view of reality.
Part I of this book returns us to the ordinary English meanings of words that we have co-
opted for special purposes in the field of information technology. By the end of this
section, your mind will be refreshed to remember the way we use these words in ordinary
speech. This will prepare you to learn new, more precise meanings for these words that
will make them powerful tools in analysis and design.
 Chapter 1
It’s All about the Words

“When I use a word,” Humpty Dumpty said in

rather a scornful tone, “it means just what I
choose it to mean—neither more nor less.”
“The question is,” said Alice, “whether you
can make words mean so many different
things.”
“The question is,” said Humpty Dumpty,
“which is to be master—that’s all.”
[Carroll 1871]

We are indeed the masters of our words, and

we have the responsibility to define them.
What I call “the Humpty-Dumpty problem” is
the fact that we must define our words in
sensible ways, while not contradicting earlier
uses of the same words, nor making them
mean so many different things.
It is my belief that many of the unsolved problems in the information technology (IT) field
remain unsolved simply because our technical vocabulary is impairing our ability to speak
and reason about these problems. Our contemporary technical vocabulary often redefines
words from everyday use and from mathematics and logic in subtly different, often
confusing, and sometimes mistaken ways.
This book sets out to solve these problems by re-examining the definitions of words that
we consider to be fundamental to data modeling, semantics, and software development—
words like type, class, entity, and relationship—and by tuning them up to make them more
precise. We will not redefine these so much as we will refine them: we will make them
mean less, so to speak. When we are done with them, the meanings of these words will
overlap less, and this will empower us to think, design, and communicate more clearly
than ever before. Certain data model patterns that have always been challenging will
become tractable, and there will be less impedance when integrating data with software
and semantics.
But since we can make words mean so many things, what is to guide this refinement?
What safety measures can we appeal to so that we don’t just end up with a different
version of the soupy mix of words that we already have? My approach is to start with the
ordinary words of everyday English—the so called natural language that we all grew up
with and knew how to use long before we knew what a computer was. It is this
vocabulary, after all, from which the IT industry has borrowed to name its specialized
terms. But when we need to specialize a term, we will first judge its specialized definition
according to how well it meshes with natural language. Only then will we consider how a
term meshes with related terms and with other well-established terminology in the IT
field. We will also look for definitions that are more consistent with themselves, and more
primitive, depending on fewer external terms—therefore more precise. Finally, we will
favor definitions that are useful as building blocks, supporting higher-level definitions
based on them.
Once we can get past the assumptions built into today’s terminology, we will be able to
see clearly the solutions to today’s intellectual roadblocks. We will discover why we
struggle with certain data modeling challenges, why it is so hard to integrate object-
oriented software with databases, and why the expression of meaning is so elusive. Armed
with our new terms and understanding, we will look again at design.
Like Humpty Dumpty, folks get very defensive about their ideas of what words mean, and
don’t take kindly to others changing their meanings. But unless we can open our minds to
altering some of our terms’ definitions, to make them more precise and more meaningful,
we will be stuck without solutions to some of our most important problems. So, although
it may at first be difficult to make the shift, please open your mind to accepting new, more
precise definitions for old familiar terms. You will be amply rewarded as old problems
melt away and analysis and design become easier and more powerful.
To help you remember the new definitions, each chapter that introduces new terms
reviews their definitions at the end of the chapter. There is also a full glossary at the end of
the book. Most of the natural-language definitions we will use are drawn from Merriam-
Webster’s Online Dictionary (www.Merriam-Webster.com).
It may be easier to learn the refined definitions than you would anticipate. This book has
been carefully edited to ensure that it uses these familiar terms only in ways consistent
with their refined definitions. As a result, you should find as you read along that you’ll
gradually forget about the older, broader, fuzzier definitions of these terms. Being more
precise will become easier than returning to the less-precise notions you had before.

Key Points
Many of our modern technology terms have overlapping and imprecise meanings. This clouds our ability to reason and
communicate about design problems.
We will return to everyday English (“natural language”) to judge and refine the meanings of our terms.
After completing this refinement process, design problems that have stubbornly refused to be solved will yield to our more
precise terminology.

REFERENCES
[Carroll 1871] Carroll, Lewis. Through the Looking Glass, 1871, chapter VI. Found at
http://en.wikisource.org/wiki/Through_the_Looking-Glass,_and_What_Alice_Found_There/Chapter_VI
 Chapter 2
Things: Entities, Objects, and Concepts

The English language has at least four words related to “thing”. Consider these definitions
from Merriam-Webster:
thing : a separate and distinct individual quality, fact, idea, or usually entity
entity 2 : something that has separate and distinct existence[1] and objective or conceptual
reality
object 1a : something material that may be perceived by the senses
concept 1 : something conceived in the mind : thought, notion
I added the italics to the second half of the word “something” in the definitions above to
emphasize that the definitions of entity, object, and concept depend on the definition of
thing. You’ll also see that there is a partial circularity between the definition of “thing”
and the definition of “entity”, because each definition uses the other word.
The worlds of software development and database development have heavily overloaded
two of these words, namely the words “entity” and “object”. (They’ve avoided the word
“thing”, I think, because who would boast of being skilled at thing-relationship modeling
or thing-oriented programming?) Let’s make sure we understand what these words meant
before technologists got a hold of them.
In ordinary English, the words “thing” and “entity” are pretty much identical in meaning.
“Entity” can be thought of as the technical term for “thing”. For those who are familiar
with entity-relationship (E-R) modeling, please note how the ordinary English definition
of “entity” is completely different from the E-R definition. Those familiar with philosophy
and semantics will recognize that the word “object” is usually used in those fields to
represent the same meaning as the ordinary English meaning of “entity”.
The Merriam-Webster definition for “entity” makes a very important distinction between
two kinds of things: objective things and conceptual things.
An objective thing is something whose existence can be verified through the senses.
Things that stimulate the senses include light and sound, but there’s an important kind of
objective thing that the dictionary defines as an “object”: “something material that may be
perceived by the senses.” Something “material” is something that is made of matter. What
is matter?
At the current limits of scientific knowledge of the universe, we believe that all matter
consists of so-called elementary particles, which come in a relatively small number of
types. (See Figure 2-1.) We call them elementary because, as far as we know, they aren’t
composed of anything else. All other matter is composed of them. An electron is an
elementary particle. Protons and neutrons are composed of the elementary particles called
quarks. If a relatively fixed number of electrons, protons, and neutrons remain in a
relatively static relationship to each other—protons and neutrons bound together in a
nucleus, and electrons orbiting the nucleus—we have what we call an atom. We call atoms
that are bound to each other in certain spatial relationships molecules. Molecules can get
quite large, and can form, among other things, minerals, proteins and other raw materials
of living things, and, very simply, everything that we can see or touch.
In ordinary parlance, when enough matter in relatively static spatial relationships is
aggregated together to the point where we can see and touch it, we call the aggregate an
object. If, for instance, you looked at your desk and saw a pencil and a pen, you would say
that these were two objects on your desk—and you would be right, despite the fact that
you will sharpen the pencil and it will get shorter, and the pen will gradually run out of
ink. You have an intuitive and approximate but very useful concept of what an object is. In
fact, your idea of an object is a concept that is widely shared by many persons.
Based on these observations, we can define the object of ordinary parlance and experience
using a technique called induction. Our induction rests on two simple definitions.
1. An elementary particle of matter (that is, an electron or other lepton, or a quark) is
an object.
2. Any collection of objects in relatively static spatial arrangements to each other is an
object.
Figure 2-1. The Elementary Particles

The first definition is really just a linguistic definition. It says that we will use the term
“object” to refer to, among other things, elementary particles of matter. An electron is an
object, a quark is an object, etc.
The second definition is where the trick is. It says that objects are built from other objects.
On the surface of it, this sounds like a circular definition: where does the object begin? So
let’s take this definition apart to see how it works.
If we are going to build objects from objects, what objects can we start with? Well, in
definition number one we said that we would call the elementary particles of matter
objects, so then we can build our first objects from elementary particles. Let’s put together
three elementary particles—three quarks—to make a proton. The three quarks stick very
closely together—that’s a relatively static spatial arrangement. So a proton, built from
objects which are elementary particles, qualifies by definition number two as an object.
Next, let’s grab an electron—which is also an object because it’s an elementary particle,
too—and put it in orbit around the proton. An orbit is a relatively static spatial
arrangement, so the electron/proton combination—which happens to be a hydrogen atom
—must be an object, too.
Relax—I won’t go on constructing the universe one particle at a time! But hopefully I’ve
gone far enough that you can see how induction works. We start with our starter kit of
objects—elementary particles of matter—and from those we can build all objects,
eventually up to objects we can see and touch.
This inductive definition reflects the reality that all objects, except the elementary
particles, are built from other, simpler objects. We say that they are composite objects,
composed of other objects called components.
We’ve now covered one-half of the definition of entity. We know what objective entities
are, and, more particularly, we know what objects are. Let’s turn now to conceptual
entities: what are they?
A concept is, according to Merriam-Webster’s Online Dictionary, a thought or notion;
essentially, an idea. We know that persons have ideas, and that they exist in a person’s
brain as a configuration of neurons, their physical states, and their interconnections. We
also know that there are many ideas that are shared by persons—many ideas that are
known by the same names, understood in approximately the same way, and enable
communication. For instance, if you are reading this book and understanding even a part
of it, it is because you and I share some of the same ideas, or concepts, about what the
words I am using mean.
The interesting thing about widely shared concepts is that, unlike objects, they have no
place or time: they are not confined to a geographic location or a particular point in time,
or even to the same set of words. For instance, the concepts of the number “one”, of
numbers in general, and of counting, are understood by all human cultures, even though
people who speak different languages use different names for any given number. In light
of this, it would be wrong to say, “The number one is here and not there”, or, “The number
one began at this point in time and will go out of existence at this other point in time.”
Perhaps if our knowledge of history were perfect we could identify the point in time at
which the first person had the idea of “one” for the first time. But we don’t know history
to that degree of detail, and it’s irrelevant anyway. The only way in which the number one
would come to an end would be if all humans ceased to exist. If that happened, there
would be no one to record the event, so it would be irrelevant. We therefore treat the
number one, and similar shared concepts, as if they have no time or place, and if we are
wise we recognize that the names of concepts are just symbols that are quite separate from
the concepts they represent.
In summary, then, an entity is a thing that exists either objectively or conceptually. An
object is an objective entity that is either an elementary particle of matter or is composed
of other objects in relatively fixed spatial relationships. A conceptual entity is a concept;
essentially, an idea.
As will be explained in greater detail in subsequent chapters, the word “entity” will be
used in exactly the sense of the definition quoted above, un-overloaded, as meaning any
thing that exists, whether it is an object (whose existence can be objectively verified) or a
concept (whose existence is merely as an idea). The chapter on entity-relationship data
modeling will examine the word “entity” as it is used in that context.
The word object will also be used in exactly the sense of the definition quoted above, to
mean a material entity, in contrast to concept, which is a conceptual entity. We will
examine the meaning of object in object-oriented programming, but we’ll save that for
later.

Key Points
The word “entity” is the technical term for “thing”.
Entities come in two flavors, conceptual and objective.
Objective entities include material things called objects. All objects, except the elementary particles, are composed of other
objects.
Conceptual entities are concepts or ideas.
Unlike objects, widely shared concepts have no time or place.
We will look at overloaded technical definitions of these words in later chapters. For now, we will use their natural-
language definitions.

CHAPTER GLOSSARY
entity : something that has separate and distinct existence and objective or conceptual reality (Merriam-Webster)
object : something material that may be perceived by the senses (Merriam-Webster)
concept : something conceived in the mind : thought, notion (Merriam-Webster)
composite : made up of distinct parts (Merriam-Webster)
component : a constituent part (Merriam-Webster)
 Chapter 3
Containment and Composition

We saw in the previous chapter that all material objects, except the elementary particles,
are composed of other material objects. We’ll take a closer look at how composition
works, but first we’ll look at the idea of objects that contain other objects without being
composed of them. Once again, one of our goals is to recover the ordinary meanings of
words that have been overloaded with technical meanings.

CONTAINMENT
Suppose I go to a grocery store and buy a
dozen eggs. I carry the eggs home in a carton
that is made of Styrofoam, fiberboard, or
some other material that protects the fragile
eggs from breaking. Over the course of a
week I eat the eggs, and when the last egg is
gone I throw away the carton.
Each egg is an object—a material thing—and
the carton is an object, but they are different
kinds of objects. The carton was specially
designed to hold up to twelve eggs. The
carton is a container and the eggs are its contents. When I brought the carton home it was
full. As soon as I took the first egg out of the carton it was no longer full. Once I took the
last egg out of the carton it was empty. So the state of the container—full, partially full,
empty—varied over the course of the week. However, despite its changing state, the
composition of the carton never changed. I would never at any time say that the carton was
composed of eggs. It was composed of Styrofoam or fiberboard.
In general, a container is designed so that contents can easily be added and removed.
These operations change the state of the container, but do not change its composition—
that is, what it is made of. If I took a few eggs out of the carton and made a cake from
them, it would be correct to say that the eggs were in the cake, but not in the same sense as
being in the carton. In the cake the eggs have lost their integrity and can never be removed
from it again. Unlike the egg carton, the cake is composed of eggs, and flour and milk and
sugar and other ingredients, blended together.
Observe that containment is exclusive, in two senses. First, an egg is either in a carton or
not in a carton. It cannot be partially contained. Second, if I had another egg carton, it
would be impossible for me to have a particular egg in both cartons simultaneously.
Some containers can nest, like Russian
matryoshka dolls. Each container can
contain, not only whatever fits, but also
another, smaller container, which can
contain another smaller container, and so
on. With nesting containers, it is possible to
say that something in a smaller container is
also in the larger container that contains the
smaller container, but the contents of the
smaller container are not in the large
container directly. An object can only be
directly in one container at a time. If the
carton of eggs is in a grocery bag, we can
say that the eggs are in the bag, but it is more complete to say that the eggs are in the
carton in the bag.
Suppose I bring home the dozen eggs from the grocery store, in their protective container,
but my refrigerator is so full that I cannot fit the carton of eggs inside. To solve the
problem, I remove the eggs from the carton, tuck each of the twelve eggs into little spaces
that can accommodate an egg-sized object, and throw the carton away. Even though I have
destroyed the container, the twelve eggs continue to exist in the refrigerator. This shows
that, in ordinary parlance, a container and its contents can exist independently.

COMPOSITION
We saw in the previous section that containment is not composition; that is, a container is
not composed of its contents. We also saw one kind of composition, where a cake is
composed of its ingredients blended together in such a way that they can’t be separated
again. There are a few more modes of composition—ways in which objects can be
composed of smaller objects—that are relevant to our ultimate purpose of representing
data, software, and semantics.
Remember that an object is composed of other
objects in some kind of relatively static spatial
relationship. Certainly a cake is an object, because
it is composed of eggs, milk, flour, sugar, and other
objects in a relatively static spatial relationship:
they are all blended together and will remain that
way until the cake is consumed.
Now let’s think about a frosted cake. Frosting is
applied to the top of the cake and between the
layers. This isn’t quite blending, because the
integrity of the cake and the frosting is still
preserved. You can still see the difference between
them, though it would be difficult to separate them once again. This kind of object
composition is called aggregation. An object is formed from other objects in a way that
the components keep their integrity, but it would be difficult to extract the components
after they’ve been joined together.
For those who know the UML, please note that, in ordinary English and in COMN,
composition is the over-arching term, and aggregation is one particular kind of
composition. Likewise, a component is that which is part of any kind of a composite.
For those who are familiar with dimensional modeling, please note that what is called
aggregation in that discipline is blending in ordinary English and in COMN.
In contrast to aggregation, we can have
assembly. This is a mode of composition where
components retain their integrity and can even
be removed from the object which they
compose, if so desired. A real-world example of
an assembly is an engine. Its parts are connected
with screws and other connectors that can be
disconnected and reconnected at will.
Another

important mode of composition is juxtaposition,

where objects are arranged in a fixed spatial
relationship to each other without being blended
and without being connected to each other. For
instance, dinner plates and silverware are
juxtaposed on a dining table to form a place
setting.
Regardless of the mode of composition, we call the objects of which another object is
composed its components. So, the components of a (blended) cake are its ingredients, the
components of a layer cake are alternating layers of cake and frosting, the components of
an engine include pistons, spark plugs, valves, the block, etc., and the components of a
place setting include dishes, silverware, and glasses.
Components are not contents. For instance, the engine assembly, which is composed of
many components, will eventually contain gasoline, but we would never say that the
engine is composed of gasoline. The soup bowl will eventually contain soup, but we
would never say that the place setting is composed of soup.
In any given real-world object, it is likely that many modes of composition are present at
once. For example, one of the components of an engine assembly is a spark plug. A spark
plug is an aggregation of ceramic and metal parts joined together such that one can see the
different parts but one cannot separate them (without destroying the spark plug and its
parts).

Key Points
 A container is an object that can hold other objects in such a way that they can be easily added to and removed from the
container.
Adding objects to and removing objects from a container changes the container’s state but not its composition. We never
say that a container is composed of its contents.
Containment is exclusive. An object can only be in one container at a time, and is either entirely in or entirely out of the
container.
Containers can nest: A container may contain another container.
All objects, except the elementary particles, are composed of other objects.
Four modes of composition important to us are:
juxtaposition
blending
aggregation
assembly
In any given real-world object, it is likely that many modes of composition are present at once.

CHAPTER GLOSSARY
container : an object that can contain other objects (like an egg carton)
contents : the objects inside a container (like the eggs in an egg carton)
juxtaposition : arranging objects in a fixed spatial relationship without connecting them (like a place setting)
blending : combining two or more objects in such a way that they lose their integrity (like eggs, flour, milk, and sugar in
a cake)
aggregation : combining two or more objects in such a way that they retain their integrity, but it is difficult or
impossible to separate them again (like a layer cake)
assembly : combining two or more objects in such a way that they retain their integrity, and it is relatively easy to
separate them again (like an engine)
 Chapter 4
Types and Classes in the Real World

In this chapter we will examine some of the most fundamental concepts that are essential
to the tasks of data modeling and implementation. Once again, we’ll endeavor to recover
the ordinary, non-technical meanings of some words that have become fuzzy technical
terms.

COLLECTIONS OF OBJECTS
Art museums usually contain paintings. Based on the previous chapter, we can recognize
that a museum is a container, and the paintings are its contents.
Art museum curators often speak of
their collections of paintings. For
example, an art museum may say
that it has a collection of Monet
paintings, a collection of Morisot
paintings, and a collection of
Renoir paintings. Unlike containers
and their contents, collections are
not so strictly tied to physical
relationships. Let’s see how this
works.
It is common in the art world for
museums to share their collections
with each other, as a benefit to the art world and the public at large. For example, suppose
there is an art museum on the East Coast of the United States that has a wonderful
collection of oil paintings by the French impressionist Monet. This East Coast museum
will package up part of its collection of Monet paintings and send them to a museum on
the West Coast, for display there for some months, before they are shipped back to the
museum that owns the collection.
Now, while those paintings are on the West Coast, they are still considered part of the
collection belonging to the East Coast museum, even though they are not physically
contained in that museum. So we can see that a collection can exist inside or outside any
particular container.
The paintings on loan to the West Coast museum might be displayed side-by-side with
paintings belonging to the West Coast museum, but they would never be considered to be
part of any collection of the West Coast museum. The East Coast museum always owns its
collection, no matter where the members of that collection might be. This is evidence that
our concept of collection, like our concept of containment, involves exclusivity. We often
describe this exclusivity in terms of ownership. Something owned by one person or group
is not owned by any other person or group. Something that is a member of one collection
may not also be a member of another collection—except transitively: a collection may
belong to another collection.
We can see from this example that the objects belonging to a collection may or may not be
in the same container at any one time. Although a container, being an object, always has
but one location at any one time, a collection of objects is not necessarily localized. This
gives us a clue that, while a container is an object, a collection is not an object; a
collection is merely a concept.
Our hypothetical East Coast art museum has paintings and other drawings of many types,
including oil paintings, watercolors, charcoal and pencil sketches, pastels, and engravings.
The paintings can have many subjects, including landscapes, still-lifes, and portraits. The
museum curators often speak of the paintings in their collection according to any of these
characteristics, and will call these collections, too. A painting by Monet might be a
landscape and an oil painting, so that, when a curator speaks of “our Monet collection,”
“our collection of landscapes,” and “our collection of oil paintings,” the oil landscape by
Monet is included every time. Thus, we can see that, in ordinary English, an object can be
in multiple collections at the same time, provided that all of the collections have the same
owner.

SETS OF CONCEPTS
We have seen that a collection is conceptual, even when the members of the collection are
objects. It is also possible to have a collection of concepts. In such a case, both the
collection and its members are conceptual. However, we don’t usually use the word
“collection” in connection with concepts. We will usually say that we have a set of
concepts.
We know that numbers are concepts. Mathematicians have a special notation that they’ve
developed just so that they can talk about sets of numbers (and other things). It is called
set notation. Very simply, a list of numbers is enclosed in curly braces, as in
{1, 2, 3}
The whole expression is called a set. The set just given consists of the numbers one, two,
and three.
One of the interesting things about sets of conceptual entities, such as sets of numbers, is
that you can destroy the set notation that describes the set, but that doesn’t destroy the set
itself, nor its members. A set of numbers, and the numbers themselves, don’t exist just
because they are written down. This is in contrast to collections of objects. A collection of
objects can be destroyed in a number of ways:
The objects themselves can be destroyed.
The collection can be destroyed by ceasing to consider it as existing. For instance,
 the East Coast art museum might give away all of its Monet paintings to other
museums. The paintings continue to exist, but the collection is destroyed.
Membership of concepts in sets is not exclusive. A single concept can be in multiple sets
at the same time. Consider as an example the number 2. It is in all these sets
simultaneously:
the set of natural numbers
the set of integers
the set of even numbers
the set of prime numbers
In fact, we could go on inventing sets ad infinitum for 2 to be part of.
Although membership in a set is not exclusive, two sets can be exclusive of each other.
For example, the set of even numbers is exclusive of the set of odd numbers. Any given
integer is a member of only one of those two sets. But, as we have seen, an integer can be
a member of many non-exclusive sets at the same time.

SETS OF OBJECTS
We have covered collections of objects and sets of concepts. We don’t generally speak of
collections of concepts. But we can speak of sets of objects. A set of objects is very similar
to a collection of objects, except without the concept of ownership. For instance, we could
speak of the set of cars in a parking lot at a given moment, and the set would be
understood, even though the cars had no one owner. A set, like a collection, is a concept,
even though members of the set may be objects.
And, as with sets of concepts, some sets may be exclusive of each other. A given painting
may not simultaneously be a pastel and watercolor, and it may not simultaneously be a
portrait and a landscape. But a painting may simultaneously be in the pastel set and the
landscape set.

TYPES AND CLASSES

Long before computers were invented, we
humans recognized similarities between
things, categorized those things by their
similar characteristics, and named those
categories. For example, humans observing a
herd of elephants roaming the African plains
would recognize that all the individual
animals in the herd shared common
characteristics, including that they were gray
in color, had long snouts, and grew to
enormous size. These humans developed a
shared concept of the common characteristics, and in order to be able to communicate
Exploring the Variety of Random
Documents with Different Content
The Project Gutenberg eBook of Robert Merry's
museum, Volumes III-IV (1842)
 This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

Title: Robert Merry's museum, Volumes III-IV (1842)

Author: Various

Editor: Samuel G. Goodrich

Release date: February 26, 2024 [eBook #73026]

Language: English

Original publication: Boston: Bradbury & Soden, 1842

Credits: Carol Brown, Linda Cantoni, Jude Eylander, Katherine

Ward and the Online Distributed Proofreading Team at
https://www.pgdp.net (This file was produced from
images generously made available by The Internet
Archive)

*** START OF THE PROJECT GUTENBERG EBOOK ROBERT

MERRY'S MUSEUM, VOLUMES III-IV (1842) ***
 ROBERT MERRY’S

MUSEUM:
VOLUMES III. IV.

BOSTON:
PUBLISHED BY BRADBURY, SODEN & CO.
10, SCHOOL STREET, AND 127, NASSAU STREET, NEW YORK.
1843.

Entered according to Act of Congress, in the year 1842, by S. G.

Goodrich, in
the Clerk’s Office of the District Court of Massachusetts.
 ROBERT MERRY’S
MUSEUM.

edited by

S. G. GOODRICH,

a u t h o r o f p e t e r pa r l e y ’ s ta l e s .

VOLUME III.

BOSTON:
B R A D B U R Y, S O D E N , & C O . ,
No. 10 School Street, and 127 Nassau Street, New York.
1842.
 CONTENTS OF VOLUME III.
JANUARY TO JUNE, 1842.

The New Year, 1

Wonders of Geology, 3
The Siberian Sable-Hunter, 7, 65, 122
Merry’s Adventures, 12, 36, 79, 150, 177
Repentance, 16
17, 41, 74, 97, 131,
Indians of America,
165
Story of Philip Brusque, 21, 60, 87
Solon, the Grecian Lawgiver, 25
How to settle a Dispute without Pistols, 26
The Painter and his Master, 27
The Turkey and Rattlesnake,—a Fable, 28
Flowers, 28
Christmas, 29
31, 95, 126, 159,
Puzzles,
190
Varieties, 31, 188
Hymn for the New Year,—Music, 32
Anecdote of a Traveller, 33
Dr. Cotton and the Sheep, 34
The Robin, 34
Echo,—A Dialogue, 35
The Lion and the Ass, 35
National Characteristics, 35
The Two Seekers, 38
Resistance to Pain, 40
The Voyages, Travels and Experiences of 45, 84, 102, 139,
Thomas Trotter, 182
Cheerful Cherry, 48
The War in Florida, 56
Composition, 58
Natural Curiosities of New Holland, 59
Beds, 61
The Great Bustard, 62
The Tartar, 63
Answers to Puzzles, 63
The Snow-Storm,—Music, 64
Bees, 69
The several varieties of Dogs, 72
Anecdote of the Indians, 73
The Wisdom of God, 77
The Canary Bird, 78
The Paper Nautilus, 79
The Zodiac, 83
The Tanrec, 89
Letter from a Correspondent, 89
Different kinds of Type, 91
The Three Sisters, 92
The Zephyr, 95
To Correspondents, 95, 127, 158, 189
March,—A Song, 96
Butterflies, 101
Herschel the Astronomer, 107
Truth and Falsehood,—An Allegory, 108
The Chimpansé, 110
The Sugar-Cane, 111
Dialogue on Politeness, 112
The Date Tree, 114
Dress, 115
Eagles, and other matters, 117
April, 120
The Prophet Jeremiah, 121
Letter from a Subscriber, 124
Toad-Stools and Mushrooms, 125
Return of Spring, 126
Smelling, 129
Isaac and Rebekah, 135
Mr. Catlin and his Horse Charley, 136
The Kitchen, 138
Knights Templars, 145
The Garden of Peace, 146
The Banana, 148
Comparative Size of Animals, 149
Misitra and the Ancient Sparta, 155
Absence of Mind, 155
The Star Fish, 156
Where is thy Home? 157
Sea-Weed, 157
Inquisitive Jack and his Aunt Piper, 158
“Far Away,”—the Bluebird’s Song, 160
The Sense of Hearing, 161
“Fresh Flowers,” 162
June, 164
House-Building, 173
Edwin the Rabbit-fancier, 175
Who planted the Oaks? 181
The Deluge, 186
Page for Little Readers, 187

Entered, according to Act of Congress, in the year 1842, by S. G.

Goodrich, in the Clerk’s Office of the District Court of
Massachusetts.
THE IGUANADON.
MERRY’S MUSEUM.

V O L U M E I I I . — N o . 1 .

Tom Stedfast.
 The New Year.

There are few days in all the year that are pleasanter than the
first of January—New Year’s Day. It is a day when we all salute each
other with a cheerful greeting;—when children say to their parents,
as they meet in the morning, “I wish you a happy new year!” and the
parents reply, “A happy new year, my dear children!”
The first of January is, then, a day of kind wishes; of happy
hopes; of bright anticipations: it is a day in which we feel at peace
with all the world, and, if we have done our duty well during the
departed year, we feel peaceful within.
Methinks I hear my young readers say, “Would that all our days
might be thus cheerful and agreeable!” Alas! this may not be. It is not
our lot to be thus cheerful and happy all the days of our lives. A part
of our time must be devoted to study, to labor, to duty. We cannot
always be enjoying holidays. And, indeed, it is not best we should.
As people do not wish always to be eating cake and sugar-plums, so
they do not always desire to be sporting and playing. As the cake
and sugar-plums would, by and by, become sickening to the palate,
so the play would at last grow tedious. As we should soon desire
some good solid meat, so we should also desire some useful and
instructive occupation.
But as it is now new year’s day, let us make the best of it. I wish
you a happy new year, my black-eyed or blue-eyed reader! Nay, I
wish you many a happy new year! and, what is more, I promise to do
all in my power to make you happy, not only for this ensuing year,
but for many seasons to come. And how do you think I propose to do
it? That is what I propose to tell you!
In the first place, I am going to tell you, month by month, a lot of
stories both useful and amusing. I wish to have a part of your time to
myself, and, like my young friend Tom Stedfast, whose portrait I give
you at the head of this article, I wish you not only to read my
Magazine, but, if you have any little friends who cannot afford to buy
it, I wish you to lend it to them, so that they may peruse it.
 Tom is a rare fellow! No sooner does he get the Magazine than he
sits down by the fire, just as you see him in the picture, and reads it
from one end to the other. If there is anything he don’t understand,
he goes to his father and he explains it. If there are any pretty
verses, he learns them by heart; if there is any good advice, he lays
it up in his memory; if there is any useful information, he is sure to
remember it. Tom resembles a squirrel in the autumn, who is always
laying up nuts for the winter season; for the creature knows that he
will have need of them, then. So it is with Tom; when he meets with
any valuable knowledge—it is like nuts to him—and he lays it up, for
he is sure that he will have use for it at some future day. And there is
another point in which Tom resembles the squirrel; the latter is as
lively and cheerful in gathering his stores for future use, as he is in
the spring time, when he has only to frisk and frolic amid the
branches of the trees—and Tom is just as cheerful and pleasant
about his books and his studies, as he is when playing blind-man’s-
buff.
Now I should like to have my young readers as much like Tom
Stedfast as possible; as studious, as fond of knowledge, and yet as
lively and as good humored. And there is another thing in which I
should wish all my young friends to resemble Tom; he thinks
everything of me! No sooner does he see me stumping and stilting
along, than he runs up to me, calling out, “How do you do, Mr.
Merry? I’m glad to see you; I hope you are well! How’s your wooden
leg?”
Beside all this, Tom thinks my Museum is first-rate—and I assure
you it is a great comfort to my old heart, when I find anybody pleased
with my little Magazine. I do not pretend to write such big books as
some people; nor do I talk so learnedly as those who go to college
and learn the black arts. But what I do know, I love to communicate;
and I am never so happy as when I feel that I am gratifying and
improving young people. This may seem a simple business, to some
people, for an old man; but if it gives me pleasure, surely no one has
a right to grumble about it.
There is another thing in Tom Stedfast which I like. If he meets
with anything in my Magazine which he does not think right, he sits
down and writes me a letter about it. He does not exactly scold me,
but he gives me a piece of his mind, and that leads to explanations
and a good understanding. So we are the best friends in the world.
And now what I intend to do is, to make my little readers as much
like Tom Stedfast as possible. In this way I hope I may benefit them
not only for the passing year, but for years to come. I wish not only to
assist my friends in finding the right path, but I wish to accustom their
feet to it, so that they may adopt good habits and continue to pursue
it. With these intentions I enter upon the new year, and I hope that
the friendship already begun between me and my readers, will
increase as we proceed in our journey together.
 Wonders of Geology.

There are few things more curious, strange, and wonderful than
the facts revealed by geology. This science is occupied with the
structure of the surface of the earth; it tells us of the rocks, gravel,
clay, and soil of which it is composed, and how they are arranged.
In investigating these materials, the geologists have discovered
the bones of strange animals, imbedded either in the rocks or the
soil, and the remains of vegetables such as do not now exist. These
are called fossil remains; the word fossil meaning dug up. This
subject has occupied the attention of many very learned men, and
they have at last come to the most astonishing results. A gigantic
skeleton has been found in the earth near Buenos Ayres, in South
America; it is nearly as large as the elephant, its body being nine feet
long and seven feet high. Its feet were enormous, being a yard in
length, and more than twelve inches wide. They were terminated by
gigantic claws; while its huge tail, which probably served as a means
of defence, was larger than that of any other beast, living or extinct.
This animal has been called the Megatherium: mega, great,
therion, wild beast. It was of the sloth species, and seems to have
had a very thick skin, like that of the armadillo, set on in plates
resembling a coat of armor. There are no such animals in existence
now; they belong to a former state of this earth,—to a time before the
creation of man.
Discoveries have been made of the remains of many other fossil
animals belonging to the ancient earth. One of them is called the
Ichthyosaurus, or fish lizard. It had the teeth of a crocodile, the head
of a lizard, and the fins or paddles of a whale. These fins, or paddles
were very curious, and consisted of above a hundred small bones,
closely united together. This animal used to live principally at the
bottoms of rivers, and devour amazing quantities of fish, and other
water animals, and sometimes its own species; for an ichthyosaurus
has been dug out of the cliffs at Lyme Regis, England, with part of a
small one in his stomach. This creature was sometimes thirty or forty
feet long.

The jaws of the Ichthyosaurus.

Another of these fossil animals is called the Plesiosaurus, a word
which means, like a lizard. It appears to have formed an intermediate
link between the crocodile and the ichthyosaurus. It is remarkable for
the great length of its neck, which must have been longer than that
of any living animal. In the engraving at the beginning of this number,
you will see one of these animals swimming in the water. The
following is a view of his skeleton; the creature was about fifteen feet
long.

Skeleton of the Plesiosaurus.

But we have not yet mentioned the greatest wonder of fossil
animals; this is the Iguanodon, whose bones have been found in
England. It was a sort of lizard, and its thigh bones were eight inches
in diameter. This creature must have been from seventy to a
hundred feet long, and one of its thighs must have been as large as
the body of an ox. I have given a portrait of this monster, drawn by
Mr. Billings, an excellent young artist, whom you will find at No. 10,
Court st., Boston. I cannot say that the picture is a very exact
likeness; for as the fellow has been dead some thousands of years,
we can only be expected to give a family resemblance. We have
good reason to believe, however, that it is a tolerably faithful
representation, for it is partly copied from a design by the celebrated
John Martin, in London, and to be found in a famous book on the
wonders of geology, by Mr. Mantel.
There was another curious animal, called the Pterodactyle, with
gigantic wings. The skull of this animal must have been very large in
proportion to the size of the skeleton, the jaws themselves being
almost as large as its body.

Skeleton of the Pterodactyle.

They were furnished with sharp, hooked teeth. The orbits of the
eyes were very large; hence it is probable that it was a nocturnal
animal, like the bat, which, at first sight, it very much resembles in
the wings, and other particulars.
The word pterodactyle signifies wing-fingered; and, if you
observe, you will find that it had a hand of three fingers at the bend
of each of its wings, by which, probably, it hung to the branches of
trees. Its food seems to have been large dragon-flies, beetles and
other insects, the remains of some of which have been found close
to the skeleton of the animal. The largest of the pterodactyles were
of the size of a raven. One of them is pictured in the cut with the
Iguanodon.
Another very curious animal which has been discovered is the
Dinotherium, being of the enormous length of eighteen feet. It was
an herbiferous animal, and inhabited fresh water lakes and rivers,
feeding on weeds, aquatic roots, and vegetables. Its lower jaws
measured four feet in length, and are terminated by two large tusks,
curving downwards, like those of the upper jaw of the walrus; by
which it appears to have hooked itself to the banks of rivers as it
slept in the water. It resembled the tapirs of South America. There
appear to have been several kinds of the dinotherium, some not
larger than a dog. One of these small ones is represented in the
picture with the Iguanodon.
The bones of the creatures we have been describing, were all
found in England, France, and Germany, except those of the
megatherium, which was found in South America. In the United
States, the bones of an animal twice as big as an elephant, called
the Mastodon, or Mammoth, have been dug up in various places,
and a nearly perfect skeleton is to be seen at Peale’s Museum, in
Philadelphia.
Now it must be remembered that the bones we have been
speaking of, are found deeply imbedded in the earth, and that no
animals of the kind now exist in any part of the world. Beside those
we have mentioned, there were many others, as tortoises,
elephants, tigers, bears, and rhinoceroses, but of different kinds from
those which now exist.
It appears that there were elephants of many sizes, and some of
them had woolly hair. The skeleton of one of the larger kinds, was
found in Siberia, some years since, partly imbedded in ice, as I have
told you in a former number.
The subject of which we are treating increases in interest as we
pursue it. Not only does it appear, that, long before man was
created, and before the present order of things existed on the earth,
strange animals, now unknown, inhabited it, but that they were
exceedingly numerous. In certain caves in England, immense
quantities of the bones of hyenas, bears, and foxes are found; and
the same is the fact in relation to certain caves in Germany.
Along the northern shores of Asia, the traces of elephants and
rhinoceroses are so abundant as to show that these regions, now so
cold and desolate, were once inhabited by thousands of quadrupeds
of the largest kinds. In certain parts of Europe, the hills and valleys
appear to be almost composed of the bones of extinct animals; and
in all parts of the world, ridges, hills and mountains, are made up of
the shells of marine animals, of which no living specimen now dwells
on the earth!
Nor is this the only marvel that is revealed by the discoveries of
modern geology. Whole tribes of birds and insects, whole races of
trees and plants, have existed, and nothing is left of their story save
the traces to be found in the soil, or the images depicted in the layers
of slate. They all existed before man was created, and thousands of
years have rolled over the secret, no one suspecting the wonderful
truth. Nor does the train of curiosities end here. It appears that the
climates of the earth must have been different in those ancient and
mysterious days from what they are at present: for in England, ferns,
now small plants, grew to the size of trees, and vegetables flourished
there of races similar to those which now grow only in the hot
regions of the tropics.
As before stated, the northern shores of Siberia, in Asia, at
present as cold and desolate as Lapland, and affording sustenance
only to the reindeer that feeds on lichens, was once inhabited by
thousands and tens of thousands of elephants, and other creatures,
which now only dwell in the regions of perpetual summer.
The inferences drawn from all these facts, which are now placed
beyond dispute, are not only interesting, but they come upon us like
a new revelation. They seem to assure us that this world in which we
dwell has existed for millions of years; that at a period, ages upon
ages since, there was a state of things totally distinct from the
present. Europe was then, probably, a collection of islands. Where
England now is, the iguanodon then dwelt, and was, probably, one of
the lords of the soil.
This creature was from seventy to a hundred feet long. He dwelt
along the rivers and lakes, and had for his companions other animals
of strange and uncouth forms. Along the borders of the rivers the
ferns grew to the height of trees, and the land was shaded with
trees, shrubs, and plants, resembling the gorgeous vegetation of
Central America and Central Africa.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookmass.com