İçeriğe geç
SteveTechArcSteveTechArc Courses

Standart Veri Modelleri

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Görsel yapay zekâ ile üretilmiştir

Data Architect kursunun 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 2.‘si. Her modül kendi başına okunabilir. Önceki: Salesforce Veri Platformu: Bir Veritabanından Fazlası · Sonraki: Kendinizinkini Oluşturun: Özel Nesneler

Bu modülün yanıtladığı soru: Salesforce sizin için zaten neyi modelledi ve bu nasıl bir araya getirilmiş?

  1. modülde size ana gemiye bakın dedim: bir şey icat etmeden önce Salesforce’un kendisinin bunu nasıl yaptığına bakın. Bu modülde gerçekten bakıyoruz. Salesforce sizin için işin büyük bir kısmını standart nesnelerinde zaten modelledi ve girdiğim org’ların çoğunda işin çoğunu bu modellerden ikisi yapıyor: Satış modeli ve Hizmet modeli. Bir şeyin özel nesneyi hak edip etmediğine karar verebilmek için orada zaten ne olduğunu bilmeniz gerekir. Sonraki iki modülün konusu bu.

Bir Nesneyi Standart Yapan Nedir

Bölüm başlığı “Bir Nesneyi Standart Yapan Nedir ”

Bir standart nesne kutudan çıktığı gibi gelir. Onu Salesforce inşa etmiştir, tanımlı bir amacı vardır ve kendi alanları ve ilişkileriyle birlikte gelir. Ona alan ekleyebilir, etrafında otomasyon kurabilir ve düzenlerini değiştirebilirsiniz, ama onu yeniden tasarlayamazsınız: standart alanlar ve ilişkiler Salesforce’undur.

Adlara bakın. Account, Contact, Case. Önek yok, sonek yok. Bu, Salesforce’un o alanı kendine ayırmasıdır. İnşa ettiğimiz her şey __c ile biter, böylece Salesforce org’unuzdaki hiçbir şeyle çakışmadan istediği zaman yeni standart nesneler ekleyebilir. Ve her sürümde ekler.

Bir noktada biri işe yaramayan bir ürün nesnesi inşa etti ve onun geride bırakılması gerekti. API adının Product2 olmasının nedeni bu. Biri bana Salesforce bildiğini söylediğinde ilk turnusol testim budur.

Satış Modeli

Bölüm başlığı “Satış Modeli ”

Solda, Potansiyel Müşteri ile başlayın: müşteri olabilecek biri. Bir potansiyel müşteri henüz gerçekten modelin bir parçası değildir. Bir bekleme alanıdır. Onu dönüştürdüğünüzde Salesforce gerçek kayıtları oluşturur: bir Hesap, bir Kişi ve bir anlaşma varsa bir Fırsat. Potansiyel Müşteri’yi kenara çizmemin nedeni bu.

Hesap şirkettir. Kişileri oradaki insanlardır. Bir Fırsat o hesapla yapılan bir anlaşmadır. Buraya kadar beklemediğiniz bir şey yok.

Sonra işler ilginçleşir. Anlaşmada ne var? Her satır bir Fırsat Ürünü’dür ve bir Fırsat Ürünü doğrudan bir Ürün’e işaret etmez. Bir Fiyat Defteri Girişi’ne işaret eder: bu ürün, bu fiyatla, bu fiyat defterinde. Fiyat Defteri Girişi Ürün ile Fiyat Defteri arasında durur, böylece aynı ürünün standart fiyat defterinde bir fiyatı, iş ortağı fiyat defterinizde başka bir fiyatı olabilir.

Bu, birbiri ardına şeye dönüşmüş iki ilişki. 2. bölümdeki Teslimat ile Ürün arasındaki Teslimat Kalemi’ni ve Köpek ile Numara arasındaki Köpek Numarası’nı hatırlıyor musunuz? Salesforce burada tam olarak aynı şeyi iki kez yaptı: Fırsat ile Fiyat Defteri Girişi arasındaki Fırsat Ürünü ve Ürün ile Fiyat Defteri arasındaki Fiyat Defteri Girişi. Bunu okuyabildiğinizde standart veri modelinin çoğunu okuyabilirsiniz.

Satış modeli Satış modeli. Solda duran bir Potansiyel Müşteri bir Hesaba dönüşür. Bir Hesabın Kişileri ve Fırsatları vardır. Bir Fırsat bir Fiyat Defteri kullanır ve Fırsat Ürünleri içerir. Her Fırsat Ürünü fiyatını tek bir Fiyat Defteri Girişinden alır. Bir Fiyat Defteri Fiyat Defteri Girişlerini listeler ve bir Ürün Fiyat Defteri Girişlerinde yer alır; böylece her Fiyat Defteri Girişi bir Ürünü ve bir Fiyat Defterini birleştirir. dönüşür sahiptir sahiptir kullanır içerir fiyatını alır listeler yer alır Potansiyel Müşteri Hesap Kişi Fırsat Fiyat Defteri Fırsat Ürünü Fiyat Defteri Girişi Ürün tam olarak bir sıfır veya bir bir veya çok sıfır veya çok © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

İşte o zincir yakından, onu bir arada tutan alanlarla:

Fiyatlandırma zinciri yakından Ayrıntılı bir veri modeli olarak fiyatlandırma zinciri. Bir Fırsat Ürünü Fırsat Kimliğini, Fiyat Defteri Girişi Kimliğini, bir miktarı ve bir satış fiyatını taşır ve fiyatını tek bir Fiyat Defteri Girişinden alır. Fiyat Defteri Girişi Fiyat Defteri Kimliğini, Ürün Kimliğini, bir liste fiyatını ve bir Standart Fiyatı Kullan işaretini taşır. Bir Fiyat Defterinin bir adı ve bir Standart Mı işareti vardır; bir Ürünün bir adı ve bir ürün kodu vardır. fiyatını alır listeler yer alır Fiyat Defteri Fiyat Defteri Kimliği KAYIT KIMLIĞI Ad Standart Mı Fırsat Ürünü Fırsat Ürünü Kimliği KAYIT KIMLIĞI Fırsat Kimliği Fiyat Defteri Girişi Kimliği Miktar Satış Fiyatı Fiyat Defteri Girişi Fiyat Defteri Girişi Kimliği KAYIT KIMLIĞI Fiyat Defteri Kimliği Ürün Kimliği Liste Fiyatı Standart Fiyatı Kullan Ürün Ürün Kimliği KAYIT KIMLIĞI Ad Ürün Kodu tam olarak bir sıfır veya bir bir veya çok sıfır veya çok © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

İnsanların takıldığı bir kural: bir standart fiyat defteri vardır ve başka herhangi bir fiyat defterindeki bir Fiyat Defteri Girişi doğrudan ürünün standart fiyatını kullanabilir. Bir fırsatın ürünlerini yüklemeden önce hangi fiyat defterini kullandığını bilin.

Hizmet Modeli

Bölüm başlığı “Hizmet Modeli ”

Şimdi evin öbür tarafı. Aynı Hesap, aynı Kişiler. Bir şeyler ters gittiğinde müşteri bir Vaka açar.

Vaka genellikle müşterinin sahip olduğu bir şeyle ilgilidir ve Salesforce’un bunun için bir nesnesi vardır: Varlık. 5. modülde ona insanların gözden kaçırdığı standart nesne diyeceğim. Müşterinin sizden satın almış olsun ya da olmasın sahip olduğu bir şeydir.

Peki müşteri neye hak kazanıyor? Bu Yetkilendirme’dir (Entitlement): bir hesabın almaya hak kazandığı destek; çoğu zaman bir varlığa, bir ürüne ya da bir hizmet sözleşmesine bağlıdır. Bir vakaya bir yetkilendirme koyun, artık vaka hangi düzeyde destek alması gerektiğini bilir.

Hizmet modeli Hizmet modeli. Bir Hesabın Kişileri, Vakaları ve Varlıkları vardır. Bir Kişi Vaka bildirir. Bir Vaka tek bir Varlıkla ilgili olabilir ve bir Hesaba ait olan bir Yetkilendirme Vakaları kapsar. Vakadan köşesinin etrafından dolaşıp yine kendisine dönen bir çizgi Üst Vakadır (Parent Case): bir vaka sıfır veya çok vakanın üst vakasıdır ve her vakanın sıfır veya bir üst vakası vardır. sahiptir sahiptir bildirir sahip olur ilgilidir kapsar üst vakası Hesap Kişi Varlık Vaka Yetkilendirme tam olarak bir sıfır veya bir bir veya çok sıfır veya çok © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Vaka’dan kendisine geri dönen çizgiye bakın. Her vakanın bir Üst Vaka (Parent Case) alanı vardır ve başka bir vakaya işaret eder. Bu bir kendine arama ilişkisidir (self-lookup): bir nesneden kendisine giden bir ilişki. Pek çok insanın ilk gördüğünde kafasını karıştırır, bu yüzden onu kullanmamın iki nedeni şunlar.

Bir: daha küçük parçalara bölünen büyük bir sorun. Müşteri tüm kurulumun çöktüğünü bildirir. Ağ, donanım ve yapılandırma için her biri kendi başına çalışılan alt vakalar açarız ve hepsi yukarı doğru çözülür: onlar bitmeden üst vaka bitmez.

İki: geçmiş. Bir vaka geçen ay kapatıldı ve şimdi aynı sorun geri döndü. Yeni vaka orijinaline işaret eder, böylece onu açan herkes bunun daha önce olduğunu ve bu konuda ne yapıldığını görebilir.

  1. modülde ilişkilere geldiğimizde kendine arama ilişkilerine geri döneceğiz.

Hesap ve Kişi’nin her iki diyagramda da aynı yerde durduğuna dikkat edin. Aynı kayıtlardır. Bir satış temsilcisi ve bir hizmet temsilcisi aynı müşteriye evin farklı taraflarından bakıyor. Bu, standartta kalmanın en güçlü gerekçelerinden biridir: modeller buluşmak üzere inşa edildi.

Dosyalar ve Ekler

Bölüm başlığı “Dosyalar ve Ekler ”

Bir kayıttaki her şey bir alan değildir. Sözleşmeler, fotoğraflar, PDF’ler ve elektronik tablolar dosyalardır ve eski (legacy) Ekler modelinde değil, Salesforce Files’ta yer alırlar. Belge zaten SharePoint Online, OneDrive, Google Drive ya da Box’ta yaşıyorsa, Files Connect kullanıcıların onu içeri kopyalamadan Salesforce’tan erişmesini sağlar.

Dosyalar kayıtlardan farklı sayılır. Salesforce depolamayı ikiye ayırır: dosya depolama ekleri, Files’ı, Salesforce CRM Content’i, Chatter dosyalarını ve benzerlerini tutar; veri depolama ise kayıtlarınızı tutar. Her kayda fotoğraf ya da tarama eklendiğinde dosya depolama hızla tırmanır; bu yüzden büyük hacimli görüntüler, örneğin bir saha uygulamasından gelen fotoğraflar, çoğu zaman tamamen Salesforce’un dışında yer almalı, Salesforce’ta yalnızca bir bağlantı kalmalıdır. 4. modül buna geri dönüyor.

İki Sütun ya da İki Yüz

Bölüm başlığı “İki Sütun ya da İki Yüz ”

Veri depolama da bir veritabanından farklı sayılır. Normal bir veritabanında iki sütunlu ve bir milyon satırlı bir tablo küçüktür, yüz sütunlu ve bir milyon satırlı bir tablo ise bir fildir. Salesforce ikisini aynı tartar: kayıtların çoğu, kaç alanı olursa olsun yaklaşık 2 KB sayılır. İstisnalar var. Bir kampanya daha fazla sayılır, bir e-posta mesajı gerçek boyutuyla sayılır ve bir kişi hesabı yaklaşık 4 KB sayılır, çünkü hem bir hesap hem bir kişidir.

Bir ipucu. Yeni bir org’a her girdiğimde ilk gittiğim yerlerden biri Setup → Storage Usage (Kurulum → Depolama Kullanımı) olur. Hatta ilk görüşmede müşteriden bir ekran görüntüsü isterim. O ekran yalan söylemez. Hangi nesnelerin büyüdüğünü ve hangilerinin zaten fil olduğunu söyler.

Kişi Hesapları: Müşteri Bir Kişi Olduğunda

Bölüm başlığı “Kişi Hesapları: Müşteri Bir Kişi Olduğunda ”

Hesap ve Kişi modeli bir şirket ve oradaki insanlar için harika çalışır. Peki ya müşteriniz bir şirket değilse? Ya bir kişiyse?

İşte kişi hesabı budur: bireyler için tek bir kayıtta birleştirilmiş bir hesap ve bir kişi. Kişi alanları da beraberinde gelir ve özel olanlar kendi sonekleriyle, __pc ile görünür. Her biri hem hesap hem kişi depolamasından düşer, çünkü altta ikisidir.

Onları açmadan önce bir uyarı: kişi hesapları etkinleştirildikten sonra devre dışı bırakılamaz. Bu, 1. bölümdeki Tersinirlik Testi’nin en saf halidir. Ne zaman buna değdiğine dair tutumumu 5. modül veriyor.

Mimarın Burada Karar Verdikleri

Bölüm başlığı “Mimarın Burada Karar Verdikleri ”
  • Yeni bir şey tasarlanmadan önce işin hangi kısımlarını Salesforce’un zaten modellediği.
  • Bir kavramın Satış modeline mi, Hizmet modeline mi yoksa ikisine birden mi düştüğü; Hesap ve Kişi’yi paylaştıklarını bilerek.
  • Belgelerin ve görüntülerin nerede yaşadığı: Salesforce Files, bağlı bir dosya sistemi ya da bir bağlantıyla platform dışında.
  • Verinin depolamada neye mal olacağı, Salesforce’un saydığı şekilde sayılarak: sütunlar değil, kayıtlar.
  • Kapatılamayan bir şeyi açmadan önce, müşterinin bir şirket mi yoksa bir kişi mi olduğu.

Peki Salesforce’ta ihtiyacınız olan şey yoksa? Onu siz inşa edersiniz. Sıradaki konu bu.

Daha Fazlası

Bölüm başlığı “Daha Fazlası ”