Estadísticas de Google Analytics

    generado por GADWP 

    Material registrado:

    Safe Creative #1709190281730

Hojas de cálculo y bases de datos

Las hojas de cálculo no son gestores de bases de datos

Muchos de los problemas que habitualmente plantean los usuarios de hojas de cálculo en los foros y blogs se enmarcan en el intento de usarlas como gestores de una base de datos, normalmente una base de datos pequeña, de una única tabla, y construida en una hoja del propio archivo de hoja de cálculo. Una tabla de este tipo tiene un formato simple cuya estructura columna-fila puede equivaler a la nomenclatura campo-registro de las bases de datos. El resultado es que, como los datos de la pequeña «base de datos» están guardados en un archivo de hoja de cálculo, se intenta usar a toda costa el propio programa de hoja de cálculo para mantenerla, y suele llegar el momento en que el usuario que desconoce los gestores de bases de datos se ve abocado a enredarse en complicadas construcciones de formularios con VBA para «simplificar» las operaciones de mantenimiento de la base de datos, incluso las de consulta más simple.

Si bien es cierto que con muchísimo trabajo, esto se puede llegar a hacer, y que además las hojas de cálculo permiten filtrar y ordenar con criterios amplios, este planteamiento me parece un error. Las hojas de cálculo no son gestores de bases de datos y si pretendemos hacerlas trabajar como tales, estaremos dándole un uso para el que no fueron concebidas y resolviendo a cañonazos problemas que un gestor de bases de datos resuelve con matamoscas. Mientras la tabla de datos tiene un tamaño moderado y las relaciones entre «campos», es decir entre encabezados de columna, no son complicadas, las cosas pueden tener un pase, pero en cuanto estas dos condiciones no se cumplen, la situación empieza a hacerse insostenible.

Gestores de bases de datos

Una base de datos es un conjunto de tablas relacionadas, cada una de ellas compuesta por campos y registros. La «gestión» de ese conjunto de datos relacionados supone crear la estructura eficaz que los almacene, alimentarla de datos y consultarla cuando se solicite, y todo esto debe hacerse con criterios de eficacia y seguridad.

Creación de una base de datos

La primera operación que hay que realizar con una base de datos es crearla: definir sus tablas, los campos de cada tabla y las relaciones entre ellas. Esto no se puede hacer una hoja de cálculo, salvo que se trate, insisto, de una única tabla simple y aceptemos que columna-fila equivale a campo-registro.

El programa adecuado es un gestor de bases de datos que nos permite definir correctamente los campos, con los tipos de datos que albergarán, y las tablas, marcando campos de claves primarias y relaciones entre tablas. Puede ser Access, OpenOffice Base, LibreOffice Base, mySQL…, cualquiera nos va a dar mucho mejor resultado que Excel o LibreOffice Calc. Puede ser también la versión Express del SQL Server de Microsoft.

Mantenimiento de una base de datos

Mantener una base de datos significa añadir, cambiar y borrar registros. Estas operaciones son muy delicadas y el personal autorizado a hacerlas debe estar bien identificado. Las hojas de cálculo no piden más pasaporte que una contraseña de apertura de archivo y quizás, otra de protección de la hoja, ambas fácilmente evitables para un usuario experto. Cualquiera de las aplicaciones que hemos mencionado es mucho mejor que las hojas de cálculo para estas tareas.

Además, en estas operaciones habrá que asegurarnos de que los datos introducidos en cada campo son los correctos según las restricciones establecidas. En hojas de cálculo la única herramienta que nos puede ayudar en esta labor es la validación de datos, cuyo manejo es engorroso y limitado, si lo comparamos con la elegancia y la fuerza de la definición de contenido de campos en los gestores de bases de datos. En una hoja de cálculo, por mucho que aquilatemos la validación, es muy difícil garantizar que datos incongruentes no terminarán en filas diferentes de la misma columna.

Consulta a una base de datos

La siguiente operación a realizar con bases de datos es la consulta. Aquí ya no estamos cambiando nada dentro de la base de datos, sino simplemente extrayendo datos sin modificarla.

Las hojas de cálculo pueden hacer esta operación y por ejemplo en el caso de Excel, incluso disponen de un menú de opciones que nos permite conectarnos a una base de datos local o remota, y descargar datos para consulta. Evidentemente la descarga deberá tener la forma de una o varias tablas simples bidimensionales, aunque en Excel, con los complementos llamados Power Utilities ahora también se pueden ver y gestionar las relaciones entre tablas y efectuar algunas operaciones propias de los gestores de bases de datos.

En cualquier caso, no conviene olvidar que los programas gestores de bases de datos que hemos mencionado están muy bien dotados nativamente para la consulta, y también aquí la realizarán de forma mucho más elegante y efectiva que las hojas de cálculo. Una sentencia SELECT del lenguaje SQL bien empleada en el gestor de bases de datos es siempre mejor que exportar datos a mansalva y tratar de seleccionarlos, por ejemplo en Excel mediante filtros, ordenaciones y formatos condicionales que al final suponen un tremendo galimatías.

Análisis de datos

Por fin llegamos al campo nativo de las hojas de cálculo. Los datos que queríamos ya están extraídos de la base de datos mediante una consulta y han sido llevados a nuestra hoja de cálculo. Ahora procedemos a analizarlos. Aquí ya nos hemos olvidado del programa gestor de base de datos porque pasamos a operar con datos, hacer gráficos, alimentar una aplicación de hoja de cálculo. Análisis y cálculo: este sí es el terreno en el que mandan las hojas de cálculo, y entre ellas destaca la reina: Excel. Estamos de acuerdo.

Dominios de acción para gestores de bases de datos y hojas de cálculo
Esquema propuesto del dominio ideal para gestores de bases de datos y hojas de cálculo

Limitaciones de las hojas de cálculo

Aun así, las hojas de cálculo y Excel sobre todas ellas, se usan como pequeña base de datos en muchas empresas. Estos usuarios deberían ser conscientes de que normalmente las bases de datos se deben gestionar con programas que satisfagan una serie de limitaciones que las hojas de cálculo, por su propia naturaleza, no satisfacen, y que yo clasifico en varios grupos:

  1. Acceso a los datos: es mucho más difícil asegurar que sólo la persona autorizada puede acceder y manipular los datos contenidos en un archivo de Excel. El único método general de protección es la contraseña de apertura, que es fácil de burlar. Internamente podemos también proteger y desproteger hojas y celdas, incluso ocultarlas con el método veryhidden con código, pero se trata de acciones muy ineficaces y realmente muy poco protectoras contra un atacante con conocimientos mínimos de Excel VBA.
  2. Consulta de los datos: en el caso de que existan usuarios que sólo pueden consultar, podemos crear un archivo de solo lectura, pero es un método muy engorroso y redundante. Para la obtención de informes debemos recurrir a filtros o búsquedas que resultan ridículos en comparación con la sólida eficacia de una simple sentencia SELECT FROM del lenguaje SQL
  3. Congruencia de los datos introducidos: el único método que Excel tiene para forzar la introducción de un tipo de datos determinado o restringido es el de validación, muchísimo más débil que la creación de campos a medida en las bases de datos. Es muy probable que datos incongruentes terminen en los mismos campos, algo intolerable en una base de datos de calidad mínima. Reflexiones similares podríamos hacer para el caso de registros repetidos. Es verdad que podríamos crear subrutinas VBA que nos avisaran, pero esto no es comparable con las capacidades nativas de los gestores de bases de datos.
  4. Relacionabilidad: Las hojas de cálculo, salvo quizás las Power Utilities de Excel, no tienen ninguna capacidad de establecer relaciones entre campos. Y ninguna es NINGUNA. Otra vez, ¡Vale! Se pueden elaborar estrategias a medida con código VBA para enlazar datos entre hojas. Sí, pero resulta tan penoso en comparación con la capacidad nativa de los gestores de bases de datos, que no vale la pena ni siquiera planteárselo.

En definitiva, las posibilidades de uso malicioso, errores no intencionados y corrupción de los datos almacenados en las hojas de cálculo son tantas, que no conviene usarlas como gestor de bases de datos en casi ninguna circunstancia mínimamente seria. Y ojo que a mí las hojas de cálculo me gustan mucho, pero he trabajado mucho en el estudio de sus límites.

Conclusión

Yo creo que todo usuario de hojas de cálculo se beneficiaría mucho de saber usar al menos un gestor de bases de datos, aparte de que se acostumbraría a tratar con más respeto a los procesos de almacenamiento y mantenimiento de los datos íntegros. El lenguaje de los gestores de bases de datos es, fundamentalmente, SQL: es un lenguaje simple y robusto, pero también un lenguaje que no se puede usar directamente con las funcionalidades nativas de hojas de cálculo, ni con Excel VBA; es un lenguaje que conserva todavía parte de aquel primitivo encanto de la informática MSDOS. Ni siquiera es necesario aprenderlo, pues los gestores de bases de datos suelen venir dotados con constructores de consultas en modo diseño arrastrar y soltar. Pero tener nociones básicas de SQL nos puede ahorrar muchísimo tiempo. He aquí un ejemplo práctico de lo que digo.

Y finalmente adjunto el código de la macro para quien lo quiera utilizar.

 

 

Sub Sel_Cols()

    ‘Trabajamos en una copia de la hoja
original

    ActiveSheet.Select:
ActiveSheet.Copy Before:=Sheets(
1)

    ‘Cargamos la selección de ENTRADA en un
rango

    Dim rngEntra As Range: Set rngEntra = Selection

    ‘Cargamos las posibles SALIDAS en otro
rango

    Dim rngSale As Range: Set rngSale = Range(Cells(1, 1), Cells(1, 1).End(xlToRight))

    ‘Preparamos un rango más para borrar

    Dim rngBorrado As Range

    ‘Empezamos las comprobaciones

    Dim comienzo As Integer: comienzo = 0

    Dim seBorra As Boolean: seBorra = False

    ‘Comprobamos en cada columna, si pertenece
a la lista a seleccionar

        For Each CellSale In rngSale

            For Each CellEntra In rngEntra

                If CellSale =
CellEntra
Then ‘hay coincidencia, la columna vive

                    seBorra = False: Exit For

                    Else

                    seBorra = True

                End If

            Next CellEntra

                If seBorra =
True Then

                    ‘seleccionamos la columna y la incorporamos a las que
van a ser borradas

                    comienzo = comienzo + 1

                    If comienzo = 1 Then

                        Set rngBorrado = CellSale.EntireColumn

                        Else

                        Set rngBorrado = Union(rngBorrado, CellSale.EntireColumn)

                    End If

                End If

        Next CellSale

    rngBorrado.Select

    Selection.Delete

End Sub

 

Comments

So empty here ... leave a comment!

Deja un comentario

Sidebar



Si continuas utilizando este sitio, significa que aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar