views:

470

answers:

6

There are couples of questions around asking for difference / explanation on identifying and non-identifying relationship in relationship database.

My question is, can you think of a simpler term for these jargons? I understand that technical terms have to be specific and unambiguous though. But having an 'alternative name' might help students relate more easily to the concept behind.

We actually want to use a more layman term in our own database modeling tool, so that first-time users without much computer science background could learn faster.

cheers!

A: 

One could use connection.

You have Connection between two tables, where the IDs are the same.

That type of thing.

Kyle Rozendo
A: 

how about

  • Association
  • Link
  • Correlation
Andrew Keith
+3  A: 

I often see child table or dependent table used as a lay term. You could use either of those terms for a table with an identifying relationship

Then say a referencing table is a table with a non-identifying relationship.

For example, PhoneNumbers is a child of Users, because a phone number has an identifying relationship with its user (i.e. the primary key of PhoneNumbers includes a foreign key to the primary key of Users).

Whereas the Users table has a state column that is a foreign key to the States table, making it a non-identifying relationship. So you could say Users references States, but is not a child of it per se.

Bill Karwin
+1  A: 

I'm going to recommend the term "weak entity" from ER modeling.

Some modelers conceptualize the subject matter as being made up of entities and relationships among entities. This gives rise to Entity-Relationship Modeling (ER Modeling). An attribute can be tied to an entity or a relationship, and values stored in the database are instances of attributes.

If you do ER modeling, there is a kind of entity called a "weak entity". Part of the identity of a weak entity is the identity of a stronger entity, to which the weak one belongs.

An example might be an order in an order processing system. Orders are made up of line items, and each line item contains a product-id, a unit-price, and a quantity. But line items don't have an identifying number across all orders. Instead, a line item is identified by {item number, order number}. In other words, a line item can't exist unless it's part of exactly one order. Item number 1 is the first item in whatever order it belongs to, but you need both numbers to identify an item.

It's easy to turn an ER model into a relational model. It's also easy for people who are experts in the data but know nothing about databases to get used to an ER model of the data they understand.

There are other modelers who argue vehemently against the need for ER modeling. I'm not one of them.

Walter Mitty
But "weak entity" is the name of the dependent entity type, not the identifying relationship type, and I think that was what requested?
Thomas Padron-McCarthy
+1  A: 

Nothing, absolutely nothing in the kind of modeling where one encounters things such as "relationships" (ER, I presume) is "technical", "precise" or "unambiguous". Nor can it be.

A) ER modeling is always and by necessity informal, because it can never be sufficient to capture/express the entire definition of a database.

B) There are so many different ER dialects out there that it is just impossible for all of them to use exactly the same terms with exactly the same meaning. Recently, I even discovered that some UK university that teaches ER modeling, uses the term "entity subtype" for the very same thing that I always used to name "entity supertype", and vice-versa !

Erwin Smout
+3  A: 

I think belongs to would be a good name for the identifying relationship.

A "weak entity type" does not have its own key, just a "partial key", so each entity instance of this weak entity type has to belong to some other entity instance so it can be identified, and this is an "identifying relationship". For example, a landlord could have a database with apartments and rooms. A room can be called kitchen or bathroom, and while that name is unique within an apartment, there will be many rooms in the database with the name kitchen, so it is just a partial key. To uniquely identify a room in the database, you need to say that it is the kitchen in this particular apartment. In other words, the rooms belong to apartments.

Thomas Padron-McCarthy
'belongs to' is also a nice one. Many Active Record implementations (e.g. ruby on rails) also use that. I wish I could accept 2 answers. Thanks again Thomas!
karlkma
Yes, I like 'belongs to' as well. +1!
Bill Karwin
But today I think I've changed my mind, and would rather call it - identifying relationship! It's the relationship that you use to identify which room it is, and perhaps that's not harder to explain than "belongs to"?
Thomas Padron-McCarthy