最近,時代遅れのDB論理設計の流れが取りざたされている.そのため,私にDBの知識は無いが,DB利用反対を表明しようと思い,今回投稿する.
http://qiita.com/nishina555/items/a79ece1b54faf7240fac
まず,いかにDBの知識が無いかをさらそうと思う.
以下の4ステップとして無知であることを説明する.
- エンティティとは.
- エンティティの何を定義するのか.
- 正規化とはうまいのか.
- ER図とは新たなビデオゲームか.
以下のステップごとに説明を行う.
- ステップ1:エンティティとは.
- ステップ2:エンティティの何を定義するのか.
- ステップ3:正規化とはうまいのか.
- ステップ4:ER図とは新たなビデオゲームか.
無知をさらすためだけの投稿により,まとめは当然無い.ポイントをまとめることもない.
しかし,無知だけをさらすのは恥ずかしいため,知っていることをチラッとだけひけらかそうと思う.世の中の役に立つまい.
ステップ1:エンティティとは.
エンティティを実体と訳すようだ.
実体を考えながらDBを作成する必要があるのだろうか.
時間の無駄にしか思えない.
思いついたモノを片っ端に作ればいいと思っている.何より,事前に考えるのは脳みそが付いていかないため,不可能に近い作業だ.
ゆえに,今回のステップでは,訳しただけで終わる.
踏み込むのはナンセンスだ.
ステップ2:エンティティの何を定義するのか.
エンティティ(実体)を構成するために,テーブル単位にまとめる必要があるようだ.
逆に言えば,同種を1つのテーブルにまとめると言うことだろう.
リンゴやバナナであれば,果物テーブルを想像すればいいのだろうか.
そんなものを考えつく人が羨ましい限りだ.
しかし,果物に必要な存在は分かる.それは私だ.捕食者がいなければ,果物の存在理由は無いからな.
ゆえに,果物テーブルの中に私が存在して問題ない.この私をあるじ(主キー)と言うべきだろう.そして,私が手に入れた下僕(果物)は誰にも渡さないため,外部キーは存在しない.
私は私だ.さあ来い!私はここだ!ここに居る!君はそこに居て,私はここだ,ここにいる!
1人しかいないのだから1テーブルだけで事足りる.
誰が食事をするのかが主キーになっていれば問題ない.
外部キーを設定するのはナンセンスだ.
ステップ3:正規化とはうまいのか.
果物を想像したらお腹が空いてきた.
正規化を行えば,満腹になるとでも言うのだろうか.
まったくのナンセンスな名前に思うのだが・・・.
せっかく,私が果物を独り占めにできたのだから,わざわざテーブルを分ける必要は無い.
むしろ,食べ物は果物だけではない.
1つのテーブルに肉や野菜も追加すれば,1つのテーブルを参照するだけで事足りる.
分けるのはナンセンスだ.
ステップ4:ER図とは新たなビデオゲームか.
食事をしたら運動しなければならない.
ER図とは新たなビデオゲームの名前だろうか.
図でテーブルを表す暇があるならば,テーブルに詰め込めるだけ詰め込む方が楽では無いのか.
テーブルの作成以外に時間と労力を費やすのはナンセンスだ.
知っていること:無知の知・・・とは言わないか.
なぜ,上記の4つのステップを知らないままなのかを説明しようと思う.
そもそもDBとは,データベースのことであり,ドラゴンボールのことではない.
もっと言えば,データベースマネジメントシステム(DBMS)と言い,
データベースは大量のデータを系統立てて保管することができ、必要に応じて検索、抽出、加工することができる
ことを指す.
http://e-words.jp/w/データベース.html
派手にステップを踏んでいるなぁ!!我がSQL!!我が無知!!あっちゃもこっちゃもみいんな御破産!!さぁて願いましては!!
さぁてそろそろクライマックスだよ
私のターンだ.
上記でも述べたが,DBとはDBを扱う前にDBを使う準備が万全に出来ていなければ使えないと言うこと.一言で言えば,目的が無ければ使えないと言うこと.
上記の果物を例に出したように,突然肉や野菜の区分を果物テーブルに追加できないと言うことになる.もし,追加するのであれば,肉用のテーブルや野菜用のテーブルを作成しなければならず,それらのテーブルに紐付けるための外部キーを事前にメイン(果物?)テーブルに追加しておかなければならない.
自分で説明しているはずなのに,混乱するような説明になって申し訳なく思・・・わない.
なぜなら,DBが遺物だからにきまっている.
もし,DBを運用する上で,野菜テーブルではなく,テーブルという名前で果物カラムが有り,ひょんな事で肉や野菜の項目を追加できるとしたらどう感じるだろうか.もちろん,稼働を止めること無く追加できるとしたら素晴らしいと思わないだろうか.しかも,無限に行を追加でき,そのカラムの中にどのような値でも入れられるとしたら夢のようではないだろうか.
もちろん,追加したからには検索も可能だとしたら失禁ものだろう.
その夢のDBをこれから説明しようと思う.読み終えて失禁しないでくれよ.
小便はすませたか?神様にお祈りは?部屋のスミでガタガタふるえて命乞いをする準備はOK?
では,始めるぞい.
今回核になっている技術は,IBM UniVerseのはずなのだが,頻繁にURLが変わるようで,昔のリンクが役に立たない.
そのため,画像だけを貼り付ける.もし,運がよければ,サイトにたどり着けるでしょう.
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_9.1.0/com.ibm.swg.im.iis.ds.univ.doc/topics/g_cuniref_Connecting_to_UniVerse_and_UniData_Databases.html
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_11.5.0/com.ibm.swg.im.iis.ds.univ.doc/topics/universeandunidata.html
検索ワードのヒントはInfoSphere DataStage and QualityStageのBASIC言語に近しいはずなので,それらしい言葉で検索すれば出てくると思われる.
見つけた.
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_8.7.0/com.ibm.swg.im.iis.ds.basic.doc/topics/r_dsbasic_TRANS_function.html
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_8.1.0/com.ibm.swg.im.iis.ds.serverjob.dev.doc/topics/r_dsvjbref_Deffun_Statement.html
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_11.5.0/com.ibm.swg.im.iis.ds.basic.doc/topics/r_dsbasic_FUNCTION_statement.html
http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_8.1.0/com.ibm.swg.im.iis.ds.basic.doc/topics/r_dsbasic_REM_function.html
■エンティティを考えるのが不要の理由
通常のDBでテーブルを考える場合,正規化などを考慮することにより複数のテーブルやキーなどを用いながら,さらにテーブル同士を紐付けることで必要なレコードを取得することだろう.
それがナンセンスという.
1つのテーブルに主キーを決めたら,それ以降の項目やレコードを無尽蔵に作成した方が利便性が高い.
http://qiita.com/jkr_2255/items/5a71ff5f8569c5e0f24d
例えば,1レコード目の2カラム目を無尽蔵に増加させたり,3カラム目以降を追加できれば,使い勝手がよくならないだろうか.
考える作業が不要になる.そして,欲しい情報があるならば,検索をかければいい.
■正規化を考えるのが不要の理由
上記でエンティティを考えるのが不要と説明した.
無尽蔵に追加できるため,正規化すら不要になる.
無尽蔵に追加できると言うことは,記入できない箇所があると言うこと.それでも問題が無いのは,それがエンティティだから.
「俺」の果物が1つに,肉が3つに,野菜が4つなのは,好みの問題だから.
逆に「僕」は果物が4つに,肉が3つ,野菜が1つでも問題ない.それが個々人の好みだからに他ならない.
検索をしたときの戻り値が何もない場合どうすればいいのかと言えば,それこそそのときに応じて決めればいいだけになる.
例えば,肉を検索したときの結果に,2つ以上ない場合野菜の結果を出せばいいだろうし,野菜が不要なときは果物で構わないし,それも不要であれば「なし」で構わない.
検索値を設定すればどのようなDBでも対応可能だと思うかもしれないが,その設定すらめんどくさいと思う場合どうすれば良いのだろうか.
この検索値をExcelのセルに計算式を埋めるようにカラムを事前設定すればいいだけのこと.
そのカラムだけを参照すればいいだけなので,開発時に楽が出来ることでしょう.まさに夢のようなDBとは思わないだろうか(下図で言えば,右端のカラム1つだけで事足りる.左端の捕食者も必要だが).
さすがの私でも,これは食い切れるかわからんDBだな!!
■エンティティや正規化を考えた場合
意味のある塊ごとにテーブルを複数にしたい場合も可能なのは当たり前だと思う(1つにまとめるのが前提かもしれないが,複数にも対応可能だから夢のDBと言う).
その場合も1つのカラムで複数のテーブルを参照可能なのは変わらない.
また,列に属性を持たないため,此処のカラムに数値や文字列を持たせることも可能になっている.
どのような文字コードでも扱えるかもしれないが・・・今回はシフトJISを用いることにする.外字は扱わない(それが現場の方針だから).
■夢のDBとは
ここまでの説明で,夢のDBが何を指すのか気がついたことでしょう.
さあ!!諸君!!DBで殺したり殺されたり死んだり死なせたりしよう.さあ乾杯をしよう.宴は遂に今宵・此の時より開かれたのだ.
東京証券取引所(通称東証)が採用している4D DAMというマルチバリュー以外に思い浮かばなかったはず.そう,DBではない.想像しやすいだろうと言うだけで,全然無関係の劣った名前を用いていたに過ぎない.
間違いない.こいつは,この4DDAMは,これらこそが我々の御敵よ.我々の宿敵よ.打ち倒すのは我々だ.打ち倒してよいのは我々だけだ.誰にも邪魔はさせん 誰にも!誰にもだ!!
http://www.jpx.co.jp/corporate/jpx-profile/tse/
https://www.value-press.com/pressrelease/39754
https://www.4dn.co.jp/develop/20090527/
https://www.facebook.com/4D-Networks-Inc-340487252658486/
http://blog.goo.ne.jp/abe-blog/e/2125448f51d931280ebbd33afb09245b
https://8clouds.co.jp
http://www.sparkle-inc.co.jp/ai_dam.html
https://twitter.com/alfaindian/status/27264309042085889
株情報に関するデータウェアハウス:http://www.bigdatarobo.co.jp/wf/cases#case-1
http://internetcom.jp/busnews/20101108/5.html
http://blog.goo.ne.jp/katakait/e/30326158763a7191af0ba81349089748
http://qiita.com/yoneken/items/181910ddbb7e236122a0
PDF:https://www.4dn.co.jp/wp-content/uploads/pdf/4DDAM090527.pdf
・その他URL
http://qiita.com/sawadybomb/items/bc03eca4699665bf2695
http://sugi-tec.tokyo/2014/10/27/製品の評価(用途の見極め、使い勝手、性能など/
http://www.jpx.co.jp/regulation/preventing/quarterly/
http://www.jpx-recruit.jp/project_03.html
http://www.ndl.go.jp/jp/diet/publication/issue/0496.pdf
http://www.kogi.co.jp/pdf/oshirase/110-150108.pdf
http://www.jast.jp/pdf/20050518kaizen.pdf
http://qiita.com/akiraak/items/27d8e91982d3322873c3
http://qiita.com/ANTON072/items/e0534daa4b2fb0f553eb
我らは己らに問う.汝ら何ぞや!!
「我らはマルチバリュー マルチバリューの4DDAMなり!!」
私は2014年の1月と2月にスモールティック修正案件に関わっていたが,その数ヶ月後に名称変更だ.
http://www.asc-net.co.jp/info/高速データベース「4d-dam」の製品名変更のお知/
残念だ.
しかし,今回は旧名称を用いることにする.呼び慣れている名前を使いたいからと言う個人的な欲求なのだが・・・.
ちなみに,新名称は「AIDAM」と言う.
4DDAMに関わっていたときの案件は,株価3千円以上の価格帯について,呼値の単位を見直し,Topix100に限定して,小数点対応をするというもの.
すでに2010年ごろの東証は次世代株式売買システム「arrowhead」を導入していたのだが,今回の改修作業で次期株式売買システム(arrowhead リニューアル)として刷新されることになった.
http://www.iforex.jpn.com/news/東証が9月にアローヘッドをリニューアルへ-1327
http://it.impressbm.co.jp/articles/-/8854
http://www.itrade.co.jp/-/raw/34/3351/24697/5/16/20140806.pdf
http://gihyo.jp/news/report/2013/12/1702?page=1
https://www.jip.co.jp/report/detail.php?report=00176
オープンソースのシステムを一部流用しているようで,東証のシステムに用いたオープンソースの流用方法を社内でのみ展開していた.インターネット上に展開していないため,意味ある宣言なのか疑問だったが,世界に名を連ねるシステムなので,問題ないのだろう.
私もオープンソースを流用して,世界に注目されたいと思っている.
そのためにも4DDAMについて詳しくなりたいと思った.
もっとも,あなた方は知らなかっただろうし,知らなくていいんですが・・・我々「長いものに巻かれる派遣社員」通称「社畜」は随分と昔から巨大企業と闘ってきたんですよ.
■改めて4DDAMとは何かを説明する.
実際のところよく分からない.
そもそも東証システムの一部とは言え,株の取引を行うシステムとは無関係の立場になっている.
私が関わった4DDAMの役割は,arrowheadの株売買終了後に,取引データから不正行為が無かったかを調べるためのシステムになっており,通称Artemisと呼ばれ,売買監視表・基準抽出・未然防止・バスケット・指数急変動の手法で審査を行う.
しかし,分かっているのはそれぐらいで,4DDAMとは何かを把握できないままで終わった.かなり急ピッチな期間だった.
そして,UIの部分はJava言語を使っていたため,ブラウザ上で試験を行う.
http://172.22.175.204:9080/ArtemisWebApp/Login.jsp
値動きのシミュレーションも出来るようで,素晴らしいらしい.
■名前のこだわり
上記の例で示したとおり,カラムの中に式を埋め込めるため,入力値と出力値が絶対に一致しない.
そして,上記の例で示したとおり,条件式をカラムに埋め込んでいるカラムを仮想フィールドという.
このフィールドは,2種類あり,物理フィールドと仮想フィールドの2つだ.
マルチバリューでの使用名は,こだわりがあるようなのだが・・・.
https://ja.wikipedia.org/wiki/マルチバリュー
http://www.pickwiki.com/index.php/Pick_Operating_System
https://en.wikipedia.org/wiki/Pick_operating_system
東証の開発現場では,レコードではなくitem(アイテム)と言い,フィールドではなくattribute(属性)と言った.
しかし,仮想フィールドや物理フィールドとも言うのだから混乱していた.
■手頃な箇所
AndroidOSに用いられているSQLiteは,利用データをテキストファイルに保存できることで有名だ.そのため,知識さえあれば,バイナリエディタでデータを書き換えられることだろう.
http://qiita.com/zaburo/items/ad690284f7430bdf5f9e
http://qiita.com/inouet/items/6fe9c69493c59ecf725d
http://qiita.com/ymko/items/8c883f21a05518706c57
http://qiita.com/tacck/items/6ef046cbbf1d848cfeea
http://qiita.com/sotetsuk/items/cd2aeae4ba7e72faad47
http://qiita.com/AsladaGSX/items/2bb743d1d8b19cec6cbc
https://ja.wikipedia.org/wiki/SQLite
http://monoist.atmarkit.co.jp/mn/articles/1209/13/news001.html
http://android.roof-balcony.com/shori/strage/sqlite/
http://android.keicode.com/basics/sqlite-dataadapter.php
その他のURL
http://qiita.com/cattaka/items/1edd041c59cbcfeb6ff4
http://qiita.com/nyamage/items/a3ccb27cdde69877c8da
http://qiita.com/toshirot/items/90d8e29d10895433c248
http://qiita.com/yaaamaaaguuu/items/0b2c6ca9b33cc320b360
http://qiita.com/shini12/items/84a1e80830b91613f998
http://qiita.com/takuya_1st/items/86c65f5ed93ed5233793
http://qiita.com/roworks/items/08b195f68b9535c4ab30
しかし,4DDAMは違う.
核になる部分を除けば,アカウントごとディレクトリ構造で保存できる.
例えば,WindowsOSを端末にインストールしたあとに,WindowsUpdateを実行してから,OSごと丸ごとバックアップを取るような想像をしていただければいいだろう.そのバックアップデータを使って,複数の端末にOSをインストールしていけば,インフラチームとしては楽が出来るはず.
それと同じように,他の人が設定した内容やデータを丸ごと保存できることで,使い回せるだけでなく,全く同じ環境を再現でき,作業をスムースに進めることも大きな特徴になっている.
それらの設定は以下の構造になっている.
便利なのはいいのだが,ネックはライセンスの問題がある.
上記の例として,WindowsOSのバックアップデータを使い回すのは,それなりのライセンスがあったはずなので問題ないと思う.
私が関わった4DDAMのライセンスは,CPU数だったため,4アカウント分のみ契約していたようで,8人以上いるのに4人しか使えない.
実に残念だった(べらんぼうに高価だったのだろう).もしかしたらCPU数では無かったかも・・・かなりうろ覚え.
http://bizex.goo.ne.jp/release/detail/54321/
http://www.keyman.or.jp/kw/4d%E3%80%80dam%E3%80%80vs%E3%80%80oracle%E3%80%80価格/
(価格に関して情報が無い.残念だ.)
■具体的なSQL文
NoSQLとは:http://qiita.com/t_nakayama0714/items/0ff7644666f0122cfba1
SQL文の基本的な記述は,他のSQLと同じなので,そこまで気にする必要は無い.
上記の「検索カラム追加」テーブルから値を取得することにする.
select 肉4つ表示 from where 検索カラム追加 捕食者 = ‘俺’;
ガチョウ
ウサギ
カンガルー
白菜
さらなる具体例は以下になる.
select * from H_FIRST_TOP_ST_161113 where @ID = '161113-01:75611';
テーブル名:H_FIRST_TOP_ST_161113
主キー項目名:@ID
・挿入・更新・削除
上記のSelect句で他のSQLと同じだと説明してしまったが,挿入・更新・削除などのSelect句以外は特殊だった.
前に,物理フィールドや仮想フィールドの話をしたと思う.
そのフィールドに対して,実際に挿入・更新・削除などが出来るのは物理フィールドに対してだけ.
そのため,「肉4つ表示」項目に対して挿入などはできないことになる.
もし「俺」の「肉4つ表示」項目内容を変更したいのであれば,果物テーブル・肉テーブル・野菜テーブルなどの物理フィールドに対して行う必要がある.
逆に言えば,その制限があるため,保守に大幅な時間を取られてしまう.
ましてや,100以上のテーブルを要する場合,物理フィールドなのか仮想フィールドなのか判断が付かないため,人海戦術で確認しなければならない.
そのため,ほんの少しだけの修正を加える場合も例外ではなく,すべてのテーブルを見直す必要があり,全てのテーブルに対して試験を行わなければならない.
東証はそれを把握していないため,契約金が高すぎることで契約を破棄した.ゆえに,私は存在しない契約を契約通りにこなす必要に迫られ,用事があるとリーダに伝えたのに「仕事だから」の一言で休出を強要されたこともあった.
2014年1月25日の土曜日に出社した今となってはいい思い出だ.休出を指示したリーダは,いつも通り寝坊で遅刻したため,仕方ないためいつも通り共連れ入館した.
世間に出回っていないDBを使うなと言うことでしょう.
ゆえに,いまでは4DDAMの採用を取り消して,オープンソースのDBに置き換えているはず・・・きっと.
その置き換えを早い段階で行ってくれていれば,東証は契約を行い,約束通りに緩やかなスケジュールで人員を確保した状態の作業だったのに…
上記の説明で簡単そうな夢のDBとほざいてしまったが,保守作業は膨大なコストが掛かる.
RDBMSとNoSQLの違い⇒http://qiita.com/Ta-tun/items/db50174ee45e8c2e4f81
NoSQLは 〜省略〜 シンプルな構造でデータの正確性はない。それではどうするかというと、アプリケーション側の実装でカバーするしかなく、それはとても大変なコストがかかる
他の参考サイト
http://qiita.com/yk-nakamura/items/5022f51ffc39e4a8c412
http://qiita.com/dotKomu/items/13f9223f2957436f3019
http://qiita.com/aozaki_aoi/items/86e4f6a5c93a87d3825c
熟練者で無ければ保守できない.その仕様などはボソボソ説明していく.
上記で,全てのテーブルに対して試験をするような話を出したが,有識者(熟練者?)であれば,必要最小限に抑えられたのでしょう.
TOC有明の19階ビルで働かされていた頃が懐かしい.
話がずれたので戻す.
挿入をする場合の具体的なSQL句は以下になる.
INSERT INTO H_FIRST_TOP_ST_081226 (@ID, RELATE_H_TRADE_LIST_KEYS, H_TRADE_LIST_KEY, F3) VALUES ('161111-01:75611', '161112-01:75611', '161113-01:75611', '20140125 16:37:39');
更新をする場合の具体的なSQL句は以下になる.
update H_FIRST_TOP_ST_161113 set RELATE_H_TRADE_LIST_KEYS = '1234567890' where @ID='161113-01:75611';
削除をする場合の具体的なSQL句は以下になる.
delete from H_FIRST_TOP_ST_140125 where @ID = '140125-01:75611';
■物理フィールドの対象テーブル
上記の注意事項の他に,さらに気をつけなければならないことがある.
設定の問題だと思うのだが,物理フィールドに関するテーブルがいくつか勝手に作られる現象に見舞われて困ったことがあった.
その理由は,「パートファイル」と「分散ファイル」の2テーブルが作られる.
(ファイルという名のテーブルだと思ってください.)
例えば,終値一文高関与抽出データ-株式(H_FINAL_RISE_ST)テーブルの更新を行う場合について説明する.
人間が4DDAMを操作してテーブルを作成する場合の他に,4DDAMが勝手にテーブルを作成することがある.
それをパートファイルという.これは日付ごとに作成され,集約コマンドを用いて分散ファイルにまとめる必要がある.
それらの流れを4DDAMが勝手にやってくれる.そのため,通常は意識しなくて構わないのだが,単体試験のように直接テーブルをいじる場合は,分散ファイルを触らなければならない.
また,結合試験や総合試験のように,通常の業務に準じた試験をする場合は,パートファイルを操作してから,集約コマンドを実行しなければならない・・・しかし,そのときは単体試験だったため,分散ファイルを直接操作して,事なきを得た.
結局最後の最後まで,集約コマンドが分からないままだった.誰に聞いても・・・.
そんな大事な仕様すら誰もしらないため,いっこうに作業が進まなかった.困った案件だった.
有識者が誰もいないというのが一番辛い.解決方法を手探りでしなければならず,解決したかどうかの確かめようもないのだから・・・.
仕事は仕事.
動作結果を試験項目書の試験予想結果と試験結果に貼り付けて,同じ事になっていれば試験消化と言うことで次の項目に移った.
解決しないまま作業を進ませたこともいい思い出だ.
■いままでの説明を具体的に説明(私の妄想を交えて)
その他のURL:http://qiita.com/fujisan3/items/59ad5c7d47270bb51ca8
具体的なSQL句で@IDなどを出したため,今までの例を全て破棄して,本来の表記方法を行おうと思う.
- @IDとは,テーブル内において一意な主キーを表す.
- 〜idとは,集合内において一意であるキーを表す.
- (M)とは,フィールドがマルチバリューであることを表す.
1テーブル内のマルチバリューにおいて,同色のものは水平方向に同期するものを表す.
マルチバリュー部分に若干の妄想が加わっているのは,そこまで詳しくないからです・・・お許しを.
(本来これらのテーブルはOracleで実装されているため,マルチバリューにはできない.)
さあどうした?かかってこい!!「さあ4DDAMの説明はこれからだ!!お楽しみはこれからだ!!ハリー!ハリーハリー!!ハリーハリーハリー!!!」
■さらなる具体例
今回の具体例は,4DDAMでの計算式をカラムに埋め込んで説明する.
冒頭でIBMのTrans関数を紹介しているが,あの関数は他のテーブル内容を自分のテーブルにデータを引き込む関数になっている.そのため,頻繁に使われる.
その関数を今回具体例として紹介(説明?)する.
下記の図のように,カラム名として項目名・フィールド識別・項目内容の3種類を提示している.
項目名:本来英名としてカラムが設定される.
フィールド識別:物理フィールドか仮想フィールドかを設定する.
項目内容:物理フィールドであれば連番が振られていく.仮想フィールドであれば式が設定される.今回はTrans関数を用いる.
・TRANS(H_TRADE_LIST_ST, TARGET_H_TRADE_LIST_KEY, YKJ_PRICE, 'X’) について
第1引数:H_TRADE_LIST_STテーブルをアカウント内から探す.
第2引数:TARGET_H_TRADE_LIST_KEYをテーブルの中から探す.
第3引数:第2引数のテーブル内からYKJ_PRICEカラムを探し出し,終値一文高関与抽出データ-株式テーブルの終値カラムに表示する.このとき,値が設定されていなければ,空白を設定する(上記のURLを参照すれば分かると思うが,第4引数を説明している).
今回は,仮想フィールドを1回のみ参照しているため分かりやすいが,さらに仮想フィールドを参照し,さらに仮想フィールドを参照し・・・と数回以上たどる状況も発生する.そうなってしまった場合発狂以外の感情はわかない.
これほどまでに改修作業はコストが掛かる.
東証はそれを把握できていないため,コストに掛かる金を出し渋って契約をしなかった.
通常のDBであれば,あり得ない挙動あるね.
参照方法例:select 第3引数 from 第1引数 where 第2引数 = 参照テーブル.@ID;
此処までの説明を確認すれば分かるとおり,終値一文高関与抽出データ-株式テーブルの終値カラムの表示値を変更したい場合は,約定データ-株式テーブルの値段カラムを変更しなければならない.
また,UniVerseの配列という概念がやっかいで,Trans関数を利用するときに足を引っ張る存在になっている.
この配列は2種類存在し,ダイナミックアレイと次元配列というのがある(片仮名と漢字の名前が気になる).
配列を区切るときのマークが5種類存在し,フィールドマーク(F)・バリューマーク(V)・サブバリューマーク(S)・テキストマーク(T)・アイテムマーク(I)とある.
※下図(表)は,IBMのLOWER関数の説明ページを引用している.
このマークは,上記の集合関係で図示した区切りになっている.
Trans関数を用いたときに,このマークが格下げされる.
そのため,Trans関数で他テーブルから値を抜き出したときに,格下げされたマークを格上げしなければならない.
非常にやっかいな仕様になっており,またまたこの仕様も知っている人がおらず,てんやわんやした.
ちなみに,LOWER関数で格下げを任意に行える.そして,格上げにはCONVERT関数を用いる.
LOWER関数:http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_8.7.0/com.ibm.swg.im.iis.ds.basic.doc/topics/r_dsbasic_LOWER_function.html
CONVERT関数:http://www.ibm.com/support/knowledgecenter/ja/SSZJPZ_8.7.0/com.ibm.swg.im.iis.ds.basic.doc/topics/r_dsbasic_CONVERT_function.html
CONVERT関数の使用例
CONVERT(@SVM, @VM, TRANS(H_TRADE_LIST_ST, TARGET_H_TRADE_LIST_KEY, SELL_ORDER_PRICE, 'X'))
⇒TRANS関数で他テーブルのカラム値を取得した値に対して@SVMを@VMに置換する.
@SVM:サブバリューマークのことで@VMに格納されている文字列.
@VM :バリューマークのことでフィールドマークに格納されている文字列.
■今更ながら4DDAMとは
今回投稿するに当たって記事を作成していたのだが,まだまだ4DDAMとは何かを理解していない部分が大きすぎで概要すら把握できていないことを自覚できた.
そもそも何も教わらないまま時間だけが過ぎたため,理解している方があり得ないのだが・・・.
なにより,4DDAMで数千万単位の件数を扱う時間を短くしても他のシステム(Oracle・エクスポート・Java・JP1)との連携で遅くなってしまえば,意味が無いように思う.何より他のシステムを使うならば,4DDAMで処理する意味がないようにも思うし・・・.
約定部分だけを早くしたいのであれば意味ありげだが・・・そうではないし・・・何より約定部分はメインメモリに保存するって・・・.
他にも色々言いたいことはあるが,本文より愚痴の部分だけで長文になってしまったため,切り上げることにする.
むしろ,DB反対になっていないように思うため,次回を作らねばならぬようにも思うが・・・.
きっと次回はない.やりたいのだが,それどころではない・・・それがたとえ那由他の彼方でも俺には充分すぎる!!
SQL諸君,任務ご苦労.さようなら
Advent Calendar 2016に参加したかったが,SQLの流れに乗りたかったため急いで作成した.
以上.
追伸.
過去にセミナーがあったようだ.
http://www.keyman.or.jp/sm/50046617/
http://www.csaj.jp/memberinfo/eventseminar/2012/120608_4dn.html
https://event.atmarkit.co.jp/events/2d56ffc98f630b9427a8c72cfb71b2e8
https://event.atmarkit.co.jp/events/e7c52d33b187d9064d3fcdc002010cc3