Schwache Entität
In einer relationalen Datenbank handelt es sich bei schwachen Entitäten um Entitäten, welche nicht alleine durch deren Attribute identifiziert werden können. Deshalb müssen Fremdschlüssel verwendet werden, um gemeinsam mit den restlichen Attributen einen Primärschlüssel zu bilden. Bei dem Fremdschlüssel handelt es sich hierbei üblicherweise um den Primärschlüssel der starken Entität, welche der schwachen Entität übergeordnet ist, beziehungsweise von welcher die schwache Entität abhängig ist. Die schwache Entität kann demzufolge nicht ohne die zugehörige starke Entität existieren.
Es gibt verschiedene Darstellungsformen für Entity-Relationship-Diagramme. In der Chen-Notation werden schwache Entitäten durch fett gedruckte oder umrandete Rechtecke dargestellt. Eine fett gedruckte oder umrandete Linie führt von der schwachen Entität zu einem Diamanten, welcher die Beziehung beschreibt und mit der übergeordneten starken Entität verbunden ist. Diese Art der Beziehung wird als identifizierende Beziehung bezeichnet und wird in IDEF1X-Notation durch eine ovale Entität anstatt einer rechteckigen Entität angezeigt. Bei identifizierenden Beziehungen wird der Primärschlüssel der übergeordneten starken Entität an die schwache Entität weitergegeben und dort für den zusammengesetzten Primärschlüssel verwendet.
Üblicherweise, jedoch nicht zwingend, enthalten Primärschlüssel von schwachen Entitäten keine anderen Attribute außer dem geerbten Primärschlüssel und einer fortlaufenden Nummer. Es gibt zwei Arten von schwachen Entitäten: Assoziative Entitäten und Subtype (Untertyp) Entitäten. Assoziative Entitäten werden verwendet um N:M-Beziehungen in relationalen Datenbanken aufzulösen und enthalten ausschließlich die Fremdschlüssel der zugehörigen Entitäten. Untertyp Entitäten verwenden geerbte Attribute von übergeordneten starken Entitäten und sind ein wichtiger Teil der Normalisierung von Datenbanken.
In IDEF1X sind zwei Arten der Untertyp-Beziehung möglich:
- vollständige Untertyp-Beziehung (Complete subtype relationship), falls alle Kategorien bekannt sind.
- unvollständige Untertyp-Beziehung (Incomplete subtype relationship), falls möglicherweise nicht alle Kategorien bekannt sind.
Ein Beispiel für eine schwache Entität ohne Untertyp-Beziehung wären "Header/Detail"-Anzeigen in verschiedenen realen Situationen, wie beispielsweise Bestellungen und Rechnungen, bei welchen der Header die gemeinsamen Informationen enthält, während die Details spezifische Informationen zu den einzelnen Artikeln beinhalten.
Das Standardbeispiel für vollständige Untertyp-Beziehungen ist eine Entität für Parteien. Durch den Diskriminator PARTY TYPE, welcher unter anderem Individuen, Partnerschaften, Unternehmen und behördliche Elemente beinhalten kann, sind zwei Untertyp-Entities notwendig: PERSON und ORGANIZATION. Wobei PERSON Informationen zu Individuen enthält, wie beispielsweise Vorname, Nachname und Geburtstag, während ORGANIZATION Attribute wie den vollständigen legalen Namen und organisatorische Hierarchien beinhaltet.
In Datenbanken werden Untertyp-Beziehungen dargestellt indem die übergeordnete starke Entität zu einer sogenannten Basis Tabelle wird. Die untergeordneten Entitäten werden davon abgeleitet und entsprechen demnach schwachen Entitäten. Referentielle Integrität wird durch kaskadierende Updates und kaskadierendes Löschen garantiert.
Beispiel
In diesem Beispiel geht es um eine Datenbank, welche die Bestellungen von Kunden abspeichert, wobei jede Bestellung einen oder mehrere zum Verkauf stehende Artikel beinhaltet. Die Datenbank enthält eine Tabelle für Kunden, welche anhand derer eindeutigen Kundennummer (Primärschlüssel) identifiziert werden. Eine andere Tabelle beinhaltet die zum Verkauf stehenden Artikel, welche durch Produktnummern (Primärschlüssel) identifiziert werden können. Außerdem enthält die Datenbank zwei weitere Tabellen um Bestellungen abzuspeichern.
Eine dieser Tabellen speichert direkt die Bestellungen, welche mit eindeutigen Bestellnummern (Primärschlüssel) identifiziert werden können. Außerdem werden auch die zugehörigen Kundennummern (Fremdschlüssel), sowie andere Informationen wie Datum, Uhrzeit, Lieferort und Zahlungsmethode, abgespeichert.
Die andere Tabelle speichert die bestellten Artikel ab, welche mittels eines zusammengesetzten Schlüssels aus der Bestellnummer (Fremdschlüssel) und einer Positionsnummer identifiziert werden. Andere Attribute, wie die Produktnummer (Fremdschlüssel) des bestellten Artikels, die Anzahl, der Preis, Rabatte und spezielle Optionen werden ebenfalls in dieser Tabelle abgespeichert. Es können keine, einer oder mehrere bestellte Artikel aus dieser Tabelle zu einer Bestellung aus der zuvor erwähnten Tabelle gehören. Allerdings können bestellte Artikel nicht ohne eine zugehörige Bestellung existieren. (Der Fall, dass keine bestellten Artikel zu einer Bestellung existieren, sollte im Normalfall nur auftreten, wenn die Bestellung erstmals abgespeichert wird und noch keine dazugehörigen bestellten Artikel eingegeben wurden.)
Jene Tabelle speichert also schwache Entitäten ab, da ein bestellter Artikel ohne eine zugehörige Bestellungen nicht existieren kann. Es kann argumentiert werden, dass ein bestellter Artikel auch ohne zugehöriger Bestellung Informationen enthält, da dadurch bekannt ist, das eine unbekannte Person zu unbekannter Zeit einen bestimmten Artikel bestellt hat. Diese Information kann verwertet werden, ist jedoch nicht von hohem Wert. Für Auswertungen von Entwicklungen und Trends über Zeiten oder Regionen sind die Informationen, welche in der Bestellungs Tabelle vorhanden sind, notwendig.
Eine Bestellung würde ohne Artikel und bestellender Person nicht existieren, demzufolge kann argumentiert werden, dass die Bestellung ebenfalls eine schwache Entität ist. In diesem Fall könnten die Attribute der bestellten Artikel auch in der Bestellungs-Tabelle abgespeichert werden.
Siehe auch
Wikipedia.de
© biancahoegel.de
Datum der letzten Änderung: Jena, den: 25.07. 2022