DB Aufbau

DB Aufbau

am 22.02.2005 08:44:42 von Stefan Klaeser

Moin NG,

ich habe eine Frage bezüglich des Aufbaus einer Datenbank.

Ich möchte ein kleines Shopsystem Programmieren und dabei Artikel
in mehrere Warengruppen eingliedern.
Es wird allerdings nur eine Ebene geben.
Wie stelle ich das am besten an?

Wenn ich der Tabelle mit Artikeln eine Spalte wgr verpasse und in
diese z.B. 1#5#13 schreibe, könnte ich ja mit LIKE auslesen.

Ich habe aber den verdacht das das nicht ganz so schön ist.
Irgendwo hab ich was von verknüpften Tabellen und dem Befehl
JOIN gelesen.

Kann mir dazu jemand eine Erklärung geben oder einen Link zu
einer verständlichen Anleitung?

Besten Dank im voraus.

--
Gruss
Stefan

--Si ehta uswi elate ini stesa bern icht.--

Re: DB Aufbau

am 22.02.2005 08:56:13 von Daniel Jaenecke

Stefan Klaeser wrote:

> ich habe eine Frage bezüglich des Aufbaus einer Datenbank.
>
> Ich möchte ein kleines Shopsystem Programmieren und dabei Artikel
> in mehrere Warengruppen eingliedern.
> Es wird allerdings nur eine Ebene geben.
> Wie stelle ich das am besten an?

-snip-

> Kann mir dazu jemand eine Erklärung geben oder einen Link zu
> einer verständlichen Anleitung?




Vor allem erstere ist IMO sehr einsteigerfreundlich.

Gruß
-dj-


--
1. Man gewoehnt sich an allem, sogar am Dativ.
2. Der Dativ ist dem Genitiv sein Tod.

Re: DB Aufbau

am 22.02.2005 15:01:34 von Michael Fesser

.oO(Stefan Klaeser)

>ich habe eine Frage bezüglich des Aufbaus einer Datenbank.
>
>Ich möchte ein kleines Shopsystem Programmieren und dabei Artikel
>in mehrere Warengruppen eingliedern.
>Es wird allerdings nur eine Ebene geben.
>Wie stelle ich das am besten an?

Eine Tabelle für die Artikel, eine für die Warengruppen. Da ein Artikel
offenbar in mehreren Warengruppen auftauchen kann, ist noch eine dritte
Tabelle notwendig, welche die beiden ersten verknüpft.

>Wenn ich der Tabelle mit Artikeln eine Spalte wgr verpasse und in
>diese z.B. 1#5#13 schreibe, könnte ich ja mit LIKE auslesen.

So ein Design ist kaputt und führt früher oder später zu ernsthaften
Problemen (Stichwort Normalisierung).

>Ich habe aber den verdacht das das nicht ganz so schön ist.
>Irgendwo hab ich was von verknüpften Tabellen und dem Befehl
>JOIN gelesen.

Vereinfachtes Beispiel mit drei Tabellen:

Die erste enthält Informationen über alle Artikel, jeder Artikel hat
eine eindeutige Artikelnummer als Primärschlüssel:

Artikel
-------
ArtikelID (primary key)
Name
Beschreibung
....

Die zweite enthält Informationen über die verfügbaren Warengruppen (läßt
sich auch relativ einfach erweitern auf verschachtelte Gruppen),
ebenfalls jede mit eindeutiger Nummer/ID:

Warengruppen
------------
GruppenID (primary key)
Name
Beschreibung
....

Die dritte Tabelle verknüpft die ersten beiden über deren IDs. Für jede
gültige Kombination aus Artikel und Warengruppe gibt es hier einen
Eintrag. Kommt ein bestimmter Artikel z.B. in drei Gruppen vor, gibt es
für diesen hier also drei Einträge:

Einordnung
----------
ArtikelID
GruppenID

HTH
Micha

Re: DB Aufbau

am 22.02.2005 17:18:59 von Stefan Klaeser

> >ich habe eine Frage bezüglich des Aufbaus einer Datenbank.
> >
> >Ich möchte ein kleines Shopsystem Programmieren und dabei Artikel
> >in mehrere Warengruppen eingliedern.
> >Es wird allerdings nur eine Ebene geben.
> >Wie stelle ich das am besten an?
>
> Eine Tabelle für die Artikel, eine für die Warengruppen. Da ein Artikel
> offenbar in mehreren Warengruppen auftauchen kann, ist noch eine dritte
> Tabelle notwendig, welche die beiden ersten verknüpft.
>
> >Wenn ich der Tabelle mit Artikeln eine Spalte wgr verpasse und in
> >diese z.B. 1#5#13 schreibe, könnte ich ja mit LIKE auslesen.
>
> So ein Design ist kaputt und führt früher oder später zu ernsthaften
> Problemen (Stichwort Normalisierung).
>
> >Ich habe aber den verdacht das das nicht ganz so schön ist.
> >Irgendwo hab ich was von verknüpften Tabellen und dem Befehl
> >JOIN gelesen.
>
> Vereinfachtes Beispiel mit drei Tabellen:
>
> Die erste enthält Informationen über alle Artikel, jeder Artikel hat
> eine eindeutige Artikelnummer als Primärschlüssel:
>
> Artikel
> -------
> ArtikelID (primary key)
> Name
> Beschreibung
> ...
>
> Die zweite enthält Informationen über die verfügbaren Warengruppen (läßt
> sich auch relativ einfach erweitern auf verschachtelte Gruppen),
> ebenfalls jede mit eindeutiger Nummer/ID:
>
> Warengruppen
> ------------
> GruppenID (primary key)
> Name
> Beschreibung
> ...
>
> Die dritte Tabelle verknüpft die ersten beiden über deren IDs. Für jede
> gültige Kombination aus Artikel und Warengruppe gibt es hier einen
> Eintrag. Kommt ein bestimmter Artikel z.B. in drei Gruppen vor, gibt es
> für diesen hier also drei Einträge:
>
> Einordnung
> ----------
> ArtikelID
> GruppenID

Hi Micha,

danke für Deine Antwort.
Wie würde den dann eine Abfrage aussehen?
Ich würde dann ja immer 3 Tabellen abfragen oder?
Also 3 Querys?

lg
Stefan

Re: DB Aufbau

am 22.02.2005 17:19:31 von Stefan Klaeser

> > ich habe eine Frage bezüglich des Aufbaus einer Datenbank.
> >
> > Ich möchte ein kleines Shopsystem Programmieren und dabei Artikel
> > in mehrere Warengruppen eingliedern.
> > Es wird allerdings nur eine Ebene geben.
> > Wie stelle ich das am besten an?
>
> -snip-
>
> > Kann mir dazu jemand eine Erklärung geben oder einen Link zu
> > einer verständlichen Anleitung?
>
>
>
>
> Vor allem erstere ist IMO sehr einsteigerfreundlich.
>
> Gruß
> -dj-

Danke, werd ih mir anschauen.

lg
Stefan

Re: DB Aufbau

am 22.02.2005 17:55:22 von Jens Riedel

> Hi Micha,
>
> danke für Deine Antwort.
> Wie würde den dann eine Abfrage aussehen?
> Ich würde dann ja immer 3 Tabellen abfragen oder?
> Also 3 Querys?

Nein, hier käme der von dir schon genannte "JOIN" ins Spiel, z.B.:

select A.*
from Artikel A, Warengruppen W, Einordung E
where E.ArtikelID = A.ID
and E.GruppenID = W.ID
and W.Name = ""

(Wenn du bereits die ID der Warengruppe kennst, reicht auch

select A.*
from Artikel A, Einordung E
where E.ArtikelID = A.ID
and E.GruppenID = )


Gruß,
Jens

Re: DB Aufbau

am 22.02.2005 18:02:08 von Michael Fesser

.oO(Stefan Klaeser)

>Wie würde den dann eine Abfrage aussehen?
>Ich würde dann ja immer 3 Tabellen abfragen oder?
>Also 3 Querys?

Drei Tabellen, aber nur eine Query. Stichwort: Joins. Damit werden die
Tabellen miteinander verknüpft. Um z.B. beim zuvor geposteten Beispiel
alle Artikel der Warengruppe 'foo' abzufragen, könnte eine Query in etwa
so aussehen:

SELECT a.ArtikelID, a.Name, a.Beschreibung
FROM Artikel a
INNER JOIN Einordnung USING (ArtikelID)
INNER JOIN Warengruppen w USING (GruppenID)
WHERE w.Name = 'foo'

Die drei mittleren Zeilen verknüpfen die Werte in den Tabellen anhand
besimmter Spalten miteinander, letztendlich ergibt sich bei obigem Code
das kartesische Produkt aller drei Tabellen. Die WHERE-Klausel am Ende
wählt daraus dann geziehlt bestimmte Zeilen aus.

Ein kurzer Test. Zunächst die drei Tabellen mit ein paar Testwerten:

mysql> SELECT * FROM Artikel;
+-----------+-----------+--------------+
| ArtikelID | Name | Beschreibung |
+-----------+-----------+--------------+
| 1 | this | NULL |
| 2 | that | NULL |
| 3 | something | NULL |
+-----------+-----------+--------------+

mysql> SELECT * FROM Warengruppen;
+-----------+------+--------------+
| GruppenID | Name | Beschreibung |
+-----------+------+--------------+
| 1 | foo | NULL |
| 2 | bar | NULL |
+-----------+------+--------------+

mysql> SELECT * FROM Einordnung;
+-----------+-----------+
| ArtikelID | GruppenID |
+-----------+-----------+
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
+-----------+-----------+

Somit gehören die Artikel 'this' und 'that' zur Gruppe 'foo', der
Artikel 'something' hingegen zur Gruppe 'bar'. Obige Query liefert dann
folgendes Ergebnis:

mysql> SELECT a.ArtikelID, a.Name, a.Beschreibung
-> FROM Artikel a
-> INNER JOIN Einordnung USING (ArtikelID)
-> INNER JOIN Warengruppen w USING (GruppenID)
-> WHERE w.Name = 'foo';
+-----------+------+--------------+
| ArtikelID | Name | Beschreibung |
+-----------+------+--------------+
| 1 | this | NULL |
| 2 | that | NULL |
+-----------+------+--------------+

Das Gleiche für die andere Warengruppe 'bar':

mysql> SELECT a.ArtikelID, a.Name, a.Beschreibung
-> FROM Artikel a
-> INNER JOIN Einordnung USING (ArtikelID)
-> INNER JOIN Warengruppen w USING (GruppenID)
-> WHERE w.Name = 'bar';
+-----------+-----------+--------------+
| ArtikelID | Name | Beschreibung |
+-----------+-----------+--------------+
| 3 | something | NULL |
+-----------+-----------+--------------+

Darüberhinaus sind natürlich auch andere Abfragen möglich, z.B. welchen
Warengruppen ein bestimmter Artikel zugeordnet ist.

HTH
Micha

Re: DB Aufbau

am 22.02.2005 18:59:35 von Stephan Seidel

Die dritte Tabelle Einordnung kann man sich sparen, wenn die beiden Tabellen
Artikel und Warengruppe entsprechend angepaßt werden:

> Artikel
> -------
> ArtikelID (primary key)
GruppenID <----------------------
> Name
> Beschreibung
> ...
>
> Warengruppen
> ------------
> GruppenID (primary key)
> Name
> Beschreibung
> ...

Die Abfragen gestalten sich dadurch auch etwas einfacher:

select A.*
from Artikel A, Warengruppen W
where A.GruppenID = W.GruppenID
   and W.Name = ""

(Wenn du bereits die ID der Warengruppe kennst, reicht auch

select A.*
from Artikel A
where A.GruppenID =

Re: DB Aufbau

am 22.02.2005 19:02:16 von Michael Fesser

.oO(Stephan Seidel)

>Die dritte Tabelle Einordnung kann man sich sparen, wenn die beiden Tabellen
>Artikel und Warengruppe entsprechend angepaßt werden:

Dann kann ein Artikel aber nur einer einzigen Warengruppe zugeordnet
werden (n:1-Beziehung), was nicht immer erwünscht ist. Will man beliebig
viele Artikel beliebig vielen Warengruppen zuordnen, handelt es sich um
eine m:n-Beziehung, zu deren Modellierung drei Tabellen notwendig sind.

Micha

Re: DB Aufbau

am 22.02.2005 19:09:36 von Stephan Seidel

Michael Fesser wrote:

> Dann kann ein Artikel aber nur einer einzigen Warengruppe zugeordnet
> werden (n:1-Beziehung), was nicht immer erwünscht ist. Will man beliebig
> viele Artikel beliebig vielen Warengruppen zuordnen, handelt es sich um
> eine m:n-Beziehung, zu deren Modellierung drei Tabellen notwendig sind.

Stimmt. Aber normalerweise sollte es auch so sein: Warengruppe -> Artikel
(1:n). Bei einer m:n-Beziehung geht auch die Eindeutigkeit verloren!
Welchen Sinn macht es einen Artikel mehreren Warengruppen zuzuordnen? Mir
fällt partout kein Beispiel aus der Praxis dazu ein.

Stephan

Re: DB Aufbau

am 22.02.2005 19:40:41 von Michael Fesser

.oO(Stephan Seidel)

>Stimmt. Aber normalerweise sollte es auch so sein: Warengruppe -> Artikel
>(1:n). Bei einer m:n-Beziehung geht auch die Eindeutigkeit verloren!

Eindeutigkeit ist aber nicht immer gegeben.

>Welchen Sinn macht es einen Artikel mehreren Warengruppen zuzuordnen? Mir
>fällt partout kein Beispiel aus der Praxis dazu ein.

Kommt natürlich drauf an, wie weit man die Spezialisierung der
Warengruppen treiben möchte. Nimm als (verwandtes) Beispiel einen
Kinofilm - nicht jeder Film läßt sich eindeutig einem bestimmten Genre
zuordnen. Je nach Art der Warengruppen/Kategorien/Wasauchimmer könnte
ich mir ähnliche Situationen auch bei einer Artikeldatenbank vorstellen.

Micha

Re: DB Aufbau

am 22.02.2005 22:03:01 von Niels Braczek

Stephan Seidel schrieb:
> Michael Fesser wrote:
>
>>Dann kann ein Artikel aber nur einer einzigen Warengruppe zugeordnet
>>werden (n:1-Beziehung), was nicht immer erwünscht ist. Will man beliebig
>>viele Artikel beliebig vielen Warengruppen zuordnen, handelt es sich um
>>eine m:n-Beziehung, zu deren Modellierung drei Tabellen notwendig sind.
>
> Stimmt. Aber normalerweise sollte es auch so sein: Warengruppe -> Artikel
> (1:n). Bei einer m:n-Beziehung geht auch die Eindeutigkeit verloren!
> Welchen Sinn macht es einen Artikel mehreren Warengruppen zuzuordnen? Mir
> fällt partout kein Beispiel aus der Praxis dazu ein.

Ein Beispiel: Montagematerial für Selbstbaumöbel. Das gleiche
Schraubenpack kann sowohl unter Küchen- als auch unter Büromöbel laufen.

MfG
Niels

Re: DB Aufbau

am 24.02.2005 08:29:19 von Stefan Klaeser

Hallo,

herzlichen Dank an alle.
Habs kapiert und klappt.

Danke und viele Grüsse

Stefan