データベースのテーブルについておたずねします.

主キーがなくて,そのかわりに外部キー(と主キー以外の列)しか持たない
テーブルも可能だと聞きました.
テーブルには主キーが必ずあるものだと思っていましたが,
どのような使いかたをするのでしょうか.

どうやら,最初からデータがあるわけではなく,
追加されるタイミングがわからないデータを格納する場合に作っておく,
ということらしいのですが,なんのことかよくわかりません.

データベース関連書籍をいくつか調べましたが,
主キーのないテーブルの説明などは見当たりません.
また,この悩ましい問題を与えてくれた知り合いに訊ねましたが,
テーブル構成などの具体的なことは,
企業内のことなので,教えてもらえませんでした.

何か具体的な例を交えながらご説明いただければと思います.

このQ&Aに関連する最新のQ&A

とは RDB」に関するQ&A: RDBとは何ぞや!

A 回答 (6件)

難しく考える必要はないと思いますよ。

主キーというのがそのテーブルの行をユニークに規定する独立したIDと考えると、その設置有無は必要性で判断すれば良いことです。不要でも設置して構いませんが、それは分かり易さとシステムリソース、レスポンス、メンテナンス性との兼合いでしょう。

では、好例ではありませんが、一つ具体例をあげてみましょう。
日本語が下手でごめんなさい。よ~く読んで、ER図を書いてみてください。
とある組立工場を思い浮かべてください。そこで生産される製品の条件を以下とします。
・製品は複数の部品から構成される。
・部品は複数の製品に使用される。
・部品は複数の仕入先から調達される。
・部品の仕入先は製品によって規定される。
・製品を構成する部品は、部品毎に仕入先が異なる。
ここで登場する実態(エンティティ)は、
・製品
・部品
・仕入先
の3つですね。各々の実態の関係は、
・製品:部品=N:N
・部品:仕入先=N:N
・製品:仕入先=N:N
となり、N:Nの関係ばかりですね。
さて、この関係でリレーションを張ってみましょう。単純に考えると各実体(テーブル)の構成項目は以下になりますね。
・製品=製品ID+製品情報
・部品=部品ID+製品ID+仕入先ID+部品情報
・仕入先=仕入先ID+仕入先情報
ここで問題になるのは、部品テーブルの部品情報ですね。同じ部品でも仕入先毎に複数の行が発生するので、データの重複になります。メンテナンス性からこれは望ましくありません。リソース的にも不利ですね。
そこで、リレーションを一つ実態に昇格させましょう。製品別部品別仕入先テーブルを作るのです。その結果各テーブルは、
・製品別部品別仕入先=製品ID+部品ID+仕入先ID
・部品=部品ID+部品情報
になります。これで、データの重複を排除できます。この時、製品別部品別仕入先テーブルには外部キーしか必要ないですね。敢えて主キーを付けても活用されません。

ひとつの例でしたが、こんなもんでどうでしょう?
    • good
    • 0
この回答へのお礼

丁寧な説明をありがとうございました.
このあとも,上の例を参考にしながらいろいろ本を読んで調べていくうちに,
だいぶわかってきました.
MSACCESSのサンプル(Northwind)における受注明細テーブルでは,
主キーを連結キーとして設定してありますが,
これが実は外部キーなのだと思います.
とにかく,どうもありがとうございました.

お礼日時:2001/08/26 11:05

storkです。


ymmasayanさんより指摘を受けました。
回答#4は、ちょっと言葉が足りなかったようです、すみません。

補足します。

>正規化すると、m_chappyさんのようにすべて1:nの
>テーブルになるが、重要性が低いので非正規化したと
>いうことではないでしょうか。

<修正>
正規化すると、m_chappyさんのように1:nのテーブルになります。
puplixさんのご質問のケースでは、重要性が低いので非正規化したためそのようなテーブルが出来上がったのではないでしょうか。
    • good
    • 1
この回答へのお礼

「重要性が低いので非正規化した」かどうかはわかりませんが,
非正規化についても必要でしょうから,
引き続き勉強していきたいと思います.
どうもありがとうございました.

お礼日時:2001/08/26 11:40

No.4のstork さんの回答には誤解があるようです。



> 正規化すると、m_chappyさんのようにすべて1:nのテーブルになるが、重要性が低いので非正規化したということではないでしょうか。

部品表を2つに分けて、「製品別部品別仕入先表」を作り出したのは、あくまでも正規化であって、非正規化では有りません。m_chappy さんの言われる通り、重複を避けるために「リレーションを一つ実態に昇格させた」ので明らかに正規化です。本来の実態との間に違和感があり、又、データベースが複雑になったように見えるのも事実ですが、この事から単純に非正規化と断定できるものではないはずです。
    • good
    • 0
この回答へのお礼

非正規化については今後勉強していくつもりですが,
いまは正規化についてとことん身に付けようと思っています.
どうもありがとうございました.

お礼日時:2001/08/26 11:36

正規化すると、m_chappyさんのようにすべて1:nのテーブルになるが、重要性が低いので非正規化したということではないでしょうか。


すべてを正規化すると、細かいテーブルがたくさん出来るので、簡略化したのだと思います。

ここで注意したいのは、『最初から正規化しなかった』と『重要性が低いので非正規化した』は結果が同じもしくは非常に似ていることが多いです。
しかし『最初から...』の場合は、データに対する認識がユーザと設計者の間で食い違っている場合があるので注意してください。システムの柔軟性が損なわれるおそれがあります。
    • good
    • 0
この回答へのお礼

お盆にDBの勉強をはじめたばかりなので,
非正規化については,まだまだ先のことになりそうです.
とにかく,回答をありがとうございました.

お礼日時:2001/08/26 11:29

RDBの表には主キーが必ず必要だと言う話と、主キーの宣言を行うかどうかと言う話を分離する必要があるように思います。



No.2のm_chappy さんの言われる「主キーというのがそのテーブルの行をユニークに規定する独立したIDと考えると、その設置有無は必要性で判断すれば良いことです。」と言うのはそれを言われていると思います。

m_chappy さんの上げられた「製品別部品別仕入先テーブル」の例では
製品別部品別仕入先=製品ID+部品ID+仕入先ID
の主キーは、「製品ID+部品ID」で必要十分であるわけですが、あえてこれを主キーというかどうか、又、主キー宣言するかどうかということだと思います。

私は「主キーがない」のではなく「主キーはあるが、それを意識する必要がないし、主キー宣言も不要だ」と言うべきだと思っています。
    • good
    • 0
この回答へのお礼

どうもありがとうございました.
主キーひとつとってみてもなかなか深いなぁと,
考えさせられました.

お礼日時:2001/08/26 11:11

あまり具体的な例をあげることができませんが。



通常、RDBは「1:n」や「m:1」となります。
が、「m:n」を設ける必要がある場合、実際には「中間テーブル」を作成し、
「1:n」と「m:1」の関係を作成します。
このときの「中間テーブル」が、外部キーを持ち主キーが存在しない、では
なかったかな?
    • good
    • 0
この回答へのお礼

最初この回答を読んだときなんのことかわからなかったのですが,皆さんの回答をあわせて読んでいくうちにわかってきました.
どうもありがとうございました.

お礼日時:2001/08/26 10:56

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QCREATE テーブルでの複数外部キーの設定

MySQL5.1で、1つの表に複数の外部キーを持つとき、
CREATEテーブル発行の仕方について教えてください。

1、以下表3つ作成
得意先表
{得意先コード(主),得意先名}

注文表
{年月日,得意先コード(外),商品コード(外),数量}
※得意先コード、商品コードに、on delete cascadeをつける。

商品表
{商品コード(主),商品名,商品区分コード(外),単価}

の三つの表があります。


質問)、注文表に、2つの外部キー(得意先コード・商品コード)を設定したいと思っています。
CREATE TABLE IF NOT EXISTS `注文表` (
`注文日` date DEFAULT NULL,
`得意先コード` varchar(10) DEFAULT NULL REFERENCES 得意先表(得意先コード) on delete cascade,
`商品コード` varchar(10) DEFAULT NULL REFERENCES 商品表(商品コード) on delete cascade,
`数量` int(11) DEFAULT NULL
)

の外部キーを列制約で作成するのがいいのでしょうか?
表制約では、二つの外部キーを設定できないと思いましたので・・・。

ご教授お願いします。

MySQL5.1で、1つの表に複数の外部キーを持つとき、
CREATEテーブル発行の仕方について教えてください。

1、以下表3つ作成
得意先表
{得意先コード(主),得意先名}

注文表
{年月日,得意先コード(外),商品コード(外),数量}
※得意先コード、商品コードに、on delete cascadeをつける。

商品表
{商品コード(主),商品名,商品区分コード(外),単価}

の三つの表があります。


質問)、注文表に、2つの外部キー(得意先コード・商品コード)を設定したいと思っています。
CREATE TABLE IF NOT EXISTS `注文表` (
`注文...続きを読む

Aベストアンサー

表制約でも出来ますよ。
CREATE TABLE `注文表`
(
`注文日` date DEFAULT NULL,
`得意先コード` varchar(10) DEFAULT NULL ,
`商品コード` varchar(10) DEFAULT NULL ,
`数量` int(11) DEFAULT NULL,
FOREIGN KEY( `得意先コード` ) REFERENCES 得意先表(得意先コード),
FOREIGN KEY( `商品コード` ) REFERENCES 商品表(商品コード)
);

QAccessから主キーの無いOracleテーブルにVBAで主キー設定付のODBC接続するには

Oracle7--------------- Access97
Workgroup Server
Release 7.3.2.2.1

TABLE_A----------------ODBC接続(リンクテーブル)    
項目1
項目2
項目3
項目4

項目1~項目4は
空白レコードがあり
主KEYが張れない

********************************************************************
主キーの作成出来ないオラクルテーブルがあります。

Access97からODBC接続を作成する時は

(1)マニュアルであれば
  対象テーブルに主キーが無ければ
任意の10項目を仮の主キーとして設定出来ますが

(2)VBA(自動?)で リンク張ると

Dim tab01 As TableDef
 Dim db01 As Database
 Dim strTABname As String

strTABname = TABLE名
Set db01 = CurrentDb
Set tab01 = db01.CreateTableDef(UserName & "_" & strTABname, dbAttachSavePWD)
tab01.SourceTableName = UserName & "." & strTABname
tab01.CONNECT = "ODBC;DSN=****;UID=" & UserName & ";PWD=" & Password & ";ConnectString=con;"
db01.TableDefs.Append tab01

主キー設定の無いODBC接続が出来て
  データの更新などが出来なくなります。

VBAでも仮の主キー設定付きのODBC接続は
 出来ないでしょうか?

Oracle7--------------- Access97
Workgroup Server
Release 7.3.2.2.1

TABLE_A----------------ODBC接続(リンクテーブル)    
項目1
項目2
項目3
項目4

項目1~項目4は
空白レコードがあり
主KEYが張れない

********************************************************************
主キーの作成出来ないオラクルテーブルがあります。

Access97からODBC接続を作成する時は

(1)マニュアルであれば
  対象テーブルに主キーが無ければ
任...続きを読む

Aベストアンサー

手元にACC97は無いのですが、擬似インデックスを作成すれば可能だったはず。

作成方法は通常のINDEX作成と変わりはありません。

db01.Execute "CREATE INDEX ・・・・;"

QMySQLの外部キーの設定について

はじめまして。
質問があります。
MySQLを使用しているのですが、以下を見てください。
----------------------------------------------------------------
mysql> create table vendors
-> (
-> vend_id char(10) NOT NULL,
-> vend_name char(50) NOT NULL,
-> vend_zip char(10),
-> vend_state char(10),
-> vend_city char(50),
-> vend_address char(50),
-> primary key(vend_id)
-> ) TYPE=MyISAM;
Query OK, 0 rows affected (0.38 sec)

mysql> create table products
-> (
-> prod_id char(10) NOT NULL,
-> vend_id char(10) NOT NULL,
-> prod_name char(255) NOT NULL,
-> prod_price decimal(8,0) NOT NULL,
-> prod_desc blob,
-> primary key(prod_id),
-> foreign key(vend_id) references vendors(vend_id)
-> ) TYPE=MyISAM;
Query OK, 0 rows affected (0.05 sec)
----------------------------------------------------------------
外部キーを設定したつもりなのですが、desc productsを実行すると
キーフィールドに「pri」と表示されているので、主キーが
設定されていることが確認できるのですが、外部キーが設定されて
いることは確認できません。外部キーは設定されているのでしょうか?
もし設定されていないのなら、どのようにすればよいのでしょうか?
また、外部キーが設定されていることを確認するにはどうすれば
よいでしょうか?ご教授お願いします。

はじめまして。
質問があります。
MySQLを使用しているのですが、以下を見てください。
----------------------------------------------------------------
mysql> create table vendors
-> (
-> vend_id char(10) NOT NULL,
-> vend_name char(50) NOT NULL,
-> vend_zip char(10),
-> vend_state char(10),
-> vend_city char(50),
-> vend_address char(50),
-> primary key(vend_id)
-> ) TYPE=MyISAM;
Query OK, 0 rows affected (0.3...続きを読む

Aベストアンサー

MySQLのバージョンが不明なので、
私が使っていた4.1では、MyIsamに対してFOREIGN KEY制約
はつけることができませんでした。
参照先・元共にInnoDBでないとだめです。
下の参考URLに記載されています。

また、参照方法ですが、参考URLの一番下にある
SHOW TABLE STATUS FROM yourdatabasename LIKE 'T'
このコマンドで参照することができるのではないでしょうか?

参考URL:http://dev.mysql.com/doc/refman/4.1/ja/innodb-foreign-key-constraints.html

Qテーブルの主キーをdate型にする

DBのテーブル設計で主キーを日付にしたい場合、
日付型を使用せずに数値or文字列で設定する場合がほとんどなのですが、
その理由が「なんとなく安定性がありそうだから」
というくらいでしかありません。

もしかしたら過去に「~~という理由だから」と教えられているかもしれませんが、
それもいまいち思い出せず・・・^^;


今すぐどうこうしたいという内容ではなく、
ちょっとした疑問ですが、
もしご存じでしたらご教授お願いします。

Aベストアンサー

個人的には date 型でも特に問題ないのではないか、と思っていま
すが、どうでしょうか。
(そもそも主キーに日付、というのパターンをあまりみたことが
 ないのでよくわかりません)
時刻まで含めたいのか、時刻は不要なのかによっても変わってき
ますが、ここは時刻はいらいない、として考えてみます。

また、使用するRDBMSによっても変わってくるはずです。
たとえばOracleの場合を比較してみると、
http://biz.rivus.jp/data_type_inside.html
(1)サイズ
  DATE型・・・7バイト
  NUMBER型・・6バイト
  CHAR型・・・8バイト
  NUMBER型がいいですが、どんぐりの背比べです。
(2)検索スピード
  =を指定したときの検索スピードは、当然インデックスが使
  われますから、どれにしても問題ないぐらい高速で、どれで
  もいいでしょう。それ以外の検索は要件に応じて、どれが早い、
  とはいちがいにはいえないと思います。可変長項目をプライマリ
  キーにすると検索が遅い、というのはきいたことがありますが、
  この場合は全部固定長ですね。


結論としては、検索の用途に応じて、実際にやりたい検索でスピード
をためしてみて決める、というところでしょうか。
RDBMSによって内部形式もちがいますし、一般的にどう、とは
いえないと思います。やりたい検索が決められなければ、DATE
関連に特化した関数がいろいろ使える(このへんもRDBMSに
よってちがいますが)、DATE型が無難かと思います。

個人的には date 型でも特に問題ないのではないか、と思っていま
すが、どうでしょうか。
(そもそも主キーに日付、というのパターンをあまりみたことが
 ないのでよくわかりません)
時刻まで含めたいのか、時刻は不要なのかによっても変わってき
ますが、ここは時刻はいらいない、として考えてみます。

また、使用するRDBMSによっても変わってくるはずです。
たとえばOracleの場合を比較してみると、
http://biz.rivus.jp/data_type_inside.html
(1)サイズ
  DATE型・・・7バイト
  ...続きを読む

Qリレーションシップと外部キー制約について

■最終的にやりたいこと
・なるべくコード(SELECT文など)を見ずに、「DB」「テーブル定義者」「ER図」等からテーブル間の関係性を把握したい


■具体例
・投稿一覧。「userテーブル」「postテーブル」
・「postテーブル」の「user_id」カラムは、「userテーブル」の「id」カラムに対応
※簡易な場合はある程度想像は付くのですが、ちょっと複雑な構成になると途端に苦労するので、何か良い方法はないかと思い、質問しました


■質問
◆「リレーションシップを組む」際、「外部キー制約」はかけるのでしょうか?
例えば、上記「投稿一覧」DBを構築する際では、どうするのでしょうか?
1.普通、「外部キー制約」をかける
2.普通、「外部キー制約」をかけない
3.どちらでも良い

◆「外部キー制約」は何の為にかけるのでしょうか?
・「SELECT&JOIN」でデータ取得出来るのであれば、「外部キー制約」と「リレーションシップ構築」に関係性はないと思うのですが、そういう認識で合っているでしょうか?
・参照先データが削除されたら整合性がとれなくなる場合のみかけるものでしょうか?

◆「リレーションシップを確認」する目的で、「外部キー制約」をかけても良いのでしょうか?
・「データ削除の整合性」ではなく、「リレーションシップを確認」する目的で外部キー制約」をかけても良いのでしょうか?

◆「外部キー制約」以外に、「リレーションシップを確認」する方法はあるのでしょうか?
・コード(SELECT文など)を見ずに、テーブル間の「リレーションシップを確認」する方法としては、「外部キー制約」以外に何かあるのでしょうか?
・そもそも、「外部キー制約確認」=「リレーションシップ確認」という考えは正しいのでしょうか?

■最終的にやりたいこと
・なるべくコード(SELECT文など)を見ずに、「DB」「テーブル定義者」「ER図」等からテーブル間の関係性を把握したい


■具体例
・投稿一覧。「userテーブル」「postテーブル」
・「postテーブル」の「user_id」カラムは、「userテーブル」の「id」カラムに対応
※簡易な場合はある程度想像は付くのですが、ちょっと複雑な構成になると途端に苦労するので、何か良い方法はないかと思い、質問しました


■質問
◆「リレーションシップを組む」際、「外部キー制約」はかけるのでしょうか?
例え...続きを読む

Aベストアンサー

 えらく、外部キー制約に拘っているように見えますが、外部キー制約は、テーブル間の関係の一例でしかありません。

 「最終的にやりたいこと」の文章がすごく象徴的です。
 というのは、完成したER図というのは、実体に対して、これをデータベースでどのように表現したかを全て記した図です。 この図には、全てのテーブル・その属性・そしてテーブル間の関係が全部表現されています。(ていうか、全部表現されていなければ、そのER図は未完成です。)
 省略せずに全てが書かれたER図を見れば、テーブル定義書は機械的に完成しますし、DBの実体もやはり機械的に完成します。

 テーブル間の関係が少し複雑になってくると、関係が見えなくなる。理解できなくなるのは誰でも同じです。これをわかりやすく整理して、誰にでも(設計している途中の自分にも)紛れなく解るようにするためにER図を書く。
 これがER図の目的です。
 (間違っても、クライアントの要求に応じて、仕方なく、システムが全部完成した後で、完成図書を作成する事務作業の一部として作成する物では断じてありません。)
 
 さて、こうして書かれたER図があるのに・・・「「ER図」等からテーブル間の関係性を把握したい」とはどういうことか?
 少なくとも、設計作業の一部としてちゃんと作成したER図があれば、これを見てテーブル間の関係が解らないなんてあり得ません。(本当に解らなければ、それはER図が間違っています。)
 複雑すぎて、ER図が理解できないというのなら解ります。その場合は、きっと、何を見ても理解できないでしょう。もはや解っている人に、実体の説明からレクチャーしてもらうしかありません。

 さて、外部キー制約とは、外部キーの要件を満たす様にデータが入力されることを、システムとして強制するために作成します。(NULLが絶対に入っていないことをシステムとして強制するためにNOT NULL制約をつけるのと全く同じです。)
 したがって、外部キーで無いものに外部キー制約をかけてはいけません。
 また、外部キー制約はデータ削除の整合性を取るためにつけるものでもありません。外部キー制約をつけたテーブルで、データが削除された時に外部キーの要件を満たさなくなるデータを自動的に連鎖削除するオプション機能はありますが、これは単なる便利機能です。
 本来の機能は、NOT NULL制約の付いた要素をNULLにしようとすると、エラーではじかれるのと同じで、外部キー制約を満たさなくなる追加・更新・削除の操作をしようとするとエラーではじかれることになります。

>・コード(SELECT文など)を見ずに、テーブル間の「リレーションシップを確認」する方法としては、「外部キー制約」以外に何かあるのでしょうか?
 
 このコードを書く時に、テーブル間の関係を理解するために、ER図を書いておくんです。ER図がなかったら、そもそも、このコードが書けません。(まぁ、世の中には、ER図は制作者の頭の中だけに存在するという事例は山とありますけどね(苦笑))
 最終目的に対して、質問が本末転倒になっているのがわかりますか?

 

 えらく、外部キー制約に拘っているように見えますが、外部キー制約は、テーブル間の関係の一例でしかありません。

 「最終的にやりたいこと」の文章がすごく象徴的です。
 というのは、完成したER図というのは、実体に対して、これをデータベースでどのように表現したかを全て記した図です。 この図には、全てのテーブル・その属性・そしてテーブル間の関係が全部表現されています。(ていうか、全部表現されていなければ、そのER図は未完成です。)
 省略せずに全てが書かれたER図を見れば、テーブ...続きを読む

Qデータベースウィンドウを表示しないで、データベースウィンドウを更新する

http://support.microsoft.com/kb/304256/ja
マイクロソフト技術情報で、RefreshDatabaseWindow メソッド は、 Access2000形式で保存されたプロジェクト(ADP)で動作しませんと出ており、データベースオブジェクトの作成、削除、または名前の変更が行われた後で、データベース ウィンドウを更新する処理が、データベースウィンドウを表示している状態でしか更新できません。データベースウィンドウが表示されていない状態で、データ入力フォームが表示されて、何かの処理がされたときにデータベースウィンドウを最新の状態に更新したい場合、何か方法をご存知の方いらっしゃいましたらご指導ください。
テーブル作成をした後、テーブルにアクセスする処理をしようとするとテーブルがないため、エラーになってしまうことがあるのですが、一時的にデータベースウィンドウを表示させてF5を押下して最新にして作成したテーブルが表示されるとエラーは発生しません。

Aベストアンサー

こんにちは、
どうしてデータベースウィンドウが表示されていてはいけないのか、わかりませんが、
処理の実行中に
画面の描画をストップさせて、データベースウィンドウ
を表示→処理→データベースウィンドウを非表示→
画面の描画をスタートさせてはいかがでしょうか。

参考URL:http://oshiete1.goo.ne.jp/kotaeru.php3?q=2229389

Q参照整合性制約と外部キー

FOREIGN KEYは、外部キー制約になるのでしょうか?
FOREIGN KEYは、参照整合制約になるのでしょうか?

参照整合制約は、FOREIGN KEYで、その制約を成り立たせるために、外部キーがあるとおもっているのですが間違ってないでしょうか?

ご教授お願いします。

Aベストアンサー

「外部キー制約」と「参照整合制約」は同じものと考えて良いと思いますよ。
実現方法に注目しているか、実現する内容に注目しているかの差でしょうか。
「タプル」を「行」や「レコード」と言うことも有りますが、それと同じようなことかと。

また「参照整合制約を成り立たせるために外部キーがある」という認識も合っていますよ。

Qテーブル作成クエリで主キーを設定

サブフォーム作成のため主キーを設定したいのですが、クエリでグループ化した顧客コードをテーブルとするクエリで主キーを顧客コードに設定したいのですが、クエリ実行で主キー設定方法を教えてください。

Aベストアンサー

テーブル作成クエリ実行後、
DAO で CreateIndex ということになると思います。

おそらく、ワークテーブルで編集し、
元のテーブルに書き戻すような処理をお考えだと思いますが、
あらかじめ、主キーを設定したテーブルを作成しておき、
削除クエリで、全レコード削除、
テーブル作成クエリを追加クエリに変更したもので、
新しいレコードを追加する、
という処理で置き換えられませんか?

Access であるとして、
テーブルの作成、削除を繰り返すと、
MDB ファイルの破損につながりますので。

見当違いだったら無視してください。

Q外部キーの設定方法について

外部キーの設定方法について
テーブルCのカラムCについて、テーブルAのカラムA、またはテーブルBのカラムBにある値しか受け付けないように、外部キーの設定を行いたいのですが、方法が分かりません。

テーブルAのカラムAとテーブルBのカラムBとをUNION したビューを作成してみましたが、ビューにはプライマリィキーを設定することが出来なく、外部キーは作成できませんでした。

何か、回避策を教えてください。
よろしくお願いします。

データベースは、ANSI標準サポートのタイプとして、考えてください。

Aベストアンサー

ど素人の私が答えるのもなんですが、

テーブルAとテーブルBのインサート時にテーブルXに同じデータを登録しておくというのはいかがでしょうか?

Q主キーが二つのテーブルのselect方法

SQL文に関して質問します。
主キーが二つあるテーブルを作成したのですが。
[table_A]
ID | SubID | Name
1 | 0 | pochi
1 | 1 | tama
2 | 0 | koma
3 | 0 | koro
3 | 1 | shiro
4 | 0 | buchu
このテーブルから、IDが二つ以上あるものに関してはSubIDの大きいほうのレコードだけ取得して
ID | SubID | Name
1 | 1 | tama
2 | 0 | koma
3 | 1 | shiro
4 | 0 | buchu
という結果を出したのですが、select文が思いつきません。
副問い合わせも考えたのですが、うまくいきませんでした。
ちなみにRDBSはSQLServer2000を使用しています。

よろしくお願いします。

Aベストアンサー

下記でどうでしょ?
手元に環境が無いので確認はしてませんが。

SELECT t1.*
FROM table_A as t1, (SELECT ID,max(SubID) as xSID FROM table_A GROUP BY ID) as t2
WHERE t1.ID=t2.ID and t1.SubID=t2.xSID;


人気Q&Aランキング

おすすめ情報