Hallo Mel,

das ist schon richtig beschrieben
1:n = 1x in PRODUKTE und n-mal in WARENKORB

Gruß Rudolf

Hallo und vielen Dank für die Antwort.



Ja, ich bin eigentlich auch überzeugt, dass es eine 1:n Beziehung zwischen Produkt : Warenkorb ist.; ich hatte, mich in meinem letzten Beitrag nur verschrieben, denn der Autor sieht es wie folgt:

n:1. (Produkte:WArenkorb) und ich frage mich warum das?

-------------------------------------------

Ich fasse hier noch einmal meinen korrigierten Beitrag zusammen, und würde mich über eure Gedanken zum Thema sehr freuen:

...
PRODUKT
-produktnummer (primary key)
-bezeichnung
-preis


WARENKORB
-warenkorbnummer (primary key)
-produktnummer (foreign key)
- preiseinesartikels
-mengeeinesartikels



BESTELLTE PRODUKTE
-bestelldetailnummer (primary key)
-produktnummer (foreign key)
-preiseinesartikels
-mengeeinesartikels
-bestellnummer (foreign key)


BESTELLUNGEN
-bestellnummer (primary key)
-kundennummer (foreign key)
-gesamtbetragallerartikelplusversandkosten



Kannengiesser schreibt, dass die TABELLE WARENKORB MIT DER TABELLE BESTELLTE PRODUKTE nahezu identisch ist. Der einzige Unterschied ist, dass WARENKORB temporal ist und nach entgütliger Bestellung aufgelóest wird.


Die Beziehungen sieht Kannengiesser wie folgt:

Eine Bestellung besteht aus meheren bestellten Produkten:
BESTELLTE PRODUKTE : BESTELLUNGEN N:1


Bestellte Produkte werden aus Warenkorb übernommen:
WARENKORB : BESTELLTE PRODUKTE 1:1

Ein Warenkorb besteht aus Produkten, daher
PRODUKTE : WARENKORB = n:1


--> Hat der Autor sich hier mit der n:1Beziehung für (PRODUKTE:WARENKORB) geirrt?

Roland und ich meinen das es sich um eine 1:n Produkte Warenkorb handeln müsste, was meint ihr?

Vielen Dank für Eure Meinungen
Gruss Mel

moin

ich hab mich bei deinem ersten post schon gewuntert...

für mich ist

PRODUKTE : WARENKORB = n:1

richtig.

um das mal in die reale welt zu transportieren:

beim einkaufen hast du einen korb dabei, in den du n produkte packst. und nicht n körbe auf die du eine packung vanille-eis aufteilst...

g,
disco

Die Frage ist, ob es mehrere Warenkörbe gleichzeitig geben kann.
Dann hat man den Fall, dass mehrere Produkte in einem Warenkorb liegen können (wäre n Produkte : 1 Warenkorb); gleichzeitig können aber mehrere Leute in ihren Warenkörben das gleiche Produkt haben (wäre 1 Produkt : m Warenkörbe) --> ergibt für mich eine n:m-Beziehung.
mfg
Hendrik

solche streitfälle (wie hendrikw es beschreibt) , hatte ich früher an der uni auch.
im grunde kannst du aus fast jeder situation eine n:m beziehung machen oder 1 und n vertauschen, je nachdem wie du es betrachtest, oder argumentierst.

wenn du den warenkorn einer usersession betrachtest, hast du einen warenkorb, der n produkte enthält.

betrachstest du die relationen zwischen warenkorb und prdoukt, dann hast du n produkte, die m warenkörben zugeordnet sind.

betrachtest du nur das produkt, ist ein produkt n warenkörben zugeordnet.

leider kann ich dir nicht sagen aus welchem blickwinkel du schauen musst

Für mich ist in diesem Beispiel die Tabelle WARENKORB Unsinn.
So wie die hier konstruiert ist, könnte man pro Warenkorb(nummer) nur ein einziges Produkt ablegen.
Hier bräuchte man eine Detailtabelle analog BESTELLTE PRODUKTE.
Dann hätte man eine saubere n:m-Beziehung.
mfg
Hendrik

@hendrikw

stimmt. die tabelle hat als primary-key nur die eigene ID, aber trotzdem eine ID fürs produkt. das heisst, dass man dem warenkorb nach diesem schema kein 2tes produkt zuordnen kann.

die relation von produkt -> (bestellung -> kunde) muss von einer tabelle ( hier: BESTELLTE PRODUKTE) hergestellt werden, die als prim. key eine fortlaufende nummer hat und durch for.keys eine relation von n produkten zu einer bestellung zusammenfast.
natürlich könnte man es auch wieder so sehen, dass in diese tabelle n produkte m bestellungen zuordnet ...

also so:
BESTELLTE PRODUKTE
-id (auto inc) (primary key)
-produktnummer (foreign key)
-mengeeinesartikels
-bestellnummer (foreign key)

der preis des artikels gehört da ebenfalls nicht rein.
der muss in der produkt-tabelle stehen.

ach so.
es könnte doch sinnvoll sein den preis in BESTELLTE PRODUKTE zu packen. da sich die preise nach der bestellung ändern könnten, aber diese änderung natürlich nicht für bestellungen gelten kann, die vorher erfolgt sind.

Wie wärs mit folgenden Tabellen?


PRODUKT
-produktnummer (primary key)
-bezeichnung
-preis


WARENKORB
-warenkorbnummer (primary key)
-kundennummer (foreign key)


WARENKORB_PRODUKT
-produktnummer (foreign key)
-warenkorbnummer (foreign key)
-preis
-menge
-status (offen, bezahlt, geliefert)


KUNDE
-kundennummer (primary key)
-name
-anschrift
-versandkosten
-zahlungsart


KUNDE_WARENKORB
-warenkorbnummer (foreign key)
-kundennummer (foreign key)



Hintergrundidee:

1 Kunde kann 0 oder n Warenkörbe haben (dazu sucht man in KUNDE_WARENKORB einfach alle Datensätze mit der Kundennummer).

1 Warenkorb gehört immer genau einem Kunden - und zwar immer. Vom ersten Moment, über den Status der Bezahlung bis nach der Lieferung. Vorteil hier ist die auch in der Zukunft stets nachvollziehbare Rechnung und der jeweilige Korbinhalt, auch wenn sich Preise ändern.

1 Warenkorb kann n Produkte beinhalten (jedoch nicht 0, dann bräuchten wir keinen Warenkorb).

1 Produkt hingegen kann jedoch in 0 bis n Warenkörben drin vorkommen.


Kurz gesagt:

Produkte 1-n : Warenkörbe 0-n
Warenkörbe 0-n : Kunden 1

Erst einmal vielen vielen Dank für die vielen Anregungen.
Ich versuche jetzt erst einmal alles in Ruhe nachzuvollziehen...
bis gleich

Also:

Dem Argument von Hendrik stime ich vollkommen zu.


Auch die ErLäuterung von user "son_quatsch" finde ich sehr einleuchtend:


Vielen Dank für die super Darstellung.
Ich habs dann jetzt wie foglt verstanden:
Je nach Sichtwinkel sehen die Beziehungen dann wohl anders aus, wobei eine n:m Beziehung wohl in diesem Fall das Korrekteste ist, sobald es sich nicht nur um mehrere Produkte sondern auch um mehrere Warenkörbe handelt.

Eines ist mir dennoch noch unklar: (Beiträge von Hendrik und "Disco")


Ich glaub, dass in diesem Zusammenhang der Autor Kannengiesser den Begriff "WARENKORB" und "Warenkorb_id") irreführend eingesetzt hat . Es soll ja eigentlich nur ein temporales Spiegelabbild von BESTELLTE PRODUKTE sein. Ganz wie Du schon schreibst.


---------------------------------------------
Also, alles in allem zusammengefasst:

Wenn man nun mal von Folgendem ausgeht:
-der "WARENKORB" ist ein Abbild von BESTELLTE PRODUKTE, daher nenne ich das jetzt mal BESTELLTE_PRODUKTE_TEMP
-es sind mehrere "Warenkörbe" zur gleichen Zeit erlaubt
-jede einzelne Bestellung eines Produktes eines Warenkorbs hat eine id und anhand der Session kann festgestellt werden, welche Bestellungen zu einem Warenkorb gehören,

dann könnte man doch folgendes ER-Modell aufstellen oder?:

PRODUKT
-produktnummer (primary key)
-bezeichnung
-preis


BESTELLTE_PRODUKTE_TEMP
-bestelldetailnummer_temp (primary key)
-produktnummer (foreign key)
-mengeeinesartikels
-sessionnummer


BESTELLTE PRODUKTE
-bestelldetailnummer (primary key)
-produktnummer (foreign key)
-mengeeinesartikels
-bestellnummer (foreign key)


BESTELLUNGEN
-bestellnummer (primary key)
-kundennummer (foreign key)
-gesamtbetragallerartikelplusversandkosten

Meine Fragen:
--> Wie wäre dann die Beziehung von PRODUKT : BESTELLTE_PRODUKTE_TMP ?
Ist es notwendig oder falsch, dass bestelldetailnummer von BESTELLTE PRODUKTE ein primary key ist?

Bin mächtig gespannt auf Eure Antworten und hoffe, dass ich mit diesem Thema nicht allzusehr auf den Senkel falle ;-)
Bis gleich

Mel

moin


kommt wieder auf deine sichtweise an.

betrachtest du nur eine session: n:1
alles sessions n:m
aus sicht des produktes 1:n

ich hätte in einer klausur n:1 hingeschrieben ...



jain :-)
der einzig notwendige eindeutige primärschlüssel ist die vereinigung von produkt und bestellnummer. da beide nummern eindeutig sind, ist ihre vereinigung auch eindeutig. aber auch nur weil für die menge eine eigne spalte existiert.

würde die mengenangabe nicht vorhanden sein, müsste es auf jedenfall eine weitere ID (auto inc) geben, da dann die menge des produkts pro bestellung über die anzahl der gleichen einträge ausgedrückt würde.

@disco:
Super vielen Dank für die Antwort am frühen Morgen.
Das hilft mir schon sehr weiter und ich werd dann mal ein wenig weitertüfteln ....

Danke Dir und wünsche Dir noch einen sonnigen Tag
Gruss Mel

@mel

gehts dir ums verstehen oder machst du etwas praktisches?
wenns etwas praktisches ist, gib es sicher andere (bessere) möglichkeiten fürs DB-Schema.

@disco:

Dank Dir fürs Nachfragen. Mir gehts sowohl ums Verstehen als auch ums Praktische.

Aber klar, ich versuch in der Tat eine funktionstüchtige Datenbank aufzustellen.
Im Internet habe ich bisher nicht viele Datenbankschemen, Er-Modelle bzgl. Online-shops entdeckt.




Kannst Du mir vielleicht sagen, auf welche Quelle Du Dich beziehst?

Vielen Dank vorab
gruss Mel

@mel

ich kann dir leider keine literatur nennen, da ich da schon etwas raus bin und dir nur eine betrachtung von der praktischen seite geben.

du solltest dir zum beispiel nochmal gedanken zur tabelle BESTELLTE_PRODUKTE_TEMP machen.



eigentlich braucht man die nicht (1), bzw. wenn man sie braucht, kann sie so nicht funktionieren (2).

1) damit möchte ich sagen, warum sollten dieser warenkorb in der datenbank gestellt werden? es ist ja nur ein temporäres gebilde und kann einfach in der session gehalten werden. es sollte ja reichen die DB zu richtigen bestellvorgang zu füttern.

2) anderers sieht es aus, wenn man den warenkorb des potentiellen käufers später wieder herstellen will (nach ablauf der session). dann muss der user aber jedes mal identifiziert werden können (cookies, user login). dann brächtest du diese tabelle. dafür fehlt ihr aber momentan so eine spalte wie userid oder cookieid...

und das diese tabelle momentan sowieso überhaupt keinen sinn macht, siehst du an der spalte sessionnummer.
eine sessionid wird jedes mal neu vergeben. d.h. wenn der kunde die session verliert, sind die einträge in der tabelle nicht mehr zu finden. somit macht es keinen sinn diese tabelle überhaupt zu füttern, da dann der warenkorb auch direkt in der session gespeichert werden kann.

g,
disco

Also, erst einmal guten Morgen und tausend Dank an "disco" für seinen letzten Beitrag. du weisst ja gar nicht, wie mir das momentan weiterhilft. Dank Dir deshalb erst einmal .


disco:

Das ist ja schon mehr als genug, denn darüber freu ich mich total. Aus praktischer Sicht gesehen und erklärt, hilft mir viel mehr als die Theorie der Bücher. Aus einem der schlauen Bücher habe ich nämlich auch die Idee des temporalen Warenkorbs.



Ja, stimmt. Absolut einleuchtend und verständlich. So einen Denkansatz hatte ich auch schon, aber ich hab ihn verschmissen, weil in einem der "schlauen" Büchlein dieser Ansatz vorgeschlagen wurde.

Ich werd Deinem Vorschlag folgen und dann die Aktionen des potentiellen Kunden wáhrend des Einkaufs in ner Session speichern und bei tatsächlicher Buchung dann in die Tabellen "BESTELLTE PRODUKTE" und " BESTELLUNGEN" usw. eintragen. So wäre es dann wohl am sinnvollsten oder?

Ich werde noch mal in dem Buch, in dem die temporale Tabelle vorgeschlagen wurde nachlesen, mit welcher Begründung sie diese vorschlagen und meld mich dann zurück.

Gruss und viiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiielen Dank @Disco

Mel

gern geschehen



wie gesagt. kommt drauf an wieviel aufwand du betreiben willst. der nachteil ist dann hier, dass wenn die session verloren geht der warenkorb weg ist. dafür muss der kunde ja nur mal ne halbe stunde aufs klo.
aus nutzersicht würd ich aber sagen, dass sehr viele shops den warenkorb "vergessen".
aber da du was lernen willst, kannst du dein projekt ja schritt für schritt erweitern...

Wie versprochen schreib ich hier noch einmal den Hintergrund, warum das "Buch" (Beginning PHP5, Apache, and MySQL Web Development (Programmer to Programmer von Naramore etc.) mit einer temp. Tabelle arbeitet:

Die temporale Tabelle soll die Daten speichern, während der Kunde einkauft und bevor er zur Kasse geht. Die restlichen Tabellen sollen noch nicht "gefüttert" werden für den Fall, dass der Kunde abbricht, denn sonst hätten wir Bestellungsnummern für eine Bestellung, die nie aufgegeben wurde, was nicht nur schlecht für die Buchhaltung wäre ;-)

Und warum nun die temporale TAbelle? Die Autoren schreiben: Die Sessionnummer soll die eingekauften Produkte zusammenhalten. Anhand der bestelldetailnummer_temp kann man dann einen einzelnen Artikel löschen oder anhand der sessionnr die gesamte Bestellung.

Mehr Begründung liefern sie nicht. Aber ich denke folgendes:
Wenn man alles nur in einer Session speichert, wie kann man dann z.B. sagen, "lösche mir alle Daten, wo Produktnummer = 1" ? Es muss ja ne Möglichkeit geben, dass der Kunden die Menge ändern kann oder seine Produktauswahl ändert usw.
Um die Daten dann noch eindeutig zuordnen zu können, müsste man da wohl mit arrays arbeiten oder?
Mit einer Session, und ohne Datenbanktabelle, wird es dann doch etwas aufwendiger mit der Programation oder nicht?

Kannengiesser spricht in seinem Buch auch von einer temporalen Tabelle. Wenn man an die typische Seite eines Onlineshops denkt, in der der Kunde ide Möglichkeit hat, die Anzahl eines eingekauften Produkts zu erhöhen oder es sogar aus dem Warenkorb zu streichen, dann steckt da sicherlich eine temporale Tabelle dahinter oder ? Mit Session wüsste ich momentan nicht, wie man dann die einzelne Daten zusammenhalten sollte. Mit Array wahrscheinlich.

Freu mich schon auf Antworten

Bis gleich
Mel

Ach ja, um auf Punkt 2 von disco zu antworten:



Die Session sollte bereits bei der Eintragung in "BESTELLUNGEN" wieder aus der temporalen Tabelle geloescht werden. Es sollen also nicht die "möglichen, abgebrochenen" Buchungen wieder hergestellt werden.

Gruss Mel