カーディナリティ（多重度）とは？かーでぃなりてぃ
カーディナリティ（多重度）とは、関連に参加するインスタンス数の上限と下限の組。上限側が1対1／1対多／多対多を、下限側が0か1かで参加の任意・必須を表し、UMLでは0..1や1..*のように書く。業務ルールをどこまでモデルで縛り、どこからアプリの入力検証へ回すかの分かれ目になる。
最終更新：2026-10-06
この語が出る過去問を解く →背景
「1件の受注に担当者は必ず1人か、未割当もありうるか」は、聞かなければ設計者には分からない業務側の取り決めで、口頭合意のままだと実装者ごとに解釈がぶれる。多重度は、その取り決めをモデル上の1か所だけに書き、外部キーのNOT NULL・一意制約・交差エンティティの要否へ機械的に落とすための記法として使う。試験では、モデルから実装上の制約を導けるかが問われる。
具体例
Redmineのようなチケット管理では「チケットは必ず1つのプロジェクトに属する」ため project_id はNOT NULL、「担当者は未割当がありうる」ため assigned_to_id はNULL許容になる。「1件のチケットに複数のウォッチャー」は多対多なので、交差表を1枚起こす。
試験での引っ掛け
多いか少ないかの目安ではなく上下限の組で、0..*と1..*はどちらも「多」だが、下限の違いがNULL許容と必須入力の設計を分ける。UMLのクラス図では相手側の個数を関連線の向こう端に書く（自分のクラス側に書く誤りが多い）。多対多はそのままでは表に落とせない。
関連用語
出た過去問
出典：平成29年度 秋期 システムアーキテクト試験 午前Ⅱ 問3（IPA）
図は"顧客が商品を注文する"を表現したUMLのクラス図である。"顧客が複数の商品をまとめて注文する"を表現したクラス図はどれか。ここで、注文明細は注文に含まれる…
正解：顧客1―0..*注文。注文の側に黒ひし形（多重度1）を置き、注文明細（多重度1..*）をコンポジションで束ねる。注文明細0..*―1商品。
要点：一括注文は注文が明細1..*を束ねる構造で表す
複数商品をまとめて注文する構造は、注文が複数の注文明細を束ね、各注文明細が一つの商品に対応する形で表現する。したがって注文と注文明細はコンポジション（注文が全体、注文明細が部分）で、注文側の多重度が1、注文明細側が1..*になる。顧客と注文は1対0..*、注文明細と商品は0..*対1が正しい。この関係を全て満たすのはアである。
出典・参考
解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。