Entity relationship diagrams doubt

Click For Summary
SUMMARY

The discussion centers on the design of entity relationship models, specifically addressing whether repeated attributes should be shared among entities or duplicated. It is established that common attributes, such as a publisher, should be defined in a parent entity like "Publication," while unique attributes should reside in their respective entities, such as "Books" and "Magazines." Additionally, the conversation touches on the challenges of using yUML for diagramming, particularly the inability to combine different geometric shapes from various diagram types.

PREREQUISITES
  • Entity Relationship Modeling
  • Understanding of Parent and Subentity Relationships
  • Familiarity with UML (Unified Modeling Language)
  • Experience with yUML Diagramming Tool
NEXT STEPS
  • Research best practices for defining parent-child relationships in entity relationship models.
  • Learn about UML class diagrams and their components.
  • Explore advanced features of yUML for creating complex diagrams.
  • Study common pitfalls in entity relationship modeling to avoid redundancy.
USEFUL FOR

Database designers, software architects, and students of data modeling who are working on entity relationship diagrams and seeking to optimize their design practices.

colt
Messages
20
Reaction score
0
I am doing a project of an entity relationship model and a doubt came: Should repeated attributes of the entities be shared? Or I must reproduce these to every entity? In another words, if two of my entities are books and magazines, shall I have a single publisher attribute, or one for each?
 
Technology news on Phys.org
colt said:
I am doing a project of an entity relationship model and a doubt came: Should repeated attributes of the entities be shared? Or I must reproduce these to every entity? In another words, if two of my entities are books and magazines, shall I have a single publisher attribute, or one for each?
What if you have some other entity, such as publication, with books and magazines as subclasses (or subentities)?

Whatever attributes that both books and magazines have in common could be defined in the publication entity, and the attributes that books and magazines don't share would go in one or the other of these entities.

That's just my take...
 
Mark44 said:
What if you have some other entity, such as publication, with books and magazines as subclasses (or subentities)?

Whatever attributes that both books and magazines have in common could be defined in the publication entity, and the attributes that books and magazines don't share would go in one or the other of these entities.

That's just my take...

True, that's a better solution. On a side note, anyone here has any experience using yuml? If someone does, the problem is that I don't know uml, so I tried to make my diagram through modifications of given samples in the yuml website. But I wasn't able to combine the two geometric shapes that I wish simultaneously. That's because a rectangular box is available in the Class Diagram Samples and the oval shape is available in the Use Case Diagram. But both doesn't work simultaneously in any of the two kinds of diagrams Example: (Register)>(Confirm Registration) is in the "Use case diagram" and [Customer]->[Billing Address] is in the "draw class diagram"
 

Similar threads

  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 48 ·
2
Replies
48
Views
10K
Replies
7
Views
2K
  • · Replies 22 ·
Replies
22
Views
3K
  • · Replies 23 ·
Replies
23
Views
3K
  • · Replies 36 ·
2
Replies
36
Views
8K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 2 ·
Replies
2
Views
4K
  • · Replies 25 ·
Replies
25
Views
2K