0

会社のイントラネット アプリケーションを開発しています。同社は、多くの事業分野、部門、部門、ユニット、グループが存在する複雑な構造を持っています。私はこれらすべての世話をしなければなりません。部門レベルで働く従業員もいれば、ユニットレベルで働く従業員もいます。現在の問題は、データベースの設計にあります。データベースの設計方法について混乱しています。最初に、次のように設計することにしました。

Employees: Username, Name, Title, OrgCode
Departments: OrgCode, Name
Divisions: OrgCode, Name
Units: OrgCode, Name

しかし、前に言ったように、一部の従業員は部門の下で働いているので、これらすべてのテーブル間の関係をどのように作成するかが問題です。Departments、Divisions、および Units テーブルの OrgCode への外部キーとして、Employees テーブルの OrgCode を使用することは可能ですか?

おすすめのデザインを教えてください。

更新: @wizzardz は優れたデータベース設計を行いました。ここで必要なのは、このデータベース設計に適合するデータの例を用意することだけです。データベースで使用している一連のデータを次に示します。次の情報を持つ従業員がいると仮定します。ユーザー名: JohnA 名前: John タイトル:エンジニア組織コード: AA

また、部門 AA があるとします。このデータをデータベース設計にどのように分配するのでしょうか?

4

3 に答える 3

3

このようなデザインを行うことができます

Departments、Divisions などの個別のテーブルに移動するのではなく、TypeId を使用して単一のテーブルに格納して、 Departments 、Divisions などを区別します。

このようなデザインを試してみませんか

ここに画像の説明を入力

レベル テーブルでは、「Deparments、Divisions」、Groups などの値を入力する必要があります (別のテーブルに保持することで、組織による将来の新しいレベルの追加を処理できます)。

OrganizationLevels テーブルでは、Department Name、Division Name、GroupName などを保存する必要があります。

従業員テーブルには、従業員が組織内で働いているレベルを格納する組織レベル テーブルを持つ外部キー参照があります。

特定の従業員の作業履歴を保存したい場合/従業員があるレベルから別のレベルに移動できる可能性がある場合は、この設計を使用することをお勧めします

ここに画像の説明を入力

設計に関するサンプルデータ

レベル

 Id  LevelType  
 1    Department
 2    Division
 3    Group

組織レベル

Id Name LevelId Parent*(Give a proper name to this column)*
13  AA    1       NULL
.
.
21  B     2        13 (This column refer to the Id of department it belongs to.)

従業員

Id UserName Name   Title 
 110  JohnA    John   Engineer

EmployeeWorkDetails

Id  EmployeeId OrganisationLevelId StartDate  EndDate IsActive
271    110           13            20/09/2011   NULL     true

Employee テーブルの OrgCode は削除できます。これは、その組織の従業員の従業員コードだと思ったからです。

これが役立つことを願っています。

于 2012-12-08T07:23:06.567 に答える
0 
Employees: Username, Name, Title, OrgCode
Departments: OrgCode, Name
Divisions: OrgCode, Name
Units: OrgCode, Name

上記のDB設計に対して、OrgCodeを含むOrgというテーブルをもう1つ作成し、タイプとして別の列を作成します（これにより、部門、部門、ユニットなど、どのタイプの組織であるかについての洞察が得られます）。

次に、従業員テーブルのOrgCodeを使用して、OrgテーブルのOrgCode（親子関係）を参照することができます。

于 2012-12-08T06:52:43.727 に答える
0

分析と設計の違いを学ぶことをお勧めします。データベースを設計するときは、データの保存方法と取得方法に影響を与えるテーブル、列、および制約を考案します。後で学習する操作を含め、更新とクエリの容易さに関心があります。

データ要件を分析するとき、あなたは物事を発明することに従事していません、あなたは物事を発見することに従事しています。そして、あなたが発見しているのは、主題が表すことになっている「現実世界」に関するものです。あなたは主題を「実体」とそれらの実体間の関係に分解します。次に、データベースに格納されているすべての値を属性のインスタンスに関連付け、すべての属性をエンティティまたは関係のいずれかの側面に関連付けます。これにより、概念モデルが作成されます。

あなたの場合、従業員、部門、ユニットなどの間の関係は非常に複雑に聞こえます。この複雑な現実を正確に反映するモデルを考え出すことは、かなりの努力の価値があります。

優れた概念モデルができたら、概念モデルを適切に表すSQLテーブル、列、および制約を作成できます。これには、学ぶことができる設計スキルが含まれます。しかし、お粗末な概念モデルを持っている場合は、設計がどれほど優れていても、運命にあります。

于 2012-12-08T14:25:25.573 に答える