A simple question with a complex answer. AFAIK fpmurphy is essentially correct but there are at least two situations in which that is not the whole story.
Firstly the dreaded zombies! If a child process has terminated but its exit status has not been read by its parent then, when the parent is terminated, the kernel re-parents the child to the init process, process number 1. The child becomes a "zombie". Thus the child process has been killed (it is no longer executing) but it remains in the process table indefinitely.
Secondly, if the process group leader is a terminal and it is killed, the kernel will send the "hang up" signal (SIGHUP) to all the processes in the dead terminal process' group. By default, they die on receiving SIGHUP but they can be configured differently. See the nohup command for an example.
There may be other situations in which members of a group do not die when their group leader or parent is killed.
As for whether it is normal ... it is often done but there could be systems an which it is rarely done; it's a question of usage and signal handling. A process can be programmed to do whatever the programmer implemented on receipt of every signal except SIGKILL. SIGKILL cannot be ignored, a bit like death.
For more information http://www.win.tue.nl/~aeb/linux/lk/lk-10.html