タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
データをシリアライズするには、独自のフォーマットを定めるよりも、基本的な定義済みの構造を組み合わせてフォーマットを作るほうが望ましい場合が多いです。 そのような仕組みとしてJSON, S式, XMLなどが存在しますが、これらは 「基本的な構造」として何を選ぶか、という観点からそれぞれに個性を持っています。 本記事では、具体的な構文のことは基本的に忘れて、各フォーマットが採用するデータモデルの違いに焦点を絞って比較します。 JSON data JSON = Value data Value = -- Compounds Array [Value] | Object (Map String Value) -- Scalars | Null | Boolean Boolean | String String -- UCS-2 | Number IntegerOrFloat -- no NaNs
Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes�to Achieve Both Frequent Updates and Stability
データ構造をimmutableにしたい、イベントは起きたことをそのまま記録したい、更には監査の観点から修正させたくない、という人類の夢と希望に対して、「だってそれじゃあ現場は回らないんだよ」という例外運用のバランスをどこで取っていくか？というのは昨日・今日出てきた話ではないんですよ— magnoliak🍧 (@magnolia_k_) 2021年11月28日 所謂、業務システムの設計の一番肝心なところって、「起きた事実をありのまま記録する」っていう要件と、実際の運用がそうなっていない現実との戦いなんじゃないかって みんなそうしたいんだよ、でもできないんだよっていう— magnoliak🍧 (@magnolia_k_) 2021年11月28日 「データを活用しよう」って言い出しても、「活用できるように維持していましたっけ？」みたいな話も同じなんだけど、とにかく例外との戦いなんですよ— m
データモデルKata - kawasima
社員は退職しても別のイベントデータと関連付けされているので、消せないことが多いでしょう。ただ氏名等個人情報に関わるものは持たないようにしなくてはならないので、サブタイプで区別します。
データモデルをチームメンバーに共有する時に TypeScript の型定義風にしている話(お試し中) - Thanks Driven Life
SmartHR Advent Calendar 2020 の3日目です。 本記事の概要 最近、テーブル定義をチームメンバーに共有する時は Rails migration のアレではなくて TypeScript の型定義で表現するようになりました。バックエンドエンジニア以外への配慮というよりも(それも少しはあるけど)、自分自身がよりイメージしやすいからというのがあったり無かったり。— Wataru MIYAGUNI (@gongoZ) 2020年9月7日 例えばこういう感じでテーブル設計(物理データモデル)したものを エンジニア含めデザイナーやプロダクトマネージャー(以下、PdM)に共有する論理データモデルは、以下のように TypeScript の型定義風にして共有するみたいなことをやってみている、というお話です。 type UUID = string type Book = { id: U
WBCが楽しかったので、野球のペナントレースを表すデータモデルを考えてみた。まずは基礎となる球団や選手、およびそれらの年次成績（年次サマリ）の関係を見てほしい（図１）。 図１．基本情報のデータモデル 年次サマリには「セパ別年次サマリ」、「球団別年次サマリ」、「選手別年次サマリ」の３種類あるが、これらのうち「選手別年次サマリ」の主キーが｛選手№＋年｝ではなく｛選手№＋所属開始日＋年｝となっている点に注意してほしい。この主キーは「所属球団」の主キー｛選手№＋所属開始日｝に＜年＞を複合させたものだ。これはシーズン中の移籍にともなって成績がリセットされるためである。つまり、選手の年間成績は「所属球団」を年で展開した定義域に関数従属する。 ３つの年次サマリには集計項目（カッコ付きは論理フィールド*1であることを示す）がいくつか載っているが、その集計過程を説明しよう。「セパ別年次サマリ」上の＜試合数＞
２つのテーブルをExcelデータモデルに追加してキューブ関数でデータを取り出す【MOSエキスパート2016】 - わえなび ワード＆エクセル問題集 waenavi
以前からMOS試験（ExcelのExpertレベル）ではキューブ関数が出題されていますが、全国にある試験会場からキューブのサーバに接続することはできないので、デモ画面（仮想の画面）で出題されていました。 しかし、Excel2016の試験では出題傾向が変わり「Excelデータモデル」からデータを取得する問題しか出題されなくなりました。そのため、キューブ関数が何の役に立つのか、何が便利なのかが全く分からない試験問題になってしまいました。しかも、問題に使われるExcelのファイルにはすでにデータモデルが設定されていて、そこからキューブ関数でデータを取り出すことだけが出題されるため、対策テキストの問題を解いても理解できない受験者が多いようです。 そこで、テーブルをデータモデルに追加して、キューブ関数を使うまでの一連の流れを解説します。この作業はMOSには出題されませんが、キューブ関数を理解する上で
Amplify & GraphQLでのデータモデル設計事例集 - BioErrorLog Tech Blog
AWS Amplify & GraphQLでのデータモデル (スキーマ) 設計例をまとめます。 はじめに スキーマ設計例 Todoアプリ イベントアプリ チャットアプリ Eコマースアプリ WhatsAppクローン Redditクローン マルチユーザーチャットアプリ インスタグラムクローン カンファレンスアプリ おわりに 関連記事 参考 はじめに こんにちは、@bioerrorlogです。 最近、AWS Amplifyに注目してします。 Amplifyはフルスタックなサーバレスアプリを素早く作ることが出来るプラットフォームで、プロダクト開発の生産性を高めることが出来ます。 AmplifyプロジェクトのAPIを GraphQL (AppSync)で構築するときには、データモデルをスキーマschema.graphqlに定義する流れになります。 このGraphQLのスキーマ設計はリレーショナルデー
— 脱RDB脳 — Cassandraのデータモデルについて考えてみる | フューチャー技術ブログ
はじめにこんにちは、Technology Innovation Group所属 DBチームの岩崎です。 私はDBチームとして様々なプロジェクトでOracleやPostgreSQLなどRDBの設計・構築に携わってきました。 現在は、Cassandraの導入とデータモデルを設計しています。 本稿ではDBネタとしてRDB脳から脱却して、KVSならではのテーブル設計の勘所をお伝えいたします。 CassandraはどのようなデータベースなのかCassandraはKVS(Key-ValueStore）と呼ばれ、KeyとValueを組み合わせる単純な構造からなるDBです。 データアクセスはkeyに対して行い、Keyに関連付けられたValueが呼び出されます。 KVSは一般的にスキーマレスを採用することが多いと思いますが、Cassandraではアプリケーションの観点から見て、データは構造的に扱える方が開発
はじめに ～概念・論理・物理データモデルの分け方～ こちらの記事『3分間でわかるデータマネジメント【データモデリング】』では、DMBOKにおける概念・論理・物理データモデルの違いを紹介しました。しかし、同記事でも書きましたが、実際のところ概念・論理・物理の考え方は人によってまちまちです。本記事では参考までに、データ総研で採用している、3層スキーマをもとにした概念・論理・物理データモデルの分け方を紹介いたします。 また、データ総研では概念データモデルを描く際、詳細度に応じて3種類の記載法を使い分けています。それぞれについて、概要や用途をご説明します。 概念データモデルの関連資料ダウンロード 概念データモデルにおけるエンティティの適切な配置ルールを解説する資料をダウンロードいただけます。 こちらの配置ルールは、EDW(Enterprise Data World)というデータマネジメントの海外カ
dbtで作成したデータモデルをそのまま可視化に使えるBIツール「Lightdash」を使ってみた | DevelopersIO
大阪オフィスの玉井です。 今回は、dbtにネイティブ対応しているBIツールを紹介します。 Lightdashとは 名前の通り、ライトなBIツールなのですが、接続先がDWHではなく、dbtプロジェクトなのが特徴です。 dbtを使う理由の1つに、BIツールで分析しやすいデータを用意する、というものがあると思います。普通は、dbtを通してDWH上にできたテーブルやビューを、別途BIツールで接続して利用します。しかし、Lightdashは、DWHを介すのではなく、直接dbtのコードを利用して可視化を行います（裏側としては、dbtのコードを利用して、dbtの後ろにあるDWHにクエリを実行するようになっています）。 やってみた 今回はローカルで試します。OSSなので無料です（有料版については後述）。 環境 macOS 11.5.2 dbt CLI 0.20.1 docker 20.10.8 dbtを接
はじめに Power BI 勉強会 GW合宿 2022 第弐夜での発表内容です。 https://powerbi.connpass.com/event/246427/ Power BI "で" 可視化しよう！ 通常はこういう文脈で語られることが多いかと思います。 データを整備して、モデリングして、レポート作成。棒グラフをつくって、円グラフをつくって、散布図をつくる。Power BI で 可視化をしています。 Power BI "を" 可視化しよう！ 今回やってみたいのは、Power BI を 可視化することです。 何段階かステップがありますので、ひとつずつやっていきます。 PBIXファイルからデータモデルを取り出す まず、やりたいことは、PBIXファイルからデータモデルを取り出すことです。 Power BI service にPBIXファイルをふつーうに作業をしてアップロードすると、データ
米Microsoft（マイクロソフト）製品でデータベース作成の際に、デジタル庁が作成した、異なるシステムを連携するためのデータ整備の体系である「政府相互運用性フレームワーク（GIF）」のデータモデルを利用できるようになる。日本マイクロソフトがデジタル庁と協力して、ローコードツールであるMicrosoft Power Platformに実装した。テンプレートを使って簡単に利用できる。地方自治体などが異なるシステム間でのデータ項目や構造をそろえやすくなり、データ連携がスムーズになるとみられる。 異なるシステム間でのデータ連携をしやすくするためデジタル庁はGIFを2022年3月に公開したが、1年たち普及が課題となっている。事業者と協力して広く使われるツールに組み込むことで、普及に弾みがつくか。 住民向けサービス構築などにデータベースを自動作成 日本マイクロソフトが2023年3月下旬からMicro
Snowflakeを愛するユーザーたちの集い #SnowVillage の大人気企画 『みんなのシリーズ』第三弾が登場！ 『みんなのデータモデル講座』、第二回はいよいよディメンショナルモデリング入門！ その本質や考え方を学びながら、ビジネスプロセスのモデリングにチャレンジします。 「実データを見てみたら、理想のデータと乖離がありすぎる…」 「扱いにくいデータがあったときはどうすれば…？」 適切なモデリングで、価値提供を加速させていきましょう！ 今回も、NTT DATA 渋谷さん、 CARTA HOLDINGS pei0804さん、 Snowflake株式会社 グレースさんがお届けします。 第一回【みんなのデータモデル講座】英雄編〜正規化・ERモデルの基礎〜はコチラ https://youtu.be/I2jxAkrolys シリーズ第一弾『みんなのSQL講座』はコチラ https
職業がら多くのデータモデルを見る機会があるのだが、根本的な発想が間違っているために何のアドバイスもできないことがある。そういったケースではしばしば設計担当者が自分のスタイルに固執しているので、アドバイスなどそもそも余計なお世話だったりする。そうなるともうガンバッテと言うしかなく、案の定その後にデスマーチ化する。悪いことに大抵は膨大なコストを投入したあげく、使いにくく保守しにくい業務システムとして完成してしまう。しかもその原因がDB設計の失敗に帰されないので、設計担当者は次の案件でも同じような仕事を繰り返す。 その種の典型的なアンチパターンが、データモデルを「概念を整理した図面」とみなす考え方だ。何の問題もなさそうに思えるかもしれない。私は断言するが、データモデルは「概念を整理した図面」ではないし、「現実を写し取った図面」でもない。正確に言えばそういった側面もあるといえばあるのだが、それだけ
大阪オフィスの玉井です。 dbtはSQLだけで柔軟なデータ変換を作ることが出来ますが、作成したデータに対してテストを実行することができます。 「データをテストする」ということ ソフトウェアエンジニアリングではテストするのが普通 何らかのアプリケーションを開発されたことのある方ならわかると思いますが、開発したものに対しては、必ずテストを行うと思います。特に、昨今のアプリケーション開発では、テストコードなるものを記述することも珍しくありませんよね（私は「人力+Excelにスクショ貼り付け」の時代しか知らない人間です）。 コードにできるということは、バージョン管理ができるということです。そして、CI/CDの手法がとれるということです。CIというのは、継続的インテグレーションの略で、ざっくり言うと、共有リポジトリにコードをマージした際、自動でビルドとテストをやってくれるというものです。 この、アプ
![[dbt] 作成したデータモデルに対してテストを実行する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6172dee51c84ef7822379d7334691c90332d7023/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F08%2Fd72f41d6eb099a8fa0ef2791ad2b18a7.png)
データモデルを活用した データ ウェアハウスの設計
データ モデルを活用した データ ウェアハウスの設計 Joshua Jones, Eric Johnson 目次 はじめに.................................................................................................................................. 2 データ ウェアハウスの設計.................................................................................................... 2 データ ウェアハウスのモデリング..........................................................................
[dbt] custom schemaを使って普段とは別のスキーマ下にデータモデルを作成する | DevelopersIO
大阪オフィスの玉井です。 今回は下記の機能を使ってみたので、ご紹介します。 dbtはどこにデータモデルを作るのか？ dbtはELTの「T」を担当するツールということで、分析に最適化されたテーブルやビューを簡単に構築することができる…というのは、dbtを調べたり触ったりしたことがある方はわかると思います。 では、その「分析に最適化されたテーブルやビュー」というのは、どのDB・どのスキーマに作られるのでしょうか。 ざっくりいうと最初の設定で指定した場所に作られる DBについては、Projectを作成するときに、対象のDWHの接続情報を設定しますが、そのときに指定した場所になります。ついでに、スキーマも合わせて設定できますが、こちらは接続情報として設定するのではなく、ユーザー毎に持つ「開発用の資格情報」として設定します。 「なんでこの設定こんな分かれ方してんの？」って思っちゃいますが、「どのスキ
分析指向データレイク実現の次の一手 ～Delta Lake、なにそれおいしいの？～（NTTデータ テクノロジーカンファレンス 2020 発表資料）
大阪オフィス所属だが現在は奈良県でリモートワーク中の玉井です。 dbtは、ELTのTをソフトウェア（またはアプリケーション）と同じように開発することができるサービスです。しかも、SQLのSELECT文さえ分かっていれば、もう早速使うことができてしまいます。 ただし、SQLはいわゆる宣言型言語で、柔軟なデータモデルを作るためには限界があります。そういう時のために、dbtはjinjaという言語が使えるようになっています。 今回はjinjaのチュートリアルを「実際にやってみつつ」、どういう事ができるかをご紹介したいと思います。 そもそもdbtとは？という方へ 下記をご覧ください。 Jinjaに関する公式情報 本家 本記事では下記に記載されているものを実際にやってみます。 やってみた Projectを新規作成する 今回の作業用に新規Projectを用意します。具体的な方法は上記の別記事をどうぞ。ち
「品番コード体系が破綻」と聞いて「うちのことか」と思った読者は少なくないはずだ。呼び名は色々あり、品目コード、商品コード、品目番号、部品番号と言う企業もある。本稿では商品、製造品、中間品、部品を含めたいので以下では「品目コード」と書く。 多くの企業が「品目コード」の運用に苦労している。扱い品目が増え、品種が多様になるにしたがって品目コードの桁数が増え、コード体系が際限なく複雑化していくからだ。 こうなるとコード体系を誰も覚えられなくなる。新たに発番する際にもコード体系を管理している専門部署といちいちやりとりすることになり面倒だ。本来、品目コードさえ分かれば膨大な候補の中から品目を特定でき、コード体系と照らし合わせることで品目の特徴も理解できたが、その利点が得られなくなる。 品目コードの破綻を避けるにはどうしたらいいのか。小手先の工夫ではなく、商品や製造品、中間品や部品といった多種多様な要素
データモデルの設計とベストプラクティス（第1部）
ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります（または、そうあるべきです）。この点を常に念頭に置きましょう。あるいは、（よく見られることですが）完全に無視することがないように注意してください。 データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう！ Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ（第1部、第2部、第3部、第4部）では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善
データモデルを作るっていうのは、別にデータベース設計をするだけじゃなくて、アプリケーションコードの中でどんな処理フローになるかを考えて、それに適したモデルと、その引き回しの指針を決めることなんだよね そうしないと知らないオブジェクトがどんどん増えていく— magnoliak🍧 (@magnolia_k_) 2021年11月20日 「必要だから作った」データ構造のためのオブジェクトがそこらじゅうに溢れかえると、コードはデータ構造の詰め替えばかりになってしまう その場その場で最小のコード量にしようと思ってボトムアップ的に作り上げていくとそんなことが起きる— magnoliak🍧 (@magnolia_k_) 2021年11月20日 モデルを作ることで… 1. ギョームヨーケンと実装詳細を”なるべく”引き離すことができる 2. 場当たり的なデータ構造が散らかるのを防ぐ 3. 作る過程において
OAuth 2.0とOIDCの理解は、ウェブアプリケーションのセキュリティを確保するために重要です。この記事では、これらのプロトコルがAuth0上どのように機能し相互に関連しているのかを解説します。アプリケーション開発者が認証基盤への理解をより深める一助となることを目的としています。
エンタープライズシステム（業務システム）は「仕訳入力システム」が発展したものだ。もともとは伝票形式で勘定科目を指定する形だったが、個々の業務に特化することでユーザは科目を意識しなくてよくなった。同時に、各業務に固有な管理項目を取り込むことで、業務データのステータス管理が可能になった。とはいえ、ユーザは気づいていないがシステム連係の裏側で個々の会計取引は仕訳に変換されている。 それゆえ、システム開発者には簿記の知識が欠かせない。簿記3級レベルの基礎知識はもちろんだが、その「データモデル」が把握される必要がある。そうでなければ、会計システム（仕訳プロセッサ）との連係を設計できない。 業務システムの開発者が身につけるべき基本のキとして、仕訳プロセッサのデータ構造、すなわち「簿記のデータモデル」を説明しよう。「貸方・借方」の意味合いや決算プロセスについては割愛するので、そこらへんを含めて理解したい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データモデルはドメインモデルに先行する - 設計者の発言
構文のことは忘れて、JSON, S式, XMLのデータモデルを比較する
DWHにおけるデータモデル 定番から最新トレンドまで
データモデルをimmutableに設計したいが... - Magnolia Tech
野球のデータモデル：一球速報からペナントレースまで - 設計者の発言
概念・論理・物理データモデルの違いは人によって異なる？データ総研の考え方をご紹介
Power BI "を" 可視化しよう！ ～データモデル編～ - Qiita
デジタル庁整備のデータモデルをMicrosoft製品に実装、自治体データ連携進むか
【みんなのデータモデル講座】進化編～ディメンショナルモデリング入門～
そのデータモデルに「ソリューション」はあるか - 設計者の発言
[dbt] 作成したデータモデルに対してテストを実行する | DevelopersIO
Amazon.co.jp: システム開発・刷新のための データモデル大全: 渡辺幸三: 本
グラフ構造のデータモデルをPower BIで可視化してみた
dbtでJinjaを利用して柔軟なデータモデルを開発する | DevelopersIO
品番コード体系が破綻！その前に知っておきたいデータモデル
なぜデータモデルをきちんと考えないといけないのか - Magnolia Tech
OAuth 2.0とOIDCの理解を深める: Auth0データモデル解説 | TC3株式会社｜GIG INNOVATED.
基本のキ「簿記のデータモデル」を学ぼう - 設計者の発言
note.com/azael
web.archive.org
times.abema.tv
seiji-honjo.hatenadiary.org
mainichi.jp
amass.jp