Dalam bahasa Inggris, kita mungkin berbicara tentang hubungan antara, katakanlah, Bob dan Tim. Mungkin mereka sepupu. Istilah "hubungan" dalam konteks ini masuk akal bagi saya.

Dalam konteks basis data relasional, saya mengerti apa yang dimaksud dengan istilah itu, tetapi saya tidak mengerti mengapa itu digunakan. Saya pikir memahami mengapa itu digunakan akan membantu saya untuk lebih memahami bidang, jadi saya ingin memahami mengapa itu digunakan.

• 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?
• Saya mengerti bahwa model relasional datang setelah model hierarkis dan jaringan (mis. Orang tua, tetangga). 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 dari model relasional?
• Bagaimana jika kita memiliki entitas mandiri yang tidak berhubungan satu sama lain. Katakan, Orang, Pintu, dan Pohon. Apakah istilah "hubungan (al)" masih berlaku?

(Mungkin ini harus beberapa pertanyaan. Saya pikir jawabannya sangat terkait - mungkin hanya ada satu jawaban - jadi saya pikir masuk akal untuk ini menjadi satu pertanyaan. Jika saya salah, beri tahu saya dan saya Akan membuat pertanyaan terpisah.)

Sunting: Diagram ini mungkin berguna untuk memvisualisasikan bahwa suatu relasi menghubungkan domain yang berbeda satu sama lain:

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 ₁ , S ₂ , ⋯, 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 ₁ , unsur kedua dari S ₂ , dan seterusnya. ¹ 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 -

• Salary (x, y, z)

... 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.

Hal yang menarik di balik 'database relasional' adalah, bahwa itu tidak (terutama) merujuk pada hubungan antara tabel, seperti yang Anda harapkan, tetapi mengacu pada hubungan beberapa properti (kolom) dalam sebuah tuple. Database relasional menyimpan tupel-tupel tersebut sebagai baris dalam sebuah tabel.

Ini didasarkan pada aljabar relasional yang didefinisikan oleh Alfred Tarski dalam makalahnya tahun 1941 (!) Tentang kalkulus hubungan . Dia merangkum sejarah istilah dan penggunaan dalam logika simbolik tetapi mendefinisikan operasi yang pada akhirnya menjadi dasar untuk SQL.

Codd mengubah ini menjadi definisi untuk apa yang dapat dipahami sebagai basis data relasional dalam 12 perintahnya .

Istilah "relasional" berasal dari matematika dan tidak ada hubungannya dengan hubungan antar entitas. Saya bukan ahli matematika (sedangkan Codd memiliki gelar PhD dalam bidang Matematika) dan tidak akan menjelaskan lebih lanjut, tetapi akan mengarahkan Anda ke artikel wikipedia ini tentang hubungan biner . Entri wikipedia tentang hubungan (database) memberikan detail tambahan tentang bagaimana Codd mengadaptasi konsep matematika untuk diterapkan pada manajemen data. Mengenai mengapa struktur matematika ini disebut relasi, saya pikir itu ada hubungannya dengan gagasan bahwa ada "hubungan" antara domain yang membentuk relasi. Sumber terbaik yang saya tahu untuk lebih memahami pemikiran asli Codd adalah Fabian Pascal '. Chris Date juga banyak menulis tentang RDM dan situs Manifes Ketiga- nya memiliki bagian yang memuat makalah dan buku. Bukunya Relational Theory for Computing Professionals adalah pengantar yang bagus. Saya harap ini membantu.

Itu nama intuitif ketika Anda memikirkannya dengan kunci alami. Anda dapat menganggap nilai sel sebagai representasi entitas.

Relation: Employee
|--------+------------+--------|
| name   | job        | boss   |
|--------+------------+--------|
| Mark   | owner      | NULL   |
| Bob    | manager    | Mark   |
| Jane   | supervisor | Bob    |
| Claire | supervisor | Bob    |
| John   | cashier    | Jane   |
| Jesse  | cashier    | Jane   |
| Jason  | cashier    | Claire |
|--------+------------+--------|

• Nama karyawan "Jane" terkait dengan "supervisor" pekerjaan.
• Nama karyawan "John" terkait dengan bos "Jane".
• Pekerjaan "kasir" terkait dengan nama-nama karyawan "John", "Jesse", dan "Jason".
• Pekerjaan "kasir" terkait dengan bos "Jane", dan "Claire".

Anda telah menerima jawaban yang sangat panjang yang banyak berbicara tentang database, tetapi izinkan saya menjawab pertanyaan yang sebenarnya Anda tanyakan:

Mengapa istilah "relasional".

Karena tabel adalah contoh konkret objek matematika "relasi".

Mari kita lihat apa yang dikatakan Wikipedia tentang istilah "hubungan" (dalam matematika, bukan RDBMS), dan kemudian terjemahkan ke basis data:

Secara formal, suatu relasi adalah seperangkat n-tuple dengan derajat yang sama. Jadi relasi biner adalah seperangkat pasangan, relasi terner seperangkat tripel, dan sebagainya. Dalam bahasa teori himpunan, hubungan antara dua himpunan adalah bagian dari produk Cartesius mereka.

Mathematics             | RDBMS
========================|===============
A relation is           | A table is
a set of                | a bunch of 
n-tuples                | rows
of equal degree.        | with the same cell (a.k.a. column) types and sizes.

Ini berlanjut dengan teori himpunan. Ingat bahwa ini adalah matematika, jauh lebih abstrak daripada hal-hal basis data. Kalimat terakhir adalah

hubungan antara dua set adalah bagian dari produk Cartesian mereka.

Ini diterjemahkan menjadi satu tabel dengan dua kolom:

• Mari kita sebut kolom "nama". Himpunan matematisnya Aadalah himpunan semua nama (manusia).
• Kolom BI memanggil "kota". Himpunan matematisnya Badalah himpunan semua kota.
• Produk kartesius A x B(dalam matematika) adalah himpunan baru yang berisi semua pasangan (alias, tupel) di (a, b)mana aanggota A, dan banggota B. Yaitu, aadalah nama dan bkota. Contohnya adalah (Alice, New York)atau (Bob, Hollywood). Tetapi produk kartesius tidak hanya beberapa di antaranya, tetapi semuanya . Suatu relasi, untuk sampai pada intinya, adalah bagian dari produk kartesius itu. Dengan kata lain, relasinya adalah (didefinisikan sebagai) jumlah pasangan (a, b)mana apun yang merupakan nama dan bkota, bahkan tidak ada sama sekali.

Sekarang saya berharap semua mulai masuk akal. Dalam RDBMS, baris-baris tabel cukup memilih subset dari produk kartesius dari semua kemungkinan kombinasi di kolom-kolom tersebut. Yaitu, saat menggunakan RDBMS, sepenuhnya sepele dan tidak relevan.

Tetapi karena Ilmu Komputer, termasuk basis data relasional, memang berakar pada matematika, kita diberkati dengan istilah "relasional" di sini. Ini sepenuhnya abstrak dan tidak ada hubungannya dengan hubungan antara orang atau apa pun dengan Anda.

Sebagai tambahan, istilah "relasi" juga kadang-kadang digunakan untuk "asosiasi", dan persis sama (di sini, himpunan relasi yang mendasarinya adalah relasi itu sendiri sebagaimana dijelaskan di atas (alias, tabel)).

NB: dalam matematika, hubungan bukan tentang basis data, tetapi sesuatu seperti fungsi, hanya lebih umum (tolong, semua yang Anda ahli matematika, jangan mulai nitpick sekarang, kami berada di dba.SE, bukan math.SE; Saya sadar bahwa ini adalah jalan yang salah :)). Fungsi seperti f(x)=x+1juga dapat diekspresikan sebagai satu set tupel (1, 2), (2, 3), ..., tetapi hanya dapat memiliki setiap angka sekali, di sebelah kiri tupel. Yaitu, ini tidak akan menjadi fungsi valid: (1, 2), (1, 3), .... Tetapi yang terakhir akan menjadi hubungan yang valid; yaitu, Anda dapat memiliki Bob di New York dan Bob di Hollywood.

Database relasional didasarkan pada model relasional EFCodd. The aljabar relasional menjelaskan metode bagaimana permintaan data. Suatu relasi hanyalah subset dari produk silang dari beberapa set (domain).

Contoh

Kami memiliki set berikut:

DepIds = {1, 2, 3, ...}
EmpIds = {1, 2, 3, ...}
DepNames = {'Engineering', 'Finance', 'Sales', ...}
FirstNames = {'John', 'Walter', 'Mary', 'Roxane', ...}
LastNames = {'Smith', 'Bondy', 'Taylor', ...}
BirthDates = {..., 1950-01-01, 1950-01-02, ...}
Jobs = {'Accountant', 'Programmer', 'Database Administrator', ...}

Selanjutnya kami memiliki set tupel

departements = { 
    (1, 'Engineering'), 
    (2, 'Finance')}
employees = { 
    (1, 1, 'John', 'Taylor', 1985-03-22, 'Programmer'), 
    (2, 1, 'Walter', 'Bondy', 1997-09-11, 'Database Administrator'), 
    (3, 2, 'Roxane', 'Myers', 1987-12-19, 'Accountant')}

departements adalah bagian dari

    DepIds x DepNames

dan itu adalah suatu hubungan.

employees adalah bagian dari

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

dan itu juga sebuah hubungan.

Jelaslah bagaimana hubungan dapat diimplementasikan oleh tabel.

Mengapa ahli matematika menyebut satu set tupel suatu relasi?

Biasanya sifat seperti '2 kurang dari 3', '4 sama dengan 4', '2 adalah antara 1 dan 3,4', '-1 adalah negatif' disebut relasi.

Relasi 'kurang dari' pada set A = {1, 2, 3} didefinisikan oleh subset

{(1, 2), (1, 3), (2, 3) }

dari

A x A = {1, 2, 3} x {1, 2, 3}=
{ (1, 1), (1, 2), (1, 3), 
  (2, 1), (2, 2), (2, 3), 
  (3, 1), (3, 2), (3, 3) } 

Dengan cara yang sama hubungan lain dapat dilihat sebagai bagian dari suatu produk silang. 'x kurang dari y', 'x sama dengan y' adalah hubungan biner dan oleh karena itu didefinisikan oleh seperangkat pasangan. 'x antara y an z' adalah hubungan terner 'dan oleh karena itu didefinisikan oleh seperangkat tiga kali lipat. 'x adalah negatif' adalah hubungan unary dan oleh karena itu didefinisikan oleh seperangkat lajang.

Kumpulan tupel departemen yang kami tetapkan di atas adalah relasi biner, relasi karyawan adalah relasi 6-ary.