Bir Veritabanından Fazlası

🌐 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 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 1.‘i. Her modül kendi başına okunabilir. Sonraki: Ana Gemiye Bakın: Standart Veri Modelleri

Bu modülün yanıtladığı soru: Salesforce’u geleneksel bir veritabanından farklı kılan nedir?

Bir süredir Salesforce yöneticisiyseniz bir nesneyi nasıl oluşturacağınızı zaten biliyorsunuz. Kurulum, Nesne Yöneticisi, Yeni Özel Nesne. Bir ad verin, birkaç alan ekleyin, bir sayfa düzeni oluşturun ve on dakika sonra kullanıcılar onunla çalışabilir.

Peki Kaydet’e tıkladığınızda gerçekte ne oldu?

Veritabanı geçmişinden geliyorsanız muhtemelen Salesforce’un gidip yeni bir tablo oluşturduğunu hayal ediyorsunuz. Oluşturmadı. Ve nedenini anlamak, bir yönetici ya da geliştirici gibi düşünmekten bir mimar gibi düşünmeye geçmeye başladığınız yerlerden biridir.

Salesforce elbette veri saklar; altında veritabanları vardır. Ama Salesforce üzerinde güzel bir ekran olan bir veritabanı değildir. Meta veri odaklı bir uygulama platformudur ve bu ayrım bu kurstaki neredeyse her kararı şekillendirir.

Platformun Bir Şekli Vardır

2. bölümde modeli Salesforce’u hiç dert etmeden kurduk. Bu bilinçliydi: isimlere kulak verdik, kavramsal modeli kurduk, öznitelikleri, anahtarları ve ilişkileri ekledik ve ancak ondan sonra Salesforce’un onu nasıl uygulaması gerektiğini sorduk. Şimdi onu üzerinde uyguladığımız şeyi anlamamız gerekiyor.

Bunun için basit bir ifade kullanırım: platformun bir şekli vardır. Salesforce bize nesneler, alanlar, ilişkiler, güvenlik, otomasyon, API’ler, işlemler, raporlama ve arama verir ve bunların hepsi birbirine bağlıdır. Bir nesne oluşturduğumda yalnızca satırları koyacak bir yer oluşturmuyorum. Güvenlik modelinde yer alan, otomasyonun üzerinde işlem yapabildiği, API’lerin dışarıya açtığı, raporların kullanabildiği, diğer nesnelerin ilişki kurabildiği ve kullanıcıların, entegrasyonların ve giderek daha fazla ajanın bağımlı olacağı bir şey oluşturuyorum. Bu bir tablodan çok daha fazlasıdır.

Meta Veri Plandır

Bir bina düşünün. Binanın kendisi vardır, bir de onu tanımlayan plan: duvarların nerede olduğu, kapıların nereye geldiği, odaların nasıl bağlandığı. Salesforce da aynı şekilde çalışır. Bir nesne tanımı meta veridir. Bir alan tanımı meta veridir. Bir ilişki meta veridir. Kurulum’da yapılandırdığımız şeylerin çoğu meta veridir ve platform, org’umuza yapısını ve davranışını vermek için onu çalışma zamanında okur.

Salesforce platformun kalbini hem çok kiracılı hem de meta veri odaklı olarak tanımlar: bir nesne ya da alan tanımladığımızda tanım, org’umuz için yeni bir fiziksel tablo ya da sütun olarak değil, meta veri olarak saklanır (Platform Multitenant Architecture (opens in a new tab), İngilizce).

Bunu öğretirken kaputu açarım. Salesforce her nesne eklediğinizde sizin için yeni bir veritabanı oluşturmuyor. Kendi tablolarına bir kayıt ekliyor: bir nesneler tablosu, bir alanlar tablosu, bir veri tablosu ve dizinler ile ilişkiler için pivot tablolar; hepsi org’unuzun verisini diğer herkesinkinden ayrı tutan bir org tanımlayıcısıyla anahtarlanmış. Yani bir alan eklemek yalnızca bir girdi eklemektir. Bu yüzden öğle arasında, canlı ortamda, anında bir alan oluşturabilirsiniz.

Bu, insanların takıldığı bir şeyi de açıklar. SELECT Id, Name, Special__c FROM Account yazdığınızda tek bir tablo gibi görünür. Altında, standart nesneyi ve onun özel alanını farklı yapılardan okuyorsunuz; yani platform sizin hiç yazmadığınız bir birleştirme (join) yapıyor. Dizinler vardır, ama geleneksel bir veritabanı dizini gibi çalışmazlar. Sınav için iç yapıyı bilmeniz gerekmez. Bilmeniz gereken, Nesne Yöneticisi’nde gördüğünüzün fiziksel tabloların bire bir resmi olmadığı ve bu soyutlamanın hem platformun gücü hem de onun böyle davranmasının nedeni olduğudur.

Click to enlarge

Ana Gemiye Bakın

Derste insanlara söylediğim şeylerden biri ana gemiye bakmalarıdır. Salesforce’ta bir şeyi yapmanın karmaşık bir yolunu icat etmeden önce Salesforce’un kendisinin onu nasıl yaptığına bakın.

Hesap’ı alın. Onu siz oluşturmadınız; Salesforce oluşturdu. Ama ona alanlar ekleyebilir, etrafında otomasyon kurabilir, düzenlerini değiştirebilir, API’ler aracılığıyla dışarıya açabilir ve başka nesneleri onunla ilişkilendirebilirsiniz. Özel nesneler aynı mekanizma üzerinde çalışır; standart ve özel nesnelerin üzerlerinde geliştirme yaparken bu kadar benzer hissettirmesinin nedeni budur. Apex’te ortak bir temel sınıfı bile paylaşırlar: sObject.

Bu bölümün üzerine kurulduğu alışkanlık budur ve sonraki modülde gerçekten bakıyoruz: Salesforce’un sizin için zaten inşa ettiği standart veri modellerine.

Salesforce’un yanında inşa etmiyoruz. Onu genişletiyoruz.

API’niz Nesneyle Birlikte Geldi

Geleneksel bir veritabanında bir tablo oluşturursanız bir tablonuz olur. Başka bir uygulamanın onunla çalışması gerekiyorsa birinin yapacak daha çok işi vardır. Salesforce’ta bir nesne oluşturursanız platform onu uygulama ve entegrasyon katmanları aracılığıyla zaten anlar: REST ve SOAP API’lerini sağlamak için aynı meta veriyi kullanır, böylece nesne var olur olmaz kayıtları bu API’ler üzerinden oluşturulabilir, okunabilir, güncellenebilir ve silinebilir (Platform Multitenant Architecture (opens in a new tab), İngilizce).

Bir nesne oluşturdum diye bir API tasarlamadım. Platform nesneyi, alanlarını, türlerini, ilişkilerini ve güvenliğini bilir. Salesforce geliştirmesinin bu kadar hızlı ilerlemesinin bir nedeni bu. Bir nesne oluşturmanın göründüğünden daha büyük bir karar olmasının nedeni de bu: bir yapıyı koca bir uygulama platformuna takıyorsunuz. Ve bu öbür yönde de geçerli. SQL Server ya da Oracle’dan gelen insanlar bazen bana veriyi doğrudan veritabanına nasıl yükleyeceklerini sorar. Yükleyemezsiniz. Her şey API’ler üzerinden gelir.

Apartman

Şimdi sürekli duyduğunuz sözcük: çok kiracılılık. Ben onu bir apartman olarak düşünürüm.

Kendi dairenizdesiniz. Eşyalarınız size ait ve anahtarınız benim kapımı açmamalı. Ama binayı paylaşıyoruz: elektrik, su, asansörler, giriş holü. Org’unuz verinizle, nesnelerinizle, otomasyonunuzla size ait bir ortam gibi hissettirir. Altında Salesforce her org’u bir kiracı olarak tanımlar; altyapı ve hizmetler paylaşılırken her kiracının verisini, meta verisini ve mantığını yalıtır (Platform Multitenant Architecture (opens in a new tab), İngilizce). Her müşteri için ayrı bir altyapı çalıştırmadan herkese bu kadar özelleştirilebilir bir platform sunabilmesi böyle mümkün olur.

Ama binayı paylaşmanın sonuçları vardır. Bir kiracı kocaman bir klima alıp aynı anda saç kurutma makinesini ve fırını çalıştırırsa sigortayı attırır ve bütün kat karanlığa gömülür.

Asansörü Ele Geçiremezsiniz

Binada bir dakika daha kalın. Bir sakinin “Asansöre sekizden öğlene kadar ihtiyacım var. Başka kimse kullanamaz” dediğini düşünün. Bu, paylaşılan bir binada işe yaramaz ve Salesforce’ta da işe yaramaz. Bir kiracının paylaşılan kaynakları sınırsızca tüketmesine ve platformu diğer herkes için kötüleştirmesine izin verilemez.

Yönetici sınırları (governor limits) buradan gelir. Salesforce’ta geliştirme yaptıysanız muhtemelen onlarla ezberlenecek bir sayı listesi olarak tanıştınız. Onları böyle düşünmenizi istemiyorum. Salesforce, bir kiracının iş yükünün paylaşılan işlem gücünü tekeline almaması için işlem ve org düzeyinde sınırlar uygular (Architecture Basics (opens in a new tab), İngilizce). Mimari budur; her bir sınır yalnızca onun uygulamasıdır. Kursun ilerleyen kısımlarında belirli sınırları bir tasarımı değiştirdikleri için önemseyeceğiz. Şimdilik binayı hatırlayın: dairenizi yeniden düzenlemek için muazzam bir özgürlüğünüz var. Asansörü ele geçiremezsiniz.

Salesforce Kimlikleri Soyutlamanın Bir Parçasıdır

Her Salesforce kaydının platformun anladığı bir kimliği vardır, kayıt kimliği, ve her yetenekte çalışır: arayüz, API’ler, raporlar, otomasyon.

2. bölümde iyi bir anahtarın benzersiz, değişmez, anlamsız ve asla kişisel veri olmayan bir anahtar olduğunu söyledik. Salesforce kimliği Salesforce için buna uyar. Ama bir iş anahtarıyla aynı şey değildir. Şirketinizin sistemler arasında bir anlam taşıyan bir ERP müşteri numarası, bir personel numarası ya da bir ortağın sipariş numarası hâlâ olabilir. “Salesforce bunun hangi kayıt olduğunu biliyor” ile “kurum bunun hangi iş varlığı olduğunu biliyor” ifadelerini karıştırmayın. Bunlar farklı kimlik sorunlarıdır ve ikincisi entegrasyonda ve ana veride geri gelir.

Nesneler Depolamadan Fazlasıdır

Bu bölümün geri kalanından önce yapmanızı istediğim zihinsel geçiş şu. Bir nesne yalnızca veri saklanacak bir yer değildir. Bir alan yalnızca bir sütun, bir ilişki de yalnızca bir yabancı anahtar değildir. Öğretirken veritabanı karşılaştırmalarını kullanırım, çünkü insanların zaten bildikleriyle bağ kurarlar. Ama orada durursak mimariyi kaçırırız.

Seçtiğimiz nesne, onunla birlikte hangi yeteneklerin geleceğini belirler. Alan türü doğrulamayı, entegrasyonu, aramayı, raporlamayı ve diğer sistemlerin veriyi nasıl okuduğunu etkiler. İlişki yaşam döngüsünü, sahipliği, paylaşımı ve silmeyi belirler. Veriyi nereye koyduğumuz depolamayı, performansı ve ölçeği etkiler. Ve bunların hepsi paylaşılan bir platformda çalıştığı için yüz kayıtla zararsız olan bir seçim yüz milyon kayıtla çok farklı davranabilir. Bu kararları tek tek ele alacağız.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yıllarca iyi adlar ve açıklamalar, bir sonraki yöneticinin ya da geliştiricinin inşa ettiğimiz şeyi anlamasına yardım etti. Artık bu bağlamı makineler de okuyor. Flag2__c adlı bir alanla çalışan bir yapay zekâ sistemi yeni bir geliştiriciyle aynı sorunu yaşar: bu şey ne anlama geliyor? Meta veri artık süs değil; makinelerin uygulamayı anlama biçiminin bir parçası.

Mimarın Burada Karar Verdikleri

• Gerçekte üzerinde olduğum platform için mi tasarım yapıyorum, yoksa Salesforce’a genel amaçlı bir veritabanı gibi mi davranıyorum?
• Tasarımımın hangi kısımları iş kavramları, hangileri Salesforce uygulama seçimleri?
• Oluşturmak üzere olduğum yapıyla birlikte hangi platform davranışları geliyor?
• Hangi sınırlar paylaşılan mimarinin ifadeleri ve bunlardan hangileri bu tasarımı şekillendirecek?
• Bu yapıyı sonradan değiştirmek zor olacaksa, ona bir mimari karar olarak mı davranıyorum?

2. bölümde Kurulum’dan yola çıkarak tasarlamayın dedik. Artık bir neden daha biliyorsunuz. Yeni Özel Nesne’ye tıklamak size yalnızca bir tablo vermez; mimarinizin bir parçasını daha meta veri odaklı, çok kiracılı bir platforma bağlar. Ama hangi nesneyi oluşturacağınıza karar vermeden önce daha temel bir soru var: bu veri hiç burada mı yaşamalı? Sırada o var.

Daha Fazlası

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02, yeniden kontrol 2026-10-12: nesne ve alan tanımları yeni tablolar olarak değil meta veri olarak saklanır; OrgID ile anahtarlanan paylaşılan tablolar (MT_Objects, MT_Fields, MT_Data, MT_Indexes); REST ve SOAP API’lerini aynı meta veri sağlar.
• Salesforce Architects, Architecture Basics (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02, yeniden kontrol 2026-10-12: kod ve işlemlerin “paylaşılan işlem kaynaklarını tekelleştirmemesi” için yönetici ve yürütme sınırları.