Em primeiro lugar, recomendo vivamente o artigo científico em que o Dr. Edgar Frank Codd publicou o quadro relacional para o público em geral em 1970, ou seja, A Relational Model of Data for Large Shared Data Banks . Lá, na seção 1.1, “Introdução”, o próprio Dr. Codd afirma que:

Este artigo trata da aplicação da teoria elementar das relações a sistemas que fornecem acesso compartilhado a grandes bancos de dados formatados.

---

_{© Association for Computing Machinery. Comunicações da ACM , Volume 13, Edição 6 (pp. 377-387), junho de 1970.}

Então, sim, os termos relação e (portanto) relacional vêm de uma base matemática. Dr. Codd —que, além de suas credenciais acadêmicas e de pesquisa, tinha cerca de 20 anos de experiência em computação e processamento de informações— vislumbrou as enormes vantagens de aplicar a relação (uma construção abstrata, naturalmente) no campo da administração de dados .

Não sou matemático mas, basicamente falando, uma relação é uma associação entre conjuntos , sendo um conjunto uma coleção de elementos ( esse recurso externo dá uma definição de relação matemática que pode ajudar a compreendê-la de uma perspectiva diferente). Ao trabalhar com o auxílio de um sistema gerenciador de banco de dados SQL (DBMS para abreviar), uma aproximação bem conhecida de uma relação é uma tabela , caso em que a associação ocorre entre os tipos de suas colunas . Evidentemente, em plataformas SQL que oferecem suporte a DOMAIN (por exemplo, Firebird e PostgreSQL ), a associação ocorre entre odomínios fixados para as colunas da tabela em questão; consulte as seções abaixo para obter detalhes significativos.

A esse respeito, vou citar novamente o Dr. Codd, que na seção 1.3, “Uma visão relacional dos dados”, afirma que:

O termo relação é usado aqui em seu sentido matemático aceito. Dados os conjuntos S ₁ , S ₂ , ⋯ , S _n , (não necessariamente distintos), R é uma relação nestes n conjuntos se for um conjunto de n -tuplas cada uma das quais tem seu primeiro elemento de S ₁ , seu segundo elemento de S ₂ e assim por diante. ¹ Vamos nos referir a S _j como o j - ésimo domínio de R . Como definido acima, R é dito ter grau n. As relações de grau 1 são freqüentemente chamadas de unárias , binárias de grau 2, ternárias de grau 3 e n -árias de grau .

_{¹ Mais concisamente, R é um subconjunto do produto cartesiano S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Association for Computing Machinery. Comunicações da ACM , Volume 13, Edição 6 (pp. 377-387), junho de 1970.}

E concordo com outras respostas em que é muito relevante salientar que o Dr. Codd fez algumas adaptações na relação matemática para tirar o máximo proveito dela em relação ao gerenciamento de dados, e elas são explicadas no artigo mencionado anteriormente e ao longo de sua extensa bibliografia .

Relação e relacionamento

Uma situação que vale a pena trazer à tona é que, ao lidar com esses assuntos, pode surgir confusão devido às semelhanças que existem em relação às definições cotidianas (não matemáticas, não técnicas) dos termos relação e relacionamento —que, como não falante nativo de inglês, acho particularmente compreensível—.

A visão entidade-relacionamento e o modelo relacional

Outro fator que acho que também pode causar confusão (e está intimamente associado às conotações técnicas dos dois termos mencionados acima) é que, ao aprender a projetar bancos de dados, um estudante ou profissional é tipicamente apresentado pela primeira vez à metodologia proposta pelo Dr. . Peter Pin-Shan Chen na visão entidade-relacionamento de dados (publicada em 1976), que sugere dois implementos diferentes (ou seja, a entidade e o relacionamento ) para delinear um esquema conceitual , e então, somente após a definição do referido esquema é estável, o aluno ou praticante é apresentado a termos e instrumentos relacionais (por exemplo, a relação ) ao declarar olayout lógico do banco de dados pertinente. Dentro do quadro de referência conceitual, relacionamento guarda conotações muito mais próximas do sentido cotidiano da palavra.

Então, talvez, essa circunstância também acrescente à questão da relação e do relacionamento —mas a sequência de primeiro definir o esquema conceitual e, posteriormente, declarar o desenho lógico correspondente é, obviamente, bastante apropriada, como detalharei nas próximas seções—.

Respostas para cada uma de suas subperguntas

Considero que ter incluído essas três subquestões é realmente pertinente porque elas estabelecem um contexto mais amplo para o post, portanto não devem ser negligenciadas. Dessa forma, além de abordar exclusivamente por que os termos relação e relacional são usados ​​(o que certamente é muito significativo e é o título do post, mas não é o post inteiro ), as referidas subquestões podem auxiliar na compreensão mais ampla do a relação e o modelo relacional quando se está envolvido em todo um projeto de gerenciamento de informações (bastante relevante, pois este é um site sobre administração de banco de dados) e, portanto, está trabalhando em diferentes níveis de abstração. Desta forma, vou compartilhar minha opinião sobre esses detalhes abaixo.

Subquestão nº. 1

Por que, por exemplo, uma Pessoa é considerada uma "relação"? Em inglês, uma relação é um substantivo que descreve como duas entidades estão associadas. Não se refere às próprias entidades. No contexto de bancos de dados relacionais, "relação" refere-se às próprias entidades. Por quê?

Nível conceitual

Em um determinado ambiente de negócios, Person pode ser considerado um tipo de entidade dependendo de como as pessoas que trabalham lá (especialistas em negócios e designers de banco de dados) o conceituam . E, sim, nesse ambiente de negócios, pode haver diferentes propriedades de interesse em relação ao tipo de entidade Person , por exemplo, Name , BirthDate , Gender , etc.

Além disso, o tipo de entidade Person pode conter certos tipos de relacionamento (ou associação ou conexão ) consigo mesmo ou com outros tipos de entidade; por exemplo, Person pode estar associado a um tipo de entidade chamado UserProfile , que por sua vez pode ter suas próprias propriedades de interesse, digamos, Username e Password .

Mas, (a) os tipos de entidade, (b) suas propriedades correspondentes, (c) os tipos de relacionamento entre os tipos de entidade e (d) os relacionamentos entre as próprias propriedades são noções que “pertencem” ao ambiente de negócios específico no qual estão inseridos. considerado significativo. São dispositivos usados ​​por designers de banco de dados que trabalham em estreita colaboração com especialistas de negócios para definir um esquema conceitual específico ao contexto , na fase de design.

Assim, no nível conceitual trabalhamos basicamente com a estrutura das ideias que surgem no segmento de interesse do mundo real, ou seja, (1) protótipos de coisas e (2) protótipos de relacionamentos entre protótipos de coisas , não trabalhamos com (3) relações —empregando este último termo no sentido do quadro relacional de dados—.

Nível lógico

Depois que Person foi precisamente delineado como um tipo de entidade no nível conceitual, e se alguém quiser implementar um banco de dados relacional que transmita o significado de Person e todos os conceitos associados a ele, então os fatos sobre entidades desse tipo podem ser gerenciados em virtude de uma relação matemática no nível lógico e tirar vantagem das operações baseadas na ciência que podem ser executadas nessa construção abstrata (ou seja, defini-la, restringi-la e manipulá-la).

Sim, pode-se nomear uma determinada relação Pessoa ao definir o arranjo lógico de um banco de dados, mas isso não transforma o conceito de Pessoa do “mundo real” em uma relação, aborda-se como tal por causa dos benefícios que são obtidos ao gerenciar informações sobre ele, por exemplo, aplicando operações de álgebra relacional nele para derivar novas relações (e, portanto, está-se derivando “novas” informações). Tais benefícios tornam-se mais evidentes levando-se em conta que as entidades de um determinado tipo compõem um conjunto, e os valores de uma determinada propriedade também compõem um conjunto.

E, sim, como mencionado nos parágrafos anteriores e também em outras respostas, um dos aspectos primordiais de uma relação é a conexão que existe entre seus domínios - que são normalmente usados ​​para representar as propriedades de tipos de entidade ou associação que fazem parte de um esquema conceitual—. Por exemplo, digamos que declaramos a seguinte relação (ternária):

• Salary (PersonNumber, EffectiveDate, Amount)

...e vamos supor que, no ambiente de negócios em questão, a tupla —que (i) representa uma entidade particular , ou seja, uma instância de um tipo de entidade do esquema conceitual aplicável, e (ii) cuja contraparte SQL é um linha —

• Salary (x, y, z)

… levaria o significado

• “O Salário pago à Pessoa identificada por PersonNumber xem EffectiveDate ycorresponde ao Valor de z” .

Assim —para descrever as coisas de maneira aproximada—, a conexão entre os três domínios é de primordial importância, eles estão todos relacionados (e, sim, uma relação unária envolveria apenas um domínio). A conexão entre todos os valores de um determinado domínio também é muito significativa, pois constituem um conjunto de tipo preciso . Além disso, o conteúdo de cada tupla da Salaryrelação deve caber na estrutura da asserção ilustrada acima.

Relações de nível conceitual e relações de nível lógico

Conforme demonstrado, agora lidei com gerenciamento de banco de dados em dois níveis diferentes de abstração, a saber, conceitual e lógico — e ainda há um nível inferior conhecido como físico , que em SGBDs SQL normalmente envolve, por exemplo, índices, páginas, extensões, etc.—.

Assim, de acordo com as noções explicadas anteriormente, no nível lógico trabalha-se exclusivamente com (a) relações matemáticas, onde (b) as relações ou associações conceituais são representadas por (c) os valores contidos nas tuplas de tais relações matemáticas, e esses valores são geralmente delimitados por restrições FOREIGN KEY para que possam representar os relacionamentos aplicáveis ​​com precisão.

E, sim, entidades associativas , isto é, instâncias de tipos de relacionamento com uma razão de cardinalidade muitos-para-muitos (M:N), podem ser transmitidas por meio das tuplas de uma única relação matemática — com as restrições correspondentes declaradas apropriadamente, de curso-.

Subquestão nº. 2

Entendo que o modelo relacional veio depois dos modelos hierárquico e de rede. Mas nesses modelos, as entidades também têm relações entre si. Então, por que chamar esse modelo de modelo relacional? Existe uma frase/termo mais específico? Ou talvez devêssemos dizer que todos os três modelos são modelos relacionais, mas os modelos hierárquicos e de rede são tipos específicos de modelos relacionais?

SGBDs de rede e hierárquicos precederam seu suporte teórico formal

É oportuno destacar que o suporte teórico em torno das abordagens hierárquica e de rede foi, de fato, criado em termos de SGBDs já existentes , com o objetivo de, entre outros aspectos, testar e estabelecer a solidez de (1) ditos tipos de software e (2) as práticas de gerenciamento de dados vinculados —um fenômeno invertido, do meu ponto de vista—.

Incompleto em comparação com o framework relacional

Dito isto, embora existam DBMSs hierárquicos e de rede que antecedem o modelo relacional, e mesmo quando o Dr. Codd se refere a cada uma dessas abordagens como um “modelo”, nenhuma é definida como tal da mesma forma que a estrutura relacional. O paradigma relacional fornece construtos científicos para a (i) definição, (ii) restrição e (iii) manipulação de dados, e as abordagens hierárquicas e de rede carecem de suporte teórico completo para cobrir todos os três tipos de construtos mencionados anteriormente.

Recursos de rede e hierárquicos

Além disso, como dito anteriormente, os tipos de entidade e relacionamento são dispositivos de nível conceitual, não pertencem às abordagens hierárquicas ou de rede, cada uma das quais oferece mecanismos particulares para representar esses aspectos:

• O paradigma de rede envolve dois dispositivos para representação de dados, ou seja, nós e arcos (e essa característica obviamente implica dois tipos diferentes de operações de manipulação de dados) que, quando contrastado com o modelo relacional que (segundo o princípio da informação ) requer apenas uma construção (a relação), evidencia a complexidade desnecessária que o trabalho em rede envolve. Por exemplo, por recorrer a dois instrumentos de representação, a abordagem em rede impõe um viés de consulta impraticável que dificulta a manipulação dos dados.

• Por sua vez, a visão hierárquica propõe a representação dos dados por meio de arquivos (físicos!) formados por registros (que por sua vez consistem em campos ) organizados em um arranjo tríplice ; ou seja, um registro pai encadeado com possivelmente muitas contrapartes filho por meio de ponteiros , que produz um caminho de acesso físico com relação à manipulação de dados. Essa abordagem também é desfavorável porque apresenta um emaranhado entre aspectos conceituais e físicos, de modo que as mudanças nos arranjos de armazenamento físico exigem uma reorganização das estruturas de dados, o que, por sua vez, exige mudanças nas operações de manipulação de dados.

Como mostrado, as visões hierárquica e de rede impõem seus construtos sobre os dados a serem gerenciados, enquanto o modelo relacional propõe administrar os dados de forma elegante em sua estrutura natural por meio de conjuntos de fatos associados (dos quais n tipos de conjuntos subsequentes, não previstos no momento ). a fase de projeto, pode ser derivada e assim por diante!).

O modelo relacional não possui submodelos

E, muito importante, nem a visão hierárquica nem a visão de rede são tipos específicos de modelos relacionais, são simplesmente outros paradigmas que alguém pode seguir para (a) construir SGBDs e (b) criar bancos de dados, mas tenha em mente que a visão hierárquica e as abordagens de rede são consideradas obsoletas há décadas.

Subquestão nº. 3

E se tivermos entidades independentes que não se relacionam umas com as outras. Diga, Pessoa, Porta e Árvore. O termo "relation(al)" ainda é aplicável?

Sim, é perfeitamente aplicável se alguém estiver (1) gerenciando informações sobre esses tipos de entidade por meio de relações matemáticas adaptadas e (2) realizando as operações relacionais aplicáveis ​​no nível lógico em um determinado banco de dados administrado com o suporte de um determinado SGBD relacional .

Não importa se, no nível conceitual, esses tipos de entidade não possuem tipos de relacionamento com outros tipos de entidade (e vale a pena notar que um tipo de entidade pode ter um relacionamento de razão de cardinalidade um para zero um ou muitos consigo mesmo), e assim não se está transmitindo nem impondo qualquer relação entre os valores das tuplas das relações em consideração.

O interessante por trás do 'banco de dados relacional' é que ele não se refere (principalmente) às relações entre tabelas, como você poderia esperar, mas se refere à relação de várias propriedades (colunas) em uma tupla. Um banco de dados relacional armazena essas tuplas como uma linha em uma tabela.

É baseado na álgebra relacional definida por Alfred Tarski em seu artigo de 1941(!) Sobre o cálculo das relações . Ele resumiu a história do termo e uso em lógica simbólica, mas definiu as operações que no final se tornaram a base do SQL.

Codd transformou isso em uma definição para o que pode ser entendido como um banco de dados relacional em seus 12 mandamentos .

O termo "relacional" vem da matemática e não tem nada a ver com relacionamentos entre entidades. Eu não sou um matemático (enquanto Codd tinha um PhD em Matemática) e, portanto, não vou elaborar, mas indicarei este artigo da wikipedia sobre relações binárias . A entrada da wikipedia em relação (bancos de dados) fornece detalhes adicionais sobre como Codd adaptou os conceitos matemáticos para aplicar ao gerenciamento de dados. Quanto ao motivo pelo qual essa estrutura matemática é chamada de relação, acho que tem a ver com a ideia de que existe uma "relação" entre os domínios que compõem a relação. A melhor fonte que conheço para entender melhor o pensamento original de Codd é Fabian Pascal'. Chris Date também escreveu extensivamente sobre o RDM e seu site do Terceiro Manifesto tem uma seção listando artigos e livros. Seu livro Relational Theory for Computing Professionals é uma boa introdução. Eu espero que isso ajude.

É um nome intuitivo quando você pensa neles com chaves naturais. Você pode pensar em um valor de célula como representando uma entidade.

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

• O nome do funcionário "Jane" está relacionado ao cargo "supervisor".
• O nome do funcionário "John" está relacionado ao chefe "Jane".
• O trabalho "caixa" está relacionado aos nomes dos funcionários "John", "Jesse" e "Jason".
• O trabalho "caixa" está relacionado aos chefes "Jane" e "Claire".

Você já aceitou uma resposta muito longa que tem a dizer muito sobre bancos de dados, mas deixe-me responder à pergunta que você realmente fez:

Por que o termo "relacional".

Porque uma tabela é uma instância concreta do objeto matemático "relação".

Let's see what Wikipedia has to say about the term "relation" (in mathematics, not RDBMS), and then translate it to databases:

Formally, a relation is a set of n-tuples of equal degree. Thus a binary relation is a set of pairs, a ternary relation a set of triples, and so forth. In the language of set theory, a relation between two sets is a subset of their Cartesian product.

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.

It continues with set theory. Remember that this is mathematics, so much more abstract than database stuff. The last sentence thus is

a relation between two sets is a subset of their Cartesian product.

This translates to a one table with two columns:

• Let's call column A "name". Its mathematical set A is the set of all (human) names.
• Column B I call "city". Its mathematical set B is the set of all cities.
• The cartesian product A x B (in mathematics) is a new set which contains of all pairs (a.k.a., tupels) (a, b) where a is a member of A, and b is a member of B. I.e., a is a name and b is a city. Examples would be (Alice, New York) or (Bob, Hollywood). But the cartesian product is not only a few of those, but all of them. A relation, to get to the point, is a subset of that cartesian product. In other words, the relation is (defined to be) any amount of pairs (a, b) where a is a name and b is a city, even none at all.

Now I hope all starts to make sense. In a RDBMS, the rows of a table simply pick out the subset of the cartesian product of all possible combinations in those columns. Which is, when using a RDBMS, completely trivial and irrelevant.

But since Computer Science, including relational databases, does have its roots in mathematics, we are blessed with the term "relational" here. It is wholly abstract and has nothing whatsoever to do with relationships between people or what have you.

As an aside, the term "relation" is also sometimes used for "association", and it's exactly the same (here, the underlying sets of the relation being themselves relations as described above (a.k.a., tables)).

N.B.: in mathematics, relations are not about databases, but are something like functions, just more general (please, all you mathematicians, don't start to nitpick now, we are in dba.SE, not math.SE; I am aware that this is the wrong way around :) ). A function like f(x)=x+1 also can be expressed as a set of tuples (1, 2), (2, 3), ..., but it can only have every number once, on the left hand of the tuple. I.e., this would not be a valid function: (1, 2), (1, 3), .... But the latter would be a valid relation; i.e., you can have a Bob in New York and a Bob in Hollywood.

Relational databases is based on the relational model of E.F.Codd. The relational algebra describes methods of how to query data. A relation is simply a subset of the crossproduct of some sets (domains).

Example

We have the following sets:

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

Further we have the sets of tuples

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 is a subset of

    DepIds x DepNames

and so it is a relation.

employees is a subset of

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

and so it is a relation, too.

It is evident how relations can be implemented by tables.

Why do mathematicians call a set of tuples a relation?

Usually such properties like '2 less than 3', '4 equals 4', '2 is between 1 and 3.4', '-1 is negative' are called relations.

The relation 'less than' on the set A={1, 2, 3} is defined by the subset

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

of

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

De maneira semelhante, outras relações podem ser vistas como um subconjunto de um produto cruzado. 'x menor que y', 'x igual a y' são relações binárias e, portanto, definidas por um conjunto de pares. 'x entre y e z' é uma relação ternária' e, portanto, definida por um conjunto de triplos. 'x é negativo' é uma relação unária e, portanto, definida por um conjunto de singletons.

O conjunto de tuplas de departamentos que definimos acima é uma relação binária, a relação de funcionários é uma relação 6-ária.