スキーマとは何か？

Scrapeless Web Unlocker は、アプリケーションが明示的なデータスキーマに従うレコードへと変換できる Web コンテンツを取得します。

スキーマとは何か？

スキーマとは、データがどのように構造化されているかと、その構造が満たさなければならないルールについての記述です。フィールド名、データ型、必須値、リレーションシップ、制約などを定義できます。この語にはいくつか関連する意味があります。データベーススキーマはテーブルやキーを記述し、API スキーマはやり取りされるメッセージを記述し、名前付き SQL スキーマはデータベースオブジェクトのための名前空間を提供します。

重要なのは、スキーマがどのような契約を確立するかという点です。あるプロダクト観測は、ソース識別子と観測時刻を必須とし、価格の欠損を許容し、金額が存在する場合は通貨を必須とするかもしれません。その契約によって、生産者と消費者はレコードの共通の解釈を持ちます。そうした意味を伴わないフィールド一覧は、仕様の一部にすぎません。

区別すべきスキーマの意味はどれか？

スキーマは、概念データモデル、論理的なレコード契約、物理的なデータベース構造、またはオブジェクト名前空間を指すことがあります。概念モデルは、あるプロダクトが複数のオファーを持ち得ることを示します。論理スキーマは、それらのオファーを表現するために使われるフィールドとリレーションシップを定義します。物理設計は、実際のテーブル、型、インデックスを選択します。

SQL の名前空間は、より狭い意味です。 PostgreSQL における名前付きスキーマの説明 は、スキーマがどのようにデータベース内でデータベースオブジェクトを整理するかを説明しています。そのような名前空間を作成しても、それだけでは中に含まれる各テーブルのビジネス上の意味は定義されません。

API メッセージスキーマは、呼び出し側が送受信する内容を記述します。JSON Schema は、JSON の構造と制約を指定するための言語の 1 つです。API 契約には、認証要件、ページネーションの挙動、エラーの意味、互換性ルールなども必要になる場合があります。これらの関心事は、個々のメッセージの形状を超えたものです。

検索用構造化データも、この用語の別の用途です。ページを語彙で記述しても、アプリケーションのデータベーススキーマの代わりにはなりません。設計ドキュメントに単に「the schema」とだけ書かれているときは、想定している対象読者と検証境界を常に明確にしておきましょう。

有用なレコード契約は何を定義すべきか？

有用なレコード契約は、識別子、型、存在ルール、単位、リレーションシップ、および意図された意味を定義します。まずレコードの粒度から始めましょう。1 行が表すのは、プロダクトなのか、オファーなのか、特定時点でのプロダクト観測なのか。これらの粒度は、タイトルや価格といったフィールドを共有していても、異なるキーを必要とします。

型は見た目ではなくドメインに従うべきです。数字から成るプロダクト識別子でも、先頭のゼロが意味を持ち、算術演算に意味がないのであれば、文字列のままである必要があります。金額は、精度ポリシーと通貨コンテキストを必要とします。タイムスタンプは、解釈の定義とタイムゾーンポリシーを必要とします。

存在ルールも同様に重要です。 オブジェクトプロパティに関する JSON Schema のルール は、スキーマで記述されているプロパティと、出現が必須とされているプロパティを区別しています。プロパティの型を宣言しても、そのプロパティが自動的に必須になるわけではありません。

追加フィールドを受け入れるかどうかを記述してください。厳格なリーダーは未知のプロパティを拒否するかもしれません。寛容なリーダーはそれらを保持するか無視するかもしれません。どちらの挙動も、ペイロードが JSON であるという事実から自動的に仮定すべきではありません。これらの決定を契約に記録し、代表的な入力で検証しましょう。

欠損値、null、空値はどう異なるか？

欠落しているプロパティはレコードに存在せず、null のプロパティはレコードに存在して値が null であり、空文字列は文字が 1 つもないが存在している文字列です。これらのビジネス上の意味は契約によって異なります。ソース記述においては、欠落しているとは抽出器がフィールドを見つけられなかったことを意味する場合があり、null とはソースが明示的に値がないと報告していることを意味する場合があり、空文字列は許可されない場合があります。

The JSON データ交換仕様 は、null、文字列、数値、オブジェクト、および配列を区別された JSON 値として定義します。これは、欠落した価格や空のタイトルに対するアプリケーション固有のビジネス上の意味を割り当てるものではありません。その解釈はレコード契約の範囲です。

数値列を満たすためだけに、未知の数値を 0 に置き換えないでください。0 は 1 つの値であり、合計値、フィルター、およびアラートに影響を与え得ます。明示的な不在状態を保持し、必要に応じてソースの欠落や抽出の不確実性など、その理由も保持してください。

空白とロケールについても判断が必要です。表示される金額には通貨記号やロケール固有の小数点記号が含まれる場合があります。ソースを意識したルールを使って正規化し、その解釈を説明するのに十分な、許容された証拠を保持してください。

スクレイピングしたデータにスキーマをどのように適用しますか?

スキーマは、ソースレコードを特定した後、正規化された出力を利用者に公開する前に適用します。例としてのカタログワークフローでは、承認済みページを収集し、それが目的のカタログを含んでいることを確認し、候補となる掲載情報を抽出し、各フィールドを合意された観測契約にマッピングします。そのうえで検証によって正規化された候補が評価されます。

Scrapeless Web Unlocker はページコンテンツを提供できます。 Web Unlocker collection request は、出力スキーマとは別の契約です。収集レスポンスが正しく構成されていても、抽出された商品レコードが正しい金額や識別情報を含むことは保証されません。

パースエラーとソースの不在を区別し続けてください。商品ページに価格が存在するにもかかわらずセレクタがそれを見つけられない場合、金額をソース由来の null としてマークすると証拠を誤って伝えることになります。候補は、受け入れ済みデータセットに入れることなく未解決のままにしておくことができます。この区別によって、後のパーサ修正を理解しやすくなります。

The スクレイピングしたレコードから分析用テーブルへの変換 は、なぜストレージ境界で型付き出力が重要なのかを示しています。スキーマは、配列、繰り返されるオファー、ネストされたバリアントを、個々の利用者に任せて独自にフラット化させるのではなく、どのようにリレーショナルな行に変換するかも記述すべきです。

Schema-on-Write や Schema-on-Read とは何を意味しますか?

Schema-on-write は、ストレージへの受け入れ前または受け入れ中に構造的な解釈を適用し、Schema-on-read はデータが読み出されるときに解釈を適用します。この違いは、いつルールが強制されるかに関するものです。一方のシステムには意味があり、もう一方には構造がないという意味ではありません。

早期の検証によって、下流のクエリが対象レコードを目にする前に、非互換なレコードを捕捉できます。また、契約が更新されるまで新しいソースフィールドを拒否することも可能です。後から解釈する方式は柔軟性を保ちますが、異なるパースルールを適用した際に読者同士で意見が分かれる可能性があるなど、責任を読み手側に移します。

多くのワークフローは両方のアプローチを組み合わせています。ランディングレイヤーでは、最小限のメタデータとともに承認済みの生データ表現を保持し、一方でキュレートされたテーブルは安定したビジネススキーマを強制します。生データの保持には、それ独自のアクセス制御と削除制御が必要です。柔軟性があるからといって、すべてのソースレスポンスを永遠に保持してよい理由にはなりません。

スキーマはどのように安全に進化させられますか?

スキーマの進化が安全かどうかは、互換性を保たなければならないリーダーとライターとの関係に対してのみ語ることができます。任意フィールドの追加は、未知のプロパティを許容するリーダーでは機能する一方で、未知のプロパティを拒否するリーダーでは失敗する可能性があります。数値を文字列に変更すると、表示される値が変わらないように見えても計算処理を壊すことがあります。

意味的な変更は特に見落としやすいものです。price というフィールドは、当初はメインオファーの金額を意味していたのに、後に最安分割払い額を意味するようになるかもしれません。型は数値のままですが、利用者側の解釈は破綻します。意味が変わるときは、その概念に別名を付けるかバージョン付けを行い、移行パスを公開してください。

プロデューサーとコンシューマーの期待値を一緒にテストしてください。代表的な受け入れレコード、不在ケース、拒否されたケースを保持します。後方互換性を約束する場合は、旧リーダーを新しい出力に対して評価します。古い契約をいつ廃止できるか、そして移行の責任者が誰かを定義してください。

表形式の交換においては W3C の表形式データおよびメタデータのモデル が、列アノテーション、キー、および検証の概念を記述しています。これらはツールをまたいで契約を文書化するのに役立ちますが、ビジネス上の定義について合意する必要性をなくしてくれるわけではありません。

結論

1 件のレコードが何を意味するかを書き出し、そのうえで構造と不在状態を定義してください。公開境界で検証を行い、意味の変更を契約変更として扱います。収集部分を計画するときは、 Scrapeless pricing を自前の検証コストおよびストレージコストと併せて検討してください。