Sözlük, Köken ve Sınıflandırma

🌐 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 5. bölümü olan Veri Kalitesi ve Yönetişim bölümündeki 6 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Kötü Veriyi Dışarıda Tutmak · Sonraki: Gizlilik Yasaları Tasarımı Şekillendirir

Bu modülün yanıtladığı soru: Verinin ne anlama geldiğini, nereden geldiğini ve ne kadar hassas olduğunu nasıl kayıt altına alırsınız?

Bir org devraldınız. Hesap’ta 900 alan var, aralarında Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c ve Account_Status__c. Hangisi birinin gerçekten müşteri olup olmadığını söylüyor? Açıklamaları açıyorsunuz. Üçü boş. Biri “Customer Type” diyor. Teşekkürler. Biri ERP’den geldiğini söylüyor; bir diğeri altı yıl önce çoktan ayrılmış biri tarafından oluşturulmuş. Şimdi mimar değil de bir entegrasyon, bir raporlama ekibi ya da bir ajan olduğunuzu düşünün. Kuruluşun bol miktarda verisi var. Bu, verinin ne anlama geldiğini bildiği anlamına gelmez.

Meta verinin mimariye dönüştüğü yer burasıdır; birbiriyle ilişkili ama aynı olmayan üç soru aracılığıyla:

• Sözlük: bu veri ne anlama geliyor?
• Köken: nereden geldi?
• Sınıflandırma: nasıl ele alınmalı?

İki Tür Meta Veri

Meta veri iki türde gelir ve ikisine de ihtiyacınız var. İş meta verisi, verinin iş için ne anlama geldiğidir: tanım, sahip, kullanım kuralları, ne kadar hassas olduğu. Teknik meta veri ise nasıl kurulduğu ve nasıl hareket ettiğidir: nesne ve alan, tür ve uzunluk, API adı, şema, bir sistemden diğerine eşleme, kaynaktan hedefe köken. Bir alanın API adı ve türü bir geliştiriciye onu nasıl kullanacağını söyler; tanımı ve sahibi ise diğer herkese onu kullanıp kullanmayacağını. İkisi çeliştiğinde ya da biri eksik olduğunda, entegrasyonlar ve raporlar tam orada ters gider.

Sınav bilgisi. İş meta verisini (anlam, tanımlar, sahip, kurallar, hassasiyet: iş sözlüğü ve sınıflandırma) teknik meta veriden (nesneler, alanlar, türler, API adları, şemalar, eşlemeler ve köken) ayırt edin.

Anlamla Başlayın

3. bölüm kuralı koydu: her alan bir açıklama alır. Customer Status adlı bir alan için “Customer Status” değil, şuna benzer bir şey: “Ortağın Steve Trucking ile güncel ticari ilişkisi. Etkinleştirmeden sonra ERP’den ayarlanır. Potansiyel müşteri değerlendirmesi için kullanmayın.” Artık ne anlama geldiğini, nereden geldiğini ve ne için kullanılmaması gerektiğini biliyorum. Bu bir iş sözlüğünün başlangıcıdır: önemli veri için ortak tanımlar. Müşteri nedir? Aktif müşteri? Teslim edildi ne anlama gelir? Ne zamanında sayılır? Bunlar beş departmanı bir odaya koyana kadar apaçık görünür: Finans’ın bir tanımı, Satış’ın bir başkası, Operasyon’un üçüncüsü, ambarın dördüncüsü vardır ve biri beşincisinin üzerine bir gösterge panosu kurmuştur. Sorun kimsenin aynı dili konuşmaması değil. Kurumun anlam üzerinde anlaşmamış olmasıdır.

Bir sözlük bir elektronik tabloda ya da bir belgeleme aracında yaşayabilir, ama önemli tanımlarının insanların veriyi kullandığı yere yakın durması gerekir. Platformda bu, alan açıklamaları, yardım metni ve sınıflandırma meta verisidir. Analitikte daha da önemlidir: “gelir” yönetici gösterge panosunda bir şey, bir analistin sorgusunda başka bir şey anlamına gelemez. Anlamsal katman bunun içindir ve Data 360’ın anlamsal modelleri, fiziksel verinin üzerinde metrikler, boyutlar ve ilişkiler gibi yönetilen tanımları tutar (Create a Semantic Model in Data 360 (opens in a new tab), İngilizce). Teknoloji değişir; gereksinim değişmez: önemli verinin üzerinde anlaşılmış bir anlamı olmalıdır.

Ve teknolojiyle değil, anlamla başlayın. Nesne, alan, tür ve API adıyla başlayan bir sözlük uygulamayı belgeler. İş terimleriyle başlayan bir sözlük kurumu belgeler:

İş terimi	Anlamı	Nerede temsil ediliyor
Perakende Ortağı	Steve Trucking’in sözleşmeyle adına teslimat yaptığı bir perakendeci	Salesforce Hesabı; finans ERP’si müşterisi
Teslimat	Bir günde, bir adreste, bir Alıcıya yapılan tek bir teslimat	Bugün RouteDesk; teslimatlar Salesforce’a taşındığında bir iş emri
Alıcı	Bir teslimatı teslim alan kişi	Teslimattaki Alıcı bilgileri
Teslim edildi	Üzerinde anlaşılmış operasyonel tanıma göre tamamlandı	Teslimat durumu
Zamanında teslimat	Üzerinde anlaşılmış teslimat zaman aralığı içinde tamamlandı	Türetilmiş metrik

Click to enlarge

Tek anlam, pek çok teknik temsil.

Sonra Nereden Geldiğini Sorun

Bir değerin ne anlama geldiğini bildiğimde nereden geldiğini bilmek isterim. Bu kökendir (lineage). Salesforce’taki bir ortağın yasal adı: bir temsilci mi yazdı, ERP mi gönderdi, bir entegrasyon mu dönüştürdü, Data 360 mı birleştirdi, hesaplandı mı, yapay zekâ mı üretti? Bunlar ona ne kadar güvendiğimi ve onunla ne yapabileceğimi etkiler. 2. modüldeki geçici kayıtları hatırlayın: iki hesap da “Keystone” diyebilir; biri dün bir temsilci tarafından oluşturulmuş, diğeri esas bir tanımlayıcıyla ERP’den gelmiş. Aynı metin, farklı köken, farklı muamele.

Köken yalnızca bir veri mühendisinin bin tablodan oluşan diyagramı değildir. Önemli veri için pratik soruları yanıtlamak isterim: nerede başladı, esas sistem hangisi, onu ne dönüştürdü, hangi sistemler kopya aldı, onu en son ne değiştirdi ve türetilmiş bir değeri kaynaklarına kadar izleyebilir miyim? 4. bölümün haritası sistemlerin bağlı olduğunu söyler. Köken, verinin yolda başına ne geldiğini söyler.

Bazı köken bilgileri bedavadır: hesaptaki ERP kimliği, Oluşturan ve Son Değiştiren, entegrasyon günlükleri, eşleme belgeleri. Data 360, veri nesnelerine her kaydın veri kaynağını ve kaynak nesnesini kaydeden köken alanları ekler (Data Lineage Fields (opens in a new tab), İngilizce). Ama sistemler entegre diye kökenin kendiliğinden ortaya çıkacağını varsaymayın. Bazen en yararlı köken tek bir alandır: Kaynak Sistem = Keystone. Ve kaynak yönetişim için önemliyse onu mekanik olarak güvenilir kılın; bir kişi tarafından yazılmasın, entegrasyon tarafından ayarlansın.

Türetilmiş veri her şeyden çok kökene ihtiyaç duyar. Diyelim ki Steve Trucking kamyon konumundan, teslimat zaman aralığından ve rota geçmişinden bir geç teslimat riski hesaplıyor ve sevk birimi önceliklendirmek için onu kullanıyor. “Yüksek” nereden geldi? Buna bir Alıcıya “teslimatınız gecikiyor” diyen bir ajan ekleyin; bunu neyin temellendirdiğini ve ne kadar taze olduğunu bilmeniz gerekir. Saklanan değerlerden hesaplanan, birleştirilen, tahmin edilen ve üretilen değerlere doğru ilerledikçe köken o kadar önemli hale gelir.

Sınıflandırma Farklı Bir Soruyu Yanıtlar

Şimdi: nasıl ele alınmalı? Alıcı adı, teslimat adresi, telefon numarası, teslimat notları, teslimat durumu, kamyon numarası, dağıtım merkezi, Perakende Ortağı, fotoğraf: eşit derecede hassas değildirler. “Dağıtımda” bir telefon numarası değildir, bir DC kodu da birinin evinin içinin fotoğrafı değildir. Salesforce bunu standart ya da özel her alanda kaydetmenizi sağlar: Data Owner, Field Usage, Data Sensitivity Level ve Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), İngilizce). 3. bölüm bunlara taksonomi alanları dedi ve neden önemli olduklarını anlattı: bir alanı PII ya da GDPR olarak işaretleyin, süreçler onu bulabilir; maskeleme araçlarından, işaretli değerlerin büyük bir dil modeline ulaşmasını engelleyebilen Salesforce’un yapay zekâ güven katmanına kadar. 3. bölümden bir uyarı: Salesforce artık ajanlar için bu LLM maskelemesini devre dışı bırakıyor, çünkü bir ajanın ihtiyaç duyduğu bağlamı silebiliyor (Önemli Olanı Sınıflandırın: Taksonomi Alanları). Dolayısıyla diğer kontrolleri hâlâ sınıflandırma belirlemelidir.

Buradaki pozisyonum bilinçli: her alanı değil, hassas alanları sınıflandırın. Biri “%100 sınıflandırıldı” diye raporlayabilsin ve kimse kullanmasın diye binlerce alanı sınıflandırmaya üç ay harcanmasını istemem. Alıcının telefon numarası: evet. Ev adresi: evet. Kapı şifrelerini ve “bahçede köpek var” notunu içerebilen teslimat notları: evet. İnsanları ya da bir evi gösterebilen fotoğraflar: kesinlikle. Dahili bir görüntüleme etiketi? Yönetişim enerjisinin gitmesi gereken yer değil. Bu, belgelenmemiş alanları kabul edilebilir yapmaz. İki farklı iş: belgeleme geniştir; sınıflandırma bilinçlidir. Sınıflandırmayı anlamlı tutan budur.

İnsanların Kullanabileceği Bir Taksonomi

Sınıflandırmanın bir sözcük dağarcığına, bir taksonomiye ihtiyacı vardır. Salesforce’un varsayılanları Public, Internal, Confidential, Restricted ve MissionCritical’dır; kuruluşunuz kendi etiketlerini isteyebilir. Onları ben dayatmıyorum. Anlaşılır tutun: 47 kategori varsa ve gizlilik ekibi dışında kimse 31. kategoriyi 32.‘den ayıramıyorsa yardımcı olmuyordur. İyi bir taksonomi bir etiketi bir davranışa bağlar. Bir alan hassas kişisel veriyse onu kim görebilir, bir sandbox’a gidebilir mi, bölgeden çıkabilir mi, analitikte görünebilir mi, ne kadar süre saklanır, bir ajan onu kullanabilir mi? Artık sınıflandırma iş yapıyor.

Uygulamasız Sınıflandırma Süstür

Alıcının telefon numarasını hassas olarak işaretleyip başka hiçbir şeyi değiştirmezseniz belge yazmış olursunuz. Yararlıdır, ama yönetişim daha ileri gider: sınıflandırma izinleri, maskelemeyi, şifrelemeyi, saklamayı, onayı, veri hareketini, sandbox kullanımını, denetimi ve yapay zekâ erişimini yönlendirmelidir. Bunun bir kısmı mimarın tasarım kararıdır; bazı platformlar artık etiketleri ve sınıflandırmaları doğrudan politikada uygular, Data 360 yönetişiminin yaptığı gibi (Data Governance in Data 360 (opens in a new tab), İngilizce). Ve bir alanı Restricted olarak işaretlemek kimsenin onu okumasını engellemez. Sınıflandırma bir alanın nasıl ele alınması gerektiğini söyler; güvenlik bunu sağlar. Sıralama şudur: veriyi tanımlayın, anlayın, önemli olanı sınıflandırın, sonra sınıflandırmanın gerektirdiği kontrolleri uygulayın.

Click to enlarge

Verinizle ilgili üç soru ve üçüncüsü bir şeyi harekete geçirmeli.

Referans Verisinin de Meta Veriye İhtiyacı Vardır

Ülke kodları, teslimat durumları, DC kodları, ortak tanımlayıcıları, iptal nedenleri: iki sistem çelişene kadar basit görünürler. Biri CANCELLED, bir diğeri CANCELED, üçüncüsü CNCL, dördüncüsü 9 der. Referans verisinin tanımlara, bir sahibe, bir kaynağa, değerlerin değiştiği bir yaşam döngüsüne ve sistemler onu farklı temsil ettiğinde eşlemelere ihtiyacı vardır. Küçük değerler çok büyük süreçleri yönlendirebilir. 6. bölüm daha ileri gidiyor.

Üçü Birlikte

Alıcı telefon numarasını alın. Sözlük: belirli bir teslimatı teslim alan kişiye ulaşmak için kullanılan numara. Köken: Perakende Ortağının yük listesinden. Sınıflandırma: kişisel veri. Artık mimari sorular mümkün: ekip onu görebilir mi ve ne kadar süreyle (senaryo özeti yalnızca kendi durakları için, yalnızca o gün diyor); bir sandbox’a gidebilir mi; Snowflake’in ona ihtiyacı var mı; bir ajan onu kullanabilir mi; teslimat bittiğinde ne olur?

Şimdi teslimat durumunu alın. Sözlük: teslimatın güncel operasyonel durumu. Köken: Steve Trucking’in teslimat süreci tarafından ayarlanır ve her ortağa kendi entegrasyonu aracılığıyla geri gönderilir. Sınıflandırma: operasyonel, hassas değil. Farklı veri, farklı muamele. Mesele bu.

Meta veriyi gerçek mimari bittikten sonra üretilen bir belge olarak ele almam. Bir alanın ne anlama geldiğini söyleyemiyorsam veri modelini anlamıyorumdur. Bir değerin nereden geldiğini bilmiyorsam entegrasyonları anlamıyorumdur. Hassas olup olmadığını bilmiyorsam güvenliği anlamıyorumdur. Meta veri mimariyi tanımlar ve bazen onu yönlendirir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Sınıflandırma, bir ajanın neyi getirebileceğinin ya da tekrarlayabileceğinin anahtarı haline geliyor ve köken ajanın yanıtına ya da eylemine kadar uzanmalı. Bir ajan bir Alıcıya teslimatın geciktiğini söylüyorsa mimari bunu neyin temellendirdiğini, nereden geldiğini ve ajanın onu kullanmasına izin verilip verilmediğini söyleyebilmelidir. “Salesforce’ta bir yerde” köken değildir, “müşteri verisi” de bir sınıflandırma değildir.

Mimarın Burada Karar Verdikleri

• Sistemler ve ekipler tek bir sözcüğe farklı anlamlar vermesin diye hangi iş terimlerinin yönetilen tanımlara ihtiyaç duyduğu.
• Önemli değerlerin kaynaklarını, yetkilerini ve dönüşümlerini gösterecek kadar kökeni nasıl koruduğu.
• Hangi alanların hassasiyet ya da uyumluluk anlamı taşıdığı ve dolayısıyla açık sınıflandırma aldığı.
• Kuruluşun hangi taksonomiyi kullandığı ve insanların onu tutarlı biçimde uygulayıp uygulayamayacağı.
• Sınıflandırmanın kullanılmadan durmak yerine gerçek kontrolleri nasıl yönlendirdiği.

Veriyi yönetmeden önce elinizde ne olduğunu bilin: ne anlama geldiğini, nereden geldiğini, nasıl ele alınması gerektiğini. Geniş belgeleyin, bilinçli sınıflandırın, önemli olduğu yerde kökeni koruyun. Yoksa veriyi yönetmiyorsunuz. Yalnızca ona sahipsiniz.

Daha Fazlası

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) ve Create a Semantic Model in Data 360 (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.