CMS modules by everest poker.

Consultas (II)

Imprimir
Valoración del Usuario:  / 7
MaloBueno 
Categoría: Teórico-práctico
Escrito por Neckkito

 

Si queréis bajaros este artículo en pdf pulsad aquí.

 

Índice de contenidoConsultas2


CONSULTAS DE ACCIÓN
CONSULTAS DE CREACIÓN DE TABLAS
CONSULTAS DE ACTUALIZACIÓN
CONSULTA DE ELIMINACIÓN
CONSULTAS DE DATOS ANEXADOS
CONSULTAS SQL
CONSULTAS DE UNIÓN
CONSULTAS DE PASO A TRAVÉS
CONSULTAS SQL: CONSULTAS DE DEFINICIÓN DE DATOS
OTRO “GRAN” EJEMPLO

 

CONSULTAS DE ACCIÓN
Veíamos en el artículo anterior una tipología de consultas que, como característica común, recogían la información, la manipulaban según nuestras necesidades y la mostraban, pero en ningún caso modificaban los valores contenidos en nuestras tablas.


Las consultas de acción, por el contrario, sí añaden, modifican o eliminan los datos contenidos en los registros de las tablas. Es por ello por lo que hay que ir con mucho cuidado a la hora de ejecutarlas. Tened en cuenta que una vez ejecutada una consulta de eliminación, por ejemplo, ya no se pueden recuperar los datos (una buena copia de seguridad sería la única solución).


En este artículo echaremos un vistazo a las diferentes consultas de acción que podemos crear en Access y comentaremos alguna de sus características principales.


Adelantar ya que todas las anteriores consultas nacen de una consulta de selección (a la que le podremos aplicar los filtros, parámetros y demás que queramos). Una vez hecha esta consulta de selección es cuando la transformamos en una consulta de acción a través de los correspondientes botones del menú.


Os recomiendo pues que, antes de convertirla en una consulta de acción, ejecutéis la consulta de selección para ver si los resultados son los esperados. ¡No vaya a ser que por un pequeño error en su definición “destrocéis” vuestra BD!


Un último comentario: cuando surjan conceptos que se hayan visto en el artículo anterior no me pararé a explicarlos de nuevo. Si alguien se “pierde” puede recurrir tranquilamente a repasar dichos conceptos en susodicho artículo.


CONSULTAS DE CREACIÓN DE TABLAS
Mediante las consultas de creación de tablas lógicamente lo que hacemos es crear una nueva tabla con los datos que devuelva la consulta.


La mecánica es muy simple. Imaginemos que tenemos una tabla que nos recoge las facturas de varios años. Queremos recoger y almacenar en una tabla separada las facturas correspondientes al año 2010. Creamos una consulta de selección que nos recoja esa información filtrada y la convertimos en una consulta de creación de tabla.

Desde el momento en que la definimos como tal nos aparecerá un cuadro de diálogo solicitándonos el nombre de la nueva tabla, en nuestro caso, por ejemplo, TFras2010.

Una vez ejecutada podremos ver que en Tablas nos aparece una nueva tabla con el nombre que habíamos indicado en la consulta y con los datos que esta devolvía.


Truco: supongamos que tenemos un campo [FechaFra]. Para poder filtrar por el año lo único que tenemos que hacer es crear un campo calculado de la siguiente manera:
AñoFra: Año([FechaFra])


y en la línea de criterios aplicamos el filtro: =2010


Lo único que debemos tener en cuenta es que los campos de la nueva tabla no heredan las características de los campos origen de la tabla (o tablas) de la consulta. Si queremos perfilar bien los campos de la nueva tabla deberemos editarla en vista diseño y manipular los campos para que queden con     las características que nosotros deseemos.


CONSULTAS DE ACTUALIZACIÓN
A través de las consultas de actualización lo que podemos hacer es modificar los datos que hay en una tabla actualizando el campo o los campos a actualizar por el nuevo valor.


Por ejemplo, imaginemos que tenemos una tabla que nos recoge en un campo una abreviatura propia de la empresa (DGA). A nivel interno nos funciona perfectamente porque todos sabemos qué significa DGA, pero ahora debemos emitir un informe para el exterior. ¿Hay que cambiar a mano todos los registros que contengan DGA por “Departamento de gestión de averías”? No hace falta. Basta que creemos una consulta de selección sobre la tabla en cuestión, filtrar por DGA el campo correspondiente y convertir la consulta en una consulta de actualización, indicándole que el nuevo valor será “Departamento de gestión de averías”. Ejecutamos la consulta y veremos que se han cambiado los valores.


Aprovecho para recordaros que, si el campo [Departamento] proviniera de una tabla auxiliar donde tenemos de alta todos los departamentos, conseguiríamos el mismo efecto al definir las relaciones entre tablas y exigirle, a la relación, integridad referencial y actualizar campos en cascada. Si queréis refrescar esto os remito al artículo que habla de ello.


En nuestro ejemplo quizá no interese hacer eso (queremos que quede DGA en nuestra BD). Luego el proceso más lógico sería, primero, realizar una consulta de creación de tabla y, posteriormente, ejecutar una consulta de actualización.


CONSULTA DE ELIMINACIÓN
Como su propio nombre indica, la consulta de eliminación nos “borra” los registros que queramos de la tabla sobre la que estemos aplicando la consulta. Si cogemos el ejemplo mencionado en el epígrafe referente a las consultas de creación de tabla, si una vez seleccionadas todas las facturas del 2010 convertimos la consulta en una consulta de eliminación nuestras facturas del 2010 desaparecerán de la BD.


Truco: muchas veces, al ir rellenando los registros de nuestra BD por parte de un usuario, o bien porque el usuario cree que ha  “deshecho” los cambios, bien porque ha habido un despiste y se pasa al registro siguiente sin haber completado el anterior o bien por cualquier otro motivo quedan registros “medio rellenados” en nuestras tablas.


Para arreglar esto podemos fijarnos nosotros mismos en calidad de administradores de la BD, como criterio propio, que si uno, dos, tres o los campos que creamos convenientes (campos clave), si no tienen datos, son indicativo de que el registro está incompleto y no es útil. Luego, periódicamente, podemos realizar una consulta de selección filtrando por valores vacíos y ejecutar una consulta de eliminación. Así “depuraremos” los datos de nuestras tablas.


Para que quede aún más claro, supongamos que yo, como administrador, establezco que si los campos [NFra] y [FechaFra] están vacíos es que el registro se creó “mal”. Haría una consulta de selección con esos dos campos (incluso podría añadir alguno más para mi propio control), en criterios establecería el siguiente filtro (para esos campos clave):


Es Nulo


Y ejecutaría la consulta de selección. Comprobado que la información que me devuelve la consulta es la que yo quiero (la lista de registros que están “mal”) convertiría la consulta en consulta de eliminación y… ¡tabla depurada!


Os recuerdo que, en según qué casos, debemos tener presente que podemos realizar una eliminación de datos relacionados a través de la definición de relaciones entre tablas (exigir integridad referencial -> eliminación de datos en cascada). Para refrescar esto os remito al artículo que habla de ello.


CONSULTAS DE DATOS ANEXADOS
La acción que realizan este tipo de consultas es adjuntar a una tabla existente los datos que devuelve la consulta.


Los requisitos que se requieren son, pues, que exista una tabla “destino” donde anexar los datos y que los datos que se vayan a anexar sean “compatibles”.


Por ejemplo, si nosotros tenemos una tabla donde uno de los campos es [FInicio] y otro campo es [FFin], y quisiéramos tener un solo campo que fuera [Fecha], el proceso podría ser el siguiente:


- Creamos una consulta de creación de tabla que nos recogiera los datos sólo con los campos necesarios y sólo con el campo [FInicio], excluyendo el campo [FFin]. Por ejemplo, crearíamos la tabla TFechasTotales
- Una vez creada nuestra nueva tabla, repetiríamos el proceso creando otra consulta que recogiera sólo [FFin], la convertiríamos en una consulta de datos anexados y la anexaríamos a la tabla TFechasTotales, y en las correspondencias indicaríamos que [FFin] debe anexarse al campo [FInicio]. Así tendríamos una tabla donde las fechas estarían en una sola “columna”.


Aunque este ejemplo parece un poco “abstracto”, os remito al epígrafe “Otro “gran” ejemplo” para que podáis ver una utilidad práctica de este proceso.


CONSULTAS SQL
La principal característica de las consultas SQL es que no permiten una vista diseño como las consultas de selección o de acción. Ello implica que debemos escribir en lenguaje SQL para poder realizar la consulta.


A modo de introducción una consulta SQL básica (lo que sería una simple consulta de selección) vendría a decir esto:


SELECCIONA [de la tabla X].[el campo 1], [de la tabla X].[el campo 2] TODO LO ANTERIOR DE [la tabla X]


Y eso, escrito en SQL, se escribiría así:


SELECT [TablaX].[Campo1], [TablaX].[Campo2] FROM [TablaX]


Si queremos ver cualquier consulta de las que hemos tratado en este artículo o del artículo anterior basta que, poniendo la consulta en vista diseño, clickemos sobre el botón “SQL”; ahí veremos la construcción de la consulta en lenguaje SQL.


Truco: si queremos seleccionar todos los campos de la tabla escribiremos un asterisco tras el select, de manera que la expresión quede así:


SELECT * FROM [TablaX]


Como ya indicaba al inicio de este epígrafe, hay una tipología de consultas que sólo podemos realizarlas con SQL. Son las que veremos a continuación:


CONSULTAS DE UNIÓN
Las consultas de unión nos permiten “unir” dos tablas con datos muy similares en una sola “tabla”.


Imaginemos que tenemos una tabla con proveedores (TProveedores) que tiene los campos [NomProveedor] y [DirProveedor] (nombre y dirección), y otra tabla (TClientes) que tiene los campos [NomCliente] y [DirCliente] (igualmente nombre y dirección). Y, por los motivos que sean, queremos juntar los datos de ambos (¿para enviar una felicitación navideña a todos?). Eso lo podríamos conseguir a través de una consulta de unión.


La programación de esa consulta sería la siguiente:


SELECT [TProveedores].[NomProveedor], [TProveedores].[DirProveedor] FROM [TProveedores]
UNION SELECT [TClientes].[NomCliente], [TClientes].[DirCliente] FROM [TClientes];


Como podemos ver, en realidad lo que estamos haciendo es dos consultas de selección simples pero “unidas” por la palabra reservada UNION.


Un par de comentarios sobre este tema:


- Hemos hablado de unir dos tablas, pero se pueden unir todas las tablas que queramos.
- En el ejemplo hemos utilizado la estructura [Tabla].[Campo]. Esta estructura se puede simplificar, de manera que no haría falta indicar la tabla en la línea del SELECT (es decir, sería SELECT [NomProveedor] FROM [TProveedores]. Sin embargo, mi recomendación personal es que utilicemos la estructura tabla.campo, sobretodo en consultas complicadas, porque facilita la interpretación del código.
- Cuando utilizamos el lenguaje SQL en las consultas siempre debemos acabar la instrucción utilizando el punto y coma. Si utilizamos SQL en VBA no debemos poner ese punto y coma.


CONSULTAS DE PASO A TRAVÉS
Las consultas de paso a través envían comandos directamente a bases de datos conectadas por ODBC (Open DataBase Connectivity), utilizando la sintaxis requerida para ese servidor.


Los motores de bases de datos (hasta donde yo sé) más utilizados son el propio Microsoft Access, MS SQL Server, Oracle, Microsoft dBase, FoxPro o Paradox.


Dada la especificidad de este tipo de consultas veremos muy rápidamente cómo funcionan, simplemente para tener la idea de que existen y lo que hacen.


Imaginemos que tenemos una base de datos llamada BDGlobal, que está en un servidor con SQL Server y conectada a través de ODBC. Si queremos realizar consultas sobre esta BDGlobal necesitaremos una consulta de paso a través.


Deberíamos, para ello, crear una consulta en vista diseño, sin añadir ninguna tabla o consulta. Haríamos click sobre el botón “Paso a través”, lo cual nos dejaría la vista de la consulta en vista SQL.


En las propiedades de esa consulta tenemos una propiedad que se denomina “Cadena de conexión ODBC”. Si nos situamos sobre ella, en el espacio en blanco que hay a su derecha, nos aparecerá un pequeño botón con puntos suspensivos.


Si hacemos click sobre él se nos abre una ventana donde podremos seleccionar el origen de datos.


Una vez hecho esto podremos escribir las sentencias que constituyan la consulta, respetando la sintaxis propia del sistema al que nos conectamos.


Como ya comentaba, este tipo de consultas son tan específicas y apenas utilizadas (si se conocen) por un usuario “normal” de una BD, por lo que lo dejaremos aquí, sin entrar en más detalles.


CONSULTAS SQL: CONSULTAS DE DEFINICIÓN DE DATOS
Las consultas de definición de datos son utilizadas para manejar y manipular objetos de nuestra BD.


Según mi experiencia no se emplean demasiado porque existen otras opciones a través de VBA para realizar las mismas acciones (y más). De todas maneras es interesante saber que existen porque podrían servirnos si no “controlamos” demasiado VBA.


Utilizaré un ejemplo que en ocasiones se ha demostrado útil: haremos una consulta que nos cree una tabla.


Queremos crear la tabla THistorico con los campos [Evento] y [Fecha]. Para ello creamos una consulta en vista diseño, sin incluir ninguna tabla o consulta, y hacemos click sobre el botón que nos la convierte en una consulta de definición de datos. Se nos abrirá la consulta en vista SQL.


La sintaxis más simple de esta consulta es, en abstracto, como sigue:


CREATE TABLE NombreTabla ([Campo] TipoDato, [Campo2] TipoDato, …)


En nuestro ejemplo deberíamos escribir:


CREATE TABLE THistorico ([Evento] String, [Fecha] Date)


Si queréis saber algo más sobre este tipo de consultas podéis consultar la siguiente dirección: http://office.microsoft.com/es-hn/access-help/crear-o-modificar-tablas-o-indices-mediante-una-consulta-de-definicion-de-datos-HA010206112.aspx


OTRO “GRAN” EJEMPLO
Para facilitar tanto la lectura como la ejecución, si queréis ir vosotros desarrollando el ejemplo, os remito aquí, donde os podréis bajar un pdf y un BD con el ejemplo desarrollado.


¡Que lo disfrutéis!
 
--- FIN DE LA PARTE SEGUNDA ---

 

Sunday the 22nd. Joomla 2.5 Templates. Neckkito's baby 2012 --- Hosted by: www.siliconproject.com.ar
Copyright 2012

©