Ich habe eine Star-Schema-Architektur-Datenbank, die ich in SQLAlchemy darstellen möchte. Jetzt habe ich das Problem, wie das auf die bestmögliche Weise gemacht werden kann. Im Moment habe ich viele Eigenschaften mit benutzerdefinierten Join-Bedingungen, weil die Daten in verschiedenen Tabellen gespeichert sind. Es wäre schön, wenn es möglich wäre, die Dimensionen für verschiedene Fact-Tabellen wiederzuverwenden, aber ich habe nicht herausgefunden, wie das gut gemacht werden kann.
Eine typische Faktentabelle in einem Sternschema enthält Fremdschlüsselreferenzen für alle Dimensionstabellen, so dass normalerweise keine benutzerdefinierten Joinbedingungen erforderlich sind - sie werden automatisch anhand von Fremdschlüsselreferenzen ermittelt.
Zum Beispiel würde ein Sternschema mit zwei Faktentabellen wie folgt aussehen:
%Vor%Aber nehmen Sie an, Sie möchten das Boilerplate in jedem Fall reduzieren. Ich würde Generatoren lokal für die Dimensionsklassen erstellen, die sich auf einer Faktentabelle konfigurieren:
%Vor%In diesem Fall wäre die Verwendung wie folgt:
%Vor% Aber es gibt ein Problem damit. Unter der Annahme, dass die hinzuzufügenden Dimensionsspalten primäre Schlüsselspalten sind, wird die Mapperkonfiguration fehlschlagen, da für eine Klasse die primären Schlüssel eingerichtet werden müssen, bevor das Mapping eingerichtet wird. Unter der Annahme, dass wir deklarative Daten verwenden (was unten zu sehen ist, hat dies einen schönen Effekt), müssten wir statt der Standard-Metaklasse die Funktion instrument_declarative() verwenden:
Also würden wir etwas wie folgt machen:
%Vor% Wenn Sie tatsächlich einen guten Grund für benutzerdefinierte Join-Bedingungen haben, können Sie, solange es ein Muster dafür gibt, wie diese Bedingungen erstellt werden, das mit Ihrem add_dimension() erzeugen:
Aber das letzte coole Ding, wenn du auf 2.6 stehst, ist add_dimension in einen Klassen-Dekorator zu verwandeln. Hier ist ein Beispiel mit allem, was aufgeräumt wurde:
Tags und Links sqlalchemy star-schema