Antes de tudo, recomendo vivamente o artigo científico em que o Dr. Edgar Frank Codd publicou a estrutura relacional ao público em 1970, ou seja, Um Modelo Relacional de Dados para Grandes Bancos de Dados Compartilhados . 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.
© Associação para Máquinas de Computação. Communications of the 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 um fundo matemático. O Dr. Codd - que, além de suas credenciais acadêmicas e de pesquisa, tinha cerca de 20 anos de experiência em primeira mão em computação e processamento de informações - previa 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, uma relação é uma associação entre conjuntos , um conjunto sendo uma coleção de elementos ( esse recurso externo fornece uma definição de relação matemática que pode ajudar a entendê-la de uma perspectiva diferente). Ao trabalhar com o auxílio de um sistema de gerenciamento de banco de dados SQL (DBMS por brevidade), uma aproximação bem conhecida de uma relação é uma tabela ; nesse caso, a associação ocorre entre os tipos de suas colunas . Evidentemente, nas plataformas SQL que oferecem suporte a DOMAIN (por exemplo, Firebird e PostgreSQL ), a associação ocorre entre osdomínios corrigidos para as colunas da tabela em questão; consulte as seções abaixo para obter detalhes significativos.
A esse respeito, citarei 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 1 , S 2 , ⋯, S n , (não necessariamente distintos), R é uma relação nesses n conjuntos se for um conjunto de n- pares, cada um dos quais com seu primeiro elemento de S 1 , seu segundo elemento de S 2 , e assim por diante. 1 Vamos referem-se a S j como o j th domínio de R . Como definido acima, R é dito ter grau n. Relações de grau 1 são frequentemente chamados unário , grau 2 binária , grau 3 ternário e grau n n-ária .
1 De maneira mais concisa, R é um subconjunto do produto cartesiano S 1 × S 2 × S 3 × S n .
© Associação para Máquinas de Computação. Communications of the ACM , Volume 13, Edição 6 (pp. 377-387), junho de 1970.
E eu concordo com outras respostas, pois é muito relevante ressaltar que o Dr. Codd fez algumas adaptações na relação matemática, a fim de tirar o máximo proveito 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 destacar é que, ao lidar com esses assuntos, pode haver confusão devido às semelhanças existentes 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 nativo de inglês, acho particularmente compreensível.
A visão de relacionamento da entidade 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 praticante é normalmente introduzido pela primeira vez na metodologia proposta pelo Dr. Peter Pin-Shan Chen, na visão de dados de relacionamento entre entidades (publicada em 1976), que sugere dois implementos diferentes (ou seja, a entidade e o relacionamento ) para delinear um esquema conceitual e, somente depois da definição do referido esquema. estável, o aluno ou profissional é apresentado a termos e instrumentos relacionais (por exemplo, a relação ) ao declarar olayout lógico do banco de dados pertinente. Dentro do quadro conceitual de referência, o relacionamento mantém conotações muito mais próximas do sentido cotidiano da palavra.
Então, talvez, essa circunstância também seja acrescentada à questão da relação e do relacionamento - mas a sequência de definir primeiro o esquema conceitual e posteriormente declarar o design lógico correspondente é obviamente bastante apropriada, como detalharei nas seções a seguir -.
Respostas para cada uma das suas subquestões
Considero que a inclusão dessas três subquestões é realmente pertinente porque elas estabelecem um contexto mais amplo para o cargo, portanto não devem ser negligenciadas. Desta forma, além de abordar exclusivamente porque os termos relação e relacional são utilizados (o que certamente é muito significativo e é o título do post, mas é não a toda post), disse subquestões pode ajudar a compreender mais do âmbito de a relação e o modelo relacional quando alguém está envolvido em um projeto completo de gerenciamento de informações (bastante relevante por ser um site sobre administração de banco de dados) e, portanto, está trabalhando em diferentes níveis de abstração. Dessa maneira, vou compartilhar minha opinião sobre os detalhes abaixo.
Subquestion no. 1 1
Por que, por exemplo, uma Pessoa é considerada uma "relação"? Em inglês, uma relação é um substantivo que descreve como duas entidades sã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, o 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 propriedades diferentes de interesse em relação ao tipo de entidade Pessoa , por exemplo, Nome , Data de Nascimento , Sexo , etc.
Além disso, a Pessoa tipo de entidade pode deter certa relação (ou associação ou conexão ) tipos com si mesmo ou outros tipos de entidade; por exemplo, Pessoa pode estar associada a um tipo de entidade chamado UserProfile , que por sua vez pode ter suas próprias propriedades de interesse, digamos, Nome de usuário e Senha .
Porém, (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 a” o ambiente de negócios específico em que estão considerado de importância. São dispositivos usados por designers de banco de dados que trabalham em estreita colaboração com especialistas em negócios para definir um esquema conceitual específico do contexto , na fase de design.
Assim, no nível conceitual, trabalhamos basicamente com a estrutura das idéias que surgem no segmento de interesse do mundo real, ou seja, (1) protótipos de coisas e (2) protótipos de relações entre protótipos de coisas , não trabalhamos com (3) relações - empregando esse último termo no sentido da estrutura relacional dos dados -.
Nível lógico
Depois que Person foi delineado com precisão como um tipo de entidade no nível conceitual, e se alguém deseja implementar um banco de dados relacional que transmita o significado de Person e todos os conceitos associados a ele, os fatos sobre entidades desse tipo podem ser gerenciados em virtude de uma relação matemática no nível lógico e aproveite as operações baseadas na ciência que podem ser executadas nesse construto abstrato (isto é, defini-lo, restringi-lo e manipulá-lo).
Sim, pode-se nomear uma certa relação Pessoa ao definir o arranjo lógico de um banco de dados, mas isso não transforma o conceito de "mundo real" de Pessoa em uma relação, trata-se dessa maneira devido aos benefícios obtidos no gerenciamento de informações sobre isso, por exemplo, aplicando operações de álgebra relacional para derivar novas relações (e, portanto, uma é derivar informações "novas"). Esses benefícios se tornam mais evidentes, levando em consideração o fato de 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 em outras respostas, um dos aspectos principais de uma relação é a conexão que existe entre seus domínios - que normalmente é usada para representar as propriedades dos 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 suponhamos que, no ambiente de negócios em questão, a tupla - que (i) represente uma entidade específica , ou seja, uma instância de um tipo de entidade do esquema conceitual aplicável e (ii) cuja contraparte SQL seja uma linha -
... carregaria o significado
- "O salário pago à pessoa identificada por PersonNumber
xna data efetiva 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, todos eles estão 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 eles constituem um conjunto de um 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 de nível lógico relações
Como demonstrado, agora lidei com o gerenciamento de banco de dados em dois níveis diferentes de abstração, conceitual e lógico - e ainda existe um nível inferior conhecido como físico , que nos DBMSs do 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 geralmente são delimitados por meio de 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 taxa 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-.
Subquestion no. 2
Entendo que o modelo relacional veio após os modelos hierárquicos 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?
DBMSs hierárquicos e de rede precederam seu suporte teórico formal
É oportuno ressaltar que o suporte teórico em torno das abordagens hierárquica e de rede foi, de fato, criado em termos de SGBDs existentes anteriormente , com o objetivo de, entre outros aspectos, testar e estabelecer a solidez de (1) tipos mencionados de software e (2) as práticas vinculadas de gerenciamento de dados - um fenômeno invertido, do meu ponto de vista -.
Incompleto em comparação com a estrutura relacional
Dito isto, embora existam SGBDs hierárquicos e de rede anteriores ao modelo relacional, e mesmo quando o Dr. Codd se referiu a cada uma dessas abordagens como um "modelo", nenhum é definido como tal da mesma maneira que a estrutura relacional. O paradigma relacional fornece construções científicas 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 construções mencionados anteriormente.
Recursos hierárquicos e de rede
Além disso, como afirmado anteriormente, os tipos de entidade e relacionamento são dispositivos de nível conceitual, eles não pertencem às abordagens hierárquicas ou de rede, cada uma das quais oferece mecanismos específicos para representar os referidos 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 contrastados com o modelo relacional que (conforme o princípio da informação ) requer apenas uma construção (a relação), evidencia a complexidade desnecessária que envolve o trabalho em rede. Por exemplo, como recorre a dois instrumentos de representação, a abordagem de rede impõe um viés de consulta impraticável que dificulta a manipulação de dados.
Por seu lado, a visão hierárquica propõe a representação dos dados por meio de arquivos (físicos!) Compostos de registros (que por sua vez consistem em campos ) organizados em um arranjo semelhante a três ; ou seja, um registro pai encadeado com possivelmente muitos colegas filhos via ponteiros , o que produz um caminho de acesso físico com relação à manipulação de dados. Essa abordagem também é desfavorável, pois apresenta um emaranhado entre aspectos conceituais e físicos; portanto, 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 visualizações hierárquica e de rede impõem suas construções nos dados a serem gerenciados, enquanto o modelo relacional propõe a administração elegante dos dados em sua estrutura natural por meio de conjuntos de fatos associados (dos quais n tipos subseqüentes de conjuntos, não previstos em a fase de projeto, pode ser derivada e assim por diante!).
O modelo relacional não possui submodelos
E, muito importante, nem as visualizações hierárquica nem a rede são tipos específicos de modelos relacionais, são simplesmente outros paradigmas que alguém pode seguir para (a) criar DBMSs e (b) criar bancos de dados, mas lembre-se de que as hierarquias e abordagens de rede são consideradas obsoletas há décadas.
Subquestion no. 3
E se tivermos entidades independentes que não se relacionam. Diga, Pessoa, Porta e Árvore. O termo "relação (al)" ainda é aplicável?
Sim, é perfeitamente aplicável se alguém (1) estiver gerenciando informações sobre esses tipos de entidades por meio de relações matemáticas adaptadas e (2) executando as operações relacionais aplicáveis no nível lógico em um determinado banco de dados administrado com o suporte de um determinado DBMS relacional .
Não importa se, no nível conceitual, os referidos tipos de entidade não mantêm tipos de relacionamento com outros tipos de entidade (e vale a pena notar que um tipo de entidade pode ter um relacionamento de proporção de cardinalidade de um para zero-um-ou-muitos por si só) e, portanto, não se está transmitindo nem reforçando 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 seria de 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 na 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 .
fonte
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 (considerando que Codd tinha um PhD em matemática) e, portanto, não vou elaborar, mas vou apontar para este artigo da Wikipedia sobre relações binárias . A entrada da Wikipedia sobre relação (bancos de dados) fornece detalhes adicionais sobre como o 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 no RDM e seu Terceiro ManifestoO site possui uma seção listando documentos e livros. Seu livro Relational Theory for Computing Professionals é uma boa introdução. Eu espero que isso ajude.
fonte
É um nome intuitivo quando você pensa neles com chaves naturais. Você pode pensar em um valor de célula como representando uma entidade.
fonte
Você já aceitou uma resposta muito longa que tem muito a dizer sobre bancos de dados, mas deixe-me responder à pergunta que você realmente fez:
Porque uma tabela é uma instância concreta do objeto matemático "relação".
Vamos ver o que a Wikipedia tem a dizer sobre o termo "relação" (em matemática, não RDBMS) e depois traduzi-lo para bancos de dados:
Continua com a teoria dos conjuntos. Lembre-se de que isso é matemática, muito mais abstrato do que material de banco de dados. A última frase é assim
Isso se traduz em uma uma tabela com duas colunas:
Aé o conjunto de todos os nomes (humanos).Bé o conjunto de todas as cidades.A x B(em matemática) é um novo conjunto que contém todos os pares (aka, tupels) dos(a, b)quaisaé membroAebmembro deB. Ou seja,aé um nome ebé uma cidade. Exemplos seriam(Alice, New York)ou(Bob, Hollywood). Mas o produto cartesiano não é apenas alguns deles, mas todos eles. Uma relação, para chegar ao ponto, é um subconjunto desse produto cartesiano. Em outras palavras, a relação é (definida como sendo) qualquer quantidade de pares em(a, b)queaé um nome ebé uma cidade, mesmo que nenhuma.Agora espero que tudo comece a fazer sentido. Em um RDBMS, as linhas de uma tabela simplesmente selecionam o subconjunto do produto cartesiano de todas as combinações possíveis nessas colunas. Ou seja, ao usar um RDBMS, completamente trivial e irrelevante.
Mas desde Ciência da Computação, incluindo bancos de dados relacionais, que tem suas raízes na matemática, somos abençoados com o termo "relacional" aqui. É totalmente abstrato e não tem nada a ver com o relacionamento entre as pessoas ou com o que você tem.
Como um aparte, o termo "relação" também é às vezes usado para "associação", e é exatamente o mesmo (aqui, os conjuntos subjacentes da relação são eles mesmos relações, como descrito acima (também conhecido como tabelas)).
NB: em matemática, as relações não são sobre bancos de dados, mas são algo como funções, apenas mais gerais (por favor, todos vocês matemáticos, não comecem a escolher agora, estamos no dba.SE, não no math.SE; estou ciente que este é o caminho errado :)). Uma função como
f(x)=x+1também pode ser expressa como um conjunto de tuplas(1, 2), (2, 3), ..., mas só pode ter todos os números uma vez, no lado esquerdo da tupla. Ou seja, isso não seria uma função válida:(1, 2), (1, 3), .... Mas o último seria uma relação válida; ou seja, você pode ter um Bob em Nova York e um Bob em Hollywood.fonte
Os bancos de dados relacionais são baseados no modelo relacional do EFCodd. A álgebra relacional descreve métodos de como consultar dados. Uma relação é simplesmente um subconjunto do produto cruzado de alguns conjuntos (domínios).
Exemplo
Temos os seguintes conjuntos:
Além disso, temos os conjuntos de tuplas
departementsé um subconjunto dee então é uma relação.
employeesé um subconjunto dee também é uma relação.
É evidente como as relações podem ser implementadas por tabelas.
Por que os matemáticos chamam um conjunto de tuplas de relação?
Normalmente, propriedades como '2 menor que 3', '4 é igual a 4', '2 está entre 1 e 3,4', '-1 é negativo' são chamadas de relações.
A relação 'menor que' no conjunto A = {1, 2, 3} é definida pelo subconjunto
do
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 um 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 dos funcionários é uma relação de 6 anos.
fonte