（乳房）カップ部、あるいは（アンダーバスト位置の）ベルト部のいずれかを構成要素として持つ衣料がブラジャーと識別・定義される との仮説に私たちは一昨日至りました（参照 ）。ここで、ブラジャー、カップ、ベルトをそれぞれエンティティとして捉えた場合、以下のような概念データモデルが描けるでしょう。
▼ブラジャー対カップ カーディナリティ→１対０…２ ブラはカップ部品を持たないこともあり（カップレスブラ）、２つ持つこともある。 ▼ブラジャー対ベルト カーディナリティ→１対０…１ ブラはベルト部をもたないこともあり（ヌーブラ）、１つ持つこともある。 カップ、ベルトともに在ったり無かったりですので、もし、ブラジャーテーブルを
と設計してしまった日には、ブラ対各パーツ（カップ部品番号、ベルト部品番号）のカーディナリティが1対1以上であることが保証できないため、必ずカップ部品番号、ベルト部品番号のどちらかのデータがNULLになる、という設計になってしまいます。 また、所謂”横に長いテーブル”になりイマイチです。そして、あのお方、データベース史を語る上で欠かせない大先生に叱責を受けるでしょう。 ﾟ･*:.｡..｡.:*･ﾟﾟ･*:.｡..｡.:*･ﾟ 下着天使ゴランジェリー（参照
）の一員として（←大嘘っ
■□■□■□■□■□
■□■□■□■□■□
NULLを許す概念データモデルを設計するエンジニアは大馬鹿者！ NULL禁止！！ に近い内容を述べられていると思います。 しかし、現実のシステム開発/運用現場において、 ・正規化していないテーブル ・NULL項目の多いテーブル を、高パフォーマンス、高トランザクションが求められるOLTP、Web、インターネットで敢えてそのように設計する場合も多々あります。例えば、key-valueでのバークレーDBやdbmやlibhashや、RDBMSでは、MyISAMのMySQLなどを用いて、とにかく高速なデータ引当、更新を実装する場合などです。 しかし、それは、「敢えて、冗長なテーブル設計を行っている」ってことを、エンジニアが自覚していて初めて価値があることで、物理的制約により、物理データベース設計段階で考えるべきこと。 概念データモデリングの過程では、あくまでも美しいエンテイティ・リレーションシップをデザインできなければならない、だから、NULLを許してはならない、正規化しなければならないっ、ってはるかは初心者なりに考えている現在です。 ﾟ･*:.｡..｡.:*･ﾟﾟ･*:.｡..｡.:*･ﾟ
カップ部品と、ベルト部品を別々のテーブルとして管理するのもイマイチです。それぞれの部品ごとに表が増えるという運用になり煩わしいです。で、カップ部品、ベルト部品などは全て部品表で管理します。 では、ブラとパーツ（部品）の関連はどのように管理しましょう？ ブラとパーツのカーディナリティは、
・≪部品からみた多重度≫ 部品はブラジャーに全く使われていないか、最大ｎのブラジャーにて使用されている（0...n）。 ・≪ブラジャーからみた多重度≫ ブラジャーは必ず一個以上の部品（カップ部 or ベルト部）から構成されている（1...n）。 ということになります。このリレーションシップはn対n（many to many）の関係、所謂 多対多の不特定リレーションシップになってしまいますので、連関エンティティ「部品構成」を挿入します。
ブラ部品表と製品表（ブラジャーテーブル）のエンティティモデルを設計したところで、明日に続きます。
■関連記事：
「ブラジャー☆データモデリング★ERD☆哲学」週間番組表★☆ |
）はるかが最も尊敬するデータベース技術者、C.J.Date先生は、その著書↓（この本だけは絶対買ってっ！！読まないとダメ）のなかで、
