Mantıksal Modeli Kurun

🌐 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 3.‘sü. Her modül kendi başına okunabilir. Önceki: İlişkileri Çizin · Sonraki: Veriyi Ait Olduğu Yere Koyun

Bu modülün yanıtladığı soru: Kavramsal bir modeli mantıksal bir veri modeline nasıl dönüştürürüm?

Kavramsal model bize Steve Trucking’de neyin var olduğunu ve nasıl ilişkili olduğunu söyledi: Perakende Ortakları ve dağıtım merkezleri, yük listeleri ve teslimatlar, Alıcılar, rotalar ve duraklar, ekipler, kamyonlar ve ekip atamaları. Bu, iş birimiyle çok verimli bir konuşma için yeterli. Ama sonunda daha fazla ayrıntıya ihtiyacım olur. Bir teslimat hakkında neyi bilmemiz gerekiyor? Bir dağıtım merkezini diğerinden farklı kılan nedir? Bir Alıcıyı nasıl tanımlarız? Ekibe ya da kamyona değil de ekip atamasına ait olan nedir? Bu sorular bizi kavramsal modelden bir mantıksal veri modeline doğru götürür ve hâlâ Salesforce’ta bir şey inşa etmiyoruz.

Otur, Bekle, Modelle

Önce köpeklere dönelim. Kutularımız ve çizgilerimiz var. Şimdi iki yeni soru: her şey hakkında ne biliyoruz ve birini diğerinden nasıl ayırt ederiz?

Onu ne tanımlar? Bir köpeğin adı ve doğum tarihi vardır. Bir sahibin adı, telefon numarası ve adresi vardır. Bir numaranın adı ve zorluğu vardır. Her olgu, tanımladığı kutuya konur.

Sonra bağlantı. Bella’nın Otur’u ne kadar iyi yaptığı ve onu ne zaman öğrendiği: bu Bella’yı mı tanımlar? Tam olarak değil; bazı numaralarda diğerlerinden daha iyi. Otur’u mu tanımlar? Hayır; her köpek Otur’u farklı yapar. Bella’yı ve Otur’u birlikte tanımlar, bu yüzden Köpek Numarası’na aittir: beceri düzeyi ve öğrenme tarihi. Bağlantının var olma nedeni budur: bazı olgular yalnızca çifte aittir.

Hangi köpek hangisi? Önce adı deneyin. Max adında çok köpek var, yani ad benzersiz değil. Sahibin telefon numarası mı? Marcus’un aynı telefonda iki köpeği var, insanlar numara değiştirir ve bu birinin kişisel verisidir; bir köpeğe işaret eden her sisteme kopyalanırdı. Mikroçip numarası daha iyi görünüyor: benzersizdir ve değişmez. Ama yeni bir yavruya henüz çip takılmamış olabilir ve bir anahtar boş olamaz. Bu yüzden mikroçip, köpeğin aynı zamanda bilindiği bir şey olarak kalır ve köpek kendi Köpek Kimliği’ni (Dog ID) alır: tek bir sıkıcı iş yapan bir numara, bir köpeği diğerinden ayırt etmek.

Click to enlarge

Bunlar şimdi Steve Trucking’e soracağımız soruların aynısı ve adın, telefonun ve mikroçipin her birinin neden yetersiz kaldığına dair nedenler, yıllardır savunduğum bir kurala dönüşüyor.

Kavramsal Model Neyin Var Olduğunu, Mantıksal Model Veri Olarak Ne Anlama Geldiğini Söyler

Kamyon’u alın. Bir kamyon hakkında neyi bilmem gerekir? Belki birim numarasını, şasi numarasını (VIN), markasını, modelini, model yılını, plakasını, güncel kilometresini ve durumunu. Bunlar Kamyon’un öznitelikleridir.

Şimdi Teslimat’ı alın. Belki Perakende Ortağının sipariş numarası, teslimat tarihi, söz verilen zaman aralığı, gerçek varış saati, durum ve bir kurulum ya da eski ürünün götürülmesini içerip içermediği. Yine öznitelikler.

Kavramsal model bize Teslimat’ın var olduğunu söyledi. Mantıksal model bir teslimatın veri olarak ne anlama geldiğini söylemeye başlar. Kamyon ya da Teslimat gibi basit bir kutu, koca bir alan kümesini temsil edebilir.

Click to enlarge

Yine de diyagramlarımızın çoğunda kutular üç nedenle sade kalır. Alan sayısı artar. Alanlar çabucak eskir. Ve her alanın bir nesne modelinde göstermesi zor ayrıntıları vardır: API adı, etiketi, veri türü ve uzunluğu. Bu ayrıntılar kesinlikle kayıt altına alınacak, yalnızca ilk veri modelinde değil. Birkaç temel alanı göstermek hikâyeyi anlatmaya gerçekten yardım ettiğinde bir ayrıntılı veri modeli çizeceğim: yalnızca konuyla ilgili alanları içeren, odaklanmış bir kesit.

Öznitelikler Varlığı Tanımlamalıdır

Bir özniteliğe bakarken kullandığım basit bir soru var: bu neyi tanımlıyor? Kamyonun markası açıkça kamyonu tanımlar. Peki bir teslimattaki ekip üyelerinin adları? Teslimatı mı tanımlarlar? Yoksa bir ekip ataması olan, o atamayla rotayı üstlenen, o rotada da bu durağın bulunduğu bir ekibi mi tanımlarlar?

Bir veri modelinin, ekranda gayet makul görünen şeyleri açığa çıkarmaya başladığı yer burasıdır. Bir koordinatör “Ekibin adlarını teslimatta görmek istiyorum” der. Bu geçerli bir kullanıcı deneyimi gereksinimidir. Ekibin adlarını teslimatta saklamak için bir gereksinim olması gerekmez. Bunlar iki farklı şeydir ve normalleştirmede buna döneceğiz. Şimdilik bu olgunun gerçekte neyi tanımladığını sorma alışkanlığı edinin. Bu soru sizi pek çok dertten kurtaracak.

Sonra Benzersiz Kimliklerden Bahsetmemiz Gerekir

Öznitelikler şeyleri tanımlar. Ama çözülmesi gereken başka bir sorun var: hangi şeyin hangisi olduğunu nasıl bilirim?

İki Alıcının adı John Smith. Aynı kişi mi? Belki; belki de değil. Bir ad yeterli değildir. Adres mi? İnsanlar taşınır. Telefon numaraları değişir. E-posta adresleri değişir. Bir Perakende Ortağının adı bile değişebilir.

Bu bizi anahtarlara getirir: modelimizde bir şeyi benzersiz biçimde tanımlamamızı sağlayan şey. Yıllar içinde oldukça güçlü bir görüş geliştirdiğim bir alan bu. Bir tanımlayıcıdan dört şey isterim:

Benzersiz. Değişmez. Anlamsız. Asla kişisel veri (PII) değil.

Benzersiz. Bir tanımlayıcı tam olarak tek bir şeyi tanımlamalıdır. İki teslimat aynı değere sahip olabiliyorsa bu güvenilir bir teslimat tanımlayıcısı değildir. Adlar genellikle benzersiz değildir, adresler mutlaka benzersiz değildir ve telefon numaraları paylaşılır. Bugün benzersiz görünen değerler bile yeterince veriniz olduğunda benzersiz olmayabilir. Öyleyse sorun: bunlardan ikisi hiç aynı değere sahip olabilir mi? Yanıt evetse onu kaydın benzersiz kimliği olarak kullanmakta çok dikkatli olun.

Değişmez. Bu gözden kaçar. Bir Perakende Ortağını adıyla tanımlıyorsak ve ortak adını değiştirirse yeni bir ortağımız mı oldu? Hayır. İş varlığı aynı kaldı; özniteliklerinden biri değişti. Bir kaydın benzersiz kimliği, tanımladığı şeydeki değişikliklerden sağ çıkmalıdır; bu da bir sistemi ilk kurarken ne kadar kullanışlı görünseler de adları, e-posta adreslerini, telefon numaralarını, adresleri ve kullanıcı adlarını dışarıda bırakır.

Anlamsız. Bunu ilk duyduğunuzda tuhaf gelir. Neden bir tanımlayıcının anlamsız olmasını isteyeyim? Çünkü anlam değişir. Birinin DC’yi, Perakende Ortağını, teslimat tarihini ve bir sıra numarasını kodlayan bir teslimat kimliği oluşturduğunu düşünün: PHX-KEY-20261002-0042. Zekice görünüyor. Sonra Alıcı teslimatı Cuma’ya erteliyor. Tanımlayıcıyı değiştirir miyiz? Değiştirmezsek bize yalan söylüyor. Değiştirirsek, özniteliklerinden biri değişti diye teslimatın benzersiz kimliğini değiştirmiş oluruz ve eski kimliği saklayan her sistem onun izini kaybeder. Tanımlayıcı iki iş yapmaya çalışıyordu: teslimatı tanımlamak ve onu betimlemek. Ben betimlemeyi özniteliklere bırakmayı, tanımlayıcıya da tek bir sıkıcı iş vermeyi tercih ederim: onu tanımlamak. Sıkıcı tanımlayıcılar iyi tanımlayıcılardır.

Asla kişisel veri değil. Bu o kadar önemli ki ayrı tutuyorum. Benzersiz görünüyor diye kişisel olarak tanımlanabilir bilgiyi (PII) tanımlayıcı olarak kullanmayın. Steve Trucking’de bir Alıcıyı telefon numarasıyla tanımak caziptir. Ama bir anahtar, sistemlerin kayıtları birbirine bağlaması gereken her yere kopyalanır: entegrasyonlar, dışa aktarımlar, günlükler, Perakende Ortaklarına geri giden durum dosyaları, veri ambarı, test verisi. Bir telefon numarasını anahtar yaparsanız bir Alıcının kişisel verisini tüm mimariye yaymış olursunuz.

Bir anahtar ayrıca her kayıt için var olmalıdır: asla null ya da boş değil. Bazı insanlar bir değeri size vermeyecekse ya da vermek zorunda olmamalıysa, o değer anahtar olamaz. Sistemlerin kendi iç tanımlayıcılarını üretmesinin nedeni budur; kişisel veri ise, gerçekten gerekiyorsa, korunan bir öznitelik olur.

Yani kuralım şu: benzersiz, değişmez, anlamsız, asla kişisel veri değil.

Doğal Anahtarlar ve Vekil Anahtarlar

Veritabanıcıların bunların bir kısmı için adları vardır. Doğal anahtar iş verisinde zaten vardır: bir kamyonun şasi numarası iyi bir örnektir. Onu uygulamamız icat etmedi ve zaten bir anlamı var. Vekil anahtar ise özellikle kaydı tanımlamak için oluşturulur; hiçbir şeyi betimlemez, yalnızca tanımlar.

Çoğu mimaride iç kayıt kimliği olarak bir vekil anahtarı tercih eder, önemli doğal tanımlayıcıları öznitelik olarak tutarım. Bu, doğal tanımlayıcıları kötü yapmaz; çoğu zaman son derece önemlidirler. Yalnızca onları otomatik olarak kaydın benzersiz kimliği yapmam. Değer düzeltilirse, yeniden biçimlendirilirse, değiştirilirse, yeniden kullanılırsa, eksikse ya da birden fazla kaynak sistemden gelirse ne olacağını sorun. Basit görünen bir karar orada bir mimari karara dönüşür.

Bir Şeyin Birkaç Yararlı Tanımlayıcısı Olabilir

İç kayıt kimliği, diğer her sistemin kullandığı tanımlayıcı olmak zorunda değildir. Steve Trucking bir teslimatı içeride üretilmiş bir kimlikle tanımlayabilir. Her Perakende Ortağı aynı teslimatı kendi sipariş numarasıyla bilir: Keystone CSV yük listesinde, Redrock API’sinde, Brightwave EDI mesajlarında. Ve eski sevk aracı RouteDesk’teki sekiz yıllık geçmiş, RouteDesk’in kendi teslimat kimliklerini kullanır.

Bu tanımlayıcılar önemlidir. Onları tutmamız ve doğru eşlememiz gerekir, çünkü bir durum güncellemesi her ortağa onun numarasıyla geri gitmelidir. Ama hepsinin teslimatın benzersiz kimliği olması gerekmez. “Kimliği ne?” sorusunun birden fazla yanıtı olabilir ve mimar hangi bağlamda hangi kimliğin esas olduğunu bilmelidir. Ana veri ve entegrasyonda buna döneceğiz.

İlişkiler Benzersiz Kimliklere Dayanır

Şimdi çizdiğimiz çizgilere dönün. Bir yük listesi teslimatları listeler. Bir Alıcı teslimatlar alır. Bir ekibin ekip atamaları vardır. Bu ilişkiler ancak her iki uçtaki şeyleri güvenilir biçimde tanımlayabildiğimiz için çalışır.

Steve Trucking’de işin can yaktığı yer burası. Bir Perakende Ortağı yük listesini aynı gün revize ediyor: bir sipariş iptal edilmiş, bir ürün değiştirilmiş, yeni bir adres. Revize edilen satırı elimizdeki teslimatla ortağın sipariş numarası üzerinden eşleştiremezsek aynı buzdolabı için ikinci bir teslimat oluştururuz ve bir ekip iki kez kapıya gelebilir. Kutular, öznitelikler, anahtarlar ve ilişkiler ayrı fikirler değildir. Hepsi aynı modelin parçalarıdır.

Click to enlarge

Bu noktada “Salesforce her kayda bir kimlik veriyor” diye düşünüyor olabilirsiniz. Doğru, oraya geleceğiz. Veri Salesforce’ta yaşıyorsa her kayıt Salesforce’un ürettiği bir kimlik alır. Şifreli ve okunması zordur; bu yüzden genellikle insanların kullanabileceği bir kimlik alanı da sunarız; örneğin bir Otomatik Numara alanı olan D-000184227 gibi bir teslimat numarası. İnsanlar çoğu zaman bu numaranın kaydın kimliği olduğunu düşünür, ama değildir: Salesforce kimliği hâlâ altındadır. Harici bir sistemin ya da Oracle veya SQL Server gibi bir veritabanının da kendi benzersiz kimlikleri vardır. Ama mimari sonunda Salesforce’u, finans ERP’sini, Snowflake’i, Data 360’ı, ortakların sistemlerini ve henüz var olmayan sistemleri içerebilir. Mantıksal model, her kararı tek bir teknolojiye bağlamadan iş verisini tanımlar. Salesforce’un onu fiziksel olarak nasıl uygulayacağı sonraki bir adımdır.

Mimarın Burada Karar Verdikleri

Kavramsal bir modeli mantıksal bir modele dönüştürürken karar verdiğim şeyler:

• Hangi özniteliklerin her varlığı gerçekten tanımladığı.
• Her varlığın nasıl benzersiz biçimde tanımlandığı ve o tanımlayıcının benzersiz kimlik olacak kadar sabit olup olmadığı.
• Hangi iş tanımlayıcılarının (ortak sipariş numaraları, eski sistem kimlikleri) tutulması ve eşlenmesi gerektiği.
• Hassas bilginin anahtar olarak kullanılıp kullanılmadığı.
• İlişkilerin varlıkları güvenilir benzersiz kimlikler üzerinden bağlayıp bağlamadığı.

Artık varlıklarımız, ilişkilerimiz, özniteliklerimiz ve benzersiz kimliklerimiz var: gerçek bir mantıksal veri modelinin başlangıçları. Ama hâlâ bir sorun var. Tamamen geçerli veriyi yanlış yere koymak çok kolaydır. Normalleştirme tam burada devreye girer.

Daha Fazlası

• Custom Field Types (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09): Otomatik Numara, her kayda önek ve baştaki sıfırlar gibi bir görüntüleme biçimiyle benzersiz bir numara atar; bu, kaydın Salesforce kimliği değildir. Ayrıca bkz. Auto-Number Fields Are Not Always Sequential (opens in a new tab) (İngilizce, kontrol tarihi 2026-10-09).