Re: ERwin and Informix

On May 20, 11:27pm, Bill MacLean wrote: > Subject: Re: ERwin and Informix Up front I should say that I use ERwin almost daily but have never evaluated Infmodeller. Having not experienced it please don't take my statements as being against that approach. I wanted to demonstrate some issues I had with the claims made here. > > Actually ERWin does not work the same way. ERWin is based on IDEF1X, > which is a logical modeling language. Infomodeler is based on Object > Role Modeling, which is a conceptual modeling language. I will give a > few examples of the differences in a second but here is asummary of > some of the most important: > 1) ORM is conceptual, IDEF1X is logical. ORM models are not > specifically tied to the relational structure, though they can be > mapped very effectively to relational databases. I'm not sure that many people would understand the difference you are making between a conceptual and a logical modelling language. Consider that I draw what I have called conceptual and logical models in ERwin depending on the target audience for which I am creating a model. I sort of use the ANSI three schema architecture but I'm not rigid in my terminology use. I doubt you mean the same thing as I do. > > 2) ORM is much more closely tied to natural language. ORM facts are > quite close to natural language. This is a big benefit in > communicating with users during the design process. There are advanatges and disadvantages to this approach. Natural language can help people who have never done modelling before but they can also be confusing and with large models difficult to get an overall picture. > > 3) ORM models can be populated with sample instances of fact types, > IDEF1X models cannot (that i know of). There are text areas in ERwin for populating sample instances information along with sample queries, attribute definitions and notes, etc. From the examples below it may be that ORM models take this beyond the basic typing in of examples and later reporting on them. > > 4) ORM has a more robust constraint notation than IDEF1X (e.g. ring > constraints, join constraints, set operators.) An example is set > operators between logical attributes. How do you graphically represent > the rule "A person can be given a company car, OR given a car > allowance, but not both". If they are given at most one car, or at > most one allowance amount, then car and allowance are both attributes > of the Person entity. In ORM, a simple set exclusion constraint takes > care of the rule. In ERWin, how would you represent such a constraint? By using Sub-Types. A sub-type is a an exclusive or condition. It's very easy to show sub-types both complete and incomplet in ERwin inculding specifying the subtype discriminator. I don't recognise the terminology used for the other constraints but I suspect that ERwin has the equivalent. I should point out that this would be done in conceptual models of the business area and in logical models of a database not necessarily in the physical database model. The physical model could use sub-types but is more likly to use check constraints depending on the performance and design requirements. Generally you do need two models as your physical model rarely maps directly to your logical or facts as you almost always change it around to meet your performance requirements. > > 5) ORM allows n-ary facts, and does not force binarization. Check fact > 2 below for an example. I'm not sure what is meant here as fact 2 is easily show in an ERwin model as a child of SalesRep with a unique index on all attributes. > 6) Normalization completely automatic with ORM, as it is accomplished > by the algorithim that maps the conceptual model to a logical schema. Now a 5NF checker in ERwin would be nice!! How far does ORM go? > With ORM, you simply identify data objects and the roles they play with > each other. This is different than trying to identify entities and > attributes. All objects are treated as equal at the conceptual level. > What you're really modeling with ORM (and Infomodeler) is business > facts and rules. The input to Infomodeler is business facts and rules, > the output is a logical model, and ultimately DDL for your chosen > database. You type the facts in, and then you add sample populations > and constraints based on those samples. Infomodeler then automatically > draws a graphic representation of the fact. Here is an example of what > some of these facts would look like in English (taken straight from a > small model) You do much the same thing with ERwin though you don't treat all objects as equal as the relationships between entities (object) define business rules that the business articulates to you. Actually everything you put in the model define business rules that have been stated. This applies to all the facts, business rules and constraints you mention. What appears to be the difference is that your business people don't have to learn IDEF1X notation to read the rules. This depends on how clearly this can be presented. You note above that ORM develops a logical model for the database. You don't say what notation this in, even whether it is an ER diagram, but a diagram can often help people understand the global requirements better than a set of facts and figures. Assuiming that there is somebody to help them understand the diagram. > 2. SalesRep earns bonus of MoneyAmount for Year > Each (SalesRep, MoneyAmount, Year) combination is unique > Examples: > SalesRep '1' earns bonus of MoneyAmount '10000' for Year '1995' > SalesRep '1' earns bonus of MoneyAmount '10000' for Year '1994' > SalesRep '2' earns bonus of MoneyAmount '10000' for Year '1995' > SalesRep '2' earns bonus of MoneyAmount '5000' for Year '1995' > > These facts come from a sample model that I made for client during a > demo. After getting the user to help me create the facts, I go through > facts and constraints one by one. The populations really help, because > many people feel more comfortable working with concrete data than > abstract fact types. Look at fact 2. The last two rows look kind of > fishy, because you should probably just say SalesRep '2' earned '15000' > for the year, in which the constraint should be different (Uniqueness > over SalesRep and Year only). Or, it may be that the fact doesn't tell > the entire story, because you really want to track quarterly, or > perhaps semi-annual bonuses. Either way, the population helped point > out an error early on, well before any code was written. I agree with this but its equally true of correct analysis using ERwin. > Another example: looking at facts 2 and 3 along with their sample > populations makes it clear that the current model will support > historical tracking of SalesRep's bonus amounts, but not of their > salaries. This may be a deficiency in the model (then again, the > historical tracking of bonuses may be overkill), but it can be caught > easily when the facts are clearly stated with their supporting sample > data. This would be equally clear from an ERwin model perhaps clearer as the moneyamount earned would just be an attribute of SalesRep. > Th