Follow @DBDebunk
Follow @ThePostWest
My March post @All Analytics.
Frequent hits @dbdebunk.com are driven by the question “Are keys
mandatory?” Puzzlingly, many data professionals do not seem to
understand why duplicates should be prohibited. This should worry
analysts. But “Stating the same fact more than once, does not make it truer, only redundant,” as E. F. Codd used to say. The absence of an identifier means that individual entities are
not meaningful, so this representation contradicts the real world. Contradictions produce problems. First, a DBMS is incapable of
“visually” discerning a data entry duplication error from "valid"
duplicates, which means high risk of inconsistent databases and wrong
counts and other query results.
Read it all. (Please comment there, not here)
Friday, March 25, 2016
Sunday, March 20, 2016
This Week
Follow @DBDebunk
Follow @ThePostWest
1. QUOTE OF THE WEEK
Q: I am trying to remove duplicate rows from a database containing 4446 tables and when finished, merge data from that database to an existing database with the same structure. Is there an easy way to remove duplicate rows from all those 4446 tables?A1: Please tell us "what is a 4446 table?" And, please give examples of duplicate records.A2: Recreate your database with unique primary keys. 2) Copy records from original database to recreated database, one table at a time. The duplicate records will drop on the floor. 3) Fix the thousands of bugs in your application code that created the duplicate rows in the first place.A3: I'm creating temporary tables + I add unique index to that table and insert data into and then I rename it to the original one.
--stackoverflow.com
Wednesday, March 9, 2016
The Fourth V -- Veracity
Follow @DBDebunk
Follow @ThePostWest
My February post @All Analytics.
"A fact is represented in the database not because it is categorically true, or categorically false, but only because somebody has asserted it, or has removed that assertion. We rely on people (and only on people!) for whatever a database system treats as true or false. When we authorize someone (or some application) to update the database, we accept their veracity, judgment, personal integrity, intelligence, comprehension, etc. insofar as the database is to have any utility. Nothing more can (or should) be said about truth and falsity." -- David McGoveran
Read it all. (Please comment there, not here)
My February post @All Analytics.
"A fact is represented in the database not because it is categorically true, or categorically false, but only because somebody has asserted it, or has removed that assertion. We rely on people (and only on people!) for whatever a database system treats as true or false. When we authorize someone (or some application) to update the database, we accept their veracity, judgment, personal integrity, intelligence, comprehension, etc. insofar as the database is to have any utility. Nothing more can (or should) be said about truth and falsity." -- David McGoveran
Read it all. (Please comment there, not here)
Sunday, March 6, 2016
This Week
Follow @DBDebunk
Follow @ThePostWest
1. Quote of the Week
1. Quote of the Week
[With] a declarative language and you have no real control over the execution plan. Heck, Oracle 12c can use multiple different execution plans for the same query depending on bind parameters, statistics not matching reality, and the phase of the moon.
No declarative language will ever be a first-class programming citizen in my eyes. Too much magic. Too non-linear. Too hard to debug for those reasons. They are great for when you have to do really simple things but once you step off the well worn path, you are in the thicket.
--reddit.com
Tuesday, March 1, 2016
First Normal Form in Theory and Practice Part 1
Follow @DBDebunk
Follow @ThePostWest
09/19/23: For the latest on this subject see: FIRST NORMAL FORM - A DEFINITIVE GUIDE
Note: This is a 11/23/17 revision of Part 1 of a three-part series that replaced all of my previous posts on the subject (pages of which redirect here), in order to further tighten integration with the McGoveran formalization and interpretation [1] of Codd's true RDM.
On the one hand:
"... there is no generally accepted definition of 1NF ... the word that you see most often is 'atomic'. It is common to say that a relation is in 1NF if all its attributes [sic] are atomic ... Does 1NF equate to “atomic attribute [values]”? ... what [do] people have in mind [when they claim] atomicity? ... the [meaning] behind definitions is that you should rarely need to extract information from a value of an attribute ... But that explains why one cannot decide, depending on theory only, whether a relation is in 1NF ... it is a habitual use of data that makes attributes atomic, not theory. No wonder, there is so much mess in theory about what 1NF should be."
--What is the actual definition of First Normal Form, Vertabelo.com
On another, according to a DBDebunk reader:
"Codd in 1969/70 (and RM V/2 20 years later) gave a precise, theory-based definition of "atomic" aka "simple" aka "non-decomposable" (later aka non-"compound" aka non-"structured"): not relation-valued. And he gave a precise definition of "normalized" (1NF): relations free of relation-valued-domains (RVD)!"All sorts of other definitions proliferate, for example:
"First normal form enforces these criteria:
- Eliminate repeating groups in individual tables.
- Create a separate table for each set of related data.
-Identify each set of related data with a primary key."--First normal form, Wikipedia
Note: A relational databases consists of relations that can be visualized as R-tables. Normal forms are a property of relations, not R-tables -- a "R-table in 1NF" is shorthand for consistency with the underlying relation.
Subscribe to:
Posts (Atom)