The ORM Foundation

I don't know how to respond directly in the "feature requests" part of this site so I'll have to put my comment here.

Comments on feature requests by "bvanskvier".

1: Your ORM diagram.
This does not make sense. 
Addresses do not have credit cards.

2: RE Your suggestion about putting the address data into the user table.
The purpose of ORM is to help people to define a Universe of Discourse in an unambiguous way.
Traditionally ORM has mapped to a 5NF logical model that preserves the property of "unambiguity".
Your suggestion would destroy this property.
I suggest you review chapter 1 of Terry's book "Information Modeling and Relational databases". You will also find it helpful to read Fabian Pascal's book " Practical Issues in Database Management"

Hope this helps
Ken

1. You are correct, Addresses do not have credit cards, but credit cards have a billing address. I just noticed that I did not put in predicate readings, which would have helped in this case.

2. I am not trying to change ORM, I just would like a way to control a little more how objects get mapped to tables. I realize that this would denormalize the objects a little, but sometimes controlled denormalization is a good thing. Please review Chapter 12.7 of Terry's book. As in this example, in my implementation of the database I don't care about keeping addresses unique, other then their ID. My application is not an address management system, I don't need addresses to be its own object. But I don't want to have to add the address facts to every object that has an address. I would like to be able to add an Address to an object and then automatically have all the facts related to Address then added to the parent object.

Maybe none of this makes sense to anyone else, I have deleted the request as noone seems to agree that it would be useful. I just know that in my pratical implementations of ORM and databases, this would be a useful feature to have in there.

OK,
I have prepared a word document that shows an OR model and a derived logical model. I'm not sure how to do attachments in this forum so until I figure that out here are my main points.

1: A credit card does not have a "billing address" It is the credit card holder who has the "billing address".

2: An object-role model is a statement of the collective truth of a set of assertions about a universe of discourse. An object-role model is either true or false. It has nothing whatsoever to do with performance.

2: Denormalization is a technique for solving performance problems. 

The concept of "performance" relates only to a physical instantiation of a logical schema. 

Hope this clarifies my position on this issue.
By the way, I believe that it is very important to hammer this out in this public forum. Byu doing that I hope that together we can help others to grasp the fundamental differences between Conceptual schema (ORM), Logical schema (R-table structures) and physical implementations (DBMS product and implementation dependent)

Regards
Ken

Following my previous post, I have uploaded the file into the "Feature Requests" section since I could not find any other way to upload.

Ken

1. I agree, credit cards don't actually have addresses, but you would then need a way to show which address a card uses. For example, I have an address that I live at, but I use a different address for one of my credit cards (my PO Box) for my billing address, while another card uses my home address.

2. So when you build ORM models and want to denormalize them for performance reasons, do you not change the ORM model and just the implentation of it? I have thought about doing that, but it becomes a hassle to make future changes in the ORM model and then propogate them to the implementation.

In 1, you are making assertions about your circumstances (the real world)
To record such "true facts" in ORM you might record the following facts: 
Person(ID)lives at Address(ID)
Person(ID)has mail sent to Address(ID)
Person(ID)works at Address(ID)

It is the Person that plays roles with multiple Addresses not the credit card.
 
You use ORM a a tool to record "true facts" about your "Universe of Discourse."
A set of facts is just a set of facts. it can be neither normalised nor denormalised.

If you change an OR model, the 5NF logical model that you then derive may be significantly different from the one that you had before the change. When you convert the new logical model to a new physical model then you may still have performance problems but they may well be quite different from those that you had in your original model. It all depends on the DBMS, hardware, application structure and so on.

It may seem a "hassle" to do the round trip work but that is the only way that you can be sure that your physical database structure is "true" i.e. that is is an accurate reflection of your Universe of Discourse.

In Terry's book (12.7) he says that denormalization is a "last resort" and should be done with extreme care.
 
The point is that when you change the table structure, you are changing what the database means. So "just changing the OR model" is a synonym for "just changing the facts".

In effect you are trying to change reality to solve a technical problem.
Changing reality is not a practice that I recommend :-)

Ken

1. Well, you still need to be able to record the fact that a certain address is related to a certain card. I guess you could do that with Person has mail sent to Address for CreditCard. Somehow that fact needs to be gathered.

2. I had hoped that you had some magical way that you knew to do the round trip stuff, maybe one day it will be there :)

I know nothing about ORM nor do I know what schema you are talking about but 
concerning #1 I'd have to say that accounts (creditcard, bank account) do have addresses. While the person is the owner of all the addresses you must have a way to tie an address to an account. In reality an account could have multiple holders each having various addresses, but the account must know which of the addresses is the account address. 

Case in point, Wells Fargo allows you to have an address that propigates to all your accounts. They also allow Debit and Credit Card accounts to have seperate addresses as the primary address, not to mention having a secondary address.

I know that I'm entering this conversation in the middle, but Ken I think that you need to explain why a CreditCard doesn't have an address and how you would determine the account address for a creditcard via the cardholder. 

Jake, 

I think it's times like this where "has" is over-used in ORM predicates.  I agree with Ken that a credit card doesn't have an address.  Not in the same way that I live at an address or that my computer is assigned an IP address.  However, I think it's fair to say that a credit card has its bill sent to a given address regardless of whether the person to whom the credit card is assigned actually lives there.  I had that problem pop up a few years ago, which is another story entirely...   

In my (limited) experience, when you're making an ORM schema it's a balancing act to decide which perspective you're viewing the Universe of Discourse from.  Ken lives in a people-centric world where systems care 

Bernd,
NORMA has what I'm told is a relatively simple way to add model extensions.  You can then record metadata about your object types and fact types, and then you could code an XSL transform based on that metadata to handle the denormalization for you.  The XSL is still an ugly process, but that way you can continue making your conceptual changes without having to hand-code all of your performance tweaks each time you regenerate the database schema.

If you wanted to go that route, you could maybe add a "denormalize me" attribute to "Address".  Then write an XSL to modify the OIAL output.  From our chat the other day, you could insert your transform between the ORM to OIAL and the OIAL to DCIL transforms.  The down side is that you'd be dealing with reams of undocumented schemas.  Ugh.

Currently, all the DDL is generated using XSLT.  I'd really like to see direct transforms based on ORM queries, but that's a ways down the road.  We need a good ORM2 meta-model (in ORM-- it exists in Microsoft's DSL tools framework at the moment) and a conceptual query language to make that work.  There's a conceptual query implementation planned to start this summer, so maybe check back then.

Until then, I continue to sheepishly denormalize my databases by saying, "Person has primary- Phone", "Person has secondary- Phone", etc.

Whoops!  I forgot to preview my last post.  My thought in the second paragraph was supposed to be continued....

Ken lives in a people-centric world where systems care that a person can live at an address, work at another address, and have their bills sent to yet another address.  In Jake's world, Corporate America stores every possible place they can send the bill to to make sure they get paid.  I think they're both valid facts, but you just have to decide on a UoD to take your perspective from.

Good, we have a debate!
It is true that everything depends on your UoD.
However, I'm still not convinced about the logic of "credit cards having an address".
Try subtracting objects and see what happens.

1: If you subtract one of the addresses, the credit card lives on and so does the account, the other addresses and the person.

2: If  subtract the credit card, the account still lives on and so do the addresses and the person.
3: If you subtract the person (e.g. death),
The physical addresses still exist but the credit card and account are meaningless. 

Why? Because a credit card is in reality just a number that links a physical or legal person and a bank account. 

I maintain my position: A credit card does not have an address. It is the person to whom the credit card is issued that has the address.

Corporate America can send a bill to wherever it likes, but unless the bill is addressed to the right PERSON it probably won't be paid - and rightly so.

Imagine you are the judge at the following court hearing:
Bank's lawyer: "We sent the bill to the address on our files."
Customer lawyer: "To whom was the bill addressed?"
Bank's lawyer" Oh, we just sent it to the address - we didn't put a name on it."

Who wins this case?

Ken  

Regarding your point 2 "round trip stuff".

The Microsoft tool can do this. The procedure is fully described in the book "Database Modeling with Microsoft Visio for Enterprise Architects" Morgan Kaufmann, 2003, ISBN 1-55860-919-9. 

Ken

"but the account must know which of the addresses is the account address"

Absolutely right.
However "the problem" is that we tend to speak in metaphors and forget what the metaphors mean when we use them.

A "bank account" is a metaphor for "a record of the transactions made by a legal or natural person"
  
Substituting in your phrase we get:
"but the 
[record of the transactions made by the person] must know which of the addresses is the 
[record of the transactions made by the person] address"

So it is clear that an "account" is about the activities of a Person.
The "linking" you mention is done by defining PK/FK relationships between tables such as "Person", "Transaction" and "Address".


Ken   

"Person has mail sent to Address for CreditCard. Somehow that fact needs to be gathered. "

Well, in my experience of opening bank accounts, the Bank always seems to be quite insistent on me filling out lots of forms that include "billing address".

Maybe I don't quite understand what you are getting at here. 

Ken   

"... a credit card has its bill sent to a given address regardless of whether the person to whom the credit card is assigned actually lives there."

Yesterday,I received a bill from the company from whom I buy water.

Three instances of "name and adress (NAD)" appeared in different places on the bill.

Instance 1 (on Page 1) headed : "Premises Supplied - Bill Amount"
DATA: Someone elses name and someone elses address.

Instance 2 (on Page 2) headed : "Premises Supplied - How your bill has been calculated"
DATA: Someone elses name and someone elses address. (the same data as in instance 1)

Instance 3: (at the bottom of Page 1) 
Was the "mailing address" that was printed in a position that ensured that the address showed through the window on the envelope.

DATA: Someone elses name (same as instances 1 & 2) but MY ADDRESS!

Note: The "someone else" is the person from whom I bought my house almost 4 years ago.

The NAD's in instance 1 and instance 2 are correct.
================================
Now what is going on here?

It is obvious that the data model in the water companies billing application is not true. It does not accurately reflect the "real" Universe of Discourse.

I don't know why this is the case. However, this kind of thing can happen when a technician alters a database structure 
 "to improve performance" without any grasp of the fact the he or she is changing the meaning of the axioms represented by the database.

Ken
  


1