2

私はデータベースの設計と理論を研究していて、最終的にSQLに基づくスキーマを作成することを慎重に試みました。時間があれば、私のレイアウトを見直して、論理的であることを確認したいと思います。私の知識を向上させることを目的としたヒントや批判はもちろん大歓迎です！:)

私の一般的な目標は次のとおりです。複数の店舗を持つ企業が、トレーニング日と検証日をマークするだけで、従業員のトレーニングの進捗状況を追跡できるデータベースを作成します。基本的に、これは階層になります。

Business 1 
--Store Location (a)
----Employee
----Employee
----Employee
--Store Location (b)
----employee
----employee
----employee

Business 2
--Store Location (a)
----employee
----employee
--Store Location (b)
----employee
----etc...

このスキーマは、無制限のビジネス、ストア、および従業員を許可する必要があります。

トレーニングに関する限り、次のタイプの階層が必要です。

Business 1
--Employee Class           (Manager, Employee, Salesman, Associate, etc)
----Training Category      (Sales, Stocking, Manufacturing, etc)
------Training Activity    (How to sell X product, How to stock Y aisle, etc)
------Training Activity
------Training Activity
----Training Category
------Training Activity
------Training Activity
--Employee Class
----Training Category
----Training Category

Business 2
--Employee Class           
----Training Category     
------Training Activity    
------Training Activity
------Training Activity
----Training Category
------Training Activity
------Training Activity
--Employee Class
----Training Category
----Training Category

次のものは、ビジネスニーズに基づいて変更可能であり、ビジネスのアカウントの作成時に作成する必要があります。

*Number of Stores
*Number of Employees 
*Employee Classes

*Training Categories
*Training Activities

したがって、壮大な質問は次のとおりです
。1）私はどれくらい近づきましたか？
2）どうすればそれをより良くすることができますか？

前もって感謝します！

ダイアグラムの画像へのリンクは次のとおりです。http： //i1227.photobucket.com/albums/ee422/CorySCline/diagram.jpg

4

1 に答える 1

1

ぱっと見だけでもかなり良いです。ほぼ間違いなく、多対多の関係は常に分割する必要があります。たとえば、会社と従業員のテーブルには、従業員 ID にリンクする会社 ID があります。すべての属性が同じ従業員が 2 つの異なる企業に雇用される可能性があるという事実を考えてみましょう。一意の識別子はありません。これに対抗する方法は、company_id と employee_id の 2 つの属性を持つ一致するテーブルを作成することです (場合によっては自動インクリメント識別子)。

同様に、店舗間を移動する従業員を考えてみましょう...従業員の実績を見つけることができませんでした。また、従業員クラスと従業員でそれを行います。

于 2012-11-05T19:05:37.563 に答える