Veriyi Ait Olduğu Yere Koyun

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 2. bölümü olan Veriyi Anlam İçin Modellemek bölümündeki 6 modülden 4.‘sü. Her modül kendi başına okunabilir. Önceki: Mantıksal Modeli Kurun · Sonraki: Üçüncü Normal Forma Göre Tasarlayın, Sonra Geri Çekilin

Bu modülün yanıtladığı soru: Normalleştirme, verinin gerçekte nereye ait olduğunu bulmama nasıl yardımcı olur?

Bir mantıksal modelimiz var: varlıklar, ilişkiler, öznitelikler ve anahtarlar. Şimdi veri modellemedeki en önemli sorulardan birini sormak istiyorum: bu veri gerçekten buraya mı ait?

Basit görünüyor. Değil. Her alanın, biri onu oluşturduğunda mantıklı olduğu pek çok sistem gördüm. Sorun alanların saçma olması değildi; olguların yanlış yerde saklanmasıydı. Bir teslimat, aslında bir dağıtım merkezini tanımlayan bilgileri tutar. Aynı adres yüzlerce kayıtta görünür. Tek bir alan virgülle ayrılmış üç değer tutar. Tek bir iş olgusundaki değişiklik 10.000 kaydı güncellemek demektir. Normalleştirme bu sorunu çözmemize yardım eder ve veritabanı terimlerine gömülmeden önce fikrin tamamı şu: bir olguyu ait olduğu yere koyun. Bu modüldeki diğer her şey, bunu daha sistemli yapmamıza yardım eder.

Normalleştirme Nedir?

Normalleştirme, veriyi her olgu bir kez ve ait olduğu yerde saklanacak şekilde düzenlemektir. Bir tablo çok fazla iş yapıyorsa, onu her biri tek bir şeyi tanımlayan tablolara böleriz ve bunları anahtarlarla birbirine bağlarız.

Neden uğraşalım? Çünkü bir kez saklanan bir olgu, bir kez değiştirdiğimiz bir olgudur. Normalleştirme fazlalığı, yani aynı olgunun birçok kayda kopyalanmasını önler; onunla birlikte de bir kopya güncellenip diğerleri güncellenmediğinde sızan tutarsızlıkları. Bu yüzden kayıtların gün boyu oluşturulup güncellendiği Salesforce gibi işlem sistemlerine uyar.

Normal formlar denen adımlarla normalleştiririz ve her biri tek bir soru sorar:

• Birinci normal form (1NF): alan başına tek bir değer ve her satırı benzersiz olarak tanımlayan bir şey.
• İkinci normal form (2NF): her olgu, satırı tanımlayan şeyin yalnızca bir kısmını değil, tamamını tanımlar.
• Üçüncü normal form (3NF): her olgu bu şeyi tanımlar, onunla ilişkili başka bir şeyi değil.

Üçüncünün ötesinde başka formlar da var. Onlar hakkında ve neden genellikle üçüncüde durduğumuz hakkında sonra bir şey söyleyeceğim. Önce üç adımın gerçekleşmesini izleyelim.

Neden Normalleştiririz?

Bunu canlı öğretirken teslimatlarla başlamam. Köpeklerle başlarım. Köpekleri herkes anlar, bu yüzden kimsenin dikkati işe dağılmaz ve verinin kendi evini bulmaya çalışmasını izleyebiliriz. Sonra aynı hamleleri Steve Trucking’e taşırız.

Otur, Bekle, Modelle

Başlangıç: ham elektronik tablo. Ekrana birkaç köpek koyarım, sonra salondakiler kendi köpeklerini ekler. Birkaç dakika içinde büyük tek bir listemiz olur: köpek, doğduğu yıl, sahibi kim, sahibi nerede yaşıyor, ırkı, kim yetiştirmiş ve bildiği numaralar.

Köpek	Doğum	Sahip	Posta Kodu	Şehir	Irk	Yetiştirici	Numaralar
Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge	Otur, Bekle, Pati Ver
Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow	Otur, Yuvarlan
Max	2022	Ana	64105	Kansas City	Melez		Otur, Ölü Taklidi
Luna	2020	Kenji	98101	Seattle	Husky	Cascade	Otur, Bekle, Dön
Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge	Otur
Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws	Pati Ver, Dön

Çalışıyor. Her elektronik tablo ilk gün çalışır. Ama şimdiden neyin yanlış olduğuna bakın. Pati Ver’i bilen her köpeği nasıl bulurum? Ana’nın posta kodu iki satırda var, Marcus’unki de öyle: biri birini güncelleyip diğerini güncellemezse ne olur? Maple Ridge iki kez geçiyor, Kansas City de. Ve Max barınaktan geldi, yani hiç yetiştiricisi yok.

1. adım: birinci normal form. İki kural. Her alan tek bir değer tutar, yani virgüllü numara listesi gitmeli. Ve her satırın onu benzersiz olarak tanımlayan bir şeye ihtiyacı vardır. Köpeğin adı değil; Max adında çok köpek var. Bir kimlik: otomatik oluşturulan bir kimlik (ID) veya bir GUID. Numaralar kendi satırlarına çıkar, her köpek ve her numara için bir satır. Ve bir numaranın kendi satırı olunca, virgüllü bir listede asla söyleyemeyeceğimiz şeylere yer açılır: numaranın ne kadar zor olduğu, bu köpeğin onu ne kadar iyi yaptığı ve ne zaman öğrendiği.

Köpek (Köpek Kimliği ile tanımlanır)

Köpek Kimliği	Ad	Doğum	Sahip	Posta Kodu	Şehir	Irk	Yetiştirici
D-001	Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	Melez
D-004	Luna	2020	Kenji	98101	Seattle	Husky	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws

Köpek Numarası (Köpek Kimliği + Numara ile tanımlanır)

Köpek Kimliği	Numara	Zorluk	Beceri Düzeyi	Öğrenme
D-001	Otur	Kolay	Uzman	2017-11
D-001	Bekle	Kolay	Uzman	2018-01
D-001	Pati Ver	Orta	İyi	2018-06
D-002	Otur	Kolay	Uzman	2020-02
D-002	Yuvarlan	Zor	Öğreniyor	2023-05
D-003	Otur	Kolay	İyi	2022-06
D-003	Ölü Taklidi	Zor	Öğreniyor	2024-03
D-004	Otur	Kolay	Uzman	2020-11
D-004	Bekle	Kolay	İyi	2021-01
D-004	Dön	Orta	Uzman	2021-06
D-005	Otur	Kolay	Öğreniyor	2025-02
D-006	Pati Ver	Orta	Uzman	2015-06
D-006	Dön	Orta	Öğreniyor	2025-04

Artık “Pati Ver’i bilen her köpek” basit bir soru. Ama Köpek Numarası’nın neyle tanımlandığına dikkat edin: tek bir şeyle değil, birlikte iki şeyle, köpek ve numara. Bunu aklınızda tutun.

2. adım: ikinci normal form. İkinci normal form yalnızca bir satır bir kombinasyonla tanımlandığında önemlidir ve Köpek Numarası öyledir. Bu yüzden her sütuna sorarım: kombinasyonun tamamını mı tanımlıyor, yoksa yalnızca bir kısmını mı? Beceri Düzeyi bu köpeğin bu numarayı yapmasını tanımlar: Bella Otur’da uzman, Rocky ise hâlâ öğreniyor. Öğrenme tarihi de öyle. Peki Zorluk? Otur, hangi köpek yaparsa yapsın kolaydır. Numarayı tanımlar, anahtarın yalnızca bir kısmını; “Kolay” sözcüğünün her Otur satırında tekrarlanmasının nedeni budur. Bu yüzden numara kendi tablosunu alır ve geriye çift kalır.

Numara

Numara Kimliği	Numara	Zorluk
T-01	Otur	Kolay
T-02	Bekle	Kolay
T-03	Pati Ver	Orta
T-04	Yuvarlan	Zor
T-05	Ölü Taklidi	Zor
T-06	Dön	Orta

Köpek Numarası (Köpek Kimliği + Numara Kimliği)

Köpek Kimliği	Numara Kimliği	Beceri Düzeyi	Öğrenme
D-001	T-01	Uzman	2017-11
D-001	T-02	Uzman	2018-01
D-001	T-03	İyi	2018-06
D-002	T-01	Uzman	2020-02
D-002	T-04	Öğreniyor	2023-05
D-003	T-01	İyi	2022-06
D-003	T-05	Öğreniyor	2024-03
D-004	T-01	Uzman	2020-11
D-004	T-02	İyi	2021-01
D-004	T-06	Uzman	2021-06
D-005	T-01	Öğreniyor	2025-02
D-006	T-03	Uzman	2015-06
D-006	T-06	Öğreniyor	2025-04

Bu Köpek Numarası tablosu, 2. modülde bulduğumuz tablodur ve veri modellemede bir adı vardır: bir bağlantı (junction) ya da benim deyişimle bir mantıksal bağlantı nesnesi. Bir köpek birçok numara bilir; bir numarayı birçok köpek bilir. Bağlantı ikisinin arasında durur ve boş bir tesisat değildir: ilişkinin kendisine ait olguları, beceri düzeyini ve tarihi tutar. Onunla 6. modülde yeniden karşılaşacağız; 3. bölümde de Salesforce’un “bağlantı nesnesi” terimini daha dar kullandığını göreceğiz: bir Salesforce bağlantı nesnesi (Salesforce Junction Object), iki ana-ayrıntı ilişkisi olan bir özel nesnedir (3. bölüm, 7. modül).

3. adım: üçüncü normal form. Şimdi Köpek tablosuna dönelim. İçindeki her şey Köpek Kimliği ile tanımlanır, bu yüzden ikinci normal formun söyleyecek bir şeyi yok. Üçüncü normal form farklı bir soru sorar: bu olgu köpeği mi tanımlıyor, yoksa köpeğin ilişkili olduğu başka bir şeyi mi? Irk kendi başına bir şeydir: bir Labrador hangi köpek olursa olsun Labrador’dur ve onunla ilgili olgular, örneğin boyutu, Bella’ya değil ırka aittir. Posta kodu ve şehir köpeği değil sahibi tanımlar: hangi köpeğine bakarsak bakalım Ana’nın yaşadığı yer orasıdır. Yetiştiricinin bilgileri yetiştiriciyi tanımlar. Bunların her biri başka bir olgu hakkındaki bir olgudur, bu yüzden her biri kendi tablosuna taşınır ve köpek ona bir yabancı anahtarla işaret eder:

• Köpek: Köpek Kimliği, Ad, Doğum, Sahip Kimliği, Irk Kimliği, Yetiştirici Kimliği
• Sahip: Sahip Kimliği, Ad, Posta Kodu, Şehir
• Irk: Irk Kimliği, Irk, Boyut
• Yetiştirici: Yetiştirici Kimliği, Ad, Şehir
• 2. adımdan Numara ve Köpek Numarası

Ana artık bir kez saklanıyor ve iki köpeği de ona işaret ediyor. Maple Ridge bir kez saklanıyor ve Irk tablosu bize her ırk hakkındaki, örneğin boyutu gibi, elektronik tablonun koyacak yeri olmadığı olgular için bir yuva veriyor. Bir yabancı anahtar boş olabilir: Max’in Yetiştirici Kimliği yok ve bu bir boşluk değil, dürüst bir cevap. Sonra salona bir şaşırtmaca soru atarım: sahip köpeği ne zaman aldı, bu tarih nereye gider? Köpeğe. Bu modelde bir köpeğin aynı anda bir sahibi vardır, bu yüzden bu tarih köpeğin sahibiyle ilişkisini tanımlar.

Bir adım daha ileri gidip şehri posta kodundan ayırabilirsiniz; ders kitapları bunu yapar. Pratikte bir adres bir arada kalır; üstelik Kansas City zaten iki eyalette yer alır, gerçek dünyanın ders kitaplarımızı okumadığına güzel bir hatırlatma.

İlerleyiş bu: bir elektronik tablo, sonra üç soru ve her olgu tek bir yere yerleşir. Bir adım geri çekilip ne kurduğumuza bakın. Dağınık tek bir liste, her biri tek bir şeyi tanımlayan ve anahtarlarla birbirine bağlanan altı tabloya dönüştü:

Click to enlarge

Bunu izlemek için kimsenin tek bir Salesforce sözcüğüne ihtiyacı olmadı. Yalnızca köpekler, etraflarındaki insanlar ve bildikleri.

Şimdi Bunu Steve Trucking’e Uygulayalım

Köpekler hamleleri görmeyi kolaylaştırır. Gerçek bir işletme ise onları önemli kılar, çünkü aynı hatalar ölçekte gerçek paraya mal olur. O halde aynı üç soruyu Steve Trucking’e götürelim. Teslimatlarını şöyle tuttuğunu düşünün:

Teslimat	Perakende Ortağı	Dağıtım Merkezi	DC Şehri	Ekip	Kamyon
1001	Keystone	Keystone Phoenix DC	Phoenix	Ekip 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Ekip 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Ekip 12	117

İlk bakışta burada karmaşık bir şey yok. Ama dağıtım merkezine bakın. “Keystone Phoenix DC, Phoenix” bilgisini oradan çıkan her teslimatta tekrarlıyoruz: Steve Trucking dokuz DC’de günde yaklaşık 3.300 teslimat yapıyor, yani her birinden günde birkaç yüz. O DC taşınırsa ne olur? Kaç kaydı değiştiririz ve biri gözden kaçarsa ne olur? Artık veri, DC’nin aynı anda iki şehirde olduğunu söyler. Bu bir güncelleme anomalisidir. Yeni bir DC’yi ilk teslimatından önce kurmak istersek ne olur? Bir DC’nin son teslimatını silersek: onun hakkında bir şey sakladığımız tek yeri de mi silmiş olduk?

Bunlar aynı sorunun farklı belirtileridir: farklı şeyler hakkındaki olguları birbirine karıştırdık. Dağıtım merkezi olguları dağıtım merkezine aittir. Teslimat olguları teslimata aittir. Ekip olguları ekibe aittir. Pratik anlamda normalleştirme budur.

Birinci Normal Form: Tekrarlanan Yapıyı Gizlemeyin

İnsanların normalleştirmeyi bazen olması gerekenden zor hale getirdiği yerden, Birinci Normal Form ya da 1NF ile başlayalım.

Bir teslimatta Kalemler adlı bir alan olduğunu varsayalım: “Buzdolabı, buz makinesi kiti, eski ürünün alınması.” Tek bir alana üç bilgi koyduk. Kullanışlı görünüyor, ta ki biri “Geçen ay kaç eski ürün aldık?” diye sorana kadar. Ya da Kalem 1, Kalem 2 ve Kalem 3 adlı alanlar düşünün. Bu da dört kalemli teslimata kadar çalışır. Sorun yanlış sayıda Kalem alanı seçmiş olmamız değil. Sorun tekrarlanan yapıyı fark etmemiş olmamız. Bir teslimatın birkaç kalemi olabilir. Bu modellememiz gereken bir veridir: 2. modülde bulduğumuz Teslimat Kalemi.

Click to enlarge

1NF’nin pratik dersi: tekrarlanan yapıyı alanların içine gizlemeyin. İşletme size bir şeyin birçok kez olabileceğini söylüyorsa dinleyin. Dışarı çıkmaya çalışan başka bir varlık olabilir.

Bunu gerçek org’larda sürekli görürsünüz. Birinin birkaç dilde açıklamaya ihtiyacı vardır, Description_English adlı bir alan oluşturur, sonra Description_French, sonra Description_German. Ya da bir onay birkaç kişi gerektirir ve Onaylayan 1, Onaylayan 2, Onaylayan 3 ortaya çıkar. Bir incelemede bunu bulduğumda, ele bir şaplak: veri modelinizi düzeltin. Bir ya da iki tane, belki, eğer işletmede gerçekten hep bir ya da iki tane varsa. Bunun ötesindeki her şey bir alt nesne olmalı: dili olan bir Çeviri, onaylayanı olan bir Onay Adımı. Sonraki dil ya da dördüncü onaylayan yeni bir alan ve bir dağıtım değil, yeni bir kayıt olur.

İkinci Normal Form: Şeyin Tamamını Tanımlayın

İkinci Normal Form ya da 2NF, bir kayıt birkaç şeyin kombinasyonuyla tanımlandığında önemlidir. Teslimat Kalemi’ni alın. Kendi kayıt kimliği vardır, ama her biri Teslimat + Ürün ile benzersizdir. Teslimatı, ürünü, miktarı ve ürünün açıklamasını sakladığımızı varsayalım.

Miktar burada mantıklıdır: bu ürünü bu teslimattaki haliyle tanımlar. Ama ürün açıklaması kombinasyonu tanımlamaz; ürünü tanımlar. Onu her Teslimat Kalemi’ne koyarsak, o buzdolabı modeli başka bir kamyonla her çıktığında tekrarlarız. Bu, olgunun başka bir yere ait olduğunun ipucudur.

Dolayısıyla 2NF sorusu şudur: bu öznitelik tanımladığım şeyin tamamını mı tanımlıyor, yoksa yalnızca bir kısmını mı? Yalnızca ürünü tanımlıyorsa Ürün’e gider. Ürünün bu belirli teslimattaki yerini tanımlıyorsa (miktar, kurulup kurulmadığı), Teslimat Kalemi’ne aittir. Pek çok yönetici hiçbir zaman bilinçli olarak “Şimdi İkinci Normal Form’u uyguluyorum” demeyecektir. Bu sorun değil. Benim için çok daha önemli olan, şunu sormayı öğrenmeniz: bu olgu aslında neyi tanımlıyor?

Üçüncü Normal Form: Başka Olgular Hakkındaki Olguları Saklamayın

Şimdi gündelik modellemede en çok önemsediğim forma geldik: Üçüncü Normal Form ya da 3NF.

Her dağıtım merkezinin Perakende Ortağı tarafında, iş ortağı portalını kullanan bir yöneticisi vardır. DC yöneticisinin adını doğrudan her teslimata koyduğumuzu varsayalım. DC’ye yeni bir yönetici gelince ne olur? O DC’den çıkan her teslimatı güncelleriz. Yine aynı koku: başka bir yere ait bir olguyu tekrarlıyoruz. Teslimat bir DC’den çıkar; DC’nin bir yöneticisi vardır. Bunlar iki ilişkidir ve yöneticinin adı DC’ye aittir.

Klasik ders kitabı örneği adrestir: posta kodu, şehir ve eyalet her kayıtta birlikte saklanır, oysa şehir ve eyalet genellikle posta kodundan çıkar. Aynı biçim, aynı soru.

Click to enlarge

Pratik 3NF sorusu şudur: bu olgu bu şeyi mi tanımlıyor, yoksa bu şeyin ilişkili olduğu başka bir şeyi mi? Bunu sürekli sormanızı istiyorum.

Şimdi köpeklerde yaptığımız gibi bir adım geri çekilin. Başladığımız teslimat tablosu, her biri kendi olgularını tutan beş şeye dönüştü: Teslimat Kalemi birinci normal formda ortaya çıktı, Ürün ikincide ve Dağıtım Merkezinin şehri ile yöneticisi üçüncüde Dağıtım Merkezine taşındı.

Click to enlarge

Aynı üç soru, aynı sonuç: her olgu tek bir yerde.

1NF, 2NF ve 3NF’yi Düşünmenin Basit Bir Yolu

Normalleştirmeye koca bir veritabanı dersi ayırabilirsiniz. Biz bunu yapmayacağız. Bu kurs için, çalışan bir mimarın kavrayışına sahip olmanızı istiyorum:

• 1NF: bir alanın ya da kaydın içine birden çok değer veya tekrarlanan yapılar mı gizliyorum?
• 2NF: bu olgu tanımladığım şeyin tamamını mı tanımlıyor?
• 3NF: bu olgu gerçekten bu varlığı mı tanımlıyor, yoksa onunla ilişkili bir şeyi mi?

Bunlar bir veritabanı ders kitabı için tanımlar değil. Tasarım yaparken gerçekten kullanabileceğim sorular.

Evet, normalleştirme daha da ileri gider: Boyce-Codd Normal Formu (BCNF), daha karmaşık anahtarları olan modeller için 3NF etrafındaki kuralları sıkılaştırır ve Dördüncü, Beşinci, hatta Altıncı Normal Formlar da vardır. Bunlar daha nadir tekrar türleriyle, gündelik iş kayıtlarından çok olağandışı anahtar yapılarından doğan türden tekrarlarla ilgilenir. Çok fazla teori ve benim deneyimime göre Salesforce üzerinde kurduğumuz türden sistemler için baş ağrısına değmez. İş sistemlerinde baskı genellikle ters yönde işler: üçüncü normal formun ötesine geçmekten çok, kullanıcılar, raporlama ve performans için ondan geri çekilmemiz çok daha olasıdır. Bu da sonraki modülün konusu. İleri formların var olduğunu bilin, ama yaptığımız işlerin çoğu için 1NF’den 3NF’ye kadarı bize gereken düşünme araçlarını verir.

Üçüncü Normal Form’a Göre Tasarlayın

Benim tutumum şu. Bir işletmeyi anlamaya ve mantıksal modelini tasarlamaya çalışırken temiz başlamak isterim: teslimat olguları teslimatla, dağıtım merkezi olguları DC ile, kamyon olguları kamyonla, tekrarlanan kavramlar kavram olarak modellenmiş. Bir iş olgusunun, sırf bir ekranı ya da raporu kolaylaştırabilir diye modelin her yerine kopyalanmasını istemem. Henüz değil.

Ama normalleştirme bir din değildir. Amaç, akademik olarak mümkün olan en saf model değildir. Saflığa o kadar odaklanan mimarlar gördüm ki model, onu kullanmak zorunda olan herkes için acı verici hale geldi. Bir normalleştirme yarışması kazanmaya çalışmıyoruz; bir sistem kuruyoruz ve o sistemin kullanıcıları, raporları, entegrasyonları, performans ihtiyaçları, ölçeği ve giderek artan biçimde veriyi okuyan yapay zekâsı var. Bunlar veriyi farklı biçimlerde isteyebilir.

Bu yüzden başlangıç noktam şudur: mümkün olduğunda Üçüncü Normal Form’a göre tasarlayın, gerektiğinde geri çekilin: önce her olgunun nereye ait olduğunu anlayın. Sonra ondan ayrılacaksak nedenini bilmek isterim. Cevap “alanı başka nereye koyacağımı bilmediğim için” ise bu yeterince iyi değildir. Cevap “bu değeri, iş ortağı karnesini basitleştirdiği için bilerek kopyaladık ve onu senkron tutmanın güvenilir bir yolu var” ise, artık bir mimari konuşması yapıyoruz demektir.

Mimarın Burada Karar Verdikleri

Bir mantıksal modeli normalleştirirken şunlara bakarım:

• Ayrı modellenmesi gereken tekrarlanan değerler ya da yapılar.
• Saklandıkları varlıktan farklı bir varlığı tanımlayan öznitelikler.
• Birçok kayda gereksiz yere kopyalanmış olgular ve onları tutarsız hale getiren bağımlılıklar.
• Alanların içine gizlenmiş iş kavramları.
• Herhangi bir uygulama ödününden önce gerçeği temsil eden temiz bir model.

Her fiziksel sistemin kusursuzca normalleştirilmiş kalması gerektiği için değil. Tam tersi. Sonraki modülde temiz modelden bilerek ayrılacağız; kullanıcılar, raporlama, ölçek, analitik ve yapay zekâ için. Ve bunu tam olarak neyi takas ettiğimizi bilerek yapacağız.