Tugas-Tugas Seorang Database Administrator Oracle

Advertisement

Tugas-tugas seorang database administrator oracle berikut menyajikan sebuah pendekatan yang diprioritaskan untuk merancang, melaksanakan, dan memelihara database Oracle. Tugas – tugas tersebut antara lain adalah sebagai berikut:

Tugas 1: Mengevaluasi Hardware  dari Database Server
Tugas 2: Instal Software Oracle
Tugas 3: Merencanakan Database
Tugas 4: Membuat dan Membuka Database
Tugas 5: Back Up Database
Tugas 6: Mendaftar Sistem Pengguna
Tugas 7: Mengimplementasikan Desain Database
Tugas 8: Melaksanakan Back Up secara keseluruhan dari Fungsional Database Sepenuhnya
Tugas 9: Melakukan Tuning Kinerja database

Tugas 1: Mengevaluasi Hardware  dari Database Server

Mengevaluasi bagaimana Oracle dan aplikasi yang terbaik dapat menggunakan sumber daya yang tersedia di komputer. Evaluasi ini harus mengungkapkan informasi berikut:

• Berapa banyak disk drive yang tersedia untuk Oracle dan database-nya

• Berapa banyak, jika ada, tape drive yang dedicated yang tersedia untuk Oracle dan database-nya

• Berapa banyak memori yang tersedia untuk kasus Oracle yang akan anda jalankan (lihat dokumentasi konfigurasi sistem anda)

Tugas 2: Melakukan Instalasi  Software Oracle

Sebagai seorang database administrator, Anda perlu untuk menginstal perangkat lunak (software) server database Oracle dan alat bantu front-end dan aplikasi database yang mengakses database. Dalam beberapa instalasi pemrosesan terdistribusi, database dikendalikan oleh komputer pusat (database server) dan alat bantu (tool) database dan aplikasi yang dijalankan pada komputer remote (klien). Dalam hal ini, Anda juga harus menginstal komponen Net Oracle yang diperlukan untuk menghubungkan mesin remote ke komputer yang menjalankan Oracle.

Tugas 3: Merencanakan Database / Design Database

Sebagai database administrator, Anda harus merencanakan:
• Struktur penyimpanan logis dari database
• keseluruhan desain database
• Sebuah strategi cadangan untuk database

Hal ini penting untuk merencanakan bagaimana struktur penyimpanan logis dari database akan mempengaruhi kinerja sistem dan berbagai operasi manajemen database. Misalnya, sebelum menciptakan setiap tablespace untuk database Anda, maka Anda harus tahu berapa banyak datafiles yang dibuat untuk membentuk tablespace, apa jenis informasi yang akan disimpan di setiap tablespace, dan di mana disk drive datafiles akan disimpan secara fisik. Ketika merencanakan penyimpanan logis keseluruhan struktur database, memperhitungkan efek bahwa struktur ini akan memiliki kapan database sebenarnya diciptakan dan berjalan. 

Pertimbangan tersebut termasuk bagaimana logical storage dari struktur database akan mempengaruhi hal-hal berikut ini:

• Kinerja komputer ketika mengeksekusi Oracle

• Kinerja database selama operasi akses data

• Efisiensi backup dan recovery prosedur untuk database

Merencanakan desain relasional pada objek database dan karakteristik penyimpanan untuk masing-masing objek. Dengan perencanaan hubungan antara setiap obyek dan penyimpanan fisik sebelum menciptakan itu, Anda dapat secara langsung mempengaruhi kinerja database sebagai satu unit. Pastikan untuk merencanakan pertumbuhan database.

Dalam lingkungan database terdistribusi, tahap perencanaan ini sangatlah penting. Lokasi fisik dari data yang sering diakses secara dramatis mempengaruhi kinerja aplikasi.

Selama tahap perencanaan, kembangkanlah strategi cadangan untuk database. Anda dapat mengubah struktur penyimpanan logis atau desain database untuk meningkatkan efisiensi backup.

Hal ini di luar cakupan buku ini untuk membahas relasional dan didistribusikan desain database. Jika Anda tidak akrab dengan masalah desain tersebut, lihat dokumentasi diterima standar industri.


Tugas 4: Membuat dan Membuka Database

Ketika Anda telah menyelesaikan desain database, Anda dapat membuat database dan membukanya untuk penggunaan normal. Anda dapat membuat database pada waktu instalasi, menggunakan Konfigurasi Database Asisten, atau Anda dapat menyediakan skrip Anda sendiri untuk membuat sebuah database.

Tugas 5: Back Up Database

Setelah Anda membuat struktur database, melaksanakan strategi cadangan Anda rencanakan untuk database. Buat file log Redo tambahan, mengambil pertama backup database penuh (online atau offline), dan jadwal backup database yang datang secara berkala.

Tugas 6: Mendaftar Sistem Pengguna (regristasi user)

Setelah Anda kembali struktur database, Anda dapat mendaftarkan pengguna database sesuai dengan perjanjian lisensi Oracle Anda, membuat peran yang sesuai untuk para pengguna, dan memberikan peran ini.

Tugas 7: Mengimplementasikan Desain Database yang sudah dibuat

Setelah Anda membuat dan mulai database, dan mendaftarkan diri pengguna sistem, Anda dapat menerapkan direncanakan struktur database logis dengan menciptakan semua tablespace yang diperlukan. Ketika Anda telah menyelesaikan ini, Anda dapat membuat objek untuk database.

Tugas 8: Back Up Database Sepenuhnya secara Fungsional

Sekarang database sepenuhnya dilaksanakan, sekali lagi kembali database. Selain backup dijadwalkan secara rutin, Anda harus selalu membuat cadangan database Anda segera setelah menerapkan perubahan struktur database.

Advertisement

Tugas 9: Melakukan Tuning Kinerja database

Mengoptimalkan kinerja database merupakan salah satu tanggung jawab yang Anda terima sebagai DBA. Selain itu, Oracle menyediakan fitur pengelolaan sumber daya database yang memungkinkan Anda untuk mengontrol alokasi sumber daya untuk berbagai kelompok pengguna

No comments

Pengenalan terhadap Design Database Part 3

Advertisement

Dalam artikel ini kita menggunakan Design Database untuk merancang dan menyajikan database kami.

Sebuah hubungan 1:1 wajib diwakili sebagai berikut:

A 1: N hubungan wajib:

A M: hubungan N adalah:

Model contoh kita akan terlihat seperti ini:

Menugaskan Keys

Primer Tombol

Sebuah kunci primer (PK) adalah satu atau lebih data atribut yang secara unik mengidentifikasi suatu entitas. Sebuah kunci yang terdiri dari dua atau lebih atribut disebut kunci komposit. Semua bagian atribut dari primary key harus memiliki nilai dalam setiap catatan (yang tidak dapat dibiarkan kosong) dan kombinasi dari nilai-nilai dalam atribut-atribut harus unik dalam tabel.

Dalam contoh ada beberapa kandidat yang jelas beberapa untuk primary key. Pelanggan semua memiliki nomor pelanggan, produk semua memiliki sejumlah produk yang unik dan penjualan memiliki jumlah penjualan. Masing-masing data unik dan setiap record akan berisi nilai, sehingga atribut ini dapat menjadi kunci utama. Seringkali sebuah kolom integer digunakan untuk primary key sehingga catatan dapat dengan mudah ditemukan melalui nomornya.

Link-entitas biasanya mengacu pada atribut primary key dari entitas yang mereka link. Kunci utama dari entitas link-biasanya merupakan koleksi dari atribut-atribut referensi-. Misalnya dalam entitas Sales_details kita bisa menggunakan kombinasi dari PK terhadap penjualan produk dan entitas sebagai PK dari Sales_details. Dengan cara ini kita menegakkan bahwa produk yang sama (jenis) hanya dapat digunakan sekali dalam penjualan yang sama. Beberapa item dari jenis produk yang sama dalam penjualan harus ditunjukkan dengan kuantitas.

Dalam ERD atribut primary key ditandai dengan 'PK' teks balik nama atribut. Dalam contoh hanya 'toko' entitas tidak memiliki calon yang jelas untuk PK, jadi kami akan memperkenalkan atribut baru untuk itu entitas: shopnr.

Foreign Key

Kunci Asing/Tamu (FK) dalam suatu entitas adalah mengacu pada primary key dari entitas lain. Dalam ERD atribut yang akan ditunjukkan dengan 'FK' di belakang namanya. Kunci asing dari suatu entitas juga dapat menjadi bagian dari primary key, dalam hal bahwa atribut akan ditunjukkan dengan 'PF' di belakang namanya. Ini biasanya terjadi dengan entitas link-, karena Anda biasanya menghubungkan dua contoh hanya sekali bersama-sama (dengan 1 dijual hanya 1 jenis produk yang dijual 1 kali).

Jika kita meletakkan semua link-entitas, PK dan FK ke ERD, kita mendapatkan model seperti yang ditunjukkan di bawah ini. Harap dicatat bahwa 'produk' atribut tidak lagi diperlukan dalam 'Penjualan', karena 'produk yang dijual' sekarang termasuk dalam tabel link-. Dalam tabel link-bidang lain ditambahkan, 'kuantitas', yang menunjukkan berapa banyak produk yang dijual. Bidang kuantitas juga ditambahkan dalam tabel saham-, untuk menunjukkan berapa banyak produk yang masih di toko.

Mendefinisikan Jenis Data Atribut ini

Sekarang saatnya untuk mencari tahu mana tipe data perlu digunakan untuk atribut. Ada banyak jenis data yang berbeda. Beberapa yang standar, tetapi banyak database memiliki tipe data mereka sendiri bahwa semua memiliki keunggulan sendiri. Beberapa offerthe database kemungkinan untuk menentukan jenis data Anda sendiri, dalam hal jenis standar tidak bisa melakukan hal-hal yang Anda butuhkan.

Tipe data standar yang setiap database tahu, dan yang paling-digunakan, adalah: CHAR, VARCHAR, TEXT, FLOAT, DOUBLE, dan INT.

Teks:

CHAR (panjang) - mencakup teks (karakter, angka, tanda baca ...). CHAR memiliki karakteristik seperti itu selalu menyimpan jumlah yang tetap posisi. Jika anda mendefinisikan suatu CHAR (10) Anda dapat menyimpan hingga sepuluh posisi maksimal, tetapi jika Anda hanya menggunakan dua posisi database masih akan menghemat 10 posisi. Sisanya delapan posisi akan diisi oleh spasi.

VARCHAR (panjang) - mencakup teks (karakter, angka, tanda baca ...). VARCHAR adalah sama seperti CHAR, perbedaannya adalah bahwa VARCHAR hanya membutuhkan ruang sebanyak yang diperlukan.

TEKS - dapat berisi sejumlah besar teks. Tergantung pada jenis database ini dapat menambahkan hingga gigabyte.
Nomor:

INT - berisi seluruh nomor positif atau negatif. Banyak database memiliki variasi INT, seperti TINYINT, SMALLINT, MEDIUMINT, BIGINT,, INT2 INT4, int8. Variasi ini berbeda dari INT hanya dalam ukuran sosok yang cocok ke dalamnya. Sebuah INT biasa adalah 4 byte (INT4) dan cocok angka dari -2147483647 sampai 2147483646, atau jika Anda mendefinisikannya sebagai unsigned 0-4294967296. The int8, atau BIGINT, bisa mendapatkan bahkan lebih besar dalam ukuran, 0-18446744073709551616, tetapi memakan waktu sampai 8 byte diskspace, bahkan jika ada hanya sejumlah kecil di dalamnya.

Float, DOUBLE - Ide yang sama seperti INT, tetapi juga dapat menyimpan angka floating point. . Lakukan dicatat bahwa ini tidak selalu bekerja dengan sempurna. Misalnya dalam MySQL menghitung dengan angka-angka floating point tidak sempurna, (1/3) * 3 akan menghasilkan dengan mengapung MySQL dalam 0,9999999, bukan 1.

Lain jenis:

BLOB - untuk data biner seperti files.INET - untuk alamat IP. Juga bisa digunakan untuk netmasks.

Sebagai contoh kita tipe data adalah sebagai berikut:

Normalisasi

Normalisasi membuat model data Anda fleksibel dan dapat diandalkan. Ini tidak menghasilkan beberapa overhead karena Anda biasanya mendapatkan lebih tabel, tetapi memungkinkan Anda untuk melakukan banyak hal dengan model data Anda tanpa harus menyesuaikan. 

Normalisasi, Formulir Pertama

Bentuk pertama dari normalisasi menyatakan bahwa mungkin tidak ada kelompok mengulangi kolom dalam suatu entitas. Kita bisa menciptakan 'penjualan' entitas dengan atribut untuk masing-masing produk yang dibeli. Ini akan terlihat seperti ini:

Apa yang salah tentang ini adalah bahwa sekarang hanya 3 produk bisa dijual. Jika Anda harus menjual produk 4, daripada Anda harus memulai penjualan kedua atau menyesuaikan model data Anda dengan menambahkan 'product4' atribut. Kedua solusi yang tidak diinginkan. Dalam kasus ini Anda harus selalu membuat sebuah entitas baru yang Anda link ke yang lama melalui hubungan satu-ke-banyak.

Normalisasi, Formulir Kedua

Bentuk kedua dari normalisasi menyatakan bahwa semua atribut dari suatu entitas harus sepenuhnya tergantung pada primary key secara keseluruhan. Ini berarti bahwa setiap atribut dari suatu entitas hanya dapat diidentifikasi melalui primary key secara keseluruhan. Misalkan kita memiliki tanggal dalam entitas Sales_details:

Entitas ini tidak sesuai bentuk normalisasi kedua, karena untuk dapat mencari tanggal penjualan, saya tidak tahu apa yang dijual (productnr), satu-satunya hal yang perlu saya ketahui adalah jumlah penjualan. Hal ini diselesaikan dengan putus tabel ke dalam penjualan dan tabel Sales_details:

Sekarang setiap atribut dari entitas tergantung pada PK seluruh entitas. Tanggal ini tergantung pada jumlah penjualan, dan kuantitas tergantung pada jumlah penjualan dan produk yang dijual.

Normalisasi, Formulir Ketiga

Bentuk ketiga normalisasi menyatakan bahwa semua atribut harus langsung tergantung pada primary key, dan bukan pada atribut lainnya. Hal ini tampaknya menjadi apa bentuk kedua negara normalisasi, namun dalam bentuk yang kedua sebenarnya menyatakan sebaliknya. Dalam bentuk kedua normalisasi Anda menunjukkan atribut melalui PK, dalam bentuk ketiga normalisasi setiap atribut harus tergantung pada PK, dan tidak ada lagi.

Dalam hal ini harga produk longgar tergantung pada jumlah pemesanan, dan jumlah pemesanan tergantung pada jumlah produk dan jumlah penjualan. Hal ini tidak sesuai dengan bentuk ketiga normalisasi. Sekali lagi, putus tabel memecahkan ini.

Normalisasi, Lebih Formulir

Ada bentuk normalisasi lebih dari tiga bentuk yang disebutkan di atas, tetapi mereka tidak menarik untuk pengguna rata-rata. Bentuk-bentuk lain sangat khusus untuk aplikasi tertentu. Jika Anda tetap berpegang pada aturan desain dan normalisasi yang disebutkan dalam artikel ini, Anda akan membuat desain yang bekerja bagus untuk sebagian besar aplikasi.

Normalized Data Model

Advertisement

Jika Anda menerapkan aturan normalisasi, Anda akan menemukan bahwa 'produsen' dalam tabel produk de juga harus menjadi tabel terpisah:

Glosarium

Atribut - data rinci mengenai suatu entitas, seperti nama harga,, panjang

Kardinalitas - hubungan antara dua entitas, dalam angka. Sebagai contoh, seseorang dapat menempatkan beberapa perintah.

Entitas - data abstrak yang Anda simpan dalam database. Sebagai contoh: pelanggan, produk.

Kunci asing (FK) - rujukan ke Primary Key dari meja lain. Kunci asing-kolom hanya dapat berisi nilai-nilai yang ada di kolom Primary Key yang mereka lihat.

Kunci - kunci yang digunakan untuk menunjukkan catatan. Kunci yang paling terkenal adalah Primary Key (lihat Primary Key).

Normalisasi - Sebuah model data yang fleksibel perlu mengikuti aturan-aturan tertentu. Menerapkan aturan ini disebut normalisasi.

Primary key - satu atau lebih kolom dalam sebuah tabel yang bersama-sama membentuk sebuah kombinasi unik dari nilai-nilai yang setiap record dapat menunjukkan secara terpisah. Sebagai contoh: pelanggan nomor, atau nomor seri produk.

No comments

Pengenalan Terhadap Design Database Part2

Sekarang kita akan menempatkan data bersama-sama untuk menemukan kardinalitas seluruh hubungan. Untuk melakukan hal ini, kita akan menyusun rancangan kardinalitas per hubungan. Untuk membuat ini mudah dilakukan, kami akan menyesuaikan notasi sedikit, dengan mencatat 'backward'-hubungan sebaliknya:

Pelanggan -> Penjualan, pelanggan dapat membeli sesuatu atau beberapa barang 1 kali dalam satu waktu 

Penjualan -> Pelanggan, 1 barang yang dijual selalu dibuat oleh 1 customer pada saat itu

Hubungan kedua kita akan berbalik sehingga memiliki urutan entitas yang sama seperti yang pertama. Harap perhatikan panah yang kini dihadapi dengan cara lain!

Pelanggan <- Penjualan, 1  barang yang dijual selalu dibuat oleh 1 customer pada saat itu

Kardinalitas ada dalam empat jenis: satu-ke-satu, satu-ke-banyak, banyak-ke-satu, dan banyak-ke-banyak. Dalam design database ini diindikasikan sebagai: 1:1, 1: N, M: 1, dan M: N. Untuk menemukan indikasi yang tepat hanya meninggalkan '1 '. Jika ada 'banyak' di sisi kiri, ini akan ditandai dengan 'M', jika ada 'banyak' di sisi kanan ditandai dengan 'N'.

Pelanggan -> Penjualan, pelanggan dapat membeli 1 kali sesuatu yang beberapa; 1: N.

Pelanggan <- Penjualan, 1 barang yang dijual selalu dibuat oleh 1 customer pada saat itu; 1:1.

Kardinalitas benar dapat dihitung melalui menempatkan nilai terbesar bagi kiri dan kanan, yang 'N' atau 'M' yang lebih besar dari '1 '. Dalam contoh berikut, dalam kedua kasus ada ''1 di sisi kiri. Di sisi kanan, ada 'N' dan '1 ',' N 'adalah nilai terbesar. Kardinalitas total karena '1: N '. Pelanggan dapat membuat beberapa 'penjualan', tetapi masing-masing 'dijual' hanya memiliki satu pelanggan.

Jika kita melakukan ini untuk hubungan lain juga, kita akan mendapatkan:

Pelanggan -> Penjualan; -> 1: N
Pelanggan -> Produk; -> M: N
Pelanggan -> Toko; -> M: N
Penjualan -> Produk; -> M: N
Toko -> Penjualan; -> 1: N
Toko -> Produk; -> M: N
Jadi, kita memiliki dua 'hubungan, dan empat' '1-ke-banyak hubungan banyak-ke-banyak '.

Antara entitas mungkin ada saling ketergantungan. Ini berarti bahwa salah satu item tidak bisa eksis jika item lainnya tidak ada. Sebagai contoh, tidak mungkin ada penjualan jika tidak ada pelanggan, dan tidak mungkin ada penjualan jika tidak ada produk.

Hubungan Penjualan -> Pelanggan, dan Penjualan -> Produk yang wajib, namun sebaliknya hal ini tidak terjadi. Pelanggan dapat ada tanpa penjualan, dan juga produk dapat eksis tanpa dijual. Ini sangat penting untuk langkah berikutnya.

Rekursif Hubungan

Kadang-kadang suatu entitas mengacu kembali ke dirinya sendiri. Misalnya, memikirkan hirarki kerja: seorang karyawan memiliki bos, dan bosschef adalah seorang karyawan juga. 'Bos' atribut 'karyawan' entitas mengacu kembali ke 'karyawan' entitas.

Dalam ERD (lihat pada artikel berikutnya) ini jenis hubungan adalah garis yang keluar dari badan dan kembali dengan loop bagus untuk entitas yang sama.

Redundant Hubungan

Kadang-kadang dalam model Anda, Anda akan mendapatkan 'hubungan berlebihan'. Ini adalah hubungan yang sudah ditunjukkan oleh hubungan lain, meskipun tidak secara langsung.

Dalam kasus contoh kita ada hubungan langsung antara pelanggan dan produk. Tapi ada juga hubungan dari pelanggan untuk penjualan dan dari penjualan produk, sehingga secara tidak langsung sudah ada adalah hubungan antara pelanggan dan produk melalui penjualan. 'Pelanggan <----> Produk' Hubungan ini dilakukan dua kali, dan salah satunya adalah karena berlebihan. Dalam hal ini, produk hanya dibeli melalui penjualan, sehingga hubungan 'Pelanggan <----> Produk' dapat dihapus. Model kemudian akan terlihat seperti ini:

Menyelesaikan Banyak-ke-Banyak Hubungan

Banyak-ke-banyak hubungan (M: N) tidak secara langsung mungkin dalam database. Apa M: hubungan N mengatakan bahwa sejumlah catatan dari satu meja milik sejumlah catatan dari meja lain. Di suatu tempat Anda perlu untuk menyimpan yang merekam dan ini adalah solusinya adalah untuk membagi hubungan dalam dua satu-ke-banyak hubungan.

Hal ini dapat dilakukan dengan menciptakan sebuah entitas baru yang ada di antara entitas terkait. Dalam contoh kita, ada hubungan banyak-ke-banyak antara penjualan dan produk. Hal ini dapat diatasi dengan menciptakan sebuah entitas baru: penjualan-produk. Entitas ini memiliki hubungan banyak-ke-satu dengan penjualan, dan hubungan banyak-ke-satu dengan Produk. Dalam model logis ini disebut entitas asosiatif dan dalam hal database fisik ini disebut link tabel atau meja persimpangan.

Dalam contoh ada dua banyak-ke-banyak hubungan yang perlu dipecahkan: "Produk <----> Penjualan ', dan' Produk <----> Toko '. Untuk kedua situasi ada perlu dibuat suatu entitas baru, tapi apa entitas itu?

Untuk Produk <----> Penjualan hubungan, setiap penjualan meliputi lebih banyak produk. Hubungan menunjukkan isi dari penjualan. Dengan kata lain, memberikan rincian tentang penjualan. Jadi entitas disebut 'Penjualan detail'. Anda juga bisa nama 'produk yang dijual' itu.

The Produk <----> menunjukkan hubungan Toko yang produk yang tersedia di mana toko-toko, juga dikenal sebagai 'saham'. Model kami sekarang akan terlihat seperti ini:

Mengidentifikasi Atribut

Elemen data yang ingin Anda simpan untuk setiap entitas disebut 'atribut'.

Tentang produk yang Anda jual, Anda ingin tahu, misalnya, apa harga adalah, apa nama pabriknya, dan apa nomor tipe. Tentang pelanggan Anda tahu nomor pelanggan mereka, nama mereka, dan alamat. Tentang toko Anda tahu kode lokasi, nama, alamat. Dari penjualan Anda tahu ketika mereka terjadi, di mana toko, produk apa yang dijual, dan jumlah total dari penjualan. Dari vendor Anda tahu nomor stafnya, nama, dan alamat. Apa yang akan dimasukkan secara tepat tidak penting lagi, itu masih hanya tentang apa yang Anda ingin menyimpan.

Source data

Data yang diperoleh adalah data yang berasal dari data lain yang Anda sudah disimpan. Dalam hal ini 'jumlah total' adalah kasus klasik data yang berasal. Anda tahu persis apa yang telah dijual dan berapa yang masing-masing biaya produk, sehingga Anda selalu dapat menghitung berapa banyak jumlah total dari penjualan. Jadi benar-benar tidak perlu untuk menyimpan jumlah total.

Jadi mengapa itu disimpan di sini? Nah, karena itu adalah penjualan, dan harga produk dapat bervariasi dari waktu ke waktu. Sebuah produk dapat harga di 10 euro hari ini dan pada 8 euro bulan depan, dan untuk administrasi Anda, Anda perlu tahu apa yang biaya pada saat penjualan, dan cara termudah untuk melakukannya adalah dengan menyimpannya di sini. Ada banyak cara yang lebih elegan, tetapi untuk nerengkan hal tersebut saya kira terlalu mendalam untuk artikel ini.

Menyajikan Entitas dan Hubungan: Diagram (ERD)

Entity Relationship Diagram (ERD) memberikan gambaran grafis dari database. Ada beberapa tipe dan jenis Diagram ER. Sebuah notasi yang banyak digunakan adalah 'crowfeet' notasi, di mana entitas yang direpresentasikan sebagai persegi panjang dan hubungan antara entitas yang direpresentasikan sebagai garis antara entitas. Tanda-tanda di ujung garis menunjukkan jenis hubungan. Sisi hubungan yang wajib bagi yang lain untuk eksis akan ditunjukkan melalui dasbor di telepon. Tidak entitas wajib ditunjukkan melalui lingkaran. "Banyak" ditunjukkan melalui 'crowfeet'; de hubungan-line terpecah dalam tiga baris.

No comments

Pengenalan Terhadap Desain Database Part1

Artikel / tutorial ini akan mengajarkan dasar design database relasional dan menjelaskan bagaimana membuat design database yang baik. Ini adalah teks yang agak panjang dan terbagi menjadi beberapa bagian, tapi kami sarankan untuk membaca semua itu. Merancang database sebenarnya cukup mudah, tetapi ada beberapa aturan yang perlu untuk diketahui. Hal ini penting untuk mengetahui apa aturan ini, tetapi yang lebih penting adalah untuk mengetahui mengapa aturan-aturan yang ada, jika tidak, anda akan cenderung membuat kesalahan!

Standardisasi membuat model data Anda fleksibel dan yang membuat bekerja dengan data Anda jauh lebih mudah. Silakan, meluangkan waktu untuk mempelajari aturan-aturan dan menerapkannya! Database yang digunakan dalam artikel ini dirancang dengan design database yang digunakan sebagai pemodelan alat untuk Database.

Sebuah design database yang baik dimulai dengan daftar data yang ingin Anda sertakan dalam database Anda dan apa yang Anda ingin bisa melakukan dengan database nanti. Ini semua dapat ditulis dalam bahasa Anda sendiri, tanpa SQL. Pada tahap ini Anda harus mencoba untuk tidak berpikir dalam tabel atau kolom, tapi hanya berpikir: "Apa yang saya perlu tahu?" Jangan mengambil terlalu sedikit, karena jika Anda menemukan kemudian bahwa Anda lupa sesuatu, biasanya Anda perlu mulai dari awal. Menambahkan hal ke database Anda adalah sebagian besar dari banyak pekerjaan.

Mengidentifikasi Entitas

Jenis-jenis informasi yang disimpan dalam database yang disebut 'entitas'. Entitas ini ada di empat jenis: orang, benda, peristiwa, dan lokasi. Segala sesuatu yang Anda inginkan untuk dimasukkan ke dalam database cocok dengan salah satu kategori. Jika informasi yang ingin Anda sertakan tidak cocok dengan kategori ini, daripada mungkin bukan entitas tetapi milik entitas, atribut.

Untuk memperjelas informasi yang diberikan dalam artikel ini kita akan menggunakan contoh. Bayangkan bahwa Anda sedang menciptakan sebuah website untuk toko, jenis informasi apa yang Anda harus berurusan dengan? Di toko Anda menjual produk Anda kepada pelanggan. The "Toko" adalah lokasi, "Sale" adalah suatu peristiwa, "Produk" hal-hal, dan "Pelanggan" adalah orang-orang. Ini semua entitas yang perlu dimasukkan dalam database Anda.

Tapi apa hal-hal lain yang terjadi saat menjual produk? Seorang pelanggan datang ke toko, mendekati vendor, mengajukan pertanyaan dan mendapatkan jawaban. "Vendor" juga berpartisipasi, dan karena vendor adalah orang-orang, kita perlu entitas vendor.

Mengidentifikasi Hubungan atau Relationship

Langkah selanjutnya adalah menentukan hubungan antara entitas dan menentukan kardinalitas setiap hubungan. Hubungan adalah hubungan antara entitas, seperti di dunia nyata: apa satu kesatuan dengan yang lain, bagaimana mereka berhubungan satu sama lain? Misalnya, pelanggan membeli produk, produk yang dijual kepada pelanggan, penjualan terdiri dari produk, penjualan terjadi di toko.

Kardinalitas menunjukkan berapa banyak dari satu sisi hubungan milik berapa banyak sisi lain dari hubungan. Pertama, Anda perlu menyatakan untuk setiap hubungan, berapa banyak dari satu sisi milik tepat 1 dari sisi lain. Misalnya: Berapa banyak pelanggan milik 1 penjualan; Berapa banyak penjualan milik 1 pelanggan, Berapa banyak penjualan terjadi dalam 1 toko???

Anda akan mendapatkan daftar seperti ini: (harap dicatat bahwa 'produk' merupakan jenis produk, tidak terjadinya suatu produk)

Pelanggan -> Penjualan, pelanggan dapat membeli 1 kali sesuatu yang beberapa
Penjualan -> Pelanggan, 1 dijual selalu dibuat oleh 1 customer pada saat itu
Pelanggan -> Produk, 1 pelanggan dapat membeli beberapa produk
Produk -> Pelanggan, 1 produk dapat dibeli oleh pelanggan beberapa
Pelanggan -> Toko; 1 pelanggan dapat membeli di toko-toko beberapa
Toko -> Pelanggan, 1 toko dapat menerima beberapa pelanggan
Toko -> Produk, dalam 1 toko ada beberapa produk
Produk -> Toko; 1 produk (tipe) dapat dijual di beberapa toko
Toko -> Penjualan, dalam 1 toko penjualan beberapa bisa saya membuat
Penjualan -> Toko; 1 dijual hanya dapat dilakukan dalam 1 toko pada saat itu
Produk -> Penjualan, 1 produk (tipe) dapat dibeli dalam penjualan beberapa
Penjualan -> Produk, 1 penjualan dapat ada di luar dari beberapa produk

Apakah kita menyebutkan semua hubungan? Ada empat entitas dan entitas masing-masing memiliki hubungan dengan setiap entitas lain, sehingga setiap entitas harus memiliki tiga hubungan, dan juga muncul di ujung kiri dari hubungan tiga kali. Di atas, 12 hubungan yang disebutkan, yaitu 4 * 3, sehingga kita dapat menyimpulkan bahwa semua hubungan yang disebutkan.

No comments

Design Database dan Pengembangan sebuah Database Plan

Saat sedang melakukan design database membutuhkan pemahaman tentang fungsi bisnis yang Anda inginkan untuk menjadi model. Hal ini juga memerlukan pemahaman tentang konsep database dan fitur yang ingin Anda gunakan untuk mewakili fungsi-fungsi bisnis. Pastikan bahwa Anda secara akurat melakukan design database untuk model bisnis, karena bisa memakan waktu untuk secara signifikan mengubah design database setelah Anda menerapkannya. Sebuah database yang dirancang dengan baik mampu menghasilkan design database yang baik pula.

Langkah pertama dalam mendesign database adalah menciptakan sebuah rencana yang berfungsi baik sebagai panduan untuk digunakan saat mengimplementasikan database dan sebagai spesifikasi fungsional untuk database setelah di implementasikan. Kompleksitas dan detail dari design database ditentukan oleh kompleksitas dan ukuran dari aplikasi database dan juga populasi pengguna.

Sifat dan kompleksitas aplikasi database, serta proses perencanaan itu, dapat bervariasi secara signifikan. Sebuah database dapat relatif sederhana dan dirancang untuk digunakan oleh satu orang, atau dapat menjadi besar dan kompleks dan dirancang, misalnya, untuk menangani semua transaksi perbankan untuk ribuan klien. Dalam kasus pertama, design database mungkin sedikit lebih dari beberapa catatan di atas kertas awal. Dalam kasus terakhir, design database mungkin menghabiskan ratusan dokumen resmi dari panjang halaman yang berisi setiap detail yang mungkin tentang database.

Dalam perencanaan design database, terlepas dari ukuran dan kompleksitas, menggunakan langkah-langkah dasar berikut:

- Mengumpulkan informasi.
- Mengidentifikasi objek.
- Model objek.
- Identifikasi jenis informasi untuk setiap objek.
- Mengidentifikasi hubungan antara objek.

* mengumpulkan Informasi untuk design database

Sebelum membuat database, Anda harus memiliki pemahaman yang baik tentang pekerjaan yang berkaitan dengan database yang diharapkan untuk bisa dilakukan terutama ketika melakukan design database. Jika database adalah untuk mengganti sistem informasi berbasis kertas atau dilakukan secara manual, sistem yang ada akan memberikan sebagian besar informasi yang Anda butuhkan. Anda harus mewawancarai semua orang yang terlibat dalam sistem untuk menentukan apa yang mereka lakukan dan apa yang mereka butuhkan dari database. Hal ini juga penting untuk mengidentifikasi apa yang mereka inginkan dan yang bisa dilakukan oleh sistem baru, dan juga untuk mengidentifikasi masalah, keterbatasan, dan hambatan dari sistem yang ada. Mengumpulkan salinan laporan pelanggan, daftar inventaris, laporan manajemen, dan dokumen lainnya yang merupakan bagian dari sistem yang ada, karena ini akan berguna untuk Anda dalam merancang database dan interface.

* Mengidentifikasi Objects

Selama proses mengumpulkan informasi, Anda harus mengidentifikasi objek kunci atau badan yang akan dikelola oleh database. Objek dapat menjadi hal yang nyata, seperti seseorang atau produk, atau dapat menjadi item yang lebih berwujud, seperti transaksi bisnis, departemen dalam suatu perusahaan, atau suatu periode penggajian. Ada umumnya obyek utama beberapa, dan setelah ini diidentifikasi, item terkait menjadi terlihat. Setiap item yang berbeda dalam database Anda harus memiliki tabel terkait.

Tujuan utama dalam database contoh AdventureWorks2008R2 yang disertakan dengan database SQL Server adalah mengenai sepeda. Benda-benda yang berhubungan dengan sepeda dalam bisnis perusahaan ini adalah karyawan yang memproduksi sepeda, vendor yang menjual komponen yang digunakan untuk memproduksi sepeda, pelanggan yang membelinya, dan transaksi penjualan yang dilakukan dengan pelanggan. Masing-masing benda adalah tabel dalam database.

* Pemodelan Objek pada design database

Sebagai obyek dalam sistem diidentifikasi, Anda harus merekam mereka dengan cara yang merupakan sistem visual. Anda dapat menggunakan model database Anda sebagai referensi selama pelaksanaan database.

Untuk tujuan ini, pengembang database menggunakan alat yang mempunyai berbagai kompleksitas teknis dari pensil dan kertas awal untuk pengolah kata dan spreadsheet, dan bahkan untuk program perangkat lunak yang dibuat khusus untuk pekerjaan pemodelan data untuk desain basis data. Apapun alat yang Anda putuskan untuk menggunakannya, penting bahwa Anda tetap up to date.

* Mengidentifikasi Jenis Informasi untuk Tiap Object saat Design Database

Setelah objek utama dalam database telah diidentifikasi sebagai kandidat untuk tabel, langkah berikutnya adalah mengidentifikasi jenis-jenis informasi yang harus disimpan untuk setiap objek. Ini adalah kolom dalam tabel objek. Kolom dalam tabel database mengandung jenis umum beberapa informasi:

Kolom data mentah
Kolom ini menyimpan potongan nyata dari informasi, seperti nama, ditentukan oleh sumber eksternal ke database.

kolom kategoris
Kolom ini mengklasifikasikan atau mengelompokkan data dan menyimpan pilihan terbatas data seperti benar / salah, menikah / lajang, dan VP / Direktur / Group Manager.

kolom identifier
Kolom ini menyediakan mekanisme untuk mengidentifikasi setiap item yang disimpan dalam tabel. Kolom ini sering memiliki ID atau nomor atas nama mereka, misalnya, employee_id, invoice_number, dan PUBLISHER_ID. Kolom identifier adalah komponen utama yang digunakan oleh kedua pengguna dan pengolahan basis data internal untuk mendapatkan akses ke baris data dalam tabel. Kadang-kadang objek memiliki bentuk nyata dari ID yang digunakan dalam tabel, misalnya, nomor jaminan sosial, tetapi dalam kebanyakan situasi Anda dapat menentukan tabel sehingga handal, ID buatan dapat dibuat untuk baris.

Kolom relasional atau referensial
Kolom ini membentuk hubungan antara informasi dalam satu table dan informasi terkait di table lain. Sebagai contoh, sebuah table yang melacak transaksi penjualan akan umumnya memiliki link ke table pelanggan sehingga informasi pelanggan yang lengkap dapat dikaitkan dengan transaksi penjualan.

* Mengidentifikasi Hubungan Antara Objek saat Melakukan Design Database

Salah satu kekuatan dari sebuah database relasional adalah kemampuan untuk berhubungan atau mengaitkan informasi tentang berbagai item dalam database. Jenis terisolasi informasi dapat disimpan secara terpisah, tapi mesin database dapat menggabungkan data bila diperlukan. Mengidentifikasi hubungan antara objek dalam proses desain membutuhkan melihat tabel, menentukan bagaimana mereka secara logis terkait, dan menambahkan kolom relasional yang membangun link dari satu table ke table yang lain.

Misalnya, perancang database AdventureWorks2008R2 telah menciptakan table untuk produk dan model produk dalam database. Tabel Production.Product berisi informasi untuk setiap produk yang mencakup kolom identifier bernama ProductID, kolom data untuk nama produk, harga produk, dan warna produk, ukuran, dan berat. Tabel berisi kolom kategoris, seperti Class, atau Gaya, yang memungkinkan produk dikelompokkan berdasarkan jenis ini. Setiap produk juga memiliki model produk, tetapi informasi yang disimpan di tabel lain. Oleh karena itu, tabel Production.Product memiliki kolom ProductModelID untuk menyimpan hanya ID dari model produk. Ketika baris data ditambahkan untuk suatu produk, nilai untuk ProductModelID harus ada dalam tabel Production.ProductModel.

Rerefensi: MSDN 

No comments