ER Modell für Entitäten, die nicht in DB gespeichert sind, und Benutzerauswahl

Question

Ich versuche, ein ER-Diagramm eines einfachen Datenbankmodells für Einzelhandelsketten zu erstellen. Sie haben Ihren Kunden, die verschiedenen Geschäfte, Inventar usw.

Meine erste Frage ist, wie man einen Kunden darstellt, der eine Bestellung in einem Geschäft aufgibt. Wenn der Kunde ein Rabattkarteninhaber ist, hat das Unternehmen seinen Namen, seine Adresse usw., sodass ich eine cardHolder-Entität mit einem Artikel verbinden und mit einer Bestellbeziehung speichern kann. Aber wie stelle ich eine Bestellung dar, die von einem Kunden aufgegeben wird, der nicht wirklich eine Entität in der Datenbank ist?

Zweitens, wie sind bedingte ... Zeug in ER-Diagramme, z. In einem Autohaus kann ein Kunde ein oder mehrere optionale Extras wählen, wenn er ein Auto kauft. Ich würde denken, dass es eine Car-Entity mit den relevanten Attributen und den Optionen als ein mehrwertiges Attribut gibt, aber wie stellen Sie einen Benutzer dar, der diese Optionen auswählt (die Auftragstabelle zeigt das bestellte Auto, ausgewählte Extras und die zusätzlichen Kosten von Extras)) in der Reihenfolge Beziehung?

Answer 1

Erstens, müssen Sie wirklich Kunden als separate Entitäten modellieren, oder benötigen Sie nur Bestell-, Zahlungs- und Lieferdetails? Viele Einzelhandelssysteme verfolgen keine individuellen Kunden. Bei Bedarf können Sie eine Kundentabelle mit einem Ersatzschlüssel und eindeutigen Einschränkungen für die Identifizierung von Attributen wie SSN oder Rabattkartennummer haben (auch wenn diese Attribute optional sind). Es ist im Allgemeinen schwierig, eine Duplizierung in Kundentabellen zu verhindern, da es keinen idealen natürlichen Schlüssel für Menschen gibt. Überlegen Sie also, ob dies wirklich erforderlich ist.

Wie Sie optionale Extras modellieren, hängt davon ab, wovon sie abhängen. Einige Extras könnten make oder modellspezifisch sein, z. die Wahl bestimmter Farben oder manuelle/automatische Übertragung. Erweiterte Garantien können auf der ganzen Linie verfügbar sein.

Hier ist ein Beispiel für fahrzeugspezifische Sonderausstattungen:

car (car_id PK, make, model, color, vin, price, ...) 
car_extras (extra_id PK, car_id FK, option_name, price) 
order (order_id PK, date_time, car_id FK, customer_id FK, payment_id FK, discount) 
order_extras (order_id PK/FK, car_id FK, extra_id PK/FK) 

I Preis Summen ausgeschlossen, da können diejenigen, die über aggregierte Abfragen berechnet werden.

In meinem Beispiel order_extras.car_id sind redundant, sondern unterstützt eine bessere Integrität über die Verwendung von Verbund Constraints FK (dh (order_id, car_id) Referenzen der entsprechenden Spalten in order und (car_id, extra_id) Referenzen die entsprechenden Spalten in car_optional_extras ungültige Extras zu verhindern, um einen verknüpft ist Auftrag).

Hier ist ein ER-Diagramm für den obigen Tabellen:

Answer 2

Zuerst wird, wie pro Ihre Gedanken Sie auf jeden Fall zwei Arten von Kunden haben. Discount-Karteninhaber, deren Details bei der Firma vorhanden sind, und neue Kunden, deren Details nicht bei der Firma verfügbar sind.

Es gibt drei Möglichkeiten, um zu erreichen, was Sie versuchen, 1) haben zwei verschiedene Ordnungstabelle im System (was ich persönlich würde nicht vorschlagen) 2) eine einzelne Order-Tabelle im System und bekommen die Details von denen, die ein Rabattkarteninhaber sind. 3) Fügen Sie für neue/nicht registrierte Kunden mit nur einer Auftragstabelle im System eine Zeile in die Rabattkarten-Halterungsliste ein.

Mit einer einzigen Auftragstabelle würde das System standardisiert und wäre bequemer während der Durchführung vieler anderer Operationen.

Zweitens, um Ihre Bedenken zu lösen, müssen Sie die Normalisierung folgen. Es reduziert das aktuelle Problem und macht das System überflüssig und macht die Entitäten leicht, was sich direkt auf die Leistung auswirkt, wenn Sie groß werden.

Die extra ausgewählten Artikel können in der Bestellung gegen den Kunden aufgeführt werden, indem sie zum Zeitpunkt der Erstellung einer Rechnung mit Fremdschlüssel hinzugefügt werden. Der Umgang mit Schlüsseln führt zu schnellen und robusten Ergebnissen anstatt redundante/sich wiederholende Details an verschiedenen Stellen zu speichern.

Nach der Normalisierung kann das Problem dadurch behoben werden, dass Fremdschlüssel überall dort angewendet werden, wo Sie auf Daten verweisen möchten, um Probleme oder Fehler zu vermeiden.

Vorzugsweise wäre NF 4 besser. Sehen Sie sich den folgenden Link an, um mit der Normalisierung zu beginnen.

http://www.w3schools.in/dbms/database-normalization/