People invent different names for the same things all the time. The English word “Sun,” French “le Soleil,” and German “die Sonne,” all look and sound distinctly different, yet they still refer to the same object. The same concept applied to RDBMSs becomes synonyms and aliases.
Throughout the book, we have used aliasing to rename columns and tables inside an SQL query for convenience reasons, to shorten fully qualified names. These aliases were short-lived, surviving only for the duration of the query. Other queries could have used the same name or come up with its own. Creating synonyms and aliases as database objects allow for creating an alternate reality.
In its most generic meaning, a SCHEMA in RDBMS context is a way to group database objects logically inside a database. The SQL Standard defines schema as a “named group of related objects,” yet different RDBMSs implement it differently. In Oracle, for instance, schema is almost identical to user, while Microsoft SQL Server and DB2 are both closer to its standard meaning. Like other database objects, schemas can be created, altered, and dropped. A detailed discussion of schema is beyond the scope of this book.
Consider Oracle RDBMS. An Oracle database concept is quite different from a database notion of Microsoft SQL Server, for instance: Each Oracle user has his own set of tables, indices, ...