DB設計

下書き。 URLがほしいので一旦公開。

下書き。 URLがほしいので一旦公開。 サマリデータ 集計用のカラムを追加し、そこに保存する。 (達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ p.149-152) いつ使うのか 集計処理のパフォーマンスを向上させる必要がある時。 サマリデータを追加する = 推移的関数従属が生まれる ということなので、サマリデータは必要最小限にする。 選択条件の冗長化 同一のカラムを複数のテーブルに持たせる。 (達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ p.153-156) 参考 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

エンティティ（実体） 例：美容院 予約システム 画面図などを使って、仕様を決める 画面図や仕様書を見ながら、何をデータとして保存するか列挙していく。 列挙したデータを種類ごとに分ける。 店名 時間帯 美容師 コース システム側が事前に用意するもの 店名 美容師 ユーザーが登録するもの 時間帯 コース 列挙したデータを抽象化して、エンティティとしてまとめる。 店名ID： 美容師No： 時間帯： コース： テーブル名と列名を定義し、データを入れる クロエ（店名）テーブル +--------+--------------+-------+ | 美容師ID| 時間帯 | コース | +--------…

新卒2年目ですががっつりDB設計をすることがあり、その際に思ったことなどをまとめておく。 3層スキーマを意識しておけばよかった 特に設計の内容が変わるわけではないのだが、どこまでやればDB設計を完了とみなしていいかがあまりわかっていなかった。今までの現場経験的なところで各カラムのデータ構造まで決定していれば大丈夫だろう。という曖昧な感覚でDB設計を終わらせてしまっていた。 今思えば3層スキーマに従って、外部設計の画面仕様書作成中は、外部スキーマを決定してるようなものだなー。ER図で論理設計をしているときは概念スキーマを決めているんだなー。じゃああとは内部スキーマの決定だけ必要だからそこまでやれ…

はじめに はじめまして、2022年3月中旬にコミューン株式会社に入社した西山です。 普段はフロントエンドのエンジニアとして開発業務に携わっています。 この記事では、私がERモデルを使ったDBのデータモデリング（以下、データ設計）を行う際、特に意識していることを3つ紹介します。 尚、具体的にユースケースからエンティティを抽出する方法や、チューニングなどの物理設計については触れません。

こんにちは。管理人のPaZooです。 最近、めっきり寒くなりました。とうとう冬ですわ。 久しぶりにブログを更新しました。本当にいつぶりなのかもう記憶にもございませんです。 しかもAdvent Calendar1日目に、ER図についてのネタを持ってくるという… うん、まあいいでしょ。うんうん。誰も怒らんし。 さて、今回のネタは「ER図」についてです。 私が参画している現場ではER図に触れる機会は全くと言っていいほどありません。 しかし、いざ現場で開発をやるうえでは知っておくべき知識のひとつであることは間違いないです。 今回は、私がざっくり「ER図」について学んだことを整理するためにまとめた記事で…

やっとER図の作成が終わりました。これからポートフォリオ完成までの道のり、「issueを切り出す」ことをやっていきます。その前に、ER図作成時にやってしまったデータベース設計でのアンチパターンを2つまとめたいと思います。 当初のテーブル設計 下記テーブル設計が当初僕が書いていたテーブルになります。 この、AccumulatedOrdersテーブルとAlcoholOrdersテーブルのカラムに問題がありました。 それぞれのやりたかった挙動をまとめます。 使用するモデル class AccumulatedOrders < ApplicationRecord has_many :alcohol_or…

気になった用語等をまとめる（細かい所はきる） 第1章_データベースを制する者はシステムを制す 学んだこと システム開発の設計工程 内容 要件定義 必要な機能を決める 設計 実際に作る前に図面を引く※本書はここがターゲット 開発 プログラムに落とし込む テスト テストする スキーマとはDBのデータ構造を表す 3層スキーマモデル 説明 外部スキーマ ユーザーから見てどのようなインターフェースを持っているかを定義（ビュー） 概念スキーマ 開発者から見てデータ同士の関係を定義（テーブル）概念スキーマの設計を論理設計 内部スキーマ DBから見てデータをどのように格納するかを定義（ファイル）内部スキーマの…

はじめに 「達人に学ぶDB設計」について リレーショナルデータベースにおける設計についての書籍で、以下2つについて解説されています。 論理設計 正規化やER図といった道具を使ったデータモデルの設計のこと。 物理設計 サーバーやストレージといった物理的なハードウェアレベルの設計のこと。 全体的な所感 私は、SQLや論理設計の基礎的な内容 (正規化とER図)は既に学習していましたが、脱初心者を謳っている本だけあって、全体的に難しく感じました。今後、定期的に見返すことで少しずつDB設計の知識を身につけていきたいと考えております。 良かったところ 全体的に難しかったが、図が豊富に使われていたためイメー…

はじめに こんにちは！Akira(彰)です！ 本日は達人に学ぶDB設計 徹底指南書 を読んだ感想を、 良かったこと 学んだこと 難しかったこと に分けて書いていきたいと思います。 良かったこと DBの基礎を学んだ後に知っておくべき知識を学べる 僕は1つ前の記事で感想を書いた本を読んでから今回の本を読んだのですが基礎を学んだ後、自分で設計する際に不安だった要素を補えるような内容となっていて助かりました。 筆者の伝えたいことがわかりやすい この本は筆者の体験談を交えて書かれており説得力があるのと、繰り返し筆者の伝えたいことを述べてくれるため頭に入りやすいです。 設計におけるアンチパターンを学べる …

早いもので、『エンジニアが終末に備えて技術を磨く日記』も、もう38日目です。2日目からReactを勉強し初め、Reactを使ったフロントエンド開発がどのようなものであるか、ざっくり理解しました。また、つい最近の32日目には『達人に学ぶDB設計 徹底指南書』を読み、DB処理のパフォーマンスを上げるためのテクニックを学びました。 フロントエンドとDBというWebアプリに必要不可欠な技術を勉強した今、Webアプリを開発したい欲が高まってきています。それも、できる限りフレームワークを使わず、細かいところまでちゃんと理解して開発したい。 『エンジニアが終末に備えて技術を磨く日記』を始める時に技術スタック…

はじめに DB設計の学習として「達人に学ぶDB設計 徹底指南書」を読んだので、感想をまとめました。 良かったところ 本書は論理設計と物理設計の知識に加え、DB設計がシステムの品質を左右する重要な要素であることを理解できたことが良かったと感じました。 また、各章の先頭に記載されている「学習のポイント」と、抑えるべき重要な箇所についてまとめられている「勘どころ」は要点が簡潔にまとめられており、とてもわかりやすいと感じました。 学んだこと 正規化がもたらすデメリットについて 本書を読む前は、論理設計におけるテーブルの正規化に関し、正規化を繰り返すことでデータの冗長性がなくなり、更新時の不整合を防ぐこ…

エンジニアが終末に備えて技術を磨く日記の32日目。 1日目はこちら。 「エンジニアが終末に備えて技術を磨く日記」カテゴリはこちら。 達人に学ぶDB設計 徹底指南書 作者:ミック 翔泳社 Amazon 『達人に学ぶDB設計 徹底指南書』を読みました。DBの設計方法、冗長化、バックアップ、ER図の書き方、パフォーマンスを向上させるためのテクニックなど、DBを扱うために必要な知識が広く浅く解説されている本です。 難しい事は書かれておらず、用語にも都度説明が挟まるので、DBに関してほぼ知識のない僕でも読めました。DB触りたての初学者向けの本という感じです。 自分用のWebアプリの処理速度がレコード数の…

主に3つに時間使ってると思う。 Flutterのアプリ やっと公開しました。意気揚々とはじめたけど…長かった。 これから機能追加したり集客周りやってみたりしたいと思ったり。 2つ感じたことがあって 1．やっぱりLaravelとか使い慣れた方が早いかもな、という感じ。Flutter×Firebaseよかったけど。仕組み、UIはググって実装にはあんまり時間掛からなかったけど、この関数をCloudFunctionで毎回叩くのかぁ...って作っていてちょっとモチベーションが下がったのも事実。 2．自分は定量的な処理の作りだったり考えるのが好きなのがわかったこと。ほんとにひとり開発だったからわからないと…

目次 前置き データベース論理設計の概要 > 達人に学ぶDB設計 徹底指南書 第2章 概念スキーマと論理設計（P28~33） 第3章 正規化（P84~122） 第4章 ER図作成（P123~138） 第5章 論理設計とパフォーマンス(P139~160) 第8章 オートナンバリングの是非(P234~240) ER図の目的と作り方 > WEB+DB PRESS Vol.130 特集1: 実践データモデリング 第1章 良いデータモデルの条件 第2章 イミュータブルデータモデルとは何か 第3章 イミュータブルデータモデルの基本 第4章 イミュータブルデータモデルの実践 第5章 ドメインモデルへの応用 …

ノーコード・ローコード開発のような実装過程の合理化が進展することで、DB設計が業務システム開発プロジェクトのカギであることが再認識されています。ノーコードだろうがローコードだろうがOOPだろうが、DB設計に失敗すれば陰鬱なデスマーチが始まる。データモデリングは、IT技術者が心身を守りつつ専門家として成長していくための基本的なサバイバル技術です。その神髄を合宿形式で学びましょう。 データモデリング合宿2023（浜名湖１泊） - connpass ２０２３年９月１７日（日）～１８日（月／祭日） 【セミナー】 １．自治体システム1700問題の現状と課題 ー岩崎和隆さん(神奈川県庁) ２．DXに向けた…

こんにちは！ 2weekインターンシップ6日目、チームAブログ担当の うえたつ です。 ブログ執筆二回目ということで、今回も今日の出来事を振り返っていきたいと思います。 開発に集中しすぎて、写真を撮り忘れてしまいました... 進捗共有アプリの開発 「夏休みの宿題の進捗を共有するアプリ」を目指して、チームでの開発をスタートしました！ UIデザイン、DIDログイン機能、DB設計と大まかに分担を決めて実装していきました。 あるメンバーは早速ChatGPTにCSSを作らせていて、かなり良い感じのUIができていたので驚きました！ （僕はブラックボックスをちょっとでも増やすことになると思うと気が引けてしま…

仕様の考え方 Data illustrations by Storyset こんにちは、開発チームでエンジニアをしている和田です。 普段の業務では、Node.js で作られているアプリケーションの仕様を考えたり、機能開発をしたりしています。 入社してから新しく開発した機能のほとんどの仕様作成に携わってきました。 今日はそんな筆者が、 「初めて機能開発に携わることになったけど、仕様ってどうやって考えればいいの...？」 と悩めるエンジニアの方のために、この1年ほどで学んできた仕様を考えるうえで大事な観点について記事にしてみようと思います。 ※ あくまで個人の意見であり、筆者が所属するチームで大切…

connpass.com こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会の概要 会の様子 DB設計の基本を外すとどうなるのか？ 正規化をしない 自由なテーブル 過程の抹消 履歴管理テーブル設計におけるアンチパターン 過度な正規化 変更履歴を1テーブルで管理 質疑応答 すでに稼働しているアプリケーションのテーブルを変更するときに工夫していることはあるか？ 履歴をどこまで保存するといいのか？ 会全体を通した感想 会の概要 以下、イベントページから引用です。 DB設計においてスケールを考えずに安易な名称やテーブル構造で作成してしまい、後から後悔した経験は無いでしょう…