一橋大学 #経済学のための実践的データ分析 2020夏: 4/10

一橋大学 #経済学のための実践的データ分析 2020夏: 4/10
4.データベースの使い方+α
4.1.データベース101
4.2.BigQuery を使ってみよう
4.3.MySQL を構築してみよう
4.4.データ可用性とプライバシー

Transcript

1. 一橋大学 「経済学のための 実践的データ分析」 2020夏: 4/10 4.データベースの使い方+α 4.1.データベース101 4.2.BigQuery を使ってみよう 4.3.MySQL を構築してみよう 4.4.データ可用性とプライバシー 一橋大学大学院経済学研究科 原泰史 yasushi.hara@r.hit-u.ac.jp
2. 今日の内容 • 13:00-13:15 • プレ講義 [録画なし] • 13:15-13:35 • 4.1データベース101 [録 画あり] • 13:35-13:40 • インターミッション[録画な し] • 13:40-14:00 • 4.2BigQuery を使って みよう [録画あり] • 14:00-14:05 • インターミッション 2[録画なし] • 14:05-14:25 • 4.3 MySQL を構築 してみよう [録画] • 14:25-14:30 • インターミッション3 [録画なし] • 14:30-14:50 • 4.4 データのプライバ シーと可用性[録画]
3. 4.1 データベース101
4. SQL を使うと 便利なこと • Q. “なんで SQL を使うんですか？ Excel かStata でいいんじゃない ですか？” • A1. データ量は増大し続けている (大学講義をZoom で行うように なったり, ソシャゲのガチャを着 実に手に入れるために課金するよ うになったり) • 数百万件のデータを人間の手や Excelで作業するのは無理！(とき どきそういうことをする学者さん いるけど) • リレーショナルデータベースを 使って処理したほうがはやい！ 2020/6/24 4 出所;平成29年度情報通信白書
5. UBER MOVEMENTS https://movement.uber.com/?lang=en-US http://www.its.berkeley.edu/UCBUberBlog 一都市あたりのデータは数十から数百ギガバイト
6. SQL を使うと便利なこと • A2. Excel の限界 • 1048576列 • これ以上は分割しないと ワークシートで処理できない • CPUのファン音が唸りをあげる • 腱鞘炎にもなる 2020/6/24 6
7. データを提供 してくれるよ うな Web で はなく SQL でデータを処 理することの メリット 2020/6/24 7 Web 版にくらべて レスポンスがはやい （すべてに おいてはや いとはいっ ていない） 自分のニーズに則したデータを取 得できる 他のデータベースとの接続が行い 易くなる
8. データベースの種類 • RDB(OLTP; Online Transaction Processing) • DocDB • グラフDB • Hadoop • RDB(DWH) Hadoop (HDFS+MapReduce) • Apache Hadoop • CloudEra • MapR • Hortonworks RDB(DWH) • Oracle Exadata • Teradata • Netezza • RedShift KVS/DocDB KVS • Cassandra • Redis DocDB • MongoDB • CouchBase RDB(OLTP) • Oracle • SQL Server • MySQL • PostgreSQL GraphDB • Neo4j • Datadog • OrientDB 引用: RDB技術者のためのNoSQLガイド スケールアウトできる スケールアウトできない スループット重視 オペレーション用途
9. システムエンジニアとして就職した場合 にデータベース運用者としてやること • データベースに係るインフラの整備 • データの整理 • データベースの設計 • データベースの運用 • Web フロントエンドとの接続
10. 昨今のデータセット • データ量 (Volume) が増大している • 処理速度 (Velocity) が増大している • 多様性 (Variety) が増加している • 正規化かつ、構造が固定されたデータ以外も扱うことが増えている • 具体例 • ソーシャルメディアに投稿されたテキスト • メタデータ • センシングデータ • メール • 取引データ 引用: RDB技術者のためのNoSQLガイド
11. 構造データと半構造データ データの分類 説明 データの例 非リレーショ ナルデータ 非構造データ バイナリや テキスト形 式など, データの構 造化が行わ れていない 半構造データ (ex. XML/JSON) 構造はある がスキーマ がない。頻 繁に構造が 変わる。 リレーショナ ルデータ 構造化データ (ex. RDBMS) スキーマが あり, 構造 が変わらな い。 電子 メール テキス ト・音声 データ システ ムログ オフィ ス文章 経理・財 務・人事 商品・ 在庫 営業・ CRM 決済・ 残高 センサ リング 情報 口コミ SNS 健康・ 医療 データ 統計 データ 行政 データ 他社保 有デー タ 引用: RDB技術者のためのNoSQLガイド
12. 構造データ
13. 半構造データ
14. データモデルごとの違い。 引用: RDB技術者のためのNoSQLガイド
15. データモデルごとの違い (cont.) • キーバリューストア (KVS) • スケールアウトして, 大量データに対するクエリを高速に応答できる。 キーでアクセスするシンプルな使い方がメイン • ドキュメントDB • KVSの特徴に加えてJSONを扱う機能が豊富。スキーマレス (データ構 造を事前に定義する必要がなく、値の型も固定されない)。 • RDB • グラフDB • スケールアウトには適さない。RDB以上に複雑なデータ処理が可能。
16. レーショナルデータベースの具体例: PATSTAT • EPO の特許データベース • Web インターフェースも存在 • Raw Data 版は有償 • Web 版 PATSTAT は2ヶ月間無料 5/14/2015 16
17. PATSTATのデータ構造 http://documents.epo.org/projects/babylon/eponet.nsf/0/95da6bccf12e54a1c1257 aa1002e2d1d/$FILE/patstat_data%20elements_v1.1.pdf 5/14/2015 17
18. PATSTAT のデータ構造 5/14/2015 18
19. PATSTAT のモデル図 5/14/2015 19 • テーブルとテーブルをつなぎ合わせ るIDがあり • IDを介して複数のテーブルの関係性 (リレーショナル) が構築されている • これらのテーブルをつなぎ合わせる ことで、複雑なデータの解析を行う ことができる
20. RDBMSのデータの型 • 数値データ型: • smallint，integer（int），real，double precision，float，decimal（dec）， numeric • 文字データ型: • character（char），character varying（varchar），national character （nchar），national character varying（nvarchar），character large object（clob） • 日付・時刻データ型: • date，time，timestamp，interval • ビット・バイナリデータ型: • bit，bit varying，binary large object（blob） • 論理値データ型: • boolean 引用; https://gihyo.jp/dev/feature/01/database/0004
21. 数値型データの型 整数型 固定小数点型 浮動小数点型 INTEGER、INT、 SMALLINT、 TINYINT、 MEDIUMINT、 BIGINT DECIMAL、NUMERIC FLOAT、DOUBLE 小数点の表示桁が 固定されている 小数点の表示桁が 変動する
22. グラフDB; Neo4j • 互いが接合している複雑なネットワーク上のデータ解析に向い ている • 経路探し, ソーシャルネットワーク上の関係性の解明 • 引用関係の分析 • 社会的な関係性の同定 • ログ解析のような処理には向いていない
23. グラフDBのデータ構造 :ラベル ノード 属性 {キー: バリュー, キー:バリュー} :ラベル ノード 属性 {キー: バリュー, キー:バリュー} :タイプ 属性 {キー: バリュー, キー:バリュー} 関係性 ラベル; 同じ種類のノードを識別するためのドメインの定義 ノード; RDB におけるレコードに相当。複数の属性を{キー:バリュー}で保持出来る 関係性; ノードとノードの間に存在, ノード間のつながりを表現する. 属性; RDB におけるカラム.
24. Ex.1「マトリックス」での関係性を示したグ ラフ
25. Ex2.) Singapore COVID-19 Dashboard • https://co.vid1 9.sg/singapore/ dashboard • Total Cases • Active Cases • Deceased • Discharged などが掲載され ている
26. Ex2.) COVID-19 Singapore Dashboard • 感染者の委細 も掲載
27. Ex2.) COVIG-19 Singapore Network Graph • こんな感じのグラフに
28. 社会科学{経済学, 経営学, 法学, 社会学} の 研究でグラフDBが利用できそうなケース • 企業間の取引関係の分析, SCM の分析 • 労使関係の分析 • 空間情報データ • 研究者同士の引用 (前方引用, 広報引用関係, 共著関係の分析 • 論文データベース • 特許データベース • 口コミの生成過程の分析
29. 主なデータベースの違い RDB(OTLP) KVS/DocDB RDB(DWH) Hadoop 重視する性能 ターンアラウンド タイム ターンアラウンド タイム スループット スループット 主な用途 オペレーション オペレーション 分析 分析 機能拡張モデル スケールアップ スケールアウト スケールアップ スケールアウト 応答時間 数ミリ秒 数ミリ秒 数秒-数分 数分-数時間 データモデル リレーショナルモ デル キーバリュー、 JSON リレーショナルモ デル 行データモデル データ量 -1TB -100TB -100TB -10PB 主に使うクエリ CRUD, トランザク ション CRUD ロード, 抽出, 集計 ロード, 集計 台数 1-2台 (正副構成) 3台-20台 1-2台 (正副構成) 10-100台 レプリケーション オプション デフォルト オプション デフォルト 引用: RDB技術者のためのNoSQLガイド
30. まとめ • 巨大なデータを管理するためには Excel ではなく、Stata でも なく, SQL+Python and/or R な管理の仕方に慣れましょう • グラフDBとRDBMS 両方慣れておくとよいです • 卒論レベルでは使わなくてもよいかもしれませんが、経済学+ データベースが出来るというラベルがついていると、データア ナリティクス/データサイエンティストという業務で仕事を探 していくときにとても楽になります (某外資系企業のデータサ イエンティスト曰く)
31. 4.2 BigQueryを使ってみよう
32. データベースの環境構築って めんどくさい • SQL を使った解析をいちから行うためには 1. SQL のサーバを構築する 2. データを展開する 3. データに対してクエリを発行して解析する の流れを踏まえる必要があり, 特に 1. や2. はオペレーションシステムや 言語環境への依存があるため, いささか面倒です.
33. 使うもの • Google Big Query Sandbox • https://cloud.google.com/bigquery/docs/sandbox?hl=ja
34. Google Big Query のはじめかた (1) 1. URL https://cloud.google.com/bigquery/docs/sandbox?hl=jaを開く
35. Google Big Query のはじめかた(2) • 2. “GCP Console を開く”をクリックする
36. Google Big Query のはじめかた(3) • 3. 左側のナビゲーションベインから BigQuery を選択する
37. Google Big Query のはじめかた(4) • 4. [完了]をクリックする
38. Google Big Query のはじめかた(5) • 以下の画面が表示されればOK
39. Google Big Query でクエリを打ってみる(1) • 以下の内容を、クエリエディタに打ち込む SELECT name, gender, SUM(number) AS total FROM `bigquery-public-data.usa_names.usa_1910_2013` GROUP BY name, gender ORDER BY total DESC LIMIT 10
40. SQL 構文の話 • SELECT: • 1 つ以上のテーブルから選択された行を取得するために使用する • Where: • 選択されるために行が満たす必要のある 1 つまたは複数の条件 • Join: • Inner Join:指定したカラムについて同じ値を持つレコード同士を結びつける • Left Join: • 左のテーブルを基準にして、指定したカラムについて同じ値を持つレコード同士を結びつ ける。値が右のテーブルにあり左のテーブルにない場合は INNER JOIN 同様結果に含まれ ないが、値が左のテーブルにあり右のテーブルにない場合は INNER JOIN と異なり 右の テーブルのカラムには全て NULL がパディングされ、結果に含まれる。 • Right Join: • 右のテーブルを基準にして、指定されたカラムについて同じ値を持つレコード同士を結び つける。 2020/6/24 40 https://dev.mysql.com/doc/refman/5.6/ja/
41. Google Big Query でクエリを打ってみる(1) • 以下の内容を、クエリエディタに打ち込む SELECT name, gender, SUM(number) AS total FROM `bigquery-public-data.usa_names.usa_1910_2013` GROUP BY name, gender ORDER BY total DESC LIMIT 10 翻訳; (1.) Select Name と gender と number の合計値を取得 して, number の合計値は total という名前に してね (2.) From `bigquery-public- data.usa_names.usa_1910_2013` というテーブルからデータを取ってきてね (3.) Order by Total の数字が大きな順にしてね (4.) LIMIT 最初から10番目までにしてね
42. Google Big Query でクエリを打ってみる(3) • [実行]をクリックする
43. Google Big Query でクエリを打ってみる (4) • 結果が出力される • どうやら James (4,924,235) や John (4,818,746) が多いらしい
44. Google Big Query でクエリを打ってみる (5) • [データポータルで調べる]をクリックする
45. Google Big Query でクエリを打ってみる(6) • [使ってみる]をクリックする
46. Google Big Query でクエリを打ってみる(7) • [承認]をクリックする
47. Google Big Query でクエリを打ってみる(8) • [許可]をクリックする
48. Google データポータルで可視化する(1) • 右下の指標に, total を指定する • クエリの出力結果と同じものが表示される
49. Google データポータルで可視化する(2) • 右上のグラフから, 可視化の手法を選択する • その1; 棒グラフ
50. Google データポータルで可視化する(3) • 右上のグラフから, 可視化の手法を選択する • その2; 積み上げ横棒グラフ
51. Google データポータルで可視化する(3) • 右上のグラフから, 可視化の手法を選択する • その3; ツリーマップ
52. 今日の復習(20分程度) • Google Big Query + Google データポータルを使って, 大規模 データの解析をやってみましょう • 注意 • Sandbox 状態で解析すること • 大量データを解析して保持した場合 && クレジットカード情報を登録している場 合, 使用料を Google さんから請求されます • 4.3 で説明するオンプレミスな分析環境も, もし関心あればやっ てみてください.
53. 利用できるデータセット • リソース から, [+ データを追加] をクリックする
54. 利用できるデータセット • Word Development Indicators • Google Patent • US Census Data • US Residential Real Estate Data • Stackoverflow など, 楽しそうなデータ が並んでいる
55. a.) baseball data の場合 • ピッチャーの球種をカウントしてみる
56. Select pitchTypeDescription, count(gameid) as total FROM `bigquery-public-data.baseball.games_post_wide` group by pitchTypeDescrption ordey by total desc LIMIT 1000
57. a.) baseball data の場合
58. b.) Stack Overflow の場合 参考文献; https://qiita.com/perico_v1/items/7ea358a64cf1efa52cd9
59. このセクションのまとめ • 多変量データが使えると、出来ることが増える • どう考えても,今の時代クラウドを使ったほうが楽 • クラウドにデプロイしてもOKなデータか, そうではないデータ かを確認しよう
60. 4.3 MySQL を構築してみよう
61. オンプレミスな実習コース (総作業時間 90分～105分) 1. リレーショナルデータベース (MySQL) の環境をローカル (自 分の PC and/or Mac) に構築するため, MySQL Server と MySQL Workbench を導入する 2. Manaba からデータをダウンロードし, MySQL 上にデプロイ する 3. 展開したデータを MySQL Workbench を使って, 初期的な解 析を行う 4. JupyterNotebook からデータを読み込み初期的な解析をする
62. 今日のレシピ • 標準化された特許データベース (の一部分; サンプルデータ) を Slack 経由でお配りします • 先程の事例と同じように, 企業ごとの特性などを MySQL や python をつかって解析します
63. 使うデータ; 日本の特許データベース 6/24/2020 63 ・特許庁の手続きデータを工業所 有権情報・研修館が提供している 整理標準化データが元データ。 ・app_info を中心にデータが構成さ れるリレーショナル・データベース 方式
64. (1) 特許データベース (patR) • app_info 出願経過 テーブル 6/24/2020 64 フィール ド名 型 インデックス 内容（カッコ内は コード表インデッ クス） 1 app_num varchar(20) 出願番号：すべて半角(B0010) 2 count int(11) ワーク用カウンタ 3 title varchar(255) 発明の名称 4 app_date date 出願日 5 renewal_dat e date 更新日付：出願マスタ 6 id bigint(20) 元処理番号 7 pat_app_nu m varchar(10) 原出願記事番号(B0010) 8 app_type varchar(4) 原出願記事関連種別(B0310,C0025) 9 pub_num varchar(10) 公開番号 10 pub_date date 公開日 11 exam_pub_n um varchar(10) 公告番号 12 exam_pub_d ate date 公告日 13 intl_app_nu m varchar(12) 国際出願番号 14 pry_cnty char(2) 筆頭優先権主張国 15 num_claim_ app int(11) 請求項の数：出願時 16 num_claim_ examed int(11) 請求項の数：公告決定時 17 num_claim_r eg int(11) 請求項の数：登録査定時 18 reg_num varchar(19) 特許番号または登録番号 19 reg_date date 登録日 20 rej_rsn char(2) 拒絶理由条文コード(C0710) 21 cnln_cl char(2) 本権利抹消識別(C0780) 22 term_dat e date 本権利消滅年月日 23 pry_clai m_date date 優先権主張日 24 dspn_ex am_date date 審査最終処分日 25 dspn_ex am_code char(3) 審査最終処分種別コード(C0360) 26 apnum varchar( 13) MUL ‘JPP’をapp_numの先頭につけた文字列 27 fin_decn char(1) 査定種別コード(C0350) 28 fin_decn _date date 査定発送日 29 trans_su bm_date date 翻訳文提出日 30 trans_pu b_num varchar( 10) 公表番号 31 idp int(11) PRI 本テーブルの固有行番号 32 num_clai m_reg_i nfo int(11) 請求項の数（登録情報） 33 udate date ワーク用日付フィールド 34 IPC8 varchar( 255) 国際特許分類第８版 35 acc_exa m_mark char(1) 早期審査マーク(C0240)
65. (1)特許データベース (patR) • citation 引用情報 テーブル 6/24/2020 65 フィール ド名 型 インデッ クス 内容 （カッコ 内はコー ド表イン デック ス） 1 citing varchar(1 0) MUL 引用特許 出願番号 (B0010) 2 cited varchar(1 0) MUL 被引用特 許出願番 号(B0010) 3 type int(11) MUL 種別（1： 審査官引 用 2：特許公 報に記載 された引 用 3：上記両 方に記載 の引用） フィールド名 型 インデックス 内容（カッコ 内はコード表 インデック ス） 1 ids int(11) PRI 固有行番号 2 name text 氏名 3 addr text 住所 4 prefecture char(2) 住所の国県 コード (C0050) 5 id_num varchar(9) 出願人コード (B0070) 6 req_type char(1) 個法官別コー ド(C0070) 7 type int(11) ワーク用 8 name1024 varchar(1024 ) MUL 氏名のイン デックス文字 列 9 addr1024 varchar(1024 ) MUL 住所のイン デックス文字 列 • applicant 出願人
66. (1) patR • inventor 発明者テーブル 6/24/2020 66 フィールド名 型 インデックス 内容（カッコ 内はコード表 インデック ス） 1 name text 氏名 2 addr text 住所 3 req_type char(1) 個法官別コー ド(C0070) 4 organization Varchar(255) 所属する組織 の名称 5 ids int(11) PRI 固有行番号 6 name1024 varchar(1024 ) MUL 氏名のイン デックス文字 列 7 addr1024 varchar(1024 ) MUL 住所のイン デックス文字 列 フィールド名 型 インデックス 内容（カッコ内 はコード表イン デックス） 1 apnum varchar(13) MUL ‘JPP’+出願番号 (B0010) 2 app_num varchar(10) MUL 出願番号(B0010) 3 pub_num varchar(10) MUL 公開番号 4 intl_app_num varchar(12) MUL 国際出願番号 5 intl_pub_num varchar(12) MUL 国際公開番号 6 trans_pub_num varchar(10) MUL 公表番号 7 exam_pub_num varchar(10) MUL 公告番号 8 reg_num varchar(10) MUL 特許番号または 登録番号 9 ref_pub_num varchar(13) MUL 文献公開番号 10 ref_trans_pub_n um varchar(13) MUL 文献公表番号 11 ref_examd_pub_ num varchar(13) MUL 文献公告番号 12 ref_reg_num varchar(13) MUL 文献登録番号 13 ref_intl_pub_nu m varchar(13) MUL 文献国際公開番 号 • numbers 番号表テーブル
67. SQL を使ったデータ分析 • 材料 • MySQL サーバ: オープンソース型データベース。 • RDBMS (Relational Database Management System) • MySQL Workbench: MySQL の開発用コンソール • サンプルデータ • Manaba に展開済み • 7z 形式で圧縮しているため, 解凍が必要 2020/6/24 67
68. 1. MySQL サーバのイ ンストール • 次ページ以降を参照のこと Windows のみなさま • Appendix の, “macOS Mojave に MAMP or MySQL Serverと MySQL Workbench をインストールする” を参 照の上, MAMP をインストールするか, 個別に MySQL サーバと MySQL Workbench をインストールすること Mac のみなさま
69. 1.MySQL サーバとMySQL Workbenchをダ ウンロードしよう • http://dev.mysql.co m/downloads/mys ql/ から、Mac版ま たは Win 版のバイ ナリをダウンロード する 2020/6/24 69
70. 1. MySQL サーバをダウンロードしよう • MSI Installer (32bit) をクリック する 2020/6/24 70 ・“No thanks, just start my download”をクリックする
71. 1-1. MySQL サーバをインストールしよう • Installer が開くので、 NEXT > をクリックする 2020/6/24 71
72. 1-1. MySQL サーバをインストールしよう • “I accept the license terms” チェックボッ クスを選択し て, NEXT > を クリックする 2020/6/24 72
73. 1-1. MySQL サーバをインストールしよう • Available Products から “MySQL Server – X64” と “MySQL Workbench” を選び ⇒ をクリックして、 Products/Features to be Installed に移 動させる 2020/6/24 73
74. 1-1. MySQL サーバをインストールしよう • Execute をクリックする 2020/6/24 74
75. 1-1. MySQL サーバをインストールしよう • インストールが行われる • Next > をクリック 2020/6/24 75
76. 1-1. MySQL サーバをインストールしよう • Next > をクリックする 2020/6/24 76
77. 1-1.MySQL サーバをインストールしよう • Config Type • Development machine • TCP/IP 3306 • Open Firewall Port for Network Access チェック ボックスを外す 2020/6/24 77
78. 1-1.MySQL サーバをインストールしよう • MySQL Root Password を 指定する • Repeat Password に同じ パスワードを指定すること 2020/6/24 78
79. 1-1. MySQL サーバをインストールしよう • Windows Serviceの設定 • 特に変更しない 2020/6/24 79
80. 1-1. MySQL サーバをインストールしよう • Plugins and Extensions • そのまま 2020/6/24 80
81. 1-1. MySQL サーバをインストールしよう • Execute をクリックす る 2020/6/24 81
82. 1-1. MySQL サーバをインストールしよう • Finish をクリックする 2020/6/24 82
83. 1-1. MySQL サーバをインストールしよう • Next > をクリックする • Finish をクリックする 2020/6/24 83
84. 1-2. MySQL Workbench でMySQL サーバ に接続する • MySQL Workbench を起動する (Windows 10 の場合) 2020/6/24 84
85. 1-2. MySQL Workbench で MySQL サーバ に接続する • + ボタンをクリックする 2020/6/24 85
86. 1-2. MySQL Workbench でMySQL サーバ に接続する • Password Vault をクリックする 2020/6/24 86
87. 1-2. MySQL Workbench でMySQL サーバ に接続する • Password を入力する • Test Connection をクリック する • 以下のメッセージが出ればOK 2020/6/24 87
88. 1-2. MySQL Workbench でMySQL サーバ に接続する • Connection Name を指定して, OK をクリックする 2020/6/24 88
89. 1-2. MySQL Workbench でMySQL サーバ に接続する • MyServer をクリックする 2020/6/24 89
90. 1-2. MySQL Workbench で MySQL サーバ に接続する • コンソールが開く 2020/6/24 90
91. 2. サンプルデータをダウンロードしよう • Manaba の「経済学のための 実践的データ分析」ページに アクセスし, TOPページの 「データダウンロード」欄を クリックする • Slack だとファイルサイズの超 過に引っかかるため 2020/6/24 91
92. 2-2. 今日使うデータ(IIP パテントデータ ベース) • 特許庁の『整理標準化 デー タ』（2013 年度提供分ま で）を基に作成された研究用 特許データベース • 「1964000001」以降の出願 番号を持つ特許（出願）を含 む • 今回は, (ダウンロード時間の 都合上)一部分のみを切り出し たデータで解析します 2020/6/24 92
93. 2-2. IIP パテントデータベース 2020/6/24 93 • データベースの構造 出願番号(ida)に基づき紐付 けることができる
94. 2-2. IIP パテントデータベース • 出願テーブル • 出願番号 • 登録番号 • 出願日 • 登録日 • IPC番号 • 請求項 (claim の数) などが記載されている 2020/6/24 94
95. 2-3. IIP パテントデータベースをMySQL サーバにインポートする • 中身 • 「なんらかの意味をもった 何 らかのデータ (引用: 岡崎体 育)」 • これをMySQL サーバに取り 込む 2020/6/24 95
96. 2-3. データベースをMySQL サーバにインポートする • ここからしないといけないこと • (1) データベースをつくる • (2) テーブルをつくる 2020/6/24 96 96 中間試験の成績 ・学籍番号 ・問1の得点 ・問nの得点 期末試験の成績 ・学籍番号 ・問1の得点 ・問nの得点 平常点の成績 ・学籍番号 ・出席点 ・小テストの得点 総合成績 ・学籍番号 ・総合得点(=中間試 験+期末試験+平常点) ・最終成績 これがテーブ ル これがデータベース
97. 2-3. パテントデータベースをMySQL サー バにインポートする • MySQL Workbench を開く 2020/6/24 97
98. 2-3. パテントデータベースをMySQL サー バにインポートする • Manaba の”データ”から hara_space_ap2.7z をダウンロードする
99. 2-3. パテントデータベースをMySQL サー バにインポートする • ダウンロードした hara_space_ap2.7z を解凍する • 解凍するためにソフトウェアのインストールが必要 • Windows の場合 • https://sevenzip.osdn.jp/ から7zip をダウンロードしてインストール • Mac の場合 • The Unarchiver (https://itunes.apple.com/us/app/the- unarchiver/id425424353?mt=12&v0=WWW-NAUS-ITUHOME- NEWAPPLICATIONS&ign-mpt=uo%3D2) を App Store からインストール • 参考文献; https://qiita.com/ntkgcj/items/afe4863c40680d72a755 • 解凍し, SQL ファイルを取得する
100. 2-3. パテントデータベースをMySQL サー バにインポートする • Data Import/Restore をクリックする 2020/6/24 100
101. 2-3. パテントデータベースをMySQL サー バにインポートする Import from Self-Comtained File の ... から解凍したSQL ファイルを選択する “New” から新しいスキーマを作成する “Start Import” をクリックする
102. 2-3. パテントデータベースをMySQL サー バにインポートする • コーヒーかレッドブルでも飲んで待つ 2020/6/24 102
103. 2-3. パテントデータベースをMySQL サーバにイン ポートする • データのインポートが終 わった場合、以下のメッ セージが表示される • レコードがインポートさ れたことが表示されてい る 2020/6/24 103
104. これで、 ようやく分析の スタートライン 2020/6/24 104 さ あ み ん な 特 許 デ ー タ は も っ た か い く ぞ ！
105. 2-4. MySQL を使ってデータベースを解析し てみる 2020/6/24 105 ・とりあえず、データの 中身を観てみる ・”select * from ap;” とタ イプして、雷マークをク リックする ・数秒待つと、先ほどイ ンポートしたデータが表 示される
106. 2-4. MySQL を使ってIIP パテントデータ ベースを解析してみる • 出願された特許のIPC分類を カウントしてみる • エクスポートボタンをおして, Excel で処理してみる 2020/6/24 106 select class1,count(*) as count from ap2 Group by class1 order by count desc;
107. 2-4. MySQL を使ってIIP パテントデータ ベースを解析してみる • この命令は何をやっているの か？ 2020/6/24 107 select class1,count(*) as count from ap2 group by class1 order by count; Select – 次に書くデータを取得してね 今回の場合; class1 という変数ごとに , その件数を count してね. Count した値の変数名として, count と 名付けてね From – 次のテーブルからデータを取ってきてね 今回の場合; ap2 テーブルからデータを取ってきてね group by – 同じラベル同士の変数はグループを作成してね 今回の場合; class1 で記載された分類ごとにデータを集約してね Order by – 数字の大小で出力結果を並べ替えてね 今回の場合; count の値で並べ替えてね
108. 日本で, どのような分類の特許が出願さ れているのか確認できる 2020/6/24 108
109. Extended; Jupyternotebook から local の mysql サーバに接続してコマンドを実行する • 実行にあたり必要なパッケージ (pymysql と ipython-sql) をイ ンストールする
110. Extended; Jupyternotebook から local の mysql サーバに接続してコマンドを実行する • MySQL サーバに接続するための情報を指定する.
111. Extended ; Jupyternotebook から local の mysql サーバに接続してコマンドを実行する • データの中身を取り出し, 先頭から100行目までを抽出する.
112. Extended ; Jupyternotebook から local の mysql サーバに接続してコマンドを実行する • IPC 分類ごとにカウントする
113. ここからの作業 • やりたいこと 1. 特定の企業の特許出願数を数える 2. 特定の企業 (企業名の変遷などを名寄せしたもの) ごとの特許出 願数やIPC分類を数える 3. 特定の産業ごとの特許出願数やIPC分類を数える • 材料 1. IIP パテントデータベース 2. NISTEP 企業名辞書 3. NISTEP 企業名辞書とIIP パテントデータベースの接合テーブル 2020/6/24 113
114. 材料1. 出願人テーブル • 出願人(applicant)テーブルの中身を確認する 2020/6/24 114 コラム名 変数の形式 主キー ida Int(10) YES seq Int(3) ida_seq Varchar(14) name Mediumtext address Mediumtext idname Varchar(10) country_pref Varchar(5) kohokan Varchar(3)
115. 材料1. 出願人テーブル • データの中身を確認してみる select * from applicant; 2020/6/24 115
116. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • やりたいこと • 特定の会社の年毎の出願数を知りたい • 特定の会社のIPC分類ごとの出願数を知りたい • そのためには • 出願テーブルと出願人テーブルを接合して、特定の会社が、どういう 特許を、いくつ出しているのか抽出する 2020/6/24 116
117. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • ER図 2020/6/24 117
118. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • MySQL Workbench 上で以下のクエリを打ち込む ・この命令は何をしているのか？ 1行目: idaとadateとrdateとclassとclaimとida_seqの情報を取ってきてね 2行目: ap テーブルを参照するよ 3行目: applicant テーブルも参照するよ. このとき, applicant の ida フィールドと ap の ida フィールドを キーにして, applicant のデータを取り出してね 4行目: applicant.name が 松下電器産業株式会社 なものを持ってきてね. 2020/6/24 118 select ap.ida, ap.adate, ap.rdate, ap.class1, ap.claim1, applicant.ida_seq from ap inner join applicant on applicant.ida = ap.ida where applicant.name like "松下電器産業株式会社";
119. SQL 構文の話 • SELECT: • 1 つ以上のテーブルから選択された行を取得するために使用する • Where: • 選択されるために行が満たす必要のある 1 つまたは複数の条件 • Join: • Inner Join:指定したカラムについて同じ値を持つレコード同士を結びつける • Left Join: • 左のテーブルを基準にして、指定したカラムについて同じ値を持つレコード同士を結びつ ける。値が右のテーブルにあり左のテーブルにない場合は INNER JOIN 同様結果に含まれ ないが、値が左のテーブルにあり右のテーブルにない場合は INNER JOIN と異なり 右の テーブルのカラムには全て NULL がパディングされ、結果に含まれる。 • Right Join: • 右のテーブルを基準にして、指定されたカラムについて同じ値を持つレコード同士を結び つける。 2020/6/24 119 https://dev.mysql.com/doc/refman/5.6/ja/
120. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • 以下のようなデータが出力される 2020/6/24 120
121. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • エクスポートする • フロッピーディスクのアイコンをクリックする 2020/6/24 121
122. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • ファイル名を指定して保存する 2020/6/24 122
123. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • Excelで開く 2020/6/24 123
124. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • ピボットテーブルを作る • [挿入]-[ピボットテーブル]を選 択 • ピボットテーブルの範囲が選 択されていることを確認し、 [OK] をクリックする 2020/6/24 124
125. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • ピボットテーブルが作成され る • フィールド名が項目に表示され る 2020/6/24 125
126. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • 行に class1, 値に ida を入れ て, ida の個数を数えるように 設定する • 降順に並べ替える • (「松下電器産業」の)IPC 分 類ごとの特許出願数が確認で きる 2020/6/24 126
127. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • グラフにする (Excel 2016 の 場合) • ピボットグラフをクリックする • [縦棒]を選び、OK をクリッ クする 2020/6/24 127 0 5000 10000 15000 20000 25000 30000 35000 40000 G11B G02F F23D G09F C04B G10H F16C G10K F23Q B23Q B05D B65B H03C C10M F02G F02P F17C G10B A61C A61D A63C A63H B31B F02N D01D F01D B24C G09D E04G F02C G06J A41B F42C D02G B63H
128. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • ツリーマップ 2020/6/24 128
129. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • 年ごとの出願数を求めてみる • 行に adate, 値はida (個数)を指 定する • Excel 2016 の場合, 自動的に年 を取り出してくれる • Excel2013 の場合は、自分で left 関数などを使って切り出す必要が ある • 四半期のデータは必要がないので 取り出す • 年毎の出願数が表示される 2020/6/24 129
130. 下ごしらえ1 出願テーブルと出願人テーブルの接合 • グラフにする 2020/6/24 130 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000 1963年 1965年 1967年 1969年 1971年 1973年 1975年 1977年 1979年 1981年 1983年 1985年 1987年 1989年 1991年 1993年 1995年 1997年 1999年 2001年 2003年 2005年 2007年
131. 答え. 松下電気工業で検索したた め、パナソニックで出願されてい る特許が存在しない。 ↓ 対処方法. 企業名の「名寄せ」を行う 2020/6/24 131
132. 材料2. NISTEP企業名辞書 • 企業名, 企業名の変遷などを 納めたデータベース • “産業セクターのイノベーション分析・研究に用い るデータベースの中心に位置付けられ、特許情報 や国内営利企業（以下、「企業」と呼ぶ）に関す る各種調査情報など、外部データから指定した企 業に関する情報を抽出するためのハブとしての役 割を担う” • 日本の会社データ(東洋経済新報社), IIP パテン トデータベース, 証券コードなどとの接続が可 能 • “企業名の読み、本社所在地、業種など、外部デー タに含まれる数多くの企業から分析対象である企 業を正しく特定しデータ抽出するための支援、お よび、合併や企業名称の変遷を考慮したデータの 収集など、企業を中心としたイノベーション分 析・研究における核となる機能を持つ” • 使いみち • いくつかのデータベースをつなぎ合わせることで、 企業の活動を定量的に計測することが可能になる 2020/6/24 132 comp_id 出願人テーブル/ida_sequence 証券コード 又は EDINETコード 企業ID comp_id 外部データ 接続テーブル 東洋経済会社コード 日本の会社データ4万社 （東洋経済新報社） NISTEPによるファイル公開範囲 （一般財団法人知的財産研究所より入手のこと） （必要に応じて利用者が購入のこと） IIPパテントデータベース IIPパテントデータベース （2015年版） との接続用 日本の会社データ4万社との接続用 NISTEP企業名辞書 外部データ 接続テーブル 証券コード、EDINETコードを持つ 企業情報データ （財務・株価データなど） （必要に応じて利用者が準備のこと） 外部データ 接続テーブル （将来予定） 企業名と住所をキーと した汎用接続テーブル 企業統計調査データ など （必要に応じて利用者が準備のこと） 外 部 デ ー タ 外 部 デ ー タ NISTEP企業名辞書は、 Ver.2015_1よりRDB構 造に変更された
133. 材料2. NISTEP 企業名辞書 • http://www.nistep.go.jp/research/scisip/rd-and-innovation- on-industry 2020/6/24 133
134. 材料2. NISTEP 企業名辞書 • カバーする企業群 ①特許出願数累積100件以上 • IIPパテントデータベースの2014年版（iipdb20140417）において、1970年以降の企 業の変遷（名称変更、合併）を考慮した特許出願の集約を行い、累積出願数が100件 を超える企業を特定し掲載 • ②株式上場企業 • 2012年1月時点の全上場企業と以降2015年3月までに新規（又は再）上場した企業を 掲載 • ③特許出願数の伸び率大 • 近年起業し活躍するベンチャー企業など、条件①では取りこぼす可能性がある企業の 抽出を目的とする。 • 1970年以降の企業の変遷を考慮した年ごとの出願数を把握し、それらデータを用い て3年、5年、7年の各期間で1年ごと移動させた線形フィットを行い、大きな回帰係 数（出願数増分）を持つ企業を抽出 • 抽出企業には条件①および②から抽出した企業が含まれるが、それら企業を除いた中 から上位500社強を抽出して掲載を行っている。 2020/6/24 134
135. 材料2. NISTEP 企業名辞書 • 掲載企業数 2020/6/24 135 ①出願数100件以上 ②上場企業 ③出願数伸び率大 掲載企業 数 ✔ 569 ✔ 2,510 ✔ 533 ✔ ✔ 219 ✔ ✔ 1,422 ✔ ✔ 13 ✔ ✔ ✔ 1,080 三条件以外 148 合計 6,494
136. 材料2. NISTEP 企業名辞書 • 構成テーブル 2020/6/24 136 番号 テーブル名称 概要 論理名 物理名 1 企 業 名 辞 書 メ インテーブル 1_comp_nam e_main_TB L 企業名、企業id等のメインの情報、お よびパネルデータとして整備をする必 要がなく、最新の情報のみ保持すれば よいデータを保管 2 沿革テーブル 2_comp_histor y_TBL 名称変更や吸収合併などの事象が発生し た際に発生した年、事象の種類を保管 3 所 在 地 テ ー ブ ル 3_address_TB L 企業の所在地に関する情報を保管 本社、本店、移転など複数の住所情報の 保管、パネル化が可能 4 企 業 規 模 テ ー ブル 4_comp_size_ TBL 資本金、従業員数、中小企業基本法によ る企業規模情報を保管 規模測定年ごとのパネル化が可能 5 業 種 （ 証 券 コ ー ド 協 会 ） テーブル 5_ind_class_ts e_TBL 証券コード協議会の定める当該企業の業 種区分を保管 属する分類が変更された際のパネル化が 可能 6 業 種 （ 日 本 標 準 産 業 分 類 ） テーブル 6_ind_class_js ic_TBL 主業の日本標準産業分類を保管 属する分類が変更された際のパネル化が 可能 7 EDINETコード テーブル 7_edinet_code _TBL EDINETのコードを保管 コードが変更された際のパネル化が可能 8 証 券 コ ー ド テーブル 8_sec_code_T BL 証券コードを保管 コードが変更された際のパネル化が可能 9 連 結 企 業 テ ー ブル 9_consolidate _TBL 連結子会社である場合の親企業情報を保 管 連結関係の変化のパネル化が可能 10 データ登録条件マス ターテーブル 10_reg_reason_MT BL 企業が企業名辞書に登録された理由に関するマスター テーブル 11 企業名称使用開始事 象マスターテーブル 21_use_name_start_ event_MTBL 新設、旧名称からの名称変更等、企業名称の使用が開始 された場合の使用開始事象に関するマスターテーブル 12 企業名称使用終了事 象マスターテーブル 22_use_name_end_e vent_MTBL 名称変更、吸収合併など、企業名称の使用が終了した場 合の使用終了事象に関するマスターテーブル 13 事業所区分マスター テーブル 31_office_class_MT BL 住所情報の本社、本店、事業所等を判定するためのマス ターテーブル 14 業種（証券コード協 会）マスターテーブ ル 51_tse_MTBL 証券コード協議会の定める業種区分に関するマスター テーブル 15 業種（日本標準産業 分類）マスターテー ブル 61_jsic_MTBL 日本標準産業分類に関するマスターテーブル 平成25年10月改定・平成26年4月1日施行に準拠 16 企業連結事象発生マ スターテーブル 91_consolidate1_MT BL 連結事象が発生した場合の発生理由(子会社化等)に関す るマスターテーブル 17 企業連結事象終了マ スターテーブル 92_consolidate2_MT BL 連結事象が終了した場合の発生理由(他社の子会社と なった、独立した等)
137. 材料2. NISTEP 企業名辞書 • ER図 2020/6/24 137 企業名辞書メインテーブル （1_comp_name_main_TBL） 企業id 企業名称 ふりがな 法人格コード 英語名称 URL データ登録理由id データ登録日 データ更新日 沿革テーブル （2_comp_history_TBL） 企業id 名称使用開始年 名称使用開始事象id 事象発生前企業id 名称使用終了年 名称使用終了事象id 事象発生後企業id データ登録日 データ更新日 企業名称使用開始事象マスターテーブル （21_use_name_start_event_MTBL） 事象id 事象概要 データ登録日 データ更新日 1…N 連結企業テーブル （9_consolidate_TBL） 企業id 連結事象発生年 連結事象発生事象id 連結事象発生前連結企業id 連結先連結企業id 連結事象終了年 連結事象終了事象id 連結事象終了後連結企業id データ登録日 データ更新日 所在地テーブル （3_address_TBL） 企業id 所在地利用開始年 所在地利用終了年 本店・本社コード 所在地 都道府県コード 地方自治体コード 住所コード 緯度 経度 データ登録日 データ更新日 EDINETコードテーブル （7_edinet_code_TBL） 企業id EDINETコード確認年 EDINETコード データ登録日 データ更新日 企業規模テーブル （4_comp_size_TBL） 企業id 企業規模測定年 中小企業基本法 資本金階級 従業員数階級 データ登録日 データ更新日 業種（証券コード協会）テーブル （5_ind_class_tse_TBL） 企業id 東証33分類開始年 東証33分類終了年 東証33分類コード データ登録日 データ更新日 事業所区分マスターテーブル （31_office_class_MTBL） 本店・本社コード 概要 データ登録日 データ更新日 N…1 1…1 企業名称使用終了事象マスターテーブル （22_use_name_end_event_MTBL） 事象id 事象概要 データ登録日 データ更新日 1…1 1…1 企業連結事象発生マスターテーブル （91_consolidate1_MTBL） 事象id 事象概要 データ登録日 データ更新日 企業連結事象終了マスターテーブル （92_consolidate2_MTBL） 事象id 事象概要 データ登録日 データ更新日 1…1 1…1 証券コードテーブル （8_sec_code_TBL） 企業id 証券コード 上場市場 上場日 上場廃止日 ISINコード データ登録日 データ更新日 業種（日本標準産業分類）テーブル （6_ind_class_jsic_TBL） 企業id JSIC開始年 JSIC終了年 JSIC分類番号 データ登録日 データ更新日 業種（証券コード協会）マスターテーブル （51_tse_MTBL） 東証33分類コード 東証33分類版 東証33分類大分類 東証33分類小分類 データ登録日 データ更新日 業種（日本標準産業分類）マスターテーブル （61_jsic_MTBL） JSIC分類番号 JSIC版 JSIC大分類 JSIC中分類 JSIC小分類 データ登録日 データ更新日 1…1 1…1 データ登録条件マスターテーブル （10_reg_reason_MTBL） 理由id 登録理由 データ登録日 データ更新日 1…1
138. 材料2. NISTEP 企業名辞書 • RDB はわかりにくいので、EXCEL 版も提供されている • 企業ID, 沿革ID, EDINETコード, 証券コード, 企業規模, 産業分類 などが確認できる 2020/6/24 138
139. 材料2. NISTEP 企業名辞書 • 企業名辞書メインテーブル 2020/6/24 139 企業名辞書メインテーブル [1_comp_name_main_TBL] フィールド名 データ型 重複 NULL 主 キー 外部キー 説明 論理名 物理名 企業番号 comp_id 数値 （整数） N N Y 企業（企業名称ごと）に 固有に付与した番号 沿革番号 history_i d 数値 （整数） Y N 同一企業の変遷レコード をグループ化して扱うた めの番号 企業名称 comp_na me 文字列 Y Y 企業の名称（変遷名称も 含む） ふりがな read 文字列 Y Y 上記企業名称のふりがな 法人格 コード comp_co de 文字列 Y Y 企業の法人格を表すコー ド（下表参照） 英語名称 e_name 文字列 Y Y 企業の英語名称 URL url 文字列 Y Y 企業のウェブページの URL データ登 録理由番 号 reg_reas on_id 数値 （整数） Y Y データ登録理由マスター テーブルの理由番号 当該企業の辞書掲載条件 データ 登録日 reg_date 年月日 Y N データを本テーブルに登 録した日 データ 更新日 up_date 年月日 Y N 既登録データの情報更新 した日
140. 材料2. NISTEP 企業名辞書 • 企業規模テーブル 2020/6/24 140 企業規模テーブル [4_comp_size_TBL] フィールド名 データ型 重複 NULL 主 キー 外部キー 詳細 論理名 物理名 企業番号 comp_id 数値（整 数） Y N Y 企業名辞書メインテーブ ルの企業番号 企業（企業名称ごと）に 固有に付与した番号 企 業 規 模 測定年 judg_year YEAR Y N Y 企業規模を確認した年 中 小 企 業 基本法 comp_size _law 文字列 Y Y 中小企業基本法に準拠し 判定した企業規模 資本金 階級 comp_size _cap 文字列 Y Y 資本金の該当階級 100万円未満 100万円以上 1000万円以上 2000万円以上 5000万円以上 1億円以上 10億円以上 従 業 員 数 階級 comp_size _emp 文字列 Y Y 従業員数の該当階級 5人未満 5～29人 30～99人 100～299人 300～999人 1,000～4,999人 5,000人以上 データ 登録日 reg_date 年月日 Y N データを本テーブルに登 録した日 データ 更新日 up_date 年月日 Y N 既登録データの情報更新 した日
141. 材料2. NISTEP 企業名辞書 • 業績 (証券コード協会) テーブル 2020/6/24 141 業種（証券コード協会）テーブル [5_ind_class_tse_TBL] フィールド名 データ型 重複 NULL 主キー 外部キー 詳細 論理名 物理名 企業番号 comp_id 数値 （整数） Y N Y 企業名辞書メインテーブ ルの企業番号 企業（企業名称ごと）に 固有に付与した番号 業種分類開 始年 inds_year YEAR Y Y 証券コード協会の業種分 類の確認初年 業種分類終 了年 inde_year YEAR Y Y 証券コード協会の業種分 類の確認最終年 業 種 分 類 コード ind_code 数値（4 桁整数） Y N Y 業種（証券コード協会） マスターテーブルの分類 コード 証券コード協会の分類該 当業種 データ 登録日 reg_date 年月日 Y N データを本テーブルに登 録した日 データ 更新日 up_date 年月日 Y N 既登録データの情報更新 した日
142. 材料3. NISTEP 企業名辞書とIIP パテント データベースとの接続テーブル • 企業名辞書と外部データであるIIPパテントデータベース （2015年版）を連携させるための接続テーブル • 企業名辞書メインテーブルの企業idとIIPパテントデータベースの出願 人テーブルのida_seqフィールドを関係付け接続する 2020/6/24 142 フィールド名 データ型 説明 論理名 物理名 企業番号 comp_i d 数値（整 数） 企業（企業名称ごと）に固有に付 与した番号 IIP パ テ ン ト 出 願 番 号 ＋ 記 載 順序 ida_seq 文字列 上記企業番号の企業が出願人であ る特許
143. 材料3. NISTEP 企業名辞書とIIP パテント データベースとの接続テーブル • ER図 2020/6/24 143 企業名辞書メインテーブル （1_comp_name_main_TBL） 企業番号 企業名称 ふりがな 法人格コード 英語名称 URL データ登録理由id データ登録日 データ更新日 IIPパテントデータベースとの接 続テーブル 企業番号 I出願番号＋記載順序 ＩＩＰパテントデータベース 出願人テーブル 出願番号 記載順序 出願番号＋記載順序 出願人名 出願人住所 出願人番号 住所コード 個法官コード
144. 詳細 • 企業名辞書(ver2015_01)利用マニュアル を参照のこと 2020/6/24 144
145. やりたいこと2: 特定の企業 (企業名の変遷などを名寄せした もの) ごとの特許出願数やIPC分類を数える • NISTEP企業名辞書を使って、パナソニック/松下電器が出願し た特許をすべからくカウントする。 • このとき、IPC 分類やclaim などについても、IIP パテントデータベー スから情報を取得する。 2020/6/24 145
146. 特定の企業 (パナソニック; 名寄せ済み) の特許出願数やIPC分類を数える • 方法 1. NISTEP企業名辞書をSQL サーバにインポートする 2. NISTEP企業名辞書とIIPパテントデータベースの接続テーブルをSQL サーバにインポートする 3. NISTEP 企業名辞書を使い、パナソニック子会社の情報を把握する。 これにより、企業ID (comp_id) と沿革ID (history_id)情報を取得する 4. NISTEP企業名辞書とIIPパテントデータベースの接続テーブルに記載 されている comp_id 情報から、パナソニックが特許出願した ida_seq 情報を取り出す 5. Ida_seq に基づき、当該特許の出願年や公開年やclaim, IPC 情報を取 り出す 2020/6/24 146
147. 2-1. NISTEP企業名辞書をSQL サーバに インポートする 2020/6/24 147 Manaba からテーブルをダウンロード, 先程と同様にSQL サーバにインストールする
148. 2-1. NISTEP企業名辞書をSQL サーバに インポートする • select * from 1_comp_name_main_tbl で, データが読み込めた ことを確認する 2020/6/24 148
149. 2-2. NISTEP企業名辞書とIIPパテントデータ ベースの接続テーブルをSQL サーバにイン ポートする • Manaba からデータをダウンロードし, SQL にインポートする • 7z ファイルなので、適宜解凍する 2020/6/24 149
150. 2-2. NISTEP企業名辞書とIIPパテントデータ ベースの接続テーブルをSQL サーバにイン ポートする • SELECT * FROM iipdb2015a.ct_dic_iip; でデータを 読み込めたか確認する 2020/6/24 150
151. 2-3. パナソニックな企業群を history_id から特定する • comp_name が”パナソ ニック” な企業の、 history_id と comp_id を 確認する • NISTEP企業名辞書メイン テーブルを使う • Comp_id = 1 • History_id = 1006752 で あることを確認 • History_id = 1006752 であ る企業を探索する 2020/6/24 151
152. 2-3. パナソニックな企業群を history_id から特定する • History_id = 1006752 である企業 を検索する • パナソニック • 松下電器産業 • 松下電工 • 松下電子工業 • パナソニック電工 • 松下冷機 • 松下通信工業 • 松下電池工業 • 松下住設機器 • パナソニックモバイルコミュニケー ションズ • パナソニックモバイル が該当することがわかる 2020/6/24 152
153. 2-3.パナソニックな企業群を特定する • パナソニックが社名に含まれ る企業を探してみる • 37社存在することを確認 • とりあえず、history_id = 1006752 な企業群を対象にす る 2020/6/24 153
154. 2-4. NISTEP企業名辞書とiip パテント データベース接続テーブルを接合する • IIP パテントデータベース接続テーブルに、NISTEP企業名辞書 メインテーブルにある history_id と comp_name を接合し, 新 しいテーブルとして保存する • 一行目に create table ct_dic_iip2 と指定し, クエリの結果を新しい テーブルに保存する 2020/6/24 154
155. 2-4. NISTEP企業名辞書とiip パテント データベース接続テーブルを接合する • データの状態を確認 • 従来の接続テーブルに、history_id と comp_name の情報が追 加されている • この段階で、パナソニックが出願した特許の出願年と数が確認 できる 2020/6/24 155
156. 2-5. IIP パテントデータベースと接合し, パナソ ニック (名寄せ済み) の特許, IPC 分類情報を抽 出する • 2-4. でつくったテーブルと, IIP パテントデータベースのap テーブルをida で接合する • Left 関数を使い, ct_dic_iip2 テーブルの ida_seq について先頭から10 文字分取り出し, それをapテーブルのida とマッチさせる • History_id=1006752 のデータを取り出す 2020/6/24 156
157. 2-5. IIP パテントデータベースと接合し, パナソ ニック (名寄せ済み) の特許, IPC 分類情報を抽 出する • 結果が表示される 2020/6/24 157
158. 2-5. IIP パテントデータベースと接合し, パナソ ニック (名寄せ済み) の特許, IPC 分類情報を抽 出する • Excelでグラフにする • 各企業体ごとの特許数 2020/6/24 158 0 5000 10000 15000 20000 25000 <1984/1/5 1985年 1987年 1989年 1991年 1993年 1995年 1997年 1999年 2001年 2003年 2005年 2007年 2009年 2011年 2013年 松下冷機 松下電池工業 松下電子工業 松下電工 松下電器産業 松下通信工業 松下住設機器 パナソニック電工
159. 2-5. IIP パテントデータベースと接合し, パナソ ニック (名寄せ済み) の特許, IPC 分類情報を抽 出する 2020/6/24 159 0 5000 10000 15000 20000 25000 30000 35000 H01L H04M H04R A61B A47K E03D G01B B65D H01P E03C G01D B28B C09D B29B G06Q B25B F23C F23Q B66B B62M F16D F27B C12N F15B C07K B28D B41C B62H E01H B67D B60C B64D B66C B27L B07B D02G D21J G10D B64G C01D G10C F22G G03D A41B G21C F16S B44B B64C
160. 2-5. IIP パテントデータベースと接合し, パナソ ニック (名寄せ済み) の特許, IPC 分類情報を抽 出する 2020/6/24 160
161. 別ケース IMDB(映画データベース)をSQL に流し込む • IMDB • 映画の評価 (rating), 監督や役者名などが網羅されたデータベース • https://www.imdb.com/
162. 別ケース IMDB(映画データベース)をSQL に流し込む • レシピ • Non-Commercial Use ならば利用OKなデータベースが提供されていること を確認する • https://www.imdb.com/interfaces/ • Dataset ごとに tsv 形式で提供されているので、それをダウンロードする • title.akas.tsv.gz - Contains the following information for titles: • title.basics.tsv.gz - Contains the following information for titles: • title.crew.tsv.gz – Contains the director and writer information for all the titles in IMDb. • title.episode.tsv.gz – Contains the tv episode information. Fields include: • title.principals.tsv.gz – Contains the principal cast/crew for titles • title.ratings.tsv.gz – Contains the IMDb rating and votes information for titles • name.basics.tsv.gz – Contains the following information for names:
163. • データを展開する
164. 別ケース IMDB(映画データベース)をSQL に流し込む • この後の作業 (前述した作業と同じ) • MySQL サーバ上に、データベース(スキーマ)を作成する • スキーマ上にテーブルを作成する • 作成したテーブルに、データを流し込む • できること • 監督や脚本のチームがどのように変遷したか. 変遷すること/しないこ とが, 映画の興行パフォーマンスにどのような影響を与えたのか
165. まとめ • アップできないデータ or クラウドに課金できない場合は、オ ンプレミス (自分の手元にある)環境でデータベースサーバを展 開してデータを構築するととても便利です。 • ただし、作るのは面倒なので Docker などを使ったほうが良さ そう
166. 4.4 データの可用性とプライバシー
167. Case https://www.recruitcareer.co.jp/news/pressrelease/2019/190805-01/
168. cont. • 【原因】 リクナビでは、2019年3月に『リクナビDMPフォロー』について言及したプライバシー ポリシーへ変更いたしました。学生の皆さまが使用する複数の画面においてプライバ シーポリシーに同意いただくサイト構成になっていますが、一部の画面においてその反 映ができていませんでした。 • また、プライバシーポリシー変更の際には、『リクナビDMPフォロー』で分析スコアの 対象となるすべての学生から適切な同意が取得できるよう設計すべきところ、考慮が漏 れてしまっておりました。 • 【本件同意取得不備の対象となる学生の皆さま】 『リクナビ2020』に会員登録されている学生の皆さまの内、2019年3月以降にプレエン トリー・イベント予約・説明会予約・ウェブテスト受検等の機能を利用されていない方 で、かつ、『リクナビDMPフォロー』を導入した企業への応募者の中で2019年3月以降 に『リクナビDMPフォロー』の分析スコアの対象となった方 • ※なお、『リクナビDMPフォロー』は『リクナビ2020』利用企業向けに提供しているも ので、『リクナビ2021』利用企業には提供されておりません。そのため、『リクナビ 2021』をご利用の学生の皆さまにつきましては、同サービスの影響は一切ございません。 https://www.recruitcareer.co.jp/news/pressrelease/2019/190805-01/
169. 8/1 時点, 最初のプレスリリース • ＜サービスの内容＞ リクナビDMPフォローは、当該採用企業における前年度の応募学生のリクナビ 上での行動ログなどのデータを解析の対象に、その企業に対する応募行動につい てのアルゴリズムを作成します。そこに、今年度に当該採用企業に応募する学生 の行動ログを照合。その結果を「採用選考のプロセスが途絶えてしまう可能性」 として企業に提示することで、企業は適切なフォローを行うことができ、学生に とっては、企業とのコミュニケーションを取る機会を増やすことができます。 • 学生の応募意思を尊重し、合否の判定には当該データを活用しないことを企業に 参画同意書として確約いただいています。コミュニケーション不足による「学生 からの辞退」という企業学生双方にとって不本意なマッチングに終わりかねない 状況に対し、誰に、いつ、どのようなフォローを行うかというコミュニケーショ ン設計の一助にしてもらうことを目的に、提供してきました。 • なお、本サービスは、2018年3月のサービス開始以降、38社に対して、試験的な 運用を積み重ねてきました。 https://www.recruitcareer.co.jp/news/pressrelease/2019/190801-02/
170. 最初のプレスリリース (cont.) • 【本サービスにおける個人情報の取り扱いについて】 これまで本サービスでは、学生が当社の就職情報サイト「リクナビ」にご登録いただく際にご同意 いただいたプライバシーポリシーに基づき、リクナビサイト上での行動履歴の解析結果を取引企業 に対して提供しておりました。 プライバシーポリシー https://job.rikunabi.com/2020/general/move/?screen=navg/help/privacy_policy.html • なお、本サービスで企業に提供されるデータは、リクナビの閲覧データをもとに算出されたスコア であり、学生の能力を推し量るものではありません。この点、いかなる時期であっても提供された 情報を合否の判定に活用しないことにご同意いただいた企業にのみ、本サービスをご提供してきま した。ご利用いただいている企業には当社から定期的に利用状況の確認をさせていただいておりま す。 【今後の対応につきまして】 本サービスの提供にあたっては、各種法令にも照らしつつ、学生の個人情報保護を最優先にサービス の設計や各種規約を整備してまいりました。しかしながら、昨今では個人情報保護に関する社会の認 識も大きく変化しております。海外におけるルール整備の潮流も受け、本日の一部報道にもあります 通り、関係各所から当社のプライバシーポリシーの表現が学生に伝わりにくいものとなっているので はないかとご意見をいただきました。こうした背景から、2019年7月31日（水）をもって、サービス 提供を一時休止させていただくことを決めました。学生の個人情報がどのように企業に提供されてい くのか、よりわかりやすい表現や説明方法を検討し終えるまで、本サービスは一時的に休止いたしま す。このたびは、多大なご迷惑をおかけしますこと、申し訳ございません。 https://www.recruitcareer.co.jp/news/pressrelease/2019/190801-02/
171. 毎日新聞の論説 • “政府の個人情報保護委員会は、リクナビを運営するリ クルートキャリアが学生に無断で「内定辞退率」予測を 売ったのは個人情報保護法に違反すると認定し、是正勧 告を出した。委員会発足以来初の勧告だった。 • 委員会は「人生を左右しうる就職に関する個人情報を 扱いながら、適切な法令順守を行っていない」と指弾し た。だが、違法と認定されたのは「内定辞退率」を販売 された就活生約７万５０００人のうち、約８０００人に 過ぎない。 • リクナビ側が会員登録時のプライバシーポリシー（個 人情報の利用規約）で「採用活動補助のために利用企業 に情報提供することがある」と記していたからだ。大半 の就活生は、この説明で「内定辞退率」の算出や企業へ の販売に同意したとみなされていた。違法とされたのは、 事務手続きの不備で形式的な同意さえ取っていなかった 分だけだ。 • 保護法は、企業が集めた個人データを第三者に提供す る場合、原則として本人に事前の同意を取ることを義務 付けている。ただ、「同意」の定義が明確でなく、リク ナビのようなあいまいな説明でも通用してしまう問題が ある。” https://mainichi.jp/articles/20190919/ddm/004/070/016000c
172. Privacy and Confidentially • 従来のデータ分析 • 統計表になっていれば、個人属性の情報や企業情報は集約されること で消えていた • ビッグデータ時代の分析 • 統計表では解析できない、ロングテールを解析することで興味深い ファクトを見つけ出すことが出来る • 個人がマスクされている情報を用い解析することが重要だが、複数の データソースを組み合わせることで、どこの誰か特定出来てしまう
173. データに含まれている個人情報 • 特許データ • 発明者の所属, 自宅またはオフィスの住所 • 論文データ • 著者の所属, オフィスの住所, メールアドレス • 家計調査データ • 年収、家族構成、性別 etc… ⇒ 実証的に経済学の課題を理論に基づき解析するにはこれらのデータを 用いることが必要不可欠。だが、こうしたデータを使うときには、個人 情報への留意が重要。
174. Definition: Privacy and Confidentially • Privacy • Privacy encompasses not only the famous ‘right to be left alone’ or keeping one’s personal matters and relationships secret, but also the ability to share information selectivity but not publicly. • Confidentially • Confidentiality is preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
175. Privacy Utility Tradeoff Initial Utility/Privacy Frontier Frontier after increase in external Data U* utility P2 P1 Privacy ・プライバシーと、データの可用性に よる利便性の間にはトレードオフの関 係 ・データが外部化されると、プライバ シーを確保するのは困難になる
176. 多変量解析におけるプライバシーの課題 • 特定のグループやサブサンプルにおける特性を抽出すると、最 終的には何処の誰かか抽出出来てしまう • Ex. ) 特定の家計や所得のグループが特定のひとりの場合, 個人が特定 出来る • 具体例 • 国立大学法人一橋大学の役職員の報酬・給与等について • http://www.hit-u.ac.jp/guide/information/salary.html • 教授はともかく、該当する役職が１－２名の給与は公開されていない
177. ロングテイルにビッグデータ解析の面白 みはある • 代表調査やサンプリング調査 ではわからない、特定グルー プの解析が可能になる • 「気温が30度になると、みん なコンビニでアイスクリーム を買う」ではなくて、「8月 の第三週にコンビニのおでん は売れ始める」をデータで解 析出来たほうが興味深い • ロングテイル (Long Tail)
178. ローソン、ビッグデータ分析で「街」を もっと幸せに • “徒歩5分以内、距離にして半 径わずか354メートルという 狭い商圏で競い合う” • “ローソンの場合は、わずか1 割に過ぎない「ヘビーユー ザー」の売り上げが全体の6 割以上を占め、これに「ミド ルユーザー」を加えた約25％ の顧客の売り上げ比率は8割 以上になる” 引用: https://marketing.itmedia.co.jp/mm/articles/1303/07/news024.html
179. 夏におでんが売れるのはなぜ? コンビニ 大手3社に聞いてみると... • “7月に梅雨明けし、暑くなると人は冷 たいものを好む。だがそれも8月にな ると、暑さにも慣れたことに加え、冷 たいものばかりだと飽きてくることか ら、おでんといった温かいものを食べ るようになるのだという。また、暑い 日と涼しい日があったりと、気温差や 肌寒さからも好まれるのだそうだ。 • 具材としては、冬にも人気のある大 根、卵、白滝がよく売れているという。 “ 引用: https://www.j-cast.com/2017/08/28306704.html
180. The Importance of activity in the tails • The Latest Data indicate that more than 20 percent of all personal health care spending in 2009 ($275 billion) was on behalf of just 1 percent of the population.
181. データの接合により個人が特定できてし まう危険性 家計調査 個人名 年収 性別 婚姻有無 職業 ID 住所 郵便番号 特許データベース 個人名 特許名 特許概要 発明者住所 発明者郵便番号 特許 Claim 特許番号 この２つを組み合わせると、ある発明者A がどこに住んでいて、どれだけ特許を出し ていて 年収がいくらで、結婚の有無、性別などが すべて特定出来てしまう
182. データの接合により個人が特定できてし まう危険性(cont.) 家計調査 個人名 年収 性別 婚姻有無 職業 ID 住所 郵便番号 特許データベース 個人名 特許名 特許概要 発明者住所 発明者郵便番号 特許 Claim 特許番号 そこで、家計調査などのデータベースは個 人名や住所の細かな情報がマスクされる ⇒ ところが, 住所の一部, 郵便番号などを用 い, 尤度を測定することでデータベース間を 接合することで特定出来てしまう可能性が ある
183. データの接合により個人が特定できてし まう危険性(cont..) 家計調査 個人名 年収 性別 婚姻有無 職業 ID 住所 郵便番号 特許データベース 個人名 特許名 特許概要 発明者住所 発明者郵便番号 特許 Claim 特許番号 SNS 個人名 アカウント名 犬の名前 周辺の地図 よく行くレストラン ママ友 子供の好きなおもちゃ データの帰属のあいまいなデータを接合する ことで、より個人の情報を把握できる可能性 がある
184. Knowledge is Power • “Big Data” has great potential to benefit society. At the same time, its availability creates significant potential for mistaken, misguided or malevolent uses of personal information. • The conundrum for the law is to provide space for big data to fulfill its potential for social benefit, while protecting citizens adequately from related individual and social harms. Current privacy law evolved to address different concerns and must be adapted to confront big data’s challenges.”
185. 従来 (またはビッグデータ時代以前) の データセット • PII 情報の管理さえに留意していれば、データの接合でプライ バシーが流出することは防げていた • PII (Personal Identifiable Information) • Any Information About an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, data and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information. • 日本の場合 • 保険番号, パスポート番号, 名前, 住所, マイナンバー(ここ数年)
186. データバイアス • リサーチクエスチョンに正しく 対応しないデータセットを選ん でしまう危険性 • 対照群 (control group) が設定 されていない危険性 • “Similarly, overreliance on, say, Twitter Data, in targeting resources after harricanes can lead to misallocation of resources towards young, Internet-savvy people with cell phones and away from elderly or impoverished neighbourhoods” https://azanaerunawano5to4.hatenablog.com/ entry/2015/09/03/101948
187. データインフラストラクチャの重要性 • 個人の匿名性を担保した上で、マイクロなデータを含むデータセッ トを提供することで、「安全な」ビッグデータ解析を可能にする • アメリカ • Sloan Digital Sky Survey • Polymath project • Longitudinal Business Database • Longitudinal Employer Household Dynamics • ヨーロッパ • RISIS • 日本 • 東京大学社会科学研究センター • CAREE/TDB
188. SSJDA • https://csrda.iss.u-tokyo.ac.jp/
189. データの提供形態 • 統計局におけるデータ提供形式 • 表形式の集約データ/統計表 • ライセンス契約に基づく Raw Data の提供 • セマンテックデータでの提供 (これも講義の別の回で詳しく) • EUの場合 • RDF などのセマンテックデータの提供度合いが高まりつつある • 日本の場合 • Excel の統計表または, (フォントが埋め込まれていない)PDF データが 中心
190. Statistical Disclosure control Techniques • Statistical Disclosure Control • Concepts and Methods that ensure the confidentiality of micro and aggregated that are to be published. It is methodology used to design statistical outputs in a way that someone with access to that output cannot relate a known individual (or other responding unit) to an element in the output.
191. データの提供形態 (cont.) • 統計表 • 他のデータセットと接合できないため、マクロまたはメソレベルでの 解析にとどまってしまう • 分散表などの提供も • 個人データをマスクした形式での提供 • 個人の再特定が可能な場合も (前述) • ライセンス契約ベースの提供になるので、管理が煩雑に • セマンテックデータでの提供 • 個人は特定されない • メタ化された情報同士をつなぎ合わせるので、個人IDを保有する必然 性がない
192. Research Data Centers • 特定のデータセットを, SaaS 形式で提供する • 個人の研究者が、ローカルに データを保持する必要性が生 じない • マスクあるいは処理された データのみを入手可能 • 日本だと限定的 • ヨーロッパだとRISISが代表 的
193. ビッグデータを匿名化することは可能か？ • “It is also nearly impossible to anonymize data. Big Data are often structured in such a way that essentially everyone in the file is unique, either because so many variables exist or because they are so frequent or geographically detailed, that they make it easy to reidentify individual pattarns.” • “There are no data stewards controlling access to individual data. Data are often so interconnected (think social media network data) that one person’s action can disclose information about another person without that person even knowing that their data are being accessed.”
194. Tカード、「個人情報を令状なしで警察に提 供」に批判 個人情報保護委員会に問題ない か聞いてみた • ポイントカード「Tカード」を運営するカ ルチュア・コンビニエンス・クラブ（以 下、CCC）が、利用者の会員情報や利用 履歴を令状なしで捜査機関に提供してい たとの報道を受け、議論を呼んでいます。 • “CCCは「2012年から、『捜査関係事項照 会書』があった場合にも、（中略）捜査 機関に協力してまいりました」とコメン トしています。これについて個人情報保 護委員会に聞いたところ、「個別の案件 について、報道の内容だけでマルかバツ かは言いづらいものの、限りなく法令に 基づくものと考えられます」とコメント。 また、法令に基づく照会に対する個人情 報提供は、行うことを利用規約に書いて いなくても「全く問題ない」との見解で した。” 引用: https://nlab.itmedia.co.jp/nl/articles/1901/24/news080 .html
195. 個人のデータを如何に保護するか？ • “Rather than attempt to deanonymize medical records, for instance, an attacker (or commercial actor) might instead infer a rule that relates a string of more easily observable or accessible indicators to a specific medical condition, rendering large populations vulnerable to such inferences even in the absence of PII. Ironically, this is often the very thing about big data that generate the most excitement: the capability to detect subtle correlations and draw actionable inferences. But it is this same feature that renders the traditional protections afforded by anonymity (again, more accurately, pseudosymmetry) much less effective.”
196. 個人のデータを如何に保護するか? (cont.) • The Value of Anonymity inheres not in namelessness, and not even in the extension of the previous value of namelessness to all uniquely identifying information, but instead to something we called “reachability, ” the possibility of knocking on your door, hauling you out of bed, calling your phone number, threatening you with sanction, holding you accountable – with or without access to identifying information.
197. 日本での事例 • “問題提起型の投稿は、世間の関心を集めやすいため、アクセス数を稼ぎたいまとめサイ トの管理人がすぐに寄ってきて記事を引用していきます。 • まとめサイトは投稿の内容を深堀りするため、最初のtwitterでの投稿からさらに細かな 情報を調査や憶測などによって枝葉をつけていきます。” • “人は、そんな馬鹿な行為をしたのが誰なのか、無意識のうちに特定したくなるため、ど んどんコメントが増えてアクセスも増えていきます。そうするうちに、画像に写ってい るわずかな情報から、 「あれ、こいつら３年２組の〇〇たちじゃないのか」 という投稿が出始めます。 万が一ここで個人名が出てしまうと、一斉にその個人名での検索が始まります。 • ここで仇となるのがInstagramやfacebookです。これらに公開制限をかけていない場合、 ことの真相を知りたい輩が、一気にアクセスしてきてその人の個人情報をどんどん吸い 出していきます。出身地、生年月日、学校、家族構成など、公開設定している情報につ いては、容赦なく漏洩していきます。” • なにかしらネットのトピックになった名前で検索すると、すぐに情報が出てくる。 引用: https://fuhyotaisaku-law.com/flames/personalinformation
198. Legal and Ethical Framework • “The Most Data are housed no longer in statistical agencies, with well-defined rules of conduct, but in businesses or administrative agencies. In addition, since digital data can be alive forever, ownership could be claimed by yet-to-be-born relatives whose personal privacy could be threatened by release of information about blood relations.” • “Traditional regulatory tools for managing privacy, notice, and consent have failed to provide a viable market mechanism allowing a form of self-regulation governing industry data collection”
199. Legal and Ethical Framework (cont.) • (1) Rules take into account the varying levels of inherent risk to individuals across different data sets • (2) traditional definitions of PII need to be rethought • (3) regulation has a role in creating and policing walls between data sets • (4) those analyzing big data must be reminded, with a frequency in proportion to the sensitivity of the data, that they are dealing with people • (5) the ethics of big data research must be an open topic for continual reassessment.
200. まとめ; ビッグデータ時代におけるデータ の使い方 • データに含まれる個人情報のあり方を検討 • データの管理および提供方法の改善。従来のクライアント＝ サーバ型にとらわれないデータ提供のあり方を模索する必要が あり • アメリカおよびヨーロッパでは具体的なシステムが運用されつつある • セマンテック型データなど、新たなデータ管理・運用手法の検 討の必要性 • 社会科学者だけではなく、情報工学などの専門家との協業の重 要性
201. Privacy Utility Tradeoff Initial Utility/Privacy Frontier Frontier after increase in external Data U* utility P2 P1 Privacy ・テクノロジーとそれに関連する法制 度の整備によって、 utility と privacy を高い精度で両立できる可能性
202. 次回:企業行動/産業のデータ分析 (企業情 報、財務、特許と論文) • 帝国データバンク企業・経済高度実証研究センター (http://www7.econ.hit-u.ac.jp/tdb- caree/about-caree/) や、日経NEEDS などが提供する企業のデータベースについて説明を行います。 本データベースには、企業の取引、出資、銀行取引データや、決算書データなどが含まれています。 こうしたデータセットに基づき、問いに基づきデータを解析することを目指します。また講義の後半 では、RESASを用いて地域産業の情報の取得する方法と、NISTEP 企業名辞書 (http://www.nistep.go.jp/research/scisip/rd-and-innovation-on-industry) などを用い, ID ベースで データセット間を接合する手法について説明します。 • 企業の研究開発活動を解析するためには、特許や学術論文の動向について測ることで、産業内での動 態を観察することが出来ます。知的財産研究所が提供する IIP パテントデータベース (http://www.iip.or.jp/patentdb/), Clarivate Analytics 社が提供する Web of Science (https://clarivate.com/products/web-of-science/), Lens.org などを用いることで、 - 「どの企業が最も特許を出願しているのか？」 - 「どのような分野に特許を出願しているのか？」 - 「日本の大学で最も年ごとの論文数が多いのは何処か？」 - 「(指導教官の)◦◦先生が書いた論文はt年にx本で、その論文は累計 y 回引用された」 などの情報を取得し分析する方法を解説の上、実習を行います。 • 項目が多いので、5.1 から 6.2 までに分けて解説予定です.
203. THANKS yasushi.hara@r.hit-u.ac.jp