ERD for a web development company

I am working on an ERD which represents the relationships between entities in a Web development company behavioral model.
There I have entities like:

• Customer

• Service ----------- (like: web development, web design, web consultation, ...)

• Order-item ------- (like: web development, web design, web consultation, ...)

• Order

• Invoice

• Project

• Project-phase

• Task --------------- (like: web development task3, web design task7)

• Developer

• Delivery ----------- (like: the developed web app, web consultation session, ...)

I have this diagram so far, though I know it still has major problems, and it is just for a start point:

Main concept

• Customer makes order-items on services, combined to form an order which relates to an invoice.

• Each project has multiple project-phases with each project-phase related to an order.

• Each project-phase has multiple tasks, each of which is assigned to a developer.

• Each project-phase has a delivery, which will be delivered upon payment of the related orders invoice.

Questions

• Are has and contains completely the same? If not, how to choose between them for relationships?! what is the measure?!

• Are there any rational problems with the Main concept section?

• Any helpful ideas or suggestions to improve this model?

Any help with this, would be really appreciated.

Update 1

Refined version of the diagram

Update 2

Considering an analogy of a Fast food restaurant would be helpful:

• Customer ---------- A hungry person

• Service ------------- Making a burger, Home delivery, Mobile delivery, ...

• Order-item --------- A burger, ...

• Order ---------------- A home-delivered burger

• Invoice -------------- The printed invoice

• Project -------------- Serving the customer for a complete year (like a contract)

• Project-phase ----- Serving the customer for a single day

• Task ----------------- Preparing the kitchen, process the meat, ...

• Developer ---------- The c

You're oversimplifying the relations. No two relations in your diagram are the same, since they don't relate the same domains. has is not the same as has . They might both be injective, but that's not sufficient to call them the same.

Try to give your relations more descriptive names. While attributes (aka one-to-one binary relations) tend to be aggregated on a common determinant to create "entity tables", multivalued attributes and more complicated relations like the ternary relation between Customer, Service and Order-item usually become tables on their own. Makes really doesn't describe the relation or resulting table properly.

I suggest you add cardinality indicators to your diagram and give your relations more descriptive names, using the predicate statement of each relation for guidance.

On second thought, those names are probably fine in a conceptual design as long as you read them together with the entity sets they relate. When you get to physical design, 1-to-1 and 1-to-many relations will probably be implemented as attributes of one of the entity sets, so the relation names won't affect the physical design. The many-to-many relations and non-binary relations will become their own tables, for table names at worst you can concatenate the entity names, e.g. CustomerServiceOrderItems.

StackExchange Database Administrators Q#127743, answer score: 3