1

次の構造があるとします。

City
Area
User

各エリアには 1 つの都市しかありません。
すべてのユーザーは、少なくとも 1 つ、場合によっては複数のエリアを持っています。
すべてのユーザーは 1 つの都市しか持っていません。

これをモデル化する最もエレガントな方法は何ですか?

現在、私は持っています：

User,
UserArea,
Area,
City

ここで、UserArea は User と 1:M の関係であり、Area は City と 1:1 の関係です。

問題はこれです：

ユーザーは現在のモデルで 3 つまたは 4 つのエリアを持つことができますが、2 つのエリアが市 "1" にあり、他の 2 つのエリアが市 "2" にある可能性があります。これはビジネスルール違反です。

この種のことを防ぐために制約を入れるべきですか、それともこの種のパラドックスが不可能になるようにさらに正規化するためのより良いアプローチですか? もしそうなら、どのようにこのシステムをモデル化して、次のようにしますか?

1 ユーザー = 1 市。
1 エリア = 1 都市;
1 ユーザー = M エリア。

洞察をありがとう。

4

7 に答える 7

1

ユーザー、エリア、都市ごとにテーブルを作成し、ユーザーと都市 (組み合わせ) が一意になるように制約されているユーザー (FK)、都市 (FK)、およびエリア (FK) の列を持つ 4 番目のテーブルを作成します。その後、ユーザーとエリアの組み合わせが挿入されるたびに、一意でない都市は許可されません。

于 2009-07-20T18:32:19.000 に答える
0

私がオフハンドで考えることができる唯一のことは次のとおりです。

Area テーブルに、CityID と AreaID の複合代替キーを指定します。AreaID をプライマリにします (1 つの都市しか持てないようにします)。

この代替キー (AK1) を使用して、Area と UserArea の間に FK 関係を形成します。

User テーブルに、UserID と CityID の複合代替キーを指定します。UserID をプライマリにします。

この代替キー (AK2) を使用して、User と UserArea の間に FK 関係を形成します。

したがって、UserArea テーブルは次のようになります。

ユーザー ID 都市 ID エリア ID

AK2 ベースの外部キーでは、ユーザーのホーム都市に一致する都市を選択する必要があり、AK1 ベースの外部キーでは、その都市に属する地域を選択する必要があります。本質的に、AK1 と AK2 の外部キーはオーバーラップし、必要なものを強制します。

于 2009-07-20T18:39:39.937 に答える
0

この回答は SQLServerCentral から提供されたもので、まさに私が探していたものです。冗長性はありますが (このフォーラムで rexum が指摘したように)、異常の可能性はありません。

私はあなたのコメントや提案に非常に興味があります.

CREATE TABLE [dbo].[Cities](
    [CityID] [int] IDENTITY(1,1) NOT NULL,
  [CityName] [varchar](50) NOT NULL,
 CONSTRAINT [PK_Cities] PRIMARY KEY CLUSTERED
(
   [CityID] ASC
)
)
CREATE TABLE [dbo].[Users](
   [UserID] [int] IDENTITY(1,1) NOT NULL,
  [UserName] [varchar](50) NOT NULL,
  [CityID] [int] NOT NULL,
 CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED
(
  [UserID] ASC
)
)

ALTER TABLE [dbo].[Users]  WITH CHECK ADD  CONSTRAINT [FK_Users_Cities] FOREIGN KEY([CityID])
REFERENCES [dbo].[Cities] ([CityID])
GO
ALTER TABLE [dbo].[Users] CHECK CONSTRAINT [FK_Users_Cities]
GO
CREATE UNIQUE NONCLUSTERED INDEX [IX_UsersCity] ON [dbo].[Users]
(
   [UserID] ASC,
   [CityID] ASC
)

CREATE TABLE [dbo].[Areas](
    [AreaID] [int] IDENTITY(1,1) NOT NULL,
  [AreaName] [varchar](50) NOT NULL,
  [CityID] [int] NOT NULL,
 CONSTRAINT [PK_Areas] PRIMARY KEY CLUSTERED
(
  [AreaID] ASC
))


GO
ALTER TABLE [dbo].[Areas]  WITH CHECK ADD  CONSTRAINT [FK_Areas_Cities] FOREIGN KEY([CityID])
REFERENCES [dbo].[Cities] ([CityID])
GO
ALTER TABLE [dbo].[Areas] CHECK CONSTRAINT [FK_Areas_Cities]
GO
CREATE UNIQUE NONCLUSTERED INDEX [IX_AreasCity] ON [dbo].[Areas]
(
 [AreaID] ASC,
   [CityID] ASC
)
GO
CREATE TABLE [dbo].[UserCityArea](
   [UserID] [int] NOT NULL,
    [CityID] [int] NOT NULL,
    [AreaID] [int] NOT NULL,
 CONSTRAINT [PK_UserCityArea] PRIMARY KEY CLUSTERED
(
   [UserID] ASC,
   [CityID] ASC,
   [AreaID] ASC
)
)

GO
ALTER TABLE [dbo].[UserCityArea]  WITH CHECK ADD FOREIGN KEY([UserID], [CityID])
REFERENCES [dbo].[Users] ([UserID], [CityID])
GO
ALTER TABLE [dbo].[UserCityArea]  WITH CHECK ADD FOREIGN KEY([AreaID], [CityID])
REFERENCES [dbo].[Areas] ([AreaID], [CityID])
于 2009-07-27T16:41:53.600 に答える
0

「ユーザー、ユーザーエリア、エリア、シティ」というアプローチは正しいと思います。違反を防ぐために、制約とビジネス ロジックに依存します。

于 2009-07-20T22:45:16.900 に答える
0

エリアについて詳しく教えてください。私の仮定を述べさせてください。
ユーザーは都市に住んでいます。
どの都市にもエリアがあります。
エリアは 1 つの都市にのみ分類できます。
ユーザーは 1 つの都市にのみ住むことができ
ます。これらの条件を考えると、設計仕様に次の機能依存関係があるようです:
エリア -> 都市
ユーザー -> 都市
ビジネス モデルは、ユーザーが同じ都市内で複数の住所を持つことができるが、できないことを示唆しています。 2 つの異なる都市に住所があります。これは現実的な設計上の制約ですか? 複数の住所を持つことができる場合、なぜ異なる都市にできないのでしょうか?
特定のユーザーのすべての領域を保存する場合は、3 番目のテーブルが必要です (提案したように)。テーブルは次のようになります
ユーザーエリア(ユーザーID、エリアID)。トリガーまたはストアド プロシージャを使用してビジネス ロジックを実装する必要があります。

于 2009-07-26T06:23:44.340 に答える
0

USER_AREAS次の列のみが必要です。

  • USER_ID(pk, fk for USERS.USER_ID)
  • AREA_ID(pk, fk for AREA.AREA_ID)

エリアは、AREAS テーブル内の 1 つの都市に関連付けられています。AREAS テーブルからロールアップすることで、どの都市がユーザーに関連付けられているかがわかります。

AREA

  • AREA_ID(ピーク)
  • CITY-ID(fk for CITY.CITY_ID)

表に入れるCITY_IDのUSER_AREASは冗長です。次に、テーブルに配置CITY_IDしても、そのレコードの が実際に AREA テーブルの に関連付けられているとはUSER_AREAS限りません。CHECK 制約は、列によって受け入れられる値を制限することによってドメインの整合性を強制するだけであり、ユーザー定義関数以外の他のテーブルの列を参照することはできません。AREA_IDCITY_ID

データベース内の 1 つの都市にのみ属するユーザーの地域のビジネス ルールを適用することはできません。アプリケーションレベルで実行する必要があります（sprocがUSER_AREASテーブルの挿入/更新を管理するものは何でも）。

于 2009-07-26T21:01:08.740 に答える
0

「エリア」の意味がわかりません。

都市区分は以下の通りだと思います。

地球には国があります。国には地域 (州、州など) があります。地域には地域 (市、町、村など) があります。地域 (十分に大きい場合) は地区を持つことができます。

ユーザー => 国 + 地域/エリア + 都市 (+ 地区)

エリアについて詳しく教えてください。

于 2009-07-26T21:07:22.160 に答える