Transcript order-no

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
tasarım
Adım 1: ER-İlişki
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)
B
A
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
Position
Staff_No
Staff number SL21
Manager
Staff_no Position’a işlevsel bağımlı değil
Position
Manager
X
Staff_No
Staff Number SL21
Staff Number SG5
Staff-Branch İlişkisi üzere işlevsel
bağımlılıklar
Staff_No
Staff_No
Staff_No
Staff_No
Staff_No
Staff_No
Staff_No
SName
SAddress
Position
Salary
Branch_No
BAddress
Tel_No
Branch_No
Branch_No
BAddress
BAddress
Tel_No
Tel_No
BAddress
Tel_no
Tel_No
Branch_No
Branch_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
SL10 Salesman
SA51 Manager
DS40 Clerk
OS45 Clerk
dept
10
20
20
30
dname
Sales
Accounts
Accounts
Operations
city
Stratford
Barking
Barking
Barking
contact number
018111777, 018111888, 079311122
017111777
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
ilişkisinin
2NF’e Rent
dönüştürülmesi
Property_no CName
PAddress Rent
Rent
Owner_no OName
Customer_No
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
Fd2 Customer_No  CName
Fd3 Property_No  PAdderss,Rent,Owner_No,
OName
Fd4 Owner_No  Owner_name
FD5 Customer_No,RentStart  Property_no,
PAdderss,RentFinish, Rent, Owner_No,OName
Fd6 Property_No,RentStart  Customer_no,
CName,RentFinish
(tam bağımlılık)
(kısmı bağımlılık)
(kısmı bağımlılık)
(dolaylı bağımlılık)
(aday anahtara bağımlılık)
(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
Fd1
Fd2
Rent
Start
Rent
Finish
Rent
Owner_no
OName
Birincil anahtara
tam bağımlık
Kısmı bağımlılık
Fd3
Kısmı bağımlılık
Fd4
d.b
Fd5
Fd6
Aday anahtara
bağımlılık
Aday anahtara bağımlılık
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Fd2
Property_no
CName
PAddress
Kısmı bağımlılık
Rent
Start
Rent
Finish
Rent
Owner_no
OName
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Fd1
Property_no
CName
PAddress
Rent
Start
Rent
Finish
Rent
Owner_no
Birincil anahtar
OName
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Property_no
CName
PAddress
Rent
Start
Rent
Finish
Rent
Owner_no
OName
Kısmı bağımlılık
Fd3
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Fd4
Property_no
CName
PAddress
Rent
Start
Rent
Finish
Rent
Dolaylı bağımlılık
Owner_no
OName
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Property_no
CName
PAddress
Rent
Start
Rent
Finish
Rent
Owner_no
OName
Fd5
Aday anahtar
Customer-Rental ilişkisinin 2NF’e dönüştürülmesi
Birincil anahtar
Customer_No
Property_no
CName
PAddress
Rent
Start
Rent
Finish
Rent
Owner_no
Fd6
Aday anahtar
OName
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,
RentFinish,
RentStart,
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
Customer
Rental
Property_for_rent
Owner
2NF
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)
Boyce-Codd normal
form (BCNF)
Remove remaining functional
dependency anomalies
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:
Name:
Address:
001964
Mark Campbell
1 The House
Leytonstone
E11 9ZZ
Order Number:
Order Date:
00012345
14-Feb-2002
Product
Number
Product
Description
Unit
Price
Order
Quantity
Line
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
Removekey.
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 Remove
primary transitive
key.
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)
prod-no
PRODUCT
order-no
ORDER
places placed by
cust-no
CUSTOMER
contains
part of
shows
belongs to
order-no, prod-no
ORDER-LINE