ここの内容に関しての質問を歓迎します。斎藤末広まで。当ページの内容をご利用した方は,末広ページご利用の案内を参照して下さい。
データモデルには階層モデル、ネットワークモデル、関係モデルの三つがある。このうちの階層モデルに関する説明として、正しいものはどれか。
ア あるレコードに対して、複数の親レコードがありうる。
イ データをいくつかの 2 次元テーブルによって表現するデータモデルである。
ウ 網状の構造をもつ対象を表現するときの記述は、冗長となる。
エ レコード間の関係付けはあらかじめ設計する必要はなく、データ操作の中で動的に行うことができる。
現在、データモデルと言えば、関係モデルです。しかし、銀行のオンラインなど、過去のソフトを利用することで、品質とスピードが確保されますので、階層モデル、網モデルが利用されています。
出題の傾向として,当面,関係モデルが一番大きく,徐々にオブジェクト指向型データベースが増えると思います。
ア:網モデル
イ:関係モデル
ウ:階層モデル
エ:関係モデル
オブジェクト指向におけるインヘリタンスに関する記述として、正しいものはどれか。
ア あるクラスの下にサブクラスを定義するとき、上のクラスで定義されたメソッドとデータをサブクラスで引き継いで使うことができる。
イ オブジェクトの性格を決めるデータ構造や値を隠ぺいし、オブジェクトを外部から直接アクセスすることを禁止する
ウ オブジェクトのデータ構造や処理方法を変更した場合、外部への影響を避けることができ、オブジェクトの独立性を向上させることができる。
エ 同一のデータ構造と同一の手続きをもつオブジェクトをまとめて表現したものである。
>ア:インヘリタンス(継承)の説明
>イ:カプセル化(隠蔽)の説明
>ウ:オブジェクト指向の利点の説明
>エ:クラスの説明?
どうもありがとうございました。エは,クラスの説明ですね。
>イ:カプセル化のこと
>ウ:オブジェクト指向始めとする、DOA概念の目的
>エ:クラスのこと
どうもありがとうございました。
オブジェクト指向は,ますます普及していくでしょう。試験問題でたら,必ず解ける分野にしておきましょう
関係データベースにおいて,第1正規形,第2正規形,第3正規形と,正規化を進めることによって得られる効果はどれか。
ア データベースの検索性能をより向上させることができる。
イ データベースの冗長性と矛盾を避けることができる。
ウ データベースのセキュリティを高めることができる。
エ テーブルの数を減らすことができる。
ア:たいていは言えます。
イ:これが完全に正しいです。これが,正規化の目的の一つです。
ウ:セキュリティに関してはあまり関係がありません。
エ:逆です。正規化をするとまず,増えます。
>一般的に正規化により検索性能は落ち、テーブル数は増える。セキュリティには
>関係ない。
こうはなかなか言い切れませんが,だいたいのところはそうですね。
>[jhomework]
980911-sai の高度共通・一種向け問題より:
>データを正規化する目的
> エンティティに属するデータ項目の明確化
> エンティティの識別
> データの冗長性の排除
> データの整合性の保持
どうもありがとうございました。
>翌日の解説より:
>>> テーブルが分割されると、むしろ処理時間は長くなります。しかしそれを補う
>>>だけの効果が正規化にはあるのです。
どうもありがとうございました。
>第n正規化 について、[jhomework] 981021
より:
>第1正規化・・・繰り返しグループを除去する。(1対多の子探し)
>第2正規化・・・一意識別子の一部のみに依存している属性を除去します。
> (1対多の親探し)
>第3正規化・・・一意識別子でない属性に依存する属性を除去します。(親探し)
どうもありがとうございました。
関係データベースのあるテーブルの主キーが、別のテーブルの外部キーとして定義されている場合、行(レコード)の追加・削除の操作の制限について、正しい組み合わせはどれか。次の表の中で△印は、主キーと外部キーに同一の値があるか無いかによって、操作に制限が生じることを表し、○印は、主キーと外部キーの値に無関係に操作できることを表す。
|
|
主キー側の行の追加 |
主キー側の行の削除 |
外部キー側の行の追加 |
外部キー側の行の削除 |
|
ア |
△ |
○ |
○ |
△ |
|
イ |
○ |
△ |
△ |
○ |
|
ウ |
○ |
△ |
○ |
△ |
|
エ |
△ |
○ |
△ |
○ |
例として,商品台帳,売上表を考えます。
商品台帳
|
商品コード |
商品名 |
仕入れ単価 |
仕入先コード |
|
1020 |
○○フライ |
78 |
950023 |
|
1021 |
△あめ |
85 |
586632 |
|
1022 |
××チョコ |
25 |
456521 |
売上表
|
売上明細コード |
商品コード |
売上数量 |
|
19990101001 |
1021 |
100 |
|
19990101002 |
1022 |
54 |
|
19990101003 |
5211 |
12 |
|
19990101005 |
1122 |
58 |
この例の場合,商品台帳の主キーは,「商品コード」で,売上表の主キーは,「売上明細コード」です。売上表には,「商品コード」が含まれています。売上表に含まれる「商品コード」は,売上表から外部を参照するためのキーで,外部キーと言われます。売上表の「商品コード」に入る値は,商品台帳の主キーである「商品コード」に存在する必要があります。この制約を「外部キー制約」といいます。
この問題は,外部キー制約の知識を問う問題でした。
売上表(外部キー側)に行を追加する場合,売上台帳(主キー側)にその商品コードが存在しなくてはいけません。よって,外部キー側の行の追加には,制約がありますので,イ,エのどちらかになります。
また,商品台帳(主キー側)は,削除するときには,それが売上表にある商品の場合,勝手に削除すると矛盾を生じることになります。よって,主キー側の削除は制約があります。解答はイであることが分かります。
売上表の削除,また,商品台帳の追加は制約はうけません。
関係データベースにおけるインデックス設定に関する記述として,正しいものはどれか。
ア インデックスの設定に際しては,検索条件の検討だけでなく,テーブル全体サイズについても考慮も必要である。
イ インデックスの設定によって検索性能が向上する場合は,更新・削除・追加の性能も必ず向上する。
ウ インデックスの設定は,論理設計時点で洗い出された検索条件に指定されるすべての列について行う必要がある。
エ 性別のように 2 値しか持たないような列でも,検索条件に頻繁に指定する場合は,インデックスの設定を行う方がよい。
>ウでしょうか?
>ここでのインデックス設定とは主キーの事を言っているのでしょうか?
違います。RDBの場合は,好きな列をキー(検索用)として設定できます。
その場合は,重複した値でも構いません。レコード(行)を特定できるキー,それを候補キーといいます。表を定義するときに,その候補キーのうちから,主キーを一つ選びます。主キーによって,その表が整理されることになります。
>ア:テーブルサイズが大きければインデックスの作成に時間が掛かるので〇
>イ:更新・削除・追加をした後インデックスを再編成するので時間は長くなる。
>ウ:すべての列に行うと処理時間がかかるのでは?
>エ:あまり意味がないように思います。男女に比率が0.5だと総レコード数の半分が検索したときに残ってしまいます。
どうもありがとうございました。ウの作業をすると追加,削除のときに時間がかかり実用的ではありません。必要に応じてインデックスの設定をします。
>インデックス機能は、高速の検索ができる分、インデックスの情報も付加
>しなくてはならないため、テーブルサイズが大きいと、かえって情報量が
>増えてしまうことになります。(最近、Accessの講習会で学びました。)
>そのため、アを選択したのですが、これが正しいのでしょうか?
正しいです。ただ,量が増える弊害より,スピードのダウンでしょうね。
>(ITEC「読む講義シリーズ5」P170参考にして)
> まとめると、
>インデックスを設定しない方がよい場合は
> ・表の行数が少ない表。
> ・頻繁に変更のあるもの。
> ・属性の値の種類が少ないもの。
> ・属性の値の種類が多くとも、値に偏りがあるもの。
> インデックスを設定した方がよい場合、
> ・主キー
> ・検索に使用する属性、または属性の組み合わせ
> ・外部キー
どうもありがとうございました。
次のようなデータ項目をもつ仕入台帳を関係データベースとして構築することにした。データ項目をどのようにまとめ、テーブルにするのが最も適切か。ここで、データベースは次の業務要件を満たす必要がある。
(1) 検索結果は、商品コード又は仕入先コードごとに出力する。
(2) 一つの仕入先からの複数の商品を仕入れることに対応できる。また、一つの商品を複数の仕入先から仕入れることに対応できる。
(3) 仕入先が変わっても商品の単価は変わらない。
[仕入台帳のデータ項目]
|
商品コード |
商品名 |
単価 |
仕入先コード |
仕入先社名 |
仕入先住所 |
ア
|
商品コード |
商品名 |
単価 |
仕入先コード |
|
仕入先コード |
仕入先社名 |
仕入先住所 |
イ
|
商品コード |
商品名 |
単価 |
|
商品コード |
仕入先コード |
仕入先社名 |
仕入先住所 |
ウ
|
商品コード |
商品名 |
単価 |
|
商品コード |
仕入先コード |
|
仕入先コード |
仕入先社名 |
仕入先住所 |
エ
|
商品コード |
商品名 |
|
商品コード |
単価 |
|
商品コード |
仕入先コード |
|
仕入先コード |
仕入先名 |
|
仕入先コード |
仕入先住所 |
先ず,このまま単純に表を持ってしますと,2つ目の用件「一つの商品を複数の仕入先」を実現するためには,商品コードと仕入先コードの対応ごとに,一つ行を持つ必要があるので,そのつど,商品名,単価,仕入先社名,仕入先住所も保持してしまいます。それは無駄です。
|
商品コード |
商品名 |
単価 |
仕入先コード |
仕入先社名 |
仕入先住所 |
この無駄を省くため,この表から,(商品コード,仕入先コード),(商品コード,商品名,単価),(仕入先コード,仕入先社名,仕入先住所)に分離した方がいいです。
この分類は,用件を全て満たすので,ウでいいことになります。
問題文とは違いますが,一般的に単価(この場合は仕入れ単価)は,仕入先が変われば変わりますので,(商品コード,仕入先コード,単価)の表と,商品コードを主キーにした商品マスタ,仕入先コードを主キーとした仕入先マスタに分類するのがいいでしょう。
次のSQL分によって”会員”テーブルから新たに得られるテーブルはどれか。
[ SQL 文 ]
SELECT AVG (年齢)
FROM 会員
GROUP BY グループ
HAVING COUNT
(*) > 1
会員
|
会員番号 |
年齢 |
グループ |
|
001 |
20 |
B |
|
002 |
30 |
C |
|
003 |
60 |
A |
|
004 |
40 |
C |
|
005 |
40 |
B |
|
006 |
50 |
C |
ア
|
AVG(年齢) |
|
36 |
イ
|
AVG(年齢) |
|
40 |
ウ
|
AVG(年齢) |
|
30 |
|
40 |
エ
|
AVG(年齢) |
|
60 |
|
30 |
|
40 |
SQL 文を解読すると,「会員」表件数が1より大きい「グループ」でグループ化して,「年齢」の平均を求めるです。
グループ A は,件数が1件ですので,省きます。B グループ,C グループの平均は,30, 40 ですので,解答はウとなります。
ここで,グループの平均で,B グループ,C グループの順で表示されてきていますが,具体的な SQL においてはどうでしょうか?。
オリジナルデータベース(オリジナル DB)と同じ内容のデータベース(コピー DB)をあらかじめ用意しておき、オリジナル DB が更新されると、独立のプロセスが指定された一定時間後にその内容をコピー DB に反映させる手法はどれか。
ア 2相コミットメント
イ イメージコピー
ウ ミラーリング
エ レプリケーション
>ウのミラーリングとエのレプリケーションは同じような意味だと思うのですが
>以下のような区別をすればよいのでしょうか?
>ミラーリング:サーバ全体を別のサーバにコピーする
>レプリケーション:サーバの一部(例えばDBだけとか)を別サーバにコピーする
そんな感じでいいと思います。レプリケーションは意味がある単位で複製で,ミラーリングの方は,訳も分からずに複製するという感じですね。
>レプリケーション(replication)
>データベースを別のサーバーに複製する機能のこと。更新の際には
>一時的にDB間の不一致が生じるため、不一致状態の管理と、定期
>的に内容を一致させる機構が必要である。
>(合格情報処理8月号付録 「情報システム辞典」より)
どうもありがとうございました。
>「2相コミット」は全体を一括して同期を取り、「レプリケーション」は一定間隔
>を開けて同期を取る、という理解で大丈夫ですか?
更新のつど,同期が取るのが2相コミットです。レプリケーションの方の理解はそれでいいでしょう。
>レプリケーションは PC や UNIX の DBMS
では一般的な機能ですが、
>汎用機の DBMS
ではあまりない機能なのでしょうか?
汎用機の世界も今風に使えば,レプリケーションはすると思います。分散データベースを実現すれば,レプリケーションは重要は要素です。
>> イ イメージコピー
>べたコピーのことでしょうか。
そうでしょう。
>ASCII Glossary Helpで調べました。
>http://www.ascii.co.jp/ghelp/22/2237.html
>オリジナルDBとコピーDBのどちらを先に更新するか等、
>問題文とGlossasry
Helpでの説明では異なりますが、様々な方式があると
>理解してよいのですか?
どうでしょうか? レプリカに対して更新をした場合,元データベースに対してどう更新するか,約束が必要ですね。
図は、2 相コミットメントプロトコルにおける正常処理の流れを示している。1 〜4 の組み合わせとして最適なものはどれか。
(図の挿入予定)
|
(1) |
(2) |
(3) |
(4) |
|
|
ア |
コミット可否問合せ |
コミット可応答 |
コミット実行指示 |
コミット実行応答 |
|
イ |
コミット実行指示 |
コミット実行応答 |
データベース更新指示 |
データベース更新応答 |
|
ウ |
ジャーナル取得指示 |
ジャーナル取得応答 |
コミット実行指示 |
コミット実行応答 |
|
エ |
データベース更新指示 |
データベース更新応答 |
メッセージ送信指示 |
メッセージ送信応答 |
2 相コミットは,複数のデータベースに対して同時更新を保証する手法です。それぞれのデータベースに対して,コミットが可能であるかを問い合わせ,それら全てが可能であると返事を貰ってから,それぞれにコミットの指示を出します。
データベース管理システムにおいて、図のような時間経過の中でシステム障害が発生した。ロールフォワードによって障害回復をしなければならないトランザクションはどれか。ここで、T2のトランザクションの終了処理前にシステム障害が発生したことを示している。
(図の挿入予定)
ア T1
イ T2
ウ T3
エ T2 と T3
システム障害発生時点で,コミットしていない T2 は,データベースに対してまだ値が反映されていません。よってデータベースに対して矛盾は発生しません。T2 に関しては単純な再処理でいいです。
T3 は,チェックポイント時からシステム障害発生時の間にコミット(終了)しているますので,回復をしないと矛盾が発生します。