ディメンショナルモデリングでアクセス分析のファクトテーブルをどう設計するか
風音屋では、データエンジニア、データアナリスト、データコンサルタントを募集しています。 書籍執筆者やOSSコントリビューターなど、業界を代表する20名以上のアドバイザーと一緒にベストプラクティスを追求できる環境です。 ぜひカジュアルトークをお申し込みください。 こんにちは、風音屋 データエンジニアの妹尾です。 この記事は、datatech-jp Advent Calendar 2023 15 日目の記事です。 ディメンショナルモデリングを採用する場合、アクセスログやGA4のファクトテーブルは、どのように設計すれば良いのでしょうか。 この疑問について風音屋でディスカッションをしました。 本記事では、ディスカッションした内容をご紹介します。 社内ディスカッションの様子 ディスカッションの様子 アドバイザーの皆様の協力もあり、課題を整理し、対応方針を洗い出すことができました。 @tvtg_24さ
Snowflakeパフォーマンスのカギはやっぱりデータモデリング
この記事はSnowflakeアドベントカレンダー2023の19日目です。 はじめに 昨年、Snowflakeのパフォーマンスにおいて非常に重要な概念であるクラスタリングとプルーニングに関して、以下の記事を書きました。 なぜクラスタリングやプルーニングが大事なのかを説明させてもらったのですが……理屈はわかった！ではどうすれば？という、具体的なユースケースについて全く書けておらず、また別のブログにします、と宣言しておいて、1年間完全に放置してしまっていました。すみません。。 この記事では、上記の記事の続きとして、クラスタリング・プルーニングの概念を知ったうえで、具体的にパフォーマンスを向上させるにはどうすれば良いかのヒントとなるようなものを書きたいと思います。 具体的には、そうデータモデリングです！ データモデリング万能説 データモデリングがめちゃくちゃ大事だよ！ってことは、SnowVilla
Modeling by Verb
セイコーエプソン株式会社、萩原豊隆さんによる、新しいモデリング手法、 「動詞de!! モデリング�」のプレゼンテーションです。 ・ソフトウェアの振る舞いは動詞で表現できます。しかし今までのモデリング手順では、“動詞”を適切に扱えませんでした。例えば名詞つまり目的語に着目する一方で、付随する動詞を無視して振る舞いを漏らす。あるいは「○○制御」クラスのように振る舞いがすべて“制御”という言葉に隠れてしまう。いずれも動詞の取り扱いのまずさに起因します。 ・そこで目的語と共に動詞も同時にクラス図へ変換する手法を作りました。モデリングツールを使って、目的語と動詞の組み合わせをサクサクとクラス図に変換していきます。クラス図の良し悪しは読み上げて確認です。単純かつ明快なので誰もがセンスに依存せずにモデリングできるようになります。Read less
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
「これだけ」モデリング - Qiita
これだけモデリングとは 「これだけモデリング」とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング（slideshare） これだけモデリングとは、 誰が？ ー 情報システム部門の
astahによるモデリングのメモ - プログラマの思索
「ドメイン駆動設計」を読み直すようになってから、UMLによるモデリングをもう一度見直している。 アイデアをラフなメモ書き。 【参考】 オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索 astah* professional 6.1の要求図: プログラマの思索 SysMLの要求図の書き方: プログラマの思索 シーケンス図とアクティビティ図と状態遷移図の関係: プログラマの思索 FP法で業務モデルを計測する: プログラマの思索 【1】僕は、UMLの各種ダイアグラムを、業務やプロセスやシステムの分析のラフなスケッチに使っている。 業務の流れ、プロセスの流れ、システムの振る舞い、システムの機能の関係を理解したい時、絵を描く方が、理解が早まる。 基本は手書きが多い。 でも、astahで描いておくと、後から何度でも修正変更できるし、ブラッシュアップできる。 UMLの利点は、1
要求開発にて”「これだけ」モデリング”：An Agile Way：オルタナティブ・ブログ
これだけモデリング！というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 （※6/5 追記： 以下に、当日の資料を公開します。） これだけモデリングとは、 誰が？ ー 情報システム部門の人（と開発の人が共に） いつ？ ー システム開発の前段階、すなわち「要求開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルにモデリングは必要か
ドメイン駆動設計入門