-1

この質問は、前のトピック「MySQL - フラット テーブルから第 1 正規形への移行」( http://bit.ly/9pvS0Y )に直接関連しています。新しいトピックを開始するのが最善だと考えました。

以下は私の最初の正規形スキーマであり、私の目的には十分にしっかりしていると確信していますが、間違っている場合は修正してください。

これを 2 番目と 3 番目のフォームに移行する方法を知りたいのですが、私のテーブルが 2NF と 3NF ルールによってどのように影響を受けるかについての指針は本当に役に立ちます。

関係

-活動と場所の関係 = 1 対多 - 1 つの活動は 1 つの場所を持つことができ、場所は多くの活動を持つことができます (活動の FK としての場所 ID)

-アクティビティと週の関係 = 1 対多 - 1 つのアクティビティに 1 週​​間、1 週間に複数のアクティビティを含めることができます (アクティビティの FK としての WeekID)。

-ユーザーとアクティビティ= 多対多 - 1 人のユーザーが多数のアクティビティを持つことができ、1 つのアクティビティが多数のユーザーを持つことができます

User Table - UserID PK
+------------+-----------+
| UserID     | Username  |
+------------+-----------+
|            |           |
+------------+-----------+


Activity Table - ActivityID PK / WeekID FK / LocationID FK
+------------+-----------+------------+-----------+------------+-------------+-----------+
| ActivityID | UserID    | WeekID     | Day       | Minutes    | LocationID  |   Miles   |
+------------+-----------+------------+-----------+------------+-------------+-----------+
|            |           |            |           |            |             |           | 
+------------+-----------+------------+-----------+------------+-------------+-----------+


Location Table - LocationID PK
+------------+---------------+
| LocationID | Location_Name |
+------------+---------------+
|            |               |
+------------+---------------+


Weeks Table - Week ID PK
+------------+-----------+
|WeekID      | Week_No   |             
+------------+-----------+
|            |           |
+------------+-----------+


User_Activity Table 
+------------+---------------+
| UserID     | ActivityID    |
+------------+---------------+
|            |               |
+------------+---------------+
4

4 に答える 4

1

これが学術的な演習でない限り、通常のフォームを「移動」しないことをお勧めします。そのプロセスの正式名称は、分解による正規化です。ただし、ほとんどの場合、あまり実用的ではなく、通常はまったく不要です。

実際には、すでに仮想的に正規化されているスキーマ (通常は 3NF ではなく 5NF または BCNF を対象とする) から始めて、それを検証する方が理にかなっています。すでに目的の NF にあるスキーマを設計するプロセスは、合成による正規化と呼ばれ、分解法よりもほとんどの実務家の作業方法に近いものです。合成による正規化を達成するための正確な手法はいくつかありますが、最も一般的な方法は、優れた分析、経験、および常識を組み合わせたものです。

于 2010-08-11T21:44:10.170 に答える
1

アクティビティ テーブルに両方の列が既に定義されているため、テーブル User_Activity の目的がわからない。そうでなければ、この設計はすでに第 3 正規形になっています。

于 2010-08-11T20:38:42.750 に答える
0

"Week_no" が "週番号" を意味する場合は、"Week_no" を "Activity" に移動し、テーブル "Weeks" を削除します。

于 2011-01-15T11:26:13.630 に答える
0

russjudge が言うように、User_Activity テーブルの目的がわかりません。

正規化では、一般に、可能な限り自然キーを使用することがベスト プラクティスです。そのため、Weeks テーブルの要点もわかりません。なぜ Week_No を使用しないのでしょうか? (ここで考えられる例外は、異なる日数で「週」を設定したい場合です。この場合、開始日と終了日を週テーブルに含めることもできます。現状では、私は要点がわかりません。)

実際には、Activity テーブルの週と日を 1 つの日付フィールドに置き換えます。これは実際には 1NF (派生データの削除) の一部である必要があります。ほとんどのバージョンの SQL (MySQL を含む) は、必要に応じて日付フィールドを日または週に簡単に変換できます。

また、ActivityID フィールドを削除して、代わりに UserID、Date、および LocationID の組み合わせを Activity テーブルの複合主キーとして使用したくなるでしょう。ただし、同じユーザー、日付、および場所に対して複数の行を記録する必要がある場合があります。その場合、ActivityID フィールドはテーブルの主キーのままにしておく必要があります。

于 2010-08-12T11:01:07.583 に答える