Bağlamak Yönetmek Değildir

🌐 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)

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

Data Architect kursunun 6. bölümü, 1. Kısım: Veri Mimarı Olmak. Önceki: Veri Kalitesi ve Yönetişim.

“Tek bir doğruluk kaynağına ihtiyacımız var.” Mimarinin en çok tekrarlanan ve en az sorgulanan ifadelerinden biri. Ne için? Tek bir hesabı alın. Yasal adının, fatura adresinin ve kredi limitinin sahibi ERP olabilir; hesap yöneticisinin ve destek katmanının sahibi Salesforce; pazarlama tercihlerinin sahibi bir onay platformu. Tek bir kayıtta üç yetki ve bu normal. Bu yüzden biri “Salesforce müşteri için tek doğruluk kaynağımız” dediğinde bir sonraki sorum her zaman şudur: hangi doğru?

Bu bölüm o soruyu bilinçli olarak yanıtlamakla ilgili. Yetki öznitelik öznitelik atanır. Kayıtları bağlamak onları yönetmek değildir. Ve Salesforce farklı işler için farklı araçlar verir: tek bir org içinde yinelenen kayıt yönetimi ve birleştirme; kaynaklar genelinde tek bir görünüm için Data 360 kimlik çözümleme; değerlere bir kez karar verilip her yere geri gönderilmesi gerektiğinde özel bir MDM platformu. Bölüm, 1. Kısım’ın Steve Trucking üzerinde bir araya geldiği 1. Kontrol Noktası ile bitiyor.

Görsel yapay zekâ ile üretilmiştir.

Bu bölümdeki pozisyonlar

• Öznitelik başına doğruluk. Her veri parçasının nerede oluşturulduğunu, düzenlendiğini ve başvurulduğunu ve ne hızla değiştiğini sorun. Harici yetkiyi şemada sap_ ya da erp_ gibi bir sistem önekiyle gösterin.
• Potansiyel müşteriler farklıdır. ERP onları tanımadan önce Salesforce’ta yaşarlar; ERP yetkisi dönüşümden sonra geçerli olur.
• Salesforce projelerinde norm kayıt defteridir (registry), ardından konsolidasyon ve birlikte var olma gelir; saf merkezî MDM nadirdir.
• Yalnızca net bir kazanan varsa birleştirin. Geriye doğru izlemeniz gerekebilecekse harici yüklemelerden gelen yinelenen kayıtları tutun; birleştirme o geçmişi yok eder. Ve alt kayıtlara ne olacağına karar verin: taşıyın, hiç yüklemeyin ya da etkin olmayan bir kayıtta tutun.
• Birleşik profil bir haritadır; altın kayıt bir karardır. Bu insanların kafasını karıştırabilir: kimlik çözümleme birleşik bir birey oluşturur, ama bir altın kayıt oluşturmaz.
• Eşleştirme katılığı bir risk kararıdır. Karıştırmanın pahalı olduğu yerde bilerek eksik eşleştirin.
• Üç iş için üç araç: birleştirme, kimlik çözümleme, MDM.
• Hiyerarşilerin ana kaydı bölünmüştür. Yetkiye dal dal karar verin.
• “En zor şey çift yönlü olanlardır.” İki yönlü bir entegrasyon iki ana kaynak yaratmaz. İlk çakışmadan önce hangi alanların tek bir işlem olarak birlikte taşınacağına karar verin.
• Ana veriyi görünür kılın. Düzenlenebilirliği bir kayıt türü değil, bunun ana veri olduğunu söyleyen bir alan (ERP’nin anahtarı ya da bir bayrak) belirler.
• ERP’leri biz kontrol etmeyiz. Onları Salesforce’ta nasıl temsil ettiğimizi kontrol ederiz: iki ERP’deki tek bir müşteri bir hiyerarşidir, eşlerdir ya da ERP başına bir alt kaydı olan tek bir hesaptır; buna müşterinin ERP’lerini ne kadar iyi senkronize tuttuğu karar verir.

Üç iş için üç araç

İş	Araç	Kaynaklara ne yapar
Tek bir org içinde, net bir kazananı olan yinelenen kayıtlar	Yinelenen kayıt yönetimi ve birleştirme	En fazla üç kaydı birleştirir; diğerleri Geri Dönüşüm Kutusu’na gider
Kaynaklar genelinde tek kimlik ve tek görünüm	Data 360 kimlik çözümleme	Onları bağlar; hiçbirini değiştirmez (bir kayıt defteri)
Her sisteme geri gönderilen, yönetilen tek bir değer	Özel bir MDM platformu	Değere karar verir ve onu dağıtır (birlikte var olma ya da merkezî)

Bu bölümdeki yol

Altı modül ve bir alıştırma; her biri kendi başına okunabilir.

1. Her Öznitelik İçin Tek Doğruluk Kaynağı. Yetki haritası, karma altın kayıt ve güven sinyalleri.
2. Ana Veriyi Yönetmenin Dört Yolu. Kayıt defteri, konsolidasyon, birlikte var olma ve merkezî; ve ortak bir modelin neden ortak bir doğru olmadığı.
3. Eşleştirme, Birleştirme ve Hayatta Kalma. Yanlış bir eşleşmenin bedeli, bir Salesforce birleştirmesinin gerçekte ne yaptığı (ve alt kayıtlara ne olduğu) ve güven hakkında bir ifade olarak hayatta kalma kuralı.
4. Harita Karar Değildir. Eşleştirme kuralları ve eşleştirme yöntemleri, uzlaştırma kuralları ve birleşik profilin neden altın kayıt olmadığı.
5. Yetki Paylaşıldığında. Talepler ile güncellemeler, döngüler ve çakışmalar, ana kaydı bölünmüş hiyerarşiler ve iki ERP’deki tek bir müşteri.
6. 1. Kontrol Noktası alıştırması, ardından 1. Kontrol Noktası: Steve Trucking, Ben Nasıl Tasarlardım. Önce alıştırmayı deneyin: 1. Kısım tasarımını çizin ve savunun, sonra benimkiyle karşılaştırın ve 4. bölümün haritasından neyin değiştiğine bakın.

Bitirdiğinizde kendinizi bölüm çalışma rehberiyle sınayın: sınav için bir kontrol listesi, onun ötesindeki alışkanlıklar, bilinmesi gereken terimler ve birkaç soru. 1. Kısım’ı kapatıyor; 1. Kısım çalışma rehberi altı bölümün hepsini bir araya getiriyor.

Mimarın burada karar verdikleri

• Her önemli öznitelik için hangi sistemin esas olduğu ve bunun modelde nasıl göründüğü.
• Her veri alanına hangi yönetim tarzının uyduğu ve yönetim katmanının ne kadar yetki aldığı.
• Ne zaman birleştirileceği, ne zaman bağlanacağı ve her hayatta kalma kuralının sahibinin kim olduğu.
• Eşleştirmenin ne kadar katı olması gerektiği; yanlış bir eşleşmenin bedeline göre.
• İki yönlü verinin ve paylaşılan hiyerarşilerin nerede açık sınırlara ihtiyaç duyduğu.

Sınavın ötesinde: ajanların üzerinde işlem yapacakları tek bir kimliğe ihtiyacı vardır ve bu riskleri iki yönde de artırır. Aşırı eşleştirme bir gizlilik olayına dönüşür ve “müşteriyi güncelleyen” bir ajan birleşik profile değil, her özniteliğin kayıt sistemine yazmalıdır. Her modül yapay zekânın neyi değiştirdiğiyle biter.

Daha Fazlası

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) ve Identity Resolution Reconciliation Rules (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.

Sonraki: 2. Kısım Ölçek İçin Tasarlamak (coming soon) ile başlıyor.