最近,時代遅れのDB論理設計の流れが取りざたされている.そのため,私にDBの知識は無いが,DB利用反対を表明しようと思い,今回投稿する.
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
まず,いかにDBの知識が無いかをさらそうと思う.
以下の4ステップとして無知であることを説明する.
無知をさらすためだけの投稿により,まとめは当然無い.ポイントをまとめることもない.
しかし,無知だけをさらすのは恥ずかしいため,知っていることをチラッとだけひけらかそうと思う.世の中の役に立つまいが.
ステップ1:エンティティとは.
エンティティを実体と訳すようだ.
実体を考えながらDBを作成する必要があるのだろうか.
時間の無駄にしか思えない.
思いついたモノを片っ端に作ればいいと思っている.何より,事前に考えるのは脳みそが付いていかないため,不可能に近い作業だ.
ゆえに,今回のステップでは,訳しただけで終わる.
踏み込むのはナンセンスだ.
ステップ2:エンティティの何を定義するのか.
エンティティ(実体)を構成するために,テーブル単位にまとめる必要があるようだ.
逆に言えば,同種を1つのテーブルにまとめると言うことだろう.
リンゴやバナナであれば,果物テーブルを想像すればいいのだろうか.
そんなものを考えつく人が羨ましい限りだ.
しかし,果物に必要な存在は分かる.それは私だ.捕食者がいなければ,果物の存在理由は無いからな.
ゆえに,果物テーブルの中に私が存在して問題ない.この私をあるじ(主キー)と言うべきだろう.そして,私が手に入れた下僕(果物)は誰にも渡さないため,外部キーは存在しない.
1人しかいないのだから1テーブルだけで事足りる.
誰が食事をするのかが主キーになっていれば問題ない.
外部キーを設定するのはナンセンスだ.
ステップ3:正規化とはうまいのか.
果物を想像したらお腹が空いてきた.
正規化を行えば,満腹になるとでも言うのだろうか.
まったくのナンセンスな名前に思うのだが・・・.
せっかく,私が果物を独り占めにできたのだから,わざわざテーブルを分ける必要は無い.
むしろ,食べ物は果物だけではない.
1つのテーブルに肉や野菜も追加すれば,1つのテーブルを参照するだけで事足りる.
分けるのはナンセンスだ.
ステップ4:ER図とは新たなビデオゲームか.
食事をしたら運動しなければならない.
ER図とは新たなビデオゲームの名前だろうか.
図でテーブルを表す暇があるならば,テーブルに詰め込めるだけ詰め込む方が楽では無いのか.
テーブルの作成以外に時間と労力を費やすのはナンセンスだ.
知っていること:無知の知・・・とは言わないか.
なぜ,上記の4つのステップを知らないままなのかを説明しようと思う.
そもそもDBとは,データベースのことであり,ドラゴンボールのことではない.
もっと言えば,データベースマネジメントシステム(DBMS)と言い,
データベースは大量のデータを系統立てて保管することができ、必要に応じて検索、抽出、加工することができる
ことを指す.
データベースとは|database|DB - 意味 / 定義 : IT用語辞典
上記でも述べたが,DBとはDBを扱う前にDBを使う準備が万全に出来ていなければ使えないと言うこと.一言で言えば,目的が無ければ使えないと言うこと.
上記の果物を例に出したように,突然肉や野菜の区分を果物テーブルに追加できないと言うことになる.もし,追加するのであれば,肉用のテーブルや野菜用のテーブルを作成しなければならず,それらのテーブルに紐付けるための外部キーを事前にメイン(果物?)テーブルに追加しておかなければならない.
自分で説明しているはずなのに,混乱するような説明になって申し訳なく思・・・わない.
なぜなら,DBが遺物だからにきまっている.
もし,DBを運用する上で,野菜テーブルではなく,テーブルという名前で果物カラムが有り,ひょんな事で肉や野菜の項目を追加できるとしたらどう感じるだろうか.もちろん,稼働を止めること無く追加できるとしたら素晴らしいと思わないだろうか.しかも,無限に行を追加でき,そのカラムの中にどのような値でも入れられるとしたら夢のようではないだろうか.
もちろん,追加したからには検索も可能だとしたら失禁ものだろう.
その夢のDBをこれから説明しようと思う.読み終えて失禁しないでくれよ.
今回核になっている技術は,IBM UniVerseのはずなのだが,頻繁にURLが変わるようで,昔のリンクが役に立たない.
そのため,画像だけを貼り付ける.もし,運がよければ,サイトにたどり着けるでしょう.
IBM Knowledge Center - UniVerse データベースおよび UniData データベースへの接続
IBM Knowledge Center - IBM UniVerse と UniData
検索ワードのヒントはInfoSphere DataStage and QualityStageのBASIC言語に近しいはずなので,それらしい言葉で検索すれば出てくると思われる.
見つけた.
IBM Knowledge Center - TRANS 関数
IBM Knowledge Center - Deffun ステートメント リンク切れ
IBM Knowledge Center - FUNCTION ステートメント
IBM Knowledge Center - REM 関数 リンク切れ
■エンティティを考えるのが不要の理由
通常のDBでテーブルを考える場合,正規化などを考慮することにより複数のテーブルやキーなどを用いながら,さらにテーブル同士を紐付けることで必要なレコードを取得することだろう.
それがナンセンスという.
1つのテーブルに主キーを決めたら,それ以降の項目やレコードを無尽蔵に作成した方が利便性が高い.
主キーを識別用以外に使わない - Qiita
例えば,1レコード目の2カラム目を無尽蔵に増加させたり,3カラム目以降を追加できれば,使い勝手がよくならないだろうか.
考える作業が不要になる.そして,欲しい情報があるならば,検索をかければいい.
■正規化を考えるのが不要の理由
上記でエンティティを考えるのが不要と説明した.
無尽蔵に追加できるため,正規化すら不要になる.
無尽蔵に追加できると言うことは,記入箇所を選べると言うこと.DBの場合は、穴を作れない(上記画像のような作成は不可).しかし、今回作成できるのは、エンティティだからだ.
「俺」の果物が1つに,肉が3つに,野菜が4つなのは,好みの問題だから.
逆に「僕」は果物が4つに,肉が3つ,野菜が1つでも問題ない.それが個々人の好みだからに他ならない.
検索をしたときの戻り値が何もない場合どうすればいいのかと言えば,そのときに応じて決めればいいだけになる.
例えば,肉を検索したときの結果に,2つ以上ない場合野菜の結果を出せばいいだろうし,野菜が不要なときは果物で構わないし,それも不要であれば「なし」で構わない.
この臨機応変な対応は,DBではできない.もしやる場合は,DBから値を引っ張ってくるときのプログラム側で対応する必要がある(非常にめんどくさいだろう).
検索値を設定すればどのようなDBでも対応可能だと思うかもしれないが,その設定すらめんどくさいと思う場合エンティティではどうすれば良いのだろうか.
この検索値をExcelのセルに計算式を埋めるようにカラムを事前設定すればいいだけのこと.
そのカラムの参照だけで検索結果が得られるため,開発時に楽が出来るだろう.
下図で言えば,右端のカラム1つだけで事足りる.左端の捕食者も必要だが.
■エンティティや正規化を考えた場合
意味のある塊ごとにテーブルを作成したい場合も可能なのは当たり前だと思う.
その場合も1つのカラムで複数のテーブルを参照可能なのは変わらない.
また,列に属性を持たないため,此処のカラムに数値や文字列を持たせることも可能になっている.
どのような文字コードでも扱えるかもしれないが・・・今回はシフトJISを用いることにする.外字は扱わない(それが現場の方針だから).
仮想テーブル(一時テーブル)ならば,対応可能かも知れないが,プログラム側で対応しなければならない(DBとは直接関係なくなる).
■夢のDBとは
ここまでの説明で,夢のDBが何を指すのか気がついたことでしょう.
東京証券取引所(通称東証)が採用している4D DAMというマルチバリュー以外に思い浮かばなかったはず.そう,DBではない.想像しやすいだろうと言うだけで,全然無関係の劣った名前を用いていたに過ぎない.
株式会社東京証券取引所 | 日本取引所グループ
いままでの常識をくつがえす! 超速データベース 「4D DAM」を発表 - フォーディーネットワークス株式会社のプレスリリース
「4D DAM」を提供開始 | 4D Networks リンク切れ(東証で採用されたことがなかったことになっている)
4D Networks, Inc. | Facebook
東京証券取引所に採用された4D DAMデータベースとRocket Software社のUuniverse - 阿部ブログ
株式会社八雲ソフトウェア
AIDAM (エーアイダム)ハイパフォーマンスソリューション - 提供サービス - Sparkle 株式会社スパークル
4DDAM リレーショナルでも、オブジェクトでも無いデータベース
— MasahiroNishikawa (@alfaindian) 2011年1月18日
30年以上前のPICOSが原型。東証の不正取引検索システムに採用され稼働中とのこと
http://www.4dn.co.jp/product/4ddam/index.html
株情報に関するデータウェアハウス - ビッグデータロボ株式会社
東京証券取引所、不正な取引を発見で「Informatica PowerCenter」を採用 - インターネットコム リンク切れのようだ
4DDAM - 片貝孝夫の IT最前線 (Biz/Browserの普及をめざして)
東証1部上場銘柄の名前と証券コードを取得する - Qiita
PDF: https://www.4dn.co.jp/wp-content/uploads/pdf/4DDAM090527.pdf
・その他URL
TOPIX Core30, Large70, Mid400, Smallの構成銘柄かどうか調べたりするクラスを作った - Qiita
製品の評価(用途の見極め、使い勝手、性能など) | 杉浦技術士事務所 (情報工学部門) ドメインごと存在しない
売買審査の状況 | 日本取引所グループ
03市場を守るための曲げない使命 - 株式会社 日本取引所グループ 採用情報サイト2016
PDF: http://www.ndl.go.jp/jp/diet/publication/issue/0496.pdf
PDF: http://www.kogi.co.jp/pdf/oshirase/110-150108.pdf
PDF: http://www.jast.jp/pdf/20050518kaizen.pdf
[TensorFlowで株価予想] 4 - 実際に売買したら儲かるのかシミュレーションしてみる - Qiita
はじめてのMongoDB - Qiita リンク切れ
・マルチバリューの4DDAM
私は2014年の1月と2月にスモールティック修正案件に関わっていたが,その数ヶ月後に名称変更だ.
高速データベース「4D DAM」の製品名変更のお知らせ | AIDAM,製品情報 | 株式会社エイ・エス・シー
残念だ.
しかし,今回は旧名称を用いることにする.呼び慣れている名前を使いたいからと言う個人的な欲求なのだが・・・.
ちなみに,新名称は「AIDAM」と言う.
4DDAMに関わっていたときの案件は,株価3千円以上の価格帯について,呼値の単位を見直し,Topix100に限定して,小数点対応をするというもの.
すでに2010年ごろの東証は次世代株式売買システム「arrowhead」を導入していたのだが,今回の改修作業で次期株式売買システム(arrowhead リニューアル)として刷新されることになった.
東証が9月にアローヘッドをリニューアルへ
事例:東証、実利追求でプロジェクト遂行 Part01 | IT Leaders
PDF:http://www.itrade.co.jp/-/raw/34/3351/24697/5/16/20140806.pdf リンク切れ
時代はオープンソースソフトウェアから“オープンソース”へ──The Linux Foundation「Enterprise User's Meeting 2013」レポート:レポート|gihyo.jp … 技術評論社
取引所のグランドデザインと課題 | 日本電子計算株式会社
オープンソースのシステムを一部流用しているようで,東証のシステムに用いたオープンソースの流用方法を社内でのみ展開していた.インターネット上に展開していないため,意味ある宣言なのか疑問だったが,世界に名を連ねるシステムなので,問題ないのだろう.
私もオープンソースを流用して,世界に注目されたいと思っている.
そのためにも4DDAMについて詳しくなりたいと思った.
■改めて4DDAMとは何かを説明する.
実際のところよく分からない.
そもそも東証システムの一部とは言え,株の取引を行うシステムとは無関係の立場になっている.
私が関わった4DDAMの役割は,arrowheadの株売買終了後に,取引データから不正行為が無かったかを調べるためのシステムになっており,通称Artemisと呼ばれ,売買監視表・基準抽出・未然防止・バスケット・指数急変動の手法で審査を行う.
しかし,分かっているのはそれぐらいで,4DDAMとは何かを把握できないままで終わった.かなり急ピッチな期間だった.
そして,UIの部分はJava言語を使っていたため,ブラウザ上で試験を行う.
例:http://172.22.175.204:9080/ArtemisWebApp/Login.jsp
値動きのシミュレーションも出来るようで,素晴らしいらしい.
■名前のこだわり
上記の例で示したとおり,カラムの中に式を埋め込めるため,入力値と出力値が絶対に一致しない.
そして,上記の例で示したとおり,条件式をカラムに埋め込んでいるカラムを仮想フィールドという.
このフィールドは,2種類あり,物理フィールドと仮想フィールドの2つだ.
マルチバリュー - Wikipedia
Pick Operating System - Pickwiki
Pick operating system - Wikipedia
東証の開発現場では,レコードではなくitem(アイテム)と言い,フィールドではなくattribute(属性)と言った.
しかし,仮想フィールドや物理フィールドとも言うのだから混乱していた.
■手頃な箇所
AndroidOSに用いられているSQLiteは,利用データをテキストファイルに保存できることで有名だ.そのため,知識さえあれば,バイナリエディタでデータを書き換えられることだろう.
sqlite最低限の覚書(Mac) - Qiita
sqlite メモ - Qiita
SQLiteのdbにファイルを保存する方法 - Qiita
AndroidでSQLiteはどこまで書くものか - Qiita
SQLite3 チートシート - Qiita
Sqlite で全文検索 - Qiita
SQLite - Wikipedia
Android Tips(19):SQLiteデータベースの基本操作 (1/2) - MONOist(モノイスト)
Androidアプリのデータ保存方法の一つ「SQLite」の使い方 SQLiteOpenHelper編 | mucchinのAndroid戦記
SQLite を簡単に扱うための DB アダプターの実装 - Android 開発入門
その他のURL
AndroidのSQLiteの面倒臭いを簡単にする - Qiita
sqliteからpostgresへの移行 - Qiita
SQLite3の旧データベースをMongoDBへ引っ越し - Qiita
個人的によく使うMySQLとSQliteの対応メモ - Qiita
SQLITEにて混乱したこと。 - Qiita
MySQLをSqliteに変換する。 - Qiita
まだSQL(SQLite)直書きで消耗してるの? - Qiita
しかし,4DDAMは違う.
核になる部分を除けば,アカウントごとディレクトリ構造で保存できる.
例えば,WindowsOSを端末にインストールしたあとに,WindowsUpdateを実行してから,OSごと丸ごとバックアップを取るような想像をしていただければいいだろう.そのバックアップデータを使って,複数の端末にOSをインストールしていけば,インフラチームとしては楽が出来るはず.
それと同じように,他の人が設定した内容やデータを丸ごと保存できることで,使い回せるだけでなく,全く同じ環境を再現でき,作業をスムースに進めることも大きな特徴になっている.
それらの設定は以下の構造になっている.
(SQLiteは,テキストファイルでデータ管理している.4DDAMはディレクトリ単位で管理している)
便利なのはいいのだが,足かせはライセンスの問題がある.
上記の例として,WindowsOSのバックアップデータを使い回すのは,それなりのライセンスがあったはずなので問題ないと思う.
私が関わった4DDAMのライセンスは,CPU数だったため,4アカウント分のみ契約していたようで,8人以上いるのに4人しか使えない.
実に残念だった(べらんぼうに高価だったのだろう).もしかしたらCPU数では無かったかも・・・かなりうろ覚え.
いままでの常識をくつがえす! 超速データベース 「4D DAM」を発表 - プレスリリース - ビジネスEX ドメインごと削除されている.
4D DAM VS ORACLE 価格のIT製品 IT関連情報【キーマンズネット】
(価格に関して情報が無い.残念だ.)
■具体的なSQL文
NoSQLとは:NoSQLについて勉強する。 - Qiita
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以上のテーブルを要する場合,物理フィールドなのか仮想フィールドなのか判断が付かないため,人海戦術で確認しなければならない.
そのため,ほんの少しだけの修正を加える場合も例外ではなく,すべてのテーブルを見直す必要があり,全てのテーブルに対して試験を行わなければならない.
東証はそれを把握していないため,少しの修正なので少しのテスト範囲に収められると思い込み,提示契約を破棄した.ゆえに,私は存在しない契約を契約通りにこなす必要に迫られ,用事があるとリーダに伝えたのに「仕事だから」の一言で休出を強要されたこともあった.
1/25(土)に出社した今となってはいい思い出だ.休出を指示したリーダは,いつも通り寝坊で遅刻したため,仕方ないためいつも通り共連れ入館した(休出は人の出入りが少なくて苦労した).
世間に出回っていないDBを使うなと言うことでしょう.
ゆえに,いまでは4DDAMの採用を取り消して,オープンソースのDBに置き換えているはず・・・きっと.ゆえに,4DDAM提供会社のホームページから当省に採用された記事を削除しているのだろう.
その置き換えを早い段階で行ってくれていれば,東証は契約を行い,約束通りに緩やかなスケジュールで人員を確保した作業だったのに…
上記の説明で簡単そうな夢のDBとほざいてしまったが,保守作業は膨大なコストが掛かる.
RDBMSとNoSQLの違い⇒勉強会ノート(150626) - Qiita
NoSQLは 〜省略〜 シンプルな構造でデータの正確性はない。それではどうするかというと、アプリケーション側の実装でカバーするしかなく、それはとても大変なコストがかかる
他の参考サイト
各種DBシステムの概要 RDBMSとNoSQL - Qiita
MongoDBでビッグデータと遊んでみた - Qiita
NoSQLの調査まとめはじめ - Qiita
熟練者で無ければ保守できない.その仕様などはボソボソ説明していく.
上記で,全てのテーブルに対して試験をするような話を出したが,有識者(熟練者?)であれば,必要最小限に抑えられたのでしょう.
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:「NoSQL」とCouchbase - Qiita
具体的なSQL句で@IDなどを出したため,今までの例を全て破棄して,本来の表記方法を行おうと思う.
- @IDとは,テーブル内において一意な主キーを表す.
- 〜idとは,集合内において一意であるキーを表す.
- (M)とは,フィールドがマルチバリューであることを表す.
1テーブル内のマルチバリューにおいて,同色のものは水平方向に同期するものを表す.
マルチバリュー部分に若干の妄想が加わっているのは,そこまで詳しくないから・・・お許しを.
(本来これらのテーブルはOracleで実装されているため,マルチバリューにはできない.)
■さらなる具体例
今回の具体例は,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関数:IBM Knowledge Center - LOWER 関数
CONVERT関数:IBM Knowledge Center - CONVERT 関数
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反対になっていないように思うため,次回を作らねばならぬようにも思うが・・・.
きっと次回はない.やりたいのだが,それどころではない・・・.
Advent Calendar 2016に参加したかったが,SQLの流れに乗りたかったため急いで作成した.
以上.
追伸.
過去にセミナーがあったようだ.
【4D DAM 評価版無償配布】有償実践トレーニングのご案内 - IT、IT製品の情報なら【キーマンズネット】
超高速マルチバリューデータベースエンジン「4D DAM」事例紹介セミナー
【無料】超高速マルチバリューデータベースエンジン4D DAMご紹介セミナー | イベントカレンダー+ログ
超高速マルチバリューデータベースエンジン 4D DAM ご紹介セミナー | イベントカレンダー+ログ