Veri Modeli İskelettir

🌐 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 ilk bölümü olan Bir Veri Mimarı Gibi Düşünmek bölümündeki 7 modülden 2.‘si. Her modül kendi başına okunabilir. Önceki: Bir Mimar Gibi Düşünmek · Sonraki: Tersinirlik Testi

Bu modülün yanıtladığı soru: Veri modeli neden üzerine inşa edilen her şeyden daha önemlidir ve bir veri modelini nasıl değerlendirirsiniz?

Veri mimarisi öğretirken tekrar tekrar döndüğüm bir söz var: veri modeli iskelettir.

Veri modeli sistemin iskeletidir. Geri kalan her şey onun etrafında kurulur ve vücudun geri kalanını bir arada tutan odur. Birine baktığınızda kemiklerini görmezsiniz, ama o kişinin ne kadar dik durduğunu, nasıl hareket ettiğini ve ne taşıyabileceğini kemikler belirler.

Bir Salesforce uygulamasında inşa ettiğimiz her şeyi düşünün. Veri modelinin etrafında otomasyon kurarız. Ona karşı Apex yazarız, onu okuyan ve güncelleyen Flow’lar oluştururuz. İçine veri gönderen ve içinden veri çeken entegrasyonlar kurarız. Üzerinde raporlar ve analizler oluşturur, güvenliği onun etrafında tasarlarız. Ve giderek artan biçimde, o veriyi anlaması ve ona göre hareket etmesi gereken yapay zekâ ajanları inşa ederiz. Bunların hepsi alttaki yapıya bağlıdır.

Veri modelini erkenden doğru kurmanın bu kadar önemli olmasının nedeni budur. İskeleti sonra değiştirebilirsiniz. Ama muhtemelen canınız yanacaktır.

İşle Başlayın

İyi bir veri modeli basit bir soruyla başlar: iş gerçekte neyi temsil etmek zorunda? “Hangi Salesforce nesnelerimiz var?” değil. Kesinlikle “hızlıca ne inşa edebilirim?” de değil.

Önce işi anlamaya çalışıyoruz. Bu işteki önemli şeyler neler? Birbirleriyle nasıl ilişkili? Sahipleri kim? Zaman içinde nasıl değişiyorlar? Neyin hatırlanması gerekiyor ve iş süreçleri arasında ne paylaşılıyor? Bunları ancak anladıktan sonra nesnelere, alanlara ve ilişkilere çevirmeye başlamalıyız.

Bu kulağa apaçık geliyor. Pratikte ise ters yüz etmek çok kolaydır. Biri Fırsat’a, Vaka’ya ya da Varlık’a benzeyen bir şey tanır ve hemen onun etrafında tasarlamaya başlar. Bazen bu tam olarak doğrudur. Bazen de kare bir çiviyi yuvarlak bir deliğe sokmaya çalışıyoruzdur ve o kararın etrafında yeterince şey inşa edildikten sonra çiviyi geri çıkarmak çok pahalı hale gelir.

Sürekli duyduğum bir soru var. Bir müşterinin işletmesinin birçok teslimat noktası olabilir. Her nokta bir Hesap mı olmalı, yoksa bir özel nesne mi? Cevap vermeden önce ilk neyi bilmeniz gerektiğine dikkat edin: bir noktanın bu işletme için ne anlama geldiğini ve başına ne geldiğini. Bu, nesnelerden önce işi modellemektir. (Benim cevabımı 3. bölümde vereceğim.)

Destekle. Büyü. Performans göster.

Bir veri modeline baktığımda üç testi geçmesini isterim: işi desteklemek, işle birlikte büyümek ve performans göstermek.

Destekle. Model, işin gerçekte başarmaya çalıştığı şeyi desteklemelidir. Veriyi teknik olarak saklayabilen bir model ile işi gerçekten iyi temsil eden bir model arasında büyük fark vardır. Model tam oturmadığı için sürekli tuhaf alanlar, özel işaretler, karmaşık otomasyonlar ve istisnalar ekliyorsam, sorunun gerçekten otomasyonda olup olmadığını sorgulamaya başlarım. Belki model yanlıştır. İyi bir model işi anlamayı kolaylaştırmalı, zorlaştırmamalıdır.

Büyü. Büyümek derken yalnızca daha fazla kaydı kastetmiyorum. Hacim önemlidir: on bin kayıt ile yüz milyon kayıt çok farklı sorunlar yaratır. Ama işletmeler karmaşıklık bakımından da büyür. Ürün eklerler, yeni pazarlara girerler, şirket satın alırlar, süreçlerini değiştirirler, kanal eklerler ve yeni sistemler bağlarlar. Tek bir şey sandıkları şeyin aslında beş farklı şey olduğunu keşfederler. Bugün için harika çalışan bir model, yarına yer bırakmamışsa bir tuzağa dönüşebilir. Bu yüzden var olanı sürekli değiştiren tasarımlar yerine ekleme yoluyla büyüyen tasarımları tercih ederim. Yeni bir şey eklemek, onlarca başka şeyin bağlı olduğu bir şeyi yeniden tanımlamaktan genellikle daha kolaydır.

Performans göster. Veri öylece durmaz. Onu yazarız, buluruz, sorgularız, paylaşırız, raporlarız ve entegre ederiz; giderek artan biçimde yapay zekâ sistemleri de harekete geçmeden önce onu bağlam olarak getirir. Bir model diyagramda güzel görünüp işletmesi berbat olabilir. Bu yüzden hem verinin nasıl saklandığı hem de verinin nasıl kullanılacağı için tasarlarız.

Ve performans göstermeye devam etmelidir. Ölçekte performans göstermelidir: kullanıcı sayısı arttığında, veri hacmi arttığında, gerçek dünya koşullarında ve zirvelerde, ortalama günde değil yılın en yoğun gününde. Ve beklenmedik bir şey olduğunda da performans göstermeye devam etmelidir.

Destekle. Büyü. Performans göster. Kurs boyunca bu üç teste dönüp duracağız.

Click to enlarge

Fazla Düz, Fazla Karmaşık ya da Düpedüz Yanlış

Veri modellerinin üç şekilde yanlış gittiğini gördüm.

Birincisi baştan yanlış şeyi seçmektir. Yeterince yakın göründüğü için standart bir nesne kullanırız, sonra hiçbir zaman doğru uyum olmadığı için yıllarca istisna ekleriz. Kare çivi budur.

İkincisi modeli fazla düz yapmaktır. Her şey tek bir nesneye gider ve ilk başta bu harika derecede basit görünür. Sonra iş büyür ve bu şeylerden bazılarının kendi yaşam döngüsü olduğunu, birden fazla örneği olabileceğini, kendi güvenliğine ihtiyaç duyduğunu ya da kendi ilişkileri olduğunu keşfederiz. Bir anda bire-çok bir ilişkiyi Alan 1, Alan 2 ve Alan 3 ile ya da giderek karmaşıklaşan işaretler ve otomasyonlarla temsil ediyoruzdur. Model bize büyüyecek hiçbir yer bırakmamıştır.

Üçüncüsü bunun tersi olan hatadır: aşırı normalleştiririz. Nesne üstüne nesne içeren, her kavramın kusursuzca ayrıldığı zarif bir diyagram çizeriz. Teknik olarak güzel, pratikte işkence. Kullanıcılar onu anlamakta zorlanır ve ilişkili liste üstüne ilişkili liste içeren sayfa düzenleri ve Lightning sayfaları sonsuz derinlikte gibi gelmeye başlar. Sorgular karmaşıklaşır, otomasyon daha fazla ilişkiyi aşar, raporlama zorlaşır ve platform sıradan iş sorularını yanıtlamak için daha fazla iş yapar.

Peki hangisi doğru, düz mü normalleştirilmiş mi? Bir formülü yok. Kafanızda en uygun modelin bir resmini tutar ve ondan uzaklaştıkça ödünleşimleri anlarsınız. Mimarinin sanatı budur; buna modül 4’te ve modellemeyi öğrendiğimiz bir sonraki bölümde döneceğiz. Şimdilik şunu kabul edin: yapının kendisi mimari bir karardır.

Click to enlarge

İskeleti Değiştirirken Dikkatli Olun

Bir sistem çalışmaya başladığında, veri modelindeki temel değişiklikler konusunda çok temkinli olurum.

Diyelim ki bir metin alanı yıllardır var ve biri “Artık onu gerçekten öyle kullanmıyoruz. Sayıya çevirelim” diyor. Bir alan değişikliği gibi görünüyor. Ama o alana ne bağlı? Flow’lar, Apex, raporlar, entegrasyonlar, veri hatları, harici uygulamalar, yapay zekâ ajanları. Ve geçmiş verilere ne olacak? Kod ya da Flow’lar hâlâ bir alana başvurduğu sürece platformun kendisi o alanın türünü değiştirmenize izin vermez; bu da değişikliğin ne kadar uzağa uzandığını gösterir.

Bazen doğru cevap var olanı değiştirmek değildir. Değişikliğin ne kadar ciddi olduğuna bağlı olarak yeni bir şey oluşturmayı, bilinçli olarak taşımayı ve eski yapıyı kullanımdan kaldırmayı tercih ederim:

Değiştirmek yerine ekleyin. Şaşırtmak yerine kullanımdan kaldırın.

Salesforce bunu meta veride söylemenin bir yolunu bile sunar: bir alanın Field Usage değeri DeprecateCandidate olarak ayarlanabilir, yani “kullanımdan kaldırılması planlanıyor ve artık kullanılmıyor.” Bu, alanı nesneyi okuyan herkes için işaretler; alanı gizlemez, dolayısıyla onu emekliye ayırmak yine sizin uygulamanız gereken bir karardır.

Çünkü mimarinin başka parçaları bir şeye bağlandığında, onun anlamını değiştirmek adını değiştirmekten çok daha tehlikeli olabilir. En kötüsü, adı aynı kalırken içeriği değişen alandır: aşağı akıştaki her şey hâlâ o ada güvenir.

Click to enlarge

Bir alandaki Zorunlu kutusunu işaretlemek kadar basit bir şey bile saatli bir bombaya dönüşebilir. Zaten veri topladıysanız, bazı kayıtlarda o alan dolu olmayacaktır. Sonra günler, haftalar ya da aylar sonra biri bu kayıtlardan birini günceller ve zorunlu alan yüzünden kaydetme başarısız olur; o değer de kimsede yoktur. Bir alanı zorunlu yapmak gibi basit bir değişikliğin istenmeyen ve gecikmeli sonuçları olabilir. Zorunlu konusuna ve bir değerin gerçekte ne zaman bilindiğine 3. bölümde döneceğiz.

Sınavın ötesinde: yapay zekâ da iskeletin üzerine inşa eder. Bir yapay zekâ aracından bir uygulama inşa etmesini isteyin; nesneleri, alanları, Flow’ları, Apex’i, bileşenleri ve testleri dakikalar içinde üretir. Asıl veri modeli yanlışsa kötü bir kararın sonuçlarından kaçınmış olmayız; onları hızlandırmış oluruz, çünkü üretilen her katman o yapıya bağlı bir şey daha demektir. Bu yüzden yapay zekânın ürettiği bir veri modelini bir insan mimarın incelemesini, anlamasını ve ondan sorumlu olmasını isterim. Modül 7 bunu daha ileri götürüyor.

Önce İskelet Gelir

Bu kurs boyunca pek çok teknolojiden bahsedeceğiz: nesneler ve ilişkiler, büyük veri hacimleri, sorgular, entegrasyon, taşıma, işlemler, güvenlik, Data 360 ve yapay zekâ. Bunların hepsinin altında veri modeli vardır.

Model işi destekliyor, işle birlikte büyüyebiliyor ve veriyi kullanacağımız yollar için performans gösteriyorsa güçlü bir temel kurmuşuzdur. Temeli yanlış kurarsak, sonrasındaki her şey zorlaşır.

Veri modeli iskelettir. Mimarlar iskeleti tasarlarken çok dikkatli olmalıdır. Mevcut yapılarda değişiklik yapmak zincirleme sonuçlar doğurabilir.

Mimarın Burada Karar Verdikleri

• Modelin işi destekleyip desteklemediği, işle birlikte büyüyüp büyüyemeyeceği ve verinin kullanılacağı yollar için performans gösterip göstermediği.
• Bir kavramın standart bir nesneye uyup uymadığı, yoksa kare bir çivi mi olduğu.
• Modelin ne kadar düz ya da ne kadar normalleştirilmiş olacağı ve nedeni.
• İskelete yapılacak bir değişikliğin yerinde bir değişiklik yerine bir ekleme mi, bir taşıma mı yoksa bir kullanımdan kaldırma mı olması gerektiği.

Daha Fazlası

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-02; yeniden kontrol 2026-10-12): hangi tür dönüşümlerinin veri kaybettirebileceği ve Apex, Flow ya da süreçlerin başvurduğu bir alanın türünü neden değiştiremeyeceğiniz.
• Data Classification Metadata Fields (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-02; yeniden kontrol 2026-10-12): Field Usage değerleri (Active, DeprecateCandidate, Hidden) ve diğer sınıflandırma alanları.