リファクタリング (データベース)

出典: フリー百科事典『ウィキペディア（Wikipedia）』

データベースのリファクタリング（Database_refactoring）はデータベースの計画ないし枠組み（英: database schema ）についてのひとつの単純な変更である。

解説[編集]

それはその挙動と'情報的意味'（英: informational semantics ）を保ったままその設計を改善するものである。データベースのリファクタリングはデータの解釈や利用の方法を変更しないしまたバグの修正や新たな機能を付け加えるものでもない。データベースに対するそれぞれのリファクタリングは稼働状態においてそのシステムを保つ、したがって管理による遅延を引き起こさずに、その生産環境においてその有効なデータの存在を与える。

データベースのリファクタリングは概念的にはプログラムコードのリファクタリングよりも難しい；コードのリファクタリングは挙動上の意味を管理する必要だけであるのに、データベースのリファクタリングは情報上の意味も管理しなければなならない。

データベースの図式は大抵幾つかの理由の一つによってリファクタリングされる：

  1. システムを保ったままの発展的な設計と併行して発展的な'作法'（英: manner）において計画を開発すること。
  2. 既存の資産のデータベースの計画のもとに設計の問題を改善すること。データベースのリファクタリングは、たいていそのデータベースの設計の「清掃（英: clean up）」である、しばしば既存の作られたデータベースの正規化についての欲求により動機づけられる。
  3. 小さな、危険性が低い変更の系列として、大きな（そして潜在的に危険な）変更になるようなものを実装すること。

データベースのリファクタリングの範疇[編集]

2006年にスコット・アンブラー（英: Scott Ambler）とピラモド・サダラージ（英: Pramod Sadalage）[1]はデータベースのリファクタリングの範疇を述べた[2][3]。

2019年にウラジスラブ・スツルジック（英: Vladislav Struzik）は新しい一つのものをもってデータベースのリファクタリングを補充した[4][5]。

データベースのリファクタリングの分類[6]
分類 概要 主な例の一つ 例
アーキテクチャ 外部プログラムがデータベースとやりとりする方法を改善するための変更。 コード内の既存のJavaの操作をデータベース内のストアドプロシージャで置き換える。ストアドプロシージャにするとJava以外のアプリケーションでも利用できる。 CRUDメソッドの追加；ミラーリングテーブルの追加；リードメソッドの追加；ビューによるテーブルのカプセル化；計算メソッドの導入；インデックスの導入；読み込み専用テーブルの導入；データベースからのメソッドの移動；データベースへのメソッド移動；ビューによるメソッドの置き換え；メソッドによるビューの置き換え；正式なデータソースの使用[7]
構造 テーブルやビューの定義の変更 テーブル間でカラムを移動する。 カラムの削除；テーブルの削除；ビューの削除；計算カラムの導入；代理キーの導入；カラムの統合；テーブルの統合；カラムの移動；カラム名の変更；テーブル名の変更；ビュー名の変更；テーブルによるLOBの置き換え；カラムの置き換え；関連テーブルによる１対多関係の置き換え；自然キーによる代理キーの置き換え；カラムの分割；テーブルの分割[8]　
データ品質 データベースに含まれる情報の品質を高めるための変更。 カラムのヌル値を禁止して常に値が含まれるようにする。 参照用テーブルの追加；標準的なコードの適用；標準的な型の適用；キー戦略の整理；カラム制約の削除；デフォルト値の削除；ヌル不可制約の削除；カラム制約の導入；共通フォーマットの導入；デフォルト値の導入；カラムのヌル不可への変更；データの移動；プロパティフラグによるタイプコードの置き換え[9]
参照整合性 参照先の行が別のテーブルに存在すること、必要でなくなった行は適宜削除されることを保障するための変更。 2つのエンティティ間に、（データベース外で実装されていた）カスケード削除のためのトリガーを追加する。 外部キー制約の追加；計算カラムへのトリガーの追加；外部キー制約の削除；カスケード削除の導入；ハードデリートの導入；ソフトデリートの導入；履歴のためのトリガーの導入[10]
変換 情報的意味の変更を伴うデータベースの計画の変更。 既存のテーブルに新しいテーブルを追加する。 データの挿入；新たなカラムの導入；新たなテーブルの導入；ビューの導入；データの更新[11]
メソッド 品質を高めるためのメソッド（ストアドプロシージャ、ストアドファンクション、トリガー）の変更。コードのリファクタリングの多くはデータベース内メソッドにも適用可能である。 ストアドプロシージャの名前をわかりやすいものに変更する。 パラメータ化メソッド；パラメータの削除；メソッド名の変更；パラメータの順序変更；陽的なメソッドによるパラメータの置き換え；条件表現の合併；条件の分解；メソッドの展開；変数の導入；コントロールフラグの削除；ミドルマン（英: Middle Man ）の削除；テーブル参照による記号の移動；入れ子の移動；ガード条項による条件；現行の変数の分割；アルゴリズムの縮減
アクセス データアクセスに関する変更。 特権許可の付与 認証属性の変更；特権許可の取消；特権許可の付与；データベースの計画の抜粋；データベースの計画の併合[12][13]

データベースのリファクタリングの処理[編集]

データベースのリファクタリングの処理は既存のデータベースの計画を発展するようデータベースのリファクタリングを適用する行為である（データベースのリファクタリングは発展的データベース設計 （英語: evolutionary database design）の中核の実践である）。考慮を要する三つの点がある：

  1. いかに単一のリファクタリングを実装するか
  2. いかにデータベースのリファクタリングが組織の中へ持ち込まれて共有されるか
  3. いかにデータベースのリファクタリングの系列が適用されるのか

引用文献[編集]

  1. ^ Ambler & Sadalage 2006, p. 384
  2. ^ 表の最初から6行目まで。
  3. ^ Ambler
  4. ^ 表の7行目。
  5. ^ Struzik 2019
  6. ^ アンブラー & サダラージ 2008, p. 22
  7. ^ アンブラー & サダラージ 2008, p. 221
  8. ^ アンブラー & サダラージ 2008, p. 65
  9. ^ アンブラー & サダラージ 2008, p. 143
  10. ^ アンブラー & サダラージ 2008, p. 193
  11. ^ アンブラー & サダラージ 2008, p. 283
  12. ^ Struzik 2020
  13. ^ Struzik 2022

参考文献[編集]

  • Ambler, Scott; Sadalage, Pramod (March 3 2006). Refactoring Database: Evolutionary Database Design (1st. ed.). Addison-Wesley Professional. ISBN 978-0321774514 
    • 上記の和書：スコット・W・アンブラー、ピラモド・サダラージ『データベース・リファクタリング: データベースの体質改善テクニック』（第1版）ピアソン・エデュケーション、東京、2008年4月10日。ISBN 978-4-89471-500-4。 
  • Ambler, Scott, Catalog of Database Refactorings - Agile Data - 
  • Струзік, В. А. (2019)" Категорія рефакторинг доступу / В. А. Струзік // Комп’ютерні науки, інформаційні технології та системи управління : Міжнародна науково-технічна конференція студентів, аспірантів та молодих вчених, 27–29 листопада 2019 р. – Івано-Франківськ : Прикарпатський національний університет ім. Василя Стефаника, 2019. – С. 20-21." 
  • Струзік, В. А. (2020)"Категорія рефакторинг доступу / В. А. Струзік, С. В. Грибков, В. В. Чобану // Наукові праці НУХТ. – Т. 26, № 2. – 2020. – С. 31–49." 
  • Struzik, Vladislav (Jan 24, 2022), Refactoring: yesterday, today, tomorrow. 

関連項目[編集]

「https://ja.wikipedia.org/w/index.php?title=リファクタリング_(データベース)&oldid=97829232」から取得