HiRDBのデータベースはリレーショナルデータベースです。その論理構造である表をどのように設計するかを検討します。

まず，表を正規化しておくことが必要です。ただし，同じように正規化した表であっても，ユーザ用RDエリアへの格納の仕方などによって，表に対する処理性能が異なります。また，処理性能よりも操作性を重視する場合もあるため，期待する効果を考慮した表の設計が必要になります。表を設計するときの検討項目を次の表に示します。

表13-1　データベースの表を設計するときの検討項目

設計作業ごとの検討項目		長所	短所	記載箇所
表の正規化		表の格納効率や処理効率が向上します。	表の検索時に，正規化後の表同士の結合検索が必要になる場合は，処理性能が落ちることがあります。	13.2
表の横分割	表の横分割の指定	RDエリアごとの運用ができます。 HiRDB/パラレルサーバの場合は，表にアクセスする処理を複数のRDエリアにわたって並列化できるため，表に対するアクセスの高速化及び負荷の分散が図れます。	RDエリアの数が増えます。 この表に作成するインデクスを横分割しないと，インデクスでの排他制御によって，同時実行性が低下することがあります。	13.3
	キーレンジ分割	表のデータをどのRDエリアに格納したかが分かります。 各業務に関連する部分のデータを別々のRDエリアにまとめて格納し，RDエリアごとの運用ができます。	キーレンジを意識しないと，RDエリアに均等に格納できません。
	フレキシブルハッシュ分割※	キーレンジを意識しなくても，データを均等にRDエリアに格納できます。 RDエリア，ハッシュ関数を変更しやすくなります。 CPU，ディスクの追加に対応できます。	表のデータをどのRDエリアに格納したかが分かりません。 特定のキーに偏りや重複があるとデータが均等に格納できません。 キーの一意性のチェックができません。
	FIXハッシュ分割※	キー値によって,データを格納するRDエリアが一意に決定されます。 キーレンジを意識しなくても，データを均等にRDエリアに格納できます。 CPU，ディスクを追加しやすくなります。 表分割ハッシュ関数を使用したUAPを作成し，入力データをRDエリアごとに格納できます。	表にデータが格納されているとユーザ用RDエリアの追加及びハッシュ関数の変更ができません。
表のマトリクス分割		キーレンジ分割したデータを，さらに別の列値で分割できるため，通常のキーレンジ分割よりも，SQLの高速処理，運用時間の短縮が期待できます。 キーレンジ分割とハッシュ分割の組み合わせで分割できるため，適用業務の幅が広がります。	通常の横分割に比べ，RDエリアを更に細分化できるため，運用や管理が複雑になります。	13.4
トリガの定義		ある表への操作を契機として，自動的にSQL文を実行するようにできます。	特にありません。	13.5
ビュー表の作成		ほかのユーザに実表のアクセス権限を与えないで，ビュー表だけのアクセス権限を与えると，アクセス可能な実表の範囲を行又は列単位で制限できます。 複雑な問い合わせ指定をした場合に検索できるデータであらかじめビュー表を作成すると，表を参照する操作が手軽になります。 ビュー表を通して実表を参照又は更新できます。 ビュー表を通して外部表を参照，更新できます。	特にありません。	13.6
FIX属性の指定		行単位インタフェースを使用する場合は列数が多くてもアクセス性能を向上できます。 FIX属性の表に対する入力データにナル値を許さないように制約できます。 列数の多い表の場合はディスク所要量を削減できます。	特にありません。	13.7
主キー（プライマリキー）の指定		主キーを定義した列には，一意性制約と非ナル値制約が適用されます。	特にありません。	13.8
クラスタキーの指定		範囲を指定した行の検索，更新，削除などをするときやクラスタキー順の検索，更新などをするときに入出力時間を削減できます。 クラスタキーにUNIQUEを指定すると，クラスタキーの構成列の値がすべての行で重複しないように制約できます。 表を作成するときの入力データがクラスタキーの昇順又は降順に並んでいるかどうかをデータベース作成ユティリティ（pdload）で確認できます。 表を再編成するときに，アンロードした行のクラスタキーと，リロードするクラスタキーが一致しているかどうかをデータベース再編成ユティリティ（pdrorg）で確認できます。	クラスタキーを構成する列の値を更新できません。 クラスタキーを構成する列の値にナル値を挿入できません。 クラスタキーを指定した表にデータを追加するとき，追加しようとするキー値に近接するキー値を持ったページを探すためのオーバヘッドが発生します。	13.9
サプレスオプションの指定		ディスク所要量を削減できます。 全件検索などの検索処理での入出力時間を削減できます。	特にありません。	13.10
ノースプリットオプションの指定		データの格納効率を向上できるため，ディスク所要量を削減できます。	特にありません。	13.11
バイナリデータ列の指定		文書，画像，音声などの可変長データを指定できます。	特にありません。	13.12
文字集合の指定		表の列ごとに異なる文字集合の文字列データを格納できます。これによって，次のことができます。 VOS3システムからHiRDBに移行した場合に，データベースに格納していた文字データをVOS3システムの文字列データの照合順で検索，代入，比較ができます。 UTF-16で文字データの検索，代入，比較ができます。	特にありません。	13.13
WITHOUT ROLLBACKオプションの指定		採番業務で使用する表を定義する場合，表に対する更新処理完了を契機に更新行に対する排他が解除されるため，排他待ちの発生を削減できます。	特にありません。	13.14
改竄防止機能の指定		表データを誤って，又は不当に更新されることを防止できます。	改竄防止表があるRDエリアに対して使用できない機能や，SQL，ユティリティ，コマンドの実行に制限があります。	13.15
繰返し列を含む表		複数の表の結合が不要になります。 重複する情報がなくなるため，ディスク容量を削減できます。 関連データ（繰返しデータ）が近くに格納されるため，別の表にするよりもアクセス性能が優れています。	特にありません。	13.16
抽象データ型を含む表		複雑な構造のデータを表に格納して，通常の表データと同様に操作できます。	特にありません。	13.17
共用表		複数バックエンドサーバ間の接続やデータ転送によるオーバヘッドが削減できます。 トランザクションの多重実行時など，並列処理の効率が上がります。	共用表を更新する場合，全バックエンドサーバで，更新する共用表があるRDエリアに排他を掛けるので，共用RDエリアのほかの表にアクセスする業務があると，デッドロックが発生することがあります。	13.18
参照制約		複数の表間のデータの整合性チェック，及びデータ操作を自動化できます。	被参照表や参照表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加します。	13.19
検査制約		データの追加又は更新時のチェックを自動化できます。	検査制約が定義された表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加します。	13.20

注※

次に示す場合は，ハッシュ分割表のリバランス機能を使用することをお勧めします。

• 表をハッシュ分割する場合
• データ量の増加が見込まれる場合

ハッシュ分割表のデータ量が増加したためRDエリアを追加すると（表の横分割数を増やすと），既存のRDエリアと新規追加したRDエリアとの間でデータ量の偏りが生じます。ハッシュ分割表のリバランス機能を使用すると，表の横分割数を増やすときにデータ量の偏りを修正できます。ハッシュ分割表のリバランス機能については，マニュアル「HiRDB Version 8 システム運用ガイド」を参照してください。