Veritabanı Tasarımında Temel Görevler

1.1 Tanıtım

Bir veritabanı tasarlamak, bir Java projesinin mimarisini tasarlamaya biraz benzer. Tüm verileri birkaç tabloya koyabilir veya şemalardan ve onlarca tablodan güzel bir veri yapısı oluşturabilirsiniz.

Bir geliştiricinin bir veritabanı tasarlarken genellikle karşılaştığı görevler şunlardır:

1. Gerekli tüm bilgilerin veritabanında saklanmasını sağlamak.
2. Gerekli tüm talepler hakkında veri elde etme olasılığının sağlanması.
3. Verilerin fazlalığını ve tekrarını azaltmak.
4. Veritabanı Bütünlüğünün Sağlanması
5. Veri erişim hızı optimizasyonu

Unutulmaması gereken en önemli şey, ideal bir veritabanı yapısı yapamayacağınızdır, çünkü. kodunuz gibi o da sürekli değişecektir. Veritabanı yapınızı tasarlarken aklınızda bulundurmanız gereken üç şey vardır:

1. Yapı yeterince iyi olmalıdır.
2. Diğer insanların anlayabileceği her şeyde bir mantık olmalıdır.
3. Erken optimizasyon tüm kötülüklerin anasıdır.

Dünyanın en iyi veritabanı yapısını yapmak zorunda değilsiniz . Hala değişecek. Göreviniz, veritabanınızın yapısındaki 20 değişiklikten sonra bunu çözmenin yeterince kolay olmasını sağlamaktır.

Büyük ihtimalle işinizin ilk yıllarında, sıfırdan bir üs tasarlamanız konusunda kimse size güvenmeyecektir. Mevcut bir şemada değişiklikler yapacaksınız. Hangi ilkeler temelinde düzenlendiğini anlamaya çalışmalı ve onlara bağlı kalmalısınız . Tüzükleri ile başka birinin manastırına girmezler.

Gerekli olana kadar veritabanını optimize etmeyin . Tabloda yalnızca birkaç yüz satır varsa, büyük olasılıkla DBMS onu bellekte tutacak ve sorguları önbelleğe alacaktır.

Öte yandan, önemli isteklerin çalışmasını onlarca hatta yüzlerce kez hızlandırabilmelisiniz. Ve bunu nasıl yapacağınızı bilseniz iyi olur. Lisede ilk sene nasıl derler? "Okulda sana öğretilen her şeyi unut..."

Veritabanı normalizasyonunun ne olduğunu biliyorsanız, sizi memnun etmek için acele ediyorum, işinizde büyük olasılıkla ilgileneceksiniz . Hiçbir şey, projenin kutsal alanları için veri tabanının hızından daha önemli değildir. Ve veritabanından veri seçimini hızlandırmak için 200 (!) Tabloyu bir (korkunç fazlalıkla) birleştirmeniz gerekiyorsa, bunu yapmanız gerekecek.

1.2 Kitaplık Tasarımı

Konu alanına biraz dalalım ve tipik bir kitap kitaplığı kadar basit bir şey kullanarak veritabanı tasarımı hakkında düşünelim.

Herhangi bir kütüphanenin ana görevi, kitap fonunun işlenmesidir. Üç ana sistem kullanıcısı grubunu ayırt etmek kolaydır: okuyucu, kütüphaneci, yönetici . Her birinin etkinliği bir kullanım durumu diyagramında gösterilir.

Şimdiden, gelecekteki veritabanının bazı varlıkları ve ilişkileri ayırt edilebilir:

Bu yaklaşımla okuyucuyu kitapla nasıl bağlayacağı net değildir (okuyucunun “alma/alma” ilişkisinde bir aritmetik yoktur. Kitabın birden fazla nüshası varsa o zaman birden fazla okuyucuya verilebilmektedir. bir kitap tek nüsha olarak anlaşılırsa, o zaman mevcut okuyucunun kitaplar tablosuna kaydedildiğinde, bu kitabı daha önce kimin (ve kaç kez) aldığına dair bilgi almak imkansız olacaktır.

Çözüm, ek bir varlığın - bir kitap yayınlamak için bir kartın - tanıtılması olabilir . Kitap okuyucuya verildiğinde bir kart oluşturulur ve kitap teslim edildiğinde üzerine karşılık gelen bir işaret konur. Bu kartlar sayesinde her kullanıcının borcu belirlenmekte ve kitap kullanım istatistikleri hesaplanmaktadır. Okuyucu tarafından literatür ayırtma işlemi yapılırken ayrıca bir kart başlatılır, rezerve edilen literatür belirli bir süre içerisinde okuyucu tarafından alınmaz ise kart imha edilir. Bir okuyucunun rezerve edebileceği kitap sayısında bir sınır vardır.

Literatürü seçerken kullanıcı, arama sonuçlarını yazara, başlığa, yayın yılına göre filtreleyebilme özelliğiyle literatür kataloğunu görüntüler.

Kütüphanedeki tüm kitaplar için istatistikler hesaplanırken, kitabın belirli bir süre için yayınlanan nüsha sayısı da hesaplanabilir. Hesaplamanın gerçekleştirildiği minimum kitap örneği sayısını da ayarlayabilirsiniz. Bu istatistiklere göre kullanılmayan kitaplar kütüphaneden silinmektedir.

Konu alanının aşağıdaki ana varlıkları ayırt edilebilir:

• kullanıcı (kütüphaneciler ve yöneticiler);
• okuyucu;
• Okuma odası;
• kitap;
• kitap verme kartı;
• kitap rezervasyon kartı.

Veritabanının değiştirilmiş ER diyagramı şekilde gösterilmiştir.

Şekil 1'de gösterilen kullanım durumlarına göre, veritabanı aşağıdaki sorguları uygulamalıdır (kapsamlı bir liste değil):

• belirtilen koşullarla eşleşen kitapları görüntüleyin;
• zamanında kapatılmamış kitapların verilmesi için kartları olan kullanıcıları görüntüleyin (kütüphaneci borçluları arıyor);
• verilen kullanıcının kitap ödünç verme kartlarına karşılık gelen ve zamanında kapatılmamış tüm kitapları görüntüleyin (kullanıcı yeni kitaplar için kütüphaneye geldi - borçlu olup olmadığını görmeniz ve onu bu konuda bilgilendirmeniz gerekir);
• N saniyeden önce oluşturulmuş tüm rezervasyon kartlarını silin;
• belirtilen kullanıcının kapatılmamış kitap rezervasyon kartlarına karşılık gelen tüm kitapları görüntüleyin (okuyucu kitap sipariş etti ve onlar için kütüphaneye geldi - kütüphanecinin bu listeyi vermesi için alması gerekiyor).

1.3 Şema oluşumu

Bir veri şeması oluşturmak için, önce ER diyagramını varlıkların ayrıntılarıyla tamamlamanız (iyileştirmeniz) gerekir. Bazen aynı zamanda bir ER diyagramı oluştururken hatalar bulmak mümkündür - bu görevde kitabın "bir şekilde" kütüphane salonuyla bağlantılı olması gerektiği bulundu.

Bu, kitaba gerekli “salon numarası” yerleştirilerek yapılabilir, ancak bu yaklaşımla, aynı kitabın (farklı salonlarda geçiyorsa) veritabanında birkaç kez anlatılması gerekecektir. Daha doğru bir yaklaşım, ek bir varlık olan "kitap yerleştirme"yi tanıtmaktır. Şekil, eklenmiş bir varlık ve donanım içeren bir ER diyagramını göstermektedir.

Yukarıdaki ER diyagramı ana tabloları, ilişkileri ve öznitelikleri yansıtır; temelinde bir veritabanı modeli oluşturabilirsiniz. ER diyagramı için bir standart yoktur, ancak bir takım notasyonlar vardır (Chen, IDEFIX, Martin, vb.), ancak alan modeli için ne standart ne de notasyonlar bulunamamıştır. Bununla birlikte, böyle bir diyagramın oluşturulması sırasında, bazen dizinler ve veri türleri olmak üzere anahtar alanlar (dış ve iç) zorunlu olarak vurgulanır.

Bu durumda, aşağıdaki şemada:

• bağlantılar için Martin gösterimi ("kaz ayağı" kullanılır);
• tablolar 3 bölüme ayrılmış dikdörtgenler olarak gösterilir:
• Tablo ismi;
• dahili tuşlar (işaretleyici ile işaretlenmiştir);
• kalan alanlar, zorunlu olanlar ise bir işaretleyici ile işaretlenmiştir.

Bu modeli geliştirirken, yöneticiler tablosunu kütüphaneciler tablosuyla birleştirme isteği vardı - ancak kullanıcılar tablosunu ekleyin:

• yönetici belirli bir odayla ilişkili değildir (ilgili alanı boş değerlerle doldurmanız gerekir);
• bu muhtemelen erişim haklarının dağıtımını karmaşıklaştıracaktır - artık yalnızca veritabanı yöneticisi (özel bir DBMS paneli aracılığıyla çalışan ve geliştirilmekte olan sistemde hesabı olmayan) yöneticiler tablosuna erişebilir. Ancak, tabloları birleştirirken, kullanıcı sorguları yeni tabloya erişim gerektirecektir.

Bu diyagramı oluştururken, ER diyagramında bir kusur bulundu ve düzeltildi - librarians_roomskütüphanecileri ve salonları birleştiren bir tablo eklendi. Bu gereklidir, çünkü bir kütüphaneci birkaç odada çalışabilir, ancak birkaç kütüphaneci aynı odada çalışabilir.

Veritabanlarını tasarlarken, en azından yukarıdaki örnekteki gibi akıl yürütebilmelisiniz. Başarılı olduğunuzu düşünüyorsanız, daha da ileri gidelim: daha fazla teori.