10月16日(木)3コマ目

今日、やったこと

  • データディクショナリ
  • テーブル作成

今日のホワイトボード

データディクショナリ

オラクルは稼働中のデータ(ユーザーやテーブルの情報など)を管理するために、テーブルを利用している。このようなデータ管理用テーブルをデータディクショナリと呼ぶ。

データディクショナリには命名パターンがある。

図　データディクショナリの命名パターン
良く使うのは

  • ユーザー一覧
  • テーブル一覧

の２つ。

図　ユーザー一覧のdba_users、テーブル一覧のuser_tables
dba_usersでユーザー一覧を確認。

図　dba_users検索結果

[前回のおさらい]ユーザー作成、システム権限付与

ユーザーjiroを作成し、システム権限を付与。
図　ユーザーjiro作成、システム権限付与

テーブル作成

テーブルは　create table　で、各列ごとに列名とデータ型を指定して作成。
図　テーブル作成
実際は、上記にオプションをいろいろと指定する。
図　商品マスタテーブル作成

作成した商品マスタテーブルにデータ登録して、全件検索。
図　データ登録、全件検索

データ型

テーブル作成時に各列のデータ型を指定する。
プログラミング言語と異なり、標準的なデータ型があるものの、データベース(厳密にはDBMS)毎に独自のデータ型を用意している。

〇文字型

C言語では、文字と文字列は別物扱いだが、データベースでは同じ扱い。
固定長　と　可変長　の2種類がある。
図　文字型

〇数値型

C言語では、整数型(int、long等)と実数型(float、double)と分かれているが、データベースでは同じ扱い。
図　数値型

テーブル一覧確認

データディクショナリ　user_tables　でログイン中のユーザーのテーブルを確認できる。
図　データディクショナリuser_tablesでテーブル一覧確認

ユーザー削除

ユーザーの削除は　drop user　で行う。
図　ユーザー削除
ただし、ユーザーがオブジェクト(テーブルとか)を持っている場合は、cascadeオプションが必要。
cascadeオプションはユーザー削除時に、ユーザースキーマも一緒に削除する。
図　ユーザー削除

[おまけ]DDLの基本パターン

作成は　create xxx、変更は　alter xxx、削除は　drop xxx。
図　DDLの基本パターン

次回は

テーブルのつづきと制約。












 



このブログの人気の投稿

10月30日(木)3コマ目

イメージ
今日、やったこと チェック制約 参照整合制約(外部キー制約) 今日のホワイトボード チェック制約(列制約構文) チェック制約 とは、 条件を満たすデータ以外は登録させないための制約 。 キーワード checkにつづく( )内に条件 を書く。 条件はwhere句と同じ。 図　チェック制約(列制約構文) 実際のSQLは以下のとおり。 ①商品マスタテーブル作成 列制約構文で、価格列にチェック制約を設定。 図　商品マスタテーブル作成 ※図中のコメントには”表制約構文”と書いてあるが、列制約構文の誤り ②商品マスタテーブルにデータ登録(正常系) 問題なく登録できる。 図　正常なデータを登録 => 登録できる ③商品マスタテーブルにデータ登録(異常系) チェック制約に引っかかるデータを登録。 エラーになり、登録できない。 図　異常なデータを登録 => エラー発生 => 登録できない なお、更新時もチェックされる。  チェック制約（表制約構文） 表制約構文 では、 複数列で1つの条件 を作ることもできる。 図　チェック制約（表制約構文） 実際のSQLは以下のとおり。 ①商品マスタテーブル作成 表制約構文で、価格列にチェック制約を設定。 図　商品マスタテーブル作成（表制約構文） ②商品マスタテーブルにデータ登録(正常系) 問題なく登録できる。 図　正常なデータを登録 => 登録できる ③商品マスタテーブルにデータ登録(異常系) チェック制約に引っかかるデータを登録。 エラーになり、登録できない。 図　異常なデータを登録 => エラー発生 => 登録できない 参照整合制約（外部キー制約） 今までの制約は1つのテーブル内で完結したが、参照整合制約は 参照する側 のテーブル（ 子テーブル ） 参照される側 のテーブル（ 親テーブル ） の 両方をチェック する。 なお、参照される側（親テーブル）は主キー列が参照される。 参照する側（子テーブル）の別テーブルの主キーを参照する列 を　 外部キー 　と呼ぶ。 参照される側（親テーブル）として、グループマスタテーブルを作成、データを登録。 図　グループマスタテーブル（親テーブル）作成 図　グループマスタテーブルにデータ登録 参照整合制約（列制約構文） キーワード　 references　 のあとに　 ...
続きを読む

1月22日(木)3コマ目

イメージ
今日、やったこと [確認テスト　解説]確認テスト2 [練習問題]シーケンス 今日のホワイトボード [確認テスト　解説]確認テスト2 0.必要なテーブル作成 問題にはないが、ビュー作成の際に必要になるテーブルたち。 〇ジャンルマスタ 図　ジャンルマスタテーブル　作成 〇蔵書マスタ 図　蔵書マスタテーブル　作成 〇会員マスタ 図　会員マスタテーブル　作成 問1　貸出データテーブル　作成 図　貸出データテーブル　作成 問2　蔵書一覧ビュー　作成 図　蔵書一覧ビュー　作成 問3　貸出中蔵書数ビュー　作成 図　貸出中蔵書数ビュー　作成 問4　会員別貸出蔵書数ビュー　作成 図　会員別貸出蔵書数ビュー　作成 問5　蔵書別貸出回数ビュー　作成 図　蔵書別貸出回数ビュー　作成 採点して気になったこと うっかりミスだと思うが原点対象なので。 テーブルの結合条件の間違い 結合条件は多くの場合、参照整合性制約のとおり。 うっかりミスだと思いたい。 　X　where 蔵書マスタ.id=ジャンルマスタ.id 　〇　where 蔵書マスタ.ジャンルid=ジャンルマスタ.id 列名のまちがい 問題文を読んでいただければ。会員マスタテーブルには名前列はあるが、氏名列はない。 　×　select 会員マスタ.氏名 　〇　select 会員マスタ.名前　 [おねがい]回答の際、改行してほしい どこまでも1行で書かないでほしい。 　×　create table 貸出データ(会員ID number(6), 蔵書ID char(6), 貸出日 date・・ 　〇　上記の回答例をみてほしい (前にも話したような気がする)count()関数の使い方 引数が*なら、表全体を見て何行あるか数える。 引数に列名を指定すると、指定列の非nullなら行数をカウント。 図　count()関数 引数は*でほぼことは足りると思う。 次回は テーブル作成＋ビュー作成の確認テストその２をやります。 [練習問題]シーケンスのつづき。  
続きを読む

12月4日(木)3コマ目

イメージ
今日、やったこと [確認テスト　解説]確認テスト1 [練習問題]ビュー　練習問題1 今日のホワイトボード [確認テスト　解説]確認テスト1 問1 ユーザー作成。 表領域名を間違っている人が結構いました。 図　問１　正解 問２ 問1で作成したユーザーsiroはDBに接続できるか？ 下図のように、作成しただけでは接続できない。 図　ユーザーsiroでDB接続してみると systemユーザーでユーザーsiroにDB接続に必要なシステム権限”create session”を付与する必要がある。 図　DB接続にはシステム権限create sessionが必要 問3 問1で作成したユーザーsiroはテーブル作成できるか？ 下図のように、やはりシステム権限が足りない。 図　ユーザーsiroでテーブル作成してみる systemユーザーでユーザーsiroにテーブル作成に必要なシステム権限”create table”を付与する必要がある。 図　テーブル作成にはシステム権限create tableが必要 問4 商品マスタテーブル作成。 図　商品マスタテーブル作成 問5 売上データテーブル作成。 売上日列の初期値を忘れている方がちょこちょこ。 図　売上データテーブル作成 問6 売上詳細データテーブル作成。 売上ID列と商品ID列の複合キー。 1回のcreate tableで、主キー制約設定のための”primary key”は1回しか使えない。 図　売上詳細データテーブル作成 問7 検索の問題。 以下が正解。 図　問７　正解例① orのかわりにin を使ってもいい。 図　問７　正解例② 以下はダメ。検索結果は270行程度になる。 where句最後の”商品名='マキアート'”は３つのテーブルの各行を総当たりで結合した結果に対してチェックされる。 図　問７　ダメな例① 以下もダメ。 商品名がカフェラテかつマキアートはありえない。 よって、検索結果も0行。 図　問７　ダメな例② 問8 グループ化して検索。 図　問８　正解例 次回は ビューの練習問題の解説。  
続きを読む