Quelle est la différence entre association, agrégation et composition?
Quelle est la différence entre association, agrégation et composition? S'il vous plaît expliquer en termes de mise en œuvre.
Pour les deux objets, Foo et Bar, les relations peuvent être définies
Association - J'ai une relation avec un objet. Foo utilise Bar
public class Foo {
void Baz(Bar bar) {
}
};
Composition - Je possède un objet et je suis responsable de sa durée de vie. Lorsque Foo meurt, Bar
public class Foo {
private Bar bar = new Bar();
}
Agrégation - J'ai un objet que j'ai emprunté à quelqu'un d'autre. Lorsque Foo décède, Bar peut survivre.
public class Foo {
private Bar bar;
Foo(Bar bar) {
this.bar = bar;
}
}
Je sais que cette question est étiquetée comme C # mais les concepts sont assez génériques des questions comme celle-ci redirect ici. Je vais donc présenter mon point de vue ici (un peu biaisé du point de vue de Java où je suis plus à l'aise).
Lorsque nous pensons à la nature orientée objet, nous pensons toujours aux objets, à la classe (plans d’objets) et aux relations qui les unissent. Les objets sont liés et interagissent les uns avec les autres via des méthodes. En d'autres termes, l'objet d'une classe peut utiliser des services/méthodes fournis par un objet d'une autre classe. Ce type de relation s'appelle association..
L'agrégation et la composition sont des sous-ensembles d'association, ce qui signifie qu'il s'agit de cas spécifiques d'association.
- À la fois dans l'agrégation et dans la composition, objet d'une classe "possède" l'objet d'une autre classe.
- Mais il y a une différence subtile. Dans Composition, l'objet de la classe qui appartient à l'objet de sa classe propriétaire ne peut pas vivre seul (appelé également "relation mortelle"). Il vivra toujours en tant que partie de son objet propriétaire, où, comme dans Aggregation, l'objet dépendant est standalone et peut exister même si l'objet de la classe propriétaire est mort.
- Donc, dans la composition, si l'objet propriétaire est récupéré, l'objet appartenant sera également ce qui n'est pas le cas dans l'agrégation.
Confus?
Exemple de composition: Prenons l'exemple d'une voiture et d'un moteur très spécifiques à cette voiture (ce qui signifie qu'elle ne peut être utilisée dans aucune autre voiture). Ce type de relation entre les classes Car et SpecificEngine est appelé Composition. L'objet de la classe Car ne peut exister sans l'objet de la classe SpecificEngine et l'objet de SpecificEngine n'a aucune signification sans la classe Car. En termes simples, la classe Car "possède" la classe SpecificEngine.
Exemple d'agrégation: Considérons maintenant la classe Car et la classe Wheel. Car a besoin d'un objet Wheel pour fonctionner. Signification Objet de voiture propre objet Roue mais nous ne pouvons pas dire que l'objet Roue n'a aucune signification sans Objet de voiture. Il peut très bien être utilisé dans un vélo, un camion ou un objet Cars différent.
En résumé -
Pour résumer, l’association est un terme très générique utilisé pour représenter lorsqu’une classe est utilisée les fonctionnalités fournies par une autre classe. Nous disons qu'il s'agit d'une composition si un objet de classe parent possède un autre objet de classe enfant et que cet objet ne peut pas exister de manière significative sans l'objet de classe parent. Si c'est le cas, cela s'appelle Agrégation.
Plus de détails ici. Je suis l'auteur de http://opensourceforgeeks.blogspot.in et j'ai ajouté un lien ci-dessus au message correspondant pour plus de contexte.
Association est un concept généralisé de relations. Il comprend à la fois Composition et Agrégation.
Composition (mélange) permet d'envelopper des objets simples ou des types de données dans une unité unique. Les compositions sont un élément essentiel de nombreuses structures de données de base
Aggregation (collection) diffère de la composition ordinaire en ce sens qu'il n'implique pas la propriété. En composition, lorsque l'objet propriétaire est détruit, les objets contenus le sont également. En agrégation, ce n'est pas nécessairement vrai.
Les deux dénotent une relation entre un objet et ne diffèrent que par leur force.
Astuce pour se rappeler la différence: a A -A agrégation et O wn - cO mpositoin
Maintenant, observons l'image suivante
Analogie:
Composition: L'image suivante est une composition d'image, c'est-à-dire l'utilisation d'images individuelles pour créer une image.
Agrégation: collection d'images en un seul endroit
Par exemple, Une université possède plusieurs départements et chaque département compte un certain nombre de professeurs. Si l'université ferme ses portes, les départements n'existeront plus, mais les professeurs de ces départements continueront d'exister. Par conséquent, une université peut être considérée comme une composition de départements, alors que les départements regroupent des professeurs. En outre, un professeur peut travailler dans plus d’un département, mais un département ne peut pas appartenir à plus d’une université.
Dépendance (références)
Cela signifie qu'il n'y a pas de lien conceptuel entre deux objets. par exemple. L'objet EnrollmentService référence les objets Student et Course (en tant que paramètres de méthode ou types de retour)
public class EnrollmentService {
public void enroll(Student s, Course c){}
}
Association (has-a)
Cela signifie qu’il existe presque toujours un lien entre les objets (ils sont associés). L'objet commandea un objet client
public class Order {
private Customer customer
}
Agrégation (a-une + partie entière)
Type spécial d’association où il existe une relation entière entre deux objets. ils pourraient vivre sans l'autre cependant.
public class PlayList{
private List<Song> songs;
}
Remarque: la partie la plus délicate consiste à distinguer l'agrégation de l'association normale. Honnêtement, je pense que cela peut donner lieu à différentes interprétations.
Composition (has-a + part entière + propriété)
Type particulier d'agrégation. Une Apartment est composée de Rooms. Une Room ne peut exister sans une Apartment. Lorsqu'un appartement est supprimé, toutes les pièces associées sont également supprimées.
public class Apartment{
private Room bedroom;
public Apartment() {
bedroom = new Room();
}
}
D'après un message de Robert Martin dans comp.object :
L'association représente la capacité d'une instance d'envoyer un message à une autre instance. Ceci est généralement implémenté avec un pointeur ou une variable d'instance de référence, bien qu'il puisse également être implémenté en tant qu'argument de méthode ou en tant que création d'une variable locale.
//[Example:]
//|A|----------->|B|
class A
{
private:
B* itsB;
};
L'agrégation [...] est la relation typique tout/partie. Ceci est identique à une association, à l'exception que les instances ne peuvent pas avoir de relations d'agrégation cycliques (c'est-à-dire qu'une partie ne peut pas contenir l'intégralité de celle-ci).
//[Example:]
//|Node|<>-------->|Node|
class Node
{
private:
vector<Node*> itsNodes;
};
Le fait qu'il s'agisse d'une agrégation signifie que les instances de Node ne peuvent pas former un cycle. Il s’agit donc d’un arbre de nœuds et non d’un graphe de nœuds.
La composition [...] est identique à l'Agrégation, sauf que la durée de vie de la "partie" est contrôlée par le "tout". Ce contrôle peut être direct ou transitif. Autrement dit, le «tout» peut assumer la responsabilité directe de la création ou de la destruction de la «partie», ou accepter une partie déjà créée et la transmettre ensuite à un autre ensemble qui en assume la responsabilité.
//[Example:]
//|Car|<#>-------->|Carburetor|
class Car
{
public:
virtual ~Car() {delete itsCarb;}
private:
Carburetor* itsCarb
};
Comme d'autres l'ont dit, une association est une relation entre des objets, l'agrégation et la composition sont des types d'association.
Du point de vue de la mise en œuvre, une agrégation est obtenue en ayant un membre de classe par référence. Par exemple, si la classe A agrège un objet de la classe B, vous obtiendrez quelque chose comme ceci (en C++):
class A {
B & element;
// or B * element;
};
La sémantique de l'agrégation est que lorsqu'un objet A est détruit, l'objet B qu'il stocke existe toujours. Lorsque vous utilisez la composition, vous avez une relation plus forte, généralement en stockant le membre par valeur:
class A {
B element;
};
Ici, lorsqu'un objet A est détruit, l'objet B qu'il contient sera également détruit. Le moyen le plus simple d'y parvenir consiste à stocker le membre par valeur, mais vous pouvez également utiliser un pointeur intelligent ou supprimer le membre dans le destructeur:
class A {
std::auto_ptr<B> element;
};
class A {
B * element;
~A() {
delete B;
}
};
Le point important est que dans une composition, l'objet conteneur possède l'objet contenu, alors que dans l'agrégation, il le référence.
Il est étonnant de voir combien de confusion existe entre la distinction entre les trois concepts de relation association, agrégation et composition.
Notez que les termes agrégation et composition ont été utilisés dans la communauté C++, probablement pendant un certain temps avant d'être définis comme cas spéciaux de association dans la classe UML. Diagrammes.
Le problème principal est le malentendu généralisé et persistant (même parmi les concepteurs de logiciels experts) selon lequel le concept de composition implique une dépendance du cycle de vie entre le tout et ses parties, de telle sorte que les composants ne peuvent pas exister sans le tout, en ignorant le fait qu'il existe cas d'associations partielles avec des parties non partageables où les parties peuvent être détachées de l'ensemble et survivre à leur destruction.
Autant que je sache, cette confusion a deux racines:
Dans la communauté C++, le terme "agrégation" a été utilisé dans le sens d'une classe définissant un attribut pour référencer des objets d'une autre classe indépendante (voir, par exemple, [1]), qui est le sens de association dans les diagrammes de classes UML. Le terme "composition" a été utilisé pour les classes qui définissent des objets composants pour leurs objets. Ainsi, lors de la destruction de l'objet composite, ces objets composants sont également détruits.
Dans les diagrammes de classes UML, les termes "agrégation" et "composition" ont été définis comme des cas particuliers d'associations représentant des relations partie-entière (discutées en philosophie depuis longtemps). Dans leurs définitions, la distinction entre une "agrégation" et une "composition" est basée sur le fait si elle permet de partager une partie entre deux ou plusieurs ensembles. Ils définissent les "compositions" comme ayant des parties non partageables (exclusives), tandis que les "agrégations" peuvent partager leurs parties. En outre, ils disent quelque chose comme ce qui suit: très souvent, mais pas dans tous les cas, les compositions présentent une dépendance du cycle de vie entre le tout et ses parties, de sorte que les parties ne peuvent exister sans le tout.
Ainsi, bien qu'UML ait placé les termes "agrégation" et "composition" dans le bon contexte (relations partielles), ils ne sont pas parvenus à les définir de manière claire et sans ambiguïté, capturant ainsi les intuitions des développeurs. Cependant, cela n’est pas surprenant, car ces relations peuvent avoir tant de propriétés différentes (et de nuances d’implémentation) et les développeurs ne s’accordent pas sur la façon de les implémenter.
Voir aussi ma réponse détaillée à la question SO d'avril 2009 ci-dessous.
Et la propriété supposée définir la "composition" entre les objets OOP de la communauté C++ (et cette conviction est encore largement répandue): la dépendance du cycle de vie d'exécution entre les deux objets liés (le composite et son composant), n’est pas vraiment caractéristique de la "composition" car nous pouvons avoir de telles dépendances en raison de l’intégrité référentielle également dans d’autres types d’associations.
Par exemple, le modèle de code suivant pour "composition" a été proposé dans une réponse SO :
final class Car {
private final Engine engine;
Car(EngineSpecs specs) {
engine = new Engine(specs);
}
void move() {
engine.work();
}
}
L'intimé a soutenu qu'il serait caractéristique de la "composition" qu'aucune autre classe ne puisse référencer/connaître le composant. Cependant, ce n'est certainement pas vrai pour tous les cas possibles de "composition". En particulier, dans le cas d'un moteur de voiture, le fabricant de la voiture, éventuellement mis en œuvre avec l'aide d'une autre classe, peut être amené à faire référence au moteur pour pouvoir contacter le propriétaire de la voiture chaque fois que le problème survient.
[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/
Annexe - Liste incomplète de questions répétées sur la composition et l'agrégation sur StackOverflow
[Avril 2009]
Agrégation ou composition [fermé principalement sous l'angle des opinions]
[Avril 2009]
Quelle est la différence entre une relation de composition et d’association? [Mai 2009]
Différence entre association, agrégation et composition
[Mai 2009]
Quelle est la différence entre composition et agrégation? [dupliquer]
[Oct 2009]
Quelle est la différence entre agrégation, composition et dépendance? [marqué comme duplicata]
[Nov 2010]
Association vs. Agrégation [marqué en double]
[Août 2012]
Différence d’implémentation entre l’agrégation et la composition en Java
[Février 2015]
UML - association ou agrégation (extraits de code simples)
Association
Association représente la relation entre deux classes.Il peut être unidirectionnel (un sens) ou bidirectionnel (deux sens)
par exemple:
- unidirectionnel
Le client passe ses commandes
- bidirectionnel
A est marié à B
B est marié à A
Agrégation
L'agrégation est une sorte d'association.Mais avec des caractéristiques spécifiques.L'agrégation est la relation dans une classe "entière" plus grande qui contient une ou plusieurs classes "parties" plus petites. classe plus grande.
par exemple:
le club a des membres
Un club ("entier") est composé de plusieurs membres du club ("parties"). Les membres ont la vie à l'extérieur du club. Si le club ("entier") devait mourir, les membres ("parties") ne mourraient pas avec lui. Parce que le membre peut appartenir à plusieurs clubs ("entier").
Composition
C’est une forme d’agrégation plus forte. Le "tout" est responsable de la création ou de la destruction de ses "parties"
Par exemple:
Une école a des départements
Dans ce cas, l'école ("entière") devait mourir, le département ("parties") mourrait avec elle . Chaque partie ne pouvant appartenir qu'à un "tout".
Composition (Si vous supprimez "entier", "partie" est également supprimé automatiquement - "Propriété")
Créez des objets de votre classe existante dans la nouvelle classe. Ceci est appelé composition car la nouvelle classe est composée d'objets de classes existantes.
Utilisez généralement des variables de membre normales.
Peut utiliser des valeurs de pointeur si la classe de composition gère automatiquement l'allocation/désallocation responsable de la création/destruction de sous-classes.
Composition en C++
#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
int nEngineNumber;
public:
Engine(int nEngineNo);
~Engine(void);
};
Engine::Engine(int nEngineNo)
{
cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
int nCarColorNumber;
int nCarModelNumber;
Engine objEngine;
public:
Car (int, int,int);
~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
cout<<" Car :: Destructor " <<endl;
Car
Engine
Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
int nBusColorNumber;
int nBusModelNumber;
Engine* ptrEngine;
public:
Bus(int,int,int);
~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
ptrEngine = new Engine(nEngineNo);
cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
cout<<" Bus :: Destructor " <<endl;
delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
freopen ("InstallationDump.Log", "w", stdout);
cout<<"--------------- Start Of Program --------------------"<<endl;
// Composition using simple Engine in a car object
{
cout<<"------------- Inside Car Block ------------------"<<endl;
Car objCar (1, 2,3);
}
cout<<"------------- Out of Car Block ------------------"<<endl;
// Composition using pointer of Engine in a Bus object
{
cout<<"------------- Inside Bus Block ------------------"<<endl;
Bus objBus(11, 22,33);
}
cout<<"------------- Out of Bus Block ------------------"<<endl;
cout<<"--------------- End Of Program --------------------"<<endl;
fclose (stdout);
}
Sortie
--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------
Agrégation (Si vous supprimez "entier", une "partie" peut exister - "Aucune propriété")
Une agrégation est un type de composition spécifique dans lequel aucune propriété entre l'objet complexe et les sous-objets n'est impliquée. Lorsqu'un agrégat est détruit, les sous-objets ne sont pas détruits.
En règle générale, utilisez des variables de pointeur/variable de référence qui pointent vers un objet qui vit en dehors de la portée de la classe d'agrégat
Peut utiliser des valeurs de référence qui pointent vers un objet qui vit en dehors de la portée de la classe d'agrégat
Pas responsable de la création/destruction de sous-classes
Code d'agrégation en C++
#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
private:
string m_strName;
public:
Teacher(string strName);
~Teacher(void);
string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
return m_strName;
}
/********************** Department Class ******************/
class Department
{
private:
Teacher *m_pcTeacher;
Teacher& m_refTeacher;
public:
Department(Teacher *pcTeacher, Teacher& objTeacher);
~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
freopen ("InstallationDump.Log", "w", stdout);
cout<<"--------------- Start Of Program --------------------"<<endl;
{
// Create a teacher outside the scope of the Department
Teacher objTeacher("Reference Teacher");
Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
{
cout<<"------------- Inside Block ------------------"<<endl;
// Create a department and use the constructor parameter to pass the teacher to it.
Department cDept(pTeacher,objTeacher);
Department
Teacher
Figure 2: Aggregation
} // cDept goes out of scope here and is destroyed
cout<<"------------- Out of Block ------------------"<<endl;
// pTeacher still exists here because cDept did not destroy it
delete pTeacher;
}
cout<<"--------------- End Of Program --------------------"<<endl;
fclose (stdout);
}
Sortie
--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------
Le problème avec ces réponses, c’est qu’elles représentent la moitié de l’histoire: elles expliquent que l’agrégation et la composition sont des formes d’association, mais elles ne précisent pas s’il est possible qu’une association ne soit ni l’une ni l’autre.
Je suppose que, sur la base de brèves lectures de nombreux articles sur SO et de documents UML, il existe 4 formes concrètes principales d’association de classes:
- composition: A est composé d'un B; B n'existe pas sans A, comme une pièce de maison
- agrégation: A a-a B; B peut exister sans A, comme un élève dans une classe
- dépendance: A utilise-a B; aucune dépendance de cycle de vie entre A et B, comme un paramètre d'appel de méthode, une valeur de retour ou un temporaire créé lors d'un appel de méthode
- généralisation: A est-a B
Lorsqu'une relation entre deux entités n'en fait pas partie, on peut simplement l'appeler "association" au sens générique du terme et décrire plus en détail d'autres moyens (note, stéréotype, etc.).
Je suppose que "l'association générique" est destinée à être utilisée principalement dans deux circonstances:
- quand les détails d'une relation sont encore en cours d'élaboration; une telle relation dans un diagramme doit être convertie dès que possible en ce qu’elle est/sera réellement (l’une des 4 autres).
- lorsqu'une relation ne correspond à aucune des 4 relations prédéterminées par UML; l'association "générique" vous donne toujours le moyen de représenter une relation qui n'est "pas une des autres", de sorte que vous n'êtes pas coincé en utilisant une relation incorrecte avec une note "ceci n'est pas réellement une agrégation, c'est juste que UML n'a aucun autre symbole que nous pourrions utiliser "
Composition : C'est là où une fois que vous détruisez un objet (Ecole), un autre objet (Salles de classe) qui lui est lié sera également détruit. Les deux ne peuvent pas exister indépendamment.
Agrégation : C'est en quelque sorte l'exact opposé de l'association ci-dessus (Composition) dans laquelle une fois que vous tuez un objet (Company), l'autre objet (Employees) qui lui est lié peut exister par lui-même.
Association .
Composition et agrégation sont les deux formes d’association.
Je pense que ce lien fera votre travail: http://ootips.org/uml-hasa.html
Pour comprendre les termes, je me souviens d'un exemple de mes débuts en programmation:
Si vous avez un objet 'échiquier' contenant des objets 'boîte' qui est composition, car si cet 'échiquier' est supprimé, il n'y a plus de raison que les boîtes existent.
Si vous avez un objet "carré" qui a un objet "couleur" et que le carré est supprimé, l'objet "couleur" peut toujours exister, c'est-à-dire aggregation
Les deux sont associations, la différence principale est conceptuelle
J'aimerais illustrer comment les trois termes sont implémentés dans Rails. ActiveRecord appelle association tout type de relation entre deux modèles. On ne trouve pas très souvent les termes composition et aggregation lors de la lecture de documents ou d'articles liés à ActiveRecord. Une association est créée en ajoutant l'une des macros de la classe d'association au corps de la classe. Certaines de ces macros sont belongs_to, has_one, has_many etc ..
Si nous voulons configurer composition ou aggregation, nous devons ajouter belongs_to au modèle possédé (également appelé enfant) et has_one ou has_many au modèle propriétaire (également appelé parent). Que nous configurions composition ou aggregation dépend des options que nous passons à l'appel belongs_to dans le modèle enfant. Avant Rails 5, la configuration de belongs_to sans aucune option créait une aggregation, l’enfant pouvait exister sans parent. Si nous voulions une composition, nous devions le déclarer explicitement en ajoutant l'option required: true:
class Room < ActiveRecord::Base
belongs_to :house, required: true
end
Dans Rails 5, cela a été changé. Désormais, la déclaration d'une association belongs_to crée une variable composition par défaut; l'enfant ne peut exister sans parent. Ainsi, l'exemple ci-dessus peut être réécrit comme suit:
class Room < ApplicationRecord
belongs_to :house
end
Si nous voulons permettre à l'objet enfant d'exister sans parent, nous devons le déclarer explicitement via l'option optional
class Product < ApplicationRecord
belongs_to :category, optional: true
end
Dans une phrase très simple:
L'agrégation et la composition sont des sous-ensembles de l'association.
A utilise B -> c'est une agrégation
A a besoin de B -> sa composition.
Lire plus ici .
Simple rules:
A "owns" B = Composition : B has no meaning or purpose in the system
without A
A "uses" B = Aggregation : B exists independently (conceptually) from A
A "belongs/Have" B= Association; And B exists just have a relation
Example 1:
A Company is an aggregation of Employees.
A Company is a composition of Accounts. When a Company ceases to do
business its Accounts cease to exist but its People continue to exist.
Employees have association relationship with each other.
Example 2: (very simplified)
A Text Editor owns a Buffer (composition). A Text Editor uses a File
(aggregation). When the Text Editor is closed,
the Buffer is destroyed but the File itself is not destroyed.
De: livre de Remo H. Jansen "Début de réaction: apprendre TypeScript 2.x - Deuxième édition":
Nous appelons association ces relations dont les objets ont un cycle de vie indépendant dans lequel il n'y a pas de propriété des objets. Jetons un coup d'oeil à l'exemple d'un enseignant et d'un élève. Plusieurs étudiants peuvent être associés à un seul enseignant, et un seul étudiant peut être associé à plusieurs enseignants, mais les deux ont un cycle de vie indépendant (les deux peuvent créer et supprimer indépendamment). Ainsi, lorsqu'un enseignant quitte l'école, nous n'avons pas besoin de supprimer d'élèves, et lorsqu'un élève quitte l'école, nous n'avons pas besoin de supprimer d'enseignants.
Nous appelons agrégation ces relations dont les objets ont un cycle de vie indépendant, mais il existe une propriété, et les objets enfants ne peuvent pas appartenir à un autre objet parent. Prenons l'exemple d'un téléphone portable et d'une batterie de téléphone portable. Une seule batterie peut appartenir à un téléphone, mais si le téléphone cesse de fonctionner et si nous la supprimons de notre base de données, la batterie du téléphone ne sera pas supprimée car elle pourrait toujours fonctionner. Ainsi, en agrégation, pendant qu’il y a propriété, les objets ont leur cycle de vie
Nous utilisons le terme composition pour désigner les relations dont les objets n'ont pas de cycle de vie indépendant. Si l'objet parent est supprimé, tous les objets enfants seront également supprimés. Prenons un exemple de la relation entre les questions et les réponses. Les questions simples peuvent avoir plusieurs réponses, et les réponses ne peuvent pas appartenir à plusieurs questions. Si nous supprimons des questions, les réponses seront automatiquement supprimées.