2018-06-24

Gimp 2.10.x macOS版について（McGimp 2.10）

GImp macOS

f:id:atuyosi:20180624155357p:plain

本格的にロゴ画像作成にトライしようと思ってGimpをダウンロードしようとしたのですが……。

現時点ではmacOSの最新バイナリパッケージはまだ提供されておらず。

Gimpの最新の安定版はバージョン2.10.x系列。

代替手段
- macOS版Gimp 2.10 (McGimp)
- McGimpの日本語化
そのほか
まとめ

代替手段

おそらく正解は公式パッケージがリリースされるまで旧バージョンを使う、です。

MacPorts経由でインストールする
自力でビルドする
非公式バイナリを使う
テスト用のパッケージを使う？

公式サイトでの旧バージョンのダウンロードページへのリンクはなくなっているようです。ただ、ファイルはサイト上に残っています。

非公式バイナリとしてMcGimpというものが比較的名前が知られており、安定しているようなので公式パッケージが提供されるまで試験的に使用しています。

なお、Homebrew Caskに旧バージョン及びMcGimp 2.10のパッケージはありますが、Homebrew 本体にgimpという名前のパッケージはありません。

macOS版Gimp 2.10 (McGimp)

公式開発チームによるパッケージではない点に注意。新機能を試したい人向け。自己責任で。

Partha's Place

下にスクロールすると右側のサイドバーにダウンロード用のリンクがあるのでそこからダウンロードする。

なお、旧バージョンとはパッケージ名が異なるので共存可能です。

Homebrewを使う場合は、Homebrew Caskにmcgimp-stdというパッケージがあります。

メニューは日本語化できるようですが、日本語の入力はできないようです。

McGimpの日本語化

初期状態では英語メニューなので"Interface"というカテゴリから表示言語を変更してGimpを再起動すると日本語になります。

画面左上のメニューから"Preferences"（またはCmd+,）をクリック
左側のメニューから"Interface"というメニューを探してクリック
"Language"を"System Language"から”Japanese”に変更
一度、McGimpを終了して再起動

f:id:atuyosi:20180624101256p:plain:w480

OSの言語を自動認識されないのはちょっと疑問ですが、以前のInkscapeのようなファイルの書き換えは不要です。

そのほか

旧バージョン

公式ページにリンクがないですが、サイト上にファイル自体はあります。2.8.22の、ファイル名の末尾が.dmgになっているファイルです。

Index of /pub/gimp/v2.8/osx

なお、Homebrew Cask でbrew cask install gimpとすると2.8.22がインストールされるようです。

テスト版

ファイルは存在するのでテス中？。おすすめしません。

Index of /pub/gimp/v2.10/osx/testing

興味があればバグトラッカーをチェックするといいかも。

Issues · GNOME / GIMP · GitLab

自力でのビルド

試していませんが、必要なファイルとツールは下記にあります。

samm-git/gimp-osx-package: FIles required to build standalone gimp 2.10 package for osx

github.com

まとめ

InkscapeよりはGimpのほうがmacOS版の扱いは優遇されている印象でしたが現状を見るとどっこいどっこいな印象。

ただ、InkscapeよりはXQuartz不要のGimpのほうがマシかなとは思います。

そもそも、Gimp関連書籍がバージョン2.8系を対象にしているので、旧バージョンを使うほうが無難かも。

できるクリエイター GIMP 2.8独習ナビ Windows&Mac OS X対応 (できるクリエイターシリーズ)

作者: ドルバッキーヨウコ,オブスキュアインク,できるシリーズ編集部
出版社/メーカー: インプレス
発売日: 2013/02/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (4件) を見る

GIMP 2.8 スーパーリファレンス for Windows&Macintosh

作者: 野沢直樹
出版社/メーカー: ソーテック社
発売日: 2012/08/04
メディア: 単行本
購入: 2人クリック: 4回
この商品を含むブログを見る

2018-06-23

財務省の公開した交渉記録PDFをいじるその3（本件終了）

OCR Python 時事ネタ関連 Hexo 行政関係財務省交渉記録

一応切りの良いところまで作業したのでここで終了。

プログラムは汚いので載せてないです。

フォーマットが微妙に違うなどの数々のトラップによりかなりの部分を手作業で治すハメに。自分で作ったページ範囲データの不備のせいでさらに無駄な苦労があったりと、見事に自業自得。

Google Cloud Vision APIのOCR機能の、認識ミスのパターンについて知見が深まったのでその点はプラスだったかな、と思っています。

自分で後で振り返るためのメモ的側面が強いのであまり役に立たないかな、と思います。

方針
成果物
備忘録
反省点と今後の課題
- 今後の課題
所感など
まとめ

方針

過去記事の方針のまま。

目次のPDFから交渉記録（応接記録）を機械可読（Computer Readable）な形式に変換
マスク無しのPDFを画像化、再度PDFに変換して過去記事で紹介したAPIでOCR
目次のページ番号から必要なページを割り出して、OCR結果を分割、どうにして添付資料のページを除去
どうにかしてMarkdown化
静的ページジェネレーターでWebページ化

成果物

Netlifyで公開しています。

財務省交渉記録 (2018/05)

OGPとか検索機能とかそのへんは気が向けばどうにかするかも。

備忘録

あまり再現性のない情報ですが載せておきます。

方式検討

まず交渉記録の個別の文書のタイトルを特定
タイトルより上にある機密文書指定などの補足情報は捨てる
応接方法として記録されている情報はカテゴリ情報に使う
極力、インデントなどの情報は残す
ある程度は妥協してエディタで修正する
80点主義で行く

JSONのパースに関しては過去記事参照。

a244.hateblo.jp

プログラムそのものは微妙な上にバグっていたので自粛。一部の処理のみ。

Markdownの生成

公式ページを参考にして、front matterと呼ばれるメタデータをYAML形式でファイル冒頭に記述する。

具体例は下記のとおり。

---
title: 利用要望照会中財産について
date: 2013-06-28 14:15:00
categories: ["応接記録", "来訪"]
tags: ["園長", "籠池", "土壌汚染", "地下埋設物", "大阪航空局", "ティーズレボ", "森友学園", "塚本幼稚園", "大阪府", ""]
---

JSONをパースして値を取り出して、string.Templateで値を埋め込む。Markdwonで書式を再現できない部分はHTMLタグを使う。

HexoのMarkdownは「はてなブログ」のそれとはちがって空白行を保存するタイプなので無駄な空白行は除去する必要あり*1。

参考：Pythonで、string.Templateを使う - naritoブログ

各記事のタグに関してははかなり偏ってしまっているのは反省点。要するに途中で力尽きた……。

正規表現関連メモ

なぜかあまり言及されないことが多いが、Python 3.6から正規表現のマッチした結果の文字列に配列のインデックスでアクセスできる。

import re

m = re.match(r"(\w+) (\w+)", "Isaac Newton, physicist")

m[0]       # The entire match
#  'Isaac Newton'

m[1]       # The first parenthesized subgroup.
#  'Isaac'

m[2]       # The second parenthesized subgroup.
#  'Newton'

Pythonで正規表現のパターンとして漢字何文字とかひらがな、かたかなという文字の種類でマッチさせたいときはregexを使う必要がある。

標準の正規表現モジュールではRuby 2.x系のようにユニコード文字プロパティを使えないです。

Rubyとは（残念ながら）違うのですよ‥…。

正規表現での漢字マッチをUnicodeプロパティーを使って綺麗に書く方法 in Python

正規表現まわりはRubyのほうが優位性はあるかなと思います。

Hexoカスタマイズなど

テーマはデフォルトのまま。細々と修正しています。

設定ファイルの修正箇所

タイトルなど基本的な部分は省略。

index_generator:
  path: ''
  per_page: 10
  order_by: dat

default_category: uncategorized
category_map:
  応接記録: reception
  来訪: came
  訪問: visit
  架電: call
  受電: receive
  その他: other
  情報: note

archive_generator:
  per_page: 10
  yearly: true
  monthly: true
  daily: false
  order_by: date

theme_config:
    google_analytics: UA-120720274-1
    show_count: true
    widgets:
        - category
        - tagcloud
        - archive
        - tag
    menu:
      Home: /
      Archives: /archives
      About: /about

ページの表示順を通常と逆順にするため、index_generatorとarchive_generatorの両方にorder_byオプションを指定しています。

テーマのカスタマイズ

themes/landscape/source/css/_partial/custom.styl
themes/landscape/source/css/style.styl
themes/landscape/source/css/_variables.styl
themes/landscape/layout/_partial/article.ejs

CSSについてはcustom.stylというファイルを新規作成してそこに記述。style.stylから読み込む。末尾の#moreの除去。バナー画像の変更など。

参考にしたサイト：Hexoでトップページに記事の概要を出す方法 | Katsunori Nippo

リスト要素のスクロール

divで囲む必要あり。

横並びにした時に、改行せずにスクロールさせる方法 - Qiita

OCR APIの認識ミスの傾向

頑なに丸囲み数字を認識しないGoogle。①とか④を「の」と認識されても困るんですが……。「〃」も認識してくれないね……。

段落の頭の字下げによる空白を"「"と認識するミスが多数。
行末に不要な"」"や”）"が追加される
単語辞書による補正のせいで変な認識をする時がある -「□（四角）」を「口（くち）」と認識したり、「■」の認識に失敗していた地味に面倒。
「数量等」の「等」が認識されない
「架電」が「書架」+「電」のように認識されるケースあり（辞書補正の弊害か？）
「藪」というを認識できず
「㎡（平方メートル）」は「m」と認識*2
「以上」の間のスペースが何故か改行（\n）になるケースがある（JSONの"detectedBreak"の値がおかしい）

「のの」など「の」が連続している場合、正しい認識結果として「①の」とか「②の」だった可能性を考慮すべし。

目視でチェックして認識されない可能性のある文字、記号類は事前に当たりをつけておく必要がある。ただし、全く認識されないわけでもなく、②や③をそれぞれ、2、3と認識するケースもある。

また、水平方向の罫線があっても、間にスペースが空いていると行の一部とはみなされず、独立した文字の塊という扱いになる。水平方向より縦方向に隣接した文字の領域があればそちらを優先してブロック扱いする。

交渉記録文書のフォーマットに関して

先方／相手方といった書式の違いだけでなく順序が違ったりとか。「以上」だったり「（以上）」だったり地味にトラップ多し。

特に時刻の表記はかなり厄介で途中で諦めた。

お役所なのに内部文書のフォーマットは意外とフリーダム。ただ、議事録としては外部の人の名前を先（ページの上部）に書く、と教わったのでその辺は大丈夫か、という感じ。

何はともあれ書式は統一していただきたい。

反省点と今後の課題

兎にも角にも前処理重要。それと仕事が遅すぎ > 自分。

認識結果の確かさの数値を参照するように
事前に傾き補正などの前処理をちゃんとやるべき
画像を分割してOCRするのも一つの方法だったか
過去記事のページ範囲リストの不備が数箇所あったり

ちょっとめんどうではあるけど、JSONの時点で認識ミスをピンポイントで補正してもよかったかも。

JSONビューワー件エディタのような治具？というかユーティリティが必要。

結論：横着はダメ

今後の課題

傾き補正、ノイズ除去、領域分割。あとはに印刷文書に手書きでメモが入っているパターンをどうするか。

所感など

もうやだこの連中。不当要求ですよ不当要求。

すぐに思い出すだけでも昼休みに押しかけたり、仕事に愛がない？とか仕事に命をかけろとかと罵詈雑言とか。

もし自分が近畿地方局の人間だったら余裕で退職届書いて精神的苦痛を理由に訴訟ですよ。

売却金額をはじめから公表したりとか、そもそも大阪府が認可しなければ……とか、寄付金の水増しを見抜いていれば、とかまあ思うところはたくさんあります。

公務員だって人間。教育勅語は罵詈雑言を奨励していなかったはずです。

次は陸自のイラク日報のような、救いのある公文書にトライしたいところ。

まとめ

ちまちまと作業しているうちに一ヶ月経過していたり、追加で文書が開示されていたりと微妙な展開。

まあPythonに対する習熟度の向上という点ではギリギリ有益だったかと。GoogleのOCRエンジンについては画質が悪いので多少の認識ミスは仕方がないのかという印象。

交渉記録に関してはせっかくなので感想文のようなものを書こうかなと思います。

*1:あまり実害はないと思うが、極端に空きが入る

*2:これは仕方ないと思う

2018-06-21

はてなブログpro、（課金期間が）停止。

はてな有料プラン

f:id:atuyosi:20180620141031j:plain:w480

課金した分、もとは取れたけど……。なんかいまいちイラつくというか、微妙。

年契約とか面倒なこと言わずに月額500円なら払うんだけど、その「途中解約受け付けませんでぇ〜」ってのがなんとなく嫌。

トップページの一覧表示は魅力的なんだけど、そもそもこのブログ基本的にアクセスは検索流入なので……。

メールの文面を見てまた使おうという感じがしなかった。一瞬、「はてなブログ停止のお知らせ」に見えてびっくりした。

有料機能の提供終了、とか書きぶりがあるだろうと。

この素っ気無い感じ、京都っぽいといえばそうなんだけど、本社東京でしょ……。

そういう変なところで京都アピールされても困るよ。商売下手だね……。

不満点メモ

プレビュー表示が遅い。たとえ光回線でも遅い。
まれにAmazon商品紹介機能で商品が表示されない
編集ページの各種検索ボックスにクリアボタンがない
過去記事の一括メンテナンス手段が提供されていない
新規記事の作成時に、タイトルを入力しようとしているのに強制的に本文の入力エリアにカーソルが飛ぶ
アクセス解析が微妙
テーマを変えるとカスタマイズのCSSがリセットされてめんどい
ログインしないと「はてなスター」が押せない

「いいね」ボタンの延長線として、「Anonymousはてなスター」はあってもいいと思う。

他にもあるけど最大の不満はカスタマイズまわりの機能強化が遅い。ブログのカスタマイズネタが大人気ってのはちょっとどうかと思う。

所感

Adsense の広告設置制限数が緩和されたので無理に有料プランにする必要がない。やろうと思えばクリックされやすい位置に自分の広告がくるようにできるし。

独自ドメインを使えるかというのは魅力的だけど現状使ってないし。

そもそもNetlify+静的ページジェネレーターでも独自ドメインは使える。

SEOに強いのはすごいことなんだけど、それでも決定打にかける。

そのうち何食わぬ顔でまた課金するかもしれないけど、とりあえず無料プランにしておきます。

2018-06-20

Tesseract OCR 近況（2018/06）

OCR Tesseract

オープンソースのOCRエンジン（正確に言うとOCR用のライブラリ）、Tesseract OCRの開発状況ウォッチング、です。

しばらくメーリングリスト、GitHubのリポジトリからの通知をチェックできていなかった時期があるので見落としがあるかも。

2017年秋ごろに下書きして、途中で興味が他の方向に行ったりして放置しているうちに半年以上経っていたという。

今年の3月頃、「5月中にバージョン4.00をリリースしたい」という話が出ていた……。

3.0x系
バージョン 4.0系
ここ最近の新しい動きなど
4.0系ベータのバイナリ
- Ubuntu
  - Ubuntu 16.04
  - Debian （)
- macOS
- Windows
そのほか
- 日本語に関連するissue
- デバッグ関連
まとめ

3.0x系

バグフィックスリリースとしてバージョン 3.05.2 がリリース。

ビルド絡みのバグのほか、4.00系のブランチからのバックポートなど。大きなバグ修正としては以前から存在した変数のオーバーフローの県の原因が判明・修正されている。

バージョン 4.0系

過去記事にも書いたようにディープラーニングによるOCRエンジン搭載。ニューラルネットワークを採用した関係で、新しい文字の追加やフォントの再学習手順が様変わりした。また、各言語用のデータについてもバリエーションが多様化している（後述）。

Ubuntu 18.04 LTSでbeta.1（GitHub側のタグはbeta.2）というバージョンが採用された。GitHubのリリースページではbeta.3とbeta.2が存在している（beta.3のほうが新しい……）。

Release 4.0.0-beta.2 · tesseract-ocr/tesseract · GitHub

いまのところ旧式の認識エンジンは残っているけどいわゆるcubeエンジンは除去された*1。

リリース向けの課題などの議論は以下。

RFC: Tesseract 4.0.0 – open tasks · Issue #1423 · tesseract-ocr/tesseract · GitHub

バージョン4.0系の注意点と新しい言語別データ

ocrpy由来のLSTMベースのニューラルネットワークによる認識エンジンが採用されている。

その関係でフォントの識別機能など、一部の機能はなくなっている。特に認識対象文字を指定・除外する機能は動作しない。

認識エンジンの変更に合わせて各言語別のデータも様変わりしている。詳細はWikiを参照。

github.com

ざっくりと紹介しておくと、

tesseract-ocr/tessdata
→旧式の認識エンジン用データを含むデータ（integerized？されたtessdata_best + 3.0x 用データ）
tesseract-ocr/tessdata_fast: Fast integer versions of trained models
→新しい認識エンジン専用データ（速度重視、旧式のOCRエンジン用のデータを含まず）
tesseract-ocr/tessdata_best: Best (most accurate) trained LSTM models.
→新しい認識エンジン専用データ（認識精度重視、旧式のOCRエンジン用のデータを含まず）
tesseract-ocr/tessdata at 3.04.00
→3.05系用のデータ（github リポジトリのタグで切り替え）

fastとbestの違いはニューラルネットワーク（LSTM）の学習時の重みの精度（integer/float）という話だったはず。

参照：fast vs. best · Issue #1404 · tesseract-ocr/tesseract

現状、基本的にHomebrew の--HEADオプションとかUbuntu or Debianでパッケージとして提供されているのはtessdata_fastの方。

メインのtessdataリポジトリ直下のデータは旧式のOCRエンジン向けのデータを含んでいる。

バージョン4.0系のtesseractコマンドの、--oem 0という旧式のOCRエンジンを利用するモードを使えるのはtessdataリポジトリにあるデータを使う場合のみ。

書字系（script）別データについて

各リポジトリ配下にscriptというサブディレクトリがあり、書字系別？の学習データが提供されるようになった。日本語の場合は"Japanese.traineddata"。

詳細はtessdata_fastの(README.md](https://github.com/tesseract-ocr/tessdata_fast/blob/master/README.md)の説明を参照。

"Japanese.traineddata"の場合は日本語と英語の学習用テキストを混在した状態で学習させた代物ということらしい。

"Latin.traineddata"の場合はベトナム語を除くラテン文字系言語全部、とのこと。

書字系という用語については専門ではないので勘違いしているかも。

参考：書字系

日本語に関係するのは"jpn.traineddata"と"jpn_vert.traineddata"。文字の方向の判定に"osd.traineddata"（これはいまのところ旧バージョンと同じものを使う）。

"tesseract -l jpn"のように指定すると、縦書き用のjpn_vertも読み込まれる。横書きだけの場合はtesseract -l jpn-jpn_vertとするか、tessdataファイルに含まれるconfigを取り出して書き換える。

Linux系ディストリビューションではtesseract-ocr-XXXと、tesseract-ocr-script-XXXXのように言語別のデータがパッケージ化されている。

なお、tesseractコマンド、libtesseractともにtessdataディレクトリ直下にあるファイルしか参照しないので使用する際はリンクを貼るか、ファイルの移動が必要。

Japanese.traineddataを使う場合の注意点

[2018/07/24 追記]

出力結果に余計な空白が含まれる問題の対処方法。

jpn.traineddataで修正されている問題が反映されていないので-cオプションでパラメータをセットする。

Fix extra intra-word spaces by adding config file by Shreeshrii · Pull Request #7 · tesseract-ocr/tessdata_fast

$ tesseract -l Japanese -c preserve_interword_spaces=1 sample.jpg  stdout

LSTMベースの認識エンジンの学習について

[2018/09/04 追記]

新しい学習用データのリポジトリが公開されています。

github.com

[追記ここまで]

以前の画像とBoxファイルではなく、テキストデータから自動的にデータを生成して行単位で学習するように変更。

まだいろいろと変更が入っているのでWikiの最新情報を参照。

以前と違って一定の認識率に到達するまで学習を繰り返すか、一定の回数学習を繰り返すかを選ぶ方式になったので終了時間が予測できない。

詳細：TrainingTesseract 4.00 · tesseract-ocr/tesseract Wiki

また、学習の仕方も3通りに増えている。

完全新規作成（Training From Scratch）
fine tune : 既存のデータの改善 or 文字の追加・削除
Training Just a Few Layers : 新しい書体を学習させたいとき

学習ツール自体が不安定だったので試していないのでなんとも言えない。ただ、メインの開発者のRay Smith氏が学習に使用している学習用テキストとフォントのリストを公開していないので公式データと同じものを作成することはできない。

なお、"osd.traineddata"と"equ.traineddata"については以前から作成方法は公開されていない（いまのところ3.0x/4.xともに共通）。

再学習させるための必要な情報がすべて提供されているかは試していないので不明。

参考：generated unicharset does not match lstm-unicharset using current langdata training_text · Issue #1280 · tesseract-ocr/tesseract

どういうことかというと、langdataリポジトリにあるファイルが更新されていない……。

従来式の画像とboxファイルからの学習

以前は文字単位でできない訳ではない、らしい。

GitHub - OCR-D/ocrd-train: Train tesseract 4 with make

マルチスレッド

4.x はデフォルトで4スレッド。

github.com

ABI 変更状況

https://abi-laboratory.pro/tracker/timeline/tesseract/abi-laboratory.pro

ときどきGoogle groupsで話題になる。

ここ最近の新しい動きなど

セマンティックバージョンニングに移行中。

参照：Switch to semantic versioning by egorpugin · Pull Request #593 · tesseract-ocr/tesseract · GitHub

関連するリポジトリが増えている。テスト用データが公開されたり、いつのまにかDockerイメージが提供されるようになっている。また、言語別のデータファイルをダウンロードするためのPython スクリプトも登場した。

Docker

公式Wikiにリンクがあるというだけで開発チームが提供しているわけではないっぽい。

4.0 Docker Containers · tesseract-ocr/tesseract Wiki

テストデータ

tesseract-ocr/test: Repository for tesseract testing

リポジトリが分離されて、tesseract のメインリポジトリからsubmoduleとして参照されるように。

Tesseract tessdata downloader

github.com

Githubから効率よくtessdataデータファイルをダウンロードできる。

git cloneだと全言語一括で非常によろしくなかった（--depth=1オプションを使えばマシになるとはいえ……）。

参考：git で shallow clone - Qiita

4.0系ベータのバイナリ

まだベータ版だということに注意。

公式開発チームとしてバイナリは配布していない。

github.com

Ubuntu

Ubuntu 18.04は4.00beta.1というパッケージが採用されている。またDebianの開発版はGitHubのパッケージを追いかけているっぽい。

Ubuntu 16.04

launchpad.net

それなりに定期更新されている。

Debian （)

experimental 扱いのパッケージがある。

macOS

基本的にHomebrew で--HEADオプションを付ければ4.0系のベータ（というかGItHubの最新版）。

$ brew install tesseract --HEAD

macOS環境でソースからインストールする場合は下記を参考に（特にデバッグ用ツールが必要な場合）。

4.0 bugs on MAC OS X and a step by step for reference · Issue #1453 · tesseract-ocr/tesseract · GitHub

Windows

一応ビルド済みのバイナリは配布されている。ソースからのインストールは鬼門。そもそも、Microsoft謹製のOCRエンジンを使う方がいいのでは？

以下はMannheim Universityの図書館*2によるWindowsバイナリ。

github.com

あとはCygwinとか。あるいはVietOCRに付属のバイナリを抜き取るという方法もある。

そのほか

日本語に関連するissue

日本語固有って感じでない。

デバッグ関連

以下、コメント欄にデバッグ用のログに関する話が出ている。

ログファイルにオプションを書いて、tesseractコマンドの最後の引数に指定する。

まとめ

開発者ではない1ユーザーとしてはこんなもんでしょう。書きぶりが雑ですが。

ちゃんと比較していませんがバージョン4.0系は日本語も結構良いです。特に英数混在は改善しているはず*3。

まだベータ版ですがバグ報告しないと改善されないのがOSS。明らかにあおかしな挙動、うまく認識できないケースはうまくいかない画像とセットで報告するとベターです。

英語でメール書くのはめんどうだったり、画像の著作権とかいろいろありますが……。

*1:一部の言語のみでしかつかえず、日本語には関係がない

*2:古いドイツ語の新聞OCRにTesseractを使っているらしい

*3:エンバグしたりいろいろあるけど

2018-06-20

書評：『達人に学ぶDB設計徹底指南書』

書評 IT DB/RDB

[2018/09/27 追記]

改訂版が出るそうです。

達人に学ぶSQL徹底指南書第2版初級者で終わりたくないあなたへ

作者: ミック
出版社/メーカー: 翔泳社
発売日: 2018/10/11
メディア: 単行本
この商品を含むブログを見る

以下は旧版についてのレビューです。

[追記ここまで]

ざっくりですが一通り読んだので簡単にレビュー。

概要

達人に学ぶDB設計徹底指南書初級者で終わりたくないあなたへ

作者: ミック
出版社/メーカー: 翔泳社
発売日: 2012/03/16
メディア: 単行本（ソフトカバー）
購入: 21人クリック: 316回
この商品を含むブログ (24件) を見る

達人に学ぶDB設計徹底指南書 - ミック - Google ブックス

リレーショナルデータベース（RDB）やSQLに関する著作をたくさん書いているミック氏のDB設計に関する本。

テーブルの定義をどうするか、理論とバッドノウハウ、ケーススタディを解説している。

明記されていないがおそらく対象読者としてDB設計担当のSEを想定している。DBのパフォーマンスと設計のトレードオフがテーマ。

DB設計の定義については「はじめに」には「論理設計」「物理設計」も対象しますと書いてある。ただ、本書で言うところの「物理設計」の話題を取り扱っているの第2章の一部ぐらい。

特徴

「なぜ」と「何のために」に重点を置いているの
きれい事の理論だけでなく、理想と現実のトレードオフ
バッドノウハウだけでなくグレーノウハウという落とし所

学者の書いた本ではなく実務家の書いた本。用語の定義と説明に終止する専門書が少なくない。一方、この本は実務家の視点で書かれているため納得しながら読める。

リレーショナルデータベースという名称の由来など、他の本やサイトであまり言及されないような小ネタも載っている。

感想

4〜6章と8章は非常に有意義だった。ただし、9章はDB設計というよりは最近のDBの新機能のひとつ、という感じで完全に書き手の趣味という気がした。

RDBの考案者の著作を参照していたり、RDBに関する概念の由来やメリット・デメリットを解説しているので非常に納得感がある。

（この本に限った話ではないが）本の内容全体を総括するようなまとめの章がないので唐突に終わる感じ。

RDBシステムと付き合うなら一度は読んでおいて損はないかと。