制約の使い方、Unicode使用可否、明細テーブルの設計

論理モデル上だけリレーションを引く

   図2と図3は、前回使ったSQL ServerのNorthwindデータベースをER図にリバースした物理モデルと論理モデルです。

   物理モデルには、実データベースの情報がそのまま表示されます。エンティティ間のリレーション（実線：依存型、破線：非依存型）が参照整合性制約に相当しますので、図2を見るとこのデータベースには参照整合性制約が張られていることがわかります。



   リレーションの線にも物理モデルと論理モデルがあります。そのため、参照整合性制約を使わない方針にした場合でも、わかりやすいER図を作成できます。物理モデル表示では箱（エンティティ）が並ぶだけの表示になりますが、論理モデル表示でエンティティ間のリレーションを設定できるのです。

Unicodeを使うか

   図2や図3のエンティティの中（アトリビュート）を見ると、文字列のデータ型がvarcharではなくnvarcharが使われていることに気づきます。頭のnは、National LanguageのNのことで、各国語文字、すなわちUnicode形式で文字列を格納することを示しています。

   皆さんはvarcharとnvarcharのどちらを使用していますか?

   多分、ほとんどの人はvarchar、つまりS-JISなどの日本独自コードを使っていると思います。その理由を一言でいえば「Unicodeを使う理由がない」というものでしょうか。

   確かにUnicodeは1文字に3バイト（UTF-8の場合）も使用しますし、Unicode非対応の外部システムとの連携にも困ります。英語と日本語以外の文字を格納しないのであれば、わざわざUnicodeを使う必要がないと考えるのも無理ありません。

   筆者はといえば、実は比較的Unicodeを使っています。これまた絶対的な理由があるわけではありません。なぜかと聞かれれば、以下の3点を理由にあげます。



   この時注意して欲しいのは、Oracleでは通常データベースのキャラクタセットでAL32UTF8などのUnicode指定を行います。つまりキャラクタセットでUnicodeを指定していれば、個々のデータ型でvarcharを選択していてもUnicodeとなります。

   逆にいえば、データ型でnvarcharを明示的に指定するのは、キャラクタセットと異なっていてもUnicodeにする場合ということになります。