私はサポートエンジニアになりたい

元教師・現開発エンジニアの挑戦

Webブラウザでwww.example.comを入力しWebサイトが表示されるまでの流れを説明する

説明する練習

ブラウザにwww.example.comを打ち込んだとき、裏側では何が行われているか

  1. クライアントがクライアントPCのWebブラウザにURLを入力する
  2. URLに含まれるドメインをDNSサーバに問い合わせる
  3. DNSサーバでドメインからIPアドレスを特定する
  4. DNSサーバからIPアドレスが送信される
  5. 取得したIPアドレスのWebサーバにデータを要求
  6. Webサーバは要求した内容に応じて、保存しているコンテンツ(HTML,CSS,画像など)を返す
  7. Webサーバから返されたデータをWebブラウザで表示する

www.rworks.jp

ブラウザからDNSサーバに問い合わせる前にやっていること

  1. クライアントPCがブラウザのキャッシュに「www.example.com」のIPアドレスが残っているか調べに行く
  2. ブラウザにキャッシュが残っていない場合はhostsファイルを調べにいく
    Windows:C:\Windows\System32\drivers\etc\hosts
    CentOS:/etc/hosts

Webページがブラウザに表示されるまでに何が起こるのか？

DNSサーバに問い合わせてIPアドレスを受け取るまでを深堀する

DNSサーバに問い合わせてwww.example.comのIPアドレスを取得する順番

  1. クライアントPCがDNSキャッシュサーバに「www.example.com」のIPアドレスは何か問い合わせをする
    1. ブラウザがクライアントPCのOSとして備わっている機能のスタブリゾルバを呼び出す
    2. スタブリゾルバがDNSのキャッシュサーバに「www.example.com」のIPアドレスは何か問い合わせをする
  2.  キャッシュサーバがルートサーバへ「www.example.com」のIPアドレスは何か問い合わせをする
  3. ルートサーバがキャッシュサーバへ「com」の情報を管理するDNSサーバのいずれか(a.dns.com, b.dns.com, ...)に問い合わせるよう回答する
  4. キャッシュサーバが回答の中から1つ選んだ「com」のDNSサーバに「www.example.com」のIPアドレスは何か問い合わせをする
  5. 「com」のDNSサーバはキャッシュサーバに「example.com」のDNSサーバの情報を回答する
  6. キャッシュサーバが回答の中から1つ選んだ「example.com」のDNSサーバに「www.example.com」のIPアドレスは何か問い合わせをする
  7. 「example.com」のDNSサーバはキャッシュサーバに「www.example.com」のIPアドレスを回答する
  8. キャッシュサーバはクライアントPCにIPアドレスの情報を回答する

JPNICの記事で紹介している「名前解決の仕組み」が分かりやすい

www.nic.ad.jp

キャッシュサーバがすでに「www.example.com」のIPアドレスを得ている場合(DNSサーバからIPアドレスを得た場合)

  1. キャッシュサーバがスタブブラウザに問い合わせの結果を返す
  2. スタブリゾルバが受け取ったIPアドレスを取り出し、ブラウザから指定されているメモリ領域に書き込む

 

インターネット10分講座：DNSキャッシュ - JPNIC

【図解】ドメインとは？をわかりやすく解説します - カゴヤのサーバー研究室

キャッシュを使う

クライアントPCがすでにwww.example.jpのIPアドレス情報を取得している場合、そのIPアドレスを用いてWebサーバにデータを要求する

 

キャッシュサーバがwww.example.jpのIPアドレス情報を取得している場合、クライアントPCはキャッシュサーバに対して問合せし、IPアドレスを取得する

WebブラウザとWebサーバとのやり取りを深堀する

  1. WebブラウザがWebサーバに対してTCPのコネクションを確立する
  2. Webブラウザが該当するIPアドレスのWebサーバにHTTPリクエストを送信してWebページのデータを要求
  3. Webサーバが受信したHTTPリクエストを解析
  4. WebサーバがWebブラウザに要求されたデータをHTTPレスポンスとして送信
  5. Webブラウザが受信したデータを解析してWebページとして表示

Webサーバとは、Webアクセスの仕組み

TCPのコネクション(3 way handshake)

コネクションを確立する。

  1. 接続元が接続先へ通信路を確保するために、データ転送の許可要求を出す「SYN(シン)：1, ACK(アック)：0」のパケット
  2. 接続先が接続元に許可と許可要求を出す「SYN：1, ACK：1」のパケット
  3. 接続元が接続先に許可を出す「SYN：0, ACK：1」のパケット

図にすると以下のようになる。

-----

　　　ノード1　　　　　　　　　　ノード2

　　　CLOSED　　　　　　　　　　LISTEN　　　

　　　　　　　　－－－SYN－－＞

　　SYN_SENT

　ESTABLISHED　＜－ACK+SYN－－

　　　　　　　　　　　　　　　　　SYN_RCV

　　　　　　　　－－－ACK－－＞　ESTABLISHED

-----

コマンドでTCPコネクションを確立すると以下のようになる。

sudo tcpdump host www.example.com and port 80

このやり取りをすますと、PC上でESTABLISHEDという状態になる。

ネットワークの接続一覧は「netstat」コマンドで表示できる。

https://wa3.i-3-i.info/word15428.html

【TCP】コネクションの確立までの道のり - Qiita

※終了するときはコネクションを切断する

TCPのフラグ(コントロールフラグ)

URG(Urgent)：緊急に処理すべきデータが含まれている

ACK(Acknowledgement)：確認応答番号のフィールドが有効であること

PSH(Push)：受信したデータをバッファリングせず、アプリケーションに渡す

RST(Reset)：コネクションが強制的に切断されること

SYN(Synchronize)：コネクションの確立を要求する

FIN(Fin)：コネクションの正常終了を要求する

TCP/IP - TCPとは - TCPヘッダ

Webサーバとのやりとりを深堀する

TCPコネクションを確立する

通常はHTTPのウェルノウンポートの80番(HTTPSであれば443番)を指定し接続を要求する

HTTP接続が可能になったら、WebサーバはURLで指定されたファイルなどのリソースを取得しクライアントに返信する

メモ

URLとドメイン

http://www.example.co.jp

ホスト名：www

ドメイン名：example.co.jp

FQDN：www.example.co.jp

jp：トップレベルドメイン

co：セカンドレベルドメイン

example：サードレベルドメイン

ドメイン名はどの部分？｜ドメイン基礎知識｜Zenlogic - 株式会社IDCフロンティアのレンタルサーバー

ホスト名とIPアドレスの例

ホスト名：www.google.co.jp

IPアドレス：172.217.161.67

SSL/TLSとは何か

TCP/IP 説明する練習

SSLで使用する技術

ハイブリッド暗号方式

盗聴対策。

共通鍵のデメリットである鍵の配布を公開鍵暗号化方式で実施。

  1. Webサーバは公開鍵と秘密鍵を作成
  2. Webサーバは公開鍵を公開し、秘密鍵を保管
  3. Webブラウザは共通鍵のもとを公開鍵で暗号化して送る
  4. Webサーバは共通鍵のもとを秘密鍵で復号
  5. WebサーバとWebブラウザは共通鍵のもとから共通鍵を生成
  6. Webブラウザはアプリケーションデータを共通鍵で暗号化
  7. Webサーバはアプリケーションデータを共通鍵で復号

メッセージ認証コード(MAC)

改ざん対策。

データとMAC鍵(共通鍵)を比較する。

ハッシュ関数に共通鍵の要素が加わるため、改ざんの検知と相手の認証をする。

ディジタル証明書

なりすましや否認対策。

相手が通信したい相手であることを保証する。

SSL通信の種類

他のプロトコルと組み合わせて使用することでプロトコルでの通信を保護する。

TLSハンドシェイク

・・・後日、またまとめたいと思います。

2021年度に取り組んだことを振り返る

サポートエンジニア 私について

この1年で何ができるようになったか振り返る回

1年前の自分と比べて、私はできることが明らかに増えていた！

技術

  • Pyhtonを使ったWebアプリケーションの開発
  • C#を使ったデスクトップアプリケーションの開発
  • Microsoft SQL ServerとVB.NETを用いた生産管理システムの改修
  • 納品した実行ファイルと同じソースコードが存在しない中、不具合改修と機能追加を実施
  • ソースコードから稼働中のシステムのボトルネックを特定し、次期改修案件として仕事を受注
  • 改修したコードを本番環境にデプロイ
  • チームで本番環境のトラブルシューティング
  • ユーザーから不具合をヒアリング・原因調査と対応

などなど。

この1年は、今までやったことのない技術にふれる機会が多かった。

いい意味で自分の殻をやぶることができた気がします。

初めて扱うプログラミング言語や技術に対して戸惑いながらも調べたり質問したりすることで何とか乗り切ることができる！(というより、何事も挑戦しないと自分が成長できない)

今もガントチャートとにらめっこしながらプロジェクトを遂行して開発職を楽しんでいます。

ユーザーの声を聞いて、不具合の現象を確認しトラブルシューティングする。これはこれで楽しい。仮説があたったときはうれしいですし、仮説がことごとくはずれたときに先輩エンジニアさんに相談すると、先輩流のトラブルシューティング(秘伝のたれ)が垣間見れて非常に勉強になる。

「ユーザーがシステムを操作するうえでは問題はないと判明したから調査は終了するけど、なんでこの現象起きたの？」というものに出会うと、ちょっと悔しい。

こんな感じで、トラブルシューティングは私の感情をゆさぶってきます！

資格

4月の応用情報技術者試験が終了次第、資格の勉強はストップします。

というのも、時間は有限だからです。

忘れないための勉強と傾向を把握するための勉強にかける時間が惜しい。それよりももっと学ぶべきことがあるのでは？と思ったのです。

たとえば、(私とお話しした)サポートエンジニアの方が重視していたTCP/IP・OS・Webの仕組みあたりは理解して説明できるようになっておきたい。

ITというものは範囲がとても広い。だから同じことを何度も繰り返すことよりも知らないジャンルの知識をつけたり学んだことを深めることが市場価値を上げるうえで大事なのでは。

その他

  • Linkedinに職務経歴をまとめる
  • サポートエンジニアに興味を持つ
  • サポートエンジニアのカジュアル面談をする
  • 本選考に進めず
  • 学習欲に火が付く
  • このブログをはじめる
  • ツイッターに1週間を振り返るようになる

チャンスに気づいたら、いつでもチャンスをつかめるように。そしてチャンスをつかみそこなうことがないように。

そのためにも常にアンテナを張り準備をし続けたい。

来年度の目標

健康で文化的な生活を送るエンジニアであり続けたい！

燃え尽きない程度に業務で力と成果を出し、社内・社外で活躍できるように今日も明日もちょっとずつ前進していくぞ！

そして、サポートエンジニアを目指す。今度こそ

私だって偶然をキャリアに活かしたい！では、そのために何をする？

書評 サポートエンジニア 私について

そう、読んだだけで終わりにするのはモッタイナイと思ったのです。

アマゾンのリンク：https://www.amazon.co.jp/dp/B09VLHHVQD

5つの行動特性とは

好奇心：興味を持ったことには取り組んでみる

持続性：仮に失敗してもすぐにやめない

楽観性：生きているのでOKくらいの、失敗や不安ごとを重く捉えすぎない

冒険心：失敗を恐れずに始める

柔軟性：新しいものを受け入れ続ける。変化を歓迎する

このような行動特性を持った人が偶然を呼び込みやすいとされている。

この本には、偶然を受け入れて自身のキャリアにつなげた方の事例が多数紹介されている。本を読んだ限り、この5つの行動特性がそろってなくても偶然は引き起こせるようでした。

 

私の日々の活動と行動特性

サポートエンジニアに興味を持ちカジュアル面談をするも、選考に進めなかった。

選考に進めなかった原因は、求めるレベルに届いていなかったことと考えた。

幅広い知識を身に着けるため、基本情報技術者試験の勉強を合格した。

社内で技術的な話をすると「えっ、そんなことも知らないの？」と言われることがあり、試験に合格しただけでは、十分な知識が身についていないことを実感した。

また「サポートエンジニアに転職した方」のブログに「自分から情報発信できることを重視されているように感じた」と書かれていたのでさっそくブログを作成する。

beasupportengineer.hatenablog.com

サポートエンジニアに関して考えたことをまとめたり学んだ技術を説明する練習の場としてブログを活用できれば満足。もしかしたら採用担当の目に届くかもしれないと思い、1日のアクセス数が0でもかまわずブログを継続する。

4月半ばまでは応用情報技術者試験の勉強をし、その後はカジュアル面談で聞かれた技術について説明できるようにブログにまとめていきたい。

具体的には以下の4つをやる。

www.he.u-tokyo.ac.jp

行動特性に当てはめる

好奇心：業務で触れる機会がない技術に対しても学習する

持続性：サポートエンジニアの選考に進めなくても学習を継続した

楽観性：ブログやTwitterで発信し続けていれば採用担当の目にとまるかも！と考える

冒険心：1日のアクセス数が0の日があっても淡々とこのブログを更新する

柔軟性：やり方がよくないと思えば、やり方を変える

偶然の発生しやすさを計画的に高める

これまでの私の活動を振り返り、5つの行動特性に当てはめることができた。

私の存在を見つけてもらえるように発信する

この本を読んだとき、自分の存在を知っている人がそばにいて＆声をかけてもらって偶然をキャリアに活かしている人が多いような印象をうけました。

「私が転職したときはこんなスキルが評価されましたよ！」や「うちでは今こんな人材を探してまして…」といった情報を手に入れるためにも私の存在をアピールしつつ話しかけやすいオーラをまとわないとな・・・。

 

私はサポートエンジニアに興味を持っています！

サポートエンジニアを目指している人はここにいますよ！

お気軽に声をかけていいですよ。

私がどんな人物であるかイメージできるような内容を発信する

サポートエンジニアとして活躍している姿がイメージできなければ、たとえ自分の存在が知られていても声をかけてもらえない可能性があると思っています。

なので、読み手がイメージできるレベルで以下のことを説明できる状態にすることが有効ではないでしょうか。

  • 現職での私の強みと強みが活きたエピソード
  • サポートエンジニアに求める技術への理解度
  • サポートエンジニアに興味を持ったエピソード

この辺りをまとめて、私がイメージするサポートエンジニア像と御社で活躍中のサポートエンジニアとの差が把握できたらいいなぁ。

他に考えていること

「王道の正面突破が難しいので、他の人と違う方法をとったらうまくいった」みたいな話がありまして、偶然から始めるキャリアプランと似てるな(もしかして一緒？)と思いました。

このnoteを併せて読むと、さらにアイディアが浮かんできそう。

kensuu.com

おわりに

こんな感じで私は現在進行形で偶然を引き寄せようと楽しくジタバタしています。

正解がわかっていない問題に取り組むときほど頭をフル回転して何とかしようとする。

その過程が人間らしくて好きだし、サポートエンジニアのお仕事もこの状態に近い気がする。

 

ここまで、読んでいただきありがとうございます。

今後も私の行動や発信に注目してください！

お気軽に声をかけていいですからね。

開発エンジニアからテクニカルサポートエンジニアになった方のブログに共感したのです！

サポートエンジニア 私について

開発エンジニアからテクニカルサポートエンジニアになった方の話を見つけました。

blog.riywo.com

現在、私は開発エンジニアであり、次のキャリアとしてサポートエンジニアを目指しています。私とこの方との間に共通する考え方があるか気になったのでまとめます。

私は「ここ」に共感した！

念願かなって Software Engineer として働いてみましたが、先日人に言われて改めて気づいたのが、僕は Software Engineer になりたかった訳ではなくて、Software Engineer をしてみたかっただけなんですね。

はじめてこの記事を読んだとき、1番ここが刺さりました。まるで自分事のように。

知識豊富のSoftware Engineerからの質問が刺さったことを思い出す。

「自宅ではプログラミングで何か作ったりしないんですか？」という質問にハッとさせられた記憶があります。『私は、本当に開発したいのか？』と。

私に質問した方は「これを自分の手で作りたいんだ！」といったものがあり、帰宅後も開発をされているようなThe開発エンジニアです。どうしても開発がしたくて仕方がないような感じ。

一方、私は帰宅してからプログラミングすることはありませんし、そもそも作りたいものがない(イメージできない)。

私は「Software Engineer になりたかったわけではなくて、Software Engineer する能力を身につけたかった」んだろうなと思いました。

Software Engineer は自分が担当する system については文字通り上から下まで責任持って自由にやれます("You build it, you run it" でした)が、担当外のものについては結局手が出せないことが多いなと感じました。言い換えると、自分が手を出せる範囲が非常に狭く深いです。

良くも悪くもこれなんですよね。自分が担当したsystemに対して色々できるのですが、担当したものしか手を出せない(ことが多い)。これはこれで楽しいのですが、systemが完成するまで短くて数カ月、巨大なsystemになると数年かかったりします。また自分が触れる技術は、参加したプロジェクトの担当箇所でほぼ決まるため、数年間で振り返ると、私がやってきたことは偏ってて意外と少ないのでは？と思ったりします。

IT業界に入って基本情報の勉強したときに「ITって、こんなに範囲広いのかよ！」と驚いていたわりには身に着いた技術の範囲は狭いかも。と感じています。

色んな技術に触れてみたい思いはあるため、今はSoftware Engineerとしてやっていけても、いずれは熱が冷めて飽きてしまいそうです。

Software Engineer以外の道としてSupport Engineerを目指している

プログラミングを触ったときに、「これさえあれば、何でも作れるのか！すごい世界だ！！」と思ったから私はSoftware Engineerになったわけですが、エンジニアの仕事は多岐にわたることエンジニアになって知りました。

現在は、Software Engineer以外の道としてSupport Engineerを考えています。(このブログのタイトルでもありますし。)

理由は4点

  • 困っている方の力になるのがすき
  • バグの原因を特定、解消できたらうれしい
  • 困っている方の課題が解決できたら私もうれしい
  • ユーザーの課題に対してブレずに応えたい

Technical Support Engineer がいいなと思った理由は、お客さんの課題を直接的に知ることができて、それを service 改善に自分でつなげやすいと思ったからです。Software Engineer だと、どうしてもそうした今起こっている課題を間近で見る機会というのは減ってしまって、ともすれば今開発しているものが一体何のためのものだったのかブレてしまうこともありがちです。

この辺は、まったく同じことを思いました。(ユーザーとの距離と開発にかかる期間がそうさせるのでしょうか。)

ユーザーのぼんやりした課題をうまく言語化してプロジェクトを開始するも、走り出している間に作りたいものがブレていき、最終的には「思っていたのと何か違うもの」が完成する。Software Engineerをやっていてもどかしい瞬間です。

Support Engineerはユーザーとの距離が近く、プロジェクト1つのサイクルが(Software Engineerと比べて)短く、課題とあるべき姿が明確なため、ユーザーの課題解決に特化できる点がいいなと思ったのです。

これからの私

業務で扱う技術・自分が興味を持った技術に関して今もこれからも貪欲に学んでいきます！(明日、面接しませんか？と言われるかもしれないですし。)

最近は、業務外に学んだこと(やったこと)を記録するようにしています。

※もちろん日々の業務も全力で取り組んでいます。

チャンスをみすみす見逃さないように、今できることを積み重ねていきたい。

私はサポートエンジニアに興味を持っています。採用担当の方や現役エンジニアの皆さんからのお声がけ、いつでもお待ちしております！

応用情報技術者試験のシステム監査で高得点とるためのまとめ

サポートエンジニア

参考になりそうなサイト

masassiah.web.fc2.com

監査人に任命するにあたり確認する独立の観点(R2秋)

  • 監査人の所属部門が監査対象と同じ指揮命令系統に属していないこと
  • 以前に監査対象の領域または業務に従事していないこと

具体的に確認すべき項目として解答すべきことは

  • 担当から離れて一定期間経過していること
  • 開発・保守業務に対する関与度合い

など。

監査手続の考え方

「必要な手続」の見つけ方

  1. 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
  2. 必要な手続きを見つける
  3. 見つけた手続きに「記録」をつけるか検討する

監査の結論を裏付けるために十分で適切な監査証拠を手に入れることができるものである必要があります。

不要な権限の見つけ方

  1. 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
  2. 誰に何の権限がある・ない・不明をまとめる
  3. ない・不明の権限が仮に付与されていた場合、1のフローを通さずに業務手続きができてしまうものを選ぶ

その他(本文の単語+本文にない業務動作の単語)

承認権限はあるので、入力権限も付与されていたら不正が可能になる(R2秋)

監査実施の注意点

エラー処理などの監査をする際に、架空のデータを使うことがあります(テストデータ法)。

そのとき注意することは、実在するデータとして処理されないようにすることです。

例：監査人が作成した発注データが受注確定されてしまわないこと

改善が必要になること

担当者が入力と承認を行うことができること

移行作業表を作成するのは開発担当者で、移行するのは以降担当者だが、開発担当者も移行に関する権限が与えれらてしまっているため、場合によっては移行作業表を作成せず移行できてしまう(R1秋)

システムを介さない手続き(R1秋)

「システムの権限設定を見てシステム利用者の職務分離が確保されているか確認する」手続きでは、システムを介さずにデータを入力・修正したものを確認する手段がない

監査手続の技法

インタビュー法

監査対象の実態を確かめるため、システム監査人が直接、関係者に口頭で問合わせ回答を入手する技法

チェックリスト法

システム監査人が、あらかじめ監査対象に応じて作成されたチェックリストに対して関係者から回答を求める技法

突合・照合法

関連する複数の証拠資料間を突き合わせること、記録された最終結果について、原始資料までさかのぼってその起因となった事象と付き合わせる技法

ペネトレーションテスト

システム監査人が一般ユーザのアクセス権または無権限で、テスト対象システムへの侵入をためし、システム資源がそのようなアクセスから守られているかどうかを確認する技法

その他

職務の分離(R3春)

業務の担当者と承認者を分離し、職責と権限を適切に分配することで、各者間での相互牽制を働かせること

ビジネスを有利にはたらくための情報

取引先の見積額

応用情報技術者試験のDB問題で高得点とるためのまとめ

応用情報技術者試験 DB

エンティティの考え方

多重度

種類は以下の4つ。この中からどれを選ぶか考え方を考える。

ー：1対1

→：1対多

⇔：多対多

1対多(R2)

これを記述するパターンが1番多い。矢印の向きは主キーから外部キーへの向き。

A(主キー)　→　A(外部キー)

A(外部キー)　←　A(主キー)

⇔：多対多

第3正規形にしないといけないため、多対多を書くことはなさそう。

属性

リレーションシップの矢印の向きと隣り合う属性をみて、判断。

隣り合うエンティティの主キー・外部キーになっているものが、空欄に記述する属性になる。

主キー：テーブルの行を一意に識別する。

隣に主キーがあれば、記述する属性は外部キー。

データウェアハウスでの考え方(あくまでR3)

要件を満たすためのデータモデルを作成するため、分析に不足している属性を本文から抜き出す。

現状のER図のままだとエラーになることが判明した(R1)

主キーが同一のレコードを登録して実行時エラーになるパターンが多そうです。

対応策として、エラー原因となっている表の主キーをみなおし、主キーを別の属性に変更することです。

正規化

第1正規系

テーブル中に複数の値をもつようなデータ項目を含まないよう整理

第2正規系か判断する

「主キーAと主キーBが存在し、非キー属性Cが異なれば主キーAは異なる」

→非キー属性Cは主キーAに関係従属し、主キーBには関係従属しない

なので第2正規系になっていない

第2正規系でなくても問題がない理由

本文に、「テーブルの内容は変更されることはない」と記載されるパターンが多い。

回答例：〇〇テーブルに追加された行の値がその後、変更されることはない

※テーブルの内容(主キー)が変更になった場合、複数の行を同時に変更しないといけないため、更新漏れが発生しそう

第2正規系

第1正規系の表に対して、主キーの一部の項目だけに従属するような項目を含まないよう整理

候補キー

主キーの候補になりうる項目

代替キー

主キー以外の候補キー

非キー属性

候補キー以外の項目

第3正規系

第2正規系の表に対して、主キー以外の項目に従属するような項目を含まないよう整理

SQL文の考え方

どの表が使われているか確認すること！

困ったら本文を探そう。見逃している条件があるかも！

SQLの実行順序

FROM

JOIN

WHERE

GROUP BY

SUMやAVEなど

HAVING

SELECT, DISTINCT

ORDER BY

LIMIT

SELECT 列名(または＊) FROM テーブル名 WHERE 条件式

例：

SELECT COUNT(*) FROM 従業員

SELECT 単価 * 0.5 FROM 商品

細かい条件

SELECT DISTINCT 商品名 FROM 商品

重複を除く

SELECT 年齢, COALESCE(性別,2) FROM 会員

 NULL値を別の値に変換する

SELECT 日付, (CASE WHEN 時刻 < 12 THEN 0 ELSE 1 END) FROM 入館

SQL文で条件式を使う

JOIN句

INNER JOIN 結合するテーブル B ON A.属性 = B.属性

両方のテーブルにあるデータのみを取り出す(内部結合)
2つのテーブルにあって、合体できるデータのみを取り出します。

エンティティが1対1のときはこれを使用(R3)

LEFT JOIN 結合するテーブル B ON A.属性 = B.属性

左のテーブルをすべて表示して結合(外部結合)

RIGHT JOIN 結合するテーブル B ON A.属性 = B.属性

右のテーブルをすべて表示して結合(外部結合)

WHERE句による条件設定

WHERE 予約日 BETWEEN '20220306' AND '20220310'

範囲を指定する

WHERE 予約日 IN ('20220306', '20220310')

()内の値が対象

WHERE 名前 LIKE '_太郎%'

_は任意の1桁、%は任意の0～N桁の文字

WHERE 電話番号 IS NULL

NULLを抽出

WHERE 電話番号 NOT IS NULL

否定した条件

GROUP BY句(R3 SELECT文にCOUNTがあればGROUP BY)

SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日

SUM()以外にはAVG(),MAX(),MIN(),COUNT(*)などがある

GROUP BY句とHAVING句(R2)

SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日 HAVING COUNT(*) > 3

ORDER BY句

SELECT 予約番号, SUM(金額) FROM 予約明細 GROUP BY 予約番号 ORDER BY 予約番号 ASC

昇順はASC、降順はDESC

副問合せ

  1. 内側のSELECT文を実行
  2. 1で取得した値を用いて外側のSELECT文を実行

例：

SELECT 宿泊日, 利用料金 FROM 予約明細

 WHERE 顧客コード IN (SELECT 顧客コード FROM 予約 WHERE 担当ID = '100')

相関副問合せ(R2,H31)

EXISTSやNOT EXISTSを使った存在チェックで使用することが多い。

副問合せでは「該当データが存在するかどうか」という結果が分かればいいので、副問合せの列名は「*」を使用する。

  1. 主問合せを実行する(外側のSELECT文)
  2. 1で取得した値を用いて副問合せを実行する(内側のSELECT文)

例：

SELECT 施設ID, 部屋種別ID, COUNT(*) FROM 部屋

 WHERE NOT EXISTS (

  SELECT * FROM 予約明細 WHERE 予約明細.部屋ID = 部屋.部屋ID

    AND 予約明細.宿泊日 >= :チェックイン日付 AND 予約明細.宿泊日 < :チェックアウト日付)

 AND 施設ID = :施設ID AND 部屋種別ID = :部屋種別ID

 GROUP BY 施設ID, 部屋種別ID

 HAVING COUNT(*) >= :部屋数

INSERT

INSERT INTO 予約 (氏名, 日付, 担当者, コースコード) VALUES('山田山男', '2022-03-07', '佐藤佐子', '08')

試験問題では、VALUESの値が書かれているケースは少なそう。

INSERT INTO 予約 (コースコード) SELECT DISTINCT 予約 FROM コース

R1

UPDATE

UPDATA テーブル名 SET 列名 = 変更値, ・・・ WHERE 条件式

試験問題では、変更値がSELECT文になっているパターンが多い。

使用しているテーブル名を見て問題に答えること

DELETE

DELETE FROM テーブル名 WHERE 条件式

WITH(H31)

WITH 副問合せ名 AS (クエリ文)：副問合せ名

UNION(H31)

同じ列名が存在する2つのSELECT文をつなぐ

SELECT 列名A FROM テーブルB UNION SELECT 列名A FROM テーブルC 

重複は1つにまとめる

SELECT 列名A FROM テーブルB UNION ALL SELECT 列名A FROM テーブルC 

重複もそのまま表示する

制約

非ナル制約

ある列にNULLが入らないようにする制約

UNIQUE制約(R2)

指定した列・列の組み合わせが一意であることを強制する制約

主キー制約

指定した列・列の組み合わせに1つだけ主キーを指定

検査制約

指定した列の内容を指定した条件を満足するもののみにする制約

参照制約

参照元テーブルに外部キーを指定する

データウェアハウス設計のスキーマ(R3)

スタースキーマ

1つのファクトテーブルの周囲に、複数のディメンションテーブルが単一の階層で関連付けられる。

ファクトテーブル：分析対象のデータを格納したテーブル

ディメンションテーブル：ファクトテーブルの外部キーから参照する主キーを持つマスタ系テーブル

スノーフレークスキーマ

スタースキーマのディメンションテーブルを正規化(階層化)した構造

データマート(R3)

データウェアハウスに格納されたデータから特定の用途に必要なデータだけを取り出し、構築する小規模なデータベース。

データウェアハウスで分析するのに時間がかかりすぎる場合、データマートを追加する。

つまり「データマートの表を見れば分析できる」という状態がのぞましい。

3層スキーマ

データモデルより前のデータベースの構成（概念スキーマ、外部スキーマ、内部スキーマ）