SQL 検索の基本編

SQL 検索編

 

・基本の形

SELECT

選択列

FROM テーブル名

 

SELECTの後に選択したい列(カラム名)を書きます。AS 〜 とすることで別名にすることができます。ASを付けた場合、AS以下の名前が列名として表示されます。

FROMのあとは、データを取ってきたいテーブル名を書きます。

SELECT shohin_id AS "商品ID",
shohin_mei AS "商品名",
shiire_tanka AS "仕入れ単価"
FROM Shohin;

 

重複行を一つにまとめる DISTINCT

SELECT DISTINCT 列名

FROM テーブル名

同じ値が入っている行については2つ表示するのではなく、1行でまとめます。

SELECT DISTINCT shohin_bunrui
FROM Shohin;

 

行を指定する WHERE

SELECT 列名

FROM テーブル名

WHERE 取得したい条件

下記では、Shohinテーブルからshohin_meiとshohin_bunruiを取得する。条件としてshohin_bunruiが"衣服"のもの。つまりWHERE抜きだと単純にshohin_meishohin_bunruiの列を全行取得しますが、WHEREに続けて条件を書けば、それに合致した行のみ取得できます。

SELECT shohin_mei, shohin_bunrui
FROM Shohin
WHERE shohin_bunrui = "衣服";

 

算術演算子

SQL文の中では四則演算も使えます。

 

SELECT shouhin_mei, hanbai_tanka,
hanbai_tanka * 2 AS '販売単価の2倍'
FROM Shohin;

注意1:

NULLが入っている式は答えが全てNULLになります。

5 + NULL = NULL

10 - NULL = NULL

2 * NULL = NULL

注意2:

データ型が違うものは+ で連結できません。

どちらかデータ型を変換して合わせましょう.

文字型 → 数字型   (できない)

数字型 → 文字型 (できる)

 

比較演算子

=    等しい

<>  等しくない

>=    以上

>      より大きい

<=    以下

<     より小さい

 

hanbai_tankaが1000(円)より大きいものを条件にする

SELECT shohin_mei, shohin_bunrui, hanbai_tanka
FROM Shohin
WHERE hanabi_tanka >= 1000;

日付に使うと、以降、以前など指定できます。

もしCHAR型(文字型)の'3'に指定すると辞書式順序になります。

 

論理演算子

 

〜でないもの AND演算子

hanbai_tankaが1000(円)より大きくないもの

 
SELECT shohin_mei, shohin_bunrui, hanbai_tanka
FROM Shohin
WHERE NOT hanabi_tanka >= 1000;

 

または OR演算子

shohin_bunruiが事務用品または衣服

SELECT shohin_mei, shohin_bunrui, torokubi
FROM Shohin
WHERE shohin_bunrui = '事務用品'
OR shohin_bunrui = '衣服';

ANDとORの組み合わせに注意:

( )で分けないと意図しないデータが取得されます。

( )の中から処理されるので取得したい条件を整理して書きましょう。

以下 、「shohin_bunruiが事務用品」と「登録日が9/11または9/20」となります。

事務用品は必ず取得できます。が()の入れ子を誤ると取得できなくなる可能性も。

SELECT shohin_mei, shohin_bunrui, torokubi
FROM Shohin
WHERE shohin_bunrui = '事務用品'
AND ( torokubi = '2009-09-11'
OR torokubi = '2009-09-20');
 

 

 

 

 

SQL DB・テーブルの作成、編集編

データベース、テーブルの作成、編集

 

SQLはデータベースに指令を出して得たい情報などを取得できる言語なので、

まずはデータベースありきです。

データベース内では様々なテーブルがあり、それら各々のテーブルから、またテーブル同士を結合させるなどして情報を取得します。

データベース、テーブルを作ることもSQLではできるので、まずはそこからまとめていきます。

 

なお、コードの内容については今読んでる参考書のものを引用させて頂きます。

使用するRDBMSSQL serverを想定しています。

 

・データベースを作る

CREATE DATABASE データベース名;

下記ではshopというデータベースを作りました。

C
REATE DATABASE shop;
 

 

・テーブルを作る

CREATE TABLE テーブル名

(カラム名 データ型   制約の設定);

下記、shohinというテーブルを作りました。

その下は例えば、shohin_idカラムで、データ型はCHAR型、さらにNOT NULL制約をつけています。制約については付けなくてもOK。付ければデータの整合性は高められます。反面、制約をかけるのでデータの使い勝手が悪くなるということも。

一番下のPRIMARY KEYは主キーです。今回はshohin_idを主キーにしました。

CREATE TABLE shohin
(shohin_id CHAR(4) NOT NULL,
shohin_mei VARCHAR(100) NOT NULL,
shohin_bunrui VARCHAR(32) NOT NULL,
hanbai_tanka INTEGER ,
shiire_tanka INTEGER ,
torokubi DATE ,
PRIMARY KEY (shohin_id)
);

 

 

・テーブルの削除

DROP TABLE テーブル名;


DROP TABLE Shohin;

 

・テーブルの更新

 

カラムの追加

ALTER TABLE テーブル名 ADD カラム名 データ型

 
ALTER TABLE Shohin ADD shihin_mei_kana VARCHAR(100);
 

 

カラムの削除

ALTER TABLE テーブル名 DROP COLUM カラム名

※追加の時は新規なのでデータ型も指定しますが、削除する時はすでにデータ型はわかっているので指定は不要。

 
ALTER TABLE Shohin DROP COLUMN shohin_mei_kana;
 

 

・テーブルにデータを登録

先ほどまではカラムでしたが、1つのデータつまりレコードを追加します。

INSERT INTO テーブル名 VALUES(カラムに対応する値、カラムに対応する値・・・);

下記の()の中の値は、上記「テーブルを作る」で作ったshohinテーブルのカラム(shohin_id, shohin_mei, shohin_bunrui, hanbai_tanka, shiire_tanka, tourokubi)にそれぞれ対応します。順番はカラム通りに追加されるので、このように全てのカラムに値を入れる際、特に順番やカラム名を指定する必要はありません。

INSERT INTO Shohin VALUES('0001', 'Tシャツ', '衣服',
1000, 500, '2009-09-20');

 

もし、一部のみデータを登録したい場合は、下記のように、どのカラムにどういう値を入れたいという指定をすることができます。逆に、これが基本です。もちろん、全部登録したい時にもカラム名も全部書いても同じですが、上記コードのように省略もできます。一部だけの時はちゃんと指定しないとどのカラムに入れたらいいのか分からないので登録できません。

 
INSERT INTO Shohin
(shohin_id, shohin_mei)
VALUES('0001', 'Tシャツ)

 

次回は「検索の基本編」です

 

 

 

SQL 基本編

SQLを勉強中なので、学んだ内容を何回かに分けてまとめていきます。

 

第一回 基本編

1、SQLを書くにあたって、自分なりに重要だと思ったこと

2、SQLの流れ(順番)

3、型

 

 

1、SQLを書くにあたって、自分なりに重要だと思ったこと

・読みやすいように改行や、インデントをつける(所属する組織、チームのコーディング規約に従う)

 

・テーブル名に別名をつける

 AS  T1やAS  T2など別名をつければ見た目もスッキリし見やすくなる。また書く手間も省ける

 

・関数を全て覚える必要はない

関数は多く、またRDBMSによって使える、使えないがあり統一されていないので、今やりたい処理は何か整理し、リファレンスなどで都度調べればOK。もちろんよく使う関数は覚えておけば便利。

 

・文が長くなる場合、処理ごとにパーツに切り出して考えると整理しやすい

例えば、サブクエリなど、別途その部分だけSQL文を書き取得したい情報がちゃんと取れるか確認してみるなど。

 

2、SQLの流れ(順番)

処理実行の順番

FROM

JOIN

WHERE

GROUP BY

SUM, AVGなど

HAVING

SELECT

DISTINCT

ORDER BY

LIMIT

 

記述の順番

SERECT

FROM

WHERE

GROU BY

HAVING

ORDER BY

 

3、型

INTEGER  整数

CHAR 固定長文字列(文字数が最大長になるまで空きを半角スペースで埋める)

VARCHAR 可変長文字列

8/11からシステムエンジニア

8/11付で新たな職場に転職します。

 

半年前に前職を退職し、プログラミングスクールで学習〜転職活動を経て新しい仕事を始めます。

今回は職種も変わりまた一からのスタートですが、毎日自己投資して成長していきます。

引き続きブログも書いていきます。

具体的な職務内容は書けませんが、学んだ技術についてアウトプットをしていきます。

 

ちなみに、今はデータベースやSQLなど自習中です。

また改めて、ブログにまとめます。

 

 

IT JAPAN 2019

IT JAPAN 2019

 

7/10(水) ~ 7/12(金)に日経BP主催で品川プリンスホテルで開催されたIT JAPAN 2019に行ってきました。

テーマは

「DXで臨む新時代 日本の競争戦略 次の一手

IT企業を中心に様々な企業の社長、CTOらが約1時間ずつ、昨今のIT業界の潮流、未来の予測、自社のデジタル戦略などについて公演されました。

https://tech.nikkeibp.co.jp/event/itjapan/2019/info/

自分が聴いた企業の公演は下記:

ANA

シスコシステムズ

・日鉄ソリューションズ

日本郵船

・日本ヒューレット・パッカード

・アマゾン ウェブ サービス ジャパン

アクセンチュア

・KPMGコンサルティング

(元レスリング選手 吉田沙保里氏 トーク

 

NTTデータ

・Box Japan

日本瓦斯

・HENNGE

日本IBM

・デロイト・トーマツ・グループ

・Sansan

 

Dell Technologies

日本オラクル

・IT企業役員兼小説家 上田岳弘氏

日立製作所

・日本マイクロソフト

 

印象に残った内容をメモから抜粋します。

 

シスコシステムズ

Ciscoはオリンピックのネットワークスポンサー(ローカルスポンサー)

ネットワークインフラストラクチャーの構築を担う

 

五輪毎に変わる技術

ロンドン五輪:大規模なWifiネットワークが実装される

リオ五輪:10億以上のサイバー攻撃を受けたがCiscoにより全てブロックされた

 

東京大会:全会場のネットワークの構築を担う IPが送られていくる

求められること:

・パケットが滞ってはいけない

・安全、安定が求められる

 

64年の東京五輪はどうだったか

社会インフラが建設された

→高度経済成長へ 首都高、新幹線

 

20年の東京五輪後に何を残すか

「デジタル社会インフラ」

箱物だけでなく、箱物にデジタルの技術を付加しハードウェアを陳腐化させないように

 

カントリーデジタイゼーション

Society5.0 (政府)

Ciscoも4分野に注力

・TT&T  (サイネージなど)

・インダストリー4.0

・デジタルワークプレイス

・パブリックセーフティ

 

 

日本ヒューレット・パッカード

アヤックス 大物選手を獲得するのではなくテクノロジーに投資して選手育成。

規模では他の欧州のビッグクラブに対抗できないので、選手の育成→移籍により移籍金を得るスタイル。

センサーなどを使い選手の動きを分析。またコンディションについても高度ITで管理し、的確なアドバイスができる。

(個人的にサッカーは好きで、この前のCLもアヤックスに注目していたので、大変興味深かった)

 

電力について:

クラウドだけで日本1国分の電力を消費する

 

データ使用量について:

94%のデータは使われていない(捨てられている)

 

 

アマゾン ウェブ サービス ジャパン

It’s still day one

「毎日が初日のようにフレッシュな気持ちで出社しよう」

 

何を提供したいかではなく、お客様が何を求めているかから逆算して考える

 

お客様にこだわり続ける

長期思考(決算期に囚われない)

先駆者であること

 

Frugality:

100万で100人集める→10万で100に集める方法を考える→100万あれば1000人集められることになる

 

AWSが大事にしていること:

意思決定のスピードを速める

意思決定には2通りある

1、一方通行で後戻りできないこと →  緻密な分析、データ、リスクをとる、慎重に決断

2、戻ることができる(ほとんど) →  60~70%で思い切って動く。失敗したら戻って来ればいい。 

 

お客様は誰か?

客の課題や新しい可能性は?

提供できる価値を明確化

ニーズやウオンツをどう知ったか

 

クラウドの特徴:

・コストが安く済む

・スピード(解を出すのが早くなる(時間とソリューションを手に入れられる)

AWSの主要サービス:EC2(バーチャルサーバー))

 

 

アクセンチュア

デジタルの世界

IT業界は変化が早く5年後先までしか予測できないと言われてきたが、今は3年先までしか予測できない。

 

やれることではなく、やらなければならないことを考える

 

SMACからDARQへ

平成:SMAC=ソーシャル、モバイル、アナリティクス、クラウド

令和:DARQ=分散型台帳、人工知能、拡張/強化現実、量子コンピューティング

 

ITで繋がる世界:

ウッドストックフェス=40万人が集まり伝説となったが、

→ 今、VRで1000万人が同時にリアルタイムでフェスに参加できる 新たな伝説へ

 

量子コンピューターの可能性

デンソーの例:

交通渋滞を瞬時に計算し、配送を調整する

 

AIの活用

Googleの例:

プラットフォームとAIがゲーム体験を変革

人はAIとも対戦できる

=ユーザーにお金を払わして、同時にAIを強化させることが可能

 

Slice pay:

ユーザーのクレジットスコアを作成

 

ドミノピザの例:

あらゆるチャネルで注文できる

全注文の50%はデジタル

 

生活習慣、住居環境など、あらゆるデータを分析し、その人がどんな人か細かく分かってしまう世界へ(ちょっと気味悪い。)

どこまでのデータを収集し、どのように使うのかを考えることが求められる

 

採用活動について:

従来は色がない新卒を雇う

→今後は、テクノロジーが応募者のポテンシャルを見極め、人材を適材適所に置く

 

ユニリーバの例:

ゲーム選考、デジタル面接により、性格、タイプ、適性を判断

 

アクセンチュア

AIロボットと協働している(相棒)

(slackでロボットが話しかけてくる)RobotPMO

 

ウェアラブル端末のエピソード:

某国の軍人が身につけていたウェアラブルのフィットネスアプリのせいで軍事拠点がバレた

 

 

KPMGコンサルティング

 

ITシステム「2025年の壁」

経営のレジリエンスが求められている

 

レジリエンスとは?

七転び八起き(機動性、柔軟性、弾力性、稲穂のように)・アジャイル

 

レジリエンス時代に即した企業文化とは?

理想:

失敗から学ぶ社風を作りたい

 

日本企業は「目先の業務の自動化を優先し、根本的な業務改革に遅れる可能性がある」

以下、調査内容:

今後5年以内に自動化導入したいと考えている企業:

日本:73%

中国:55%

アメリカ:36%

 

今後3年以内に根本的に業務を変革したい

日本:23%

中国:48%

アメリカ:43%

 

推察:

日本は保守的なレジリエンスになっているのでは

・明確なゴールがない

・目先の短期的な対応に終始している

 

 

デジタルリーダーが重要視していること

・エコシステム

・スピード重視

・オープンマインドセット

・データ重視

 

サイバー戦略:

過去2年攻撃受けた国の割合:

日本:56%

中国:33%

アメリカ:31%

 

サイバーは競争優位性を生み出す重要な戦略かと考える企業

日本:55%

アメリカ:80%

 

見えないものとの闘い

 

人材

デジタル人材の不足

 

新しいテクノロジーと人材のスキル強化

どっちに投資?

(日本企業)

人材:32%

テクノロジー:68%

 

ダイバーシティのマネジメント

多種多様な経験、知見、価値観

 

世界的にESG, SDGsへの取り組みが高まっている

 

 

NTTデータグループ

写真では見る角度によって、取得する情報が違う(英国王子の例)

切り取りによって、嘘ではないが真実ではない

 

Data

Information

Inteligence

自律的な社会

 

PEST分析

情報社会トレンド 

  デジタル化による主導権シフトが社会の仕組みを変革する

  この影響力拡大が新たな価値の源泉を生み出す

  技術がもたらす洗剤課題が意識や行動の変化を促す

  循環視点の連携が持続可能な社会を実現する

 

工場の新人:

ARゴーグルで立体的にマニュアルが見れる 実際に動いている様子も見れる

 

Box Japan

企業向けSaasを提供

 

ユニコーン企業はどの国に多いか:

米国、中国が圧倒的(2カ国で9割を占める)

次いで

インド

韓国

インドネシア

香港

日本

 

2025年の壁:

基幹システムの稼働期間が21年以上になる企業の割合が20%に

レガシーシステムは保守はしたくない」というエンジニアが多くなる?

 

団塊世代の方が後期高齢者になり介護離職

 

デジタル化への取り組み

デジタル化は2種類:プロセスとサービス

検討すらしていない企業:

プロセス:3割

サービス:5割

 

BOXユーザーとして金融機関、官公庁が多いが、同時に厳しい要望を受けている

1、データーは国内に置くべし

2、VPNを設置するべし

→もともと米国にデータを置いていたが、日本にも置くようにした

 

来春から5G始まるが:

超高速、超低遅延、多数同時接続が実現されると社会はどう変わっていくのだろうか

 

 

 

 

 

個人アプリまとめ

勉強も兼ねて家計簿アプリを作りました。

細かい部分で修正が必要ですがここで一旦、個人アプリ開発に取り組んでみた感想をまとめます。

 

①よかったこと

②難しかったこと

③改善できるところ・反省点

 

概要:

アプリ内容:家計簿アプリ

使用言語・フレームワークRuby on Rails

 

①よかったこと

考える力、想像する力を鍛えられた

今回は、課題を与えられてないので何のアプリを作るのかというところから自分一人で考えました。そしてアプリに必要な機能は何か(必須なもの、応用的なもの)、それらを実装するために必要な処理の流れを考え全体の設計をしました。また、家計簿アプリは分析ツールであるため、データが非常に重要です。そのためDB設計にもかなり神経を使いました。チーム開発も勉強になりましたが、一連の処理を自分一人で考えたことは非常に鍛えられました。3ヶ月間スクールで課題に追われながら、何とかやりきったのが精一杯でしたが、個人のアプリを開発することで、いい復習にもなりましたし、少しずつ勉強したことが繋がってきています。

 

 

②難しかったこと

よかった点で、自分で考えれたということを書きましたが、同時にそれは難しいことでもありました。「自分の考えたアプリを作る」ということは自由度が高い分、何から手をつければいいかわかりませんでした。もちろん設計〜開発という流れはありますが、細かな部分をどう進めれば良いか分かりませんでした、またスクールの課題で開発したクローンサイトのように見本がないので、機能の抜け漏れもあり、手戻りも結構ありました。ゲームで例えるとオープンワールドみたいな感じですかね。自由だけど何していいか分かんないみたいな

 

また、「設計」にどれだけこだわるかという点。

自分は元々、完璧主義なところがあるので、スクールに通うにあたってそこは意識して捨てるようにしました。多分まだ残ってますが。今回の個人アプリも設計を固めてから開発始めたいという想いはありましたが、完璧主義すぎていつまでも開発が始まらないという懸念がありましたので、今回は実験的に、大まかに作って仮で開発をスタートさせてみることにしました。だいたい1週間掛けました(毎日ずっと考えてたわけではありませんが)。案の定抜け漏れ、矛盾などわんさか出てきます。

経験を積んで、設計〜開発の流れもスムーズにできるようにしていくのが1つの目標です。

 

 

③改善できるところ・反省点

バリデーション:

「月ごとカテゴリー毎に金額を計算し、合計金額を表示する」という機能をつけました。この時、データベースに値が入っていない時、ページを表示しようとしてもエラーになりますので、値が入っていない(nil)の時は、¥0を返すように設定しています。

それ以外にまだ設定していないところがいくつかあります。

・「予算設定」では何回も同じ年・月に金額を設定できてしまうので、2回目はできないようにする→「すでに設定されています」の表示や、編集ページに飛ばすなどの対策が必要。

・収入、支出入力ページで値が入力されなかった時のバリデーション。

 

データの取り方、加工のしかた:

上述の月ごとにカテゴリー毎に金額を計算し、合計金額を表示するという機能について、そのコードは修正の余地ありです。

検索結果は以下のように表示されます。

 

f:id:Arts91:20190708214210p:plain

 

そしてコードは、

def show
 
@search_year = params[:year]
@search_month = params[:month]
detail_year = @search_year
detail_month = @search_month

# 以下問題ありコード。修正を検討する
# 長すぎる
# カテゴリーIDを1つずつ取ってきているため、もしユーザーが独自にカテゴリーを追加できる機能をつける場合、対応できない
 
#収入計算
@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
@income_detail_saraly[[@search_year.to_i, @search_month.to_i]]
@income_detail_saraly_view = @income_detail_saraly[[@search_year.to_i,
@search_month.to_i]]
 

まず@income_detail_saralyに入っているのはデータベースの収入テーブルの給与カラムの合計金額。ここでは月ごとにハッシュ形式で取得できてますので、ページで年、月を選択すると、その対象となる期間の合計金額を表示させるという流れです。

問題はカテゴリーを一つずつ取ってきているということ。

影響1:

1カテゴリーのデータを取得するのに数行書いていますので、複数のカテゴリーについて書くとコードが非常に長くなり、見ずらくなる。いわゆるファットコード。

影響2:

1つずつコードを書いてカテゴリーのデータを取得しているということは、仮に将来、

「ユーザーが自分で好きにカテゴリーを作り追加できる」という機能を追加したいと思った時に対応できない。柔軟性に欠けます。

 

DB設計:

データベース設計もまだまだです。

例えば、家計簿アプリなので、いろんなところで日付を扱いますが、カラムの型がバラバラで、日付をもとにデータを検索する際に、いちいち日付を認識できるようにコードを書く手間が掛かりました。

@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
 

group.("YEAR(date)").group("MONTH(date)")と書かないと、日付がうまく認識されず検索がうまくいきません。

あとは、収入用のカテゴリーと紐付けるcategory_idカラムを作り忘れ、途中で追加しました。途中でも追加、編集はできるとは言え、最初の段階でがっちり固められるようになりたいです。

 

gitの扱い

スクール似通っていた時から、gitの作業はGUIgithub desktop)を使っていました。バージョンが古く、新しくしたかったのですがなぜか上手くいかずそのまま使いました。新しいバージョンになれるように、今からでも使いたいです。また、GUIだけでなくコマンドでも作業がスムーズにできるよう慣れていきたいです。

 

以上