リレーショナル型が変えたデータ管理の未来【ChatGPT統計解析】
現在のデータベースには階層型、ネットワーク型、リレーショナル型などがあり、階層型はデータが階層構造、ネットワーク型は網目状の構造を特徴としますが、いずれもデータ構造変更の難しさが課題でした。これを解決するため1970年にCodd博士がリレーショナルデータモデルを提唱し、1979年に製品化されました。リレーショナル型は表形式でデータを扱い、物理構造の変更がアプリケーションに影響しないため広く普及しています。SQLはリレーショナルデータベース操作のために開発され、標準化されています。さらに、辞書テーブルを利用することでコード管理が容易になり、入力データの整合性を保つ役割も果たします。セットアップにはテーブル定義、ビュー作成、入力画面設計、データチェック機能設定が含まれ、臨床試験などにおいても有用です。
▼▼▼▼▼▼▼▼
チャンネル登録はこちら
データベースの種類
コンピュータで現在,利用できるデータベースには様々な種類がある.
論理構造と物理構造が一致しているデータベースとしては,階層型データベースとネットワーク型データベースが知られている.
そして,階層型は,データ構造が階層構造になっており,親レコードは複数の子レコードを持てるが,子レコードはただ一つの親レコードしか持てないという特徴を持つ.
ネットワーク型は,各レコードの間の関係付けが網目状になっており,子レコードは複数の親レコードを持つことができるという特徴を持つ.
ただ,いずれもプログラムの作成者はデータ構造や,そのデータが物理的にどういう順番で保管されているかなどの情報を知っていなければならないことに加え,データベース作成後のデータ構造の変更などが難しいことが課題となっていた.
このような課題を解決するために,論理構造と物理構造が独立したデータベースとしてデータを表の形で表現するリレーショナル・データ・モデルがIBMのEdgar Codd博士によって1970年に発表された.
しかしながら,この段階ではあくまで理論としての発表であり,市場に初めて製品が登場したのは1979年にRelational Software Inc. (現Oracle社)により発売されたOracleであった.
当初は,階層型などに比べて複数のファイルを組み合わせて処理するためにオーバーヘッドが大きくなるのでパフォーマンスが悪く,実務への導入に時間がかかったが,現在ではコンピュータの進化に伴いパフォーマンスの問題も大きく改善されている.
ユーザーはデータの物理構造を意識する必要がなく,データの論理構造と物理構造が独立しているため,物理構造が変更されてもアプリケーションプログラムを変更する必要がない.
これはコンピュータを利用する上で極めて優れた点であり,数多くのプロダクトが市場に投入されており,現在ではリレーショナル型が事実上のデータベースシステムの主流を占めている.
リレーショナルデータベース
リレーショナル型データベース(RDB; Relational Data Base)においては,データは行(レコード; record)と列(フィールド; field)の2次元からなる表(テーブル; table)として構成され,複数の表で関係を結ぶ(リレーションシップ; relationship)ことにより,複雑な構造のデータを単純化して取り扱うことができるようになっている.
また,データベースの構造を記述したものをスキーマ(schema)と呼ぶ.
たとえば、テーブル「社員」とテーブル「事業所」を「所属」というキー項目で結合(join)させることにより社員名簿用データを作成することができる.
このようにリレーショナルデータベースにおいては,最初から完成されたデータ構造を決定しておく必要がなく,適宜テーブルを作成してキー項目により組み合わせて利用することができるため,手軽に利用することができる.
もちろん,最初から下段のようなテーブルを作成することも可能であるが,もし事業所の住所が変更になった場合には該当する全てのデータについて書き換える必要があるのに対し,上段のようにテーブルが分割されている場合にはテーブル「事業所」の該当データを一回だけ書き換えればよいという利点がある.
このようなテーブルの結合などを行うリレーショナルデータベース操作のための言語であるSQL (Structured Query Language)は, 1974年にIBMの研究所においてSEQUEL(Structured English Query Language)として誕生し,その後に名称が改定されたのに続き,1986年にANSIで規格化され, 1987年にはISOとJISで規格化されている.
よく使用されるSQL文としては次のようなものがある.
データベース作成 create database [データベース名]
・テーブル作成 create table [テーブル名]
・テーブル変更 alter table [テーブル名]
・テーブル削除 drop table [テーブル名]
・データ照会 select[column]from[テーブル名]
一条件指定としてwhere, group by, order by 節を使用できる
・データ追加 insert into [テーブル名]
・データ更新 update[テーブル名]set[カラム名[値]
ただし,各社が様々な拡張を行っており,ベンダー間での互換性が完全であるとは言えなくなっていることには注意が必要である.
また, SQLを直接に記述しなくてもメニューなどをマウスなどで制御して操作するGUI (Graphical User Interface)を介してデータベースを操作することができるようになっているプロダクトが多い.
データベースの辞書
データベース,とくにリレーショナルデータベースを利用することのメリットの一つとして,コードや用語の管理が容易であるということが挙げられる.
すなわち,辞書(シソーラス)を管理することが簡単になるということである.
たとえば「0:なし」,「1:あり」,「9:不明」というコードとその内容を定義したテーブルを用意し,この定義コードを必要な項目に共通して利用するようにしておけば,もし「8:判定不能」というようなコードを追加する必要が生じた場合にも全ての項目で定義を追加する必要はなく,定義テーブルだけに追加すればよい.
また,用語として適切なものを使用したい場合の管理方法として定義テーブルを利用する場合には,1番目の項目である有害事象名に対応した2番目の項目を器官分類として定義して,集計・解析には器官分類を利用するものとする.
そして,有害事象名に対応する器官分類を示した定義テーブルを用意しておくことにより,有害事象名の内容からこの定義テーブルを参照して自動的に器官分類をセットさせるというテーブル・ルックアップ機能の利用ができる.
こうしておくことにより,器官分類を変更したいという時には,定義テーブルさえ変更すれば済む.
さらに,このアイデアは項目の内容によって日本語から英語への変換というようなことにも応用することが可能である.
これはあくまでも変換であり,コメントなどのような文章を翻訳できるということではない.
このような目的で辞書テーブルを作成・管理する場合には自ら作成する辞書だけではなく,先に述べたMedDRAというようなものも利用することが可能である.
また,入力したデータを辞書テーブルと照合し,辞書テーブルに存在するかどうかを確認することにより,入力データをチェックするという方法がある.
とくにこの方法は入力するデータが文字型データである場合に有用である.
日本語を入力する際には,数字コードなどを用いる場合とは異なり,半角や全角の違い,微妙な送り仮名の違いなど,全く同じ内容であるにもかかわらず,違う言葉が入力されてしまう可能性が高いためである.
データベースのセットアップ
データベースのセットアップには,いくつかの段階がある.
基本的には,ハードウェアやシステムの設定,データベースそのものの設定は完了しているものとして,リレーショナルデータベースの設定から考えてみよう.
まず,最初に行うことはテーブルの定義である.
データ項目の全てをリストアップしておく必要はないが,少なくとも必要となる全てのテーブルとキー項目,リレーションなどは,予め紙に図としてまとめておくと作業が容易になる.
たとえば,「患者背景」というテーブルを作成する.
次いで,このテーブルに含まれるデータ項目,たとえば患者IDは5バイト長の文字型データ,年齢は整数型データ,性別は1バイト長の文字型データというようなことを定義する.
さらに,性別では「M:男性」と「F:女性」という使用するコードを定義する.
これらの設定は,既に準備されているメタデータから選択する形式で作業ができれば,ほかの臨床試験データベースとの整合性を心配する必要もなく,効率的に作業を行うことができる.
また,この段階で投与開始日と投与終了日から自動的に投与日数を計算するなどの項目間演算の定義や,辞書変換のようなテーブル・ルックアップの設定も行う.
このようにして全てのテーブルを準備した後,必要に応じて「患者背景」テーブルと「効果判定」テーブルは「患者ID」により1:1で結び付けられるというようなテーブル間のリレーションの設定や,複数のテーブルを組み合わせて作成される仮想的なテーブルであるビュー(view)の作成などを行う.
次に,テーブルやビューを利用して,入力画面の作成を行う.
入力画面は誰もが容易に入力できることを考えると,症例報告書と同じレイアウトであることが望ましい.
ただし,画面のスクロールが必要になったりするようであれば逆に操作が大変になる可能性があるため,ページを分割することなども考慮して無理に症例報告書と同じレイアウトにこだわることはない.
また,この入力画面を作成する際に,最小値と最大値などのレンジチェック,投与終了日は必ず投与開始日より後でなければならないというようなデータチェック機能も設定しておく.
なお,データチェック機能を設定する際に注意しなければならないことがある.
プロトコルで登録時の年齢が20歳から65歳までと定義されていれば年齢の項目に最小値として20,最大値として65というレンジチェック機能を設定することはできる.
ただ,現実的に67歳という患者が登録されてしまうことはあり得る.このような場合を考え,警告は表示されたとしてもデータ入力が行えないようでは困るので注意が必要である.
以上で,臨床試験データの入れ物としてのリレーショナルデータベースのセットアップは完了である.
この後,必ずアクセプタンス・テスト(Acceptance Test)を実施し,問題がある場合には必要な修正を行う.
また,必要に応じて出力帳票の設定を行う.
システムバリデーションのため,定義したテーブルや項目の情報,リレーション,入力画面,データチェック機能などについてはプリントアウトして確認できるようになっていなければならない.
パーソナルコンピュータ上で利用できるようなリレーショナルデータベースでは,そのアプリケーションだけではこのような情報をきちんとプリントアウトすることができないものもあるので予め機能を確認しておくことが必要である.
現在のデータベースには、階層型データベース、ネットワーク型データベース、リレーショナル型データベースなどがあり、それぞれ特有の特徴と利点があります。階層型データベースは、データが階層構造で表現され、親レコードが複数の子レコードを持つことが可能である一方、子レコードは一つの親レコードしか持つことができません。これに対し、ネットワーク型データベースはレコード間の関係が網目状になっており、子レコードが複数の親レコードを持つことが可能です。しかし、これらのモデルでは、プログラム作成者がデータの物理的な格納順序やデータ構造を詳細に把握している必要があり、また、データベース作成後の構造変更が難しいという課題が存在しました。こうした課題を解決するために、1970年にIBMのEdgar Codd博士が提唱したリレーショナルデータモデルが登場しました。このモデルでは、データを行(レコード)と列(フィールド)から成る表(テーブル)形式で表現し、論理構造と物理構造を独立させることで、アプリケーションプログラムに影響を与えることなく物理構造を変更できる柔軟性を提供しました。しかし、当初は理論として発表されたものであり、市場に初めてリレーショナルデータベースが製品として登場したのは1979年、Relational Software Inc.(現在のOracle社)による「Oracle」が最初でした。初期のリレーショナルデータベースは、階層型やネットワーク型に比べて複数のファイルを組み合わせて処理するためにオーバーヘッドが大きく、性能が低いとされていましたが、コンピュータの進化に伴い、パフォーマンスの問題は次第に解消され、現在ではリレーショナル型がデータベースシステムの主流となっています。リレーショナルデータベースは、ユーザーが物理構造を意識する必要がなく、アプリケーション開発の効率性が高い点が広く評価されています。このモデルでは、複数の表で関係性(リレーションシップ)を設定することで、複雑なデータ構造を単純化して扱うことが可能です。データベース構造を記述したものはスキーマと呼ばれ、たとえば「社員」テーブルと「事業所」テーブルを「所属」というキー項目で結合することで社員名簿を作成できる仕組みが挙げられます。このように、リレーショナルデータベースでは、データ構造を最初から完全に設計する必要はなく、必要に応じてテーブルを追加し、それらを結合して利用することが可能です。この柔軟性により、データの保守や変更が容易になるという利点があります。さらに、リレーショナルデータベースを操作するための標準言語であるSQL(Structured Query Language)は、1974年にIBMの研究所で開発され、1986年にはANSIで、1987年にはISOとJISで標準化されました。SQLでは、データベースの作成、テーブルの作成・変更・削除、データの照会、追加、更新などが行えます。また、条件指定や集計機能を組み合わせることで複雑なクエリの実行も可能です。現在では、SQLを直接記述しなくても、GUI(Graphical User Interface)を通じて操作できる製品も多く、初心者から専門家まで幅広く利用されています。リレーショナルデータベースのもう一つの重要な特徴は、辞書テーブルを利用することでコードや用語の管理が容易になる点です。たとえば、「0:なし」「1:あり」「9:不明」というコードを定義したテーブルを使用し、必要な項目に共通して利用することで、コードの追加や変更が容易になります。また、有害事象名に対応する器官分類を定義するテーブルを用意し、このテーブルを参照して器官分類を自動設定する機能も利用できます。これにより、器官分類や他のコードを変更する際にも、定義テーブルを修正するだけで済むため、データの整合性を保ちながら効率的な運用が可能です。さらに、辞書テーブルは日本語から英語への変換などにも応用でき、データの一貫性を確保するためのツールとしても活用されています。リレーショナルデータベースのセットアップには、まずテーブルの定義を行い、キー項目やリレーションを設計します。たとえば、「患者背景」テーブルでは、患者ID、年齢、性別などの項目を定義し、それぞれのデータ型やコードを設定します。また、メタデータを活用することで、ほかのデータベースとの整合性を確保しながら効率的に作業を進めることができます。この段階で、辞書変換や項目間演算などの設定も行い、たとえば投与開始日と終了日から投与日数を自動計算する機能を追加することも可能です。全てのテーブルを準備した後は、入力画面を作成します。入力画面は、症例報告書と同じレイアウトにすることが望ましいですが、操作性を考慮してページ分割なども検討されます。さらに、レンジチェックや日付の前後関係を確認するデータチェック機能も設定され、プロトコルの条件を満たしながら柔軟にデータを入力できるようにします。これらの設定が完了した後にはアクセプタンス・テストを実施し、必要に応じて修正を行います。データベース運用の際には、出力帳票の設定も行い、リレーショナルデータベースの特徴であるデータの一貫性や柔軟性を最大限活用します。また、システムバリデーションのため、テーブルやリレーション、入力画面、データチェック機能などの情報をプリントアウトして確認できる状態にしておく必要があります。特に、パーソナルコンピュータ上で利用する場合、アプリケーションがこうした情報を適切に出力できるかを事前に確認することが重要です。このように、リレーショナルデータベースは、柔軟性や保守性の高さ、効率的な運用を可能にする点で、現代のデータ管理において欠かせない存在となっています。
関連記事