Follow @DBDebunk Follow @ThePostWest

    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  

even though our systems may. None of these situations can be handled directly in a relational database."

     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

 

--------------------------------------------------------------------------------------------------------

SUPPORT THIS SITE
This content here is not available anywhere else,  except in regurgitations and hallucinations of  LLMs, potentially mixed with other garbage.  If you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing papers, donating, or contact me for online seminars/consulting.

 

USING THIS SITE
- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the SEARCH  page. For detailed instructions on how to understand and use the labels in conjunction with that page, see the ABOUT page. The 2017 and 2016 posts, incl uding earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search.
- The links to my AllAnalytics columns no longer work. I re-published only the 2017 columns @dbdebunk, and within them links to sources external to AllAnalytics may or may not work.

 

SOCIAL MEDIA
You can follow me @LinkedIn, and ThePostWest on X.

 --------------------------------------------------------------------------------------------------------

The building blocks of relational databases are, of course, relations—database representations of sets of facts. Normalization applies to relations, not to tables. Table are only one way to visualize relations on some physical medium. In fact, tables are both incomplete and superfluous representations of relations:

• Date notwithstanding, relations do not have “body” and “heading”— those are table, not relations features;
•     The tabular row-and-column physical arrangement does not encode any information from conceptual models (CM), so it plays no role in RDM;
•   The body of tables depicts the extension of relations (data), but lack the intension (meaning)—the relation predicate (RP)—for which the heading (just a bunch of attribute names) is no substitute.
•   You cannot do with tables what you can do with relations. 

What defines relations as distinct from tables are the relationships among their components—attributes and tuples. It's those relationships that are important. They comprise conceptual information (semantics)—the business rules (BR) in CMs—encoded in RPs, which are missing from tables. When expressed in a relational data sublanguage they are semantic constraints that constrain the relation for semantic consistency with the “natural occur ring phenomena”—the BRs in the CM— the interpretation of the relation. What is more, as currently defined, the relational algebra (RA) does not include the constraints and expressions thereof in its operations, hence the semantic loss (mislabeled in industry as “update anomalies”.

   Practitioners are familiar with relationships “between tables”, but not those within relations, which are absent from tables.

"Logical refers to the relationships among the components of the relation, not to any arrangement of the components of a relation. Any presentation that preserves those relationships and adds no extra ones is acceptable. A table is one possible such presentation. The problem is that people fixate on this one presentation, identifying it with relation. They then go even further and force the physical implementation of a relation to be table-like". --David McGoveran

   “Multi-valued attributes” (MVA) are not “commonly occurring phenomena” but one possible database representation thereof—a clear example of conceptual-logical conflation. It’s entity properties that are. MVAs represent them in the database. MVAs are a design choice, which has drawbacks.

   Whenever I come across “relational systems can't handle something",  or " not everything is tables" it's a dead giveaway for poor or no understanding of RDM.

·         Skills can be modeled (i.e., viewed) either as multiple properties and represented relationally as a 5NF database relation, or as a multi-component property represented by a non-1NF relation, or a non-relation. This is subjective modeling/design choice, which should be a function of the advantages and drawbacks of each. The problem with anti-relational proponents is that they focus on the structure and ignore the manipulation, where the problems pile up with hierarchies, including non-1NF containment hierarchies.

As de Koppelaars said “Oracle supports nested tables, but I hardly ever see them used, however.”

·         Many-to-many to…to-many relationship (of which many-to-many is a special case) between groups of entities can be readily modeled as an associative group of entities and represented as an associative relation in RDM.

The first author has got it backwards. It is criticism of RDM for table deficiencies that is the real tableitis, and a straw man argument to boot. Genuine relational proponents—not those who just use relational jargon without understanding it—do not “think tables”, but database relations in 5NF—sets with intension (interpretation) and extension (data) manipulated together by a proper RA.

Normalization and denormalization change the number of logical relations, which does not affect performance (determined exclusively at the physical level) unless the DBMS has poor support of physical independence, which holds for SQL systems.

   So, no, MungoDB is not relational, nor is any DBMS in the market, including SQL ones.