DB設計者は語学が堪能???

情報システム開発にはデータベースがつきもので、システムを使う人が画面で

目にする情報全てを管理するのですが、その存在を意識することはないですよね?

例えばアマゾンで本を買う時に表示される、レビューやセットで買う本の候補、

中古品の情報、お届け先、カード、過去の購買履歴など、全てデータベースで

保存されているわけです。万が一壊れると大変なのは想像に難くありません。

このデータベースに携わるエンジニアには2種類いて、

業務知識やデータの特性を考慮してシンプルで使いやすい

データ構造をデザインする人と、複雑な計算式でデータ量を見積もったり、

変更の記録などを解析してパフォーマンスを常に最高に保つ役目の人です。

車でいうならさしずめデザイナーとメカニックの関係でしょうか。 

大きなプロジェクトでは前者と後者で人格が分かれる場合もありますが、

今回のプロジェクトは今は前者、そのうち後者になる予定のデータベース設計者として

参画することになりました。

 前置きが長くなりましたが、さてプロジェクト初期の、まだプログラムを作ったりする前の

設計段階で、データベース設計者が行う作業の一つに、「項目の名称の統一」が

あります。これは一見地味ですがとても重要です。

例えばWEB通販サイトで扱っている商品をあらわす番号のことが

「商品コード」「商品ID」「アイテムNO」「アイテム番号」と4種類も

設計書のなかに混在していたら、開発プロジェクトに関わる全ての人が

この4つが同じだと分かっているかは相当怪しくなります。

ましてや、この設計書を外注のプログラマーさんに渡したなら、

当然それぞれの名前でプログラムを書いて、当たりの1つを除き

他の3つの表記をしたプログラムは動かない訳です。 

さっきの4つはどれも間違いではありません。

どれにするかはデータベース設計者が独断で決めます。私は、

・IDはWEBのユーザ登録時に発行されるIDと区別するためNG

・アイテムは画面の項目の英語名を考えるとかぶるのでNG

・番号やNOは注文や請求書など取引のデータに使い、区別するためNG

という理由から「商品コード」にしました。

そんなわけで、バラバラに作られた名前のリスト5つを渡され、

合体した結果ざっと2000個近い名称のリストを整理することになったわけです。

名前が適切かどうかは、その項目が何に使うものなのかを理解することから始まります。

例を挙げてみましょう。

「受注区分」—曖昧です。注文の経路を指す場合(電話、FAX、WEB)もあります。

注文の状態を指す場合(在庫の引当てが済んだ、カード決済が通って確定した、

商品の出荷が終わったなど)もあります。名前的には間にもう1ワード入れます。

受注経路(方法)区分、受注ステータス区分など。

※「ステータス区分」も類義語が重複している感がありますが、終わりを

「区分」で終わらせるのには深い意味が(私が設計する上で)あります。

たいていは企業に共通の業務に関連するので察しがつくものですが、その会社特有

のものや、特殊な呼び方の場合があるので注意が必要です。

と、この辺はまだまだ序の口で、さらにディープな世界へ入ります。

それはまた次の機会として、こういう名称の統一や新たに名付けるときのルールきめは、

設計書やプログラムを書くいかにもエンジニアという作業ではないためか、

ついつい見落とされます。

ですが、後から気付いて何千にもなる設計書の一斉直しとか、

名前から想像できないデータが入っててプログラムミスの多発地帯になってたりとか、

軽視した代償は高くつくものです。

どんな仕事でもそうかもしれませんが、常に自分ひとりが分かって

その場のタスクがこなせればよいという考えから俯瞰して、

大勢が一斉にやるときに混乱しないために、という視点を持つ大切さを

システム開発ほど実感する仕事も他にないかもしれませんね^^;

シェアする

  • このエントリーをはてなブックマークに追加

フォローする