Shane Hathaway wrote:
Well, Evan, I'm having a hard time interpreting the paper you referenced that way. The paper seems to use "relation" and "relationship" interchangeably. What it describes are relationships and relationship sets. A relationship set is a set of relationships of the same type.
Yup. Since Relationship seems to be a natural class name for these thingies, I wanted to avoid calling individual things that they contain relationships.
This one seems to use only the terms "relationship" and "relationship set". In fact, the next chapter of the course introduces relations and the relational algebra, which are clearly distinct concepts from ERM.
Actually the next chapter starts off with "A row in a table represents a relationship among a set of values. Thus a table represents a collection of relationships." :-) Of course, this is consistent with what you state above. I'm happy to call them whatever, I just wanted to try to avoid making up terminology when some exists.
I'll ponder the rest of your email once we've agreed on common definitions.
It basically boils down to defining a relationship by listing the roles of entities that it relates. I also suggest declaring one-many type constraints among entitites in a relationship using a simple nested list notation. No involvement of the entities' classes is required, and in fact the relationship definition can use strings for role names and avoid caring what class/type/kind of entity will fill that role altogether. That might be problematic for APE, though, which I imagine would be happiest knowing exactly what class of object will fill each role. Cheers, Evan @ 4-am