In inglese, potremmo parlare della relazione tra, diciamo, Bob e Tim. Forse sono cugini. Il termine "relazione" in questo contesto ha senso per me.

Nel contesto dei database relazionali, capisco a cosa si riferisce il termine, ma non capisco perché sia ​​usato. Immagino che capire perché è usato mi aiuterà a capire meglio il campo, quindi mi piacerebbe capire perché è usato.

• Perché, ad esempio, una persona è considerata una "relazione"? In inglese, una relazione è un sostantivo che descrive come sono associate due entità. Non si riferisce alle entità stesse. Nel contesto dei database relazionali, "relazione" si riferisce alle entità stesse. Perché?
• Capisco che il modello relazionale è venuto dopo i modelli gerarchici e di rete (es. Genitore, vicino). Ma in quei modelli, le entità hanno anche relazioni reciproche. Quindi perché chiamare questo modello il modello relazionale? C'è una frase / termine più specifico? O forse dovremmo dire che tutti e tre i modelli sono modelli relazionali, ma i modelli gerarchici e di rete sono tipi specifici di modelli relazionali?
• E se avessimo entità autonome che non si relazionano tra loro. Dì, persona, porta e albero. Il termine "relazione (al)" è ancora applicabile?

(Forse questa dovrebbe essere una domanda multipla. Ho pensato che le risposte fossero altamente correlate - forse c'è solo una risposta - quindi ho pensato che avrebbe senso che questa fosse una singola domanda. Se sbaglio, fammi sapere e io creerò invece domande separate.)

Modifica: questo diagramma può essere utile per visualizzare che una relazione mette in relazione domini diversi tra loro:

Prima di tutto, consiglio vivamente il documento scientifico in cui il Dr. Edgar Frank Codd ha pubblicato il quadro relazionale per il grande pubblico nel 1970, vale a dire, Un modello relazionale di dati per grandi banche dati condivise . Lì, nella sezione 1.1, "Introduzione", lo stesso Dr. Codd afferma che:

Questo documento riguarda l'applicazione della teoria delle relazioni elementari ai sistemi che forniscono accesso condiviso a grandi banche di dati formattati.

---

_{© Associazione per macchine informatiche. Comunicazioni dell'ACM , volume 13, numero 6 (pagg. 377-387), giugno 1970.}

Quindi, sì, i termini relazione e (quindi) relazionale provengono da un background matematico. Il dott. Codd — che, a parte le sue credenziali accademiche e di ricerca, ha avuto circa 20 anni di esperienza diretta nell'informatica e nell'elaborazione delle informazioni— ha immaginato gli enormi vantaggi dell'applicazione della relazione (un costrutto astratto, naturalmente) nel campo dell'amministrazione dei dati .

Non sono un matematico ma, in sostanza, una relazione è un'associazione tra insiemi , un insieme essendo una raccolta di elementi ( questa risorsa esterna fornisce una definizione di relazione matematica che può aiutare a capirlo da una prospettiva diversa). Quando si lavora con l'aiuto di un sistema di gestione di database SQL (DBMS per brevità), una nota approssimazione di una relazione è una tabella , nel qual caso l'associazione si svolge tra i tipi delle sue colonne . Evidentemente, nelle piattaforme SQL che offrono supporto DOMAIN (ad esempio, Firebird e PostgreSQL ), l'associazione si verifica tradomini fissi per le colonne della tabella in questione; vedere le sezioni seguenti per dettagli significativi.

A tale proposito, citerò nuovamente il Dr. Codd, che nella sezione 1.3, "Una visione relazionale dei dati", afferma che:

Il termine relazione è usato qui nel suo senso matematico accettato. Dati gli insiemi S ₁ , S ₂ , ⋯, S _n , (non necessariamente distinti), R è una relazione su questi n insiemi se è un insieme di n -tuple ciascuno dei quali ha il suo primo elemento da S ₁ , il suo secondo elemento da S ₂ e così via. ¹ ci riferiremo a S _j come j esimo dominio di R . Come definito sopra, si dice che R abbia il grado n. Le relazioni di grado 1 sono spesso chiamate unarie , di grado 2 binarie , di grado 3 ternario e di grado n n-ary .

_{¹ Più concisamente, R è un sottoinsieme del prodotto cartesiano S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Associazione per macchine informatiche. Comunicazioni dell'ACM , volume 13, numero 6 (pagg. 377-387), giugno 1970.}

E sono d'accordo con altre risposte in quanto è molto rilevante sottolineare che il Dr. Codd ha apportato alcuni adattamenti alla relazione matematica al fine di ottenere il massimo da essa per quanto riguarda la gestione dei dati, e sono spiegati nel documento di cui sopra e in tutta la sua vasta bibliografia .

Relazione e relazione

Una situazione che merita di essere sollevata è che, quando si affrontano questi argomenti, può sorgere confusione a causa delle somiglianze esistenti per quanto riguarda le definizioni quotidiane (non matematiche, non tecniche) dei termini relazione e relazione , che, come non madrelingua inglese, trovo particolarmente comprensibile—.

La vista entità-relazione e il modello relazionale

Un altro fattore che penso possa anche causare confusione (ed è strettamente associato alle connotazioni tecniche dei due termini sopra menzionati) è che, quando si impara a progettare database, uno studente o un praticante viene in genere introdotto per la prima volta alla metodologia proposta dal dott. Peter Pin-Shan Chen nella visione dei dati entità-relazione (pubblicata nel 1976), che suggerisce due diversi strumenti (cioè l' entità e la relazione ) per delineare uno schema concettuale , e quindi, solo dopo la definizione di detto schema è stabile, lo studente o il professionista viene introdotto a termini e strumenti relazionali (ad esempio, la relazione ) quando dichiara illayout logico del database pertinente. All'interno del quadro concettuale di riferimento, la relazione mantiene connotazioni molto più vicine al senso quotidiano della parola.

Quindi, forse, questa circostanza si aggiunge anche alla questione della relazione e della relazione , ma la sequenza di definire innanzitutto lo schema concettuale e successivamente dichiarare il corrispondente disegno logico è ovviamente del tutto appropriata, come illustrerò in dettaglio nelle sezioni seguenti—.

Risposte a ciascuna delle tue domande

Ritengo che aver incluso queste tre domande sia davvero pertinente perché stabiliscono un contesto più ampio per il post, quindi non dovrebbero essere trascurati. In questo modo, oltre ad affrontare esclusivamente il motivo per cui i termini relazione e relazionale vengono utilizzati (che certamente è molto significativo ed è il titolo del post, ma è non è l' intera post), ha detto subquestions possono aiutare a comprendere più del campo di applicazione la relazione e il modello relazionale quando si è coinvolti in un intero progetto di gestione delle informazioni (abbastanza rilevante dal momento che si tratta di un sito sull'amministrazione del database) e quindi sta lavorando a diversi livelli di astrazione. In questo modo, condividerò la mia opinione su quei particolari di seguito.

Domanda n. 1

Perché, ad esempio, una persona è considerata una "relazione"? In inglese, una relazione è un sostantivo che descrive come sono associate due entità. Non si riferisce alle entità stesse. Nel contesto dei database relazionali, "relazione" si riferisce alle entità stesse. Perché?

Livello concettuale

In un determinato ambiente aziendale, Persona può essere considerata un tipo di entità a seconda di come le persone che vi lavorano (esperti di business e progettisti di database) lo concettualizzano . E, sì, in tale ambiente aziendale, potrebbero esserci diverse proprietà di interesse rispetto al tipo di entità Persona , ad esempio Nome , Data di nascita , Genere , ecc.

Inoltre, la persona tipo entità può possedere certa relazione (o associazione o connessione ) tipi con se stesso o altri tipi di entità; ad esempio, la Persona può essere associata a un tipo di entità denominato UserProfile , che a sua volta può avere le proprie proprietà di interesse, diciamo, Nome utente e Password .

Tuttavia, (a) i tipi di entità, (b) le proprietà corrispondenti, (c) i tipi di relazione tra i tipi di entità e (d) le relazioni tra le proprietà stesse sono nozioni che "appartengono" al particolare ambiente aziendale in cui si trovano ritenuto significativo. Sono dispositivi utilizzati dai progettisti di database che lavorano a stretto contatto con esperti di business al fine di definire uno schema concettuale specifico per il contesto , in fase di progettazione.

Pertanto, a livello concettuale, lavoriamo sostanzialmente con la struttura delle idee che sorgono nel segmento di interesse del mondo reale, ovvero (1) prototipi di cose e (2) prototipi di relazioni tra prototipi di cose , con cui non lavoriamo (3) relazioni —utilizzando quest'ultimo termine nel senso del quadro relazionale dei dati—.

Livello logico

Dopo che la Persona è stata delineata con precisione come un tipo di entità a livello concettuale e se si desidera implementare un database relazionale che trasmetta il significato di Persona e tutti i concetti ad essa associati, i fatti sulle entità di quel tipo possono essere gestiti in virtù di una relazione matematica a livello logico e trarre vantaggio dalle operazioni basate sulla scienza che possono essere eseguite su quel costrutto astratto (cioè, definirlo, vincolarlo e manipolarlo).

Sì, quando si definisce la disposizione logica di un database , si può nominare una determinata relazione Persona , ma ciò non trasforma il concetto di Persona nel mondo reale in una relazione, si accede ad essa in quanto tale a causa dei benefici che si ottengono quando si gestiscono le informazioni al riguardo, ad esempio, applicando operazioni di algebra relazionale su di esso per derivare nuove relazioni (e quindi si stanno ricavando "nuove" informazioni). Detti benefici diventano più evidenti tenendo conto del fatto che le entità di un certo tipo compongono un insieme e anche i valori di una determinata proprietà compongono un insieme.

E sì, come menzionato nei paragrafi precedenti e anche in altre risposte, uno degli aspetti fondamentali di una relazione è la connessione che esiste tra i suoi domini, che sono tipicamente usati per rappresentare le proprietà di entità o tipi di associazione che fanno parte di uno schema concettuale—. Ad esempio, diciamo che abbiamo dichiarato la seguente relazione (ternaria):

• Salary (PersonNumber, EffectiveDate, Amount)

... e supponiamo che, nell'ambiente aziendale in questione, la tupla - che (i) sta per una particolare entità , cioè un'istanza di un tipo di entità dallo schema concettuale applicabile, e (ii) la cui controparte SQL è un fila -

• Salary (x, y, z)

... porterebbe il significato

• "Lo stipendio pagato alla persona identificata da PersonNumber alla xdata effettiva ycorrisponde all'importo di z" .

Di conseguenza, per descrivere le cose in modo approssimativo, la connessione tra i tre domini è di primaria importanza, sono tutti correlati (e, sì, una relazione unaria coinvolgerebbe un solo dominio). Anche la connessione tra tutti i valori di un determinato dominio è molto significativa, in quanto costituiscono un insieme di un tipo preciso . Inoltre, il contenuto di ciascuna tupla della Salaryrelazione deve adattarsi alla struttura dell'asserzione sopra illustrata.

Concettuale a livello relazioni e logica a livello delle relazioni

Come dimostrato, ora ho affrontato la gestione del database a due diversi livelli di astrazione, vale a dire concettuale e logico, e c'è ancora un livello inferiore noto come quello fisico , che nei DBMS SQL coinvolge tipicamente, ad esempio, indici, pagine, estensioni, eccetera.-.

Quindi, in conformità con le nozioni spiegate prima, a livello logico si lavora esclusivamente con (a) relazioni matematiche, dove (b) le relazioni o le associazioni concettuali sono rappresentate da (c) i valori contenuti nelle tuple di tali relazioni matematiche, e detti valori sono generalmente delimitati da vincoli FOREIGN KEY in modo che possano rappresentare accuratamente le relazioni applicabili.

E, sì, entità associative , cioè istanze di tipi di relazione con un rapporto di cardinalità molti-a-molti (M: N), possono essere trasmesse per mezzo delle tuple di una singola relazione matematica, con i vincoli corrispondenti dichiarati appropriatamente, di corso-.

Domanda n. 2

Capisco che il modello relazionale è venuto dopo i modelli gerarchici e di rete. Ma in quei modelli, le entità hanno anche relazioni reciproche. Quindi perché chiamare questo modello il modello relazionale? C'è una frase / termine più specifico? O forse dovremmo dire che tutti e tre i modelli sono modelli relazionali, ma i modelli gerarchici e di rete sono tipi specifici di modelli relazionali?

I DBMS di rete e gerarchici hanno preceduto il loro supporto teorico formale

È opportuno sottolineare che il supporto teorico attorno agli approcci gerarchici e di rete è stato, infatti, creato in termini di DBMS precedentemente esistenti , con l'obiettivo, tra l'altro, di testare e stabilire la solidità di (1) detti tipi del software e (2) le pratiche di gestione dei dati collegate — un fenomeno capovolto, dal mio punto di vista—.

Incompleto rispetto al quadro relazionale

Detto questo, sebbene esistano DBMS gerarchici e di rete che precedono il modello relazionale, e anche quando il Dr. Codd si riferiva a ciascuno di quegli approcci come a un “modello”, nessuno viene definito come tale nello stesso modo in cui lo è il quadro relazionale. Il paradigma relazionale fornisce costrutti scientifici per la (i) definizione, (ii) limitazione e (iii) manipolazione dei dati, e gli approcci gerarchici e di rete mancano del pieno supporto teorico per coprire tutti e tre i tipi di costrutti precedentemente menzionati.

Funzionalità di rete e gerarchiche

Inoltre, come affermato in precedenza, l'entità e i tipi di relazione sono dispositivi a livello concettuale, non appartengono agli approcci gerarchici o di rete, ognuno dei quali offre meccanismi particolari per rappresentare detti aspetti:

• Il paradigma di rete prevede due dispositivi per la rappresentazione dei dati, vale a dire nodi e archi (e quella caratteristica ovviamente implica due diversi tipi di operazioni di manipolazione dei dati) che, se contrastate con il modello relazionale che (secondo il principio dell'informazione ) richiede un solo costrutto (la relazione), evidenzia la inutile complessità che comporta lavorare in rete. Ad esempio, dato che ricorre a due strumenti di rappresentazione, l'approccio di rete impone una distorsione imprecisa della query che ostacola la manipolazione dei dati.

• Da parte sua, la visione gerarchica propone di rappresentare i dati mediante file (fisici!) Costituiti da record (che a loro volta consistono in campi ) organizzati in una disposizione a tre ; vale a dire, un genitore record di incatenato, probabilmente, molti bambini controparti tramite puntatori , che produce un fisico percorso di accesso per quanto riguarda la manipolazione dei dati. Questo approccio è anche sfavorevole perché presenta un intreccio tra aspetti concettuali e fisici, quindi i cambiamenti nelle disposizioni di archiviazione fisica richiedono una riorganizzazione delle strutture di dati, che a sua volta richiede cambiamenti nelle relative operazioni di manipolazione dei dati.

Come mostrato, le viste gerarchiche e di rete impongono i loro costrutti sui dati da gestire, mentre il modello relazionale propone di amministrare i dati elegantemente nella sua struttura naturale per mezzo di serie di fatti associati (da cui n tipi successivi di serie, non previsti a la fase di progettazione, può essere derivata e così via!).

Il modello relazionale non ha modelli secondari

E, abbastanza importante, né le viste gerarchiche né quelle di rete sono tipi specifici di modelli relazionali, sono semplicemente altri paradigmi che qualcuno potrebbe seguire per (a) costruire DBMS e (b) creare database, ma per favore tenete presente che il gerarchico e gli approcci di rete sono considerati ormai obsoleti da decenni.

Domanda n. 3

E se avessimo entità autonome che non si relazionano tra loro. Dì, persona, porta e albero. Il termine "relazione (al)" è ancora applicabile?

Sì, è perfettamente applicabile se si sta (1) gestendo informazioni su quei tipi di entità a causa di relazioni matematiche adattate e (2) eseguendo le operazioni relazionali applicabili a livello logico in un determinato database gestito con il supporto di un dato DBMS relazionale .

Non importa se, a livello concettuale, detti tipi di entità non detengono tipi di relazione con altri tipi di entità (e vale la pena notare che un tipo di entità può avere una relazione di rapporto di cardinalità da uno a zero-uno-o-molti con se stesso), e quindi non si sta trasmettendo né applicando alcuna relazione tra i valori delle tuple delle relazioni in esame.

La cosa interessante dietro 'database relazionale' è che non si riferisce (principalmente) alle relazioni tra le tabelle, come ci si potrebbe aspettare, ma si riferisce alla relazione di più proprietà (colonne) in una tupla. Un database relazionale memorizza quelle tuple come una riga in una tabella.

Si basa sull'algebra relazionale definita da Alfred Tarski nel suo articolo del 1941 (!) Sul calcolo delle relazioni . Ha riassunto la storia del termine e dell'uso nella logica simbolica, ma ha definito le operazioni che alla fine sono diventate la base per SQL.

Codd lo ha trasformato in una definizione per quello che può essere compreso come un database relazionale nei suoi 12 comandamenti .

Il termine "relazionale" deriva dalla matematica e non ha nulla a che fare con le relazioni tra entità. Non sono un matematico (mentre Codd aveva un dottorato in Matematica) e quindi non elaborerò, ma ti indicherò questo articolo di Wikipedia sulle relazioni binarie . La voce di Wikipedia sulla relazione (database) fornisce ulteriori dettagli su come Codd ha adattato i concetti matematici da applicare alla gestione dei dati. Per quanto riguarda il motivo per cui questa struttura matematica è chiamata relazione, penso che abbia a che fare con l'idea che esista una "relazione" tra i domini che compongono la relazione. La migliore fonte che conosco per comprendere meglio il pensiero originale di Codd è Fabian Pascal '. Chris Date ha anche scritto ampiamente su RDM e il suo sito del Terzo Manifesto ha una sezione che elenca documenti e libri. Il suo libro Relational Theory for Computing Professionals è una buona introduzione. Spero che aiuti.

È un nome intuitivo quando ci pensi con le chiavi naturali. Puoi pensare a un valore di cella come a rappresentare un'entità.

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

• Il nome dell'impiegato "Jane" è correlato al lavoro "supervisore".
• Il nome dell'impiegato "John" è legato al capo "Jane".
• Il lavoro "cassiere" è legato ai nomi dei dipendenti "John", "Jesse" e "Jason".
• Il lavoro "cassiere" è legato ai capi "Jane" e "Claire".

Hai già accettato una risposta molto lunga che deve dire molto sui database, ma lasciami rispondere alla domanda che hai effettivamente posto:

Perché il termine "relazionale".

Perché una tabella è un'istanza concreta della "relazione" dell'oggetto matematico.

Vediamo cosa ha da dire Wikipedia sul termine "relazione" (in matematica, non su RDBMS), e poi traduciamo in database:

Formalmente, una relazione è un insieme di n-tuple di uguale grado. Quindi una relazione binaria è un insieme di coppie, una relazione ternaria un insieme di triple e così via. Nel linguaggio della teoria degli insiemi, una relazione tra due insiemi è un sottoinsieme del loro prodotto cartesiano.

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.

Continua con la teoria degli insiemi. Ricorda che questa è matematica, molto più astratta delle cose del database. L'ultima frase è quindi

una relazione tra due insiemi è un sottoinsieme del loro prodotto cartesiano.

Questo si traduce in un una tabella con due colonne:

• Chiamiamo la colonna A "nome". Il suo set matematico Aè l'insieme di tutti i nomi (umani).
• Colonna BI chiama "città". Il suo insieme matematico Bè l'insieme di tutte le città.
• Il prodotto cartesiano A x B(in matematica) è un nuovo set che contiene tutte le coppie (aka, tupels) di (a, b)cui aè membro Aed bè membro B. Cioè, aè un nome ed bè una città. Esempi sarebbero (Alice, New York)o (Bob, Hollywood). Ma il prodotto cartesiano non è solo alcuni di quelli, ma tutti . Una relazione, per arrivare al punto, è un sottoinsieme di quel prodotto cartesiano. In altre parole, la relazione è (definita come) qualsiasi quantità di coppie in (a, b)cui aè un nome ed bè una città, anche nessuna.

Ora spero che tutto inizi a dare un senso. In un RDBMS, le righe di una tabella selezionano semplicemente il sottoinsieme del prodotto cartesiano di tutte le possibili combinazioni in quelle colonne. Cioè, quando si utilizza un RDBMS, completamente banale e irrilevante.

Ma dal momento che informatica, compresi i database relazionali, non ha le sue radici nella matematica, siamo benedetti con il termine "relazionale" qui. È completamente astratto e non ha nulla a che fare con le relazioni tra le persone o che cosa hai.

A parte questo, il termine "relazione" è talvolta usato anche per "associazione", ed è esattamente lo stesso (qui, gli insiemi sottostanti della relazione sono essi stessi relazioni come sopra descritto (aka, tabelle)).

NB: in matematica, le relazioni non riguardano i database, ma sono qualcosa di simile a funzioni, solo più generali (per favore, tutti voi matematici, non iniziate subito a parlare, siamo in dba.SE, non in matematica.SE; lo so che questo è il modo sbagliato :)). Una funzione come f(x)=x+1anche può essere espressa come un insieme di tuple (1, 2), (2, 3), ..., ma può avere ogni numero solo una volta, sulla mano sinistra della tupla. Vale a dire, questo non sarebbe una funzione valida: (1, 2), (1, 3), .... Ma quest'ultima sarebbe una relazione valida; vale a dire, puoi avere un Bob a New York e un Bob a Hollywood.

I database relazionali si basano sul modello relazionale di EFCodd. L' algebra relazionale descrive i metodi per interrogare i dati. Una relazione è semplicemente un sottoinsieme del prodotto incrociato di alcuni insiemi (domini).

Esempio

Abbiamo i seguenti set:

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', ...}

Inoltre abbiamo le serie di tuple

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 è un sottoinsieme di

    DepIds x DepNames

e quindi è una relazione.

employees è un sottoinsieme di

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

e quindi è anche una relazione.

È evidente come le relazioni possano essere implementate dalle tabelle.

Perché i matematici definiscono una serie di tuple una relazione?

Di solito tali proprietà come "2 meno di 3", "4 è uguale a 4", "2 è compreso tra 1 e 3,4", "-1 è negativo" sono chiamate relazioni.

La relazione "minore di" sull'insieme A = {1, 2, 3} è definita dal sottoinsieme

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

di

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) } 

Allo stesso modo, altre relazioni possono essere viste come un sottoinsieme di un prodotto incrociato. 'x minore di y', 'x equivale a y' sono relazioni binarie e pertanto definite da un insieme di coppie. 'x tra y an z' è una relazione ternaria 'e quindi definita da una serie di triple. 'x is negative' è una relazione unaria e quindi definita da una serie di singoli.

Il set di tuple dei dipartimenti che abbiamo definito sopra è una relazione binaria, la relazione dei dipendenti è una relazione a 6 anni.