"Position" vs "location"

To represent your several categories, you need words that (a) already have meaning specific to your need; that (b) are uncommon, to sidestep confusion that arises when a word is used multiple ways; and that (c) can flex, taking suffixes -ed, -able, -less without elephantining. (The -less suffix denotes -able but not yet -ed, e.g. fixable but not yet fixed.)

In chart below, (a), (b), (c) denote these criteria (specific; uncommon; flexible), and I, II, III denote your categories: I (placed), II (aimed), III (aimed and placed). Each line of the chart suggests a base word and its category, then an assessment (+, ., -) for good, neutral, bad.

• orientationless, I: .a +b -c
• locate, I: +a .b -c
• place, I: +a .b +c
• spot, I: +a +b +c (except spotless may confuse)
• fix, I: +a .b +c
• locationless, II: .a +b -c
• rotate, II: +a +b -c (rotatable and unrotated both clumsy)
• line, II: .a .b +c (except lineable is clumsy)
• head, II: .a .b +c
• aim, II: +a .b +c (except aimless may confuse)
• position, III: .a -b -c
• tangible, III: -a .b -c
• fungible, III: -a .b -c
• solid, III: .a .b -c
• overt, III: +a +b -c
• patent, III: .a .b +c
• 6-fixed, III: +a +b +c

You might disagree with my assessments, but could use a similar approach in evaluating some words. As you can see from the list, I think overt and 6-fixed, a neologism, are the best possibilities for naming your aimed-and-placed objects.

Personally, I'd start by calling the two existing categories something like orientationless and locationless. The lack of one attribute or the other is presumably the defining feature of each category, if most objects in the database actually have both.

Alternatively OP can draw on David Deutsch's somewhat creative use of the word (imagine drumroll here) fungible. As per my answer here, this seems to imply that every measurable attribute of some particular "thing" could be replicated in another one. Deutsch thinks there may be an infinite number of "things" sharing exactly the same combination of attribute values, but OP's database could probably get away with storing them all as one single record (or possibly store them all in an infinite number of fungible databases).