Home arrow Development Cycles arrow Page 13 - 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 - Level of Knowledge
(Page 13 of 21 )


In the analysis team, the system analysts must have an expert level knowledge of business modeling. By business modeling, I mean exactly that. (i.e. I do not mean expert knowledge of Entity Relationship modeling without relating it to the real world.) However well a person may be educated, nothing beats the experience earned from several similar tasks at the equivalent level of complexity. How does one gain experience then? Participate under a tutor. I would never hire a consultant without experience and trust her to understand the complexity of my business, all by herself.

I will not go into detail as to the total staff composition. This will depend on many outside factors, such as degree of participation from each party, size of the project, formal requirements (public sector tends to require at higher level of project staffing, partly due to rigorous documentation requirements), etc. What we focus on is the tightly performing party that determines the final business model.  This means the experts on the business together with the system analysts, -preferably more than one- in this phase.

Due to the increasing complexity that tends to be taken into systems development, I cannot imagine a development project of any noticeable size that should not use a development tool as support for the analysis team as well as for each stage other of development. I regard the tools chosen as an integral part of the team. In many cases, the tool is also the communicator between the business and the analyst. 

I have often started a project by going through the way we communicate with each other. In my experience, the business soon finds Entity Relationship diagrams familiar, if not as familiar as to the system analysts. However, they are a means of communication that work. The same may be said for function diagrams, or function hierarchies. They are even easier to understand for a non-system person.

Analysis progress 
With the tools of today’s technology (laptops, projectors, computer networks and not least, the Internet), the analysis process can take place literary anywhere. Actually, most processes are mobile. For all practical puposes, we are more mobile: some parts of the analysis progress may take place at the business office, and other parts at the analyst’s office. They can communicate on the net at any time, collaborating outside of formal meetings. No doubt, this is increasing performance in the analysis progress, as well as saving time, and thereby costs. 

For instance, sometimes I do vital parts of a project at my home office, but my tools repository (Oracle), resides on the server park at the office. I can also get limited access to it for my customers, if I wish.(Sidebar: The invention of home offices is perfect for employers: We, the employees, work both day and night, and on top of it, we love it…Crazy world). OK, back to business: While we may have inherited a sketch of an ER model from the strategy phase of the project, now is the time to start asking the difficult questions. We will be probing that sketch, and stressing both the model and the business representatives (yes, I am now talking on behalf of the system analyst; since you are still reading this, most likely you are also one).


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