Re: About Entity Relation Diagram

"Silver" <argytzak_at_med.auth.gr> wrote in message news:cprtnf$7dq$1_at_nic.grnet.gr...
> Hi,
>
> I 'm currently working on the ER diagram of a dating site.
>
> I have this question about the tables that will contain the members data.
>
> How can I organize the data so that the table remain as normalized as
> possible. In particular, I want my tables to be in the 3rd Normal form.
>
> For example, the table with the member's APPEARANCE: will I have to have a
> table with the member's ID and then the columns: eyeColor, hairColor,
> Weight, BodyType, etc... ? That makes the table too large. Is there any
> other smarter way ?

First of all, you are dealing with an ERD, so there are no tables yet. There are entities and relationships. In any event, there is really no such thing as a table that is "too large". A table is derived from your ERD, and an entity needs to contain whatever it needs to contain. Therefor, so does the table. Two attributes, a hundred attributes- whatever. Now, that being said, it is not "usual" to have 100 attributes, but it certainly happens, and is quite fine, so long as it is correct.

>
> What about the table with the member's PerfectPartner? Will I have to
> include the same attributes as in the APPEARANCE table? Again ?

I doubt that you would store a PerfectPartner. This will change often, as when new people come in to the system or someone updates their preferences. PerfectPartner is probably a derived value, and as such, should probably not be stored- at least not in an OLTP system. Others will argue that it should be stored. It is really a decision that is made based on many factors. Theorists (such as Celko) will argue it should definitely NOT be stored. In the realm world, the answer is "it depends". In this case, my feeling is that because it will be subject to frequent change, it should be derived on the fly. I presume you are using some collection of comparisons to determine the PerfectPartner. You didn't really say.

>
> The same problem occurs with the table INTERESTS. I want to have a list of
> predefined interests that the member can choose from, as well as a
StringBox
> where one can enter something different. How can this be organized which
as
> much as redundancy as possible??

You should not be considering implementation during the analysis phase (which is what you are in when constructing an ERD). All it can serve to do is confuse you. And, I think you want _no_ redundancy, not "as much redundancy as possible". Just think about the ERD -the data and the relationships among the data. Are you saying,

"A PERSON can have one or more INTERESTS and an INTEREST can be had by one or more PERSONs"?

If so, then you have a classic M:N situation. You should have been taught how to model this in the ERD, and how this will eventually translate to tables.

Once you have mapped your ERD to tables, then it is time to think about how to implement everything. It will also be easier. Once you see how the INTERESTs are connected to the PERSONs, you will understand how to implement your drop-down list.

>
> I'm not asking to do this for me, just looking for advice on how to
proceed.
>
> Thanks!
> Silver
>
>
>
>
Received on Thu Dec 16 2004 - 20:06:10 CET