[Thursday, Jan 20, 17:15] > I was wondering if we work in groups to solve the homework, do each of us > need to submit our homework separately or do you want us to just submit one > with all of our names on it? Please submit only one copy with all names on it. Everybody will be credited the points individually, so there is no advantage in submitting several copies. It is also forbidden to submit joint work as individual work. Siripun (the GSA) is paid only for 10 hours per week, so we hope that due to group work we get significantly less than 70 homework submissions. ------------------------------------------------------------------------------- > We've already done with the E-R model of homework 1. > But we have a question and hope you can answer for us. > > In the solution, do we need an attribute-"topic manager" under > entity-"topic"? > It seems kind of redudant because the topic manager will > be the same as some of the members in that group. > But on the other hand, if we don't put the attribute there, > it seems the "manage" relationship cannot be shown. I thought that there is only one group of people, not one group for every topic. Web-pages they collect are classified into topics, though. I am sorry that the exercise was not clearer. I understand that it can also be read that way. But in any way, you should never use an attribute to identify another entity. You must always use a relationship. Something similar will come up with the cities and the capital city in Homework 2. I can think of three different solutions, but none is really perfect, i.e. clearly better than the other. Each could need an additional constraint. But if you don't have to model the group members, but only the topic manager, it should not be difficult. Although I agree that probably not every member is interested in every topic, so it would be reasonable to model different groups. If you want, you can do that, but it makes the task more difficult and you will not get more points (most probably). ------------------------------------------------------------------------------- [Saturday, Jan 22, 13:00] > We understand that there's only one group of people, and some of them may > be managers of various topics. We also know that each topic is managed by > only one person. Our question is more about whether it's appropriate to > represent "topic_manager" as an attribute of "topic", since topic_manager > is also is also a member, and this might involve redundant information, or > a shortcut, as slide 3-40 illustrates. > > Here's what we've got: > > member --- votes --- webpage -- has(belongs to) --- topic > | | > ------------------- manages ------------------------- > > And our question is twofolds: > (1) Is the member -- mamages -- topic route redundant, since we can also > infer the relation between member and topic indirectly from member to > webpage to topic? No, this relationship is not redundant. It would only be redundant if for all members P and topics T There is a webpage P such that member M votes for P and P belongs to T if and only if M manages T. The "only if" direction (i.e. the first line implies the second) is certainly false: It is possible that a member votes for a page, although he/she is not the topic manager. The "if" direction is normally, but not always true: The topic manager votes presumably for at least one page of his/her collection, better still, for all pages. However, at the beginning, when a topic was just created, there might be no page for this topic. So then the second line might be true but not the first. But already if one of the two implications does not hold, the relationship is not redundant (it contains information which would be lost if the relationship were deleted). If one of the two implications would hold, you should specify a constraint (starting from Homework 2), but here the implications do not hold in general. > (2) Should we have a "topic_manager" attribute associated with topic, > since in this graph "topic_mamager" is also represented by "member"? > > I guess what confuses us here is the definition of redundancy and > shortcuts. We know we should avoid them, but we don't know if the member - > manages - topic route counts as a shortcut. Not every cycle of relationships really is a shortcut. Something is redundant only if the same information is stored twice. But if you remove this relationship, you lose the information, who of the members who voted for a page related to the topic is the topic manager. However, it is certainly a mistake to use an attribute containing an identification of another entity. You must use a relationship in such cases.