Sql

Lenguaje de consulta estructurado, abreviado como SQL (S-Q-L, a veces "secuela" por razones históricas), es un lenguaje específico de dominio utilizado en la programación y diseñado para administrar datos almacenados en un sistema de administración de bases de datos relacionales (RDBMS) o para el procesamiento de flujos en un sistema de administración de flujos de datos relacionales (RDSMS). Es particularmente útil en el manejo de datos estructurados, es decir, datos que incorporan relaciones entre entidades y variables.

SQL ofrece dos ventajas principales sobre las API de lectura y escritura más antiguas, como ISAM o VSAM. En primer lugar, introdujo el concepto de acceder a muchos registros con un solo comando. En segundo lugar, elimina la necesidad de especificar cómo alcanzar un registro, p. con o sin índice.

Originalmente basado en el álgebra relacional y el cálculo relacional de tuplas, SQL consta de muchos tipos de declaraciones, que pueden clasificarse informalmente como sublenguajes, comúnmente: un lenguaje de consulta de datos (DQL), un lenguaje de definición de datos (DDL), un lenguaje de control de datos (DCL) y un lenguaje de manipulación de datos (DML). El alcance de SQL incluye consulta de datos, manipulación de datos (inserción, actualización y eliminación), definición de datos (creación y modificación de esquemas) y control de acceso a datos. Aunque SQL es esencialmente un lenguaje declarativo (4GL), también incluye elementos de procedimiento.

SQL fue uno de los primeros lenguajes comerciales en utilizar el modelo relacional de Edgar F. Codd. El modelo se describió en su influyente artículo de 1970, "Un modelo relacional de datos para grandes bancos de datos compartidos". A pesar de no adherirse por completo al modelo relacional descrito por Codd, se convirtió en el lenguaje de base de datos más utilizado.

SQL se convirtió en un estándar del Instituto Nacional Estadounidense de Estándares (ANSI) en 1986 y de la Organización Internacional para la Estandarización (ISO) en 1987. Desde entonces, el estándar se ha revisado para incluir un conjunto más amplio de características. A pesar de la existencia de estándares, la mayoría del código SQL requiere al menos algunos cambios antes de ser portado a diferentes sistemas de bases de datos.

Historia

SQL fue desarrollado inicialmente en IBM por Donald D. Chamberlin y Raymond F. Boyce después de conocer el modelo relacional de Edgar F. Codd a principios de la década de 1970. Esta versión, inicialmente llamada SEQUEL (Structured English Query Language), fue diseñada para manipular y recuperar datos almacenados en el sistema de gestión de base de datos cuasirelacional original de IBM, System R, que un grupo del Laboratorio de Investigación de IBM San Jose había desarrollado durante la década de 1970..

El primer intento de Chamberlin y Boyce de un lenguaje de base de datos relacional fue SQUARE (Especificación de consultas en un entorno relacional), pero era difícil de usar debido a la notación de subíndice/superíndice. Después de mudarse al Laboratorio de Investigación de San José en 1973, comenzaron a trabajar en una secuela de SQUARE. El nombre original SEQUEL, que se considera un juego de palabras con QUEL, el lenguaje de consulta de Ingres, se cambió más tarde a SQL (eliminando las vocales) porque "SEQUEL" era una marca comercial de la empresa Hawker Siddeley Dynamics Engineering Limited con sede en el Reino Unido. La etiqueta SQL más tarde se convirtió en el acrónimo de Structured Query Language.

Después de probar SQL en sitios de prueba de clientes para determinar la utilidad y practicidad del sistema, IBM comenzó a desarrollar productos comerciales basados en su prototipo System R, incluidos System/38, SQL/DS e IBM Db2, que estaban disponibles comercialmente en 1979, 1981 y 1983, respectivamente.

A fines de la década de 1970, Relational Software, Inc. (ahora Oracle Corporation) vio el potencial de los conceptos descritos por Codd, Chamberlin y Boyce, y desarrolló su propio RDBMS basado en SQL con aspiraciones de venderlo a la Marina de los EE. UU., la Agencia Central de Inteligencia y otras agencias del gobierno de los Estados Unidos. En junio de 1979, Relational Software presentó una de las primeras implementaciones comerciales de SQL, Oracle V2 (Versión 2) para computadoras VAX.

En 1986, los grupos de estándares ANSI e ISO adoptaron oficialmente el estándar "Database Language SQL" definición de lenguaje. Se publicaron nuevas versiones del estándar en 1989, 1992, 1996, 1999, 2003, 2006, 2008, 2011 y, más recientemente, en 2016.

Sintaxis

UPDATEclause:{}UPDATEcountries⏞ ⏞ table}SETclause:{}SETpopulation⏞ ⏞ column=population+1⏟ ⏟ literal⏞ ⏞ expression}WHEREclause:{}WHEREname⏞ ⏞ column=.USA.⏞ ⏞ literal⏞ ⏞ expression⏟ ⏟ predicate};}declaración⏟ ⏟ SQLquerSí.{displaystyle underbrace {left.{begin{array}{rl}textstyle {fnMittt {fnMittt {fnh}}}} {\\\mtttt {\\fnMittt {f}}}\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\fn}}}}}\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\fn}}}}}}}}\\\\\\\\\\\\\ {\fnMittt {fnMittt} {fnMittt {\fnMittt {f}} {fnMittt {fnMittt}} {fnK} ^{Mathtt {colum # Sobrebrace {Mathtt {{population}+underbrace {fnhtt {}}\\\fnK}}\\\\\\\\\\\\\fnMitttt {}}}\\\\\\\\\\\\\fnK\\\\\\\fnhnh0h0h0hnhnhnhnKh0hKh0h3nKh0h0h0hKh0h9}}}}}}\\\\\\\\\\sh9}}}}}}\\\\\\\\\\\\\\\\\\sh9}}}}\\\\\\\\\\\\\\\\ {fnh} {fnh} {fnh} {\fnh} {\fnh} {\fnh} {fnh} {\fnh} {fnh}} {fnh} {fn}}\fnh}\fnh}}\fnh}}}\\\\fnhnh}}}\\\fnhnh}}}\\\\fnH0}}}}\\\\]}}}}}}}}}}}}}}\\\\\\\\\\\\\\\\\\\\\]}}}}}}}}}}}tttttttttttttttttttttttttttttttt}} {fnMitt {fnh}} {fnMittt {f}}\ftt {f}}}end{array}}}right}{f}{hmestilo {textttt {statement}}} - ¿Qué?

Un gráfico que muestra varios de los elementos del lenguaje SQL que componen una sola declaración

El lenguaje SQL se subdivide en varios elementos del lenguaje, que incluyen:

• Cláusulas, que son componentes constitutivos de declaraciones y consultas. (En algunos casos, son opcionales).
• Expresiones, que puede producir valores de escalar, o tablas consistentes en columnas y filas de datos
• Predicados, que especifica las condiciones que pueden ser evaluadas a la lógica de tres valores SQL (3VL) (true/false/unknown) o valores de la verdad booleana y se utilizan para limitar los efectos de las declaraciones y consultas, o para cambiar el flujo del programa.
• Consultas, que recupera los datos basados en criterios específicos. Este es un elemento importante SQL.
• Declaraciones, que puede tener un efecto persistente en los esquemas y datos, o puede controlar transacciones, flujo de programas, conexiones, sesiones o diagnósticos.
  • Las declaraciones SQL también incluyen el rescindor de declaración semicolon (";"). Aunque no se requiere en cada plataforma, se define como una parte estándar de la gramática SQL.
• Espacio blanco insignificante es generalmente ignorado en las declaraciones y consultas SQL, haciendo más fácil formatear código SQL para la legibilidad.

Extensiones de procedimiento

SQL está diseñado para un propósito específico: consultar datos contenidos en una base de datos relacional. SQL es un lenguaje de programación declarativo basado en conjuntos, no un lenguaje de programación imperativo como C o BASIC. Sin embargo, las extensiones de SQL estándar agregan funciones de lenguaje de programación de procedimientos, como construcciones de control de flujo. Éstos incluyen:

Además de las extensiones SQL/PSM estándar y las extensiones SQL propietarias, la programación orientada a objetos y de procedimientos está disponible en muchas plataformas SQL a través de la integración de DBMS con otros lenguajes. El estándar SQL define extensiones SQL/JRT (rutinas y tipos SQL para el lenguaje de programación Java) para admitir código Java en bases de datos SQL. Microsoft SQL Server 2005 usa SQLCLR (SQL Server Common Language Runtime) para hospedar ensamblados.NET administrados en la base de datos, mientras que las versiones anteriores de SQL Server estaban restringidas a procedimientos almacenados extendidos no administrados escritos principalmente en C. PostgreSQL permite a los usuarios escribir funciones en una amplia variedad de lenguajes, incluidos Perl, Python, Tcl, JavaScript (PL/V8) y C.

Interoperabilidad y estandarización

Resumen

Las implementaciones de SQL son incompatibles entre proveedores y no necesariamente siguen completamente los estándares. En particular, la sintaxis de fecha y hora, la concatenación de cadenas, NULLs y la distinción entre mayúsculas y minúsculas varían de un proveedor a otro. PostgreSQL y Mimer SQL se esfuerzan por cumplir con los estándares, aunque PostgreSQL no se adhiere al estándar en todos los casos. Por ejemplo, el doblado de nombres sin comillas a minúsculas en PostgreSQL es incompatible con el estándar SQL, que dice que los nombres sin comillas deben doblarse a mayúsculas. Por lo tanto, Foo debería ser equivalente a FOO y no a foo según el estándar.

Las implementaciones populares de SQL suelen omitir la compatibilidad con las funciones básicas de SQL estándar, como los tipos de datos DATE o TIME. Los ejemplos más obvios y, por cierto, los DBMS comerciales y patentados de SQL más populares son Oracle (cuyo DATE se comporta como DATETIME y carece de TIME tipo) y MS SQL Server (antes de la versión 2008). Como resultado, el código SQL rara vez se puede transferir entre sistemas de bases de datos sin modificaciones.

Razones de incompatibilidad

Varias razones de la falta de portabilidad entre sistemas de bases de datos incluyen:

• La complejidad y el tamaño del estándar SQL significa que la mayoría de los implementadores no soportan todo el estándar.
• El estándar no especifica el comportamiento de la base de datos en varias áreas importantes (por ejemplo, índices, almacenamiento de archivos...), dejando implementaciones para decidir cómo comportarse.
• El estándar SQL especifica precisamente la sintaxis de que un sistema de base de datos de conformación debe implementar. Sin embargo, la especificación de la semántica de las construcciones lingüísticas es menos bien definida, lo que conduce a la ambigüedad.
• Muchos proveedores de bases de datos tienen grandes bases de clientes existentes; donde la versión más reciente del estándar SQL conflictos con el comportamiento previo de la base de datos del proveedor, el proveedor puede no estar dispuesto a romper la compatibilidad atrasada.
• Existe un pequeño incentivo comercial para que los proveedores de bases de datos cambien de forma más fácil (véase el bloqueo de proveedores).
• Los usuarios que evalúan el software de bases de datos tienden a situar otros factores como el rendimiento más alto en sus prioridades que la conformidad de normas.

Historial de estandarización

SQL fue adoptado como estándar por ANSI en 1986 como SQL-86 e ISO en 1987. Lo mantiene ISO/IEC JTC 1, Tecnología de la información, Subcomité SC 32, Gestión e intercambio de datos.

Hasta 1996, el programa de estándares de administración de datos del Instituto Nacional de Estándares y Tecnología (NIST) certificaba el cumplimiento de SQL DBMS con el estándar SQL. Los proveedores ahora autocertifican el cumplimiento de sus productos.

El estándar original declaraba que la pronunciación oficial de "SQL" era una sigla: ("ess cue el"). Independientemente, muchos profesionales de bases de datos de habla inglesa (incluido el propio Donald Chamberlin) usan la pronunciación similar a un acrónimo de ("sequel"), reflejando el nombre de desarrollo preliminar del idioma, "SEQUEL".
El estándar SQL ha pasado por varias revisiones:

Estándar actual

La norma suele indicarse con el patrón: ISO/IEC DIS 9075-n:yyyy Parte n: título o, como abreviatura, ISO/IEC 9075 (El término 'DIS' no se usa en versiones anteriores). Las partes interesadas pueden adquirir los documentos de normas de ISO, IEC o ANSI. Algunos borradores antiguos están disponibles gratuitamente.

ISO/IEC 9075 se complementa con ISO/IEC 13249: SQL Multimedia and Application Packages y algunos informes técnicos.

Anatomía del estándar SQL

El estándar SQL se divide en 10 partes, pero con lagunas en la numeración debido a la retirada de partes obsoletas.

Extensiones del estándar SQL

ISO/IEC 9075 se complementa con ISO/IEC 13249 Paquetes de aplicaciones y multimedia SQL. Este estándar estrechamente relacionado pero separado es desarrollado por el mismo comité. Define interfaces y paquetes basados en SQL. El objetivo es el acceso unificado a aplicaciones típicas de bases de datos como texto, imágenes, extracción de datos o datos espaciales.

Informes técnicos

ISO/IEC 9075 también va acompañado de una serie de Informes técnicos, publicados como ISO/IEC TR 19075. Estos Informes técnicos explican la justificación y el uso de algunas características de SQL y brindan ejemplos cuando corresponde. Los Informes Técnicos no son normativos; si hay alguna discrepancia con 9075, se mantiene el texto en 9075. Los informes técnicos 19075 actualmente disponibles son:

Alternativas

Debe hacerse una distinción entre las alternativas a SQL como lenguaje y las alternativas al modelo relacional en sí. A continuación se proponen alternativas relacionales al lenguaje SQL. Consulte la base de datos de navegación y NoSQL para obtener alternativas al modelo relacional.

Procesamiento de SQL distribuido

La arquitectura de base de datos relacional distribuida (DRDA) fue diseñada por un grupo de trabajo dentro de IBM entre 1988 y 1994. DRDA permite que las bases de datos relacionales conectadas a la red cooperen para cumplir con las solicitudes de SQL.

Un usuario o programa interactivo puede emitir sentencias SQL a una RDB local y recibir tablas de datos e indicadores de estado en respuesta desde RDB remotas. Las declaraciones SQL también se pueden compilar y almacenar en RDB remotos como paquetes y luego invocarse por nombre de paquete. Esto es importante para el funcionamiento eficiente de los programas de aplicación que emiten consultas complejas de alta frecuencia. Es especialmente importante cuando las tablas a las que se accede se encuentran en sistemas remotos.

Los mensajes, protocolos y componentes estructurales de DRDA están definidos por la arquitectura de administración de datos distribuidos. El procesamiento SQL distribuido ala DRDA se distingue de las bases de datos SQL distribuidas contemporáneas.

Críticas

Diseño

SQL se desvía de varias maneras de su fundamento teórico, el modelo relacional y su cálculo de tuplas. En ese modelo, una tabla es un conjunto de tuplas, mientras que en SQL, las tablas y los resultados de las consultas son listas de filas; la misma fila puede aparecer varias veces, y el orden de las filas se puede emplear en las consultas (por ejemplo, en la cláusula LIMIT). Los críticos argumentan que SQL debería ser reemplazado por un lenguaje que regrese estrictamente a la base original: por ejemplo, vea El Tercer Manifiesto.

Ortogonalidad y completitud

Las primeras especificaciones no admitían funciones importantes, como claves principales. No se pudieron nombrar los conjuntos de resultados y no se definieron las subconsultas. Estos se agregaron en 1992.

La falta de tipos de suma se ha descrito como un obstáculo para el uso completo de los tipos definidos por el usuario de SQL. La compatibilidad con JSON, por ejemplo, debía agregarse mediante un nuevo estándar en 2016.

Nulo

El concepto de Nulo es objeto de algunos debates. El marcador Nulo indica la ausencia de un valor y es distinto de un valor de 0 para una columna de enteros o una cadena vacía para una columna de texto. El concepto de Nulls aplica la lógica de 3 valores en SQL, que es una implementación concreta de la lógica general de 3 valores.

Duplicados

Otra crítica popular es que permite filas duplicadas, lo que dificulta la integración con lenguajes como Python, cuyos tipos de datos pueden dificultar la representación precisa de los datos, en términos de análisis y por la ausencia de modularidad. Esto generalmente se evita declarando una clave principal, o una restricción única, con una o más columnas que identifican de forma única una fila en la tabla.

Desajuste de impedancia

En un sentido similar al desajuste de impedancia objeto-relacional, se produce un desajuste entre el lenguaje SQL declarativo y los lenguajes de procedimiento en los que SQL suele estar incrustado.

Tipos de datos SQL

El estándar SQL define tres tipos de tipos de datos:

• tipos de datos predefinidos
• tipos construidos
• tipos definidos por el usuario.

Los tipos construidos son ARRAY, MULTISET, REF(erence) o ROW. Los tipos definidos por el usuario son comparables a las clases en lenguaje orientado a objetos con sus propios constructores, observadores, mutadores, métodos, herencia, sobrecarga, sobreescritura, interfaces, etc. Los tipos de datos predefinidos son intrínsecamente compatibles con la implementación.

Tipos de datos predefinidos