En inglés, podríamos hablar sobre la relación entre, por ejemplo, Bob y Tim. Quizás son primos. El término "relación" en este contexto tiene sentido para mí.

En el contexto de las bases de datos relacionales, entiendo a qué se refiere el término, pero no entiendo por qué se usa. Creo que entender por qué se usa me ayudará a comprender mejor el campo, por lo que me gustaría entender por qué se usa.

• ¿Por qué, por ejemplo, una Persona se considera una "relación"? En inglés, una relación es un sustantivo que describe cómo se asocian dos entidades. No se refiere a las entidades mismas. En el contexto de las bases de datos relacionales, "relación" se refiere a las entidades mismas. ¿Por qué?
• Entiendo que el modelo relacional vino después de los modelos jerárquicos y de red (por ejemplo, padre, vecino). Pero en esos modelos, las entidades también tienen relaciones entre sí. Entonces, ¿por qué llamar a este modelo el modelo relacional? ¿Hay una frase / término más específico? ¿O tal vez deberíamos decir que los tres modelos son modelos relacionales, pero los modelos jerárquicos y de red son tipos específicos de modelos relacionales?
• ¿Qué pasa si tenemos entidades independientes que no se relacionan entre sí? Decir, persona, puerta y árbol. ¿Sigue siendo aplicable el término "relación (al)"?

(Quizás esto debería ser varias preguntas. Supuse que las respuestas están muy relacionadas, tal vez solo hay una respuesta, así que pensé que tendría sentido que se tratara de una sola pregunta. Si me equivoco, avíseme y yo crearé preguntas separadas en su lugar).

Editar: este diagrama puede ser útil para visualizar que una relación relaciona diferentes dominios entre sí:

En primer lugar, recomiendo encarecidamente el artículo científico en el que el Dr. Edgar Frank Codd publicó el marco relacional para el público en general en 1970, es decir, Un modelo relacional de datos para grandes bancos de datos compartidos . Allí, en la sección 1.1, "Introducción", el propio Dr. Codd afirma que:

Este artículo trata sobre la aplicación de la teoría de la relación elemental a los sistemas que proporcionan acceso compartido a grandes bancos de datos formateados.

---

_{© Asociación de Maquinaria Informática. Comunicaciones de la ACM , Volumen 13, Número 6 (pp. 377-387), junio de 1970.}

Entonces, sí, los términos relación y (por lo tanto) relacional provienen de un fondo matemático. El Dr. Codd —que, además de sus credenciales académicas y de investigación, tenía cerca de 20 años de experiencia de primera mano en informática y procesamiento de información— imaginó las enormes ventajas de aplicar la relación (una construcción abstracta, naturalmente) en el campo de la administración de datos .

No soy matemático pero, básicamente, una relación es una asociación entre conjuntos , un conjunto es una colección de elementos ( este recurso externo proporciona una definición de relación matemática que puede ayudar a entenderlo desde una perspectiva diferente). Cuando se trabaja con la ayuda de un sistema de administración de bases de datos SQL (DBMS por brevedad), una aproximación bien conocida de una relación es una tabla , en cuyo caso la asociación se lleva a cabo entre los tipos de sus columnas . Evidentemente, en las plataformas SQL que ofrecen soporte DOMAIN (por ejemplo, Firebird y PostgreSQL ), la asociación se produce entredominios fijos para las columnas de la tabla en cuestión; Consulte las secciones a continuación para obtener detalles significativos.

A ese respecto, voy a citar nuevamente al Dr. Codd, quien en la sección 1.3, “Una visión relacional de los datos”, afirma que:

El término relación se usa aquí en su sentido matemático aceptado. Dados los conjuntos S ₁ , S ₂ , ⋯, S _n (no necesariamente distintos), R es una relación en estos n conjuntos si es un conjunto de n -tuplas, cada una de las cuales tiene su primer elemento de S ₁ , su segundo elemento de S ₂ , y así sucesivamente. ¹ nos referiremos a S _j como el j ésimo dominio de R . Como se definió anteriormente, se dice que R tiene un grado n. Las relaciones de grado 1 a menudo se denominan unario , grado 2 binario , grado 3 ternario y grado n n-ario .

_{¹ Más concisamente, R es un subconjunto del producto cartesiano S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Asociación de Maquinaria Informática. Comunicaciones de la ACM , Volumen 13, Número 6 (pp. 377-387), junio de 1970.}

Y estoy de acuerdo con otras respuestas en que es muy relevante señalar que el Dr. Codd hizo algunas adaptaciones a la relación matemática para aprovechar al máximo la gestión de datos, y se explican en el documento mencionado anteriormente y a lo largo de su extensa bibliografía .

Relación y relación

Una situación que vale la pena mencionar es que, cuando se trata con estos temas, puede surgir confusión debido a las similitudes que existen con respecto a las definiciones cotidianas (no matemáticas, no técnicas) de los términos relación y relación , que, como hablante nativo de inglés, me parece particularmente comprensible—.

La vista entidad-relación y el modelo relacional.

Otro factor que creo que también puede causar confusión (y está estrechamente asociado con las connotaciones técnicas de los dos términos mencionados anteriormente) es que, cuando se aprende a diseñar bases de datos, un estudiante o profesional generalmente se presenta por primera vez a la metodología propuesta por el Dr. Peter Pin-Shan Chen en la vista de datos entidad-relación (publicada en 1976), que sugiere dos implementos diferentes (es decir, la entidad y la relación ) para delinear un esquema conceptual , y luego, solo después de la definición de dicho esquema es estable, el alumno o profesional se introduce en términos e instrumentos relacionales (por ejemplo, la relación ) al declarar elDiseño lógico de la base de datos pertinente. Dentro del marco conceptual de referencia, la relación tiene connotaciones que están mucho más cerca del sentido cotidiano de la palabra.

Entonces, tal vez, esa circunstancia también se suma a la relación y el problema de la relación , pero la secuencia de definir primero el esquema conceptual y luego declarar el diseño lógico correspondiente es, por supuesto, bastante apropiado, como detallaré en las siguientes secciones.

Respuestas a cada una de tus preguntas

Considero que incluir esas tres preguntas secundarias es realmente pertinente porque establecen un contexto más amplio para la publicación, por lo que no deben pasarse por alto. De esta manera, además de abordar exclusivamente por qué los términos relación y relacional se utilizan (que por cierto es muy importante y es el título del post, pero es no la totalidad de correos), dijeron sub-preguntas pueden ayudar a comprender más del ámbito de la relación y el modelo relacional cuando uno está involucrado en un proyecto completo de gestión de información (bastante relevante ya que este es un sitio sobre administración de bases de datos) y, por lo tanto, está trabajando en diferentes niveles de abstracción. De esta manera, voy a compartir mi opinión sobre los detalles a continuación.

Subconsulta no. 1

¿Por qué, por ejemplo, una Persona se considera una "relación"? En inglés, una relación es un sustantivo que describe cómo se asocian dos entidades. No se refiere a las entidades mismas. En el contexto de las bases de datos relacionales, "relación" se refiere a las entidades mismas. ¿Por qué?

Nivel conceptual

En un entorno empresarial dado, la persona puede considerarse un tipo de entidad dependiendo de cómo la conceptualicen las personas que trabajan allí (expertos en negocios y diseñadores de bases de datos) . Y, sí, en ese entorno empresarial, puede haber diferentes propiedades de interés con respecto al tipo de entidad Persona , por ejemplo, Nombre , Fecha de nacimiento , Género , etc.

Por otra parte, la persona tipo entidad puede tener cierta relación (o asociación o conexión ) tipos con sí mismo o de otros tipos de entidad; por ejemplo, la persona puede estar asociada con un tipo de entidad llamada Perfil de usuario , que a su vez puede tener sus propias propiedades de interés, digamos, Nombre de usuario y Contraseña .

Pero, (a) los tipos de entidad, (b) sus propiedades correspondientes, (c) los tipos de relación entre tipos de entidad y (d) las relaciones entre las propiedades mismas son nociones que "pertenecen" al entorno empresarial particular en el que se encuentran considerado de importancia. Son dispositivos utilizados por diseñadores de bases de datos que trabajan en estrecha colaboración con expertos empresariales para definir un esquema conceptual específico del contexto , en la fase de diseño.

Por lo tanto, en el nivel conceptual, básicamente trabajamos con la estructura de las ideas que surgen en el segmento de interés del mundo real, es decir, (1) prototipos de cosas y (2) prototipos de relaciones entre prototipos de cosas , no trabajamos con (3) relaciones —empleando este último término en el sentido del marco relacional de datos—.

Nivel lógico

Después de que Person se delineó con precisión como un tipo de entidad en el nivel conceptual, y si se quiere implementar una base de datos relacional que transmita el significado de Person y todos los conceptos asociados con ella, entonces los hechos sobre las entidades de ese tipo se pueden manejar en virtud de una relación matemática a nivel lógico y aprovechar las operaciones basadas en la ciencia que se pueden realizar en esa construcción abstracta (es decir, definirla, restringirla y manipularla).

Sí, se puede nombrar una determinada relación Persona cuando se define la disposición lógica de una base de datos, pero eso no transforma el concepto de Persona del "mundo real" en una relación, se aborda como tal debido a los beneficios que se obtienen al administrar la información al respecto, por ejemplo, aplicando operaciones de álgebra relacional para derivar nuevas relaciones (y, por lo tanto, uno está derivando información "nueva"). Dichos beneficios se hacen más evidentes teniendo en cuenta el hecho de que las entidades de cierto tipo forman un conjunto, y los valores de cierta propiedad también forman un conjunto.

Y sí, como se mencionó en los párrafos anteriores y también en otras respuestas, uno de los aspectos más importantes de una relación es la conexión que existe entre sus dominios , que generalmente se utilizan para representar las propiedades de los tipos de entidad o asociación que forman parte de un esquema conceptual Por ejemplo, digamos que hemos declarado la siguiente relación (ternaria):

• Salary (PersonNumber, EffectiveDate, Amount)

... y supongamos que, en el entorno empresarial en cuestión, la tupla, que (i) representa una entidad en particular , es decir, una instancia de un tipo de entidad del esquema conceptual aplicable, y (ii) cuya contraparte SQL es un fila -

• Salary (x, y, z)

... llevaría el significado

• "El salario pagado a la persona identificada por PersonNumber xen EffectiveDate ycorresponde a la cantidad de z" .

Por consiguiente, para describir las cosas de manera aproximada, la conexión entre los tres dominios es de primordial importancia, todos están relacionados (y, sí, una relación unaria implicaría un solo dominio). La conexión entre todos los valores de un determinado dominio también es muy significativa, ya que constituyen un conjunto de un tipo preciso . Además, el contenido de cada tupla de la Salaryrelación debe encajar en la estructura de la afirmación ilustrada anteriormente.

A nivel conceptual relaciones y de nivel lógico relaciones

Como se demostró, ahora he tratado con la administración de bases de datos en dos niveles diferentes de abstracción, a saber, conceptual y lógico, y todavía hay un nivel inferior conocido como el físico , que en los DBMS de SQL generalmente involucra, por ejemplo, índices, páginas, extensiones, etc.

Entonces, de acuerdo con las nociones explicadas anteriormente, en el nivel lógico se trabaja exclusivamente con (a) relaciones matemáticas, donde (b) las relaciones o asociaciones conceptuales están representadas por (c) los valores contenidos en las tuplas de tales relaciones matemáticas, y dichos valores generalmente se delimitan a través de restricciones de FOREIGN KEY para que puedan representar las relaciones aplicables con precisión.

Y sí, las entidades asociativas , es decir, instancias de tipos de relación con una relación de cardinalidad de muchos a muchos (M: N), pueden transmitirse a través de las tuplas de una única relación matemática, con las restricciones correspondientes declaradas apropiadamente, de curso-.

Subconsulta no. 2

Entiendo que el modelo relacional vino después de los modelos jerárquicos y de red. Pero en esos modelos, las entidades también tienen relaciones entre sí. Entonces, ¿por qué llamar a este modelo el modelo relacional? ¿Hay una frase / término más específico? ¿O tal vez deberíamos decir que los tres modelos son modelos relacionales, pero los modelos jerárquicos y de red son tipos específicos de modelos relacionales?

Los DBMS jerárquicos y de red precedieron a su apoyo teórico formal.

Es oportuno señalar que el apoyo teórico en torno a los enfoques jerárquicos y de red fue, de hecho, creado en términos de DBMS previamente existentes , con el objetivo de, entre otros aspectos, probar y establecer la solidez de (1) dichos tipos del software y (2) las prácticas de gestión de datos vinculadas —un fenómeno al revés, desde mi punto de vista—.

Incompleto en comparación con el marco relacional

Dicho esto, aunque existen DBMS jerárquicos y de red que son anteriores al modelo relacional, e incluso cuando el Dr. Codd se refirió a cada uno de esos enfoques como un "modelo", ninguno se define como tal de la misma manera que el marco relacional. El paradigma relacional proporciona construcciones científicas para la (i) definición, (ii) restricción y (iii) manipulación de datos, y los enfoques jerárquicos y de red carecen de soporte teórico completo para cubrir los tres tipos de construcciones mencionadas anteriormente.

Red y características jerárquicas

Además, como se indicó anteriormente, los tipos de entidad y relación son dispositivos de nivel conceptual, no pertenecen a los enfoques jerárquicos o de red, cada uno de los cuales ofrece mecanismos particulares para representar dichos aspectos:

• El paradigma de la red implica dos dispositivos para la representación de datos, es decir, nodos y arcos (y esa característica, por supuesto, implica dos tipos diferentes de operaciones de manipulación de datos) que, en contraste con el modelo relacional que (según el principio de información ) requiere solo una construcción (la relación), pone de manifiesto la innecesaria complejidad que implica trabajar en red. Por ejemplo, dado que recurre a dos instrumentos de representación, el enfoque de red impone un sesgo de consulta poco práctico que dificulta la manipulación de datos.

• Por su parte, la vista jerárquica propone representar los datos a través de archivos (¡físicos!) Formados por registros (que a su vez consisten en campos ) organizados en una disposición similar a tres ; es decir, un registro padre encadenado con posiblemente muchos homólogos secundarios a través de punteros , lo que produce una ruta de acceso físico con respecto a la manipulación de datos. Este enfoque también es desfavorable porque presenta un enredo entre los aspectos conceptuales y físicos, por lo que los cambios en las disposiciones de almacenamiento físico requieren una reorganización de las estructuras de datos, lo que a su vez exige cambios en las operaciones de manipulación de datos.

Como se muestra, las vistas jerárquicas y de red imponen sus construcciones sobre los datos a gestionar, mientras que el modelo relacional propone administrar los datos de manera elegante en su estructura natural por medio de conjuntos de hechos asociados (de los cuales n tipos de conjuntos posteriores, no previstos en la fase de diseño, se puede derivar y así sucesivamente).

El modelo relacional no tiene submodelos.

Y, muy importante, ni las vistas jerárquicas ni las de red son tipos específicos de modelos relacionales, son simplemente otros paradigmas que alguien puede seguir para (a) construir DBMS y (b) crear bases de datos, pero tenga en cuenta que la jerarquía y los enfoques de red se consideran obsoletos desde hace décadas.

Subconsulta no. 3

¿Qué pasa si tenemos entidades independientes que no se relacionan entre sí? Decir, persona, puerta y árbol. ¿Sigue siendo aplicable el término "relación (al)"?

Sí, es perfectamente aplicable si uno (1) maneja información sobre esos tipos de entidad a fuerza de relaciones matemáticas adaptadas y (2) realiza las operaciones relacionales aplicables a nivel lógico en una determinada base de datos administrada con el apoyo de un DBMS relacional dado .

No importa si, a nivel conceptual, dichos tipos de entidad no tienen tipos de relación con otros tipos de entidad (y vale la pena señalar que un tipo de entidad puede tener una relación de cociente de cardinalidad de uno a cero uno o muchos consigo mismo) y, por lo tanto, no se transmite ni se impone ninguna relación entre los valores de las tuplas de las relaciones bajo consideración.

Lo interesante detrás de la 'base de datos relacional' es que no se refiere (principalmente) a las relaciones entre tablas, como es de esperar, sino que se refiere a la relación de múltiples propiedades (columnas) en una tupla. Una base de datos relacional almacena esas tuplas como una fila en una tabla.

Se basa en el álgebra relacional definida por Alfred Tarski en su artículo de 1941 (!) Sobre el cálculo de las relaciones . Resumió la historia del término y el uso en lógica simbólica, pero definió las operaciones que al final se convirtieron en la base de SQL.

Codd convirtió esto en una definición de lo que puede entenderse como una base de datos relacional en sus 12 mandamientos .

El término "relacional" proviene de las matemáticas y no tiene nada que ver con las relaciones entre entidades. No soy matemático (mientras que Codd tenía un doctorado en Matemáticas) y, por lo tanto, no daré más detalles, pero te señalaré este artículo de Wikipedia sobre relaciones binarias . La entrada de wikipedia sobre relación (bases de datos) brinda detalles adicionales sobre cómo Codd adaptó los conceptos matemáticos para aplicarlos a la gestión de datos. En cuanto a por qué esta estructura matemática se llama relación, creo que tiene que ver con la idea de que existe una "relación" entre los dominios que componen la relación. La mejor fuente que conozco para comprender mejor el pensamiento original de Codd es Fabian Pascal '. Chris Date también ha escrito extensamente sobre el RDM y su sitio del Tercer Manifiesto tiene una sección que enumera artículos y libros. Su libro Teoría relacional para profesionales de la informática es una buena introducción. Espero que esto ayude.

Es un nombre intuitivo cuando piensas en ellos con claves naturales. Puede pensar en un valor de celda como representación de una entidad.

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

• El nombre del empleado "Jane" está relacionado con el trabajo "supervisor".
• El nombre del empleado "John" está relacionado con el jefe "Jane".
• El trabajo "cajero" está relacionado con los nombres de los empleados "John", "Jesse" y "Jason".
• El trabajo "cajero" está relacionado con los jefes "Jane" y "Claire".

Ya ha aceptado una respuesta muy larga que tiene mucho que decir sobre las bases de datos, pero permítame responder la pregunta que realmente hizo:

Por qué el término "relacional".

Porque una tabla es una instancia concreta del objeto matemático "relación".

Veamos qué dice Wikipedia sobre el término "relación" (en matemáticas, no RDBMS), y luego traduzca a bases de datos:

Formalmente, una relación es un conjunto de n-tuplas de igual grado. Así, una relación binaria es un conjunto de pares, una relación ternaria un conjunto de triples, y así sucesivamente. En el lenguaje de la teoría de conjuntos, una relación entre dos conjuntos es un subconjunto de su producto 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.

Continúa con la teoría de conjuntos. Recuerda que esto es matemática, mucho más abstracto que material de base de datos. La última oración así es

Una relación entre dos conjuntos es un subconjunto de su producto cartesiano.

Esto se traduce en un una tabla con dos columnas:

• Llamemos a la columna A "nombre". Su conjunto matemático Aes el conjunto de todos los nombres (humanos).
• Columna BI llamada "ciudad". Su conjunto matemático Bes el conjunto de todas las ciudades.
• El producto cartesiano A x B(en matemáticas) es un nuevo conjunto que contiene todos los pares (también conocidos como tupeles) de los (a, b)que aes miembro Ay bes miembro B. Es decir, aes un nombre y bes una ciudad. Los ejemplos serían (Alice, New York)o (Bob, Hollywood). Pero el producto cartesiano no es solo algunos de ellos, sino todos . Una relación, para llegar al punto, es un subconjunto de ese producto cartesiano. En otras palabras, la relación es (definida como) cualquier cantidad de pares (a, b)donde aes un nombre y bes una ciudad, incluso ninguno.

Ahora espero que todo comience a tener sentido. En un RDBMS, las filas de una tabla simplemente seleccionan el subconjunto del producto cartesiano de todas las combinaciones posibles en esas columnas. Que es, cuando se usa un RDBMS, completamente trivial e irrelevante.

Pero desde la informática, incluyendo bases de datos relacionales, no tiene sus raíces en las matemáticas, hemos sido bendecidos con el término "relacional" aquí. Es completamente abstracto y no tiene nada que ver con las relaciones entre las personas o lo que tienes.

Por otro lado, el término "relación" a veces también se usa para "asociación", y es exactamente el mismo (aquí, los conjuntos subyacentes de la relación son relaciones como se describió anteriormente (también conocido como tablas).

NB: en matemáticas, las relaciones no son sobre bases de datos, sino que son algo así como funciones, simplemente más generales (por favor, todos ustedes matemáticos, no comiencen a jugar ahora, estamos en dba.SE, no en matemáticas.SE; soy consciente que este es el camino equivocado :)). Una función como f(x)=x+1también se puede expresar como un conjunto de tuplas (1, 2), (2, 3), ..., pero solo puede tener cada número una vez, en la mano izquierda de la tupla. Es decir, esto no sería una función válida: (1, 2), (1, 3), .... Pero esto último sería una relación válida; es decir, puedes tener un Bob en Nueva York y un Bob en Hollywood.

Las bases de datos relacionales se basan en el modelo relacional de EFCodd. El álgebra relacional describe métodos de cómo consultar datos. Una relación es simplemente un subconjunto del producto cruzado de algunos conjuntos (dominios).

Ejemplo

Tenemos los siguientes conjuntos:

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

Además tenemos los conjuntos de tuplas

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 es un subconjunto de

    DepIds x DepNames

y entonces es una relación.

employees es un subconjunto de

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

y también es una relación.

Es evidente cómo las tablas pueden implementar las relaciones.

¿Por qué los matemáticos llaman a un conjunto de tuplas una relación?

Por lo general, propiedades como '2 menos que 3', '4 es igual a 4', '2 está entre 1 y 3.4', '-1 es negativo' se denominan relaciones.

La relación 'menor que' en el conjunto A = {1, 2, 3} está definida por el subconjunto

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

de

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 manera similar, otras relaciones pueden verse como un subconjunto de un producto cruzado. 'x menos que y', 'x es igual a y' son relaciones binarias y, por lo tanto, se definen mediante un conjunto de pares. 'x entre y an z' es una relación ternaria 'y, por lo tanto, se define por un conjunto de triples. 'x es negativo' es una relación unaria y, por lo tanto, se define por un conjunto de singletons.

El conjunto de tuplas de departamentos que definimos anteriormente es una relación binaria, la relación de los empleados es una relación de 6 arios.