様々な基本になるサンプルを記録しています。

不定期更新です。

記事のサイドに使用している商品の紹介も掲載しているので、良ければご覧ください。

【組み合わせ】【SQL】内部結合によるデカルト積

テストケースを考えるときに組み合わせを頭ですべて考えるのは、過剰になりすぎたり、過不足になったりと、本当に正式なパターンが洗い出されているのか不安ではないかと思う。
そういうときにデカルト積により、テストパターンの組み合わせを網羅できれば、憂鬱にならない。

以下のような、こんなテーブルデータを用意してやってみる。
とりあえず、テーブル名を「test」としてみる。
(以下、貼り付けているイメージはMicrosoft Accessでキャプチャを取っている。)

サンプルテーブルデータ

このデータの4つ並べた時の組み合わせをSQLで作ってみる。

--一つのテーブルを4つ定義し、それぞれフィールド指定
SELECT 
 A.F1 AS F1,
 B.F1 AS F2,
 C.F1 AS F3,
 D.F1 AS F4

FROM 
 test AS A,
 test AS B,
 test AS C,
 test AS D

--4つ並べる
WHERE 
         A.F1<B.F1
  And B.F1<C.F1
  And C.F1<D.F1

この結果が以下のようになる。
5通りのパターンが出る。

ちなみに2つ並べるとしたら、テーブル定義数とフィールド指定、WHERE条件を減らすとできる。

--一つのテーブルを2つ定義し、それぞれフィールド指定
SELECT 
 A.F1 AS F1,
 B.F1 AS F2,

FROM 
 test AS A,
 test AS B,

--2つ並べる
WHERE 
         A.F1<B.F1

結果は10通り。

4つ選択時と2つ選択時の違いから、選択数を増やすと共に、WHERE条件を指定したフィールド文、不等号で繋げていくイメージ。
言葉での説明が難しいので、SQLの例を見て判断してもらいたいと思う。

ちなみに同じ組み合わせでも、違う順番で選ばれるパターンの組み合わせを出すやり方もあるが、不等号の部分を変更するだけになる。

--一つのテーブルを4つ定義し、それぞれフィールド指定
SELECT 
 A.F1 AS F1,
 B.F1 AS F2,
 C.F1 AS F3,
 D.F1 AS F4

FROM 
 test AS A,
 test AS B,
 test AS C,
 test AS D

--4つ並べる 組み合わせ重複および選択順が異なる
WHERE 
         A.F1<=B.F1
  And B.F1<=C.F1
  And C.F1<=D.F1

70通り出てくるが、さすがにイメージでは長すぎて載せられない。。。



これらは、掃除当番とか、グループ分けとかの表作成を行うときに、便利かもしれない。

SQL*PlusによるOracleインスタンスの起動

START
SYSDBA権限を付与されたユーザーのみ可能。

1.SHUTDOWN
インスタンスの停止

2.NOMOUNT
インスタンスの起動、初期化パラメータファイルの読み込み
インスタンスが起動されるということは、SGA、バックグラウンドプロセスも有効になる。

3.MOUNT
制御ファイルの読み込み

4.OPEN
REDOログファイル、データファイルを利用可能にする。

Oracleのデータサービスが利用できるようになるには、1~4の順に起動したり、有効になったりしないと使えないということか。

しかし、無料のEditionを使用していると、これを意識することがあんまりないような。。。

Oracle Database 18c Express Editionの初期設定

インストールして使おうとしたら、11gと違って、デフォルトでPDBが設定されていた。

最初はユーザーすら作成できないので、いろいろ設定を行うことに・・・

  

1.最初にやるべきは、SYSユーザーでPDBに切り替えなければいけない。

/*
Oracle 18C ExpressEditionの初期設定
PDBに切り替えないとユーザーが作れない。
*/
--PDBの確認
select * from cdb_pdbs

/
--PDBオープン
ALTER PLUGGABLE DATABASE XEPDB1 OPEN;

--自動起動設定
ALTER PLUGGABLE DATABASE XEPDB1 SAVE STATE;
/
--PDB切り替え
alter session set container = XEPDB1;

/
--PDBの確認 念のため
select * from cdb_pdbs

/
--SQL Developerで以下を実行して状態確認
show pdbs

 

2.それからユーザーの作成

例は無難なところで設定。

-- USER SQL
CREATE USER "TESTUSER" IDENTIFIED BY "test"
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK 

-- QUOTAS
ALTER USER "TESTUSER" QUOTA UNLIMITED ON "USERS"


3.接続はTNSを使うしかないかなと思ったので、「tnsnames.ora」に設定

SERVICE_NAMEがPDBの名前になるのね。

 XEPGB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = XEPDB1)
)
)


4.ユーザーもTNSも設定したので、接続。。。と思ったら、ユーザーに権限を割り振るのを忘れていた。

--セッション権限付与
grant create session to TESTUSER
/
--リソース権限付与
grant resource to TESTUSER
/
--テーブルスペース権限付与
grant unlimited tablespace to TESTUSER


これでようやく繋がった。

さすがにもうPDBを意識しないとダメってことなんだろうね。

【参考】会社の数字に関すること①

会社の数値って考えるほど複雑でわけわからなくなりがちだが、

少なくとも損益計算書(PL)に関しては知っておいた方がいいと思う。

f:id:karinto441:20181031231341p:plain

f:id:karinto441:20181031231345p:plain

f:id:karinto441:20181031231349p:plain

f:id:karinto441:20181031231352p:plain

開発者なら、原価と売上に対しての売上総利益が身近になると思うけど、

リーダー、マネージャークラスだと営業利益、経常利益を意識しなければいけないところではないかな。

貸借対照表とかは就職活動で四季報を見て、優良企業かどうかを判断するものになったり、株やってる人は配当金がどこに当たるかが気になるところだね。

キャッシュフローに関しては、ちゃんとお金は回収しないと黒字倒産しちゃうこともあるしね。

単に売り上げがあればいいってわけじゃないってことは、社会人としては知っておかないといけないことだと、これを改めてみたときに思った。

【参考】新人教育

今の時代は新人の教育は非常に難しいところがあるかもしれない。

ただ、新人本人はたいていはやる気があるので、やる気を削ぐようなことをやらないようすればいいと思う。

でも、口頭で言うには簡単なことだけど、実際は難しい。

個人的には以下のことを考えつつ、一緒に仕事をしていく感じになるかな。

f:id:karinto441:20181031225409p:plain

f:id:karinto441:20181031225412p:plain

ガツンと言わなければならないときが、必ずどこかであるとは思うけど、

先行く人たちが時と場合を考えて判断していくことなので、

とりあえずは、しっかりコミュニケーションをとることを優先したいところ。

【参考】タスクの整理方法

いろんな作業(タスク)があると思う。

その中で、どのようにタスクを処理していくかは、人それぞれだと思うけど、

参考程度にタスクの整理方法をフリーハンドで書いておいた。

もちろん、誤字や間違えたところは斜線が引いてある、恥ずかしいものではあるけどね。

f:id:karinto441:20181031224547p:plain

f:id:karinto441:20181031224559p:plain

f:id:karinto441:20181031224610p:plain

f:id:karinto441:20181031224616p:plain

⑧の余裕を最後に入れるというのは、なにか割り込んだり、納期遅延が起こった時の余裕時間を設けておくと思えば良い。

その余裕時間を見直す時にうまく割り当てていく。

CCPMというのは各自で調べて確認してほしい。

【ORACLE】インデックス設計

読みにくいかもしれないが貼っておこう。

f:id:karinto441:20181029012912p:plain

f:id:karinto441:20181029012924p:plain

f:id:karinto441:20181029012954p:plain

テーブル設計をするときは、日常運用で想定されるトランザクション数およびデータ件数を考えて行うが、
データの格納パターンも考えて、カーディナリティや頻繁に実行される検索条件も想定しておかないと、
インデックスの設定が難しくなってしまい、パフォーマンス対策において、どうすることもできないテーブルオブジェクトになってしまうことが多い。

インデックスは設定により、劇的なデータ検索速度をたたき出すことができるので、
設計は慎重にやっておくべきだと思う。