データベースモデリング

デンタルフロスについての曲を書きましたが、誰かの歯がきれいになりましたか？

フランク・ザッパ

私たちが歯科医院について考えるとき、私たちの最初の関連は、訓練、痛み、そして恐怖です。 OK、それは悪いですね。歯の世話をすることに加えて、歯科医は専門的、合法、またはその両方である他の多くの義務を負っています。それらはすべて適切なデータ管理が必要です。

この文書化の要件を満たすために、多くの歯科および医療機関は紙の記録を使用しています。しかし、ゆっくりと、しかし確実に、21世紀のデジタル記録と管理に向かう傾向があります。

歯科医院内

歯科医に行くことは、私たちがいつも喜んで覚えていることではありません。運が良ければ痛みをかわしましたが、財布はひどく苦しんでいたのでしょう。歯科医院に足を踏み入れた後の手順は、通常、次のとおりです。

あなたは両方とも短いおしゃべりをします。（歯科医に来週訪問し、2年が経過すると約束したため、不快なことがよくあります。それから、忘れたと言い、彼は同意し、すべてが再び大丈夫です。）
彼があなたの以前の治療記録を見ている間、あなたは椅子に座っています。彼は前回の訪問以降に何かが起こったかどうかを尋ね、あなたの医療記録に更新はありますか。
彼はあなたの口の中を見て、何がうまくいかなかったかを判断し、何がそれを修正するかを教えてくれます。
彼の治療計画に同意するか、他のオプションを選択できます。
数か月後、ハリウッドの笑顔が再びあなたの顔に現れます。もっと早くなったでしょうが、最終的に歯科治療の費用を全額支払うまで、あなたは微笑むことができませんでした。

この時点で、最も熱心なデータベースの専門家でさえ、おそらく考えていません。「うわー、この経験のためのデータモデルがあればいいのに！」 。しかし、それはあり、検討する価値があります。そのため、以下に印刷しました。

デンタルオフィスデータベースモデルの紹介

このモデルの背後にある考え方は、歯科医院に最初に足を踏み入れた瞬間から問題が解決するまでのすべての手順をカバーすることです。このモデルの一部（ user_accountというラベルの付いたテーブル 、ステータス 、 user_has_status 、役割 、 user_has_role ）は、以前の記事で提示および説明されました。ここでは役割やステータスは不要に見えるかもしれませんが、診療には、既往歴（記録取得）を処理する看護師、受付係、歯科学生、訓練を受けた歯科助手、さらには訪問専門家や衛生士が含まれる可能性があることを忘れないでください。ただし、この記事では支払いの詳細は考慮されません。

歯科データベースのテーブル

患者 tableは、データベースで最も重要な2つのテーブルの1つです。患者のデータを保存し、患者のドキュメントや訪問に接続されます。 mailを除いて、テーブル内のすべての属性は必須です：

名前 –患者の名前

 名前 –患者の名前
   Identification_number  –このフィールドは、実世界で使用されるクライアントの一意のIDを格納するために使用されます
 アドレス –患者の住所
 電話 –患者の電話番号
 メール –患者のメールアドレス

   
 
 データベースで2番目に重要なテーブルはvisit   。テーブルと組み合わせると患者  、後続のすべてのアクションをトリガーしたイベントに関する情報を格納します。表の属性は次のとおりです。
    visit_date  –訪問が発生した実際の日時が含まれます
  patient_id  –訪問に関連する患者のIDです
   dentist_id  –は  user_has_roleへの参照です  表、役割が歯科医であると仮定
 
   
 
 次はアナメシスです  テーブル。医学では、既往歴は、患者の現在の状態などの病歴を収集して保存する手順です。 アナメシス  テーブルにはこのデータが格納されます。これはオフィスに到着してすぐに発生するため、イベントごとに最大1回の既往歴があります。表の属性は次のとおりです。
    anamnesis_id  –は  anamnesisの主キーです    visitも参照するテーブル  テーブル
   user_anamnesis_id  –これは  user_has_roleに関連しています  テーブル。歯科医が既往歴を持っている必要はないことに注意してください。
 メモ –特定の既往歴に関するテキストノートが含まれています。必須フィールドではありません。
 
   
 
   anamnesis_type   tableは、  anamnesis_catalogで参照されるすべての可能な値を格納するために使用される単純な辞書です。  。唯一の属性はtype_nameです 、および「病気」、「アレルギー」、「使用した薬」などの値を含めることができます。もちろん、その唯一の属性は必須です。
   
 
   anamnesis_catalog   表は、  anamnesis_typeに格納されている値よりも具体的な情報を提供する辞書です。  テーブル。特定の病気、アレルギー、投薬に関するデータを保持するために使用します。属性はすべて必須であり、次のものが含まれます。
    catalog_name  –は特定の  anamnesis_typeの名前です  サブカテゴリ
   anamnesis_type_id  –は  anamnesis_typeへの参照です  テーブル
 
   
 
   visit_anamnesis   テーブルは、訪問データを既往歴カタログの値に接続するために使用されます。テーブル内のすべての属性が必要です：
    anamnesis_anamnesis_id  –は  anamnesisへの参照です  テーブル
   anamnesis_catalog_id  –は  anamnesis_catalogへの参照です  テーブル
 
 
   visit_anamnesisに注意してください  tableは、  anamnesisというラベルの付いたテーブルを接続する多対多の関係です。  およびanamnesis_catalog   。このペアを保存する意味はありません（ anamnesis_anamnesis_id  ＆ anamnesis_catalog_id  ）2回。そのペアを主キーとして使用します。
   
 
 ドキュメント  表は、患者のドキュメントを保存した場所を含む単純なカタログです。このようなドキュメントの例としては、患者のカルテ、X線、請求書のスキャンがあります。もちろん、これらのドキュメントをデータベースに直接保存することはありません。これは、ドキュメント管理システムの失礼な単純化です。 ドキュメント内の属性  テーブルは（すべて必須）：
  説明 –は短いドキュメントの説明です
 場所 –正確なドキュメントの場所が含まれています
  patient_id  –は患者への参照です  テーブル
 
   
 
 歯  表は、後で歯科医がどの歯が問題であったかを指定するときに使用される単純な辞書です。このテーブルのすべての属性は必須です。それらは：
    is_baby_tooth  –は、歯が赤ちゃんの歯であるかどうかを単にマークするブール値です。もちろん、両方の歯の値が重複する可能性があります。手順は歯の種類によって異なる場合があるため、これは重要です。
 歯 –歯の作業を行うために使用される説明です–通常、その値は画面に表示されます。
 
   
 
   problem_catalog   表は別の単純な辞書です。これには、歯や口に通常見られるすべての問題のリストが含まれています。このカタログで考えられる値の例は、「虫歯」、「酸蝕症」、「歯肉炎」、「口内痛」、「魅力のない笑顔」です。  problem_nameのみ 属性は必須です。
   
 
   problem_detected   表は、訪問、歯、および問題のカタログデータを治療に接続します  テーブル。 歯への参照が含まれています  、  problem_catalog   および訪問  テーブル。  tooth_idを除くすべての属性は必須です 。この例外の理由は、一部の問題が1本の歯だけに関連していないためです（たとえば、歯肉炎は歯茎に関連しています）。これらの3つの属性は、一緒に代替キー（UNIQUE）を形成します。他の2つの属性は次のとおりです。
    Suggested_treatment_id  治療への参照です  テーブル（歯科医によって提案された治療法）。すべてがOKで、処理が不要な場合は、NULL値になる可能性があります。
   selected_treatment_id  治療への別の参照です  テーブル。これには、使用に同意した治療歯科医と患者に関するデータが含まれています。おそらく患者が提案された治療法や他の可能性について考える時間が必要なため、これはNULLになる可能性があります。
 
 
 属性suggested_treatment_idに注意してください およびselected_treatment_id どちらも治療を参照しています  テーブル。これを行うことができるのは、最大で2つの値を格納するだけでよいためです。もちろん、保存する値の数が事前にわからない場合は、ここで多対多の関係を使用する必要があります。
   
 
 ステップ  表は、すべての治療で可能なすべてのステップを含む単純な辞書です。表の属性（すべて必須）は次のとおりです。
    step_name  –画面上で使用される短いステップ名です
 説明 –このステップで実行されるアクションの説明です
 
   
 
 治療  表は実際、歯科医院が提供するすべての治療法の辞書です。ほとんどの治療は通常いくつかのステップで構成されているため、どのステップが最終的なものであるかを知る必要があります。表の属性はすべて必須です：
   treatment_name  –はシステム内の治療の名前です
 説明 –簡単な治療の説明です
   final_step_id  –はステップへの参照です  テーブル。この情報を使用して、治療が終了したかどうかを検出して自動アクションを開始するか、その情報をユーザーに表示して、ユーザーに次のアクションを選択させることができます。
 
   
 
  treatment_steps   テーブルは、ステップと治療をつなぐ多対多の関係です。表の必須属性は次のとおりです。
   treatment_id  –は処理への参照です  テーブル
   step_id  –はステップへの参照です  テーブル
   step_order  –は治療のステップの順序を定義する番号です
 
 
 この表では、2つの代替キー（UNIQUE）が定義されています。
  ペア（treatment_id  ＆ step_id  ）–このステップは1回だけ治療に割り当てることができます
 ペア（treatment_id  ＆ step_order  ）–同じ注文番号で2つのステップを処理することはできません
 
   
 
   visit_steps   表は、その訪問後に実際に実行されたすべてのステップのリストです。それらを別々のテーブルに保存する理由は2つあります。
  治療法を選択した可能性がありますが、そのために定義されたすべての手順が必要なわけではありません。
 このようにして、ステップが実行された実際の時間を保存します。
 
 
 テーブル内の属性（ problem_detected_idを除くすべてが必須です およびnotes ）は次のとおりです：
    visit_id  –は  visitへの参照です  テーブル
  treatment_steps_id  –は treatment_stepsへの参照です  テーブル
   problem_detected_id  –は  problem_detectedへの参照です  テーブル。この関係により、どの問題がそのアクションを開始したかについての情報が得られます。歯科医が検出された問題とは関係のない行動を取ることを決定した場合は、NULLになる可能性があります。
   step_time  –ステップが実際に実行された日付および/または時刻です
 メモ –必要に応じて、そのステップのメモです
 
   
 
   visit_status   tableは、訪問で発生する可能性のあるすべてのステータスを格納するために使用される単純な辞書です。 「初めてのオフィス訪問」、「最初の訪問」、「治療中」、「治療が正常に終了した」などのステータスを使用できます。  status_nameという1つの属性のみが含まれています 、これは必須です。
   
 
 visit_status_history   テーブルは、訪問が通過したステータスに関するデータを格納するために使用されます。特定のアクションが完了した後（たとえば、既往歴の後、いくつかの治療のいくつかのステップを完了した後）、手動でステータスを追加すると考えられます。すべて必須の属性は次のとおりです。
    status_time  –ステータスが挿入された日時です
   visit_status_id  –は  visit_statusへの参照です  テーブル
   visit_id  –は  visitへの参照です  テーブル
 
 歯科データベースモデルの改善の可能性
 
 私たちのモデルは順調なスタートを切っていますが、改善される可能性があります。たとえば、次の項目は対象外です：
  支払い方法と請求書
 会議のスケジュール（ただし、これは  visit_steps にデータを挿入することで実行できます）  今後のイベントの表）
 ドキュメントの処理
 
 
 それでも、それはあなたにあなたの歯科医院とその手順について異なった考えをさせますね？