NORMALLEŞTİRME

•Normalleştirmenin amacı
•Veri fazlalığı ile bağlı sorunlar
•Güncelleme sapmaları (anomalileri)
•İşlevsel bağımlılıklar
•İlişkilerin normal biçimleri
•Normalleştirme süreci
•Yaygın Kullanılan Normal Biçimler
Tasarım sürecinde Normalleştirmenin yeri
Kavramsal Adım 1: ER-İlişki
tasarım dönüşümü

Kavramsal Şema
(ER Model)

Mantıksal Tasarım Adım 2: Normalleştirme:

Tasarımı geliştirme

Mantıksal Şema
(İlişkisel Model
İlişkisel Tasarım İlkeleri

• İlişkilerin anlamsal bütünlüğü olmalıdır

• Veri tekrarlanmaları önlenmelidir:
– sapmalar: ekleme, silme, değişiklik yapma
• Null değerlerden mümkün oldukça
kaçınılmalıdır
– Yorumlama zorluğu:
• Belli değil, erişile bilen değil, uygulana bilen değil
• Yapay birleşmelrden kaçınılmalıdır
Normalleştirme
İlişkisel veri tabanlarının geliştirilme aşaması olan mantıksal
veri modelinin oluşturulmasında başlıca hedef, verilerin,
veriler arasındaki ilişkilerin ve sınırlamaların kesin, tam
ifade edilmesidir. Bu hedefe ulaşmak için uygun ilişkiler
kümesi tanımlanmalıdır. Böyle ilişkilerin tanımlanması
işlevine normalleştirme denir.

Normalleştirme- veri gereksinimlerinde tanımlanmış olan,

arzu olunan nitelikleri bulunan ilişkiler kümesinin üretilmesi
sürecidir.
 Normalleştirme (devamı)
• Kötü tasarlanmış veri tabanlarının, sapmalar nedeniyle kullanım
zorlukları bulunmaktadır:
Sapmalar:
– Değiştirme –özelliğin değerinin değiştirilmesi veri tabanının
tutarsızlığına neden ola bilir
– Ekleme – bazı tasarım kusurlarından dolayı satır eklenmesi
mümkün olmaya bilir
– Silme - satır silinmesi bilgilerin beklenmeyen kaybına neden
ola bilir
• Normalleştirme tüm bu sapmaların kaldırılması için veri tabanı
tasarımında yapılan düzenli süreçtir.
 Değiştirme Sapması (örnek)
ŞİRKETLER(şirket_adı, şirket_adresi,kuruluş_tarihi, sahip_adı, sahiplik_belgesi, pay )

• Eğer şirketin üç sahibi varsa, ŞİRKETLER ilişkisinde bu

şirket için üç satır olacaktır
• Eğer bu şirket yeni adrese taşınmış olsa, şirketin adresi
her üç satırda uyumlu biçimde değiştirilmelidir.
– Şirketin yeni adresinin her üç satırda değil, bir veya
iki satırda kaydedilmesi veya yanlış kaydedilmesi veri
tabanının tutarsız durumuna neden olacaktır.
 Ekleme Sapması (örnek)
ŞİRKETLER(şirket_adı, şirket_adresi,kuruluş_tarihi, sahip_adı, sahiplik_belgesi,
pay )

• Varsayalım ki, üç kişi yeni şirket kuruyor:

– Üç kurucunun henüz sahiplik belgeleri (titles) yoktur
– Sermaye hisseleri henüz paylaştırılmayıp
• Yeni şirket ŞİRKETLER ilişkisine ilave edilemez,
çünkü satırın tüm özelliklerini değerlendirmek için
yeterli bilgi yoktur.
– satırı tamamlamak için null değer kullanılmalıdır
 Silme Sapması (örnek)
ŞİRKETLER(şirket_adı, şirket_adresi, kuruluş_tarihi, sahip_adı,
sahiplik_belgesi, pay )

• Varsayalım ki, şirketin sahiplerinden birisi belirli bir süre için

sahiplikten çekilmiştir. Ama hisseleri şirkette kalmaktadır.
• Eğer bu kişiye ait satır ŞİRKETLER ilişkisinden silinirse, onun
şirkette ne kadar hissesi olduğu hakkında bilgiyi de kaybetmiş
oluruz.
Veri Fazlalığı ve Güncelleme Sapmaları
(örnek)
 Staff_Branch ilişkisinde güncelleme sapmaları (ekleme)

• 1. Varsayalım ki, Branch_Staff ilişkisine yeni personelin kayıtları eklenmelidir.

Bu halde personelin çalışacağı şubenin bilgileri de girilmelidir. Örneğin, yeni
personel B7 şubesine kabul edilmişse, bu şubenin bilgileri öyle kaydedilmelidir ki,
bu bilgiler B7 şubesi bilgileri bulunan diğer satırlardaki bilgilerle aynı olsun, yani
veri tutarsızlığı oluşmasın. Bu muhtemel hatanı önlemek için Staff_Branch
ilişkisinin iki ilişkiye parçalanması (Staff ve Branch) gerekmektedir.

• 2. Varsayalım ki, yeni şube oluşturulmuş, ama bu şubeye henüz personel

atanmamıştır. Personel bilgileri yerine null değerler yazıla bilir. Ama Staff_No
ilişkide birincil anahtar olduğundan null değer alamaz. Bu ikilemi önlemek için
Staff_Branch ilişkisinin iki ilişkiye parçalanması (Staff ve Branch) gerekmektedir.

Staff_Branch(Staff_No,SName,SAddress, Position, Salary,

Banch_no,BAddress, Tel_No)
Staff_Branch ilişkisinde güncelleme sapmaları
(silme)
• 1. Varsayalım ki, Branch_Staff ilişkisinden şubede çalışan
sonuncu personel hakkındaki bilgiler de silinmelidir Ama
bu bilgilerin silinmesi, şube hakkındaki bilgilerin de
kaybına neden olacaktır.(böyle ki, bu şube hakkında
bilgiler ilişkinin diğer hiçbir satırında bulunmuyor).
Örneğin, ilişkiden SA9 (Mary Howe) bilgilerinin silinmesi
ile B7 şubesi hakkındaki bilgileri de kaybedeceğiz. Bu
olası itkileri önlemek için Staff_Branch ilişkisinin iki
ilişkiye parçalanması (Staff ve Branch) gerekmektedir.

Staff_Branch(Staff_No,SName,SAddress, Position, Salary,

Banch_no,BAddress, Tel_No)
Staff_Branch ilişkisinde güncelleme sapmaları
(güncelleme)

– Varsayalım ki, Branch_Staff ilişkisinden her hangi bir

şubenin bir veya birkaç özellik değerini değiştirmek
gerekmektedir.Örneğin, B7 şubesinin telefon
numarası değiştirilmelidir. Bunun için ise Staff_Branch
ilişkisindeki B7 şubesinde çalışan personellere uygun
tüm satırlar güncellenmelidir. Eğer tüm gereken
satırlar güncellenmezse bu veri tabanının
tutarsızlığına neden olacaktır.Yani, B7 şubesi
hakkındaki bilgileri içeren farklı satırlarda şubenin
telefon numaraları farklı görünecektir.

Staff_Branch(Staff_No,SName,SAddress, Position, Salary,

Banch_no,BAddress, Tel_No)
 Veri Fazlalığı ve Güncelleme Sapmaları
(devamı)

•Ekleme anormalliği
•Silme Anormalliği
•Değiştirme anormalliği
 Ne yapmalı?
• Mantıksal tasarım sürecinde oluşturulmuş her bir veri
ilişkisini ayrılıkta gözden geçirmeli ve arzu olunan
niteliklere ulaşmak için ilişkileri “iyileştirmeli”
– Normal biçimler
• Atomik değerler (1NF)
• Anahtarlara ve bağımlılıklara göre tanımlana bilir.
• İşlevsel bağımlılıklar ( 2NF, 3NF, BCNF)

– Normalleştirme
• Normalleştirme,”yukarıdan aşağıya” metodolojisinin
uygulandığı ve ardışık parçalamalar ve arındırmalar yolu ile
yeni ilişkilerin oluşturulduğu tasarım sürecidir.
Normalleştirme sorunları
• Şema arzu olunan normal biçimlere nasıl parçalanmalıdır?
• Kaynak şemanın anlamsal bütünlüğünü korumak için parçalanmış
şemalara hangi kıstaslar koyulmalıdır?
– Yeniden yapılabilirlik: kaynak şemanın yeniden elde edilmesi 
yapay bitiştirmeler yoktur
– Parçalamada kayıp olmaması: bilgi kaybı yoktur
– Kısıtlamaların korunması: kaynak şemada bulunan kısıtlamalar
parçalanmış ilişkilerde tanımlanan kısıtlamalarla uygulanabilir
olmalıdır.
• Bitiştirme işlemlerinden dolayı sorguların işlem süresi
yükseliyor
İşlevsel Bağımlılıklar
İşlevsel bağımlılık- ilişkideki özellikler
arasındaki bağlantıları ifade ediyor.
Eğer A ve B, R ilişkisinin özellikleri ise ,
ve A’nın her bir değerine B’nin kesin bir
değeri uygun ise B işlevsel olarak A’ya
bağımlıdır.(A B)

A B
B, A’ya işlevsel
bağımlıdır
İşlevsel Bağımlılıklar
• İşlevsel bağımlılık ilişkisel veri tabanının iki özellikler
kümesi arasındaki kısıtlamayı ifade ediyor.

• Eğer X ve Y aynı T ilişkisinin özellikleri kümeleri ise, o

zaman X  Y , X’in işlevsel olarak Y’ni tanımlaması
anlamını veriyor:
– X’deki özellik değerleri Y’deki özellik değerlerini
tekdeğerli tanımlar
– T’deki her hangi iki t1 ve t2 satırları için t1[X] = t2[X]
olması t1[Y] = t2[Y] anlamına gelir
(Eğer T ilişkisinin iki satırı X sütunu(sütunları)üzere aynıdırsa, onların Y
sütunu(sütunları) da aynı olmalıdır)
İşlevsel bağımlılıklar
ŞİRKETLER(şirket_adı, şirket_adresi,
kuruluş_tarihi, sahip_adı,
sahiplik_belgesi, pay )

şirket_adı  şirket adresi

şirket_adı  kuruluş_tarihi
şirket_adı, sahip_id  sahiplik_belgesi
şirket_adı, sahip_id  pay
şirket_adı, sahiplik_belgesi  sahip_id
sahip_id  sahip_adı
İşlevsel Bağımlılıklar
• Belirleyici- bağımlılık işaretinin solundaki özellik veya
özellikler grubuna işlevsel bağımlılığın belirleyicisi denir

Position Staff_no’ya işlevsel bağımlıdır

Staff_No Position

Staff number SL21 Manager

Staff_no Position’a işlevsel bağımlı değil

Position X Staff_No
Staff Number SL21
Manager
Staff Number SG5
Staff-Branch İlişkisi üzere işlevsel
bağımlılıklar

Staff_No SName Branch_No BAddress

Staff_No SAddress Branch_No Tel_no
Staff_No Position BAddress Tel_No
Staff_No Salary BAddress Branch_No
Staff_No Branch_No
Staff_No BAddress Tel_No Branch_No
Staff_No Tel_No Tel_No BAddress
Staff_No,Branch_No,BAddress , Tel_No belirleyicilerdir.
(Her şubenin bir telefonu olduğunu varsayıyoruz)

Staff_Branch (Staff_No,SName,SAddress, Position, Salary,

Banch_no,BAddress, Tel_No)
Normal Biçimler arasında bağlılık
 Tekrarlanan Gruplar
Tekrarlanan grup, birincil anahtar değeri için birden fazla
değeri bulunan özellik veya özellikler kümesidir

Örnek: aşağıdaki örnekte şube ve personel bilgileri ,her bir personelle irtibat
telefonları verilmiştir. (contact number –tekrarlanan gruptur)
staffNo job dept dname city contact number
SL10 Salesman 10 Sales Stratford 018111777, 018111888, 079311122
SA51 Manager 20 Accounts Barking 017111777
DS40 Clerk 20 Accounts Barking
OS45 Clerk 30 Operations Barking 079311555

Tasarımda Tekrarlanan gruplara izin verilmez, tüm özellikler bölünmez

olmalıdır,yani tablonun her hücresinde tek bir değer bulunmalıdır
Normalolmayan biçim- Unnormalized
Form -(UNF)
• Bir veya daha fazla tekrarlanan gruplar
içeren ikiboyutlu tablo normal olmayan
tablodur

• Normal olmayan tablo oluşturmak için

– Bilgi kaynaklarından verileri ikiboyutlu
tabloya aktarmak yeterlidir.
Birinci Normal Biçim

• Normal olmayan biçim (unnormalized form)-UNF-

tablonun satırlarında özellik veya özellikler
çokdeğerli ifade edilmişse böyle tablo normal
olmayan biçimdedir

• Birinci normal biçim (1NF) -ilişkinin her hücresi

(satır ve sütunların kesişmesi) yalnız ve yalnız bir
değer içeriyorsa, bu ilişki birinci normal
biçimdedir.
UNF’den 1NF’e dönüştürme

• Normalleştirilmemiş tablon için anahtar

olacak özellik veya özellikler kümesini
belirlemeli.

• Normal olmayan tablodaki tekrarlanan

grubun her öğesini anahtarla bir yerde
tanımlamalı (gruptaki her değer için
anahtarı tekrarlamalı)
UNF’den 1NF’e dönüş

• Tüm anahtar özellikler

tanımlanmıştır
• Tabloda tekrarlanan gruplar yoktur
• Tüm özellikler birincil anahtara
bağımlıdır
İkinci Normal Biçim (2NF)
• Tam işlevsel bağımlılk kavramına dayalıdır:
– A ve B ilişkinin özellikleridir,
– B özelliği A özelliğine işlevsel bağımlı olup A’nın her
hangi altkümesine bağımlı değilse o zaman B, A’ya
tam bağımlıdır,
• 2NF – Birinci normal biçimde olup her bir
birincil anahtar olmayan özellikleri birincil
anahtardan tam bağımlı ise (kısmı bağımlılığın
olmaması) bu ilişki ikinci normal biçimdedir
1NF’den 2NF’e dönüştürme

• 1NF ilişkisi için birincil anahtarı tanımlamalı

• İlişkideki işlevsel bağımlılıkları tanımlamalı

• Eğer birincil anahtar üzere kısmı bağımlılıklar

varsa bu bağımlılıkları oluşturan özellikleri
onların belirleyicilerinin kopyası ile yeni bir
ilişkiye taşımalı
 İkinci Normal Biçim
• Tam işlevsel bağımlılık- A ve B ilişkinin özellikleri ise, eğer
B, işlevsel olarak A’ya bağımlı ise, ama A’nın her hangi alt
kümesine bağımlı değilse, o zaman B özelliği A özelliğine
tam işlevsel bağımlıdır
• A ve B özellikleri (özellikler kümeleri) işlevsel bağımlı ise
(A B) ve A özellikler kümesinden her hangi özelliğin
çıkarılması bu bağımlılığı bozmazsa, A B bağımlılığına
kısmı bağımlılık denir

Staff_No,SName Branch_No
Bağımlılğı tam işlevsel bağımlılık değil, çünkü, Branch_no
aynı zamanda Staff_No özelliğine de işlevsel bağımlıdır.
İkinci Normal Biçim
• Eğer ilişki birinci normal biçimde ise ve her bir
birincil anahtar olmayan özellik birincil
anahtardan tam işlevsel bağımlı ise , bu ilişki
ikinci normal biçimdedir (2NF)

• 1NF’den 2NF’e geçmek için kısmı bağımlılıklar

kaldırılmalıdır.
 Customer-Rental
Customer_No
ilişkisinin
Property_no CName
2NF’e Rent
PAddress Rent
dönüştürülmesi
Rent Owner_no OName
Start Finish

Customer_No,Property_No özellikler kümesini

birincil anahtar olarak kabul ettiğimizi varsayıyoruz

• İşlevsel bağımlılıklar
Fd1 Customer_No,Property_No  RentStart,
RentFinish (tam bağımlılık)
Fd2 Customer_No  CName (kısmı bağımlılık)
Fd3 Property_No  PAdderss,Rent,Owner_No,
OName (kısmı bağımlılık)
Fd4 Owner_No  Owner_name (dolaylı bağımlılık)
FD5 Customer_No,RentStart  Property_no,
PAdderss,RentFinish, Rent, Owner_No,OName (aday anahtara bağımlılık)
Fd6 Property_No,RentStart  Customer_no,
CName,RentFinish (aday anahtara bağımlılık)
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Fd1 Birincil anahtara

tam bağımlık
Fd2
Kısmı bağımlılık

Fd3
Kısmı bağımlılık

Fd4 d.b

Fd5
Aday anahtara
bağımlılık
Fd6
Aday anahtara bağımlılık
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Kısmı bağımlılık
Fd2
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Fd1 Birincil anahtar

 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Kısmı bağımlılık

Fd3
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Fd4
Dolaylı bağımlılık
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Fd5
Aday anahtar
 Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar

Customer_No Property_no CName PAddress Rent Rent Rent Owner_no OName

Start Finish

Fd6

Aday anahtar
Customer-Rental İlişkisinin 2NF’e
dönüştürülmesi
Customer_Rental İlişkisinin 2NF’e
dönüştürülmesi

• Customer_Rental (Customer_No,Property_No,
CName, PAddress, RentStart,
RentFinish, Rent, Owner_No,OName)

• Customer_No (Customer_No,CName)
• Rental (Customer_No,Property_No,
RentStart,RentFinish)
• Property_Owner(Property_No, PAddress,Rent,
Owner_No,OName)
Üçüncü Normal Biçim (3NF)

• Dolaylı bağımlılık kavramına dayanmaktadır:

– A, B ve C ilişkinin özellikleridir; A  B ve B  C ise
O zaman C A’dan B özelliği aracılığıyla dolaylı bağımlıdır

• 3NF - 1NF ve 2NF de olup, birincil anahtar

olmayan özelliklerinin birincil anahtara dolaylı
bağımlı olmadığı ilişkidir.
2NF’den 3NF’e dönüştürme
• Birincil anahtarı 2NF’de tanımlamalı

• İlişkideki işlevsel bağımlılıkları tanımlamalı.

• Eğer birincil anahtara işlevsel bağımlılık varsa

bu bağımlılığı oluşturan özellikleri
belirleyicilerinin kopyası ile birlikte yeni bir
ilişkiye taşımalı
3NF’e dönüştürme sonuçları

• Prevent referential integrity violation by

adding a JOB_CODE
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CODE, JOB_DESCRIPTION, CHG_HOUR)
 Üçüncü Normal Biçim
• Dolaylı bağımlılık- A, B ve C ilişkinin özellikleri
ise ve A  B ve B  C ise, o zaman C,
A’dan B aracılığıyla dolaylı bağımlıdır.

Staff_No  Branch_No
Branch_NoBAddress

Üçüncü normal biçim (3NF)- eğer ilişki birinci ve ikinci

normal biçimde ise ve birincil anahtar olmayan
özellikler birincil anahtardan dolaylı bağımlı değilse ,
bu ilişki üçüncü normal biçimdedir
Üçüncü Normal Biçim
• Customer, Rental ve Property_Owner ilişkilerindeki işlevsel
bağımlılıklar :
• Customer ilişkisi
Fd2 Customer_No  CName

Rental İlişkisi
Fd1 Customer_No,Property_No  RentStart,RentFinish
FD5 Customer_No,RentStart  Property_no, RentFinish
Fd6 Property_No,RenStart  Customer_no, RentFinish

Property_Owner İlişkisi
Fd3 Property_No Paddress, Rent,Owner_No,OName
Fd6 Owner_No  OName

Customer ve Rental ilişkilerinde dolaylı bağımlılık yoktur. Tüm birincil olmayan

özellikler birincil anahtara işlevsel bağımlıdır
 Property_Owner ilişkisinin 3NF’e
dönüştürülmesi
• Property_Owner ilişkisinde OName özelliğinin dışında tüm özellikler birincil anahtara
işlevsel bağımlıdır. OName ise aynı zamanda Owner_No’ya bağımlıdır (Fd4).
• 3NF’e dönüştürmek için dolaylı bağımlılık kaldırılmalıdır. Bunu 2 yeni ilişki
oluşturmakla yapa bileriz:
• Property_for_Rent (Property_No,PAdderss,Rent,Owner_No)
• Owner (Owner_No,OName)
Customer_Rental tablosunun 1NF’den 3NF’e
dönüştürülmesi

Customer_Rental 1NF

Property_Owner 2NF

Customer Rental Property_for_rent Owner 3NF

Customer_Rental tablosunun 3NF ilişkilerinin
alınması
ŞİRKETLER ilişkisinin normalleştirme sonuçu
parçalanması
ŞİRKET1(şirket_adı, şirket_adresi, kuruluş_tarihi,
sahip_id, sahip_belgesi, pay)
Şirket_adı  şirket_adresi, kuruluş_tarihi
Şirket_adı, sahip_id  sahip_belgesi, pay
Şirket-adı, sahip_belgesi  sahip_id

Şirket2(sahip_id, sahip_adı)
sahip_id  sahip_adı

Şirket1 yeniden parçalanıyor:

Şirket1(şirket_adı, şirket_adresi, kuruluş_tarihi)
Şirket12(şirket_adı, sahip_id, sahip_belgesi, pay)
 Stages of Normalisation
Unnormalised
(UDF)
Remove repeating groups
First normal form
(1NF)
Remove partial dependencies
Second normal form
(2NF)
Remove transitive dependencies
Third normal form
(3NF)
Remove remaining functional
dependency anomalies
Boyce-Codd normal
form (BCNF)
Remove multivalued dependencies
Fourth normal form
(4NF)
Remove remaining anomalies
Fifth normal form
(5NF) 50
 Unnormalised Normal Form (UNF)
Definition: A relation is unnormalised when it has not had any
normalisation rules applied to it, and it suffers from various
anomalies.

This only tends to occur where the relation has been

designed using a ‘bottom-up approach’. i.e., the capturing of
attributes to a ‘Universal Relation’ from a screen layout,
manual report, manual document, etc...
 Unnormalised Normal Form (UNF)
ORDER
Customer No: 001964 Order Number: 00012345
Name: Mark Campbell Order Date: 14-Feb-2002
Address: 1 The House
Leytonstone
E11 9ZZ

Product Product Unit Order Line

Number Description Price Quantity Total
T5060 Hook 5.00 5 25.00
PT42 Bolt 2.50 10 20.50
QZE48 Spanner 20.00 1 20.00

Order Total: 65.50

ORDER (order-no, order-date, cust-no, cust-name, cust-add,

(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total
 First Normal Form (1NF)
Definition: A relation is in 1NF if, and only if, all its
underlying attributes contain atomic values only.
Remove repeating groups into a new relation

A repeating group is shown by a pair of brackets within the relational schema.

ORDER (order-no, order-date, cust-no, cust-name, cust-add,

(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total

Steps from UNF to 1NF:

• Remove the outermost repeating group (and any nested repeated
groups it may contain) and create a new relation to contain it.
• Add to this relation a copy of the PK of the relation immediately
enclosing it.
• Name the new entity (appending the number 1 to indicate 1NF)
• Determine the PK of the new entity
• Repeat steps until no more repeating groups.
 Example - UNF to 1NF
ORDER (order-no, order-date, cust-no, cust-name, cust-add,
(prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total

1. Remove the outermost repeating group (and any nested repeated groups it may
contain) and create a new relation to contain it. (rename original to indicate 1NF)
ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total
(prod-no, prod-desc, unit-price, ord-qty, line-total)
2. Add to this relation a copy of the PK of the relation immediately enclosing it.
ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total
(order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
3. Name the new entity (appending the number 1 to indicate 1NF)
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
4. Determine the PK of the new entity
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
 Second Normal Form (2NF)
Definition: A relation is in 2NF if, and only if, it is in 1NF and
every non-key attribute is fully dependent on the primary key.
Remove partial functional dependencies into a new relation

Steps from 1NF to 2NF:

• Remove the offending attributes that are only partially
functionally dependent on the composite key, and place
them in a new relation.
• Add to this relation a copy of the attribute(s) which are
the determinants of these offending attributes. These will
automatically become the primary key of this new
relation.
• Name the new entity (appending the number 2 to indicate 2NF)
• Rename the original entity (ending with a 2 to indicate 2NF)
 Example - 1NF to 2NF
ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)
1. Remove the offending attributes that are only partially functionally dependent on
the composite key, and place them in a new relation.
ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total)

(prod-desc, unit-price)
2. Add to this relation a copy of the attribute(s) which determines these offending
attributes. These will automatically become the primary key of this new relation..
ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total)
(prod-no, prod-desc, unit-price)
3. Name the new entity (appending the number 2 to indicate 2NF)
PRODUCT-2 (prod-no, prod-desc, unit-price)
4. Rename the original entity (ending with a 2 to indicate 2NF)
ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)
 Third Normal Form (3NF)
Definition: A relation is in 3NF if, and only if, it is in 2NF and
every non-key attribute is non-transitively dependent on the
primary key.
Remove transitive dependencies into a new relation

Steps from 2NF to 3NF:

• Remove the offending attributes that are transitively
dependent on non-key attribute(s), and place them in a
new relation.
• Add to this relation a copy of the attribute(s) which are
the determinants of these offending attributes. These will
automatically become the primary key of this new
relation.
• Name the new entity (appending the number 3 to indicate 3NF)
 Example - 2NF to 3NF
ORDER-2 (order-no, order-date, cust-no, cust-name, cust-add, order-total
1. Remove the offending attributes that are transitively dependent on non-key
attributes, and place them in a new relation.
ORDER-2 (order-no, order-date, cust-no, order-total

(cust-name, cust-add )
2. Add to this relation a copy of the attribute(s) which determines these offending
attributes. These will automatically become the primary key of this new relation..
ORDER-2 (order-no, order-date, cust-no, order-total

(cust-no, cust-name, cust-add )

3. Name the new entity (appending the number 3 to indicate 3NF)
CUSTOMER-3 (cust-no, cust-name, cust-add )
4. Rename the original entity (ending with a 3 to indicate 3NF)
ORDER-3 (order-no, order-date, cust-no, order-total
 Example - Relations in 3NF
ORDER-3 (order-no, order-date, cust-no, order-total

CUSTOMER-3 (cust-no, cust-name, cust-add )

PRODUCT-2 (prod-no, prod-desc, unit-price)

ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)

order-no prod-no
ORDER PRODUCT

places placed by contains shows

belongs to
cust-no part of order-no, prod-no
CUSTOMER ORDER-LINE