Veritabanı tasarımına nasıl yaklaşıyorsunuz? [kapalı]

Öncelikle bir web geliştiricisiyim ve başlamak istediğim birkaç kişisel projem var.

Beni rahatsız eden bir şey de veritabanı tasarımı. Ben okul db normalizasyon ve bunun gibi şeyler geçirdim ama birkaç yıl önce oldu ve ben okul dışında ilişkisel veritabanı tasarımı ile hiç deneyimim olmadı.

Peki veritabanına web uygulaması açısından nasıl yaklaşıyorsunuz? Nasıl başlıyorsunuz ve neye dikkat ediyorsunuz? Dikkatli bayraklar nelerdir?

Veritabanı tasarımı ile ilgili şimdiye kadar satın aldığım en iyi kitap Michael Hernandez tarafından Mete Mortals için Veritabanı Tasarımı idi : ISBN: 0-201-69471-9. Amazon Listing Üçüncü bir baskısı olduğunu fark ettim.

Üçüncü baskıya bağlantı

Bir veritabanı tasarlama sürecinin (baştan sona) tüm işleminde size yol gösterir. Bu kitapla başlamanızı tavsiye ederim.

Gruplara veya parçalara bakmayı öğrenmelisin. Veritabanı tasarımı, programlama gibi basit yapı taşlarına sahiptir. Bu basit yapı taşlarını tam olarak anlarsanız, herhangi bir veritabanı tasarımıyla başa çıkabilirsiniz.

Programlamada:

• Yapılar
• Başka Yapı Varsa
• Döngülerken Yap
• Döngülere Kadar Yap
• Vaka Yapıları

Veritabanları ile:

• Veri Tabloları
• Arama Tabloları
• Birebir ilişkiler
• Bire Çok İlişkiler
• Çoktan çoğa ilişkiler
• Birincil anahtarlar
• Yabancı anahtarlar

İşleri ne kadar basit yaparsanız o kadar iyi olur. Veritabanı, verileri cubbie deliklerine koyduğunuz bir yerden başka bir şey değildir. Bu cubbie deliklerinin ne olduğunu ve bunlarda ne tür şeyler istediğinizi belirleyerek başlayın.

İlk denediğinizde asla mükemmel veritabanı tasarımı oluşturmayacaksınız. Bu bir gerçek. Tasarımınız süreç boyunca çeşitli ayrıntılandırmalardan geçecektir. Bazen, siz veri girmeye başlayana kadar bazı şeyler belirgin görünmez ve sonra bir anınız olur .

Web kendi zorluklarını getiriyor. Bant genişliği sorunları. Vatansızlık. Başlayan, ancak hiç bitmeyen işlemlerden hatalı veriler.

Hem nesne yönelimli programlama hem de (çoğunlukla işlemsel, ancak bazı OLAP) veritabanı tasarımı yapıyorum ve durumlarım için, yinelenen temalar var (en azından OLTP ile).

3nf normalizasyon uygulamak, tek sorumluluk ilkesinin bazı varyantlarını uygulamama yardımcı olur. Bir tablo sisteminizdeki bir kavramı temsil etmelidir - ve kavramlar gerçekliği taklit etmeye çalışacak şekilde birbirleriyle ilişkili olmalıdır; Örneğin, bir Müşterinin 0 veya daha fazla Etkinliğe sahip olabileceği bir sistem oluşturuyorsam, bir Müşteri Tablosu ve bir Etkinlik Tablosu oluştururum. Etkinlik tablosunun Müşteri tablosuyla yabancı anahtar ilişkisi vardır. Saklı yordamlar oluştururken, Müşterinin ve faaliyete katılmak için bir dış birleştirme kullandığınızdan emin olurum çünkü bir Müşterinin 0 etkinliği olabileceği iş gereksinimi.

Ayrıca köprü (link) tablolarını kullanarak genişletilebilirlik fırsatlarına dikkat ediyorum. Örneğin, bir kitabın sınırsız (değişken) yazar sayısına sahip olabileceği bir iş kuralını temsil etmeye çalışsaydım, bir Kitap Tablosu, bir Yazar tablosu ve her ikisine de yabancı anahtar referansları olan bir köprü / bağlantı tablosu oluştururdum Kitap ve Yazar.

Ayrıca, tüm tablolarda yedek anahtarlar kullanıyorum (tipik olarak otomatik olarak artan kimlik sütunları, ancak belki de Kılavuzlar - koddaki kılavuzlarla yapılan takas, basit bir tam sayıdan daha fazla bellek alanı kaplamasıdır) ve benim için doğal anahtarlara güvenmekten kaçınırım aramaları (Köprü / Bağlantı Tabloları hariç). Varsayılan olarak, ortak yabancı anahtar sütunlarında dizinler oluşturur ve dizinleme stratejilerini optimize etmek için zaman zaman saklı yordamları / sistem sorgularını gözden geçiririm. Kullandığım başka bir dizinleme stratejisi, kodumda bir arama sütununa dayalı bir koleksiyon oluşturduğum yerleri aramak ve arama sütunlarına uygun dizinler eklemektir.

Önce veritabanı şememi tasarlıyorum, sonra ondan nesneleri oluşturmak için ORM kullanıyorum. Ben bu şekilde biraz eski bir okulum; Akıllı, verimli bir veritabanı şeması oluşturmak için ORM'lere güvenmiyorum. Bu insanların işi ve yazılım tasarımının zanaatının bir parçası.

Bill Karwin'in SQL Antipatterns adlı kitabının veritabanı planlaması için gerçekten yararlı olduğunu gördüm . En kapsamlı olarak vurguladığı nokta, veritabanının verilerinizin bütünlüğünü ve anlamlılığını korumak için birçok fırsat sunması ve tasarımcıların bu özellikleri cazip nedenlerle görmezden gelmenin yaygın bir hatadır. Bu sorunları en baştan dikkate almak ve tüm tasarımı bilgilendirmelerine izin vermek faydalıdır ve daha sonra çatlaklar üzerinde kağıt atmaya çalışırken yener.

Veritabanı düzeyinde iş mantığı ve bütünlüğünü uygulamak için kapsamlı kısıtlamaları olan bir veritabanı kullanmayı tercih ederim. Genellikle veritabanını uygulama ve yalnızca bir arayüz olarak erişen bir şey olarak görüyorum. Bu, diğer "arayüzlerin" eklenmesini daha hoş ve anlaşılır bir deneyim haline getirir ve güvenlik için olumlu faydaları vardır.

Ayrıca veritabanının yapısını, başka bir şeye başlamadan önce tamamlamanız ve mühürlemeniz gerektiğini varsaymak yerine, değişen bir varlık olarak düşünmenin önemli olduğunu düşünüyorum. Değişikliği planlamalı ve DB'yi sürüm sisteminize yerleştirmelisiniz. Bu konuda güzel bir deneme var: Martin Fowler & Pramod Sadalage'ın Evrimsel Veritabanı Tasarımı (ve bunu okumamış olmama rağmen Sadalage tarafından konuyla ilgili bütün bir kitap).

Son olarak, kullanıcı hesapları / rolleri, donanım / konum / ana bilgisayar bağlantısı vb. Gibi çevresel sorunlar önemlidir ve bazen göz ardı edilir. Planlama yaparken bunları da aklınızda bulundurun.

veritabanı tasarımı, verilerin nasıl kullanılacağı düşünülmeden tamamen yapılamaz, bu nedenle kısa bir adım listesi:

• varlıklar arasındaki ilişkiyi ele geçiren kısa cümleler yaz
• cümleleri temsil eden bir varlık-ilişki diyagramı çizin
• ER diyagramından normalleştirilmiş bir mantıksal veri modeli oluşturmak
• uygulamalar ve varlıklar için CRUD matrisi oluşturma
• her bir varlığın yaşam döngüsünün kapsamını doğrulamak için matrisi kullanın
• her uygulama için subkemaları çıkar
• her bir ana / CRUD operasyonu için subkemalar üzerindeki navigasyon yollarını inceleyin
• gerekli olacak raporları düşünün
• yukarıdakilerin tümüne dayanarak fiziksel veri modelini tasarlayabilecek; uygun olduğunda yıldız şemalarını denormalize edin, bölümlere ayırın ve kullanın

Bir veritabanını başarılı bir şekilde tasarlamak için önce birkaç şeyi göz önünde bulundurmanız gerekir:

• Hangi verileri saklamam gerekiyor ve sakladığım diğer verilerle nasıl ilişkili. Bu verilerin zaman içinde nasıl değişmesi gerekecek? Bir anlık görüntüyü zamanında görebilmem gerekir mi (2009'dan itibaren bu sipariş) veya yalnızca geçerli olana ihtiyacım var mı (yalnızca aktif kullanıcılar)?
• Verilerimin anlamlı olduğundan ve zaman içinde anlamı koruduğundan (veri bütünlüğü) nasıl emin olabilirim?
• Veri erişiminin hızlı olduğundan nasıl emin olabilirim?
• Verilerimi nasıl güvende tutabilirim?

Bu nedenle, bir veritabanı tasarlamaya başlamadan önce, normalleştirme ve verilerin bütünlüğünü korumak için kullanılan bir veritabanının özelliklerini öğrenmeniz gerekir.

O zaman performans ayarını anlamanız gerekir. Bu erken değildir, performans çoğu veritabanının kritik başarısızlık noktasıdır ve milyonlarca kaydınız olduğunda düzeltmek çok zordur.

Son olarak, verilerin kötü niyetli olarak değiştirilmemesini sağlamak veya verilerin kimin ve ne zaman ve ne zaman olduğunu öğrenmek için zaman içinde değişiklikleri izleyebilmenizi sağlamak için verilerin nasıl güvenliğini ve hangi verilerin güvenliğinin sağlanması gerektiğini ve hangi dahili denetimlere ihtiyacınız olduğunu anlamanız gerekir. bir değişiklik yapıldı ve önceki sürümlere dönebildi.

Daha sonra yeniden düzenleme yapılması gerekeceğinden veritabanlarını yeniden düzenleme hakkında biraz okumak da yararlıdır ve mümkün olduğunca kolay bir şekilde yeniden düzenleme yapabilmeniz için birimlerin nasıl ayarlanacağını bilmek faydalıdır.

Genel olarak veriler, uygulamayı yıllarca geride bırakmaktadır, uygulamanın kalbidir ve çoğunlukla ilgisiz bazı aptal veri deposu olarak düşünülmemelidir.

Genel anlamda, iyi bir veritabanı tasarımı iyi bir veritabanı tasarımıdır - web kullanımı için en büyük soru, verilere nasıl erişeceğiniz ve temelde web'in sahip olmadığı durumu gerektirebilecek şeyleri nasıl yöneteceğiniz olacaktır.

Bunu düşünerek, yaklaşımım gerçekten çok fazla deneyime dayanıyor ... ama şema veya nesnelerle başlasanız da aynı şeyi yapmaya çalışıyorsunuz, yani verilerinizin kullanılabilir bir modelini oluşturuyor - önemli sayıda Projeler, model ve şema arasında oldukça doğrudan bir ilişki olmakla yükümlüdür (her durumda değil ve muhtemelen tüm tablolar / nesneler için değil), bu yüzden gerçekten rahat ve buradan çalıştığınız yerden başlayarak iyi bir model oluşturma meselesidir.

İyi bir model oluşturma açısından - @Tim, veritabanları için aşağıya sahiptir ve temel olarak nesne modelinizi oluşturmak genel olarak benzer olacaktır - benzersiz olan, hiyerarşi nedir, çok sayıda ilişkinin olduğu yerler, vb. bir veritabanına gidin, tüm iyi şeyleri yaptığınızdan emin olun.

Ayrıca şemayı sıfırdan oluşturmanıza ve değişiklik yaparken güncellemenize izin vermek için kod veya ddl kodunuz olduğundan emin olun (koddaki ddl benim tercih ettiğim yöntemdir - bir sistemim var ve çalışıyor).

Büyük bir beyaz tahta ve bir sürü farklı renk kalemiyle başlıyorum. Farklı renkler farklı şeyler ifade eder. Ve çizmeye başladım. Genellikle siyah renkte kesin olan şeyleri, mavi renkte olanları ve yeşil renkte olmayan şeyleri çizerim. Kırmızı önemli notlar içindir. Ben bolca silip yeniden çiziyorum. Ne tür şeyleri sorgulamamız ve modelin desteklediğinden emin olmam gerektiğini düşünüyorum. Eğer yapmazsa yapana kadar ayarlayacağım.

Sonunda model çok büyürse Visio'ya taşıyacağım ve tahtadaki parçalar üzerinde çalışacağım.

Son olarak uzatma noktalarını düşünüyorum. Çoğu insanın yaptığı en büyük hata, kendi veritabanını tasarlamak ve sonra "Ben veritabanı ile işim bitti" demek ve devam etmektir. Veritabanını asla bitirmediniz. Aldığınız her değişiklik isteğinin bu düzeye kadar inmesi muhtemeldir. Nasıl ekleyeceğinizi düşünün. Ne tür taleplerin olabileceğini düşünün ve bunları bağlayabildiğinizi görün. Genişletilebilirlik hakkında hiç düşünmüyorsanız, bu değişiklik istekleri geldiğinde büyük tasarım borcuna gireceksiniz.

"SQL sonra ORM" ya da tam tersi, size kalmış. Önce modelinizin iyi bir temel oluşturduğundan emin olun.

Önce nesneleri tasarlıyorum, sonra şemayı oluşturmak için ORM (nHibernate gibi) kullanıyorum. Tersini yapmaktan çok daha fazla esneklik sağlıyor.

Bir sonraki adım, oluşturulan şemanın optimizasyonudur.

Veritabanı tablolarının ilk tasarlandığı bir proje gördüğümden bu yana uzun zaman geçti.

Şimdiye kadar diğer arkadaşlar tarafından açıkça belirtilmeyen birkaç şey:

• Veritabanı tasarımının profesyonel biri tarafından yapılması en iyisidir. Elbette öğrenmek tamam, ancak modelleme veya veritabanı tasarımında iyi usta değilse, orta veya büyük bir model oluşturmayı önermem. Bunun nedeni, yanlış bir tasarımın maliyetinin genellikle çok yüksek olmasıdır.

• Sistem hedeflerini ve kullanıcı gereksinimlerini iyi bilir. Gereksinimleri bilmeden doğru veri modelini tasarlayamazsınız.

• Programlarda hangi kodun yapılacağını ve DB'nin ilgilenmesine izin verecek kodu öğrenin. Bu, veri sütununun null değil null değerini ayarlamanız için gereklidir. Bu, UR'nizi doğru bir şekilde belirtmeniz için de gereklidir.

• Birincil anahtarlarınızı iyi belirleyin. Mümkün olduğunda basit anahtarlar için gidin.

• Diğer uygulamalarla entegrasyon ihtiyaçlarını göz önünde bulundurun.

• Evrensel veri modellerini kullanmayı düşünün ve adlandırma ve veri sütunu boyutunda endüstri standartlarını izleyin.

• Gelecekteki ihtiyaçları düşünün (biliniyorsa ve uygulanabilir olduğunda)

• Modunuzun başkaları tarafından incelenmesini sağlayın.

• Modelleme için bir araç kullanın - Bir ERD aracı veya bir UML aracı.

• Oluşturulan DDL kodunu inceleyin ve anlayın. Bunu kabul etme.