ER 图，物理数据 Model 关系

Question

I am trying to create a very simple database Supermarket management system. And it seems that I am having a problem with how relations work between entities, I am using PowerDesigner to create the ERD and then generate everything from it(LDM, PDM, OOM). Is this a bad idea?.

Now for my main problem It's between these 3 tables:

1. Employee(Cashier)
2. Customer
3. Orders(Receipt).

The way I did it is:
The customer gather the products he wants to buy and present it to the employee, then the employee gets the order for the customer from the machine, so:

1. There is a relation between the Customer and the Employee (Many to Many): each customer can request_order from one or more Employee and each Employee can get_order to one or more Customer.
2. There is a relation between the Employee and the Orders (1 To Many): each Employee can get one or more orders, each order is fetched by one employee. The problem is if I want to know the customer related to that specific order......I can't. How do I fix this? How can I get the specific order that customer made. I am still very new to this, so sorry for any obvious mistakes.

Answer 1

I am sticking to the Relational Database context, that you have tagged.

Data Modelling is an iterative process. There is a lot more definition that is needed, before the data model can be complete. Rather than answering the specifics that you request, which would be limited to one iteration; one increment, allow me to provide something more complete, several iterations progressed.

If it is useful, please discuss this data model, and progress it to fulfil all your requirements.

• Of course it is too small as an inline graphic. As a PDF Supermarket Data Model .

• The Standard for Relational Data Modelling since 1983 is IDEF1X. For those unfamiliar with the Standard, refer to the short IDEF1X Introduction .

I am using PowerDesigner to create the ERD and then generate everything from it (LDM, PDM, OOM). Is this a bad idea?.

1. PowerDesigner is great. Just ignore the Oracle-specific nonsense, it pushes you into considering the physical far too early.
2. Skip the ERD, it is brain-dead in the context of the Relational paradigm, and surpassed by IDEF1X, which is specific to that paradigm.
   • Use the Entity Level display for ERD equivalence.
3. For small projects you can ignore the academic distinctions {CDM; LDM; PDM; OOM, etc}.
   • There is actually just one model: it is "conceptual" at the beginning, and you just progress to "logical", and last, when the "logical" is stable, to the "physical".
   • Understand that the whole process is Logical.
   • Unfortunately, in PD you have to have separate "models" or files for each.

Now for my main problem It's between these 3 tables:

I have solved that issue. And exposed others.

each customer can request_order from one or more Employee and each Employee can get_order to one or more Customer
each Employee can get_order to one or more Customer

Yes, but that is the overall result. In each shopping or presentation instance:

• a customer can request_order from one Employee (Cashier)
• a Employee can get_order from one Customer

The problem is if I want to know the customer related to that specific order......I can't. How do I fix this?

Solved: Each Order is Identified by (CustomerId, DateTime) , ie. the Customer who created the Order .

Note

1. Do not mix Process elements (eg. Get_Order) with Data elements (eg. the data model). The two areas are separate, and governed by quite different science. Here we are solving the Data; only the Data; and nothing but the Data. After that, the Process Model is easy.
2. RecordIds are anti-Relational. They are certainly not needed in a Relational database. Read my other Answers for detailed explanations.
3. Relational Keys (aka Compound Keys or Composite Keys) are standard fare in a Relational database. They provide far more integrity than a RecordId based file ever can.
4. You need to be more precise (state the exact sequence) in defining how an Order is created.

Please feel free to comment or ask specific questions.