Development Cycles
  Home arrow Development Cycles arrow Entity Relationship Modeling
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
DEVELOPMENT CYCLES

Entity Relationship Modeling
By: Alf A. Pedersen
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 60
    2004-04-05

    Table of Contents:
  • Entity Relationship Modeling
  • The Entity
  • Other Business Contacts
  • Attributes in entities
  • Business Rules
  • Three types of relationships
  • Supplier Entity
  • A Weak Relation
  • A Useful Relation
  • Involuted (or recursive) relationships
  • Many-to-Many
  • The Database Analysis Team - A Teamwork
  • Level of Knowledge
  • Experience vs. Inexperience
  • Complete Model?
  • Building Queries
  • Other Common Errors in ER Modeling
  • Second Normal Violation
  • More Specific
  • Generic or Specific Models?
  • Analysts Experience

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Entity Relationship Modeling


    (Page 1 of 21 )

    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.

    In the analysis phase, we are concerned about finding out about the business. At this early stage, we normally do not talk about performance-specific issues. The main goal of the Analysis phase is to determine what information the business needs to perform a certain task (accounting, invoicing, customer support), how that information should be best possibly organized, and what are the relationships between the different sets of information. We start with a few definitions:

    Entity-An entity is a specific object of interest to the business area. We might say that in an accounting system, two things are basically necessary: Accounts and transactions. In a customer support system, we would need to have some information about customers, for a start.  Each such unit of essential information is named ‘an entity’, with a name and attributes.

    Attributes-Each entity will normally have one or more attributes. Attributes may be thought of as smaller pieces of information within an entity. Together they describe our entity to the degree we find necessary. An example is a customer entity:

    Attribute

    The entity is named CUSTOMER, and has two attributes, that we have found to be important to know about the customer: Customer number and customer name. Most likely, the customer will have several other attributes as well, but that will show up during the analysis phase. The attributes have a # and a * in front of them: A # means that the attribute is (part of) the primary key for that entity. The primary key is a unique value for every new customer we get so that we can uniquely identify him from all the other customers. The attribute NAME has a * in front: This indicates that it is a mandatory attribute; for every new customer, name MUST be filled in. The opposite is also possible; if an attribute has an o in front of it, it is an optional attribute, and a value is not required.

    Relationships-In a relational database, all entities have bonds between them, expressed as relationships. A relationship is a link between to entities, and it tells us something about which relationships exists between our entities. The following example illustrates this:

    relationships

    This sketch tells us that a given account MAY have zero or more balances, but a given balance MUST BE valid for one and only one account. That sounds reasonable. Reading ER diagrams with relationships, gives us a very quick view of the logical structure of a database in the making, without thinking about the physical implementation of it, at this point.

    These are the basic elements you need to know about before starting out on your ER modeling: Entities, their attributes, what uniquely identify an occurrence of an entity, and what the relationships between the different entities are. 

    More Development Cycles Articles
    More By Alf A. Pedersen


     

    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





     


     


    © 2003-2010 by Developer Shed. All rights reserved. DS Cluster 3 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek