予約と貸出のデータをどう分ける？記録のつながりを設計する手順

データモデルは、仕事で区別する記録と関係の説明

データモデルとは、扱う情報をどの単位に分け、どう関係させるかを表す説明です。機材貸出なら、「予約の希望」「一台ずつ見分ける機材」「その貸出について残す記録」を、同じものとして扱ってよいかを考えます。最初から表の名前やプログラムを書く必要はありません。

項目

予約ID、希望する種類、希望開始日など、一つの情報を入れる欄です。

記録

ある予約や貸出について、項目と値を対応させた一件分の情報です。同じ利用者でも、別の予約は区別して扱います。

個体

「カメラ」という種類だけでなく、一台ずつ区別して扱う対象です。この例の個体IDは、その対象との対応をたどる仮の番号です。

関係

ある予約に、どの貸出や個体の記録が対応するかというつながりです。線を描くときは、何の番号を使い、何を意味する関係かを説明します。

画面では予約と貸出をまとめて見せるとしても、保存する情報の役割まで同じとは限りません。反対に、説明上は区別した記録を、必ず同じ数の物理テーブルにするとも決まりません。まず業務上の違いと関係をそろえ、その後で開発担当が保存・更新・検索の方法へ具体化します。

分ける基準は、別々に変わり、別々に残したい事実か

同じ受付画面に載る情報でも、変わる理由と残す期間が違います。予約の希望日は利用者の相談で変わり、どの個体を対応させるかは割当の判断で変わります。一方、貸出について既に残した記録を、希望日の変更で一緒に上書きしてよいとは限りません。この違いが、記録を分けて考える理由です。

たとえば、機材の呼び名を直すたびに、過去の予約を全部探して同じ文字を直す設計なら、直し漏れで説明が食い違うおそれがあります。反対に、過去の書類に当時の表記を残す必要があるなら、現在の名称を参照する情報と、当時の記載を保存する情報を区別する案が必要です。「同じ内容は全部消す」でも「全ての予約へコピーする」でもなく、どの事実の正本か、当時の記録かで判断します。

Microsoftのデータベース設計の基本も、主題の異なる情報を分け、関係を使って対応させる理由を、重複の更新漏れや意図しない情報喪失から説明しています。AccessのデスクトップDB向け資料なので、ここではその考え方を参照し、物理テーブルの構成を本稿だけで確定しません。

目標は表を細かく増やすことではなく、同じ事実を矛盾なく更新し、必要な過去をたどれることです。画面は一つにまとめたままでも構いません。希望、個体の情報、貸出の記録を区別して保存し、必要なときに対応する内容を一緒に表示する方法を、開発担当と検討します。

Microsoftのデータ構造とモデリングの解説では、業務のデータ要件と関係、データの管理者や流れを整理する考え方を扱っています。本稿では説明の整理方法を参考にします。架空の会社がDynamics 365を使うという前提や、特定の共通モデルを採用する義務へ移すものではありません。

各項目の意味、値の出所、誰が更新するかを整理する場合は、新システムに必要なデータ項目を決める方法も参照できます。ここでは、その項目を持つ記録同士をどう結ぶかに焦点を当てます。

希望を受ける仕事と、貸出・返却を残す仕事を並べる

受付担当には、実際の一件を例に、どの情報を受け、どの時点で何を確かめるかを説明してもらいます。開発担当は、そこで扱う情報が「希望」「個体の割当」「貸出の記録」「返却の確認」のどれに当たるかを整理します。次は設計を相談する観点であり、この架空例で全操作を実施した順序ではありません。

予約の希望を受けるとき

相手を識別する情報、希望する種類と期間、受付の状態を区別します。希望が届いたことと、在庫の確保や予約の確定は同じではありません。誰が、どの確認をしたら確定できるかを、業務の責任者に尋ねます。

機材の個体と対応させるとき

種類の希望だけで足りる段階と、一台ずつの個体を決める段階を分けます。予約を受けた時点で個体を決めるのか、後で決めるのか、別の個体へ替える場合をどう扱うのかは、その会社の規則です。この記事の空欄から、割当の時期や変更方法を決めつけません。

貸出や返却を記録するとき

どの予約に、どの個体と貸出の記録が対応するかを残す案を考えます。実際の受渡しや返却を、誰が何を見て記録するかも別に確かめます。希望開始日を実際の貸出日へ、希望終了日を実際の返却日へ、そのまま写して済ませないことが大切です。

仕事の説明から、記録と線を導く順序

1. 最初に、答えたい問いを決める。この受付について「何をいつ借りたいか」「どの個体と貸出に対応するか」「返却を何で確かめるか」を、別々の問いにします。必要な問いが定まると、図に載せる情報の範囲も決めやすくなります。
2. その問いの答えを持つ記録を分ける。希望は予約、機材一台を区別する情報は個体、貸出について残す情報は貸出の記録として考えます。「日付」のように同じ名前の欄でも、希望日と実際の日時なら役割を分けます。
3. 同じ相手へ戻れる番号を付けて結ぶ。画面の見た目や並んだ順で対応を判断せず、どの予約ID・個体ID・貸出IDを見るかを説明します。既存の番号を使えるか、重複や変更がないかは、実データと運用から確かめます。
4. 一つだけか、複数か、まだなくてもよいかを尋ねる。受付時に個体が未定でも保存するのか、一つの予約で複数台を借りるのかを確認します。この回答が、記録の単位や線の意味を変えます。
5. 更新する場面を順に当てはめる。希望の変更、個体の入替え、貸出の追加、返却の確認を仮に当てはめ、変える情報と残す情報を指します。答えられない場面は、その部分の規則を質問して図を直します。

この段階で顧客や業務責任者へ示すのは、扱う仕事の範囲、各記録が表すもの、番号と線の意味、確定した規則、未回答と確認先です。専門的な図の記号を見せるだけでなく、「この問い合わせには、この予約と貸出をたどって答えます」と説明すると、業務として抜けている関係を話し合えます。

顧客名や機材の呼び方を複数の部署でそろえる問題は、記録同士の関係とは別に整理します。マスターデータの識別と更新担当を決める方法では、同じ対象かを確かめる根拠と管理責任を扱っています。

予約だけの記録と、貸出記録がある別の記録を読む

以下の番号は、説明の中で同じ記録をたどるための仮のIDです。Rは予約、Cは顧客、Uは機材個体、Lは貸出に対応します。メニューや作業手順の符号ではありません。番号の発行方法や、データベース上の主キーを決めたものでもありません。

R01が作り直されてR02になった例ではありません。違う予約の記録を並べ、予約の希望が分かることと、個体や貸出との対応が分かることの違いを見ています。

IDで何を結ぶかを説明し、一つと複数を先に決めない

関係を説明するときは、「つながっています」だけで終えず、どの記録の何を見れば、どの相手を探せるかを言葉にします。この例なら、R02の予約について、貸出L02と個体U09との対応を確認できます。C02は、その予約の相手をたどるための番号です。図の線には、その対応を意味する説明を付けます。

MicrosoftのEF Coreの関係の入門は、対象同士の関係と、リレーショナルデータベースで主キー・外部キーを使う表現を説明しています。資料中の例では、一件を識別する主キーに、別の表の外部キーの値を対応させています。これは用語を理解するための参考で、この記事の仮番号をそのまま物理DBの制約として実装したという意味ではありません。

一つの予約に、複数の機材を含めるか

今回の二記録に個体IDが一つずつの欄で表れていても、会社の予約が必ず一台だけとは決まりません。まとめて借りる仕事があるか、種類だけ先に希望するか、個体を別の時点で決めるかを、受付の責任者へ尋ねます。

複数個体を結ぶ必要があると分かったら、予約の内容と各個体との対応を、明細のような別の記録で扱う案も検討できます。どの単位で貸出・返却を残すかは、その回答に合わせて開発担当が説明し直します。この会社の件数の規則を、現時点で一対一や一対多と確定しません。

同じ個体を、別の貸出でも使うか

同じ機材を繰り返し貸し出す仕事があるなら、個体を説明する情報と、その都度の貸出を分ける必要を検討します。一台の情報を上書きするだけで過去の貸出が追えなくならないか、どの履歴を残すかを確認します。具体的な保存期間や、過去を修正できる条件は、業務の回答から決めます。

線やIDの対応が整っていても、予約期間の競合や、取消してよい状態まで自動的に決まるわけではありません。記録の関係と、業務で許される操作の条件を分けて、両方を説明します。

複数個体・取消し・競合・返却の未回答を質問に変える

未回答を残す目的は、設計を止めることではなく、どの回答があれば関係や条件を具体化できるかを示すことです。受付の責任者が業務の扱いを説明し、開発担当が記録と操作への影響を返します。誰が答えを確認するか分からない場合は、業務を決める担当者を先に確かめます。

一件で複数の機材を扱う場合

予約はまとめたまま個体別に貸出・返却するのか、予約自体を分けるのかを尋ねます。回答次第で、必要な記録の単位と線を見直します。

希望を変える・取り消す場合

どの状態まで変更でき、個体の割当や貸出の記録がある場合に何を残すかを尋ねます。取消しの規則が未取得だからといって、取消不可や削除してよい状態とは決めません。

期間や個体の利用が重なる場合

希望の段階と確定した段階をどう区別し、何が重なったら競合とするかを聞きます。比較する期間の意味や境目も確認し、同時更新がある場合の扱いは開発担当へ具体化を頼みます。この例の競合確認は未取得で、検出機能が動いた結果ではありません。

返却を確定する場合

誰が何を確認したら返却の記録を残し、次の貸出に使える状態へ進めるかを尋ねます。希望終了日や貸出記録の存在だけで、返却済みとはしません。

返答が届いたら、答えた人、参照した規則や資料、どの記録と操作に適用するかを対応させます。回答の適用範囲が予約R02だけなのか、通常の全予約なのかも読み分けます。個別の例外の回答を、全社共通の規則へそのまま広げません。

「未取得」と、明示された「なし・あり」も別です。R01の貸出記録は「なし」、R02は「あり」という明示値ですが、返却はどちらも情報が未取得です。情報がない所へ「いいえ」を入れると、未確認が業務上の否定に変わってしまいます。

図で、予約から個体と貸出をたどり、未取得の先を読む

解説図を原寸で見る

この図を読んだ後の判断：予約の希望と、個体・貸出との対応を分けて説明できます。受付の責任者へ、複数機材、取消し、返却、競合の規則を尋ね、開発担当は回答に応じて線と記録の単位を更新します。未取得の情報を、返却済みや設計完了へ補いません。

回答でモデルを直し、一件の仕事で説明を確かめる

回答が来たら、未取得欄を埋めることだけを目標にせず、その回答で記録の区別や操作の条件が変わるかを見ます。本文や図の説明も同じ内容へ直し、元の質問と回答の対応を残します。ここからは、返答が届いた場合の進め方であり、この架空例で回答や動作確認が完了したという記録ではありません。

一台だけを扱うと回答されたら

その規則の適用範囲と、例外を確認します。予約時と貸出時で個体が変わる場合、変更の履歴をどう残すかも相談します。「一台」という返答だけで、貸出・返却の記録の単位や取消しまで全て決まったとは扱いません。

複数個体や分けた返却が必要と分かったら

どの予約に、どの個体と貸出・返却の記録を結ぶか、開発担当に別の単位の案を示してもらいます。受付担当は、記録をたどって希望と対応状況を説明できるかを確認します。必要な明細が増える場合も、数を増やすこと自体が目的ではありません。

取消し・重なり・返却の回答で、操作の条件を直す

取消しを認める状態が決まったら、その状態で何を止め、どの割当を解除し、過去の貸出記録をどう残すかを対にして設計します。貸出の記録がある場合は別の手続きが必要なのかも確かめます。取消しを、関連する情報の一括削除と同じ操作にはしません。

期間の重なりについては、希望段階の重複も止めるのか、確定した割当を対象にするのかで、確認する記録が変わります。期間の終わりと次の始まりが同じ場合を認めるか、点検時間を見込むかなども先に決めます。回答後、対象にする状態・期間・個体を明示し、受付が重なったときにも同じ規則を守れる実装と試験を、開発担当に具体化してもらいます。

返却については、全部そろった時点でまとめて記録するのか、個体ごとに別々に確認するのかで、必要な記録が変わります。個別の返却が必要なら、予約全体の「完了」だけを更新する案では途中の状況が説明できるかを見直します。いずれも、この例では未回答の規則です。

規則や確認する人が決まらない場合

どの関係や操作を確定できないかを保留として残します。今説明できる予約の希望や既知のIDまでを図にし、推測で一台の割当や返却を描き足しません。誰へどの質問を返し、回答後に何を見直すかを次の作業へつなげます。

一つの変更を当てはめ、変える記録と残す記録を確かめる

次は、設計案を読み合わせるための確認例です。この架空原票へ新しい値を加えたり、動作試験に合格したりした記録ではありません。受付担当が期待する扱いを説明し、開発担当が、どこを変更するとどの結果になる案かを対応させます。

希望期間だけを変更するなら

予約の希望を変えたとき、関連する割当の再確認が必要かを説明します。既に記録された実際の日時や貸出履歴まで、同じ値で上書きしないかを見ます。希望と実績が同じ欄なら、分ける設計へ戻します。

割り当てた個体を入れ替えるなら

予約の希望を残し、個体との対応だけをどう変更するかをたどります。元の対応を履歴として残す規則なら、それも追えるかを確かめます。別の予約の個体まで変わる案なら、対応する番号や更新の範囲を見直します。

複数台のうち、一部だけが返るなら

複数貸出・個別返却を認めると回答された場合の確認です。戻った個体と、まだ確認できない個体を区別できるかを説明します。予約全体の完了欄だけでは分からなければ、個体ごとにたどれる貸出・返却の単位を検討します。

対応先が見つからない、同じ番号が重なるなら

誤った相手へ推測で結ばず、入力・取込み元と番号の規則を調べます。業務で訂正する人と、保存時に誤対応を防ぐ仕組みを分けて決めます。表示上の線があるだけで整合が保たれるとは扱いません。

説明の確認を終える目安は、通常の受付だけでなく、変更や例外でも「どの記録を見て、何を更新し、何を残すか」を両者が指せることです。指せない場合は、単位・対応・規則のどこが足りないかへ戻ります。その後、合意した期待結果を使って、保存・更新・取消し・同時操作などの実装試験を設計します。ここでの読み合わせと実システムの試験結果は、別に記録してください。

今回の予約について、希望の種類と期間、個体との対応、貸出・返却の記録を分けて説明したいです。一つの予約に複数の機材を結ぶ場合があるか、希望変更や取消しをどう扱うか、何を確認したら返却や競合の判断ができるかを教えてください。

この図で示した既知のIDと未取得の欄を読み合わせ、規則が分かる資料と、答えを確認する担当者を示してください。開発担当からは、その回答で必要な記録や線、操作の条件をどう直すか説明してもらいたいです。

業務の関係が整理できた後は、開発担当がデータの型、保存方法、整合を保つ仕組み、同時更新、検索、権限などの設計を具体化します。利用量や確認環境がないまま、速さや規模への対応を保証しません。既存データを移す場合は、移行前後のデータを照合する方法が別の作業として必要です。

アプリや保存先の配置と接続を説明する場合は、システム構成図の根拠を確かめる方法を使えます。記録を結ぶ線と、アプリ同士の通信や設置場所の線を、一つの意味で混ぜないようにします。

予約と貸出の違いを、同じ項目で見比べる

受付中の予約は、個体・貸出の番号が未取得で、貸出記録は「なし」です。別の予約には、個体・貸出の番号と貸出記録があります。二つは別の架空の記録で、予約から貸出へ進んだ前後の記録ではありません。番号は、どの予約に個体や貸出の情報が対応するかをたどるために使います。

希望する期間は、実際に貸し出した日や返却した日ではありません。貸出記録がある方も、予約確定や返却完了を示してはいません。未取得を「なし」にせず、取消の扱い、返却の確定条件、重複・競合を確かめる方法を業務責任者へ聞きます。

まとめ：予約の希望と貸出の記録を分け、分からない関係を質問する

予約と貸出のデータを設計するときは、最初から一枚の表や物理DBの完成形を決めず、仕事で区別する記録と、その対応を説明します。予約の希望、機材の個体、貸出・返却について記録された事実を分け、どのIDを見れば関係をたどれるかを示しましょう。

架空のR01は個体・貸出IDが未取得で、貸出記録はなし。別のR02にはU09とL02の対応と貸出記録がありますが、返却や取消し・競合の情報は未取得です。これを成功の前後や、返却済みの結果に変えません。

最初の一歩は、一件の受付を選び、希望、個体との対応、貸出、返却を別の記録として説明し、分からない線を一つ質問することです。受付の責任者と開発担当で答えを読み合わせ、関係・条件・残る保留を同じ図と説明へ更新してください。