Follow @DBDebunk Follow @ThePostWest


See Relations and the Relational Model

Follow @DBDebunk Follow @ThePostWest

1.
My keynote address at the Northern California Oracle User Group Spring 2013 conference was added to the SCHEDULE page.

2.
The 'Quote of the Week' was posted on the QUOTES page.

3.
A 'To Laugh or Cry' item was posted on the LAUGH/CRY page.

4.
Links to online exchanges I participated in were posted on the FP ONLINE page.

5.
I agree with most of Cary Millsap's take on NoSQL and Oracle, Sex and Marriage, but note that there is no reference whatsoever to the implications of the data models involved.

6.
After First Great Blunder Refuted consider my Type vs. Domain and Class.

7.
Another job description: Analytics- Data Modeler. Any idea why I post such?

Follow @DBDebunk Follow @ThePostWest

Note: What follows are my comments on a LinkedIn exchange, So What is a 'Large Database'? Minor edits of the online comments for grammatical, clarity, precision and coherence purposes are within square brackets.

PS: No doubt Oracle/SQL Server/etc are designed and optimized to deal with normalized data. That's where the power lies. They're like Sirens though ... those who don't respect them with proper designs are destined to have performance crashes (bear with me on this metaphor will ya? :)

Follow @DBDebunk Follow @ThePostWest

1.
The 'Quote of the Week' was posted on the QUOTES page.

2.
A 'To Laugh or Cry' item was posted on the LAUGH/CRY page. Many pronouncements exhibit poor grasp of foundation knowledge.  It is a rich target for  debunking, so I may tackle it at some point. You may want to test your mastery of fundamentals before I do.

3.
Links to online exchanges I participated in were posted on the FP ONLINE page.

4.
Job description: Solutions Developer. No comment.

5.
An oldie but goodie republished: Leonardo Was Right!

Follow @DBDebunk Follow @ThePostWest

Note: Minor edits 3/29/13.

In an online discussion initiated by the question Does It Matter If Data is BIG or not? MQ commented:

I still feel the discussion around Relational Modelling is confusing the point, and should be put aside until the problem is understood. If a company came to me and said 'Help me solve my big data issue - I have a billion emails I want to analyse' my answer is not 'just create a logical model using relational model theory' because this does not supply an answer. I will make more ground if I say 'right, lets discuss what this is, what technology you have, where the fail points and choke points are, etc and model (relational model) that as part of the process'.

I've built data models for 25 years (all levels) and firmly believed in Relational Theory across this entire period, so I am not saying drop Relational Models, just saying don't start there. Interestingly, I don't get any backlash against relational modelling using this approach - so perhaps the issues mentioned are about how the concept is sold to clients (a weapon rather than an intellectual concept)?

Follow @DBDebunk Follow @ThePostWest

1.
The 'Quote of the Week' was posted on the QUOTES page.

2.
A 'To Laugh or Cry' item was posted on the LAUGH/CRY page.

Here's an exchange between its author and myself:

I was thinking about database skills. When I started in the nineties, and systems were moving from Cobol to RDBMS, database and design skills were really valuable. Now, as much as we know that DB skills are important and valuable, it seems to be the GUI that is more important. At least in management's mind.  :(  At my alma mater, no student is studying the database track now. They either do app development, or networking. When does this mean for the future?

That is why the new generation of products are either applications and files, or labeled DBMSs when they are really application-specific DBMSs. Many practitioners do not distinguish between DBMS, applications, network and OS functions. It's all one big lump.

To which I add: This is also the reason application developers like object-orientation: it is a programming, not data "paradigm".

3.
Links to online exchanges I participated in were posted on the FP ONLINE page.

4.
The following Advanced Database Design and Implementation - Course Outline requires no comments for the reader possessing foundation knowledge. It is good evidence of academia pursuing industry fads rather than leading it with science.

This year the course will examine the following two contemporary fields in the database systems area: XML Data Model and XML Databases and Data Warehousing.

XML Data Model and XML Databases will comprise approximately 65% of the course. There, we shall consider topics such as: XML documents, Document Type Definition (DTD) and XML Schema, XML constraints, XML query languages, Types of XML Databases, Mapping XML data to relational databases, Publishing relational databases as XML documents, and what research is going on in the XML database area. The practical experience will be achieved through the use of XML processors like xmllint and the native XML database management system eXist.
...
By the end of the course, students should be able to:

• Design well formed XML documents that are valid with regard to a given DTD or XML Schema and thus develop the ability to solve practical engineering problems (BE graduate attribute 3(f)),
• Analyze a part of the real world and design a corresponding XML DTD or Schema in XML normal form and thus develop the ability to formulate and build efficient models of complex systems using principles of engineering science and mathematics (BE graduate attribute 3(b) and BE graduate attribute 3(c)),
• Design faithful models of a part of the real world using XML database constraints and thus develop the ability to apply mathematical and engineering science in solving engineering problems (BE graduate attribute 3(a)),
• Use available web sources to learn about the eXist XML database management system and define XQuery queries and XUPdata updates of an almost arbitrary complexity against a native XML database and thus develop the ability to look for additional information from pertinent sources (BE graduate attribute)...

Interestingly, the pre-requisite is familiarity with    "Relational Data Model, Structured Query Language (SQL), Relational Functional Dependencies and Normal Forms, PostgreSQL Data Base Management System."

Can't figure out why.

5.
On the lighter side: Models and met-a-date.

Follow @DBDebunk Follow @ThePostWest

Re-write:

• Normalization and Further Normalization Part 1: Databases Representing What
• Normalization and Further Normalization Part 2: If You Need Them, You're Doing It Wrong