Question

Normalizing schema to third normal form (3NF) ,no coding needed! SHIPPING (ShipName, ShipType, VoyageID, Cargo, Port, ArrivalDate) Key: ShipName, ArrivalDate FD1: ShipName > ShipType FD2: VoyageID > ShipName, Cargo FD3: ShipName, ArrivalDate > VoyageId, Port

1.Normalize SHIPPING to 3NF showing PKs, any FKs, functional dependencies. Show the normal form of the schema at each step in the process (e.g. 2NF?, 3NF?).

2..Please list the final set of 3NF schema including all its keys.

3 .Do any of the finalized 3NF schema have determinates that are not candidate keys? If yes, explain - which schema(s)? Why?

Answer 1

1.

SHIPPING (ShipName, ShipType, VoyageID, Cargo, Port, ArrivalDate) IS THE GIVEN RELATION.

Key: ShipName, ArrivalDate

FD1: ShipName > ShipType

FD2: VoyageID > ShipName, Cargo

FD3: ShipName, ArrivalDate > VoyageId, Port

ISSUES IN 3NF :::

STEP :01     1. IT MUST BE IN 1NF

       EXPLANATION : There doesn't exist any two identical rows in a given relation or table.

IN GENERAL EVERY RELATION IS IN 1NF. SO THE GIVEN RELATION IS ALSO IN 1NF.

       STEP :02 2. IT MUST BE IN 2NF

        EXPLANATION : THERE DOESN'T EXIST ANY PARTIAL DEPENDENCIES.

        PARTIAL DEPENDENCY : A NON-PRIME ATTRIBUTE MUST NOT BE DEPENDENT ON A NON-PRIME   

       ATTRIBUTE.

        i,e., THERE SHOULD NOT BE ANY FD IS OF THE FORM

        NON-PRIME -----> NON-PRIME

        PRIME ATTRIBUTE : A PRIME ATTRIBUTE IS THE PROPER SUB SET OF A KEY (CANDIDATE KEY).

        NON PRIME ATTRIBUTES : ATTRIBUTES WHICH ARE NOT PRIME ATTRIBUTES.

        CANDIDATE KEY : IT A ATTRIBUTE OR SET OF ATTRIBUTES WHICH HELPS TO UNIQUELY IDENTIFY EACH ROW IN A RELATION.

        PRIME ATTRIBUTES FOR THE GIVEN RELATION : SHIPNAME , ARRIVALDATE

        NON PRIME ATTRIBUTES FOR THE GIVEN RELATION : ShipType, VoyageID, Cargo, Port

        CANDIDATE KEY FOR THE GIVEN RELATION : (SHIPNAME , ARRIVALDATE)

       EXAMINING THE FUNCTIONAL DEPENDENCIES IN THE GIVEN RELATION :

        IN FD 1 ::::: FD1: ShipName > ShipType   [PRIME > NON-PRIME ] [ SO NO PARTIAL DEPENDENCY]

        IN FD 2 ::::: FD1: VoyageID > ShipName, Cargo

        i.e,. BY LAW OF DECOMPOSITION

             VoyageID > ShipName   [NON-PRIME > PRIME] [SO NO PARTIAL DEPENDENCY]

              VoyageID > Cargo         [NON-PRIME > NON-PRIME] [SO PARTIAL DEPENDENCY]

       SO HERE WE DECOMPOSE THE RELATIONS SUCH THAT THERE IS NO PARTIAL DEPENDENCIES IN ALL

        RELATIONS .

        THEREFORE SHIPPING (ShipName, ShipType, VoyageID, Cargo, Port, ArrivalDate)

       WITH FUNCTIONAL DEPENDENCIES :

        FD1: ShipName > ShipType

        FD2: VoyageID > ShipName, Cargo

        FD3: ShipName, ArrivalDate > VoyageId, Port

       WILL DECOMPOSE INTO R1(VoyageID , Cargo) AND R2(ShipName, ShipType, Port, ArrivalDate,VoyageId)

       NOW R1 HAS THE KEY VoyageID AND R2 HAS THE KEY (ShipName, ArrivalDate)

       NOW IN BOTH THE RELATIONS THERE ARE NO PARTIAL DEPENDENCIES.

       HERE WE ARCHIVED IT BY DECOMPOSING THE GIVEN RELATION INTO SEVERAL RELATIONS

       WHEN THERE EXIST A PARTIAL DEPENDENCY.

     NO THE GIVEN RELATION IS IN 2NF.

      

STEP :03 :::: 3. THERE DOESN'T EXIST ANY PARTIAL DEPENDENCIES :

       TRANSITIVE DEPENDENCY : A NON-PRIME ATTRIBUTE MUST NOT BE DEPENDENT ON A PRIME ATTRIBUTE.

        i,e., THERE SHOULD NOT BE ANY FD IS OF THE FORM

        PRIME -----> NON-PRIME

        EXAMINING THE FUNCTIONAL DEPENDENCIES IN R1: R1(VoyageID , Cargo)

        IN R1 THERE IS ONLY ONE FUNCTIONAL DEPENDENCY VoyageID > Cargo [KEY --- > NON-PRIME]

        [SO NO TRANSITIVE DEPENDENCY]

       EXAMINING THE FUNCTIONAL DEPENDENCIES IN R2:

        R2(ShipName, ShipType, Port, ArrivalDate ,VoyageId)

       FD1: ShipName > ShipType   [PRIME ---- > NON-PRIME] [TRANSITIVE DEPENDENCY]

       SO WE DECOMPOSE THE RELATION R2 SUCH THAT THERE IS NO TRANSITIVE DEPENDENCY.

       SO THE RELATION R2 BECOMES R2(ShipName, ShipType) AND

        R3(ShipName, Port, ArrivalDate ,VoyageId)

       NOW IN R2 ShipName is the key and in R3 (ShipName , ArrivalDate) is the key

     

       FD2: VoyageID > ShipName [NON-PRIME ---- > PRIME] [ NO TRANSITIVE DEPENDENCY]

      FD3: ShipName, ArrivalDate > VoyageId, Port [KEY ---- > NON-PRIME] [ NO TRANSITIVE DEPENDENCY]

     NO THE GIVEN RELATION IS IN 3NF .

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2. Final set of 3NF schema including all its keys

R1(VoyageID , Cargo) , R2(ShipName, ShipType) , R3(ShipName, Port, ArrivalDate ,VoyageId)

     IN R1 :::::

    FUNCTIONAL DEPENDENCIES ::: VoyageID > Cargo

    PRIMARY KEY :::: VoyageID

   FOREIGN KAY :::: VoyageID   FROM R3

    IN R2 ::::::

    FUNCTIONAL DEPENDENCIES ::: ShipName > ShipType

    PRIMARY KEY :::: ShipName

   FOREIGN KAY :::: ShipName FROM R3

    IN R3 :::::::::

    FUNCTIONAL DEPENDENCIES ::: VoyageID > ShipName AND ShipName, ArrivalDate > VoyageId, Port

    PRIMARY KEY ::::ShipName, ArrivalDate

   FOREIGN KAY :::: NO FOREIGN KEY

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

3 . YES , any of the finalized 3NF schema have determinants that are not candidate keys because here in 3NF we are only restricting the functional dependencies of the form [prime --- > non-prime ] and

[non-prime ---- > non-prime] but not [prime ---- > prime ] or [non-prime ---- > prime].

So here for every finalized 3NF there is a chance of determinants that are not candidate keys but prime or non-prime attributes depending upon the given functional dependencies in the given relation.

HERE FOR THE GIVEN RELATION WHICH IS FINALLY IN 3NF HAS DETERMINANT VoyageID in the functional dependency VoyageID > ShipName.

PLEASE DO VOTE : )