logo header
logo header
logo header
logo header
  • 2016.02.08
  • 技術ブログ開発

MySQLでデータベース設計:ユーザー、許可、フィンランドの女の子についての余談

 

20160205-1

こんにちは、農道JSです。
最近、MySQLという関係データベースの設計の作業いろいろある為、それについて少し話をしたいと思います。

「ユーザー」と「許可」

ほとんどのシステム開発プロジェクトで、誰が何ができるかをデータベースで表現しないといけない、つまり「ユーザー」と「許可」です。下記のように作るパターンがありがちです:

管理者であるかどうかは「is_admin」によって判別できます。

しかし!

ただ、単純に「管理者」と「一般的なユーザー」ではなく、情報を表示するシステムだと、記事を更新できる人と、TOPページのメッセージを更新できる人など、分けたいかも知れないですね。その時は下記のようになりました:

上記のようなやり方だと、問題があります。許可の種別が増えるほど、ユーザーテーブルが大きくなって、のちのち、許可が増える次第ALTER TABLEをしないといけないですね。

どうすれば良い?

問題の根本のところは、設計の考え方です。テーブルは構成です。「ユーザー」と「許可」という概念があって、それをその構成に表現して、テーブルのデータは具体的なユーザー(山田太郎など)と許可(削除できないなど)になれば良いですが、上記のやり方だと許可自体は構成に入ってしまいます。

DAC

DAC(Discretionary Access Control、任意アクセス制御)のやり方だと、ユーザーと許可はそれぞれのテーブルになって、そして誰がどの許可を持っているのは関連テーブルで表現します:

上記のやり方だと、許可の種別は30つになっても、テーブル構成が変わらないです(permissionsのデータが増えるだけです)。

RBAC

DACは設計的に綺麗ですが、デメリットがあります。新しいユーザーを追加して許可を設定する時、毎回全然違う許可設定になるシステムは少ないと思います。

普通だと、運用的にいくつかの役割があって、その役割によって許可を与える為、同じ役割は同じ許可になりますので、それを毎回設定するのは効率悪いです。場合は、DACではなく、RBAC(Role based access control、ロールベースアクセス制御)を使うほうが良いです。

ユーザーと許可のテーブルだけではなく、「役割」という概念もテーブルにします。そして、許可と役割の関連テーブルとユーザーと役割のテーブルを追加します:

上記のようにすると、設定も楽になるし、ある役割の許可を変更したい場合は、一発で全員、簡単に変更できます(user_permissionsのテーブルは必要であれば「役割以外の許可」の為に使う事は出来ます)。

ミイ

最後に、スカンジナビア半島の代表として、MySQLの名前について伝えるべきの事があります:
SQLはStructured Query Languageの省略、つまり構造化照会言語の意味ですが、「My」はどう意味意味ですか?

MySQLは20年前スウェーデンの株式会社「MySQL AB」で作成されました。その会社の共同創業者、Michael Wideniusというフィンランド人の娘の名前はMyのだったところから、製品名をMySQLにしました。

フィンランドなので、ムーミンと同じく、「マイ」ではなく、「ミイ」ですので、次回、「MySQL」という言葉を聞いたら、基本勘違いしている通り「俺の構造化照会言語」ではなく、「フィンランドの女の子の構造化照会言語」と思って頂ければと思います。

ともに世界をアップグレードできる、そんな日を夢見て。
Upgrade the World!