CMS modules by everest poker.

Tablas

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

 

Si queréis descargaros el artículo en pdf pulsad aquí

 

Índice de contenidotablas


EL CORAZÓN Y CEREBRO DE ACCESS
LOS CAMPOS DE TABLA
Resumen de propiedades y alguna característica interesante
LOS ÍNDICES DE TABLA
RELACIONES ENTRE TABLAS
RECOMENDACIONES FINALES

 

EL CORAZÓN Y CEREBRO DE ACCESS
Las tablas constituyen el corazón y el cerebro de Access. Porque Access es una base de datos, y, ¿dónde encontramos los datos? ¿Dónde se almacenan para su posterior consulta, modificación y presentación de información? Evidentemente, el objeto de Access que responde a las anteriores cuestiones es: las tablas. Es más, no estamos hablando de la introducción de datos en una sola tabla, sino que hablamos, en bases de datos complejas, de la existencia de múltiples tablas en las cuales el acceso al dato que necesitamos desde la tabla “más al norte” nos permite obtener información almacenada en la tabla totalmente opuesta “del sur” gracias al modelo relacional (véase artículo) y las relaciones que hayamos establecido entre aquellas dos y todas sus intermedias.


LOS CAMPOS DE TABLA
Los campos de la tabla nos permiten definir el nombre genérico del dato que queremos introducir, además de permitirnos definir la tipología del dato y configurar algunas de sus características.


Es decir, si queremos guardar el nombre de un cliente podremos crear un campo llamado, por ejemplo, nomCli, indicar que el tipo de dato es “texto” y configurar qué longitud máxima puede tener la información a introducir, qué valor por defecto contendrá ese campo para nuevos registros, que título ponerle (que es el que saldrá por defecto si creamos un formulario sobre esa tabla), si se requiere la introducción obligatoria de ese valor para poder guardar el dato (registro), entre otras muchas.


El conjunto de campos de una tabla que contengan información constituirían lo que se denomina un “registro”.


Resumen de propiedades y alguna característica interesante
De manera muy breve veremos qué tipos de datos pueden adoptar nuestros campos y una somera descripción:


- Autonumérico: es un formato numérico, que va añadiendo una unidad a cada registro.

Hay que tener en cuenta que no toma como referencia el último valor existente, sino el último valor introducido. Ello significa que si introducimos el registro 14 y lo borramos, el siguiente registro no volverá a ser asignado como 14, sino como 15.


Los campos autonuméricos son muy utilizados como identificador inequívoco del registro, y necesarios para establecer una relación de “uno a varios” entre tablas (ver epígrafe relaciones entre tablas).


- Texto: campo de tipo String. Su longitud máxima puede ser de 255 caracteres.
- Memo: campo de tipo String. Su longitud máxima es de 63.999 caracteres.
- Número: campo de tipo numérico. Puede adoptar diferentes subtipos (entero, largo, decimal, etc.), en función la longitud del número que queramos almacenar, y si lo queremos con decimales o no.
- Fecha/Hora: campo de tipo Date. Nos permite varios formatos (fecha corta, larga, general, etc.)


Truco: para coger la fecha actual del sistema basta, en sus propiedades, con poner como valor predeterminado lo siguiente: =Ahora()


- Moneda: campo de tipo Currency: nos permite introducir importes numéricos y ser tratados con formato de moneda.


Truco: si no queremos valores negativos basta, en sus propiedades, con poner como regla de validación lo siguiente: >=0
y como texto de validación, por ejemplo: No se permiten valores negativos


- Sí/No: campo de tipo Boolean. Puede presentar dos valores: Verdadero (a modo de check marcado) o Falso (a modo de check desmarcado).
- Objeto OLE: campo de tipo OLE, que se basa en la tecnología del mismo nombre. Nos permite vincular o incrustar objetos OLE (como un Word o un Excel, por ejemplo).
- Hipervínculo: nos permite almacenar una combinación de texto y números que será tratada como si fuera un link.
- Datos adjuntos: para adjuntar todos los tipos de archivos permitidos.
- Asistente para búsquedas: nos permite seleccionar un valor de otra tabla o consulta.

Su presentación en el formulario basado en esa tabla es de cuadro de lista o cuadro combinado. Por defecto nos devuelve el valor de la clave principal de la tabla cuyo dato hemos seleccionado.


LOS ÍNDICES DE TABLA
Crear un índice de tabla nos permite es crear un sistema de búsqueda y ordenación que optimiza nuestra tabla. En definitiva, la idea que subyace en la creación de un índice es: busquemos un dato buscando el índice que represente ese dato.


Algunas cosas que debemos tener en cuenta a la hora de crear un índice son:


- No todos los tipos de campos admiten la creación de un índice.
- La repetición de los datos: si para ese campo se van a introducir datos con valores idénticos el índice no sólo no funcionará correctamente sino que ralentizará los procesos de búsqueda.
- Reflexionar sobre si realmente necesitamos ese dato como índice.


Existen dos tipos de índices: índices simples e índices múltiples. La creación de ambos es un proceso muy sencillo: seleccionamos el campo que deseamos convertir en índice, nos vamos a sus propiedades y fijamos la propiedad “Indexado” como Sí (con duplicados) o Sí (sin duplicados), en función de si se pueden repetir los valores de ese campo.


Si lo que queremos es definir un índice múltiple tenemos que irnos al botón de la cinta de opciones “Índices” (dentro del menú diseño) y lo que hacemos es: a) poner un nombre identificador del índice; b) seleccionar el campo a indexar y c) establecer un criterio de ordenación.


La clave principal siempre estará indexada. Si no la queremos indexada no podrá ser clave principal.


RELACIONES ENTRE TABLAS
Para una introducción más genérica del modelo relacional podéis revisar este artículo que os comentaba al principio de este texto.


Antes de entrar de lleno en las relaciones debemos antes tener dos conceptos claros: la clave primaria y la clave externa.


La clave primaria permite recopilar la información almacenada de forma distribuida en diferentes tablas. El campo que sea clave primaria es claramente distinguible porque a su izquierda (con la tabla en vista diseño) aparece una pequeña llave. Las tres características principales de una clave primaria son:


- Debe estar asignada a un campo que sea índice
- No pueden existir valores duplicados en ese campo
- El campo no puede contener valores nulos.


La clave primaria puede ser única o múltiple, es decir, puede ser “primary key” un solo campo o podemos seleccionar diferentes campos, siempre y cuando cumplan las condiciones antes citadas.


La clave externa es un elemento “abstracto” que deriva del propio modelo relacional. Ello significa que cuando relacionamos tablas en ningún momento estamos diciendo, específicamente, que tal campo será una clave externa, pero indirectamente sí lo estamos definiendo.


Un ejemplo creo que será el mejor clarificador del concepto y nos ayudará a “pensar en Access”. Este ejemplo nos servirá para el resto de lo explicado en este artículo, y además os podéis bajar la BD aquí.


Supongamos que tengamos una tabla de escritores y una tabla de libros. Los campos de la tabla escritores serán:


[codAutor]: autonumérico y clave principial
[Autor]: nombre del autor


OK. Aquí lo que es la clave principal está claro, ¿verdad?


Ahora debemos preguntarnos: ¿puede un escritor escribir más de un libro? Si la respuesta es que no, que sólo puede escribir un solo libro, lo único que tendríamos que hacer es, a la tabla autores, añadir un campo más llamado
[Libro]: nombre del libro


Pero, en la realidad, esto (para este ejemplo y para la mayoría de casos) un escritor puede escribir de un libro. Vamos a intentar una cosa: la tabla libros la creamos así, con estos campos:
[nomAutor]: nombre autor y clave principal
[Libro]: título del libro


¿Nos va a funcionar bien la tabla? La respuesta, evidentemente, es no, porque al ser autor clave principal debemos recordar que no admite valores duplicados: sólo podríamos escribir un registro.


Es más, si intentáramos relacionar las claves principales de ambas tablas tendríamos un pequeño problema: [Codigo] es un tipo numérico, y [nomAutor] es un tipo texto, y los tipos serían pues incompatibles.


¿Cuál es la solución, pues? Vamos a cambiar los campos de la tabla libro:


[codLibro]: autonumérico y clave principal
[codAutLibro]: numérico, nos identifica el código de autor
[Libro]: nombre del libro


Una vez más, para esta tabla, tenemos claro qué campo es la clave principal. ¿Ok?


Ahora sí podríamos relacionar los campos [codAutor] y [codAutLibro] porque son del mismo tipo. ¿Y cúal sería la clave externa? Pues la clave externa para [codAutor] sería, lógicamente, [codAutLibro].


Volvamos a las relaciones. Existe una tipología de relaciones, que es la siguiente:


- Relación de uno a uno (1:1)
- Relación de uno a varios (1:N)
- Relación de varios a uno (N:1)
- Relación de varios a varios (N:N)


Evidentemente la segunda y la tercera son “los mismos perros con distintos collares”. A partir de aquí utilizaré siempre la nomenclatura “uno a varios” para referirme a ambas.


La relación 1:N es la más habitual, y en ella nos centraremos. De hecho, en el ejemplo anterior hemos definido una relación 1:N (un autor->varios libros)


La relación 1:1 no es muy habitual. Por ejemplo, supongamos que, por motivos de operativa, necesitamos tener separados en dos tablas los campos [DNI] y [numeroSeguridadSocial] para un trabajador, cuyo campo identificativo es [codTrabajador]. Si relacionamos esas dos tablas a través de [codTrabajador] deberemos establecer una relación 1:1, porque un trabajador sólo puede tener (al menos, en teoría), un solo DNI y un solo número de la Seguridad Social.


La relación N:N no está permitida en Access. ¿Qué significa eso? Que el trabajo de crear esa relación recae totalmente sobre nosotros, pues debemos dividir las tablas de tal manera que creemos esa relación N:N a través de un conjunto de relaciones 1:N.


¿Y cómo creamos la relación? Para ello tenemos que irnos, en Access 2007, al menú “Herramientas de la Base de Datos”, y en la cinta de opciones veremos un botón que pone “Relaciones”. Si hacemos click sobre él se nos abre la ventana de relaciones.


Añadimos las tablas pues entre las cuales queremos crear las relaciones y las distribuimos en la ventana relaciones de manera que tengamos un panorama “claro” de las mismas. Clickamos sobre la clave principal de la tabla 1 y la “arrastramos” sobre la clave externa de la tabla 2. Entonces nos aparecerá una ventana que nos permite modificar la relación.


En la parte de abajo nos indica qué tipo de relación es (según el ejemplo, uno a varios). Y después nos pide una serie de cosas. Vamos a verlas:


- Exigir integridad referencial: si forzamos la integridad referencial conseguimos que las modificaciones o eliminaciones que se produzcan entre registros relacionados se actualicen de manera automática (en cascada). Ahora veremos qué es esto.
- Actualizar en cascada los campos relacionados: el propio título lo dice. Un pequeño ejemplo lo clarificará: supongamos que tenemos relacionados los nombres del campo [nomTrabajador]. En la tabla 1 tenemos un trabajador que se llama “José pérez”. En la tabla 2 tenemos varios registros que nos dicen que “José pérez” ha trabajado en domingo. ¿Ok?


Después de 1000 registros (ya que el señor trabaja mucho) nos damos cuenta de que el apellido del trabajador lo dimos de alta en minúscula. Nos vamos a la tabla 1, modificamos el registro y ahora el trabajador se llama “José Pérez”. El registro 1001 nos dirá que “José Pérez” ha trabajado en domingo, pero, ¿y los 1000 primeros registros? Pues quien habrá trabajado será “José pérez”.


Pero si en su día creamos la relación y exigimos integridad referencial, marcando la opción “actualizar en cascada los campos modificados”, de manera automática los primeros 1000 registros se actualizarán, y ahora sí, quien habrá trabajado en todos los registros de la tabla será “José Pérez”.


No sólo eso, sino que cualquier otra tabla que dependa del nombre del trabajador tendrá los registros actualizados.


Mi consejo: si queremos tener una tabla que recoja fidedignamente la información original que en su día se introdujo, sin importarnos si los campos después se modifiquen, no marquéis esta opción.


- Eliminar campos en cascada: entendido el punto anterior, la mecánica para este punto es la misma, pero en lugar de modificar hablamos de eliminar.


Y ahora nos encontramos con un botón que nos dice: “tipo de combinación”, y nos da 3 alternativas.


1.- Campos que en ambas tablas sean iguales
2.- Todos los campos de la tabla de la izquierda y sólo aquellos que sean iguales en la tabla de la derecha.
3.- Todos los campos de la tabla de la derecha y sólo aquellos que sean iguales en la tabla de la izquierda.


¡Ojo! Tened en cuenta que para tablas y consultas el tipo de combinación predeterminado es el 1.


¿Y qué significa esto? Significa un problema para mucha gente que no conoce estos tipos de combinación.


Como siempre, qué mejor que un ejemplo real de un problema que mucha gente ha tenido que “sufrir” en sus carnes.


Imaginemos que tenemos nuestra tienda, y queremos llevar un control de inventario de productos. Tenemos una tabla que nos recoge las compras y otra que nos recoge las ventas (además de la tabla que nos recoge los productos en sí). Nuestra BD, ya casi acabada, nos funciona estupendamente. Creamos una consulta para poder sacar [prodComprado], [prodVendido] y de ahí calcular la diferencia para obtener el [prodStock]. Ejecutamos la consulta y… ¡sorpresa! ¡Algo va mal!


Yo he comprado:
- Tomates
- Zanahorias
- Pepinos


Y he vendido:
- Tomates
- Pepinos


Pero aún no he vendido ninguna zanahoria. Y en la consulta no aparece ninguna zanahoria por ninguna parte (pero sé que tengo zanahorias, porque las he comprado y, sobretodo, las he pagado). ¿Qué pasa?


Lo que pasa es que la combinación es de tipo 1, por lo que el resultado de la consulta muestra sólo los campos que son iguales (que existen) en ambas tablas. Zanahoria no está en la tabla de ventas, luego no se muestra.


Si hubiéramos definido la relación de tipo 2, donde se muestren TODOS los campos de la tabla de compras, la consulta sí nos daría un resultado correcto, en el sentido que podríamos ver las compras de todos los productos y las ventas de los mismos, y si no hay venta el dato nos saldría en blanco.


Es decir, que hay que andarse con mucho ojo con el tema del tipo de combinación según los datos que manejemos.


Finalizado el proceso de configuración de la relación podremos ver ahora que las tablas están unidas por una línea, que además nos indica que es una relación 1:N porque nos aparece un “1” en la tabla que tiene el registro único y el símbolo infinito en la otra.


Si, una vez establecidas las relaciones, queremos modificarlas o eliminarlas, sólo tenemos que sacar la ventana de relaciones y, con precisión “quirúrgica”, situar el puntero del ratón sobre esa línea y click con el botón derecho del mouse. El menú emergente nos muestra esas dos opciones.


Para acabar cerramos la ventana de relaciones, guardamos los cambios y… “the end”.


RECOMENDACIONES FINALES
Un par de recomendaciones a tener en cuenta cuando trabajéis con tablas. Se debe entender que son recomendaciones “genéricas”, y que quizá no sean las óptimas en función del tipo de base de datos que se vaya a realizar.


Aquí las tenéis:


- Evitad en lo posible duplicar datos en diferentes tablas (aunque a veces sea necesario). Si ya lo tenemos en una, ¿para qué tenerlo en más? Pensad que el modelo relacional precisamente nos permite “llegar” a ese dato a través de las relaciones entre tablas.
- Cread tantas tablas auxiliares como necesitéis para datos que siempre sean los mismos. Un ejemplo de esto serían los campos que contienen información sobre poblaciones, países, meses, puestos de trabajo, profesiones, etc. Si se pueden escribir una sola vez, ¿para qué tener que escribirlas manualmente en cada registro que demos de alta?
- Guardad las tablas con un nombre descriptivo lo más corto posible, con un identificador de objeto y sin espacios entre palabras. ¿Por qué? Porque cuando tengáis una tabla que se llame, por ejemplo, “Pedidos realizados a proveedores mayoristas”, deberéis tener en cuenta que:
- Si tenéis un formulario y un informe con el mismo nombre según en qué ocasiones no sabréis qué tipo de objeto es el que tenéis delante.
- Si tenéis que escribir código resulta sumamente cansado tener que escribir algo tan largo
- A lo anterior se debe sumar que, si hay espacios entre palabras, en consultas SQL y código VB, en general, la llamada a la tabla se debe poner entre corchetes, con lo que el nombre se hace más largo.
- Y si esa tabla se convierte en subformulario, pues creo que ya podemos hablar de un “nombre eterno”.
Respecto a los nombres yo suelo anteponer una “T” al nombre (“F” para formularios, “C” para consultas y “R” para informes), aunque hay otra gente que antepone las abreviaturas comúnmente aceptadas, que para el caso de tablas es “tbl”. Así, yo tendría:
TAutores / FAutores / CAutores / RAutores /subFrmAutores
Así, con sólo mirar el nombre, ya sé si se trata de una tabla, consulta, etc.


Un saludo, y...


¡suerte!

 

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

©