Bir Veri Mimarı Gibi Düşünmek
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 1. bölümünün çalışma rehberi. Önce yedi modülü okuyun; bu sayfa aklınızda neyin kaldığını kontrol etmenize yardım eder.
Bu çalışma rehberi hakkında. Yalnızca bu kursun kendi içeriğinden ve Salesforce’un yayımladığı sınav rehberindeki hedefler listesinden hazırlanmıştır. Hiçbir zaman gerçek sınav sorularına dayanmaz ve sınavda ne olduğunu bildiğini iddia etmez. Sınava girdiyseniz lütfen bana sınavdan soru göndermeyin: sertifika sözleşmesi bunları paylaşmayı yasaklar ve zaten yanıt ezberlemek mimar olmanın yanlış yoludur.
Bu bölümde sınav bilgisi daha azdır ve bu bilinçli bir tercihtir. Bölüm bir mimarın nasıl düşündüğüyle ilgilidir ve hiçbir sınav hedefi yalnızca ona ait değildir. Ama sınav senaryolardan oluşur: bir işletme, birkaç sayı, bir kısıt ve işe yarayabilecek birkaç yanıt. Bu bölümdeki alışkanlıklar o senaryoları nasıl okuduğunuzdur. Bu yüzden aşağıdaki kontrol listesi, doğrudan test edildiğini iddia etmek yerine her maddenin hangi hedefi desteklediğini söyler.
Sınav İçin
Bölüm başlığı “Sınav İçin ”İlerledikçe işaretleyin. Her madde öğretildiği yere bağlanır.
Bir senaryoyu bir mimar gibi okumak (tüm hedefleri destekler)
- Gerçek gereksinimi, geldiği tasarımdan ayırırım (“Onaylayıcı 2 ve Onaylayıcı 3 alanlarına ihtiyacımız var” ile “her onayı takip etmemiz gerekiyor” arasındaki fark). (Gereksinimi Olduğu Gibi Almayın)
- Kimsenin dile getirmediği örtük gereksinimleri ararım: sahiplik, güncellik, başarısızlık, saklama, erişim. (Örtük Gereksinimleri Arayın)
- Sayıları koyarım: günlük, yıllık, büyümeyle birlikte hacim; ve bir sıfır daha eklenince yanıtın değiştiğini fark ederim. (Sayılarınızı Bilin)
- İşe yarayan birkaç yanıt arasında, her birinin ne kazandırıp neden vazgeçtiğini belirtilen gereksinimler ve kısıtlarla karşılaştırırım. (Neden Vazgeçtiğinizi Bilin, Kısıtlar Cevabı Değiştirir)
- Maliyeti, lisansı ve sınırları, sonradan akla gelen bir şey olarak değil, bir aracın uyup uymadığının parçası olarak ele alırım. (Dokuz Soru)
Veri modeli (DM-1’i destekler)
- Bir modeli işi destekleyip desteklemediğine, onunla birlikte büyüyüp büyüyemeyeceğine ve performans gösterip göstermediğine göre değerlendirebilirim. (Destekle. Büyü. Performans göster.)
- Fazla düz (Alan 1, Alan 2, Alan 3), aşırı normalleştirilmiş ya da yanlış standart nesne üzerine kurulmuş bir modeli fark edebilirim. (Fazla Düz, Fazla Karmaşık ya da Düpedüz Yanlış)
- Seçim listesinin neden kısa ve sabit bir listeye, arama ilişkisinin (lookup) neden büyümeye devam eden ya da bir entegrasyondan gelen bir listeye uyduğunu bilirim. (Sorunu Çözmenin Pek Çok Yolu)
- Anlam taşıyan bir anahtarın (örneğin bir adın bir parçası) o anlam değiştiğinde bozulduğunu bilirim. (Bazı Kararları Değiştirmek Ucuzdur)
Var olanı değiştirmek (DM-1 ve SDM-2’yi destekler)
- Bir alanın türünü değiştirmenin ya da var olan bir alanı Zorunlu yapmanın neden ileride bir şeyleri bozabileceğini ve kod ya da flow’lar alana başvururken platformun tür değişikliğini neden engellediğini bilirim. (İskeleti Değiştirirken Dikkatli Olun)
- Değiştirmek yerine ekle, sürpriz yapmak yerine kullanımdan kaldır kalıbını ve Field Usage’ın bir alanı kullanımdan kaldırma adayı olarak işaretleyebildiğini bilirim. (İskeleti Değiştirirken Dikkatli Olun)
- Tersinirlik Testi’nin arkasındaki ana-ayrıntı (master-detail) olgularını bilirim: ayrıntı kaydının erişimi ve sahipliği ana kaydı izler, bir ana kaydı silmek ayrıntılarını da siler, toplama özeti alanları ana-ayrıntı ilişkisi gerektirir ve bir arama ilişkisi ancak her kaydın bir değeri olduğunda ana-ayrıntı ilişkisine dönüştürülebilir. (Tersinirlik Testi, Daha Fazlası)
Lisanslar ve paylaşım (SDM-1’i destekler)
- Yüksek hacimli topluluk kullanıcılarının (aralarında Customer Community) rolü olmadığını ve paylaşım modelini kullanmadıklarını, dolayısıyla erişimin paylaşım kümelerinden ve paylaşım gruplarından geldiğini ve Apex paylaşımının onlara ulaşamadığını bilirim. (Çözümlü Bir Örnek: Apex Paylaşımı)
Başarısızlık (MIG-1’i ve entegrasyon bölümlerini destekler)
- “İş tamamlandı” ile verinin doğru olmasının aynı şey olmadığını ve mutabakatın aktarılamayan kayıtları nasıl bulduğunu bilirim. (Kısmi Başarı da Anlamanız Gereken Bir Başarısızlıktır)
Sınavın Ötesinde
Bölüm başlığı “Sınavın Ötesinde ”Sınav taban, tavan değil. Bunlar bu bölümden, bir soru onları hiç sorsun ya da sormasın, bir mimarın ihtiyaç duyduğu alışkanlıklardır.
- Birinin planı elinde tutması gerekir. Mimari, eksik bilgiyle iyi kararlar vermek ve sonuçlarını bilmektir.
- Veri modeli iskelettir. Geri kalan her şey onun üzerine kurulur.
- Tersinirlik Testi: bunu geri almak ne kadar zor ve ona ne kadar şey bağlı olacak?
- Mimari çekim gücü yaratır. Değişikliği pahalı kılan değişikliğin kendisi değil, bağımlılıklardır.
- Etki alanını düşünün, Salesforce’un içinde ve kurum genelinde. Mimari çift yönlü bir trafiktir.
- Nedenini yazın: bağlam, seçenekler, karar, sonuçlar, sahip, gözden geçirme. Yerine yenisini koyun; silmeyin.
- Neyde en iyi? Bilerek veriyorsanız, en uygun olmayan bir karar en uygun bir mimarinin parçası olabilir.
- Bir “en uygun” resmi taşıyın; böylece ondan hangi yöne ve neden uzaklaştığınızı bilirsiniz.
- Doğru Düşün. Hızlı Düşün. Hız, o andan önce yapılmış düşünmeden gelir.
- Bugün için inşa edin. Yarın için planlayın. Başarısızlık için planlayın. Ve kimse size bir sayı vermediğinde yüzde 30 büyüme kullanın.
- Yalnızca cevapları değil, dokuz soruyu öğrenin.
- Yapay zekâ bir roket iticisidir. Üretmek muhakeme değildir, geri alınamaz olan hâlâ geri alınamaz ve insan incelemesi bir tören değildir. Güven ama doğrula.
Bilinmesi Gereken Terimler
Bölüm başlığı “Bilinmesi Gereken Terimler ”| Terim | Tek satırda |
|---|---|
| Mimari karar | Geri alınması zor olan ve ona çok şeyin bağlı olduğu karar |
| Tersinirlik Testi | Bunu geri almak ne kadar zor ve ona ne kadar şey bağlı olacak? |
| Çekim gücü | Zamanla bir kararın etrafında toplanan bağımlılıklar |
| Etki alanı | Bir karar değiştiğinde hareket eden diğer her şey |
| Karar kaydı | Bağlam, seçenekler, karar, sonuçlar, sahip ve gözden geçirme noktası; kısa tutulur |
| Ödünleşim | Bir seçeneğin kazandırdığı ve bunun için vazgeçtiği şey |
| Örtük gereksinim | İşletmenin sormadan beklediği bir şey; örneğin bir yükleme başarısız olduğunda kurtarma |
| Steve’s Number of Zeros (Steve’in Sıfır Sayısı) | Hacimdeki bir sıfır daha tüm mimariyi değiştirebilir |
| Mutabakat | Olması gerekenle olanı kayıt kayıt karşılaştırmak |
| Kullanımdan kaldırmak | Bir şeyi yerinde değiştirmek yerine, çıkmakta olduğunu işaretleyip sonra bilinçli olarak emekliye ayırmak |
| Yüksek hacimli kullanıcı | Rolü olmayan, paylaşım modelinin dışında kalan bir topluluk kullanıcısı (lisanslar arasında Customer Community) |
| Şema yayılması | Oluşturmak ucuz olduğu için birikip sonunda modeli kimsenin tasarlamadığı hale getiren nesneler ve alanlar |
Kendinizi Sınayın
Bölüm başlığı “Kendinizi Sınayın ”Kursun tarzında kısa senaryolar. Açmadan önce yanıtınıza karar verin.
1. Bir satış ekibi Opportunity üzerinde, her biri bir tarihle birlikte Onaylayıcı 2 ve Onaylayıcı 3 alanları istiyor. Ne sorarsınız ve ne inşa edebilirsiniz?
Nedenini ve kaç onay olabileceğini sorun. İki ya da üçten fazla olabiliyorsa gereksinim alan eklemek değil, her onayı takip etmektir: her onay için bir kayıt tutan bir alt nesne. Gereksinimi Olduğu Gibi Almayın bölümünü yeniden okuyun.
2. Biri bir alanın etiketini değiştirmek istiyor, bir başkası da beş sistemin halihazırda sakladığı müşteri tanımlayıcısının biçimini değiştirmek istiyor. Hangisi dikkatinizi daha çok hak ediyor ve neden?
Tanımlayıcı. Etiketi değiştirmek ucuzdur. Tanımlayıcı Tersinirlik Testi’ni geçemez: geri alması zordur ve ona halihazırda çok şey bağlıdır. Dikkatinizi yanılmanın maliyetiyle orantılı harcayın. Bazı Kararları Değiştirmek Ucuzdur bölümünü yeniden okuyun.
3. Bir metin alanı yıllardır kullanılıyor. İşletme artık onun bir sayı tutmasını istiyor. Yaklaşımınız nedir?
Onu yerinde değiştirmeyin. Ona neyin bağlı olduğunu (Flow’lar, Apex, raporlar, entegrasyonlar, ajanlar) ve eski veriye ne olacağını bulun. Genellikle: yeni bir alan ekleyin, bilinçli olarak taşıyın ve eskisini kullanımdan kaldırın. İskeleti Değiştirirken Dikkatli Olun bölümünü yeniden okuyun.
4. 1.200 nokta, nokta başına günde 100 randevu, yılda yaklaşık 305 gün, randevu başına iki kayıt, beş yıl saklama, yüzde 30 büyüme. Kabaca kaç kayıt eder ve bu neden önemli?
İlk yılda yaklaşık 73 milyon kayıt (36,6 milyon randevu, her biri iki kayıt), büyümeyle birlikte beş yılda 650 milyonun üzerinde. Aynı özellik, birkaç sıfır daha, bambaşka bir mimari. Sayılarınızı Bilin bölümünü yeniden okuyun.
5. Gecelik bir yükleme bir milyon kayıtta “tamamlandı” bildiriyor. İşe yaradığını nasıl bilirsiniz?
Mutabakat yaparsınız. Alıcı taraf kaydettiği her kaydı teyit eder; gönderen, gönderdiğini teyit edilenle karşılaştırır. Eksik teyitler, iş durumu ne derse desin işe yaramadığı anlamına gelir ve hangi kayıtları yeniden deneyeceğinizi, bir kişiye yönlendireceğinizi ya da hangileri için uyarı vereceğinizi söyler. Kısmi Başarı da Anlamanız Gereken Bir Başarısızlıktır bölümünü yeniden okuyun.
6. 15 milyon Customer Community kullanıcısından oluşan bir topluluk karmaşık kayıt erişimine ihtiyaç duyuyor. Biri Apex paylaşımını öneriyor. Sorun nedir?
Bunlar yüksek hacimli kullanıcılardır: rolleri yoktur, paylaşım modelinin dışındadırlar; dolayısıyla Apex’in yazacağı bir paylaşım kaydı yoktur. Erişim paylaşım kümelerinden ve paylaşım gruplarından gelir. Hangi paylaşım araçlarının var olduğunu lisans belirledi. Çözümlü Bir Örnek: Apex Paylaşımı bölümünü yeniden okuyun.
7. Bir yapay zekâ aracı yeni bir uygulama için dakikalar içinde yirmi nesne üretiyor. Mimarın işi şimdi nedir?
Beş nesnemiz olması gerekip gerekmediğine karar vermek. Modeli savunabilecek kadar iyi anlamak: neden bu nesneler ve ilişkiler, anahtarlar ve ana veri nerede, ölçekte ne oluyor. Dayandığı olguları doğrulamak. Üretmek muhakeme değildir. Ucuz Uygulama Değeri Yer Değiştirtir bölümünü yeniden okuyun.
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-09-25): hedeflerin ve ağırlıklarının resmî listesi. Sınava kaydolmadan önce her zaman güncel sürümü kontrol edin.