Veritabanını Yeniden Tasarlamak İçin En İyi Uygulamalar

Bir uygulama için bir veritabanı tasarlarken bazı genel en iyi uygulamaların farkındayım, peki ya yeniden tasarlamak?

Bir iç iş uygulamasını yeniden tasarlamakla görevli bir ekibim var, ancak “iç” dememe rağmen, maalesef sistemin gerçek kullanıcıları ile temastan uzak pek çok insan katmanından oluşuyorum.

Şu anki program, bazılarının normalize edilmemiş tablolarına dağılmış Oracle Formlarında, bazen birbirlerinin verilerinde küçük değişkenler barındıran birden fazla yinelenen tablolarla birlikte. Kısıtlamalar çoğu zaman kötü uygulanmış saklı prosedürler şeklindedir. Türler bile doğru saklanmış görünmüyor. Oracle'ın görmezden geldiği düşünülen, ancak SQL Server’ın İthalat / İhracat Sihirbazı’na (ve haklı olarak) uyan her türlü kötü veriyle karşılaştım. (Örneğin, iki basamaklı tamsayılar tam bir tarih saatini oluşturmaz!)

Orijinal program muhtemelen yirmi yıl öncesine dayanıyor ve orjinal geliştiricilerin hepsi o kadar uzun zaman önce emekli olmuşlar ki buradaki yaşlı insanlar bile kim olduklarını bilmiyorlardı. Sonuç olarak, gerçekten ortadan kalkacak herhangi bir temiz gereksinim de bulunmuyor - sadece mevcut uygulamanın işlevselliğini çoğaltmamız ve mevcut verilerini tutmamız gerekiyor.

Yeniden yazmanın sonucu, arka uç için MS SQL Server ile ASP.NET'te çalışan web tabanlı bir sürüm olacak.

Diğer iki geliştirici takım arkadaşım benden çok daha büyük, ikisi de işletme / MIS geçmişine sahipken, benimki de CS. Kıdemli üyenin deneyimi neredeyse yalnızca Oracle formlarıydı ve diğer üye çoğunlukla Visual Basic'te iş uygulamaları yaptı. Veri tabanı arka planım, MySQL veya SQLite'daki projeler için yeni veritabanları tasarlamakla sınırlı olmasına rağmen, çoğunlukla lisans sınıflarım için, aslında veritabanı tasarlama deneyimi olan tek kişi gibi görünüyorum.

C # dilinde, mevcut tüm verileri tarafsız bir formata okuyan, yeniden oluşturulmaya ve yeni bir veritabanına yerleştirilmiş küçük bir program yazdım. Hedef veritabanı tasarlandıktan sonra yükleme kodunu yazmayı planlıyorum, böylece veriler yeni normalize edilmiş tablolara doğru şekilde bölünebilir, yeni kısıtlamaları takip etmek için doğru sıraya eklenebilir, vb. Aynı program daha sonra tekrar çalıştırılabilir. Üretim verilerini yeni dağıtılan bitmiş yeniden tasarımına kopyalamak için. Bu, veritabanının asıl yeniden tasarlanmasını en önemli şey olarak görüyor.

Öyleyse sorumun özü: mevcut bir uygulamanın veri tabanı düzeyinde yeniden tasarım yapmak için en iyi uygulamalar nelerdir?

Bir veritabanını nasıl normalleştireceğinizi zaten bildiğinizi düşünüyorum.

İhtiyacınız olan, tüm yazılımı yeni veritabanına taşırken riski en aza indirmeye yönelik stratejilerdir.

Benim önerdiğim şey daha az risk için takas olarak çalışmak.

Veritabanını normalleştirin ve normalleştirilmiş veri tabanını orijinal veri tabanındaki verilerle doldurmak için bir işlem oluşturun. Orijinal veritabanı, ekler, güncellemeler ve silme işlemleri için veritabanı olacaktır. Normalleştirilmiş veritabanı sadece dönüşüm sırasında sorgu veritabanı olacaktır .

Doldurma işleminizin sorgu verisine ihtiyaç duyulduğu kadar sık ​​çalışması gerekir. Günün eski verileri kabul edilebilirse, her gece popülasyon işlemini çalıştırabilirsiniz. Daha fazla güncel veriye ihtiyacınız olursa, sürekli bir doldurma işlemi çalıştırmanız gerekir.

Yeni ASP.NET sisteminizin sorgu bölümünü yeni normalize veritabanına işaret ederek oluşturun.

Yeni sisteminizden gelen sorgu sonuçları, orijinal sistemdeki sorgu sonuçlarıyla karşılaştırılmalıdır.

Bu noktada durabilirsin. Bu bir iş kararı, teknik bir karar değil.

Boş zamanlarınızda, yeni ASP.NET sisteminizde yeni ekleme / güncelleme / silme işlevi oluşturursunuz. Yeni işlevi oluştururken, orijinal sistemin karşılık gelen kısımlarını kapatırsınız. Bir noktada, orijinal sistemden hiçbir şey kalmıyor.

Bu şekilde dönüştürmenin avantajları, önce sorgu bölümünü oluşturarak riski azaltmasıdır. Genellikle sorgu işlevleri, ekle / güncelle / sil işlevine gömülü iş mantığına kıyasla basittir.

Ekleme / güncelleme / silme işlevini bir seferde bir işlem dönüştürürsünüz. İşletme mantığını yanlış anlamada bir sorun varsa, kullanıcılarınız orijinal sistemi kullanırken bu sorun giderilebilir.

Nüfus sürecinizin kesinlikle tutarlı olması daha iyi olduğunu söylemeden devam etmeli.

Onları yeni sistemin geliştirilmesini bir dış şirkete sözleşmeye ikna etmeye çalışın, uygulamaları düzgün bir şekilde sınırlı ekibinizden daha hızlı ve daha iyi geliştirmek için kaynakları olan çok sayıda iyi geliştirme şirketi var. İyi bir geliştirme şirketi, üstlerinizi, talep etmeniz durumunda yapamayacakları şeyleri yapmaya zorlayabilecek, bir şirketin geliştirmek için çok fazla para ödeyecek olan bir şirketin geliştiricisi, kullanıcının katılımını sağlamak için çok daha fazla çekiciliğe sahip olacak. BT çalışanlarından daha fazla düzeyde bu tür işleri düzenlemek için yönetim yetkisi altında.

Önceden çok para harcıyor, ancak geliştirme ve uygulama için uygun kaynaklara sahip olmak büyük zaman harcıyor. Bir RFP yayınlamayı başarırsanız, elde ettiğiniz tekliflerin, yapmaya çalıştığınız şeylerin yöneticilerinizin düşündüğünden çok daha karmaşık olduğunu gösterdiğine bahse girerim.

İhtiyacınız olan veri türleriyle ihtiyacınız olan normalleştirilmiş veritabanını tasarlayın. O zaman en zor kısım veriyi taşıyor. Öncelikle eskiden yeniye nasıl harita çıkaracağınız ve yeni yapıya uymayan verilerle ne yapacağınız konusunda bir plana ihtiyacınız var. Örneğin, uygun bütünlük kısıtlamalarınız olmasaydı, verileriniz şu anda tanımlanamayabilir. Bu verileri taşımak istemeyebilir veya taşımanız gerekebilir, ancak "Bilinmeyen" adlı yeni bir üst kayda eklemeniz gerekebilir. Bir tarih gerçek değilse, gerçek bir tarih değilse, geçiş yaparken bu alanı boşaltabilir misiniz? Bu tür soruların cevaplarına ihtiyacınız olacak. Geliştiricilerin bir kısmının, yeni veritabanı direncini kullanmak için GUI’yi ve diğerlerini de kesinlikle göç üzerinde çalışmak için değiştirdiğini düşünüyorum. Göç çok büyük bir iştir çok fazla beceri ve zaman alacaktır. Sonrası olarak bırakma.

SQL Server kullandığınız için gerçek geçişi SSIS üzerinden yapabilirsiniz.

İyi bir sağlam test senaryosu seti oluşturun, böylece sonuçları eski sistemle karşılaştırabilirsiniz, yeni sistemle aynıdır.

Çünkü o kadar çok veriye sahipseniz, iki parçaya geçirmek isteyebilirsiniz. İlk önce verilerin çoğunu, daha sonra yayınlanma zamanı geldiğinde, yalnızca değişen verileri geçirin. Tabii ki, henüz sahip olamadığınız değiştirilmiş verileri bulabilmek için veritabanına kontrolleri yerleştirmeniz gerekir. Bazı verileri arşivlemek istiyorsanız, şu anda yorum yapabilirsiniz.

MS Access dosyaları (.mdb) olarak doğan birçok eski uygulamanın desteklenmesi ve daha da geliştirilmesi nedeniyle neredeyse her gün veritabanı şemasını yeniden tasarlamakla karşı karşıya kaldım ve sonra MS SQL'de bulunan yüzlerce tabloyla büyük veritabanlarına büyüdüm. Sunucu, ancak yine de özgün tasarımın "bebek ölümlerine" sahip. İşte benim için yararlı bulduğum bazı uygulamalar:

Veri tabanı şemanızın herkese açık yüzeyini simge durumuna küçültmeyi deneyin.

Bu, harici uygulamalara sunacağınız ortak bir API tasarlamaya çalışmanız gerektiği anlamına gelir. Normalde statik verileri görünümler (sadece tek bir tabloya dayansalar bile) ve dinamik verileri parametreli görünümler veya saklı prosedürler olarak uygulamaya çalışıyorum. Sadece tek bir değerin yeterli olduğu veri sorguları için skaler fonksiyonları da kullanabilirsiniz.

Sadece bunlar (görünümler, saklı prosedürler ve skalar fonksiyonlar) harici uygulamalara görünür (ORM yoluyla veya doğrudan) ve tüm CRUD işlemlerinde kullanılır. Bu şema daha sonra tamamen dondurulurken, içsel olarak alttaki tabloları değiştirebilir, prosedürlerinizi vb. Geliştirebilirsiniz - bu, uygulamanızın uyumluluğunu bozmaz.

Kitaplardakiler için değil, gerçek dünya kriterleri için optimizasyon yapmayı deneyin.

Normalleştirme, veritabanı tasarımı ile ilgili her kitapta büyük bir konudur. Ancak, gerçek hayatta, normalizasyonun size fazla getirmeyeceği veya veritabanınızı yavaşlatacağı durumlar söz konusudur, örneğin, tekrarlanan bazı verileriniz varsa, ancak tekrarlama yüzdesi çok düşük vb. Normalizasyona karşı değilim. Burada söylemeye çalıştığım şey, biraz şüphecilik ve sağduyuyla mücadele etmen gerektiği.

Profil oluşturma oturumunu kaydedin ve analiz edin.

Yalnızca veritabanı şemasına dayalı veritabanı yeniden tasarımı tamamlanmadı. Veritabanınıza dinamik olarak bakın, yük testleri sırasında tıkanıklıkları bulmaya çalışın ve bunları ele alın. MS SQL Server olması durumunda , kaydedilen aktivite takibi üzerine bazı önerilerde bulunabilecek özel bir Ayar Danışmanı vardır.

İşte cevabım:

1. İlk önce mevcut veritabanı sistemini mümkün olduğu kadar iyi anlayın. Kullanıcıların yanı sıra bu sistemin tüm kullanımlarını da bilmeniz gerekir. Sisteme gelen tüm kaynakları ve kaynak sistemleri olarak hizmet edebileceği sistemleri bilmeniz gerekir.

2. Operasyonel mi raporlama mı yoksa her ikisi de mi, sistemin tüm farklı kullanımlarını tanımlamanız gerekir. Veritabanını kullanıyor olabilecek uygulamaları ve giriş sistemini tanımlayın. Bunu yaparak, mevcut veritabanının kullanılmayan ve artık gerekmeyen öğelerini bileceksiniz.

3. Ayrıca veriyi veri tabanına yükleyen ve veri tabanından veri alan mevcut ETL sürecini analiz edip anlayın.

4. Veritabanının tüm veri öğelerini ve yinelenen öğeleri tanımlamanıza yardımcı olabilecek bir kutu matrisi oluşturabilirseniz anlayın.

5. Tüm bilgileri aldıktan sonra, gereksinim toplamanızın bir parçası olarak topladığınız bilgilerle veritabanını ilk kez tasarlıyormuşsunuz gibi yeniden tasarlamaya yaklaşabilirsiniz.

6. İyi şanslar!