That's pretty much how Windows works, and you're pretty much stuck with it.
Now I can see you asking yourself:
Why the heck does Windows do that when any self respecting Linux can do all the updates in one go?
The answer comes down to how Windows and Posix *nixes handle the open file problem. On Windows, if a file is open it also has a DenyWrite lock on it and the file can not be written to. Such as for an update. On Linux, everything is a file, and all files can be updated, so the file just gets updated. If the file can't be updated for some other reason the installer throws a cryptic error and it gets tricky to figure out why the update failed.
Because Windows can only update certain files during the reboot process, you get cases where you need multiple reboots to apply certain patch-sets. This happens the most when updates for different products overlap files in some way, and that later update needs the previous update to be actually applied before it can update. Windows has gotten A LOT better about dependency checking over the years, before Windows Update it was common practice to apply each update individually with its own reboot[1], but there are still some things it gets confused about; especially when it is also doing OS, IE, and Media Player patches all at the same time.
The last time I staged up a Server 2003 server (not R2) it took four reboots to get everything updated, not including the service pack. If I'm staging up a SLES 9 server (dates from about the same time, on a 2.6.4ish kernel), that update set is also going to be fearsome. The 'rcd' process used on that distro will get confused by the size of the update, so I would have to update just that a couple of times before I could update the entire patch-set. It isn't multiple reboots, but it does require multiple applications of the update process. And on SLES9, RCD can take a bloody age to chew through large update sets, so that SLES9 server would probably finish updating everything after the Win 2003 server would[2].
[1] There were some tools out there to help 'chain' updates, but different IT shops had different ideas about using these tools on production systems.
[2] Which just shows the quality of the rcd process on that distro. So glad that died with SLES11.