Procedimiento para gestionar la BB.DD. del Laboratorio A continuacin detallamos un procedimiento para gestionar la BB.DD. del Laboratorio.

Damos los pasos para su aprendizaje y manejo adecuado, y comentamos sus problemas y detalles ms importantes. Aprendizaje y manejo de BB.DD. en PL/SQL

Lo primero a tener claro son los campos existentes en las diferentes tablas y las relaciones existentes entre dichas tablas que conforman la BB.DD. Para ello tenemos unos esquemas que lo detallan denominados entidades de relacin. Un esquema tpico de entidades de relacin en BB.DD. es el siguiente:

Albaran_Entrada -idAlbaranEntrada : Integer -fechaRecepcion : Date -idDistribuidor_fk : Integer -idPedido_fk : Integer -idPersonal_fk : Integer

Articulo -idArticulo : Integer -serialNumber : String -fechaProximaCalibracion : Date -fechaAlta : Date -ubicacion : String -precioUnitario : Double -observaciones : String -unidades : Integer -idEstado_fk : Integer -idAlmacen_fk : Integer -idCodigoProyecto_fk : Integer(= idOferta from Gestion) -idDistribuidor_fk : Integer -idModelo_fk : Integer -unidadesReservadas : Integer -fechaInicialProximaCalibracion : Date -esPropio : Byte -numeroDEProyecto : String -datosIniciales : String -idCliente_fk : Integer -idSubalmacen_fk : Integer

Articulo_Albaran -idArticuloAlbaran : Integer -unidades : Integer -idArticuloPedido_fk : Integer -idArticulo_fk : Integer -idAlbaranEntrada_fk : Integer

Personal (from Gestin de Usuarios) -id_personal : Integer -nombre : String -tlf : Integer -movil : Integer -mail : String -department : String -inactive : String -login : String -password : String

Modelo (from Material) -idModelo : Integer -nombre : String -descripcion : String -partNumber : String -granel : Integer -referenciaAlternativa : String -necesitaCalibracion : Integer -idPeriodicidadCalibracion_fk : Integer -datosCalibracion : String -procedimientoCalibracion : String -observaciones : String -stockMinimo : Integer -idTipo_fk : Integer -idEmpresaCalibracion_fk : Integer -idFamilia_fk : Integer -idPreavisoCalibracion_fk : Integer

Pedido -idPedido : Integer -referenciaPedido : String -fechaPedido : Date -fechaRecepcionPrevista : Date -lugarEntrega : String -observaciones : String -idDistribuidor_fk : Integer -idPersonal_fk : Integer Articulo_Pedido -idArticuloPedido : Integer -unidades : Integer -precioUnitario : Double -idModelo_fk : Integer -idPedido_fk : Integer

Posteriormente hay que tener una cierta soltura para realizar consultas en BB.DD. del tipo PL/SQL. Existen numerosos tutoriales en Internet, uno muy didctico es el siguiente: http://sql.1keydata.com/es/ Como ya hemos comentado hay que tener cierta soltura para realizar consultas, para lo cual sera bueno mirar los comandos de la primera pestaa Comandos SQL (esto se puede mirar en un da). Las dems pestaas son para la creacin de tablas y dems tareas ms avanzadas que no nos son necesarias por el momento. Teniendo estas dos cosas claras podemos realizar un buen manejo de BB.DD. en PL/SQL y realizar infinidad de consultas en ellas relacionando diferentes tablas y campos entre s. BB.DD. del Laboratorio

La BB.DD. del Laboratorio tiene un esquema de entidad de relaciones extenso (pedir a alguien el completo). Las tablas principales de la BB.DD. del Laboratorio son Artculo y Modelo pero existen otras que se relacionan con estas mediante ciertos campos con una clave externa (fk = foreign key). Estos campos son los que nos permiten relacionar las tablas entre s (forzamos una cierta condicin en una sentencia SQL). El problema de esto es que conforme ms condiciones imponemos la tabla se nos puede restringir ms, llegando incluso a despreciar elementos de inters. A continuacin explicamos esto con ms detalle: Si por ejemplo realizamos un Query data de la tabla Artculo_Old,
select * from articulo_old a;

y listamos todos los elementos,

select count(*) from articulo_old a;

obtenemos 5022 elementos existentes en la tabla. Si ahora relacionamos las tablas Artculo_Old y Modelo_Old mediante la siguiente sentencia SQL,
select * from articulo_old a, modelo_old m where a.idmodelo_fk = m.idmodelo;

y listamos de nuevo todos los elementos,

select count(*) from articulo_old a, modelo_old m where a.idmodelo_fk = m.idmodelo;

obtenemos 4954 elementos. Esto sucede porque el campo que relaciona ambas tablas no cumple la condicin impuesta, en particular en este caso existirn elementos de la tabla Artculo_Old que no tengan relacin con ninguno de la tabla Modelo_Old por lo que no podremos saber el elemento que es (nombre y descripcin) ya que esa informacin se encuentra en la tabla Modelo_Old. Haciendo lo mismo con las BB.DD. nueva tenemos:
select count(*) from articulo a;

5487

y,
select count(*) from articulo a, modelo m where a.idmodelo_fk = m.idmodelo;

5487

Esto es lgico ya que no deberamos perder elementos al relacionar diferentes tablas entre s. No obstante esto puede suceder y de hecho sucede cuando aumentamos el

nmero de tablas que se relacionan entre s o incluso cuando relacionamos las tablas antiguas Artculo_Old y Modelo_Old como ya hemos visto. Esto sucede en las tablas antiguas porque el campo que nos da la relacin entre dichas tablas estar vaco y ahora con la nueva copia (bug) de la BB.DD. del Laboratorio tenemos solucionado dicho problema. Gracias a la nueva versin ya no perdemos elementos al relacionar Artculo y Modelo pero si seguimos aumentando las relaciones entre las tablas existentes del Laboratorio esto sigue sucediendo ya que al imponer nuevas condiciones lo que hacemos es restringir ms los elementos que las cumplen. Yndonos al caso ms extremo de relacionar todas las tablas que tienen campos con una clave externa (fk) en la tabla Artculo tenemos la siguiente sentencia:
select * from articulo a, modelo m, estado e, almacen al, distribuidor d where a.idmodelo_fk = m.idmodelo and a.idestado_fk = e.idestado and a.idalmacen_fk = al.idalmacen and a.iddistribuidor_fk = d.iddistribuidor;

y si contamos los elementos listados (count) obtenemos, 1105 Esta cantidad frente a la tenamos antes de 4954 es muy considerable. No obstante lo que os queremos hacer ver con esto, es que este resultado no es de extraar ya que hemos impuesto 5 condiciones frentes a 1 que haba antes, por lo que limitamos mucho ms los elementos que las cumplan todas. Ahora bien, os podris preguntar, para que relacionar las tablas si lo que hacemos es perder elementos? Esa pregunta tiene trampa, ya que esta claro que la idea de relacionar las tablas es porque existen campos que las relacionan mediante claves externas (fk). Pero lo que ocurre en general es que el contenido de esos campos de por s solo no da informacin alguna (suele ser numrico), es necesario relacionarlos con los campos de otras tablas para que nos proporcionen informacin. Y precisamente al establecer dicha relacin perdemos elementos pero ojo, perdemos los que no tienen relacin alguna! Por tanto, parece ser que el mejor procedimiento para tener toda la informacin y no perder elementos sera relacionar las tablas Artculo y Modelo y si nos interesa saber que informacin da un cierto valor de esos campos tendremos que irnos a su tabla correspondiente y hacer un Query data viendo la correspondencia numrica. O bien, si lo tenemos claro, relacionarlos mediante una cierta condicin pero sabiendo que la perdida de elementos al hacerlo es algo que nos puede suceder. Comparador de archivos: WinMerge

Por ltimo, explicamos el funcionamiento de un programa que sirve para comparar archivos. Este nos va a ser til para ver los cambios existentes entre las BB.DD. del Laboratorio antigua y nueva. Con lo de antigua y nueva nos referimos a las tablas Artculo_Old y Modelo_Old frente a Artculo y Modelo, ya que realmente se puede decir que estas tablas son las de inters en la BB.DD. del Laboratorio y las que nos pueden proporcionar toda la informacin ya que las dems se mantendrn fijas y lo que cambia es el contenido de los campos de estas.

WinMerge es un comparador de archivos, bsicamente su funcionamiento es comparar 2 archivos y buscar sus diferencias. WinMerge acepta una variedad elevada de formatos pero se ha observado que el ms cmodo para lo que queremos hacer es XML. Por tanto la idea de esto sera la siguiente, mediante PL/SQL relacionamos los campos de inters de la BB.DD. del Laboratorio nueva y antigua (tablas Artculo y Modelo frente a tablas Artculo_Old y Modelo_Old), exportamos ambos archivos a formato XML y posteriormente con WinMerge vemos los cambios aadidos de uno a otro. Una vez tenemos eso, tendremos que actualizar dichos cambios en los archivos existentes que hayan hecho uso de la BB.DD. del Laboratorio ya que siempre se ha trabajado con la antigua y la informacin de la nueva no se encuentra actualizada. A continuacin expondremos lo anterior detalladamente pero antes ponemos un ejemplo simple para ver el formato de WinMerge. Tenemos 2 archivos de tipo .txt, en el primero escribimos HOLA, ESTO ES UNA PRUEBA y en el segundo HOLA, ESTO ES UN PRUEBA. Los cargamos en WinMerge y lo que obtenemos es lo siguiente:

Como vemos WinMerge nos sombrea en amarillo la fila donde hay un error y nos resalta este con otra tonalidad. A la izquierda del todo tenemos una ventana que nos indica como estn distribuidos los errores a lo largo del documento. Y debajo tenemos 2 ventanas ms donde se nos muestran las diferencias en detalle. Por ltimo, los pasos detallados para hacerlo con la BB.DD. del Laboratorio antigua y nueva seran:

1) Con PL/SQL abrimos la BB.DD. del Laboratorio antigua y nueva relacionando las tablas Artculo_Old con Modelo_Old y Artculo con Modelo. Los campos de inters a listar seran: IDARTICULO SERIALNUMBER FECHAPROXIMACALIBRACION FECHAALTA UBICACION PRECIOUNITARIO OBSERVACIONES IDESTADO_FK IDALMACEN_FK IDDISTRIBUIDOR_FK UNIDADES NUMEROMETROL UNIDADESRESERVADAS FECHAINICIALPROXIMACALIBRACION IDCASATOOL IDMODELO_FK NOMBRE DESCRIPCION Donde hemos resaltado en negro los campos de la tabla Artculo/Artculo_Old y en azul los campos de la tabla Modelo/Modelo_Old. La consulta a realizar en PL/SQL sera la siguiente para obtener el archivo para la BB.DD. del Laboratorio nueva:
select a.idarticulo, a.serialnumber, a.fechaproximacalibracion, a.fechaalta, a.ubicacion, a.preciounitario, a.observaciones, a.idestado_fk, a.idalmacen_fk, a.iddistribuidor_fk, a.unidades, a.numerometrol, a.unidadesreservadas, a.fechainicialproximacalibracion, a.idcasatool, a.idmodelo_fk, m.nombre, m.descripcion from articulo a, modelo m where a.idmodelo_fk = m.idmodelo order by a.idarticulo;

Y para obtener la vieja solo tendramos que cambiar articulo por por modelo_old.

articulo_old

y modelo

Recordamos que el tamao de las 2 consultas realizadas ser diferente, como ya dijimos para la BB.DD. del Laboratorio nueva tendremos 5487 elementos y para la BB.DD. del Laboratorio antigua tendremos 4954. Como ya comentamos esto sucede porque en la antigua hay elementos que no cumplen la condicin impuesta y esto ya se solucion en la versin nueva. 2) Exportamos ambas consultas a formato XML para lo cual nos situamos con el ratn sobre la primera fila y columna que aparece en la tabla (mismo sitio que cuando en el Excel seleccionamos toda la Hoja). Pulsamos con el botn secundario y en Export Results seleccionamos XML file y las guardamos. 3) Posteriormente abrimos WinMerge y cargamos ambos archivos y obtendremos algo como esto:

Aqu ya veremos los campos que han cambiado de la versin antigua a la nueva y podremos irlos actualizando. Si hacemos un anlisis de los campos que han cambiado en general son los siguientes: FECHAPROXIMACALIBRACION IDESTADO_FK FECHAINICIALPROXIMACALIBRACION 4) Lo ltimo sera ir realizando los cambios pertinentes. Esto es una tarea ardua y lenta as que el procedimiento a realizar lo dejamos un poco en el aire por si a alguien se le ocurre algo rpido y sencillo.