Gibt es überhaupt eine Zeit, in der mit Hilfe einer Datenbank 1: 1-Beziehung Sinn macht?

https://stackoverflow.com/questions/517417

21-08-2019
|

Frage

Ich war neulich auf Normalisierung zu denken, und es fiel mir ein, ich kann nicht an eine Zeit denken, wo es sollte ein 1:. 1-Beziehung in einer Datenbank

Name: SSN? Ich würde sie in der gleichen Tabelle haben PersonID: AddressID? Wieder selber Tisch.

Ich kann mit zig Beispielen von 1 kommen: viele oder viele: viele (mit entsprechenden Zwischentabellen), aber nie ein. 1: 1

Bin ich etwas fehlt offensichtlich?

Lösung

Eine 1: 1-Beziehung gibt normalerweise an, dass Sie eine größere Einheit aus irgendeinem Grunde partitioniert haben. Oft wegen Leistungsgründen im physischen Schema es ist, aber es kann auch, wenn ein großer Teil der Daten in der Logikseite passieren wird erwartet, dass „unbekannt“ zugleich sein (in diesem Fall haben Sie ein 1: 0 oder 1:. 1, aber nicht mehr)

Als Beispiel für eine logische Partition: Sie haben Daten über einen Mitarbeiter, aber es gibt eine größere Menge an Daten, die gesammelt werden muss, wenn und nur wenn sie wählen Krankenversicherung haben. Ich würde in Bezug auf der Krankenversicherung die demographischen Daten hält in einer anderen Tabelle sowohl einfache Sicherheit Partitionierung geben und um in Abfragen in keiner Zusammenhang mit Versicherung, dass die Daten des Schleppen zu vermeiden.

Ein Beispiel einer physischen Partition wären die gleichen Daten auf mehreren Servern gehostet werden. Ich kann die demographischen Daten Krankenversicherung halten in einem anderen Staat (wo die Personalabteilung ist, zum Beispiel) und die primäre Datenbank kann Link nur über einen Verbindungsserver, um es ... sensible Daten an andere Standorte zu vermeiden replizieren, noch macht es für (unter der Annahme, hier selten) Abfragen, die es brauchen.

Physikalische Partitionierung kann nützlich sein, , wenn Sie haben Abfragen, die konsistenten Teilmengen einer größeren Einheit benötigen.

Andere Tipps

Ein Grund dafür ist Datenbank Effizienz. mit einer 1: 1-Beziehung ermöglicht es Ihnen, die Felder aufgeteilt, die während einer Reihe / Tabellensperre betroffen sein werden. Wenn Tabelle A eine Tonne Updates hat und Tabelle b hat eine Tonne liest (oder hat eine Tonne von Updates von einer anderen Anwendung), dann Verriegelungs Tabelle A ist nicht beeinflussen, was in Tabelle B vor sich geht.

Andere bringen einen guten Punkt. Die Sicherheit kann auch ein guter Grund sein, je nachdem, wie Anwendungen usw., das System schlagen. Ich würde dazu neigen, einen anderen Ansatz zu nehmen, aber es kann eine einfache Möglichkeit, den Zugriff auf bestimmte Daten zu beschränken. Es ist wirklich einfach, nur der Zugang zu einer bestimmten Tabelle in einer Prise zu verweigern.

darüber Mein Blogeintrag.

Sparseness. Die Datenbeziehung sein kann technisch 1: 1, aber entsprechende Reihen müssen für jede Zeile nicht vorhanden ist. Also, wenn Sie zwanzig Millionen Zeilen und es gibt einige Reihe von Werten, die nur 0,5% davon vorhanden ist, sind die Platzersparnis riesig, wenn Sie die Spalten aus in eine Tabelle schieben, die dünn besiedelt werden können.

Die meisten der hochrang Antworten geben sehr nützliche Datenbank-Tuning und Optimierung Gründe für die 1: 1-Beziehungen, aber ich will auf nichts konzentrieren, sondern „in the wild“ Beispiele, bei denen. 1: 1-Beziehungen natürlich vorkommen

Bitte beachten Sie ein wichtiges Merkmal der Datenbank Umsetzung der meisten dieser Beispiele: keine historischen Informationen beibehalten über die 1: 1-Beziehung. Das heißt, diese Beziehungen 1: 1 zu einem bestimmten Zeitpunkt. Wenn der Datenbankentwickler will Änderungen der Beziehung Teilnehmer im Laufe der Zeit erfassen, dann werden die Beziehungen 1: M oder M: M; sie verlieren ihre 1: 1 Natur. Damit verstanden, hier geht:

"Is-A" oder übergeordneter Typ / Subtyp oder Vererbung / Klassifizierung Beziehungen : Diese Kategorie ist, wenn ein Unternehmen eine bestimmte Art eines anderen Unternehmens ist. Zum Beispiel könnte es eine Employee-Entität mit Attributen, die für alle Mitarbeiter gelten, und dann verschiedene Einheiten auf bestimmte Arten von Mitarbeitern mit Attributen einzigartig für diesen Mitarbeitertyp angeben, z.B. Arzt, Buchhalter, Pilot, etc. Dieser Entwurf vermeidet mehrere Nullen, da viele Mitarbeiter nicht die speziellen Eigenschaften eines bestimmten Subtyp haben würden. Andere Beispiele in dieser Kategorie könnte sein Produkt als Supertyp und ManufacturingProduct und MaintenanceSupply als Subtypen; Tier als übergeordnete Typ und Hund und Katze als Subtypen; usw. Beachten Sie, dass, wenn Sie versuchen, eine objektorientierte Vererbungshierarchie in eine relationale Datenbank (wie in einem objektrelationalen Modell) abzubilden, das die Art von Beziehung, die solche Szenarien darstellt.
"Boss" Beziehungen , wie Manager, Vorsitzender, Präsident, usw., wo eine Organisationseinheit nur einen Vorsprung haben kann, und eine Person kann Chef von nur einer Organisationseinheit . Wenn diese Regeln gelten, dann haben Sie eine 1: 1-Beziehung, wie ein Manager einer Abteilung, ein CEO eines Unternehmens usw. „Boss“ Beziehungen nicht nur für Menschen gelten. Die gleiche Art von Beziehung tritt auf, wenn es nur ein Speicher als Sitz eines Unternehmens ist, oder wenn nur eine Stadt ist die Hauptstadt eines Landes, zum Beispiel.
Einige Arten von knappen Ressourcen-Zuweisung , z.B. ein Mitarbeiter kann zu einem Zeitpunkt nur einen Firmenwagen zugeordnet wird (z ein LKW pro hüte, ein Taxi pro Taxifahrer, etc.). Ein Kollege hat mir dieses Beispiel vor kurzem.
Heirat (zumindest in Gerichtsbarkeiten, wo Polygamie illegal ist): Eine Person kann zu einem Zeitpunkt nur auf einer anderen Person verheiratet sein. Ich habe dieses Beispiel aus einem Lehrbuch, das dies als Beispiel für eine 1:. 1 einstellige Beziehung, wenn ein Unternehmen zeichnet Ehen zwischen ihren Mitarbeitern
Matching Reservierungen : Wenn eine einmalige Reservierung vorgenommen wird und dann als zwei getrennte Einheiten erfüllt. Zum Beispiel kann ein Autovermietung System könnte eine Reservierung in einer Einheit, und dann eine tatsächliche Miete in einer separaten Einheit aufzunehmen. Obwohl eine solche Situation alternativ als eine Einheit ausgebildet sein könnte, könnte es sinnvoll sein, die Objekte zu trennen, da nicht alle Reservierungen erfüllt sind, und nicht alle Mieten verlangen Reservierungen, und beide Situationen sind sehr häufig.

Ich wiederhole den Vorbehalt ich früher gemacht, dass die meisten von ihnen sind 1: 1-Beziehungen nur, wenn keine historischen Informationen aufgezeichnet. Also, wenn Mitarbeiter ihre Rolle in einer Organisation ändert oder ein Manager übernimmt die Verantwortung von einer anderen Abteilung oder ein Mitarbeiter ein Fahrzeug neu zugewiesen werden, oder jemand verwitwet ist und eine neue Ehe, dann können die Beziehung Teilnehmer ändern. Wenn die Datenbank nicht gespeichert wird jede vorherige Geschichte über diese 1: 1-Beziehungen, so bleiben sie legitim 1: 1-Beziehungen. Aber wenn die Datenbank historische Informationen (wie das Hinzufügen von Start- und Enddatum für jede Beziehung) aufzeichnet, dann ziemlich viel sie alle verwandeln sich in M:. M Beziehungen

Es gibt zwei bemerkenswerte Ausnahmen zudie historische Anmerkung: Erstens ändern sich einige Beziehungen so selten, dass historische Informationen normalerweise nicht gespeichert werden. Zum Beispiel, die meisten IS-A-Beziehungen (z Produkttyp) sind unveränderlich; das heißt, sie können sie nie ändern. Somit ist der historische Aufzeichnung Punkt strittig; 1-Beziehungen: diese würden immer als natürliche 1 umgesetzt werden. Zweitens geht die Reservierungs Mietverhältnis Geschäft getrennt, da die Reservierung und die Vermietung unabhängige Ereignisse sind, die jeweils mit ihren eigenen Termine. Da die Einheiten ihre eigenen Termine, anstatt die 1: 1-Beziehung selbst ein Startdatum hat, würden diese als 1 bleiben. 1 Beziehungen obwohl historische Informationen gespeichert

Ihre Frage kann auf verschiedene Weise interpretiert werden, wegen der Art und Weise Sie es formuliert. Die Antworten zeigen dies.

1-Beziehungen zwischen Datenelementen in der realen Welt:

Es kann auf jeden Fall 1 sein. Keine Frage. Die „ist eine“ -Beziehung im allgemeinen 12.59 ist. Ein Auto ist ein Fahrzeug. Ein Auto ist ein Fahrzeug. Ein Fahrzeug kann ein Auto sein. Einige Fahrzeuge sind Fahrzeuge, wobei in diesem Fall ein Fahrzeug kein Auto. Mehrere Antworten adressieren diese Interpretation.

Aber ich denke, was Sie wirklich fragen, ist ..., wenn 1: 1-Beziehungen bestehen, sollten Tabellen immer aufgeteilt werden? Mit anderen Worten, sollten Sie immer zwei Tabellen haben, die genau die gleichen Schlüssel enthalten? In der Praxis analysieren die meisten von uns nur Primärschlüssel, und nicht die anderen Kandidatenschlüssel, aber diese Frage ist etwas eigenartig.

Normalisierungsregeln für 1NF, 2NF und 3NF erfordern nie (Splitting) mit dem gleichen Primärschlüssel eine Tabelle in zwei Tabellen zu zersetzen. Ich habe nicht, ob Putting ein Schema in BCNF ausgearbeitet, 4NF oder 5NF kann je in zwei Tabellen mit den gleichen Tasten führen. Aus der Spitze von meinem Kopf, ich werde erraten, dass die Antwort nein ist.

Es gibt einen Grad der Normalisierung genannt 6NF. Die Normalisierungsregel für 6NF kann auf jeden Fall in zwei Tabellen mit dem gleichen Primärschlüssel zur Folge hat. 6NF hat demgegenüber den Vorteil, dass 5NF NULLS vollständig vermieden werden kann. Dies ist wichtig, um einige, aber nicht alle Datenbank-Designer. Ich habe noch nie ein Schema in 6NF zu setzen gestört.

In 6NF können fehlende Daten durch eine Reihe weggelassen, statt einer Reihe mit einer NULL in irgendeiner Spalte darstellen sein.

Es gibt andere Gründe als Normalisierung zum Spalten von Tabellen. Manchmal führen Split-Tabellen in eine bessere Leistung. Bei einigen Datenbank-Engines, können Sie die gleichen Leistungsvorteile erhalten, indem die Tabellenpartitionierung, anstatt es tatsächlich zu splitten. Dies kann den Vorteil haben, die logische Design leicht zu verstehen, zu halten, während die Datenbank-Engine die Werkzeuge, benötigt die Dinge zu beschleunigen.

Ich benutze sie in erster Linie für ein paar Gründe. Eine davon ist signifikanter Unterschied in der Rate der Datenänderung. Einige meiner Tabellen Audit können Pfade, wo ich frühere Versionen von Aufzeichnungen verfolgen, wenn ich nur Pflege frühere Versionen von 5 von 10 Spalten zu verfolgen, diese 5 Spalten auf eine separate Tabelle mit einem Audit-Trail-Mechanismus Aufspaltung auf es effizienter ist. Auch kann ich Aufzeichnungen haben (sagen für eine Buchhaltung App), die nur schreiben. Sie können nicht die Dollar-Beträge ändern oder das Konto sie waren, wenn Sie einen Fehler gemacht haben, dann müssen Sie einen entsprechenden Datensatz machen den falschen Datensatz schreiben anpassen aus, dann einen Korrektureintrag erstellen. Ich habe Einschränkungen für die Tabelle, um die Tatsache, Erzwingen, daß sie nicht aktualisiert oder gelöscht werden, aber ich kann ein paar Attribute für das Objekt hat, die formbar sind, auf denen Modifikation gehalten in einer separaten Tabelle ohne die Einschränkung. Ein anderes Mal, wenn ich dies tun, ist in medizinischen Aufzeichnungen Anwendungen. Es gibt Daten zu einem Besuch im Zusammenhang, die nicht geändert werden können, wenn es auf abgezeichnet wird, und andere zu einem Besuch bezogenen Daten, die nach signoff geändert werden können. In diesem Fall werde ich die Daten geteilt und einen Trigger auf der gesperrten Tabelle setzen Aktualisierungen der gesperrten Tabelle zurückgewiesen, wenn abgezeichnet, aber so dass Aktualisierungen der Daten wird der Arzt nicht aus bei der Unterzeichnung.

Ein anderes Plakat kommentiert 1: 1 nicht normiert ist, würde ich mit, dass in einigen Situationen nicht einverstanden ist, besonders Subtypisierung. Sagen wir, ich habe eine Mitarbeitertabelle und der Primärschlüssel ist ihre SSN (es ist ein Beispiel, lassen Sie uns auf die Debatte speichern, ob dies ein guter Schlüssel oder nicht für einen anderen Thread). Die Mitarbeiter unterschiedlicher Art sein können, sagen temporäre oder permanente und wenn sie permanent sind, haben sie mehrere Felder ausgefüllt werden, wie Büro-Telefonnummer, die nicht nur null sein sollte, wenn die type = ‚Permanent‘. In einer dritten Normalform Datenbank sollte die Spalte hängt nur von dem Schlüssel, den Mitarbeiters Sinn, aber es hängt wirklich von Mitarbeitern und Art, so dass eine 1: 1-Beziehung ist völlig normal und wünschenswert in diesem Fall. Es verhindert auch allzu spärliche Tabellen, wenn ich 10 Spalten, die normalerweise gefüllt sind, aber 20 zusätzliche Spalten nur für bestimmte Typen.

Das gebräuchlichste Szenario, das ich denken kann, ist, wenn Sie Blob haben. Angenommen, Sie große Bilder in einer Datenbank (in der Regel nicht der beste Weg, um sie zu speichern, aber manchmal ist die Zwänge machen es bequemer) gespeichert werden sollen. Sie würden wollen, typischerweise der Blob in einer separaten Tabelle sein Lookups der Nicht-Blob-Daten zu verbessern.

In Bezug auf die reine Wissenschaft, ja, sie sind nutzlos.

In realen Datenbanken ist es manchmal sinnvoll, ein selten verwendetes Feld in einer separaten Tabelle zu halten: Abfragen zu beschleunigen, mit dieser und nur in dieses Feld; zu vermeiden, Schlösser, etc.

Anstatt Ansichten mit Zugriff auf Felder zu beschränken, macht es manchmal Sinn eingeschränkte Felder in einer separaten Tabelle zu halten, auf die nur bestimmten Benutzer Zugriff hat.

kann ich denke auch Situationen, wo Sie ein OO-Modell, in dem Sie Vererbung und der Vererbungsbaum hat an die DB beharrte werden.

Zum Beispiel haben Sie eine Klasse Vogel und Fisch, die sowohl von Animal erben. In Ihrer DB könnten Sie einen ‚Animal‘ Tisch haben, die die gemeinsamen Felder der Tierklasse enthält, und der Tiertisch hat eine Eins-zu-eins-Beziehung mit dem Vogel Tisch, und eine Eins-zu-Eins-Beziehung mit dem Fisch Tabelle.

In diesem Fall haben Sie nicht ein Tier Tisch haben, die eine Menge von Nullable-Spalten enthält den Vogel und Fisch-Eigenschaften zu halten, in der alle Spalten, die Fisch-Daten enthalten, werden auf NULL gesetzt, wenn der Datensatz ein repräsentiert Vogel.

Stattdessen haben Sie einen Datensatz in der Vogel-Tabelle, die eine Eins-zu-Eins-Beziehung mit dem Datensatz in der Tier Tabelle hat.

1-1-Beziehungen sind auch erforderlich, wenn Sie zu viele Informationen haben. Es gibt eine Rekordgröße auf jedem Datensatz in der Tabelle. Manchmal Tabellen sind in zwei Teile geteilt (mit der am häufigsten abgefragten Informationen in der Haupttabelle) nur so, dass die Datensatzgröße nicht zu groß sein wird. Datenbanken sind auch effizienter in die Abfrage, wenn die Tabellen schmal sind.

Es ist auch ein Weg, um einen Tisch zu erstrecken, die mit weniger (gefühlte) Risiko als eine „echte“ Datenbankänderung bereits in Produktion ist. eine 1 zu sehen. 1-Beziehung in einem Altsystem ist oft ein guter Indikator dafür, dass Felder nach dem ersten Entwurf hinzugefügt wurden

In SQL ist es unmöglich, eine 1 zu erzwingen: 1-Beziehung zwischen zwei Tabellen, die auf beiden Seiten obligatorisch ist (es sei denn, die Tabellen sind schreibgeschützt). Für die meisten praktischen Zwecke eine "1: 1" Beziehung in SQL bedeutet wirklich 1: 0 | 1

Die Unfähigkeit obligatorische Mächtigkeit in Referenzrandbedingungen zu unterstützen, ist eine ernsthafte Einschränkungen der SQL. „Verzögerte“ Einschränkungen gelten nicht wirklich, weil sie nur eine Art zu sagen, die Einschränkung sind nicht Teil der Zeit durchgesetzt werden.

Wenn Sie die Daten mit einem der beliebten ORMs verwenden, könnten Sie eine Tabelle in mehrere Tabellen brechen wollen, um Ihre Objekthierarchie entsprechen.

Ich habe festgestellt, dass, wenn ich ein. 1: 1-Beziehung sein völlig für einen systemischen Grund, nicht ein relationaler Grund

Zum Beispiel habe ich festgestellt, dass die reservierten Aspekte eines Benutzers in 1 Tisch setzen und die editierbaren Felder des Benutzers in einem anderen Tisch setzen erlaubt es logisch, diese Regeln zu Berechtigungen auf diesen Feldern viel viel einfacher zu schreiben.

Aber Sie sind richtig, in der Theorie, 1: 1-Beziehungen sind völlig gekünstelt, und sind fast ein Phänomen. Allerdings logisch erlaubt es die Programme und Optimierungen zu abstrahieren der Datenbank zu erleichtern.

Die meiste Zeit, sind Entwürfe gedacht, um 1: 1, bis jemand fragt: „Nun, warum kann es 1 nicht sein: viele“? Scheiden die Konzepte von einer vorzeitig anderen wird im Vorgriff auf dieses gemeinsamen Szenario getan. Person und Adresse nicht so fest binden. Viele Leute haben mehrere Adressen. Und so weiter ...

In der Regel zwei getrennte Objekträume implizieren, dass eine oder beide können (x: viele) multipliziert werden. Wenn zwei Objekte wirklich waren, wirklich 1: 1, auch philosophisch, dann ist es eher eine ist-Beziehung. Diese beiden „Objekte“ sind tatsächlich Teile eines Ganzen Objekt.

erweiterte Informationen, die nur in bestimmten Szenarien benötigt wird. in Legacy-Anwendungen und Programmiersprachen (wie RPG), wo die Programme in den Tabellen zusammengestellt werden (so, wenn die Tabelle ändert haben Sie das Programm (e) neu kompilieren). Tag entlang Dateien kann auch in Fällen nützlich sein, wenn Sie über die Tabellengröße kümmern.

Am häufigsten ist es eher ein physikalischer als logischer Aufbau. Es wird allgemein vertikal eine Tabelle Vorteil des Aufspaltens aufzunehmen partitionieren verwendet I / O in physischen Geräten oder andere Abfrage Optimierungen zugeordnet Absonderungs weniger häufig zugegriffenen Daten oder Daten, die sicherer gehalten werden muss, als der Rest der Attribute auf demselben Objekt (SSN, Gehalt usw.).

Die einzige logische Überlegung, dass eine 1-1-Beziehung schreibt vor, wenn bestimmte Attribute nur einige der Unternehmen gelten. Doch in den meisten Fällen ist eine bessere / mehr normalisiert Art und Weise die Daten durch Unternehmen Extraktion zu modellieren.

Der beste Grund, warum ich für eine 1 sehen: 1-Beziehung ist ein übergeordneter Typ SubType von Datenbank-Design. Ich habe Struktur eines Real Estate MLS Daten basierend auf diesem Modell. Es gab fünf verschiedene Daten-Feeds; Wohn-, Geschäfts-, Mehrfamilien-, Hotels & Land.

Ich habe ein übergeordneter Typ Eigenschaft genannt, die Daten enthalten, die zu jedem der fünf separaten Daten-Feeds üblich war. Dies erlaubt eine sehr schnelle „einfachen“ Suche über alle Datentypen.

Ich schaffe fünf separate Subtypen, der die einzigartige Datenelemente für jede der fünf Daten-Feeds gespeichert. Jeder Supertyp Rekord hatte. 1: 1-Beziehung zu dem entsprechenden Datensatz SubType

Wenn ein Kunde eine detaillierte Suche wollte, mußte sie einen Supertyp zum Beispiel PropertyResidential auszuwählen.

Meiner Meinung nach einer 1: 1-Beziehung bildet eine Klasse Vererbung auf einem RDBMS. Es gibt eine Tabelle A, die die gemeinsamen Attribute enthält, das heißt, die Klasse partent Status Jeder vererbte Klasse-Status wird mit einer Tabelle B auf dem RDBMS abgebildet mit einer 1: 1-Beziehung zu einer Tabelle, enthält die speziellen Eigenschaften. Die Tabelle namend A enthalten auch ein Feld „Typ“, der die „Casting“ Funktionalität

steht

Bye Mario

1: 1 Beziehungen nicht wirklich Sinn machen, wenn Sie in einer Normalisierung als etwas sind, das wäre 1:. 1 in der gleichen Tabelle gehalten werden würde

In der realen Welt ist es allerdings oft anders aus. Vielleicht möchten Sie Ihre Daten brechen Ihre Anwendungen Schnittstelle entsprechen.

Vielleicht, wenn Sie irgendeine Art von typisierte Objekten in Ihrer Datenbank haben.

Sprich in einer Tabelle, T1, haben Sie die Spalten C1, C2, C3 ... mit einem Eins-zu Eins-Beziehung. Es ist OK, es ist in normierter Form. Jetzt in einer Tabelle T2 sagen, Sie haben die Spalten C1, C2, C3, ... (die Namen unterscheiden können, aber die Typen sagen, und die Rolle ist die gleiche) mit Eins-zu-Eins-Beziehung zu. Es ist in Ordnung für T2 aus den gleichen Gründen wie bei T1.

In diesem Fall jedoch sehe ich einen Sitz für eine separate Tabelle T3, das Halten C1, C2, C3 ... und eine 12.59 Beziehung von T1 bis T3 und von T2 bis T3. Ich mehr sogar einen Anfall sehen, ob es eine andere Tabelle existiert, mit denen es existiert bereits ein eine bis mehrere C1, C2, C3 ... sagen aus Tabelle A zu mehreren Zeilen in Tabelle B Dann anstelle von T3, verwenden Sie B, und haben eine eins-zu eins-Beziehung von T1 bis B das gleiche für von T2 bis B und immer noch die gleichen, um mehrere Beziehung von A nach B.

Ich glaube Normalisierung nicht damit einverstanden sind, und das kann eine Idee, außerhalb davon sein: Objekttypen identifizieren und Objekte des gleichen Typs, um ihre eigenen Speicherpool zu bewegen, eine 0.59 Beziehung von einigen Tabellen verwendet, und ein eine bis mehrere Beziehung von einigen anderen Tabellen.

Sie können eine 0.59 Beziehungstabelle erstellen, wenn es ein erheblicher Performance-Vorteil ist. Sie können die selten genutzte Felder in separate Tabelle setzen.

Es ist unnötig groß für Sicherheitszwecke, aber es gibt bessere Möglichkeiten, die Sicherheitskontrollen durchzuführen. Stellen Sie sich vor, Sie einen Schlüssel erstellen, eine Tür nur öffnen können. Wenn der Schlüssel andere Tür öffnen können, sollten Sie den Alarm läuten. Im Wesentlichen können Sie „CitizenTable“ und „VotingTable“ haben. Citizen Eine Stimme für Kandidaten One, die in der Abstimmung Tabelle gespeichert ist. Wenn Bürger ein wieder in der Wahltabelle erscheinen, dann sollte sie ein Alarm sein. Seien Sie Beratung, das ist ein Eins-zu Eins-Beziehung, weil wir nicht auf das Kandidatenfeld beziehen, wir sind was sich auf die Abstimmungstabelle und den Bürgertisch.

Beispiel:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Wenn wir dann die Abstimmung Tabelle sehen, wie so:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Wir könnten sagen, dass Bürger Nummer 3 eine Lügnerhose auf Feuer ist, die Bern Nie betrogen. Nur ein Beispiel.

waren überall zwei völlig unabhängige Einheiten teilen sich ein Eins-zu-Eins-Beziehung. Es müssen viele Beispiele sein:

Person <-> Zahnarzt (! Seine 1: N, so dass sie falsch)

Person <-> Arzt (! Sein 1: N, also ist es auch falsch)

Person <-> Ehepartner (! Sein 1: 0 | 1, so dass sie meist falsch)

EDIT: Ja, das waren ziemlich schlechte Beispiele, vor allem, wenn ich immer suchte ein 1: 1, nicht 0 oder 1 auf beiden Seiten. Ich glaube, mein Gehirn war mis-firing: -)

Also, ich werde noch einmal versuchen. Es stellt sich heraus, nach einem wenig Gedanken, dass der einzige Weg, können Sie zwei getrennte Einheiten haben, die müssen zusammen die ganze Zeit sein (soweit die Software geht) ist für sie in höherer Kategorisierung existieren zusammen. Wenn dann und nur dann, wenn Sie eine niedrigere Zersetzungs fallen, sind die Dinge, und sollten getrennt sein, aber auf der höheren Ebene können sie nicht ohne einander leben. Kontext, dann ist der Schlüssel.

Für eine medizinische Datenbank, die Sie verschiedene Informationen über bestimmte Regionen des Körpers speichern möchten, so dass sie als eigenständige Einheit zu halten. In diesem Fall hat ein Patient nur einen Kopf, und sie müssen es haben, oder sie sind kein Patient. (Sie haben auch ein Herz und eine Reihe von anderen notwendigen einzelnen Organen). Wenn Sie bei der Verfolgung Operationen zum Beispiel interessiert sind, dann sollte jede Region eine einzigartige separate Einheit sein.

In einer Produktions / Inventar-System, wenn Sie die Montage von Fahrzeugen sind Tracking, dann möchten Sie sicherlich den Motor Fortschritt unterschiedlich von der Karosserie sehen, doch gibt es eine Eins-zu Eins-Beziehung. Eine Pflege muss einen Motor hat, und nur ein (oder es wäre kein ‚Auto‘ mehr sein). Ein Motor gehört nur ein Auto.

In jedem Fall können Sie die einzelnen Einheiten als eine große Datensatz erzeugen, aber das Niveau der Zersetzung gegeben, das falsch sein würde. Sie sind in diesen spezifischen Kontexten, wirklich unabhängige Einheiten, obwohl sie nicht so auf einer höheren Ebene erscheinen.

Paul.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow