Sunday, November 22, 2015

Weekly Update

Housekeeping: Added If a table with a SK has a NK does it violate 3NF? to LINKS page.

1. Quote of the Week

One other intriguing benefit of NoSQL that I started to unwitting benefit from recently is the ability to push data scheme concerns entirely to the application layer. In this scenario, the applications use a NoSQL database predominantly as a storage service, lightly structured by a few indexed key fields. The object structured data document within the payload becomes transparent to the database. The applications then assume the role of enforcing and understanding the data scheme.

This approach allows the application architect to encode the data structures and meaning directly in the code that creates and consumes the data. So data structure changes required for functional updates can be implemented, tested, and deployed in the application code base with no updates to the database layer at all. (Of course, a conversion of existing NoSQL data documents may be required in situations.)

In this NoSQL approach, the removed translation of object data scheme to a relational structure and, and then back to an object structure again is a very welcome relief as well.

Sunday, November 15, 2015

Moving in Circles: SQL for NoSQL

We've been there, done that.  

In Coming Full Circle: Why SQL now powers the NoSQL Craze Ryan Betts, CTO at VoltDB, argues that NoSQL products should adopt SQL for queries. I don't know about you, but to me it looks like a contradiction. Let me make it clear that my intention here is neither to defend SQL, nor to criticize it--I sure have done enough of that during the years--but rather strictly debunk the notion that its use with NoSQL systems is a good idea.

Sunday, November 8, 2015

Weekly Update

Housekeeping: Added
to LINKS page.
to SOFTWARE section on Home page.

1. Quote of the Week

After attending NoSQL conference I am really hoping that companies think through this 'big data' implementation! No one there was interested in Data model ... and said so ... forget the data model ... even 'standards' were looked at 'its 'too early' for this new technology ... and no one could tell us anything about 'meta-data'...!!!!!

Sunday, November 1, 2015

Entity Supertype-Subtypes, SQL & TRDBMS

Back in April I argued in a LinkedIn exchange on missing data that, Codd notwithstanding, "inapplicable data" and 4VL are a red herring. If the conceptual model says that an attribute does not apply to an entity, it does not have it and, therefore, the column representing the attribute in the database should not exist for the rows representing those entities. If it does, the design does not accurately represent the conceptual model and the inapplicable NULL's (in SQL) are an artifact of poor design: it fails to account for entity super-types and sub-types (ESS).

This prompted a query from Nik Spicer.

Sunday, October 25, 2015

Weekly Update

1. Quote of the Week
The ER notation consists a set of constructs, such as, a rectangle to represent an entity types, an ellipse to represent an attribute a diamond to represent a relationship type, and so on. The RDS is a set of linear relation schemas. A relation schema has a name and is a sequence of attributes of text separated by comas and arranged horizontal. I have also developed an ER-to relational transformation algorithm to transform an ER schema to its corresponding RDS. I wish to implement this project as a CASE tool.
The problem is not the student, but the quality of education he gets at his university.

Sunday, October 18, 2015

Interpreting Codd: 1NF in Theory and Practice

Not long after I recently published several posts on 1NF
Konrad Zdanowski tries to answer What is the actual definition of First Normal Form (1NF)? himself.
... there is no generally accepted definition of 1NF ... When you look at various descriptions 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 ... Date's DATABASE DESIGN AND RELATIONAL THEORY presents four eminent examples of such definitions ... Does 1NF equate to “atomic attributes”? ... what [do] people have in mind demanding atomicity? In my opinion, the intuition behind definitions [in books] 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.
Unfortunately, this creates an impression opposite to the one intended.