はじめに

構造化データとは http://schema.org/ にて定義されている、この世に存在する様々なデータを構造的に記述するためのものです。
単なる文字列としてではなく、名前や所在地、生年月日といった要素を予め指定されているフォーマットに合わせて記述することにより、検索エンジン等が的確に情報を収集することができます。

SEOのテクニックの一つという文脈で語られがちなこの構造化データですが、「パンくずリストを構造化データで記述して検索順位アップ♪」みたいな小手先のテクニックではなく、そもそものデータ設計の時点から構造化データを意識してモデリングを行うことにより、より美しい設計を行えるのではないかと考え、今回筆を執りました。

構造化データの構造

構造化データを理解する上で、知っておくべき項目がいくつかあります。

DataTypeとThing
要素と型
継承関係
包含関係

以下について順番に説明します。

DataTypeとThing

構造化データには大きく分けて2つの種類があります。

1つはDataType。
これは純然たるデータを記述するための型で、以下のようなものがあります。

Boolean
- True
- False
Date
DateTime
Number
- Float
- Integer
Text
- CssSelectorType
- PronounceableText
- URL
- XPathType
Time

名称はそれぞれ異なるにしても、多くのプログラミング言語で導入されている型そのものですね。
これらのDataTypeの特徴としては、「中にこれ以上要素がない」という点です。
「人」であれば「名前」があり、「生年月日」があり、「性別」がありと様々な要素を持ってますが、「単なる数字」や「単なる文字列」にはそれ以上要素がないということです。

逆に、「人」のような複数の要素を持つものをThing系と仮称します。

Thing系には以下のようなものが含まれます。

Action
CreativeWork
Event
Intangible
MedicalEntity
Organization
Person
Place
Product

細かくは次以降の項に書きます。

要素と型

次はThing系の型の例として、Person型を見てみましょう。
これは人を表す構造化データです。

全部書くとキリがないので、いくつかピックアップしますが、

name:Text 名前
birthDate:Date 生年月日
birthPlace:Place 場所
address:PostalAddress or Text 住所

他にも性別や身長、体重、受賞歴等々様々なものがあります。
今回はPerson型を紹介しましたが、製品なら製品、場所なら場所と、それぞれの型ごとにどういった要素が含まれているかが定義されています。

全部の型のリストは以下にあるので、膨大な型のリストから一番合うものを探すとよいかと思います。

構造化データを参考にDBのテーブル設計を考えることにより、

そもそもこのデータはどの種類だ？
その場合、このデータに必要な要素は何だ？
それぞれのデータの型は何だ？

といったような部分で抜け漏れや誤りを防ぐ効果があると思います。
また、カラムの名前を付ける際にも役に立つでしょう。

継承関係

構造化データを理解する上で大事なのが継承関係です。
例として、店を表現した構造化データのStoreTypeを見てみます。

Storeは以下のTypeを継承してます。

Thing > Organization > LocalBusiness > Store
Thing > Place > LocalBusiness > Store

Storeの要素を見ると、たとえば以下のような要素があります。

name
address
openingHours

nameはThing型を、addressはOrganization型やPlace型を、openingHours型はLocalBusiness型を継承した時に付加された要素になります。

また、Storeにはさらに子タイプとして以下のようなものがあります。

AutoPartsStore
BikeStore
BookStore
ClothingStore
ComputerStore

and more...

このように、構造化データにはThing型を起点として継承関係が存在し、継承したものの要素を付加していくという特徴があります。
これにより、「場所なのかお店なのか本屋なのか」など、抽象度の上げ下げや、それぞれに含まれる要素の絞り込みが容易になります。

関連

構造化データの中には、他のものを含んだり、含まれたり、紐付けたりするための型が存在します。
作品を表す型の群で見てみましょう。

https://schema.org/TVSeries
https://schema.org/TVSeason
https://schema.org/Episode

TVSeriesには「containsSeason」や「episode」、
TVSeasonには「partOfSeries」や「episode」、
Episodeには「partOfSeries」や「partOfSeason」

という要素があり、これにより

TVSeries ∈ TVSeason
TVSeries ∈ Episode
TVSeson ∈ Episode

という関連が表現できます。

具体例を挙げるのであれば、

TVSeriesは「ドラゴンボール(アニメ)」
TVSeasonは「ドラゴンボール(無印)」「ドラゴンボールZ」「ドラゴンボールGT」
Episodeは「＃95 ついに変身！！伝説の超サイヤ人･孫悟空」

みたいな感じで、「ドラゴンボールのアニメの中のドラゴンボールZ、そのうちの95話の超サイヤ人変身回」みたいなものを表現することができるわけです。

このように構造化データを参照することで、

「アニメ作品のデータ」「クールごとのデータ」「各話データ」のようなデータのレイヤー分割をどうするのか
1対1なのか1対多なのか多対多なのか
テーブルに分割して関連を定義するべき項目なのか、単なる文字列などで格納して良い項目なのか

など、データベースのテーブルの分け方や関連の付け方に指針ができます。

まとめ

以上、構造化データとモデリングの関連について書きました。

構造化データを参照することにより

そもそも今から作ろうとしているものはどんな型なのか(人なのか店なのか製品なのか)
この型の場合、どのような要素が含まれているのか
それぞれの要素はどのような型なのか
カラムの名付けをどうするか
データをどれぐらいの抽象度で定義すればいいのか
データをテーブルに分割する際にどういったレイヤーで分割するか
データ同士の親子関係や関連をどのように定義するか

などにある程度の指針を設けることができると思います。

また、副次効果として、そもそも構造化データを参考にしてデータベースを定義している以上、構造化データをWebサイト上にほとんど変更せずに公開することができるため、SEO等にも効果を発揮できると思います。

構造化データを元にしたデータモデリング、ぜひお試しください！