March 25, 2010 at 3:19 am
Michael Valentine Jones (3/24/2010)
The time spent gaining a good understanding of the business process and modeling the data pays off in faster development and lower maintenance costs.
I think this is the main problem: the database desing comes after processes and data-flow analysis, that can have been done poorly. A perfect database design based on a poor modeling of the business will be as good as a poor db design.
-- Gianluca Sartori
March 25, 2010 at 5:44 am
I got you.
Is there any standards in which normalization can be double checked/audited-? That will almost have to be a totally manual effort by a 3rd party, not? I don't think Erwin tool can say 'OK, you did a good job', can it?
March 25, 2010 at 7:13 am
ErWin can do some checks, but it tests for some basic mistakes, that's it. This is a quote from Erwin manual:
...ERwin provides some support for normalization of data models, but does not currently contain a full normalization algorithm...
In a model, each entity or attribute is identified by its “name.” ERwin will accept any name for an object, with the following exceptions:
? ERwin will flag a second use of an entity name (depending on your preference for unique names).
? ERwin will flag a second use of an attribute name, unless that name is a role name. When rolenames are assigned, the same name for an attribute may be used in different entities.
? ERwin will not let you bring a foreign key into an entity more than once without unifying the like columns.
By preventing multiple uses of the same name, ERwin is basically prompting you to put each fact in exactly one place. There may still be second normal form errors if you place an attribute incorrectly, but no algorithm would find that without more information than is present in a model.
...
ERwin does not currently know about functional dependencies, but it can help to prevent second and third normal form errors. ...By preventing the multiple occurrence of foreign keys without role names, ERwin is reminding you to think about what the structure represents....
Hope this falls into the "fair use" of the manual, I'll have to ask Steve Jones about that. And, eventually remove the quote.
-- Gianluca Sartori
March 25, 2010 at 9:04 am
repent_kog_is_near (3/24/2010)
Paul,Do you have a link for Kimball's star-schema that you refer to, for OLAPs?
For a good starter, Google "A Dimensional modelling manifesto"
March 25, 2010 at 12:54 pm
I think this is the main problem: the database desing comes after processes and data-flow analysis, that can have been done poorly. A perfect database design based on a poor modeling of the business will be as good as a poor db design.
Absolutely. The design is a model of something that exists. If your model diverges from that which is being modeled then you are hosed. Suffering and poor code will follow. A consistent model is functional, a consistent model which can accommodate possible future changes, that would be sublime. Normalization can help you accommodate change.
March 25, 2010 at 1:28 pm
repent_kog_is_near (3/24/2010)
Paul,Do you have a link for Kimball's star-schema that you refer to, for OLAPs?
My pleasure... try this one http://www.consolidata.co.uk/Data-Warehousing/What-is-DWH/Star-Schema/default.aspx
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.March 26, 2010 at 4:10 pm
I recommend you stay away from Kimball at least until you are confident of enough knowledge and experience to evaluate what he says properly. Personally, I think that most of what RK peddles under the "dimensional modelling" banner is vacuous and sometimes dangerous nonsense. I am far from alone in that opinion. Try reading Bill Inmon, Terry Halpin and Chris Date's books as well for some alternative views and approaches based on genuine science rather than dogma.
PaulB-TheOneAndOnly (3/24/2010)
I do believe there is nothing you can't solve with 3NF for OLTP purposes.
Are you saying that problems related to join dependencies (and solved by 5NF) are never important? Or that you try to solve them in other ways?
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply