BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Teori Umum Teori Basis Data Menurut Connolly dan Begg (2010, p65), basis data adalah sekumpulan data yang terelasi secara logikal beserta dengan deskripsinya, dirancang untuk memenuhi kebutuhan informasi dari sebuah organisasi. Sedangkan sistem basis data adalah sekumpulan aplikasi yang berinteraksi dengan basis data melalui Database Management System (DBMS) dan basis data itu sendiri (Connolly dan Begg, 2010, p54). Menurut Kroenke dan Auer (2010, p8), basis data adalah sekumpulan tabel-tabel terelasi dan struktur lainnya. Menurut Edhy Tri Cahyono (2009) pada Jurnal Perancangan Basis Data: Antara Pendekatan Model Entity Relationship Dan Model Relasional menyatakan bahwa basis data adalah salah satu komponen sistem informasi yang mempunyai posisi yang sangat menentukan dalam menunjang keberhasilan suatu sistem informasi. Berdasarkan definisi pada sumber di atas, dapat disimpulkan bahwa basis data adalah sekumpulan data dengan relasi logikal satu sama lain beserta deskripsinya dan dirancang untuk memenuhi dan menunjang keberhasilan kebutuhan informasi yang digunakan oleh sistem aplikasi perusahaan. Sedangkan sistem basis data adalah sistem terkomputerisasi dalam bentuk aplikasi yang berinteraksi dengan basis data melalui DBMS 7

2 8 dan basis data itu sendiri yang bertujuan untuk menyimpan dan memungkinkan pengguna untuk melakukan manipulasi terhadap informasi sesuai dengan kebutuhan secara keseluruhan Database Management System (DBMS) Menurut Connolly dan Begg (2010, p66), Database Management System adalah sistem perangkat lunak yang memungkinkan pengguna untuk melakukan definisi, membuat, mengelola, dan mengatur akses terhadap basis data. Menurut Kroenke dan Auer (2010, p8), Database Management System adalah program komputer yang digunakan untuk membuat, memproses, dan mengatur administrasi basis data. Berdasarkan sumber definisi diatas, dapat disimpulkan bahwa Database Management System adalah sistem perangkat lunak yang digunakan untuk mendefinisikan, membuat, memproses, dan memungkinkan penggunanya untuk melakukan berbagai manipulasi terhadap data Komponen lingkungan DBMS Menurut Connolly dan Begg (2010, p68-71), terdapat 5 komponen utama dalam DBMS Environment, yaitu hardware, software, data, procedures, dan people.

3 9 Gambar 2.1 Komponen DBMS Environment (Sumber: Connolly dan Begg, 2010, p68) 1. Hardware Agar dapat berjalan, pengaplikasian DBMS memerlukan perangkat keras yang terdiri dari single personal computer, single mainframe, atau network of computers. Tidak semua DBMS dapat berjalan pada bermacam-macam perangkat keras serta sistem operasi. 2. Software Komponen perangkat lunak terdiri atas perangkat lunak DBMS dan program aplikasi beserta sistem operasi termasuk perangkat lunak jaringan apabila DBMS digunakan dalam sebuah jaringan. 3. Data Data sebagai salah satu komponen penting dalam DBMS berdasarkan sudut pandang pengguna adalah sebagai penghubung antara komponen mesin (perangkat keras) dengan komponen manusia.

4 10 4. Procedures Prosedur berisi instruksi-instruksi dan aturan-aturan yang mengatur suatu rancangan dan penggunaan basis data. Proses yang terdapat di dalamnya adalah: a. login ke dalam basis data b. penggunaan fasilitas DBMS c. memulai dan mengakhiri DBMS d. membuat backup basis data e. menangani kegagalan perangkat keras dan perangkat lunak f. mengubah struktur tabel, mengatur ulang basis data melalui multiple disk, meningkatkan kinerja atau arsip data pada secondary storage 5. People Manusia sebagai salah satu komponen yang terlibat dalam proses sistem basis data, dapat diidentifikasikan antara lain sebagai data administrators, database administrators, database designers, application developers, dan end users Keuntungan DBMS Menurut Connolly dan Begg (2010, p77-81), terdapat 14 keuntungan dari penggunaan DBMS yaitu: 1. Control of data redundancy Pendekatan basis data yang ditujukan untuk mengeliminasi redundansi dengan mengintegrasikan file-file

5 11 sehingga banyaknya file dari data yang sama tidak disimpan. Pendekatan tersebut tidak menghilangkan redundansi secara keseluruhan, tetapi mengontrol jumlah redundansi yang terjadi. 2. Data consistency Dengan menghilangkan atau mengontrol redundansi akan meminimalisir resiko tidak konsisten yang muncul terhadap data. Data disimpan hanya sekali dalam basis data, setiap update yang dilakukan menghasilkan perubahan untuk semua pengguna sesegera mungkin. 3. More information from the same amount of data Dengan terintegrasinya data operasional, memungkinkan organisasi untuk memperoleh informasi tambahan melalui data tersebut. 4. Sharing of data Basis data suatu organisasi digunakan oleh pengguna yang memiliki otorisasi. Sejauh ini, penggunaan data dalam membangun sebuah aplikasi adalah data yang sudah disediakan, sedangkan untuk data yang akan ditambahkan belum tentu masuk kedalam DBMS melainkan hanya digunakan untuk mendefinisikan persyaratan yang ada. Aplikasi yang baru juga dapat digunakan untuk definisi dan manipulasi data.

6 12 5. Improved data integrity Integritas basis data menunjukkan validitas dan konsistensi data yang disimpan. Integritas biasanya disesuaikan dengan constraint. 6. Improved security Keamanan basis data adalah perlindungan basis data terhadap pengguna-pengguna yang tidak berwenang. Akses yang diperbolehkan terhadap pengguna yang memiliki wewenang dibatasi oleh operasi tertentu (retrieval, insert, update, delete). 7. Enforcement of standards Integrasi memperbolehkan Database Administrator (DBA) untuk mendefinisikan dan menegaskan standar-standar yang diperlukan, meliputi skala departemen, organisasi, nasional, maupun internasional. 8. Economy of scale Dengan menggabungkan seluruh data operasional organisasi kedalam suatu basis data dan membuat sebuah set aplikasi pada satu sumber data yang berdampak terhadap penghematan biaya. 9. Balance of conflicting requirements Setiap pengguna atau departemen memiliki kebutuhankebutuhan yang memungkinkan terjadinya konflik terhadap kebutuhan dari pengguna lainnya. Karena basis data

7 13 dikendalikan DBA, maka DBA dapat membuat keputusan tentang perancangan dan operasional dari basis data. Keputusan yang dihasilkan akan mendukung performa yang optimal pada aplikasi tersebut. 10. Improved data accessibility and responsiveness Sebagai dampak dari integrasi, data dapat diakses secara langsung oleh end user melalui batasan antar departemen. 11. Increased productivity DBMS menyediakan berbagai fungsi standar yang memungkinkan programmer untuk berkonsentrasi pada fungsionalitas spesifik yang dibutuhkan oleh user tanpa harus mengkhawatirkan rincian low-level implementation. Hal ini meningkatkan produktivitas dari programmer dan mengurangi waktu pengembangan serta efisiensi terhadap biaya. 12. Improved maintenance through data independence Deskripsi dari data dan logika yang digunakan untuk mengakses data antar aplikasi satu sama lainnya, menyebabkan program tergantung dengan data. DBMS memisahkan deskripsi data dari aplikasi sehingga menghilangkan ketergantungan. 13. Increased concurrency Dalam basis data, jika terdapat dua atau lebih pengguna mengakses data yang sama secara bersamaan, maka akan mengakibatkan terjadinya kehilangan informasi atau

8 14 kehilangan integritas. DBMS mengelola akses konkurensi basis data dan meyakinkan agar masalah pengaksesan data tersebut tidak terjadi. 14. Improved backup and recovery services File-based systems menyediakan batasan dan ukuran untuk melindungi data dari kegagalan sistem operasi maupun program aplikasi melalui layanan backup dan recovery Kerugian DBMS Menurut Connolly dan Begg (2010, p80-81), terdapat 7 kerugian dari penggunaan DBMS yaitu: 1. Complexity Ketentuan yang diharapkan dari fungsionalitas DBMS yang baik, menjadikannya sebagai perangkat lunak dengan kompleksitas yang sangat tinggi. 2. Size Karena kompleksitas dan kedalaman dari fungsionalitas, DBMS memerlukan kapasitas penyimpanan yang besar. 3. Cost of DBMS Variasi dari biaya DBMS secara signifikan bergantung pada lingkungan dan fungsionalitas yang tersedia.

9 15 4. Additional hardware costs Kapasitas penyimpanan yang dibutuhkan DBMS dan basis data menyebabkan pembelian kapasitas penyimpanan tambahan. 5. Cost of conversion Biaya yang dibutuhkan DBMS dan perangkat keras tambahan dibandingkan dengan biaya konversi aplikasi yang telah ada sebelumnya untuk menjalankan DBMS dan perangkat keras yang baru. 6. Performance DBMS digunakan untuk melayani lebih dari satu aplikasi, sehingga tidak memiliki performa yang sebagaimana mestinya. 7. Greater impact of a failure Sentralisasi dari sumber daya meningkatkan kerentanan dari sebuah sistem dikarenakan semua pengguna dan aplikasi bergantung pada DBMS Fungsi DBMS Menurut Connolly dan Begg (2010, p ), fungsifungsi yang terdapat pada Database Management System (DBMS) meliputi: 1. Data storage, retrieval, dan update

10 16 DBMS harus menyediakan kemampuan untuk melakukan store, retrieve, dan update data terhadap basis data bagi pengguna. 2. A user-accesible catalog DBMS harus menyediakan sebuah catalog yang mendeskripsikan data items yang disimpan dan diakses oleh pengguna. 3. Transaction support DBMS harus menyediakan mekanisme yang memastikan bahwa seluruh updates dari transaksi yang diberikan berhasil dibuat atau tidak ada transaksi yang dibuat. 4. Concurrency control services DBMS harus menyediakan mekanisme yang memastikan bahwa basis data di-update dengan benar jika beberapa pengguna melakukan update basis data secara bersamaan. 5. Recovery services DBMS harus menyediakan mekanisme pengembalian basis data jika mengalami kerusakan. 6. Authorization services DBMS harus menyediakan mekanisme agar hanya pengguna berwenang yang dapat melakukan akses pada basis data. 7. Support for communication data

11 17 DBMS harus mampu diintegrasikan dengan perangkat lunak komunikasi. 8. Integrity services DBMS harus menyediakan sarana agar seluruh data dan perubahan data di dalamnya mengikuti aturan tertentu. 9. Services to promote data independence DBMS harus mencakup fasilitas yang mendukung independence programs dari struktur aktual basis data. 10. Utility services DBMS harus menyediakan utility services tertentu, contohnya: a. Fasilitas import untuk load basis data dari flat files, dan sebaliknya fasilitas export untuk unload basis data kepada flat files. b. Fasilitas monitoring untuk mengawasi penggunaan dan operasi basis data. c. Statistical analysis programs untuk memeriksa kinerja dan statistik pemakaian. d. Fasilitas index reorganization untuk merombak indexes dan overflow. e. Garbage collection dan reallocation untuk menghapus records secara fisik dari storage devices, konsolidasi terhadap space released, dan alokasi kembali saat dibutuhkan.

12 Fasilitas yang terdapat di DBMS Menurut Connolly dan Begg (2010, p66), secara khusus, sebuah DBMS menyediakan fasilitas-fasilitas sebagai berikut: 1. Memperbolehkan pengguna untuk melakukan definisi terhadap basis data, umumnya melalui Data Definition Language (DDL). DDL memungkinkan pengguna melakukan spesifikasi terhadap tipe-tipe data dengan struktur beserta constraints dari data tersebut untuk disimpan ke dalam basis data. 2. Memperbolehkan pengguna untuk melakukan insert, update, delete dan retrieve data dari basis data, umumnya melalui Data Manipulation Language (DML). Memiliki central repository terhadap seluruh data dan deskripsinya yang memungkinkan DML untuk menyediakan fasilitas general inquiry terhadap data tersebut yang dikenal sebagai query language. 3. Menyediakan akses kontrol terhadap basis data sebagai berikut: a. Sistem keamanan yang mencegah pengguna tidak berwewenang melakukan akses terhadap basis data. b. Sistem integritas yang mengelola konsistensi data yang disimpan. c. Sistem pengendalian konkurensi yang mengijinkan berbagi akses basis data.

13 19 d. Sistem pengendalian pemulihan yang melakukan restorasi basis data terhadap kondisi sebelumnya terkait kegagalan perangkat lunak maupun perangkat keras. e. User-accessible catalog yang berisi deskripsi-deskripsi data di dalam basis data Database System Development Lifecycle Menurut Connolly dan Begg (2010, p313), tahapan-tahapan yang terdapat di dalam Database System Development Lifecycle adalah sebagai berikut: Gambar 2.2 Tahapan-tahapan dari DBLC (Sumber: Connolly dan Begg, 2010, p314)

14 Database Planning Menurut Connolly dan Begg (2010, p ), Database Planning (Perancangan Basis Data) adalah aktivitas manajemen yang memungkinkan tahapan-tahapan pengembangan sistem basis data untuk direalisasikan secara efektif dan efisien. Perencanaan basis data harus diintegrasikan dengan keseluruhan strategi sistem informasi dari organisasi. Terdapat 3 masalah utama dalam merumuskan sistem informasi, yaitu: 1. Mengidentifikasikan rencana dan tujuan perusahaan dengan menentukan kebutuhan berikutnya dari sistem informasi. 2. Melakukan evaluasi terhadap sistem informasi untuk menjelaskan kelebihan dan kekurangan yang ada saat ini. 3. Melakukan penilaian dari kesempatan-kesempatan teknologi informasi yang memungkinkan dihasilkannya keuntungan kompetitif. Tahap pertama yang penting dalam perencanaan basis data adalah mendefinisikan secara jelas mission statement untuk sistem basis data. Mission statement menjelaskan tujuan utama dari sistem basis data tersebut. Jika mission statement sudah didefinisikan, tahap selanjutnya adalah mengidentifikasikan mission objectives. Setiap mission objectives harus mengidentifikasikan tugas-tugas tertentu yang mendukung sistem basis data.

15 System Definition Menurut Connolly dan Begg (2010, p316), System Definition adalah menjelaskan ruang lingkup, batasan-batasan dari sistem basis data dan major user view. User view tersebut mendefinisikan apa yang dibutuhkan oleh sebuah sistem basis data dari berbagai perspektif bagian pekerjaan (contoh manager, supervisor) atau area aplikasi perusahaan (contoh marketing, stock control). Sebelum mencoba untuk merancang sistem basis data, hal pokok pertama yang diperlukan adalah melakukan identifikasi terhadap batasan-batasan dari sistem yang sedang diteliti dan bagaimana interface memiliki relevansi dengan bagian lain dari sistem informasi organisasi tersebut. System definition sangat penting dimana batasan-batasan pada sistem tidak hanya terbatas pada pengguna maupun aplikasi untuk saat ini, tetapi turut dihadapkan kepada pengguna dan aplikasi pada masa yang akan datang. Sebuah sistem basis data dapat memiliki satu atau lebih user views. Identifikasi terhadap user view merupakan bagian yang penting karena memastikan bahwa tidak ada pengguna yang terlupakan dalam pengembangan sistem basis data tersebut. User view mendefinisikan apa yang diperlukan dari sebuah sistem basis data dengan ketentuan dari data dan transaksi yang ditampilkan. Kebutuhan-kebutuhan daripada user view membedakan antara

16 sudut pandang yang ada maupun yang tumpang tindih terhadap satu sama lainnya Requirement Collection and Analysis Menurut Connolly dan Begg (2010, p ), Requirement Collection and Analysis adalah proses pengumpulan dan analisis informasi terhadap bagian dari suatu organisasi yang didukung dengan sistem basis data dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan-kebutuhan yang akan digunakan pada sistem baru. Tahapan-tahapan ini melibatkan pengumpulan dan analisis informasi mengenai bagian perusahaan yang didukung oleh teknologi basis data. Terdapat beberapa teknik dalam pengumpulan informasi melalui metode fact finding. Informasi dikumpulkan dengan tujuan untuk setiap major user view yang meliputi deskripsi data, rincian penggunaan data dan tambahan kebutuhan untuk sistem basis data baru. Informasi yang telah dikumpulkan tersebut kemudian dianalisa untuk mengidentifikasikan kebutuhan-kebutuhan yang akan dimasukkan ke dalam sistem basis data baru sebagai requirements specifications. Beberapa contoh requirements specifications techniques meliputi Structured Analysis and Design (SAD) techniques, Data Flow Diagrams (DFD), dan Hierarchical Input Process Output

17 23 (HIPO) charts supported by documentation. Aktivitas penting lainnya yang terkait pada tahapan ini adalah menentukan bagaimana menghadapi situasi dimana terdapat lebih dari satu sudut pandang pengguna pada sistem basis data. Terdapat tiga pendekatan utama dalam mengelola kebutuhan-kebutuhan sistem basis data, yaitu: 1. The centralized approach Kebutuhan-kebutuhan setiap user view digabungkan menjadi sekumpulan kebutuhan sistem basis data baru. Sebuah model data mewakili seluruh user views yang dibuat selama tahapan perancangan basis data. 2. The view integration approach Kebutuhan-kebutuhan setiap user view tersisa sebagai daftar terpisah. Model data mewakili setiap user view yang dibuat dan kemudian digabungkan setelahnya selama tahapan perancangan basis data. 3. A combination of both approaches Merupakan penggabungan kedua pendekatan diatas yang digunakan pada sistem basis data yang bersifat kompleks Database Design Menurut Connolly dan Begg (2010, p ), Database Design adalah proses perancangan yang mendukung sasaran dan tujuan dari perusahaan terhadap sistem basis data yang

18 24 diperlukan. Terdapat 2 pendekatan utama dalam perancangan basis data yang meliputi: 1. Pendekatan bottom-up Pendekatan yang dimulai pada level fundamental dari atribut-atribut yang meliputi properties of entities dan relationship melalui analisis antar atribut dan dikelompokkan kedalam relasi yang mewakili tipe-tipe entitas serta hubungan antar entitas. Pendekatan bottom-up ini baik digunakan untuk perancangan basis data sederhana dengan jumlah atribut yang relatif sedikit. 2. Pendekatan top-down Pendekatan yang dimulai dengan membangun modelmodel data yang berisikan beberapa high level entities dan relationship yang diaplikasikan secara top-down disertai dengan perbaikan-perbaikan untuk mengidentifikasikan lower level entities, relationships dan associated attributes. Pendekatan top-down ini menggambarkan penggunaan konsep dari Entity Relationship (ER) model yang dimulai dengan mengidentifikasikan entitas dan hubungan antar entitas. Pada tahapan ini, terdapat data modeling yang berfungsi sebagai bantuan dalam memahami pengertian (semantik) dari data serta merupakan fasilitas komunikasi terhadap informasi yang

19 25 dibutuhkan. Pemahaman yang diperoleh melalui penggunaan data model adalah: a. Perspektif dari data setiap pengguna b. Kealamian dari data tersebut, kebebasan representasi fisiknya c. Penggunaan data berdasarkan sudut pandang pengguna Kriteria yang diperlukan untuk memperoleh model data yang optimal yaitu: 1. Structural validity Konsistensi melalui cara yang telah ditentukan oleh perusahaan dan informasi dari suatu organisasi. 2. Simplicity Kemudahan pemahaman yang ditujukan kepada information system professionals dan non-technical users. 3. Expressibility Kemampuan untuk membedakan antar data yang berbeda, hubungan dan batasan-batasan yang terdapat pada data tersebut. 4. Non redundancy Pengecualian terhadap informasi yang berlebihan. Representasi dari suatu informasi tepatnya hanya satu kali. 5. Shareability Tidak memiliki batasan yang spesifik terhadap aplikasi dan teknologi tertentu sehingga dapat digunakan oleh banyak user.

20 26 6. Extensibility Kemampuan evolusi yang mendukung kebutuhankebutuhan baru dengan dampak minimalis yang berasal dari pengguna. 7. Integrity Konsistensi terhadap cara dan batasan yang digunakan perusahaan dalam mengatur informasi. 8. Diagrammatic representation Kemampuan untuk merepresentasikan sebuah model menggunakan diagrammatic notation yang mudah dipahami. Pendekatan lainnya di dalam perancangan basis data adalah pendekatan inside-out dan pendekatan the mixed strategy. Pendekatan inside-out memiliki relevansi dengan pendekatan bottom-up namun dibedakan berdasarkan identifikasi yang dimulai dengan sekumpulan entitas utama dan dilanjutkan terhadap entitas lainnya, hubungan-hubungan dan atribut terkait entitas yang telah teridentifikasi sebelumnya. Sementara pendekatan the mixed strategy menggunakan penggabungan dua pendekatan antara bottom-up dengan top-down pada beberapa bagian-bagian model sebelum disatukan secara keseluruhan. Menurut Connolly dan Begg (2010, p ), Design Methodology adalah pendekatan terstruktur yang menggunakan

21 27 procedures, techniques, tools dan documentation aids untuk mendukung dan memfasilitasi proses perancangan. Metodologi perancangan terdiri dari tahapan yang masingmasing berisikan sejumlah langkah panduan bagi perancang baik dalam perencanaan, pengaturan, kontrol, dan evaluasi terhadap pengembangan basis data. Dalam merepresentasikan basis data, proses perancangan dikelompokkan dalam tiga tahapan utama yaitu conceptual, logical, dan physical database design. Langkahlangkah yang ada pada ketiga tahapan utama tersebut meliputi: 1. Conceptual database design Step 1: Build conceptual data model Step 1.1 Step 1.2 Step 1.3 Identify entity types Identify relationship types Identify and associate attributes with entity or relationship types Step 1.4 Step 1.5 Determine attribute domains Determine candidate, primary, and alternate key attributes Step 1.6 Consider use of enhanced modeling concepts (optional step) Step 1.7 Step 1.8 Check model for redundancy Validate conceptual data model againts user transactions Step 1.9 Review conceptual data model with user

22 28 2. Logical database design Step 2: Build and validate logical data model Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5 Step 2.6 Derive relations for logical data model Validate relations using normalization Validate relations against user transactions Check integrity constraints Review logical data model with user Merge logical data models into global model (optional step) Step 2.7 Check for future growth 3. Physical database design Step 3: Translate logical data model for target DBMS Step 3.1 Step 3.2 Step 3.3 Design base relations Design representation of derived data Design general constraints Step 4: Design file organizations and indexes Step 4.1 Step 4.2 Step 4.3 Step 4.4 Analyze transactions Choose file organizations Choose indexes Estimate disk space requirements Step 5: Design user views Step 6: Design security mechanisms Step 7: Consider the introduction of controlled redundancy Step 8: Monitor and tune the operational system

23 Conceptual Database Design Proses membangun sebuah data model yang digunakan oleh perusahaan, bersifat independent terhadap seluruh pertimbangan fisikal yang ada. Pada tahapan ini, perancangan dimulai dengan membuat model data konseptual dari perusahaan terhadap rincian implementasi seperti target DBMS, application programs, programming languages, hardware platform, performance issues, atau physical consideration lainnya. Langkah-langkah yang terdapat dalam conceptual database design adalah: 1. Identify entity types Bertujuan untuk mengidentifikasi tipe entitas dan objek utama yang dibutuhkan sesuai dengan kebutuhan user. Salah satu metode yang digunakan untuk identifikasi entitas adalah dengan memeriksa users requirements specification. Melalui spesifikasi ini, dilakukan identifikasi terhadap nouns atau noun phrases yang disebutkan (misalnya: staff number, staff name, property number, property address, rent, number of rooms) serta turut memperhatikan objek utama lainnya yaitu people, places atau concepts of interest diluar noun lain sebagai kualitas objek lainnya.

24 30 2. Identify relationship types Bertujuan untuk mengidentifikasi important relationships yang muncul antar tipe entitas dengan melakukan beberapa hal yaitu menggunakan Entity Relationship (ER) diagrams, menentukan multiplicity constraints dari relationship types yang ada, memeriksa fan dan chasm traps serta mendokumentasikan relationship types tersebut. 3. Identify and associate attributes with entity or relationship types Bertujuan untuk menghubungkan atributatribut terkait dengan entitas atau tipe yang telah disesuaikan. Terdapat beberapa macam atribut yaitu simple atau composite attributes, single atau multivalued attributes, dan derived attributes. 4. Determine attribute domains Bertujuan untuk menentukan domain dari attributes yang terdapat pada model data konseptual serta melakukan dokumentasi terhadap setiap rinciannya. Domain merupakan sekumpulan nilai dari satu atau lebih atribut yang menggambarkan nilainya.

25 31 5. Determine candidate, primary, and alternate key attributes Bertujuan untuk mengidentifikasi candidate keys setiap entitas dan memilih sebuah primary key sebagai simbolik yang unik dari beberapa candidate yang tersedia, turut mengelompokkan alternate keys lainnya. 6. Consider use of enhanced modeling concepts (optional step) Bertujuan untuk mempertimbangkan penggunaan dari modeling concepts semisal specialization atau generalization, aggregation, dan composition. Pada tahap ini, pengembangan terhadap ER model dilakukan dengan menggunakan beberapa konsep modeling yang tersedia. 7. Check model for redundancy Bertujuan untuk memeriksa redundansi pada model dengan objek spesifik dan menghilangkan keberadaannya. Terdapat 3 aktivitas pada langkah ini yaitu: a. Memeriksa hubungan one-to-one (1:1) relationships b. Menghilangkan redundansi relationships c. Mempertimbangkan dimensi waktu

26 32 8. Validate conceptual data model against user transactions Bertujuan untuk memastikan bahwa conceptual data model mendukung transaksi-transaksi yang diperlukan. Dua pendekatan yang digunakan sebagai berikut: a. Menjelaskan transaksi-transaksi b. Menggunakan jalur transaksi 9. Review conceptual data model with user Bertujuan untuk melakukan review pada conceptual data model terhadap user sekaligus meyakinkan pertimbangan model tersebut sebagai representasi sebenarnya terhadap kebutuhan data suatu perusahaan. Apabila ditemukan adanya anomali data, maka dilakukan perbaikan yang diperlukan dan disesuaikan dengan pengulangan atas langkah-langkah yang ada Logical Database Design Proses membangun sebuah data model yang digunakan perusahaan berdasarkan sebuah spesifik model data, tetapi independent terhadap particular DBMS dan physical consideration lainnya dengan tujuan menterjemahkan conceptual data model ke dalam

27 33 logical data model, lalu divalidasikan untuk memeriksa kebenarannya agar mampu mendukung transaksi yang diperlukan. Langkah-langkah yang terdapat dalam logical database design adalah: 1. Derive relations for logical data model Bertujuan untuk membangun relasi logical data model yang merepresentasikan entitas, relasi, dan atribut yang telah teridentifikasi. Relasi yang diturunkan dari conceptual data model meliputi: a. Strong entity types b. Weak entity types c. One-to-many (1:*) binary relationship types d. One-to-one (1:1) binary relationship types: 1) Mandatory participation on both sides of 1:1 relationship 2) Mandatory participation on one sides of 1:1 relationship 3) Optional participation on both sides of 1:1 relationship e. One-to-one (1:1) recursive relationship types f. Superclass/subclass relationship types g. Many-to-many (*:*) binary relationship types h. Complex relationship types i. Multi-valued attributes

28 34 Tabel 2.1 Pemetaan dari Entities dan Relationships Entity/Relationship Mapping Strong entity Membuat suatu relasi yang menyertakan keseluruhan simple attributes. Weak entiy Membuat suatu relasi yang menyertakan keseluruhan simple attributes (kemudian harus dilakukan identifikasi terhadap primary key setelah dilakukan mapping hubungan dengan setiap owner entity). 1:* binary relationship Menyertakan primary key dari suatu entitas pada sisi one yang bertindak sebagai foreign key ke relasi yang mempresentasikan entitas pada sisi many. Atribut daripada relasi juga disertakan pada sisi many. 1:1 binary relationship (a) Mandatory participation on both sides Menggabungkan entitas-entitas ke dalam satu relasi. Menyertakan primary key entitas pada sisi optional sebagai suatu (b) Mandatory participation on entitas yang merepresentasikan one side entitas pada sisi mandatory. (c) Optional participation on one Tidak beraturan dengan tanpa side further information. Superclass/subclass relationship Lihat pada table 2.2 *:* binary relationship, Complex relationship Membuat representasi relasi yang menghubungkan dan termasuk di

29 35 dalamnya atribut yang terdapat di relationship tersebut. Menyertakan duplikat primary keys dari setiap owner entities ke dalam suatu relasi baru sebagai foreign keys. Multi-valued attribute Merepresentasikan sebuah ketergantungan antar atribut dalam suatu relasi, sehingga untuk setiap nilai A terdapat satu set nilai untuk B dan satu set nilai untuk C. Namun, set nilai untuk B dan C yang independen satu sama lain. Tabel 2.2 Representasi dari Subclass/Relationships Participation Disjoint Constraint Relations Required Constraint Mandatory Nondisjoint {And} Relasi tunggal (dimana terdapat satu atau lebih discriminators untuk membedakan tipe setiap tuple). Optional Nondisjoint {And} Dua relasi: satu relasi untuk superclass dan satu relasi untuk seluruh subclasses, (terdapat satu atau lebih discriminators untuk membedakan tipe setiap tuple). Mandatory Disjoint {Or} Banyak relasi: satu relasi yang ditujukan untuk

30 36 kombinasi yang terdapat dari superclass/subclass. Optional Disjoint {Or} Banyak relasi: satu relasi ditujukan pada superclass dan satu untuk masingmasing subclass. 2. Validate relations using normalization Bertujuan untuk melakukan validasi atas relasi yang terdapat pada logical data model dengan menggunakan teknik normalisasi. Penggunaan teknik tersebut diperlukan untuk mengidentifikasi ketergantungan fungsional antar atribut setiap relasi yang melalui beberapa langkah dalam menentukan komposisi atribut suatu relasi, yaitu 1NF, 2NF, dan 3NF, dst. Untuk menghindari redundansi data, disarankan agar setiap relasi sekurang-kurangnya mencapai hingga 3NF. 3. Validate relations against user transactions Bertujuan untuk memastikan bahwa relasi di dalam logical data model dapat mendukung transaksi-transaksi yang diperlukan sesuai dengan spesifikasi kebutuhan user. 4. Check integrity constraints

31 37 Bertujuan untuk memeriksa integrity constraints yang direpresentasikan di dalam logical data model. Beberapa tipe dari integrity constraints yang menjadi pertimbangan adalah: a. Required data Terdapat beberapa atribut yang seharusnya memiliki nilai valid atau tidak boleh null. b. Atribute domain constraints Setiap atribut memiliki sebuah domain yang berupa kumpulan dari nilai yang memenuhi persyaratan-persyaratan. c. Multiplicity Merepresentasikan batasan jumlah yang terdapat pada hubungan antara data yang satu dengan data lainnya di dalam basis data. d. Entity integrity Primary key yang terdapat pada sebuah entitas tidak boleh bernilai null. e. Referential integrity Sebuah foreign key menghubungkan setiap tuple di dalam child relation dengan tuple di dalam parent relation yang berisikan nilai candidate key yang bersesuaian. f. General constraints

32 38 Batasan-batasan umum dimana updates di dalam suatu entitas ditentukan berdasarakan representasi yang berasal dari real worlds. 5. Review logical data model with user Bertujuan untuk melakukan review terhadap logical data model dengan user untuk meyakinkan bahwa model yang menjadi pertimbangan merepresentasikan data yang sebenarnya sesuai dengan kebutuhan perusahaan. Sebelum memasuki tahap selanjutnya, terdapat hubungan antara logical data model dengan data flow diagrams mengikuti ketentuan sebagai berikut: a. Setiap data yang disimpan harus merepresentasikan seluruh jumlah entitas b. Atribut-atribut pada data flows harus mengacu kepada tipe entitas 6. Merge logical data models into global model (optional step) Bertujuan untuk mengabungkan logical data model yang merepresentasikan satu atau lebih tetapi tidak seluruh sudut pandang pengguna ke dalam sebuah global logical data model yang merepresentasikan sebaliknya. Aktivitas yang terdapat di dalam tahap ini adalah:

33 39 a. Menggabungkan local logical data model ke dalam global logical data model b. Melakukan validasi terhadap global logical data model c. Melakukan review global logical data model dengan user 7. Check for future growth Bertujuan untuk menentukan perubahan yang diperlukan pada masa mendatang dan menilai apakah logical data model dapat menyesuaikan terhadap perubahan yang terjadi Physical Database Design Proses menghasilkan sebuah deskripsi mengenai implementasi dari basis data pada secondary storage yang menjelaskan base relations, file organizations, dan indexes yang digunakan untuk memperoleh akses efisien terhadap data dengan integrity constraints terkait serta security measures. Pada tahapan ini, designer diperbolehkan untuk memilih bagaimana basis data akan diimplementasikan sekaligus DBMS spesifik yang akan digunakan. Langkahlangkah yang terdapat dalam physical database design adalah: 1. Translate logical data model for target DBMS

34 40 a. Design base relations Bertujuan untuk menentukan representasi base relations teridentifikasi di dalam logical data model terhadap target DBMS. b. Design representation of derived data Bertujuan untuk menentukan representasi dari derived data yang ditampilkan pada logical data model terhadap target DBMS. c. Design general constraints Bertujuan untuk merancang general constraints terhadap target DBMS. 2. Design file organizations and indexes Bertujuan untuk mengoptimalkan file organizations untuk menyimpan base relations dan indexes yang diperlukan agar memperoleh kinerja maksimal. Terdapat beberapa aktivitas pada tahap ini, sebagai berikut: a. Analyze transactions Bertujuan untuk memahami fungsionalitas dari transaksi yang akan dijalankan pada basis data untuk menganalisis transaksi yang bersifat penting. b. Choose file organizations Bertujuan untuk menentukan efisiensi file organizations terhadap base relations.

35 41 c. Choose indexes Bertujuan untuk menentukan penambahan indexes yang akan meningkatkan kinerja dari sistem. d. Estimate disk space requirements Bertujuan untuk melakukan estimasi kapasitas penyimpanan pada disk yang dibutuhkan oleh basis data. 3. Design user views Bertujuan untuk merancang user view yang diidentifikasikan selama requirements collection dan analysis stage dari Database System Development Lifecycle. 4. Design security mechanisms Bertujuan untuk merancang mekanisme keamanan basis data yang disesuaikan selama tahapan requirements dan collection pada Database System Development Lifecycle. 5. Consider the introduction of controlled redundancy Bertujuan untuk menentukan introduction of controlled redundancy (mengikuti ketentuan normalisasi) yang digunakan agar sistem memberikan performa terbaik. 6. Monitor and tune the operational system

36 42 Bertujuan untuk melakukan monitorisasi pada sistem operasional dan meningkatkan performa sistem guna memperbaiki pengambilan keputusan yang tidak tepat sekaligus refleksi terhadap perubahan persyaratan DBMS Selection Menurut Connolly dan Begg (2010, p ), DBMS Selection adalah seleksi terhadap DBMS yang tepat untuk mendukung sistem basis data. Terdapat beberapa langkah-langkah utama dalam melakukan seleksi DBMS yaitu: 1. Define terms of reference of study Merujuk kepada ketentuan dalam memilih DBMS, menyatakan tujuan dan ruang lingkup dari pembelajaran dan kegiatan yang perlu dilakukan. Dokumen terkait termasuk deskripsi mengenai kriteria yang didasarkan kepada user requirements digunakan sebagai evaluasi terhadap produk DBMS. 2. Shortlist two or three products Pertimbangan dalam pengambilan keputusan terhadap produk DBMS mengacu kepada budget available, level of vendor support, compatibility dengan perangkat lunak lainnya yang menjadi tolak ukur untuk melakukan komparasi antara kinerja dari produk-produk DBMS.

37 43 3. Evaluate products Terdapat beberapa fitur yang digunakan untuk mengevaluasi produk DBMS dan dikategorikan berdasarkan data definition, physical definition, accessibility, transaction handling, utilities, development dan fitur lainnya. 4. Recommend selection and produce report Langkah terakhir dari pemilihan DBMS adalah dokumentasi proses dan menyediakan saran perbaikan untuk produk DBMS Application Design Menurut Connolly dan Begg (2010, p ), Application Design adalah perancangan user interface dan program-program aplikasi yang digunakan serta diproses pada basis data. Terdapat dua aspek dari perancangan aplikasi yaitu: 1. Transaction design Transaction adalah suatu kegiatan maupun sekumpulan kegiatan oleh single user atau program aplikasi yang mengubah dan mengakses isi dari basis data. Tujuan dari transaction design adalah menjelaskan dan mendokumentasikan high-level characteristics yang diperlukan dalam transaksi basis data meliputi: a. Data yang digunakan untuk transaksi b. Karakteristik fungsional dari transaksi

38 44 c. Output dari transaksi d. Pentingnya untuk pengguna e. Tingkat penggunaan Aktivitas ini seharusnya dihadirkan sejak awal pada proses perancangan untuk meyakinkan bahwa implementasi terhadap basis data menunjang seluruh transaksi yang dibutuhkan. Terdapat 3 jenis transaksi utama, yaitu: a. Retrieval transactions Digunakan dalam pengambilan data untuk ditampilkan pada layar atau sebagai laporan. Contoh: retrieval transaction sebagai operasi untuk mencari dan menampilkan rincian data lengkap dari property jika diberikan property number. b. Update transaction Digunakan untuk menambahkan data baru, menghapus data lama, atau memodifikasi data yang telah ada di dalam basis data. Contoh: update transaction sebagai operasi untuk menambahkan property baru ke dalam basis data. c. Mixed transaction Mixed transaction adalah penggabungan yang melibatkan retrieval transaction dan update transaction data. Contoh: mixed transaction sebagai operasi untuk mencari dan menampilkan data lengkap mengenai suatu

39 45 property yang diberikan property number dan kemudian dilakukan modifikasi terhadap nilai sewa bulanan. 2. User interface design Sebelum sebuah form atau report diimplementasikan, merancang tata letak merupakan hal penting dalam permulaan. Menurut (Shneiderman and Plaisant, 2004) pedomanpedoman yang digunakan untuk merancang form atau report adalah sebagai berikut: a. Meaningful title Informasi yang disampaikan oleh judul harus jelas dan tidak ambigu dalam mendefinisikan tujuan dari form atau report. b. Comprehensible instructions Terminologi yang familiar harus digunakan untuk menyampaikan instruksi-instruksi kepada user. Intruksi tersebut harus jelas, menggunakan grammar yang konsisten dengan mengikuti prosedur standar. c. Logical grouping and sequencing of fields Field-field yang berhubungan harus diletakkan bersamaan pada form atau report. Urutan dari field-field tersebut harus konsisten dan bersifat logikal. d. Visually appealing layout of the form or report Form atau report harus menampilkan interface yang menarik kepada user serta seimbang, tepat dan konsisten.

40 46 e. Familiar field labels Nama field harus mudah dikenali. Contoh: jika sex diganti dengan gender tentunya akan membingungkan bagi user tertentu. f. Consistent terminology and abbrevitions Penggunaan istilah-istilah dan singkatan harus konsisten. g. Consistent use of color Warna harus dapat memberikan improvisasi terhadap penampilan dari sebuah form atau report dan menekankan fields atau informasi penting lainnya. Untuk mencapai tujuan tersebut, penggunaan dari warna harus konsisten dan bermakna. Contoh: fields pada sebuah form dengan latar belakang warna putih dapat mengindikasikan data entry fields, sedangkan warna biru mengindikasikan display-only fields. h. Visible space and boundaries for data-entry fields User harus peka terhadap visualisasi kapasitas yang tersedia untuk setiap kapasitas field sekaligus memperbolehkan user untuk mempertimbangkan format yang tepat sebelum memasukkan nilai ke dalam field tersebut. i. Convenient cursor movement

41 47 User harus dengan mudah mengidentifikasi operasi yang dibutuhkan untuk menggerakan kursor pada form atau report dengan mekanisme tab key, arrows, dan mouse pointer. j. Error correction for individual characters and entire fields User harus dengan mudah mengidentifikasi operasi yang dibutuhkan untuk melakukan alterations terhadap nilai field menggunakan mekanisme sederhana backspace key atau overtyping. k. Error messages for unacceptable values Jika user mencoba mencoba memasukkan data yang salah ke sebuah field, maka pesan kesalahan akan ditampilkan. Pesan tersebut menginformasikan kepada pengguna tentang kesalahan dan indikasi nilai akses. Contoh: jika terdapat field username dan password yang dilanjutkan dengan menekan tombol submit sementara field tidak diisi maka akan ditampilkan pesan error username harus diisi. l. Optional fields marked clearly Optional fields harus dapat diidentifikasikan oleh pengguna secara jelas melalui pendekatan field label atau dengan menampilkan field menggunakan warna yang mengindikasikan tipe dari field tersebut.

42 48 m. Explanatory messages for fields Ketika user meletakkan kursor pada field, informasi mengenainya harus muncul pada posisi reguler layar seperti window status bar. n. Completion signal Harus jelas ketika proses pengisian form yang dilakukan user telah selesai. Bagaimanapun, pilihan proses selesai tidak bersifat otomatis sehingga pengguna dapat melakukan review terhadap data yang telah dimasukkan Prototyping Menurut Connolly dan Begg (2010, p333), Prototyping adalah membuat sebuah model kerja dari sistem basis data. Sebuah prototype adalah sebuah model kerja yang biasanya tidak mempunyai keseluruhan fitur atau menyediakan semua fungsionalitas dari sistem akhir. Tujuan utama dari pengembangan prototype basis data adalah untuk memperbolehkan user menggunakan prototype sebagai identifikasi terhadap fitur-fitur yang bekerja dan jika memungkinkan memberikan saran perbaikan bahkan penambahan fitur baru ke dalam sistem basis data. Terdapat 2 jenis prototype yang sering digunakan secara umum yaitu: 1. Requirement prototype

43 49 Prototype ini digunakan untuk menjelaskan kebutuhankebutuhan dari sistem basis data yang diusulkan, ketika kebutuhan tercapai maka prototype akan dibersihkan. 2. Evolutionary prototype Prototype ini digunakan dengan tujuan yang sama, perbedaannya terletak pada proses dimana prototype tidak dibuang, melainkan digunakan untuk pengembangan lebih lanjut menjadi sistem basis data yang bekerja Implementation Menurut Connolly dan Begg (2010, p333), Implementation adalah realisasi fisik dari basis data dan design application. Pada tahap ini, implementasi dari basis data menggunakan DDL yang dipilih dari DBMS maupun GUI dimana tersedia fungsionalitas yang sama dengan statements DDL bersifat low level. Security dan integrity control untuk sistem juga akan diimplementasikan. Beberapa dari kontrol-kontrol tersebut diimplementasikan menggunakan DDL sementara sisanya menggunakan fungsi selain DDL semisal utilities DBMS atau operating system control Data Convertion and Loading Menurut Connolly dan Begg (2010, p334), Data Convertion and Loading adalah memindahkan data-data yang tersedia ke

44 50 dalam basis data baru dan melakukan konversi terhadap aplikasiaplikasi yang ada agar dapat berjalan pada basis data tersebut. Tahap ini diperlukan ketika mengganti sistem yang lama menjadi sistem basis data yang baru. DBMS mempunyai fasilitas untuk memasukkan data yang telah ada ke dalam basis data yang baru. Fasilitas ini membutuhkan spesifikasi sumber file dan target basis data, kemudian konversi data akan dilakukan secara otomatis Testing Menurut Connolly dan Begg (2010, p334), Testing adalah proses dari sistem basis data yang sedang berjalan dengan tujuan untuk menemukan kesalahan yang terdapat pada sistem basis data tersebut. Di dalam perancangan basis data, user daripada sistem yang baru seharusnya dilibatkan dalam proses testing. Testing turut mencakup beberapa usability dari sistem basis data sebagai berikut: 1. Learnability : waktu yang diperlukan agar pengguna menjadi produktif dengan sistem. 2. Performance : kecocokan antara system response terhadap user s work practice. 3. Robustness : tingkat toleransi sistem terhadap kesalahan user.

45 51 4. Recoverability : kemampuan pemulihan sistem dari kesalahankesalahan user. 5. Adaptability : kedekatan antara system tied dengan single model of work Operational Maintenance Menurut Connolly dan Begg (2010, p335), Operational Maintenance adalah proses pengawasan dan pemeliharaan sistem basis data beserta instalasinya. Pada tahap sebelumnya, sistem basis data telah diimplementasikan dengan sukses dan teruji. Kemudian, sistem bergerak maju menuju tahap pemeliharaan yang melibatkan kegiatan-kegiatan sebagai berikut: 1. Melakukan pengawasan atau monitorisasi terhadap performa dari sistem. Jika performa berada dibawah level yang dapat diterima, maka dilakukan perbaikan atau reorganization terhadap basis data sesuai dengan kebutuhan. 2. Melakukan pemeliharaan dan peningkatan sistem basis data ketika diperlukan. Kebutuhan baru akan dimasukkan kedalam sistem basis data melalui tahap-tahap yang telah tersedia sebelumnya berdasarkan lifecycle.

46 Entity Relationship Modeling Menurut Connolly dan Begg (2010, p371), Entity Relationship Modeling adalah pendekatan top-down untuk perancangan basis data yang dimulai dengan mengindentifikasikan data penting yang berupa entities dan relationship antara data yang harus diwakilkan dalam sebuah model. Kemudian dilakukan penambahan beberapa rincian semisal informasi yang lebih lengkap tentang entities dan relationship yang disebut attribute dan constraints dalam entities, relationship, dan attribute Entity Types Menurut Connolly dan Begg (2010, p ), Entity Types adalah sekelompok objek dengan properties sama yang diidentifikasikan oleh perusahaan sebagai keberadaan yang independent. Representasi terhadap entity types digambarkan dalam sebuah persegi yang berisi nama entity dimana nama entity adalah kata benda tunggal. Penulisan nama entity pada UML, diawali dengan huruf kapital pada setiap kata. Contoh entity types adalah Staff, PropertyForRent, dll.

47 53 Gambar 2.3 Contoh ER Diagram (Sumber: Connolly dan Begg, 2010, p373) Entity Types dibagi menjadi 2, yaitu: 1. Strong entity types Tipe entitas yang tidak bergantung pada entitas lain. Karakteristik dari tipe entitas kuat dimana entitas tersebut dapat diidentifikasikan unik dan menggunakan attribute primary key dari tipe entitas. Contoh: kita dapat mengidentifikasikan secara unik dari setiap client yang menggunakan attribute clientno, dimana clientno adalah primary key dari entitas client.

48 54 2. Weak entity types Tipe entitas yang tergantung pada entitas lain. Karakteristik dari tipe entitas lemah dimana entitas tersebut tidak dapat diidentifikasikan unik dan hanya menggunakan attribute dari tipe entitas. Contoh: pada entitas preference yang tidak mempunyai primary key, sehingga tidak dapat diidentifikasikan serta entitas preference itu menggunakan attribute entitas tersebut. Gambar 2.4 Contoh strong entity type dan weak entity (Sumber: Connolly dan Begg, 2010, p384) Relationship Types Menurut Connolly dan Begg (2010, p374), Relationship Types adalah sekumpulan set asosiasi antara beberapa entity types. Setiap relationship type diberikan nama yang menjelaskan fungsinya.

49 55 Representasi relationship type digambarkan dengan sebuah garis yang menghubungkan antar entitas. Contoh relationship type adalah hubungan antara entitas Staff dan entitas Branch. Setiap branch memiliki staff. Sehingga relationship types dari kedua entitas tersebut adalah has. Menurut Connolly dan Begg (2010, p375), Relationship Occurrence adalah sebuah hubungan yang unik termasuk satu kejadian dari setiap entity type yang berpartisipasi di dalamnya. Gambar 2.5 Contoh individual occurences (Sumber: Connolly dan Begg, 2010, p375)

50 56 Gambar 2.6 Contoh representasi diagramatic (Sumber: Connolly dan Begg, 2010, p376) Menurut Connolly dan Begg (2010, p376), Degree of Relationship Type adalah jumlah entitas yang ada dalam relationship. Degree of relationship type dibagi menjadi beberapa jenis yaitu: 1. Binary Relationship Hubungan antara dua entitas. Contoh binary relationship adalah POwns relationship, hubungan antara entitas PrivateOwner dengan PropertyForRent.

51 57 Gambar 2.7 Contoh binary relationship (Sumber: Connolly dan Begg, 2010, p377) 2. Ternary Relationship Hubungan antara tiga entitas. Contoh ternary relationship adalah register relationship, dimana terdapat 3 entitas yang berpartisipasi, yaitu entitas Staff, Branch, dan Client. Hubungan ini menunjukkan registrasi client yang dilakukan oleh staff pada sebuah branch. Gambar 2.8 Contoh ternary relationship (Sumber: Connolly dan Begg, 2010, p377) 3. Quaternary Relationship Hubungan antara empat entitas. Contoh quaternary relationship adalah arranges relationship, dimana terdapat 4 entitas yang berpartisipasi, yaitu entitas Buyer, Bid, Solicitor,

52 58 dan Financial Institution. Hubungan ini menunjukkan seorang buyer yang memperoleh advise dari seorang solicitor dan didukung oleh seorang financial institution, melakukan bid. Gambar 2.9 Contoh quarternary relationship (Sumber: Connolly dan Begg, 2010, p378) 4. Recursive Relationship Menurut Connolly dan Begg (2010, p378), Recursive Relationship adalah sebuah hubungan dimana entitas yang sama ikut serta dalam hubungan tersebut lebih dari satu kali dengan peranan yang berbeda. Contoh recursive relationship adalah supervises relationship, dimana entitas yang terlibat adalah staff. Partisipasi pertama seorang staff sebagai supervisor dan partisipasi kedua sebagai seorang staff yang menjadi supervises.

53 59 Gambar 2.10 Contoh recursive relationship (Sumber: Connolly dan Begg, 2010, p378) Attribute Menurut Connolly dan Begg (2010, p379), Attribute adalah property dari sebuah entity atau relationship type. Setiap attribute terkait dengan sekumpulan nilai yang disebut dengan domain. Domain menjelaskan nilai potensial yang dimiliki atribut terhadap relational model. Attribute domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Pengelompokkan attribute sesuai dengan klasifikasi adalah: 1. Simple and composite attributes Simple attributes adalah sebuah atribut yang tersusun dari single component dengan sebuah independent existence. Simple attributes dikenal dengan sebutan atomic attributes.

54 60 Composite attributes adalah sebuah atribut yang tersusun dari multiple components, dimana setiap komponennya memiliki sebuah independent existence. 2. Single-valued and multi-valued attributes Single-valued attributes adalah sebuah atribut yang memiliki single value untuk setiap occurrence dari sebuah entity type. Multi-valued attributes adalah sebuah atribut yang memiliki multiple value untuk setiap occurence pada sebuah entity type. 3. Derived attributes Sebuah atribut yang merepresentasikan sebuah nilai yang diturunkan dari nilai atribut terkait atau sekumpulan atribut, yang tidak seharusnya berada pada entity type yang sama Keys Menurut Connolly dan Begg (2010, p ), terdapat beberapa jenis keys yang meliputi: 1. Candidate key Set minimal dari atribut yang mengidentifikasikan setiap occurence dari sebuah entity type secara unik. Candidate key merupakan kumpulan dari atribut minimal yang dapat menjadi primary key.

55 61 2. Primary key Candidate key terpilih yang mengidentifikasikan sebuah entity type secara unik. Setiap entity type dapat memiliki lebih dari satu candidate key. Pertimbangan dalam memilih primary key adalah berdasarkan attribute length, minimal number of attributes required, dan future certainty of uniqueness. 3. Composite key Candidate key yang memiliki dua atau lebih atribut. Pada kasus tertentu, key pada entity type tersusun atas beberapa atributte yang memiliki nilai unik untuk setiap occurrence entity type namun tidak terpisah Structural Constraint Menurut Connolly dan Begg (2010, p ), Structural Constraint adalah batasan-batasan di dalam relationships yang merepresentasikan dunia nyata. Tipe utama yang terdapat pada constraint relationship disebut multiplicity. Multiplicity adalah sekumpulan nilai dengan possible occurrence dari entity type yang memiliki hubungan dengan single occurrence dari entity lainnya melalui particular relationship. Pada complex relationship multiplicity secara umum tersusun atas n-ary relationships yang merepresentasikan jumlah entity occurrences pada sebuah relationship ketika nilai lainnya

56 62 (n-1) ditetapkan. Multiplicity terdiri atas dua constraints terpisah yang dikenal sebagai cardinality dan participation. Cardinality adalah batasan yang menjelaskan maximum number dari possible relationship occurrences untuk sebuah entity yang berpartisipasi di dalam sebuah relationship type. Participation adalah batasan yang menentukan keseluruhan atau hanya beberapa entity occurrences yang berpartisipasi di dalam sebuah relationship. Gambar 2.11 Contoh multiplicity sebagai constraint (Sumber: Connolly dan Begg, 2010, p391)

57 Normalization Menurut Connolly dan Begg (2010, p416), Normalization adalah teknik untuk menghasilkan sekumpulan relasi terhadap properties sesuai dengan data requirements dari perusahaan. Normalisasi bertujuan untuk mengidentifikasi sekumpulan relasi yang mendukung kebutuhan dari suatu perusahaan. Menurut Peter dan Coronel (2005, p176), Normalization adalah proses menetapkan atribut suatu entitas. Tujuan dari normalisasi untuk mengurangi redundansi data dan membantu menghilangkan anomali data yang berasal dari redundansi tersebut. Berdasarkan sumber pada definisi di atas, Normalization adalah teknik untuk menghasilkan atribut, relasi dari suatu entitas yang bertujuan untuk mengurangi redundasi data dan menghilangkan anomali data yang disebabkan update anomalies yang terdiri atas insertion anomalies, deletion anomalies dan modification anomalies. Karakteristik dari normalisasi adalah: a. Jumlah minimal atribut yang diperlukan untuk mendukung persayaratan data dalam sebuah perusahaan. b. Atribut dengan hubungan logical yang dekat (digambarkan dengan functional dependency), ditemukan dalam hubungan yang sama. c. Meminimalkan redundansi dengan masing-masing atribut hanya mewakili sekali dengan pengecualian dari atribut yang membentuk seluruh atau sebagian dari foreign keys sebagai bagian terpenting untuk penggabungan dalam relasi yang terkait.

58 64 Gambar 2.12 Hubungan antar normal form (Sumber: Connolly dan Begg, 2010, p429) Proses yang terdapat pada normalisasi adalah: 1. Unnormalized Form (UNF) Menurut Connolly dan Begg (2010, p430), Unnormalized Form (UNF) adalah sebuah tabel yang berisi satu atau lebih repeating groups. Proses normalisasi yang pertama dilakukan dengan memindahkan data dari sumber kedalam tabel sesuai dengan baris dan kolom. Dalam format tersebut, tabel ini disebut UNF yang merepresentasikan tabel unnormalized. Contoh repeating groups:

59 65 Tabel 2.3 Tabel ClientRental Unnormalized (Sumber: Connolly dan Begg, 2010, p432) clie ntn o cna me prope rtyn o paddress rentsta rt rentfin ish rent own ern o ona me CR7 6 John Kay PG4 6Lawrence St, Glasgrow 1-Jul Aug CO 40 Tina Murp hy PG16 5Novar Dr.Glasgrow 1-Sep Sep CO 93 Tony Shaw CR5 6 Aline Stew art PG4 6Lawrence St, Glasgrow 1-Sep Jun CO 40 Tina Murp hy PG36 2Manor Rd. Glasgrow 10- Oct-07 1-Dec CO 93 Tony Shaw PG16 5Novar Dr.Glasgrow 1-Nov Aug CO 93 Tony Shaw Repeating Group = (propertyno, paddress, rentstart, rentfinish, rent, ownerno, oname) 2. First Normal Form (1NF) Menurut Connolly dan Begg (2010, p430), First Normal Form (1NF) adalah sebuah relasi dimana pertemuan antara baris dan kolom yang terdiri dari satu dan hanya bernilai satu. Proses untuk mengubah UNF menjadi 1NF adalah dengan mengindentifikasikan dan menghilangkan repeating groups dalam tabel. Repeating groups adalah sebuah atribut atau kumpulan-

60 66 kumpulannya yang ada di dalam tabel yang memiliki beberapa nilai untuk sebuah atribut pada tabel tersebut. Terdapat dua pendekatan yang digunakan untuk menghilangkan repeating group dari tabel unnormalized: a. Pendekatan pertama, menghilangkan repeating group dengan memasukkan data yang tepat ke dalam kolom yang kosong pada baris dengan isi data berulang. b. Pendekatan kedua, menghilangkan repeating group dengan menempatkan data berulang, melalui copy terhadap atribut dari original key ke dalam relasi yang terpisah. Tabel 2.4 1NF Relasi ClientRental (Sumber: Connolly dan Begg, 2010, p432) clie nt No prop erty No cname paddress rentsta rt rentfin ish rent owne r No ona me CR 76 PG4 John Kay 6Lawrence St, Glasgrow 1-Jul Aug CO4 0 Tina Murp hy CR 76 PG1 6 John Kay 5Novar Dr.Glasgrow 1-Sep Sep CO9 3 Tony Shaw CR 56 PG4 Aline Stewart 6Lawrence St, Glasgrow 1-Sep Jun CO4 0 Tina Murp hy CR 56 PG3 6 Aline Stewart 2Manor Rd. Glasgrow 10- Oct-07 1-Dec CO9 3 Tony Shaw CR 56 PG1 6 Aline Stewart 5Novar Dr.Glasgrow 1-Nov Aug CO9 3 Tony Shaw

61 67 Tabel 2.5 Alternatif 1NF Client dan Relasi PropertyRental-Owner (Sumber: Connolly dan Begg, 2010, p433) clientno CR76 CR56 cname John Kay Aline Stewart client No Prop ertyn o paddress rentstart rentfinish rent own ern o ona me CR76 PG4 6Lawrence St, Glasgrow 1-Jul Aug CO 40 Tina Murp hy CR76 PG16 5Novar Dr.Glasgrow 1-Sep-08 1-Sep CO 93 Tony Shaw CR56 PG4 6Lawrence St, Glasgrow 1-Sep Jun CO 40 Tina Murp hy CR56 PG36 2Manor Rd. Glasgrow 10-Oct Dec CO 93 Tony Shaw CR56 PG16 5Novar Dr.Glasgrow 1-Nov Aug CO 93 Tony Shaw 3. Second Normal Form (2NF) Menurut Connolly dan Begg (2010, p434), Second Normal Form (2NF) adalah sebuah relasi yang terdapat pada 1NF dimana setiap atribut yang bukan primary key bergantung penuh terhadap primary key. Proses untuk mengubah 1NF menjadi 2NF adalah menghilangkan ketergantungan partial dengan menghapus atribut yang memiliki

62 68 ketergantungan tersebut dari relasi dan menempatkan atribut tersebut kedalam sebuah relasi yang baru dengan melakukan copy dari determinannya. Fully functional dependency adalah suatu kondisi dimana A dan B adalah atribut di dalam suatu relasi, B memiliki ketergantungan fungsional penuh pada A, jika B memiliki ketergantungan fungsional pada A tetapi bukan subset dari A. A B adalah fully functional dependency dimana jika atribut dari A dihapus, maka ketergantungan tidak terjadi lagi. Sedangkan A B adalah ketergantungan partial dimana jika beberapa atribut dari A dihapus, maka atribut lainnya masih memiliki ketergantungan. Ketergantungan partial dari relasi ClientRental adalah clientno cname dan propertyno paddress, rent, ownerno, oname. Tabel 2.6 2NF Relasi ClientRental (Sumber: Connolly dan Begg, 2010, p435) clientno propertyno rentstart rentfinish CR76 PG4 1-Jul Aug-08 CR76 PG16 1-Sep-08 1-Sep-07 CR56 PG4 1-Sep Jun-07 CR56 PG36 10-Oct-07 1-Dec-08 clientno cname CR76 John Kay CR56 Aline Stewart

63 69 propertyno paddress rent ownerno oname PG4 6 Lawrence St, Tina 350 CO40 Glasgrow Murphy PG16 5 Novar Dr. Glasgow 450 CO93 Tony Shaw PG36 2 Manor Rd, Glasgow 375 CO93 Tony Shaw 4. Third Normal Form (3NF) Menurut Connolly dan Begg (2010, p435), Third Normal Form (3NF) adalah sebuah relasi yang terdapat pada 1NF dan 2NF, dimana atribut yang bukan primary key memiliki ketergantungan transitive terhadap primary key. Proses untuk mengubah 2NF menjadi 3NF adalah dengan menghapus ketergantungan transitive pada atribut dari relasi dan menempatkannya kedalam sebuah relasi baru dengan melakukan copy dari determinannya. Transitive dependency adalah suatu kondisi dimana A, B, dan C adalah atribut dari relasi yang merupakan A B dan B C, maka C adalah transitive dependency terhadap A melalui B. Contoh atribute yang memiliki ketergantungan transitive adalah relasi antara Staff dan Branch. staffno branchno branchno baddress Ketergantungan transitive staffno baddress melalui atribut branchno. Kondisi ini menyebabkan staffno tidak memiliki ketergantungan fungsional pada branchno atau baddress.

64 70 Ketergantungan transitive dari relasi Client, Rental, dan PropertyOwner adalah ownerno oname. Tabel 2.7 3NF Relasi PropertyOwner (Sumber: Connolly dan Begg, 2010, p436) propertyno paddress rent ownerno PG4 6 Lawrence St, Glasgrow 350 CO40 PG16 5 Novar Dr. Glasgow 450 CO93 PG36 2 Manor Rd, Glasgow 375 CO93 ownerno CO40 CO93 oname Tina Murphy Tony Shaw Tabel 2.8 Summary 3NF Relasi PropertyOwner (Sumber: Connolly dan Begg, 2010, p438) clientno propertyno rentstart rentfinish CR76 PG4 1-Jul Aug-08 CR76 PG16 1-Sep-08 1-Sep-07 CR56 PG4 1-Sep Jun-07 CR56 PG36 10-Oct-07 1-Dec-08 CR56 PG16 1-Nov Aug-10 clientno CR76 CR56 cname John Kay Aline Stewart

65 71 propertyno paddress rent ownerno PG4 6 Lawrence St, Glasgrow 350 CO40 PG16 5 Novar Dr. Glasgow 450 CO93 PG36 2 Manor Rd, Glasgow 375 CO93 ownerno CO40 CO93 oname Tina Murphy Tony Shaw Dekomposisi yang terjadi pada relasi ClientRental 1NF menjadi relasi 3NF dapat dilihat pada gambar berikut ini, yaitu: Gambar 2.13 Contoh dekomposisi 1NF ke 3NF (Sumber: Connolly dan Begg, 2010, p437) Software Development Lifecycle (SDLC) Menurut Pressman (2005, p79), salah satu model pengembangan sistem yang digunakan adalah model waterfall. Waterfall model (classic

66 72 life cycle) menggunakan pendekatan klasik di dalam daur hidup sistem. Beberapa tahapan yang terdapat di dalamnya yaitu: 1. Communication Kerangka aktivitas yang melibatkan komunikasi dan kolaborasi dengan customer dan (stakeholders) meliputi project initiation, requirements gathering, dan aktivitas terkait lainnya. 2. Planning Kegiatan ini melibatkan sebuah perencanaan terhadap software engineering yang menjelaskan teknis yang akan dikerjakan, resiko, sumber-sumber yang dibutuhkan dan penjadwalan. 3. Modeling Aktivitas ini melibatkan penciptaan model yang memungkinkan pengembang maupun konsumen untuk saling memahami analisis terhadap software requirements dan design yang ingin dicapai. 4. Construction Kegiatan ini menggabungkan code generation baik secara manual maupun otomatis dan testing yang dibutuhkan untuk menemukan kesalahan-kesalahan di dalam code. 5. Deployment Perangkat lunak yang dihadirkan (secara keseluruhan maupun partial) menempatkan konsumen untuk melakukan evaluasi terhadap produk dan menyediakan feedback berdasarkan evaluasi tersebut.

67 73 Gambar 2.14 The waterfall model (Sumber: Pressman, 2005, p79) Data Flow Diagram (DFD) Menurut Whitten (2004, p344), Data Flow Diagram (DFD) adalah alat yang digunakan untuk menggambar aliran data dalam sistem dan proses yang bekerja dalam sebuah sistem. Data Flow Diagram menggambarkan sistem informasi pada suatu perusahaan. Terdapat empat komponen utama dalam DFD yang berupa simbol berikut: 1. Aliran Data (Data Flow) Merepresentasikan aliran data yang terjadi pada suatu sistem, bergerak dari satu posisi ke posisi lainnya dan dapat terdiri atas banyak data yang bergerak ke suatu tujuan secara bersamaan. Simbol: 2. External Agent Merepresentasikan sumber yang merupakan tempat dan tujuan data sebagai external entities yang menyediakan informasi untuk sistem. Simbol:

68 74 3. Proses (Process) Merepresentasikan proses yang terjadi di dalam suatu sistem. Proses merupakan suatu aktivitas atau aksi yang ditransformasikan, disimpan dan didistribusikan sesuai dengan kebutuhan. Simbol: 4. Penyimpanan Data (Data Store) Merepresentasikan penyimpanan data saat tidak digunakan yang dapat terdiri dari banyak lokasi penyimpanan fisikal. Simbol:

69 75 Gambar 2.15 A Simple Data Flow Diagram (Sumber: Whitten, 2004, p346) Context Diagram Menurut Whitten (2004, p372), Context Diagram adalah proses model yang digunakan untuk mendokumentasikan batasan dari sebuah sistem. Context Diagram memiliki hanya satu proses yang menggambarkan sistem secara keseluruhan. Proses tersebut diberikan penamaan label 0 (nol). Sumber menggambarkan

70 76 cakupan dan batasan di dalam suatu sistem karena penyimpanan data pada sistem terdapat pada satu proses, sehingga tidak ada penyimpanan dalam diagram konteks. Gambar 2.16 The Context Data Flow Diagram (Sumber: Whitten, 2004, p373) Data Flow Diagram Level 0 Data flow diagram level 0 adalah diagram aliran data yang menggambarkan konteks dalam sebuah event. Data flow diagram level 0 menunjukkan interaksi antara input, output, dan data store pada setiap proses.

71 77 Gambar 2.17 The Event Diagrams (Sumber: Whitten, 2004, p379) Data Flow Diagram Level 1 Data Flow Diagram Level 1 adalah diagram yang menggambarkan dekomposisi dari Diagram Level State Transition Diagram (STD) Menurut Whitten (2004, p673), State Transition Diagram adalah sebuah tool yang digunakan untuk menggambarkan urutan dan variasi dari layar yang mungkin terjadi selama user session. Diagram ini memberikan gambaran berdasarkan ketergantungan waktu dari sistem (time-dependent). Adapun notasi yang terdapat pada State Transition Diagram adalah: 1. State sebagai representasi dari keadaan suatu objek. State disimbolkan dengan kotak. Simbol :

72 78 2. Arrow sebagai representasi dari kejadian yang diakibatkan perubahan keadaan pada sistem. Arrow disimbolkan dengan tanda panah. Simbol : Gambar 2.18 STD (Sumber: Whitten, 2004, p674)