Normalisierung einer DB

Hallo zusammen,

es gibts doch diese Preisvergleichsuchmaschienen wie billiger.de usw.
Wie sehen die normalisierten Tabellen einer solchen DB aus? Ich brauch nur
die Grundstruktur, nichts tiefgehendes.

Ist meine Überlegung für die tabellen so richtig, oder muss ich da noch was
aufteilen?


--Artikel--
Art_Nr
Artikel_Name


--Shop--
Shop_Nr
Art_Nr
Shop_Name


--Preis--
PreisNr.
Art_Nr
Preis

Feld "Art_Nr" ist in "--Preis--" und "--Shop--" der Fremdschlüssel von
"--Artikel--"

Gruß anikel

Re: Normalisierung einer DB

anikel schrieb:
>
> Ist meine Überlegung für die tabellen so richtig, oder muss ich da
> noch was aufteilen?
>
>
> --Artikel--
> Art_Nr
> Artikel_Name
>
>
> --Shop--
> Shop_Nr
> Art_Nr
> Shop_Name
>
>
> --Preis--
> PreisNr.
> Art_Nr
> Preis
>
> Feld "Art_Nr" ist in "--Preis--" und "--Shop--" der Fremdschlüssel
> von
> "--Artikel--"


Wie wär's mit:

Artikel:
+ art_nr (*)
+ artikel_name

ShopArtikel:
+ id (*)
+ art_nr
+ shop_nr
+ preis

Shop:
+ shop_nr (*)
+ shop_name


Viele Grüße
Thomas

Re: Normalisierung einer DB

Thomas Krug wrote:

> Wie wär's mit:

> ShopArtikel:
> + id (*)
> + art_nr
> + shop_nr
> + preis

Ich tät' art_nr und shop_nr gleich zum Primärschlüssel zusammenfassen. Dann
hat man auch gleich sichergestellt, dass der gleiche Shop den selben Artikel
nicht laut Datenbank zu zwei verschiedenen Preisen verkaufen kann.

Re: Normalisierung einer DB

Markus Pfefferle schrieb:
> Thomas Krug wrote:
>
>> Wie wär's mit:
>
>> ShopArtikel:
>> + id (*)
>> + art_nr
>> + shop_nr
>> + preis
>
> Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
> zusammenfassen. Dann hat man auch gleich sichergestellt, dass der
> gleiche Shop den selben Artikel nicht laut Datenbank zu zwei
> verschiedenen Preisen verkaufen kann.

Das würde ich über die Anwendung prüfen, die Einträge würde ich nicht
zusammenfassen, auch wenn es technisch geht - man spart höchstens eine
Spalte in der Tabelle, bricht dadurch aber das DB-Design auf.

Viele Grüße
Thomas

Re: Normalisierung einer DB

Am Thu, 16 Feb 2006 21:06:50 +0100 schrieb Thomas Krug:

> Das würde ich über die Anwendung prüfen, die Einträge würde ich nicht
> zusammenfassen, auch wenn es technisch geht - man spart höchstens eine
> Spalte in der Tabelle, bricht dadurch aber das DB-Design auf.

Wieso etwas umständlich in der Anwendung prüfen lassen, wenn die DB einem
die Arbeit abnehmen kann? Selbst wenn man bei deinem Designvorschlag mit
der zusätzlichen ID als PK bleibt, kann man ART_NR und SHOP_NR problemlos
als UNIQUE definieren und sich so Ärger ersparen.

Gruß
Carsten

Re: Normalisierung einer DB

Thomas Krug schrieb:

>>> + id (*)
>>> + art_nr
>>> + shop_nr
>>> + preis
>> Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
>> zusammenfassen...
>
> ...man spart höchstens eine
> Spalte in der Tabelle, bricht dadurch aber das DB-Design auf.

Wieso? Das ist die normale Vorgehensweise bei einer n:m-Relation.

gruss, heli

Re: Normalisierung einer DB

Helmut Chang schrieb:
> Thomas Krug schrieb:
>
>>>> + id (*)
>>>> + art_nr
>>>> + shop_nr
>>>> + preis
>>> Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
>>> zusammenfassen...
>>
>> ...man spart höchstens eine
>> Spalte in der Tabelle, bricht dadurch aber das DB-Design auf.
>
> Wieso? Das ist die normale Vorgehensweise bei einer n:m-Relation.

Mehrere Spalten in einer zusammenzufassen, indem man Foreign Keys
zusammenwirft? Bäh, das mag ich nicht :-)
Technisch kann man's machen, aber schön ist es IMHO nicht.

Bei n:m ist die normale Vorgehensweise auf jeden Fall über eine
zusätzliche Tabelle, welche die n:m Relation (Artikel <->Shops)
handhabt, jepp.

Viele Grüße
Thomas

Re: Normalisierung einer DB

Carsten Heinrich schrieb:
> Am Thu, 16 Feb 2006 21:06:50 +0100 schrieb Thomas Krug:
>
>> Das würde ich über die Anwendung prüfen, die Einträge würde ich
>> nicht
>> zusammenfassen, auch wenn es technisch geht - man spart höchstens
>> eine Spalte in der Tabelle, bricht dadurch aber das DB-Design auf.
>
> Wieso etwas umständlich in der Anwendung prüfen lassen, wenn die DB
> einem die Arbeit abnehmen kann? [...] kann man
> ART_NR und SHOP_NR problemlos als UNIQUE definieren
> und sich so Ärger ersparen.


Kommt auf den Anwendungsfall an, ob das wirklich was bringt.
Beispiel: Ein Shopbetreiber legt mehrere gleiche Artikel, um die
Trefferchance auf seinen Shop zu erhöhen:
"Schickes TFT Display", Art.Nr.: 200
"Schickes TFT Display (viereckig)", Art.Nr.: 200a
"Schickes TFT Display (mit Strom!)", Art.Nr.: 200undeins

Wenn jetzt geprüft werden soll, ob dieser Artikel bereits von diesem
Shop angeboten wird, geht das natürlich nicht einfach über ein
UNIQUE - muss dann also anderweitig (gibt ja sicher mehrere Wege)
geprüft werden.

Wenn die Artikel vom Betreiber der Webseite angelegt werden (und eben
nicht von den Shop-Betreibern), dann könnte ein UNIQUE über artnr und
shopnr jedoch etliche Arbeit und Ärger abnehmen, da die DB gleich von
sich aus dafür sorgen kann, dass die Einträge passen -stimmt.

Viele Grüße
Thomas

Re: Normalisierung einer DB

Thomas Krug schrieb:
> Helmut Chang schrieb:
>> Thomas Krug schrieb:
>>
>>>>> + id (*)
>>>>> + art_nr
>>>>> + shop_nr
>>>>> + preis
>>>> Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
>>>> zusammenfassen...
>>
>> [...]
>
> Mehrere Spalten in einer zusammenzufassen[...]?
> Bäh, das mag ich nicht :-) [...]

Ähm... oder hab ich Dich falsch verstanden und Du meinst den
Primärschlüssel über die beiden Spalten gehen zu lassen?
Die beiden Spalten wären zusammen eindeutig. Gibt's weitere Vorteile?

Viele Grüße
Thomas

Re: Normalisierung einer DB

Thomas Krug schrieb:
> Thomas Krug schrieb:
>> Helmut Chang schrieb:
>>> Thomas Krug schrieb:
>>>
>>>>>> + id (*)
>>>>>> + art_nr
>>>>>> + shop_nr
>>>>>> + preis
>>>>> Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
>>>>> zusammenfassen...


Also nochmal drüber geschlafen ist

ShopArtikel:
+ art_nr (*)
+ shop_nr (*)
+ preis

wirklich schick. Ich hab bisher grundsätzlich eine id Spalte angelegt,
aber die ist dann ja hinfällig.

Danke für den Input/ Denkanstoss!

Viele Grüße
Thomas

Re: Normalisierung einer DB

Thomas Krug schrieb:
> Thomas Krug schrieb:
>=20
>>Helmut Chang schrieb:
>>
>>>Thomas Krug schrieb:
>>>
>>>
>>>>>>+ id (*)
>>>>>>+ art_nr
>>>>>>+ shop_nr
>>>>>>+ preis
>>>>>
>>>>>Ich tät' art_nr und shop_nr gleich zum Primärschlüssel
>>>>>zusammenfassen...
>>>
>>>[...]
>>
>>Mehrere Spalten in einer zusammenzufassen[...]?
>>Bäh, das mag ich nicht :-) [...]
>=20
>=20
> Ähm... oder hab ich Dich falsch verstanden und Du meinst den=20
> Primärschlüssel über die beiden Spalten gehen zu lassen?
> Die beiden Spalten wären zusammen eindeutig. Gibt's weitere Vorteile?=


Zusammengesetzer PRIMARY KEY über die beiden Fremdschlüssel, ja.
Bei einigen DB-Engines (etwa Oracle) kannst du dann die komplette=20
Datenbank als Index führen, was Plattenplatz spart (NUR Index, keine=20
Tabelle mehr).

Eine m:n Beziehung mehrfach vorkommen zu lassen macht nur dann Sinn,=20
wenn es weitere Attribute bei dieser Beziehung gibt, was aber, je nach=20
Anwendungsfall auch einfach bedeuten kann, dass man den PK weiter aufbohr=
t.

--=20
HTH,
Fabian

Re: Normalisierung einer DB

Thomas Krug schrieb:

> ShopArtikel:
> + art_nr (*)
> + shop_nr (*)
> + preis
>
> wirklich schick. Ich hab bisher grundsätzlich eine id Spalte angelegt,
> aber die ist dann ja hinfällig.
>
> Danke für den Input/ Denkanstoss!

Jepp. Eben genauso macht man das! ShopArtikel ist eine n:m-Auflösung von
Shop und Artikel. Dass die Tabelle zusätzliche Attribute hat, ändert
daran nichts.

gruss, heli

Re: Normalisierung einer DB

Thomas Krug wrote:
> Also nochmal drüber geschlafen ist
>
> ShopArtikel:
> + art_nr (*)
> + shop_nr (*)
> + preis
>
> wirklich schick. Ich hab bisher grundsätzlich eine id Spalte angelegt,
> aber die ist dann ja hinfällig.
>
> Danke für den Input/ Denkanstoss!

Bitte :)

Und auch nicht vergessen, die Spalte ´shop_nr´ nochmals eigenständig zu
indizieren, um sicher zu stellen, dass die Indizierung auch in beide
Abfragerichtungen wirkt (zumindestens unter MySQL)!

Re: Normalisierung einer DB

@all Danke für die Hilfe :-)

Ich hab die normalisierte Db jetzt in mysql eingetragen.
Gibt es eine vordefinierte Funktionen die von z.b 3 Werten die kleinste
ausgibt?
Oder wie kann ich dieses Problem lösen? Es müsste auch mit 5 Werten laufen.

z.B

50
20 (kleinste integer Zahl soll ausgegeben werden)
40


Gruß anikel

Re: Normalisierung einer DB

anikel schrieb:
> @all Danke für die Hilfe :-)
>=20
> Ich hab die normalisierte Db jetzt in mysql eingetragen.
> Gibt es eine vordefinierte Funktionen die von z.b 3 Werten die kleinste=

> ausgibt?
> Oder wie kann ich dieses Problem lösen? Es müsste auch mit 5 Werten=
laufen.
>=20
> z.B
>=20
> 50
> 20 (kleinste integer Zahl soll ausgegeben werden)
> 40


Es gibt zu MySQL nicht nur unzählige Tutorials, HowTos und=20
Erfahrungsberichte, sondern auch eine exzellente Dokumentation. Diese=20
findest du überlicherweise als Mitbringsel deiner Installation.=20
Weiterhin kannst du http://dev.mysql.com/doc/ besuchen und dort in der=20
für dich zutreffenden Dokumentation nach SELECT und MIN() suchen. Die=20
Seiten erklären dann die entsprechende Syntax.

--=20
HTH,
Fabian