o BCNF is the advance version of 3NF.

It is

stricter than 3NE.

o A table is in BCNF if every functional

dependency X Y, X is the super key of

the table.

o For BCNE, the table should be in 3NE,

and for every FD, LHS is super key.

Example: Let's assume there is a company

where employees work in more than one

department.

EMPLOYEE table:

EMP_ID

264

264

364

364

EMP_COUNTRY EMP_DEPT

India

India

UK

UK

Designing

Testing

Stores

Developing
In the above table Functional dependencies

are as follows:

EMP_ID - EMP_COUNTRY

EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Candidate key: {EMP-ID, EMP-DEPT}

The table is not in BCNF because neither

EMP_DEPT nor EMP_ID alone are keys.

To convert the given table into BCNE, we

decompose it into three tables:

EMP_COUNTRY table:

EMP ID EMP COUNTRY

264

264

India

India

EMP_DEPT table:

EMP DEPT DEPT TYPE EMP DEPT_NO

Designing D394

Testing

Stores

Developing

D394

D283

D283

283
300

232

549

EMP_ID

D394

D394

D283

EMP_DEPT

283

300

232

Candidate keys:

For the first table: EMP_ID

For the second table: EMP_DEPT

For the third table: {EMP_ID, EMP_DEPT}

Now, this is in BCNF because left side part of

both the functional dependencies is a key.

BCNF in DBMS stands for Boyce-Codd

Normal Form which was formed in the

1970s by R.F Boyce and E.F Codd. It isa

technique applied to normalize the table

by remoing any pre-existing redundancy

and anomalies. As a result, it improves

data integrity. Let us learn more about

BCNF in DBMS.

What is BCNF in DBMS?

BCNF in DBMS is a higher level of

normalization than the third normal form

(3NF) and is often known as 3.5NF. It is

based on functional dependencies

between attributes in a relation. Although,

it is very rare that a table satisfies the

criteria for 3NF but does not satisfy

BCNE.

The properties followed by BCNF in

DBMS are aS-

1. It should already follow the

properties of 3NF

2. For a functional dependency, A->B, A

must be a super key or candidate

key.

As stated above in the properties, apart

from already being in 3NE, every non-

trivial functional dependency in the

relation must have a super key as its

determinant. Thus ensuring as a result

that the data is free of redundancy and

consistent.

Conditions for BCNF in DBMS

For a relation to be in BCNF in DBMS, the

following conditions must be met:

1. Every determinant (or candidate key)

of the relation must be functionally

dependent on all the attributes in the

relation.

2. There should be no non-trivial

functional dependencies between

the attributes of the relation, where

non-trivial means that the dependent

attribute is not a subset of any

candidate key.
3. If the relationship has more than one

candidate key, all the candidate keys

must be irreducible, meaning that no

subset of the attributes can

functionally determine any other

attribute.

If the above, conditions are to be met, it is

proved to be a relation that ensures that

there is no redundancy or data

inconsistency in the relation.

Example to Understand BCNF in

DBMS

Now that we have learned about the

basic properties of BCNF in DBMS, let us

move on to look at the example for a

better understanding of BCNF in DBMS

and how BCNF in DBMS functions:

Let us suppose we have a table

containing information about football

clubs around the world with their

respective city, countries, stadium names

and stadium capacities given below:-

Table: Club Details

The primary key in the following table in

the combination of Club Name and

Stadium Name.

Let's suppose we take a functional

dependency (FD) from the table, City ->

Country that justifies the City determines

the Country uniquely. But since there can

be many clubs from the same city, it does

not qualify as a superkey. Hence, the

table does not follow the properties of

BCNF in DBMS.

But there is a way we can turn it into a

BCNF-obeying table. We can decompose

the table into two with one table

consisting of City and Country with the

City set as the Primary Key, the reason

being that there can be multiple cities

from a single country.

Now removing the Country Column from

the City, we can the decomposed two

tables as follows:-

Table: CityCountry

On performing this, the table Club Details

is in BCNF as all the non-trivial functional

dependency has a super key as its

determinant. By decomposinga relation

into smaller tables, we can bring it to

BCNF and improve the overall efficiency

of the database.

Conclusion

In this article, we studied the topic of

BCNE, got to know what is BCNF in

DBMS, the properties it follows, and how

it helps it improve data integrity and

remove redundancy.

Later we moved to study the example of

BCNF in DBMS to solidify the topic

Questions

Some Frequently Asked Questions related

to "BCNF in DBMS" are given below.

1. What is BCNF in DBMS?

BCNF stands for Boyce-Codd Normal

Form, which is a higher level of database

normalization. It ensures that each

determinant of a relation is a candidate

key, which means that all non-trivial

functional dependencies are eliminated.

2. Why is BCNF important in DBMS?

BCNF in DBMS is important because it

helps to eliminate data redundancy and

inconsistencies in a database. By

ensuring that each determinant of a

relation is a candidate key, BCNF in DBMS

helps to prevent update anomalies and

maintain data intearity.

3. How do you check if a relation is in

BCNF?

To check if a relation is in BCNF, you need

to identify all the functional dependencies

in the relation and check if each

determinant is a candidate key. If any

determinant is not a candidate key, then

the relation is not in BCNF and needs to

be decomposed into smaller, normalized

relations.

4. Differentiate between 3NF and BCNF

in DBMS?

3NF (Third Normal Form) and BCNF in

DBMS are both levels of database

normalization, but BCNF is a higher level

than 3NF. 3NF requires that every non-key

attribute is dependent on the primary key,

while BCNF requires that every

determinant of a relation is a candidate

key.

5. When should you use BCNF in

database design?

You should use BCNF in database design

when you need to ensure that each

determinant of a relation is a candidate

key. This is important for maintaining

data integrity and preventing update

anomalies, especially in complex

databases with many interrelated tables.

However, BCNF may not always be

necessary or practical, depending on the

specific requirements of the database

and the trade-offs between normalization

and performance.

6. Is BCNF Normalized table completely

free from redundancy?

If a table has multiple candidate keys, the

data may be duplicated across the

different candidate keys. In addition, in

Some cases, it may be necessary to join

multiple tables together to retrieve all the

Fourth Normal Form

(4NF)
The Fourth Normal Form (4NF) is a

level of database

normalization

where there are no

non-trivial

multivalued dependencies other than

a candidate key. It builds on the first

three normal forms (1NF, 2NF, and

3NF) and the Boyce-Codd Normal

Form_(BCNE). It states that, in

addition to a database meeting the

requirements of BCNF, it must not

contain more than one multivalued

dependency.

Properties

A relation R is in 4NF if and only if the

following conditions are satisfied:

1. It should be in the

Boyce-Codd Normal Form

(BCNF).

2. The table should not have

any Multi-valued Dependency.

A table with

dependency

multivalued
violates

the

normalization standard of the Fourth

Normal Form (4NE) because it creates

unnecessary redundancies and can

contribute to inconsistent data. To

bring this up to 4NF, it is necessary to

break this information into two

tables.

Example: Consider the database

table of a class that has two relations

R1 contains student ID(SID) and

student name (SNAME) and R2

contains course id(CID) and course

name (CNAME).

Table R1

SID->->CID; SID -> ->CNAME;

SNAME ->->CNAME

Join Dependency

Join
decomposition

is

of

further

generalization

dependencies. If the join of R1 and R2

over C is equal to relation R then we

can say that a join dependency ŲD)

exists, where R1 and R2 are the

decomposition R1(A, B, C) and R2(C,

Multivalued

D) of a given relations R (A, B, C, D).

Alternatively, R1 and R2 are

lossless decomposition of R. A JD M

{R1, R2, .., Rn} is said to hold over a

relation R if R1, R2,

lossless-join decomposition. The *(A,

B, C, D), (C, D) will be a JD of R if the

join of joins attribute is equal to the

relation R. Here, *(R1, R2, R3) is used

to indicate that relation R1, R2, R3

and so on are a JD of R. Let R is a

relation schema R1, R2, R3...... Rn be

the decomposition of R. r( R) is said

to satisfy join dependency if and only

if

Fifth normal form (5NF), also known as

projection-join normal form (PJ/NF), is a

level of database normalization designed to

remove redundancy in relational databases

recording multi-valued facts by isolating

semantically related multiple relationships. A

table is said to be in the 5NF if and only if

every non-trivial join dependency in that table

is implied by the candidate keys. It is the final

normal form as far as removing redundancy is

concerned.

A 6NF also exists, but its purpose is not to

remove redundancy and it is therefore only

adopted by a few data warehouses, where it

can be useful to make tables irreducible.

A join dependency *{A, B,. Z} on R is implied

by the candidate key(s) of R if and only if each

of A, B, .., Z is a superkey for R.]

The fifth normal form was first described by

Ronald Fagin in his 1979 conference paper

Normal forms and relational database

Operaters

A relation is said to be in 5NE, if it satisfies

the following conditions:

• It is in 4NE.

• It cannot be further broken down to

smaller tables.

• The decomposed tables join

operation must be lossless, which

means the decomposed tables

joined using natural join should

produce original relation without

loosing any information.

5NF Example

Consider this table, a same course can be

assigned to different teachers.

The problem with this relation is that all

three columns combine together form a

primary key. If you want to add a new

course to the table, the Stu Name and

Stu_Professor fields are empty (null),

which is not acceptable as they are part of

primary key.

This relation is not in 5NF as it contains

redundant data and it can be broken down

to smaller tables.

Let's break it down to three tables like this:

Table 1: Course
Domain key normal form

(DKNF) - There is no Hard and fast rule to

define normal form up to 5NF. Historically the

process of normalization and the process of

discovering undesirable dependencies were

carried through 5NF, but it has been possible

to define the stricter normal form that takes

into account additional type of dependencies

and constraints. The basic idea behind the

DKNF is to specify the normal form that takes

into account all the possible dependencies

and constraints. In simple words, we can say

that DKNF is a normal form used in database

normalization which requires that the

database contains no constraints other than

domain constraints and key constraints. In

other words, a relation schema is said to be in

DKNF only if all the constraints and

dependencies that should hold on the valid

relation state can be enforced simply by

enforcing the domain constraints and the key

constraints on the relation. For a relation in

DKNF, it becomes very straight forward to

enforce all the database constraints by simply

checking that each attribute value is a tuple is

of the appropriate domain and that every key

constraint is enforced. Reason to use DKNF

are as follows:

1. To avoid general constraints in the

database that are not clear key constraints.

2. Most database can easily test or check key

constraints on attributes.

However, because of the difficulty of including

complex constraints in a DKNF relation its

practical utility is limited means that they are

not in practical use, since it may be quite

difficult to specify general integrity

constraints. Let's understand this by taking an

example: Example - Consider relations CAR

(MAKE, Vin#) and MANUFACTURE (vin#,

country), Where vin# represents the vehicle

identification number 'country' represents the

name of the country where it is manufactured.

A general constraint may be of the following

form: If the MAKE is either 'HONDA' or

'MARUTI' then the first character of the vin# is

a 'B' If the country of manufacture is 'INDIA' If

the MAKE is 'FORD' or 'ACCURA, the second

character of the vin# is a 'B" if the country of

manufacture is 'INDIA. There is no simplified

way to represent such constraints short of

writing a procedure or general assertion to

test them. Hence such a procedure needs to

enforce an appropriate integrity constraint.

However, transforming a higher normal form

into domain/key normal form is not always a

dependency-preserving transformation and

these are not possible always.

Advantages of Domain Key Normal

Form:

Improved Data Integrity: DK/NF ensures that

all dependencies and constraints are

preserved, resulting in improved data integrity.

Reduced Data Redundancy: DK/NF reduces

data redundancy by breaking down a relation

into smaller, more focused relations.

Improved Query Performance: By breaking

down a relation into smaller, more focused

relations, query performance can be

improved.

Easier Maintenance and Updates: The

smaller, more focused relations are easier to

maintain and update than the original relation,

making it easier to modify the database

schema and update the data.

Better Flexibility: DK/NF can improve the

flexibility of the database system by allowing

for easier modification of the schema.

Disadvantages of Domain Key Normal

Form:

Increased Complexity: Normalizing a relation

to DK/NF can increase the complexity of the

database system, making it harder to

understand and manage.

Costly: Normalizing a relation to DK/NF can

be costly, especially if the database is large

and complex. This can require additional

resources, such as hardware and personnel.

Reduced Performance: Although query

performance can be improved in some cases,

in others, normalization to DK/NF can result in

reduced query performance due to the need

for additional join operations.

Limited Scalability: Normalization to DK/NF

may not scale well in larger databases, as the

number of smaller, focused relations can

become unwieldy.

Domain Key Canonical Form (DK/NF or

DKNF) is a canonical form used in

database normalization that requires

that the database contains no

constraints other than domain and key

constraints. A domain constraint

specifies the allowable values for a

particular attribute, and a key constraint

specifies the attributes that uniquely

identify rows within a particular table.

Domain/key canonical form is achieved

when all constraints on relationships are

logical consequences of

of key and domain definitions, and enforcing key

and domain constraints and conditions

satisfies all constraints. Thus avoiding

all non-time anomalies. The reason for

using domain/key canonical form is to

avoid having general constraints in the

database that are not explicit domain or

key constraints. Most databases make it

easy to test domain and key constraints

on attributes. However, Common

constraints usually require special

database programming in the form of

stored procedures (often some type of

trigger), which are expensive to maintain

and run on the database. So general

constraints are split into domain

constraints and key constraints. Building

a database in domain/key canonical

form is much easier than converting a

small database that may contain many

anomalies. However, successfully

building a domain/key canonical form

database remains a daunting task, even

for experienced database programmers.

So while domain/key normalization

solves the problems found in most

databases, it tends to be the most

expensive normalization to implement.

However, failing to achieve domain/key

normalization can have long-term

hidden costs due to anomalies that

appear over time in databases that only

stick to lower normalizations. Third

Normal Form, Boyce-Codd Normal Form,

Fourth Normal Form, and Fifth Normal

Form are special cases of domain/key

normal forms. Everything has either a

functional dependency, a multivalued

dependency, or a join dependency that

can be transformed into a superkey.

These canonical forms of domains have

no constraints, so all domain constraints

are satisfied. However, transforming a

higher-order normal form to a

domain/key normal form is not always a

dependency-preserving transformation,

and is therefore not always possible.

Example

DKNF Violations occur in the following

table. (We assume that the wealthy

person domain consists of the names of

all wealthy people in a predefined

sample of wealthy people.

and

"Millionaire", and the net worth domain

consists of all integers greater than or

equal to 1,000,000 in dollars.) Even

though you cant infer one from the

other, there are constraints that tie

wealth type and net worth in dollars.

This constraint determines that

millionaire's net worth is between

1,000,000 and 999,999,99 9 and that a

billionaire's net worth is greater than or

equal to 1,000,000,000. This constraint

is neither a domain constraint nor a key

constraint. Therefore, we cannot rely on

domain or key constraints to ensure that

inconsistent combinations of HNW type

and net worth in dollars do not enter the

database. The DKNF violation can be

resolved by removing the "High Net

Worth Type" column. Your wealthy

status as a millionaire or millionaire is

determined by your net worth in dollars

as defined in the Wealthy Status table,

● so no useful information is lost.