¿Cuál es la diferencia entre una base de datos relacional y no relacional?


82

Sé que soluciones como MySQL, PostgreSQL y MS SQL Server son sistemas de bases de datos relacionales, y NoSQL, MongoDB, etc. son DBMS no relacionales.

Sin embargo, ¿cuáles son las diferencias entre los dos tipos de sistema?

Son preferibles los términos laicos.

Gracias.


11
Esto no es tarea ... pero hoy estaba tratando de explicarle las diferencias a un amigo y comencé a quedarme en blanco. Así que pensé que buscaría aquí y no encontré ninguna explicación satisfactoria. Así que pensé que preguntaría. Las diferencias que estaba diciendo es que con RDBMS hay muchas tablas y uniones entre las tablas. NoSQL no tiene varias tablas, solo tiene una tabla y usa pares clave-valor. No estoy seguro de si esta es una descripción precisa, así que pensé en preguntar.
marcamillion

Encontré estas respuestas inútiles porque pasan demasiado tiempo hablando de lo difícil que es la pregunta sin responder realmente a la pregunta. Después de leer esta publicación de blog, creo que la idea principal es que nosql es mejor que sql dbs para escalar, es decir, distribuirse al escalar, es decir, más potencia de cómputo en una sola máquina ya no es una opción jamesserra.com/archive/2015/08/…
mbigras

Respuestas:


23

Las bases de datos relacionales tienen una base matemática (teoría de conjuntos, teoría relacional), que se destila en SQL == Structured Query Language.

Las muchas formas de NoSQL (por ejemplo, basadas en documentos, basadas en gráficos, basadas en objetos, almacén de valores clave, etc.) pueden o no estar basadas en una única teoría matemática subyacente. Como ha señalado correctamente S. Lott, los almacenes de datos jerárquicos sí tienen una base matemática. Lo mismo podría decirse de las bases de datos de gráficos .

No conozco un lenguaje de consulta universal para bases de datos NoSQL.


"no tienen tales fundamentos matemáticos"? De Verdad? Las bases de datos jerárquicas me parecían bastante matemáticas. También eran relativamente simples, en comparación. Creo que la gente de la base de datos XML tiene un bloqueo bastante sólido sobre lo que se puede (y no se puede) hacer en una base de datos jerárquica.
S.Lott

Podría ser mi ignorancia o mi simplificación excesiva en juego aquí, S. Lott. Buscaré una referencia.
duffymo

1
No soy un experto en el tema, pero como todos son flujos de datos estructurados, creo que al menos un subconjunto de SQL se puede aplicar a cualquier modelo. De hecho, me gusta cómo Google ha expuesto un lenguaje de consulta que es fiel a SQL para su código de Big Table.google.com/appengine/docs/python/datastore/… . Realmente hizo las cosas mucho más fáciles.
Filip Dupanović

43

Hmm, no estoy muy seguro de cuál es tu pregunta.

En el título preguntas sobre bases de datos (DB), mientras que en el cuerpo de tu texto preguntas sobre sistemas de gestión de bases de datos (DBMS). Los dos son completamente diferentes y requieren respuestas diferentes.

Un DBMS es una herramienta que le permite acceder a una base de datos.

Aparte de los datos en sí, una base de datos es el concepto de cómo se estructuran esos datos.

Así que, al igual que puede programar con la metodología de Objeto Orientado con un compilador que no funciona con OO, o viceversa, también puede configurar una base de datos relacional sin un RDBMS o usar un RDBMS para almacenar datos no relacionales.

Me centraré en lo que significa la base de datos relacional (RDB) y dejaré la discusión sobre lo que los sistemas les hacen a los demás.

Una base de datos relacional (el concepto) es una estructura de datos que le permite vincular información de diferentes 'tablas' o diferentes tipos de depósitos de datos. Un depósito de datos debe contener lo que se llama una clave o índice (que permite identificar de forma única cualquier fragmento atómico de datos dentro del depósito). Otros depósitos de datos pueden hacer referencia a esa clave para crear un vínculo entre sus átomos de datos y el átomo al que apunta la clave.

Una base de datos no relacional simplemente almacena datos sin mecanismos explícitos y estructurados para vincular datos de diferentes depósitos entre sí.

En cuanto a la implementación de este esquema, si tiene un archivo en papel con un índice y en un archivo en papel diferente se refiere al índice para obtener la información relevante, entonces ha implementado una base de datos relacional, aunque bastante simple. Entonces ve que ni siquiera necesita una computadora (por supuesto, puede volverse tedioso muy rápidamente sin una que lo ayude), de manera similar, no necesita un RDBMS, aunque podría decirse que un RDBMS es la herramienta adecuada para el trabajo. Dicho esto, existen variaciones en cuanto a lo que pueden hacer las diferentes herramientas, por lo que elegir la herramienta adecuada para el trabajo puede no ser tan sencillo.

Espero que estos sean términos bastante profundos y sea útil para su comprensión.


"Si tiene un archivo en papel con un índice y en un archivo en papel diferente se refiere al índice para obtener la información relevante, entonces ha implementado una base de datos relacional" muy buen ejemplo. Sería genial si este se expande más allá para explicar clave primaria, clave externa, etc.
Zeni

No es necesario conocer las restricciones o declarar alguna o tener alguna que declarar (incluidos PK, CK y FK) para usar una base de datos relacional. Están a favor de la integridad. Las tablas representan relaciones (barcos). Unir y otros operadores conectan tablas para obtener nuevas tablas cuyas relaciones (envíos) son combinaciones de relaciones (envíos) de tablas de argumentos. Además, los índices son para la optimización de la implementación y son irrelevantes para que una base de datos / DBMS sea relacional con sus usuarios.
philipxy

22

La mayor parte de lo que "sabe" está mal.

En primer lugar, como algunos de los gurús relacionales señalan de forma rutinaria (ya veces estridentemente), SQL no encaja tan de cerca con la teoría relacional como mucha gente piensa. En segundo lugar, la mayoría de las diferencias en las cosas "NoSQL" tienen relativamente poco que ver con si es relacional o no. Finalmente, es bastante difícil decir en qué se diferencia "NoSQL" de SQL porque ambos representan una gama bastante amplia de posibilidades.

La única diferencia principal con la que puede contar es que casi todo lo que admita SQL admite cosas como desencadenantes en la propia base de datos, es decir, puede diseñar reglas en la base de datos propiamente dicha para garantizar que los datos siempre sean coherentes internamente. Por ejemplo, puede configurar las cosas para que su base de datos afirme que una persona debetener una dirección. Si lo hace, siempre que agregue a una persona, básicamente lo obligará a asociar a esa persona con alguna dirección. Puede agregar una nueva dirección o puede asociarla con alguna dirección existente, pero de una forma u otra, la persona debe tener una dirección. Del mismo modo, si elimina una dirección, lo obligará a eliminar a todas las personas que se encuentran actualmente en esa dirección o asociarlas con alguna otra dirección. Puede hacer lo mismo con otras relaciones, como decir que todas las personas deben tener una madre, que todas las oficinas deben tener un número de teléfono, etc.

Tenga en cuenta que este tipo de cosas también están garantizados a suceder de forma atómica, por lo que si alguien mira a la base de datos que va a añadir a la persona, que van a ver o no la persona en absoluto, o de lo contrario van a ver a la persona con la dirección (o la madre, etc.)

La mayoría de las bases de datos NoSQL no intentan proporcionar este tipo de aplicación en la base de datos propiamente dicha. Depende de usted, en el código que utiliza la base de datos, hacer cumplir las relaciones necesarias para sus datos. En la mayoría de los casos, también es posible ver datos que son solo parcialmente correctos, por lo que incluso si tiene un árbol genealógico en el que se supone que todas las personas están asociadas con los padres, puede haber ocasiones en las que las restricciones que haya impuesto no lo sean realmente. en vigor. Algunos te permitirán hacer eso a voluntad. Otros garantizan que solo ocurre temporalmente, aunque puede cuestionarse cuánto tiempo puede o durará exactamente.


9

La base de datos relacional utiliza un sistema formal de predicados para abordar los datos. La implementación física subyacente no tiene sustancia y puede variar para optimizar para ciertas operaciones, pero siempre debe asumir el modelo relacional . En términos simples, eso es solo decir que sé exactamente cuántos valores (atributos) tiene cada fila (tupla) en mi tabla (relación) y ahora quiero explotar el hecho en consecuencia, a fondo y al extremo. Esa es la verdadera naturaleza de la bestia. 

Dado que obviamente somos la generación que ha tenido una educación relacional, si observa los modelos de base de datos NoSQL desde la perspectiva del modelo relacional, nuevamente en términos simples, la primera diferencia obvia es que no se pueden hacer suposiciones sobre el número de valores por fila. contener se hace alguna vez. Esto realmente simplifica demasiado el asunto y no se aplica claramente a las complejidades de los modelos físicos de cada base de datos NoSQL, pero es el pináculo del modelo relacional y la primera suposición que tenemos que dejar atrás o, si lo prefiere, la más grande. salto que tenemos que dar.

Podemos estar de acuerdo con dos cosas que son ciertas para cada DBMS: puede almacenar cualquier tipo de datos y tiene suficientes fundamentos matemáticos para que sea posible administrar los datos de cualquier forma imaginable. La realidad es que nunca querrá cometer el error de poner a prueba ninguno de los dos puntos, sino más bien quedarse con lo que realmente se hizo el DBMS. En términos sencillos: ¡ respeta a la bestia interior!

(Tenga en cuenta que he evitado comparar los estándares (obviamente) bien fundamentados que giran en torno al modelo relacional con los muchos sabores proporcionados por las bases de datos NoSQL. Si lo desea, considere las bases de datos NoSQL como un término general para cualquier DBMS que no incluya completamente asume el modelo relacional, excluyendo todo lo demás. Las diferencias son demasiadas, pero esa es la diferencia principal y la que creo que te sería más útil para entender las dos.)


6

Intente explicar esta pregunta en un nivel que se refiera a un poco de tecnología.

Tome MongoDB y SQL tradicional para comparar, imagine el escenario de publicar un Tweet en Twitter. Este tweet contiene 9 imágenes. ¿Cómo almacena este tweet y sus imágenes correspondientes?

En términos de SQL de relación tradicional, puede almacenar los tweets y las imágenes en tablas separadas y representar la conexión mediante la creación de una nueva tabla.

Además, puede establecer un campo que sea un tipo de imagen, comprimir las 9 imágenes en un documento binario y almacenarlo en este campo.

Con MongoDB, podría crear un documento como este (similar al concepto de tabla en SQL relacional):

{

"id":"XXX",

"user":"XXX",

"date":"xxxx-xx-xx",

"content":{

"text":"XXXX",

"picture":["p1.png","p2.png","p3.png"]

}

Por tanto, en mi opinión, la principal diferencia radica en cómo se almacenan los datos y el nivel de almacenamiento de las relaciones entre ellos.

En este ejemplo, los datos son el tweet y las imágenes. El mecanismo diferente sobre el nivel de almacenamiento de la relación entre ellos también juega un papel importante en la diferencia entre ambos.

Espero que este pequeño ejemplo ayude a mostrar la diferencia entre SQL y NoSQL (ACID y BASE).

Aquí hay un enlace de imagen sobre los objetivos de NoSQL de Internet:

http://icamchuwordpress-wordpress.stor.sinaapp.com/uploads/2015/01/dbc795f6f262e9d01fa0ab9b323b2dd1_b.png


Muy buena explicación, hay un enlace donde tuve la primera idea, espero que pueda ayudar a alguien. growthefuturenow.com/relational-vs-non-relational-database
Muhammad Sadiq

4

La diferencia entre relacional y no relacional es exactamente eso. La arquitectura de la base de datos relacional proporciona objetos de restricciones como claves primarias, claves externas, etc. que permiten vincular dos o más tablas en una relación. Esto es bueno para que normalicemos nuestras tablas, es decir, dividir la información sobre lo que representa la base de datos en muchas tablas diferentes, una vez que podamos mantener la integridad de los datos.

Por ejemplo, supongamos que tiene una serie de tablas que contienen información sobre un empleado. No puede eliminar un registro de una tabla sin eliminar todos los registros que pertenecen a dicho registro de las otras tablas. De esta manera, implementa la integridad de los datos. La base de datos no relacional no proporciona estas construcciones de restricciones que le permitirán implementar la integridad de los datos.

A menos que no implemente esta restricción en la aplicación de interfaz que se utiliza para completar las tablas de las bases de datos, está implementando un desastre que se puede comparar con el salvaje oeste.


1

Primero, permítanme comenzar diciendo por qué necesitamos una base de datos.

Necesitamos una base de datos para ayudar a organizar la información de tal manera que podamos recuperar los datos almacenados de manera eficiente.

Ejemplos de sistemas de gestión de bases de datos relacionales (SQL):

1) Base de datos Oracle

2) SQLite

3) PostgreSQL

4) MySQL

5) Microsoft SQL Server

6) IBM DB2

Ejemplos de sistemas de gestión de bases de datos no relacionales (NoSQL)

1) MongoDB

2) Cassandra

3) Redis

4) Sofá

5) HBase

6) DocumentDB

7) Neo4j

Las bases de datos relacionales tienen datos normalizados, ya que la información se almacena en tablas en forma de filas y columnas, y normalmente cuando los datos están en forma normalizada, ayuda a reducir la redundancia de datos, y los datos en tablas normalmente están relacionados entre sí, por lo que cuando queremos recuperar los datos, podemos consultar los datos mediante el uso de declaraciones de unión y recuperar datos según nuestras necesidades. Esto es adecuado cuando queremos tener más escrituras, menos lecturas y no hay muchos datos involucrados, también es realmente fácil relativamente actualizar datos en tablas que en bases de datos no relacionales. El escalado horizontal no es posible, el escalamiento vertical es posible hasta cierto punto. Cumplimiento de CAP (consistencia, disponibilidad, tolerancia a la partición) y ACID (atomicidad, consistencia, aislamiento, duración).

Permítanme mostrarles cómo ingresar datos a una base de datos relacional usando PostgreSQL como ejemplo.

Primero cree una tabla de productos de la siguiente manera:

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric
);

luego inserta los datos

INSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', 9.99);

Veamos otro ejemplo diferente: ingrese la descripción de la imagen aquí

Aquí, en una base de datos relacional, podemos vincular la tabla de estudiantes y la tabla de materias usando relaciones, a través de clave externa, ID de materia, pero en una base de datos no relacional no es necesario tener dos documentos, ya que no hay relaciones, por lo que almacenamos todos los detalles de la materia y los detalles del estudiante en un documento dicen que el documento del estudiante, luego los datos se están duplicando, lo que dificulta la actualización de los registros.

En las bases de datos no relacionales, no hay un esquema fijo, los datos no están normalizados. no se crean relaciones entre los datos, todos los datos se colocan principalmente en un documento. Muy adecuado para manejar una gran cantidad de datos y puede transferir muchos datos a la vez, mejor donde grandes cantidades de lecturas y menos escrituras, y menos actualizaciones, son un poco difíciles de consultar datos, ya que no hay un esquema fijo. Es posible el escalado horizontal y vertical.CAP (consistencia, disponibilidad, tolerancia a la partición) y BASE (básicamente disponible, estado suave, eventualmente consistente).

Permítanme mostrarles un ejemplo para ingresar datos a una base de datos no relacional usando Mongodb

db.users.insertOne({name: ‘Mary’, age: 28 , occupation: ‘writer’ })
db.users.insertOne({name: ‘Ben’ , age: 21})

Por lo tanto, puede entender que a la base de datos llamada db, y hay una colección llamada usuarios, y un documento llamado insertOne al que agregamos datos, y no hay un esquema fijo ya que nuestro primer registro tiene 3 atributos y el segundo atributo tiene 2 atributos solamente , esto no es un problema en bases de datos no relacionales, pero esto no se puede hacer en bases de datos relacionales, ya que las bases de datos relacionales tienen un esquema fijo.

Veamos otro ejemplo diferente

({Studname: ‘Ash’, Subname: ‘Mathematics’, LecturerName: ‘Mr. Oak’})

Por lo tanto, podemos ver que en la base de datos no relacional podemos ingresar tanto los detalles del estudiante como los detalles de la asignatura en un documento, ya que no hay relaciones definidas en las bases de datos no relacionales, pero aquí esta forma puede conducir a la duplicación de datos y, por lo tanto, pueden ocurrir errores en la actualización.

Espero que esto explique todo


-1

En términos simples, está fuertemente estructurado frente a no estructurado, lo que implica que tiene diferentes grados de adaptabilidad para su base de datos. Las diferencias surgen en la indexación, especialmente porque necesita asegurarse de que un determinado índice de referencia pueda vincularse a otro elemento -> esta relación. La estructura más estricta de la base de datos relacional proviene de este requisito.

Para tener en cuenta que NosDB aparentemente proporciona bases de datos relacionales y no relacionales y una forma de consultar tanto http://www.alachisoft.com/nosdb/sql-cheat-sheet.html

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.