2.1. Desain konseptual
Desain database ditindakake ing telung tahap:
- desain konseptual;
- desain logis;
- desain fisik.
Tujuwan saka tahap desain konseptual yaiku nggawe model data konseptual adhedhasar gagasan pangguna babagan subyek. Kanggo nggayuh iki, sawetara prosedur sing berurutan ditindakake. Conto skema entitas (konseptual):
1. Definisi entitas lan dokumentasi. Kanggo ngenali entitas, obyek ditetepake sing ana kanthi bebas saka liyane. Objek kasebut minangka entitas. Saben entitas diwenehi jeneng sing migunani sing bisa dingerteni pangguna. Jeneng lan deskripsi entitas dilebokake ing kamus data. Yen bisa, jumlah kedadeyan sing dikarepake saben entitas disetel.
2. Penentuan hubungan antarane entitas lan dokumentasi. Mung hubungan antarane entitas sing ditetepake sing perlu kanggo nyukupi syarat desain database. Jinis saben disetel. Kelas anggota entitas dicethakaké. Tautan diwenehi jeneng sing teges sing ditulis nganggo kriya. Katrangan rinci babagan saben sambungan, sing nuduhake jinis lan kelas kepemilikan saka entitas sing melu sambungan kasebut, dilebokake ing kamus data.
3. Nggawe model ER saka area subyek. Diagram ER digunakake kanggo makili entitas lan hubungan ing antarane. Adhedhasar kasebut, gambar visual siji saka area subyek sing dimodelake digawe - model ER saka area subyek.
4. Definisi atribut lan dokumentasi. Kabeh atribut sing nggambarake entitas model ER sing digawe dicethakaké. Saben atribut diwenehi jeneng sing migunani sing bisa dingerteni pangguna. Informasi ing ngisor iki disimpen ing kamus data kanggo saben atribut:
- jeneng atribut lan katrangan;
- jinis lan ukuran nilai;
- nilai standar kanggo atribut (yen ana);
- apa atribut bisa duwe nilai NULL;
- apa atribut iku gabungan, lan yen ya, apa atribut prasaja kasusun saka. Contone, atribut "Jeneng lengkap Klien" bisa kalebu atribut prasaja "Jeneng mburi", "Jeneng", "Patronymic", utawa bisa uga prasaja, ngemot nilai tunggal, kayata "Sidorsky Evgeniy Mikhailovich". Yen pangguna ora mbutuhake akses menyang unsur individu saka "Jeneng", banjur atribut diwenehi prasaja;
- apa atribut diwilang, lan yen ya, kepiye cara ngitung.
5. Definisi nilai atribut lan dokumentasi. Kanggo saben atribut entitas sing melu model ER, sakumpulan nilai sing sah ditemtokake lan diwenehi jeneng. Contone, atribut "Jenis akun" mung bisa duwe nilai "simpenan", "saiki", "on demand", "akun kertu". Entri kamus data sing ana gandhengane karo atribut dianyari karo jeneng set nilai atribut.
6. Definisi kunci utama kanggo entitas lan dokumentasi. Langkah iki dipandu dening definisi kunci utama - minangka atribut utawa set atribut saka entitas sing ngidini identifikasi unik saka kedadeyan kasebut. Informasi kunci utama diselehake ing kamus data.
7. Diskusi model data konseptual karo pangguna pungkasan. Model data konseptual diwakili dening model ER kanthi dokumentasi sing ngemot deskripsi model data sing dikembangake. Yen ora konsistensi domain ditemokake, banjur owah-owahan digawe kanggo model nganti pangguna ngonfirmasi yen model sing diusulake cukup nggambarake tampilan pribadine.
2.2 Desain Logika
Tujuan saka tataran desain logis yaiku kanggo ngowahi model konsep adhedhasar model data sing dipilih dadi model logis sing ora gumantung saka fitur DBMS sing digunakake kanggo implementasi fisik database. Kanggo entuk, prosedur ing ngisor iki ditindakake.
Conto skema database logis.
1. Milih model data. Paling asring, model data relasional dipilih amarga kejelasan presentasi tabel data lan kepenak nggarap.
2. Nemtokake set tabel adhedhasar model ER lan dokumentasi. Tabel digawe kanggo saben entitas model ER. Jeneng entitas yaiku jeneng tabel. Hubungan antarane tabel ditetepake liwat mekanisme kunci utama lan manca. Struktur tabel lan hubungan sing ana ing antarane didokumentasikan.
3. Normalisasi tabel. Kanggo nindakake normalisasi kanthi bener, desainer kudu ngerti semantik lan pola panggunaan data kasebut. Ing langkah iki, dheweke mriksa bener struktur tabel sing digawe ing langkah sadurunge kanthi ngetrapake prosedur normalisasi. Iku kasusun ing nggawa saben tabel kanggo paling 3rd NF. Minangka asil normalisasi, desain database sing fleksibel banget dipikolehi, sing ndadekake gampang kanggo nggawe ekstensi sing dibutuhake.
4. Priksa model data logis kanggo kemungkinan nindakake kabeh transaksi sing diwenehake dening pangguna. Transaksi minangka sakumpulan tumindak sing ditindakake dening pangguna individu utawa program aplikasi kanggo ngganti isi database. Dadi, conto transaksi ing proyek BANK bisa dadi transfer hak kanggo ngatur akun klien tartamtu menyang klien liyane. Ing kasus iki, sawetara owah-owahan kudu digawe ing database bebarengan. Yen komputer kacilakan sajrone transaksi, database bakal dadi ora konsisten amarga sawetara owah-owahan wis digawe lan liyane durung. Mulane, kabeh owah-owahan parsial kudu dibatalake kanggo mbalekake database menyang kahanan konsisten sadurunge.
Dhaptar transaksi ditemtokake dening tumindak pangguna ing wilayah subyek. Nggunakake model ER, kamus data, lan hubungan sing diadegake ing antarane kunci utama lan manca, upaya ditindakake kanggo nindakake kabeh operasi akses data sing dibutuhake kanthi manual. Yen operasi manual gagal, model data logis sing dikompilasi ora cukup lan ngemot kasalahan sing kudu diilangi. Mbok menawa ana hubungane karo celah ing model entitas, hubungan, utawa atribut.
5. Penentuan syarat dhukungan integritas data lan dokumentasi. Persyaratan kasebut minangka watesan sing dilebokake kanggo nyegah data sing bentrok dilebokake ing basis data. Ing langkah iki, masalah integritas data dilindhungi tanpa nggatekake aspek tartamtu saka implementasine. Jinis-jinis larangan ing ngisor iki kudu dianggep:
- data sing dibutuhake. Nggoleki yen ana atribut sing ora bisa duwe nilai NULL;
- watesan ing nilai atribut. Nilai sing sah kanggo atribut ditetepake;
- integritas entitas. Iki digayuh yen kunci utama entitas ora ngemot nilai NULL;
- integritas referensial. Dimangerteni yen nilai kunci manca kudu ana ing kunci utama salah sawijining baris tabel kanggo entitas induk;
- watesan dileksanakake dening aturan bisnis. Contone, ing kasus proyek BANK, aturan bisa diadopsi sing nglarang klien ngatur, ngomong, luwih saka telung akun.
Informasi babagan kabeh watesan integritas data sing wis ditemtokake diselehake ing kamus data.
6. Nggawe versi final saka model data logis lan diskusi karo pangguna. Langkah iki nyiapake versi final saka model ER, sing makili model data logis. Model kasebut dhewe lan dokumentasi sing dianyari, kalebu kamus data lan skema link tabel relasional, disedhiyakake kanggo ditinjau lan dianalisis dening pangguna, sing kudu mesthekake yen kanthi akurat nggambarake area subyek.
2.3. Desain fisik
Tujuan saka tataran desain fisik kanggo njlèntrèhaké implementasine tartamtu saka database dumunung ing memori external komputer. Iki minangka gambaran babagan struktur panyimpenan data lan cara sing efisien kanggo ngakses data basis data. Ing desain logis, dheweke njawab pitakonan - apa sing kudu ditindakake, lan ing desain fisik - cara milih cara kanggo nindakake. Tata cara desain fisik kaya ing ngisor iki.
1. Ngrancang tabel database nggunakake DBMS sing dipilih. DBMS relasional dipilih kanggo digunakake kanggo nggawe database sing di-host ing media mesin. Fungsine kanggo ngrancang tabel ditliti kanthi jero. Banjur desain tabel lan skema sambungan ing lingkungan DBMS ditindakake. Proyek database sing disiapake diterangake ing dokumentasi sing diwenehake.
2. Implementasi aturan bisnis ing lingkungan DBMS sing dipilih. Nganyari informasi ing tabel bisa diwatesi dening aturan bisnis. Cara sing ditindakake gumantung marang DBMS sing dipilih. Sawetara sistem kanggo ngleksanakake syarat area subyek nawakake luwih akeh fitur, liyane kurang. Ing sawetara sistem, ora ana dhukungan kanggo ngetrapake aturan bisnis. Ing kasus iki, aplikasi dikembangake kanggo ngetrapake watesan kasebut.
Kabeh keputusan sing digawe gegayutan karo implementasine aturan bisnis domain diterangake kanthi rinci ing dokumentasi sing diwenehake.
3. Ngrancang organisasi fisik database. Langkah iki milih organisasi file sing paling apik kanggo tabel. Transaksi sing bakal ditindakake ing basis data sing dirancang diidentifikasi, lan sing paling penting disorot. Transaksi throughput dianalisis - jumlah transaksi sing bisa diproses ing interval wektu tartamtu, lan wektu respon - periode wektu sing dibutuhake kanggo ngrampungake siji transaksi. Dheweke ngupayakake nambah throughput transaksi lan nyuda wektu nanggepi.
Adhedhasar indikator kasebut, keputusan digawe kanggo ngoptimalake kinerja database kanthi nemtokake indeks ing tabel sing nyepetake pilihan data saka basis data, utawa kanthi ngurangi syarat kanggo tingkat normalisasi tabel. Ruang disk sing dibutuhake kanggo nampung basis data sing digawe dikira-kira. Usaha kanggo nyilikake.
Keputusan sing digawe babagan masalah ing ndhuwur didokumentasikan.
4. Pangembangan strategi perlindungan basis data. Basis data minangka sumber daya perusahaan sing terkenal, lan akeh perhatian sing dibayar kanggo proteksi kasebut. Kanggo nindakake iki, desainer kudu duwe pemahaman sing lengkap lan jelas babagan kabeh proteksi sing diwenehake dening DBMS sing dipilih.
5. Organisasi monitoring fungsi database lan imbuhan sawijining. Sawise nggawe proyek fisik database, pemantauan terus-terusan fungsine diatur. Informasi asil babagan tingkat kinerja database digunakake kanggo nyetel. Kanggo iki, sarana DBMS sing dipilih uga melu.
Kaputusan kanggo nggawe owah-owahan ing basis data sing bisa digunakake kudu dianggep lan ditimbang kanthi teliti.
GO TO FULL VERSION