-1

This is an ER diagram for project management software I'm building.

It contains these entities:

  • project - software projects
  • tasks - software projects that can be broken into a number of tasks
  • employees - employees that belong to this software

To complete the project:

  • project must divide into sub tasks
  • project can have 1 or many tasks
  • tasks belong to only 1 project.
  • assign employees to project
  • project can assign 1 or many employees
  • selected employee happen to be assigned to a 1 or more projects

Let's take project A

  • project A has these tasks - task a1, task a2, task a3
  • project A has assigned these employees - emp aa1, emp aa2, emp aa3

From those project A assigned employees(emp aa1,emp aa2, emp aa3) you can select one employee, and to that employee you can assign selected project A task (task a1, task a2, task a3).

And employee can submit spend daily amount of time to a particular assigned task. It can be multiple entries.because to done a task it can be spend multiple amount of days

If he submit those data to system

  1. employee allocated to a particular project(project B) has done few tasks (task b1, task b2) that belong to project B.

Using system select task b1 and then can view how employee spend time day wise for completing that task

enter image description here

I have the following questions

  1. Is this ER diagram correct?

  2. Can I convert relationship (diamond) to convert associative entity?

  3. How to mark cardinality?

Susantha7
  • 898
  • 1
  • 20
  • 38

1 Answers1

1

Is this ER diagram correct?

Your diagram doesn't appear to correspond to the given text. Since each Task belongs to a single Project (i.e. Task determines Project), there would be no reason to have both Task and Project together in a relationship with other entity sets. Similarly, Assignment and Project wouldn't be found together in a relationship with other entity sets. Overall, the unnamed central relationship just doesn't make sense.

Can I convert relationship (diamond) to convert associative entity?

Why? In the ER model, associative entity sets are used when a relationship needs to be the subject of another relationship.

How to mark cardinality?

Next to each line going from a relationship to an entity set, write "1" if only one entity can occur in that role in the relationship for any combination of the rest of the roles. Write a variable letter ("M", "N", etc) if multiple entities can occur in that role for any combination of the rest of the roles. Don't use the same variable letter more than once per relationship.

For example, let's say you have a company which distributes multiple products in various regions, and there is exactly one salesperson per product in each region. That would be a ternary relationship, in which the Salesperson is determined by the combination of Product and Region. For any combination of Product and Salesperson, multiple regions might be recorded (I didn't say Salespersons were limited to a single Region) and for any combination of Region and Salesperson, multiple Products might occur (a Salesperson could sell multiple Products in the same region). So the cardinalities would be M (Products) to N (Regions) to 1 (Salesperson).

reaanb
  • 9,806
  • 2
  • 23
  • 37
  • both Task and Project together in a relationship because ???? Let's take project A `project A has these tasks - task a1, task a2, task a3` `project A has assigned these employees - emp aa1, emp aa2, emp aa3` if not use both Task and Project together in a relationship From those project A assigned employees(emp aa1,emp aa2, emp aa3) can assign any task (that belong to project A and also other projects) – Susantha7 Feb 19 '18 at 05:20
  • 1
    I would expect to see a binary relationship between Task and Project. However, since Task determines Project, I wouldn't expect 3-way or 4-way relationships involving both Task and Project _together with other entity sets_. Such arrangements would produce redundant transitive functional dependencies in the logical model. – reaanb Feb 19 '18 at 05:42
  • There are different ways to indicate cardinalities (in particular look-here & look-across) so you have to give a reference to the variant ER method you are told to use. Also any relationship can be reified to an associative entity--if your method allows it. So again give a reference to the method you are to use. – philipxy Feb 19 '18 at 06:48
  • but to convert relationship to associative entity all the relationships for the participating entity types are M:N relationships mentioned in here and https://stackoverflow.com/questions/28905166/difference-between-associative-entity-and-associative-relationship-attribute is this true – Susantha7 Feb 19 '18 at 10:19
  • @Susantha7 The entity-relationship model (as defined by Chen) doesn't require associative entities to represent many-to-many binary or ternary and higher relationships (except as mentioned in my answer). It's an idea that was required in binary data models due to the limited expressive abilities of those models. – reaanb Feb 20 '18 at 07:52
  • @Susantha7 The requirements for M:N (or M:N:P in ternary relationships) is again due to expressive limits in ER diagramming notation - constraints on entity sets don't reflect in their relationships. Song, Evans and Park said in [A Comparative Analysis of Entity-Relationship Diagrams](http://www.cci.drexel.edu/faculty/song/publications/p_Jcse-erd.PDF) that a "gerund always has many side cardinality, regardless of the cardinality of the original ternary relationship". – reaanb Feb 20 '18 at 07:52