Veriyi konuşmak: ER ve veri sözlüğü, alan eşleme (field mapping), yeni tablo önerisi, göç kontrolleri

ER ve veri sözlüğü okuma, kaynaktan hedefe alan eşleme, kupon için tablo önerisi, veri göçü kontrolleri, sınırın nerede olduğu.

Bu sayfa dersin okuma sürümüdür. Metin bir kutuyu çalıştırmanı ya da adıma geçmeni söylüyorsa dersi uygulamada aç.

Kupon nereden okuyacak, nereye yazılacak? İş analisti veritabanı tasarlamaz, ama “bu alan nereden geliyor, boş olabilir mi, kim dolduruyor?” sorularını sormadan gereksinim bitmez.

Bugünkü model ve öneri

Şemayı şöyle oku: bir müşterinin çok siparişi olabilir, bir siparişin tek müşterisi vardır (1:N). Bir siparişin en çok bir kuponu olur, çoğunun hiç olmaz (1:0..1). Bu son cümle iş kuralıdır ve tabloda UNIQUE olarak yaşar.

Veri sözlüğü (data dictionary)

Her alanın anlamını, tipini ve boş olup olamayacağını yazar. Bu uygulamada Veri setleri sayfası bu işi görür; orada lk_orders tablosunu aç. Sözlük yazılan değil, doğrulanan bir şeydir:

SELECT status, COUNT(*) AS siparis,
       SUM(CASE WHEN picked_at IS NULL THEN 1 ELSE 0 END) AS alis_bos,
       SUM(CASE WHEN delivered_at IS NULL THEN 1 ELSE 0 END) AS teslim_bos,
       SUM(CASE WHEN courier_id IS NULL THEN 1 ELSE 0 END) AS kurye_bos
FROM lk_orders
GROUP BY status
ORDER BY status;

Eksik alan da bulgudurKullanıcı hikâyesinde “söz verilen süre” geçiyordu, ama lk_orders tablosunda söz verilen süre diye bir alan yok. Bu yüzden 45 dakikalık sabit kural yazdık. Bunu BRD'ye “varsayım” olarak yaz: müşteriye uygulamada başka bir süre söyleniyorsa kural çelişir.

Alan eşleme (field mapping)

Her hedef alanın nereden, hangi dönüşümle geldiğini tablo olarak yazarsın. Geliştirici bunu kodlar, test uzmanı bununla sınar.

Hedef alan	Tip	Boş olabilir mi?	Kaynak	Dönüşüm
`order_id`	tam sayı	hayır	`lk_orders.order_id`	yok
`customer_id`	tam sayı	hayır	`lk_orders.customer_id`	yok
`tutar`	para, 2 ondalık	hayır	`placed_at`, `delivered_at`	süre 3.600 saniyeyi aşıyorsa 60, 2.700'ü aşıyorsa 30
`olusturma`	tarih-saat	hayır	sistem saati	kupon oluşma anı
`kullanim`	tarih-saat	evet	ödeme servisi	kupon kullanılana kadar boş

DDL önerisini okumak

DDL (data definition language), tablo yapısını tanımlayan SQL'dir. Geliştirici ekibin önerisini okuyup kuralların yansıyıp yansımadığını kontrol edersin:

CREATE TABLE ba_kupon (
  kupon_id    BIGINT PRIMARY KEY,
  order_id    BIGINT NOT NULL UNIQUE REFERENCES lk_orders(order_id),
  customer_id BIGINT NOT NULL REFERENCES lk_customers(customer_id),
  tutar       DECIMAL(10, 2) NOT NULL CHECK (tutar > 0),
  olusturma   TIMESTAMP NOT NULL,
  kullanim    TIMESTAMP NULL
);

Satır	Hangi kurala denk geliyor?
`order_id ... UNIQUE`	Sipariş başına en çok bir kupon. İki kez çalışan iş ikinci kupon üretemez.
`REFERENCES`	Var olmayan siparişe kupon yazılamaz.
`DECIMAL(10, 2)`	Para kesin ondalık tipte tutulur; kayan noktalı tipte yuvarlama hatası olur.
`kullanim ... NULL`	Kullanılmamış kupon için boş değer anlamlıdır.

Sınır nerede?Senin işin “sipariş başına tek kupon” kuralını söylemek ve DDL'de bunu görmektir. İndeks seçimi, bölümleme, kilitleme ve anahtar tipi geliştirici ya da veritabanı yöneticisinin kararıdır. Eksik görürsen soru sor, tasarımı üstüne alma. Bu derste tablo kurmanın amacı da kuralı denemektir.

Veri göçü (data migration) kontrolleri

Yeni sistem açılırken eski kayıtlar da taşınacaksa ya da geçmiş dönem için kupon üretilecekse (backfill), üç soru sorulur: satır sayısı tuttu mu, toplam tuttu mu, kural dışı kayıt var mı? Aşağıda Aralık 2024 için aday siparişleri hazırlayan bir kutu var. Alıştırmalarda bunu tabloya yükleyip kontrol edeceksin.

SELECT COUNT(*) AS kaynak_aday,
       SUM(CASE WHEN ROUND((julianday(delivered_at) - julianday(placed_at)) * 86400) > 3600 THEN 60 ELSE 30 END) AS kaynak_tutar
FROM lk_orders
WHERE status = 'teslim' AND placed_at >= '2024-12-01' AND placed_at < '2025-01-01'
  AND ROUND((julianday(delivered_at) - julianday(placed_at)) * 86400) > 2700;

Yüklemeden sonra hedef tablodan aynı iki sayı çıkmalı. Çıkmıyorsa göç bitmemiştir.