Consider an environment where we have a single, core database, with many separate systems using this one database.

This leads to all of these systems have a common dependency, which ultimately introduces coupling between them.

This means that we cannot always evolve systems independently of each other. Structural changes to the database (even if only intended for one, particular system), requires a full sweep test of ALL systems, and may require that other systems be 'patched' and subsequently released.

This is especially tricky when you want to have separate teams working on different projects.

What is a good 'pattern' to help in avoiding such coupling?

I would imagine that a database should be exclusively depended on by one system. If other systems require data for whatever reason, they should request such from an API service of some kind.

A drawback of this approach which comes to mind is performance: routing data between high-throughput systems through service calls is much slower than through a database connection.