Normalizing tables Issue

Neither the first, nor the second. In the classic relational model thinking, there are no flags. You have two tables instead:

A provider and a consumer table. These are simple tables:

Consumers: AgencyID (PK, FK)
Providers: AgencyID (PK, FK)

When looking further into this, you will maybe have an agency, which is both. But you'll have different contacts for consumers and providers.. then these simple tables come in very handy:

Agencies: AgencyID (PK), AgencyName  -- No contact here
Consumers: AgencyID (PK, FK), ContactText
Providers: AgencyID (PK, FK), ContactText

Another solution is possible, when your consumer/provider status is really mutually exclusive:

Agencies: AgencyID (PK), AgencyName, ContactText, AgencyCategoryCode [C,P,NULL only]

What makes an agency to be a provider or consumer? Can be both at same time?

Thanks a lot ste5an for your help.
It is happening that agency is Provider & Consumer in same time, so shall we keep their "ID & Name" in agency table and "duplicate" their other information in provider table and consumer table as well?

Thanks a lot Vitor.
- We are exchanging some data between more than one agency; and we say agency is:
- Provider, when it's providing certain data to other agencies in order to deliver their online services.
- Consumer, when it's consuming certain data from other agencies to deliver their online services.
- Agency may be a Provider only OR Consumer only OR Both.

So, do you really need a flag to say if the agency is Provider or Consumer?
I mean, you can know it depending on the data flow, right? i.e. which tables tracks the following information?
"- Provider, when it's providing certain data to other agencies in order to deliver their online services.
 - Consumer, when it's consuming certain data from other agencies to deliver their online services."

in the classic relational model thinking, there are no flags.

Not sure about that.  But there are certainly supertypes and subtypes in logical modeling, and that could be applied here.  

That wouldn't apply here, but you could still have a "type" column added to the Agency table, but there would be separate rows for the Provider and the Consumer entries.  That is, each would get its own AgencyID.  You could create another table to relate AgencyIDs to the same parent company, if you needed it.

That's because you want to see the "Provider" and "Consumer" relationships specifically, rather than just combined.  That is, if an Agency is both P and C, you want to be able to query: what are this Agency's relationships as a Provider, and what are they as a Consumer.

If it's the same AgencyID, you can't do that.  This need becomes even clearer when you consider adding another type(s) of AgencyID in the future (3rd Party Provider maybe?).

Thanks a lot Vitor, ste5an, Scott & Olaf  for your excellent explanations.
it's was very informative discussion for me and I'll evaluate what will be best for my case right now.