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?

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.

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.

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.

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

Maybe I read Object-Oriented concepts a bit too much.

thanks guys, this has been most helpful...

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.