Class-Responsibility-Collaboration hierarchies in databases

Database Structure is the rules of how an organization's data interacts together. This may seem obvious, but if you look at designs of databases and development, you see that the obvious is often ignored when in context. The database structure is the Meta Data, the data that explains data.

An organization, from where I sit in the back office “virtually” consists of a network skeleton that reaches across to nodes, and or satellites. A backbone of heavy iron churns that data and runs the processes, launched by request from workstations.

Usually an organization will have one or many databases that act as the repository of information in an organization. The purpose of this data is to monetize the information or processes for profit.

The way to think about the database is not to view it as a dog-pile of stuff, but to think of knowledge units. Many knowledge units are contained in the database and linked through processes and/or relationships.

Knowledge units are first understood through the analysis of existing (or new) business practices. This often is done through “Use Case” scenarios. These knowledge units are transformed (part of the problem?) into “machine Instructions†” by a programmer.

Knowledge Unit storage in the database, is the combination of data and the applied rules to the data in conjunction with the relationships that data has with other data (a variety of rule).

Yet, what so often happens in production of a database design, is too much of the design is set up because, “I need to store this somewhere,” and a table of codes is created. The structure reflects the needs of the designer at design time, but does not take into account that what needs to be stored are things from the real world. These knowledge units are digital depictions of a real world objects or processes. The real world intrudes on the digital with Class-Responsibility-Collaboration hierarchies, but too often the immediate needs of a program result in structures being created on the fly that are nonsense.

So what I am saying is that when we are storing data into a database, we are storing the digital representation of a real thing, a classification or series of actions. To miscellaneously toss this willy-nilly into a hierarchical structure risks moving the whole structure into a game of “Silly-Buggers.”




†Usage for me is anything set of instructions a computer can use to render results, i.e. Table relationships, SQL statements for data extraction, script or compiled code, ect.