The alias mechanism allows you to treat two or more users as the same user inside a database so that they all have the same privileges. This mechanism is often used so that more than one user can assume the role of database owner. A database owner can use the setuser command to impersonate another user in the database. You can also use the alias mechanism to set up a collective user identity.
For example, suppose that several vice presidents want to use a database with identical privileges and ownerships. If you add the login “vp” to Adaptive Server and the database and have each vice president log in as “vp,” there is no way to tell the individual users apart. Instead, alias all the vice presidents, each of whom has his or her own Adaptive Server account, to the database user name “vp.”
Although more than one individual can use the alias
in a database, you can still maintain individual accountability
by auditing the database operations performed by each user. See Chapter 10, “Auditing.”
The collective user identity from using aliases implies set-ownership for database objects. For example, if user “loginA” is aliased to dbo in in database db1, all objects created by “loginA” in db1 are owned by dbo. However, Adaptive Server concretely records an object’s ownership in terms of the login name and the creator’s database user ID. See “Concrete identification”. An alias cannot be dropped from a database if he or she concretely owns objects in that database.
You cannot drop the alias of a login if that login created
objects in the database. In most cases, use aliases only for users
who do not own tables, procedures, views, or triggers.
