Supertyp / Subtyp, der zwischen Kategorie entscheidet: vollständige disjunkte oder unvollständige Überlappung

Ich erstelle eine Inventardatenbank, in der IT-Hardware wie Desktop-Computer, Laptops, Switches, Router, Mobiltelefone usw. gespeichert ist. Ich verwende ein Supertyp- / Subtyp-Muster, bei dem alle Geräte in einer einzigen Tabelle gespeichert sind, sowie spezifische Informationen wird in Subtyp-Tabellen abgelegt. Mein Dilemma besteht darin, zwischen den folgenden zwei Designs zu wählen:

Im oberen Diagramm haben alle Geräte gemeinsame Untertypen. Beispielsweise verfügen Desktop-Computer und Laptops über Datensätze in den folgenden Tabellen: Gerät, NetworkDevice. Ein Switch hätte Datensätze in: Device, NetworkDevice. Ein Router hätte Datensätze in: Device, NetworkDevice, WANDevice. Jedes Gerät, für das wir den Standort verfolgen, hat einen Datensatz im Standort. Einige Vor- und Nachteile, an die ich bei diesem Setup gedacht habe:

• Pro: Das Auswählen von Datensätzen basierend auf einem gemeinsamen Feld wie Hostname oder LocationID ist einfacher.
• Pro: Keine Nullfelder.
• Con: Tabellen, die in CRUD-Operationen für ein bestimmtes Gerät enthalten sein sollten, sind nicht offensichtlich und können zukünftige Datenbankadministratoren verwirren.

Im unteren Diagramm haben alle Geräte ihren eigenen Subtyp (Es gibt weitere Geräteklassen, die hier nicht angezeigt werden). In dieser Situation ist es offensichtlich, in welche Tabellendatensätze eingefügt oder aus diesen ausgewählt wird. Desktop-Computer und Laptops sind in Computer usw. enthalten. Einige Vor- und Nachteile, an die ich bei diesem Setup gedacht habe:

• Pro: Es ist sofort klar, welche Tabellen für CRUD-Operationen für Subtypen verwendet werden sollen.
• Pro: Für CRUD-Operationen muss nur eine Tabelle verwendet werden.
• Con: Um SELECT-Datensätze basierend auf gemeinsamen Subtypfeldern auszuwählen, müssen alle Tabellen kombiniert werden, z. B. die Suche nach Hostname oder LocationID.

In beiden Situationen wird das ClassDiscriminator-Feld in Subtyp-Tabellen platziert, um mit einer CHECK-Einschränkung zu steuern, welche Typen eingefügt werden können.

Gibt es Empfehlungen, für welche das Design besser ist, oder ist es völlig Ansichtssache und hängt vom beabsichtigten Zweck der Datenbank ab?

EDIT: Eine spezielle Frage, die ich bezüglich der Überlappung der Tabelle "NetworkDevice" habe. Diese Tabelle enthält Netzwerkinformationen für alle Geräte mit einem Hostnamen und / oder einer IP-Adresse, unabhängig davon, ob es sich um einen Computer, einen Switch oder einen Router handelt. Ist die Überlappung dieser Tabelle etwas, das Probleme verursachen könnte, oder ist es in Ordnung, sie auf diese Weise zu implementieren?

Vielen Dank im Voraus für jede Eingabe. Bitte fragen Sie, ob zusätzliche Informationen benötigt werden.

Die physische Implementierung der Untertypisierung in einer Datenbank ist ein komplexes Problem. Wenn Sie keine Situation haben, in der es überzeugende Vorteile bietet (siehe unten für ein oder zwei Beispiele), erhöht es die Komplexität der Implementierung und bietet relativ wenig Wert.

Nachdem ich dies mit wirklich komplexen Untertypen getan habe (Anträge und Urteile auf ein Gerichtsverfahrensverwaltungssystem, unterschiedliche gewerbliche Versicherungsvertragsstrukturen mit kombiniertem Risiko), habe ich wahrscheinlich einige Beobachtungen dazu. Einige wichtige Eckfälle sind:

• Wenn die Gesamtzahl der Datenbankfelder über die Subtypen hinweg relativ gering ist (z. B. weniger als 100) oder eine signifikante Gemeinsamkeit zwischen den Subtypen besteht, ist die Aufteilung der Subtypen in separate physische Tabellen wahrscheinlich von geringem Wert. Das Melden von Abfragen und Suchvorgängen erhöht den Aufwand erheblich. In den meisten Fällen ist es am besten, eine einzige Tabelle zu haben und Ihre Untertypisierung innerhalb der Anwendung zu verwalten. (Wahrscheinlich am nächsten an Ihrem Problem)

• Wenn Ihre Untertypisierung sehr unzusammenhängend ist und an verschiedenen Untertypen typabhängige Datenstrukturen hängen (z. B. untergeordnete Tabellen oder komplexere Strukturen), sind Untertypentabellen sinnvoll. In diesem Fall hat wahrscheinlich jeder Subtyp relativ wenig Gemeinsamkeiten innerhalb der Anwendung (dh es gibt wahrscheinlich ein ganzes Subsystem innerhalb der Anwendung, das diesem Subtyp zugeordnet ist). Die meisten Berichte und Abfragen werden wahrscheinlich innerhalb eines bestimmten Untertyps durchgeführt, wobei typübergreifende Abfragen hauptsächlich auf eine Handvoll allgemeiner Felder beschränkt sind. (Gerichtsverfahrensverwaltungssystem)

• Wenn Sie eine große Anzahl von Untertypen mit unterschiedlichen Attributen haben und / oder diese konfigurierbar machen müssen, sind möglicherweise eine generische Struktur und zusätzliche Metadaten besser geeignet. In diesem SO-Beitrag finden Sie eine Übersicht über einige mögliche Ansätze. (Verwaltungssystem für Versicherungspolicen)

• Wenn Sie eine sehr große Anzahl von Feldern haben, die für Ihre Untertypen wenig Gemeinsamkeiten aufweisen und nur wenig Abfragetabellen abfragen müssen (dh nicht viel in Bezug auf äußere Mehrwegverknüpfungen für Ihre Untertyptabellen), dann Typentabellen können bei der Verwaltung der Spaltenausbreitung hilfreich sein. (Pathologisch komplexe Version Ihres Problems)

• Einige O / R-Mapper unterstützen möglicherweise nur einen bestimmten Ansatz zum Verwalten von Unterklassen.

In den meisten Fällen sind physische Untertyp-Tabellen in einem DB-Schema eine Lösung für die Suche nach einem Problem, da sie möglicherweise unerwünschte Nebenwirkungen haben.

In Ihrem Fall gehe ich davon aus, dass Sie eine relativ bescheidene Anzahl von Untertypen und eine überschaubare Anzahl von Attributen haben. Ihr Diagramm und Ihre Frage weisen nicht auf die Absicht hin, untergeordnete Tabellen von den Datensätzen abzuhängen. Ich würde vorschlagen, dass Sie in Betracht ziehen, die oben vorgeschlagene erste Option zu verwenden und eine Tabelle zu verwalten und die Untertypisierung in Ihrer Anwendung zu verwalten.

Erwägen Sie zunächst die Entwicklung eines soliden logischen Datenmodells unter Verwendung der Regeln der Klassifizierungshierarchie für die Datenmodellierung in Enterprise Model Patterns , einem Buch von David Hay. Beim Erstellen einer Klassifizierungshierarchie darf jedes Vorkommen (jede Zeile) von einem und nur einem Untertyp sein. Dies bedeutet, dass sich die Untertypen gegenseitig ausschließen. Die Klassifizierung muss auf einem einzigen grundlegenden, unveränderlichen Merkmal beruhen. Die Verwendung dieser Grundregel verleiht Ihrem Modell viel Klarheit. In dem Modell, das Sie haben, ist das einzige Merkmal, das klassifiziert werden muss, der Zweck des Geräts - ein Telefon, ein Netzwerk-Switch, ein Computer, ein Router usw. Jedes Gerät muss von einem und nur einem dieser Typen sein. So wäre beispielsweise der Standort kein Untertyp. Attribute wie die IP-Adresse gehören zum Supertyp.

Ich denke, Sie werden feststellen, dass die Anzahl der Gerätetypen groß genug ist, um ein EAV-Muster zu rechtfertigen, wie in einer anderen Antwort erwähnt. Das Buch von David Hay, auf das ich mich beziehe, behandelt dieses Muster sehr effektiv. Wenn jedoch nur wenige Untertypen vorhanden sind, können Sie als Faustregel entscheiden, nur eine Supertyp-Tabelle mit vielen nullbaren Spalten, nur Untertyp-Tabellen mit doppelten Spalten oder beides zu implementieren. Wenn jeder Untertyp in seinen Attributen stark variiert und keine Beziehungen auf der Ebene des Supertyps aufweist, können Sie nur Untertyp-Tabellen verwenden. Wenn das Gegenteil der Fall ist, können Sie nur Super-Typ-Tabellen verwenden. Wenn es eine Mischung gibt, implementieren Sie beide.

Beachten Sie schließlich, dass Sie jederzeit ein EAV-Muster als Basistabellenschema implementieren und dann eine Ansichtsabstraktionsschicht erstellen können, die die Daten der Anwendung als Super- und Subtyp-Tabellen präsentiert. Dies gibt Ihnen Flexibilität auf der Speicherebene, aber Verständlichkeit auf der Anwendungsansichtsebene.

Ein Produkt ist kein Inventar. Inventar und Produkte sind unterschiedlich.

Ein Produkt ist wirklich eine Spezifikation eines Produkts, keine physische Sache.

Die physische Sache ist ein Vermögenswert, den das Unternehmen besitzt (oder speichert). Sie können Assets haben, die Sie nach Seriennummer (diskrete Assets) verfolgen, oder Assets, die Sie nur nach Menge verfolgen (Inventar-Assets).

Ich würde mir Silverstons Data Model Resource Book Vol 1 ansehen. Er hat ein gutes Schema für Stolz, Funktionen, Preise und Inventar. Das spart Ihnen viel Zeit.

Eine der Fragen, die ich stellen möchte, ist, warum Sie die verschiedenen Attribute Ihrer Inventargegenstände verfolgen. - Oder genauer gesagt, was machen Sie mit diesen Attributinformationen?

Wenn Sie viele Berichte oder Formulare haben, die bestimmte Attribute genau verstehen, müssen Sie den von ConcernedOfTunbridgeWell empfohlenen Ansatz verwenden. Wenn diese Attribute andererseits aufgezeichnet werden, um sie aufzulisten oder möglicherweise mit ähnlichen Attributen ähnlicher Geräte zu vergleichen, haben Sie möglicherweise tatsächlich eine (seltene) gute Entschuldigung für die Verwendung von EAV. Ich weiß, dass "EAV aus vielen Gründen rein böse ist", außer in sehr seltenen Fällen, in denen diese Gründe für eine bestimmte Anwendung keine Rolle spielen. Ihre könnte eine solche Anwendung sein.

Sehen Sie sich diese Antwort zum Entwurf eines Geräteinventarsystems und diese Antwort zum Entwurf eines Produktkatalogsystems an, um zu sehen, wie ein EAV-Ansatz Ihre Anwendung vereinfachen kann, und diskutieren Sie genau, welche Risiken EAV birgt und wie Beurteilen Sie, ob diese Risiken möglicherweise nicht für Ihre spezifische Anwendung gelten.