Memahami Konsep Logical Database Design Pada Basis Data

Memahami Konsep Logical Database Design Pada Basis Data - Logical database design adalah proses pembuatan suatu model informasi yang digunakan pada perusahan berdasarkan pada model data yang spesifik, tetapi tidak tergantung dari Database Management System (DBMS) yang khusus dan pertimbangan fisik yang lain (Connolly,2002,p441). Melalui artikel ini diharapkan dapat mengetahui dan memahami mengenai logical database design.

image source: logo-designer.co

baca juga: Memahami Metode Conceptual Database Design Pada Basis Data

DBMS adalah software yang memungkinkan pemakai untuk mendefinisi, membuat, memelihara, dan mengontrol akses ke basis data (Connolly,2002,p16).

Fasilitas-fasilitas yang disediakan oleh DBMS antara lain :

1. Memperbolehkan user untuk mendefinisikan basis data.
2. Memperbolehkan user untuk menambah , mengubah, dan menghapus serta mengambil data dari basis data.
3. Menyediakan kontrol akses ke basis data. Seperti security, integrity, concurrency control, recovery control system dan user-accessible catalog.

Langkah kedua : membuat dan memvalidasi local logical data model untuk setiap pandangan. Bertujuan untuk membuat local logical data model dari local conceptual data model yang mempresentasikan pandangan khusus dari perusahaan dan memvalidasi model tersebut untuk menjamin kebenaran strukturnya (dengan menggunakan teknik normalisasi) dan menjamin bahwa model tersebut mendukung kebutuhan transaksi.

Pada perancangan model logical langkah kedua, tahapan-tahapannya adalah :

a. Menghilangkan features yang tidak compatible dengan model relasional (pilihan). Bertujuan untuk menghasilkan model yang kompatibel dengan model relasional. Yaitu dengan :

• Menghilangkan many-to-many (*:*) binary relationship types 
• Menghilangkan many-to-many (*:*) recursive relationship types 
• Menghilangkan complex relationship types 
• Menghilangkan multi-valued attributes 

b. Memperoleh relasi untuk local logical data model.

Bertujuan untuk membuat hubungan logical model yang mewakili entity, relationship dan attribute yang telah didefinisi. Mendeskripsikan komposisi tiap hubungan memakai Database Definition Language (DDL) untuk relasi yang diikuti dengan daftar dari relasi attribute yang mudah lalu mengidentifikasikan primary key dan foreign key dari suatu relasi. Untuk memperoleh relasi untuk local data model, maka diperlukan penjelasan untuk mendeskripsikan struktur yang mungkin dalam data model saat ini.

Bahasa dalam basis data dapat dibedakan menjadi dua bentuk :

- Data Definition Language (DDL)

DDL merupakan bahasa dalam basis data yang memungkinkan pengguna untuk membuat atau menghapus basis data, membuat atau menghapus tabel membuat struktur penyimpanan tabel. Hasil dari kompilasi DDL adalah kumpulan tabel yang disimpan dalam file khusus yang disebut dengan kamus data.

- Data Manipulation Language (DML)

DML merupakan bahasa dalam basis data yang memungkinkan pengguna untuk melakukan manipulasi data pada suatu basis data, seperti menambah, mengubah, menghapus data dari suatu basis data.

Langkah ketiga : Membuat dan memvalidasi global logical data model. Bertujuan untuk menyatukan local logical data model menjadi global logical data model.

Pada perancangan model logikal langkah ketiga, tahapan-tahapannya adalah :

a. Menggabungkan local logical data model menjadi global model
Pada langkah ini, setiap local logical data model menghasilkan E-R diagram, skema relasional, kamus data dan dokumen pendukung yang mendeskripsikan constraints dari model.

Beberapa tugas yang harus dikerjakan adalah sebagai berikut :

• Memeriksa kembali nama dan isi dari entities dari relationships dan candidate key.
• Memeriksa kembali nama dan isi dari relationships/ foreign keys.
• Menggabungkan entities atau hubungan dari local data model.
• Mengikutsertakan (tanpa menggabungkan) entities atau relationships yang unik pada tiap local data model.
• Menggabungkan relationships atau foreingn key dari local data model.
• Mengikutsertakan (tanpa menggabungkan) relationships atau foreign key unik pada tiap local data model.
• Memeriksa untuk entities (hubungan) dan relationships atau foreign key.
• Memeriksa integrity constraints.
• Menggambarkan ER-diagram.
• Melakukan update dokumen.

b. Memvalidasi global logical data model
Bertujuan untuk memvalidasi relasi yang dibuat dari global logical data model dengan teknik normalisasi dan menjamin bahwa model tersebut mendukung kebutuhan transaksi

c. Mengecek pertumbuhan yang akan datang
Bertujuan untuk menentukan apakah ada perubahan yang signifikan seperti keadaan yang tidak terduga dimasa mendatang dan menilai apakah model logikal tersebut dapat menampung atau menyesuaikan perubahan yang terjadi.

d. Melihat kembali global logical data model dengan pengguna
Bertujuan untuk menjamin model data logikal yang bersifat global telah tepat untuk perusahaan.

STUDY KASUS

No.1

Soal Kasus.

Koperasi XYZ adalah sebuah koperasi yang mengelola simpan pinjam bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian Kredit dalam menangani pemberian pinjaman bagi para anggotanya.

Setiap kali bagian kredit akan memberikan pinjaman kepada Anggota maka Anggota diharuskan mengisi Formulir Permohonan Pinjaman yang berisi Nomor FPP, Tanggal Permohonan, Nomor Anggota, Nama Anggota, Jumlah Permohonan dan Keperluan (rincian data diambil dari analisa dokumen yang ada). Yang kemudian oleh Bagian Kredit dicatat dan disimpan kedalam Arsip FPP. Berdasarkan Arsip FPP tersebut Bagian Kredit membuat Bukti Peminjaman yang diberikan kepada Anggota yang berisi No. BP, tgl BP, Nomor Anggota, Nama Anggota, Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran dan Bunga. Sebelum pemberian bukti terlebih dulu dilakukan pengecekan apakah anggota masih punya pinjaman, jika masih punya maka anggota diberitahukan penolakan pinjaman.

Setiap Bulan Anggota diharuskan membayar Angsuran sejumlah Angsuran yang disepakati pada saat Peminjaman yang kemudian oleh bagian Kredit dicatat dan direkam kedalam Arsip Angsuran. Berdasarkan Arsip Angsuran tersebut bagian Kredit membuat Bukti Angsuran yang diberikan kepada Anggota yang berisi No. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga

Pada akhir bulan Bagian Kredit selalu membuat Laporan Peminjaman dan Laporan Angsuran yang diberikan Kepada Ketua Koperasi.

Lakukan analisis dan rancangan sistem sebagai berikut :

• Model ER
• Transformasi ER-D ke Relasi
• Gambarkan Relasi-nya
• LRS (Logical Record Structure)

No.2

Kasus:

Soal Kasus.

”RENTAL CILEDUG” adalah sebuah badan usaha yang mengelola penyewaan CD Lagu dan Film, bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian penyewaan dalam menangani pemberian pinjaman bagi para anggotanya.

Setiap orang yang ingin menyewa CD haruslah menjadi anggota terlebih dahulu, untuk menjadi anggota tinggal mengisi formulir keanggotaan yang berisi nomor anggota, nama anggota sesuai KTP, nama panggilan, nomor KTP, alamat tempat tinnggal, nomor telepon rumah serta nomor HP. Dalam formulir tersebut juga tercantum aturan-aturan untuk menjadi anggota. Salah satunya poin yang tercantum adalah setiap yang ingin menjadi anggota diwajibkan untuk membayar uang keangotaan sebesar Rp. 10.000.

Setiap Anggota yang akan menyewa akan dicatat dalam buku peminjaman yang isinya nomor anggota, nama anggota dan CD yang di sewa, tanggal sewa dan tanggal harus kembali. Untuk sekali sewa setiap anggota boleh menyewa lebih dari satu CD tetapi dengan judul yang berbeda. Setiap mengembalikan CD anggota wajib membayar uang sewa sebesar ketentuan yang ada yaitu setiap CD mempunyai harga sewa per harinya. Jika pengembalian CD terlambat maka akan dikenakan biaya 10% per hari untuk setiap CD yang dipinjam. Jika CD yang dipinjam ternyata hilang maka diwajibkan untuk mengganti CD yang sama atau membayar sebesar harga CD yang tercantum ditambah uang sewa.

Pada akhir bulan Bagian penyewaan selalu membuat Laporan pendapantan penyewaan dan laporan kondisi CD yaitu yang tersedia dan yang disewa. Serta laporan CD-CD yang seharusnya sudah dikembalikan

Setelah membahas tentang metodologi perancangan basis data secara konseptual pada modul sebelumnya, pada modul yang kesembilan ini akan dibahas tentang studi kasus dalam lingkup perancangan basis data secara konseptual.

Studi kasus:

Administrasi akomodasi universitas XYZ

The director of the University XYZ accommodation office requires you to design a database to assist with the administration of the office. The requirement collection and analysis phase of the database design process has provided the following data requirements specification for the university accommodation office database followed by examples of query transaction that should be supported by the database.

- Data requirements

Students

The data stored on each full-time student includes: the matriculation number, name (first name, last name), home address (street, city, postcode), date of birth, sex, category of student (for example, first year undergraduate, post graduate), nationality, smoker (yes, no), special needs, any additional comments, current status (placed, waiting) and what course the student is studying on. The student information stored relates to those currently renting a room and those on the waiting list. Students may rent a room in a hall of residence or student flat.

When a student joins the university, he or she is assigned to a member of staff who acts as his or her advisor of studies. The advisor of studies is responsible for monitoring the student’s welfare and academic progression throughout his or her time at the university. The data held on a student’s advisor includes full name, position, name of department, internal telephone number and room number.

Halls of residence

Each hall of residence has a name, address, telephone number, a hall manager who supervises the operation of the hall. The halls provide only single rooms, which have a room number, place number, and monthly rent rate.

The place number uniquely identifies each room in all halls controlled by the accommodation office and is used when renting a room to a student.

Students Flats

The accommodation office also offers student flats. These flats are fully furnished and provide single-room accommodation for groups of three, four, or five students. The information held on student flats includes a flat number, address, and the number of single bedrooms available in each flat. The flat number uniquely identifies each flat.

Each bedroom in a flat has a monthly rent rate, room number, and a place number. The place number uniquely identifies each room available in all student flats and is used when renting a room to a student.

Leases

A student may rent a room in a hall or student flat for various periods of time. New lease agreement are negotiated at the start of each academic year with a minimum rental period of one semester and a maximum rental period of one year, which includes semesters 1, 2 and the summer semester. Each individual lease agreement between a student and the accommodation office is uniquely identified using a lease number.

The data stored on each lease includes the lease number, duration of the lease (given as semesters), name and matriculation number of the student, place number, room number, address details of the hall or student flat, and the date the student wishes to enter the room, and the date the student wishes to leave the room (if known).

Invoices

At the start of each semester each student is sent an invoice for the following rental period. Each invoice has unique invoice number.

The data stored on each invoice includes the invoice number, lease number, semester, payment due, student’s full name and matriculation number, place number, room number, and the address of the hall or flat. Additional data is also held on the payment of the invoice and includes the date the invoice was paid, the method of payment (cheque, cash, Visa, etc), the date the first and the second reminder is sent (if necessary).

Student flat inspections

Student flats are inspected by staff on a regular basis to ensure that the accommodation is well maintained. The information recorded for each inspection is the name of the member of staff who carried out inspection, the date of inspection, an indication of whether the property was found to be in a satisfactory condition (yes or no) and any additional comments.

Accommodation staff

Some information is also held on members of staff of the accommodation office and includes the staff number, name (first name and last name), home address (street, city, postcode), date of birth, sex, position (for example, accommodation office or hall). 

Courses

The accommodation office also stores a limited amount of information on the courses run by the university including the course number, course title (including year), course leader, internal telephone number, room number, and department name. Each student is associated with a single course.

Next-of-kin

Whenever possible, information on a student’s next-of-kin is stored which includes the name, relationship, address (street, city, postcode) and contact telephone number.

- Query transaction

Listed below are some common examples of query transaction that should be supported by the university accommodation office database system

1. Present a report listing the manager’s name and telephone number for each hall of residence. 
2. Present a report listing the names and matriculation numbers of students with the details of their lease agreement. 
3. Display the details of lease agreement that include the summer semester. 
4. Display the details of the total rent paid by a given student 
5. Present a report on students that have not paid their invoices by a given date. 
6. Display the details of flat inspections where the property was found to be in an unsatisfactory condition. 
7. Present a report of the names and matriculation numbers of students with their room number and place number in a particular hall or residence. 
8. Present a report listing the details of all students currently o the waiting list for accommodation 
9. Display the total number of students in each student category. 
10. Present the report of the names and matriculation numbers for all the students who have not supplied details of their next-of-kin. 
11. Display the name and internal telephone number of the advisor of studies for a particular student. 
12. Display the minimum, maximum, and average monthly rent for rooms in halls of residence. 
13. Display the total number of places in each hall of residence. 
14. Display the staff number, name, age and current location of all members of the accommodation staff who are over 66 years old today. 

Dari penjelasan diatas dapat diketahui entitas, hubungan antar entitas, multiplicity dan atribut-atribut dari setiap entitasnya.

Jawaban:

Langkah 1: mengidentifikasi tipe entitas yang ada

Entitas yang diidentifikasi:

• invoices 
• accommodation 
• room 
• flat 
• hall 
• student 
• course 
• NOK 
• staff 
• lease 
• inspection 

Langkah 2: mengidentifikasi tipe hubungan

• lease à invoices : generates 
• student à lease : request 
• room à lease : for 
• accommodation à room : provide 
• flat à accomodation : kind of 
• hall à accommodation : kind of 
• flat à inspection : has 
• student à NOK : has 
• staff à inspection : do 
• staff à hall : manages 
• student à course : take 

Langkah 3: mengidentifikasi atribut dari setiap entitas

1. Student (matricNo, name (composite: fName, lName), address (composite: street, city, postcode), DOB, sex, category, nationality, smoker, special needs, comments, status)
2. Course (courseNo, courseTitle, courseLeader, courseLeaderTelNo, courseLeaderRoomNo)
3. Lease (leaseNo, duration (derived as dateLeave-dateEnter), name 
4. (composite: fname, lname), matricNo, placeNo, roomNo, hallAddress/flatAddress, dateEnter, dateLeave)
5. Accommodation (hallNo, flatNo)
6. Flat (flatNo, fAddress, noOfRooms)
7. Hall (hallNo, hName, hAddress, hTelNo, managerName)
8. Room (placeNo, roomNo, monthlyRent)
9. NOK (name (composite: fname, lname), relationship, address (composite: street, city, postcode), contactTelNo)
10. Inspection (flatNo, iDate, condition, comments, inspStaffNo)
11. Invoice (invoiceNo, semester, paymentDue, datePaid, paymentMethod, dateReminder1, dateReminder2)
12. Staff (staffNo, name (composite: fName, lName), address (composite: street, city, postcode), DOB, sex, position, location)

Langkah 4: menentukan domain dari atribut

Untuk tabel diatas penjelasan untuk entitas dan domain atribut yang dijelaskan hanya dari satu entitas yaitu entitas student. Informasi yang dapat anda tambahkan adalah kolom keterangan yang dapat memberikan identifikasi dari atribut yang ada. Untuk entitas yang lain dapat anda lanjutkan sesuai dengan contoh diatas.

Langkah 5: menentukan primary key dari entitas

Berdasarkan data requirement dapat kita amati bahwa primary key dari setiap entitas adalah atribut yang dapat mengidentifikasi entitas secara unik.

Dari entitas student, atribut yang dapat mengidentifikasi secara unik adalah matricNo. Bagaimana dengan entitas yang lain?

Langkah 6: perhatikan kemungkinan penggunaan model EER

Dari keterangan data requirement terdapat kemungkinan model EER yaitu pada entitas Akomodasi sehingga dapat dituliskan sebagai berikut:

Gambar diatas menjelaskan bahwa hall dan flat merupakan bagian dari accommodation, antara entitas tersebut terdapat hubungan generalisasi.

Apakah ada bentuk EER yang lain dari data requirement?

Dari akhir langkah 6 dapat kita satukan entitas, hubungan, multiplicity, atribut dan primary key yang sudah teridentifikasi dalam diagram ER sebagai berikut:

Langkah 7: periksa model data yang redundan

- Periksa apakah ada 2 atau lebih entitas yang maksudnya sama

• tidak ada entitas yang redundan

- Periksa apakah ada hubungan yang redundan

• tidak ada hubungan yang berarti redundan

- Perhatikan dimensi waktu

• tidak ada hubungan atau entitas yang redundan berdasarkan waktu

Langkah 8: validasi model data konseptual dengan transaksi user

Bagaimana dengan transaksi yang lain?

Langkah 9: review model data konseptual bersama user

Langkah untuk mereview boleh dilakukan pada saat anda melakukan perancangan basis data yang memang melibatkan user dalam pembuatannya. Untuk latihan tidak diperlukan.

Untuk perancangan konseptual hasilnya adalah sebuah ERD dan kamus data serta validasi transaksi untuk ERD yang sudah ada.

No.1

Soal Kasus.

Koperasi XYZ adalah sebuah koperasi yang mengelola simpan pinjam bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian Kredit dalam menangani pemberian pinjaman bagi para anggotanya.

Setiap kali bagian kredit akan memberikan pinjaman kepada Anggota maka Anggota diharuskan mengisi Formulir Permohonan Pinjaman yang berisi Nomor FPP, Tanggal Permohonan, Nomor Anggota, Nama Anggota, Jumlah Permohonan dan Keperluan (rincian data diambil dari analisa dokumen yang ada). Yang kemudian oleh Bagian Kredit dicatat dan disimpan kedalam Arsip FPP. Berdasarkan Arsip FPP tersebut Bagian Kredit membuat Bukti Peminjaman yang diberikan kepada Anggota yang berisi No. BP, tgl BP, Nomor Anggota, Nama Anggota, Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran dan Bunga. Sebelum pemberian bukti terlebih dulu dilakukan pengecekan apakah anggota masih punya pinjaman, jika masih punya maka anggota diberitahukan penolakan pinjaman.

Setiap Bulan Anggota diharuskan membayar Angsuran sejumlah Angsuran yang disepakati pada saat Peminjaman yang kemudian oleh bagian Kredit dicatat dan direkam kedalam Arsip Angsuran. Berdasarkan Arsip Angsuran tersebut bagian Kredit membuat Bukti Angsuran yang diberikan kepada Anggota yang berisi No. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga

Pada akhir bulan Bagian Kredit selalu membuat Laporan Peminjaman dan Laporan Angsuran yang diberikan Kepada Ketua Koperasi.

Lakukan analisis dan rancangan sistem sebagai berikut :

• Model ER
• Transformasi ER-D ke Relasi
• Gambarkan Relasi-nya
• LRS (Logical Record Structure)

Sekian artikel tentang Memahami Konsep Logical Database Design Pada Basis Data.