1NF Relation => 2NF Relations => 3NF Relations => BCNF Relations

Main Concept of BCNF:

Here is the famous quoting for the concept of BCNF: "Each attribute must describe the key, the whole key, and nothing but the key". No FD can be occurred beside the key. This eliminates the redundancy problem found in 3NF. As we know, every key can only occurred once in a relation, if all left hand side of FD can only be key, then it means that NO redundancy can be occurred at all. Therefore, BCNF is the 'perfect' form of redundancy reduction format just by FD method.

Relations in BCNF:

(Notations used in the database)

All relations in 3NF relation schema are already in BCNF. Because they have fulfilled the following properties:

  1. All non-prime attributes are fully dependent.
  2. All prime attributes are fully dependent on keys that they do not belong to.
  3. No attribute is fully dependent on any set of non-prime attributes.
Except the functional dependency over relation AIRLINE, fd2: N ->& CP, as it violates the Property 3 of BCNF while N is non-prime attribute, so it would be eliminated.

Finally, we can have the following relation schema and function dependencies for DD Flight Scheduling System:

ALNAME VARCHAR2(30) Airline name, e.g. 'Cathay Pacific'
ALCODE CHAR(2) Airline code, e.g. 'CX'
PCODE CHAR(4) Parking-area code, e.g. 'PA12'

FD over AIRLINE,
fd1: C -> NP, i.e. a airline code have one airline name and parking area
ALCODE CHAR(2) Airline code, e.g. 'CX'
FNUM NUMBER(3) Flight number, e.g. 808
FMODEL VARCHAR2(30) Flight model, e.g. 'Airbus Industrie A330-300'
FSTATUS CHAR(1) Flight status, e.g. 'A' for active, 'M' for maintenance

FD over FLIGHT,
fd1: CF -> MT, i.e. a airline code and a flight number can determine the flight model
SDATE DATE Scheduling date, e.g. 9 Dec 2001
SSLOT CHAR(9) Scheduling timeslot, e.g. '0000-0015'
RCODE CHAR(4) Runway code, e.g. 'RW03'
ALCODE CHAR(2) Airline code, e.g. 'CX'
FNUM NUMBER(3) Flight number, e.g. 808

FDs over SCHEDULE,
fd1: DSR -> CF, i.e. a runway can have one flight at a particular date and timeslot
fd2: DSCF -> R, i.e. a flight can use one runway at a particular date and timeslot
RCODE CHAR(4) Runway code, e.g. 'RW03'
RSTATUS CHAR(1) Runway status, e.g. 'A' for active, 'M' for maintenance
MDATE DATE Runway last maintenance date, e.g. 9 Dec 2001
MSLOT CHAR(9) Runway last maintenance timeslot, e.g. '0015-0030'

FD over RUNWAY,
fd1: R -> UAL, i.e. a runway code can determine its status and last maintenance date and timeslot

And the ER-Diagram is shown below: