Üçüncü Normal Forma Göre Tasarlayın, Sonra Geri Çekilin
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)
Data Architect kursunun 2. bölümü olan Veriyi Anlam İçin Modellemek bölümündeki 6 modülden 5.‘i. Her modül kendi başına okunabilir. Önceki: Veriyi Ait Olduğu Yere Koyun · Sonraki: Modeli Salesforce’a Dönüştürün
Bu modülün yanıtladığı soru: Temiz, normalleştirilmiş bir modelden ne zaman bilerek uzaklaşmalıyım?
Önceki modülde size Üçüncü Normal Form’a göre tasarlamanızı söyledim.
Şimdi onu bozmanızı söyleyeceğim.
Bazen.
Bu önemli bir ayrım. Kazara dağınık bir veri modeli inşa etmek ile temiz bir modeli bilerek normalleştirmeden çıkarmak arasında büyük fark vardır. Verinin en başta nereye ait olduğunu anlamıyorsanız onu başka bir yere kopyalamak mimari değildir. Yalnızca çoğaltmadır.
Ama temiz mantıksal modeli anladığımda, veriyi onu tüketen insanlar ve sistemler için farklı biçimlendirme konusunda bilinçli bir karar verebilirim.
Mümkün olduğunda üçüncü normal forma göre tasarlayın. Sonra gerektiğinde geri çekilin.
Bu cümlenin ne söylemediğine dikkat edin. Üçüncü normal formun anlaşılmasının daha kolay olduğunu söylemiyor. Bazen daha zordur: tamamen normalleştirilmiş bir model tek bir iş fikrini beş nesneye dağıtabilir ve onu kullanan insanlar fikri kafalarında yeniden birleştirmek zorunda kalır. Normalleştirme bana her olgunun nereye ait olduğunu söyler. Okuması, kullanması ya da raporlaması en kolay biçimin bu olduğunu vaat etmez. Geri çekilmenin bir başarısızlık değil de bir tasarım becerisi olmasının nedeni tam olarak budur.
Gerçeği modelleyerek başlayın. Sonra o gerçeğin nasıl sunulması gerektiğine karar verin.
Otur, Bekle, Modelle
Bölüm başlığı “Otur, Bekle, Modelle ”Köpeklere dönelim; bu kez bazı bilinçli seçimler yapıyoruz.
Irk: bir seçim listesi mi, yoksa kendi tablosu mu? Bu modülün ilerisinde size vereceğim sorulardan geçirin. Birden fazla sütun bilgi var mı? Evet: en azından boyut. Kaç değer var? Köpek kulüpleri birkaç yüz ırkı tanır (yalnızca American Kennel Club 205 ırk listeler); bu, yaklaşık 20’lik pratik kuralımın çok üstünde. Bu yüzden Irk kendi tablosunu hak eder ve her köpek kendi ırkına işaret eder. Bu, 1. modülden beri taşıdığımız soruyu çözer: Irk kendi başına bir kutudur.
Beceri Düzeyi: bir seçim listesi. Öğreniyor, İyi, Uzman. Üç etiket, haklarında söylenecek başka bir şey yok ve değişmeyecekler. Seçim listesi tam da bunun içindir.
Her köpek kaç numara biliyor? Cevap zaten modelde var: köpeğin Köpek Numarası kayıtlarını sayın. Ama eğitmen bu sayıyı her raporda, iki tablo üzerinden rapor kurmadan, sıralamak ve filtrelemek için istiyor. Bu yüzden geri çekilirim ve doğrudan köpeğin üzerinde bir Bilinen Numaralar sayısı tutarım. Bu bir kopyadır. Gerçek hâlâ Köpek Numarası’nda yaşar; sayı onun bir temsilidir ve onunla uyumlu kalmalıdır. Salesforce bize tam olarak bunu yapmanın temiz bir yolunu verir; onu 6. modülde göreceğiz.
Şimdi sürpriz: köpek okulu kedi de kabul etmeye başlıyor. Ne yaparız? Bir seçenek: Köpek tablosunun yanına bir Kedi tablosu, Köpek Numarası’nın yanına bir Kedi Numarası eklemek. Her şey ikiye katlanır: her ekrandan iki tane, her rapordan iki tane ve tavşan kabul ettikleri gün üç tane. Diğer seçenek: bir adım geri çekilip bir kedinin de bir sahibi, belki bir yetiştiricisi, bir ırkı, bir doğum tarihi ve sabırla bir iki numarası olduğunu fark etmek. Bir köpekle aynı olgular ve aynı ilişkiler. Bu yüzden genelleştiririz: köpek ya da kedi olarak bir Tür’ü olan bir Evcil Hayvan. Her ırk da bir türe aittir ve tür gerçekte orada yaşar: bir Labrador bir köpektir. Evcil hayvan bilerek bir kopya taşır, böylece her ekran ve rapor ırka bakmadan “köpek mi kedi mi?” diye başlayabilir. Bir bilinçli kopya daha ve 6. modülde kendine ait bir görev alıyor.
Bu, değişime göre tasarlamaktır ve bir ödünleşimdir. Çok erken genelleştirirseniz her şey, kimsenin anlamadığı bir tür alanı olan belirsiz bir “Şey” haline gelir. İşletme bana gerçekten ikinci türü getirdiğinde ve ikisi, buradaki köpekler ve kediler gibi, neredeyse her şeyi paylaştığında genelleştiririm. Kediler çok farklı olgular gerektirseydi iki kez düşünürdüm.
Şimdi aynı türden seçimler, risklerin daha yüksek olduğu Steve Trucking’de.
En Temiz Model Her Zaman En İyi Sistem Değildir
Bölüm başlığı “En Temiz Model Her Zaman En İyi Sistem Değildir ”Bir durakta bir ekibi gözünüzün önüne getirin. Teslimatın kalemleri var. Kurulumun bir kontrol listesi var. Her adım fotoğraf gerektiriyor. Alıcı imza atıyor.
Normalleştirilmiş model çok güzel: Teslimat → Teslimat Kalemi → Kurulum Kontrol Listesi → Fotoğraf; her biri ait olduğu yerde.
Sonra onu gerçekten kullanan insanlarla oturuyorum. Bir ekip günde yaklaşık on durak kapatıyor; garaj yollarında, çoğu zaman sinyal olmadan. Güzel modelim tek bir durağı bitirmek için onları ekranlar ve ilgili listeler labirentinden geçiriyorsa bir mimari sorunum var demektir.
Tasarladığımız tek şey veri modeli değil.
Bir sistem tasarlıyoruz.
Bazen Kullanıcı Deneyimi Kazanır
Bölüm başlığı “Bazen Kullanıcı Deneyimi Kazanır ”Kusursuz biçimde normalleştirilmiş bir modelden bazen geri çekilmemin nedenlerinden biri bu: kullanıcı deneyimi.
Belki bir kavram teknik olarak kendi başına bir varlık olabilir, ama onu ayırmak çok az değer sağlayan bir karmaşıklık ekler. Belki birkaç düzey alt kaydı olan bir üst kayıt akademik olarak temizdir ama girmesi ve bakımı bir işkencedir. Belki kavram küçüktür, sabittir ve çoğunlukla bir seçim olarak kullanılır.
Burada yalnızca “Bu olgu teoride nereye ait?” diye sormayı bırakır ve “Bu sistem gerçekte nasıl kullanılacak?” diye sormaya başlarım.
Bu, fazladan bir tıklama hakkındaki her şikâyetin modeli düzleştirdiği anlamına gelmez. Kullanılabilirliğin meşru bir mimari girdi olduğu anlamına gelir.
Bazen Raporlama Kazanır
Bölüm başlığı “Bazen Raporlama Kazanır ”Raporlama da yaygın bir nedendir.
Her Perakende Ortağı bir karne istiyor: bölgeye ve aya göre zamanında teslimatlar. Temiz modelde bir teslimat kendi dağıtım merkezini, DC de kendi bölgesini bilir. Teknik olarak bunu takip edebiliriz.
Ama raporlama aracı edebilir mi? Kendi raporlarını oluşturan insanlar edebilir mi? Soruyu, sorunun kendisinden daha karmaşık bir raporlama mimarisi olmadan yanıtlayabilirler mi?
İşte o zaman bölgeyi, tüketildiği yere daha yakın olacak şekilde teslimata kopyalayabilir ya da türetebilirim.
Artık çoğaltma getirdim. Dolayısıyla başka bir soruya ihtiyacım var: gerçeğin sahibi kim?
Kaynak değer değişirse kopyama ne olur? Değişmeli mi? Yoksa teslimat gerçekleştiğinde doğru olanı mı korumalı? Bunlar farklı gereksinimlerdir.
Normalleştirmeyi geri almak karmaşıklığı ortadan kaldırmaz.
Onu yer değiştirtir.
Arama İlişkisi mi, Seçim Listesi mi?
Bölüm başlığı “Arama İlişkisi mi, Seçim Listesi mi? ”İşte Salesforce yöneticilerinin sürekli karşılaştığı daha küçük bir örnek. Kullanıcının bir değerler kümesinden seçim yapması gerekiyor. Başka bir varlık oluşturup onunla ilişki mi kurarım, yoksa bir seçim listesi mi kullanırım?
Bir teslimatın durumunu alın: planlandı, yüklendi, dağıtımda, yaklaşıyor, teslim edildi, kuruldu, istisna, iade edildi. Kısa, sabit bir etiket listesi. Tam olarak istediğim şey bir seçim listesi.
Şimdi durak türünü alın: yalnızca teslimat, kurulumlu teslimat, eski ürünü götürmeli teslimat. Bunun kendine ait bilgileri var: durağın ne kadar sürdüğü, ekibin hangi becerilere ihtiyaç duyduğu, hangi kurulum kontrol listesinin geçerli olduğu. Bağımsız olarak değişir ve iş birimi onu yönetir. Bu bir etiket değil, bir varlıktır.
Teoride normalleştirilebilecek her kavram için bir nesne oluşturursam, teknik olarak güzel ama kimsenin kullanmaktan hoşlanmadığı bir sistem inşa edebilirim. Kolay olduğu için her kavramı bir seçim listesine dönüştürürsem çok hızlı bir şekilde kendimi köşeye sıkıştırabilirim.
Bu yüzden sorarım: kendine ait bilgisi var mı? İlişkileri? Bağımsız olarak değişiyor mu? Veri olarak yönetilmesi gerekiyor mu? İş birimi sonunda ondan bir etiketten fazlasını isteyebilir mi?
Bir tasarım oturumunda gerçekte sorduğum sorular şunlar.
Birden fazla sütun bilgi var mı? Değerin bir açıklamaya, bir süreye, bir beceri listesine, bir sahibe ihtiyacı varsa artık bir etiket değildir.
Kaç değer? Kabaca kuralım yaklaşık 20. 20 değeri geçince bir seçim listesi zorlanmaya başlar ve bir nesne düşünme zamanı gelir. Elli tanesiyle ABD eyaletleri katlandığımız istisnadır, ülkeler daha da kötüdür; dürüst olalım, ülke seçim listelerini seven var mı? Bence can sıkıcılar.
Değerler zamanla mı oluşturuluyor ve kim tarafından? Bir seçim listesi değeri eklemek bir yapılandırma değişikliğidir; yani bir yönetici gerektirir. İş birimi her hafta değer ekliyorsa ve ekleyenler yönetici değilse, bir seçim listesi her yeni değerin önüne bir talep kaydı koyar.
İnsanların ona göre filtreleme ve raporlama yapması gerekiyor mu? Seçim listeleri bunun için harikadır. Arama ilişkileri o kadar temiz değildir. Her arama ilişkisi bir adım daha ekler: bir rapor türü yalnızca kısa bir ilgili nesneler zincirini izler (özel bir rapor türü en fazla dört nesne ilişkisine izin verir), ekran ilgili listelerin içinde ilgili listelere dönüşür ve kod daha karmaşık hale gelir.
Bir değer listesi çoğu zaman hayata bir seçim listesi olarak başlar ve zamanla kendine ait bir nesneyi hak eder. Bırakın hak etsin.
Bazen Ölçek Yanıtı Değiştirir
Bölüm başlığı “Bazen Ölçek Yanıtı Değiştirir ”Birkaç bin kayıtla harika çalışan bir tasarım milyonlarca kayıtla çok farklı davranabilir.
Bu yüzden yalnızca diyagrama bakmayın. Sayıları bilin.
Steve Trucking yılda yaklaşık bir milyon teslimat yapıyor ve yılda yüzde 30 büyüyor. Her teslimat yaklaşık sekiz durum güncellemesi topluyor. Bu, bu yıl sekiz milyon durum kaydı ve üçüncü yılda yılda yaklaşık 13,5 milyon demek. Buna yılda dört beş milyon fotoğraf ekleyin.
Aynı model. Bambaşka bir mimari.
Architecting at Scale kursunda çok daha derine ineceğiz. Şimdilik hatırlayın: hacim bir veri modelleme kararını değiştirebilir. Mantıksal olarak doğru bir ilişki, her ölçekte otomatik olarak en iyi fiziksel tasarım değildir.
Farklı Tüketiciler Farklı Biçimler İster
Bölüm başlığı “Farklı Tüketiciler Farklı Biçimler İster ”Şimdiye kadar operasyonel sistemi düşünüyorduk. Koordinatörler teslimatları rotalara yerleştirir. Ekipler durakları kapatır. Sistem, iş yürüdükçe değişir.
Ama iş birimi yılların geçmişini de analiz etmek ister. Hangi ortaklar ve bölgeler gecikiyor? Teslimat süresi nasıl değişti? Kurulumlar ne sıklıkla ikinci bir ziyaret gerektiriyor?
Analitik bir sistem aynı bilgiyi farklı düzenlenmiş halde isteyebilir. Veri ambarı, olgu (fact), boyut (dimension) ve yıldız şema gibi terimler duyacaksınız. Bunları burada açmıyoruz; Steve Trucking’de bu Snowflake ambarıdır ve kursun ilerleyen kısmında ona döneceğiz.
Şimdilik: farklı tüketiciler aynı gerçeğin farklı biçimlerine ihtiyaç duyabilir.
Yapay Zekâ Bir Tüketici Daha Ekler
Bölüm başlığı “Yapay Zekâ Bir Tüketici Daha Ekler ”Ve şimdi bir tüketici daha var: yapay zekâ.
Bir Alıcı mesaj atıyor: “Teslimatım nerede?” Bir yapay zekâ asistanı şunu bulabilir:
Teslimat 10427, Rota 3312, Durak 7, Kamyon 117, Zaman aralığı 13.00–15.00.
Geleneksel bir uygulama bu ilişkileri izlemekten gayet memnundur. Ama Alıcıya yanıt vermek için asistanın birkaç yerden bir araya getirilmiş bağlama ihtiyacı vardır:
Redrock bulaşık makineniz, Phoenix dağıtım merkezinden çıkan bugünkü rotanın yedinci durağı. Kamyon üç durak uzaklıkta ve hâlâ 13.00–15.00 aralığınızdasınız.
Birkaç ilişkili varlıktan bilgi alıp belirli bir tüketici için daha düz, bağlam açısından zengin bir temsil oluşturduk.
Bu, normalleştirilmiş modelimi yok ettiğim anlamına gelmez. Ve kesinlikle “Yapay zekâ düz veriyi sever, o halde her şeyi dev bir nesneye koyun” anlamına gelmez. Bunu yapmayın.
Gerçeğin kaynağı temiz kalır. Yapay zekâ, yaptığı iş için oluşturulmuş bir temsil alır. Az önce analitikte gördüğümüz fikrin aynısı:
Tek bir gerçek kaynağı, tüketim için birden fazla biçimi destekleyebilir.
Temellendirme ve getirme (retrieval) konularına kursun ilerleyen kısmında çok daha derin gireceğiz.
Birden Fazla Gerçek Yaratmayın
Bölüm başlığı “Birden Fazla Gerçek Yaratmayın ”Burada bir tehlike var.
Raporlama için bölgeyi teslimata kopyalarsam, Snowflake’e düzleştirilmiş bir sürüm gönderirsem ve yapay zekâ asistanı için bağlam açısından zengin bir sürüm oluşturursam, hangisi doğrudur?
Bu sorunun bir yanıta ihtiyacı var. Esas değerin nerede yaşadığını bilmek isterim. Geri kalan her şey, o gerçeğin bir amaç için oluşturulmuş bir temsilidir.
O yer kayıt sistemidir. Normalleştirilmemiş kopyalar iyi olabilir: durak ekranı, karne, Snowflake ve yapay zekâ bağlamı, her biri kendisi için oluşturulmuş bir biçimle işini daha iyi yapar ve onlara başvurmak sorun değildir. Ama bir şey değiştiğinde değişiklik kayıt sisteminde, genellikle ilişkisel modelde başlar ve oradan dışarıya, her kopyaya akar. Kimse bölgeyi Snowflake’te düzeltmez ya da yapay zekânın bağlamını elle düzenlemez. Kaynakta düzeltin ve değişikliğin akmasına izin verin.
Ve bu en çok veri değiştiğinde önemlidir. Bir dağıtım merkezi bugün başka bir bölgeye taşınırsa geçen ayın teslimatları yeni bölgeyi mi göstermeli? Belki. Belki de değil. Geçmiş için teslimat gerçekleştiğinde doğru olan bölgeye ihtiyacım olabilir. Bu artık bir eşitleme sorunu değil. Bu bir iş kararıdır.
Normalleştirmeyi geri almanın asla kazara olmaması gerekmesinin nedeni budur. Çoğaltılan her olgu sahiplik, eşitleme, geçmiş ve güven hakkında sorular doğurur. 1. bölümdeki ödünleşim düşüncesi budur: ne satın aldığınızı (daha kolay bir ekran, daha basit bir rapor, yapay zekâ için daha iyi bağlam) ve ne ödediğinizi (yinelenen veri, eşitleme, gerçeğin daha karmaşık sahipliği) bilin. Ve temiz bir mantıksal modelden başladığımız için her kopyayı gösterip şunu söyleyebiliriz: “Bunun oraya ait olduğunu biliyorum. Bu gereksinim yüzünden burada onun bir temsilini tutuyorum.” Bu, gözden geçirebileceğimiz, itiraz edebileceğimiz ve yazıya dökebileceğimiz bir karardır; böylece bir sonraki mimar nedenini bilir.
Mimarın Burada Karar Verdikleri
Bölüm başlığı “Mimarın Burada Karar Verdikleri ”Normalleştirmeyi geri almayı düşünürken karar verdiğim şeyler:
- Her iş olgusunun esas kaynağının nerede yaşadığı.
- Temiz modelin kullanıcılar, raporlama, ölçek ya da performans için gerçek sorunlar yaratıp yaratmadığı.
- Daha basit bir temsilin çoğaltmaya değip değmediği ve kopyanın nasıl güvenilir kalacağı.
- Güncel kaynak değiştiğinde geçmiş değerlerin değişmesi gerekip gerekmediği.
- Analitiğin ya da yapay zekânın verinin operasyonel sistemden farklı bir biçimine ihtiyaç duyup duymadığı.
Başlangıç noktası hiç değişmez: gerçeğin nereye ait olduğunu bilin. Sonra gereksinimler bunu haklı çıkardığında onu sunum için biçimlendirin.
Sırada Salesforce yeniden resme giriyor. Tasarladığımız şeyi bir fiziksel veri modeline dönüştüreceğiz.
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 Haziran 2019 (İngilizce, kontrol tarihi 2026-10-12): özel bir rapor türü “en fazla 4 nesne ilişkisini kapsayabilir.”
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 Ocak 2026 (İngilizce, kontrol tarihi 2026-10-12): “AKC, bu üç yeni gelen dahil 205 ırkı tanıyor.”
- Eğlence için: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (kontrol tarihi 2026-10-12): uluslararası federasyonun on gruba ayrılmış ırk listesi. Göz gezdirin, Irk’ın neden kendi tablosunu hak ettiğini göreceksiniz.