Home arrow Development Cycles arrow Page 15 - 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 - Complete Model?
(Page 15 of 21 )


But, is this based on a complete model of the reality? Where do we get our BALANCE from? It does not come from out of the blue. A full and true picture of the reality would be something like:

entity relationship

Quarterly balances are computed from of transactions. The entities for BALANCES and PERIODS are denormalizations; derived (or computed values) that has to come from transactions. It MAY be correct to use the former model (in a data warehouse), but it violates 3NF if you expand your view to look at the complete business model.

I call this The Analysis Trap 1. This may happen if one tries to limit the scope of the task at hand, and it would lead us into a situation where, whenever a transaction is inserted, updated or deleted, we MUST have a business rule that says ‘Update BALANCES whenever something happens in TRANSACTIONS. There may even be a worse cause for this analysis trap 1 to happen: Someone might say: ‘Performance will be lacking if we do not sum up here and there’. But those quotes are a certain sign that one is thinking physical implementation of the model; tables, SELECT statements, and so on. However, a computer’s performance ability has NOTHING to do with the analysis of the business!

(We will return to that in an upcoming Design Phase topic).

Remember, it is the business; how we run it (or would like to run it), that determines what information (entities) we need, and how the different types of information interact with each other (relationships). As you work your way through the analysis phase, the business model (and implicitly the E-R model) will become more and more accurate. Applying normalization techniques will ensure low (or no) level of redundancy (repeating the same information), and as a consequence also deliver a high level of referential integrity (correct relationship values).

Analysis Trap 2 - Incomplete Business Understanding
The Analysis Trap 2 is about incomplete business understanding or misinterpretation of the business processes. This is a common source for inadequate data models. There are (at least) two factors that may lead to this; The system analyst is lacking experience either from the specific business area, or in general, and/or the business fails to bring forward enough detailed information about the business needs. 

I have come to the conclusion, after more than 15 years of ER modeling, and a total of 28 years in the software industry, that more often than not, the "professional" part in the business analysis task, the system analyst, must take a fair share of the burden here.

Being a system analyst is not the same as being a programmer. These are two distinct different professions, and different skills are necessary. It is not a disadvantage for a system analyst to have a programming background; you may quickly see areas where the model will influence the development phase in a negative way.


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