Note: Each "Test Your Foundation Knowledge" post presents one or more misconceptions about data fundamentals. To test your knowledge, first try to detect them, then proceed to read our debunking, reflecting the current understanding of the RDM, distinct from whatever has passed for it in the industry to date. If there isn't a match, you can review references -- reflecting the current understanding of the RDM, distinct from whatever has passed for it in the industry to date -- which explain and correct the misconceptions. You can acquire further knowledge by checking out our POSTS, BOOKS, PAPERS, LINKS (or, better, organize one of our on-site SEMINARS, which can be customized to specific needs).

“The key idea is "Parent-Child" relationship. Entities ~ Relations ~ Tables (tilde stands for "more or less like"). Concept of a Table resonates with most of the people just as everybody intuitively grasps a concept of "rows and columns” but might struggle with "tuples and attributes". Explain relations and relationships, 1:1, 1:N, N:N etc. Explain rationale for this way of collecting and storing data, touch upon data normalization, and tell a few anecdotes about cost of storage back in 1970 and Y2K problem it have caused; add that we have inadvertently created Y10K problem while fixing it (not exactly true but not wrong either). Show an ERD diagram, trace the relationships, introduce SQL, maybe run a few simple SELECT queries to help your listeners visualize it, including equijoin and ORDER BY. Save other JOIN types, data types and other, more advanced topics, and for the next encounter.”

--Quora.com

 An excellent example that validates my claim of lack of foundation knowledge in the industry: most "explainers" of RDM have acquired relational jargon, but do not know or understand it at all.

Misconceptions

• "Parent-Child" is not the key relational idea (but the exact opposite);
• Relations do not represent entities;
• Tables, rows and columns are not "more or less like" relations, tuples and attributes;
• 1:1, M:1 and M:N relationships are not the only type of relationship represented by the RDM in databases, and are not the feature to which the RDM owes its name;
• The relational idea has intentionally and explicitly nothing to do with data storage;
• Proper database design does not require (it obviates) normalization and further normalization;
• SQL is not a proper data sublanguage, let alone truly relational and its teaching should not be syntactic;
• ORDER BY is a non-relational, non-database operator;
• Neither equi-joins, nor joins are the only relational operations;
• Programming data types are not part of the RDM;
• The chance that such explanations will lead to understanding of the RDM is nil.

Debunking

"Parent-child" is the key idea behind hierarchic DBMSs that preceded the RDM, which was introduced precisely to address the complexity and rigidity issues thereof.

• Graph Databases: They Who Forget the Past...
• Understanding Data Modeling Part 3: OO/UML and Graph Data Models
• Reader Mail Sets vs. Graphs, Education vs. Training
• OBG The Fate of Fads -- XML DBMS

Database relations are mathematical relations constrained to represent formally in databases groups of entities of a single type, for which reason they are by design in both 1NF and 5NF; it's their tuples that represent individual entities.

• What Relations Really Are and Why They Are Important
• Nobody Understands the Relational Model: Semantics, Relational Closure and Database Correctness series
• TYFK: Normalized, Fully Normalized, Non-Normalized, Denormalized: Clearing the Mess
• Understanding Relations series

R-tables, columns and rows should not be confused with database relations, attributes and tuples -- they only visualize them on physical media and play no role in the RDM.

• Relational Misconceptions Part 1: Relationships and Tables
• Understanding Relations Part 1: Tables, So What?

Conventional wisdom notwithstanding, M:1 and M:N relationships between entity groups are not the only ones represented in relational databases -- there are several other types of relationships, all of which are formally represented by constraints in databases.

• Relationships and the RDM series
• Levels of Representation: Relationships, Rules, Relations and Constraints
• TYFK: What Is A Database Relationship
• Data and Meaning series
• Understanding Relational Constraints
• OBG: Relationships and Relations
• TYFK: Semantics, Relations and the Missed Link: Constraints

Contrary to the logical-physical confusion (LPC) rampant in the industry, one of the core objectives of the RDM is physical independence (PI) -- the insulation of applications and users from implementation details.

• OBG: Data Independence and Physical Denormalization
• Physical Independence series
• OBG: Data Models and Physical Independence
• OBG: Don't Confuse Levels of Representation series
• Moving in Circles: RDBMS-SQL Conflation & Logical-Physical Confusion
• Data Warehouses and the Logical-Physical Confusion

For correctness, database relations are by definition -- and thus must be designed to be -- in 1NF and 5NF and the relational algebra (RA) must be revised for 5NF closure, in which case explicit normalization (to 1NF) and further normalization (to 5NF) is required only to repair bad designs.

• Database Design: What It Is and Isn't
• Normalization and Further Normalization series
• The Principle of Orthogonal Database Design series
• Don't Design Databases Without Foundation Knowledge and Conceptual Models
• OBG: Database Design and Guaranteed Correctness series
• How to Think (and Not to Think) During Database Design
• Normalization, Further Normalization, Ease of Use, Integrity and Performance
• The 'Real World' and Database Design
• OBG: Experimental Science and Database Design
• Nobody Understands the Relational Model: Semantics, Relational Closure and Database Correctness series
• The Costly Illusion: Normalization, Integrity and Performance
  

SQL's introduction and adoption as a relational data sublanguage is primarily responsible for the lack of true implementations of the RDM. SQL DBMSs have always ben confused with RDBMSs while in reality SQL is not a proper data sublanguage, let alone truly relational.

• Data Sublanguage series
• Data Sublanguages vs. Programming Languages
• Language Redundancy and DBMS Performance: A SQL Story
• Precision, Procedurality and SQL series
• The Cloud and SQL
• Thinking Logically SQL, NoSQL and the Relational Model
• To Really Understand Integrity, Don't Start with SQL
• SQL Sins
• The SQL and NoSQL Effects: Will They Ever Learn?
• NoSQL and SQL A Plague on Both Their Houses

Because physical order plays no part in the RDM, ordering of attributes and tuples in results of RA operations is not relational and, therefore, an application, not DBMS function.

• Order Is For Society, Not Databases
• DISTINCT and ORDER BY Are Not Relational
• Relational Fidelity, Cursors and ORDER BY

RA consists of several primitive set operations that are combined into derived operations, one of which is join, a combination of cross-product, restriction and projection. As surrently defined, RA operations, including join, lack 5NF closure and, thus, correctness is not guaranteed.

• Nobody Understands the Relational Model: Semantics, Relational Closure and Database Correctness series
• TYFK: 5NF, Association Relations and Join
• Data and Meaning Part 4: Query and Result Correctness
• TYFK: “Why is a relational database so powerful”

Notwithstanding conventional wisdom, relational domains should not be confused with programming data types, from which they are critically distinct -- the reason Codd used a different term.

• Understanding Domains and Attributes
• TYFK: What Domains Are and Are Not
• Domains: The Database Glue
• Simple Domains and Value Atomicity
• First Normal Form in Theory and Practice series