EntityList

Entities found

The following Entities have been found:

• CUSTOMER
• SERVICE
• INVOICE
• INVOICE LINES
• LABOUR CHARGES
• PARTS
• INVENTORY
• SUPPLIES
• VENDOR
• CAR
• MAILINGS

mj (Sep 6, 2001 11:23 am; Comment #1)

My remarks

• Maybe we should mark composite entities like the INVOICE LINES entity; 't will be easier to distinguish them later on when making the ERDs.
• I am not sure if LABOUR CHARGES is an ENTITY, could it be just an attribute to the INVOICE?
• MAILINGS are a process, not an entity set; someone or a program pulls out the last service date of a car and decides wether or not to send mail. I don't think any data about the mailing itself needs to be stored.

sqjackson (Sep 7, 2001 1:23 pm; Comment #2)

If there is only one set labour charge i agree

The thought behind MAILINGS was keeping mailings history by customer, but perhaps I am overcomplicating things Q

mj (Sep 7, 2001 1:26 pm; Comment #3)

 >  If there is only one set labour charge i agree
 

I see the charge as an attribute of the invoice; it doesn't have it's own attributes. I understand it as being only one charge per invoice, anyway.

mj (Sep 7, 2001 3:31 pm; Comment #4)

Further thought: What is SERVICES for?

mj (Sep 7, 2001 3:33 pm; Comment #5)

I also think INVENTORY is just an attribute of PART (signular).

john_knight (Sep 7, 2001 5:31 pm; Comment #6)

I have just managed to find my way around Quantum Pythons and see you have already agreed that some of the entities already listed may not be required.

I agree with comment on Labour Charge, since it is just a standard rate. The one charge per invoice would simply be based on time taken for the task. I read the text as implying one standard charge and not different charges for different activities.

With regard to mailings, then these could fit into both camps. Yes the mailings are a process, but the mail sent could be classed as an entity in that each one could be different, based on current prices for the parts. But then this is no more than a mail merge activity, which could be regenerated at will. So on balance I agree there is no need for them in the entity list.

With regard to SERVICES, I see this as another process and not an entity. One doesnt store information against services, but against customer and car.

INVENTORY v PARTS. I agree that the number of parts in stock is just another attribute of the PART table that will be updated when a part is used.

I will now get on with the Excel Spreadsheet as tasked by Q.

mj (Sep 8, 2001 4:10 pm; Comment #7)

As John points out on EntityAttributes there is a difference between INVENTORY and PART; PART is the type of part used, like windshield wiper, or oil. INVENTORY lists the individual parts, where one wiper could be from one vendor, while another from the next vendor. I've added this to the EntityAttributes page as an example. This list is still authorative.

mj (Sep 10, 2001 9:43 pm; Comment #8)

See discussion on EntityAttributes: We may have gained an additional (composite) entity: SUPPLIES, as vendors supply parts and parts are supplied by vendors. Also see remark on Assumptions.