まず、データベースのデータの管理方法は、エクセルのブックなどのファイルの管理方法とは異なります。
ブックならディスクからメモリ上に読み込んで、更新後ディスクに上書きします。
つまりディスク上のデータ位置は連続しているし、データの順番も固定されています。
Accessの場合は、テーブルデータの更新、削除、追加した場合、データの連続性、データの並び順は保証されません。
更新した場合同じ位置に上書きされるとは限りません。
削除した場合、実際に削除されるわけではなく削除フラグを立てるだけです。
追加した場合、ファイルの最後に追加されるわけでもありません。
これは大量のデータを扱うデータベースに最適化された設計です。
つまり更新、削除、追加を繰り返すと、データの連続性はなくなり、データの並び順もごちゃごちゃになります。
このままではファイルサイズは肥大して、パフォーマンスも落ちます。
データ破損の危険性も高まります。
この非連続性を解消して、並び順もキーフィールドに合致するようにするのが「データベースの最適化/修復」という処理です。
Accessデータベースにおいて定期的な「データベースの最適化/修復」というのは必須といえます。
「テーブルのコピー」→「リネーム」で解決できる場合もあるかもしれませんが、それでは上記の非連続性は解消されませんので根本的な解決にはならないでしょう。
また、データペースにおいて、リレーションシップが設定されていれば、コピー→リネームの前にリレーションシップの削除、リネーム後にリレーションシップの再設定という作業も必要になり煩雑になります。設定ミスで破損なんてことにもなりかねません。
「データベースの最適化/修復」でやっていることは、元のデータベースファイルからデータをキーフィールドの並び順に読み込んで、新規データベースファイルに書き込むという処理をして、完了後に元のファイルを削除して新規ファイルをリネームするということをしています。つまり「洗い替え」をしているということだと思います。
経験上「データベースの最適化/修復」を定期的にやっていればめったに破損することはないです。
ただ、絶対破損しないということはないし、「データベースの最適化/修復」で修復できない場合もないとは言えないので、定期的にデータベースファイルのバックアップを取るという運用も必須でしょう。