1

まず、すべての属性/フィールドを更新できるようにしたいのですが、単一の一意のキーはありません。各 PC を PC1/PC2/PC3 として分類でき、例を挙げられず、各 PC にネットワークとソフトウェア情報があるような階層があります。デザインと作例は

Parent Table PC(EmpName, PCName, HostName,.... PhysicalLocation, PCType) EMPName,PCName,PCType組み合わせると、このテーブルがユニークになります。

記録例('XYZ', 'Work Laptop','XYZ-PC',.....,'DESK-123','PC1')

子テーブルPCNetwork(EmpName, PCName, HostName,IPAddr,....,PhysicalLocation,PCType)

example record1 ('XYZ', 'Work Laptop','XYZ-PC','0.0.0.0',....,'DESK-123','PC1')

example record2 ('XYZ', 'Work Laptop','XYZ-PC','0.0.0.1',....,'DESK-123','PC1')

すべてのフィールドを変更可能にしたいので、両方に Surrogate Key Id 列を追加しました。PC-Id をネットワーク テーブルへの FK として使用しましたが、挿入中に、PC テーブルから ID を取得するクエリを作成する必要があります。

2 つの問題があります。自然/複合キーを使用すると、主キーの更新を許可しない Asp.Net Gridview を介して更新が行われるため、すべてのレコードを更新できません。

サロゲート キーを使用すると、レコードが重複する可能性があり、それらを参照したり、他のフィールドに外部キー制約を設定したりすることはできません。これらは 3 つのフィールドすべてを結合することによってのみ一意になるためです。

SQL Server 2008 と ASP.Net 4.0 を使用しています

私は確かに何かが欠けています.誰かがこれを助けたり、良いデザインを提案したりできます. ありがとう！！

4

1 に答える 1

1

サロゲート キーを使用すると、レコードが重複する可能性があり、それらを参照したり、他のフィールドに外部キー制約を付けたりすることはできません。3 つのフィールドをすべて組み合わせてのみ一意にすることができるからです。

代理キーを使用しても、重複の可能性を排除し、参照制約を作成できます。候補キー列を一意としてマークすることから始めます。

alter table PC
add constraint UK_PC_EMPName_PCName_PCType
unique (EMPName, PCName, PCType);

次に、次のように外部キーを追加できます。

alter table PCNetwork
add constraint FK_PC_PCNetwork
foreign key (EMPName, PCName, PCType)
references PC (EMPName, PCName, PCType);

ただし、説明されているスキーマを完全には理解していないため、データをモデル化するより良い方法があるかどうかはわかりません。そうは言っても、ここにいくつかの観察があります：

  • PhysicalLocationPCType一見冗長なデータのように見えます。どのテーブルが最適かを判断する必要があります。
  • PCNetworkの代理キーを参照する列を に持つことができるため、PCNetworkPCでは必要ありません(ただし、 で一意のキーを作成します)。EmpName, PCName, HostNamePC
于 2013-04-03T20:56:37.247 に答える