Aras Innovatorでは、ItemTypeを1つ作ると、その裏でSQL Serverのテーブルが1つできます。つまりItemTypeの設計は、そのままデータベース設計です。あとから直すのが最も高くつくのがここで、作り直しになった案件の原因をさかのぼると、たいてい最初の数時間の判断に戻ってきます。
この記事は、当社がAras開発メンバーを育てるときの3回目の内容から、設計に関わる部分をまとめたものです。Aras公式のマニュアルを読む前に、あるいは読みながら、頭の地図として使ってください。
1. Arasの世界では、すべてがItemです
最初に覚えることは1つだけです。ItemTypeが設計図、Itemがその実体。そしてItemType自身もまたItemです（「ItemType」というItemTypeのインスタンス）。画面からItemTypeを作る操作と、コードからItemTypeを作る操作が同じAPIの上にあるのは、このためです。
.NETの開発者であれば、次の対応で入ると早いです。
| Aras | .NETでいうと |
|---|---|
| ItemType | class の定義 |
| Property | field / property |
| Item | そのクラスのインスタンス（＝1行のレコード） |
| AML | クエリとDTOを兼ねたXML |
| Method | そのクラスに紐づくメソッド（C# または JavaScript） |
この対応が頭に入っていると、あとで出てくるAMLが「見たことのない独自言語」ではなく、「SELECTとINSERTとオブジェクトを1つのXMLで表したもの」に見えてきます。
2. Property と DataType — あとで効いてくる3つの判断
stringの長さは、最初に余裕を持たせる
string型には長さの指定が必要です。ここを詰めすぎると、あとで必ず当たります。日本語の品名や備考は、想定の倍を見ておいてください。運用が始まってから長さを縮める変更は、既存データの移行を伴います。広げるほうはまだしも、縮めるほうは事故になります。
item型は、外部キーそのもの
item型のPropertyは、別のItemTypeへの参照です。値として入るのは参照先のIDで、画面には参照先のkeyed_nameが表示されます。1件だけを指すならitem型、複数件を持つならRelationship。この線引きが最初の分かれ道です。
foreign型を使えば、Relationshipを張らずに他のItemの値が読める
ここが、実務でいちばん効きます。item型のPropertyでつながっているなら、foreign（Foreign Property）を定義することで、参照先のPropertyをそのまま自分のPropertyのように扱えます。一覧にもフォームにも出せますし、検索条件にも使えます。
一覧画面が重い、という相談を受けて中を見ると、foreignで足りるところをすべてRelationshipにしていた、という例が本当に多いです。
予約語に気をつける
Arasには、すべてのItemTypeが最初から持っているシステムPropertyがあります。次の名前は自分で作らないでください。
id config_id generation is_current is_released state keyed_name major_rev locked_by_id created_on created_by_id modified_on modified_by_id permission_id
特に state は、LifeCycleを使うときにArasが管理します。自分で同名のPropertyを作ると、あとでLifeCycleを入れる段階で詰みます。
3. Relationship — 「関係」もまたItemTypeです
RelationshipTypeは、source_id と related_id を持つ特別なItemTypeです。ここで大事なのは、関係そのものがPropertyを持てるということです。数量、順番、有効期間、備考。これらは関係側に置きます。
related_id を持たない形（null relationship）も作れます。この場合、そのRelationshipType自身が子データの入れ物になります。親に完全に従属し、単独では存在しない明細行は、この形が合います。
判断の順番は、こう整理すると迷いません。
| やりたいこと | 使うもの |
|---|---|
| 1件だけを指したい | item型のProperty |
| 参照先の値を表示・検索したいだけ | foreign型のProperty |
| 複数件をぶら下げたい | Relationship |
| 関係そのものに属性を持たせたい | Relationship（件数によらず） |
| 親なしでは存在しない明細 | related_idなしのRelationship |
4. Reverse Relationship — 逆から見たいときだけ
通常、親から子はたどれますが、子から「自分を参照している親の一覧」は見えません。Reverse Relationshipは、その逆方向を定義するものです。related側のフォームに、自分を指しているsourceの一覧を出せるようになります。
実際に使うのは、TreeGridViewやQuery Definitionで階層を組み立てるときです。そこは次の記事で扱います。
5. 現場で実際に起きた失敗
都合の悪い話も書いておきます。以下は、当社が実際にやった、あるいは引き継いだ案件で見た失敗です。
- 何でもRelationshipにして、一覧が重くなった。 表示したいだけの項目は、foreign Propertyで足りました。作り直しではなく、Property追加とビュー修正で解決しています。
- string(32)で切ったら、日本語の品名が入らなかった。 英数字の想定のまま定義していました。運用開始後だったため、移行作業が発生しています。
- データが入ってからバージョン管理を有効にした。 既存データの世代が揃わず、あとから整合を取る作業が必要になりました。バージョン管理の要否は、最初に決めてください。
- Permissionを最後に設計した。 ItemTypeとRelationshipをすべて作り終えてから権限を考え始め、結果としてItemTypeの分割からやり直しになりました。権限の単位は、データ構造の設計と同時に決めるものです。
共通しているのは、どれもコードの問題ではないということです。設計の失敗は、あとからコードでは取り戻せません。