［オブジェクト指向と情報処理試験 -2001年 春-］
ココが変だよ？ 情報処理試験
今年の春に行われました情報処理試験、皆さん、出来栄えはいかがだったでしょうか。
今回、答え合わせも兼ね(?)、オブジェクト指向に関する問題をピックアップして、あれこれツッコミをいれてみました。ケンケンガクガクの議論をお楽しみください。
なおコンテンツはオージス社内のWikiによって作られました。よって中にはスレッドが完結しきっていないものもありますが、続きは広場のMLでどうぞ。
資格別出題数は、
という結果でした。
 | 2001年 ソフトウェア開発技術者午後問題はこちらから |
(基本：午前・問46) (ソフト：午前・問48)
|
(コメント)
| nope | どれも納得いかないですけど、あえてひとつ選べばイですね。
ある対象(システム全体でも、プログラム中のオブジェクトでも、外部のファイルでも、隣の遠藤さんでも何でも良い)の取り得る状態と、状態の(イベントや、時間経過に伴う)移り変わりをあらわすものが状態遷移図では？ 少なくとも、(ある状態における)「動作を記述する」のが状態遷移図の本位ではないと思います。UMLの状態遷移図でも、状態の中のactivityを記述することはできますけどね。 |
| PaCman | まあ問題作成者の意図として、「状態」という語句を選択肢の記述の中に含めたくなかったのでしょうね。問題が簡単になると思ったのでしょう。
でも「状態」という語句を使わずに「状態遷移図」の説明をするというのは無理があるような…。しっくりこない選択肢しか書けない問題を選んだこと自体が問題？ |
| "動作"を各状態での動作、ではなく、好意的に"状態遷移"そのもののこと、と考えればまぁ、いいのでは。文章的にそうも読めますよ。 |
(基本：午前・問47)
|
(コメント)
| まぁエ。でも、文章はどことなくおかしいです。
「概念によって...局所化できる」とありますが、継承の概念だけではこうしたことの実現は不可能。「継承の機能によって」もしくはシンプルに「継承によって」ですね。 更に言えば、拡張の際には「変更」ではないのですから、「モデルの拡張や変更の際に変更部分を...」は、「モデルの拡張や変更の際に、追加・変更部分を...」でしょう。もっとも、これは細かすぎるか？ |
(DB：午前・問22)
|
(コメント)
| nope | 「オブジェクト指向データベースにおける」というふうに限定している意味がどこにあるのか今ひとつ不明ですが、まあいいでしょう。エです。 |
| Oracle でも OID があるんですよ、じつは。で、さらにオブジェクト参照というのもあって、これは結局OIDを使って JOIN するわけです。ということで、「オブジェクト指向データベースにおける」って言ってるんでしょう。じゃないと、イも正解になりますから。っていうかこんな問題つくるほうが間違ってる。 | |
| red sky | スピーカーさん、OIDがOracleにあるとのことですが、昔のOracle(8より前)でもあるのでしょうか？
Oracleは8からエンジンがORDB化されているんですよね？ |
| avi | エの"システム"が"DBMS"のことなら、エだと思いますが、OSなどもっと大きい意味でのシステム、の意味なら"DBMS"が知ることはできませんよね。
ってことで、"イ"に一票。"候補キー"ってのが、、、 |
| nope | ちょっと待った。"候補キー"は、「タプルを一意に持定することができる属性の組合わせ」なので、やはり変では?。("名前""生年月日")などとしたりするので。"主キー"ならまだしも。 |
| avi | ちゃうちゃう（関西風)
"候補キー"は「タプルを一意に持定することができる属性」だと思います("組み合わせ"ではないはず）。 でもって、"主キー"は"候補キー"のなかから意味のあるものを選んだものです("主キー"は"候補キー"を継承 :-) ) 問題はRDB と ODB のマッピングに関わるのでややこしいですが、私の認識ではODBにてオブジェクトを一意に認識できるものであればそれは関係データベースでの"候補キー"といってよく、OIDの他、属性値である社員番号なんかも"候補キー"といえます。ここであえて"主キー"としなかったあたりに出題者の渋さを感じたのですが、いかがでしょう？(なにを"主キー"にするかは開発者が決めるもので、OID = 主キー、とすると、DBMS開発者的にはよいが、アプリケーション開発者的には…) |
| えせスピーカー | red sky さん、そのとおり、Oracle8i からの機能です。このOracleのOIDはなんと、主キーをOIDとして利用できる、つまりユーザが直接指定できるのです。というわけで、RDBを含めてしまうと、エの回答にならなくなってしまいます。また、"システム"の記述ですが、ODBによってはメモリアドレスをOIDとして使っているものもあります。で、その場合、OSのページスワップのタイミングで２次記憶とのデータやり取りをしてます。なので、OSを含んでもよいのでは？ただ、"候補キー"は必ず属性の組み合わせである必要はないでしょう。主キーは候補キーのなかの一つなのですから。 |
| えせスピーカー | 自分はどう答えたかなぁ。ひとつ問題点を発見。候補キーは空値を許すけど、OIDは許しません。これをなんとする？ |
| スマイリー | 候補キーに空値がOKとは知りませんでしたが、この問題では"OIDはRDBの候補キーに相当"という話しであって、OIDが空値を許さない、というのはOIDそのもののお話し。そう取れば別に良いのでは。 |
| えせスピーカー | "相当"の考え方が微妙ですが、RDBの候補キーに定義されている特性をOIDが満たしているかと考えるのが普通でしょう。 |
| rope | これ以上は言葉の問題になりそうなので深入りは止めますが、"適切なもの"という題意からみて、そんなに"不適切"な記述ではないような、、、(鯨のひげは人間の歯に相当、、、なーんて)
それと候補キーに関してちょっと見ましたが、空値を許すというのはやっぱりないのですが。(候補キーが空値だと、一意に行を判別できなくなるので"候補キー"の定義から外れますよね。もっとも、空値が該当列中で唯一ならOKですが) |
| out | うーん、だからこういう問題は間違ってると思うんだけどなぁ。アとウは間違いだってすぐわかるけど、イとエのような微妙な場合はどちらがより適切"っぽい"かを考えるしかないような気がします。とすると、エのが適切っぽいかな。
あと、候補キーについて、少し前の話にもどりますが、候補キーは「タプルを一意に持定することができる属性の集合」であって、複数の属性から構成される候補キーには空値がはいることを許します。逆からいうと、キー制約として主キーは候補キーでかつ空値を許さないことであることからして、候補キーが空値をとりえるものとしているでしょう。 |
| pwd | (本題とは関係ない話です、、、)うーーん、やっぱり候補キーが空値OKってのが見つからない、、、どっか参照になるところ教えていただけますか？ |
| pwd | (ふと、気づく)よく読むと、"複数の属性から構成される候補キーには空値がはいることを許します"、ということだったのですね。
この場合、"複数の属性の集合＝候補キー"となるので、候補キーが空値、というわけではありませんよね。候補キーを構成する属性のひとつが空値なだけです。また、候補キーは極小集合でないといけないので、無制限に空値が許されるわけではありません(これは少し余談) で、話しはもどりますが、"複数の属性の集合"と"OID"が対応する関係と考えていただければ、OIDは空値を取らない、という前提のもとでも"OIDが RDB の候補キーに相当"というのもOKですよね(RDB的には候補キーである"複数の属性の集合"が空値であることまで許していないはずですから） |
| えせスピーカー | 候補キーが空値を許すって言うのは SQL92 からみたいですね。というのも、SQL92ではUNIQUE の指定の時にかならずしも NOTNULL 指定がいらない、つまり一意に識別される属性にもNULLが許されるということになっています。このあたりは、MySqlなりPostgresなりの文献を参照して下さい。つまりこれは候補キーに空値が許されることだと思うのですが。
で、また"相当"の定義にもどることになる。 |
| ？？？ | うーーん、"UNIQUE 指定時に NULL が許される"、という話しと、"候補キーにNULLが許される"ってのは別個の話しですよね。
UNIQUE 指定は、"その要素のもつ値が、テーブル中で唯一である"、ということを示すものであって、"その要素により、テーブル中の行を特定できる"、という意味ではないですから。 候補キーにとって、UNIQUE であることは必要条件ですが、十分条件ではありません。 ってことで、やっぱり "候補キーには空値は許されない"、と思います。 #候補キーの要素中、NULL値をとる行が唯一であれば、(数学的に空値っ て何を示す？、って話しもありますが)それはOKかもしれません :-) |
| ？？？ | ん、ということは、候補キーがNULL値であってもよい場合があるって言ってません？ |
| ？？？ | (まぁ、上の話しはあくまでいちびった余談ですので、、、一応説明します)
候補キーはその定義から、とあるテーブルRにおいてある属性Kが候補キーであるとは、２つの異なる行s, r に対して、s[K] != r[K] であることが条件とされています。 従って、属性Kにおいてnull 値が唯一であれば、この条件は満たされることになります。 この場合、
ってことで、スマイリーつきの余談として書いたものです。 なので、主張としては"候補キーには空値は許されない"、で、"この問題の答えとしてはイ"です。 |
| えせスピーカー | ちょっとまった、それは議論が飛躍し過ぎでしょう。長くなると思いますが、整理＆文献の紹介をします。すでにこのスレッドだけ非常に長くなってますけど、、。
まず、選択肢アとウについてはいいですね。全部について説明するのも大変なので。イとエについて、適切でないというポイントと適切であるというポイントをあげましょう。 では、私の主張：
イが適切でない点
エが適切である点
文献：
以上、ふぅ。 |
| ？？？ | こちらも一応、候補キーに関する記述も引用しておきます。
(https://www.ish.ic.kanagawa-it.ac.jp/sotsuken/R95/yamada/part3.html の 3.6 から) 引用 引用ここから----- R(A1,A2,…,An)をリレーションスキーマとし、K={Ak1,Ak2,…Akp}(1≦k1＜k2＜…＜kp≦n)を属性の集合とする。このときKがRの候補キー(candidate key)と呼ばれるのは次の二つの条件を満たすときである。
引用ここまで----- ということで、ここで強調したいのは、
|
| cwd | 普通にシステムととらえたときに、なぜ OS となるのかが疑問です。システムエンジニアとか、システムテストとかの"システム"ってOSじゃないと思いますけど。普通に考えれば個々のアプリケーションを統合したコンピュータで情報処理を行うしくみ全体となるのでは？
あと、 >システム(OS？)が管理しない何がしの数字をDBMS で OID として管理してもOK 上記の意味がよくわかりません。 |
(DB：午前・問49) (EB：午前・問49)
|
(コメント)
| 異機種分散環境上で、オブジェクトが互いに通信を行うための仕様ですね。
説明はなんかピントがずれてるけど、正解はア。 「機能単位に分割したアプリケーション(オブジェクト)」と言い切ってしまうところがすごい。 |
| © 2001 OGIS-RI Co., Ltd. |
|
