Nulo (SQL)

Nulo es un marcador especial usado en Structured Query Language (SQL) para indicar que un valor de datos no existe en la base de datos. Introducido por el creador del modelo de la base de datos relacional, E. F. Codd, SQL saques Nulos para realizar el requisito que todos los sistemas de gestión de la base de datos relacional verdaderos (RDBMS) apoyen una representación de "información ausente e información inaplicable". Codd también introdujo el uso de la Omega griega minúscula (ω) símbolo para representar Nulo en la teoría de la base de datos. también es la palabra clave reservada de un SQL solía identificar el marcador especial Nulo.

Nulo ha sido el foco de controversia y una fuente de debate debido a su lógica tres valorada asociada (3VL), requisitos especiales para su uso en junturas de SQL y el manejo especial requerido por funciones agregadas y SQL operadores que se agrupan. Aunque las funciones especiales y los predicados se proporcionen para manejar correctamente Nulls, los opositores sienten que la resolución de estas cuestiones introduce la complejidad innecesaria y la inconsistencia en el modelo relacional de bases de datos.

Historia

Nulo fue introducido por E. F. Codd como un método de representar datos ausentes en el modelo relacional. Codd más tarde reforzó su requisito que todos RDBMS apoyen Nulo para indicar datos ausentes en una serie de dos partes publicada en la revista ComputerWorld. Codd también introdujo una lógica (tres valorada) ternaria, consistiendo en los valores de la verdad La verdad es que Falsos, y Desconocidos, que estrechamente se ata al concepto del Nulo. El valor de la verdad Desconocido se genera siempre que Nulo es comparado con cualquier valor de datos, o con el otro Nulo.

Codd indicó en su 1990 reservan El Modelo Relacional para la Gestión de datos, la Versión 2 que el single Nulo encomendado por el estándar SQL era inadecuado, y debería ser sustituido por dos marcadores del Tipo nulo separados para indicar la razón por qué los datos fallan. Estos dos marcadores del Tipo nulo comúnmente se refieren como 'A-valores' y 'I-valores', representando 'Ausencia, Pero' y 'Ausencia Aplicable, Pero Inaplicable', respectivamente. La recomendación de Codd habría requerido que el sistema lógico del SQL se amplíe para acomodar un sistema lógico cuatro valorado. A causa de esta complejidad adicional, la idea de valores del Tipo nulo múltiples no ha ganado la aceptación extendida.

Lógica tres valorada (3VL)

Desde Nulo no es un miembro de ninguna esfera de datos, no se considera un "valor", pero mejor dicho un marcador (o placeholder) indicación de la ausencia de valor. A causa de esto, las comparaciones con el Nulo nunca pueden causar Verdadero o Falso, pero siempre en un tercer resultado lógico, Desconocido. El resultado lógico de la expresión abajo, que compara el valor 10 con el Nulo, es Desconocido:

SELECCIONE 10 = NULO - Causa Desconocido

</fuente>

Sin embargo, ciertas operaciones en valores de retorno de la lata Nulos si el valor de Nulo no es relevante para el resultado de la operación. Considere el ejemplo siguiente en el cual el O declaración se evalúa en la forma puesta en cortocircuito:

SELECCIONE VERDADERO O NULO - causa verdadero

</fuente>

En este caso, el hecho que el valor a la derecha O es incognoscible es irrelevante, porque el resultado del U OPERACIÓN Sería verdad sin tener en cuenta el valor a la derecha.

SQL pone en práctica tres resultados lógicos, por tanto las realizaciones SQL deben asegurar una lógica tres valorada especializada (3VL). Las reglas que gobiernan SQL que la lógica tres valorada se muestra en las mesas abajo (p y q representan estados lógicos)"

Los operadores de la comparación SQL básicos siempre vuelven Desconocido comparando algo con el Nulo, por tanto el estándar SQL asegura dos predicados de la comparación Nulos y específicos especiales. El y predicados prueban si los datos son o no son, Nulos.

Mecanografía de datos

Nulo se no escribe a máquina en SQL, significando que no se designa como un número entero, carácter o ningún otro tipo de datos específico. A causa de esto, es a veces obligatorio (o deseable) a explícitamente el converso Nulls a un tipo de datos específico. Por ejemplo, si las funciones sobrecargadas son apoyadas por el RDBMS, SQL no podría ser capaz de resolverse automáticamente a la función correcta sin saber los tipos de datos de todos los parámetros, incluso aquellos para los cuales Nulo se pasa.

Lengua de la manipulación de datos

SQL lógica tres valorada se encuentra en Data Manipulation Language (DML) en predicados de la comparación de declaraciones DML y preguntas. La cláusula hace que la declaración DML afecte a sólo aquellas filas para las cuales el predicado evalúa al Verdadero. Las filas para las cuales el predicado evalúa a Falso o a Desconocido no se interpretan a por, o declaraciones DML, y son desechadas por preguntas. Haciendo de intérprete Desconocido y Falso ya que el mismo resultado lógico es un error común encontrado tratando con Nulls. El ejemplo simple siguiente demuestra este error:

SELECCIONE *

DE t

DONDE yo = NULO;

</fuente>

La pregunta del ejemplo encima lógicamente siempre devuelve filas cero porque la comparación de yo que la columna con el Nulo siempre devuelve Desconocido, hasta para aquellas filas donde soy Nulo. El resultado Desconocido hace que la declaración deseche sumariamente todos y cada fila. (Sin embargo, en la práctica, algunos instrumentos SQL recuperarán filas usando una comparación con el Nulo.)

Expresiones del CASO

Las expresiones de SQL funcionan según las mismas reglas como las reglas de la cláusula DML para el Nulo. Como se puede evaluar como una serie de condiciones de la comparación de igualdad, una expresión simple no puede examinar para ver la existencia de Nulo directamente. Un control del Nulo en una expresión simple siempre resulta en el Desconocido, como en lo siguiente:

SELECCIONE EL CASO i CUANDO NULO ENTONCES 'es Nulo' - Esto nunca se devolverá

CUANDO 0 ENTONCES 'Sea el Cero' - Esto se devolverá cuando yo = 0

CUANDO 1 ENTONCES 'Sea Un' - Esto se devolverá cuando yo = 1

FINAL

DE t;

</fuente>

Como la expresión evalúa al Desconocido pase lo que pase valoran la columna i contiene (aun si contiene Nulo), la cuerda nunca se devolverá.

Una expresión buscada también devuelve el primer valor para el cual el resultado del predicado de la comparación evalúa a La verdad es que incluso comparaciones usando el y predicados de la comparación. El ejemplo siguiente muestra cómo usar una expresión buscada para comprobar correctamente el Nulo:

SELECCIONE EL CASO CUANDO sea NULO ENTONCES 'el Resultado Nulo' - Esto se devolverá cuando sea NULO

CUANDO yo = 0 ENTONCES 'Cero' - Esto se devolverá cuando yo = 0

CUANDO yo = 1 ENTONCES 'Un' - Esto se devolverá cuando yo = 1

FINAL

DE t;

</fuente>

En la expresión buscada, la cuerda se devuelve para todas las filas en las cuales soy Nulo.

Compruebe coacciones

El lugar primario en cual SQL la lógica tres valorada se cruza con Data Definition Language (DDL) SQL está en la forma de coacciones del control. Una coacción del control colocada en una columna funciona bajo un conjunto de reglas ligeramente diferente que aquellos para la cláusula DML. Mientras una cláusula DML debe evaluar al Verdadero para una fila, una coacción del control no debe evaluar al Falso. Esto significa que una coacción del control tendrá éxito si el resultado del control Es verdad o es Desconocido. La mesa del ejemplo siguiente con una coacción del control prohibirá a cualquier valor entero insertarse en la columna i, pero permitirá Nulo insertarse ya que el resultado del control siempre evaluará al Desconocido para Nulls.

CREE LA TABLA T (

yo NÚMERO ENTERO,

COACCIÓN ck_i CONTROL (yo

</fuente>

A fin de reprimir una columna a rechazar Nulls, la coacción se puede aplicar, como mostrado en el ejemplo abajo. La coacción es semánticamente equivalente a una coacción del control con un predicado.

CREE LA TABLA T (yo NÚMERO ENTERO NO NULO);

</fuente>

Extensiones procesales

SQL/PSM (SQL Módulos Almacenados Persistentes) define extensiones procesales para SQL, como la declaración. Sin embargo, los vendedores SQL principales han incluido históricamente sus propias extensiones procesales patentadas. Las extensiones procesales para colocación y comparaciones funcionan según las reglas de la comparación Nulas similares a aquellos para declaraciones DML y preguntas. El fragmento del código siguiente, en la ISO formato del estándar de SQL, demuestra el uso de Nulo 3VL en una declaración.

SI yo = NULO ENTONCES

ESCOGIDO 'El resultado Es verdad'

ELSEIF NO (yo = NULO) ENTONCES

ESCOGIDO 'El resultado es Falso'

MÁS

ESCOGIDO 'El resultado es Desconocido';

</fuente>

La declaración realiza acciones sólo para aquellas comparaciones que evalúan al Verdadero. Para declaraciones que evalúan a Falso o Desconocido, el control de pases de declaración a la cláusula, y finalmente a la cláusula. El resultado del código encima siempre será el mensaje ya que las comparaciones con el Nulo siempre evalúan al Desconocido.

Junturas

SQL junturas externas, incluso junturas externas izquierdas, junturas externas correctas, y junturas externas llenas, automáticamente producen Nulls como placeholders para perder valores en mesas relacionadas. Para junturas externas izquierdas, por ejemplo, Nulls se producen en el lugar de filas que faltan en la mesa que aparece a la derecha del operador. El ejemplo simple siguiente usa dos mesas para demostrar la producción placeholder Nula en una juntura externa izquierda.

La primera mesa (Empleado) contiene Números de identificación del empleado y nombres, mientras la segunda mesa (PhoneNumber) contiene Números de identificación del empleado relacionados y números de teléfonos, como mostrado abajo.

| valign = "cumbre" |

| }\

La muestra siguiente pregunta de SQL realiza una juntura externa izquierda en estas dos mesas.

SELECCIONE e. ID, e. LastName, e. FirstName, pn. Número

DE Empleado e

JUNTURA EXTERNA IZQUIERDA PhoneNumber pn

EN e. ID = pn. ID;

</fuente>

El resultado se puso generado por esta pregunta se manifiesta cómo usos de SQL Nulos como un placeholder para valores que faltan en la mesa (PhoneNumber) derecha, como mostrado abajo.

Las junturas interiores y las junturas enfadadas, también disponibles en SQL estándar, no generan placeholders Nulo para perder valores en mesas relacionadas.

El cuidado se debe tomar usando nullable columnas en criterios de la juntura de SQL. Como un Nulo no es igual a ninguno otro Nulo, Nulls en una columna de una mesa no se unirá a Nulls en la columna relacionada de otra mesa usando a los operadores de la comparación de igualdad estándares. La función de SQL o las expresiones pueden ser usadas "para simular" la igualdad Nula en criterios de la juntura, y el y los predicados se pueden usar en los criterios de la juntura también.

El predicado siguiente prueba de la igualdad de los valores A y B y convites Nulls como igual. Requieren al operador desde un = el B devuelve un valor Nulo si al menos un de A o B es Nulo y es Nulo él mismo.

IFNULL (UN = B, FALSO) O (A ES NULO Y B ES NULO)

</fuente>

Matemático y encadenamiento de la cuerda

Como Nulo no es un valor de datos, pero un marcador para un valor desconocido, usando a operadores matemáticos en resultados Nulos en un valor desconocido, que se representa por el Nulo. En el ejemplo siguiente, multiplicándose 10 por resultados Nulos en Nulo:

10 * NULO - el Resultado es NULO

</fuente>

Esto puede llevar a resultados inesperados. Por ejemplo, cuando una tentativa se hace dividirse Nulo en el cero, las plataformas pueden volver Nulo en vez de lanzar una "excepción de datos esperada - división por el cero". Aunque este comportamiento no sea definido por la ISO estándar de SQL muchos vendedores DBMS tratan esta operación de manera similar. Por ejemplo, el Oráculo, PostgreSQL, Servidor de MySQL y plataformas de Microsoft SQL Server toda la vuelta un resultado Nulo para lo siguiente:

NULO / 0

</fuente>

Las operaciones del encadenamiento de la cuerda, que son comunes en SQL, también resultan en el Nulo cuando uno de los operands es Nulo. El ejemplo siguiente demuestra el resultado Nulo devuelto usando Nulo con el operador del encadenamiento de la cuerda de SQL.

'El pescado' || NULO || 'Chips' - Resultado es NULO

</fuente>

Esto no es verdad para todas las realizaciones de la base de datos. En un Oráculo RDBMS por ejemplo NULOS y la cuerda vacía se consideran la misma cosa y por lo tanto 'Pescado' || NULO || 'los Chips' causan 'Chips de Pescado'.

Funciones agregadas

SQL define funciones agregadas para simplificar cálculos del conjunto del lado del servidor en datos. Casi todas las funciones agregadas realizan un paso de Eliminación nula, de modo que los valores Nulos no se incluyan en el resultado final del cálculo. Esta eliminación Nula implícita, sin embargo, puede tener un impacto a resultados de función agregados.

La mesa del ejemplo siguiente causa resultados diferentes devueltos para cada columna cuando el SQL función agregada (media) se aplica:

La función agregada SQL vuelve 233 cuando aplicado a la columna i, pero vuelve 175 cuando aplicado a la columna j. El paso de Eliminación nula de la función agregada explica la diferencia en estos resultados. La única función agregada que no elimina implícitamente Nulo es la función.

Agrupación y clasificación

Como define todos los marcadores Nulos como desiguales el uno al otro, se requirió una definición especial a fin de agrupar Nulls juntos realizando ciertas operaciones. SQL define "cualquier dos valor que sea igual el uno al otro o cualesquiera dos Nulls", como "no distinto". Esta definición de no distinto permite que SQL agrupe y clasifique Nulls cuando la cláusula (y otras palabras clave que realizan la agrupación) se usa.

Otras operaciones SQL, cláusulas y palabras clave usan "no distinto" en su tratamiento de Nulls. Éstos incluyen lo siguiente:

El estándar SQL no define explícitamente un pedido de la clase de la falta por Nulls. En cambio, en sistemas correspondientes, Nulls se puede clasificar antes o después de todos los valores de datos usando el o las cláusulas de la lista, respectivamente. No todos los vendedores DBMS ponen en práctica esta funcionalidad, sin embargo. Los vendedores que no ponen en práctica esta funcionalidad pueden especificar tratamientos diferentes por la clasificación Nula en el DBMS.

Efecto en operación del índice

Algunos productos SQL no ponen índice a llaves que contienen valores NULOS. Por ejemplo, las versiones de PostgreSQL antes de 8.3 no hicieron, con la documentación para un índice del B-árbol declarando esto

En casos donde el índice hace cumplir la unicidad, los valores NULOS se excluyen del índice y la unicidad no se hace cumplir entre valores NULOS. Otra vez, cotizando de la documentación de PostgreSQL:

Esto es consecuente con el comportamiento SQL:2003-definido de comparaciones Nulas escalares.

Otro método de poner índice a Nulls implica manejarlos como no distinto de acuerdo con el comportamiento SQL:2003-definido. Por ejemplo, la documentación de Microsoft SQL Server declara lo siguiente:

Ambos de estas estrategias de indexación son consecuentes con el comportamiento SQL:2003-definido de Nulls. Como las metodologías que ponen índice no son explícitamente definidas por el estándar SQL:2003, las estrategias que ponen índice para Nulls se dejan completamente a los vendedores diseñar y poner en práctica.

Funciones que se manejan del modo nulo

SQL define dos funciones para manejar explícitamente Nulls: y. Ambas funciones son abreviaturas para expresiones buscadas.

NULLIF

La función acepta dos parámetros. Si el primer parámetro es igual al segundo parámetro, vueltas Nulas. Por otra parte, el valor del primer parámetro se devuelve.

NULLIF (value1, value2)

</fuente>

Así, es una abreviatura para la expresión siguiente:

EL CASO CUANDO value1 = value2 ENTONCES NULO MÁS value1 TERMINAN

</fuente>

FUNDIRSE

La función acepta una lista de parámetros, devolviendo el primer valor no nulo de la lista:

FÚNDASE (value1, value2, value3...)

</fuente>

se define como la taquigrafía para la expresión SQL siguiente:

EL CASO CUANDO value1 no es NULO ENTONCES value1

CUANDO value2 no es NULO ENTONCES value2

CUANDO value3 no es NULO ENTONCES value3

...

FINAL

</fuente>

Algunos SQL DBMSs ponen en práctica funciones específicas para el vendedor similares a. Algunos sistemas (p.ej. Tramite-SQL) ponen en práctica una función u otras funciones similares que son funcionalmente similares a. (Ver que las funciones para más en las funciones en Tramitan-SQL.)

NVL

La función acepta dos parámetros. Devuelve el primer parámetro NO NULO o NULO si todos los parámetros son NULOS.

Una expresión se puede convertir en una expresión equivalente así:

FÚNDASE (val1..., val {n})

</fuente>

se convierte:

NVL (val1, NVL (val2, NVL (val3, …, NVL (val {n-1}, val {n}) …)))

</fuente>

Un caso de uso de esta función debe sustituir en una expresión un valor NULO por un valor fijo como en que dice, 'si contiene un valor NULO, sustitúyalo por 0'.

Hay, sin embargo, una excepción notable. En la mayor parte de realizaciones, evalúa sus parámetros hasta que alcance el primer NO NULO, mientras evalúa todos sus parámetros. Esto es importante por varios motivos. Un parámetro después del primer parámetro NO NULO podría ser una función, que podría ser o computacionalmente cara, inválida, o podría crear efectos secundarios inesperados.

Controversia

Errores comunes

El malentendido de cómo los trabajos Nulos son la causa de un gran número de errores en el código de SQL, tanto en el estándar de la ISO declaraciones de SQL como en los dialectos SQL específicos apoyados por sistemas de administración de bases de datos de mundo real. Estos errores son por lo general el resultado de confusión entre el Nulo y 0 (cero) o una cuerda vacía (un valor de la cuerda con una longitud del cero, representado en SQL como

Por ejemplo, una cláusula o la declaración condicional podrían comparar el valor de una columna con una constante. A menudo se supone incorrectamente que un valor ausente sería "menos que" o "no igual a" una constante si ese campo contiene Nulo, pero, de hecho, tal vuelta de expresiones Desconocida. Un ejemplo es abajo:

SELECCIONE *

DE sometable

DONDE num

- al contrario de las expectativas de muchos usuarios.

</fuente>

Los valores Nulos del mismo modo, a menudo se confunden con cuerdas vacías. Considere la función, que devuelve el número de caracteres en una cuerda. Cuando un Nulo se pasa en esta función, las vueltas de función Nulas. Esto puede llevar a resultados inesperados, si los usuarios no están bien versados en la lógica de 3 valores. Un ejemplo es abajo:

SELECCIONE *

DE sometable

DONDE LONGITUD (cuerda)

Esto es complicado por el hecho que en algunos programas del interfaz de la base de datos, NULOS se relata como una cuerda vacía, y las cuerdas vacías se pueden incorrectamente almacenar como NULAS.

Críticas

La ISO la realización de SQL del Nulo es el sujeto de crítica, debate y pide el cambio. En El Modelo Relacional para Gestión de datos: la Versión 2, Codd sugirió que la realización SQL del Nulo se estropeó y debería ser sustituida por dos marcadores del Tipo nulo distintos. Los marcadores que propuso debían significar "La ausencia, pero la" y "Ausencia Aplicable, pero Inaplicable", conocido como A-valores e I-valores, respectivamente. La recomendación de Codd, de ser aceptada, habría requerido la realización de una lógica cuatro valorada en SQL. Los otros han aconsejado añadir marcadores del Tipo nulo adicionales a la recomendación de Codd de indicar aún más motivos que un valor de datos podría "Fallar", aumentando la complejidad del sistema lógico del SQL. En varios tiempos, las ofertas también se han echado para poner en práctica marcadores Nulos definidos por los usuarios múltiples en SQL. A causa de la complejidad de los sistemas que se manejan del Modo nulo y lógicos requeridos apoyar marcadores Nulos múltiples, ninguna de estas ofertas ha ganado la aceptación extendida.

Chris Date y Hugh Darwen, los autores del Tercer Manifiesto, han sugerido que la realización Nula SQL intrínsecamente se estropea y se debería eliminar totalmente, señalando a inconsistencia y defectos en la realización del Manejo nulo SQL (en particular en funciones agregadas) como la prueba que el concepto entero del Nulo se estropea y se debería quitar del modelo relacional. Los otros, como el autor Fabian Pascal, han declarado una creencia que "cómo el cálculo de función debería tratar valores ausentes no es gobernada por el modelo relacional."

Asunción mundial cerrada

Otro punto del conflicto acerca de Nulls es que violan el modelo de la asunción mundial cerrado de bases de datos relacionales introduciendo una asunción mundial abierta en ello. La asunción mundial cerrada, ya que pertenece a bases de datos, declara que "Todo lo declarado por la base de datos, explícitamente o implícitamente, es verdad; todo lo demás es falso." Esta visión supone que el conocimiento del mundo almacenado dentro de una base de datos sea completo. Nulls, sin embargo, actúan bajo la asunción mundial abierta, en la cual algunos artículos almacenados en la base de datos se consideran desconocidos, haciendo el conocimiento almacenado de la base de datos del mundo incompleto.

Ley del medio excluido

SQL permite tres opciones lógicas, que son verdad, falsas, y desconocidas, el que significa que SQL necesariamente no hace caso de la ley del medio excluido. Puesto simplemente la Ley del Medio Excluido esencialmente declara que cuando dado cualquier resultado Booleano, la parte de enfrente del resultado se puede obtener aplicando el lógico "no" operador. Esto no se aplica a SQL nulls, sin embargo. Según los preceptos de la ley del medio excluido, una expresión Booleana como lo siguiente se puede simplificar:

SELECCIONE * DE la materia DONDE (x = 10) O NO (x = 10);

</fuente>

La ley del medio excluido tiene la simplificación en cuenta del DONDE el predicado de la cláusula, que causaría una declaración como lo siguiente:

SELECCIONE * DE la materia;

</fuente>

Esto no trabajará en SQL, ya que la columna x podría contener nulls que causaría algunas nuevas filas devueltas.

Realmente:

SELECCIONE * DE la materia;

- es (debido a 3VL) equivalente a:

SELECCIONE * DE la materia DONDE (x = 10) O NO (x = 10) O x es NULO;

</fuente>

Así, simplificar correctamente la primera declaración en SQL requiere que devolvamos todas las filas en las cuales x no es nulo.

SELECCIONE * DE la materia DONDE x no es NULO;

</fuente>

Mientras no hacer caso de la ley del medio excluido realmente introduce la complejidad adicional en la lógica SQL, tentativas de aplicar esta regla al SQL'S 3VL causa una dicotomía falsa.

Inconsistencia datatype booleana

La ISO estándar de SQL:1999 introdujo datatype Booleano en SQL. Datatype Booleano, como definido por el estándar, puede sostener los valores de la verdad LA VERDAD ES QUE FALSOS, y DESCONOCIDOS. Nulo se define en este caso como equivalente al valor de la verdad DESCONOCIDO.

Esto "nulo iguala la proposición" del valor de la verdad DESCONOCIDA introduce una inconsistencia en SQL 3VL. Un problema principal consiste en que contradice una propiedad básica de nulls, la propiedad de propagación. Nulls, por definición, se propagan a través de todas las expresiones SQL. Los valores de la verdad Booleanos no tienen esta propiedad. Considere los guiones siguientes en SQL:1999, en el cual dos valores de la verdad Booleanos se combinan en un predicado compuesto. Según las reglas de SQL 3VL, y como mostrado en el 3VL mesa de la verdad mostrada antes en este artículo, las declaraciones siguientes sostienen:

Sin embargo, porque nulls se propagan, tratando nulo como resultados DESCONOCIDOS en las inconsistencia lógicas siguientes en SQL 3VL:

El estándar SQL:1999 no define cómo tratar con esta inconsistencia, y los resultados podrían variar entre realizaciones. A causa de estas inconsistencia y carencia del apoyo de vendedores datatype Booleano SQL no ganó la aceptación extendida. La mayor parte de SQL DBMS plataformas ahora ofrecen sus propias recomendaciones específicas para la plataforma para almacenar datos del Tipo booleano.

Note que en la realización de PostgreSQL de SQL, el valor nulo es usado para representar todos los resultados DESCONOCIDOS y las evaluaciones siguientes ocurren:

MySQL se comporta de manera similar a PostgreSQL en este aspecto (con la excepción menor que MySQL considera VERDADERO y FALSO como no diferente de los números enteros ordinarios 1 y 0).

Véase también

Adelante lectura

Enlaces externos



Buscar