BTデータ構造

2006年11月12日 00:07
  • 神楽坂ショールーム
  • 資料請求・お問い合わせ
  • 概算見積もり

バイバイ タイムカードのデータベースは、「1打刻1レコード」というデータ構造をしています。
(以下仮に、この方式を「BTデータ構造」といいます。「BT」とは、バイバイ タイムカードの略称です。)

「1従業員1日1レコード」という構造も考えられ、多分一般的にはそちらの方が多いだろうなとは思われますが、あえて選んだのが「1打刻1レコード」という方式です。
(以下仮に、「1従業員1日1レコード」の方を「一般データ構造」といいます。)

一般データ構造では、1つのレコードに、「Aさんは、○月○日は○時○分に出社して、○時○分に退社した」という情報が記録されます。Excelで言えば、従業員名、日付、時刻が横に並ぶ感じです。

これに対してBTデータ構造では、「Aさんは、○月○日は○時○分に出社した」というデータで1行、「○時○分に退社した」というデータで1行といった形式となります。

一般データ構造はデータ処理が簡単であり、設計次第ではシステムの負荷も低く、開発も比較的容易です。しかし、ユーザーにとってのシステムの使い方にデータ構造上の制限が生じます。

どういうことかというと、データベースでは、1行あたり横にいくつのデータの入力スペース(Excelで言うなら横に並ぶ「列」)を用意しておくかを予め決めておかなければならないので、入れられるデータが限られます。具体的に言えば、「1日に何打刻まで受け付けられるか」が決められてしまい、それを超えることが出来なくなるのです。
(「1日に4打刻までしか出来ません」といった感じ。)

これに対してBTデータ構造では、打刻データを全て縦に並べてみて、その日の最初の打刻を出勤、最後の打刻を退勤として、その間にあるOUT-INの打刻を休憩/中抜けとみなすという処理を行うため、1日に何打刻でもすることが出来るようになっています。

その他にも有休・特休などの休暇情報や、出張、直行直帰、遅早退、シフト、各種の手当などなど・・・あらゆる情報がそれぞれ1行のレコードとして保存されるようになっているため、一切の制限なくバイバイ タイムカードのデータベースという入れ物に必要な情報を入力することが出来るようになっています。
(一般データ構造では、当初の想定にないデータは取り扱うことが出来ないため、例えば「有休は処理出来るけど、各種手当なんかはちょっと・・・」などという事態が発生します。)

バイバイ タイムカードが様々な業種・業界、規模、用途、要望などに柔軟に対応出来る理由の1つは、実はこのような柔軟なデータ構造にあったのです。

ただ、この方式には問題もあります。

データ量がものすごく増えるということです。

「Aさんは、○月○日は○時○分に出社して、○時○分に退社した。この日のAさんのシフトは○時○分から○時○分の予定となっていて、宿直手当が付いている」という情報の場合、一般データ構造におけるレコード数は「1」ですが、BTデータ構造におけるレコード数は「5」になります。

これが1ヶ月25日分とすると25対125、100人分だとすると2,500対12,500、1年分にすると30,000(3万)対150,000(15万)という違いとなってきます。

更にこの方式から、必然的にバイバイ タイムカードでは各種の処理を「ダイナミック(動的)」という方式で行っています。このため、システムは膨大なデータを非常に効率良く高速で処理することが出来るよう練り上げられていなければならないということになります。

システムの柔軟性を確保するために選ばれたBTデータ構造は、今日もネオレックス技術陣の頭を悩ませ、更なる努力と工夫を要求している、という状況となっています。

  • バイバイ タイムカード日記

このページの先頭へ