[Sunday, Feb 6, 16:45] > I have few questions on homework three. Please clarify: > > 1) Will the inclusion of chain of grocery stores be a redundant > entity ? You do not need the chain itself as an entity, since the database is only for a single chain. > 2) For a store having several checkouts, is it better to make a > multivalued attribute for stores or have checkouts as a separate > entity in itself. You need to store which checkout produced a sales check. If you make checkouts a multivalued attribute for store, you cannot have a relationship to sales checks. > 3) Please clarify: what is a sales checks ? I'm not clear as to what > this word means, does it mean that you verify the validity of the > sale, or is it something else ? A sales check is a piece of paper stating what you bought and how much each item costed. You get it at the checkout (cash register). A receipt is a very similar thing. If you know a better word, please tell me. I looked the word up in my dictionary, and sometimes it has not good translations. It also mentions sales receipt and sales slip as possible words, but sales check is marked as American. > 4) will to-date be an optional attribute because it might not be > known. I can't tell you this. This decision is part of the exercise. I think you can easily answer it yourself given what you already know. > Thanks for your time and patience, I am benefiting from this class, at the > end of this course, will we learn how to make databases interact with web > pages ? Yes, I hope so. We will talk at least one evening about this. However, two or more weeks might be better, but we won't have so much time. We are already quite significantly behind the schedule. ------------------------------------------------------------------------------- [Sunday, Feb 6, 17:00] > Our group has a question re: the assignment #3 and the ER Model for the > grocery store chain. > > With the construct for the product price, and keeping historical data of > valid price "from date" and "to date", we have set up our diagram with > price being a multi-valued (double oval) attribute of product. From this > attribute we then have the 3 attributes (single ovals) with start date, > price and stop date respectively. Our question is how to incorporate the > fact that there will always be a start date, and a price but there may not > be a stop date if that is the current selling price. > > Our two possibilities are (1) have the stop attribute as an optional > "o" attribute or (2)just have a natural language constraint that one of > the stop date values will be a null value. If it is can be null or unknown, you must declare it as an optional attribute. It is a bit strange that you have a multivalued an structured attribute, and only one component can be null, but I did not forbid this, so it is possible to mark only one component as null. (2) is not an alternative: If stop date values can be null, you must mark them as optional. It is a good question whether you need a constraint saying that one of the intervals is open to the right, i.e. the price must be valid until further notice. It is not completely clear whether such a constraint will always be fulfilled (you might want to say that this price is only valid until the end of the year but without already specifying the future price). But such a constraint makes sense: You might want to make sure that you do not run out of a valid price for the product, so that suddenly you can't sell it any more. I.e. this is your decision (normally you must talk with the grocery store manager and also look at your update programs). By the way, using a multivalued attribute is not the only possibility (although it is valid). Another solutions is to create a second entity "priced product". We talked in class about the relation between weak entities and multivalued attributes. > Is this similar to the issue of a name attribute structured with first > name, middle name and last name -- and needing to account for the > possiblity that someone might not have a middle name? Yes. Although there it would be an option to use the empty string for the middle name instead of a null value. But both is possible. ------------------------------------------------------------------------------- [Sunday, Feb 6, 17:05] > Regarding the homework #3, I have some questions. > > 1. Is it OK to assume that only one customer card is issued to one customer, > or should I consider the possibility of one customer having more than one > customer card? Only one customer card is issued per customer. I understand that there are sometimes connected cards, e.g. for husband and wife, but the exercise is already quite complicated, so we ignore such possibilities. > 2. Is the credit limit set for each customer or for each customer card? This is then the same. > 3. What should I use for the key for "known customers"? This question is in > regard to the above 1 - If only one customer card is issued to one customer, > then I can use the customer card number as a key -- if not, should I just use > name and address as a combined key? Yes, the card number will be fine. Probably in reality, one would do some checks, at least when a new card is issued, that the same person does not apply more than once. But again, this is too complicated. > I'm not sure if I should create "Customer" entity as a parent for > "Known Customer" entity and create a specialization. But, then again, > it doesn't make sense because there's not much information for the general > customers, who don't use the customer card. Could you provide me with some > idea as to how I should go about it? Right. If the customer is not known, you have only the sales check and nothing else. It is not necessary to store "unknown customers" in the database. Only their sales checks are stored.