Una base de datos es un conjunto organizado de datos estructurados que se almacenan en un sistema informático para facilitar su acceso, gestión, actualización y análisis. A diferencia de un archivo de texto plano o una hoja de cálculo simple, una base de datos permite relacionar información entre sí, reducir la redundancia y garantizar la consistencia de los datos mediante reglas específicas. Esta organización es fundamental para que las aplicaciones modernas, desde redes sociales hasta sistemas bancarios, puedan funcionar con eficiencia y escalabilidad.

El motor que gestiona esta organización se conoce como Sistema de Gestión de Bases de Datos (SGBD). El SGBD actúa como intermediario entre los datos almacenados en el disco duro y las aplicaciones que necesitan leerlos o escribirlos. Sin este sistema, los datos serían una colección caótica de bits difíciles de interpretar y actualizar sin errores. La importancia de las bases de datos radica en su capacidad para transformar datos crudos en información útil y accesible en tiempo real.

Definición y concepto

Una base de datos es una colección estructurada de información almacenada electrónicamente, diseñada para facilitar la recuperación, modificación y análisis de los datos. No se trata simplemente de archivos apilados, sino de un sistema donde los elementos guardan relaciones lógicas entre sí. Esta organización permite que múltiples usuarios accedan a la información simultáneamente sin que los datos se desintegren o se vuelvan inconsistentes.

Es común confundir una base de datos con una hoja de cálculo, pero las diferencias son estructurales. Una hoja de cálculo, como las de Excel, es ideal para cálculos lineales y vistas estáticas; sin embargo, cuando los datos crecen o varios usuarios editan al mismo tiempo, aparecen errores de versión y lentitud. Una base de datos, en cambio, gestiona grandes volúmenes de información mediante tablas interconectadas, optimizando el almacenamiento y la consulta. La escalabilidad es la clave: mientras la hoja de cálculo se vuelve pesada, la base de datos mantiene su eficiencia.

El rol del SGBD

Para interactuar con la base de datos sin tocar cada archivo individualmente, se utiliza un Sistema de Gestión de Bases de Datos (SGBD). Este software actúa como intermediario entre los usuarios (o aplicaciones) y los datos almacenados en el disco duro. El SGBD traduce las peticiones del usuario en instrucciones que la computadora puede entender, asegurando que la información se guarde, se busque y se actualice correctamente.

Ejemplos de SGBD populares incluyen MySQL, PostgreSQL y Oracle. Estos sistemas manejan tareas complejas como la indexación para acelerar las búsquedas o el bloqueo de registros para evitar conflictos cuando dos personas editan el mismo dato a la vez. Sin el SGBD, gestionar los datos requeriría un esfuerzo manual considerable y propenso a errores humanos.

Dato curioso: El concepto moderno de base de datos relacional fue propuesto por Edgar F. Codd en 1970, quien sugirió organizar los datos en tablas con filas y columnas, una estructura que sigue siendo estándar hoy en día.

Integridad, redundancia e independencia

La calidad de una base de datos se mide por tres pilares fundamentales: integridad, redundancia e independencia. La integridad asegura que los datos sean precisos y coherentes. Por ejemplo, si un cliente tiene un número de identificación único, la integridad impide que otro cliente tenga el mismo número o que se guarde una fecha de nacimiento futura. Esto se logra mediante reglas predefinidas en el SGBD.

La redundancia se refiere a la repetición de datos. En una base de datos bien diseñada, la redundancia se minimiza para ahorrar espacio y evitar inconsistencias. Si el nombre de un cliente aparece en diez tablas distintas y se cambia en solo una, los datos quedan desincronizados. Reducir esta duplicación mejora la eficiencia del sistema.

Finalmente, la independencia de los datos permite que los cambios en el almacenamiento físico o en la estructura lógica no afecten necesariamente a las aplicaciones que usan los datos. Si se cambia el tipo de disco duro donde se guardan los datos, la aplicación web que los muestra puede seguir funcionando sin necesidad de reescribir todo el código. Esta flexibilidad es crucial para la evolución tecnológica de los sistemas de información.

Historia y evolución tecnológica. Imagen: Siemens Pressebild / Wikimedia Commons / CC BY-SA 3.0

Historia y evolución tecnológica

El almacenamiento de datos no siempre fue tan estructurado como lo conocemos hoy. En las décadas de 1950 y 1960, las computadoras dependían de los llamados archivos planos. Estos consistían en simples secuencias de registros almacenados en cintas o discos magnéticos, donde la relación entre los datos dependía más de la lógica del programa que leía el archivo que del propio archivo. La redundancia era el enemigo principal: si un dato cambiaba, había que actualizarlo en múltiples lugares, lo que generaba errores constantes.

Modelos jerárquico y de red

Para ordenar el caos, surgieron los primeros modelos formales. El modelo jerárquico, popularizado por IBM con su sistema IMS (Information Management System), organizaba los datos como un árbol genealógico. Cada registro hijo tenía un solo padre. Era eficiente para leer, pero rígido para expandir. Poco después, el modelo de red permitió que un registro tuviera múltiples padres, ofreciendo mayor flexibilidad. Sin embargo, ambos modelos exigían que el programador conociera la estructura física de los datos para extraer información, lo que acoplaba estrechamente el software con la base de datos.

La revolución relacional

El punto de inflexión llegó en 1970, cuando Edgar F. Codd, un investigador de IBM, publicó su artículo seminal. Propuso el modelo relacional, que trataba los datos como tablas matemáticas (relaciones) conectadas por claves comunes. Esta abstracción liberó a los programadores de la complejidad física del almacenamiento. La consecuencia es directa: la estructura de los datos se separó de la lógica de la aplicación.

Dato curioso: Aunque Codd propuso el modelo en 1970, el sistema relacional no se convirtió en el estándar de la industria hasta la década de 1980, gracias a la llegada de SQL (Structured Query Language) y el éxito comercial de sistemas como Oracle y MySQL.

Este modelo dominó el panorama durante casi cuatro décadas. Su fuerza radicaba en la consistencia y la capacidad de gestionar transacciones complejas, esencial para la banca y la contabilidad. La teoría de conjuntos subyacente permitía consultas poderosas sobre grandes volúmenes de datos estructurados.

La era NoSQL y Big Data

Hacia finales de los años 2000, el auge de la web 2.0 y la necesidad de procesar enormes volúmenes de datos semiestructurados desafiaron la rigidez relacional. Alrededor de 2009 y 2010, surgió el término NoSQL (No Only SQL) para describir una nueva generación de bases de datos diseñadas para la escalabilidad horizontal. Sistemas como MongoDB, Cassandra o Redis priorizaban la velocidad y la flexibilidad sobre la consistencia estricta en tiempo real.

Esta evolución no significó la muerte del modelo relacional, sino su complemento. Mientras que las bases de datos relacionales siguen siendo el rey para los datos transaccionales, las soluciones NoSQL dominan en el análisis de grandes volúmenes de datos donde la estructura puede variar constantemente. La elección tecnológica depende ahora más de la naturaleza de los datos que de la tradición histórica.

¿Cómo se estructuran los datos en una base de datos?

La estructura de una base de datos no es caótica; se organiza mediante capas de abstracción que ocultan la complejidad técnica al usuario final. Esta arquitectura en tres niveles permite que los datos cambien en el disco sin que el usuario note la diferencia, o que varios usuarios vean versiones distintas de la misma información sin interferencias. Comprender estos niveles es fundamental para diseñar sistemas eficientes.

Los tres niveles de abstracción

El modelo relacional estándar divide la organización de la información en tres capas jerárquicas. En la base se encuentra el nivel físico, donde los datos residen en el almacenamiento (discos duros, SSDs o memoria RAM). Aquí, la información se traduce en bits, bloques y páginas. El usuario raramente interactúa con este nivel, salvo cuando optimiza el rendimiento leyendo archivos.dat o índices B-Tree.

Por encima está el nivel lógico, el corazón del modelo relacional. Define qué datos se almacenan y cómo se relacionan, independientemente de cómo se guardan físicamente. Se organiza en tablas (o relaciones), donde cada fila es un registro y cada columna es un atributo o campo. Las claves primarias identifican cada registro de forma única, mientras que las claves foráneas crean puentes entre tablas distintas.

Finalmente, el nivel de vista es la interfaz que ve el usuario o la aplicación. Puede mostrar solo una porción de los datos lógicos. Por ejemplo, un estudiante ve sus notas, pero el profesor ve las calificaciones completas y el promedio de la clase, aunque ambos consultan la misma base de datos lógica.

Nivel Enfoque principal Ejemplo concreto
Físico Cómo se guardan los bits en el disco Páginas de 4 KB, bloques de memoria, índices B-Tree
Lógico Estructura de tablas y relaciones Tabla Alumnos con columnas: ID, Nombre, Edad
Vista Lo que ve el usuario o la aplicación El alumno ve solo su nombre y nota final

Conceptos clave: registros, campos y claves

Un registro es una fila completa en una tabla, representando una entidad concreta, como un alumno o un producto. Cada registro está compuesto por campos (columnas), que definen sus atributos. Por ejemplo, en la tabla Alumnos, los campos podrían ser Matricula, Nombre y Correo.

La clave primaria es el campo (o conjunto de campos) que identifica de forma única a cada registro. No puede haber dos alumnos con la misma matrícula. Esta clave garantiza la integridad de los datos. Por su parte, una clave foránea es un campo que hace referencia a la clave primaria de otra tabla, estableciendo una relación. Si la tabla Notas tiene un campo ID_Alumno, ese campo es una clave foránea que vincula cada nota con un alumno específico.

Dato curioso: El concepto de clave foránea fue introducido por Edgar F. Codd en 1970, cuando presentó el modelo relacional. Antes de eso, las bases de datos dependían de estructuras más rígidas, como el modelo jerárquico, donde las relaciones eran más difíciles de gestionar.

La consecuencia de usar claves bien definidas es directa: sin ellas, los datos se duplican, se pierden o se vuelven difíciles de actualizar. Un diseño lógico sólido reduce la redundancia y mejora la consistencia, permitiendo que las aplicaciones funcionen con mayor precisión y velocidad.

Tipos de bases de datos: relacionales vs NoSQL

La arquitectura de una base de datos define cómo se almacenan, organizan y recuperan los datos. Históricamente, el modelo relacional dominó la escena, pero la explosión de datos no estructurados en la era digital impulsó la aparición de las bases de datos NoSQL. Comprender la diferencia es fundamental para elegir la tecnología adecuada según las necesidades específicas de un sistema.

Bases de datos relacionales (SQL)

Las bases de datos relacionales organizan la información en tablas con filas y columnas, vinculadas mediante claves primarias y foráneas. Este modelo se basa en el álgebra relacional y utiliza un esquema fijo, lo que significa que la estructura de los datos debe definirse antes de insertarlos. Lenguajes como SQL (Structured Query Language) permiten realizar consultas complejas y garantizar la integridad de los datos a través del modelo ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad).

Sistemas como MySQL y PostgreSQL son ejemplos clásicos. Son ideales cuando la estructura de los datos es predecible y la consistencia es crítica, como en sistemas bancarios o de gestión de inventarios. La rigidez del esquema puede ser una ventaja, ya que evita errores de tipo de dato, pero puede volverse costoso si los datos cambian frecuentemente.

Bases de datos NoSQL

El término NoSQL, que significa "No Solo SQL", abarca una variedad de modelos de datos diseñados para ofrecer flexibilidad y escalabilidad horizontal. A diferencia de las relacionales, no requieren un esquema fijo, lo que permite almacenar datos diversos en una misma colección. Los principales tipos incluyen:

Las bases de datos NoSQL suelen priorizar la escalabilidad horizontal (añadir más servidores) y la velocidad de lectura/escritura, a veces sacrificando la consistencia inmediata a cambio de la consistencia eventual, según el teorema CAP.

Tecnología Tipo Característica Principal Uso Típico
MySQL Relacional Esquema fijo, ACID Sistemas transaccionales
PostgreSQL Relacional Extensibilidad, JSON integrado Datos complejos y geoespaciales
MongoDB Documento Flexibilidad de esquema Catálogos, contenido dinámico
Redis Clave-Valor Velocidad en memoria Caché, sesiones
Neo4j Gráfico Relaciones entre nodos Redes sociales, rutas
Dato curioso: El término "NoSQL" fue acuñado en 1998 por Carlo Stankov para su base de datos de código abierto, pero ganó popularidad en 2009 durante una conferencia organizada por Johan Helsing para describir bases de datos distribuidas que no usaban SQL como interfaz principal.

Cuándo usar cada una

La elección depende de la naturaleza de los datos y las necesidades de rendimiento. Si los datos tienen relaciones complejas y la consistencia es vital, una base de datos relacional como PostgreSQL suele ser la mejor opción. Por el contrario, si se necesita escalar rápidamente con datos que cambian de estructura, como en una aplicación móvil con millones de usuarios, una base de datos NoSQL como MongoDB ofrece mayor flexibilidad.

En muchos sistemas modernos, se utilizan ambas: una base de datos relacional para los datos maestros y una NoSQL para la velocidad de lectura o el almacenamiento de metadatos. Esta combinación permite aprovechar las fortalezas de cada paradigma. La decisión técnica debe basarse en un análisis detallado de los requisitos de escalabilidad, consistencia y complejidad de las consultas.

¿Qué es el lenguaje SQL y cómo funciona?

SQL, siglas de Structured Query Language (Lenguaje Estructurado de Consulta), es el estándar universal para gestionar bases de datos relacionales. A diferencia de los lenguajes de programación tradicionales, como Python o Java, SQL es declarativo: el usuario especifica qué datos se desean obtener o modificar, y el motor de la base de datos decide cómo ejecutar la operación de manera eficiente. Esta separación permite que las sentencias sean relativamente legibles por humanos, lo que facilita el mantenimiento del código a largo plazo.

Operaciones CRUD

La gestión de datos se resume en cuatro operaciones fundamentales conocidas como CRUD, por sus siglas en inglés: Create (Crear), Read (Leer), Update (Actualizar) y Delete (Borrar). Estas acciones permiten manipular la información almacenada en las tablas con precisión.

La operación Read utiliza la sentencia SELECT. Por ejemplo, para obtener el nombre y el correo de todos los usuarios, se escribe:

SELECT nombre, correo FROM usuarios;

Para Create, se emplea INSERT, que añade nuevas filas a una tabla. Un ejemplo concreto sería agregar un nuevo registro:

INSERT INTO usuarios (nombre, correo) VALUES ('Ana', 'ana@ejemplo.com');

La operación Update modifica datos existentes mediante UPDATE. Es crucial especificar qué fila cambiar para evitar modificar toda la tabla:

UPDATE usuarios SET correo = 'ana.nueva@ejemplo.com' WHERE nombre = 'Ana';

Finalmente, Delete elimina registros. La sentencia DELETE borra filas específicas. Si no se usa una condición, se borrarán todas las filas de la tabla:

DELETE FROM usuarios WHERE nombre = 'Ana';

Filtrado y unión de datos

La potencia de SQL radica en su capacidad para filtrar y combinar datos. La cláusula WHERE actúa como un filtro que selecciona solo las filas que cumplen una condición específica. Por ejemplo, SELECT * FROM productos WHERE precio > 100; devuelve todos los productos cuyo precio supera las 100 unidades monetarias.

Sabías que: La palabra clave SELECT proviene de la teoría de conjuntos en matemáticas, donde "seleccionar" significa extraer elementos que cumplen ciertas propiedades de un conjunto mayor.

Las bases de datos relacionales suelen dividir la información en varias tablas para reducir la redundancia. Para recuperar datos completos, se utilizan los JOINs. Un INNER JOIN combina filas de dos tablas cuando hay un valor coincidente en una columna común. Por ejemplo, para unir una tabla de pedidos con una de clientes por su ID:

SELECT clientes.nombre, pedidos.monto FROM clientes INNER JOIN pedidos ON clientes.id = pedidos.cliente_id;

Esta unión permite ver el nombre del cliente junto con el monto de su pedido, aunque la información esté almacenada en tablas distintas. Los JOINs son esenciales para transformar datos normalizados en vistas comprensibles para el usuario final.

El dominio de SQL es fundamental en campos como la ciencia de datos, la ingeniería de software y la analítica empresarial. Aprender a estructurar consultas eficientes reduce el tiempo de carga de los datos y optimiza el rendimiento de las aplicaciones. La lógica detrás de las sentencias SQL se basa en principios matemáticos, donde cada tabla se comporta como un conjunto y cada operación transforma esos conjuntos según reglas definidas.

Aplicaciones prácticas y casos de uso

Las bases de datos son el esqueleto invisible que sostiene la mayoría de los servicios digitales modernos. Su función va más allá del simple almacenamiento; permiten organizar, recuperar y relacionar datos a una velocidad que el cerebro humano apenas puede procesar. La elección del tipo de base de datos depende directamente de cómo se accede a la información y de qué tan crítica es su consistencia en un momento dado.

Gestión de relaciones y comercio electrónico

En las redes sociales, la estructura de datos más eficiente suele ser el grafo. Los usuarios son nodos y las amistades o interacciones son aristas. Esta estructura permite responder preguntas complejas como "¿quién es amigo de tu amigo?" con gran rapidez. Un ejemplo clásico es el algoritmo de sugerencias de amigos, que recorre estas conexiones para encontrar caminos cortos entre perfiles que aún no se conocen.

Sabías que: Las bases de datos relacionales tradicionales, muy usadas en el comercio electrónico, dependen de las propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) para garantizar que una transacción bancaria o una compra en línea no se quede a medias. Si el servidor falla justo al cobrar la tarjeta, la propiedad de Atomicidad asegura que el dinero vuelva a la cuenta o se reste definitivamente, evitando saldos fantasma.

El comercio electrónico utiliza estas bases de datos para sincronizar el inventario en tiempo real. Cuando dos compradores hacen clic en "Comprar" al mismo tiempo, el sistema debe bloquear temporalmente el producto para evitar vender dos unidades de un artículo único. Esta coordinación evita el sobreingreso y mantiene la confianza del cliente.

Identidad digital y seguridad en la nube

La identidad digital se construye sobre bases de datos que almacenan credenciales, preferencias y huellas digitales. En la nube, los modelos SaaS (Software como Servicio) permiten que múltiples empresas compartan la misma infraestructura de base de datos, separando los datos mediante identificadores únicos. Esto reduce costos y facilita las actualizaciones.

La ciberseguridad depende de la integuacidad de estos registros. Un ataque común, como la inyección de datos, intenta engañar a la base de datos para que revele información oculta. Para protegerse, las bases de datos modernas utilizan cifrado tanto en reposo como en tránsito. La fórmula de la entropía de Shannon mide la incertidumbre en los datos, lo que ayuda a determinar la fuerza de las claves de cifrado:

Donde es la entropía y es la probabilidad de cada símbolo. Una mayor entropía significa que la clave es más difícil de adivinar. La consecuencia es directa: sin una gestión rigurosa de estos datos, la identidad digital se vuelve frágil y vulnerable a la fragmentación.

Ejercicios resueltos

La teoría de las bases de datos cobra sentido cuando se aplica a problemas concretos. A continuación, se presentan ejercicios resueltos que abordan diseño de esquemas, consultas SQL y análisis de redundancia. Estos ejemplos ilustran cómo pasar de un concepto abstracto a una implementación funcional.

Diseño de esquema relacional para una biblioteca

Supongamos que debemos modelar una biblioteca pequeña. Necesitamos registrar libros, autores y los préstamos realizados. Un enfoque común es crear tres tablas principales para minimizar la repetición de datos.

La tabla Libros contendrá información básica como el título y el ISBN. La tabla Autores almacenará el nombre y la nacionalidad. Finalmente, la tabla Prestamos vinculará un libro específico con un autor y una fecha. Es crucial definir claves foráneas para mantener la integridad referencial. Por ejemplo, el campo id_libro en la tabla Prestamos debe existir previamente en la tabla Libros.

Dato curioso: En los inicios de las bases de datos relacionales, Edgar F. Codd propuso 12 reglas para definir qué tan "relacional" era un sistema. Muchas bases de datos modernas aún no cumplen con todas ellas, pero siguen siendo altamente eficientes.

Consulta SQL para filtrar por autor

Una vez creado el esquema, es necesario extraer información. Si queremos encontrar todos los libros escritos por "Gabriel García Márquez", debemos unir las tablas Libros y Autores a través de su relación.

La consulta SQL sería la siguiente:

SELECT L.titulo
FROM Libros L
JOIN Autores A ON L.id_autor = A.id_autor
WHERE A.nombre = 'Gabriel García Márquez';

Esta estructura permite navegar entre tablas sin necesidad de repetir el nombre del autor en cada registro de libro. La cláusula JOIN es fundamental para relacionar datos dispersos en diferentes tablas.

Análisis de redundancia: archivo plano vs. base de datos relacional

La redundancia es uno de los mayores enemigos de la eficiencia en las bases de datos. Consideremos un archivo plano donde cada línea representa un préstamo y contiene: ID_Prestamo, Titulo_Libro, Nombre_Autor, Fecha_Prestamo.

Si el libro "Cien años de soledad" se presta 50 veces, el nombre "Gabriel García Márquez" se repite 50 veces en el archivo plano. En una base de datos relacional, ese nombre se almacena una sola vez en la tabla Autores, y se hace referencia a él mediante un identificador único.

La fórmula para calcular la redundancia relativa es:

Si el archivo plano ocupa 1000 bytes y el espacio ocupado por el nombre del autor repetido es de 400 bytes, la redundancia sería del 40%. Este cálculo demuestra por qué las bases de datos relacionales ahorran espacio y reducen errores de actualización.

Identificación de clave primaria en una tabla de estudiantes

La clave primaria es un campo o conjunto de campos que identifica de forma única a cada registro en una tabla. En una tabla llamada Estudiantes con los campos Nombre, Apellido, Fecha_Nacimiento, Correo_Electronico, debemos elegir el mejor candidato.

Aunque Correo_Electronico suele ser único, puede cambiar con el tiempo. La combinación de Nombre y Apellido puede tener duplicados (varios "Juan Pérez"). Por lo tanto, una buena práctica es añadir un campo ID_Estudiante como clave primaria, que sea un número entero autoincrementable. Esto asegura que cada estudiante tenga un identificador inmutable y único.

La elección correcta de la clave primaria simplifica las consultas y mejora el rendimiento de la base de datos. Un error común es usar campos compuestos cuando un solo campo podría bastar, lo que complica las relaciones con otras tablas.

Preguntas frecuentes

¿Cuál es la diferencia principal entre una base de datos y una hoja de cálculo?

Una hoja de cálculo es ideal para cálculos rápidos y datos tabulares simples, pero pierde eficiencia con grandes volúmenes de información. Una base de datos está diseñada para manejar miles o millones de registros, permite el acceso simultáneo de varios usuarios y ofrece mayor integridad y relaciones complejas entre los datos.

¿Qué significa que una base de datos sea "relacional"?

Significa que los datos se organizan en tablas con filas y columnas, y que estas tablas se conectan entre sí mediante claves comunes. Por ejemplo, una tabla de "Clientes" puede relacionarse con una tabla de "Pedidos" usando el número de identificación del cliente, permitiendo saber qué compró cada persona sin repetir su nombre en cada pedido.

¿Es necesario saber SQL para trabajar con bases de datos?

Depende del tipo de base de datos. Para las bases de datos relacionales tradicionales, SQL (Lenguaje Estructurado de Consultas) es el estándar casi universal. Sin embargo, en las bases de datos NoSQL, a menudo se usan lenguajes de consulta específicos o incluso lenguajes de programación como JavaScript o Python, aunque conocer SQL sigue siendo una habilidad muy valiosa.

NoSQL se refiere a un grupo diverso de sistemas de bases de datos que no siguen el modelo de tablas rígido de SQL. Son populares porque ofrecen mayor flexibilidad para almacenar datos variados (como documentos JSON o grafos) y escalan fácilmente en servidores distribuidos, lo que las hace ideales para aplicaciones web modernas y grandes volúmenes de datos (Big Data).

¿Dónde se almacenan físicamente los datos?

Los datos se almacenan en dispositivos de almacenamiento físico, como discos duros mecánicos (HDD) o unidades de estado sólido (SSD), dentro de los servidores. En la era de la nube, estos servidores pueden estar en centros de datos remotos gestionados por proveedores como AWS, Google Cloud o Azure, pero el principio de almacenamiento físico sigue siendo el mismo.

Resumen

Las bases de datos son sistemas esenciales para almacenar y gestionar información de manera estructurada, permitiendo el acceso eficiente a grandes volúmenes de datos. Existen dos enfoques principales: las bases de datos relacionales, que usan tablas y el lenguaje SQL, y las bases de datos NoSQL, que ofrecen flexibilidad para datos menos estructurados. Comprender cómo se organizan y consultan estos datos es fundamental para el desarrollo de software y el análisis de información en la actualidad.