orm - スキーマレス データにアクセスするためのベスト プラクティスは?

Question

私は RDF をいじっています。特に、rdf ストレージに格納されている情報にアクセスする方法を考えています。従来のリレーショナル データベースとの大きな違いは、事前定義されたスキーマがないことです。リレーショナル データベースでは、テーブルにそれらの列があることがわかっており、技術的に各行をクラスのインスタンスにマップできます。このクラスには、明確に定義されたメソッドと、明確に定義された属性があります。

スキーマのないシステムでは、特定の情報にどのデータが関連付けられているかわかりません。これは、事前定義されていない任意の数の列を持つデータベース テーブルを持つようなものであり、すべての行はこれらの列の任意の数にデータを持つことができます。

ObjectRelational マッパーと同様に、オブジェクト RDF マッパーがあります。RDFAlchemy と SuRF は、私が現在プレイしている 2 つです。基本的に、それらは Resource オブジェクトを提供し、そのメソッドと属性は動的に提供されます。それは理にかなっています...しかし、それはそれほど簡単ではありません。多くの場合、適切に定義されたインターフェイスを持ち、モデル オブジェクトでデータを設定および取得するときに何が起こっているかをより詳細に制御することを好みます。このような一般的なアクセス権を持つことは、ある意味で物事を困難にします。

私が指摘したもう 1 つの (そして最も重要な) ことは、たとえ一般的に 、スキーマのないデータは、リソースに関する任意の情報を提供することが期待されています。実際には、一緒になる傾向がある「情報のクラス」を多かれ少なかれ知っています。もちろん、追加情報の存在を排除することはできませんが、これは場合によっては標準ではなく例外ですが、例外は厳密なスキーマにとっては混乱を招くほど十分に賢明ですが. 記事の rdf 表現 (たとえば、RSS/ATOM フィードなど) では、記述されたリソースの用語を知っており、それらを明確に定義されたオブジェクトにマップできます。追加情報を提供する場合は、拡張オブジェクト (基本オブジェクトから継承) を定義して、拡張情報へのアクセサーを提供できます。したがって、ある意味では、拡張可能な「スキーマ指向オブジェクト」を使用して、スキーマのないデータを処理します。関心のある特定の追加情報を見たい場合。

私の質問は、スキーマレス データ ストレージの実際の使用方法に関するあなたの経験に関連しています。それらをオブジェクト指向の世界にどのようにマッピングして、スキーマレス ストレージの「ベア メタル」に近づきすぎずに上手に使用できるようにするのでしょうか? (RelDB 用語では、あまり SQL を使用せず、テーブル構造を直接いじることはありません)

アクセスは非常に一般的なものになる運命にあるのでしょうか (たとえば、SuRF の「プラグイン属性」は、データにアクセスするために必要な最高の、最も特殊化されたレベルです)、または合意された特定の便利なスキーマに特化したクラスを持つことも良いアプローチですが、新しい予期しない関連データにアクセスするためのクラスが急増するリスクはありますか?

Answer 1

私の短い答えは「しない」だと思います。私は少し白ひげを生やしており、XML データをリレーショナル データベースにマッピングする作業を数多く行ってきました。そのようなデータベースを使用することにした場合は、データを常に検証する必要があります。また、共通性がほとんどないデータベースを避けるために、非常に厳格な規律が必要になります。ほとんどの XML スキーマはオブジェクト指向であり、したがって拡張可能であるため、スキーマを使用すると、データベースにアクセスする必要がある人があなたについて悪い考えを抱く原因となる、似ていない名前の類似したデータを作成しないようにするための分析の必要性が軽減されます。

私の個人的な経験では、ネットワーク化されたデータベースが理にかなっているようなことをしているなら、それを選んでください。そうしないと、整合性チェック、トランザクション、セットの選択など、リレーショナル データベースが実行できる他のすべての機能が失われます。しかし、とにかくほとんどの人がリレーショナル データベースをオブジェクト ストアとして使用しているため、その点は議論の余地があると思います。

そのデータにアクセスする方法については、Hashtable に入れるだけです。真剣に。どこにもスキーマがなければ、そこに何があるかわかりません。スキーマがある場合は、それを使用してアクセサー オブジェクトを生成できますが、DAO (データ アクセス オブジェクト) の柔軟性を失うと同時に、基になるストアのすべての柔軟性が失われるため、得られるものはほとんどありません。

たとえば、Hashtable がある場合、XML パーサーから値を取得するのはたいてい簡単です。使用するストレージ タイプを定義してから、XML ツリーをたどってストレージ タイプに値を入力し、必要に応じて Hashtable または List のいずれかにタイプを格納します。ただし、DAO を使用すると、XML の長所の 1 つであるデータ オブジェクトを自明に拡張できなくなり、拡張を行うオブジェクトのゲッターとセッターを作成する必要があります。

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());
    }
}

もちろん、サブレイヤーのローダーと定義を含む、そのスキーマレイヤーのすべての単一の値に対してそれを行う必要があります。そしてもちろん、コールバックを使用する高速なパーサーを使用すると、結果のツリーを生成するときに自分がどのオブジェクトにいるかを追跡する必要があるため、はるかに大きな混乱が発生します。

通常はバリデーターを作成し、次に XML とデータ クラスの一致を提供するアダプターを作成し、それをデータベースと照合するための調整プロセスを作成します。ただし、ほとんどすべてのコードが最終的に生成されます。DTD があれば、それにアクセスするためのほとんどの Java コードを生成でき、妥当なパフォーマンスでアクセスできます。

最終的には、フリーフォーム、ネットワーク化、または階層化されたデータを、フリーフォーム、ネットワーク化、または階層化されたデータとして保持するだけです。

Answer 2

スキーマのないXMLファイルのベストプラクティスは、そのスキーマを作成することです。

スキーマがないことは特に良いことではありません。これは、ファイルが整形式のXMLであるかどうかを検出する以外の方法で、ファイルを検証できないことを意味します。

ファイルにセマンティクスがないのは、怪しげなようです。それは、あなたが何をすべきか、何をしたか、または何を入れるかがわからないことを意味するからです。その場合、問題を探すための解決策のように疑わしく聞こえます。

スキーマ言語がまだわからないためにスキーマがない場合は、DTDを確認してください。とても簡単です。アプリケーションに検証ユーティリティまたは検証パーサーがある場合は、約1〜2時間で学習して習得できます。

スキーマの作成を妨げている問題が、スキーマルールがこれまでに確認したスキーマ定義ファイルの種類に適合していないように見えることである場合は、恐れることはありません。

DTDおよびXSD（XMLスキーマ）ファイルでさえ多少柔軟性がありませんが、他のより柔軟なスキーマファイルタイプがあります。それらもXSDよりもはるかに単純です。私を信じてください。

RNC（RELAX NG、コンパクト）スキーマファイルの仕様を確認してください。RNCファイルは、人間が読み書きするのが非常に簡単です。それらを理解するXMLエディタがいくつかあります。RELAX NG形式（RNGまたはRNC）とDTDやXSDなどの他の形式の間で相互に変換するユーティリティがあります。

前回チェックしたとき、XHTML TRには、それを明確に文書化することは言うまでもなく、検証に役立つ非規範的なRNCファイルが含まれていました。RELAX NGにはそれを行う柔軟性があり、ボーグの集合体に参加しなくても実際に読むことができます。この場合、Borgは婉曲表現のMicrosoftではありません。

RELAX NGよりもさらに柔軟なものが必要な場合は、Schematronをご覧ください。これは非常に優れたルールベースのスキーマ検証言語です。それほど複雑ではありません。これらの他のスキーマ言語と同様に、それも長い間使用されており、成熟しており、認識されている標準です。

Microsoftの一部の上級エンジニアでさえ、XSDについて深刻な不安を抱いていました。複雑さが高く、特定のそれほど奇妙ではないデータ配置を表現できないことが判明し、非常に冗長であり、検証やデフォルト値などの懸念が混在しています。あなたが何をしていても、それを直接サポートするのにはあまり適していません。

XSDバインディングツールのようなRDFマッパーは、Javaのようなサポートされているプログラミング言語（JAXBなど）でのクラスを考えると、オブジェクトの永続化に非常に適しています。ただし、そもそも永続化したいクラスがあるかどうかは明らかではありません。

OWLやRDFのように、柔軟性があり、非常に動的なセマンティックWebテクノロジーがいくつかあります。

あなたが見たいと思うかもしれない1つのツールはスタンフォードのProtegeです。それは非常に強力で非常に柔軟です。これは基本的にセマンティックWebIDEおよびフレームワークです。後者は、ツールと同様にJavaで記述されています。ただし、Protegeが作成および編集するセマンティックWebスキーマおよびデータファイルは、任意の言語で記述されたプログラムで使用できます。このようなファイルにはJavaへの偏見はありません。

また、 Swoogleを使用すると、多くのセマンティックWebスキーマを見つけることができます。アプリケーションが何であれ、それに適合するスキーマがすでに存在する可能性があります。

基本的に、XMLデータファイルに何を入れたいかがわかれば、これらの多くのスキーマ検証言語の1つでスキーマファイルを作成することはそれほど難しくありません。あなたが知らないなら、それはプログラムである可能性が低いか、人がそれを読んだときにそれをどうするかを知っているでしょう。その場合、XMLは最適なストレージ表現ではない可能性があります。何が起こるかわかりません。

代わりに、PythonやRubyなどの動的に型指定された汎用スクリプト言語で実行していることを単純に実行したい場合があります。プログラムが無制限のデータ形式を持つだけでなく、それ自体を変更できるようにしたい場合は、LISPを使用することもできます。

スキーマレスデータストレージのもう1つのオプションは、論理プログラミング言語です。これらには通常、スキーマがありません。代わりにオントロジーがあります。

オントロジーを使用するために私がよく使用した2つのプログラミング言語は、CLIPSとPrologです。無料のオープンソースのクロスプラットフォームの両方の実装が利用可能です。

SWI-Prologを見てください; 高速、シンプル、そしてパワフル。その中にファクトを定義し、必要に応じて基本的に適切なファクトを合成するルールを定義できます。クエリを使用してデータを引き出します。私が覚えているように、Prologは、1990年代に作成されたとき、実際にはRDFのインスピレーションでした。Prologを頻繁に参照するために使用された元のRDFドキュメント。オントロジーの事実について「発見」または「分析」または「発見」したい場合、Prologはそのようなアプリケーションを作成するための非常に優れた言語です。自然言語の構文解析にも便利です。

オントロジーの事実に基づいて問題解決を行う場合は、CLIPSも便利です。これは、アプリケーションの整理、トラブルシューティング、および構成に関連するアプリケーションに最適です。

スキーマがあなたのものではない場合、おそらくオントロジーはあなたのものです。そうでない場合は、動的に型付けされたスクリプト言語を使用し、マップとリストを使用して複雑なオブジェクトに格納されたデータを、標準の永続化メカニズムを使用してファイルに永続化する必要があります。

Answer 3

MongoDBまたは他のnosqlデータベースを使用します。このブログも参照してください。Mongoがデータベースに対して、Railsがフレームワークに対してであると考える理由。

Answer 4

スキーマレス DB と OOP を組み合わせた経験はありませんが、スキーマレス DB とスクリプトの経験は 1 年あります。私の経験から、それは非常に便利です。私が使用したDBも型指定されていません（すべて任意の文字列）。これにより、次の利点が得られます。

• DB 構造を気にする必要はありません。何かを保存する必要がある場合は、保存するだけです。また、スクリプト言語に適したデータ型を気にする必要はありません
• ほとんどのテーブル行に空の列を持たずに、必要に応じて「オブジェクト」にデバッグ情報を簡単に追加できます。これにより、必要な場所に大量のデータを保存することもできます。
• DB 構造の更新を気にする必要はありません。新しいソフトウェア バージョンに付属する新しいデータをデータベースに書き込むだけです。このように、管理者がテーブル構造を更新して古いデータを変換する必要はありません。それはその場で起こるだけです
• キーと値のペアのキーに意味のある名前が付いている場合、データのドキュメントはあまり必要ありません

したがって、私の場合、スクリプティングと組み合わせたスキーマレス DB は非常に有用であり、大きな成功を収めました。

スキーマレス DB にオブジェクトを使用することを考えると、オブジェクトをハッシュテーブルに格納することで自由度を維持しようとします。これにより、選択した「オブジェクト」に関係なく、すべてのキーと値のペアに自由にアクセスできます。また、必要に応じて新しいキー値を自由に追加できます。

オブジェクト (RSS フィードなど) が明確に定義されたベースを持っている場合、明確に定義されたベースをカプセル化するだけでなく、自由のためにある種のハッシュ マップを持つベース オブジェクトを考え出すことは理にかなっています。

ますます多くのキーと値のペアが「標準」であることが判明したらすぐに、オブジェクト モデルを更新してこれらをカプセル化します。ソフトウェアは適切なデータ構造に進化します。後で一部のデータを従来の RMDBS に移動することも理にかなっているかもしれません。

設計しすぎないでください - 必要に応じて機能を実装してください...