Ich würde doch mal sagen, poste lauffähigen Code.torres hat geschrieben:wie poste ich mein DB Konzept hier genau? Die Sql-Statements zum erstellen der DB plus einiger Erklaerungen posten? Oder als Bild?
Was soll ich nehmen? Django oder WSGI?
-
BlackJack
@snafu: Der lauffähige Code zur DB ist doch momentan noch in PHP. Und ein DB-Entwurf ist ja grundsätzlich auch erst einmal unabhängig von der Programmiersprache. Ich denke das Datenbankmodell und eine Erklärung in Prosa soweit das aus dem Entwurf nicht klar wird, reicht aus.
Hallo,
hier waeren mal ein Bild, Prosa und Statements: http://www.ommeluse.de/.data/
(hab mir gedacht, dass das zu viele Daten fuer hier waeren)
Viele Gruesse,
Torres
hier waeren mal ein Bild, Prosa und Statements: http://www.ommeluse.de/.data/
(hab mir gedacht, dass das zu viele Daten fuer hier waeren)
Viele Gruesse,
Torres
-
BlackJack
@torres: Die beiden Tabellen `info` und `url` verstehe ich nicht. Da weichst Du in der grafischen Notation auch vom Rest ab. Was bedeuten `ziel` und `selbst`? Warum verweisen in `url` beide auf `pano`? Was sind da die Rollen der Verbindungen? Und Zusatzinformationen könntest Du doch später auch noch in zusätzlichen Tabellen unterbringen.
Und noch etwas zu den Verbindungen: Ich würde erst einmal redundante Wege vermeiden, solange nicht klar ist, dass dadurch Leistungsprobleme entstehen. Und da bin ich immer recht konservativ -- soll heissen, solange die O-Komplexität in Ordnung ist, gibt es keine Probleme mit der Leistung bis man dass tatsächlich durch Messungen belegen kann. `info.ziel` ist zum Beispiel redundant, weil man da auch über `info.selbst.objekt` hin kommt. Genau so `alt.objekt` was man auch über `alt.pano.objekt` erreicht.
Und noch etwas zu den Verbindungen: Ich würde erst einmal redundante Wege vermeiden, solange nicht klar ist, dass dadurch Leistungsprobleme entstehen. Und da bin ich immer recht konservativ -- soll heissen, solange die O-Komplexität in Ordnung ist, gibt es keine Probleme mit der Leistung bis man dass tatsächlich durch Messungen belegen kann. `info.ziel` ist zum Beispiel redundant, weil man da auch über `info.selbst.objekt` hin kommt. Genau so `alt.objekt` was man auch über `alt.pano.objekt` erreicht.
Hallo BlackJack,
was ich im dot nicht abbilden konnte.
Auch fuer alt.objekt und alt.pano.objekt hatte ich unter "Prosa" bemerkt, dass das neu ist und ich mich noch nicht entschieden habe,
welches ich davon behalte, einer sollte weg, ist eh klar.
Viele Gruesse,
Torres
Steht eigentlich unter "Prosa": die Notation ist anders, weil die Paare (selbst und ziel) jeweils tabellenuebergreifend uniq sein sollen,BlackJack hat geschrieben:@torres: Die beiden Tabellen `info` und `url` verstehe ich nicht. Da weichst Du in der grafischen Notation auch vom Rest ab. Was bedeuten `ziel` und `selbst`? Warum verweisen in `url` beide auf `pano`? Was sind da die Rollen der Verbindungen? Und Zusatzinformationen könntest Du doch später auch noch in zusätzlichen Tabellen unterbringen.
was ich im dot nicht abbilden konnte.
Steht eigentlich auch unter "Prosa" url.self und info.self zeigen auf ein Objekt mit Bild (das Bild auf welchem die Information dann im Web abgebildet ist) Das ist in der Tat redundant, aber ich hatte auch dazugeschrieben, dass ich das so gemacht hatte, um flexibel zu sein was die Attribute fuer urls und infos betrifft. url.ziel und info.ziel zeigt jeweils entweder auf ein Objekt ohne Bild oder ein Objekt mit Bild.BlackJack hat geschrieben: Und noch etwas zu den Verbindungen: Ich würde erst einmal redundante Wege vermeiden, solange nicht klar ist, dass dadurch Leistungsprobleme entstehen. Und da bin ich immer recht konservativ -- soll heissen, solange die O-Komplexität in Ordnung ist, gibt es keine Probleme mit der Leistung bis man dass tatsächlich durch Messungen belegen kann. `info.ziel` ist zum Beispiel redundant, weil man da auch über `info.selbst.objekt` hin kommt. Genau so `alt.objekt` was man auch über `alt.pano.objekt` erreicht.
Auch fuer alt.objekt und alt.pano.objekt hatte ich unter "Prosa" bemerkt, dass das neu ist und ich mich noch nicht entschieden habe,
welches ich davon behalte, einer sollte weg, ist eh klar.
Viele Gruesse,
Torres
-
BlackJack
@torres: Ich verstehe es mit jeder Erklärung ein bisschen weniger. Lies Dir Deine letzte Erklärung zu `selbst` und `ziel` noch einmal durch und vergleiche das mit dem Bild -- es passt nicht zusammen. Und erklärt immer noch nicht was diese Verbindung eigentlich bedeuten soll.
Servus BlackJack,
ich das Bild mal neugemalt (das alte steht auch noch da). Die alt Tabelle habe ich korrigiert.
Die andere Formatierung der url und info Tabelle hab ich raus, das entspricht jetzt dem tatsaechlichen Schema.
hm, allerdings weiss ich jetzt nicht genau wie ich es noch erklaeren soll, was ich damit moechte.
Also: ich zeige auf der Seite ein Bild(A) (url.self oder info.self) auf dem Bild ist entweder ein Link zu einem
naechsten Bild(B) (url.ziel) oder eine Info(info.ziel). Es ist in zwei Tabellen, damit ich die beiden voneinander getrennt
aendern kann (neues Attribut hinzufuegen)
?
Viele Gruesse,
Torres
ich das Bild mal neugemalt (das alte steht auch noch da). Die alt Tabelle habe ich korrigiert.
Die andere Formatierung der url und info Tabelle hab ich raus, das entspricht jetzt dem tatsaechlichen Schema.
hm, allerdings weiss ich jetzt nicht genau wie ich es noch erklaeren soll, was ich damit moechte.
Also: ich zeige auf der Seite ein Bild(A) (url.self oder info.self) auf dem Bild ist entweder ein Link zu einem
naechsten Bild(B) (url.ziel) oder eine Info(info.ziel). Es ist in zwei Tabellen, damit ich die beiden voneinander getrennt
aendern kann (neues Attribut hinzufuegen)
?
Viele Gruesse,
Torres
-
BlackJack
@torres: Was so rein Formal zur Vollständigkeit noch fehlt sind Kardinalitäten und Use Cases. Und vielleicht auch Generalisierungen/Spezialisierungen. Sind Panoramen Objekte!? Ein Frage die mir mal durch den Kopf ging. Letztendlich verstehe ich das wahrscheinlich nicht, weil ich mit `objekt`, `info`, und `url` einfach nichts anfangen kann. Ich weiss nicht wie die semantisch zusammenhängen sollen und was damit gemacht wird.
`weg.teilgebiet` ist IMHO redundant.
`weg.teilgebiet` ist IMHO redundant.
Hallo BlackJack,
for i in `mysql -N db -e "show tables"`; do echo $i; mysql -N db -e "select count(*) from $i";done|egrep -v "\+"
gebiet
19
info
2059
member
303
objekt
649
pano
373
teilgebiet
73
url
2785
weg
64
Use Cases: ganz unten auf der Seite ist ein Link zum Projekt.
Sind Panoramen Objekte? Nein, darum stehen sie in der pano Tabelle und nicht in der objekt Tabelle. Objekte sind: Berg, Huegel, Weg, Dorf, Alm usw und weil ich dafuer keinen Sammelbegriff gefunden habe, habe ich Objekt gewaehlt, man koennte vielleicht auch Landschaftsobjekt sagen, aber da muss man mehr tippen.
Url haette ich auch Link nennen koennen. Ein Link ist eine klickbare Verbindung von einem Panorama zum naechsten Panorama, waehrend eine Info lediglich eine Beschriftung ist. Auf einem Panoramabild sind also Berge in der Ferne mit "Infos" Beschriftet und Berge, fuer die es Panoramen gibt ist hinter der Beschriftung also ein Link (mit url) hinterlegt.
Schau es Dir halt mal an, da wird das dann vielleicht klarer? (siehe Link ganz unten in dem Link, den ich vorher geschickt hatte)
oh, weg.teilgebiet ist tatsaechlich redundant :-/
Viele Gruesse,
Sylvia
Kardinalitäten (musste erstmal nachschauen was das genau ist):BlackJack hat geschrieben:@torres: Was so rein Formal zur Vollständigkeit noch fehlt sind Kardinalitäten und Use Cases. Und vielleicht auch Generalisierungen/Spezialisierungen. Sind Panoramen Objekte!? Ein Frage die mir mal durch den Kopf ging. Letztendlich verstehe ich das wahrscheinlich nicht, weil ich mit `objekt`, `info`, und `url` einfach nichts anfangen kann. Ich weiss nicht wie die semantisch zusammenhängen sollen und was damit gemacht wird.
`weg.teilgebiet` ist IMHO redundant.
for i in `mysql -N db -e "show tables"`; do echo $i; mysql -N db -e "select count(*) from $i";done|egrep -v "\+"
gebiet
19
info
2059
member
303
objekt
649
pano
373
teilgebiet
73
url
2785
weg
64
Use Cases: ganz unten auf der Seite ist ein Link zum Projekt.
Sind Panoramen Objekte? Nein, darum stehen sie in der pano Tabelle und nicht in der objekt Tabelle. Objekte sind: Berg, Huegel, Weg, Dorf, Alm usw und weil ich dafuer keinen Sammelbegriff gefunden habe, habe ich Objekt gewaehlt, man koennte vielleicht auch Landschaftsobjekt sagen, aber da muss man mehr tippen.
Url haette ich auch Link nennen koennen. Ein Link ist eine klickbare Verbindung von einem Panorama zum naechsten Panorama, waehrend eine Info lediglich eine Beschriftung ist. Auf einem Panoramabild sind also Berge in der Ferne mit "Infos" Beschriftet und Berge, fuer die es Panoramen gibt ist hinter der Beschriftung also ein Link (mit url) hinterlegt.
Schau es Dir halt mal an, da wird das dann vielleicht klarer? (siehe Link ganz unten in dem Link, den ich vorher geschickt hatte)
oh, weg.teilgebiet ist tatsaechlich redundant :-/
Viele Gruesse,
Sylvia
-
BlackJack
@torres: Bei Kardinalitäten hast Du das falsche gefunden. Das bezog sich auf das Diagramm und da bezeichnet es die Angaben wie oft ein Exemplar an einer Beziehung teilnimmt. Also bei Gebieten und Teilgebieten wäre das zum Beispiel 1:N weil ein Gebiet mehrere Teilgebiete hat. Oder in UML-Notation (1, 1..*), was zusätzlich aussagt, dass es mindestens ein Teilgebiet geben muss.
Das Panoramen keine Objekte sind, kann man nicht daran sehen, dass sie in einer eigenen Tabelle stehen. Auch in einer relationalen Datenbank möchte man ja Generalisierungen/Spezialisierungen abbilden. Also zum Beispiel Kunden und Mitarbeiter, die als Personen gemeinsame Daten haben. Dann kann man eine Tabelle `person` mit den gemeinsamen Daten ablegen -- zum Beispiel Name, Geburtsdatum usw. und jeweils eine Tabelle `mitarbeiter` und `kunde` wo die Informationen drin steheh, die jeweils nur für diese Personenarten gelten. Und da würde man die Frage ob ein `kunde` eine `person` ist, mit "Ja" beantworten.
Ich habe mal versucht ein ER-Diagramm daraus zu machen [1]_. Noch ohne künstliche IDs -- ausser bei `weg`. Die `member`-Tabelle ist da nicht drin, weil das nur eine einfache N:M-Verbindung ist. Solange das so bleibt, braucht die Tabelle später übrigens auch keine eigene `id`. Das alternative Bild habe ich auch erst einmal raus gelassen.
.. [1] http://dl.dropbox.com/u/5914422/pyforum/pano_er_001.png
Mein Verständnisproblem liegt jetzt bei den drei Entities `objekt`, `panorama`, und `panorama_objekt_info`. Welches geht mit welchem, wie viele Verbindungen ein. Ein Objekt kann in mehr als einem Panorama enthalten sein, nehme ich mal an. Also eine Hütte zum Beispiel kann ja in zwei Panoramen zu sehen sein, welche an verschiedenen Punkten um die Hütte herum aufgenommen wurden. Die Informationstabelle macht auf mich jetzt aber im Moment den Eindruck, als sei es eine Verbindungstabelle zwischen `objekt` und `panorama`. Dann wäre eine direkte Verbindung zwischen den beiden Tabellen aber redundant und `panorama` bräuchte keinen Fremdschlüssel auf `objekt`. Es sei denn der bedeutet etwas anderes als "Panorame enthält Objekt". Oder haben nicht alle in einem Panorama enthaltenen Objekte auch eine (x,y)-Position? Die Frage kann man zum Beispiel weder aus dem Diagramm noch durch anschauen der Webseite beantworten.
Das Panoramen keine Objekte sind, kann man nicht daran sehen, dass sie in einer eigenen Tabelle stehen. Auch in einer relationalen Datenbank möchte man ja Generalisierungen/Spezialisierungen abbilden. Also zum Beispiel Kunden und Mitarbeiter, die als Personen gemeinsame Daten haben. Dann kann man eine Tabelle `person` mit den gemeinsamen Daten ablegen -- zum Beispiel Name, Geburtsdatum usw. und jeweils eine Tabelle `mitarbeiter` und `kunde` wo die Informationen drin steheh, die jeweils nur für diese Personenarten gelten. Und da würde man die Frage ob ein `kunde` eine `person` ist, mit "Ja" beantworten.
Ich habe mal versucht ein ER-Diagramm daraus zu machen [1]_. Noch ohne künstliche IDs -- ausser bei `weg`. Die `member`-Tabelle ist da nicht drin, weil das nur eine einfache N:M-Verbindung ist. Solange das so bleibt, braucht die Tabelle später übrigens auch keine eigene `id`. Das alternative Bild habe ich auch erst einmal raus gelassen.
.. [1] http://dl.dropbox.com/u/5914422/pyforum/pano_er_001.png
Mein Verständnisproblem liegt jetzt bei den drei Entities `objekt`, `panorama`, und `panorama_objekt_info`. Welches geht mit welchem, wie viele Verbindungen ein. Ein Objekt kann in mehr als einem Panorama enthalten sein, nehme ich mal an. Also eine Hütte zum Beispiel kann ja in zwei Panoramen zu sehen sein, welche an verschiedenen Punkten um die Hütte herum aufgenommen wurden. Die Informationstabelle macht auf mich jetzt aber im Moment den Eindruck, als sei es eine Verbindungstabelle zwischen `objekt` und `panorama`. Dann wäre eine direkte Verbindung zwischen den beiden Tabellen aber redundant und `panorama` bräuchte keinen Fremdschlüssel auf `objekt`. Es sei denn der bedeutet etwas anderes als "Panorame enthält Objekt". Oder haben nicht alle in einem Panorama enthaltenen Objekte auch eine (x,y)-Position? Die Frage kann man zum Beispiel weder aus dem Diagramm noch durch anschauen der Webseite beantworten.
Hallo BlackJack,
(wobei die sich aber nicht wesentlich zu meinem Entwurf geaendert hat, eigentlich gar nicht geaendert hat?)
Fuer panorama_info und panorama gilt im Prinzip das gleiche, nur, dass die Verbindung <in> nicht nach panorama gehen kann,
weil fuer das entsprechende objekt kein panorama vorhanden ist, also muss der Zeiger auf die Objekt Tabelle zeigen.
Panorama braucht einen Fremdschluessel auf Objekt. Weil nur ueber diese Tabelle geklaert werden kann, wie es heisst und in welchem Teilbegiet es sich befindet. Die Tabelle Panorama enthaelt keine Landschaftsnamen. Der Fremdschluessel von Panorama zu Objekt bedeutet nicht "Panorame enthält Objekt", sondern "Panorama ist dieses Objekt".
Alle Objekte haben in verschiedenen Panoramen verschiedene x, y Werte und: ja, alle in einem Panorama enthaltenene Objekte haben x,y Werte.
pff
Viele Gruesse,
Torres
Also soweit ich das verstanden habe, kann man panorama_link mit der dargestellten Beziehung zu panorama so lassen.BlackJack hat geschrieben: .. [1] http://dl.dropbox.com/u/5914422/pyforum/pano_er_001.png
Mein Verständnisproblem liegt jetzt bei den drei Entities `objekt`, `panorama`, und `panorama_objekt_info`. Welches geht mit welchem, wie viele Verbindungen ein. Ein Objekt kann in mehr als einem Panorama enthalten sein, nehme ich mal an. Also eine Hütte zum Beispiel kann ja in zwei Panoramen zu sehen sein, welche an verschiedenen Punkten um die Hütte herum aufgenommen wurden. Die Informationstabelle macht auf mich jetzt aber im Moment den Eindruck, als sei es eine Verbindungstabelle zwischen `objekt` und `panorama`. Dann wäre eine direkte Verbindung zwischen den beiden Tabellen aber redundant und `panorama` bräuchte keinen Fremdschlüssel auf `objekt`. Es sei denn der bedeutet etwas anderes als "Panorame enthält Objekt". Oder haben nicht alle in einem Panorama enthaltenen Objekte auch eine (x,y)-Position? Die Frage kann man zum Beispiel weder aus dem Diagramm noch durch anschauen der Webseite beantworten.
(wobei die sich aber nicht wesentlich zu meinem Entwurf geaendert hat, eigentlich gar nicht geaendert hat?)
Fuer panorama_info und panorama gilt im Prinzip das gleiche, nur, dass die Verbindung <in> nicht nach panorama gehen kann,
weil fuer das entsprechende objekt kein panorama vorhanden ist, also muss der Zeiger auf die Objekt Tabelle zeigen.
Panorama braucht einen Fremdschluessel auf Objekt. Weil nur ueber diese Tabelle geklaert werden kann, wie es heisst und in welchem Teilbegiet es sich befindet. Die Tabelle Panorama enthaelt keine Landschaftsnamen. Der Fremdschluessel von Panorama zu Objekt bedeutet nicht "Panorame enthält Objekt", sondern "Panorama ist dieses Objekt".
Alle Objekte haben in verschiedenen Panoramen verschiedene x, y Werte und: ja, alle in einem Panorama enthaltenene Objekte haben x,y Werte.
pff
Viele Gruesse,
Torres
-
BlackJack
@torres: Aber ist die URL/Link-Tabelle dann nicht überflüssig? Kommt man dann nicht hiermit aus http://dl.dropbox.com/u/5914422/pyforum/pano_er_002.png ?
Es sei denn Du möchtest Objekte im Panorama darstellen, die zwar selbst wieder Panoramen repräsentieren, aber nicht immer als Link darauf dargestellt werden sollen.
Es sei denn Du möchtest Objekte im Panorama darstellen, die zwar selbst wieder Panoramen repräsentieren, aber nicht immer als Link darauf dargestellt werden sollen.
Hallo BlackJack,
Viele Gruesse,
Torres
ja, fast genauso koennte man es ausdruecken. Die einen representieren ein Panorama mit Link darauf, die anderen nicht oder noch nicht. Erstere hab ich bisher als url bezeichnet und die anderen als info.BlackJack hat geschrieben: Es sei denn Du möchtest Objekte im Panorama darstellen, die zwar selbst wieder Panoramen repräsentieren, aber nicht immer als Link darauf dargestellt werden sollen.
Viele Gruesse,
Torres