0

このデータベース設計の問題に対する最善のアプローチを探しています。うまくいくものを見つけたと思いますが、それが最善の方法かどうかはわかりません。それがあなたにとって何か意味があるなら、私はCakePHPを使っています。

私のデータベースは音楽レッスン用に作られています。私には、両親、学生、教師、管理者、または以下に概説する人々と呼ばれるテーブルの他の誰かであるかどうかにかかわらず、すべての人々がいます。

People
id first_name last_name email created modified

今私が抱え始めている問題は、一人を教師、生徒の親などとしてどのように識別するかです。グループごとに別々のテーブルを用意することは私にとって理にかなっています。例えば

Teachers
id person_id

Students
id person_id

Payers
id person_id

このように、理論的には教師は学生になることもできます。授業料を支払う人である「支払人」も学生である可能性があり、リストは続きます。

今、私は人と学生の関係も知る必要があります。したがって、次のような別のテーブルがあります。

Relationships:
id person_id student_id type

「タイプ」は、母親、父親、法定後見人、世話人、叔母、祖母などです。このデザインは私には理にかなっていますが、同時に、それが必要と思われることを説明するためのかなりの作業とテーブルのようです。説明しやすくなります。これを行うためのより良い方法はありますか？私は自分自身を推測し続け、人を学生や教師としてラベル付けするためだけに、まったく新しいテーブルを用意することを考えています。

4

1 に答える 1

2

あなたは古典的なサブタイピングのシナリオを説明しました。ここで、はスーパータイプであり、、、、 （本当に保護者） 、およびおそらく他のタイプ（従業員など）PERSONを含むサブタイプを定義しました。STUDENTTEACHERPARENT

通常、このタイプのサブタイピングモデルを使用する場合、さまざまなサブタイプが独自の述語、つまり属性または関係を持っているためです。

関係をモデル化するには、ビジネスルールの観点から何が重要であり、スキーマにこれらのビジネスルールを課すために何をする価値があるかを決定する必要があります。うるさいことが必要な場合は、とテーブルGUARDIAN_RELATIONSHIPの共通部分であるテーブルを使用することを決定する場合があります。これには、問題の各個人サブタイプに対するFKと、関係タイプのフラグ/コード/説明が含まれます。PARENTSTUDENT

または、2つのレコードPERSONAL_RELATIONSHIP間の共通部分である単一のテーブルを作成することもできます。PERSONここにリレーションシップタイプコードを配置することもできます。このアプローチははるかに緩いですが、おそらく保守が容易です。最終的には、追跡する必要のある関係の種類の数と、それらがビジネスルールの中心にあるかどうかによって異なります。

于 2012-04-11T23:52:23.980 に答える