Veriyi Anlam İçin Modellemek

🌐 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 2. bölümünün çalışma rehberi. Önce 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 dörtte birini oluşturan Veri Modelleme ve Veritabanı Tasarımı kısmının temelidir. Düşünme biçimini ele alır; bir sonraki bölüm, Salesforce Veri Mimarisi, platformun onu nasıl inşa ettiğini ele alır. Dolayısıyla nesneler, alanlar ve ilişkiler hakkında test edilenlerin çoğu iki bölümü birden gerektirir.

Sınav İçin

Bu bölümden sınavda önemli olma olasılığı en yüksek noktalar. Her biri kendi sınav hedefine bağlıdır ve öğretildiği yere bağlantı verir. İlerledikçe işaretleyin.

DM-1: Salesforce veri modeli tasarlama tekniklerini karşılaştırmak

• Kavramsal, mantıksal ve fiziksel veri modeli arasındaki farkı ve her birinin ne işe yaradığını açıklayabilirim. (Modeli Salesforce’a Dönüştürün)
• Bir gereksinimde aday varlıkları bulabilir, bir iş yapan kişiyi bir veri parçasından ayırt edebilirim. (İsimler Size Aday Varlıklar Verir)
• Kaz ayağı gösterimini okuyup çizebilirim: bir, çok ve isteğe bağlı ya da zorunlu için ikinci işaret. (Çizgileri Okuyun, İsteğe Bağlılık da Önemlidir)
• Bir ilişkinin kardinalitesini adlandırabilirim: bire-bir, bire-çok, çoka-çok. (“Bir mi, Çok mu?” Diye Sorun)
• Çoka-çok bir ilişkinin kendi başına bir varlığa, Salesforce’ta da genellikle iki üst kaydı olan bir bağlantı nesnesine dönüştüğünü bilirim. (İlişkiler Birer Şeye Dönüşebilir)
• Bir ilişkinin, üzerine yazılan bir alan yerine ne zaman geçmişe (başlangıç ve bitiş tarihli bir kayıt) ihtiyaç duyduğunu bilirim. (Zaman İlişkileri Değiştirir)
• İyi bir benzersiz kimlik seçebilirim ve doğal bir anahtarın ya da kişisel bilgi içeren herhangi bir şeyin neden riskli olduğunu bilirim. (Sonra Benzersiz Kimliklerden Bahsetmemiz Gerekir)
• Doğal anahtar ile vekil anahtar arasındaki farkı ve bir kaydın birkaç harici tanımlayıcı taşıyabileceğini bilirim. (Doğal Anahtarlar ve Vekil Anahtarlar)
• Bir Otomatik Numara alanının kaydın Salesforce kimliği değil, okunabilir bir numara olduğunu bilirim. (İlişkiler Benzersiz Kimliklere Dayanır)
• Birinci, ikinci ve üçüncü normal formu uygulayabilir, birkaç değer tutan ya da başka bir şey hakkındaki bir olguyu tekrarlayan bir alanı fark edebilirim. (1NF, 2NF ve 3NF’yi Düşünmenin Basit Bir Yolu)
• Ne zaman bilerek normalleştirmeyi geri almak gerektiğini (kullanıcılar, raporlama, ölçek) ve bunun bedelini açıklayabilirim. (Üçüncü Normal Forma Göre Tasarlayın, Sonra Geri Çekilin)
• Bir değer listesi için seçim listesi ile bir nesneye arama ilişkisi arasında karar verebilirim. (Arama İlişkisi mi, Seçim Listesi mi?)
• Özel bir rapor türünün en fazla dört nesne ilişkisine izin verdiğini ve bunun derin modeller için neden önemli olduğunu bilirim. (Arama İlişkisi mi, Seçim Listesi mi?)
• Ana-ayrıntı ilişkisinin ne zaman uyduğunu (alt kayıt asla başka bir üst kayda taşınmaz) ve ne zaman bir arama ilişkisinin daha güvenli olduğunu, Salesforce’un tek bir üst kayıtta en fazla 10.000 alt kayıt önerisi dahil, bilirim. (İlişkiler Platform Kararlarına Dönüşür)
• Mümkün olduğunda çok biçimli (polimorfik) ilişkilerden neden kaçınmam gerektiğini bilirim. (İlişkiler Platform Kararlarına Dönüşür)
• Bir iş varlığının otomatik olarak bir özel nesne anlamına gelmediğini bilirim: standart bir nesne, bir alan, yapılandırma ya da Salesforce’un dışında yaşayan veri olabilir. (Bir İş Varlığı Otomatik Olarak Özel Bir Nesne Demek Değildir)

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.

• Bir dakikalığına Salesforce’u unutun. İşi Hesap ve Kişi’ye eşlemeden önce modelleyin.
• İki şeyi gizleyen sözcüğe kulak verin. Steve Trucking’de “müşteri” hem bir Perakende Ortağıydı hem de bir Alıcı.
• Model konuşmanın bir parçasıdır. İlk modelinizin doğru olması beklenmez; size nerede yanıldığınızı göstermesi beklenir.
• Çizgilere ad verin. Aynı kutulara sahip iki model farklı anlamlara gelebilir.
• Her ilişki için “Şimdi mi, zaman içinde mi?” diye sorun.
• Benzersiz, değişmez, anlamsız, asla kişisel veri değil.
• Bir olguyu ait olduğu yere koyun, sonra bilerek geri çekilin ve nedenini yazın.
• Normalleştirmeyi geri almak karmaşıklığı ortadan kaldırmaz; yer değiştirtir. Gerçeğin sahibinin kim olduğunu bilin.
• Tek gerçek kaynağı, birçok biçim: ekranlar, raporlar, ambar ve yapay zekâ.
• Kurulum’dan yola çıkarak tasarlamayın. Yeni Özel Nesne’ye tıklamadan önce modeli çizin.
• Her fiziksel kararı işin ihtiyaç duyduğu bir şeye kadar geriye doğru izleyin.

Bilinmesi Gereken Terimler

Terim	Tek satırda
Varlık	İşin önemsediği ve hakkında veri tuttuğu bir şey
Aday varlık	Hakkında soru sorduktan sonra bir varlığa dönüşebilecek bir isim
Öznitelik	Bir varlığı tanımlayan bir olgu
İlişki	İki varlığın nasıl bağlı olduğu; işin diliyle adlandırılır
Kardinalite	Birinden kaç tanesinin diğerinden kaç tanesiyle ilişkili olduğu
İsteğe bağlılık	İlişkinin zorunlu mu olduğu, yoksa sıfır olabilir mi
Kaz ayağı	Bir çizginin ucundaki “çok” işareti
Bağlantı nesnesi	Salesforce’ta çoka-çok bir ilişki kurmanın yolu: her iki üst kaydın alt kaydı
Kavramsal model	İşte neyin var olduğu ve nasıl ilişkili olduğu; Salesforce yok
Mantıksal model	Veri: öznitelikler, benzersiz kimlikler ve ilişkiler; hâlâ bir platforma bağlı değil
Fiziksel model	Platformun onu nasıl inşa edeceği: nesneler, alanlar ve ilişki türleri
Doğal anahtar	İşte zaten var olan bir tanımlayıcı; örneğin bir kamyonun şasi numarası
Vekil anahtar	Yalnızca kaydı tanımlamak için oluşturulan bir tanımlayıcı
Harici tanımlayıcı	Aynı kayıt için başka bir sistemin kimliği; tutulur ve eşlenir
Normalleştirme (1NF, 2NF, 3NF)	Her olguyu ait olduğu yere koymak: alan başına bir değer, anahtarın bütünüyle ilgili olgular, başka olgular hakkında olgu yok
Normalleştirmeyi geri alma	Adını koyabileceğiniz bir neden için veriyi bilerek kopyalamak ya da düzleştirmek
Güncelleme anomalisi	Aynı olgunun birçok yerde saklanması; bu yüzden tek bir değişiklik bazı kopyaları yanlış bırakır

Kendinizi Sınayın

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

1. Bir işletme size bir ekibin bir kamyonu kullandığını söylüyor. Altı hafta sonra biri belirli bir günde 117 numaralı kamyonun hangi ekipte olduğunu soruyor. Modelde ne olmalıydı?

Bir Ekip Ataması: ekip ile kamyon arasındaki ilişkinin başlangıç tarihi, bitiş tarihi ve rotayla birlikte kendi başına bir kayıt olarak tutulması. Ekipler ve kamyonlar zaman içinde çoka-çok ilişkilidir ve iş birimi geçmişi önemser. Kamyondaki bir alanın üzerine yazılırdı. Zaman İlişkileri Değiştirir bölümünü yeniden okuyun.

2. Bir ekip, “benzersiz olduğu için” her Alıcının telefon numarasını benzersiz kimlik olarak kullanmayı öneriyor. Ne dersiniz?

Testlerden kalıyor: telefon numaraları değişir ve paylaşılır, yani değişmez ya da güvenilir biçimde benzersiz değildir; ayrıca kayda bağlanan her sisteme kopyalanacak kişisel bir bilgidir. Anlamsız, üretilmiş bir kimlik kullanın ve telefon numarasını öznitelik olarak tutun. Sonra Benzersiz Kimliklerden Bahsetmemiz Gerekir bölümünü yeniden okuyun.

3. Bir Teslimat'ta Kalem 1, Kalem 2 ve Kalem 3 alanları var. Dört kalemli bir teslimat geliyor. Asıl sorun nedir ve çözüm ne?

Model, alanların içinde tekrar eden bir yapı saklamış (birinci normal form sorunu). Çözüm bir Kalem 4 alanı değil; Teslimat’ın alt kaydı olan bir Teslimat Kalemi varlığıdır, böylece her kalem bir kayıt olur. Birinci Normal Form bölümünü yeniden okuyun.

4. Her teslimat dağıtım merkezi müdürünün adını saklıyor. Müdür değişiyor. Ne yanlış gitti?

Başka bir şey (dağıtım merkezi) hakkındaki bir olgu teslimatta saklanmış: bir üçüncü normal form sorunu ve artık yüzlerce kayıtta bir güncelleme anomalisi. Müdür dağıtım merkezine aittir; teslimat dağıtım merkezine işaret eder. Üçüncü Normal Form bölümünü yeniden okuyun.

5. Durak türü (yalnızca teslimat, kurulumlu, eski ürünü götürmeli) bir süreye, ekip becerilerine ve bir kontrol listesine ihtiyaç duyuyor. Seçim listesi mi, nesne mi?

Bir nesne. Birden fazla sütun bilgisi var, iş birimi tarafından yönetiliyor ve kendi takvimiyle değişiyor. Kısa ve sabit bir etiket listesi olan teslimat durumu ise seçim listesi olarak kalır. Arama İlişkisi mi, Seçim Listesi mi? bölümünü yeniden okuyun.

6. Ortaklar bölgeye göre bir zamanında teslimat karnesi istiyor ve bölge dağıtım merkezinde yaşıyor. Bölgeyi her teslimata kopyalıyorsunuz. Neye karar vermeniz gerekir?

Gerçeğin sahibinin kim olduğuna, kopyanın nasıl eşit kalacağına ve eski teslimatların gerçekleştikleri sırada doğru olan bölgeyi mi koruyacağına yoksa dağıtım merkezi taşınırsa onu mu izleyeceğine. Normalleştirmeyi geri almak karmaşıklığı yer değiştirtti; ortadan kaldırmadı. Bazen Raporlama Kazanır bölümünü yeniden okuyun.

7. Otur gibi bir numara yüz binlerce evcil hayvana bağlanabilir. Evcil Hayvan Numarası'ndan Numara'ya ana-ayrıntı mı, arama ilişkisi mi?

Arama ilişkisi. Salesforce’un önerisi tek bir üst kayıtta en fazla 10.000 alt kayıttır ve popüler bir numara bunu aşar. Ana-ayrıntı, Evcil Hayvan Numarası’ndan Evcil Hayvan’a uyar, çünkü bir evcil hayvanın numarası asla başka bir üst kayda taşınmaz ve bir evcil hayvan yalnızca birkaç numara bilir; evcil hayvanın Bilinen Numaralar sayısını toplamasını sağlayan da budur. Otur, Bekle, Modelle 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.