Theoretically, relationships are
View n - 1 ViewModel n - 1 Model
I know, a lot of people will bite and beat me, but... In practice...
Very often, in business applications, there is data access layer (DAL). And very often entities from DAL are your Models. Sometimes you should wrap those entities with additional classes to provide extended functionality or maybe some additional properties. Maybe you have your own Models...
ViewModels and Views (in practice) usually have 1 to 1 relationship. Something like - every screen (or part of screen) is actually a paired View and ViewModel. I think usually just something like - View is UI layer and ViewModel is code-behind level. View is just XAML file - presentation layer. And (the best practice) everything else should be in ViewModel - all data receiving processes, all commands, all changable fields etc. This way you can usually test ViewModel (with unit testing). One ViewModel can have several Views (in practice) usually only when you have shared ViewModels for, for example, DesktopApplication (WPF), Web Application (Silverlight) and Windows Phone. Something like this. But usually - one ViewModel - one View. If you have several Views for one ViewModel - usually you will have a lot of maintaince problems...
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…