Hinsichtlich der Beziehungen zwischen Klassen weist die erste Version der Objektmodells dieselben Defizite auf, wie die SNMP-MIB: Es existiert keinerlei Vererbungshierarchie; Containment-Hierarchien sind nur ansatzweise vorhanden. Ein Grundgedanke des objektorientierten Paradigmas ist es jedoch, die reale Welt, d.h. die einzelnen Objekte sowie ihre Beziehungen zueinander, möglichst gut abzubilden. Die Einführung einer Vererbungshierarchie ist ein Modell für den Sachverhalt, daß eine Systemkomponente eine Spezialisierung einer anderen ist. So ist z.B. ein Mikroprozessor eine Spezialisierung eines Gerätes (Device).
Zur Wurzel des Enthaltenseins- bzw. Containment-Baumes wird die Klasse System bestimmt. Dies entspricht auch der Realität: Ein (End-)System ist diejenige Hauptkomponente, die andere Teilkomponenten enthält. Dabei sollten Enthaltenseinsbeziehungen der Objektklasse System mit möglichst spezialisierten Klassen bestehen, also Klassen, die sich im Vererbungsbaum weiter ,,unten`` befinden. Damit können die einzelnen Beziehungen individuell gestaltet werden: So benötigt ein System mindestens einen Prozessor (hier also eine 1:n-Beziehung mit n1), jedoch kann es beliebig viele permanentStorageDevices besitzen (in diesem Fall eine 1:n-Beziehung mit n0). Ein Drucker wiederum ist kein unmittelbarer Bestandteil eines Systems (im Sinne einer Workstation), sondern ein Peripheriegerät. Hier besteht also keine Aggregationsbeziehung , sondern eine einfache 1:n-Beziehung mit n0. Wäre die Beziehung zwischen System und ,,höher`` liegenden Klassen modelliert worden, so wäre eine individuelle Gestaltung nicht möglich gewesen, da jede Subklasse dieselbe Beziehung zu System wie die entsprechende Superklasse gehabt hätte. Abbildung gibt einen Überblick über die Beziehungsstruktur eines Teils des optimierten Objektmodells.
Eine weitere Besonderheit findet sich in der Beziehung zwischen den Klassen Filesystem und Account (vormals die User-Klasse). Die Klasse Account enthält in der SNMP-MIB Attribute, die benutzerspezifische Quoten für Betriebsmittel wie zum Beispiel Plattenplatz darstellen. Dies ist semantisch nicht korrekt, da Quoten keine Eigenschaft eines Benutzers sind, sondern eine Eigenschaft der Beziehung zwischen einem Benutzer und einem Dateisystem. Aus diesem Grund werden die entsprechenden Attribute ausgelagert und unter der Assoziationsklasse Quota zusammengefaßt. Abbildung veranschaulicht dies.