小特集･HITAC Mシリーズアプリケーション ∪.D.C.る81.322.022.0る7:る58.81

販売管理オンライン･データベース･システムシステム建設･維持/支援ソフトウェアの開発

Online Data Base SYStem for Sales Management

-g吉器恕諾冨nも溢髭サareforBui■dingandHITAC M-170,VOS2 ADMによるキヤノン株式会社版売管理オンライン･デ

ータベース･システムは,昭和52年5月以来,順調に稼動している｡販売管理シス

テムは,データ量の急速な増大とともにいっそう高度なサービスの提供が要請され,

加えて市場動向や販売政策の変更に際し,システムの即応が要求されてきた0 更に

システム拡大に比例してEDP部門の労力(とr)わけ維持のための労力)が増大する

とともに,生産性の低下を招いているのが現状である0 これらの問題解決の一方法

として,日立製作所が開発したADMの採用と和まって,本稿で述べる｢システム

建設,維持/支援ソフトウェア+にあると考えており,このソフトウエアは今回の新

システムの建設にも有効に働いたと確信している｡

口 緒 言

キヤノン株式会社では,これまでHITAC 8350システムと,

IBM370/135システムとを使用し,オンライン及びバッチ処

理による全社の販売管理を中心とした業務をElectronic

Data Processing(以下,EDPと略す)化してきた｡

今回,業務の拡張と事務量の増大などにより,HITAC M‾

170へのシステム移行を契機として,これらの業務を無理なく

短期間に移行するための方策を種々考えてきた｡-･九 今後

の｢システム開発の生産性+に対する考え方も転換しなけれ

ばならない時期にきていた｡キヤノン株式会社では,当初よ

り,EDP部門における生産性の向上を目指して,幾つかの

汎用のレポーティング･システムや情報検索システムなどを

開発してきた｡今回これを発展させ,より大きな視点から考

え出したものが,｢システム建設･維持/支援ソフトウェア+

である｡

このソフトウェアは,仕様書言語と,システム管理支援の

機能を具備し,日立製作所が開発したAdaptable Data

Manager(以下,ADMと略す)と相まって,大規模Data

Bas｡/Data C｡mmunication(以下,Dfi/DCと略す)システ

ムの建設及び椎持を容易にするものであr),これによりEDP

部門の生産管理｢開発･維持のトータル･システム化+への

布石を敷くことができた｡

臣l 販売管王里システムの概要

キヤノン株式会社は,昭和48年より販売業務のEDP化を進

めてきた｡昭和52年5月には,HITAC M-170,Virtual

Starage Operating System2(以下,VOS2と略す)

ADMでのシステム建設を完了し,その後順調に稼動し,次

期のシステム･ネットワークによる全社トータル･システム

ヘの基礎固めを果たしている｡

2.1VOS2 ADM導入の背景

VOS2は,仮想記憶方式により,システム開発,運用コス

トを最小にするとともに,システムの安全性,安定性が高め

られている｡

*

キヤノン株式会社事務菅野部第二課**

日立製作所ソフトウェア工場

本村昭二*

森 征市*

菅田邦彦*

黒沢真佐夫*

田村誠二**

〃0れm〟γα 5ん∂ノJ

〃or才 5f･g言cんi

5ぴgαJα 払れ～ゐ才ん0

付加rO5αぴα 〟αざαO

mm址γα 5e才ノよ

また,ADMは,大規模なDB/DCシステムの構築と維持

を可能にしている｡

従来の異機種2台のシステムでは,データの同期化が困難

であー),処理遅延の原因にもなっていた｡販売管理システム

の特性から,従来の処理方式では不十分であるなどの理由か

ら,昭和51年5月からVOS2 ADMの検討に入r),特に次

の諸点に着目してj采用するに至った｡

(1)トータル･スループットの向上

2台のシステムを統合するには,処理能力の高い大形シス

テムが必要であり,HITAC M-170,VOS2は仮想記憶方式の

環境下で多重処王翠が関られ,十分効果を発揮するものである0

(2)オンラインの安定運用

ADMによるオンラインシステムでは,部分閉塞,部分リ

ランが可能である｡すなわち,特定業務プログラムがダウン

しても関連するDBだけがストップし,オンラインシステム

ダウンという大きな事態には波及しない｡

(3)トラフィック増大への対応

ADMコントロールはマルチ･タスクであり,業務プログ

ラムもマルチ･プログラミングが可1弛である｡特に,VOS2

ADMでは,トラフィックに対応してパ∬ティションの設定

とプリロード機能を手采用することができる｡

なお,図1にハードウェアの構成を示す｡

2.2 システムの位置と適用業務

キヤノン株式会社での取扱い主製品である,カメラや事務

機器の製品特性は,付加価値が高く,かつ好みの変化や合理

化による技術革新など,製品の変遷も激しいものである0 ま

た,地方出先も相対的に小規模である｡

これらの要件から,販売システムの主なねらいは,次に述

べるとおりである｡

(1)情報の本社集中管理への要請

(2)データ収集スピード,精度の向上

(3)売上統計,売掛台帳,在庫台帳などのDB化と問合せ

(4)システム維持,変更への即応

33

628 日立評論 VOL･59 No.10(1977-10)

バイトマルチプレクサチャネル

セレクタ･

チャネルブロック･マルチプレクサ･

チャネル

【-8531-70

統合ディスク制御鼓構

H-F8092-10

プリンタ

H-8297-10

カートリーグ

H-8276-12

ライン･プリンタ

H-8276-12

ライン･プリンタ

H-8225-1

テープせん孔俊

汎用入出力制御装置

H-8622-1

通信制御処王里装置

l‾一l■‾l‾■端末設置箇所:約50箇所

端末台数:約†00台回線数:26回線

H-858g-11

ディスク駆動装置

【-8ヰ6β-†

韻気テープ差置

図lハードウェア構成 端末とLては,ビデオ･データ･ターミナル

約川0台のほかにTEJEX端末及び自動倉庫制御用のプロセス･コンピュータが

ある｡

｢‾‾‾‾‾■■‾‾-‾

l エ場システム｢‾■'‾‾‾‾-‾

l

l

l

l

l

+_

I l

l l

l l

ll

‡ l

I l

I 1

1 L_

--■+

-■一■+

PIGS

発注管理 在庫管玉里

販売管理システム

入庫処理

娠替処理

出庫処‡里

掴内売上入金管現)

･受注処理

サービス部品倉庫

在庫管理 (国内売上入金管理)

入庫処理振替処理

出庫処理

受注処理

売上処理売掛入金処理

COSMIS

発注管理 在庫管理 売上入金管壬里

･仕入処理 入庫処理

回送処理

出庫処理

受注処理

売上処理

入金処王里

代王里店

(5)物流管理への情報管理サイドからのバックアップ

(6)本社,輸出,キヤノン販売株式会社システムの統合

図2に,販売管理システムの位置づけ及び相互関連と処理

概要を示す｡

また,昭和52年には,従来のシステムから新システムへの

切替を実施した(図3参照)｡

この,新システム開発の課題として,

(1)ハードウェアの統合(HITAC8350,IBM370/135→

HITAC 叩-170)

(2)OS(Operating System)の統合〔EDOS-MSO(Ext｡｡d_

ed Disk Operati咽 System-MultiStage Operations),

DOS/VS(Disk Operating System/VertualStorage)→

VOS2〕

(3)DBMS(Data fiase Management System)の統合

〔PDM(PracticalData Management)＋CICS(Custom｡r

Info･nation ControISystem)＋DL/1(Data Language/

1)→ADM DB/DC〕

(4)大規模DB/DCシステムの建設

(5)短期建設(約10箇月)

(6)アーキテクチャの異なるビデオ･データ･ターミナルの

HITAC M-170への接続

(7)テレックスのHITAC M-170への接続

(8)自動倉庫用プロセス･コンビュ【タのHITAC M-170へ

の接続

などがあった｡

2.3 開発,維持のシステム化への要請

これら,システム移行及び,ADMによる新システムの開

発を,

(1)短期軌 ′ト工数で実現し,加えて,今後のシステム維持

の面から,(2)環境整備とシステム資源の動的管理,(3)仕

EISOC

一一

｢+-

く物涜管理〉

大オーダー倉庫

(商品倉庫)

中央倉庫(大森)

取手

大阪

営業所商品セン

ター(三郎

得意先

キヤノン株式会社l___.__

_...+

FICS

‾‾■-｢

トータル･ギャランティ管理

TG売上処理･入金処理

消耗品売上処理･機番管理

請求処理

=+

キヤノン販売株式会社

図2 販売管理システムの位置付けと概要 キヤノン株式会社とキヤノン販売株式会社の五つのサブ.

システムから構成され,相互の関連及び工場システムとのつながりを図示Lた｡

34

複写穂ユーザー

輸送手段

海外販売会社

注:略字説明PIGS=Pa｢tsIn〉e〔tO｢Y

GardSystem

COLTS=CanonOn-Li〔e

†打TD払】お】e5

COSMIS=Cano【0∩一Llne

鮎Ies他〔ageme〔l

In†肝mal仰System

EISOC=Expo｢tI【fo｢mat10n

System o一曲〔On

FICS=Fuk]S旭kjI【brmat10n

Con打OISystem

得土居先

販売管理オンライン･データベース･システム 829

IBM 370-135

TEX

TEX

10台

製品倉庫

サービス部品倉庫

DOS′′ノVS

COLTS

PIGS

COSMIS

COJTS

DB

PIGS

DB

COSM工S

DB

HITAC 8350

EDOS′′■′MSO

EISOC

PIGS

FICS

EISOC

DB

PIGS

DB

FICS

DB

HITAC M-170

VOS2..′/ADM

注:略字ほか説明

DLノ/1=ロataLa[g]age/1

COLTS=Ca〔OnOn一しi[e†or TotalSales

PIGS二ParlsI[〉e[tryGaTdSystem

COSMIS=Ca[0〔On-しi【eSales

Ma【agementInformation

SYStem

EISOC=Expo｢tI[†0｢matio【

Sッstemof Cano[

FICS=F]k]Shak弓Ⅰ〔format10〔

ControISystem

Oは捌.すタ

●は再掛橋システムれ本

プログラム本数

TE)(

TEX

自動倉庫

10台

ミニコンビュータ

匂ヒ○190本

220本

330本

160本100台,26L

キヤノン株式会社

統合DB

キヤノン販売株式会社

統合DB

30DB

20DB

環 境 条 件

システム移行の大規模,短期間,少要員

プログラムとドキュメント

の遊離

各種ADM定義と

70ログラムの一体化

DB./DC利用環境の整備

業務処理プログラムの多様性

販売情報システムの特性

機 能 要 件

プログラムの簡便化,

EU+指向

プログラム仕様書=

プログラム,二重投資の除去

作業の一体化,一元管理

ロジカルなイメージによる定義作業の簡略化

処‡里形態のパターン化

システム組替えの柔軟性

注:EUL=エンドユーザーランゲージ

図4 システム建設･維持/支援ソフトウェアの必要性 スムー

ズなシステム移行を実現L,かつ今後の維持面での課題を一挙に解決する手段

とLて,｢システム建設･維持/支援ソフトウェア+の開発を決心した0

図3 システム移行の概要

再設計対象は全システムに及んで

おり,DB/DC関連プログラム約

600本は,仕様書言語に基づき開発

Lた｡

様吉とプログラムとの-一体化,(4)プログラムとデータ･ベ

ース/ファイルとの同期化,一元管理などの諸点から考察を重

ねた(図4参照)｡

なかでも,販売管理システムの特性として,市場動向や販

売政策の変更に対して,システム自体も変化することが顕著

である｡ニれら変化する主-ズに即応して,システムの組替

えを来秋に行なえる道具をトータル･システムとして準備し

ておくことは,特に販売管理システムを支えるうえで不可欠

であった｡

ニれら販売管理システムでの｢開発･維持のトータル･シ

ステム化+を出発点として,EDP部門における生産性向-.L

という枯年の課題の解i央を目指して組み立てられたものが,

｢システム建設,維持/支桜ソフトウェア+である｡

田 システム建設,維持/支援ソフトウェアの概要

これまでもキヤノン株式会社は,EDP部門での開発,維

持のシステム化に取り組んできたが,今回,DIi/DCとして

高度な機能を備えたADMを採用し,よりいっそう具現化が

容易となった｡

3.1開発の基本的な考え方

システム建設･維持のシステム化を実現することは,単に

HITAC M-170システムによる販売管理システムの建設に際

し,生産性を向上させることだけにとどまらない｡今後のE

DP部門の生産管理という点から分析してみると,主に次の

阻害要因があったが,ニれらの要因を除去することにつながる0

35

830 日立評論 VO+.59 No.10(t977-10)

-

｢■■-一

‾---■--■---､､

仕 様 書 言 語

プログラム･テスト‥サポート

･TESTデータ･ジェネレータ

･TEST結果チェック

･トレース･′シミュレータなど､

､

ヽ

､

ヽ-

システム設計サポート

･DBデザイン･エイド

･プロジェクト管理

管理DB支援

･リモート サービス

･管理DBメインテナンス

･管王里DB問合せ

L____________′

プログラム実行サポート

･汎用情報検索

･汎用lノポーティングなど

図5 システム建設･維持/支援ソフトウェアの考え方 開発･維持のトタル･システム化の第一

ステップとして･今回実現した範囲を示すbシステム設計,運用のサポートが次のステップである｡

■一

-+■

‥還

システム運用サポート

･スケジューラー及びチェッカー機能

･オペレーション指示

･リラン処理指示

【:コ内は,今回実現部分を示す｡l

脚自･' ワぎ王折EⅥ岳■■i

l l l l

仕様書言語コンパイラ

斤

管理DB支援

レポート

オンライン

リモート･サービス

B

デバッグ支援

･データ

ユーティリティ

構文解

レ

画面, 管理

ム

テスレポート編集ドライバ

D呂′/DCアクセス

サポート機能

丁ソソヨンテープノ

サポート機能

DB,レイアウト管理

仕様書管理

ADM定義

ジェネレータ

メインテナンス

ジョブストリー実行

管王里DB問合せ

ジェネレータ

トレース

シミュレータ

システム管王里資料作成

汎用処理ルーチン

図6 ソフトウェア体系 基本的な機能構造を示す｡オンライン･リモートサービスにはTSS(T.me

Shar山g Syslem),RJE(RemoteJob Entry)的な機能も具備Lている｡

(1)規模の拡大に伴い,開発･維持(とりわけ維持)の労力増

大が生産性を阻害している｡

(2)設計者の資質に依存した開発は,EDP部門では多種多様

なシステムの集合となり,全体としてのバランスがとれなく,

トータル･システムの弊害となる｡

(3)ユーザー側の利用意識が向上し,EDP部門に対する要求

が非常に複雑化かつ高度化してきた｡

(4)os機能の拡張や各種パッケージの採用などにより,E

DP要員に要求される知識が量的に増加し,また質的にも高

度化している｡

これらに対応して,当システムの開発の基本的な考え方と

しては,第一に生産性の向上,第二にシステムの平準化,第

三にユーザーの参画,第四に新技術の即利用体制などに集約

される｡したがって,このような展望をもちつつ,まず当面

の範囲(図5参照)を考え,そこに至るまでの技術と経験の蓄

積のうえに立って次の段階へ進むことにした｡

3.2 ソフトウェア体系と弓幾能

求められた要件を満たすため,図6に示すようなソフトウ

36

ェア体系をもつ｡本ソフトウェアは仕様書言語コンパイラ,

管理DB支援,オンライン･リモート･サービス,デバック

支援,及びサポート･ユーティ りティの五つから構成されて

いる｡

それぞれの概略機能は次に述べるとおりである｡

(1)仕様書言語コンパイラ

日本語文で讃=かれた処理仕様案を解析し,COBOLソース

プログラムをジュネレートする(図7参照)｡

(2)管理DB支援

仕様書DB(仕様書のライブラリ),DB定義DB(DB構造,

DBセグメントの定義ライブラリ),画面レポート定義DIi

(端末画面の定義ライブラリ)などのDBに登録,更新削除を

行なう((1),(2)の関連は図7参照)｡

(3)オンライン･リモート･サービス

オンライン･リモートによる管理DBの問合せと上記(1),

(2)の処理を行なう｡更に端末からの指示に基づき種々のジョ

ブストリームの実行及び端末からの要求により,実行結果の

耳丈り出しを行なう(図8参照)｡

販売管理オンライン･データベース･システム 831

仕様書

本IZZMOO.1_ウ_リアゲウリアゲガメントクイサキマスタ

不云1d.素早呂文 アゲ

仕様書DB

DB構造･各種レイウト･定義

×Xトクイサキマスタ××

[葺等コ

DB定義DB

画面･リスト定義

A XXウリアゲガメン××

Bトクイサキコード唾×

C コー

画面

レポートDB

コンパイル及びリンケージ

ロード

モジュール

業務DB

ユーザープログラムの実 行

ADM

コントロール

ステートメント

プログラム定義

ユーティりテイ

ADM@PAS

コントロール

ステートメント

データ･ペース定義

ユーティリティ

ADM@･DBD

コントロール

ステートメント

メッセージ･フォーマット

定義ユーティリティ

ADM@MFD

図7 ソフトウェア概念図 管ま里対象DBは,仕様書記述DB,DB定義記述DB,画面ルポ‾ト記述

DBの他にも仕様書記述エラーを管理L.問合せに供するERROR情報管理DBがある0

業務選択画面

処理選択画面

入力画面

出力画面

処理選択画面出力

リンカー

画面レポートロBメインテナンス

DB定義DBメインテナンス

‾一‾‾●‾1

1

ク

画面レポートDB表示

DB定義･DB表示

仕様書DB

ディレクトリ表示

｢‾‾‾‾‾‾‾‾

ジ]7･ジッコウ指命

コン′りル･カタログ

コンパイル

エラー表示

⊥/

コンパイル･カタログ処理

メッセージ･フォーマット

プログラム定義

ジェネレーション

メッセージ･キュー

‾‾▼

開発維持

ライブラリ

/

りシーケンス処理

リネーム処理

リコピー処玉里

/

′

仕様書言語

エラー情報管理DB

′リーダ起動

サポート

′

′

′

ジョブ

ストリーム

ライブラリ

′

′

/′

′入力

ジョブキュー

′′

ノジョブ･ストリームー

オートジェネレータ

仕様書言語

コンパイラ

lJ

J

■‾‾‾‾▲‾■1

一一--11

COBOL

コンパイラ

t+ンケージ

ll

ll

ト+

J

各種ジョブ･ストリノームり〈ターン

仕様書語

/くラメ一夕など

+OBLIB

図8 オンライン･リモート･サービスの概要 オンライン･プログラム約30本から構成され,開発

言語は,仕様書言語を全面的に採用Lている｡

37

832 日立評論 VOL.59 No.10(1977-10)

(4)デバッグ支援

テスト結果を容易に解析できるように,トレ【ス機能やDB,

端末への入出力データのシミュレーション･ツールを組み込

むことが可能であり,その結果を編集,出力する｡

(5)ユーティリティ

管理資料(例えば,あるDBを使用している仕様書の一覧表

などの相互関連など)の作成やDBを維持していくのに必要な

各穐モジュールを備えている｡

これらの機能は,それぞれ独立したものではなく関連をも

ち,有機的に処理されるものである｡

3.3 技術的特徴と考慮点

仕様書言語の開発には,日本文の文型及び冗長度などによ

り,機械による解析は非常に困難なものである｡また,シス

テム規模の増大に対して,標準化,ドキュメント化や一部の

汎用化などという小手先の対処では解決できなくなっている｡

これらに閲し,次に述べるような工夫をして第一段階のもの

を完成させた｡

(1)仕様書言語とプリコンパイラ

図9の例に示すように,日本文による｢仕様書=プログラ

ム+の仕様書言語を開発した｡ニれによりドキュメントの一

書♯--●

****-

サー*一*↑↑*

書

↑↑-SCAE*

↑↑↑*S亡n白RRE♯

†T*SCA

㌫椚m8｡｡批0｡｡㌶諾温慧仰濫認器仙濫仙m認諾Ⅶ琵㌶諾刑…7｡｡m諾㌶M仰MMm脚認諾m㌶…7D｡…Mm㌶M㈹諾欄㌫m㌫諾50｡∽諾MM㌫mmm肌仙恥㌫弧批m8｡5椚m椚0｡5mO｡Smmぬ㌫諾㌫0｡60口6m貼附DD7Ⅳ8｡70D70｡7抑抑㌫M㌫m㌶0｡8m㌫mMm椚㌫椚㌫0｡9MM…Dl｡Mロl｡MMOl｡MOllロ11ロ･1mmOllmmmO3耶030303諾03諾03諾詣諾宗03耶耶03耶∽誤記∽附耶03耶凹氾∽宗田耶03∽0303∽叩氾琵83耶ロコ83030383監03諾耶宗諾0303琵0303諾ロコ03凹030303耶03貼附

′′′′′′ノ′′′′′′′′JJJ′′′J′′J′′′JノJJノ′ノ′′′′′′′′′′′J′J′′ノJ′′J′JJ′′′′′ノ′′′′′′′′′′′//′′′//ノ/

2222222222222222222222222222222222222222222222222222222222222222222222222222222222222

111111111111111111111111111111111111111111111111ュ111111111111111111111111111111111111

′′′′′′′′′′′′′ノ′′J′′′′′J′′′J′J′′′′′JJ′′′ノ′′′メイJJ′′JJ′′JJ′′′′J′ナナJ′′′′J′′ノ′ノ′′′′′′′////

68666666666666666E66G6ら6668`も868886g866GG56666666686666886G86ち6666G6E66ち666666666Eら66

777777777丁77777777丁77777777777丁777777777777777777777777777777?777777777777777ナナ7777丁7

GSP符 丁 ワリ?- 丘 ショリ ⊃-ト小 事エ･叩

CIJ白れ小メン ズ ウケlル.

書サJナう ♯g へ イり.-

LロU-∨白しUEJ Cl伯力小〆ン ヽ ウ･リス.

Cu白か､メン J ヨム.

∂AVCHK(Cu‡け)､､ブントCL穴.Cu肋､､ノントPFI(､●1)丁 子ン乃イズl.

■1-1.

エラー .‥ Cun刀小ノン8一三RR.

ショリコート小:CIJRか～ノン 宇?ナうl亡卜PC甘 才 ▼､､ミー1へ サリス

勺､､ミー2 才 9小ミー3 へ ウッズ

メーツt-シIlロ17 エラー へ ケリス

? へ イワ

112!3!色

!▼E'!,L,!,Ml!I

y!

!X!

!X

!●3!書血!書5

苛RVEND(N80,メリt-シ{oD)一 号ン¶イ 71i.

●1 へ イウ.

コモン エ】j7 ノ ナイヨウ オ ヒョウシ小 スル

RV6SP【) 一 日u テ･､ヨん.

白Vt;SP〔IJ ごいゎか､ノン へ り､･ルーフ●イい､り 加,

'TXXIXXXXXX' 才 ●1一之り-い､王C-】A¶､､メン へ ウリス.

牛､､ヨウんブラり小!角VGSPロ書手小ヨウら｢ラワ､l…Cu向力､､メンへサツス.

CuRか､ノン 丁 ¶ワ.

♯1 ヽ イり.

エラー

Lロー

ワ､､ミ"8 NロT 一;ハ●スつ一い､三CりRヤ小メシ ナう

AV6SPO オ

ーム一口.

Il●71

11●ス2 .

】1●又1云

Il●ス1 1

一色-l.

つ弓り小l.‥

つうっ､､2 ‥.

ブラつ､､ヱ...

メ■ワモーシ､､D2 チ エうlヽ ウ･リコ

書5 ･l イウ.

6HU 予､､ヨム.

サマリー■＼◆スり-い､ミCu抑･､メン.

ワマリー11一三り-い､;RV6SP【】.

1121

し8u ナラ !Y!Nl

l＼●ス2 ヘ ウーリズ ! !X†

システム7うつ､､王Cl】月力小メン,

シズ子ムー与り､＼三内VGSIコ0.

⊃刊し7ラワ1-:RVGSP【Ⅰ,

f‥;…;

1!2!さ†A】

7うワ小l = ? ナ与 ■しOu†tY･!･N･l

｢うっ小l T 7うり小2 ヽウ･リア! -Y!1!

コヽ●‾Z 一 っ弓ワ"3 へ り･リス! !X,

〆りトシ小D3 Jエうー へサリヨ !X t●5 へ イ7

!X】

■7

■+7

,7

｢一

24▲I

サンマり7うり小一Cl】∩わ小メン.

▼ンマ■りつ号つl､.】舟VGSPO.

38

体化を実現L,システムの維持を容易にすることができた｡

(a)文法の設定と構文解析

日本語の表現は,多稚多様で記述者の個性に強く作用さ

れるものがある｡そのため,仕様書を記述する必要最小限

の機能語を洗い出し,それらを文法の体系に整備し,簡単

で正確,客観性のあるものにした｡また,日本語文は,一般

に動詞が最後にあり,文の最後になって初めてその文の解

析が始まる｡したがって,日本語文を｢AN記法+(ALGOL

Nの構文を解析するのに考案された技法で,使用する言語

を記号化して解析する)を用いて構文解析し,正確を期す

と共に,プリコンパイラに全く新しいテーブル･ドライバ

技法(構文のチェック及び解析の一手法)を採用し,構造化

をl当るとともに拡張性を高めた｡

(b)デシジョン･テーブル記述上の制約緩和

デシジョン･テーブルは,仕様書のロジックを全体的に

見ることができ,仕様書の冗長性,不明確性を防止するう

えで有効な手段である｡これまでに開発されてし-るデシジ

ョン●テ‾ブル･プロセッサの不具合事項を解決し,簡略

化,列の制御及びテーブル内に再定義項目を導入すること

に成功した(図川参照)｡

以下 アロセデーア鉢

…CORA⊥ キクp命令

…不定書

]

ーう,､､1.?ナ,

.し占ぃ;,….…,≡､;且!,｢うり､'1 オ ーっり､､2 ヽ ウワス †X!X†

図9 仕様書言語例 仕様

書言語で記述されたオンライン･

プログラムの例を示す｡COBO+

プログラムに比較し,約÷のステ

ップである｡

プレジーy･テーブル

]帆ソト

‥▲DM DB/℃C C▲LLに対応

ソース ステートメント

ロ 1 2 :; 血 5 6 7

7〔…g□1234567∈き90.12:;45678ヨD123血56789D1234567∈∋日日i2:;ム567日ヨロ1234567白きD12

C 子中一っ已 ? ナラ

*

C サ､､イコ コ '831' ナう

ヰ:

角 ? = ? * スウ オ サイサン スル

*

白 コウ苧 芦 コウ宇 ヰ スウ オ サイサン スル

*

八 つ = ワ / スウ オ サイサン スル

E lヒ､l一千

▼1【)▼ 12ロI I38■

N V N

コウナイ !ユシ1,リ !コワナイ6

r

コワナイ白!1シ1■り爪!コワナイH

2 3

匡ItO デシジョン･テーブル例 デシジョン･テーブルは,基本形

(条件行での-Y,,■N',行動行での-×'記述)の他,拡張形とLて挿入制御や列へ

の飛び先制御などの広範な機能を備えている｡

(c)DB/DCアクセスの汎用化

通常のオンライン･バッチプログラムにおいて,その人

出力部分はほとんど類似しており,幾つかにパターン化が

できる｡そこで,Dfi/DCのアクセスについて個々のプロ

グラムでは,構成項目の設計･登録のみでシステムとして

完成することを目指している｡例えば,DB及びDCに対

するアクセスと,それに関連するステータス･チェックな

どを自動的に組み込み,仕様書プログラムの単純化を図り,

設計者の負担を軽i成させるようにした｡

(2)システム･リソースの集中一元管至里

これは,DD/DS(Data Dictionary/Directory Sys-

tem)の概念である｡仕様書プログラムDB,セグメント･

フィールド,入出力アイテムなどの一元管理を目的として,

機1城によるシステム･リソースの制御を行なおうとするもの

である｡

(a)DB構造,画面,レポMトなどのレイアウト類の記述

販売管理オンライン･データベース･システム 833

作業(設計作業そのもの)の結果を動的に活用するため,直

接,イメージ･フォーマットで登録,参照できるようにし

ている(図11,12参照)｡

(b)各種ADM定義(DB定義,プログラム定義,画面定義

など)のパラメータをジュネレートし,実行させる｡

(c)DBと仕様書,DI∋とセグメントタイプなどの相互関

連の問合せや,プリント出力が可能であり,仕様書やアイ

テムの修正,追加による影響が一目で分かるように配慮さ

れている｡

(d)また,単に管理にとどまらず,実行面においても動的

に利用可能なように,例えば,一つのデータ･フィールドの

登録,変更は直ちにすべての連絡をたどって変更し,シス

テム内部の処理態様の変更をも完了するように考えている｡

(3)運用上の効率向上の施策

オンライン･リモート･サービス(図8参照),デバッグ支

援のツ【ルの開発,コンパイラ回転率の向上などの運用上の

効率向上の仕j卦けを行なっている｡

特にデバ､ソグ支援では,日立製作所提供のATS(Application

Program Testing System)とりンクさせることにより,プ

ログラムで異常が発生したとき,仕様書上の位置やメモリ,

DB/DC,ファイルなどの状況が答易に分かるように配慮さ

れている｡

【】 結 言

キヤノン株式会社の販売管手堅システムは,販売オペレMシ

ョナル･レベルでのトータル･システムの-一環である｡HITAC

M-170,VOS2 ADMによる新システムの建設を短期間に行

なったが,販売システムの特性により,システムの組替えが

頻繁に発生する｡これまで,システム拡大に比例して維持す

る労力も増大し,EDP部門の生産低下の一要因となr),新

システムの開発を阻害してきた｡

このようなこ快音兄から,システム建設･推持/支援ソフトウエ

アの開発は,EDP部門の生産性を上げ,今後の販売システ

ムの改変にも柔軟に対J芯できると確信している｡

8E Q. D B 名 心 力 特 称 蕪成法 偶

S E Q デ ー タ･ ペ ー ス 耕 連 1Ⅰ)苫NT

セタメソト名(〟-ト)

セタメソト名

親セタメソト名

セタメγ.†名 セタメソト名

)(

セタメソト名

セタメソト名 セタメ:′一名

セグメント名

セグメント名 セダメソ一名

(備 考)

軌ゼ7ツ)ltこ商品ヤヌスヨkタンントに茂泉予定′輸出マスタ 図Ilデータ･ベース定義

登蕃景例 簡明なイメージでフ

ォーマッティングされた用紙上に

図示表現Lたものが登重責の入力と

なる｡

39

834 日立評論 VOL.59 No.10=97ト】0)

M A P レイ7ウト定義書

穿MAp餓 SPA COPY名称 山人P 略称名 トタンザクレ,ソ1Ⅰ〉 備 考

詑刃

で;;窒丁㌶禁二孟¢伽キープ一-ルド乃(慧芸二三)

蓋譲葉主L他姓L捜し二止

二[m二亡□工工匪巨巨匝[]こコ:亡匪細萱ココ工紐コユ工雛匝Ⅰ]コニ工鉦Ⅰ至1東口二工

班Ⅰ亘匝[こ[コニニ

匪巨Ⅰ虻]二二[]二二抑東口工工獅1‾T｢｢

軋2担艮此旦Ll⊥⊥

抑圧[二Ⅲ工獅二Ⅲ工弧Ⅱ工垂匡回頭亙[Ⅲ二[弧亘□:コニ

雛珂正Ⅲ工蜘Ⅰ二[Ⅱ二晰二Ⅱ工匪【至E至耳二□]二組コニⅠ工晰ロコニ亡酢同前両T｢｢T

飽氾継凶逃出凶逃出凰迎濫区[エロⅧ工□嘲エコ嘲Ⅱ□嘲エロ卿紅⊂□珊麺Ⅱ口

蓋監慧慧琵琶冠丑恥エロ晰市岡郡師岡肺｢｢∩

雌企迦凶

匡□嘲些且ヱ1旦止1旦椰

些Lむ軋び竣

重圧回頭空獅

旺二画巫区区

虹嘲†古rん脚満更振幅X.1Xlメ壬米主剤X!X事X】×】X王×

ぴゼ+月旦

妻空匝王至示丁打椰

捌盤痢m

×【XMXlXぎ× XIXⅨtX】×粗ゼLU⊥⊥1+型

m皿瑚二]ココニ]工Ⅲ工m

⊥⊥⊥+__他姓L⊥

皿皿変:匪左迩丞コ王[二固妻m｢1ヨ協

デlタ】71デ5ク×lXlX事刈X∃X

また,今回の新システムの建設に本ソフトウェアを使用し,

従来のシステム建設よりも非常に生産性が上がっており,定

性的にもシステム管理の効果が上がっていると考えている｡

今後,二のソフトウェアは,DD/DSの機能,DBA(Data

Base Administrator)の機能,リモート･サービス機能を

充実させるとともに,仕様書即プログラムの簡便化と処理効

川川蝉]文論

図12 画面定義登金蔓例

画面レイアウトの記述作業(設計

作業そのもの)の結果を動的に活

用するため.直接イメージ･フォ

ーマットで至言緑,参照できるよう

にエ夫Lている∩

率-システムの最適化-を目指して改良を進め,更にEDP部

門以外の利用(ユーザーによる利用)を図っていく考えである｡

終わりに,販売管理システムの建設及びこのソフトウェア

の開発に当たって,関係各位から御技月力をいただいたことに

対し深謝の意を表わす次第である｡

戯空夢H≡琵琵琴

データ･テざィクショナリ/ディレクトリの動向

日立製作所 酒井博敬

情報処理18-5,491(昭52-5)

データ･ディクショナリ/ディ レクトリ

(DD/D)はメタデータを蓄積したデータ

ベースである｡メタテ■-タとは,データの

属性に関するデータの意味で,データの名

前,表現,構造,所在及び使い方,更に,

データの意味,発生源,収集責任者,使用

権,有効期限などを指す｡そして,メタデ

ータを管二哩するシステムがDD/Dシステム

である｡

DD/Dシステムは,情報システム,特に

データベース システムにおける運用管理手

段として要請され,体系化が進められてき

た｡

データ･ディクショナリとは,データの

ソース定義ライブラリであり,ユーザ【に

よるメタデ【タ管理の便宜を目標としたも

のである｡一一方,データ･ディレクトリは,

ディクショナリ中の計算機で必要とする情

報を機械コードに変換し,データの物理的

な所在場所やアクセス制御情報を付加した,

データのオブジュクト定義ライブラリである｡

DD/Dシステムの目標には,ソース及び

オブジェクト定義の収集,生成,提供並び

にデータの命名法,使用法,符号化などに

関する標準化という二つの側面がある｡更

に,メタデータ管理の完全性を期するため

には,DD/Dは情報システムのすべての要

素に関するノ去範な定義情報を含んでいる必

要がある｡すなわち,デ【タだけではなく,

70ロセス,トランザクション,レポート,

発生i凰ドキュメント,ユーザーなどの実

体を対象として､二れらの実体が本来もっ

てし､る属性,及びその環境要素との関係に

よって定まる属性のすべてが,DD/Dに蓄

積されねばならない｡二れらの実体に関す

るメタデ【タの論理構造は有方向グラフと

して表現され,またその実現値の集合をデ

ータベースとLて編成し,維持することができる｡

現在,データベース システムのユーザー

向けに提供されている幾つかのDD/Dシス

テム ソフトウェアには,データに関する広

範な定義づけ,データの矛盾性と冗良性の

検知,メタヂ【タの版制御,システム要素

関係の相互参照,メタデータに対する問合

わせ応答,標準ドキュメンテーションの生

成,データベース管理システムあるいは言

語プロセッサに対するデータ定義ステート

メントの自動生成,メタデータの安全性と

完全性の維持などの機能が含まれている｡

メタデータの集中制御という目的からす

れば,DD/Dは,オペレーティング シス

テム.データベ▼ス管至里システム,コミュ

ニケーション モニタ,言語プロセッサなど

の共通な定義情報源として利用されるべき

である｡しかし,現実のDD/Dシステムで

は,DD/Dの管理及びユーザーを含むシス

テム諸成分とのインタフェースに関して独

自の機能が設けられている｡将来のデータ

ベース管理システムの目標は,DD/D管理

機能の統合に焦点が置かれている｡

40