Ich werde das Szenario kommentieren, das ich derzeit beim Entwerfen meiner Datenbank habe.

Ich habe folgende Tabellen:

user (id, name, lastname)

role (id, name)

user_role (user_id, role_id, from_date, to_date)

period (id, name, from_date, to_date)

Die Periodentabelle dient als Datenstamm, um den Namen der Perioden zu kennen, die ich in meiner Anwendung definiert habe.

In diesem Fall erwähne ich nur die Tabellen user, role und user_role, aber es gibt viel mehr Tabellen mit Punkten.

Die Absicht des Periodenplans besteht darin, als Kennzeichnungssystem für die verschiedenen Perioden zu fungieren, die in den Tabellen meines Modells vorhanden sind. Diese Tabelle ist in keiner Weise durch einen Fremdschlüssel mit anderen Tabellen verbunden. Um die Suche durchzuführen und andere Tabellen damit in Beziehung zu setzen, wird ein Join mit Datumsangaben von und Datumsangaben zu erstellt.

Beispielsweise kann ein Tupel der Tabelle user_role ein Datum von und ein Datum bis haben, das mehrere in der Periodentabelle definierte Perioden abdeckt, sodass es mit den Namen der Perioden gekennzeichnet wird, aus denen es besteht.

Ist es in Ordnung, wenn die Tabelle period eine nicht verwandte Tabelle ist? Es dient nur dazu, den Perioden Namen zu geben, deshalb habe ich es so ausgedrückt. Können Sie sich einen anderen besseren Weg vorstellen, um es zu erhöhen? Sollte die Periodentabelle auf andere Weise mit den anderen Tabellen verknüpft sein?

Danke im Voraus.

2
Mr. Mars 23 Feb. 2020 im 15:02

5 Antworten

Beste Antwort

Tabellen (Basen, Ansichten und Abfrageergebnisse) repräsentieren Beziehungen (Schiffe) / Assoziationen. FK-Einschränkungen (Fremdschlüssel) werden manchmal als "Relation (Schiff) s" bezeichnet, sind es aber nicht. Sie sind Tatsachenaussagen. Sie sagen, dass Unterzeilen an anderer Stelle als PK (Primärschlüssel) oder EINZIGARTIG erscheinen. dass Unternehmen einmal anderswo teilnehmen. Tabellenbedeutungen sind notwendig und ausreichend zum Abfragen. Einschränkungen - einschließlich PKs, UNIQUE, NOT NULL, CHECK & FKs - sind für die Abfrage weder erforderlich noch ausreichend. Sie dienen der Durchsetzung der Integrität durch das DBMS. (Wenn jedoch Einschränkungen gelten, geben zusätzliche Abfragen dieselben Ergebnisse zurück wie Abfragen, bei denen keine Einschränkungen angenommen werden.)

Deklarieren Sie Einschränkungen, wenn sie gelten und nicht durch bereits deklarierte Einschränkungen impliziert sind, und deklarieren Sie sie nicht, wenn sie nicht gelten oder durch bereits deklarierte Einschränkungen impliziert sind.

Abfragen & Einschränkungen.

1
philipxy 5 März 2020 im 02:35

Die Frage, ob die Periodentabelle eine nicht verwandte Tabelle sein kann, ist schließlich eine Geschäftsfrage und kann nur von Ihnen / Ihren Geschäftsanforderungen beantwortet werden ...;) Wenn z. Ihre Benutzerrolle bezieht sich auf einen oder mehrere Zeiträume. In der Benutzerrollentabelle sollte anstelle des Start- und Enddatums eine FK vorhanden sein, oder, wenn viele zu viele, eine Beziehungstabelle. Wenn die Definition von Perioden einer anderen Logik folgt und überlappende Perioden oder asynchrone Zuweisungen von Ereignissen zu Daten / Perioden zulässt, können Sie keine Beziehung zueinander haben.

0
Andreas 5 März 2020 im 01:56

Der Zeitraum bezieht sich auf user_role. Beide haben from_date- und to_date-Spalten, die sich aufeinander beziehen.

Sie haben keine Fremdschlüsselbeziehung, aber Sie können Ihre Periodentabelle unbedingt mit Ihrer user_role-Tabelle verknüpfen, wenn Sie dies möchten.

Ich glaube nicht, dass es einen besseren Weg gibt, dies zu entwerfen, da Ihre Perioden willkürlich sind und eine Viele-zu-Viele-Beziehung zu Ihren Benutzerrollen haben.

0
Geoff Griswald 4 März 2020 im 17:51

Sie haben also zwei Situationen.

Situation eins (Fremdschlüssel) Sie beziehen sich auf einen Punkt aus Ihrer anderen Tabelle. Nehmen wir an, Tabelle x bezieht sich über period_id auf die Periodentabelle. Wenn Sie den Zeitraum für viele Zeilen aktualisieren müssen, die denselben Zeitraum verwenden, müssen Sie nur eine Zeile in der Periodentabelle aktualisieren. Der Vorteil dieser Lösung besteht darin, dass Sie nur 1000 Zeilen aktualisieren müssen, wenn Sie 1000 Zeilen in Tabelle x haben, die sich auf einen Zeitraum beziehen, und nicht die 1000 Zeilen. Wenn sich mehrere Zeilen in mehreren Tabellen auf denselben Zeitraum beziehen, müssen Sie nur eine Zeile in der Periodentabelle aktualisieren. Der Nachteil ist, dass Sie, wenn Sie einen Zeitraum wünschen, der sich von den vorhandenen Zeiträumen unterscheidet, einen neuen Zeitraum erstellen und auf den Zeitraum aus Tabelle x verweisen müssen, anstatt nur Tabelle x zu aktualisieren.

In Situation zwei speichern Sie den Zeitraum in Tabelle x Wenn Sie nicht auf die Periodentabelle aus Tabelle x verweisen, ist es einfacher, die Periode anzupassen. Sie müssen nur die Tabelle x anstelle des Datensatzes in der Periodentabelle aktualisieren.

Wenn Sie also keine Daten zwischen vielen Zeilen austauschen, sind die Vorteile von Situation eins nicht vorhanden und Situation zwei ist besser.

2
Sven van den Boogaart 5 März 2020 im 11:21

Sie machen Zeitdimensionen in Bezug auf Data Warehousing. Und Sie müssen keine Beziehung zu anderen Tabellen haben. Diese Tabelle wird nur zur Suche verwendet und kann basierend auf dem Datumsintervall verwendet werden.

2
Digvijay S 3 März 2020 im 06:08