Togu Novriansyah Turnip

Pemodelan Data dengan Fully Communication Oriented Information Modeling (FCO-IM) sebagai Solusi Alternatif Menghasilkan Model Data dengan Bentuk Tabel Normal Data Modeling using Fully Communication Oriented Information Modeling(FCO-IM) is an Alternative Solution for Creating Data Model with Normal Form Tables Togu Novriansyah Turnip Lecturer of Informatics Engineering; Faculty of Informatics and Electrical Engineering Del Institute of Technology, Laguboti, Tobasa, Sumatera Utara [email protected]

ABSTRACT. Data model is a vital component in developing information system. When creating a data model, we need to ensure all the relevant information in business process covers on it. One of the crucial activity in software engineering for making a data model for an information system is data modeling. Entity Relationship Diagram(ERD) is a common method to analysing and modeling data and it can generate a data model which describing how entities relate to one another. When developers use ERD method, they need to have data modeling skills such as relational concept and normalization concept. Although ERD is commonly used, Fully Communication Oriented Information Modeling (FCO-IM) is another alternative data modeling method. FCOIM is a conceptual model of data modeling based on natural language. At the end, the author tried to provide a knowledge how to use FCO-IM in order to give another alternative for creating a model data. Therefore, the result of FCO-IM method is a relational scheme which satisfies the rule of normalization.

KEYWORDS: Data Model, Data Modeling, ERD, Relational, Normalization, Conceptual Model, FCO-IM. 1.

PENDAHULUAN

Pemodelan data pada rekayasa perangkat lunak adalah tahapan penting yang dilakukan dalam membangun dan menghasilkan model data yang akan digunakan sebagai cikal bakal dari sebuah sistem informasi [1]. Pemodelan data berfokus pada data apa yang akan disimpan yang menggambarkan hubungan antara kumpulan entitas yang dibutuhkan oleh sebuah organisasi. Mayoritas developer banyak menggunakan metode Entity Relationship Diagram (ERD) untuk memodelkan entitas beserta relasi antara entitas yang dibutuhkan dalam pembangunan sebuah sistem informasi. Tahapan pembuatan ERD memerlukan pemahaman yang baik mengenai konsep relational dan konsep normalisasi tabel sehingga model data yang dihasilkan akan sesuai dengan kebutuhan data yang sudah dianalisis pada tahapan sebelumnya. Penelitian ini berfokus kepada satu metode yang dapat digunakan dalam tahap pemodelan data yaitu metode Fully Communication Oriented Information Modeling(FCO-IM). Metode FCO-IM memiliki keunikan sendiri dalam menghasilkan model data yang ada karena metode ini berfokus kepada informasi yang didapatkan dari artefak-artefak dan wawancara dengan expert sistem atau pengguna perangka lunak tersebut sehingga dapat mendukung setiap proses bisnis suatu organisasi. Metode ini diharapkan dapat menjadi sebuah alternatif lain untuk menghasilkan sebuah model data yang sudah memenuhi bentuk tabel normal sehingga menghindari permasalahan redudansi data dan menjamin integritas data tanpa perlu mengetahui konsep relational dan konsep normalisasi yang mendalam. Pada penelitian ini akan menjelaskan bagaimana cara penggunaan untuk menerapkan metode FCO-IM sehingga dapat menghasilkan model data yang sesuai dengan informasi yang diperoleh dari expert sistem.

2.

KONSEP MODEL DATA RELATIONAL

Model data yang banyak digunakan pada saat ini adalah model data relasional. Model data relasional menggunakan relational database management system(RDBMS) yang menyediakan layanan pengelolaan data yang mudah dan memiliki kemampuan untuk menangani jumlah data yang besar[2]. Relasi merupakan satu struktur logik dari data model relasional. Struktur relasi terdiri dari struktur data dua dimensi yang pada level fisik disebut dengan tabel yang memiliki kolom dan baris. Pada data model relasional terdapat beberapa istilah sebagai berikut: Tabel 1. Istilah Model Data Relasional Orientasi Tabel Orientasi Set Orientasi Record Table Relation Record-Type/File Row Tuple Record Column Attribute Field Istilah pada orientasi tabel direpresentasikan secara logik menjadi sebuah tabel yang terdiri dari baris dan kolom. Istilah untuk orientasi set/kumpulan direpresentasikan sebagai relasi, nilai-nilai data yang sesuai dengan atributnya disimpan dalam tuple. Istilah yang terakhir adalah orientasi record direpresentasikan dengan recordtype/file dimana nilai dari tiap-tiap entitas disimpan di record yang terstruktur berdasarkan field-field yang dimiliki. Faktor penentuan model data yang baik ditentukan dari keakuratan, konsistensi, dan kehandalan data. Untuk mewujudkan hal tersebut dibutuhkan integritas data. Integritas data biasanya diterapkan dalam sistem basis data dengan beberapa integritas konstrain atau aturan. Terdapat tiga jenis integrity constraint yang tidak dapat dapat dipisahkan dari model data relasional yaitu: 1. Integritas Entitas Integritas entitas mendefinisikan aturan setiap tabel harus memiliki satu kolom atau kombinasi kolom yang memiliki nilai unik (tidak ada nilai data yang sama dari setiap record) dan tidak null. 2. Integritas Domain Integritas domain mendefinisikan aturan untuk nilai yang memungkinkan pada setiap atribut. Integritas domain dapat dilakukan melalui pembatasan tipe data, format, atau rentang nilai yang mungkin. 3. Integritas Referensial Integritas referensial mendefinisikan aturan dengan nilai dari field suatu tabel harus sama dengan nilai dari suatu field tabel lain yang memiliki hubungan/relasi.

3.

Konsep Normalisasi Tabel

Pada model data relasional dikatakan baik apabila sudah menerapkan normalisasi. Menurut E.F. Codd, Normalisasi adalah langkah-langkah sistematis yang menjamin struktur basis data sehingga bebas dari insertion, update dan deletion anomalies yang dapat menyebabkan hilangnya integritas data[3]. Normalisasi dapat disimpulkan sebagai teknik analisis data yang mengelola atribut-atribut data dengan cara mengelompokkan sehingga terbentuk entitas yang tidak redudansi, stabil, dan fleksibel. Normalisasi dilakukan sebagai uji coba dalam model data relasional untuk menentukan apakah relasi itu sudah baik, yaitu dapat dilakukan proses insert, update, dan delete pada satu atau beberapa atribut tanpa mempengaruhi integritas data dalam relasi tersebut. Pada proses normalisasi terhadap tabel pada basis data dapat dilakukan dengan beberapa tahap normalisasi, namun pada penelitian ini hanya menguraikan tiga bentuk normal antara lain: 1. Bentuk Normal ke Satu(1NF) Syarat: a. Tidak ada atribut yang berulang dan bernilai ganda (multi value). b. Telah ditentukannya primary key untuk tabel atau relasi. 2. Bentuk Normal ke Dua(2NF) Syarat: a. Memenuhi kriteria 1NF. b. Tidak ada partial functional dependency artinya atribut bukan kunci memiliki ketergantungan fungsional sepenuhnya pada primary key.

3.

Bentuk Normal ke Tiga(3NF) Syarat: a. Memenuhi kriteria 2NF. b. Atribut bukan kunci tidak boleh memiliki ketergantungan fungsional transitif terhadap atribut bukan kunci lainnya. Seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja.

Menurut Date, C.J menyatakan bahwa tabel pada basis data relasional digambarkan sebagai "normal" jika dalam Bentuk Normal Ketiga. Kebanyakan tabel 3NF bebas dari anomali penambahan, perubahan, dan penghapusan[4]. Menurut Elmasri dan Navathe, menyatakan bahwa idealnya desain model data berbasis relasional harus mencapai minimal normal 3NF untuk menjaga integritas data[5]. Dari beberapa studi literatur yang ada dapat disimpulkan bahwa sebuah model data yang baik harus memenuhi bentuk normal ketiga sehingga dapat menjaga integritas dan redundansi data. 4. Fully Communication Oriented Information Modeling(FCO-IM) FCO-IM merupakan sebuah teknik yang powerful untuk memodelkan aspek konseptual data berdasarkan cara komunikasi informasi dengan domain expert sesuai dengan fakta yang diinginkan dari sistem yang akan dikembangkan[8]. FCO-IM tidak memodelkan struktur dari sistem yang dikembangkan tetapi memodelkan komunikasi informasi tentang sistem yang akan dikembangkan. FCO-IM memodelkan informasi dengan berbasiskan fakta yang dikomunikasikan sehingga dapat ditampilkan melalui IGD. Model tersebut dapat secara otomatis berubah menjadi ERM (Entity Relationship Model), UML, relasional atau dimensional model menggunakan FCO-IM Bridgetools dan memungkinkan untuk menghasilkan aplikasi end-user yang lengkap dengan menggunakan IMAGine toolset. Alat bantu yang digunakan untuk memodelkan informasi dengan menggunakan pendekatan metode FCO-IM adalah CaseTalk Educational Versi 8.0. Adapun kelebihan FCO-IM sebagai berikut[6][7]: 1. Intensitas keikutsertaan user tinggi, sehingga menuju ke arah validasi yang baik 2.

Pendekatan model menghasilkan desain yang lebih baik

3.

Dokumentasi terintegrasi penuh sehingga mencegah penambahan biaya pemeliharaan

4.

Meningkatkan dukungan terhadap perkembangan sistem ke arah yang lebih baik

5.

Mengurangi time to market untuk pemodelan dan realisasi

Mulai

1. Proses Verbalisasi

2. Proses Klasifikasi dan Kualifikasi

3. Proses Pembuatan Information Grammar Diagram(IGD)

4. Proses Pembuatan Constraint

5. Proses Grouping, Lexicalizing, dan Reducing(GLR)

Akhir

Gambar 1. Langkah-langkah Metode FCO-IM Dalam melakukan pemodelan terhadap informasi (skenario), FCO-IM melakukannya dalam beberapa tahapan. Berikut penjelasan dari masing-masing tahapan yang terdapat pada Gambar 1: 1. Verbalisasi Keikutsertaan dari domain expert sangat penting dalam tahap verbalisasi. Hal ini yang menjadi keunikan pada metode FCO-IM karena domain expert tidak hanya memberikan informasi tetapi juga ikut serta dalam pembentukan ekspresi fakta. Pada prakteknya, analis juga cukup mampu dalam mengungkapkan ekspresi fakta sesuai dengan starting document dan concrete examples yang sudah ada. Hal ini diharapkan agar analis juga mengenal domain sistem yang ada. Jadi, penyusunan ekspresi fakta untuk tahap verbalisasi berdasarkan starting document dan concrete examples. a. Starting document mendeskripsikan secara umum informasi yang relevan dan proses informasi b. Concrete Examples, untuk memperjelas dan mendukung perspektif informasi yang ada dari masingmasing daftar yang sudah diberikan pada starting document sehingga dapat menghasilkan fakta yang akurat.

Bagaimanapun hasil dari verbalisasi yang dilakukan oleh analis harus divalidasi oleh domain expert untuk memastikan kebenaran interpretasi fakta sesuai dengan starting document dan concrete examples. Yang perlu diperhatikan pada tahap verbalisasi adalah kalimat yang menjadi ekspresi fakta harus kalimat dasar(fact elementary). Jika pada tahap verbalisasi terdapat kalimat majemuk, maka kalimat tersebut harus dipisahkan menjadi kalimat dasar. 2.

Klasifikasi dan Kualifikasi Klasifikasi adalah proses mengelompokkan ekspresi fakta tersebut ke dalam kelas-kelas//elementary fact type sedangkan kualifikasi adalah proses memberikan nama terhadap masing-masing kelas. Setelah tahapan klasifikasi dan kualifikasi dilakukan maka hasilnya disimpan di dalam repository (Information Grammar/IG) dan bagian-bagian kalimat tersebut diklasifikasi berupa fact type (role), object type, dan label type. Prosedur dari tahapan klasifikasi dan kualifikasi sebagai berikut: a. Salah satu ekspresi fakta dipilih dari masing-masing fact type expressions kemudian value yang ada dirubah dengan menggunakan label. b. Jika label/kombinasi label diidentifikasi sebagai objek yang memiliki makna menurut pandangan domain expert, maka bagian kalimat tersebut diklasifikasikan menjadi object expression. Selanjutnya akan dikualifikasi dengan memberikan nama yang bermakna sesuai dengan object type-nya. Contoh pemberian nama object type: Fact: “In project P66, EUR 10,000 is the budget of subproject 3”. Kalimat ini seharusnya diformulasi ulang karena dalam mengidentifikasi subproject 3 dibutuhkan project. Kalimat tersebut menjadi: “Subproject 3 of project P66 has a budget of EUR 10,000” sehingga bagian kalimat “Subproject 3 of project P66” dapat diidentifikasi sebagai object type expression dan dikualifikasikan sebagai subproject. Hal ini bertujuan untuk memfasilitasi fact type yang memiliki jenis hubungan unary fact type. c. FTE yang memiliki hubungan dengan object type yang sudah didefinisikan sebelumnya akan secara otomatis dikenali bersamaan dengan label-nya sedangkan value dari kalimat tersebut yang tidak memiliki hubungan akan diklasifikasikan sebagai label. d. Label diklasifikasikan dengan nama yang bermakna sesuai dengan label type tersebut. Notasi penulisan label disarankan tidak boleh menggunakan huruf kapital. Label type disebut juga lexical object type (LOT). e. Semua OE harus dilakukan analisis kembali. OE yang terdapat pada FE harus tidak ditemukan lagi OE yang baru sehingga memunculkan label type level. Object type disebut juga nonlexical object type (NOLOT).

3.

Information Grammar Diagram Tahapan ini bertujuan untuk mendapatkan model informasi berdasarkan kalimat natural input-an user. Model informasi yang dihasilkan sesuai dengan item-item yang terdapat pada repository.

4.

Constraint

Tahapan constraint merupakan proses melakukan penambahan constraint yang dilakukan pada Information Grammar Diagram (IGD). Pada umumnya, tidak ada metode sistematik untuk menentukan subset, equality, exclusion, maupun cardinality constraint. Constraint tersebut dapat muncul dari sumber informasi (starting document dan concrete examples) atau dari interview dengan user. Terdapat beberapa constraint pada FCO-IM, sebagai berikut: a. Value constraint(VC), untuk membuat batasan pada label type. b. Uniqueness constraint(UC) merupakan sebuah constraint yang mengindikasikan bahwa nilai dari setiap populasi hanya dapat muncul sekali. Algoritma untuk menentukan semua uniqueness constraint pada sebuah fact type: 2. Unary Fact Type: verifikasi object type yang memang berhubungan dengan label type. 3. Fact type dengan “n” role (n adalah lebih besar dari satu) sehingga ada n kemungkinana dari sebuah UC pada n-1 role. Kemudian harus tepat satu UC pada semua n role. Uji semua kemunginan UC: Tidak UC pada role n-1 ditemukan, Hanya tepat satu UC untuk semua n role dan Paling kecil satu UC pada role n-1 ditemukan. 4. Pada fact type yang memiliki dua atau lebih role untuk setiap UC pada role n-1 ditemukan pada langkah 2: lakukan pengecekan UC yang lebih kecil dari role n-2 sehingga ada UC benar-benar

ditemukan. Ada n-1 kemungkinan untuk UC pada role n-2 per UC yang ditemukan pada langkah 2. Uji kembali keberadaan kemungkinan UC. Hal yang sama dilakukan seperti point 2 dengan role n-2. c. Totality constraint(TC) diterapkan pada role yang terkait dengan object type, dimana populasi dari object type harus muncul pada role tersebut. i. Prosedur penentuan TC sebagai berikut: ii. Pada baris yang pertama pada masing-masing kolom diisi dengan nilai yang sesuai. Untuk selanjutnya akan dilakukan pengecekan apakah fact harus diisi atau tidak. Jika jawabannya tidak maka TC akan didefinisikan dan sebaliknya. iii. Pertama, dengan mempertimbangkan semua kemungkinan role tunggal TC pada gilirannya. Selanjutnya, proses menyelidiki semua kombinasi dari dua role, yang perlu dipertimbangkan role yang berlaku tanpa TC role tunggal. Sama halnya dengan uniqueness constraint, hal ini berlaku juga untuk TC: harus ada dua TC “p” dan “q”, di mana semua role dari p juga terdapat pada q, jika p lebih berperan dari q, maka q harus diabaikan. Selanjutnya, proses mempertimbangkan semua kombinasi dari tiga role yang tidak mencakup TC yang ditemukan sebelumnya. d. Subset constraint(SC) diberikan ketika populasi dari satu role harus menjadi bagian/subset dari populasi role lain e. Equality constraint merupakan constraint yang terdiri dari 2 subset constraint f. Exclusion constraint diberikan ketika populasi dari role tidak dapat memiliki label g. Cardinality constraint menentukan bahwa populasi dari role muncul dengan nilai tertentu 5.

Grouping, Lexicalizing, dan Reducing (GLR), yaitu mengkombinasikan sebanyak mungkin fact type ke dalam tabel yang sama tanpa adanya redundansi, mentransformasi fact type sehingga setiap role memiliki label type dan menghapus fact type tertentu. Setelah melalui tahapan terakhir yaitu GLR dapat dihasilkan skema relasional. Prosedur untuk algoritma grouping sebagai berikut: 1. Semua role diperiksa yang memenuhi lima syarat dibawah ini, jika role memenuhi syarat maka role tersebut diberikan tanda G dan dapat dihapus selama proses grouping. a. Role merupakan bagian dari n-ary fact type, dengan n lebih besar dari satu. b. Role dilakukan oleh sebuah non-lexical object type. c. Role memiliki sebuah UC tunggal d. Role tidak opsional, yaitu tidak memiliki nilai kosong e. Role tidak secara langsung rekursif, yaitu role tidak dimainkan secara langsung oleh nominalized fact type itu sendiri. 2. Untuk setiap role yang diperoleh dari langkah 1 terapkan langkah 2a-2h a. Jika lebih dari satu role berada pada fact type yang sama, maka lakukan langkah ini terhadap role terebut satu persatu. Ada dua kasus yaitu: i. Hanya ada satu role dengan UC tunggal, maka langkah ini diterapkan terhadap role tersebut terlebih dahulu. ii. Jika lebih dari satu role dengan UC tunggal atau tidak ada memiliki UC tunggal, maka penerapan langkah ini dapat diterapkan pada role maupun terlebih dahulu. Namun pilihan yang berbeda akan menghasilkan skema relational ekivalen yang berbeda-beda. b. Jika fact type yang dinormalisasi memainkan role-nya sendiri, maka pilih fact type lain yang tidak dinormalisasi. Selain itu dikelompokkan, biarkan role-role tersebut dimainkan oleh fact type yang dinormalisasi yang menyesuaikan role sisanya dan sesuaikan constraint yang ada. c. Role yang sudah ditandai akan dihapus dan role yang tersisa diletakkan dari fact type ke nominalisasi fact type yang memainkan role tersebut. UC yang lain tidak berubah, kemudian hapus object type/ fact type dari role yang ditandai tersebut. d. Jika role yang telah dihapus memiliki TC, maka proses TC tersebut dalam hal ini ada 3 kasus: i. Jika tidak ada single role TC atau multiple role TC, maka semua role yang disesuaikan pada role yang telah dihapus tersebut menjadi opsional. ii. Jika ada sebuah multiple role TC, maka semua role yang disesuaikan pada role yang telah dihapus tersebut menjadi opsional dan multiple role TC tersebut dihapus dan diganti dengan EC pada kolom tabel hasil. iii. Jika ada sebuah single role TC, maka tidak ada perubahan dan single role TC dihapus.

e.

3.

Proses semua konstrain yang ada pada role yang telah dihapus tersebut dan kemudian diganti dengan EC. f. Proses fact type expression(FTE) dan object type expression(OTE) dari fact type yang telah dikelompokkan. Isi titik-titik pada OTE yang mengacu pada role yang telah dihapus dan dipindahkan semuanya ke normalisasi fact type tersebut tidak memainkan role lainnya, maka hapus semua OTE yang berkatian. g. Semua ekspresi fakta ditambahkan dari populasi peran yang tersisa pada type fact yang telah dikelompokkan pada populasi ekspresi fakta yang menyerapkan role-role ini. Role opsional diberikan nilai null. Jika tidak ada lagi role yang tersisa, maka proses grouping telah selesai. Jika ada, maka lakukan langkah 2a-2h.

Prosedur untuk algoritma lexicalizing sebagai berikut: 1. Semua role non-lexical ditandai dengan huruf L pada IGD role tersebut. 2. Untuk setiap role tersebut lakukan langkan 2a-2g a. Role yang sudah diberikan tanda L dicari. b. Role yang sudah ditandai dipisahkan dari object type yang memainkannya. Jika object type expression role yang ditandai tersebut hanya terdiri dari satu role, maka letakkan role ke label type yang memainkan role yang mengacu ke object type expression tersebut. Jika OTE, role yang ditandai tersebut terdiri dari lebih dari satu role, maka pisahkan role-role tersebut menjadi rolerole tersebut menjadi role-role dengan nomor role yang sama dan sambungkan ke label type yang memainkan role yang mengacu ke OTE tersebut. c. Substitusi OTE role yang ditandai menjadi semua FTE dan OTE yang mengacu pada role yang tandai dan proses populasinya. d. Sebuah SC ditambahkan dari role yang telah mengalami proses lexicalizing ke role yang mengacu pada OTE role yang telah mengalami proses lexicalizing. e. Setiap TC pada role yang ditandai dihapus. Tambahkan sebuah SC untuk setiap TC yang dihapus sehingga SC yang dibangun dan dengan beberapa SC yang dibangun pada tahap 2d menjadi setara TC f. Proses semua konstrain lain pada role mengalami proses lexicalizing. g. Setiap tahap 2a-2f fact type yang dinormalisasi tidak memainkan role apapun. Hapus semua OTE yang berkatian dengan fact type juga populasinya. Jika fact type tidak memiliki FTE, maka hapus keduanya berikut konstrain-konstrain yang ada. Prosedur untuk algoritma reducing sebagai berikut: 1. Kondisi yang harus dipenuhi sebuah fact type untuk mengalami tahap reducing yaitu setelah tahap L, setidaknya ada satu EC yang diterapkan pada semua role fact type tersebut dan memerankan satu fact type lainnya. Fact type yang cocok untuk dihapus juga dapat dilihat pada G-IGD dan EI-IGD yaitu fact type yang dinominalisasi, tetapi tidak terkait role apapun dan setidaknya memiliki satu TC, 2. Administrator basis data ditanyakan, apakah sebuah fact type dapat dihapus atau tidak. 3. Setelah mendapat izin, fact type dihapus termasuk FTE, konstrain-konstrain dan populasinya. 4. Fact type yang merupakan kandidat untuk dihilangkan dapat diketahui melalui G-IGD yaitu nominalisasi fact type yang tidak terkait role maupun dan setidaknya memiliki satu TC pada role yang dimainkannya. 5.

TAHAPAN PEMODELAN FCO-IM

Langkah-langkah yang diuraikan akan dilengkapi dengan ilustrasi yang konkrit dari studi kasus TIM POSS IT DEL. Hal ini bertujuan agar masing-masing tahapan pemodelan dengan metode FCO-IM mudah dipahami dengan baik. 1. Verbalisasi Proses untuk melakukan tahapan verbalisasi adalah melakukan analisis deskripsi singkat dari sistem informasi yang akan dikembangkan beserta berbagai artefak(concrete examples) yang dapat mendukung proses analisis. Berikut contoh starting document yang berisi deskripsi singkat sistem informasi yang akan dikembangkan:

Tim POSS IT Del merupakan tim yang memberdayakan penggunaan perangkat lunak yang bersifat open source. Tim ini menawarkan beragam seminar di sekolah, universitas, pemerintahan, bahkan di lokasi umum. Seminar yang diadakan sifatnya gratis; diadakan untuk menjalin hubungan dengan pengguna. Tim ini mendapatkan dana dengan menjual buku dan video tentang manfaat dan penggunaan perangkat lunak open source. Apabila seseorang menghadiri seminar, kesempatan ini digunakan oleh tim untuk menjual salah satu produk atau layanan kepada orang tersebut. Kemudian, tim akan mengembangkan sebuah basisdata untuk menelusuri pelanggan termasuk: seminar yang mereka ikuti, kontak yang sudah pernah dilakukan kepada pelanggan, dan pembelian yang sudah pernah dilakukan oleh pelanggan. Tim ingin menggunakan basisdata ini untuk terus melanjutkan hubungan dengan pelanggan dan menawarkan produk dan jasa. Selain form yang dikumpulkan, berdasarkan hasil wawancara dengan tim POSS ditentukan bahwa peserta dapat menghadiri sebanyak mungkin seminar yang mereka sukai, tetapi tim POSS menginginkan agar dapat menyimpan data pelanggan walaupun pelanggan tersebut tidak pernah mengikuti seminar. Selain itu, tim tidak pernah mengadakan seminar yang jumlah peserta kurang dari 10 orang. Faktur penjualan yang digunakan tim POSS IT Del untuk menjual buku dan video ditunjukkan pada gambar 3. Karena alasan keamanan pada komputer, tim POSS memutuskan untuk tidak menyimpan nomor kartu kredit di dalam basisdata. Tim hanya menyimpan jenis pembayaran, sedangkan arsip tanda terima kartu kredit dimasukkan pada loker dengan catatan yang akan menghubungkannya dengan nomor penjualan. Berikut contoh dari concrete examples yang mengklarifikasi kebenaran informasi yang sudah diungkapkan pada tahap sebelumnya.

Gambar 2. Daftar Peserta Seminar

Gambar 3. Faktur Penjualan

Berikut hasil verbalisasi/fact type expression dari starting document dan concrete examples: 1. Ada pelanggan dengan nama Nancy Jacobs 2. Ada pelanggan dengan nama Ralph Able 3. Nancy Jacobs memiliki nomor telepon 555-900-9999 4. Ralph Able memiliki nomor telepon 555-900-8765 5. Nancy Jacobs memiliki alamat email [email protected] 6. Ralph Able memiliki alamat email [email protected] 7. Nancy Jacobs beralamat di 456 Sitoluama 8. Ralph Able beralamat di 123 Sitoluama 9. 456 Sitoluama berada di kecamatan Laguboti 10. 123 Sitoluama berada di kecamatan Laguboti 11. 456 Sitoluama terletak di bagian tx 12. 123 Sitoluama terletak di bagian tx 13. 456 Sitoluama memiliki kodepos 22381 14. 123 Sitoluama memiliki kodepos 22382 15. Tim POSS mengadakan seminar dengan judul Pengembangan OSS 16. Tim POSS mengadakan seminar dengan judul Implementasi OSS 17. Seminar Pengembangan OSS diadakan di Auditorium IT Del pada tanggal 07 Maret 2016 pukul 15:00 WIB 18. Seminar Implementasi OSS diadakan di Gedung Serbaguna IT Del pada tanggal 17 Juni 2016 pukul 11:00 WIB 19. Seminar pengembangan OSS diikuti oleh Nancy Jacobs dan jumlah peserta sebanyak 27 orang 20. Seminar pengembangan OSS diikuti oleh Ralph Able dan jumlah peserta sebanyak 27 orang 21. Tim POSS menjual buku berjudul Buku POSS 22. Tim POSS menjual video berjudul Video Tip dan trik implementasi POSS 23. Buku POSS berharga 10.000 24. Video Tip dan trik implementasi POSS berharga 20.000 25. Ada transaksi dengan nomor invoice 34988 26. Pada nomor invoice 34988 terdapat 1 buah buku dengan judul Buku POSS yang dibeli oleh Ralph Able pada tanggal 08 Maret 2016 27. Pada nomor invoice 34988 terdapat 1 buah video dengan judul Video Tip dan trik implementasi POSS yang dibeli oleh Ralph Able pada tanggal 08 Maret 2016 28. Pada nomor invoice 34988 memiliki total pembayaran sebesar 35.000 termasuk biaya pengiriman barang sebesar 5000 29. Ada jenis pembayaran dengan kartu kredit 30. Transaksi nomor invoice 34988 dibayarkan dengan kartu kredit 2. Klasifikasi dan kualifikasi Pada tahapan ini, pihak yang akan menggunakan metode FCO-IM harus memiliki kemampuan untuk mengkelompokan atau mengkategorikan hasil verbalisasi menjadi kelas. Pada studi kasus yang ada dapat dikualifikasikan menjadi enam kelas/elementary fact type sebagai berikut: Pelanggan, Seminar, Produk_Jasa, Alamat, Transaksi, dan Tipe_Pembayaran. Hasil akhir tahapan ini untuk selanjutnya akan disimpan di dalam repository (Information Grammar/IG) dan bagian-bagian kalimat tersebut diklasifikasi berupa fact type (role), object type, dan label type. Beberapa ekspresi fakta yang merupakan hasil dari verbalisasi akan ditambahkan secara manual pada saat ekspresi fakta sudah dibuat. Penambahan populasi data dapat ditambahan setelah ekspreksi fakta dilakukan.

Berikut hasil dari tahap klasifikasi dan kualifikasi untuk studi kasus yang ada: Tabel 2. Daftar Label dan Object/Label Type LABEL Pelanggan Ada pelanggan dengan nama Nancy Jacobs Pelanggan:O1 nama_pelanggan Nancy Jacobs memiliki nomor telepon 555-900-9999 Pelanggan:O1 nama_pelanggan telepon_pelanggan Nancy Jacobs memiliki alamat email [email protected] Pelanggan:O1 nama_pelanggan email_pelanggan Nancy Jacobs beralamat di 456 Sitoluama Pelanggan:O1 Alamat:02 nama_pelanggan nama_alamat Alamat 456 Sitoluama berada di kecamatan Laguboti Alamat:02 kecamatan nama_alamat 456 Sitoluama terletak di bagian tx Alamat:02 provinsi nama_alamat 456 Sitoluama memiliki kodepos 22381 Alamat:02 kodepos nama_alamat Seminar Tim POSS mengadakan seminar dengan judul Pengembangan OSS Seminar:03 judul_seminar Seminar Pengembangan OSS diadakan di Auditorium IT Del pada tanggal 07 Maret 2016 pukul 15:00 WIB Seminar:03 lokasi_seminar tanggal_seminar jam_seminar judul_seminar Seminar pengembangan OSS diikuti oleh Nancy Jacobs dan jumlah peserta sebanyak 27 orang

Object / Label Type

F1: “Ada pelanggan dengan nama < nama_pelanggan> F2: memiliki nomor telepon O1: ‘Pelanggan’ F3: memiliki alamat email <email_pelanggan> O1: ‘Pelanggan’ F4: beralamat di O1: ‘Pelanggan’ O2: ‘Alamat’

F5: berada di kecamatan O2: ‘Alamat’ F6: terletak di bagian <provinsi> O2: ‘Alamat’ F7: memiliki kodepos O2: ‘Alamat’

F8: Tim POSS mengadakan seminar dengan judul <Seminar:O3> O3: ‘Seminar<judul_seminar>’ F9: seminar<Seminar:O3> diadakan di pada tanggal< tanggal_seminar> pukul < jam_seminar> O3: ‘Seminar<judul_seminar>’ F10: Seminar <Seminar:O3> diikuti oleh dan jumlah peserta sebanyak < jumlah_peserta> orang

LABEL Pelanggan:O1 nama_pelanggan

Seminar:O3 judul_seminar Produk_Jasa Tim POSS menjual buku berjudul Buku POSS Produk_Jasa:O4 nama_produk Buku POSS berharga 10.000 Produk_Jasa:O4 harga_produk nama_produk

Object / Label Type jumlah_peserta

Transaksi Ada transaksi dengan nomor invoice 34988 Transaksi:O5 nomor_invoice Pada nomor invoice 34988 terdapat 1 buah buku dengan judul Buku POSS yang dibeli oleh Ralph Able pada tanggal 08 Maret 2016 Transaksi:O5 jlh_produk_transaksi Produk_Jasa:O4 Pelanggan:O1 tanggal_transaksi nomor_invoice nama_produk nama_pelanggan Pada nomor invoice 34988 memiliki total pembayaran sebesar 35.000 termasuk biaya pengiriman barang sebesar 5000 Transaksi:O5 total_pembayaran biaya_pengiriman nomor_invoice Jenis_Pembayaran Ada tipe pembayaran dengan kartu kredit Jenis_Pembayaran:O6 nama_jenis_pembayaran Transaksi nomor invoice 34988 dibayarkan dengan kartu kredit Transaksi:O5 Jenis_Pembayaran:O6 nomor_invoice nama_jenis_pembayaran

O3: ‘Seminar<judul_seminar>’ O1: ‘Pelanggan’ F11: Tim POSS menjual buku O4: ‘Produk_Jasa’ F12: berharga O4: ‘Produk_Jasa’

F13: Ada transaksi dengan nomor invoice O5: ‘Transaksi< nomor_invoice>’ F14: Pada nomor invoice terdapat <jlh_produk_transaksi> buah buku dengan judul yang dibeli oleh pada tanggal < tanggal _transaksi> O5: ‘Transaksi< nomor_invoice>’ O4: ‘Produk_Jasa’ O1: ‘Pelanggan’ F15: Pada nomor invoice memiliki total pembayaran sebesar termasuk biaya pengiriman barang sebesar O5: ‘Transaksi< nomor_invoice>’

F16: Ada jenis pembayaran dengan < Jenis_Pembayaran:O6> O6: ‘Jenis_Pembayaran ’ F17: Transaksi nomor invoice < Transaksi:O5> dibayarkan dengan < Jenis_Pembayaran:O6> O5: ‘Transaksi< nomor_invoice>’ O6: ‘Jenis_Pembayaran ’

3. Information Grammar Diagram Setelah tahap klasifikasi dan kualifikasi disimpan ke dalam repository maka information grammar diagram dapat ditampilkan. Berikut hasil IGD untuk setiap fact type dan objek yang dihasilkan.

Gambar 4. Information Grammar Diagram 4. Penambahan constraint Tahapan penambahan constraint dapat dilakukan dengan bantuan yang sudah tersedia di tool casetalk pada menu repository seperti penambahan uniqueness, totality, subset, equality, exclusion, dan cardinality constraint. Gambar 5 merupakan penambahan constraint totality pada kelas seminar.

Gambar 5. Penambahan Totality Constraint 5. Grouping, Lexicalizing, dan Reducing (GLR) GLR merupakan tahap terakhir yang harus dilakukan pada metode FCO-IM. Tahapan ini juga menggunakan fitur transform yang terdapat pada tool casetalk. Casetalk akan melakukan setiap algoritma yang

ada pada masing-masing proses GLR. Tahapan ini akan merubah IGD ke skema relasional. Pada studi kasus ini proses grouping dilakukan pada tipe_transaksi_pembayaran dengan jenis_pembayaran dan pada proses reducing akan ditanyakan untuk menghapus fact type jenis pembayaran.

Gambar 6. Model Data Hasil Metode FCO-IM Gambar 6 merupakan bentuk ER-Diagram yang dapat dihasilkan setelah melakukan proses transformasi IGD ke skema relasional dapat ditentukan berbagai script language seperti Borland, XML, Interbase, MySql, Oracle, Microsoft Access, dan Microsoft Server SQL, tetapi yang dihasilkan pada penelitian ini dipilih Script MySQL. Tipe engine yang dihasilkan oleh metode FCO-IM menggunakan InnoDB. Berdasarkan hasil analisis pada model data yang dihasilkan masing-masing atribut bukan kunci tidak memiliki ketergantungan fungsional transitif terhadap atribut bukan kunci lainnya dan setiap atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja sehingga dapat disimpulkan bahwa model data hasil metode FCO-IM ini sudah memenuhi konsep normalisasi 3NF.

No. 1 2 3 4 5 6 7 8 9

Tabel 3. Transformasi dari FCO-IM ke Model Relasional FCO-IM Model Relasional Fact type Relation type, tipe tabel Role Attribut atau kolom Label type Value/domain Tuple Tuple, row Primary identifier Primary key Identifier: NN role, or combination of NN roles Candidate key Subset constraint Reference SC to primary identifier Foreign key Value constraint dan constraint lainnya(XC, CC) Domain constraint dan integrity rule

1. 2. 3. 4.

5.

6.

6. KESIMPULAN dan SARAN Pemodelan data menggunakan metode FCO-IM dapat menghasilkan skema data relasional yang sudah memenuhi normalisasi 3 NF sehingga dapat digunakan sebagai alternatif dalam memodelkan data. Metode FCO-IM sangat menekankan kepada pentingnya melakukan wawancara kepada pengguna dan juga mempelajari artefak-artefak berupa form ataupun report sehingga dapat mempermudah tahap verbalisasi. Penggunaan metode FCO-IM ini tidak membutuhkan pemahaman mengenai konsep normalisasi dan relational. Pada saat menentukan kelas/elementary fact type membutuhkan ketelitian dalam mengkelompokkan masing-masing hasil verbalisasi sehingga developer yang akan menggunakan metode FCO-IM harus benarbenar memahami konsep kelas atau pengelompokan data sejenis dan mengikuti tahapan penambahan constraint. Proses GLR dilakukan secara otomatis oleh bantuan tool casetalk, proses ini merupakan tahapan terakhir dalam menghasilkan model data relasional. Masing-masing tahapan dapat diperhatikan proses perubahannya. Penentuan tipe data dapat dilakukan pada proses penambahan constraint sehingga developer dapat menentukan tipe data yang sesuai untuk masing-masing atribut. Tetapi tool casetalk memiliki kemampuan dalam menentukan tipe data secara sintaks dari data fakta yang terdapat di ekspresi fakta sehingga disarankan agar pengembangan tool casetalk dapat lebih fleksibel sehingga semantik dari data tidak terabaikan.

7. DAFTAR PUSTAKA [1] Silberschatz Abraham, Korth Henry F., Sudarshan S., 2006: Database System Concepts, Fifth Edition. New York: McGraw-Hill Companies, Inc. [2] C. J. Date. 1999. An Introduction to Database Systems, Eighth Edition Addison. [3] Codd, E. F. 1971. Further Normalization of the Database Relational Model, San Jose IBM Research Report. [4] Moody, D and Shanks, G.2003: Improving the Quality of Entity Relationship Models: Experience in Research and Practice, Information Systems Journal, 619. [5] Elmasri, R., Navathe S. 2010. Fundamentals of Database Systems,Sixth Edition [6] Bakema, Guido., Zwart,Jan.,Pieter., Lek,Harm.,van.,der. 2002. Fully Communication Oriented-Information Modeling. HAN University, The Netherlands [7] Bakema,Guido., Zwart,Jan.,Pieter. 2006. Innovative information system modeling and development with FCO-IM. HAN University, The Netherlands [8] Manoku, Elton., Bakema,Guido. 2005. Integrated Tool Support for Datawarehouse Design. HAN University, The Netherlands