B21- EVALUATION ON THURSDAY(5TH MAY)-10:30 to 12:30pm
B12 & B11 - EVALUATION ON THURSDAY(5TH MAY)- 2 to 5pm
B22- EVALUATION ON MONDAY(9TH MAY).timings to be decided
Saturday, April 30, 2011
Sunday, April 24, 2011
LAB SCHEDULE
java :B1-28/4 B2-29/4
MP: B11-26/4 B12-3/5
B21-28/4 B22-5/4
B22-DBMS LAB on 26/4
B21-DBMS LAB on 3/5
B12-DBMS LAB on 30/4
B11-DBMS LAB on 6/5
ROLL NOS.
B11- 55 TO 71
B12- 72 TO 87
B21- 88 TO 104
B22- 105 TO 281
MP: B11-26/4 B12-3/5
B21-28/4 B22-5/4
B22-DBMS LAB on 26/4
B21-DBMS LAB on 3/5
B12-DBMS LAB on 30/4
B11-DBMS LAB on 6/5
ROLL NOS.
B11- 55 TO 71
B12- 72 TO 87
B21- 88 TO 104
B22- 105 TO 281
phone no list
4th SEMESTER B-Section TEACHERS CONTACT DETAILS
SUJATA MA'AM 9448744540
SHANTHI MA'AM 9901659271
SMITHA MA'AM 9980250304
VIJAYA SIR 9535680918
CENITTA MA'AM 9738891473
SUJATA MA'AM 9448744540
SHANTHI MA'AM 9901659271
SMITHA MA'AM 9980250304
VIJAYA SIR 9535680918
CENITTA MA'AM 9738891473
Tuesday, April 19, 2011
example of 4nf
Multivalued dependencies
If the column headings in a relational database table are divided into three disjoint groupings X, Y, and Z, then, in the context of a particular row, we can refer to the data beneath each group of headings as x, y, and z respectively. A multivalued dependency X →→ Y signifies that if we choose any x actually occurring in the table (call this choice xc), and compile a list of all the xcyz combinations that occur in the table, we will find that xc is associated with the same y entries regardless of z.
A trivial multivalued dependency X →→ Y is one in which Y consists of all columns belonging to X. That is, a subset of attributes in a table has a trivial multivalued dependency on the remaining subset of attributes.
A functional dependency is a special case of multivalued dependency. In a functional dependency X → Y, every x determines exactly one y, never more than one.
[edit] Example
Consider the following example:
Pizza Delivery Permutations
Restaurant Pizza Variety Delivery Area
A1 Pizza Thick Crust Springfield
A1 Pizza Thick Crust Shelbyville
A1 Pizza Thick Crust Capital City
A1 Pizza Stuffed Crust Springfield
A1 Pizza Stuffed Crust Shelbyville
A1 Pizza Stuffed Crust Capital City
Elite Pizza Thin Crust Capital City
Elite Pizza Stuffed Crust Capital City
Vincenzo's Pizza Thick Crust Springfield
Vincenzo's Pizza Thick Crust Shelbyville
Vincenzo's Pizza Thin Crust Springfield
Vincenzo's Pizza Thin Crust Shelbyville
Each row indicates that a given restaurant can deliver a given variety of pizza to a given area.
The table has no non-key attributes because its only key is {Restaurant, Pizza Variety, Delivery Area}. Therefore it meets all normal forms up to BCNF. If we assume, however, that pizza varieties offered by a restaurant are not affected by delivery area, then it does not meet 4NF. The problem is that the table features two non-trivial multivalued dependencies on the {Restaurant} attribute (which is not a superkey). The dependencies are:
• {Restaurant} →→ {Pizza Variety}
• {Restaurant} →→ {Delivery Area}
These non-trivial multivalued dependencies on a non-superkey reflect the fact that the varieties of pizza a restaurant offers are independent from the areas to which the restaurant delivers. This state of affairs leads to redundancy in the table: for example, we are told three times that A1 Pizza offers Stuffed Crust, and if A1 Pizza starts producing Cheese Crust pizzas then we will need to add multiple rows, one for each of A1 Pizza's delivery areas. There is, moreover, nothing to prevent us from doing this incorrectly: we might add Cheese Crust rows for all but one of A1 Pizza's delivery areas, thereby failing to respect the multivalued dependency {Restaurant} →→ {Pizza Variety}.
To eliminate the possibility of these anomalies, we must place the facts about varieties offered into a different table from the facts about delivery areas, yielding two tables that are both in 4NF:
Varieties By Restaurant
Restaurant Pizza Variety
A1 Pizza Thick Crust
A1 Pizza Stuffed Crust
Elite Pizza Thin Crust
Elite Pizza Stuffed Crust
Vincenzo's Pizza Thick Crust
Vincenzo's Pizza Thin Crust
Delivery Areas By Restaurant
Restaurant Delivery Area
A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City
Elite Pizza Capital City
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
In contrast, if the pizza varieties offered by a restaurant sometimes did legitimately vary from one delivery area to another, the original three-column table would satisfy 4NF.
Ronald Fagin demonstrated that it is always possible to achieve 4NF
If the column headings in a relational database table are divided into three disjoint groupings X, Y, and Z, then, in the context of a particular row, we can refer to the data beneath each group of headings as x, y, and z respectively. A multivalued dependency X →→ Y signifies that if we choose any x actually occurring in the table (call this choice xc), and compile a list of all the xcyz combinations that occur in the table, we will find that xc is associated with the same y entries regardless of z.
A trivial multivalued dependency X →→ Y is one in which Y consists of all columns belonging to X. That is, a subset of attributes in a table has a trivial multivalued dependency on the remaining subset of attributes.
A functional dependency is a special case of multivalued dependency. In a functional dependency X → Y, every x determines exactly one y, never more than one.
[edit] Example
Consider the following example:
Pizza Delivery Permutations
Restaurant Pizza Variety Delivery Area
A1 Pizza Thick Crust Springfield
A1 Pizza Thick Crust Shelbyville
A1 Pizza Thick Crust Capital City
A1 Pizza Stuffed Crust Springfield
A1 Pizza Stuffed Crust Shelbyville
A1 Pizza Stuffed Crust Capital City
Elite Pizza Thin Crust Capital City
Elite Pizza Stuffed Crust Capital City
Vincenzo's Pizza Thick Crust Springfield
Vincenzo's Pizza Thick Crust Shelbyville
Vincenzo's Pizza Thin Crust Springfield
Vincenzo's Pizza Thin Crust Shelbyville
Each row indicates that a given restaurant can deliver a given variety of pizza to a given area.
The table has no non-key attributes because its only key is {Restaurant, Pizza Variety, Delivery Area}. Therefore it meets all normal forms up to BCNF. If we assume, however, that pizza varieties offered by a restaurant are not affected by delivery area, then it does not meet 4NF. The problem is that the table features two non-trivial multivalued dependencies on the {Restaurant} attribute (which is not a superkey). The dependencies are:
• {Restaurant} →→ {Pizza Variety}
• {Restaurant} →→ {Delivery Area}
These non-trivial multivalued dependencies on a non-superkey reflect the fact that the varieties of pizza a restaurant offers are independent from the areas to which the restaurant delivers. This state of affairs leads to redundancy in the table: for example, we are told three times that A1 Pizza offers Stuffed Crust, and if A1 Pizza starts producing Cheese Crust pizzas then we will need to add multiple rows, one for each of A1 Pizza's delivery areas. There is, moreover, nothing to prevent us from doing this incorrectly: we might add Cheese Crust rows for all but one of A1 Pizza's delivery areas, thereby failing to respect the multivalued dependency {Restaurant} →→ {Pizza Variety}.
To eliminate the possibility of these anomalies, we must place the facts about varieties offered into a different table from the facts about delivery areas, yielding two tables that are both in 4NF:
Varieties By Restaurant
Restaurant Pizza Variety
A1 Pizza Thick Crust
A1 Pizza Stuffed Crust
Elite Pizza Thin Crust
Elite Pizza Stuffed Crust
Vincenzo's Pizza Thick Crust
Vincenzo's Pizza Thin Crust
Delivery Areas By Restaurant
Restaurant Delivery Area
A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City
Elite Pizza Capital City
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
In contrast, if the pizza varieties offered by a restaurant sometimes did legitimately vary from one delivery area to another, the original three-column table would satisfy 4NF.
Ronald Fagin demonstrated that it is always possible to achieve 4NF
Thursday, April 14, 2011
Wednesday, April 13, 2011
Tuesday, April 12, 2011
important
i have decided the following lab schedule for dbms :
B22-DBMS LAB on 26/4
B21-DBMS LAB on 3/5
B12-DBMS LAB on 29/4
B11-DBMS LAB on 6/5
if u r not satisfied with this proposal, u can messg me a better one by 9pm today ; the majority satisfaction will be taken into account as the final decision.
i have decided the above considering that no student should have more than 2 lab exams in a week.
JAVA & MP are already finalized.
java :B1-28/4 B2-29/4
MP: B11-26/4 B12-3/5
B21-28/4 B22-5/4
plz get ur bus xerox to class tomorrow.
B22-DBMS LAB on 26/4
B21-DBMS LAB on 3/5
B12-DBMS LAB on 29/4
B11-DBMS LAB on 6/5
if u r not satisfied with this proposal, u can messg me a better one by 9pm today ; the majority satisfaction will be taken into account as the final decision.
i have decided the above considering that no student should have more than 2 lab exams in a week.
JAVA & MP are already finalized.
java :B1-28/4 B2-29/4
MP: B11-26/4 B12-3/5
B21-28/4 B22-5/4
plz get ur bus xerox to class tomorrow.
Monday, April 11, 2011
Thursday, April 7, 2011
Wednesday, April 6, 2011
Sunday, April 3, 2011
Friday, April 1, 2011
Subscribe to:
Posts (Atom)