1

次のテーブルを持つデータベースがあります。

PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS)

フィールドMEDICAL_EXAMINATIONSには、患者が実施した検査のフリーテキストの説明が含まれています。

最近、健康診断は（いつものように）フリーテキストとして、または構造化された方法（検査名、日付、結果などで分割）で報告できることが決定されました。

そこで、スキーマを次のように変更することを考えました (アスタリスクでマークされたフィールドがキーを構成します)。

PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS)
MEDICAL_EXAMINATION (PATIENT_ID*, NUMBER*, NAME, DATE, RESULT)

しかし、同じ情報 (健康診断) が 2 つのテーブルに格納されているため、この解決策は少し気がかりでした。この場合、「患者が受けたすべての健康診断を選択する」というクエリの結果は、それほど「エレガント」ではありません。

私の質問をどのように表現したらよいかわかりませんが、この状況は私には奇妙に思えます。問題が本質的に仕様 (変更できない) に起因するのか、それとも「2 つのバージョン」のデータをモデル化するためのより良い方法があるのか​​ 疑問に思います。

4

9 に答える 9

3

個人的には、健康診断の概念を患者から完全に2つの別々のテーブルに分けます。

PATIENT(PATIENT_ID)
MEDICAL_EXAMINATION(PATIENT_ID,NAME,DATE,RESULT)
MEDICAL_EXAMINATION_NOTES(PATIENT_ID,NOTES)

「メモ」はテーブル名の大まかな推測です。ユースケースが何であるかに基づいて、これにはより適切な名前がある場合があります。

これにより、将来のある時点で複数の「自由形式」の検査を選択できるため、柔軟性が向上します。

データ構造が異なるため、これらの両方を選択することは常に面倒です。次のように、それらをまとめたい場合は、おそらく最小公分母に制限され、文字列としてそれらを引き出します。

SELECT 'Name ' + NAME + ', Date ' + DATE + ', Result: ' + RESULT AS EXAM
FROM MEDICAL_EXAMINATION WHERE PATIENT_ID = @PATIENT_ID

UNION ALL

SELECT NOTES AS EXAM FROM MEDICAL_EXAMINATION_NOTES WHERE PATIENT_ID = @PATIENT_ID

さらに良いことに、このデータベースがある種のビジネスオブジェクトをサポートしている場合は、「自由形式」と「構造化」の検査用に別々のクラスを用意し、次に健康診断の文字列表現を提供する共通のインターフェイスを用意します。そうすれば、ビジネスレイヤーには、それらを個別に処理するか、一緒に使用するかを選択できます。

于 2009-10-29T13:46:46.040 に答える
2

リレーショナル データベースの主要な規則の 1 つは、Joe Celko によって "One Fact, One Place, One Way" ("One Time" が追加されることもあります) として表現されています。データ (見た目からして非常に重要なデータ) をデータベースに 2 回存在させ、2 つのまったく異なる方法で格納することは、良い考えではありません。次のようなことができますか？

  • 検査のために存在しなければならない重要な事実がある場合は、それらの列を作成します (名前、日付、結果の場合と同様)。
  • それを考えると、説明には他に何が含まれるでしょうか? これを個別に提示して、独自の列に保存しようとします（たとえば、コメント）
  • これにより、関連データに基づいて、「標準化された」フリーテキストの説明をオンザフライで作成できます。

それ以外の場合は、情報を得るために、2 つの異なる、おそらく意見が一致しない情報源を選別する必要があります。

于 2009-10-29T13:50:42.543 に答える
2

私はするだろう：

  • 患者：ID、名前、生年月日、検査など
  • 健康診断: ID、患者 ID (FK)、名前、日付、結果

Patient.Examinationフリーテキスト フィールドは、基本的に未処理または未転写の試験と考えてください。アイデアは、フリー テキスト フィールドからデータを転記する際に、そこからデータを削除して別のテーブルに追加するというものです。

ただし、これにより、あらゆる種類のエラー検出と制御の問題が発生します。医療転写はデリケートな領域です (当然のことです)。

おそらく、これをさらに正規化し、考えられる各検査を記述し、それに ID とその他のデータを与えてから、検査 ID を単純な Name 列の代わりに Medical Examination エンティティに入れることができます。

しかし、それはすべてあなたの要件に依存します。

于 2009-10-29T13:44:10.013 に答える
2

たいした状況じゃない。もう少しクリーンなアプローチの 1 つは、健康診断を患者テーブルから除外し (いずれにせよそこには属しません)、健康診断テーブルに患者 ID、名前、日付、結果、および自由文字列を含めることです。特定の行の free_text 値が入力された場合、他の行は無視されます。たとえば、日付をDBの必須フィールドにすることはできませんが、それでも現在のバージョンよりは優れていると思います。

また、悪いデータから良いデータに移行するためのパスも提供します。

フェーズ 1: ほとんどの患者には、複数の検査を説明するフリー テキストを含む単一の関連する medical_examination 行があります。

フェーズ 2: ほとんどの患者には、複数の関連する medical_examination 行があり、それぞれの個別の検査を説明する自由テキストがあります。

フェーズ 3: ほとんどの患者には、個別の検査ごとに構造化データを含む複数の関連する medical_examination 行があります。

于 2009-10-29T13:44:20.257 に答える
0

「最近、健康診断はフリーテキスト（いつものように）または構造化された方法（検査名、日付、結果などで分割）のいずれかで報告できることが決定されました。」

これは私を非決定（おそらく非認知者によってなされた）として思い起こさせます。私がそれを理解できることから、このいわゆる「決定」は、情報提供者に、構造化されているかどうかにかかわらず、彼が望む方法で情報を提供する自由を残しています。（注：情報プロバイダーが「構造化」と「非構造化」の間で決定的な選択を強いられた場合、私の回答は適用されません。）

「構造化」とは、情報プロバイダーが準拠する必要のある「レイアウトルール」（例：CSV）と「コンテンツルール」（例：「examNameは既知のコース/試験の名前である必要があります」）があることを意味します。

しかし、定義による「非構造化」は、「情報提供者が提供する情報が何であれ、その情報は常に少なくとも「非構造化」を満たすことを意味し続けます。したがって、提供される情報は、定義上、「非構造化」の下で常に受け入れられます。構造化された」解釈。

したがって、このいわゆる「構造化も許可するという決定」は、まったく役に立ちません。そして（私が述べた警告を考慮に入れると）、論理的な結論は、この決定（完全に偽物のように見える）で「何もしない」ことがあなたの最良の選択肢であるということです。

「でも、それはできない」と思うことは間違いありません。あなたの経営陣が論理的に十分に根拠のある推論に完全に鈍感であるならば、あなたは正しいかもしれません。

PS

「一事実一箇所一方向」の発言について：このような事例は、なぜそれを（一時的に！）「一事実一箇所一本」に緩和する必要があるのか​​を説明しているのかもしれません。 2つの可能な方法」。ユーザーのペースでの移行を容易にするためだけに。

于 2009-10-29T20:53:28.957 に答える
0

MEDICAL_EXAMINATIONテーブルに列コメントを追加できます。

次のようになります

MEDICAL_EXAMINATION (PATIENT_ID, NAME, DATE, RESULT,comment)

したがって、非構造化データをコメント列に保存できます。

于 2009-10-29T13:48:14.697 に答える
0

これは難しい問題であり、私がそれらを解釈する際に賛成票を投じる過程にあるいくつかの良い答えがここにあります.

私の個人的な道筋は、患者の行からフリー テキストの検査列を分割することです。ほとんどの物理モデルでは、ntext、text、または varchar(MAX) などになり、行のスペースを占有することは望ましくありません。これらの型は通常、データを行の外に格納しますが、いずれにしても、 出して良かったです。通常、私は患者に 1 対 1 で対応します。これにより、患者の列が小さくなり、管理しやすくなります。

次に、データが解釈され、抽出され、列と行に正規化された別のテーブルを作成します。

あなたはデータが同じだと言います。その場合、フリー テキストを保持する必要はなく、正規化された検査表を使用できます (さらに、元の「フリー テキスト」を再構築するためのビューを作成することもできます)。

実際には、私は通常、フリー テキストをレガシーとして扱い、アクセスを制限し、正規化されたデータからすべてのビューと更新を実行します。フリー テキストを正規化されたバージョンと同期して維持する必要がある場合、これをトリガーのように処理するための多くの手法がありますが、個々のトランザクションの変更が許可されていて、「フリー テキスト」にいくつかの情報が必要な場合、それらは非常に面倒になる可能性があります。パーツ変更。

于 2009-10-29T18:02:42.833 に答える
0

ここにあるのは半構造化データの例です。これに対処する 1 つの方法は、XML データ型フィールドを使用することですExamDetails。あなたが持つことができます：

<root>
 <ExamName></ExamName>
 <ExamResult></ExamResult>
 <FreeText></FreeText>
</root>

すべての要素がすべてのレコードに存在する必要はありません。フィールドをクエリするには、DB XML 機能を使用します。すべての市長 DB (MS SQl サーバー、Oracle、DB2) は、XML を格納およびクエリできます。

さらにいくつかのメモ:
少なくとも 3 つのテーブルがあります: 患者、医師、検査

TABLE Patient (ID (PK), Name, other patient details...)
TABLE Doctor (ID (PK), Name, other doctor details...)
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...)

医師と患者の両方がたまたま人間である場合 (獣医クリニックや家の検査とは対照的に)、テーブル Person を追加し、サブタイプの患者テーブルと医師テーブルを Person テーブルに追加できます。このようにして、医師を簡単に患者としてのクリニックも。例えば：

TABLE Person (ID (PK), FirstName, LastName, Phone, Address, other details common to people...)
TABLE Patient (PersonID (PK, FK), ...specific patient details only)
TABLE Doctor (PersonID (PK, FK), ...specific doctor details only)
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...)

患者と医師は個人のタイプであるため、PersonID は Person テーブルの ID と同じ番号である必要があります。

クリニック_モデル

于 2009-10-29T16:22:33.347 に答える
0

NAME、DATE、RESULT カラムを PATIENT テーブルに追加できます。「自由形式データまたは構造化データのいずれかを保持する必要があるが、両方を保持する必要はない」という条件が成立する必要がある場合は、条件違反を防止するトリガーを追加できます。

于 2009-10-29T13:43:46.657 に答える