Follow @DBDebunk Follow @ThePostWest

Note: In "Setting Matters Straight" posts I debunk online Q&As that involve fundamentals which I first post on LinkedIn. The purpose is to induce practitioners to test their foundation knowledge against our debunking, where we explain what is correct and what is fallacious. For in-depth treatments check out the POSTS and our PAPERS, LINKS and BOOKS (or organize one of our on-site/online SEMINARS, which can be customized to specific needs). Questions and comments are welcome here and on LinkedIn.

“...The relational model organizes data through relations (aka tables). You then normalize it in one of six forms. By normalizing data you:
- Reduce redundancy
- Ensure consistency
- Optimize for atomic inserts, updates and deletes
The biggest drawback ... are keys that let you join different tables across multiple systems.”

                                                                      --LinkedIn.com

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

SUPPORT THIS SITE
DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics column. The site was discontinued in 2018. The content here is not available anywhere else, so if you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing publications, or donating. On-site seminars and consulting are available.Thank you.

LATEST POSTS

08/14 THE VOCIFEROUS IGNORANCE HALL OF SHAME (T&N)

08/04 DATABASE RELATIONS, TABLES AND SEMANTIC CONSISTENCY

07/12 MISSING DATA AND MULTI-RELATION QUERY RESULTS (T&N)

LATEST PUBLICATIONS (order from PAPERS and BOOKS pages)
- 08/19 Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, paper #2 in the new UNDERSTANDING THE REAL RDM series.
- 02/18 The Key to Relational Keys: A New Understanding, a new edition of paper #4 in the PRACTICAL DATABASE FOUNDATIONS series.
- 04/17 Interpretation and Representation of Database Relations, paper #1 in the new UNDERSTANDING THE REAL RDM series.
- 10/16 THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book (reviewed by Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).

USING THIS SITE
- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the FUNDAMENTALS 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, including 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
I deleted my Facebook account. You can follow me @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture? posts, and my exchanges on LinkedIn.
------------------------------------------------------------------------------------------------------------------

Misconceptions

• Tables per se play no role in the RDM.
• You do not "normalize database relations in one of six forms".
• Normalization does not reduce redundancy, ensure consistency, or optimize for anything.
• Keys are not a drawback and do not "let you join across multiple systems".

Fundamentals

A database relation represents a group of entities of a single type (i.e., share properties and relationships). As a set, it has:

• An intension: the semantic constraints representing the properties/relationships, which the tuples must satisfy to be included in the relation; and,
• An extension: the set of tuples that satisfy the constraints; it can be visualized on a physical medium as a table, but the column-and-row layout plays no relational role.

The complete definition of a database relation consists of both the intension and extension.

Database relations are not just in 1NF (normalized), but also in 5NF (fully normalized) by definition; otherwise they may be, mathematically, relations, but are not database relations.

Adherence to three database design principles produces databases that require neither normalization to 1NF, nor further normalization to 5NF. Explicit normalization and further normalization are necessary only to repair poorly designed databases due to failure to adhere to the principles:

• Normalization to repair non- 1NF relations eliminates relation-valued attributes (RVA) defined on relation-valued domains (RVD) and, thus, does not reduce redundancy.
• Further normalization to repair 1NF relations that are not in 5NF is not performed through the six forms in sequence", but from whatever lower normal form relations are to 5NF.

Keys represent in the database names assigned by convention in the real world to collections of properties/relationship that define entities and groups thereof. They are components in the constraint mechanism ensuring semantic consistency of database relations with:

• Individually, with the individual groups, and
• Collectively, with the multigroup

they represent.

Conforming database design, the declaration of constraints by users and enforcement of the constraints by a RDBMS guarantees correctness -- semantic consistency and logical validity.

Setting Matters Straight

We revise the above comment as follows:

“The RDM organizes data as database relations (which can be visualized as tables) which are designed to be:

• In 1NF (normalized) and devoid of RVAs; and,
• In 5NF (fully normalized) and devoid of redundancy

for by-design semantic consistency and system-guaranteed logical validity, of which keys are an integral part, one use of which are joining relations within a database.”