BAB II TINJAUAN PUSTAKA

BAB II TINJAUAN PUSTAKA 2.1 Perencanaan Arsitektur Enterprise Menurut Surendro (2009) sesuai dengan IEEE (1471-2000), arsitektur adalah pengorganisasian yang fundamental dari suatu sistem yang terdiri dari beberapa komponen, relasi yang terjadi antara komponen dan beberapa lingkungannya, serta prinsip-prinsip yang digunakan sebagai petunjuk dalam desain dan evolusinya. Menurut Spewak yang dikutip Surendro (2009), definisi dari enterprise adalah organisasi (atau badan lintas organisasi) yang mendukung lingkup bisnis dan misi yang telah ditetapkan. Definisi enterprise dapat berarti suatu daerah aktivitas umum dan tujuan dalam sebuah organisasi atau antara beberapa organisasi, dimana informasi dan sumber daya lainnya dipertukarkan (Bernard dalam Sanny dkk., 2012). Dari definisi arsitektur dan enterprise yang berkaitan tersebut dapat disimpulkan bahwa arsitektur enterprise adalah komponen yang saling berkaitan, ataupun prinsip guna mendukung suatu bisnis organisasi. Sesuai dengan Surendro (2009), arsitektur enterprise adalah sekumpulan prinsip, metode dan model yang bersifat masuk akal yang digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi enterprise, proses bisnis, sistem informasi dan infrastrukturnya (Surendro, 2009). Dalam membangun sebuah arsitektur enterprise, dibutuhkan sebuah perencanaan. PAE merupakan pendekatan yang dibuat oleh Spewak (1992) untuk membangun arsitektur enterprise dengan berdasarkan dorongan data dan 9

10 dorongan bisnis. Menurut Surendro (2009), PAE merupakan proses mendefinisikan arsitektur-arsitektur untuk penggunaan informasi yang mendukung bisnis dan juga mencakup rencana untuk mengimplementasikan arsitektur tersebut. 2.2 Kerangka Kerja Perencanaan Arsitektur Enterprise Dalam perencanaan arsitektur enterprise terdapat sebuah kerangka kerja yang dapat menjadi panduan dalam merencanakan arsitektur enterprise tersebut. Menurut CIO Council yang dikutip oleh Setiawan (2009), sebuah architecture framework adalah alat yang bisa digunakan untuk mengembangkan cakupan luas dari arsitektur-arsitektur yang berbeda. Ada banyak kerangka kerja perusahaan arsitektur pada saat ini, dan dari sekian kerangka kerja yang ada selalu ada yang baru dan ditambahkan setiap hari. Beberapa kerangka kerja tersebut adalah sebagai berikut (Minoli, 2008): a. The Open Group Architecture Framework (TOGAF). b. Zachman Enterprise Architecture Framework. c. Extended Enterprise Architecture Framework (E2AF). d. Enterprise Architecture Planning (EAP). e. Federal Enterprise Architecture Framework (FEAF). f. Treasury Enterprise Architecture Framework (TEAF). g. Capgemini s Integrated Architecture Framework (IAF). h. Joint Technical Architecture (JTA). i. Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoDAF.

11 j. Department of Defense Technical Reference Model (DoD TRM). k. Technical Architecture Framework for Information Management (TAFIM). l. Computer Integrated Manufacturing Open System Architecture (CIMOSA). m. Purdue Enterprise Reference Architecture (PERA). n. Standards and Architecture for egovernment Applications (SAGA). o. European Union IDABC & European Interoperability Framework. ISO/IEC 14252 (IEEE Std 1003.0). p. IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description. Dari sekian banyak kerangka kerja yang ada, hanya beberapa yang populer digunakan dikalangan perancang sistem informasi. Hal ini dikuatkan oleh hasil survei Institute for Enterprise Architecture Development (IFEAD) di tahun 2003 pada Gambar 2.1. Kerangka kerja yang paling banyak digunakan dalam dunia industri maupun pemerintahan adalah Zachman, TOGAF, IAF dan FEAF (Setiawan, 2009). Gambar 2.1 Survei Penggunaan EA Framework (Setiawan, 2009) Berdasarkan hasil survei di atas, dapat ditarik dua kerangka kerja yang lebih banyak digunakan dan populer yaitu Zachman Framework dan The Open Group Architecture Framework (TOGAF).

12 2.2.1 Kerangka Kerja Zachman Salah satu kerangka kerja yang paling popular adalah kerangka kerja Zachman. Kerangka kerja ini diperkenalkan oleh John Zachman pada tahun 1980. Kerangka kerja ini bukan sebuah metodologi yang menyebutkan metode dan proses spesifik untuk mengumpulkan, mengelola dan menggunakan informasi yang dituliskan pada sebuah kerangka kerja pada umumnya. Kerangka kerja Zachman lebih mengarah kepada alat untuk taksonomi pengelolaan artifak sebuah arsitektur seperti dokumen perancangan, spesifikasi dan model yang menunjukkan kepada siapa target dari artifak tersebut seperti pemilik organisasi, para pengembang. Dari beberapa artifak yang ada pada organisasi berguna, namun dengan bantuan kerangka kerja Zachman kemudian dapat dipilih artifak yang berguna untuk organisasi, (Surendro, 2009). Kerangka kerja Zachman adalah kerangka kerja arsitektur enterprise yang menyediakan cara untuk memandang dan mendefinisikan sebuah enterprise secara formal dan terstruktur dengan baik. Menurut Rumapea (2007), kerangka kerja Zachman terdiri dari matriks 6x6. Pada kolom merepresentasikan fokus, abstraksi atau topik arsitektur enterprise, yaitu Data (atau What), Fungsi (atau How), Jaringan (atau Where), Manusia (atau Who), Waktu (atau When) dan Motivasi (atau Why). Sedangkan pada urutan baris dari baris pertama hingga baris keenam merepresentasikan perspektif-perspektif sebagai berikut : a. Perspektif Perencana: perencana disini selaku perencana arsitektur yang akan menetapkan konteks, latar belakang dan tujuan enterprise.

13 b. Perspektif Pemilik: pada baris ini pemilik akan menetapkan model-model konseptual dari enterprise. c. Perspektif Perancang: para perancang menetapkan model-model sistem informasi sekaligus menjembatani dan menghubungkan hal-hal yang diinginkan pemilik dan hal-hal yang dapat direalisasikan secara teknis dan fisik. d. Perspektif Pembangun: pada baris ini pembangun sistem menetapkan rancangan teknis dan fisik yang digunakan dalam mengawasi implementasi teknis dan fisik. e. Perspektif Subkontraktor: menetapkan peran dan rujukan bagi pihak yang bertanggung jawab untuk melakukan pembangunan sistem. f. Perspektif Functioning Enterprise: merepresentasikan perspektif pengguna dan wujud nyata hasil implementasi. Dari urutan perspektif tersebut merupakan sebuah urutan kronologis dari perencana sampai ke pengguna. Setiap perspektif memberikan syarat dan batasan pada arsitektur sistem informasi. Tiap perspektif tersebut merupakan representasi lengkap sistem informasi dari berbagai sudut pandang. Dari tiap perspektif inilah nantinya akan memberikan sebuah deskripsi dari arsitektur enterprise, (Surendro, 2009). Kerangka kerja Zacman ditunjukkan seperti sel-sel seperti yang terlihat pada Gambar 2.2.

14 Gambar 2.2 Kerangka Kerja Zachman 2.2.2 TOGAF Architecture Development Method Kerangka kerja populer lainnya adalah The Open Group Architecture Framework atau yang biasa dikenal dengan TOGAF. TOGAF adalah kerangka kerja dan metode yang diterima secara luas dalam pengembangan arsitektur sebuah perusahaan. TOGAF merupakan hasil pengembangan forum Open Group yang merupakan forum kerja antara vendor dan pengguna. Menurut Open Group yang dikutip Yunis (2009), TOGAF merupakan sebuah kerangka kerja yang memberikan detil bagaimana membangun dan mengelola serta mengimplementasikan arsitektur enterprise yang disebut dengan Architecture Development Method (ADM). ADM merupakan metode generik yang berisikan sekumpulan aktivitas yang digunakan dalam memodelkan pengembangan arsitektur enterprise. Metode

15 ini juga bisa digunakan sebagai panduan atau alat untuk merencanakan, merancang, mengembangkan dan mengimplementasikan arsitektur sistem informasi untuk organisasi (Yunis dan Surendro, 2009). TOGAF ADM seperti ditunjukkan pada Gambar 2.3 merupakan metode yang fleksibel yang dapat menggunakan berbagai macam teknik pemodelan yang ada dalam perancangan. Metode ini juga dapat disesuaikan dengan perubahan dan kebutuhan selama perancangan dilakukan, seperti menggabungkan ADM dengan kerangka kerja lainnya sehingga menghasilkan arsitektur yang spesifik terhadap organisasi. TOGAF ADM menyatakan visi dan prinsip yang jelas tentang bagaimana melakukan pengembangan arsitektur enterprise. Prinsip tersebut digunakan sebagai ukuran dalam menilai keberhasilan dari pengembangan arsitektur enterprise oleh organisasi (Open Group, 2009). Prinsip-prinisip tersebut dapat dijelaskan sebagai berikut: a. Prinsip Enterprise, prinsip yang mendukung keputusan bisnis di seluruh bagian organisasi, (Surendro, 2009). b. Prinsip Teknologi Informasi (TI), yang mengarahkan penggunaan sumber daya teknologi informasi di seluruh bagian organisasi, (Surendro, 2009). c. Prinsip Arsitektur, prinsip yang menjelaskan bagaimana mengembangkan arsitektur proses organisasi dan bagaimana mengimplementasikannya. Prinsip ini dipengaruhi oleh rencana organisasi, strategi, faktor pasar, sistem dan teknologi yang ada dalam organisasi. Langkah awal yang perlu diperhatikan pada saat mengimplementasikan TOGAF ADM adalah mendefinisikan persiapan-persiapan yaitu dengan cara mengidentifikasi konteks arsitektur yang akan dikembangkan, kedua adalah

16 mendefinisikan strategi dari arsitektur dan menetapkan bagian-bagian arsitektur yang akan dirancang, yaitu mulai dari arsitektur bisnis, arsitektur sistem informasi, arsitektur teknologi, serta menetapkan kemampuan dari arsitektur yang akan dirancang dan dikembangkan (Harrison dan Varveris dalam Yunis, 2009). Tahapan TOGAF ADM terdiri dari 8 (delapan) fase yang berbentuk seperti siklus yang ditunjukkan pada Gambar 2.3 yaitu : a. Architecture Vision Tahapan Architecture Vision menjelaskan bagaimana menciptakan keseragaman pandangan mengenai pentingnya arsitektur enterprise untuk mencapai tujuan organisasi yang dirumuskan dalam bentuk strategi serta menentukan lingkup dari arsitektur yang akan dikembangkan. Pada tahapan ini berisikan pertanyaan-pertanyaan yang diajukan untuk mendapatkan arsitektur yang ideal. b. Business Architecture Tahapan ini mendefinisikan kondisi awal arsitektur bisnis, menentukan model bisnis atau aktivitas bisnis yang diinginkan berdasarkan skenario bisnis. c. Information System Architecture Pada tahapan ini lebih menekankan pada aktivitas bagaimana arsitektur sistem informasi dikembangkan. Pendefinisian arsitektur sistem informasi dalam tahapan ini meliputi arsitektur data dan arsitektur aplikasi yang akan digunakan oleh organisasi. Arsitekur data lebih memfokuskan pada bagaimana data digunakan untuk kebutuhan fungsi bisnis, proses dan layanan. Teknik yang bisa digunakan dengan yaitu: ER-Diagram, Class Diagram, dan Object Diagram.

17 d. Technology Architecture Membangun arsitektur teknologi yang diinginkan, dimulai dari penentuan jenis kandidat teknologi yang diperlukan dengan menggunakan Technology Portfolio Catalog yang meliputi perangkat lunak dan perangkat keras. Dalam tahapan ini juga mempertimbangkan alternatif-alternatif yang diperlukan dalam pemilihan teknologi. e. Opportunities and Solution Pada tahapan ini lebih menekan pada manfaat yang diperoleh dari arsitektur enterprise yang meliputi arsitektur bisnis, arsitektur data, arsitektur aplikasi dan arsitektur teknologi, sehingga menjadi dasar bagi stakeholder untuk memilih dan menentukan arsitektur yang akan diimplementasikan. f. Migration Planning Pada tahapan ini akan dilakukan penilaian dalam menentukan rencana migrasi dari suatu sistem informasi. Biasanya pada tahapan ini untuk pemodelannya menggunakan matrik penilaian dan keputusan terhadap kebutuhan utama dan pendukung dalam organisasi terhadap implementasi sistem informasi g. Implementation Governance Menyusun rekomendasi untuk pelaksanaan tatakelola implementasi yang sudah dilakukan, tatakelola yang dilakukan meliputi tata kelola organisasi, tatakelola teknologi informasi, dan tatakelola arsitektur. h. Arcitecture Change Management Menetapkan rencana manajemen arsitektur dari sistem yang baru dengan cara melakukan pengawasan terhadap perkembangan teknologi dan perubahan

18 lingkungan organisasi, baik internal maupun eksternal serta menentukan apakah akan dilakukan siklus pengembangan arsitektur enterprise berikutnya. TOGAF ADM juga merupakan metode yang bersifat generik dan mudah di implementasikan berdasarkan kebutuhan banyak organisasi, baik organisasi industri ataupun industri akademik seperti perguruan tinggi (Mutyarini dan Sembiring dalam Yunis, 2009). Gambar 2.3. Architecture development method 2.2.3 Pemilihan Kerangka Kerja Arsitektur Enterprise Menurut Setiawan (2009), dalam memilih sebuah kerangka kerja arsitektur enterprise tidak hanya sekedar memilih, tetapi juga terdapat kriteria yang berbeda yang bisa dijadikan sebagai acuan, seperti:

19 a. Tujuan dari arsitektur enterprise dengan melihat bagaimana definisi arsitektur dan pemahamannya, proses arsitektur yang telah ditentukan sehingga mudah untuk diikuti, dukungan terhadap evolusi arsitektur. b. Input untuk aktivitas arsitektur enterprise seperti pendorong bisnis dan input teknologi. c. Output dari aktivitas arsitektur enterprise seperti model bisnis dan desain transisional untuk evolusi dan perubahan kerangka kerja. Hasil perbandingan yang dilakukan oleh Setiawan (2009), memetakan Zachman framework dan TOGAF kedalam sebuah tabel sebagai bahan pertimbangan dalam pemilihan EA Framework, seperti yang ditunjukkan dalam Tabel 2.1. Tabel 2.1 Perbandingan kerangka kerja arsitektur enterprise antara Zachman Framework dan TOGAF Kriteria Zachman TOGAF Definisi arsitektur dan pemahamannya Parsial Ya, pada fase preliminary Proses arsitektur yang detail Ya Ya, ADM dengan 9 fase yang detail Dukungan terhadap evolusi arsitektur Tidak Ya, ada fase migration planning Architecture knowledge base Tidak Ya Pendorong bisnis Parsial Ya Input teknologi Tidak Ya Model bisnis Ya Ya Desain transisional Tidak Ya, hasil fase migration planning Menyediakan prinsip arsitektur Tidak Ya 2.3 Arsitektur Data Pengertian data di dalam kamus besar bahasa Indonesia (Departemen Pendidikan Nasional, 2008) adalah kenyatan yang ada yang berfungsi sebagai bahan sumber untuk menyusun suatu keterangan yang benar. Pada masing-masing area fungsi dan proses-proses organisasi membutuhkan data dan informasi sejalan dengan pertumbuhan enterprise dan peningkatan kinerjanya. Kepentingan data

20 dalam rencana pengembangan menempatkan pembangunan arsitektur data sebagai langkah pertama dalam visi perencanaan masa depan. Arsitektur data merupakan bagian dari PAE. Menurut Tupper (2011), arsitektur data merupakan model disain strategis yang merupakan landasan untuk kegiatan pembangunan berkelanjutan yang bertumpu pada persetujuan pemilik rencana pengembangan. Menurut Surendro (2009), arsitektur data merupakan kumpulan kebutuhan bisnis suatu organisasi, informasi, satuan proses dan penyatuan yang mengendalikan bisnis organisasi. Arsitektur data juga merupakan suatu aturan bagi organisasi untuk memilih, membangun dan memelihara informasi tersebut. Kerangka arsitektur data menyediakan struktur untuk mendokumentasikan detail informasi yang penting bagi sebuah organisasi atau perusahaan seperti mengidentifikasikan dan mendefinisikan jenis-jenis data utama yang mendukung fungsi-fungsi bisnis yang telah didefinisikan pada model bisnis. arsitektur data menghasilkan model data konseptual yang menguraikan detail data sehingga cukup untuk tujuan perencanaan. Arsitektur data merupakan kumpulan master cetak biru (blue print) terintegrasi pada level abstraksi yang berbeda-beda dan mencakup nama data formal, definisi data komprehensif, struktur data yang efektif, aturan integritas data yang tepat serta dokumentasi data yang tangguh (Setiawan, 2009). Menurut Rumapea (2009), arsitektur data memberikan manfaat seperti menyediakan kosa kata standar untuk identifikasi, definisi dan penamaan jenis data utama yang mendukung bisnis serta digunakan untuk menetapkan kebutuhan sistem aplikasi yang didefinisikan untuk mengelola sekumpulan entitas data.

21 Menurut Surendro (2007), ada tiga tahap dalam pembangunan arsitektur data yaitu pembuatan daftar entitas data, diagram hubungan entitas dan matrik proses bisnis terhadap entitas data. 2.3.1 Daftar entitas data Pada tahap ini dilakukan identifikasi entitas data yang muncul dari fungsi dan proses bisnis. Entitas data ini muncul sebagai kebutuhan untuk menjalankan fungsi dan proses bisnis yang ada di organisasi. 2.3.2 Diagram hubungan-entitas Suatu entitas data dapat menunjang lebih dari satu area fungsi dan tidak berdiri sendiri. Dalam tahap ini menghubungan antar entitas dengan entitas lainnya. Pemodelan dilakukan dengan Entity Relationship Diagram (ERD). 2.3.3 Matriks Proses vs. Entitas Data Matriks proses vs. entitas data merupakan hubungan antara area fungsi dan entitas data adalah dalam hal pembuatan, pengolahan, dan penggunaan data untuk keperluan pemenuhan tujuan fungsi bisnis. Hubungan ini didefinisikan melalui matriks proses terhadap entitas data. Masing-masing sel dalam matriks diisi dengan huruf-huruf: C (create), R (reference) dan U (update). 2.4 Normalisasi data Normalisasi adalah suatu proses yang digunakan dalam menentukan pengelompokan atribut-atribut dalam sebuah relasi sehingga dapat diperoleh relasi

22 yang berstruktur baik, (Kadir, 2008). Normalisasi dapat dikatakan sebagai suatu teknik untuk mengatur atau mengorganisasi data ke dalam tabel-tabel untuk memenuhi kebutuhan pemakai dalam suatu organisasi. Tujuan dari normalisasi sendiri adalah untuk menghilangkan kerangkapan data, mengurangi kompleksitas dan mempermudah pemodifikasian data. Berikut adalah tahapan dalam normalisasi. Bentuk Tidak Normal Menghilangkan Perulangan Bentuk Normal Pertama Menghilangkan Ketergantungan Parsial Bentuk Normal Kedua Menghilangkan Ketergantungan Transitif Bentuk Normal Ketiga Gambar 2.4. Tahapan Normalisasi 1. Bentuk tidak normal (Unnormalized form) merupakan kumpulan data yang akan dicacat dan tidak ada suatu format tertentu. 2. Bentuk normal pertama (1NF / First normal form) adalah suatu keadaan yang menghilangkan atribut yang bernilai ganda. 3. Bentuk normal kedua (2NF / Second normal form) adalah jika relasi sudah berada dalam bentuk normal pertama.

23 4. Bentuk normal ketiga (3NF / Third normal form). Suatu relasi dikatakan memenuhi bentuk normal ketiga apabila sudah memenuhi bentuk normal kedua dan tiap relasi yang ada tidak mempunyai atribut yang bergantung secara transitif terhadap kunci utama. 2.5 Conceptual Data Model / Model Data Konseptual Sebuah model data konseptual merupakan representasi, rincian logis dari sebuah data. Sedangkan model data fisik adalah kelanjutan dari model data konseptual yang menggambarkan data ditingkat internal, desain mutlak dari implementasi suatu database seperti bagaimana sebuah penyimpanan data secara detailnya dengan format record, penyusunan record dan jalur akses. Menurut Connolly dan Begg (2005), dalam membuat model data konseptual digunakan teknik pemodelan Entity Relationship (ER) yang kemudian direpresentasikan dalam Entity Relationship Diagram (ERD). Model ER dinyatakan dalam entitas dalam sebuah lingkungan bisnis, hubungan antara entitas dan atribut dari entitas tersebut (Hoffer, 2005). Menurut Elmasri dan Navathe (2001) Model ER menggambarkan data sebagai entitas, hubungan dan atribut. Entitas adalah objek dalam dunia nyata yang dapat dibedakan dari objek yang lainnya (Ramakhrisnan dan Gehrke, 2003). Menurut Hoffer (2011) entitas dapat berupa individu, sebuah tempat, sebuah objek, suatu peristiwa atau suatu konsep. Atribut adalah properti atau sebuah karakteristik dari suatu entitas (Hoffer et al, 2011). Relationship adalah hubungan di antara dua atau lebih entitas (Ramakhrisnan dan Gehrke, 2003). Relationship adalah sekumpulan relasi yang mempunyai tipe yang sama.

24 Menurut Winarko (2006), kardinalitas relasi adalah sebuah bilangan yang menunjukkan jumlah maksimum elemen dari sebuah entitas yang berelasi dengan elemen dari entitas yang lain. Macam kardinalitas relasi adalah sebagai berikut: a. Satu ke satu : kardinalitas satu ke satu menyatakan bahwa setiap entitas pada tipe entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas B, begitu pula sebaliknya (Kadir, 2009). b. Satu ke banyak : kardinalitas satu ke banyak menyatakan bahwa setiap entitas pada tipe entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B, sedangkan setiap entitas B hanya bisa berpasangan dengan satu entitas pada tipe entitas A (Kadir, 2009). c. Banyak ke satu : kardinalitas banyak ke satu menyatakan bahwa setiap entitas pada tipe entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas B dan setiap entitas pada tipe entitas B bisa berpasangan dengan banyak entitas pada tipe entitas A (Kadir, 2009). d. Banyak ke banyak : kardinalitas banyak ke banyak menyatakan bahwa setiap entitas pada tipe entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B, begitu pula sebaliknya (Kadir, 2009). Menurut Connolly dan Begg (2005) : Tahapan dalam membuat model data konseptual adalah sebagai berikut: a. Mengidentifikasi tipe-tipe entitas yang dibutuhkan oleh basis data. b. Mengidentifikasi tipe-tipe relasi yang terdapat diantara tipe-tipe entitas yang telah diidentifikasi sebelumnya.

25 c. Mengidentifikasi dan menghubungkan atribut-atribut dengan tipe entitas atau dengan tipe relasi yang sesuai dan mendokumenkan setiap atribut secara detail. d. Menentukan domain atribut dalam model konseptual dan mendokumentasikan secara detail setiap domain. e. Menentukan atribut pada kunci kandidat, kunci primer, dan kunci pengganti jika terdapat lebih dari satu kunci kandidat maka harus dipilih satu kunci primer dan kunci pengganti untuk sisanya. f. Mempertimbangkan penggunaan konsep pemodelan tingkat tinggi / enhanced modelling (langkah pilihan), seperti spesialisasi / generalisasi, agregasi, dan komposisi. g. Memeriksa redundansi pada model Mengidentifikasikan apakah ada redundansi dalam model. Aktifitas dalam langkah ini adalah : 1. Memeriksa kembali relasi satu ke satu (1:1). Kemungkinan ada dua entitas yang menggambarkan obyek yang sama dalam organisasi. Oleh karena itu, kedua entitas tersebut harus digabungkan. 2. Menghilangkan relasi yang berlebihan (redundant). Suatu relasi menjadi berlebihan jika informasi yang sama dihasilkan melalui relasi yang berbeda. Untuk meminimalkan data model maka relasi yang berlebihan tersebut harus dihilangkan. 3. Mempertimbangkan dimensi waktu. Dimensi waktu yang dimaksud meliputi situasi dan kondisi, seperti relasi kekeluargaan.

26 h. Memvalidasi model konseptual dengan transaksi pengguna dengan menjamin model konseptual dapat mendukung kebutuhan proses bisnis yang dibutuhkan oleh pengguna. i. Memeriksa model data konseptual dengan pengguna dengan melakukan pemeriksaan terhadap model data konseptual dengan pengguna untuk menjamin model telah merepresentasikan sudut pandang pengguna berdasarkan kebutuhan perusahaan. 2.5 Sistem Manajemen Basis Data Basis data menurut Hoffer (2005) adalah kumpulan data yang saling berkaitan. Menurut Connolly (2005) basis data merupakan kumpulan data yang saling berhubungan, yang didesain sedemikian rupa untuk memenuhi kebutuhan informasi organisasi. Sistem Manajemen Basis Data atau Database Management System (DBMS) menurut Connolly (2005) adalah suatu sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, dan memelihara database dan juga menyediakan akses terkontrol ke database. Menurut Neeraj Sharma (2010) Sistem Manajemen Database, atau sering disingkat DBMS, adalah satu set perangkat lunak yang merupakan suatu kontrol akses, mengatur, menyimpan, mengelola, mengambil dan memelihara data dalam database. DMBS merupakan program untuk pengelolaan kumpulan file yang saling berkaitan yang berguna untuk membaca data, mengisi data, menghapus data dan melaporkan data dalam database.

27 Beberapa fungsi dari DBMS menurut Connolly dan Begg (2005) : 1. Data Storage, Retrieval dan Update Sebuah DBMS harus menyediakan pengguna dengan kemampuan untuk menyimpan, mengambil dan mengubah data dalam basis data. 2. A User-Accessible Catalog Sebuah DBMS harus menyediakan sebuah catalog dimana deskripsi dari data disimpan dan yang diakses oleh pengguna. 3. Transaction Support DBMS harus menyediakan suatu mekanisme yang dapat memastikan dengan baik semua update berhubungan dengan transaksi yang diberikan dibuat atau tidak satupun dari update tersebut dibuat. 4. Concurrency Control Services DBMS harus meyediakan suatu mekanisme untuk memastikan bahwa basis data ter-update dengan benar ketika beberapa pengguna meng-update basis data pada waktu yang bersamaan. 5. Recovery Service DBMS harus menyediakan suatu mekanisme untuk memperbaiki basis data yang rusak karena suatu kejadian. 6. Authorization Service DBMS harus menyediakan sebuah mekanisme untuk memastikan bahwa hanya pengguna yang diberikan otoritas yang dapat mengakses basis data. 7. Support For Data Communication DBMS harus mampu berintegrasi dengan komunikasi perangkat lunak.

28 8. Integrity Services DBMS harus menyediakan saran untuk memastikan bahwa data di dalam basis data dan perubahan data mengikuti aturan tertentu. 9. Service To Promote Data Independence DBMS harus memasukkan fasilitas-fasilitas untuk mendukung programprogram independen dari struktur actual dari basis data. 10. Utility Services DBMS seharusnya menyediakan sekumpulan untility services agar basis data dapat dikelola secara efektif. Menurut Connolly dan Begg (2005), beberapa tahapan bertujuan untuk memilih DBMS yang tepat untuk mendukung sistem basis data seperti : 1. Define terms of reference of study, mendefinisikan dan pemilihan DBMS yang sesuai dengan tujuan dan ruang lingkup penelitian serta tugas-tugas yang harus dilakukan, sesuai spesifikasi kebutuhan pengguna, daftar DBMS yang tersedia dan batasan serta jadwal waktu untuk penelitian. 2. Shortlist two or three products, membuat daftar berbagai produk DBMS yang ada untuk dievaluasi. Memilih produk DBMS tertentu yang sesuai dengan anggaran organisasi, dukungan vendor dan kecocokan dengan perangkat lunak yang lain. 3. Evaluate products, untuk kepentingan evaluasi, fitur-fitur ini dapat berupa groups (seperti definisi data) atau individu (tipe data yang tersedia. 4. Recommend selection and produce report, tahap akhir dari pemilihan DBMS adalah untuk mendokumentasikan proses dan untuk menyediakan laporan dan rekomendasi untuk sebuah produk DBMS tertentu.