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).
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 m2, 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:
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.
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.
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.
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.
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:
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:
* 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:
* 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.
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.
Coste
estimado de gestión de la Base de Datos: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
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 €
120 €
· Estudio
Modelo E/R, modelo relacional, todo lo relativo a diseño:
105 €
105 €
· Programación:
creación de tabla, campos, relaciones y restricciones:
75 €
75 €
· Instalación
y aprendizaje del usuario final:
45 €
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:
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.
