Re: About Entity Relation Diagram

Thanks you for the reply.

I thought that normalizing was all about making flat tables into tables with as less columns as possible.

I do, however, have another question. What will the primary key of the entity INTERESTS and APPEARANCE be? I read somewhere that when relating 2 entities with a relation, the relation doesn't have to include the primary keys of the entities it relates. For example, between member and tape, the relation RENTAL doesn't have to include MemverID and TapeID, only DateRent and DateDue.
Will this be the same case with the entities Member and Interests ? (the relation will be HAS). But then, what attributes will the relation HAS have?

PS. I 'm also reading some theory stuff. I just could use an extra advice

"Mark D Powell" <Mark.Powell_at_eds.com> wrote in message news:1103203101.391468.169390_at_f14g2000cwb.googlegroups.com...
> Silver, why do you think the column list is too large. We have several
> tables with more than 100 columns in them. As long as each and every
> column is fully dependend on the PK then the data is normalized.
> Splitting data that shares the same PK into multiple tables is
> denormalized.
>
> Now, if the combined length of the columns exceeds the maximum row
> length supported by your RDBMS then you will have to split the rows
> into pieces each of which will have to be stored in a separate table,
> but the tables will share the same PK. This is a case where the
> physical implementation has to vary from the logical design due to
> limitations in the software.
>
> HTH -- Mark D Powell --
>
Received on Thu Dec 16 2004 - 14:21:50 CET