If we had to justify the rationale and the aim of the database approach, what would spring to mind?

• Data Independence: both, Logical data independence, Physical data independence.
• Data redundancy.

"Transparency refers to the separation of the higher-level semantics of a system from lower-level implementation issues."

• Thus, data independence is a transparency issue.
• For a distributed database approach there are other issues.

We want to choose and use those distributed DBMS that offer the highest level of transparency support.

• Data replication is common in distributed databases. Which site to query? Which site to update first and then the rest (with cascades)?
• If a site (or a link) fails then, on re-connecting the isolated sites, the relevant data commits done during the interruption must be updated.
• Transaction scheduling over multiple sites is much harder than the centralised case.

• Lack of experience or complete knowledge.
• Complexity.
• Costs.
• Control.
• Security.
• Upgrading a database to a distributed database is not self evident.

• Performance.
• Reliability.
• Upsizing.
• Shareability.
• Local autonomy.

Strange combination.

• Databases are a logical repository of structured data. With most implementations having a centralised framework.
• High level networks promote sharing.

Could a database be made available to a number of users without specifying a "single" computer? – Yes.

How?

• Distributing the data.
• Distributing the DBMS processing.
• Distributing the database control etc.

What do we need?

• More refined database techniques.
• Better and new DBMS technology.
• A networking infrastructure that connects all of the databases' end users.