「酸」と「塩基」に見る理想の父親像についての話。
ちょっと偏った話をしたい。
タイトルにも書いたが、「酸」と「塩基」について。
とは言っても、化学の話がしたいわけじゃなくて、ましてや化学の知識なんてとうの昔にサッパリ忘れてしまった私が、そもそもそんな話ができるはずもなく。
では何の話かというと、ずばり「データベース」の話だ。
「データベースって何？」という方もいらっしゃるかもしれない。私は、普段、システム開発業務に従事しているので、聞き慣れている、というかこれが無いと仕事にならないくらいに密接に関わっている言葉なのだけれども。
今回の記事はこれについて、少し説明していきます。
なので、「よし、よく分かんないけど、とりあえず聞いてやるか」という方は、是非お付き合いいただければと思います。なるべく専門用語は使わないつもり。
あと、システムが本職の方は、読まないでください。嘘です。読んでいただいてもいいですが、適当なことばっかり書くので、先に謝っておきます。ごめんなさい。「ああこいつは頭が悪いんだなあ」と思っても、どうか温かく見守って見逃してやってください。
それでは、どうぞ。
「データベース」とは何か。
ネットで調べると、こんな定義が出てくる。
データベースとは、構造化した情報またはデータの組織的な集合であり、通常はコンピューター・システムに電子的に格納されています。
ちょっと分かりにくいので、ものすごくザックリとした説明をすれば、「データを入れておく箱」とか「データを集めて置いておくところ」としてここでは捉えていただければいい。厳密には様々定義があるが、ひとまずそう考えておいていただきたい。
その前に、そもそも「データ」って何、という疑問がある方も居るかもしれない。これも調べてみよう。
既知の事項や判断材料．研究活動においては，調査や実験により得られ，考察の材料となる客観的な結果である．一方，情報処理システムの処理対象でもある．
これに関しては、後者の「情報処理システムの処理対象」というのがここでは一番適切だけれど、難しく考える必要は無くて、今の世の中では、客観的に存在するあらゆるものがデータになり得る。
たとえば、ネットサーフィンして通販サイトで「良いなぁ」と思ってついクリックしてしまった商品の嗜好とか、病院に診察に行って自分が今までその病院で診察されたカルテとか、よく行くスーパーで買い物のたびにポイントカードを提示して買った金額に応じて溜まっていくポイントとか、こうして note に書いている記事そのものとか、例を挙げればキリが無いけれど、客観的に存在しているものであれば多分なんでも「データ」として扱うことができる。
ポイントはこの「客観的」というところにあると考える。現代ではまだ「自分の頭の中にある考え」とか「形而上」的なものは、外に現れていない限りはデータにはならない。でも、近い将来もしかしたら、たとえ目には見えないものだとしても、それも何らかの媒体を介して客観的に表現されることになればその限りではない。と私は思う。余談。
さて、そういう「データ」たちを入れておく箱、が「データベース」だ。
具体的なイメージを、ちょっとお見せする。
私は、今まで note に書いた記事たちをデータにして、個人的なデータベースに登録している。この画像キャプチャは、なんとも恥部を晒すようで恥ずかしい限りだが、そのデータベースの登録状況を表示したものだ。
「どんだけ自分好きやねん」と言われてしまいそうだが、少し言い訳をさせてほしい。note にはエクスポート機能が無いので、仕方なく、記事のデータを抽出して個人のパソコン内に保存しておく仕組みを自作しているだけだ。やっぱり誰が何と言おうと、幾ら他人にはつまらなかろうと、自分の書いた文章は、記事は、大切なものなのだ。それを失わないために、このような方法をとっている。
ちなみに、ここでは、青くハイライトが当たっている１行ごとに１つの記事データを表している。色んなデータの形式で表現は可能だが、私は単純に、文字という形式で保存している。
このように、客観的に情報として整理することができるのであれば、基本的にはどんなものでも保存が可能だ。
ところで、いわゆるシステム設計とかシステム開発の仕事についている人たちの間では、この「データベース」という存在は以下のような特性があるものとして長らく認識されてきていて、それを前提としてシステムが作られてきた。
原子性（Atomicity）
処理が実行されたか、実行されていないか、どちらかであること。一貫性（Consistency）
開始時点と終了時点とで、データに整合性があること。隔離性・独立性（Isolation）
同時に複数の処理を行っても、それぞれ正しい結果になること。持続性・永続性（Durability）
処理した結果は正常に保持されて、失われないこと。
この説明もザックリだな。
厳密には、データベースというよりも、これは、とある処理が行われてデータを扱う際に、このような特性を前提として、データベースが使われていると言ったほうが適切かもしれない。
で、これらの特性を、それぞれ順番にアルファベットの頭文字をとって、
「ACID」
と呼ぶ。
誤解を恐れず言ってしまえば、要するに、
「システムで処理したらちゃんとデータは登録されるし、勝手にはデータが変わらないし、同時に誰が何人でどうやって処理してもキチンとした結果になるし、処理の前と後とで『まぁ普通そうなるよね』『おかしなことにはなっていないね』という結果が得られて、一回処理したらそのデータはちゃんと無くさないまま持っていてくれる」
ようなもの。
システムを作る側としては、データを処理してその結果を入れておく箱としてデータベースを利用するので、この特性は非常に重要だ。
よく教科書の説明の中でたとえられるのが、銀行口座のデータだ。
たとえば、Aさんという人の口座の残高が9,000円だったとして、Aさんが自分の口座から1,000円を出金して、それをBさんの口座に入金するとしたら。
Aさんが出金操作をして初めて、1,000円のデータが出ていくし、Aさんの口座に対して何もしていないのに勝手にお金が減ったり増えたりすることはない（１．「原子性」）。
出金操作をしたら、9,000円から1,000円を引く計算がされて、正しく残高は8,000円になる（２．「一貫性」）。
仮に、AさんがBさんに1,000円を入金しようとしたときに、同じタイミングでBさんがCさんに対して5,000円を振り込もうとしても、Bさんの口座は、Aさんの1,000円が入ってきて、Cさんへの5,000円分が減っていないといけない（３．「隔離性・独立性」）。
そして、一連の操作が終わった後も、Aさんの口座の残高は8,000円のままになっていて、次の日になったら何もしていないのに勝手に残高が9,000円に戻っていたなんてことはない（４．「持続性・永続性」）。
普通に考えれば「いやそんなの当たり前でしょ」と思うんだけど、そういう当たり前を支えるために、こうやって、データを処理する流れを制御したり、おかしなことにならないよね、と注意を払う。言わば、ガチガチにすべてのデータの行き先とか形をきちんと決めて、綺麗な状態で扱う。そうやってシステムを作っている。
その土台になるのが、データベースであり、そのデータベース上でデータを処理する際に一般的に備わっているとされているのが、そういう「ACID」の特性だ。
で、それに対して、近年（と言っても結構前からあったみたいだが、一気に盛り上がってきたのは、肌感覚でここ10年くらいな印象）、「ACID」とは違う特性を持ったデータベースが勢力を付けてきている。
どんな特性かというと、これだ。
基本的に利用できる（Basically Available）
基本的にはいつでも利用可能な状態であること。柔軟な状態（Soft-state）
データは厳密ではなくていいし、常に一貫していなくてもいいこと。結果整合性（Eventually consistent）
最終的にデータが一貫していればOKであること。
こちらも、ざっくりと表現するならば、
「ある処理が使えなくなったとしても、システム全体として動いていればよくて、誰でもいつでもすぐに使えることができて、処理途中のデータはたとえ変なものが混じっていたり、何かちょっとデータの作りがおかしかったとしても、最終的にちゃんと処理完了して結果に問題なければそれでOK」
といった感じか。
上に挙げた「ACID」に対して、こちらは、
「BASE」
と呼ぶ。
勘の良い方ならお気づきの通り、
「ACID」→「酸（acid）」
「BASE」→「塩基（base）」
という、何とも見事な用語定義になっている。まあ見事というか、ダジャレのような、遊び心というか。上手いこと言うね、みたいな。
では、なぜ「BASE」という特性のデータベースが出てきたかについては、一言で表すなら、「大量だったり、色んな種類や形式のデータを、高速に処理する必要が出てきたから」だ。
上に挙げたとおり、「ACID」特性は、堅牢で厳密で、ブレが無い。一貫している。信頼感がバツグンだ。
しかし、それを利用するためには、事前にデータの種類と形式とか、どうやって保存しておいたらいいかとか、そういうのをキッチリ細かく決めておく必要がある。また、そういうガチガチに固まった形式のデータが増えていけばいくほど、データベースの仕事も大変になる。
そうすると、ガチガチのデータを処理するためにパワーがたくさん必要になる。データベース自体もそれを扱うシステム自体も、とにかくやらなきゃいけない仕事が多くて、しかも面倒な仕事ばっかりで大変になっちゃう。
結果、処理がめっちゃ重くなって、動きが遅くなる。
スピードが求められる現代、動きが遅いことはかなり致命的だ。ましてや、システムが経営の立場から欠かせないツールとなっている場合はなおさら。さらには、ビッグデータなどの大規模なものや、複雑で雑多な形式のデータを扱う必要性が出てくれば、にっちもさっちも行かなくなる。なんだか処理も重いし、あんまり機能がアップグレードされないし、扱えるデータが少ない、となると、それこそシステムを使う旨味も減ってくる。最悪、使わない人が増えて来たり、事業競争に敗れたりして、悲惨なことになりかねない。
やっぱりそういう状況で、「ACID」型のデータベースで全部が全部をカバーしようとすると、それだけ無理が出てくるわけだ。
そこで、「BASE」のデータベースによって、「最初から最後まできちんとしていなくていい。途中のデータは多少ヘンでもいいから、さっさと沢山さばいちゃおうぜ」という方針で、処理を進めた方が都合が良いケースも出てきた。
もちろん、適材適所はあるので、どっちが優れているとか劣っているという話ではないのだけれど、こうやって、人が生み出した行動や意思決定を情報として扱い、データベースで管理できるような形にして、より便利な世の中にしようとしている。
そうやって、私のようなエンジニアの端くれも含めて、システム開発のお仕事をする人たちは日夜がんばっているのだ。
と、これだけだと、単にデータベースとシステムのお仕事の紹介（しかも教科書に書いてあるような入門レベルの話）なのだけれど、それで終わりではない。
「ACID」と「BASE」、何かに似ている。
何だろう。
そうだ、子育てだ。
その前に一言。
普段私は、note で偉そうに子育ての話を書いてしまっているが、それは敢えて、気付きを記すことで、自分への戒めにしている部分がある。「お前、こんなこと前に書いてたよな。できてんのか？ああん？」みたいな。
もちろん出来ていない。出来ていないのだ。だからこうして、偉そうに今日も書くのだ。未来の自分のため。
閑話休題。
思うに、私自身が子供に対して接する際に、父親像として無意識にイメージしているのが、まさにこの「ACID」だと思うのだ。
きっと、これを読んでいる方は、私の説明があまりに下手くそすぎて、ACIDなどという言葉の定義は忘却の彼方へ葬り去っていると思う。したがって、ここでもう一度、くどいようだが、ACID特性の定義をおさらいしておこう。
ACIDとは、１．「原子性」、２．「一貫性」、３．「隔離性・独立性」、４．「持続性・永続性」を持っていること。
これを父親像として考えた場合に、言ってしまえば、「厳格で頑固一徹でめっちゃしっかりしている父ちゃん」ということだ。
そう、たとえば、こんな感じかもしれない。
子どもが悪いことをしたらこっぴどく叱るし、場合によっては手が出る。裏表はないし、頼もしい。男に二言はないタイプだし、笑うこともあまり無い。無口で余計なことは言わず、いつもムスッとしている。そのくせ細かいことにいちいちうるさい。仕事で帰りはいつも遅い。「男は外で稼いでくるものだ」と思っている節がある。子供が宿題をきちんとやらなかったり、部屋が散らかったままになっているのなら、容赦なく雷を落とす。「厳しさ＝愛」とか思っているタイプだ。言わば、威厳の塊。
何とも、子供からしたら、怖い父親だ。
かく言う私も、子供に対しては、つい厳しくしてしまう。優しくもするが、つい厳しくして叱ってしまう。「可哀想だが、この子のためだ・・」と涙をこらえて心を鬼にするのだ。
でも、そういう父親像は、果たして正しいのだろうか、と最近思うようになってきている。
そんな、厳格で完璧でそれでいて愛情深い、ザ・昭和の男のイメージを地で行くことができる父親って、多分一握りだ。
そして、これは私の独断と偏見だが、そんな父親になりたい人って、実はあまり多くないんじゃないかと思う。少なくとも私は、そうはなりたいとは思えない。
それでも、子供と接する時（特に、叱らなきゃいけないと思っている時）にはそういう父親像をイメージして、そう振舞ってしまう。自分はそんな完璧なはずが無いのに。結局、厳しくはあるけれど、愛情が足りなかったりする。いつも、叱った後に、「ああ、言いすぎたなぁ」と凹んでばっかりだ。現実の私は、学ばない愚かな親なのだ。
だから、敢えてここで「BASE」の出番ではないかと考える。
こちらもおさらいしよう。BASEとは、「基本的に利用できる（Basically Available）」、「柔軟な状態（Soft-state）」、「結果整合性（Eventually consistent）」という特性を持っているもの。
父親でたとえれば、「いつでもフレンドリーで話しかけやすくて、どんな相談でも受け入れてくれ、細かいことは気にしなくて、途中子供が失敗しても『いいよいいよ』と笑っていて、一貫性は無くて言うことがコロコロ変わったりするけれど、決めるときは決めて、最後に結果良ければそれでよし、とドーンと構えている父ちゃん」とでも言おうか。
ACIDとBASEで、どちらの父ちゃんで居たいかというと、やっぱり私は「BASE」のほうでありたいと思ってしまうのだ。
もちろん、子供に対しては、時には厳しくする必要もあるだろう。けれど、基本的には、「大好きで親しみやすい父ちゃん」で居たいのだ。そして、BASE特性が生み出された背景にあるように、子供がどんなに面倒で大変な問題を持ち込んできても、複雑な悩みを抱えていても、それに対して、スピーディに対応して、最終的には解決してあげられるような、そんな父親像が、理想だ。
なお、ここでは「父親」と書いたが、別にそれは「母親」でも同じだと思う。私は男なのでそういう表現にしたが、上に書いた「BASE」の母ちゃんでも最高だと思うからだ。単に親としてのスタンスという意味を出ないことを明記しておく。
時には「ACID」、でも基本は「BASE」といったようなスタンスで、子供と接することができたら理想だな、と個人的には思うのだ。
子供にとって、どんな親であるべきか。そんなことについて、まさか日々当たり前に使っている仕事の道具の中から、考えるヒントを得てしまった。何だか得した気分だ。
仕事から、子育てから、やっぱり世界は混沌としていながらも、つながっていると思うのだ。
というわけで、仕事のような仕事でないようなお話でした。おしまい。
この記事が気に入ったらサポートをしてみませんか？