Vol.3_個人開発プロジェクト「旅行先の飲食店におけるマッチングアプリ（仮称）」開発。技術スタック選定（データベース設計）
こんにちは。２記事毎にサムネデザインも変えてみます。笑
今回も表題のプロジェクトの進捗を記事にする。前回までに、「要件定義（機能要件・非機能要件）」が概ね完了したので、次の工程として「技術スタック」の選定をしている。
こちらも概ね必要な技術スタックは決定したのだが、各技術の部分（サーバー構成、データーベース、言語、CI /CDなど）について調べながら進める必要があるため、少し時間がかかりそうだ。とは言っても、ガチガチに各要件を固めてから進めるようなプロジェクトではないので、ある程度、理解ができたらとりあえず進めていく。
今回の記事では、必要な技術スタックの内、「データベース設計」を中心とした記事を書こうと思う。と言うのも昨今のアプリやシステム開発では、DOA（Data Oriented Approach）と呼ばれる「データ中心のアプローチ」が主流となっているそうなので、データベースの設計はある程度しっかり考えておきたい。
簡単に説明すると、DOAとは反対のプログラム開発アプローチがあり、POA（Process Oriented Approach）という「業務プロセスからプログラムの設計・開発」もあるのだが、この進め方をしてしまうと「プロセス（処理）毎にデータ構成を考える必要がある」ため、管理が煩雑になり、後々のシステム改修や開発を進める中で変更が発生した場合に手戻りコストが増大になる。よって、このPOAは今では時代遅れとなっており、「データベース」からプログラム開発を考えるのが基本だそうだ。
最近読んだデータベース設計の書籍に言わせると『データベースを制する者がシステムを制する！！』とのこと。
そこまで言われているのであれば、「データベース設計」についてもある程度知ろう！という事で寄り道ではないが、少しデータベース設計も深掘りしながら、本プロジェクトを進めることにする。
１.本プロジェクトの技術スタック
まずは概ね決定した技術スタックを下記に添付する。大きく分けて5つの技術を利用する。サーバ構成は充実したサービスが整っており、安心安全王道の「AWS」をベースに考える。また、利用する言語は今回のアプリケーションは最終的にiosに公開することを目指しているため、Apple製品と相性が良い「Swift」を中心に実装していく。また、本プロジェクトのパートナーがSwiftを使って色々と開発を進めていたり、学習していたりもするので、自分自身も有難いところがある。
（当初LLMやRAGをテーマに始めたので、Pythonを扱ってみる事から始めたが「開発全般」を知る事、何かしら開発した経験が最初に欲しいので、言語は”将来性”があればある程度なんでも良い。こだわりはない。笑 こんな紆余曲折も楽しみたいし、楽しんでください。「こいつブレブレやないか！」と。笑 良いんですよ。最終的に身になる物があれば。笑）
という独り言が長くなってしまいましたが、そんな感じで、概ね必要な技術選定をしたところです。
その中でも、前傾しましたが、「データベース設計」を初めにある程度、固めるべく、DBとDBMSを選定している。
2.データベースとDBMS
2.1 データベース『リレーショナルデータベース（Relational Database:RDB』
今回のプロジェクトで利用するデータベースモデルは「リレーショナルデータベース（Relational Database:RDB）」と言われる「関係データベース」と言われ、現在、最も利用されているデータベースで進めていきます。特徴としては「Excelの表のようなイメージで2次元表形式でデータを管理」するものです。
他にも「XMLデータベース」や「オブジェクト指向データベース」などデータ管理の手法が複数種類存在するようですが、今回のアプリも「RDB」がマッチすることと広く使われているため汎用性がある点からもこちらを利用します。
2.2 DBMS『PostgersSQL、MySQLなど』
データベースモデルにも種類があるようにDBMSにも種類があります。代表的なものでいくと「SQL server」「DB2」「Oracle Database」「PostgersSQL」などがあり、有料で利用するものと無料で利用できる物があります。
今回はオープンソースである「PostgersSQL、MySQL」あたりを利用する想定です。ここで一つ疑問が浮かぶかもしれませんが、「なぜ想定なのか？」というのも、データベースの設計手法とDBMSは後で決定しても、その設計に影響を与えないからです。つまりDBMSは後から選定・変更したとしても、影響しないのでまずは、データベースに必要なテーブル（情報）を定義して、ER図と呼ばれるデータベースのカテゴリーみたいなものをある程度決めてから、DBMSを決定していく流れになると思います。（次の目次でイメージを紹介します。）
3.今後の流れ
データベースを固めるために必要な要素を洗い出していきます。データベースの設計に必要な考え方として下記の「スキーマ」という概念があります。
①外部スキーマ（ビュー）
②概念スキーマ（テーブル） ＝論理設計
③内部スキーマ（ファイル） ＝物理設計
今回のプロジェクトの場合「②の概念スキーマ」を設計すれば概ね、必要なデータベースが整う形になります。この概念スキーマの説明はややこしく感じてしまう方も多いと思いますので、割愛しますが、データベース設計は主に3つの設計（論理設計、物理設計、実装設計）に分かれるそうで、その中でも論理設計が概念スキーマに当たる部分なんだということだけ、この記事ではお伝えさせていただきます。
この概念スキーマ（論理設計）の設計に必要な要素として、テーブル（簡単にいうとデータの基）になるものを作成する必要性があります。細かく言うと（エンティティの抽出、エンティティの定義、正規化、ER図）と呼ばれるフローでデータベース設計する必要性があります。
テーブルのイメージとしては、下記のようなものです。
今回のプロジェクトは「旅行者（ユーザー）」と「飲食店（レストランなど）」に関連する情報が基本的なデータとして必要なため、これらに必要なデータ要素を洗い出して、整理して（これがエンティティの抽出と定義、正規化）その関連性を紐づけていく作業（ER図）をしていきます。
と言うことで、直近の数日間はこのあたりのデータテーブルの洗い出しを行なっていきます。
4.まとめ
今回の記事は長くなりましたが、データベース設計も名前だけ見ると凄く地道であまり楽しくない工程だと思っていましたが、全くそんなことはない！！というのも昨日もプロジェクトパートナーと話をしていたのですが、このデータベースを考える工程では、アプリケーションの動作も合わせてイメージしなければならず、そこに紐付くデータを枝葉のように考えるとゲーム感覚で楽しいものです。
データベース設計・・・沼りそう。笑