2

データベース設計について混乱しています。私はある会社で開発者として働いており、データベース設計における次の問題について上司と話し合いました。私が処理しなければならないデータベース設計の一部には、2つのテーブルが含まれています。

Employees Table: Username, Name, JobTitle, OrganizationCode
Organizations Table: OrganizationCode, Name...

これらの2つのテーブルは、会社のすべての従業員、部門、部門、およびユニットを処理します。他の開発者によって設計されたデータベースのほとんどは、これら2つのテーブルの間に関係がないように設計されています。

私の場合、上司に、これら2つのテーブルの間に関係を作成する方がよいと言いました（つまり、OrganizationCodeは組織テーブルの主キーへの外部キーです）。制約、整合性、およびクエリの記述を簡単に適用できるためです。

彼は私に適切な理由を与えずにそれを拒否した。私の部門には2000人以上の従業員がおり、会社には約50000人以上の従業員がいます。ですから、彼が勧めたデザインはかなりのスペースを取り、アプリケーション開発の見通しからは扱いにくいと思います。

みんなに何をすすめますか？

4

3 に答える 3

5

あなたもあなたの上司も、分析と設計の違いを理解する必要があります。2 つのテーブル間の関係の設計は、主題の現実世界の現実と、データベースの情報要件に従属します。

主題 (いわゆる「実世界」) をデータの観点から分析する場合、主題空間全体をエンティティーとそれらのエンティティー間の関係に分割します。次に、各値を属性のインスタンスとしてデータベースに格納します。各属性は、エンティティまたは関係の何らかの側面を表します。各属性には、その属性の可能な値のセットであるドメインもあります。これらすべてが概念的なデータ モデルを構成し、その機能は発見されたものであり、発明されたものではありません。

次に、データベースの設計に進むときは、エンティティ、関係、および属性について知っていることを考慮して、列、テーブル、および外部キーを設計します。もちろん、概念モデルと他のいくつかの詳細が与えられた場合、優れた設計を作成する方法を知る必要があります。

では、あなたの場合、件名はどのように見えますか? 従業員は部門で働いていますか？それは関係です。部門には、多くの従業員が勤務する場合があります。従業員は複数の部門で働くことができますか? はいの場合、多対多の関係があります。その場合、2 つの外部キーを含むジャンクション テーブルが必要になります。そうでない場合、設計は多対 1 の関係を適切に反映します。

このように質問の言い回しをすることで、内容的には、現実世界の構造について上司と共通認識に達することができるかもしれません。そうすれば、外部キーがその現実を表現するのにどのように役立つかについて、共通の理解に達することができるかもしれません。あるいは、あなたの上司は、概念モデルに対する拒否権を保持している限り、データベースの (再) 設計をあなたに任せることに満足しているかもしれません。

于 2012-12-05T12:12:27.920 に答える
1

従業員は何らかの形で組織単位に関連付ける必要があり、問題はその関係の履歴を保存するかどうかです。履歴を保存する必要がない場合は、従業員テーブルの組織コードを使用できます。それ以外の場合は、従業員と部門の関係の履歴を表示するために、組織と従業員の間の結合テーブルが必要です。

もう 1 つの考慮事項は、別の結合テーブルが必要になる組織間の関係の履歴を保存するかどうかです。

于 2012-12-05T08:38:01.950 に答える
1

あなたのデザインは上司のデザインよりも優れています。上司の設計により、存在しない組織単位に従業員を関連付けることが可能になります。組織情報の更新も面倒で、これらの更新は 2 つの場所で行う必要があります。

現在、スペースはもはや大きな要因ではありませんが、システムの保守性と、データが正しいことを保証することが、2 つのテーブル間に適切な関係を確立するための決定要因となるはずです。

もし私があなただったら、なぜあなたの上司が関係を強化することに反対しているのかを尋ねます.

于 2012-12-05T08:47:26.853 に答える