ER-Modell der Typolight DB?
Hi allerseits,
ich wollte eigentlich nur mal wissen ob es zu TYPOlight ein schönes, visualisierendes ER-Modell gibt, z.B. für die MySQL Workbench. Ich kann mir die Fremdschlüssel Beziehungen zwar oftmals denken, aber wenn es da schon was zur Ansicht gäbe ...
Danke und Grüße aus Düsseldorf
:)
Liste der Anhänge anzeigen (Anzahl: 1)
Moin,
ein erster Eindruck, wie das TYPOlight Datenmodell mit Hilfe der MySQL Workbench aussehen kann:
https://community.contao.org/de/atta...4&d=1269064458
Bei diesem Screenshot schwebte meine Maus über 'tl_article', die farbigen Hervorhebungen macht dann die Workbench. Ich habe natürlich nicht all die 34+10+56 "more" Spalten manuell eingegeben (und auch nicht die mehreren Hundert Spalten in den nicht gezeigten 31 weiteren Tabellen), das kann die Workbench dann schon selbst via "Reverse Engineering" (hier via PHPMyAdmin Export als SQL-Script ohne Daten).
Aber, zumindest auf diesem Weg, sind keinerlei Relationen im Modell vorhanden (die Striche 1:N zwischen den Tabellen-Kästen). Das musste ich dann selbst machen (mühsam, fehlende Features in der Workbench oder Unverständnis meinerseits).
Die PHP/serialized Array Handhabung von N:M in TYPOlight muss ich auch noch in den Griff bekommen. Die Workbench geht natürlich von "klassischer" Modellierung aus. Dazu lasse ich mir was einfallen und werde das demnächst mal vorstellen.
Recht unzufrieden bin ich mit dem "Autoarrange" der Workbench, soweit ich das bisher getestet habe ... im Moment rate ich davon ab, sie vermarmelt mir jedes manuell erzeugte Layout zu "schlicht unbrauchbar". Da habe ich vor Jahren schon besseres gesehen ... aber ich bin auch noch nicht fertig mit den Tests.
Dennoch: im Moment sieht es so aus, dass ich sämtliche 34 core Tabellen von Hand positionieren muss (und in Layer packen usw). Wird also echt mühsam werden.
LG, Georg
Liste der Anhänge anzeigen (Anzahl: 1)
TL N:M Darstellung mit der MySQL WB
Moin alle,
ich habe hin und her überlegt/probiert, wie ich N:M "the TYPOlight 2.x.x way" in der MySQL Workbench gut darstellen kann. Ich falle aber immer wieder zurück auf die "klassische" Art und Weise mit "komischen" Hilfstabellen:
https://community.contao.org/de/atta...9&d=1269316236
Vom Sachverhalt ist das korrekt (wenn man denn physische Datenmodelle lesen kann). Schade ist, dass das Feld "tl_user.groups" (siehe den roten Pfeil, der natürlich NICHT im Modell vorhanden sein wird) nicht direkt beim :hover über der Beziehung erkennbar ist, sondern nur aus dem Namen der Hilfstabelle. Im Namen hätte ich (in der freien Version) statt des '-' auch '.' verwenden können, ich befürchte aber, dass das in der kommerziellen Version nicht validiert.
Mein Plan ist, im Kommentar zu N:M Hilfstabellen wie "tl_user-groups" die Implementation als serialized Array zu dokumentieren. Falls in anderen N:M-Beziehungen (dem jeweiligen serialized Array) weitere Eigenschaften der Beziehung gespeichert wären, würde ich wohl weitere Felder in die jeweilige Hilfstabelle aufnehmen und im Kommentar beschreiben.
Was denkt Ihr? Habe ich eventuell ein "logical" Modelling in der WB übersehen?
LG, Georg
Liste der Anhänge anzeigen (Anzahl: 2)
Moin,
in der Anlage ein allererster Stand des Datenmodells als WB Datei. Erwartet bitte noch nicht viel, ich habe mal gerade ein wenig in modules/backend hereingerochen. Was man aber schon jetzt erkennen kann (tl_content) ist, dass es MEHR 1:N Beziehungen gibt als die wenigen, die man auf Anhieb per DCA p/ctable erkennen kann. Und natürlich gibt es auch diverse N:M Beziehungen.
Ich werde jede Beziehung nach bestem Wissen/Erkenntnis kommentieren, bei der N:M Hilfstabelle (siehe Bild rechts unten) bzw. bei der 1:N Beziehung. Das lässt sich in einem einzigen Bild nicht alles zeigen, dazu muss man dann die WB installieren und die Beziehungen an- oder doppel-klicken.
Anhang 1550
Das Erkennen der zusätzlichen 1:N Beziehungen für 'tl_content' war nicht ganz leicht, es ging nur dadurch, dass ich einerseits im Backend herumgespielt habe, andererseits nicht nur alle BLOB Felder, sondern auch alle INT(10) Felder von tl_content im Code besichtigt habe. Nun ist tl_content wohl ein Extrem, ich hoffe, dass ich nicht all zu viele weitere solch schwierigen Tabellen noch vor mir habe :D .
Nebenbei habe/werde ich alle Foreign Key Attribute nach oben ziehen, so dass bei der verkürzten Darstellung in der Workbench die FKs immer sichtbar sind.
Über weitere Tipps, wie ich Beziehungen einfach erkennen kann, wäre ich dankbar. Wie etwa ein grep -i 'foreignkey' (das für tl_content allerdings die N:M Beziehung 'groups' markierte).
Dass das Reverse Engineering so mühsam ist, zeigt aber auch, wieviel Aufwand Leo in den Code gesteckt hat.
LG, Georg
Welche Workbench Version?
Hallo,
mit welcher Version wurde die Datei erstellt?
Meine aktuell runtergeladene 5.1.18a (OSS Community Edition) sagt mir, inkompatible Version. :(
Ne 5.2.16.beta gibt auch noch sehe ich grad, wäre es die?
Nachtrag: Scheint wohl so, denn meine erzeugt eine Modell Version 1.3.1, deine eine 1.4.0.
Bestätigt, mit der 5.2.16.beta kann ich das öffnen. :cool:
Liste der Anhänge anzeigen (Anzahl: 2)
Moin liebe Leser,
@BugBuster: ja, dies Modell ist für die WB 5.2.16 beta (wie oben bereits erwähnt).
Inzwischen bin ich das erste Mal durch mit system/modules/backend/* (ein zweiter Durchgang wird folgen). Und wie Ihr sehen könnt, sind reichlich neue 1:N und N:M Beziehungen dazu gekommen.
Anhang 1561
Langsam wird das Placement/Routing (die übersichtliche Darstellung der Tabellen und Beziehungen) zum Problem ... zumal noch deutlich mehr Beziehungen dazu kommen werden, wenn ich mich den weiteren Verzeichnissen in system/modules zuwende. Deshalb habe ich im Moment auch noch nicht sehr darauf geachtet. Allerdings habe ich auch schon meine bevorzugte Darstellung der Beziehungen als "Krähenfüße" angetestet ... war aber leider auch nicht überzeugend. Die WB ist bezüglich Routing echt schwach auf der Brust. Bei so komplexen Datenmodellen wünschte ich mir sowas wie das Routing für Platinen/Mainboards (2 Layer würden ja schon reichen). Interessierte Leser dürfen gern einmal selbst die Tabellen in der WB hin- und herschieben, bzw. eine andere Darstellung der Relationen wählen ... und mir Tipps zur besseren Anordnung geben :) .
Wenn das komplette Modell fertig ist, werde ich auch versuchen, Teil-Diagramme hinzuzufügen, die verschiedene Aspekte übersichtlich (reduziert) darstellen.
Ansonsten sind im Modell zu jeder Beziehung (und deren zugehörigen Feldern) Kommentare vorhanden. Falls die nicht stimmen sollten, bitte ich um Hinweise.
LG, Georg
PS: die merkwürdigen Anzeige-Namen der ZIP Dateien hier im Forum (im Moment ein verdoppelter '.' vor der Endung "zip" ) sind sicher nicht mein Problem. Die Upload-Datei bei mir heisst "xxx.zip" und nach Download erscheint sie auch wieder genau so (als "xxx.zip"). Ich befürchte, da muss die Forums-Software noch mal korrigiert werden.
Liste der Anhänge anzeigen (Anzahl: 1)
So, damit es besser verstaendlich ist, habe ich die Graphviz Ausgabe mal gemacht.
Die Vorlage fuer dieses Bild wird dann erstellt. Generieren dauert auch nicht lange. Also ich habe diese Uebersicht nach etwa 5 Sekunden :
Anhang 1569
(ich musste das Bild fuer Forum verkleinern und in einer schlechteren Aufloesung speichern, Original ist hier : http://dev.typolight-forge.org/attac.../DBCrawler.jpg)
Liste der Anhänge anzeigen (Anzahl: 2)
GraphViz Test
Moin,
nach dem Finden der Oster-Eier war mir langweilig und deshalb habe ich mal GraphViz (GV) erprobt ...
Anhang 1598
... und bin recht zufrieden mit dem Placement/Routing. Wie Ihr seht, hat GV die Tabellen so gut angeordnet, dass nur eine einzige Relation andere überkreuzt (die N:M von tl_page zu tl_member_group). Und das Diagramm ist nicht übermäßig breit oder hoch.
Dies Diagram entspricht in etwa dem Workbench-Diagramm und ist zur Zeit noch maunell erzeugt (siehe Anlage). Allerdings so angelegt, dass sich das weitgehend auch automatisch erzeugen lässt aus DCA + Zusatz-Infos (z.B. für Foreign-Key-Felder, die sich nicht eindeutig aus den DCAs erkennen lassen, gelegentlich auch, um Einfluss auf die Sortierung von Feldern nehmen zu können).
Zur Notation: ich habe hier Krähenfüße verwendet, weil sie so selbstverständlich sind. Auf Seite der "referencing" Tabelle setzt die Relation immer direkt am Feld an (einem GV port; bei N:1 ein INT(10) "Foreign Key", bei N:M ein BLOB mit einem serialized Array von IDs).
Auf der anderen Seite der Beziehung (die "referenced" Tabelle) zeigt die Relation in etwa auf die Mitte der ganzen Tabelle und endet diverse Pixel VOR der dem Kasten. Das erlaubt GV mehr Freiraum für die Darstellung, meint aber immer, dass das Feld ID referenziert wird.
Was denkt Ihr dazu?
LG, Georg
Liste der Anhänge anzeigen (Anzahl: 2)
Weiteres GraphViz Experiment, Script
Moin,
ich habe mir ein wenig Zeit gestohlen, GraphViz weiter zu erforschen:
https://community.contao.org/de/atta...2&d=1271302619
Zufrieden bin ich damit noch lange nicht, aber immerhin wurde die GraphViz DOT Quell-Datei automatisch aus meiner 2.8.0 TL Installation erzeugt (siehe Script im Anhang).
Jedenfalls lässt sich erkennen, dass tl_user/_group (der Backend-Benutzer und seine Gruppe) eine zentrale Rolle spielt (Überraschung?). Die tl_meber_group (Frontend-Benutzer-Gruppe) ist auch noch recht wichtig, der einzelne Frontend-Benutzer dagegen garnicht.
In meiner Installation ist die Erweiterung [survey_ce] vorhanden und beansprucht ebenfalls viel Platz nahe des Zentrums ... völlig zu Recht, weil sie für mich wichtig ist.
Ich würde mich freuen, wen der eine oder andere das anhängende Script mal erprobt und Rückkopplung gibt.
LG, Georg
Liste der Anhänge anzeigen (Anzahl: 1)
Nettes Ergebniss ...
Also dafür das es automatisch generiert wird finde ich es cool.
Wenn ich im Viewer "dotty.exe" was verändern wollte, gabs immer n totales Chaos mit Darstellungsfehlern und er "vergisst" einige Formatierungen bei den Beziehungs Pfeilen sobald ich was ändere. Hab mich aber jetzt noch nicht weiter großartig damit beschäftigt.
Die Verbindung von meinen Relationen tl_channel -> tl_show -> tl_video hat er jedenfalls gut erkannt.
Gruß Tim :)
Liste der Anhänge anzeigen (Anzahl: 2)
Liebe Leser,
da ich mit dem GraphViz Layout nicht wirklich zufrieden war, habe ich mich mal umgesehen und bin dabei auf den yEd gestoßen. Kostenlos, wenn auch nicht Open Source (die Jungs dort leben vom Verkauf ihrer Bibliothek). Ich bin wirklich echt begeistert von diesem Werkzeug und zeige hier nur einmal kurz EINE Variante der möglichen Layouts (hierarchisch, entspricht in der Struktur dem GraphViz Layout). Die volle Stärke des Layouts zeigt sich nebenbei nicht im anliegenden Bild, sondern erst interaktiv in yEd (siehe unten).
Ich warne Interessierte aber: yEd ist nicht nur ein wundervolles Werkzeug, sondern auch ein geiles Spielzeug ... nicht gerade eine Ego-Shooter, aber yEd hat so unglaublich viele Layout-Verfahren und Optionen, dass man sich tagelang damit beschäftigen kann ... und dabei immer neue Erkenntnisse gewinnt!
Und damit Ihr auch etwas zu spielen habt, hänge ich ein ZIP mit den yEd-Quellen für die TYPOlight DB an (noch unvollständig, es fehlen noch einige Foreign Keys). "TYPOlight_yEd_hierachical.graphml" ist bereits fertig ausgelegt, "TYPOlight.graphml" ist so, wie es aus meinem (beta) DBCrawler Script erzeugt wird: ohne jegliche Größen- und Positions-Angaben. Sieht echt blöd aus nach dem ersten Laden ... aber dann probiert doch bitte (in yEd):
- Werkzeuge > Knoten wie Beschriftung...
- Layout > Hierarchisch...
- Layout > Beschriftungen...
und spielt mit den Parametern herum.
Das Script ist, wie gesagt, noch beta, aber es fehlt echt nicht mehr viel. Sobald es fertig ist, bekommt Ihr es, zusammen mit Instruktionen/Hinweisen, wie man daraus gute Layouts macht.
LG, Georg
Liste der Anhänge anzeigen (Anzahl: 3)
Moin,
ich hatte gerade mal wieder Lust und Zeit, an der automatischen Erzeugung eines Datenmodells der TL DB weiter zu arbeiten. Im Anhang der aktuelle Stand des Scripts (Doku folgt) und etwas zu sehen.
LG, Georg