Sql – Entity Relationship Diagram Sales

databaseentity-relationshiperdrelational-databasesql

I wanted to ask your opinion on the following ERD diagram i made. Keep in mind that i haven't already represented the cardinality of the relations yet.

What i'm going for is:

  • A client goes in to buy a car;
  • The car can be upgraded with many extras which add up to the base price of the car;
  • The salesman can offer extras at no cost or offer a discount on the sale's total price in order to captivate clients;

What do you think of my diagram? Is it right? Do you see anything wrong?

[EDIT]

How do i go about representing the following scenario. A customer sells me a used car as a part of a purchase of a new car.

Best Answer

Whether your model is right or not depends on whether your model can capture all the business scenarios you described above - and IMHO, your model does that quite well (Congratulation!); barring few small anomalies such as, not having the Discount attribute in Order entity to capture overall discount on sales (which is a possible business scenario).

But when you create model like this, you should consider the final purpose of this model:

  • Is it for capturing transactional data (OLTP)?
  • Is it for storing data for reporting purpose (OLAP)

In your case, I believe your final goal is to capture business transactions by designing on Online Transaction Processing (OLTP) system. OLTP models are generally normalised in nature (due to the obvious benefits of normalisation such as reduced redundancy, update/ delete anomaly prevention etc.) Your model is mostly in 3NF form, except for few transitive dependencies. The column SalesTotal in entity Order appears to be a derivable column (based on Price and Discount which you have already stored in other entities) and, IMO, need not be separately maintained (read redundant).

Also based on your comment above,

extra's change price at any given point. Bu i should be ale to break down the sale enough to see the original price of stuff at that date

I don't think you will be able to do it because your Extra entity is designed to store the current Price always. Your OrderDeatils contain the relationship between Car and Extra for any given point in time. If the prices of car and extra changes later, you will lose the old value as you will update the old price with new price. Hence, although you will be able to track the ID_Car and ID_Extra from OrderDetails, you won't know what were their historical prices during the time of order creation.

If you want to store historical prices, consider adding one more table each with Car and Extra to store past prices against dates.

client can act as a seller

In the situation when a client can act as a seller, the person will exist independently in both your Client and Salesman table... That's perfectly alright (Such design technique is called Vertical Separation).

Alternatively, if you really need a 3NF model, then you should create a new entity - Person containing attributes such as name, id etc. This Person entity will be used to store both your client and salesman details as technically both of them are some person, but their "role" is different. Once you have this Person entity, you can delete SalesMan and Client entities. Then in the Order entity, you already have a Clent ID and a Salesman ID attribute to define the relationship between two different persons (These Clent ID and Salesman ID will be Foreign Key to the Person ID in Person entity). Whether a person is playing the role of a salesman or a client can be known from Order entity.

Hope this helps

Related Topic