BAB 2 LANDASAN TEORI
2.1
Teori Umum 2.1.1
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
8
dan basis data itu sendiri yang bertujuan untuk menyimpan dan memungkinkan pengguna untuk melakukan manipulasi terhadap informasi sesuai dengan kebutuhan secara keseluruhan.
2.1.2
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.
2.1.2.1
Komponen lingkungan DBMS Menurut Connolly dan Begg (2010, p68-71), terdapat 5 komponen utama dalam DBMS Environment, yaitu hardware, software, data, procedures, dan people.
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.
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.
2.1.2.2
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
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.
12
5. Improved data integrity Integritas konsistensi
basis
data
data
yang
menunjukkan
disimpan.
validitas
Integritas
dan
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
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
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.
2.1.2.3
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.
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.
2.1.2.4
Fungsi DBMS Menurut Connolly dan Begg (2010, p100-104), fungsifungsi yang terdapat pada Database Management System (DBMS) meliputi: 1. Data storage, retrieval, dan update
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
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.
18
2.1.2.5
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
berbagi akses basis data.
konkurensi
yang
mengijinkan
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.
2.1.3
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)
20
2.1.3.1
Database Planning Menurut Connolly dan Begg (2010, p313-315), 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.
21
2.1.3.2
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
22
sudut pandang yang ada maupun yang tumpang tindih terhadap satu sama lainnya.
2.1.3.3
Requirement Collection and Analysis Menurut Connolly dan Begg (2010, p316-319), 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
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.
2.1.3.4
Database Design Menurut Connolly dan Begg (2010, p320-322), Database Design adalah proses perancangan yang mendukung sasaran dan tujuan dari perusahaan terhadap sistem basis data yang
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
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.
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, p466-468), Design Methodology adalah pendekatan terstruktur yang menggunakan
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
Identify entity types
Step 1.2
Identify relationship types
Step 1.3
Identify and associate attributes with entity or relationship types
Step 1.4
Determine attribute domains
Step 1.5
Determine candidate, primary, and alternate key attributes
Step 1.6
Consider use of enhanced modeling concepts (optional step)
Step 1.7
Check model for redundancy
Step 1.8
Validate conceptual data model againts user transactions
Step 1.9
Review conceptual data model with user
28
2. Logical database design Step 2: Build and validate logical data model Step 2.1
Derive relations for logical data model
Step 2.2
Validate relations using normalization
Step 2.3
Validate relations against user transactions
Step 2.4
Check integrity constraints
Step 2.5
Review logical data model with user
Step 2.6
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
Design base relations
Step 3.2
Design representation of derived data
Step 3.3
Design general constraints
Step 4: Design file organizations and indexes Step 4.1
Analyze transactions
Step 4.2
Choose file organizations
Step 4.3
Choose indexes
Step 4.4
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
29
2.1.3.4.1 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.
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
atribut-
atribut 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.
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 penggunaan
dari
untuk modeling
mempertimbangkan 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
relationships b. Menghilangkan redundansi relationships c. Mempertimbangkan dimensi waktu
(1:1)
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.
2.1.3.4.2 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
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
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
dilakukan primary
identifikasi key
setelah
harus terhadap 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
Menggabungkan entitas-entitas ke
(a) Mandatory participation on dalam satu relasi. both sides
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
side
further information.
Superclass/subclass relationship
Lihat pada table 2.2
beraturan
dengan
tanpa
*:* binary relationship, Complex Membuat representasi relasi yang relationship
menghubungkan dan termasuk di
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
Nondisjoint {And}
Relasi tunggal (dimana
Constraint Mandatory
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
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
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
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
merepresentasikan
logical
data
sebaliknya.
terdapat di dalam tahap ini adalah:
model
yang
Aktivitas
yang
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.
2.1.3.4.3 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
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.
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
42
Bertujuan untuk melakukan monitorisasi pada sistem operasional dan meningkatkan performa sistem guna memperbaiki pengambilan keputusan yang tidak tepat
sekaligus
refleksi
terhadap
perubahan
persyaratan.
2.1.3.5
DBMS Selection Menurut Connolly dan Begg (2010, p325-329), 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.
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.
2.1.3.6
Application Design Menurut Connolly dan Begg (2010, p329-333), 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
mendokumentasikan
adalah high-level
menjelaskan
dan
characteristics
yang
diperlukan dalam transaksi basis data meliputi: a. Data yang digunakan untuk transaksi b. Karakteristik fungsional dari transaksi
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
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.
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
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.
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.
2.1.3.7
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
fungsionalitas
dari
pengembangan memperbolehkan identifikasi
sistem
prototype user
terhadap
fitur
atau akhir. basis
menggunakan fitur-fitur
yang
menyediakan Tujuan data
semua
utama adalah
prototype bekerja
dari untuk
sebagai 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
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.
2.1.3.8
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.
2.1.3.9
Data Convertion and Loading Menurut Connolly dan Begg (2010, p334), Data Convertion and Loading adalah memindahkan data-data yang tersedia ke
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.
2.1.3.10 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.
51
4. Recoverability : kemampuan pemulihan sistem dari kesalahankesalahan user. 5. Adaptability : kedekatan antara system tied dengan single model of work.
2.1.3.11 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.
52
2.1.4
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.
2.1.4.1
Entity Types Menurut Connolly dan Begg (2010, p372-374), 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.
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.
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)
2.1.4.2
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.
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)
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
PrivateOwner dengan PropertyForRent.
antara
entitas
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,
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.
59
Gambar 2.10 Contoh recursive relationship (Sumber: Connolly dan Begg, 2010, p378)
2.1.4.3
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.
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.
2.1.4.4
Keys Menurut Connolly dan Begg (2010, p381-383), 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.
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.
2.1.4.5
Structural Constraint Menurut Connolly dan Begg (2010, p385-395), 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
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)
63
2.1.5
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.
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:
65
Tabel 2.3 Tabel ClientRental Unnormalized (Sumber: Connolly dan Begg, 2010, p432) clie ntN o
cNa me
CR7
John
6
Kay
prope rtyN
6
PG4
Aline Stew
rentFin
rt
ish
o
PG16
CR5
pAddress
rentSta
PG4
art PG36
PG16
6Lawrence
1-Jul-
31-
St, Glasgrow
07
Aug-08
5Novar
1-Sep-
1-Sep-
Dr.Glasgrow
08
09
6Lawrence
1-Sep-
10-Jun-
St, Glasgrow
06
07
2Manor Rd.
10-
1-Dec-
Glasgrow
Oct-07
08
5Novar
1-Nov-
10-
Dr.Glasgrow
09
Aug-10
own rent
erN o
350
450
350
375
450
CO 40
oNa me Tina Murp hy
CO
Tony
93
Shaw
CO 40
Tina Murp hy
CO
Tony
93
Shaw
CO
Tony
93
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-
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
prop
nt
erty
No
No
CR 76
PG4
rentSta
rentFin
rt
ish
6Lawrence
1-Jul-
31-
Kay
St, Glasgrow
07
Aug-08
cName
pAddress
John
CR
PG1
John
5Novar
1-Sep-
1-Sep-
76
6
Kay
Dr.Glasgrow
08
09
Aline
6Lawrence
1-Sep-
10-Jun-
Stewart
St, Glasgrow
06
07
CR 56
PG4
CR
PG3
Aline
2Manor Rd.
10-
1-Dec-
56
6
Stewart
Glasgrow
Oct-07
08
CR
PG1
Aline
5Novar
1-Nov-
10-
56
6
Stewart
Dr.Glasgrow
01
Aug-03
rent
350
450
350
375
450
owne
oNa
r No
me
CO4 0
Tina Murp hy
CO9
Tony
3
Shaw
CO4 0
Tina Murp hy
CO9
Tony
3
Shaw
CO9
Tony
3
Shaw
67
Tabel 2.5 Alternatif 1NF Client dan Relasi PropertyRental-Owner (Sumber: Connolly dan Begg, 2010, p433) clientNo
cName
CR76
John Kay
CR56
Aline Stewart
client No
CR76
CR76
CR56
Prop
own
ertyN pAddress
rentStart
rentFinish
rent
o
PG4
PG16
PG4
CR56
PG36
CR56
PG16
erN o
6Lawrence St, Glasgrow 5Novar Dr.Glasgrow 6Lawrence St, Glasgrow
1-Jul-07
1-Sep-08
1-Sep-06
2Manor Rd.
10-Oct-
Glasgrow
07
5Novar Dr.Glasgrow
1-Nov-09
31-Aug-08
1-Sep-09
10-Jun-07
350
450
350
1-Dec-08
375
10-Aug-10
450
CO 40
oNa me Tina Murp hy
CO
Tony
93
Shaw
CO 40
Tina Murp hy
CO
Tony
93
Shaw
CO
Tony
93
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
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 AB adalah ketergantungan partial dimana jika beberapa atribut dari A dihapus, maka atribut lainnya masih memiliki ketergantungan. Ketergantungan
partial
dari
relasi
ClientRental
adalah
clientNocName dan propertyNopAddress, rent, ownerNo, oName.
Tabel 2.6 2NF Relasi ClientRental (Sumber: Connolly dan Begg, 2010, p435) clientNo
propertyNo
rentStart
rentFinish
CR76
PG4
1-Jul-07
31-Aug-08
CR76
PG16
1-Sep-08
1-Sep-07
CR56
PG4
1-Sep-06
10-Jun-07
CR56
PG36
10-Oct-07
1-Dec-08
clientNo cName CR76
John Kay
CR56
Aline Stewart
69 propertyNo
pAddress 6 Lawrence St,
PG4
Glasgrow
rent
ownerNo
350
CO40
oName Tina 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 BC, maka C adalah transitive dependency terhadap A melalui B. Contoh atribute yang memiliki ketergantungan transitive adalah relasi antara Staff dan Branch. staffNo branchNo branchNobAddress Ketergantungan transitive staffNobAddress melalui atribut branchNo.
Kondisi
ini
menyebabkan
staffNo
tidak
ketergantungan fungsional pada branchNo atau bAddress.
memiliki
70
Ketergantungan transitive dari relasi Client, Rental, dan PropertyOwner adalah ownerNooName. 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
oName
CO40
Tina Murphy
CO93
Tony Shaw
Tabel 2.8 Summary 3NF Relasi PropertyOwner (Sumber: Connolly dan Begg, 2010, p438) clientNo
propertyNo
rentStart
rentFinish
CR76
PG4
1-Jul-07
31-Aug-08
CR76
PG16
1-Sep-08
1-Sep-07
CR56
PG4
1-Sep-06
10-Jun-07
CR56
PG36
10-Oct-07
1-Dec-08
CR56
PG16
1-Nov-09
10-Aug-10
clientNo
cName
CR76
John Kay
CR56
Aline Stewart
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
oName
CO40
Tina Murphy
CO93
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)
2.1.6
Software Development Lifecycle (SDLC) Menurut Pressman (2005, p79), salah satu model pengembangan sistem yang digunakan adalah model waterfall. Waterfall model (classic
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.
73
Gambar 2.14 The waterfall model (Sumber: Pressman, 2005, p79)
2.1.7
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:
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:
75
Gambar 2.15 A Simple Data Flow Diagram (Sumber: Whitten, 2004, p346)
2.1.7.1
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
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)
2.1.7.2
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.
77
Gambar 2.17 The Event Diagrams (Sumber: Whitten, 2004, p379)
2.1.7.3
Data Flow Diagram Level 1 Data Flow Diagram Level 1 adalah diagram yang menggambarkan dekomposisi dari Diagram Level 0.
2.1.8
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 :
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)
79
2.2
Teori Khusus 2.2.1
Teori Pembelian Menurut Himayati (2009, p79), pembelian adalah suatu transaksi dimanna perusahaan membutuhkan barang atau jasa, baik untuk dipakai maupun untuk persediaan yang akan dijual.
2.2.2
Teori Penjualan Dalam jurnal “Strategi Pemasaran Produk Wisata” oleh Wayan Suardana menyatakan penjualan adalah ilmu dan seni mempengaruhi pribadi yang dilakukan oleh penjual untuk mengajak orang lain agar bersedia membeli barang atau jasa yang ditawarkannya, mengembangkan keunggulan bersaing yang berkesinabungan melalui pasar yang dimasuki dengan program pemasaran yang digunakan untuk melayani pasar sasaran tersebut.
2.2.3
Teori Persediaan Dalam
jurnal
“Analisis
Dan
Perancangan
Sistem
Informasi
Persediaan, Pembelian, Dan Penjualan Pada Toko Sinar Jaya” oleh Wawan Saputra menyatakan persediaan merupakan aset pengadaan barang di dalam sebuah bisnis, atau yang sedang dalam proses produksi untuk penjualan tertentu, atau dalam wujud material atau pendukung untuk digunakan dalam proses produksi atau penyumbangan jasa. Dalam jurnal “Just in Time” oleh Ign. Sarto Kothson Budiman menyatakan bahwa persediaan adalah salah satu pengeluaran terbesar yang
80
dilakukan oleh perusahaan, yaitu meliputi kurang lebih 40% dari modal yang diinvestasikan. Persediaan merupakan stok yang digunakan untuk memudahkan produksi atau memuaskan permintaan pelanggan. Menurut Vivi Triyanti dan M.T. Gadis (2008) pada Jurnal “Pemilihan Supplier Untuk Industri Makanan Menggunakan Metode Promethee” menyatakan bahwa untuk sebuah perusahaan manufaktur, ketersediaan bahan baku tergantung pada performa dari supplier. Terdapat dua metode penilaian supplier yang dapat digunakan yaitu metode Entropy untuk menghitung bobot kriteria dan menghasilkan reject rate sebagai kriteria utama. Sedangkan metode Promethee (Preference Rangking Organization Method for Enrichment Evaluation) untuk menentukan peringkat dari supplier.
