- by erked, Prospector
- 4/24/2015 12:43:15 PM
"But without training how to do that and appreciation for it, it is much easier to throw everything into NoSQL and let the analyst worry about it."
And the masochistic part is that it's not just analysts that worry about it... it's QA, documentation, support, and other engineers as well, who have to collectively deal with the problems arising from lack of clarity.
- 3/7/2015 5:13:41 PM
Well, as long as the educational system fails to teach the fundamentals, including the history of the field and employers do not condition hiring on it, there is no reason to expect anything else.
The problem is much worse due to the conceptual-logical conflation and the logical-physical confusion.
One of the many advantages of the relational model lost on most practitioners is that it forces you to think clearly upfront. But without training how to do that and appreciation for it, it is much easier to throw everything into NoSQL and let the analyst worry about it.
- by cimode, Prospector
- 3/7/2015 4:48:09 PM
I am amazed at how simple/granted things of applicative relational design must still be reexplained from the ground up such as the relationship between business rules and need for documentation. 40 years after RM inception, it is regrettable that we are still stuck at rediscovery of existing concepts.
As far as I am concerned, documentation is *de facto* semantically established when moving from conceptual to logical model, and technologically established when moving from the logical model to the physical model. I would even dare going further as saying that two documentations are necessary and not one: a semantic documentation and a technological documentation, the former being a prerequisite for the latter.
It is reasonable to assume that the process itself of documentation could be simplified using smarter design client applications where all layers of proper design are visible to the designer.
- 3/6/2015 6:23:09 PM
Constraints ARE approximations to business rules, but very loose ones, and can be interpreted correctly only if the tables are in 5NF, which most are not.
Constraints are recorded in SQL database catalogs and triggered/stored procedures.
However business rules must be documented by the business modeler/db designer somewhere. To that end they must know the types of rules, which is what my clumns are about.
- by cbeauvais_data_shaman, Prospector
- 3/6/2015 6:08:00 PM
Integrity constraints should be based on business rules. Some Business Analysts I know don't want to widen the definition of business rules to include data centric quality or constraint rules. There is a need, IMHO to include constraints and the business rules that they enforce in a metadata repository that links the natural language rule, a pseudo-code statement that logically defines the rule, and the implementation as a db constraint or other middle-ware code/object that enforces it at the physical layer.
I don't see lots of companies taking the time to do it, but to ensure provenance of the data, those are the pieces of the puzzle that need to be put in place.