Tough? You ain't seen nothing yet...
Mind you this is advice, although it may sound like criticism.

> Well, in this particular application (and in general) one could argue> that if you design the interfaces properly, it doesn't matter the> order or simultaneity between the 2 aspects above.

No, one could NEVER argue that. You simply CANNOT design and code
an application that manipulates data without first analysing the
relationships of that same data. The simple fact that you needed
to ask a question about how to store the data in Oracle proves that
you don't have the foggiest idea how to store that data in a database.
Because you spent no time at all designing the data model. Which means
you have not spent anytime figuring out how to store your data out of
main memory. A typical situation in modern so-called "design".

> This protocol is simple and standard enough. When you need to fill> the tree/forest at the GU level, the Oracle/web server will send you> something like this:

Excuse me: "the Oracle/web server"???? Are you sure we're all talking
about one and the same thing?

> That's the _only_ agreement necessary between the client and the server> and therefore it doesn't matter whether I resort to a traditional> (i.e., relational) storage or the more flexible objects.

Really? Explain two things:
1- How are objects more flexible, given that you have no idea
how to store them? And please do NOT say "serialize", say "store":
that is the proper name. Renaming something obvious to make it obscure
achieves nothing.

2- Since when is there such a thing as an "agreement" between a
client application and a database server? What you need is a
definition of what data you have in the client, what you data have in
the server, and how one maps to another. There is no such thing as
an "agreement": this is not politics, this is IT and data engineering.

> Two programmers incomunicado from each other could do the project,> an Oracle DBA and a GUI type of guy.

And end up like you with no idea how to store the data offline...
In IT this problem was solved 40 years ago. Apparently it's back.

Your reply to Nial on how some companies might not have a state
and district "hardwired into a table name" is typical of this state
of affairs. Nowhere did Nial imply that the name of the table
had ANYTHING to do with the data. It doesn't, it never did.

You store AVAILABLE districts and AVAILABLE states in tables,
THEN you link them to the appropriate company using foreign keys.
Drag and drop all you may care, the above is what you MUST do.

If you want to change a bunch of companies to another one, you
drag and drop the companies to wherever you want them (GU stuff) AND
you link them to the appropriate owner. This happens WITH or
WITHOUT objects and is ALWAYS done. Assuming of course you're
talking about the state and district. If you're talking about
ownership of the company, then the situation is completely
different, the state/district stuff is totally irrelevant
and I don't even understand why it was called into here.

On a general note:
Don't try to tell me that objects can somehow "magically" be dragged
around and they know who belongs to what: there is no such thing.
Objects are as EXACTLY as dumb as you make their methods. They do nothing
unless there is a method to tell them what to do, inherited or not
is immaterial.

You MUST have a method associated to the object class to get the object
instance to do anything. That method also must change the data
relationships if you plan to store all that jazz in a database. Otherwise
you have no way whatsoever of knowing later on when you load the data back
to memory, what was where and how.

Assuming of course that you believe data must be stored offline.
If you are of the belief that data should always live in memory and
all else are "implementation details", then quite frankly we're done.