Home arrow Development Cycles arrow Page 6 - Entity Relationship Modeling
DEVELOPMENT CYCLES

Entity Relationship Modeling


Entity Relationship Modeling (ER modeling) is by far the most common way to express the analytical result of an early stage in the construction of a new database. In this ebook, Alf Pedersen describes the principles for ER modeling, as well as the most important terms used in modeling a new database.

Author Info:
By: Alf A. Pedersen
Rating: 4 stars4 stars4 stars4 stars4 stars / 89
April 05, 2004
TABLE OF CONTENTS:
  1. · Entity Relationship Modeling
  2. · The Entity
  3. · Other Business Contacts
  4. · Attributes in entities
  5. · Business Rules
  6. · Three types of relationships
  7. · Supplier Entity
  8. · A Weak Relation
  9. · A Useful Relation
  10. · Involuted (or recursive) relationships
  11. · Many-to-Many
  12. · The Database Analysis Team - A Teamwork
  13. · Level of Knowledge
  14. · Experience vs. Inexperience
  15. · Complete Model?
  16. · Building Queries
  17. · Other Common Errors in ER Modeling
  18. · Second Normal Violation
  19. · More Specific
  20. · Generic or Specific Models?
  21. · Analysts Experience

print this article
SEARCH DEVARTICLES

Entity Relationship Modeling - Three types of relationships
(Page 6 of 21 )


One-to-one relationships
One-to-many relationships
Many-to-many relationships

For each relationship type, we may have one or both ends optional or mandatory, which give us a total of 10 different theoretical variations of relationships between entities. However; some of them are actually impossible logically, and a few other are so far-fetched that you probably have some less well-thought constructs in your analysis if you need them.

One-to-one relationships

Mandatory-mandatory

one-to-one

This relationship says; a given product MUST come from one and only one supplier product. A given supplier product MUST be the origin for one and only one product.

It sounds right, but it is not. If the supplier product is the origin of one single product, then the attributes of the supplier product most likely should be included in our product entity. Furthermore, we can deduct from this model that we cannot enter a NEW product unless a supplier product exists. However, we cannot enter a NEW supplier product before it has a product to relate to. It is a deadlock: We will never be able to enter anything into these two entities (when they become tables). This will do us no good; it is a result of theory, and not practice.

Mandatory-optional

one-to-many

This one is a little more flexible: a product MAY come from one and only one supplier product; however, a given supplier product MUST BE the origin of one and only one product. See the above relationship on how to solve this properly.

Optional-optional

optional-optional

At last some freedom: A given product MAY come from one and only one supplier product, and a supplier product MAY BE the origin of one and only one product.


blog comments powered by Disqus
DEVELOPMENT CYCLES ARTICLES

- Division of Large Numbers
- Branch and Bound Algorithm Technique
- Dynamic Programming Algorithm Technique
- Genetic Algorithm Techniques
- Greedy Strategy as an Algorithm Technique
- Divide and Conquer Algorithm Technique
- The Backtracking Algorithm Technique
- More Pattern Matching Algorithms: B-M
- Pattern Matching Algorithms Demystified: KMP
- Coding Standards
- A Peek into the Future: Transactional Memory
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- How to Strike a Match

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials