10
LANDASAN TEORI
2.1 Pendekatan Basis Data 2.1.1 Pengertian Basis Data
Menurut Connolly dan Begg (2005, p15), Basisdata adalah kumpulan-kumpulan data logis, merupakan deskripsi dari data tersebut, dan dirancang untuk menemukan serta memenuhi kebutuhan informasi yang dibutuhkan dari suatu organisasi atau persusahaan yang bersangkutan.
Menurut Atzeni, Ceri, Paraboschi, dan Torlone (2003, p3) Basisdata adalah sebuah koleksi data yang dikelola oleh sebuah DBMS.
2.1.2 Data Base Management System (DBMS)
Menurut Connolly dan Begg (2005, p16), DBMS adalah sebuah sistem perangkat lunak yang memperbolehkan user untuk mendefinisi, membuat, memelihara, dan mengendalikan akses terhadap sebuah sistem basis data.
Menurut Atzeni, Ceri, Paraboschi, dan Torlone (2003, p3) DBMS adalah sebuah sistem perangkat lunak (software) yang memungkinkan untuk mengelola koleksi-koleksi data yang besar, terbagi, dan konstan.
Fasilitas-fasilitas yang diberikan oleh suatu DBMS adalah sebagai berikut (Connolly dan Begg, 2005, pp16-17) :
1. Pendefinisian suatu basisdata menggunakan Data Definition Languange (DDL).
2. Penambahan, pengubahan, penghapusan, serta pengambilan data dari basisdata menggunakan Data Manipulation Languange (DML).
3. Penyediaan akses yang terkontrol ke basisdata, contohnya dapat memberikan :
a. Sistem keamanan (security system), mencegah pengguna yang tidak berhak mengakses basisdata.
b. Sistem integritas (integrity system), memelihara konsistensi data yang disimpan. c. Sistem kontrol akses yang bersamaan
(concurrency control system), mengijinkan akses basisdata bersama.
d. Sistem kontrol perbaikan (recovery control system), mengembalikan basisdata ke kondisi konsisten sebelumnya setelah terjadi kegagalan perangkat keras atau perangkat lunak.
e. Katalog pengguna (user-accessible catalog), berisi deskripsi data dalam basisdata.
DBMS mempunyai beberapa komponen utama seperti (Connolly dan Begg, 2005, pp18-21) :
a. Perangkat keras (Hardware)
Untuk menjalankan sebuah DBMS dan aplikasi-aplikasi, membutuhkan perangkat keras. Perangkat keras dapat berupa komputer pribadi, mainframe tunggal, sampai jaringan komputer. b. Perangkat lunak (Software)
Komponen perangkat lunak mengandung perangkat lunak DBMS itu sendiri dan program aplikasi, bersama dengan sistem operasi, termasuk perangkat lunak jaringan jika DBMS digunakan melalui jaringan. Secara khusus, program aplikasi ditulis dalam bahasa pemrograman generasi ketiga (3thGL), seperti C, C++, Java, Visual Basic, dll, atau menggunakan bahasa pemrograman generasi keempat (4thGL), seperti SQL yang ditambahkan 3th GL.
c. Data
Komponen yang paling penting dari DBMS yaitu data. Data bertindak sebagai jembatan antara komponen mesin dan komponen manusia. Basisdata terdiri dari data operasional dan meta-data, data mengenai data sendiri. Struktur basisdata ini disebut skema.
d. Prosedur
Prosedur menunjuk pada instruksi dan aturan yang mempengaruhi desain dan kegunaan basisdata. Pengunaan sistem dan staf yang mengatur basisdata membutuhkan prosedur yang didokumentasikan mengenai bagaimana menggunakan atau menjalankan sistem.
e. Pengguna
Komponen terakhir adalah pengguna yang dilibatkan dengan sistem.
Beberapa keuntungan dan kerugian dari DBMS (Connolly dan Begg, 2005, pp26-30) :
a. Keuntungan :
1. Mengontrol duplikasi data. 2. Konsistensi data.
3. Informasi yang lebih dari sejumlah data yang sama.
4. Penggunaan data bersama. 5. Meningkatkan integritas data. 6. Meningkatkan keamanan. 7. Pelaksanaan standarisasi. 8. Skala ekonomi tertentu.
9. Kebutuhan pengguna yang kompleks dapat teratasi.
10. Meningkatkan aksesibilitas data dan responsibilitas data.
11. Meningkatkan produktivitas.
12. Meningkatkan pemeliharaan melalui data yang bebas.
13. Meningkatkan konkurensi.
14. Layanan back up dan recovery semakin baik.
b. Kerugian : 1. Rumit.
2. Membutuhkan tempat penyimpanan yang besar di memori.
3. Biaya DBMS yang bervariasi. 4. Biaya tambahan perangkat keras.
5. Biaya konversi.
6. Kinerja aplikasi tidak berjalan cepat seperti seharusnya karena adanya DBMS.
7. Kerusakan pada bagian sistem menyebabkan operasi terhenti.
2.1.3 Structure Query Language (SQL)
Menurut Connolly dan Begg (2005, p113), Structure Query Language adalah sebuah contoh dari transformed-oriented language, atau sebuah bahasa yang didesain untuk menggunakan hubungan untuk mentransformasikan input ke output yang dibutuhkan. Sebagai sebuah bahasa, standar ISO SQL mempunyai dua komponen utama yaitu Data Definition Language (DDL) dan Data Manipulation Language (DML).
2.1.3.1 Data Definition Language (DDL)
Menurut Connolly dan Begg (2005, p40), Data Definition Language (DDL) adalah bahasa yang memungkinkan DBA atau pengguna mendeskripsikan dan memberi nama entitas, atribut, dan hubungan yang dibutuhkan untuk aplikasi, termasuk batasan-batasan keamanan dan integritasnya.
Hasil kompilasi dari DDL adalah seperangkat tabel yang disimpan dalam file spesial yang dinamakan sistem katalog. Sistem katalog ini mengintegrasikan meta-data, data yang menggambarkan objek dalam basisdata dan membuatnya menjadi lebih mudah untuk diakses.
2.1.3.2 Data Manipulation Language (DML)
Menurut Connolly dan Begg (2005, pp40-41), Data Manipulation Language adalah bahasa yang menyediakan seperangkat operasi untuk mendukung operasi dasar manipulasi data pada data dalam basisdata.
Operasi manipulasi data biasanya seperti memasukan data baru ke dalam basisdata (insert), memodifikasi data yang disimpan dalam basisdata (modification), mengambil data yang ada di dalam basisdata (retrieval), dan menghapus data dari basisdata (delete).
DML dibedakan menjadi dua tipe yaitu :
1. DML prosedural adalah bahasa yang memungkinkan pengguna untuk memberi instruksi ke sistem mengenai data yang dibutuhkan dan cara pengambilan data.
2. DML non-prosedural adalah bahasa yang memungkinkan pengguna untuk menentukan data apa yang dibutuhkan daripada bagaimana data tersebut diambil.
2.1.4 Fourth Generation Language (4th GL)
Menurut Connolly dan Begg (2005, pp42-43), dibandingkan dengan 3rd GL yang prosedural, 4th GL adalah non-prosedural yaitu pengguna lebih ditekankan pada pendefinisian apa yang akan dikerjakan, daripada bagaimana mengerjakannya. 4th GL meliputi :
a. Forms generator
Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa yang akan disajikan, komponen warna pada layar dan karakteristik lainnya.
b. Report generator
Membuat laporan yang diambil dari basisdata. Memungkinkan pengguna untuk mengambil data yang diperlukan untuk laporan. Lebih menekankan kepada rancangan output, yaitu bagaimana suatu laporan akan disajikan.
c. Graphics generator
Digunakan untuk mengambil data dari basisdata, dan menampilakan dalam bentuk grafik, seperti bar chart, pie chart, dll.
d. Application generator
Fasilitas untuk menghasilkan program yang berhubungan dengan data, menentukan bagaimana menampilkan fungsi-fungsi.
2.1.5 Database System Development Lifecycle
Menurut Connolly dan Begg (2005, pp284-306), Database System Development Lifecycle adalah sebagai berikut :
Gambar 2.1 Database System Development Lifecycle (Connolly dan Begg, 2005)
2.1.5.1 Database Planning
Merupakan aktifitas manajemen yang memungkinkan tahapan dari siklus hidup aplikasi basis data direalisasikan se-efektif dan se-efisien mungkin.
2.1.5.2 System Definition
Merupakan proses mendeskripsikan ruang lingkup dan batasan sebuah aplikasi basisdata dan sudut pandang utama pengguna.
2.1.5.3 Requirements Collection and Analysis
Merupakan sebuah proses dari pengumpulan dan penganalisaan informasi mengenai bagian dari sebuah organisasi yang dapat bermanfaat bagi sistem basisdata, dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan dari system yang baru.
Menurut Connolly dan Begg (2005, p317) ada beberapa cara dalam pengumpulan informasi dengan teknik fact-finding :
Mempelajari dokumen Wawancara
Observasi Penelitian
Kuisioner
2.1.5.4 Database Design
Merupakan suatu proses menciptakan sebuah rancangan yang mendukung visi dan misi perusahaan yang dibutuhkan bagi sebuah sistem basisdata.
Menurut Connolly dan Begg (2005, p439) metodologi perancangan sistem basis data terdiri dari 3 tahap, yaitu :
a. Tahap 1 : Perancangan basis data konseptual, yaitu proses dalam membangun sebuah model data yang digunakan pada perusahaan tanpa pertimbangan fisikal.
b. Tahap 2 : Perancangan basis data logikal, yaitu proses dalam membangun sebuah model data yang digunakan pada perusahaan berdasarkan atas model data yang spesifik, tetapi tidak mempertimbangkan DBMS tertentu dan pertimbangan fisikal lainnya. c. Tahap 3 : Perancangan basis data fisikal, yaitu proses yang
menciptakan hasil dari implementasi sebuah basis data dari penyimpanan tambahan, mendeskripsikan relasi dasar, organisasi file, dan indeks-indeks yang digunakan untuk mengakses data secara efisien, dan menghubungkan semua integrity constraints dan pengukuran keamanan.
2.1.5.5 DBMS Selection
Merupakan proses pemilihan DBMS yang tersedia untuk digunakan pada basis data yang sesuai.
2.1.5.6 Application Design
Merupakan perancangan sebuah tampilan pengguna (user interface) dan program aplikasi yang dapat mengakses dan melakukan proses terhadap basisdata.
2.1.5.7 Prototyping
Merupakan proses membangun model yang bekerja terhadap sistem basis data.
2.1.5.8 Implementation
Merupakan sebuah realisasi fisik suatu basis data dan suatu rancangan aplikasi.
2.1.5.9 Data Conversion and Loading
Mentransfer semua data yang ada ke dalam basis data yang baru dan mengubah semua aplikasi yang ada untuk dijalankan pada basis data yang baru tersebut.
2.1.5.10 Testing
Merupakan sebuah proses pengoperasian sistem basis data dengan tujuan untuk mencari kesalahan (error).
2.1.5.11 Operational Maintainance
Merupakan sebuah proses memantau dan memelihara sebuah sistem basis data pada masa instalasi.
2.1.6 Entity-Relationship Modeling
Menurut Connolly dan Begg (2005, p342) Entity-Relationship Modeling (ER Modeling) adalah pendekatan top-down pada perancangan basisdata, yang dimulai dengan indetifikasi data yang penting, disebut juga entitas, dan hubungan antar entitas yang harus direpresentasikan model.
2.1.6.1 Entity Types
Menurut Connolly dan Begg (2005, p343), tipe entitas adalah kumpulan dari objek-objek dengan properti yang sama, yang diidentifikasi oleh perusahaan yang mempunyai eksistensi yang independen.
Menurut Connolly dan Begg (2005, pp354-355), tipe entitas dibedakan menjadi 2, yaitu tipe entitas kuat dan
tipe entitas lemah. Tipe entitas kuat adalah tipe entitas yang keberadaannya tidak bergantung pada entitas yang lain, sedangkan tipe entitas lemah adalah tipe entitas yang keberadaannya bergantung pada entitas yang lain.
2.1.6.2 Relationship Types
Menurut Connolly dan Begg (2005, p346), tipe relasi adalah kumpulan keterhubungan yang mempunyai arti antara tipe entitas yang ada.
Menurut Connolly dan Begg (2005, pp347-349), derajat tipe hubungan yaitu jumlah entitas yang berpartisipasi dalam sebuah hubungan. Derajat tipe hubungan terdiri dari :
• Binary relationship merupakan keterhubungan antara dua tipe entitas.
• Ternary relationship merupakan keterhubungan antara tiga tipe entitas.
Gambar 2.3 Ternary Relationship
• Quarternary relationship merupakan keterhubungan antara empat tipe entitas.
• Unary relationship merupakan keterhubungan antara satu tipe entitas dimana tipe entitas tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. Kadang disebut juga recursive relationship.
Gambar 2.5 Unary Relationship
2.1.6.3 Attributes
Menurut Connolly dan Begg (2005, p350), atribut adalah properti dari sebuah entitas atau tipe relasi. Attribute domain merupakan sekumpulan nilai yang diperbolehkan bagi satu atau lebih atibut.
Tabel 2.1 Contoh dari attribute domain
Menurut Connolly dan Begg (2005, pp351-352), macam-macam atribut yaitu :
• Simple and composite attribute
Simple attribute adalah atribut yang terdiri dari satu komponen tunggal yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi, contohnya seperti, sex dan salary. Sedangkan composite attribute adalah attribut yang terdiri dari beberapa komponen, dimana masing-masing komponen memiliki keberadaan yang independen, contohnya Alamat dapat bercabang menjadi NamaJalan, NamaKota, KodePos .
• Single-valued and multi-valued attribute
Single-valued attribute adalah atribut yang memiliki nilai tunggal untuk setiap kejadian. Sedangkan multi-valued attribute adalah atribut yang memiliki beberapa nilai untuk setiap kejadian.
• Derived attribute
Derived attribute adalah atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
2.1.6.4 Keys
Menurut Connolly dan Begg (2005, pp252-253), ada tiga jenis kunci yaitu :
• Candidate key adalah jumlah minimal atribut-atribut yang secara unik mengdentifikasikan setiap kejadian dari tipe entitas.
• Primary key adalah kunci kandidat yang dipilih untuk mengidentifikasi setiap kejadian dari suatu tipe entias secara unik.
• Composite key adalah kunci kandidat yang terdiri dari dua atribut atau lebih.
2.1.6.5 Structural Constraints
Menurut Connolly dan Begg (2005, p356), batasan utama pada relationship disebut multiplicity, multiplicity adalah jumlah (atau range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relasi.
Relasi yang umum adalah binary relationship. Macam-macam binary relationship, yaitu one to one(1:1),
one to many (1:*), dan many to many (*:*).
Menurut Connolly dan Begg (2005, 363) multiplicity dibentuk dari dua macam batasan pada relationship, yaitu :
Cardinality yaitu batasan yang menjelaskan jumlah maksimum dari kejadian relasi yang mungkin untuk entitas yang berpartisipasi di dalam relasi tersebut.
Participation yaitu batasan yang menetapkan apakah seluruh atau hanya sebagian entitas yang berpartisipasi dalam suatu relasi.
2.1.7 Metodologi Perancangan Basisdata
Menurut Connolly dan Begg (2005, p438), metodologi perancangan basisdata merupakan pendekatan terstruktur yang menggunakan bantuan prosedur, teknik, tools, dan dokumentasi untuk mendukung dan memfasilitasi proses perancangan basisdata.
Metodologi perancangan basisdata terbagi atas 3 tahap perancangan yaitu perancangan konseptual, perancangan logikal dan perancangan fisikal basis data.
2.1.7.1 Perancangan Konseptual
Perancangan konseptual merupakan proses membangun model data yang digunakan oleh suatu perusahaan, bebas dari segala pertimbangan fisik (Connolly dan Begg, 2005, p439).
Langkah-langkah dalam membangun model data konseptual yaitu (Connolly dan Begg, 2005, pp1326-1328) :
Langkah 1 Membangun model data konseptual Langkah 1.1 Identifikasi entitas
Langkah pertama dalam membangun model data konseptual lokal adalah menentukan
objek-objek utama atau mengidentifikasi entitas-entitas yang diperlukan pengguna.
Langkah 1.2 Identifikasi hubungan (relationship)
Mengindentifikasi hubungan-hubungan (relationships) yang penting antara entitas-entitas yang ditemukan pada tahap sebelumnya. Entity-Relationship modeling digunakan untuk menggambarkan entitas dan hubungannya. Dalam tahap ini juga ditentukan batasan multiciply dari relationship tersebut dan pengecekan adanya fan atau chasm traps dalam model tersebut. Setelah itu, dilakukan dokumentasi relationship.
a. Fan traps terjadi dimana model yang merepresentasikan suatu hubungan antar entitas, tetapi alur relasinya memperlihatkan ambiguitas (Connolly dan Begg, 2005, p364).
b. Chasm traps terjadi dimana model menggambarkan keadaan dari
hubungan antara entitas yang satu dengan yang lainnya, tetapi tidak ada hubungan antara kedua entitas yang utama (Connolly dan Begg, 2005, p365).
Langkah 1.3 Identifikasi dan hubungkan atribut-atribut dengan entitas atau hubungan (relationship)
Menghubungkan atribut-atribut dengan entitas atau relationship yang tepat. Mengidentifikasi simple/composite attributes, single-valued/multi-valued attributes, dan derived attributes. Jenis-jenis atribut tersebut sudah dijelaskan di poin 2.1.6.3. Setelah itu, lakukan dokumentasi atribut.
Langkah 1.4 Menentukan wilayah atribut Menentukan wilayah atribut dalam model konseptual. Yang dimaksud wilayah adalah sekumpulan nilai-nilai dimana suatu atribut menggambarkan nilainya. Contoh : nilai
yang mungkin untuk atribut Jenis Kelamin dari entitas Karyawan adalah ‘M’ atau ‘F’, wilayah dari atribut ini adalah single character string yang berisi nilai ‘M’ atau ‘F’. Setelah itu, dilakukan dokumentasi domain atribut.
Langkah 1.5 Menentukan atribut candidate, primary, dan alternate key
Mengidentifikasi candidate key untuk tiap-tiap entitas dan, jika ada lebih dari satu candidate key, pilih salah satu untuk menjadi primary key dan lainnya menjadi alternate key. Pengertian candidate key dan primary key telah dibahas di poin 2.1.6.4. Dokumentasikan primary dan alternate key untuk tiap-tiap entitas yang merupakan strong entity.
Langkah 1.6 Mempertimbangkan penggunaan Enchanced Modelling Concepts (langkah opsional)
Mempertimbangkan penggunaan konsep
permodelan, seperti specialization/generalization, aggregation,
dan composition.
a. Specialization, adalah proses memaksimalkan perbedaan antara anggota-anggota entitas dengan mengidentifikasi karakteristik yang membedakan masing-masing entitas (Connolly dan Begg, 2005, p374). b. Generalization, adalah proses
meminimalkan perbedaan antara
entitas-entitas dengan mengidentifikasi karakteristik yang
sama dari masing-masing entitas (Connolly dan Begg ,2005, p375).
c. Aggregation, adalah
mempresentasikan hubungan ‘has-a’ atau ‘is-part-of’’ antara tipe-tipe entitas, dimana salah satu adalah
sebagai ‘whole’ dan yang lainnya sebagai ‘part ’ (Connolly dan Begg 2005, p383).
d. Composition, adalah sebuah bentuk spesifik dari aggregration yang mempresentasikan penggabungan antara entitas-entitas dimana ada kepemilikan yang kuat dan kesamaan lifetime antara ‘whole’ dan ‘part’ (Connolly dan Begg ,2005, p384).
Langkah 1.7 Memeriksa model akan adanya redudansi
Memeriksa keberadaan redudansi dalam model. Dilakukan pemeriksaan secara spesifik terhadap hubungan one-to-one (1:1), menghilangkan hubungan (relationship) yang redudan, dan mempertimbangkan penggunaan dimensi waktu.
Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna
Memastikan bahwa konseptual data telah mendukung transaksi-transaksi yang dibutuhkan. Dapat dilakukan dua cara yaitu :
a. Mendeskripsikan transaksi secara detail, dengan pendekatan ini berarti akan diperiksa semua informasi (entitas, relationship, dan atribut) yang dibutuhkan oleh setiap transaksi apakah telah disediakan dalam model, dengan mendokumentasikan setiap kebutuhan transaksi.
b. Menggunakan jalur transaksi (transaction pathways), pendekatan ini untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langusng pada diagram ER.
Langkah 1.9 Review model data konseptual dengan pengguna
Memeriksa model data konseptual dengan pengguna sistem untuk memastikan bahwa model data tersebut secara tepat menggambarkan transaksi dan kebutuhan data secara nyata dalam perusahaan.
2.1.7.2 Perancangan Logikal
Perancangan logikal merupakan proses membangun model data yang digunakan oleh suatu perusahaan berdasarkan model data spesifik, namun bebas dari penggunaan DBMS dan segala pertimbangan fisik (Connolly dan Begg, 2005, p439).
Langkah-langkah dalam membangun dan memvalidasikan model data logikal yaitu (Connolly dan Begg, 2005, pp1328-1330) :
Langkah 2 Membangun Data Model Logika Langkah 2.1 Menurunkan Relasi Untuk Model Data Logical
Membuat relasi dari model data konseptual untuk mempresentasikan entitas-entitas,
rekationships, dan atribut-atribut yang telah teridentifikasi. Tabel dibawah ini menunjukkan bagaimana memetakan entitas, hubungan (relationship) dan atribut sebuah relasi. Dokumentasikan relasi dan atribut foreign key. Dan juga dokumentasikan primary atau alternate key baru yang muncul dari hasil proses penurunan relasi.
Tabel 2.2 Pemetaan Entitas, Relationship, dan Atribut Sebuah Relasi Entitas/relationship/atribut Pemetaan relasi
Strong entity Membuat relasi yang
menyertakan semua atribut simple.
Weak entity Membuat relasi yang
menyertakan semua atribut simple (primary key masih harus ditentukan setelah relasi dengan tiap-tiap owner entity yang telah dipetakan).
1:* (one to many) binary relationship
Menyertakan primary key entitas pada sisi ‘one’ sebagai foreign key pada relasi yang menggambarkan entitas ‘many’. Semua atribut relasi juga disertakan pada entitas ‘many’.
1:1 (one to one) binary relationship
(a) Kewajiban partisipasi di dua sisi
(b) Kewajiban partisipasi di satu sisi
(c) Pilihan partisipasi di dua sisi
Mengkombinasikan entitas-entitas menjadi satu relasi. Menyertakan primary key entitas pada sisi ‘optional’ pada relasi yang menggambarkan entitas pada sisi ‘mandatory’.
Berubah-ubah tergantung informasi lebih lanjut mengenai partisipasi entitas. Superclass/Subclass
relationship
*:* (many to many) binary relationship, complex relationship
Membuat relasi untuk menggambarkan
relationship dan menyertakan atribut relationship tersebut. Sertakan duplikat primary
keys dari masing-masing owner entitas ke dalam relasi baru untuk berperan sebagai foreign key.
Multi-valued attribute Membuat relasi untuk menggambarkan atribut multi-valued dan menyertakan duplikat primary key dari
masing-masing owner entitas ke dalam relasi baru untuk berperan sebagai foreign key.
Tabel 2.3 Representasi dari Superclass/Subclass Relationship Berdasarkan pada Partisipasi dan Disjoint Constraints. Batasan Partisipasi Disjoint Constraint Pemetaan Relasi
Mandatory Nondisjoint {And} Relasi tunggal (dengan satu atau lebih diskriminator untuk membedakan tipe relasi) Optional Nondisjoint {And}
Dua relasi : satu relasi untuk superclass dan satu relasi untuk semua subclass (dengan satu atau lebih
diskriminator untuk membedakan tipe relasi)
Mandatory Disjoint {or} Banyak relasi : satu relasi untuk tiap-tiap kombinasi superclass/sub class.
Batasan Partisipasi Disjoint Constraint Pemetaan Relasi Optional Disjoint {or} Banyak relasi : satu relasi untuk superclass dan satu untuk tiap subclass.
Langkah 2.2 Validasi Relasi Menggunakan Normalisasi
Validasikan relasi pada model data logikal menggunakan teknik normalisasi. Tujuan langkah ini adalah untuk memastikan tiap-tiap relasi setidaknya berada dalam bentuk 3NF(Third Normal Form).
Langkah 2.3 Validasi Relasi Terhadap Transaksi Pengguna
Memastikan bahwa relasi-relasi yang ada dalam model data logikal telah mendukung transaksi-transaksi yang diperlukan.
Langkah 2.4 Memeriksa Batasan-Batasan Integritas (Integrity Constraints)
Menentukan batasan-batasan integritas (integrity constraints), dimana mencakup pemeriksaan lengkap :
a. Data yang dibutuhkan
Beberapa atribut harus mempunyai nilai yang valid, atau dengan kata lain tidak boleh null.
b. Batasan domain atribut
Setiap atribut mempunyai domain, yaitu kumpulan dari nilai-nilai yang memenuhi persyaratan (langkah 1.4).
c. Multiplicity
Merupakan batasan jumlah yang ditempatkan pada hubungan antar data di dalam basisdata (langkah 1.2).
d. Integritas entitas (entity integritas)
primary key dari sebuah entitas tidak boleh bernilai null (langkah 1.5)
e. Referential Integrity
sebuah foreign key menghubungkan setiap tuple pada relasi child ke tuple
pada relasi parent yang mengandung candidate key yang mempunya nilai yang sama.
f. Batasan umum (general constraint) Batasan yang berasal dari persyaratan-persyaratan bisnis perusahaan.
Kemudian dokumentasikan semua batasan-batasan integritas (integrity constraints).
Langkah 2.5 Review Model Data Logikal dengan Pengguna
Me-review model data logikal dengan pengguna untuk memastikan bahwa pengguna menyetujui model data logikal merupakan representasi nyata terhadap persyaratan data perusahaan.
Langkah 2.6 Gabungkan Model Data Logikal Menjadi Model Data Global
Metodologi perancangan logikal memudahkan perancangan basisdata yang sederhana maupun basisdata kompleks.
Untuk membuat basis data dengan multiple user view, digunakan pendekatan integrasi view. Pada tahap ini, model data-model data ini digabungkan menjadi satu. Kegiatan-kegiatan yang biasanya dilaksanakan dalam langkah ini antara lain :
a. Review nama dan isi entitas/ relasi dan candidate keys mereka.
b. Review nama dan isi dari relationships/foreign keys.
c. Menggabungkan entitas/relasi dari model data lokal.
d. Menyertakan (tanpa menggabungkan) entitas/relasi yang unik dari masing-masing model data lokal.
e. Menggabungkan relationships/foreign keys dari model data lokal.
f. Menyertakan (tanpa menggabungkan) relationships/foreign keys yang unik dari masing-masing model data lokal.
g. Memeriksa adanya entitas/relasi dan relationships/foreign keys yang hilang. h. Memeriksa foreign keys.
i. Memeriksa batasan integritas (integrity constraints).
j. Menggambar diagram ER global.
k. Update dokumentasi. Validasikan relasi yang dibentuk dari model data logikal global menggunakan teknik normalisasi dan memastikan mereka mendukung transaksi yang dibutuhkan.
Langkah 2.7 Memeriksa Perkembangan di masa yang Akan Datang
Menentukan apakah akan ada perubahan yang penting dapat muncul yang mungkin terjadi di masa yang akan datang dan untuk menilai apakah model data logikal dapat menyesuaikan diri dengan perubahan tersebut.
2.1.7.3 Perancangan Fisikal
Perancangan fisikal basisdata merupakan proses menghasilkan deskripsi implementasi basisdata pada secondary storage. Deskripsi yang dihasilkan meliputi relasi utama, organisasi file, dan index yang digunakan
unutk mencapai akses yang efisien terhadap data, dan segala batasan integritas dan aturan kemanan yang digunakan (Connolly dan Begg, 2005, p439).
Langkah-langkah dalam metodologi peracangan basisdata fisik yaitu (Connolly dan Begg, 2005, p1330-1331) :
Langkah 3 Menerjemahkan Model Data Logikal Untuk DBMS yang Ditargetkan
Langkah 3.1 Merancang relasi dasar Menentukan bagaimana representasi relasi dasar yang telah diidentifikasi pada model data logikal global, agar dapat diimplementasikan pada DBMS tujuan. Informasi yang dibutuhkan dapat diperoleh dari kamus data dan definisi dari relasi dideksripsikan menggunakan Database
Design Languange (DBDL). Dokumentasikan rancangan relasi dasar.
Langkah 3.2 Merancang Representasi Derived Data
Menentukan bagaimana representasi data turunan yang ada pada model data logikal global, agar dapat diimplementasikan pada DBMS tujuan. Atribut yang mana nilainya didapatkan dari mengkaji nilai atribut lain dinamakan derived atau calculated attributes. Contohnya jumlah karyawan yang bekerja pada suatu cabang perusahaan atau total gaji semua karyawan. Untuk setiap derived attribute yang ada, tanda ‘/’ digunakan untuk menandakan atribut tersebut adalah derived attribute. Dokumentasikan rancangan derived data.
Langkah 3.3 Merancang Batasan-Batasan Umum (General Constraint)
Merancang batasan-batasan umum untuk DBMS yang akan digunakan. Dokumentasikan rancangan batasan-batasan umum (general constraint).
Langkah 4 Merancang Organisasi File dan index
Langkah 4.1 Menganalisa Transaksi
Memahami fungsionalitas transaksi yang dijalankan pada basisdata dan menganalisis transaksi-transaksi yang penting.
Langkah 4.2 Memilih Organisasi File Tujuan langkah ini adalah menentukan organisasi file yang efisien untuk tiap-tiap relasi dasar jika diperolehkan DBMS yang akan digunakan.
Langkah 4.3 Memilih index
Tujuan langkah ini adalah untuk menentukan apakah menggunakan index akan meningkatkan kinerja sistem. Ada tiga jenis index yaitu :
• Primary index, pengindeksan dilakukan pada kolom kunci (key field), yang diurutkan terlebih dahulu secara sekuensial (Connolly dan Begg, 2005, p1277).
• Clustering index, pengindeksan dilakukan pada kolom bukan kunci (non-key field), yang sudah dirurutkan terlebih dahulu secara sekuensial. Kolom bukan kunci itu disebut juga dengan clustering attribute (Connolly dan Begg, 2005, p1277).
• Secondary index, pengindeksan dilakukan pada kolom yang tidak terurut di dalam file data (Connolly dan Begg, 2005, p1277).
Langkah 4.4 Memperkirakan Kebutuhan Kapasitas Disk
Memperkirakan besarnya ruang disk (disk space) yang dibutuhkan untuk mendukung implementasi basis data. Estimasi pemakaian disk tergantung pada DBMS dan perangkat keras yang digunakan untuk mendukung basisdata. Perkiraan ukuran dapat dilakukan dengan mengukur besar
data tiap baris dan jumlah baris pada setiap relasi.
Langkah 5 Merancang View Pengguna
Merancang view pengguna yang telah diidentifikasi selama tahap pengumpulan kebutuhan dan tahap analisa pada Daur Hidup Pengembangan Sistem Basisdata Relasional (System Development Life Cycle). Dokumentasikan rancangan view pengguna.
Langkah 6 Merancang Mekanisme Keamanan Merancang mekanisme keamanan untuk sistem basisdata, sesuai yang dibutuhkan pengguna. Ada dua macam keamanan basisdata yang disediakan oleh DBMS relational yaitu keamanan sistem mencakup akses dan penggunaan basisdata pada level sistem, seperti username dan password. Dan keamanan data mencakup akses dan penggunaan objek basisdata (seperti relasi dan view) dan aksi yang dapat dimiliki pengguna terhadap objek. Keamanan bagi sistem basisdata sangat
diperlukan karena basisdata merupakan sumber daya perusahaan yang penting.
Langkah 7 Mempertimbangkan Adanya Redudansi Terkontrol (Controlled Redudancy)
Menentukan apakah adanya redudansi yang terkontrol dengan cara melonggarkan aturan normalisasi akan meningkatkan kinerja sistem. Misalnya, mempertimbangkan duplikasi atribut-atribut atau join relasi bersama. Dokumentasikan adanya redudansi.
Langkah 8 Mengawasi dan Melakukan Setting Terhadap Sistem Operasi
Mengawasi sistem operasional dan meningkatkan kinerja sistem untuk memperbaiki keputusan perancangan yang kurang tepat atau dalam mengatasi kemungkinan adanya perubahan.
2.1.8 Normalisasi
Menurut Connolly dan Begg (2005, p388), normalisasi merupakan suatu teknik formal untuk menghasilkan kumpulan hubungan dengan kepemilikan yang dikehendaki, yang memiliki kebutuhan dari sebuah perusahaan, dan berfungsi untuk menganalisis relasi berdasarkan primary key (atau candidate key) dan functional dependency.
Menurut Atzeni, Ceri, Paraboschi, dan Torlone (2003, p255), normalisasi merupakan sebuah proses yang mengijinkan perubahan skema non-normalized menjadi skema-skema baru dengan struktur yang telah normal.
Tahapan-tahapan normalisasi menurut Connolly dan Begg (2005, pp403-4011), yaitu :
1. Unnormalized Form, merupakan sebuah tabel yang mengandung satu atau lebih kelompok perulangan.
2. First Normal Form (1NF), merupakan suatu relasi dimana perpotongan antara setiap barisdan kolom memiliki tepat satu nilai. Fungsi 1NF adalah untuk :
a. Menghilangkan perulangan (redudansi) dan perhitungan.
b. Memecah data yang redundansi menjadi tabel yang baru.
3. Second Normal Form (2NF), merupakan sebuah relasi di dalam 1NF dan pada setiap atribut yang non-primary key memiliki ketergantungan fungsional secara penuh terhadap primary key. Fungsi 2NF adalah untuk menghilangkan ketergantungan yang bersifat parsial (ketergantungan).
4. Third Normal Form (3NF), merupakan sebuah relasi yang terdapat pada 1NF dan 2NF dan tidak memiliki atribut yang bukan primary key yang memiliki ketergantungan transitif terhadap primary key. Fungsi 3NF adalah untuk menghilangkan ketergantungan transitif yang bersangkutan.
2.2 Client-Server
Client-server merupakan sebuah paradigma dalam teknologi informasi yang merujuk kepada cara untuk mendistribusikan aplikasi ke dalam dua pihak, yaitu pihak client dan pihak server.
Dalam model client/server, sebuah aplikasi dibagi menjadi dua bagian yang terpisah, tapi masih merupakan sebuah kesatuan yakni komponen client dan komponen server. Komponen client juga sering disebut sebagai front-end, sementara komponen server disebut sebagai back-end. Komponen client dari aplikasi tersebut dijalankan dalam sebuah workstation dan menerima masukan data dari pengguna. Komponen client tersebut akan menyiapkan data yang dimasukkan oleh pengguna dengan menggunakan teknologi pemrosesan tertentu
dan mengirimkannya kepada komponen server yang dijalankan di atas mesin server, umumnya dalam bentuk request terhadap beberapa layanan yang dimiliki oleh server. Komponen server akan menerima request dari client, dan langsung memprosesnya dan mengembalikan hasil pemrosesan tersebut kepada client. Client pun menerima informasi hasil pemrosesan data yang dilakukan server dan menampilkannya kepada pengguna, dengan menggunakan aplikasi yang berinteraksi dengan pengguna.
Client-server merupakan penyelesaian masalah pada software yang menggunakan basisdata sehingga setiap komputer tidak perlu meng-install basisdata, dengan metode client -server database dapat diinstal pada suatu komputer sebagai server dan aplikasinya diinstal pada client. (http://id.wikipedia.org/wiki/Klien-server)
2.2.1 2-tier Architechture
2-tier architechture membagi proses load kedalam dua bagian. Aplikasi utama secara logika dijalankan/berjalan pada sisi client yang biasanya mengirimkan request dalam bentuk sintaks SQL ke sebuah database server yang berfungsi sebagai media penyimpanan data. Kita bisa juga menyebutnya dengan arsitektur fat client karena bagian terbesar atau yang utama dari aplikasi berjalan pada sisi client/ komputer client.
2.2.2 3-tier Architechture
3-tier architechture membagi proses loading antara 1) komputer client menjalankan graphical user interface (GUI) logic, 2) aplikasi server menjalankan business logic, dan 3) database dan/ atau legacy application. Karena 3-tier memindahkan application logic ke server sehingga sering juga disebut sebagai arsitektur fat server.
(http://dosen.amikom.ac.id/downloads/artikel/2tier%20VS%203tier.pdf)
2.3 Tools yang Digunakan 2.3.1 Data Flow Diagram
Menurut Whitten, Bentley, dan Dittman (2004, p344), Data Flow Diagram (DFD) merupakan model proses yang digunakan untuk menggambarkan suatu aliran data melalui sebuah sistem dan tugas atau sebuah proses yang dilakukan oleh sistem. Simbol-simbol yang terdapat pada DFD :
1. Processes
Tugas yang dikerjakan oleh suatu sistem dalam tanggapan terhadap aliran data yang masuk atau keadaan. Simbolnya adalah :
2. External Entity
Merupakan entity (orang, unit organisasi, sistem, atau organisasi) yang berasal dari luar yang berinteraksi dengan sistem. Simbolnya adalah :
3. Data Stores
Merupakan data yang tersimpan yang bertujuan untuk kegunaan yang akan datang, dan dapat digunakan apabila sewaktu-waktu data tersebut dibutuhkan. Simbolnya adalah :
4. Data Flows
Merupakan tanda yang menggambarkan data yang masuk atau keluar menuju atau dari suatu proses yang ada. Simbolnya adalah :
2.3.2 Flowchart
Menurut Widia S (1982, p4), Flowchart adalah bagan yang menggambarkan urutan dan instruksi untuk proses dengan komputer dan hubungan antara suatu proses dengan proses lainnya, dengan menggunakan simbol-simbol tertentu. Ada dua macam tipe flowchart, yaitu :
1. System Flowchart
System Flowchart adalah suatu bagan dengan simbol-simbol tertentu yang menggambarkan urutan prosedur dan proses dari suatu
file di dalam suatu media menjadi file di dalam media lain, dalam suatu sistem pengolahan data.
2. Program Flowchart
Merupakan suatu bagan dengan simbol tertentu yang menggambarkan urutan proses secara mendetail dan hubungan antara suatu proses (instruksi) dengan proses lainnya dalam suatu program.
2.3.3 State-Transition Diagram
Menurut Whitten, Bentley, dan Dittman (2004, p673), State-Transition Diagram (STD) merupakan suatu alat yang digunakan untuk menggambarkan urutan dan variasi screens yang dapat terjadi selama satu sesi pengguna. Notasi-notasi yang digunakan dalam STD yaitu :
1. Kotak digunakan untuk menggambarkan State sistem.
2. Anak panah menunjukan arah perubahan state.
3. Kondisi dinyatakan dengan tulisan yang diberi garis bawah.
4. Aksi dinyatakan dengan tulisan tanpa garis bawah. Biasanya terletak di bawah kondisi. Gambar 2.6 Notasi yang digunakan
2.4 Terminologi Pajak Bumi dan Bangunan Sektor Perkebunan Sektor perkebunan kaitannya dalam Pajak Bumi dan Bangunan merupakan objek pajak PBB yang digunakan untuk pengusahaan tanaman perkebunan dengan luasan paling sedikit 2 (dua) hektar, termasuk emplasemen (Pengenaan PBB Sektor Perkebunan Direktorat Jenderal Pajak (PER-50/PJ/2008 DAN SE-81/PJ/2008)). Terdapat beberapa terminologi yang ada dalam Undang-undang Pajak Bumi dan Bangunan, antara lain :
- Bumi - Bangunan
- Nilai Jual Objek Pajak
- Surat Pemberitahuan Objek Pajak - Surat Pemberitahuan Pajak Terutang
2.4.1 Bumi
Menurut Gunadi, Hutagaol, Burton, Pandiangan, Ilyas, Satiomo (1999, p129), Bumi merupakan permukaan bumi dan tubuh bumi yang ada di bawahnya, sehingga dapat di beri pengertian bahwa bumi meliputi tanah (perkebunan) dan perairan pedalaman serta laut wilayah Indonesia.
Menurut Pengenaan PBB Sektor Perkebunan Direktorat Jenderal Pajak (SE-81/PJ/2008), Bumi dibagi menjadi beberapa jenis, antara lain :
• Areal Produktif (Areal yang sudah ditanam) : a. Areal Tanaman belum
menghasilkan
b. Areal tanaman menghasilkan • Areal Belum Produktif :
a. Areal yang sudah diolah tetapi belum ditanami
b. Areal belum diolah
• Areal Emplasemen, yaitu areal yang digunakan untuk berdirinya bengunan dan sarana pelengkap lainnya dalam perkebunan. • Areal Lainnya :
a. Areal tidak produktif atau tidak dapat dimanfaatkan seperti rawa, cadas, dan jurang.
b. Areal jalan, meliputi :
- Jalan Utama : Terletak di dalam atau diluar areal perkebunan.
- Jalan Produksi : Berfungsi untuk pengumpulan hasil
- Jalan Kontrol : Berfungsi untuk pengawasan areal perkebunan
2.4.2 Bangunan
Menurut Gunadi, Hutagaol, Burton, Pandiangan, Ilyas, Satiomo (1999, p129), Bangunan adalah konstruksi teknik yang ditanam atau dilekatkan secara tetap pada tanah atau perairan.
Menurut Pengenaan PBB Sektor Perkebunan Direktorat Jenderal Pajak (SE-81/PJ/2008), Bangunan meliputi segala konstruksi teknik yang ditanam atau dilekatkan secara tetep pada tanah dan perairan , yaitu bangunan dan infrastruktur lainnya seperti jalan, jembatan, dan sebagainya.
2.4.3 Nilai Jual Objek Pajak (NJOP)
Menurut Gunadi, Hutagaol, Burton, Pandiangan, Ilyas, Satiomo (1999, p130), NJOP adalah harga rata-rata yang diperoleh dari transaksi jual beli yang terjadi secara wajar, dan bilamana tidak terdapat transaksi jual beli, NJOP ditentukan melalui perbandingan harga dengan objek lain yang sejenis, atau perolehan baru, atau NJOP pengganti.
2.4.4 Surat Pemberitahuan Objek Pajak (SPOP)
Menurut Gunadi, Hutagaol, Burton, Pandiangan, Ilyas, Satiomo (1999, p130), SPOP adalah surat yang digunakan oleh wajib pajak untuk melaporkan data objek pajak menurut ketentuan undang-undang.
2.4.5 Surat Pemberitahuan Pajak Terutang (SPPT)
Menurut Gunadi, Hutagaol, Burton, Pandiangan, Ilyas, Satiomo (1999, p130), SPPT adalah surat yang digunakan oleh Direktorat Jenderal Pajak untuk memberitahukan besarnya pajak terutang kepada wajib pajak.
2.5 Terminologi Pendaftaran dan Pendataan, Penilaian, Penetapan, Pembayaran dan Penagihan PBB
2.5.1 Pendaftaran dan Pendataan
Menurut Suandy (2002, p352), dalam rangka pendataan, Subjek Pajak wajib mendaftarkan objek pajaknya dengan mengisi Surat Pemberitahuan Objek Pajak (SPOP). Wajib Pajak akan diberikan SPOP untuk diisi dan dikembalikan kepada Direktorat Jenderal Pajak. Wajib Pajak yang pernah dikenakan Iuran Pembangunan Daerah (IPEDA) tidak wajib mendaftarkan objek pajaknya kecuali ia menerima SPOP, maka dia wajib mengisinya dan mengembalikannya kepada Direktorat Jenderal Pajak. SPOP harus diisi dengan jelas, benar, lengkap dan tepat waktu serta ditandatangani dan disampaikan kepada Dirjen Pajak yang wilayah keadaannya meliputi letak objek pajak selambat-lambatnya 30 ( tiga puluh ) hari setelah tanggal diterimanya SPOP oleh subjek pajak.
Jelas, dimaksudkan agar penulisan data yang diterima dalam SPOP dibuat sedemikian rupa sehingga tidak menimbulkan salah tafsir yang dapat merugikan negara maupun WajibPajak sendiri.
Benar, berarti data yang dilaporkan harus sesuai dengan keadaan yang sebenarnya seperti luas tanah dan/atau bangunan, tahun dan harga perolehan dan seterusnya sesuai dengan kolom-kolom/pertanyaan yang ada pada Surat Pemberitahuan Objek Pajak (SPOP).
2.5.2 Penilaian
Penilaian PBB diklasifikasikan menurut bumi dan bangunan adalah:
1. Bumi dan Tanah
- Dinilai atas dasar transaksi jual beli tanah yang terjadi di wilayah tersebut
- Kemudian Dirjen Pajak menerbitkan Nilai Jual Obyek Pajak (NJOP) serta ditetapkan oleh Menteri Keuangan setiap 3 tahun sekali
- Atas penilaian ini fiskus mencantumkan kelas tanah pada Surat Pemberitahuan Obyek Pajak (SPOP)
2. Bangunan
Obyek pajak bangunan dinilai atas:
- Bahan yang digunakan
- Jenis konstruksi
- Letak bangunan
- Kondisi lingkungan dan lain-lain
- Atas dasar penilaian ini ditetapkan klasifikasi Nilai Bangunan yang dicantumkan pada SPOP.
(http://arsasi.wordpress.com/2008/09/09/pajak-bumi-dan-bangunan-pbb/)
2.5.3 Penetapan
Sesuai dengan yang tercantum dalam pasal 1 UU Nomor 12 Tahun 1994 tentang Pajak Bumi dan Bangunan, Nilai Jual Objek Pajak (NJOP) ditetapkan berdasarkan harga rata-rata yang diperoleh dari transaksi jual beli yang terjadi secara wajar.
2.5.4 Pembayaran
Menurut Suandy (p534, 2002), pajak yang terutang berdasarkan Surat Pemberitahuan Pajak Terutang harus dilunasi
selambat-lambatnya enam bulan sejak tanggal diterimanya Surat Pemberitahuan Pajak Terutang oleh Wajib Pajak.
Pajak yang terutang bedasarkan Surat Ketetapan Pajak harus dilunasi selambat-lambatnya 1 (satu) bulan sejak tanggal diterimanya Surat Ketetapan Pajak oleh Wajib Pajak.
Pajak yang terutang pada saat jatuh tempo pembayaran tidak dibayar, dikenakan denda administrasi sebesar 2% (dua persen) sebulan, yang dihitung dari saat jatuh tempo sampai dengan hari pembayaran untuk jangka waktu paling lama 24 (dua puluh empat) bulan.
Denda administrasi ditambah dengan utang pajak yang belum atau kurang dibayar, ditagih dengan Surat Tagihan Pajak yang harus dilunasi selambat-lambatnya 1 (satu) bulan sejak tanggal diterima Surat Tagihan Pajak oleh Wajib Pajak.
Surat Pemberitahuan Pajak Terutang, Surat Ketetapan Pajak, dan Surat Tagihan Pajak merupakan dasar penagihan pajak.
Jumlah pajak yang terutang berdasarkan Surat Tagihan Pajak yang tidak dibayar pada waktunya dapat ditagih dengan Surat Paksa.
2.5.5 Penagihan
Proses penagihan merupakan tindakan penagihan pajak yang dilakukan apabila utang pajak sampai dengan tanggal jatuh
tempo pembayaran belum dilunasi, maka akan dilakukan tindakan penagihan pajak sebagai berikut:
a. Surat Teguran
Utang pajak yang tidak dilunasi setelah lewat 7 (tujuh) hari dari tanggal jatuh tempo pembayaran, akan diterbitkan Surat Teguran.
b. Surat Paksa
Utang pajak setelah lewat 21 (dua puluh satu) hari dari tanggal Surat Teguran tidak dilunasi, diterbitkan Surat Paksa yang diberitahukan oleh Jurusita Pajak dengan dibebani biaya penagihan pajak dengan Surat Paksa sebesar Rp 50.000,00 (lima puluh ribu rupiah). Utang pajak harus dilunasi dalam jangka waktu 2 x 24 jam setelah Surat Paksa diberitahukan oleh Jurusita Pajak. c. Surat Sita
Utang pajak dalam jangka waktu 2 x 24 jam setelah Surat Paksa diberitahukan oleh Jurusita Pajak tidak dilunasi, Jurusita Pajak dapat melakukan tindakan penyitaan, dengan dibebani biaya pelaksanaan Surat Perintah Melakukan Penyitaan sebesar Rp 100.000,00 (seratus ribu rupiah).
d. Lelang
Dalam jangka waktu paling singkat 14 (empat belas) hari setelah tindakan penyitaan, utang pajak belum juga dilunasi akan dilanjutkan dengan pengumuman lelang melalui media massa. Penjualan secara lelang melalui Kantor Lelang Negara terhadap barang yang disita, dilaksanakan paling singkat 14 (empat belas) hari setelah pengumuman lelang. Dalam hal biaya penagihan paksa dan biaya pelaksanaan sita belum dibayar maka akan dibebankan bersama-sama dengan biaya iklan untuk pengumuman lelang dalam surat kabar dan biaya lelang pada saat pelelangan.
(http://www.pajak.go.id/index.php?option=com_content&view=articl e&id=57:prosedur-satu&catid=45:prosedur-pajak&Itemid=85
2.6 Prosedur Pajak Bumi dan Bangunan
Gambar 2.7 Prosedur Proses Pajak Bumi dan Bangunan
