BAB 2 LANDASAN TEORI
2.1
Teori Umum
2.1.1
Pengertian Data Menurut Laudon (2000, p8), data merupakan aliran fakta yang mewakili kejadian yang terjadi dalam organisasi atau dalam lingkungan fisik sebelum mereka diatur menjadi sebuah bentuk yang dapat dimengerti dan digunakan oleh pengguna. Menurut O’Brien (2003, p13), data adalah fakta-fakta atau observasi yang mentah, biasanya mengenai kejadian atau transaksi bisnis. Dari definisi-definisi di atas, dapat disimpulkan bahwa data adalah fakta yang telah diketahui dan dapat disimpan di dalam media komputer yang nantinya perlu diolah lebih lanjut sehingga dapat menghasilkan informasi yang berguna dan berarti bagi pemakai.
2.1.2 Pengertian Database Menurut Date (1994, p9), database terdiri dari sekumpulan data yang digunakan oleh aplikasi sistem dari sebuah perusahaan. Menurut Connolly (2002, p14), database adalah sekumpulan data yang mempunyai keterkaitan secara logika serta deskripsi dari data tersebut, yang dirancang untuk memenuhi kebutuhan-kebutuhan informasi dari sebuah organisasi.
7
8
Dari definisi-definisi di atas, dapat disimpulkan bahwa database adalah sebuah tempat penyimpanan data tunggal yang memiliki kapasitas besar yang dapat digunakan oleh banyak departemen dan pengguna.
2.1.3
Database Management System (DBMS) Menurut Connolly (2002, p16), Database Management System (DBMS) adalah sebuah sistem perangkat lunak yang memungkinkan users untuk mendefinisikan (define), menciptakan (create), memelihara (maintain), dan mengatur (control) akses ke database.
2.1.3.1
Fasilitas DBMS Menurut Connolly (2002, p16), Fasilitas-fasilitas yang disediakan oleh Database Management System (DBMS) antara lain : a. Data Definition Language (DDL) : Memungkinkan user untuk menspesifikasikan tipe-tipe data, struktur-struktur serta batasan-batasan data untuk disimpan dalam database. b. Data Manipulation Language (DML) : Memungkinkan user untuk melakukan operasi insert, update, delete dan retrieve data dari database. c. Pengontrolan akses terhadap database yang meliputi : Sistem keamanan (security system) untuk mencegah user yang tidak memiliki hak akses melakukan akses ke database. Sistem yang terintegritas (integrity system) untuk memelihara konsistensi dari data-data yang tersimpan.
9
Kontrol konkurensi (concurrency control system) yang memungkinkan pengaksesan menyebar dari database.
2.1.3.2
Komponen DBMS
Gambar 2.1 Komponen DBMS (Connolly, 2002, p53)
10
Menurut Connolly (2002, p18), Komponen-komponen DBMS adalah : a. Hardware DBMS dan aplikasi membutuhkan perangkat keras (hardware) untuk dapat beroperasi. Perangkat keras tersebut dapat berupa personal computer, mainframe sampai dengan jaringan komputer. Perangkat keras tergantung pada kebutuhan organisasi dan DBMS yang digunakan. b. Software Software merupakan perangkat lunak DBMS itu sendiri dan program aplikasi, sistem operasi, termasuk perangkat lunak jaringan apabila DBMS digunakan dalam jaringan. c. Data Data berperan penting sebagai jembatan antara komponen mesin (machine components) dan komponen manusia (human components). d. Procedures Procedures mengacu pada instruksi dan aturan tentang desain dan penggunaan dari database. Pengguna sistem dan staff membutuhkan prosedur-prosedur dalam menggunakan atau menjalankan sistem. Prosedurprosedur tersebut berisi instuksi-instuksi tentang bagaimana cara :
Log on ke DBMS
Menggunakan fasilitas DBMS dan program aplikasi yang khusus
Memulai dan menghentikan DBMS
Membuat salinan cadangan (backup) database
Menangani kegagalan-kegagalan hardware atau software
11
Mengganti struktur dari sebuah tabel, mengorganisasikan kembali database, meningkatkan tampilan (performance), atau menyimpan data ke dalam penyimpanan kedua (secondary storage).
e. People People merupakan orang yang terlibat dengan sistem tersebut. Komponen ini memiliki lima peran yaitu : Data Administrator (DA) berperan dalam mengatur sumber data meliputi perencanaan database (database planning), pengembangan (development) dan pemeliharaan (maintenance) standar pengaturan, kebijakan dan prosedur, serta konseptual atau logikal perancangan database (database design). Database Administrator (DBA) adalah berperan dalam realisasi fisik (physical realization) dari database, termasuk di dalamnya perancangan dan implementasi fisik database, kontrol keamanan dan integritas, pemeliharaan operasional sistem, dan jaminan kepuasan kinerja aplikasi users. Database Designer terdiri dari logical dan physical designers. Logical database designers yang berperan dalam pengindentifikasian, hubungan (relationship), dan batasan-batasan dari data untuk disimpan di dalam database. Physical database designers berperan dalam mementukan bagaimana rancangan logical database dapat direalisasikan. Application Developers berperan dalam implementasi aplikasi database yang menyediakan fungsi-fungsi yang dibutuhkan pengguna akhir.
12
End Users merupakan clients untuk database yang sudah dirancang dan diimplementasikan untuk melayani kebutuhan informasi mereka.
2.1.3.3
Kelebihan DBMS Menurut Connolly (2002, p26), beberapa keuntungan DBMS antara lain : a. Penggunaan data secara bersama-sama (The Data can be Shared) b. Mengurangi kerangkapan data (Redudancy can be Reduced) c. Menghindari ketidakkonsistenan data (Inconsistency can be Avoided) d. Integritas data terpelihara (Integrity can be Maintained) e. Keamanan terjamin (Security can be Enforced) f. Kebutuhan user yang kompleks dapat teratasi (Balanced conflicting requirements) g. Pelaksanaan standarisasi (Standars can be Enforced) h. Meningkatkan produktivitas (Increased productivity) i. Layanan backup dan recovery yang baik (Improved backup and recovery services)
2.1.3.4
Kekurangan DBMS Menurut Connolly (2002, p29), beberapa kekurangan DBMS antara lain : a. Rumit (Complexity) b. Ukuran (Size)
13
c. Biaya DBMS yang cukup besar (Cost of DBMS) d. Memerlukan tambahan biaya hardware (Additional Hardware Costs) e. Memerlukan biaya konversi (Cost of Conversion)
2.1.4
Database Application Life Cycle (DBLC) Menurut Connolly (2002, p271), Database Application Life Cycle (DBLC) merupakan komponen mendasar suatu sistem informasi dimana pengembangan atau pemakaiannya harus dilihat dari perspektif yang lebih luas berdasarkan kebutuhan organisasi. Menurut Connolly (2002, p273), Tahapan dari Database Application Life Cycle (DBLC) terdiri dari :
14
Gambar2.2 Database Application Life Cycle (Connolly, 2002, p272)
Gambar 2.2 Tahapan dari Database Application Life Cycle (DBLC)( Connolly (2002, p273)
2.1.4.1
Perencanaan Database (Database Planning) Menurut Connolly (2002, p273), Perencanaan database merupakan aktivitas manajemen
yang memungkinkan
tahapan dari database
application lifecylle direalisasikan se-efektif dan se-efisien mungkin.
15
2.1.4.2
Definisi Sistem (System Definition) Menurut Connolly (2002, p274), Definisi Sistem Menjelaskan batasan-batasan dan cakupan dari aplikasi database dari sudut pandang pemakai database (user view) yang utama.
2.1.4.3
Analisis dan Pengumpulan Kebutuhan (Requirements Collection and Analysis) Menurut Connolly (2002, p276), Analisa dan Pengumpulan Kebutuhan merupakan suatu proses pengumpulan dan penganalisaan informasi mengenai bagian dari organisasi yang didukung oleh sistem database, dan penggunaan informasi tersebut untuk mengidentifikasi kebutuhan user akan sistem yang baru. Beberapa teknik yang digunakan dalam proses pencarian data yang mendukung kebutuhan informasi (Connolly, 2002, p305), yaitu : a. Mempelajari dokumen b. Wawancara c. Mengobservasi kegiatan kerja perusahaan d. Penelitian e. Kuisioner
2.1.4.4
Perancangan Database (Database Design) Menurut Connolly (2002, p279), Perancangan Database merupakan suatu proses pembuatan sebuah desain database yang akan mendukung
16
tujuan dan operasi pada perusahaaan. Ada dua Pendekatan utama dalam perancangan database (database design) yaitu: a. Top-Down Pendekatan top-down diawali dengan pengembangan (development) model data (data models) yang mengandung beberapa entitas dan hubungan tingkat tinggi (high-level entityes and relationships) dan kemudian menggunakan pendekatan top-down secara berturut-turut untuk mengidentifikasi entitas, hubungan, dan atribut-atribut yang terkait di dalamnya dengan tingkatan yang lebih rendah (lower-level). b. Bottom-Up Pendekatan bottom-up dimulai dari atribut dasar (yaitu properties dari entitas dan relationship), yang melalui analisa dari penggabungan antar atribut dikelompokkan ke dalam suatu relasi yang merepresentasikan tipe dari entitas dan hubungan (relationship) antar entitas. Pendekatan ini digunakan untuk merancang database yang sederhana dengan jumlah atribut yang relatif sedikit.
Menurut Connolly (2002, p281), Desain Database memiliki tiga fase utama, yaitu : a. Conceptual database design Conceptual Database design merupakan suatu proses pembentukan model dari informasi yang digunakan dalam enterprise, independen dari
keseluruhan
aspek
fisik.
Model
data
dibangun
dengan
17
menggunakan informasi dalam spesifikasi kebutuhan user. Model data konseptual merupakan sumber infromasi untuk fase desain logikal. b. Logical database design Merupakan suatu proses pembentukan model dari informasi yang digunakan dalam enterprise berdasarkan model data tertentu (misal : relasional), tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal. c. Physical database design Merupakan suatu proses yang menghasilkan deskripsi implementasi database pada penyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu.
2.1.4.5
Pemilihan DBMS (DBMS Selection) Pemilihan DBMS merupakan proses pemilihan DBMS yang sesuai untuk mendukung sistem database. (Connolly, 2002, p284)
2.1.4.6
Perancangan Aplikasi (Application Design) Menurut Connolly (2002, p287), Perancangan Aplikasi merupakan perancangan antar muka pemakai (user interface) dan program-program aplikasi yang menggunakan dan memproses database.
18
Desain database dan aplikasi merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu : a. Transaction Design Transaksi adalah suatu atau serangkaian aksi yang dilakukan oleh user tunggal atau program aplikasi tunggal, yang mengakses atau mengubah isi dari database. Kegunaan dari transaction design adalah untuk mendefinisikan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi-transaksi yang dibutuhkan pada database, meliputi: Data yang akan digunakan oleh transaksi Karakteristik fungsional dari suatu transaksi Output transaksi Kepentingan users Tingkat kegunaan yang diharapkan b. User Interface Design Guidelines Beberapa aturan pokok dalam pembuatan user interface : Meaningful title : informasi yang disampaikan melalui judul haruslah jelas dan mengidentifikasi tujuan dari form atau report tanpa mengandung makna yang ambigu. Comprehensible instructions : terminologi yang familiar harus digunakan dalam menyampaikan instruksi-instruksi. Instruksi tersebut harus bersifat singkat atau ringkas, dan ketika dibutuhkan informasi tambahan, maka harus disediakan help screen. Instruksi harus ditulis
19
dengan gaya tata bahasa yang konsisten dengan menggunakan pola (format) yang standar. Logical grouping and sequencing of fields : field yang saling berhubungan ditempatkan pada form atau report yang sama. Urutan field harus logis dan konsisten. Visually appealing layout of the form atau report : form atau report harus menampilkan interface yang menarik kepada user. Familiar field labels : label field yang digunakan, haruslah familiar. Consistent terminology and abbreviations : terminologi dan singkatan-singkatan yang digunakan, haruslah bersifat konsisten. Consistent use of colors : Warna harus digunakan secara konsisten. Visible space and boundaries for data-entry fields : seorang user haruslah mengetahui jumlah dari tempat yang tersedia untuk setiap field
yang
ada.
Hal
ini
nantinya
akan
membantu
user
mempertimbangkan format untuk data, sebelum memasukkan nilai (values) ke dalam sebuah field. Convenient cursor movement : seorang user harus dapat dengan mudah
mengidentifikasi
operasi
yang
dibutuhkan
dengan
menggerakkan sebuah kursor di sepanjang form atau report. Mekanisme-mekanisme yang sederhana seperti penggunaan tab key, arrows, atau mouse pointer haruslah digunakan. Error correction for individual characters and entire fields : seorang user harus dapat dengan mudah mengidentifikasi operasi yang
20
dibutuhkan untuk membuat perubahan pada bahagian (fields) nilai (values). Mekanisme-mekanisme yang sederhana seperti penggunaan Backspace key atau overtyping haruslah tersedia. Error messages for unacceptable values : jika seorang user mencoba memasukkan data yang tidak benar ke dalam sebuah field, sebuah pesan kesalahan (error message) haruslah ditampilkan. Optional
fields
marked
clearly :
Optional
fields
haruslah
diidentifikasikan dengan jelas kepada user dengan menggunakan sebuah label field yang sesuai, atau menampilkan field dengan menggunakan sebuah warna yang mengindikasikan tipe dari field tersebut. Optional fields harus ditempatkan setelah required fields. Explanatory messages for fields : Ketika user meletakkan kursor pada suatu field, maka keterangan mengenai field tersebut haruslah muncul di layar, seperti sebuah window status bar. Completion signal : merupakan indikator yang menjelaskan bahwa proses pengisian fields pada suatu form telah selesai dilaksanakan.
2.1.4.7
Prototyping (Optional) Menurut Connolly (2002, p291), Prototyping merupakan proses pembuatan sebuah model kerja dari suatu sistem database. Tujuan utama dari pembuatan prototyping adalah untuk mengidentifikasi fitur dari sistem yang berjalan dengan baik atau tidak, memberikan perbaikan-perbaikan
21
atau penambahan fitur baru, klarifikasi kebutuhan user serta evaluasi feasibilitas (kemungkinan yang akan terjadi) dari desain sistem khusus.
2.1.4.8
Implementation Menurut Connolly (2002, p292), Implementasi merupakan realisasi fisik dari database dan desain aplikasi.
2.1.4.9
Data Conversion and Loading Menurut Connolly (2002, p292), Data Conversion and Loading Merupakan pemindahan data yang ada kedalam database baru dan mengkonversikan aplikasi yang ada agar dapat digunakan pada database yang baru. Tahapan ini dibutuhkan ketika sistem database baru menggantikan sistem yang lama. DBMS biasanya memiliki utilitas yang memanggil ulang file yang sudah ada kedalam database baru.
2.1.4.10 Testing Menurut Connolly (2002, p293), Merupakan proses menjalankan sistem database yang bertujuan untuk menemukan kesalahan-kesalahan (errors) yang ada. Proses ini menggunakan strategi perencanaan tes dengan teliti dan data yang realistis.
22
2.1.4.11 Operational Maintenance Menurut Connolly (2002, p287), Merupakan suatu proses pengawasan dan pemeliharaan sistem setelah dilakukan instalasi. Pada tahap-tahap sebelumnya, sistem database sudah diimplementasi dan diuji secara penuh. Pada saat ini sistem bergerak ke suatu proses pengawasan dan pemeliharaan, yang melibatkan aktivitas-aktivitas berikut : a. Pengawasan performa sistem. Jika performa turun melampaui batas yang dapat diterima, maka perlu dilakukan perubahan atau pengaturan ulang database. b. Pemeliharaan dan pembaharuan sistem database (jika dibutuhkan). c. Penggabungan kebutuhan baru kedalam aplikasi database.
2.1.5
Tahapan Perancangan Database
2.1.5.1
Perancangan Konseptual (Conceptual database design) Tahapan ini merupakan proses pembuatan model informasi yang digunakan dalam sebuah perusahaan yang tidak tergantung pada semua masalah fisik. Awal tahap ini dimulai dengan pembuatan conceptual data model perusahaan yang secara keseluruhan bebas dari detail implementasi seperti DBMS yang digunakan, program aplikasi, bahasa pemrograman, platform untuk hardware, tingkat kinerja, maupun bentuk masalah fisik lainnya. Menurut Connolly (2002, p422), Conceptual database design terdiri dari beberapa langkah, yaitu :
23
Langkah 1 : Membangun model konseptual data lokal untuk setiap user view. 1.1 Mengidentifikasi tipe-tipe entity Mengidentifikasi tipe entity yang dibutuhkan oleh view.
Tabel 2.1 Contoh Kamus Data Entity Yang Mendeskripsikan Entity untuk View DreamHome (Connolly, 2002, p424)
1.2 Mengidentifikasi tipe-tipe relationship Mengidentifikasi hubungan penting yang terjadi antara entity yang telah diidentifikasi.
Tabel 2.2 Contoh Kamus Data Relationship yang Mendeskripsikan Relatioship untuk View DreamHome (Connolly, 2002, p426)
24
1.3 Mengidentifikasi dan menghubungkan atribut-atribut dengan tipe entity atau relationship Mengidentifikasi dan menggabungkan atribut yang dibutuhkan entity atau relasi, dan mendokumenkan setiap atribut secara detail.
Tabel 2.3 Contoh Kamus Data Atribut yang Mendeskripsikan Atribut untuk View DreamHome (Connolly, 2002, p430)
1.4 Menentukan domain atribut Menentukan domain atribut dalam model konseptual lokal dan mendokumentasikan secara detail setiap domain. 1.5 Menentukan atribut kandidat dan primary key Mengidentifikasikan candidate key(s) untuk setiap entity dan jika terdapat lebih dari satu candidate key pilih satu menjadi primary key. 1.6 Mempertimbangkan penggunaan konsep pemodelan yang tinggi / enhanced modelling (step optional). Mempertimbangkan penggunaan konsep enhanced modeling, seperti specialization / generalization, aggregation, dan composition. 1.7 Memeriksa redundansi pada model
25
Mengidentifikasikan
apakah
ada
redundansi
dalam
data
dan
memindahkan data yang telah ada. Aktifitas dalam langkah ini adalah : a. Memeriksa ulang relationship 1-1 (one to one) : kemungkinan ada dua entitas yang menggambarkan obyek yang sama dalam organisasi. Oleh karena itu, kedua entitas tersebut harus digabungkan. b. Menghilangkan relationship yang terduplikasi (redundant). Suatu relationship menjadi redundant jika informasi yang dihasilkan melalui relationship yang lainnya. Untuk meminimalkan data model maka relationship yang redundant harus dihilangkan. 1.8 Memvalidasi model konseptual lokal terhadap transaksi user Menjamin model konseptual dapat mendukung kebutuhan transactions yang dibutuhkan oleh view. 1.9 Memeriksa model konseptual data lokal dengan user Melakukan review terhadap model konseptual data lokal dengan user untuk menjamin model telah merepresentasikan user view berdasarkan kebutuhan perusahaan.
2.1.5.2
Perancangan Logikal (Logical Database Design) Tahapan ini merupakan proses pembuatan model informasi yang digunakan perusahaan berdasarkan pada model data khusus tetapi bebas dari DBMS tertentu dan masalah fisik lainnya. Logikal data model perlu
26
juga diuji untuk memastikan bahwa logikal data model mendukung transaksi yang ditetapkan oleh user. Menurut Connolly (2002, p442), Logical database design terdiri dari beberapa langkah, yaitu : Langkah 2 : Membangun dan memvalidasi model logikal data lokal untuk setiap view. 2.1 Menghilangkan fitur-fitur yang tidak kompatibel dengan model relational (step optional) Aktivitas dalam langkah ini adalah : a. Menghilangkan relasi binary many to many (*:*)
Gambar 2.3 menghilangkan relasi binary many to many (Connolly, 2002, p444)
b. Menghilangkan relasi rekursif many to many (*:*)
27
c. Menghilangkan tipe relasi yang kompleks
Gambar 2.4 Menghilangkan relasi binary many to many (Connolly, 2002, p444)
d. Menghilangkan atribut multi valued Branch BranchNo{ PK } telNo [ 1..3 ]
Gambar 2.5 (a) Branch Memiliki Multivalued pada Atribut TelNo
Gambar 2.5 (b) Mendekomposisi telNo menjadi Entitas baru dengan nama Telephone (Connolly, 2002, p446)
28
2.2 Mendapatkan relasi untuk model logikal data lokal Membangun
relasi
untuk
model
logikal
data
lokal
yang
mempresentasikan entitas, relasi antar entitas dan artibut yang telah diidentifikasi. Aktivitas pada langkah ini adalah menentukan : a. Strong entity type. b. Weak entity type. c. One-to-many binary relationship types. d. One-to-one binary relationship types. e. Recursive One to One relationship type. f. Superclass / Subclass relationship types (Model Enhanced). g. Many-to-many binary relationship types. h. Complex relationship types. i. Multivalued attributes. 2.3 Memvalidasi hubungan menggunakan normalisasi Normalisasi digunakan untuk meningkatkan model yang telah terbentuk agar duplikasi data yang tidak diperlukan dapat dihindari. 2.4 Memvalidasi hubungan terhadap transaksi user Memastikan relasi yang telah ada pada model data logikal dapat mendukung transaksi yang diperlukan oleh view. 2.5 Mendefinisikan integrity constraint Integrity constraint adalah batasan yang digunakan untuk menjaga agar basis data tidak menjadi inkonsiten. Ada 5 tipe integrity constraints, yaitu :
29
a. Required data (data / nilai yang valid) b. Batasan domain atribut. c. Entity integrity (primary key tidak boleh null). d. Referential integrity (foreign key pada suatu entity harus sesuai dengan candidate key pada entity lain). e. Enterprise constraint (batasan pada organisasi). 2.6 Meninjau kembali model logikal data lokal dengan user Memastikan model data logikal lokal yang terbentuk merupakan representasi dari user view. Untuk memvalidasi model data logikal ini digunakan Data Flow Diagram (DFD). DFD dapat menunjukkan aliran data dari suatu organisasi.
Langkah 3 : Membangun dan memvalidasi model data logikal global 3.1 Menggabungkan model logikal data lokal menjadi model logikal data global Menggabungkan model logikal data individual ke dalam model data logikal global organisasi. 3.2 Memvalidasi model logikal data global Memvalidasi relasi yang telah dibuat oleh model data global menggunakan teknik normalisasi dan memastikan relasi ini mendukung transaksi yang diperlukan. 3.3 Memeriksa perkembangan yang akan datang
30
Memastikan apakah ada perubahan
yang berarti
yang dapat
diperkirakan dan memastikan apakah model logikal data global ini dapat mendukung perubahan-perubahan ini. 3.4 Memeriksa kembali model logikal data dengan user Memastikan bahwa model logikal data global merupakan representasi nyata dari organisasi.
2.1.5.3
Perancangan Fisikal (Physical Database Design) Tahapan
ini
merupakan
proses
pembuatan
deskripsi
dari
implementasi database pada secondary storage yang menjelaskan basis relasi, organisasi file, dan indeksnya yang digunakan untuk memperoleh akses pada data yang efisien, dan masalah integritas lainnya yang berkaitan, dan menentukan mekanisme security. Menurut Connolly (2002, p480), Physical database design terdiri dari beberapa langkah, yaitu : Langkah 4 : Menerjemahkan model logikal data global untuk DBMS yang akan digunakan. 4.1 Mendesain relasi dasar (base relations) Memutuskan bagaimana mempresentasikan relasi-relasi yang telah diidentifiksikan pada model logikal data global pada DBMS yang akan dipakai. 4.2 Mendesain representasi derived data
31
Memutuskan bagaimana mempresentasikan derived atribut dalam model data logikal global pada DBMS yang akan dipakai. 4.3 Mendesain enterprise constraints Menentukan batasan-batasan untuk target DBMS.
Langkah 5 : Mendesain representasi fisikal 5.1 Menganalisa transaksi-transaksi Memahami fungsi-fungsi dari transaksi yang akan dijalankan pada database dan menganalisa transaksi yang penting. 5.2 Memilih organisasi file yang akan digunakan Menentukan organisasi file yang efisien dan terdapat lima tipe organisasi file, yaitu : Heap, Hash, Indexed Sequential Access Method (ISAM) , B-tree, Clusters. 5.3 Memilih indeks yang digunakan Memutuskan apakah dengan menggunakan indeks akan meningkatkan performance dari sistem. 5.4 Memperkirakan disk space yang diperlukan Memperkirakan disk storage (secondary storage) yang diperlukan untuk menggunakan sistem database. Langkah 6 : Mendesain user view Pada langkah ini, kita mendesain user view yang telah diidentifikasi.
32
Langkah 7 : Mendesain mekanisme keamanan (security) Pada langkah ini, kita membatasi pengaksesan database oleh user-user yang tidak berhak dan menspesifikasi user terhadap database yang dapat diakses.
Langkah 8 : Menentukan apakah redudansi data telah dapat dikontrol Pada langkah ini dilakukan normalisasi agar dapat meningkatkan performance dari sistem dan menghilangkan redudansi.
Langkah 9 : Mengawasi dan mengatur sistem operasional Pada langkah ini, kita memonitor dan meningkatkan performance dari sistem dengan memperbaiki desain yang tidak sesuai atau perubahan kebutuhan.
2.1.6
Relational Model
2.1.6.1
Relational Data Structure Menurut Connolly (2002, p72), Relasi direpresentasikan sebagai tabel yang terdiri dari baris dan kolom yang diaplikasikan hanya pada struktur logikal bukan fisikal. Di dalam relational model terdapat beberapa konsep, yaitu : a. Atribut adalah nama kolom pada tabel. b. Tuple adalah baris pada tabel. c. Domain adalah himpunan nilai dari satu atau lebih atribut.
33
d. Degree adalah banyaknya atribut atau kolom pada tabel. e. Cardinality adalah banyaknya tuple atau baris pada tabel.
Gambar 2.6 Contoh atribut, tuple, degree, cardinality (Connolly, 2002, p73)
Relational database adalah kumpulan relasi ternormalisasi dengan nama relasi yang jelas dan dapat dibedakan. Sifat-sifat Relational Model antara lain : a. Nama relasi berbeda satu sama lain dalam skema relasional . b. Setiap sel (baris, kolom) dari relasi berisi satu nilai atomik. c. Setiap atribut memiliki nama yang berbeda. d. Nilai suatu atribut berasal dari domain yang sama. e. Setiap tuple berbeda, dan tidak ada duplikasi tuple.
34
2.1.6.2
Relational Keys Menurut Connolly (2002, p78), Kunci-kunci yang ada pada relasional (relational keys) adalah : a. Candidate Key : merupakan sebuah atribut atau himpunan atribut yang mengidentifikasi secara unik tuples yang ada dalam relasi. b. Composite Key : merupakan Candidate key yang terdiri atas dua atau lebih artribut. c. Primary Key : merupakan candidate key yang dipilih untuk identifikasi tuple secara unik dalam suatu relasi. d. Alternate Keys : merupakan candidate key yang tidak terpilih sebagai primary key. e. Foreign Keys : merupakan atribut atau himpunan atribut dalam relasi yang disesuaikan dengan candidate key pada beberapa relasi.
2.1.6.3
Relational Integrity Menurut Connolly (2002, p81), Relational integrity terdiri dari : a. Null Merepresentasikan nilai untuk atribut yang tidak diketahui / tidak digunakan / tidak tersedia untuk suatu tuple. Null berkaitan dengan ketidaklengkapan atau pengecualian data. Representasi tidak adanya suatu nilai tidak sama nilainya dengan Nol atau Spasi. b. Entity Integrity
35
Merupakan relsai dasar yang tidak ada atribut ataupun primary key yang bernilai NULL. c. Referential Integrity Jika terdapat foreign key dalam suatu relasi, maka nilai foreign key tersebut harus sesuai dengan nilai candidate key dari beberapa tuple pada database atau nilai foreign key harus NULL seluruhnya. d. Enterprise Constraints Merupakan aturan tambahan yang dispesifikasikan oleh user atau database administrator (DBA).
2.1.7
Document Flowchart (Bagan Aliran Dokumen) Menurut Mulyadi (2001, p66), Bagan Aliran Data (Document Flow) adalah bagan yang menggambarkan aliran dokumen dalam suatu sistem informasi. Simbol
Keterangan Dokumen, Simbol ini digunakan untuk menggambarkan semua jenis dokumen, yang merupakan formulir yang digunakan untuk merekam terjadinya suatu transaksi.
Penghubung halaman yang berbeda (off-page connector), simbol ini digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan
36
lainnya. Terminal, simbol ini untuk menggambarkan awal dan akhir suatu sistem.
Penghubung pada halaman yang sama (on-page connectior), simbol ini digunakan untuk memungkinkan aliran dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama. Berbagai dokumen, simbol ini digumakan untuk menggambarkan berbagai jenis dokumen yang digabungkan bersama di dalam satu paket.
Garis alir (flowline), simbol ini menggambarkan arah proses pengolahan data.
Kegiatan manual, simbol ini digunakan untuk menggambarkan kegiatan manual seperti : menerima order dari pembeli, mengisi formulir, membandingkan, memeriksa jenis kegiatan yang lain.
37
Arsip permanen, simbol ini digunakan untuk menggambarkan arsip permanent yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem. Keputusan, simbol ini menggambarkan keputusan yang
ya
harus dibuat dalam proses pengolahan data.
tidak
Tabel 2.4 Tabel Simbol-Simbol Flow Document Diagram (Mulyadi, 2001, 60)
2.1.8
Data Flow Diagram (DFD) Menurut Whitten (2004, p326), Data flow Diagram atau diagram aliran data adalah model proses yang digunakan untuk menggambarkan aliran data melalui sebuah sistem dan tugas atau pengolahan yang dilakukan oleh sistem tersebut. DFD terdiri dari beberapa simbol yaitu : proses, aliran data (data flow), penyimpanan data (data store), dan Agen Eksternal (Eksternal agent).
38
2.1.8.1
Proses Proses adalah kerja yang dilakukan oleh sistem sebagai respons terhadap aliran data masuk atau kondisi.
Gambar 2.7 Simbol-simbol dari Proses (Whitten, 2004, p329)
2.1.8.2
Aliran Data Aliran data menunjukkan input data ke proses atau output data (informasi) dari proses. Aliran data juga digunakan untuk menunjukkan pembuatan, pembacaan, penghapusan, atau pembaharuan data dalam file atau database.
Nama Aliran data Gambar 2.8 Simbol aliran data (Whitten, 2004, p338)
2.1.8.3
Penyimpanan Data Data Store adalah “inventori” data atau penyimpanan data yang ditujukan untuk penggunaan selanjutnya.
Gambar 2.9 Simbol Data Store (Whitten, 2004, p346)
39
2.1.8.4
Agen Eksternal Agen Eksternal mendefinisikan orang, unit organisasi, system, atau organisasi luar yang berinteraksi dengan sistem. Disebut juga entitas eksternal.
Gambar 2.10 Simbol External Agent (Whitten, 2004, p345)
2.1.8.5
Diagram Aliran Data Konteks Context data flow diagram / diagram aliran data konteks merupakan model proses untuk mendokumentasikan lingkup sistem. Disebut juga model lingkungan.
40
Gambar 2.11 Contoh Diagram Aliran Data Konteks (Whitten, 2004, p352)
2.1.8.6
Diagram Kejadian Event Diagram / diagram kejadian merupakan diagram aliran data yang menggambarkan konteks kejadian untuk kejadian tunggal. Dengan menggambarkan diagram kejadian untuk tiap proses, pengguna tidak akan kewalahan dengan ukuran keseluruhan sistem.
Gambar 2.12 Contoh Diagram Kejadian (Whitten, 2004, p357)
41
2.1.9
Entity Relationship Modelling (ER Modelling) Menurut Connolly (2002, p330), Entity Relationship Modelling (ER Modelling) adalah pendekatan top-down untuk desain database yang dimulai dengan mengidentifikasi data-data penting yang disebut entity-entity dan hubungan antar data yang harus digambarkan dalam model.
2.1.9.1
Tipe Entity Menurut Connolly (2002, p331), Entity tipe merupakan kumpulan dari obyek-obyek dengan sifat (property) yang sama, yang diidentifikasi oleh
enterprise
dimana
mempunyai
eksistensi
yang
independen.
Keberadaannya dapat berupa fisik maupun abstrak. Entity occurence adalah pengidentifikasian obyek yang unik dari sebuah tipe entity. Setiap entitas diidentifiksikan dan disertakan propertinya. (Connolly, 2002, p333).
2.1.9.2
Tipe relasi Menurut Connolly (2002, p334), tipe relationship merupakan kumpulan keterhubungan yang mempunyai arti (meaningful associations) antara tipe entity yang ada.
42
Gambar 2.13 Contoh Relationship(Connolly, 2002, p335)
a. Derajat relationship Derajat relationship menyatakan jumlah tipe entity yang berpatisipasi dalam sebuah relasi. Participants adalah entity-entity yang dilibatkan dalam sebuah tipe relasi partikular. Jumlah participants dalam sebuah tipe relasi disebut degree. Derajat relationship terdiri dari :
Binary relationship : merupakan keterhubunan antar dua tipe entity.
Gambar 2.14 Binary relationship (Connolly, 2002, p336)
Ternary relationship : merupakan keterhubungan antar tiga tipe entity.
43
Gambar 2.15 Ternary relationship (Connolly, 2002, p336)
Quaternary relationship : merupakan keterhubungan antar empat tipe entity.
Gambar 2.16 Quaternary relationship (Connolly, 2002, p337)
b. Recursif relationship Recursif relationship merupakan keterhubungan antar satu tipe entity dimana tipe entity tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. Relationship dapat diberikan role names untuk mengidentifikasikan keterkaitan tipe entity dalam relationship.
44
Gambar 2.17 Recursif Relationship (Connolly, 2002, p337)
2.1.9.3
Atribut Menurut Connolly (2002, p338), Artribut merupakan sifat-sifat (property) dari sebuah entity atau tipe relationship. Contoh sebuah entity staff digambarkan oleh atribut staffNo, name, position dan salary. Tipe-tipe atribut terdiri dari : a. Domain Attribute : merupakan himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. b. Simple Attribute : merupakan atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama atomic attribute. c. Composite attribute : merupakan atribut yang terdiri dari beberapa komponen, dimana masing-masing komponen memiliki keberadaan yang independen. Misalkan atribut address dapat terdiri dari street, city, postcode.
45
d. Single Valued Attribute : nerupakan atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entity branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian. e. Multi valued attribute : merupakan atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalnya entity branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian. f. Derived attribute : merupakan atribut yang mempresentasikan sebuah nilai yang berasal dari nilai sebuah atribut yang berhubungan atau set atribut, dan tidak harus berada dalam tipe entity yang sama.
Gambar 2.18 Contoh Tipe-Tipe Atribut (Connolly, 2002, p342)
2.1.9.4
Strong and Weak Entity Types Menurut Connolly (2002, p342), Strong entity adalah entity yang keberadaannya tidak bergantung dengan entity lain. Karakteristik dari
46
strong entity adalah setiap entity dapat diidentifikasikan dengan primary key dari tipe entity itu. Weak entity adalah entity yang keberadaannya tergantung dari entity lain. Karakteristik dari weak entity adalah tidak dapat mengidentifikasi primary key dari tipe entitynya karena bergantung pada strong entity.
Gambar 2.19 Contoh Strong and Weak Entity (Connolly, 2002, p343)
2.1.9.5
Structural Constraints Menurut Connolly (2002, p344), Batasan utama pada relationship disebut multiplicity, yaitu jumlah atau range dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relationship. Relationship yang paling umum adalah binary relationship. Macam-macam binary relationship, yaitu : a. One to One (1 : 1) Merupakan relasi dimana setiap entity yang ada hanya dapat mempunyai maksimal satu relasi dengan entity yang lain.
47
Gambar 2.20 Contoh Relasi 1 : 1 (Connolly, 2002, p346)
b. One to Many (1 : *) Merupakan relasi dimana setiap entity yang ada dapat mempunyai satu atau lebih dari satu relasi dengan entity yang lain.
Gambar 2.21 Contoh relasi 1 : * (Connolly, 2002, p347)
c. Many to Many (* : *) Merupakan relasi dimana setiap entity dapat mempunyai lebih dari satu relasi dengan entity lainnya.
Gambar 2.22 Contoh relasi * : * (Connolly, 2002, p348)
48
2.1.9.6
Cardinality and Participation Constraints Menurut Connolly (2002, p351), Cardinality menjelaskan jumlah maksimun dari kejadian relationship yang mungkin untuk entity yang berpartisipasi didalam relationship tersebut. Participation menetapkan apakah seluruh atau sebagian entity yang berpartisipasi dalam suatu relationship.
Gambar 2.23 Contoh Cardinality dan Participation (Connolly, 2002, p351)
2.1.10 Normalisasi Menurut Connoly dan Begg (2002, p376), normalisasi merupakan suatu teknik untuk menghasilkan sekumpulan relasi dengan properti-properti yang berdasar pada kebutuhan-kebutuhan data dari sebuah perusahaan. Tujuan normalisasi adalah untuk mengidentifikasi sekumpulan relasi yang mendukung kebutuhan-kebutuhan data sebuah perusahaan.
49
2.1.10.1 First Normal Form (1NF) Menurut Connoly dan Begg (2002, p388), Suatu kondisi sebelum masuk ke proses normalisasi adalah Unnormalized form (UNF), yaitu dimana sebuah tabel mengandung satu atau lebih repeating group. Sedangkan 1NF adalah sebuah relasi dimana gabungan dari tiap kolom dan baris terdiri atas satu dan hanya satu nilai. Langkah dari UNF ke 1NF antara lain : a. Tunjuk satu atau sekumpulan atribut sebagai kunci untuk table unnormalized. b. Identifikasikan groups yang berulang dalam table unnormalized yang berulang untuk kunci atribut. c. Hapus group yang berulang dengan cara : Masukkan data yang semestinya ke dalam kolom yang kosong pada baris yang berisikan data yang berulang. Menggantikan data yang ada dengan copy dari kunci atribut yang sesungguhnya ke dalam relasi terpisah.
50
2.1.10.2 Second Normal Form (2NF) Menurut Connoly dan Begg (2002, p391), 2NF merupakan sebuah relasi dalam 1NF dan setiap atribut non primary key bersifat fully functionally dependent pada primary key. Langkah dari 1NF ke 2NF : a. Identifikasikan primary key untuk relasi 1NF b. Identifikasikan functional dependencies dalam relasi c. Jika terdapat partial dependencies terhadap primary key, maka hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinannya.
2.1.10.3 Third Normal Form (3NF) Menurut Connoly dan Begg (2002, p394), Merupakan relasi yang terdapat dalam 1NF dan 2N, dimana tidak terdapat atribut non primary key yang bergantung transitif terhadap primary key. Langkah dari 2NF ke 3NF : a. Identifikasikan primary key dalam relasi 2NF b. Identifikasikan functional dependencies dalam relasi c. Jika terdapat transitive dependencies terhadap primary key, hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinannya. Menurut Connoly dan Begg (2002, p398), Boyce Codd Normal Form
(BCNF),
berdasarkan
pada
functional
dependencies
yang
51
dimasukkan ke dalam hitungan seluruh candidate key dalam suatu relasi, bagaimanapun BCNF juga memiliki batasan-batasan tambahan yang disamakan dengan definisi umum dari 3NF. Suatu relasi dikatakan BCNF, jika dan hanya jika setiap determinan merupakan candidate key. Perbedaan antara 3NF dan BCNF adalah untuk functional dependency A -> B, 3NF memungkinkan dependency ini dalam suatu relasi jika B adalah atribut primary key dan A bukan merupakan candidate key. Sedangkan BCNF menetapkan dengan jelas bahwa untuk dependency ini agar ditetapkan dalam relasi maka A harus merupakan candidate key. Setiap relasi dalam BCNF juga merupakan 3NF tetapi relasi dalam 3NF belum tentu termasuk kedalam BCNF.
2.2
Teori Khusus
2.2.1
Web Menurut Bodnar (2006, 87), Web adalah sekumpulan dokumen, file, dan program yang saling terkait. Web dijalankan dengan program pada server dan menerima respon dari klien. Dari hubungan tersebut maka beberapa komputer menjadi Web Server, yaitu server yang memungkinkan pengguna (klien) mengakses dokumen dan menjalankan program komputer yang secara fisik berada di komputer lain.
52
2.2.2
PHP (Hypertext Preprocessor) PHP merupakan bahasa scripting yang menyatu dengan HTML dan dijalani pada server side. Sintaks PHP akan dijalankan pada sisi server yang hasilnya ditampilkan pada sisi client dalam format HTML. Kelebihan PHP dari bahasa pemrograman lain diantaranya : a. Bahasa pemrograman PHP adalah sebuah bahasa script yang tidak melakukan sebuah kompilasi dalam penggunaanya. b. Web Server yang mendukung PHP dapat ditemukan dimana-mana dari mulai IIS sampai dengan apache, dengan konfigurasi yang relatif mudah. c. Dalam sisi pengembangan lebih mudah, karena banyaknya milis-milis dan developer yang siap membantu dalam pengembangan. d. Dalam sisi pemahamanan, PHP adalah bahasa scripting yang paling mudah karena referensi yang banyak. e. PHP dapat digunakan di berbagai mesin (linux, unix, windows) dan dapat dijalankan secara runtime melalui console serta juga dapat menjalankan perintah-perintah sistem. (sumber : www.id.wikipedia.com).
2.2.3
MySQL MySQL adalah Relational Database Management System (RDBMS) yang didistribusikan secara gratis dibawah lisensi GPL (General Public License). MySQL memiliki beberapa keistimewaan, antara lain :
53
a. Portabilitas : MySQL dapat berjalan stabil pada berbagai sistem operasi seperti Windows, Linux, FreeBSD, Mac Os X Server, Solaris, Amiga, dan masih banyak lagi. b. Open Source : MySQL didistribusikan secara open source, dibawah lisensi GPL sehingga dapat digunakan secara cuma-cuma. c. Multiuser : MySQL dapat digunakan oleh beberapa user dalam waktu yang bersamaan tanpa mengalami masalah atau konflik. d. Performance tuning : MySQL memiliki kecepatan yang menakjubkan dalam menangani query sederhana, dengan kata lain dapat memproses lebih banyak SQL per satuan waktu. e. Jenis Kolom : MySQL memiliki tipe kolom yang sangat kompleks, seperti signed / unsigned integer, float, double, char, text, date, timestamp, dan lain-lain. f. Perintah dan Fungsi : MySQL memiliki operator dan fungsi secara penuh yang mendukung perintah Select dan Where dalam perintah (query). g. Keamanan : MySQL memiliki beberapa lapisan sekuritas seperti level subnetmask, nama host, dan izin akses user dengan sistem perizinan yang mendetail serta sandi terenkripsi. h. Skalabilitas dan Pembatasan : MySQL mampu menangani basis data dalam skala besar, dengan jumlah rekaman (records) lebih dari 50 juta dan 60 ribu tabel serta 5 milyar baris. Selain itu batas indeks yang dapat ditampung mencapai 32 indeks pada tiap tabelnya.
54
i. Konektivitas
:
MySQL
dapat
melakukan
koneksi
dengan
klien
menggunakan protokol TCP/IP, Unix soket (UNIX), atau Named Pipes (NT). j. Lokalisasi : MySQL dapat mendeteksi pesan kesalahan pada klien dengan menggunakan lebih dari dua puluh bahasa. Meski pun demikian, bahasa Indonesia belum termasuk di dalamnya. k. Antar Muka : MySQL memiliki interface (antar muka) terhadap berbagai aplikasi dan bahasa pemrograman dengan menggunakan fungsi API (Application Programming Interface). l. Klien dan Peralatan : MySQL dilengkapi dengan berbagai peralatan (tool) yang dapat digunakan untuk administrasi basis data, dan pada setiap peralatan yang ada disertakan petunjuk online. m. Struktur tabel : MySQL memiliki struktur tabel yang lebih fleksibel dalam menangani ALTER TABLE, dibandingkan DBMS lainnya semacam PostgreSQL ataupun Oracle. (sumber : www.id.wikipedia.com)
2.2.4
XAMPP XAMPP adalah paket PHP berbasis open source yang terdiri dari instalasi Apache, PHP, MySql, FTP dan Mercury yang merupakan salah satu aplikasi dalam membangun sebuah server web baik intranet maupun internet. (sumber : Web Server dengan XAMPP v.1.7.0, p37).
55
2.2.5
E-Rerporting (Laporan Elektronik) Menurut Mulyadi (2001, p5), Laporan merupakan hasil akhir dari proses akuntansi, berisi informasi yang keluar dari sistem. Laporan dapat berbentuk hasil cetak komputer dan tayangan pada layar monitor komputer. E-Reporting adalah suatu pelaporan yang disampaikan secara elektronik dengan menggunakan media elektronik. Media elektronik yang bisa di pakai untuk mengakses pelaporan ini berupa komputer dengan menggunakan jaringan intranet. (sumber : www.total.or.id) Menurut Connolly & Begg (2002, p496) intranet adalah suatu website yang dimiliki oleh suatu organisasi, yang hanya dapat diakses oleh anggota organisasi tersebut (jaringan yang tertutup).
2.2.5.1
Special Business Record (SBR) Special Business Record (SBR) merupakan
laporan
yang
berisi
permintaan penawaran harga yang diajukan oleh pelanggan kepada perusahaan. Perusahaan kemudian akan mengeskalasikannya secara bertahap hingga SBR tersebut disetujui atau ditolak. Berikut tahapan eskalasi SBR : a. Pegawai UNER b. Manager UNER c. GM UNES d. Pegawai EGM DIVES e. GM DIVES
56
f. VP Enterprise 2.2.5.2
Proposal Proposal merupakan laporan permintaan penyediaan barang dan jasa yang diajukan oleh Divisi Enterprise. Laporan ini menandakan bahwa SBR yang diajukan pelanggan telah disetujui. Laporan ini akan menjadi pengantar untuk selanjutnya diteruskan kepada bagian persediaan untuk memenuhi permintaan penawaran tersebut.
2.2.5.3
Justifikasi Justifikasi adalah laporan persetujuan penyediaan barang dan jasa yang ditujukan kepada Divisi Enterprise. Laporan ini berisi spesifikasi barang dan jasa yang diinginkan. Laporan ini juga memberikan informasi mengenai barang dan jasa lainnya yang dapat dijadikan bahan pertimbangan bagi pelanggan untuk kemudian menjadikan barang dan jasa tersebut sebagai barang dan jasa substitusi atau komplementer.
2.2.5.4
Provisioning Provisioning adalah laporan persetujuan permintaan barang dan jasa yang diajukan oleh Divisi Enterprise kepada pelanggan. Laporan ini menyatakan kesanggupan Divisi Enterprise atas nama PT. Telekomunikasi Indonesia Tbk (TELKOM) untuk memenuhi permintaan pelanggan.
2.2.5.5
Proyek
57
Proyek adalah laporan yang memuat mengenai perkembangan pelaksanaan dan penyediaan barang dan jasa yang telah berjalan. Laporan ini memuat aktivitas-aktivitas yang dilakukan perusahaan untuk memenuhi permintaan pelanggan beserta dengan permasalahan yang ada.
2.2.6
Istilah-istilah yang berkaitan dengan Divisi Enterprise (DIVES)
2.2.6.1
Account Manager (AM) Account Manager adalah petugas front line yang sesuai fungsinya melakukan pengelolaan
pelanggan
secara proaktif dan
individual
(personalized) bagi Corporate Customer dan diangkat sesuai ketentuan yang berlaku.
2.2.6.2
Corporate Customer (CC) CC adalah Pelanggan segmen Bisnis yang merupakan satu entitas bisnis yang memberikan kontribusi tertinggi terhadap pendapatan (dan laba) operasional TELKOM, dengan minimal pendapatan rata-rata sebesar Rp 500 Juta per bulan untuk seluruh penggunaan produk TELKOM.
