Ich habe 4 ähnliche Tabellen (es ist ein Beispiel):

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

Angenommen, ich habe eine classificationmit id = 20, id_company = 1. Und ein departmentdas hat id_company = 2(das repräsentiert eine andere Firma).

Auf diese Weise können Sie einen Mitarbeiter aus zwei Unternehmen erstellen, da die Klassifizierung und die Abteilung separat mit dem Unternehmen verknüpft sind. Ich möchte nicht, dass das passiert, also denke ich, dass ich ein Problem mit meinen Beziehungen habe und ich weiß nicht, wie ich es lösen soll.

Ihr Problem beruht auf der Tatsache, dass in Ihrem Modell ein Entitätstyp fehlt. Betrachten Sie die folgende ERD:

Beachten Sie, dass ich einen Schnittpunkt-Entitätstyp zwischen DEPARTMENTund hinzugefügt habe CLASSIFICATION. Dieser neue Entitätstyp: POSITIONStellt die in Ihrem Modell implizite Information bereit, dass eine bestimmte Abteilung eine Reihe von Jobs mit verschiedenen Klassifizierungen hat.

Das Hinzufügen POSITIONzu Ihrem Modell als explizite Entität hat einige Vorteile.

1. Es vermeidet das Problem, dass Sie befürchten, WORKERmöglicherweise Abteilungen und Klassifizierungen in verschiedenen Unternehmen zugeordnet zu werden.
2. Es gibt Ihnen einen Ort für andere Prädikate, die möglicherweise auf eine Position zutreffen, z. B. Gehaltsstufe usw.
3. Hiermit können Sie die Tatsache aufzeichnen, dass eine Position vorhanden ist, auch wenn WORKERderzeit keine s in der Position vorhanden sind. Dies ist möglicherweise eine nützliche Information.

Beachten Sie, dass ich die Schlüssel von beiden DEPARTMENTund erweitert habe, um das Problem zu vermeiden, dass eine Position für eine Abteilung und eine Klassifizierung in verschiedenen Unternehmen definiert wird CLASSIFICATION.

ACHTUNG Das obige Modell setzt eine Vereinfachung voraus. Insbesondere wird davon ausgegangen, dass jede Position nur einmal aufgezeichnet wird. Dies passt möglicherweise nicht zu Ihren Geschäftsregeln. Wenn Sie POSITIONinnerhalb eines Unternehmens mehrere Datensätze für dieselbe Abteilung und Klassifizierung benötigen , können Sie einen Ersatzschlüssel eingeben POSITION.

Ich glaube nicht, dass Sie ein Problem mit den Beziehungen haben. Ich denke, stattdessen besteht das Problem darin, dass die resultierende Datenbank durch die Verwendung von Ersatzschlüsseln (dh IDs) für jede Tabelle nicht verhindern kann, dass Mitarbeiter eingefügt werden, deren Abteilung zu einer Firma gehört, während die Klassifizierung zu einer anderen gehört, und umgekehrt. Ein guter Weg, dies zu verstehen, ist die Visualisierung des Schemas mithilfe eines ER-Diagrammtools. Ich werde das Oracle Data Modeler- Tool verwenden, das kostenlos heruntergeladen werden kann.

ER-Diagramm

So wie es aussieht, könnten Sie 2 Firmen haben - sagen wir IBMund Microsoft. IBMkann eine Software DevelopmentAbteilung haben, und Microsoft kann eine Desktop SoftwareAbteilung haben. IBM kann eine Software EngineerKlassifizierung haben, und Microsoft kann eine Software DeveloperKlassifizierung haben. Nun, da Sie haben einen Ersatzschlüssel für Departmentund Classificationdie Tatsache , dass Software Developmenteine ist IBMAbteilung und Desktop Softwareeine MicrosoftAbteilung für zukünftige Kind - Beziehungen verloren. Dies gilt auch für Classification. Daher ist es leicht, versehentlich zuzuordnen Harlan Mills, wer ein IBMMitarbeiter in der Software DevelopmentAbteilung ist, dessen Klassifizierung a Software DeveloperistMicrosoftEinstufung! Ebenso könnte der Arbeiter die richtige Klassifizierung und falsche Abteilung erhalten! Hier ist ein Diagramm, das das erste Beispiel zeigt:

Die 1 Ids repräsentieren IBMund die 2 Ids repräsentieren Microsoft. Ich habe in rot Szenario hervorgehoben , wo Harlan Millsund Bill Gatesan den falschen Abteilungen zugeordnet, die kehrt auf die 200 Klassifizierungs - ID und vice zugeordnet durch die 10 - Abteilung Id visualisiert.

Zu lösende Optionen

Also, was sind die Optionen, um sein Geschehen zu verhindern? Es gibt zwei unmittelbare Möglichkeiten. Die erste besteht darin, zu erkennen, dass dieses Problem bei Verwendung eines Ersatzschlüssels für jede Tabelle besteht, und zusätzliche Programmierung einzuführen, um zu überprüfen, ob es nicht auftritt. Dies könnte in der Anwendung geschehen, aber wenn Einfügungen und Aktualisierungen außerhalb der Anwendung erfolgen können, können immer noch falsche Zuordnungen auftreten. Ein besserer Ansatz wäre, einen Auslöser zu erstellen, der beim Einfügen und Aktualisieren eines Mitarbeiters ausgelöst wird, um sicherzustellen, dass die zugewiesene Abteilung zur gleichen Firma gehört wie die zugewiesene Klassifizierung. Wenn dies nicht der Fall ist, wird das Einfügen oder Aktualisieren fehlschlagen.

Die zweite Möglichkeit besteht darin, nicht für jede Tabelle Ersatzschlüssel zu verwenden. Verwenden Sie die Ersatzschlüssel stattdessen nur für die CompanyTabelle, die von grundlegender Bedeutung ist und keine übergeordneten Elemente hat, und erstellen Sie dann identifizierende Beziehungen zu den Tabellen Departmentund den Classificationuntergeordneten Elementen. Die Tabellen Departmentund Classificationhaben jetzt eine PK mit dem Company IdPluszeichen und eine Sequenznummer oder einen Namen, um sie zu unterscheiden. Dann sind die Beziehungen von DepartmentundClassification zu Workerauch werden identifyingund damit die PK von Workerwird das Company Id, plus die Department Number(ich bin eine Sequenznummer in diesem Beispiel verwendet wird ), sowie die Classification Number. Das Ergebnis gibt es nur one Company Idin der WorkerTabelle. Es ist jetzt unmöglich , eine zuzuweisenWorkerzu einem Departmentin einem Companyund zu einem Classificationin einem anderen Company.

Warum ist das unmöglich? Dies ist unmöglich, da das Schema die referenzielle Integrität zwischen Workerund Departmentund implementiert Classification. Wenn versucht wird, ein Workerfür ein Departmentin ein Companyund ein Classificationvon einem anderen einzufügen , löst die Kombination, die in der entsprechenden übergeordneten Tabelle nicht vorhanden ist, eine Verletzung der referenziellen Integrität aus, und das Einfügen funktioniert nicht.

Hier ist ein aktualisiertes Diagramm einer Implementierung der zweiten Option:

Bevorzugte Option

Von den beiden Optionen bevorzuge ich aus zwei Gründen die zweite - die identifizierenden Beziehungen und die kaskadierenden Schlüssel. Erstens erreicht diese Option die gewünschte Regel ohne zusätzliche Programmierung. Einen Auslöser zu entwickeln ist nicht trivial. Es muss codiert, getestet und gewartet werden. Es ist auch nicht trivial sicherzustellen, dass die Triggerlogik optimal ist, um die Leistung nicht zu beeinträchtigen. Das Buch Angewandte Mathematik für Datenbankprofis enthält viele Details zur Komplexität einer solchen Lösung. Zweitens implizieren die Regeln, dass eine Abteilung und eine Klassifikation nicht außerhalb des Kontexts der existieren können Company, und daher spiegelt das Schema die reale Welt jetzt genauer wider.

Dies ist eine gute Frage, da sie genau zeigt, warum es eine schlechte Idee ist, einfach anzunehmen, dass jede Tabelle einen Ersatzschlüssel erfordert. auf der physischen Ebene, gerade weil Verknüpfungen erforderlich sind, die bei ordnungsgemäßer Kaskadierung von Schlüsseln unnötig wären. Ein weiteres interessantes Thema, das diese Frage aufzeigt, ist, dass eine Datenbank nicht sicherstellen kann, dass alle darin eingegebenen Daten in Bezug auf die reale Welt korrekt sind. Stattdessen kann es nur sicherstellen, dass die darin eingefügten Daten mit den ihm deklarierten Regeln übereinstimmen. In diesem Fall können wir das bestmögliche tun, indem wir den Cascading-Key-Ansatz verwenden, um sicherzustellen , dass das DBMS die Daten in Bezug auf die Regel konsistent hält, dass einem bestimmten Datenelement zugewiesen werden muss und das DBMS nichts anderes tun kann, als davon auszugehen, dass es angegeben wurde eine wahre Tatsache.Fabian Pascal hat einen ausgezeichneten Blogeintrag zu diesem Thema verfasst, der zeigt, dass ein Ersatzschlüssel nicht nur vom Standpunkt der Datenintegrität aus eine schlechte Idee sein kann, sondern auch einige Abfragen verlangsamtWorkerCompanyClassification und einer Departmentvon demselbenCompany . Aber wenn in der realen Welt Microsofteine Abteilung angerufen hat, Desktop Softwareaber der Benutzer der Datenbank behauptet, die Abteilung sei stattdessenSoftware Development

Ich verstehe die Frage so, dass das Feld ID_Classification in der Tabelle 'Workers' nur die Klassifizierungen zulassen sollte, die für das jeweilige Unternehmen des Arbeitnehmers definiert wurden. Das Validieren (durch Anhängen einer REGEL oder durch TRIGGERS) der in das Feld Workers.ID_Classification eingegebenen / aktualisierten Informationen ist daher ausreichend, um diese Anforderung zu erfüllen.

Aus meinen Lesungen weiß ich immer noch nicht, was diese Klassifikation ist und warum sie die ID_Company haben muss . Wenn es sich um eine Position handelt, wie sie hier erwähnt wird, wäre eine statische Tabelle mit allen Positionen besser.

Wenn Sie dies tun, um eine Klassifizierung / Position in einem Unternehmen leicht zu finden, fügen Sie bitte eine einfache Abfrage / Ansicht hinzu, um die Abteilungen der Klassifizierungsarbeiter zu verbinden und die Firmen-ID der Klassifizierung abzurufen.

Heutzutage gibt es intelligentere Ansichten oder Technologien wie materialisierte Ansichten und Verknüpfungsindizes. Wenn es also um die Leistung der Abfrage geht, sollten Sie diese verwenden.