Base de Datos para Almud59

Creación de una Base de Datos para gestión de vendimia para Almud59

Juan Verón Gormaz

1º ASIR - Gestión de Base de Datos

enero-2.014

Para quién realizamos el trabajo:

        El trabajo referente a la creación de una base de datos se realizará para la oficina técnica “Almud59”, dedicada a asesoramiento en lo referente a temas técnicos agrícolas en general, y especialmente de la viña.

       En la actualidad, cuenta con 1 sólo empleado y sus oficinas se ubican en la calle Río Pie-dra nº 12 de Calatayud (Zaragoza).

      Como curiosidad, hemos investigado el significado de “almud”: antigua medida arábiga de capacidad o de superficie que en lo referente a medida de superficie, en Huesca y en Zaragoza, equivale a 59’5984 m², siendo de ahí de donde procede el nombre de esta oficina técnica: Almud59.

 

          En lo referente a "almud" podemos obtener más información en los enlaces siguientes:

http://www.proteccioncivil.es/catalogo/carpeta02/carpeta24/vademecum12/vdm02550.htm

http://es.wikipedia.org/wiki/Almud

Concepto básico del trabajo:

         Vamos a realizar una base de datos para gestionar información relativa a los procesos de vendimia y control de calidad de uva para producción de vino centrada en la Cooperativa del municipio de Munébrega a la que pueden dar entrada de producto tanto socios de ésta, como personal que denominaremos "Externos", únicamente colaboradores no socios, para lo que utilizaremos información del tipo: kgs/cepa, algunos análisis de las uvas, estado sanitario de las viñas, etc. Datos que afectarán a los resultados de cada campaña para controlar que el producto sea de calidad y determinar el momento oportuno de la vendimia.

         Para ello, además de información relativa a estos Socios/Externos será imprescindible almacenar una relación de parcelas con sus datos correspondientes, generalidades de cada variedad y referencias de la vendimia, que en principio parece ser lo fundamental y sobre lo que habría de girar la base de datos, sin embargo opino que el centro de la actividad se halla en las parcelas y es con lo que hemos de relacionar el resto de la información y de las tablas a desarrollar.

          Realmente no precisaremos demasiados datos en este sentido, pero lógicamente esto llevara consigo la gestión de información adicional relativa a los agricultores: socios o externos, parcelas con sus datos correspondientes de  localización, los tipos y variedades de uvas u otros apartados que pueden ser necesarios o útiles para el desarrollo de dicha actividad,

        En cuanto a Socios/Externos, Almud59, tiene mucho interés en conocer y poder separar bien si son socios de la Cooperativa o externos a ésta, si son miembros o no de la Junta, así como si son colaboradores o no, además de diversos datos personales, pero insiste en que todos se incluyan en una misma tabla donde diferenciemos esta información.

Cooperativa de Maluenda:

      La base de datos irá enfocada exclusivamente para trabajos de vendimia destinados a producción de vino en la Cooperativa de Maluenda, de la que seguidamente adjuntamos enlace a su web.

     Almud59 no tiene interés en gestionar con base de datos ninguna otra sección de su entorno de trabajo, al menos de momento.

        Web Cooperativa de Maluenda: http://www.castillodemaluenda.com/

   

Informática en Almud59:

         La infraestructura de Almud59, obviamente, es sencilla tanto en su funcionamiento en sí, como en lo referente al tema informático: un ordenador PC único con Sistema Operativo Windows 7, programas de Microsoft Office, diversos programas de imagen (Adobe Photoshop, Autocad) y poco más.

         A dicho ordenador accede exclusivamente el propietario, hecho que implica una menor necesidad de sistemas de seguridad en cuanto a accesos y, por supuesto, no precisa de dar permisos a otros usuarios, pues no los hay, ni existe red de trabajo.

             Lógicamente, se trata de una base de datos “ofimática” en la que lo más importante será la facilidad de manejo pues va a contener pocas tablas y una cantidad de información relativamente pequeña para lo que podría contener una base de datos corporativa, es decir: es para uso a pequeña escala.

         Vamos a trabajar en la línea de hacer una base de datos en la que:

       a) No haya redundancias pues la duplicación de datos es muy habitual entre personas que no conocen la dinámica de las bases de datos como, de hecho, sucedía en la idea básica en Almud59

    b) Los datos estén bien estructurados, facilitando así su manejo, que debe ser lo más sencillo posible.

Creación de Base de Datos

* Modelo Entidad/Relación - primeros pasos:

          Vamos a centrar la Base de Datos en la tabla PARCELAS, a la que vamos a relacionar todas las restantes tablas, a pesar de que la idea inicial es controlar las vendimias,de las que realmente precisaremos pocos datos concretos.

           Fundamentos para tomar esta decisión:

1) Cada parcela pertenece a un agricultor, socio de la bodega, o simplemente colaborador externo, del que guardaremos la información necesaria en la tabla Socios/Externos de forma conjunta.

      2) Cada parcela contiene diferentes tipos de uva para distintos tipos de vinos:

a) Vino Blanco / Vino Tinto

b) Vino de mesa / VCPRD / DO

c) Diferentes variedades: Garnacha, Cabernet, Tempranillo, Macabeo, etc. que pueden dar lugar individualmente a un vino concreto o ir en mezclas con diferentes proporciones y tratamiento, aunque este tema se sale ya de nuestra gestión pues dependerá de la bodega una vez realizada la vendimia.

      3) Anualmente habrá nuevas cosechas de las que realizaremos nuevas selecciones, nuevos análisis, nuevas vendimias cuyos datos habremos de relacionar con sus correspondientes parcelas, que habrán de estar en tablas diferentes y de ninguna manera incluyéndolos en la tabla de parcelas pues contienen información que se va sacando nuevamente cada para cada parcela de forma acumulativa (no “sustitutiva”).

      4) Una parcela se halla situada en una población o término municipal.

* Modelo Entidad/Relación - completo:

* Modelo Relacional:

·     *  SOCIOS {DNI_Socio, Letra NIF, Nombre, Ape-1, Ape-2, Tipo de vía, Domicilio, Número, Piso, Letra, Cod.Postal, Población, Provincia, Teléfono fijo, Teléfono móvil, Correo electrónico, CCC entidad, CCC sucursal, CCC DC, CCC Cuenta, Cliente Activo (S/N), Colaborador (S/N), Relación (S-socio/J-socio perteneciente a la Junta/E-Externo), Observaciones, Fecha actualización ficha}

   - Clave Primaria  {DNI_Socio }

   - VNN  {Nombre, Ape-1, Cliente Activo, Colaborador, Relación (S/J/E), Fecha}

·   * PARCELAS {Id.Parcela, DNI_socio, Id_población, Polígono, Nº parcela, Nº subparcela, Superficie en Has., Nombre del paraje, Regadío (S/N), Portainjerto, Código DGA, Nº de cepas (cantidad), Año de plantación, Tipo de poda (vaso, espaldera, vaso elevado), Marco de plantación, Producción ecológica (S/N), Parcela de vino de pago (S/N), Coordenada UTM (x),  Coordenada UTM (y), Coordenada UTM (z) }

   - Clave Primaria  {Id.Parcela}

 - Clave Ajena  {DNI_Socio (de la tabla SOCIOS), Código DGA (de la tabla VARIEDADES), Id_Población (de la tabla POBLACIONES)}

   - VNN {Polígono, Nº parcela, Nº subparcela} (Lógicamente, incluye todas la claves en VNN).

·  * VARIEDADES {Código DGA, Nombre, Tinto/Blanco, Nº de clon de la variedad, Mesa/VCPRD/DO}

   - Clave Primaria  {Código DGA}

   - VNN {Nombre, Tinto/Blanco, Mesa/VCPRD/DO}

·       *  POBLACIONES {Id_Población, Cod.Postal, Nombre}

- Clave Primaria  {Id_Población}

- VNN {Nombre}

·     *  VENDIMIA {Id-Vendimia, Id.Parcela, Año de vendimia, Seleccionada (S/N), Kgs/cepa, Sanidad (B/R/M), Análisis: PH, Análisis: Grado, Observaciones, Fecha de actualización de la ficha}

 - Clave Primaria {Id-Vendimia}

 - Clave Ajena {Id.Parcela (de la tabla PARCELAS)}

 - VNN {Año, Fecha actualización ficha}

* Modelo Relacional - restricciones:

•     RT1 En la tabla SOCIOS, la clave principal ha de ser un campo numérico de 8 dígitos, no aleatorio, sino que se introduce para cada Socio (o Externo) y ha de ser único
• 
  
•    RT2: En la tabla SOCIOS, los 4 campos de nº de cuenta, CCC, serán numéricos, a ser posible con las siguientes extensiones: CCC entidad (4 dígitos), CCC sucursal (4 dígitos), CCC-DC (2 dígitos), CCC-Cuenta (10 dígitos).
• 
  
•     RT3: En la tabla SOCIOS, el campo Cliente Activo es de tipo lógico: S/N.
• 
  
•     RT4: En la tabla SOCIOS, el campo Colaborador es de tipo lógico: S/N.
• 
  
•    RT5: En la tabla SOCIOS, el campo Relación solo admitir las siguientes 3 opciones S para Socios, J para Socios pertenecientes a la Junta y E para Externos (que no pueden pertenecer a la junta). Esta restricción se debe a que en Almud59 precisan distinguir estos tipos de socios o externos y el propietario de la empresa obliga a que todos estén en una misma tabla, creando por ello este campo que identifica a éstos según indiquen las letras J/S/E.
• 
  
•     RT6: En la tabla SOCIOS, el campo Fecha de actualización de la ficha, recomendaría que tomara por defecto la fecha del sistema, la fecha del día en que se accede a la ficha para insertarla tal cual o para modificarla si así lo considera el usuario final.
• 
  
•    RT7: En la tabla PARCELAS, el campo Regadío es de tipo lógico: S/N, identificando perfectamente con ello si se trata de Regadío o de Secano.
• 
  
•   RT8: En la tabla PARCELAS, el Año de Plantación es fecha (solo año). Puede ser conveniente restringir entre 1950 y 2050 para evitar despistes al teclear. Si la tabla se siguiera utilizando pasada esta fecha, siempre se podrían variar estas restricciones.
• 
  
•     RT9: En la tabla PARCELAS, el campo Producción ecológica es de tipo lógico: S/N.
• 
  
•     RT10: En la tabla PARCELAS, el campo Parcela de vino de pago es de tipo lógico: S/N. Como ya explico en la memoria, una parcela de pago es la que esté produciendo una uva especial para un vino especial y pueda pagarse a un precio superior. También recuerdo que a mi modo de ver este campo debería ir relacionado con la producción anual, es decir en la tabla VENDIMIA, pero el usuario final se niega a que sea así y él es quien, en definitiva, manda a la hora de realizar este trabajo.
• 
  
•   RT11: En la tabla PARCELAS, los campos: Nº de cepas, Coordenada UTM (x),  Coordenada UTM (y), Coordenada UTM (z) serán numéricos.
• 
  
•     RT12: En la tabla VENDIMIA, el campo Seleccionada es un campo lógico, con respuesta SI o NO
• 
  
•     RT13: En la tabla VENDIMIA, el  campo Sanidad solo precisa un dígito para las letras: B: Buena /R: Regular / M: Mala) pues solo se va a usar para tener una pequeña referencia de la salud del cultivo.
• 
  
•     RT14: En la tabla VENDIMIA, si fuera de interés para el programador o para el usuario final, tenemos 2 opciones: 1) que la clave primaria Id-Vendimia se inserte de forma automática o bien 2) obviar dicho campo (Id-Vendimia) y asignar como claves primarias la unión de Id.Parcela+Año de vendimia que identificarían de forma única cada registro. Quizás lo más cómodo sea mantener la Id-Vendimia como se hace constar en el modelo Entidad/Relación y en éste mismo.
• 
  
•    RT15: Se debe tener en cuenta que aunque un Socio pueda desaparecer o pasar a Pasivo, sus parcelas pueden continuar en activo a nombre de un heredero o alguien que se haga cargo de ellas y por tanto no habrían de ser borradas aunque se elimine el Socio. Otra razón para no borrar estos campos aunque desaparezca el propietario, es en lo referente a posibles consultas históricas que se devaluarían en tal caso.

- NOTA 1: Aunque pueda parecer que el campo “Portainjerto” en la tabla PARCELAS pudiera incluirse en VARIEDADES no es así pues una misma variedad pueden llevar diferente portainjerto y viceversa.

- NOTA 2: La tabla VENDIMIA puede contener algunos campos vacíos pues se pueden ir completando en diferentes días dado que sus datos se van produciendo a lo largo de un tiempo hasta llegar a la vendimia. En esta tabla se repetirán las mismas parcelas de la tabla PARCELAS, pero con diferentes años de vendimia, siempre y cuando ésta se produzca o, al menos se pretenda realizar en cada año correspondiente.

* Vista de las tablas normalizadas:

Consideraciones:

      En el momento de generar la base de datos, existen las siguientes consideraciones que creo son importantes:

       1) La arquitectura de la Base de Datos es de capa 1: el usuario, la base de datos y el gestor se hallan en el mismo equipo.

        2) No existe concurrencia. Solo hay un usuario y no se va a trabajar en red.

        3) No precisa conectividad con el exterior.

      4) Considero muy importante la gestión de copias de seguridad: Programar Access para que haga copias de seguridad y avisar al usuario de la importancia de éstas y recomendarle que también haga copias manualmente en memorias USB o discos externos.

       5) En principio no se gestionan informes, vistas y demás usos de la base de datos que habría que considerar a posteriori, sin embargo, detallamos seguidamente algunas posibilidades según los intereses de Almud59 

Posibilidades que tenemos con esta base de datos:

        Algunas de las vistas o informes que podemos plantearnos, según las referencias que hemos sacado de ambas entrevistas, pueden ser:

* Relación de vendimia de un año:

- Total.

- Por Socio/Externo.

- Por tipo de vino: blanco, tinto.

- Por tipo de vino: de pago, de mesa, denominación origen.

* Listado de Socios/Externos (datos personales).

* Relación de parcelas:

- Según propietario -Socio/Externo-

- Por tipo de vino (igual a vendimia).

* Etiquetas con datos para envío de cartas o incluso para usar en cabecera de una carta:

- Socios

- Socios de la Junta

- Externos

- Colaboradores o No colaboradores

- Otros

Sistema gestor de la base de datos: Oracle o Access:

       En la oficina técnica Almud59 ya están utilizando Access para gestión de pequeñas bases de datos e incluso para envío de correspondencia a los Socios/Externos tomando los datos de los destinatarios de una tabla generada con dicha información.

        Planteo la posibilidad de hacer la base de datos “Vendimia” con Access o con Oracle que nos da mucha mayor seguridad, fiabilidad, capacidad, rapidez. José Luis me deja muy claro que no quiere complicaciones y que él conoce Access mientras que Oracle no lo ha oído en su vida y que ya tiene diversos datos en diferentes tablas de Access.

         Esto me hace plantear directamente el uso del gestor de base de datos de Microsoft para crear y gestionar la vendimia, más aún cuando la implantación de Oracle resultaría un gasto innecesario pues al tratarse de una base de datos pequeña donde vamos a tener pocas tablas (en las que de ninguna manera se va a llegar al millar de registros) no vamos a precisar de la velocidad de acceso y de gestión de Oracle, siendo suficiente con Access. Tampoco tenemos problemas de seguridad, y por tanto no hace falta el control que nos daría Oracle sobre quién puede o no acceder a los datos pues José Luis es la única persona que los va a utilizar. Igualmente, al ser un único usuario no habrá riesgo de corrupción por uso simultáneo de la base de datos, siendo suficiente con las prestaciones dadas por Access.

      No he planteado ningún otro gestor, pues hoy por hoy son los únicos con los que yo podría trabajar. Siempre cabría la posibilidad de que un programador de la aplicación fuera quien realizara dicha programación con los diseños que le proporcionáramos, pero el usuario final solicita que se le haga en Access y no es preciso involucrar a ningún programador.

  

Elección: ACCESS

Coste estimado de gestión de la Base de Datos:

       Aplico las horas empleadas en cada sección y un coste horario que considero razonable, aprox. 15 €/h al que habría que sumar su correspondiente IVA. Lógicamente de ahí descontaríamos el IRPF.

·       Estudio previo, 2 entrevistas, organización y selección de información:  aprox.
                                                                                                                                    120 €

·       Estudio Modelo E/R, modelo relacional, todo lo relativo a diseño:
                                                                                                                                    105 €

·       Programación: creación de tabla, campos, relaciones y restricciones:
                                                                                                                                      75 €

·       Instalación y aprendizaje del usuario final:
                                                                                                                                      45 €

TOTAL (IVA aparte)                                                                                             ------------------------

                                                                                                                                            345 €

      A este presupuesto habría que añadirle el IVA y si después hay modificaciones (no correcciones) habría que ampliar lo que corresponda a cada variación a realizar. Por supuesto, si son correcciones o errores, habrían de ser asumidos dentro de este presupuesto.

INFORMACIÓN ADICIONAL -
PRIMEROS PASOS, ENTREVISTAS, FILTRADO DE INFORMACIÓN:

Datos de la primera entrevista con José Luis/Almud59

      Cuando hablamos de gestionar los procesos de producción, de vendimia, control de calidad etc., José Luis comienza explicándome que quienes proporcionan la uva a la Coope-rativa de Maluenda, pueden ser socios de ésta o únicamente colaboradores a los que denomina “Externos”. Me dice que de todos ellos precisará exactamente los mismos datos personales (a primera vista entreveo una relación de herencia que después estudiaremos más detenidamente): NIF, nombre, domicilio, teléfono, número de cuenta, tipo de cultivo (ecológico o no) que realiza este productor.

     Parece ser imprescindible también almacenar una relación de parcelas, con su localización, municipio, superficie, polígono, nº de parcela y subparcela, superficie, nombre del propietario,  contenido de cada parcela: cepas, variedades, destino, tipo de poda, secano o regadío, cosecha anual, tipo de selección, sanidad, análisis de ph y grado y fecha de análisis..etc., las variedades plantadas, sus códigos según DGA, si son tinto o blanco, para mesa o denominación de origen, nombre del portainjerto número de cepas y otros datos, todos ellos relacionados con dichas parcelas.

         Por mi parte, no acabo de ver clara esta mezcla de datos y tomo nota para estudiarlos con detenimiento pues incluye datos propios de la parcela con otros que corresponden al  cultivo anual de cada una de esas parcelas e incluso hay otra información que parece no estar incluida ni siquiera en el tema de cultivo. Veo que pretende incluir datos de cada variedad en cada una de las parcelas, pero sería más lógico crear una tabla con los datos de cada variedad y relacionarla con las parcelas.

         Le comento a José Luis la posibilidad de desdoblarlo en, al menos, 2 tablas diferentes o quizás 3. En principio es algo reacio, quizás porque no me haya sabido explicar.

         En esta primera entrevista, el propietario me hablaba también de una serie de datos que, desde mi punto de vista, no eran relevantes para el seguimiento de la vendimia y lo único que podían hacer era enturbiar algunas de las tablas. Ciertamente, podían ser interesantes en cuanto a tener más información de los Socios/Externos o de sus parcelas, pero no se precisan de ningún modo para el trabajo a realizar. Incluyo información sobre este tema a continuación en el apartado: conceptos no utilizados.

Conceptos no utilizados:

         En una segunda entrevista, de la que después incluyo breve informe, sugerí a José Luis, separar ciertos datos en tablas adicionales de Socios/Externos y de Parcelas o incluso eliminarlos sin crear ninguna tabla pues parecen ser datos prescindibles. Opino que con buen criterio, tomó esta segunda opción y finalmente no llegamos ni a plantear la creación de estas tablas adicionales.

         Relaciono seguidamente algunos de dichos conceptos no utilizados en la base de datos por dar más detalle de la elaboración y filtrado realizado e incluso el porqué de no emplear esta información:

1)  José Luis tenía intención de incluir en la tabla Socios todo lo relativo a consultas realizadas por éstos, con la siguiente información: Pregunta concreta de un socio, Consulta remitida por el Atria, Lugar donde se efectúa la consulta, Fecha de consulta del Atria, Respuesta dada al Atria, Lugar o medio de respuesta, Satisfacción con el trato recibido por el Atria y por el Socio.

   En este caso concreto, como solo algunos clientes, muy pocos, hacen consultas y además los hay que repiten diferentes consultas, le propuse hacer una tabla exclusiva para éstas y de ningún modo incluirlo, como él pretendía, en la tabla Socios/Externos.

   Por otra parte también le insté a que guardara toda la documentación de cada consulta en los ficheros físicos de socios, pudiendo localizar físicamente los datos en caso de precisarlos.

   El Sr. Rosel se planteó que definitivamente era mejor esa solución y no complicar más la base de datos pues no era información necesaria para el control de las vendimias, más aún cuando raras veces había precisado revisar dichas consultas a posteriori.

2)  También pretendía adjuntar datos de los Socios en cuanto a su relación con la DGA, relación con el Atria, planes de re-estructuración, censo de viña y numerosos datos en esa línea que igualmente consideré no precisos para el caso y que comentándolo con José Luis en la 2ª entrevista optó por no considerar, pudiendo así eliminar posibles tablas o numerosos campos de la tabla Socios/Externos que la hubiera hecho excesivamente extensa.

3)   La idea de José Luis de adjuntar información no precisa para el seguimiento que él pretende realizar se da también en las parcelas, donde deseaba incluir Código de parcela según la DGA, Seguimiento de la DGA en cuanto a ensayos, Punto de Control de Plagas, Punto de seguimiento de plagas, nº de la parcela según el catastro viejo, Diversos datos de laboratorio y de análisis que NO le resultan necesarios y otros muchos datos.

   Nuevamente le propongo hacer otras tablas para esta información o bien eliminarla si no le es necesaria y, como en la anterior ocasión, decide que no le hace falta para nada y mejor no tener en cuenta nada de esto.

  En la segunda entrevista con José Luis, cuando comentamos todas estas correcciones o eliminaciones, le cuestiono sobre tal cantidad de información que no es de utilidad o que al menos podemos considerar prescindible y entiendo el porqué de ello: José Luis, hace unos años, gestionaba varias cooperativas, no solo para la vendimia y producción, sino que también se hacía cargo de las compras de vides, de los trámites legales con DGA, con Atria, informaba a los socios o a sus clientes, solucionaba problemas de plagas y enfermedades y otras muchas cuestiones de las que ahora no se hace cargo y por ello precisaba de mucha más información que tenía en la cabeza a la hora de enfocar la base de datos, pero que tras ambas entrevistas conmigo y algunos comentarios realizados, ha observado que no precisa para nada.

Otros datos no comentados aún de la segunda entrevista con José Luis Rosel / Almud59:

          El Sr. Rosel me había hablado de Socios y Externos y me dijo que debería haber alguna diferencia entre ellos, pero no acabo de encontrarla, así que le pido que me explique en que discrepan y parece ser que aparte de lo referente a que unos sean Socios y otros No socios o Externos, la única variación, al menos en cuanto a datos a insertar en nuestra base, es que un socio puede pertenecer o no a la junta, mientras un externo no puede pertenecer a la junta.

          José Luis da mucha importancia a que un socio pueda ser o no colaborador y me insiste en que desglose Socios y No socios para identificar también a colaboradores o no. Le sugiero varias opciones a estudiar haciendo alguna tabla paralela o bien dejándolos en una misma pero adjuntando otra tabla que diferencie algunos factores como  si son miembros o no de la junta, si son o no colaboradores, etc.; entonces me indica que sucede lo mismo con los Externos, que pueden ser o no colaboradores a pesar de estar incluidos en la tabla. No veo claro el asunto e insisto en ello.

       Parece ser que, para José Luis, la mayor importancia de estos datos está en que a la hora de confeccionar cartas, tomando información de la base de datos, puedan determinar que sean exclusivas para colaboradores, para socios o para miembros de la junta. Entiendo que siendo únicamente esta la causa, no precisamos desdoblar tablas, ni siquiera desdoblar campos, pues me resulta más cómodo aunar todo ello en un solo campo que puede darnos la información exacta de forma sencilla, un campo en el que tengamos, por ejemplo, la opción de definir J: socios pertenecientes a la junta, S: socios no pertenecientes y E: Externos (no socios).

       También barajamos la posibilidad de hacer constar si un socio está en activo o no y conocer con qué fecha se ha actualizado o revisado una ficha. Campos que añadiremos a dicha tabla.

          Le explico que habríamos de hacer diferentes tablas, una de “Parcelas” con los datos de la parcela propiamente dicho (datos que habitualmente no cambian de un año a otro: localización, superficie, portainjerto, tipo de poda, etc) y otra tabla, que podemos llamar “Vendimia”, con los datos que sí pueden variar anualmente y van enfocados concretamente a la vendimia de cada año, como son kgs/cepa, sanidad de la parcela, análisis de las muestras y por supuesto fecha de captación de todos estos datos (variables según fecha), añadiendo además resultados de análisis que se vayan realizando. También recomiendo poner todos datos del tipo de uva en una tabla “Variedades” relacionada con las parcelas mediante un identificador de estas variedades.

         José Luis se da cuenta entonces de que es muy importante la situación de cada parcela en coordenadas UTM (x, y, z) e incluso la posibilidad de un campo para observaciones que no habíamos considerado en la primera entrevista. Me habla también de información para anotar si una parcela es “de pago” es decir si es útil para hacer un vino especial; le digo que sería mejor incluirlo en la tabla “Vendimia” pues considero que puede es un dato que puede variar anualmente, pero él dice que no, que él quiere que vaya en la tabla “Parcelas”.

         En varios puntos de la entrevista inicial habíamos hablado de variedades, En ese sentido le recomiendo que hagamos una tabla exclusiva para las variedades con las características de cada una de éstas y que las otras tablas que precisen estos datos se relacionen con su clave primaria. José Luis capta el concepto y le parece razonable y me indica que los datos imprescindibles para una variedad serían los siguientes: nombre, tipo (blanco/tinto), tipo de vino (vinos de mesa/ vinos de calidad producidos en región determinada/denominación de origen), nº de clon de la variedad y código de la variedad dado por DGA. Al ser exclusivo este nº dado por DGA veo que puede usarse como clave primaria, más aún cuando hay una lista de variedades con dicha numeración que facilitaría su numeración y su utilización.

      Parecía que ya que había concretado todas la tablas, pero José Luis me indica que, a petición suya, haga una minitabla solamente para las poblaciones en las que haya parcelas porque él prefiere tener una relación de éstas y que en la tabla “Parcelas” tome los datos mediante la id de poblaciones. “Municipios” incluirá únicamente una “id”, nombre y acaso los códigos postales. Hemos de tener en cuenta que todas ellas son poblaciones localizadas en un radio cercano a Maluenda.