Home arrow Development Cycles arrow Page 5 - Entity Relationship Modeling

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 / 90
April 05, 2004
  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

Entity Relationship Modeling - Business Rules
(Page 5 of 21 )

Now, we have suddenly gotten the opportunity to define a business rule here! This definition WILL result in a constraint in the complete database, at the end of the design phase, like this:

PROMPT Creating Check Constraint on 'TRANSACTIONS'
(CONSTRAINT AVCON_1071502401_VALUE_000 CHECK (VALUE BETWEEN 0.01 AND 999999.99)).

But we are too far into design now: Let us step back, and look at how we can define a type-domain as well:

type domain

Since we have the legal range constraint defined, we should be able to reduce the length of the domain. Since the MONEY domain is attached to the transaction amount attribute in some transaction, changes in the domain have immediate impact. I will stress this. Relate all attributes to its domain, like this:


The best advice I can give is - Do not settle for tools that do not support most of your development cycle.

Relations are the bonds between entities. They tell about certain rules that apply if you want to insert, update or delete occurrences (rows) from what later becomes tables. Relations also tell us much about the logic connections between entities. In the physical design of the database, relationships become constraints that govern how you are allowed to manipulate data in the different tables. The relationships are there to enforce referential integrity. This refers to the internal logic of your system and ensures that your objects are referring to actual items in tables.

Relations, as we use them in analysis, are in some ways in contrast to what is allowed when you physically transform the ER model to a physical, live database. This is due to the fact that in analysis, we model the business, but in design, we have to abide by laws of the database system. This is all, again, to enforce referential integrity; securing that your database does not get corrupt.

blog comments powered by Disqus

- 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 

Developer Shed Affiliates


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