Ana Veri ve Kimlik

🌐 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 6. bölümünün çalışma rehberi. Önce 1. Kontrol Noktası çözümü dahil altı 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üm sınavın Ana Veri Yönetimi kısmını (%5) ve Salesforce Veri Yönetimi’nden tek müşteri görünümünü taşır. Ağırlık olarak küçük bir kısımdır, ama fikirleri (yetki, eşleştirme, hayatta kalma) pek çok başka senaryonun içinde karşınıza çıkar. Platform sayıları değişir; bu yüzden onlara güvenmeden önce güncellerini kontrol edin.

Sınav İçin

İlerledikçe işaretleyin. Her madde öğretildiği yere bağlanır.

MDM-2: bir altın kayıt ve bir doğruluk sistemi

• Yetkinin kayıt başına değil, öznitelik başına atandığını bilirim: tek bir hesabın ana kaydı ERP’de olan alanları ve ana kaydı Salesforce’ta olan alanları olabilir. (Doğruluk Bir Özniteliğe Aittir)
• Her özniteliğin nerede oluşturulduğunu, düzenlendiğini ve başvurulduğunu ve değişim gecikmesini sorarım. (Oluşturulan, Düzenlenen, Başvurulan; ve Ne Hızla?)
• Bir yetki haritası oluşturabilirim ve iş sahibi ile esas sistemin aynı şey olmadığını bilirim. (Bir Yetki Haritası Oluşturun)
• Yetkinin yaşam döngüsü boyunca değişebileceğini (Salesforce’taki bir potansiyel müşteri ERP’nin yönettiği bir müşteriye dönüşür) ve bir kopyanın yetki olmadığını bilirim. (Yetki Yaşam Döngüsü Boyunca Değişir, Kopya Yetki Değildir)

MDM-1: MDM teknikleri

• Sınav bilgisi: Dört MDM uygulama tarzını bilirim: kayıt defteri, konsolidasyon, birlikte var olma ve merkezî; her birinin neyi merkezîleştirdiğini ve değerleri geri gönderip göndermediğini. (Dördü Yan Yana)
• Dört MDM tarzını birbirinden ayırabilirim: kayıt defteri, konsolidasyon, birlikte var olma ve merkezî; ve sorunu çözen en hafifini seçerim. (Dördü Yan Yana)
• Kanonik bir veri modelinin yapıyı uyumlaştırdığını ama yetkiye karar vermediğini bilirim. (Ortak Bir Model Ortak Bir Doğru Değildir)
• Sırayı bilirim: önce uyumlaştır, sonra eşleştir, sonra konsolide et. (Önce Uyumlaştırın, Sonra Eşleştirin, Sonra Konsolide Edin)
• Eşiklerin hataya toleransı yansıttığını ve zenginleştirmenin kaynak bilgisi gerektirdiğini bilirim. (Eşikler, İnceleme ve Zenginleştirme)
• Sınav bilgisi: Hiyerarşi yönetimini bilirim: hiyerarşiyi Parent Account kurar (Lightning görünümü kişi hesapları olmadan en fazla 2.000 hesap gösterir), hiyerarşilerin ana kaydı çoğu zaman bölünmüştür ve bir şirketin birkaç geçerli hiyerarşisi olabilir. (Hiyerarşiler de Ana Veridir, Tek Hiyerarşi, Birkaç Ana Kaynak)

MDM-3: kazanan öznitelikleri seçmek

• Eşleştirmeyi, birleştirmeyi ve hayatta kalmayı birbirinden ayrı tutarım. (Eşleştirme, Birleştirme ve Hayatta Kalma)
• Hayatta kalma kurallarını bilirim: en yeni, en sık, kaynak önceliği; ve her kuralın bir sahibe ihtiyacı olduğunu. (Hayatta Kalma: Hangi Değer Kazanır?)
• Bir eşleşmenin birleştirme gerektirmediğini bilirim ve önce alt kayıtlara ne olacağına karar vererek yalnızca net bir kazanan varsa birleştiririm. (Bir Eşleşme Birleştirme Gerektirmez, Birleştirme Kuralım: Net Bir Kazanan)
• Sınav bilgisi: Bir Salesforce hesap birleştirmesinin ne yaptığını bilirim: en fazla üç kayıt, bir ana kayıt, en eski Created By ve Created Date korunur, diğerleri Geri Dönüşüm Kutusu’na gider ve kişi hesapları için iletişim noktası nesneleri birleştirilmez. (Bir Salesforce Birleştirmesi Gerçekte Ne Yapar)

SDM-3: tek müşteri görünümü

• Data 360 kimlik çözümlemesinin kaynak profilleri birleşik bir profile bağladığını ve geri bağlantıları tuttuğunu bilirim: en çok bir kayıt defterine yakındır. (Kimlik Çözümleme “Kim?” Sorusunu Yanıtlar)
• Sınav bilgisi: Data 360 eşleştirme kurallarını bilirim: bir kuraldaki tüm ölçütler eşleşmelidir, herhangi bir kural eşleşebilir; doğruluk için daha çok ölçüt, birleştirme için daha az. (Eşleştirme Kuralları)
• Eşleştirme yöntemlerini (Exact, Exact Normalized, üç hassasiyette Fuzzy) bilirim: daha az hassas bir yöntem birleştirmeyi, yanlış eşleşme riskini de artırır. (Eşleştirme Kuralları)
• Sınav bilgisi: Uzlaştırma kurallarının (Last Updated, Most Frequent, Source Priority) birleşik profilin neyi göstereceğine karar verdiğini ama kaynakları değiştirmediğini; iletişim noktalarının uzlaştırılmadığını bilirim. (Uzlaştırma da Yönetmek Değildir)
• İş için yinelenen kayıt yönetimi, kimlik çözümleme ve özel bir MDM platformu arasında seçim yapabilirim. (Üç İş İçin Üç Araç)

MDM-4 ve iki yönlü veri

• İki yönlü verinin iki ana kaynak anlamına gelmediğini bilirim: ERP’nin sahip olduğu bir alanda Salesforce düzenlemesi bir taleptir; bu yüzden bekleyen bir durumla talep → doğrulama → kabul → yayımlama tasarlarım. (İki Yönlü Veri İki Ana Kaynak Demek Değildir, Ana Kaynak Hayır Dediğinde)
• Döngülerden ve çakışmalardan nasıl kaçınacağımı bilirim: başlatan bir değişikliği onun yankısından ayırt ederim ve hangi alanların tek bir işlem olarak birlikte taşınacağına karar veririm. (Döngüler ve Çakışmalar)
• İki ERP’deki tek bir müşteri için, müşterinin ERP’lerini ne kadar iyi senkronize tuttuğuna göre bir hiyerarşi, eş hesaplar ya da ERP başına bir alt kaydı olan tek bir hesap seçebilirim. (Tek Müşteri, İki ERP, ERP’leri Nasıl Senkronize Tuttuklarını Sorun)

1. Kontrol Noktası: 1. Kısmı bir araya getirmek

• Sınav bilgisi: Hangi harici lisansların standart paylaşım taşıdığını bilirim: harici kullanıcılar için roller gerektiren Customer Community Plus ve Partner Community; Customer Community paylaşım kümeleri kullanır. (Kim Neyi Görür ve Kimin Lisansa İhtiyacı Var)

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.

• “Tek doğruluk kaynağı”: hangi doğru? Bu tek bir kayıt değil, bir doğruluk mimarisidir.
• Yetkiyi şemada görünür kılın: başka bir sistemin sahip olduğu alanlar için bir önek.
• Güven bir değerden fazlasını gerektirir: kaynak, son teyit, onu kimin değiştirdiği.
• MDM ürünüyle değil, sorunla başlayın. MDM yetki hakkında bir iş kararıdır.
• Bağlamak yönetmek değildir.
• Yanlış eşleşmelerin pahalı olduğu yerde bilerek eksik eşleştirin.
• Geriye doğru izlemeniz gerekebilecekse harici yüklemelerden gelen yinelenen kayıtları tutun.
• Birleşik profil bir haritadır. Altın kayıt bir karardır.
• Gösterim yetki değildir.
• Kimliği birleştirmek güvenlik sınırlarını silmez.
• En zor şey çift yönlü olanlardır. Paylaşılan yetki sorun değildir; belirsiz yetki sorundur.
• Reddedilen bir talebin rakip bir doğruya dönüşmesine asla izin vermeyin.
• Düzenlenebilirliği bir kayıt türü değil, bunun ana veri olduğunu söyleyen bir alan belirler.
• ERP’leri biz kontrol etmeyiz. Onları Salesforce’ta nasıl temsil ettiğimizi kontrol ederiz.

Bilinmesi Gereken Terimler

Terim	Tek satırda
Ana veri yönetimi (MDM)	Temel verinin esas kimliğini ve değerlerini sistemler genelinde oluşturmak ve yönetmek
Yetki haritası	Her öznitelik için: onu kim oluşturur, kararın sahibi kim, hangi sistem esas, kim değiştirebilir
Altın kayıt	Hangi değerlerin esas olduğuna dair yönetilen bir karar
Karma altın kayıt	Bazı öznitelikleri başka yerde yönetilip içeri kopyalanan, bazılarının sahibi yerel olan bir kayıt
Kayıt defteri	Kaynakları değiştirmeden kayıtları aynı varlık olarak bağlayan MDM
Konsolidasyon	Veriyi, genellikle analitik için, geri göndermeden merkezde birleştiren MDM
Birlikte var olma	Yönetilen değere karar veren ve onu kaynaklara geri yayımlayan MDM
Merkezî MDM	Yönetilen verinin ana kaynakta oluşturulup dağıtıldığı MDM
Kanonik veri modeli	Bir kavram için üzerinde anlaşılmış kurumsal biçim; sistemleri birbirine eşlemek için kullanılır
Uyumlaştırma	Değerleri karşılaştırılabilir kılmak: standart biçimler, kodlar ve kısaltmalar
Eşleştirme	Kayıtların aynı şeyi temsil edip etmediğine karar vermek
Hayatta kalma	Kaynaklar çeliştiğinde hangi değerin kazanacağına dair kurallar
Ana kayıt (principal)	Bir Salesforce birleştirmesinde hayatta kalan ve gizli ve salt okunur alanlarını koruyan kayıt
Eşleştirme yöntemi	Bir Data 360 eşleştirme ölçütünün değerleri nasıl karşılaştırdığı: exact, exact normalized ya da fuzzy
Kimlik çözümleme	Data 360’ın kaynak profilleri birleşik profillerde eşleştirmesi
Birleşik profil	Tek bir kişiyi ya da şirketi temsil eden kaynak kayıtları bağlayan anahtarlar kümesi
Uzlaştırma kuralları	Birleşik bir profilin hangi değeri göstereceğine dair Data 360 kuralları
Ana kaydı bölünmüş hiyerarşi	Dallarının sahibi farklı sistemler olan bir hiyerarşi

Kendinizi Sınayın

Kursun tarzında kısa senaryolar. Açmadan önce yanıtınıza karar verin.

1. “Salesforce müşteri için tek doğruluk kaynağımız.” Ne sorarsınız?

Hangi doğru? Yetki öznitelik başınadır: yasal adın, fatura adresinin ve kredi limitinin sahibi ERP olabilirken hesap yöneticisinin ve başarı katmanının sahibi Salesforce’tur. Bir yetki haritası oluşturun. Doğruluk Bir Özniteliğe Aittir bölümünü yeniden okuyun.

2. Servis temsilcilerinin bir Salesforce kişisinin çevrimiçi alışveriş yapan kişiyle aynı olduğunu görmesi gerekiyor. Kimse sistemlerin değişmesine ihtiyaç duymuyor. Hangi MDM tarzı?

Bir kayıt defteri: kaynakları değiştirmeden kayıtları tek bir kimlik olarak bağlayın; Data 360 kimlik çözümlemesinin yaptığı da budur. Sorunu çözen en hafif kalıbı seçin. Kayıt Defteri: Bana Kimin Kim Olduğunu Söyle bölümünü yeniden okuyun.

3. Hayatta kalma her alan için “en yeni kazanır” olarak ayarlanmış. Biri ERP'nin sahip olduğu yasal adın Salesforce kopyasını değiştiriyor. Ne olur ve yanlış olan ne?

En yeni değer kazanır ve kopya yetkinin önüne geçer. “En yeni”, bazı özniteliklere (bir cep telefonu numarası) uyan, diğerlerine uymayan bir güven ifadesidir. Yetki haritası alanın sahibinin ERP olduğunu söylüyorsa ERP kazanır. Hayatta Kalma: Hangi Değer Kazanır? bölümünü yeniden okuyun.

4. Eski sistemden müşteri kayıtları içe aktarılıyor ve var olan hesaplarla eşleşiyor. Birleştirelim mi?

Temkinli olun. Bir eşleşme birleştirme gerektirmez ve birleştirme izlemeniz gerekebilecek eski kimlikleri ve eski değerleri yok eder. Net bir kazanan yoksa ve yinelenen kayıt ihtiyacınız olan bir şey ekliyorsa onları bağlayın. Birleştirme Kuralım: Net Bir Kazanan bölümünü yeniden okuyun.

5. Data 360'taki birleşik profil Dallas gösteriyor. Ekip Dallas'ın artık her sistem için altın değer olduğunu söylüyor. Öyle mi?

Hayır. Uzlaştırma birleşik profilin neyi göstereceğine karar verir; kaynakları değiştirmez ya da bir ana veri kararı vermez. Her sistemin yönetilen tek bir değeri kullanması gerekiyorsa bu, bir sahibi olan birlikte var olma ya da merkezî MDM’dir. Uzlaştırma da Yönetmek Değildir bölümünü yeniden okuyun.

6. Tıbbi kayıtları ve pazarlama kayıtlarını eşleştirmek: aynı kurallar mı?

Hayır. Pazarlamada yanlış bir eşleşme yanlış teklifi gönderir; tıbbi veride iki kişinin geçmişini birleştirir. Katılığı yanılmanın bedeline göre belirleyin ve karıştırmanın pahalı olduğu yerde eksik eşleştirin. Yanılmanın Bedeli bölümünü yeniden okuyun.

7. Temsilciler ERP'nin sahip olduğu bir fatura adresini Salesforce'tan güncellemek istiyor. Bunu nasıl tasarlarsınız?

Bir düzenleme olarak değil, bir talep olarak: Salesforce önerilen değeri gönderir, ERP onu doğrular ve kabul eder ve esas değeri geri yayımlar. O zamana kadar bekleyen bir durum tutun ve reddi, çakışmaları ve yankıları ele alın. İki Yönlü Veri İki Ana Kaynak Demek Değildir bölümünü yeniden okuyun.

8. Steve Trucking'de aynı John Smith iki Perakende Ortağının yük listesinde görünüyor. Onu birleştirelim mi?

Hayır, bilerek hayır. Her ortak asla bir başkasının Alıcılarını görmemelidir ve birleşik bir kimlik sızdıran köprüdür. Karıştırmanın pahalı olduğu yerde eksik eşleştirin; bir ortak tekrar gelen Alıcıların tanınmasını istiyorsa bunu yalnızca o ortakla sınırlayın. Alıcıları Ortaklar Arasında Birleştirir miydim? bölümünü yeniden okuyun.

9. Bir temsilci, sahibi ERP olan bir adres için yeni bir sokak gönderirken aynı dakika ERP'deki biri şehri değiştiriyor. Neye karar verirsiniz?

Adresin tek bir işlem olarak taşınıp taşınmayacağına. Taşınıyorsa alanların hepsi birlikte gider ya da hiçbiri gitmez ve adres bu arada değiştiği için talep reddedilir. Buna ilk çakışmadan önce karar verin ve talebin ERP’nin değerini değiştirmediğini, değiştirilmesini istediğini hatırlayın. Döngüler ve Çakışmalar bölümünü yeniden okuyun.

10. Bir müşterinin iki ERP'de tek bir müşterisi var ve iki kaydı kimse senkronize tutmuyor. Satış tek bir hesap istiyor. Ne önerirsiniz?

Tek bir hesap değil. Kayıtları kendi ERP’lerinde senkronize tutamıyorlarsa Salesforce bunu onlar için yapamaz: onları eş hesaplar ya da bir hiyerarşi olarak temsil edin ve satışın zaten bildiği yapıyı gösterin. ERP başına bir alt kaydı olan tek bir hesap, ortak değerleri senkronize tutan bir müşteri gerektirir. ERP’leri Nasıl Senkronize Tuttuklarını Sorun bölümünü yeniden okuyun.

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.
• Her modülün kendi Daha Fazlası kısmı, olgularının arkasındaki Salesforce belgelerini kontrol tarihleriyle birlikte listeler.