バックグラウンド

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

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

私の考えは、一般的なCSVエクスポートを作成し、オフィスでホストされているMySQLデータベースに（おそらくPythonで）毎晩インポートし、そこから必要な特定のクエリを実行できるようにすることです。私はデータベースの経験はありませんが、基本を理解しています。データベースの作成と通常のフォームについて少し読みました。

国際的なクライアントがすぐに始まる可能性があるので、それが発生した場合にデータベースが爆発しないようにしてください。現在、クライアントとしていくつかの大企業があり、部門が異なります（例：ACME親会社、ACMEヘルスケア部門、ACMEボディケア部門）。

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

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

スキーマを「落書き」のように「設計」し、3番目の形式に正規化するようにしました。私は、MySQLのワークベンチにそれを差し込むと、それはかなり私のためにすべてをした：
（フルサイズのグラフィックはこちら）

_{（ソース：maian.org）}

実行するクエリの例

• クレジットが残っているクライアントは非アクティブです（将来的にクラスがスケジュールされていないクライアント）
• クライアント/部門/部門ごとの出席率はどのくらいですか（各セッションのステータスIDで測定）
• 教師が1か月に行った授業の数
• 出席率の低いクライアントにフラグを立てる
• 部門の出席率を示す人事部門のカスタムレポート

質問

• これは過剰設計ですか、それとも正しい方向に進んでいますか？
• ほとんどのクエリで複数のテーブルを結合する必要があるため、パフォーマンスに大きな影響がありますか？
• おそらく一般的なクエリになるので、クライアントに「lastsession」列を追加しました。これは良い考えですか、それともデータベースを厳密に正規化しておくべきですか？

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

あなたの質問に対するいくつかのより多くの答え：

1）このような問題に初めて取り組む人にとって、あなたはほぼ目標を達成しています。この質問に関する他の人からのポインタは、これまでのところほとんどカバーしています。よくやった！

2＆3）パフォーマンスヒットは、特定のクエリ/プロシージャに適切なインデックスを設定して最適化することに大きく依存します。さらに重要なのはレコードの量です。メインテーブルの100万を超えるレコードについて話しているのでない限り、合理的なハードウェアではパフォーマンスが問題にならない十分に主流の設計に順調に進んでいるようです。

とは言え、これはあなたの質問3に関連しています。最初は、パフォーマンスや正規化正統性に対する過敏症について、ここで過度に心配するべきではありません。これは、作成しているレポートサーバーであり、トランザクションベースのアプリケーションバックエンドではありません。パフォーマンスや正規化の重要性に関して、プロファイルが大きく異なります。ライブサインアップおよびスケジューリングアプリケーションをサポートするデータベースは、データを返すまでに数秒かかるクエリに注意する必要があります。レポートサーバー関数は、複雑で時間のかかるクエリに対する許容度が高いだけでなく、パフォーマンスを向上させるための戦略も大きく異なります。

たとえば、トランザクションベースのアプリケーション環境では、パフォーマンス改善オプションには、ストアドプロシージャとテーブル構造をn度にリファクタリングすることや、一般的に要求される少量のデータのキャッシュ戦略を開発することが含まれます。レポート環境では確実にこれを行うことができますが、スケジュールされたプロセスが実行され、事前設定されたレポートを保存するスナップショットメカニズムを導入することで、パフォーマンスにさらに大きな影響を与えることができ、ユーザーはデータベース層に負荷をかけずにスナップショットデータにアクセスしますリクエストごと。

これらはすべて、作成するデータベースの役割によっては、採用する設計の原則と手法が異なる可能性があることを説明するために長続きします。お役に立てば幸いです。

あなたは正しい考えを持っています。ただし、クリーンアップして、マッピング（has *）テーブルの一部を削除することができます。

できることは、Departmentsテーブルで、CityIdとDivisionIdを追加することです。

その上、私はすべてがうまくいくと思います...

私が行う唯一の変更は次のとおりです。
。1-VARCHARをNVARCHARに変更します。国際化する可能性がある場合は、Unicodeが必要になる場合があります。

2-可能であれば、int IDをGUID（uniqueidentifier）に変更します（これは私の個人的な好みかもしれません）。最終的に複数の環境（dev / test / staging / prod）ができるようになったとすると、データを一方から他方に移行することができます。GUID IDがあると、これが大幅に簡単になります。

3-会社の3つのレイヤー->部門->部門の構造では不十分な場合があります。さて、これはやりすぎかもしれませんが、nレベルの深度をサポートできるように、その階層を一般化することができます。これにより、一部のクエリがより複雑になるため、トレードオフの価値がない場合があります。さらに、より多くの層を持つクライアントは、このモデルに簡単に「詰め込む」ことができるかもしれません。

4-また、VARCHARであるクライアントテーブルにステータスがあり、ステータステーブルへのリンクがありません。クライアントステータスが何を表すかについては、もう少し明確になると思います。

いいえ。詳細レベルでデザインしているようです。

国と企業、そして都市と部門は、あなたのデザインにおいて本当に同じ実体であると思います。CountriesテーブルとCitiesテーブル（およびCities_Has_Departments）を削除し、必要に応じて、ブールフラグIsPublicSectorをCompaniesテーブル（または、民間セクター/公共セクターよりも選択肢が多い場合はCompanyType列）に追加します。

また、Departmentsテーブルの使用法にエラーがあると思います。Departmentsテーブルは、各顧客部門が持つことができるさまざまな種類の部門への参照として機能するように見えます。もしそうなら、それはDepartmentTypesと呼ばれるべきです。しかし、あなたのクライアント（私は、出席者だと思います）は、部門のTYPEに属しておらず、会社の実際の部門インスタンスに属しています。現在のところ、特定のクライアントは人事部のどこかに属していますが、どの部署に属していないかがわかります。

言い換えると、クライアントはDivisions_Has_Departmentsを呼び出すテーブルにリンクする必要があります（ただし、私は単にDepartmentsと呼びます）。その場合、データベースで標準の参照整合性を使用する場合は、前述のように都市を部門に集約する必要があります。

ちなみに、すでにCSVを生成していて、それらをmySQLデータベースにロードしたい場合は、LOAD DATA LOCAL INFILEが最適です。http：//dev.mysql.com/doc/refman/5.1/ en / load-data.html。Mysqlimportも検討する価値があり、基本的にはデータをファイルにロードするための優れたラッパーであるコマンドラインツールです。

ほとんどのことはすでに述べられていますが、1つ付け加えることができると思います。若い開発者がパフォーマンスについて少し前から心配しすぎることは非常に一般的であり、テーブルの結合に関する質問はその方向に向かっているようです。これは、「時期尚早の最適化」と呼ばれるソフトウェア開発アンチパターンです。あなたの心からその反射を追放してみてください:)

もう1つ：「都市」と「国」のテーブルが本当に必要だと思いますか？部門のテーブルに「city」列と「country」列があれば、ユースケースに十分ではありませんか？たとえば、アプリケーションで、部署を都市別に、都市を国別にリストする必要があるでしょうか

ビジネスインテリジェンス/レポーティングスペシャリストおよび戦略/プランニングマネージャーとしての役割に基づいたコメント：

1. 上記のラリーの指示に同意します。私見、それはあまりにも過度に設計されているわけではなく、いくつかのものが場違いに見えるだけです。わかりやすくするために、クライアントに会社ID、部門の説明、部門の説明、部門タイプID、部門タイプIDを直接タグ付けします。長期的な一貫性を保つために、部門タイプIDと部門タイプIDをルックアップテーブルと内部レポート/分析フィールドへの参照として使用します。

2. パックテーブルには「クレジット」列が含まれていますが、実際にはクライアントのベーステーブルに関連付けられているのではないので、パックが多い場合、将来のクラスに残されているクレジットの量を確認できますか？アプリケーションは計算を処理し、クライアントテーブルに集中的に格納できます。

3. 会社の情報では、明らかな住所/電話番号など、さらに多くのフィールドを使用できます。情報。また、D＆Bの「DUNs」列（サイト/ブランチ/アルティメット）を長期的に追加する準備もします。Dunand Bradstreet（D＆B）には巨大な会社のカタログがあり、後でその情報が非常に役立ちます。レポート/分析用。これは、あなたが言及する複数の部門の問題を処理し、サブ/部門/ブランチ/その他の階層をロールアップできるようにします。大軍団の。

4. 事前にパッケージ化された「レポート」ソフトウェアを使用すれば、迅速かつはるかに少ない頭痛の種となる可能性のある大規模な開発イニシアチブに向けて準備する可能性がある、いくつのレコードを処理するかについては触れません。大規模なデータベース（<65000）の行を処理しない場合は、MS-Access、OpenOffice（Base）、または関連するレポート/アプリ開発ソリューションがうまくいかないことを確認してください。私はOracleの無料のAPEXソフトウェアをかなり自分で使用しています。無料のデータベースOracle XEが付属しているので、サイトからダウンロードするだけです。

5. FYI-レポートの洞察：大規模なデータベースの場合、通常、2つのデータベースインスタンスがあります。a）各詳細レコードを記録するためのトランザクションデータベース。b）別のマシンに格納されているレポートデータベース（データマート/データウェアハウス）。詳細については、スタースキーマとスノーフレークスキーマの両方を検索してください。

よろしく。

複数のテーブルへの結合がパフォーマンスに影響を与えるという懸念のみに対処したいと思います。結合を行う必要があるため、正規化を恐れないでください。結合は正常であり、リレーショナルデータベースでは予期されており、結合を適切に処理するように設計されています。PK / FK関係を設定する必要があります（データの整合性のため、これは設計で考慮することが重要です）が、多くのデータベースではFKは自動的にインデックス付けされません。これらは結合で使用されるため、FKSのインデックス付けから開始することをお勧めします。PKは一意である必要があるため、通常、作成時にインデックスを取得します。データウェアハウスの設計により結合の数が減少することは事実ですが、通常、1つのレポートで何百万ものレコードにアクセスする必要があるまで、データウェアハウジングのポイントに到達しません。それでも、ほとんどすべてのデータウェアハウスは、トランザクションデータベースを使用してリアルタイムでデータを収集し、その後、データをスケジュールに従って（夜間または月間、またはビジネスニーズに合わせて）ウェアハウスに移動します。したがって、レポートのパフォーマンスを向上させるために後でデータウェアハウスを設計する必要がある場合でも、これは良い出発点です。

あなたのデザインは最初の1年のCS学生にとって印象的だと言わざるを得ません。

それは過度に設計されたものではなく、これが私が問題に取り組む方法です。結合は問題ありませんが、パフォーマンスへの影響はそれほど大きくありません（データベースを非正規化しない限り完全に必要ですが、これはお勧めできません！）。ステータスについては、代わりにenumデータ型を使用してそのテーブルを最適化できるかどうかを確認してください。

私はトレーニング/学校のドメインで働いていましたが、「セッション」（特定のコースのインスタンス）と呼ばれるものとコース自体の間には一般にM：1の関係があると指摘しました。言い換えると、カタログはコース（「スペイン語101」など）を提供しますが、1学期中に2つの異なるインスタンスがある可能性があります（スミスが教えるトゥス、ジョーンズが教える水と金）。

それ以外は、良いスタートのようです。クライアントドメイン（「クライアント」につながるグラフ）は、モデル化したものよりも複雑であることに気づくと思いますが、実際のデータが手に入るまで、それを使いすぎないでください。

いくつかのことが頭に浮かびました：

1. これらの表はレポート作成に向いているように見えましたが、実際にはビジネスを運営していませんでした。クライアントがサインアップすると、基本的にセッションのリストに参加するクライアントの注文があり、その注文は1つの会社の複数の従業員に対するものになると思います。「注文」テーブルは実際にはシステムの中心にあり、データキャプチャと最終的なレポートを駆動するように見えます。（ビジネスを実行するために使用してきた紙のドキュメントとデータベース設計を比較して、論理的に一致するかどうかを確認してください。）

2. 多くの場合、企業には部門がありません。従業員は、部門/部門を変更する場合があり、セッションの途中で変更される場合もあります。企業は、部門/部門を追加/削除/名前変更することがあります。テーブルの内容がリアルタイムで変化する可能性があるため、その後のレポートやグループ化が難しくならないようにしてください。非常に多くの連絡先データが非常に多くのテーブルに分割されているため、レポートを意味のある包括的なものにするには、非常に厳密なデータ入力検証を実施する必要がある場合があります。たとえば、新しいクライアントが追加されたとき、彼の会社/部門/部門/都市が同僚と同じ値に一致することを確認します。

3. 「パック」の概念はまったく明確ではありません。

4. 中小企業であることを示しているので、現在のマシンの速度と容量を考えると、パフォーマンスが問題になるのは驚くべきことです。