JP2007293467A - 情報処理装置 - Google Patents

Abstract

【課題】情報処理装置において、システムの設計技法を統一して、柔軟で汎用性と永続性のあるシステムを低コストで作成して蓄積する。
【解決手段】すべての業務処理におけるデータ記録構造を、１項目１レコードの「語」の集合である「文」という形式に統一する。システムに関するすべてのデータを、「記録ファイル」と「ログファイル」にのみ記録する。「定義体ファイル」の記述に従って、各項目の更新処理と読出しを統一的に行う。対象の特質を生かした総合的な情報処理システテムが、少ない工数と低コストで作成でき、データの共有も簡単になる。また、プログラムやファイルを蓄積して資産化し再利用できるので、真のERP（Enterprise Resource Planning：企業資源利用計画）が実現できる。
【選択図】図１

Description

本発明は、情報処理装置に関し、特に、設計技法を統一して設計することで、機能の拡張やデータの共有が簡単にできるようにした情報処理装置に関する。

従来の業務処理システム開発における設計技法は統一されておらず、SEの数だけ異なる基本設計が作成される。基本設計に基づく個々の仕様書も担当SEの数だけ異なったものが作成される。仕様書に基づくプログラムも、プログラマーの数だけ異なったものが作成される。サブプログラムの共通化や、構造化技法によって、プログラム工数の一定の節約ができたとしても、根本的解決にはならない。

現在の主流の手法では、それぞれの業務ごとにパッケージシステムを作成し、個々の対象については追加でカスタマイズを行っている。パッケージの基本部分は、最大公約数的に共通部分を限定して作っている。そのためカスタマイズ部分が、個々のシステムのかなりの部分を占める。同一業務を行っている対象であっても、それぞれの実施方法や、管理手法は異なっている。異なっている部分がその企業の特質であり、競争を勝ち抜く原動力になっている場合が多いからである。従来のシステム設計は、ハードウエアの機能的限界について、把握することから出発している。その中でどのように最適化を図るかに終始している。これに関連する従来技術の例を以下にあげる。

特許文献１に開示された「情報処理装置」は、ビジュアルベーシックなどのVisual開発言語を使用して、画面入出力系を持つアプリケーションプログラムを作成するとき、１つのFormのみで、画面の入出力量（入出力項目数）に依存しないアプリケーションプログラムを構築して開発労力を飛躍的に低減させるものである。プログラムの実体を示す１つの基本Formプログラムによって、画面上に動的に作成、配置されるControlを定義している定義体ファイルから情報を読み取って、画面上にControlを動的に生成、配置するとともに、定義体ファイルの画面情報に基づき、データファイルからデータを読み取って、これを所定のControlに供給する。
特開2000-112735号公報

しかしながら、従来のシステム設計技法では、次のような問題がある。作成されたプログラムやファイルを、同一業務の他のシステムや他の対象業務に転用することができない。プログラムやファイルを資産として蓄積し活用することができず、使い捨てをしている。パッケージ手法を採用しても個々のカスタマイズとパッケージ全体が、統一した設計思想で作成されないため、パッケージのバージョンアップ毎に矛盾が発生し、カスタマイズ部分の作り直しが必要となる。カスタマイズ部分の使い捨てである。すべての対象に合致するパッケージの作成は不可能である。バージョンアップの時のカスタマイズ工数と費用が膨大になる。従来の手法は、プログラミング技術の統一と省力化に過ぎない。業務そのものから発想しシステム設計技法を統一するという観点からは中途半端である。

システムおよびプログラムのメンテナンスが行われる度に、仕様書の書き直しをすることは、現実には不可能である。プログラムを読まなければ、実際のシステムの中味を把握することができない。システム設計書やプログラム仕様書は、建前資料となっている。プログラムのたった１行で、システム全体に影響を及ぼすような障害が発生し、それを防ぐためには、多大なテスト作業とプログラムの解析が必要となる。

従来のシステム設計では、物理ファイルは統一されていない。システムごとに、複数の物理ファイル（テーブル）が規定される。各ファイルに関する入出力方法もシステムごとプログラムごとに、SEとプログラマーが決定している。SEとプログラマーの能力によりシステム効率に大きな差が出来る。デバッグのためのテスト方法もプログラムごとにその都度決めなければならない。システム設計で使用されるマスターファイル・トランザクションファイルなどの用語について、確立された定義は存在せず、統一した手法もない。ここでも、SEの数だけ違った考え方が生まれる。

従来のシステムでは、記録を間違った場合の「訂正」と、事実が変化した場合の「変更」とを区別していないものが、数多く存在する。会員の今現在の住所を把握するだけで良いのであれば、引越しをして住所が変わったことと、会員の新規登録などで間違って入力した住所を訂正することの間には、システム上の差異はない。画面上に「登録・訂正・削除」という処理区分しかないようなシステムがこれに当たる。しかし、このようなシステムでは、地区別の会員数の増減を出力しようとすると、履歴が無いため、現在の会員数にしか対応できない。過去のある時点の状況を再現するには、システムの作り直しが必要となり高価なカスタマイズ料が必要になる。

履歴を意識するとプログラムが急に複雑になるという事情が反映している。売上管理システムで取扱商品に履歴があると、売上伝票の日付時点でその商品が取り扱いされているか、つまり、その売上日付が商品の有効期間内にあるかどうかをチェックしなければならない。逆に、取扱商品の廃止登録をする場合は、廃止日以降に当該商品を記載した売上伝票が存在しないかどうかのチェックが必要となる。取扱商品の取り扱い開始日を変更する場合も、同様のチェックが必要になる。プログ ラマーに対する時間的、能力的負荷が急に増大する。したがって、SEは通常、履歴を把握するべき項目を極力減らそうとする。しかし、履歴を把握していなければ、過去のある時点での状況を再現することはできない。

履歴の管理を複雑にしているもう１つの原因に、人間はミスをするということがある。正しいデータしか入力されないのであれば、プログラミングは簡単である。しかし、データの認識過程・記録過程・コンピュータへの入力過程で、人間はミスをする。登録済みのデータの訂正・削除は当然可能でなければならない。現在値のみしか持たないシステムであっても、訂正・削除については論理的整合性を保つためには、注意が必要である。履歴を持つ場合は、存在チェックがさらに付け加わって複雑になる。この論理構築作業をSEがそれぞれの経験に基づいて行っており、SEの数だけ違った考え方ができてしまう。具体的プログラムのアルゴリズムも、仕様書には書ききれず、プログラマーの能力と経験により、プログラマーの数だけ違ったプログラムが生まれてしまう。設計技法と更新処理の統一がここでもなされていないのである。

ある人を取り巻く様々な関係は多種多様であり、有機的な関連を持っている。あるひとは、ある所帯の一員であり、ある町内会の一員であり、ある企業の一員である。ある趣味の会の一員である場合もある。どこかの銀行に普通預金の口座を持っているはずである。社会的な存在である人の関連は、無数に存在している。それを、１つのシステムの中ですべて表現することは、事実上できない。ある人は無限の関連のなかにあり、「システムがある」という観点からでは関係を限定できず、システム設計を完結することが不可能となる。したがって従来は、今作成するシステムに必要なもののみを切り取って「システムとしてみる」という観点から設計を行っている。

しかし、売上・売掛管理システムを運用している企業が、仕入・買掛管理システムを新たに導入しようとする時、同一相手先に売上と仕入の両方が発生する場合がある。その時、売掛金と買掛金の相殺をスムーズに行うため、同一相手先であることを把握する必要が出てくる。その場合、パッケージであれ個別開発のシステムであれ、相手先の同一性をシステム上どのように表現するかは、担当SEにまかされている。SEの数だけ処理方法ができてしまう。システム設計上、「システムがある」という観点にたった処理を最初から意識しなければならないにも関わらず、その手法がこの点でも統一されていない。

本発明の目的は、上記従来の問題を解決して、システムの設計技法を統一して設計することで、柔軟で汎用性と永続性のあるシステムを低コストで作成し、蓄積することである。

上記の課題を解決するために、本発明では、情報処理装置に、以下のようなデータベースと更新処理手段とを備える。データベースは、記録ファイルとログファイルを有する。記録ファイルとログファイルを、１項目１レコードの構造にする。あるシステムに関するすべての記録を、記録ファイルとログファイルにのみ記録する。すなわち、すべての業務処理におけるデータを記録するファイルを、複数の「語」レコードを組み合わせた「文」からなる単一のデータ記録構造の記録ファイルとログファイルに統一する。更新処理手段は、各項目の更新処理と読出しを統一的に行う。

さらに、更新処理手段として、以下のように統一的に更新処理を行うシステムエンジンを備える。更新処理区分を、現実に起こった事象（現実事象）の記録区分である「発生」「変化（増減・現在値）」「消滅」と、システムへの入力処理（入力事象）の記録区分である「登録」「訂正」「削除」に分ける。すべての記録の更新処理を、その９通りの組合せのうちのいずれかで表現する。すべての記録を「ログファイル」に入力順に保持する。訂正される前のデータと削除されたデータを除いたすべての記録を、「記録ファイル」に保持する。「ログファイル」と「記録ファイル」に対して、９通りの組合せのうちのいずれかで、更新処理を行う。「記録ファイル」は、システム別と論理ファイル別に取り出し可能な基本的キーを備えている。

さらに、記録ファイルとログファイルの記述内容を論理的に定義するために、複数の定義体ファイルを備える。定義体ファイルは、あらゆるシステムに共通のプロパティ定義体ファイルと、各プロパティがシステムごとにどのように使用されているかを定義するアイテム定義体ファイルと、システム対象項目をアイテムのかたまりとして定義するセンタークラス定義体ファイルと、各項目の変化と現在値を記録するための履歴クラス定義体ファイルと、各クラスの記録順と読み出し順を定義するキー定義体ファイルと、入力処理を画面ごとに定義する入力画面定義体ファイルと、出力処理を帳票ごとに定義する出力定義体ファイルである。システムエンジンは、これらの定義体を参照して、アプリケーションプログラムのために、更新処理と出力を統一的に行う。各定義体は、類似するシステムにコピーして、修正し蓄積して再利用できる。また、センタークラス定義体と履歴クラス定義体とキー定義体と入力画面定義体と出力定義体の関連を解析して、プログラム仕様書を出力する。

上記のように構成したことにより、対象の特質を生かした総合的な情報処理システテムが、少ない工数と低コストで作成でき、データの共有も簡単になる。システムの変更に、より柔軟に対応できる。また、プログラムやファイルを蓄積して資産化して再利用できるので、真のERP（Enterprise Resource Planning：企業資源利用計画）が実現できる。

以下、本発明を実施するための最良の形態について、図１〜図12を参照しながら詳細に説明する。

本発明の実施例は、すべての業務処理におけるデータ記録構造を、１項目１レコードの「語」の集合である「文」という形式に統一し、システムに関するすべてのデータを、「記録ファイル」と「ログファイル」にのみ記録し、「定義体ファイル」の記述に従って、各項目の更新処理と読出しを統一的に行う情報処理装置である。

図１は、本発明の実施例における情報処理装置で用いるログファイルと記録ファイルの基本構造の概要を示す表である。図２は、現実事象（現実に起こった事象）と入力事象（システムへの入力処理）を説明する表である。図３は、会計システムの構成を示す概要図と、ログファイルと記録ファイルの記述内容を示す表である。図４は、会員システムのログファイルと記録ファイルの記述内容（現実事象）を示す表である。図５は、会員システムのログファイルと記録ファイルの記述内容（入力事象）を示す表である。図６は、システムがあるとした場合の関連図である。図７は、システムとして見るという観点からの関連図である。図８は、会員システムにおけるクラス・アイテム・プロパティ関連図と、クラス・アイテム・プロパティ定義体の表である。図９は、ログファイルと記録ファイルのキー構造とキー定義体を示す表である。

図10は、基本関数を示す表である。図11は、入力様式定義体・出力様式定義体を示す表である。図12は、システムエンジンの位置づけを示すシステム構成の機能ブロック図である。図12において、入出力装置１は、データを入力するキーボードなどの手段と、データ出力するディスプレイなどの手段である。システムエンジン２は、データの更新処理などを行う更新処理手段である。定義体ファイル３は、システムやデータを規定する情報を格納したファイルである。ログファイル４は、すべての記録を入力順に保持するファイルである。記録ファイル５は、訂正される前のデータと削除されたデータを除いたすべての記録を入力順に保持するファイルである。

上記のように構成された本発明の実施例における情報処理装置の設計思想と動作を説明する。最初に、設計思想の原理を説明する。無限の容量、無限のスピードを持ったコンピュータを仮想的に考える。その時、履歴を意識し、人間はミスを起こすという前提に立ち、システムの変化、拡大に柔軟に対応できるデータ構造とはどのようなものかを、本質的に考え、決定する。その上で、現実のコンピュータの機能的限界に即して、様々な手法を付け加える。現実のコンピュータの機能が向上すれば、必要でなくなった手法は排除すればよい。

図１（ａ）は、ログファイルの基本構造である。ログファイルには１回の更新処理毎に文番号が振られ、１回の更新記録毎に枝番号がふられる。バッチ処理において１回の更新処理の中で、複数の更新記録が存在するとき枝番号が振られる。例えば、介護システムにおいて、訪問介護の計画から予定を作成するとき、１回の予定作成という更新処理中には、利用者１人１人の１回ごとの訪問予定を記録する複数の更新記録が存在する。共通の更新処理を示す１つの文番号の下に複数の更新記録を示す枝番号が記録される。１個の文番号＋枝番号ごとに、ヘッダー部分とデータ部分が存在する。ヘッダー部分には、この文の更新処理の性格と日付が記録される。データ部分には、具体的な更新内容が記録される。ヘッダー部分もデータ部分も、１項目１レコードで記録され、各レコードには語番号が振られる。システムのすべての情報が、この形式で統一的に記録される。

図１（ｂ）に、記録ファイルの基本構造を示す。記録ファイルには、ログファイルのデータ部分の１つ１つの「語」について、どのシステムのデータであるか、どのクラス（従来のファイル又はテーブル）のデータであるか、どの基本IDについてのデータであるか、どの入力様式で作成されたデータであるか、どのアイテムのデータであるかと、その具体的更新内容が記入される。システム内で有効期限を持つデータには、発生日とその文番号（＋枝番号）及び消滅日とその文番号（＋枝番号）が記入され、そのデータの有効期限が判断できるように記録される。現在値や増減などある変化の発生を示すデータには、発生日とその文番号（＋枝番号）のみが記入され、そのデータの発生日が判断できるように記録される。

本発明の実施例の具体的手法として、記録ファイルとログファイルですべてのデータが記録できることを説明するためには、いくつかの概念規定が必要である。まず、「現実事象」について、図２（ａ）を参照して説明する。「現実事象」とは、現実に起こった事実をどのように更新記録するかを分類したものである。システムのデータにおいては、履歴を示す変化レコードが重要である。なぜなら、システムに書込みが必要となるのは、何らかの変化が起こったときだからである。例えば、簿記において変化レコードは仕訳である。ある企業が設立されてから今までのすべての仕訳を足し算すれば、その企業の現在の貸借対照表を作成することが出来る。ある人の最終学歴も、その人の入学、卒業、中退などの履歴レコードを保持すれば、どの時点での最終学歴であっても表示可能である。したがって、本発明の中では「変化」を中心として考える。

「変化」には数値項目と属性項目がある。数値項目には、増減と現在値がある。増減とは、仕訳のように金額の増減を扱うものや、入出庫のように数量の増減を扱うものがある。現在値とは、体温、試験のときの１回の点数、100メートルの走破記録等がある。ある勘定科目のある期末の残高も現在値である。複数の現在値の差額で変化が認識できる。属性項目では、属性の開始と終了と、属性の現在値がある。属性の開始とは、入学や転居後の新住所や役職就任など、ある属性がある主体に属するようになったことを意味する。属性の終了とは、卒業・退学や転居前の住所や役職解任など、ある属性がある主体に属さなくなったことを意味する。属性の現在値とは、現住所や趣味など、ある主体についてある時点の属性として認識したことを意味する。住所のように、ある時は開始又は終了として、ある時は現在値として記録される物もある。例えば、会員システムにおいて、入会時の住所は現在値であり、変更届では、転居前の住所の終了と転居後の住所の開始が記録される。「変化」の中に現在値が含まれているのは、現在値を認識しようとする事そのものが、システム内における認識の「変化」を示していると考えればよい。

ところで、「変化」レコードを記録するには、「集計単位」が必要である。例えば、仕訳レコードは、勘定科目という「集計単位」がなければ記録しようがない。会員管理における住所・性別・生年月日などのレコードも、会員という「集計単位」がなければ意味を持たない。これらの「集計単位」には、システム上、有効期間が存在する。例えば、会員が入会してから退会するまでが、その会員の有効期間であり、その会員の住所・性別・趣味などの属性も、システムから見ればその期間だけ有効なものである。有効期間の開始を「発生」、終了を「消滅」と定義する。「発生」「消滅」は、社会的な意味と必ずしも一致しない。例えば、ある個人会員の社会的「発生」と「消滅」を示すのは、生年月日と死亡年月日である。

しかし、会員管理システムでは、入会と退会がシステムとしての「発生」と「消滅」を示している。言い換えれば、「発生」とは、その対象がシステムに認識されたことを示し、「消滅」は、システムの認識対象から除外された事を示していると定義できる。「システムがある」という観点からは、システムの決定された範囲に登場することと、除外されることだと定義することもできる。「集計単位」は、会員や勘定科目といった基本的な項目だけではない。会員管理システムにおける趣味、住所（地名）等付随的な属性項目も、マスター登録するものについては「集計単位」である。「集計単位」には、有効期間の管理が必ずしも必要のないものもあるが、原則として日付の管理を行い、必要のないものは無視することにより、更新処理の統一ができる。

以上を踏まえて「現実事象」を整理すると、以下の通りである。システムとして把握されるデータは、すべて（認識の）「変化の記録」である。「変化の記録」は、「集計単位」の「発生」つまり有効期限の開始を扱うものと、「集計単位」の「消滅」つまり有効期限の終了を扱うものと、各「集計単位」の有効期限内を前提として、様々な集計単位に付随する「変化」を扱うものに分けることができる。両方が同時に記録される場合もある。具体的な実施例を、図３（ａ）を参照して説明する。図３（ａ）は、会計システムの例である。「集計単位」と、その有効期間の開始と終了を管理するデータの集まりを「センタークラス」と呼ぶ。センタークラスの各データの有効期限内の「変化」を記録するデータを「履歴クラス」と呼ぶ。会計システムのセンタークラスは「勘定科目センタークラス」である。勘定科目のコードや名称は「勘定科目履歴クラス」に記録される。仕訳は「仕訳履歴クラス」に記録される。

勘定科目には、社会的勘定科目体系が背景として存在しており、個々のシステムは、その中から選択して具体的な勘定科目を設定する。「勘定科目センタークラス」は、勘定科目の採用つまり「発生」と、勘定科目の使用中止つまり「消滅」を日付とともに記録する。センタークラスの各項目の認識のためIDが自動裁番されるが、IDについては後述する。「勘定科目履歴クラス」は勘定科目の採用時つまり「発生」時点の「変化」（主に現在値）としての勘定科目名や、コード、貸借区分を記録するとともに、勘定科目の有効期限内に起こる様々な「変化」を記録する。「仕訳履歴クラス」は勘定科目の有効期限内の金額的増減という「変化」のみを記録する。従来の設計手法では、各クラスを物理的に別々のファイルとして定義する。本情報処理装置では、これを「記録ファイル」と「ログファイル」の２つの物理ファイルに統一的に記録する。

「履歴クラス」は、複数の項目を持っている。「勘定科目履歴クラス」には、勘定科目名・勘定科目コード・貸借区分などの項目がある。これらの項目を「アイテム」と呼ぶ。「仕訳履歴クラス」にも、借方科目・金額・貸方科目・金額・摘要などの「アイテム」が存在する。「クラス」「アイテム」をシステム上どう扱うかは、順次説明の中でふれていく。一方、センタークラスのアイテムはIDのみである。

記録ファイルとログファイルの具体的な記録方法を、図３（ｂ）と図３（ｃ）で説明する。文番号１及び２は勘定科目の登録である。「集計単位」である勘定科目として、現金と売上を採用したこと、「発生」を記録している。コード1001、借方科目として、現金という科目を、コード5001、貸方科目として、売上という科目を登録したことを示している。文番号３は仕訳の登録である。「集計単位」である勘定科目の存在を前提として、金額の増減である「変化」を記録している。現金売上が10万円あったので仕訳を行ったことを示している。従来であれば、勘定科目マスターファイルと仕訳ファイルを物理的、に別々に定義しその定義に従ってSEが更新方法を仕様書で決定し、プログラマーが具体的処理方法を、プログラミング言語を使用して記載していた。本情報処理装置では、３つの記録は同じ「記録ファイル」と「ログファイル」のみに統一形式で記録される。つまり、従来のマスターデータもトランザクションデータも同じ物理ファイルに統一的に同一手法で記録されるのである。図３（ｂ）、ログファイルはこのように更新順に記録されている。図３（ｃ）、記録ファイルではシステム別、基本ID別、日付順など、業務の必要に応じて読出しやすい形式で記録される。

ここでIDとコードの違いを説明する。通常１つのシステム内で同一性を判定するためにはコードが使用される。同じ勘定科目に２つのコードが振られることはない。しかし、会計システムだけではなく売上管理システムが同時に運用されている場合、売上管理システムでは売上コードを１とし、入金コードを２と規定する場合がある。この時、会計システムのコード5001と売上管理システムのコード１とが同一の「変化」を記録していることを判定するためには、それぞれのコードが同じ勘定科目IDの0002であることを保障する必要がある。従って、当装置では複数のシステムにまたがる場合は当然として１つのシステム内であっても「センターファイル」に記録されるすべての対象にコードとは別のID番号を強制的に振り、すべての記録でID番号を使用する。勘定科目名などの名称もシステム内の同一性を判定するために使用される場合もある。

しかし、勘定科目名も時代とともに変化することがある。例えば減価償却引当金という科目名は減価償却累計額に変わった。しかし、その意味するところは同一である。この時ID番号を持つことにより、勘定科目名が変化してもその同一性をシステム的に判断することが出来る。人のデータを扱う場合、結婚や養子縁組で姓が変わることはありうることであり、本人の同一性を確保するためには、姓名に頼ることなく、最初からIDをふっておく事は必須である。つまりある主体の同一性を、属性がどのように変化しても認識できるよう、IDをふるのである。

図４（ａ）と図４（ｂ）は、会員管理システムの実施例である。文番号４及び５は会員種別の登録である。「集計単位」である会員種別が正会員と準会員と定められたという「発生」を記録している。文番号６は趣味の登録である。「集計単位」である趣味として、読書が採用されたという「発生」を記録している。文番号７は山田太郎が正会員になったという「発生」と、その時点の住所や趣味の現在値や、会員番号という属性の開始という「変化」を同時に記録している。記録ファイルでは会員になったことは会員センタークラスに自動採番されたIDとして記録され、その発生日と文番号が記録される。属性や決定された会員番号は、会員履歴クラスの各アイテムとして記録される。文番号８は山田太郎が会員として存在していることを前提として、転居による古い住所の終了と新しい住所の開始という「変化」を記録している。

記録ファイルには、会員履歴ファイルに古い住所の終了と新しい住所の開始が住所アイテムの有効期限を示すものとして記録される。会計システムにおける仕訳履歴ファイルは「変化」だけを記録するが、会員履歴ファイルは発生時点の「変化」もその後の「変化」もともに記録する。文番号９は山田太郎が会員でなくなった「消滅」を記録している。ログファイルは、全ての記録を記録順に保持するので文番号９で記録される。記録ファイルでは、「集計単位」の有効期限の判定、管理を容易に行うことと、データの読み出しを実際のシステム運用上、より迅速に行うために会員センタークラスのIDの0006番が消滅したことを示す消滅日付とその文番号が会員センターファイルの該当欄に記録される。

ここまで述べたような記録構造をとれば、業務処理システムの全てのデータを統一形式で記録することが出来るだけでなくアイテムの追加も簡単である。すべて１アイテム１レコードで記録されているので、アイテムを追加しても記録構造に変更が必要ないのである。例えば、図３（ｂ）の会員管理システムで最終学歴を追加したい場合、文番号７の１に語番号15として最終学歴のアイテムを定義体に追加すればよい。更新処理の手法を変える必要がないのである。このことによりシステムのメンテナンスの工数が飛躍的に減少するとともに、後で述べる各種定義体の蓄積、再利用も可能となる。従来のデータベースではこの「現実事象」が考慮されていない。

次に、図２（ｂ）を参照して、「入力事象区分」について説明する。「入力事象」とは、システムでの記録を行う場合の誤謬と、それに対する対応のことである。「登録」とは、システムに対するなんらかの記録を行うことである。もし人間がミスを犯さないなら「登録」だけでよく、区分は必要ない。しかし、ミスを完全になくすことはありえない。ミスを含んだ記録は、記録内容を「訂正」するか、記録そのものを「削除」する必要がある。記録上の誤謬の原因には、認識に関するミス（思い込み、うっかり）、記録時の記入ミスと、システムへの入力ミスによるものとがある。厳密には区分すべきであるが、実務上、両者を区分する必要がない事が多く、同じものとして取り扱う。区分したいときは、アイテムとして訂正理由の項目を設定し、必須記録項目とすれば管理可能となる。

前掲の会員システムでの訂正・削除の例を図５（ａ）と図５（ｂ）を参照して説明する。文番号10は会員の住所変更の記録が間違っていたことの訂正である。東京都大田区とするべきところを、会員自身が間違えたか、入力時に間違えたかのどちらかの理由により、港区として登録されたと考えられる。ログファイルでは、訂正も１つの記録として捉え、１つの文番号が振られる。訂正の元になった記録が「変化」であるので、現実事象は「変化」、入力事象は「訂正」となる。訂正により港区が取り消されたこと、大田区が登録されたことが、ログファイルに記録される。記録ファイルでは、直接港区を大田区に書き換える。文番号11は、会員の退会の取り消しである。退会届の入力において他の会員と思い込んだか、会員コードのパンチミスにより、誤って退会処理をしてしまったことに後から気づき退会処理記録の削除をする場合である。ログファイルでは、削除も１つの記録として捉え、１つの文番号がふられる。削除の元になった記録が「消滅」であるので、現実事象は「消滅」、入力事象は「削除」となる。ログファイルでは元の記録は削除されたことが記録される。記録ファイルでは、消滅日付と消滅文番号が空白（ブランク）に戻される。

つまり、３つの現実事象「発生」「変化」「消滅」と、３つの入力事象「登録」「訂正」「削除」との組み合わせにより、ログファイルと記録ファイルのすべての記録の処理方法が、一義的に決定出来る。本情報処理装置では、プログラマーがプログラミングするにあたって、論理ファイルの構造がどのようなものであれ、具体的な記録の処理を統一できるよう、少数の関数を用意する。SEは仕様書で関数を指定することにより統一的な更新記録と呼び出しを実現できる。プログラマーは、更新や呼び出しについて、毎回自分で考える必要はなく、指定された関数の記述をするだけで良い。プログラミングのエネルギーを画面の操作性や論理チェックに集中することが出来る。関数の内容については、後で説明する。

図３（ｂ）と図３（ｃ）を参照して、繰返番号を説明する。ログファイルと記録ファイルでは、各アイテムに２次元テーブルを示す繰返し番号が振られる。これは、会計伝票や、売上伝票のように１つの伝票の中で複数の行があり、同じ性格の記録が繰り返される場合、その何行目かと借方貸方という性格の区別を記録するものである。１−１は借方１行目を示し１−２は貸方１行目を示す。このことにより、仕訳における勘定科目の行数制限がシステムごとに変わっても繰返し番号の制限を変えるだけで、記録構造を変える必要は無く、システム設計上の柔軟性を確保できる。

次に「プロパティ」と「アイテム」について図６と図７と図８を参照して説明する。まず、図６を参照して、「システムがある」という考え方を説明する。ある人について社会的に存在する関連の一部を示した図である。ある人は家族や世帯の一員である。ある市町村に住んでいる。市町村からは行政サービスを受け取っていると同時に、条例に従う義務や納税の義務を負っている。都道府県や国の一員でもある。さらに、ある人は、地球上に存在する生命体の一部であり、他の動物や植物と関連を持って生きている。地殻の上に住んでおり、地震などの影響や、気候にも影響を受けながら存在している。自然の大きなシステムの一部でもある。一方、社会的な教育を受けながら成長していく。その過程では何らかの教育機関の一員であり、その中で授業だけではなく、クラブ活動などを通じで人間関係を築いていく。卒業後は同窓会に所属する。勤務先ではその組織の一員であり、同僚との人間関係を持っている。取引先として様々な法人・個人と関係を持つ。慣習や道徳、法律の影響を受けている。趣味や社会活動、酒場などでの出会いを通じて様々な人間関係を築いていく。逆にある人は、筋肉組織や骨格組織、内臓や神経から出来ており、脳の機能として知識や思考力を持っている。これらの組織や関係はすべてシステムとして見ることが出来る。つまり、ある人を取り巻くシステムは多様であり、見方によって無数に存在しており、客観的な「システムがある」という発想では、ある人を取り巻く無限のシステムが存在することは示せても、業務対応システムとしては成り立たないのである。

次に、図７を参照して、「システムとして見る」という考え方を説明する。業務対応システムは、必ず何らかの目的を持って作成される。現実の様々な関連の中から、そのシステムに必要な範囲を定め、主体的に切り取る作業である。図７の縦方向は、システムとして見るという観点から分類された、具体的システムの例である。会計システムは、主として価値の表現である勘定科目毎貨幣価値の増減を扱い、人や物は、取引の摘要として現れる。売上売掛システムや、仕入買掛システムでは、得意先や仕入先として現れる人を中心に、売上仕入の発生高と、売掛買掛という債権債務として現れる価値の残高を取り扱う。物は商品として摘要に現れる。在庫管理システムとしてみれば、物は商品として現れる、物を中心に、その数的増減を扱う。人は出荷先や入庫元として摘要に現れる。この表の各升目に現れるのが、そのシステムのアイテムである。「システムとして見る」という観点から、例えば、会員管理システムの中で、会員として把握されるある人について、必要とされる情報の範囲を定めることは、システム設計の第一歩である。意識的であれ無意識であれ、SEであれば普通に行なっていることである。この範囲を固定しても、システムの内容や範囲が変化しなければ何の問題も起こらない。

しかし、システムの前提である業務は変化していく。システムの処理対象の範囲は拡大していくのが普通である。その時、情報の範囲が固定されていると、システムは処理内容の拡大に対応できなくなる。範囲を拡大する手法は担当SEにまかされ、SEの数だけ設計方法が出来てしまう。それを解決するために、すべての項目について、「システムがある」という観点から把握するための「プロパティ」定義体と、「システムとしてみる」という観点から把握するための「アイテム」定義体を最初から用意し、その扱い方法を統一することによって、システム設計手法の統一化を実現する。売上売掛システムの得意先と仕入買掛システムの仕入先が同一であることを保証するために、最初から人プロパティを定めておき、得意先と仕入先という違うアイテムが、同じ人プロパティに属していることをアイテム定義体で規定しておけば良い。このことによって、システムをまたがって現れてくる人の同一性が確保され、売掛と買掛残高の相殺が容易となる。

図７の横方向がプロパティの実例である。最初、「人」「物」「価値」など基本的にあらゆるシステムに共通して使用されるものを用意する。これらは、社会的にその扱いが共通しているものである。各プロパティには、名称、社会的発生日、社会的消滅日、所在地（地名）などの属性プロパティがある。「自然人」プロパティであれば、姓名・生年月日・死亡年月日・住所（地名）などのプロパティである。各プロパティはプロパティ定義体に定義される。システムが「自然人」を取り扱う上で不可欠なこのような定義体のかたまりを記載したものが「自然人」プロパティ定義体群である。あらゆるシステムに現れる「自然人」についてこの定義体群を利用すれば、システムごとの設計作業を統一出来、作業工数の軽減がはかることが出来る。この定義体に従って作成されるデータの登録処理を統一するサブルーチンを用意し、例えば、同一人物を違うIDで登録することを防ぐ基本になる定義体群でもある。

「物」や「価値」などについても、それぞれの社会的な特徴にそった扱いを統一できるように、プロパティ定義体群を準備する。図７の上部の記載がその一部である。しかし、それだけに固定されるものではない。システムの設計過程では、それまで定義されていない項目については、その都度すべての項目に関して、それぞれ新たなプロパティを定義し蓄積していく。新たなシステム設計では、蓄積された定義体群から、類似したものを探し、コピーし必要な訂正を加えて、さらに蓄積していく。その結果、プロパティ定義体群の全体がカバーする客観的な社会関係の範囲が拡大していく。プロパティ定義体群を繰返し利用することによってシステム設計のスピードが加速する。各SEの設計手法を統一できるし、統一的な教育も可能となる。個々のプロパティ定義体には、項目の性格・内容・形式が記録される。数値であるか文字列であるか、日付であるか、最大値・最小値などである。これらの項目を統一的に処理するルーチンをシステムエンジン内に準備し、存在チェックだけでなく、範囲チェックや妥当性チェックなどもシステムエンジンが行うことにより、プログラミング作業の更なる短縮ができる。

１つのシステムで、同じプロパティが、違うアイテムとして使用される場合がある。例えば、自然人は、会計システムでは摘要内の関係者として現れるに過ぎない。しかし、売上売掛システムでは、個人の得意先として現れるだけでなく、法人得意先の代表者や担当者としても現れる場合がある。会員システムでは、個人会員だけでなく、個人会員の家族や法人会員の代表者として現れる場合もある。会員システムを例にとれば、システム上、会員本人と、家族、代表者は、別々のアイテム定義体として定義される。同じプロパティが、各システムで具体的に現れる現れ方を定義するために、アイテム定義体が定義されるのである。逆に言えば、会員本人や会員家族アイテムが自然人プロパティに属していることをアイテム定義体に定義しておくことにより、ある会員本人が他の会員の家族である場合、同一人物であることを認識できる。また、会員の家族単位の構成の把握などシステムを拡張したい場合の対応も容易に行える。その場合、会員本人の生年月日は必須項目であるが、家族や代表者の生年月日はシステム上必要とされないことが多いなど、扱いが異なる場合にもアイテム定義体で規定できる。

具体的なシステムにおいて、各アイテムは単独で扱われることはない。何らかの基本アイテム（インスタンスID）を中心としたかたまりとして現れる。このデータのかたまりをクラスと定義する。従来のファイルとかテーブルという概念と同じものであるが、本処理装置の機能を説明するため、クラスという概念を導入する。クラスとアイテムプロパティの関係について、図８（ａ）を参照して説明する。会員システムの具体例である。この会員システムのセンタークラスは、会員センタークラス、会員種別センタークラス、趣味センタークラス、会費処理区別センタークラスである。履歴クラスは、会員履歴クラス、会員種別履歴クラス、趣味履歴クラス、会費処理区別履歴クラス、会費請求入金クラスである。

各クラスはクラス定義体に定義され、センタークラスか、センター履歴クラスか、履歴クラスに分類される。センタークラスは集計単位の発生と、消滅を記録し、具体的な集計単位はIDで記録する。センター履歴クラスは、基本アイテムの発生、変化、消滅それぞれの時点での各属性項目の履歴を扱う。つまり、基本アイテムの有効期限内の各属性項目の履歴を扱う。履歴クラスは、基本アイテムの有効期限を前提に、各項目の変化のみを扱う。各クラスにどのようなアイテムが含まれるかは、アイテム定義体に定義される。アイテム定義体の各アイテムには、そのアイテムの性格と、そのアイテムがどのプロパティに属しているかが定義される。アイテム定義体には、プロパティ定義体で規定された性格が、個々のアイテムでどう利用されるかが定義される。例えば、あるシステムで仕訳の桁数を制限したい場合は、ここで定義すればよい。システムエンジンはこれらの定義体を参照して処理方法を決定する。図８（ｂ）に、「プロパティ」「アイテム」「クラス」の定義体の具体的内容と各項目の意味を示す。

次に、図９（ａ）、（ｂ）、（ｃ）を参照して、キー定義体について説明する。ログファイルで最初から用意されているメインキーは、図９（ａ）に示すように、文番号＋語番号である。記録ファイルで最初から用意されているのは、メインキーと５つの副キーである。副キーの内容と意味を、図９（ｂ）に示す。これらは、業務処理システムにおいて共通して使用されるものから、その使用頻度が高いと思われるものを設定してある。各具体的システムでは、これらのキー以外にも必要とされるものがある。その設定を容易にし、再利用できるように、キーファイル定義体を作成する。システムエンジンは、最初からログファイルと記録ファイルに設定されたキーと、キー定義体に規定されたキーを、自動的に生成する。キー定義体の具体的構造を、図９（ｃ）に示す。物理ファイルは、ログファイルと記録ファイルの２種類しかないため、論理ファイルはキー定義体ファイルで指定するのである。このことにより、論理ファイルは自由に設定できる。また、項目の追加時にも、必要に応じて新しいキーファイルを設定することにより、柔軟な対応が可能となる。

このような記録構造を持つため、記録ファイルでデータの破損が起こった場合でも、ログファイルがあれば記録ファイルの再現はいつでも可能である。ミラーリングなどの手法で、ログファイルを常にバックアップしておけばよい。また、ある時点の記録ファイルと最終文番号を定期的にバックアップしてあれば、その文番号以降のログファイルにより、記録ファイルの再現は、より迅速に行なうことができる。

以上の説明により、本情報処理装置の基本的記録方法と読出方法が、明らかになった。具体的な処理は、システムエンジンが持つ関数によって行われる。関数の具体的内容を、図10に示す。関数の説明と具体的な使用例を以下に示す。物理ファイルが統一されているため、これら少数の関数で記録と呼出しが可能となる。

関数
システムのオープン(Open)：データベースをオープンし、初期設定（プログラム権限レベル）を読む。入力＝データベースのエリアス名、データベースのパスワード。
クラス情報設定(GetClassInfo)：指定したクラスを元に、領域を確保し、アイテム、プロパティ情報を読み込む。プログラム履歴ファイルに、起動中のプログラムが登録されている場合、指定された対象日付において有効なものを読む。入力＝クラスコード、対象日付。出力＝アイテム内容テーブル。
データ読込(Read)：インスタンスIDからクラスが持つ全アイテムの内容を得る。入力＝インスタンスID、対象日付。入出力＝アイテム内容テーブル。記録ファイルから読む。１つのアイテムの内容取得の方法は、「データ処理方法」の（1-2-2）を参照。
データ読込、アイテム指定(ReadWithItem)：インスタンスIDから指定したアイテムの内容を得る。入力＝インスタンスID、指定アイテムのリスト、（アイテムコード、アイテムコード、・・・）、対象日付。入出力＝アイテム内容テーブル。記録ファイルから読む。１つのアイテムの内容取得の方法は、「データ処理方法」の（1-2-2）を参照。
データ読込、リスト出力(ReadList)：アイテムの値が条件に一致しているIDを取得。対象日付の指定。入力＝アイテム内容テーブル、対象日付。条件リスト＝（アイテムコード Start 値）、（アイテムコード End 値）の２レコードがセット。複数セット指定も可。指定アイテムのリスト＝（アイテムコード、アイテムコード、・・・）。上記の条件で指定したアイテムのみ設定可。区分１：有効データ、区分２：消滅データ、区分３：有効・消滅データ。出力＝結果リスト、（アイテムコード、ID）の複数レコード。アイテム毎に条件に一致したIDを出力。記録ファイルから読む。「データ処理方法」の（1-2-9）を参照。

履歴リスト抽出(GetHistList)：あるIDのあるクラス内の現実事象の履歴のリストを出力。入力＝インスタンスID、アイテム内容テーブル（この中にクラスを指定する）。出力＝履歴のリスト（現実事象区分、現実事象日付）の複数レコード。記録ファイルから読む。「データ処理方法」の（1-2-8）を参照。
Blobデータ取得(GetMemo)：Blobのリンクコードよりメモデータを得る。入力＝Blobのリンクコード。出力＝メモデータ。
インスタンスIDの割当(GetNewInstId)：出力＝インスタンスID。
インスタンスIDセット(SetInstId)：取得した新規インスタンスIDを、アイテム内容テーブルに格納する。入力＝インスタンスID。出力＝アイテム内容テーブル。
今回事象情報セット(EventSet)：今回事象をアイテム内容テーブルに格納する。入力＝現実事象（区分１：発生、区分２：消滅、区分３：変化）、入力事象（区分１：登録、区分２：取消、区分３：訂正、区分４：日付訂正）、現実事象日付。出力＝アイテム内容テーブル。
アイテム内容テーブルへの格納(SetItem，SetItemDate)：入力＝格納する内容、アイテムコード、繰り返し番号１、繰り返し番号２。出力＝アイテム内容テーブル。
アイテム内容テーブルからの取り出し(GetItem，GetItemDate)：入力＝アイテム内容テーブル、アイテムコード、繰り返し番号１、繰り返し番号２。出力＝取出した内容。

データの登録(Write)：入力＝アイテム内容テーブル、記録ファイルにも書くようにする。「データ処理方法」の（1-1）を参照。過去履歴の登録にも対応する。「データ処理方法」の（3-1）を参照。
複合キーの作成(MakeCompKey)：入力＝アイテム内容テーブル（キーの内容はここに入れておく）、複合キーコード、区分１：前回事象から、区分２：今回事象から。新複合キーファイルにも出力する。「データ処理方法」の（2-1）を参照。過去履歴の登録にも対応する。「データ処理方法」の（3-1）を参照。
カナ文字列からかなキー変換(MakeKanaKey)：途中の空白詰め、濁点、半濁点除去、小文字の大文字化、20バイトになるよう後ろに空白詰め。入力＝カナ文字列。出力＝カナキー。
数値を文字列キーに変換(MakeNumKey)：型変換、20バイトになるよう後ろに空白詰め。入力＝数値型。出力＝文字列キー。
文字列をキー形式に変換(MakeStrKey)：20バイトになるよう後ろに空白詰め。入力＝文字列。出力＝文字列キー。

複合キーからID取得(GetInstIdList)：指定した複合キーのインスタンスのIDを取得。入力＝アイテム内容テーブル（キーの内容はここに入れておく）、複合キーコード、対象日付、区分１：前回事象から、区分２：今回事象から。出力＝インスタンスIDリスト（ID，ID，・・・）。新複合キーファイルから読む。「データ処理方法」の（2-2）を参照。
クラスに属するID取得(GetClassIdList)：指定したクラスに属するインスタンスのID。入力＝アイテム内容テーブル（この中にクラスを指定する）、対象日付、区分１：前回事象から、区分２：今回事象から。出力＝インスタンスIDリスト（ID，ID，・・・）。記録ファイルから読む。「データ処理方法」の（1-2-4）を参照。
クラス指定でカナキーからID取得(GetClassKanaIdList)：指定したクラスのカナキーに前方一致するインスタンスIDを取得。入力＝アイテム内容テーブル（この中にクラスを指定する）、カナキー、対象日付、区分１：前回事象から、区分２：今回事象から。出力＝インスタンスIDリスト（ID，ID，・・・）。記録ファイルから読む。「データ処理方法」を参照。（1-2-9）で指定したカナを持つIDを得て、そのIDが指定したクラスに属するか（1-2-5）でチェックする。
全体でカナキーからID取得(GetKanaIdList)：全クラスのカナキーに前方一致するインスタンスIDを取得。入力＝アイテム内容テーブル、カナキー、対象日付、区分１：前回事象から、区分２：今回事象から。出力＝インスタンスIDリスト（ID，ID，・・・）。記録ファイルから読む。「データ処理方法」を参照。（1-2-9）で指定したカナを持つIDを得る。

前回事象と今回可能事象のチェック(EventCheck)：入力＝アイテム内容テーブル。
今回可能な事象
発生 消滅 変化
登録 取消 訂正 日付 登録 取消 訂正 日付 登録 取消 訂正 日付
前回の事象
発生 △1 ○ ○ ○ ○ × × × ○ × × ×
消滅 △2 × × × × ○ ○ ○ × × × ×
変化 × × × × ○ × × × ○ ○ ○ ○
○＝可能、×＝不可能、△1＝多重発生を許す場合は可能、△2＝再発生を許す場合は可能。あるインスタンスが複数のクラスで扱われる時、他のクラスでは△は○となる。ただし、他のクラスの登録を他のクラスで訂正・取消できない。

データの整合性チェック(DataCheck)：入力＝アイテム内容テーブル。
・必須項目のチェック
・データの範囲チェック
・変化・消滅の日付が発生の日付の前になっていないか
・親子関係(1:0-M)におけるチェック
・子の発生日付が親の発生日付の前になってはいけない
・子が現存する場合、親は消滅できない
・親の消滅日付が、どの子の消滅日付よりも前になってはいけない
・クラスファイルで定義した「発生制約」と「発生のみ」に関するチェック
・プロパティ種別の日付で設定した「変化なし」に関するチェック

日付型をＸ形式文字列に変換(DateToXDate)：日付型をDyyyy-mm-ddの形式に変換する。入力＝日付型。出力＝文字列型。
Ｘ形式文字列を日付型に変換(XDateToDate)：Dyyyy-mm-ddの形式の文字列を日付型に変換する。入力＝文字列型。出力＝日付型。
Ｘ形式文字列を年、月、日に変換(XdecodeDate)：Dyyy-mm-dd形式の文字列から年、月、日を取得。入力＝文字列型。出力＝年、月、日。
IDのロック(XLock)：入力＝インスタンスID。
IDのアンロック(XUnlock)：入力＝インスタンスID。
過去履歴の登録(PastWrite)：入力＝インスタンスID、発生日、指定アイテムのリスト（アイテムコード、アイテムコード、・・・）。指定した複数のアイテムの中に、指定した消滅日以前の消滅日を持つレコードが１つでもあるとエラーにする。消滅日以前の発生日を持つデータが存在する場合、無効化文番号を設定して無効化する。指定された発生日を持つデータと（消滅日＋１日）の発生日を持つデータを作成する。「データ処理方法」の（3-2-1）を参照。
過去履歴の取消(PastDelete)：入力＝インスタンスID、最新の無効化文番号にNULLを設定する。過去履歴登録で作成したデータを削除する。

データ処理方法
（１）記録ファイルに対する処理
（1-1）登録
記録ファイルには、入力事象区分、入力事象日付、現実事象日付、IDのレコードは作成しない。現実事象区分、クラス、その他のレコードを作成する。
（1-1-1）発生の登録：発生日付、発生文番号を入れてレコードを作成。消滅日付、消滅文番号は空欄。
（1-1-2）消滅の登録：消滅日付、消滅文番号を設定。
（1-1-3）変化の登録：「（ID＝指定のID）AND（アイテムコード＝変更のあったアイテムのコード）AND（消滅日＝ヌル）」のレコードに対して、消滅日←（変化日−１日）、消滅文番号←あらたに採番した文番号、新たに、変更後の値を設定したレコードを作製する。発生日←変化日、発生文番号←消滅文番号と同じ値、内容←変更後の値、現実事象区分のレコードも作る。発生日←変化日、発生文番号←あらたに採番した文番号、消滅日←（変化日−１日）、消滅文番号←発生文番号と同じ、内容＝「変化」、どのクラスにおける変化か把握するため、クラスのレコードもダミーで作る。この際クラス自体は変化したわけではないので、発生日、消滅日は空欄にする。
（1-1-4）取消：（1-2-1）の「前回文番号を得る」で得た文番号について、発生文番号にそれをもつものは、そのレコードを消す。消滅文番号にそれをもつものは、消滅日と消滅文番号を消す。
（1-1-5）訂正：「（ID＝指定のID）AND（アイテムコード＝訂正のあったアイテムのコード）AND（消滅日＝ヌル）」のレコードに対して内容を書きかえる。上記条件で複数レコードがある場合は、発生日が最高値のもの。
（1-1-6）日付訂正：（1-2-1）の「前回文番号を得る」で得た文番号について、発生文番号にそれをもつものは、そのレコードの発生日を書き換える。消滅文番号にそれをもつものは、そのレコードの消滅日を書き換える。

（1-2）検索
＊以下の検索処理では無効化文番号に値の入っているものは読まない。
（1-2-1）前回文番号を得る：「（ID＝指定のID）AND（アイテムコード＝"REALEVENT"）」のレコードの中で、発生か消滅のどちらかの文番号が最新のもの
（1-2-2）あるIDのあるアイテムのある時点の値を得る。：「（ID＝指定のID）AND（アイテムコード＝指定のアイテムコード）AND（効力開始日≦指定の日付）AND（効力終了日≧指定の日付（効力終了日が入っているときのみ））」のレコードの値
（1-2-3）あるIDのあるアイテムの最新の値を得る。：「（ID＝指定のID）AND（アイテムコード＝指定のアイテムコード）」のレコードのうち、効力開始日が最新のものの値
（1-2-4）あるクラスに属するＩＤを得る：「（アイテムコード＝"CLASS"）AND（内容＝指定したクラスコード）AND（効力開始日≦指定の日付）AND（効力終了日≧指定の日付（効力終了日が入っているときのみ））」のレコードのインスタンスIDを得る
（1-2-5）あるIDがあるクラスに属するか。：「（ID＝指定のID）AND（アイテムコード＝"CLASS"）AND（内容＝指定したクラスコード）AND（効力開始日≦指定の日付）AND（効力終了日≧指定の日付（効力終了日が入っているときのみ））」のレコードがあるか
（1-2-6）あるIDのあるクラスの発生日を得る。：「（ID＝指定のID）AND（アイテムコード＝"CLASS"）AND（内容＝指定のクラスコード）」のレコードの発生日を見る。
（1-2-7）あるIDのあるクラスの消滅日を得る。：「（ID＝指定のID）AND（アイテムコード＝"CLASS"）AND（内容＝指定のクラスコード）」のレコードの消滅日を見る。
（1-2-8）あるIDのあるクラスの現実事象履歴を得る。：「（ID＝該当者のID）AND（アイテムコード＝"CLASS"）AND（内容＝指定のクラスコード）」のレコードを得て、その文番号から、「（（発生文番号＝その文番号）OR（消滅文番号＝その文番号））AND（アイテムコード＝"REALEVENT"）」のレコードを得る。
（1-2-9）あるアイテムがある値になっているIDを得る。：「（アイテムコード＝指定したアイテムコード）AND（内容＝指定した値）AND（効力開始日≦指定の日付）AND（効力終了日≧指定の日付（効力終了日が入っているときのみ））」のレコードのインスタンスIDを得る。
＊有効データのみの場合、上記に次の行を追加：消滅日＝ヌル
＊消滅データのみの場合、上記に次の行を追加：消滅日≠ヌル

（２）複合キーファイルに対する処理
（2-1）登録
（2-1-1）発生の登録：発生日付、発生文番号を入れてレコードを作成。消滅日付、消滅文番号は空欄。
（2-1-2）消滅の登録：消滅日付、消滅文番号を設定。
（2-1-3）変化の登録：変更のあったアイテムに複合キーのアイテムが含まれるとき作成。「（ID＝指定のID）AND（消滅日＝ヌル）」のレコードに対して、消滅日←（変化日−１日）、消滅文番号←あらたに採番した文番号、新たに、変更後の値を設定したレコードを作製する。発生日←変化日、発生文番号←消滅文番号と同じ値、内容←変更後の値
（2-1-4）取消：（1-2-1）の「前回文番号を得る」で得た文番号について、発生文番号にそれをもつものは、そのレコードを消す。消滅文番号にそれをもつものは、消滅日と消滅文番号を消す。
（2-1-5）訂正：訂正のあったアイテムに複合キーのアイテムが含まれるとき作成。「（ID＝指定のID）AND（消滅日＝ヌル）」のレコードに対して内容を書きかえる。上記条件で複数レコードがある場合は、発生日が最高値のもの
（2-1-6）日付訂正：（1-2-1）の「前回文番号を得る」で得た文番号について、発生文番号にそれをもつものは、そのレコードの発生日を書き換える。消滅文番号にそれをもつものは、そのレコードの消滅日を書き換える。
（2-2）検索
＊以下の検索処理では無効化文番号に値の入っているものは読まない。
（2-2-1）キーの値を指定してそのキーを持つIDを得る（時点を指定）：「（複合キーのコード＝検索したいキーの名前）AND（複合キーの内容＝検索したいキーの内容）AND（効力開始日≦指定の日付）AND（効力終了日≧指定の日付（効力終了日が入っているときのみ））」のレコードのインスタンスIDを得る。

（３）過去履歴の処理
（3-1）登録：記録ファイル、新複合キーファイルについて以下の処理をする。
（3-1-1）過去履歴の登録：発生日付、消滅日付を入れてレコードを作成。指定した消滅日以前に発生日を持つレコードが既にある場合、そのレコードの無効化文番号に文番号を入れて書換え、履歴上無効なレコードにする。そして、指定された消滅日＋１日を発生日にして、それと同じ値を持つレコードを作成する。現実事象区分のレコードも「変化」で作成する。
（3-1-2）過去履歴の取消：（1-2-1）の「前回文番号を得る」で得た文番号について、発生文番号にそれをもつものは、そのレコードを消す。無効化文番号にそれをもつものは無効化文番号を消す。
（3-2）検索
＊以下の検索処理では無効化文番号に値の入っているものは読まない。
（3-2-1）あるID、あるアイテムに、ある日以前の消滅日を持つレコードがあるか。：「（ID＝指定のID）AND（アイテムコード＝指定のアイテムコード）AND（効力終了日≦指定の日付）AND（効力終了日≠ヌル）」のレコードがあるか。

関数の使用例
登録の手順
・システムのオープン(Open)
・クラス情報設定(GetClassInfo)
・これから登録するものが既に別件(入会登録の場合、非会員として登録されているかとか、一度退会したが再入会しようとしているとか、別のクラスに登録されている)で登録されているか検索し、あればその内容をアイテム内容テーブル、インスタンスIDエリア、前回事象エリアに取り込む(下記Ａ)
・前回と今回可能な事象のチェックする(EventCheck)
・別件で登録されていない場合は新規にインスタンスIDを取得する(GetNewInstId，SetInstId)
・そのIDのデータを他の端末でいじれないようにLOCKする(XLock)。それがすでにロックされていた場合、メッセージを出して、先に進めなくする。
・アイテム内容テーブルの中身を画面の項目にセットする(GetItem，GetItemDate)
・各項目の中身を入力
・項目の所にある参照ボタンのクリックでコード化項目の内容を一覧表示し、選択する(下記Ｂ)
・登録ボタンをクリックで、画面項目の中身をアイテム内容テーブルにセットする(SetItem，SetItemDate)
・データのチェック (日付の整合性チェック等)(DataCheck)
・コードが手入力の場合、コードが空番かチェック(ReadList)
・コードが自動採番の場合、コードを割当て表示
・データを登録する(Write)
・インスタンスIDをUNLOCKする(XUnlock)
・システムのクローズ

登録済みデータの呼出しの手順
・システムのオープン(Open)
・クラス情報設定(GetClassInfo)
・コードを入力させ検索する(GetInstIdList)
・そのIDのデータを他の端末でいじれないようにLOCKする(XLock)
・それがすでにロックされていた場合、メッセージを出して、先に進めなくする。
・内容の取込みを行なう(Read)
・前回と今回可能な事象のチェックする(EventCheck)
・アイテム内容テーブルの中身を画面の項目にセットする(GetItem，GetItemDate)
・各項目の中身を入力
・項目の所にある参照ボタンのクリックでコード化項目の内容を一覧表示し、選択する(下記Ｂ)
・登録ボタンをクリックで、画面項目の中身をアイテム内容テーブルにセットする(SetItem，SetItemDate)
・データのチェック(日付の整合性チェック等)(DataCheck)
・データを登録する(Write)
・インスタンスIDをUNLOCKする(XUnlock)
・システムのクローズ

共通処理
（Ａ）名前の前方一致検索、アイテム内容テーブルへの取り込み(登録の重複を避けるため、その名前で既に登録されているか調べる)、入力＝カナ名のアイテムコード、出力＝アイテム内容テーブル
内部処理
・今から登録しようとするものの名前をいれさせる。
・全クラスで名前の前方一致検索をする(GetClassKanaIdList)。
・一致したものを一覧表示する。
・同姓同名の場合もあるので、ボタンクリックで詳細(住所、生年月日など)を表示する(ReadWithItem)。
・一覧から選択する。
・そのインスタンスの全てのアイテムの内容を内部テーブル、インスタンスIDに入れる(Read)。

（Ｂ）コード化項目の内容表示し選択する。入力＝クラスのコード、内容の出力順(１:コード順、２:名前順)、内容(前方一致検索用)。出力＝内容のID、内容のコード、内容。
内部処理
・指定されたクラスに現在存在するインスタンスを取り出す(GetInstIdList)。
・コードと内容の一覧画面を表示する(ReadWithItem)。
・一覧から選択する。
・内容のID、内容のコード、内容をセットする。

SEは、仕様書で関数を指示することにより、記録と読み出しを具体的に決定することができる。しかし、これだけでは、SEの理解の程度により、それぞれ異なった指示がなされる可能性が残る。また、誤った指示が発生しても、そのチェックが困難であり、工数も増加する懸念が払拭できない。そのため、本情報処理装置では、さらに、入力様式定義体と出力様式定義体を使用することにより、実際の業務処理と、システム設計のつながりを、よりわかりやすくし、点検も容易にできるようにした。

図11を参照して入力様式定義体、出力様式定義体を説明する。まず入力様式定義体について説明する。当該処理の現実事象と入力事象は入力画面ごとに定義しておけば良い。例えば会員システムであれば、会員の入会登録画面（「発生」の「登録」）、会員情報の変更画面（「変化」の「登録」）退会登録画面（「消滅」の「登録」）をまず用意する。訂正では、どの記録を訂正するかを判定するための履歴画面を用意し、選択された記録の性格により、「発生」の「訂正」なのか、「変化」の「訂正」なのか、「消滅」時の「訂正」なのかにより処理方法を決定できる。削除でも訂正と同様の方法で、「発生」の「削除」なのか、「変化」の「削除」なのか、「消滅」の「削除」なのかが決定できる。会費の請求や入金など「変化」でしかあり得ないデータについては「登録」「訂正」「削除」の区分を画面に設けておけば、「変化」の「登録」なのか、「変化」の「訂正」なのか、「変化」の「削除」なのかは、区分によって判定できる。

入力定義体にどのクラスのどのアイテムを扱うかを定義することにより、その入力画面が使用されたとき、最初に主記憶内に展開するクラス、アイテムを特定できる。そのことにより、仕様書でいちいち指示しなくても、どのクラスに対してどの関数を使用して読み込みを行うか、その画面でどのクラスに対してどのような更新処理を行うかが、システムエンジンにより判定可能となり、自動的に決定される。

また、それぞれの入力画面で、アイテムの性格を記載することにより、入力画面ごとにより詳細なチェックも可能となる。例えば、小口現金出納帳入力画面では、振替伝票の入力画面より金額について小さい桁数を記入することにより、小口現金出納帳ではあり得ない金額の入力を防止できる。

出力定義体ファイルも入力定義体と同様、そこで使用されるクラス、アイテムを定義する。そのことにより、プログラマーは、抽出条件の入力と、出力の具体的デザインのみを行えばよい。

つまり、画面の判定とSEが設定する各種定義体により、各項目の存在チェックと一定の論理チェック及び更新記録の処理方法が、各プログラマーに依存することなく、システムエンジンにより一義的に決定できる。仕様書作成時点で、SEは各種定義体とその関連図を印刷することにより、簡単に処理方法を確認できるようになり、システム作成工数の削減と、プログラムミスの予防が可能となる。従来の方法では、仕様書通りに更新処理がされているかどうかは、プログラムのレビューでしか点検できなかった。本実施例の処理装置を使用すれば、仕様書の徹底的な点検さえ行えば、更新処理についてプログラムレベルでのミスは発生しない。また、システムエンジンは、あらゆる業務に使用されるため、繰返し点検され、バグの発見と訂正が集中的に行なわれる。SEは入力処理における論理チェックや処理手順のみを指示し、その点検だけを行えばよい。

また、これらの定義体は、プログラムの知識がなくても、業務に即して点検、検討できるように規定されている。むしろ、業務の知識を積み重ねることによって、定義体の規定方法を理解すれば、システムの基本部分がプログラミングに依存せず、構築できる。定義体は、それぞれの、国や地域の商慣習を始めとする、様々な文化を反映している。それぞれにあった定義体を用意することによって、世界中どこでも最も適したシステムを、システムエンジンを利用して、より簡単に構築できる。

次に、図12を参照して、情報処理装置について説明する。システムエンジン２は、ActiveXの形式である。具体的には、ボーランド社のデルファイを使用して記述されたプログラムである。Ｃ言語に変換した形式のプログラムでも可能である。画面ツールや出力ツールは、デルファイを利用する。データベースは、インターベースを利用する。システムエンジン２は汎用性が高く、アプリケーションプログラムへの負荷も限られたものであるので、他のデータベースへの移植も簡単に行える。定義体ファイル３に、各種の定義体を格納しておく。入出力装置１のキーボードや表示装置や通信装置などに入力された情報に基づき、システム外部とデータを交換し、アプリケーションプログラムの記述に従い、システムエンジン２が定義体ファイル３の定義に従ってログファイル４と記録ファイル５に、処理対象のデータを統一的に格納する。

システムエンジン２は、プロパティ定義体ファイルとアイテム定義体ファイルとセンタークラス定義体ファイルと履歴クラス定義体ファイルとキー定義体ファイルと入力画面定義体ファイルと出力定義体ファイルとを解析する。解析結果に基づいて、各定義体ファイルの内容を一般的な用語を使って出力する。

上記のように、本発明の実施例では、情報処理装置を、すべての業務処理におけるデータ記録構造を、１項目１レコードの「語」の集合である「文」という形式に統一し、システムに関するすべてのデータを、「記録ファイル」と「ログファイル」にのみ記録し、「定義体ファイル」の記述に従って、各項目の更新処理と読出しを統一的に行う構成としたので、データの共有とシステムの変更とプログラムの再利用が容易なシステムが、少ない工数と低コストで作成できる。

本発明の情報処理装置は、すべての業務処理に対して機能の拡張やデータの共有を簡単にできる情報処理装置として最適である。

本発明の実施例における情報処理装置で用いるログファイルと記録ファイルの構造の概要を示す表である。 現実事象と入力事象を説明する図である。 本発明の実施例における情報処理装置で実現される会計システムの概要を示す図と、ログファイルと記録ファイルの記述内容を示す表である。 本発明の実施例における情報処理装置で実現される会員システムのログファイルと記録ファイルの記述内容（現実事象）を示す表である。 本発明の実施例における情報処理装置で実現される会員システムのログファイルと記録ファイルの記述内容（入力事象）を示す表である。 システムがあるとした場合の関連図である。 システムとして見るという観点からの関連図である。 本発明の実施例における情報処理装置で実現される会員システムにおけるクラス・アイテム・プロパティ関連図と、クラス・アイテム・プロパティ定義体の表である。 本発明の実施例における情報処理装置で用いるログファイルと記録ファイルのキー構造とキー定義体を示す表である。 本発明の実施例における情報処理装置で用いる基本関数の表である。 本発明の実施例における情報処理装置で用いる入力様式定義体・出力様式定義体の表である。 本発明の実施例における情報処理装置で用いるシステムエンジンの位置付けを示す機能ブロック図である。

符号の説明

１・・・入出力装置、２・・・システムエンジン、３・・・定義体ファイル、４・・・ログファイル、５・・・記録ファイル。

Claims (4)

1. １つのシステムにおけるすべての業務処理の記録を保持する２つの物理的テーブルであるログファイルと記録ファイルとを有するデータベースと、すべての記録の更新処理を統一的に行う更新処理手段とを具備する情報処理装置であって、前記ログファイルは、すべての記録を入力順に保持するファイルであり、前記記録ファイルは、訂正される前のデータと削除されたデータを除いたすべての記録を入力順に保持するファイルであり、前記ファイルは、１レコード１項目の同一形式の語レコードの複数個からなる文により統一的に構成されており、前記更新処理手段は、前記文を１回の更新単位として更新処理を行う手段を備えることを特徴とする情報処理装置。
2. 前記更新処理手段は、３つの現実事象（発生と変化と消滅）と３つの入力処理（登録と訂正と削除）について、発生登録と発生訂正と発生削除と変化登録と変化訂正と変化削除と消滅登録と消滅訂正と消滅削除との９つの更新処理区分のいずれかにより、すべての記録の更新処理を行う手段を備えることを特徴とする請求項１記載の情報処理装置。
3. 前記更新処理手段は、システムの論理的な構造を規定するためにあらゆるシステムに共通する項目を登録するプロパティ定義体ファイルと、システムごとの項目を登録するアイテム定義体ファイルと、集計単位を示すセンタークラス定義体ファイルと、各センターファイルの具体的な記録内容を示す履歴クラス定義体ファイルと、センタークラス・履歴クラスの読出し順を示すキー定義体ファイルと、登録単位ごとの更新方法を定義する入力画面定義体ファイルと、出力帳票・画面の特徴に応じて読出方法を定義する出力定義体ファイルと、前記各定義体ファイルを参照して、前記ログファイルと前記記録ファイルのすべての項目の更新処理と読出し処理をアプリケーションプログラムに依存せずに統一的に行う手段とを備えることを特徴とする請求項１記載の情報処理装置。
4. 前記更新処理手段は、前記プロパティ定義体ファイルと前記アイテム定義体ファイルと前記センタークラス定義体ファイルと前記履歴クラス定義体ファイルと前記キー定義体ファイルと前記入力画面定義体ファイルと前記出力定義体ファイルとを解析する手段と、解析結果に基づいて前記各定義体ファイルの内容を一般的な用語を使って出力する手段とを備えることを特徴とする請求項３記載の情報処理装置。

Images