| Sıra | DOSYA ADI | Format | Bağlantı |
|---|---|---|---|
| 01. | Normalleşti̇rme | ppt | Sunumu İndir |
Transkript
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 yeriKavramsal tasarımKavramsal Şema(ER Model)Mantıksal TasarımMantıksal Şema(İlişkisel ModelAdım 1: ER-İlişki dönüşümüAdım 2: Normalleştirme:Tasarımı geliştirme
• İ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İlişkisel Tasarım İlkeleri
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)• 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.ŞİRKETLER(şirket_adı, şirket_adresi,kuruluş_tarihi, sahip_adı, sahiplik_belgesi, pay )
Ekleme Sapması (örnek)• 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ŞİRKETLER(şirket_adı, şirket_adresi,kuruluş_tarihi, sahip_adı, sahiplik_belgesi, pay )
Silme Sapması (örnek)• 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.ŞİRKETLER(şirket_adı, şirket_adresi, kuruluş_tarihi, sahip_adı, sahiplik_belgesi, pay )
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 BB, 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şirket_adı şirket adresişirket_adı kuruluş_tarihişirket_adı, sahip_id sahiplik_belgesişirket_adı, sahip_id payşirket_adı, sahiplik_belgesi sahip_idsahip_id sahip_adıŞİRKETLER(şirket_adı, şirket_adresi, kuruluş_tarihi, sahip_adı, sahiplik_belgesi, pay )
İşlevsel Bağımlılıklar• Belirleyici- bağımlılık işaretinin solundaki özellik veya özellikler grubuna işlevsel bağımlılığın belirleyicisi denirStaff_NoPositionPositionStaff_NoPosition Staff_no’ya işlevsel bağımlıdırStaff_no Position’a işlevsel bağımlı değilStaff number SL21 ManagerManager Staff Number SL21Staff Number SG5X
Staff-Branch İlişkisi üzere işlevsel bağımlılıklarStaff_No SName Branch_No BAddress Staff_No SAddress Branch_No Tel_noStaff_No Position BAddress Tel_NoStaff_No Salary BAddress Branch_No Staff_No Branch_NoStaff_No BAddress Tel_No Branch_No Staff_No Tel_No Tel_No BAddressStaff_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 GruplarTekrarlanan 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 numberSL10 Salesman 10 Sales Stratford 018111777, 018111888, 079311122 SA51 Manager 20 Accounts Barking 017111777DS40 Clerk 20 Accounts BarkingOS45 Clerk 30 Operations Barking 079311555Tasarı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 denirStaff_No,SName Branch_NoBağı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 dönüştürülmesi• İşlevsel bağımlılıklarFd1 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_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameCustomer_No,Property_No özellikler kümesini birincil anahtar olarak kabul ettiğimizi varsayıyoruz
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd1Fd2Fd3Fd4Fd5Fd6Birincil anahtara tam bağımlıkKısmı bağımlılıkKısmı bağımlılıkd.bAday anahtara bağımlılıkAday anahtara bağımlılık
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd2Kısmı bağımlılık
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd1Birincil anahtar
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd3Kısmı bağımlılık
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd4 Dolaylı bağımlılık
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd5 Aday anahtar
Customer-Rental ilişkisinin 2NF’e dönüştürülmesiBirincil anahtarCustomer_NoProperty_noCName PAddressRent StartRent FinishRent Owner_noONameFd6Aday 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_NoBAddressÜçü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şkisiFd2 Customer_No CName Rental İlişkisi Fd1 Customer_No,Property_No RentStart,RentFinishFD5 Customer_No,RentStart Property_no, RentFinishFd6 Property_No,RenStart Customer_no, RentFinish Property_Owner İlişkisiFd3 Property_No Paddress, Rent,Owner_No,OName Fd6 Owner_No ONameCustomer 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_RentalCustomer Rental Property_for_rent Owner 3NF Property_Owner 2NF1NF
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)
50Unnormalised (UDF)First normal form(1NF)Remove repeating groupsSecond normal form(2NF)Remove partial dependenciesThird normal form(3NF)Remove transitive dependenciesBoyce-Codd normalform (BCNF)Remove remaining functional dependency anomaliesFourth normal form(4NF)Remove multivalued dependenciesFifth normal form(5NF)Remove remaining anomaliesStages of Normalisation
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)ORDERCustomer No: 001964 Order Number: 00012345Name: Mark Campbell Order Date: 14-Feb-2002Address: 1 The HouseLeytonstoneE11 9ZZProduct Product Unit Order LineNumber Description Price Quantity TotalT5060 Hook 5.00 5 25.00PT42 Bolt 2.50 10 20.50QZE48 Spanner 20.00 1 20.00Order Total: 65.50ORDER (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.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.Remove repeating groups into a new relationA 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
Example - UNF to 1NFORDER (order-no, order-date, cust-no, cust-name, cust-add, (prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total1. 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 entityORDER-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.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)Remove partial functional dependencies into a new relation
Example - 1NF to 2NFORDER-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..(prod-no, prod-desc, unit-price)ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total)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.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)• Rename the original entity (ending with a 3 to indicate 3NF)Remove transitive dependencies into a new relation
Example - 2NF to 3NFORDER-2 (order-no, order-date, cust-no, cust-name, cust-add, order-total1. Remove the offending attributes that are transitively dependent on non-key attributes, and place them in a new relation. (cust-name, cust-add )ORDER-2 (order-no, order-date, cust-no, order-total2. 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..(cust-no, cust-name, cust-add )ORDER-2 (order-no, order-date, cust-no, order-total3. 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 3NFCUSTOMER-3 (cust-no, cust-name, cust-add )ORDER-3 (order-no, order-date, cust-no, order-totalORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)PRODUCT-2 (prod-no, prod-desc, unit-price)CUSTOMERORDERORDER-LINEPRODUCTplaces placed by containspart ofshowsbelongs tocust-noorder-no prod-noorder-no, prod-no
Normalleşti̇rme
Yıl : 2020
Anahtar Kelimeler
Daha fazla görüntüle