As the documentation subscribes, I have created the DBC DBC substitute, and I have given you the indicated rights.
Logged in as DBADMIN I can create a DB correctly, and then create a Table, but then when I log in as DBC, I have no rights over DB or Table.
Why does DBC not inherit DBADMIN rights?
Ultimately, DBC has complete access to everything on a Teradata system.
However, what DBC may have to do is to GRANT itself the required AccessRights. This is the bit that a Teradata username cannot do unless it is the owner of the object. And as DBC is the ultimate owner of everything, it can do this on any object.
Agreement with your answer, but it is very tedious to have to perform some administrative task, such as copying data to another environment or other basis and find that even as DBC does not have the necessary rights.
In many other databases there are predefined roles to impersonate the DBC.
Faced with this scenario, I can not even think of using an account for each DBA, since the objects would be in the name of each of them ...
...which is why you have (and I think should use) 'Roles'.
Create a 'DBA role' which has all of the Access Rights that a DBA needs in your environment. Then grant the Role to each DBA userid.
Also remember that in most Teradata customers most Access Rights are granted at the database level and not for each individual object. This cuts down on your administrative work, the size of the DBC.AccessRights table and can help with some contention issues that used to affect TD systems.
If you suddenly have a lot of AccessRights to issue, try generating them using SQL.
The concern re each DBA creating things and becoming the creator is a different conversation than where this thread started.
For DBA operations where it is desired to have the DBA log on using their own account for traceability reasons but have behavior as if they are logged on as another user (eg DBADMIN), there is a little known (little advertised) feature of Trusted Sessions called Connect Through. It requires some searching in the docs and some setup but it allows this scenario where the DBAs have separate logins but operate through DBADMIN for priveleges, creator identity,...
IMHO: If DBC is being used for operations like this, then it is being misused. It should be a major exception for anyone to log onto DBC or do any operations from DBC.
DBC is not meant to be used for DBA functions. The separate DBADMIN user or another user at the top of the user database heirarchy but below DBC should be used for these operations. DBC login should be an extremely exceptional operation.
So maybe don't use 'connect through' for DBC, but use it for DBADMIN (or whatever you call it).
I think you have two basic approaches to this.
1) Create a Role that contains 'all' the access rights that are needed by your DBA team. Grant that role to each userid in your dba team. You now have full control and auditing.
2) Create a Role that contains 'all' the access rights that are needed by your DBA team. Grant that role to DBADMIN and then set up 'connect through' for each of your dba userid's running 'under' DBADMIN. You still have audit capabilities because the proxyuser is recorded as a separate column in dbqlogtbl.
Personally I'd go with option#1 above.
I agree with @ToddAWalter that you should not be using DBC on a regular basis. Once your system is initialy set up and you have other 'admin' users defined, IMHO DBC should typically only be used for software upgrades and even then it is normally Teradata CS staff who will run those jobs.