1. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

Frage zu ERD und NF

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von sqlnewb1253, 21 März 2019.

  1. sqlnewb1253

    sqlnewb1253 Neuer Benutzer

    Hallo zusammen,

    ich hoffe ich schreibe hier im richtigen Forum ( habe eine MySQL DB).

    Möchte gleich betonen ich frage selbstverständlich NICHT nach kompletten Antworten, mir wären ein paar Tipps und Hinweise am liebsten damit ich mich in die richtige Richtung bewegen kann.

    da ich gerade dabei bin SQL zu lernen (als Abwechslung zum "Systemadministratordasein"), dachte ich mir ich probier mal ein kleines Bestellsystem zu erstellen..
    Mir ist bewusst dass die Datentypen, Namenskonventionen etc.. noch nicht i. O sind, mir geht es im Prinzip darum ob ich die Sache mit den Beziehungen und NFs richtig habe.

    Mein Gedankengang:

    Ein Produkt kann mehrere Kategorien haben aber eine Kategorie auch mehrere Produkte, somit eine Jointable und 1:m Beziehung von Kategorie und Produkt auf jene Jointable

    Eine Bestellung kann mehrere Produkte haben, aber nur eine Bestellungsnummer somit wieder das gleiche wie bei Kategorie und Produkt.

    Ein Benutzer kann mehrere Bestellungen haben, somit 1:n auf tblBestellung

    ERD.png


    Wenn das richtig ist, dann vermute ich werde ich noch die CONSTRAINTS anpassen muessen oder macht das die workbench bereits richtig?
    Damit das ganze dann auch bedienbar ist habe ich vor ein Interface in PHP zu schreiben. --> Da ist dann CRUD angesagt - richtig? Dann wäre es aber auch nicht verkehrt wenn ich eine tbl fuer einen Warenkorb anlege und diese dann irgendwie mit tblJoinBestellungBenutzer verknüpfe?
    Gibt es eine internationale Richtlinie für die Benennung von Tabellen, Schlüsseln und sonstigem?
     
  2. akretschmer

    akretschmer Datenbank-Guru

    deine Kategorien sind Murks. Was machst Du, wenn später nach alkoholische / nichtalkoholische Getränke werden soll? Oder Produkte, wenn Dinge nach Stückzahl gehandelt werden? Und was ist 5 für ein Geschlecht?
     
    sqlnewb1253 gefällt das.
  3. sqlnewb1253

    sqlnewb1253 Neuer Benutzer

    Hallo akretschmer,
    erstmal danke für die Antwort,
    KATEGORIEN: ich hätte mir gedacht ich füge mit einem INSERT dann die Unterkategorien ein ( https://www.kern.bayern.de/mam/cms03/wissenschaft/dateien/lebensmittelkategorien.pdf ) und wähle sie dann per Formular auf HP aus?
    GESCHLECHT: TINYCHAR(1) hätte ich gedacht wegen 0=W 1=M 2=X --> wäre eine bessere Lösung des Problem mit dem Geschlecht via char(1) (m, f, x ) gegeben
    STÜCKZAHL: wäre es eine Möglichkeit in der Join Table eine Col. einzufuegen (z.B stueckzahl) und diese dann durch das Formular auf der Homepage einzutragen?
     
  4. Walter

    Walter Administrator Mitarbeiter

    Dafür gibt es eigene Datentypen wie z.B. enum, die verhindern z.B. dass ungültige Werte in der Datenbank landen.
     
    sqlnewb1253 gefällt das.
  5. castorp

    castorp Datenbank-Guru

    Naja, enums sind letztlich eine Form der De-Normalisierung (und sind auch nicht Teil des SQL Standards)

    Eine (akademisch) korrekte Lösung wäre ein gender Tabelle mit einem Foreign Key von der Benutzer Tabelle zur Gender Tabelle.
    Oder ein CHECK CONSTRAINT auf die Spalte "Geschlecht".

    @sqlnewb1253
    Präfixe wie "tbl" sind vollkommen überflüssig und häufig eher hinderlich als hilfreich. Natürlich ist das auch eine Geschmacksfrage, aber ich würde Dir empfehlen diesen Präfix ganz wegzulassen.

    Du kannst Dir ja mal die Antworten zu diesem Thema hier durchlesen: Is adding the ‘tbl’ prefix to table names really a problem?
     
    sqlnewb1253 gefällt das.
  6. Dukel

    Dukel Datenbank-Guru

    Nicht die Spalten mit den Zeilen verwechseln.
    Deine Spalten (Obst, Getränke, Teigwaren,...) sollten Werte der Kategorien sein und keine Spalten.
    Was trägst du z.B. bei einem "Apfel" ein?
    Eigendlich reicht eine Spalte (Kategorie) und ggf. eine Hirachiespalte (Oberkategorie)

    ID|Kategorie|Oberkategorie
    -----------------------------
    1|Obst|
    2|Apfel|1
    3|Getränke|
    4|Bier|3
    5|Wein|3
     
    sqlnewb1253 und castorp gefällt das.
  7. sqlnewb1253

    sqlnewb1253 Neuer Benutzer

    Erstmal danke an alle für die raschen Antworten


    Hab´s mal angepasst - müsste so hinhauen oder?
    Danke, angepasst.



    ______________


    Was mir noch ein wenig Kopfzerbrechen bereitet ist

    1) die Sache mit der Stückzahl in der Bestellung, habe in der JoinTable einfach mal stückzahl reingeschrieben (werd´s noch auf INT anpassen) - aber das kommt mir fast zu einfach vor als dass es funktionieren wuerde..

    2) Das Handling mit den Fotos, einfacher wäre es vmtl. als blob und foto reinladen
    bessere lösung ist wahrscheinlich einfach eine referenz zum pfad des fotos?

    EDIT1: Dass die Datentypen noch angepasst werden muessen ist mir bewusst - bin gerade dabei.



    ERD.png
     
  8. ukulele

    ukulele Datenbank-Guru

    Zu den Fotos (Dateien in der DB):
    Kann man machen, die meisten machen es von der Dateigröße abhängig. Kleine Bilder / Icons ist okay aber wenn es sehr viele Daten werden möchte man sie meiste eher auf dem Dateisystem ablegen. Hier zählt aber auch, was ist eigentlich schneller? Wie gut kann die gewählte DB damit umgehen und wie gut kann die Homepage was laden?

    Bestellungen:
    Ich würde die Tabelle JoinBestellungBenutzer nicht so nennen, das trifft eigentlich nicht zu, der Benutzer ist hier nicht direkt verknüpft. Abgesehen davon würde ich den Begriff Join nicht im Tabellennamen verwenden. Ich würde das eher als Bestellpositionen bezeichnen.

    Geschlecht:
    Das in eine Tabelle auszulagern ist natürlich BilderbuchDB aber total umständlich. Niemand will wirklich mehr Speicherplatz nutzen und längere Querys um hier noch mit Fremdschlüsseln zu arbeiten. Wenn du wirklich mit Kunden eines dritten Geschlechts rechnest musst du dir schon gut überlegen ob du diese (nach DSGVO besonders schützenwerte) Information überhaupt speichern willst. Eine Anrede umgeht das datenschutztechnisch eleganter.
     
    Walter gefällt das.

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden