First and foremost I think you need to define exactly what technology you want to be using. You keep saying DataSet which I would assume you are being forced to use classical ADO.NET database programming. If this is the case it doesn't really matter which order you build your objects.
Your application will utilize objects which you will hydrate from you ADO.NET DataSet or you can use the newer features of Load<Type>()
to return the hydrated object. You would first build your objects out that you will want to return, these objects should be independent of database considerations. (When and where you build your database model doesn't matter, you could do it now or later... persistence concerns should not interfere with object modeling and business logic)
Example:
public class Book
{
public string Title {get;set;}
public DateTime PublicationDate {get;set;}
public decimal Cost {get;set;}
public virtual Author {get;set;}
}
public class Author
{
public string Name {get;set;}
public DateTime DateOfBirth {get;set;}
}
Next you would build out your repository to return the objects and define your queries. Instead of once again typing this out I'll give you a few links to read.
Repository and Data Mapper pattern
You then use your DataSet to hydrate your objects whether it be from a SQL query or from a Stored Procedure makes no difference.
HOWEVER
I would advise you to do some research into Entity Framework 5RC or Entity Framework 4.1+ Code First to do this. ADO.NET is not the best way of doing this. There is a plethora of data here on stack about how to work inside Code First but I'll give you a link or two to get you started down that path if it is an option.
How to query a complex result set from EntityFramework and display the result set in MVC.
Something I forgot to mention
You CANNOT and SHOULD NOT return a live dataset from WCF. There are hacks to allow you to do this but I would highly advise you do not do this for MANY reasons. WCF should return out a DTO (Data Transfer Object) which is entirely independent of persistence concerns and contain purely data with no logic. This then can serialize and deserialize without any concerns over someone having the object DTO and being forced to operate under the .NET environment. A WCF service should be able to be consumed by any SOAP capable language and deserialized into objects within that language.
Responses from WCF are essentially just XML serialized objects and you should ALWAYS consider what additional concerns am I injecting into my DTO that will not exist in any WCF responses to a consumer of your service.