Ownership of objects within a trusted context
You can simplify the administration of authorization by having roles as object owners. In addition, object ownership carries with it a set of related privileges on the object; you can prevent users from obtaining implicit privileges from object ownership by making roles object owners.
If
the owner of an object is an authorization ID and you need to transfer
the ownership to another ID, you need to drop the object first and
re-create it with the new authorization ID as the owner. You don't
need to take these steps if the owner is a role because all users
that are associated with that role have the owner privilege.
The definition of a trusted context determines the ownership of objects that are created in the trusted context. Assume that you issue the CREATE statement dynamically and that the trusted context is defined with the ROLE AS OBJECT OWNER clause. In this case, the associated role is the owner of the objects, regardless of whether the objects are explicitly qualified.
In contrast, assume that you issue
the CREATE statement statically and that the plan or package is bound
in the trusted context with the ROLE AS OBJECT OWNER clause. In this
case, the role that owns the plan or package also owns the objects
that are created, regardless of whether the objects are explicitly
qualified.