アプリケーションの機能の状態を監視するためのデータベースを作成しています。ロジックは次のとおりです。

各アプリケーションには、私が監視している独自の特定の機能リストがあります。各機能は、1 つのアプリケーションのみに属します。アプリケーションへの外部キーを持つ機能テーブルがあります

各アプリケーションは、1 つ以上のマシンで実行されます。各マシンは、1 つ以上のアプリケーションを実行できます。これは MTM 接続なので、ApplicationInstance テーブル接続アプリケーションとマシンがあります。

実際の監視は、ApplicationInstance のクエリに関するものです。問題がある場合、それに関する情報は、ApplicationInstance への外部キーを保持する AppInstanceError テーブルに送られます。クエリが成功すると、各機能のステータスのリストが取得されます。したがって、ApplicationInstance と Functionality への外部キーを持つ FunctionalityStatus テーブルがあります。

これは一種の悪い設計だと思います。なぜアプリケーションへの複数の参照があるのでしょうか? 両方が同じアプリケーションを指すことを保証するものは何ですか? または、これを確実にする方法はありますか？

したがって、私の修正案は、FunctionalityStatus を外部キーで Machines & Functionality に接続することです。しかし、この場合、彼らは ApplicationInstance を定義しているので、各ペアに ApplicationInstance があるという保証は何ですか? 何らかの形で接続すべきではないでしょうか。現実の世界では接続が存在し、それは明白なので、データベースに存在しなくても問題ないでしょうか?

この問題を解決する、またはデータ設計から見えない接続を確保する「適切な方法」はありますか?

より明確にするために、現在持っている DB の設計を準備しました。

欠けているのは、FunctionalityStatus から Machine への接続だけです。このような接続を行うには、次の 2 つの方法があります。

1. 外部キーを ApplicationInstance に追加します - 次に、私の疑問は次のとおりです。
   • Functionality の ApplicationId が ApplicationInstance の ApplicationId と同じであることを確認するにはどうすればよいですか?
   • このデータの複製は本当に必要ですか?
2. マシンに外部キーを追加 - そして疑問:
   • すべての FunctionalityStatus レコードに適切な ApplicationInstance レコードがありますか?
   • ApplicationInstance と FunctionalityStatus の間に明らかな関連がある場合 (最初の疑問で言及)、データベースでそれを確認できないのはなぜですか?
   • ここでも、すべての ApplicationInstance レコードが FunctionalityStatus テーブルに表示される (または表示されるはず) ため、データの冗長性が確保されます。

それとも、デザイン全体が台無しになっていて、まったく別のことを考え出す必要があるのでしょうか?

バックグラウンド

私は CS の 1 年生で、父の中小企業でアルバイトをしています。実際のアプリケーション開発の経験はありません。私は Python でスクリプトを書き、C でいくつかのコースワークを作成しましたが、このようなものはありません。

私の父は小規模なトレーニング ビジネスを経営しており、現在、すべてのクラスは外部の Web アプリケーションを介してスケジュール、録画、フォローアップされています。エクスポート/「レポート」機能がありますが、非常に一般的であり、特定のレポートが必要です。クエリを実行するために実際のデータベースにアクセスすることはできません。カスタム レポート システムのセットアップを依頼されました。

私の考えは、一般的な CSV エクスポートを作成し、(おそらく Python を使用して) オフィスで毎晩ホストされている MySQL データベースにインポートし、そこから必要な特定のクエリを実行することです。データベースの経験はありませんが、基本的なことは理解しています。データベースの作成と正規形について少し読んだことがあります。

すぐに国際的な顧客を獲得し始めるかもしれないので、それが起こった場合にデータベースが爆発しないようにしたい. また、現在、いくつかの大企業を顧客としており、さまざまな部門があります (例: ACME 親会社、ACME ヘルスケア部門、ACME ボディケア部門)。

私が思いついたスキーマは次のとおりです。

1. クライアントの観点から:
   • クライアントがメインテーブル
   • クライアントは、所属する部門にリンクされています
     • 部門は、ロンドンの人事部、スウォンジーのマーケティングなど、国中に分散している可能性があります。
     • 部門は会社の部門にリンクされています
   • 部門は親会社にリンクされています
2. クラスの観点から：
   • セッションはメインテーブルです
     • 教師は各セッションにリンクされています
     • 各セッションには statusid が与えられます。例: 0 - 完了、1 - キャンセル
     • セッションは、任意のサイズの「パック」にグループ化されます
   • 各パックはクライアントに割り当てられます

私はスキーマを 1 枚の紙に "設計" (走り書きのようなもの) し、3 番目の形式に正規化したままにしようとしました。次に、MySQL Workbench にプラグインすると、すべてきれいになりました:
(フルサイズのグラフィックはここをクリック)

_{(ソース: maian.org )}

実行するクエリの例

• クレジットがまだ残っているクライアントのうち、非アクティブなクライアント (今後クラスが予定されていないクライアント)
• クライアント/部門/部門ごとの出席率は? (各セッションのステータス ID で測定)
• 教師は月に何回授業を受けましたか
• 出席率の低いクライアントにフラグを立てる
• 部門内の人々の出席率を含む人事部門のカスタム レポート

質問

• これはオーバーエンジニアリングですか、それとも正しい方向に向かっていますか?
• ほとんどのクエリで複数のテーブルを結合する必要があると、パフォーマンスが大幅に低下しますか?
• おそらく一般的なクエリになるため、「lastsession」列をクライアントに追加しました。これは良い考えですか、それともデータベースを厳密に正規化する必要がありますか?

御時間ありがとうございます

私はデータベースの正規化の概念を理解していますが、特に就職の面接では、それを平易な英語で説明するのにいつも苦労しています。ウィキペディアの投稿を読みましたが、それでも開発者以外の人に概念を説明するのは難しいと思います。「重複データを取得しないようにデータベースを設計する」が最初に頭に浮かぶことです。

データベースの正規化の概念をわかりやすい英語で説明する良い方法はありますか？また、第1正規形、第2正規形、第3正規形の違いを示す良い例は何ですか？

あなたが就職の面接に行き、その人が尋ねたとしましょう： 正規化の概念と、正規化されたデータベースを設計する方法を説明してください。

インタビュアーが探している重要なポイントは何ですか？

データベースに T ₁₀と T ₁₁という 2 つのテーブルがあり、それぞれ 10 列と 11 列があり、そのうちの 10 列は両方でまったく同じであるとします。

違反している正規化ルール (ある場合) は?

Post、Attachment、Media の 3 つのテーブルがあります。

投稿には添付ファイルがあり、添付ファイルにはメディアがあります。

現在、Post テーブルと Attachment テーブルは外部キーによってリンクされており、Attachment テーブルと Media テーブルも同様です。私の質問は、適切なデータベース設計と正規化のために、Post と Media の間に外部キー関係を設定する必要があるかどうかです。これらのテーブルをどの程度深くリンクすればよいかわかりません。

ありがとう

ユーザーがイベントに登録できるフリーランスの Web アプリケーションがあります。私のデータベースには、t_users.user_id 列にリンクされた外部キー制約を持つ列 t_events_applications.user_id を持つ t_events_applicants テーブルがあります。したがって、これは、Web アプリケーションに登録したユーザーのみが Web アプリケーションのイベントに登録できることを意味します。

私のクライアントは、未登録ユーザー (私の t_user テーブルにエントリを持たないユーザー) がイベントに登録できるようにしたいと考えています。これらの未登録ユーザーは、名前と電子メール アドレスを提供するだけで、イベントに登録できます。

name 列と email 列を含む t_temporary_user テーブルを作成してから、t_events_applicants.user_id fk 制約を削除する必要がありますか? または、未登録ユーザーを t_user テーブルに追加してから、タイプが「登録済み」または「未登録」の t_user.type という列を追加する必要がありますか?

どのアプローチを使用するかをどのように決定しますか?

多くの場合、どちらのアプローチにも躊躇します。「後で、一時ユーザーが完全に登録されたユーザーになることを許可されたらどうなるでしょうか。その場合は、t_user テーブルのみを使用する必要があるかもしれません。しかし、多くの一時ユーザーを保存することにも満足できません。 t_user で」

野球の統計にデータを保存していますが、players、battingStats、pitchingStatsの3つのテーブルを使用して保存したいと思います。質問の目的のために、各プレーヤーはバッティング統計またはピッチング統計を持っていますが、両方は持っていません。

3NFでこのような関係を正規化するにはどうすればよいですか？

私は 1 ～ 2 年の経験があるので、この面接の質問に何を答えればよいでしょうか。

正規化にはどのような種類がありますか? 私はすべての正規形を言うべきですか、それとも何ですか？

顧客は、Cell、Workなどの複数の電話番号を持つことができます。CustomerテーブルのphoneIDは一意であり、PhoneテーブルのPhoneIDを指します。顧客レコードが削除された場合は、電話テーブルのphoneIDも削除する必要があります。

私のデザインについて何か心配はありますか？これは適切に設計されていますか？私の問題は、CustomerテーブルのphoneIDが子であり、子レコードが削除された場合、親（Phone）レコードを自動的に削除できないことです。

フィットネス情報を保存しているデータベースを引き継いで、特定のテーブルを1つのテーブルのままにするか、3つのテーブルに分割するかについて議論していました。

今日、次のフィールドを持つワークアウトと呼ばれる1つのテーブルがあります

id、exercise_id、reps、weight、date、person_id

したがって、1日に3つの異なるエクササイズを2セット行った場合、その日のテーブルには6つのレコードがあります。例えば：

id、exercise_id、reps、weight、date、person_id 1、1、10、100、1 / 1
/ 2010、10 2、1、10、100、1 / 1
/ 2010、10 3、1、10、100、1
/ 1 / 2010、10 4、2、10、100、1 / 1 /
2010、10 5、2、10、100、1 / 1 / 2010、10
6、2、10、100、1
/ 1/2010、 10

したがって、複数のレコードに冗長なデータ（date、personid、exercise_id）がある場合、これを3つのテーブルに正規化する必要があります。

WorkoutSummary： -id
-
date
--person_id

WorkoutExercise： -id
-
workout_id（WorkoutSummaryへの外部キー）
-exercise_id

WorkoutSets：
--id
--workout_exercise_id（WorkoutExerciseへの外部キー）
--reps
--weight

欠点は、このリファクタリング後のクエリが遅くなることだと思います。これは、以前は結合がなかった同じクエリを実行するために3つのテーブルを結合する必要があるためです。リファクタリングの利点により、将来、重複を追加することなく、ワークアウトサマリーレベルまたはエクササイズレベルで新しいフィールドを追加できるようになります。

この議論についてのフィードバックはありますか？