Apa itu Physical Model?

                               

 PHYSICAL MODEL

                               Pemodelan data adalah tindakan mengeksplorasi struktur berorientasi data. Seperti artefak pemodelan lainnya, model data dapat digunakan untuk berbagai tujuan, dari model konseptual tingkat tinggi hingga model data fisik (PDM). Pemodelan data fisik secara konseptual mirip dengan pemodelan kelas desain, tujuannya adalah untuk merancang skema internal database, menggambarkan tabel data, kolom data tabel tersebut, dan hubungan antara tabel.
Gambar 1 menyajikan sebagian PDM untuk universitas - Anda tahu bahwa itu tidak lengkap dengan fakta bahwa tabel Seminar menyertakan kunci asing ke tabel yang tidak ditampilkan, dan terus terang jelas bahwa banyak konsep domain seperti kursus dan profesor jelas tidak dimodelkan. Semua kecuali satu kotak mewakili tabel, satu-satunya pengecualian adalah UniversityDB yang mencantumkan prosedur tersimpan yang diterapkan dalam database. Karena diagram diberi Model Data Fisik stereotip Anda tahu bahwa kotak kelas mewakili tabel, tanpa diagram stereotip saya akan perlu menggunakan Tabel stereotip di setiap tabel. Hubungan antara tabel dimodelkan menggunakan notasi UML standar, meskipun tidak ditunjukkan dalam contoh itu akan masuk akal untuk komposisi model dan hubungan warisan antara tabel. Hubungan diimplementasikan melalui penggunaan kunci (lebih lanjut tentang ini di bawah).

Gambar 1 . Sebagian PDM untuk universitas.

Saat Anda memodelkan data fisik, tugas-tugas berikut dilakukan secara berulang:

• Identifikasi tabel . Tabel adalah database yang setara dengan kelas; data disimpan dalam tabel fisik. Seperti yang Anda lihat pada Gambar 1 , universitas memiliki tabel Siswa untuk menyimpan data siswa, tabel Kursus untuk menyimpan data kursus, dan sebagainya. Gambar 1 menggunakan notasi berbasis UML ( ini adalah profil yang didefinisikan secara publik di mana siapa pun dapat memberikan masukan ke dalamnya). Jika Anda memiliki model kelas di tempat awal yang baik adalah melakukan pemetaan satu-ke-satu dari kelas Anda ke tabel data, sebuah pendekatan yang bekerja dengan baik di lingkungan "greenfield" di mana Anda memiliki kemewahan merancang skema basis data Anda dari awal. . Karena ini jarang terjadi dalam praktiknya, Anda perlu dipersiapkan untuk dibatasi oleh satu atau lebih skema basis data warisan yang kemudian harus Anda petakan untuk kelas Anda. Dalam situasi ini sepertinya Anda tidak perlu melakukan banyak pemodelan data, Anda hanya perlu belajar untuk hidup dengan sumber data yang ada, tetapi Anda harus dapat membaca dan memahami model yang ada. Dalam beberapa kasus Anda mungkin perlu melakukan analisis data lama dan memodelkan skema yang ada sebelum Anda dapat mulai bekerja dengannya.
• Normalisasi tabel . Normalisasi data adalah proses di mana atribut data dalam model data disusun untuk meningkatkan kohesi tabel dan untuk mengurangi kopling antar tabel. Tujuan mendasar adalah untuk memastikan bahwa data disimpan di satu dan hanya satu tempat. Ini merupakan pertimbangan penting bagi pengembang aplikasi karena sangat sulit untuk menyimpan objek dalam database relasional jika atribut data disimpan di beberapa tempat. Tabel pada Gambar 1 dalam bentuk normal ketiga (3NF).
• Identifikasi kolom . Kolom adalah database yang setara dengan atribut, dan setiap tabel akan memiliki satu atau lebih kolom. Sebagai contoh, tabel Student memiliki atribut seperti FirstName dan StudentNumber . Tidak seperti atribut di kelas, yang bisa berupa tipe primitif atau objek lain, kolom mungkin hanya tipe primitif seperti char (string), int (integer), atau float.
• Identifikasi prosedur yang tersimpan . Prosedur tersimpan secara konseptual mirip dengan metode global yang diterapkan oleh database. Pada Gambar 1 Anda melihat bahwa prosedur tersimpan seperti averageMark () dan studentsEnrolled () dimodelkan sebagai operasi kelas UniversityDB . Prosedur tersimpan ini menerapkan kode yang berfungsi dengan data yang disimpan dalam database, dalam hal ini mereka menghitung nilai rata-rata siswa dan menghitung jumlah siswa yang terdaftar dalam seminar yang diberikan masing-masing. Meskipun beberapa dari prosedur yang tersimpan ini jelas bertindak atas data yang terkandung dalam satu tabel, mereka tidak dimodelkan sebagai bagian dari tabel (sepanjang garis metode menjadi bagian dari kelas). Alih-alih, karena prosedur tersimpan adalah bagian dari keseluruhan database dan bukan satu tabel, mereka dimodelkan sebagai bagian dari kelas dengan nama database.
• Terapkan konvensi penamaan . Organisasi Anda harus memiliki standar dan pedoman yang berlaku untuk pemodelan data, dan jika tidak, Anda harus melobi untuk menerapkannya. Seperti biasa, Anda harus mengikuti praktik AM tentang Menerapkan Standar Modeling .
• Identifikasi hubungan . Ada hubungan antar tabel seperti halnya ada hubungan antar kelas. Saran yang disajikan hubungan dalam diagram kelas UML berlaku.
• Terapkan pola model data . Beberapa pemodel data akan menerapkan pola model data umum, buku David Model's Patterns Data adalah referensi terbaik pada subjek. Pola model data secara konseptual paling dekat dengan pola analisis karena mereka menggambarkan solusi untuk masalah domain umum. Buku Hay adalah referensi yang sangat bagus untuk siapa pun yang terlibat dalam pemodelan tingkat analisis, bahkan ketika Anda mengambil pendekatan objek daripada pendekatan data karena polanya memodelkan struktur bisnis dari berbagai domain bisnis.
• Tetapkan kunci . Kunci adalah satu atau lebih atribut data yang secara unik mengidentifikasi baris dalam sebuah tabel. Kunci yang dua atribut atau lebih disebut kunci komposit. Kunci utama adalah kunci pilihan untuk tipe entitas sedangkan kunci alternatif (juga dikenal sebagai kunci sekunder) adalah cara alternatif untuk mengakses baris dalam tabel. Dalam database fisik kunci akan dibentuk dari satu atau lebih kolom tabel yang nilainya mengidentifikasi baris secara unik dalam tabel relasional. Kunci primer ditandai menggunakan <<PK>> stereotip dan kunci asing melalui <<FK>>.

Meskipun notasi yang sama digunakan, menarik untuk mencatat perbedaan antara PDM Gambar 21 dan diagram kelas UML yang darinya berbasis:

1. Kunci . Di mana merupakan praktik umum untuk tidak memodelkan properti perancah pada model kelas, biasanya kunci model (data setara dengan perancah).
2. Visibilitas . Visibilitas tidak dimodelkan untuk kolom karena semuanya publik. Namun, karena sebagian besar database mendukung hak kontrol akses, Anda mungkin ingin memodelkannya menggunakan batasan UML, catatan UML, atau sebagai aturan bisnis . Prosedur yang disimpan juga bersifat publik sehingga tidak dimodelkan.
3. Tidak ada asosiasi banyak-ke-banyak . Database relasional tidak dapat mendukung banyak asosiasi secara native, tidak seperti objek, dan sebagai hasilnya Anda harus menyelesaikannya melalui penambahan tabel asosiatif. Hal terdekat dengan tabel asosiatif di adalah WaitList yang diperkenalkan untuk menyelesaikan daftar tunggu banyak-ke-banyak yang digambarkan dalam diagram kelas . Tabel asosiatif murni terdiri dari kolom kunci utama dari dua tabel yang mempertahankan hubungan antara, dalam hal ini StudentNumber dari Student dan SeminarOID dari Seminar . Perhatikan bagaimana dalam WaitList , kolom-kolom ini memiliki stereotip PK dan FK karena mereka membuat kunci utama dari WaitList sementara pada saat yang sama adalah kunci asing ke dua tabel lainnya. WaitList bukan benar-benar tabel asosiatif karena berisi kolom non-kunci, dalam hal ini kolom Tambah yang digunakan untuk memastikan bahwa orang pertama dalam daftar tunggu adalah orang-orang yang diberi kesempatan untuk mendaftar jika kursi tersedia . Seandainya WaitList menjadi tabel asosiatif murni saya akan menerapkan stereotip tabel asosiatif untuk itu.

Sumber

Deskripsi artefak ini dikutip dari Bab 12 dari Object Primer Edisi ke-3: Pengembangan Agile Model Driven dengan UML 2 .