dbtでJinjaを利用して柔軟なデータモデルを開発する | DevelopersIO
大阪オフィス所属だが現在は奈良県でリモートワーク中の玉井です。 dbtは、ELTのTをソフトウェア（またはアプリケーション）と同じように開発することができるサービスです。しかも、SQLのSELECT文さえ分かっていれば、もう早速使うことができてしまいます。 ただし、SQLはいわゆる宣言型言語で、柔軟なデータモデルを作るためには限界があります。そういう時のために、dbtはjinjaという言語が使えるようになっています。 今回はjinjaのチュートリアルを「実際にやってみつつ」、どういう事ができるかをご紹介したいと思います。 そもそもdbtとは？という方へ 下記をご覧ください。 Jinjaに関する公式情報 本家 dbt 本記事では下記に記載されているものを実際にやってみます。 やってみた Projectを新規作成する 今回の作業用に新規Projectを用意します。具体的な方法は上記の別記事をど
イミュータブルデータモデル(入門編)
6. Step1 エンティティの抽出 発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が あれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。 間違い！ この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。 まず、はじめにエンティティを抽出します。
テーブル関連の「排他性」をモデル上で表現する - 設計者の発言
どんなに複雑に見えるデータモデルでも、テーブル関連には親子関係、参照関係、派生関係の３種類しかない。ただし、それぞれの関連には排他的なものとそうでないものがある。これを見かけ上区別できるような工夫を紹介しよう。ここらへんを理解しておけば、データモデリングのスキルがワンランクアップする。 まず、参照関係の例を見よう。あるテーブル(B)に置かれたレコードが、別のテーブル(A)上のレコードに対して対応関係を持つとする。このとき、B上のAへのアクセスキーが、B自身の主キーに包含されていない場合、両者の関係を参照関係という（図１）。この場合、B側のテーブルを「参照元」、A側を「参照先（被参照）」といい、B側のアクセスキーを外部キー（または参照キー）と呼ぶ。 図１ ここで、BがAの他にA'の間にも参照関係を持つとしよう（図２）。ここで、BがAとの対応を持つときはA'との対応を持たず、A'との対応を持つ
アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人数ではなく技能を確保するためのシフト管理システム公開 - 設計者の発言
