- FT Relation Interpretation
- L/C Tree Prediction in SQL
- L/C "Purpose built systems"
- SMS Primary Key Immutability
- FT Kinds of Surrogate Key
- SMS Imaginary Keys
- FT Uniqueness Is Relationship
- SMS SST/FOPL & Keys
Note: I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:THE FIRST NORMAL FORM - A DEFINITIVE GUIDE
PRIMARY KEYS - A NEW UNDERSTANDING
available for ordering from the PAPERS page, and two more:
RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE
DATABASE RELATIONS: A DEFINITIVE GUIDE
are in progress.
In the process I am coming across industry common and entrenched "pearls" that I am using for my "What's Right/Wrong with this Database Picture, or "Setting Matters Straight" (SMS), and "To Laugh or Cry" (TLC) posts on Linkedin. I do these posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.
Time permitting, I may specify those fallacies in brief posts that I set straight in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.
Here comes the first, a TLC I just posted on LinkedIn:
“The company was using a [SQL] RDBMS . . . to handle data transactions for its trading applications. However, the applications required arbitrary data types, which is nearly impossible for relational systems, according to experts.”
which contains three fallacies--can you identify them before you proceed?
New, completely re-written. Available to order here
Table of Contents
Series Preface
Abstract
Introduction
1. Entities, Properties, Names, and Identification
2. Relational Representation
3. Relational Keys
3.1. Kinds of Keys
3.1.1. Candidate, Primary and Alternate Keys
3.1.2. Natural and Surrogate Keys
4. Formal Primary Key Mandate
5. Primary Key Designation
6. Keys and Constraints
7. Keys and Performance
7.1. Keys and Indexes
Conclusion
References
Appendix A: Keys in SQL
Appendix B: Duplicates and Consequences
B1. Duplicate Interpretation
B2. Duplicates in SQL
B2.1. Duplicates and Correctness
B2.2. Duplicates and Query Nestability
B2.3. Language Redundancy & Duplicates
B2.4. Duplicates and Performance Optimization
B2.5. Duplicate Removal
In Part 1 we introduced in the conceptual model (CM) the metalogical designation property. It represents—in the absence of known shared defining properties of an entity type, the designation by a group's definer that an entity identifier (aka assigned name) or property value is a member of the group. Such a group is not a group of entities, but a group of name and property values. In the logical model (LM), it is formalized as a designation predicate (DP) and defines a domain.
In Part 2, we introduce the metalogical assertion property. It represents the assertion by an authorized database user that a specific entity, represented by a tuple, either does or does not correspond to an actual entity in the real world.
One purpose of our contributions here is to suggest a vocabulary that avoids confusion not just within the formal logical level, but also between conceptual and logical terminologies, which is widespread in the industry and is exacerbated by limitations of natural language (NL). We use the following terminology in our approach to conceptual modeling:
- Primitive (basic entities);
- Compound:
- groups of related entities;
- multigroups (groups of related groups);
- Individual (of basic entities);
- Collective:
- Of groups: relationships among entities within a group;
- Of multigroups: relationships among groups within a multigroup.
Note: It is a McGoveran insight that relationships between objects at a lower aggregate level are properties of the object at the higher aggregate level which the former comprise (LOGIC FOR SERIOUS DATABASE FOLK, forthcoming; see draft chapters) http://www.alternativetech.com/ATpubs_dir.html For classification of properties as first, second, third and fourth order (1OP, 2OP, 3OP and 4OP) see RELATIONSHIPS AND THE RDM Parts 1-3. https://www.dbdebunk.com/2023/03/relationships-and-rdm-v2-part-1.html All such properties can be expressed logically in a FOPL-based relational data sublanguage as constraints, which is beyond the scope of this discussion.
Due to:
1. Taking care of some health issues that have accumulated (not getting any younger);
2. Concentration on the Israel-Hamas War;
3. Effort to update old papers and write new ones;
4. Much needed rest and the holidays.
I am taking the remaining of the year off and will re-start my contributions in January.
Wishing you and yours season's greetings and happy holidays!
“I have read this article in an effort to boost my academic knowledge on data modeling a bit and still have no idea what this academic author wanted to say. Apparently First Normal Form (1NF) doesn't get enough respect and then proceeds to talk about Non-First Normal Form (NFNF). But what about First Normal Form (1NF) damnit.”
PRACTICAL DATABASE FOUNDATIONS
FIRST NORMAL FORM
A DEFINITIVE GUIDE
(September 2023)
Fabian Pascal
Table of Contents
Introduction
1. The Normal Form
2. The First Normal Form
3. Domain Decomposability & Atomicity
4. 1NF & Tables
5. SQL & 1NF
5.1. Repeating Groups & Repeated Attributes