Shironan Memory

いろいろかきます

H30データベーススペシャリスト試験午後2問2解説

今年の春にデータベーススペシャリスト試験を受けました。

 

でこの間結果発表の日で!!

 

 

無事受かりました!!🎊🎊🎊

 

で、受かったから良いのだけれども午後2の問題ワルスギィ!ってことなので

ちょっと復習も兼ね、自分なりの解説をここに残しておきたいと思います。

 

ちなみに

平成30年春期データベーススペシャリスト試験で

午後2 問題 解説 私が選んだ問は問2

です。

 

午後2復習

問2.受注、製造指図、発注、入荷業務の概念データモデリングに関する次の記述を読んで、設問に答えよ。

 

問題文が長すぎて、この問題の趣旨が何か分かりずらいなあと思ったのでまとめてみた。

 

▼製菓ラインを稼働させるために必要なユニット、すり合わせ部品及びユニットの設置・試運転を設計、調達、製造し提供している製菓ラインのメーカのシステムを再構築する。

 

▼再構築するシステムで

・自社の組織管理

・取引先の管理

・品目の整理

・品目の在庫管理

・商談と受注の関係性を管理

・受注と品目の関係性を管理

・受注と所有量の関係を管理

・製造の管理

・発注・入荷の管理

ができるDBを設計する

 

▼品目の整理

実務経験ないからか頭悪いからかわからないけれど、品目の仕組みを理解するのに苦労した。。

てことでこの問題で出されている品目についてまとめてみます。

ーーーー参考問題文ーーーーー

4品目・在庫

(1)品目

①品目とは、E社が提供する製品及びサービスのことであり、品目コードで識別する。品目には、全体設計、ユニット、中間仕掛け品、構成部品、すり合わせ部品、ソフトウェア、設置・試運転がある。

②品目には、受注品目(得意先から受注する品目)、投入品目(製造に必要な品目)、製造品目(自社で製造する品目)、発注品目(仕入れ先に発注する品目)がある。

③製造品目ごとに、どの投入品目が幾つ必要なのかをまとめたものを、品目構成という。

④発注品目ごとに、仕入れ先が1つ決まっている。

ーーーーーーーーーーーーー

 

??????(・・?

って感じですよね。品目は一体何種類なのっていう。。。

分からないときは関係スキーマをみてみます。

 

ーーーー参考問題文ーーーーーー

品目(品目コード、品目名、製造品目フラグ、発注品目フラグ、受注投入品目区分)

受注品目(品目コード、標準販売単価)

投入品目(品目コード、投入方法)

製造品目(品目コード、製造ロット数量)

発注品目(品目コード、標準仕入単価、納入リードタイム、発注ロット数量、仕入れ取引先コード

在庫(品目コード、実在庫数量...)

 

ーーーーーーーーーーーーー

 

上記の関係スキーマの書き方からわかること

・品目がスーパータイプで、様々なサブタイプが存在する。

・スーパータイプ品目のカラムに「受注投入品目区分」があることから品目は受注品目か投入品目のいずれかにあてはまること。

・スーパータイプ品目のカラムに「製造品目フラグ」「発注品目フラグ」があることから品目は製造品目や発注品目に分類することができること。

 

つまり品目は受注品目か、投入品目のいずれかである、また製造品目や発注品目に分類することができる ということがわかります。

 

また 「品目には、全体設計、ユニット、中間仕掛け品、構成部品、すり合わせ部品、ソフトウェア、設置・試運転がある」ということから

全体設計、ユニット、中間仕掛け品、構成部品、すり合わせ部品、ソフトウェア、設置・試運転 受注品目か、投入品目のいずれかであり、また製造品目や発注品目に分類することができる。 ということも以上のことからわかります。

 

 

設問(2)の問題の表をみるとわかりやすいとおもいます。

 

f:id:tn-mi:20180623002634j:plain

 

 ではこの設問(2)の問題を解きながら

購買ユニット、中間仕掛品、構成部品、専用すり合せ部品、汎用すり合せ部品、ソフトウェア、設置・試運転 はどのサブタイプに該当するのか考えていきます。

 

 

 

~受注・投入品目の分類~

まず 22ページ

(2)在庫

①投入品目である中間仕掛品と構成部品は在庫をもつ。

という記述から中間仕掛品と構成部品は投入品目 ということがわかります。

また品目は受注品目か、投入品目のいずれかであるという定義から

中間仕掛品と構成部品以外は受注品目である。ということがわかります。

そのため

 

受注品目:購買ユニット、専用すり合せ部品、汎用すり合せ部品、ソフトウェア、設置・試運転

投入品目:中間仕掛品、構成部品

 

という分類ができます。

 

~製造品目・発注品目の分類~

ーーーー参考問題文ーーーー

②製造指図には、次の分類がある。

・ユニット製造指図

・すり合わせ部品製造指図

・ソフトウェア製造指図

・中間仕掛品見込製造指図

・中間仕掛品製造指図

~~~~~

②発注には次の分類がある。

・ユニット発注

・すり合わせ部品発注

・ソフトウェア発注

・構成部品定量発注

・構成部品都度発注

ーーーーーーーーーーー

 

・購買ユニット

ココをみてユニットは製造品目と発注品目があることがわかります。

23ページ(ⅱ)ユニット受注明細には(中略)記録する。内製ユニットの場合は受注明細を基に製造を指図する。購買ユニットの場合は仕入先に発注する

という記述からユニットは内製ユニットと購買ユニットに分別されることがわかります。

また下線から購買ユニットは発注品目であることわかります。

したがって購買ユニットは受注品目であり、発注品目でもあることがわかります。 

 

 ・中間仕掛品

ココをみて製造指図する項目に中間仕掛品が含まれてることがわかります。したがって中間仕掛品は投入品目であり、製造品目であることがわかります。

 

・構成部品

ココをみて発注する項目に構成部品が含まれていることがわかります。したがって構成部品は投入品目であり、発注品目であることがわかります。

 

・専用すり合わせ部品と汎用すり合わせ部品

ココを見てすり合わせ部品は製造品目と発注品目があることがわかります。

23ページ すり合わせ部品設計には、汎用品を使うか専用品が必要かを区別する専汎区分を記録する。汎用すり合せ部品を使う場合は仕入先に発注し、専用する合わせ部品が必要な場合は製造を指図する。

 という記述からすり合わせ部品は汎用すり合わせ部品と専用すり合わせ部品に分別されることがわかります。

また下線から専用すり合わせ部品は製造をするもの、汎用すり合わせ部品は発注するものということがわかります。

したがって

専用すり合わせ部品:受注品目であり、製造品目である。

汎用すり合わせ部品:受注品目であり、発注品目である。

ということがわかります。

 

・ソフトウェア

ココをみてソフトウェアは製造品目と発注品目があることがわかります。

したがってソフトウェアは受注品目であり、製造品目、発注品目である。

ということがわかります。

 

・設置・試運転

 製造指図や発注に特に記述されていないことから 製造品目、発注品目に分類されていないことがわかります。

したがって設置・試運転品目は受注品目であることがわかります。

 

以上のことから設問(2)の問題の答えは

f:id:tn-mi:20180623133613j:plain

であることがわかります。

こんな感じで品目について整理してみました。

これを文章から読み解くのはむずかしい...(-ω-;)ウーン

なんて思いました。 

 

 

 

問題の趣旨と概要については以上でLet’s設問!

 ※設問(2)は省きます。

 

設問(1)表1中のア、イに適切な字句を入れて、表を完成させよ。

 

f:id:tn-mi:20180622225039j:plain

中間仕掛品の受注を受けて所有量展開した結果によって、さまざまな指図や発注が必要になるのでその判断を確認する決定表。

 

アについて

表から 内製ユニットを受注し、構成部品は引き当てることができたが中間仕掛品はすべて引き当てできていない 場合ということがわかる。

つまり中間仕掛品が不足しているということがわかる。

24ページ問題文(3)④在庫引き当て後、中間仕掛け品が不足する場合には、後述する製造指図を行い、(略)

から中間仕掛品が不足する場合は、製造指図を行わなければいけないことがわかる。

したがってアの答えは「中間仕掛品の製造を指図する」である。

 

イについて

アと同じ要領で解いていく。

表から 内製ユニットを受注し、中間仕掛品は引き当てることができたが構成部品はすべて引き当てできていない 場合ということがわかる。

つまり構成部品が不足しているということがわかる。

24ページ問題文(3)④在庫引き当て後(中略)構成部品が不足する場合には、後述する発注を行う。

から構成部品が不足する場合には、発注を行わなければいけないことがわかる。

したがってイの答えは「構成部品を発注する」である。

 

設問(3)図1中のあ~うに入れるエンティティタイプ名を答えよ。また、図1中で欠落している、リレーションシップ及び発注のサブタイプを補って、概念データモデルを完成させよ。

 

あについて

f:id:tn-mi:20180623150651j:plain

図から取引先テーブルがスーパータイプで取引先テーブルのサブタイプが複数できていることがわかります。

21ページ(3)取引先には、販売相手の得意先と、購買相手の仕入先がある。取引先が得意先と仕入先のどちらに該当するかは、取引先区分で分類している。取引先と仕入先の両方に該当する取引先は存在しない。

という記述から取引先と仕入先どちらのテーブルも必要なことがわかります。

したがって あの答えは取引先が該当します。

 

いについて

 f:id:tn-mi:20180623225637j:plain

22ページ問題文 ②商談は商談#で識別し...

から い の答えは商談であることがわかります。

 

うについて

関係スキーマを作成しながら考えます。

 

設問(3)の続き概念データモデルを作成する問題ですが。

個人的に設問(4)の関係スキーマを作成して、関係スキーマを参考に概念データモデルを作成する方が効率が良いと思っているので先に設問(4)から解いていきます。

 

設問(4)図2中のa~rに適切な一つまたは複数の属性名を入れ、更に図2中の下部の空白部分に、(以下略)

f:id:tn-mi:20180623230320j:plain

aについて

21ページ問題文

(1)部門は、部門コードで識別する。部門は階層構造であり、下位の部門は上位の一つ部分に所属する。

下線から部門テーブルに上位部門コードカラムが必要なことがわかる。

したがってaの答えは上位部門コードである。

 

bについて

(3)取引先には、販売相手の取引先と、購買相手の仕入先がある。取引先が得意先と仕入先のどちらに該当するかは、取引先区分で分類している。得意先と仕入先の両方に該当する取引先は存在しない。

下線から取引先テーブルに取引先区分カラムが必要なことがわかる。

したがってbは取引先区分である。

 

cについて

得意先(取引先コード、c)

(4)得意先には、契約先と出荷先がある。契約先とは、販売に関して契約を交わす部門であり、出荷先とは、販売した製菓ラインを納める部門である。契約先は契約先フラグで識別し、出荷先は出荷先フラグで識別する。一つの得意先が契約先と出荷先を兼ねることもある。

下線から得意先テーブルに契約先フラグと出荷先フラグ両方カラムが必要な事がわかる。

したがってcは契約先フラグ、出荷先フラグである。

 

f:id:tn-mi:20180624210206j:plain

 

dについて

商談(商談#、d)

22ページ5(1)②商談は、商談#で識別し、案件名、案件内容、商談年月日、商談相手の契約先、商談を担当する技術営業社員を記録する。

下線通り、dの答えは案件名、案件内容、商談年月日、契約契約先コード技術営業社員コードである。

 

eについて

23ページ⑤(ⅰ)全体設計受注明細には全体設計内容を記録する。

とあるからeの答えは、全体設計内容である。

 

fについて

23ページ⑤(ⅱ)ユニット受注明細には、ユニットが製菓ラインの何番目で使われるのかを表す工程順を記録する。(以下略)

下線通り、fの答えは工程順である。

 

gについて

23ページ⑤(ⅲ)すり合わせ部品受注明細には、すり合わせ箇所を記録しておく。

とあるからgの答えは、すり合わせ箇所である。

 

hについて

24ページ⑤(ⅳ)ソフトウェア受注明細には、詳細仕様を記録する。

とあるからhの答えは、詳細仕様である。

 

iについて

24ページ⑤(ⅴ)設置・試運転受注明細には、開始予定年月日、終了予定年月日を記録しておく。

とあるからiの答えは、開始予定年月日、終了予定年月日である。

 

f:id:tn-mi:20180624210323j:plain

 

jについて

23ページ⑤(ⅲ)問題文

・すり合わせ部品設計は、設計#で識別する。すり合わせ部品は受注明細ごとに、設計#を一つ割り振る。

・すり合わせ部品設計には、汎用品を使うか専用品が必要かを区別する専汎区分を記録する。

下線からすり合わせ部品の受注(受注明細)ごとに設計テーブルを作成すること、および汎用品か専用品か設計テーブルにて区別することがわかる。

したがってjの答えは、受注受注明細、専汎区分である。

 

kについて

24ページ⑤(ⅴ)問題文

・設置・試運転受注明細を基に設置・試運転指示を行う。複数の指示に分かれることもある。

・設置・試運転指示は、設置・試運転指示#で識別し、指示年月日を記録する。

下線から設置・試運転指示テーブルに受注明細を対応づけること、指示年月日カラムが必要なことがわかる。

したがってkの答えは受注受注明細、指示年月日である。

 

lについて

25ページ②(ⅰ)ユニット製造指図は、受注明細の受注数量がそのまま製造指図数量となる。

という記述からユニット製造指図テーブルと受注明細テーブルを対応づけることが分かる。

したがってlの答えは受注受注明細である。

 

mについて

25ページ②(ⅱ)すり合わせ部品製造指図は、受注明細の受注数量がそのまま製造指図数量となる。どのすり合わせ部品設計に基づくのかの設計#を記録する。

という記述からmの答えは設計#であることがわかる。

ちなみに受注と受注明細は。。。と考えるかもしれないが、外部参照される設計テーブルに記録されているため(すり合わせ部品受注明細ごとに、設計#を一つ割り振る から)すり合わせ部品製造指図テーブルに受注明細の記録は不要。

 

nについて

25ページ②(ⅲ)ソフトウェア製造指図は、受注明細の受注数量がそのまま製造指図数量となる。納品方法を記録する。

という記述から、受注明細と対応づけること及び納品方法を記録することがわかる。

したがってnの答えは受注受注明細、納品方法である。

 

оについて

中間仕掛品見込製造指図(製造#、o)

25ページ②問題文

(ⅳ)中間仕掛品について、”製造リードタイムが長い”、”構成部品の発注ロケットサイズが大きい”などの条件に該当する場合、製造部門の判断で製造を指図し、在庫をもつ場合がある。これを中間仕掛品見込製造指図と呼ぶ。製造部門が、製造する品目、製造指図数量、優先度を決定し、記録する。

下線から中間仕掛品見込製造指図テーブルが必要なのがわかり、製造品目、製造指図数量、優先度を記録することがわかる。

したがってoの答えは製造品目コード、製造指図数量、優先度である。

 

pについて

中間仕掛品製造指図は、1日分の所要量展開の結果を基に行い、対象の所要量展開の結果に同じ品目が複数件ある場合には、1件の製造指図にまとめる。品目、製造指図数量を記録する。(以下略)

oとテーブル名が似ていて(・・?ってなりますが、

見込み製造指図は優先度つけて記録できるテーブルで、所要量展開の結果による製造指図は見込みとは別のテーブル それぞれで管理するってことですね。

下線からpの答えは製造品目コード、製造指図数量であることがわかる。

 

発注のサブタイプの関係スキーマを追加

ーーーー参考問題文ーーーー

発注(発注#、発注年月日、発注区分)

25ページ(5)②発注には次の分類がある。

・ユニット発注

・すり合せ部品発注

・ソフトウェア発注

・構成部品定量発注

・構成部品都度発注

ーーーーーーーーーーーーー

 

26ページ(ⅰ)ユニット発注は、受注明細の受注数量がそのまま発注数量となる。仕入先から出荷先に、直接納入するかどうかの直納区分を記録する。

という記述からユニット発注と受注明細の対応付け、および直納区分の記録が必要な事がわかる。

したがってユニット発注(発注#受注#受注明細#、直納区分)というサブタイプが必要。

 

 (ⅱ)すり合せ部品発注は、受注明細の受注数量を基に発注ロットサイズを加味して、発注数量を決定する。どのすり合わせ部品設計に基づくのかの設計#を記録する。

という記述から、すり合せ部品は発注ごとに発注数量がきまる(=発注の際に発注数量を記録しなければいけない)こと、及びすり合せ部品設計テーブルとの対応付けが必要なことがわかる。

したがってすり合せ部品発注(発注#設計#、発注数量)というサブタイプが必要。

受注明細への対応付けは外部参照されているすり合わせ部品設計テーブルに記録されているため不要。

 

(ⅲ)ソフトウェア発注は、受注明細の受注数量がそのまま発注数量となる。瑕疵担保期間を記録する。

という記述からソフトウェアの発注と受注明細を対応づけること、および瑕疵担保期間を記録することがわかる。

したがってソフトウェア発注(発注#受注#受注明細#、瑕疵担保期間)というサブタイプが必要。

 

(ⅳ)一定量の在庫をもつ方針の構成部品については、構成部品定量発注を行う。品目ごとの実在庫数量が発注点を下回ったときに、定められた数量を発注する。品目、発注数量、発注時在庫数量を記録する。

という記述から一定量の在庫をもつ方針の構成部品に対する発注テーブルが必要な事、及びそのテーブルに品目、発注数量、発注時在庫数量を記録することがわかる。

したがって構成部品定量発注(発注#発注品目コード、発注数量、発注時在庫数量)というサブタイプが必要。

 

(ⅴ)一定量の在庫をもたず、都度発注する方針の構成部品については、構成部品都度発注を行う。1日分の所要量展開の結果を基に発注ロットサイズを加味して、発注数量を決定する。対象となる所要量展開に同じ品目が複数件ある場合は、1件にまとめて発注する。品目、発注数量、希望納入年月日を記録する。(以下略)

という記述から一定量の在庫を持たない構成部品用の発注テーブルが必要なこと、そのテーブルに品目、発注数量、希望納入年月日を記録することがわかる。

したがって構成部品都度発注(発注#発注品目コード、発注数量、希望納入年月日)というサブタイプが必要なことがわかる。

 

 

f:id:tn-mi:20180625014308j:plain

 

rについて

所要量展開テーブルについて

・24ページ③所要量展開の結果は、受注#、受注明細#、所要量明細#の組合せで識別し、必要品目、必要数量、引当済数量を記録する。という記述から、所要量展開の結果を記録するテーブルであることがわかる。

・24ページ④在庫引当後、中間仕掛品が不足する場合には、後述する製造指図を行い、構成部品が不足する場合には、後述する発注を行う。という記述から、製造指図や発注と関連付けるテーブルであることがわかる。

・25ページ(ⅴ)(前略)所要量展開には、どの製造指図にまとめられたかの製造#を記録する。という記述から製造#を記録することがわかる。

・26ページ(ⅴ)(前略)所要量展開には、どの発注にまとめられたかの発注#を記録する。という記述から発注#を記録することが分かる。

またここでいう所要量展開の品目は

24ページ問題文製造品目に必要な投入品目とその数量を、品目構成に基づいて求めることである。

という記述から投入品目の所要量展開であることがわかる。

したがってrの答えは

所要量明細#投入品目コード、必要数量、引当済数量、発注#製造#である。

 

 

うとqについて

問題文を見ながら解いていけば一目瞭然、入荷についてのテーブルがないことがわかる。

また問題文構成からも

5業務の内容の項目(1)商談(2)受注(3)所要量展開(4)製造指図(5)発注(6)入荷 とあるが(6)入荷についてのテーブルだけが関係スキーマに記述されていなことがわかり、入荷についてのテーブルが必要なことがわかる。

26ページ(6)入荷

①発注に基づいて、仕入先から品目が入荷される。入荷は入荷#で識別し、入荷年月日、入荷数量、どの発注に該当する入荷であるかを記録する。

②1件の発注において、仕入先の在庫不足などで、数量の一部だけが入荷され入荷が分割される場合がある。ただし、複数の発注が1件の入荷にまとめられることはない。

という記述から うとqの答えは

う.入荷

入荷(入荷#、入荷年月日、入荷数量、発注#

であることがわかる。

②の問題文については発注#を主キーにしなくていいぜ ということ。

 

 ここまでを整理すると関係スキーマ

f:id:tn-mi:20180625104548j:plain

こうなることがわかる。

これを参考に概念データモデルを作成していく。

 

問題文から発注サブタイプが欠落していることがわかる。

そのためまず発注のサブタイプ、ユニット発注、すり合せ部品発注、ソフトウェア発注、構成部品定量発注、構成部品都度発注を追加する。

 

部門テーブル

上位部門コードカラムがあり外部参照していることから自分自身に1:多のリレーションシップが必要な事がわかる。

 

得意先テーブル

契約先フラグ、出荷先フラグがあることから契約先テーブルと出荷先テーブルへ親子関係のリレーションシップが必要なことがわかる。

 

品目テーブル

・受注投入品目区分があることから、受注品目テーブルと投入品目へ親子関係のリレーションシップが必要なことがわかる。

・製造品目フラグ、発注品目フラグがあることから、製造品目テーブル、発注品目テーブルへの親子関係のリレーションシップが必要な事がわかる。

 

発注品目テーブル

仕入取引先コードを外部参照していることから仕入先テーブルへの1:多のリレーションシップが必要なことがわかる。

 

商談テーブル

契約取引先コード、技術営業社員コードを外部参照していることから契約先テーブルおよび、社員テーブルへ1:多のリレーションシップが必要なことがわかる。

 

受注テーブル

商談#、出荷取引先コードを外部参照していることから商談テーブルおよび、出荷先テーブルへの1:多のリレーションシップが必要なことがわかる。

 

受注明細テーブル

受注品目コードを外部参照していることから、受注品目テーブルへの1:多のリレーションシップが必要なことがわかる。

 

すり合せ部品設計テーブル

受注#、受注明細#を外部参照している。および23ページ問題文(ⅲ)・すり合わせ部品設計は、設計#で識別する。すり合せ部品受注明細ごとに、設計#を一つ割り振る。とあることからすり合わせ部品設計テーブルとすり合わせ部品受注明細テーブル間で1:1のリレーションシップが必要なことが分かる。

 

設置試運転指示テーブル

受注#、受注明細#を外部参照している。および24ページ問題文(ⅴ)・設置試運転受注明細を基に設置・試運転指示を行う。複数の指示にわかれることもある。という記述から設置・試運転指示テーブルと設置・試運転受注明細テーブル間に多:1のリレーションシップが必要な事がわかる。

 

ユニット製造指図テーブル

受注#、受注明細#を外部参照していることから、ユニット受注明細へのリレーションシップが必要なことがわかる。また25ページ問題文(ⅰ)...受注数量がそのまま製造指図数量となる とあることから1:1の関係であることがわかる。

 

すり合せ部品製造指図テーブル

設計#を外部参照していることから、すり合わせ部品設計テーブルへのリレーションシップが必要なことがわかる。また25ページ問題文(ⅱ)...受注明細の受注数量がそのまま製造指図数量となる とあることから1:1の関係であることがわかる。

 

ソフトウェア製造指図テーブル

受注#、受注明細#を外部参照していることから、ソフトウェア受注明細へのリレーションシップが必要なことがわかる。また24ページ問題文(ⅲ)...受注明細の受注数量がそのまま製造指図数量となる。 とあることから1:1の関係であることがわかる。

 

中間仕掛品見込製造指図テーブル

製造品目コードを外部参照していることから、製造品目テーブルへのリレーションシップが必要なことがわかる。また見込み製造指図はその都度指図するものであって、製造品目は複数回参照されることもわかる。したがって製造品目テーブルへの多:1のリレーションシップが必要なことがわかる。

 

中間仕掛品製造指図テーブル

製造品目コードを外部参照していることから、製造品目コードへのリレーションシップが必要なことがわかる。また所要量展開の結果の都度指図するものであって、製造品目は複数回参照されることもわかる。したがって製造品目テーブルへの多:1のリレーションシップが必要なことがわかる。

 

発注テーブル

発注区分というカラムからユニット発注、すり合せ部品発注...などのテーブルへ親子関係が必要なことがわかる。

 

ユニット発注テーブル

受注#、受注明細#を外部参照していることから、ユニット受注テーブルへのリレーションシップが必要なことがわかる。26ページ問題文(ⅰ)...受注明細の受注数量がそのまま発注数量となる。 とあることから1:1のリレーションシップであることがわかる。

 

すり合わせ部品発注テーブル

設計#を外部参照していることからすり合せ部品設計テーブルへのリレーションプが必要なことがわかる。26ページ問題文(ⅱ)...受注明細の受注数量を基に発注ロットサイズを加味して、発注数量を決定する。 とあることから1:1のリレーションシップであることがわかる。

 

ソフトウェア発注テーブル

受注#、受注明細#を外部参照していることからソフトウェア受注テーブルへのリレーションシップが必要なことがわかる。26ページ問題文(ⅲ)...受注明細の受注数量がそのまま発注数量となる。 とあることから1:1の関係であることがわかる。

 

構成部品定量発注テーブル

発注品目コードを外部参照していることから発注品目テーブルへのリレーションシップが必要な事がわかる。また品目ごとの実在庫数量が発注点を下回った際にその都度このテーブルを作成することが問題文からわかることから発注品目テーブルと構成部品定量発注テーブルの間は多1:であることがわかる。

 

構成部品都度発注テーブル

発注品目コードを外部参照していることから発注品目テーブルへのリレーションシップが必要なことがわかる。また所要量展開の結果の都度に発注をすることが問題文からわかることから構成部品都度発注テーブルと発注品目テーブルの間は多:1であることがわかる。

 

所要量展開テーブル

受注#、受注明細#、投入品目コード、発注#、製造#を外部参照している。

・受注#、受注明細#は問題文24ページ(3)①内製ユニットに必要な中間仕掛品及び直下の構成部品とその数量を求め、在庫があれば...という記述があることから内製ユニットを記録している受注明細ごとに所要量展開が複数あることがわかる。ここでいう内製ユニットの受注明細はユニット受注明細に記録されてあることがこれまでの解答の過程からわかる。したがって所要量展開とユニット受注明細の間にリレーションシップが必要であり、下線の見解から多:1のリレーションシップであることもわかる。

・投入品目コードは投入品目テーブルにあり、所要量展開テーブルと投入品目テーブルの間にリレーションシップが必要なことがわかる。また所要量展開の都度複数回参照することから多:1のリレーションシップることもわかる。

・製造#は、25ページ問題文(ⅴ)中間仕掛品製造指図は、(中略)所要量展開には、どの製造指図にまとめられたかの製造#を記録する。という記述から所要量展開テーブルと中間仕掛品製造指図テーブル間に多:1のリレーションシップがあることがわかる。

・発注#は、26ページ問題文(ⅴ)...所要量展開には、どの発注にまとめられたかの発注#を記録する。という記述から所要量展開テーブル構成部品都度発注テーブルの間に多:1のリレーションシップがあることがわかる。

 

~~~~~~~~~~~

 

ツカレタァ...

DB試験の午後問題は問題文みてうまく解釈して答えを考えるものだから「お絵かき」って呼ばれているんだけれども、、今年の問題は”マジお絵かき”だった気がします。(なにがいいたいんだ)

 

高度情報処理試験どれもそうだけれど問題文がとにかく長い!!!!でも長い分、解答欄埋めれたときの快感はきもちのよいものだなあって個人的にかんじます。問題を楽しむぐらいの勢いで資格を受けるのもありなんじゃないかなあって。

 

秋のNW試験もがんばるぞい。

 

Seccamp2018に応募した話

 

こんばんは。

セキュキャンに応募した話です。

 

 

セキュキャンを知ったきっかけ 

初めて知ったのが実は一年前の四月ごろ。

去年に情報処理安全確保支援士のお勉強をしているときに知りました。

まずIPAさんが主催していて!!しかも無料!!!というところにめちゃくちゃ興味惹かれて!

調べてみたらありえん豪華すぎる!ナニコレ本当に無料でいいの!?え全部受けたい!え絶対参加したい!!!

ってなりました。

 

 

で肝心の応募課題をみてみると...

 

f:id:tn-mi:20180614160750j:plain

 

撃沈...

 

課題解答晒している人みて

 

f:id:tn-mi:20180530211706j:plain

 

またもや撃沈...

 

 

今の自分じゃ無理だ と痛感しまして、

来年までに鍛えよう絶対。とアウトプットすることを中心に一年間頑張りました。頑張ったつもりです。

実は、セキュキャン公式Twitterやセキュキャン参加者Twitterをネトストしまくっていました。去年の夏はつらかったです。

 

で応募した結果!!!!

 

無事選考通過したので。。。。。 

 

私のような最弱でもがんばれば受かるよ!!

ってことをだれかに伝えるためにも最弱参考応募用紙貼っておきます。

 

もっと頭いい人の応募用紙もみてね。

 

ちなみにバラエティトラックの10番です。

ダリフラのゼロツーが好きなのでどうせなら02番がよかった

応募課題:https://www.ipa.go.jp/files/000066028.txt

 

~応募用紙晒し~

 

1今の(コンピューター、マルウェア、メモリ、etc.フォレンジックスにはどんな課題があるでしょうか?

フォレンジックツールの人工知能化の発展

私はフォレンジックスツールの機械学習を採用した人工知能化が今のフォレンジックスの課題の一つにあるのではないかと思いました。なぜかというと今のフォレンジックスのようなフォレンジックスツールのパターン検索や人的捜査ではフォレンジックスが難しい世界になっていくのではないかと考えたからです。

今後IoTAIの活用が加速していき益々ビッグデータ化が予想されています。そんな中今のフォレンジックスを続けていくことは非常に非効率ではないでしょうか。例えば今のフォレンジックスのままだと、膨大なデータをパターン検索で手探りにフォレンジックスする状況が発生する可能性が考えられると思います。

そこで人工知能と化したフォレンジックスツールを使えば、膨大なデータからも手探りではなく自身が学習したベストプラクティスな方法でフォレンジックを行えるのではないでしょうか。

人工知能を活用したフォレンジックスツールとして「lit i view xaminer」が発表されています。しかし準備不足が原因で暴走したMicrosoft開発の人工知能Tayの事例が最近あったように、今の人工知能を活用したフォレンジックスツールはまだ信頼できるもの普及しているものとはあまり感じません。もっと信頼され普及する普及されるようにするためにフォレンジックスツールの人工知能化の発展が今のフォレンジックスの課題ではないかと考えました。

 

・プライバシーの尊重

私はプライバシーの尊重が今のフォレンジックスの課題の一つにあるのではないかと思いました。なぜかというとフォレンジックスがプライバシーの侵害になりえるのではないかと考えたからです。

例えば社員のPCを同じ会社の担当者がフォレンジックスするといった体制です。フォレンジックスで見つかるべき材料の見当がまったくつかない状況になった場合、手探りに全く関係のないところまで捜査されてしまい他人に知られたくないような情報までみられてしまうのではないでしょうか。私が社員側でしたら知り合いに自分の部屋を手探りに荒らされているようなものと同じように感じますし、なおかつプライバシーの侵害のようにも感じます。

去年の10月にセキュリティ社員がウイルスを不正に保管していたことで逮捕された事件があったように、今後コンプライアンスや規定違反の証拠性を明らかにする手段としてフォレンジックスを行うことが多くなると思います。フォレンジックスが起因で何かプライバシーを侵害するような事件が起こりえる可能性も高くなるのではないでしょうか。そのためにも今からフォレンジックスにおいてのプライバシーの尊重について深く考えておくべきだと私は思います。

例えばフォレンジックス体制の明確化(外観の独立性を確保する)、必要最低限のことしか調べないように規制するなどが考えられると思います。以上のことからプライバシーの尊重が今のフォレンジックスの課題の1つにあるのではないかと考えました。

 

クラウドサービスへの対応

私はクラウドサービスへの対応が今のフォレンジックスの課題の一つにあるのではないかと思いました。なぜかというとクラウドサービスを利用していたがためにフォレンジックスすれば見つかるべき材料を見落としてしまうリスクが発生するのではないかと考えたからです。

例えばクラウドサービスに保存してある自社のメールを過去に遡ってまでフォンレンジックしたい。クラウドサービスを利用している自社以外の利用者との関係性もないか利用者の状況もフォレンジックしたい。といった場合です。メールを過去の分まで十分に遡ることができる保証はあるのでしょうか。機密情報の観点からみることができる情報の範囲が制限されてしまう可能があるのではないでしょうか。参考程度の事実ならまだしも重要な参考事実がクラウドサービスにて残っていた場合致命的な損失になってしまうと考えられます。

総務省クラウドサービスの利用状況の調べによるとクラウドサービスを利用している企業の割合は2014年末から上昇していると示されています。(参照:http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h27/html/nc372130.html)これからも上昇していくであろうと考えられているクラウドサービスの利用のためにもフォレンジックスのクラウドサービスへの対応をしていくべきではないかと考えました。

例えばクラウドサービス側でフォレンジックスに十分のデータが提供できるようにする。利用者はクラウドサービス業者をフォレンジックスの観点も考え契約する。フォレンジックスに必要になるデータなどは自社で管理する。など対策が考えられると思います。以上のことからクラウドサービスへの対応が今のフォレンジックスの課題の一つにあるのではないかと思いました。

 

フォレンジックスの在り方

私はフォレンジックスの在り方が今のフォレンジックスの課題の一つにあるのではないかと思いました。なぜかというと誤った在り方にいると様々なリスクを招きかねないと考えたからです。

例えば横浜市小学校襲撃予告事件のようなCSRF脆弱性を踏んでしまったがために大学生が誤認逮捕された事例です。この事件について私は誤認逮捕が起こってしまった原因は警察の捜査不足だと考えていて、横浜市のウェブサイトにてのフォレンジックスで得られた証拠のみで逮捕と判断してしまったからだと思います。もしフォレンジックス=完全な証拠だという誤認識がなければ誤った逮捕に繋がらなかったのではないかとも思います。

私はフォレンジックスについては尋問よりも完全性があり効率的で良い物だと思います。

しかしこのような事件のリスクをまた引き起こさないためにもフォンレジックスは法的な証拠性を明らかにする参考程度のもの。フォレンジックスはあくまで参考証拠であり証拠性は明らかにできない。などフォンレンジックスの在り方について正しく定義しておくべきではないかと考えました。以上のことからフォレンジックスの在り方が今の課題の一つにあるのではないかと考えました。

 

------------

 

1問目から文書の稚拙さが露呈して恥ずかしいwwwwwwwwwwww 

もっと具体的に書けばよかったかな なんて思う。

フォレンジックスの現状や意味などを深く調べてみて現在における課題、今後の動向に伴う課題など ありったけあげて選定してうまくまとめた感じです。

法令や社会の観点からみた答案ばかり...同じ課題を選んだ方の答案をみてみるともっと内部の技術的なことを書いている方もみかけました。

あとはメモリフォレンジックスの限界、マルウェアによる改ざんなどあげられるかなあって思います。

 

--------------

 

問2 匿名化通信を利用することによって犯罪者が特定しにくくなっています。匿名化通信の利用を認めつつ、犯罪者を特定するにはどうしたらよいですか?

 

匿名化通信にVPNを介した通信とプロキシサーバを複数介した通信があげられると思いました。プロキシサーバを複数介した通信において犯罪者を特定する方法を考えてみました。

プロキシサーバを複数介した通信として匿名化通信を実現したブラウザソフトTorを犯罪者が使ったと仮定して考えてみました。

まずWebサーバ側で通信元がTorを使用しているものかHTTPリクエストメッセージのUser-AgentメッセージヘッダがOnionBrowserになっているかで判断します。

そして以下のいずれかの手法を使います。

 

1.アカウント管理を利用する。

これはWebサーバにアカウント管理できるサービスがある前提の手法です。

Webサーバにあらかじめ以下のような設定をしておきます。

・アカウント登録をしていてログインに成功した人のみ通信を許可。

・アカウント登録の際、アカウント情報として氏名や携帯電話番号、住所を入力。

・またなりすまし防止のためにアカウント登録の際に携帯電話番号へショートメールで認証コードを送り返し、認証コードが一致した場合のみ登録を許可のようなSMS認証を行う。

以上の設定をWebサーバにしておけば、犯罪者のログインアカウント情報によって犯罪者を特定することが可能ではないかと考えました。

 

2.プロキシサーバの変換ログをたどる。

これは経由するプロキシサーバ全てに時刻とIPアドレスの変換履歴、及び通信先の対応が保持されている前提の手法です。

犯罪時刻からプロキシサーバが保持している変更履歴を遡って犯罪者を特定します。

具体的に、例えば犯罪者がプロキシサーバBAを経由した匿名化通信を利用したとすると

①2018/04/28,12:00:04 犯行。 犯行者IPアドレスを特定。

IPアドレスの保有者はプロキシサーバAだと特定。

②プロキシサーバAから2018/04/28,12:00:04以前に犯行があったWebサーバへの通信への通信を抽出。IPアドレス変換ログを確認。時刻や通信形態などから最も犯行者に近いであろう変換元IPアドレスを判別。変換元IPアドレスの保有者はプロキシサーバBだと判別。

③②を繰り返し変更元IPアドレスから犯罪者を特定。

以上のようにプロキシサーバの変換ログを辿ることで犯罪者を特定することが可能ではないかと考えました。

 

3.サーバからクライアントまでのレスポンスタイムからどのプロキシサーバを介した経路で行われたか推測してみる。

WebサーバからOnionBrowserで経由する各プロキシサーバへの通信速度を計ります。

犯罪者とのSYN/ACKなどのアクセスログから通信速度を計測します。

計測して出た通信速度と各プロキシサーバへの通信速度から、経由したであろうプロキシサーバのルートを特定します。

そのルートの最終プロキシサーバ(犯罪者が一番最初に経由したプロキシサーバ)のアクセスログを捜査し犯罪者を特定することが可能ではないかと考えました。

 

4.サーバ側で犯罪者の動きに類似したTor以外を使ったアクセスがないか調べる。

私はWebページでのユーザの動きには個性がでると考えています。

例えばブラウザのお気に入り機能などにトップページではない特定のページが追加されていて、トップページではない特定のページから必ずトップページへアクセスする。特定の範囲まで読んだら閲覧を終了する。などといった個性です。

犯罪者の個性をアクセス解析ツールやヒートマップ分析を使って見つけ出し、この個性をもつTor以外を使ったアクセスがないか調べます。犯罪者は犯行をする前に下調べとして匿名化ツール以外の方法でアクセスしている可能性は高いのではないでしょうか。そのためこのような方法で犯罪者を特定することが可能ではないかと考えました。

 

5.HTTPリクエストのHTTPヘッダーを利用する。

HTTPリクエストのHTTPヘッダーを利用して犯罪者を特定できるのではないかと考えました。例えば以下のHTTPヘッダーを利用します。

リファラReferer

リクエストの発生元ページやリクエストの発生元ページのリクエスト発生元ページなどを調べることによって犯罪者の爪痕を探し出し、犯罪者の情報を得ます。

自然言語Accept-Language

使用している自然言語から犯罪者が住んでいると思われる所在国の情報を得ます。

・ユーザーエージェント(User-Agent

使用しているパソコンのOSから犯罪者の使っているOSの情報を得ます。

以上のHTTPヘッダーから得られた犯罪者の情報を使います。例えば「日本でWindows10を使っていてTorをインストールしたPCIPアドレスから犯罪者を特定する」「日本でWindows10を使っていて何個かのあるサイトによくアクセスするTor以外を使った通信がないか調べて犯罪者を特定する」などが可能ではないかと考えました。

 

 -------------------

 

まず匿名化通信の定義についていまいち理解していなく、匿名化通信ってなんだ???ってところから始まりました。

ネットで調べてみると TorTorTor 玉ねぎの暴力でして、、、

VPN、Proxy使ったものも匿名化通信じゃないかな~~って思いつつ

Tor推しで理論上可能じゃないかなあ~~~~~~~ってものをいろいろ考えてズラズラ並べました。

正直いうと可能かは検証していません。 

 

--------------------

 

問3 管理しているネットワーク内にウイルスに感染した端末が存在するかどうか、そしてその端末はどれなのか、あなたならどうやって突き止めますか?

 

端末を管理しているネットワークに接続する前にウイルスにかかっていないか確認する方法が一番良いのではないかと考えましたが、今回は管理しているネットワークに端末が接続してしまっている状況でのウイルスに感染した端末を探索する方法を考えてみました。

 

・管理ネットワークを監視する。

管理ネットワーク内にある端末と差異のないダミーのような端末をおき、ネットワーク監視ツールでその端末宛にくる明らかに不要な通信(FTPやSMBを使った通信など)を送っている端末がないか監視します。

他にもNIDSを使ってネットワークを流れるデータに異常がないか、プロミスキャスモードになっている端末がないかなど管理ネットワークを監視します。

監視によって検知された端末を隔離ネットワークに接続させウイルスにかかっていないか精密に検査し、MACアドレスからウイルスに感染した端末を突き止めます。

ワームのような他人伝染機能を持っているウイルスに感染した端末を発見する場合には、管理ネットワーク下での監視が一番有効的ではないかと考えたためこのような手法を考えてみました。

 

・プロキシサーバ・ファイアウォール・管理ネットワーク接続ネットワーク機器のログの監視。

 

~プロキシサーバのログの監視~

これはプロキシサーバ設置されている前提での手法です。プロキシサーバのログにおいて外部のC&Cサーバへの通信が繰り返し行われているなど通常ではありえない特徴的な通信を確認します。

 

ファイアウォールのログの監視~

プロキサーバを経由せずに直接外部へ通信を試みた形跡はないかファイアウォールにてブロックされた通信ログを確認します。

 

~管理ネットワーク接続ネットワーク機器のログの監視~

例えば夜間や祝日など管理ネットワークを使うことが明らかにないであろう時間帯がある場合、その時間帯に外部に通信している端末がないか管理ネットワークに接続しているネットワーク機器の通信ログを確認します。

 

以上の方法で摘出された端末を隔離ネットワークに接続させウイルスにかかっていないか精密に検査することで、MACアドレスから端末を特定することができるのではないかと考えました。

これはC&Cサーバと通信するようなボット型のウイルスに感染してしまっている端末を発見するために、外部とやりとりする間の機器での監視が有効的ではないかと考えたためこのような手法を考えました。

 

 

Ping応答時間によって自己伝染機能を持っているウイルスに感染している端末を突き止めます。

これはあまり現実的ではないかもしれません。

ウイルスに感染している端末の一番の特徴として動作が不自然、重いなどの特徴があると思います。

そこで任意のネットワークから管理ネットワーク内に接続している各端末へ定期的にPingを送り、応答時間が遅い、動作が通常ではありえないような反応をする端末からウイルスに感染している疑惑のある端末をマークする方法があるのではないかと考えました。

VRRPadvertisementのようなものを想像していただければわかりやすいと思います。

そしてマークした端末を隔離ネットワークに接続させウイルスにかかっていないか精密に検査することで、IPアドレスやMACアドレスからウイルスに感染している端末を特定できるのではないかと考えました。

他人伝染機能を持っていない上に外部と不正通信もしていないが自己伝染機能及び潜伏機能は持っているウイルスを発見するためにこのような手法を考えました。

 

 ----------------

 

管理ネットワークの監視と各種装置のログ監視などはRISSで勉強して得た知識を活かして考えました。

Pingの応答で~というところは100%想像です。端末中で炎上しているウイルスはどうしたらみつけられるんだろ~~~~と悩んだ末の結果です。

 

-----------------

 

問4 あなたは、とある取引先のシステムを保守契約に基づいて保守しています。そして、取引先のシステムに重大な脆弱性があることが分かりました。このまま放置すると、顧客情報の流出など、甚大な被害が想定されます。しかし、その旨を取引先に説明しても、「1万円でなんとかしろ」と無理を言われます。あなたは、相手に対する説明責任は果たしているものとし、こちらに法的な非はない状態とします。しかし、何かあったときに被害をうけるのは、先方だけではなく、多くのシステムの利用者も含まれます。あなたなら、どうしますか?

 

①  可能な限り説得

念入りに説明した上での結果かもしれませんが、まずは会社存続が危ぶまれるような状態な危機にいることを相手へ正しく理解していただくことが最初に大切だと考えました。

シュミレーションテストのように、現在の脆弱性のある環境と同じ状況を可能な限り用意しこれから予想される莫大な被害を実演してみます。

また顧客情報流出による損失の規模を合わせて説明します。

情報セキュリティ対策の専門家に託すことを勧め、費用対効果(1万円以上かけて守れる〇〇万円の損失)を説明しなんとか説得させます。

 

②  (それでもダメだったら)可能な限り顧客情報を暗号化しておく。

①  の方法でダメだった場合に取引先への被害はある程度覚悟して、顧客情報を管理しているデータベースサーバを最低限守ることが次に大切だと考えました。

守る方法は管理している脆弱性の種類によって異なると思います。一つずつ考えてみました。

・例えばHDD自体を抜かれる可能性があるなどの顧客情報を管理しているデータベースサーバの物理的な脆弱性の場合

 物理媒体自体に暗号化をします。(ハードディスク暗号化ツールを使うなど)

 ハードディスクを管理している部屋を厳重にします。(ドアに二重ロックする など)

・顧客情報を管理しているデータベースサーバへつなぐサーバやネットワーク機器の脆弱性の場合

 IPAに自分自身で脆弱性関連の届け出をします。機関を通して説明してもらえばもっと説得力があるのではないかと考えました。

 専門会社に聞いたり、ネットで調べたりして、サーバとネットワーク機器脆弱性を可能な限りなくします。

 サーバの利用を必要な時間以外控えます。

 ネットワーク機器においてデータベースへのアクセス許可を必要最低限のものだけに限定します。

・顧客情報を管理しているデータベースサーバへつなぐ専用ソフトウェアの脆弱性の場合(開発環境の欠陥など)

 専用ソフトウェアの代替ができるものがあったら代替を利用し、リスクを回避します。

 専用専門会社に聞いたり、ネットで調べたりして、可能な限り専用ソフトウェアの脆弱性を無くします。

 

③  (それでもダメだったら)システム利用者に現在の状況を説明する。

例えば専用ソフトウェアの脆弱性が起因して顧客のクレジットカード情報が流出する可能性があるなど といった場合、メールやHPなどで現在の脆弱性の状況、考えられるリスク、現在している対処を説明し、クレジットカード情報を変更するように指示する趣の内容を提示します。

現在の取引先に現在ある脆弱性や現在の状況を公開し、利用者自身で身を守ってもらうことが大切なのではないかと考えました。

 

---------------

 

この問が一番手が進みませんでした。。。。。

5000兆ほしい

1万円は少なすぎますよね!!!大学生の私のバイト代より少ないです!!

③は相当のお人好しの心があるときじゃないと無理そう。。。。

被害を防ぐためにどの方向にもっていくのが正しいか考えてみて

優先順位1:専門家にきく方向にどうにかもっていく。

優先順位2:自分で何とかする。

優先順位3:顧客自身で身を守ってもらう。

かなあって私は考えたので上記のようにまとめてみました。

 

----------------

 

マジでなんで通ったんだろう。。。

 

実は課題提出締め切りの日、学校がお休みだったので家で仕上げをしていたのですが、、

突然インターネットにつながらなくなって!!!!

 午後からバイトでしたしマーーーーーージでビビりました。

 

バイト終わってWifiFreeのお店に飛び込んで提出して一件落着しましたがほんと自分冗長化しとけよって話ですよね😱

ヒエーって感じでした。

 

 

 

 

Raspberry3メモログ

f:id:tn-mi:20180528105023j:plain

 

学校で使うために去年の後期にRaspberryPi3を購入しました。

 

ちなみにOSはRaspbian GNU/Linux 9.1 (stretch)です。

バージョンによって全く操作方法が異なっていたりするのでご注意。

 

いろんなサイトや本などを参考にしてRaspberryPiで色々作ってみました。自分の備忘録のためにも参考にしたサイトなどをまとめておきます。インフラ系のもののみです。

 

 

-----------------------------------------

 

 

 NASサーバーとしての運用

おすすめ度:★★★★★

 参考サイト:http://www.raspberrypirulo.net/entry/2016/08/22/Sambaを使用してファイルを共有する方法

Sambaをインストールして5分ぐらいでできます。RaspberryPiで遊ぶなら環境構築として共有フォルダ作っておくのおすすめ。

 

ApacheでWebサーバーを立てる

おすすめ度:★★★☆☆

参考サイト:https://www.server-world.info/query?os=Debian_8&p=httpd&f=1

ちなみにサイトの設定 /etc/apache2/sites-available/000-default.conf

で行うのですが

Jessieへのアップデート前は000-default.confがdefaultというファイル名だったみたいで。

自分のラズパイがstretchと気づかずWheezyのサイト参考にしてやっていた(アホ)私は何回もファイル名が違うな~新しく作っていいのかな~(;´Д`A ``ウマクイカネってつまずいてたw

ここのサイトもとても参考になりました。

 

CGIサーバをつくる。

おすすめ度:★★★☆☆

参考サイト:https://www.server-world.info/query?os=Debian_8&p=httpd&f=2

Apatche立てたついでにPythonばかりかいててもなんかなあと思ったので入れてみました。

 

DNSサーバをつくる。

おすすめ度:★★★★☆

参考サイト:https://qiita.com/chalkygames123/items/f6a841e49fe022a022bd

学校でのネットワーク構築のついでに。dnsmasqを利用して簡単にできます。

 

VPNサーバー構築

おすすめ度:★★★★☆

参考サイト:https://qiita.com/sumyapp/items/b13542e6d0dae5b2153e

実は自宅のルーターのIPTableを弄るところは断念したので、VPNサーバに接続が確認できたわけではありません。。。。ですがRaspberryでSoftEtherを利用してVPNServerを立てることは簡単にできました。

f:id:tn-mi:20180529205008j:plain

 

----------------

 

1万円以下の値段でインフラ構築が十分にできるって凄いですよね。

また更新あったら追記していきます。

 

-------------------

 

番外編

本体と別にモニターを購入しました。

 

 

簡単にセットアップできます。

小型ですがRaspberryPi以外のモニターとしても利用可能です。

でもモニター剥き出しでちょっと傷入っただけでもおじゃんになりそうなので、ケースも同時に購入することをおすすめします。

 

私のクレジットカード情報が海外鉄道会社で流出された話

 

とある日のこと...

自分が契約しているクレジットカード会社さんから

「中国硬貨に50万換金しようとした履歴がありますが、ご本人様でしょうか?」

との電話。。。。

 

Σ( ̄ロ ̄lll)!?!?!??!?!?!??!?!??!?!?!?!?!

 

滅多に電話のこないクレジットカード会社さんから電話があることですらハラハラした上に、50万ってドユコトナノー!?!?という感じでした。

 

もちろんご本人様(私)ではなく...不正利用されている可能性があるねということでカードを変えてこの件は落着しました。

 

!!!恐ろしすぎる!!!

まさか自分が個人情報流出の加害者になるなんて思ってもいませんでしたしめちゃくちゃビビりました。。

 

で、電話受けてから自分のクレカの明細を確認してみると... 

 

 

 めちゃくちゃ大変なっているじゃないですかーーー。という状況になっていて。。

契約しているクレカの会社さんから連絡なかったら気づかず引き落とされていたかもしれない。。。って考えるとヒエーって感じです。

使っていなくてもクレカの明細は毎月確認しようと実感😨

 

で、原因わからず2か月過ぎ、、、外国から突然手紙が来た!!

 RAILEUROPEで流出されてたみたい。

RAILEUROPEはイギリス旅行でTGV予約するために利用していたサイト。。。

たしか日本で2回、イギリスで1回サイトにアクセスしてクレカ情報入力してTGV予約したから、

サイト自体に脆弱性があった。

RAILEUROPEのシステムに脆弱性があった。

が原因なのかなって見当つけています。

 

今回の件があり、海外ではお金を使う場合

・海外対応クレカを使う。

・換金して現金を使う。

どちらが安全なのかなあって考えなおしてみて、

 

「自分は換金して現金を使う」が安全なんじゃないかなあって思いました。

もちろんカバンがひったくられたりスリにあったりする危険性もあると思いますが、

どこのネットワーク使っているのかもわからない、信頼できるクレカスキャン機なのかもわからない、ようなところで何回もクレカを使うような行為と比べたら換金して現金を使うほうがリスク少ないんじゃないかなあって思いました。

 

 

 

NTT技術史料館に行った話

 

後日談ですがNTT技術史資料館に行った話をします。

 

~NTT技術史料館とは~

その名のとおりNTTの企業博物館で、日本電信電話公社以降のNTT技術史料を歴史をさぐったり技術をさぐったりできるところ。東京都武蔵野市にあります。西武新宿線を使って東伏見駅で降りて歩いていきました。駅からまあまあ遠いからバスがおすすめと聞いていましたが散歩程度にしか感じませんでした。まあ道も景色もいいし歩いても全然良いと思います。

 

春休みに学生特別見学会がありましてそれに参加しました。

 

~思ったこと~

小型化すごい!!!

(小並感)

NTT技術史料館では交換機やケーブル、電話などの進化の過程が実物を追ってみれます。

 元の電話交換機は何を入れればあんなにでかくなるんだ…って思うぐらいのこの収縮度。

 

他にもHDDもすごかった。。。。

f:id:tn-mi:20180529010156j:plain

今のHDDと比べるとめちゃくちゃ大きい!!

でも大きいからって容量が良いわけじゃなかったみたいです。埃溜まりやすそうな形していますよね。

今じゃ失くしちゃうぐらいのサイズのメモリチップで事足りる時代...

小型化すごいなあと実感しました。。。

 

普段みることができないものがみれる!!!

NTT技術史料館に行こうと思ったきっかけでもあります。

例えば光ファイバ!!

f:id:tn-mi:20180529011001j:plain

こんな細いのがネットワークつなぐために地下に張り巡らされてるそうです。光ファイバを構成する原料構成装置なんかもみれます。

 

これはISDN!!

f:id:tn-mi:20180529012756j:plain

今ではあまり使われていないISDN!資格勉強などを通して言葉だけは知っていたので、ヤットアエタナ!って感じでした。

 

時間が足りない!

NTT技術史料館は一般公開時間13:00~17:00までで、地下一階~三階までたくさんのコーナーがあります。

つまり一階を1時間で回らなきゃ全コーナー間に合いません...

一つ一つのコーナーが興味惹かれるものばかりで!!自分はとても時間が足りなかったです。

 

OBの方が丁寧に解説してくれる。

正直行く前は自分ネットワーク機器ぐらいしかわからないけど楽しめるかな...?と不安でした。

ですが私に付いてくれたOBの方がコーナー一つ一つを丁寧に説明してくれて!!

全く知らない分野のコーナーも十分楽しめました。OBの方すごい。

 

また時間あったら色んな史料館回ってみたいです。

ツイートのデータマイニングツールを作った話

 

こんにちは。

JavaTwitterのツイートをデータマイニングできるようなもののツールを作ったので記録。

//ソースコード修正ミスをしていたみたいで下のリポジトリですがただいま削除してあります。報告していただいた方スペシャルサンクス(本当にありがとうございます)

コード:https://github.com/shironatan/TweetSearch

 

データベーススペシャリスト試験の問題でデータマイニングの問題がありまして、

ナニコレオモシロイカキタイ!!

ってなりまして、JavaとTwitter4Jを使って作ってみました。

 

開発言語:Java 8 + MySQL

開発利用:Twitter4J

開発環境:Windows10 eclipse 4.7

開発期間:1週間ぐらい

 

目的

特定の単語を含むツイートをしている人を分析する。

 

データベースの構築 f:id:tn-mi:20180526140533j:plain

 

スタースキーマを利用してデータベースを構築しました。

 このように構築することで以下のようなツイート分析が可能です。

・特定の単語を含むツイートをしたアカウントはどのような特徴があるか分析が可能。(例えば”こんにちは”を含む内容をツイートした人はフォロー数500人の人が多い。 など)

・フォロー軸、フォロワー軸、リスト保有数軸、ツイート数軸、アカウント作成年数軸それぞれを指定した観点から、特定の単語を含むツイートをした人の件数を分析が可能。(例えばフォロー数5000、フォロワー数2000、3個のリストを保有、ツイート数10000件台、2017年にアカウント作成にあてはまる人は”こんにちは”をツイートしているか。 など)

・特定の単語同士の関係性があるか分析が可能(例えば”こんにちは”を呟いている人は”おはよう”も呟いている確率が高いが、”こんにちは”と”おはよう”と”こんばんは”を呟いている確率は高くない。 など)

 

実践

このツールを使って

23時12分~翌日2時12分まで”よるほー”と”ふぁぼれよ”と”アニメ”の内容を含むツイートをしている人を分析してみます。

f:id:tn-mi:20180527145313j:plain

”読み込み開始”においてTwitter4JのStreamingを開始しています。

”読込み終了”においてJPanelの移動とStreamingの停止を行っています。

 

 

結果

f:id:tn-mi:20180527145308j:plain

>!!!みにくい!!!<

・いずれのツイート内容もフォロワー数が500人未満の人が多くつぶやいているのがわかります。

・”よるほー”、”ふぁぼれよ”を含む内容を呟いている人が2011~2014年にアカウントを作成していて、リスト保有数が5個以上の確率が高いのに対し、”アニメ”を含む内容を呟いている人は2016~2018年にアカウントを作成していて、リスト保有数が0個の確率が高いことがわかります。

・また”よるほー”と呟く人は”ふぁぼれよ”を呟く可能性が高いことも分かります。

などのことがこのツールから分析できます。

 

まとめ

Swingの理解が足りなかったり、データマイニングの理解が足りなかったり、色々自分に不足しすぎててコーディング大変だった(;^ω^)

にしてもツイッターってハッシュタグ乱用しているアフィリエイトマンが多いっすね。データを上手く取るのが難しいかった。

これからいろいろ改善していきたいです。データマイニングたのしー

 

 

 

バリに行った話

2017年8月18日~23日まで友達とバリに行った話をします。

 

クアラルンプール乗り継ぎのマレーシア航空でいきました。

 

行ったこと。

レンボガン島に行ってめちゃくちゃ泳いだ。

バリハイクルーズというオプショナルツアー使いました。

海はすっごい綺麗!!!ってわけではないです。

 

 

ケチャックダンスみた。

バリの南端ウルワツ寺院に行ってケチャックダンスみました。

夕日がめちゃくちゃ綺麗にみえます。行き帰りの道でバリらしい民家や夜景が見えるのでそれも楽しかったです。

 

・ジンバランの近くで海みながら海鮮食べた。

海辺の砂浜でこんな感じの景色みながら

f:id:tn-mi:20180517153252j:plain

海鮮食べました。料理美味しいし楽しかったーーー

 

・全身スパした。

f:id:tn-mi:20180517153446j:plain

これは本当に良かった。

3000円で180分のリンパスパ。安すぎないですか。日本でこんなに安いスパはみたことはありません。

またバリに行くとしたら絶対スパはしたい!!

 

バリ行って思ったこと

 

インドネシア料理は辛い物が多い。

 

 ホテルでインドネシア料理食べてみて、一品一品が辛い物(香辛料が強い?)が多いように感じました。

 

・めちゃくちゃ客引きされる。

レギャン通りのような観光地通りを通るとめちゃくちゃ客引きされます。

「お金がないから買えない」といってもATMに連行されます(笑)でも強引にではないのではっきり断れば大丈夫だと思います。

 

・物価が安い。

スパでの出来事もそうですがめちゃくちゃ物価安いです。

現地で3万円しか換金しませんでしたが、十分楽しめましたしお土産も十分購入できました。

 

 

次回行くときはアヤナリゾートあたり探索してスパ祭りしたいです^^*