I'll make it brief and to the point. This is how Starcraft "sprites" are structured and percisely how they function.
You may have noticed that in Arsenal II's unit editor, you can choose different "sprites" for each unit (and each weapon projectile). This is one place where the Starcraft will "start" connecting up a sprite. What I mean is, the "sprite" you choose -- or more percisely, the flingy.dat entry you choose (more on that later) -- will determine percisely what properties it has. There are likely other starting point in which Starcraft will start a sprite, for example the tileset files might connect up the doodads.
The "sprite" you chose in the Units and Weapons editor (units.dat and weapons.dat respectively) is actually just a "pointer" (or a number that "links") to an entry number in the flingy.dat file. You can edit it in the Misc. Editor of Arsenal II. So, if you chose the scourge, for example, you are actually telling the unit to use the first entry (or actually Entry 0) in flingy.dat. Besides a couple identification errors, the arsenal\sprites.txt list that Arsenal II writes out in your cwad will correspond each sprite to an entry (i.e., the first name listed corresponds to entry 0, the second corresponds to entry 1, third to entry 2, etc. in flingy). This way, you can find out what flingy entry is what (or wait until the next Stardraft which will have them all identified).
You should think of flingy.dat is the list of "unit/weapon sprites." It would be incorrect to say that they are all the sprites in Starcraft because there are actually many more (like doodads and all other graphics). Flingy.dat controls properties that solely belong to unit or weapon sprites such as the speed at which they move, how fast they turn, and things like that. For specifics ("specs") go here.
The first variable in flingy.dat (currently labeled as "Unknown 1") is a pointer to an entry in sprites.dat.
Sprites.dat is a more comprehensive listing of the Starcraft "sprites." The first 130 entries are doodad graphics and the remaining are either unit/weapon sprites or unused ones (I believe). Sprites.dat controls things like how large the sprite's health bar is and what graphic (another sprite) to use as its "selection circle." Arsenal II is not capable of editing sprite.dat yet so I put up a little post I made which identified most of the variables. You will have to know how to hex edit in order to understand it. View it here.
The first variable in sprite.dat is a pointer to an entry in images.dat.
Now, it would be correct to say that images.dat is a complete listing of all the sprites (or graphics) in Starcraft. Everything from doodads to unit graphics to explosions, etc. are in here. Actually, it is not really accurate to speak in terms of "units" or "doodads" anymore because in actuality, you can make any entry become anything you want.
Images.dat mainly controls things like the palette (colors) to use for the graphic, where to put certain "overlay" graphics (other sprites that go "ontop" or "below" of the graphic), and a few other random things. For specs go here; for an entry list, go here. Mainly, it is just another pointer file.
The first variable in images.dat (currently labeled "Unknown 1") is a pointer to a line the images.tbl file. The images.tbl file is a listing (with each "entry" in a single line) of the grp files in the mpq. So basically, the first variable in images.dat determines what actual grp the sprite uses. Keep in mind that a grp is nothing more than a collection of image files in a particular order. They really have no "control" properties at all.
The variable currently labeled as "Unknown 8" in images.dat is a pointer to an entry list in the iscript.bin file.
The iscript.bin is really the "meat" of each sprite because it determines each way it is actually animated in the game. In other words, it determines which grp frame to play when, which sound to play at certain times, and what "overlay graphics" (other sprites) to spawn where. An important note is that the iscript.bin is not the "end" of the chain of links that build up a Starcraft sprites, because many times, the iscript will again have pointers back to the images.dat (particularly when it wants to play an overlay graphic). When this happens (say to spawn an overlay graphic like the wraith thrusters), another images.dat sprite is called which has its own iscript entry (and thus its own set of animations). It is possible to cycle this "pointer" process indefinitely (though probably not practical =).
As of now, Camelot Systems is working on a user friendly editor for the iscript.bin, but it is not complete yet. If you are comfortable with hex editing, you can view my full article on the iscript here.
If you will notice, the images.dat file has a lot more entries compared to, say the flingy.dat file. What might Starcraft do with all those extra sprites? (all 999 of them) Well, there is a lot, and in fact, most of them are probably used (unlike the morass of unused units that exist). For example, each "shadow" has its own images entry, each explosion, each morphing animation, each doodad, and even things like smoke effects and "blood." It is all very complex, so it is no wonder that Starcraft can get laggy when it has to display and control literally thousands of different sprites at a time.
I hope that all made some sense.