Wie Struktur in einem Tag-basierte Organisation definieren?

Question

[ehemalige Titel: Gibt es eine Möglichkeit, eine Beziehung Struktur auf einem Tag-basierte Organisations Methodik zu zwingen]

Ich habe einige Einheiten, und sie haben eine Reihe von Attributen. Einige der Attribute beeinflussen, was andere Attribute das Unternehmen haben kann, werden viele der Attribute in Gruppen organisiert, und gelegentlich sind Entitäten vergolten bestimmte Anzahl von Attributen von bestimmten Gruppen haben, oder möglicherweise eine Reihe von Attributen von bestimmten Gruppen.

Gibt es eine Möglichkeit, diese Art von Tag-zu-Tag-Beziehungen, wie Anforderung zu modellieren, Gruppierung, Ausgrenzung usw. unter Verwendung einer Datenbank, oder ist dies nur möglich mit programmiert „Geschäftsregeln“? Im Idealfall möchte ich die möglichen Tags und die Beziehungen leicht konfigurierbar sein und daher sehr flexibel.

Eine der Möglichkeiten, wie ich in Betracht gezogen habe, ist die Tags und mögliche Beziehungen zu haben, und Sie dann eine Tag-Tag-Anwendung Beziehung Art von Tisch zu bekommen, aber dies scheint wie ein ziemlich spröde Ansatz.

Also, das ist möglich in einer strengeren Art und Weise, und wenn ja, wie würde ich sogar anfangen, darüber zu gehen?

Answer 1

Bearbeiten : Ihre Beschreibung der variablen Attribute, die nur gelten die Werte in anderen Attributen abhängig ist ein nicht-relationales, nicht normalisiert Design. RDBMS möglicherweise nicht die beste Lösung sein, für diese Art von Daten zu speichern. Wahrscheinlich wäre RDF eine gute Lösung für Daten sein, die dieses Maß an Flexibilität erfordert.

Meine frühere Antwort, die sich auf RDBMS-Lösungen unter:

---

Einige Leute Modell flexible Attribute mit dem Entity-Attribute-Value Design , aber das ist oft zu unstrukturiert und Sie mit Datenintegritätsproblemen kämpfen am Ende. Verwenden Sie diese Option nur, wenn Sie eine praktisch unbegrenzte Anzahl von Unternehmen Untertypen benötigen.

Andere Leute benutzen Single Table Inheritance , wo Sie alle Spalten von allen Unter verwendet Attribut setzen -Typen in einem sehr breiten Tisch, und sie auf Zeilen NULL verlassen, in dem das Attribut auf den Untertyp keine Rolle spielt. Das hat aber Grenzen, da die Tabelle zu breit wachsen kann, und Sie verlieren die Fähigkeit zu allen Attributen obligatorisch zu machen, weil sie alle nullable sein muss.

Wenn Sie eine relativ kleine Anzahl von Unternehmen Unterarten haben, würde ich empfehlen, für jede Gruppe von erforderlichen Attributen eine abhängige Tabelle erstellen. Definieren der Primärschlüssel der abhängigen Tabelle als Fremdschlüssel für die übergeordnete Tabelle, so erhalten Sie eine Eins-zu-Eins-Beziehung.

CREATE TABLE Vehicles (
  vehicle_id INT PRIMARY KEY
  ...attributes common to all vehicles...
);

CREATE TABLE Automobiles (
  vehicle_id INT PRIMARY KEY,
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id) REFERENCES Vehicles(vehicle_id)
);

Sie kann auch ein wenig mehr Datenintegrität bieten den Subtyp in dem Primärschlüssel der übergeordneten Tabelle durch Codierung. Das ist eine Zeile in Automobiles um sicherzustellen, dass kein Motorrad in Vehicles verweisen kann.

CREATE TABLE Vehicles (
  vehicle_id INT,
  vehicle_type VARCHAR(10),
  ...attributes common to all vehicles...
  PRIMARY KEY (vehicle_id, vehicle_type),
  FOREIGN KEY (vehicle_type) REFERENCES VehicleTypes (vehicle_type)
);

CREATE TABLE Automobiles (
  vehicle_id INT,
  vehicle_type VARCHAR(10) CHECK (vehicle_type = 'Automobile'),
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id, vehicle_type) 
    REFERENCES Vehicles(vehicle_id, vehicle_type)
);

Natürlich müssen Sie jedes Mal eine neue abhängige Tabelle erstellen Sie einen neuen Untertyp definieren, aber das Design gibt Ihnen viel mehr Struktur der Datenintegrität zu erzwingen, NOT NULL Attribute, und so weiter.

Der einzige Teil, den Sie in der Anwendungslogik erzwingen müssen, ist, dass, um sicherzustellen, eine Zeile in Automobiles für jede Zeile in Vehicles mit vehicle_type = ‚Automobil‘ zu erstellen.

Answer 2

Es gibt keinen Unterschied zwischen den Datenbanken anhand festgelegte Regeln oder mit Quellcode an anderer Stelle zu erzwingen. Code ist Daten. Das ist die esoterische Lisp Antwort.

Die eigentliche Frage Sie fragen, ob diese in einer relationalen Datenbank einfacher ist, oder in (ich nehme an) eine Algol Familiensprache. Sie hat nicht angegeben was ein RDBMS, also werde ich ANSI zu übernehmen. Das macht diese hart.

BTW, das ist einfach in Prolog. Aber das ist weder hier noch dort.

Ich würde sagen, zu Check-Einschränkungen für alles zu verwenden. Die mentale Verschiebung für diesen Ansatz erforderlich ist zu erkennen, dass die Benutzeroberfläche einen Weg benötigt diese Tag-Beziehungen zu definieren. Traditionell würden Sie CRUD Aussagen über die Benutzeroberfläche an die DB ausgeben. Stattdessen müssen Sie ALTER TABLE-Anweisungen CRUD Check-Bedingungen erteilen.

Es gibt zwei Probleme mit diesem Ansatz:

• Solche Aussagen sind nicht parametrierbare in den meisten RDBMS. Denken Sie SQL-Injection.
• Implementationen unterscheiden sich in ihrer Unterstützung für die vollständige Prüfung Einschränkungen ANSI. Wenn Unterabfragen nicht unterstützt werden, vergessen Sie es.

Wenn Sie Ihre Frage mit einem bestimmten RDBMS klären können, dann können wir Ihnen eine bessere Antwort geben.