BAB

2

LINGKUNGAN

BASIS DATA

rsitektur Basis Data adalah sebuah struktur antara komponen - komponen yang membangun Basis Data dan

hubungan atau relasi yang mengaitkan komponen - komponen tersebut, dalam artian lainnya, bahwa Basis

Data dibangun dari berbagai komponen, dimana setiap komponen memiliki fungsi dan terhubung dengan

komponennya. Arsitektur ini memberikan kerangka kerja bagi pembangunan Basis Data.

2.1 ARSITEKTUR THREE-LEVEL ANSI-SPARC

Proposal awal untuk terminologi arsitektur dan standar umum untuk sistem basis data dibuat pada tahun 1971 oleh

DBTG (Data Base Task Group) ditunjuk oleh Conference on Data Systems and Languages (CODASYL, 1971). DBTG

mengakui perlunya pendekatan dua level tingkatan dengan pandangan sistem yang disebut skema dan pandangan

pengguna disebut sub skema. American National Standards Institute (ANSI) Standards Planning and Requirements

Committee (SPARC), ANSI/X3/SPARC, menghasilkan terminologi dan arsitektur yang sama pada tahun 1975 (ANSI,

1975). ANSI-SPARC mengakui perlunya pendekatan tiga tingkatan dengan sistem katalog. Proposal ini tercermin

dengan diterbitkannya IBM User Organizations Guide and Share beberapa tahun sebelumnya. Meskipun model

ANSI-SPARC tidak menjadi standar, tetapi kita perlu mengetahui beberapa hal dasar untuk memahami fungsi DBMS.

Gambar 2.1 - ANSI-SPARC Three-Level Architecture.

Pada Gambar 2.1 terdapat tiga tingkakatan abstraksi yang bertujuan untuk membedakan cara pandang pemakai

terhadap basis data dan cara pembuatan basis data secara fisik.

A

Ada beberapa alasan mengapa pemisahan tiap level ini sangat diperlukan :

1. Setiap pengguna harus dapat mengakses data yang sama, tetapi dengan cara pandang yang berbeda. Setiap

pengguna harus dapat mengubah cara ia memandang data, namun perubahan tersebut tidak mempengaruhi

pengguna lain.

2. Pengguna tidak harus berhubungan langsung dengan penyimpanan fisik database secara rinci, seperti

pengindeksan atau hashing. Dengan kata lain, interaksi pengguna dengan database harus independen dari

penyimpanan.

3. Database Administrator (DBA) harus mampu mengubah struktur penyimpanan database tanpa mempengaruhi

pandangan pengguna.

4. Struktur internal database seharusnya tidak terpengaruh oleh perubahan aspek fisik penyimpanan, seperti

pergantian perangkat penyimpanan baru.

5. DBA harus dapat mengubah struktur konseptual database tanpa mempengaruhi semua pengguna.

2.1.1 TINGKAT EKSTERNAL (EXTERNAL LEVEL)

External Level The users’ view of the database. This level describes that part of the database

that is relevant to each user.

Tingkat eksternal merupakan cara pandang pemakai terhadap basis data. Pada tingkat ini menggambarkan bagian

basis data yang relevan bagi seorang pemakai tertentu. Tingkat eksternal terdiri dari sejumlah cara pandang yang

berbeda dari sebuah basis data. Masing-masing pemakai merepresentasikan dalam bentuk yang sudah dikenalnya.

Cara pandang secara eksternal hanya terbatas pada entitas, atribut dan hubungan antar entitas (relationship) yang

diperlukan saja.

Selain itu, pandangan yang berbeda mungkin memiliki representasi yang berbeda dari data yang sama.

Sebagai contoh, satu pengguna dapat melihat tanggal dalam bentuk (hari, bulan, tahun), sementara yang lain

mungkin melihat tanggal sebagai (tahun, bulan, hari).

2.1.2 TINGKAT KONSEPTUAL (KONSEPTUAL LEVEL)

Conseptual

Level

The community view of the database. This level describes what data is stored

in the database and the relationships among the data.

Tingkat konseptual merupakan kumpulan cara pandang terhadap basis data. Pada tingkat ini menggambarkan data

yang disimpan dalam basis data dan hubungan antara datanya. Hal-hal yang digambarkan dalam tingkat konseptual

adalah :

Semua entitas beserta atribut dan hubungannya,

Batasan data, informasi semantik tentang data,

Informasi semantic tentang data,

Keamanan dan integritas informasi.

Semua cara pandang pada tingkat eksternal berupa data yang dibutuhkan oleh pemakai harus sudah tercakup di

dalam tingkat konseptual atau dapat diturunkan dari data yang ada. Deskripsi data dari entitas pada tingkat ini hanya

terdiri dari jenis data dan besarnya atribut tanpa memperhatikan besarnya penyimpanan dalam ukuran byte.

2.1.3 TINGKAT INTERNAL (INTERNAL LEVEL)

Internal

Level

The physical representation of the database on the computer. This level

describes how the data is stored in the database.

Tingkat internal merupakan perwujudan basis data dalam komputer. Pada tingkat ini menggambarkan

bagaimana basis data disimpan secara fisik di dalam peralatan storage yang berkaitan erat dengan tempat

penyimpanan / physical storage. Tingkat internal memperhatikan hal-hal berikut ini :

Alokasi ruang penyimpanan data dan indeks

Deskripsi record untuk penyimpanan (dengan ukuran penyimpanan untuk data elemen

Penempatan record

Pemampatan data dan teknik encryption

2.1.4 SKEMA, PEMETAAN DAN INSTANCES

Gambaran keseluruhan basis data disebut skema basis data. Terdapat tiga skema dalam basis data, pada tingkat

tertinggi, skema eksternal (juga disebut Sub-Skema) yang sesuai dengan pandangan yang berbeda dari data. Pada

tataran konseptual, menggambarkan semua entitas, atribut, dan hubungan bersama dengan kendala integritas.

Pada tingkat terendah abstraksi kita memiliki skema internal, yang merupakan deskripsi lengkap tentang internal

model, yang berisi definisi dari catatan yang disimpan, metode representasi, bidang data, dan indeks dan struktur

penyimpanan yang digunakan. Hanya ada satu skema konseptual dan satu skema internal per database.

DBMS bertanggung jawab untuk memetakan ketiga jenis skema basis data tersebut dan memeriksa

konsistensi skema, dalam kata lain, DBMS harus memastikan setiap skema eksternal diturunkan dari skema

konseptual (menggunakan informasi dalam skema konseptual) agar dapat berhubungan dengan skema internal

melalui pemetaan konseptual/internal.

Gambar 2.2 Perbedaan Cara Pandang Pemakai Terhadap Basis Data

Hal ini memungkinkan DBMS untuk menemukan catatan yang sebenarnya atau kombinasi catatan dalam

penyimpanan fisik yang merupakan record logis dalam skema konseptual, bersama dengan batasan yang akan

diberlakukan pada operasi untuk catatan logis. Hal ini juga memungkinkan setiap perbedaan dalam nama entitas,

nama atribut, urutan atribut, tipe data, dan sebagainya, harus diselesaikan. Akhirnya, masing-masing skema

eksternal berhubungan dengan skema konseptual dengan pemetaan eksternal / konseptual. Hal ini memungkinkan

DBMS untuk memetakan nama dalam pandangan pengguna ke bagian yang relevan dari skema konseptual.

Penting untuk membedakan antara deskripsi dari basis data dan basis data itu sendiri. Deskripsi basis data

adalah skema basis data. Skema ditentukan selama proses desain basis data dan seminimal mungkin berubah.

Namun, data aktual dalam basis data mungkin sering berubah, misalnya, berubah setiap kali kita memasukkan

rincian dari anggota baru staf atau properti baru. Data dalam basis data pada setiap titik waktu tertentu disebut

database instance.

2.1.5 DATA INDEPENDENCE

Tujuan utama dari arsitektur 3 tingkat adalah memelihara kemandirian data (data independence) yang berarti

perubahan yang terjadi pada tingkat yang lebih rendah tidak mempengaruhi tingkat yang lebih tinggi.

Ada 2 jenis data independence, yaitu

1. Physical Data Independence

Bahwa internal schema dapat diubah oleh DBA tanpa menggangu conceptual schema. Dengan kata lain

physical data independence menunjukkan kekebalan conceptual schema terhadap perubahan internal

schema.

Physical Data

Independence

Logical data refers to the immunity of the external independence

schemas to changes in the conceptual schema.

2. Logical Data Independence

Bahwa conceptual schema dapat diubah oleh DBA tanpa menggangu external schema. Dengan kata lain logical

data independence menunjukkan kekebalan external schema terhadap perubahan conceptual schema.

Logical Data

Independence

Physical data independence refers to the immunity of the conceptual

schema to changes in the internal schema.

Prinsip data independence adalah salah satu hal yang harus diterapkan di dalam pengelolaan sistem basis data

dengan alasan-alasan sbb :

1. DBA dapat mengubah isi, lokasi, perwujudan dalam organisasi basis data tanpa mengganggu program-

program aplikasi yang sudah ada.

2. Pabrik / agen peralatan / software pengolahan data dapat memperkenalkan produk-produk baru tanpa

mengganggu program-program aplikasi yang sudah ada.

3. Untuk memindahkan perkembangan program-program aplikasi

4. Memberikan fasilitas pengontrolan terpusat oleh DBA demi keamanan dan integritas data dengan

memperhatikan perubahan-perubahan kebutuhan pengguna.

Gambar 2.3 Data independence dan ANSI-SPARC Three-Level Architecture

2.2 BAHASA DALAM BASIS DATA

DBMS (Database Management systems) adalah kumpulan program yang mengkoordinasikan semua kegiatan yang

berhubungan dengan basis data. Dengan adanya berbagai tingkatan pandangan dalam suatu basis data maka untuk

mengakomodasikan masing-masing pengguna dalam piranti lunak manajemen basis data biasanya terdapat

bahasa-bahasa tertentu yang disebut Data Sub language.

Data sub language adalah subset bahasa yang dipakai untuk operasi manajemen basis data. Dalam

penggunaan biasanya dapat ditempelkan (embedded) pada bahasa tuan rumah (Cobol, PL/1, dsb). Secara umum

maka setiap pengguna basis data memerlukan bahasa yang dipakai sesuai tugas dan fungsinya.

2.2.1 DATA DEFINITION LANGUAGE (DDL)

DDL

A language that allows the DBA or user to describe and name the entities,

attributes, and relationships required for the application, together with any

associated integrity and security constraints.

Skema database ditentukan oleh sekumpulan definisi diungkapkan dengan bahasa khusus yang disebut Data

Definition Language. DDL digunakan untuk mendefinisikan skema atau memodifikasi yang sudah ada. Hal ini tidak

dapat digunakan untuk memanipulasi data.

Hasil penyusunan laporan DDL adalah satu set tabel yang disimpan dalam file khusus secara kolektif yang

disebut sistem katalog. Sistem katalog mengintegrasikan metadata, yaitu data yang menggambarkan objek dalam

database dan membuatnya lebih mudah diakses atau dimanipulasi.

2.2.2 DATA MANIPULATION LANGUAGE (DML)

DML

A language that provides a set of operations to support the basic data

manipulation operations on the data held in the database.

Bahasa yang digunakan untuk menjabarkan pemrosesan dari basis data, fasilitas ini diperlukan untuk memasukkan,

mengambil, mengubah data. DML dipakai untuk operasi terhadap isi basis data. Operasi manipulasi data biasanya

meliputi:

Penyisipan data baru ke dalam basis data;

Modifikasi data yang disimpan dalam basis data;

Pengambilan data yang terdapat dalam basis data;

Penghapusan data dari basis data.

Bagian dari DML yang melibatkan pengambilan data disebut bahasa query. Sebuah bahasa query tingkat tinggi

bertujuan khusus yang digunakan untuk memenuhi permintaan dan pengambilan beragam data dalam database.

Ada 2 jenis DML, yaitu :

a. Procedural DML

Procedural

DML

A language that allows the user to tell the system what data is needed

and exactly how to retrieve the data.

digunakan untuk mendefinisikan data yang diolah dan perintah yang akan dilaksanakan.

b. Non Procedural,

Non Procedural

DML

A language that allows the user to state what data is needed rather

than how it is to be retrieved.

digunakan untuk menjabarkan data yang diinginkan tanpa menyebutkan bagaimana cara pengambilannya.

2.2.3 FOURTH GENERATION LANGUAGE (DDL)

Tidak ada konsensus tentang bahasa generasi keempat, pada dasarnya merupakan bahasa pemrograman steno.

Sebuah operasi yang membutuhkan ratusan baris dalam bahasa generasi ketiga (3GL).

Dibandingkan dengan 3GL, yang prosedural, 4GL berjenis non-prosedural: user mendefinisikan apa yang

harus dilakukan. 4GL sebagian besar bergantung pada komponen yang lebih tinggi dan hanya mendefinisikan

parameter pada alat untuk menghasilkan sebuah program aplikasi sehingga 4GLs di klaim dapat meningkatkan

produktivitas. Bahasa generasi keempat meliputi:

Bahasa Presentasi, seperti bahasa query dan laporan generator;

Bahasa khusus, seperti spreadsheet dan bahasa basis data;

Generator aplikasi yang mendefinisikan, insert, update, dan retrieve data dari basis data untuk membangun

aplikasi;

Bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi.

SQL dan QBE, yang disebutkan di atas, adalah contoh 4GLs. Beberapa tipe 4GL yang lain adalah:

1. Forms generators

2. Report generators

3. Graphic generators

4. Application generators

2.3 DATA MODEL DAN KONSEPTUAL MODELLING

Skema ditulis menggunakan DDL atau DDL dari DBMS itu sendiri, tetapi sayangnya, jenis tingkat bahasa terlalu

rendah untuk menjelaskan persyaratan sebuah data organisasi dengan cara yang mudah dimengerti oleh berbagai

pengguna. Apa yang kita butuhkan adalah deskripsi tingkat tinggi dari skema: yaitu, model data.

Data

Model

An integrated collection of concepts for describing and manipulating data,

relationships between data, and constraints on the data in an organization

Sebuah model adalah representasi objek dari dunia nyata dan peristiwa. Sebuah model data mewakili organisasi

sehingga desainer dan pengguna harus berada di titik satu pemahaman konsep dasar dan notasi tentang data

organisasi. Sebuah model terdiri dari tiga komponen:

1. Struktural (structural part), terdiri dari seperangkat aturan untuk membangun basis data;

2. Manipulatif (manipulative part), mendefinisikan jenis operasi yang diperbolehkan pada data (ini meliputi

operasi yang digunakan untuk memperbarui atau mengambil data dari basis data atau untuk mengubah

struktur basis data);

3. Integritas constraint (integrity constraints), untuk menjamin bahwa data yang ada sangat akurat.

Tujuan dari model data adalah untuk mewakili data dan membuat data mudah dimengerti dalam merancang basis

data. Dari arsitektur ANSI-SPARC, kita dapat mengidentifikasi tiga model data, yaitu terkait:

1. Model data eksternal, untuk mewakili pandangan masing-masing pengguna dalam organisasi (Universe of

Discourse (UOD));

2. Model data konseptual, untuk mewakili tampilan logis dari sebuah DBMS yang independen;

3. Model data internal, untuk mewakili skema konseptual yang dapat dipahami oleh DBMS.

2.3.1 OBJECT-BASED DATA MODEL

Model data berbasis objek menggunakan konsep seperti entitas, atribut, dan hubungan. Beberapa jenis yang umum

digunakan dalam permodelan data berbasis objek adalah: Entity–Relationship, Semantic, Functional, dan object-

Oriented.

ENTITY–RELATIONSHIP DATA MODEL

Model Entity-Relationship adalah model data konseptual tingkat tinggi untuk perancangan basis data. Model data

konseptual adalah himpunan konsep yang mendeskripsikan struktur basis data, transaksi pengambilan dan

pembaruan basis data. Model ER dikemukakan oleh Chen (1976).

SEMANTIC DATA MODEL

Model semantic duigunakan unntuk menjelaskan hubungan antar data dalam basis data kepada pemakai secara

logic. Sedangkan dasar pengembangan model semantic adalah persepsi terhadap dunia nyata bahwa data terdiri

dari objek-objek dasar yang mempunyai hubungan antara objek-onbjek dasar tersebut. Penggambaran model

semantic pada dasarnya dilakukan dengan menggunakan diagram atau simbol dan mekanisme SOM yang diusulkan

oleh Kroenke (2006).

FUNCTIONAL DATA MODEL

Menguraikan sistem ke desain entitas atau benda yang akan berinteraksi dan mengubah data untuk melakukan

tujuan sistem yang diperlukan. Menetapkan nama yang unik untuk setiap entitas desain, dan entitas kelompok

menurut jenis, misalnya, kelas, objek, prosedur..

OBJECT-ORIENTED DATA MODEL

Suatu model data logis yang secara semantic dari objek yang didukung oleh pemrograman berbasis objek.

2.3.2 RECORD-BASED DATA MODEL

Pada record-based data model, database terdiri dari sekumpulan records dengan format yang tetap, yang mungkin

dengan tipe yang berbeda-beda. Setiap record rnemiliki sejumlah fields (fixed) yang telah ditetapkan, dimana

rnasingmasing biasanya memiliki panjang yang telah ditetapkan juga. Ada tiga jenis utama dari model data logis

record-based: relational data model, network data model, dan hierarchical data model.

RELATIONAL DATA MODEL

Direpresentasikan sebagai sebuah tree graph, dengan record sebagai nodes atau disebut juga segments dan

himpunan sebagai edges Relational data model didasarkan pada konsep hubungan matematika. Pada relational

model ini, data dan relationship direpresentasikan dengan table, yang masing-masing memiliki sejumlah kolom

dengan narna yang unik. Relational data model memerlukan hanya bahwa database diterima user sebagai table.

Bagaimanapun persepsi ini hanya diterapkan pada logical structure dad database, yaitu pada external dan

conceptual level dad three-level architecture. Itu tidak diterapkan pada physical structure dad database, dimana

dapat diterapkan dengan berbagai macam struktur penyimpanan.

Gambar 2.4 – Contoh Relational Data Model

NETWORK DATA MODEL

Pada network, data direpresentasikan sebagai kumpulan records, dan relationship direpresentasikan oleh suatu

himpunan (sets). Dibandingkan dengan relational data model, relationship dimodelkan dengan lebih jelas melalui

himpunan yang menjadi pointer pada implementasinya. Record diatur sebagai struktur grafik biasa dengan records

sebagai nodes dan himpunan sebagai edges pada grafik.

Gambar 2.5 – Contoh Network Data Model

HIERARCHICAL DATA MODEL

Hierarchical merupakan jenis network model yang terbatas. Kembali data direpresentasikan sebagai records dan

relationship sebagai himpunan (sets). Hierarchical model mengijinkan sebuah node untuk memiliki hanya satu

parent. Sebuah hierarchical model dapat direpresentasikan sebagai sebuah three graph, dengan record sebagai

nodes atau disebut juga segments dan himpunan sebagai edges.

Gambar 2.6 – Contoh Hierarchical Data Model

2.3.3 PHYSICAL DATA MODELS

Physical data model mendeskripsikan bagaimana data disimpan dalam komputer, merepresentasikan informasi

seperti structure record, pengurutan record, dan access paths. Physical data model tidak sebanyak logical data

model, yang paling sering digunakan adalah unifying model dan frame memory.

2.3.4 CONCEPTUAL MODELING

Conceptual schema mendukung semua external views dan didukung oleh internal schema. Internal schema

hanyalah implementasi fisik dan conceptual schema. Conceptual schema seharusnya dapat secara lengkap dan

akurat merepresentasikan data yang dibutuhkan organisasi. Conceptual modeling atau conceptual database design

adalah proses pembuatan sebuah model dari informasi yang digunakan dalam organisasi terpisah dad detail

implementasi, seperti target DBMS, application program, programming languages, atau pertimbangan flsik lainnya.

Conceptual model juga menunjuk pada logical model.

2.4 FUNGSI DBMS

Bagian ini akan menguraikan berbagai jenis fungsi dan layanan yang dapat diberikan sebuah DBMS

Codd (1982) telah mengidentifikasikan terdapat sepuluh layanan DBMS sebagai berikut

Data Storage, Retrival Dan Update

Sebuah DBMS harus mempunyai kemampuan untuk rnenyimpan (store), mencari (retrieve), dan

memperbaharui (update) data di dalarn database. Ini merupakan fungsi dasar. Dalam menyediakan fungsi ini,

DBMS menyembunyikan detail mengenai implementasi fisik internal (file organization dan storage structures)

dari user.

A User Accessible Catalog

Sebuah DBMS harus menyediakan katalog dimana deskripsi dari data yang disimpan dan dapat diakses oleh

user. Kunci dari three-level architecture adalah mengidentifikasi suatu system catalog yang terintegrasi untuk

menyimpan data mengenai schemas, users, applications, dan lain-lain. Catalog diharapkan dapat diakses oleh

user sebaik diakses oleh DBMS. Sebuah system catalog, atau data dictionary, adalah sebuah tempat

penyimpanan dari deskripsi informasi yang terdapat di dalam database data mengenai data atau metadata.

Transaction Support

Sebuah DBMS harus memiliki sebuah mekanisrne yang akan memastikan bahwa semua pembaharuan (update)

yang berhubungan dengan transaksi yang diberikan terjadi atau tidak terjadi sama sekali. Sebuah transaksi

adalah sekumpulan aksi, dihasilkan oleh seorang user atau program aplikasi yang mengakses/merubah isi dari

database. Jika transaksi mengalami kegagalan pada saat pelaksanaan, yang mungkin terjadi karena komputer

crash, database akan menjadi tidak konsisten. Oleh karena itu perubahan yang telah dibuat akan dibatalkan

dan kembali pada keadaan database yang konsisten.

Concurrency Control Services

Sebuah DBMS harus memiliki sebuah mekanisme untuk memastikan bahwa update pada database dilakukan

secara benar ketika ada beberapa user melakukan update secara bersamaan.

Recovery Service

Sebuah DBMS harus memiliki sebuah mekanisme untuk pemulihan database pada saat database dalam

keadaan bahaya. Pada penjelasan mengenai “transaction support”, disebutkan bahwa jika transaksi gagal maka

database akan kembali pada keadaan konsisten semula. Hal ini dapat mengakibatkan DBMS berhenti, maka

harus ada mekanisme untuk memulihkan database pada keadaan yang konsisten.

Authorization Services

Sebuah DBMS harus menyediakan katalog dimana deskripsi dari data yang disimpan dan dapat diakses oleh

user. Kunci dari three-level architecture adalah mengidentifikasi suatu system catalog yang terintegrasi untuk

menyimpan data mengenai schemas, users, applications, dan lain-lain. Catalog diharapkan dapat diakses oleh

user sebaik diakses oleh DBMS. Sebuah system catalog, atau data dictionary, adalah sebuah tempat

penyimpanan dari deskripsi informasi yang terdapat di dalam database data mengenai data atau metadata.

Support For Data Communication

Sebuah DBMS harus dapat berintegrasi dengan communication software. Sebagian besar user mengakses

database malalui workstations yang terkadang terhubung secara langsung dengan komputer yang menjadi host

DBMS, terkadang berada pada jarak jauh dan workstations terhubung melalui sebuah jaringan. DBMS

rnenerima permintaan sebagai communication messages dan memberikan tanggapan degan cara yang sama.

Perlu bagi DBMS untuk dapat berintegrasi dengan berbagai macam komunikasi data.

Integrity Services

Sebuah DBMS harus memiliki sebuah mekanisme untuk memastikan baik data di dalam database dan

perubahan yang terjadi pada data mengikuti peraturan yang ada. Database integrity menunjuk pada kebenaran

dan konsistensi dan data yang disimpan. Ketika integrity berhubungan dengan security maka integrity

berkonsentrasi dengan kualitas data. Integrity biasa dikenal dengan istilah constrains, yang rnenjadi aturan

konsistensi yang tidak boleh dilanggar oleh database.

Services To Promote Data Independence

Sebuah DBMS harus memiliki sebuah mekanisme untuk mendukung kemandirian program-program dari

struktur aktual database. Data independence pada umumnya didapat dari view atau mekanisme subschema.

Pada beberapa sistem, beberapa tipe perubahan pada komponen yang telah ada pada logical structure tidak

diperbolehkan.

Utility Services

Utility program membantu DBA mengelola database secara efektif.beberapa utility bekerja pada eksternal

level, lainnya pada internal level dan dapat disediakan oleh DBMS vendor. Contoh utility:

o Fasilitas impor, memanggil data dari flat files, dan fasilitas ekspor untuk menutup data ke dalam flat files.

o Fasilitas monitoring, memonitor penggunaan database dan operasinya.

o Statistical analisis program, rnengevaluasi kinerja atau statistic penggunaan.

o Fasilitas index reorganization, mengatur ulang index dan kelebihannya (overflow)

o Garbage collection and reallocation, memindahkan record yang dihapus secara fisik dari tempat

penyimpanan, mengkonsolidasi kapasitas yang dilepaskan dan mengalokasikannya di tempat yang

memerlukannya.

2.5 KOMPONEN DBMS

Sebuah DBMS sangat komplek dan terdiri dari bagian-bagian piranti lunak yang amat rumit agar dapat menyediakan

berbagai layanan seperti telah dijelaskan dimuka. Adalah sangat tidak mungkin membuat batasan yang sangat

umum komponen dari DBMS ini karena hal ini sangat bergantung pada berbagai variasi system computer yang

digunakan. Agar memperoleh gambaran yang lengkap dibawah ini akan diuraikan suatu contoh komponen database

ORACLE.

Query processor

Merupakan komponen utama DBMS yang merubah query menjadi sekumpulan instruksi level rendah yang

ditujukan untuk database manager

Gambar 2.7 - Komponen DBMS

Database Manager

Menerima queries dan menguji skema eksternal dan konseptual untuk menentukan catatan konseptual apa

saja yang dibutuhkan.

Gambar 2.8 - Komponen Database Manager

File Manager

File manager memanipulaasi file penyimpanan utama dan mengatur lokasi penyimpanan dalam disk, juga

membuat dan memelihara daftar struktur dan index yang dijelaaskan dalam skema internal.

DML Processor

Modul ini mengubah pernyataan DML yang tersimpan dalam program aplikasi, menjadi fungsi panggilan

standar dalam host language. Preprocessor DML harus berinteraksi dengan query processor untuk

menghasilkaan kode yang tepat.

DDL Compiler

Mengubah pernyataan DDL menjadi sekumpulan tabel yang berisi meta-data. Taqbel ini kemudian disimpan

di dalarn sistem katalog ketika informasi kontrol disimpan didalam data file header.

Catalog Manager

Memelihara dan mengatur akses ke sistem katalog

Sedangkan beberapa komponen piranti lunak database manager adalah sebagai berikut :

Authorized control

Command processor

Integrity checker

Query optimizer

Transaction manager

Scheduler

Recovery manager

Buffer manager

2.6 ARSITEKTUR DBMS MULTI-USER

Beberapa arsitektur secara umum yang dipakai untuk implementasi database pada sebuah jaringan multi-user.

2.6.1 TELEPROCESSING

Arsitektur tradisional untuk sistem multy-user adalah

teleprocessing, dimana ada 1 komputer dengan single

CPU dan beberapa terminal. Namun beberapa tahun

terakhir mi, ada peningkatan dalam perkembangan dari

performance komputer dan jaringan, yaitu trend yang

mengarah pada downsizing, yaitu menggantikan

computer mainframe yang mahal dengan computer

jaringan yang lebih murah namun dapat mencapai hasil

yang sama atau babkan lebih baik. Trend in

memunculkan 2 arsitektur lain : file-server dan client-

server

Gambar 2.9 - Arsitektur Teleprocessing

2.6.2 FILE-SERVER ARCHITECTURE

Gambar 2.10 – Arsitektur File-Server

File-server memiliki file-file yang diperlukan oleh aplikasi dan DBMS.

File server bertindak hanya sebagai .shared hard disk drive. DBMS

di masing-msing workstation mengirimkan permintaan ke file-

server untuk semua data yang diperlukan DBMS yang disimpan

dalam disk.

Keuntungan Kerugian

Ada aliran jaringan yang besar

Diperlukan seluruh salinan DBMS untuk setiap workstation

Control terhadap concurrency, recovery dan integritas lebih sulit karena banyak user yang mengakses file yang sama.

Client-server menunjuk pada suatu cara dimana suatu komponen software berinteraksi untuk membuat suatu sistem.

Memungkinkan akses yang lebih luas ke database

Meningkatkan penampilan

Mengurangi biaya hardware

Mengurangi biaya komunikasi

Meningkatkan konsistensi

Fungsi Client: Fungsi Server:

Mengatur tampilan user

Menerima dan mengecek sintak yang dimasukkan oleh user

Memproses logika aplikasi

Meningkatkan permintaan database dan dikirimkan ke server

Memberikan respon ke user

Menerima dan memproses permintaan database dari client

Memeriksa autorisasi

Memastikaan bahwa batasan integritas yang ada tidak dilanggar

Menampilkaan query/melakukan proses update dan mengirimkan respon ke klien

Memeliharaa sistem katalog

Menyediakan akses database yang dapat dilakukan bersama-sama

2.6.3 TRADITIONAL TWO-TIER CLIENT–SERVER ARCHITECTURE

Untuk mengatasi kekurangan dari dua pendekatan sebelum dan mengakomodasi lingkungan bisnis yang semakin

terdesentralisasi, arsitektur client-server dikembangkan. Client-server mengacu pada cara di mana komponen

software berinteraksi membentuk sebuah sistem. Client membutuhkan sumber daya, dan server, yang menyediakan

sumber daya. Tidak ada persyaratan bahwa client dan server harus berada pada mesin yang sama. Dalam

prakteknya, sangat umum untuk menempatkan server di salah satu situs dalam LAN dan clien di situs lain.

Gambar 2.11 – Traditional Two Tier Client-Server Architecture

Aplikasi bisnis terdiri dari empat komponen utama: database, logika transaksi, logika aplikasi bisnis dan data, dan

user interface. Arsitektur client-server tradisional dua lapis memberikan pemisahan yang sangat dasar komponen

ini. Client (tier 1) bertanggung jawab untuk penyajian data ke pengguna, dan server (tier 2) bertanggung jawab untuk

memasok layanan data ke client, seperti digambarkan pada Gambar 2.11.

2.6.4 THREE-TIER CLIENT–SERVER ARCHITECTURE

Pada tahun 1995, variasi baru dari model client-server tradisional dua tingkat muncul untuk memecahkan masalah

skalabilitas perusahaan. Arsitektur baru yang diusulkan yaitu tiga lapisan, masing-masing berjalan pada platform

yang berbeda :

1. Lapisan antarmuka pengguna , yang berjalan pada komputer pengguna akhir ( client ).

2. Logika bisnis dan lapisan pengolahan data. Lapisan tingkat menengah ini berjalan pada server dan sering

disebut server aplikasi .

3. Sebuah DBMS , yang menyimpan data yang dibutuhkan oleh tingkat menengah . Tingkat ini dapat berjalan

pada server terpisah yang disebut database server.

Gambar 2.12 - Three-Tier Architecture

Seperti diilustrasikan dalam Gambar 2.12 client sekarang bertanggung jawab hanya untuk pengguna aplikasi

antarmuka dan mungkin melakukan beberapa pengolahan logika sederhana, seperti validasi input, sehingga

memberikan client lebih mudah. Inti logika bisnis dari aplikasi berada pada lapisan tersendiri, secara fisik terhubung

ke client dan database server melalui jaringan area lokal (LAN) atau wide area network ( WAN ) . Salah satu aplikasi

server dirancang untuk melayani beberapa client.

2.6.5 TRANSACTION PROCESSING MONITOR

TP

Monitor

A program that controls data transfer between clients and servers in order to

provide a consistent environment, particularly for online transaction

processing (OLTP).

Gambar 2.13 – Proses Transaction Processing Monitor

Aplikasi yang kompleks sering dibangun di atas beberapa Resource Managers (seperti DBMS, Sistem Operasi,

antarmuka pengguna, dan messaging). Sebuah Transaction Processing Monitor, atau TP Monitor, adalah komponen

middleware yang menyediakan akses layanan dari sejumlah Resource Managers dan menyediakan antarmuka yang

seragam untuk programmer dalam mengembangkan perangkat lunak transaksional. A TP monitor membentuk

tingkat menengah dari arsitektur three-tier, seperti digambarkan pada Gambar 2.13. TP Monitor memberikan

keuntungan yang signifikan, termasuk:

Transaction routing

Managing distributed transactions

Load balancing

Funneling

Increased reliability