martes, 26 de agosto de 2014

Nueva etapa, nuevo sitio

A partir de septiembre dejaré de publicar nuevos contenidos en este blog, ya que estreno web oficial en la que agruparé todos los contenidos con mi perfil profesional y colaboraciones.

Pero no creas que me olvido de ti, así que como me encantaría que siguiéramos en contacto, te animo a visitar www.luciamonterorodriguez.com y suscribirte en el enlace que verás a la derecha.¡Hasta pronto!

www.luciamonterorodriguez.com
www.luciamonterorodriguez.com

domingo, 18 de mayo de 2014

Cómo diferenciar el tipo de relación entre dos tablas

Desde mi experiencia como docente, creo que lo más complicado no es manejar una base de datos, sino hacer un buen análisis.

Partiendo de esta premisa, en las evaluaciones siempre pido el análisis en papel junto con la propia base de datos, y es curioso ver cómo hay personas que son capaces de solventar un mal análisis, aunque el resultad final no sea eficiente.

Tipos de relaciones

Comencemos por repasar las diferentes modalidades, suponiendo que tenemos dos tablas con información relacionada entre sí.

1 a 1: 
     Cuando un registro de la tabla A sólo se puede relacionar con un registro de la tabla B
1 a varios: 
     Cuando un registro de la tabla A se puede relacionar con varios registros de la tabla B
Varios a varios: 
     Cuando varios registros de la tabla A se pueden relacionar con varios registros de la tabla B

Base de datos: Tipos de relaciones entre dos tablas

Preguntas que debo hacerme

Estas dos sencillas preguntas te ayudarán definir correctamente la relación entre dos tablas:

Tiene una clave principal?
     Si es así, estaremos ante un extremo 1, lo que descarta automáticamente la tercera modalidad.

Cuántas veces puede aparecer cada elemento de A en la tabla B?
     Este supuesto es mejor analizarlo con un ejemplo concreto. Mira las tablas de la siguiente figura:

Tablas sin relacionar en una base de datos


Por un lado tenemos tablas auxiliares:
Clientes: lista con los datos de todos los clientes de una agencia de viajes.
Transporte: lista con los diferentes medios para cada viaje del catálogo
Tipos de viajes: catálogo de los productos que la agencia oferta, y que se alimenta de la tabla anterior.

Además, la tabla principal es:
Viajes:  lista de los viajes realmente contratados, por lo que deberá relacionarse con Clientes y con Tipos de viajes.

Suponiendo que la tabla A es Clientes y la tabla B es Viajes, piensa ahora en la relación entre  codigocliente y codigocli.

1ª  pregunta: En la tabla Clientes, ¿cuántas veces aparecerá cada cliente?
Respuesta: Como es la lista de todos los clientes, cada persona deberá aparecer sólo una vez. Además, si te fijas en la imagen, el campo codigocliente está marcado como clave principal, lo que garantiza que sea un extremo 1 dentro de la relación.

2ª  pregunta: En la tabla Viajes, ¿es posible que un mismo cliente contrate más de un viaje?
Respuesta: Si la respuesta es SI, como en este caso, la tabla B tiene el extremo varios de la relación.

Por lo tanto, definiremos la relación como del tipo Uno a varios.

Comprobación en Access

Para ver si Access coincide con nosotros, arrastra el campo codigocliente hasta situarlo encima de codigocli o viceversa. Al soltar el ratón, la aplicación muestra el cuadro de diálogo Modificar relaciones:

Cuadro Modificar Relaciones indicando el Tipo de relación en la parte inferior

Si te fijas en la parte inferior de la imagen, Access ya está indicando el Tipo de relación: Uno a varios. Si además activamos la opción Exigir integridad referencial y pulsamos el botón Crear, verás como Access dibuja dicha relación en el esquema.

Relación 1 a varios entre dos tablas de una base de datos

Conclusión

Has podido comprobar cómo, realizando las preguntas adecuadas, podemos detectar fácilmente el tipo de relación que se establece entre dos tablas diferentes.

En el siguiente artículo, abordaremos el tratamiento de las relaciones Varios a Varios, hasta entonces, no dejes de practicas y probar, y si surgen dudas, ya sabes que me tienes a tiro de comentario :)

martes, 11 de marzo de 2014

En pocas palabras: un buen manual de Access

Hace poco tiempo la editorial IdeasPropias contactó conmigo para que revisara el libro Microsoft Access: Diseño de aplicaciones sencillas de bases de datos y, si tenía a  bien, hacer una reseña en mi blog; así que como me gusta hacer colaboraciones de todo tipo, dije que sí sin pensármelo dos veces.
Microsoft Access: Diseño de aplicaciones sencillas de bases de datos

Reconozco que al recibir el paquete y empezar a ojear el libro me quedé un poco “a cuadros”, ya que me estaban proponiendo la revisión de un libro dedicado a Access 2007. Lo primero que pensé es que tenía que ser un error, teniendo en cuenta que 2013 está en la calle, pero que casi toda la formación que me demandan ahora mismo es para Access 2010.

No obstante, decidí revisar el contenido y debo decir que me alegro de haberlo hecho. Se trata de un manual bien elaborado que, a pesar de introducir teoría de diseño de base de datos que podría despistar a cierta tipo de público, se integra bien con explicaciones prácticas, sin dar nada por supuesto.

Además, en cada capítulo se incluyen actividades que ayudarán a comprender el funcionamiento de Access y al final de cada uno, podrás encontrar conclusiones y test de autoevaluación. Aparte, el libro físico viene con un CD que incluye diversos videos tutoriales.

Sin embargo, si pienso en las necesidades que me encuentro durante los cursos que imparto para empresas, tengo que reconocer que el capítulo dedicado a las Consultas podría estar más completo, ya que mi experiencia me ha demostrado que es el objeto más potente y el que todo usuario de Access debería dominar.

A pesar de lo anterior, tengo que concluir diciendo que es un manual, apto, útil y recomendable para personas que quieran empezar desde cero o para aquéllos usuarios que se limitan a introducir y modificar datos y desean avanzar en el manejo de la aplicación.

martes, 25 de febrero de 2014

Consultas en campos que contienen asteriscos

En el primer artículo dedicado al Diseño de Consultas con criterios, indicábamos que el carácter comodín nos podía servir de ayuda en los campos de tipo texto.

Por ejemplo, fíjate en la siguiente imagen. Vemos una tabla denominada Artículos con dos campos, Código y Denominación:

Tabla de muestra con asteriscos dentro de un campo

Pues bien, vamos a imaginar que queremos consultar todos los artículos cuyo nombre contenga la letra A. El diseño de la consulta sería el que aparece a continuación:

Ejemplo de consulta con carácter comodín

El primer asterisco indica que puede haber o no un número indeterminado de caracteres delante de la a, y el segundo, lo mismo, pero detrás de dicha letra. Y el resultado será:

Resultado de una consulta

Pero…. ¿qué ocurriría si lo que necesito, es mostrar los registros en cuyo código existan asteriscos? En tal caso hay que combinar el uso del asterisco comodín con el asterisco carácter indicando como criterio: *[*]*

La manera de obligar a Access a que encuentre el carácter comodín, independientemente del resto de caracteres escritos en el campo es situar el asterisco entre corchetes. El resultado será:

Resultado de una consulta que busca los registros que contengan asteriscos

 ¿A qué no era tan complicado?

lunes, 13 de enero de 2014

Consultas con relaciones múltiples entre dos tablas

En el artículo anterior vimos cómo crear varias relaciones entre dos tablas, tarea que Access realiza mediante clones, y ahora veremos cómo podemos manejarlas.

El punto de partida

Se supone que, si Access te propone de manera automática crear un clon a partir de la segunda relación entre dos tablas, debería saber gestionarlas luego correctamente, pero por desgracia no es así.

Recuerda el esquema que tratamos anteriormente: usamos las tablas Líneas y Paradas para reflejar la primera y última parada correspondiente a una línea de autobuses.

Relaciones con clon

Pues bien, ahora queremos elaborar una consulta que nos diga, precisamente, el número de línea, el nombre de la parada inicial y el nombre de la parada final.

La consulta

Al crear una consulta desde la vista Diseño y añadir las tablas que necesitamos, ACCESS MUESTRA LA RELACIÓN DOBLE SIN CLONES.

Y si, como pudiera parecer lógico, añadimos a la cuadrícula el campo numerolin y dos veces nombre, ACCESS NO ES CAPAZ DE RESOLVER LA SITUACIÓN.

Relación doble entre dos tablas

En consecuencia, al ejecutar la consulta, Access no muestra ningún resultado, a pesar de haber datos relacionados en ambas tablas, ya que no sabe distinguir cada relación de manera individual.

La solución

¿Qué podemos hacer entonces? La solución es fácil de obtener aunque un pelín laboriosa. Todo pasa por eliminar relaciones, añadir y clones y volver a anexionar, y es que todas las modificaciones que se hacen en la vista Diseño se consideran temporales. Entonces será necesario seguir estos pasos:
  1. Eliminar la relación entre codparada y paradafin
  2. Añadir otra vez la tabla Paradas, de manera que Access genere un clon de la misma
  3. Crear la relación entre codparada de Paradas_1 y paradafin
  4. En la cuadrícula inferior, sustituir nombre de Paradas por nombre de Paradas_1


Relaciones temporales en diseño de consultas

Si has seguido correctamente los pasos, y el esquema es similar al de la figura, al ejecutar la consulta Access SÍ mostrará la solución correcta. Ten en cuenta que en la imagen siguiente para que el resultado quede mejor, hemos cambiado los títulos de las columnas, aportando de paso más información para el usuario.

Resultado de consulta con múltiples relaciones

Otra alternativa

Acabamos de ver la solución formal, pero si relacionaste los campos mediante Búsqueda, no será necesario (al menos en este supuesto) seguir todos estos pasos; con sólo mostrar la tabla Líneas, tendremos la solución a nuestro alcance ;)

Tabla con búsquedas bien enlazadas en Acccess