Desain Database Pertemuan Minggu Ke-2

Kompetensi Khusus Mahasiswa mampu menjelaskan DBLC, aktivitas paralel antara SDLC dan DBLC, dan strategi desain database (C2)

Sistem Informasi Database merupakan bagian dari sistem informasi, yang digunakan untuk pengumpulan, penyimpanan, dan pengambilan data. Sistem informasi membantu merubah data menjadi informasi, serta mengatur data dan informasi. Kinerja dari sistem informasi bergantung pada: Desain & implementasi database Desain & implementasi aplikasi Prosedur administratif

Pengembangan Database Tujuan utama dalam desain database adalah untuk membuat model database yang lengkap, normal (tidak redundan), dan terintegrasi penuh antara konseptual, logis, dan fisik. Tahap implementasi mencakup pembuatan struktur penyimpanan database, memasukkan data ke dalam database, dan manajemen data.

SDLC

DBLC

Studi Awal Database Bertujuan untuk: Menganalisa situasi perusahaan Mendefinisikan masalah Mendefinisikan tujuan Mendefinisikan ruang lingkup & batasan

Menganalisa situasi perusahaan Situasi perusahaan mendeskripsikan kondisi umum dimana perusahaan beroperasi, struktur organisasi, & misi. Desainer database harus mempelajari komponen operasional perusahaan, fungsionalitas & interaksinya. Beberapa masalah yang harus diatasi: Desain harus memenuhi kebutuhan operasional yang dibuat dari misi perusahaan. Mendefinisikan aliran informasi, laporan, format query, dsb dengan mengetahui siapa pemegang kekuasaan & struktur pelaporannya.

Mendefinisikan masalah End user perusahaan biasanya tidak dapat mendeskripsikan secara tepat operasi perusahaan secara keseluruhan atau mengidentifikasi masalah sebenarnya yang muncul selama operasi perusahaan. Biasanya pandangan manajerial terhadap operasi perusahaan & masalahnya berbeda dari end user yang melakukan pekerjaan rutin. Selama proses ini, desainer mengumpulkan deskripsi masalah yang sangat luas, yang diikuti oleh masukan dari end user. Desainer database selanjutnya melakukan penyelidikan untuk memperoleh informasi tambahan yang dapat mendefinisikan masalah dalam kerangka yang lebih besar dari operasional perusahaan. Penting untuk menemukan jawaban yang tepat, khususnya yang berkaitan dengan hubungan operasional antar unit bisnis. Jika sistem yang diusulkan dapat menyelesaikan masalah suatu divisi tetapi memperburuk masalah di divisi lain, maka tidak banyak kemajuan yang dibuat.

Mendefinisikan tujuan Sistem database yang diajukan harus dirancang untuk menyelesaikan paling tidak masalah utama yang teridentifikasi selama proses penemuan masalah. Desainer harus memastikan tujuan databasenya sesuai dengan yang dibayangkan oleh end user. Berikut beberapa pertanyaan yang harus diajukan: Apa tujuan awal dari sistem yang diusulkan? Apakah sistem perlu memiliki antarmuka dengan sistem lain yang sudah ada atau mendatang dalam perusahaan? Apakah sistem akan berbagi data dengan sistem atau user lain?

Menentukan ruang lingkup & batasan Ruang lingkup sistem menentukan sejauh mana desain sesuai dengan kebutuhan operasional. Apakah desain database mencakup seluruh perusahaan, satu atau lebih departemen dalam perusahaan, atau satu atau lebih fungsi dalam satu departemen? Pengetahuan ruang lingkup membantu mendefinisikan struktur data yang dibutuhkan, tipe dan jumlah entitas, ukuran fisik database, dsb. Batasan ada di luar sistem, bisa berupa waktu, anggaran, software & hardware yang ada. Idealnya, desainer dapat memilih hardware & software yang paling baik dalam mencapai sasaran sistem. Nyatanya, pemilihan software adalah aspek penting dari SDLC. Tetapi nyatanya, sistem harus dirancang sesuai hardware yang ada. Oleh karena itu, desainer bertugas untuk merancang sistem sebaik mungkin dalam batasan tersebut. Terkadang definisi masalah & tujuan harus diperbaiki untuk memenuhi ruang lingkup & batasan sistem.

Desain Database Konsentrasi terdapat pada karakteristik data yang dibutuhkan untuk membangun model database. Terdapat 2 pandangan terhadap data dalam sistem: Pandangan bisnis dari data sebagai sumber informasi. Pandangan desainer terhadap struktur data, akses, & aktivitas yang diperlukan untuk merubah data menjadi informasi.

Beberapa poin terkait prosedur yang dibutuhkan untuk menyelesaikan tahap desain dalam DBLC: Proses desain database berkaitan dengan analisis & desain sistem yang lebih besar. Komponen data hanya merupakan satu elemen dari sistem informasi yang lebih besar. Analis atau programmer sistem bertanggung jawab dalam merancang komponen sistem lain. Aktivitasnya membuat prosedur yang akan membantu transformasi data dalam database menjadi informasi. Desain database tidak mengikuti proses sekuensial, melainkan merupakan proses iteratif yang menyediakan umpan balik secara berkelanjutan yang dirancang untuk melacak langkah sebelumnya.

Proses desain database terbagi menjadi 3 tahap: desain konseptual, logis, & fisik, ditambah keputusan pemilihan DBMS, yang sangat kritis untuk menentukan tipe desain logis & fisik yang akan dibuat. Proses desain dimulai dengan desain konseptual yang berlanjut ke desain logis & fisik. Pada tiap tahap, detail lebih mengenai desain model data ditentukan & didokumentasikan. Desain konseptual sebagai keseluruhan data yang dilihat oleh end user, desain logis sebagai data yang dilihat oleh DBMS, & desain fisik sebagai data yang dilihat oleh alat manajemen penyimpanan sistem operasi.

Implementasi & Loading Output dari tahap desain database adalah serangkaian instruksi yang berisi detail pembuatan tabel, atribut, domain, view, indeks, batasan keamanan, & pedoman penyimpanan & kinerja. Pada tahap ini, semua spesifikasi desain tersebut diimplementasi.

Instal DBMS Langkah ini diperlukan hanya ketika dibutuhkan instance DBMS yang baru untuk sistem. DBMS dapat diinstal pada server baru atau yang sudah ada. Virtualisasi adalah teknik yang menciptakan representasi logis dari sumber daya komputasi yang independen dari sumber daya komputasi fisik. Teknik ini banyak digunakan dalam area komputasi, seperti pembuatan server virtual, penyimpanan virtual, & jaringan pribadi virtual (VPN). Dalam lingkungan database, virtualisasi database mengacu pada instalasi dari instance DBMS yang baru pada server virtual yang berjalan pada hardware bersama (shared).

Memasukkan atau mengkonversi data Membuat database Diawali dengan pembuatan database dan tabel menggunakan DDL. View sebenarnya tidak dibutuhkan untuk akses database dalam lingkungan relasional, tetapi view diperlukan dari sisi keamanan. Memasukkan atau mengkonversi data Setelah database dibuat, data harus dimasukkan ke dalam tabel database melalui migrasi dari versi sistem sebelumnya. Biasanya data harus dikumpulkan dari beberapa sumber. Skenario terbaiknya adalah semua data berada dalam database relasional sehingga dapat ditransfer langsung ke database baru. Nyatanya tidak demikian, sehingga dibutuhkan program konversi untuk memformat kembali data sebelum diimpor ke database baru. Skenario terburuknya adalah data harus diinput secara manual ke dalam database. Setelah data berhasil dipindahkan ke database baru, DBA bekerja dengan pengembang aplikasi untuk menguji & mengevaluasi database.

Pengujian & Evaluasi Pada tahap ini, DBA menguji dan menyetel database untuk memastikannya bekerja sesuai yang diharapkan. Fase ini terjadi dalam hubungannya dengan pemrograman aplikasi. Programmer menggunakan tool database untuk membuat prototipe aplikasi selama pengkodean program. Alat seperti report generators, screen painters, & menu generators berguna khususnya untuk programmer aplikasi.

Menguji database DBA menguji database untuk memastikan integritas & keamanan data. Integritas data diberlakukan oleh DBMS melalui penggunaan aturan primary & foreign key. DBMS juga mendukung pembuatan domain constraints & triggers. Pengujian dilakukan untuk memastikan batasan tersebut telah dirancang & diimplementasi dengan baik. Pengujian juga dilakukan pada hak akses user serta privasi & keamanan data.

Beberapa hal berikut yang harus diuji: Keamanan fisik  hanya personel yang diotorisasi yang memiliki akses fisik ke area tertentu. Implementasinya tergantung pada tipe database. Keamanan password  memberikan hak akses ke user yang terotorisasi & berlaku pada saat login di tingkat sistem operasi. Hak akses  dibuat melalui penggunaan software database. Hak akses dapat membatasi operasi (CREATE, UPDATE, DELETE, dsb) pada objek yang ditentukan seperti database, tabel, view, query, & laporan. Jejak audit  disediakan oleh DBMS untuk memeriksa pelanggaran akses. Enkripsi data  menampilkan data yang tidak berguna bagi user yang tidak terotorisasi yang mungkin melanggar beberapa lapisan keamanan database. Diskless workstation  user dapat mengakses database tanpa dapat mengunduh informasi dari komputernya.

Menyetel database Kinerja database sulit dievaluasi karena tidak ada standar pengukuran tetapi ini merupakan faktor penting dalam implementasi database. Kebutuhan kinerja database bergantung pada sistem, misalnya sistem yang mendukung transaksi cepat membutuhkan database yang menyediakan kinerja superior selama tingginya transaksi insert, update, & delete. Sistem lain seperti DSS membutuhkan kinerja superior untuk pengambilan data yang rumit. Banyak faktor yang dapat mempengaruhi kinerja database termasuk hardware & software dimana database beroperasi. Selain itu, karakteristik & volume data turut mempengaruhi kinerja database. Faktor penting lainnya mencakup parameter konfigurasi sistem & database seperti penempatan data, definisi jalur akses, penggunaan indeks, & ukuran buffer.

Evaluasi database & program aplikasinya Pengujian & evaluasi komponen individual harus berujung pada berbagai uji sistem yang lebih luas untuk memastikan bahwa semua komponen berinteraksi dengan baik sesuai kebutuhan user. Pada tahap ini, masalah integrasi & rencana deployment diperhalus, pelatihan user dilakukan, & dokumentasi sistem difinalisasi. Untuk memastikan tidak terjadinya kehilangan data maka rencana backup & restore harus diuji. Vendor database mendukung penggunaan komponen fault-tolerant seperti UPS, penyimpanan RAID, clustered servers, & teknologi replikasi data untuk memastikan operasi berkelanjutan dari database dalam kasus kegagalan hardware. Walaupun demikian, fungsi backup & restore merupakan bagian yang sangat penting dari operasi database sehari-hari. Beberapa DBMS menyediakan fungsi bagi DBA untuk menjadwalkan backup database secara otomatis ke alat penyimpanan seperti disk, DVD, tape, & penyimpanan online.

Backup database dapat dilakukan pada beberapa tingkat: Full backup, atau dump  membackup semua objek database. Differential backup  hanya membackup objek yang pernah dimodifikasi sejak full backup terakhir. Transaction log backup  hanya membackup operasi log transaksi yang tidak terdapat dalam backup database sebelumnya, tidak ada objek database lain yang dibackup. Backup database disimpan dalam lokasi aman, biasanya dalam gedung yang berbeda dari database itu sendiri, & dilindungi dari bahaya seperti api, pencurian, banjir, & ancaman lainnya. Pemulihan database biasanya diawali dengan menentukan tipe & tingkat pemulihan yang dibutuhkan. Pada akhir tahap ini, database menyelesaikan proses iteratif dari pengujian, evaluasi, & modifikasi yang berkelanjutan sampai sistem dinilai siap memasuki tahap operasional.

Operasi Awal tahap operasional memulai proses evolusi sistem. Segera setelah semua end user memasuki tahap operasi, masalah yang tidak dapat diramalkan selama tahap pengujian muncul ke permukaan. Beberapa masalah cukup serius sehingga membutuhkan respon darurat, sementara yang lain hanya berupa gangguan minor. Contoh: jika database diimplementasi dengan web, volume transaksi mungkin dapat menurunkan kinerja sistem. Dalam kasus ini, desainer harus mengidentifikasi sumber bottleneck & membuat solusi alternatif. Solusi tersebut dapat berupa software load balancing untuk mendistribusikan transaksi ke beberapa komputer, meningkatkan cache yang tersedia untuk DBMS, dsb.

Pemeliharaan & Evolusi DBA melakukan aktivitas pemeliharaan rutin dalam database yang mencakup: Pemeliharaan preventif (backup) Pemeliharaan korektif (pemulihan) Pemeliharaan adaptif (meningkatkan kinerja, menambah entitas & atribut, dsb) Pemberian akses & pemeliharaan untuk user baru & lama Pembuatan statistik akses database untuk meningkatkan efisiensi & kegunaan audit sistem & untuk memantau kinerja sistem Audit keamanan berkala berdasarkan statistik yang dihasilkan sistem Ringkasan penggunaan sistem bulanan, tiap 3 bulan, atau tahunan untuk tujuan billing internal atau budgeting Perubahan mudah diimplementasi hanya ketika desain database fleksibel & semua dokumentasi tersedia. Akhirnya bahkan database yang dirancang dengan baik tidak selamanya mampu mengikuti perubahan yang evolusioner, sehingga proses DBLC dimulai lagi.

Aktivitas Paralel dalam DBLC & SDLC

Desain Konseptual Tahap pertama dalam proses desain database. Bertujuan untuk merancang database yang independen dari software database & detail fisik. Output dari proses ini adalah model data konseptual yang mendeskripsikan entitas data utama, atribut, hubungan, & batasan dari domain yang diberikan. Biasanya terdiri dari representasi grafis bersamaan dengan deskripsi tekstual dari elemen data utama, hubungan, & batasan. Semua elemen data yang dibutuhkan oleh transaksi database harus didefinisikan dalam model, & semua elemen data yang didefinisikan dalam model harus digunakan paling sedikit oleh satu transaksi database. Fokus tidak hanya pada kebutuhan data sekarang tetapi juga kebutuhan data mendatang. Desain database harus memungkinkan modifikasi & penambahan di masa mendatang.

Langkah dalam desain konseptual: Analisis & kebutuhan data Pemodelan hubungan entitas & normalisasi Verifikasi model data Desain database terdistribusi

Analisis & kebutuhan data Langkah pertama adalah untuk menemukan karakteristik dari elemen data dengan fokus: Kebutuhan informasi: Jenis informasi apa yang dibutuhkan? Output/ laporan/ query apa yang harus dihasilkan oleh sistem? Informasi apa yang dihasilkan sistem berjalan & sampai sejauh mana informasi tersebut memadai? Pengguna informasi: Siapa pengguna informasi? Bagaimana informasi digunakan? Data apa yang dilihat oleh end user? Sumber informasi: Dimana informasi dapat ditemukan? Bagaimana informasi akan diekstrak saat ditemukan? Susunan informasi: Elemen data apa yang dibutuhkan untuk menghasilkan informasi? Atribut data, hubungan antar data, volume data? Seberapa sering data digunakan? Transformasi data yang akan digunakan untuk menghasilkan informasi yang dibutuhkan?

Desainer memperoleh jawaban untuk pertanyaan di atas dari berbagai sumber untuk mengkompilasi informasi yang dibutuhkan: Membangun & mengumpulkan view data end-user Mengamati sistem berjalan secara langsung Berinteraksi dengan kelompok desain sistem Dari sudut pandang database, kumpulan data menjadi berarti hanya ketika aturan bisnis didefinisikan. Aturan bisnis diturunkan dari deskripsi operasi format, yaitu dokumen yang menyediakan deskripsi aktivitas yang tepat, up-to-date, & menyeluruh yang mendefinisikan lingkungan operasi perusahaan. Sumber informasi untuk deskripsi operasi & aturan bisnis adalah manajer perusahaan, pembuat kebijakan, manajer divisi, & dokumentasi tertulis seperti prosedur perusahaan, standar, & manual operasi. Untuk memperoleh aturan bisnis dengan cepat adalah dengan mewawancarai end user tetapi masing-masing end user mungkin memiliki persepsi yang berbeda, sehingga desainer bertugas untuk merekonsiliasi perbedaan & memverifikasi hasil rekonsiliasi untuk memastikan aturan bisnis sesuai & akurat.

Aturan bisnis menghasilkan beberapa manfaat penting dalam desain sistem baru: Membantu standarisasi pendangan data perusahaan. Membentuk alat komunikasi antara user & desainer. Memperbolehkan desainer untuk memahami sifat, peran, & ruang lingkup data. Memperbolehkan desainer untuk memahami proses bisnis. Memperbolehkan desainer untuk membangun aturan partisipasi hubungan yang tepat & batasan foreign key.

Pemodelan hubungan entitas & normalisasi Sebelum membuat model ER, desainer harus mendiskusikan mengenai standar yang akan digunakan dalam dokumentasi desain, mencakup penggunaan diagram & simbol, jenis tulisan, layout, dsb. Berikut langkah membangun model konseptual menggunakan diagram ER: Identifikasi, analisis, & perbaikan aturan bisnis. Identifikasi entitas utama menggunakan hasil langkah 1. Definisikan hubungan antar entitas, menggunakan hasil langkah 1 &2. Definisikan atribut, primary key, & foreign key untuk tiap entitas. Normalisasi entitas. Lengkapi diagram ER awal. Validasi model ER dengan kebutuhan informasi end user & pemrosesan. Modifikasi model ER menggunakan hasil langkah 7.

Selama proses pemodelan ER, desainer harus: Mendefinisikan entitas, atribut, primary key, & foreign key. Membuat keputusan mengenai penambahan atribut primary key baru untuk memuaskan kebutuhan end-user & pemrosesan. Membuat keputusan mengenai perlakuan atribut composite & multivalued. Membuat keputusan mengenai penambahan atribut turunan untuk memuaskan kebutuhan pemrosesan. Membuat keputusan mengenai posisi foreign key dalam hubungan 1:1. Hindari hubungan ternary yang tidak perlu. Gambar diagram ER. Normalisasi entitas. Masukkan semua definisi elemen data dalam kamus data. Membuat keputusan mengenai standar penamaan. Standar penamaan penting agar tim pengembangan memiliki acuan yang sama.

Verifikasi model data Merupakan tahap paling penting dimana model ER diverifikasi dengan proses sistem yang diusulkan. Verifikasi dilakukan dengan pengujian model terhadap: Pandangan data end-user Semua transaksi yang dibutuhkan: operasi SELECT, INSERT, UPDATE, & DELETE Hak akses & keamanan Kebutuhan data & batasan bisnis Perancangan database dipecah menjadi komponen utama yang dinamakan modul. Tiap modul menangani fungsi bisnis tertentu dan didukung oleh pecahan ER yang merupakan subset atau pecahan dari model ER perusahaan. Pecahan ER dapat mengakibatkan terjadinya overlapping, duplikasi, atau konflik pada view dari data yang sama; & tidak dapat mendukung semua proses dalam modul sistem

Langkah proses verifikasi model ER: Identifikasi entitas utama model ER Identifikasi tiap modul & komponennya Identifikasi kebutuhan transaksi tiap modul Internal: updates/ inserts/ deletes/ queries/ reports Eksternal: module interfaces Verifikasi semua proses dengan kebutuhan sistem Lakukan semua perubahan yang disarankan di langkah 4 Ulangi langkah 2-5 untuk semua modul

Desain database terdistribusi Beberapa perusahaan membutuhkan database terdistribusi yang tersebar di beberapa lokasi geografi. Proses yang mengakses database juga bervariasi antar lokasi. Jika data & proses akan didistribusikan maka pecahan database akan berada di beberapa lokasi fisik. Pecahan database dapat berupa subset dari baris atau kolom dari satu atau lebih tabel. Strategi alokasi menentukan bagaimana membagi database & dimana tiap pecahan harus disimpan.

Pemilihan Software DBMS Beberapa faktor yang mempengaruhi keputusan membeli software: Biaya: harga beli, biaya pemeliharaan, operasional, lisensi, instalasi, pelatihan, & konversi. Fitur & tool DBMS: contoh tool DBMS yaitu QBE (Query by Example), screen painters, report generators, application generators, & data dictionaries. Fasilitas administrator database, query, kemudahan pemakaian, kinerja, keamanan, kontrol konkurensi, pemrosesan transaksi, & dukungan pihak ketiga juga mempengaruhi pemilihan software DBMS. Model: hirarki, jaringan, relasional, atau berorientasi objek. Portabilitas: portabel di semua platform, sistem, & bahasa. Kebutuhan hardware DBMS: prosesor, RAM, kapasitas penyimpanan, dsb.

Desain Logis Tujuan dari desain logis adalah untuk merancang database perusahaan berdasarkan model data tertentu tetapi independen dari detail tingkat fisik. Desain logis membutuhkan semua objek dalam model konseptual dipetakan ke bentuk khusus yang digunakan oleh model database yang dipilih. Berikut langkah desain logis: Memetakan model konseptual ke komponen model logis. Memvalidasi model logis menggunakan normalisasi. Memvalidasi integrity constraint pada model logis. Memvalidasi model logis dengan kebutuhan user.

Memetakan model konseptual ke model logis Model logis yang digunakan adalah model relasional karena merupakan model yang paling banyak digunakan. Berikut aktivitas yang dilakukan: Memetakan entitas yang kuat Memetakan hubungan supertype/ subtype Memetakan entitas yang lemah Memetakan hubungan binary Memetakan hubungan tingkat tinggi

Validasi model logis menggunakan normalisasi Desain logis harus berisi hanya tabel yang sudah normal (3NF). Proses pemetaan dari model konseptual ke model logis akan mengungkap beberapa atribut baru atau multivalued atau composite. Desain database merupakan proses iteratif. Normalisasi akan dilakukan pada beberapa tahapan berbeda dalam proses desain. Setiap kali suatu tahap diulangi, model menjadi lebih baik.

Validasi integrity constraint pada model logis Tiap constraint yang teridentifikasi harus dipetakan ke constraint model relasional. Hak akses database juga ditentukan selama tahap desain logis. View dapat membantu membatasi akses user ke satu atau lebih data. Sebagai tambahan, jika menggunakan desain database terdistribusi, data dapat disimpan pada beberapa lokasi, & tiap lokasi mungkin memiliki batasan keamanan yang berbeda. Validasi model logis dengan kebutuhan user Model logis divalidasi terhadap semua kebutuhan data end-user, transaksi, & keamanan. Tahap ini merupakan persiapan untuk mendefinisikan kebutuhan fisik agar sistem dapat berfungsi dalam lingkungan DBMS/ hardware yang dipilih.

Desain Fisik Desain fisik adalah proses menentukan organisasi penyimpanan data & karakteristik akses data dari database untuk memastikan integritas, keamanan, & kinerja. Desain fisik dapat menjadi pekerjaan teknis yang bukan hanya mempengaruhi aksesibilitas data dalam alat penyimpanan tetapi juga kinerja sistem. Langkah dalam desain fisik: Mendefinisikan organisasi penyimpanan data Mendefinisikan ukuran integritas & keamanan Menentukan ukuran kinerja

Mendefinisikan organisasi penyimpanan data Desainer harus menentukan volume data yang akan dikelola & pola penggunaan data, kemudian dilanjutkan dengan langkah berikut: Menentukan lokasi & organisasi penyimpanan fisik untuk tiap tabel. Mengidentifikasi indeks & jenis indeks untuk tiap tabel. Mengidentifikasi view & jenis view untuk tiap tabel.

Menentukan ukuran integritas & keamanan Sebelum user dapat mengakses data dalam database, user harus dikonfirmasi dengan benar. Berikut 2 hal yang harus dilakukan desainer: Mendefinisikan user, kelompok user & perannya. Desainer harus mengetahui berbagai jenis user & kelompok user agar dapat memberlakukan keamanan database. Kebanyakan DBMS mendukung penggunaan database role. Database role adalah seperangkat hak database yang diberikan ke user atau kelompok. Menentukan kontrol keamanan. DBMS juga memperbolehkan administrator untuk menentukan hak akses tertentu pada objek database ke user atau kelompok user.

Menentukan ukuran kinerja Desain fisik menjadi lebih rumit ketika data terdistribusi ke beberapa lokasi karena kinerja dipengaruhi oleh throughput media komunikasi. Kinerja database relasional dipengaruhi oleh properti penyimpanan fisik seperti waktu pencarian, ukuran sector & block (page), ukuran buffer pool, & jumlah disk platters & read/ write heads. Faktor seperti indeks juga cukup berpengaruh terhadap kinerja database relasional, yaitu kecepatan & efisiensi akses data.

Strategi Desain Database Terdapat 2 pendekatan desain database: Desain top-down diawali dengan identifikasi set data kemudian mendefinisikan elemen data untuk tiap set tersebut. Proses ini melibatkan identifikasi entitas kemudian menentukan atribut dari tiap entitas. Lebih sesuai untuk jumlah, variasi, & kompleksitas entitas, relasi, & transaksi yang besar. Desain bottom-up diawali dengan identifikasi elemen data (item) kemudian mengelompokkannya ke dalam set data. Dengan kata lain, definisikan atribut terlebih dulu, kemudian mengelompokkannya menjadi entitas. Lebih sesuai untuk database kecil dengan sedikit entitas, atribut, relasi, & transaksi.

Sentralisasi vs Desentralisasi Desain sentralisasi lebih produktif ketika komponen data memiliki jumlah objek & prosedur yang relatif kecil. Hanya dibutuhkan 1 orang DBA ntuk mendesain database ini. Desain desentralisasi digunakan ketika komponen data sistem memiliki jumlah entitas yang cukup besar & hubungan yang rumit dimana operasi rumit dilakukan. Desain ini biasanya digunakan ketika masalah tersebar di beberapa titik operasional & tiap elemen adalah bagian dari keseluruhan set data.

Review Materi Mahasiswa mengerjakan tugas yang ada di portal.