Supportnet / Forum / Datenbanken

Hallo, vielleicht kennt der eine oder andere die Bücher vom Fachautor Matthias Kannengiesser. Nein, ich will hier keine Werbung machen, sondern ich werd aus einem seiner ER-Modelle für einen Onlineshop nicht ganz schlau. Ich hab mal das entsprechende Modell auf die 4 wesentlichen Tabellen reduziert: 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 Waren werden aus Warenkorb übernommen: WARENKORB : BESTELLTE PRODUKTE 1:1 Ein Warenkorb besteht aus mehreren Produkten, daher PRODUKTE : WARENKORB 1:N Meine Frage bezieht sich auf das letzte Verhältnis: Warum ist das Verhältnis von PRODUKTE zu WARENKORB 1:N? Jedes Produkt kann doch mehrmals als bestelltes Produkt vorkommen, und es wäre eine N:1 Beziehung, oder nicht? --> Hat der Autor sich hier mit der 1:n Beziehung geirrt? Vielen Dank für Eure Ideen im voraus Gruss Mel

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

also mit php kann ich dir nich viel helfen, aber normalerweise hast du ja sowieso ein objekt, das die jeweilige DB-tabelle abbildet.

vereinfacht:

Objekt: BESTELLTE_PRODUKTE_TEMP
{
String produktnummer;
int mengeeinesartikels;
...
}

Für jedes Produkt (produktnummer), das in den warenkorb gelegt werden soll, erzeugst du eine neue instanz des objekts und packst es in ein arrayähnliches gebilde (je nach dem was es da so in php gibt). in java würd ich vielleicht ne hashtable mit der produknummer als key nehmen...


mit tabelle ist es aufwändiger weil du ja noch DB-arbeiten zwischendurch hast.



nein. du kannst die angabe ja genau so gut im session-objekt ändern, bzw. das objekt löschen.

jupp, so werd ich´s dann mal mit der Session probieren.

vielen vielen Dank, dank Deiner Hilfe beginnt die Woche hervorragend!

Bis bald
Mel

Hi Mel,

ich weiss ja nicht wofür du das machst, ob das ein echter Shop werden soll oder "nur" ein Übungsobjekt ist.

Meiner Meinung nach sollte man aber den temporären Warenkorb von Kunden speichern und per Cookie wiederauffindbar machen.

Wie oft habe ich mich schon geärgert, wenn ich mal ne halbe Stunde abgelenkt war und ich dann den ganzen Kram neu suchen oder eingeben musste.

Ist doch nett wenn der Shop sich die Daten merkt und per Cookie meine Angaben immer wieder selber schon einfügt. Gerade bei Shops geht es um den Kundennutzen und wenn der schon beim Onlinekauf verärgert wird weil er Daten zwei mal eingeben muss...

Oder man hat abends seine Waren gesucht wurde abgelenkt (durch Schlaf evtl ;-) und morgens kann man trotzdem noch weiter einkaufen wie schön.

Gruß Fabian

@Fabian.

Vielen , vielen herzlichen Dank für die Antwort und sorry für mein verspätetes Feedback.



Ich würde gern einen echten Shop basteln. Obwohl leider nicht alles geht wie man möchte, würde ich doch gern die reale Seite eines Onlineshops (ferner der Büchertheorie) kennenlernen...


Ja, inzwischen hab ich mich auch dafür entschieden. Ein Cookie ja, aber aus Sicherheitsgründen ist es besser, wenn der Cookie nach ner halben Stunde nicht merh gueltig ist (normale einstellungen eines sessioncookies soweit ich weiss). Wenn Deine "Sessionverbindung" die ganze nacht über aktiv bleiben soll, gábe es doch das Risiko, dass jemand Deine Session übernimmt, oder nicht?

Oder beziehst Du Dich auf ein "normales "Cokie, das Deine Einkaufsdaten speichern soll?

Bis danni und vielen Dank noch einmal für den Beitrag
Mel

Hi Mel,

ja das Risiko bestünde, daher würde ich es auch nicht in einer Session oder einem Sessioncookie speichern sondern den Warenkorb und die Angaben des Usern in der Datenbank speichern und ihm ein Cookie setzen über das man ihn wieder identifizieren kann wenn er nach Ablauf der Session in ein paar Tagen x oder Stunden y wieder vorbei schaut.

Wie gesagt es gibt meiner Meinung nach nichts ärgerliches wie dieser dämliche Satz: "Ihre Session ist abgelaufen, begeben Sie sich auf die Sartseite und machen sich die ganze Mühe noch einmal..."

Der Benutzer weiss doch gar nicht was eine Session ist und er versteht auch nicht warum die abläuft, er will nur bequem etwas kaufen.

Gruß Fabian

Hi "halfstone"



Ja, das ist wohl war. Der Normalkunde wird entweder Cookie aktivieren oder deaktivieren, und wahrscheinlich nicht darauf achten, ob es sich um ein Sessioncookie handelt oder nicht.



--> Würdest Du dann ganz ohne Session arbeiten, richtig?
--> Aber was ist, wenn der Kunde in einem Internetcafe sitzt und die Bestellung nicht beendet und der nächste user mit seinem Cookie locker weiter bestellt?

Ein weiterer Aspekt, der mir einfällt,ist, dass Du, wenn Du wirklich ALLE eingegebenen Daten vom Kunden temporal in der DB speichern willst ist (anstelle in der Session), dass Du die Tabelle ziemlich oft aufrufen musst, um Daten zu ändern, einzufügen, usw. (Ich denke da nur an Anschrift, Versandart. Bezahlungsform, usw.) Das könnte, glaube ich, nicht nur das Sicherheitsrisiko erhöhen sondern auch mehr Zeit zum Laden der Seite benötigen und bedeutet zudem einen zusätzlichen Programmieraufwand, denn da sind ja dann einige zusätzliche temporale Tabellen fällig, oder nicht?

Bin gespannt auf Deine Antwort
Einen angenehmen Nachmittag
Gruss Mel

Hi Mel,

also ich würde sicherheitsrelevante Daten, also solche mit denen ein anderer Benutzer am gleichen PC (Internetcafe) Unfug machen könnte, nicht temporär speichern.

Aber der Warenkorb ist meiner Meinung nach unkritisch, außer du machst einen Shop für Schweinkram ;-)

Sobald es an die Bestellung geht würde ich es über eine Session oder Sessioncookie machen, da diese Angaben ja auch personenbezogene Daten sind.

Aber bis dahin würde ich alles temporär speichern, also den Warenkorb.

Von der Performance her sollte das jede übliche DB (denke mal es handelt sich um mysql) locker aushalten. Da man nicht davon ausgehen wird, dass zigtausend Kunden Warenkörbe füllen aber nicht bestellen und man die Daten ja nach x Tagen sowieso löscht sollte das keine große Rolle spielen.

Aber ich bin selber kein Programmierer insofern können dir da andere User sicher besser helfen.

Gruß Fabian

@Fabian,

vielen Dank für Deine Tipps. Ich werde mal alle Möglichkeiten ausprobieren:

Mit Warenkorb temporär speichern oder gleich alles in Session usw.

Es scheint, als wenn man einen Warenkorb auf hunderte von verschiedenen Arten programmieren kann, nicht wahr?

Na, ich versuch mich dann zumindestens mal an den zwei o.g. Varianten und meld mich dann wieder.

Einen schönen Abend noch udn vielen vielen Dank für die vielen Mitteilungen

Gruss Mel

• Löschen der "1"-Seite einer 1:n Beziehung
• Kann man eine über Internet versendete sms zurückverfolgen??????
• Google + Lego
• änderung in tabelle
• Suchen im Hauptformular + Unterformular