Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am finding it difficult to get together in a single place the different types of relationships used for different things and would like to find out which I have correct and incorrect and the proper "technical" terms for the different types of relationships. An example:

In database we have:
One to One
One to Many
Many to Many

I beleive (although I may be wrong hense the question) that these types of relationships are collectively termed "Multiplicity" relationships. Is this correct, and if so, are there other names for it.

In programming we have:

I beleive (and may be very wrong here) that these are different types of "Compound" relationships. If they are all the same type of compound relationship then is there other names for it. If they are different, how are they named.

I would also like to know if there are other relationship types in general database / programming world that would be used to some degree without going into obscurity like some sort of unused sci-fi "molocular mumbo jumbo bumbo" relationship. Just keeping to what would be generally useful in the real world.

I think I have a good understanding of the different relationship types, its more the terms used to describe them, and comming up with a brief 2 or 3 line description that really sums it up (assuming someone has allready got a fair understaiding).

Knowing the technical terms properly and clearly will help me should I need to advise others on what to look for elsewhere.

Can anyone offer suggestions on this for me without getting overly technical. Thanks in advance.


migration rejected from stackoverflow.com Jul 10 '13 at 15:11

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by user61852, Kilian Foth, thorsten müller, MichaelT, Jimmy Hoffa Jul 10 '13 at 15:11

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

One-to-many relationships are synonymous with foreign key relationships for databases. –  Andrew Lee Aug 10 '11 at 16:33
I assume you mean multiplicity as one to many is one type of multiplicity relationship, hense foreign key relationships would also include many to many or one to one. Am I wrong about this. Or does foreign key relstionships refere "only" to one to many types and therefoere is a special type of multiplicity relationship. Thanks for your answer. –  Francis Rodgers Aug 10 '11 at 16:39
Foreign key relationships don't include many-to-many, since an object with a foreign key reference can only refer to one other object. –  Andrew Lee Aug 10 '11 at 16:46
For those mathematical types out there thinking I was talking about different types of relationships, in english, thats called a play on words! :-> The last sentence was another one. Cause I actually was talking about "different types" of relationships but in a database or programming enviorment. I could have phrased that to be another play on words but didnt want the literal types getting too confused! :-) Thanks for all the answers so far. –  FranAsm Aug 13 '11 at 21:05

3 Answers 3

Inheritance: "Is A Type Of"
Encapsulation: "Is A Part Of"
Polymorphism: "Call the method having the specified number and type of arguments"

Inheritance is a one-to-many only in those languages that support multiple inheritance, like C++. In C#, it's a one-to-one with classes, but a one-to-many with interfaces.

Encapsulation is a one-to-many: one class object, many members.

Polymorphism is a one-to-many: one method name, many argument signatures.

This really breaks down the whole programming side of relationships. I have nothing to pick at. Just out of curiosity, what is the technical name for the relationship that describes inheritance. Was I right to say it is a compositional as opposed to multiplicity. Or does it depend on weather you describe in in the first way or the second. I would have voted this answer up, but I dont have the points. –  FranAsm Aug 10 '11 at 19:38
Collectively, those relationships are called a hierarchy: see en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) for most of the technical terms. –  Robert Harvey Aug 10 '11 at 19:40
Compositional is a bit of a red herring: "Favor composition over inheritance." –  Robert Harvey Aug 10 '11 at 19:42
Thank you for that wiki link. It provides an interesting talk on another topic "composite reuse principle" which I found even more interesting. More importantly, I have found the correct term for these types of relationships, as you pointed out it is "Hierarchacal". Thank you. It is now unfortunate that I cant pick this as my accepted answer because it does not deal with the other side of the question "Multiplicity". This is much better delt with by another user. But I do appreicate your answer, and will vote you up when my points increase. Thanks again for your excellent answer. –  FranAsm Aug 13 '11 at 16:24

The terms "One to Many" and family actually aren't part of the relational model at all. They are instead part of the entity-relationship language that's used for describing systems. It happens that entity relationship analysis is a convenient way to build a relational model of a system, and the relational model has the advantage of many efficient (near) implementations (in the form of SQL databases).

There are corresponding notions in the relational model, that map closely to the ideas of one-to-many and similar; namely functional dependence. By carefully designing the features of the fields of particular tables, it's possible to enforce or allow, at the schema level, the "multiplicity" of dependent data. This mostly takes the form of specifying certain columns be unique or nullable, other columns to have foreign key constraints of a particular sort, and specifying the particular range of values a particular column is permitted to take.

  • When a relation (in the relational model sense, think 'table') has a functional dependence on a key (some unique combination of columns in a table) in some other relation (even the same relation itself), this happens to mean that there is a unique row in that second relation (called the 'referent' or 'independent') that is associated with the row in the first (called the 'reference' or 'dependent'), although more than one row in the dependent relation may have this property for a given row in the referent, This is how a one-to-many entity-relationship is described in the relational model.
  • In the above example, if the columns in the dependent relation that reference the other relation are themselves a key (unique), then instead of being one-to-many, the entity-relationship is one-to-one, since only one row in the dependent table can have that foreign key value.
  • If a relation is dependent on two separate relations (or the same relation on two, distinct attributes), then it happens that there is a many-to-one entity relationship from one referent to the dependent, and another one-to-many entity relationship from the dependent to the other referent, which indirectly implies a many-to-many entity relationship between the two independent relations. It's possible to express an association between any combination of rows in the two relations.

The entity-relationship approach of describing systems applies equally to other representations of systems, it maps quite naturally to the compositional aspect of OOP. The fact that ER works so naturally with both OOP and RM is a good reason why the terminology of ER leaks into many object-relational mapping libraries.

A nice explanation of ER's. And an excellent way to understand functional depandancy. Which I am having difficulty with. While it is a nice answer, it doesnt really answer my question. Which is, what is the technical term used to call these types of relationships, and how does it fit into the whole "Multiplicity / Compound" jargon. I know these are not the right words to use to describe these types of relationships, this is why I am looking for others. But thank you kindly for taking the time to provide your excellent answer. –  FranAsm Aug 13 '11 at 16:03
I would have liked to make this my accepted answer, but unfortunately, like the user who answered the programming side of the question, you answered the database side. Both of you have answered very well. But on different sides of the question. Also your answer is not fully complete, is "Multiplicity" the correct term, or is there another. The programming side has found a more fitting term than compound shows that "Hierarchacal" is the better term for those types of relationships. Again, thank you for your answer. –  FranAsm Aug 13 '11 at 16:31
the phrase used to describe 'One-To-Many' and family is simply 'entity relationships' –  SingleNegationElimination Aug 13 '11 at 19:14

Most relationships in databases are quite different from the relationships you will find in object oriented programming and there is no strong relationship between these types of relationships. This is what is called the object-relational impedance mismatch and that is why ORM mappers like Hibernate exist. ORM layers were invented to bridge the gap between relational relationships and object relationships. They translate the relations in your relational base to object relations like composition, aggregation and even inheritance.

Describing polymorphism as a one-to-many relationship, because you can overload a method by giving it different arguments is wrong in multiple ways. First, overloading is overloading: creating multiple methods with the same name, but with different arguments. Overloading is not polymorphism (multiple implementations of the same abstract type). Secondly, both overloading and polymorphism don't explain the nature of relationships between objects and the relationships between database tables and the differences and similarities between them. When we are talking about relationships in this context we should be talking about has-a relationships in OO and foreign key relationships in databases and how they are different and where they are somewhat the same.

The types of OO relationships that have an equivalent in relational databases are in my humble opinion only aggregation and composition.


In composition and object A has one or more other objects which can be seen as "parts" of object A. This means the parts of A are useless without A and must be destroyed along with A. A good example is a Car and its wheels, clutch, steering wheel, etc. Let's say a Car has a collection of CarParts.

class Car {
    Collection<CarPart> carParts;

When the Car gets destroyed the CarParts will be destroyed ad well, because they are "owned" by the car.

Another example of composition:

class House {
    Collection<Room> rooms;

If the house is destroyed, the.... well, you probably get the point by now.

Composition in a relational database can be expressed by having a one-to-many relationship (Car to CarParts or House to Rooms) and setting a CASCADE DELETE on the reference(s) to the records on the many-side, so the Rooms get deleted with the House and the CarParts get deleted with the Car.


In an aggregation relationship an object A also has a relationship (or relationships) to other objects, but the other objects can live without its container A.

class House {
    Collection<Room> rooms; // composition
    Collection<Resident> residents // aggregation

I think you will get the idea. When we destroy the house the rooms are also gone, because they make up the house. The residents however, should be spared. They can continue to live and move to another House and live a happy life there.

The aggregation relationship can be modeled in a relational database by having a one-to-many relationship with a CASCADE NO ACTION constraint. In this way, the resident records in the Resident table will be untouched when the House record is deleted from the House table.


Now, it is technically possible to model an inheritance relationship in a database. But this relationship is not part of relational "lingo". It's more of an OO thing. Depending on the strategy you choose, you will have to apply some tricks and deal with some tradeoffs, like data duplication or the loss of referential integrity to achieve an inheritence relationship in a relational database. If you want to know how it can be done, you can have a look at the different strategies Hibernate offers: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html. You can implement these without Hibernate as well.


Not the answer you're looking for? Browse other questions tagged or ask your own question.