2.1. Desain konseptual

Perancangan basis data dilakukan dalam tiga tahap:

  1. desain konseptual;
  2. desain logis;
  3. desain fisik.

Tujuan dari fase desain konseptual adalah untuk membuat model data konseptual berdasarkan ide-ide pengguna tentang area subjek. Untuk mencapainya, serangkaian prosedur berurutan dilakukan. Contoh skema entitas (konseptual):

1. Definisi entitas dan dokumentasinya. Untuk mengidentifikasi entitas, objek didefinisikan yang ada secara independen dari yang lain. Objek seperti itu adalah entitas. Setiap entitas diberi nama yang bermakna yang dapat dipahami pengguna. Nama dan deskripsi entitas dimasukkan ke dalam kamus data. Jika memungkinkan, jumlah instance yang diharapkan dari setiap entitas ditetapkan.

2. Penentuan hubungan antar entitas dan dokumentasinya. Hanya hubungan antar entitas yang ditentukan yang diperlukan untuk memenuhi persyaratan desain basis data. Jenis masing-masing diatur. Kelas keanggotaan entitas terungkap. Tautan diberi nama bermakna yang diungkapkan oleh kata kerja. Deskripsi terperinci dari setiap koneksi, yang menunjukkan jenisnya dan kelas entitas yang berpartisipasi dalam koneksi, dimasukkan ke dalam kamus data.

3. Pembuatan model ER dari area subjek. Diagram ER digunakan untuk mewakili entitas dan hubungan di antara mereka. Berdasarkan mereka, satu gambar visual dari area subjek yang dimodelkan dibuat - model ER dari area subjek.

4. Definisi atribut dan dokumentasinya. Semua atribut yang mendeskripsikan entitas model ER yang dibuat akan terungkap. Setiap atribut diberi nama yang bermakna yang dapat dipahami pengguna. Informasi berikut disimpan dalam kamus data untuk setiap atribut:

  • nama atribut dan deskripsi;
  • jenis dan dimensi nilai;
  • nilai default untuk atribut (jika ada);
  • apakah atribut dapat memiliki nilai NULL;
  • apakah atributnya komposit, dan jika ya, terdiri dari atribut sederhana apa. Misalnya, atribut "Nama lengkap klien" dapat terdiri dari atribut sederhana "Nama belakang", "Nama depan", "Patronimik", atau bisa juga sederhana, berisi nilai tunggal, seperti "Sidorsky Evgeniy Mikhailovich". Jika pengguna tidak memerlukan akses ke elemen individual dari "Nama", maka atributnya disajikan sederhana;
  • apakah atribut dihitung, dan jika demikian, bagaimana nilainya dihitung.
Java university

5. Definisi nilai atribut dan dokumentasinya. Untuk setiap atribut entitas yang berpartisipasi dalam model ER, satu set nilai yang valid ditentukan dan diberi nama. Misalnya, atribut "Jenis akun" hanya boleh memiliki nilai "deposit", "current", "on demand", "card account". Entri kamus data yang terkait dengan atribut diperbarui dengan nama kumpulan nilai atribut.

6. Definisi primary key untuk entitas dan dokumentasinya. Langkah ini dipandu oleh definisi kunci primer - sebagai atribut atau sekumpulan atribut entitas yang memungkinkan identifikasi unik dari instance-nya. Informasi kunci utama ditempatkan di kamus data.

7. Diskusi model data konseptual dengan pengguna akhir. Model data konseptual diwakili oleh model ER dengan dokumentasi yang berisi deskripsi model data yang dikembangkan. Jika ketidakkonsistenan domain ditemukan, maka perubahan dilakukan pada model sampai pengguna mengonfirmasi bahwa model yang diusulkan oleh mereka cukup mencerminkan pandangan pribadi mereka.

2.2 Desain logika

Tujuan dari tahap desain logis adalah untuk mengubah model konseptual berdasarkan model data yang dipilih menjadi model logis yang independen dari fitur DBMS yang digunakan nanti untuk implementasi fisik basis data. Untuk mencapainya, prosedur berikut dilakukan.

Contoh skema basis data logis.

1. Memilih model data. Paling sering, model data relasional dipilih karena kejelasan penyajian data tabular dan kemudahan bekerja dengannya.

2. Menentukan sekumpulan tabel berdasarkan model ER dan mendokumentasikannya. Tabel dibuat untuk setiap entitas model ER. Nama entitas adalah nama tabel. Relasi antar tabel dibangun melalui mekanisme primary dan foreign key. Struktur tabel dan hubungan yang terjalin di antara mereka didokumentasikan.

3. Normalisasi tabel. Untuk melakukan normalisasi dengan benar, perancang harus sangat memahami semantik dan pola penggunaan data. Pada langkah ini, ia memeriksa kebenaran struktur tabel yang dibuat pada langkah sebelumnya dengan menerapkan prosedur normalisasi pada tabel tersebut. Ini terdiri dari membawa masing-masing tabel ke setidaknya NF ke-3. Sebagai hasil dari normalisasi, desain database yang sangat fleksibel diperoleh, yang membuatnya mudah untuk membuat ekstensi yang diperlukan.

4. Memeriksa model data logis untuk kemungkinan melakukan semua transaksi yang disediakan oleh pengguna. Transaksi adalah serangkaian tindakan yang dilakukan oleh pengguna individu atau program aplikasi untuk mengubah konten database. Jadi, contoh transaksi dalam proyek BANK dapat berupa pengalihan hak pengelolaan rekening klien tertentu ke klien lain. Dalam hal ini, beberapa perubahan perlu dilakukan pada database sekaligus. Jika komputer macet selama transaksi, database akan berada dalam keadaan tidak konsisten karena beberapa perubahan telah dilakukan dan yang lainnya belum. Oleh karena itu, semua perubahan parsial harus dibatalkan untuk mengembalikan database ke keadaan konsisten sebelumnya.

Daftar transaksi ditentukan oleh tindakan pengguna di area subjek. Dengan menggunakan model ER, kamus data, dan hubungan antara kunci utama dan kunci asing, upaya dilakukan untuk melakukan semua operasi akses data yang diperlukan secara manual. Jika ada operasi manual yang gagal, maka model data logis yang dikompilasi tidak memadai dan mengandung kesalahan yang harus dihilangkan. Mungkin mereka terkait dengan kesenjangan dalam model entitas, hubungan, atau atribut.

5. Penentuan persyaratan dukungan integritas data dan dokumentasinya. Persyaratan ini adalah batasan yang diberlakukan untuk mencegah data yang bertentangan dimasukkan ke dalam database. Pada langkah ini, masalah integritas data dicakup tanpa memperhatikan aspek spesifik dari implementasinya. Jenis pembatasan berikut harus dipertimbangkan:

  • data yang diperlukan. Mencari tahu apakah ada atribut yang tidak boleh memiliki nilai NULL;
  • pembatasan nilai atribut. Nilai yang valid untuk atribut ditentukan;
  • integritas entitas. Ini dicapai jika kunci utama entitas tidak berisi nilai NULL;
  • integritas referensial. Dipahami bahwa nilai kunci asing harus ada di kunci utama salah satu baris tabel untuk entitas induk;
  • pembatasan yang diberlakukan oleh aturan bisnis. Misalnya, dalam kasus proyek BANK, aturan dapat diadopsi yang melarang klien mengelola, katakanlah, lebih dari tiga akun.

Informasi tentang semua kendala integritas data yang ditetapkan ditempatkan di kamus data.

6. Pembuatan versi final model data logis dan diskusi dengan pengguna. Langkah ini menyiapkan versi final model ER, yang merepresentasikan model data logis. Model itu sendiri dan dokumentasi yang diperbarui, termasuk kamus data dan skema tautan tabel relasional, disajikan untuk ditinjau dan dianalisis oleh pengguna, yang harus memastikan bahwa itu mewakili area subjek secara akurat.

2.3. Desain fisik

Tujuan dari tahap desain fisik adalah untuk menggambarkan implementasi tertentu dari database yang terletak di memori eksternal komputer. Ini adalah deskripsi dari struktur penyimpanan data dan metode yang efisien untuk mengakses data database. Dalam desain logis, mereka menjawab pertanyaan - apa yang perlu dilakukan, dan dalam desain fisik - cara dipilih bagaimana melakukannya. Prosedur desain fisik adalah sebagai berikut.

1. Merancang tabel database menggunakan DBMS yang dipilih. DBMS relasional dipilih untuk digunakan untuk membuat database yang dihosting di media mesin. Fungsionalitasnya untuk mendesain tabel dipelajari secara mendalam. Kemudian desain tabel dan skema koneksinya di lingkungan DBMS dilakukan. Proyek database yang disiapkan dijelaskan dalam dokumentasi terlampir.

2. Implementasi aturan bisnis di lingkungan DBMS yang dipilih. Memperbarui informasi dalam tabel dapat dibatasi oleh aturan bisnis. Cara penerapannya bergantung pada DBMS yang dipilih. Beberapa sistem untuk menerapkan persyaratan area subjek menawarkan lebih banyak fitur, yang lain lebih sedikit. Di beberapa sistem, tidak ada dukungan untuk penerapan aturan bisnis sama sekali. Dalam hal ini, aplikasi dikembangkan untuk mengimplementasikan keterbatasannya.

Semua keputusan yang dibuat sehubungan dengan penerapan aturan bisnis domain dijelaskan secara rinci dalam dokumentasi terlampir.

3. Merancang organisasi fisik database. Langkah ini memilih organisasi file terbaik untuk tabel. Transaksi yang akan dilakukan dalam database yang dirancang diidentifikasi, dan yang paling penting disorot. Throughput transaksi dianalisis - jumlah transaksi yang dapat diproses dalam interval waktu tertentu, dan waktu respons - periode waktu yang diperlukan untuk menyelesaikan satu transaksi. Mereka berusaha keras untuk meningkatkan throughput transaksi dan mengurangi waktu respons.

Berdasarkan indikator ini, keputusan dibuat untuk mengoptimalkan kinerja database dengan menentukan indeks dalam tabel yang mempercepat pemilihan data dari database, atau dengan mengurangi persyaratan tingkat normalisasi tabel. Ruang disk yang diperlukan untuk mengakomodasi database yang dibuat diperkirakan. Berusahalah untuk meminimalkannya.

Keputusan yang dibuat pada isu-isu di atas didokumentasikan.

4. Pengembangan strategi perlindungan database. Basis data adalah sumber daya perusahaan yang berharga, dan banyak perhatian diberikan untuk perlindungannya. Untuk melakukannya, desainer harus memiliki pemahaman yang lengkap dan jelas tentang semua perlindungan yang disediakan oleh DBMS yang dipilih.

5. Organisasi pemantauan fungsi database dan penyesuaiannya. Setelah pembuatan proyek fisik database, pemantauan berkelanjutan atas fungsinya diatur. Informasi yang dihasilkan tentang tingkat kinerja database digunakan untuk menyetelnya. Untuk ini, sarana DBMS yang dipilih juga dilibatkan.

Keputusan untuk membuat perubahan apa pun pada database yang berfungsi harus dipertimbangkan dan ditimbang secara menyeluruh.