Datenbank strukturierung...

[Anonymous]

Hallo zusammen...
Seit langem bin ich dabei, eine Download-DB für eine spezielle Sparte zusammen zu Basteln...  nun bin ich über folgendes Problem gestolpert:

Ich möchte eine Datenbank, welche ohne Probleme Erweitert werdenb kann!

Die Strukturierung ist wie folgt, zur Zeit, 4 Hauptkategorien, mit je 3-9 Unterkategorien, jede Unterkategorie enthält zur Zeit ca. 5-50 Einträge!

Wie erstelle ich nun am sinnvollsten die Tabellen ?
1 Tabelle für Einträge, mit "beschreibung, url, name, kategorie, unterkategorie"  Wie aber soll ich das mit den kotegrien und unterkategorien einordnen ?

Oder wäre es einfacher das ganze anders aufzubauen ? Mache ich einen grundlegenden Fehler ?

Vielen Dank für Eure profesionellen Tips....

Euer

Anonymous

[Roman Pfarrhofer]

Hi Anonymous!

So mal eine Bsp auf die Schnelle http://195.202.152.140/Sample_DB.gif.

Also noch eine kleine Erörterung dazu:
Also in die erste Tabelle kommen ALLE Kategorien egal ob haupt-, über- oder unterkategorie. Alle Hauptkategorien haben bei "num_parent_Kategorie" den Wert "0" und alle anderen haben den "idx_Kategorie_ID" von der Eltern (also Übergeordenten Kategorie)

In der Tabelle tbl_Liste werden alle URLs eingetragen

Und in der mittleren Tabelle werden die Verbindungen zu den Gruppen hergestellt. Man kann mehreren Gruppen die selbe URL zuweisen und auch einer Gruppe mehrere URLs.

Der Ansatz mag vielleicht anfangs etwas verwirrend sein, aber die Daten sind nach allen Richtung erweiterbar, ohne daß man die DB ändern muß!

Legende:
idx ... Index
txt ... Text
num ... Zahl
tbl ... Tabelle

Noch Fragen?

CU Roman

[Anonymous]

Hi Roman,

Zuersteinmal, vielen Dank für Eure Beiträge.. ich weiss das wircklich zu schätzen, es ist beeindruckend was man hier im Forum für Fachleute antrifft, welche nicht nur auf Bares aus sind (Gillt auch für den Betreiber des Forums)!

Nun, deine Lösung sieht interesannt aus, wie siehts mit der Geschwindigkeit aus ? Das ganze sollte nachher mit einer LAMP-Kombination laufen (Linux-Apache-MySQL-PHP3)!

Wäre es nicht schneller, 2 Tabellen zu machen, eine für Kategorie, eine für Unterkategorien ? Plus eine 3te, welche Kategorie, Unterkategorie und einträger verknüpft? Hab da mal was gehört das "null"-werte nicht ganz konform sind...

Was erweitert wir:  Kategorien, Untrerkategorien, und einträge... an der Strucktur selber sollte es eigentlich bleiben, also immer 1 Kategorie, mit meheren Unterkategorien. Jede unterkategorie besteht hingegen wieder aus vielen Einträgen...  ähh.. alles klar ?

Also, nochmals vielen Dank....

Anonymous

Hi Anonymous!

So mal eine Bsp auf die Schnelle http://195.202.152.140/Sample_DB.gif.

Also noch eine kleine Erörterung dazu:
Also in die erste Tabelle kommen ALLE Kategorien egal ob haupt-, über- oder unterkategorie. Alle Hauptkategorien haben bei "num_parent_Kategorie" den Wert "0" und alle anderen haben den "idx_Kategorie_ID" von der Eltern (also Übergeordenten Kategorie)

In der Tabelle tbl_Liste werden alle URLs eingetragen

Und in der mittleren Tabelle werden die Verbindungen zu den Gruppen hergestellt. Man kann mehreren Gruppen die selbe URL zuweisen und auch einer Gruppe mehrere URLs.

Der Ansatz mag vielleicht anfangs etwas verwirrend sein, aber die Daten sind nach allen Richtung erweiterbar, ohne daß man die DB ändern muß!

Legende:
idx ... Index
txt ... Text
num ... Zahl
tbl ... Tabelle

Noch Fragen?

CU Roman

[Tom]

Hallo Anonymer

Im Sinne der realtionalen datenmodellierung hast Du es hier mit 3 Entitäten in jeweils einer 1:n-Beziehung zu tun.
Dies sieht in etwa so aus:

------------------              ------------------              ------------------
                       1:n                             1:n                        
  Hauptkategorie  -----------<  Unterkategorie  -----------<      Eintrag    
                                                                                  
------------------              ------------------              ------------------

Das heisst, Du erstellst 3 Tabellen mit etwa folgendem Aufbau:
Hauptkategorie:

Feld:   Datentyp:   Bemerkungen:      
HK_ID   int         PrimaryKey
HK_Text char(255)   Textfeld mit dem Namen der Hauptkategorie

Unterkategorie:

Feld:   Datentyp:   Bemerkungen:      
UK_ID   int         PrimaryKey
HK_ID int      ForeignKey aus Tabelle Hauptkategorie
UK_Text char(255)   Textfeld mit dem Namen der Unterkategorie

Eintrag:

Feld:   Datentyp:   Bemerkungen:      
EN_ID   int         PrimaryKey
UK_ID int      ForeignKey aus Tabelle Unterkategorie
EN_desc char(255)   Felder je nach Bedarf
EN_url  char(255)   Felder je nach Bedarf
EN_name char(255)   Felder je nach Bedarf

Dies ist eine Möglichkeit die Daten zu strukturieren.

Natürlich kannst Du auch komplexere Modellierung wählen, bei der eine baumartige Struktur der Kategorien abgebildet werden. Siehe dazu den Thread weiter unten <35455.html>.

Ich hoffe, das hilft Dir fürs Erste weiter.

Grüsse

Tom

[Roman Pfarrhofer]

Hi Tom!

Bevorzuge meinen Vorschlag, da wie gefordert die DB nach allen seiten offen ist, denn bei deiner ist keine m:n beziehung zw. Kategorie und Link vorhanden. Aber das muß Anonymous entscheiden, ob er meinen Vorschlag braucht.

Aber worauf ich eingentlich hinaus wollte ist dein Vorschlag <35455.html>. Die, wie du bezeichnest kompliziert Form, verstößt gegen die Entitätsintegrität und gegen die zweite Normalform. Gebe zu, daß meine tbl_Kategorie nicht 100% der zweiten Normalform entspricht, aber sonst wäre es noch komplizierter geworden <g>.

Aber stelle dir mal deinen Vorschlag mit so ab 1000 Einträgen vor - wie soll man da irgendwas warten? Die Garbage-Collection wird elends kompliziert!

CU Roman

[Tom]

Hallo Roman

Bevorzuge meinen Vorschlag, da wie gefordert die DB nach allen seiten offen ist, denn bei deiner ist keine m:n beziehung zw. Kategorie und Link vorhanden. Aber das muß Anonymous entscheiden, ob er meinen Vorschlag braucht.

Mein Vorschlag war einfach und geradeaus gedacht.
Natürlich ist es flexibler alle Kategorien (also Hauptkategorien, Unterkategorien, Zwischenkategorien, Zwischenunterkategorien... ;-) ) in einer Tabelle abzulegen und mit einem Zeiger auf sich selber hierarchisch zu strukturieren. Das Ganze muss aber in der Bearbeitung etwas aufwendiger angepackt werden. Mein Vorschlag ist zwar einfacher, dafür aber völlig unflexibel bezüglich der Anzahl Hierarchestufen in den Kategorien.
Da soll wirklich Anonymous entscheiden, was ihm im Moment eher hilft :-)

Aber worauf ich eingentlich hinaus wollte ist dein Vorschlag <35455.html>. Die, wie du bezeichnest kompliziert Form, verstößt gegen die Entitätsintegrität und gegen die zweite Normalform. Gebe zu, daß meine tbl_Kategorie nicht 100% der zweiten Normalform entspricht, aber sonst wäre es noch komplizierter geworden <g>.

Mein Vorschlag <35455.html> bildet eine typische Baumstruktur (auch für Objekte) in einer relationalen Datenbank ab. Beispiele sind: Dateisysteme, Katalogstrukturen, Organistationen etc.
Die Vorteile gegenüber Deinem Vorschlag sind:

• Jedes Element (ob Wurzel, Knoten oder Blatt) weiss nur gerade das nötigste über die direkt darüber- und darunterliegende Elemente.
• Innerhalb eines Astes der Baumstruktur können beliebig Knoten und Blätter gemischt werden.
• Es ist eine sortierreihenfolge innerhalb des Astes gegeben.
• Ganze Äste der Struktur können mit einer Datensatzänderung innerhalb der Baumstruktur verschoben werden.

Die Nachteile meines Vorschlages:

• Das Löschen ganzer Äste muss durch rekursive Funktionen erfolgen (-> Garbage Collection :-( Du sagst es ...). Dies kann nicht mehr über einfache SQL-Statements realisiert werden. Dazu sind Stored-Procedures oder Funktionen im Anwendungsprogramm notwendig.
• Das physikalische Kopieren eines Astes muss ebenfalls über rekursive Funktionen erfolgen.

Im Grossen und Ganzen sehe ich jedoch bei baumartig (hierarchisch) strukturierten Daten, die sehr flexibel sein müssen, die Vorteile eher bei meinem Modell.

Mit besten Grüssen

Tom

[Tom]

Hallo Roman

Natürlich hast Du recht, bezüglich den Normalformen.

Die bescreibenden Inhalte wie Text etc. gehören in eine separate Tabelle mit einem eigenen Key (z.B. Ele_ID). Dieser Key wir dann in der eigentlichen Strukturtabelle verwendet, um auf das Element zu referenzieren.

Das Datenmodel sieht dann etwa so aus:

Structure:

Feld             Datentyp    Bemerkungen
Str_ID           int         PrimaryKey
Str_ParentID     int         Zeiger auf das übergeordnete Element
Str_FirstChildID int         Zeiger auf das erste untergeordnete Element
Str_NextID       int         Zeiger auf das nächste Element auf der gleichen Ebene
Ele_ID           int         ForeignKey, Zeiger zum eigentlichen Element in der Tabelle Element

Element:

Feld             Datentyp    Bemerkungen
Ele_ID           int         PrimaryKey
Ele_Text         char(255)   Textfeld für das Element.
                             Hier können nun beliebig viele beschreibende Felder angehängt werden.

Ich hoffe, dies hält Deiner messerscharfen Kritik stand ;-)

Grüsse

Tom

[Roman Pfarrhofer]

Hallo Tom!

Ich hoffe, dies hält Deiner messerscharfen Kritik stand ;-)

Hält sie - endlich mal wer der meine Sprache spricht *fg*. Hoffe wir können in zukunft weiterhin etwas fachsimpeln - aber bei deinem "einfachen" Vorschlag habe ich immer noch unbehagen. Kommt warscheinlich daher, daß mir das ganze schon ins Blut übergegangen ist und ich nur noch in Tabellen mit 10.000 einträgen aufwärts denke *G*.

Also bis auf ein weiteres,

CU Roman

[Tom]

Hallo Roman

• aber bei deinem "einfachen" Vorschlag habe ich immer noch unbehagen. Kommt warscheinlich daher, daß mir das ganze schon ins Blut übergegangen ist und ich nur noch in Tabellen mit 10.000 einträgen aufwärts denke *G*.

Der einfache Vorschlag war wirklich _nur_ geradeaus gedacht. Zwar das exakte Abbild der Wirklichkeit ohne weitere Abstrahierung, dadurch aber völlig unflexibel und der (fast) garantierte Stolperstein bei den sich ständig ändernden Kundenwünschen (bzw. der sich ändernden Realität).

Kommt wohl auch daher, dass ich bezüglich der Datenmodellierung etwas aus der Übung gekommen bin ;-)

Also darauf, dass ich hier wieder etwas Stoff finden werden :-)

Grüsse

Tom

[Michael Schröpl]

Ich möchte eine Datenbank, welche ohne Probleme Erweitert werdenb kann!

:-))) Das ist ungefähr so leicht, wie eine WebSite zu bauen, die in allen Browsern aller Besucher perfekt aussieht.

Oder wäre es einfacher das ganze anders aufzubauen ? Mache ich einen grundlegenden Fehler ?

Ich würde damit anfangen, zu definieren, welche Operationen auf Deinen Daten möglich sein sollen. Ungeachtet der (richtigen) relationalen Zerlegung des Datenmodells in den anderen Threads ist es nicht zuletzt das, was Deine Anwendung letztlich dem Benutzer zeigen wird. Das definiert auch Deine erforderlichen Zugriffspfade, insbesondere Tabellen oder auch Views. Auf diesen kannst Du dann schon mal Deine Anwendung prototypen.

In gewisser Weise kann man die tatsächliche Repräsentation der Daten in Tabellen sogar so weit einschalen, daß sie für die Zugriffsoperationen - na, sagen wir mal: Weniger wichtig werden. (Schreiben durch Views hindurch geht halt nicht immer.)
Du kannst also die Definition der Tabellen vom Relationenmodell Deiner Daten, die SQL-Anweisungen aber von Deinen Anforderungen ableiten und zur Vereinfachung eine Zwischenschicht an Views einfügen, wo beide Welten nicht automatisch homogen zusammenpassen.
Es ist für die konkrete Definition der Tabellen durchaus wichtig, ob Du in ihnen viele Änderungen vornimmst (und welche), aber für die Abfrage der Werte reichen Dir die Views (egal, auf welchen Anfragen darunterliegender Tabellen diese letztlich basieren).

Wahrscheinlich war das jetzt der zu große Hammer für die kleine Maus. Aber überlege Dir wirklich zuerst die Ausgabeformate und definierte die Tabellen später.