DBの論理設計に関する備忘録
こちらの記事の続きです。
論理設計
データベースの構造(テーブル、ビュー)と索引を決定する。成果物は非正規化などを行った概念ER図を修正した論理ER図。
手順1:データ量を検討する
エンティティのデータ量から、性能に問題がありそうなエンティティを選別する。概念設計の業務分析時に作成したデータ量に関する資料を利用する。
初期データ量、平均データ量、最大データ量、増加率、保存期間の５つの指標からなる資料
手順2:業務に対するユーザー要件を考慮する
データベース設計と同時に行われているプロセス設計の資料からユーザー要件を把握する。ユーザー要件を把握し、手順１で選別したエンティティにシビアなレスポンスが要求されている要件がないか調べる。また、索引を定義するだけで求められる性能を満たせるか検討する必要がある。
業務処理内容、操作パターン、要求性能、処理形態、処理タイミング、実行頻度、処理データ量、実行資格などからなる資料
手順3:プロセス要件を考慮する
エンティティの状態の変化を保持するカラムを追加する。この工程によって、プログラムで制御もできるが、プログラムで制御するとレスポンスが悪くなることが多いので、この段階でデータベースに値をもつことを検討する。
手順4:最適化を図る(索引、導出項目、非正規化の検討)
- 索引の定義
- 導出項目の追加
- 非正規化
手順5:ビューを定義する(任意)
ビュー(仮想表)とはテーブルに対する問い合わせを保存したもので物理的にデータを格納、管理していない。ビューにDML操作するときはトリガーを作成しないといけないRDBMSもある。また、DML操作時の問い合わせで使えない機能がいくつかある。
ビューは問い合わせを簡素化したり、データのアクセスに権限をつけてセキュリティーを高めるために用いられる。問い合わせを簡素化して、性能が落ちる場合もあるので注意が必要。
手順6:テーブル/ビューに対するアクセス権限を検討する
システム権限とアクセス権限がある。システム権限はデータベースに接続してよいやデータベースにテーブルを作ってよいなどを表す。オブジェクト権限はテーブルやビューなどに対する権限を指定する。
手順7:ER図からRDBMSへ変換する
SQL文を作成する。
索引の定義方法
索引を定義することによって、パフォーマンスが上がる。索引には定義した列の名前とその値が格納されている位置情報(データファイル、ブロック番号、行番号)が記録されている。
あー索引の付け方とか、導出項目、重複項目の出し方、非正規化のやり方まとめたけど、全部消えたから記事リリース笑
モテない男多すぎませんか？
最近、急にモテるようになった。僕のいう「モテる」とは学生のときは「女の子からわーキャーいわれる」みたいなものだと思っていたけれど、大人になるにつれて変化があって、「自分が落としたいと思った女性を落とせる」ことがモテることだと思うようになった。
日本が少子高齢化だと言われている中で、少しでも世の中の男の人に「モテる」ようになってもらいたいと思っている。だから、どうやって「モテる」ようになったか整理して、アウトプットしてみる。
モテる人とは
モテるようになって、モテている人とモテない人の区別がすぐつくようになった。モテる人が必ず持っているものが「自信」というやつだ。でも、この本当の「自信」というものを持っている人は本当に少ない。スーパーレアな存在だ。そんな男に女性は群がる。この自信を身に付けている人には下記のような特徴が見られる。
- 誰にも媚びへつらわない
- 恥ずかしがらない、堂々としている
- 上から目線じゃない、誰に対しても平等
- 余裕があり、空気が読める
- 包容力がある
結局、自信があると上記のような「モテる」条件を身にまとうようになる。なので、まずモテるためには「本物の自信」を身につけることが先決だ。イケメンな人は顔がいいから「モテる」と思っている人がいるがそれは大間違い。イケメンな人はビジュアルの優位性が自信に繋がって、モテる状態にあるのだ。イケメンじゃないからモテないという考えは本質を捉えることができていないモテない男のいい訳だ。
自信を身につけるには
ではどうやったら、自信を身につけることができるのだろうか。「自分で目標を設定し、目標を達成するという成功体験を積んでいくこと」と「自信のある人の近くにいること」でたくさん学び、少しずつレベルを上げて自信をみにつけていくしかない。
自信だけではいけない
自信はモテるための必要条件だ。ただ、自信を身にまとっていても「自分が落としたいと思った女性を落とせる」状態にまで昇華することはできないかもしれない。やはり、「女性を知っている」ということもモテるために非常に大切な要素だ。例えば、自信を身につけていても、女性のことを知れずにいきなり「好きだ、付き合ってくれ」といっても、そりゃ振られる可能性は大ですよ。女性を好きにさせる過程は結構パターン化しており、難しいものではない。しかし、その方法をしらずに、女性を口説こうとしても難しいだろう。
どうやって女性のことを知ればいいか
女性のことは女性に聞くのがいいだろう。でもそれより、実際に女性にアタックしてみるのが一番女性を知るのにはいい。なぜなら、女性から話を聞くだけではあまりにわからないことが多すぎるからだ。女性から話を聞いてわかることは、例えば、どういう服装がよくて、どういう服装がダメとかそういう見える部分ぐらいだ。実際に女性にアタックし、失敗したらその理由を考え、次のアクションを設定する。このサイクルを続けることで確実に誰でもモテるようになる。しかし、世の中の男は失敗が怖くて、このサイクルを回したがらない。結局のところ、「失敗したときにくじけない心」というのがモテるための必要条件だろう。
モテる要素を持っている人は
ビジュアルがほとんどモテることに関係ないことは前述のとおり。結局モテる可能性の秘めている人は「失敗を恐れず、チャレンジできる人」と「学習能力が高い人」この二点になる。この要素がある人は小さな成功体験を積みながら、女性を知っていき、自信を身につけながら「モテる」状態まで到達できる。
抽象的な話になってしまったが、あまり僕はテクニック的なことは書きたくない。小手先のテクニックなんて頼らず、自分を磨いて、本当にいい男になって、モテる人になってほしいと思う。
SQLチューニングの条件分岐に関する備忘録
前回の記事の続きです。
SQLにおける分岐条件
CASE式を用いる方法と集合演算子UNIONを用いる方法があるが、基本は以下の二つの理由からCASE式を用いること。
- CASE文の方がパフォーマンスが良い
- SQL自体が簡潔に書ける
UNIONを使った条件分岐
SELECT item_name, year, price_tax_ex AS price
FROM Items
WHERE year <= 2001
UNION ALL
SELECT item_name, year, price_tax_in AS price
FROM Items
WHERE year >= 2002;
CASE式を使った条件分岐
SELECT item_name, year,
CASE WHEN year <= 2001 THEN price_tax_ex
WHEN year >= 2002 THEN price_tax_in END AS price
FROM Items;
実行計画を確認するとUNIONのはテーブルに二回アクセスしているが、CASE文は一回しかアクセスしないので、二倍程度パフォーマンスに差が出る。
しかし、異なるテーブルの結果をマージするときはUNIONを使わなければならない。
UNION必須なケース
SELECT col_1
FROM Table_A
WHERE col_2 = 'A'
UNION ALL
SELECT col_3
FROM Table_B
WHERE col_4 = 'B';
また、UNIONを使ってうまく絞り込みの効くインデックスを利用できて、かつUNION以外の手段ではそうしたインデックスを利用できない場合、UNIONを利用したほうがパフォーマンスが良いこともある。
カットと集約
GROUP BY句：集約とカットの機能を持つ
GROUP BYを用いて集約操作を行った場合、SELECT句には以下の三つしか書くことができない。
- 定数
- GROUP BY句で指定した集約キー
- 集約関数
SELECT id,
CASE WHEN data_type = 'A' THEN data_1 ELSE NULL END AS data_1,
CASE WHEN data_type = 'A' THEN data_2 ELSE NULL END AS data_2
FROM NonAggTbl
GROUP BY id;
上記のようなクエリは構文エラーが発生します。正しくは下記のクエリです。
SELECT id,
MAX (CASE WHEN data_type = 'A' THEN data_1 ELSE NULL END) AS data_1,
MAX (CASE WHEN data_type = 'A' THEN data_2 ELSE NULL END) AS data_2
FROM NonAggTbl
GROUP BY id;
PARTITION BY句：カットの機能のみ持つウィンドウ関数
PARTITION BYは集約機能をもたないので、GROUP BYと違い、SELECT句に普通の列を指定できる。
SELECT name, age,
CASE WHEN age < 20 THEN '子供'
WHNE age BETWEEN 20 AND 69 THEN '成人'
WHNE age >= 70 THEN '老人'
ELSE NULL END AS age_class,
RANK() OVER (PARTITION BY CASE WHEN age < 20 THEN '子供'
WHEN age BETWEEN 20 AND 69 THEN '成人'
WHEN age >= 70 THNE '老人'
ELSE NULL END
ORDER BY age) AS age_rank_in_class
FROM Persons
ORDER BY age_class, age_rank_in_class;
RDBMSアーキテクチャの備忘録
現在、モデリング、 DBテーブル設計、DBチューニングに関する技術を一気に勉強している。WEBアプリのアーキテクチャを勉強して、フロントサイド(HTML,CSS,Javascript)、サーバーサイド(Java)の実装はできるようになったけど、DBまわりの知識が非常に乏しい(SQLでCRUD使えて、環境構築できるぐらい)ので、勉強している。
上記の記事では学んだデータモデリングの基礎をアウトプットけど、今回はDBチューニングに関する基礎を学んだので、それをアウトプット。今、利用している書籍は下記です。今の自分の知識量ではついていくのに少々厳しいところがあるけど、非常に詳しく解説しているので、おすすめ。
RDBMSアーキテクチャ
DBMS(Data Base Management System)はその名を通り、DBを管理するシステム。SOLがDBMSに渡り、解釈され、DBにアクセスされる。この解釈されの部分の仕組みを知らないと、DBチューニングできない。
クエリ評価エンジン
データベースにアクセスする手続きを決めるモジュール。ユーザから送信されたSQLを受けとる。クエリ評価エンジンはさらに５つのモジュールに分類できる。
1.パーサ
受け取ったSQLを分解し、SQLの構文に間違いがないかチェックする。
2.オプティマイザ
選択可能な実行計画を、データの分散や偏りの度合いなどの情報を考慮し作成する。そして作成された実行計画のコストを評価して、最も低コストな実行計画に絞り込む。うまくオプティマイザが動かない場合、カタログマネージャーに記録されている統計情報が古いままの場合があるので、更新処理を行う。
3.カタログマネージャー
オプティマイザが選択可能な実行計画を作るときに必要な情報を保持していて、それを必要な時に提供する。
4.プラン評価
オプティマイザが作成した実行計画から最適なものを選択し、手続き型のコードに変換する。
※実際に利用される計画実行はコマンドで確認できるので確認しながら行うことが多い。
バッファマネージャ
パフォーマンス向上のためにメモリに格納する情報を管理する。DBMSが情報を保持するために使うメモリには大きく２つある。ユーザが用途に応じて容量を変更することも可能。通常は性能試験の段階で各容量を検討する。
データキャッシュ
ディスクにあるデータの一部。運悪く、メモリの中に取り出したい情報がなかった場合、パフォーマンスが低下する。
ログバッファ
DBMSは更新SQL文を受け取っても即座にストレージ上のデータを変更せず、一度ログバッファ上に変更情報を溜めて、更新はあとでまとめて行う。また、ログファイルは同期処理でコミット時に行われるが、ストレージへの更新処理は後にして、処理能力と堅牢性のどちらも担保する。
※ワーキングメモリ
ハッシュ、ソートなどの特定の処理に利用されるメモリ。データ領域が不足すると、ストレージ上で処理を行うので非常に処理が遅くなる。(スワップ)
ディスク容量マネージャ
ストレージのどこにどのようなデータを保存するかを管理し、それに対して読み出し/書き込みを行う。
トランザクションマネージャとロックマネージャ
トランザクション同士をうまく整合性を保ちながら実行し、必要であればロックをかける。
リカバリマネージャ
定期的にバックアップを取る
flierというWEBサービスが熱い！
あなたはfilerというWEBサービスを知っていますか？僕はこのサービスの課金ユーザです。WEBサービスを有料で使うことなんてめったにないけど、これは有料でも使いたいと思った。その理由を紹介したい。
僕は本屋さんに週に２，３回いく。いつも何か面白い本がないかなーと思って、いろんな本を手に取ってみる。でも、そんなにたくさん本は買わない。月に３～4冊ぐらい。しかも大体購入する多くの本は技術系の本だ。なぜなら、技術系の本は一度購入するときっと何回も読み返すことになり、費用対効果が高い。しかし、ビジネス系、自己啓発系の本はあまり購入しようとは考えない。なぜなら本当にいいことを書いてある本もあれば、どうでもいいことしか書いてない本も多く、また購入しても読み返すことが少ないからだ。だから本屋さんに行くと、以下の手順でほんと手に取って読むか考える。
１．タイトルが面白そうか、また著者が有名な人か
→ ２．目次を読んでみて、自分の知らないまたは興味のある内容がたくさん記述されていそうかどうか。
→ ３．先頭から少し読んでみて、自分にとって価値のある本かどうか。
これら一連の手順を行い、読むに値する本かを選別するコストは非常に大きい。それでこのflierというサービスを使い始めた。
flierとは
flierはビジネス、自己啓発系の書籍の内容を要約しているWEBサービスである。有料会員は月額2000円かかるがそれ以上の価値を見出している。
その理由は編集クオリティの高さだ。プロの編集者を雇い、いい具合に本を要約している。字数的には5000字程度にまとめているので、内容を把握するのにストレスがかからない。また、事前のダウンロードが必要だが、オフライン環境でも記事の要約を読むことができる。それにサイトの機能もシンプルで使いやすい。
また、ビジネスモデルも非常に優れている。会員数が増えても仕事量は増えないし、有料会員からのキャッシュだけでなく、紹介した本の書籍のオンライ上での購入を通じて、広告料も入る。また、サイト自体はシンプルなので、システム開発コスト自体も少ないだろう。小さく初めることができ、自動化できて、スケールのするビジネスモデルだ。今は競合が少ないと思うので、今のうちに投資をして、ユーザーをしっかり獲得しておきたいところだ。
強いて改善点を上げるとすると、まだまだ要約している書籍数が少ないこと。1000~2000程度だろう。今後に期待したい。
