Sunday, September 28, 2014

Weekly Update

1. Quote of the Week
Further to that point, in my mind you can have a database that is both relational and schema-less, in the sense that it is relational if the only thing in it is relations but it is schema-less if any data updating operation is allowed to change the number or degree etc of said relations, rather than that being reserved for so called data-definition operations.
2. To Laugh or Cry?
Turning dirty data words into sweet talk
And an oldie, but goodie
Gardner to DBAs, BI Vendors Reinvent Yourselves
3. Online Debunkings
4. Elsewhere

An old classic:
Unskilled and Unaware of It
and a related consequence
How Our Botched Understanding of Science Ruins Everything
5. And now for something completely different
John Oliver: Nuclear Weapons
Freaky Physics Experiment May Prove Our Universe Is A Two-Dimensional Hologram
About the PostWest:
PA: Israelis Must Return to Their Countries of Origin
How about the Arabs in Palestine, most of of whom originate in immigrants from Arab countries attracted to Palestine by jobs created by Jewish development?
If it's not Jews doing it, who cares. It's not so much care for Palestinians as it is hate of the Jews.
Any way, Nice people. Let's give them a state.
US Providing Indirect Military Aid to Hezbollah
Afghanistan and Iraq redux.
Go Easy on Iran So It Fights ISIS? That's Absurd
Indeed: Why should the US allow an enemy nuclear weapons, when fighting ISIS is Iran's own existential interest anyway? Let radical Shia and Sunni duel it out.
World Council of Churches Demands Israel Release Terrorists
Ah, yes, religion is the source of morality.

Sunday, September 21, 2014

New Paper on Domains

I have just published a new PRACTICAL DATABASE FOUNDATIONS paper. See the PAPERS page for pricing and ordering information.

Domains: The Database Glue 

Abstract: Domains are a fundamental database feature. Codd, the inventor of the relational model referred to them as the "glue that holds the database together". Mathematical relations are defined on domains and, therefore, so are their database representations, R-tables. Yet they are one of the least understood database features. This is both a cause and a consequence of the failure by SQL DBMS's to implement them truly and fully. The negative implications e.g., weak support for complex and/or user-defined data types" is claimed a weakness of the relational model, rather than an industry implementation failure. This paper
  • Defines and explains the domain concept;
  • Distinguishes between domains and data types;
  • Discusses kinds of domains;
  • Clarifies DBMS domain support;
  • Discusses practical implications for database and DBMS design.

Table of Contents


1. Property Business Rules and Domains

2. Domains vs. Data Types

3. Value Atomicity and Encapsulation

4. Kinds of Domains
4.1. Simple and Complex Domains
4.2. System-defined Domains
4.3. User-defined Domains

5. DBMS Domain Support
5.1. Complex Domains

6. Practical Implications
6.1. Relational Domains vs. Object Classes
6.2. Business Modeling
6.3. Database Design
6.4. DBMS Design
6.4.1. SQL “Domains”
6.4.2. “Universal” DBMS

7. Conclusion


Sunday, September 14, 2014

Weekly Update


  • Added a LINKS page to the top site menu, with links to items I deem worth reading. Added a few from my old site and new ones will be added as I come across them.
  • Overhauled the FUNDAMENTALS list of sources at the right of the HOME page. It now includes links to the bibliographies of E. F. Codd, D. McGoveran, C. J. Date, H. Darwen and myself. 

1. Quote of the Week
The future in data modeling is Object Role Modeling (ORM).  It is a far superior way to approach data modeling (compared to any record-based methods such as relational) that avoids all the pitfalls of "Table Think" and the necessity of normalization.
2. To Laugh or Cry?
Survey data model, what is the best approach?
3. Online Debunkings
Dr. Robin Bloor: Big Data is “nonsense”
4. Elsewhere
5. And now for something completely different
Senator Challenges Zuckerberg
American patriot.
The Exorcisms of Anneliese Michel

@The PostWest:

Sunday, September 7, 2014

Weak Entities, Referential Constraints and the Conceptual-Logical Conflation (REVISED)

A LinkedIn exchange initiated by the question What is a weak entity? diversified into various aspects of data modeling and database design, some of which was contaminated by the conceptual-logical conflation.

"Peter Chen (E/R Modeling, 1976) used the term "weak" entity to describe one which could not meaningfully have an independent existence. An example might be an Order which requires a customer (and a Product or set of products). A weak entity need not be a composite, as in your OrderItem example. The central issue here is dependency of one entity [of one] type on another [of another type]. Furthermore, there could be more that one such dependency. In your example, the OrderItem would be dependent on BOTH Order and Item.

It is important to note that this dependency will NOT be enforced by a simple RDBMS unless you also define referential integrity on both parts of the composite key, notwithstanding that some RDBMS's (e.g., SQL Server) couple the definition of the relationship with a referential integrity constraint. In other words, you cannot have a defined relationship without enforcing referential integrity.

This is not always desirable. Consider the task of bulk loading some records which have a relationship with some other entity type(s). The only practical way to do this is to first turn off referential integrity enforcement which means deleting the definition of the relationship entirely. After completing the loading of data, if you reinstate the defined relationship, will the system automatically ensure that referential integrity is not violated? Good question."
--Gordon Everest