Modeli Salesforce'a Dönüştürün

🌐 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ü olan Veriyi Anlam İçin Modellemek bölümündeki 6 modülden 6.‘sı. Her modül kendi başına okunabilir. Önceki: Üçüncü Normal Forma Göre Tasarlayın, Sonra Geri Çekilin · Sonraki: bölüm çalışma rehberi, ardından sonraki bölüm: Salesforce Veri Mimarisi

Bu modülün yanıtladığı soru: Mantıksal bir veri modeli fiziksel bir Salesforce veri modeline nasıl dönüşür?

Sonunda Salesforce’tan bahsedeceğiz. Her kutuyu bir nesneye dönüştürme isteğine direniyorduysanız artık serbestsiniz. Ama hangi sırayla geldiğimize dikkat edin: işi anladık, veriyi tanımladık, her olguyu ait olduğu yere koyduk ve bunu nerede bilerek esneteceğimize karar verdik. Ancak şimdi Salesforce’un bunu nasıl uygulaması gerektiğini soruyorum. Hatırlamanızı istediğim ilerleyiş bu: kavramsal → mantıksal → fiziksel. Kavramsal model işi tanımlar. Mantıksal model veriyi tanımlar. Fiziksel model onu gerçekte nasıl inşa edeceğimizi tanımlar.

Otur, Bekle, Modelle

Fiziksel adımı küçük bir şey üzerinde görmek en kolayıdır, bu yüzden önce evcil hayvanlar.

İşletmeler ve insanlar kimler? Yetiştirici bir işletmedir, bu yüzden Yetiştirici kayıt türüyle bir Hesap olur. Sahip de bir Hesaptır ya da Sahip kayıt türüyle bir kişi hesabı. Aynı standart nesnenin iki türü, diyagramın üstünde yan yana, 1. modülden beri durdukları yerde.

Neyin standart bir yuvası yok? Evcil Hayvan, Irk, Numara, Evcil Hayvan Numarası ve Numara Değerlendirmesi özel nesneler olur. Ve 5. modülde evcil hayvanın üzerine kopyaladığımız türü hatırlıyor musunuz? Burada görevini alıyor: Evcil Hayvan’ın kayıt türü olur, Köpek ya da Kedi. Bir Köpek nesnesi ve bir Kedi nesnesi yerine, her biri kendi sayfa düzeni ve seçim listesi değerleriyle iki kayıt türü olan tek bir nesne.

Hangi ilişkiler ana-ayrıntı? Ana-ayrıntıyı yalnızca alt kaydın asla başka bir üst kayda taşınmayacağı yerde kullanırım. Bir Evcil Hayvan Numarası ömür boyu kendi evcil hayvanına aittir ve her Numara Değerlendirmesi kendi Evcil Hayvan Numarası’na aittir, bu yüzden ikisi de ana-ayrıntıdır. Bu hemen karşılığını verir: evcil hayvanın Evcil Hayvan Numaralarının bir toplama özetini tutmasını sağlayan şey ana-ayrıntıdır; böylece 5. modüldeki Bilinen Numaralar sayısı kendiliğinden uyumlu kalır. Ama evcil hayvanlar ev değiştirir, bu yüzden Sahip bir arama ilişkisidir.

Hangileri arama ilişkisi? Salesforce tek bir üst kayıtta 10.000’den fazla alt kayıt önermez. Otur gibi popüler bir numara, yaygın bir ırk ya da büyük bir yetiştirici bunu kolayca aşabilir; bu yüzden Evcil Hayvan Numarası kendi Numarası’na bir arama ilişkisiyle işaret eder, evcil hayvan da Irk’ına ve Yetiştiricisi’ne aynı şekilde. Ve mümkün olduğunda polimorfik ilişkilerden kaçının, yani tek bir alanın birkaç nesne türüne işaret edebildiği türden ilişkilerden. İlk gün kullanışlıdırlar, ama sonradan onları okumak zorunda olan her şey için daha zordurlar: raporlar, entegrasyonlar ve artık ajanlar.

Ne platformun dışında kalır? Evcil hayvan nerede olduğunu bildiren bir GPS tasması takıyorsa, o konumun içeri kopyalanmasına hiç gerek yoktur. Tasmanın takip sisteminden canlı okunan bir harici nesne olabilir.

Click to enlarge

O diyagramdaki her karar daha önce verdiğimiz bir şeye dayanır ve mesele de budur. Şimdi aynı adım Steve Trucking için.

Mantıksal Modelle Başlayın

Steve Trucking mantıksal modelimiz artık Perakende Ortağı, Dağıtım Merkezi, Yük Listesi, Teslimat, Teslimat Kalemi, Alıcı, Rota, Durak, Ekip, Kamyon ve Ekip Ataması’nı içeriyor. Bunlar iş kavramlarıdır ve şimdi onları Salesforce’a eşlemeye başlayabilirim.

Bir Perakende Ortağı bir Hesap olabilir. Bir teslimat, Salesforce’un sahada planlanan işler için zaten sahip olduğu bir şeye eşlenebilir ya da özel bir nesne olabilir. Bir yük listesine uyan standart bir şey yoktur; bu yüzden muhtemelen özel bir nesne olur. Alıcı ise gerçekten zor bir soru: bir Kişi Hesabı mı, bir Kişi mi, yoksa yalnızca teslimattaki bilgiler mi? Bunu bir sonraki bölümde gereği gibi yanıtlayacağız.

Önemli sözcük hâlâ olabilir. Bir iş kavramı bir Salesforce nesnesine benziyor diye uygulamayı varsaymayın. Önce mantıksal modeli kurmamızın nedeni buydu: Salesforce tasarımını sınayabileceğimiz bir şey verir.

Bir İş Varlığı Otomatik Olarak Özel Bir Nesne Demek Değildir

Yöneticilerin kaçınmasını istediğim bir tuzak: “On bir varlık belirledik, o halde on bir özel nesneye ihtiyacımız var.” Hayır. Mantıksal bir varlık bize iş kavramının önemli olduğunu söyler. Salesforce’un onu nasıl saklaması gerektiğini dayatmaz. Bir kavram standart bir nesne, özel bir nesne, nesneler arasında bir ilişki, bir alan ya da birkaç alan, yapılandırmada yönetilen bir değer ya da tamamen Salesforce’un dışında yaşayan veri olabilir (Steve Trucking’in teslimat fotoğrafları bunun için iyi bir aday). Bu seçimler fiziksel modelde yapılır; ilk görüşmede onları yapmamamızın nedeni de tam olarak budur.

Öznitelikler Fiziksel Alanlara Dönüşür

Aynı geçiş özniteliklerde de olur. Mantıksal Kamyon’umuzun birim numarası, şasi numarası, markası, modeli, model yılı, plakası ve durumu var. Şimdi bunların fiziksel olarak nasıl var olacağına karar veririz: onlara hangi nesnenin sahip olduğu, hangi alan türlerini kullandıkları, hangilerinin zorunlu, hangilerinin benzersiz olması gerektiği, hangilerinin harici tanımlayıcı olduğu, hangilerinin doğrulama gerektirdiği, hangilerinin saklanmak yerine türetildiği ve hangilerinin hassas olduğu. Mantıksal düzeyde Kamyon’un ne anlama geldiğini sorduk. Fiziksel düzeyde Salesforce’un Kamyon’u nasıl temsil edeceğini sorarız. Farklı sorular.

Click to enlarge

İlişkiler Platform Kararlarına Dönüşür

İlişkilere harcadığımız tüm zaman burada karşılığını verir. Her birinin bire-bir mi, bire-çok mu, çoka-çok mu, zorunlu mu isteğe bağlı mı olduğunu ve geçmişinin önemli olup olmadığını zaten biliyoruz. Şimdi Salesforce’un onu nasıl uygulayacağına karar veririz: bir arama ilişkisi, bir ana-ayrıntı ilişkisi ya da bir Salesforce bağlantı nesnesi (Salesforce Junction Object); belki de kendi öznitelikleri olan bir bağlantı, çünkü gördüğümüz gibi ilişkinin kendisinin bir iş anlamı olabilir.

Ekip Ataması’nı düşünün. Bu bölüme “Ekip ile kamyon arasında bir Salesforce bağlantı nesnesi oluşturalım” diyerek başlayabilirdik. Neyi atlayacağımıza bakın: ilişkinin neden var olduğunu, bir tarihe ve bir rotaya ihtiyacı olup olmadığını, bir durumu olup olmadığını ve haftalar sonraki bir hasar talebinin onun geçmişine ihtiyaç duyup duymadığını. Bu iş soruları bize bir Ekip Ataması’nın ne olduğunu söyler. Ancak ondan sonra Salesforce’un onu nasıl inşa edeceğine ve Salesforce’ta bu işi gören bir şeyin zaten olup olmadığına karar vermeliyiz.

Şimdi Fiziksel Modeli Çizin

Diyagram yine değişir. Kavramsal model iş kavramlarını ve basit çizgileri gösteriyordu. Mantıksal model öznitelikleri, anahtarları, kardinaliteyi ve ilişkilerde saklanan varlıkları ekledi. Şimdi fiziksel model Salesforce’a benzemeye başlar: standart nesneler, özel nesneler, alanlar, ilişki türleri ve platform dışında yaşayanlar.

Click to enlarge

Bu üç diyagramı yan yana koyup ilerleyişi görebilmenizi istiyorum: birbiriyle ilgisiz üç diyagram değil, üç düzeyde aynı iş.

Bunları nasıl çizdiğime dair bir not, çünkü yerleşim de mesajın bir parçasıdır. Birincil nesneyi ortaya, biraz aşağıya koyarım. Üst nesneleri varsa onları biraz yukarıya koyarım; böylece modeli işin onu düşündüğü şekilde, yukarıdan aşağıya, soldan sağa okursunuz. Referans verisi kenara gider. Rengin de bir anlamı vardır: Salesforce’u her zaman mavi yaparım, şirketin kendi sistemleri için de bir renk seçerim, genellikle yeşil, çünkü yeşil hoş, dostane bir renktir. Kırmızı kullanmam, sarılar da biraz serttir. Bir model böyle yerleştirildiğinde bana adeta şarkı söyler. Karşınıza çıkacak diyagramların çoğu aslında alan yönetimidir: tıklım tıklım garajıma bütün arabalarımı nasıl park ederim? Ben zihnin kavrayabileceği mantıklı bir resim çizmeyi tercih ederim.

Fiziksel Model Platforma Saygı Göstermelidir

Salesforce genel amaçlı bir ilişkisel veritabanı değildir. İlişkiler, sahiplik, güvenlik ve raporlama hakkında kendi görüşleri vardır. Sınırları, sorgu davranışı ve otomasyonu, bir modelin ölçekte nasıl davrandığını etkileyen bir mimarisi vardır. Dolayısıyla beyaz tahtada mükemmel görünen mantıksal bir model fiziksel hale geldiğinde değişmek zorunda kalabilir. Bu, Salesforce’un yolunuza çıkması değildir. Platformun bir şekli olduğu anlamına gelir ve iyi mimarlar o şekli anlar. Bir sonraki bölüm tam olarak bununla ilgili.

Bazen de fiziksel model, 5. modülde verdiğimiz normalleştirmeyi geri alma kararları nedeniyle temiz mantıksal modelden bilerek farklı olur. Nedenini açıklayabildiğimiz sürece bu sorun değil.

Kurulum’dan Yola Çıkarak Tasarlamayın

Varsa kırmanızı istediğim bir alışkanlık: veri mimarinize Kurulum → Nesne Yöneticisi → Yeni Özel Nesne ile başlamak ve modeli giderken çözmek. Salesforce bir şeyler oluşturmayı inanılmaz kolaylaştırır; bu güçlü yanlarından biridir ve zayıf veri modellerinin bu kadar hızlı ortaya çıkmasının nedenlerinden biridir. Birkaç tıklamayla bir nesneniz, birkaç tıklama daha ile alanlarınız ve bir ilişkiniz olur. Sonra veri gelir, flow’lar inşa edilir, raporlar oluşturulur, entegrasyonlar ona bağımlı hale gelir ve beş dakikada oluşturduğunuz nesneyi değiştirmek çok pahalı olur. Bu, 1. bölümdeki Tersinirlik Testi’dir. Bu yüzden Yeni Özel Nesne’ye tıklamadan önce modeli çizin.

Fiziksel Kalıcı Demek Değildir

Üç modeli ayrı tutmamın bir nedeni daha var: teknoloji değişir. Bugün Steve Trucking’in verisinin bir kısmı Salesforce çekirdeğinde yaşıyor. Yarın bir kısmı Data 360’ta, bir ambarda ya da henüz seçmediğimiz bir sistemde yaşayabilir ve yapay zekâ asistanının kendi temsiline ihtiyacı vardır. Fiziksel mimari değişebilir, iş kavramları ise dikkat çekici derecede sabit kalır: Perakende Ortakları, teslimatlar ve Alıcılar yine vardır. Mantıksal modeli değerli kılan budur. İşin bugünkü uygulamaya bağlı olmayan, kalıcı bir tanımıdır.

Mimarın Burada Karar Verdikleri

Mantıksal bir modeli fiziksel bir Salesforce modeline dönüştürürken karar verdiğim şeyler:

• Hangi iş varlıklarının standart Salesforce yeteneklerine eşlendiği, hangilerinin özel nesnelere ya da başka bir temsile ihtiyaç duyduğu.
• Mantıksal özniteliklerin nasıl fiziksel alanlara dönüştüğü ve ilişkilerin platformda nasıl uygulandığı.
• Bilinçli normalleştirme geri almanın fiziksel tasarımda nereye ait olduğu.
• Hangi verinin Salesforce’a, hangisinin başka bir yere ait olduğu.
• Platformun hangi özelliklerinin fiziksel modelin mantıksal modelden farklı olmasını gerektirdiği.

En önemlisi, her kararı geriye doğru izleyebilmek isterim. Fiziksel modelimdeki bir şeyi gösterip “Bu neden orada?” diye sorarsanız, sizi mantıksal ve kavramsal model üzerinden işin gerçekten ihtiyaç duyduğu bir şeye kadar geri götürebilmeliyim: iş → kavramsal → mantıksal → fiziksel.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yapay zekâ artık bir gereksinim belgesini tek bir sıçramayla Salesforce nesnelerine ve alanlarına kadar götürebiliyor. Bu, sıralamayı daha az değil, daha çok önemli kılıyor: gereksinimlerden doğrudan yapılandırmaya atlıyorsa aradaki adımları göstermesini isteyin: neyin bir varlık olduğuna karar verdiğini, hangi anahtarları seçtiğini, hangi ilişkileri varsaydığını ve nerede normalleştirmeyi geri aldığını. Bunlar mimari kararlardır ve mimarın hâlâ onları görmesi gerekir.

Bu bölüme bir ilk görüşmede, isimlere kulak vererek başladık ve işe kadar geri izleyebildiğimiz fiziksel bir modelle bitiriyoruz. Salesforce üzerinde inşa etmeyi seçtiğimize göre bir sonraki soru daha derine iniyor: gerçekte ne tür bir veri platformu üzerinde inşa ediyoruz?

Daha Fazlası

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (İngilizce, kontrol tarihi 2026-10-02): “üst-alt ilişkilerini tek bir üst kayda en fazla 10.000 alt kayıt olacak şekilde yapılandırın.” Kesin bir sınır değil, veri çarpıklığı hakkında bir yönerge; 7. bölüm daha derine iniyor.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-12): bir toplama özeti, ayrıntı kayıtlarını bir ana-ayrıntı ilişkisi üzerinden sayar ya da toplar.