Betrachten Sie ein Gemischtwarenladenszenario (ich mache das), wo Sie FACT-Datensätze haben, die eine Verkaufstransaktion darstellen, wobei die Spalten der Faktentabelle
enthalten %Vor%Selbst wenn es in der Tabelle Duplikate gibt, wenn Sie ALLE Schlüssel in Betracht ziehen, würde ich behaupten, dass ein stellvertretender laufender numerischer Schlüssel (d. h. Identitätsspalte) aufgebaut sein sollte, z. B. TransactionNumber vom Typ Integer.
Ich kann jemanden sehen, der argumentiert, dass eine Faktentabelle möglicherweise keinen eindeutigen Schlüssel hat (obwohl ich einen erfinden und die 4 Bytes verschwenden würde, aber wie wäre es mit einer Dimensionstabelle?
Das erste normale Formular benötigt einen Primärschlüssel für jeden Tisch. Dies ist das absolute Minimum, das für ein gutes Datenbankdesign erforderlich ist. Was Sie für den Primärschlüssel wählen, ist offen für viele Diskussionen. Aber die erste normale Form für das Datenbankdesign ist nicht.
Ein Grund für viele, einen eindeutigen Schlüssel pro Zeile zu haben (aus den Daten oder sonstwie), ist die Erleichterung von Aktualisierungen oder Löschungen für diese bestimmte Zeile.
In jedem Fall ist diese Frage ziemlich albern, weil es wirklich keinen technischen Kompromiss gibt. Es gibt keinen wirklichen Vorteil darin, den Schlüssel nicht zu haben. Worum geht es also? Wahr / Ja, Zeilen sollten eindeutige Bezeichner haben.
Weil sich Ihre Frage unter datawarehousing befindet:
Dimensionstabellen sollten einen Ersatz- (bedeutungslosen) Primärschlüssel haben, normalerweise eine Ganzzahl mit automatischer Inkrementierung; und einen Geschäftsschlüssel, der ein Objekt eindeutig identifiziert, das in der Tabellenzeile beschrieben wird - wie eine E-Mail-Adresse, ein vollständiger Name oder Ähnliches.
Faktentabellen haben meistens (fast immer) einen Primärschlüssel, der eine Kombination aus zwei oder mehr Fremdschlüsseln ist.
Es sollte keine Duplikate in Fakttabellen geben, wenn Fremdschlüssel in den Primärschlüssel kombiniert werden. Um dies zu testen, versuchen Sie einfach, die gleiche Transaktion zweimal zu laden - es sollte fehlschlagen. Ein automatisch generierter Primärschlüssel verhindert dies nicht, da er außerhalb des Warehouse nicht existiert. Das Problem kann normalerweise gelöst werden, indem der Zeitstempel in den Primärschlüssel eingefügt wird.
Manchmal wird eine Faktentabelle als Dimension oder in einer Ansicht verwendet, die als Dimension fungieren kann. In diesem Fall ist es sinnvoll, anstelle mehrerer FK-Felder eine (große) Ganzzahl als Primärschlüssel zu verwenden. Die ursprüngliche Kombination von FKs und Zeitstempeln sollte jedoch die Fakt-Zeile immer noch eindeutig identifizieren.
Für Data Warehouses haben Fakttabellen oft einen zusammengesetzten Primärschlüssel, normalerweise die Zusammensetzung aller Fremdschlüssel für Ihre Dimensionstabellen.
Es ist ziemlich üblich, dass Sie auch keinen Primärschlüssel in Ihren Faktentabellen haben, da diese oft keinen anderen Zweck haben, als Platz zu verschwenden - und bei großen Datawarehouses kann der Platz ziemlich groß sein. Ihre Dimensionstabellen haben jedoch Primärschlüssel.
Wenn Sie über den OLTP-Teil Ihres Lebensmittelgeschäfts sprechen, würden Sie normalerweise dem Standard-OLTP-Datenbankdesign folgen, Ihre Tabellen normalisieren und einen Primärschlüssel bereitstellen.
Wahr. Denken Sie konzeptionell, alles ist einzigartig, auch wenn es nicht durch eindeutige Daten definiert ist. Wenn Sie also Daten in eine Tabelle eingeben und genau die gleichen Informationen haben, sind sie immer noch eindeutig, da sie zweimal eingegeben wurden.
Wenn Sie das verlassen, haben Sie den Vorteil, dass Sie auf der Basis der ID zu relativ niedrigen Kosten (4 Bytes) einfach auswählen, aktualisieren und löschen können. Je größer die Tabelle, desto nützlicher ist die ID. So werden die 4 Bytes immer weniger zu einem Punkt, je größer die Tabelle: -)
Tags und Links database-design data-warehouse