1 Each plane is a table in your DB design. 2 Eventually you can also start a table with all planes as its records, each one of them with an unique reference 3 Each table/plane will consist of certain number of records, each one of them is a part, with an unique reference number. 5 Each one of these records has as well among other pieces of information a unique tag which will be the link to any other part, in other plane/table 6 Each one of these records is in turn an XML file with recursive information, which includes a nested structure, including tagged components accordingly
You will have all planes connected by corresponding tags which in turn will point to all tables where those components are part of different planes. You would be able to explode/implode any plane in any war/peace scenario depending on common definition procedures. Stocks and locations are obvious and would not need further design You just need someone able to start for instance a common SQL database, with knowledge of XML technology. That would be a simple design, that you can also develop into the web without security concerns On 26 fev, 12:03, Georges Metanomski <[email protected]> wrote: > 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.
