İlişkilerin Sonuçları Vardır

🌐 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 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 7.‘si. Her modül kendi başına okunabilir. Önceki: Alanlar da Mimaridir · Sonraki: Sahiplik ve Yaşam Döngüsü

Bu modülün yanıtladığı soru: İki Salesforce nesnesini bağladığımda gerçekte neyi seçiyorum?

Bir ilişki çizmek kolaydır. 2. bölümde çizgiler çizip onlara ad verdik: bir Perakende Ortağı çok sayıda yük listesi gönderir, bir teslimat çok sayıda kalem taşır, ekipler ve kamyonlar bir Ekip Ataması’nda buluşur. Kardinaliteden, isteğe bağlılıktan ve geçmişten bahsettik. Şimdi bu çizgileri Salesforce’ta uyguluyoruz ve diyagramdaki bir çizgi çok daha fazla ağırlık taşımaya başlıyor.

Salesforce’ta bir ilişki türü seçtiğimde yalnızca bu iki kayıt bağlıdır demiyorum. Alt kaydın sahibinin kim olduğuna, üst kayıt olmadan var olup olamayacağına, onu kimin görebileceğine, üst kayıt silindiğinde ne olacağına, başka bir üst kayda taşınıp taşınamayacağına, onu üst kayıtta özetleyip özetleyemeyeceğime ve yüz binlerce alt kayıt olduğunda ne olacağına da karar veriyor olabilirim. Bir ilişki yalnızca bir çizgi değildir. Davranış taşır.

İş İlişkisiyle Başlayın

Arama ilişkisi ya da ana-ayrıntı ilişkisinden önce işe dönün. Bir Teslimat’ı ve Teslimat Kalemlerini alın: buzdolabı, kurulum, eski ürünün götürülmesi. Bir kalem teslimatı olmadan var olabilir mi? Hayır. Teslimat silinirse kalemleri de gitmeli mi? Evet. Kalemlerin kendi sahibine ya da kendi güvenliğine ihtiyacı var mı? Pek değil. Biri bir kalemi bir teslimattan diğerine taşımalı mı? Umarım kazara değil.

Şimdi bir Teslimat’ı ve içinde yer aldığı Rota’yı alın. Teslimat rotaya konmadan önce vardır, plan değiştiğinde başka bir rotaya taşınabilir ve bir rotayı silmek asla üzerindeki teslimatları silmemelidir. Diyagramda aynı görünen, bambaşka davranışlara sahip iki bire-çok çizgi. Hâlâ “arama ilişkisi” ya da “ana-ayrıntı” demediğimize dikkat edin. Önce davranışı tanımlayın. Yapılandırma onu uygular.

İlişki Türleri

Yeni Alan ekranını açın; Salesforce size bir avuç ilişki türü sunar (Object Relationships Overview (opens in a new tab), İngilizce):

• Arama (Lookup): iki nesneyi birbirine bağlar. Salesforce ilişkilerinin ekmeği, aşı.
• Ana-ayrıntı (Master-detail): üst kaydın alt kaydı kontrol ettiği bir üst-alt bağı.
• Çoka-çok (Many-to-many): kendi başına bir alan türü değil, bir kalıp: bir Salesforce bağlantı nesnesi (Salesforce Junction Object), yani iki ana-ayrıntı ilişkisi olan bir özel nesne.
• Kendine ilişki (Self-relationship): bir nesneden kendisine bir arama ilişkisi.
• Hiyerarşik (Hierarchical): yalnızca Kullanıcı (User) nesnesinde var olan özel bir arama ilişkisi, örneğin bir kullanıcının yöneticisi.
• Harici arama (External lookup) ve dolaylı arama (indirect lookup): harici nesnelere giden ve onlardan gelen ilişkiler, yani 4. modüldeki __x nesneleri. Harici arama bir üst harici nesneye işaret eder; dolaylı arama ise bir harici nesneden bir standart ya da özel nesneye, benzersiz bir Harici Kimlik üzerinden eşleşerek işaret eder.

Tasarım zamanınızın çoğu ilk üçüne gider. Onları tek tek ele alalım.

Arama İlişkisi: Bu Kayıtlar Bağlıdır

Bir arama ilişkisi şunu söyler: bu kayıt şu kayıtla ilişkilidir. Alt kayıt kendi kimliğini, kendi sahibini ve kendi hayatını korur. Bir Teslimat kendi Rota’sına işaret eder. Rota iptal edilirse teslimatlar yok olmaz; yeniden rotaya konmak üzere geri dönerler.

İşin komik yanı: arama alanı alt kayda konur, ama üst kayıt da bir şey alır: alt kayıtlarının bir ilgili listesi (related list). Bu yüzden bir tane oluşturduğunuzda iki ucu da adlandırın. Related List Label (İlgili Liste Etiketi) insanların üst kayıtta gördüğüdür; Child Relationship Name (Alt İlişki Adı) ise geliştiricilerin ve entegrasyonların üst kayıttan alt kayıtlara gitmek için kullandığıdır. Varsayılanları kabul etmeyin.

Bir arama ilişkisi zorunlu ya da isteğe bağlı olabilir. İsteğe bağlı olduğunda, işaret ettiği kayıt silinirse ne olacağına siz karar verirsiniz ve üç seçenek vardır (Considerations for Object Relationships (opens in a new tab), İngilizce):

• Bu alanın değerini temizle (Clear the value of this field), varsayılan. Alt kayıt kalır, arama alanı boş olarak.
• Arama kaydının silinmesine izin verme (Don’t allow deletion). Rotayı silmeye çalışın, Salesforce hayır der: bir ilişkinin parçasıdır.
• Bu kaydı da sil (Delete this record also), bir ana-ayrıntıdaki gibi zincirleme silme. Yalnızca bir özel nesnedeki özel bir arama ilişkisi için sunulur, varsayılan olarak devre dışıdır ve Salesforce’un onu org’unuz için açması gerekir, çünkü zincirleme silme güvenliği ve paylaşımı atlar: kullanıcılar göremedikleri kayıtları bile silebilir.

Bu, bir kurulum ekranında saklanan bir yaşam döngüsü kararıdır.

Arama filtreleri (Lookup filters), bir kullanıcının neyi seçebileceğini daraltır. Diyelim ki Teslimat’ın Kişi’ye bir Kurulumcu arama ilişkisi var ve kurulumcular, kişilerin pek çok kayıt türünden biri. Bir arama filtresi yalnızca kurulumcuları gösterir ve geçerli kayda, aranan kayda ve kullanıcıya, yani onun profiline, rolüne ya da izinlerine göre filtreleyebilir (Lookup Filters (opens in a new tab), İngilizce). Bir arama ilişkisini dürüst tutmanın ucuz bir yoludur.

Ana-Ayrıntı: Bu Alt Kayıt O Üst Kayda Aittir

Ana-ayrıntı çok daha güçlü bir ifadedir. Derste ona çok sıkı bir bağ derim. Ana kaydı olmadan bir ayrıntı kaydınız olamaz; ana kayıt alanı zorunludur. Ayrıntı kaydı kendi Sahip alanını kaybeder ve üst kaydının sahibini devralır. Ayrıntı için ayrı bir paylaşım tablosu yoktur; bu yüzden bir alt kaydı tek başına paylaşamazsınız; üst kaydının paylaşımını devralır. Bir ayrıntı nesnesinin paylaşım kuralları, elle paylaşımı ya da kuyrukları olamamasının nedeni budur: hepsinin bir Sahip alanına ihtiyacı vardır (Object Relationships Overview (opens in a new tab), İngilizce). Kurulum’da paylaşım ayarı Controlled by Parent (Üst Kayıt Tarafından Kontrol Edilir) olarak görünür. Ve ana-ayrıntı alanının kendisinde bir Sharing Setting (Paylaşım Ayarı) seçersiniz: bir kullanıcının ayrıntı kayıtlarını oluşturmak, düzenlemek ya da silmek için ana kayıtta Salt Okunur mu yoksa Okuma/Yazma erişimine mi ihtiyacı olduğu. Ana kaydı silmek ayrıntılarını da siler. Ve ana kayıt toplama özeti alanları (roll-up summary) alır.

Yani Teslimat Kalemi, Teslimat’ın ayrıntı kaydıysa şunu söylüyorum: bu kalem tüm ömrü boyunca bu teslimata aittir. Biri Kurulum’da Ana-Ayrıntı İlişkisi’ni seçmeden önce yanıtlanmasını istediğim soru budur.

Silme Sorusu

Her şeyin düşünülüp düşünülmediğini anlamanın en sevdiğim yolu: biri üst kaydı silerse alt kayıtlara ne olmalı? Herkes huzursuzlanır. Güzel. Artık mimari yapıyoruz.

Bir Perakende Ortağının yüz binlerce geçmiş teslimatı var. Biri ortağı siliyor. Teslimatlar yok olmalı mı? Neredeyse kesinlikle hayır: talepler, faturalama ve geçmiş onlara bağlı. Belki bir ortağı silmeye hiç izin verilmemeli, onun yerine ortak devre dışı bırakılmalı. Ana-ayrıntıda ana kaydı silmek ayrıntılara ve onların ayrıntılarına basamaklı olarak yayılır; ana kaydın silinmesini geri almak onları da geri getirir (Considerations for Object Relationships (opens in a new tab), İngilizce). Bu yüzden biri “ana-ayrıntı bize toplama özetleri veriyor” dediğinde yanıtım şu olur: harika. Başka neyi kabul ettiniz?

Sahiplik de Beraberinde Gelir

Arama ilişkisinde alt kaydın kendi sahibi olabilir. Ana-ayrıntıda olamaz; erişim ana kaydı izler. Ayrıntı gerçekten üst kaydın bir parçasıysa bu tam olarak doğrudur. Ama alt kaydın kendi sahibine, kendi paylaşımına ya da kendi yaşam döngüsüne ihtiyacı varsa model size ana-ayrıntının yanlış seçim olduğunu söylüyordur. Bir sonraki modül sahipliğe daha derin iniyor, Sharing and Visibility kursu ise daha da ileri gidiyor. Şimdilik: ilişki tasarımı ve güvenlik tasarımı ayrı konuşmalar değildir. Veri modeli, kimse bir paylaşım kuralı yazmadan önce güvenlik modelini şekillendirir.

Üst Kayıt Zorunlu mu, İsteğe Bağlı mı?

Alt kayıt, üst kaydını bilmeden önce var olabilir mi? Bu göründüğünden daha önemlidir. Teslimatlar önceki gece yük listesiyle geliyor ve rotalar sonradan oluşturuluyorsa, Teslimat’ta zorunlu bir Rota alanı, kayıt daha oluşturulmadan rota planlamanın yapılması gerektiği anlamına gelir. Fiziksel ilişki gerçek yaşam döngüsünü desteklemelidir. Bu yüzden ilişkileri yalnızca durağan bir diyagramdan tasarlamam. Bilmek isterim: nasıl doğuyorlar, tek başlarına var olabilirler mi, taşınabilirler mi ve nasıl ölüyorlar?

Alt Kayıt Üst Kaydını Değiştirebilir mi?

Varsayılan olarak bir ana-ayrıntı alt kaydı başka bir üst kayda taşınamaz. İlişkide Yeniden üst kayda bağlamaya izin ver (Allow reparenting) seçeneğini işaretleyerek buna izin verebilirsiniz (Considerations for Object Relationships (opens in a new tab), İngilizce). İçgüdüm temkinlidir: iş, alt kaydın ömür boyu tek bir üst kayda ait olduğunu söylüyorsa onu taşımayı kolaylaştırmam. Bir kalemin bir teslimattan diğerine taşınması bir alan düzenlemesi değil, bilinçli bir iş olayı olmalıdır. Yine, ayar mimari değildir. Yaşam döngüsü kuralı mimaridir; ayar onu uygular.

Ekipleri sonradan yakalayan iki şey daha. Zaten verisi olan bir nesnede ana-ayrıntı ilişkisi oluşturamazsınız; bir arama ilişkisi oluşturur, her kayıtta doldurur, sonra dönüştürürsünüz. Ve arama ilişkisine ancak ana kayıtta hiç toplama özeti alanı yoksa geri dönebilirsiniz. Dönüştürmenin güvenliğe ne yaptığına da dikkat edin: bir arama ilişkisini ana-ayrıntıya çevirmek alt kaydın paylaşımını Controlled by Parent yapar, bir ana-ayrıntıyı arama ilişkisine geri çevirmek ise alt kaydın kuruluş genelindeki varsayılanını Public Read/Write (Herkese Açık Okuma/Yazma) yapar (Considerations for Object Relationships (opens in a new tab), İngilizce). Dün gizli olan kayıtlar bugün açıktır, biri fark edene kadar. Erken seçin.

Toplama Özetleri Yararlıdır ama Bedava Değildir

Toplama özetlerini severim. Bir teslimattaki kalemleri sayın, bir faturadaki satır tutarlarını toplayın, en son tarihi bulun: yerel, kodsuz. Ana-ayrıntı alanı alt kayda konur, ama toplama özeti üst kayda konur. Yine de ince yazılarla gelirler (Roll-Up Summary Field (opens in a new tab), İngilizce):

• Belirli değişikliklerden sonra (yeni bir toplama özeti alanı, bağlı olduğu bir formülün değişmesi, zorunlu bir yeniden hesaplama) toplama değerlerinin hesaplanması, etkilenen kayıt sayısına bağlı olarak 30 dakikaya kadar sürebilir. İnsanların üst kayıttaki sayının neden henüz değişmediğini merak ettiklerini izledim.
• Her şeyi özetleyemezler. Bir otomatik numara, toplanan alan olamaz. Ve bir toplama özeti, bir formül alanını ancak o formül başka bir nesneye uzanmıyorsa ve NOW() ya da TODAY() gibi kendiliğinden değişen bir fonksiyon kullanmıyorsa özetleyebilir. TODAY() üzerine kurulu bir “gecikme gün sayısı” formülü, kimse bir kaydı kaydetmeden her gece değişir; dolayısıyla toplama özetinin yeniden hesaplamak için dayanacağı bir şey yoktur. Bu tür bir sayı zamanlanmış bir akışa ya da bir rapora ihtiyaç duyar.
• Filtrenin de sınırları vardır: uzun metin alanı, çoklu seçim listesi, Açıklama, Last Activity gibi sistem alanları, nesneler arası formüller ya da arama alanları olmaz.
• Toplama özetleri düzenleme sayfalarında yer almaz; bu yüzden bir doğrulama kuralı birini kullanabilir ama hatasını orada gösteremez.

Ve kararı tersinden vermeyin. “Bir toplama özetine ihtiyacımız var, o halde bu ana-ayrıntı olmalı” demeyin. “Bu alt kayıt gerçekten bu üst kayda ait, sahiplik ve yaşam döngüsü uyuyor ve faydalardan biri de yerel toplama özetleri” deyin. Anlam uymuyorsa hesaplamayı başka bir yolla çözün. Bir özellik elde etmek için veri modelini çarpıtmayın.

Peki başka yol ne? Toplama özetini kendiniz kurarsınız: üst kayıtta hesaplanan değeri tutan bir alan ve onu güncel tutan bir otomasyon. Diyelim ki Perakende Ortağı, olması gerektiği gibi, Teslimat’tan bir arama ilişkisi ve iş, ortak üzerinde Açık Teslimatlar’ı görmek istiyor. Ortağa Açık Teslimatlar adlı bir sayı alanı ekleyin. Sonra bir kayıt tetiklemeli akış (record-triggered flow), ya da hacim veya mantık kod gerektirdiğinde bir Apex tetikleyicisi, bir teslimat her değiştiğinde onu yeniden hesaplar. Bir arama ilişkisi üzerinden çalışır, her şeye göre filtreleyebilir ve yerel bir toplama özetinin kullanamadığı tarihleri ve formülleri kullanabilir.

Ama artık doğru yapmak size kalmıştır ve bunlar tam da orada ters gider. Otomasyon önemli olan her değişiklikte tetiklenmelidir: yeni bir alt kayıt, düzenlenen bir alt kayıt, silinen bir alt kayıt, silinmesi geri alınan bir alt kayıt ve başka bir üst kayda taşınan bir alt kayıt; bu sonuncusu hem eski hem yeni üst kaydı yeniden hesaplamak demektir. Sınırlara takılmadan her seferinde 200 kayıtlık bir veri yüklemesini kaldırabilmelidir. Ekleyip çıkarmak yerine yeniden sayın; böylece kaçırılan tek bir olay sayıyı sonsuza dek yanlış bırakmaz. Her şeyi yeniden hesaplamanın bir yolunu planlayın: ilk yükleme için ve sayının kaydığı gün için. Ve unutmayın, artık her alt kayıt kaydı üst kaydı günceller; dolayısıyla binlerce alt kaydı olan bir üst kayıt, birazdan göreceğimiz kilitlenmeyi geri getirir. Yerel bir toplama özeti bunların hepsini sizin için yapar; özel olanı ise sahibi olduğunuz küçük bir yazılım parçasıdır.

Üç Düzey Derinlik: Ana-Ayrıntıları Üst Üste Koymak

Platformun bir şekli vardır ve ana-ayrıntının bu şekilde iki boyutu vardır. İlki derinliktir.

Ana-ayrıntıları üç özel ayrıntı düzeyi derinliğe kadar üst üste koyabilirsiniz ve dip orasıdır (Considerations for Object Relationships (opens in a new tab), İngilizce). Derste bunu bir siparişi olan bir hesap (bir), kalemleriyle sipariş (iki) ve ayrıntılarıyla kalemler (üç) olarak çizerim; sonra dördüncüyü eklemeye çalışırım ve Salesforce izin vermez. Steve Trucking’de şöyle görünebilir: bir Teslimat ana kayıttır; onun Teslimat Kalemleri birinci düzeydir; bir kalemin Kurulum Görevleri ikinci düzeydir; her görevin Görev Adımları da üçüncü düzeydir. Dördüncü bir düzey, diyelim bir Adım Notu, bir arama ilişkisi olmak zorundadır.

Click to enlarge

Bu yığınla birlikte birkaç kural gelir:

• Standart nesneler bir özel nesnenin ayrıntı tarafında olamaz. Bir özel nesne Hesap’ın ayrıntısı olabilir; Hesap sizin nesnenizin ayrıntısı olamaz.
• Bir nesne çok düzeyli bir yığında yalnızca bir kez görünebilir. Salesforce kendi üzerinize geri dönmenizi istemez: bir alt ayrıntı aynı zamanda kendi ana kaydının ana kaydı olamaz.
• Ana kayıt en alt düzeyi doğrudan toplayamaz. Teslimat, Görev Adımı sayısını istiyorsa Kurulum Görevi kendi adımlarını toplar, Teslimat Kalemi o toplamları toplar, Teslimat da kalemleri toplar: her seferinde bir düzey.
• Sahiplik ve paylaşım tepeden gelir. Her düzey ana kaydın sahibini ve erişimini devralır.
• Ana kaydı silmek altındaki her şeyi siler ve silmeyi geri almak her şeyi geri getirir.

Üç düzey genellikle fazlasıyla yeterlidir. Tasarımınız sürekli bir dördüncüsünü istiyorsa, her düzeyin gerçekten ömür boyu üstündekine ait olup olmadığını sorun. Ve zinciri hangi bağlantının kıracağını seçebileceğinizi unutmayın. Dördüncü düzeyin arama ilişkisi olması gerekmez: belki bir Kurulum Görevi aslında kendi Teslimat Kalemi’ne ait değildir, kendi başına planlanır ve atanır; o zaman o bağlantı bir arama ilişkisi olur ve artık Kurulum Görevi, altında Görev Adımı ve Adım Notu ile yeni bir zincir başlatır. Alt kaydın gerçekten kendi hayatı olduğu bağlantıyı seçin ve arama ilişkisini o yapın.

Click to enlarge

Artık Kurulum Görevi’nin kendi sahibi ve kendi paylaşımı var, bir teslimat kurulum görevlerini de beraberinde götürmeden silinebilir ve Kurulum Görevi’nin altında iki düzey daha olabilir. Ödünleşim budur: zincir daha kısadır ve kurulum görevinin hayatı kendisine aittir.

İki Üst Kayıt Genişlik: Salesforce Bağlantı Nesnesi

Önce sözcükler hakkında bir söz, çünkü “bağlantı nesnesi” (junction object) iki şey anlamına gelir ve ben ikisini de öğretirim.

2. bölümde mantıksal bağlantı nesnesini bulduk: iki anahtar fikrin kesişimi olup kendi özniteliklerine sahip, kendi başına bir şeye dönüşen nesne. Bir köpek birçok numara bilir, bir numarayı birçok köpek bilir ve Köpek Numarası aralarında durup beceri düzeyini ve tarihi tutar. Bu, mantıksal modelde, kimse arama ilişkisi mi ana-ayrıntı mı diye karar vermeden çok önce bir mantıksal bağlantı nesnesidir.

Salesforce terimi daha dar kullanır. Salesforce bağlantı nesnesi dediğinde iki ana-ayrıntı ilişkisi olan bir özel nesneyi kasteder (Create a Many-to-Many Object Relationship (opens in a new tab), İngilizce). Ben ona Salesforce bağlantı nesnesi (Salesforce Junction Object) diyeceğim. Her Salesforce bağlantı nesnesi bir mantıksal bağlantı nesnesidir, ama her mantıksal bağlantı nesnesi bir Salesforce bağlantı nesnesine dönüşmez: onu bir ana-ayrıntı ve bir arama ilişkisiyle ya da iki arama ilişkisiyle kurun, yine bir mantıksal bağlantı nesnesidir, yalnızca Salesforce türünden değildir. (Salesforce’un kendisi de tam tutarlı değil: kendi nesne başvurusu, arama ilişkileri üzerine kurulu bazı standart nesnelere “junction object” der. Sınavda dar tanımı varsayın.)

Sınav bilgisi. Bir Salesforce bağlantı nesnesi (Salesforce Junction Object), iki ana-ayrıntı ilişkisi olan bir özel nesnedir ve Salesforce “junction object” dediğinde kastettiği budur. Mantıksal bağlantı nesnesi daha geniş modelleme fikridir: nasıl kurulmuş olursa olsun, iki nesneyi çoka-çok bir ilişkide birleştiren ve kendi özniteliklerini taşıyan her nesne.

İkinci boyut genişliktir. Bir alt kaydın iki ana-ayrıntı üst kaydı olabilir mi? Evet. Üç? Hayır. Her özel nesnenin en fazla iki ana-ayrıntı ilişkisi olabilir (Considerations for Object Relationships (opens in a new tab), İngilizce). İki ana-ayrıntı üst kaydı, çoka-çok bir ilişki için bir Salesforce bağlantı nesnesini böyle kurarsınız. Ekip ve Kamyon bir Ekip Ataması’nda buluşur ve 2. bölümde bulduğumuz gibi bu bir tesisat değildir: bir tarihi, bir rotası, belki bir durumu vardır. Bağlantı nesnesi, ilişkinin bir iş kavramına dönüştüğü yerdir. Salesforce’un bir tane kurmak için ipuçları: ona ne olduğunu söyleyen bir ad verin, kayıt adını otomatik numara yapın ve her ana kaydın ilgili listesini diğer ana kaydın adıyla yeniden adlandırın; böylece Ekip sayfası “Kamyonlar”ı, Kamyon sayfası “Ekipler”i gösterir (Create a Many-to-Many Object Relationship (opens in a new tab), İngilizce).

İşin inceliği şu. İki üst kayıttan biri birincildir ve o, ana-ayrıntı alanını önce oluşturduğunuz üst kayıttır. Hangisinin birincil olduğuna dair görsel bir işaret yoktur; bu yüzden klasik bir sınav sorusudur, klasik bir sürprizdir de.

Birincil neye karar verir? Üç şeye (Create a Many-to-Many Object Relationship (opens in a new tab), İngilizce):

• Görünüm. Bağlantı nesnesinin sayfaları birincil ana kaydın rengini ve simgesini kullanır.
• Sahip. Bağlantı kayıtları birincil ana kaydın sahibini devralır. Bunu hiç görmezsiniz, çünkü bir ayrıntının Sahip alanı yoktur; yalnızca daha sonra iki ana-ayrıntı ilişkisini de kaldırırsanız önem kazanır.
• Bölüm (Division), org’unuz bölümler kullanıyorsa, aynı şekilde.

Diğeri de ikincildir. Bu ne anlama gelir?

• Birincil olmak için sırada bekler. Birincil ana-ayrıntı alanını silin ya da bir arama ilişkisine dönüştürün, ikincil birincil olur.
• Raporların kapsamını belirler. Salesforce size iki rapor türü verir: “Primary master with junction object and secondary master” ve “Secondary master with junction object and primary master”. Önce listelenen ana kayıt, raporun hangi kayıtları gösterebileceğine karar verir.
• Erişim için tam olarak aynı ölçüde önemlidir. Ben şöyle söylerim: sahiplik birincilden, erişim ikisinden ve en kısıtlayıcı olan kazanır. Bir bağlantı nesnesinin, her ayrıntı gibi, kendi paylaşım tablosu yoktur. Salesforce kullanıcının iki ana kayda erişimini de her ana-ayrıntı alanındaki Sharing Setting (Paylaşım Ayarı) üzerinden denetler. İkisi de Okuma/Yazma olarak ayarlanmışsa, kullanıcının Ekip Ataması’nı düzenlemek için ekipte ve kamyonda Okuma/Yazma erişimine ihtiyacı vardır (Considerations for Object Relationships (opens in a new tab), İngilizce).
• Tam olarak aynı ölçüde siler. Ana kayıtlardan herhangi birini, ekibi ya da kamyonu silin, bağlantı kayıtları Geri Dönüşüm Kutusu’na gider. İkisini de silin, kalıcı olarak yok olurlar.

Click to enlarge

Birkaç kural daha: iki ana kaydın da bağlantı nesnesinden toplama özetleri olabilir ve bağlantı nesnesinin formülleri ve doğrulama kuralları ikisindeki alanlara da ulaşabilir. Ama bir bağlantı nesnesi başka hiçbir şeyin ana kaydı olamaz; dolayısıyla bir yığının ortasında duramaz ve iki ana kayıt aynı nesne olamaz; bir nesneden kendisine çoka-çok bir ilişki farklı bir tasarım gerektirir. Ve bir üst kaydın 200’den fazla bağlantı kaydı varsa ve bağlantı nesnesi diğer üst kayda toplama yapıyorsa, Salesforce yeterince bağlantı kaydını kaldırana kadar o üst kaydı silmenize izin vermez.

Peki hangi üst kayıt birincil olmalı? Anlamın sahibi olanı önce oluşturun. Bir Ekip Ataması için işi yapan ekiptir; bu yüzden Ekip’i önce oluştururum. Sonra bunu yazıya dökün, çünkü ekrandaki hiçbir şey bunu bir sonraki kişiye söylemeyecek.

Bütün bunları söyledikten sonra, sonunda elimde pek fazla Salesforce bağlantı nesnesi olmaz. Tipik olarak bir nesnenin tek bir ana-ayrıntı üst kaydı vardır ve aynı türden veridir: müşteri verisinin altında müşteri verisi, işlem verisinin altında işlem verisi (2. bölümdeki veri türlerini hatırlayın: müşteri, işlem, referans). Diğer üst kaydı farklı bir türdeyse, genellikle bir referans nesnesiyse, o ilişki bir arama ilişkisidir. Bir Teslimat Kalemi kendi Teslimat’ına aittir: ana-ayrıntı, ikisi de işlem verisi. Taşıdığı Ürün’e ise bir arama ilişkisiyle işaret eder, çünkü ürün kendi hayatı olan bir referans verisidir ve kimse bir ürünü silmenin yılların teslimat geçmişini de beraberinde götürmesini istemez. Teslimat Kalemi yine de bir teslimat ile üzerindeki ürünler arasında bir mantıksal bağlantı nesnesidir; yalnızca bir Salesforce bağlantı nesnesi değildir.

Kendine İlişkiler: Çizgi Geri Döndüğünde

Bir nesne kendisiyle ilişkili olabilir: bir üst hesap, bir yönetici, bölgesel bir merkeze bağlı bir dağıtım merkezi. Salesforce neredeyse her org’da karşılaşacağınız iki tanesini yerleşik olarak kurar: Hesaptan Hesaba, hesap hiyerarşisini kuran Üst Hesap (Parent Account) alanı, ve Vakadan Vakaya, ilgili vakaları gruplayan, 2. modüldeki Üst Vaka (Parent Case). Kendine ilişki bir arama ilişkisi olmalıdır ve bir kayıt kendisine işaret edemez, ancak iki kayıt birbirine işaret edebilir (Considerations for Object Relationships (opens in a new tab), İngilizce). Kullanıcı nesnesinde ise kendine ait özel bir türdür: bir kullanıcının yöneticisi gibi şeyler için kullanılan hiyerarşik ilişki. Mekaniği kolaydır; önemli olan adlandırmadır. Dağıtım Merkezi’nden Dağıtım Merkezi’ne Distribution_Center__c adlı bir arama ilişkisi kimseye yardım etmez. Üst mü? Yedek mi? Taşma mı? İlişkiyi işaret ettiği nesneye göre değil, role göre adlandırın.

Click to enlarge

Hiyerarşik: Kullanıcı Nesnesinin Kendi İlişkisi

Bu küçük bir konu ve bir sınavın tam da başvuracağını düşündüğüm türden, az bilinen, türünün tek örneği bir bilgi. Hiyerarşik, yalnızca Kullanıcı nesnesinde var olan özel bir arama ilişkisidir. Bir kullanıcıyı başka bir kullanıcıya bağlar ve Salesforce zincirin geri dönmesine izin vermez: bir kullanıcı doğrudan ya da dolaylı olarak kendisine işaret edemez (Object Relationships Overview (opens in a new tab), İngilizce). Maria’nın yöneticisi Dev ise Dev’in yöneticisi Maria ya da Maria’ya bağlı herhangi biri olamaz.

Yukarıdaki kendine ilişkilerden farkı budur. Hesap’ta ya da bir özel nesnede iki kayıt birbirine işaret edebilir. Kullanıcı’da hiyerarşi hiyerarşi olarak kalmak zorundadır. Ve Kullanıcı’yı Kullanıcı’ya bağlamanın tek yolu budur: Kullanıcı’dan kendisine sıradan bir arama ilişkisi sunulmaz.

Zaten bir tane var. Kullanıcı’daki standart Manager (Yönetici) alanı hiyerarşik bir ilişkidir ve onaylar onu kullanabilir: bu talebi gönderenin yöneticisine gönder. Kendinizinkini de oluşturabilirsiniz, diyelim bir Eskalasyon Kişisi ya da Yedek Onaylayıcı; bir onay da aynı şekilde onun üzerinden yönlendirilebilir (ApprovalProcess, Metadata API (opens in a new tab), İngilizce). Onu kayıt erişimini yönlendiren rol hiyerarşisiyle karıştırmayın. Hiyerarşik bir alan yalnızca kullanıcılar arasında bir ilişkidir; tek bir kaydı bile paylaşmaz.

Sınav bilgisi. Hiyerarşik ilişki, standart Manager alanı gibi, yalnızca Kullanıcı nesnesinde vardır ve bir kullanıcı doğrudan ya da dolaylı olarak kendisine işaret edemez. Rol hiyerarşisi değildir.

İlişkilerin de Sınırları Vardır

Her nesnenin en fazla iki ana-ayrıntı ilişkisi olabilir. Arama ilişkisi ve ana-ayrıntı alanları birlikte ilişki alanı sayılır: varsayılan olarak nesne başına 40, talep üzerine en fazla 50. Toplama özeti alanları: varsayılan olarak nesne başına 25, en fazla 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), İngilizce). Salesforce, iki sınırdan birini yükseltmenin performansı etkileyebileceğini de ekler.

Bu sayılara göre tasarlamanız gerekmez; onlara yaklaştığınızda fark etmeniz gerekir. Üzerinde ilişki ardına ilişki asılı olan bir nesne size bir şey söylüyordur. Belki gerçekten o kadar merkezîdir. Ya da belki model yanlıştır. (Ve 18. bölümün pay bırakma kuralı geçerlidir: üçüncü yıla göre ölçülmüş olarak bir sınırın epey altında kalın.)

10.000 Alt Kayıt Sorusu

Bir de çok fazla alt kaydı olan üst kayıt var. Salesforce’un kendi önerisi, tek bir ana-ayrıntı üst kaydı için yaklaşık 10.000 alt kaydı aşmamaktır (Considerations for Object Relationships (opens in a new tab), İngilizce) ve ölçekte kayıt erişimi rehberi genel olarak üst-alt ilişkileri için aynısını söyler (Parent-Child Data Skew (opens in a new tab), İngilizce). 10.001’inci kayıt org’u bozmaz. Ama o noktadan sonra bir alt kaydı kaydetmek üst kaydı kilitleyebilir ve üst kayıttaki paylaşım değişiklikleri her alt kayda dalga dalga yayılır.

Bu yüzden tek bir üst kayıt, muazzam sayıda alt kayıt gördüğümde sorarım: neden hepsi aynı üst kaydın altında, sahipleri kim, nasıl sorgulanıyorlar ve üst kayda hangi otomasyon dokunuyor? Tek bir “Steve Trucking” hesabının altındaki tüm teslimatlar birkaç günde 10.000’i geçerdi. Masum bir bire-çok ilişki bir çarpıklık (skew) sorununa dönüşür. Bir sonraki modül çarpıklığa bir ön bakış atıyor, 2. Kısım ise derine iniyor.

Çizgiyi Özelliğe Göre Tasarlamayın

Bu modülden edinmenizi istediğim alışkanlık bu. “Bir toplama özetine ihtiyacım var”, “zorunlu olmasına ihtiyacım var”, “devralınan paylaşım istiyorum” ile başlamayın. Bunlar uygulama ipuçlarıdır. İşle başlayın: alt kaydın kendi hayatı var mı, sahibi kim, tek başına var olabilir mi, taşınabilir mi, üst kayıt gittiğinde ne olur, ilişki veri taşıyor mu ve her iki taraf ne kadar büyüyebilir? Sonra yanıtları uygulayan ilişkiyi seçin.

Click to enlarge

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yapay zekâ saniyeler içinde ilişkiler önerebilir. İşin üst kaydı hiç silip silmeyeceğini size söyleyemez. Daha hızlı diyagram çizmek, milyonlarca kayıt ve düzinelerce otomasyon ona bağımlı hale geldiğinde yanlış bir ilişkiyi geri almayı ucuzlatmaz.

Mimarın Burada Karar Verdikleri

• Alt kaydın kendi yaşam döngüsü olup olmadığı ya da gerçekten üst kayda ait olup olmadığı ve sahiplik ile erişimin kendine ait mi yoksa devralınmış mı olması gerektiği.
• Alt kaydın üst kayıt olmadan var olup olamayacağı, üst kayıtlar arasında taşınıp taşınamayacağı ya da üst kaydın silinmesinden sağ çıkıp çıkamayacağı.
• Her arama ilişkisinin üst kaydı silindiğinde ne yaptığı: temizleme, engelleme ya da zincirleme silme.
• Bir çoka-çok ilişkinin tesisat mı yoksa bir iş kavramı mı olduğu, mantıksal bağlantı nesnesinin bir Salesforce bağlantı nesnesine dönüşüp dönüşmediği, hangi üst kaydın birincil olduğu ve iki üst kaydın erişim için ne anlama geldiği.
• Modelin platformun şekline uyup uymadığı: üç özel ayrıntı düzeyi derin, iki ana-ayrıntı üst kaydı geniş, ilişki ve toplama özeti sınırları.
• Beklenen alt kayıt sayısının ve dağılımının tasarımı değiştirmesi gereken bir çarpıklık riski yaratıp yaratmadığı.

Bir ilişki, iki veri parçasının birlikte nasıl davrandığına dair bir dizi sözdür. Bu sözleri bilinçli verin.

Daha Fazlası

• Salesforce Help, Considerations for Object Relationships (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Help, Object Relationships Overview (opens in a new tab) ve Create a Many-to-Many Object Relationship (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Help, Roll-Up Summary Field (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Help, Lookup Filters (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (opens in a new tab) ve Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.