Note: In MEANING AND THE DATA MODEL I mentioned a recent LinkedIn exchange that prompted that post. It also reminded me of an older post, which had triggered two exchanges: one @DBDebunk, and another @https://news.ycombinator.com/item?id=12437389&goto=news, in which I participated at the time. I decided to update the post, including the former exchange. I strongly recommend the latter exchange, particularly comments by catnaroek.

 "Can you have 2 tables, VIEWS and DOWNLOADS, with identical structure in a good DB schema (item_id, user_id, time). Some of the records will be identical but their meaning will be different depending on which table they are in. The "views" table is updated any time a user views an item for the first time. The "downloads" table is updated any time a user downloads an item for the first time. Both of the tables can exist without the other."

 Recently I participated in a LinkedIn exchange initiated by the following statement:

“First-Order Predicate Logic is quietly breaking enterprise semantics. FOPL assumes meaning can be expressed as predicates applied to entities:

     subject → predicate → object

That works beautifully in theory. It fails in practice. Because the predicate is where ambiguity hides. So you can build vast semantic graphs where:
– entities carry multiple meanings
– predicates encode multiple dimensions
– relationships look precise but aren’t disjoint

It scales connections. Not clarity.” –Robert Vane

Table of Contents

 Introduction

1 Data Types

1.1 Abstract Data Types

2 Database Domains

2.1 Domain Adaptations

2.1.1 Attributes

2.1.2 Tuple States

2.2 Domain Definition

2.2.1 Type Specification

2.2.2 Domain Operators

3 Kinds of Domains

3.1 Base Domains

3.2 Primitive Domains

3.3 Atomic ("Simple") Domains

3.4 Derived ("Complex") Domains

4 DBMS Domain Support

Appendix 1: Complex Domain Example

Appendix 2: Type System

Appendix 3: Note on SQL Built-in Data Types

As we explain in Logical Database Design (forthcoming), LDD assigns the meaning of terms in conceptual models (CMs)—properties, entities, groups, multigroup—to non-logical symbols of a formal logic theory.

If the theory is RDM, the symbols stand for sets—domains/attributes, tuples, relations, database—adapted for database management. For each CM the theory acquires an interpretation, which produces a LM (application) of the theory for database representation and manipulation.

Here are the adapted sets symbolized in RDM which acquire the interpretation of the terms in CMs.

    This was said years ago:

 ”Table (n.) – a collection of information (data?) describing a population of entities which possess some common characteristics, called attributes. -itis – “suffix denoting diseases characterized by inflammation, itself often caused by an infection.”  ---------- from the Wikipedia Wiktionary.”

Tables are the building block of relational databases. Tables must generally be “normalized,” at least to 1NF. That may be an appropriate way to think of databases when implemented in a modern day DBMS. However, it is not the way the world thinks logically. People have no problem with commonly occurring phenomena such as:

·         A multi-valued attribute, e.g., an Employee possesses multiple Skills.

·         Many-to-many (M:N) relationships, e.g., as between Employees and Projects

·         A relationship with attributes  

     This just now, on LinkedIn (check out my comments).

“Putting to one side the argument that your data almost certainly didn't start out broken out in to tables, and it almost certainly isn't consumed that way either, here's the thing; MongoDB, if you squint, is essentially a relational database with an unorthodox take on first normal form and some great high availability and scalability features.” -- Graeme Robinson

“... In ORM there is no concept of an entity record (tuple), although relational tables can be automatically generated from an ORM model (furthermore, guaranteed to be fully normalized).” --Online comment

“Object Role Modeling (ORM) is a ...a fact-oriented modeling approach for specifying, transforming, and querying information at a conceptual level. Unlike [other modeling approaches] ... fact-oriented modeling is attribute-free, treating all elementary facts as relationships ... In practice, ORM data models often capture more business rules, and are easier to validate and evolve than data models in other approaches. --ORM.net