Results 1 to 8 of 8
  1. #1
    Join Date
    May 2002
    Posts
    2

    entity relationship diagram question

    how do you represent many different kinds of essentially the 1 object? like a candidate for election, say, candidates can have a party, can be independant and so on...do i make 1 candidate entity and give it all possible attributes? or do i make many canidate entitys to represent all possibilities?

  2. #2
    Join Date
    Dec 2001
    Location
    Delhi/Bangalore, India
    Posts
    74
    Generally, having a schema representing an entity to have any one of a given set of attributes is not considered good ER-design. (because that's not how intuitive object-oriented systems work, in real world).

    An alternative solution is to have an attribute (boolean) "Independent" associated with the Candidate, and an attribute "Party" associated too. The value in attribute "Party" is used only if the attribute "Independent" indicates the candidate belongs to a party.

  3. #3
    Join Date
    May 2002
    Posts
    24
    actually, you are introducing a useless column there by having both an "independant" and "party" column. being "independant" can be considering being part of a "party" - the independant party.

    those are mutually exclusive properties. it's the same as saying a candidate cannot be in two different parties at the same time.

    i would personally model that one as a lookup value - a foreign key to a list of parties a candidate can belong to, listing independant as one of the possible parties.

    in other words "party" and "indepedent" are the same attribute so should be the same column.

  4. #4
    Join Date
    Dec 2001
    Location
    Delhi/Bangalore, India
    Posts
    74
    Originally posted by fallacy
    actually, you are introducing a useless column there by having both an "independant" and "party" column. being "independant" can be considering being part of a "party" - the independant party.
    I know, and I considered that while writing the above post. But keeping it this way would allow for any future expansions on logical/db-programming part (as per my experience has been with the programming part...), so it might be better to have as "component"-ized a design as it could be.

    Anyway, this particular thing doesn't matter.... It was used as an example, and Rashad might want to utilize the concept onto other actual tables.

  5. #5
    Join Date
    May 2002
    Posts
    24
    i guess i can't really see how it would allow for future logical expansion? will, in this particular situation anyways.

    interestingly enough, my experience has taught me that keeping things completely relational and using lists where possible is a good thing =)

    hehehe, such opposing experiences eh

  6. #6
    Join Date
    Dec 2001
    Location
    Delhi/Bangalore, India
    Posts
    74
    Maybe I read Object-Oriented concepts a bit too much.

  7. #7
    Join Date
    May 2002
    Posts
    2
    thanks guys, this has been most helpful...

  8. #8
    Join Date
    May 2002
    Location
    USA
    Posts
    1
    Try to verbalize the real world facts you are modeling.

    "Candidate may be associated with Party". Also true are instances where Candidate is not associated with a party. You can imply this by the lack of relationship between the two instances, (making it a nullable relationship, or zero-or-one to many) or you can introduce a unary fact, "Candidate is independent" with a true/false value.

    Physically, a DBA may want to collapse those two facts into one, by making the lack of affiliation to a party one of the values in the party. Carefull though, there are parties out there now called 'The Independent Party', etc.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •