Langkah Reka Bentuk Pangkalan Data Utama

2.1. Rekabentuk konsep

Reka bentuk pangkalan data dijalankan dalam tiga peringkat:

1. rekabentuk konsep;
2. reka bentuk logik;
3. reka bentuk fizikal.

Tujuan fasa reka bentuk konsep adalah untuk mencipta model data konsep berdasarkan idea pengguna tentang kawasan subjek. Untuk mencapainya, satu siri prosedur berurutan dijalankan. Contoh skema entiti (konseptual):

1. Definisi entiti dan dokumentasinya. Untuk mengenal pasti entiti, objek ditakrifkan yang wujud secara bebas daripada yang lain. Objek sedemikian adalah entiti. Setiap entiti diberi nama yang bermakna yang boleh difahami oleh pengguna. Nama dan perihalan entiti dimasukkan ke dalam kamus data. Jika boleh, bilangan kejadian yang dijangkakan bagi setiap entiti ditetapkan.

2. Penentuan perhubungan antara entiti dan dokumentasi mereka. Hanya perhubungan antara entiti tersebut ditakrifkan yang diperlukan untuk memenuhi keperluan reka bentuk pangkalan data. Jenis setiap satu ditetapkan. Kelas keahlian entiti didedahkan. Pautan diberikan nama bermakna yang dinyatakan oleh kata kerja. Penerangan terperinci bagi setiap sambungan, yang menunjukkan jenisnya dan kelas kepunyaan entiti yang mengambil bahagian dalam sambungan, dimasukkan ke dalam kamus data.

3. Penciptaan model ER bagi kawasan subjek. Gambar rajah ER digunakan untuk mewakili entiti dan hubungan antara mereka. Berdasarkan mereka, imej visual tunggal kawasan subjek yang dimodelkan dicipta - model ER kawasan subjek.

4. Definisi atribut dan dokumentasinya. Semua atribut yang menerangkan entiti model ER yang dicipta didedahkan. Setiap atribut diberi nama yang bermakna yang boleh difahami oleh pengguna. Maklumat berikut disimpan dalam kamus data untuk setiap atribut:

• nama atribut dan perihalan;
• jenis dan dimensi nilai;
• nilai lalai untuk atribut (jika ada);
• sama ada atribut boleh mempunyai nilai NULL;
• sama ada atribut itu adalah komposit, dan jika ya, apakah atribut mudah yang terkandung di dalamnya. Sebagai contoh, atribut "Nama penuh pelanggan" boleh terdiri daripada atribut ringkas "Nama keluarga", "Nama pertama", "Patronymic", atau ia boleh menjadi mudah, mengandungi nilai tunggal, seperti "Sidorsky Evgeniy Mikhailovich". Jika pengguna tidak memerlukan akses kepada elemen individu "Nama", maka atribut itu dibentangkan sebagai mudah;
• sama ada atribut itu dikira, dan jika ya, bagaimana nilainya dikira.

5. Definisi nilai atribut dan dokumentasinya. Untuk setiap atribut entiti yang mengambil bahagian dalam model ER, satu set nilai yang sah ditentukan dan nama diberikan kepadanya. Sebagai contoh, atribut "Jenis akaun" hanya boleh mempunyai nilai "deposit", "semasa", "atas permintaan", "akaun kad". Entri kamus data yang berkaitan dengan atribut dikemas kini dengan nama set nilai atribut.

6. Definisi kunci utama untuk entiti dan dokumentasinya. Langkah ini dipandu oleh takrif kunci utama - sebagai atribut atau set atribut entiti yang membenarkan pengenalpastian unik kejadiannya. Maklumat kunci utama diletakkan dalam kamus data.

7. Perbincangan model data konsep dengan pengguna akhir. Model data konseptual diwakili oleh model ER dengan dokumentasi yang disertakan mengandungi penerangan tentang model data yang dibangunkan. Jika ketidakkonsistenan domain ditemui, maka perubahan dibuat pada model sehingga pengguna mengesahkan bahawa model yang dicadangkan oleh mereka mencerminkan pandangan peribadi mereka dengan secukupnya.

2.2 Reka bentuk logik

Tujuan peringkat reka bentuk logik adalah untuk mengubah model konsep berdasarkan model data yang dipilih kepada model logik yang bebas daripada ciri-ciri DBMS yang digunakan kemudian untuk pelaksanaan fizikal pangkalan data. Untuk mencapainya, prosedur berikut dilakukan.

Contoh skema pangkalan data logik.

1. Memilih model data. Selalunya, model data hubungan dipilih kerana kejelasan pembentangan jadual data dan kemudahan bekerja dengannya.

2. Mentakrifkan set jadual berdasarkan model ER dan mendokumentasikannya. Jadual dibuat untuk setiap entiti model ER. Nama entiti ialah nama jadual. Hubungan antara jadual diwujudkan melalui mekanisme kunci utama dan asing. Struktur jadual dan hubungan yang telah ditetapkan antara mereka didokumenkan.

3. Normalisasi jadual. Untuk melaksanakan normalisasi dengan betul, pereka bentuk mesti memahami semantik dan corak penggunaan data dengan mendalam. Pada langkah ini, dia menyemak ketepatan struktur jadual yang dibuat dalam langkah sebelumnya dengan menggunakan prosedur normalisasi kepada mereka. Ia terdiri daripada membawa setiap jadual ke sekurang-kurangnya NF ke-3. Hasil daripada normalisasi, reka bentuk pangkalan data yang sangat fleksibel diperolehi, yang memudahkan untuk membuat sambungan yang diperlukan kepadanya.

4. Menyemak model data logik untuk kemungkinan melaksanakan semua transaksi yang disediakan oleh pengguna. Transaksi ialah satu set tindakan yang dilakukan oleh pengguna individu atau program aplikasi untuk menukar kandungan pangkalan data. Jadi, contoh transaksi dalam projek BANK boleh menjadi pemindahan hak untuk menguruskan akaun pelanggan tertentu kepada pelanggan lain. Dalam kes ini, beberapa perubahan perlu dibuat pada pangkalan data sekaligus. Jika komputer ranap semasa transaksi, pangkalan data akan berada dalam keadaan tidak konsisten kerana beberapa perubahan telah dibuat dan yang lain tidak. Oleh itu, semua perubahan separa mesti dibuat asal untuk mengembalikan pangkalan data kepada keadaan konsisten sebelumnya.

Senarai urus niaga ditentukan oleh tindakan pengguna dalam kawasan subjek. Menggunakan model ER, kamus data, dan perhubungan yang mantap antara kunci utama dan asing, percubaan dibuat untuk melaksanakan semua operasi capaian data yang diperlukan secara manual. Jika mana-mana operasi manual gagal, maka model data logik yang disusun tidak mencukupi dan mengandungi ralat yang mesti dihapuskan. Mungkin ia berkaitan dengan jurang dalam model entiti, perhubungan atau atribut.

5. Penentuan keperluan sokongan integriti data dan dokumentasinya. Keperluan ini adalah sekatan yang ditetapkan untuk mengelakkan data bercanggah daripada dimasukkan ke dalam pangkalan data. Pada langkah ini, isu integriti data diliputi tanpa mengambil kira aspek khusus pelaksanaannya. Jenis sekatan berikut harus dipertimbangkan:

• data yang diperlukan. Mengetahui jika terdapat atribut yang tidak boleh mempunyai nilai NULL;
• sekatan ke atas nilai atribut. Nilai sah untuk atribut ditakrifkan;
• integriti entiti. Ia dicapai jika kunci utama entiti tidak mengandungi nilai NULL;
• integriti rujukan. Difahamkan bahawa nilai kunci asing mesti ada dalam kunci utama salah satu baris jadual untuk entiti induk;
• sekatan yang dikenakan oleh peraturan perniagaan. Sebagai contoh, dalam kes projek BANK, peraturan boleh diterima pakai yang melarang pelanggan daripada mengurus, katakan, lebih daripada tiga akaun.

Maklumat tentang semua kekangan integriti data yang ditetapkan diletakkan dalam kamus data.

6. Penciptaan versi akhir model data logik dan perbincangan dengan pengguna. Langkah ini menyediakan versi akhir model ER, yang mewakili model data logik. Model itu sendiri dan dokumentasi yang dikemas kini, termasuk kamus data dan skema pautan jadual hubungan, dibentangkan untuk semakan dan analisis oleh pengguna, yang mesti memastikan ia mewakili kawasan subjek dengan tepat.

2.3. Reka bentuk fizikal

Tujuan peringkat reka bentuk fizikal adalah untuk menerangkan pelaksanaan khusus pangkalan data yang terletak dalam memori luaran komputer. Ini adalah penerangan tentang struktur penyimpanan data dan kaedah yang cekap untuk mengakses data pangkalan data. Dalam reka bentuk logik, mereka menjawab soalan - apa yang perlu dilakukan, dan dalam reka bentuk fizikal - cara dipilih bagaimana melakukannya. Prosedur reka bentuk fizikal adalah seperti berikut.

1. Mereka bentuk jadual pangkalan data menggunakan DBMS yang dipilih. DBMS relasi dipilih untuk digunakan untuk mencipta pangkalan data yang dihoskan pada media mesin. Fungsinya untuk mereka bentuk jadual dikaji dengan mendalam. Kemudian reka bentuk jadual dan skema sambungannya dalam persekitaran DBMS dilakukan. Projek pangkalan data yang disediakan diterangkan dalam dokumentasi yang disertakan.

2. Pelaksanaan peraturan perniagaan dalam persekitaran DBMS yang dipilih. Mengemas kini maklumat dalam jadual boleh dihadkan oleh peraturan perniagaan. Cara ia dilaksanakan bergantung pada DBMS yang dipilih. Sesetengah sistem untuk melaksanakan keperluan kawasan subjek menawarkan lebih banyak ciri, yang lain kurang. Dalam sesetengah sistem, tiada sokongan untuk melaksanakan peraturan perniagaan sama sekali. Dalam kes ini, aplikasi dibangunkan untuk melaksanakan batasannya.

Semua keputusan yang dibuat berkaitan dengan pelaksanaan peraturan perniagaan domain diterangkan secara terperinci dalam dokumentasi yang disertakan.

3. Mereka bentuk organisasi fizikal pangkalan data. Langkah ini memilih organisasi fail terbaik untuk jadual. Urus niaga yang akan dilakukan dalam pangkalan data yang direka bentuk dikenal pasti, dan yang paling penting diserlahkan. Urus niaga dianalisis - bilangan urus niaga yang boleh diproses dalam selang masa tertentu, dan masa tindak balas - tempoh masa yang diperlukan untuk menyelesaikan satu transaksi. Mereka berusaha untuk meningkatkan pemprosesan transaksi dan mengurangkan masa tindak balas.

Berdasarkan penunjuk ini, keputusan dibuat untuk mengoptimumkan prestasi pangkalan data dengan mentakrifkan indeks dalam jadual yang mempercepatkan pemilihan data daripada pangkalan data, atau dengan mengurangkan keperluan untuk tahap normalisasi jadual. Ruang cakera yang diperlukan untuk menampung pangkalan data yang dibuat dianggarkan. Berusaha untuk meminimumkannya.

Keputusan yang dibuat mengenai isu di atas didokumenkan.

4. Pembangunan strategi perlindungan pangkalan data. Pangkalan data adalah sumber korporat yang berharga, dan banyak perhatian diberikan kepada perlindungannya. Untuk melakukan ini, pereka bentuk mesti mempunyai pemahaman yang lengkap dan jelas tentang semua perlindungan yang disediakan oleh DBMS yang dipilih.

5. Organisasi pemantauan fungsi pangkalan data dan pelarasannya. Selepas penciptaan projek fizikal pangkalan data, pemantauan berterusan fungsinya dianjurkan. Maklumat yang terhasil tentang tahap prestasi pangkalan data digunakan untuk menalanya. Untuk ini, cara DBMS yang dipilih juga terlibat.

Keputusan untuk membuat sebarang perubahan pada pangkalan data yang berfungsi harus dipertimbangkan dan ditimbang dengan teliti.