まず、オブジェクト指向の用語でデータベースを考えようとするのをやめます。オブジェクト指向プログラミングの原則は、リレーショナルデータベースには適用されません。
共有データベースは、ビジネスの観点からは非常に優れています。それらの間で転送する必要のある情報を格納する複数のデータベースは、何百ものオブジェクトよりもはるかに複雑になります。エンタープライズアプリケーション間で一貫性のあるデータは貴重です。GECorpとGeneralElectricCorporationが2つのデータベース間で実際に同じエンティティであるかどうかを調整しようとすると、悪夢になる可能性があります。
データベースのリファクタリングは素晴らしい目標ですが、実際には非常に複雑です。対処する必要のある大きなパフォーマンスの問題がある場合、または変更の影響を受ける可能性のあるすべてのコードを特定するプロセスにコミットする意思がない場合を除いて、これを行わないでください。それでも、変更される可能性のあるすべてのコードを知っているかどうかを検討してください（これが、データベースの人々が動的コードを嫌う、嫌う、嫌う理由の1つです！）。
多くの場合、リファクタリングの最良の方法は、変更を追加し、設定された有効期限まで古いフィールドをそのままにして、新しいフィールド、spなどの使用に切り替え始めることです。あなたは年次サイクルにいるので、あなたはそれらの日付を長期間にわたって管理する必要があります。spsが使用されているかどうかを確認するには、不明なspsを特定し、実行するたびにテーブルに挿入するコードを追加します。1年のサイクルを経ても実行されていない場合は、安全に削除できます。spによっては、サイクルが短くなる場合があります。
年に1回しか実行されないものを書いている場合、通常はspの名前に年次という単語を入れます。しかし、それはあなたがいる場所では当てはまらないかもしれませんが、spの関数は、それが定期的にのみ実行されるべきものであるかどうかをあなたに教えてくれるはずです。usp_send email procが1年に1回だけ実行されるとは思いませんが、usp_attendance_reportが頻繁に実行されるとは思わないかもしれません。もちろん、私が言ったように、私はそれをusp_annual_attendance_reportのような名前にしたでしょう、そしてあなたはその種のことを前進させることを考えることができます。
ただし、必要なものを削除しないようにするには、リファクタリングを長いサイクルで実行する必要があることに注意してください。コードがソース管理システムにある場合（そしてすべてのデータベーステーブル、sp、ビュー、UDF、トリガーなどが必要です）、失敗した場合はすぐに元に戻すことができるので、おそらくいくつかのことを排除できます。繰り返しになりますが、オブジェクトを調べて、それらを排除することで発生する可能性のあるリスクを判断します。
もちろん、適切な自動テストが実施されている場合は、開発で何かを削除してテストを実行すると、何かがまだ参照されているかどうかを確認するのに役立ちます。
あなたがリファクタリングする簡単な方法を探しているなら、私はそれを知りません。データベースのリファクタリングは、時間のかかるリスクの高いアクティビティであり、そのために喜んで支払う力に対して十分な改善が見られない可能性があります。
データベースのリファクタリングに関する優れた本は次のとおりです。http：//www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533