Chisme 92 del Lince: bases de datos NoSQL con datos que fallan

El Lince de la Noche lleva meses guardando lecturas de la cueva. Pero no todas llegan completas: a veces el sensor de luz no responde, una versión antigua del programa escribe temp en lugar de temperatura y, de vez en cuando, la micro:bit avisa de que tiene la batería baja.

—Los datos de ayer no cuadran —dijo el Lince, con el portátil abierto en la mesa—. Hay filas que no tienen luz y otras que tienen un campo raro.

—Las cosas fallan —respondió la Gata Montesa—. No podemos parar por eso. Lo que hacemos es guardar lo que llega y saber con qué lo hemos guardado.

El Lince miró la tabla de SQL del chisme anterior. Todas las filas tenían las mismas columnas, y los fallos no tenían sitio.

Bases de datos NoSQL: datos que no encajan en una tabla

En este chisme aprendemos las bases de datos NoSQL con los mismos datos del chisme 91: temperatura, luz y sonido de una micro:bit. Pero ahora cada lectura es un documento, un objeto con sus propios campos, y no todos los documentos tienen la misma forma.

Puedes probarlo aquí: simulador de bases de datos NoSQL.

Por qué este chisme

En un sensor real los fallos son normales. Un dato que falta, un formato antiguo o un error de conexión pasan todos los días en una estación de medida. Una tabla SQL obliga a decidir antes la forma de cada fila. Una colección de documentos acepta lo que llega, y eso la hace útil cuando los datos son variados.

El NoSQL no sustituye al SQL. Son herramientas distintas, y elegir entre una y otra es una decisión de ingeniería.

Cómo funciona

Cada lectura se guarda en JSON, un formato de texto con llaves, corchetes y pares campo: valor. Un documento completo se ve así:

{"fecha_hora": "2026-10-13 08:00:00", "temperatura": 19, "luz": 66, "sonido": 160}

Y un documento con un fallo, así:

{"fecha_hora": "2026-10-13 08:07:00", "temperatura": 20, "sonido": 41}

El segundo no tiene luz. En NoSQL eso es válido: el campo simplemente no existe. En SQL, la misma fila tendría un valor NULL, que significa «dato que falta», y no es lo mismo que un 0. Un sensor que no responde no es un sensor que mide 0 grados.

Para preguntar, el filtro NoSQL es también un objeto JSON. Por ejemplo, {"luz": {"$exists": false}} busca los documentos a los que les falta la luz, y {"aviso": {"$exists": true}} los que tienen un aviso.

Qué necesitamos

• Un ordenador con Chrome o Edge, sin instalar nada.
• Para el modo real, una micro:bit V2 con el programa de abajo. Es el mismo programa del chisme 91, con Bluetooth activado.

Construcción

En el simulador, el modo simulación genera una mañana de clase con fallos: casi todos los documentos son completos, pero algunos no tienen luz, otros usan el formato antiguo, hay avisos y errores de sensor. El censo de campos muestra cuántos documentos tienen cada uno.

En el modo real, cada línea de la micro:bit se convierte en un documento. Si una línea no tiene el formato esperado, se guarda igualmente como un documento de error con la línea original: nada se pierde.

El código

Programa de la micro:bit (MakeCode, JavaScript). Necesitas activar la extensión Bluetooth y elegir «No se requiere emparejamiento» en la configuración del proyecto:

bluetooth.startUartService()
basic.forever(function () {
    let linea = "" + input.temperature() + "," + input.lightLevel() + "," + input.soundLevel()
    bluetooth.uartWriteLine(linea)
    serial.writeLine(linea)
    basic.pause(1000)
})

Cómo probarlo

1. Toma 60 lecturas en el modo simulación.
2. Pulsa el ejemplo «Sin luz». Cuenta cuántos documentos devuelve.
3. Cambia a «Tabla SQL» y pulsa el mismo ejemplo. ¿Dan el mismo número?
4. Pulsa «Calor» en los dos motores. ¿Qué diferencia encuentras y por qué?

Qué estamos midiendo realmente

Los documentos no son medidas de precisión. Un dato que falta no es un cero; un error también es un dato, porque dice que hubo un problema. Y cambiar de formato tiene un precio: cualquier consulta tiene que saber que existen los dos nombres.

Si quieres ver cómo se encadenan sensor, dato, conjunto de datos y análisis, mira el chisme de entrada y salida, o el simulador de la ciudad inteligente, donde también hay datos que no siempre llegan.

Para el aula

• Toma 60 lecturas y cuenta a mano cuántos documentos tienen luz. Compruébalo con el censo.
• Escribe el mismo documento en dos formatos. ¿Qué filtro funciona con los dos?
• ¿Cuándo preferirías una tabla fija y cuándo una colección de documentos? Piensa en una agenda, en las notas de un alumno y en una estación meteorológica.
• Diseña un documento para un fallo de sensor que nunca hemos previsto. ¿Qué campos necesita?

Retos

• Reto 1: escribe un filtro que encuentre los documentos sin luz.
• Reto 2: encuentra los documentos con un aviso.
• Reto 3: encuentra los documentos que tienen temperatura o temp.
• Reto 4: encuentra los documentos de error con dos o más intentos.
• Reto 5: conecta la micro:bit y guarda un rato de datos de tu aula.

Qué hemos aprendido

Una tabla SQL decide antes la forma de todos los datos. Una colección de documentos acepta lo que llega, con sus campos y sus fallos. El Lince ya no tiene que elegir entre guardar todo o nada: guarda lo que llega y sabe explicarlo.

Prototipo educativo: las lecturas de la micro:bit no son medidas de laboratorio.