気になったので

11 04 2010
関係データベースの候補キーの説明として,適切なものはどれか[H12-DB 午前問50]

1値を空値(ナル)にすることはできない列又は列の組
2表の行を唯一に識別できる列又は列の組

2だそうで。




INと=ANYと=ALL

25 03 2010
INと=ANYは一緒 OR演算
NOT INと<>ALLも一緒 "いずれでもない"
=ALLは全てと一致でTRUE
<>ANYは全てと一致でFALSE

1 IN(1,2,4)=true
3 IN(1,2,4)=false
1 =ANY(1,2,4)=true
3 =ANY(1,2,4)=false
1 =ALL(1,1,1)=true
1 =ALL(1,2,4)=false
1 NOT IN(1,2,4)=false
3 NOT IN(1,2,4)=true

1 <>ANY(1,2,4)=true
3 <>ANY(1,2,4)=true
1 <>ANY(1,1,1)=false





ちょっとテスト

24 03 2010
[社員表]
社員番号 社員名 生年 担当部門 給料 階級
00001    織田 信夫    1943    001    250    003
00002    2武田 信二    1968    001    362    002
00003    3柴田 勝男    1970    003    3265    002
00004    4武田 信二    1943    002    325    001
00005    5武田 信二    1953    001    32    002
00006    6武田 信二    1954    001    65423    003
00007    7武田 信二    1962    002    132    003
00008    8武田 信二    1975    003    2    004
00009    9武田 信二    1961    003    12    002
00010    10武田 信二    1957    003    132456    004

[SQL]
CREATE VIEW 仮想社員表(社員番号,担当部門,給料) AS SELECT 社員番号,担当部門,給料 FROM 社員表 WHERE 生年>1960;
CREATE VIEW 第二社員表(社員番号,担当部門,給料) AS SELECT 社員番号,担当部門,給料 FROM 社員表 WHERE 階級=003;

[SQL]
SELECT a.社員番号,a.担当部門,a.給料 FROM 仮想社員表 a
INNER JOIN
第二社員表 b
ON a.社員番号=b.社員番号

[出力]
社員番号 担当部門 給料
00007    002    132

これは

[SQL]
SELECT * FROM 仮想社員表
INTERSECT
SELECT * FROM 第二社員表

と一緒になるはず





午後のデータベース 重要事項

22 03 2010
利便性のためにあえて第二正規形で放置。
[H19秋-SW 午後I問6][H17春-SW午後I問6]

データの整合性を守るためのロックの箇所を選ぶ問題
[H16-SW 午後I問6][H18春-SW 午後I問6]

連関エンティティを作る場合は
根っこをそのままにエンティティと矢印を分離、左右にひっぱって、間にエンティティを入れる!
連関エンティティは双方の主キーが連関Eの主キーになるとは限らない! 無駄は排除!
[H12-1K 午後問3][H15春-SW 午後I問6][H17秋-SW 午後I問6][H20春-SW 午後I問6]

テーブル名の別名が使われているにも関わらず定義されていない場合はSELECT文の中で定義する!
同様に,ASで別名が使われてない,別名に番号が振られているときは注意
設問でホスト関数が指定されている場合は絶対どっかで使う!
SELECT 文の穴埋めはレポート(明細書)もしくは設問に書かれてる抽出する項目に注目!
[H16春-SW 午後I問6][H20秋-SW 午後問6][H17春-SW午後I問6]

CREATE TABLE(
この中はDMLと違って区切りにコンマがいる!
社員コード CHAR(6),←これ
氏名 CHAR(20)
)
[H17 秋-SW 午後I問6]

副問合せの結果との照合が=になってて エラー探せとか出る。IN()とか=ANY()に直す!
逆に副問合せの結果との照合が=になっている場合はSELECT文にMAX()やMIN(),COUNT(),AVG(),SUM()などの可能性が高い!
GROUP BYが無くても集約関数は使える
[H11-1K 午後問3][H19春-SW 午後I問6]

副問合せの中の SELECT文が*になっている場合は相関副問合せの可能性が高い!
[H12-1K 午後問3]

販売明細に単価を入れる問題多し!
単価改定履歴を持つ場合と販売明細に単価属性を追加する場合がある。
単価改定履歴だと営業担当者が個別に単価を設定できないし,レコードが増える!
[RT @tm3242: @wizard_paso 単価改定の問題はやっておかないと、単価は何度も更新されるから更新日毎にレコードが増える。ってとこまで行くのに時間かかるよね。]
また,アクセス数を減らすために単価を入れたり
[H19春-SW 午後I問6][H21春-AP 午後I問6][H16春-SW 午後I問6][H17春-SW午後I問6]

データベース操作言語(DML) CREATE文などは確実に覚える。書けって言われます
INSERT,UPDATE,DELETE 文
[H17秋-SW 午後I問6]
UNION,UNION ALL,INNER JOIN,LEFT OUTER JOIN(LEFT JOIN)など
[H21春-AP 午後問6]
DECLARE CURSOR FOR,INTO:ホスト変数名 など
[H17春-SW午後I問6]
ORDER BY DESCも頻出

GROUP BY句を使った場合,SELECT文に指定できるのはGROUP BY句で指定したものか,集約関数のみ
逆手にとれば,GROUP BY句で指定されているものやSELECT文で指定されているものを推測できる
[H16 春-SW 午後I問6][H18秋-SW 午後問6][H21春-AP 午後問6]

正規化について
[H21秋-AP 午後問6]

列制約でPRIMARY KEYをつけることができるが,
複数のPRIMARY KEYを設定するときは必ず表制約で

    * [SQL] CREATE TABLE test(
    * a CHAR(10) PRIMARY KEY,
    * b CHAR(4) PRIMARY KEY
    * )
    * [Err] 1068 – Multiple primary key defined

[H17 秋-SW 午後I問6]

PRIMARY KEYには必然的にNOT NULLが含まれるので以下は冗長と思われる。実行は可能

    * CREATE TABLE test(
    * a CHAR(10) NOT NULL,
    * b CHAR(4) NOT NULL,
    * PRIMARY KEY(c,d)
    * )

[H17秋-SW 午後I問6]





データベースの単語とか

20 03 2010
RDA(Remote Database Access)…遠隔地にあるデータベースにアクセスするためのプロトコル
セミジョイン法…サイト間にまたがる表の結合演算の問合せの方式の一つ。他に入れ子ループ,マージジョイン,ハッシュセミジョインなど
レプリケーション…マスタデータベースと同じ内容の複製を他のサイトに決められた間隔ごとに複写する
2相コミットメント制御…キーワードはセキュア状態,ブロック状態。3相コミットメントのプリコメットも重要
OLAP(Online Analytical Processing)…多次元データベースの分析を行うためのツール
トリガ…更新前,更新後をきっかけとして他の動作を行う
データウェアハウス…データ項目の定義は,部門横断的に一元管理されている[14-SW39]

ストアドプロシージャ,データウェアハウス,データマート,データマイニング





データベース

20 03 2010
データの追加・変更・削除が少ないながら,一定の頻度で行われるデータベースがある。このデータベースのバックアップを磁気テープに採取するに当たって、バックアップ作業の間隔を今までの2倍にした。このときデータベースの運用に関する記述として,適切なものはどれか。[H17-春SW午前問49]

→ア  ジャーナル情報からの復旧処理時間が平均して約2倍になる。 

イ  データベースの容量が約2倍になる。 

ウ  バックアップ1回当たりの磁気テープ本数が約半分になる。 

エ  バックアップ採取の平均実行時間が約2倍になる。

RT @webdevjp: @wizard_paso (解説読んでないから自信ないんだけど)今まで1時間ごとにテープにとってた場合、いまから3時間30分後に故障したら3時間後のテープのバックアップ+30分のジャーナル情報で復旧可能。
RT @webdevjp: @wizard_paso 2時間ごとにした場合、いまから3時間30分後に故障したら2時間後のテープのバックアップ+1時間30分の分のジャーナル情報で復旧可能。ってことかな・・?要はバックアップ間隔を広げると、ジャーナル情報で復旧しなきゃいけない範囲が広がるってことかな・・?





SQL 参照制約

18 02 2010
RESTRICT…親の行を削除するとき子がいれば削除不可
CASCADE…親の行を削除するときこの行も削除
SET NULL…親の行を削除した時にこの行の外部キーにNULLを設定
SET DEFAULT…親のry
表定義の列制約または表制約の時にREFERENCES 表名  ON DELETE CASCADE ON UPDATE CASCADE
のように指定する。指定しなかった場合は自動でRESTRICTが指定される
RESTRICTは親の行を削除するとき子がいれば削除不可なので
つまり何も指定しなかった場合,自動的に子を先に削除しないといけないということになる

こういうこと
       追加     削除
子      ○      制約
親    制約      ○

子は社員表   親は役職表
役職表のs1は消せない
社員表に104 ぱそ s4は追加できない

社員表
社員コード    社員名         役職
100             元祖ぱそ          s3
101             戦士ぱそ          s1
102             魔術師ぱそ       s2
103             魔法戦士ぱそ    s3

役職表
役職コード     役職名
s1                戦士
s2                魔術師
s3                遊び人