Is it correct not to make relationship between some entities? and how do we do normalization to reach to this diagram ?
-
At first glance, an administrator should be a user. It appears that your using User to represent Employees and Clients, I would segregate the two. – S. Walker Nov 04 '17 at 23:47
-
I don't understand what the service_provider table does. The service request is already tracking the user is and service id. Why do you need another table? If this table has additional fields, why are you tracking user is in the service request table, when they are already in the service provider table? – S. Walker Nov 04 '17 at 23:50
-
What's this database supposed to accomplish? – S. Walker Nov 04 '17 at 23:52
-
tthis erd describe app about (road helper ) , the user can be either service provider or service request , – Shatha Azzazi Nov 04 '17 at 23:56
-
when user need help he request a service and another user give help – Shatha Azzazi Nov 05 '17 at 00:01
-
Start by segregating User into Client and Provider. This will allow expansion later and enhance your normalization. Then map service request to client ID instead of user id. – S. Walker Nov 05 '17 at 00:18
-
I would then say each Service Request has Line items, each line item having a service that was rendered. This allows you to easily map which service provider fulfilled that line item and also allow you to say that these service providers are capable of performing these services. – S. Walker Nov 05 '17 at 00:21
-
Yet, a line item should only ever have 1 service and a service request may have many line items. Each provider may have many services and many services may have many providers. I think those would help alot. – S. Walker Nov 05 '17 at 00:23
1 Answers
It's not wrong to have multiple ERDs that aren't connected, but normally most/everything involved in a single system will end up related.
Administrators are normally handled as users with most/all permissions enabled, not as distinct entity sets. Advertisements may well be disconnected, though though they often end up related when advertisers want to target specific groups of users or the system needs to log impressions or clicks. As for the other parts, it's difficult to say if they should be related or not without better understanding the situation you're modeling.
Normalization is normally done after a conceptual ERD is translated to a logical relational model, not directly on an ERD or in the process of creating one. Understanding how entity sets, attributes and relationships translate to domains, relations and dependencies may invite one to try normalizing directly in the ERD, but a problem with this approach is that the entity-relationship model isn't a complete and consistent logical model, and so some relations may not be representable in an ERD.
One problem with your use of notation is that you indicate foreign keys as weak key attributes. Weak keys are a different concept from foreign keys, foreign keys aren't normally shown in an ERD. Second, I would make services_providers
a relationship and add a relationship between it and services_requests
(a relationship on a relationship turns the latter into an associative entity) instead of relating it directly to services
.

- 9,806
- 2
- 23
- 37