Database Systems; extra credit project
Fall Semester 2004
  Winter Style | Home » Old » School Projects » Database Systems project
 
 

Besides learning all about database theory and implementation, I created a neat little program to perform several standard database algorithms. Among these are Attribute Closure (X+), Third Normal Form, Boyce-Codd Normal Form, Canonical/Minimal Cover, and Functional Dependency Loss Checking.

If you aren’t already familiar with schema normalization or functional dependencies (the main function of the program), take a look at the quick overview I put together below. Otherwise, you can start playing around with the program. You can input schemas as lists of functional dependencies of the form "start attributes > determined attributes", where the attributes are comma-separated lists (i.e. "A,B > C").

A database schema is composed of a set of attributes and a set of functional dependencies. An attribute is basically a column in one of the database’s tables. A functional dependency indicates that a set of attributes determines another set of attributes. Normalization deals with reorganizing the functional dependencies of a schema so that data repetition, insertion and deletion anomalies, and other problems are removed.

For example, lets say you have a schema with the following set of attributes: {SupplierName, SupplierAddress, ItemNumber, ItemPrice} :for keeping track of suppliers, the items they supply, and the prices associated with a given supplier and its items. Each supplier is associated with an address, which creates the functional dependency {SupplierName} -> {SupplierAddress} (i.e. given a supplier, a unique address can be determined). Similarly, given a supplier and an item, you can determine its price, which creates the functional dependency {SupplierName, ItemNumber} -> {ItemPrice}. Since you need both SupplierName and ItemNumber to determine all of the attributes in the schema, {SupplierName, ItemNumber} is the only candidate key (a minimal set of attributes that determines all of the other attributes in a schema) for the schema, making it the primary key (a candidate key chosen as the unique identifier of a table in a database).

SupplierName
SupplierAddress
ItemNumber
ItemPrice
Bob’s Bargains
123 Fake Street
1
$ 5
Bob’s Bargains
123 Fake Street
2
$ 3
Jake’s Junk
5 Boulevard Ave
1
$ 4
There are several problems with this schema, as can be seen in the example at right. For example, for every item a supplier offers, we have to repeat the supplier’s address. If the address changes, we have to search the entire table and change each entry. To fix this, normalization algorithms, such as 3NF and BCNF, can be used. Here, 3NF would split the schema into two separate schemas, one for each functional dependency: {SupplierName, SupplierAddress} with {SupplierName} -> {SupplierAddress}, and {SupplierName, ItemNumber, ItemPrice} with {SupplierName, ItemNumber} -> {ItemPrice}.

 
 
Go back a page |  Schema Normalizer,  Source Code | Resume Entry | @ | Copyright © 2004-2011 Paul A Hansen. Some rights reserved.