Veri envanteri ve köken kaydı
Yönetişim kararlarının uygulanabilmesi için hangi alanın nerede durduğunu ve neden türediğini alan düzeyinde kaydetmeyi öğretir. Tek bir senaryodan başlayıp kopyaların durduğu her durağı çıkarma yöntemini kurar.
BU DERSİN SONUNDA
- Sistem düzeyinde bir listeyi alan düzeyinde karar verilebilir bir envantere çevirmek
- Bir alanın kopyasının durduğu tüm durakları çıkarıp sahip atamak
- Köken kaydının hangi ayrıntı düzeyinde tutulacağına maliyet-fayda gerekçesiyle karar vermek
- Serbest metin ve model istemi gibi şemayla sınırlanamayan durakları ayrı işaretlemek
- 1
Teori
Kavramın çalışma mantığı
- 2
Örnek
Gerçek bir senaryo üzerinde gösterim
- 3
Lab
Uygulamalı alıştırma
- 4
Test
Kısa ölçüm
- 5
Proje
Rotadaki projeye katkı
Kısa cevap
Veri yönetişimi envanterle başlar. Envanter "hangi alan nerede duruyor" sorusunun yazılı cevabı, köken kaydı ise "bu alan hangi kaynaktan hangi dönüşümle geldi" sorusunun cevabıdır. Bu ikisi olmadan minimizasyon, saklama süresi ve silme talebi kâğıt üzerinde kalır: kararı uygulayacağınız yeri bilmezsiniz.
Teori: karar birimi alandır#
Sistem düzeyinde bir envanter ("CRM'de müşteri verisi var") hiçbir karar üretmez. Yönetişim kararları alan düzeyinde verilir: kimlik numarası saklanacak mı, doğum tarihi yerine yaş aralığı yeterli mi, bu alan model istemine girecek mi. Karar biriminin alan olması, envanterin biriminin de alan olmasını zorunlu kılar.
İkinci baskı kopyadır. Aynı alan veri ambarında, analitik panoda, arama dizininde, günlük satırında, değerlendirme setinde ve yedekte ayrı ayrı bulunur. Silme kararı yalnızca ana tabloda uygulanırsa karar uygulanmamış olur. Bu yüzden envanter alanı değil, alanın durduğu her durağı kaydeder. Köken kaydı ise bu durakları birbirine bağlar ve ilk kuralı üretir: türev bir alan, kaynağından daha gevşek bir kurala tabi olamaz.
Örnek: bir senaryonun alan haritası#
| Alan | Kaynak sistem | Duraklar | Sınıf | Köken notu |
|---|---|---|---|---|
| musteri_kimlik | Sipariş servisi | ambar, pano, eğitim seti | takma kimlik | Sipariş kaydından üretilir, eşleme tablosu ayrı durur |
| eposta | CRM | ambar, e-posta hattı, destek arşivi | doğrudan kimlik | Tek kaynak CRM; diğer duraklar kopya |
| adres_metni | Sipariş formu | ambar, kargo entegrasyonu | doğrudan kimlik | Serbest metin; içine telefon yazılabiliyor |
| destek_mesaji | Destek aracı | ambar, arama dizini, değerlendirme seti | karışık | Kullanıcı yazdığı için her tür veriyi taşıyabilir |
| satin_alma_toplami | Ambar (türev) | pano, skor modeli | türev | Sipariş satırlarından hesaplanır; kaynak silinirse yeniden üretilemez |
| oturum_kaydi | Web izleme | günlük deposu, ambar | dolaylı | Ham günlüğün saklama süresi ambardaki özetten ayrı yönetilir |
Serbest metin ve model girdileri#
Serbest metin alanı şemayla sınırlanmaz: bir destek mesajına kimlik numarası, sağlık bilgisi veya üçüncü bir kişinin adı yazılabilir. Bu yüzden serbest metin envanterde "içeriği bilinmiyor" diye değil, "en yüksek hassasiyet varsayılır" diye işaretlenir. Aynı kural üretken modele giden bağlam için geçerlidir: isteme konan her alan yeni bir durak yaratır.
Köken kaydı hangi ayrıntıda tutulur#
- Sütun düzeyi: her hedef alanın hangi kaynak alanlardan üretildiği. Silme ve düzeltme taleplerini karşılamak için gereken en düşük ayrıntı budur.
- Dönüşüm düzeyi: türetmenin kuralı — maskeleme, toplama, birleştirme. "Bu alan geri döndürülebilir mi" sorusunu yalnızca bu kayıt cevaplar.
- İş düzeyi: alanı taşıyan akışın adı ve çalışma sıklığı. Bir kural değiştiğinde etkisinin kaç gün içinde görüleceğini bu belirler.
- Satır düzeyi: hangi kaydın hangi kaynaktan geldiği. Doğruluğu en yüksek, maliyeti de en yüksek seçenek; yalnızca ihtilafın kayıt bazında çözülmesi gereken dar alanlarda tutulur.
Karar: nereden başlanır#
- 1Sınırı senaryoyla çiz
Tüm kurumu değil, uçtan uca tek bir kullanım senaryosu seç. Bitme ihtimali olan tek ölçek budur; kurum geneli envanter denemeleri genelde yarıda kalır.
- 2Çıktıdan geriye yürü
Senaryonun ürettiği ekrandan, cevaptan veya karardan başla; hangi alanları kullandığını yaz, sonra o alanların kaynağına çık. İleriye doğru yürümek kullanılmayan yüzlerce alanı da içeri alır.
- 3Durakları işaretle
Her alan için kopyanın durduğu tüm yerleri yaz: ambar, dizin, pano, günlük, yedek, değerlendirme seti, istem şablonu.
- 4Sahip ata
Her alanın tek bir karar sahibi olur. Sahipsiz alan, sonraki bölümlerdeki minimizasyon ve saklama kararlarında tıkanma noktasına dönüşür.
Sık yapılan hata#
En yaygın hata, envanteri bir kerelik proje olarak yapmaktır. Envanter üretildiği gün doğrudur; ilk şema değişikliğinde eskimeye başlar ve bir süre sonra kimse ona bakmaz. Çözüm, envanteri denetim için hazırlanan ayrı bir belge olarak değil, kod deposunda duran ve şema değişikliğiyle aynı gözden geçirmede güncellenen bir dosya olarak tutmaktır. Üretimle bağı kopan her envanter hızla kurguya döner.
LAB · UYGULAMALI ALIŞTIRMA
Tek senaryonun alan haritasını çıkarın
- 1Kendi kurumunuzdan uçtan uca tek bir senaryo seçin (örneğin destek yanıtı taslağı) ve senaryonun ürettiği çıktıyı bir cümleyle yazın.
- 2O çıktıyı üreten ekranı veya sorguyu açın; kullanılan alanları tek tek listeleyin ve türev alanların hesaplandığı formülü yanlarına yazın.
- 3Her alan için kaynak sistemi ve kopyanın durduğu tüm yerleri (ambar tablosu, pano, dizin, günlük, yedek, istem şablonu) ayrı sütunlar olarak işaretleyin.
- 4Serbest metin alanlarını ayrıca işaretleyin; o alanlardan yirmi örnek kaydı okuyup içlerinde beklenmedik hangi veri türlerinin göründüğünü not edin.
- 5Her alana tek bir karar sahibi yazın ve sahibi belirsiz kalan alanları ayrı bir "açık" listesinde toplayın.
Beklenen çıktı
Tek senaryo için alan, durak ve sahip sütunlarını taşıyan, açık noktaları ayrıca işaretlenmiş bir veri envanteri tablosu.
Sık sorulan sorular
Envanteri otomatik tarama araçlarıyla çıkarmak yetmez mi?
Otomatik tarama alanları ve tahminî sınıflarını bulur; alanın neden toplandığını, kimin sahibi olduğunu ve hangi kararın ona bağlı olduğunu bulmaz. Taramayı başlangıç listesi olarak kullanın, karar sütunlarını insan doldursun.
Köken kaydını satır düzeyinde tutmak en doğrusu değil mi?
Çoğu yönetişim sorusu — silme, düzeltme, kural devralma — sütun ve dönüşüm düzeyinde cevaplanır. Satır düzeyi kayıt başına iz tutmayı gerektirdiği için depolama ve bakım maliyetini belirgin biçimde artırır; onu ihtilafın gerçekten kayıt bazında çözülmesi gereken dar alanlara saklayın.
Yedekler envantere girmeli mi?
Evet, ayrı bir durak olarak. Silme kararının yedekte anında uygulanamaması bir eksiklik değil bir kısıttır; kısıtın kendisi yazılır (yedek döngüsü dolana kadar kayıt kalır) ve saklama bölümünde açıkça karara bağlanır.
LEARN
Veri Yönetişimi Sorumlusu rotasına devam et
Dersler tek başına da okunabilir, ama sıralı ilerlemek önkoşul boşluklarını kapatır.