Tom, I like your style and agree with most of your assessments. NULLs indeed. But I won't even attempt to insinuate that I have anywhere near your understanding of all the works and authors mentioned. It is enough for me to learn and understand the principled ideas. I don't need to know who first found a way to express them best. Good principles existed long before any articulated mouthpiece came along to enunciate the wonders.

As to the OP article, it is good to see progression. All of us start from birth and learn as we go. I have struggled with exactly how to teach the current run of developmental pontificates the principles of RDB design. I have worked in both arenas. I understood immediately the apples and oranges mix of the vocabulary used in the article. The DEV uses "decouple" because it is a term bandied about much in development, and has taken on a few meanings. I personally think the REST movement is what really muddied the term. It was for a time a catch phrase that had to be used in daily mutterings... but I don't desire to dive into that just now.

To the point, I don't know of an academic school yet with a course that actually teaches RDBMS design with the effect of producing any significant amount of experienced DBA talent as a result. Academic courses spend more time discussing the history and competing views, rather than on actual principled design implementation. And they certainly don't focus on specific vendor implementation best practices.

Most schools focus on development, and in that, on design patterns and academic problem solving methodologies, from a developmental standpoint.

So, in my view, here I see another soul getting a grip on relationships, and being able to regurgitate the concepts (actually terminology be what it may). I smile and remember the days those first waves of understanding washed over me, and I finally could see a normalized structure all laid out in my minds eye.

Being able to design relational tables, however, is only the start of a being a DBA. I come across many... too many... who think the role of a DBA is unnecessary. "The database is just a bucket to store things in..." and, "we prefer to decouple the application from the DB". Such are the refrains. That ilk all hits the fan the minute management wants any significant reporting and crunching to analyze the data, or the same data has to feed more than one purpose... (and it *always* feeds more than one purpose eventually).