Yinelenen veritabanı sütunlarına karşı ikna edici bir şekilde nasıl savunabilirim?

Yeni bir organizasyonda çalışmaya başladım ve veritabanında gördüğüm modellerden biri, işletme analistleri için sorgu yazmayı kolaylaştırmak için alanları çoğaltıyor. Django ve ORM kullanıyoruz.

Bir durumda, bir hastayı belirli bir bağlamda tanımlayan benzersiz bir dize ile MedicalRecordNumber nesnesini tutarız . Biz Tescil hastaları izlemek ve ilgili olan nesneleri MedicalRecordNumbers ziyade bir yabancı anahtar ilişkisi kullanmaktan daha onlar katılmak yazılmasını önlemek, böylece onlar dize çoğaltmak ( değil performans nedenleriyle). Bu kalıp veri tabanı genelinde yaygındır.

Benim için temiz bir veri modelinin önemi sadece iyi düşünebilmem için. Gereksiz karmaşıklık, sınırlı bilişsel işlem süremin boşa harcanmasıdır. Bu sistematik bir problem. Yazarken rahat olmamak, birleştirilebilir bir beceri sorunudur. Mutlaka geri dönüp şemayı değiştirmeyi savunmak istemem ama bu tür bir çoğaltma ile ilgili sorunları ikna edici bir şekilde ifade etmeyi çok isterim.

Operasyonel veritabanınız anomalileri azaltmak için oldukça normalize edilmelidir .

Analitik veritabanınız (depo) analizi kolaylaştırmak için yüksek oranda denormalize edilmelidir.

Ayrı bir analitik veritabanınız yoksa, bazı oldukça denormalize edilmiş [materyalize] görüşler sunmalısınız.

Üst düzey iş analistinize / yöneticilerinize basit bir analiz için çok sayıda katılım yapmalarını söylerseniz, işten kovulabilirsiniz.

Çevik Veri Ambarı Tasarımı iyi bir kitaptır

Hızlı n 'kirli veri ambarı ipuçlarım için buraya göz atın

Anladım, neden birileri her seçim için bir katılmak istemekten kaçınmak istiyor .

Ancak bir kez birleştirme ile bir görünüm oluşturabilir ve normal olmayan tablonuzun yerine kullanabilirsiniz.

Böylece normalizasyonun avantajını kolay seçimin rahatlığı ile birleştirirsiniz.

Zaten fazla oy alan cevaplar “çoğaltmanın nasıl önleneceğini” (görünümleri kullanarak) kapsar ancak sebebini değil. Temel olarak, sütunların çoğaltılmasının, sorgu yazmayı kolaylaştırma sorununa yanlış bir çözüm olduğunu göstermektedir. Ancak, "neden sadece bunun için rastgele bir sütunu çoğaltmıyorsunuz?" hala duruyor.

Cevap "Murphy Kanunu'ndan dolayı" dır. Murphy kanunu şöyle belirtir:

Bir şey yanlış gidebilirse, olur.

Bu durumda, çoğaltılmış bir sütunun her bir satır alanının içeriğinin, orijinal sütunun karşılık gelen her bir satır alanının içeriğiyle aynı olması gerekir. Yanlış gidebilen şey, bazı satır alanlarının içeriğinin orijinallerden farklı olması, hasara yol açması. Sen onlar farklılık emin olmak için tüm akla önlemleri almış olduğunu düşünebilirsiniz, ama Murphy kanunu beri belirtiyor onlar yapabilirsiniz farklılık onlar olacaktır farklıdır. Ve tahribat gerçekleşecek .

Bunun nasıl olabileceğinin bir örneği olarak, çoğaltılmış sütunların sihirle dolmadığı gerçeğini düşünün; Birisi aslında orijinal tabloda satırlar oluşturulduğunda kendi içinde değerleri saklayan bir kod yazmalı ve bir tanesi de orijinaller ne zaman değiştirilse, güncellenmeye devam eden bir kod yazmalıdır. Bunun, veri tabanına veri giren koda (ve tanım gereği sadece veri tabanını sorgulayan herhangi bir koda göre çok daha önemli olan) çok fazla yük getirdiği gerçeğini bir kenara bırakmak, bazı durumlarda, bazı durumlarda unutabilir. bu kopyalamayı yapmak için. Ardından, değerler farklı olacaktır. Veya çoğaltmayı gerçekleştirmeyi hatırlayabilirler, ancak bir işlem içinde değil, bu nedenle bazı nadir hata koşulları altında ihmal edilebilir. Fakat bu örnekleri yazarak zamanımı boşa harcamama gerek yoktu,Yanlış gidebilirse, olacak.

Bunu iyi / kötü değil, haksızlık açısından düşünmek daha verimli olacaktır. Sorgu kullanılabilirliğindeki avantajlar için normalleştirme avantajları (özellikle de tutarlılık) ile işlem yapıyorlar.

Bir uçta, eğer veriler ciddi tutarsızlaşırsa veritabanı işe yaramaz hale gelirdi. Diğer uçta, güvenebilecekleri sonuçları elde etmek için her gün sorgulaması gereken insanlar için çok zorsa, veritabanı kullanışsız olacaktır.

Riskleri ve maliyetleri azaltmak için ne yapabilirsiniz?

• Bir tutarlılık kontrol aracı oluşturun ve düzenli olarak çalıştırın.
• Çoğaltılmış verileri tutarlı bir şekilde güncelleyen yazılımlar yoluyla yazma erişimini yönlendirin.
• İş insanları DB içindekiler yerine bilgi açısından düşünebilmeleri için görünümler ekleyin veya otomatik olarak birleştirilen sorgu araçları oluşturun.

İş analistleri için veri normalizasyonu için en güçlü argümanın veri bütünlüğünü teşvik ettiği kanısındayım. Anahtar verileriniz yalnızca bir yerde saklanırsa (bir tabloda, bir tabloda bir sütun), verilerin yanlış güncellemelerden zarar görmesi çok daha az olasıdır. Muhtemelen veri bütünlüğünün önemini önemseyeceklerini düşünüyorum, bu yüzden bu onları veritabanı ile etkileşime girme yollarını güncellemeye ikna etmenin iyi bir yolu olabilir.

Potansiyel veri bozulmalarına göre biraz daha zor bir sorgulama yöntemi tercih edilecektir.

Yukarıda diğerlerinin önerdiklerine eklemek için. Bu bir veri yönetişimi sorunudur. İlgili paydaşlarla çalışmanız gerekir: veri ilkeleri, politikaları ve adlandırma kuralları geliştirmek için veri mimarları ve veri görevlileri.

Sabırlı olun ve düzenli çalışın. Değişim gece boyunca olmayacak.

Bırakmak, vazgeçmek.

Dürüst olmak gerekirse, ayları normalleşme, tutarlılık ve saf tembellikten kaynaklanan çılgın böceklerle savaşarak tartışabilir ve sonra bırakabilirsiniz.

Ya da sadece zamandan tasarruf edersiniz, ve hayal kırıklığı ve şimdi istifa.

İyi programcılar çok tembel insanlardır. Müşteri ve yönetim ihtiyaçlarını anlarlar. Fakat en önemlisi, sorunları iyi çözmenin, iyi tasarlanmış ve iyi uygulanmış çözümler kullanmanın kişisel olarak BÜYÜK miktarlarda iş, çaba ve en önemlisi acı ve stresten kurtardığını anlıyorlar .

Böylece iyi mühendisliği anlayan ve değer veren bir yerde çalışmak daha iyi olacaktır.

İyi şanslar.

Ardından: Belki ihtiyaç duydukları BI / OLAP araçlarıdır ... http://en.wikipedia.org/wiki/Online_analytical_processing