CREATE TABLE chicken (cID INT PRIMARY KEY,
                      eID INT REFERENCES egg(eID));
CREATE TABLE egg(eID INT PRIMARY KEY,
                 cID INT REFERENCES chicken(cID));

Nah, tabel chicken ternyata memiliki foreign key eID yang merupakan primary key dari tabel egg, begitu juga tabel egg memiliki foreign key cID yang merupakan primary key dari tabel chicken. Dengan struktur yang seperti ini, bagaimana kita bisa menginput data chicken sebelum menginput data egg, atau sebaliknya, menginput data egg sebelum menginput data chicken? Dengan kata lain, data mana yang seharusnya kita input terlebih dahulu, chicken atau egg?
Untuk memecahkan masalah ini, kita perlu melakukan modifikasi struktur.

CREATE TABLE chicken(cID INT PRIMARY KEY,
                     eID INT);
CREATE TABLE egg(eID INT PRIMARY KEY,
                 cID INT);

Dalam struktur tabel di atas kita belum memasukkan foreign key. Berikut struktur foreign key nya

ALTER TABLE chicken ADD CONSTRAINT chickenREFegg
    FOREIGN KEY (eID) REFERENCES egg(eID)
    INITIALLY DEFERRED DEFERRABLE;
ALTER TABLE egg ADD CONSTRAINT eggREFchicken
    FOREIGN KEY (cID) REFERENCES chicken(cID)
    INITIALLY DEFERRED DEFERRABLE;

Perhatikan bahwa kita menambahkan baris perintah INITIALLY DEFERRED DEFERRABLE. Kita dapat memecahnya menjadi 2.
INITIALLY DEFERRED. Perintah ini mengoverload nilai default INITIALLY IMMEDIATE dari setiap tabel yang dibuat. INITIALLY IMMEDIATE artinya sistem akan mengevaluasi nilai segera setelah nilai tersebut diinsert. Tetapi INTIALLY DEFERRED akan menunda evaluasi nilai dalam rangka referential integrity (implementasi constraint) hingga perintah COMMIT dijalankan.
DEFERRABLE. Perintah ini akan membuat constraint tersebut dapat di-DEFERRED, yang mengoverload nilai default NOT DEFERRABLE dari setiap tabel yang dibuat.

Opsi lain, Anda bisa mengeset constraint menjadi INITIALLY IMMEDIATE DEFERRABLE, dan pada saat dibutuhkan Anda bisa mengeset session Anda menjadi DEFERRED untuk kemudian mengembalikannya kembali jadi IMMEDIATE saat mode DEFERRED sudah tidak diperlukan, dengan contoh seperti berikut (sumber). Misalkan kita memiliki 2 tabel.

CREATE TABLE tab1 (id  NUMBER(10), tab2_id NUMBER(10));
CREATE TABLE tab2 (id  NUMBER(10));

Kita modifikasi tabel untuk menambahkan constraint.

ALTER TABLE tab2 ADD PRIMARY KEY (id);

ALTER TABLE tab1 ADD CONSTRAINT fk_tab1_tab2
  FOREIGN KEY (tab2_id)
  REFERENCES tab2 (id)
  DEFERRABLE
  INITIALLY IMMEDIATE;

Anda dapat mengubah SESSION Anda agar bisa memodifikasi isi tabel dengan mode DEFERRED.

ALTER SESSION SET CONSTRAINTS = DEFERRED;

Kemudian Anda bisa mengembalikan kembali ke mode IMMEDIATE.

ALTER SESSION SET CONSTRAINTS = IMMEDIATE;

Yang akan saya bahas di sini menggunakan IDE Delphi dan database Firebird, dan koneksi menggunakan komponen Interbase bawaan Delphi.

Kita akan sedikit membahas teori tentang tipe koneksi. Pada dasarnya ada 2 tipe koneksi, yaitu connection-oriented dan connectionless. Connection-oriented artinya koneksi (dengan server) akan tetap dipertahankan selama program berjalan, sedangkan connectionless artinya koneksi antara program dengan server hanya akan dibuat ketika program membutuhkan data.

Contoh aplikasi connection-oriented adalah ketika Anda login, Anda akan menjalankan perintah ini:
IBDatabase1.Connected := true;
dan koneksi ini akan diputus ketika seorang pengguna logout atau menutup aplikasi.
Nah, masalahnya, ketika terjadi connection lost, maka ada beberapa perintah yang akan mengeluarkan error ketika dieksekusi, oleh karena itu, kita harus memberinya exception dan menjalankan perintah yang tetap bisa dijalankan sekalipun koneksi jaringan terputus.
Anda dapat membaca artikel dari mc-computing yang membahas tentang bagaimana menangani connection lost.
Beberapa baris perintah yang error adalah:

- IBDatabase1.Connected := false;
Anda dapat menambahkan baris perintah IBDatabase1.ForceClose; yang tetap berjalan meski koneksi terputus.
contoh :
try
IBDatabase1.Connected := false;
IBDatabase1.ForceClose;
except
end;
Jangan lupa juga memeriksa apakah transaksi sedang InTransaction atau tidak, dan me-rollback atau commit.
if IBTransaction1.InTransaction then
begin
IBTransaction1.Rollback;
IBTransaction1.Active := False;
end;

-IBQuery1.Open;
Perhatikan, dataset akan selalu menimbulkan exception “Invalid transaction handle” ketika dia diberi perintah open, apabila ketika terjadi connection lost dataset tersebut sedang dalam keadaan open dan belum ditutup. Oleh karena itu, mungkin Anda harus sedikit “membersihkan” kode-kode Anda dengan menambahkan baris perintah:
IBQuery1.Close;
IBQuery1.Active := false;
di setiap akhir query yang Anda lakukan. Tentu saja saya tidak bisa menjelaskan di mana saja baris perintah ini harus diletakkan, karena tergantung pada algoritma dan alur program yang Anda pakai.
Penggunaan tambahan 2 baris di atas juga dapat menghilangkan munculnya exception “Dataset open” ketika sebuah form ditutup atau dibuka yang mana dalam form tersebut terdapat dataset yang masih terbuka.

Cara pertama adalah dengan mengubah password standar SYSDBA. Namun mungkin akan menjadi masalah apabila file database kita dikopi ke mesin lain dengan server Firebird yang masih standar, yang tentunya juga masih memiliki password standar. User akan dengan mudah membuka file database kita dengan akun SYSDBA.

Cara kedua, dengan menterjemahkan artikel dari eksa ke dalam program. Namun setelah kucoba, file security2.fdb tidak lagi dapat dibuka dengan akun super administrator, sehingga cara ini mungkin sudah kadaluarsa dengan sistem Firebird di atas versi 1.5.

Cara ketiga, Anda bisa membuat database baru dengan user baru yang Anda buat sendiri. Kemudian Anda bisa memompa data dari database lama ke database baru. Namun masalahnya, apabila Anda sudah terlanjur menciptakan database dengan SYSDBA dan proses development sudah terlampau jauh dengan berbagai rules telah terpasang dalam database Anda, memompa data ke database baru bukan suatu pekerjaan mudah. Anda harus memastikan seluruh data berpindah dengan sempurna.

Cara keempat, Anda bisa menggunakan FBOwnerMigrator yang dibuat oleh Thomas Steinmaurer. Program utility ini bisa Anda dapatkan dengan menghubungi Thomas Steinmaurer (alamat email ada di tautan). Program ini akan memigrasi ownership database Anda dari SYSDBA ke user baru yang telah Anda create sebelumnya, sehingga pada akhirnya database Anda akan terlindungi dari akses SYSDBA.
(Thanks to Mr. Steinmaurer for his great job)

Dalam proses pembuatan aplikasi, Anda juga harus memperhatikan infrastruktur yang akan menunjang aplikasi Anda. Anda tidak dapat membuat kueri yang memakan waktu dan sumber daya terlalu banyak dalam jaringan yang lambat. Anda dituntut untuk menggunakan koneksi seefisien mungkin supaya jalur data tidak mengganggu proses bisnis organisasi yang Anda layani. Anda mungkin harus bekerja ekstra dalam membuat stored procedure dan trigger yang diletakkan dalam server sehingga mengurangi beban jaringan.

Ketika Anda harus berhadapan dengan kebijakan organisasi tentang hak akses data, Anda juga dituntut memodifikasi skrip (dan bila perlu hak akses basis data) untuk mendukung kebijakan ini, sehingga proses pembuatan aplikasi akan memakan waktu lebih lama. Dalam prosesnya, Anda tidak boleh melupakan Proof of Concept (POC) untuk mencoba apakah teknik-teknik yang akan Anda pakai dapat diterapkan dalam organisasi Anda. POC ini biasanya dilakukan di awal masa pengembangan sehingga proses development dan hasil akhir tidak menjadi sia-sia dan dapat diterapkan dalam organisasi Anda.

Perlu diingat bahwa proses implementasi sistem baru adalah salah satu tahapan yang paling sulit, karena kita dihadapkan pada orang-orang yang memiliki karakteristik yang berbeda. Lain halnya ketika kita berhadapan dengan mesin yang dapat dengan mudah dikendalikan, kita tidak dapat mengubah pola kerja dan pola pikir seseorang untuk menyesuaikan dengan sistem baru yang kita luncurkan.

Terkadang dalam stored procedure kita harus mencari tanggal beberapa tahun ke depan, atau mencari selisih bulan antara 2 tanggal. Walaupun terlihat sepele, pekerjaan tersebut sulit dilakukan. Tetapi menggunakan library tambahan FreeUDFLib, aritmatika tanggal jadi sangat mudah.

Nah, apa yang terjadi jika basis data dengan data yang saling merujuk tersebut tidak menggunakan integritas referensial? Semisal kita memiliki tabel barang (tbarang), tabel penjualan (tpenjualan), dan tabel penjualan detail (tpenjualan_detail)
tbarang:
kd_barang *
nama_barang
merek

tpenjualan:
no_nota *
tgl_nota

tpenjualan_detail
no_nota *
kd_barang *
qty

Ket : *) primary key

Dari tabel dan entitasnya di atas, perhatikan tabel tpenjualan_detail yang merujuk data ke tabel tbarang melalui field kd_barang. Kedua tabel ini akan terhubung dengan relasi tbarang one-to-many tpenjualan_detail.
Jika tanpa integritas referensial, maka jika sebuah record dari tbarang yang menjadi rujukan dalam tpenjualan_detail dihapus, maka record dalam tpenjualan_detail tersebut akan menjadi orphan data, artinya data yang rujukannya sudah tidak eksis lagi. Dan dalam sistem basis data, data seperti ini sangat dihindari karena dampaknya akan sangat merugikan atau bahkan datanya tidak bisa digunakan lagi.

Barangkali ada yang mempunyai ide untuk menangkal orphan data ini di level aplikasi. Bisa, tetapi terbatas pada struktur basis data yang kompleks. Bayangkan bila tbarang di atas dirujuk oleh banyak sekali tabel, maka jika akan menghapus record harus melakukan pengecekan satu persatu. Berbeda kasusnya bila kita menggunakan fasilitas dalam integritas referensial yang mampu secara otomatis menghasilkan error ketika record yang menjadi rujukan berusaha dihapus.

Pembahasan singkat di atas mungkin bisa menjadi referensi bagus untuk mempertimbangkan penggunaan DBMS yang sudah menggunakan integritas referensial secara intensif. Contoh di antaranya adalah Microsoft Access dan Firebird.

Query
• Melihat isi tabel
Sintaks:
SELECT * FROM nama_tabel;
Tanda asterisk (*) menunjukkan semua kolom dalam tabel.
Contoh:
SELECT * FROM infoprib;

• Menampilkan kolom tertentu
Sintaks:
SELECT nama_kolom1, nama_kolom2, …
FROM nama_tabel;
Contoh:
SELECT nama, tgl_lahir
FROM infoprib;

• Memperoleh data yang unik
Menggunakan klausa DISTINCT setelah klausa SELECT
Contoh:
SELECT DISTINCT sex
FROM infoprib;

• Memilih baris tertentu
Menggunakan klausa WHERE untuk menentukan kondisi data yang boleh ditampilkan.
Sintaks:
SELECT nama_kolom1, nama_kolom2,…
FROM nama_tabel
WHERE [kondisi];
Contoh:
SELECT nama
FROM infoprib
WHERE sex = ‘W’;

• Menggunakan operator Relasional
Kondisi menggunakan operator relasional.
Operator Arti
= Sama dengan
> Lebih dari
< Kurang dari
>= Lebih dari atau sama dengan
<= Kurang dari atau sama dengan
<> Tidak sama dengan
Contoh:
SELECT nama_peg, gaji
FROM pegawai
WHERE gaji > 2000000;

• Menggunakan operator Boolean
? Operator OR, sifatnya benar bila salah satu benar
Contoh:
SELECT *
FROM infoprib
WHERE sex = ‘P’ OR id_bin = ‘STONE’;
? Operator AND, sifatnya benar bila keduanya benar
Contoh:
SELECT nama, tgl_lahir
FROM infoprib
WHERE sex = ‘P’ AND tgl_lahir < ‘1950-01-01’;
? Operator NOT, digunakan untuk pembalikan nilai nalar
Contoh:
SELECT nama
FROM infoprib
WHERE NOT sex = ‘P’;

• Menggunakan operator BETWEEN dan NOT BETWEEN
Operator BETWEEN digunakan untuk membuat suatu kondisi di mana data berada di antara batas-batas nilai yang ditentukan, sedang NOT BETWEEN memiliki sifat kebalikan dengan BETWEEN, yaitu kondisi data tidak berada di antara batas-batas nilai yang ditentukan.
Contoh:
SELECT nama, tgl_lahir
FROM infoprib
WHERE tgl_lahir BETWEEN ‘1960-01-01’ AND ‘1970-12-31’;
SELECT nama
FROM infoprib
WHERE nama NOT BETWEEN ‘C’ AND ‘J’;

• Menggunakan operator LIKE dan NOT LIKE
Hal-hal yang harus diperhatikan:
- tanda garis bawah ( _ ) berarti sebuah karakter apa saja
- tanda persen (%) berarti cocok dengan karakter apa saja dan berapapun panjangnya (termasuk cocok dengan nol karakter)
Contoh:
SELECT nama
FROM infoprib
WHERE nama LIKE ‘%on%’;
SELECT nama
FROM infoprib
WHERE nama NOT LIKE ‘S%’;

• Menggunakan operator IS NULL dan IS NOT NULL
Operator IS NULL digunakan untuk mencari nilai yang kosong dalam suatu kolom, sedangkan IS NOT NULL digunakan untuk mencari nilai yang tidak kosong.
Contoh:
SELECT *
FROM infoprib
WHERE tgl_lahir IS NULL;
SELECT *
FROM infoprib
WHERE tgl_lahir IS NOT NULL;

• Mengurutkan data dengan ORDER BY
Contoh:
SELECT *
FROM infoprib
ORDER BY nama;

• Mengurutkan secara descending
Contoh:
SELECT *
FROM infoprib
ORDER BY nama DESC;

• Mengurutkan beberapa kolom
Contoh:
SELECT sex, nama
FROM infoprib
ORDER BY sex, nama;

• Mengelompokkan data dengan GROUP BY
Contoh:
SELECT sex
FROM infoprib
GROUP BY sex;

• Menggunakan klausa HAVING
Klausa HAVING digunakan untuk menentukan kondisi bagi GROUP BY. Kelompok yang memenuhi HAVING saja yang akan dihasilkan.
Contoh:
SELECT kota
FROM pegawai
GROUP BY kota
HAVING kota <> ‘Yogya’;

• Menggunakan fungsi Agregat
Beberapa fungsi Agregat:
? Fungsi AVG, untuk memperoleh rata-rata
Contoh:
SELECT AVG(gaji)
FROM pegawai;
? Fungsi COUNT, untuk melakukan pencacahan terhadap data
Contoh:
SELECT COUNT(nama_peg)
FROM pegawai;
? Fungsi MAX, untuk memperoleh nilai yang terbesar
Contoh:
SELECT MAX(gaji)
FROM pegawai;
? Fungsi MIN, untuk memperoleh nilai yang terkecil
Contoh:
SELECT MIN(gaji)
FROM pegawai;
? Fungsi SUM, untuk melakukan penjumlahan data
Contoh:
SELECT SUM(gaji)
FROM pegawai;

Mengupdate Data
Updating data dilakukan karena adanya data yang berubah nilainya.
Sintaks:
UPDATE nama_tabel
SET nama_kolom = [nilai baru]
WHERE [kondisi]
Contoh:
UPDATE tMahasiswa
SET kota = ‘Yogyakarta’
WHERE kota = ‘Yogya’;

Menghapus Data
Digunakan untuk menghapus data.
Sintaks:
DELETE FROM nama_tabel
WHERE [kondisi];
Contoh:
DELETE FROM tMahasiswa
WHERE nama = ‘Yovie’;

Derajat Partisipasi Hubungan
Hubungan antarentiti akan menyangkut dua komponen yang menyatakan jalinan ikatan yang terjadi, yaitu derajat dan partisipasi hubungan. Derajat hubungan menyatakan jumlah anggota entiti yang terlibat di dalam ikatan yang terjadi. Dalam hal ini ikatan yang terjadi akan membentuk instan hubungan (relationship instances, relationship occurences). Sedangkan partisipasi hubungan menyatakan sifat keterlibatan tiap anggota entiti dalam ikatan terjadinya hubungan.

Tabel normal
model konsepsual dalam penyusunan basis data tidak hanya terdiri atas satu tabel, melainkan banyak tabel dalam satu kesatuan pandangan data. Kelompok tabel yang memenuhi ketentua tabel normal disebut tabel normal penuh (fully normalised tables).

Data Rangkap dan Data Duplikasi
Salah satu keuntungan menggunakan pendekatan basis data adalah konsistensi data selalu terjaga. Hal ini dapat tercapai kalau data yang disimpan dalam basis data terhindar dari adanya data rangkap (redundant data). Sebelum melangkah pada pembicaraan lebih lanjut kiranya perlu dibedakan antara data duplikasi (duplicated data) dan data rangkap.
Data duplikasi terjadi apabila satu atribut mempunyai dua atau lebih nilai yang sama. Sedangkan nilai data dikatakan data rangkap adalah dalam satu atribut mempunyai dua atau lebih nilai yang sama, tetapi apabila salah satu nilai dihapus, maka tidak ada informasi yang hilang. Atau dengan kata lain, data rangkap merupakan data duplikasi yang tidak perlu terjadi.

Aturan Data
Terjadinya data rangkap hanya diamati dari nilai data yang ada pada setiap instan tabel. Oleh karena data dalam basis data itu bersifat dinamis atau setiap saat dapat terjadi penambahan, penghapusan, atau revisi data, maka hanya dengan cara pengamatan data saja tidak akan memberikan hasil yang akurat pada proses model konsepsual. Salah satu cara pendekatan analisis data agar data dalam basis data memenuhi aturan penyusunan tabel adalah dengan membuat aturan data dalam basis data (enterprise rules).

Proses Normalisasi Tabel
Basis data tidak hanya terdiri atas satu tabel saja, melainkan banyak tabel. Gabungan tabel-tabel dalam basis data disusun sesuai ketentuan penyusunan tabel (tabel normal) dan antartabel saling berhubungan serta terbebas dari adanya data rangkap. Kondisi tabel demikian dikatakan sebagai tabel normal penuh.
Proses pembentukan tabel normal penuh (normalisasi) bertujuan untuk:
• Membuat sekecil mungkin terjadinya data rangkap
• Menghindarkan adanya data yang tidak konsisten terutama bila dilakukan penghapusan atau penambahan data sebagai akibat adanya data rangkap
• Menjamin bahwa identitas tabel secara tunggal sebagai determinan semua atribut.

Bentuk-bentuk tabel normal
Proses normalisasi tabel secara umum dibagi menjadi lima tahap, sehingga dikenal bentuk-bentuk tabel normal sesuai dengan tahapan normalisasi yang telah dilakukan, yaitu bentuk normal pertama, kedua, ketiga, keempat, dan kelima.
Bentuk normal pertama dicapai bila tiap nilai atribut adalah tunggal. Kondisi ini dapat diperoleh dengan melakukan eliminasi terjadinya data ganda (repeating groups). Pada kondisi normal pertama ini kemungkinan masih terjadi adanya data rangkap.
Bentuk normal kedua dicapai bila atribut yang dijadikan identitas benar-benar sebagai determinan dari semua atribut. Bentuk normal kedua diperoleh dengan bantuan diagram determinansi atau manipulasi data tabel pada kondisi bentuk normal pertama
Bentuk normal ketiga adalah bentuk normal kedua tanpa terjadi adanya ketergantungan transitif (transitif determinan). Kondisi ini sama dengan tabel normal Boyce/Codd, namun masih diperlukan pemilihan identitas tunggal bila terdapat beberapa kandidat untuk dijadikan identitas.
Bentuk normal keempat adalah tabel bentuk normal ketiga dengan nilai atribut tidak tergantung pada banyak nilai (multi-value determiancies). Sedangkan bentuk normal kelima berhubungan dengan apa yang disebut ketergantungan pada gabungan beberapa atribut (join dependency). Kasus ini dalam praktek jarang ditemukan, sebab secara nyata akan disusun suatu tabel dengan atribut-atribut yang ditentukan dengan satu identitas.

Incoming search terms for the article:

• tentang tabel (12)
• pengertian tabel (10)
• contoh database (1)

Skema dan Instan Basis Data
Skema basis data merupakan deskripsi dari basis data yang spesifikasinya ditentukan dalam tahap perancangan. Skema basis data tidak diharapkan dapat diubah setiap saat walaupun dimungkinkan untuk diadakan perubahan. Penggambaran skema biasanya ditampilkan dalam diagram skema yang berisi sebagian dari detail deskripsi basis data.
Data dalam basis data setiap saat aka berubah karena terjadi penambahan, penghapusan, atau pembaharuan data. Sekelompok data yang tersusun dalam satu baris (tuple) dan tersimpan dalam basis data disebut instan (instances) atau kejadian (occurences). Setiap susunan skema basis data mempunyai satu set instan-instan sesaat.

Arsitektur SMBD
Arsitektur SMBD dikenal dengan sebutan asitektur tiga skema (three-schema architecture). Fungsi skema ini adalah untuk memisahkan anatar fisik basis data dan program aplikasi pemakai. Skema dalam arsitektur tersebut adalah:
• Level internal merupakan skema internal yang memuat deskripsi struktur penyimpanan basis data. Skema internal menggunakan model data fisikal dan mendefinisikan secara detail penyimpanan data dalam basis data, serta jalur pengaksesan data.
• Level konsepsual merupakan skema konsepsual yang memuat deskripsi struktur basis data secara keseluruhan untuk semua pemakai. Skema konsepsual hanya memuat deskripsi tentang entiti, atribut, hubungan, dan konstrain, tanpa memuat deskripsi data secara detail. Model data tingkat tinggi atau model data implementasi dapat digunakan dalam skema ini.
• Level eksternal merpakan skema eksternal (user views) yang mendefinisikan pandangan data terhadap sekelompok pemakai (local view) dengan menyembunyikan data lain yang tidak diperlukan oleh kelompok pemakai tersebut. Model data tingkat tinggi atau model data implementasi dapat digunakan dalam skema eksternal.

Komponen SMBD
Dalam praktek jarang sekali dijumpai SMBD yang secara tegas membedakan antarskema pada arsitektur tiga-skema. Namun demikian dari skema dapat dilakukan indikasi adanya komponen SMBD:
• Bahasa untuk jendela perantara, yang di dalamnya termasuk Bahasa Manipulasi Data (Data Manipulation Language) yang disingkat BMD.
• Bahasa Definisi Data (Data Definition Language) yang disingkat BDD untuk skema eksternal, skema konsepsual, dan skema internal.
• Sistem Kontrol Basis Data (SKBD) yang akan mengakses basis data karena adanya perintah dari BMD.
Pada perkembangan terakhir kebanyakan SMBD tidak memisahkan antara bahasa untuk jendela perantara, BDD dan BMD. Structured Query Language (SQL) merupakan contoh bahasa standar yang digunakan SMBD relasional untuk pengelolaan basis data.

Klasifikasi SMBD
Sistem Manajemen Basis Data terutama diklasifikasikan berdasarkan model data yang digunakan yaitu model data hierarki, jaringan, relasional, orientasi obyek, dan model data yang lain.
Klasifikasi kedua didasarkan pada lokasi penyimpanan data, yaitu SMBD terpusat (centralized database) dan SMBD terdistribusi (distributed database). Dalam SMBD terpusat basis data disimpan dalam satu komputer media penyimpanan sehingga pemakai sistem mengakses data dari satu tempat. Sedangkan dalam SMBD terdistribusi, basis data disimpan tidak dalam satu komputer melainkan tersebar pada penyimpanan tiap terminal pemakai. Antarpemakai dapat mengakses data secara langsung tidak perlu melalui pusat penyimpanan. SMBD terdistribusi memerlukan sistem kontrol yang lebih rumit daripada sistem basis data tersentralisasi.

Model data hierarki
Dalam model data hierarki, data disusun menurut struktur pohon. Pada puncak dari hierarki disebut dengan istilah akar (root). Dalam rekaman akar hanya terdapat satu rekaman yang terdiri atas satu medan atau lebih. Di samping itu dalam model data hierarki tiap entiti pada tingkat atas (dikenal dengan istilah induk atau parent) mempunyai satu atau lebih sub-entiti (anak atau children). Tiap entiti hanya boleh mempunyai satu induk, tetapi dapat mempunyai banyak anak.

Model data jaringan
Dalam model jaringan (network), tiap entiti dapat mempunyai banyak induk atau banyak anak. Hal ini lebih fleksibel daripada model hierarki. Dalam model jaringan lebih sedikit terdapat data yang rangkap daripada model hierarki. Namun demikian lebih banyak terdapat hubungan antarentiti, sehingga akan menambah informasi hubungan yang harus disimpan dalam basis data. Hal ini akan menambah volume dan kerumitan dalam penyimpanan berkas data. Dalam basis data yang kompleks, informasi hubungan antarentiti dapat mencapai jumlah besar dan akan banyak memerlukan waktu jika terjadi perubahan hubungan yang dikehendaki.

Model data relasional
Dalam model data relasional tidak terdapat hierarki atau jenjang dalam medan rekaman data, dan setiap medan data dapat dijadikan kunci data. Dengan menggunakan model ini, pencarian medan atribut dari suatu tabel atau banyak tabel dapat dilakukan dengan cepat. Pencarian atribut yang berhubungan di mana tersimpan pada tabel yang berbeda dapat dilakukan dengan menghubungkan terlebih dahulu tabel-tabel tersebut dengan menggunakan atribut yang sama. Prosedur ini dikenal dengan operasi gabungan (joint operation).