Database design for multiple account types management system
You are going down the path of table explosion with resulting complicated queries.
In a relational database, you want fewer tables but more columns, fewer columns but more rows.
Applying this mantra: your two types of accounts should be one accounts table with a type column. You could have two child tables to store data specific to each type of account if there would otherwise be too many null columns. But if there are only one or two such attributes I would personally add them as nullable columns and add a constraint something like:
 alter table accounts
   add check (type = 'normal' and pro_attribute is null or type = 'professional' and pro_attribute is not null);

where pro_attribute is the name of an attribute that only applies to professional accounts.
This could be simplified to:
alter table accounts
  add check ((type = 'normal') = (pro_attribute is null));

but that's not clearer.
Then for your profiles, you need to apply the same pattern: One profiles table with a service column. If individual services have different attributes you can store them in their own child tables.
As far as the relationship to services: it sounds like each account has one profile for each service that exists. In this case I would create the profiles table with columns account_id (foreign key to accounts), service (or service_id as a foreign key to a services table) and any attributes you need for that particular service for that particular account.