My former student who became general charged with plane maintenance
of an Air Force asked me to audit various envisaged designs of the
maintenance Data Base. Actually I had designed the original version,
but it was back in 71. Many versions using new tools succeeded as well
as many pressing ad hoc "temporary" patches and we know that nothing
sticks longer than temporaries. As result the DB got inflexible and
unyielding to updates, conversions and modifications.
Applying my principle that beyond a certain corruption level a system
has to be redesigned from scratch, he issued an invitation for bid
for design and implementation of a new DB system.
The problem may be briefly described as follows:
Each plane has to pass regularly a revision of a different level
depending on flight hours. A revision involves exchange of particular
parts. Thus, planning a revision we have to determine the number of
parts to be available in store of the particular air base, as well as
dismount paths to reach them in the plane structure. In techical terms
we have to "explode" the plane into its parts. Let's remember that
some item may be a part of several aggregates, either independent or
containing recursively one another. The recursivity depth is open and
adjustable in function of new planes and new devices and can easily
reach 100. In case of being understocked, other air bases have to be
searched and replanishmend orders issued. But that is marginal and
my audit concerns the core of the problem, to wit the explosion.
That's in peace. But in war the parts may stop being supplied and
all stores may run out of them. And that's where the real problem
starts. A part may belong to various planes and planes have various
importance. At the time when I designed the original version some
parts were shared by Phantom and Hercules and it was accepted to
dismount a Hercules to keep the Phantom in the air.
Thus, for a Phantom's part missing in all stores we had to "implode"
it, i.e. to search in which aggregates of which planes in which
quantity it exists. Then, picking up the planes by inverse of
importance we had to search the bases (again by importance order)
for their availability and once found - explode the planes to get
dismounting paths towards the required part.
Now, I have two problems:
1.Since I stopped programming there came lots of new tools, which may
support designs which I may understand, but with which I have no
practical experience.
2.Having done an ancient, but successful design I may be biased towards
it and misjudge alternative solutions.
That's why I could do with suggestions of people more au courrant of
the current computing cutting edge than myself, like Richard, Eray
and doubtless other members of our lists.
Now, my audit is restricted to the crucial issue of DB design and its capacity
of supporting:
1.recursive explosion of a plane into requested parts,
2.recursive implosion of each requested part into all less important
planes.
I'll appreciate suggestions, best in form of the usual Entity/Relation
terms easily shown with ASCII indented format.
Thanks in advance.
Georges.
--
You received this message because you are subscribed to the Google Groups
"Epistemology" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/epistemology?hl=en.
