ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

●難しい概念・・・でもない

皆さん、排他制御ってご存じですかー？
これって、基本的な概念なんですが、普段の生活では耳慣れませんよね
でも、皆さんは自然にやっちゃってるんですよ

それを小難しい言葉にすると排他制御って呼んでいます

どんな時に使っているかって言うと
貴方が上司から何か仕事を言いつけられている時に
部下が電話してきて、あーだこーだ言い始めた時に

「ごめん、ちょっと後にして」って言って
上司からの指示が終わったら、その部下に電話して
「ごめん、さっきの電話はなんだったかな？」って

こんなことって良くありますよね(笑)
排他の他はこの場合は部下をさしますね。
上司の指示を受けている時は部下を排除しています

そして、上司の指示が終わったら部下に何だったって聞き返すのが
制御にあたるわけですよね。

●データベース管理には必須

この排他制御、データベースの世界では必須なんです
だって、これが無かったらとっても困っちゃうんです

たとえば、あなたがある通販サイトで、超レアなグッズを見つけたとします。
金額が金額だけに、カートに追加を押したのはいいけれど
悩んでいるうちに・・・他の人が既に購入していた

そんな事あったら悲しいでしょ(笑)

なので、通販サイトとしては、あなたが購入しようとその商品をカートに入れたら
一定時間は他の人が購入できないようにブロック（排他）するんです
ただ、あなたが１年も２年も悩んだら通販サイト側が困るので
一定時間後にあなたの為のブロックを解除します。

でも、データベースの排他制御の方は最後の他の人に不都合なようになります。
それは、あなたの処理を完了させることを第一に考えるからです
これは、業務システムだけでなく、様々な処理で必要な事です

なので、データベース方式の排他制御を通販サイトで行った場合
�@あなたが、レア商品をカートに入れ、どこかに旅行に行ってしまう
�A別の人が、同じ商品をカートに入れようとしても、入れられない
�B別の人に、一定時間（例えば５分とか、１０分とか）その商品が既に他の人がカートに入れているのであなたには売れないと通知が来る
�C別の人が、再度同じことをするけど、何度もメッセージが来る
�D別の人は、業を煮やしてサイト管理者にクレームを言う
�Eサイト管理者は、あなたのカートから商品を削除して開放する

●当社のは簡単

当社の場合、データベースが一か所なのでこのような排他制御はＯＳがやってくれます
あっ！　ＩＢＭ　ＡＳ／４００はＯＳがＲＤＢ機能を装備しているので

なので、チョー簡単です。
それに比べ

●親会社のは複雑すぎ

システムが多数存在し、それぞれがデータベースを装備しています
そして、システム間でファイルでやり取りします
当然、システムが別であれば排他制御データベースエンジンはやってくれません

今日も、その問題をどうしようかと悩んでいる会議でした
でも、あーだこーだ言いながら本質には全然近づきません

多分、一生やっていることでしょう
あ〜あ

●そういえば・・・過去にも

2021年4月にも、排他制御について記事を投稿したことがありました。
ブログ記事：排他制御は難しいかも
ブログ記事：排他制御は難しいかも・・・ Part 2

こんばんわ
データベースを利用しない人はほぼいない現在
データベースが何かわからない人はほとんどいないでしょう

でも、排他制御というデータベースにとって、入力・検索・出力と並んで非常に重要な機能があります
入力や出力、検索は皆さん、だれもがお目にかかる機能ですよね
会社の業務でもよく使う機能です

でも、排他制御は
説明できる方はあまりいないのではないでしょうか

排他制御とは、データベース更新において正しく更新できることを保証する機能です
えっ　なんのこっちゃって
でしょうね〜〜〜
これは、もう縁の下の力持ちの機能ですから。

表立っては出てきませんね。
たま〜〜〜に、んっって思うことがあるとき、働いている機能ですからね(^_-)-☆

皆さんが、データベースに何らかの入力をするとき
入力した値がデータベースにきちんと格納されることを疑うことはないですよね
さっき、『１』って入ってるのを『２』に入力したのに、そのあとデータを見たら『１』のままだったら
そんなデータベース使いたくないですよね。

このような現象が発生しないようにする機能が『排他制御』なんです。

このような機能が働かない場合って、やっぱりそうそうあるもんなんですよ

例えば・・・・
サーバーにＡというファイルがありました。
�@太郎さんは、サーバーからＡというファイルを自分のＰＣにコピーして、それを開いて、『私は太郎です。』って入力しました。
�A次郎さんは、サーバーからＡというファイルを自分のＰＣにコピーして、それを開いて、『私は次郎です。』って入力しました。
�B太郎さんは、ファイルを保存し、自分のパソコンからサーバーに書き戻しました。
�C次郎さんは、ファイルを保存し、自分のパソコンからサーバーに書き戻しました。

さて、サーバー上のファイルＡにはなんと入力されているでしょう？

太郎さんに聞きました。　太郎さんは『私は太郎です。』って入力されていますよって答えます。
次郎さんに聞きました。　次郎さんは『私は次郎です。』って入力されていますよって答えます。

どちらが正しいでしょうか？
二人とも大真面目に答えていますが、太郎さんは実際にファイルＡを開くと、『私は次郎です。』って入力されているのを見て愕然とするでしょう。
まるでキツネに化かされているみたいに



さっき、太郎さんは『私は太郎です。』と入力したファイルＡ（のコピー）をサーバーに書き戻したのに・・・

そうですよね。そのあとに次郎さんが上書きしてしまっているからですよね。

このように排他制御がかかっていないと、太郎さんの努力が無駄になっちゃいますよね。
無駄になるぐらいならいいんですが、これが例えば在庫量だったりすると、
ビジネスチャンスを失ってしまいかねません。

どうです？　排他制御がとっても大切なデータベース機能だとお判りいただけたと思います。



それは次回のお楽しみ

って言っても色々ありますよね。
　(1) データをたくさん入れられること
　(2) データを入れるための時間が短いこと
　(3) 入れたデータが消えないこと、勝手に変化しないこと
　(4) 入れたデータが取り出せること
　(5) 取り出したいデータがすぐに取り出せること

皆さん、この中で一番重要なのはどれだと思いますか？

実は・・・・
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
どれも重要です。
どの要素もかけては大変なことになります。　ってか、データベースとしての機能が成り立ちません。

(1) はどうでしょうか？
　　たくさんというのは客観的ではない表現ですので、言い換えれば、運用上不足しない量と解釈します。
　　つまり、使っている間に容量がいっぱいになってそれいじょうにっちもさっちもいかない・・・
　　重要なシステムでこんなのが起こったら、致命的ですね。

例えば、銀行ATMで、入金しようとしたら銀行のデータベースがいっぱいになって、ATM端末画面に、『申し訳ありませんが、データベースが一杯になりました。処理ができませんので、後日お越しください。』とか表示されたら、あなたはその銀行を二度と使わないようにしようと思いませんか

(2) はどうでしょうか？
　　短いことってまたまた主観的な表現ですが、これは実用上問題ないレベルの時間と言うことです。

またまた、銀行ATMの例で
入金しようとしたら、前の人の入金処理がまだ終わっていません。画面には、『現在、入金処理中です。しばらくお待ちください。』と表示され、タイマーが『残り・・・１７分３２秒』とか表示されていたら、その銀行はもう使わないでおこうと思いますよね

(3) はどうでしょうか？
　　これは、もう、言わずもがな・・・ですね。

銀行の例で、あなたの口座残高が勝手に増えたりしたら嬉しいですが、勝手に減ったら困りますよね。

(4) はどうでしょうか？
　　取り出せなければデータベースの意味がありませんよね。

(5) はどうでしょうか？
　　(4) と似ていますが、『すぐに』と言う副詞が付いています。　これも主観的な表現ですが、(2)と同様ですね。

なので、(1)から(5)の性能はデータベースに必要なことです。


データベース製品によってさまざまです。
ただ、同じデータベースを使っていても、アプリケーションによって、データベース性能をいかんなく発揮できているアプリケーションもあれば、なんでこんなに遅いのか？ってマウスをたたきつけたくなるようなアプリケーションもあるでしょう。

アプリケーションによる差は、データベースの機能を有効に利用できてるかどうかにかかわってきます。
データベースの(5) 取り出したいデータがすぐに取り出せる　機能を有効利用できていなければ、データベース自体がどんなに高性能でもへぼアプリケーションにかかったら耐えきれないほど遅い動作になってしまいます。


もう、言わなくてもわかってらっしゃるでしょー(笑)
へぼ過ぎない限りは、実用上使える・・・程度ではなくて、処理を指示しても、そのレスポンスが早すぎて、処理を指示するボタンを押し忘れたかな？って思う程度です
もちろん、データベースのサイズやレコード数が小さいわけではありません。
メインのデータベースでは、
　レコード数　：　932,205,665
　サイズ　　　：　191,228,723,200
このデータベースから、キーの日付が 20201122であるレコードを検索抽出するのにかかる時間は約 3秒以下
　抽出レコード数は、351,256 レコード

まぁ、AS/400のOSがDB機能を提供しているだけあって、DBアクセスにHardwareまで駆使しているので当然と言えば当然でしょう。
他では真似できない芸当でしょうね。

一言でいうと、データを貯められる器　です。

●データをたくさん入れられること
●データを入れるための時間が短いこと
●入れたデータが消えないこと、勝手に変化しないこと
●入れたデータが取り出せること
●取り出したいデータがすぐに取り出せること

これは、仕様書を見ていただいたらいいのですが・・・
多分、一部の大企業以外ではオーバースペックだと思います


現在、10億を超えるレコードが格納されているデータベースに、60個もの索引を付けていても、実運用上全く問題ない時間でアクセス(挿入・更新・削除)できています

データベースの構造の変更も簡単ですし、新規作成もね

文句の付けようが無いということです。

新しいシステムの構築プロジェクト・・・

当グループ側より提案されたマスター構成について、そんなに正規化したらマスターアクセスのパフォーマンスが心配だ
との意見が・・・


私はＡＳ４００とそのデータベースを使ってきて、正規化命ってぐらいに正規化してきた

だってパフォーマンスが悪化するようにデータベースを利用する為にはインデックスを張らずに全件リードして特定のレコードを抽出するぐらいしかないかなぁ

システムを維持する担当者として、どのようなシステムが望ましいか？

パフォーマンスは？

アプリケーションの使い勝手は？

データベース管理は？

っていろいろと考える事が有りますよね。
でもね AS400 を使えば、そんな悩みのほとんどは杞憂に終わってしまうんですよ。

だって、パフォーマンスは抜群だし、
アプリケーションの使い勝手はレスポンス良いし、
データベース管理は、殆どOSがやってくれるし

でもね グループ本社の圧力で、このAS400で構築したシステムを切り貼りして、グループ共通のシステムを導入しろって言ってくるんですよ。


すると、一元管理出来ていたデータベースが細切れにされて、データのバケツリレーをしなきゃならなくなります。
これが、情報の整合性を保つのにえらい苦労するんですよ

やだなー

現在、現行システムのファイル定義書なるものを作らされていますが・・・

各ファイルのレイアウト、フィールドについての説明、論理ファイルの仕様など、エクセルにまとめています。
指示では主要なファイル27についてですが、その中に当然のことながら顧客マスターも含まれています。

この顧客マスター、論理ファイルの仕様を調べようとしましたが、

どっへー

って感じでした

なんと、論理ファイルが900個近くついているんです。

論理ファイルとは、データベースをアクセスする為のインデックスです。
AS400では、そう呼びます。

資料を手で打ち込むのは非常にばかばかしいので、コンバートしました。

作られた資料を見るだけでも大変だろうなぁ