Specific dbcontext per use case or an all in one context?

I searched for some time for a suitable solution for my question, but did not find a compelling answer.

So don't abandon this question if it is in the wrong place or answered elsewhere. Please state a hint where to put it or where a possible answer may to be found. It will be appreciated.

Assume there is a database with tables as shown here:

table user {    int id primary;    varchar(50) lastname;    varchar(50) firstname;    varchar(50) externalUserID;    varchar(50) onewayencryptedpwd;}table applicationright {    int id primary;    varchar(50) displayname;    varchar(2000) description;}table userapplicationright {    int user_id foreign key from user;    int applicationright_id foreign key from applicationright;}table whatever1 {    int id primary;    int user_id foreign key from user;    ...}table whatever2 {    int id primary;    int user_id foreign key from user;    ...}table whateverN {    int id primary;    int user_id foreign key from user;    ...}

And yes, it is not SQL. It is a not standardized from of notation I just used to show the structure. The correct SQL should not be of any interest, since my quest I have is about structuring the database contexts for EF.

Now the application has several use cases. One is to check the user password on login. Others may be to setup userrights or CRUD actions on entries in one of the whatever tables. Since the database itself contains a lot of different tables - some connected to the user table, others not - it seems a good idea to create a dbcontext based on the actual use case it will be used for.

This seems to be a good idea to me because it

• hides the rest of the database from the actual use case
• reduces overhead while creating the context

So is my idea correct and if so what is the best practice to achieve the goal?

Any hint will be appreciated, to state it again.

Thanks in advance...