En un principio, el proyecto que iba a presentar al concurso no era JavaDiKt, sino otro llamado Javadict. Javadict (con “c”, y no con “k” de “kanji”) iba a ser una librería/API de propósito general para construir diccionarios de cualquier tipo de manera rápida y sencilla en Java. Iba a proveer de una serie de clases para modelar los contenidos (como podrían haber sido las clases “Verb” o “Adverb“) con sus respectivos mecanismos de almacenaje y recuperación. Era un proceso ambicioso, quizás más que el actual, pero al final decidí hacer algo más práctico y dejé el proyecto en el tintero para el futuro. El caso es que de esta idea surgió JavaDiKt y decidí usar algunas cosas que tenía en mente sobre el proyecto anterior en éste. Así, me propuse elaborar en una pequeña biblioteca independiente del resto del programa que contuviese todo lo necesario para la recuperación de los datos. Ese paquete acabaría siendo el actual paquete data.

En el paquete data, el modelado de datos está implementado en data.kanji, del que hemos hablado las semanas anteriores, mientras que las funciones que permiten consultas estás contenidas en data.dict:

Paquete data, data.dict está a la derecha. Haz click para verlo más grande.

Como podemos ver en el diagrama, el paquete se divide a todas sus clases en el mismo paquete data.dict y en el subpaquete data.query.

La clase KanjiDatabaseManager, que extiende de DatabaseManager, es una clase que hace de interfaz entre la base de datos y la clase KanjiDict, que es la interfaz de más nivel que recubre a todas las posibles interfaces dedicadas a la consulta. KanjiDict, cuando recibe una consulta, resuelve a que base de datos debe hacerla(aunque de momento solo hay una base de datos, representada por NeodatisKanjiDatabaseManager, pero es probable que en el futuro haya más)  y realiza todos los cálculos necesarios sobre los datos extraídos antes de devolverlos. NeodatisKanjiDatabaseManager traduce las consultas de KanjiDict al lenguaje de la base de datos ( en este caso, Neodatis ODB) y realiza el trabajo sucio extrayéndolos para servirlos devolverlos de nuevo a KanjiDict.

El caso es que al implementar NeodatisKanjiDatabaseManager de DatabaseManager, KanjiDict puede usar la interfaz genérica de DatabaseManager para acceder a los datos, lo que permitirá, llegado el día, cambiar fácilmente de base datos simplemente implementando una nueva instancia de DatabaseManager, como pudiera ser, por ejemplo, MySQLDatabaseManager, SQLiteDatabaseManager o XMLDatabaseManager.

Por otro lado el paquete data.dict.query conforma mediante sus clases el mecanismo de elaboración de consultas y queries. En este paquete se diferencian 3 clases principales: la clase KanjiQuery, la clase ValueQAbout y la clase KanjiExpression. Estas tres clases representan las 3 de las 4 fases de las que está compuesta la elaboración de una query simple en lenguaje natural, que son:

1. Selección: elegir el tipo de dato que se quiere recuperar. En el caso de JavaDiKt, el dato a recuperar será siempre “Kanji”, por lo tanto no existen clases que modelen este comportamiento, todas las queries empezarán directamente en la siguiente fase. En SQL vendría dado por el comando SELECT.
2. Exclusión: En este conjunto de fases distinguimos entre los elementos que queremos seleccionar y los que no. En SQL el comienzo de estas fases vendría dado por la expresión WHERE. En data.dict.query, este proceso comienza creando una nueva instancia de la clase KanjiQuery.
   1. Atribución: en esta fase determinamos para que atributos del tipo de datos especificado en la fase de selección queremos establecer una condición. En data.dict.query, el proceso seguiría al llamar desde la instancia creada anteriormente de KanjiQuery al método con el nombre del atributo del cual queremos hacer la atribución, lo cual nos devolvería un objeto de tipo ValueQAbout que representa los tipos posibles de condicionamientos posibles que pueden hacerse sobre dicho atributo
   2. Condicionamiento: a continuación, definimos la condición que ha de cumplir la atribución anterior para que las instancias del tipo de dato elegido en la primera fase sean devueltos. En data.dict.query, elegiríamos del objeto ValueQAbout obtenido en la fase anterior el tipo del condicionamiento que queremos aplicar sobre el atributo al que se refiere, obteniendo un objeto de tipo KanjiExpression. Llegados a este punto, KanjiExpression conforma ya una expresión válida y bien formada que describe un kanji o conjunto de kanjis, y puede ser usada para hacer consultas a la base de datos (podemos ver que el método executeQuery() de Kanjidict tiene como único argumento este tipo de datos). Sin embargo, si parásemos aquí, solo podríamos hacer exclusiones basándonos en un único atributo, razón por la que existe una fase opcional.
   3. Sobrexclusión: en esta fase, iniciamos una nueva etapa de exclusión que podrá que impondrá nuevas restricciones sobre el tipo de dato elegido. En data.dict.query, la clase KanjiExpression provee de los métodos AND() y OR() que permiten iniciar de nuevo el proceso devolviendo un nuevo método KanjiQuery. La expresión no volverá a ser válida y a estar bien formada hasta que del proceso se vuelva a obtener un nuevo método KanjiExpression.

Después de esto, creo que ayudará ver varios ejemplos:

1
2
3
4
5
6
7

//Busca los kanjis cuyo código unicode sea 0x4FFF o 0x4FF1
KanjiExpression unicodeQuery = new KanjiQuery().unicode_value().equalz(0x4FFF).OR().unicode_value().equalz(0x4FF1);
 
//Busca los kanjis con número de trazos entre 3 y 5inclusive
KanjiExpression strokeQuery = new KanjiQuery().stroke_count().greatherThan(3);
     //Puede hacerse también en varios pasos
strokeQuery = strokeQuery.AND().stroke_count().equalsOrLessThan(5);

Ahora para ejecutar la query tendríamos que hacer:

8
9
10

KanjiDict kanjiDB;
 
Set<KanjiTag> retrievedKanjis = kanjiDB.executeQuery(strokeQuery);

Dos últimas anotaciónes. La primera, quizás os habéis percatado que su utiliza una clase distinta para cada valor de ValueQAbout relacionado con una propiedad de cada kanji cuando eso no es realmente necesario. Podría haberse usado un ValueQAbout genérico con un campo que definiese a que propiedad del Kanji se refiere y evitar así la multiplicidad de clases. Sin embargo, lo hice de esta manera porque pienso que en futuro se podrán refinar las clases en función de las características de cada propiedad. Por ejemplo, podría definirse para KanjiGraphQAbout un nuevo tipo de condicionamiento que sea, por ejemplo, “se parece a” o “tiene el radical x“.
La segunda, es referente a aquellas propiedades del kanji que tienen más de un valor, como por ejemplo la variante, el código JIS o el significado. Veamos un trozo de código:

1
2
3

KanjiExpression ke1 = new KanjiQuery().dictionary_name.equalz("gakken");
KanjiExpression ke2 = new KanjiQuery().dictionary_reference.equalz("234");
KanjiExpression ke3 = new KanjiQuery().dictionary_name.equalz("gakken").AND().dictionary_reference().equalz("234");

Lo que definen estas tres expresiones puede ser confuso, pero en realidad es muy simple. Al ejecutar la primera de ellas, la base de datos devolverá todos los kanjis que tienen una referencia en el diccionario Gakken, es decir, todos los kanjis que aparecen listados en dicho diccionario. La segunda, todos los kanjis que en cualquiera de los diccionarios tienen la referencia 234. La tercera y última devolverá el kanji del diccionario Gakken que tiene la referencia 234. Para este tipo de consultas es donde la sobreexclusión se hace imprescindible, otorgando al sistema de elaboración de queries gran poder.

Con esto terminamos por fin con la serie referente al paquete data kanji. En las próximas entradas empezaremos a hablar de la interfaz gráfica y los paquetes subyacentes.

Cuando empecé a pensar en como iba a hacer funcionar todo lo que había pensado para JavaDiKt, lo primero que pensé fue en como almacenar los datos de manera rápida, eficiente y sencilla. Lo primero que consideré fue en recuperar los datos sobre la marcha directamente desde un archivo XML, pero pronto me di cuenta de que el acceso secuencial típico de este tipo de archivos significaba problemas a la hora de hacer búsquedas complejas como las que pretendía.

Después medite la posibilidad de usar alguna base de datos ligera tipo SQL, que pudiese incluirse dentro del mismo programa (es decir, que no necesitase un programa externo). Investigando encontré SQLite, y seguidamente un port para Java. Esta era la solución idónea, pero para mi suponía un hándicap importantísimo, pues si lo que se sé de SQL es poco, lo que sé de modelado de datos SQL es aún menos, eso sin contar la batería de adaptadores y parseadores que tendría que desarrollar.

Estaba ya resignado a tener que empollarme un manual de SQL cuando por casualidad encontré bicheando por Internet algo llamado bases de datos de objetos. Éstas se caracterizan por:

• Permiten almacenar y recuperar objetos de cualquier tipo siempre de manera íntegra, es decir, almacenas un objeto con todos sus atributos y lo recuperas en el mismo estado en el que fue almacenado.
• La base de datos viene modelada según los tipos de clases a las que pertenecen los objetos que están almacenados en ella. Esto quiere decir, por ejemplo, que al almacenar un objeto crearas un nuevo tipo tabla con el nombre de su clase como nombre de la tabla y los atributos de dicha clase como dominios, añadiendo nuevos datos a esa tabla cada vez que añades un objeto de la misma clase.
• Los objetos almacenados en otro objeto como campos o en contenedores formarán tablas nuevas en la base de datos, pudiendo realizar entonces consultas sobre estos objetos sin tener que referirse al objeto que los contenía.
• Cada query solo podrá contener expresiones referentes a un tipo de clase. Esto significa que solo podrá extraerse de la base de datos un tipo de objeto a la vez.
• Cada base de datos es fuertemente dependiente del lenguaje para el que está diseñado y depende en gran medida de las propiedades de éste, como herencia, tipos, genéricos,…etc. Por tanto, las querys son construidas usando métodos, estilos y técnicas propias del lenguaje de programación elegido.

Tengo que decir que me impresionó la sencillez y elegancia del invento, que solucionaba todos mis problemas. De una tacada me ahorraba tanto el modelado de datos usando el mismo modelado de clases del programa, como la construcción de adaptadores recuperando los objetos directamente de la base de datos.

Buscando entonces algo parecido para Java me topé con Neodatis, una base de datos de este estilo y de software libre, con una documentación adecuada y un desarrollo lo suficientemente maduro, y decidí tras una serie de pruebas que era viable su uso.

Además de todo lo dicho anteriormente, Neodatis incluye además algunas características interesantes extras como la posibilidad de construir índices de un campo en concreto de una clase para acelerar las búsquedas de objetos, elaboración de queries muy intuitiva, elección de codificación, exportación/importación XML o una api de desarrollo de constructores de queries.

Sin embargo, Neodatis también presenta algunos problemas importantes.Después de las pruebas, he comprobado que:

• La mezcla de herencia y tipos genéricos en una misma clase genera problemas a la hora de recuperar objetos de dicha clase.
• La única consulta posible sobre contenedores que sean campos de una clase es contains. Esto quiere decir que si, por ejemplo, tenemos una lista de números dentro de un objeto de tipo grupo de números, podremos recuperar todos los objetos de tipo grupo de números que contengan al número 5, pero no a todos los que contengan números menores que 5.
  Además para tipos como los mapas ni siquiera esto será posible
• Todos los métodos de la base de datos usan técnicas de reflexión y consultas en tiempo de ejecución sobre los tipos de datos, lo que significa que no existe seguridad en los tipos en ningún momento.
• Hasta donde he podido probar, no es posible acceder a la base de datos usando distintos hilos. Solo un proceso puede manejarla a la vez.
• Las consultas sobre igualdad de objetos se basan en la igualdad de atributos entre las dos clases y no en el método equals de cada clase.

Y con esto terminamos la entrada de hoy. En la próxima, veremos como todos estos factores han sido fundamentales a la hora de definir la estructura del paquete data.kanji.