Posted: xxx, 2008Written: xxxA Refinement On All Tables Must Contain Business Keys.

Posted: xxx, 2008Written: xxxBad Data Models and How They Work.

Posted: xxx, 2008Written: xxxBinding.

Posted: xxx, 2008Written: xxxDAMA 2008 Primary Keys, Surrogate Keys and Business Keys.

The Semantics and Syntax of Codd's Information Principle. A presentation at the DAMA International Conference, 2008.

Posted: xxx, 2008Written: xxxDAMA 2008 Speaker Notes for: Primary Keys, Surrogate Keys and Business Keys.

Posted: xxx, 2008Written: xxxData Modeling As Engineering And As Conceptual Clarification.

Posted: Nov, 2007Written: Oct, 2006Data Modeling and Ontologies.

Mathematics, normalization, early binding, ontologies. Also brief comments on the past, present and future of the representation of information in databases and application systems.

Posted: Oct, 2007Written: 2001 - 2005Keys in Relational Databases.

A ten-part series.

Posted: Nov, 2007Written: 1997Modeling With Recursion: Part 1.

Linear recursion, implementing a one-to-one recursive relationship.

Posted: Nov, 2007Written: 1997Modeling With Recursion: Part 2.

Hierarchical recursion, implementing a one-to-many recursive relationship. This is the only recursive relationship data modelers usually think of. Although it can be used to model a one-to-one relationship, it normally should not be used to do so. The reason is that its structure permits violations of the one-to-one rule; in other words, to fully express the semantics of a one-to-one recursive relationship in a one-to-many recursive structure, code will be required to prevent violations of the one-to-one rule.

Posted: Nov, 2007Written: 1997Modeling With Recursion: Part 3.

Network recursion, implementing a many-to-many recursive relationship. This structure can be used to model one-to-one and one-to-many relationships as well as many-to-many relationships but, for the same reason that a one-to-many structure should typically not be used to model a semantically one-to-one relationship, this structure should typically not be used to model either a one-to-one or a one-to-many relationship. But if the cardinality of the semantic relationship may "increase" (a 1:1 becoming a 1:M, or a 1:M becoming a M:M), then it may be advisable to anticipate this business rule change by creating a physical many-to-many recursive structure, and using code to enforce the constraints of a one-to-one or one-to-many relationship. The reason is flexibility, and the reason for flexibility is cost containment. For example, if a physical many-to-many recursive structure is used to implement a one-to-many relationship, and later on the business wishes to change the relationship to many-to-many, the cost of making that change is simply the cost of removing the code that prevented any row from being a child of more than one other row. On the other hand, if the physical recursive structure was itself one-to-many, then it is easy to imagine conversion costs of man-months.

Posted: Jan 11, 2008Written: Nov, 2007On the Dangers of Reading Meaning Into Surrogate Keys.

Surrogate keys, by definition, have no business meaning. But suppose, for example, that the surrogate key for table X is a sequence number. If a system-knowledgeable user makes use of that knowledge, he can tell, for example, of a set of rows in table X, the chronological sequence in which they were inserted. What's the danger in doing that?

Posted: Jan, 2008Written: Oct, 2006What Makes Real World Data Modeling Tough.

In short: dirty data. While some data management purists would argue that the solution to dirty data is to keep it out of your databases, experienced practitioners know that vast amounts of data are dirty, yet are needed to run the business. An important class of dirty data is dirty primary keys. Tables which contain dirty primary keys are the ones which need to be "de-dupped", i.e. which are known to have multiple rows representing the same real world object. Of course, there's never time, right now, to de-dup an important table. It will have to be done some time much later, when we have time to get around to that enormous task!

Posted: Feb 14, 2008Written: Feb, 2008Nulls: Caveat Emptor.

An account of some of the ways in which current implementations of SQL deploy nulls incorrectly.

Posted: Jun, 2008Published: Feb, 2008 at Datawarehouse.com in 2001 - 2002.A Nine-Part Series on Basic Normalization.

Background, then first through Boyce-Codd normal forms.

Posted: Jun 26, 2008Published: at Datawarehouse.com in 2002.Modeling and Conceptual Clarification - 1.

Posted: Jun 26, 2008Published: at Datawarehouse.com in 2002.Modeling and Conceptual Clarification - 2.