Professional Documents
Culture Documents
Final Dbms Unit II
Final Dbms Unit II
1. What is model?
A. A representation of reality that retains only selected details.
6. What is Aggregation?
A. Aggregation: It is a relationship set viewed as an object set.
· Lines’ linking attributes to entity sets and entity sets to relationship sets.
Like the Hierarchical Data Model the Network Data Model also consists of nodes and
branches, but a child may have multiple parents within the network structure.
The Relational Data Model has the relation at its heart, but then a whole series of
rules governing keys, relationships, joins, functional dependencies, transitive
dependencies, multi-valued dependencies, and modification anomalies.
The Relation
A. Keys
1. A simple key contains a single attribute.
2. A composite key is a key that contains more than one attribute.
ORDER
In order to create a table that is in first normal form we must extract the repeating
groups and place them in a separate table, which I shall call ORDER_LINE.
ORDER
order_id customer_id
123 456
456 789
ORDER_LINE
order_id product
123 abc1
123 def1
123 ghi1
456 abc2
Each row contains one product for one order, so this allows an order to contain any
number of products.
You must also note the use of calculated or derived fields. Take the example where a
table contains PRICE, QUANTITY and EXTENDED_PRICE where EXTENDED_PRICE is
calculated as QUANTITY multiplied by PRICE. As one of these values can be
calculated from the other two then it need not be held in the database table. Do not
assume that it is safe to drop any one of the three fields as a difference in the
number of decimal places between the various fields could lead to different results
due to rounding errors. For example, take the following fields:
· AMOUNT - a monetary value in home currency, to 2 decimal places.
· EXCH_RATE - exchange rate, to 9 decimal places.
· CURRENCY_AMOUNT - amount expressed in foreign currency, calculated as
AMOUNT multiplied by EXCH_RATE.
If you were to drop EXCH_RATE could it be calculated back to its original 9 decimal
places?
Reaching 3NF is adequate for most practical needs, but there may be circumstances
which would benefit from further normalization.
· The keys contain more than one attribute (they are composite keys).
· An attribute is common to more than one key.
Note that no two buildings on any of the university campuses have the same name,
thus ROOM/BLDG CAMPUS. As the determinant is not a candidate key this table is
NOT in Boyce-Codd normal form.
R2(room/bldg, campus)
The relation is in 3NF but not in BCNF because of the following dependencies:
· student# s_name
· course# c_name
1 Programming Golf
1 Programming Bowling
1 Analysis Golf
1 Analysis Bowling
2 Analysis Golf
2 Analysis Gardening
2 Management Golf
2 Management Gardening
This table is difficult to maintain since adding a new hobby requires multiple new rows
corresponding to each skill. This problem is created by the pair of multi-valued
dependencies EMPLOYEE# SKILLS and EMPLOYEE# HOBBIES. A much better
alternative would be to decompose INFO into two relations:
skills(employee#, skill)
hobbies(employee#, hobby)
This is used to track buyers, what they buy, and from whom they buy.
The question is, what do you do if Claiborne starts to sell Jeans? How many records
must you create to record this fact?
The problem is there are pairwise cyclical dependencies in the primary key. That is, in
order to determine the item you must know the buyer and vendor, and to determine
the vendor you must know the buyer and the item, and finally to know the buyer you
must know the vendor and the item.
The solution is to break this one table into three tables; Buyer-Vendor, Buyer-Item,
and Vendor-Item.
This standard was proposed by Ron Fagin in 1981, but interestingly enough he made
no note of multi-valued dependencies, join dependencies, or functional dependencies
in his paper and did not demonstrate how to achieve DKNF. However, he did manage
to demonstrate that DKNF is often impossible to achieve.
Descr Price
101-Keyboard 2000
Mouse 800
Eg:
To retrieve Cust# of Customers who've placed orders in July and in
August
Cust#
003
Eg:
To retrieve Cust# of Customers who've placed orders in July but not in August
Cust#
001
Eg:
Note: The above join operation logically implies retrieval of details of all orders and the
details of the corresponding customers who placed the orders.
Such a join operation where only those rows having corresponding rows in the both
the relations are retrieved is called the natural join or inner join. This is the most
common join operation.
EMPLOYEE
ACCOUNT
A join can be formed between the two relations based on the common column Acc#.
The result of the (inner) join is :
Note that, from each table, only those records which have corresponding records in
the other table appear in the result set. This means that result of the inner join shows
the details of those employees who hold an account along with the account details.
The other type of join is the outer join which has three variations – the left outer
join, the right outer join and the full outer join. These three joins are explained as
follows:
The left outer join retrieves all rows from the left-side (of the join operator) table. If
there are corresponding or related rows in the right-side table, the correspondence
will be shown. Otherwise, columns of the right-side table will take null values.
The right outer join retrieves all rows from the right-side (of the join operator) table.
If there are corresponding or related rows in the left-side table, the correspondence
will be shown. Otherwise, columns of the left-side table will take null values.
(Assume that Acc# 120004 belongs to someone who is not an employee and hence
the details of the Account holder are not available here)
The full outer join retrieves all rows from both the tables. If there is a correspondence
or relation between rows from the tables of either side, the correspondence will be
shown. Otherwise, related columns will take null values.
a1 b1 c1
a2 b2 c2
a3 b3 c3
Thus the result contains those values from R1 whose corresponding R2 values in R3
include all R2 values.