I'll answer your second querstion first: both vertex and pixel shaders can treat part of (4 constants) their assigned constant memory (basically an array of 4D vectors, which can also be interpreted as integers or booleans with more modern shader versions) as a matrix in row-major format. It's up to you to upload the "right" transformation matrix for a job. So for example, for a standard 3D transform you'd upload this: Matrix mFullTransform = mProj * mView * mWorld, to transform a rigid vertex from object space. Get a basic (may just as well be dated) book about programming the post-fixed-pipe graphics pipeline. I have an old nVidia book called the CG tutorial lying around that covers this quite well.
As for multiple shaders, depending on your application design it might be a good idea to split up vertex and pixel shaders. From there on a common challenge is to write a shader that transforms/renders geometry based on a material. The material likely imposes small differences in the shader code. Now you can choose to upload these parameters (for a modern model) to constants and branch at runtime. This is not a very speedy approach though so it might be a good idea to take a different one. An often used strategy is to 'build' (or splice) and compile shaders at compiletime (or, in some simpler or runtime cases on initialization) and pair them up with the corresponding (material) data. Tailor your solution to your needs: for simple games and graphics demos it usually suffices to write all the shaders by hand and perhaps take a small hit left or right for a runtime parameter or 2.
Anyway hope it helps, been out of this game for a while.
[EDIT] Look at the first comment as well, has a good point about an important difference between D3D (which I mistakenly assumed, force of habit..) and OpenGL.