DB設計について質問なんですが、テーブル1のA列を主キーとし、テーブル2のA列から外部キーでA列を参照したとします。
この時、テーブル2のA列を主キーとして設定することは可能なんでしょうか。
(テーブル2の方で列Aと列Bを組み合わせて主キーにしたいのです。要は二列でデータがユニークになるように設計したい)
使用しているDBはPostgreSQLです。

以上、宜しくお願い致します。

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

A 回答 (2件)

PostgresSQLでも下の解答と同様なことが可能です。

    • good
    • 0
この回答へのお礼

Postgreでも出来るんですね。
ありがとうございました。

お礼日時:2001/12/06 14:26

PostgreSQLができるかどうかは分かりませんが、Oracle、Accessなどはできます。


また、DB設計上も何も問題ありません。
Oracleの場合は、2つの列にプライマリキー制約を、外部キーにしたい列にフォーリンキー制約をそれぞれつけるだけです。
    • good
    • 0
この回答へのお礼

丁寧にありがとうございました。
これで何とか作れると思います。

お礼日時:2001/12/06 14:25

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

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

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

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

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

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

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 ・・・・;"

Q外部キーだけのテーブル(主キーがない?)

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

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

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

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

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

Aベストアンサー

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

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

ひとつの例でしたが、こんなもんでどうでしょう?

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

では、好例ではありませんが、一つ具体例をあげてみましょう。
日本語が下手でごめんなさい。よ~く読んで、ER図を書いてみてください。
とある組立工場を思い浮かべてください。そこで生産される製品の条件を以下とし...続きを読む

QDBアプリケーションの設計方針 (参照整合性、外部キーなどの制約はDDLで定義すべき?)

標記の件でご意見を伺いたく投稿します。
データベースにおいて、参照整合性、外部キーなど、レコードの整合性を守るのに不可欠な要素が
いくつかありますが、これらをDDLで定義するのと、フロントエンドのアプリケーションで実装する
のと、どちらが望ましいでしょうか?

世間で普及している教本等では、DDLで定義することになっているようですが、この辺りをきちんと
作り込んだ経験がありません。理由は以下の通りです。

(1) 制約でガチガチに縛ってしまうと、テストデータの作成に難儀する。
→ Access の場合、アプリケーションの画面が影も形もない段階で、テーブルのデータシート
ビューから直接データを投入できるが、制約で縛るとこの手軽さが失われてしまう。
(トリガを書けば、データは投入できるが、何だか余分な作業が増えて損をしたような気がする)

(2) データの整合性は保証できるものの、制約に違反した場合のエラーメッセージがユーザー
フレンドリーではない。

結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。

DDLで制約を定義しても、アプリケーション実装の作業負担は軽くならない。


そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。
Accessの場合、ド素人でもデータベースを直接GUIから操作できるので、設計者の意図に反して
データの整合性が損なわれるリスクはありますが、総合的に見て、DDLで制約を定義するメリット
を私はあまり感じません。

一般的にはどうなのでしょうか?
専門家の皆様のご意見をお待ちしております。

初心者ですので、わかりやすくご指導頂けると幸いです。(笑)

標記の件でご意見を伺いたく投稿します。
データベースにおいて、参照整合性、外部キーなど、レコードの整合性を守るのに不可欠な要素が
いくつかありますが、これらをDDLで定義するのと、フロントエンドのアプリケーションで実装する
のと、どちらが望ましいでしょうか?

世間で普及している教本等では、DDLで定義することになっているようですが、この辺りをきちんと
作り込んだ経験がありません。理由は以下の通りです。

(1) 制約でガチガチに縛ってしまうと、テストデータの作成に難儀する。
→ Ac...続きを読む

Aベストアンサー

>そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。

業務の種類によって対応はまちまちですが、
私も主キー、規定値、サイズくらいですかね。

>結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。

これも同意です。
アプリのほうでメッセージ出して、なおかつ通常のメッセージボックスはダメという要求が多い。
結局作りこむことになるのが現状

なおかつ、現在個人情報保護法等もあり、
データフィールドを個別に暗号化処理するようにしてしまったので、
基本の制約は意味を成さなくなってしまいました、

暗号化込みのデータベースが出ればまた使うかもしれないですが・・・

なので、最近に限って言えばほとんど使っていません。

Qアクセス2000で主キーとなる誤ってIDの列を削除

再びID列を作りオートナンバーにしたいのですが、途方にくれています。誰か教えてください。

Aベストアンサー

#1の補足です。
テーブルのフィールドが少なければ新規テーブルを作成、挿入しても良いのですが、多ければ再作成は手間がかかると思います。
#1のやり方以外でも、次の方法でできました。
こっちの方がいいかな。
1)元のテーブルをテーブル構造のみ複製する。(貼り付けるときに選択できる。)
2)ID列のデータ型をオートナンバーにする。
3)元のデータを挿入貼付する。
4)テーブルの名前を入れ替える。
5)動作確認後、元テーブルを削除する。

リンクなどは確認していませんが、テーブル自体は問題なく作れました。

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&Aを見た人がよく見るQ&A

人気Q&Aランキング

おすすめ情報