dr.e.

Hallo zusammen,

ich habe mich die letzten Tage mit der Datenschicht eines mehrsprachigen CMS beschäftigt - konkret mit dem Tabellen-Layout desselben. Anforderungen waren Mehrsprachigkeit und generische Datenspeicherung, damit Erweiterungen leicht einbindbar sind. Ich bin dabei von der dritten Normalform ausgegangen und habe Objekte und deren Beziehungen in eigene Tabellen gesteckt. Weiterhin werden einfache Rechte-Vergabe auf Artikel und Navigationen über die User- und Group-Tabellen und deren Beziehungstabellen auf die Article und Navigation-Tabelle unterstützt.

Ein Objekt/eine Tabelle erhält hier konzeptionell dadurch einen sprachabhängigen Inhalt, in dem ein Container-Objekt INhalts-Objekte komponiert, die jeweils eine Sprache assoziieren.

Das ER-Diagramm dazu sieht so aus:



Eine leserlichere Version ist unter http://media.adventure-php-framework...ase_Schema.PNG erhältlich. Eim Feasibility-Check der Anwendunsgfälle:

- Laden eines Artikels mit seinem sprachabhängigen Inhalt
- Laden aller Artikel auf die ein Benutzer Rechte hat
- Laden aller Artikel mit Inhalten (sprachabhängig) unter einem Navi-Knoten
- Laden einer Navigation bis zu einem bestimmten Knoten
- Laden eines Navigations-Knotens mit seinem sprachabhängigen Inhalt
- Laden der Navigationen auf die ein Benutzer oder eine Gruppe Rechte hat
- Speichern einzelner Objekte und Beziehungen

ergab, dass das Design theoretisch alle Anforderungen unterstützt und jede Beziehung ist abfragbar.

Durch die Struktur-Tabellen wird das Laden eines Inhalts in der entsprechenden Sprache natürlich etwas komplizierter, aber man möchte schließlich generisch bleiben. Möglich ist hier nämlich noch die Einführung eines Projekts und die Spezifizierung, welcher Artikel zu welchem Projekt gehört. Zusätzlich könnte man auch noch Inhalts-Container einführen, damit Inhalte in einer Ordner-Struktur abgelegt werden können.

Ich würde gerne mal einige Meinungen dazu hören. Kritik jeder Art ist willkommen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mister Ad

phpdummi

Keine Meinung, ist mir zu hoch
Aber eine Frage:
Mit welchem Programm hast du das Schema erstellt? Diesen "Feasibility-Check" macht auch das Programm?

Zergling-new

Was ist denn der Unterschied zwischen den ass_* (die Verknüpfungstabellen nehme ich an) und cmp_* (compare? inwiefern? Edit: ach Komposition, hm)?

Muss ich mir deine Artikel wie Wikipedia-Artikel XY vorstellen, der sich dadurch definiert, dass es den Artikel XY auf deutsch (Content DE) und englisch (Content EN) gibt?

Man könnte sich überlegen eher oder zusätzlich die Inhalte (Content) an Rechte zu koppeln, anstatt nur den Artikel. Warum sollte ich einen japanischen Content editieren dürfen, wenn mir offensichtlich die (sprachliche, nicht unbedingt inhaltliche) Kompetenz fehlt. Aber vielleicht treibt man es da zu weit.

Die Bezeichnung Article und Content finde ich dann aber zu ähnlich und nicht unbedingt von sich aus Aussagekräftig. Sprachversion klingt zwar abgedroschen, aber das genau ist es ja eigentlich.

Bei der Navigation verstehe ich nicht ganz den Unterschied zwischen Navigation und Navigations-Knoten. Definiert sich eine Navigation nicht durch seine Navigationsknoten-Kombination?
Wie baust du diese Navigation auf, Nested Set würde sich anbieten, benötigt ja aber nur eine Tabelle.

Was soll das CMS denn hauptsächlich verwalten - News? Oder frei und beliebig?

dr.e.

Hallo phpdummy,

Das Schema ist mit EA (Enterprise Architct) von Sparx Systems erstellt. Ist ein UML-Modellierungstool, das ich einsetze um Tabellen-Layouts (wie hier) oder Klassen-Diagramme nebst Anforderungs-Dokumentation zu erstellen (siehe z.B. http://www.adventure-php-framework.org/Seite/Gaestebuch). Auf der Webseite findest du mehr Infos: http://www.sparxsystems.at/.

"Feasibility-Check" bedeute einfach nur "Machbarkeitsanalyse". Ich überlege mir dabei, ob die Anwendungsfälle mit diesem Design abbildbar sind. Kann ich z.B. abfragen, welcher Benutzer auf welche Artikel Rechte hat, etc.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

dr.e.

Hallo Zergling,

ich unterscheide bei der Speicherung der Beziehungen zwischen den Qualitäten Assoziation (Objekt A KENNT ObjektB) und Komposition (Objekt A HAT Objekt B) - richtig.


Genau. In der Tabelle "cms_Content" speichere ich den eigentlichen Inhalt und ein Eintrag in "cms_Article" ist quasi nur ein mehrsprachiger Artikel mit mehreren Inhalten.


Das ist sicher eine gute Ergänzung. Die Abfrage wird aber ziemlich wild, da man ja Gruppen- und Benutzerrechte berücksichtigen muss. Aber das ist ein gutes Beispiel um JOINen zu üben


Da bin ich auch schon drübergestolpert. Hab mir dann aber gedacht, dass Article die Instanz eines Artikels ist und wenn dieses Objekt geladen wird, dann ist die sprache bekannt und ich mappe die Inhalte über die Beziehung direkt in das Objekt Artikel. Aus diesem Blickwinkel ist die Tabelle "cms_Content" nur eine "Hilfstabelle" der Datenschicht.


Das bedeutet: Eine Webseite kann mehrere Navigationen haben und eine Navigation komponiert mehrere Navigations-Punkte. Stell dir vor eine Webseite hat auf der linken Seite eine Haup-Navigation und horizontal oben eine generische Navigation mit Impressum, Sitemap, ..., dann sind das zwei unterschiedliche Navigationen. Ich möchte diese getrennt behandeln können, da ich dann auch die Ausgabe sauber trennen kann.


Frei & beliebig. Was ich noch gemacht habe ist ein ContentTagParser. Schreibst du z.B. in den Text ein "[TerminDB]", so wird dir die Termin-Datenbank beim generieren der Ausgabe dort reingesetzt. Diese wiederum ist ein eigenes Modul. Genauso kann man dort "[news date="123456" title="hallo"]my news content[/news]" reinschreiben und der entsprechende parser generiert dier daraus eine HTML-Darstellung (bbCodeParser). Man hat also die Freiheit alles einzubinden, was man sich denken kann. Die jeweiligen Module können natürlich wieder eigene Tabellen mitbringen.


Andere/weitere Meinungen?

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Zergling-new

Der Beitrag ist im Tutorials besser aufgehoben, daher verschoben und mit Prefix im Titel versehen.

brian johnson

hi,

ich hätte da zunächst einige grundsätzliche fragen:

1. die unterscheidung von "ass_group_article" und "ass_user_article" verbunden mit den pfeilen auf "cms_article" impliziert das es "cms_article" überlassen ist, welche rechte gelten, wenn überschneidungen vorhanden sind, oder?

2. wofür ist "ass_navinode_article"? ich sehe hier eindeutig eine modularität, ich könnte also "cms_article" durch beliebieges anderes, also beispielsweise einem kategorie modul, ersetzen. das heißt demnach auch ich könnte beides auf einer seite mischen. demnach wäre die navigation auf dem selben level wie "benutzer und rechte", also "global", d.h. immer einzubinden. was ich nicht verstehe, ist wie dieses mischen der modularität, die du eindeutig vorsiehst, funktioieren soll....und: warum ist sie nicht teil des blocks "navigation"?

3. ich sehe die sprache immer nur als eigenschaft eines objects. in diesem schema allerdings sehe ich, das die klasse "cms_language" im mittelpunkt steht. wer ruft wen?

__________________
PHP4?!?>>>Aktuelle PHP Version: 5.2.11 || 5.3.0
Suse 11.2 *vorfreude*

dr.e.

Hallo brian,

einige der Fragen beantworten sich einfach dadurch, dass das Diagramm ein bischen Objekte und Beziehungen mit ER-Diagramm vermischt. Das ER-Diagramm ist einfach die Implementierung eines UMLs, das die Beziehungen zwischen den in der Applikation existierenden Objekte beschreibt. Beispiel: Ein Benutzer ist der Ersteller eines Artikels. Aus diesem Grund wird das Objekt User mit dem Objekt Article assoziiert. Eine Assoziation muss deshalb her, da ein Artikel ohne eine Person existieren können soll und ein Artikel nicht zwangsläufig einer Person (alleine) gehören muss. Um diese Zuordnungen aufzulösen ist auch etwas Erfahrung notwendig, da Assoziationen und Kompositionen komplett andere Auswirkungen auf das Verhalten der Applikationen haben.

Nein, das nicht. Konkret geht es hier darum, dass nur diejenigen Artikel angezeigt werden, auf die ein Benutzer, oder eine Gruppe auch rechte haben. Gleiches Konstrukt siehst du auch bei den Navigationsknoten.

ass_navinode_article definiert, welche Inhalte unter welchem Navigationsknoten angezeigt werden. Diese Zuordnung kann beliebig sein, sprich ich kann alle Inhalte unter allen Navigationsknoten veröffentlichen, auf die ich auch Rechte habe. Das ist sehr generisch, ja. Einen cms_Article kann man erst mal nicht durch ein anderes Objekt ersetzen, es sei denn, es erbt von cms_Article, da diese Beziehung (noch) nicht existiert. Grundsätzlich ist das aber auch kein Problem, denn Module kann man auf der Inhaltsebene einbinden. Möglich wäre dies durch das Einbinden spezieller Tags wie [SchreibMirHierDasNewsModulHin]. Du hast jedoch Recht, man könnte auf der Ebene der navigationsknoten noch weiter Modularisieren, in dem man dem Navigationsknoten eine Art Typ (z.B. "Seitenvorlage") zuordnet, der jeweils eine andere Ausgabe auf Grund der unter dem Navigationsknoten befindlichen Inhalte ausgibt, oder z.B. einfach nur ein Modul einbindet. Auf der Ebene der Inhalte würde ich das persönlich nicht machen.

Mittelpunkt ist ja wohl optisch falsch, der liegt am linken Ende. Ich gebe dir natürlich Recht, Sprache ist ein Attribut eines Objekts, jedoch muss das auf ER-Ebene nicht der Fall sein. Ich habe das deshalb ausgelagert, dass ich einerseits entsprechende Beziehungen zu diesem Objekt aufbauen kann und andererseits eine Sprache und deren Attribute nur einmal pflegen muss. Weiterhin hätte ich sonst an vielen Stellen Mehrfachdatenhaltung, was ich persönlich nicht mag. Hier gilt - wieder aus Erfahrung die Regel: wenn du ein identisches Attribut über verschiedene Objekttypen verwendest, so lagere es in ein eigenes Objekt aus und binde es über eine Beziehung an. Wie du das nun im Domänen-Model deiner Anwendung präsentierst, bleibt der Mapper-Schicht vorbehalten. Eine Möglichkeit kann sein, die Sprache als Attribut in jedes Objekt zu speichern.

Alle Fragen beantwortet?

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

brian johnson

ja, deine antworten vertiefen das. es geht also mehr um die tatsächliche beziehung als um die umsetzung.

interessant.
du hast nicht noch einen berühmt berüchtigten links auf das adventure php framework dazu?

optisch ja, aber viele pfeile drauf

ok, wenn du mir jetzt noch die "ER-Ebene" erklärst würde ich den absatz komplett verstehen

auf jeden fall danke!

__________________
PHP4?!?>>>Aktuelle PHP Version: 5.2.11 || 5.3.0
Suse 11.2 *vorfreude*

dr.e.

Hallo brian,

Ich will dich ja nicht entäuschen, deshalb hier zwei Links:
* http://adventure-php-framework.org/S...ebuch-Tutorial (Gästebuch-Tutorial; zeigt dieses Thema im kleinen Stil)
* http://adventure-php-framework.org/f...plomarbeit.pdf (Arbeit über den Entwurf einer Applikation. Dort wird das nochmal genauer aufgeschlüsselt)


Es gibt mehrere Ansätze ein Objektmodell umzusetzen. Komplette Denormalisieren bedeutet, dass du irgendwie alles in einer Tabelle ablegst. Ob das nun sinnvoll ist oder nicht sei dahingestellt. Vollständige Normalisierung bedeutet, dass du alles haarklein zerlegst und sogar Objekte ein einzelne Attribute und deren Werte aufgespaltet speicherst. Das wird gerade für kleinere Applikationen unübersichtlich und zu aufwändig. Der von mir verfolgte Weg bedeutet, Applikationsobjekte in einer Tabelle zu speichern und nur deren Beziehungen in eigene Beziehungstabellen auszulagern.

Nehmen wir das oben genannte Gästebuch, so gibt es die Objekte "Guestbook", "Entry" und "Comment". Im UML der Applikation gibt es zwischen diesen Objekten eine Beziehung, die die Zugehörigkeit definiert. Ein Gästebuch hat ein oder mehrere Einträge und ein Eintrag hat ein oder mehrere Kommentare. Im ER-Diagramm sieht das dann so aus, dass es drei Tabellen für die drei Objekte gibt und zwei Tabellen, die die Beziehung zwischen den drei Objekten auflöst. Ausgelagerte Beziehungstabellen haben dabei den Charme, dass die Beziehung vor- und rückwärts auflösbar ist und man sich bei der Entwicklung leichter tut.

Ich hoffe, das beantwortet deine Frage!


Gerne!

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~