カーディナリティとは？2つの意味とインデックス設計・ER図での使い方を解説

データベース設計のレビューで「このカラムはカーディナリティが低いからインデックスは効かない」と指摘された。別の場面では「ここのカーディナリティは1対多です」と説明された。同じ言葉なのに、指している内容が違うように聞こえる。

実際、カーディナリティという言葉はデータベースの文脈で2つの意味で使われます。1つは列に含まれる値の種類の多さ、もう1つはテーブル間の関係の多重度です。どちらの話をしているのかが共有されていないと、議論が噛み合いません。

本記事では、2つの意味の違いから、インデックス設計との関係、実際の確認方法、ER図での使い方、そして設計でつまずきやすい点までを順番に整理します。

確認したいポイント	結論	詳細
カーディナリティとは？	文脈で2つの意味がある	列に含まれる値の種類の多さを指す場合と、テーブル間の関係の多重度を指す場合があります。
高い・低いとは？	一意な値が多いか少ないか	社員番号のように行ごとに異なれば高く、性別のように2種類しかなければ低くなります。
インデックスとの関係は？	高いほど効きやすい	絞り込める行数が少ないほど有効で、低い列では全件走査が選ばれることもあります。
ER図での意味は？	1対1・1対多・多対多	多重度とも訳されます。多対多はそのまま表現できないため中間テーブルに分解します。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• カーディナリティの2つの意味と、文脈による見分け方
• 列のカーディナリティが高い・低いとはどういう状態か
• インデックスの効きやすさとカーディナリティの関係
• 実際の値を確認する方法と、その値が推定であること
• ER図における1対1・1対多・多対多の扱い方

▼ システム開発やデータ活用の進め方を整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

カーディナリティとは何を指すのか

まず言葉の整理から始めます。同じ用語が2つの異なる概念を指すため、ここを押さえておかないと会話が成立しません。

この整理ができていないまま設計レビューに臨むと、指摘の意図を取り違えたまま修正することになります。まずは用語の前提をそろえてから議論に入ってください。

直訳は「要素の数」

カーディナリティは、直訳すると要素の数を意味します。もともとは数学で集合の要素の個数を表す概念で、そこからデータベースの分野に持ち込まれました。

この「数」が何を数えているのかによって、実務での意味が2つに分かれます。列の中の値を数えているのか、関係するレコードの数を数えているのかという違いです。

意味その1：列に含まれる値の種類の多さ

1つ目は、テーブルの列に含まれる一意な値の数を指す使い方です。性能の話をする場面では、ほぼこちらの意味になります。

例えば、性別の列には2種類の値しか入らないため、この列のカーディナリティは低いと表現されます。一方、社員番号のように行ごとに異なる値を持つ列は、カーディナリティが高いと言われます。

この意味でのカーディナリティは、インデックス設計やクエリの性能を検討する際の中心的な指標になります。

英語圏の資料でも同じ語が両方の意味で使われます。翻訳された記事を読むときも、どちらの話をしているのかを文脈から判断する必要があります。

意味その2：テーブル間の関係の多重度

2つ目は、ER図などのデータモデリングで、テーブル間の対応関係を表す使い方です。1対1、1対多、多対多のいずれであるかを指します。

日本語では多重度と訳されることもあります。設計の議論で「ここのカーディナリティは」と言われた場合、こちらを指していることが多くなります。

なお、テーブル全体の行数を指してカーディナリティと呼ぶ場面もあります。実行計画の説明などで見かける用法で、この場合は「見積もり行数」という意味合いになります。

どちらの話かを見分ける

見分け方は単純です。「高い」「低い」と形容されているなら列の値の多さ、「1対多」のように関係が示されているならテーブル間の多重度です。

場面でも判別できます。性能やインデックスの話なら前者、ER図やテーブル設計の話なら後者。それでも曖昧なときは、その場で「値の種類の話ですか、関係の話ですか」と確認してください。

列のカーディナリティが高い・低いとは

ここからは、性能に関わる1つ目の意味を掘り下げます。高い低いの判断には、実は複数の考え方があります。

なお、性能の議論で使われる場面が圧倒的に多いため、文脈の指定がなければ列の値の多さを指していると考えて差し支えありません。

高いとはどういう状態か

カーディナリティが高い列は、重複の少ない値が入っている列です。社員番号、メールアドレス、注文番号など、原則として行ごとに異なる値を持つ列が典型になります。

この種の列では、特定の値を指定すれば該当する行が1件か、ごく少数に絞り込まれます。探す範囲が小さくなるという性質が、後述するインデックスの効きやすさにつながります。

一意制約や主キーが設定されている列は、定義上すべての値が異なるため、カーディナリティは行数と一致します。これが最も高い状態になります。

低いとはどういう状態か

カーディナリティが低い列は、限られた種類の値が繰り返し登場する列です。性別、都道府県、ステータスの区分、はい・いいえのフラグなどが該当します。

例えば都道府県の列であれば、すべての都道府県が登場していてもカーディナリティは47です。全体が100万行あっても、値の種類は47しかありません。

この場合、特定の値で絞り込んでも該当する行が大量に残ります。ここが性能上の分かれ目になります。

ただし、値の分布が均等とは限りません。都道府県の列でも、実際には東京と大阪に大きく偏っているといったことは普通に起こります。種類の数だけでなく、偏りも確認してください。

絶対値で見るか、比率で見るか

注意したいのが、カーディナリティを値の種類の絶対数とする考え方と、レコード件数に対する比率とする考え方の両方があるという点です。

後者の考え方では、値のバリエーションが多くても、レコード件数が極めて多く同じ値が繰り返し登場するなら、カーディナリティは低いと評価されます。都道府県の47種類も、100万行の中では比率としては非常に小さくなります。

実務で性能を議論するときは、比率で考えるほうが判断を誤りません。「1つの値で絞り込んだとき、全体の何割が残るか」を考えてください。

▼ データベース設計や性能の課題もご相談いただけます システムの設計、既存システムの見直し、データ活用の進め方まで含めて、実務目線でご相談いただけます。 ＞ 相談予約はこちら

インデックス設計との関係

カーディナリティが注目される最大の理由がこれです。インデックスを貼るべきかどうかの判断に直結します。

なぜ効きやすさが変わるのか

インデックスは、目的の行を素早く見つけるための仕組みです。1つの値で絞り込んだときに残る行が少ないほど、その効果が大きくなります。

社員番号のように一意に近い列なら、インデックスをたどれば1件にたどり着けます。対して性別の列では、絞り込んでも全体の約半数が残ります。

この場合、データベースは「インデックスを経由して1件ずつ取りに行くより、最初から全件を読んだほうが速い」と判断することがあります。インデックスを作っても使われない、という現象はこうして起こります。

データベースは、統計情報として各列のカーディナリティを保持しています。「この条件で絞り込むとおよそ何行になりそうか」という見積もりを立てる際の判断材料として使われます。

低いカラムでも効く場合がある

ただし、低ければ必ず無意味というわけではありません。値の分布が偏っている場合、少数派の値で絞り込むならインデックスは有効に働きます。

例えばステータスの列で、大半が「完了」で「エラー」がごく少数という分布なら、エラーを探す検索ではインデックスが効きます。種類の数より、実際の分布を見ることが重要です。

また、他の列と組み合わせた複合インデックスの一部として使う場合も、単独では効かない列が役に立つことがあります。

複合インデックスでの列の順序

複数の列をまとめてインデックスにする場合、列の順序が性能を左右します。一般には、絞り込みの効果が大きい列を先頭に置くのが基本の考え方です。

ただし、実際に使われるクエリの条件によって最適な順序は変わります。どの列が常に条件に含まれるかを確認したうえで決めてください。理論だけで決めると外します。

列の値を加工して検索する条件では、そもそもインデックスが使われないことがあります。関数を適用した結果で絞り込む場合などが該当するため、条件の書き方もあわせて確認してください。

NULLの扱いに注意する

見落とされやすいのがNULLです。NULLも1つの値として数えられる場合があり、カーディナリティの評価に影響します。

大半の行がNULLという列では、NULL以外で絞り込むときには効きますが、NULLを含む検索では効きません。設計段階で、その列にNULLを許すかどうかを明確にしておいてください。

▼ 既存システムの性能課題もご相談いただけます 「動いてはいるが遅い」「原因が特定できない」といった状態の切り分けから、改善の進め方までご支援します。 ＞ 相談予約はこちら

実際の値を確認する方法

推測ではなく、実際のデータで確認するのが設計の出発点です。確認方法と、その値の性質を押さえておきます。

インデックスの情報から確認する

MySQLの場合、インデックスの情報を表示するコマンドにカーディナリティの項目が含まれます。公式のドキュメントでは、この値はインデックス内の一意な値の数の推定値であると説明されています（出典：MySQL「SHOW INDEX Statement」）。

あわせて、カーディナリティが高いほど、結合の際にそのインデックスが使われる可能性が高くなるとも記載されています。インデックスを作ったのに使われていない場合、ここを確認する価値があります。

インデックスがない列については、対象の列で重複を除いた件数を数えるクエリで確認できます。全体の行数と比べれば、比率としての評価もできます。テーブルの列数が多い場合は、対象を絞って確認するほうが現実的です。実際に検索条件として使われている列から順に見ていってください。

表示される値は推定である

重要な注意点です。この値は統計情報に基づく推定であり、正確とは限りません。公式にも、整数として保存された統計に基づいて数えられるため、小さなテーブルでも必ずしも正確ではないと明記されています。

InnoDBの場合、統計の収集はインデックスの構造に対するランダムなサンプリングで行われます。そのため、同じ操作を繰り返しても異なる数値になることがあります（出典：MySQL「ANALYZE TABLE Statement」）。

表示された数字を絶対視せず、傾向をつかむための目安として扱ってください。

なお、この考え方はMySQLに限った話ではありません。他のデータベース製品でも、統計情報をもとに実行計画を決める仕組みは共通しています。呼び方や確認方法が異なるだけです。

統計情報を更新する

データが大きく変わったのに統計が古いままだと、データベースが誤った判断で実行計画を選ぶことがあります。統計を更新するコマンドを実行すれば、最新の状態に近づきます。

大量のデータを投入した後、あるいは大きな削除を行った後は、更新を検討してください。設定によっては自動で再計算されないため、運用の手順に組み込んでおく必要があります。

更新の頻度が高いテーブルでは、統計の更新そのものが負荷になる場合もあります。実行するタイミングは、業務への影響が小さい時間帯を選んでください。

実行計画とあわせて見る

カーディナリティは判断材料の1つにすぎません。最終的には、実行計画を確認して、意図したインデックスが使われているかを見るのが確実です。

インデックスを追加したのに速くならない場合、そもそも使われていないのか、使われているが効果が小さいのかで対処が変わります。実データに近い件数で検証してください。検証環境と本番環境で件数が大きく違うことも、判断を誤る原因になります。少ないデータで試して問題がなくても、本番の件数では結果が変わることがあります。

ER図でのカーディナリティ

ここからは2つ目の意味です。テーブル間の関係を表す多重度として使われる場面を整理します。

1対1・1対多・多対多

基本となる3つの関係があります。1対1は、一方の1件に対して他方も1件だけが対応する関係です。担任とクラスのような関係が該当します。

1対多は、一方の1件に対して他方の複数件が対応する関係です。クラスと生徒、顧客と注文といった関係が典型になります。実務で最も多く登場する形です。

多対多は、互いに相手方の複数件が対応しうる関係です。生徒と習い事、商品とタグのような関係が該当します。

1対1の関係は、そもそも1つのテーブルにまとめられる場合も多くあります。あえて分けるのは、参照する頻度が大きく違う、あるいは権限を分けたいといった理由があるときです。

多対多は中間テーブルに分解する

多対多の関係は、リレーショナルデータベースではそのままの形で表現できません。両者をつなぐ中間のテーブルを作り、1対多の関係を2つに分解するのが基本の対処になります。

中間テーブルには、両方のテーブルを参照する列を持たせます。さらに、その関係自体が持つ情報、例えば登録日や数量なども、この中間テーブルに置くことになります。

設計段階で多対多を見つけたら、必ず分解する。これを後回しにすると、後から構造を変えることになります。

中間テーブルには、両方のIDを組み合わせた一意制約を設定しておくと、同じ組み合わせが重複して登録されることを防げます。

必須か任意かも表現する

多重度には、最大でいくつかという情報だけでなく、最小でいくつかという情報も含まれます。「必ず1件は存在する」のか「0件でもよい」のかという違いです。

顧客と注文の関係で言えば、注文には必ず顧客が1件必要ですが、顧客には注文が0件でも成立します。この違いは、外部キーにNULLを許すかどうかの設計に直結します。

ER図の記法によって、この最小と最大の表現方法が異なります。どの記法を使うのかをプロジェクト内で決め、凡例を図に添えておいてください。

関係に名前を付けておくことも有効です。「顧客が注文する」「商品がタグを持つ」のように動詞で表現すると、図を読む人が関係の意味を理解しやすくなります。

実データで確認する

設計時に1対多だと思っていた関係が、実データでは多対多になっていることがあります。既存システムからの移行では特によく起こります。

既存データがある場合は、実際に重複がないかを確認してから設計を確定してください。想定と違えば、テーブル構成そのものを見直す必要があります。

▼ データ設計の妥当性を第三者視点で確認します テーブル構成、性能、既存システムからの移行まで含めて、設計段階からご相談いただけます。 ＞ 相談予約はこちら

設計でつまずきやすい点

カーディナリティに関わる失敗は、パターンが決まっています。知っていれば避けられるものを挙げます。

とりあえず全列にインデックスを貼る

「検索が遅いから」という理由で、条件に使う列すべてにインデックスを作るのはよくある失敗です。効かない列にも作ってしまうことになります。

さらに、インデックスは更新時の負荷にもなります。登録や更新のたびにインデックスの更新も必要になるため、多すぎると書き込みが遅くなります。

実際のクエリを確認し、効果のある列に絞って作ってください。作った後に使われているかを確認する工程も、設計の一部です。

多対多を放置したまま進める

多対多の関係を中間テーブルに分解せず、片方のテーブルに複数の値をまとめて持たせるという設計をしてしまうことがあります。カンマ区切りで複数のIDを1つの列に入れるような形です。

この構造では、検索も集計も困難になります。最初は動いても、要件が増えた時点で必ず行き詰まる設計です。

カーディナリティは後から変わる

見落とされやすい点です。運用開始時は効いていたインデックスが、データが増えるにつれて効かなくなることがあります。値の分布が変わるためです。

逆に、当初は件数が少なくインデックスが不要だった列も、データが増えれば必要になります。定期的に見直す前提で設計しておいてください。

仕様変更で値の種類が増えるケースもあります。区分が2種類だった列に、後から10種類が追加されるといった変化は業務システムでは珍しくありません。

統計情報が古いまま放置される

設計が正しくても、統計が実態と合っていなければデータベースは誤った判断をします。大量のデータを投入した後に突然遅くなった、という現象はこれが原因であることがあります。

統計の更新を運用の手順に含め、いつ誰が実行するのかを決めておいてください。

実務で使えるようにする

知識として知っているだけでは意味がありません。設計と運用の手順に組み込む方法を整理します。

設計時の確認項目にする

テーブル設計のレビュー項目に、「検索条件になる列のカーディナリティを確認したか」「多対多の関係を分解したか」を加えておいてください。チェックリストにすれば、担当が変わっても水準が保てます。

あわせて、想定される件数と、その列で絞り込んだときに残る件数も見積もっておきます。数字で確認する習慣があると、判断がぶれません。

あわせて、想定される検索条件を設計時に洗い出しておいてください。どの列で絞り込むかが分からなければ、インデックスの設計もできません。

運用でも定期的に確認する

データが増えたときに性能がどう変わるかを、定期的に確認する仕組みを作ってください。遅くなってから調べるのでは、業務に影響が出た後になります。

実行に時間がかかっているクエリを記録しておく仕組みがあれば、傾向の変化に早く気づけます。

インデックスを追加したときは、その判断の根拠も記録に残してください。どのクエリを速くするために作ったのかが分かれば、不要になった際に削除する判断もできます。

チームで用語をそろえる

冒頭で触れたとおり、この言葉は2つの意味で使われます。チーム内で「性能の文脈では列の値の多さ、設計の文脈では多重度」と決めておくだけで、認識のずれが減ります。

設計書にも、どちらの意味で使っているかが分かる表現を心がけてください。「多重度」と書き分けるのも実用的な方法です。

判断できる人を増やす

性能の問題は、分かる人が1人しかいないと、その人が不在のときに手が止まります。設計の意図と判断の根拠を記録として残し、レビューを通じて共有してください。

なぜこの列にインデックスを作ったのか、なぜ作らなかったのか。理由が残っていれば、後任者が見直す際の判断材料になります。

あわせて、社内で設計を担える人を増やす取り組みも進めてください。

まとめ

カーディナリティには2つの意味があります。列に含まれる一意な値の数を指す場合と、テーブル間の関係の多重度を指す場合です。「高い・低い」で語られていれば前者、「1対多」で語られていれば後者と見分けられます。

列のカーディナリティは、インデックスの効きやすさに直結します。値の種類の絶対数ではなく、1つの値で絞り込んだときに全体の何割が残るかという比率で考えると、判断を誤りません。

実際の値はインデックスの情報から確認できますが、これは統計に基づく推定値であり、実行のたびに変わることもあります。絶対視せず、実行計画とあわせて確認してください。

ER図では、1対1、1対多、多対多の3つが基本です。多対多はそのまま表現できないため、中間テーブルに分解するのが原則になります。設計段階で見つけて処理しておけば、後からの作り直しを避けられます。

▼ システム開発とデータ活用を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しから要件の整理、システム開発、AI活用と社内への定着支援までを一貫してご支援しています。何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら