Pertama-tama, saya sangat merekomendasikan makalah ilmiah di mana Dr. Edgar Frank Codd menerbitkan kerangka relasional kepada masyarakat umum pada tahun 1970, yaitu, Model Data Relasional untuk Bank Data Bersama Besar . Di sana, di bagian 1.1, "Pendahuluan", Dr. Codd sendiri menyatakan bahwa:
Makalah ini berkaitan dengan penerapan teori hubungan dasar ke sistem yang menyediakan akses bersama ke bank besar data yang diformat.
© Asosiasi untuk Mesin Komputer. Komunikasi ACM , Volume 13, Edisi 6 (hal. 377-387), Juni 1970.
Jadi, ya, istilah relasi dan (karenanya) relasional berasal dari latar belakang matematika. Codd — yang, terlepas dari kemampuan akademis dan penelitiannya, memiliki sekitar 20 tahun pengalaman tangan pertama dalam komputasi dan pemrosesan informasi — memimpikan manfaat luar biasa dari penerapan hubungan (konstruksi abstrak, secara alami) di bidang administrasi data .
Saya bukan ahli matematika tetapi, pada dasarnya berbicara, hubungan adalah hubungan antara set , set menjadi kumpulan elemen ( sumber daya eksternal ini memberikan definisi hubungan matematika yang dapat membantu untuk memahaminya dari perspektif yang berbeda). Ketika bekerja dengan bantuan sistem manajemen database SQL (DBMS untuk singkatnya), terkenal pendekatan dari relasi adalah tabel , dalam hal asosiasi berlangsung antara jenis nya kolom . Jelas, dalam platform SQL yang menawarkan dukungan DOMAIN (misalnya, Firebird dan PostgreSQL ), hubungan terjadi antaradomain diperbaiki untuk kolom tabel yang dimaksud; lihat bagian di bawah ini untuk perincian yang signifikan.
Dalam hal itu, saya akan mengutip lagi Dr. Codd, yang dalam bagian 1.3, "Pandangan Relasional Data", menyatakan bahwa:
Istilah relasi digunakan di sini dalam pengertian matematika yang diterima. Set diberikan S 1 , S 2 , ⋯, S n , (tidak harus berbeda), R adalah relasi pada ini n set jika itu adalah satu set n -tuples masing-masing memiliki elemen pertama dari S 1 , unsur kedua dari S 2 , dan seterusnya. 1 Kami mengacu pada S j sebagai j th domain dari R . Sebagaimana didefinisikan di atas, R dikatakan memiliki derajat n. Hubungan derajat 1 sering disebut unary , derajat 2 biner , derajat 3 ternary , dan derajat n n-ary .
1 Secara lebih ringkas, R adalah bagian dari produk Cartesian S 1 × S 2 × S 3 ⋯ × S n .
© Asosiasi untuk Mesin Komputer. Komunikasi ACM , Volume 13, Edisi 6 (hal. 377-387), Juni 1970.
Dan saya setuju dengan jawaban lain dalam hal ini sangat relevan untuk menunjukkan bahwa Dr. Codd membuat beberapa adaptasi pada hubungan matematika untuk mendapatkan yang terbaik dari hal itu mengenai manajemen data, dan mereka dijelaskan dalam makalah yang disebut sebelum dan sepanjang daftar pustaka yang luas .
Relasi dan hubungan
Suatu situasi yang layak diangkat adalah bahwa, ketika berhadapan dengan mata pelajaran ini, mungkin timbul kebingungan karena kesamaan yang ada mengenai definisi keseharian (non-matematika, non-teknis) dari istilah relasi dan hubungan — yang, sebagai penutur asli bahasa Inggris, saya menemukan sangat dimengerti—.
Tampilan hubungan entitas dan model relasional
Faktor lain yang saya pikir mungkin juga menyebabkan kebingungan (dan terkait erat dengan konotasi teknis dari dua istilah yang dikemukakan di atas) adalah bahwa, ketika belajar merancang basis data, seorang siswa atau praktisi biasanya pertama kali diperkenalkan dengan metodologi yang diusulkan oleh Dr. Peter Pin-Shan Chen dalam pandangan hubungan entitas data (diterbitkan pada tahun 1976), yang menyarankan dua implementasi yang berbeda (yaitu entitas dan hubungan ) untuk menggambarkan skema konseptual , dan kemudian, hanya setelah definisi skema tersebut. stabil, siswa atau praktisi diperkenalkan dengan istilah dan instrumen relasional (misalnya, relasi ) ketika menyatakantata letak logis dari basis data yang bersangkutan. Dalam kerangka referensi konseptual, hubungan memiliki konotasi yang jauh lebih dekat dengan makna kata sehari-hari.
Kemudian, mungkin, keadaan itu juga menambah masalah hubungan dan hubungan - tetapi urutan pertama mendefinisikan skema konseptual dan kemudian menyatakan desain logis yang sesuai tentu saja cukup tepat, karena saya akan merinci dalam bagian berikut-.
Tanggapan untuk setiap pertanyaan Anda
Saya menganggap bahwa memasukkan ketiga sub-pertanyaan itu benar-benar relevan karena mereka membangun konteks yang lebih luas untuk pos tersebut, sehingga mereka tidak boleh diabaikan. Dengan cara ini, selain secara eksklusif menangani mengapa hal hubungan dan relasional digunakan (yang tentunya sangat signifikan dan merupakan judul posting, tetapi tidak pada seluruh posting), mengatakan subquestions dapat membantu dalam memahami lebih dari lingkup yang hubungan dan model relasional ketika seseorang terlibat dalam proyek manajemen seluruh informasi (cukup relevan karena ini situs tentang administrasi database) dan karena itu bekerja pada berbagai tingkat abstraksi. Dengan cara ini, saya akan membagikan pendapat saya tentang hal-hal di bawah ini.
No.pertanyaan no. 1
Mengapa, misalnya, Seseorang, dianggap sebagai "hubungan"? Dalam bahasa Inggris, relasi adalah kata benda yang menggambarkan bagaimana dua entitas dikaitkan. Itu tidak merujuk pada entitas itu sendiri. Dalam konteks database relasional, "relasi" mengacu pada entitas itu sendiri. Mengapa?
Tingkat konseptual
Dalam lingkungan bisnis tertentu, Person dapat dianggap sebagai tipe entitas tergantung pada bagaimana orang yang bekerja di sana (pakar bisnis dan perancang basis data) mengonseptualisasikannya . Dan, ya, dalam lingkungan bisnis itu, mungkin ada sifat - sifat menarik yang berbeda sehubungan dengan tipe entitas Orang , misalnya, Nama , Tanggal Lahir , Jenis Kelamin , dll.
Selain itu, Orang tipe entitas dapat memegang tertentu hubungan (atau asosiasi atau koneksi ) jenis dengan dirinya sendiri atau jenis entitas lainnya; misalnya, Orang dapat dikaitkan dengan jenis entitas yang bernama UserProfile , yang pada gilirannya mungkin memiliki sifat yang menarik, katakanlah, Nama Pengguna dan Kata Sandi .
Tetapi, (a) jenis-jenis entitas, (b) sifat-sifatnya yang sesuai, (c) jenis-jenis hubungan antara jenis-jenis entitas dan (d) hubungan-hubungan antara sifat-sifat itu sendiri adalah gagasan-gagasan yang “dimiliki” oleh lingkungan bisnis tertentu di mana mereka berada. dianggap penting. Mereka adalah perangkat yang digunakan oleh perancang basis data yang bekerja sama dengan para ahli bisnis untuk menentukan skema konseptual konteks-spesifik , pada tahap desain.
Jadi, pada level konseptual kita pada dasarnya bekerja dengan struktur ide-ide yang muncul dalam segmen kepentingan dunia nyata, yaitu, (1) prototipe hal-hal dan (2) prototipe hubungan antara prototipe hal-hal , kita tidak bekerja dengan (3) hubungan — menggunakan istilah terakhir ini dalam arti kerangka kerja relasional data—.
Tingkat logis
Setelah Person secara tepat digambarkan sebagai tipe entitas pada level konseptual, dan jika seseorang ingin mengimplementasikan database relasional yang menyampaikan makna Person dan semua konsep yang terkait dengannya, maka fakta-fakta tentang entitas dari tipe tersebut dapat dikelola berdasarkan kebajikan dari hubungan matematika pada tingkat logis , dan mengambil keuntungan dari operasi berbasis sains yang dapat dilakukan pada konstruksi abstrak (yaitu, mendefinisikan, membatasi dan memanipulasi itu).
Ya, seseorang dapat menamai Orang relasi tertentu ketika mendefinisikan pengaturan logis dari suatu basis data, tetapi itu tidak mengubah konsep "dunia nyata" dari Orang menjadi suatu relasi, seseorang mendekatinya karena manfaat yang diperoleh ketika mengelola informasi tentang hal itu, misalnya, menerapkan operasi aljabar relasional di atasnya untuk memperoleh hubungan baru (dan karena itu orang memperoleh informasi "baru"). Manfaat-manfaat tersebut menjadi lebih jelas dengan mempertimbangkan fakta bahwa entitas-entitas dari tipe tertentu membentuk suatu perangkat, dan nilai-nilai properti tertentu juga membentuk suatu perangkat.
Dan, ya, seperti yang disebutkan dalam paragraf sebelumnya dan dalam jawaban lain juga, salah satu aspek terpenting dari suatu hubungan adalah koneksi yang ada di antara domainnya — yang biasanya digunakan untuk mewakili properti entitas atau tipe asosiasi yang merupakan bagian dari skema konseptual—. Sebagai contoh, katakanlah kita telah mendeklarasikan relasi (ternary) berikut:
Salary (PersonNumber, EffectiveDate, Amount)
... dan mari kita anggap bahwa, dalam lingkungan bisnis yang dimaksud, tuple — yang (i) mewakili entitas tertentu , yaitu instance dari tipe entitas dari skema konseptual yang berlaku, dan (ii) yang merupakan mitra SQL-nya adalah baris -
... akan membawa maknanya
- "Gaji yang dibayarkan kepada Orang yang diidentifikasi oleh PersonNumber
xpada EffectiveDate ysesuai dengan Jumlah z" .
Oleh karena itu — untuk menggambarkan hal-hal dengan perkiraan — hubungan antara ketiga domain itu sangat penting, semuanya terkait (dan, ya, hubungan yang tidak disadari akan melibatkan satu domain saja). Koneksi di antara semua nilai dari domain tertentu juga sangat signifikan, karena mereka merupakan sekumpulan tipe yang tepat . Juga, isi masing-masing tupel Salaryrelasi harus sesuai dengan struktur pernyataan yang digambarkan di atas.
Konseptual tingkat hubungan dan logis tingkat hubungan
Seperti yang ditunjukkan, saya sekarang telah berurusan dengan manajemen database pada dua tingkat abstraksi yang berbeda, yaitu konseptual dan logis — dan masih ada tingkat yang lebih rendah yang dikenal sebagai fisik , yang dalam SQL DBMS biasanya melibatkan, misalnya, indeks, halaman, luasan, dll.
Jadi, sesuai dengan pengertian yang dijelaskan sebelumnya, pada tingkat logis seseorang bekerja secara eksklusif dengan (a) hubungan matematika, di mana (b) hubungan konseptual atau asosiasi diwakili oleh (c) nilai - nilai yang terkandung dalam tupel hubungan matematika tersebut, dan nilai-nilai tersebut biasanya dibatasi melalui batasan ASING sehingga mereka dapat mewakili hubungan yang berlaku secara akurat.
Dan, ya, entitas asosiatif , yaitu, contoh tipe hubungan dengan rasio kardinalitas banyak-ke-banyak (M: N), dapat disampaikan melalui tupel hubungan matematika tunggal — dengan batasan terkait yang dinyatakan secara tepat, dari tentu saja—.
Pertanyaan no. 2
Saya mengerti bahwa model relasional datang setelah model hierarkis dan jaringan. Tetapi dalam model-model itu, entitas juga memiliki hubungan satu sama lain. Jadi mengapa menyebut model ini model relasional? Apakah ada frasa / istilah yang lebih spesifik? Atau mungkin kita harus mengatakan bahwa ketiga model adalah model relasional, tetapi model hierarkis dan jaringan adalah tipe spesifik model relasional?
Jaringan dan DBMS hirarkis mendahului dukungan teoritis formal mereka
Adalah tepat untuk menunjukkan bahwa dukungan teoritis di sekitar pendekatan hierarkis dan jaringan , pada kenyataannya, dibuat dalam hal DBMS yang ada sebelumnya , dengan tujuan, di antara aspek-aspek lain, menguji dan membangun kesehatan (1) jenis-jenis tersebut. perangkat lunak dan (2) praktik manajemen data yang ditautkan — fenomena terbalik, dari sudut pandang saya—.
Tidak lengkap dibandingkan dengan kerangka kerja relasional
Yang sedang berkata, meskipun ada DBMS hirarkis dan jaringan yang mendahului model relasional, dan bahkan ketika Dr. Codd menyebut masing-masing pendekatan tersebut sebagai "model", tidak ada yang didefinisikan seperti itu dengan cara yang sama seperti kerangka relasional. Paradigma relasional menyediakan konstruksi ilmiah untuk (i) definisi, (ii) pembatasan dan (iii) manipulasi data, dan pendekatan hierarkis dan jaringan tidak memiliki dukungan teoritis penuh untuk mencakup ketiga jenis konstruksi yang disebutkan sebelumnya.
Fitur jaringan dan hierarkis
Juga, seperti yang dinyatakan sebelumnya, entitas dan tipe hubungan adalah perangkat tingkat konseptual, mereka tidak termasuk dalam pendekatan hierarki atau jaringan, yang masing-masing menawarkan mekanisme tertentu untuk mewakili aspek-aspek tersebut:
Paradigma jaringan mensyaratkan dua perangkat untuk representasi data, yaitu, node dan busur (dan karakteristik itu tentu saja menyiratkan dua jenis operasi manipulasi data) yang, ketika kontras dengan model relasional yang (sesuai dengan prinsip informasi ) hanya memerlukan satu konstruksi (Relasi), membuat jelas kerumitan yang tidak perlu yang bekerja dalam jaringan mode melibatkan Misalnya, mengingat bahwa ia menggunakan dua instrumen representasi, pendekatan jaringan memaksakan bias permintaan yang tidak praktis yang menghambat manipulasi data.
Untuk bagiannya, tampilan hierarki mengusulkan mewakili data dengan cara (fisik!) File yang terdiri dari catatan (yang pada gilirannya terdiri dari bidang ) yang diatur dalam pengaturan tiga-suka ; yaitu, satu catatan induk dirantai dengan kemungkinan banyak rekanan anak melalui pointer , yang menghasilkan jalur akses fisik berkaitan dengan manipulasi data. Pendekatan ini juga tidak menguntungkan karena menghadirkan keterikatan antara aspek konseptual dan fisik, sehingga perubahan dalam pengaturan penyimpanan fisik memerlukan reorganisasi struktur data, yang pada gilirannya menuntut perubahan dalam operasi manipulasi data terkait.
Seperti yang diperlihatkan, pandangan hierarkis dan jaringan memaksakan konstruknya pada data yang akan dikelola, sedangkan model relasional mengusulkan pengelolaan data secara elegan dalam struktur alaminya melalui serangkaian fakta terkait (dari mana n set jenis berikutnya, tidak diantisipasi pada fase desain, bisa diturunkan dan seterusnya!).
Model relasional tidak memiliki sub model
Dan, yang cukup penting, baik hierarki maupun tampilan jaringan bukanlah tipe spesifik dari model relasional, mereka hanyalah paradigma lain yang dapat diikuti seseorang untuk (a) membangun DBMS dan (b) membuat basis data, tetapi harap diingat bahwa hierarkis dan pendekatan jaringan dianggap usang selama beberapa dekade sekarang.
Pertanyaan no. 3
Bagaimana jika kita memiliki entitas mandiri yang tidak berhubungan satu sama lain. Katakan, Orang, Pintu, dan Pohon. Apakah istilah "hubungan (al)" masih berlaku?
Ya, itu sangat berlaku jika seseorang (1) mengelola informasi tentang jenis-jenis entitas dengan hubungan matematika yang disesuaikan dan (2) melakukan operasi relasional yang berlaku pada tingkat logis dalam database tertentu yang dikelola dengan dukungan DBMS relasional yang diberikan .
Tidak masalah jika, pada level konseptual, tipe entitas tersebut tidak memiliki tipe hubungan dengan tipe entitas lainnya (dan perlu dicatat bahwa tipe entitas dapat memiliki hubungan kardinalitas satu-ke-nol-satu-atau-banyak). dengan dirinya sendiri), dan dengan demikian seseorang tidak menyampaikan atau menegakkan hubungan apa pun antara nilai-nilai tupel hubungan yang sedang dipertimbangkan.
