Veritabanları İş Yerinde Nasıl Tek Doğru Kaynak Olur?

“Tek Doğru Kaynak” Gerçekte Ne Anlama Gelir\n\nBir tek doğru kaynak (SSOT), bir kuruluşun “Kaç aktif müşterimiz var?” ya da “Gelir olarak ne kabul edilir?” gibi temel soruları nasıl yanıtlayacağını paylaşmasının yoludur—ve ekipler arasında aynı yanıtı almayı sağlar.\n\nSSOT’un tek bir yerde veri olması demek olduğunu düşünmek cazip gelebilir. Pratikte SSOT, tek bir araçtan ziyade uzlaşma ile ilgilidir: herkes rapor oluştururken, operasyon yürütürken veya karar alırken aynı tanımları, kuralları ve tanımlayıcıları kullanır.\n\n### SSOT bir ürün değil, bir uzlaşmadır\n\nBir SSOT’u bir veritabanı, entegre sistemler seti ya da bir veri platformunun üzerine kurabilirsiniz—ancak “gerçek” yalnızca insanların şu konularda hizalanmasıyla geçerli olur:\n\n- Tanımlar (Tam olarak “aktif kullanıcı” ne demek?)\n- Zamanlama (Veri ne zaman “kesin” vs. “devam ediyor” sayılır?)\n- Sahiplik (Sorunları kim düzeltmekten sorumlu?)\n- Kullanım kuralları (Hangi alanlar hangi kararlar için kullanılmalı?)\n\nBu uyum olmadan, en iyi veritabanı bile çelişkili sayılar üretebilir.\n\n### “Gerçek” gerçekte ne demektir\n\nSSOT bağlamında “gerçek” nadiren felsefi kesinlik anlamına gelir. Anlamı şu olan veridir:\n\n- Doğru: gerçekten olanı yansıtır\n- Güncel: iş ihtiyacına göre yeterince sık güncellenir\n- Eksiksiz: gereken tüm kayıtları ve alanları içerir\n- İzlenebilir: nereden geldiğini ve neyin değiştiğini açıklayabilirsiniz\n\nBir sayıyı kaynağına ve mantığına kadar izleyemiyorsanız, doğru gibi görünse bile güvenmek zordur.\n\n### Kaçınılması gereken yaygın yanlış anlamalar\n\n- “Bizim SSOT bir dashboard.” Dashboardlar veriyi gösterir; onu tanımlamaz.\n- “Bu bir ana elektronik tablo.” Elektronik tablolar kullanışlıdır ama kolayca kopyalanır, düzenlenir ve farklılaşırlar.\n- “Tek bir veritabanı demek.” Tek bir veritabanı bile tutarsız tanımlar veya çoğaltılmış varlıklar içerebilir.\n\nSSOT tutarlı veri + tutarlı anlam + tutarlı süreçler kombinasyonudur.\n\n## Kuruluşların Çelişen Verilerle Neden Mücadele Ettiği\n\nÇelişkili veriler genellikle “kötü insanlar” veya “kötü araçlar” yüzünden olmaz. Büyümenin doğal sonucudur: ekipler yerel problemleri çözmek için sistemler ekler ve zamanla bu sistemler örtüşmeye başlar.\n\n### Aynı kayıtlar birden fazla yerde yaşar\n\nÇoğu kuruluş aynı müşteri, sipariş veya ürün bilgisini birden fazla sistemde saklar—CRM, faturalama, destek, pazarlama, elektronik tablolar ve bazen belirli bir ekip tarafından yapılan özel bir uygulama. Her sistem kendi programında, kendi kullanıcıları tarafından güncellenen kısmi bir gerçeklik haline gelir.\n\nBir müşteri CRM’de şirket adını değiştirir, ama faturalamada eski ad kalır. Destek, mevcut kaydı bulamayınca “yeni” bir müşteri oluşturur. Bu her zaman iş hatası değildir—veri yalnızca çoğaltılmıştır.\n\n### Takımlar arasında tanımlar sürüklenir\n\nDeğerler eşleşse bile anlam genellikle farklıdır. Bir ekibin “aktif müşteri”si “son 30 günde giriş yapmış” anlamına gelirken, başka bir ekip için “bu çeyrekte fatura ödemiş” olabilir. Her iki tanım da makul olabilir ama raporlarda karıştıklarında tartışmalara yol açar.\n\nBu yüzden analitik tutarlılık zordur: sayılar farklıdır çünkü altta yatan tanımlar farklıdır.\n\n### Manuel işler gerçeğin sürümlerini çoğaltır\n\nManuel dışa aktarmalar, elektronik tablo kopyaları ve e-posta ekleri veri anlık görüntüleri oluşturur ve hemen eskimeye başlar. Bir elektronik tablo kendi düzeltmeleri ve notlarıyla mini bir veritabanına dönüşür—bunların hiçbiri günlük olarak güvenilen sistemlere geri akmaz.\n\n### Gerçek maliyet: güven ve hız\n\nSonuçlar hızla görünür:\n\n- Kararlar yanlış toplamlar veya yanlış segmentler üzerine alınır.\n- Her metrik için mutabakat gerektiği için raporlama yavaşlar.\n- Güven düşer; insanlar ortak gerçekler yerine “benim raporum vs. senin raporun” moduna geri döner.\n\nOrganizasyon yetkili versiyonun nerede yaşadığını ve güncellemenin nasıl yönetileceğini belirleyene kadar çelişkili veri varsayılan haldir.\n\n## Neden Veritabanları Sıklıkla SSOT Çekirdeği Seçilir\n\nBir “tek doğru kaynak” paylaşılan bir elektronik tablo ya da iyi niyetli bir dashboard’dan daha fazlasını gerektirir. Verinin öngörülebilir şekilde saklanabileceği, otomatik doğrulanabileceği ve birçok ekip tarafından tutarlı şekilde alınabileceği bir yere ihtiyaç vardır. Bu yüzden kuruluşlar genellikle bir veritabanını SSOT’un merkezine koyar—tabii etrafında hâlâ birçok uygulama ve araç olabilir.\n\n### “Yeterince yakın” veriyi önleyen yapı\n\nVeritabanları sadece bilgiyi saklamaz; bilginin nasıl var olabileceğini de zorlayabilir.\n\nMüşteri kayıtları, siparişler ve ürünler yapılandırılmış bir şemada yaşadığında, şunları tanımlayabilirsiniz:\n\n- İlişkiler (bir sipariş gerçek bir müşteriye ait olmalı)\n- Kısıtlar (bir durum onaylı değerlerden biri olmalı)\n- Benzersizlik (bir müşteri kimliği iki farklı kişiye işaret etmemeli)\n\nBu, ekiplerin kendi alanlarını, adlandırma kurallarını veya “geçici” geçiş yollarını icat ettiğinde oluşan yavaş sürüklenmeyi azaltır.\n\n### Operasyonlar için güvenilir tutarlılık\n\nOperasyonel veri sürekli değişir: faturalar oluşturulur, gönderimler güncellenir, abonelikler yenilenir, iadeler yapılır. Veritabanları bu tür işler için tasarlanmıştır.\n\nİşlemlerle (transactions) veritabanı çok adımlı bir güncellemeyi tek bir birim olarak ele alabilir: ya tüm değişiklikler başarılı olur ya da hiçbiri olmaz. Pratikte bu, bir sistemde ödeme alınmış görünürken diğerinin hâlâ başarısız olduğunu düşünmesi gibi durumların azalması demektir. Ekipler “Şu anda geçerli gerçek nedir?” diye sorduğunda, bir veritabanı baskı altında buna cevap verecek şekilde kuruludur.\n\n### Bir ekipten fazlasına ölçeklenen sorgulanabilirlik\n\nSSOT yalnızca bir kişinin yorumlayabileceği bir şeyse kullanışlı olmaz. Veritabanları veriye sorgular yoluyla erişim sağlar, böylece farklı araçlar aynı tanımları çekebilir:\n\n- Finans veya destek için operasyonel raporlar\n- Tutarlı metriklere ihtiyaç duyan analitik araçlar\n- Diğer sistemleri eşitleyen entegrasyonlar\n\nBu paylaşılan erişim, insanların veriyi izole şekilde kopyalayıp yeniden şekillendirmemesini sağlayarak analitik tutarlılık için büyük bir adımdır.\n\n### Paylaşılan tanımlar ve kontroller için doğal bir yuva\n\nSon olarak, veritabanları pratik yönetişimi destekler: rol tabanlı erişim, değişiklik kontrolleri ve neyin ne zaman değiştiğine dair denetime uygun geçmiş. Bu, “gerçek”i bir uzlaşmadan uygulanabilir bir şeye dönüştürür—tanımlar sadece bir belgede tarif edilmez, veri modelinde uygulanır.\n\n## SSOT, Kayıt Sistemi ve Veri Ambarı Arasındaki Fark\n\nEkipler sıklıkla “tek doğru kaynak”ı “güvendiğim yer” anlamında kullanır. Pratikte üç ilişkili fikri ayırmak yardımcı olur: kayıt sistemi (system of record), etkileşim sistemi (system of engagement) ve analitik depo (çoğunlukla bir veri ambarı). Bunlar örtüşebilir ama aynı olmak zorunda değildir.\n\n### Kayıt sistemi: yetkili kitap\n\nBir kayıt sistemi (SoR) bir gerçeğin resmi olarak oluşturulduğu ve korunduğu yerdir. Örneğin: müşteri yasal adı, fatura durumu, çalışan işe başlama tarihi. Genellikle günlük operasyonlar ve doğruluk için optimize edilmiştir.\n\nKayıt sistemi domaine özgüdür. CRM’iniz lead ve fırsatlar için SoR olabilirken, ERP faturalar ve ödemeler için SoR olabilir. Gerçek bir SSOT genellikle domain bazında uzlaşılan “gerçekler” setidir, tek bir uygulama değildir.\n\n### Etkileşim sistemi: işin yapıldığı yer\n\nBir etkileşim sistemi kullanıcıların etkileşimde bulunduğu yerdir—satış araçları, destek masaları, ürün uygulamaları. Bu sistemler SoR’den veri gösterebilir, onu zenginleştirebilir veya geçici düzenlemeler tutabilir. İş akışı ve hız için tasarlanmışlardır, her zaman resmi otorite olmak için değil.\n\nÇatışmalar genellikle burada başlar: iki araç aynı alanı “sahiplenir” ya da benzer veriyi farklı tanımlarla toplar.\n\n### Veri ambarı (analitik depo): raporlama için gerçek\n\nBir veri ambarı (veya analitik depo) soruları tutarlı şekilde yanıtlamak için tasarlanmıştır: zaman içindeki gelir, segmente göre churn, departmanlar arası operasyonel raporlama. Genellikle analitik (OLAP) amaçlıdır; sorgu performansını ve geçmişi önceliklendirir.\n\nBir SSOT şu şekilde olabilir:\n\n- Operasyonel (OLTP): işletme işlemleri ve gerçek zamanlı tutarlılık için tek bir canlı veritabanı gerektiğinde.\n- Analitik: tutarlı metrikler, tarihsel izleme ve çapraz sistem raporlama öncelikli olduğunda.\n\n### “Her şey için tek veritabanı” tuzağından kaçının\n\nHer iş yükünü tek bir veritabanına zorlamak ters tepebilir: operasyonel ihtiyaçlar (hızlı yazma, katı kısıtlar) analiz gereksinimleriyle (büyük taramalar, uzun sorgular) çatışabilir. Daha sağlıklı bir yaklaşım, her domain için hangi sistemin yetkili olduğunu tanımlamak, sonra entegrasyon ve yayınlama yaparak herkesin aynı tanımları okumasını sağlamaktır—veri birden fazla yerde yaşasa bile.\n\n## Paylaşılan Anlayış İçin Veri Modeli Tasarımı\n\nBir veritabanı ancak insanlar “gerçeğin” ne olduğunu kabul ederse tek doğru kaynak olabilir. Bu uzlaşma veri modelinde yakalanır: önemli varlıkların, onların kimliklerinin ve ilişkilerinin paylaşılan haritası. Model net olduğunda, analitik tutarlılık artar ve operasyonel raporlama tartışmaya dönüşmekten çıkar.\n\n### Temel varlıklarla başlayın\n\nİşinizin dayandığı isimleri belirleyerek başlayın—genellikle müşteri, ürün, çalışan ve tedarikçi—ve her birinin ne anlama geldiğini sade bir dille tanımlayın. Örneğin, “müşteri” bir fatura hesabı mı yoksa son kullanıcı mı, yoksa her ikisi mi? Cevap tüm raporlamayı ve entegrasyonları etkiler.\n\n### Benzersiz kimlikler, anahtarlar ve ilişkileri tanımlayın\n\nHer temel varlığın kararlı, benzersiz bir kimliğe (müşteri ID, ürün SKU, çalışan ID) ihtiyacı vardır. Bölgesel veya yıl gibi anlam taşıyan “akıllı” ID’lerden kaçının çünkü bu özellikler değişir. Anahtarlar ve ilişkilerle bağlantıları ifade edin:\n\n- Customer ↔ Orders (bir-e-çoğul)\n- Product ↔ Order Lines (bir-e-çoğul)\n- Vendor ↔ Products (duruma bağlı olarak bir-e-çoğul veya çok-e-çok)\n\nNet ilişkiler çoğaltılmış kayıtları azaltır ve sistemler arası entegrasyonu basitleştirir.\n\n### Tanımları ve izin verilen değerleri belgeleyin\n\nİyi bir veri modeli küçük bir veri sözlüğü içerir: iş tanımları, örnekler ve önemli alanlar için izin verilen değerler. Eğer “status” active, paused veya closed olabiliyorsa bunu yazın—ve yeni değerleri kimin oluşturabileceğini not edin. Veritabanı yönetişimi burada pratik olur: daha az sürpriz, daha az “gizemli” kategori.\n\n### Tarihsel değişim için plan yapın\n\nGerçek değişir. Müşteriler taşınır, ürünler yeniden markalanır, çalışanlar departman değiştirir. Tarihi nasıl izleyeceğinize (etkinlik tarihleri, “mevcut” bayrakları veya ayrı tarihçe tabloları) erken karar verin.\n\nModeliniz değişimi temiz temsil edebiliyorsa, denetim izi daha kolay olur, veri kalite kuralları uygulanması basitleşir ve ekipler zaman bazlı raporlamaya güvenebilir.\n\n## Veri Yönetişimi: Sahiplik, Erişim ve Paylaşılan Tanımlar\n\nBir veritabanı, kim kimin sorumluluğunda, kim değiştirebilir veya alanların ne anlama geldiğini bilmiyorsa tek doğru kaynak olamaz. Yönetişim, “gerçeği” takımların güvenebileceği kadar istikrarlı kılan günlük kurallar setidir—her kararı komite toplantısına çevirmeden.\n\n### Sahiplik: kim soruları yanıtlar (ve kim sorunları düzeltir)\n\nHer domain için veri sahipleri ve veri görevlileri atayarak başlayın (örneğin: Müşteriler, Ürünler, Siparişler, Çalışanlar). Sahipler verinin anlamı ve doğru kullanımı için hesap verebilir. Görevliler pratik işi yapar: tanımları güncel tutmak, kaliteyi izlemek ve düzeltmeleri koordine etmek.\n\nBu, veri problemlerinin IT, analitik ve operasyonlar arasında kimsenin karar vermediği yere çarpıp durmasını önler.\n\n### Paylaşılan tanımlar: bir anlam, birçok kullanım\n\nEğer “aktif müşteri” Satış’ta bir şeyi, Destek’te başka bir şeyi ifade ediyorsa raporlar asla uyuşmaz. Ekiplerin gerçekten kullandığı bir veri kataloğu / sözlük tutun:\n\n- Tanımları kısa, örneklerle ve sınır durumlarla birlikte tutun\n- Ana alanları tablolar/kolonlarla ilişkilendirin\n- “Resmi” metrikleri ve nasıl hesaplandığını vurgulayın\n\nBunu dashboardlara, ticketlara ve oryantasyon dokümanlarına gömerek erişimi kolay ve göz ardı etmeyi zor hale getirin.\n\n### Değişiklik kontrolü: istemeden gerçek kaymasının önüne geçin\n\nVeritabanları evrimleşir. Amaç şemaları dondurmak değil—değişiklikleri kasıtlı yapmak. Özellikle şu durumlar için şema ve tanım değişiklikleri onay iş akışları kurun:\n\n- Sütun adlarını değiştirme\n- Veri tiplerini değiştirme\n- İş mantığını değiştirme (örneğin durum kuralları)\n\nHafif bir süreç (öneri → inceleme → planlanmış sürüm notları) bile downstream raporlama ve entegrasyonları korur.\n\n### Erişim: varsayılan olarak en az ayrıcalık\n\nGerçek ayrıca güvene bağlıdır. Erişim kurallarını rol ve hassasiyete göre belirleyin:\n\n- Gerçekten ihtiyacı olan sistemlere ve kişilere yazma erişimini sınırlayın\n- Operasyonel kullanıcıları analitik tüketicilerden ayırın\n- Hassas alanları (PII, ücretlendirme, sağlık verisi) daha sıkı izinlerle koruyun\n\nAçık sahiplik, kontrollü değişim ve paylaşılmış tanımlarla veritabanı insanlar tarafından güvenilen bir kaynak olur—sadece verinin olduğu yer değil.\n\n## Güveni İnşa Eden Veri Kalitesi Kontrolleri\n\nBir veritabanı insanların söylediklerine güvenmelerini sağlayacaksa, bu güven dashboard veya bir notla yaratılmaz—tekrarlanabilir veri kalite kontrolleriyle kazanılır: kötü verinin girişini engelleyen, sorunları hızlıca gösteren ve düzeltmeleri görünür kılan süreçler.\n\n### Giriş noktasında veriyi doğrulayın\n\nEn ucuz veri problemi alım sırasında durdurulan problemdir. Pratik doğrulama kuralları şunları içerir:\n\n- Tipler ve formatlar: tarihler tarih olsun, e-postalar e-posta formatında görünsün, ID'ler beklenen desende olsun.\n- Aralıklar ve akılcı değerler: miktarlar negatif olamaz, indirimler %100'ü geçemez, doğum tarihleri gelecekte olamaz.\n- Zorunlu alanlar: operasyonel raporlama için gerekli asgari set (örneğin müşteri adı + benzersiz tanımlayıcı + durum).\n\nİyi doğrulama "mükemmel" olmak zorunda değildir. Tutarlı ve paylaşılan tanımlarla uyumlu olması yeterlidir; zaman içinde analitik tutarlılık artar.\n\n### Ana veride çoğaltma ve eşleştirme\n\nÇoğaltmalar sessizce güveni yok eder: farklı yazımlar, birden fazla tedarikçi girişi veya bir kişinin iki departmanda listelenmesi. Burada “ana veri yönetimi” (MDM) aslında herkesin üzerinde anlaştığı eşleştirme kuralları setidir.\n\nYaygın yaklaşımlar:\n\n- Güvenli benzersiz anahtar üzerinde kesin eşleşme (vergi numarası veya iç müşteri ID'si gibi).\n- Ad + adres üzerine bulanık eşleştirme ile yakın çoğaltmaları yakalayma.\n- Yaşama hakkı (survivorship) kuralları: çelişen kayıtlar olduğunda hangi değerin kazanacağına karar verme (örneğin fatura adresi finansal sistemden alınır).\n\nBu kurallar veritabanı yönetişiminin parçası olarak belgelenmeli ve tek seferlik temizlik yerine sahiplenilmelidir.\n\n### Kaliteyi sürekli izleyin\n\nDoğrulamaya rağmen veri sürüklenir. Sürekli kontroller sorunları ekipler iş etraflarından çözmeden önce görünür kılar:\n\n- Tamlık: zorunlu alanlar dolduruluyor mu?\n- Tazelik: kritik veriler planlandığı sıklıkta güncelleniyor mu (saatlik, günlük, haftalık)?\n- Doğruluk sinyalleri: beklenmeyen sıçramalar, imkansız kombinasyonlar veya uzlaşmayan toplamlar.\n\nBasit bir skor kart ve uyarı eşikleri genellikle kalitenin nabzını tutmak için yeterlidir.\n\n### İnsanların gerçekten kullanacağı üç aşamalı düzeltme akışı\n\nBir sorun bulunduğunda, düzeltmenin net bir yolu olmalı: kimin sahibi olduğu, nasıl kaydedildiği ve nasıl çözüldüğü. Kalite sorunlarını destek ticket'ı gibi ele alın—etkiye göre öncelik verin, bir veri görevlisine ata, kaynağı düzelt, değişikliği doğrula. Zamanla bu iyileştirmelerin denetim izi oluşur ve “veritabanı yanlış” yerine “neden olduğunu biliyoruz ve düzeltiliyor” olur.\n\n## Veriyi Tutarlı Tutan Entegrasyon Desenleri\n\nGüncellemeler geç gelirse, iki kez gelirse veya kaybolursa veritabanı tek doğru kaynak olamaz. Kullandığınız entegrasyon deseni—batch işler, API'ler, olay akışları veya yönetilen bağlayıcılar—verinizin ekipler tarafından nasıl tutarlı algılandığını doğrudan belirler.\n\n### Batch vs. gerçek zamanlı senkronizasyon\n\nBatch senkronizasyon veriyi zamanlı olarak taşır (saatlik, gece, haftalık). Uygun olduğunda:\n\n- iş gecikmeyi tolere edebilir (ör. finans kapanışı, pazarlama atfedilmesi)\n- kaynak sistemler mesai saatlerinde sorgulanması zor olabilir\n- daha öngörülebilir ve basit operasyonlar isteniyordur\n\nGerçek zamanlı senkronizasyon (veya yakın gerçek zamanlı) değişiklikleri oluştuğu anda iletir. Faydalıdır:\n\n- müşteri odaklı operasyonlar (stok, sipariş durumu)\n- anlık güncelleme gerektiren iş akışları (destek, dolandırıcılık kontrolleri)\n- “ekrandaki veriniz neden benimkine uymuyor?” konuşmalarını azaltmak için\n\nTakas, karmaşıklıktır: gerçek zamanlı daha güçlü izleme ve anlaşmazlık kuralları gerektirir.\n\n### ETL/ELT boru hatları ve SSOT tutarlılığı\n\nETL/ELT boru hatları tutarlılığın kazanıldığı veya kaybedildiği yerdir. İki yaygın tuzak:\n\n- Farklı yerlerde farklı dönüşüm mantığı (elektronik tablolar, BI araçları, el yapımı script'ler) aynı metrik için birden çok “tanım” yaratır.\n- Kısmi yüklemeler bazı tabloları güncellerken diğerlerini güncellemez ve SSOT’u geçici olarak çelişkili bırakır.\n\nPratik yaklaşım, dönüşümleri merkezileştirmek ve sürümlendirmek, böylece aynı iş kuralının (örneğin “active customer”) raporlama ve operasyonlarda tutarlı uygulanmasını sağlamaktır.\n\n### API'ler, olaylar ve bağlayıcılar (daha az manuel işlem)\n\n- API'ler, SSOT’a kontrollü, doğrulanmış yazma gerektiğinde en iyisidir (örn. müşteri kayıtlarını oluştur/güncelle).\n- Olaylar (publish/subscribe) değişiklikleri güvenilir şekilde yaymaya ve sistemleri sıkı bağlılık olmadan senkron tutmaya yardımcı olur.\n- Yönetilen bağlayıcılar SaaS araçlarından alımı hızlandırır, kırılgan el yapımı scriptleri azaltır.\n\nAmaç aynı: daha az manuel dışa/içe aktarma, daha az “dosyayı çalıştırmayı unutmuş” ve daha az sessiz veri düzenlemesi.\n\n### Hataları ele alma: yeniden denemeler, dead-letter kuyruğu ve uyarılar\n\nEntegrasyonlar başarısız olur—ağlar düşer, şemalar değişir, hız sınırları aşılır. Buna göre tasarlayın:\n\n- Geçici sorunlar için geri çekme ile yeniden denemeler\n- İşlenemeyen mesajları yakalayan dead-letter kuyruğu, böylece hiçbiri kaybolmaz\n- Sadece “iş başarılı” değil, tazelik ve hata oranlarına bağlı uyarılar ve dashboardlar\n\nHatalar görünür ve kurtarılabilir olduğunda, veritabanınız kötü günlerde bile güvenilir kalır.\n\n## Jargonsuz Ana Veri Yönetimi (MDM)\n\nAna Veri Yönetimi (MDM), müşteriler, ürünler, konumlar, tedarikçiler gibi “temel şeylerin” her yerde tutarlı kalmasını sağlama pratiğidir—böylece ekipler hangi kaydın doğru olduğu konusunda tartışmaz.\n\nVeritabanınız tek doğru kaynak olduğunda, MDM çoğaltmaları, uyumsuz adları ve çakışan nitelikleri raporlara ve günlük işlemlere sızmaktan nasıl alıkoyacağınızın yoludur.\n\n### Paylaşılan bir kimlikle başlayın\n\nSistemleri hizada tutmanın en kolay yolu mümkün olduğunda bir kimlik stratejisi kullanmaktır.\n\nÖrneğin, her sistem aynı customer_id saklarsa (sadece e-posta veya ad değil), veriyi güvenle birleştirebilirsiniz ve kazara çoğaltmalardan kaçınırsınız. Paylaşılan bir ID mümkün değilse, veritabanında bir eşleme tablosu tutun (örn. CRM müşteri anahtarı ↔ fatura müşteri anahtarı) ve bunu birinci sınıf varlık olarak yönetin.\n\n### “Altın kayıt” oluşturun\n\nAltın kayıt, bir müşterinin veya ürünün birden fazla kaynaktan derlenmiş en iyi bilinen versiyonudur. Bu, tek bir sistemin her şeyi sahiplenmesi demek değildir; veritabanı, downstream sistemlerin ve analitiğin güvenebileceği küratörlü bir ana görünüm tutar.\n\n### Yaşama hakkı (survivorship) kurallarına karar verin\n\nÇakışmalar normaldir. Önemli olan her alan için hangi sistemin kazandığına dair net kuralların olmasıdır.\n\nÖrnekler: