it-swarm.com.de

Kann eine schwache Entität einen Primärschlüssel haben?

Entschuldigen Sie wahrscheinlich eine sehr grundlegende Frage, aber in der Literatur und im Internet bin ich auf zwei verschiedene Definitionen von schwachen Entitäten gestoßen, die manchmal widersprüchlich sein können.

1) Eine schwache Entität ist eine Entität, die ohne eine andere (Eigentümer-) Entität nicht existieren kann.
2) Eine schwache Entität hat keinen Primärschlüssel, sondern einen Teilschlüssel und kann nur durch Kombinieren dieses Teilschlüssels mit einem Fremdschlüssel der Eigentümerentität eindeutig identifiziert werden.

Welches davon ist wahr? Nehmen wir das Beispiel Kunden-> Auftragsbeziehung, in der Aufträge eine eindeutige Bestell-ID haben. Hier kann eine Bestellung nicht ohne einen Kunden existieren, sie hat jedoch immer noch einen eigenen Primärschlüssel. Wäre es dann eine starke oder eine schwache Einheit?

4
shiftyscales

Der Primärschlüssel ist eine Möglichkeit, eine Zeile in einer einzelnen Tabelle von allen anderen Zeilen in derselben Tabelle zu unterscheiden. Es ist keine Möglichkeit, eine Zeile im Kontext der zugehörigen Zeilen von anderen Tabellen zu unterscheiden.

Manchmal besteht der Primärschlüssel einer Tabelle aus einer einzelnen Spalte. Die Benutzer-ID einer Person wäre ein Beispiel.

Manchmal besteht es aus mehreren Spalten. Ein Ort ist sowohl Längen- als auch Breitengrad. Dies ist als zusammengesetzter Schlüssel bekannt. Manchmal können eine oder mehrere dieser Spalten auch ein Fremdschlüssel sein. Dies wird als schwacher Entitätstyp bezeichnet.

Um Ihr Beispiel zu nennen: Könnte eine einzelne Zeile in der Tabelle "Bestellungen" von allen anderen Zeilen allein durch die Bestellnummer unterschieden werden? Normalerweise ja. Die Bestellnummer ist systemweit eindeutig. Angesichts der Bestellnummer 8765 wissen wir, dass dies für Kunde A gilt. Dies macht Order zu einem starken Entitätstyp.

Wie wäre es mit der OrderLine-Tabelle? Können wir bei einer einzelnen Bestellzeilennummer, z. B. "1", eindeutig herausfinden, auf welche Bestellung sich diese bezieht? In der Regel nein, da die Bestellnummern für jede Bestellung erneut beginnen. OrderLine ist daher eine schwache Entität, da für ihren Primärschlüssel (Bestellnummer, Bestellzeilennummer) der Primärschlüssel aus einer anderen verwandten Tabelle erforderlich ist, d. H. Order.

Nach den Regeln von Geschäft macht es keinen Sinn, dass eine Bestellung ohne den Kunden existiert, aber nach den Regeln von Datenbank ist dies in Ordnung. Eine OrderLine kann ohne die Order nach beiden Regeln nicht existieren.

5
Michael Green

Sie sind beide korrekte Definitionen. Aufträge sind eine starke Einheit. Es existiert für sich. OrderItems wären jedoch schwach. Es hat eine Bestellnummer (Fremdschlüssel) und eine Zeilennummer (Teilschlüssel). Es ist nur eindeutig mit beiden identifiziert.

Schwache Entitäten haben zusammengesetzte Primärschlüssel.

http://www.ques10.com/p/3828/we-can-convert-any-entity-set-to-a-strong-entity-s/

Stellen Sie sich einen Entitätssatz "Zahlung" mit drei Attributen vor: "Zahlungsnummer", "Zahlungsdatum" und "Zahlungsbetrag". Obwohl jede Zahlungseinheit unterschiedlich ist, kann die Zahlung für verschiedene Kredite dieselbe Zahlungsnummer haben. Daher hat dieser Entitätssatz keinen Primärschlüssel und ist ein Entitätssatz. Jede schwache Menge muss Teil einer Eins-zu-Viele-Beziehungsmenge sein. Ein schwacher Entitätssatz ist aus folgenden Gründen erforderlich:

  1. Um Inkonsistenzen zu vermeiden, die durch das Duplizieren des Schlüssels der starken Entität verursacht werden.

ich. Obwohl schwache Entitätsmengen durch einfaches Hinzufügen geeigneter Attribute in starke Entitätsmengen umgewandelt werden können, führt dieser Ansatz zur redundanten Speicherung des Primärschlüssels.

ii. Der Primärschlüssel eines schwachen Entitätssatzes kann aus seiner Beziehung zum starken Entitätssatz abgeleitet werden. Wenn wir dem schwachen Entitätssatz Primärschlüsselattribute hinzufügen, sind diese sowohl im Entitätssatz als auch im Beziehungssatz vorhanden und müssen identisch sein.

iii. Daher wird das ER-Diagramm redundant sein und wir verlieren das Konzept der Abhängigkeit.

iv. In dem oben erwähnten Beispiel führt das Hinzufügen eines Primärschlüsselattributs zum schwachen Entitätssatz Zahlung zu einer redundanten Speicherung des Primärschlüssels.

4
indiri