Blog ini memfokuskan diri pada sharing dan belajar ilmu database, design database, implementasi database, database relational, dan tips sql database. Selain itu sebagai catatan pembelajaran penulis mengenai database sql dan database nosql
(Pengertian database server - Ilmu Database). Istilah Server database dapat merujuk pada hardware dan software yang digunakan untuk menjalankan database, sesuai dengan konteksnya. Pengertian database server sebagai perangkat lunak, server database adalah bagian back-end dari aplikasi database, mengikuti model client-server tradisional. Dalam pengertian database server, bagian back-end ini kadang-kadang disebut instance. Hal ini juga dapat merujuk ke komputer fisik yang digunakan untuk meng-host database. Pada pengertian database server, ketika disebutkan dalam konteks ini, database server biasanya merupakan high-end komputer khusus yang menjadi host database.
Pada pengertian database ini, perhatikan bahwa server database independen / terbebas atau terpisah dari arsitektur database. Database relasional, flat file, database non-relasional: semua arsitektur ini dapat ditampung pada server database.
Untuk pengertian database server yang lain adalah istilah yang digunakan untuk merujuk pada sistem back-end dari aplikasi database menggunakan arsitektur client / server. Pada pengertian database server sebagai back-end ini, kadang-kadang disebut database server, melakukan tugas-tugas seperti analisis data, penyimpanan, manipulasi data, pengarsipan, dan tugas-tugas non-pengguna lain yang spesifik.
Definisi Database Server berdasarkan Techopedia (Suatu pengertian database server yang lain)
Dalam model komputasi client-server pada pengertian database server, ada host khusus untuk menjalankan dan melayani sumber daya , biasanya satu atau lebih aplikasi perangkat lunak . Ada juga beberapa klien yang dapat terhubung ke server dan menggunakan sumber daya host dan ditawarkan oleh server ini .
Ketika mempertimbangkan database dalam model client-server , dalam pengertian database server ini bisa saja menjadi back-end dari aplikasi database ( hanya contoh saja) , atau mungkin komputer hardware yang meng-host database . Kadang-kadang , bahkan mungkin mengacu pada kombinasi dari kedua hardware dan software database.
Untuk mengetahui pengertian database server dalam instalasi kecil dan menengah , secara tipikal database server hardware akan juga menjadi bagian host server dari aplikasi software yang menggunakan database . Dalam pengertian database server untuk bank , misalnya , database server hardware akan menjadi host server database perangkat lunak dan aplikasi perangkat lunak bank . Aplikasi ini kemungkinan akan terhubung ke database melalui port tertentu dan menggunakan komunikasi antar-proses untuk login ke dan mengakses baris-baris data dalam database . Para pengguna di bank , duduk di komputer pribadi mereka , juga akan menggunakan modul klien dari aplikasi yang diinstal pada komputer mereka untuk terhubung ke database . Dalam contoh pengertian database server ini , sebenarnya ada dua model client-server yang dapat kita lihat : database dan aplikasi .
Database merupakan suatu subyek yang teramat utama. Tentunya anda setuju bukan? Apalagi apabila anda seorang ahli IT. Di dunia IT kita mengenal 2 macam database, database closed source dan database open source. Database ada di mana-mana—dari kita lahir, sekolah, bekerja, hingga pensiun. Semua kesibukan komputasi yaitu sekitar memproses data—data keuangan, data percobaan ilmiah, data statistik pengunjung. Tiada database maka akan banyak segi kehidupan yang bakal pincang serta pada akhirnya mati—perorangan, perusahaan, serta negara. Aplikasi apapun yang Anda bikin, tak tahu itu shopping cart, CRM, portal komune, webledger, yang menjadi jantungnya yaitu database.
Pasar untuk database juga sangat besar. Untuk memperoleh deskripsi, lihatlah Larry Ellison. Dari satu keluarga product saja, yakni Oracle, pria ini sukses mengeruk duit sampai jadi orang terdua paling kaya didunia sesudah Bill Gates—bahkan pernah satu hari menempati tampuk pertama pada waktu harga saham Microsoft turun. Nilai kekayaan dari bos Oracle ini sebesar US$ 43 milyar. Orang kelima terkaya di dunia ini berhasil meningkatkan kekayaannya US$ 7 miliar karena terdorong lonjakanlebih dari 20% nilai saham Oracle. Serta walau merajai kian lebih separuh market share untuk enterprise besar, sudah pasti Oracle bukan hanya hanya satu product yang ada untuk pemakai database, terutama di kelas kecil serta menengah.
Ukuran pasar database terutama untuk pasar bigdata th. 2017 diprediksikan meraih $47.5 milyar, serta sudah bertumbuh selalu kurang lebih 10% dari th. ke th. dengan cara berkelanjutan. Waktu ini pasar itu memanglah tetap didominasi oleh cuma sebagian pemain besar saja. Tak hanya Oracle sebagai brand paling top—dan product paling menguras kantong—terdapat juga Microsoft dengan SQL Servernya, IBM dengan DB2-nya, Sybase, NCR dengan product data mart/data warehousingnya, serta Borland dengan Interbasenya. Namun makin lama serta pasti, gerakan database open source mulai merasuki dunia perusahaan serta menggerogoti penjualan beberapa produk komersial ini. Sebagian database open source sudah ada dari bertahun-tahun lalu serta saat ini cukup masak untuk siap digunakan. Memanglah benar, belum ada database open source yang sematang atau selengkap Oracle dalam hal feature, namun : 1) tak semua orang perlu semua feature itu ; 2) tak semua orang mempunyai duit untuk beli Oracle hingga akhirnya melirik database open source. Database open source mulai ramai didorong oleh keperluan untuk turunkan cost serta menambah interoperabilitas, sebagian organisasi besar—komersial ataupun nonkomersial, sebutlah seperti NASA serta Yahoo! —mulai berpindah dari modus mahal ke modus gratis, karena ini perusahaan ini akhirnya menggunakan database open source. Dalam konsentrasi saat ini kita bakal berjalan-jalan serta melihat-lihat product database open source yang ada.
Kita semua tentunya sudah mahfum bahwa database yang saat ini paling menjadi trend center, terutama di perusahaan-perusahaan raksasa dan pemerintahan, pastinya kita akan mendengar nama “Oracle”. Begitu hebatnya nama ini, hingga untuk mendapatkannyapun kita perlu mengeluarkan biaya yang sangat-sangat besar di bandingkan dengan database-database yang lain. Tapi sebenarnya “what is oracle database?” Apakah database oracle itu, hingga sedemikian hebat kita mendengarnya?
Definisi – Apa sebenarnya yang dimaksud dengan Oracel Database ?
Database Oracle (Oracle DB) adalah sistem manajemen database relasional (RDBMS) dari Oracle Corporation. Awalnya dikembangkan pada tahun 1977 oleh Lawrence Ellison dan pengembang lainnya, Oracle DB merupakan salah satu mesin database relasional terbesar dan banyak digunakan yang saat ini ada di sunia. Sistem ini dibangun dengan kerangka database relasional di mana objek data yang dapat langsung diakses oleh pengguna (atau front end aplikasi) melalui bahasa query terstruktur (SQL). Oracle adalah arsitektur database relasional yang “full scalable” dan sering digunakan oleh perusahaan-perusahaan global, yang mengelola dan mengolah data melalui jaringan luas dan lokal. Database Oracle memiliki komponen jaringan sendiri untuk memungkinkan komunikasi di seluruh jaringan. Oracle DB juga dikenal sebagai Oracle RDBMS dan, kadang-kadang, hanya Oracle.
Oracle DB saat ini bersaing ketat dengan Microsoft SQL Server di pasar database yang dipergunakan di kalangan perusahaan. Ada persembahan database lain, tapi kebanyakan dari perintah ini pangsa pasar kecil dibandingkan dengan Oracle DB dan SQL Server. Untungnya, struktur Oracle DB dan SQL Server cukup mirip, yang merupakan suatu keuntungan tersendiri ketika belajar administrasi database. Oracle DB berjalan pada kebanyakan platform utama, termasuk Windows, UNIX, Linux dan Mac OS. Versi perangkat lunak yang berbeda tersedia, berdasarkan kebutuhan dan anggaran. Edisi dari Oracle DB secara hirarki dipecah sebagai berikut:
Enterprise Edition: Menawarkan semua fitur - termasuk kinerja yang unggul dan keamanan-dan yang paling kuat.
Edisi Standar: Berisi fungsi dasar untuk pengguna yang tidak memerlukan paket yang kuat Enterprise Edition ini.
Express Edition (XE): The ringan, Windows dan Linux edisi gratis dan terbatas.
Oracle Lite: Untuk perangkat mobile.
Fitur utama dari Oracle adalah bahwa arsitektur dibagi antara logis dan fisik. Struktur ini berarti bahwa untuk skala besar komputasi terdistribusi, juga dikenal sebagai komputasi grid, data lokasi tidak relevan dan transparan kepada pengguna, memungkinkan untuk struktur fisik lebih modular yang dapat ditambahkan ke dan diubah tanpa mempengaruhi aktivitas database, data, atau pengguna. Berbagi sumber daya dengan cara ini memungkinkan untuk jaringan data yang sangat fleksibel yang kapasitasnya dapat disesuaikan naik atau turun sesuai permintaan, tanpa penurunan layanan. Hal ini juga memungkinkan untuk sistem yang kuat harus dibuat karena tidak ada titik di mana kegagalan dapat menurunkan database skema jaringan sumber daya penyimpanan berarti bahwa setiap kegagalan akan terjadi hanya secara lokal.
Penjelasan Langsung dari Oracle
Database Oracle adalah kumpulan data yang diperlakukan sebagai satu unit. Tujuan utama dari dibentuknya database yaitu untuk menyimpan dan mengambil informasi yang terkait. Pada sebuah server database terdapat kunci yang digunakan untuk memecahkan masalah-masalah untuk pengelolaan informasi. Secara umum, server terpercaya untuk mengelola sejumlah besar data dalam lingkungan multiuser sehingga banyak pengguna secara bersamaan dapat mengakses data yang sama. Semua ini dilakukan dan bersamaan dengan hal itu juga memberikan kinerja tinggi. Sebuah server database juga mencegah akses tidak sah dan menyediakan solusi yang efisien untuk pemulihan apabila terjadi suatu kegagalan.
Advertisement
Oracle Database adalah database pertama yang dirancang untuk komputasi grid secara enterprise, cara yang paling fleksibel dan biaya yang efektif untuk mengelola informasi dan aplikasi. Perusahaan komputasi grid menciptakan penampungan besar (large pool) pada industri-standar, penyimpanan modular dan juga sekumpulan server. Dengan arsitektur ini, setiap sistem baru dapat dengan cepat ditetapkan dari kolam komponen. Tidak ada kebutuhan untuk beban kerja puncak, karena kapasitas pada oracle dapat dengan mudah untuk ditambahkan atau pun direalokasi dari tampungan sumber daya yang diperlukan.
Database memiliki struktur logis dan struktur fisik. Karena struktur fisik dan logis terpisah, maka secara umum penyimpanan fisik data bisa dikelola tanpa mempengaruhi akses ke struktur penyimpanan logis nya.
Ingin berdiskusi seputar oracle atau ada masukan untuk perbaikan web ini. Silahkan anda kirim komentar anda.. ?
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.
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.
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.
