¿Mejores prácticas para acceder a datos sin esquema?

Question

Estoy jugando con RDF y, en particular, cómo acceder a la información almacenada en un almacenamiento de rdf. La gran diferencia de una base de datos relacional tradicional es la falta de un esquema predefinido: en una base de datos relacional, usted sabe que la tabla tiene esas columnas, y puede mapear técnicamente cada fila a una instancia de una clase. La clase tiene métodos bien definidos y atributos bien definidos.

En un sistema sin esquema, no sabe qué datos están asociados a una determinada información. Es como tener una tabla de base de datos con un número arbitrario y no predefinido de columnas, y cada fila puede tener datos en cualquier número de estas columnas.

Similar a ObjectRelational Mappers, existen mapeadores Object RDF. RDFAlchemy y SuRF son los dos que estoy jugando en este momento. Básicamente, le proporcionan un objeto de Recurso, cuyos métodos y atributos se proporcionan dinámicamente. Tiene algún sentido ... sin embargo, no es tan fácil. En muchos casos, prefiere tener una interfaz bien definida y tener más control de lo que sucede cuando establece y obtiene datos en su objeto modelo. Tener un acceso tan genérico hace que las cosas sean difíciles, en cierto sentido.

Otra cosa (y más importante) he observado es que, incluso si engenerales, se espera que los datos sin esquema para proporcionar información arbitraria sobre un recurso, en la práctica más o menos clases saber" de la información "que tienden a estar juntos". Por supuesto, no puede excluir la presencia de información adicional, pero esto, en algunos casos, es la excepción, en lugar de la norma, aunque la excepción es lo suficientemente sensible como para ser demasiado perjudicial para un esquema estricto. En una representación en rdf de un artículo (por ejemplo, como en los feeds RSS/ATOM) conoce los términos de los recursos descritos y puede asignarlos a un objeto bien definido. Si proporciona información adicional, puede definir un objeto extendido (heredado de la base) para proporcionar acceso a la información mejorada. De modo que, en cierto sentido, puede tratar con datos sin esquema por medio de "objetos orientados al esquema", puede ampliar cuando desea ver información adicional específica que le interese.

Mi pregunta es relativa a su experiencia sobre las prácticas de uso del mundo real de almacenamiento de datos sin esquema. ¿Cómo se asignan al mundo orientado a objetos para que pueda usarlo con soltura y sin acercarse demasiado al "bare metal" del almacenamiento sin esquema? (en términos de RelDB, sin utilizar demasiados SQL y directamente jugando con la estructura de la tabla)

El acceso está condenado a ser muy genérico (por ejemplo, los "atributos conectados" de SuRF son el nivel más alto y especializado que puede tener acceda a sus datos), o tener clases especializadas para esquemas convenientes convenidos específicos también es un buen enfoque, ¿pero presenta el riesgo de tener una proliferación de clases para acceder a datos asociados nuevos e inesperados?

Answer 1

Supongo que mi respuesta breve sería "do not". Soy un poco greybeard, y he hecho un montón de mapeo de datos XML en bases de datos relacionales. Si decide utilizar una base de datos de este tipo, tendrá que validar sus datos constantemente. También necesitarás una disciplina muy estricta para evitar tener bases de datos con poca similitud. Usar un esquema ayuda aquí, ya que la mayoría de los esquemas XML están orientados a objetos y son extensibles, aliviando la necesidad de análisis para evitar crear datos similares con nombres diferentes, lo que hará que cualquiera que tenga que acceder a su base de datos piense mal sobre usted.

En mi experiencia personal, si está haciendo el tipo de cosas que una base de datos en red tiene sentido, vaya por ello. De lo contrario, perderá todas las otras cosas que las bases de datos relacionales pueden hacer, como la verificación de integridad, las transacciones y la selección de conjuntos. Sin embargo, dado que la mayoría de las personas usa una base de datos relacional como una tienda de objetos de todos modos, creo que el punto es discutible.

En cuanto a cómo acceder a esa información, simplemente colóquela en una Hashtable. Seriamente. Si no hay ningún esquema en ninguna parte, nunca sabrá qué hay allí. Si tiene un esquema, puede usarlo para generar objetos de acceso, pero gana poco, ya que pierde toda la flexibilidad del almacén subyacente al mismo tiempo que gana la inflexibilidad de un DAO (Objeto de acceso a datos).

Por ejemplo, si tiene una Hashtable, obtener los valores de un analizador XML a menudo es bastante fácil. Usted define los tipos de almacenamiento que va a utilizar, luego recorre el árbol XML y coloca los valores en los tipos de almacenamiento, almacenando los tipos en una tabla Hashtable o en una lista, según corresponda. Sin embargo, si se utiliza un DAO, terminan por no ser capaz de extender trivialmente el objeto de datos, uno de los puntos fuertes de XML, y hay que crear métodos get y set para el objeto que hacer

public void setter(Element e) throws NoSuchElementException { 
    try { 
     this.Name = e.getChild("Name").getValue(); 
    } catch (Exception ex) { 
     throw new NoSuchElementException("Element not found for Name: "+ex.getMessage()); 
    } 
} 

Excepto , por supuesto, tiene que hacerlo por cada valor individual en esa capa de esquema, incluidos cargadores y definiciones para subcapas. Y, por supuesto, terminas con un lío mucho más grande si usas los analizadores más rápidos que emplean devoluciones de llamada, ya que ahora tienes que rastrear a qué objeto perteneces mientras produces el árbol resultante.

He hecho todo esto, aunque normalmente construyo un validador, luego un adaptador que proporciona la correspondencia entre el XML y la clase de datos, luego un proceso de conciliación para reconciliarlo con la base de datos. Casi todo el código termina siendo generado, sin embargo. Si tiene la DTD, puede generar la mayor parte del código de Java para acceder a ella, y hacerlo con un rendimiento razonable.

Al final, simplemente mantendría datos de forma libre, en red o jerárquicos como datos de forma libre, en red o jerárquicos.

Answer 2

No tengo experiencia con esquema menos DB combinado con OOP, con tengo un año de experiencia con un esquema menos DB y scripting. Desde mi experiencia, puede ser bastante útil. El DB que he usado también estaba sin tipo (todas las cadenas arbitrarias). Esto lleva a las siguientes ventajas:

• no tiene que preocuparse por la estructura de su base de datos. Si necesita almacenar algo, simplemente almacénelo. Y no tiene que preocuparse por los tipos de datos que se ajustan al lenguaje de scripting
• puede agregar fácilmente la información de depuración a "objetos" cuando sea necesario sin tener columnas vacías para la mayoría de las filas de la tabla. Esto le permite incluso almacenar grandes cantidades de datos donde sea necesario,
• no tiene que preocuparse por las actualizaciones de la estructura de la base de datos. Simplemente escriba los datos nuevos que acompañan a su nueva versión de software en la base de datos.De esta forma, no necesita un administrador para actualizar su estructura de tabla y convertir sus datos antiguos. Lo que ocurre sobre la marcha
• si la clave de los valores clave pares tiene un nombre meaningfull, que no necesita mucha documentación para sus datos

Así que en mi caso, el esquema menos DB junto con el guion fue muy útil y un gran éxito.

Cuando piense en usar objetos para el esquema menos DB, trataría de mantener la libertad almacenando los objetos en una tabla hash. Esto le daría la libertad de acceder a todos los pares clave-valor, sin importar qué "objeto" haya seleccionado. También le daría la libertad de agregar nuevos pares clave-valor según sea necesario.

Si sus objetos (como en una fuente RSS) tienen una base bien definida, tiene sentido encontrar un objeto base que encapsule la base bien definida, pero también tiene algún tipo de mapa hash para su libertad.

Tan pronto como descubra que cada vez más pares clave-valor resultan ser "estándar", simplemente actualice su modelo de objetos para encapsularlos: su software evolucionará a la estructura de datos correcta. Puede tener sentido mover algunos de los datos a un RMDBS tradicional en un momento posterior.

No más de ingeniero - implementar las características cuando sea necesario ...

Answer 3

Yo diría que la mejor práctica para un archivo XML sin esquema es crear un esquema para él!

Tener un esquema no es particularmente agradable. Significa que no puede validar el archivo de ninguna manera, salvo para detectar si está bien formado XML o no.

No tiene semántica para el archivo que parece sospechoso. Porque eso significaría que no sabes lo que deberías, hiciste o pondrás en ello. Si ese es el caso, suena sospechosamente como una solución en busca de un problema.

Si no tiene un esquema porque aún no conoce un lenguaje de esquema, eche un vistazo a DTD. Es muy simple. Puede aprender y dominarlo en aproximadamente una o dos horas, si tiene una utilidad de validación o valida el analizador en su aplicación.

Si el problema que le impide tener un esquema es que sus reglas de esquema no parecen ajustarse a los tipos de archivo de definición de esquema que ha examinado hasta ahora, no tema.

Aunque los archivos DTD e incluso XSD (Esquema XML) son algo inflexibles, existen otros tipos de archivo de esquema más flexibles. Son mucho más simples que XSD también, confía en mí.

Eche un vistazo a la especificación del archivo de esquema RNC (RELAX NG, compacto). Los archivos RNC son muy fáciles de leer y escribir para los humanos. Hay algunos editores de XML que los entienden. Hay utilidades que se convertirán entre formatos RELAX NG (RNG o RNC) y otros formatos como DTD y XSD.

La última vez que verifiqué, el XHTML TR incluyó un archivo RNC no normativo para ayudar a validarlo, sin mencionar documentarlo sin ambigüedades. RELAX NG tiene la flexibilidad para hacer eso, y usted puede leerlo sin ser parte del colectivo Borg. En este caso, Borg no es un eufemismo de Microsoft.

Si necesita algo aún más flexible que RELAX NG, eche un vistazo a Schematron. Es un lenguaje de validación de esquema basado en reglas muy agradable. No es muy complejo. Al igual que estos otros lenguajes de esquema, también ha existido por mucho tiempo, es maduro y es un estándar reconocido.

Incluso algunos ingenieros superiores de Microsoft tenían dudas sobre XSD. La complejidad es alta, resulta imposible expresar ciertos arreglos de datos no tan extraños, es muy detallado, mezcla preocupaciones tales como validación y valores predeterminados, y así sucesivamente. Lo que sea que estés haciendo, no parece muy adecuado para apoyarlo directamente.

Los correladores RDF, al igual que las herramientas de enlace XSD, son adecuados para objetos persistentes, dadas sus clases en algún lenguaje de programación compatible como Java (por ejemplo, con JAXB). Sin embargo, no está claro que tengas algunas clases en las que quieras persistir.

Existen algunas tecnologías de web semántica como OWL y RDF que son flexibles y muy dinámicas.

Una herramienta que tal vez desee consultar es Stanford's Protege. Es bastante poderoso y muy flexible. Básicamente es un IDE web semántico y un framework. Este último está escrito en Java, como es la herramienta. Sin embargo, el esquema de la web semántica y los archivos de datos creados y editados por Protege podrían ser utilizados por programas escritos en cualquier idioma. No hay ningún sesgo hacia Java en dichos archivos.

Además, puede encontrar muchos esquemas de web semántica usando Swoogle. Puede que ya exista un esquema que se adapte a tu aplicación.

Básicamente, crear un archivo de esquema en uno de estos muchos lenguajes de validación de esquemas no es muy difícil una vez que sepa qué desea colocar en su archivo de datos XML. Si no tiene idea, entonces es poco probable que un programa o una persona vaya a saber qué hacer con él cuando lo lean. Si ese es el caso, XML podría no ser la mejor representación de almacenamiento. No estoy seguro de que algo sea así.

En su lugar, es posible que simplemente desee hacer lo que esté haciendo con un lenguaje de scripting de escritura dinámica como Python o Ruby. LISP también podría usarse si desea que sus programas no solo tengan formatos de datos ilimitados sino que también puedan modificarse ellos mismos.

Otra opción para el almacenamiento de datos sin esquema es un lenguaje de programación lógica. Estos generalmente no tienen ningún esquema. Tienen un ontology en su lugar.

Dos lenguajes de programación con los que he trabajado mucho y que usan ontologías son CLIPS y Prolog. Existen implementaciones gratuitas, de código abierto y multiplataforma de ambas disponibles.

Eche un vistazo a SWI-Prolog; rápido, simple y poderoso. Puede definir hechos en él, y reglas que básicamente sintetizan hechos apropiados cuando sea necesario. Saca los datos con consultas. Prolog fue en realidad una inspiración para RDF cuando se creó, en la década de 1990, según recuerdo. La documentación original de RDF utilizada para hacer referencias frecuentes a Prolog. Si desea "descubrir", "analizar" o "encontrar" cosas sobre hechos en su ontología, Prolog es un lenguaje muy bueno para escribir dichas aplicaciones. También es útil para el análisis de lenguaje natural.

CLIPS es bueno también, si está buscando resolver problemas sobre los hechos en su ontología. Es adecuado para organizar, solucionar problemas y aplicaciones relacionadas con la configuración.

Si los esquemas no son lo tuyo, tal vez sean las ontologías. De lo contrario, tal vez debería usar un lenguaje de scripting de tipo dinámico y conservar datos almacenados en objetos complejos usando mapas y listas en archivos usando sus mecanismos de persistencia estándar.

Answer 4

Utilice MongoDB u otras bases de datos nosql. También vea este blog en, Why I think Mongo is to Databases what Rails was to Framework.