Top, bottom… what are you talking about? What options you may possibly have?
Let's say, you have a database server with a database. Let's say this is your
back-end data tier. You can have another tier, running your WCF service. It can use different hosting (IIS, self-host…), different protocols — this is the whole idea behind WCF, but your
application-layer protocol in on you, it can be expressed in the form your you WCF
service contract. You can have many options here. Your contract can be close to the database semantics, or it can abstract out functional detail of your particular database service and present some more generalized database model. Or it can reflect just the semantics of your application. Or you can combine those approaches. And you can have more than one WCF service. Your service application should play the role of the WCF and, from the other hand, should act as a client of your database.
And then you can have anything else you need, but the idea is: your other tier(s) will communicate to the database only through your WCF tier.
Please see:
Multitier architecture - Wikipedia, the free encyclopedia[
^].
—SA