タグ付けされた質問 「referential-integrity」

データ内の一貫性を確保するためにデータベース管理システムによって提供される機能。

3
配列メンバーの外部キー制約？
ジョブの役割を含むテーブルがあるとします： CREATE TABLE roles ( "role" character varying(80) NOT NULL, CONSTRAINT "role" PRIMARY KEY (role) ); さらにテーブル、ユーザーがあり、各行（特定のユーザー）が任意の数のジョブロールを持つことができるとします。 CREATE TABLE users ( username character varying(12) NOT NULL, roles character varying(80)[] NOT NULL, CONSTRAINT username PRIMARY KEY (username) ); の各メンバーがusers.roles[]roles.role に存在することを確認する必要があります。私が望むのは、users.roles[]ifがroles.roleを参照するような各メンバーの外部キー制約だと思われます。 これはpostgresでは不可能のようです。私はこれを間違った方法で見ていますか？これを処理するための推奨される「正しい」方法は何ですか？
3
データベースで「少なくとも1つ」または「正確に1つ」を強制する制約
ユーザーがいて、各ユーザーが複数のメールアドレスを持つことができるとします CREATE TABLE emails ( user_id integer, email_address text, is_active boolean ) いくつかのサンプル行 user_id | email_address | is_active 1 | foo@bar.com | t 1 | baz@bar.com | f 1 | bar@foo.com | f 2 | ccc@ddd.com | t すべてのユーザーがアクティブなアドレスを1つだけ持つという制約を施行したい。Postgresでこれを行うにはどうすればよいですか？私はこれを行うことができました： CREATE UNIQUE INDEX "user_email" ON emails(user_id) WHERE is_active=true; これは、複数のアクティブなアドレスを持つユーザーを保護しますが、すべてのアドレスがfalseに設定されることは保護しません。 可能であれば、トリガーまたはpl / …
5
ビューを参照する外部キー（ベーステーブルだけでなく）を許可するDBMSはありますか？
Djangoモデリングの質問に触発されました：Djangoの複数の多対多リレーションを使用したデータベースモデリング。db-designは次のようなものです。 CREATE TABLE Book ( BookID INT NOT NULL , BookTitle VARCHAR(200) NOT NULL , PRIMARY KEY (BookID) ) ; CREATE TABLE Tag ( TagID INT NOT NULL , TagName VARCHAR(50) NOT NULL , PRIMARY KEY (TagID) ) ; CREATE TABLE BookTag ( BookID INT NOT NULL , TagID INT …
2
多対多および弱いエンティティ
別のエンティティに定義されない限り存在できないエンティティがあり、このエンティティを多対多の関係に参加させたい。 例：アーティストにはアルバムがあり（アルバムはアーティストなしでは存在できません）、アルバムにも多くのトラックがありますが、同じトラックが多くのアルバムに存在する可能性があります。 そのため、アルバムとトラックの間には多対多の関係があります。 アルバムが弱いエンティティである場合、その主キーはアーティストを参照する外部キーであるため、多対多の関係を表す別のテーブルへの外部キーにすることはできません。 問題は、SQLでこのような関係を持つことは可能ですか？その場合、どのように表現するのですか？
2
制約-1つのブール行はtrue、他のすべての行はfalse
列があります： standard BOOLEAN NOT NULL 1つの行をTrueに、その他の行をすべてFalseに強制したいと思います。この制約に応じて、FKやその他のものはありません。私はplpgsqlでそれを達成できることを知っていますが、これは大槌のようです。CHECKまたはUNIQUE制約のようなものを好みます。シンプルなほど良い。 1つの行はTrueでなければなりませんが、すべてFalseにすることはできません（したがって、最初に挿入された行はTrueである必要があります）。 行を更新する必要があります。つまり、すべての行が最初にFalseに設定され、その後に1つの行がTrueに設定される可能性があるため、更新が完了するまで制約を確認するのを待つ必要があります。 そこの間にFKがあるproducts.tax_rate_idとtax_rate.id、それはデフォルトまたは新製品を作成する容易にするために、ユーザが選択可能で、標準税率、とは何の関係もありません。.. 重要な場合はPostgreSQL 9.5。 バックグラウンド 表は税率です。税率の1つがデフォルトです（standardデフォルトはPostgresコマンドであるため）。新しい商品が追加されると、標準の税率が商品に適用されます。がないstandard場合、データベースは推測またはすべての種類の不要なチェックを実行する必要があります。簡単な解決策は、があることを確認することだと思いましたstandard。 上記の「デフォルト」とは、プレゼンテーション層（UI）を意味します。デフォルトの税率を変更するためのユーザーオプションがあります。GUI /ユーザーがtax_rate_idをNULLに設定しないようにするために追加のチェックを追加するか、デフォルトの税率を設定する必要があります。
3
参照するすべての外部キーへの主キー更新のカスケード
それを参照するすべての外部キー間で更新をカスケードして主キー列の値を更新することは可能ですか？ ＃編集1： followinqクエリを実行すると select * from sys.foreign_keys where referenced_object_id=OBJECT_ID('myTable') 、update_referential_actionが0に設定されていることがわかります。したがって、主キー列を更新した後は何も行われません。外部キーを更新してCASCADE UPDATEでそれらを作成するにはどうすればよいですか？ ＃EDIT 2： スキーマ内のすべての外部キーの作成または削除をスクリプト化するには、次のスクリプトを実行します（ここから取得） DECLARE @schema_name sysname; DECLARE @table_name sysname; DECLARE @constraint_name sysname; DECLARE @constraint_object_id int; DECLARE @referenced_object_name sysname; DECLARE @is_disabled bit; DECLARE @is_not_for_replication bit; DECLARE @is_not_trusted bit; DECLARE @delete_referential_action tinyint; DECLARE @update_referential_action tinyint; DECLARE @tsql nvarchar(4000); DECLARE @tsql2 nvarchar(4000); …
4
DELETEステートメントがREFERENCE制約と競合しています
私の状況は次のようになります： テーブルSTOCK_ARTICLES： ID *[PK]* OTHER_DB_ID ITEM_NAME テーブルの場所： ID *[PK]* LOCATION_NAME テーブルWORK_PLACE： ID *[PK]* WORKPLACE_NAME テーブルINVENTORY_ITEMS： ID *[PK]* ITEM_NAME STOCK_ARTICLE *[FK]* LOCATION *[FK]* WORK_PLACE *[FK]* INVENTORY_ITEMSの3つのFKは、明らかに、他のそれぞれのテーブルの「ID」列を参照しています。 ここに関連するテーブルは、STOCK_ARTICLEとINVENTORY_ITEMSです。 これで、上記のデータベースを別のデータベース（OTHER_DB）と「同期」するいくつかの手順（SQLスクリプト）で構成されるSQLジョブがあります。このジョブ内のステップの1つは「クリーンアップ」です。同じIDを持つ他のデータベースに対応するレコードがないSTOCK_ITEMSからすべてのレコードを削除します。次のようになります。 DELETE FROM STOCK_ARTICLES WHERE NOT EXISTS (SELECT OTHER_DB_ID FROM [OTHER_DB].[dbo].[OtherTable] AS other WHERE other.ObjectID = STOCK_ARTICLES.OTHER_DB_ID) しかし、このステップは常に失敗します： DELETEステートメントは、REFERENCE制約「FK_INVENTORY_ITEMS_STOCK_ARTICLES」と競合しました。データベース「FIRST_DB」、テーブル「dbo.INVENTORY_ITEMS」、列「STOCK_ARTICLES」で競合が発生しました。[SQLSTATE 23000]（エラー547）ステートメントは終了しました。[SQLSTATE 01000]（エラー3621）。ステップは失敗しました。 したがって、問題は、レコードがINVENTORY_ITEMSによって参照されている場合、STOCK_ARTICLESからレコードを削除できないことです。しかし、このクリーンアップは機能する必要があります。つまり、クリーンアップスクリプトを拡張して、最初にSTOCK_ITEMSから削除する必要のあるレコードを特定する必要がありますが、対応するIDがINVENTORY_ITEMS内から参照されているため、できません。次に、最初にINVENTORY_ITEMS内のレコードを削除してから、STOCK_ARTICLES内のレコードを削除します。私は正しいですか？SQLコードはそのときどのように見えますか？ ありがとうございました。
1
「2つのテーブルから離れた」制約の適用
SQLで電気回路図をモデリングするときに問題が発生しました。キャプチャしたい構造は part ←────────── pin ↑ ↑ part_inst ←───── pin_inst ここで、「inst」は「instance」の略です。 例えば、私のように持っているかもしれないpartとのLM358オペアンプpinの1OUT、1IN-、1IN +、GND、2IN +、2IN-、2OUT、およびV CC。次に、このパーツを回路図に配置して、a part_instと8を 作成しpin_instます。 データフィールドを無視して、スキーマでの最初の試みは create table parts ( part_id bigserial primary key ); create table pins ( pin_id bigserial primary key, part_id bigint not null references parts ); create table part_insts ( part_inst_id bigserial primary key, part_id …
2
この「マッピング」テーブルには別のId列が必要ですか？
の表Producersとの表がありProducts、どちらも次の形式です。 Id -int、主キー Name -nvarchar プロデューサーは複数の製品を運ぶことができるため、次のようなテーブルを作成しましたProducerDetails。 ProducerId -int、外部キー Producers.Id ProductId -int、外部キー Products.Id それから自分に問いかけ始めたので、専門家に聞いてみようと思いました。テーブルに追加のId（int、主キー）列がある方がデータベース設計が優れてProducerDetailsいるでしょうか？それとも不要ですか？ SQL-Server 2008 R2を使用しています。 編集 -これらのテーブル間の関係は多対多だと思います。申し訳ありませんが、明確にしていません。生産者は複数のタイプの製品を運ぶことができ、同じ製品が複数の異なる生産者によって生産される可能性があります。 この質問が非常に単純である場合はお詫び申し上げます。参照整合性/データベース設計は私の強みではありません（私はそれを改善しようとしていますが）。
2
別々のデータベース間の関係は悪い習慣ですか？
複数のデータベースを持つクライアントを使用しています。レベルデータベース（アプリケーション固有のDB）masterからの関係を持ついくつかのレベルデータベースがありますinstance。fromからinstancetoへの関係masterは、のテーブルへの主キーを表す整数値ですmaster。のビューとストアドプロシージャは、これらのストアドキーを介してinstancesデータをロードするように設定masterされています。 明らかに、実際の参照整合性はありませんが、それは悪い習慣なのinstanceでしょうか、それともデータベースの読み取り専用テーブルにデータを常駐させるべきなのでしょうか。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.