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 .
Yang membedakan database open sourcePostgreSQL dengan database open source MySQL yaitu kekuatan OO (Object Oriented). Di database open source ini / database PostgreSQL, kita bisa mendeskripsikan suatu tabel yang mewarisi pengertian tabel lain yang bisa kita katakana sebagai object oriented. Umpamanya, ada tabel Karyawan yang mempunyai field partyId serta currentSalary. Kita bisa mendeskripsikan tabel KaryawanDivisiA dengan cuma mendeskripsikan field penambahan postId serta ditambah klausa SQL INHERITS (Karyawan). Field-field lain bakal automatis di ambil dari tabel induknya, Karyawan. Bukan hanya tabel saja, jenis data baru juga bisa didefinisikan. Serta uniknya, database open sourcePostgreSQL juga mempunyai jenis data geometri (seperti titik, garis, lingkaran, poligon) yang barangkali bermanfaat untuk aplikasi ilmiah spesifik. Satu lagi, anehnya, database PostgreSQL yang notabene merupakan database open source memberikan kita kekuatan mendeskripsikan suatu field untuk array.
Dari sisi kekayaan SQL, beberapa pengembang database barangkali bakal lebih tergiur dengan database open source ini. Database PostgreSQL mempunyai nyaris semua sarana standard yang umumnya di idamkan : view (tabel virtual), trigger, subselect, stored procedure (dalam sebagian bhs), serta foreign key constraint. Database PostgreSQL juga mempunyai apa yang dimaksud dengan rule, yakni aksi custom yang dapat kita definisikan dieksekusi waktu suatu tabel di-INSERT, UPDATE, atau DELETE. System rule ini sangat mungkin bagi kita untuk menguasai bagaimana data kita dirubah atau di ambil. Umpamanya, kita bisa bikin suatu tabel mernjadi berbentuk append-only dengan bikin rule yang membatalkan dampak DELETE serta UPDATE. Atau kita dapat lakukan penelusuran data sebelum saat terjadinya pergantian pada tabel. Atau membuat perlindungan row spesifik supaya tak dapat di ambil datanya, dsb. Rule ini digunakan untuk mengimplementasi view. Walau demikian barangkali Anda butuh menghindari memakai rule dengan cara eksplisit lantaran sarana ini tak ada dalam standard (SQL92) database open source ini.
Lebih jauh tentang perbandingan MySQL serta PostgreSQL dimana keduanya merupakan database open source dapat dipandang di artikel MySQL vs PostgreSQL.
Usaha Database Open Source Juga
Keluarga Ingres/Postgres sudah melahirkan sebagian perusahaan penjual product komersial yang sukses—meski pada saat ini semua perusahaan itu sudah dimakan oleh raksasa IBM/Microsoft serta CA. Lisensi Ingres/Postgres/Postgres95/PostgreSQL memanglah dari dahulu sangat liberal dan mengusung nafas database open source, ala BSD. Berarti, dibanding dengan GPL yang mewajibkan product turunan jadi GPL juga, maka lisensi Postgres membolehkan kita menggunakan product itu untuk maksud apapun, terhitung mengemas serta menjualnya untuk product komersial yang closed-source. Syaratnya cuma dua : pertama, nama penulis aslinya terus dijelaskan ; serta ke-2, pengembang awal—termasuk University of California, Berkeley—dibebaskan dari semua tanggung jawab yang berlangsung disebabkan oleh pemakaian software.
Diawal th. 2000, suatu perusahaan bernama Landmark Communications Inc. di Amerika membangun Great Bridge, yang mempunyai tujuan meningkatkan suatu versus PostgreSQL komersial untuk di jual, yang tentu saja sangat berbeda dengan keinginan awal PostgreSQL sebagai database open source. Great Bridge merekrut Bruce Momjian jadi wakil presiden di perusahaan itu. Diluar itu dua pengembang inti PostgreSQL yang lain juga turut berhimpun. Keseluruhan tim lebih kurang 25 orang.
Gerakan ini diikuti lebih kurang setahun lalu oleh Red Hat, distributor Linux paling besar. Pada mulanya Frank Batten, satu diantara investor di Red Hat serta yang lalu jadi komisaris di Great Bridge, sudah merekomendasikan supaya Red Hat masuk pasar database dari akhir 1999. Tetapi saat itu Red Hat mengambil keputusan tidak untuk masuk ke dalam persaingan dengan Oracle serta IBM, hingga pada akhirnya Frank juga keluar. Tetapi bln. Juni 2001, Red Hat menyebutkan bakal meluncurkan product serta jalan keluar database open source. Database yang bakal digunakan tetap dirahasiakan saat itu, namun banyak yang telah dapat menebak bahwasanya PostgreSQL-lah yang bakal digunakan. Benar saja, pada mulanya memanglah Red Hat telah pernah menghubungi Great Bridge untuk mendiskusikan kemungkinan kerja sama (Red Hat mensubkontrak Great Bridge). Tetapi perundingan tidak berhasil, serta Red Hat pada akhirnya membuat tim sendiri dibawah judul Red Hat Database Project. Maksudnya, turut meningkatkan PostgreSQL serta tawarkan jalan keluar database open source komersial.
Sayangnya, komersialisasi database open source kelihatannya tidak, atau belum, sukses. Sesudah 16 bulan beroperasi serta tak membuahkan pemasukan yang cukup, pada akhirnya pada bulan September 2001 Great Bridge tutup. Ini menunjukkan kepada kita kembali bahwasanya pasar database yaitu pasar yang konvensional apalagi untuk database open source yang dikomersialisasi, yang belum bakal mengambil suatu hal yang baru dengan cara cepat. Bukan hanya artinya database open source tak dapat dikomersilkan, cuma saja. Serta juga bukan hanya artinya PostgreSQL tidak berhasil dengan cara komersial. Product ini sudah¬ digunakan dengan cara meluas di industri ; cuma saja, untuk masuk ke pasar komersial diperlukan saat serta kesabaran. Tetap ada Red Hat dengan RHDB-nya, dan pada akhirnya kita tetap menanti bagaimana prospek usaha itu.
Pertengahan 1996, nama Postgres95 sudah kadaluwarsa, maka lahirlah database PostgreSQL (baca : post-grés-kju-él), dengan label versus diawali dari angka 6. 0 (versus paling akhir dari Postgres/Berkeley yaitu 4. 2, serta Postgres95 dikira versus 5. x). Di sinilah, serta juga berlanjut di keluarga 7. 0–7. 1, banyak berlangsung penambahan dalam hal skalabilitas, feature, serta kecepatan untuk database open source ini.
Walau demikian, perbaikan database open source ini berjalan tak dengan cara tiba-tiba, tetapi berangsur-angsur. Beberapa pengembangnya butuh terutama dahulu tetap butuh mengatur kode-kode lama serta kode yang belum seutuhnya dipahami. Sampai versus 6. 4 (1998) misalnya—di mana banyak ditambahkan feature baru seperti support ciri-ciri internasional, bahasa stored procedure baru, view, serta sebagian sintaks SQL tambahan—banyak berlangsung persoalan mengenai issue kestabilan pada database open source ini.
Sebagian pengguna melaporkan menggerakkan sistem server database PostgreSQL yang lalu dengan cara misterius tiba-tiba mati tiada laporan apa-apa di log—alias crash. Beberapa yang lain melaporkan diskonek dengan cara acak. Serta beberapa lagi mengeluhkan kurang memuaskannya kemampuan database PostgreSQL. Juga ada pengguna yang membelot ke database MySQL. Periode ini adalah saat-saat yang cukup mencemaskan untuk popularitas database PostgreSQL. Misalnya, tengok saja www. phpbuilder. com/columns/tim20000705. php3 dimana Tim Perdue menceritakan bahwasanya di th. 1999, ia terpaksa berpindah ke database MySQL dalam membeangun SourceForge. Kemampuan database PostgreSQL terlampau tidak sama dengan database MySQL hingga pemakai setia database PostgreSQL ini mesti harus bertukar database open source yang lain.
Versus 6. 5 menurut pengembang database PostgreSQL adalah babak baru pemahaman mereka pada total source code PostgreSQL sebagai database open source. Versus ini dapat dikatakan sebagai versus perbaikan bug yang utama ; terdapat beberapa bug seperti beragam masalah crash, kebocoran memori, serta kejanggalan/kekurangan pada sintaks SQL-nya diperbaiki. Diluar itu, di versus 6. 5 pada database open source ini ditambahkan MVCC oleh Vadim, yang punya potensi menambah kemampuan database PostgreSQL dengan cara penting. MVCC, atau Multi Version Concurrency Control, sama dengan InnoDB pada database MySQL dalam hal memberikan kekuatan database PostgreSQL yang menunjukkan kian lebih satu versus penampilan data untuk klien. Pergantian data yang di buat oleh klien yang tengah melakukan transaksi tak lagi tampak dahulu oleh klien lain sebelum saat transaksi dicommit. Hal Ini tentunya bisa menghindari locking yg tidak dibutuhkan.
Versus 6. 5. x (1999, seri paling akhir dari 6. x) cukup sukses serta memuaskan untuk beberapa pemakainya. Tetapi tetap terdapat banyak kekurangan database PostgreSQL yang dirasakan mengganjal untuk beberapa orang. Kekurangan-kekurangan database open source ini makin lama diperbaiki di seri 7. x, serta menurut Bruce Momjian, di seri 7. 3 ia mengharapkan database PostgreSQL bakal seutuhnya layak serta sepadan dengan database komersial dalam hal feature utama. Satu terbatasnya yang paling menjengkelkan yakni ukuran data maksimum suatu field cuma 8–32KB. Ini mengakibatkan orang susah menaruh teks panjang atau gambar didalam database open source ini. Terbatasnya kemampuan database open source / database PostgreSQL ini pada akhirnya dihapuskan di 7. 1. Menambahkan feature utama yang lain diantaranya foreign key constraint (ditambahkan di 7. 0), write-ahead logging untuk penambahan keamanan serta kemampuan (7. 1), dan OUTER JOIN pada database open source yang kenal sebagai database PostgreSQL ini. Tetap ada lagi feature seperti replikasi yang gagasannya bakal ditambahkan sesudah database PostgreSQL versi 7. 2.
Pemakai setia database PostgreSQL bisa berbangga dengan seri 7. x. Di seri ini database PostgreSQL mulai menantang database open source yang lain serta juga mengungguli database MySQL dalam hal kecepatan, terlebih di query-query kompleks serta pada keadaan load tinggi. Dalam artikelnya Tim Perdue melaporkan hasil benchmark database MySQL 3. 23 serta database PostgreSQL 7. 0 serta kesimpulannya yaitu : database PostgreSQL memanglah sudah jadi makin baik. Serta kecepatannya cukup mempesona. Database open source ini juga Stabil.
Versi teranyar database PostgreSQL waktu artikel ini ditulis yakni 9.3. database PostgreSQL di kembangkan dengan siklus launching lebih kurang 4 bln.,. Sampai saat ini, diantara pengembang inti database PostgreSQL yang paling aktif diantaranya Thomas, Vadim, Tom Lane (AS), Tatsuo Ishii (Jepang), Hiroshi Inoue (Jepang), Philip Warner (Australia), serta Bruce Momjian (AS).
Apakah anda sudah mencoba untuk menggunakan database open source ini ?
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.
DBMS (Data Base Management System) yakni perangkat lunak yang menangani semua pengaksesan database. Secara fungsi, data base management system atau dbms mempunyai fasilitas mengintegrasikan, terhubung, merekayasa dan memelihara basis data.
1. Menurut C. J. Date : Data Base Management System (DBMS) adalah software yang menghandel semua akses pada database untuk melayani keperluan user.
2. Menurut S, Attre : Data Base Management System (DBMS) yaitu software, hardware, firmware serta procedure-procedure yang memanage database. Firmware yaitu software yang sudah jadi modul yang tertanam pada hardware (ROM).
3. Menurut Gordon C. Everest : Data Base Management System (DBMS) yaitu manajemen yang efisien untuk mengorganisasi sumber daya data.
Pengertian Data Base Management System (DBMS)
Jadi Data Base Management System (DBMS) : Seluruh peralatan computer (Hardware+Software+Firmware). Data Base Management System (DBMS) dilengkapi dengan bhs yang bertujuan pada data (High level data language) yang kerap dimaksud juga untuk bhs generasi ke 4 (fourth generation language).
FUNGSI Data Base Management System (DBMS)
1. Data Definition, Data Base Management System (DBMS) mesti bisa memproses pendefinisian data
2. Data Manipulation, Data Base Management System (DBMS) mesti bisa mengatasi keinginan dari pengguna untuk terhubung data
3. Data Security & Integrity, Data Base Management System (DBMS) mesti dapatmemeriksa security serta integrity data yang didefinisikan oleh
DBA
4. Data Recovery & Concurency, Data Base Management System (DBMS) mesti bisa mengatasi kegagalan–kegagalan pengaksesan database
yang bisa dikarenakan oleh sesalahan system, rusaknya disk, dsb.
5. Data Dictionary, Data Base Management System (DBMS) mesti sediakan data dictionary.
6. Performance, Data Base Management System (DBMS) mesti mengatasi unjuk kerja dari seluruh manfaat seefisien barangkali.
Peralatan untuk mengambil keputusan/memastikan pendekatan database dimaksud DBMS.
Data Base Management System (DBMS) adalah software (serta hardware) yang kusus didesain membuat perlindungan serta memanage database.
Pengertian Data Base Management System (DBMS)
Dengan memakai Data Base Management System (DBMS), maka bisa :
- Mendeskripsikan data serta hubungan.
- Mendokumentasikan susunan serta pengertian data
- Melukiskan, mengorganisasikan serta menaruh data untuk akses yang selektif/diambil serta efektif.
- Jalinan yang seperti pada user dengan sumber daya data.
- Perlindungan pada sumber daya data bakal terjamin, bisa dihandalkan, berkelanjutan serta benar.
- Memisahkan persoalan Logical serta physical hingga mengubah implementasi database dengan cara fisik tak menginginkan user untuk mengubah maksud data (Logical).
- Memastikan pembagian data pada beberapa user untuk terhubung dengan cara concurent pada sumber daya data.
Perumpamaan Data Base Management System (DBMS) :
1. Database Hierarchy : Pengaksesan data mesti ikuti aturan hierarchy yang telah didefinisikan terlebih dulu.
Perumpamaan : IMS-2 (Information Management Sistem) oleh IBM, 1968
2. Data Network : Data membuat jaringan yang lebih bebas dari jenis hierarchy.
3. Data Relational : Data dikelompokkan dengan cara bebas menurut macamnya melalui proses
normalisasi
Sample Database :
- INGRES oleh UN of CA & Relational Tech., 1973
- System-R oleh IBM Research, 1975
- ORACLE oleh Relational Software Inc., 1979
- DBASE II oleh Ashton-Tate, 1981
Pengertian Data Base Management System (DBMS)
KOMPONEN Data Base Management System (DBMS)
Satu DBMS (Data Base Management System) umumnya memiliki sebagian komponen fungsional (modul) seperti :
1. File Manager, yang mengelola area dalam disk serta susunan data yang digunakan untuk merepresentasikan
info yang tersimpan dalam disk.
2. Database Manager, yang sediakan interfaceantara data low-level yang ada di basis data denganprogram
aplikasi serta query yang didapatkan ke system.
3. Query Processor, yang menterjemahkan perintahperintah dalam query language ke perintah low-level yang
bisa dipahami oleh database manager.
4. DML Precompiler, yang mengkonversi perintah DMLyang ditambahkan dalam suatu program aplikasi
kepemangin prosedur normal dalam bhs induk.
5. DDL Compiler, yang mengkonversi perintah-perintahDDL ke dalam sekumpulan tabel yang mengandung
metadata. Tabel-tabel ini lalu disimpan dalam kamus data.
Keuntungan Serta Kerugian PemakaianData Base Management System (DBMS)
Pengunaan Data Base Management System (DBMS) untuk mengelola data memiliki sebagian keuntungan,
yakni :
- Kebebasan data serta akses yang efisien
- Mereduksi saat pengembangan aplikasi
- Integritas serta keamanan data
- Administrasi keseragaman data
- Akses berbarengan serta perbaikan dari terjadinya crashes (tabrakan dari sistem serentak).
- Kurangi data redundancy : Data redundansi bisa direduksi/dikurangi, namun tak bisa di hilangkan sekalipun (untuk keperluan keyfield)
- Memerlukan sedikit memory untuk penyimpanan data.
Pengertian Data Base Management System (DBMS)
Kerugian pengunaanData Base Management System (DBMS) diantaranya :
Beroleh piranti lunak yang mahal (tehnologi DBMS, Operation, Conversion, Planning, Risk). DBMS mainframe tetap benar-benar mahal. Data Base Management System (DBMS) berbasis mikro biayanya meraih sebagian ratus dolar, bisa melukiskan satu organisasi yang kecil dengan cara yang berarti memperoleh konfigurasi piranti keras yang besar.
Data Base Management System (DBMS) kerap membutuhkan kemampuan penyimpanan primer serta sekunder yang semakin besar dari pada yang dibutuhkan oleh program aplikasi lain. Juga, kemudahan yang di buat oleh DBMS dalam mengambil info mendorong semakin banyak terminal pengguna yang diikutkan dalam konfigurasi dari pada bila sebaliknya.
Mempekerjakan serta menjaga staf DBA Data Base Management System (DBMS) membutuhkan pengetahuan spesial supaya bisa memakai kekuatan dengan cara penuh. Pengetahuan spesial ini paling baik didapatkan dari pengelola database.
Pada saat sekarang ini. Administrasi Data Base Management System (DBMS) selain dilakukan dengan bahasa PL/SQL, ada juga yang melakukannya dengan metode bahasa no sql. Anda penasaran dengan nosql Data Base Management System (DBMS) ? Nantikan ulasan-ulasan menarik lainnya mengenai Data Base Management System (DBMS) di blog ini. Ingin menyebarkan ulasan pengertian Data Base Management System (DBMS) kepada rekan anda? Atau anda bisa juga mendownload artikel pengertian Data Base Management System (DBMS) dalam bentuk pdf file.
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.
