Üretim için özel uygulamada Postgres veri modeli nereden başlamalı?

Bir üretim ekibi, iş emirlerinin neden beklediğini görmek için küçük bir uygulama istiyor. Mevcut ERP iş emrini açıyor ama tezgâh başında yapılan hazırlık, kalite kontrolü bekleyişi ve parçanın bir sonraki istasyona teslimi farklı yerlerde kaydediliyor. İlk fikir basit: birkaç ekran, bir durum seçici, bir de rapor. Asıl karar ise ekranlarda değil, bu kayıtların nasıl saklanacağında.

Supabase burada özel uygulama için bir Postgres veritabanı sağlar. Bu yazının konusu paketteki bütün servisler değil, veritabanını üretim sürecine göre tasarlamak. Önceki Supabase’in arka yüz bileşenleri yazısı veritabanı, kimlik doğrulama ve depolamayı birlikte ele alıyordu. Bu kez soru daha dar: iş emriyle sahadaki olayları aynı veritabanına koyarken neyi ayırmak gerekir?

İş emri ile olay aynı kayıt değildir

Varsayımsal bir sac işleme atölyesinde ERP, kesim için 4821 numaralı iş emrini açsın. İş emrinde müşteri referansı, planlanan miktar ve teslim tarihi var. Operatör ise hazırlığa başladığını, ilk parçayı kontrol ettiğini ve malzeme beklediğini bildiriyor. Bu üç kayıt, iş emrinin mevcut durumunu açıklıyor ama iş emrinin kendisi değil.

Tek tabloda durum = bekliyor yazıp eski değerin üzerine kaydetmek hızlı görünür. Sonra vardiya amiri “Ne zamandan beri bekliyor?” diye sorar. Eski durum silinmişse bu sorunun cevabı yoktur. Daha sağlam bir başlangıç, ERP’den gelen iş emri kimliğini ve temel alanları ayrı tutmak, sahada oluşan durum değişikliklerini zaman damgalı olaylar olarak kaydetmektir. Böylece mevcut durum olaylardan çıkarılabilir, geçmiş ise kaybolmaz.

Bu ayrım her veri için sonsuz geçmiş tutmak anlamına gelmez. Hangi olayların operasyonel veya denetim açısından gerekli olduğunu ekip belirlemeli. Örneğin operatörün ekrandaki sıralama tercihi ile kalite onayı aynı saklama kuralına tabi olmak zorunda değil. Şema, gerçek sorulara cevap vermek için kurulmalı; sırf ileride işe yarayabilir diye her dokunuşu toplamamalı.

Kimlikleri ve sınırları erken belirlemek

Özel uygulamanın veritabanında jobs, operations ve operation_events gibi tablolar düşünelim. İş emri birden fazla operasyondan geçer; her operasyonun birden fazla olayı olabilir. Olay kaydı, ilgili operasyon kimliği, olay türü, olay zamanı ve kaynağını taşır. Kaynak, bir operatör girişi de olabilir, ERP entegrasyonu da. Bu taslak doğrudan kurulacak hazır bir şema değil, ilişkileri konuşmak için bir çerçevedir.

İş numarası tek başına kalıcı kimlik olmak zorunda değildir. ERP iş numaralarını şirket bazında yeniden kullanabilir veya revizyonla değiştirebilir. Yerel kayıt için ayrı bir anahtar, ERP tarafı için ayrı bir dış kimlik alanı tutmak daha güvenlidir. Entegrasyon aynı iş emrini ikinci kez gönderdiğinde tekrar kayıt oluşmaması için dış kimlik ve kaynak sistem eşleşmesi açıkça tanımlanır. Aynı mantık olaylarda da geçerli: bağlantı koptuktan sonra yeniden gönderilen bir olay çift sayılmamalı.

Zaman bilgisinde de iki farklı an vardır. Operatörün olayı gerçekleşti diye işaretlediği an ile kaydın sunucuya ulaştığı an farklı olabilir. Özellikle atölye ağı kesintiliyse bunları tek sütuna sıkıştırmak gecikmeyi görünmez kılar. Veritabanında zamanları tutarlı bir biçimde saklayıp arayüzde yerel saat dilimine çevirmek, vardiya sınırındaki kayıtların yanlış güne yazılmasını önler. Vardiya raporunun hangi saat dilimini esas aldığı da baştan yazılmalı.

Postgres’in görevi nerede biter?

Postgres, ilişkileri ve kuralları verinin yakınında tutmaya elverir. Yabancı anahtar, olmayan bir operasyona olay bağlanmasını engelleyebilir. Tekillik kuralı, aynı kaynak olayının tekrar eklenmesini önleyebilir. Zorunlu alanlar boş kayıtları sınırlayabilir. Bu kurallar, yalnızca mobil ekranın doğru davranacağı varsayımına göre daha dayanıklıdır; başka bir entegrasyon aynı veritabanına yazdığında da geçerlidir.

Ama veritabanı bütün üretim mantığını tek başına çözmez. ERP’deki iş emri iptal edildiğinde sahadaki açık işlem ne olacak? Bir kalite onayından sonra kim durumu değiştirebilir? Çelişen kayıtların hangisi yetkili kabul edilecek? Bunlar tablo açarak değil, iş akışı ve sorumluluk kararıyla çözülür. Uygulama kodu, entegrasyon ve veritabanı kuralları bu kararın farklı parçalarını uygular.

Supabase’in otomatik veri erişimi geliştirmeyi kolaylaştırır, fakat üretim verisi istemciye açılmadan önce erişim sınırı tasarlanmalı. Kullanıcı giriş yapmış diye bütün iş emirlerini görmemeli. Supabase belgeleri, istemciden erişilen tablolar için Row Level Security ve en az yetki yaklaşımını önerir. Bir istasyon operatörü yalnızca yetkili olduğu alanın kayıtlarını düzenleyebilmeli; sunucuya ait gizli anahtar tarayıcıya veya operatör tabletine konmamalı. İzinleri test ederken sadece doğru kullanıcının yapabildiklerini değil, yanlış kullanıcının yapamadıklarını da deneyin.

Küçük bir deneme nasıl yapılır?

İlk sürümde tüm fabrikanın verisini taşımak yerine tek bir operasyon seçilebilir. ERP’den gelen bir iş emri, o operasyona bağlı birkaç durum olayı ve bir vardiya görünümü yeterli. Ekip üç soruya gerçek kayıtlarla bakar: Şu an ne bekliyor? Bekleme ne zaman başladı? Bilgiyi kim veya hangi sistem kaydetti? Bu soruların cevapları ekrandan ve veritabanından tutarlı biçimde çıkmıyorsa yeni grafik eklemek yerine veri modelini düzeltmek gerekir.

Denemeye hata senaryoları da dahil edilmeli. ERP aynı iş emrini tekrar yollasın. Tablet çevrimdışıyken olay kaydetsin ve sonra yeniden göndersin. Bir kullanıcı başka istasyonun olayını değiştirmeye çalışsın. Beklenen sonucun her durum için yazılması, “çalışıyor” sözünü denetlenebilir hale getirir. Yedekleme ve geri yükleme denemesi de planın parçasıdır; yalnızca yedek alındığını görmek, geri dönülebileceğini göstermez.

Özel uygulama kurmak, ERP’nin yerini almak zorunda değil. ERP planın sahibi kalabilir; Postgres sahadaki ayrıntılı kayıtları, ERP kimlikleriyle bağlantılı ve kendi kurallarıyla yönetebilir. Değer, veritabanının adında değil, bir iş emrinin geçmişini kaybetmeden ve erişim sınırlarını karıştırmadan anlatabilmesinde.

Kaynaklar: Luke van Enkhuizen’in açık kaynak üretim araçları derlemesi, Supabase veritabanı belgeleri ve veri güvenliği rehberi. Atölye örneği açıklama amacıyla kurgulanmıştır.