(Database Systems A Practical Approach To Design Implementation and Management) (Sixth Edition) (Thomas Connolly) (Carolyn Begg) (0377-0434) en Id [PDF]

Citation preview

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.com



1



1



terjaditer



C



Analisis Database dan



Rumah impianStudi kasus Tujuan Bab Dalam bab ini Anda akan belajar: • Ketika teknik pencarian fakta digunakan dalam siklus hidup pengembangan sistem basis data.



• Jenis fakta yang dikumpulkan di setiap tahap siklus hidup pengembangan sistem basis data.



• Jenis dokumentasi yang dihasilkan di setiap tahap siklus hidup pengembangan sistem basis data. • Teknik pencarian fakta yang paling umum digunakan. • Bagaimana menggunakan masing-masing teknik pencarian fakta dan kelebihan dan kekurangan masing-masing.



• Tentang perusahaan persewaan properti bernamaRumah impian.



• Bagaimana menerapkan teknik pencarian fakta ke tahap awal siklus hidup pengembangan sistem basis data.



Dalam Bab 10 kami memperkenalkan tahapan siklus hidup pengembangan sistem basis data. Ada banyak kesempatan selama ini ketika sangat penting bahwa pengembang basis data menangkap fakta yang diperlukan untuk membangun sistem basis data yang diperlukan. Fakta-fakta yang diperlukan termasuk, misalnya, terminologi yang digunakan dalam perusahaan, masalah yang dihadapi dengan menggunakan sistem saat ini, peluang yang dicari dari sistem baru, batasan yang diperlukan pada data dan pengguna sistem baru, dan serangkaian kebutuhan yang diprioritaskan untuk sistem baru. sistem. Fakta-fakta ini ditangkap dengan menggunakan teknik pencarian fakta.



Pencarian fakta



Proses formal menggunakan teknik seperti wawancara dan kuesioner untuk mengumpulkan fakta tentang sistem, persyaratan, dan preferensi.



Dalam bab ini kita membahas kapan pengembang database mungkin menggunakan teknik pencarian fakta dan jenis fakta apa yang harus ditangkap. Kami menyajikan ikhtisar tentang bagaimana fakta-fakta ini digunakan untuk menghasilkan jenis dokumentasi utama yang digunakan selama siklus hidup pengembangan sistem basis data. Kami menjelaskan teknik pencarian fakta yang paling umum digunakan dan mengidentifikasi kelebihan dan kekurangannya



375



|



376



Bab 11Analisis Database danRumah impianStudi kasus setiap. Kami akhirnya mendemonstrasikan bagaimana beberapa teknik ini dapat digunakan selama tahap awal siklus hidup pengembangan sistem database menggunakan perusahaan manajemen properti bernamaRumah impian.ItuRumah impianstudi kasus digunakan di seluruh buku ini.



Struktur Bab iniDi Bagian 11.1 kita membahas kapan pengembang database mungkin menggunakan teknik pencarian fakta. (Di seluruh buku ini kami menggunakan istilah "pengembang basis data" untuk merujuk pada seseorang atau sekelompok orang yang bertanggung jawab atas analisis, desain, dan implementasi sistem basis data.) Di Bagian 11.2 kami mengilustrasikan jenis fakta yang harus dikumpulkan dan dokumentasi yang harus dihasilkan pada setiap tahap siklus hidup pengembangan sistem basis data. Di Bagian 11.3 kami menjelaskan lima teknik pencarian fakta yang paling umum digunakan dan mengidentifikasi keuntungan dan kerugian masing-masing. Pada Bagian 11.4 kami mendemonstrasikan bagaimana teknik pencarian fakta dapat digunakan untuk mengembangkan sistem basis data untuk studi kasus yang disebutRumah impian,sebuah perusahaan manajemen properti. Kami memulai bagian ini dengan memberikan gambaran tentang Rumah impianstudi kasus. Kami kemudian memeriksa tiga tahap pertama dari siklus hidup pengembangan sistem basis data, yaitu perencanaan basis data, definisi sistem, dan pengumpulan dan analisis kebutuhan. Untuk setiap tahapan kami mendemonstrasikan proses pengumpulan data dengan menggunakan teknik pencarian fakta dan mendeskripsikan dokumentasi yang dihasilkan.



11.1Kapan Teknik Pencarian Fakta Digunakan? Ada banyak kesempatan untuk pencarian fakta selama siklus hidup pengembangan sistem database. Namun, pencarian fakta sangat penting untuk tahap awal siklus hidup, termasuk perencanaan basis data, definisi sistem, dan tahap pengumpulan dan analisis persyaratan. Selama tahap awal inilah pengembang basis data menangkap fakta-fakta penting yang diperlukan untuk membangun basis data yang diperlukan. Pencarian fakta juga digunakan selama desain database dan tahap selanjutnya dari siklus hidup, tetapi pada tingkat yang lebih rendah. Misalnya, selama desain basis data fisik, pencarian fakta menjadi teknis karena pengembang basis data mencoba mempelajari lebih lanjut tentang DBMS yang dipilih untuk sistem basis data. Juga, selama tahap akhir, pemeliharaan operasional, Perhatikan bahwa penting untuk memiliki perkiraan kasar tentang berapa banyak waktu dan upaya yang akan dihabiskan untuk pencarian fakta untuk proyek database. Seperti yang kami sebutkan di Bab 10, terlalu banyak belajar terlalu cepat menyebabkankelumpuhan dengan analisis.Namun, terlalu sedikit pemikiran dapat mengakibatkan pemborosan waktu dan uang yang tidak perlu, karena mengerjakan solusi yang salah untuk masalah yang salah.



11.2Fakta Apa yang Dikumpulkan?



|377



11.2Fakta Apa yang Dikumpulkan? Sepanjang siklus hidup pengembangan sistem basis data, pengembang basis data perlu menangkap fakta tentang sistem saat ini dan/atau masa depan. Tabel 11.1 memberikan contoh jenis data yang diambil dan dokumentasi yang dihasilkan untuk setiap tahap siklus hidup. Seperti yang kami sebutkan di Bab 10, tahapan siklus hidup pengembangan sistem basis data tidak sepenuhnya berurutan, tetapi melibatkan sejumlah pengulangan dari tahapan sebelumnya melalui putaran umpan balik. Ini juga berlaku untuk data yang diambil dan dokumentasi yang dihasilkan pada setiap tahap. Misalnya, masalah yang dihadapi selama desain database mungkin memerlukan pengambilan data tambahan pada persyaratan untuk sistem baru.



Tabel 11.1Contoh data yang diambil dan dokumentasi yang dihasilkan untuk setiap tahap siklus hidup pengembangan sistem basis data. TAHAP DATABASE Pengembangan sistem



CONTOH DATA TANGKAP



CONTOH PRODUK DOKUMENTASI



Perencanaan basis data



Maksud dan tujuan proyek database



Pernyataan misi dan tujuan dari sistem basis data



Definisi sistem



Deskripsi tampilan pengguna utama



Definisi ruang lingkup dan batasan sistem



(termasuk peran pekerjaan atau bidang



basis data; definisi tampilan pengguna yang



aplikasi bisnis)



akan didukung



Persyaratan untuk tampilan pengguna; spesifikasi sistem, termasuk persyaratan kinerja dan keamanan



Spesifikasi kebutuhan pengguna dan sistem



Tanggapan pengguna untuk memeriksa desain



Desain basis data konseptual/logis (termasuk model ER, kamus data, dan skema relasional); desain basis data fisik



lingkaran kehidupan



Pengumpulan dan analisis kebutuhan



Desain basis data



database konseptual/logis; fungsionalitas yang disediakan oleh DBMS target



Desain aplikasi



antarmuka



Desain aplikasi (termasuk deskripsi program dan antarmuka pengguna)



pemilihan DBMS



Fungsi yang disediakan oleh DBMS target



evaluasi dan rekomendasi DBMS



Pembuatan prototipe



Tanggapan pengguna terhadap prototipe



Persyaratan pengguna yang dimodifikasi dan



Tanggapan pengguna untuk memeriksa desain



spesifikasi sistem



Penerapan



Fungsi yang disediakan oleh DBMS target



Konversi dan pemuatan data



Format data saat ini; kemampuan impor data DBMS target



Pengujian



Hasil tes



Strategi pengujian yang digunakan; analisis hasil tes



Pemeliharaan operasional



Hasil pengujian kinerja; kebutuhan pengguna dan sistem yang baru atau berubah



Panduan pengguna; analisis hasil kinerja; kebutuhan pengguna yang dimodifikasi dan spesifikasi sistem



|



378



Bab 11Analisis Database danRumah impianStudi kasus



11.3Teknik Pencarian Fakta Pengembang basis data biasanya menggunakan beberapa teknik pencarian fakta selama satu proyek basis data. Ada lima teknik pencarian fakta yang umum digunakan: • memeriksa dokumentasi; • wawancara; • mengamati perusahaan yang beroperasi; • riset; • kuesioner. Pada bagian berikut kami menjelaskan teknik pencarian fakta ini dan mengidentifikasi keuntungan dan kerugian masing-masing.



11.3.1 Memeriksa Dokumentasi Memeriksa dokumentasi dapat bermanfaat ketika kita mencoba untuk mendapatkan beberapa wawasan tentang bagaimana kebutuhan akan database muncul. Kami juga dapat menemukan bahwa dokumentasi dapat membantu memberikan informasi tentang bagian perusahaan yang terkait dengan masalah tersebut. Jika masalah terkait dengan sistem saat ini, harus ada dokumentasi yang terkait dengan sistem tersebut. Dengan memeriksa dokumen, formulir, laporan, dan file yang terkait dengan sistem saat ini, kita dapat dengan cepat memahami sistem tersebut. Contoh jenis dokumentasi yang harus diperiksa tercantum dalam Tabel 11.2.



11.3.2 Wawancara Wawancara adalah teknik pencarian fakta yang paling umum digunakan dan biasanya paling berguna. Kita dapat mewawancarai untuk mengumpulkan informasi dari individu secara tatap muka. Ada beberapa tujuan untuk menggunakan wawancara, seperti mencari tahu



Tabel 11.2Contoh jenis dokumentasi yang harus diperiksa. tujuan dari Dokumentasi



CONTOH SUMBER BERMANFAAT



Menjelaskan masalah dan



Memo internal, email, dan risalah rapat



kebutuhan basis data



Keluhan karyawan dan dokumen yang menjelaskan masalah Media sosial seperti blog dan tweet



Tinjauan/laporan kinerja yang dipengaruhi oleh



Bagan organisasi, pernyataan misi, dan rencana strategis perusahaan



masalah



Tujuan untuk bagian dari perusahaan yang sedang dipelajari



Menjelaskan bagian dari perusahaan



Uraian tugas/pekerjaan



Contoh formulir dan laporan manual yang sudah diisi Contoh formulir dan laporan terkomputerisasi yang telah diisi Menjelaskan sistem saat ini



Berbagai jenis diagram alur dan diagram Kamus data Desain sistem basis data



dokumentasi program Manual pengguna/pelatihan



|379



11.3Teknik Pencarian Fakta Tabel 11.3Keuntungan dan kerugian menggunakan wawancara sebagai teknik pencarian fakta.



Keuntungan



KERUGIAN



Mengizinkan orang yang diwawancarai untuk menanggapi



Sangat memakan waktu dan mahal, dan



pertanyaan secara bebas dan terbuka



karena itu mungkin tidak praktis



Memungkinkan orang yang diwawancarai merasa menjadi bagian dari proyek



Kesuksesan tergantung pada keterampilan komunikasi pewawancara



Memungkinkan pewawancara untuk menindaklanjuti komentar menarik



Keberhasilan dapat bergantung pada kesediaan orang yang



yang dibuat oleh orang yang diwawancarai



diwawancarai untuk berpartisipasi dalam wawancara



Memungkinkan pewawancara untuk mengadaptasi atau menulis ulang pertanyaan selama wawancara Memungkinkan pewawancara untuk mengamati bahasa tubuh orang yang diwawancarai



fakta, memverifikasi fakta, mengklarifikasi fakta, membangkitkan antusiasme, melibatkan pengguna akhir, mengidentifikasi persyaratan, dan mengumpulkan ide dan opini. Namun, menggunakan teknik wawancara membutuhkan keterampilan komunikasi yang baik untuk menangani orang-orang yang memiliki nilai, prioritas, pendapat, motivasi, dan kepribadian yang berbeda secara efektif. Seperti teknik pencarian fakta lainnya, wawancara tidak selalu merupakan metode terbaik untuk semua situasi. Keuntungan dan kerugian menggunakan wawancara sebagai teknik pencarian fakta tercantum dalam Tabel 11.3. Ada dua jenis wawancara: tidak terstruktur dan terstruktur.Wawancara tidak terstruktur dilakukan hanya dengan tujuan umum dan dengan sedikit, jika ada, pertanyaan khusus. Pewawancara mengandalkan orang yang diwawancarai untuk memberikan kerangka kerja dan arahan untuk wawancara. Jenis wawancara ini sering kehilangan fokus dan, karena alasan ini, seringkali tidak bekerja dengan baik untuk analisis dan desain database. Di dalamwawancara terstruktur, pewawancara memiliki serangkaian pertanyaan khusus untuk ditanyakan kepada orang yang diwawancarai. Bergantung pada tanggapan orang yang diwawancarai, pewawancara akan mengarahkan pertanyaan tambahan untuk mendapatkan klarifikasi atau perluasan. Pertanyaan terbuka memungkinkan orang yang diwawancarai untuk menanggapi dengan cara apa pun yang tampaknya tepat. Contoh pertanyaan terbuka adalah: "Mengapa Anda tidak puas dengan laporan pendaftaran klien?"Pertanyaan tertutupbatasi jawaban untuk pilihan tertentu atau tanggapan singkat dan langsung. Contoh dari pertanyaan seperti itu mungkin: "Apakah Anda menerima laporan pendaftaran klien tepat waktu?" atau “Apakah laporan pendaftaran klien berisi informasi yang akurat?” Kedua pertanyaan tersebut hanya membutuhkan jawaban “Ya” atau “Tidak”.



Untuk memastikan wawancara yang sukses termasuk memilih individu yang tepat untuk diwawancarai, mempersiapkan wawancara secara ekstensif, dan melakukan wawancara dengan cara yang efisien dan efektif.



11.3.3 Mengamati Perusahaan dalam Operasi Pengamatan adalah salah satu teknik pencarian fakta yang paling efektif untuk memahami suatu sistem. Dengan teknik ini, dimungkinkan untuk berpartisipasi atau menonton seseorang melakukan aktivitas untuk mempelajari sistem. Teknik ini sangat berguna ketika validitas data yang dikumpulkan melalui metode lain dipertanyakan atau ketika kompleksitas aspek tertentu dari sistem mencegah penjelasan yang jelas dari pengguna akhir.



|



380



Bab 11Analisis Database danRumah impianStudi kasus Tabel 11.4Keuntungan dan kerugian menggunakan observasi sebagai teknik pencarian fakta.



Keuntungan



KERUGIAN



Memungkinkan validitas fakta dan data untuk diperiksa



Orang mungkin secara sadar atau tidak sadar tampil berbeda saat diamati



Pengamat dapat melihat dengan tepat apa yang sedang



Mungkin melewatkan tugas mengamati yang melibatkan



dilakukan



berbagai tingkat kesulitan atau volume yang biasanya dialami selama periode waktu tersebut



menggambarkan lingkungan fisik tugas



Beberapa tugas mungkin tidak selalu dilakukan dengan cara yang diamati



Relatif tidak mahal



Mungkin tidak praktis



Pengamat juga dapat memperoleh data yang



Pengamat dapat melakukan pengukuran kerja



Seperti halnya teknik pencarian fakta lainnya, observasi yang sukses membutuhkan persiapan. Untuk memastikan bahwa pengamatan berhasil, penting untuk mengetahui sebanyak mungkin tentang individu dan aktivitas yang akan diamati. Misalnya, "Kapan periode rendah, normal, dan puncak aktivitas diamati?" dan “Apakah orang-orang tersebut akan kecewa dengan meminta seseorang menonton dan merekam tindakan mereka?” Keuntungan dan kerugian menggunakan observasi sebagai teknik pencarian fakta tercantum dalam Tabel 11.4.



11.3.4 Penelitian Teknik pencarian fakta yang berguna adalah meneliti aplikasi dan masalah. Jurnal perdagangan komputer, buku referensi, dan Internet (termasuk kelompok pengguna dan papan buletin) adalah sumber informasi yang baik. Mereka dapat memberikan informasi tentang bagaimana orang lain memecahkan masalah serupa, ditambah apakah ada paket perangkat lunak untuk memecahkan atau bahkan menyelesaikan sebagian masalah. Keuntungan dan kerugian menggunakan penelitian sebagai teknik pencarian fakta tercantum dalam Tabel 11.5.



11.3.5 Kuesioner Teknik pencarian fakta lainnya adalah dengan melakukan survei melalui kuesioner. Kuesioner adalah dokumen dengan tujuan khusus yang memungkinkan fakta dikumpulkan dari sejumlah besar orang sambil mempertahankan kendali atas tanggapan mereka.



Tabel 11.5Keuntungan dan kerugian menggunakan penelitian sebagai teknik pencarian fakta.



Keuntungan



KERUGIAN



Dapat menghemat waktu jika solusi sudah ada



Membutuhkan akses ke sumber informasi yang tepat



Peneliti dapat melihat bagaimana orang lain memecahkan



Mungkin pada akhirnya tidak membantu dalam memecahkan



masalah serupa atau memenuhi persyaratan serupa



masalah karena masalah tidak didokumentasikan di tempat lain



Membuat peneliti tetap up to date dengan perkembangan saat ini



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil Tabel 11.6Keuntungan dan kerugian menggunakan kuesioner sebagai teknik pencarian fakta. Keuntungan



KERUGIAN



Orang-orang dapat mengisi dan mengembalikan kuesioner sesuai keinginan mereka



Jumlah responden bisa rendah, mungkin hanya 5% sampai 10%



Cara yang relatif murah untuk mengumpulkan



Kuesioner dapat dikembalikan tidak lengkap



data dari sejumlah besar orang Orang lebih cenderung memberikan fakta



Tidak boleh memberikan kesempatan untuk mengadaptasi atau



sebenarnya karena tanggapan dapat disimpan



menyusun ulang pertanyaan yang telah ada



rahasia



disalahtafsirkan



Tanggapan dapat ditabulasikan dan dianalisis dengan



Tidak dapat mengamati dan menganalisis bahasa



cepat



tubuh responden



Saat berhadapan dengan audiens yang besar, tidak ada teknik pencarian fakta lain yang dapat mentabulasikan fakta yang sama secara efisien. Keuntungan dan kerugian menggunakan kuesioner sebagai teknik pencarian fakta tercantum dalam Tabel 11.6. Ada dua jenis pertanyaan yang dapat ditanyakan dalam kuesioner: format bebas dan format tetap. Pertanyaan format bebasmemberikan kebebasan yang lebih besar kepada responden dalam memberikan jawaban. Sebuah pertanyaan diajukan dan responden mencatat jawabannya di tempat yang disediakan setelah pertanyaan. Contoh pertanyaan format bebas adalah: "Laporan apa yang Anda terima saat ini dan bagaimana laporan itu digunakan?" dan “Apakah ada masalah dengan laporan ini? Jika demikian, tolong jelaskan.” Masalah dengan pertanyaan format bebas adalah bahwa jawaban responden mungkin terbukti sulit untuk ditabulasikan, dan dalam beberapa kasus, mungkin tidak sesuai dengan pertanyaan yang diajukan.



Pertanyaan dengan format tetapmemerlukan tanggapan khusus dari individu. Diberi pertanyaan apa pun, responden harus memilih dari jawaban yang tersedia. Ini membuat hasil lebih mudah untuk ditabulasikan. Di sisi lain, responden tidak dapat memberikan informasi tambahan yang mungkin terbukti berharga. Contoh pertanyaan dengan format tetap adalah: “Format laporan sewa properti saat ini sudah ideal dan tidak boleh diubah.” Responden dapat diberikan pilihan untuk menjawab “Ya” atau “Tidak” untuk pertanyaan ini, atau diberikan pilihan untuk menjawab dari berbagai tanggapan termasuk “Sangat setuju”, “Setuju”, “Tidak ada pendapat”, “Tidak setuju, ” dan “Sangat tidak setuju.”



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil Pada bagian ini pertama-tama kami menyajikan gambaran umum tentangRumah impianstudi kasus dan kemudian gunakan studi kasus ini untuk mengilustrasikan bagaimana membuat proyek database. Secara khusus, kami mengilustrasikan bagaimana teknik pencarian fakta dapat digunakan dan dokumentasi dihasilkan pada tahap awal siklus hidup pengembangan sistem database yaitu, perencanaan database, definisi sistem, dan tahap pengumpulan dan analisis kebutuhan.



|381



|



382



Bab 11Analisis Database danRumah impianStudi kasus



11.4.1Rumah impianStudi Kasus—Ikhtisar Sistem Saat Ini Kantor cabang pertama dariRumah impiandibuka pada tahun 1992 di Glasgow di Inggris. Sejak itu, Perusahaan terus berkembang dan sekarang memiliki beberapa kantor di sebagian besar kota utama di Inggris. Namun, Perusahaan sekarang begitu besar sehingga semakin banyak staf administrasi dipekerjakan untuk menangani jumlah dokumen yang terus meningkat. Selain itu, komunikasi dan berbagi informasi antar kantor, bahkan di kota yang sama, masih buruk. Direktur Perusahaan, Sally Mellweadows, merasa bahwa terlalu banyak kesalahan yang dibuat dan kesuksesan Perusahaan akan berumur pendek jika dia tidak melakukan sesuatu untuk memperbaiki situasi tersebut. Dia tahu bahwa database dapat membantu sebagian untuk memecahkan masalah dan telah meminta agar sistem database dikembangkan untuk mendukung jalannyaRumah impian.Direktur telah memberikan gambaran singkat tentang bagaimana Rumah impiansaat ini beroperasi. Rumah impianmengkhususkan diri dalam manajemen properti, mengambil peran perantara antara pemilik yang ingin menyewakan properti berperabotan mereka dan klien dari Rumah impianyang membutuhkan untuk menyewa properti berperabot untuk jangka waktu tertentu.Rumah impian saat ini memiliki sekitar 2000 staf yang bekerja di 100 cabang. Ketika seorang anggota staf bergabung dengan Perusahaan,Rumah impianformulir pendaftaran staf digunakan. Formulir pendaftaran staf untuk Susan Brand ditunjukkan pada Gambar 11.1.



Setiap cabang memiliki jumlah dan jenis staf yang sesuai termasuk Manajer, Supervisor, dan Asisten. Manajer bertanggung jawab untuk menjalankan cabang sehari-hari dan setiap Supervisor bertanggung jawab untuk mengawasi sekelompok staf yang disebut Asisten. Contoh halaman pertama dari laporan daftar rincian staf yang bekerja di kantor cabang di Glasgow ditunjukkan pada Gambar 11.2.



Gambar 11.1ItuRumah impianformulir pendaftaran staf untuk Susan Brand.



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil



Gambar 11.2Contoh halaman pertama laporan yang mencantumkan detail staf yang bekerja di a



Rumah impiankantor cabang di Glasgow.



Setiap kantor cabang menawarkan berbagai properti untuk disewakan. Untuk menawarkan properti melaluiRumah impian, pemilik properti biasanya menghubungiRumah impiankantor cabang terdekat dengan properti yang disewakan. Pemilik memberikan perincian properti dan menyetujui sewa yang sesuai untuk properti tersebut dengan Manajer cabang. Formulir pendaftaran properti di Glasgow ditunjukkan pada Gambar 11.3.



Setelah properti terdaftar,Rumah impianmenyediakan layanan untuk memastikan bahwa properti disewakan untuk pengembalian maksimum bagi pemilik properti dan, tentu saja, Rumah impian.Layanan ini termasuk mewawancarai calon penyewa (disebut klien), mengatur tampilan properti oleh klien, mengiklankan properti di surat kabar lokal atau nasional (bila perlu), dan menegosiasikan sewa. Sekali disewa, Rumah impian bertanggung jawab atas properti termasuk koleksi sewa. Anggota masyarakat yang tertarik untuk menyewakan properti harus terlebih dahulu menghubungi terdekat merekaRumah impiankantor cabang untuk mendaftar sebagai klien dari



Rumah impian.Namun, sebelum pendaftaran diterima, calon klien biasanya diwawancarai untuk mencatat detail pribadi dan preferensi klien dalam hal persyaratan properti. Formulir pendaftaran untuk klien bernama Mike Ritchie ditunjukkan pada Gambar 11.4. Setelah pendaftaran selesai, klien diberikan laporan mingguan yang mencantumkan properti yang saat ini tersedia untuk disewa. Contoh halaman pertama laporan daftar properti yang tersedia untuk disewa di kantor cabang di Glasgow ditunjukkan pada Gambar 11.5.



Klien dapat meminta untuk melihat satu atau lebih properti dari daftar dan setelah melihat biasanya akan memberikan komentar tentang kesesuaian properti tersebut. Halaman pertama laporan yang menjelaskan komentar yang dibuat oleh klien tentang properti di Glasgow ditunjukkan pada Gambar 11.6. Properti yang terbukti sulit untuk disewakan biasanya diiklankan di surat kabar lokal dan nasional.



|383



|



384



Bab 11Analisis Database danRumah impianStudi kasus



Gambar 11.3ItuRumah impianformulir pendaftaran properti untuk properti di Glasgow.



Gambar 11.4ItuRumah impianformulir pendaftaran klien untuk Mike Ritchie.



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil



3



Gambar 11.5Halaman pertama dariRumah impianproperti untuk disewakan laporan daftar properti yang tersedia di cabang di Glasgow.



Gambar 11.6Halaman pertama dariRumah impianlaporan melihat properti untukAproperti di Glasgow.



|385



|



386



Bab 11Analisis Database danRumah impianStudi kasus



Gambar 11.7ItuRumah impianformulir sewa untuk klien bernama Mike Ritchie yang menyewa properti di Glasgow.



Setelah klien mengidentifikasi properti yang sesuai, anggota staf membuat kontrak sewa. Sewa antara klien bernama Mike Ritchie dan properti di Glasgow ditunjukkan pada Gambar 11.7.



Di akhir periode sewa, klien dapat meminta agar sewa dilanjutkan; namun, hal ini mengharuskan dibuatnya sewa baru. Alternatifnya, klien dapat meminta untuk melihat properti alternatif untuk keperluan sewa.



11.4.2Rumah impianStudi Kasus—Perencanaan Database Langkah pertama dalam mengembangkan sistem basis data adalah mendefinisikan dengan jelas pernyataan misiuntuk proyek database, yang mendefinisikan tujuan utama dari sistem database. Setelah pernyataan misi didefinisikan, kegiatan selanjutnya melibatkan mengidentifikasi tujuan misi, yang harus mengidentifikasi tugas-tugas tertentu yang harus didukung database (lihat Bagian 10.3).



Membuat pernyataan misi untukRumah impiansistem basis data Kami memulai proses pembuatan pernyataan misi untukRumah impiansistem database dengan melakukan wawancara dengan Direktur dan staf lain yang sesuai, sebagaimana ditunjukkan oleh Direktur. Pertanyaan terbuka biasanya yang paling berguna pada tahap proses ini. Contoh pertanyaan umum yang mungkin kami ajukan meliputi:



“Apa tujuan perusahaan Anda?” “Mengapa Anda merasa membutuhkan database?” “Bagaimana Anda tahu bahwa database akan menyelesaikan masalah Anda?”



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil Misalnya, pengembang basis data dapat memulai wawancara dengan bertanya kepada DirekturRumah



impianpertanyaan-pertanyaan berikut: Pengembang Basis Data:



Apa tujuan perusahaan Anda?



Direktur:



Kami menawarkan berbagai properti berkualitas tinggi untuk disewakan kepada klien yang terdaftar di cabang kami di seluruh Inggris. Kemampuan kami untuk menawarkan properti berkualitas, tentu saja, bergantung pada layanan yang kami berikan kepada pemilik properti. Kami memberikan layanan yang sangat profesional kepada pemilik properti untuk memastikan bahwa properti disewakan untuk pengembalian maksimum.



Pengembang Basis Data:



Mengapa Anda merasa membutuhkan database?



Direktur:



Sejujurnya, kita tidak bisa mengatasi kesuksesan kita sendiri. Selama beberapa tahun terakhir kami telah membuka beberapa cabang di sebagian besar kota utama di Inggris, dan di setiap cabang kami sekarang menawarkan lebih banyak pilihan properti untuk semakin banyak klien. Namun, keberhasilan ini dibarengi dengan meningkatnya masalah pengelolaan data, yang berarti tingkat layanan yang kami berikan menurun. Juga, kurangnya kerjasama dan berbagi informasi antar cabang, yang merupakan perkembangan yang sangat mengkhawatirkan.



Pengembang Basis Data:



Bagaimana Anda tahu bahwa database akan menyelesaikan masalah Anda?



Direktur:



Yang saya tahu adalah bahwa kita tenggelam dalam dokumen. Kami membutuhkan sesuatu yang akan mempercepat cara kami bekerja dengan mengotomatiskan banyak tugas sehari-hari yang tampaknya memakan waktu lama akhir-akhir ini. Juga, saya ingin cabang-cabang mulai bekerja sama. Database akan membantu mencapai hal ini, bukan?



Tanggapan terhadap jenis pertanyaan ini harus membantu merumuskan pernyataan misi. Contoh pernyataan misi untukRumah impiansistem basis data ditunjukkan pada Gambar 11.8. Ketika kami memiliki pernyataan misi yang jelas dan tidak ambigu bahwa stafRumah impiansetuju dengan, kami melanjutkan untuk menentukan tujuan misi.



Membuat tujuan misi untukRumah impiansistem basis data Proses menciptakan tujuan misi melibatkan melakukan wawancara dengan anggota staf yang tepat. Sekali lagi, pertanyaan terbuka biasanya paling berguna pada tahap proses ini. Untuk mendapatkan rangkaian lengkap misi



Gambar 11.8Pernyataan misi untukRumah impiansistem basis data.



|387



|



388



Bab 11Analisis Database danRumah impianStudi kasus tujuan, kami mewawancarai berbagai anggota staf dengan peran yang berbedaRumah impian. Contoh pertanyaan umum yang mungkin kami ajukan meliputi:



"Apa deskripsi pekerjaan Anda?"



“Tugas apa yang Anda lakukan pada hari-hari biasa?” “Jenis data apa yang Anda kerjakan?” “Jenis laporan apa yang Anda gunakan?”



“Hal-hal apa saja yang perlu Anda pantau?” “Layanan apa yang diberikan perusahaan Anda kepada pelanggan Anda?” Pertanyaan-pertanyaan ini (atau yang serupa) diajukan kepada DirekturRumah impiandan anggota staf dalam peran Manajer, Supervisor, dan Asisten. Mungkin perlu menyesuaikan pertanyaan sesuai kebutuhan, tergantung pada siapa yang diwawancarai.



Direktur Pengembang Basis Data:



Peran apa yang Anda mainkan untuk perusahaan?



Direktur:



Saya mengawasi jalannya perusahaan untuk memastikan bahwa kami terus memberikan layanan sewa properti sebaik mungkin kepada klien dan pemilik properti kami.



Pengembang Basis Data:



Jenis tugas apa yang Anda lakukan di hari-hari biasa?



Direktur:



Saya memantau jalannya setiap cabang oleh Manajer kami. Saya mencoba untuk memastikan bahwa cabang bekerja sama dengan baik dan berbagi informasi penting tentang properti dan klien. Saya biasanya mencoba untuk menjaga profil tinggi dengan Manajer cabang saya dengan menelepon ke setiap cabang setidaknya sekali atau dua kali sebulan.



Pengembang Basis Data:



Jenis data apa yang Anda gunakan?



Direktur:



Saya perlu melihat semuanya, setidaknya ringkasan data yang digunakan atau dihasilkan olehRumah impian.Itu termasuk data tentang staf di semua cabang, semua properti dan pemiliknya, semua klien, dan semua sewa. Saya juga suka memantau sejauh mana cabang mengiklankan properti di surat kabar.



Pengembang Basis Data:



Jenis laporan apa yang Anda gunakan?



Direktur:



Saya perlu tahu apa yang terjadi di semua cabang dan ada banyak cabang. Saya menghabiskan banyak hari kerja saya membahas laporan panjang tentang semua aspekRumah impian.Saya memerlukan laporan yang mudah diakses dan memungkinkan saya mendapatkan gambaran umum yang baik tentang apa yang terjadi di cabang tertentu dan di semua cabang.



Pengembang Basis Data:



Jenis hal apa yang perlu Anda pantau?



Direktur:



Seperti yang saya katakan sebelumnya, saya perlu memiliki gambaran umum tentang segalanya; Saya perlu melihat keseluruhan gambar.



Pengembang Basis Data:



Layanan apa yang perusahaan Anda berikan kepada pelanggan Anda?



Direktur:



Kami bertujuan untuk memberikan layanan persewaan properti terbaik di Inggris. Saya yakin ini akan tercapai dengan dukungan sistem basis data baru, yang memungkinkan



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil staf saya untuk menangani pelanggan dan klien kami secara lebih efisien dan memasarkan properti kami dengan lebih baik melalui pengembangan yang baruRumah impianSitus web. Situs ini akan memungkinkan klien persewaan kami saat ini dan yang baru untuk melihat properti kami di Web.



Pengelola Pengembang Basis Data:



Apa deskripsi pekerjaan Anda?



Pengelola:



Jabatan saya adalah Manager. Saya mengawasi jalannya cabang saya sehari-hari untuk memberikan layanan sewa properti terbaik kepada klien dan pemilik properti kami.



Pengembang Basis Data:



Jenis tugas apa yang Anda lakukan di hari-hari biasa?



Pengelola:



Saya memastikan bahwa cabang memiliki jumlah dan jenis staf yang sesuai yang bertugas setiap saat. Saya memantau pendaftaran properti baru dan klien baru, serta aktivitas penyewaan klien aktif kami saat ini. Merupakan tanggung jawab saya untuk memastikan bahwa kami memiliki jumlah dan jenis properti yang tepat untuk ditawarkan kepada klien kami. Saya terkadang terlibat dalam negosiasi sewa untuk properti kelas atas kami, meskipun karena beban kerja saya, saya sering kali harus mendelegasikan tugas ini kepada Supervisor.



Pengembang Basis Data:



Jenis data apa yang Anda gunakan?



Pengelola:



Saya kebanyakan bekerja dengan data tentang properti yang ditawarkan di cabang saya dan pemilik, klien, dan sewa. Saya juga perlu tahu kapan properti terbukti sulit untuk disewakan sehingga saya dapat mengaturnya untuk diiklankan di surat kabar. Saya perlu mengawasi aspek bisnis ini, karena iklan bisa jadi mahal. Saya juga memerlukan akses ke data tentang staf yang bekerja di cabang saya dan staf di cabang lokal lainnya. Ini karena saya terkadang perlu menghubungi cabang lain untuk mengatur rapat manajemen atau meminjam staf dari cabang lain untuk sementara guna menutupi kekurangan staf karena sakit atau selama masa liburan. Peminjaman staf antar cabang lokal ini bersifat informal dan untungnya tidak sering terjadi. Selain data staf, akan sangat membantu untuk melihat jenis data lain di cabang lain seperti data properti, pemilik properti, klien, dan sewa, Anda tahu, untuk membandingkan catatan. Sebenarnya, saya pikir Direktur berharap proyek database ini akan membantu mempromosikan kerja sama dan berbagi informasi antar cabang. Namun, beberapa Manajer yang saya kenal tidak akan terlalu tertarik dengan hal ini, karena mereka pikir kami bersaing satu sama lain. Bagian dari masalahnya adalah bahwa persentase gaji Manajer terdiri dari bonus, yang terkait dengan jumlah properti yang kami sewakan.



|389



|



390



Bab 11Analisis Database danRumah impianStudi kasus Pengembang Basis Data:



Jenis laporan apa yang Anda gunakan?



Pengelola:



Saya memerlukan berbagai laporan tentang staf, properti, pemilik, klien, dan sewa. Sekilas saya perlu tahu properti mana yang perlu kami sewa dan apa yang dicari klien.



Pengembang Basis Data:



Jenis hal apa yang perlu Anda pantau? Saya perlu melacak gaji staf. Saya perlu tahu seberapa baik properti di buku kami disewakan dan kapan sewa akan diperbarui. Saya juga perlu mengawasi pengeluaran kami untuk iklan di surat kabar.



Pengelola:



Pengembang Basis Data:



Layanan apa yang perusahaan Anda berikan kepada pelanggan Anda?



Pengelola:



Ingatlah bahwa kami memiliki dua jenis pelanggan; yaitu, klien ingin menyewa properti dan pemilik properti. Kami perlu memastikan bahwa klien kami menemukan properti yang mereka cari dengan cepat tanpa terlalu banyak kerja keras dan dengan harga sewa yang masuk akal, dan, tentu saja, pemilik properti kami mendapatkan keuntungan yang baik dari menyewakan properti mereka dengan kerumitan minimal. Seperti yang mungkin sudah Anda ketahui dari pembicaraan dengan Direktur kami, serta dari pengembangan sistem basis data baru, kami juga bermaksud untuk mengembangkan sistem basis data baru.Rumah impianSitus web. Situs Web ini akan membantu klien kami melihat properti kami di rumah sebelum datang ke cabang kami untuk mengatur tampilan. Saya perlu memastikan bahwa tidak peduli bagaimana klien menghubungi kami— baik melalui email melalui situs Web kami, melalui telepon, atau secara langsung—bahwa mereka menerima layanan efisien yang sama untuk membantu mereka menemukan properti yang mereka cari.



Pengawas Pengembang Basis Data:



Apa deskripsi pekerjaan Anda?



Pengawas:



Jabatan saya adalah Supervisor. Saya menghabiskan sebagian besar waktu saya di kantor berhadapan langsung dengan pelanggan kami; yaitu, klien ingin menyewa properti dan pemilik properti. Saya juga bertanggung jawab atas sekelompok kecil staf yang disebut Asisten dan memastikan bahwa mereka tetap sibuk, tetapi itu bukan masalah, karena selalu ada banyak hal yang harus dilakukan— sebenarnya tidak ada habisnya.



Pengembang Basis Data:



Jenis tugas apa yang Anda lakukan di hari-hari biasa?



Pengawas:



Saya biasanya memulai hari dengan mengalokasikan staf untuk tugas-tugas tertentu, seperti berurusan dengan klien atau pemilik properti, mengatur klien untuk melihat properti, dan mengajukan dokumen. Ketika klien menemukan properti yang cocok, saya memproses pembuatan kontrak, meskipun Manajer harus melihat dokumentasi sebelum tanda tangan diminta. Saya selalu memperbarui detail klien dan mendaftarkan klien baru ketika mereka ingin bergabung dengan Perusahaan. Ketika properti baru didaftarkan,



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil Manajer mengalokasikan tanggung jawab untuk mengelola properti itu kepada saya atau salah satu Supervisor atau Asisten lainnya. Pengembang Basis Data:



Jenis data apa yang Anda gunakan?



Pengawas:



Saya bekerja dengan data tentang staf di cabang saya, properti, pemilik properti, klien, tampilan properti, dan sewa.



Pengembang Basis Data:



Jenis laporan apa yang Anda gunakan? Laporan



Pengawas:



staf dan properti untuk disewakan. Jenis hal apa



Pengembang Basis Data:



yang perlu Anda pantau?



Pengawas:



Saya perlu tahu properti apa yang tersedia untuk disewa dan kapan masa sewa aktif akan berakhir. Saya juga perlu tahu apa yang dicari klien. Saya perlu memberi tahu Manajer kami tentang properti apa pun yang terbukti sulit untuk disewakan. Saya perlu memastikan bahwa klien yang menghubungi kami melalui email yang meminta untuk melihat properti diberi tanggapan cepat dari kami dengan mengundang mereka untuk menelepon ke kantor terdekat.Rumah impiankantor cabang. Sebagai bagian dari layanan yang kami berikan kepada pemilik properti kami, kami perlu mewawancarai semua klien terlebih dahulu sebelum mereka diizinkan untuk melihat properti kami. Tidak ada yang aneh tentang hal ini, karena kami selalu mewawancarai klien kami pada kunjungan pertama mereka ke a



Rumah impiancabang, dan selama waktu inilah kami mencatat detail dan persyaratan properti mereka.



Asisten Pengembang Basis Data:



Apa deskripsi pekerjaan Anda?



Asisten:



Jabatan saya adalah Asisten. Saya berhubungan langsung dengan klien



Pengembang Basis Data:



kami. Jenis tugas apa yang Anda lakukan di hari-hari biasa?



Asisten:



Saya menjawab pertanyaan umum dari klien tentang properti yang disewakan. Anda tahu apa yang saya maksud: “Apakah Anda memiliki jenis properti ini dan itu di area tertentu di Glasgow?” Saya juga mendaftarkan klien baru dan mengatur klien untuk melihat properti. Saat kami tidak terlalu sibuk, saya mengajukan dokumen, tetapi saya benci bagian pekerjaan ini—sangat membosankan.



Pengembang Basis Data:



Jenis data apa yang Anda gunakan?



Asisten:



Saya bekerja dengan data tentang properti dan tampilan properti oleh klien dan terkadang sewa.



Pengembang Basis Data:



Jenis laporan apa yang Anda gunakan?



Asisten:



Daftar properti yang tersedia untuk disewa. Daftar ini diperbarui setiap minggu.



Pengembang Basis Data:



Jenis hal apa yang perlu Anda pantau? Apakah properti tertentu tersedia untuk disewakan dan klien mana yang masih aktif mencari properti.



Asisten:



|391



|



392



Bab 11Analisis Database danRumah impianStudi kasus



Gambar 11.9Tujuan misi untukRumah impiansistem basis data.



Pengembang Basis Data:



Layanan apa yang perusahaan Anda berikan kepada pelanggan Anda?



Asisten:



Kami mencoba menjawab pertanyaan tentang properti yang tersedia untuk disewa seperti: "Apakah Anda memiliki flat dua kamar tidur di Hyndland, Glasgow?" dan "Berapa yang harus saya bayar untuk apartemen satu kamar tidur di pusat kota?"



Tanggapan terhadap jenis pertanyaan ini harus membantu merumuskan tujuan misi. Contoh tujuan misi untukRumah impiansistem basis data ditunjukkan pada Gambar 11.9.



11.4.3Rumah impianStudi Kasus—Definisi Sistem Tujuan dari tahap definisi sistem adalah untuk menentukan ruang lingkup dan batas dari sistem basis data dan pandangan pengguna utamanya. Di Bagian 10.4.1 kami menjelaskan bagaimana tampilan pengguna menunjukkan persyaratan yang harus didukung oleh sistem basis data seperti yang ditentukan oleh peran pekerjaan tertentu (seperti Direktur atau Supervisor) atau bidang aplikasi bisnis (seperti penyewaan properti atau penjualan properti).



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil



Gambar 11.10Batas sistem untukRumah impiansistem basis data.



Mendefinisikan batas sistem untukRumah impiansistem basis data Selama tahap siklus hidup pengembangan sistem basis data ini, wawancara lebih lanjut dengan pengguna dapat digunakan untuk mengklarifikasi atau memperluas data yang diambil pada tahap sebelumnya. Namun, teknik pencarian fakta tambahan juga dapat digunakan, termasuk memeriksa contoh dokumentasi yang ditunjukkan di Bagian 11.4.1. Data yang dikumpulkan sejauh ini dianalisis untuk menentukan batas sistem basis data. Batas sistem untukRumah impiansistem basis data ditunjukkan pada Gambar 11.10. mengidentifikasi tampilan pengguna utama untukRumah impiansistem basis data Kami sekarang menganalisis data yang dikumpulkan sejauh ini untuk menentukan tampilan pengguna utama dari sistem basis data. Sebagian besar data tentang tampilan pengguna dikumpulkan selama wawancara dengan Direktur dan anggota staf yang berperan sebagai Manajer, Supervisor, dan Asisten. Tampilan pengguna utama untukRumah impiansistem basis data ditunjukkan pada Gambar 11.11.



11.4.4Rumah impianStudi Kasus—Pengumpulan dan Analisis Persyaratan Selama tahap ini, kami terus mengumpulkan lebih banyak detail tentang tampilan pengguna yang diidentifikasi di tahap sebelumnya, untuk membuat aspesifikasi kebutuhan penggunayang menjelaskan secara rinci data yang akan disimpan dalam basis data dan bagaimana data tersebut akan digunakan. Saat mengumpulkan lebih banyak informasi tentang tampilan pengguna, kami juga mengumpulkan persyaratan umum apa pun untuk sistem. Tujuan pengumpulan informasi ini adalah untuk membuat a spesifikasi sistem, yang menjelaskan semua fitur yang akan disertakan dalam sistem basis data baru, seperti jaringan dan persyaratan akses bersama, persyaratan kinerja, dan tingkat keamanan yang diperlukan. Saat kami mengumpulkan dan menganalisis persyaratan untuk sistem baru, kami juga mempelajari tentang fitur yang paling berguna dan paling menyusahkan dari sistem saat ini. Kapan



|393



|



394



Bab 11Analisis Database danRumah impianStudi kasus



Gambar 11.11Tampilan pengguna utama untukRumah impiansistem basis data.



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil membangun sistem database baru, masuk akal untuk mencoba mempertahankan hal-hal baik tentang sistem lama sambil memperkenalkan manfaat yang akan menjadi bagian dari penggunaan sistem baru. Aktivitas penting yang terkait dengan tahap ini adalah memutuskan cara menghadapi situasi di mana terdapat lebih dari satu tampilan pengguna. Seperti yang telah kita bahas di Bagian 10.6, ada tiga pendekatan utama untuk menangani berbagai tampilan pengguna:terpusat pendekatan, yangmelihat integrasipendekatan, dan kombinasi dari kedua pendekatan tersebut. Kami membahas bagaimana pendekatan ini dapat digunakan segera. mengumpulkan lebih banyak informasi tentang tampilan pengguna dariRumah impian sistem basis data Untuk mengetahui lebih lanjut tentang persyaratan untuk setiap tampilan pengguna, kami dapat kembali menggunakan pilihan teknik pencarian fakta, termasuk wawancara dan mengamati bisnis yang sedang berjalan. Contoh jenis pertanyaan yang mungkin kami tanyakan tentang data (diwakili sebagai X) yang diperlukan oleh tampilan pengguna meliputi:



“Jenis data apa yang perlu Anda simpan di X?” "Halhal apa yang Anda lakukan dengan data di X?" Misalnya, kami dapat mengajukan pertanyaan berikut kepada Manajer: Pengembang Basis Data:



Jenis data apa yang Anda butuhkan untuk menyimpan staf?



Pengelola:



Jenis data yang dimiliki oleh seorang staf adalah nama lengkap, jabatan, jenis kelamin, tanggal lahir, dan gaji.



Pengembang Basis Data:



Hal-hal apa yang Anda lakukan dengan data staf?



Pengelola:



Saya harus bisa memasukkan detail anggota staf baru dan menghapus detail mereka saat mereka pergi. Saya perlu memperbarui detail staf dan mencetak laporan yang mencantumkan nama lengkap, posisi, dan gaji setiap anggota staf di cabang saya. Saya harus dapat mengalokasikan staf ke Supervisor. Kadang-kadang ketika saya perlu berkomunikasi dengan cabang lain, saya perlu mencari tahu nama dan nomor telepon Manajer di cabang lain.



Kita perlu mengajukan pertanyaan serupa tentang semua data penting yang akan disimpan dalam database. Tanggapan atas pertanyaan ini akan membantu mengidentifikasi detail yang diperlukan untuk spesifikasi kebutuhan pengguna.



mengumpulkan informasi tentang persyaratan sistem dariRumah impiansistem basis data Saat melakukan wawancara tentang pandangan pengguna, kami juga harus mengumpulkan informasi yang lebih umum tentang persyaratan sistem. Contoh jenis pertanyaan yang mungkin kami tanyakan tentang sistem meliputi:



“Transaksi apa yang sering berjalan di database?” “Transaksi apa yang penting untuk operasi organisasi?” “Kapan transaksi penting dijalankan?”



|395



|



396



Bab 11Analisis Database danRumah impianStudi kasus “Kapan periode beban kerja rendah, normal, dan tinggi untuk transaksi penting?” “Jenis keamanan apa yang Anda inginkan untuk sistem basis data?”



“Apakah ada data yang sangat sensitif yang harus diakses hanya oleh anggota staf tertentu?” “Data historis apa yang ingin Anda simpan?”



“Apa persyaratan jaringan dan akses bersama untuk sistem basis data?” “Jenis perlindungan dari kegagalan atau kehilangan data apa yang Anda inginkan untuk sistem basis data?” Misalnya, kami dapat mengajukan pertanyaan berikut kepada Manajer: Pengembang Basis Data:



Transaksi apa yang sering berjalan di database?



Pengelola:



Kami sering mendapat permintaan baik melalui telepon atau klien yang menelepon ke cabang kami untuk mencari jenis properti tertentu di area kota tertentu dan untuk sewa tidak lebih dari jumlah tertentu. Kami berharap klien menggunakan yang baruRumah impianSitus web akan dapat melihat properti kami kapan saja, siang atau malam hari. Kami juga memerlukan informasi terkini tentang properti dan klien sehingga laporan dapat dijalankan yang menunjukkan properti yang saat ini tersedia untuk disewa dan klien sedang mencari properti.



Pengembang Basis Data:



Transaksi apa yang penting untuk operasi bisnis?



Pengelola:



Sekali lagi, transaksi penting mencakup kemampuan untuk mencari properti tertentu dan mencetak laporan dengan daftar properti terkini yang tersedia untuk disewa. Klien kami akan pergi ke tempat lain jika kami tidak dapat menyediakan layanan dasar ini.



Pengembang Basis Data:



Kapan transaksi penting dijalankan?



Pengelola:



Setiap hari.



Pengembang Basis Data:



Kapan periode beban kerja rendah, normal, dan tinggi untuk transaksi kritis?



Pengelola:



Kami buka enam hari seminggu. Secara umum, kita cenderung diam di pagi hari dan semakin sibuk seiring berjalannya hari. Namun, slot waktu tersibuk setiap hari untuk berurusan dengan pelanggan adalah antara pukul 12 dan 14:00 dan 17:00 dan 17:00. Kami berharap klien menggunakan yang baruRumah



impian Situs web akan dapat mencari melalui properti kami di PC mereka sendiri; ini harus mengurangi jumlah permintaan properti yang harus ditangani oleh staf. Kami mungkin mengajukan pertanyaan-pertanyaan berikut kepada Direktur:



Pengembang Basis Data:



Jenis keamanan apa yang Anda inginkan untuk sistem basis data?



Direktur:



Saya kira database yang menyimpan informasi untuk perusahaan persewaan properti tidak menyimpan data yang sangat sensitif, tetapi saya tidak ingin ada pesaing kita yang melihat data tersebut.



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil pada properti, pemilik, klien, dan sewa. Staf seharusnya hanya melihat data yang diperlukan untuk melakukan pekerjaan mereka dalam bentuk yang sesuai dengan apa yang mereka lakukan. Misalnya, meskipun Supervisor dan Asisten perlu melihat detail klien, catatan klien harus ditampilkan hanya satu per satu dan bukan sebagai laporan. Sejauh klien menggunakan yang baruRumah impianSitus web prihatin, kami ingin mereka memiliki akses ke properti kami dan detail mereka sendiri — tetapi tidak ada yang lain. Pengembang Basis Data:



Apakah ada data yang sangat sensitif yang harus diakses hanya oleh anggota staf tertentu?



Direktur:



Seperti yang saya katakan sebelumnya, staf seharusnya hanya melihat data yang diperlukan untuk melakukan pekerjaan mereka. Misalnya, meskipun Supervisor perlu melihat data staf, detail gaji tidak boleh disertakan.



Pengembang Basis Data:



Data historis apa yang ingin Anda simpan?



Direktur:



Saya ingin menyimpan detail klien dan pemilik selama beberapa tahun setelah transaksi terakhir mereka dengan kami, sehingga kami dapat mengirimkan penawaran terbaru kepada mereka, dan secara umum mencoba menarik mereka kembali. Saya juga ingin dapat menyimpan informasi sewa selama beberapa tahun, sehingga kami dapat menganalisisnya untuk mengetahui jenis properti dan area mana di setiap kota yang paling populer untuk pasar persewaan properti, dan seterusnya.



Pengembang Basis Data:



Apa persyaratan jaringan dan akses bersama untuk sistem basis data?



Direktur:



Saya ingin semua cabang terhubung ke kantor cabang utama kami di Glasgow sehingga staf dapat mengakses sistem dari mana pun dan kapan pun mereka membutuhkannya. Di sebagian besar cabang, saya memperkirakan sekitar dua atau tiga staf mengakses sistem pada satu waktu, tetapi ingat bahwa kami memiliki sekitar 100 cabang. Sebagian besar waktu staf harus hanya mengakses data cabang lokal. Namun, saya tidak benar-benar ingin ada batasan tentang seberapa sering atau kapan sistem dapat diakses, kecuali memiliki implikasi finansial yang nyata. Seperti yang saya katakan sebelumnya, klien menggunakan yang baruRumah impianSitus web harus memiliki akses ke properti kami dan detailnya sendiri, tetapi tidak ada yang lain.



Pengembang Basis Data:



Jenis perlindungan dari kegagalan atau kehilangan data apa yang Anda inginkan untuk sistem basis data?



Direktur:



Yang terbaik, tentu saja. Semua bisnis kami akan dilakukan dengan menggunakan database, jadi jika turun, kami akan tenggelam. Untuk serius sebentar, saya pikir kita mungkin harus mencadangkan data kita setiap malam saat cabang tutup. Bagaimana menurutmu?



|397



|



398



Bab 11Analisis Database danRumah impianStudi kasus Kita perlu mengajukan pertanyaan serupa tentang semua aspek penting dari sistem. Tanggapan atas pertanyaan ini harus membantu mengidentifikasi detail yang diperlukan untuk spesifikasi persyaratan sistem. mengelola tampilan pengguna dariRumah impiansistem basis data Bagaimana kami memutuskan apakah akan menggunakan pendekatan integrasi terpusat atau tampilan, atau kombinasi keduanya untuk mengelola beberapa tampilan pengguna? Salah satu cara untuk membantu membuat keputusan adalah dengan memeriksa tumpang tindih dalam data yang digunakan antara tampilan pengguna yang diidentifikasi selama tahap definisi sistem. Tabel 11.7 merujuk silang tampilan pengguna Direktur, Manajer, Supervisor, Asisten, dan Klien dengan jenis data utama yang digunakan oleh setiap tampilan pengguna.



Kita lihat dari Tabel 11.7 bahwa ada tumpang tindih dalam data yang digunakan oleh semua tampilan pengguna. Namun, tampilan pengguna Direktur dan Manajer serta tampilan pengguna Supervisor dan Asisten menunjukkan lebih banyak kesamaan dalam hal persyaratan data. Misalnya, hanya tampilan pengguna Direktur dan Manajer yang memerlukan data tentang cabang dan surat kabar, sedangkan hanya tampilan pengguna Supervisor dan Asisten yang memerlukan data tentang tampilan properti. Tampilan pengguna Klien memerlukan akses ke jumlah data paling sedikit, dan itu hanya properti dan data klien. Berdasarkan analisis ini, kami menggunakanterpusat pendekatan untuk terlebih dahulu menggabungkan persyaratan untuk tampilan pengguna Direktur dan Manajer (diberi nama kolektif Cabangtampilan pengguna) dan persyaratan untuk tampilan pengguna Supervisor, Asisten, dan Klien (diberikan nama kolektif dariStafKlien tampilan pengguna). Kami kemudian mengembangkan model data yang mewakili tampilan pengguna Branch dan StaffClient dan kemudian menggunakanmelihat integrasi pendekatan untuk menggabungkan dua model data. Tentunya untuk studi kasus sederhana sepertiRumah impian, kami dapat dengan mudah menggunakan pendekatan terpusat untuk semua tampilan pengguna, tetapi kami akan tetap pada keputusan kami untuk membuat dua tampilan pengguna kolektif sehingga kami dapat menjelaskan dan mendemonstrasikan cara kerja pendekatan integrasi tampilan dalam praktiknya di Bab 17.



Sulit untuk memberikan aturan yang tepat tentang kapan waktu yang tepat untuk menggunakan pendekatan integrasi terpusat atau tampilan. Keputusan harus didasarkan pada penilaian kompleksitas sistem basis data dan tingkat tumpang tindih antara berbagai tampilan pengguna. Namun, apakah kita menggunakan pendekatan integrasi terpusat atau tampilan atau campuran keduanya untuk membangun basis data yang mendasarinya, pada akhirnya kita perlu membangun kembali



Tabel 11.7Referensi silang tampilan pengguna dengan jenis data utama yang digunakan oleh masing-masing.



DIREKTUR MANAJER SUPERVISOR ASISTEN



Klien



cabang



X



X



staf



X



X



X



properti untuk disewakan



X



X



X



X



pemilik



X



X



X



X



klien



X



X



X



X



X



X



X



X



melihat properti



sewa



X



X



koran



X



X



X X



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil



tampilan pengguna asli (yaitu Direktur, Manajer, Supervisor, Asisten, dan Klien) untuk sistem basis data yang berfungsi. Kami menjelaskan dan mendemonstrasikan pembentukan tampilan pengguna untuk sistem basis data di Bab 18. Semua informasi yang dikumpulkan sejauh ini pada setiap tampilan pengguna dari sistem basis data dijelaskan dalam dokumen yang disebut aspesifikasi kebutuhan pengguna. Spesifikasi persyaratan pengguna menjelaskan persyaratan data untuk setiap tampilan pengguna dan contoh bagaimana data digunakan oleh tampilan pengguna. Untuk kemudahan referensi, spesifikasi persyaratan pengguna untuk tampilan pengguna Cabang dan StaffClient dari Rumah impiansistem basis data diberikan dalam Lampiran A. Di sisa bab ini, kami menyajikan persyaratan sistem umum untukRumah impiansistem basis data.



Spesifikasi sistem untukRumah impiansistem basis data Spesifikasi sistem harus mencantumkan semua fitur penting untukRumah impian sistem basis data. Jenis fitur yang harus dijelaskan dalam spesifikasi sistem meliputi: • ukuran basis data awal; • tingkat pertumbuhan basis data; • jenis dan jumlah rata-rata pencarian record; • persyaratan jaringan dan akses bersama; • pertunjukan; • keamanan; • cadangan dan pemulihan; •



masalah hukum.



Persyaratan sistem untukRumah impianSistem Basis Data Ukuran



basis data awal



(1) Ada sekitar 2000 anggota staf yang bekerja di lebih dari 100 cabang. Ada ratarata 20 dan maksimal 40 anggota staf di setiap cabang. (2) Ada sekitar 100.000 properti yang tersedia di semua cabang. Ada rata-rata 1000 dan maksimal 3000 properti di setiap cabang. (3) Ada sekitar 60.000 pemilik properti. Ada rata-rata 600 dan maksimal 1000 pemilik properti di setiap cabang. (4) Ada sekitar 100.000 nasabah yang terdaftar di semua cabang. Ada rata-rata 1000 dan maksimal 1500 klien terdaftar di setiap cabang. (5) Ada sekitar 4.000.000 penayangan di semua cabang. Ada rata-rata 40.000 dan maksimal 100.000 tampilan di setiap cabang. (6) Ada sekitar 400.000 sewa di semua cabang. Ada rata-rata 4000 dan maksimal 10.000 sewa di setiap cabang. (7) Ada sekitar 50.000 iklan surat kabar di 100 surat kabar di semua cabang.



Tingkat pertumbuhan basis data



(1) Sekitar 500 properti baru dan 200 pemilik properti baru akan ditambahkan ke database setiap bulan.



|399



|



400



Bab 11Analisis Database danRumah impianStudi kasus



(2) Setelah properti tidak lagi tersedia untuk disewa, catatan terkait akan dihapus dari database. Sekitar 100 rekaman properti akan dihapus setiap bulan. (3) Jika pemilik properti tidak menyediakan properti untuk disewa setiap saat dalam jangka waktu dua tahun, catatannya akan dihapus. Sekitar 100 catatan pemilik properti akan dihapus setiap bulan. (4) Sekitar 20 anggota staf bergabung dan keluar dari perusahaan setiap bulan. Catatan staf yang telah meninggalkan perusahaan akan dihapus setelah satu tahun. Sekitar 20 catatan staf akan dihapus setiap bulan. (5) Sekitar 1000 klien baru mendaftar di cabang setiap bulan. Jika klien tidak melihat atau menyewakan properti kapan pun dalam jangka waktu dua tahun, catatannya akan dihapus. Sekitar 100 catatan klien akan dihapus setiap bulan. (6) Sekitar 5000 penayangan baru dicatat di semua cabang setiap hari. Detail tampilan properti akan dihapus satu tahun setelah pembuatan catatan. (7) Sekitar 1000 sewa baru akan dicatat di semua cabang setiap bulan. Rincian sewa properti akan dihapus dua tahun setelah pembuatan catatan. (8) Sekitar 1000 iklan surat kabar dipasang setiap minggu. Detail iklan surat kabar akan dihapus satu tahun setelah pembuatan catatan.



Jenis dan jumlah rata-rata pencarian rekaman (1) Mencari detail cabang—kira-kira 10 per hari. (2) Mencari detail anggota staf di cabang—kira-kira 20 per hari. (3) Mencari detail properti tertentu—kira-kira 5.000 per hari (Senin sampai Kamis), dan kira-kira 10.000 per hari (Jumat dan Sabtu). Beban kerja puncak adalah 12.00–14.00 dan 17.00–19.00 setiap hari. (Beban kerja untuk pencarian properti harus dinilai ulang setelahRumah impianSitus web diluncurkan.) (4) Mencari detail pemilik properti—kira-kira 100 per hari. (5) Mencari detail klien—kira-kira 1000 per hari (Senin sampai Kamis), dan sekitar 2000 per hari (Jumat dan Sabtu). Beban kerja puncak adalah 12.00–14.00 dan 17.00–19.00 setiap hari. (6) Mencari detail view properti—kurang lebih 2000 per hari (Senin s/d Kamis), dan kurang lebih 5000 per hari (Jumat dan Sabtu). Beban kerja puncak adalah 12.00–14.00 dan 17.00–19.00 setiap hari. (7) Mencari rincian sewa—kira-kira 1000 per hari (Senin sampai Kamis), dan kirakira 2000 per hari (Jumat dan Sabtu). Beban kerja puncak adalah 12.00–14.00 dan 17.00–19.00 setiap hari.



Persyaratan jaringan dan akses bersama Semua cabang harus terhubung dengan aman ke database terpusat yang terletak di DreamHome'skantor pusat di Glasgow. Sistem harus memungkinkan setidaknya dua hingga



11.4Menggunakan Teknik Pencarian Fakta: Contoh yang Berhasil



tiga orang secara bersamaan mengakses sistem dari setiap cabang. Pertimbangan perlu diberikan pada persyaratan lisensi untuk jumlah akses bersamaan ini.



Pertunjukan (1) Selama jam buka, tetapi tidak selama periode puncak, diharapkan respons kurang dari 1 detik untuk semua pencarian rekaman tunggal. Selama periode puncak, perkirakan respons kurang dari 5 detik untuk setiap pencarian. (2) Selama jam buka, tetapi tidak selama periode puncak, mengharapkan respons kurang dari 5 detik untuk setiap pencarian beberapa rekaman. Selama periode puncak, perkirakan respons kurang dari 10 detik untuk setiap pencarian beberapa rekaman. (3) Selama jam buka, tetapi tidak selama periode puncak, diharapkan respons kurang dari 1 detik untuk setiap pembaruan/penyimpanan. Selama periode puncak, perkirakan respons kurang dari 5 detik untuk setiap pembaruan/penyimpanan.



Keamanan



(1) Basis data harus dilindungi kata sandi. (2) Setiap anggota staf harus diberi hak akses database yang sesuai dengan tampilan pengguna tertentu, yaitu Direktur, Manajer, Supervisor, atau Asisten. (3) Seorang staf harus melihat hanya data yang diperlukan untuk melakukan pekerjaannya dalam bentuk yang sesuai dengan apa yang dia lakukan.



(4) Klien hanya boleh melihat data properti dan detail pribadi mereka menggunakan Rumah impianSitus web. cadangan dan pemulihan Basis data harus dicadangkan setiap hari pada pukul 12 tengah malam.



masalah hukum



Setiap negara memiliki undang-undang yang mengatur cara penanganan penyimpanan data pribadi yang terkomputerisasi. SebagaiRumah impiandatabase menyimpan data tentang staf, klien, dan pemilik properti, setiap masalah hukum yang harus dipatuhi harus diselidiki dan diterapkan. Masalah profesional, hukum, dan etika yang terkait dengan manajemen data dibahas di Bab 21.



11.4.5Rumah impianStudi Kasus—Desain Basis Data Dalam bab ini kami mendemonstrasikan pembuatan spesifikasi kebutuhan pengguna untuk tampilan pengguna Cabang dan Staf dan spesifikasi sistem untuk Rumah impiansistem basis data. Dokumen-dokumen ini adalah sumber informasi untuk tahap selanjutnya dari siklus hidup yang disebutdesain basis data. Dalam Bab 16 sampai 19 kami menyediakan metodologi langkah demi langkah untuk desain database dan menggunakanRumah impian studi kasus dan dokumen yang dibuat untukRumah impiansistem database dalam bab ini untuk menunjukkan metodologi dalam praktek.



|401



|



402



Bab 11Analisis Database danRumah impianStudi kasus



Ringkasan Bab • Pencarian faktaadalah proses formal menggunakan teknik seperti wawancara dan kuesioner untuk mengumpulkan fakta tentang sistem, persyaratan, dan preferensi.



• Pencarian fakta sangat penting untuk tahap awal siklus hidup pengembangan sistem basis data, termasuk tahap perencanaan basis data, definisi sistem, dan pengumpulan persyaratan serta analisis.



• Lima teknik pencarian fakta yang paling umum adalah memeriksa dokumentasi, wawancara, mengamati operasi perusahaan, melakukan penelitian, dan menggunakan kuesioner.



• Ada dua dokumen utama yang dibuat selama tahap pengumpulan dan analisis kebutuhan:



spesifikasi kebutuhan penggunadanspesifikasi sistem.



•



Ituspesifikasi kebutuhan penggunamenjelaskan secara rinci data yang akan disimpan dalam database dan bagaimana data tersebut akan digunakan.



• Ituspesifikasi sistemmenjelaskan setiap fitur yang akan disertakan dalam sistem basis data, seperti persyaratan kinerja dan keamanan.



meninjau Pertanyaan 11.1Diskusikan secara singkat tujuan wawancara dalam proyek pengembangan basis data. 11.2Jelaskan bagaimana pencarian fakta digunakan di seluruh tahapan siklus hidup pengembangan sistem basis data. 11.3Untuk setiap tahap siklus hidup pengembangan sistem basis data, identifikasi contoh fakta yang ditangkap dan



dokumentasi yang dihasilkan. 11.4Pengembang basis data biasanya menggunakan beberapa teknik pencarian fakta selama satu proyek basis data. Lima teknik



yang paling umum digunakan adalah memeriksa dokumentasi, wawancara, mengamati bisnis dalam operasi, melakukan penelitian, dan menggunakan kuesioner. Jelaskan masing-masing teknik pencarian fakta dan identifikasi kelebihan dan kekurangan masing-masing.



11.5Apa bahaya dari tidak mendefinisikan tujuan misi dan pernyataan misi untuk sistem basis data?



11.6Apa tujuan mengidentifikasi batas sistem untuk sistem basis data? 11.7Bagaimana isi spesifikasi kebutuhan pengguna berbeda dari spesifikasi sistem? 11.8Pengembangan basis data dan pencarian fakta tidak dapat dipisahkan. Salah satu faktor keberhasilan proses pembangunan jika keterlibatan



pengguna. Apa peran yang dimainkan oleh pengguna dalam proses pengembangan basis data?



latihan 11.9Asumsikan bahwa teman Anda saat ini bekerja di perusahaan konsultan multinasional yang menangani analisis dan pengembangan basis



data di Tanzania. Tugas pertamanya adalah menjalankan misi pencarian fakta untuk klien yang berniat mengembangkan sistem database untuk perusahaan mereka untuk mengontrol transaksi bisnis sehari-hari mereka. Teman Anda telah memutuskan untuk meminta nasihat dari Anda.



Tugas:Persiapkan catatan singkat yang akan membantu teman Anda berhasil memilih teknik pencarian fakta yang terbaik. Untuk setiap teknik, uraikan faktor-faktor penting untuk mewujudkan fakta-fakta berkualitas. Catatan tersebut juga harus merinci masalah yang harus dihindari atau ditangani agar setiap alat berhasil.



|403



Latihan



Klien untuk latihan ini dan yang mengikutinya dapat berupa salah satu dari studi kasus fiktif yang diberikan dalam Lampiran B atau beberapa perusahaan nyata yang diidentifikasi oleh Anda atau profesor Anda. 11.10Asumsikan bahwa Anda adalah seorang karyawan dari sebuah perusahaan konsultan yang berspesialisasi dalam analisis, desain,



dan implementasi sistem database. Seorang klien baru-baru ini mendekati perusahaan Anda dengan maksud untuk menerapkan sistem basis data.



Tugas:Anda diminta untuk membangun proyek database melalui tahap awal proyek. Dengan mengingat tugas ini, buat pernyataan misi dan tujuan misi serta diagram sistem tingkat tinggi untuk sistem basis data klien. 11.11Asumsikan bahwa Anda adalah seorang karyawan dari sebuah perusahaan konsultan yang berspesialisasi dalam analisis, desain, dan



implementasi sistem database. Seorang klien baru-baru ini mendekati perusahaan Anda dengan maksud untuk menerapkan sistem basis data. Telah ditetapkan bahwa sistem basis data klien akan mendukung banyak kelompok pengguna yang berbeda (tampilan pengguna).



Tugas:Anda diminta untuk mengidentifikasi cara terbaik mengelola persyaratan untuk tampilan pengguna ini. Dengan mempertimbangkan tugas ini, buat laporan yang mengidentifikasi persyaratan tingkat tinggi untuk setiap tampilan pengguna dan tunjukkan hubungan antara tampilan pengguna. Simpulkan laporan dengan mengidentifikasi dan membenarkan pendekatan terbaik untuk mengelola persyaratan tampilan multi-pengguna.



2



1



terjaditer



C



Pemodelan Entitas-Hubungan



Tujuan Bab Dalam bab ini Anda akan belajar: • Bagaimana menggunakan pemodelan Entity–Relationship (ER) dalam desain database.



• Konsep dasar yang terkait dengan model ER: entitas, hubungan, dan atribut. • Teknik diagram untuk menampilkan model ER menggunakan Unified Modeling Language (UML). • Bagaimana mengidentifikasi dan menyelesaikan masalah dengan model ER yang disebut jebakan koneksi.



Dalam Bab 11 kami menjelaskan teknik utama untuk mengumpulkan dan menangkap informasi tentang apa yang dibutuhkan pengguna dari sistem basis data. Setelah tahap pengumpulan dan analisis persyaratan dari siklus hidup pengembangan sistem basis data selesai dan kami telah mendokumentasikan persyaratan untuk sistem basis data, kami siap untuk memulai tahap desain basis data. Salah satu aspek yang paling sulit dari desain basis data adalah kenyataan bahwa perancang, pemrogram, dan pengguna akhir cenderung melihat data dan penggunaannya dengan cara yang berbeda. Sayangnya, kecuali kita mendapatkan pemahaman umum yang mencerminkan bagaimana perusahaan beroperasi, desain yang kita hasilkan akan gagal memenuhi kebutuhan pengguna. Untuk memastikan bahwa kita mendapatkan pemahaman yang tepat tentang sifat data dan bagaimana data itu digunakan oleh perusahaan, kita memerlukan model komunikasi yang nonteknis dan bebas dari ambiguitas. Model Entity–Relationship (ER) adalah salah satu contohnya. Pemodelan ER adalah pendekatan top-down untuk desain database yang dimulai dengan mengidentifikasi data penting yang dipanggilentitasDanhubunganantara data yang harus direpresentasikan dalam model. Kami kemudian menambahkan lebih banyak detail, seperti informasi yang ingin kami simpan tentang entitas dan hubungan yang dipanggilatributdan apapun



kendalapada entitas, relasi, dan atribut. Pemodelan ER adalah teknik penting yang harus dikuasai oleh setiap perancang basis data dan menjadi dasar metodologi yang disajikan dalam buku ini.



Dalam bab ini kami memperkenalkan konsep dasar model ER. Meskipun ada kesepakatan umum tentang arti setiap konsep, ada sejumlah notasi berbeda yang dapat digunakan untuk mewakili setiap konsep secara diagram. Kami telah memilih notasi diagram yang menggunakan bahasa pemodelan berorientasi objek yang semakin populer disebutBahasa Pemodelan Terpadu(UML) (Boochet al.,



405



|



406



Bab 12Pemodelan Entitas-Hubungan 1999). UML adalah penerus sejumlah metode analisis dan desain berorientasi objek yang diperkenalkan pada 1980-an dan 1990-an. Object Management Group (OMG) bertanggung jawab atas pembuatan dan pengelolaan UML (tersedia di www.uml.org). UML saat ini diakui sebagai bahasa pemodelan standar industri de facto untuk proyek rekayasa perangkat lunak berorientasi objek. Meskipun kami menggunakan notasi UML untuk menggambar model ER, kami terus menjelaskan konsep model ER menggunakan terminologi basis data tradisional. Pada Bagian 27.8 kami akan memberikan pembahasan yang lebih lengkap tentang UML. Kami juga menyertakan ringkasan dua notasi diagram alternatif untuk model ER di Lampiran C. Pada bab selanjutnya kita membahas masalah inheren yang terkait dengan merepresentasikan aplikasi basis data yang kompleks dengan menggunakan konsep dasar model ER. Untuk mengatasi masalah ini, konsep "semantik" tambahan ditambahkan ke model ER asli, menghasilkan pengembangan model Entity-Relationship (EER) yang Ditingkatkan. Dalam Bab 13 kami menjelaskan konsep utama yang terkait dengan model EER, yang disebut spesialisasi/generalisasi, agregasi, dan komposisi. Kami juga mendemonstrasikan bagaimana mengubah model ER yang ditunjukkan pada Gambar 12.1 menjadi model EER yang ditunjukkan pada Gambar 13.8.



Struktur Bab iniPada Bagian 12.1, 12.2, dan 12.3 kami memperkenalkan konsep dasar model Entitas–Hubungan: entitas, relasi, dan atribut. Di setiap bagian kami mengilustrasikan bagaimana konsep dasar ER direpresentasikan secara gambar dalam diagram ER menggunakan UML. Pada Bagian 12.4 kita membedakan antara entitas lemah dan kuat dan pada Bagian 12.5 kita membahas bagaimana atribut yang biasanya diasosiasikan dengan entitas dapat ditugaskan ke relasi. Pada Bagian 12.6 kami menjelaskan kendala struktural yang terkait dengan hubungan. Terakhir, di Bagian 12.7 kami mengidentifikasi masalah potensial yang terkait dengan desain model ER yang disebut jebakan koneksi dan mendemonstrasikan bagaimana masalah ini dapat diselesaikan. Diagram ER yang ditunjukkan pada Gambar 12.1 adalah contoh salah satu produk akhir yang mungkin dari pemodelan ER. Model ini mewakili hubungan antara data yang dijelaskan dalam spesifikasi persyaratan untuk tampilan Cabang Rumah impianstudi kasus diberikan dalam Lampiran A. Gambar ini disajikan di awal bab ini untuk menunjukkan kepada pembaca contoh jenis model yang dapat kita bangun dengan menggunakan pemodelan ER. Pada tahap ini, pembaca tidak perlu khawatir untuk memahami diagram ini sepenuhnya, karena konsep dan notasi yang digunakan dalam gambar ini dibahas secara mendetail di seluruh bab ini.



12.1Jenis Entitas Jenis entitas



Sekelompok objek dengan properti yang sama, yang diidentifikasi oleh perusahaan memiliki keberadaan yang independen.



Konsep dasar dari model ER adalahtipe entitas, yang mewakili sekelompok "objek" di "dunia nyata" dengan properti yang sama. Sebuah tipe entitas memiliki



|407



12.1Jenis Entitas



Gambar 12.1Diagram Entitas–Hubungan (ER) dari tampilan CabangRumah impian.



keberadaan independen dan dapat berupa objek dengan keberadaan fisik (atau "nyata") atau objek dengan keberadaan konseptual (atau "abstrak"), seperti yang tercantum dalam Gambar 12.2. Perhatikan bahwa kami hanya dapat memberikan definisi yang berfungsi dari tipe entitas, karena tidak ada definisi formal yang ketat. Ini berarti bahwa desainer yang berbeda dapat mengidentifikasi entitas yang berbeda.



kejadian entitas



Objek yang dapat diidentifikasi secara unik dari tipe entitas.



|



408



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.2



Contoh



entitas dengan



fisik atau konseptual



adanya.



Setiap objek yang dapat diidentifikasi secara unik dari tipe entitas disebut hanya sebagai terjadinya entitas. Di sepanjang buku ini, kami menggunakan istilah "tipe entitas" atau "kemunculan entitas"; namun, kami menggunakan istilah "entitas" yang lebih umum di mana artinya jelas.



Kami mengidentifikasi setiap jenis entitas dengan nama dan daftar properti. Database biasanya berisi banyak tipe entitas yang berbeda. Contoh tipe entitas yang ditampilkan di



Gambar 12.1 meliputi:Staf,Cabang,PropertyForRent, DanPemilik Pribadi.



Representasi diagram dari tipe entitas Setiap tipe entitas ditampilkan sebagai persegi panjang, diberi label dengan nama entitas, yang biasanya berupa kata benda tunggal. Di UML, huruf pertama dari setiap kata dalam nama entitas adalah huruf besar (misalnya,StafDanPropertyForRent). Gambar 12.3 mengilustrasikan representasi diagram dariStafDanCabangtipe entitas.



12.2Jenis Hubungan Jenis hubungan



Satu set asosiasi yang bermakna di antara tipe entitas.



Atipe hubunganadalah sekumpulan asosiasi antara satu atau lebih tipe entitas yang berpartisipasi. Setiap tipe relasi diberi nama yang menjelaskan fungsinya. Contoh tipe relasi yang ditunjukkan pada Gambar 12.1 adalah relasi yang disebutPOwn, yang mengasosiasikanPemilik PribadiDanPropertyForRententitas.



Gambar 12.3



Diagramatik



perwakilan entitas Staf dan Cabang jenis.



12.2Jenis Hubungan



Seperti halnya tipe entitas dan entitas, istilah "tipe hubungan" dan "kejadian hubungan" perlu dibedakan. Hubungan kejadian



Asosiasi yang dapat diidentifikasi secara unik yang mencakup satu kejadian dari setiap jenis entitas yang berpartisipasi.



Terjadinya hubunganmenunjukkan kejadian entitas tertentu yang terkait. Di sepanjang buku ini, kami menggunakan istilah "tipe hubungan" atau "kejadian hubungan". Namun, seperti istilah "entitas", kami menggunakan istilah "hubungan" yang lebih umum jika artinya jelas. Pertimbangkan tipe hubungan yang disebutMemiliki, yang mewakili hubungan antara CabangDanStafentitas,



yaituCabangMemilikiStaf. Setiap kejadian dariMemilikihubungan asosiasi satuCabangkejadian entitas dengan satuStafterjadinya entitas. Kita dapat memeriksa contoh kejadian individu dariMemilikihubungan menggunakan a jaringan semantik. Jaringan semantik adalah model tingkat objek, yang menggunakan simbol • untuk mewakili entitas dan simbole • untuk mewakili hubungan. Jaringan semantik



pada Gambar 12.4 menunjukkan tiga contohMemilikihubungan (dilambangkan rl, r2, dan r3). Setiap hubungan menggambarkan asosiasi tunggalCabangkejadian entitas dengan satuStafterjadinya entitas. Hubungan diwakili oleh garis yang menghubungkan setiap pesertaCabangentitas dengan yang terkaitStafkesatuan. Misalnya, hubungan rl mewakili hubungan antaraCabangentitas B003 danStaf entitas SG37.



Perhatikan bahwa kami mewakili masing-masingCabangDanStafkejadian entitas menggunakan nilai untuk atribut primary key, yaitucabangNoDanstafNo.Atribut kunci utama secara unik mengidentifikasi setiap kejadian entitas dan dibahas secara rinci di bagian berikut. Jika kami mewakili perusahaan menggunakan jaring semantik, akan sulit untuk dipahami, karena tingkat detailnya. Kita dapat lebih mudah merepresentasikan hubungan antar entitas dalam suatu perusahaan dengan menggunakan konsep model ER. Model ER menggunakan tingkat abstraksi yang lebih tinggi daripada jaring semantik dengan menggabungkan kumpulan kejadian entitas ke dalam tipe entitas dan kumpulan kejadian relasi ke dalam tipe relasi.



Gambar 12.4Jaring semantik yang menunjukkan kejadian individu dariMemilikitipe hubungan.



|409



|



410



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.5 Sebuah diagram



perwakilan dari CabangMemilikiStaf



tipe hubungan.



Representasi diagram dari tipe hubungan Setiap tipe relasi ditampilkan sebagai garis yang menghubungkan tipe entitas terkait dan diberi label dengan nama relasi. Biasanya, suatu hubungan diberi nama menggunakan kata kerja (misalnya,MengawasiatauMengelola)atau frase pendek termasuk kata kerja (misalnya, Disewa Oleh). Sekali lagi, huruf pertama dari setiap kata dalam nama relasi ditampilkan dalam huruf besar. Jika memungkinkan, nama relasi harus unik untuk model ER tertentu. Suatu hubungan hanya diberi label dalam satu arah, yang biasanya berarti bahwa nama hubungan hanya masuk akal dalam satu arah (misalnya,Cabang MemilikiStaflebih masuk akal daripadaStafMemilikiCabang). Jadi setelah nama relasi dipilih, simbol panah ditempatkan di samping nama yang menunjukkan arah yang benar bagi pembaca untuk menginterpretasikan nama relasi (misalnya,Cabang Memiliki - Staf) seperti yang ditunjukkan pada Gambar 12.5.



12.2.1 Derajat Tipe Hubungan Gelar a tipe hubungan



Jumlah jenis entitas yang berpartisipasi dalam suatu hubungan.



Entitas yang terlibat dalam tipe relasi tertentu disebut sebagaipeserta dalam hubungan itu. Jumlah peserta dalam suatu tipe hubungan disebut derajatdari hubungan itu. Oleh karena itu, derajat suatu relasi menunjukkan jumlah tipe entitas yang terlibat dalam suatu relasi. Hubungan derajat dua disebutbiner. Contoh relasi biner adalahMemilikihubungan yang ditunjukkan pada Gambar 12.5 dengan dua tipe entitas yang berpartisipasi; yaitu,StafDanCabang. Contoh kedua dari hubungan biner adalahPownshubungan yang ditunjukkan pada Gambar 12.6 dengan dua tipe entitas yang berpartisipasi; yaitu,Pemilik PribadiDanPropertyForRent. ItuMemiliki



DanPownshubungan juga ditunjukkan pada Gambar 12.1 serta contoh lainnya



Gambar 12.6 Sebuah contoh



dari biner hubungan disebut



Powns.



12.2Jenis Hubungan



Gambar 12.7Contoh relasi terner disebutRegister.



hubungan biner. Faktanya, derajat yang paling umum untuk suatu hubungan adalah biner, seperti yang ditunjukkan pada gambar ini.



Hubungan derajat tiga disebutterner. Contoh relasi terner adalahRegisterdengan tiga jenis entitas yang berpartisipasi:Staf,Cabang, DanKlien. Hubungan ini mewakili pendaftaran klien oleh anggota staf di cabang. Istilah "hubungan kompleks" digunakan untuk menggambarkan hubungan dengan derajat lebih tinggi dari biner. Representasi diagramatik dari hubungan yang kompleks



Notasi UML menggunakan berlian untuk mewakili hubungan dengan derajat lebih tinggi dari biner. Nama relasi ditampilkan di dalam berlian, dan dalam hal ini, panah arah yang biasanya diasosiasikan dengan nama dihilangkan. Misalnya, hubungan ternary disebutRegisterditunjukkan pada Gambar 12.7. Hubungan ini juga ditunjukkan pada Gambar 12.1. Hubungan derajat empat disebutkuaterner. Karena kami tidak memiliki contoh hubungan seperti itu pada Gambar 12.1, kami menggambarkan hubungan kuaterner yang disebutMengaturdengan empat tipe entitas yang berpartisipasi—yaitu,Pembeli, Pengacara,Lembaga keuangan, DanPenawaran—dalam Gambar 12.8. Hubungan ini mewakili situasi di



mana pembeli, yang disarankan oleh pengacara dan didukung oleh lembaga keuangan, mengajukan penawaran.



Gambar 12.8Contoh relasi kuaterner disebutMengatur.



|411



|



412



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.9 Sebuah contoh



dari rekursif hubungan diteleponMengawasi dengan nama peran



Pengawas dan



Awasi.



12.2.2 Hubungan Rekursif Rekursif hubungan



Jenis hubungan di manasamatipe entitas berpartisipasi lebih dari sekaliperan yang berbeda.



Pertimbangkan hubungan rekursif yang disebutMengawasi, yang mewakili asosiasi staf dengan Supervisor di mana Supervisor juga merupakan anggota staf. Dengan kata lain,Staftipe entitas berpartisipasi dua kali dalamMengawasihubungan; partisipasi pertama sebagai Supervisor, dan partisipasi kedua sebagai staf yang disupervisi (Supervisee). Hubungan rekursif terkadang disebutunaryhubungan. Hubungan dapat diberikannama peranuntuk menunjukkan tujuan yang dimainkan oleh setiap tipe entitas yang berpartisipasi dalam suatu hubungan. Nama peran dapat menjadi penting untuk hubungan rekursif untuk menentukan fungsi masing-masing peserta. Penggunaan nama peran untuk menggambarkanMengawasihubungan rekursif ditunjukkan pada Gambar 12.9. Partisipasi pertama dariStaftipe entitas diMengawasihubungan diberi nama peran "Supervisor" dan partisipasi kedua diberi nama peran "Supervisee."



Nama peran juga dapat digunakan saat dua entitas diasosiasikan melalui lebih dari satu relasi. Misalnya,StafDanCabangtipe entitas dikaitkan melalui dua hubungan berbeda yang disebutMengelolaDanMemiliki. Seperti yang ditunjukkan pada Gambar 12.10, Gambar 12.10 Sebuah contoh



entitas terkait melalui dua berbeda



hubungan diteleponMengelola DanMemilikidengan



nama peran.



|413



12.3Atribut penggunaan nama peran menjelaskan tujuan dari setiap hubungan. Misalnya, dalam kasusStafMengelolaCabang, seorang staf (Stafentitas) diberi nama peran "Manajer" mengelola cabang (Cabangentitas) diberi nama peran "Kantor Cabang." Demikian pula untukCabangMemilikiStaf, sebuah cabang, diberi nama peran “Kantor Cabang” memiliki staf yang diberi nama peran “Anggota Staf.”



Nama peran biasanya tidak diperlukan jika fungsi entitas yang berpartisipasi dalam suatu relasi tidak ambigu.



12.3Atribut Atribut



Properti entitas atau tipe relasi.



Properti khusus dari tipe entitas disebut atribut. Misalnya, aStaf tipe entitas dapat dijelaskan olehstafNo,nama,posisi, Dangajiatribut. Atribut menyimpan nilai yang menggambarkan setiap kejadian entitas dan mewakili bagian utama dari data yang disimpan dalam database. Tipe relasi yang menghubungkan entitas juga dapat memiliki atribut yang mirip dengan tipe entitas, tetapi kami menunda pembahasan ini hingga Bagian 12.5. Pada bagian ini, kami berkonsentrasi pada karakteristik umum dari atribut.



Domain atribut



Himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.



Setiap atribut dikaitkan dengan sekumpulan nilai yang disebut adomain. Domain mendefinisikan nilai-nilai potensial yang dimiliki atribut dan mirip dengan konsep domain dalam model relasional (lihat Bagian 4.2). Misalnya, jumlah ruangan yang terkait dengan properti adalah antara 1 dan 15 untuk setiap kemunculan entitas. Oleh karena itu kami mendefinisikan kumpulan nilai untuk jumlah kamar (kamar) atribut dari PropertyForRenttipe entitas sebagai himpunan bilangan bulat antara 1 dan 15.



Atribut dapat berbagi domain. Misalnya,alamatatribut dariCabang, DanPemilik bisnistipe entitas berbagi domain yang sama dari semua kemungkinan alamat. Domain juga dapat terdiri dari domain. Misalnya, domain untukalamatatribut dariCabangentitas terdiri dari subdomain:jalan,kota, DanKode Pos. Pemilik Pribadi,



Domain darinamaatribut lebih sulit untuk didefinisikan, karena terdiri dari semua kemungkinan nama. Ini tentu saja merupakan string karakter, tetapi mungkin tidak hanya terdiri dari huruf tetapi juga tanda hubung atau karakter khusus lainnya. Model data yang dikembangkan sepenuhnya mencakup domain dari setiap atribut dalam model ER. Seperti yang sekarang kami jelaskan, atribut dapat diklasifikasikan sebagai:sederhanaataukomposit, bernilai



tunggalataumulti-nilai,atauberasal dari.



12.3.1 Atribut Sederhana dan Komposit Sederhana



atribut



Atribut terdiri dari satu komponen dengan keberadaan independen.



|



414



Bab 12Pemodelan Entitas-Hubungan



Atribut sederhana tidak dapat dibagi lagi menjadi komponen yang lebih kecil. Contoh atribut sederhana termasukposisiDangajidariStafkesatuan. Atribut sederhana terkadang disebutatomatribut. Gabungan atribut



Atribut terdiri dari beberapa komponen, masing-masing dengan keberadaan independen.



Beberapa atribut dapat dibagi lebih lanjut untuk menghasilkan komponen yang lebih kecil dengan keberadaannya sendiri yang independen. Misalnya,alamatatribut dariCabang



entitas dengan nilai (163 Main St, Glasgow, G11 9QX) dapat dibagi lagi menjadijalan



(163 Jalan Utama),kota(Glasgow), danKode Pos(G11 9QX) atribut.



Keputusan untuk memodelkanalamatatribut sebagai atribut sederhana atau untuk membagi atribut menjadijalan,kota, DanKode Postergantung pada apakah tampilan pengguna data mengacu padaalamatatribut sebagai satu unit atau sebagai komponen individu.



12.3.2 Atribut Bernilai Tunggal dan Bernilai Banyak Bernilai tunggal



atribut



Atribut yang memegang nilai tunggal untuk setiap kemunculan tipe entitas.



Sebagian besar atribut bernilai tunggal. Sebagai contoh, setiap kejadian dari Cabangtipe entitas memiliki nilai tunggal untuk nomor cabang (cabangNo) atribut (misalnya, B003), dan karenanyacabangNoatribut disebut sebagai singlevalued.



Multi-nilai atribut



Atribut yang menyimpan banyak nilai untuk setiap kemunculan tipe entitas.



Beberapa atribut memiliki banyak nilai untuk setiap kejadian entitas. Sebagai contoh, setiap kejadian dariCabangtipe entitas dapat memiliki beberapa nilai untuk telNoatribut (misalnya nomor cabang B003 memiliki nomor telepon 0141-339-2178 dan 0141-339-4439) dan karenanyatelNoatribut dalam hal ini multi-nilai. Atribut multi-nilai mungkin memiliki sekumpulan angka dengan batas atas dan bawah. Misalnya,telNoatribut dariCabangtipe entitas memiliki antara satu dan tiga nilai. Dengan kata lain, sebuah cabang dapat memiliki minimal satu nomor telepon hingga maksimal tiga nomor telepon.



12.3.3 Atribut Turunan Berasal dari



atribut



Atribut yang mewakili nilai yang dapat diturunkan dari nilai atribut terkait atau kumpulan atribut, tidak harus dalam tipe entitas yang sama.



|415



12.3Atribut



Nilai yang dipegang oleh beberapa atribut dapat diturunkan. Misalnya, nilai untuk durasiatribut dariSewaentitas dihitung darirentStartDanrentFinish atribut, juga dariSewajenis entitas. Kami mengacu padadurasiatribut sebagai atribut turunan, yang nilainya diturunkan darirentStartDanrentFinish atribut. Dalam beberapa kasus, nilai atribut diturunkan dari kejadian entitas dalam tipe entitas yang sama. Misalnya, jumlah total staf (totalStaff) atribut dariStaftipe entitas dapat dihitung dengan menghitung jumlah totalStafkejadian entitas. Atribut turunan juga dapat melibatkan asosiasi atribut dari tipe entitas yang berbeda. Misalnya, pertimbangkan atribut yang dipanggilmenyetorkandariSewajenis entitas. Nilai darimenyetorkanatribut dihitung sebagai dua kali sewa bulanan untuk properti. Oleh karena itu, nilai darimenyetorkanatribut dariSewatipe entitas berasal dari menyewaatribut dariPropertyForRenttipe entitas.



12.3.4 Kunci Calon kunci



Kumpulan atribut minimal yang secara unik mengidentifikasi setiap kejadian dari tipe entitas.



Kunci kandidat adalah jumlah minimal atribut, yang nilainya secara unik mengidentifikasi setiap kejadian entitas. Misalnya, nomor cabang (cabangNo) atribut adalah kunci kandidat untukCabangtipe entitas, dan memiliki nilai berbeda untuk setiap kejadian entitas cabang. Kunci kandidat harus memiliki nilai yang unik untuk setiap kemunculan tipe entitas. Ini menyiratkan bahwa kunci kandidat tidak boleh berisi null (lihat Bagian 4.2). Misalnya, setiap cabang memiliki nomor cabang yang unik (misalnya B003), dan tidak akan pernah ada lebih dari satu cabang dengan nomor cabang yang sama.



Kunci utama



Kunci kandidat yang dipilih untuk mengidentifikasi secara unik setiap kejadian dari tipe entitas.



Jenis entitas mungkin memiliki lebih dari satu kunci kandidat. Untuk tujuan diskusi, pertimbangkan bahwa seorang anggota staf memiliki nomor staf khusus yang ditetapkan perusahaan (stafNo) dan juga Nomor Asuransi Nasional (NIN) unik yang digunakan oleh pemerintah. Oleh karena itu kami memiliki dua kunci kandidat untukStafentitas, salah satunya harus dipilih sebagai primary key.



Pemilihan primary key untuk entitas didasarkan pada pertimbangan panjang atribut, jumlah minimal atribut yang dibutuhkan, dan kepastian keunikan di masa mendatang. Misalnya, nomor staf yang ditentukan perusahaan berisi maksimal lima karakter (misalnya, SG14), dan NIN berisi maksimal sembilan karakter (misalnya, WL220658D). Oleh karena itu, kami memilihstafNosebagai kunci utama dariStaftipe entitas danNINkemudian disebut sebagaikunci alternatif.



|



416



Bab 12Pemodelan Entitas-Hubungan Kunci komposit



Kunci kandidat yang terdiri dari dua atau lebih atribut.



Dalam beberapa kasus, kunci dari tipe entitas terdiri dari beberapa atribut yang nilainya unik untuk setiap kejadian entitas tetapi tidak secara terpisah. Misalnya, pertimbangkan entitas yang disebutIklandenganpropertiNo(nomor properti), koranName,tanggalIklan, Danbiayaatribut. Banyak properti diiklankan di banyak surat kabar pada tanggal tertentu. Untuk secara unik mengidentifikasi setiap kejadian dari



Iklantipe



entitas membutuhkan nilai untukpropertiNo,koranName, DantanggalIklan



atribut. Dengan demikian,Iklantipe entitas memiliki kunci utama komposit yang terdiri dari propertiNo,koranName,



DantanggalIklanatribut.



Representasi diagram atribut Jika tipe entitas akan ditampilkan dengan atributnya, kita membagi persegi panjang yang mewakili entitas menjadi dua. Bagian atas persegi panjang menampilkan nama entitas dan bagian bawah menampilkan nama atribut. Sebagai contoh, Gambar 12.11 menunjukkan diagram ER untukStafDanCabangtipe entitas dan atribut terkaitnya. Atribut pertama yang dicantumkan adalah primary key untuk tipe entitas, jika diketahui. Nama atribut primary key dapat diberi label dengan tag {PK}. Di UML, nama atribut ditampilkan dengan huruf pertama dalam huruf kecil dan, jika nama memiliki lebih dari satu kata, dengan huruf pertama dari setiap kata berikutnya dalam huruf besar (misalnya,alamatDantelNo). Tag tambahan yang dapat digunakan termasuk kunci primer parsial {PPK} saat atribut merupakan bagian dari kunci primer gabungan, dan kunci alternatif {AK}. Seperti yang ditunjukkan pada Gambar 12.11, primary key dariStaf



tipe entitas adalahstafNoatribut dan kunci utama dariCabangtipe entitas adalah cabangNoatribut.



Gambar 12.11Representasi diagram entitas Staf dan Cabang serta atributnya.



12.4Jenis Entitas Kuat dan Lemah Untuk beberapa sistem basis data yang lebih sederhana, dimungkinkan untuk menampilkan semua atribut untuk setiap tipe entitas dalam diagram ER. Namun, untuk sistem database yang lebih kompleks, kami hanya menampilkan atribut, atau atribut, yang membentuk kunci utama dari setiap tipe entitas. Saat hanya atribut primary key yang ditampilkan dalam diagram ER, kita dapat menghilangkan tag {PK}.



Untuk atribut bernilai tunggal yang sederhana, tidak perlu menggunakan tag, jadi kami cukup menampilkan nama atribut dalam daftar di bawah nama entitas. Untuk atribut gabungan, kami mencantumkan nama atribut gabungan diikuti di bawah dan menjorok ke kanan dengan nama atribut komponen sederhananya. Misalnya pada Gambar 12.11 atribut kompositalamatdariCabangentitas ditampilkan, diikuti di bawah ini dengan nama atribut komponennya,jalan,kota, DanKode Pos. Untuk atribut multinilai, kami memberi label nama atribut dengan indikasi rentang nilai yang tersedia untuk atribut tersebut. Misalnya, jika kita memberi label padatelNoatribut dengan rentang [1..*], ini berarti bahwa nilai untuktelNo atribut adalah satu atau lebih. Jika kita mengetahui jumlah nilai maksimum yang tepat, kita dapat memberi label atribut dengan rentang yang tepat. Misalnya, jikatelNoatribut menampung satu hingga maksimal tiga nilai, kita dapat memberi label atribut dengan [1..3].



Untuk atribut turunan, kami awali nama atribut dengan "/". Misalnya, atribut turunan dariStaftipe entitas ditunjukkan pada Gambar 12.11 sebagai/totalStaff.



12.4Jenis Entitas Kuat dan Lemah Kita dapat mengklasifikasikan tipe entitas sebagai kuat atau lemah.



Kuat tipe entitas



Jenis entitas yangbukaneksistensi-tergantung pada beberapa jenis entitas lain.



Suatu tipe entitas disebut kuat jika keberadaannya tidak bergantung pada keberadaan tipe entitas lain. Contoh entitas kuat ditunjukkan pada Gambar 12.1 dan termasukStaf,Cabang ,PropertyForRent, DanKlienentitas. Karakteristik dari tipe entitas yang kuat adalah bahwa setiap kemunculan entitas dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas tersebut. Misalnya, kami dapat secara unik mengidentifikasi setiap anggota staf menggunakanstafNoatribut, yang merupakan kunci utama untukStaftipe entitas.



Lemah



tipe entitas



Tipe entitas yang keberadaannya bergantung pada beberapa tipe entitas lain.



Tipe entitas yang lemah bergantung pada keberadaan tipe entitas lain. Contoh tipe entitas lemah disebutPreferensiditunjukkan pada Gambar 12.12. Karakteristik entitas yang lemah adalah bahwa setiap kejadian entitas tidak dapat diidentifikasi secara unik hanya dengan menggunakan atribut yang terkait dengan tipe entitas tersebut. Sebagai contoh, perhatikan bahwa tidak ada primary key untukPreferensikesatuan. Ini berarti bahwa kita tidak dapat mengidentifikasi setiap kejadian dariPreferensitipe entitas hanya menggunakan atribut ini



|417



|



418



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.12Tipe entitas kuat disebut Klien dan tipe entitas lemah disebut Preferensi.



kesatuan. Kami dapat secara unik mengidentifikasi setiap preferensi hanya melalui hubungan yang dimiliki preferensi dengan klien yang dapat diidentifikasi secara unik menggunakan kunci utama untukKlienjenis entitas, yaituklienNo.Dalam contoh ini,Preferensi entitas digambarkan memiliki ketergantungan keberadaan untukKlienentitas, yang disebut sebagai entitas pemilik. Tipe entitas yang lemah terkadang disebut sebagaianak, tanggungan,ataubawahanentitas dan tipe entitas yang kuat sebagaiorang tua, pemilik,ataudominanentitas.



12.5Atribut pada Relasi Seperti yang kami sebutkan di Bagian 12.3, atribut juga dapat ditugaskan ke hubungan. Misalnya, perhatikan hubungannyaBeriklan, yang mengasosiasikanKoranDan PropertyForRenttipe entitas seperti yang ditunjukkan pada Gambar 12.1. Untuk mencatat tanggal properti diiklankan dan biayanya, kami mengaitkan informasi ini denganBeriklan hubungan sebagai atribut disebuttanggalIklanDanbiaya, bukan denganKoranatau PropertyForRententitas.



Representasi diagram atribut pada hubungan Kami mewakili atribut yang terkait dengan tipe hubungan menggunakan simbol yang sama dengan tipe entitas. Namun, untuk membedakan antara relasi dengan atribut dan entitas, persegi panjang yang mewakili atribut dikaitkan dengan relasi menggunakan garis putus-putus. Sebagai contoh, Gambar 12.13 menunjukkan Beriklanhubungannya dengan atributtanggalIklanDanbiaya. Contoh kedua yang ditunjukkan pada Gambar 12.1 adalahMengelolahubungan denganmgrStartDateDanbonus



atribut.



Kehadiran satu atau lebih atribut yang ditetapkan ke suatu hubungan dapat mengindikasikan bahwa hubungan tersebut menyembunyikan jenis entitas yang tidak teridentifikasi. Misalnya keberadaan daritanggalIklanDanbiayaatribut padaBeriklanhubungan menunjukkan adanya entitas yang disebutIklan.



12.6Kendala Struktural



|419 Gambar 12.13



Contoh dari sebuah hubungan



diteleponBeriklan



dengan atribut dateAdvert dan biaya.



12.6Kendala Struktural Kami sekarang memeriksa kendala yang mungkin ditempatkan pada tipe entitas yang berpartisipasi dalam suatu hubungan. Batasan harus mencerminkan batasan pada hubungan seperti yang dirasakan di "dunia nyata". Contoh kendala tersebut mencakup persyaratan bahwa properti yang disewakan harus memiliki pemilik dan setiap cabang harus memiliki staf. Jenis utama kendala pada hubungan disebut beragam.



Beragam



Jumlah (atau rentang) kemungkinan kejadian dari tipe entitas yang mungkin berhubungan dengan kejadian tunggal dari tipe entitas terkait melalui hubungan tertentu.



Multiplisitas membatasi cara entitas terkait. Ini adalah representasi dari kebijakan (atau aturan bisnis) yang ditetapkan oleh pengguna atau perusahaan. Memastikan bahwa semua sesuaikendaladiidentifikasi dan diwakili adalah bagian penting dari pemodelan suatu perusahaan. Seperti yang kami sebutkan sebelumnya, derajat yang paling umum untuk hubungan adalah biner. Hubungan biner umumnya disebut sebagai satu-ke-satu (1:1), satu-ke-banyak (1:*), atau banyak-ke-banyak (*:*). Kami memeriksa ketiga jenis hubungan ini menggunakan batasan integritas berikut: • seorang anggota staf mengelola sebuah cabang (1:1); • seorang anggota staf mengawasi properti yang disewakan (1:*); • surat kabar mengiklankan properti untuk disewakan (*:*). Pada Bagian 12.6.1, 12.6.2, dan 12.6.3 kami mendemonstrasikan cara menentukan multiplisitas untuk setiap kendala ini dan menunjukkan cara merepresentasikan masing-masing dalam diagram ER. Pada Bagian 12.6.4 kita mengkaji multiplisitas untuk hubungan derajat lebih tinggi dari biner.



Penting untuk dicatat bahwa tidak semua batasan integritas dapat dengan mudah direpresentasikan dalam model ER. Misalnya, persyaratan bahwa seorang anggota staf menerima hari libur tambahan untuk setiap tahun bekerja di perusahaan mungkin sulit untuk direpresentasikan dalam model ER.



|



420



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.14(a) Jaring semantik menunjukkan dua



kejadian dari



stafMengelola Hubungan cabang jenis.



12.6.1 Hubungan Satu-ke-Satu (1:1). Pertimbangkan hubungannyaMengelola, yang berhubungan denganStafDanCabangtipe entitas. Gambar 12.14(a) menampilkan dua kemunculan dariMengelolatipe hubungan (dilambangkan rl dan r2) menggunakan jaring semantik. Setiap hubungan (rN) mewakili hubungan antara satuStafkejadian entitas dan tunggalCabangterjadinya entitas. Kami mewakili setiap kejadian entitas menggunakan nilai untuk atribut kunci utama dari



ituStafDanCabangentitas, yaitustafNoDancabangNo.



Menentukan multiplisitas Menentukan multiplisitas biasanya membutuhkan pemeriksaan hubungan yang tepat antara data yang diberikan dalam kendala perusahaan menggunakan data sampel. Data sampel dapat diperoleh dengan memeriksa formulir atau laporan yang diisi dan, jika mungkin, dari diskusi dengan pengguna. Namun, penting untuk ditekankan bahwa untuk mencapai kesimpulan yang tepat tentang kendala mensyaratkan bahwa data sampel yang diperiksa atau didiskusikan merupakan representasi sebenarnya dari semua data yang dimodelkan.



Pada Gambar 12.14(a) kita melihatnyastafNoSG5 mengelolacabangNoB003 danstafNo SL21 mengelolacabangNoBOO5, tapistafNoSG37 tidak mengelola cabang mana pun. Dengan kata lain, seorang anggota staf dapat mengelolanol atau satucabang dan setiap cabang dikelola olehsatuanggota staf. Karena ada maksimal satu cabang untuk setiap anggota staf yang terlibat dalam hubungan ini dan maksimal satu anggota staf untuk setiap cabang, kami menyebut jenis hubungan ini sebagaisatu-ke-satu,yang biasanya kita singkat sebagai (1:1).



Gambar 12.14(b)



Banyaknya stafMengelola



Cabang satu-ke-satu



(1:1) hubungan.



12.6Kendala Struktural



|421



Representasi diagram hubungan 1:1 Diagram ER dariStafMengelolaCabanghubungan ditunjukkan pada Gambar 12.14(b). Untuk mewakili bahwa seorang anggota staf dapat mengelolanol atau satucabang, kami menempatkan "0..1" di sampingCabangkesatuan. Untuk menyatakan bahwa cabang selalu memilikisatumanajer, kami menempatkan "1..1" di sampingStafkesatuan. (Perhatikan bahwa untuk hubungan 1:1, kami dapat memilih nama hubungan yang masuk akal untuk kedua arah.)



12.6.2 Relasi Satu ke Banyak (1:*). Pertimbangkan hubungannyaMengawasi, yang berhubungan denganStafDanPropertyForRenttipe entitas. Gambar 12.15(a) menampilkan tiga kemunculan dariStafMengawasiPropertyForRent



tipe hubungan (dilambangkan rl, r2, dan r3) menggunakan jaringan semantik. Setiap hubungan (rN) mewakili hubungan antara satuStafkejadian entitas dan tunggal PropertyForRentterjadinya entitas. Kami mewakili setiap kejadian entitas menggunakan nilai untuk atribut kunci utama dariStafDanPropertyForRententitas, yaitu stafNoDanpropertiNo.



Menentukan multiplisitas Pada Gambar 12.15(a) kita melihatnyastafNoSG37 mengawasipropertiNoPG21 dan PG36, dan stafNoSA9 mengawasipropertiNoPA14 tapistafNoSG5 tidak mengawasi properti apa pun untuk disewa danpropertiNoPG4 tidak diawasi oleh anggota staf manapun. Singkatnya, seorang anggota staf dapat mengawasinol atau lebihproperti untuk disewakan dan properti untuk disewakan diawasi olehnol atau satuanggota staf. Oleh karena itu, untuk anggota staf yang berpartisipasi dalam hubungan ini adabanyakproperti untuk disewakan, dan untuk properti yang berpartisipasi dalam hubungan ini ada maksimalsatuanggota staf. Kami menyebut jenis hubungan ini sebagaisatu-ke-banyak,yang biasa kita singkat dengan (1:*). Representasi diagram dari hubungan 1:*Diagram ER dariStaf MengawasiPropertyForRent hubungan ditunjukkan pada Gambar 12.15(b). Untuk mewakili bahwa seorang anggota staf dapat mengawasinol atau lebihproperti untuk disewakan, kami menempatkan "0..*" di sampingPropertyForRentkesatuan. Mewakili bahwa setiap properti yang disewakan diawasi olehnol atau satuanggota staf, kami menempatkan "0..1" di sampingStafkesatuan. (Perhatikan bahwa dengan hubungan 1:*, kami memilih nama hubungan yang masuk akal dalam arah 1:*.) Gambar 12.15(a) Jaring semantik menunjukkan tiga



kejadian dari



stafMengawasi PropertyForRent



tipe hubungan.



|



422



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.15(b)



Banyaknya stafMengawasi PropertyForRent



satu-ke-banyak (1:*)



tipe hubungan.



Jika kita mengetahui nilai minimum dan maksimum aktual untuk multiplisitas, kita dapat menampilkannya sebagai gantinya. Misalnya, jika seorang anggota staf mengawasi minimal nol dan maksimal 100 properti untuk disewakan, kita dapat mengganti “0..*” dengan “0..100.”



12.6.3 Relasi Banyak ke Banyak (*:*). Pertimbangkan hubungannyaBeriklan, yang berhubungan denganKoranDanPropertyForRent



tipe entitas. Gambar 12.16(a) menampilkan empat kejadian dariBeriklanhubungan (dilambangkan rl, r2, r3, dan r4) menggunakan jaringan semantik. Setiap hubungan (rN) mewakili hubungan antara satuKorankejadian entitas dan tunggal PropertyForRentterjadinya entitas. Kami mewakili setiap kejadian entitas menggunakan nilai untuk atribut kunci utama dariKoranDanPropertyForRentkesatuan jenis, yaitukoranNameDanpropertiNo.



Menentukan multiplisitas Pada Gambar 12.16(a) kita melihat bahwaHarian GlasgowmengiklankanpropertiNoPG21 dan PG36,Berita Baratjuga mengiklankanpropertiNoPG36 danAberdeen Express mengiklankan propertiNoPA14. Namun,propertiNoPG4 tidak diiklankan di koran manapun. Dengan kata lain, satuiklan surat kabarsatu atau lebihproperti untuk disewakan dansatuproperti untuk disewa diiklankan dinol atau lebihsurat kabar. Oleh karena itu, untuk Gambar 12.16(a) Jaring semantik menunjukkan empat



kejadian dari



Koran Beriklan



PropertyForRent



tipe hubungan.



12.6Kendala Struktural



|423



Gambar 12.16(b)



Banyaknya Koran Beriklan



PropertyForRent banyak ke banyak



(*:*) hubungan.



koran adabanyakproperti untuk disewa, dan untuk setiap properti untuk disewa yang berpartisipasi dalam hubungan ini adabanyaksurat kabar. Kami menyebut jenis hubungan ini sebagai banyak-ke-banyak, yang biasanya kami singkat sebagai (*:*).



Representasi diagram dari hubungan *:* Diagram ER dariKoranBeriklanPropertyForRenthubungan ditunjukkan pada Gambar 12.16(b). Untuk menyatakan bahwa setiap surat kabar dapat beriklansatu atau lebihproperti untuk disewakan, kami menempatkan "1..*" di sampingPropertyForRenttipe entitas. Untuk menyatakan bahwa setiap properti yang disewakan dapat diiklankan olehnol atau lebihsurat kabar, kami menempatkan "0..*" di sampingKorankesatuan. (Perhatikan bahwa untuk hubungan *:*, kita dapat memilih nama hubungan yang masuk akal di kedua arah.)



12.6.4 Multiplisitas untuk Hubungan yang Kompleks Multiplisitas untuk hubungan kompleks—yaitu, yang lebih tinggi dari biner—sedikit lebih kompleks.



Beragam (kompleks



Jumlah (atau rentang) kemungkinan kejadian dari tipe entitas dalam sebuahNhubungan -ary ketika yang lain (N–1) nilai tetap.



hubungan)



Secara umum, multiplisitas untukNHubungan -ary mewakili jumlah potensi kejadian entitas dalam hubungan ketika (N–1) nilai ditetapkan untuk tipe entitas lain yang berpartisipasi. Sebagai contoh, multiplisitas untuk relasi ternary merepresentasikan rentang potensial kemunculan entitas dari entitas tertentu dalam relasi ketika dua nilai lainnya yang mewakili dua entitas lainnya adalah tetap. Pertimbangkan ternerRegisterhubungan antaraStaf,Cabang, DanKlien ditunjukkan pada Gambar 12.7. Gambar 12.17(a) menampilkan lima kejadian dari Registerhubungan (dilambangkan rl ke r5) menggunakan jaring semantik. Setiap hubungan (rN) mewakili asosiasi tunggalStafkejadian entitas, tunggalCabang kejadian entitas, dan tunggalKlienterjadinya entitas. Kami mewakili setiap kejadian entitas menggunakan nilai untuk atribut kunci utama dariStaf,Cabang, Dan Klienentitas, yaitustafNo,cabangNo, DanklienNo. Pada Gambar 12.17(a) kita memeriksa Registerhubungan ketika nilai-nilai untukStafDanCabangentitas adalah tetap.



|



424



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.17(a) Jaring semantik menunjukkan lima



kejadian dari ternerRegister hubungan dengan nilai untuk tipe entitas Staf dan Cabang tetap.



Menentukan multiplisitas Pada Gambar 12.17(a) denganNo.staf/No.Cabangnilai tetap adanol atau lebihklienNo nilai-nilai. Misalnya,stafNoSG37 dicabangNoregister B003klienNoCR56 dan CR74, dan stafNoSG14 dicabangNoregister B003klienNoCR62, CR84, dan CR91. Namun, SG5 di cabangNoB003 tidak mendaftarkan klien. Dengan kata lain, ketikastafNo DancabangNonilai-nilai ditetapkan sesuaiklienNonilai-nilai adalahnol atau lebih. Oleh karena itu, banyaknya dariRegisterhubungan dari sudut pandang StafDanCabangentitas adalah 0..*, yang direpresentasikan dalam diagram ER dengan menempatkan



0..* di sampingKlienkesatuan.



Jika kita ulangi tes ini kita menemukan bahwa multiplisitas kapanStaf/Kliennilai-nilai tetap adalah 1..1, yang ditempatkan di sampingCabangentitas, danKlien/Cabangnilai-nilai tetap adalah 1..1, yang ditempatkan di sampingStafkesatuan. Diagram ER dari ternaryRegister hubungan yang menunjukkan multiplisitas ada pada Gambar 12.17(b).



Rangkuman dari cara-cara yang mungkin untuk merepresentasikan batasan multiplisitas bersama dengan deskripsi makna ditunjukkan pada Tabel 12.1.



12.6.5 Kendala Kardinalitas dan Partisipasi Multiplisitas sebenarnya terdiri dari dua kendala terpisah yang dikenal sebagai kardinalitas dan partisipasi.



Kardinalitas



Gambar 12.17(b)



Multiplisitas dari terner Register



hubungan.



Menjelaskan jumlah maksimum kemungkinan kejadian relasi untuk entitas yang berpartisipasi dalam tipe relasi tertentu.



12.6Kendala Struktural



|425



TABEL 12.1Ringkasan cara untuk merepresentasikan kendala multiplisitas.



CARA ALTERNATIF UNTUK MENYATAKAN BANYAK KENDALA



ARTI



0..1



Nol atau satu kejadian entitas



1..1 (atau hanya 1)



Tepat satu kejadian entitas



0..* (atau hanya *)



Nol atau banyak kejadian entitas



1..*



Satu atau banyak kejadian entitas



5..10



Minimal 5 hingga maksimal 10 kejadian entitas



0, 3, 6–8



Nol atau tiga atau enam, tujuh, atau delapan kejadian entitas



Kardinalitas relasi biner adalah apa yang sebelumnya kita sebut sebagai satu ke satu (1:1), satu ke banyak (1:*), dan banyak ke banyak (*:*). Kardinalitas suatu hubungan muncul sebagaimaksimumnilai untuk rentang multiplisitas di kedua sisi hubungan. Misalnya,Mengelolahubungan yang ditunjukkan pada Gambar 12.18 memiliki kardinalitas satu-ke-satu (1:1), dan ini diwakili oleh rentang multiplisitas dengan nilai maksimum 1 di kedua sisi hubungan. Partisipasi



Menentukan apakah semua atau hanya beberapa kejadian entitas berpartisipasi dalam suatu hubungan.



Batasan partisipasi mewakili apakah semua kejadian entitas terlibat dalam hubungan tertentu (disebut sebagaiwajibpartisipasi) atau hanya beberapa (disebut sebagaiopsionalpartisipasi). Partisipasi entitas dalam a Gambar 12.18



Beragam



digambarkan sebagai



kardinalitas dan



partisipasi kendala untuk



stafMengelola Cabang (1:1)



hubungan.



|



426



Bab 12Pemodelan Entitas-Hubungan



hubungan muncul sebagaiminimumnilai untuk rentang multiplisitas di kedua sisi hubungan. Partisipasi opsional direpresentasikan sebagai nilai minimum 0, dan partisipasi wajib ditampilkan sebagai nilai minimum 1. Penting untuk dicatat bahwa partisipasi entitas tertentu dalam suatu hubungan diwakili oleh nilai minimum padadi depansisi hubungan; yaitu, nilai minimum untuk multiplisitas di samping entitas terkait. Misalnya, pada Gambar 12.18, partisipasi opsional untuk Stafentitas diMengelolahubungan ditampilkan sebagai nilai minimum 0 untuk multiplisitas di sampingCabangentitas dan partisipasi wajib untukCabangentitas di Mengelolahubungan ditampilkan sebagai nilai minimum 1 untuk multiplisitas di sampingStafkesatuan. Ringkasan konvensi yang diperkenalkan di bagian ini untuk mewakili konsep dasar model ER ditampilkan di sampul depan bagian dalam buku ini.



12.7Masalah dengan Model ER Pada bagian ini kami memeriksa masalah yang mungkin muncul saat membuat model ER. Masalah-masalah ini disebut sebagaijebakan koneksi, dan biasanya terjadi karena salah tafsir makna hubungan tertentu (Howe, 1989). Kami memeriksa dua jenis jebakan koneksi utama, yang disebutperangkap kipasDanperangkap jurang, dan mengilustrasikan bagaimana mengidentifikasi dan menyelesaikan masalah seperti itu dalam model ER. Secara umum, untuk mengidentifikasi perangkap koneksi, kita harus memastikan bahwa makna dari suatu hubungan dipahami sepenuhnya dan didefinisikan dengan jelas. Jika kita tidak memahami hubungan tersebut, kita dapat membuat model yang bukan representasi sebenarnya dari "dunia nyata".



12.7.1 Perangkap Kipas



Perangkap kipas



Di mana model mewakili hubungan antara tipe entitas, tetapi jalur antara kejadian entitas tertentu bersifat ambigu.



Perangkap penggemar mungkin ada di mana dua atau lebih hubungan 1:* menyebar dari entitas yang sama. Potensi fan trap diilustrasikan pada Gambar 12.19(a), yang menunjukkan dua hubungan 1:* (MemilikiDanBeroperasi)berasal dari entitas yang sama disebutDivisi. Model ini mewakili fakta bahwa satu divisi beroperasisatu atau lebih cabang dan memiliki satu atau lebihstaf. Namun, masalah muncul ketika kita ingin mengetahui anggota staf mana yang bekerja di cabang tertentu. Untuk menghargai masalah, kami memeriksa beberapa kejadian dariMemilikiDanBeroperasihubungan menggunakan nilai untuk atribut primary key dariStaf,Divisi, DanCabangtipe entitas, seperti yang ditunjukkan pada Gambar 12.19(b). Jika kami mencoba menjawab pertanyaan: "Di cabang mana staf nomor SG37 bekerja?" kami tidak dapat memberikan jawaban spesifik berdasarkan struktur saat ini. Kami hanya dapat menentukan staf nomor SG37 yang bekerja di Cabang B003atauB007. Itu



Gambar 12.19(a)Contoh perangkap kipas angin.



|427



12.7Masalah dengan Model ER



Gambar 12.19(b)Jaringan semantik model ER ditunjukkan pada Gambar 12.19(a). ketidakmampuan untuk menjawab pertanyaan ini secara khusus adalah hasil dari jebakan penggemar yang terkait dengan representasi yang salah dari hubungan yang benar antaraStaf,Divisi, Dan Cabangentitas. Kami mengatasi perangkap kipas ini dengan merestrukturisasi model ER asli untuk



mewakili hubungan yang benar antara entitas ini, seperti yang ditunjukkan pada Gambar 12.20(a). Jika kita sekarang memeriksa kejadian dariBeroperasiDanMemilikihubungan, seperti yang ditunjukkan pada Gambar 12.20(b), kita sekarang berada dalam posisi untuk menjawab jenis pertanyaan yang diajukan sebelumnya. Dari model jaringan semantik ini dapat ditentukan bahwa staf nomor SG37 bekerja di cabang nomor B003 yang merupakan bagian dari divisi Dl.



Gambar 12.20(a)Model ER yang ditunjukkan pada Gambar 12.19(a) direstrukturisasi untuk menghilangkan perangkap kipas.



Gambar 12.20(b)Jaringan semantik model ER ditunjukkan pada Gambar 12.20(a).



|



428



Bab 12Pemodelan Entitas-Hubungan



Gambar 12.21(a)Contoh perangkap jurang.



12.7.2 Perangkap Jurang Jurang perangkap



Dimana model menyarankan adanya hubungan antara tipe entitas, tetapi jalur tidak ada antara kejadian entitas tertentu.



Jebakan jurang dapat terjadi jika ada satu atau lebih hubungan dengan multiplisitas minimum nol (yaitu, partisipasi opsional) yang membentuk bagian jalur antara entitas terkait. Jebakan jurang potensial diilustrasikan pada Gambar 12.21(a), yang menunjukkan hubungan antaraCabang,Staf, DanPropertyForRententitas. Model ini mewakili fakta yang dimiliki oleh satu cabangsatu atau lebihstaf yang mengawasinol atau lebihproperti untuk disewakan. Kami juga mencatat bahwa tidak semua staf mengawasi properti, dan tidak semua properti diawasi oleh anggota staf. Masalah muncul ketika kita ingin mengetahui properti mana yang tersedia di setiap cabang. Untuk menghargai masalah, kami memeriksa beberapa kejadian dariMemilikiDanMengawasi hubungan menggunakan nilai untuk atribut primary key dariCabang,Staf, DanPropertyForRent tipe entitas, seperti yang ditunjukkan pada Gambar 12.21(b).



Jika kami mencoba menjawab pertanyaan: "Di cabang mana properti nomor PA14 tersedia?" kami tidak dapat menjawab pertanyaan ini, karena properti ini belum dialokasikan untuk anggota staf yang bekerja di cabang. Ketidakmampuan untuk menjawab pertanyaan ini dianggap sebagai hilangnya informasi (seperti yang kita ketahui bahwa properti harus tersedia di cabang), dan merupakan hasil dari jebakan jurang. Keragaman keduanyaStafDanPropertyForRententitas diMengawasiRelasi memiliki nilai minimum nol, yang berarti bahwa beberapa properti tidak dapat dikaitkan dengan cabang melalui anggota staf. Oleh karena itu, untuk mengatasi masalah ini, kita perlu mengidentifikasi hubungan yang hilang, yang dalam hal ini adalahPenawaranhubungan



Gambar 12.21(b)Jaringan semantik model ER ditunjukkan pada Gambar 12.21(a).



|429



12.7Masalah dengan Model ER



Gambar 12.22(a)Model ER yang ditunjukkan pada Gambar 12.21(a) direstrukturisasi untuk menghilangkan jebakan jurang.



diantaraCabangDanPropertyForRententitas. Model ER yang ditunjukkan pada Gambar 12.22(a) merepresentasikan asosiasi sebenarnya antara entitas-entitas ini. Model ini memastikan bahwa setiap saat, properti yang terkait dengan setiap cabang diketahui, termasuk properti yang belum dialokasikan ke anggota staf. Jika kita sekarang memeriksa kejadian dariMemiliki,Mengawasi, DanPenawarantipe hubungan, seperti yang ditunjukkan pada Gambar 12.22(b), kita sekarang dapat menentukan bahwa properti nomor PA14 tersedia di nomor cabang B007.



Gambar 12.22(b)Jaringan semantik model ER ditunjukkan pada Gambar 12.22(a).



|



430



Bab 12Pemodelan Entitas-Hubungan



Ringkasan Bab • Sebuahtipe entitasadalah sekelompok objek dengan properti yang sama, yang diidentifikasi oleh perusahaan sebagai keberadaan independen. Sebuahterjadinya entitasadalah objek yang dapat diidentifikasi secara unik dari tipe entitas.



• Atipe hubunganadalah sekumpulan asosiasi yang bermakna di antara tipe-tipe entitas. Aterjadinya hubunganadalah asosiasi yang dapat diidentifikasi secara unik, yang mencakup satu kejadian dari setiap jenis entitas yang berpartisipasi.



• Ituderajat tipe hubunganadalah jumlah tipe entitas yang berpartisipasi dalam suatu relasi. • Ahubungan rekursifadalah jenis hubungan di manasamatipe entitas berpartisipasi lebih dari sekali berbeda peran.



• Sebuahatributadalah properti dari entitas atau tipe relasi. •



Sebuahdomain atributadalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.



• Aatribut sederhanaterdiri dari satu komponen dengan eksistensi independen. • Aatribut kompositterdiri dari beberapa komponen yang masing-masing memiliki keberadaan yang independen. • Aatribut bernilai tunggalmemegang nilai tunggal untuk setiap kemunculan tipe entitas. • Aatribut multi-nilaimemegang beberapa nilai untuk setiap kemunculan tipe entitas. • Aatribut turunanmerepresentasikan nilai yang dapat diturunkan dari nilai atribut terkait atau kumpulan atribut, tidak harus dalam entitas yang sama.



•



Akunci kandidatadalah sekumpulan minimal atribut yang secara unik mengidentifikasi setiap kejadian dari sebuah tipe entitas.



• Akunci utamaadalah kunci kandidat yang dipilih untuk mengidentifikasi secara unik setiap kejadian dari tipe entitas. • Akunci kompositadalah kunci kandidat yang terdiri dari dua atau lebih atribut. •



Atipe entitas yang kuatadalahbukaneksistensi-tergantung pada beberapa jenis entitas lain. Atipe entitas yang lemahkeberadaannya tergantung pada beberapa jenis entitas lain.



• Beragamadalah jumlah (atau rentang) kemungkinan kejadian dari tipe entitas yang mungkin berhubungan dengan kejadian tunggal dari tipe entitas terkait melalui hubungan tertentu.



• Multiplisitas untuk hubungan yang kompleksadalah jumlah (atau range) dari kemungkinan kejadian dari sebuah tipe entitas dalam sebuahNhubungan -ary ketika yang lain (N–l) nilai tetap.



• Kardinalitasmenjelaskan jumlah maksimum kemungkinan kejadian relasi untuk entitas yang berpartisipasi dalam tipe relasi tertentu.



• Partisipasimenentukan apakah semua atau hanya beberapa kejadian entitas berpartisipasi dalam hubungan tertentu. • Aperangkap kipasada di mana model mewakili hubungan antara tipe entitas, tetapi jalur antara kejadian entitas tertentu bersifat ambigu.



• Aperangkap jurangada di mana model menyarankan adanya hubungan antara tipe entitas, tetapi jalur tidak ada antara kejadian entitas tertentu.



Tinjau Pertanyaan 12.1Mengapa model ER dianggap sebagai pendekatan top-down? Jelaskan empat komponen dasar model ER. 12.2Jelaskan jenis hubungan apa yang diwakili dalam model ER dan berikan contoh hubungan unary, binary, ternary,



dan quaternary.



|431



Latihan



12.3Model ER menggunakan sejumlah notasi dan tag untuk mewakili konsep yang berbeda. Buat garis besar bagaimana komponen



ER dasar direpresentasikan dalam diagram ER. 12.4Jelaskan apa yang diwakili oleh kendala multiplisitas untuk tipe hubungan.



12.5Apa kendala integritas dan bagaimana multiplisitas memodelkan kendala ini?



12.6Bagaimana multiplisitas mewakili kardinalitas dan kendala partisipasi pada tipe hubungan? 12.7Berikan contoh tipe hubungan dengan atribut. 12.8Bedakan antara model Entity—Relationship dan diagram Entity—Relationship. 12.9Jelaskan



bagaimana perangkap kipas dan jurang dapat terjadi dalam model ER dan bagaimana hal itu dapat diatasi.



Latihan 12.10Buat model ER untuk setiap deskripsi berikut: (A)Setiap perusahaan mengoperasikan empat departemen, dan setiap departemen dimiliki oleh satu perusahaan. (B)Setiap departemen pada bagian (a) mempekerjakan satu atau lebih karyawan, dan setiap karyawan bekerja untuk satu departemen. (C)Setiap karyawan pada bagian (b) dapat memiliki atau tidak memiliki satu tanggungan atau lebih, dan setiap tanggungan



dimiliki oleh satu karyawan. (D)Setiap karyawan di bagian (c) mungkin memiliki atau tidak memiliki riwayat pekerjaan. (e)Mewakili semua model ER yang dijelaskan dalam (a), (b), (c), dan (d) sebagai model ER tunggal.



12.11Asumsikan Anda telah dikontrak oleh universitas untuk mengembangkan sistem basis data untuk melacak pendaftaran



siswa dan catatan akomodasi. Kursus universitas ditawarkan oleh fakultas. Tergantung mahasiswanya IQ, tidak ada batasan berapa banyak kursus yang dapat diikuti siswa. Fakultas tidak bertanggung jawab atas akomodasi siswa. Universitas memiliki sejumlah asrama dan setiap mahasiswa diberikan kunci kamar bersama setelah pendaftaran. Setiap kamar memiliki furnitur yang melekat padanya. (A)Identifikasi tipe entitas utama untuk proyek tersebut.



(B)Identifikasi jenis hubungan utama dan tentukan multiplisitas untuk setiap hubungan. Nyatakan asumsi apa pun yang Anda



buat tentang data tersebut. (C)Dengan menggunakan jawaban Anda untuk (a) dan (b), gambarkan diagram ER tunggal untuk mewakili persyaratan data untuk proyek tersebut.



12.12Baca studi kasus berikut, yang menjelaskan persyaratan data untuk perusahaan persewaan DVD. Perusahaan persewaan



DVD memiliki beberapa cabang di seluruh Amerika Serikat. Data yang disimpan di setiap cabang adalah alamat cabang yang terdiri dari jalan, kota, provinsi, dan kode pos, serta nomor telepon. Setiap cabang diberi nomor cabang, yang unik di seluruh perusahaan. Setiap cabang dialokasikan staf, yang mencakup seorang Manajer. Manajer bertanggung jawab untuk menjalankan cabang tertentu sehari-hari. Data yang dimiliki oleh seorang anggota staf adalah nama, jabatan, dan gajinya. Setiap anggota staf diberi nomor staf, yang unik di seluruh perusahaan. Setiap cabang memiliki stok DVD. Data yang dimiliki DVD adalah nomor katalog, nomor DVD, judul, kategori, persewaan harian, biaya, status, dan nama pemain utama dan sutradara. Nomor katalog secara unik mengidentifikasi setiap DVD. Namun, dalam kebanyakan kasus, ada beberapa salinan dari setiap DVD di cabang, dan masing-masing salinan diidentifikasi menggunakan nomor DVD. Sebuah DVD diberikan kategori seperti Aksi, Dewasa, Anak-anak, Drama, Horor, atau Fiksi Ilmiah. Status menunjukkan apakah salinan DVD tertentu tersedia untuk disewa. Sebelum meminjam DVD dari perusahaan, pelanggan terlebih dahulu harus mendaftar sebagai anggota cabang setempat. Data yang dimiliki oleh seorang anggota adalah nama depan dan belakang, alamat, dan tanggal pendaftaran anggota di suatu cabang. Setiap anggota diberi nomor anggota, yang unik di semua cabang perusahaan. Setelah terdaftar, seorang anggota bebas untuk menyewa DVD, hingga maksimum sepuluh DVD sekaligus. Data yang dimiliki pada setiap DVD yang disewa adalah nomor rental, nama lengkap dan nomor member, nomor DVD, judul, dan sewa harian, dan tanggal DVD disewakan dan dikembalikan. Nomor DVD unik di seluruh perusahaan. (A)Identifikasi jenis entitas utama dari perusahaan persewaan DVD.



(B)Identifikasi tipe hubungan utama antara tipe entitas yang dijelaskan di bagian (a) dan wakili setiap hubungan



sebagai diagram ER.



|



432



Bab 12Pemodelan Entitas-Hubungan



(C)Tentukan kendala multiplisitas untuk setiap hubungan yang dijelaskan di bagian (b). Sajikan multiplisitas untuk



setiap hubungan dalam diagram ER yang dibuat di bagian (b). (D)Identifikasi atribut dan kaitkan dengan tipe entitas atau relasi. Representasikan setiap atribut dalam diagram ER



yang dibuat di (c). (e)Tentukan kandidat dan atribut primary key untuk setiap tipe entitas (kuat). (F )Dengan menggunakan jawaban Anda untuk bagian (a) hingga (e), cobalah untuk menyajikan persyaratan data perusahaan persewaan DVD sebagai



diagram ER tunggal. Nyatakan asumsi apa pun yang diperlukan untuk mendukung desain Anda.



12.13Buat model ER untuk setiap deskripsi berikut: (A)Sebuah



organisasi besar memiliki beberapa tempat parkir, yang digunakan oleh staf.



(B)Setiap tempat parkir memiliki nama, lokasi, kapasitas, dan jumlah lantai yang unik (bila perlu). (C)Setiap tempat parkir memiliki tempat parkir yang diidentifikasi secara unik menggunakan nomor tempat parkir.



(D)Anggota staf dapat meminta penggunaan satu tempat parkir tunggal. Setiap anggota staf memiliki nomor



unik, nama, nomor ekstensi telepon, dan nomor lisensi kendaraan. (e)Sajikan semua model ER yang dijelaskan di bagian (a), (b), (c), dan (d) sebagai model ER tunggal. Berikan asumsi yang diperlukan



untuk mendukung model Anda. Jawaban akhir untuk latihan ini ditunjukkan pada Gambar 13.11. 12.14Buat model ER untuk mewakili data yang digunakan oleh perpustakaan. Perpustakaan menyediakan buku untuk peminjam. Setiap buku dijelaskan menurut judul, edisi, dan tahun penerbitan, dan diidentifikasi secara unik menggunakan ISBN. Setiap peminjam dijelaskan dengan nama dan alamatnya dan diidentifikasi secara unik menggunakan nomor peminjam. Perpustakaan menyediakan satu atau lebih salinan dari setiap buku dan setiap salinan diidentifikasi secara unik menggunakan nomor salinan, status yang menunjukkan apakah buku tersebut tersedia untuk dipinjamkan, dan jangka waktu peminjaman yang diperbolehkan untuk salinan yang diberikan. Peminjam dapat meminjamkan satu atau banyak buku, dan tanggal setiap buku dipinjamkan dan dikembalikan dicatat. Nomor pinjaman secara unik mengidentifikasi setiap pinjaman buku.



Jawaban untuk latihan ini ditunjukkan pada Gambar 13.12.